18:02
13/4/2013

Od kilku dni blogi postawione na WordPressie są celem ataków polegających na zgadywaniu haseł — atakujący dysponują botnetem składającym się z 90 000 hostów.

Wzrosła liczba ataków zgadywania haseł

O atakach poinformowały m.in. firma hostingowa Hostgator, a także CloudFlare, który sprytnie wykorzystuje ten atak do promocji swojego chmurowego WAF-a:

Because CloudFlare sits in front of a significant portion of web requests we have the opportunity to, literally, patch Internet vulnerabilities in realtime

Wordpress

WordPress

Ale niestety, te ataki to nie wymysł marketingowców z Cloudflare’a — są prawdziwe — co potwierdzają statystyki firmy Sucuri za ostatnie miesiące:

Luty: 1,034,323 prób zgadywania haseł (36k dziennie)
Marzec: 950,389 prób zgadywania haseł (31k dziennie)
Kwiecień: 774,104 prób zgadywania haseł (77,410 dziennie)

Wszystkie te firmy mylnie nazywają ataki “brute-forcem”, kiedy wszystko wskazuje na to, że botnet korzysta raczej ze słownika…

Sucuri publikuje także listę wykorzystywanych w atakach loginów i haseł:

loginy

admin
test
administrator
Admin
root

hasła

16,798 [pwd] => admin
10,880 [pwd] => 123456
9,727 [pwd] => 666666
9,106 [pwd] => 111111
7,882 [pwd] => 12345678
7,717 [pwd] => qwerty
7,295 [pwd] => 1234567
6,160 [pwd] => #@F#GBH$R^JNEBSRVWRVW
5,640 [pwd] => password
5,446 [pwd] => 12345
5,392 [pwd] => $#GBERBSTGBR%GSERHBSR
5,058 [pwd] => %G#GBAEGBW%HBFGBFXGB
5,024 [pwd] => RGA%BT%HBSERGAEEAHAEH
4,861 [pwd] => aethAEHBAEGBAEGEE%
4,317 [pwd] => 123
4,281 [pwd] => 123qwe
4,133 [pwd] => 123admin
4,092 [pwd] => 12345qwe
4,086 [pwd] => 12369874
3,880 [pwd] => 123123
3,831 [pwd] => 1234qwer
3,814 [pwd] => 1234abcd
3,787 [pwd] => 123654
3,751 [pwd] => 123qwe123qwe
3,744 [pwd] => 123abc
3,623 [pwd] => 123qweasd
3,606 [pwd] => 123abc123
3,422 [pwd] => 12345qwert

Upewnijccie się, że nie używacie żadnego z powyższych!

Oczywiście obecnie największa tajemnicą jest obecność tych skomplikowanych haseł w słownikach atakujących oraz powód włamywania się na WordPressy; czy chodzi o przejęcie serwerów, które dysponują dużym uploadem, aby wykorzystać je w atakach DDoS?

Jak zabezpieczyć WordPressa?

Przed skutkami ataków zgadywania haseł najlepiej zabezpieczyć się ustawiając trudny do przewidzenia login i niesłownikowe, unikatowe (niewykorzystywane w żadnym innym miejscu) hasło. O ile silne hasło zabezpieczy nas przed przejęciem kontroli nad naszym blogiem, to wcale nie oznacza, że atakujący przestanie wysyłać w naszą stronę zautomatyzowane zapytania, które obciążają serwer i spowalniają działanie bloga — na to rada jest jedna — wykrywać błędne próby logowania i banować intruzów. Efekt ten można osiągnąć na kilka sposobów…

    Najgorszym (a niestety najczęściej polecanym) jest wgranie odpowiedniego pluginu do WordPressa (np. Better WP Security, Limit Login Attempts). Należy mieć świadomość, że wtyczki te nie uchronią nas przed atakiem bo pochodzi on z wielu adresów IP! Natomiast prawie na pewno, dzięki instalacji tych wtyczek zwiększymy powierzchnię ataku (ew. dziury w kodzie dodatkowej wtyczki), oraz spowolnimy działanie naszego bloga (PHP nie jest zbyt efektywne w bronieniu się przed atakami na PHP ;)

    Dlatego można rozważyć dostęp do panelu logowania tylko dla wybranego IP lub przeniesienie panelu logowania do WordPressa w inne miejsce, przy czym warto wtedy na starą lokalizację założyć dodatkową warstwę ochrony-pułapkę w postaci uwierzytelniania BasicAuth (popularnie zwanego .htaccess) — ale uwaga, nie wystarczy wrzucić .htaccess do /wp-admin bo za logowanie de facto odpowiada plik /wp-login.php! On też musi być objęty ochroną. Po wdrożeniu BasicAuth należy zliczać w logach nieudane próby logowania i banować intruzów np. przy pomocy pakietu fail2ban.

Zawsze dobrym pomysłem w przypadku WordPressa jest przestrzeganie zaleceń dotyczących bezpieczeństwa pochodzących z oficjalnej strony WordPressa lub wdrożenie dwuskładnikowego uwierzytelnienia (użytkownicy blogów w domenie WordPress.com mogą je po prostu włączyć w ustawieniach, inni są skazani na wtyczkę np. DuoSecurity lub Google Authenticator).

Przeczytaj także:

61 komentarzy

Dodaj komentarz
  1. Trzecie rozwiązanie: zbyt popularny i ze znanymi powszechnie źródłami oraz lokalizacjami plików system blogowy zastąpić autorskim CMSem. ;-)

    • “Autorskie CMS’y” (a może bardziej “amatorskie CMS’y”) najczesciej sa tak popisane przez “programistow-amatorow” ktorzy probuja z gowna (swojej mizernej wiedzy) ulepic zamek, ze nie nadaja sie do NICZEGO. Widzialem juz kod wielu takich potworkow. Pozdrawiam.

    • Autorski CMS być może przed tym konkretnym atakiem akurat lepiej się broni, ale przed wszystkimi innymi o wiele gorzej. A z ciekawośc: algorytmy kryptograficzne też kolega sam pisze? :)

    • tak, tylko żeby napisać dobrego CMSa bez dziur trzeba by było siedzieć tygodniami/miesiącami nad kodem, a nie każdy ma zamiar pisać CMSa bod bloga, który może okazać się klapą!

    • @Lukasz, w Twoim komentarzu słowo “najczęściej” sprawia, że cały komentarz niczego nie wnosi. Autorzy WordPress’a nie są jedynymi profesjonalistami na świecie.

      @Darek, z tymi algortymami kryptograficznymi to tani chwyt erystyczny. Jest olbrzymia różnica poziomów potrzebnych do implementacji (nie mówiąc już o wymyślaniu) algorytmów kryptograficznych a systemów CMS. Kolega bierze się za to, na czym się (jak się mu wydaje) zna.

      @WP, zgadza się, ale jeżeli blog już jest popularny to inwestycja wiąże się z niewielkim ryzkiem. Poza tym autorski nie musi oznaczać indywidualnie tworzonego – może po prostu oznaczać mniej popularne, niszowe (co nie oznacza, że “ulepione z gówna”) rozwiązanie.

    • Ależ oczywiście, że nie. Powiem więcej – kod WP jest równie paskudny, co “autorskich CMS” – ale ma mniej dziur i jest lepiej udokumentowany dla kogoś z zewnątrz zatrudnionego przez biednego właściciela strony, kiedy się okaże, że firma rozwijająca “autorskiego CMS’a” chce 500 zł za podmianę obrazka :).
      Profesjonalnie napisanym CMSem powoli staje się drupal. Profesjonalnego CMS’a można zbudować z komponentów dostępnych od ręki dla frameworka Symfony 2. Bardzo dobrze kiedyś dla mnie zapowiadał się digitalus, ale chyba projekt zostal porzucony.
      Powtorze clue: 90% autorskich CMS nie nadaje się do niczego, jest proba odkrycia kola na nowo i nabicia klienta w butelke.

    • Pomylka, Digitalus zyje, teraz zajrzalem w internet ;)

    • @Lukasz

      Jakby WP był taki paskudny to z pewnością nie korzystałby z niego niebezpiecznik.

    • @Lukasz Nie rozpędzałbym się z tym Drupalem. Dwie rzeczy wg. mnie skreślają go kompletnie jako profesjonalne narzędzie:
      1. Trzymanie logiki aplikacji w bazie danych – nie ma mowy o stosowaniu systemu kontroli wersji.
      2. Proceduralna architektura. Tak się pisało w bandyckich latach 90.

    • Klienci nie lubią autorskich cmsów, i nie ma takiej potrzeby gdzie prosta stronkę można szybko bazować np. na WP + jest szybciej i taniej. Pisałem portal noclegowy (autorski) dla pewnych ludzi którzy w momencie rozliczeń za każdym razem nawiązywali do dyskusji “dlaczego tak drogo”. W pewnym momencie straciłem cierpliwość i powiedziałem żeby pisali to sobie sami ;)

  2. Ja chcę taką wtyczkę Google Authenticator do Joomli :P.

  3. Polecam wtyczkę Lockdown WordPress Admin
    która zmienia link do logowania się do admina z domyślnego /wp-admin na dowolny ciąg znaków ustalany przez nas,

    • Gorzej jak bociki nie wchodzą po linku, tylko od razu bezczelnie ładują /wp-admin.

    • @SuperTux
      Właśnie dlatego zmienia się domyślny /wp-admin na coś innego

  4. Ja miałem 12 kwietnia, aż 7 prób logowania i zablokowania. Nieźle, bo nigdy wczesniej tyle sie nie zdażało. Najwyżej 1 na 3 dni.

    Dzięki za info. Na pewno dodam sobie te dodatkowe zabezpieczenia.

  5. Mój blog ma się dobrze :) Może dlatego że mały ruch. Od dawna mam te główne wtyczki aktywne o których mowa. Wiele takich jest dostępnych, kilka z nich też posiadam, np.:
    Login Lock – Enforces strong password policies, monitors login attempts, blocks IP address for too many failed login attempts.
    Jak na razie się nie gryzą.

  6. Czy to zagrożenie dotyczy tylko WP czy także innych darmowych CMSów jak Joomla! czy Drupal?

    • Zagrożenie dotyczy wszystkich po równo, bo nigdy nie wiadomo kto i kiedy zacznie robić masowe ataki. Ale ten artykuł (i jak z niego wynika) informuje o ostatnio odkrytym ataku na WordPressa. Więc o swoją Joomlę możesz być nieco spokojniejszy ;>

  7. Warto też zabezpieczyć xmlrpc.php, bo za jego pomocą również możliwe jest “testowanie” loginów i haseł.

  8. A co to za hasła ‘#@F#GBH$R^JNEBSRVWRVW’ itp.?

    • Podejrzewam że to najczęstsze hasła generowane automatycznie przez WP ale to tylko domysł.

  9. Z ciekawości wrzuciłem do siebie Limit Login Attempts i po ok. 2 godzinach już zablokowało mi 2 adresy IP.

  10. Nie rozumiem, dlaczego wtyczki typu Better WP Security, Limit Login Attempts są “najgorszym rozwiązaniem” ?
    Owszem, nie pomogą na dobrze przygotowany atak z pierdyliarda adresów IP, ale zdecydowanie podniosą skuteczność w innych, mniej wyrafinowanych próbach.
    Osobiście korzystam i regularnie co pewien czas jednak coś blokują, co w połączeniu z trudnym do odgadnięcia hasłem jest dość dobrą barierą, puki co. A jak będzie DDoS to raczej przeciętny blogger i tak nic nie poradzi, lepsza chwilowa niedostępność niż odgadnięcie hasła.

  11. Witam, tak trochę w związku z tym, a dokładnie chciałem spytać jaką polecacie wtyczkę do antyspamu dla komentarzy już stosowałem obrazkowe, obliczanie wyniku liczb, ale nie chcę też takiej gdzie mam pobierać jakiś klucz ze strony na którą wysyłane są wszystkie komentarze moich odwiedzających. Dziennie potrafię mieć kilka spamów, kiedyś było tak dużo, że musiałem wyłączyć komentowanie. Owszem powinienem zrobić aktualizację wordpressa (bo jest to 3.1), ale to chyba nie ma dużego wpływu na to, a tak nigdy czasu na nic nie ma.

    • Do spamu w komentarzach tylko Akismet – to najlepsza “pierwsza linia”. Gdyby się okazało, że coś będzie przepuszczał, to wtedy dopiero możesz stawiać kolejną linię za nim. Wiem co mówię, bo sam się tym spamem na co dzień zajmuję ;)

  12. Hehe, u mnie z 20 prób logowania :p
    Skurczybyki jedne.
    Dzieki niebezpieczniki za info!

  13. @Tomek: Spróbuj “Cookies For Comments” i dodatkowo ustaw rozsądny minimalny czas – boty lubią działać szybko.

  14. Ja już jakiś czas temu zainstalowałem coś takiego:
    http://bestwebsoft.com/plugin/captcha-plugin/

    prosta i miła capatcha rozwiązała problem ze spambotami, ataków o których mowa również nie zauważyłem

  15. http://wordpress.org/extend/plugins/wp-fail2ban/
    ot ciekawa wtyczka :) i dziala

  16. U mnie jedyne ponad 8000 prób zalogowania się tylko do jednej ze stron ^^

  17. A htaccess na folder admina + fail2ban się sprawdzi? ;-)

  18. Potwierdzę tendencję, ale dodam, że problem nie dotyczy magicznych ‘ostatnich dni’. Problem ten istnieje od przynajmniej kilku lat i nasila się. Oczywiście odwiedziny botnetów zgadujących hasła przebiegają z różną częstotliwością i natężeniem. W moim przypadku wykonałem w 2011 roku prostą pracę – skrypt wp-login.php został zastąpiony plikiem zbierającym dane o źródłach wejść. Po uporządkowaniu danych okazało się, że 90% ruchu tego typu wpada do mnie z popularnych serwerowni świadczących usługi wirtualizacji masowo z dwutygodniowym okresem bezpłatności ;) Stosownie skonstruowany firewall i problem praktycznie przestał występować. Raz na jakiś czas należy tylko odświeżyć klasy adresowe w regułach ;)

  19. dziadki moje drogie a gdzie można zobaczyć liczbę błędnych logowań? gdzieś w panelu WP?

    • Do wykrycia błędnych logowań jest fajna wtyczka Login Logger.

      A co do prób logowań, to potwierdzam, jak kolega @Artur, że to nie jest problem ostatnich kilku dni. U siebie zauważyłem ten stan rzeczy już od co najmniej kilku miesięcy.

  20. Od dawna zastanawiam się czy polecane w artykule przenoszenie domyślnej lokalizacji panelu admina jest techniką głębokiego ukrycia.

    • Jeśli tylko na interface prywatny za VPN to nawet bardzo głębokiego ;)

  21. #@F#GBH$R^JNEBSRVWRVW?

  22. Jednego nie rozumiem – piszecie że ataki są słownikowe, a wszystkie podane hasła wskazują raczej na brute-force.

    No chyba że macie mniej legalny biznes na boku ;).

  23. Nie do końca zgadzam się, że wgranie WP Better Security jest złym pomysłem. Samo wgranie wtyczki wiele nie zmienia, ale odpowiednie jej skonfigurowanie owszem. W konfiguracji wtyczki można ustawić właśnie takie zabezpieczenia jakie sugerowane są w artykule.

    Kila najbardziej przydatnych:
    – zmiana ścieżki logowania
    – zmiana domyślnego prefiksu bazy
    – wymuszenie mocnych haseł
    – zmiana praw dostępów do plików wp-config.php oraz .htaccess
    – blokada wielokrotnych prób logowania
    – logowanie 404
    – blokowanie długich URL

  24. “PHP nie jest zbyt efektywne w bronieniu się przed atakami na PHP”

    Hmm, myślę że na pewno radzi sobie lepiej niż RoR ostatnio, ponadto php-5.4 jest o niebo szybszy i mniej pamięciożerny – więc PHP jako backend w przypadku ataku wcale nie musi być dodatkowym gwoździem do trumny – wszystko zależy od programisty :-).

  25. To chcecie powiedzieć, że autorskie rozwiązania są do niczego …. ?

    Czy po prostu tak piszecie, ponieważ sami nie programujecie i korzystacie z takich łatwo dostępnych rozwiązań?

    Ciekawe, kto tu jest programistą, czy raczej kopierem czyjegoś kodu ….

    Napiszcie co o tym myślicie, bez urazy oczywiście …..

    • Dla większości stron po prostu nie potrzeba autorskiego rozwiązania. WorpPress jest na tyle elastyczny, że można za jego pomocą wykonać dużo więcej niż tylko prosty blog.
      Nie ma więc potrzeby wymyślania od nowa koła. Po co pisać od podstaw system logowania, publikacji stron, postów, zarządzania użytkownikami, skoro w WP jest to zrobione na prawdę dobrze. Pisząc te rzeczy od podstaw prawdopodobnie spędzimy na tym wiele czasu, a wcale nie mamy zagwarantowane, że nasz system będzie mniej bezpieczniejszy.

      Poza tym problem opisywany w artykule to zwykły atak brute force, nie mający nic wspólnego z dziurami w systemie CMS.

  26. Dodałem 9 w haśle, dla bezpieczeństwa.

  27. Autorskie rozwiazania moga byc tez postawione na frameworkach django / flask gdzie wszystkie najwazniejsze funkcje strony sa napisane przez “calodobowych” programistow a amator tylko skleja stronke z tych “klockow”. Czy w takim przypadku autorskie rozwiazanie tez jest do niczego?

  28. Jesteśmy zdecydowanie za systemami autorskimi chociaż czasem na życzenie klienta wdrażamy również WP, joomle, typo3 etc. Systemy autorskie pisane bez wsparcia frameworków i wiedzy którą zdobywa się latami mogą być trudne w rozwijaniu, administracji, posiadać szereg błędów. Dlatego muszą mieć wsparcie, update etc. My korzystamy z autorskiego systemu który jest ciągle rozwijany i pozbywamy się niedociągnięć. System działa w kilkuset projektach. System autorski jest dużo lepszy w rękach profesjonalistów ponieważ budowa dodatkowych modułów nie stanowi problemu. Wdrożenie naszego systemu dla projektu internetowego zajmuje nam dużo mniej niż WP etc. Wybieramy to co najlepsze dla naszych klientów i dla nas samych. Z pewnością dobrze wykonane systemy autorskie są również bezpieczniejsze niż te z otwartym kodem sprawa jest chyba oczywista.

    • Chyba przede wszystkim to co dla Was samych, z uwagi na to, że innym firmom wykonać moduł etc będzie trudniej. Takie rozwiązania uwiązują klienta.

  29. Co do otwarcia kodu i bezpieczenstwa to dla mnie oczywiste jest wrecz przeciwne zdanie. Jednak nie pytalem tutaj o autorskie rozwiazania pisane przez profesjonalistow ale wlasnie amatorskie ale oparte na sprawdzonym i pisanym przez profesjonalistow frameworku.. czy takie tez jest “do niczego”?

  30. niom, to się robi konkretna dyskusja na ten temat … bo to trochę takie dziwne że jest najazd na autorskie rozwiązania i oczywiście przypisywania im że są do niczego i “NIEBEZPIECZNE” … ;) bez urazy oczywiście dla fanów wp, drupala, jojo itd etc. i reszta końcówek :)

    Mam szacunek do takich rozwiązań, jednakże, nie pozwolę na najazd na autorskie rozwiązania.

    Jeśli chodzi o bezpieczeństwo itd, to każdy się uczy … to prawda że są może popularniejsze i jest większa rzesza użytkowników, ale to tak jak z windows, im popularniejszy nie znaczy że lepszy, więcej dziur itd. zupełnie inaczej sprawa przedstawia się z OS X czy linux … czy ja jestem w błędzie ;/ ;)

  31. Na moje oko to BlackHatSeowcy chcą dostać linka i wrzucić tam jakiś link. Zakładając, że złamią 10000 naszych blogów (na pewno WARTOSCIOWYCH dla google z wysokim site i PageRank) to mają świetną liczbę linków. Problem mają z tym, że jak spamuja komentarze, to mają nofollow (link nie przekazuje mocy pozycjonerskiej), a jak dodadzą sobie “artykuł”, lub wepchają go niezauważenie do słowa to mają doskonały link kradnący nam moc z bloga. Jeśli zrobili to inteligentnie to sprawdźcie czy nie doszły Wam linki do jakiejś piramidy albo do głównej domeny. Jesli byli mało inteligentni i spalili swój pomysł to będą chcieli wrzucić nic nie warte presell pages, które szybko wywalimy. Na moje oko taki jest cel tego ataku, bo potencjalne korzyści z takiego masowego zostawiania linków są ogromne.

    Pozdrawia BlackHatSeowiec.

    P.S. Starczy captcha na logowanie i problemy znikają (ale niestandardowa, bo reCaptcha to łamią deathbycaptcha i podobnymi) .

  32. Od dawna używam wtyczki, która ustawiona jest tak, że po jednej próbie wpisania błędnego loginu lub hasła, blokuje możliwość logowania na dobę, wysyła do mnie powiadomienie o tym incydencie jak również ip delikwenta.

    Ostatnia próba zgadywania hasła nastąpiła 4 dni temu i pochodziła z Niemiec.

    Taka wtyczka powinna być wbudowanym mechanizmem wordpressa.

  33. drumknott

    a jaka to wtyczka jeśli możesz zdradzić?

  34. Mam coś co pogodzi “wtyczkowców” i “htacces’owców” – wtyczka BulletProof Security z bardzo rozbudowanymi opcjami zabezpieczeń na poziomie .htaccess na WP. Są wersje Free i Pro:
    http://www.ait-pro.com/bulletproof-security-pro-flash/bulletproof.html

  35. Mam pytanie do fachowców. Czy jest możliwość aby ktoś przejął moje hasła zapisane w pliku (katalog firefoxa) w trakcie odwiedzin jakiejś strony, przelądania jej ?

  36. CloudFlare daje radę. 10-15 wpisów dziennie mam w logu, że wyświetlili podejrzanemu captchę i jej nie wypełnił. Czyli 10-15 prób spamu/zalogowania mniej dziennie u mnie.

  37. Ja wtopiłem :/ Hasło dałem proste, bo skasowałem nickname używany do logowania. Zapomniałem o RSS …
    Strata niewielka, stąd zabezpieczenia niewielkie. Po przeczytaniu tego newsa sprawdziłem blog i wszystko wyglądało ok, ale nie popatrzyłem w logi, a dopiero wczoraj przed 3 znalazłem awstats i odkryłem 6 tyś prób przez 3 dni, bo logi apacha z tego okresu skasowane. Deface strony pojawił się dopiero przedwczoraj.
    Zrobiłem backup całego hostingu, wgrałem świeżą paczkę WP, przejrzałem bazę, 2 razy zmieniłem hasła użytkownika i bazy na kompletnie losowe i ręcznie zmniejszyłem uprawnienia do autora z poziomu mysql. W razie możliwości dodam autoryzację certyfikatem po SSL.
    Minus dla mojego hostingu, bo o 3 w nocy nie było się do kogo zgłosić i możliwości zarządania strasznie ubogie. Minus dla mnie za frajerstwo, ale czegoś się nauczyłem niskim kosztem :D

  38. WordPress to dziura, a jeszcze większa to Joomla. Ten CMS to programistyczny odpad. Poważne strony stoją na dedykowanych CMS’ach, i są o wiele bardziej odporne. Problem w tym, że większość firm tworzących witryny z takimi cmsami to amatorzy nie potrafiący nawet poprawnie skleić HTMLa pod nowoczesny, co tam nowoczesny, jakikolwiek standard. Z archaicznym Transitional włącznie, a co dopiero PHP.
    Ta branża jest przesiąknięta amatorami i lamusami.

    • Ziutek masz rację, trochę mocno pojechałeś po tych lamusach, ale w dużej większości to fakt. Najbardziej zabawne jest to, że łyknął taki jeden kursu HTMLa i za chwile na swojej stronie lub gdzieś indziej nazywa się wielkim twórcą stron czy programistą, w dodatku robiącym niebywałe sklepy internetowe, portale. A w zasadzie czy doctype takie czy inne, czy inne części języka są pisane bez kompletnej wiedzy z zasad to szkoda gadać.

  39. Inną opcją jest wykupienie jakiegoś dobrego hostingu np na
    nazwie, home czy ovh. Mocny hosting powinien zapewnić płynne
    działanie strony nawet przy ataku DDoS. Minus tego rozwiązania jest
    taki, że dobry hosting to spory koszt.

  40. A co w przypadku, kiedy niestety strona została już zaatakowana i w źródle strony znajduje się kilka, kilkanaście spamowych linków? Gdzie ich szukać, żeby je usunąć? I czy zmiana hasła, aktualizacja wszystkich wtyczek itp. pomoże zabezpieczyć się przed atakiem w przyszłości?

  41. cóż, w tym kontekście nawet dziurawy ale autorski cms jest o tyle dobry, że oprze się zautomatyzowanym atakom.

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: