Vorgehensweise Absturz? Sicherheit?
Hallo Liste!
Achtung, die Mail wird etwas länger glaube ich.
Hier liegt ein - finde ich - recht interessanter Fall vor: Bei uns steht
ein Server im Flur. Debian Woody drauf, handcompilter Kernel 2.4.22,
Security Updates von gestern. Der hängt hinterm Router, durchgeschleift
werden nur Port 85 für den Apache, 21 für den proftpd und 22 für den sshd.
Fürs LAN läuft noch ein nfs sowie ein bind9 drauf. Die Kiste heisst
blackbox und hat die IP 192.168.0.1, der Router 192.168.0.30. Auf allen
Platten/Partitionen sind >500 MB Platz frei, nur auf der /boot Partition
noch gigantische 300 kb.
So weit die Umgebung.
Um 23:12 habe ich festgestellt, dass der DNS nicht mehr tat. Auf einen
Ping hat die Kiste noch reagiert. Also wollte ich via ssh drauf um zu
schauen was tut. Tja, ssh hat geantwortet, lief aber nicht durch:
# ssh -vv 192.168.0.1
OpenSSH_3.8.1p1 Debian 1:3.8.1p1-4, OpenSSL 0.9.7d 17 Mar 2004
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.0.1 [192.168.0.1] port 22.
debug1: Connection established.
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
Mehr kam nicht. Auch kein Timeout (zumindest nicht nach 3 Minuten oder
so). Das fand ich schon verwirrend. Ein nmap ergab, dass sämtliche
Services korrekt antworten. Da ich nicht wusste was ich ohne SSH tun
soll habe ich die Kiste resettet. Was ich dadurch dummerweise natürlich
nicht weiß ist, ob die Platte vollgelaufen war und er den tmp beim
Reboot gelöscht hat. Bei 800 MB frei auf der Platte welche /tmp
beherrbergt halte ich das jedoch für recht unwahrscheinlich?
Nach dem Reboot dann ein Blick in die Logs. Dazu muss man wissen, dass
der Timechip auf der Kiste einen Schuß hat und die Uhr deswegen 13
Minuten vor ging.
Die letzten zwei Einträge stammen vom proftpd, der den Login eines
Kumpels von mir registriert hat. Danach kommt nichts mehr, auch nicht
der Fehler-Eintrag des *hust* *rotwerd* immer noch Mißkonfigurierten
mrtg, welches dort normal alle 5 Minuten einen Fehler reinspuckt ;-)
(Hey, war bisher zu faul das Ding abzuschießen!). Dadurch weiß ich aber
sicher, dass sich 10 Minuten nach mindestens der syslog nicht mehr
gemuckst hat. Was ich nicht weiß ist, wie lange der Download des
Freundes lief, den kann ich erst morgen fragen. In der proftpd Logfile
ist nichts irgendwie auffälliges vorhanden, keine massiven
Einlogversuche oder so.
Ich kann auch relativ sicher ausschließen, dass sich irgendetwas massiv
aufgehängt hat, da die Ping-Reply Zeit absolut normal war und der
Rechner mit 350 MHz so schwach auf der Brust ist, dass ein
hängengebliebener Service sich da normal sofort auswirkt (erinnere mich
da gut an ein paar ekelhafte NFS Zicken).
Ich muss sagen, dass mich das ganze etwas nervös gemacht hat, die
Maschine ist zwar nicht hammerwichtig (und ich habe wöchentliche
Backups) aber ich fände es häßlich, wenn sich darauf jemand
herumgetrieben hätte, der da nicht sein soll.
Naja, was habe ich jetzt gemacht? Weder in der .bash_history irgendeines
Users, noch in der passwd / groups / shadow ist irgendetwas auffälliges.
Auch ein chkrootkit fand nichts auffälliges.
Was soll ich jetzt noch tun? Ich wüsste doch ganz gerne, woran das lag,
finde das nämlich nicht sehr angenehm. Irgendwelche Tips?
Was sich mir in dem Zuge auch aufdrängte: Kann man irgendwie die
.bash_history an zwei Orten erstellen lassen? Schlicht eine Kopie unter
unauffälligem Namen die mit-geschrieben wird?
Sorry, wenn das OT ist,
danke
mfG Johannes
Reply to: