Das iptables HowTo

(Last Updated On: 13. Mai 2015)

In diesem Guide gebe ich einen groben Überblick über die funktionsweise von IPTables. IPtables ist eine Software-Firewall-Lösung zum filtern von paketen.

IPTables ist oft auch als Netfilter bekannt. Dabei handelt es sich um zwei zusammengehörende Softwarelösungen. IPTables ist die userseitige Implementierung der Firewall, mit der Sie „firewall-Regeln“ festlegen. Diese Regeln werden dann durch Netfilter, der kernelseitigen Implementierung – interpretiert. Netfilter ist also die „tiefgreifendere“ Softwarekomponenten, die sich um die Analyse der Netzwerkpakete kümmert. Lassen Sie sich daher nicht verwirren, wenn jemand im Zusammen von IPtables-Regeln und Netfilter-Regeln spricht.

Sie können mit

iptables -L

sich erstmal alle vorhanden iptables-Regeln anschauen. Wenn der Server frisch ist, sollte es im moment noch keine Regeln geben

iptables ist eine Liste – oder auch eine Kette – von Befehlen, die nacheinander gelesen werden. Das heißt die REgeln, die ganz oben stehen, werden vor den Regeln, die weiter unten stehen, angewandt. Deswegen spricht man bie dein iptables-Regeln auch von einer iptables rule chain – einer Regelkette.

Um eine Regel zu der Regelkette hinzuzufügen, gibt man ein

iptables -A <Regel>

