devopsiarz

Czyli np. jak aplikuje reguły do .htaccess, to mieści się to w tej definicji, bo wpływa na komunikację HTTP. Znaczy się, wszedłeś w wątek, nie wiedząc, co można robić fail2ban, tak mam rozumieć powyższą wypowiedź? 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ż.

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.

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. 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.

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.

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. Obydwa to rozwiązania programowe, ale to pierwsze jest w fancy obudowie, za fancy cenę. Każde jest softwarowe.

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

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.

No to teraz dla pewności odpal Safari i sprawdź czy Ci webp działają

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.

Digital Ocean ma VPSy w datacentrach w USA, nie wspominając o tych popularniejszych dostawcach tego typu usług (Amazon, Google, Microsft)

https://askubuntu.com/a/875087

Nie widzę problemu, głosowanie portfelem działa zawsze. Cisco sprawdza, na ile sobie może pozwolić, a jak będzie wahnięcie finansowe na ich niekorzyść, to zmienią to szybciej, niż ktoś ich zdąży pozwać.

Tak, korzystałem, pierwszy raz w 2015. Ale umówmy się, że jak nie masz zamiaru odnosić się w ogóle do treści merytorycznej mojego posta, to albo na niego nie odpowiadaj, albo nie licz, że będę na poboczne pytania jednozdaniowe odpowiadał. Czyli zamiast zadawać takie pytania, wprost wskaż, gdzie nie mam racji - będzie szybciej i przyjemniej w dyskusji.

Nie działają dla każdej instalacji WordPress i nie na każdym serwerze. Polecam się zapoznać z tym, jak działają czasem wtyczki "pod maską", w tym te co wymieniłeś. One z czegoś korzystają, bo nikt koła na nowo we wtyczce nie wymyśla (np. optymalizacja obrazków). Często same Ci powiedzą, czego Ci brak na serwerze, albo same zaoferują swoje API, za stosowną opłatą powyżej pewnego limitu. Więc nie, nie działają wszędzie i na każdym. Z punktu widzenia użytkownika końcowego lepszy jest cache kompatybilny z popularniejszymi rozwiązaniami. Ale szanuję, mówka handlowca była tu książkowa. Nie, nie może. Tzn. możesz sobie popychać treść między tymi wtyczkami, jak zależy Ci na zwiększeniu latencji, w sytuacji, gdy cache jeszcze nie masz wygenerowanego. Natomiast jak jedna wtyczka działa "dobrze", w sensie robi co powinna, to druga już efektywnie działać nie może. Chyba, że jednak będzie "poprawiać" pierwsza. Zatem kilka wtyczek do statycznych plików to ciekawa idea, ale dziwna i niepotrzebna. Rozwiązanie się sprawdza (jako tako) do pewnej skali, ale jest pozbawione sensu w ogólnym rozrachunku, gdyż: 1) Użycie PHP powoduje zwiększenie zasobów serwera, fakt - bazy nie używamy, jest postęp! 2) Użycie PHP jest problematyczne jeszcze z innego powodu - wciąż jesteś narażony na błędy bezpieczeństwa związane z wtyczkami WP, jak i samym silnikiem PHP - dziwna sytuacja, gdy chcemy serwować pliki statyczne. Podałeś cyfry dla jakiej sytuacji? Jakie obciążenie, strona, routing, przy jakiej treści, jakim protokole konkretnie? Bo wiesz, cyfry bez kontekstu, to tylko cyfry. TTFB jest mocno mylącym parametrem (nie mającym nic wspólnego z tym, co określasz "podstawowym parametrem") i zalecałbym się nim nie przejmować, w ogóle nie mówi nic o wydajności strony jako takiej. Np. mój serwer może błyskawicznie wysłać header i TTFB będzie miał rewelacyjny, a że baza zwróci wyniki za 5 sek to już taka mało znacząca kwestia. Skorzystanie z HTTP2, bez kontekstu, tylko na zasadzie "włączmy", może równie dobrze zdegradować wydajność.

To ja bym w to najprostsze rozwiązanie poszedł. Czyli jak skrypt zwraca jakiś kod błędu (jak sam używa polecenia mysql to duża szansa), to odpalać go później znowu - jeśli ten błąd oczywiście wystąpił i jeśli następne odpalenie dopiero problem rozwiązuje. A skrypt definitywnie jakiś nieteges jest.