Blokowanie zalewu robotów MSNu

Mniej więcej pod koniec grudnia, odezwał się do mnie dostawca hostingu dla aviary.pl – Dreamhost.

Napisali do mnie, że niestety muszą mnie prosić o zdjęcie serwisu bugs.aviary.pl ze względu na ogromne obciążenie łącza jakie ten serwis generuje.

To oczywiście dość mocny cios w postawowy mechanizm jakiego używa Aviary.pl do swojej pracy i na dodatek cios w punkt, na którym nie znam się aż tak dobrze (nie znam kodu Bugzilli aby ocenić co wpływa na jej wydajność). Pan z DH poinformował, że wygląda na to, że nasza bugs.aviary.pl zużywa ogromne zasoby procesora i rejestruje bardzo wysoką liczbę odwiedzin z robota MSN.

To natchnęło mnie by założyć system statystyczny i zacząć obserwować. Z DH dogadaliśmy się, że zamykamy bugzillę do czasu gdy zrozumiemy przyczynę tak dużego obciążenia.

W okresie świąt i nowego roku trudno było znaleźć czas na pracę nad tym, ale gdy w końcu się zebrałem, logi okazały się bezlitosne. Nasza Bugzilla dziennie obsługuje nasz zespół (trochę ponad 20 osób) plus odwiedzających, co powinno, na moje oko, dawać koło 60-80 osób dziennie, koło 150 wizyt, koło 600 stron.

Zamiast tego, w październiku rejestrowaliśmy średnio 6500 pobrań stron dziennie, w listopadzie 7000 a w grudniu dochodziło do 8000. To znacząca różnica zwłaszcza, że te żądania w znacznej części dotyczyły złożonych kwerend wyszukiwawczych i załączników. Takie kwerendy generują największe obciążenie serwera i są najwolniejsze.

Następnym wnioskiem było to, że około 84% tego ruchu generowane jest przez hosty w domenie 65.55 oraz 66.249 zaś najpopularniejszą przeglądarką jest msnbot/2.0b która pobrała w listopadzie 157000 stron, czyli około 13000 stron dziennie! Na dalszych miejscach było Googlebot z 2500 i Yahoo Slurp! z 166 zapytaniami dziennie.

Pierwszą reakcją było oczywiście założenie robots.txt, które powinno załatwić sprawę oraz lektura google w poszukiwaniu podobnych przypadków. Lekcja pierwsza mówiła, że są dobre i złe roboty. Dobre to takie, które sprawdzają robots.txt i jak ten mówi “nie” to nie przeszukują oraz złe, takie, które ignorują robots.txt.

Oczywiście po chwili okazało się, że msnbot/2.0b, który przychodzi do mnie z domen takich jak msnbot-65-55-104-75.search.msn.com czy msnbot-65-55-104-59.search.msn.com jest złym robotem, który ignoruje plik dla niego przygotowany (mimo, że czyta go, oj czyta, tak mniej więcej co 30 sekund przez 24h na dobę!).

Ciekawą reakcją (obserwowaną także przez innych adminow) jest to, że po włączeniu robots.txt, msnbot zaczyna oszukiwać. Mianowicie odpytuje robots.txt jako msnbot, znajduje informację, że go nie chcemy a następnie zaczyna indeksować strony podając się za Internet Explorera 6.

Przykład takiego zachowania:

65.55.51.69 - - [03/Feb/2010:14:05:41 -0800] "GET /robots.txt HTTP/1.1" 200 319 "-" "msnbot/2.0b (+http://search.msn.com/msnbot.htm)"
65.55.110.210 - - [03/Feb/2010:14:06:12 -0800] "GET /attachment.cgi?id=453&action=diff&context=patch&collapsed=&headers=1&format=raw HTTP/1.1" 200 841 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2;  SLCC1;  .NET CLR 1.1.4322;  .NET CLR 2.0.40607)" 
msnbot-65-55-232-33.search.msn.com - - [03/Feb/2010:14:06:30 -0800] "GET /attachment.cgi?id=132&action=edit HTTP/1.1" 200 477 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.2;  SV1;  .NET CLR 1.1.4322;  .NET CLR 2.0.50727;  .NET CLR 3.0.04506.648)" 
msnbot-65-55-232-33.search.msn.com - - [03/Feb/2010:14:06:44 -0800] "GET /attachment.cgi?bugid=189&action=viewall HTTP/1.1" 200 477 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1;  SLCC1;  .NET CLR 1.1.4322;  .NET CLR 2.0.50727;  .NET CLR 3.0.30729;  .NET CLR 3.5.30729;  InfoPath.2)" 
65.55.110.210 - - [03/Feb/2010:14:06:47 -0800] "GET /attachment.cgi?id=784&action=diff&context=patch&collapsed=&headers=1&format=raw HTTP/1.1" 200 2160 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2;  SLCC1;  .NET CLR 1.1.4325;  .NET CLR 2.0.50727;  .NET CLR 3.0.04506.648)" 
msnbot-65-55-232-33.search.msn.com - - [03/Feb/2010:14:06:50 -0800] "GET /attachment.cgi?bugid=189&action=viewall HTTP/1.1" 200 477 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1;  SLCC1;  .NET CLR 1.1.4322;  .NET CLR 2.0.50727;  .NET CLR 3.0.30729;  .NET CLR 3.5.30729;  InfoPath.2)"
msnbot-65-55-104-75.search.msn.com - - [03/Feb/2010:14:07:16 -0800] "GET /attachment.cgi?bugid=1098&action=viewall HTTP/1.1" 200 477 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1;  SLCC1;  .NET CLR 1.1.4322)" 

