Debian vServer: UDP-Port 53 auch von aussen erreichbar... wi

[jg1]

Hallo,

ich habe einen vServer, auf dem Debian Sarge läuft.
Es läuft kein DNS-Dienst, sondern nur der Resolver.
Da mein vServer nachträglich einen LO Schnittstelle bekommen hat,
heisst diese nun 127.0.0.37! MySQL und EXIM4 habe ich umkonfiguriert und nun sind diese nur von "Innen" zu erreichen. Aber der Resolver antwortet auch auf Anfragen von Aussen! Wie bzw. wo kann ich das ausschalten?

Danke

Code: Select all

ifconfig:
eth0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          inet addr:xxx.xx.xxx.xx  Bcast:0.0.0.0  Mask:255.255.255.255
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:37527634 errors:0 dropped:0 overruns:0 frame:0
          TX packets:30951311 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:3842272774 (3.5 GiB)  TX bytes:191203005 (182.3 MiB)
          Base address:0xdcc0 Memory:dfae0000-dfb00000

lo        Link encap:Local Loopback
          inet addr:127.0.0.37  Mask:255.255.255.255
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1083886 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1083886 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:71072552 (67.7 MiB)  TX bytes:71072552 (67.7 MiB


netstat -an

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 127.0.0.37:3306         0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 127.0.0.37:25           0.0.0.0:*               LISTEN
tcp        0    232 xxx.xx.xxx.xx:22        xx.xx.xx.xxx:1114       ESTABLISHED
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node Path
unix  3      [ ]         DGRAM                    2215063  /dev/log
unix  2      [ ACC ]     STREAM     LISTENING     2318528  /var/run/mysqld/mysqld.sock
unix  2      [ ACC ]     STREAM     LISTENING     2320820  /var/run/apache2/cgisock.19269
unix  2      [ ACC ]     STREAM     LISTENING     2320823  /var/run/apache2/fastcgi/1a94431e6b26b8c419ea2e154638579a
unix  2      [ ACC ]     STREAM     LISTENING     2328016  /var/run/apache2/fastcgi/dynamic/a6d6c59ae240c609b176164aa3ca41b5
unix  2      [ ]         DGRAM                    2318526

[elch_mg]

Vielleicht.. in der Konfigurationsdatei des Resolvers, mithilfe der Dokumentation deines Vertrauens?

Verrat doch mal, welchen Resolver du verwendest...

[jg1]

Vielleicht.. in der Konfigurationsdatei des Resolvers, mithilfe der Dokumentation deines Vertrauens?

Verrat doch mal, welchen Resolver du verwendest...

Hallo,

ich benutzte den standard Resolver von Debian.... also resolv.conf und dort kann man nur die unterschiedlichen Nameserver einstellen. Habe schon unterschiedliche Dokumentationen durchforstet. Habe den Verdacht, dass irgendwie das fehlen von 127.0.0.1 daran schuld ist....

[elch_mg]

Es gibt keinen Standard-Resolver von Debian mit der Konfigurationsdatei /etc/resolv.conf, der dann auf 0.0.0.0:53/udp lauscht.
In der resolv.conf legst du fest, welche DNS-Server dein lokales System für Abfragen verwenden soll.

Zeig mal die Ausgabe von netstat -tunlp, in [ code ] [ / code ] - tags.

[jg1]

Es gibt keinen Standard-Resolver von Debian mit der Konfigurationsdatei /etc/resolv.conf, der dann auf 0.0.0.0:53/udp lauscht.
In der resolv.conf legst du fest, welche DNS-Server dein lokales System für Abfragen verwenden soll.

Zeig mal die Ausgabe von netstat -tunlp, in [ code ] [ / code ] - tags.

Stimmt, eigentlich dürfte demnach gar kein Resolver bei mir laufen... Denkfehler. Aber irgendetwas läuscht auf dem Port 53 UDP und antwortet...

Ich werde heute Nachmittag den Netstat-Befehl ausprobieren und mich dann melden.

[Roger Wilco]

Stimmt, eigentlich dürfte demnach gar kein Resolver bei mir laufen... Denkfehler. Aber irgendetwas läuscht auf dem Port 53 UDP und antwortet...

Es läuft mit Sicherheit ein Resolver bei dir, sonst könntest du keine Hostnamen auflösen. Allerdings ist das eine Client- und keine Serverkomponente. Die Ausgabe von `netstat -an` zeigt auch, dass kein Prozess bei dir an Port 53 (UDP oder TCP) gebunden ist.

Wie testest du denn, dass etwas auf Port 53 bei dir läuft?

[jg1]

Stimmt, eigentlich dürfte demnach gar kein Resolver bei mir laufen... Denkfehler. Aber irgendetwas läuscht auf dem Port 53 UDP und antwortet...

Es läuft mit Sicherheit ein Resolver bei dir, sonst könntest du keine Hostnamen auflösen. Allerdings ist das eine Client- und keine Serverkomponente. Die Ausgabe von `netstat -an` zeigt auch, dass kein Prozess bei dir an Port 53 (UDP oder TCP) gebunden ist.

Wie testest du denn, dass etwas auf Port 53 bei dir läuft?

Jetzt bringt ihr mich durcheinander :)
Also Debian hat einen Resolver (Client) um Hostnamen auflösen zu können. Dies ist aber kein Dienst auf Port 53 UDP... richtig?

Ich habe einen NSLOOKUP von Zuhause auf den vServer gemacht... und habe eine Antwort bekommen. Zwar nur eine nicht autorisierte, aber immerhin eine Auflösung!

[Roger Wilco]

Ich habe einen NSLOOKUP von Zuhause auf den vServer gemacht... und habe eine Antwort bekommen. Zwar nur eine nicht autorisierte, aber immerhin eine Auflösung!

Sehr präzise Aussage...
Welcher Server hat denn genau geantwortet?

[jg1]

Ich habe einen NSLOOKUP von Zuhause auf den vServer gemacht... und habe eine Antwort bekommen. Zwar nur eine nicht autorisierte, aber immerhin eine Auflösung!

Sehr präzise Aussage...
Welcher Server hat denn genau geantwortet?

? Mein Server?

Also nslookup, dann meinen Server als Nameserver ausgewählt und dann eine Domain (z.B. google.de) abgefragt!

Code: Select all

C:WINDOWS>nslookup
Standardserver:  xxxxxx
Address:  192.168.3.10

> server berlin.grewe-server.de
Standardserver:  berlin.grewe-server.de
Address:  193.34.121.37

> google.de
Server:  berlin.grewe-server.de
Address:  193.34.121.37

Nicht autorisierte Antwort:
Name:    google.de
Addresses:  216.239.59.104, 72.14.221.104, 66.249.93.104

>

[elch_mg]

Wenn ich mich nicht irre, zeigt netstat -an nicht alles an, u.a. kein udp. Bitte poste also mal die Ausgabe von netstat -tunlp.

Ein dig @berlin.grewe-server.de google.de hat dein Aussage bestätigt - Da läuft tatsächlich was ;)

[Roger Wilco]

Code: Select all

$ dig +noall +answer @193.34.121.37 ch txt version.bind
VERSION.BIND.           0       CH      TXT     "8.4.6-REL-NOESW"

Ja, da läuft ein (recht alter) Bind. Schau auf deiner Kiste nach, welcher Prozess das ist (`lsof -i :53 || netstat -tuplen|grep :53`). Wenn das nichts ergibt, läuft der Prozess vermutlich auf dem Hostsystem, auf dem auch dein Vserver läuft.

[elch_mg]

OT: Hm, wieder was gelernt.. Versionsabfrage für Bind per DNS ;)

[Roger Wilco]

OT: Hm, wieder was gelernt.. Versionsabfrage für Bind per DNS ;)

Naja, ist eine nette Spielerei, aber den String kann man beliebig ändern und ist damit so vertrauenswürdig, wie die From-Header einer E-Mail. ;)

[captaincrunch]

Gibt's wirklich noch (ernsthafte) Hostmaster, die diesen String nicht unterbinden / ändern?

[jg1]

Hallo,

so ein netstat -tuplen ergibt:

Code: Select all

(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode      PID/Program name
tcp        0      0 127.0.0.37:3306         0.0.0.0:*               LISTEN     101        2318527    18576/mysqld    
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN     0          2320815    19269/apache2   
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN     0          2215485    32042/vsftpd    
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN     0          2215470    32038/sshd      
tcp        0      0 127.0.0.37:25           0.0.0.0:*               LISTEN     0          2319541    18944/exim4    

Da nicht so viel läuft, habe ich mal den grep weggelassen!
Heisst das jetzt wirklich, dass ich von der Host-Maschine den BIND auf meiner IP habe!?! Was heisst das nun für mich (solange ich nicht selbst einen BIND laufen lassen möchte)?

Danke
J.Grewe

PS: War als root eingeloggt, aber mein Root hat irgendwie nicht alle Rechte (eth0 z.B. nicht). Ist wohl nicht so gut virtualisiert der Server (oder wie man das nennt).

[elch_mg]

Sehe ich das richtig, dass apache2 sowie exim4 als root laufen?

Bin mal Brille putzen...

[Roger Wilco]

Sehe ich das richtig, dass apache2 sowie exim4 als root laufen?

Müssen sie auch, um sich an einen privilegierten Port binden zu können. ;)

[elch_mg]

Bei apache lass ich das nach reiflicher Überlegung noch durchgehen, aber zumindest mein exim lauscht auf mehr als nur einem privilegiertem Port als "Debian-exim". Da funktioniert wohl das privilege-dropping oder wie mans nennen soll nicht richtig, oder ist nicht konfiguriert...

