Verständnissfrage zu Firewall / PORTS Regeln

[m43stro 10]

Hallo Leute,

 

sitze hier im LAN mit einer Softwarefirewall AtGuard und teste rum.

Möchte ich z.B. mit Firefox surfen, muss ich den 80HTTP und 443HTTPS auf dem Remoterechner ausgehend zulassen.

 

Es reicht dann aber auch und ich kann wunderbar surfen.

 

z.B. bei DNS sieht es schon wieder anders aus.

Da muss ich den 53 UDP auf dem Remoterechner in BEIDE Richtungen zulassen, sowohl ausgehen, als auch ankommen.

 

Warum eigentlich ankommen? Ich bin je kein DNS Server, sondern will nur Surfen.

 

Warum verlangen machen Protokolle wie Dienste wie Ping, DNS, FTP Regeln in beide Richtungen und z.B. HTTP MICROSOFT-DS nicht?

[Wordo 11]

Weil das eine Protokoll (HTTP/S) auf TCP basiert (verbindungsorientiert) und DNS auf UDP. FTP ist wieder ne eigene Geschichte, da werden dann die Ports gewechselt. Such mal bei wikipedia nach TCP/IP, DNS und FTP. Da wird dir das in Kurzform recht gut erklaert.

[grizzly999 11]

Weil das eine Protokoll (HTTP/S) auf TCP basiert (verbindungsorientiert) und DNS auf UDP. .

Damit hat das so ziemlich gar nichts zu tun, eher damit, dass entweder eine Fehlbedienung vorliegt oder das dass eine seltsame Firewall ist (ich kene sie nicht).

Ich habe an "richtigen " Firewalls im Leben noch keinen Port 53 UDP eingehend aufmachen müssen, um nach draussen eine Namensauflösung zu erhalten

 

 

grizzly999

[m43stro 10]

Damit hat das so ziemlich gar nichts zu tun, eher damit, dass entweder eine Fehlbedienung vorliegt oder das dass eine seltsame Firewall ist (ich kene sie nicht).

Ich habe an "richtigen " Firewalls im Leben noch keinen Port 53 UDP eingehend aufmachen müssen, um nach draussen eine Namensauflösung zu erhalten

 

 

grizzly999

 

es ist ja nicht so, dass ich mich mit den Diensten nicht auskenne, aber die Erfahrung, die grizzly gemacht hat, habe ich uach.

 

Ich vermute, dass die Firewall einfach noch tiefgründiger reingeht und sogar die Rückkommende DNS Pakete filtert.

 

Warum nur nicht die HTTP Pakete?

 

AtGuard ist 98 bzw. 99 entwickelt worden.

Paketfilter, Webfilter, Coockies -> total genial, klein und performsparrend.

 

Aber kommen wir zum eigentlichem Problem..

[grizzly999 11]

Ich vermute, dass die Firewall einfach noch tiefgründiger reingeht und sogar die Rückkommende DNS Pakete filtert.

Das tut sie hoffentlich auch, das tut jede Firewall mit Stateful Inspektion, was di AT hoffentlich ist. ABER: Die Antwortpakete gehen nicht an den Port 53 UDP, sondern an irgend einen HighPort, den sich dein DNS-Client ausgesucht hat.

 

Aber kommen wir zum eigentlichem Problem..

Da kann ich leider nichts dazu beitragen, ich kenne die Firewall nicht, aber du kannst die Regel mal korrekt setzen (wie sie gehören würde) und dann ins Log schauen

 

grizzly999

[m43stro 10]

Da kann ich leider nichts dazu beitragen, ich kenne die Firewall nicht, aber du kannst die Regel mal korrekt setzen (wie sie gehören würde) und dann ins Log schauen

 

grizzly999

 

 

Habe es gerade nochmal versucht, aber irgendwie logt sie das nicht mit.

TCP View kann ich auch nichte erkenne.

 

Die Firewall gibt es unter http://www.maxtroy.host.sk/

[Wordo 11]

Damit hat das so ziemlich gar nichts zu tun, eher damit, dass entweder eine Fehlbedienung vorliegt oder das dass eine seltsame Firewall ist (ich kene sie nicht).

Ich habe an "richtigen " Firewalls im Leben noch keinen Port 53 UDP eingehend aufmachen müssen, um nach draussen eine Namensauflösung zu erhalten

 

 

grizzly999

 

"Da muss ich den 53 UDP auf dem Remoterechner in BEIDE Richtungen zulassen, sowohl ausgehen, als auch ankommen."

 

Quell- und Zielport ist in dem Satz nicht angegeben. Bei iptables muss man auch eine Rueckregel einrichten (eben halt mit den Ports vertauscht), wieso sollte es da nicht genauso sein?

 

"Warum verlangen machen Protokolle wie Dienste wie Ping, DNS, FTP Regeln in beide Richtungen und z.B. HTTP MICROSOFT-DS nicht?"

 

Und da ist es doch genau dasselbe: ICMP und DNS, und der "Sonderfall" FTP.

 

Ich wuerde also eher auf eine seltsame Firewall (so ziemlich alle Software Firewalls) tippen ;)

[s21it21 10]

Hallo,

 

Die AT-Gaurd-FW ist so wie die meisten Software-Firewalls Schrott bzw. ist nur ein Paketfilter und nicht mehr. Dass TCP verbindungsorientiert ist und UPD nicht stimmt schon, hat aber primär nichts mit dem Verhalten der FW zu tun (mit dieser FW).

 

Kurz die Info:

 

Viele Paketfilter-FWs (so wie AT-Guard) filtern den Traffic auf Grund von Quell/Ziel-IP und Port. Dass dabei die Daten auch wieder zurück müssen ist diesen Dingern mal egal. Und das ist das Problem. Bei bekannten Protokollen oder bei gänigen checken die Dinger das noch, aber dann eben nicht mehr.

 

Eine StateFull-Firewall schreibt sich die Verbindungen in eine eigene Tabelle und schaltet impliziet den Rückverkehr wieder frei (aber eben nur für diese eine Verbindung und nicht global und auch nicht dauerhaft). Das is eben der grosse Unterschied.

 

Solche Paketfilterfirewalls sind dann natürlich extrem mühselig und unübersichtlich bzw. sind auch nicht mehr State-of-the-art.

Im Heimbereich sind diese Dinger aber noch sehr verbreitet. Ich pers. rate von solchen FWs ab.

 

lg

Martin

[m43stro 10]

Dass dabei die Daten auch wieder zurück müssen ist diesen Dingern mal egal. Und das ist das Problem. Bei bekannten Protokollen oder bei gänigen checken die Dinger das noch, aber dann eben nicht mehr.

 

Komisch HTTP und DNS sind ja beide bekannt, dennoch muss man DNS in beide Richtungen zulassen.

Statefullfirewall kann man sich nicht immer Leisten.

Und sicher ein DLINK Router habe ich ja auch. Aber er zeigt mir nicht welche Programme ins INET wollen.

 

Kennst Du evtl. eine gute Alternative zu AtGuard?

[BuzzeR 10]

@m43stro

 

Es ist genau so, wie grizzly999 geschildert hat. Völlig ungeachtet ob nun TCP, oder

UDP, jede Netzwerkapplikation fordert beim OS eine Portnummer an und bekommt

diese dann zugewiesen. Sowohl TCP, als auch UDP - Applikationen identifizieren sich

durch ihre RECHNER-IP/PORTNUMMERN-Kombination.

 

Bei den gängigen Diensten sieht das dann anders aus, sie arbeiten i. d. R. auf den

Well-Known-Ports, kurz WKP. Diese wurden standardisiert und liegen im Bereich von 0-1024.

Sie werden auch als Systemports bezeichnet und die Standardisierung hat zur Folge,

dass ein Client sehr wohl weiß, welchen Port er auf dem Zielsystem ansprechen muß, um

die nötige Antwort zu erhalten. Soll also heißen, dass diese auf den jeweiligen Ports

lauschen (LISTEN) und auf Anfragen warten.

 

Hier liegen also Verständnisprobleme zu der grundlegenden Arbeitsweise von TCP/IP-

Implementierungen vor. Dazu empfehle ich das Buch ...

 

TCP / IP - Konzepte, Protokolle und Architekturen

Douglas E. Comer

mitp - Verlag

3-8266-0995-6

58,00 €

 

Ich habe hier Auflage 4, ob diese noch aktuell ist weiß ich nicht, doch sie ist trotz der

ungemein trockenen Schreibweise ein Fundus an Informationen bezgl. der Arbeitsweise

der TCP/IP-Protokoll-Suite.

 

Des weiteren wären sicherlich die RFCs zu den jeweiligen Protokollen sehr hilfreich.

Check out: http://www.faqs.org/rfcs

 

Ich wüßte auch nicht, wieso FTP ein Sonderfall sein sollte, denn es ist auch nur ein

weiteres Protokoll auf Anwendungsebene ... nicht mehr und nicht weniger. Und auch

DNS muß man nicht eingehend freischalten, wäre ja wider des Sinns von TCP/IP.

Eingehend Port 53 wäre nur dann sinnvoll, wenn Dein Rechner DNS-Server

wäre und das ist er ja nicht. Mal ganz davon abgesehen, dass wohl DNS eher der

Sonderfall ist, weil es sowohl auf UDP - Port 53, als auch auf TCP - Port 53 lauscht.

 

Ist dann wohl eher eine sehr suspekte Firewall, die Du da betreibst. ;)

 

LG

Marco

[s21it21 10]

Hallo,

 

Wie schon gesagt, es kommt vor, dass man DNS sehr wohl in beide Richtungen freischalten muss. Das liegt aber natürlich nicht an DNS sonder dann an der Firewall. Bei diesen Firewalls muss man dan so ziemlich jeden "Rückverkehr" freischalten. Das geht dann so weit, dass man Outbound (vom Client ins Internet) alle high-ports freischaltet. Und das ist absolut unsicher.

 

FTP ist auf gar keinen Fall ein "normales" Protokoll (wobei "normal" relativ ist und davon abgesehen, dass es ein vollkommen unsicheres Protokoll ist). Es gibt sehr viele Firewalls die damit Probleme haben (gute natürlich nicht). FTP-Datenverker muss eine Firewall wirklich beherrschen und "verstehen". Es kommt ja darauf an, ob man passiv- oder active-ftp verwendet. Und wenn das die Firewall nicht beherrscht, dann wird es sehr unangenehm (es gibt viele Firewalls die nur eine Art unterstützen).

 

Das beste Programm, dass Dir anzeigt, welche Verbindungen Dein PC macht ist noch immer:

"netstat -an". Da siehst Du sämtliche Verbindungen die hergestellt sind bzw. auf die der PC lauscht.

 

lg

Martin

[Wordo 11]

Ich wüßte auch nicht, wieso FTP ein Sonderfall sein sollte, denn es ist auch nur ein

weiteres Protokoll auf Anwendungsebene ... nicht mehr und nicht weniger. Und auch

DNS muß man nicht eingehend freischalten, wäre ja wider des Sinns von TCP/IP.

Eingehend Port 53 wäre nur dann sinnvoll, wenn Dein Rechner DNS-Server

wäre und das ist er ja nicht. Mal ganz davon abgesehen, dass wohl DNS eher der

Sonderfall ist, weil es sowohl auf UDP - Port 53, als auch auf TCP - Port 53 lauscht.

 

http://de.wikipedia.org/wiki/File_Transfer_Protocol

Beim Active Mode baut der Server von seinem Port 20, dem Data Port, eine Datenverbindung zu einem vom Client gewählten Endpunkt auf.

Beim Passive Mode baut der Client eine Datenverbindung zum vom Server gewünschten Port auf. Hier wird typischerweise von beiden Seiten ein Port jenseits 1023 benutzt.

 

Die Ports werden gewechselt, ich bezeichne das mal als Sonderfalls weils bei den anderen von ihm genannten Protokollen nicht der Fall ist.

Und das man bei AT-Guard "eingehend DNS erlauben" muss, sagt noch lange nichts aus wie die Quell- und Zielports in der Regel definiert sind. Da ist in dem Screenshot von AT-guard nur "allow incoming DNS" zu sehen. Ob da jetzt aber sport 53 oder dport 53 drinsteht sieht man ja nicht.

[m43stro 10]

Es ist ja nicht so, dass ich Verständnissprobleme mit TCP/IP habe.

Habe schon OSI hoch und runter gelernt.

 

Es ist eher ein Problem mit der Firewall was ich habe.

 

Wie Du schon gesagt hast, braucht man eben den DNS Port nicht eingehend öffnen, aber bei dieser Firewall schon.

 

Jetzt stellt sich nur die Frage weshalb es die Programmierer gemacht haben und Warum ich das bei dieser Firewall freigeben muss.

 

Fakt ist, wenn ich den DNS mit dieser Firewall nicht öffne geht die Auflösung nicht.

[Wordo 11]

Ich wuerde vorschlagen du oeffnest die Eigenschaften der eingehenden DNS-Regel und postest die Konfiguration (evtl. auch Screenshots). Dann wird sich sicher alles klaeren ...

[Klettermaxx 10]

Nicht um euch noch mehr zu verwirren, aber der Fall kommt mir ziemlich bekannt vor. Normalerweise sollte es ja so sein.

 

Die Firewall sollte, wenn sie eine gute ist eingehende Verbindungen zulassen, sofern sie von innen eröffnet worden sind. Grob gesagt. Bei Cisco habe ich zum Beispiel auch immer das Problem, das der Router keine DNS auflösen kann, sofern die Access-List keinen Port 53 eingehend nach überall erlaubt.

 

Und das obwohl der ip inspect gesetzt ist. Vielleicht hilft das.