Forum Debian Users Gang

Rzuć okiem na to:
http://www.jasonkingstudios.com/blog/apache-mod_sec … ng-wordpress/

O ile pamiętam, w mod-sec można whitelistować hosty na kilka sposobów.

Zamiast mod_security radzę Nginxa lub Lighttpd do serwowania stron pierwszy user (php-fpm do php), apache do paneli administracyjnych drugi user - inne uprawnienia.
Założenia:
user nginx/lighty ma tylko odczyt do skryptów php, i folderów innych niż tmp, cache i session, takich, gdzie CMS musi zapisywać w trybie strony.
Apache schowany za Nginxem/Lightym ma pancerne zabezpieczenia, działa tylko po ssl, autoryzację http ale obrabia tylko zaplecza administracyjne, w ogóle niedostępne z poziomu Lighty/Nginx.
Ma za to prawo zapisu w plików php, obrazków i innych, przez co można
aktualizować Joomle, Wordpressy, itp.
Lighttpd czy Nginx jest też rev_proxy dla pancer Apacha, oprócz tego serwuje stronę (część publiczna) samodzielnie.

Do tego trzeba tak przerobić CMSY ( w starym Oscommerce-2 to był standard, ale w nowszych CMSach trzeba się nagimnastykować trochę),  żeby strona publiczna używała innego użytkownika i miała obcięte do SELECT (na niezbędnych tabelach) prawa w mysql (i całkowity zakaz dostępu do tabeli z hasłami użyszkodników), natomiast schowany za pancernym Apachem backend administracyjny - innych użytkowników w bazie, którzy mają pełne prawa do tych baz.

Czyli:
Część publiczna, bez logowania: nginx lub Lighty z php-fpm, i obciętymi wszystkimi możliwymi uprawnieniami do koniecznego, niezbędnego minimum.
Cześć prywatna, panele administracyjne, phpmyadminy, logi, webalizery awstatsy, itp) - pancer Apache, nie musi być szczególnie wydajny, ale musi być bezpieczny jak czołg, a bootów i tak się tam nie wpuszcza.
Wszystkie CMSowe logowania schować za solidnym http_auth z ssl.
Jak ktoś nie umie podłączyć WP do http_auth, to niech klepie 2 hasła po 256 znaków :D

W ten sposób masz z głowy spory kawał podatności SQL-Injection, która jest swoistym"znakiem firmowym" CMSów podobnych do Wordpressa.
Także całkowicie wyeliminujesz taki ulubiony drobiazg, jak wbicie na serwer np c99 przez skrypciarza i późniejsza zabawa.
I do tego ewentualnie pacjent, który wali na WordPressa uprawnienia -R 777 (bo tak "się robi") , a potem narzeka, że serwer do dupy, bo mu na tego WP gówniarze wjechali.

Trochę zabawy jest, ale w rezultacie wychodzi szybkie, sprawne, i diabelnie trudnohakowalne diabelstwo.

Ostatnio edytowany przez Jacekalex (2013-02-12 14:01:05)

W pancer Apachu mod-sec się przyda.
W Lightym i Nginxie masz wszystkie limity, jakie potrzebujesz, rewrite'y i podobne diabelstwa.

Polecam Lighttpd, u mnie do działania nie potrzebuje żadnego procesu z uprawnieniami roota, (w przeciwieństwie do Nginxa i Apacha).

I patrz, żebyś nie spierdolił serwera w taki sposób:
http://dorzeczy.pl/robots.txt
http://dorzeczy.pl/wp-admin/
http://dorzeczy.pl/wp-includes/

Bo jakby mnie ktoś tak serwer postawił, jak w powyższych sznurkach, to bym za nabiał na latarni powiesił takiego "administratora".

Jeśli  tego całego bajzla postawisz na regularnie aktualizowanym Gentusiu-hardened z maksymalną ochroną grsec/pax - grsecurity-ACl, to za karę będziesz musiał przygotować dla ofiar tego serwerka stronkę motywacyjną z cyklu "pocałujta w doopę wójta".
Wtedy będzie można go albo przyblokować zwykłym dos/ddos - na serwerze tego nie zatrzymasz (trzeba łapać kilka pięter wyżej, najlepiej w okolicy routera BGP), albo poderwać Asię Rutkowską. :DDD

I zainteresuj się php.ini i opcjami php w plikach konfiguracyjnych, masz tam możliwość wyłączenia niebezpiecznych funkcji (mniej więcej połowa :D ), ograniczenia katalogu (open_basedir), i całego Suhosina
z takimi bajerami, jak np szyfrowanie ciasteczek (utrudnia przechwycenie sesji),
i setką innych opcji.
Sznurek:
http://www.hardened-php.net/suhosin/configuration.html


Pozdrawiam
;-)

Ostatnio edytowany przez Jacekalex (2013-02-12 14:00:10)