template per htaccess sperren - hilfe über 800.000 scriptaufrufe

[sascha_k]

hallo,

wir haben momentan das problem, dass unsere seite, bzw. ein template unserer seite extem mit scriptaufrufen beschossen wird - alleine 800.000 gestern - richtig böse.

einzelne ip`s mit extrem vielen aufrufen habe ich aus dem accesslog gefiltert und in der htaccess gesperrt, doch das hilft nichts.

gibt es eine möglichkeit, irgendwie das template zu sperren, da 99,9% áller aufrufe auf das eine template laufen mit den entsprechenden unterseiten.

damit habe ich es versucht, aber ohne erfolg:
RewriteCond %{QUERY_STRING}  /cgi-bin/seite&|$

ich möchte im grunde alles sperren, was mit /cgi-bin/seite& anfängt, da mehrere seiten auch unter z.b. /cgi-bin/seite&wcheck=1&Pos=3672.12 oder  z.b. /cgi-bin/seite&wcheck=1&Pos=2211.05
zu erreichen sind.

hoffe, mir kann jemand helfen.
danke
sascha

[Felix Riesterer]

Lieber sascha_k,

es ist in meinen Augen ein schwerer Designfehler, wenn Template-Dateien (oder nachladbare Scriptdateien o.ä.) in für den Browser erreichbaren Bereichen abgelegt werden. Hierfür sollte man sich entweder ein per htaccess völlig verriegeltes Verzeichnis nehmen, oder gar die Dateien in einem Verzeichnis außerhalb des für die Domain erreichbaren Verzeichnisbaums ablegen.

Ob Dein Ansatz über die htaccess-Direktiven überhaupt sinnvoll ist, bezweifle ich, auch wenn er weniger aufwendig zu sein scheint.

Liebe Grüße,

Felix Riesterer.

[dedlfix]

Tach!

einzelne ip`s mit extrem vielen aufrufen habe ich aus dem accesslog gefiltert und in der htaccess gesperrt, doch das hilft nichts.

Wenn du sagtest, wie du das gemacht hast, könnte man Verbesserungsvorschläge anbringen.

gibt es eine möglichkeit, irgendwie das template zu sperren, da 99,9% áller aufrufe auf das eine template laufen mit den entsprechenden unterseiten.

Templates müssen üblicherweie gar nicht direkt aufgerufen werden. Wenn sie nicht in einem separaten Verzeichnis liegen, auf das man den Zugriff mit Deny from all sperren kann, dann solltest du zumindest über eine Änderung der Projektstruktur diesbezüglich nachdenken. Noch besser ist, wie Felix schon sagte, sie (und alles andere, was nicht direkt aufgerufen werden soll) ganz aus dem DocumentRoot herauszunehmen.

damit habe ich es versucht, aber ohne erfolg:
RewriteCond %{QUERY_STRING}  /cgi-bin/seite&|$

Das ist nur ein Teil, der allein gar nichts bewirkt. Außerdem beginnt der Querystring erst nach dem "?". Was du da hast sieht mir eher nach Pfad aus.

dedlfix.

[Kay]

hallo,

wir haben momentan das problem, dass unsere seite, bzw. ein template unserer seite extem mit scriptaufrufen beschossen wird - alleine 800.000 gestern - richtig böse.

