Suse-Linux Server gehackt / Rootkit ??

[aragorn2]

Hallo liebe LinuXer,

bin noch kein Linux-Experte und habe eine dringende Frage zu
meinem Server (SUSE 9.3 Prof.). Vielleicht ist der Server
gehackt worden, da eine nicht von mir initiierte Verbindung zu
einem fremden Host aufbaut wird, gestern hat sich die IP
von 67.15.231.35 (paylease.com) auf 212.227.83.130 (p15194013.pureserver.info)
geändert. Es wird immer nur auf Port 1 und 21 gesendet, von
hohen Ports ausgehend. Ich habe das erst gestern entdeckt.

Die Verbindung(en) werden in 'netstat -pantu' und anderen
netstat Optionen nicht angezeigt, nur über

cat /proc/net/ip_conntrack

hostXXX:~ # cat /proc/net/ip_conntrack | grep port=1
tcp 6 18908 ESTABLISHED src=<MyIP> dst=212.227.83.130 sport=60089 dport=1 packets=1 bytes=60 src=212.227.83.130 dst=<MyIP> sport=1 dport=60089 packets=0 bytes=0 mark=0 use=1
hostXXX:~ #

Könnte es sich dabei um ein Trojaner/Rootkit handeln?

Ich habe bisher noch keine weiteren Infos herausbekommen,
(bin auch noch kein Linux-Experte) ist aber IMO sehr merkwürdig...

Gibt es Linux-Tools die das Program/PID/Prozess eines
Programmes anzeigen, das Pakete an einen entfernten Host sendet?

Ich würde gerne den Code/die Datei(en) finden, die für dieses
Verhalten verantwortlich sind. Oder ist das ein typisches Rootkit-
Verhalten?

Gibt es Vorschläge zur Lösung?
Welche Infos wären noch dazu hilfreich?

aragorn2

 

[theton]

Erstmal muss ich anmerken, dass es mir immernoch ein Raetsel ist, warum Leute, die selbst zugeben, dass sie keine Ahnung haben, sich unbedingt einen Server ans Netz stellen muessen. Verantwortungsbewusstsein = Null.

Ich wuerde einfach mal mit 'ps ax' schauen, was dort an Prozessen laeuft. Sonst schau einfach mal mit netstat, welche Programme ueberhaupt das Netzwerk nutzen. Da sollte sich das identifizieren lassen, das dort die Verbindungen aufbaut. Dann mal tiger, chkrootkit und rkhunter drueber laufen lassen um typische Angriffssignaturen im System zu erkennen.

 

[the-mr-freak]

Original von theton
Erstmal muss ich anmerken, dass es mir immernoch ein Raetsel ist, warum Leute, die selbst zugeben, dass sie keine Ahnung haben, sich unbedingt einen Server ans Netz stellen muessen. Verantwortungsbewusstsein = Null.

Hier stimm ich erstmal zu.

Also ich kann dir, aragorn2, eigentlich nur sagen was das ist, wie du es bekämpfst weiss ich nicht.
Es ist zu 99% ein sogenannter "Stro". Das ist ein Begriff aus der FXP/Warez Szene und bezeichnet einen gehackten Server, auf dem ein FTP Server gestartet wurde (vom Angreifer gestartet). Der Server wird dann erst secured, dh zB ein Rootkit installiert, rehack Möglichkeiten ausgeschaltet usw.
Dann wird die IP weiteren Leuten zugänglich gemacht, und es werden Daten (meist Warez) draufgeflasht. Flashen ist das direkte kopieren von Daten von FTP zu FTP.
Die wechselnden IPs sind eventuell andere gehackte Server die als Proxy dienen.

Könnte es sein dass du auf deinem Server einen MySQL-Server mit einfachem oder garkeinem Passwort laufen hast? Oder ein etwas anderes, das nicht auf dem aktuellen Stand war (für das es bereits Exploits gibt)?

Du selbst bekommst ausser der bestehenden Verbindung nicht besonders viel mit. Du siehst nicht einmal dass deine Festplatte in den nächsten Tagen immer voller wird. Das regelt alles ein Rootkit.

Befolge mal die Tipps von theton, ich selbst weiss nur wie man einen Stro aufsetzt, nicht jedoch wie man das alles wieder wegbekommt

