• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[jelöööst] apache2 / mod_rewrite / ubuntu 18.04.x

suwelo

Member
Moin zusammen,
ich hätte da mal eine Frage zu dem Modul "mod_rewrite" von Apache2 von Ubuntu 18.04.1.

Wenn ich mich in dem Verzeichnis "/etc/apache2/mods-available" umsehe, finde ich dort "*.load und *.conf" Dateien zu fast jedem Modul.

Das "mod_rewrite" Modul ist angeschalten, aber für dieses Modul gibt es keine "rewrite.conf" Datei sondern nur die "rewrite.load".

In der "vhosts.conf" habe ich für Port 80 in den Abschnitten für die jeweiligen vhosts ein redirect auf HTTPS eingebaut:

Code:
RewriteEngine On
RewriteCond % {HTTPS} Off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}[R301,L]

Das führt dazu, dass reguläre Port 80 Anfragen des aufgerufenen vhost auf Port 443 des zugehörigen vhost umgeleitet werden sollen.


In den Logs tauchen jedoch Dinge auf, die an Port 80 abgearbeitet werden und keine Fehler verursachen und somit keinen Eintrag in der "error.log" erzeugen. Ein redirect unterbleibt zudem.
Hier nur eines von vielen Beispielen:

Code:
server_name:80 ip.add.re.sse datum "POST /1111.php HTTP/1.1" 301 537 "-" "Mozilla 5.0 usw. usw.

Ich möchte über das "mod_rewrite" Modul solche Anfragen in nachfolgender Form "Blacklisten".
Beispiel:

Code:
<IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteCond %{POST} ^.*(\\r|\\n|%0A|%0D).* [NC]
 RewriteRule ^(.*)$ - [F,L]
 </IfModule>

UND / ODER

<IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteCond %{HTTP_REFERER} ^http://(www\.)?.*(-|.)?1111(-|.).*$  [NC,OR]
 RewriteRule ^(.*)$ - [F,L]
</IfModule>


Da ich mehrere VHOSTS in einer Konfigurationsdatei vereinigt habe, wäre eben genanntes Beispiel eine Horroraufgabe, da ich jeden Block, wie eben gezeigt, in jeden "vhost Abschnitt" eintragen müsste.


Mir stellen sich jetzt mehrere Fragen:

1) Ist das möglich in "/etc/apache2/mods-available" eine Datei mit dem Namen "rewrite.conf" zu erzeugen, so dass ich die "rewrite rule" zentral verwalten kann?

2) Ganz oben im Text habe ich in der "vhosts.conf" in jedem Abschnitt bereits ein redirect definiert, das Port 80 Anfragen auf Port 443 umleiten soll.
Überschreiben sich womöglich die Regeln, wenn ich wie in "1" beschrieben, die Regeln mit einer zentralen "rewrite.conf" abarbeite?

3) Die Idee habe ich im Internet gefunden und ich kann schlecht sagen, ob der Ubuntu Apache2 mit dem Anfang aus den Rewrite Regeln:

Code:
<IfModule mod_rewrite.c>
mit dem "*.c" etwas anfangen kann und ob das dringend notwendig ist.

4) Geht das überhaupt, so wie ich mir das vorstelle?


Ich hoffe, dass ich die Problematik einigermassen verständlich und nachvollziehbar dargestellt habe.

Ich danke im Voraus für eure Hilfe

:D
 

marce

Guru
Code:
server_name:80 ip.add.re.sse datum "POST /1111.php HTTP/1.1" 301 537 "-" "Mozilla 5.0 usw. usw.
wird doch umgeleitet. Return-Code 301.

Zudem - warum sollte sowas in der error.log auftauchen? Ist doch kein Fehler.

"Zentrale" rewrite-Rules kann man machen, man muss ich jedoch im klaren sein, was man damit "anstellt" und zudem gibt es natürlich immer noch die Abarbeitungsreihenfolge Config / .htaccess / Dirctory / Location / ... - siehe Doku.

