Iptables – Templates

Hi,

heute möchte ich einige Templates vorstellen für Iptables um Euch die arbeit etwas einfacher zu machen das richtige Konzept zu finden.

Die Templates dienen nur zur Anregung, Copy & Paste wird also nicht funktionieren.

Ich werde hier nicht 3Mio. Befehle einhacken sondern das ganze passiert im Editor eurer Wahl und es wird nur mit der IMPORT und EXPORT Funktion von IPtables gearbeitet. (iptables-save > /pfad/datei und iptables-restore < /pfad/datei)

Erstmal eine Leere Iptables konfiguration:

*mangle und *nat werde ich nicht Erklären da diese nur für NAT benötigt werden, ich werde nur mit *filter arbeiten.

Policy ist DROP mit Debian 8 wurde dies auf ACCEPT geändert mit dem ich aber nicht arbeite, ich und andere haben hier das Problem das die Logik in den regeln nicht so funktioniert wie man das erwartet, daher nimmt man einfach das was man kennt und weiß das es geht wie man es sich vorstellt.
Dazu kommt noch das wenn man etwas vergessen hat zu blocken sicher sein kann das es geblockt wird, solange keine Freigabe erteilt wurde.

Je nach Anwendungsbereich des Server machen bestimmte Konzepte Sinn und manche nicht.

Für jeden Server gibt es eine Grundregel – Man sollte immer ein Management LAN haben und diese nur zur Administration nutzen.
Das heisst für den administrativen Zugriff auf hat man immer eine Extra IP die nur  dazu genutzt wird und sonst NICHTS.

  • Das Einfache Konzept

Erklärung:

  • Erlaubt wird der Zugriff via SSH auf die IP 1.2.3.4 (Management IP)
  • Erlaubt wird der Zugriff auf den Webserver sowie DNS Server für die IP 5.6.7.8 (Public IP)
  • RELATED und ESTABLISHED erlauft den Zugriff auf das System, NEW wird durch RELATED erfüllt und kann daher weg gelassen werden
  • Prüfung der TCP FLAGS
  • STATUS Überprüfung
  • Loggen von gedropten Paketen in SYSLOG
  • DROP alle andere Pakete werden gedropt (verworfen)
  • In OUTPUT wird nur akzeptiert da dies für ein  System ist welches im Internet hängt und es zuviel Aufwand wäre für jede Gegebenheit eine Freigabe zu Konfigurieren.

  • Custom Chains

Erklärung:

  • Jeder Traffic der an die IP 1.2.3.4 (Management IP) geht wird in die Chain MANAGEMENT geleitet, sonst nichts.
  • In der Chain MANAGEMENT erlauben wir den Zugriff auf den Port 22 (SSH) alles andere wird gedropt (Verworfen)
  • Alle Daten Pakete die an die IP 5.6.7.8 gesendet werden gehen in die Chain WEB, sonst nichts.
  • Genauso wie vorher erlauben wir in der Chain WEB den Zugriff auf den Webserver und DNS.
  • Alles andere wird danach gedropt (verworfen)
  • Optional kann man noch mehr in der Chain WEB freigeben wie E-Mail, FTP und Co, aber dafür erstelle ich nochmal ein separates Template.

  • Lokaler Server

Erklärung:

  • Dieser Server hat keinen Internet Zugriff.
  • Daten Pakete vom Interface ETH0 von dem Source-Netzwerk 10.0.0.0/20 an die Lokale IP 1.2.3.4 gehen in die Chain MANAGEMENT.
  • Über das Interface ETH1 von der Source IP 192.168.1.1 an die Lokale IP 5.6.7.8 gehen in die Chain SERVER2
  • Traffic vom Interface ETH2 von der Source IP 172.52.2.5 an die Lokale IP 192.168.178.1 geht in die Chain SERVER3
  • In der Chain MANAGEMENT wird nur SSH (Port 22) erlaubt alles andere wird gedropt.
  • In der Chain SERVER2 werden nur anfragen auf den Webserver und DNS erlaubt.
  • In der Chain SERVER3 erlauben wir nur anfragen für den E-Mail Server
  • Über die OUTPUT Chain stellen wir sicher das nur Pakete vom richtigen Interface sowie Lokaler IP an den Entsprechenden Server/Client zurück gegeben werden und somit keinerlei Kommunikation zu einer anderen Host IP möglich ist. Würde man dies nicht machen besteht die Möglichkeit das Daten Pakete auch an eine andere IP gehen, was aber hiermit ausgeschlossen ist.
  • Es würde auch die Möglichkeit bestehen in der OUTPUT Chain Custom chains zu erstellen um dies noch weiter zu filtern.

  • Hosting Server ohne Panel

Erklärung:

  • Daten Pakete vom Source Netzwerk 10.0.0.0/20 auf die Lokale IP 1.2.3.4 gehen in die Chain MANAGEMENT.
  • Traffic zur IP 5.6.7.8 auf die Ports 53,80,443 gehen in die Chain WEB.
  • Traffic zur IP 5.6.7.8 auf die Ports 20,21,1024-65000 gehen auf die Chain FTP.
  • Und Traffic zur IP 5.6.7.8 auf die Ports 25,110,143,465,587,993,995 gehen auf die Chain EMAIL.
  • Wie zu vor erlauben wir in der Chain MANAGEMENT den Zugriff auf den Port 22 (SSH).
  • In der Chain WEB erlauben wir den Zugriff auf den Webserver sowie DNS.
  • Die Chain FTP ist etwas Speziell da wir hier auch die Dynamischen Ports angeben, da wir diese für den Passiv Modus benötigen. Bei einem FTP ist es so das die Anbindung und die Anmeldung über die Ports 20 und 21 gehen, aber die Daten laufen im Passiv Modus über Dynamisch Ports daher müssen die mit angegeben werden. Aber die Dynamischen Ports werden nur genutzt wenn die Verbindung neu oder schon besteht, RELADTED wollen wir hier nicht da sonst alles erlaubt wäre, was wir aber nicht wollen. In dieser gezeigten Kombination werden die Dynamischen Ports nur genutzt wenn eine FTP Verbindung besteht, sonst nicht.
  • In der Chain EMAIL sind nur die für die E-Mail Kommunikation benötigen Ports frei gegeben.
  • Bis auf die MANAGEMENT Chain haben wir am ende keinen DROP sondern ein RETURN was Iptables dazu veranlässt das  es zurück geht in die vorherigen Chain, hier INPUT.
  • In INPUT wird dann gedropt.

  • Hosting Server mit Panel, GeoIP und mehr

Erklärung:

  • Wie bei allen Templates haben wir das Management LAN separiert.
  • Danach kümmern wir um ICMP (Ping) Pakete, diese erlaufen wir nur aus einem Source Netzwerk sowie Lokalen IP die wir beide in der Chain ICMP definiert haben.
  • Pakete an unsere Public IP für den Webserver gehen in die Chain WEB
  • Danach wie vorher kommt die Chain für den FTP Server
  • Und auch der E-Mail Server wie bei Template vorher.
  • Für das Server Panel (Plesk) sämtlicher Traffic der genutzten Ports sowie die Management IP gehen in die Chain Panel. Wir nutzen auch hier die Management IP da wir mit dem Panel root rechte haben und gehört daher auch separiert.
  • Ich habe auch mal einen Teamspeak 3 Server mit eingebunden. Dieser ist nur über die Public IP erreichbar und in der Chain habe ich zudem noch definiert das der TS3 Server nur aus dem Deutschsprachigem raum erreichbar ist genauso wie der Query Port. Es gibt leider Webseiten die Abfragen machen ohne nach zu fragen, meistens ausserhalb von Deutschland.
  • Wer DrWeb nutzt benötigt die IPs damit dieser sich Updaten kann, daher eine extra Chain, dies ist aber nur ein MUSS wenn man via GeoIP Russland gesperrt hat, ohne die Sperrung geht das auch ohne eine extra Chain.
  • Zum Abschluss noch die Länder die ich aussperren will, man kann die Liste beliebig erweitern oder auch kürzen.
  • Ganz am Ende dann die Chain um das Logging zu aktivieren, man kann dies auch nur mit 2. Zeilen machen, wenn aber wie ich wissen will ob es sich um ein TCP,UDP oder ICMP paket gehandelt hat, ist die Aufteilung schöner und wenn man dann noch Graphen erstellen will hat man es mit dem „grepen“ einfacher.

Mehr zum Thema Iptables bzw. dessenGgrundlagen schaut in den Beitrag Iptables Grundlagen

Für das Thema GeoIP und wie man dies installiert schaut einfach hier.

 

Ich hoffe das Euch der Beitrag weiter geholfen hat, bei Fragen wie immer einen Kommentar hinterlassen.

Grüße
Cheech ak DocSchneidi

Tagged , , , , , , , , , , , , , , , , , , , . Bookmark the permalink.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.