Seid einiger Zeit unlautere post-requests im Log

[einsiedler]

Hallo liebe Forumer,

wie ihr meiner Überschrift entnehmen könnt, habe ich seid einiger Zeit post-requests in meinem Log und zwar nicht die, die für meine Formulare erforderlich sind sondern seht selbst, die werden einfach übertragen:

2020-08-05 18:45:05	Error	52.142.53.130	404	GET /.env HTTP/1.0		Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36	1.22 K	Apache-Zugriff
2020-08-05 18:45:06	Error	52.142.53.130	404	POST / HTTP/1.0		Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36	921	Apache-Zugriff
2020-08-05 18:45:05	Error	52.142.53.130	404	GET /.env HTTP/1.0		Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36	1.22 K	Apache-Zugriff
2020-08-05 18:45:06	Access	52.142.53.130	200	POST / HTTP/1.0		Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36	22.2 K	Apache-Zugriff

Die IP wird nun geblockt, aber ich habe hier : https://perishablepress.com/protect-post-requests/ von schädlichen post requests gelesen.

Sodann habe ich gleich mal folgendes meinem htaccess hinzugefügt:

# whitelist POST requests
<IfModule mod_rewrite.c>
	RewriteCond %{REQUEST_METHOD} POST
	RewriteCond %{REQUEST_URI} !/hiergehtszumeinloggen.php [NC]
	RewriteCond %{REQUEST_URI} !/hiergehtszumregistrieren.php [NC]
	RewriteCond %{REQUEST_URI} !/ichhabemeinpasswortvergessen.php [NC]
	RewriteCond %{REQUEST_URI} !/meinaccountverifizieren.php [NC]
	RewriteCond %{REQUEST_URI} !/resettemeinpasswort.php [NC]
	RewriteCond %{REMOTE_ADDR} !127.0.0.1 
	RewriteRule .* - [F,L]
</IfModule>

(die php-Namen habe ich mal geändert!)

Also muss ich jede php die auch eine Übertragung veranlasst (also ein post) dort eintragen.

Jedenfalls funktioniert es wohl, denn alle Funktionen: "Das einloggen, das registrieren, das passwort verifizieren und der reset" uvm. funktionieren reibungslos.

Ich habe auch gelesen das das kürzer geht:

# allow POST based on referrer
<IfModule mod_rewrite.c>
	RewriteCond %{REQUEST_METHOD} POST
	RewriteCond %{REQUEST_URI} /hiergehtszumeinloggen\.php
  RewriteCond %{REQUEST_URI} /hiergehtszumregistrieren\.php
  RewriteCond %{REQUEST_URI} /ichhabemeinpasswortvergessen\.php
  RewriteCond %{REQUEST_URI} /resettemeinpasswort\.php
	RewriteCond %{HTTP_REFERER} !(.*)meinetollehomepage.de(.*) [OR]
	# RewriteCond %{HTTP_USER_AGENT} ^$
	RewriteRule .* - [F,L]
</IfModule>

Was ist nun richtig von beiden.

Das zweite Beispiel will bei mir irgendwie nicht funktionieren, ich bekomme da immer eine 403 Meldung.

Oder ist es da wichtig bei der Addy "https" davorzuschreiben?

Was ist nun von beiden richtig?

Kennt ihr das mit den Malicious POST Requests?

Vielen Dank!

Der einsiedelnde

[Auge]

Hallo

Wie (wenn ich mich recht erinnere auch dir) schon einige Male hier beschrieben wurde, sind das Requests auf als unsicher bekannte Ressourcen typischer webbasierter Systeme. Die zielen darauf ab, Systeme wie CMS, Foren oder ähnliches (also alles, was auf einem Webspace installiert sein kann) anzugreifen, bei denen Sicherheitslücken bekannt sind und bei denen die Angreifer davon ausgehen können, dass viele Betreiber solcher Systeme die passenden Updates nicht eingespielt haben (also praktisch bei allen).

