Root Server

[cheechyba]

Hallo liebe community,

ich habe folgendes problem und ich weiss nicht an wen ich mich damit wenden soll. und zwar hat sich einer in der letzten woche auf mein rootz server eingelogt und eine file namens unixcod abgelegt.

ich habe es bemerkt wo ich mich in die ssh console eingelogt hatte um verschiedene server nach dem restart zu starten.

nun das problem diese datei wurde von einer homepage runtergeladen, die ich über den eingegebenen gespeicherten befehl besuicht habe. auf der hp ist nichts ud es steht unter construktion. aber die file die er heruntergelaten hat unixcod.tar.gz ist dort vorhanden.

er ist über die homeverzeichnisse der css server hineingelangt und hat das tool was aus 5 dateien besteht in alle homeverzeichnisse abgelegt. ich habe diese nun schnellstmöglich gelöscht. dachte ich zu mindest!

als ich dann am nächsten tag also heute auf meinen server wollte waren die zugfriffszeiten darauf schon sehr lang.

ich habe dann mit dem befehl ps ax mir die task angeschaut und sehr viele tasks namens attack gefunden so ungefähr 40 mal.

jetzt habe ich den server neugestartet und es ist komisch aber bei dem neustart ist jedesmal cs 20mb mehr im arbeitsspeicher abgelegt was ich aber nicht aus den laufenden task herausfinden kann da beim severstart nur die sql datenbanken und der web server dort verzeichnet ist.

nun bitte ich euch dringenst um eure hilfe ich komme echt icht merh weiter. er hat auch befehle in die ssh console eigegeben von denen ich noch nie was gehört habe oder was anfangen könnte.

ich bin am verzweifeln und hoffe ihr könnt mirt dabei helfen.

icq 270948423 skype cheech512 msn cheechyba@msn.com

