nicht angemeldet
Moin!
Alles rund um Webserver. Angriffe zu im einzelnen zukenne und präventiv maßnahmn zu ergreifen. Wie gesagt mir geht es um den Webserver!
Wenn es sich um ungezielten, automatischen Angriff einen Webserver handelt, dann kann man wegen der Vielzahl solcher Fälle durchaus davon ausgehen, dass vor einem erfolgreichen Angriff eine Reihe 404er Fehler erzeugt werden. Der Angreifer spielt nämlich regelmäßig eine Reihe von Schwachpunkten durch.
1. Methode der Abwehr: fail2ban & Co.
Man kann also die Logfiles beobachten. Da nun niemand den ganzen Tag da sitzen will und auf ein Terminal, in welchem
tail -f /var/log/apache2/error.log
läuft, starren will übernimmt z.B. fail2an das.
Hier der Inhalt von /etc/fail2ban/filter.d/apache-noscript.conf
# Fail2Ban filter to block web requests for scripts (on non scripted websites)
#
#
[INCLUDES]
# overwrite with apache-common.local if _apache_error_client is incorrect.
before = apache-common.conf
[Definition]
failregex = ^%(_apache_error_client)s ((AH001(28|30): )?File does not exist|(AH01264: )?script not found or unable to stat): /\S*(\.php|\.asp|\.exe|\.pl)\s*$
^%(_apache_error_client)s script '/\S*(\.php|\.asp|\.exe|\.pl)\S*' not found or unable to stat\s*$
ignoreregex =
# DEV Notes:
#
# https://wiki.apache.org/httpd/ListOfErrors for apache error IDs
#
# Second regex, script '/\S*(\.php|\.asp|\.exe|\.pl)\S*' not found or unable to stat\s*$ is Before http-2.2
#
# Author: Cyril Jaquier
Angeschaltet wird dieser Filter mit etwas wie
[apache-overflows]
enabled = true
port = http,https
filter = apache-overflows
logpath = /var/log/apache*/*error.log
findtime = 600
maxretry = 2
in der Datei /etc/fail2ban/jail.conf
failtoban sucht also (siehe den Regex) nach Zugriffen auf nicht vorhandene Skripte in einem definierten Zeitraum (hier: 10 Minuten) und stoppt im Erfolgsfall dann den Netzwerkverkehr in dem es die Firewall anweist, für eine Weile den künftigen Datenverkehr von und zum mutmaßlichen Angreifer zu blockieren.
2. Methode der Abwehr: Honeypot
Nach einigem Lesen in Logfiles habe ich mir einen Honeypot "geschnitzt".
Aber dieser funktioniert nur dann wenn der Angreifer eine bereits bekannte Angriffsmethode benutzt. Er beruht ebenfalls darauf, dass Angreifer zunächst erfolglos ihm bekannte aber auf dem System nicht vorhandene Sicherheitslücken testet. Wird das fest gestellt, dann wird der Datenverkehr hier durch einen Eintrag in .htaccess blockiert. Es ist aber (mit root-Rechten!) machbar auch die Firewall zu bemühen.
3. Methode: Kopf zum Nachdenken benutzen
Schlicht und einfach nicht darauf vertrauen, dass Skripte aus merkwürdigen Quellen funktionieren. Bei Wordpress und Joomla auch darauf achten, was Designs oder Templates so an Includes mitbringen und diese intensiv prüfen. Oder auf derart durchseuchte Software ganz verzichten.
Dieses ist die Abstand wirksamste. Aber eben teuer und zeitaufwendig. Viele wollen das nicht investieren und haben dann die "Arschkarte".
4. Methode: Sicherheitsmeldungen lesen
Darauf achten, dass installierte Software (CMS & andere Webskripte zählen dazu) aktuell ist und auf Meldungen in der Presse achten, ggf. auch entsprechende Newsletter und Ankündigungen der Hersteller abbonnieren und lesen.
Kombination: Intelligenz kaufen
Leider gerät man da oft an Buzzwortbläser. Die haben aber tolle Bescheinigungen. Geht's darum, dem Chef im Falle des Falles zu beweisen, dass man "alles" getan hat, dann engagiere man den mit den meisten Zertifikaten...
Aber auch das Intelligenz kaufen kann man auslagern. Einfach einen "Managed Server" mieten. Klar ist das teurer, aber dann hat man auch den Service mit gebucht.
Jörg Reinholz
Der Martin
Tabellenkalk
Matthias Apsel