Hoffe mal ich liege richtig mit meiner Vermutung, vielleicht kann ein anderer dir ja dann sagen wie du das Problem beseitigst.

mfg
the-mr-freak

 

[theton]

Um rauszufinden, wie man einen versteckten FTP-Server (den man uebrigens spaetenstens dann bemerkt, wenn die Polizei vor der Tuer steht; ich hoffe mal, dass aragorn2 fleissig gespart hat ) wieder entfernt, waere es erstmal notwendig rauszubekommen, mit Hilfe welchen Rootkits der installiert wurde um die Schritte des Rootkits rueckgaengig machen zu koennen. Aber allgemein kann man sagen, dass ein gewissenhafter Admin in einem solchen Fall die wichtigsten Daten sichert und den Server neu aufsetzt. Alles andere waere verantwortungslos. *find* Offenbar wurde hier nicht mit Tools gearbeitet, mit denen man Aenderungen an Programm-Dateien ausfindig und rueckgaengig machen kann und dann sehe ich keine andere Moeglichkeit. Wer weiss, was da noch alle im System veraendert wurde. (LKM-Trojaner als Backdoor, manipulierte Libs usw. usf.)
Beim naechsten mal einfach nen managed Server nehmen, um den sich Leute kuemmern, die sich damit auskennen und die z.B. Datei-Aenderungen und somit auch rootkits mit Tools wie tripwire oder aide ausfindig machen, die z.B. Angriffsversuche mit Snort oder einem anderen IDS mitloggen und abwehren und die z.B. regelmaessig Sicherheitsupdates einspielen.

 

[aragorn2]

Hallo theton, hallo the-mr-freak, danke ersteinmal für eure Antworten.

@theton

Erstmal muss ich anmerken, dass es mir immernoch ein Raetsel ist, warum Leute, die selbst zugeben, dass sie keine Ahnung haben, sich unbedingt einen Server ans Netz stellen muessen. Verantwortungsbewusstsein = Null.

Du solltest das Posting genau lesen, denn ich habe nicht geschrieben, dass ich keine Ahnung habe, sondern noch kein Linux-Experte bin, was ein großer Unterschied ist.

Da ich seit 8 Jahren im Bereich Netzwerksicherheit und -design arbeite ist mein Fokus klar auf Sicherheit ausgelegt, Schlußfolgerungen wie "Verantwortungsbewusstsein = Null' sind da ganz offensichtlich falsch.

Ich wuerde einfach mal mit 'ps ax' schauen, was dort an Prozessen laeuft. Sonst schau einfach mal mit netstat, welche Programme ueberhaupt das Netzwerk nutzen. Da sollte sich das identifizieren lassen, das dort die Verbindungen aufbaut. Dann mal tiger, chkrootkit und rkhunter drueber laufen lassen um typische Angriffssignaturen im System zu erkennen.

In meinem Posting habe ich geschrieben, dass mit netstat und Konsorten (auch ps, lsof mit Internet-Files (lsof -i), logfiles via logsurfer, nmap, ...), also mit normalen Linux-Boardmitteln eben nichts feststellbar ist und ich erst nachdem ich das Netfilter-Modul ip_conntrack getestet habe, darauf aufmerksam geworden bin.

Bisher habe ich noch keinerlei andere Anzeichen gefunden, was aber in der Natur der Sache liegen könnte/wird.

Mit chkrootkit habe ich regelmäßig getestet, keine Anzeichen, was aber nicht unbedingt etwas zu bedeuten hat, da dazu die systemeigenen Bibliotheken und Tools genutzt werden und falls diese manipuliert oder ausgetauscht wurden ...

Danke für den Tipp zu tiger und rkhunter, das werde ich noch testen.

@the-mr-freak

Es ist zu 99% ein sogenannter "Stro". Das ist ein Begriff aus der FXP/Warez Szene und bezeichnet einen gehackten Server, auf dem ein FTP Server gestartet wurde (vom Angreifer gestartet). Der Server wird dann erst secured, dh zB ein Rootkit installiert, rehack Möglichkeiten ausgeschaltet usw.
Dann wird die IP weiteren Leuten zugänglich gemacht, und es werden Daten (meist Warez) draufgeflasht. Flashen ist das direkte kopieren von Daten von FTP zu FTP. Die wechselnden IPs sind eventuell andere gehackte Server die als Proxy dienen.

Das 'File Exchange Protocol' ist mir bekannt, nutze ich selber, aber nicht auf meinem Server. Danke für die Infos zu 'Stro'.

Mein MySQL-Server ist mit komplexen Passwörtern und einer Firewall geschützt, die keinerlei Remote-Verbindung zuläßt, Anwendungen werden regelmäßig aktualisiert, Apache läuft mit mod_security und regelmäßig aktualisierten Regelwerk.

Aber allgemein kann man sagen, dass ein gewissenhafter Admin in einem solchen Fall die wichtigsten Daten sichert und den Server neu aufsetzt. Alles andere waere verantwortungslos. *find* Offenbar wurde hier nicht mit Tools gearbeitet, mit denen man Aenderungen an Programm-Dateien ausfindig und rueckgaengig machen kann und dann sehe ich keine andere Moeglichkeit. Wer weiss, was da noch alle im System veraendert wurde. (LKM-Trojaner als Backdoor, manipulierte Libs usw. usf.)

Ich habe zwar gehofft, das Problem ohne Neuinstallation beheben zu können, nach den Infos zu 'Stro's sehe ich aber auch keine Alternative. Backups sind vorhanden, und falls es dazu kommen sollte, können diese auch zur forensischen Analyse / Beweissicherung genutzt werden.

Danke für Eure Hilfe
aragorn2

 

[Havoc][]

Ich seh das nicht GANZ so eng wie theton. Aber theoretisch hat er schon recht. Wenn man sich nicht auskennt, sollte man vorsichtig sein.

Um theton aber zu ergänzen, sei gesagt das man nicht versuchen sollte alles rückgängig zu machen. In 90% fäll *schätz* bekommt man ein rootkit nicht mehr aus dem System entfernt. Zumindest nicht komplett. Deswegen rate ich dir zur Neuinstallation. Ein einmal infiziertes System wieder ins Netz zu stellen ist für mich noch viel Verantwortungsloser!!

Um herrauszufinden ob du ein Rootkit hast, empfehle ich dir "chkrootkit" durchlaufen zu lassen. ps aux wird die wichtigen Rootkit-Prozesse eh nicht anzeigen. Auch der Login wird dann wahrscheinlich schon kompromitiert sein.

Havoc][

 

[Keruskerfürst]

1. Rechner sofort vom Netz nehmen.
2. Es besteht keine Alternative zur Neuinstallation.

 

[tr0nix]

Jetzt trampelt mal nicht so auf ihm rum, sowas kann jedem mal passieren.

Aragorn hast du irgendwelche Files gefunden die nicht auf das System gehören? Neue Dateien kannst du mit dem Kommando "find" ausfindig machen.

 

[phrenicus]

Leute,

jetzt mal eins nach dem anderen.

1. Keine Panik. Ich sehe hier keinerlei Beweis dafür, dass der Rechner gehackt wurde, höchstens erste Anzeichen
2. Hackt bitte nicht auf dem Mann rum (oder ist es eine Frau?). Seine Postings zeigen IMHO, dass er sich gar nicht so schlecht auskennt. Wer von Euch liest denn regelmäßig /proc/net/ip_conntrack?
3. @aragorn2: Gehen wir mal davon aus, dass der Rechner gehackt ist. Dann brauchst Du Deine Utilities auf der Platte nicht bemühen, die sind in der Regel durch ein Rootkit ersetzt. Machen wir einen ganz einfachen Test. Du hast SuSE 9.3 mit allen aktuellen Patches?
Gib uns mal die md5sum von /usr/bin/find und /bin/ps:

md5sum /usr/bin/find
3bacc7d351197e70d4f6d057f44fa830  /usr/bin/find
md5sum /bin/ps
9914bc770e2551c5ea148b505392c046  /bin/ps

Bei meinem aktuell upgedateten SuSE 9.3 sind die so.
Lass hören. Ich hab noch kein Rootkit gesehen, das md5sum austauscht.

Zugegeben, die Verbindung sieht verdächtig aus, aber wir wissen ja nicht, was auf seinem Server läuft. Des weiteren ist der 212.227.83.130 offen wie ein Scheunentor, auch der 67.15.231.35 sieht etwas seltsam aus.

Wir werden sehen. Wie gesagt, alles kein Grund zur Panik.

Gruß

 

[theton]

@theton

Da ich seit 8 Jahren im Bereich Netzwerksicherheit und -design arbeite ist mein Fokus klar auf Sicherheit ausgelegt, Schlußfolgerungen wie "Verantwortungsbewusstsein = Null' sind da ganz offensichtlich falsch.

Nun, ich arbeite in diesem Bereich erst knapp 5 Jahre (naja, fast 6) und schon bevor ich mit diesem Job anfing waren mir Tools wie tripwire und aide zum Sicherstellen der Datei-Integritaet und Snort als IDS vertraut. Ausserdem kannte ich damals schon grundlegende Mechanismen zum Absichern von Servern und zum Nachvollziehen von Einbruechen (was natuerlich einen entsprechend abgesicherten Server voraussetzt). Und auch die rechtlichen Belange, wie Rechten und Pflichten eines Administrators. musste ich vorher erlernen. Wenn du grundlegende Sicherheitsmechanismen von Anfang an implementiert haettest, waere es jetzt kein Problem rauszufinden welche Programme im System manipuliert wurden bzw. welche Programme/Skripte/Kernel-Module hinzugefuegt wurden. Ein taegliches durchsehen der wichtigsten Logs (wie z.B. das eines IDS und der Firewall) haette dir sicherlich rechtzeitig Unregelmaessigkeiten gezeigt, so dass du nicht erst durch ip_conntrack drauf gekommen waerst. Und da du scheinbar nichtmal die System-Integritaet sichergestellt hast, scheint mir meine Schlussfolgerung nicht so offensichtlich falsch.Ich hoffe, dass du die Kiste wenigstens schon vom Netz genommen hast.

 

[damager]

denke wir sollten mal abwarten was nun rkhunter rausbringt...

übrigens sehe ich das auch wie theton: man muss sich schon bewust sein was man da tut und welche verantwortung der betrieb eines öffentlichen serverdienstes mitsich bringt.
mangelndes wissen (wie ausgeprägt auch immer) schützt vor gesetzlichen konsequenzen nicht. sollte der server z.b für warez mißbrauchst werden und die kipo das mitbekommt ... ist der server betreiber der verantwortliche.
die aussage es nicht besser gewust zu haben dürfte den richter IMHO wenig interessieren.

 

[aragorn2]

Hallo tr0nix, hallo Havoc][,

Ja, es wurde unter anderen '/dev/tty10' und '/usr/sbin/suexec2' geändert, ein RPM-Check zeigt einige Änderungen der Dateirechte und MD5-Hashes an.

ind / -mtime -8 -fprint ./mchanges_all.txt
find / -ctime -30 -fprint ./new_files.txt
find / -atime -8 -o -ctime -30 -o -mtime -8 -fprint ./changes_all.txt

=> nichts auffälliges und keine unbekannten neuen Dateien

hostXXX:~/STR/sw-archives # ifpromisc
eth0: PF_PACKET(/sbin/dhcpcd)
hostXXX:~/STR/sw-archives # checkproc
checkproc: Usage:
checkproc [-v] [-k] [-p pid_file] /full/path/to/program

=> der Pfad/PID der Malware ist leider nicht bekannt ...

rpm -Va > rpm-validation.txt

Bedeutung der Symbole:
M Mode verändert
S File Size verändert
5 MD5 Summe verändert
D Device major/ minor number verändert
L readLink(2) path falsch
U User ownership verändert
G Group ownership verändert
T mTimeverändert

nur auszugsweise:

S.5....T /usr/sbin/suexec2
.M....G. /dev/ttyS0
S.5....T c /etc/default/useradd
S.5....T c /etc/crontab
.M...... /bin/cmd5checkpw
S.5....T c /etc/securetty

=> ich werde den Server ASAP neu aufsetzen

Mit chkrootkit habe ich regelmäßig getestet, keine Anzeichen, was aber nicht unbedingt etwas zu bedeuten hat, da dazu die systemeigenen Bibliotheken und Tools genutzt werden und falls diese manipuliert oder ausgetauscht wurden ...

 

[phrenicus]

übrigens sehe ich das auch wie theton: man muss sich schon bewust sein was man da tut und welche verantwortung der betrieb eines öffentlichen serverdienstes mitsich bringt.
[...]
die aussage es nicht besser gewust zu haben dürfte den richter IMHO wenig interessieren.

Natürlich. Vollkommen richtig und ganz meine Meinung.
Ich gehe aber auch davon aus, dass er sich selbst fragt, wie das passieren konnte und wo er nachlässig war. Hat er nicht gepatcht oder upgedatet? Hat er unsichere Dienste eingesetzt oder unsichere Passwörter? Ich gehe ferner davon aus, dass er alles dran setzen wird, dass sich so etwas nicht mehr wiederholt. Die Tipps von theton mit den IDS-Systemen wird er sich zu Herzen nehmen.
Auch wenn der Rechner _nicht_ gehackt wurde, hat er viel daraus gelernt. Und das steht IMHO noch nicht fest, oder? Für einige hier scheint es bereits eine Tatsache zu sein.

Ich sehe grade den Output von aragorn2.

Immer unter der Voraussetzung, dass die Maschine gehackt ist, kannst Du Dich auf find nicht verlassen.
Dass sich die RPM-Daten ändern, ist normal, wenn man updated. Alles was ich hier sehe, kann auch von einem Administrator verursacht worden sein.

Ich finde immer noch, dass es zu früh ist, sicher zu sagen, dass der Server gehackt wurde.

Gruß

 

[damager]

Ich finde immer noch, dass es zu früh ist, sicher zu sagen, dass der Server gehackt wurde.

sehe ich ja auch so ... deswegen ja meine aussage:

denke wir sollten mal abwarten was nun rkhunter rausbringt...

und auf diese ausgabe, nach einem rkhunter --update, warten wir noch

 

[aragorn2]

Hallo,

es hat etwas länger gedauert, rkhunter werde ich als cronjob im reporting mode laufen lassen, ist ein richtig gutes Programm! Tiger werde ich auch noch testen.

Stimmt, gelernt habe ich schon einiges, auch falls es nur ein falscher Alarm sein sollte.

Bisher habe ich Whirlpool (whirlpooldeep) als Hash-Algo genutzt, aber nur manuell aktualisiert, und da ich in den letzten 14 Wochen im Krankenhaus war, ..., das werde ich automatisieren und mir diffs regelmäßig zusenden lassen.

meine Dateien sind identisch:
3bacc7d351197e70d4f6d057f44fa830 /usr/bin/find
9914bc770e2551c5ea148b505392c046 /bin/ps
Habe md5sum auch überprüft, ist in Ordnung.

MD5-Kollisionen zu generieren, ist sehr schwer, wenn nicht beliebige Zeichen benutzt werden können, da die Binaries auch funktionieren müssen.

## rkhunter ##

hostXXX:~/STR/sw-archives/rkhunter # rkhunter --update
Running updater...

Mirrorfile /usr/local/rkhunter/lib/rkhunter/db/mirrors.dat rotated
Using mirror http://mirror07.mirror.rkhunter.org
[DB] Mirror file : Update available
Action: Database updated (current version: 2005050700, new version 2006041300)
[DB] MD5 hashes system binaries : Update available
Action: Database updated (current version: 2006021400, new version 2006022800)
[DB] Operating System information : Update available
Action: Database updated (current version: 2005102800, new version 2006051200)
[DB] MD5 blacklisted tools/binaries : Up to date
[DB] Known good program versions : Update available
Action: Database updated (current version: 2006021400, new version 2006031400)
[DB] Known bad program versions : Update available
Action: Database updated (current version: 2006021400, new version 2006031400)

Ready.

Die Ausgabe von rkhunter ist angehängt, zeigt aber keinen Rootkit, nur zwei versteckte Dateien/Verzeichnisse:

hostXXX:/dev/.udevdb # cat udevd.pid
1990
hostXXX:/dev/.udevdb # cat /etc/.pwd.lock
[empty]

Ich werde bei SSH das Protokoll 1 noch abschalten, OpenSSL war schon gepatcht.

#####################

nmap zeigt bei den beiden Hosts folgendes:

# Nmap 4.10 scan initiated Wed Jul 12 10:02:26 2006 as: nmap --append-output -oN /root/STR/scripts/proxy+id/nmap/nmap_logfile -R -PE -PP -PM -sS --system-dns -F -sV --version-intensity 9 -A -O --osscan-guess --log-errors -v -v --privileged -P0 212.227.83.130
Interesting ports on p15194013.pureserver.info (212.227.83.130):
Not shown: 1201 closed ports
PORT STATE SERVICE VERSION
7/tcp open echo
9/tcp open discard?
13/tcp open daytime Microsoft Windows International daytime
17/tcp open qotd Windows qotd
19/tcp open chargen
20/tcp open ftp-data?
21/tcp open ftp Microsoft ftpd
25/tcp open tcpwrapped
80/tcp open http Microsoft IIS httpd
81/tcp open hosts2-ns?
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn
445/tcp open microsoft-ds Microsoft Windows 2003 microsoft-ds
1025/tcp open msrpc Microsoft Windows RPC
1026/tcp open msrpc Microsoft Windows RPC
1027/tcp open msrpc Microsoft Windows RPC
1030/tcp open msrpc Microsoft Windows RPC
1212/tcp open lupa?
1433/tcp filtered ms-sql-s
1434/tcp filtered ms-sql-m
1935/tcp open printer
2000/tcp open tcpwrapped
2001/tcp open tcpwrapped
2002/tcp open tcpwrapped
2003/tcp open tcpwrapped
2004/tcp open tcpwrapped
2005/tcp open tcpwrapped
2006/tcp open tcpwrapped
2007/tcp open tcpwrapped
2008/tcp open tcpwrapped
2009/tcp open tcpwrapped
2010/tcp open tcpwrapped
2011/tcp open netbios-ssn
2012/tcp open ttyinfo?
3000/tcp open ppp?
3306/tcp open mysql MySQL 4.0.20a-nt
3389/tcp open microsoft-rdp Microsoft Terminal Service
5 services unrecognized despite returning data. If you know the service/version, please submit the following fingerprints at http://www.insecure.org/cgi-bin/servicefp-submit.cgi :
==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)==============
==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)==============
==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)==============
==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)==============
==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)==============
[ Fingerprints gekürzt]

Device type: general purpose
Running: Microsoft Windows NT/2K/XP|2003/.NET
OS details: Microsoft Windows 2003 Server, 2003 Server SP1 or XP Pro SP2
OS Fingerprint:
TSeq(Class=TR%IPID=I%TS=0)
T1(Resp=Y%DF=N%W=4000%ACK=S++%Flags=AS%Ops=MNWNNT)
T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
T3(Resp=Y%DF=N%W=4000%ACK=S++%Flags=AS%Ops=MNWNNT)
T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=0%IPLEN=B0%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)

TCP Sequence Prediction: Class=truly random
Difficulty=9999999 (Good luck!)
IPID Sequence Generation: Incremental
Service Info: OS: Windows

# Nmap run completed at Wed Jul 12 10:04:59 2006 -- 1 IP address (1 host up) scanned in 153.588 seconds
# Nmap 4.10 scan initiated Wed Jul 12 10:05:00 2006 as: nmap --append-output -oN /root/STR/scripts/proxy+id/nmap/nmap_logfile -R -PE -PP -PM -sS --system-dns -F -sV --version-intensity 9 -A -O --osscan-guess --log-errors -v -v --privileged -P0 67.15.231.35
Interesting ports on paylease.com (67.15.231.35):
Not shown: 1190 filtered ports
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 2.0.1
25/tcp open smtp Sendmail 8.13.1/8.13.1
53/tcp closed domain
80/tcp open http Apache httpd 2.0.52 ((Red Hat))
110/tcp open pop3 UW Imap pop3d 2003.83rh
143/tcp open imap UW imapd 2003.338rh
443/tcp open ssl OpenSSL
6000/tcp closed X11
6001/tcp closed X11:1
6002/tcp closed X11:2
6003/tcp closed X11:3
6004/tcp closed X11:4
6005/tcp closed X11:5
6006/tcp closed X11:6
6007/tcp closed X11:7
6008/tcp closed X11:8
6009/tcp closed X11:9
6017/tcp closed xmail-ctrl
6050/tcp closed arcserve
6101/tcp closed VeritasBackupExec
6103/tcp closed RETS-or-BackupExec
6105/tcp closed isdninfo
6106/tcp closed isdninfo
6110/tcp closed softcm
6111/tcp closed spc
6112/tcp closed dtspc
6141/tcp closed meta-corp
6142/tcp closed aspentec-lm
6143/tcp closed watershed-lm
6144/tcp closed statsci1-lm
6145/tcp closed statsci2-lm
6146/tcp closed lonewolf-lm
6147/tcp closed montage-lm
6148/tcp closed ricardo-lm
6400/tcp closed crystalreports
6401/tcp closed crystalenterprise
6502/tcp closed netop-rc
6543/tcp closed mythtv
6544/tcp closed mythtv
6547/tcp closed PowerChutePLUS
6548/tcp closed PowerChutePLUS
6558/tcp closed xdsxdm
6588/tcp closed analogx
6666/tcp closed irc-serv
6667/tcp closed irc
6668/tcp closed irc
6969/tcp closed acmsoda
7000/tcp closed afs3-fileserver
Device type: general purpose
Running: Linux 2.6.X
OS details: Linux 2.6.10 - 2.6.11
OS Fingerprint:
TSeq(Class=RI%gcd=1%SI=2DC353%IPID=Z%TS=U)
T1(Resp=Y%DF=Y%W=16D0%ACK=S++%Flags=AS%Ops=M)
T2(Resp=N)
T3(Resp=N)
T4(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=N)
PU(Resp=Y%DF=N%TOS=C0%IPLEN=164%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)

