devopsiarz
-
Postów
31 -
Dołączył
-
Ostatnia wizyta
Typ zawartości
Profile
Forum
Wydarzenia
Odpowiedzi opublikowane przez 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.
-
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.
-
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.htmlZrzucał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.
-
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'oweObydwa 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.
-
5 godzin temu, theqkash napisał:
Ostatnio do swoich serwerów zacząłem wdrażać mod_pagespeed od Google, szczerze mówiąc doskonale rozwiązuje opisywany tutaj problem, a dodatkowo z automatu konwertuje grafiki na webp, kompresuje skrypty i css'y. Jedynym problemem jest praktycznie brak możliwości konfiguracji przez użytkownika, zwłaszcza wtedy gdy korzysta się np. z php-fpm. No, przynajmniej mnie się nie udało tego sensownie ustawić.
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)
-
-
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ć.
-
21 minut temu, szmigieldesign napisał:
@devopsiarz, korzystałeś kiedyś z wymienionych przeze mnie rozwiązań, w tym z serwera LiteSpeed czy wtyczki o której piszę? Czy piszesz tylko po to, aby komuś dogryźć?
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.
-
1 godzinę temu, szmigieldesign napisał:
@devopsiarz, wtyczka LiteSpeed Cache dla WordPress to stosunkowo rozbudowane narzędzie, którego funkcje można zamknąć w dwóch grupach:
a) szereg narzędzi optymalizacyjnych działających po stronie PHP i funkcji wbudowanych w WordPress (minifikacja, zarządzanie skryptami, obsługa CDN, optymalizacja obrazków, etc.) - te narzędzia działają dla każdej instalacji WordPress, na każdym serwerze.
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.
1 godzinę temu, szmigieldesign napisał:b) interfejs dla cache serwera kompatybilny z licencjonowanymi wersjami LiteSpeed Web Server.
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.
1 godzinę temu, szmigieldesign napisał:Wtyczka może więc działać zarówno w tandemie z wtyczkami generującymi pliki statyczne, jak W3TC czy WP Super Cache, oraz samodzielnie w przypadku serwera LiteSpeed.
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.
1 godzinę temu, szmigieldesign napisał:Zadaniem cache, nawet obsługiwanego przez PHP, jest zmniejszenie zapytań do bazy i opóźnienia przed wysłaniem kodu HTML do przeglądarki klienta - nie jest to więc rozwiązanie pozbawione sensu, nawet jeżeli routing jest oparty o PHP (a trzeba wiedzieć, że zarówno W3TC jak i WP Super Cache są w stanie obsługiwać cache przez .htaccess, czyli z pominięciem PHP).
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.
1 godzinę temu, szmigieldesign napisał:Dla serwerów, które pod obciążeniem generują TTFB na poziomie 0.3 - 0.8 sekundy, uruchomienie cache pozwala na zmniejszenie tego parametru np. do 0.1 lub mniej, nawet przy cache serwowanym przez PHP - po prostu skrypt nie czeka na bazę a PHP obsługuje jedynie prosty routing.
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.
1 godzinę temu, szmigieldesign napisał:@marv, punkty w testach syntetycznych to ostatnie czym powinieneś się kierować jeżeli chodzi o wydajność strony internetowej. Podstawowym parametrem jest czas potrzebny na wyświetlenie kompletnej strony przez przeglądarkę. Nawet taki cache, którego routing jest obsługiwany przez PHP powinien zmniejszyć TTFB - szczególnie w przypadku hostingów współdzielonych, kiedy ruch na serwerze jest znaczący (pamiętaj, że chodzi nie tylko o ruch na Twojej stronie - który może być niewielki - ale także o obciążenie serwera na którym jest Twoja strona). Zobacz mój tekst, pt. "Punkty, punkciki, paranoja", gdzie piszę o wariactwie testów syntetycznych.
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.
1 godzinę temu, szmigieldesign napisał:Kolejna sprawa to skuteczna konfiguracja cache oraz optymalizacji strony (minifikacja, opóźnione ładowanie skryptów, usunięcie niepotrzebnych rzeczy, optymalizacja obrazów, skorzystanie z HTTP2 i precaching, etc. - tego jest całkiem sporo).
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.
-
1
-
-
Oczywiście wszystko zależy od wielkości strony (w tym przypadku m.in. bazy w WP), ilości wtyczek, które "coś robią" itp. Rzeczywiście, jak masz niewielki ruch, parę wpisów na krzyż i nie masz 100 wtyczek, to cache może być zwyczajnie zbędny. Jeżeli bez kombinowania z jakimkolwiek cache, Twojej stronie lepiej i nie narzekasz, to warto przy tym pozostać, zaznaczałem tylko, że wtyczki zazwyczaj robią "pseudo" cache. Działa nawet, ale ten prawdziwy (co daje 100/100 w PageSpeedInsights) wymaga zabawy za kulisami serwera www.
-
Absolutnie popieram kolegę @Archi w tym co tutaj napisał, tylko dopiszę (jako admin, co ma ponad 12 lat swoje serwery poczty), że należy rozróżnić 2 rodzaje dostarczenia:
1) Dostarczenie do docelowego serwera SMTP (to widać w logach naszego serwera), gdy to zawiedzie zwykle dostajemy zwrotkę. Technologie takie jak greylisting mogą to opóźnić o kilka godzin, bo nasz serwer smtp i docelowy, jeszcze ze sobą "negocjują" - wtedy my nie mamy żadnej informacji - chyba, że mamy dostęp do logów naszego serwera i nasz adresat nie ma żadnej informacji.
2) Dostarczenie do krańcowego użytkownika/adresu e-mail przy założeniu, że docelowy serwer SMTP pocztę odebrał. Tutaj nie wiemy czy krańcowy użytkownik dostał swój e-mail. Mógł jego serwer SMTP go "wziąć", ale mu nie dostarczyć z jakichś powodów (np. skaner antyspamowy, antywirusowy, itp). Z kolei, jeżeli użytkownik dostał już finalnie e-mail do swojej skrzynki, to wciąż tego niekoniecznie będziemy świadomi, jeżeli używa np. zewnętrznego klienta poczty, typu thunderbird, który z automatu blokuje wszystkie linki i obrazki pikselowe i ostrzega wyraźnie, że robi to dla prywatności. Myślę, że interfejs webowy gmail też to w przyszłości zacznie blokować na podobnej zasadzie z automatu.
Wniosek: nie ma technologii, która gwarantuje 100% dostarczalność (ba, do czego/kogo - do serwera czy do użytkownika?). Technologię, które "weryfikują" czy użytkownik przeczytał, to już w ogóle loteria i one "działają" w bardzo specyficznych warunkach i "pudłują" z 1/3 maili. Jedynym, 100% pewnym potwierdzeniem dostarczenia e-maila jest e-mail zwrotny od klienta poczty (tzw. potwierdzenie przeczytania - to jest nic innego jak e-mail zwrotny właśnie) lub zwykła odpowiedź od adresata w reakcji na nasz e-mail. Nawet tzw. linki śledzące nie są pewne (te z newsletterów), ponieważ, po tych linkach mogą chodzić automaty skanujące i sprawdzać, czy nie wita ich strona z nagłówkiem application/octet-stream, czyli że nie chce czegoś userowi wysłać.
-
Końcówka logów to sytuacja, gdy Ty próbujesz się podłączyć do bazy, czy ten skrypt?
-
1
-
-
3 godziny temu, szmigieldesign napisał:
Tak jak sam sobie odpowiedziałeś - Wyświetlaj zasoby statyczne, stosując efektywne zasady pamięci podręcznej' dotyczy pamięci podręcznej przeglądarki, albo raczej poinstruowania jej, jak ma traktować materiały pobrane z serwera. WP Super Cache nie dodaje odpowiednich zapisów do .htaccess (o ile mnie pamięć nie myli), robi to W3TC albo LiteSpeed, który niezawodnie polecam do kompletnej optymalizacji stron opartych na WordPress. Myślę, że to dużo lepsze rozwiązanie niż Autoptimize, chociażby ze względu na mnogość opcji, rozbudowane zarządzanie wyjątkami i chyba najlepszą w branży optymalizację obrazów w bibliotece Media. Jeżeli jesteś zainteresowany tematem, na moim blogu przeczytasz więcej o LiteSpeed Cache dla WordPress.
Żadna ze znanych mi wtyczek cache, w tym LiteSpeed, mówię o wersjach darmowych, nie robi cache porządnie. Jeśli webserver jest niestandardowy (patrz: nie apache), to robią "biedacache" - wygenerowane pliki statyczne są serwerowane przez... PHP. Nie wiem jak na apache jest, mogę podejrzewać, że też źle. Czyli zamiast serwować bezpośrednio pliki, serwer podaje request do php, a php dopiero "kuma", że ma cache (redis czy coś tym stylu lub właśnie pliki statyczne).
Owszem w stosunku do "gołego" WP, te wtyczki przyspieszają działanie strony, ale i tak jest to marnowanie zasobów na wysokim poziomie i zmarnowany potencjał. Jeśli cache ma być porządny, to bez grzebactwa w webserverze się nie obejdzie i/lub współpracy z czymś z rodzaju varnish. Także nie polecam wydawać pieniędzy na te wtyczki, bo to nie jest warte świeczki.
-
Ja mam tzw. immutable infrastrukture. Tworzę nowy obraz z pełną aktualizacją (w zasadzie to automat po API u Cloud providera) co jakiś czas i jak obraz jest gotowy to w razie potrzeby od razu tworzę nową instancję na bazie tego obrazu (z aktualnymi rzeczami na moment utworzenia obrazu). To ma też taką zaletę, że jak działa "stara" instancja, to na boku mogę stworzyć "nową" i sprawdzić np. kitchen inspec, czy to co wstało, działa prawidłowo. Czysty DevOps.
-
Uwaga, kandyduję o złotą łopatę!
A co do problemu to nic się nie przejmuj, bo masz po prostu podane zwyczajnie parametry z jakimi masz odpalonego demona `php-cgi71`, który obsługuje pliki *.php. Z tego co pamiętam,
-dwskazuje parametry konfiguracyjne i w ten sposób jest tutaj ustawiony "sendmail_path" - to parametr, który wpływa na obsługę funkcji "mail()". Według mnie, to co niepokoi, to bez wątpienia parametr "open_basedir" powinno się go używać z głową lub wcale, a tutaj np. widzę "/home/bip" wskazany na luzaka. Pozdrowienia dla konfigurującego z tego miejsca.
-
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,
-
3 godziny temu, spex napisał:
A jaki jest cel zamykania starych wątków? Czy podobny problem nie może się zdarzyć komuś ponownie? I co wtedy, ma zakładać nowy tematu, bo u niego rozwiązanie nie działa.
No tak, jak komuś odpowiem po roku, to złota łopata, a jak sygnalizuję, że niektóre fora automatycznie zamykają stare nieaktywne tematy (co też ma uzasadnienie), to już ktoś oponuje, że "co jeśli". Zdecydujcie się tutaj czego oczekujecie.
-
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.
-
Tak, dziwne, chcę pomóc. A forum nie zamyka z automatu starych wątków w roku 2019. Założyliście tutaj jakiś elitarny klan, że tak "reagujecie" na nowych?
Zabezpieczenia aplikacji na serwerze
w Bezpieczeństwo
Opublikowano
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ż.