bugblatterbeast
Anmeldungsdatum: 30. Januar 2008
Beiträge: 455
|
Hallo, ich habe eine nicht allzu komplizierte Frage. Ich bin leider etwas in Zeitdruck und hoffe, dass jemand von Euch ein vergleichbares Problem schon gelöst hat und mir kurz helfen kann. Auf einem Server melden sich Nutzer mit OpenVPN an und bekommen alle eine Adresse aus dem gleichen Netzwerk zugewiesen (z.B. 10.0.10.*) Auf dem gleichen Server läuft auch der Dienst Samba und die VPN-Benutzer sollen nur auf diesen Dienst und sonst auf nichts anderes zugreifen können. Meine erste Idee war das so zu realisieren:
| iptables -A INPUT -s 10.0.10.0/24 -p udp --dport 137 -j ACCEPT
iptables -A INPUT -s 10.0.10.0/24 -p udp --dport 138 -j ACCEPT
iptables -A INPUT -s 10.0.10.0/24 -p tcp --dport 139 -j ACCEPT
iptables -A INPUT -s 10.0.10.0/24 -p tcp --dport 445 -j ACCEPT
iptables -A INPUT -s 10.0.10.0/24 -j DROP
|
Mein Problem ist aber, dass ich bei iptables immer unsicher bin, ob ich die richtige Reihenfolge eingehalten habe und ob sie wirklich persistent sind und nicht beim nächsten Neustart verschwinden. Ich benutze nicht gerne Lösungen, bei denen ich mir nicht absolut sicher bin. Allerdings fällt mir gerade nichts naheliegenderes als iptables ein. Hat jemand von Euch eine gute Idee? Gruß
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
Vergiss nicht Pakete mit dem Status ESTABLISHED und RELATED mit zu erlauben. Für das persistente Speichern eignet sich iptables-save.
|
bugblatterbeast
(Themenstarter)
Anmeldungsdatum: 30. Januar 2008
Beiträge: 455
|
Hallo misterunknown, vielen Dank schon mal. Lädt iptables-save die gespeicherten Einstellungen automatisch beim nächsten Systemstart? Ich hätte jetzt nicht gedacht, dass established und releated noch extra behandelt werden müssen. | iptables -A INPUT -s 10.0.10.0/24 -p udp --dport 137 -j ACCEPT
iptables -A INPUT -s 10.0.10.0/24 -p udp --dport 138 -j ACCEPT
iptables -A INPUT -s 10.0.10.0/24 -p tcp --dport 139 -j ACCEPT
iptables -A INPUT -s 10.0.10.0/24 -p tcp --dport 445 -j ACCEPT
iptables -A INPUT -s 10.0.10.0/24 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -s 10.0.10.0/24 -j DROP
|
|
bugblatterbeast
(Themenstarter)
Anmeldungsdatum: 30. Januar 2008
Beiträge: 455
|
Lädt iptables-save die gespeicherten Einstellungen automatisch beim nächsten Systemstart?
Schon gefunden, es muss anscheinend noch iptables-persistant installiert werden, was dafür sorgt, dass die gespeicherten iptables automatisch beim nächsten Start geladen werden.
|
bugblatterbeast
(Themenstarter)
Anmeldungsdatum: 30. Januar 2008
Beiträge: 455
|
OK, ich habe das ganze jetzt mal auf einem Test-Server ausprobiert und bin zufrieden mit den Ergebnissen. Ich habe mich mit iptables bisher nicht so richtig wohl gefühlt, glaube aber jetzt etwas gelernt zu haben. So wie ich das sehe, muss die DROP-Regel (in diesem Fall) ganz unten in der Liste stehen, damit die erlaubten Ausnahmen funktionieren. Wenn ich also die iptables schon (wie im Code-Beispiel oben) gesetzt habe und auf einmal merke, dass ich http auch erlauben will, dann funktioniert es nicht, wenn ich eine neue Regel dafür mit -A (append) eingebe, weil sie dann unter die DROP-Regel geschrieben wird. In dem Fall muss ich die zusätzliche Erlaubnis für den http-Port mit -I (insert) eingeben, damit sie über die DROP-Regel geschrieben wird. Das haben meine Tests eben ergeben und erscheint soweit schlüssig.
|
bugblatterbeast
(Themenstarter)
Anmeldungsdatum: 30. Januar 2008
Beiträge: 455
|
Was mir wieder einmal auffällt ist, dass es bei iptables anscheinend sehr leicht ist aus mangelnder Erfahrung sehr fatale Fehler zu machen. Würde jetzt zum Beispiel jemand auf die Idee kommen, ein auftretendes Problem auf die grobe Art zu lösen und mangels besseren Wissens folgenden Befehl eingeben:
| iptables -I INPUT -j ACCEPT
|
Dann ist es für denjenigen nicht unbedingt offensichtlich, dass er damit alle Sicherheitsregeln außer Kraft gesetzt hat. - Ich halte das jetzt nicht für ein konzeptionelles Problem. Ich befürworte die UNIX/Linux Haltung "Du kannst machen was Du willst aber Du solltest besser wissen was Du tust". Ich finde es an dieser Stelle nur besonders erwähnenswert.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13896
|
bugblatterbeast schrieb: Was mir wieder einmal auffällt ist, dass es bei iptables anscheinend sehr leicht ist aus mangelnder Erfahrung sehr fatale Fehler zu machen.
Ja, ich stimme dir zu.
Deshalb benutze ich mit iptables, nie "-A" und auch nie "-I" _ohne_ "rule number". Das hat zur Folge, dass man sich mit "-I" und der "rule number", im Vorfeld schon Gedanken machen muss, an welcher Stelle in der chain die iptables-Regel gesetzt bzw. berücksichtigt werden muss.
|
bugblatterbeast
(Themenstarter)
Anmeldungsdatum: 30. Januar 2008
Beiträge: 455
|
Deshalb benutze ich mit iptables, nie "-A" und auch nie "-I" _ohne_ "rule number".
Was ist, wenn man z.B. auf einem laufenden Internet-Server mit fail2ban arbeitet? Da kann die Liste ja zum Teil sehr lang werden. Gibt es eine Option für iptables -L, damit für jede Zeile die rulenum mit ausgegeben wird?
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13896
|
bugblatterbeast schrieb: Was ist, wenn man z.B. auf einem laufenden Internet-Server mit fail2ban arbeitet? Da kann die Liste ja zum Teil sehr lang werden. Gibt es eine Option für iptables -L, damit für jede Zeile die rulenum mit ausgegeben wird?
fail2ban habe ich nie benutzt und werde ich auch nicht benutzen. Die rulenum kannst Du mit z. B.:
sudo iptables -nvx -L --line-numbers
bekommen.
|
TomLu
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
bugblatterbeast schrieb: Ich hätte jetzt nicht gedacht, dass established und releated noch extra behandelt werden müssen.
Muss es auch nicht, das hebelt jetzt nur den Drop für diese besonderen VPN-Clients für alle anderen Dienste aus. Das heisst, Du hast denen damit eine General-Erlaubnis erteilt.
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
bugblatterbeast schrieb: So wie ich das sehe, muss die DROP-Regel (in diesem Fall) ganz unten in der Liste stehen, damit die erlaubten Ausnahmen funktionieren.
Alternativ kann man die Policy der Chain auf "DROP" setzen:
iptables -P INPUT DROP
Damit sollte man aber sehr vorsichtig sein, vor allem, wenn man keinen physischen Zugriff auf den Server hat. bugblatterbeast schrieb: Ich halte das jetzt nicht für ein konzeptionelles Problem. Ich befürworte die UNIX/Linux Haltung "Du kannst machen was Du willst aber Du solltest besser wissen was Du tust". Ich finde es an dieser Stelle nur besonders erwähnenswert.
Man kann auch "einfachere" Wrapper, wie beispielsweise ufw nutzen. Dennoch ist es sinnvoll zu wissen, wie iptables und das Netfilter-Frwamework funktioniert. bugblatterbeast schrieb: Was ist, wenn man z.B. auf einem laufenden Internet-Server mit fail2ban arbeitet?
Ja, das ist so. Wenn man sich die Regeln im "iptables-save"-Format ausgeben lässt, kann man fail2ban rausgreppen:
iptables -vS | grep -v f2b-sshd
Ist dann halt nicht mehr so übersichtlich.
|
bugblatterbeast
(Themenstarter)
Anmeldungsdatum: 30. Januar 2008
Beiträge: 455
|
Danke noch mal für die vielen Beiträge.
Muss es auch nicht, das hebelt jetzt nur den Drop für diese besonderen VPN-Clients für alle anderen Dienste aus. Das heisst, Du hast denen damit eine General-Erlaubnis erteilt.
Ich weiß nicht, ob ich die Aussage richtig verstanden habe. Auf meinem Testsystem habe ich beides probiert, mit und ohne der Zeile
| iptables -A INPUT -s 10.0.10.0/24 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
|
Da ich keinen Unterschied feststellen konnte (Samba funktioniert in beiden Fällen und ssh funktioniert in beiden fällen nicht) habe ich beim Live-System auf diese Zeile verzichtet. -
Alternativ kann man die Policy der Chain auf "DROP" setzen
Ich fürchte dass das keine Option für mich ist, weil eine Policy (wenn ich das richtig verstanden habe) keine IP-Range haben darf. Benutzer im Lokalen Netzwerk und Benutzer eins zweiten Administrativen VPN-Zugangs sollen per ssh auf den Server zugreifen können. iptables -vS sieht sehr vielversprechend aus, danke.
|
TomLu
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
bugblatterbeast schrieb: Auf dem gleichen Server läuft auch der Dienst Samba und die VPN-Benutzer sollen nur auf diesen Dienst und sonst auf nichts anderes zugreifen können.
Die Established-Regel hat keinen Einfluss auf die Samba-Regeln, aber Du hast damit das -siehe oberhalb- ausgehebelt.
|
bugblatterbeast
(Themenstarter)
Anmeldungsdatum: 30. Januar 2008
Beiträge: 455
|
Du hast damit das -siehe oberhalb- ausgehebelt.
Das kann ich anhand der (möglicher Weise nicht ausreichenden) Beobachtungen auf meinem Test-System nicht bestätigen. Die Dienste die ich ausprobiert habe waren wie gewünscht blockiert. Meine Vermutung war, dass diese Regel dann sinnvoll sein könnte, wenn sich auch im VPN-Netz Samba-Server befinden. Also wenn vom VPN-Server aus eine Samba-Anforderung an einen der Computer im VPN-Netz gestellt wird. Mir fiel keine andere Situation ein, in der RELATED oder ESTABLISHED Verbindungen entstehen könnten.
|
TomLu
Anmeldungsdatum: 23. August 2014
Beiträge: 603
|
bugblatterbeast schrieb: Das kann ich anhand der (möglicher Weise nicht ausreichenden) Beobachtungen auf meinem Test-System nicht bestätigen. Die Dienste die ich ausprobiert habe waren wie gewünscht blockiert.
Dann hast Du falsch getestet.... ☺ ... eine SADDR, die die Input-Chain passiert hat, gilt dann als established, wenn sie das erste Mal auch die Postrouting-Chain untouched passiert hat. Und genau das passiert, wenn einer Deiner VPN-Clients auf Samba zugreift und eine der vorhandenen Port-Regeln das mit ACCEPT erlaubt.... ab dann ist die SADDR aber established und der DROP würde nicht mehr greifen, fall dieser Client nun im Anschluß z.B. auf Port 22 oder wasweissich zugreifen würde... wo auch immer da ein Dienst lauscht. bugblatterbeast schrieb: Meine Vermutung war, dass diese Regel dann sinnvoll sein könnte, wenn sich auch im VPN-Netz Samba-Server befinden.
Die Regel wäre dann sinnvoll, wenn sie andere lokale Clients berücksichtigt, die nicht aus dem VPN kommen.
|