TCP Sequence Prediction: Class=random positive increments
Difficulty=2999123 (Good luck!)
IPID Sequence Generation: All zeros
Service Info: OS: Unix

# Nmap run completed at Wed Jul 12 10:05:25 2006 -- 1 IP address (1 host up) scanned in 25.671 seconds

##################

 

[damager]

das sieht an sich ja gut aus ... schon komisch.
ist der source-port auf deinem server immer der gleiche (60089)?
was sagt eigentlich lsof -i | grep 60089 oder netstat -a?

 

[theton]

[11:19:10] Info: Service /etc/xinetd.d/visasd3 enabled

Kann es sein, dass hier Visas zur Verwaltung im Einsatz ist/war? Soweit ich weiss, wird das garnicht mehr supported, so dass es dafuer auch keine Updates mehr gibt. Wenn da tatsaechlich Visas laeuft, duerfte dort wohl die groesste Sicherheitsluecke sein.

 

[phrenicus]

Jo,

ist schon recht. Das sieht gut aus.
Dann administrier in Zukunft Deinen Server ordentlich, denk auch daran, was theton über snort gesagt hat. Das zu installieren und ordentlich zu konfigurieren ist kein Fehler. Ebenso darf man daran denken, tripwire oder auch ViperDB einzusetzen.

