Zabezpieczenia aplikacji na serwerze

[theqkash]

Hej, czy uważacie że WAF jest dobrym rozwiązaniem do zabezpieczenia aplikacji na serwerze, czy może zalecacie lepsze rozwiązanie?

 

Jeśli WAF, to jaki?

[devopsiarz]

Nie napisałeś nic o typie aplikacji, czym jest, co robi. Czasem może to mieć sens, czasem nie, wszystko zależy od wielu czynników.

Edytowane 3 Września 2019 przez devopsiarz

[theqkash]

U siebie hostuję głównie wordpressy, nie mam natomiast doświadczenia z WAFami i nie wiem które z rozwiązań jest warte uwagi. 

[devopsiarz]

Według mnie nie ma sensu, mówię tutaj zwłaszcza o Wordpressowych dodatkach, które za takiego "protektora" robią. Lepsze i bezpieczniejsze są odpowiednie reguły na poziomie serwera httpd (.htaccess i ekwiwalenty na innych serwerach). Dodatkowo na poziomie samego serwera, warto mieć usługę typu `fail2ban`, która analizując logi np. www podejmie decyzję czy jakieś IPeki nie wyciąć w ogóle na poziomie całego serwera. Taka jest moja opinia.

[theqkash]

Miałem tu na myśli WAF taki jak proponują niektórzy dostawcy usług hostingowych

[devopsiarz]

No to tylko oni to wiedzą, co tu u nich tak naprawdę oznacza

[Spoofy]

A oznacza to tyle, że bardziej pasuje to do regułki: Web Application Firewall niż anty-bruteforce Fail2ban który nim nie jest ;)

 

Nie oznacza to jednak, że mamy sprecyzowane co rzeczywiście chcemy osiągnąć w takim przypadku - tak samo jak w przypadku IDS'ów ;)

W DUŻYM uproszczeniu możemy podzielić takie rozwiązania na trzy kategorie:
- Sprzętowe rozwiązania - gotowe produkty np. Fortigate'a
- Software'owe
- Proxy/L7

Powiedzmy że skupimy sie na standardowym modsec'u i OWASP'owych regułkach - te mają zbyt dużo false positive'ów i dostosowanie tego niestety wymaga czasu. Są alternatywy, takie jak np. CWAF (Comodo WAF) - tutaj sprawa wygląda znacznie lepiej. Warte polecenia, są również regułki Atomi Corp'a - też mało false positive'ów. W przypadku Imunify360 - nie powiem za dużo, ale wydaje się całkiem przystępnym rozwiązaniem (z resztą jak wszystko od CloudLinucha ;) ).

Jeżeli jednak masz zamiar rozpatrywać WAF'a jako ochronę sieciową, tzn. np. proxy L7 to tutaj też mamy całą masę rozwiązań. Prawdopodobnie Panu @devopsiarz w przypadku .htaccess'a - czyli regułek rewrite, w przypadku WordPress'a chodziło o blokowanie/limitowanie niechlubnego xmlrpc - takie rzeczy oczywiście można zablokować na każdym serwerze, nie tylko regułkami rewrite (np. Nginx'em).

Czy warto? IMHO każde rozwiązanie zwiększające świadomość zagrożeń oraz bezpieczeństwo - warto stosować. Z wymienionych, polecałbym na początek CWAF'a ;)

P.S. Dodatki do skryptu, czyli wykonywalnego już PHP - po tej stronie nie zdziałają za wiele, także "dodatki" do samego WordPress'a nie podlegają pod definicję WAF.

[devopsiarz]

8 minut temu, Spoofy napisał:

A oznacza to tyle, że bardziej pasuje to do regułki: Web Application Firewall niż anty-bruteforce Fail2ban który nim nie jest

 

Tzn, co dokładnie? Jakie konkretne rozwiązanie? I jak działające, bo, że hosting powie A, to nie znaczy, że to działa jak A. Natomiast fail2ban może Ci wsadzać bloki do serwera www na podstawie logów i jak najbardziej spełnia definicję WAF, mówię oczywiście o standardowym, najbardziej znanym fail2ban.

 

8 minut temu, Spoofy napisał:

- Sprzętowe rozwiązania - gotowe produkty np. Fortigate'a
- Software'owe

 

Obydwa to rozwiązania programowe, ale to pierwsze jest w fancy obudowie, za fancy cenę. Każde jest softwarowe.

 

Edytowane 4 Września 2019 przez devopsiarz

[Spoofy]

5 minut temu, devopsiarz napisał:

Tzn, co dokładnie? Jakie konkretne rozwiązanie? I jak działające, bo, że hosting powie A, to nie znaczy, że to działa jak A. Natomiast fail2ban może Ci wsadzać bloki do serwera www na podstawie logów i jak najbardziej spełnia definicję WAF, mówię oczywiście o standardowym, najbardziej znanym fail2ban.

 

 

Fail2ban = anty bruteforce (swoją drogą, parser python'a, który nie jest aż tak wydajny jak np. perl'owy LFD  ) to NIE jest WAF.
 

Podałem przykład - imunify360 - zestaw regułek do modsec'a

 

7 minut temu, devopsiarz napisał:

Obydwa to rozwiązania programowanie, ale to pierwsze jest w fancy obudowie, za fancy cenę. Każde jest softwarowe.

Także napisałem że w "DUŻYM" uproszczeniu, zaś kwestia sprzętowa w tym przypadku ma znaczenie - jak dużo request'ów jest w stanie przyjąć i wyfiltrować - inaczej takie rozwiązania nie miałby racji bytu. Polecam poczytać w/w produkt Fortigate'a - Fortiweb: https://www.fortinet.com/products/web-application-firewall/fortiweb.html

[devopsiarz]

4 minuty temu, Spoofy napisał:

 

Fail2ban = anty bruteforce (swoją drogą, parser python'a, który nie jest aż tak wydajny jak np. perl'owy LFD  ) to NIE jest WAF.
 

Podałem przykład - imunify360 - zestaw regułek do modsec'a

 

Oczywiście, że jest. Fakt, z antybruteforce jest najbardziej znany, co nie oznacza, że nie można nim monitorować np. niedozwolonych metod HTTP dla dla np. group adresów IP. Jak najbardziej w tej sytuacji jest to WAF.

 

4 minuty temu, Spoofy napisał:

Także napisałem że w "DUŻYM" uproszczeniu, zaś kwestia sprzętowa w tym przypadku ma znaczenie - jak dużo request'ów jest w stanie przyjąć i wyfiltrować - inaczej takie rozwiązania nie miałby racji bytu. Polecam poczytać w/w produkt Fortigate'a - Fortiweb: https://www.fortinet.com/products/web-application-firewall/fortiweb.html

 

Zrzucałem kiedyś (nie wiem na ile to było legalne przyznam szczerze, ale była potrzeba) OS Fortigate. To zwykły linux 2.2.* był. Zaś same te "naleśniki" mają zazwyczaj wydajność PC kilku lat wstecz. To nie są magiczne puszki, to zwykłe PCty w dziwnych obudowach z wieloma interfejsami sieciowymi, wsparciem oraz fajnym interfejsem i za to się właśnie płaci.  Nikt nie pisze OSa od podstaw czy stosu TCP/IP od podstaw pod takie zastosowania, bo to są ciężkie rzeczy, na które stać tylko największych typu MS/Apple/etc.

[Spoofy]

2 minuty temu, devopsiarz napisał:

 

Oczywiście, że jest. Fakt, z antybruteforce jest najbardziej znany, co nie oznacza, że nie można nim monitorować np. niedozwolonych metod HTTP dla dla np. group adresów IP. Jak najbardziej w tej sytuacji jest to WAF.

 

 

Zrzucałem kiedyś (nie wiem na ile to było legalne przyznam szczerze, ale była potrzeba) OS Fortigate. To zwykły linux 2.2.* był. Zaś same te "naleśniki" mają zazwyczaj wydajność PC kilku lat wstecz. To nie są magiczne puszki, to zwykłe PCty w dziwnych obudowach z wieloma interfejsami sieciowymi, wsparciem oraz fajnym interfejsem i za to się właśnie płaci.  Nikt nie pisze OSa od podstaw czy stosu TCP/IP od podstaw pod takie zastosowania, bo to są ciężkie rzeczy, na które stać tylko największych typu MS/Apple/etc.

No niestety, ale podstawowy, prosty parser logów, fukcjonujący jako anty-bruteforce  nie może być nazwany WAF'em. Odsyłam do definicji: https://sekurak.pl/czym-jest-web-application-firewall-czesc-pierwsza-na-przykladzie-naxsi/

