Apache2 access.log automatisierte Hack Versuche.

[seven81]

Guten Abend,
ich habe seltsame Einträge in den access.log von apache2.
Hier ein kleiner Beispiel:

Code: Alles auswählen

45.155.205.108 - - [26/Dec/2020:23:37:40 +0000] "GET /console/ HTTP/1.1" 404 460 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"
45.155.205.108 - - [26/Dec/2020:23:37:40 +0000] "GET /wp-content/plugins/wp-file-manager/readme.txt HTTP/1.1" 404 460 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"
45.155.205.108 - - [26/Dec/2020:23:37:41 +0000] "GET /?a=fetch&content=<php>die(@md5(HelloThinkCMF))</php> HTTP/1.1" 200 644 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"

Ich weiß das daß sehr wahrscheinlich automatisierte Programme tun. Kann ich irgendwie alle IP Adressen die nicht aus DE Stämmen filtern, oder gibt's da proffiesionelle Lösungen.

Meine OS ist Raspbian mit PHP 7, mariadb und apache2.

Danke.

[novalix]

Hi,
so seltsam sind die Einträge nicht. Wie Du ja schon richtig erkannt hast, sind das automatisierte Verbindungsversuche nach dem Gießkannenprinzip.
So lange Du Deinen Apache vernünftig konfiguriert hast (d.h. keine Zugriffe außerhalb Document Root) und keine löchrigen Versionen der meist angegriffenen Software (hier: Wordpress und ThinkPHP) verwendest, passiert genau nichts ausser den Einträgen ins Log.
Nichtsdestotrotz kann man mit einer Kombination aus libapache2-mod-security2, modsecurity-crs und fail2ban solche Einträge erkennen und die jeweiligen IPs sperren.
Das ist allerdings recht aufwendig, fehleranfällig (false positives) und verbraucht Rechenkapazität, die an anderen Stellen gebraucht werden könnte. Außerdem werden solche Gießkannenversuche üblicherweise von Botnets gefahren, die naturgemäß mit einem großen Zoo an IPs um die Ecke kommen.

[seven81]

OK, danke. Ich verwende keine CMS. Außerhalb von document root hat keiner Zugriff, außer ein PHP Script darf auf Home zugreifen wo er per exec ein Python Script ausführt. Das PHP Script darf nur dann ausgeführt werden wenn die Session gesetzt ist.

[incredibletimbo]

Außerdem werden solche Gießkannenversuche üblicherweise von Botnets gefahren, die naturgemäß mit einem großen Zoo an IPs um die Ecke kommen.

Bei verstreuten Bots spare ich mir das auch, das lohnt sich nicht. Aber massenhafte Zugriffe aus den immer gleichen Subnetzen werden automatisch ausgesperrt mit fail2ban-subnets, zu finden unter https://github.com/XaF/fail2ban-subnets. Da fallen schon mal fernöstliche Fachhochschulen mit Klasse B- und C- Subnetzen auf, die reihenweise geleakte Passwörter durchprobieren.

Ich bin gut zufrieden damit, mein spartanischer vServer hat jetzt mehr Zeit, sich zu langweilen!

[unitra]

Ich setze gerne sshguard ein. Primär für SSH blocking, das funktioniert aber nicht mit Apache. Fail2ban ist die Lösung, aber die iptables database wird irgendwann mal richtig groß und die Ressourcen umd Hundertausende Hosts einzenl zu Blocken, macht dann später wenig Sinn, weil das dann zähflüssig ist und die Ressourcen CPU/RAM einfach sich besser nutzen lassen.-

Zum Schluß bin ich dazu übergegangen große Netzeblöcke per ip route blackhole zu blocken, weil iptables zu teuer ist und die Liste auch unheimlich lang war mit über 100.000 geblockten /32 Netzen. Das geht auch einfacher.

Das sieht dann zum Beispiel so aus:

Code: Alles auswählen

ip route add blackhole 167.88.0.0/20
ip route add blackhole 1.0.1.0/24
ip route add blackhole 1.0.2.0/23
ip route add blackhole 1.0.8.0/21
ip route add blackhole 1.0.32.0/19
ip route add blackhole 1.1.0.0/24
ip route add blackhole 1.1.2.0/23
ip route add blackhole 1.1.4.0/22
ip route add blackhole 1.1.8.0/21
ip route add blackhole 1.1.16.0/20
ip route add blackhole 1.1.32.0/19
...

Code: Alles auswählen

more blackhole_nets.sh | wc -l
5516

Über 5500 Netze sind geblockt. Wie man erkennen kann sind kleinere Netze als /24 sind da nicht drin. Größtenteils sind das APNIC Netze da enthalten aber nur deswegen weil die so viel Last erzeugen dass das nicht mehr schön ist. Bootet der Knoten, dann gibt es einen cronjob der @reboot die blackhole_nets.sh Datei wieder ausführt. Damit ist auch die iptables Datebank richtig klein und performant geworden.

[schwedenmann]

Hallo


Und was in Bezug auf Attacken hiervon zu halten

https://packages.debian.org/unstable/endlessh


mfg
schwedenmann

[incredibletimbo]

Hi Schwedenmann,
das klingt abgesehen von "security through obscurity" ganz interessant, vermutlich teste ich das mal bei meinem Heimserver. Der hat fast ausschließlich mit ssh zu tun.

SSH-seitige Maßnahmen bringen mich beim Webserver mit postfix, dovecot und 2 joomla-Instanzen nicht wirklich weiter. Danke trotzdem für den Hinweis!

[incredibletimbo]

Zum Schluß bin ich dazu übergegangen große Netzeblöcke per ip route blackhole zu blocken, weil iptables zu teuer ist und die Liste auch unheimlich lang war mit über 100.000 geblockten /32 Netzen. Das geht auch einfacher.

