nmap Ergebnisse interpretieren

[zusey]

Hi,

ich habe mir vor einiger Zeit einen vServer zugelegt, auf dem ein apache, svn und sonst nur die Standardsystemdienste laufen.

An einem paranoiden Tag wie heute, habe ich einen Portscan auf meinen eigenen vServer laufen lassen und sehe dort ports als "filtered", die ich nicht kenne, z.B.

18067/tcp filtered unknown

Wenn ich der Sache mit netstat oder lsof nachgehe, finde ich nichts, d.h. mit lsof -i:18067 bekomme ich nicht heraus, was da läuft.

Woran kann das liegen? Eine Anfrage beim Betrieber ergab nur, dass dieser Port nicht für die Administration o.ä. benötigt wird (hat also nichts mit dem hostsystem oder virtualisierung zu tun).

Jemand eine Idee?

Viele Grüße
zusey

 

[Maysi2k]

BEi sowas ist immer Google gut... der erste Eintrag mit dem Trojaner gefällt mir jedoch garnicht... http://www.google.de/search?q=Port:...&rls=org.mozilla:de:official&client=firefox-a

 

[zusey]

Hi,

danke für Deine Antwort, aber das betrifft (also die dort genannten Trojaner) Windows.
Es handelt sich um ein Linux.

Grüße
zusey

 

[Maysi2k]

Oh hatte nicht gesehen, dass es im Linuxunterforum ist. Sorry

 

[IceMatrix]

Kannst du mal den gesamten Output von nmap hier rein kopieren? filtered heißt nicht, dass auf deinem Server dieser Port "offen" ist. Es heißt ganz einfach dass eine Firewall diesen Port blockiert, indem Verbindungsanfragen gefiltert werden. Es ist gut möglich dass dein Provider das zentral macht weil es über den Port zu Missbrauch gekommen ist.

 

[zusey]

ja gern:

Starting Nmap 5.21 ( http://nmap.org ) at 2011-10-04 19:37 CEST

Nmap scan report for XXXXXXXXXXXX

Host is up (0.015s latency).
Not shown: 63973 closed ports
PORT      STATE    SERVICE
25/tcp   filtered smtp
80/tcp   open     http
135/tcp  filtered msrpc
139/tcp  filtered netbios-ssn
445/tcp  filtered microsoft-ds
593/tcp  filtered http-rpc-epmap
6699/tcp  filtered napster
18067/tcp filtered unknown
30722/tcp filtered unknown

Insb. für die letzten drei (siehe code oben) gelingt es mir nicht, eine quelle/service/wasauchimmer zu finden, und hab gedacht, vielleicht hat einer von Euch noch ne idee. Wie gesagt, mit netstat und lsof kann ich nichts finden. Und sucht mal in Netz nach "nmap filtered"...
Für 135,139,445,593 finde ich auch keine dienste, nur für 25, 80 und meinen ssh port (nicht in der Liste).

Von der Virtualisierung oder Hostsystem kommts nicht (lt. support). Klar, kann an anderer Stelle gefiltert werden, und der Supportmitarbeiter wusste vielleicht nichts davon oder so, aber firewall ist zumindest auf dem server keine aktiv. Zusammen mit dem napster siehts so aus, als könnte Deine Vermutung hinhauen, IceMatrix. Das System hab ich gecheckt, der server scheint 100% sauber (rootkitscan, dienste, users, traffic, einfach alles ok).

Grüße
zusey

 

[mensch183]

Auf den gefilterten wird nix laufen. Das sind von außen "schwarze Löcher" aus denen nix kommt - egal was man hinschickt. Also mal mit iptables auf dem vserver nach Filterregeln für diese Ports schauen, um die Ursache zu finden.

Wenn die ports auf dem vserver selbst nichts gefiltert werden, filtert ein anderer auf der Strecke zwischen dir und dem nmap-Ziel. Das kann dein heimischer Router sein, dein Provider, der Hoster des vservers oder einer dazwischen.

 

[zusey]

Ok, vielen Dank - dann seht Ihr das genauso wie ich oben vermutet habe und dann werd ich's dabei belassen.

Danke Euch allen.

 

[IceMatrix]

Du könntest auch einfach auf einem vServer selbst eine Firewall aufsetzen, die alle nicht benötigten Ports dicht macht. Dann werden die hier in nmap auch nicht mehr angezeigt, weil alle per default filtered sind.

 

[aabbeeff]

Hallo,

wenn eine Firewall den Datentransfer blockiert, gibt es mehrere Möglichkeiten. Zwei dieser Möglichkeiten sind die ankommenden Pakete zu verwerfen ohne den Sender darüber zu informieren und die andere Möglichkeit ist, die Pakete zu verwerfen aber auch den Sender darüber zu informieren. Beides ist harmlos, aber im ersten Fall erscheint ein Port normalerweise als blocked oder closed und im zweiten Fall als filtered.

 

[zusey]

Wollte ich schon @ IceMatrix, leider ist das kernelmodul für iptables nicht verfügbar. Das scheint bei vServern nicht ungewöhnlich zu sein, war für mich aber neu. Habe bisher auf servern immer mit iptables gearbeitet, und das ist auch das einzige, womit ich mich richtig auskenne. Werd mir mal noch was anderes ansehen müssen, sehr schade, iptables ist einfach das perfekte Teil. Ich glaub nicht, dass es eine gleichwertige Alternative gibt.
Da auf dem Server aber kaum services laufen und der mehr als ausreichend abgesichert ist, ist das weitgehend unkritisch. Man hat halt trotzdem gern sein Standard-Setup...

Man kann eine Firewall über das webinterface des Providers konfigurieren. Scheint zuverlässig zu funktionieren. Von mir aus.

zusey