Captcha w formularzu logowania

Tak mnie dzisiaj olśniło, że można podnieść poziom bezpieczeństwa swojej strony na WordPress’ie poprzez dodanie kodów captcha do formularza logowania (i innych miejsc). Utrudni to nieco próby łamania haseł i kombinowania z dostępem, a może i podroży (jeśli ktoś korzysta z deathbycaptcha.com czy innych tego typu usług).

Nie było to jednak zbyt nowatorskie i odkrywcze – gotowe rozwiązania już na nas czekają i tak w moim przypadku zaintalowałem wtyczkę Captcha Code z repozytorium pluginów WordPress’a, którą na razie ustawiłem na formularze logowania, rejestracji i odzyskiwania haseł. Jak zacznie się spamowanie po komentarzach, pewnie i tam znajdzie swoje zastosowanie.

Testowanie bezpieczeństwa WordPress’a

Parę rzeczy mnie martwiło, dlatego zacząłem się rozglądać po sieci w temacie zabezpieczania WordPress’a. Jest tego trochę (m.in. polecana wtyczka Better WP Security), a z ciekawostek znalazłem skaner flunym0us

Dostępny jest pod adresem http://code.google.com/p/flunym0us/ Do działania wymaga Python’a. W moim przypadku skorzystałem z VPS’a i tam zainstalowałem wszystko co potrzebne. Rzecz stosunkowo prosta, jeśli są opanowane podstawy poruszania się w Debianie i korzystania z bash’a.

  1. Wystarczy ściągnąć paczkę flunym0us-2.1.tar.gz, rozpakować.
  2. Zainstalować Pythona i moduł argparse do niego:
    apt-get install python python-argparse
  3. W katalogu flunym0us wykonać polecenia:
    python setup.py build
    python setup.py install
  4. w wynikowym katalogu build/scripts założyć plik słownika np. wordlist i na początek wpisać tam cokolwiek (obstawiam, że to lista haseł do bruteforce’a)
  5. zacząć korzystać z narzędzia poprzez wywołanie:
    ./flunym0us -H http://twoj-adres-wordpressa.pl/ -wp -w wordlist

Z testów wyszło o tyle dobrze, że nie są niby ujawnione informacje o wersji mojego WordPressa, czy informacje o pluginach, natomiast jest wypis zarejestrowanych użytkowników, nad czym muszę popracować. Nie jest to oczywiście gwarancja bezpieczeństwa, ale zawsze jakiś punkt wyjścia do poustawiania tego co trzeba.

Jako przykład podam online’owe narzędzie http://www.scanwp.com, które zidentyfikowało moja wersję WP, zaleciło jej update do dokładnie tej samej, napisało że są publicznie dostępne jakieś pliki WordPress’a, ale już nie potrafiło przechwycić nazw użytkowników, co w sumie jest dość proste, przynajmniej na domyślnych ustawieniach. Przegrzebałem trochę pliki motywu, zmieniłem ID administratora i niby jest lepiej. Przynajmniej o tyle, że być może niektóre automaty się wyłożą …

Chciałem przetestować jeszcze http://wpscan.org/ – oparte o Ruby On Rails. Niby na szczęście dla niedoświadczonych w temacie (jak ja), dokładny opis instalacji jest na stronie, ale miałem trochę problemów. Z mojego mieszania wynikało, że jedyne czego mi tam brakowało to poleceń apt-get install git rails gem rubygems ruby-full oraz dodatkowo w trakcie (po komunikacie File not found: lib) wydałem jeszcze gem install rack + gem install rails + gem install rdoc + gem install bundle.

Cały czas jednak po wykonywaniu gem install bundler && bundle install –without test development otrzymywałem komunikat -bash: bundle: command not found

Sukces miał przyjśc gdy namierzyłem dziada w /var/lib/gems/1.8/bin/bundle

Niby się udało poskładać i już prawie dało się wykonać ruby wpscan.rb –url www.example.com, ale w nagrodę pojawił się komunikat Ruby >= 1.9 required to run wpscan (You have 1.8.7). Ponieważ samo wykonanie apt-get install ruby1.9.1 nie wystarczyło, odpuściłem temat z racji innych obowiązków …. Może jeszcze do niego powrócę ….