VPS kompromittiert? Falsch konfiguriert?

2801

Ich habe jetzt ein halbes Jahr ein VPS gemietet (zu Lernzwecken) und ich habe versucht, so viel wie möglich zu lernen, um es sicher zu halten.

Vor kurzem wurde es kompromittiert und ich vermute, dass es eine Woche vor der Realisierung als jemandes Stellvertreter verwendet wurde. Ich hatte Protokolle von anonymen Benutzern und niemandem, die sich über SSH an- und abmelden, und die CPU-Auslastung war buchstäblich außerhalb des Diagramms.

Auf jeden Fall habe ich es neu installiert und alles, was ich wusste, erneut angewendet, um zu testen, ob es erneut vorkommt. Innerhalb von 24 Stunden nach der Neuinstallation glaube ich, dass dies der Fall war.

Hier sind die jeweiligen Protokolle, aus /var/log/auth.logdenen ich mich paranoid fühle:

Oct 31 06:30:21 vultr su[24157]: Successful su for nobody by root Oct 31 06:30:21 vultr su[24157]: + ??? root:nobody Oct 31 06:30:21 vultr su[24157]: pam_unix(su:session): session opened for user nobody by (uid=0) Oct 31 06:30:21 vultr systemd: pam_unix(systemd-user:session): session opened for user nobody by (uid=0) Oct 31 06:30:21 vultr systemd-logind[503]: New session 40 of user nobody. Oct 31 06:30:24 vultr su[24157]: pam_unix(su:session): session closed for user nobody Oct 31 06:30:24 vultr systemd-logind[503]: Removed session 40. 

Ich war nicht derjenige, der sich morgens um 6:30 Uhr authentifizierte, also bin ich natürlich besorgt, dass ich irgendwo wieder versaut habe ...

(Anmerkung: .bash_historyvon rootzeigt nichts verdächtiges, und soweit ich weiß, hat der Benutzer nobodykeine .bash_history- korrigieren Sie mich, wenn ich falsch liege)

Die Kennwortauthentifizierung ist für SSH deaktiviert, es ist nur die SSH-Schlüsselauthentifizierung möglich, weshalb ich wirklich verwirrt bin, was als nächstes probiert werden soll, da es immer noch jemand geschafft hat, Zugriff zu erhalten (denke ich).

Ich habe diesen Artikel über einen phpMyAdmin-Exploit gelesen, bei dem der Angreifer Zugriff auf den Benutzer "nobody" erhalten hat. Ich glaube jedoch nicht, dass dies auf meinen Fall zutrifft, da laut meinen Apache-Protokollen keine Versuche unternommen wurden, auf die phpMyAdmin-Seite zuzugreifen, ganz zu schweigen davon, dass der Artikel aus dem Jahr 2010 stammt und meine phpMyAdmin-Seite momentan noch nicht verfügbar ist .

Die Art der Anfragen, die Apache erhält, beunruhigt mich jedoch ein wenig. Hier ein Beispiel (von /var/log/apache2/access.log):

192.99.144.140 - - [31/Oct/2015:03:43:48 +0000] "PROPFIND /webdav/ HTTP/1.1" 405 569 "-" "WEBDAV Client" 185.25.151.159 - - [31/Oct/2015:03:59:35 +0000] "GET http://testp2.czar.bielawa.pl/testproxy.php HTTP/1.1" 404 460 "-" "Mozilla/5.0 (Windows NT 5.1; rv:32.0) Gecko/20100101 Firefox/31.0" 61.228.95.69 - - [31/Oct/2015:09:07:39 +0000] "CONNECT 126mx00.mxmail.netease.com:25 HTTP/1.0" 405 536 "-" "-" 185.25.151.159 - - [31/Oct/2015:09:15:13 +0000] "GET http://testp4.pospr.waw.pl/testproxy.php HTTP/1.1" 404 457 "-" "Mozilla/5.0 (Windows NT 5.1; rv:32.0) Gecko/20100101 Firefox/31.0" 

während ich etwas mehr erwarten würde:

my ip - - [31/Oct/2015:14:47:58 +0000] "GET / HTTP/1.1" 200 589 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.130 Safari/537.36" 

Ich verstehe nicht, was durch den Versuch erreicht wird

"GET http://testp4.pospr.waw.pl/testproxy.php"

von meinem Server. Es gibt keine solche Datei oder ein solches Verzeichnis in/var/www/html

Ich liste alle Dinge auf, die ich unternommen habe, um nach der Neuinstallation sicher zu bleiben. Bitte machen Sie darauf aufmerksam, wenn Sie der Meinung sind, dass ich etwas falsch gemacht habe oder wenn Sie überhaupt nichts getan haben.

Was ich getan habe:

  1. Neuinstallation von Ubuntu 15.04
  2. Öffentliches und privates Schlüsselpaar generieren
  3. Fügen Sie meinen öffentlichen Schlüssel zu meiner authorized_keysDatei auf meinem Server hinzu
  4. Ändern Sie diese Einstellungen in /etc/ssh/sshd_config, um die Kennwortauthentifizierung zu deaktivieren und nur die SSH-Schlüsselauthentifizierung zuzulassen

    PermitRootLogin without-password RSAAuthentication yes PubkeyAuthentication yes PasswordAuthentication no 
  5. Starten Sie neu

  6. Installiere die Dinge, die ich brauche, in dieser Reihenfolge:

    zip  unzip  apache2 mysql-server php5 libapache2-mod-php5 openjdk-7-jdk gcc g++ screen vsftpd auditd 
  7. Entfernen Sie den Standard /var/www/html/index.html

  8. Konfigurieren Sie vsftpd für die Arbeit (ich habe ein starkes Passwort für FtpUser). Ich bin diesem Tutorial von DigitalOcean gefolgt

    mkdir /home/proj groupadd ftp-users chown root:ftp-users /home/proj chown root:ftp-users /var/www useradd -g ftp-users -d /home/proj FtpUser chown FtpUser /home/proj passwd FtpUser (add strong password) 

    Ich habe diese Einstellungen in geändert /etc/vsftpd.conf

    anonymous_enable=NO local_enable=YES write_enable=YES chroot_local_user=NO pam_service_name=ftp 
  9. Starten Sie neu

Alles andere, was ich nicht erwähnt habe, ist standardmäßig eingestellt, die gesamte installierte Software ist auf dem neuesten Stand.

Bitte lassen Sie mich wissen, ob die Protokolle, die ich zuvor gezeigt habe, ein Grund zur Sorge sind. Ich wäre auch sehr dankbar, wenn Sie mir sagen könnten, ob meine Konfiguration falsch ist und was ich tun kann, um meine Sicherheit weiter zu verbessern. Wenn Sie darüber hinaus gute Artikel zu diesem Thema kennen, wäre dies auf lange Sicht sehr hilfreich.

7
Weitere Informationen zum Benutzer "niemand": https://askubuntu.com/questions/329714/what-is-the-purpose-of-the-nobody-user vor 8 Jahren 0
@AustinHartzheim Danke für den Link! vor 8 Jahren 0

1 Antwort auf die Frage

0
Stuart Cardall

Führen Sie hiawatha Webserver als reverse proxyvor Ihrem Webserver. Es wird Exploits wie diese blockieren (sie werden als " Müll " blockiert ) in den Protokollen:

91.196.50.33|Sat 19 Mar 2016 21:12:15 +0000|GET http://testp3.pospr.waw.pl/testproxy.php HTTP/1.1 Host: testp3.pospr.waw.pl Proxy-Connection: Keep-Alive User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:32.0) Gecko/20100101 Firefox/31.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: pl,en-US;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate 

Führen Sie den Webserver und das Proxy in separaten lxcContainern aus, um die Prozesse weiter zu isolieren.

Verwenden Sie die integrierte chrootFunktion php-fpm.

Stellen Sie KEINEN zur shellVerfügungchroot

Stealth deinen sshHafen .

Montiere dein /var/www/public_htmlals noexec nosuid nodev.