Forum Debian Users Gang

A Apache miał prawo zapisu w folderach z wyświetlanymi plikami?
Może dzięki "superbezpiecznemu" SUEXEC?
Może z poziomu php można było maszkecić w plikach strony?

Czy może ktoś znalazł sposób, żeby wbić przez podatność Apacha, korzystając z faktu, że główny proces chodzi z uprawnieniami roota?

Najpierw zobacz, jak w ogóle doszło do tego włamania, i czy na pewno wbili się przez Apacha, czy może np przez Proftpd, który też co chwila ma jakieś hardcorowe dziury, i jest podatny na siłowe łamanie hasła.
Czy może masz tam zainstalowanego np backdoora ssh.

Jak natomiast nie piszesz ani słowa, o konfiguracji, i nawet nie wiadomo, jak mogło dojść do włamania, to idź z tym do wróżki, żeby sprawdziła w szklanej kuli, co się naprawdę stało. :D

To by było na tyle
;-)

Ostatnio edytowany przez Jacekalex (2013-08-19 16:45:22)

Ja radziłbym 2 vhosty na tą Joomlę.
Jeden do strony publicznej - user apapche, grupa apache, całe jego uprawnienia, to rx na folderach, z wyjątkiem /tmp i /cache.
Drugi vhost - suexec owner, logowanie http-auth, ssl, (można też zrobić logownanie certyfikatem ssl p12), backend administracyjny, ten miałby prawo zapisu w folderach Joomli, powinien móc dodawać obrazki, aktualizować moduły, itp.

Do tego np FW:

iptables -A INPUT -p tcp --dport 80 {inne opcje} -j ACCEPT
iptables - I OUTPUT -m owner --uid-owner apache -m conntrack --ctstate INVALID,NEW  -j REJECT

Spróbuj obciąć możliwości Apacha na FW mniej więcej tak.
Odpadnie Ci wtedy ryzyko, że Twoja Joomla będzie się sama łączyć z netem w celach, o których nie masz pojęcia.

I jeszcze jedno:
Joomla, część publiczna, powinna mieć prawo tylko do SELECT do niezbędnych tabel, na serwerze Mysql, ewentualnie, jak jest jakiś licznik, czy dodawanie komentarzy, to INSERT i UPDATE do jakieś tabeli, w każdym razie minimalne uprawnienia do bazy na serwerze Mysql.
W ten sposób ograniczysz do minimum ryzyko SQL-injection (w Joomli takich dziur masz zawsze kilka).

Wtedy backend administracyjny musiałby mieć innego użytkownika do bazy danych, z wyższymi uprawnieniami, niż absolutne minimum.
W Joomli jest to dosyć trudne, ale wykonalne.
Programiści powinni sobie poradzić :D

Jeśli do tego wyłączysz w php niepotrzebne funkcje, możesz wyłączyć też upload plików na vhoście publicznym, i zostanie bardzo niewiele możliwości na hakowanie tej Joomli.

W każdym razie z takimi dziurawymi rzeczami, jak Joomla, trzeba nieźle pokombinować, najlepiej z nieszablonowymi rozwiązaniami.

Pozdro
;-)

Ostatnio edytowany przez Jacekalex (2013-08-21 18:49:22)

Wsparcie dla Joomli można sobie w buty wsadzić.
Jak ktoś chce, to w 15 minut znajdzie podatność na atak XSS lub SQL-Injection, jak nie w samym silniku, to w którymś z tysięcy rozszerzeń.

jeśli to Apache, to ma mod_security, którym można zatrzymać setki różnych ataków na serwisy www.
W Nginxie i Lighttpd to samo można uzyskać regexami, choć oczywiście nie ma tam możliwości automatycznego dekodowania zapytań ukrytych np w base64 czy rot13 (a może jest, a ja po prostu jestem ślepy?).

Z innych kwestii, na ile pozwoli administrator, tyle może zdziałać włamywacz.
Dlatego, jak się starannie zaprojektuje konfiguracje serwera, zgodnie z zasadami sztuki, ale zarazem wprowadzając trochę własnych, sprawdzonych pomysłów, wielkiego strachu ani ryzyka nie ma.

Tylko trzeba myśleć, najlepiej postarać się myśleć metodami hakera, który chce się włamać do takiego serwisu, i zastanowić, co ja bym zrobił, gdybym chciał zhakować tą stronę.

Do Apacha są gotowe profile Apparmora i Selinuxa, jest możliwosć zrobić sobie bezpieczniejszą wersje php, jeśli się je skompiluje z flagami hardened na poziomie kompilatora (odpadnie 60-80% ataków buffer-owerflow),
a nawet w Joomli możesz ze starej wersji zrobić mocniejszą stronę, niż z najnowszej, jak przejrzysz cały kod, i np dozbroisz wszystkie punkty wprowadzania danych funkcjami, które przecież są dostępne w php.

To by było na tyle
;-)

hello_world napisał(-a):

Zapewniam Cię, że jak bym miał żyłkę do pisania kodu mówiąc potocznie byłbym pełną gębą developerem aplikacji php to pierd.. bym tzw administrację.

Admin zarządzający serwerami WWW, który nie umie programować w PHP to dupa, a nie admin.
Programista który tworzy kod w PHP, a nie zna się na admince serwerami WWW to dupa, a nie programista.

Popieram wypowiedź @Jacekalex w 100%.
Ponadto jeżeli chce się zadbać poważnie o bezpieczeństwo to się nie wybiera joomli.

redelek napisał(-a):

macie pomysł czego szukać w logach apache2 wskazującego na włamanie ?

1 rzeczą którą bym zrobił to sprawdzenie kiedy i o której było 1 wejście na index.html, Na tej podstawie uzyskasz IP atakującego... Później na podstawie IP przegrepuj logi apache. i zobacz do czego miał dostęp.

Wasz serwer jest już skompromitowany. Ja bym rozważał reinstalkę systemu.
Po reinstalacji, i wstawieniu CMS-a z waszą stroną ( przywróconą z kopii bezpieczeństwa przed atakiem ) zainstalowałbym AIDE, do śledzenia zmian w plikach. Po przywróceniu należy zmienić wszystkie hasła użytkowników ... Zalecam również zmiany domyślnej ścieżki logowania do PA joomli.

Ostatnio edytowany przez adam05 (2013-08-22 14:28:27)