Und immer so schnell wie möglich updaten, sobald es neue Patches gibt, die Sicherheitslücken heben. Du kannst ja Mitglied auf der SuSE-Security-Announcement-Mailingliste werden, dann erfährst Du es sofort, wenn es Patches gibt.

Gruß

@theton: was ist Visas?

 

[damager]

evtl. auch mal mit ethereal oder tcpdump diesen traffic aufnehmen ... evtl sieht man dort mehr.

 

[aragorn2]

@damager:

> lsof -i | grep 60089 (oder auch andere genutzte Ports)
> netstat -a

beides zeigt keine Infos dazu an

ist der source-port auf deinem server immer der gleiche (60089)?

nein, der Src-Port wechselt, aber immer im Bereich 40000 < x < 65535,
Ziel ist immer Port 1 und 21

Den Server halte ich mit:
> you security (Yast Online Update) aktuell

und auf der Suse-ML 'suse-security-announce' bin ich auch.

@theton:

Kann es sein, dass hier Visas zur Verwaltung im Einsatz ist/war? Soweit ich weiss, wird das garnicht mehr supported, so dass es dafuer auch keine Updates mehr gibt. Wenn da tatsaechlich Visas laeuft, duerfte dort wohl die groesste Sicherheitsluecke sein.

Ja, der Strato-Server wurde mit Visas aufgesetzt. Ich werde mich zu ServerAdmin24 (Visas) informieren und ggf. Visas/Serveradmin24 deinstallieren, da ich das Webinterface zum Administrieren nur anfangs genutzt habe und eigentlich nicht mehr brauche.

Der Tipp mit Snort/AIDE/Tripwire ist gut, ich sehe mir die Tools gerade an, sie sind wesentlich leistungsfähiger als whirlpooldeep. ViperDB werde ich mir später auch ansehen.

Danke für eure Hilfe.
Aragorn2