[FreeBSD] PF unnütz oder doch nicht

[callmax]

Hallo Community,

Ich bin in diesem Forum gelandet um mich eben ein bisschen über eine Firewall schlau zu machen. Das einzige was ich gelesen habe ist das eine Firewall Blödsinn ist, mann sich eine HWF zulegen soll, etc. etc.

1. Ist eine HWF verdammt teuer
2. Was ist an einem Packetfilter AUF dem System den so schlecht.

Ich habe gelesen, Firewall hin oder her, die Firewall muss die Packets ja trotzdem filtern. Ist ansich richtig, aber im Falle eines dos / ddos kann die Firewall ja praktisch so konfiguriert werden das sie sieht, aha von dieser IP kommen Packets, zu schnell, zu groß und zuviele, zack wird die IP nullgerouted und kann dem entsprechend auch keine connection mehr zum Server aufbauen. Zack dos geblockt, bei einem ddos wäre das ganze natürlich schwieriger aber ich denke kleine botnets mit 500 bots +/- wären damit auch kein Problem. Was wäre denn nun nutzlos an eben so einem Packetfilter?

So ungefähr würde ich die PF dann aufbauen.

Code: Select all

pass in quick on $interface proto tcp from any to any port 13000 keep state (max-src-conn 15, max-src-conn-rate 8/3, overload <blacklist> flush global)
pass in quick on $interface proto udp from any to any port 13000 keep state (max-src-conn 15, max-src-conn-rate 8/3, overload <blacklist> flush global)

[ddm3ve]

Es gibt mehrere Gründe warum eine lokale firewall einfach nicht den Schutz bieten kann, wie eine vorgelagerte Firewall z.B. vom Provider.
Ich denke, Du verschmischt ein paar Punkte aus vielen Diskussionen die leider zu hauf nicht wirklich sachlich geführt wurden.

Dein Ansinnen, z.B. die Anzahl von Connections von einer IP zu beschränken ist durchaus ein legititmies Mittel um das lokale System / den Schaden durch eine DOS Attacke zu minimieren . Wenn der Angreifer allerdings Deine Leitung mit Packeten floodet, so dass die 1Gbit dicht sind bringt dir das auch nicht mehr viel. Ebenfalls wird der entstandene Traffik trotzdem berechnet.

Eine vorgeschaltete Firewall bietet einen zuverlässigeren Schutz ein und ausgehenden Datenverkehr zu regeln. Wird Dein System durch eine Lücke kompromitiert ist eine lokale Firewall zügig ausgehebelt.

[Joe User]

Moin,

Ich bin in diesem Forum gelandet um mich eben ein bisschen über eine Firewall schlau zu machen. Das einzige was ich gelesen habe ist das eine Firewall Blödsinn ist, mann sich eine HWF zulegen soll, etc. etc.

1. Ist eine HWF verdammt teuer
2. Was ist an einem Packetfilter AUF dem System den so schlecht.

Solange man den Paketfilter nur als Paketfilter betrachtet und nicht als Firewall, spricht überhaupt nichts dagegen, diesen auf dem Zielsystem einzusetzen. Betrachtet man ihn hingegen als Firewall, dann macht es keinen Sinn, denn:
*) Die Pakete prasseln nach wie vor ungehindert auf das System ein
*) Die Pakete müssen nach wie vor vom Kernel verarbeitet werden
*) Die Pakete verursachen nach wie vor den gleichen incoming Traffic
*) Die Pakete können nach wie vor das System vom Netz nehmen (DoS)

Es bleiben also alle entscheidenen Faktoren bestehen, gegen die nur eine vorgelagerte dedizierte Firewall helfen kann.
Die einzigen beiden Faktoren die man damit ein wenig abschwächen aber nicht verhindern kann sind:
*) Es fällt weniger outgoing Traffic an
*) Die jeweiligen Dienste werden etwas entlastet

Insofern macht eine Firewall auf dem zu schützenden System schlicht keinen Sinn.


Das nullrouten was Du erwähnst, ist etwas, das nur der Netzbetreiber/Provider auf seinen Routern durchführen kann, aber nicht der einzelne Serverbetreiber/Kunde. Dabei wird das Zielsystem aus den Routingtabellen der Router genommen, wodurch dann keinerlei Verbindung zum Internet mehr besteht (weder incoming noch outgoing).
Damit hat $Angreifer sein Ziel ebenfalls erreicht und der Serverbetreiber ungleich mehr Ärger als nur ein paar geDoSte Dienste.

So ungefähr würde ich die PF dann aufbauen.

Code: Select all