W kwestii fortigate'a - sprawdzałeś może kiedyś moduły takiego kernela albo jego konfigurację? Sądzę że mógłbyś się mocno zdziwić, zaś benchmarki wydajnościowe również mówią same za siebie. W początkach działalności, można by nawet pokuśić się o takie stwierdzenie, że jest to "zwykły PC", aczkolwiek po coś są to komponenty dobierane i produkowane pod konkretną konfigurację  Jeżeli zraziłeś się do Fortigate'a, to masz jeszcze całą masę innych rozwiązań - Sonicwall'e, Juniper'y etc.

[devopsiarz]

4 minuty temu, Spoofy napisał:

No niestety, ale podstawowy, prosty parser logów, fukcjonujący jako anty-bruteforce  nie może być nazwany WAF'em. Odsyłam do definicji: https://sekurak.pl/czym-jest-web-application-firewall-czesc-pierwsza-na-przykladzie-naxsi/

 

Na mój gust: https://www.owasp.org/index.php/Web_Application_Firewall + https://en.wikipedia.org/wiki/Application_firewall - jak najbardziej spełnia te definicje, to, że nie jest proxy, to nic jeszcze nie znaczy.

 

4 minuty temu, Spoofy napisał:

 

W kwestii fortigate'a - sprawdzałeś może kiedyś moduły takiego kernela albo jego konfigurację? Sądzę że mógłbyś się mocno zdziwić, zaś benchmarki wydajnościowe również mówią same za siebie. W początkach działalności, można by nawet pokuśić się o takie stwierdzenie, że jest to "zwykły PC", aczkolwiek po coś są to komponenty dobierane i produkowane pod konkretną konfigurację  Jeżeli zraziłeś się do Fortigate'a, to masz jeszcze całą masę innych rozwiązań - Sonicwall'e, Juniper'y etc.

 

Nie, nie sprawdzałem wtedy. Co by zmieniło niby? Jeżeli masz tą samą architekture CPU, zbliżony chip sieciowy, to PC z lepszym CPU będzie wydajniejsze w obsłudze sieci. Proste. Wtedy jak ja to robiłem, było to wielokrotnie słabsze urządzenie od "zwyczajnego" PC, sam ram był na poziomie 32 czy coś. Stos sieciowy jest ustandaryzowany, inaczej inne routery nie rozmawiały by z czymś customowym. Zatem podtrzymuję opinię: to są rozwiązania software w ładnych obudowach. Żadnej innej przewagi nad custom PC z jakąś porządną sieciówką (2 lub 4x) nie mają, w sensie wydajności czy czegoś. Nawet nie wiem czy są bezpieczniejsze, bo raz za czas słyszy się o jakichś "furtkach" administracyjnych.

 

PS Juniper też, o ile pamiętam on z kolei był oparty o FreeBSD, bo go CVE niektóre nawet tyczyły i szły o tym informacje. Czyli podsumowując: stawiając FreeBSD na zbliżonej klasy interfejsie sieciowym, ale lepszym CPU, dostaniesz w kompie "cywilnym" wyższą wydajność takiego rozwiązania, zakładając, że infrastruktura Ci go obsłuży.

 

Generalnie nie mam nic przeciwko tym urządzeniom, jak kto woli, choć kosztują mnóstwo siana i błędnie się przyjęło, że to są jakieś rozwiązania "sprzętowe", a przez to lepsze. Dla klientów cywilnych, co chcą jedynie klikać (lub nawet nie), są to dobre rzeczy, bo płacisz i zapominasz o "problemie". I to tyle.

[Spoofy]

5 minut temu, devopsiarz napisał:

Na mój gust: https://www.owasp.org/index.php/Web_Application_Firewall + https://en.wikipedia.org/wiki/Application_firewall - jak najbardziej spełnia te definicje, to, że nie jest proxy, to nic jeszcze nie znaczy.

Eh, nie mam siły się sprzeczać. Podajesz definicję owasp'a - w takim układzie podaj mi przykład wykrywania XSS'a na podstawie logów, stwórz taką regułkę i zmierz wydajność. Dodatkowo, porównaj z innymi rozwiązaniami. Jeżeli podajesz przykład z wiki, czym jest application firewall, to już Ci odpowiadam - jak chcesz BRONIĆ, na podstawie logów serwera www? Gdzie tutaj jest prewencja, hm? Jedynie taka, żeby ktoś nie wykonał danego request'a ponownie - także to nawet nie wpasowywuje się w taką, podaną przez Ciebie regułkę.
 

 

8 minut temu, devopsiarz napisał:

Nie, nie sprawdzałem wtedy. Co by zmieniło niby? Jeżeli masz tą samą architekture CPU, zbliżony chip sieciowy, to PC z lepszym CPU będzie wydajniejsze w obsłudze sieci. Proste. Wtedy jak ja to robiłem, było to wielokrotnie słabsze urządzenie od "zwyczajnego" PC, sam ram był na poziomie 32 czy coś. Stos sieciowy jest ustandaryzowany, inaczej inne routery nie rozmawiały by z czymś customowym. Zatem podtrzymuję opinię: to są rozwiązania software w ładnych obudowach. Żadnej innej przewagi nad custom PC z jakąś porządną sieciówką (2 lub 4x) nie mają, w sensie wydajności czy czegoś. Nawet nie wiem czy są bezpieczniejsze, bo raz za czas słyszy się o jakichś "furtkach" administracyjnych.

 

PS Juniper też, o ile pamiętam on z kolei był oparty o FreeBSD, bo go CVE niektóre nawet tyczyły i szły o tym informacje. Czyli podsumowując: stawiając FreeBSD na zbliżonej klasy interfejsie sieciowym, ale lepszym CPU, dostaniesz w kompie "cywilnym" wyższą wydajność takiego rozwiązania, zakładając, że infrastruktura Ci go obsłuży.

Jeżeli twierdzisz że zwykły PC jest "wydajniejszy", "bezpieczniejszy" i "lepszy" jako np. WAF, to polecam zakupić takie urządzenie i chwilkę się nim pobawić przy realnym use-case. Podatności czy CVE, zarówno na JuniOS'a czy FortiOS'a są znane, ale nie zmienia to faktu do czego są one wykorzystywane. Spójrz proszę na realne przykłady.

 

11 minut temu, devopsiarz napisał:

 

Generalnie nie mam nic przeciwko tym urządzeniom, jak kto woli, choć kosztują mnóstwo siana i błędnie się przyjęło, że to są jakieś rozwiązania "sprzętowe", a przez to lepsze. Dla klientów cywilnych, co chcą jedynie klikać (lub nawet nie), są to dobre rzeczy, bo płacisz i zapominasz o "problemie". I to tyle.

Tym twierdzeniem zakończę dyskusję z mojej strony w tym temacie

[devopsiarz]

3 minuty temu, Spoofy napisał:

Eh, nie mam siły się sprzeczać. Podajesz definicję owasp'a - w takim układzie podaj mi przykład wykrywania XSS'a na podstawie logów, stwórz taką regułkę i zmierz wydajność. Dodatkowo, porównaj z innymi rozwiązaniami. Jeżeli podajesz przykład z wiki, czym jest application firewall, to już Ci odpowiadam - jak chcesz BRONIĆ, na podstawie logów serwera www? Gdzie tutaj jest prewencja, hm? Jedynie taka, żeby ktoś nie wykonał danego request'a ponownie - także to nawet nie wpasowywuje się w taką, podaną przez Ciebie regułkę.

 

Uwaga, podaję Ci to na talerzu: z Wiki OWASP masz: `A web application firewall (WAF) is an application firewall for HTTP applications. It applies a set of rules to an HTTP conversation`

Z wiki normalnej masz: `An application firewall is a form of firewall that controls input, output, and/or access from, to, or by an application or service. It operates by monitoring and potentially blocking the input, output, or system service calls that do not meet the configured policy of the firewall` 

 

Wszystko to pierwsze zdania. Sam Ci wyłuściłem. Więc chyba zasad podstawowej logiki nie muszę wyjaśniać, że fail2ban spełnia tą definicję. Robi to na swój sposób, nie jak klasyczny fw, ale to spełnia. Wszystkiego nie obsługuje, ale definicje spełnia.  Chyba oczywiste? To, że Ty masz w pamięci coś ala mod_security, to nie oznacza, że to, jak działa mod_security od razu staje się to definicją. Więc szukaj dalej.

 

3 minuty temu, Spoofy napisał:

Jeżeli twierdzisz że zwykły PC jest "wydajniejszy", "bezpieczniejszy" i "lepszy" jako np. WAF, to polecam zakupić takie urządzenie i chwilkę się nim pobawić przy realnym use-case. Podatności czy CVE, zarówno na JuniOS'a czy FortiOS'a są znane, ale nie zmienia to faktu do czego są one wykorzystywane. Spójrz proszę na realne przykłady.

 

Lubisz wyrywać z kontekstu widzę. Ja Ci napisałem warunki, przy których jest wydajniejszy. Jak nie potrafisz interpretować moich wypowiedzi, to Twój problem (to co tu zinterpretowałeś)

