Massiv attackierende IP Range

[Ralph]

Vorhin rausgefischt wg. aggressiver requests ... diese Range ist wohl gut aufgehoben in der Firewall oder IPset Blacklist, schaut euch mal die Anzahl der reports an:
https://www.abuseipdb.com/check-block/45.156.129.0/24

[Toorms]

Danke für die Info, habe sie bei mir mal mit aufgenommen.

[Ralph]

Noch zur Info, die requests waren gezielt auf das Panel ausgerichtet, die IP war in keinen User access.logs vorhanden ...

Code: Select all

# /var/log/apache2/keyhelp/access.log
45.156.129.110 - - [21/Jun/2024:13:29:55 +0200] "GET /Telerik.Web.UI.WebResource.axd?type=rau HTTP/1.1" 404 4537 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36"
45.156.129.110 - - [21/Jun/2024:13:30:11 +0200] "GET /cgi-bin/authLogin.cgi HTTP/1.1" 403 4540 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36"
45.156.129.110 - - [21/Jun/2024:13:30:31 +0200] "GET /showLogin.cc HTTP/1.1" 404 4537 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36"
45.156.129.110 - - [21/Jun/2024:13:30:45 +0200] "GET /static/historypage.js HTTP/1.1" 404 4537 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36"
45.156.129.110 - - [21/Jun/2024:13:31:02 +0200] "GET /ext-js/app/common/zld_product_spec.js HTTP/1.1" 404 4537 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36"
45.156.129.110 - - [21/Jun/2024:13:31:03 +0200] "GET /favicon.ico HTTP/1.1" 404 4537 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36"
45.156.129.110 - - [21/Jun/2024:13:31:13 +0200] "GET /cgi-bin/config.exp HTTP/1.1" 403 4540 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36"
45.156.129.110 - - [21/Jun/2024:13:31:18 +0200] "GET /cf_scripts/scripts/ajax/ckeditor/ckeditor.js HTTP/1.1" 404 4537 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36"
45.156.129.110 - - [21/Jun/2024:13:31:18 +0200] "GET /WebInterface/ HTTP/1.1" 404 4537 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36"
45.156.129.110 - - [21/Jun/2024:13:31:23 +0200] "GET /sugar_version.json HTTP/1.1" 404 4537 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36"

[24unix]

Hmm, keine für KeyHelp relevanten Routen.

Aber woher wissen die, was ein Panel ist, und was eine normale Seite?

[Blubby]

Aber woher wissen die, was ein Panel ist, und was eine normale Seite?

Das wissen die nicht und sie versuchen es einfach überall. Ist ja nicht so das das jemand per Hand macht.

[24unix]

Aber woher wissen die, was ein Panel ist, und was eine normale Seite?

Das wissen die nicht und sie versuchen es einfach überall. Ist ja nicht so das das jemand per Hand macht.

Anscheinend ja nicht:

Code: Select all

die IP war in keinen User access.logs vorhanden ...[sic]

[Alexander]

Die nehmen einfach die Server-IP und kommen damit nun mal bei KeyHelp raus.

[24unix]

Die nehmen einfach die Server-IP und kommen damit nun mal bei KeyHelp raus.

Das mach Sinn, ja. Danke.

[Ralph]

Die nehmen einfach die Server-IP und kommen damit nun mal bei KeyHelp raus.

Sehr wahrscheinlich ... ich dachte zuerst an eine übliche WP 404 Attacke, bei der Suche nach "45.156.129" in den User Logs gab es allerdings keine Treffer. Ich werde das Panel Log File trotzdem mal im Auge behalten könnte auch ein probing sein was darauf abzielt System Infos und Reaktionen auszuwerten. Das ist aber derzeit nichts ungewöhnliches und bei anderen Systemen ebenfalls zu beobachten.
## edit ###
Was mich etwas stutzig macht ist die Provider Info die man bei einer Google Suche findet
https://www.abuseipdb.com/check/45.156.129.2
Was haben diese Apache requests mit "Email Threat Intelligence" zu tun falls das ein Mail Pentesting sein sollte?

[Tobi]

Ihr denkt euch da viel zu viel.

Da werden einfach stumpf die üblichen Verdächtigen durchprobiert. Und wenn der Pfad tatsächlich stimmen sollte und dort die entsprechende veraltete Softwarebibliothek rumliegt war der „Angriff“ erfolgreich.

Seit Jahren ist mein selbstgeschriebenes CMS den üblichen Wordpress / Joomla / Typo3 Angriffen ausgesetzt. Anfangs habe ich genauso entsetzt reagiert. Heute ringt mir das bestenfalls ein müdes Gähnen ab .

[Jolinar]

Ihr denkt euch da viel zu viel.

Korrekt, das ist ganz normales Grundrauschen

Es lebe die Paranoia

[Ralph]

Korrekt, das ist ganz normales Grundrauschen
Es lebe die Paranoia

Haha, ja sorry ... das "Grundrauschen" hab ich mal wieder nicht beachtet
Na gut, aber so ein umfangreicher Attacken Report für eine IP range kommt auch eher selten vor!
https://www.abuseipdb.com/check-block/45.156.129.0/24

[Jolinar]

Na gut, aber so ein umfangreicher Attacken Report für eine IP range kommt auch eher selten vor!

Ich will es mal so sagen...Die Technik entwickelt sich weiter, die Botnetze werden größer, die Angriffsvektoren werden vielseitiger...Aber auch die Schutzmaßnahmen dagegen verbessern sich im gleichen Maßstab.
Wir haben also einfach nur mehr Grundrauschen als vor 5 oder 10 Jahren. Davon sollten wir uns aber nicht aus der Ruhe bringen lassen...

[Blubby]

Was man halt machen kann ist das Fail2ban aufbohren.

bei sachen wie direktaufrufe auf

Code: Select all

/cgi-bin/config.exp

oder solche die erkennbar darauf abzielen schon vorhandene Backdoors zu finden kann man ja leicht Regeln erstellen und das dadurch unterbinden.


Auf manchen Servern wo das Überhand genommen hat habe ich das rigoros ab dem ersten Versuch abgewürgt.


Wenn man die Websysteme im Griff hat kann man auch einfach die 404 Versuche zählen und ab ner gewissen Schwelle ebenfalls bannen. Geht natürlich nicht wenn man da Kunden hostet die auch mal ihr System einfach umstellen und massenhaft 404 dadurch erzeugen.

[Ralph]

Was man halt machen kann ist das Fail2ban aufbohren.

Code: Select all

/cgi-bin/config.exp

Nur wenn man denn dabei nicht vergisst die "/var/log/apache2/keyhelp/access.log" mit in das jail einzubinden ... sonst hat der Filter & Jail keine Auswirkung auf die Panel requests