Wenn Du zentrale, allgemeingültge Regeln hat - wie z.B. http -> https - spricht natürlich nichts dagegen, die z.B. in einem einzigen http-VHost entsprechend allgemein def. abzulegen. Arg viel mehr als so eine zentrale Umleitung wird man da aber realistisch nicht machen können.
 
suwelo schrieb:
..
Da ich mehrere VHOSTS in einer Konfigurationsdatei vereinigt habe, wäre eben genanntes Beispiel eine Horroraufgabe, da ich jeden Block, wie eben gezeigt, in jeden "vhost Abschnitt" eintragen müsste.
....
Ich glaube nicht, dass das so richtig ist.
Deine rewrite rules sind in vhosts.conf (oder wie auch immer) gut aufgehoben, wenn du wildcards verwendest und die Reihenfolge beachtest.
Beispiel (ich habe nicht alle Apache Anweisungen im Kopf):

Alle 443 mit extra log (log definiert anderswo mit: Logformat "blah_blah" vhost_ssl)
Code:
<IfModule ssl_module>
<VirtualHost *:443>
	SSLEngine on
	SSLCertificateFile	"/blah_blah/server.crt"
	SSLCertificateKeyFile	"/blah_blah/server.key"
	CustomLog /var/log/apache/access.log vhost_ssl
</VirtualHost>
</IfModule>

Den localhost (für den brauchen wir nicht das große ssl Programm)
Code:
<VirtualHost localhost:80>
		ServerName localhost
		DocumentRoot "/mnt/www/irgendwo"
</VirtualHost>

Alle anderen :80 werden umgeleitet
Code:
<VirtualHost *:80>
	RewriteEngine On
	RewriteCond %{HTTPS} off
	RewriteRule (.*) https://%{SERVER_NAME}/ [R,L]
</VirtualHost>

Und der individuelle, virtuelle Rest
Code:
<IfModule ssl_module>
<VirtualHost  pluto:443>
	ServerName pluto
	DocumentRoot "/mnt/www/pluto"
</VirtualHost>
</IfModule>

usw ..
Der arbeitet das von oben nach unten ab und sollte in dieser Reihenfolge funktionieren (Nur ein Schaubild zum Verständnis und mit Sicherheit nicht komplett)

Gruß
Gräfin Klara
 
OP
suwelo

suwelo

Member
Moin zusammen,
der Eintrag wie im Eingangspost beschrieben ist richtigerweise in der "access.log" und ist kein Fehler.
Die Nummer "301" bedeutet auf kurz, "Permanently moved".

Die Einträge werden von zumeist Chinesischen IP-Adressen verursacht, die den Server testen.
Da laufen Scripte ab, die hunderte Einträge in der von mir beschriebenen Weise verursachen:

Code:
target_server_name:80 quell.ip.addre.sse - - [datum:uhrzeit +0200] "POST /boots.php HTTP/1.1" 301 539 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
target_server_name:80 quell.ip.addre.sse - - [datum:uhrzeit +0200] "POST /s.php HTTP/1.1" 301 531 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
target_server_name:80 quell.ip.addre.sse - - [datum:uhrzeit +0200] "GET / HTTP/1.1" 301 521 "-" "-"
target_server_name:80 quell.ip.addre.sse - - [datum:uhrzeit +0200] "GET /mysql/admin/index.php HTTP/1.1" 301 563 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:28.0) Gecko/20100101 Firefox/28.0"


@marce
Richtigerweise schmeisst sich "mod_rewrite" dazwischen und erkennt, dass der Anfrage Header, eine IP-Adresse auf Port 80 ist, leitet die Anfrage an die URL "target_server_name:80" um, was mit der Nummer "301" quittiert wird, da die Dateien, die über die Anfrage getestet werden, inexistent und damit unauffindbar sind.
Auf "target_server_name:443" kommen die erst gar nicht an, was gut so ist und auch gewollt.

