Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- it-wiki:netzwerk:iptables [2014/09/02 07:43] – marko
+++ it-wiki:netzwerk:iptables [2014/09/02 10:51] (aktuell) – marko
@@ Zeile 10: / Zeile 10: @@
 ==== Funktionsweise - Chains/Ketten ====
 Egal, ob ein Paket vom eigenen Rechner ins Netzwerk geschickt werden soll, oder von außerhalb zum Rechner gelangt, oder aber der Rechner das Paket an der einen Stelle annehmen und einfach zur nächsten weiterleiten soll, so durchläuft dieses Paket bei iptables immer mindestens eine Chain (dt. Kette"). Davon gibt es fünf vordefinierte, wobei nicht jede Tabelle wirklich alle Chains verwendet:
-   * INPUT - Der Name der Kette zeigt auch schon die Funtkionsweise auf: Ein Paket wird lokal zugestellt.
+  * INPUT - Der Name der Kette zeigt auch schon die Funtkionsweise auf: Ein Paket wird lokal zugestellt.
-   * OUTPUT - Ein Paket, welches vom eigenen Rechner erzeugt wurde und weggeschickt werden soll, wird mindestens diese Chain durchlaufen.
+  * OUTPUT - Ein Paket, welches vom eigenen Rechner erzeugt wurde und weggeschickt werden soll, wird mindestens diese Chain durchlaufen.
-   * FORWARD - Diese Kette dient allen Paketen, welche geroutet aber nicht lokal zugestellt werden.
+  * FORWARD - Diese Kette dient allen Paketen, welche geroutet aber nicht lokal zugestellt werden.
-   * PREROUTING - Pakete durchlaufen diese Chain, noch vor dem Routing.
+  * PREROUTING - Pakete durchlaufen diese Chain, noch vor dem Routing.
-   * POSTROUTING - Pakete durchlaufen diese Kette, nachdem sie geroutet wurden, aber noch bevor sie weitergeleitet werden.
+  * POSTROUTING - Pakete durchlaufen diese Kette, nachdem sie geroutet wurden, aber noch bevor sie weitergeleitet werden.
 {{Iptables1.png}}
-\\ ==== Funktionsweise - Policy ====
+\\
+ ==== Funktionsweise - Policy ====
 Mithilfe von iptables kann man sehr fein definieren, was mit einzelnen Paketen, welche die unterschiedlichen Ketten durchlaufen, passieren soll. So durchläuft ein Paket nacheinander alle Regeln der Kette, bis eine passende gefunden ist.
@@ Zeile 130: / Zeile 131: @@
 |INVALID|Pakete, welche nicht identifiziert werden können.|
+\\ ====  Protokollierung ====
+Nachdem nun die ersten Schritte mit "iptables" beschrieben wurden, widmet dieser Abschnitt sich einem der wichtigsten, wenn nicht sogar dem wichtigsten Thema: Logging.
+Es ist möglich, ebenfalls mittels "Regeln", auch wieder sehr fein eingestellt, alles mögliche mitzuprotokollieren. Dazu gibt ein Ziel: LOG.
+Es werde ausgehenden DNS-Anfragen protokolliert:
+<code># iptables -A OUTPUT -p udp --dport 53 -j LOG
+#iptables -A OUTPUT -p udp --dport 53 -j ACCEPT</code>
+Normalerweise durchläuft ein Paket die Tabelle nicht mehr, sobald DROP, ACCEPT oder REJECT über das Schicksal des Paketes entscheiden. Bei LOG wird das Paket allerdings nur "geloggt", muss aber dann die Kette weiterdurchlaufen. Daher sollte man darauf achten, dass man ein LOG macht, bevor mal ein Paket verwirft, wenn weitere Regeln würden nicht erfolgen!
+Man kann hinter -j LOG noch einige weitere Optionen dranhängen, welche das Log-Verhalten beeinflussen:
+^Optionen/Präfix^Beschreibung^
+|--log-level <Level>|Passt die Priorität der Meldung(en) an. Damit ist es sogar möglich, über Konfiguration von /etc/syslog.conf in unterschiedliche Dateien zu protokollieren.|
+|--log-uid|Protokolliert bei einem lokal erzeugten Paket (also ein Paket, welches die OUTPUT-Kette passiert) die UID des Benutzers mit, welcher das Paket erzeugt hat.|
+|--log-tcp-sequence|Protokolliert die Sequenznummern der einzelnen TCP-Verbindungen mit.|
+|--log-tcp-options|Protokolliert mögliche Optionen des TCP-Headers mit.|
+|--log-ip-options|Protokolliert mögliche Optionen des IP-Headers mit.|
+|--log-prefix <prefix>|Fügt einen String jedem Log-Eintrag hinzu, welcher diesem vorangestellt wird. Dadurch wird eine bessere Lesbarkeit möglich, außerdem lassen sich so leichter bestimmte Protokollgruppen rausfiltern (z.B. mittels grep)|
+Von den Log-Leveln gibt es 7 Stück:
+^Level^Bedeutung^
+|1|alert|
+|2|critical|
+|3|error|
+|4|warning|
+|5|notice|
+|6|info|
+|7|debug|
+Eine solche Log-Ausgabe sieht im ersten Moment etwas kryptisch aus, enthält auf den zweiten Blick allerdings alle notwendigen Informationen:
+<code># Nov  8 16:54:04 Uranus kernel: [15061.388110] IN= OUT=wlan0 SRC=192.168.178.23 DST=192.168.178.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=20331 DF PROTO=UDP SPT=46779 DPT=53 LEN=40</code>
+In diesem Fall sieht man nochmal deutlich; das ausgehende UDP-Datagram auf Port 53 (und einige Zusatzinformationen), welches von der internen IP-Adresse 192.168.178.23 an das Default-Gateway gesendet wird, aber keinen Inhalt der Applikationsebene. Falls es sich um einen Log-Eintrag eines TCP-Segmentes handelt, so werden auch Window-Size, reservierte Bits im TCP-Header und Flags (z.B. SYN,ACK) mitprotokolliert.
+Was ebenfalls auffällt: "Uranus". Das ist der Name des Rechners, welcher den Log-Eintrag getätigt hat. Hierbei sei die Möglichkeit erwähnt, den BSD-Syslogd auch über das Netzwerk nutzen zu können und so einen externen Protokoll-Server anzulegen. Außerdem: Das Jahr wird nicht mitprotokolliert. Falls man dieses benötigt, so muss man dies händisch einfügen.
+Aber wo finde ich jetzt diesen Log-Eintrag? In /var/log/syslog. Aber damit sich die iptables-Logs nicht mit den anderen aus syslog mischen, sollte man diese umlenken. Dazu wird die Datei /etc/rsyslog.conf (als root) erweitert. Idealerweise, kann man an dieser Stelle dann die --log-level Option ausnutzen:
+<code>
+kern.alert                      /var/log/kern.alert.log #enthält Level 1 Logs
+kern.critical                   /var/log/kern.critical.log #enthält Level 2 Logs
+kern.error                      /var/log/kern.error.log #enthält Level 3 Logs
+kern.warning                    /var/log/kern.warning.log #enthält Level 4 Logs
+kern.notice                     /var/log/kern.notice.log #enthält Level 5 Logs
+kern.info                       /var/log/kern.info.log #enthält Level 6 Logs
+kern.debug                      /var/log/kern.debug.log #enthält Level 7 Logs
+</code>
+Hierbei sollte man allerdings beachten, dass auch alle anderen Kernel-Meldungen nach in die entsprechenden Log-Dateien geschrieben werden. Es ist sinnvoll hierfür die --log-prefix Option zu nutzen, um daraus später vernünftige Protokolle basteln zu können.
+Falls man einen anderen System-Logger als den BSD-Syslogd verwendet (z.B. syslog-ng) so müssen andere Konfigurationsdateien geändert werden, damit die Ausgaben in entsprechende Log-Files (oder wohin auch immer) geschrieben werden.
+Bei der Protokollierung sollte einem bewusst sein, dass je nach Nutzung des Netzwerks, durchaus Logfiles von >500MByte/Tag entstehen können. Hier ist also Vorsicht geboten.
+\\ ==== Type of Service ====
+Im IP-Header kann das 8Bit große Type of Service Feld manipuliert und so die Priorisierung des Paketes gesetzt werden (Quality of Service).
+Betrachte man folgendes Beispiel:
+<code># iptables -t mangle -A PREROUTING -p tcp --dport 22 -j TOS --set-tos 0x10</code>
+Hierbei werden die IP-Pakete bereits in der MANGLE-Tabelle, schon vor dem eigentlichen Routing manipuliert. Die oben beschriebene Regel trifft auf das SSH-Protokoll zu. mit --set-tos gefolgt von einem Hexadezimalwert, kann man nun den Type of Service in einem IP-Paket beeinflussen. Das bedeutet, man kann den Transport von Paketen, anderen vorziehen. Folgende Werte beeinflusst man mit --set-tos:
+^Value^Effekt^
+|0x10|Minimale Verzögerung|
+|0x08|Maximaler Durchsatz|
+|0x04|Maximale Zuverlässigkeit|
+|0x02|Minimale Kosten|
+|0x00 (default)|Normaler Service |
 \\ ===== iptables Regeln dauerhaft speichern =====