Skocz do zawartości

devopsiarz

Użytkownicy
  • Postów

    31
  • Dołączył

  • Ostatnia wizyta

Treść opublikowana przez devopsiarz

  1. 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ż.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. No to tylko oni to wiedzą, co tu u nich tak naprawdę oznacza
  7. 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.
  8. No to teraz dla pewności odpal Safari i sprawdź czy Ci webp działają
  9. 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.
  10. Digital Ocean ma VPSy w datacentrach w USA, nie wspominając o tych popularniejszych dostawcach tego typu usług (Amazon, Google, Microsft)
  11. 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ć.
  12. 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.
  13. 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ść.
  14. 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.
  15. 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.
  16. 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ć.
  17. Końcówka logów to sytuacja, gdy Ty próbujesz się podłączyć do bazy, czy ten skrypt?
  18. Ż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.
  19. 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.
  20. 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, -d wskazuje 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.
  21. 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). 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. 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,
  22. 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.
  23. 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.
  24. 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?
×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Korzystając z forum, wyrażasz zgodę na: Warunki użytkowania, Regulamin, Polityka prywatności.