[FreeBSD] PF unnütz oder doch nicht

Rund um die Sicherheit des Systems und die Applikationen
callmax
Posts: 1
Joined: 2014-02-06 21:25

[FreeBSD] PF unnütz oder doch nicht

Post by callmax » 2014-02-06 21:52

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
Moderator
Moderator
Posts: 1187
Joined: 2011-07-04 10:56

Re: [FreeBSD] PF unnütz oder doch nicht

Post by ddm3ve » 2014-02-07 11:36

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.
02:32:12 21.12.2012 und dann sind Deine Probleme alle unwichtig.

User avatar
Joe User
Project Manager
Project Manager
Posts: 11139
Joined: 2003-02-27 01:00
Location: Hamburg

Re: [FreeBSD] PF unnütz oder doch nicht

Post by Joe User » 2014-02-07 14:02

Moin,

callmax wrote: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.


callmax wrote: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
PayPal.Me/JoeUserFreeBSD Remote Installation
Wings for LifeWings for Life World Run

„If there’s more than one possible outcome of a job or task, and one
of those outcomes will result in disaster or an undesirable consequence,
then somebody will do it that way.“ -- Edward Aloysius Murphy Jr.

User avatar
daemotron
Administrator
Administrator
Posts: 2635
Joined: 2004-01-21 17:44

Re: [FreeBSD] PF unnütz oder doch nicht

Post by daemotron » 2014-03-09 08:45

callmax wrote: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.

callmax wrote: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.
“Some humans would do anything to see if it was possible to do it. If you put a large switch in some cave somewhere, with a sign on it saying 'End-of-the-World Switch. PLEASE DO NOT TOUCH', the paint wouldn't even have time to dry.” — Terry Pratchett, Thief of Time