Uważny czytelnik zwróci uwagę, że bot posługuje się różnymi UA stringami, różnymi adresami IP (tak na prawde to jest ich znacznie więcej, rotują się jednak raz na kilka godzin więc trudno było to ładnie ująć w wycinku logu) i identyfikują MSN albo przez host, albo przez UA, albo w ogóle! (wiersz drugi) W takiej sytuacji domyślenie się koincydencji (oraz odwiedzin z domeny 65.55.*.* na polskim serwisie polskiego zespołu lokalizacyjnego) wymaga logicznego rozumowania i jest trudne do zapisania w sposób algorytmiczny.

Uważam takie zachowanie za skandaliczne, choć później okazało się, że nie oni jedni.

Google zachowuje się w miare sensownie i utrzymuje stałe IP crawlera, co pozwala go wyciąć po nim. Yahoo podobnie. Natomiast przedwczoraj zaatakował crawler WP, który również zignorował robots.txt i przez 3 godziny indeksował każdą kombinację kwerend wyszukania i załączniki jakie mamy w naszej Bugzilli.

Mimo to, że takich problemów mam więcej, najważniejsze są implikacje takich zachowań:

1) Jakie obciążenie generuje dla serwisów dynamicznych taki robot. Proszę zrozumieć skalę! Ten robot atakuje falami, co godzinę, przez 24 godziny na dobę, przez wszystkie dni w miesiącu, za każdym razem generując falę zapytań na poziomie 100 zapytań w minutę! I to nie są zapytania o pliki statyczne, CSS, JS czy PNG. To wyłącznie zapytania o strony! Jakie koszty to generuje, jakie obciążenie… to absurd

2) Robot, który wedle logów zaczął działac mniej więcej po uruchomieniu wyszukiwarki bing, ignoruje kontrakt społeczny między autorami stron i wyszukiwarkami i indeksuje wszystko pomimo, że pobiera też robots.txt który mu tego zabrania.

3) Jaki ma to wpływ na statystyki IE? W moim, bardzo starym mechanizmie statystyk (webalizer chyba – to dostarcza DH) ma ogromny. Aktualnie wedle niego bugs.aviary.pl odwiedza 80% użytkowników z IE6.

Na koniec dodam tylko, że obecnie stosuję niniejszy .htaccess do blokowania tego ile się da.

5 thoughts on “Blokowanie zalewu robotów MSNu”

  1. Hmm. Skoro obroną google było to że można wyłączyć kopiowanie treści przez plik robots.txt to oznacza że wp/msn.

    PS. W dokumentacji MSN znalazłem Crawl-delay (nigdzie indziej nie znalazłem opisu). Czy on też nie działa? I tak przy okazji – kto chciałby wpisywać minimalny czas indeksowania w sekundach? A dodanie wprost msnbot zamiast *? No i może przed sądem po prostu wysłać list z pogrózkami wyjaśnieniem sytłacji…

  2. miałem coś podobnego z tym że była to pierwsza indeksacja gógla (oczywiście nie właził tam gdzie nie powinien) ale równie mocno dotknął mnie spadek parametrów łącza (bez regułek w tablesach lub konfigu serwera, wysysa calutkie), aktualizacje były już mniej zasobożerne. A msn i wp trzeba wycinać, takie zachowanie jest nie do przyjęcia.

  3. Zauważyłem to samo (msnbota w ubranku IE) sporo wcześniej, natomiast nie skojarzyłem, że zmiana nastąpiła po tym, jak wyciąłem go w robots.txt.

    Z bandytów rodzimych również Szukacz olewa robots.

    Jako ciekawostkę polecam też sprawdzić w logach, co przychodzi z amazon.com i OVH(94.23.) Są bardzo twórczy w wymyślaniu User-Agent.

  4. Niezwykle drapieżny jest MSFT 207.46. Potrafi nawet 10-krotnie przebić Googlebota w dziennej liczbie zapytań i włazi wszędzie “z buciorami”. Jest co kilka minut, za każdym razem inne IP i udawanie innej przeglądarki, przez 24h na dobę. Zachowuje się jak natrętny kameleon. Chciałem z nim kiedyś delikatnie… ale nic nie pomagało – skuteczne jest tylko całkowite wycięcie 207.46.0.0/16 na poziomie serwera… i po sprawie 🙂
    iptables -I INPUT -s 207.46.0.0/16 -j DROP
    Odtąd spokój.

Comments are closed.