Im Katalog suchen

Linux - Wegweiser für Netzwerker

Online-Version

Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG

Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.


vorheriges Kapitel Inhaltsverzeichnis Stichwortverzeichnis nächstes Kapitel



IP-Accounting konfigurieren

Da IP-Accounting eng mit IP-Firewall zusammenhängt, kann man in beiden Fällen dieselben Tools verwenden, also ipfwadm, ipchains oder iptables. Die Befehlssyntax bei IP-Accounting ist der Syntax der Firewall-Regeln sehr ähnlich. Wir gehen daher nicht noch mal detailliert darauf ein, zeigen Ihnen aber, wie Sie damit tieferen Einblick in die Dynamik Ihres Netzwerkverkehrs bekommen.

Die allgemeine Syntax für IP-Accounting mit ipfwadm ist:

# ipfwadm -A [Richtung] [Befehl] [Parameter]

Das Richtungsargument ist neu. Es kann einen der folgenden Werte haben: in, out oder both codiert. Diese Richtungen sind aus der Perspektive der Linux-Maschine selbst zu sehen. in bezeichnet Daten, die über eine Netzwerkverbindung in die Maschine hineinfließen, out meint Daten, die von diesem Host über eine Netzwerkverbindung übertragen werden. Mit both sind beide Richtungen gemeint.

Die allgemeine Befehlssyntax für ipchains und iptables ist:

# ipchains -A Chain Regelspezifikation # iptables -A Chain Regelspezifikation

Die Befehle ipchains und iptables ermöglichen es Ihnen, die Richtungen auf eine etwas konsistentere Weise als bei den Firewall-Regeln anzugeben. IP Firewall Chains gestattet es Ihnen nicht, Regeln anzugeben, die beide Richtungen betreffen. Sie können aber Regeln für die forward-Chain angeben, was bei der älteren Implementierung nicht möglich war. Die Unterschiede werden wir später noch in einigen Beispielen sehen.

Die Befehle sind fast dieselben wie bei den Firewall-Regeln, mit der Ausnahme, daß die Aktionsregeln hier nicht wirksam werden. Wir können Accounting-Regeln hinzufügen, einfügen, löschen und auflisten. Bei ipchains und iptables sind alle zulässigen Regeln Accounting-Regeln. Jeder Befehl, bei dem die Option -j nicht angegeben ist, führt ausschließlich Accounting durch.

Die Regelspezifikations-Parameter für IP-Accounting sind dieselben wie diejenigen für IP-Firewall. Wir benutzen sie, um genau zu definieren, welchen Netzwerkverkehr wir abrechnen und aufsummieren wollen.

Accounting anhand von Adressen

Nun zeigen wir anhand eines konkreten Beispiels, wie wir IP-Accounting anwenden können.

Stellen Sie sich vor, wir hätten einen Linux-basierten Router, der zwei Abteilungen in der virtuellen Brauerei bedient. Der Router hat zwei Ethernet-Geräte, nämlich eth0 und eth1, die jeweils eine Abteilung bedienen, sowie eine PPP-Schnittstelle an ppp0, die uns über eine serielle Hochgeschwindigkeitsleitung mit dem Haupt-Campus der Groucho-Marx-Universität verbindet.

Stellen wir uns außerdem vor, daß wir zur Kostenberechnung den Umfang des Datenverkehrs wissen wollen, der von den beiden Abteilungen über die seriellen Leitungen übertragen wird. Für Verwaltungszwecke wollen wir außerdem wissen, wie viele Daten zwischen den beiden Abteilungen hin- und herwandern.

Die folgende Tabelle zeigt die Adressen der Schnittstellen, die wir in unserem Beispiel benutzen:

Schnittstelle Adresse Netzmaske
eth0 172.16.3.0 255.255.255.0
eth1 172.16.4.0 255.255.255.0

Wie viele Daten überträgt jede Abteilung über die PPP-Verbindung? Um diese Frage zu beantworten, könnten wir etwa folgende Regel benutzen:

# ipfwadm -A both -a -W ppp0 -S 172.16.3.0/24 -b # ipfwadm -A both -a -W ppp0 -S 172.16.4.0/24 -b
oder:
# ipchains -A input -i ppp0 -d 172.16.3.0/24 # ipchains -A output -i ppp0 -s 172.16.3.0/24 # ipchains -A input -i ppp0 -d 172.16.4.0/24 # ipchains -A output -i ppp0 -s 172.16.4.0/24
und mit iptables:
# iptables -A FORWARD -i ppp0 -d 172.16.3.0/24 # iptables -A FORWARD -o ppp0 -s 172.16.3.0/24 # iptables -A FORWARD -i ppp0 -d 172.16.4.0/24 # iptables -A FORWARD -o ppp0 -s 172.16.4.0/24

Die erste Hälfte jeder dieser Regelsätze besagt: “Zähle alle Daten in beiden Richtungen über die Schnittstelle namens ppp0 mit Quell- oder Zieladresse 172.16.3.0/24.” (Erinnern Sie sich an die Funktion des -b-Flags in ipfwadm.) Die andere Hälfte dieser Regelsätze macht dasselbe für das zweite Ethernet-Netzwerk auf unserer Site.

Zur Beantwortung der zweiten Frage “Wie viele Daten werden zwischen den beiden Abteilungen bewegt?” benötigen wir eine Regel, die etwa so aussieht:

# ipfwadm -A both -a -S 172.16.3.0/24 -D 172.16.4.0/24 -b
oder:
# ipchains -A forward -s 172.16.3.0/24 -d 172.16.4.0/24 -b
oder:
# iptables -A FORWARD -s 172.16.3.0/24 -d 172.16.4.0/24 # iptables -A FORWARD -s 172.16.4.0/24 -d 172.16.3.0/24
Diese Regeln zählen alle Datagramme mit einer Quelladresse aus einem Netzwerk unserer Abteilungen und mit einer Zieladresse, die zum anderen Netzwerk gehört.

Accounting anhand von Service-Ports

Okay, jetzt nehmen wir mal an, wir wollten nicht nur etwas über den Umfang, sondern auch Näheres über die Art des übertragenen Datenverkehrs wissen. Wir könnten zum Beispiel wissen wollen, wieviel Leitungskapazität von FTP-, SMTP- und WWW-Diensten in Anspruch genommen wird.

Dazu könnten wir ein Skript mit Regeln zusammenstellen, etwa so:

#!/bin/sh # Erstellt eine Statistik des FTP-, SMTP- und WWW-Datenverkehrs # über unsere PPP-Verbindung mit ipfwadm # ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 ftp ftp-data ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 smtp ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 www
oder:
#!/bin/sh # Erstellt eine Statistik des FTP-, SMTP- und WWW-Datenverkehrs # über unsere PPP-Verbindung mit ipchains # ipchains -A input -i ppp0 -p tcp -s 0/0 ftp-data:ftp ipchains -A output -i ppp0 -p tcp -d 0/0 ftp-data:ftp ipchains -A input -i ppp0 -p tcp -s 0/0 smtp ipchains -A output -i ppp0 -p tcp -d 0/0 smtp ipchains -A input -i ppp0 -p tcp -s 0/0 www ipchains -A output -i ppp0 -p tcp -d 0/0 www
oder:
#!/bin/sh # Erstellt eine Statistik des FTP-, SMTP- und WWW-Datenverkehrs # über unsere PPP-Verbindung mit iptables # iptables -A FORWARD -i ppp0 -m tcp -p tcp --sport ftp-data:ftp iptables -A FORWARD -o ppp0 -m tcp -p tcp --dport ftp-data:ftp iptables -A FORWARD -i ppp0 -m tcp -p tcp --sport smtp iptables -A FORWARD -o ppp0 -m tcp -p tcp --dport smtp iptables -A FORWARD -i ppp0 -m tcp -p tcp --sport www iptables -A FORWARD -o ppp0 -m tcp -p tcp --dport www

In dieser Konfiguration sind einige interessante Features enthalten. Erstens haben wir das Protokoll spezifiziert. Wenn wir in unseren Regeln Ports angeben, müssen wir auch ein Protokoll benennen, da TCP und UDP verschiedene Portmengen anbieten. Da alle diese Dienste TCP-basiert sind, haben wir es hier auch als Protokoll angegeben. Zweitens haben wir die beiden Dienste ftp und ftp-data in einer einzigen Anweisung angegeben. ipfwadm gestattet die Spezifikation einzelner Ports, von Portbereichen oder beliebigen Listen von Ports. ipchains erlaubt entweder einzelne Ports oder Portbereiche, was wir hier auch ausgenutzt haben. Die Notation ftp-data:ftp bedeutet “Ports ftp-data (20) bis ftp (21)” und ist die Art und Weise, wie wir Portbereiche sowohl in ipchains als auch iptables beschreiben. Wenn Sie in einer Accounting-Regel eine Liste von Ports angeben, bedeutet das, daß alle Daten addiert werden, die über irgendeinen dieser Ports laufen. Wir haben uns daran erinnert, daß FTP-Dienste immer zwei Ports brauchen, nämlich einen für die FTP-Befehle und einen für die Datentransfers, und daher beide Ports zusammen angegeben, um den gesamten FTP-Verkehr zu addieren. Schließlich haben wir die Quelladresse als 0/0 angegeben. Dabei handelt es sich um eine spezielle Notation, die zu allen Adressen paßt und sowohl von ipfwadm als auch von ipchains für die Spezifikation der Ports benötigt wird.

Den zweiten Punkt können wir noch etwas ausweiten, um einen etwas differenzierteren Einblick in die Daten unserer Verbindung zu bekommen. Dazu klassifizieren wir FTP-, SMTP- und WWW-Daten als essentiellen Datenverkehr und alle anderen Daten als nicht essentiell. Um nun das Verhältnis von essentiellem zu nichtessentiellem Datenverkehr zu ermitteln, geben wir etwa folgendes ein:

# ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 ftp ftp-data smtp www # ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 1:19 22:24 26:79 81:32767

Wenn Sie sich Ihre /etc/services-Datei schon mal angesehen haben, werden Sie feststellen, daß die zweite Regel alle Ports bis auf ftp, ftp-data, smtp und www abdeckt.

Wie erreichen wir das nun mit ipchains oder iptables, zumal sie jeweils nur ein Argument in ihrer Portspezifikation zulassen? Nun, wir können uns benutzerdefinierte Ketten für Accounting genauso einfach zunutze machen wie bei den Firewall-Regeln. Betrachten Sie folgende Vorgehensweise:

# ipchains -N a-essent # ipchains -N a-noness # ipchains -A a-essent -j ACCEPT # ipchains -A a-noness -j ACCEPT # ipchains -A forward -i ppp0 -p tcp -s 0/0 ftp-data:ftp -j a-essent # ipchains -A forward -i ppp0 -p tcp -s 0/0 smtp -j a-essent # ipchains -A forward -i ppp0 -p tcp -s 0/0 www -j a-essent # ipchains -A forward -j a-noness
Hier erzeugen wir zwei benutzerdefinierte Ketten, zum einen a-essent, in der wir Accounting-Daten für essentielle Dienste sammeln, und zum anderen a-noness, wo wir solche für nichtessentielle Dienste erhalten. Danach fügen wir Regeln zu unserer Weitergabe-Kette hinzu, die unsere essentiellen Dienste filtern und sie zur weiteren Verarbeitung an die a-essent-Kette weiterleiten. Dort haben wir nur eine Regel, die alle Datagramme akzeptiert und durchzählt. Die letzte Regel in unserer Weitergabe-Kette ist eine Regel, die zu unserer a-noness-Kette verzweigt, wo wir wiederum nur eine Regel haben, die alle Datagramme akzeptiert und durchzählt. Die Regel, die zur a-noness-Kette verzweigt, kann von keinem der essentiellen Dienste erreicht werden, da sie in ihrer eigenen Kette akzeptiert wurden. Unsere Zähler für die essentiellen und nichtessentiellen Dienste sind daher in den Regeln dieser Ketten verfügbar. Diese Vorgehensweise ist nur eine Möglichkeit; es gibt auch noch andere. Dasselbe Schema würde in einer iptables-Implementierung so aussehen:
# iptables -N a-essent # iptables -N a-noness # iptables -A a-essent -j ACCEPT # iptables -A a-noness -j ACCEPT # iptables -A FORWARD -i ppp0 -m tcp -p tcp --sport ftp-data:ftp -j a-essent # iptables -A FORWARD -i ppp0 -m tcp -p tcp --sport smtp -j a-essent # iptables -A FORWARD -i ppp0 -m tcp -p tcp --sport www -j a-essent # iptables -A FORWARD -j a-noness

