ROZWIĄZANY: Zabezpieczenie serwera

[Amfidiusz]

Hej,

Wczoraj po powrocie z pracy zaskoczył mnie dosyć ciekawy widok na wszystkich moich stronach: Hacked by ***

Wygląda na to, że ktoś w jakiś sposób uzyskał możliwość podmiany wszystkich plików index html i php na swoje własne. Podejrzewam, że udało mu się to przy pomocy dosyć wiekowej wersji joomli, która stoi w jednym z katalogów.

Pytanie więc, czy i jak można zdiagnozować którędy dostał się na serwer? Nie sądzę, że przechwycił hasło do ftp, bo pod tym względem jestem dosyć ostrożny, a i reszta plików czy bazy danych pozostały nietknięte. Czy mozliwe, że ktoś przeprowadził taką czynność z poziomu podkatalogu ftp, tak jak w przypadku niedawnego ataku na vbhelp? Czy istnieje jakakolwiek możliwość rozgraniczenia katalogów na serwerze tak, że nawet jak się dostaną do jednego z nich, to nie zrobią nic z pozostałymi? Serwer mam dzielony w dH, więc wierzę w ich zabezpieczenia od strony technicznej i to raczej był mój błąd gdzies po drodze.

[DawPi]

Na moje amatorskie serwerowe oko to mając dostęp do jednego katalogu na dH, dostęp do innych jest domyślnie. Ewentualnie można tworzyć subkonta FTP z dostępami do wydzielonych katalogów - to powinno być OK.

[Amfidiusz]

subkonta FTP z dostępami do wydzielonych katalogów - to powinno być OK.

To właśnie miałem na myśli I z tego co pamiętam, to własnie przez takie subkonta padło vbhelp.

[Portek]

Mniemam że dostępu do konsoli via ssh nie masz? Informacje n/t włamania możesz sprawdzić w logach - jeśli masz dostęp ssh: /var/log/apache2, jeśli nie i nie widzisz logów po wejściu na FTP pisz do boku z prośbą o udostępnienie logów error i dostępu z dnia włamania (najlepiej dzień wcześniej też). W logach jest IP, prosisz o blokadę na poziomie firewalla i tyle.

Jak można się zabezpieczyć? Tutaj w sumie prościej było by to robić pod konsolą SSH, wątpię że ktoś Ci daje dostęp do chroot jail - to co jest w standardzie konfiguracji jest, hmm jakby to powiedzieć nie do końca odpowiednie.

[DawPi]

Tak się tłumaczyli. A prawdy i tak nie poznamy. Wg mnie, jak dobrze zrobione, to nie ma opcji przebicia się..

[Tajfun]

Witajcie.

To mój pierwszy post

Jeśli ktoś miał dostęp do jednego katalogu to za pomocą ShellCodów robić z plikami na całym serwerze (o ile mają chmod większy niż 4**) co tylko zechce.

Pozdro

Tajfun von Bruno

[DawPi]

Tajfun: ok, ale na każdym serwerze i nie ma opcji zablokowania tego? Coś wierzyć mi się nie chce, a widzę, że Ty masz o wiele większą wiedzę w tym zakresie - podzielisz się?

[Amfidiusz]

Nie mam dostępu SSH. Czekam na odpowiedź BOKu. Dam znać, co dalej

[Tajfun]

@DawPi, ShellCode jest najzwyklejszym plikiem napisanym w PHP. Jesli już dostanie się na serwer to nic go nie powstrzyma, bo blokada tego musiałaby być blokadą operacji na plikach dla wszystkich skryptów PHP. Osobiście nie znam hostingu ktory posiada przed tym zabezpieczenie.

Tajfun von Bruno

[DawPi]

Znam definicję ShellCode, ale nadal nie przekonałeś mnie, że zwykły kod PHP korzystający przecież z ograniczonego wachlarzu funkcji nie może zostać zablokowany - np. wyłączając te niektóre opcje.

[Tajfun]

No to weźmy przykład.

Masz forum na nie pamiętam jakim skrypcie niewykorzystującym MySQL. Jak wtedy zablokujesz w PHP funkcje takie jak np.: unlink() ?

Tajfun von Bruno

[Amfidiusz]

Ekhem.... Możemy trzymać się tematu, a mianowicie mojego serwera/skryptu/ustawień? Nic mi po funkcjach unlink, skoro nie mogę zmieniać ich ustawień. A zależy mi na optymalnym zabezpieczeniu się przed powtórką wczorajszego ataku.

[Tajfun]

@Amfidiusz, spokojnie, nie denerwuj się.

Może podczas dyskusji o unlink() wpadniemy na pomysł zabezpieczenia Twojego serwera?

Największe pomysly rodzą się przypadkiem

Tajfun von Bruno

[mlodszy]

Jeżeli nie masz jakiegoś większego rozgraniczenia to raczej nic nie zrobisz. Na przyszłość nie trzymaj rzeczy starych z dostępem.

Po 1 radzę projekty rozdzielać na różne katalogi.

Po 2 sądzę że różne konta FTP z różnymi użytkownikami to nie jest taki zły pomysł

Po 3 myślę że można zastanowić się nad czymś takim: http://www.php.net/manual/en/ini.core.php#ini.open-basedir

