# Filtrowanie outputu z Apache

## exidox

Witam,

szukałem sporo po sieci, niestety natrafiłem na manuale, które są mało zrozumiałe dla mnie, dodatkowo bez przykładów, które mnie interesowałyby.

Sprawa wygląda następująco.

Potrzebuje filtrować ruch wychodzący z serwera apache w ten sposób:

apache -> filtr -> klient

filtr miałby sprawdzać, czy w wygenerowanym przez serwer outpucie znajdują się określone wyrażenia i gdyby tak się stało, to wykonałby któreś z poleceń:

- zwróć 403

- daj klientowi bana na cały serwer (w sensie dodaj wpis do iptables)

Myślałem nad użyciem modułu sed'a, niestety w takim wypadku osiągnąłbym jedynie rozjechanie strony (podmienienie kodu) zamiast zwrócenia błędu lub wywalenia klienta.

Próbowałem modułu string w iptables, jednakże nie działa mi to poprawnie.

Macie jakieś pomysły?

Rozwiązanie podobnego do mojego problemu widziałem tutaj:

http://www.digipedia.pl/usenet/thread/2181/16090/

jednakże link na dole wygasł.

Pozdrawiam

----------

## Jacekalex

Bramą aplikacyjną dla Apacha jest mod_security, i ten zazwyczaj działa.

Obsługuje czysty regex w regułach, także conieco można w nim zrobić.

Conieco można też zrobić w mod_rewrite.

Jednak te filtry dzialają na wejściu, filtrując zapytania GET i POST, co Apache zwróci w wyniku zapytania, to już kwestia treści, jakie ten Apache udostępnia.

Jeśli na Apachu masz jakiś CMS, oparty np na PHP, to w nim też mozesz conieco zrobić, żeby zabezpieczyć bajzel.

Są np blacklisty, jest captcha, i kilka innych rozwiązań, które mozna wdrożyć w samym skrypcie cms, żeby ograniczyć trochę dokuczliwość spamerów.

----------

## exidox

Witam,

dzięki za odpowiedź.

W moim problemie nie chodzi o spam, ale o dziury moich użytkowników w wordpressach i jumlach.

Mam delikwenta który wpycha im na konta webshelle, szukam rozwiązania tego problemu i ewentualne filtrowanie treści mogłoby to rozwiązać.

Najlepszym rozwiązaniem jest zabezpieczenie skryptu, ale userom nie jestem w stanie tego wytłumaczyć...   :Embarassed: 

Głównie chodzi o webshelle tego typu:

http://pastebin.com/SWgYAm1S

Mój pomysł był nad filtrowaniem wyjścia apacha, i jak naprafi na podobny output to go zablokuje.

----------

## Jacekalex

To masz nieźle spieprzoną konfigurację.

Zaionteresuj się parametrem umask - obsługują go wszystkie serwery ftp.

Możesz też kombinować np z  lepkim bitem, albo ustawić dla Apacha ACL np w Grsecurity czy Apparmorze, żeby Apache nie mial prawa zapisu w folderach ze skryptami, z wyjątkiem folderów tmp, cache  i logs.

I do tago skrypty, które zmieniają uprawnienia, np  *.php na 755, *.jpg na 644, itp.

Jeśli ktoś dorzuca php.shell do Joomli, to znaczy, że ma prawo zapisu w folderach Joomli, a tego się nie zostawia.

----------

## SlashBeast

Troche poplynales Jacekalex. Jak to mowia sa trzy prawdy, a Ty jestes gdzies pomiedzy druga i trzecia.

Normalna praktyka jest odpalanie php jako user ktorego jest to vhost, przez suexec, suphp, spawnowanie php-fpm pooli i tak dalej. W tym momencie taki apache laczy sie do php usera X, ktory rowniez jest ownerem plikow *.php, tak wiec moze je edytowac. Jezeli dasz nawet sobie bez praw zapisu, czyli *.php na 0400 to nie jest problemem zrobic chmod(), chyba, ze to rowniez zablokujesz w php ale bardzo negatywnie wplywalo by to na wiekszosc skryptow. Polityki Grsecurity RBAC raczej nikt nie bedzie pisal per vhost jezeli bedzie mial ich wiele. By np. zblokowac takie php usera foo by moglo zapisywac tylko do tmp, cache itp musial bys naprawde duzo wysilku i checi w to wlozyc, rozne sa to pathy per-aplikacja, zupelnie nie warto.

@exidox: Proponuje upewnic sie, ze serwer jest bezpieczny, cuda jak system, shell_exec itp sa wylaczone, czy nawet wylaczyc troche wiecej jak fopen czy curl. Jezeli Ci ludzie placa za ten hosting - ich sprawa, ze maja webszele, jak bys mial abuse jakies, to urwij im konta i tyle. Jezeli natomiast robisz to nieodplatnie to odrazu urwij im konta za dzialanie na szkode serwera.

----------

## Jacekalex

W polityce  Grsec ostatnio pojawia się regex, także można conieco sensownie wykombinować, nie robiąc tego per/user, a grsec przywołalem jako przykałd ACL - dosć pancernego.

Znacznie łatwiej to zrobić  w profilach Apparmora.

Uruchomiemie php-fpm - każdemu  pacjentowi jego własny demon php? bardzo fajna sprawa, w Nginxie i Lighttpd działa elegancko, w Apachu trzeba go zapinać przez moduł fastcgi.

Osobiście jdnak podzieliłbym odpowiedzialność, Administrator odpowiada za serwer, pacjenci za swoje skrypty.

Oczywiście wyłączenie kilku potencjalnie groźnych funkcji w php też jest niezbędne, i to jak najbardziej jest w zasięgu Administratora,  choć zawsze znajdzie się jakiś pacjent, który bez shell_exec i curla żyć nie może  :Wink: 