Das Ganze sieht ja ziemlich einfach aus. Leider taucht ein kleines, aber unvermeidliches Problem auf, wenn man versucht, Accounting nach Service-Typen durchzuführen. In einem früheren Kapitel hatten wir ja bereits darüber gesprochen, welche Rolle die MTU in TCP/IP-Netzwerken spielt. Die MTU (Maximum Transmission Unit) definiert das größte Datagramm, das von einem Netzwerkgerät übertragen wird. Wenn ein Datagramm von einem Router empfangen wird, das größer als die MTU der Schnittstelle ist, die die Übertragung fortsetzen soll, dann führt der Router einen besonderen Trick durch, nämlich eine sogenannte Fragmentierung. Dabei zerteilt der Router das große Datagramm in leichter verdauliche Häppchen, die jeweils nicht größer als die MTU der Schnittstelle sind, und überträgt diese dann. Dabei erzeugt der Router in jedem dieser kleinen Datagramme jeweils einen neuen Header, der zur Rekonstruktion des großen Datagramms am Zielort dient. Unglücklicherweise wird bei der Zerteilung die Information über den verwendeten Port nur im ersten Fragment abgespeichert, in den nachfolgenden Fragmenten ist das nicht mehr der Fall. Das bedeutet, daß das IP-Accounting fragmentierte Datagramme natürlich nicht mehr richtig zählen kann. Es kann nur das jeweils erste Fragment eines zerteilten Datagramms sowie unzerteilte Datagramme zählen. Es gibt bei ipfwadm aber einen kleinen Trick, mit dem man die zerteilten Fragmente doch zählen kann, auch wenn man in den Fragmenten keine Angaben über den verwendeten Port vorfindet. Eine frühe Version der Linux-Accounting-Software wies den Fragmenten nämlich immer die unsinnige Portnummer 0xFFFF zu, die man dann zählen konnte, zum Beispiel mit folgender Regel:

# ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 0xFFFF

Die IP-Chains-Implementierung benutzt dafür eine etwas durchdachtere Lösung, das Ergebnis bleibt aber fast dasselbe. Bei ipchains könnten wir so vorgehen:

# ipchains -A forward -i ppp0 -p tcp -f
und bei iptables:
# iptables -A FORWARD -i ppp0 -m tcp -p tcp -f

Diese Regeln geben uns zwar keine Auskunft über den Ursprungsport, aber wir sind zumindest in der Lage festzustellen, wie viele unserer Datenpakete fragmentiert sind, und können daher Angaben über deren Datenumfang machen.

Falls Ihr Linux-Rechner als einzelner Zugriffspunkt für ein Netzwerk dient, können Sie in den 2.2-Kerneln eine bestimmte Compile-Time-Option einstellen, die diese ganze Sache ganz und gar abschaltet. Wenn Sie die Option IP: always defragment aktivieren, bevor Sie Ihren Kernel kompilieren, werden alle empfangenen Datagramme vom Linux-Router erst zusammengesetzt, bevor sie dann weiter geroutet und übertragen werden. Diese Operation findet bereits statt, bevor das fertige Datagramm die Firewall- und Accounting-Software erreicht. Sie müssen sich dann nicht mehr mit IP-Fragmenten ­herumschlagen. In 2.4er Kerneln kompilieren und laden Sie dafür das netfilter-Modul forward-fragment.

Accounting von ICMP-Datagrammen

Das ICMP-Protokoll kann mit Portnummern nichts anfangen und ist daher etwas schwieriger zu handhaben, was die Sammlung von Informationen darüber betrifft. ICMP benutzt unterschiedliche Arten von Datagrammen. Viele von diesen sind “harmlos” und normal, während andere nur unter ganz bestimmten Umständen auftauchen sollten. Manche Zeitgenossen, die mit ihrer Zeit nichts anzufangen wissen, versuchen absichtlich, Netzwerkverbindungen anderer Leute zu unterbrechen, indem sie eine Unmenge von ICMP-Nachrichten erzeugen. Dieses Verfahren wird allgemein als Ping Flooding bezeichnet. IP-Accounting kann nichts gegen solche Probleme unternehmen (aber IP-Firewalling kann das!), wir können aber zumindest Regeln einführen, die uns zeigen, ob irgend jemand versucht hat, uns aus diese Weise anzugreifen.

