IPs werden nicht per "overload" an die Tabelle übergeben

kippe333

Member
Hallo liebe Leute,

ich bin neu im Thema und verzweifel seit geraumer Zeit an den Stateful Tracking Options der Paket Filter.

Was möchte ich erreichen:
Ich möchte, dass wenn eine Regel zutrifft, die betroffene IP in eine Tabelle geschrieben wird.

Was habe ich bisher gemacht:
  • Ich benutze FreeBSD 9.1
  • Ich habe die src komplett neu heruntergeladen und einen neuen Kernel erstellt
Dafür habe ich die GENRIC Datei kopiert und folgende Zeilen hinzugefügt:
Code:
device pf
device pflog
device pfsync
options        ALTQ
options        ALTQ_CBQ        # Class Bases Queuing (CBQ)
options        ALTQ_RED        # Random Early Detection (RED)
options        ALTQ_RIO        # RED In/Out
options        ALTQ_HFSC      # Hierarchical Packet Scheduler (HFSC)
options        ALTQ_PRIQ      # Priority Queuing (PRIQ)
options        ALTQ_NOPCC      # Required for SMP build

Zusätzlich habe die rc.conf um folgende Einträge erweitert:
Code:
pf_enable="YES"
pf_rules="/etc/pf.conf"
pf_flags=""
pflog_enable="YES"
pflog_logfile="/var/log/pflog"
pflog_flags=""

In meine pf.conf habe ich zu Testzwecken folgendes eingetragen:
Code:
### INTERFACES ###
if = "{ em0 }"

### SETTINGS ###
set block-policy drop

### Timeout Options for anti SYN DDoS with short timeouts ###
set optimization aggressive
set timeout { tcp.first 5, tcp.opening 5, tcp.established 5400, tcp.closing 60, tcp.finwait 30, tcp.closed 30, tcp.tsdiff 5}

### OFFENE TCP/UDP-PORTS ###
tcp_pass = "{ 22 25 80 3306 11002 12001 13101:13108 13201:13208 13301:13308 13901:13908 }"
udp_pass = "{ 22 25 80 3306 11002 12001 13101:13108 13201:13208 13301:13308 13901:13908 }"
icmp_types = "echoreq"
test = "{ 11002 12001 13101:13108 13201:13208 13301:13308 13901:13908 }"

### Queues, States and Types ###
TcpState ="flags S/SA keep state"
UdpState ="keep state"

### Stateful Tracking Options (STO) ###
###NetSTO  ="( source-track rule, max-src-conn 3, max-src-nodes 1024, max-src-conn-rate 3/5, overload <newtwork> flush global)"
NetSTO  ="(max-src-conn-rate 2/120, overload <network>)"

### Network ###
table <network> persist file "/tmp/network"
#block quick from <network>
pass in on em0 inet proto tcp all $TcpState $NetSTO

### NORMALISATION ###
#scrub in all
#antispoof for $if

### Intra ###
table <intranet> { 127.0.0.1 }
pass in quick from <intranet> to any keep state

#ruleset
block in all
pass in quick on lo0
pass out quick on lo0
#table <blocklist> persist file "/tmp/blocklist.txt"
#block quick from <blocklist>
pass in quick on em0 proto tcp from any to any port $tcp_pass $TcpState
pass in quick on em0 proto udp from any to any port $udp_pass $UdpState
pass out all keep state

# PING #
pass in on $if inet proto icmp all icmp-type $icmp_types keep state

Ich weiß, nicht alles ist so wie man es eigentlich machen sollte, doch es ist wie gesagt ein Testszenario. Eigentlich funktioniert alles - aber nur eigentlich. Denn wenn die Regel
Code:
pass in on em0 inet proto tcp all $TcpState $NetSTO
eintritt, dann wird die IP nicht wie erwartet an die Tabelle <network> übergeben.
Zum Testen habe ich mich ca. 10 Mal innerhalb von 2 Minuten mit dem Server verbunden.

Ich kann mir das mittlerweile nicht mehr erklären. Denn ich habe alles so gemacht, wie ich es aus mehreren Tutorials herausgelesen habe. Ebenso gehe ich davon aus, dass die IPs umgehend aus der Tabelle ausgeladen werden können. Sollte ich mich irren, korrigiert mich bitte.

Via "pfctl -t network -T add x.x.x.x" kann ich die Tabelle manuell bearbeiten und IPs eintragen. Doch das soll ja automatisch passieren. Ich möchte hier gar nicht Handanlegen müssen.

Ich hoffe ihr könnt mir helfen.
 
Zuletzt bearbeitet:
moin


also 2 verbindungen , komplette 3 wayhand shake , in einem zeitraum von 120 sekunden initiiert von ein und der selben src ip.

quasi 2x telnet von src rechner zum dst.

sollte klappen , jedoch solltest du mal die tabelle ohne persistent erstellen. also nur

table <network>

wenn du den inhalt in eine datei haben willst mit
pfctl -t network -s > /tmp/network
dumpen.


holger
 
Hallo Holger,

herzlichen Dank für deinen Versuch zu Helfen. Ich habe deinen Vorschlag übernommen und den Zusatz "persist" entfernt und dann den Regelsatz neu geladen. Leider hat auch das nicht den gewünschten Erfolg. Die IPs werden immer noch nicht in die Tabelle geschrieben.

Für die Übertragung, die Sortierung und die Rückspielung der IPs in die Datei habe ich mir bereits ein Script erstellt, welches ich sobald das grundlegende Problem gelöst ist, per Crontab regelmäßig ausführen lassen werde. Momentan habe ich das allerdings bewusst nicht aktiviert.

Um eine Fehlerquelle beim Hoster auszuschließen, habe ich den Server ohne Zusatzprogramme in einer virtuellen Maschine lokal auf meinem PC aufgesetzt. Da ich den Fehler reproduzieren konnte, muss ich wohl eine Einstellung vergessen haben oder es handelt sich um einen Bug.

Gibt es vielleicht eine Möglichkeit, das Ganze auch mit IPFW umzusetzen?

Ziel:
Die hergestellten Verbindungen überwachen, und ab einer gewissen Anzahl die IPs automatisch in eine Tabelle schreiben.

Noch besser wäre, die Verbindungsversuche auf den Ports in einem definierten Zeitraum zu überwachen und diese dann ab einer gewissen Anzahl in eine Tabelle zu schreiben.


MfG
Sven
 
hi

stell doch mal das logging auf debug

set debug debug

beachte aber das es dann sehr viele eintrage gibt.

im pflog

holger
 
Hallo Holger,

wie trage ich das wo ein? Wenn ich "set debug debug" oder "set debug" in die pf.conf eintrage, dann kann ich den Regelsatz nicht mehr laden. Das gibt eine Fehlermeldung.

sven
 
Hallo Holger,

folgende Einstellungsmöglichkeiten habe ich für "set debug" gefunden:


set debug option
Setze pfs Debugging-Level.
  • none - keine Debugging-Nachrichten werden angezeigt.
  • urgent - Debug-Nachrichten werden für ernste Fehler erzeugt.
  • misc - Debug-Nachrichten werden für verschiedene Fehler erzeugt (z. B. um den Status vom Packet-Normalizer/Scrubber und Fehler in der ,state'-Erzeugung zu sehen).
  • loud - Debug-Nachrichten werden für typische Ereignisse erzeugt (z. B. um den Status des passiven OS-,fingerprinter' zu sehen).
Der Standard ist urgent.

Aber für keine dieser Optionen habe ich Einträge erhalten.

Sven
 
oh

dann setz mal loud

overload als funktion funktioniert einwandfrei da viele es auch als brute force schutz bim ssh nutzen

holger
 
Ok Holger,

ich habe das auf loud gesetzt.
Zusätzlich habe ich noch
  • set loginterface em0
  • und die Regel von pass in auf pass in log
abgeändert. Unter pfctl -si erscheint nun auch die Info "Debug Loud" und der Datendurchsatz für IPv4.

anbei nochmal die rc.conf:
Code:
pf_enable="YES"
pf_rules="/etc/pf.conf"
pflog_enable="YES"
pflog_logfile="/var/log/pflog"
pflogd_flags="-s 256"

Via "tcpdump -i pflog0" erhalte ich aber keine Infos und mit "tcpdump -n -e -ttt -r /var/log/pflog" sehe ich leider auch nichts.

Wenn die Funktion overload bei mir jetzt unter 9.1 nicht funktioniert, stimmt unter Umständen etwas mit meinen Grundeinstellungen in der pf.conf oder in der rc.conf nicht?

Sven
 
auch mal in den log files vom syslog geschaut ?

set debug loggt nach syslog ( pflog war mein fehler)

mit man pf.conf beachen

holger
 
Der einzige Eintrag der debug.log ist die Erstellungsmeldung der Datei mit dem Zusatz "first createt".
Eine Datei Syslog wurde im Pfad /var/log bisher nicht erstellt.

Sven
 
So nun habe ich den Fehler endlich entdeckt :). Was so ein kleines Wort doch alles anrichten kann...
Bei
Code:
pass in on em0 inet proto tcp all $TcpState $NetSTO

fehlt ein quick, damit PF an dieser Stelle anhält und die weiteren Regeln nicht mehr abgearbeitet werden.

Hier der richtige Code:
Code:
pass in quick on em0 inet proto tcp all $TcpState $NetSTO

Und nochmal herzlichen Dank für deine Hilfestellungen Holger.

Sven
 
Zuletzt bearbeitet:
Ich verstehe nicht, warum alle immer meinen, mit quick arbeiten zu müssen. Dadurch kommen dann solche Fehler zustande. Aber da bin ich wohl der Einzige...
 
Hi makenoob,

hättest du denn eine Alternative im Angebot? Ich kenne mich in der Materie offenkundig nicht so gut aus.
Ganz oben kannst du sehen, dass ich bei der Regel vorher ohne den Zusatz "quick" gearbeitet habe. Das Ergebnis ist bekannt... PF hat einfach die letzte zutreffende Regel auf den Port im ganzen Regelsatz angewendet und die IP nicht wie gewünscht, in die Tabelle geschrieben.

MfG
Sven
 
Ob quick oder nicht ist so eine Glaubensfrage. Man sollte nur konsistent sein, entweder überall quick oder gar nicht.
 
ich nehme halt gar kein "quick" und gehe da den Weg "last match wins". Es ist halt auch eine Frage, was für einen persönlich übrsichtlicher erscheint. Erst alles dicht machen, und dann immer granularer öffnen ist mein Weg. Man kann's natürlich auch "Kraut und Rüben" in die Konfiguration kippen und überall ein quick vorknallen, ohne sich Gedanken machen zu müssen ;)
 
ich nehme halt gar kein "quick" und gehe da den Weg "last match wins"
Quick kann halt potentiell das ruleset beschleunigen, statt für jedes neue Paket das komplette Set durchzugehen.

Erst alles dicht machen, und dann immer granularer öffnen ist mein Weg.
Wobei es da natürlich keinerlei Unterschied gibt, ob man ganz oben alles dichtmacht ohne quick oder am Ende eine sichere default rule mit quick hat.

Man kann's natürlich auch "Kraut und Rüben" in die Konfiguration kippen und überall ein quick vorknallen, ohne sich Gedanken machen zu müssen ;)
Für dich Kraut und Rüben. Andere kommen mit first match wins perfekt zurecht.
 
hi

quick machr schon sinn in bereichen wo sehr viele regeln aktiv sind.

gerade bei regeln zb http/https oder dns wo viele packete drueber gehen , die mussen dann nicht noch uinter umstaenden 200 weitere regeln durch laufen.

holger
 
der Unterschied war aber erst bei 5(0)k Regeln messbar, da das eh im Kernelspace abläuft; oder hat sich das mittlerweile so grundlegend geändert?
 
Zurück
Oben