schick... ändert aber nichts... da du nicht weisst, wie das defacement genau eingerichtet wurde, kannst du auch nie sicher sein, dass du keien Backdoors im System hast - entweder, du verbringst die nächsten 78h ununterbrochen mit Forensik und lebst immer mit der Ungewissheit, ob du nicht doch was übersehen hast, oder du setzt den Server neu auf.
Und dann machst du das Ding mal einigermassen sicher:
Portscan:
PORT STATE SERVICE
21/tcp open ftp <-- OK
42/tcp filtered nameserver <-- da gehört ein reject hin
80/tcp open http <-- OK
135/tcp filtered msrpc <-- reject, Dienst abschalten
137/tcp filtered netbios-ns <-- reject, Dienst weg
138/tcp filtered netbios-dgm <-- reject, Dienst weg
139/tcp filtered netbios-ssn <-- reject, Dienst weg
445/tcp filtered microsoft-ds <-- reject, Dienst weg
593/tcp filtered http-rpc-epmap <-- reject, Dienst weg
1025/tcp filtered NFS-or-IIS <-- reject, Dienst weg
1080/tcp filtered socks <-- reject, Dienst weg
2766/tcp filtered listen <-- reject, Dienst weg
3128/tcp filtered squid-http <-- reject, Dienst weg
3306/tcp open mysql <-- NIEMALS einen SQL auf einem offenen Port laufen lassen, wenn es keinen zwingenden Gründe dafür gibt - das ist vermutlich der Angriffspunkt gewesen
4444/tcp filtered krb524 <-- reject, Dienst bleibt, wenn du Kerberos Auth verwendest
8080/tcp open http-proxy <-- keine offenen Proxies! Port auf reject, Proxy deaktivieren, da du den höchstwahrscheinlich eh nicht (sinnvoll) verwendest
17300/tcp filtered kuang2 <-- was ist das denn? auf jeden Fall auch ein Reject
Ehrlich gesagt wundert es mich nicht, dass da jemand rein kam. Setz die Kiste neu auf, und informiere dich über Absicherungstechniken.