einzelne ip`s mit extrem vielen aufrufen habe ich aus dem accesslog gefiltert und in der htaccess gesperrt, doch das hilft nichts.

gibt es eine möglichkeit, irgendwie das template zu sperren, da 99,9% áller aufrufe auf das eine template laufen mit den entsprechenden unterseiten.

damit habe ich es versucht, aber ohne erfolg:
RewriteCond %{QUERY_STRING}  /cgi-bin/seite&|$

ich möchte im grunde alles sperren, was mit /cgi-bin/seite& anfängt, da mehrere seiten auch unter z.b. /cgi-bin/seite&wcheck=1&Pos=3672.12 oder  z.b. /cgi-bin/seite&wcheck=1&Pos=2211.05
zu erreichen sind.

hoffe, mir kann jemand helfen.
danke
sascha

Hallo,

da ich weder den Apachen benutze noch firm in sowas bin, ein paar Codezeile zur Anregung wie man in anderen Webserver Sachen regelt. Da die Grundgedanken vom Apachen kommen, hilft es vielleicht eine Idee, zur schnellen Lösung zu finden.

Beispiel 1

if ($http_user_agent ~* aesop_com_spiderman|alexibot|backweb|bandit|ba
tchftp|bigfoot|black.?hole|blackwidow|blowfish|botalot|buddy|builtbott
ough|bullseye|cheesebot|cherrypicker|chinaclaw|collector|copier|copyri
ghtcheck|cosmos|crescent|curl|custo|da|diibot|disco|dittospyder|dragon
fly|drip|easydl|ebingbong|ecatch|eirgrabber) {
rewrite ^/ http://www.example1.com/robots.txt;

Beispiel 2

if($http_user_agent ~ "Alexibot|Art-Online|asterias|BackDoorbot|Black.
Hole|\ BlackWidow|BlowFish|botALot|BuiltbotTough|Bullseye|BunnySlippers|Cegbf
eieh|Cheesebot") {
deny all;
}
if ($http_user_agent ~ Google|Yahoo|MSN|baidu) {
limit_rate 20k;
}

Beispiel 3

if ($http_referer ~* (.us$|dating|diamond|forsale|girl|jewelry|organi
c|poker|poweroversoftware|teen|webcam|zippo) ) {
deny all;
}

Beispiel 4

server_name www.example1.com;
location ~* ^.+.(jpg|jpeg|gif)$ {
valid_referers none blocked example1.com www.example1.com;
if ($invalid_referer) {
return 444;
}

Kay

[Dennis]

Hi sascha_k,

damit habe ich es versucht, aber ohne erfolg:
RewriteCond %{QUERY_STRING}  /cgi-bin/seite&|$

Eine RewriteCond ohne eine RewriteRule dahinter bringt nichts, steht auch so in der Doku:

The RewriteCond directive defines a rule condition.
  One or more RewriteCond can precede a RewriteRule directive.
  The following rule is then only used if both the current
  state of the URI matches its pattern, and if these conditions
  are met.

Probier mal folgendes:

# Serve 403 for all URLs starting with cgi-bin/seite  
RewriteRule ^cgi-bin/seite.*$ - [F]

Das sollte für alle gewünschten URLs eine 403 Forbidden liefern. Falls du das in die VirtualHost-Konfiguration schreibst, muss noch ein Slash vor cgi-bin, falls du es in eine .htaccess im cgi-bin Ordner schreibst muss das cgi-bin/ raus.

Viele Grüße,
  ~ Dennis.

[Dennis S]

Hallo Sascha,

irgendwie kommt mir dein Parameteraufruf (wcheck, pos) und Problem bekannt vor. Ärgere mich vermutlich mit dem selben herum.

Die Spammversuche waren zuletzt so zahlreich, das der Server kaum noch Luft bekommen hat.
Eine Umleitung im Apache kann funktionieren. Aber auch wenn du die Formulare jetzt vermutlich irgendwo versteckt hast, werden die Bot's sie irgendwann finden.

Da du nicht über Spamm klagst, hast du warscheinlich schon einen funktionierenden Filter gefunden und suchst jetzt einen Weg die Last zu reduzieren.

Hier mein Ansatz, wie ich bei der Seite den http Traffic von knapp 4Gb am Tag auf 1Gb gesenkt habe. (root Rechte vorrausgesetzt)

Dem Perl Prozess musst du zunächst sudo rechte an iptables geben.

Durch zuviele Spammversuche oder falsche Logins machen die Bot's auf sich aufmerksamm (Du wirst da deinen eigenen Weg gefunden haben) Ich lass da eine Datenbank parallel zum Spammfilter mitloggen. Und bei 3 Versuchen innerhalb von 2 Sekunden passiert folgendes.

$returnc = qx(sudo /usr/sbin/iptables -I INPUT -s $Ip_adresse -j DROP);

Nun ist Ruhe, denn der Teilnehmer ist direkt an der Firewall geblockt.

---
Das bringt mich zu der eigentlichen Frage von mir zu diesem Thema:

Seit Tagen beobachte ich wie sich die Firewallregeln mit hunderten von Adressen (90% aus China) füllen.
Wie lange geht das gut? Gibt es eine Maximalwert, bei der die Firewall schon alleine duch die Anzahl der Regeln überfordert ist? Wo liegt der typisch?

Ist das überhaupt der geeignete Ansatz das Problem zu lösen?

[Jens Holzkämper]

Tach,

Dem Perl Prozess musst du zunächst sudo rechte an iptables geben.

uh, potentielle Sicherheitslücke, ick hör dir trapsen; einem Perl Script, das aus dem Internet erreichbar ist, teilweise Root-Rechte zu geben, ist zumindest gewagt.

$returnc = qx(sudo /usr/sbin/iptables -I INPUT -s $Ip_adresse -j DROP);

Hier fehlt das Escaping und dabei wäre es mir vollkommen egal, ob ich sicher bin, was in $Ip_adresse drin steht: $returnc = qx(sudo /usr/sbin/iptables -I INPUT -s \'$Ip_adresse\' -j DROP);

Wie lange geht das gut? Gibt es eine Maximalwert, bei der die Firewall schon alleine duch die Anzahl der Regeln überfordert ist? Wo liegt der typisch?

Dafür wird es keine einfache Vorhersage geben, das hängt zu sehr von der Hardware, der verwendeten Version von netfilter und der genauen Form der Regeln ab. Du löscht die Regeln ja bestimmt auch automatisiert nach einer gewissen Zeit wieder, damit es nicht zu einem größeren Problem wird, oder?

Ist das überhaupt der geeignete Ansatz das Problem zu lösen?

Ich würde sagen nein, da gibt es bessere Lösungen, die das selbe bewirken (z.B. Fail2ban), ohne dabei direkt dem Internet ausgesetzt zu sein und sich automatisch um das löschen alter Regeln kümmern.

mfg
Woodfighter

[Dennis S.]

uh, potentielle Sicherheitslücke, ick hör dir trapsen; einem Perl Script, das aus dem Internet erreichbar ist, teilweise Root-Rechte zu geben, ist zumindest gewagt.

Darf man "sicher" nicht außer Acht lassen. Aber bei einem Webserver der standardmäßig sowieso von überall erreichbar ist, scheint das Risiko überschaubar.

Hier fehlt das Escaping

richtig

Wie lange geht das gut? Gibt es eine Maximalwert, bei der die Firewall schon alleine durch die Anzahl der Regeln überfordert ist? Wo liegt der typisch?

Dafür wird es keine einfache Vorhersage geben, das hängt zu sehr von der Hardware, der verwendeten Version von netfilter und der genauen Form der Regeln ab. Du löscht die Regeln ja bestimmt auch automatisiert nach einer gewissen Zeit wieder, damit es nicht zu einem größeren Problem wird, oder?

Automatisch passiert da noch nichts. Teilweise sehe ich momentan auch die selben IP's Tage später noch. Meinetwegen muss ich die nie wieder. Möglichweise könnte ich einmal im Monat die Regeln automatisch zurücksetzen und ganz von vorne anfangen (oder so). Aber meine Frage habe ich nur gestellt, um zu erfahren, wie lange ich noch Zeit habe um mir genau darüber Gedanken zu machen. ;)

Ist das überhaupt der geeignete Ansatz das Problem zu lösen?

Ich würde sagen nein, da gibt es bessere Lösungen, die das selbe bewirken (z.B. Fail2ban), ohne dabei direkt dem Internet ausgesetzt zu sein und sich automatisch um das löschen alter Regeln kümmern.

Danke für den Tip. Muss ein extra Logfile mit den "Bad Actions" dafür geschrieben werden, welches Fail2ban dann analysiert. Aber auch Fail2ban wird genauso unmengen von Einzelregeln einrichten. Meine Skepsis, dass die irgendwann zu viel für den kleinen Server sind, die bleibt. Aber ein löschen nach Zeit ist damit schonmal sauber gelöst. Nur hoffe ich, dass fail2ban nicht mehr Ressourcen frisst, als es einspart.

Danke soweit, Frage beantwortet.

Gruß
Dennis

[Jens Holzkämper]

Tach,

uh, potentielle Sicherheitslücke, ick hör dir trapsen; einem Perl Script, das aus dem Internet erreichbar ist, teilweise Root-Rechte zu geben, ist zumindest gewagt.

Darf man "sicher" nicht außer Acht lassen. Aber bei einem Webserver der standardmäßig sowieso von überall erreichbar ist, scheint das Risiko überschaubar.

zwischen der Webserver-User ist kompromittiert und der Root-Account ist kompromittiert, ist ein großer Unterschied.

Danke für den Tip. Muss ein extra Logfile mit den "Bad Actions" dafür geschrieben werden, welches Fail2ban dann analysiert.

Nein, das kann das ganz normale Log des Dienstes nutzen.

mfg
Woodfighter

[Der Martin]

Hallo,

Spammversuche
Spamm
vorrausgesetzt
Spammversuche
aufmerksamm
Spammfilter

du scheinst eine Vorliebe für Konsonantenverdopplung zu haben, vor allem beim 'm'. ;-)

Ciao,
 Martin