Zu einer Regel gehört die Angabe, ob die Regel für

  • den eingehenden Verkehr (INPUT von anderen Netzwerken bzw. dem Internet zum Rechner / server. Beispielsweise also, wenn ein Client von unserem Server einen Dienst erfragt)
  • für das weiterleiten von Verkehr (FORWARD nur sinnvoll, wenn der Rechner, auf dem iptables konfiguriert wird, ein Gateway / Router ist und dadurch Verkehr zwischen mehreren Netzen weiterleitet
  • den ausgehenden Verkehr (OUTPUT, also von unserem Server zu anderen Rechnern oder anderen Netzwerken / dem Internet. Beispielsweise also, wenn unser Server einen Dienst anfragt – etwa Updates – oder wenn der Server die Anfrage von einem Client beantwortet)

In der Regel ist es in der Praxis so, dass man nur Regeln für den INPUT-Verkehr definiert. Denn wenn es keine Anfragen von Clients an den Server über eingehenden Verkehr gibt, dann gibt es auch keine Antworten vom Server an die Clients über ausgehenden Verkehr – theoretisch. Vergibt man also Regeln für eingehenden und ausgehenden Verkehr, wäre es eigentlich doppelt gemoppelt. Und FORWARD-REgeln definiert man wie gesagt nur bie Gateways / Routern.

man kann Regeln aber nicht nur auf die Art des Verkehrs anwenden, sondern zusätzlich auch auf die Art des Verbidnungsstatus einer Verbindung. DAs geht über

iptables -A <Angabe der Verkehrsart> -m conntrack --ctstate <Verbindungsstatus1>,<Verbindungsstatus2>

Man kann also eine Regel auch auf eine oder mehrere Verbindungsstausangaben anwenden. solche Statusangaben sind beispielsweise

  • NEW – verbindung kommt grade frisch rein und wurde noch nicht analysiert
  • ESTABLISHED – verbindung hergestellt
  • RELATED – Verbindung besteht zusätzlich aufgrund einer anderen Verbindung
  • INVALID – der verkehr konnte aus irgendeinem grund nichtr richitg identifiziert werden.

Wir können Reglen auch (zusätzlich) explizit auf bestimmte protokolle anwenden. Das geht mit der Option -p <Protokollname>.

wir können aber Regeln auch auf bestimmte Ports anwenden lassen. Wer etwas Ahnung von Netzwerkverbindungen / Sockets hat, der weiß, dass es auf beiden Seiten einer verbindung immer jeweils eine IP-Adresse und einen Port gibt. Interessant für iptables sind natürlich vordergründig ports. Dabei gibt es einen Zielport – also den Port, den der Absender anfrägt, und einen quellport – also den port, von dem aus der absender anfrägt und auf dem diesen geantwortet werden kann.

Mit der option –dport gibt man den Zielport an. Es kann entweder nur ein Port angegeben werden oder eine Range im Format <start>:<ende>

Das gleiche gilt für die Option –sport, die den Quellport angibt. für einen Server ist die Option –sport in der Regel nicht interessant, da sowohl erwünschte clients als auch unerwünschte angreifer sich den Quellport in der Regel (fast) frei aussuchen können und dadurch Regeln auf Basis von Quellports sehr schwer zu realisieren sind. –sport ist in der Regel nur interessant, wenn Sie Regeln für ausgehenden Verkehr schrieben wollen, da dann der Quellport der Port des SErverdienstes ist, den ein Client von außen angefragt hat. Wie oben bereits erläutert kommt es in der Praxis aber sehr selten vor, dass sie regeln für ausgehenden Verkehr schreiben.

Eventuell hat Ihr SErver mehrere Netzwerkkarten, auf die theoretisch Netzwerkverkehr ein- und ausgehen kann. Sie können Regeln nur für spezifische Netzwerkschnittstellen schreiben. Wenn Sie Regeln für Verkehr schreiben wollen, der auf einer bestimmten Netzwerkkarte eingeht, verweneden Sie die option -i. Bei REgeln für Verkehr, der auf einer netzwerkkarte ausgeht,m verwenden sie -o. Der parameter -o hat die Besonderheit, dass Sie mit [+] Regeln für Verkehr angeben können, der auf einer beliebigen Netzwerkschnittselle ausgeht. So könnten Sie beispielsweise in Verbindung mit –sport den ausgehenden Verkehr für einen bestimmten Port auf allen netzwerkkarten grundsätzlich sperren.

Sie könnten sogar theoretisch regeln anhand von quell- oder ziel-IP-Adresse festlegen.  Die Quell-IP-Adresse geben sie an als -s <adresse>/<maske> und ie ziel-IP-Adresse als -d <adresse>/<maske>. Meistens macht es mehr sinn, die Netzwerkkarten anzugeben, auf denen die Regle angewendet werden soll, statt die darauf befindlichen IP-Adresen anzugeben. Die Optionen zur Angabe von IP-Adressen machen beispielsweise sinn, wenn Sie einen Port für Verbindung aus dem lokalen Netzwerk erlauben, aber für verbindungen aus dem Internet auf der selben Netzwerkkarte verbieten wollen, oder wenn Sie beispielsweise Anfragen auf die LAN-IP und die öffentliche internet-IP des Servers verbieten wollen, aber Anfragen auf den Loopback-Adapter 127.0.0.1 erlauen wollen.

Jetzt haben wir so ziemlich alle wichtigen Argumente, die man braucht, um eine iptables-Regel zu notieren. Was wir jetzt noch brauchen ist eine Angabe die sagt, was iptables mit einem Netzwerkpaket tun soll, wenn es eine dieser Reglen erfüllt. Das amcht man mit dem Paramter, der als letztes ganz hinten nach allen anderen Argumenten, die die Regle überhaupt erst definieren, notiert wird. -j hat folgende Optionen

  • ACCEPT – das Paket wird so, wie es ist, akzeptiert – und alle danach folgenden iptables-Regeln, die in der Regelkette weiter unten stehen würden, werden auf dieses Paket nicht mehr weiter angewandt
  • REJECT – das Paket wird verworfen und der Absender bekommt eine mitteilung, dass sein Paket verworfen wurde. Alle weiteren iptables-REgeln, die eventuell in der Regelkette weiter unten stehen würden, werden auf das paket nicht mehra negwandt
  • DROP – wir verwerfen das Paket, der Absender bekommt davon jedoch nichts mit. Weitere Regeln in der Regelkette unterhalb dieser Regel werden nicht mehr auf das Paket angewandt
  • LOG – das Paket wird in die /var/log/syslog geloggt und es werden weitere Regeln in der Regelkette von iptables, die weiter unten stehen, auf das Paket angewandt. Es steht alos noch nicht fest, ob das Paket akzeptiert oder verworfen wird.

Jetzt wo Sie wissen, was man alles mit einem Paket machen kann, nachdem es eine Regel erfüllt, wollen Sie vielleicht wissen, was es mit der Option LOG auf sich hat. Sie können bestimmte Pakete loggen lassen, um über sie informiert zu werden. Das macht beispielsweise Sinn bei besonders heiklen Paketen – wie etwa neue Logins über SSH. Das Paket wird dabei in eine Logdatei geschrieben.

Mit dem PArametr –log-prefix können Sie einen TExt angeben, der in die Logdatei geschirbeen werden soll, bevor die Beschreibung des durch iptables geloggten Paketes folgt.

Mit dem APramter –log-level können sie das syslog-Level für das Log angeben. meist ist hier 7 die richtige Wahl.

soweit, so gut. Sie wissen jetzt also, wie man iptables-Regeln schreibt. sie wissen auch, dass diese von oben nach unten (aktuell: vom ältesten zum neuesten Eintrag) abgearbeitet werden. Was ist nun, wenn Ihnen einfällt: Oh sh*t. Ich habe eine Regel, die unbedingt weiter oben – vor einer älteren Regel – stehen mus, da sie sonst von der älteren Regel überschrieben wird?

Dann müssen Sie für diese Regel erstmal identifizieren,  ob es eine Regel für INPUT, FORWARD oder OUTPUT ist, und an welcher Stelle aller INPUT/FORWARD/OUTPUT-Regeln diese Regel letztendlich stehen soll. Wenn Sie die richtige Position erfasst haben, dann geben sie statt iptables -A einfach

 iptables -I [INPUT|FORWARD|OUTPUT] <gewünschte Position der Regel>

ein.

Was sind nun sinnvolle Regeln für iptables? Dabei muss man zunächst einmal zwei gängige Szenarien unterscheiden

Szenario 1: iptables-Regeln für den Rechner, der auch die Services nach außen hostet. Sie haben einen Server, bestimmte Services anbietet, die aus dem Internet erreichbar sein sollen – beispielsweise FTP, SSH, NFS, Voice-Server, Game-Server usw. Dieser rechner hängt entweder direkt selber am Internet (über ein angeschlossenes modem) oder über einen Router, von welchem die Ports über Portweiterleitung / Port Forwarding an diesen Rechner weitergeleitet werden. Wenn dieses Szenario auf sie zutrifft, müssen Sie überwiegend Regeln für den eingehenden Verkehr, der vom Internet bzw. vom Router auf diesen Rechner eingeht, definieren

Szenario 2: iptables-Regeln für eine (router-Firewall). Sie haben einen oder mehrere server in ihrem lokalen Netzwerk, die bestimmte Services über das internet zur Verfügung stellen – beispielsweise FTP, SSH, NFS, Voice-Server usw. Während Sie direkt auf diesen Servern die Regeln definieren, die wir im Szenario 1 erklären, haben Sie vor diese Server einen selbstgebauten Router geschaltet. Dieser selbstgebaute Router könnte beispieslweise ein normaler PC mit Linux und pfSense darauf sein, der über ein Modem mit dem Intenret kommuniziert. Dieser „Router-Rechner“ dient als Firewall. Er steuert sämtlichen aus dem Internet kommenden Verkehr und leitet ihn an die Server weiter, die dafür zuständig sind – oder lehnt den Verkehr vollständig ab, wenn er unerwünscht ist. In diesem 2. Szenario müssen Sie überwiegend FORWARD-Verkehr definieren, da Sie von diesem Rechner aus Verkehr an die Server im lokalen Netzwerk weiterleiten wollen.

Regeln für Szenario 1

in der Regel kann man davon ausgehen, dass sobald eine Verbindung ESTABLISHED ist, diese auch in der Regel erwünscht und erlaubt ist. Deswegen kann man grundsätzlich ganz weit unten an die iptables die folgende Regel setzen.

Als erstes stellen wir sicher, dass alle bereits existierenden Regeln in iptables gelöscht werden

#flushing all rules
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -F
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

Dann ist es zu Konfiugrationszwecken empfehlenswert, dass wir derzeit alle bestehendne Vebrindungen erlauben

sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Diese Regel verhindert, dass wenn Sie jetzt beispielsweise in diesem moment in iptables eine Regel eingeben, die den Zugriff auf SSH blockt – sie sich selbst aus der Fernwartung werfen und nicht mehr auf Ihren Server drauf kommen – da die SSH-Verbindung im Moment ja schon steht, wenn Sie Ihren Server aus der ferne administrieren. Blöd nur, wenn Sie die Verbindung trennen, ohne die Regel zu fixen – dann hilft Ihnen diese Regel nicht mehr. Deswegen sollten Sie nach der konfiguration von iptables und vor dem Verlassen ihrer SSH-Session immer einen Test der Regeln durchführen, was ich ihnen gegen Ende dieses Beitrages zeigen werde.

Dann haben wir derzeit noch keinen Verkehr auf den loopback-Adaptern erlaubt. das ist aber wichtig, weil beispeilsweise viele Linux-SErviecs den loopback-Adapter ansprechen, um sich gegenseitig miteiannder zu unterhalten. Deswegen erlauben wir auf dem Loopback-Adapter unbegrenzten traffic

#allow unlimited traffic on loopback
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT

Während wir jetzt IPTABLES konfigurieren, lassen wir alle restlichen eingehenden Anfragen nicht zu, aber alle ausgehenden Anfragen zu, weil esj a sein könnte, dass wir beispieslwese während der konfiguration von iptables noch pakete nachinstallieren wollen usw. und so fort.

#Setting default filter policy
-P INPUT DROP
-P OUTPUT ACCEPT
-P FORWARD DROP

Wenn Sie ihren Rechner aus der Ferne warten wollen, macht es außerdem Sinn, eingehenden Traffic auf SSH zu erlauben. Wenn Sie den port von SSH nicht umgestellt haben, können Sie dies folgendermaßen bewerkstelligen

#Anfragen von SSh-cleints erlauben
sudo iptables -A INPUT -p tcp --dport ssh -j ACCEPT

Das Erlauben des eingehen einer Anfrage an den SSH-Server heißt noch lange nicht, dassa auch die notwendige Antwort des servers an den Client erlaubt ist. Deswgen erlauben wir diese explizit auch

#Antwort von SSH-Server an Client erlauben
sudo iptables -A OUTPUT -p tcp --sport ssh -j ACCEPT

Zur Erklärung: da SSH-Verbindung eigentlich nur sinnvoll über das TCP-Transportprotokoll abgewickelt werden können, macht es keinen Sinn, Traffic auf den SSH-port auch über UDP zu erlauebn. Deswegen erlauben wir mit der Option -p ausschließlich traffic, der über das Protokoll TCP eingeht.

Wenn Sie einen Webserver aufgesetzt haben, der auf den Standardports für http://- und https://-Verbindungen lauscht können Sie die beidne foglenden Regeln hinzufügen

#Anfragen von Cleints erlauben
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT
#Antworten der Server erlauben
iptables -A OUTPUT -p tcp --sport 80 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 443 -j ACCEPT

Nun wollen Sie ja nicht nur eventuell einen Webserver hosten, sondern beispielsweise Pakete und Updates eventuell von HTTP- und HTTPS-Quellen aus dem Netz herunterladen. also müssen wir auch dafür Regeln definieren

Reglen für HTTP/ HTTPS-Anfragen an fremde Server
#Anfrage stellen
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT
#Antworten der fremden Server erlauben
iptables -A INPUT -p tcp --sport 80 -j ACCEPT
iptables -A INPUT -p tcp --sport 443 -j ACCEPT

Einige werden vielleicht sagen: Ja aber einige Webserver laufen ja nicht auf Port 80 oder Port 443, sondern evtl. auf Port 81, 82, 83, 8443, 44300, 8000, 8001 usw. Ich persönlich empfehle Ihnen, für diese Ports keine permanente Regel zu definieren, da diese Fälle sehr selten auftreten und Sie in dem Fall dann einfach temporär eine Regel zu definieren, indem Sie einfach den entsprechenden iptables-Command eingeben und die Regel wieder löschen, wenn Sie sie nicht mehr brauchen. Denken Sie daran: Sie arbeiten hier an einem Server und nicht an einer Workstation. Geben Sie nur das nötigste frei!

wir haben aktuell nur Regeln erstellt, die Traffic erlauben. Wenn man nur Regeln erstellt, die Traffic erlauben, und sonst nichts, dann kann man sich die Einrichtung einer firewall sparen, da ohne Firewall eben auch jeglicher Traffic erlaubt wird.

Was Sie nämlich noch nicht kennengelernt haben, ist die Option iptables -P. diese option legt fest, was für eine Regelkette gemacht werden soll, wenn auf ein Datenpaket gar keine der eingetragenen Regeln zutrifft. So können Sie sich in oh-sh*t-Situationen, in der Sie komplett vergessen haben, Reglen für ein bestimmtes Paket festzulegen, retten, indem Sie beispieslweise iptables -P INPUT DROP angeben. Dann werden alle eingehenden Datenpakete, für die es davor keine iptables-REgel mit accept gibt, standardmäßig verworfen.

Vorsicht: Wenn Sie das selbe mit iptables -P OUTPUT DROP machen, können sie keinen Verkehr nach draußen aufbauen, den sie nicht vorher definiert haben. Das heißt keine Websiten afurufen, keine Updates runterladen, keine Pakete installieren – gar nichts. Udn wenn sie keine Regeln für die Antwort des Servers konfiguriert haben, kann Ihr Server auch nicht mehr auf Client-Anfragen auf ihre Serverdienste antworten. iptables -P OUTPUT DROP macht jedoch sinn, wenn Sie keinen physikalischen Zugang zum Rechner haben und diesen für eine gewisse Zeit offline stellen wollen – und das ausschalten der einzlenen netzwerkschnittstellen dafür zu umständlich wäre (beispielsweise weil es mehrere netzwerkschnittstellen gibt).

Iptables -P macht außerdem Sinn, wenn Sie ganz genua wissen, welchen asugehenden Verkehr Sie auf Ihrem Server erlauben wollen, und welchen nicht. Sie können also beispielsweise iptables -P OUTPUT DROP konfigurieren und dann beispielsweise das Updaten und die Paketverwaltung als Regel vorschieben, um diesen Verkehr zu erlauebn. Und wenn Sie doch mla auf einer Website surfen und etwas downloaden müssen, danan können Sie diesen Verkehr auch noch freigeben.

Im folgenden werden wir es so machen, dass wir zunächst sämtlichen OUTPUT-Verkehr zulassen. Wir werden jetzt in Zukunft auch Regeln für den ausgehenden Verkehr definieren, so dass wir nach Abschluss unserer iptables-Konfigurationjeglichen nicht definierten ausgehenden Verkehr verbieten. Das machen wir aber nicht über iptables -P, sondern wir machen das anders – das lernen Sie aber erst später kennen.

Vorerst jedcoh vergeben wir folgende Reglen:

iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP

hingegen macht es wiederum sinn, dass Sie jeglichen FORWARD-Verkehr verwerfen, sofern ihr Server nicht als Gateway/Router genutzt wird. das machen wir oben mit -P FORWARD DROP

Bei den -P regeln müssen Sie keine Reihenfolge beachten. Sie stehen quasi immer ganz unten in der iptables-Regelkette und werden immer als letztes beachtet.

Da wir jedoch später Output-Verkehr verbieten wollen, müssen wir uns jetzt schon gedanken darüber machen, welchen output-Verkehr wir letztendlihc erlauben wollen. Dazu gehört sicherlich der ausgehende Verkehr von DNS-Anfragen, sonst können Sie auf ihrem Server beispielsweise keine paketquellen mehr von archive.ubuntu.org herunterladen, weil der FQDN nciht aufgelöst werden kann

#Anfragen an fremde DNS-Server zulassen
-A OUTPUT -p tcp --dport 53 -j ACCEPT
-A OUTPUT -p udp --dport 53 -j ACCEPT
#Antwort auf unsere DNS-Anfragen zulassen
-A INPUT -p tcp --sport 53 -j ACCEPT
-A INPUT -p udp --sport 53 -j ACCEPT

Sofern Sie keinen DNS-Server selbst auf dem Server betreiben, können Sie eingehenden DNS-Verkehr verbieten (siehe unten), ansonsten erlauben Sie ihn.

#erlauben von Anfragen an eigenen DNS-Server:
#Anfrage an unseren DNS-Server erlauben
-A INPUT -p tcp --dport 53 -j ACCEPT
-A INPUT -p udp --dport 53 -j ACCEPT
#Antwort von unserem DNS-Server
-A OUTPUT -p tcp --sport 53 -j ACCEPT
-A OUTPUT -p udp --sport 53 -j ACCEPT

Jetzt erlauben wir erstmal den ausgehenden Verkehr, den Sie brauchen werden, um Pakete und Updates über Paketverwaltungen wie rpm, aptitude, apt-get usw. zu installiern

#Anfragen an FTP-quellen
-A OUTPUT -p tcp --dport 20 -j ACCEPT
-A OUTPUT -p tcp --dport 21 -j ACCEPT
-A OUTPUT -p udp --dport 20 -j ACCEPT
-A OUTPUT -p udp --dport 21 -j ACCEPT
#Antworten von FTP-Quellen
-A INPUT -p tcp --sport 20 -j ACCEPT
-A INPUT -p tcp --sport 21 -j ACCEPT
-A INPUT -p udp --sport 20 -j ACCEPT
-A INPUT -p udp --sport 21 -j ACCEPT
#auth-service für paketquellen freigeben
#Anfragen an auth-services
-A OUTPUT -p tcp --dport 113 -j ACCEPT
-A OUTPUT -p udp --dport 113 -j ACCEPT
#Antworten von auth-services
-A INPUT -p tcp --sport 113 -j ACCEPT
-A INPUT -p udp --sport 113 -j ACCEPT

sie wollen wahrscheinlich E-Mails versenden, denn im Laufe des Guides  vergeben wir einige Tipps, wie Sie sich über bestimmte Ereignisse auf Ihrem System benachrichtigen lassen können. Deswegen erlauben wir entsprechende Ports

#ausgehender SMTP-port ziel (nötig, wenn Sie über #einen fremden SMTP-SErver / SMTP Relay Server e-Mails verschicken wollen:
-A OUTPUT -p tcp --dport 25 -j ACCEPT
#ausgehender SMTP-port Quelle (nötig, wenn Sie #E-Mails über SMTP überhaupt vershcicken wollen)
-A OUTPUT -p tcp --sport 25 -j ACCEPT
#ausgehender SMTP-port Ziel (nötig, wenn User #Ihren SMTP-Server zum Versendenn nutzen können #sollen
-A INPUT -p tcp --dport 25 -j ACCEPT

Falls sie nicht nur Benachricihtungen per E-Mail verschicken, sondern auch einen Mailserver betreiben, auf dem User sich Accounts und Postfä#cher einrichten können, müssen Sie außerdem eventuell ausgehenden und eingehenden Verkehr

$IPTABLES -A INPUT -p tcp --dport 110 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 110 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 143 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 143 -j ACCEPT

Beachten Sie, dass wir hier keine Regeln für den Verkehr von Anfragen an fremde POP- und IMAP-Server festlegen – macht ja keinen sinn, da sie auf ihrem Server wohl kaum ihr googlemail-konto pflegen werden.

es ist strittig, ob Sie ausgehenden Verkehr für den Port 22 erlauben sollen, also für SSH auf fremde SSH-Server. Sie bruachen den Port, wenn Sie Dateien auf andere Server per SCP kopieren wollen (wird häufig auch für backup-skripte genutzt) oder wenn Sie die anderne Server von diesem Server aus administrieren wollen. Eventuell haben sie jedoch auf den anderen Servern auch den SSH-port auf einen anderen Port umgelegt – dann können Sie den alternativen Port freigeben.

#Anfragen an fremde SSh-Server
-A OUTPUT -p tcp --dport <SSH-port fremder Server> -j ACCEPT
#Antworten von fremden SSH-Servern
-A INPUT -p tcp --sport <SSH-Port fremder Server> -j aCCEPT

Wenn sie einen virutalsiierten Server haben und Sie Zugriff auf die VMware-Wartung des SErvers haben, wollen Sie diesen SErver evtl. über einen entsprechenden Client warten. Bei der VMWare vSphere Suite beispielsweise müssen Sie hierzu die Ports 443, 902 und 903 freigeben. 443 ist bereits frei, wenn Sie die oberen Regeln für einen Webserver eingespielt haben. sie müssen jedoch nur anfragen freigeben, keine Antworten – und können daher die OUTPUT-Regeln wieder löschen.

#Anfragen auf den vSphere Server zum Verwlaten
-A INPUT -p tcp --dport 902 -j ACCEPT
#Antworten des vSphere Servers an den Vsphere Client
-A OUTPUT -p udp --sport 902 -j ACCEPT
#Anfragen Teil 2
-A INPUT -p tcp --dport 903 -j ACCEPT

Wenn Sie einen Sambashare freigeben wollen, müssen Sie folgendermaßen feststellen, welche ports von samba genutzt werden.

# netstat -tulpn | egrep „samba|smbd|nmbd|winbind“

normalerweise lauten die Anforderungen zum Freigeben der verbidnungen dann so:

#Anfragen an densamba server
-A INPUT -p tcp --dport 445 -j ACCEPT
-A INput -p tcp --dport 139 -j ACCEPT
#Antworten des samba servers
-A Output -p tcp --sport 445 -j ACCEPt
-A INPUT -p tcp --sport 139 -j ACCEPT
#anfragen an den nmbd
-A INPUT -p udp --dport 137 -j ACCEPt
-A INPUT -p udp --dport 138 -j ACCEPT
#Antwiorten
-A OUTPUT -p udp --sport 137 -j ACCEPT
-A OUTPUT -p udp --sport 138 -j ACCEPT

Beachten Sie oben, dass der eingehende Verkehr mit TCp, der ausgehende mit UDP eingeleitet wird.

Wenn Sie die Zeit des Servers über einen fremden NTP-Server snychronisieren wollen oder wenn Sie manche Paketquellen nutzen wollen, müssen Sie ausgehenden NTP-Traffic erlauben

#Anfrage an fremde NTP-Server
-A OUTPUT -p udp --dport 123 -j ACCEPT
#Antwort fremder NTP-Server erlauben
-A INPUT -p udp --sport 123 -j ACCEPT
#wenn wir selber einen NTP-Server anbieten wollen
#Anfragen an unseren NTP-Server
-A INPUT -p udp --dport 123 -j ACCEPt
#Antworten von unserem NTP-Server
-A OUTPUT -p udp --sport 123 -j ACCEPT

in der folgenden Einstellung erlauben wir auschließlich ICMP Pakete, die dem pingen des SErvers dienen. Einige halten das für eine schlechte Idee.

-A INPUT -p icmp --icmp-type 8 -j ACCEPT
-A OUTPUT -p icmp --icmp-type 0 -j ACCEP

icmp-type 8 ist für echo-request, 0 für echo-reply. Daher die verschiedenen types.

Wenn Sie jegliche Art von ICMP erlauebn wollen, lauten die Zeilen

-A INPUT -p icmp -j ACCEPT
-A OUTPUT -p icmp -j ACCEPT

Hier eine kleine Sonderregelung, wenn Sie einen VPN-Server auf diesem Rechner hosten wollen, beispielsweise über L2TPD und IPSec. Dann müssen Sie folgende Regeln definieren:

#Anfragne an den VPN-Server erlauben
iptables -A INPUT -m state --state NEW -i eth0 -p udp --dport 500 -j ACCEPt
iptables -A INPUT -m state --state NEW -i eth0 -p udp --dport 4500 -j ACCEPT
#Antworten vom VPN-Server erlauben
iptables -A OUTPUT -ieth0 -p udp --sport 500 -j ACCEPt
iptables -A OUTPUT -i eth0 -p udp --sport 4500 -j ACCEPT
#IPSEC erlauben
iptables -N firewall
#jeglichen ESP-Verkehr erlauben:
iptables -A firewall -p esp -j ACCEPT
#zusätzlich jeglichen Verkehr auf Port 1701 #(L2TPD) erlauben, SOFERN er in IPSec #eingewickelt ist:
iptables -A firewall -m policy --dir in --pol ipsec -p udp --dport 1701 -j ACCEPT
#Verkehr über das PPP Interface erlauben
iptables -A firewall -i ppp+ -p all -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Mit der hier gezeigten Möglichkeit, dass Sie per iptables -N eine neue REgelkette aufmachen und dann in einer bestehenden Regelkette auf diese verweisen, sind Sie vielleicht heiß geworden und wollen nun vielleciht eine eigene Regelkette eröffnen.

Ist Ihnen dabei aufgefallen, dass wir bisher bei den Regelketten INPUT und OUTPUT nie definieren mussten, ob es sich um eingehendenden oder ausgehenden Verkehr handelt? Klar werden sie jetzt sagen, das weiß doch IPtables schon anhand des Namens von der Regelklette, nicht wahr?

Und genau das ist das Problem. Wenn Sie jetzt eine neue Regelkette mit iptables -N erstellen und dort neue Regeln anlegen, dann kann iptables anhand des namens der Custom-Regelkette nicht feststellen, ob die Regel nur auf eingehenden oder nur ausgehenden Verkehr angewendet werden soll. Dabei kann es zu schwierig zu findenden Fehlern kommen, wenn Sie solche Regeln anlegen.

Deswegen müssen Sie bei iptables-Regeln für neue REgelketten zusätzlich die richtung angeben, auf die die Regel angewendet werden soll. Beachten sie: auf die Regelkette LOGNDROP müssen Sie diese Richtungsangaben nicht mehr machen, da wir ja bereits sicher sind, dass jeder Datenverkehr der es bier zur Regelkette LOGNDROP geschafft hat, definitiv gedroppt und geloggt werden soll – egal ob er ausgehend oder eingehende ist.

Für Ihre eigenen Regeln müssen Sie jedoch noch mit dem Parameter –dir [in|out] die Richtung angeben. in steht für eingehenden Verkehr, out für ausgehenden Verkehr.

wir haben ja jetzt theoretisch für die Regelkette INPUT ganz unten eine Regel, dass alle eingehenden netzwerkpkaete, die eingehen, verworfen werden sollen, richtig? Wäre es nicht sinnvoll, diese Pakete in der /var/log/syslog zu loggen, damit wir wissen, ob es verworfene Pakete gab? So lässt sich beispieslweise feststellen, ob jemand vehement versucht, sich auf unseren Server zu schalten.

Deswegen empfiehlt es sich, mit iptables -L zu schauen, an welcher position der INPUT-Regelkette derzeit die DROP ALL Regel, die wir soeben ja definiert haben, steht – und an dieser Stelle mit iptables -I eine Regel zum loggen der Pakete stellen, die es bis zu dieser Regel geschafft haben.

iptables -I INPUT <Position an der derzeit die DROP ALL Regel steht> -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

Mit dem Argument -m limit und –limit 5/min legen wir fest, das maximal 5 verworfene Datenpakete pro minute geloggt werden. Dadurch verhindern wir, dass ein automatisierter Angriff auf unser System unser Log vollspammt.

Falls Sie einmal in die Situation kommen, dass sie eine iptables-REgel löschen müssen, geht das mit der Option -D. Dabei können Sie die Regel entweder anhand einer Regeldefinition löschen

iptables -D INPUT -s 127.0.0.1 -p tcp --dport 111 -j ACCEPT

oder sie löschen Sie anhand ihrer Position in der Rulechain – diese ermitteln sie über iptables -L, wie oben schon beim PAramter -i gezeigt.

iptables -D INPUT 4

ganz wichtig: am Ende, nachdem wir unsere iptables-Regeln aufgestellt haben, müssen wir sie mit

sudo sh -c "iptables-save > /etc/iptables.rules"

speichern.

Nur weil die Regeln gespeichert sind, werden Sie jedoch nicht bei jedem neustart neu geladen. Wir müssten also theoretisch im aktuellen Zustand immer noch alle iptables-Regeln nach jedem neustart neu eingeben. Das ist natürlich Quatsch.

Deswegen erstellen wir ein Skript, welches die soeben gespeicherten iptables-REgeln lädt, sobald die Netzwerkinterfaces wieder hochgefahren werdne. dazu erstlelen wir die Datei /etc/network/if-pre-up.d/iptablesload mit folgendem inhalt

#!/bin/sh
iptables-restore < /etc/iptables-rules
exit 0

Jetzt laden wir zumindest imm die iptables, die wir gerade eben gespeichert haben. Doch was ist, wenn wir jetzt irgendwann unsere iptables einmal ändern? dann müssten wir die Reglen entweder mit dem obigen Befehl nochmal neu abspeichern – oder wir erstellen einfach ein Skript, welches die aktuellen iptables automatisch speichert, sobald eine Netzwerkkarte heruntergefahren wird (was ja auch beim Herunterfahren des Betriebssystems geschieht)

Dazu erstellen wir die Datei /etc/network/if-post-down.d/iptablessave mit folgendem Inhalt:

#!/bin/sh
iptables-save -c > /etc/iptables.rules
if [ -f /etc/iptables.downrules ]; then
   iptables-restore < /etc/iptables.downrules
fi
exit 0

beiden skripten geben wir nun noch ausführrechte

sudo chmod +x /etc/network/if-post-down.d/iptablessave
sudo chmod +x /etc/network/if-pre-up.d/iptablesload

Jetzt sind wir mit der grundkonfiguration unserer iptables fertig und stellen jetzt ein, dass jeglicher Verkehr, der nicht erlaubt ist, gedropt wird.  Dazu ersetzen wir die derzeitig exisiterenden letzten Regeln für INPUt und OUTPUT. Wir verbieten ja derzeit jeglichen INPUt-Verkehr, der nicht definiert ist, und erlauben jeglichen OUTPUT-Verkehr, der nicht definiert ist. Das ändern wir nun.

iptables -N LOGNDROP
iptables -I INPUT <aktuelle Position Logging für DROP ALL> -j LOGNDROP
iptables -I OUTPUT <aktuelle Position Logging für DROP ALL> -j LOGNDROP
iptabels -A firewall -j LOGNDROP

#löschen der DROP ALL Regel für INPUT und der ACCEPT ALL Regel für OUTPUT
iptables -D INPUT <letzte Position>
iptables -D OUTPUT <letzte Position>
#Löschen der zuvor erstellten Logging-Regel zum #Loggen gedroppter Pakete
iptables -D INPUT <letzte position>

#stattdessen Setzen dieser ultimativen Regel für #neue chain LOGNDROp
iptables -A LOGNDROP -j DROP

Diese Regel setzt nun die Loggingregel sowie die Regel iptables -P INPUT DROP außer Kraft und übergibt die Pakete statdessen an die Regelkette LOGNDROP, die zuvor mit iptables -N erstellt wurde. Diese Regelkette gab es noch nicht, doch wir haben Sei mit iptables -N gerade erstellt. Sinn dieser Regelkette ist, ein noch detailliertes Logging zu erzielen, so dass wir in unseren Logs der gedroppten Pakete unterschieden können, über welches Protokooll die geloggten Pakete gekommen sind.

hinweis: da sie jetzt bereits für die Regelkette LOGNDROP die allerletzte Regel -A LOGNDROP -j DROP erstellt haben, die wirklcih auf ALLE nicht definierten Regeln angewandt wird – egal ob Sie in der Regelkette INPUt oder OUTPUT nicht definiert wurde, verbietet – müssen sie jetzt die folgenden Regeln über iptables -I <letzte Position> VOR diese letzte ultimative Regel stellen, da sonst kein Logging stattfindet. Einleuchtend, oder?

#wenn Sie eingehende DNS-Anfragen verbieten wollen:
iptables -I <pos> LOGNDROP -p tcp --dport 53 -m limit --limit 5/min -j LOG --log-prefix "Denied DNS/TCP Request: " --log-level 7
iptables -I <pos> LOGNDROP -p tcp --dport 53 -m limit --limit 5/min -j LOG --log-prefix "Denied DNS/UDP Request: " --log-level 7
##

iptables -I <pos> LOGNDROP -p tcp -m limit --limit 5/min -j LOG --log-prefix "Denied TCP: " --log-level 7
iptables -I <pos> LOGNDROP -p udp -m limit --limit 5/min -j LOG --log-prefix "Denied UDP: " --log-level 7
iptables -I <pos> LOGNDROP -p icmp -m limit --limit 5/min -j LOG --log-prefix "Denied ICMP: " --log-level 7
iptables -i <pos> LOGNDROP -j DROP

Verfeinern der Firewall-Regeln

Bisher haben wir in unserer Firewall im prinzip nichts anderes gemacht, als Ports zu blocken oder zu erlauben. Mit Ausnahmen zwei Regeln: wir haben noch explizit jeden Verkehr auf und von Loopback-Adaptern erlaubt und den Verkehr von bestehenden/bereits aufgebauten Verbindungen und den Verkehr.

Wenn Sie die oben genannten Basis-Regeln zum erlauben und blockn von Ports sowie zum Loggen von gedroppten Paketen eingestellt haben, haben Sie schon einen sehr guten Basisschutz.

Wenn Sie noch tiefer einsteigen wollen, können sie nun noch den Verkehr auf Basis von IP-Adressräumen, von denen der verkehr erlaubt sein soll, verfeinern.

Desweiteren können sie die Firewall von einer stateless-Firewall zu einer stateful Firewall verwandeln. Bei einer Stateful-Firewall prüfen wir bei jeder Paketregel zusätzlich den Verbidnungsstatus einer verbindung über den Parameter -m conntrack, den Sie ja oben bereits schon kennengelernt haben.

Hinweis: sie sollten Ihre Firewall NICHT stateful machen, wenn Sie eine sehr hohe Last auf Ihrem Server haben (ab ca. 10 000 Netzwerkpakete pro Sekunde, die verarbeitet werden müssen). Die sogenannte stateful Inspection verbraucht einige REssourcen auf dem Server, die bei so einer hohen Last für spürbare Leistungseinbußen sorgt. Ansonsten ist die Optimierung auf eine stateful Firewall hingegen grundlegend empfehlenswert.

Priorität von Verbindungen mit Regeln

Stellen Sie sich vor, Sie haben auf einem Server im Netzwerk mehrere Services am Laufen. Sagen wir beispielsweise, auf Ihrem Server läuft ein TeamSepak Server, ein Gaming server und ein FTP Server für eine kleine Community von Leuten.

Können Sie sich vorstellen, dass es schelcht für die Performance des Gaming- und TS3-SErverdienstes ist, wenn ein Nutzer vom FTP-Server eine große Datei herunterlädt? Und können sie sich daher vorstellen,d ass es Sinn macht, dem Datenverkehr des Gaming- und TS3_Serverdiesntes Vorrang vor dem Dateidownload zu geben? denn der Nutzer, der sich die große Datei herunterlädt, kann wahrscheinlich eher ein paar Stunden länger auf seine antwort warten, als die Gamer dazu bereit wären, länger auf die Datenpakete des Gaming- und Voice-Servers zu warten.

Die folgende regel erlaubt es Ihnen beispielsweise, Verbindungen, die bereits mehr als 10 MB übertragen haben, in Ihrer Priorität herunterzustufen

iptabels -t mangle -A INPUT -o eth1 -p tcp -m connbytes --connbytes 10000000: --connbytes-mode bytes --connbytes-dir both -j CONNMARK --set-mark 999

bestimmte Datenpakete anhand von ASCII-Strings sichern

Nun ja, Ihnen ist wahrscheinlich bewusst, dass wenn Sie beispielsweise einen Webserverdienst auf Ihrem Server betreiben und in den oben erwähnten Firewall-REgeln beispielsweise den Port 80 freigeschaltet haben, dass dieser Webserverdienst an sich noch ein verwundbares Angriffsziel darstellt, nicht wahr?

Beispielsweise könnte jemand versuchen, das Admin-Panel einer WordPress-Installation auf dem webserver aufzurufen (/wp-admin) und sich per Brute Force in das Admin-Konto einzuloggen. Natürlich gibt es Mittel und Wege, sich auf Serverseite vor solchen Angriffen zu schützen, die ich an anderer Stelle schon mal erläutert habe.

Sie können jedoch auch bereits auf Netzwerkebene über iptables bestimmte Angriffsszenarien explizit verhindern. Bei Datenpaketen, die Ihre Daten nicht in Byte-Salat übertragen, sondern als Text – und das ist bei Webpaketen der fall – können Sie bestimmte anwendungspakete explizit rausfiltern lassen. Sie können beispielsweise verhindern, dass jemand von außeneine Anfrage an ihren Webserver schickt und dabei die administration über den url-zusatz wp-admin aufruft, indem Sie folgende Regel definieren

#Anfragen aus dem lokalen Netzwerk erlauben
iptables -t mangle -A INPUT -i eth0 -p tcp -s 192.168.1.0/255.255.255.0 --dport 80 -m string --string "get /wp-admin http/1.1" --icase --algo bm -m conntrack --ctstate ESTABLISHED -j ACCEPT
#Anfragen von überall sonst verweigern.
iptables -t mangle -A INPUT -i eth0 -p tcp --dport 80 -m string --string "get /wp-admin http/1.1" --icase --algo bm -m conntrack --ctstate ESTABLISHED -j DROP

Den Zugriff in bestimmten Datumszeiträumen verbieten

Angreifer suchen sich für Ihre Angriffe oftmals Zeiträume aus, in denen kein Schwein arbeitet, da dann in der regel niemand da ist, um auf mögliche erkannte Angriffe sofort zu reagieren. Mit IPtables können Sie den Zugriff auf bestimmte Diesnte zu diesen Zeiten deaktivieren.

Es wäre beispeislweise mit foglender Zeile möglich, den Zugriff auf den SSH-port an Weihnachten zu verbieten.

iptables -t filter -A INPUT -p tcp --dport 22 -m time --datestart "2015-12-24T00:00:00" --datestop "2015-12-26T23:59:59" --utc -j DROP

Sie könnten diese funktioanlität so weit ausbauen, dass Sie über einen cronjob in regelmäßigen Zeitabständen zum Dienstschluss ein Skript aufrufen, welches das aktuelle heutige Datum einträgt, um den Zugriff auf Fernwartungsdienste nach der Regelarbeitszeit per iptabltes zu verbieten. Das bedeutet aber natürlich, dass Sei im notfall dann acuh selber nicht mehr reinkommen würden. Und Sie können zu Beginn eines neuen Jahres Regeln für alle gesetzlichen Feiertage und Brückentage festlegen, um Zugriffe zu vermeiden.

 

nfqueue recorder und iptables

— to be continued–

ipset und die spamhouse-liste

ipset ist ein Kernelmodul, welches Ihnen erlaubt, viele iptables-REgeln für spezielle fälle zu einer einzigen kleinen Regel zusammenzufassen.

Lassen Sie mich das ein wenig detaillierter Erklären. Nehmen wir einmal an, sie wollen einer ganzen bestimmten IP-Adresse aus Ihrem Netzwerk beispielsweise nicht erlauben, auf sämtliche Serverdienste auf Ihrem Server zuzugreifen.

Eigentlich müssten Sie jetzt für jeden einzelnen Ihrer Serverdienste eine extra Regel aufmachen, in der Sie die ip-Adresse als Parameter angeben, und dabei mit -j die Aktion DROP angeben.

iptables -A INPUT -p tcp --dport 80 -s <zu blockende IP> -j DROP
iptables -A INPUT -p tcp --dport 443 -s <zu blockende IP> -j DROP
iptables -A INPUT -p tcp --dport 21 -s <zu blockende IP> -j DROP
...

Damit hätten Sie Ihr Zeil zwar erreicht, jedoch haben Sie sehr viel Aufwand erzeugt, da nun jedes EINZELNE Paket, welches eingeht, gegen diese zahlreichen iptables-Regeln gegengecheckt wird – auch wenn das paket nicht von dieser IP-Adresse kommt.

sie können sich vielleicht vorstellen, dass wenn Sie solche spezifischen Regeln desöfteren anlegen wollen, Sie irgendwann sehr viele Checks auf ihrer firewall haben, die jedes einzelne Datenpaket durchlaufen muss. Das kann auf Dauer sehr viel Performance fressen.

Mit dem Kernelmodul ipsets ist es möglich, solch komplexe Regelungen in einer einzigen iptables-Regel zusammenzufassen und somit nur einmalige Checks durchzuführen, was Ihnen sehr viel Perforamnce einspart.

Als erstes msüsen Sie das Kernelmodul hinzufügen

modprobe ip_set

Dann erstellen wir beispeilsweise eine Droplist, in welcher wir künftig alle explizit zu blockenden IP-Adressen angeben

ipset -N droplist nethash

und fügen nun hier im Beispiel eine zu blcokende IP-Adresse hinzu

ipset --add droplist 192.168.1.24/32

zu guter letzt müssen Sie jetzt für alle Dienste nur noch EINE einzige iptables-Regel definieren:

iptables -A INPUT -m set --set droplist src -j DROP

Und jetzt noch ein sehr guter Tweak in diesem zusammenhang wäre die Möglichkeit, die sgoeannnte Spamhouse-Liste in Ihre iptables zu integrieren. Dei Spamhouse-Liste ist eine Liste von netzwerken und auch einzelnen IP-Adressen, die dafür bekannt sind, für das Versenden von Spam-Mails oder als Ausgangspunkt von Netzwerkangriffen zu dienen. Alld iese Adressen können Sie jetzt mit einem simplen Shell-Skript in Ihre iptables-Regeln aufnehmen:

#! /bin/bash
wget -q http://www.spamhaus.org/drop/drop.txt -O drop.lasso.$(date +%s)
if [ -a $DEST ]; then
ipset --flush $HASHNAME
for i in $(grep -v E "^;|^$" $DEST | awk {'print $!'}); do
echo "insert $i to $HASHNAME"
ipset --add droplist $i
done
fi

führen Sie das Skript in regelmäßigen Abständen per cronjob aus und Sie haben immer eine aktuelle Liste von unerwünschten IP-Adressen in Ihrer Dropliste.

Und noch was cooles: Sie können spezifische IPtables-REgeln für verschiedene Länder festlegen.

Dazu holen Sie sich eine Liste von allen IP-Adressblöcken, die in einem bestimmten ALnd verwendet werden, von https://www.countryipblocks.net/country_selection.php

die Dateien speichern Sie nun als sogenannte country-files auf Ihrem Dateisystem ab.

Sie können nun beispielsweise russische IPs oder chinesische IPs blockieren. Wir erstellen

iptables -X COUNTRIES
iptables -N COUNTRIES
iptables -A COUNTRIES -j LOG --log-prefix "blocked country: " --log-level 7
iptables -A COUNTIRES -j DROP
for country_file in $(ls <speciherpfad zu den countryfiles>/*.cidr); do
bname=$(basename $country_file)
#! /bin/bash
iptables -X COUNTRIES
iptables -N COUNTRIES
country_name=$(echo $bname|cut -d ',' -f 1)
echo $processing $country_name from $country-file"; sleep 2
ipset --destroy $country_name
ipset --create $country_name nethash
#add the IPs to it
for ip in $(grep -v "^#|^$" $country_file)
do
echo "insert $ip to $country_name"
ipset --ad $country_name $ip
done
echo "$country_name IPs loaded in IPset. Configuring Netfilter"
iptables -I INPUT -m set --set $country-name src j COUNTRIES
done

in etwas abgewandelter Form können Sie das skript zu benutzen, um Ihren Traffic nach Ländern zu erfassen (dabei müssen Sie die oben zuvor gemachten iptabels-Befehle weglassen, insbesondere die Regeln zum Loggen „blocked country“ und zum droppen der Pakete).

#! /bin/bash
iptables -X COUNTRIES
iptables -N COUNTRIES
iptables -A COUNTRIES -j RETURN
country_name=$(echo $bname|cut -d ',' -f 1)
echo $processing $country_name from $country-file"; sleep 2
ipset --destroy $country_name
ipset --create $country_name nethash
#add the IPs to it
for ip in $(grep -v "^#|^$" $country_file)
do
echo "insert $ip to $country_name"
ipset --ad $country_name $ip
done
echo "$country_name IPs loaded in IPset. Configuring Netfilter"
iptables -I INPUT -m set --set $country-name src j COUNTRIES
done

nur zugriff von bestimmten ip-adressen zulassen

–to be continued–

benutzerspezifische Verbindungen

Wir können unsere iptables-Regeln noch ein wenig verfeinern, indem wir Verbindungen nur für bestimmte Benutzer zulassen. Wenn Sie für jeden Serverdienst einen extra Benutzer angelegt haben, können Sie damit beispeislweise festlegen, dass nur Prozesse, die von diesem User ausgeführt werden, auch ausgehende Verbindungen auf den dafür freigegebenen Port machen können. So verhindern Sie, dass jemand einen anderen Serverdienst einschleust, der Traffic auf einem freien Port nach draußen schickt, er eigentlich für einen anderen nutzer vorgesehen war.

Die folgende Regel erlaubt ausgehenden Traffic auf Port 80 nur für Prozesse, die der Nutzer „apache“ gestartet hat

 iptatbles -A OUTPUT -o eth0 --sport 80 -m owner --uid-owner apache -j ACCEPT

statt dem benutzernamen können Sie auch die uid des Benutzers eingeben. Gruppen können sie mit –gid-owner angeben.

Regeln für szenario 2

— to be continued

Abschließende Konfiguration

Na, fühlen Sie sich schon richtig 1337? Jetzt zeige ich ihnen wie weiter oben schon angekündigt, wie Sie iptables-Regeln testen, bevor sie ihre SSH-Verbindung trennen und nachher nicht mehr auf den Server kommen.

sie schreiben sich ein skript in irgendeinem Ordner mit irgendeinem Namen und foglendem Inhalt

touch /etc/iptables.rules_test
sudo sh -c "iptables-save > /etc/iptables.rules_test"
iptables-apply /etc/iptables.rules_test

dies speichert den aktuell gültigen Stand der iptables neu in der Datei iptables.rules und prüft die iptables-REgeln auf eventuelle Fehler. Natürlich wäre es jedesmal etwas umständlich, ständig nach dem konfigurieren von iptables daran zu denken, dieses skript auszuführen. Deswegen machen Sie sich einen alias namens checkfirewall über

alias checkfirewall='<pfad zum skript>'

Diese Zeile tragen Sie in die ~/.bashrc ihres users ein und evtl. in die vom root user, wenn Sie auch mit diesem User den Alias nutzen wollen. jedesmal, wenn Sie nun mit der konfiguration von iptables fertig sind, geben Sie checkfirewall ein, und die iptables-Konfiguration wird auf Fehler geprüft.

Jetzt zumn schluss zeige ich Ihnen noch, wie Sie ein Skript bauen, welches ihnen die komplette iptables-konfiguration temporär flusht. mit diesem Skript können sie also sozusagen die Firewall kurzfristig deaktiivieren. Um die Firewall wieder zu aktivieren, führen Sie dann einfach ein iptables-restore aus.

Erstellen Sie dazu ein File, welches nur durch den root-Benutzer auszuführen ist, und fügen Sie dort ein:

echo "Stopping firewall and allowing everyone..."
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

zum Schluss noch ausführrechte geben

sudo chmod +x <pfad zum skript>

und mit einem Alias

alias stopfirewall='<pfad zum skript>'

eingetragen in die ~/.bashrc können Sie jedesmal, wenn Sie stopfirewall eingeben, die Firewall sozusagen stoppen. sie können sich auch einen alias für startfirewall basteln, mit welchem Sie dann ein iptables-restore ausführen.

Damit die erstellten aliase übrigens auch mit dem kommando sudo funktionieren, müssen Sie einen alias für das kommando sudo erstellen

alias sudo='sudo '

Beachten sie das Leerzeichen.

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

Das könnte Dich auch interessieren...

1 Antwort

  1. 24. April 2015

    […] Einen super uide zu iptables und über die Basiskonfiguration bietet ihnen mein entsprechender blogpost […]

Kommentar verfassen

This site uses Akismet to reduce spam. Learn how your comment data is processed.