pass in quick on $interface proto tcp from any to any port 13000 keep state (max-src-conn 15, max-src-conn-rate 8/3, overload <blacklist> flush global)
pass in quick on $interface proto udp from any to any port 13000 keep state (max-src-conn 15, max-src-conn-rate 8/3, overload <blacklist> flush global)

Um Dir eine ganz einfache pf.conf als Einstieg zu liefern (kommt auf meinem internen IPv4-only Testsystem zum Einsatz) falls Du trotzdem PF als Paketfilter und Firewall nutzen willst (bitte selbst nach Bedarf anpassen):

Code: Select all

##### MACROS #####
ext_if = "{ re0 }"

##### TABLES #####
table <rfc5735> const persist counters { 0.0.0.0/8, 10.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, 192.0.0.0/24, 192.0.2.0/24, 192.88.99.0/24, 192.168.0.0/16, 198.18.0.0/15, 198.51.100.0/24, 203.0.113.0/24, 224.0.0.0/4, 240.0.0.0/4, 255.255.255.255/32 }
table <badhosts_sshd> persist counters file "/etc/pf.badhosts_sshd"
table <badhosts_http> persist counters file "/etc/pf.badhosts_http"
table <badhosts_smtp> persist counters file "/etc/pf.badhosts_smtp"
table <badhosts_imap> persist counters file "/etc/pf.badhosts_imap"

##### OPTIONS #####
set skip on lo0
set loginterface re0
set optimization aggressive
set block-policy return
set hostid 1

##### NORMALIZATION #####
scrub on $ext_if all no-df random-id max-mss 1440 reassemble tcp fragment reassemble

##### QUEUEING #####

##### TRANSLATION #####

##### FILTERING #####
block  in quick log on $ext_if inet              from no-route to any
block  in quick log on $ext_if inet              from <rfc5735> to any
block  in quick log on $ext_if inet              from <badhosts_sshd> to any
block  in quick log on $ext_if inet              from <badhosts_http> to any
block  in quick log on $ext_if inet              from <badhosts_smtp> to any
block  in quick log on $ext_if inet              from <badhosts_imap> to any

pass   in quick     on $ext_if inet  proto icmp  from any to any icmp-type echoreq    keep state
pass   in quick     on $ext_if inet  proto icmp  from any to any icmp-type unreach    keep state
pass  out quick     on $ext_if inet  proto icmp  from any to any icmp-type echoreq    keep state
pass  out quick     on $ext_if inet  proto icmp  from any to any icmp-type unreach    keep state

pass   in quick     on $ext_if inet  proto udp   from any to any port 53              keep state
pass  out quick     on $ext_if inet  proto udp   from any to any port 53              keep state
pass  out quick     on $ext_if inet  proto udp   from any to any port 123             keep state
pass  out quick     on $ext_if inet  proto udp   from any to any port 33433 >< 33626  keep state

pass   in quick     on $ext_if inet  proto tcp   from any to any port 53              flags S/SA synproxy state
pass   in quick     on $ext_if inet  proto tcp   from any to any port 22              flags S/SA synproxy state (max-src-conn  25, max-src-conn-rate  5/300, overload <badhosts_sshd> flush global)
pass   in quick     on $ext_if inet  proto tcp   from any to any port 80              flags S/SA synproxy state (max-src-conn 500, max-src-conn-rate 100/30, overload <badhosts_http> flush global)
pass   in quick     on $ext_if inet  proto tcp   from any to any port 443             flags S/SA synproxy state (max-src-conn 500, max-src-conn-rate 100/30, overload <badhosts_http> flush global)
pass   in quick     on $ext_if inet  proto tcp   from any to any port 25              flags S/SA synproxy state (max-src-conn  25, max-src-conn-rate   5/30, overload <badhosts_smtp> flush global)
pass   in quick     on $ext_if inet  proto tcp   from any to any port 587             flags S/SA synproxy state (max-src-conn 250, max-src-conn-rate  50/30, overload <badhosts_smtp> flush global)
pass   in quick     on $ext_if inet  proto tcp   from any to any port 993             flags S/SA synproxy state (max-src-conn 250, max-src-conn-rate  50/30, overload <badhosts_imap> flush global)
pass  out quick     on $ext_if inet  proto tcp   from any to any port 53              flags S/SA modulate state
pass  out quick     on $ext_if inet  proto tcp   from any to any port 22              flags S/SA modulate state
pass  out quick     on $ext_if inet  proto tcp   from any to any port 80              flags S/SA modulate state
pass  out quick     on $ext_if inet  proto tcp   from any to any port 443             flags S/SA modulate state
pass  out quick     on $ext_if inet  proto tcp   from any to any port 25              flags S/SA modulate state
pass  out quick     on $ext_if inet  proto tcp   from any to any port 587             flags S/SA modulate state
pass  out quick     on $ext_if inet  proto tcp   from any to any port 993             flags S/SA modulate state
pass  out quick     on $ext_if inet  proto tcp   from any to any port 43              flags S/SA modulate state
pass  out quick     on $ext_if inet  proto tcp   from any to any port 3690            flags S/SA modulate state