ICMP benutzt keine Ports, wie es TCP und UDP tun, sondern ICMP-Nachrichtentypen. Wir können Regeln einführen, die ein Accounting dieser ICMP-Nachrichtentypen durchführen. Dazu geben wir im Portfeld des ipfwadm-Befehls die ICMP-Nachricht und die Typnummer an. Die ICMP-Nachrichtentypen sind in “Arten von ICMP-Datagrammen” aufgelistet, so daß Sie im Bedarfsfall hierauf zurückgreifen können.

Eine IP-Accounting-Regel zur Sammlung von Informationen über den Umfang von Ping-Daten, die zu Ihnen gesendet werden bzw. die Sie zu anderen senden, könnte wie folgt aussehen:

# ipfwadm -A both -a -P icmp -S 0/0 8 # ipfwadm -A both -a -P icmp -S 0/0 0 # ipfwadm -A both -a -P icmp -S 0/0 0xff
oder bei ipchains:
# ipchains -A forward -p icmp -s 0/0 8 # ipchains -A forward -p icmp -s 0/0 0 # ipchains -A forward -p icmp -s 0/0 -f
oder bei iptables:
# iptables -A FORWARD -m icmp -p icmp --sports echo-request # iptables -A FORWARD -m icmp -p icmp --sports echo-reply # iptables -A FORWARD -m icmp -p icmp -f
Die erste Regel sammelt Informationen über “ICMP Echo Request”-Datagramme (Ping-Anfragen), die zweite Regel über “ICMP Echo Reply”-Datagramme (Ping-Antworten). Die dritte Regel ist schließlich für ICMP-Datagrammfragmente zuständig. Dies ist ein Trick, der dem bereits für die fragmentierten TCP- und UDP-Datagramme beschriebenen ähnlich ist.

Wenn Sie in Ihren Regeln Quell- und/oder Zieladressen angeben, können Sie verfolgen, woher die Pings kommen und ob sie ihren Ursprung innerhalb oder außerhalb Ihres Netzwerks haben. Sobald Sie festgestellt haben, woher die üblen Datagramme kommen, können Sie entscheiden, ob Sie hier Firewall-Regeln einführen wollen, um solche Attacken zu vermeiden, oder ob Sie irgend etwas anderes vorziehen, wie zum Beispiel den Eigentümer des angreifenden Netzwerks anzurufen und ihn über das Problem zu informieren, oder sogar rechtliche Schritte in Erwägung ziehen.

Accounting anhand des Protokolls

Stellen wir uns nun vor, wir wollten wissen, welche Anteile TCP, UDP und ICMP am gesamten Datenverkehr in unserer Verbindung haben. Dafür würden wir etwa folgende Regeln benutzen:

# ipfwadm -A both -a -W ppp0 -P tcp -D 0/0 # ipfwadm -A both -a -W ppp0 -P udp -D 0/0 # ipfwadm -A both -a -W ppp0 -P icmp -D 0/0
oder:
# ipchains -A forward -i ppp0 -p tcp -d 0/0 # ipchains -A forward -i ppp0 -p udp -d 0/0 # ipchains -A forward -i ppp0 -p icmp -d 0/0
oder:
# iptables -A FORWARD -i ppp0 -m tcp -p tcp # iptables -A FORWARD -o ppp0 -m tcp -p tcp # iptables -A FORWARD -i ppp0 -m udp -p udp # iptables -A FORWARD -o ppp0 -m udp -p udp # iptables -A FORWARD -i ppp0 -m icmp -p icmp # iptables -A FORWARD -o ppp0 -m icmp -p icmp
Mit diesen Regeln wird der gesamte Datenverkehr über die ppp0-Verbindung analysiert und ermittelt, ob es sich dabei um TCP, UDP oder ICMP handelt. Für jedes dieser Protokolle wird der entsprechende Zähler aktualisiert. Der Befehl iptables trennt den eingehenden Datenverkehr vom ausgehenden, wie es seine Syntax erfordert.





vorheriges Kapitel Inhaltsverzeichnis Stichwortverzeichnis nächstes Kapitel


Weitere Informationen zum Linux - Wegweiser für Netzwerker

Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center


O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen
Kontakt|Über O'Reilly|Datenschutz

© 2001, O'Reilly Verlag