[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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. 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
> habe.

Ok. Wobei ich nicht blocken sondern rejecten würde.


Gruß
-Jörg



Reply to: