Czy mod_security to dobra rzecz?

Ostatnio byłem odwiedzany przez błędne komunikaty o błędach od mod_security. Jego zestawy filtrów obejmują nieaktualne exploity PHP i muszę przepisać moje rzeczy, ponieważ Wordpress & Co miał błędy wiele lat temu.

Czy zdarza się to komukolwiek innemu?

Apache mod_security blokuje potencjalnie niebezpieczne żądania HTTP, zanim dotrą do aplikacji (w szczególności PHP). Wykorzystuje różne zestawy filtrów, głównie oparte na wyrażeniach regularnych.

Więc mam fajnego współdzielonego dostawcę hostingu, technicznie trafnego i takie tam. Ale to mnie wkurzyło:

W zeszłym tygodniu musiałem zmienić nazwę parametru &src=w jednej z moich aplikacji, ponieważ mod_security blokuje DOWOLNE żądania z tym. Nie sprawdziłem jego szczegółów, ale ta reguła filtrowania uniemożliwiała wykorzystanie innej aplikacji, z której nie korzystam i o której prawdopodobnie nigdy nie słyszałem. Nadal musiałem przepisać mój kod (zmiana nazwy parametru często wystarcza, aby oszukać mod_security), który nie miał nic wspólnego z tym!

A dzisiaj głupie bloki wyrażeń regularnych tworzą formularze, ponieważ chciałem przesłać przykładowy kod php. Biorąc pod uwagę, jest to prosta rzecz, przed którą mod_security ma chronić. Ale nie wierzę, że mod_security może wykryć poważnie zaciemniony kod, i po prostu wychodzi na oczywiste (iw tym przypadku całkowicie trywialne) fragmenty php.

Zasadniczo jestem karany przez mod_security, ponieważ inne osoby wydały podatne na błędy aplikacje. (Nie mówię, że moje aplikacje są bardzo bezpieczne - jestem dość ostrożny, ale nie zgłaszam żadnych hiperbolicznych roszczeń).
Już i tak poprosiłem mojego dostawcę, aby go wyłączył, korzyści są zbyt małe w przypadku IMO i dla moich aplikacji.

Co myślisz? Czy mod_security ma sens poza hostingiem WP? A może to naprawdę tylko garść czarnych list dawno minionych błędów bezpieczeństwa? Które z jego zasad są rzeczywiście pomocne? Czy istnieje równoważny poziom aplikacji?

Osobiście widzę mod_security jako łatkę. Używam go na niektórych naszych serwerach, na których nie możemy kontrolować kodu, który został przesłany (na przykład serwery hostingu współdzielonego), ale tak naprawdę nigdy nie wydawało mi się to dobrym rozwiązaniem. Opierając się na szerokim i bardzo ogólnym podejściu do czarnej listy, jest to raczej łatka do zatuszowania luk bezpieczeństwa niż dobra polityka bezpieczeństwa.

Może również zapewnić fałszywe poczucie bezpieczeństwa. mod_security może ujawnić niektóre typowe ataki, ale w żaden sposób nie może zapobiec żadnemu atakowi. Ponownie jest to czarna lista powszechnie znanych ataków. Jeśli po prostu zainstalujesz mod_security i pomyślisz, że jesteś magicznie bezpieczny, jesteś w strasznym błędzie.

Znalazłem o wiele lepsze zasady dla zarządzanych przeze mnie serwerów, na których mój zespół sprawdza cały umieszczony na nich kod, w połączeniu z dużą ilością dzienników, analizą plików dziennika, systemami raportowania oraz systemami wykrywania włamań / zapobiegania włamaniom (IPS). Za każdym razem, gdy instalowane jest oprogramowanie innych firm lub oprogramowanie typu open source (patrzę na ciebie , WordPress!), Przechowujemy dziennik miejsca, w którym zostało zainstalowane, a po wydaniu nowych wersji aktualizujemy każdą zainstalowaną kopię.

Ponownie, bardziej prawdopodobne jest znalezienie mod_security na współużytkowanym serwerze hostingowym, tak jak obecnie. W miarę rozwoju możesz przejść do dostawcy hostingu opartego na VPS lub clod, w którym dostajesz własne zarządzane środowisko i możesz ściślej kontrolować dostępne oprogramowanie.

Moim zdaniem, jeśli jesteś początkującym programistą, mod_security jest dobrym pomysłem, ale jeśli poświęcisz trochę czasu na poprawne napisanie aplikacji i unikniesz pisania niepewnego kodu, który używa eval lub konkatenuje ciągi GET bezpośrednio do SQL, powinieneś być w porządku bez to. mod_security nigdy nie powstrzyma poważnych hakerów, a jeśli masz dobrą aplikację, dzieciaki skryptów poddadzą się i przejdą do następnej naprawdę słabej i niepewnej aplikacji.