[Amfidiusz]

Po 1 radzę projekty rozdzielać na różne katalogi.

Nie wyobrażam sobie trzymać ich wszystkich w jednym katalogu

Dostałem odpowiedź z BOKu. Niestety, szablonową. Twierdzą, że to moja wina, bo wyciekło mi hasło, więc zalecają aktualizację firewalla, mimo że wyraźnie zaznaczyłem, że staram się być maksymalnie zabezpieczony pod tym względem Nie mówię, że nie mają racji, ale trochę mało profesjonalnie wygląda taka odpowiedź.

W każdym razie udostępnili mi logi. Umiecie z nich wyczytać coś więcej niż ja?

***;/home/klient.dhosting.pl/***/libraries/phputf8/index.html;9174;173.0.3.246;173.0.3.246;STOR;2010-10-24 22:46:30;0.925
***;/home/klient.dhosting.pl/***/libraries/joomla/installer/adapters/index.html;9174;173.0.3.246;173.0.3.246;STOR;2010-10-24 22:46:34;0.585
***;/home/klient.dhosting.pl/***/libraries/joomla/installer/index.html;9174;173.0.3.246;173.0.3.246;STOR;2010-10-24 22:46:35;0.870

Teraz muszę się upewnić, że mam czystego peceta. Dam znać co powiedzieli chłopaki od analizy logów OTL.

[DawPi]

Jak widać wbili nie przez IP.Board, a przez Joomlę, więc Ty najlepiej wiesz, jaką stronę masz na tym skrypcie - musieli ją jakoś wynaleźć, a potem złamać, a przy okazji wszystkie inne strony na FTP - pewnie z automatu poszła zmiana indexów.

[Amfidiusz]

dH twierdzi, że ewidentnie wykradli mi hasło i albo wirus sam się zalogował i pozmieniał indeksy, albo trojan przesłał hasło na inny komputer. FlashFXP jest na tyle popularny, że jest to prawdopodobne.

Ja obstawiam albo tę nieszczęsna joomlę (która już poleciała z serwera), albo bug w skrypcie z hostingiem obrazków (chociaż nie jest on zbyt znany, a atak wygląda na zabawę jakiegoś dzieciaka gotowymi exploitami). joomla jest także pierwsza w logach, chociaż nie wiem, czy to o czymś przesądza (zresztą wydaje mi się, że logi, które dostałem, były niepełne).

Anyway, i tak muszę się najpierw upewnić, że komputer mam czysty.

[Macsch15]

Twierdzą, że to moja wina, bo wyciekło mi hasło, więc zalecają aktualizację firewalla, mimo że wyraźnie zaznaczyłem, że staram się być maksymalnie zabezpieczony pod tym względem Nie mówię, że nie mają racji, ale trochę mało profesjonalnie wygląda taka odpowiedź.

To raczej standardowe stwierdzenie

[Amfidiusz]

Komputer czysty:

Na takiej zasadzie: Udowodnij, że nie jesteś wielbłądem.

W logu nie widać niczego podejrzanego.

dH nie chce współpracować. Pozostaje więc usunięcie joomli i nadzieja, że to ona była przyczyną włamania.

[mlodszy]

Hmpf. Widzę instalacje joomla, powiedz mi, ustawiłeś sobie ten katalog na jakieś 644 czy nawet 444? :>

[Amfidiusz]

Hmpf. Widzę instalacje joomla

Przeczytałeś w ogóle moje posty?

[mlodszy]

Tak, grzecznie poczytałem. Ale mimo to pozostawiam swoje pytanie odnośnie instalacji, bo nigdzie nie mówiłeś o poziomie dostępu do katalogu o którym mówię.

[Amfidiusz]

Były ustawione domyślne CHMODy.

[mlodszy]

Domyślne Chmody Cię nie bronią, po to w instrukcji mówią(chyba) żeby zmieniać, a może wręcz usuwać.

To teraz podaj mi jaką tam miałeś wersję to poszukam sobie chociaż jakie były możliwe opcje haków Może gdzieś w mojej bazie wiedzy opisali to

Widzisz @Amfidiusz - są tacy co niektóre wersje cmsów(różnych) niszczą w 5 minut z podaniem Ci zestawu loginów, haseł i paru innych.

Edytowane 27 Października 2010 przez mlodszy

[Amfidiusz]

Domyślne Chmody Cię nie bronią, po to w instrukcji mówią(chyba) żeby zmieniać, a może wręcz usuwać.

Jeżeli w instrukcji instalacji była wzmianka o zmianie CHMODów, to na pewno je zmieniłem

To teraz podaj mi jaką tam miałeś wersję to poszukam sobie chociaż jakie były możliwe opcje haków Może gdzieś w mojej bazie wiedzy opisali to

Na pewno 1.5. Końcówka chyba 9, może lekko więcej.

Widzisz @Amfidiusz - są tacy co niektóre wersje cmsów(różnych) niszczą w 5 minut z podaniem Ci zestawu loginów, haseł i paru innych.

Zdaję sobie z tego sprawę. Szczególnie w przypadku popularnych i darmowych skryptów, które są rozwijane amatorsko.

DawPi, problem wydaje mi się rozwiązany. Proszę o zamknięcie.