[jg1]

Bei apache lass ich das nach reiflicher Überlegung noch durchgehen, aber zumindest mein exim lauscht auf mehr als nur einem privilegiertem Port als "Debian-exim". Da funktioniert wohl das privilege-dropping oder wie mans nennen soll nicht richtig, oder ist nicht konfiguriert...

Hallo,

mein Exim4 läuft auch als Debian-Exim:

Code: Select all

root@berlin:~# ps -Alf | grep exim
5 S 102      18944     1  0  76   0 -  1324 -      Jan30 ?        00:00:00 /usr/sbin/exim4 -bd -q30m
0 S root     22703 22692  0  75   0 -   411 pipe_w 17:24 pts/7    00:00:00 grep exim
root@berlin:~#

und mein Apache läuft 1x als root sonst als www-data:

Code: Select all

root@berlin:~# ps -Alf | grep apache
5 S root     19269     1  0  75   0 -  2474 -      Jan30 ?        00:00:00 /usr/sbin/apache2 -k start
5 S www-data 19274 19269  0  83   0 -  2417 -      Jan30 ?        00:00:00 /usr/sbin/apache2 -k start
5 S www-data 19277 19269  0  81   0 - 57848 pipe_w Jan30 ?        00:00:00 /usr/sbin/apache2 -k start
5 S www-data 19279 19269  0  81   0 - 57814 pipe_w Jan30 ?        00:00:00 /usr/sbin/apache2 -k start
0 S root     22740 22692  0  75   0 -   410 pipe_w 17:26 pts/7    00:00:00 grep apache
root@berlin:~#

Eigentlich sollte alles sauber sein...
User 102 = Debian-exim

J.Grewe

[Roger Wilco]

Beispiel Apache 2. Parent läuft als "root", damit er sich an Port 80 binden kann, die übrigen Prozesse laufen unter dem Benutzer "apache".

Code: Select all

$ ps aux|grep apache
root      4835  0.0  0.4   9600  5000 ?        Ss    2006   0:06 /usr/sbin/apache2 [...]
apache    4337  0.0  0.2   8908  2408 ?        S    05:39   0:00 /usr/sbin/apache2 [...]
apache   29712  0.0  0.2   9096  2272 ?        S    05:39   0:00 /usr/sbin/apache2 [...]
[usw...]

Beispiel Exim 4. Ursprünglich als Benutzer "root" gestartet, damit er sich an Port 25 binden kann, danach zu "mail" gewechselt. In der Ausgabe von Netstat steht trotzdem, er laufe als "root".

Code: Select all

$ ps uax|grep exim
mail     28402  0.0  0.0   9248  1036 ?        Ss   Jan17   0:09 /usr/sbin/exim -bd -q15m
$ netstat -tplen|grep :25
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      0          24394227   28402/exim

[elch_mg]

Okay, ich nehm alles zurück und geh wieder im Sandkasten Mailserver bauen ;)

[jg1]

Hallo,

so, da dass geklärt ist (spiele gerne im Sandkasten :-D ) würde mich interessieren, ob ich jetzt mir besondere sorgen um den offenen Port 53 machen muss...

Schließen kann ich den ja nicht. Provider anmeckern?

J.Grewe

[Roger Wilco]

Schließen kann ich den ja nicht. Provider anmeckern?

Naja, anmeckern vielleicht nicht, aber ein netter Hinweis wäre sicher nicht verkehrt. Zumal ein für alle zugänglicher Nameserver, der rekursive Abfragen zulässt, leicht das Ziel eine DoS-Attacke werden kann.

[jg1]

Hallo!

Ich werde schon höflich sein :-D

Ich habe mal den DIG-Befehl auf benachbarte IPs ausgeführt:

Code: Select all

root@berlin:~# dig +noall +answer @193.34.121.36 ch txt version.bind
VERSION.BIND.           0       CH      TXT     "8.4.6-REL-NOESW"
root@berlin:~# dig +noall +answer @193.34.121.35 ch txt version.bind
VERSION.BIND.           0       CH      TXT     "8.4.6-REL-NOESW"
root@berlin:~# dig +noall +answer @193.34.121.34 ch txt version.bind
VERSION.BIND.           0       CH      TXT     "8.4.6-REL-NOESW"
root@berlin:~# dig +noall +answer @193.34.121.33 ch txt version.bind
VERSION.BIND.           0       CH      TXT     "8.4.6-REL-NOESW"
root@berlin:~# dig +noall +answer @193.34.121.32 ch txt version.bind
VERSION.BIND.           0       CH      TXT     "8.4.6-REL-NOESW"
root@berlin:~# dig +noall +answer @193.34.121.31 ch txt version.bind
VERSION.BIND.           0       CH      TXT     "8.4.6-REL-NOESW"

Scheint klar vom Host-System zu kommen 8)

J.Grewe