ip-range sperre mit htaccess

[MERO]

hallo leute,

ich betreue privat eine page mit forum und gb.
allerdings wir in letzter zeit das gb zu gespamt und wir bzw. ich die beiträge moderieren ist es nervig.

ich habe mir jetzt eine htaccess gebastelt die mir eigentlich die typen vom hals halten soll.

es funzt eigentlich ganz gut nur kommt einer immer wieder durch obwohl die range eigentlich geblockt werden ist. ich habe die addi sogar einzeln eingetragen aber er schafft es immer wieder.

hier mal der quelltext der htaccess:
----------code-----on----------
RewriteEngine on

RewriteCond %{REMOTE_ADDR} ^24.62.(0[8-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^24.62.(1[0-5]).[OR]
RewriteCond %{REMOTE_ADDR} ^65.(18[4-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^65.(19[0-1]).[OR]
RewriteCond %{REMOTE_ADDR} ^67.173.(11[8-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^68.(0[0-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^68.(1[0-5]).[OR]
RewriteCond %{REMOTE_ADDR} ^68.(8[0-7]).[OR]
RewriteCond %{REMOTE_ADDR} ^68.1.(0[0-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^68.1.(1[0-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^68.1.(2[0-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^68.1.(3[0-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^68.1.(4[0-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^68.1.(5[0-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^68.1.(6[0-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^68.1.(7[0-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^68.1.(8[0-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^68.1.(9[0-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^68.1.(10[0-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^68.1.(11[0-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^68.1.(12[0-7]).[OR]
RewriteCond %{REMOTE_ADDR} ^68.83.(19[2-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^68.83.(20[0-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^68.83.(21[0-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^68.83.(22[0-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^68.83.(23[0-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^69.(20[8-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^69.(21[0-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^69.(22[0-3]).[OR]
RewriteCond %{REMOTE_ADDR} ^70.(12[8-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^70.(13[0-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^70.(14[0-3]).[OR]
RewriteCond %{REMOTE_ADDR} ^70.(16[0-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^70.(17[0-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^70.(18[0-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^70.(19[0-1]).[OR]
RewriteCond %{REMOTE_ADDR} ^70.40.(22[6-7]).[OR]
RewriteCond %{REMOTE_ADDR} ^81.95.(14[4-7]).[OR]
RewriteCond %{REMOTE_ADDR} ^81.95.146.162.[OR]
RewriteCond %{REMOTE_ADDR} ^124.106.(0[8-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^124.(10[4-7]).[OR]
RewriteCond %{REMOTE_ADDR} ^124.106.(1[0-3]).[OR]
RewriteCond %{REMOTE_ADDR} ^195.225.(17[6-9]).[OR]
RewriteCond %{REMOTE_ADDR} ^218.90.(3[1-8]).[OR]


RewriteRule ^.* -[F]
----------code-----end----------

die rot makierte ist das problem.
vieleicht habe ich ja einen denkfehler oder so! hat von euch jemand noch eine idee?

übrigens werde ich für leute die es interessiert die list in abständen aktuell halten. soll heißen wer mag darf sie frei verwenden.


mfg
MERO

[cycomate]

Die Regexps stimmen nicht so 100%ig.
Bei der zweiten roten Zeile ist z.B. ein Punkt am Ende zuviel. Ein Punkt heißt "beliebiges Zeichen", d.h.:
^81.95.146.162.
entspricht dem Ausdruck "81<beliebiges Zeichen>95<beliebiges zeichen>146<beliebiges Zeichen>162" am Anfang, gefolgt von irgendeinem Zeichen.
Korrekt wäre "^81\.95\.146\.162$"
Achso, Ausdrücke müssen nicht geklammert werden. Leerzeichen vor [OR] nicht vergessen.

[MERO]

danke für die schnelle antwort.

muss ich das bei allen einträgen andern?

[cycomate]

Ich würde die komplette Liste überarbeiten, auch in der Hinsicht, ob die Einträge überhaupt existieren können. Beispiel

RewriteCond %{REMOTE_ADDR} ^24.62.(0[8-9]).[OR]Es werden keine führenden Nullen angegeben, mach daraus also

RewriteCond %{REMOTE_ADDR} ^24\.62\.[89]\. [OR]Den Block mit

RewriteCond %{REMOTE_ADDR} ^68.1.(0[0-9]).[OR]
:
RewriteCond %{REMOTE_ADDR} ^68.1.(12[0-7]).[OR]kannst Du zusammenfassen zu

RewriteCond %{REMOTE_ADDR} ^68\.1\.[0-9]?[0-9]\. [OR]
RewriteCond %{REMOTE_ADDR} ^68\.1\.1[01][0-9]\. [OR]
RewriteCond %{REMOTE_ADDR} ^68\.1\.12[0-7]\. [OR]
Aber mal ganz nebenbei: wenn Du access control statt rewrites nimmst, kannst Du die Blöcke eine ganze Ecke einfacher blocken:

deny from 61.1.0.0/17

[MERO]

ich habe es jetzt dahin gehend geändert, der typ kommt immernoch durch.
:mad:

[cycomate]

Funktioniert der rewrite-filter denn generell bei Dir? Möglicherweise ist das Rewrite-Modul nicht geladen oder es ist AllowOverride None gesetzt.
Notfalls mal in den Logfiles gucken und/oder auf mod_access umsteigen.

[MERO]

so ich habs jetzt ersteinmal, allerdings mauelt er das leerzeichen vor dem OR an.

[cycomate]

Du hast das Leerzeichen aber schon vor dem [OR] und nicht vor dem OR, oder?

[MERO]

die datei funzt jetzt so, aber der typ kommt immernoch durch.:mad:
hier mal eine auszug aus den server-logs:

www.****.de 81.95.146.162 - - [15/Sep/20xx:xx:xx:53 +0200] "POST /book/new_post.php HTTP/1.0" 200 3604 "http://www.****.de/book/new_post.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; MRA 4.3 (build 01218))"


ich verzweifle langsam.

[actro]

erde mal 81.95.144.0/22 gegen /dev/nul..

[cycomate]

Ich wiederhole gern noch einmal: Leerzeichen vor dem [OR]? Läßt man es weg, funktioniert es nicht. Und die letzte RewriteCond braucht kein [OR], aber mit funktioniert es trotzdem.

Edit: achso, ich sehe gerade, daß Du auch ein Leerzeichen in der RewriteRule zwischen dem Minus und dem [F] vergessen hast. Das führt zwar irgendwie auch zu einem gewünschten Ergebnis (daß er die Seite nicht anzeigt), aber nur, weil er die Datei "-[F]" nicht finden kann.

[MERO]

ähm, wie geht das denn? das erden gegen dev/null?
leider bin ich nicht so bewandert in diesen dingen.

[actro]

leg das gesamte segment in die /etc/hosts.deny..

[Monk]

Es wurde zwar das Meiste im wesentlichen schonmal gesagt, aber (mit Verlaub) kam es an?

Wenn es denn unbedingt ein Block per .htaccess sein muss (Server-Config oder Mittel der Anwendung wären vorzuziehen), warum dann mit Rewrites eine Kanone auspacken, die da eigentlich nicht hingehört? Nebenbei ist sowas ohne saubere Kenntnisse eine ewige Fehlerquelle.

Hier mal das anscheinend Gewollte als (in .htaccess oder Config einbaubare) denies, der Reihe nach aus fix dem Original abgearbeitet und mit Kommentaren:


## Comcast
## für den Bereich vielleicht besser gleich 24.60.0.0/14?
deny from 24.62.8.0/22
## Roadrunner
deny from 65.184.0.0/13
## Comcast
## für den Bereich vielleicht besser gleich 67.173.0.0/17 oder sogar 67.160.0.0/11?
deny from 67.173.118.0/23
### 68er sind unklar, die 68.1er anscheinend darüber schon enthalten.
### Der erste soll wohl 68.0.0.0-68.0.15.255 sein:
## Cox Atlanta Teilblöcke
deny from 68.0.0.0/20
deny from 68.1.0.0/17
# deny from 68.0.0.0/12 (alternativ zu den letzten beiden und möglicher weiterer gleich ganz Cox Atlanta)
## Comcast Jumpstart-2
deny from 68.80.0.0/13
# deny from 68.83.192.0/19 (schon in 68.80.0.0/13 enthalten)
# deny from 68.83.224.0/20 (schon in 68.80.0.0/13 enthalten)
## SBC
deny from 69.208.0.0/12
deny from 70.128.0.0/12
## Cox Atlanta-10
deny from 70.160.0.0/11
## Adelphia Cable
## vielleicht besser gleich ganz 70.32.0.0/13 und 70.40.0.0/16?
deny from 70.40.226.0/23
## RBNET Russia
deny from 81.95.144.0/22
## IPG Philipines
## warum aber nicht gleich mindestens die direkte APNIC-Hülle 121-126?
# deny from 124.106.8.0/23 (schon im nächsten enthalten)
deny from 124.104.0.0/14
# deny from 124.106.10.0/23 (schon in 124.104.0.0/14 enthalten)
# deny from 124.106.12.0/23 (schon in 124.104.0.0/14 enthalten)
## Netcathosting Ukraine (hardly any good guys there)
deny from 195.225.176.0/22
## Teile von Chinanet Jiangsu
## warum aber nicht gleich das umliegende Netz oder die direkte APNIC-Hülle 218-220?
deny from 218.90.31.0/24
deny from 218.90.32.0/22
deny from 218.90.36.0/23
deny from 218.90.38.0/24


Das sieht (nach Abzug der unnötigen Kommentare) schon viel aufgeräumter und wartungsfreundlicher aus. Tut auch dem Server weniger weh.

Oben fällt nun auch leichter auf, was Du sperrst: Anscheinend die mehr oder weniger direkt umliegenden Netze, aus denen schonmal ein konkreter Spam-Versuch aufgelaufen ist. Dabei hast Du viel Aufwand für (noch) ganz wenige Bereiche genutzt, in denen eher Trojaner verbreitet sind. Bis auf Netcathosting sehe ich da aber die echten "Hämmer" noch nicht.
Welche Relevanz haben etwa die paar Inselspammer und Jiangsu-Chinesen? Hast/adressierst Du überhaupt User aus Asien? Braucht Australien/Neuseeland eine Sonderbehandlung? Wenn nicht, dann doch gleich ganz weg mit den ganzen APNIC-Netzen.

Wenn Du aber noch weiter per Rewrites anstückelst, wirst Du mit Sicherheit nicht mehr glücklich werden. An Deiner Stelle würde ich ganz klar
- zuerst von den Rewrites die Finger lassen und auf denies umstellen,
- bei konkreten Vorfällen gleich nach dem maximal sinnvollen (!) Bereich schauen, der noch in den Ausschlüssen fehlt,
- alle solche Blöcke sauber kommentieren

[Wusl]

In der .htaccess, je nach Server-Konfiguration, entweder

order allow,deny
allow from all
deny from 81.95.144.0/22

oder

order allow,deny
allow from all
deny from 81.95.144.
deny from 81.95.145.
deny from 81.95.146.
deny from 81.95.147.

[Q__]

oder

order allow,deny
allow from all
deny from 81.95.144.
deny from 81.95.145.
deny from 81.95.146.
deny from 81.95.147.
Allerdings ohne den abschließenden Punkt, wenn's funktioneiren soll ;) :cool:


deny from 81.95.144
usw.

Ref. http://httpd.apache.org/docs/2.0/mod/mod_access.html#allow

Gruß,
Q

[Wusl]

Allerdings ohne den abschließenden Punkt, wenn's funktioneiren soll ;) :cool:


deny from 81.95.144
usw.

Nada.
Ich habe eine Maschine, bei der es genau so funktioniert.
Allerdings nur eine, die anderen benehmen sich normal.
Vielleicht zu-viel-alkohol oder so...:D

[Q__]

Ref. http://httpd.apache.org/docs/2.0/mod/mod_access.html#allow
Naja, wäre mir nicht derselbe Fehler passiert und mein russischer Freund bekam immer noch den Status "200 OK", wäre es mir auch überhaupt nicht aufgefallen...

Gruß,
Q