statefull Firewall arp Probleme

F

fgemein

Member
Hallo und guten Abend
Ich habe bereits einen Thread auf unixboard.de eröffnet und dort den Tip bekommen, es hier zu versuchen.
Guten Morgen

Ich bin Techniker bei einem Internet Provider und administriere u.a. nun auch mehrere Openbsd Firewall Cluster mit packetfilter.

Die ersten Systeme sind von meinem Vorgänger aufgesetzt worden, ich selber bin erst durch sie mit BSD in Kontakt gekommen.

Ich bin sowohl von Packetfilter, als auch von Carp sehr begeistert, habe nur ein Problem , bei dem ich nicht so recht weiterkomme:

Mit zunehmender Anzahl von offenen states bekomme ich immer mehr incomplete Einträge im Arp Table, sprich Ping schlägt fehl, weil die IP<->Macadressen Auflösung versagt.

Nun frage ich mich, wie ich das Problem lösen kann:

Ich möchte eher nicht mit static Arp Einträgen arbeiten, dafür sind die Umgebungen hinter der Firewall zu groß.

Gibt es eine Möglichkeit die Lebenszeit der 'keep state' Anweisungen einzuschränken?

Kann man Parameter ändern (buffer, ulimits o.ä), um die Zahl der möglichen States zu erhöhen?

Gibt es eine Möglichkeit eine extra nic für die DMZ komplett an PF vorbei zu routen?

Ich bin ein echter BSD Laie, langjähriger Linuxer, und wäre für jede Hilfe echt dankbar.

Danke

Frank
Zum Vergrößern anklicken....

Eine Beispiel pf.conf

ext_if="bge0"
int_if="bge1"
sync_if="em0"
loop_if="lo0"

ext_ip="XX.XX.XXX.XX"
vip="XX.XX.XXX.XX"

set loginterface $ext_if
set optimization normal
scrub in on $ext_if all fragment reassemble
set skip on { $loop_if }

# Netze die nicht geroutet werden sollen
table <NoRoute> { XXX.X.X.X/X, XXX.XX.X.X/XX, XXX.XXX.X.X/XX, XX.X.X.X/X, XXX.XXX.XXX.XXX/XX }
table <gateways> { XX.XX.XXX.XXX XX.XXX.X.XXX XX.XX.XXX.XX XX.XX.XXX.XXX XX.XXX.X.XXX }
table <XXX> { XX.XXX.X.XX XXX.XX.XXX.XX }
# customer Rules in anchor laden
load anchor customer from "/etc/pf/customer.pf"
# openvpn Rules laden
load anchor openvpn from "/etc/pf/openvpn.pf"

# kein IPv6
block quick inet6
# RST auf geblockte pakete senden
block return log on $ext_if
# interne netze gegen spoofing sch�tzen
antispoof for { $loop_if $int_if }

# pfsync + carp immer erlauben, ssh via sync_if zum debugen
pass quick on $sync_if proto pfsync keep state (no-sync)
pass quick on $sync_if inet proto tcp from any to any port ssh keep state
pass quick on { $ext_if $int_if } proto carp keep state
pass quick on { vlanXXX vlanXXX vlanXXX vlanXXX vlanXXX } proto carp keep state

# Debug
#pass quick all

# grundsaetzlich alles erlauben, kunde muss firewall 'aktivieren'
pass all

# customer rules
anchor "customer/XXXXX" on vlanXXX
anchor "customer/XXXXX" on vlanXXX
anchor "customer/XXXXX_X" on vlanXXX
anchor "customer/XXXXX_X" on vlanXXX
anchor "customer/XXXXX" on vlanXXX
anchor "customer/XXXXX" on vlanXXX
anchor "customer/XXXXX_X" on vlanXXX
# firewall schuetzen
block on $ext_if inet proto { tcp udp } from any to $ext_ip
block on $ext_if inet proto { tcp udp } from any to $vip
pass on $ext_if inet proto tcp from { XXX.XX.XXX.XX XX.XXX.X.XX } to $ext_ip port ssh
block on $ext_if inet proto tcp from ! <XXX> to <gateways>
# openvpn rules
anchor "openvpn"
Zum Vergrößern anklicken....
Ich denke, daß die weiteren anchor files nicht so interessant sind.


Anscheinend könnte es auch daran liegen, daß pfsync bei einer großen Zahl an states rel. viel Traffic zwischen den einzelnen Firewalls generiert.

Ich freue mich über jede Antwort

Viele Grüße
Frank
 
Dass Arp-Einträge die Ursache für dein Problem sind würde ich jetzt nicht vermuten, denn erstens reden wir dann von Layer 2 und zweitens hat pf da keine Aktien drin. Wie viele Arp-Einträge muss dein System denn verkraften?

Ich würde eher vermuten, weil deine Umgebung ja so groß ist, dass eventuell der für States reservierte Memory nicht reicht. Beim Überfliegen deiner conf fällt dann auch auf, dass du hierfür keine Optionen gesetzt hast.

Schau mal im Handbuch:
set limit option value
http://www.openbsd.org/faq/pf/options.html
und hier noch Stateful Tracking Options
http://www.openbsd.org/faq/pf/filter.html#stateopts

mfg
morph
 
Hallo und danke Morph,

das sieht sehr gut aus.

Da der default Wert für states auf 10000 gesetzt ist und das sich auch mit der Anzeige von pftop bei auftretenden Problemen deckt, habe ich mal das Limit auf 50000 erhöht.

Ich melde mich, wenn ich weiß, ob es geklappt hat.

Danke nochmal

Frank
 
Gern geschehen. Wenn es hilft und hier eine Rückmeldung kommt, macht es mir auch mehr Spaß mich solcher "Probleme" anzunehmen.
 
Sieht sehr gut aus!

Hallo Morph,
ich habe jetzt die Zugriffe nicht gemonitored, aber die letzte Nacht war ruhig, es scheint also zu klappen.

Danke noch mal, bis zur nächsten Frage ;-)

Viele Grüße

Frank
 
Scheint ja neuerdings eine gefragte Information zu sein. Wäre mal interessant zu wissen, in welcher Größenordnung OpenBSDs pf eingesetzt wird und zuverlässig seinen Dienst verrichtet.
Bei mir im Netzwerk komme ich nicht annähernd an 10000 States ran, liegt aber auch am Einsatzzweck im Access-Network.
 
morph schrieb:
Scheint ja neuerdings eine gefragte Information zu sein. Wäre mal interessant zu wissen, in welcher Größenordnung OpenBSDs pf eingesetzt wird und zuverlässig seinen Dienst verrichtet.
Bei mir im Netzwerk komme ich nicht annähernd an 10000 States ran, liegt aber auch am Einsatzzweck im Access-Network.
Zum Vergrößern anklicken....


hi laeuft sehr gut . aktuell mit 2x 100 Mbit standleitungen die zz
bis zu , je nach tages zeit, 80% ausgelastet sind.

grund saetzlich ist openbsd als firewall , ipsec / sicherheitloesung immer einem linux vorzu ziehen

gerade was die themen ua. ha-cluster , statefull connection , cryptografie w^x
allgemente sicherheit des os betrifft.

das thema arp kommt nicht zwingend von den states ! und es ist auch nicht tragissch.

die gemeinten arp eintrage kommen von scans von aussen auf locale ip´ s die
es im zweifel nicht , mehr , gibt.

ich vermute mal das die drop policy auf return ist . ( was auch richtig so ist
, aber dass ist ein anderes thema ;) ) . <- UPDATE das kommt davon , haette ich nicht nur fluechtig gelesen hatte ich gewusst
das die drop policy via block return auf return steht .;)



holger
 
Zuletzt bearbeitet:
mark05 schrieb:
hi laeuft sehr gut . aktuell mit 2x 100 Mbit standleitungen die zz
bis zu , je nach tages zeit, 80% ausgelastet sind.

grund saetzlich ist openbsd als firewall , ipsec / sicherheitloesung immer einem linux vorzu ziehen

gerade was die themen ua. ha-cluster , statefull connection , cryptografie w^x
allgemente sicherheit des os betrifft.

das thema arp kommt nicht zwingend von den states ! und es ist auch nicht tragissch.

die gemeinten arp eintrage kommen von scans von aussen auf locale ip´ s die
es im zweifel nicht , mehr , gibt.

ich vermute mal das die drop policy auf return ist . ( was auch richtig so ist
, aber dass ist ein anderes thema ;) ) . <- UPDATE das kommt davon , haette ich nicht nur fluechtig gelesen hatte ich gewusst
das die drop policy via block return auf return steht .;)



holger
Zum Vergrößern anklicken....

Hallo nochmal,

Seltsam ist eben, daß zunächst immer nur ICMP von den zu vielen states betroffen ist.
Und dass sich mit den states die incompletes häufen. Was aber eigentlich nicht durch scans von außen passiert, sondern weil die Web-Entwickler mal wieder die /etc/hosts auf ihren Appservern nicht angepaßt haben und somit jede Menge interner Traffic über die äußeren IPs läuft ( pftop ), Ansonsten laufen die Port 80 Anfragen am FE Cluster vorbei (DMZ).


DOS Attacken und Floods bleiben entweder bei unseren Uplink Providern hängen, oder werden durch einen eigenen Algorithmus als untypischer Traffic von den Switchen ausgelesen und vom nagios gemeldet.

Wir haben derzeit an 3 Standorten Packetfilter im HA Modus mit carp im Einsatz. Mit potentiell bis zu 1 Gb/s , was aber nicht vorkommt, .s.o.

2 unserer Kunden machen derzeit jeder > 30 TB/Monat, unser Rekordpeak an einem uplink lag bei >900Mb/s.

Gateways, Loadbalancer, VPN und Firewalls alles Linux und BSD.

Nun will aber ein neuer Kunde seinen Traffic komplett über die Firewalls geroutet haben (eigene Firewalls/VPN ), deshalb mußte ich das Problem dringend lösen.
Er spricht von 100 Millionen requests pro Monat (warten wir es mal ab, aber wenn, müssen wir darauf vorbereitet sein)

Da die windows Server einsetzen wollen und wir die nicht administrieren, möchte ich mich nicht darauf verlassen, daß eine zweite IP auf den webservern dann tatsächlich nur Port 80/443 dauerhaft offen hat. Also muß ich pf optimieren.

Wobei auch der 2.Link von morph klasse ist. Der "max" Schalter an der entsprechenden Rule dürfte sehr hilfreich sein.


Grüße

Frank
 
hi

grundsaetzlich ist die menge des traffic und verbindungne kein problem
fuer obsd , vorrausgesetzt die hw stimmt.

fuer den rest muesste man sich das im detail anschauen und laesst sich
aus der ferne schlecht diagnostizieren.

icmp ist eine der meist verwendeten port scanning methoden vondaher kann die
menge der inkomplete arp ensprechend hoch sein.

du kannst ja mal statt block return ein block drop machen .

holger
 
Hallo, noch mal ne kleine Rückmeldung:

Ich habe mal mit mehreren siege Instanzen heftig requests generiert und bin ohne Probleme auf über 100000 states gekommen. Load 0.11.

Ich habe also max states auf 250.000 gesetzt und denke, das wird ausreichen.

Grüße

Frank
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben