PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : iptables: Warum alle Ports schließen?



SeeksTheMoon
10.10.05, 00:43
Überall liest man es: "Mach mit der Firewall ALLES dicht und öffne dann gezielt".
Ich habe jetzt ein paar Stunden im Netz gesucht ob es eine Begründung dafür gibt, immer alles dicht zu machen, aber die habe ich nicht gefunden.
Was passiert denn wenn ein Angreifer auf einen offenen, aber ungenutzten Port zielt? Nichts. Oder doch? Meiner Meinung nach kann doch gar kein Schaden entstehen, da keine Auswertung der Pakete stattfindet.

Speziell wenn ich in der Firewall auf connection tracking verzichten will, dann schließe ich mich nur selber aus wenn ich alles dicht mache, die Ports ab 1024 sollten da schon offen sein (denn man kann dann nicht abfragen ob ein Paket zu einer related/established Verbindung gehört).

Dann reicht es doch eigentlich, alle Pakete zu accepten und nur dort Einschränkungen zu machen wo man es für sinnvoll hält, z.B. um einen Dienst zusätzlich abzusichern oder um Zugriffe loggen zu lassen.


Ich bin auf Gegenargumente gespannt.

klemens
10.10.05, 01:07
Ich persönliche finde es dann für sinnvoll, wenn man noch so seine Probleme hat, ev. unkonfigurierte Dienste in den Griff zu bekommen :D
Z.b. knapp nachdem man ein System neu aufgesetzt hat.

Also eine Firewall in diesem Sinne, hat ja auch immer mit einer Ungewissheit zu tun, was sich hinter der Firewall abspielt. Da wirds wohl klüger sein, zuerst dicht zu machen und nur dort zu öffnen, wo ich mir sicher bin.

Dass ein nicht existenter Port verletzbar ist, hab ich auch noch nie gehört.

Freekazonid
10.10.05, 01:22
vermutungen meinerseits:

1. packets die an ports adressiert sind welche geschlossen werden, werden auch direkt verworfen, was ja nicht der fall ist wenn sie offen sind, dort verarbeitet der kernel sie ja vorerst weiter
2. nehmen wir an bei dir laeuft eine anwendung von der du nichts weisst, ueber die du nicht informiert bist, die du vergessen hast, oder von der du garnicht weisst das sie an bestimmten ports lauscht, dann ist sie trotzdem entschaerft wenn ihr entsprechender port dicht ist

es gibt dir einfach mehr kontrolle. du sagst was offen ist und was zu ist. aber so ein wischiwaschi "ja mal offen lassen und da wird schon keine anwendung horchen" ist ja nicht so erstrebenswert. erstaunlich das man dieses modell ueberhaupt in frage stellt ;)

Roger Wilco
10.10.05, 01:25
Überall liest man es: "Mach mit der Firewall ALLES dicht und öffne dann gezielt".
Wo liest man das überall?


Was passiert denn wenn ein Angreifer auf einen offenen, aber ungenutzten Port zielt?
Ein Port einer Schnittstelle, an den kein Dienst gebunden ist, heißt per Definition "geschlossen". Es gibt also keine ungenutzten (i. S. v. kein Dienst ist daran gebunden) offenen Ports.


Dann reicht es doch eigentlich, alle Pakete zu accepten und nur dort Einschränkungen zu machen wo man es für sinnvoll hält, z.B. um einen Dienst zusätzlich abzusichern oder um Zugriffe loggen zu lassen.
Ja.


Dass ein nicht existenter Port verletzbar ist, hab ich auch noch nie gehört.
Ja, weil es per Definition nicht geht. :ugly:

rudelgurke
10.10.05, 07:30
Das "alles dicht machen" und dann öffnen hat schon einen Sinn. Unter Win läuft meist der gesamte Freigabe Kram unter Port 445 ab, manche Distributionen aktivieren einen DNS Server auf Port 53, X11 lauscht bei schlechter Konfiguration auf Port 6000 usw. Dass können dann Schwachstellen sein, die man natürlich gezielt schliessen kann. Vom Überblick her ist es aber wohl einfacher erstmal alles zu schliessen und dann einzeln auf zu machen - so weiss man auch selbst was wozu geöffnet wurde.

Russel-Athletic
10.10.05, 09:05
Ein Packetfilter ist etwas, was mir Sicherheit geben soll.
Ich kann auch einfach alles offen lassen, aber dann ist der Sinn einer Firewall nicht gegeben.

Alles schließen ist einfach dazu da um deine Fehler auszubügeln.

