m43stro 10 Geschrieben 31. Januar 2006 Melden Teilen Geschrieben 31. Januar 2006 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? Zitieren Link zu diesem Kommentar
Wordo 11 Geschrieben 31. Januar 2006 Melden Teilen Geschrieben 31. Januar 2006 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. Zitieren Link zu diesem Kommentar
grizzly999 11 Geschrieben 31. Januar 2006 Melden Teilen Geschrieben 31. Januar 2006 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 Zitieren Link zu diesem Kommentar
m43stro 10 Geschrieben 31. Januar 2006 Autor Melden Teilen Geschrieben 31. Januar 2006 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.. Zitieren Link zu diesem Kommentar
grizzly999 11 Geschrieben 31. Januar 2006 Melden Teilen Geschrieben 31. Januar 2006 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 Zitieren Link zu diesem Kommentar
m43stro 10 Geschrieben 31. Januar 2006 Autor Melden Teilen Geschrieben 31. Januar 2006 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/ Zitieren Link zu diesem Kommentar
Wordo 11 Geschrieben 31. Januar 2006 Melden Teilen Geschrieben 31. Januar 2006 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 ;) Zitieren Link zu diesem Kommentar
s21it21 10 Geschrieben 31. Januar 2006 Melden Teilen Geschrieben 31. Januar 2006 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 Zitieren Link zu diesem Kommentar
m43stro 10 Geschrieben 31. Januar 2006 Autor Melden Teilen Geschrieben 31. Januar 2006 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? Zitieren Link zu diesem Kommentar
BuzzeR 10 Geschrieben 31. Januar 2006 Melden Teilen Geschrieben 31. Januar 2006 @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 Zitieren Link zu diesem Kommentar
s21it21 10 Geschrieben 31. Januar 2006 Melden Teilen Geschrieben 31. Januar 2006 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 Zitieren Link zu diesem Kommentar
Wordo 11 Geschrieben 31. Januar 2006 Melden Teilen Geschrieben 31. Januar 2006 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. Zitieren Link zu diesem Kommentar
m43stro 10 Geschrieben 31. Januar 2006 Autor Melden Teilen Geschrieben 31. Januar 2006 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. Zitieren Link zu diesem Kommentar
Wordo 11 Geschrieben 31. Januar 2006 Melden Teilen Geschrieben 31. Januar 2006 Ich wuerde vorschlagen du oeffnest die Eigenschaften der eingehenden DNS-Regel und postest die Konfiguration (evtl. auch Screenshots). Dann wird sich sicher alles klaeren ... Zitieren Link zu diesem Kommentar
Klettermaxx 10 Geschrieben 31. Januar 2006 Melden Teilen Geschrieben 31. Januar 2006 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. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.