Mein nftables-Regelsatz des Web- und Mailservers ist gerade 344 Zeilen lang. Die geblockten Subnetze sind minimal 29 Bits groß, mehrheitlich größer. Sicher blocke ich einige Leute mehr oder weniger, aber auf Kunden aus Fernost können meine beiden Kundinnen gut verzichten - die niemals im normalen Server-Log landen und ausschließlich mit Schabernack auffallen. Ich mache Stichproben.

fail2ban einzurichten und zu pflegen ist anfangs nicht ganz trivial, aber es erschlägt halt alle Serverdienste, wenn man denn will. Zu Beginn war ich direkt gezwungen, mir endlich reguläre Ausdrücke in den Kopf zu kloppen. War durchaus befriedigend!

[Lord_Carlos]

Code: Alles auswählen

sudo grep 'Invalid user' /var/log/auth.log* |wc -l
926

1000 Verbindungsversuche zu meinem SSHd in 2 Monaten

Code: Alles auswählen

sudo grep 'wp-content' /var/log/nginx/* |wc -l
8

Ist was es ist.
Ich habe teilweise China gesperrt. Eine Laenderliste zu machen war mit open source nginx nicht ganz so einfach. Haette gerne ganze Kontinente angegeben.

[MSfree]

1000 Verbindungsversuche zu meinem SSHd in 2 Monaten

Lächrlich

Ich hatte schon 35 Versuche in 7 Stunden an meinem privaten DSL-Anschluß seit heute morgen 6.40h. In der letzten Woche gab es im Schnitt 170 Versuche pro Tag. Aber die prallen alle gnadenlos an der Firewall ab.

[Lord_Carlos]

1000 Verbindungsversuche zu meinem SSHd in 2 Monaten

Lächrlich

Ich hatte schon 35 Versuche in 7 Stunden an meinem privaten DSL-Anschluß seit heute morgen 6.40h. In der letzten Woche gab es im Schnitt 170 Versuche pro Tag. Aber die prallen alle gnadenlos an der Firewall ab.

Oh, was ich vergessen habe: Port ist geaendert.
Ich glaube das hat einiges geholfen den log spam zu vermindern. Wuerde ich auch so anderen empfehlen, hilft kein Meter mit der Sicherheit, aber weniger spam

Ist auch Privat Anschluss hier.

[MSfree]

Oh, was ich vergessen habe: Port ist geaendert.
Ich glaube das hat einiges geholfen den log spam zu vermindern.

Naja, ich habe hier mein eigenes Sicherheitskonzept. SSH steht überhaupt nicht nach aussen offen. Ich habe einen Anklopfdienst davor gehängt, der ähnlich wie Portknocking den SSH-Port nur bei korrektem Anklopfen für die IP-Adresse der Anklopenden und dann für eine Minute aufmacht. Ich nehme allerdings kein Portknocking sondern Ping-Knocking, weil ich Ping-Pakete praktisch von überall absetzen kann. Der Knocking-Daemon protokolliert netterweise alle Verbindungsversuche (auch unberechtigte) mit.

[ChrisGER]

@MSfree
das Thema SSH Loginversuche aus aller Welt, habe ich wie folgt eingedampft, ohne den Port zu ändern.
ich habe die UFW auf Debian 11 installiert und die Standard Regel für SSH (any source) auf die meines ISP eingeschrännkt. In meinem Fall hat meinn Provider ein /16 Segment für die DSL Einwahl in meiner geographischen Region. Dieses Netz habe ich für SSH 22/tcp freigeschaltet und damit sind die weltweiten logon Roboter ausgebremst. Da muss einer aus dem IP Segment Deines Providers kommen, damit er ein SSH Login Prompt bekommt.

Bei Apache suche ich selbst noch die eleganteste Lösung.

Gruß
Chris

[DeletedUserReAsG]

In meinem Fall hat meinn Provider ein /16 Segment für die DSL Einwahl in meiner geographischen Region. Dieses Netz habe ich für SSH 22/tcp freigeschalte

Viel Spaß, wenn dein Provider mal was ändert, oder du dich von unterwegs einloggen musst, oder so. Gerade bei SSH sind die Loginversuche doch allenfalls ein Ärgernis im Logfile, solange der Daemon ordentlich konfiguriert ist, und man Schlüssel statt Passphrases benutzt. Und selbst die Logeinträge wird man los, sobald man den Daemon auf einen der höheren Ports legt. Da gibt’s eigentlich keinen Grund, sich potentiell selbst auszusperren, denke ich. Zumindest ich hab auf mehreren Kisten seit Monaten nix vom sshd im Log, das ich nicht selbst produziert habe …

Was den Apache angeht – da liegt das Problem ja eher bei den Anwendungen, die darüber ausgeliefert werden, weniger am Daemon selbst. Gegen mehrfache Loginversuche hat sich fail2ban als nützlich erwiesen, das ist recht gut konfigurierbar. Nutzt natürlich nix, wenn jemand die Webanwendung mit dem ersten Versuch aufmacht – da hilft dann nur noch ein gutes Setup mit IDS, ordentlicher Rechteverwaltung (und idealerweise sowas wie SELinux) und so.

[mat6937]

In meinem Fall hat meinn Provider ein /16 Segment für die DSL Einwahl in meiner geographischen Region.

Wenn Du den ssh-Client auf einem Linux-System (oder gleichwertig) verwendest, kannst Du auch einen 5-stelligen source-Port festlegen und beim sshd-Server darauf achten/filtern. Was auch noch geht, ist das gesetzte ecn-Bit beim sshd-Server und beim ssh-Client. Denn es gibt kaum Portscans auf dem Port 22, mit gesetztem ecn-Bit.