SeeksTheMoon
10.10.05, 11:37
Wo liest man das überall?
z.B. im Netfilter Howto auf netfilter.org und in dem hier verlinkten Firewall-FAQ-Dings und noch mindestens an 100 anderen Stellen.

Gut, ich weiß ja welche Dienste bei mir laufen und welche Ports sie verwenden. Dann werde ich nur Regeln gegen ungültige Pakete oder gegen Spoofing, Flooding etc. einbauen und die Dienste dicht machen sofern das sinnvoll ist.
Das sichert ausreichend ab und reduziert den Code um 80% Komplexität und man kann sich nicht mehr aus Versehen selber ausschließen wenn man an den Regeln etwas ändert.


btw: kennt jemand ein iptables Target mit dem ich Kommandos ausführen kann, wenn die Regel matcht?
Das wär z.B. sinnvoll um sich eine Mail schicken zu lassen o.ä.
Vielleicht gehts mit QUEUE, aber das hab ich noch nie benutzt und weiß nicht ob das damit so klappt.

maomakmaa
10.10.05, 12:59
Alles schließen, und nur öffnen was gebraucht wird ist doch logisch.
Es hilft Fehler zu vermeiden.
Ausserdem lasse ich zuhause auch nicht Tür und Tor offen, und mach nur dann eine Luke zu wenn mir einer da was rausgeschleppt hat ;)

r00t043
10.10.05, 13:19
Das ist Sinnvoll fuer Leute, die die Serverdienste auf dem Rechner nicht beherrschen. Da laufen dann auf dem Router/direkt im Netz stehendem Einzelplatzrechner ein Apache, MySQLd, etc und der Benutzer schaft es nicht die Anleitung zu lesen um den so zu konfigurieren das er nur im internen Netz/loopback lauscht (in Ausnahmefaellen laesst sich der Server dementsprechend nicht konfigurieren).
Paranoide Zeitgenossen nutzen das auch um sich unsichtbar zu machen.

Das sieht dann so aus:
Client will eine Verbindung mit SYN eroeffnen:
Auf dem Port lauscht ein Serverdienst:
-Server antwortet mit SYN/ACK -> Port ist offen, Verbindung wird angenommen

Auf dem Port lauscht kein Serverdienst, oder der will die Verbindung nicht:
-Server antwortet mit RST -> Port geschlossen, Verbindung wird nicht angenommen

Firewall verwirft die Packete:
-Server antwortet garnicht -> Client weiss nicht ob hinter der IP sich ein Rechner verbirgt oder nicht

(Mir solls egal sein, bei mir sind die Ports normal geschlossen. Viel schlimmer find ich die Leute die ICMP rausfiltern)

Mr_Maniac
10.10.05, 15:40
-Server antwortet garnicht -> Client weiss nicht ob hinter der IP sich ein Rechner verbirgt oder nicht
DAS ist ein weit verbreiteter IRRTUM!
Gerade wenn KEINE Antwort kommt, weiß man, dass da was ist...
Wenn da nämlich WIRKLICH kein Rechner wäre, dann würde der letzte Router auf der Strecke "Host not reachable" zurückgeben!
Man kann seinen PC/seine IP nicht "tarnen"...

Dieses "Pakete verwerfen" bringt AFAIK nur time-outs auf der Client-Seite aber keine weitere Sicherheit...

r00t043
10.10.05, 16:58
@Mr_Maniac:
Woher nimmst du diese Information?
edit:
Und was meinst du mit "Host not reachable"? ICMP host unreachable?

Mr_Maniac
10.10.05, 18:59
Ja, ICMP host unreachable...
Und woher ich das weiß?
Nun... Vielleicht, weil das TCP/IP-Netzwerk nun mal so funktioniert?
Der letzte Router vor dem Endpunkt gibt diese Meldung nunmal zurück, falls der Host off-line ist...

EDIT:
Hier dann doch noch zwei Links ;)

http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#Deny
http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html#Verarsche

Jasper
10.10.05, 21:09
Ich bin auf Gegenargumente gespannt.

ist einfach ein sicherheitsnetz. an ports, die gefiltert werden, können nunmal keine dienste lauschen, egal ob gewollt oder unabsichtlich. ausserdem gibt es viele dienste, die sich nicht auf eine/mehrere ip-adresse(n) binden lassen. und auch serverdienste können bugs haben und ports öffnen, die sie gar nicht öffnen sollen.
deshalb die serverdienste ordentlich konfigurieren und den filter als zusätzliche barriere, tut ja niemandem weh.
den dicken hals kriege ich nur bei kompletten DROPs, aber das ist eine andere geschichte.


-j