iptables Frage

[*cerox*]

Hallo zusammen,

ich bin noch Linux-Newbie und habe mir nun einige Regeln für iptables definiert:

iptables -A INPUT -p tcp -j DROP
iptables -A INPUT -p udp -j DROP
iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -p icmp -m icmp --icmp-type 5 -j DROP
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 20 -j ACCEPT
iptables -A INPUT -p tcp --dport 21 -j ACCEPT
iptables -A INPUT -p tcp --dport 29000 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -p tcp -j ACCEPT
iptables -A OUTPUT -p udp -j ACCEPT
iptables -A OUTPUT -p icmp -j ACCEPT

Kann mir jemand sagen warum mit diesen Regeln kein ausgehender Datenverkehr mehr funktioniert, also ich kann im Browser keine URL's mehr aufrufen, auch keine IP's also an der Adressauflösung liegt es nicht. Anpingen etc. kann ich den Router, sobald ich mit "iptables --flush" alles lösche, geht ja auch alles^^

 

[Enigma]

Schreib deine Drop anweisungen doch mal ganz ans Ende der Chain.

Du verwirfst jedes TCP und UDP-Packet

 

[jdkbx]

wie schon gesagt, was zuerst matched wird genommen. daher solltest du erst die regeln angeben die traffic erlauben, am ende alles andere verbieten. du kannst dir das explizite verbieten auch sparen, wenn du die policy auf DROP stezt. trotzdem wirst du wahrscheinlich stateful filtering brauchen, da es relativ schwierig ist, für nen desktop statische regeln für input festzulegen, weil manche ports halt dynamisch gewählt werden.

 

[*cerox*]

Also wenn ich die Policy auf DROP setze, dann verwirft er alles, außer das, was ich in den Regeln mit ACCEPT erlaube?

 

[marcelcedric]

Also wenn ich die Policy auf DROP setze, dann verwirft er alles, außer das, was ich in den Regeln mit ACCEPT erlaube?

Jep, genau.

MfG

 

[*cerox*]

Also es sieht jetzt so aus:

#!/bin/sh
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTUP ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p icmp -m icmp --icmp-type 5 -j DROP
iptables -A INPUT -i eth0 -p tcp --dport 21 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 29070 -j ACCEPT

Ist das so sicher also so, dass von aussen keiner auf mich zugreifen kann bis auf Zugriffe auf einen SSH, FTP- und Gameserver (Port 29070)?

Nehmen wir an ich füge folgende Zeilen hinzu:

iptables -A INPUT -p icmp -m icmp --icmp-type 0 -j DROP
iptables -A INPUT -p icmp -m icmp --icmp-type 8 -j DROP

Dann kann mich doch theoretisch keiner mehr anpingen oder?

 

[jdkbx]

Also es sieht jetzt so aus:

#!/bin/sh
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTUP ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p icmp -m icmp --icmp-type 5 -j DROP
iptables -A INPUT -i eth0 -p tcp --dport 21 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 29070 -j ACCEPT

Ist das so sicher also so, dass von aussen keiner auf mich zugreifen kann bis auf Zugriffe auf einen SSH, FTP- und Gameserver (Port 29070)?

ja

Nehmen wir an ich füge folgende Zeilen hinzu:

iptables -A INPUT -p icmp -m icmp --icmp-type 0 -j DROP
iptables -A INPUT -p icmp -m icmp --icmp-type 8 -j DROP

Dann kann mich doch theoretisch keiner mehr anpingen oder?

dich kann schon jetzt keiner mehr anpingen, da du ja icmp nich explizit erlaubt hast. dh is die zeile
iptables -A INPUT -p icmp -m icmp --icmp-type 5 -j DROP
redundant

 

[*cerox*]

Hm also die Zeile mit ICMP Type 5 blocken hab ich aus soner Empfehlung ^^

Wofür ist denn ICMP Type 5 zuständig?

 

[jdkbx]

die zeile is ja nich falsch, aber unnötig. wenn die policy schon DROP ist, dann macht eine zeile mit DROP keinen sinn, solange sie nich eine algemeinere, tiefer stehende zeile mit einem anderen target als DROP einschränken soll.

zum type 5: redirect (erster treffer bei google
http://www.iana.org/assignments/icmp-parameters

wenn dus genauer wissen willst, dann lies am besten RFCs (792 für ICMP).
http://www.faqs.org/rfcs/rfc792.html

 

[arkelanfall]

Also es sieht jetzt so aus:

iptables -A INPUT -p icmp -m icmp --icmp-type 0 -j DROP
iptables -A INPUT -p icmp -m icmp --icmp-type 8 -j DROP

Dann kann mich doch theoretisch keiner mehr anpingen oder?

Warum soll dich denn keiner mehr anpingen können? Welchen Vorteil, außer, dass du dazu beiträgst, ip zu sabotieren, siehst du in dieser Maßnahme?
Außerdem solltest du eingehend auf jeden Fall icmp (zumindest teilweise) erlauben. Anderenfalls erhältst du keine icmp-destination-unreachable-Meldungen mehr, was dir selber mehr schadet als nutzt.

Zur DROP-Policy generell sollte man per "reject"-Regel Pakete ablehnen, damit das Gegenüber auch sieht, dass man nichts wissen will. DROP macht eigentlich ausschließlich bei typischen "Wurm-Ports" (z.B. 135) oder gegen lästige filesharing-clients (die sich nicht um tcp-rst-Pakete kümmern) (also z.B. Pot 4662) Sinn.

Dazu kommt dann natürlich noch die grundsätzliche Regel, dass ein nicht laufender Server auch nicht angegriffen werden kann.
Bildlich gesprochen: Eine nicht vorhandene Tür ist sicherer, als eine Tür mit einem Schloss davor.

Prinzipiell kann ich dir auch nur empfehlen, dich ausführlich mit iptables und tcp/ip generell zu beschäftigen, bevor du einen Paketfilter aufsetzt. Naja, aber das ist wohl, obwohl es der sinnvollste Rat ist (meiner Meinung nach zumindest), gleichzeitig der, den du wohl nicht hören wolltest.

Ich poste dir hier mal als Denkansatz mein iptables-Skript (ohne Anspruch darauf, dass es perfekt ist).
Der Rechner bietet im LAN Samba an, und nach außen (und zum Lan hin) ssh. Schließlich werden alle Pakete vor dem Verwerfen geloggt.

# ALTE REGELN LOESCHEN
iptables --flush

# POLICIES
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# DISABLE FORWARDING
echo 0 > /proc/sys/net/ipv4/ip_forward

# lokale kommunikation immer erlauben
iptables -A INPUT -i lo --dest 127.0.0.1 --source 127.0.0.1 -j ACCEPT
iptables -A OUTPUT -o lo --dest 127.0.0.1 --source 127.0.0.1 -j ACCEPT


#ICMP

#icmp
iptables -A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
iptables -A INPUT -p icmp --icmp-type parameter-problem -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
iptables -A INPUT -p icmp --icmp-type timestamp-reply -j ACCEPT
iptables -A INPUT -p icmp --icmp-type timestamp-request -j ACCEPT
iptables -A INPUT -p icmp -j DROP

iptables -A OUTPUT -p icmp -j ACCEPT


# INPUT

#ssh
iptables -A INPUT -p TCP --source 192.168.1.0/24 --dport 22 -m state --state NEW -j ACCEPT
#samba
iptables -A INPUT -p TCP --source 192.168.1.0/24 --dport 139 -m state --state NEW -j ACCEPT
iptables -A INPUT -p TCP --source 192.168.1.0/24 --dport 445 -m state --state NEW -j ACCEPT
iptables -A INPUT -p UDP --source 192.168.1.0/24 --dport 137 -j ACCEPT
iptables -A INPUT -p UDP --source 192.168.1.0/24 --dport 138 -j ACCEPT
#apache
iptables -A INPUT -p TCP --source 192.168.1.0/24 --dport 80 -m state --state NEW -j ACCEPT
#established 
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT

# ssh auch vom Internet erlauben
iptables -A INPUT -p TCP --dport 22 -m state --state NEW -j ACCEPT

#rest 
iptables -A INPUT -j LOG --log-prefix "IPTABLES REJECT "
iptables -A INPUT -j REJECT

# OUTPUT 
iptables -A OUTPUT -j ACCEPT

 

[jdkbx]

Warum soll dich denn keiner mehr anpingen können? Welchen Vorteil, außer, dass du dazu beiträgst, ip zu sabotieren, siehst du in dieser Maßnahme?
Außerdem solltest du eingehend auf jeden Fall icmp (zumindest teilweise) erlauben. Anderenfalls erhältst du keine icmp-destination-unreachable-Meldungen mehr, was dir selber mehr schadet als nutzt.

Zur DROP-Policy generell sollte man per "reject"-Regel Pakete ablehnen, damit das Gegenüber auch sieht, dass man nichts wissen will. DROP macht eigentlich ausschließlich bei typischen "Wurm-Ports" (z.B. 135) oder gegen lästige filesharing-clients (die sich nicht um tcp-rst-Pakete kümmern) (also z.B. Pot 4662) Sinn.
[/CODE]

wenn man aber dem gegenüber gar nicht verraten will, dass man überhaupt da ist, macht DROP schon mehr sinn.
das kommt aber auf die eigene einstellung zu dem thema an. standardkonform und einfach nur funktionierend; da hast wohl recht. wenn du aber nen defensiven standpunkt hast und es nem potenziellen angreifer schwer machen willst, dann macht mans halt anders.

 

[arkelanfall]

wenn man aber dem gegenüber gar nicht verraten will, dass man überhaupt da ist, macht DROP schon mehr sinn.

Nein. Die einzige Möglichkeit, das vorzugaukeln wäre, dass dein Provider ein "icmp host unreachable" absetzt. Dadurch wäre dann aber die Kommunikation mit der Außenwelt leicht schwieriger geworden.
Wenn du nicht reagierst, zeigst du deine Existenz genauso, wie wenn du sagst "ich will nicht mit dir reden". Und sobald du irgendeinen Dienst anbietest, bist du so oder so sichtbar. Egal, ob deine anderen Ports "stealth" sind oder nicht.
Der Glaube an den"stealth mode" ist zusammen mit Personal Firewalls ins Marketing eingezogen. Dadurch hat er aber noch lange keinen technischen Hintergrund.
Dafür kann man sich durch Verbieten von ICMP-Typen wie "fragmentation needed" selbst extrem gut ins Bein schießen.

wenn du aber nen defensiven standpunkt hast und es nem potenziellen angreifer schwer machen willst, dann macht mans halt anders.

Nein. Es macht bei einem gezielten Angriff keinen Unterschied, ob du DROPst oder REJECTest. Ein erreichbarer Dienst kann so oder so angegriffen werden.
Ein nicht laufender Dienst, kann so oder so nicht angegriffen werden.
Der tcp-stack kann so oder so angegriffen werden.
netfilter kann so oder so angegriffen werden.

Welchen Nachteil hat ein Angreifer also durch Drop? Einen langsameren Portscan? Und weiter? In Zeiten von DSL kann er Problemlos zig Ports gleichzeitig testen. Und wenn deine Sicherheit darauf beruht, dass ein Angreifer länger braucht, um einen laufenden Dienst zu finden, dann würde ich die Sicherheitspolitik mal gründlich überdenken.

Und gegen nicht-gezielte Angriffe ist es erst recht egal, ob du Pakete verwirfst, oder korrekt zurückweist.
Korrekte Kommunikation wird allerdings teilweise erheblich behindert. Siehe icmp "fragmentation needed" als Paradebeispiel. Aber auch ein eingehendes "host unreachable" oder "port unreachable", das vom Paketfilter verworfen wird, ist lästig (du wartest dann locker die dreifache Zeit, bis du merkst, dass du dich bei der Eingabe der IP-Adresse vertippt hast. Toller Gewinn.)

 

[jdkbx]

technisch hast natürlich recht. hab ich ja auch nie anders behauptet.

Und gegen nicht-gezielte Angriffe ist es erst recht egal, ob du Pakete verwirfst, oder korrekt zurückweist.

nur hier seh ich die sache ein wenig anders. wenn script kiddies auf opfersuche sind, kann das schon mal den unterschied machen.

 

[arkelanfall]

Wenn du mir "technisch" recht gibst, inwiefern gibst du mir dann nicht recht? Gefühlsmäßig? Ein "gutes Gefühl" bringt meiner Erfahrung nach nur Nachteile. Man "fühlt" sich sicherer, ist es aber nicht. Das kann nur nach hinten losgehen.

Und zu den "script kiddies". Welchen Sicherheitsnachteil hat man, wenn man denen mit tcp-rst oder icmp-port-unreachable antwortet? Dann gehen sie zum Nächsten, und man hat Ruhe. Bringt beiden Seiten nur Vorteile.
Warum soll ich meinen Internetanschluss stören, nur damit irgendein "Script-Kiddie" pro Tag 5 Hosts weniger scannen kann?

Wie schon weiter oben geschrieben, ich sehe den Sicherheitsgewinn nicht. Weder den "technischen", noch den "sozialen". Ich sehe nur einen Haufen Probleme (vom Droppen von P2P-Ports und "Windows-Wurm-Ports" mal abgesehen), lasse mich aber gern eines Besseren belehren.

 

[jdkbx]

Wenn du mir "technisch" recht gibst, inwiefern gibst du mir dann nicht recht? Gefühlsmäßig? Ein "gutes Gefühl" bringt meiner Erfahrung nach nur Nachteile. Man "fühlt" sich sicherer, ist es aber nicht. Das kann nur nach hinten losgehen.

mach mal nich so viele annahmen, sonst wird das schnell zu nem monolog.

Und zu den "script kiddies". Welchen Sicherheitsnachteil hat man, wenn man denen mit tcp-rst oder icmp-port-unreachable antwortet? Dann gehen sie zum Nächsten, und man hat Ruhe.

auch das würd ich als annahme bezeichnen. wenn man die halt anders trifft, kommt man zu anderen schlussfolgerungen.

das kommt aber auf die eigene einstellung zu dem thema an

 

[arkelanfall]

mach mal nich so viele annahmen, sonst wird das schnell zu nem monolog.

Meine Annahmen sind alle fundiert belegbar (und wurden großteils auch hier im Thread von mir belegt). Wenn du das anders siehst, dann geh bitte konkret auf meine "Annahmen" ein und widerlege sie.

Bring doch bitte ein Argument an, inwiefern DROP zusätzliche Sicherheit bringt.
Egal vor wem/oder was. Aber einfach mal ein konkretes Argument oder Beispiel.

auch das würd ich als annahme bezeichnen. wenn man die halt anders trifft, kommt man zu anderen schlussfolgerungen.

Dann bring doch bitte ein Argument vor, warum sich REJECT negativ auswirken kann. Konkret bitte. Ich habe ein konkretes Beispiel gebracht, warum ein generelles DROP schlecht ist. Du hast das weder zu widerlegen versucht, noch irgendetwas vorgebracht, was konkret FÜR DROP spricht.

Und ja, mich würden deine Argumente wirklich interessieren. Und nein, das ist kein Trollversuch.

 

[jdkbx]

ok, na gut. mal ein richtig konkretes bsp

Annahmen:
menge von exploits für spezifische dienste (version, os, architektur),
motif,
technische möglichkeit sind vorhanden

nun sucht man natürlich ein match, in der regel per (port)scan und analyse der gesammelten daten.
hier kommts jetzt auf die art des scannens an. gehst du direkt auf die entsprechenden ports (also quasi die menge der exploits durchiterieren) dann machts kein unterschied ob DROP oder REJECT oder was auch immer. das sollte in der realität und bei heutigen technischen möglichkeiten auch meist der fall sein.
gehst du allerdings unauffällig vor, also erstma ein simples icmp packet, das kein aufsehen in nem logfile verursacht, und tastest dich dann langsam immer weiter vor, zb erstma ermitteln des os' anhand von response charakteristika und weitere signatur ermittlungen, dann kann das DROP die analyse durchaus erschweren. im günstigsten fall wird ein host dann relativ schnell als uninteressant eingestuft.
natürlich bewegt sich das szenario schon in die richtung der gezielten angriffe, wos dann wieder irrelevant ist, welche policy gesetzt ist, aber wenn der ganze prozess (aus kostenminimierungsgründen) automatisiert abläuft, bist du als opfer potenziell weniger gefährdet.
es stellt keinen harten sicherheitsgewinn dar, sondern ändert lediglich wahrscheinlichkeiten. und ob man sowas braucht (um mich nochmal zu zitiern )

das kommt aber auf die eigene einstellung zu dem thema an

 

[arkelanfall]

ok, na gut. mal ein richtig konkretes bsp

Juhu, danke.

gehst du allerdings unauffällig vor, also erstma ein simples icmp packet, das kein aufsehen in nem logfile verursacht,

Ich finde nicht, dass ein Ping unauffälliger ist, als ein Verbindungsversuch. Wenn ich wissen will, ob jemand einen Webserver hostet, versuch ich ein connect auf Port 80. Unauffälliger gehts gar nicht. Oder mache ich jetzt einen Denkfehler? Und wenn ich x Dienste abklappern möchte, bringt es auch wenig, wenn ich durch die Feststellung des OS diese Dienste auf x/1,2 reduziere (viel mehr wird es nicht bringen, da fast alle "wichtigen" Dienste auf extrem vielen Plattformen laufen).

Dafür mach ich gerne mal ein traceroute oder ping zu einem Host, den ich nicht erreichen kann, obwohl ich es eigentlich möchte, um herauszufinden, wo das Problem liegt.
Und um auf den Ursprungspost zurückzukommen: Bei einem Gameserver (der ja gehostet werden soll) sind Pingzeiten erst recht extrem nützlich (Stichwort: Lag).

und tastest dich dann langsam immer weiter vor, zb erstma ermitteln des os'

Ja, man kann so das Ermitteln des OS erschweren, da gebe ich dir Recht. Sozusagen "security by obscurity". Aber was bringt das dem Angreifer? Angriff eines Dienstes? Dann ist das Betriebssystem erst einmal uninteressant. Die Version des entsprechenden Dienstes ist dann viel interessanter.
Also Angriff des tcp-stacks? Wenn der nicht gepatcht ist, ist es nur eine Frage der Zeit, bis mal jemand blind einfach probiert, ob der Exploit funktioniert. OS-Verschleierung bringt hier also auch nichts.

im günstigsten fall wird ein host dann relativ schnell als uninteressant eingestuft.

Korrekt. "Im günstigsten Fall". Das nennt sich dann Glücksspiel, aber nicht Sicherheit. Wenn ich mit geschlossenen Augen über die Straße renne, komme ich im günstigsten Fall auch auf der anderen Seite an. Je nach Verkehrssituation in dieser Straße kann das sogar recht lange gut gehen. Aber ich würde das nicht als sicher bezeichnen.

natürlich bewegt sich das szenario schon in die richtung der gezielten angriffe,

Das ist weniger das Problem. Bruce Schneier (Erfinder von Blowfish und Twofish) hat das in seinem aktuellen Crypto-Gram meiner Meinung nach sehr schön auf den Punkt gebracht: Du beschreibst ein bestimmtes Szenario, gegen das du dich schützt. Das ist natürlich erstmal nicht falsch. Aber es bringt dir auch keinen Vorteil, weil du eben im Voraus nicht weißt, wie der Angreifer vorgehen wird. Präventives Konzentrieren auf einzelne, eng gefasste, Szenarien verändert deine Gesamtsicherheit so gut wie überhaupt nicht. Dafür werden viele Ressourcen verbraucht (Geld, Arbeitszeit), und die Komplexität (und damit der Wartungsaufwand, und die Wahrscheinlichkeit, etwas zu übersehen) deines Systems erhöht sich exponentiell.

es stellt keinen harten sicherheitsgewinn dar, sondern ändert lediglich wahrscheinlichkeiten.

Nicht einmal das. Es schließt ein spezielles, noch dazu erstmal harmloses, Szenario aus (Nämlich die Bestimmung des Betriebssystems mit Hilfe von ip-Paketen). Du verringerst nicht die Wahrscheinlichkeit eines Angriffes, sondern du entfernst ein einzelnes spezielles Szenario aus einem riesigen Topf voller Angriffsmöglichkeiten.
An der Gesamtsicherheit ändert sich dadurch nichts, da weder die Anzahl der Angreifer, noch deren Methoden fest definiert sind.

Aber in einem muss ich dir natürlich Recht geben: Es ist tatsächlich reine Ansichtssache, ob man meint, dass der Versuch des Verschleierns der Betriebssystemversion (Achtung: Apache & Co. geben hierüber auch oft sehr freigiebig Auskunft) einen so großen Sicherheitsgewinn bringt, dass man deshalb massive Störungen bei regulärer ip-Kommunikation in Kauf nimmt.

 

[*cerox*]

So nach eurer ewigen Diskussion habe ich dann noch eine Frage:

Wenn ich die Pakete per DROP verwerfe, bekommt der andere Host die Meldung "Zeitüberschreitung". Ich habe das mal im LAN ausprobiert. Wenn ich nun die Konnektivität physikalisch trenne und wieder einen Ping ausführe, kommt dieselbe Meldung und es dauert auch nicht länger oder geht schneller. Also wie merkst du dann, dass der Host trotzdem existiert indem du ihn anpingst? Oder habe ich das nur falsch verstanden und du meintest einfach, die Person führt dann Portscans aus und sieht aktive Dienste, wodurch dann klar ist, dass der Host existiert.

Wenn ich die Pakete mit REJECT verwerfe, wodurch der andere Host ja eine Rückmeldung bekommt... Was kommt dann für eine Meldung? Destination Unreachable???

 

[arkelanfall]

Wenn ich die Pakete per DROP verwerfe, bekommt der andere Host die Meldung "Zeitüberschreitung". Ich habe das mal im LAN ausprobiert. Wenn ich nun die Konnektivität physikalisch trenne und wieder einen Ping ausführe, kommt dieselbe Meldung

Korrekt. Aber das Internet ist kein Lan. Dein Lan hat vermutlich nur einen Switch, und der generiert keine Fehlermeldungen. Im Internet gibt es aber Router,... Und spätestens der letzte Router deines Providers, der die Daten dann an deinen Anschluss weiterleitet, weiß, ob du online bist oder nicht. Und schickt, so er nicht völlig kaputtkonfiguriert wurde, entweder eine Fehlermeldung "host unreachable" an den Absender, oder leitet das Paket an dich weiter. Jetzt klarer?

Oder habe ich das nur falsch verstanden und du meintest einfach, die Person führt dann Portscans aus und sieht aktive Dienste, wodurch dann klar ist, dass der Host existiert.

Das kommt dazu. Sobald du auch nur einen einzigen Dienst anbietetst, kannst du dir das ganze DROP-Zeug sowieso ersparen. OS-Fingerprinting geht dann anhand der so versandten TCP/SYN, TCP/FIN,... Pakete.

Wenn ich die Pakete mit REJECT verwerfe, wodurch der andere Host ja eine Rückmeldung bekommt... Was kommt dann für eine Meldung? Destination Unreachable???

- Host unreachable (icmp)
- port unreachable (icmp)
- administratively prohibited (icmp)
gehören alle zur übergruppe "destination unreachable" von icmp

oder ein tcp/rst paket bei tcp (das ist das normale verhalten des tcp-stacks, ohne paketfilter) bzw. bei udp immer ein icmp port-unreachable.