block  in quick log on $ext_if                   from any to any
block out quick log on $ext_if                   from any to any

Dazu dann noch diese Cronjobs:

Code: Select all

*/15    *       *       *       *       root    /sbin/pfctl -t badhosts_sshd -T show > /etc/pf.badhosts_sshd && /sbin/pfctl -t badhosts_sshd -T expire 86400 >/dev/null 2>&1
*/15    *       *       *       *       root    /sbin/pfctl -t badhosts_http -T show > /etc/pf.badhosts_http && /sbin/pfctl -t badhosts_http -T expire 86400 >/dev/null 2>&1
*/15    *       *       *       *       root    /sbin/pfctl -t badhosts_smtp -T show > /etc/pf.badhosts_smtp && /sbin/pfctl -t badhosts_smtp -T expire 86400 >/dev/null 2>&1
*/15    *       *       *       *       root    /sbin/pfctl -t badhosts_imap -T show > /etc/pf.badhosts_imap && /sbin/pfctl -t badhosts_imap -T expire 86400 >/dev/null 2>&1

Gruss,
Joe User

[daemotron]

Ich bin in diesem Forum gelandet um mich eben ein bisschen über eine Firewall schlau zu machen. Das einzige was ich gelesen habe ist das eine Firewall Blödsinn ist, mann sich eine HWF zulegen soll, etc. etc.

1. Ist eine HWF verdammt teuer
2. Was ist an einem Packetfilter AUF dem System den so schlecht.

Gegen einen Paketfilter auf dem System spricht nichts, solange man ihn für Aufgaben einsetzt, für die ein Paketfilter auf dem System auch tatsächlich geeignet ist. Dazu gehören für mich Dinge wie

• Redirect und NAT Regeln für Jails (oder vergleichbare Virtualisierungstechniken)
• "Notwehr-Konfigurationen", um bestimmte Dienste auch über IPv6 anbieten zu können, die selbst nur IPv4-fähig sind
• Kompensation von Unzulänglichkeiten in der Konfigurierbarkeit bestimmter Dienste (z. B. wenn Binden an ein bestimmtes Interface nicht unterstützt wird o. ä.)

Gerade ICMP ist für letzteres ein schönes Beispiel; allerdings wäre es natürlich sinnvoller, böte die Systemkonfiguration (z. B. per sysclt) die Möglichkeit festzulegen, welche Messages verarbeitet werden und welche nicht.

Overload-Regeln hingegen sehe ich eher kritisch - ja, kann man machen, man muss aber bedenken, dass solche Konfigurationen auch für einen gezielten DoS-Angriff genutzt werden können (Stichwort IP Spoofing). Ganz wichtig daher, dass diese Tabellen regelmäßig wieder expired werden.

Ich habe gelesen, Firewall hin oder her, die Firewall muss die Packets ja trotzdem filtern. Ist ansich richtig, aber im Falle eines dos / ddos kann die Firewall ja praktisch so konfiguriert werden das sie sieht, aha von dieser IP kommen Packets, zu schnell, zu groß und zuviele, zack wird die IP nullgerouted und kann dem entsprechend auch keine connection mehr zum Server aufbauen. Zack dos geblockt, bei einem ddos wäre das ganze natürlich schwieriger aber ich denke kleine botnets mit 500 bots +/- wären damit auch kein Problem. Was wäre denn nun nutzlos an eben so einem Packetfilter?

Ein Paketfilter bietet in so einem Szenario Untersetzung, mehr nicht - Filtern auf Layer 3 ist deutlich billiger als die Request-Verarbeitung auf Layer 7. Es spricht nichts dagegen, den Filter gezielt einzusetzen, um z. B. bei einer hereinschwappenden Spamwelle aus einem bestimmten Subnetz den Mailserver zu entlasten, indem man die Bandbreite für dieses Netz gezielt reduziert oder gar vorübergehend keine eingehenden Verbindungen zulässt. Eine solche Entscheidung sollte aber immer vom Admin getroffen werden; automatisierte Lösungen (à la Fail2Ban, aber auch komplexere IDS/IPS Lösungen) hingegen sind i.d.R. einfach zu anfällig gegen einen gezielten Angriff.