NETBIOS datagram, name, ssn auf Debian-Server

[schgoddy]

Hallo Forummitglieder,

ich habe einen Server bei server4you.de gemietet (Debian Etch 2.6.24-etchnhalf.1-686), da läuft standardmäßig Plesk i.V.m. MySQL, Apache, Dr.Web und Anti-Spam-Daemon.

Wenn ich nun per nmap die offenen Ports (von meinem privaten PC aus) prüfe, erscheinen folgendende, eigentlich von Windows/Samba genutzte Ports:

• 135/tcp filtered msrpc
  137/tcp filtered netbios-ns
  138/tcp filtered netbios-dgm
  139/tcp filtered netbios-ssn

Welcher Dienst stellt diese Ports bereit?
Samba ist nicht aktiv, zumindest habe ich unter /etc/rc*.d/ keine Start-/Stop-Skripte gefunden. Auch finde ich mit ps -ef keine Prozesse, die auf smbd oder nmdb hinweisen. Konfiguriert habe ich definitiv nichts, was Richtung Windows/Samba geht.
Ist das irgendeine Namensauflösungsgeschichte?

Kann mir jemand weiterhelfen, wie ich (ohne den zwingenden Einsatz von iptables) die Ports, besser die Dienste deaktivieren kann?

BTW: das sind die einzigen vier Ports, die beim Status "filtered" eingetragen haben, die anderen sind "open". Was hat das zu bedeuten?

Danke schonmal,
Robert

[rendegast]

135 ist nicht netbios, sondern der Standardport des hochangreifbaren RPC-Dienstes,
siehe die security-bulletins und knowledgebase und cert-Meldungen.

Die Ports sind vermutlich vom Provider explizit gesperrt, um sein inneres Netz zu schützen.
Dann hat er aber den Port 445 vergessen, ist auch netbios.

Die verwendeten Ports auf Deiner Maschine mit

Code: Alles auswählen

netstat -tpaun

[schgoddy]

Allerdings ist das ziemlich merkwürdig, da netstat -tpaun keinen dieser 4 Ports auflistet. Lediglich per nmap sehe ich sie von außen.

Und ob der Provider sie blockt (woran könnte ich das erkennen?), kann ich nicht sagen. Auf eine Vermutung möchte ich mich da ungern verlassen!
Gibt es noch Möglichkeiten auf "meinem" System nach Ursachen zu suchen? Oder reicht die netstat-Ausgabe aus, um sicher zu sagen, dass "mein" Server diese Dienste nicht anbietet - sondern evtl. der Provider "vor meinem Server vorgeschaltet"?

Port 445 kann ich ebenfalls nicht finden.

Grüße,
Robert

[nepos]

Allerdings ist das ziemlich merkwürdig, da netstat -tpaun keinen dieser 4 Ports auflistet. Lediglich per nmap sehe ich sie von außen.

Und ob der Provider sie blockt (woran könnte ich das erkennen?), kann ich nicht sagen. Auf eine Vermutung möchte ich mich da ungern verlassen!
Gibt es noch Möglichkeiten auf "meinem" System nach Ursachen zu suchen? Oder reicht die netstat-Ausgabe aus, um sicher zu sagen, dass "mein" Server diese Dienste nicht anbietet - sondern evtl. der Provider "vor meinem Server vorgeschaltet"?

Port 445 kann ich ebenfalls nicht finden.

Grüße,
Robert

Frag halt einfach den Provider/Hoster, ob die diese Ports generell blocken.

[rendegast]

Oder reicht die netstat-Ausgabe aus, um sicher zu sagen, dass "mein" Server diese Dienste nicht anbietet

Wenn netstat nicht alle benutzten Ports listet, hast Du entweder einen veritablen Bug gefunden,
oder Dir ein rootkit eingefangen

[schgoddy]

Danke für die Antworten.
@rendegast: den veritablen Bug würde ich jetzt mal ausschließen und doch eher den worst case annehmen...

Auch eine Anfrage beim Provider zielt in dieselbe Richtung, leider. Dienste derart werden nicht standardmäßig eingerichtet. Warum auch.

Zusätzlich zu den oben erwähnten Ports/Diensten war vorgestern noch eine ganze Reihe mehr zu sehen.

• 83/tcp filtered mit-ml-dev
  191/tcp filtered prospero
  218/tcp filtered mpp
  227/tcp filtered unknown
  529/tcp filtered irc
  668/tcp filtered unknown
  750/tcp filtered kerberos
  894/tcp filtered unknown
  990/tcp filtered ftps
  1000/tcp filtered cadlock
  1005/tcp filtered unknown
  1399/tcp filtered cadkey-licman
  1408/tcp filtered sophia-lm
  2006/tcp filtered invokator
  2201/tcp filtered ats
  3455/tcp filtered prsvp
  5000/tcp filtered UPnP
  32776/tcp filtered sometimes-rpc15

Hier macht sich also jemand reichlich zu schaffen

Mit gängigen Rootkit-Checktools war auf die Schnelle erstmal nichts zu finden (außer ein paar Hinweisen auf evtl. getauschte Dateien, die jedoch original waren). Ich werde weiter ein wenig Ursachenforschung betreiben, jedoch, da die Aussichten auf Heilung gering sind, wird sich wohl eine saubere Neuinstallation nicht vermeiden lassen.

Möglicher Grund war wohl die lange Standzeit (ca. 1 Monat), als noch niemand auf dem (standardinstallierten, ungesicherten) System irgendwelche zusätzlichen Riegel vorgeschoben hat. So war es - meine Vermutung - möglich, das relativ schwache, vom Provider vergebene Root-Passwort zu knacken.

Viele Grüße
Robert

[rendegast]

Hier macht sich also jemand reichlich zu schaffen

Was die Liste aussagt, ist, daß die Kommunikation zu den entsprechenden Ports unterbunden ist.
Ob das nun der Provider auf seinen Routern oder eine Firewalllösung auf Deiner eigenen Maschine macht, sei dahingestellt.

Es heißt NICHT, daß diese Dienste auch nach außen angeboten werden, bzw. laufen.

Wenn Du einigermaßen sorgfältig beim Konfigurieren|Passwörtern warst, ist die Wahrscheinlichkeit für ein rootkit gering.
Also solltest Du auch der Ausgabe von 'netstat -tpaun' trauen können.

Zumal ein rootkit versucht, sich zu tarnen, und nicht durch viele offene Ports aufzufallen.

Gibt es noch Möglichkeiten auf "meinem" System nach Ursachen zu suchen?

Auf Deinem Server

Code: Alles auswählen

 lsof -i -n -P               # Alternative zu 'netstat -tpaun'
nmap -v -n -sS -p 1-65535 eigene_IP
nmap -v -n -sS -p 1-65535 localhost

iptables -vn -L
iptables -vn -L -t mangle
iptables -vn -L -t nat
iptables -vn -L -t raw