:( euer cheech :(

[zyrusthc]

Sichere die Logs und lass den Server neu aufsetzen!
Das System scheint von einen Cracker kompromittiert zu sein!
http://de.wikipedia.org/wiki/Technische_Kompromittierung

PS:http://www.root-und-kein-plan.ath.cx

Greeez Oli

[cheechyba]

zusätzlich ergänze ich diesen auszug der tasks:

sh -c find \/ -name \* 2>/dev/null
/ -name *
diese befehle sagen mir nichts. hier ein kompletter auszug:

1 ? S 0:03 init [2]
2 ? S 0:00 [keventd]
3 ? SN 0:01 [ksoftirqd_CPU0]
4 ? S 0:00 [kswapd]
5 ? S 0:00 [bdflush]
6 ? S 0:00 [kupdated]
7 ? S 0:00 [kjournald]
441 ? Ss 0:00 dhclient -e -pf /var/run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0
525 ? Ss 0:00 /sbin/portmap
732 ? Ss 0:00 /sbin/syslogd
738 ? Ss 0:00 /sbin/klogd -x
793 ? S 0:00 /bin/sh /usr/bin/mysqld_safe
830 ? S 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-lockin
831 ? S 0:00 logger -p daemon.err -t mysqld_safe -i -t mysqld
832 ? S 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-lockin
833 ? S 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-lockin
834 ? S 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-lockin
835 ? S 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-lockin
836 ? S 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-lockin
838 ? S 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-lockin
839 ? S 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-lockin
840 ? S 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-lockin
841 ? S 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-lockin
844 ? S 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-lockin
885 ? Ss 0:00 /usr/sbin/lpd -s
892 ? Ss 0:00 /usr/sbin/inetd
903 ? Ss 0:00 /usr/sbin/sshd
933 ? Ss 0:00 /sbin/rpc.statd
961 ? Ss 0:00 sendmail: MTA: accepting connections
997 ? Ss 0:00 /usr/sbin/cron
1012 ? Ss 0:00 /usr/sbin/apache2 -k start
1057 ? Ss 0:00 sshd
1067 ? S 0:00 /usr/sbin/apache2 -k start
1068 ? S 0:00 /usr/sbin/apache2 -k start
1069 ? S 0:00 /usr/sbin/apache2 -k start
1070 ? S 0:00 /usr/sbin/apache2 -k start
1071 ? S 0:00 /usr/sbin/apache2 -k start
1072 ? Ss 0:00 /usr/bin/perl /usr/share/webmin/miniserv.pl /etc/webmin/miniserv.conf
1097 tty1 Ss+ 0:00 /sbin/getty 38400 tty1
1098 tty2 Ss+ 0:00 /sbin/getty 38400 tty2
1099 tty3 Ss+ 0:00 /sbin/getty 38400 tty3
1100 tty4 Ss+ 0:00 /sbin/getty 38400 tty4
1101 tty5 Ss+ 0:00 /sbin/getty 38400 tty5
1102 tty6 Ss+ 0:00 /sbin/getty 38400 tty6
1121 ? S 0:00 /usr/sbin/apache2 -k start
1122 ? S 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-lockin
1125 ? S 0:01 /usr/sbin/apache2 -k start
1126 ? S 0:00 /usr/sbin/apache2 -k start
1272 ? S 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-lockin
1322 ? S 0:08 /usr/share/webmin/file/search.cgi
1323 ? S 0:00 sh -c find \/ -name \* 2>/dev/null
1324 ? S 0:00 find / -name *
1325 ? S 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-lockin
1354 ? S 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-lockin
1627 ? S 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-lockin
1995 ? S 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-lockin
2110 ? S 0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip-external-lockin
2153 ? S 0:00 /usr/sbin/apache2 -k start
2165 ? S 0:00 /usr/bin/perl /usr/share/webmin/miniserv.pl /etc/webmin/miniserv.conf
2166 ? S 0:00 /usr/bin/perl /usr/share/webmin/miniserv.pl /etc/webmin/miniserv.conf
2167 ? S 0:00 /usr/bin/perl /usr/share/webmin/miniserv.pl /etc/webmin/miniserv.conf
2168 ? S 0:00 /usr/bin/perl /usr/share/webmin/miniserv.pl /etc/webmin/miniserv.conf
2173 ? Rs 0:00 sshd: root@pts/0
2178 pts/0 Ss 0:00 -bash
2182 pts/0 R+ 0:00 ps ax

und meine frage ist wieso kann ich denn denjenigen nicht sehen irgendwo muss er ja eingeloggt sein?

[cheechyba]

btw als root bin ich drin um befehle killen zu können die mit den einzelden anderen benutzer nicht möglich sind zu killen

[zyrusthc]

btw als root bin ich drin um befehle killen zu können die mit den einzelden anderen benutzer nicht möglich sind zu killen
Lies die von mir geposteten Links genau durch!

Das Kommando w sollte dir verraten , welche Benutzer angemeldet sind und was sie gerade tun!
Und who zeigt dir wer angemeldet ist und wo er sich angemeldet hat und seit wann er auf dem System eingeloggt ist.

PS: Und überarbeite bitte deinen Post mit den Ausgaben, verwende die Code-Tags des Forums!

[-hanky-]

Auch wenn das bereits gesagt wurde: Fahr den Server auf der Stelle herunter und lass ihn von deinem Provider neu installieren. Vorher aber bitte noch soviele Beweise wie möglich sichern, am Besten alle Logs. Die sind zwar vermutlich unbrauchbar wenn derjenige, der sich da an deinem Server zu schaffen gemacht hat, Ahnung hat von dem was er da tut, aber man weiß ja nie.

Nix mit "als Root Prozesse abschießen" etc. - einem einmal kompromittierten System ist nicht mehr zu trauen, der Cracker kann alle möglichen Dateien versteckt und im Hintergrund laufen haben, von Rootkits ganz zu schweigen. An einer Neuinstallation führt kein Weg vorbei.

Nachdem du das gemacht hast meldest du dem Serverbetreiber, von dessen Server die Schadsoftware geladen wurde, dies - dann kann der das Teil so schnell wie möglich vom Netz nehmen.

Weiterhin solltest du dir Gedanken machen wie der Cracker in das System kam - veraltete Software ( sprich: keine Updates? ), unsicheres Passwort, etc. und dementsprechend Maßnahmen ergreifen.

-hanky-

edit: Google hilft wie so oft auch hier. Das ominöse "unixcod" ist scheinbar ein Tool um automatisiert SSH-Zugänge mit Passwörtern durchzugehen ( anhand einer Datenbank ). Im Paket ist auch eine "find"-Binary - es spricht also vieles dafür dass der "find-Befehl" daher rührt. Herzlichen Glückwunsch - dein Server attackiert gerade fremde Systeme...

edit²: Die Seite, von der ich unixcod habe, ist scheinbar ein kompromittiertes System - die Url lautet sinngemäß infected.xyz.com. Naja, Humor hatte der Cracker offenbar :ugly:

[bla!zilla]

Wie wäre es denn dann mal mit einem gepflegten Shutdown des Servers?

[kreol]

Wie wäre es denn dann mal mit einem gepflegten Shutdown des Servers?Nein, erst muss der Fehler gefunden und von dem hochprofessionellen Admin beseitigt werden. Runterfahren um Schlimmeres zu verhindern ist völlig unnötig und versaut nur die uptime. Auch ein vom Netz nehmen kommt keinesfalls in Betracht, der Server muss ja zwingend 24/7 erreichbar sein... :ugly:

Abschalten, nur weil der Server Amok läuft, ihr seid einfach nur weich :ugly:


Kreol

Wer Ironie findet darf sie behalten.

[bla!zilla]

*Ironieeinsammel*

Die kann ich später noch mal gebrauchen.....

[kreol]

*Ironieeinsammel*

Die kann ich später noch mal gebrauchen.....Lass für den TE cheechyba noch etwas Ironie übrig, sonst geht die Botschaft vllt. an ihm vorüber... ;)


Kreol

[Stephanw]

Man sollte vielleicht das Linux durch ein Windows ME Server ersetzten. Da hat das unixcod keine Chance mehr. Hah!

Gruß Stephan

PS: Wie geil! Gerade eine Rootserver-Noob-Belehrung entwickelt und schon kommt sie zum Einsatz.

EDIT: Ich habe mir dieses unixcod gerade auch mal ergoogelt (lag auf einem Server, wo es noch so ein paar ominöse MP3s u.Ä. gab???). Jedenfalls ist da ein abgefahrenes Wörterbuch dabei:



stephan@Steph64 ~/Desktop/uc/unixcod $ grep root data.conf |wc -l
10173


Und ****** die Wand an: Mein root-Passwort auf meinem Desktop ist tatsächlich dabei. Wie gut, das ich genattet bin und kein sshd laufen habe.

Noch ein Tip für root-Server: Ich würde den root-Zugang in der /etc/ssh/sshd_config deaktivieren. Dann würde ich einen Adminuser einrichten, den Zugang per Passwort in der /etc/shadow abschalten und einen passenden SSH-Key in die ~/.ssh/authorized_keys legen. Wenn man mal auf ne dicke Baustelle muss, kann man dann den su machen oder sich ggf. nen sudo einrichten.

[jay-t]

Das ist der Teil in /etc/ssh/sshd_config



# Authentication:
LoginGraceTime 600
PermitRootLogin no
StrictModes yes


Bastille http://www.bastille-linux.org/ ist ein gutes Tool um das System sicherer zu machen.

Auf jeden Fall erfährt man dabei mehr über Linux.

[bla!zilla]

Noch ein Tip für root-Server: Ich würde den root-Zugang in der /etc/ssh/sshd_config deaktivieren. Dann würde ich einen Adminuser einrichten, den Zugang per Passwort in der /etc/shadow abschalten und einen passenden SSH-Key in die ~/.ssh/authorized_keys legen. Wenn man mal auf ne dicke Baustelle muss, kann man dann den su machen oder sich ggf. nen sudo einrichten.

Eine Authentifizierung per Key und Passphrase ist auf _jeden_ Fall anzuraten. Das habe ich selbst bei meinem Server hier bei mir. SSH ist bei dem nach Außen gar nicht geöffnet. Von Außen komme ich lediglich über einen IPSec Tunnel an den SSH heran. Allgemein sollten _nur_ Anwendungsports geöffnet sein, also 25/tcp bei einem Mailserver, 80/tcp und 443/tcp bei einem Webserver, 53/tcp und udp bei einem DNS...bla...bla..bla. SSH, rsh, Telnet, Webmin, Plesk usw. sollten nie direkt erreichbar sein. Nicht auf ihrem Standardport, nicht auf einem alternativen Port. So ziemlich jeder Rootserver verfügt doch über eine serielle Konsole (SSH auf Konsolenserver und von da aus auf den Server) - warum nutzt man das nur für den K-Fall?

[obzidian]

Weil der durchschnittliche root-Server root nicht weiß was ssh ist, höchstens mal "putty" vom hörensagen, dann ist es aber auch schon ein ziemlicher liet-Gameobermaster mit allerlei Skills.

[ThE_FiSh]

vllt sollte man sich erst mit den themen linux,sicherheit,konfiguration beschäftigen.... ist ja nicht so, als ob das netz da keine informationen hätte ;)

btw. ich find vpn prima :)

[cheechyba]

wisst ihr ich habe zwar keine ahnung was die gazen anderen anderen themen hier sollen aber naja......

anstatt mal alle anderen lamer fertigzumachen die nicht den ganzen tag vor einem unixsystem sitzten habe ich nur um hilfe gebeten und was hier für srüche kommen ich hatte ja ne antändige community erwartet aber danke euch den tipps für so einen unix noob wie mich

[cheechyba]

Nein, erst muss der Fehler gefunden und von dem hochprofessionellen Admin beseitigt werden. Runterfahren um Schlimmeres zu verhindern ist völlig unnötig und versaut nur die uptime. Auch ein vom Netz nehmen kommt keinesfalls in Betracht, der Server muss ja zwingend 24/7 erreichbar sein... :ugly:

Abschalten, nur weil der Server Amok läuft, ihr seid einfach nur weich :ugly:


Kreol

Wer Ironie findet darf sie behalten.

absolut schwachsinn

[cheechyba]

Lass für den TE cheechyba noch etwas Ironie übrig, sonst geht die Botschaft vllt. an ihm vorüber... ;)


Kreol

und was soll das TE

[cheechyba]

Weil der durchschnittliche root-Server root nicht weiß was ssh ist, höchstens mal "putty" vom hörensagen, dann ist es aber auch schon ein ziemlicher liet-Gameobermaster mit allerlei Skills.

aha also meinst du ich kenne putty nicht? oder wie war der dumme spruch gemeint! ode rmeinst du ich benutze es nicht?

naja wie auch imme r

[marce]

Alle hilfreichen Tipps wurden bereits gegeben. Und nein, am System noch herumdoktern ist keine Alternative.

Nimm die Kiste vom Netz, sichere die Daten und Logs und lasse der Server neu aufsetzen. Und dann kümmerst Du dich um die Härtung des Systems - bevor Du ihn der Öffentlichkeit zugänglich machst...

... und dann die tägliche Pflege nicht vergessen...

[Rain_maker]

Zumindest die "Popcorn und anderes Knabberzeug herstellende"-Industrie hatte sicher etwas von diesem Thread.

*SCNR*

Ansonsten kann man sich den Tipps bezüglich

- _unverzügliches_ "vom Netz nehmen" der kompromittierten Kiste.

- Sichern der Logs/Daten.

- Neuaufsetzen und Härten des Systems _bevor_ die Kiste wieder ans Netz geht.

- Dem Erwerb von Linux-Grundlagen, bevor man überhaupt an den letzten Punkt auch nur zu denken wagt.

vollständig anschließen.

Und hier noch etwas Lesestoff:

http://www.rootforum.de/faq/content/14/104/de/vorgehensweise-bei-gecracktem-server.html

Greetz,

RM

[-hanky-]

und was soll das TE

TE heißt Threadersteller.

Und ich weiß ehrlich gesagt nicht was du dich aufregst - du wurdest mehrfach darauf hingewiesen dass das System kompromittiert ist und du es deshalb schleunigst vom Netz nehmen und neu aufsetzen sollst.

Was gibt es daran nicht zu verstehen?

In Anbetracht der Tatsache dass du offensichtlich einen Rootserver betreibst ohne über das erforderliche Grundlagenwissen zu verfügen fielen die Antworten hier sogar noch relativ human aus...

-hanky-

[zyrusthc]

Kann hier mal jemand jetzt schliessen!?

[cheechyba]

das system habe ich vom netz genommen und habe es neu installiert nur habeich einige probleme mit dem alten datenbank backup abe rnaja ich bekomme das schon hin.

[cheechyba]

und btw hab emir den link angeschaut und meinen provider über die ips inkenntnis gesetzt was den aber wenig störte. die haben gesagt: "so lange bei uns nochkeine beschwerden deshalb hereingekommen sind und wir noch nichts auffälliges gemerkt haben mussen sie dei daten löschen und die schadensbegrenzung so kein wie möglich halten"

war nen zitat!

[bla!zilla]

Okay, es ist alles gesagt. :)

CLOSED