Hallo, ich benutze einen Linuxrechner u.A. als Fileserver und Firewall. An diesem Rechner sind weder Bildschirm noch Tastatur angeschlossen. Bedienen tue ich ihn per Telnet. Das Firewalldesign mit IPTABLES gibt mir folgendes Raetsel auf: Wenn ich die Default-Policy der INPUT-Chain auf DROP stelle und nur die Verbindungen explizit zulasse, die ich brauche, so erhalte ich von dem Telnet-Server erst ca. 10 Sekunden nach Anforderung das login. Stelle ich dagegen die Default-Policy der INPUT-Chain auf ACCEPT und sperre explizit alle Verbindungen, die ich nicht brauche, so erhalte ich das login sofort nach Anforderung. Kann mir jemand diesen Umstand erklären? Vielen Dank! -- Thomas Broer Gänsewiese 5 24107 Kiel 0431 314910
Am Montag, 20. Oktober 2003 11:18 schrieb Thomas Broer:
so erhalte ich von dem Telnet-Server erst ca. 10 Sekunden nach Anforderung das login.
Schreib doch mal deinen Client in die /etc/hosts oder stelle sicher dass der DNS-mässig gefunden wird (DNS-Abfragen durchlassen) Alfred
Hallo, * Am 20.Oct.2003 postete Thomas Broer:
ich benutze einen Linuxrechner u.A. als Fileserver und Firewall. An diesem Rechner sind weder Bildschirm noch Tastatur angeschlossen. Bedienen tue ich ihn per Telnet.
Das Firewalldesign mit IPTABLES gibt mir folgendes Raetsel auf:
Wenn ich die Default-Policy der INPUT-Chain auf DROP stelle und nur die Verbindungen explizit zulasse, die ich brauche, so erhalte ich von dem Telnet-Server erst ca. 10 Sekunden nach Anforderung das login.
Stelle ich dagegen die Default-Policy der INPUT-Chain auf ACCEPT und sperre explizit alle Verbindungen, die ich nicht brauche, so erhalte ich das login sofort nach Anforderung.
Kann mir jemand diesen Umstand erklären?
Ich kann es nicht. Aber ich kann Dir gerne erklären, weshalb Du Dich nicht mit heruntergelassenen Hosen in einem Netzwerk bewegen solltest. Und dabei geb ich Dir gleich den Rat, ssh zu nutzen. Ist nämlich verschlüsselt. Hast Du mit ssh das gleiche Problem? Ich könnte mir vorstellen, daß telnet highports (1025-65...) will.
Vielen Dank!
Wenns hilft. Gern geschehen! Beste Grüße Alex -- Das Freibad ist der Ort, wo man im Sommer auch frische Pilze kriegt. [Harald Schmidt]
On Monday 20 October 2003 11:18, Thomas Broer wrote:
Wenn ich die Default-Policy der INPUT-Chain auf DROP stelle und nur die Verbindungen explizit zulasse, die ich brauche, so erhalte ich von dem Telnet-Server erst ca. 10 Sekunden nach Anforderung das login.
1. Wenn Du Dich schon mit dem Thema Sicherheit auseinandersetzt, dann willst Du keine Services betreiben, die Daten unverschlüsselt übertragen. Verwende ssh statt telnet. 2. Erstelle Deine iptables-Regeln am Besten mit fwbuilder (http:// www.fwbuilder.org). Das ist übersichtlicher. 3. Wenn Du vor Deine Default-Policy-Regel DROP eine explizite Alles-Sperr-Regel mit Logging stellst, kannst Du sehen, ob als Antwort auf Deinen telnet-Versuch Pakete zurück kommen, die Du blockierst. 4. Wahrscheinlich läuft der telnetd auf der Gegenseite hinter einem tcpd. Der macht eine identd-Query gegen Dich. Da Du unseligerweise DROP als Policy verwendest, läuft die identd-Query in einen Timeout und Du mußt einen Timeout lang warten, bis Du einen Connect kriegst. Das wäre auch mit sshd nicht besser. 5. DROP sollte man in Firewall-Regeln generell nicht nehmen. Besser ist ein REJECT mit einem ICMP Code 3, Subcode 10 (administratively prohibited). Ein DROP hilft Die gegen einen erfahrenen Angreifer gar nichts - er wird eine Lücke trotzdem finden und eindringen. Es hilft Dir gegen ein Script Kiddie auch nix. Hier ist ein ICMP 3:10 besser, denn so weiß das Script Kiddie "Hier ist eine Firewall" und sucht sich ein leichteres Ziel. Und legitimen Benutzern machst Du mit einem DROP nur das Debugging des Netzwerkes schwieriger. Schließlich bestrafst Du Dich mit einem DROP statt einem REJECT selber, denn Du läufst an allen Ecken und Enden in nutzlose Timeouts. Kristian -- http://www.amazon.de/exec/obidos/wishlist/18E5SVQ5HJZXG
Hallo, Am Mon, 20 Oct 2003, Kristian Köhntopp schrieb:
5. DROP sollte man in Firewall-Regeln generell nicht nehmen. Besser ist ein REJECT mit einem ICMP Code 3, Subcode 10 (administratively prohibited).
# iptables -P FORWARD REJECT iptables: Bad policy name Als Policy geht ein "REJECT" nicht (zumindest bis inkl. iptables 1.2.4). Und hier ging es um die Policy... -dnh -- Williams and Holland's Law: If enough data is collected, anything may be proven by statistical methods.
On Monday 20 October 2003 17:24, David Haller wrote:
Am Mon, 20 Oct 2003, Kristian Köhntopp schrieb:
5. DROP sollte man in Firewall-Regeln generell nicht nehmen. Besser ist ein REJECT mit einem ICMP Code 3, Subcode 10 (administratively prohibited).
# iptables -P FORWARD REJECT iptables: Bad policy name
Als Policy geht ein "REJECT" nicht (zumindest bis inkl. iptables 1.2.4). Und hier ging es um die Policy...
Sieht ganz so aus. Meine fwbuilder-generierten Rules haben auch als Default-Policy DROP stehen, die aber von der CATCHALL final rule überschattet werden. Chain RULE_13 (3 references) target prot opt source destination LOG all -- anywhere anywhere LOG level info prefix `CATCHALL -- DROP ' REJECT all -- anywhere anywhere reject-with icmp-host-prohibited Kristian -- http://www.amazon.de/exec/obidos/wishlist/18E5SVQ5HJZXG
David Haller wrote:
Am Mon, 20 Oct 2003, Kristian Köhntopp schrieb:
5. DROP sollte man in Firewall-Regeln generell nicht nehmen. Besser ist ein REJECT mit einem ICMP Code 3, Subcode 10 (administratively prohibited).
Als Policy geht ein "REJECT" nicht
Kann es auch nicht, weil ja nur fuer UDP und TCP ein reject richtig Sinn macht. Man stelle sich vor auf ein ICMP network-administrative-prohibited wuerdest du ein ebensolches Paket wieder hinausschicken. -- Have fun, Peter
Thomas Broer wrote:
so erhalte ich von dem Telnet-Server erst ca. 10 Sekunden nach Anforderung das login.
Kann mir jemand diesen Umstand erklären?
Telnet, SMTP und Dienste wie IRC schicken vom Server an den Client einen auth-Request. Wenn die Policy auf Accept steht, wird kurze Zeit spaeter der Request beantwortet oder ein Reject-Paket geschick, weil der identd nicht laeuft. Wahrscheinlich funktioniert bei dir die Default-Policy DROP erst dann, wenn du ein "iptables -p tcp --dport auth -j REJECT --reject-with tcp-reset" mit aufnimmst. Bei Problemen wie diesen helfen auch -j LOG Regeln, damit du die abgelehnten Pakete ueberhaupt mal zu Gesicht bekommst. -- Have fun, Peter
participants (6)
-
Alex Klein -
Alfred Reinhard -
David Haller -
Kristian Köhntopp -
Peter Wiersig -
Thomas Broer