Beiträge von mwe

    Nun ja, mit der robots.txt ist das so eine Sache. Das ist ja kein offizieller Standard sondern nur ein "de facto" Standard, an den sich halten kann wer will. Zudem haben noch einige große Unternehmen eigene Erweiterungen eingeführt, die nur von einigen wenigen beachtet werden.
    Die offiziellsten Beschreibungen habe ich hier gefunden:
    The Web Robots Pages


    http://www.robotstxt.org/norobots-rfc.txt


    und hier:
    Performance, Implementation, and Design Notes


    In keinem von denen steht, das der Datensatz mit user-agent: * als letzes in der robots.txt stehen muss. Im Gegenteil im ersten Dokument ist sogar ein Beispiel, wo der Datensatz mit diesem Feld als erstes kommt und später noch ein weiterer Datensatz mit einem spezifischen user-agent. Während in den ersten beiden Dokumenten im wesentlichen nur steht, das eine robots.txt aus einem oder mehreren Datensätzen mit jeweils einem oder mehreren user-agent Feldern gefolgt von einem oder mehreren Disallow Feldern, legt das dritte Dokument fest, dass in einem Datensatz nur genau ein user-agent Feld vorkommen darf, gefolgt von einem oder mehreren Disallow Feldern, und dass das Feld "user-agent: *" nur einmal in der robots.txt vorkommen darf.


    Das erste Dokument ist noch sehr allgemein gehalten, während das 2 als Draft einer RFC schon recht konkrete Angaben macht, wie eine robots.txt zu interpretieren ist.
    " These name tokens are used in User-agent lines in /robots.txt to
    identify to which specific robots the record applies. The robot
    must obey the first record in /robots.txt that contains a User-
    Agent line whose value contains the name token of the robot as a
    substring. The name comparisons are case-insensitive. If no such
    record exists, it should obey the first record with a User-agent
    line with a "*" value, if present. If no record satisfied either
    condition, or no records are present at all, access is unlimited."


    Wenn ich das richtig verstehe bedeutet das, dass ein robot die erste Anweisung in der robots.txt, die seinen Namen enthält, zu beachten hat, sollte diese nicht existieren, dann die erste Anweisung mit "user-agent: *". Wenn beides nicht zutrifft, ist das Durchsuchen der kompletten Seite erlaubt.


    Das letzte Dokument, ist das einzige, was man als wirklich offiziell bezeichnen kann, die Spezifikation des HTML 4.01 Standard. Erwähnt wird die robots.txt leider nur im Anhang B Kapitel 4.1 und das ist sehr kurz gehalten und lässt einigen Spielraum für Interpretationen. Aber wie schon geschrieben, in keinem der erwähnten Dokumente (sowie allen anderen, die ich durchsucht habe) steht, dass der Datensatz mit "user-agent: *" als letztes in der robots.txt stehen muß.
    Somit bleibt als einziges, was mir die Betreiber von Pixray und Co entgegnen könnten - sie halten sich an dass, was in der HTML 4.01 Spezifikation Anhang B festgelegt ist und da ich mehrere user-agents Felder hintereinander habe und erst dann die Disallow Anweisung kommt, können sie das ignorieren.


    Um sicher zu gehen, habe ich meine robots.txt mit verschiedenen Tools, die im Web verfügbar sind getestet. Das Ergebnis war erschreckend, je nachdem welcher Philosophie die einzelnen Prüfprogramme folgen, habe sie entweder keinen Fehler oder mehrere Fehler oder kompletten Unsinn produziert.


    z.B. New Robots.txt Syntax Checker: a validator for robots.txt files
    Hat keinen Fehler gefunden und nur eine Warnung ausgegeben, dass ich doch den user-agent:* Datensatz als letztes haben sollte(wie du empfohlen hast), weil sonst einige ältere robots verwirrt werden könnten.


    Der nächste Robots.txt Analysis - Check whether your site can be accessed by Robots (Google,Yahoo,MSN) bietet die Möglichkeit zu testen wie sich einige robots aus einer auswählbaren Liste beim Aufruf einer bestimmten URL verhalten würden. Hier kommt genau das heraus, was ich mir vorstelle, egal ob ich die user-agent:* Anweisung am Anfang oder am Ende der robots.txt habe.


    Robots.txt syntax checker keine Fehler gefunden, egal ob user-agent: * am Anfang oder am Ende der robots.txt steht.



    Robots.txt Checker führt einen Test einer URL gegen einen user-agent string durch (beides frei eingebbar). Der Test liefert genau die Ergebnisse, die ich erwarte, unabhängig davon, wo die user-agent:* Anweisung steht.



    robots.txt Checker, Test Your Robot File Syntax will nach jeder Zeile mit einem user-agent eine Disallow Zeile, meldet also jede Menge Fehler.



    Um nun allen gerecht zu werden, werde ich den user-agent: * Block ans Ende der robots.txt setzen und nach jeder user-agent Zeile eine Disallow Zeile einfügen.


    Aber eigentlich wollte ich ja wissen, welche Erfahrungen ihr so mit den verschiedensten Crawlern, Bots, Spiders oder wie sie sich auch immer nennen mögen, gemacht habt.

    Hallo,


    mich würde mal interessieren, welche Erfahrungen die Webserverbetreiber unter euch mit diversen Crawlern und Searchbots gemacht haben. Dadurch, dass mein Webserver von Spammern angegriffen wird, schaue ich mir die Logs ja nun etwas genauer an. Mir sind da 2 solcher bots besonders negativ aufgefallen.

    • Ahrefsbot
    User-agent IP Adressen
    Mozilla/5.0 (compatible; AhrefsBot/3.1; +http://ahrefs.com/robot/) 212.113.35.162, 212.113.37.105, 212.113.37.106, 213.186.119.131, 213.186.119.132, 213.186.119.133, 213.186.119.134, 213.186.119.135, 213.186.119.136, 213.186.119.137, 213.186.119.138, 213.186.119.139, 213.186.119.140, 213.186.119.141, 213.186.119.142, 213.186.119.143, 213.186.119.144, 213.186.120.196, 213.186.122.2, 213.186.122.3, 213.186.127.10, 213.186.127.11, 213.186.127.12, 213.186.127.13, 213.186.127.14, 213.186.127.2, 213.186.127.28, 213.186.127.3, 213.186.127.4, 213.186.127.5, 213.186.127.6, 213.186.127.7, 213.186.127.8, 213.186.127.9, nano2.dc.ukrtelecom.ua, node.beautystore.com.ua


    • Der bot wird in der Ukraine gehostet und scheint völlig außer Kontrolle zu sein.Die Betreiber behaupten zwar er würde eine robots.txt beachten, allerdings hat er sie ein meinem Fall nie abgerufen und stattdessen innerhalb von 13 Stunden meinen Webserver mit mehr als 12000 Anfragen bombardiert. Danach habe ich die Netzwerke in der Firewall blockiert. Immerhin reagieren die Betreiber konstruktiv auf Beschwerden via email.
    • Pixray-Seeker


    User-agent IP Adressen
    Pixray-Seeker/1.1 (Pixray-Seeker; http://www.pixray.com/pixraybot; crawler@pixray.com) 176.9.0.12, 176.9.0.13, 176.9.19.103, 176.9.7.28, 188.40.65.130, 188.40.66.214, 188.40.85.200, 46.4.116.100, 46.4.118.74, 46.4.118.75, 46.4.119.231, 46.4.121.154, 46.4.125.109, 46.4.19.85, 46.4.92.140, 46.4.92.141, 88.198.64.132, 88.198.65.99, 88.198.67.134, 88.198.67.197



    • Dieser bot wird bei NAMEENTFERNT gehostet und zeigt auch ein etwas seltsames Verhalten. Er hat doch tatsächlich innerhalb von 22 Stunden sage und schreibe 58 mal die robots.txt abgerufen. Wie oft am Tag glauben die Betreiber werde ich meine Meinung und die robots.txt ändern? Sie 1-2 mal am Tag abzurufen ist doch eigentlich völlig ausreichend. Und obwohl ich in der robots.txt schon seit längerem stehen habe:


      hat ihn das nicht gehindert, trotzdem von einigen IPs aus zu versuchen die Webseiten zu durchsuchen.
      Für mich sieht das so aus, als wäre hinter jeder IP Adresse ein eigenständiges unabhängiges Botsystem und die jeweils erhaltenen Daten werden nicht zwischen den verschiedenen Bots abgeglichen. Sowohl die Betreiber als auch NAMEENTFERNT reagieren sehr ignorant auf Beschwerden. Mehr als eine automatisierte Eingangsbestätigung, dass ein Ticket eröffnet wurde, kommt nicht zurück. Da der Bot sein Verhalten auch 3 Tage später nicht geändert hatte, habe ich die Netze ebenfalls in der Firewall blockiert.

    IPtables funktioniert auch ohne Angabe eines Protokolls, wenn ich das weglasse gilt die Regel für alle Protokolle.
    Bsp:

    Code
    $ iptables -A INPUT -s <IP-ADRESSE> -j DROP


    ergibt dann folgendes:

    Code
    $ iptables -L INPUT -n
    Chain INPUT (policy ACCEPT)
    target 	prot opt source           	destination
    DROP   	all  --  <IP-ADRESSE>       	0.0.0.0/0


    Außerdem funktioniert es ja, wenn ich eine Regel für das Netz von meinem Provider erstelle. Ich komme dann nicht mehr auf den Server.


    Und es gibt dann noch ein Problem, ich will den Server komplett unerreichbar machen, dass heißt ich müßte jede Regel 3 mal anlegen (tcp, udp und icmp). Ich habe jetzt schon 50 Regeln definiert, wenn ich das alles umstellen wollte auf die einzelnen Protokolle, bin ich bei 150 Regeln und damit oberhalb des Limits von 100 Regeln.


    Denn Server komplett unsichtbar machen hat auch seinen Grund, wenn ich ein böser Bube wäre und auf einen Server eindringen wollte, der plötzlich über tcp nicht mehr erreichbar ist, würde ich nachprüfen
    a: lebt der Server noch (ping, icmp) und wenn ja
    b: gibt es alternative Möglichkeiten, den Server doch noch mit meinem Müll zu befruchten, also einen detaillierten Portscan starten und dann dort nach Sicherheitslöchern fahnden oder versuchen von einer anderen Adresse aus den Server zu erreichen.


    Die bots die zur Zeit meinen Server attackieren scheinen eher von der dummen Sorte zu sein und versuchen nur auf den Webserver über port 80 zu kommen aber wer weiß, vielleicht schaut der Botnetzbetreiber ja auch mal Logs an, zumindest sehe ich in den Logs schon ein erstes Ausweichen auf andere Adressbereiche.


    Als admin sollte man ja immer vom worst case ausgehen und erst einmal alles verbieten und dann nur das erlauben, was benötigt wird. Leider ist das in der Praxis nicht immer umsetzbar, weil sonst manche Sachen einfach nicht mehr funktionieren. Ich kann den Server einfach nicht so dicht machen, wie ich gerne wollte, schon gar nicht wenn mir nur 100 Regeln zur Verfügung stehen.

    Alle Regeln sind mit State New, Established, Related erstellt. Trotzdem tauchen auch jetzt noch, nach fast 48 Stunden immer wieder diese IP-Adressen auf dem Server auf. Und wie geschrieben, wenn ich testweise ein Regel für das Netz von meinem Provider erstelle, greift diese sofort nach Aktivierung, selbst wenn ich mich kurz vorher auf dem vServer angemeldet habe und die Verbindung demzufolge noch offen ist. Und ich kontrolliere auch immer mal wieder mit netstat, welche Verbindungen offen sind. Aktuell 18:30 z.B.:

    Code
    tcp        0      0 localhost.localdo:10011 localhost.localdo:44329 ESTABLISHED 
    tcp        0     52 v2201110103146458.y:ssh p57ABDA38.dip.t-di:7662 ESTABLISHED
    tcp        0      0 v2201110103146458.y:www 199.15.234.159:50259    TIME_WAIT


    Das ist natürlich nicht die komplette Liste, nur der relevante Teil. Es sind also lediglich 2 Verbindungen von/nach außerhalb da. Eine ist meine SSH Verbindung zum Server und die andere von 199.15.234.159 auf den Webserver.
    Jetzt, 18:38 sieht das ganze so aus:

    Code
    tcp        0      0 v2201110103146458.y:www 199.15.234.60:57903     TIME_WAIT
    tcp        0      0 localhost.localdo:10011 localhost.localdo:44329 ESTABLISHED
    tcp        0      0 v2201110103146458.y:ssh p57ABDA38.dip.t-di:7662 ESTABLISHED
    tcp        0      0 v2201110103146458.y:www 95-25-190-29.broa:58849 TIME_WAIT
    tcp        0      0 v2201110103146458.y:www 95-25-190-29.broa:58856 TIME_WAIT


    Die WWW-Verbindung von 199.15.236.60 und meine SSH Verbindung sind nach wie vor vorhanden, aber jetzt sind noch 2 WWW Verbindungen von 95.25.190.29 hinzugekommen.

    Für dieses Netz habe ich bereits eine Regel (Nr 47) definiert: INPUT, Quell-IP: 95.24.0.0/14, Quell-Port: any, Protokoll any, Ziel-IP: 46.38.235.xx, Ziel Port: any, Zusatz State NEW,ESTABLISHED,RELATED, DROP. Dass heißt, der IP Bereich von 95.24.0.0 bis 95.27.255.255 müßte mit dieser Regel gesperrt sein und diese Verbindung hätte niemals zustande kommen dürfen, zumindest wenn ich es von innerhalb des vServers betrachte.

    Und ehe jemand fragt, ob es noch andere IP Adressen gibt unter denen der Server erreichbar ist, nein gibt es nicht. Ifconfig zeigt nur eth0 und lo als Schnittstellen. Und für eth0 sieht die Ausgabe so aus:

    Code
    eth0      Link encap:Ethernet  HWaddr 00:26:b9:89:27:6d 
     inet addr:46.38.235.xx Bcast:46.38.239.255  Mask:255.255.248.0 
     UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1 
     RX packets:6479178223 errors:0 dropped:0 overruns:0 frame:0 
     TX packets:9428141500 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 
     RX bytes:1869983070235 (1.7 TiB)  TX bytes:5176936380702 (4.7 TiB) 
     Interrupt:36 Memory:d6000000-d6012800



    Wenn ich es richtig verstanden habe, läuft die Firewall außerhalb des vServers und wie es da mit dem Verbindungsstatus aussieht, kann ich nicht kontrollieren.

    Ich sehe nur, dass die Regel nicht greift.

    Hmm, aber wird nicht für jeden http Request eine neue Verbindung aufgebaut? Jedenfalls in meinen Tests wenn ich das Netz von meinem Provider eingetragen habe (mit State New, Established, Related) war keine Verbindung zum Forum mehr möglich, auch bei bestehender Anmeldung. Ich habe die Logs mal ein bisschen mit Excel überarbeitet (erleichtert die Auswertung ungemein) und da ist mir z.B. folgendes aufgefallen:


    IP 46.116.75.193 (ist aus Israel) dafür habe ich mindesten seit meinem ersten Post eine Firewall Regel:
    [Blockierte Grafik: http://hma.mwserv.de/VCP%20FW%20Regel1.jpg]


    Wenn ich jetzt in die Logs schaue und auf diese IP Filtere, sehe ich folgendes:
    Bannlog vom Forum:
    [Blockierte Grafik: http://hma.mwserv.de/ban-report.jpg]


    und im Access log vom Webserver:
    [Blockierte Grafik: http://hma.mwserv.de/http%20access%20log.jpg
    Wen es interessiert, ich habe das Excelfile mit der kompletten Liste und die CSV Datei, die ich zum Füttern der Pivottabelle benutzt habe, angehängt.
    Das heißt hier war heute zwischen 1:52 und 11:04 eine Pause in der keine Zugriffe von dieser IP erfolgten. Solange kann man doch keine Verbindung offen halten ohne das etwas passiert. Ich habe auch mal mit netstat kontrolliert welche offenen Verbindungen es gibt, da wurde diese IP nicht aufgelistet und gerade jetzt, wo ich den Artikel schreibe, taucht sie wieder im Forum auf. ?( Ich weiß wirklich keinen Rat mehr wie ich diese Spammer von meinem Server fernhalten kann.

    Ich habe mal testweise den Adressbereich von meinem DSL Provider nach der gleichen Methode in der Firewall eingetragen. Ich kam dann nicht mehr auf das Forum. Die Spambots sehe ich aber nach wie vor im Forum obwohl dafür Regeln in der Firewall existieren. Ich bin ziemlich ratlos, warum die nach wie vor Zugriff haben. Da beim vServer ja die Firewall ja außerhalb des vServers läuft, bekomme ich auch keinerlei Einträge in den logs. Ich finde also keinen Punkt an dem ich ansetzen könnte.
    Einerseits, die Regel für das Netz von meinem Provider hat funktioniert, also kann ich die Regeln nicht falsch erstellt haben. Andererseits tauchen andere in der Firewall gesperrte Adressbereiche nach wie vor im Forum auf also funktionieren diese Regeln nicht. Ich habe sogar noch zusätzlich einzelne IP Adressen gesperrt obwohl schon Regeln für das jeweilige Netz existieren und diese an die ersten Stellen der Regeln gesetzt, trotzdem tummeln sich diese weiter munter im Forum. Ich weiß einfach nicht mehr weiter. Ich kann nur sagen, seit meinem Posting hier haben die Spambots ca. 1000 neue Einträge im Bannlog vom Forum erzeugt, also ca. 125 Einträge pro Stunde. Dazu kommen noch etliche von IPs, die ich bisher nicht in der Bannliste habe. Im Durchschnitt habe ich 10000 Zugriffe auf das Forum pro Tag von denen 49% aus Rußland, 22% nicht aufgelöst und 13% aus der Ukraine stammen, um nur die größten Trafficverursacher zu nennen.

    Hallo,


    ich habe ein ähnliches Problem mit den Firewallregeln. Ich habe alle von Hand über das VCP Frontend eingegeben, aber diese scheinen ignoriert zu werden.
    Bsp:
    [Blockierte Grafik: http://hma.mwserv.de/VCP%20FW%20Regel.jpg]


    Damit sollten ja Alle IP Adressen von 188.143.233.0 - 188.143.255 nicht mehr auf den Server zugreifen können. Leider funktioniert das nicht und ich sehe auch Stunden, nachdem ich die Regel erstellt habe, immer noch Zugriffe aus diesem Adressbereich auf das Forum, welches auf dem Server läuft.
    [Blockierte Grafik: http://hma.mwserv.de/forumlog.jpg]


    Ich weiß, ein komplettes Netz sperren, ist der große Hammer, aber das ist ein russisches Netz und das Forum ist ein deutsches. Außerdem haben es diese Spambots in den letzten Wochen (ich konnte da nicht regelmäßig ins Forum schauen) geschafft trotz Captcha über 12000 Fakeuser anzulegen und das Forum mit über 15000 Spambeiträgen zuzumüllen. Wenn ich einzelne IP-Adressen sperre, reichen die 100 Regeln, die möglich sind, bei weitem nicht aus. Es tummeln sich teilweise gleichzeitig 30-40 IP Adressen aus der Ukraine, Rußland, China und diversen anderen Ländern im Forum, die alle versuchen neue Benutzer anzulegen. (Das habe ich mittlererweile unterbunden, aber diese Zugriffe verursachen ja auch Traffic und Last auf dem Server). Ich habe mittlererweile 30 Regeln für verschiedene Quellnetze definiert, aber keine scheint zu greifen. Ich sehe die Adressen auch Stunden später immer wieder im Forum auftauchen, Ich habe den Server sogar mal neu gestartet um mit Sicherheit alle Verbindungen zurückzusetzen, aber auch das hat keine Auswirkungen.


    Hat irgend jemand eine Idee, warum das mit diesen Regeln nicht klappt?