Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Ogłoszenie
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
#1 2013-08-02 10:26:19
Odin - Użytkownik
- Odin
- Użytkownik
- Zarejestrowany: 2012-10-25
Mod_Security i blokowanie passwd
Witam,
Ktoś odczytał plik passwd na moim testowym serwerze używając ajaxfilemanager:
Kod:
ajaxfilemanager/ajax_text_editor.php?editor=form&elementId=aaa&filepath=../../../../../../../../etc&path=../../../../../../../../etc/passwd
Próby odczytania passwd przez:
Kod:
domena.pl/../../../../../../../../etc/passwd
Są blokowane przez mod_security stąd moje zaskoczenie bo myślałem, że każdy url tego typu będzie blokowany.
Możecie mi podać przykład formułki dla mod_security żeby blokowała wszystkie zapytania http posiadające passwd?
Z góry dziękuję.
edit:// Zakręciłem się niepotrzebnie, oczywiście wystarczy:
Kod:
SecRule REQUEST_URI "passwd" "deny,log,status:406"
Ostatnio edytowany przez Odin (2013-08-02 10:48:25)
Offline
#2 2013-08-02 18:13:44
Jacekalex - 
Podobno człowiek...;)
- Jacekalex
- Podobno człowiek...;)
- Skąd: /dev/random
- Zarejestrowany: 2008-01-07
Re: Mod_Security i blokowanie passwd
A Apache przypadkiem nie ma automatycznego chroota?
Mieli to wprowadzić w którejś wersji.
W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem para bellum ;) | Pozdrawiam :)
Offline
#3 2013-08-16 08:43:31
Odin - Użytkownik
- Odin
- Użytkownik
- Zarejestrowany: 2012-10-25
Re: Mod_Security i blokowanie passwd
Raczej nie wprowadzili, jest coś takiego jak mod_chroot ale jeszcze nie miałem okazji przetestować.
Offline
#4 2013-08-16 10:19:05
Jacekalex - Podobno człowiek...;)
- Jacekalex
- Podobno człowiek...;)
- Skąd: /dev/random
- Zarejestrowany: 2008-01-07
Re: Mod_Security i blokowanie passwd
Apacha w tej chwili pod ręką nie mam, tylko Lighttpd, a ten domyślnie wszystkie ścieżki przymierza do DOCUMENT_ROOT a nie /.
Wynik:
Kod:
curl "http://localhost/../../../../../../../../../../../etc/passwd"
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>404 - Not Found</title>
</head>
<body>
<h1>404 - Not Found</h1>
</body>
</html>Bez żadnego mod_security. ;)
Sprawa jest tak oczywista, ze w Apachu niezależnie od Chroota i Mod_security powinno się to dać identycznie ustawić w podstawowej konfiguracji.
Sam jestem ciekaw, gdzie. ;)
Natomiast w przypadku interpretera php, którego nie ogarniają zmienne Apacha, sensowniejszym rozwiązaniem od Mod_Security jest dostępna w php funkcja open_basedir.
Tutaj z resztą odczytanie /etc/passwd miało miejsce nie z winy Apacha,
tylko z poprzez php, który to jest kiepsko albo w ogóle nie skonfigurowany.
Tu masz conieco na ten temat:
http://nfsec.pl/security/2706
W ogóle konfiguracja php, to osobna bajka, i nawet bardziej skomplikowana, niż Apache.
Na szczęście php pozwala wyłączyć nieużywane funkcje.
Mod_security natomiast radziłbym użyć do filtrowania ataków typu xss czy sql_injection, czyli do tego, do czego został stworzony, bo blokowanie dostępu do/etc/passwd, to jest przedszkole, i powinno być blokowane domyślnie z buta,w Apachu.
EDIT:
Zamiast kombinować regułki osobno, dla każdgo pliku w /etc, zainteresuj się w Apachu funkcją:
Kod:
SecChrootDir
z modułu mod_security.
EDIT2:
Mam już Apacha - wersja 2.2.25, i on ma wbudowany moduł chroot.
Dyrektywę ChrootDir:
Kod:
grep -ri chroot /etc/apache2/* /etc/apache2/httpd.conf:ChrootDir /var/www/
łyka jak małpa banana bez żadnych dodatkowych modułów. :D
Kod:
==> /var/log/apache2/ssl_error_log <== [Fri Aug 16 11:38:20 2013] [error] [client 127.0.0.1] client denied by server configuration: /var
I nawet działa, ;P
Gotowe, podstawowa konfiguracja nie jest szczególnie trudna:
http://www.howtoforge.com/chrooting-apache2-with-mo … ebian-squeeze
http://www.cyberciti.biz/tips/chroot-apache-under-r … os-linux.html
Ten moduł pojawił się w wersji wbudowanej w Apacha od Apache 2.2.10,
zewnętrzny mod_chroot był do wcześniejszych wersji.
Najtrudniejszym do zabezpieczenia elementem są skrypty cgi, i o ile to możliwe, lepiej z ich użyciem nie przesadzać.
Pozdro
;-)
Ostatnio edytowany przez Jacekalex (2013-08-16 16:07:24)
W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem para bellum ;) | Pozdrawiam :)
Offline
#5 2013-08-16 15:11:13
morfik - Cenzor wirtualnego świata
Re: Mod_Security i blokowanie passwd
Jacekalex napisał(-a):
A Apache przypadkiem nie ma automatycznego chroota?
Mieli to wprowadzić w którejś wersji.
Zgodnie z tym zapisem:
Kod:
# Sets the default security model of the Apache2 HTTPD server. It does
# not allow access to the root filesystem outside of /usr/share and /var/www.
# The former is used by web applications packaged in Debian,
# the latter may be used for local directories served by the web server. If
# your system is serving content from a sub-directory in /srv you must allow
# access here, or in any related virtual host.
<Directory />
Options FollowSymLinks
AllowOverride None
Require all denied
</Directory>
<Directory /usr/share>
AllowOverride None
Require all granted
</Directory>
<Directory /var/www/>
Options Indexes FollowSymLinks
AllowOverride None
Require all granted
</Directory>apache nie uzyska dostępu do / . To chyba się pojawiło w ostatniej aktualizacji apache, bo straciłem dostęp do swojego localhostowego servera i musiałem popatrzeć wtf. xD
Offline
#6 2013-08-16 15:53:00
Jacekalex - Podobno człowiek...;)
- Jacekalex
- Podobno człowiek...;)
- Skąd: /dev/random
- Zarejestrowany: 2008-01-07
Re: Mod_Security i blokowanie passwd
Kiedy tu nie Apache się wyrwał z klatki, tylko php, o ile pamiętam, nie wszystkie dyrektywy Apacha jednakowo działają z w interpreterze php, tam się stosuje przede wszystkim safe_mode i open_basedir, z równoczesnym wyłączeniem funkcji symlink.
Chroot jest o tyle skuteczniejszy, że kiedy Apache się zamknie w chroocie, to wszystkie wtórne procesy Apacha, php i cgi dziedziczą nowy $ROOT, i działają w chroocie.
Jest trochę zabawy z konfiguracją, ale to najlepszy sposób, żeby trzymać Apacha na smyczy z całym bajzlem, jaki uruchamia.
Nawet robiąc ACL w SELinux/Apparmor/Grsec Apachowi trzeba dać wgląd w /etc/passwd i /etc/group, żeby wiedział, z jakim userem i grupą ma chodzić.
Zrzucenie uprawnień z równoczesnym przeskoczeniem do chroota (wbudowana obecnie funkcja Apacha) rozwiązuje ten problem automatycznie.
Inna sprawa, że /etc/passwd i /etc/group są praktycznie we wszystkich Debianach takie same, i od kiedy nie ma w nich haseł systemowych, to nie ma w nich też nic tajnego, natomiast bardzo groźna jest możliwość modyfikacji tych plików, ale to załatwia domyślny system uprawnień w Linuxie.
Ostatnio edytowany przez Jacekalex (2013-08-16 17:23:22)
W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem para bellum ;) | Pozdrawiam :)
Offline