Ich habe heute ein Monster von einer "rewrite.conf" zusammen geschrieben, in der alle diese Anfragen eingeflossen sind.

Wenn solche Anfragen so oder so schon als "301" abgearbeitet wurden, frage ich mich, ob doppelt gemoppelt besser ist oder zusätzliche Lücken auftreissen kann.
Das KISS (Keep It Small and Simple) Prinzip habe ich damit erfolgreich umgangen.

Hier nur mal ein kleiner Ausschnitt. Ich habe das ganze mit "GET, POST und eben dem HTTP_REFERER" zusammen geschrieben:

Code:
<IfModule mod_rewrite.c>
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?logon(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?log(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?lol(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?manager(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?muhstik2(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?muhstik-dpr(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?muhstik(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?muhstiks(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?myadmin2/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?myadmin/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?MyAdmin/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?mysite/wp-login(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?mysql_admin/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?mysql-admin/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?mysql/admin/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?mysqladmin/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?mysql/dbadmin/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?mysql/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?mysql/mysqlmanager/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?mysql/sqlmanager/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?new1/wp-login(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?new_license(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?new/wp-login(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?payload(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?php2MyAdmin/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpadmin/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpAdmin/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpiMyAdmin/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpmadmin/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpma/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpMyAbmin/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpmyadm1n/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpMyAdm1n/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpMyadmi/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpmyadmin0/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpMyAdmin_111/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpMyAdmin123/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpmyadmin1/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpMyAdmin1/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpmyadmin2222/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpmyadmin2/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpMyAdmin._2/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpMyAdmin-4.4.0/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpMyAdmina/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpMyadmin_bak/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpmyadmin/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpMyAdmin__/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpMyAdmin/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpMyAdmin._/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpMyAdmin+++---/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpmyadmin-old/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpMyAdmin.old/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpMyAdminold/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpmyadmin/phpmyadmin/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpMyAdmin/phpMyAdmin/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpmyadmin/scripts/db___.init(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpMyAdmin/scripts/db___.init(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpmyadmin/scripts/setup(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpMyAdmin/scripts/setup(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpMyAdmins/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpMyAdmion/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpMydmin/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpmy/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phpNyAdmin/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?phppma/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?plugins/weathermap/editor(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?PMA2/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?pma/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?PMA/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?pmamy2/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?pmamy/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?pma-old/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?pmd/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?pmd_online(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?program/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?pwd/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?_query(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?robots(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?rxr(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?sane(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?scripts/setup(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?shaAdmin/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?shell(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?shopdb/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?s/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?spider(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?t6nv(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?test(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?text(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?tools/phpMyAdmin/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?typo3/phpmyadmin/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?undx(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?uploader(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?up(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?view/img/favicon(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?v/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?w00tw00t.at.ISC.SANS.DFind:)(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?webdav(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?web/phpMyAdmin/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?wordpress1/wp-login(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?wordpress2/wp-login(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?wordpress3/wp-login(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?wordpress5/wp-login(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?wordpress6/wp-login(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?wordpress9/wp-login(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?wp1/wp-login(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?wp-config(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?wp-content/plugins/portable-phpmyadmin/wp-pma-mod/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?wpc(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?wp-login(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?wpo(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?wp/wp-login(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?www/phpMyAdmin/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?xampp/phpmyadmin/index(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?x(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?yu(-|.).*$ [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://(*\.)?.*(-|.)?z(-|.).*$ [NC,OR]
</IfModule>


@Gräfin Klara
Mir ist unklar ob es Sinn macht das in jeden VHOST Abschnitt einzutragen.
Es sind 2 VHOSTS, die über eine öffentliche URL auffindbar sein sollen, einer davon ist der "Default" Webserver sowie die Dynamische IP-Adresse, die auf die öffentliche "Default" Webserver URL umgeleitet wird.


Über Sinn und Unsinn dieses vorhabens würde ich mich über eine Antwort von den Profis, die bereits geantwortet haben, freuen.

Auch alle anderen Profis, die Apache Knowledge haben sind herzlich eingeladen eine Antwort zu verfassen.

Ich bedanke mich im Voraus, und im Falle mein Thread überhaupt verständlich ist, für eure Hilfe ..


:D
 

marce

Guru
Was um Himmels willen erwartest Du Dir von einer solchen Rewrite-Regel denn?

Zum einen ist das Ding nicht pflegbar, zum anderen bringt es Dir keinerlei Gewinn an Sicherheit oder sonstigem.

Wenn Du irgendwas sperren willst nach entsprechenden Zugriffen würde ich (eigentlich nicht, aber egal) fail2ban oder mod_security empfehlen.
 
.
Jetzt verstehe ich erst was du willst. Du möchtest einen Referrer Spam Filter erstellen.
So solltest du das auf keinen Fall anstellen. Verwende dafür eine rewrite database.

Siehe dazu folgende Schlagwörter:

RewriteMap
httxt2dbm

Die rules werden erstellt in einem Textfile und mit httxt2dbm zu einer binären Datenbank gewandelt,
auf die dann mit RewriteMap referenziert wird. Das bringt Geschwindigkeit und ist einfach zu implementieren.
Schau es dir an.
 
OP
suwelo

suwelo

Member
Moin zusammen,

@marce
Ich will Clients, die täglich hunderte solcher sinnlosen Anfragen verursachen blockieren.
Am besten für immer, weil es immer von den gleichen IP-Adressen kommt.
Ich habe mich vor ein paar Jahren mit "Fail2Ban" noch unter "OpenSuSE" auseinandergesetzt und genutzt, hatte aber das Gefühl und nach Durchsicht der logs, dass das nicht funktioniert.
Da "Fail2Ban" in den "iptables" Änderungen vornimmt, habe ich mich auch mit diesen auseinander gesetzt.
Trotz lesens vieler Manuals und Workarounds zu "Fail2Ban" und "iptables" bin ich nie dahinter gekommen warum das nicht so funktioniert, wie ich mir das vorstelle.
Nach meinem Denken und meiner Konfiguration hätte "Fail2Ban" spätestens nach dem 10. oder 15. solcher Einträge die Quell IP-Adresse sperren müssen.
Meine Spekulation war, dass "Fail2Ban" eine öffentliche IP-Adresse erwartet. Ich sitze allerdings auf meiner "Spielwiese" an einer Dynamischen "IP-Adresse" mit "DynDomains".

ModSecurity habe ich auf dem System installiert.
Da ich oftmals in den logs sehe, dass solche Quell IP-Adressen viel Müll verursachen, kann ich schlecht sagen ob das so läuft wie ich mir das vorstelle.
ModSecurity ist, so wie ich das bisher erfahren habe, etwas schwach aufgestellt was Workarounds angeht.
Ich kann natürlich auch Missverständnisse mit ModSecurity meinerseits kaum ausschliessen.


@Gräfin Klara
Ich lese mich da ein, bin aber nach der eben verfassten Antwort an "marce" überzeugt davon, dass "Fail2Ban" und "iptables" die Lösung sein müsste.


Danke für eure Geduld und Hilfe

:D
 

gehrke

Administrator
Teammitglied
suwelo schrieb:
Ich will Clients, die täglich hunderte solcher sinnlosen Anfragen verursachen blockieren.
Eine Antwort ist mod_security in Verbindung mit dem CRS (Core Rule Set von OWasp).

mod_security ist die Implementierung für eine Web Application Firewall (WAF) im Apache, und CRS bietet einen offenen, kontinuierlich gepflegten Regelsatz.

Die von Dir genannten Beispiele werden verlässlich erkannt und blockiert.

Ist aber nicht ganz trivial...
 

marce

Guru
... und ganz ehrlich: Es bringt keinen Mehrgewinn an irgendwas.

Dein System ist dadurch weder sicherer (eher im Gegenteil, man fühlt sich sicherer ohne es zu sein, es ziemlich gefährliche Kombination) noch bringt es anderweitige Vorteile - wenn man nicht genau weiß was man tut überwiegen die Nachteile eindeutig. Vor allem, wenn man sich dadurch noch so einen Verwaltungsoverhead reinholt wie Du es vor hattest...
 
OP
suwelo

suwelo

Member
Moin zusammen,
ich bedanke mich bei euch dreien für den neuen Input und will mich in die vorgeschlagenen Tools weiter vertiefen.
Auch die, die ich schon nutze wie z.b. "modsecurity-crs".

Ich schliesse das Thema.

Danke
 

gehrke

Administrator
Teammitglied
marce schrieb:
Dein System ist dadurch weder sicherer (eher im Gegenteil, man fühlt sich sicherer ohne es zu sein, es ziemlich gefährliche Kombination) noch bringt es anderweitige Vorteile
Ich möchte hier widersprechen. Diese Meinung höre ich immer wieder, aber sie stimmt IMHO nicht per se.

Offenbar gehen deren Anhänger davon aus, dass Unbedarfte glauben, mit einer WAF auch die unsicherste Application magisch sicher machen zu können. Das ist natürlich mitnichten so, aber der Umkehrschluss ist ebenfalls unzulässig.

Für eine ausreichend sichere Application ist ein guter Regelsatz trotzdem ein Gewinn, weil dadurch eine zweite Sicherheitslinie gezogen wird - und 100%-ige Sicherheit gibt es auch bei Applications nicht.

Desweiteren schafft eine WAF erhebliche Transparenz. Bei einem aktivierten CRS wird nicht nur ein Haufen Zeug geblockt, sondern auch geloggt. Darin sind viel mehr Informationen enthalten, als aus normalen Logs ablesbar wäre. Daran lassen sich Angriffsmuster erkennen, dienen sowohl der Weiterentwicklung zur besseren Verteidigung und dienen der Forensik.

Ich jedenfalls habe nirgendwo mehr über Angriffsverfahren gelernt als bei der Lektüre der Logs von mod_security.

Ja, man erkauft sich das mit einem erheblichen Overhead, was dem KIS-Ansatz widerspricht. Aber diese Investition kann sich in bestimmten Fällen lohnen. Das ist abzuwägen, und ein unbedarftes Vorgehen kann natürlich auch schaden.
Aber so absolut, wie es hier formuliert wurde, möchte ich das nicht stehen lassen.

Und ja, bevor irgendjemand damit kommt: Security-Audits sollte man natürlich immer auch mit abgeschalteter WAF durchführen.
 

marce

Guru
Grundsätzlich hast Du Recht (und ich stimme Dir zu), aber - wie bei fast jedem IDS / ...
* muss man Aufwand und Nutzen abwägen
* sollte man wissen, was man tut, wie man die Logs auszuwerten und zu verstehen hat, ...
* schon im Voraus die Plausibilität von Angriffsvektoren bewerten können
* im Voraus sehr viel über seine gehostete Applikation wissen

Für ein Standard-Wordpress / Typo3 kommt man auch mit den vorgefertigten Regelwerken recht weit - sobald es aber an's Eingemachte geht (sprich selbst entwickelte Applikationen mit komplett eigenen Einstiegsvektoren) helfen einem die "default" / "öffentlichen" / "bekannten" Regelwerke maximal noch als Doku.

Wenn dies nicht gegeben ist gaukelt einem ein fertiges Framework aus meiner Sicht eine Sicherheit vor, die eben nicht "per so" vorhanden ist. Es ist ja auch nicht einfach damit getan, "das Zeugs" zu installieren und fertig - sondern es ist nur ein Schritt / Komponente in einer umfangreichen Kette, in der man alles forlaufend verstehen, bewerten und anpassen, optimieren und ggf. auch wieder verwerfen muss.

Security ist eben kein einfacher Task, sondern ein Prozess.
 
Oben