Was spricht gegen "iptables -P FORWARD DROP"?
Ich will ja nicht, dass mein Gerät IP Pakete zwischen irgendwelchen anderen Geräten routet, von denen ich nichts weiß.
Die Standardeinstellung ist aber nicht DROP, sondern ACCEPT. Warum?
4 Antworten
# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0
Typischerweise ist Forwarding eh deaktiviert und wenn Du es aktivierst, kannst Du auch die FW gleich konfigurieren.
Davon ab ist die default Policy eben ACCEPT bei allem, einfach weil so keien Intervention stattfindet, wenn nichts konfiguriert wurde.
Ich würde mal sagen, der Standardfall ist eben, dass keine "Firewall" aktiv ist. Also erst mal von einem vertrauenswürdigen Netz ausgegangen wird.
Die Standardeinstellung von allen iptables-Policies ist ACCEPT. Das auf DROP umzustellen ist immer sinnvoll. Selbst wenn du die Funktion benutzt, dann richtet man eben spezifische Regeln für den erlaubten Verkehr ein.
Wenn du kein forwarding / routing machst, kannst du das Problemlos umstellen.
Ich habe auch bei INPUT und OUTPUT als Policy DROP, aber mit entsprechenden Regeln für den erlaubten Verkehr davor.
Typischerweise gibt es aber noch einen net.ipv4.ip_forward Kernel Flag, der oft default aus ist, so dass auch Accept prinzipiell kein Problem gibt.
PS: Wenn du Docker oder Virtualisierung auf der Kiste machst, brauchst du da dann ggf. Regeln für.
Das auf DROP umzustellen ist immer sinnvoll.
Naja, bei INPUT und OUTPUT finde ich ACCEPT schon sinnvoll, da ja die Dienste, die auf dem Gerät laufen, erreichbar sein sollen und man sich bei ausgehenden Paketen normalerweise nicht selbst einschränken möchte.
PS: Wenn du Docker oder Virtualisierung auf der Kiste machst, brauchst du da dann ggf. Regeln für.
Eben, darum ist IP Forwarding überhaupt aktiviert, denke ich. Aber Docker erstellt ja seine eigenen Regeln, da dürfte die Policy ziemlich egal sein.
DROP erlaubt mehr Kontrolle. für die Dienste gibt es dann eben entsprechende Regeln, die diese explizit erlauben. Ich will ja z.B. ssh nur im LAN erlauben, nicht weltweit. Bei OUTPUT kann man geteilter Meinung sein, weil es macht Arbeit, das mache ich dann auch nur bei Servern mit einer festen Aufgabe.
Hmm ja, bei Servern ergibt es Sinn. Lokal habe ich eh im Router eine Firewall, da kommt sowieso nichts rein, außer was ich erlaube.
Ein generelles DROP würde jeglichen Weiterleitungsverkehr blockieren, ohne Rücksicht auf spezifische Sicherheitsregeln. Was unweigerlich zu Problemen im Netzwerk führen dürfte.
Das ist ja nur die Policy, wenn keine Regel auf das Paket zutrifft.
Naja aber du musst davon ausgehen das der DAU sich damit eher nicht so auskennt und daher es wenig soll macht die Firewall erstmal komplett zu versiegeln
Eigentlich ist es nicht "nur" die Policy, welche greift, wenn keine andere Regel zutrifft. Das "nur" ist völlig Fehl an dem Platz, denn es ist die Policy, die IMMER dann greift, wenn wenn keine andere Regel greift. Das ist quasi der Schrottcontainer, in den jeglicher Mist hinein läuft, den du vorher nicht explizit mit einer anderen Regel behandelt hast.
Ist also durchaus möglich, dass darin auch etwas verschwindet, was du im Netzwerk brauchst, aber weil du es nicht mit einer anderen Regel explizit behandelst (und dies nicht auf dem Schirm hast!), schiesst du dir sowas dann ins Nirvana.
Sowas kann also völlig ok und angebracht sein, es kann aber genauso auch für immense Probleme sorgen, wenn man nicht daran denkt, dass diese Policy aktiv ist.
Üblicherweise lässt man jeglichen Traffic erst einmal zu und blockt dann gezielt das, was man absolut nicht haben will.
Du willst das andersherum -> erst einmal alles blocken und dann gezielt wieder erlauben. Musst du entscheiden, welcher Weg auf Dauer in deinem Anwendungsfall pflegeleichter ist.
Es geht hier um die Forward Chain, die wird auf einem normalen PC oder Server nicht benötigt, lediglich, wenn der Rechner als Router oder Firewall fungiert. Daher schadet ein Drop als Default Policy nicht.
Abgesehen davon, dass es eh keine Auswirkungen hat, solange man nicht explizit das ip Forwarding im Kernel mittels
sysctl net.ipv4.ip_forward=1
aktiviert hat.
Und ja, mit der Policy legt man fest, ob man in der jeweiligen Chain Black- oder Whitelisting haben möchte. Das muss jeder selbst entscheiden, was für den jeweiligen Anwendungsfall sinnvoller ist.
Für Docker, Podman oder LXC braucht man IP Forwarding, wenn die Container Zugriff auf das Netzwerk haben sollen.