Przeszukiwanie folderu w poszukiwaniu plików php

[arve_lek]

Ktoś się na mnie uwziął i nie popuszcza. Ciągle szuka plików. 

 

1. Dodałem konkretne IP w pliku htaccess - /var/www/html ale to nie pomogło.

2. Włączyłem firewalla w ovh, ale to też nie pomogło. Choć nie konfigurowałem, więc nie wiem czy się da zablokować tego typu ataki ?

 

Apache mi się wiesza co kilka dni i strony się wykruszają. Restart apache i kłopot na kilka dni załatwiony. 

 

Jakieś sugestie czy da się zablokować te ataki ? 

 

[Tue Dec 11 20:18:33.856735 2018] [access_compat:error] [pid 9114] [client 47.52.26.165:11797] AH01797: client denied by server configuration: /var/www/html/7.php
[Tue Dec 11 20:18:34.075947 2018] [access_compat:error] [pid 9116] [client 132.232.32.150:58354] AH01797: client denied by server configuration: /var/www/html/myadmin
[Tue Dec 11 20:18:34.491850 2018] [access_compat:error] [pid 9117] [client 47.52.26.165:12038] AH01797: client denied by server configuration: /var/www/html/xiaoma.php
[Tue Dec 11 20:18:35.137162 2018] [access_compat:error] [pid 9119] [client 47.52.26.165:12245] AH01797: client denied by server configuration: /var/www/html/xiaomae.php
[Tue Dec 11 20:18:35.784413 2018] [access_compat:error] [pid 9123] [client 47.52.26.165:12432] AH01797: client denied by server configuration: /var/www/html/xiaomar.php
[Tue Dec 11 20:18:36.418219 2018] [access_compat:error] [pid 9134] [client 47.52.26.165:12652] AH01797: client denied by server configuration: /var/www/html/qq.php
 

[#Gremsonkowy#]

iptables -I INPUT -p tcp -s 47.52.26.165 -j DROP

[arve_lek]

Tylko takich ip ciągle mi przybywa. Ręcznie IP muszę dodawać ? Jeżeli ktoś korzysta z publicznych proxy to ręcznie będzie ciężko to zrobić.

 

Plik errors z dnia dzisiejszego zawiera już  35tys wierszy i tak każdego dnia.

[#Gremsonkowy#]

6 minut temu, arve_lek napisał:

Tylko takich ip ciągle mi przybywa. Ręcznie IP muszę dodawać ? Jeżeli ktoś korzysta z publicznych proxy to ręcznie będzie ciężko to zrobić.

 

Plik errors z dnia dzisiejszego zawiera już  35tys wierszy i tak każdego dnia.

hmm, ulokuj stronę za CloudFlare w płatnym planie na pewno masz opcję wycinania krajów ewentualnie wytnij korzystając z IpSet kraje typu Chiny Rosja możesz też pokombinować z  http://proxycheck.io/ mają bardzo spoko api do wykrywania proxy tylko tutaj musiałbyś ogarnąć coś ala Proxy do twojej strony.

Edytowane 11 Grudnia 2018 przez #Gremsonkowy#

[Fizyda]

A czemu nie spróbować mod-security? Może to wystarczy i nie trzeba będzie kombinować z CloudFlare.

[Mion]

1 godzinę temu, arve_lek napisał:

Jakieś sugestie czy da się zablokować te ataki ?  ... Ręcznie IP muszę dodawać ?

Taka koncepcja przynajmniej teoretyczna. Jeśli klient wykonuje żądania do nieistniejących zasobów serwer loguje taki request jako 404 + IP klienta.
Wiec dodatkowe oprogramowanie, które co (n) czasu odczytuje (n) linii z loga i jak trafi się (n) 404 z danego IP w określonym czasie takie IP automatycznie trafia na listę banów i firewall  nie dopuszcza kolejnych żądań z tego IP.  Najlepszy był by firewall  przed serwerem do którego za pomocą API szło by IP na bieżąco dodawać.

[devopsiarz]

Można wyciąć firewallem, ale ja bym zmienił apache na nginx, który lepiej radzi sobie z tego typu requestami do istniejących/nieistniejących plików. 

I nie logowałbym wówczas tego.

[Spoofy]

5 godzin temu, devopsiarz napisał:

Można wyciąć firewallem, ale ja bym zmienił apache na nginx, który lepiej radzi sobie z tego typu requestami do istniejących/nieistniejących plików. 

I nie logowałbym wówczas tego.

1) Znów "złota łopata" za wykopalisko na forum
2) Apache też potrafi sobie poradzić z wieloma przypadkami
3) W tym konkretnym przypadku spojrzałbym na UA i na tej podstawie powycinał zbędny ruch
4) Jeżeli w jakikolwiek sposób zajmowałbyś się administracją, wiedziałbyś że nie logowanie czegoś potencjalnie "złego" nie rozwiąże problemu - bo niby jak?

[devopsiarz]

1) Powód jak poprzednio

2) Apache jest słaby w serwowaniu statycznych plików, po coś lighttpd/nginx powstały (nie wspominając np o czymś takim jak varnish), weź sobie zrób prosty benchmark

3) Twoja porada, masz do niej prawo

4) Skądże znowu, warto wołać dodatkowe syscalle do obsługi I/O (buforów w najlepszym razie), wszakże są zawsze za darmo z punktu widzenia zasobów.

 

PS Jak już pieczołowicie moje kompetencje chcesz podważać, choć na priv się wyjaśnimy.

[Spoofy]

9 minut temu, devopsiarz napisał:

1) Powód jak poprzednio

2) Apache jest słaby w serwowaniu statycznych plików, po coś lighttpd/nginx powstały (nie wspominając np o czymś takim jak varnish), weź sobie zrób prosty benchmark

3) Twoja porada, masz do niej prawo

 4) Skądże znowu, warto wołać dodatkowe syscalle do obsługi I/O (buforów w najlepszym razie), wszakże są zawsze za darmo z punktu widzenia zasobów.

  

PS Jak już pieczołowicie moje kompetencje chcesz podważać, choć na priv się wyjaśnimy.

Ad.2) zbyt dużo benchmarków robiłem w swoim życiu i uwierz mi że znam większość web serwerów i ich możliwości. W przypadku autora wątku, domyślam się że jedną z kluczowych kwestii będzie obsługa regułek rewrite. Jeżeli już odsyłasz do benchmarków, polecam również zbadać te, odnośnie varnish'a względem wspomnianego nginx'a, który powstał właśnie przede wszystkim jako proxy
Ad.4) W przypadku podobnych request'ów, load i oranie zasobów będzie większe przy ich obsłudze niż przy ich zalogowaniu, zaś z punktu widzenia bezpieczeństwa, jest to tylko kamuflowanie tematu który dalej istnieje.

Wypowiedziałeś się publicznie, więc publicznie odpowiadam. Nie mam zamiaru "się wyjaśniać", zaś takim sformułowaniem jestem mocno zniesmaczony, zatem podaruję sobie i Tobie dalszych wywodów w tym temacie.

[devopsiarz]

Ad.2 -> jesteśmy w internecie, zawsze możesz sypnąć dowodem, chyba znasz jakieś poza "znam większość web serverów"? 

 

Ad.4 -> mógłbym się kłócić, bo swoje doświadczenie mam. Moja opinia: przy tym ruchu nie logujemy tego, chyba, że nas load=100, przy 4 vCPU satysfakcjonuje i to, że będziemy wiedzieć, że ktoś odpytuje nasze pliki. Syscalle I/O są kosztowne, a tu nawet nie wiadomo czy on cachuje te logi, czy lecą per request. No ale ja mam doświadczenie za skali rzędu 100 000 tps (tak, requestów na sekundę), więc może przesadzam.

[Archi]

8 godzin temu, devopsiarz napisał:

Ad.2 -> jesteśmy w internecie, zawsze możesz sypnąć dowodem, chyba znasz jakieś poza "znam większość web serverów"? 

 

Ad.4 -> mógłbym się kłócić, bo swoje doświadczenie mam. Moja opinia: przy tym ruchu nie logujemy tego, chyba, że nas load=100, przy 4 vCPU satysfakcjonuje i to, że będziemy wiedzieć, że ktoś odpytuje nasze pliki. Syscalle I/O są kosztowne, a tu nawet nie wiadomo czy on cachuje te logi, czy lecą per request. No ale ja mam doświadczenie za skali rzędu 100 000 tps (tak, requestów na sekundę), więc może przesadzam.

 

Logi mogą być buforowane pomiędzy write'ami (parametry buffer, open_log_file_cache), CPU ani wątków na I/O nie zużywasz, bo jest to operacja asynchroniczna. Jeśli twoim bottleneckiem jest logowanie zapytań to spierdzieliłeś konfigurację (a raczej w ogóle nie przeczytałeś dokumentacji) i optymalizujesz problem, który nie istnieje.

 

