Angriff vom eigenen Webserver

standi · 21. Oktober 2014

Hallo Leute,

ich habe soeben vom Provider eine Email erhalten, dass von meinem dedizierten Server (Debian) ein Angriff stattfand mit folgendem Auszug:

##########################################################################
# Netscan detected from host xx.xx.xx.xx #
##########################################################################

time protocol src_ip src_port dest_ip dest_port
---------------------------------------------------------------------------
Tue Oct 21 02:49:56 2014 TCP xx.xx.xx.xx 57581 => xx.16.35.7 7777
Tue Oct 21 02:49:56 2014 TCP xx.xx.xx.xx 35246 => xx.16.35.13 7777
Tue Oct 21 02:49:56 2014 TCP xx.xx.xx.xx 35196 => xx.16.35.14 7777
Tue Oct 21 02:49:56 2014 TCP xx.xx.xx.xx 54060 => xx.16.35.17 7777

Der Server befand sich seither in Grundstellung, außer dass zusätzlich noch ISPConfig installiert wurde, um ein paar Webseiten zu verwalten. Bisher sind es nur 2 Webseiten aufgesetzt mit Joomla.

Ich habe nun Joomla und ISPConfig aktualisiert und wollte auch ein update von Debian durchführen. Ich erhalte aber folgende Fehlermeldung:

Code:

Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue [Y/n]? Y
Setting up openssh-server (1:5.5p1-6+squeeze5) ...
grep: line too long
insserv: warning: script is corrupt or invalid: /etc/init.d/../rcS.d/S76watchdog

/etc/init.d/ssh: xmalloc: ../bash/parse.y:5874: cannot allocate 1577058285 bytes (4295020544 bytes allocated)
invoke-rc.d: initscript ssh, action "restart" failed.
dpkg: error processing openssh-server (--configure):
 subprocess installed post-installation script returned error exit status 2
configured to not write apport reports
                                      Errors were encountered while processing:
 openssh-server
E: Sub-process /usr/bin/dpkg returned an error code (1)

Sagt das euch etwas?

Festgestellt habe ich auch, dass es in /etc/init.d folgende seltsame Dateien gibt, die mir bisher nie aufgefallen sind:

---------- 1 root root 417 Oct 21 01:05 sed0gTFiy
---------- 1 root root 417 Oct 21 00:22 sed0iJ8Jp
---------- 1 root root 417 Oct 21 01:07 sed1ur7Wl
---------- 1 root root 417 Oct 21 00:29 sed44rAKL
---------- 1 root root 417 Oct 21 00:40 sed4SgVUi
---------- 1 root root 417 Oct 21 00:25 sed5FwSRZ
---------- 1 root root 417 Oct 21 00:51 sed7QGzO1
---------- 1 root root 417 Oct 21 00:59 sedApIFVS
---------- 1 root root 417 Oct 21 00:27 sedcDkIpN
---------- 1 root root 417 Oct 21 01:13 sedINrSPV
---------- 1 root root 417 Oct 21 00:38 sedj7FHIs

Lawnmower · 21. Oktober 2014

Hat der Provider nichts genaueres geschrieben, nur mit dem Auszug da kann man ja nicht viel anfangen.

Sieht so aus als hättest Du zuwenig RAM oder Speicherplatz (zumindestens sieht die Meldung in Zeile 13 so aus).
Vielleicht hat irgendein Programm auch den Speicher gefüllt oder sowas ähnliches.

Und ganz ehrlich: Wenn man keine fundierten Kenntnisse hat wie man einen Webserver (und ein CMS) anständig und sicher betreiben kann, sollte man tunlichst die Finger davon lassen.
Dazu sagt Daaron bestimmt noch was wenn er hier reinschaut aber für solche Sachen kann man u.U. haftbar gemacht werden.

miwob · 21. Oktober 2014

Abgesehen davon, dass diese Informationen nicht viel nützen, musst du in erster Linie davon ausgehen, dass die Kiste möglicherweise kompromittiert ist. Joomla und ISPConfig Updates kannst du dir demnach sparen. Das einzig sinnvolle was du jetzt tun musst, ist die Kiste platt machen und neu aufsetzen.

HominiLupus · 21. Oktober 2014

Was steht in diesen init.d Skripten denn drin?

openssh-server (1:5.5p1-6+squeeze5)

Du betreibst noch ernsthaft einen Squeeze Debian server und wunderst dich das du Schadsoftware einfängst? Du brauchst ein aktuelles und mit Sicherheitsupdates unterstütztes Debian. Also Wheezy.

Eigentlich sollte man dir den Vertrag kündigen bis du lernst wie man einen Server betreibt, sorry.

moshimoshi · 21. Oktober 2014

An der Fehlermeldung: allein sieht man das jemand zugrief gehabt hat.
Das kann Ich dir auch so sagen dazu wäre eine Rückmeldung vom ISP nicht nötig.

Die einfachste methode neu aufsätzen und diesmal die Security überarbeiten.

NiThDi · 21. Oktober 2014

HominiLupus schrieb:
Du betreibst noch ernsthaft einen Squeeze Debian server und wunderst dich das du Schadsoftware einfängst? Du brauchst ein aktuelles und mit Sicherheitsupdates unterstütztes Debian. Also Wheezy.

Debian Squeeze hat soweit ich weiß LTS support bis Februar 2016. Nun ist die Frage, ob er die LTS Paketquellen hinzugefügt hat, weil das manuell geschehen muss. Daher ist das Update auf Wheezy nicht unbedingt notwendig.

Dass der Server aber in der Grundeinstelung gelassen wurde, find ich jetzt auch nicht so berauschend... Wurde denn wenigstens der SSH Port geändert und root Login verboten? Oder besser sogar Login nur per Zertifikat? Ab und an mal ein apt-get upgrade durchgeführt?

Edit: Sieht jan icht so aus - daher: Daten sichern, Platt machen und von vorne anfangen.

Bisumaruku · 21. Oktober 2014

---------- 1 root root 417 Oct 21 01:05 sed0gTFiy
---------- 1 root root 417 Oct 21 00:22 sed0iJ8Jp
---------- 1 root root 417 Oct 21 01:07 sed1ur7Wl
---------- 1 root root 417 Oct 21 00:29 sed44rAKL
---------- 1 root root 417 Oct 21 00:40 sed4SgVUi
---------- 1 root root 417 Oct 21 00:25 sed5FwSRZ
---------- 1 root root 417 Oct 21 00:51 sed7QGzO1
---------- 1 root root 417 Oct 21 00:59 sedApIFVS
---------- 1 root root 417 Oct 21 00:27 sedcDkIpN
---------- 1 root root 417 Oct 21 01:13 sedINrSPV
---------- 1 root root 417 Oct 21 00:38 sedj7FHIs

Das hatte ich mal auf nem Raspberry Pi der von außen erreichbar war und Standardpasswörter hatte

Keine Chance das wieder grade zu ziehen. Der Server wurde "gehackt" bzw. jemand hat sich unberechtigten Zugriff verschafft und dir dein ganzes System verwurstet. Die meisten Dateien kann man löschen, aber die liegen überall, auch in /etc/ und teilweise nicht löschbar.
Einzige Chance, alles Sichern was dir heilig ist und den Server resetten!

Daaron · 21. Oktober 2014

HominiLupus schrieb:
Was steht in diesen init.d Skripten denn drin?

Spielt keine Rolle. Die Maschine ist kompromittiert, alle Geheimnisse sind als "offengelegt" anzusehen, keinem Dienst kann mehr vertraut werden...
Wozu also analysieren, wenn die einzige Lösung "ABREISSEN" lautet?

Die Maschine wurde gehackt, also mach sie platt!

Du betreibst noch ernsthaft einen Squeeze Debian server und wunderst dich das du Schadsoftware einfängst?

Squeeze ist LTS und hat somit grob genauso lange Support wie Wheezy (das noch kein LTS erhalten hat). Es ist vollkommen in Ordnung, noch auf Squeeze zu setzen, auch wenn es schlichtweg besser geht.
Debian als Server-OS ist halt allgemein fragwürdig, eben weil die LTS-Situation in der Schwebe hängt. Ubuntu und CentOS bieten da deutlich verlässlichere Laufzeiten.

standi · 21. Oktober 2014

Hallo Leute,

ich hatte Squeeze genommen, weil dies so vom Provider bereitgestellt wurde. (LTS)
Ich hätte aber auch kein Problem auf Ubuntu umzusteigen, wobei die sich untereinander nicht wirklich viel schenken. Ich mache nun den Server komplett platt und setze ihn erneut (minimal wie möglich) auf.

ISPConfig würde ich vermutlich erneut installieren, da ich es zum administrieren angenehm fand. SSH Port wird dann geändert und kein ROOT-Zugriff mehr erlaubt. Zertifikat war bereits aktiviert. Gibt es sonst noch irgendwelche Vorkehrungen oder Tools die ihr mir empfehlen würdet?

Lawnmower · 21. Oktober 2014

Ja, wenns unbedingt Joomla sein muss dann auch regelmässig updaten und Security Setup Guidelines beachten (nicht einfach runterladen und hopp).

Daaron · 21. Oktober 2014

standi schrieb:
ich hatte Squeeze genommen, weil dies so vom Provider bereitgestellt wurde. (LTS)

Das ist kein Argument. Bei den verfügbaren Bandbreiten ist ein neues System in ner halben Stunde grundlegend aufgesetzt.

Ich hätte aber auch kein Problem auf Ubuntu umzusteigen, wobei die sich untereinander nicht wirklich viel schenken.

Das is totaler Bullshit.

Ubuntu 14.04 bietet (sowohl gegenüber Wheezy als auch Squeeze):
- Support bis 2019
- Kernel 3.13 (und bald kommt der neue Backport *freu*).... nicht solche Steinzeit-Kernel wie bei Debian.
- Apache 2.4 statt 2.2. Das gibt nicht nur Zugriff auf mod_proxy_fcgi für meeeehr Performance (z.B. für PHP-FPM), sondern gleichzeitig lässt sich mit Apache 2.4 wenigstens Elliptic Curve Diffie-Hellman nutzen. Das hat mit den 2.2-Paketen von Debian7 oder Ubuntu 12.04 nie funktioniert und bietet einen hübschen Sicherheitsvorteil gegenüber RSA_DHE.
- PHP 5.5 inkl. Zend Cache (RIESIGER Vorteil)
- MariaDB 10 statt veralteter MySQL5 - Versionen. MariaDB 10 ist MySQL in allen Belangen weit überlegen.
- OpenSSL Version 1.0.1f inklusive TLS_FALLBACK_SCSV. Im Hinblick auf POODLE und ähnlich geartete Attacken eigentlich ein Must-Have.

ISPConfig würde ich vermutlich erneut installieren, da ich es zum administrieren angenehm fand.

Kann man ja auch nutzen, wenn man es vernünftig absichert.... WENN!

Gibt es sonst noch irgendwelche Vorkehrungen oder Tools die ihr mir empfehlen würdet?

1.) Lesen! Lesen! Lesen! Wenn du in obiger Vorteile-Liste auch nur ein Fragezeichen im Hirn hattest, dann musst du dich weiter bilden.
2.) Fail2Ban. Einfach nur nützlich, wenn man es sauber (und scharf) konfiguriert.
3.) RKHunter. Kein Nobrainer, aber definitiv nützlich
4.) Unattended Upgrades (natürlich sauber konfiguriert)

standi · 8. November 2014

Danke für die Tipps. Was habe ich bisher getan:

Ubuntu mit 14.04-trusty-64-minimal aufgesetzt
Install php5 libapache2-mod-php5 apache2
Zu Testzwecken wurde als Serververwaltungssoftware "LiveConfig" installiert mit folgenden Zusatzpaketen. Werde das aber vermutlich rausschmeißen:
- MariaDB (Hat aber als Extra-Packages auch MySQL 5.5.39 installiert)
- vsftpd + db5.3-util
- Anschließend vsftpd desinstalliert und proftpd installiert, weil LiveConfig die Konfiguration von vsftpd nicht gepacken bekommen hat.
Port von SSH verlegt
Shell User angelegt und direkten Root-Login deaktiviert
ssh-keygen -b 4096 erstellt und Login über Zertifikat eingerichtet. (Passwort-Login muss noch deaktiviert werden + Shell-Login nur diesem einen User erlauben
Bin noch am Überlegen, ob ich su generell deaktivieren soll, also kein Passwort für root setzen. Dann müsste ich aber noch sudoers konfigurieren

Desweiteren überlege ich mir, ob ich eine Email-Benachrichtigung einrichten soll, wenn man sich auf den Server einloggt. Dazu müsste ich jedoch ssmtp oder mailutils + postfix installieren, wo die Gefahr da ist, dass der Server als Spam-Schleuder fungiert. Der Server bräuchte auch garkeinen Email-Server, außer evtl. diese Benachrichtigung und Emails/Kontaktformulare aus den Webseiten heraus.
Die Dienste wie FTP, LiveConfig (Später evtl. eine andere Software oder garkeine) würde evtl. sogar immer deaktivieren und sie nur aktivieren, wenn ich aktiv diese brauche.
In Fail2Ban muss ich mich noch einlesen und entsprechend installieren
Bzgl. regelmäßige Updates überlege ich mir, ob ich dies automatisch über cronjobs machen lassen soll oder apticron einsetzen, um benachrichtigt zu werden und manuell die Updates durchzuführen.
Später müssen dann wieder die 2-3 Joomla-Webseiten eingerichten werden.

Ich hoffe, dass ich auf dem richtigen Weg bin.

Daaron · 8. November 2014

standi schrieb:
[*]Install php5 libapache2-mod-php5 apache2

mod-php ist nur ein Notnagel. Eigentlich kann/solllte man mod-php nur in Verbindung mit Apache2-MPM-ITK verwenden. Andernfalls reißt man derbe Sicherheitslücken in Webseiten.

[*]In Fail2Ban muss ich mich noch einlesen und entsprechend installieren

Was gibt es da einzulesen? Die Basis-Config ist schon ziemlich gut. Installieren und fertig.

[*]Bzgl. regelmäßige Updates überlege ich mir, ob ich dies automatisch über cronjobs machen lassen soll oder apticron einsetzen, um benachrichtigt zu werden und manuell die Updates durchzuführen.

Das Zaubewort heißt Unattended Upgrades.

standi · 8. November 2014

Hi,

mod-php ist nur ein Notnagel. Eigentlich kann/solllte man mod-php nur in Verbindung mit Apache2-MPM-ITK verwenden. Andernfalls reißt man derbe Sicherheitslücken in Webseiten.

Entwickelt wird garnicht direkt auf dem Server. Laut folgendem Artikel stellt MP-ITK im Livebetrieb sogar ein Sicherheitsrisiko dar.
http://web-rocker.de/2011/01/apache-2-itk-mpm
Was sagst du dazu?

Das Zaubewort heißt Unattended Upgrades.

Problem ist, wenn aufgrund mancher Updates irgendwelche Scripte oder Webseiten nicht mehr funktionieren sollten, wenn diese automatisch durchgeführt werden. Gut wäre natürlich eine Email-Benachrichtigung, welche Programme geupdatedt werden. Bin mir aber weiterhin noch unsicher, ob ich mailutils oder ähnliches einrichten sollte. (ClamAV, SpamAssassin, DNS-Blacklists brauche ich ja eigentlich garnicht, wenn postfix als "Satellite System" eingerichtet ist, da man ja keine Emails empfangen kann)

Ansonsten stelle ich, wie im vorherigen Post angedeutet, root nicht inaktiv, um dem bestimmten Benutzer über sudoers die entsprechenden Rechte einzuräumen.

Daaron · 8. November 2014

standi schrieb:
Entwickelt wird garnicht direkt auf dem Server. Laut folgendem Artikel stellt MP-ITK im Livebetrieb sogar ein Sicherheitsrisiko dar.

Ein hypothetisches Problem, das mir durchaus bekannt ist.
Praktisch würde hier nur ein Problem existieren, wenn tatsächlich ein Exploit existiert, der den Hauptprozess des Apachen übernehmen und für böswillige Zwecke ausnutzen kann. Da so ein Exploit nicht existiert... scheiß drauf. Dafür hat man mit ITK eine schöne Fire&Forget - Lösung, um ohne Konfigurationsaufwand (3-4 sehr kurze zusätzliche Zeilen in der VHost Conf nenn ich nicht "Aufwand") die verschiedenen VHosts voneinander abzuschotten.

- MPM-ITK ist einen Hauch langsamer als MPM-Prefork, dafür viel flexibler
- MPM-ITK ist signifikant langsamer als MPM-Worker, aber dafür anders als Worker+FCGI eben n Nobrainer beim Setup
- MPM-ITK + mod_php funktioniert mit OpCode-Caches, das macht mod_suphp z.B. nicht

Problem ist, wenn aufgrund mancher Updates irgendwelche Scripte oder Webseiten nicht mehr funktionieren sollten, wenn diese automatisch durchgeführt werden.

Das ist mir noch nie passiert... Alles, was bei Ubuntu LTS über die Security Updates kommt, ist auch stabil wie Sau. Noch nie hatte ich da ein Problem, in x-wieviel Jahren jetzt.
Ubuntu LTS ist mindestens genau so stabil wie Debian.

standi · 8. November 2014

Supi, hört sich echt gut an.

Könntest du noch zum Abschluss mir kleine Informationen zur Email-Benachrichtigung geben, bzw. bestätigen, ob ich mit folgender Annahme richtig liege:

[..] (ClamAV, SpamAssassin, DNS-Blacklists brauche ich ja eigentlich garnicht, wenn postfix als "Satellite System" eingerichtet ist, da man ja keine Emails empfangen kann)

Viele Grüße

Daaron · 9. November 2014

nä, sorry. bei der postfix-config muss ich auch immer nachlesen.

Angriff vom eigenen Webserver

Lt. Junior Grade

Maître de cuisine

Lt. Junior Grade

Banned

Captain

Lt. Commander

Lt. Commander

Fleet Admiral

Lt. Junior Grade

Maître de cuisine

Fleet Admiral

Lt. Junior Grade

Fleet Admiral

Lt. Junior Grade

Fleet Admiral

Lt. Junior Grade

Fleet Admiral

Ähnliche Themen

Passend zum Thema