(fast) alle ports zu und Namensauflösung funktioniert nicht mehr
Juergen Koenig
Wir haben einen fli4l Router und hinter dem Router unseren Server auf dm die
Dienste http, ssh, vsftp und zope laufen. Bisher waren nur die ports<1024,
bis auf die, die man für diese Dinste braucht, gestealth.
Auf Grund von seltsamen Vorkomnissen habe ich heute versucht alle
1024<ports<65355 zuzumachen. Jetzt funktioniert die Namensauflösung nicht
mehr. Ich kann zwar eine externe IP-Adresse anpingen, aber keine
www-adresse. Mein Routing steht also, aber die Namensauflösung kommt nicht
zurück.
Welchen Port muss ich dafür auflassen?
Anmerkung: Das forwarden der Namensauflösung durch den fli4l Router habe ich
nicht hingekriegt. Deswegen steht der externe-Nameserver in
der /etc/resolv.conf.
Gruss
Jürgen
Christoph Sorge
> Wir haben einen fli4l Router und hinter dem Router unseren Server auf dm die
> Dienste http, ssh, vsftp und zope laufen. Bisher waren nur die ports<1024,
> bis auf die, die man für diese Dinste braucht, gestealth.
Was meinst Du damit?
> Auf Grund von seltsamen Vorkomnissen habe ich heute versucht alle
> 1024<ports<65355 zuzumachen.
Wie hast Du das gemacht?
> Jetzt funktioniert die Namensauflösung nicht
> mehr. Ich kann zwar eine externe IP-Adresse anpingen, aber keine
> www-adresse. Mein Routing steht also, aber die Namensauflösung kommt nicht
> zurück.
>
> Welchen Port muss ich dafür auflassen?
Für DNS braucht man 53 TCP und 53 UDP. Wenn Du wirklich nur Ports > 1024
filterst, dann hast Du vermutlich in den entsprechenden Filterregeln
einen Fehler (z.B. könnte es sein, daß Du die Antwort des DNS-Servers,
die natürlich einen Zielport != 53 hat, nicht durchläßt - das wird aber
aus Deiner Beschreibung nicht klar).
> Anmerkung: Das forwarden der Namensauflösung durch den fli4l Router habe ich
> nicht hingekriegt. Deswegen steht der externe-Nameserver in
> der /etc/resolv.conf.
Das sollte kein Problem darstellen.
Christoph
Juergen Koenig
> Juergen Koenig schrieb:
>
>> Wir haben einen fli4l Router und hinter dem Router unseren Server auf dm
>> die Dienste http, ssh, vsftp und zope laufen. Bisher waren nur die
>> ports<1024, bis auf die, die man für diese Dinste braucht, gestealth.
>
> Was meinst Du damit?
So sehen die Zeilen z.B. in fli4l aus:
FIREWALL_DENY_PORT_3='114:1023 REJECT'
>
>> Auf Grund von seltsamen Vorkomnissen habe ich heute versucht alle
>> 1024<ports<65355 zuzumachen.
>
> Wie hast Du das gemacht?
Die alte Zeile sah so aus und alles funktioniert.
FIREWALL_DENY_PORT_4='1024:9999 REJECT'
Diese habe ich modifiziert, so dass sie so aussieht:
FIREWALL_DENY_PORT_4='1024:65355 REJECT'
und seitdem funktioniert die Namensauflösung nicht mehr.
ping (IP von google) - funktioniert
ping www.google.de - funktioniert nicht
>
>> Jetzt funktioniert die Namensauflösung nicht
>> mehr. Ich kann zwar eine externe IP-Adresse anpingen, aber keine
>> www-adresse. Mein Routing steht also, aber die Namensauflösung kommt
>> nicht zurück.
>>
>> Welchen Port muss ich dafür auflassen?
>
> Für DNS braucht man 53 TCP und 53 UDP. Wenn Du wirklich nur Ports > 1024
> filterst, dann hast Du vermutlich in den entsprechenden Filterregeln
> einen Fehler (z.B. könnte es sein, daß Du die Antwort des DNS-Servers,
> die natürlich einen Zielport != 53 hat, nicht durchläßt - das wird aber
> aus Deiner Beschreibung nicht klar).
Anscheinend habe ich alles zu. Soll ja auch so sein. Hier liegt wohl
anscheinend ein Denkfehler bei mir vor. Wenn ich das also jetzt richtig
verstehe, muss oberhalb von 1024 etwas auf bleiben.
Gruss
Jürgen
Marcel Noe
> Welchen Port muss ich dafür auflassen?
53. TCP und UDP. Eingehend und ausgehend.
Gruss Marcel
Marcel Noe
> Diese habe ich modifiziert, so dass sie so aussieht:
> FIREWALL_DENY_PORT_4='1024:65355 REJECT'
Ganz schlechte Idee. Du brauchst die High Ports um Antworten zu
bekommen. Vor allem Masquerading verwendet Ports über 60000.
Sinnvoller ist es einfach, alle Syn Pakete, die kein ACK enthalten an
diese Ports zu sperren.
Ich habe z.b. soetwas in meinem Firewall Script:
$fwcommand -A FORWARD -p tcp ! --syn -m state --state NEW -j DROP
$fwcommand -A FORWARD -i eth2 -p tcp ! --syn -j ACCEPT
Gruss Marcel
Jan Greve
> 1024<ports<65355 zuzumachen. Jetzt funktioniert die Namensauflösung nicht
> mehr. Ich kann zwar eine externe IP-Adresse anpingen, aber keine
> www-adresse. Mein Routing steht also, aber die Namensauflösung kommt
nicht
> zurück.
warum hast du denn den zugriff von innen nach außen gesperrt? Das ist
unguenstig, da alle protokolle zur wirklichen uebertragung der daten
nich ihren port nehmen, sondern quasi einen "vereinbaren" untereinander,
der irgendwo zwischen 1024 und unendlich liegt. dementsprechend duerfte
eigentlich nichts mehr funktionieren. kannst du denn auf dem router
pingen? (hast du auf deinem rechner den DNS-Server ueberprueft?)
mfg jan
Christoph Sorge
>> Welchen Port muss ich dafür auflassen?
>
> 53. TCP und UDP. Eingehend und ausgehend.
Wieso eingehend?
Christoph
Christoph Sorge
>>> Bisher waren nur die
>>> ports<1024, bis auf die, die man für diese Dinste braucht, gestealth.
>>
>> Was meinst Du damit?
>
> So sehen die Zeilen z.B. in fli4l aus:
> FIREWALL_DENY_PORT_3='114:1023 REJECT'
Das hat allerdings wenig mit "Stealth" zu tun.
>>> Auf Grund von seltsamen Vorkomnissen habe ich heute versucht alle
>>> 1024<ports<65355 zuzumachen.
>>
>> Wie hast Du das gemacht?
>
> Die alte Zeile sah so aus und alles funktioniert.
> FIREWALL_DENY_PORT_4='1024:9999 REJECT'
>
> Diese habe ich modifiziert, so dass sie so aussieht:
> FIREWALL_DENY_PORT_4='1024:65355 REJECT'
Du solltest mal herausfinden, was genau diese Regeln machen (vermutlich
werden daraus iptables-Regeln erzeugt?). Vermutlich werden eingehende
Pakete mit den o.g. Zielports gefiltert. Grundsätzlich keine schlechte
Idee, aber ... (s.u.)
> und seitdem funktioniert die Namensauflösung nicht mehr.
> ping (IP von google) - funktioniert
> ping www.google.de - funktioniert nicht
Wie sieht es mit anderen Diensten aus, die TCP oder UDP verwenden?
>> Für DNS braucht man 53 TCP und 53 UDP. Wenn Du wirklich nur Ports > 1024
>> filterst, dann hast Du vermutlich in den entsprechenden Filterregeln
>> einen Fehler (z.B. könnte es sein, daß Du die Antwort des DNS-Servers,
>> die natürlich einen Zielport != 53 hat, nicht durchläßt - das wird aber
>> aus Deiner Beschreibung nicht klar).
>
> Anscheinend habe ich alles zu. Soll ja auch so sein. Hier liegt wohl
> anscheinend ein Denkfehler bei mir vor. Wenn ich das also jetzt richtig
> verstehe, muss oberhalb von 1024 etwas auf bleiben.
Der Denkfehler liegt wohl im Verständnis der Funktionsweise einiger
Protokolle:
Üblicherweise kommt die Antwort nicht an den Port, der dem Protokoll
zugeordnet ist, sondern an den Quellport der "Anfrage".
Meist erschlägt man das in Firewalls, indem man Zustand aufbaut, sich
also merkt, von wo aus eine Anfrage gesendet wurde. Wie das bei der von
Dir verwendeten Firewall bzw. dem iptables-Konfigurationsskript, das Du
verwendest, geht, entzieht sich meiner Kenntnis - Google mit "stateful
filter" o.ä. könnte da aber weiterhelfen.
Christoph
Marcel Noe
>> 53. TCP und UDP. Eingehend und ausgehend.
>
> Wieso eingehend?
Weil einige DNS Client Implementierungen (besonders die von einer gewissen
Firma aus Redmont) Port 53 als Sourceport für ihre DNS Anfragen nehmen
und man doch Antworten bekommen möchte.
Gruss Marcel
Marcel Noe
Christoph Sorge <chr...@gmx.de> wrote:
> Meist erschlägt man das in Firewalls, indem man Zustand aufbaut, sich
> also merkt, von wo aus eine Anfrage gesendet wurde. Wie das bei der von
> Dir verwendeten Firewall bzw. dem iptables-Konfigurationsskript, das Du
> verwendest, geht, entzieht sich meiner Kenntnis - Google mit "stateful
> filter" o.ä. könnte da aber weiterhelfen.
Die Iptables Option heisst "--state" (also z.b. iptables -A INPUT
--state new -j REJECT).
Gruss Marcel
Christoph Sorge
>>> 53. TCP und UDP. Eingehend und ausgehend.
>>
>> Wieso eingehend?
>
> Weil einige DNS Client Implementierungen (besonders die von einer gewissen
> Firma aus Redmont) Port 53 als Sourceport für ihre DNS Anfragen nehmen
> und man doch Antworten bekommen möchte.
Trotzdem ist es dann doch (modulo DoS) sinnvoller, zustandsbehaftet zu
filtern, damit es nicht nur zufällig funktioniert.
BTW, ich benutze ein OS einer Firma aus Redmond, und als ich das gerade
mal ausprobiert habe, hatte die DNS-Anfrage sinnvollerweise einen
Quellport != 53.
Gruß,
Christoph
Marcel Noe
> Trotzdem ist es dann doch (modulo DoS) sinnvoller, zustandsbehaftet zu
> filtern, damit es nicht nur zufällig funktioniert.
Das Problem ist, dass es bei UDP keine Zustände gibt. Ja, ok, connection
tracking:
iptables -A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT
sollte das selbe tun.
> BTW, ich benutze ein OS einer Firma aus Redmond, und als ich das gerade
> mal ausprobiert habe, hatte die DNS-Anfrage sinnvollerweise einen
> Quellport != 53.
Ja, XP. Probier's mal mit Windows 98.
Gruss Marcel
Juergen Koenig
> Juergen Koenig schrieb:
>
>>>> Bisher waren nur die
>>>> ports<1024, bis auf die, die man für diese Dinste braucht, gestealth.
>>>
>>> Was meinst Du damit?
>>
>> So sehen die Zeilen z.B. in fli4l aus:
>> FIREWALL_DENY_PORT_3='114:1023 REJECT'
>
> Das hat allerdings wenig mit "Stealth" zu tun.
Ich bin jetzt verunsichert, weil ich es in der Schule lange nicht mehr
gemacht habe. Aber wenn ich mit grc.com und shields up die ports testen
lasse, dann werden sie als 'Stealth' und nicht als 'closed' angezeigt.
>>>> Auf Grund von seltsamen Vorkomnissen habe ich heute versucht alle
>>>> 1024<ports<65355 zuzumachen.
>>>
>>> Wie hast Du das gemacht?
>>
>> Die alte Zeile sah so aus und alles funktioniert.
>> FIREWALL_DENY_PORT_4='1024:9999 REJECT'
>>
>> Diese habe ich modifiziert, so dass sie so aussieht:
>> FIREWALL_DENY_PORT_4='1024:65355 REJECT'
>
> Du solltest mal herausfinden, was genau diese Regeln machen (vermutlich
> werden daraus iptables-Regeln erzeugt?). Vermutlich werden eingehende
> Pakete mit den o.g. Zielports gefiltert. Grundsätzlich keine schlechte
> Idee, aber ... (s.u.)
[... gekürzt ....]
> sich
> also merkt, von wo aus eine Anfrage gesendet wurde. Wie das bei der von
> Dir verwendeten Firewall bzw. dem iptables-Konfigurationsskript, das Du
> verwendest, geht, entzieht sich meiner Kenntnis - Google mit "stateful
> filter" o.ä. könnte da aber weiterhelfen.
Dass fli4l aus diesen Konfigurationsfiles, die diese Zeilen enthalten,
Filterregeln für iptables erzeugt, vermute ich auch. Aber die kann ich
weder einsehen noch modifizieren. Das würde auch mein Fähigkeiten bei
weitem übersteigen.
Gruß
Jürgen
Christoph Sorge
>> Trotzdem ist es dann doch (modulo DoS) sinnvoller, zustandsbehaftet zu
>> filtern, damit es nicht nur zufällig funktioniert.
>
> Das Problem ist, dass es bei UDP keine Zustände gibt.
Im Protokoll nicht. Aber in der Firewall.
> Ja, ok, connection
> tracking:
> iptables -A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT
>
> sollte das selbe tun.
Darauf wollte ich hinaus.
>> BTW, ich benutze ein OS einer Firma aus Redmond, und als ich das gerade
>> mal ausprobiert habe, hatte die DNS-Anfrage sinnvollerweise einen
>> Quellport != 53.
>
> Ja, XP. Probier's mal mit Windows 98.
Mein wissenschaftlicher Ehrgeiz hat mich gepackt und dazu getrieben, das
tatsächlich zu tun ;-) Gleiches Verhalten. Allerdings gibt es ja
verschiedene Versionen von Windows 98; vielleicht ist eine davon
wirklich so eigenwillig.
Christoph
Christoph Sorge
>>> So sehen die Zeilen z.B. in fli4l aus:
>>> FIREWALL_DENY_PORT_3='114:1023 REJECT'
>>
>> Das hat allerdings wenig mit "Stealth" zu tun.
>
> Ich bin jetzt verunsichert, weil ich es in der Schule lange nicht mehr
> gemacht habe. Aber wenn ich mit grc.com und shields up die ports testen
> lasse, dann werden sie als 'Stealth' und nicht als 'closed' angezeigt.
Dieses Verhalten erwarte ich eigentlich nur bei "Drop"-Regeln. Aber auch
dann ist der Begriff ihreführend, denn verborgen wird so nichts.
In Sachen Sicherheit macht das allerdings praktisch keinen Unterschied.
>> sich
>> also merkt, von wo aus eine Anfrage gesendet wurde. Wie das bei der von
>> Dir verwendeten Firewall bzw. dem iptables-Konfigurationsskript, das Du
>> verwendest, geht, entzieht sich meiner Kenntnis - Google mit "stateful
>> filter" o.ä. könnte da aber weiterhelfen.
>
> Dass fli4l aus diesen Konfigurationsfiles, die diese Zeilen enthalten,
> Filterregeln für iptables erzeugt, vermute ich auch. Aber die kann ich
> weder einsehen noch modifizieren. Das würde auch mein Fähigkeiten bei
> weitem übersteigen.
Das Problem ist, daß ich fli4l nicht kenne und deshalb auch nicht weiß,
was man in den Konfigurationsfiles genau einstellen muß. Für iptables
findet man Anleitungen an jeder Ecke... Prinzipiell müßte fli4l aber
eigentlich solch eine Basisfunktionalität unterstützen.
Die Anleitung auf
http://www.fli4l.de/german/extern/doku/stable/doc/deutsch/html/index.html
ist in der Hinsicht leider auch nicht besonders aussagekräftig.
Kannst Du Dich denn per SSH oder telnet auf dem Router einloggen und
z.B. den Befehl "iptables -L" ausführen? Die Ausgabe könnte Klarheit
schaffen.
Grüße,
Christoph
Juergen Koenig
Christoph Sorge hat geschrieben:
>> Ich bin jetzt verunsichert, weil ich es in der Schule lange nicht mehr
>> gemacht habe. Aber wenn ich mit grc.com und shields up die ports testen
>> lasse, dann werden sie als 'Stealth' und nicht als 'closed' angezeigt.
>
> Dieses Verhalten erwarte ich eigentlich nur bei "Drop"-Regeln. Aber auch
> dann ist der Begriff ihreführend, denn verborgen wird so nichts.
Wie gesagt. Ich bin mir derzeit auch nicht sicher und kann es erst am Montag
überprüfen. Tut aber auch jetzt nichts zur Sache.
>
> In Sachen Sicherheit macht das allerdings praktisch keinen Unterschied.
> Das Problem ist, daß ich fli4l nicht kenne und deshalb auch nicht weiß,
> was man in den Konfigurationsfiles genau einstellen muß. Für iptables
> findet man Anleitungen an jeder Ecke... Prinzipiell müßte fli4l aber
> eigentlich solch eine Basisfunktionalität unterstützen.
> Die Anleitung auf
> http://www.fli4l.de/german/extern/doku/stable/doc/deutsch/html/index.html
> ist in der Hinsicht leider auch nicht besonders aussagekräftig.
>
> Kannst Du Dich denn per SSH oder telnet auf dem Router einloggen und
> z.B. den Befehl "iptables -L" ausführen? Die Ausgabe könnte Klarheit
> schaffen.
Es gibt ein Modul, so dass man das kann. Dieses Modul habe ich aber nicht
installiert, da bisher kein Bedarf bestand. Werde ich dann wohl als
nächstes mal angehen müssen.
Gruß
Jürgen
Marcel Noe
> Mein wissenschaftlicher Ehrgeiz hat mich gepackt und dazu getrieben, das
> tatsächlich zu tun ;-) Gleiches Verhalten. Allerdings gibt es ja
> verschiedene Versionen von Windows 98; vielleicht ist eine davon
> wirklich so eigenwillig.
Oh! Welches Stück Software hatte ich denn dann in den Fingern, die sich
so verhalten hat? Evtl. war es Bind himself.
Gruss Marcel
Christoph Sorge
[DNS-Anfragen von Quellport 53]
> Oh! Welches Stück Software hatte ich denn dann in den Fingern, die sich
> so verhalten hat? Evtl. war es Bind himself.
Kurze Usenet-Recherche spricht in der Tat dafür, daß ältere
Bind-Versionen (wohl bis Bind4) das so gemacht haben, neuere es aber
nicht mehr standardmäßig tun.
Gruß,
Christoph,
sich freuend, daß hier mal wieder etwas Leben ist.
A propos "hier": Da fällt mir was auf...
Marcel Noe
> Kurze Usenet-Recherche spricht in der Tat dafür, daß ältere
> Bind-Versionen (wohl bis Bind4) das so gemacht haben, neuere es aber
> nicht mehr standardmäßig tun.
Ja. Mir fällt jetzt auch ein, in welchem kaputten Setup der Fehler
aufgetreten ist. Kurzes nachschauen:
// If there is a firewall between you and nameservers you want
// to talk to, you might need to uncomment the
// query-source
// directive below. Previous versions of BIND
// always asked
// questions using port 53, but BIND 8.1
// and later use an unprivileged
// port by default.
// query-source address
// * port 53;
> sich freuend, daß hier mal wieder etwas Leben ist.
Hey, ich kann David Allen als Entschuldigung ins Feld führen.
> A propos "hier": Da fällt mir was auf...
^^
Gruss Marcel
Christoph Sorge
>> sich freuend, daß hier mal wieder etwas Leben ist.
>
> Hey, ich kann David Allen als Entschuldigung ins Feld führen.
?
>> A propos "hier": Da fällt mir was auf...
>
> ^^
Du weißt, worauf ich hinaus will?
Gruß,
Christoph
P.S.: F'up2 poster, da das nun wirklich OT wird...