Jakiś czas temu robiłem benchmarki do 500k requestów na sekundę statyki z włączonym logowaniem, bo akurat sam testowałem faktyczny overhead i conditional logging, i nie jestem w stanie potwierdzić tego co mówisz, tak więc jeśli masz jakieś merytoryczne wskazówki odnośnie tego co robię źle, to z miłą chęcią posłucham.

 

A logi nie przydają się tylko jako moduł rate-limitingu, anti-bruteforce czy wykrywania zagrożeń, jest to również najlepsze źródło statystyk odwiedzin, popularnych podstron i informacji o userach, w szczególności dzisiaj gdy połowa adblocków wycina śmieciowe analytics z miejsca. Jeśli uważasz to za coś zbędnego to prawdopodobnie nigdy nie wykorzystałeś ich potencjału .

Edytowane 25 Lipca 2019 przez Archi

[devopsiarz]

6 godzin temu, Archi napisał:

 

Logi mogą być buforowane pomiędzy write'ami (parametry buffer, open_log_file_cache),

CPU ani wątków na I/O nie zużywasz, bo jest to operacja asynchroniczna. Jeśli twoim bottleneckiem jest logowanie zapytań to spierdzieliłeś konfigurację (a raczej w ogóle nie przeczytałeś dokumentacji) i optymalizujesz problem, który nie istnieje.

 

Napisałem, że tu nie wiem czy są buforowane. Ponadto, podajesz parametry, które nie robią tego samego i wrzucasz je do jednego worka, nie wiem czy jesteś świadomy co podałeś, ale skonsultuj to z dokumentacją nginx, bo nawet ona explicite mówi jaki jest koszt logów.

A to, czy CPU, czy I/O nie zużywasz i jaki to typ operacji, to zależy od webservera, jego konfiguracji i wreszcie konfiguracji systemu (i piszę Ci to m.in. programista, który grzebie w jednym ze znanych webserwerów).

 

 

6 godzin temu, Archi napisał:

Jakiś czas temu robiłem benchmarki do 500k requestów na sekundę statyki z włączonym logowaniem, bo akurat sam testowałem faktyczny overhead i conditional logging, i nie jestem w stanie potwierdzić tego co mówisz, tak więc jeśli masz jakieś merytoryczne wskazówki odnośnie tego co robię źle, to z miłą chęcią posłucham.

 

To się podziel detalami np. w czym logowałeś (apka), co logowałeś, jaki był faktycznie traffic, jaka była konfiguracja software (OS), hardware. Jako osoba, która zarabia na optymalizacji, chętnie się czegoś nowego nauczę. Bo wiesz, z mojego doświadczenia, z tpsami o którym wspomniałem + tego co znajdziesz w sieci na ten temat, jest właśnie odwrotnie. Ale jestem otwarty na dyskusje.

 

6 godzin temu, Archi napisał:

 

A logi nie przydają się tylko jako moduł rate-limitingu, anti-bruteforce czy wykrywania zagrożeń, jest to również najlepsze źródło statystyk odwiedzin, popularnych podstron i informacji o userach, w szczególności dzisiaj gdy połowa adblocków wycina śmieciowe analytics z miejsca. Jeśli uważasz to za coś zbędnego to prawdopodobnie nigdy nie wykorzystałeś ich potencjału .

 

Ja oczywiście się zgadzam z tym stwierdzeniem, nie deprecjonuję logów jako ich samych. Tylko spójrz z czym problem miał OP, a takie scenariusze wielokrotnie miałem do ogarnięcia. Wystarczył zazwyczaj apache/jmeter/siege benchmark z kilku serwerów i serwer zdychał, bo sprawdzał istnienie każdego dziwnego pliku (lub w gorszej sytuacji nie sprawdzał a od razu proksował po regule *.php do php-fpm).

 

Wyłączenie logów w pewnym sensie na szybko pomaga do pewnego stopnia. Bo czasem musimy zdecydować, czy chcemy dostać się do serwera i mieć szansę serwować 1 request na 10 sec, czy chcemy mieć piękne logi, które właśnie, w najlepszym przypadku, są zrzucane do pliku już bo buffor (jak go w ogóle włączono) się zapełnił i przez 5 minut serwer oleje wszystko co chcemy na nim zrobić. Kwestia priorytetów, podałem jedno z możliwych rozwiązań na szybko. Zresztą, nawet OP sam przyznaje, że restart apache na parę dni załatwia problem - to też może potwierdzać moją tezę (pootwierane deskryptory m.in do logów itp)

 

Pozdrawiam,

Edytowane 26 Lipca 2019 przez devopsiarz