Solange du solche Systeme nicht betreibst beziehungsweise nicht ungepflegt belässt, können dir solche Anfragen peripher vorbeigehen. Das sollten sie auch, denn ansonsten bist du mit nichts anderem als (viel zu spezifischen) Abwehrmaßnahmen beschäftigt. Sowas zu ignorieren gehört zur Pflege deiner eigenen geistigen Gesundheit.

Mehr als ein Status 404 passiert ja nicht, das lässt sich eigentlich, wenn man nicht andauernd hinschaut, ganz gut ignorieren.

Tschö, Auge

[edit]: Zwei (in Worten: zwei) Typos in einem Wort und einen weiteren korrigiert.

[Tabellenkalk]

Hallo,

Mehr als ein Status 404 passiert ja nicht,

Naja, wenn man genau schaut, passiert im 4. Versuch dann doch eine 200.

Gruß
Kalk

[Auge]

Hallo

Mehr als ein Status 404 passiert ja nicht,

Naja, wenn man genau schaut, passiert im 4. Versuch dann doch eine 200.

Was verbirgt sich denn hinter /? Normalerweise (und je nach Serverkonfiguration) doch die index.*. Wenn diese Ressource POST-Anfragen nicht verarbeitet, dann wäre mir das Wurscht. Wenn die doch POST annimmt, aber mit den per POST angelieferten Feldern nichts anfängt, wäre mir das ebenfalls wurscht. Selbst wenn die korrekten Felder angeliefert würden, griffe nur der normale Verarbeitungsmechanismus.

Letzterer muss natürlich so zuverlässig und sicher, wie möglich sein. Das ist aber das, was ich (nach bestem Wissen und Gewissen) eh' sicherstellen muss. So what?

Tschö, Auge

[localhorst]

Hallo,

wenn man das aus Sicherheitsgründen unbedingt genau wissen muss, kann man mal für eine Zeit lang die Requestdaten mitloggen. Dazu kann man eventuell auch das Logformat ändern. Dazu muss man selbstverständlich Zugriff auf die Serverkonfiguration haben. Sonst muss man das in den Handlern einbauen.

Und damit man die ermittelten Daten nachher ggf. juristisch verwerten darf, sollte die Datenschutzerklärung entsprechend angepasst sein!

Und alternativ kann man in allen Verzeichnissen, in denen kein POST vorgesehen ist, diesen verbieten (z.B. in .htaccess-Dateien). Siehe auch Apache Dokumentation zu Limit

LG
localhorst

[Der Martin]

Hi,

Und alternativ kann man in allen Verzeichnissen, in denen kein POST vorgesehen ist, diesen verbieten (z.B. in .htaccess-Dateien). Siehe auch Apache Dokumentation zu Limit

kann man machen ... muss man aber nicht ...

Mal ganz naiv gefragt: Was ist schlimm daran, wenn eine Ressource, bei der eigentlich nur GET vorgesehen ist, plötzlich auch mal mit POST angefordert wird?
Genau: Nichts. Es tut nicht weh, es richtet keinen Schaden an. Die Ressource wird ganz normal ausgeliefert wie bei GET, wenn man das nicht bewusst unterbindet.

Live long and pros healthy,
 Martin

[localhorst]

Hi,

Mal ganz naiv gefragt: [...]

Naivität im Umgang mit dem Internet kann tödlich sein.

Ein neues CMS würde ich auf jeden Fall auf diese Weise beobachten, ob es Hintertüren enthält, insbesondere, wenn POSTs auf unerwartete Ressourcen mit Status 200 beantwortet werden.

LG
localhorst

[Auge]

Hallo

Und damit man die ermittelten Daten nachher ggf. juristisch verwerten darf, sollte die Datenschutzerklärung entsprechend angepasst sein!

Da dort heutzutage üblicherweise sowieso drinsteht, dass aus technischen Gründen Logs geschrieben werden, muss, wenn es denn so ist, nicht einmal etwas geändert werden. Ausnahmen bestätigen, wie üblich, die Regel.

Tschö, Auge