Daniel Lord schrieb:
Hi,
On Fri, 26 Aug 2005, Bernd Obermayr wrote:
Daniel Lord schrieb: [..] EXE 2250: /dev/net/.../work/fedssh2/exploit (deleted) [...]
ok, d.h. du hattest dann noch einen schönen zweiten SSH Zugang zu der Kiste.
chattr -i <datei> rm -f <datei>
Das hab ich schon versucht, geht nicht.. frx:/dev/net/.../kent # chattr -i ls frx:/dev/net/.../kent # mv ls ls-bad mv: cannot move `ls' to `ls-bad': Permission denied frx:/dev/net/.../kent # rm ls rm: cannot remove `ls': Permission denied frx:/dev/net/.../kent #
frx:/dev/net # lsattr -R ... suS--adAc------ .../kent .../kent:
chattr -suSadAc .../kent rm -rf .../kent Ok, das ging ;) Ich bin noch auf eine ganze Reihe weiterer solcher Änderungen gestossen: klogd, ls, netstat, /usr/share..
Gestern hab ich den Server neu aufgesetzt. Da die HD seltsame Geräusche von sich gab, (Klicken) und der fsck nicht durchlief hab ich gleich eine neue HD verwendet. Damit hatte ich dann das Problem mit dem Nullen der Platte auch nicht mehr ;) Der Kunde hat sich nun doch für eine externe Firewall entschieden, wenn auch nur ein DSL Router mit Firewall aber immerhin ;) Nachwievor ist unklar wie die Angreifer in das System kamen. Um den Server vor weiteren Attacken zu schützen müsste ich mich wohl mehr mit Intrusion detection etc. befassen. Da mir das nicht bezahlt wird, fehlt mir die Zeit dazu ;) Habe den Kunden nochmal aufgefordert, einen Spezialisten einzuschalten...
3. Angreifer beobachten. - eigenes LKM (umständlich)
Hab grad ein Brett vorm Kopf: LKM was ist das?
Loadable Kernel Modul d.h. einfach ein Kernelmodul, dass dir auf
hmmm, rot werd, naja war ja schon spät :))
unterster Ebene in die Suppe spuckt. Wenn das ding richtig programmiert ist hast du am laufenden System als admin fast keine chance dagegen. Einzige Alternative (die ich kenne) ist ein monolytischer Kernel oder ein eigenes "Admin LKM" das eben alles was du nicht haben willst rauswirft. Z.B. könnte das im einfachsten Fall ein Kernelmodul sein, dass als letztes geladen wird und danach keine neuen Module mehr annimmt. In lsmod etc. darf es natürlich nicht sichtbar sein ;) [...]
nmap -sV -p 35721 oder nc <ip> 35721 lsof -i TCP:35721 netstat -tulpen netstat und lsof waren auch betroffen nc kannte ich noch garnicht.
Der letzte Port war da vorher nicht :(
hehe shit happens ;)
/var/log/firewall: Aug 11 23:19:54 frx kernel: SuSE-FW-ACCEPT IN=ppp0 OUT= MAC= SRC=85.186.224.83 DST=84.150.214.196 LEN=48 TO S=0x00 PREC=0x00 TTL=120 ID=32877 DF PROTO=TCP SPT=2936 DPT=35721 WINDOW=16384 RES=0x00 SYN URGP=0 OPT (02040 5AC01010402)
ok, das Packet darf also durch deine Firewall. D.h. du hast wohl highports in der Konfiguration erlaubt. Nicht gut.
Ja das war so :( Wie ich aus einem Vergleich mit dem Backup ersehen konnte habe ich das nicht aktiviert. Offenbar hat das rootkit sich so die Tür offengehalten. In /etc/init.d/syslog war die Zeile eingefügt: source /usr/share/... Deswegen liess sich syslog nicht restarten. Am Anfang meiner Suche habe ich diese Zeile übersehen. Diese Meldung von iroffer, siehe erste Mail, mein erster Gedanke war, im Startscript nachzusehen...
Aug 11 23:19:55
hmm, auf einem server ist es wichtig immer eine genaue Uhrzeit zu haben (ntpdate oder eigene DCF77 Uhr) Sonst bist du im Fehlerfall immer am umrechnen der Zeiten.
Es lief ntp Aber warum erwähnst Du das?
Aug 11 23:27:53 frx kernel: eth0: Promiscuous mode enabled.
Aug 11 23:27:55 frx kernel: eth0: Promiscuous mode enabled.
Aug 11 23:27:55 frx kernel: Kernel logging (proc) stopped.
Aug 11 23:27:55 frx kernel: Kernel log daemon terminating.
Da wird man ja richtig zum Detektiv ;)
läuft da zufällig dein cron.daily? Oder ist es möglich, dass sich der Angreiffer ein Zeitfenster für seine Logins geschaffen hat?
Da hab ich jetzt gar nicht mehr nachgesehen.
Die Rootkit Dateien habe ich mir mal näher angeschaut. bis auf top sind alles normal binaries. Normal heißt, dass es die Binaries sind die bei deiner SuSE dabei waren. Also keine Patches, Viren, Backdoors etc..
Fein :-/ Was offensichtlich verändert wurde, ist mindestens klogd wahrscheinlich auch syslogd und ...
Top kann ich nicht so einfach verifizieren. Aber vielleicht hat jemand noch ne SuSE rumstehen, und kann dir sagen ob die MD5Summe zu einem "known good binary" passt.
3bc67a1772a8e5543d4459f581c1c25d top
Laut Hans-Martin Flesch ist das auch in Ordnung (Danke!)
Jedenfalls Danke für Deine ausführlichen Antworten, Du hast mir sehr geholfen ;)) -- Gruss Bernd