Die Sache mit den Abuse-Meldungen
Gestern Abend war es wieder soweit: Etliche Abuse-Meldungen von verschiedenen Firmen und Institutionen trudelten per eMail an. Ursache dafür war die Teilnahme einer Benutzer-VM an Brute Force-Angriffen auf SSH-Daemons der Betroffenen.
Das normale Vorgehen bei Abuse-Meldungen ist wie folgt:
Liegen nur 1-2 Meldungen zu einem Zeitpunkt t vor, so sendet Hetzner die Meldungen per Mail an den Serverbetreiber, bittet um Abstellung des Problems und ein Statement zur Ursache.
Liegen hingegen mehrere Meldungen vor, so wie im gestrigen Fall, werden betroffene IP-Adresen oder Subnetze am Router von Hetzner gesperrt.
Offenbar waren die Mitarbeiter gestern etwas übereifrig und haben nicht nur die betroffene Einzel-IP gesperrt, sondern kurzerhand den gesamten Server physisch vom Netz getrennt.
Die eMail-Korrespondenz mit dem Support gestaltete sich durch die Verzögerungen des Ticket-Systems als etwas zäh, so dass der Server gestern von ca. 18:00 bis 23:00 vom Netz getrennt war.
Noch einmal die Hinweise zur sicheren Konfiguration der VM:
Die Punkte 1 - 6 des vorherigen Beitrags gelten weiterhin.
Zusätzlich sinnvoll:
-7- SSH Daemon absichern
Das Login - Verbot für den Benutzer root und Fail2Ban wurden bereits beschrieben. Weiterhin sinnvoll ist die Installation eines Port-Knocking Daemons, um Portscans abzuwehren und die Umstellung auf Key Based Authentication, an Stelle von Passwortauthentifizierung.
Wer von seinem ISP eine statische öffentliche IP-Adresse erhält und die VM nur von diesem Anschluss administriert, kann die Firewall auch dahingehend konfigurieren, dass Anfragen an Port 22 nur von eben dieser Quelladresse akzeptiert werden.
-8- Webserver absichern
Nicht minder gefährlich sind schlecht abgesicherte Webserver. Dass in komplexen Webanwendungen immer mal wieder Fehler gefunden werden, die sich dazu eignen schreibenden Zugriff auf den Webspace zu erlangen, ist kein Geheimnis. Hier gilt wieder Punkt 4. Besonders unangenehm ist ein solcher Fall jedoch dann, wenn Laufzeitumgebungen auf dem Webserver nicht abgesichert sind. Berühmtes Beispiel: Die Shell-Funktionen unter PHP.
Bei zukünftigen Abuse-Meldungen werde ich betreffende VMs sofort, bis zur Rückmeldung des administrierenden Nutzers abschalten - Das ist nicht böse gemeint, sondern geschieht zum Schutz aller Nutzer. Das Abschalten einer einzelnen kompromittierten VM ist im Sinne der Schadensminderung wohl sinnvoller als das Fremdabschalten des gesamten Servers.
Das normale Vorgehen bei Abuse-Meldungen ist wie folgt:
Liegen nur 1-2 Meldungen zu einem Zeitpunkt t vor, so sendet Hetzner die Meldungen per Mail an den Serverbetreiber, bittet um Abstellung des Problems und ein Statement zur Ursache.
Liegen hingegen mehrere Meldungen vor, so wie im gestrigen Fall, werden betroffene IP-Adresen oder Subnetze am Router von Hetzner gesperrt.
Offenbar waren die Mitarbeiter gestern etwas übereifrig und haben nicht nur die betroffene Einzel-IP gesperrt, sondern kurzerhand den gesamten Server physisch vom Netz getrennt.
Die eMail-Korrespondenz mit dem Support gestaltete sich durch die Verzögerungen des Ticket-Systems als etwas zäh, so dass der Server gestern von ca. 18:00 bis 23:00 vom Netz getrennt war.
Noch einmal die Hinweise zur sicheren Konfiguration der VM:
Die Punkte 1 - 6 des vorherigen Beitrags gelten weiterhin.
Zusätzlich sinnvoll:
-7- SSH Daemon absichern
Das Login - Verbot für den Benutzer root und Fail2Ban wurden bereits beschrieben. Weiterhin sinnvoll ist die Installation eines Port-Knocking Daemons, um Portscans abzuwehren und die Umstellung auf Key Based Authentication, an Stelle von Passwortauthentifizierung.
Wer von seinem ISP eine statische öffentliche IP-Adresse erhält und die VM nur von diesem Anschluss administriert, kann die Firewall auch dahingehend konfigurieren, dass Anfragen an Port 22 nur von eben dieser Quelladresse akzeptiert werden.
-8- Webserver absichern
Nicht minder gefährlich sind schlecht abgesicherte Webserver. Dass in komplexen Webanwendungen immer mal wieder Fehler gefunden werden, die sich dazu eignen schreibenden Zugriff auf den Webspace zu erlangen, ist kein Geheimnis. Hier gilt wieder Punkt 4. Besonders unangenehm ist ein solcher Fall jedoch dann, wenn Laufzeitumgebungen auf dem Webserver nicht abgesichert sind. Berühmtes Beispiel: Die Shell-Funktionen unter PHP.
Bei zukünftigen Abuse-Meldungen werde ich betreffende VMs sofort, bis zur Rückmeldung des administrierenden Nutzers abschalten - Das ist nicht böse gemeint, sondern geschieht zum Schutz aller Nutzer. Das Abschalten einer einzelnen kompromittierten VM ist im Sinne der Schadensminderung wohl sinnvoller als das Fremdabschalten des gesamten Servers.