I w ogóle czemu ja dyskutuję argumentami rzeczowymi, a Ty broszurkami reklamowymi? Bo w takiej dyskusji to ja nie mam szans, logika vs marketing.

 

 

[#Gremsonkowy#]

22 minuty temu, devopsiarz napisał:

 

Uwaga, podaję Ci to na talerzu: z Wiki OWASP masz: `A web application firewall (WAF) is an application firewall for HTTP applications. It applies a set of rules to an HTTP conversation`

Z wiki normalnej masz: `An application firewall is a form of firewall that controls input, output, and/or access from, to, or by an application or service. It operates by monitoring and potentially blocking the input, output, or system service calls that do not meet the configured policy of the firewall` 

 

Wszystko to pierwsze zdania. Sam Ci wyłuściłem. Więc chyba zasad podstawowej logiki nie muszę wyjaśniać, że fail2ban spełnia tą definicję. Robi to na swój sposób, nie jak klasyczny fw, ale to spełnia. Wszystkiego nie obsługuje, ale definicje spełnia.  Chyba oczywiste? To, że Ty masz w pamięci coś ala mod_security, to nie oznacza, że to, jak działa mod_security od razu staje się to definicją. Więc szukaj dalej.

 

 

Lubisz wyrywać z kontekstu widzę. Ja Ci napisałem warunki, przy których jest wydajniejszy. Jak nie potrafisz interpretować moich wypowiedzi, to Twój problem (to co tu zinterpretowałeś)

I w ogóle czemu ja dyskutuję argumentami rzeczowymi, a Ty broszurkami reklamowymi? Bo w takiej dyskusji to ja nie mam szans, logika vs marketing.

 

 

Fail2ban nigdy nie był i nie będzie WAFem i to spełnianie przez niego założeń definicji jest również bardzo naciągne choćby przytoczmy pierwszy zacytowany przez ciebie fragment definicji "It applies a set of rules to an HTTP conversation" więc czy fail2ban pozwala nam na stworzenie konkretnej reguły do blokady tylko 1 konkretnego urla/requesta a nie ogranicza się tylko do blokady na poziomie IP? Nie! Co jednoznacznie kłóci się z powyższą definicją jako iż zakłada ona stosowanie ACLek tylko w obrębie samej komunikacji HTTP. 

 

 

"An application firewall is a form of firewall that controls input, output, and/or access from, to, or by an application or service. It operates by monitoring and potentially blocking the input, output, or system service calls that do not meet the configured policy of the firewall"

 

Tutaj natomiast fail2ban nie wypełnia w 100% definicji jako iż pozwala on jedynie na kontrolę inputu która w normalnym użyciu nie ma sensu jako iż raz zadziała z opóźnieniem (użytkownik dostanie response) a dwa owe narzędzie poza logami nie ma żadnych innych sensownych możliwość analizowania i reagowania na potencjalne nieprawidłowe requesty.

[devopsiarz]

11 minut temu, #Gremsonkowy# napisał:

"It applies a set of rules to an HTTP conversation"

 

Czyli np. jak aplikuje reguły do .htaccess, to mieści się to w tej definicji, bo wpływa na komunikację HTTP.

 

11 minut temu, #Gremsonkowy# napisał:

więc czy fail2ban pozwala nam na stworzenie konkretnej reguły do blokady tylko 1 konkretnego urla/requesta a nie ogranicza się tylko do blokady na poziomie IP?

Nie! Co jednoznacznie kłóci się z powyższą definicją jako iż zakłada ona stosowanie ACLek tylko w obrębie samej komunikacji HTTP. 

 

Znaczy się, wszedłeś w wątek, nie wiedząc, co można robić fail2ban, tak mam rozumieć powyższą wypowiedź?

 

11 minut temu, #Gremsonkowy# napisał:

 

"An application firewall is a form of firewall that controls input, output, and/or access from, to, or by an application or service. It operates by monitoring and potentially blocking the input, output, or system service calls that do not meet the configured policy of the firewall"

 

Tutaj natomiast fail2ban nie wypełnia w 100% definicji jako iż pozwala on jedynie na kontrolę inputu która w normalnym użyciu nie ma sensu jako iż raz zadziała z opóźnieniem (użytkownik dostanie response) a dwa owe narzędzie poza logami nie ma żadnych innych sensownych możliwość analizowania i reagowania na potencjalne nieprawidłowe requesty.

 

Tu zgoda, 100% nie spełnia, bo outputu nie monitoruje. Natomiast to, jak on się sprawdza, zależy od jego konfiguracji i założeń. Jak chcesz zmapować możliwości 1:1 do modsecurity, to nie będzie miał takich możliwości, to oczywiste. Natomiast nie zgodzę się, co do twierdzenia "narzędzie poza logami nie ma żadnych innych sensownych możliwość analizowania i reagowania na potencjalne nieprawidłowe requesty." - nie wiesz czy zdajesz sobie sprawę, ale w logach serwera http można umieścić cały payload (request i response). Więc to, jakie możliwości dasz f2b w stosunku do Twojego serwera, zależy od Ciebie, zresztą w przypadku modsecurity też.

[Spoofy]

Takie wywody na forach, w moim przekonaniu w tym miejscu dalej zmierzają do offtop'u. Zarzucasz mi brak konkretów, także zacznę może od (pseudo)analizy Twojej wypowiedzi:
 

2 godziny temu, devopsiarz napisał:

Uwaga, podaję Ci to na talerzu: z Wiki OWASP masz: `A web application firewall (WAF) is an application firewall for HTTP applications. It applies a set of rules to an HTTP conversation`

Z Twojego "talerza", można wywnioskować, że zbój o którym tutaj mowa, tyczy się ruchu webowego. Cóż, wikipedia nie jest dla mnie źródłem oczywistym, natomiast (niby) podręcznikową i dokładniejszą definicję znajdziemy w innych jej zasobach: https://en.wikipedia.org/wiki/Web_application_firewall - tutaj już uściślone jest, że tyczy się to konkretnie ruchu za pomocą protokołu HTTP i WAF jest czymś innym niż zwykły firewall i dla przykładu chroni przed popularnymi atakami Sqli, xss, czy fi. Podałem już przykład krótszej, dokładniejszej definicji, także nie będę Ci jej "wytłuszczać".

 

2 godziny temu, devopsiarz napisał:

Z wiki normalnej masz: `An application firewall is a form of firewall that controls input, output, and/or access from, to, or by an application or service. It operates by monitoring and potentially blocking the input, output, or system service calls that do not meet the configured policy of the firewall` 

widzisz, ta "normalna" wiki opisuje metodę działania ochrony aplikacyjnej. Zadałbym Ci pytanie - w jaki sposób chciałbyś blokować "potencjalnie" czy prewencyjnie zły ruch za pomocą fail2bana przy aplikacji webowej, ale domyślam się, że będę źle zrozumiany i zbyt ofensywny w stosunku do Ciebie. Na owej stronie przeczytamy również o innych sposobach "ochrony" aplikacji systemowych (o których również mógłbym chętnie porozmawiać). Język angielski chyba jest dla Ciebie zrozumiały, tak więc pozwól że w tym momencie skupimy się na tym, czym jest WAF, gdyż o tego zbója się tu rozchodzi

 

2 godziny temu, devopsiarz napisał:

Wszystko to pierwsze zdania. Sam Ci wyłuściłem. Więc chyba zasad podstawowej logiki nie muszę wyjaśniać, że fail2ban spełnia tą definicję.

dziękuję za /b/wytłuszczenie, lecz właśnie wykazałem, że logicznie tak nie jest.
 

 

2 godziny temu, devopsiarz napisał:

Robi to na swój sposób, nie jak klasyczny fw, ale to spełnia.

przybliż mi zasadę działania samego fail2ban'a - czy przypadkiem nie jest to parser logów serwera webowego, który wykonuje daną czynnośc, najczęściej dodanie do netfilter'a regułki blokującej? Zapytałbym, co w praktyce powinniśmy logować w takim logu, jak dużo, jak będzie działać parser python'a, jak szybko da rezultat w przypadku np. dużego ruchu, ale skupmy się na tej (niby) podręcznikowej definicji, a nie (where am I?!) praktyce.
 

2 godziny temu, devopsiarz napisał:

To, że Ty masz w pamięci coś ala mod_security, to nie oznacza, że to, jak działa mod_security od razu staje się to definicją.

w mojej głowie(sajko!) są różne(sic!) realne przykłady i nie tylko "coś ala modsec" wyznacza owe określenie.

 

2 godziny temu, devopsiarz napisał:

Zrzucałem kiedyś (nie wiem na ile to było legalne przyznam szczerze, ale była potrzeba) OS Fortigate. To zwykły linux 2.2.* był.

pamiętam czasy tego kernela (hehe ), także pozwól że podzielę się z Tobą tą nostalgią...

Wyobraź sobie czasy, gdzie floppy disk, taki 3,5' był jak pendrive. W tamtych czasach, liczyła się jakość kodu, nawet tak prostych programów, które możnaby zmieścić poniżej 1,5 MB.  Takich zbójów, co mają robić tylko jedno, nie przejmować się niczym inmym i dla przykładu - robić to dobrze. Pamiętam również czasy nocnych kompilacji, tak więc potrafię docenić jakość danego oprogramowania jak i rozwiązania, również tego komercyjnego.
 

 

2 godziny temu, devopsiarz napisał:

Więc szukaj dalej.

widzisz, mam wrażenie że ja już znalazłem to, czego Ty nadal szukasz

 

2 godziny temu, devopsiarz napisał:

Lubisz wyrywać z kontekstu widzę.

Panie @devopsiarz, taki nickname powinien do czegoś zobowiązywać - szybka analiza, filtrowanie oraz wyciąganie wniosków nie powinno być Ci obce, nawet w sytuacjach stresowych, prawda?

Nie, ja nie "wyrywam" niczego, ja "podaję" tylko lepiej, szybciej i dokładniej
 

 

2 godziny temu, devopsiarz napisał:

Ja Ci napisałem warunki, przy których jest wydajniejszy.

czyli mówisz, że zwykły PC, będzie wydajniejszy to chciałbym zobaczyć realny przykład (w konkretnej skali) jaki Ty masz w głowie. Czy mógłbyś się takim podzielić, hm?

 

2 godziny temu, devopsiarz napisał:

Jak nie potrafisz interpretować moich wypowiedzi, to Twój problem (to co tu zinterpretowałeś)

Analyze error: buffer overflow, kernel panic!?!!
 

 

2 godziny temu, devopsiarz napisał:

I w ogóle czemu ja dyskutuję argumentami rzeczowymi, a Ty broszurkami reklamowymi? Bo w takiej dyskusji to ja nie mam szans, logika vs marketing.

ja rozumiem, full Stallman, GNU(slash!)/Linux, wszyscy korzystamy z dobrodziejstw ludzkości, ale jeżeli jesteś w stanie "zbudować" rozwiązanie tak kompleksowe, dać mi takie wsparcie w takiej cenie, to Panie @devopsiarz - nie wiem ile tych hostów tam devopsujesz, ale sądzę, że poległbyś w przebiegach

 

Kończąc tą pseudo-analizę, dalej sądzę że wcześniejsza próba urwania tematu była słuszna i dalsze dyskutowanie o podręcznikowej czy praktycznej definicji słowa WAF, względem np. fail2ban'a, jest tylko offtopem.
 

Być może Panie @devopsiarz chciałbyś usłyszeć konkret, lecz wybacz, ale nie jest to miejsce pod tytułem "niedzielna szkółka Spoofiego" i nie prowadzę tego rodzaju konsultacji

Zawsze możemy porozmawiać, tak jak już to robiliśmy, na naszym Discordzie,do czego zachęcam przy okazji czytających ten wątek.

Jeżeli zaś chciałbyś w praktyce dowiedzieć się, jak ja rozumiem definicję WAF'a i jak powinien on działać, serdecznie zachęcam do skorzystania z moich usług administracyjnych czy hostingowych - być może usługa hostingu www, wraz z (np. kilkoma) WAF'ami, przy realnym ruchu byłaby odpowiednia, hm?

 

[Archi]

Ja tylko wspomnę, że F2B nie ogranicza się wyłącznie do anty-bruteforce'a. Nie, nie jest WAFem jak już koledzy napisali wyżej, ale można w nim zrobić sporo dobrego, np. zwracać użytkownikowi 403 tam gdzie nie powinien zaglądać, zliczać je po stronie F2B i banować na poziomie IP. Taki ban na poziomie IP również będzie dużo bardziej efektywny niż ban na poziomie nginxa czy innego apache'a, bo request zostanie odrzucony już w kernelu, a nie eskalowany do usługi. Parsowanie z kolei nie jest aż tak problematyczne, backend w pythonie może nie jest najszybszym rozwiązaniem do tego celu, ale F2B jest dość mocno zoptymalizowany pod tym kątem, a jakby jakimś cudem I/O czytania logów było problematyczne, to zawsze można wrzucić w pamięć typu tmpfs. Nie sądzę, żeby ktoś miał tyle logów, żeby mu CPU nie wyrabiał, już I/O jest mocno naciągane biorąc pod uwagę to, że F2B używa inotify i czyta od konkretnych linijek, a nie całe pliki (podobnie do tail -f), a już na pewno jest to rozwiązanie dużo efektywniejsze niż operowanie na web serverze czy o zgrozo php, ale mniejsza.

 

WAF moim zdaniem na pewno odgrywa rolę w kwestii bezpieczeństwa, ale nie jest aż tak ważny z powodu natury samych aplikacji. Jeśli aplikacja jest dziurawa to się łata aplikację, a nie dorzuca strażników na froncie, którzy upewniają się, że do tych dziur w aplikacji nikt nie wejdzie. Nie mam doświadczenia ani informacji jak bardzo WAF pomaga na ew. 0daye i inne requesty, które rzeczywiście mogą wpłynąć na prawidłowo utrzymywaną aplikację, ale spodziewam się że dość nikłe, podczas gdy na wydajności aplikacji taki WAF odbije się całkowicie, gdzie F2B działający w tle analizujący logi zapisywane przez nginxa nie wpływa w żaden sposób na aktywną część web servera, a jak jakimś cudem I/O byłoby problemem to jak już pisałem wcześniej można je zrobić przez tmpfs i operować na logach w pamięci.

 

IMHO o wiele ważniejsze jest aktualizowanie aplikacji i usług, WAF jest OK jak ktoś nalega, ale nie uważam żeby znacząco podnosił bezpieczeństwo samych aplikacji, w stosunku do kosztu jego wdrożenia i utrzymania. Jest zbyt duża szansa, że WAF nie wyłapie tego co powinien wyłapać, a wszystko to co wyłapuje można w większosci osiągnąć samemu.

Edytowane 4 Września 2019 przez Archi

[Krystek]

A ja do WordPressa polecę dodatek All in One WP Security & Firewall. Od momentu, gdy go zainstalowałem to widzę ile prób dziennie podejmują włamywacze, by dostać się do instalacji WP. Czasami jest to 5 prób dziennie, ale są dni, w których mam kilkanaście prób zalogowania się do panelu admina w ciągu godziny (od 27 czerwca 2019 do dzisiaj log pokazuje ponad 1800 prób logowania się do admina) - log bieżący, z dzisiejszej doby pokazuje 17 prób zalogowania się. Dodatek jest bardzo mocno konfigurowalny - da się w nim ustawić praktycznie wszystko, co jest związane z bezpieczeństwem WP i akcje, jakie WordPress ma podjąć w momencie wykrycia naruszenia reguł bezpieczeństwa. Taki dodatek przydaje się, bo o ile na serwerze mamy ograniczone możliwości konfiguracji zabezpieczeń (chyba, że ktoś korzysta z VPS-a albo własnej maszyny) to z tym dodatkiem możemy skutecznie poprawić braki czystej instalacji WordPressa.

[sempre]

Generalnie jeżeli chodzi o wordpressa to największym niebezpieczeństwem nie są ddosy, słabo zoptymalizowany kod  który katuje procka albo możliwość bruteforcowania wp-admina bo to idzie łatwo zabezpieczyć, problemem są sami klienci, którzy świadomie i z pełną premedytacją instalują znulledowane wtyczki/szablony, wtyczki tego typu z reguły są naszpikowane wykonywalnym kodem (co sprytniejsze strony które udostępniają nulled wtyczki nauczyły się już wstrzykiwać  zakodowane malware do obrazków, wychwycenie tego to naprawdę syzyfowa praca), jedne potrafią całkowicie przejąć kontrole nad wp-adminem, inne stosują malware typowo pod SEO, czyli linkowanie do wątpliwej jakości domen w celu podniesienia ich DA. Na podstawie moich dotychczasowych doświadczeń typowo pod wordpressa mogę polecić soft od imunify, bardzo dobrze się sprawdza, jeżeli shared hosting to w smarthosćie mają dobrze przygotowany i aktualizowany system anty exploitowy i nieraz wyłapał wśród moich klientów exploity w pluginach. 
Wtyczek nie polecę żadnych, bo wszystkie mają dosyć słabą skuteczność, no może z małym wyjątkiem jakim jest gotmls ale i tak jak chcesz mieć pewność że wordpressy będą się miały dobrze to nic innego niż imunify.

Ogólnie to polecam każdą strone na wordpressie podpinać pod CF co już samo w sobie zablokuje dostęp do strony dużej ilości spamerskich bruteforcujących oflagowanych ajpików, do tego regułki już w samym CF na logowanie do wp-admina i będzie okej. 

Edytowane 6 Września 2019 przez sempre