Re: OT: Bind-Verständnisfrage, oder: Wo kommt plötzlich die Meldung her?
Hi! Am Thu, 03 Aug 2006 14:14:58 +0200 schrieb Joerg Zimmermann [EMAIL PROTECTED]: Ich konnte nur folgendes zu den anderen System herausfinden. secureserver.net scheint ein Provider zu sein. Ich habe das System nicht gescannt, es scheint aber ein BSD-Unix zu sein. So weit ich das gesehen habe bietet secureserver.net anonymen Webspace an. Ausserdem stehen die Systeme von denen teilweise auf Blacklists. Ah! Das bringt mich auf die Idee, was es sein könnte. Es könnte einer der Server sein, zu dem mein Tor-Client einen circuit aufbaut. Ich nutze Tor seit der Umstellung von licq auf gaim, um meine IP zu verschleiern, da gaim das leider nicht kann. Ich versuche mal zu verifizieren, ob ich das in irgend einer Log finde. Nein, so Du keine Dienste nach Aussen hin anbietest, sollten alle Ports von Aussen geschlossen sein, mit Ausnahme von ICMP. Aber von Innen sollten die Ports 53 (tcp/udp) geöffnet sein. Wenn Dein Router Zustandsbasiert filtert, kommen alle Packete die in diesem Kontext von Aussen ankommen auch durch. Ja, so läuft es eigentlich auch bei mir. Daher stellt sich also dennoch noch die Frage, warum bloß der Timeout zustande kommt. Hmmm... Hmm, da die Router irgendwie alle für bestimmte Dinge verschiedene - teilweise aus dem Zusammenhang gerissene - Fachbegriffe für gewisse Dinge nutzen, bin ich in der Hinsicht mit diesen Begriffen etwas verwirrt. Nicht nur Du. Das beruhigt mich. :-) Um aber Deine Frage zu beantworten: Mein Router blockt fast alles außer ein paar wenige Ports, die ich mir (z.B. für SSH) nach außen freigegeben habe. Ok. Wobei ich nicht blocken sondern rejecten würde. Das kann ich im Router leider nicht beeinflussen. LG, Ace -- () ASCII Ribbon Campaign - against HTML mail /\- against Microsoft attachments http://www.efn.no/html-bad.html http://www.goldmark.org/netrants/no-word/attach.html signature.asc Description: PGP signature
Re: OT: Bind-Verständnisfrage, oder: Wo kommt plötzlich die Meldung her?
Hi! Am Thu, 03 Aug 2006 14:14:58 +0200 schrieb Joerg Zimmermann [EMAIL PROTECTED]: Besser wäre $ tcpdump -v -i eth0 host 68.178.211.201 -w /root/tcpdump.dump Ist ja klar. Jetzt, wo der tcpdump läuft, bekomme ich die Meldung seit 18 Stunden nicht mehr. :-\ LG, Ace -- () ASCII Ribbon Campaign - against HTML mail /\- against Microsoft attachments http://www.efn.no/html-bad.html http://www.goldmark.org/netrants/no-word/attach.html signature.asc Description: PGP signature
Re: OT: Bind-Verständnisfrage, oder: Wo kommt plötzlich die Meldung her?
Hi, Ace Dahlmann wrote: Hi! Am Thu, 03 Aug 2006 14:14:58 +0200 schrieb Joerg Zimmermann [EMAIL PROTECTED]: Besser wäre $ tcpdump -v -i eth0 host 68.178.211.201 -w /root/tcpdump.dump Ist ja klar. Jetzt, wo der tcpdump läuft, bekomme ich die Meldung seit 18 Stunden nicht mehr. :-\ schade, aber vielleicht hilft das ja auch schon. -Jörg -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: OT: Bind-Verständnisfrage, oder: Wo kommt plötzlich die Meldung her?
Hi Ace, Ace Dahlmann wrote: [..]. elbereth:~# tcpdump tcp port 53 8 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 00:49:15.401561 IP elbereth.intern.dahlmann.net.57196 ip-68-178-211-201.ip.secureserver.net.domain: S 324446473:324446473(0) win 5840 mss 1460,sackOK,timestamp 594682738 0,nop,wscale 0 00:49:15.588176 IP ip-68-178-211-201.ip.secureserver.net.domain elbereth.intern.dahlmann.net.57196: S 2056054616:2056054616(0) ack 324446474 win 5840 mss 1452,sackOK,timestamp 594682738 0,nop,wscale 0 00:49:15.588286 IP elbereth.intern.dahlmann.net.57196 ip-68-178-211-201.ip.secureserver.net.domain: . ack 1 win 5840 nop,nop,timestamp 594682925 594682738 00:49:15.588804 IP elbereth.intern.dahlmann.net.57196 ip-68-178-211-201.ip.secureserver.net.domain: P 1:60(59) ack 1 win 5840 nop,nop,timestamp 594682926 594682738 330% [1au][|domain] 00:49:15.772734 IP ip-68-178-211-201.ip.secureserver.net.domain $ host ip-64-202-165-202.secureserver.net Host ip-64-202-165-202.secureserver.net not found: 3(NXDOMAIN) elbereth.intern.dahlmann.net.57196: R 1:1(0) ack 1 win 5840 nop,nop,timestamp 594682925 594682738 00:49:16.014073 IP elbereth.intern.dahlmann.net.57197 ip-64-202-165-202.secureserver.net.domain: S 322018682:322018682(0) win 5840 mss 1460,sackOK,timestamp 594683351 0,nop,wscale 0 00:49:16.201716 IP ip-64-202-165-202.secureserver.net.domain elbereth.intern.dahlmann.net.57197: S 1869801305:1869801305(0) ack 322018683 win 5840 mss 1452,sackOK,timestamp 594683351 0,nop,wscale 0 00:49:16.201810 IP elbereth.intern.dahlmann.net.57197 ip-64-202-165-202.secureserver.net.domain: . ack 1 win 5840 nop,nop,timestamp 594683539 594683351 00:49:16.202267 IP elbereth.intern.dahlmann.net.57197 ip-64-202-165-202.secureserver.net.domain: P 1:60(59) ack 1 win 5840 nop,nop,timestamp 594683539 594683351 40868% [1au][|domain] 00:49:16.387429 IP ip-64-202-165-202.secureserver.net.domain elbereth.intern.dahlmann.net.57197: R 1:1(0) ack 1 win 5840 nop,nop,timestamp 594683539 594683351 8 Hmm, die IPs sagen mir übrigens gar nichts. Ich hab die URLs, die ich eben aufgerufen habe, überprüft; da scheint nichts dergleichen dabei gewesen zu sein (also auch nicht auf den Links der Seiten). Allerdings heißt das wahrscheinlich nichts, denn ich bekomme die Log-Meldungen auch zu Zeiten, in denen hier wirklich NIEMAND ist, von daher könnte ich mir vorstellen, dass Spamassassin das auch mit einem seiner Checks hervorrufen könnte. Ich konnte nur folgendes zu den anderen System herausfinden. secureserver.net scheint ein Provider zu sein. Ich habe das System nicht gescannt, es scheint aber ein BSD-Unix zu sein. So weit ich das gesehen habe bietet secureserver.net anonymen Webspace an. Ausserdem stehen die Systeme von denen teilweise auf Blacklists. Hilft Dir der TCP-Dump irgendwie? Nicht wirklich. Da sieht man nicht genug. Besser wäre $ tcpdump -v -i eth0 host 68.178.211.201 -w /root/tcpdump.dump Damit logs Du alle Packete komplett. Eventuel steht in der Payload irgendwo eine Fehlermeldung vom System gegenüber. Ausserdem wäre es natürlich interessant zu wissen, _warum_ die Namensauflösung über TCP läuft. Also alles was sonst noch zu diesem Rechner geht, könnte interessant sein. Insbesondere auch IP, UDP und ICMP. Auffällig ist übrigens, dass die beiden Meldungen immer genau mit einer Sekunde Abstand aufeinander folgen. Ich habe das gerade mal mit den anderen Log-Einträgen verglichen, das ist in der Tat immer so. Naja, timeouts eben. [..] Du solltest TCP [53] schon zulassen. Auch nach außen völlig freigegeben? Nein, so Du keine Dienste nach Aussen hin anbietest, sollten alle Ports von Aussen geschlossen sein, mit Ausnahme von ICMP. Aber von Innen sollten die Ports 53 (tcp/udp) geöffnet sein. Wenn Dein Router Zustandsbasiert filtert, kommen alle Packete die in diesem Kontext von Aussen ankommen auch durch. Außerdem stealtht mein Router nicht, sondern blockt. Also eigentlich Wenn Du z.B. ssh nach Aussen hin anbietest, ist Dein Rechner auch sichtbar. Dann wäre ein REJECT besser als ein DROP. könnte Bind doch auf seinem eigenen Anfrage-Weg auch etwas zurück bekommen, oder? Keine Ahnung was Du meinst, _was_ blockt Dein Server denn genau? Hmm, da die Router irgendwie alle für bestimmte Dinge verschiedene - teilweise aus dem Zusammenhang gerissene - Fachbegriffe für gewisse Dinge nutzen, bin ich in der Hinsicht mit diesen Begriffen etwas verwirrt. Nicht nur Du. Bei mir im Router ist das dort sog. SPI + Anti-DoS ausgeschaltet. Das verhindert erstmal, dass man beim Scannen über z.B. scan.sygate.com nur noch blocked. Das macht es mir dann auch möglich, in den Router-Einstellungen einzelne Ports für einzelne IPs nach außen freizugeben. Nach meiner Erfahrung lässt dies dann auch Kommunikation zu, die über Stealth GAR nicht gehen. Z.B.
OT: Bind-Verständnisfrage, oder: Wo kommt plötzlich die Meldung her?
Hallo zusammen, ich komme mal wieder mit einer Debian-unspezifischen Frage um die Ecke: Seit ein paar Tagen bekomme ich plötzlich solche Nachrichten über logcheck zugesandt: --8-- Aug 2 13:17:00 elbereth named[27143]: dispatch 0x819b830: shutting down due to TCP receive error: connection reset --8-- Beim Googlen fand ich das hier dazu heraus: [1], [2] Die Situation bei mir ist fast derer von [1] gleich. Ich benutze den Bind also nur hier für mein lokales Netz sowie als Cache für außen. Nun steht ja in [2], dass das ganz normal ist und wahrscheinlich TCP-Port 53 offen sein müsste. Was ich aber nicht verstehe: Logcheck und Bind laufen bei mir beide seit vielen Monaten und erst seit dem 31. habe ich täglich diese Meldungen. Was ist denn plötzlich anders? Außerdem stealtht mein Router nicht, sondern blockt. Also eigentlich könnte Bind doch auf seinem eigenen Anfrage-Weg auch etwas zurück bekommen, oder? Woanders hatte ich noch gelesen, dass diese Meldungen bei bind ganz normal sind (was sich allerdings mit [2] widerspricht). Aber wie gesagt: Seit Dezember tauchen sie nun das allererste Mal auf. Und mal eine Nebenfrage: Was genau ist eigentlich 0x819b830? Das ist immer gleich. Ist das eine Anfrage-ID so wie die IDs bei Mailspool-Jobs? Bevor ich bind gestern mal neugestartet habe, war es immer 0x816aac8. Installiert ist bind9 auf Sarge in einer Changeroot, wie gesagt, seit Monaten gleich. [1] http://archive.netbsd.se/?ml=bind-usersa=2005-10m=1432849 [2] http://archive.netbsd.se/?ml=bind-usersa=2005-10m=1433159 Irgendwelche Ideen oder gar Erfahrungen zu dispatch-Fehlern? -- () ASCII Ribbon Campaign - against HTML mail /\- against Microsoft attachments http://www.efn.no/html-bad.html http://www.goldmark.org/netrants/no-word/attach.html signature.asc Description: PGP signature
Re: OT: Bind-Verständnisfrage, oder: Wo kommt plötzlich die Meldung her?
Hi Ace, Ace Dahlmann wrote: Hallo zusammen, ich komme mal wieder mit einer Debian-unspezifischen Frage um die Ecke: Seit ein paar Tagen bekomme ich plötzlich solche Nachrichten über logcheck zugesandt: --8-- Aug 2 13:17:00 elbereth named[27143]: dispatch 0x819b830: shutting down due to TCP receive error: connection reset Könntest Du davon einen tcpdump-Mitschnitt senden? Ich denke das liegt nicht an Deinem BIND, sondern an der Gegenseite. Möglicherweise baut die Gegenseite die Verbindung nicht korrekt ab. Das sollte aber keine negativen Auswirkungen auf Dein System haben. Beim Googlen fand ich das hier dazu heraus: [1], [2] Die Situation bei mir ist fast derer von [1] gleich. Ich benutze den Bind also nur hier für mein lokales Netz sowie als Cache für außen. Nun steht ja in [2], dass das ganz normal ist und wahrscheinlich TCP-Port 53 offen sein müsste. Du solltest TCP [53] schon zulassen. Was ich aber nicht verstehe: Logcheck und Bind laufen bei mir beide seit vielen Monaten und erst seit dem 31. habe ich täglich diese Meldungen. Was ist denn plötzlich anders? Wenn der Nameserver eine Antwort auf eine Anfrage eines Resolvers liefert die groesser 512 Bytes wäre, so wird der Nameserver das TC-Bit im Flag-Feld des DNS Packetes setzen und nur die ersten 512Bytes senden. Das veranlasst den Resolver seinerseits eine erneute Anfrage über TCP zu stellen. Es muss sich also auf Deinem System nichts geändert haben. Außerdem stealtht mein Router nicht, sondern blockt. Also eigentlich könnte Bind doch auf seinem eigenen Anfrage-Weg auch etwas zurück bekommen, oder? Keine Ahnung was Du meinst, _was_ blockt Dein Server denn genau? Woanders hatte ich noch gelesen, dass diese Meldungen bei bind ganz normal sind (was sich allerdings mit [2] widerspricht). Aber wie gesagt: Seit Dezember tauchen sie nun das allererste Mal auf. Und mal eine Nebenfrage: Was genau ist eigentlich 0x819b830? Das ist immer gleich. Ist das eine Anfrage-ID so wie die IDs bei Mailspool-Jobs? Bevor ich bind gestern mal neugestartet habe, war es immer 0x816aac8. Eher nicht, weiss ich aber nicht so genau. Könnte das was mit der PID zu tun haben? -Jörg -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: OT: Bind-Verständnisfrage, oder: Wo kommt plötzlich die Meldung her?
Hi! Am Wed, 02 Aug 2006 21:26:44 +0200 schrieb Joerg Zimmermann [EMAIL PROTECTED]: Könntest Du davon einen tcpdump-Mitschnitt senden? Ok, hab auch direkt einen Treffer gelandet (das Ganz kommt nämlich nur so 1-3 mal pro Stunde vor. Aus /var/log/daemon.log: 8 Aug 3 00:49:15 elbereth named[27143]: dispatch 0x82177a8: shutting down due to TCP receive error: connection reset Aug 3 00:49:16 elbereth named[27143]: dispatch 0x82177a8: shutting down due to TCP receive error: connection reset 8 elbereth:~# tcpdump tcp port 53 8 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 00:49:15.401561 IP elbereth.intern.dahlmann.net.57196 ip-68-178-211-201.ip.secureserver.net.domain: S 324446473:324446473(0) win 5840 mss 1460,sackOK,timestamp 594682738 0,nop,wscale 0 00:49:15.588176 IP ip-68-178-211-201.ip.secureserver.net.domain elbereth.intern.dahlmann.net.57196: S 2056054616:2056054616(0) ack 324446474 win 5840 mss 1452,sackOK,timestamp 594682738 0,nop,wscale 0 00:49:15.588286 IP elbereth.intern.dahlmann.net.57196 ip-68-178-211-201.ip.secureserver.net.domain: . ack 1 win 5840 nop,nop,timestamp 594682925 594682738 00:49:15.588804 IP elbereth.intern.dahlmann.net.57196 ip-68-178-211-201.ip.secureserver.net.domain: P 1:60(59) ack 1 win 5840 nop,nop,timestamp 594682926 594682738 330% [1au][|domain] 00:49:15.772734 IP ip-68-178-211-201.ip.secureserver.net.domain elbereth.intern.dahlmann.net.57196: R 1:1(0) ack 1 win 5840 nop,nop,timestamp 594682925 594682738 00:49:16.014073 IP elbereth.intern.dahlmann.net.57197 ip-64-202-165-202.secureserver.net.domain: S 322018682:322018682(0) win 5840 mss 1460,sackOK,timestamp 594683351 0,nop,wscale 0 00:49:16.201716 IP ip-64-202-165-202.secureserver.net.domain elbereth.intern.dahlmann.net.57197: S 1869801305:1869801305(0) ack 322018683 win 5840 mss 1452,sackOK,timestamp 594683351 0,nop,wscale 0 00:49:16.201810 IP elbereth.intern.dahlmann.net.57197 ip-64-202-165-202.secureserver.net.domain: . ack 1 win 5840 nop,nop,timestamp 594683539 594683351 00:49:16.202267 IP elbereth.intern.dahlmann.net.57197 ip-64-202-165-202.secureserver.net.domain: P 1:60(59) ack 1 win 5840 nop,nop,timestamp 594683539 594683351 40868% [1au][|domain] 00:49:16.387429 IP ip-64-202-165-202.secureserver.net.domain elbereth.intern.dahlmann.net.57197: R 1:1(0) ack 1 win 5840 nop,nop,timestamp 594683539 594683351 8 Hmm, die IPs sagen mir übrigens gar nichts. Ich hab die URLs, die ich eben aufgerufen habe, überprüft; da scheint nichts dergleichen dabei gewesen zu sein (also auch nicht auf den Links der Seiten). Allerdings heißt das wahrscheinlich nichts, denn ich bekomme die Log-Meldungen auch zu Zeiten, in denen hier wirklich NIEMAND ist, von daher könnte ich mir vorstellen, dass Spamassassin das auch mit einem seiner Checks hervorrufen könnte. Hilft Dir der TCP-Dump irgendwie? Auffällig ist übrigens, dass die beiden Meldungen immer genau mit einer Sekunde Abstand aufeinander folgen. Ich habe das gerade mal mit den anderen Log-Einträgen verglichen, das ist in der Tat immer so. Ich denke das liegt nicht an Deinem BIND, sondern an der Gegenseite. Möglicherweise baut die Gegenseite die Verbindung nicht korrekt ab. Das sollte aber keine negativen Auswirkungen auf Dein System haben. OK, schonmal beruhigend. Du solltest TCP [53] schon zulassen. Auch nach außen völlig freigegeben? Außerdem stealtht mein Router nicht, sondern blockt. Also eigentlich könnte Bind doch auf seinem eigenen Anfrage-Weg auch etwas zurück bekommen, oder? Keine Ahnung was Du meinst, _was_ blockt Dein Server denn genau? Hmm, da die Router irgendwie alle für bestimmte Dinge verschiedene - teilweise aus dem Zusammenhang gerissene - Fachbegriffe für gewisse Dinge nutzen, bin ich in der Hinsicht mit diesen Begriffen etwas verwirrt. Bei mir im Router ist das dort sog. SPI + Anti-DoS ausgeschaltet. Das verhindert erstmal, dass man beim Scannen über z.B. scan.sygate.com nur noch blocked. Das macht es mir dann auch möglich, in den Router-Einstellungen einzelne Ports für einzelne IPs nach außen freizugeben. Nach meiner Erfahrung lässt dies dann auch Kommunikation zu, die über Stealth GAR nicht gehen. Z.B. habe ich letztens gemerkt, dass man sich zu einem BOINC-Projekt nicht hinzufügen kann, wenn der Router auf Stealth steht. Auch die Kommunikation zu Razor2 und DCC (durch Spamassassin) funktioniert so. Bei richtigen Firewalls in Firmen musste ich dort spezielle Ports per iptables noch freigeben, bei meinem Router muss ich das nicht. Da ich seeehr lange ISDN hatte und noch nicht soo lange Router-erfahren bin, hört da meine Kenntnis, wann nun welcher Port nur bei einer Anfrage geöffnet wird und wann gar nicht, usw, auch leider schon auf. :o) Um aber Deine Frage zu beantworten: Mein Router blockt fast alles außer ein paar wenige Ports, die ich mir (z.B. für SSH) nach außen freigegeben