A i amator REGISTER_GLOBALS też pewnie jakiś się znajdzie...

----------

## exidox

Witam,

Problem tkwi w dziurach np. templates moich userów w wordpresach,  atakujący wgrywa przez nie taki webshell i go uruchamia, ma on prawa tylko do katalogu domowego - o stan samego serwera się nie boję. Po takim ataku podmienia im indeksy i tyle.

Wyrzucenie funkcji system(), exec() niestety nie wchodzi w grę ;/ Fopen curl itd również. Zadźgaliby mnie.

Suexec, suphp jest.

Aktualnie na serwerze jest skonfigurowany mod_security, ale tego nie wyłapuje.

Myślałem też nad modułem string w iptables, ale raczej wydajnościowo to nie wydoi - dodatkowo próbowałem i niestety nie działało.

----------

## Jacekalex

To naucz tych pajentów, że sami odpowiadają za bezpieczeńswo swoich aplikacji.

Poza tym ja spróbowalbym zrobić to tak, zeby np każdy pacjent miał 2 userów, jednego, który ma prawo zapisywać pliki, i drugiego, który ma tylko odczyt i uruchomienie.

Jeśli w susexec odpalisz tego drugiego usera, to uniemożliwisz skrypciarzom modyfikację plików i skryptów.

Musiałbyś wtedy robić dwa vhosty dla pacjenta, bo jak znam lamerstwo, to przy Joomli muszą mieć prawo zapisu w folderze głównym, bo samemu rozpakować rozszerzenia nie łaska, ustawić prawidłowych uprawnień również nie.

 Ale dać takiemu pacjentowi umask 022. niech strona chodzi z uprawnieniami innego usera, i gotowe.

Wyjątek stanowią miejsca, gdzie taka np Joomla musi zapisywać, czyli /tmp, /log i /cache.

Osobna sprawa, to Mysql, tutaj też lepiej dać np Wordpressowi czy Joomli tylko SELECT dla strony widocznej z netu, a zapis dla administratora.

Jednak o ile w starym Oscommerce-2 admin i sklep mialy 2 różne konfigi,

 i mogły chodzić na 2 różych użyszkodnikach SQL, o tyle w Joomli czy Wordpessie trzeba by majstrować w tych skryptach, bo to generalnie dość durne narzędzia.

A precyzyjne ustawienie uprawnień w Mysql, to najlepsza obrona przez dokuczliwością ataku SQL-Injection, ktory jest pierwszym zagrożeniem, 

jakie dotyczy wszystkich CMSów, jakie widziałem.

Dałbym też pacjentom możlowość tworzenia konfigu, który byłby includowany do konfigu vhosta, nie dla pacjentów, tylko dla siebie, bo jak bałwan jakiś wklei np listę sblamu do .htacces, to cały Apache, lub tylko host virtualny dostaje czkawki przy każdym wejsciu do folderu.

Wymagało by to oczywiście skrytpu testujacego poprawność składni takiego konfigu, ale myślę, że warto.

Jesli w dodatku dasz możliwość wklejania reguł  w tym konfigu (czy htacces), obejmujących choćby rewrite, to część ludzi sobie poradzi.

Choć oczywiście nie wszyscy.  :Smile: 

A z wyłaczniem poszczególnych funkcji? ja bym bałwanów przywyczajał, na rozmaitych hołmach czy nazwach też nie można odpalać kliku potencjalnie groźnych fuynkcji php, i jakoś nikt z tego wrzasku nie robi.

Mozesz też zmontować sprawe tak, jak kiedyś home robilo z register_globals, domyslnie wyłączone, ale każdy może sobie włączyć, jak potrzebuje.

W rezultacie większość pacjentów, którzy RG nie potrzebowali, nie włączyła go, bo i tak nie potrzebowała, a często nie wiedziała jak.  :Very Happy: 

Tak bym potraktowal wszystkie niebezpieczne funkcje php, najprościej każdemu zostawić jego wlasny php.ini. własnego demona php-fpm, i niech się sam martwi, co z tym zrobić.

W jailu, żeby Ci durnota jednego bałwana nie uwaliła całego serwera, masz limit.conf i cgroup, także bezbronny nie jesteś.

natomiast na poziomie kernela możesz te jaile/chrooty potraktować tym:

```
kernel.grsecurity.chroot_caps = 1

kernel.grsecurity.chroot_deny_chmod = 1

kernel.grsecurity.chroot_deny_chroot = 1

kernel.grsecurity.chroot_deny_fchdir = 1

kernel.grsecurity.chroot_deny_mknod = 1

kernel.grsecurity.chroot_deny_mount = 1

kernel.grsecurity.chroot_deny_pivot = 1

kernel.grsecurity.chroot_deny_shmat = 1

kernel.grsecurity.chroot_deny_sysctl = 1

kernel.grsecurity.chroot_deny_unix = 1

kernel.grsecurity.chroot_enforce_chdir = 1

kernel.grsecurity.chroot_execlog = 0

kernel.grsecurity.chroot_findtask = 1

kernel.grsecurity.chroot_restrict_nice = 1
```

Także, czy sobie pacjent "rękę odpiłuje", czy "oko wydłubie",

 serwer ma wytrzymać, a za swoje skrypty niech ludzie przede wszystkim sami odpowiadają.

Zostaw im trochę narzędzi do konfiguracji, ale nie próbuj za ni9ch myśleć, bo jak podejrzewam, 90% Twoich pacjentów nie wie nawet, czym się różni chmod 755 od 777 dla pliku php.

Ale jak im ktoś shakuje stronę, to jest święte oburzenie.  :Very Happy: 

Pozdrawiam

 :Cool: 

----------

