Polskie Forum Użytkowników Debiana

Zwracam się do Was z prośbą o pomoc w rozgryzieniu zagadki włamania na mój serwer FTP (vsftpd). Pomoże mi (i pewnie nie tylko) lepiej zabezpieczyć system.
Zwracam się z prośbą nie tylko do guru systemu Debiana lecz także do znawców innej sztuki tajemnej.

A o co chodzi...
Wczoraj jakiś koleś po FTP bez logowania najpierw pobrał wszystkie pliki index.xxx, dodał linijkę: a następnie ponownie je wrzucił na serwer. Zaznaczam - wszystko bez logowania do serwera FTP!
Na szczęście nie narobił szkód, gdyż konto użytkownika ftp służy mi tylko do wstępnego wrzucania plików, które później już po ssh są przenoszone dalej, choć z uprawnieniami tego użytkownika. Zainfekował jedynie pliki, które stanowiły kopię starych witryn lub wersji roboczych, których na wszelki wypadek nie usuwałem (apache nie ma dostępu do tych plików).
Jak zapewne nietrudno się domyśleć, link wskazywał na zainfekowany serwer. Co ciekawe komenda dig pokazuje zawsze 5 IP, a na każdym z nich Linux, głównie Debian. Na porcie w linku zawsze jest aktywny nginx.

Moje pytanie: jak on to zrobił?
Szukałem różnych exploitów na vsftpd ale żaden nie zadziałał.
Druga możliwość to wykorzystanie, którejś strony i hack na apache (wskazuje na to użytkownik, na którego konto nastąpił atak).

Serwer chroni fail2ban oraz firewall zrealizowany na iptables. Po za głównymi konfiguracjami kernela są właściwie tylko 2 grupy reguł. Zezwolenia nawiązania połączeń na określonych portach z netu oraz druga zezwolenia wyjścia co odpowiada określonym usługom na serwerze plus zezwolenie połączeń established i related. Jeśli tak, to gdzie szukać śladów? Gość był sprytny. Każdy plik pobierał i wgrywał ponownie z innego IP.

Jeśli ktoś ma jakieś sugestie - będę wdzięczny. Pomoże mi to lepiej zabezpieczyć serwer

Tutaj podobny przypadek i wyjaśnienie.
Ostatnio miałem taką samą sytuację na jednej ze stron; zmieniłem hasło na ftp i nie zapisuję go w programie (męczące, ale jak pamięć wyrabia) i od tego czasu w miarę spokój.
Tyle z mojej strony, więcej nie wiem.

Bardzo ciekawy przypadek. Napisz tego posta na uw-team.org (bardzo dobre forum w dziedzinie security). Miałem podobne przypadki zmiany treści zawartości strony na hostingu od cba.pl, i też nie wiem jak intruz tego dokonał (zapewne jest to możliwe tylko w przypadku posiadania konta na tym samym serwerze). Taka wiedza pozwoliła by lepiej zabezpieczyć serwer. Pozdrawiam

W tej sytuacji bardzo pomocne byly by jakies logi.
Zazwyczaj nie kompromituje sie serwerów ftp ani apache tym bardziej ssh.

W logach sprawdz sobie anomalie z jakiego adresu zostaly wprowadzone zmiany.
Najprawdopodobniej masz dziure w samym kodzie strony zezwalacjaca na atak LFI (Remote file include), w ten sposob atakujacy jest ewentualnie wstanie podmienic lub dodac jakies pliki nie logujac sie w ogóle do twojego serwera. Jak juz kolega dodal ludziska na uw-team moga ci pomoc ale malo ci powiedza bez dokladnych logow.
Jezeli potrzebujesz jakies konkretnej pomocy tu masz link do blogu jednego z zalozycieli i wlascicieli Devil Team, strona niestety w budowie ale...
link

Co teraz powinienes zrobic to zamknac serwis www na dzien lub dwa, zachowac wszystie logi z dnia ataku i kilku poprzednich, skopiowac dane zainfekowane (najlepiej cala strone i reszte plikow wykorzystywanych do ich obslugi) i przywrocic strone z kopii zapasowej.

jaqbeu, dziękuję za szczere chęci lecz to nie jest podobny przypadek.
Serwer nie linkuje do katalogu /home, konto użytkownika, jest odseparowane od serwera Apache. To konto pośrednie, na które dokonuję wrzucenia plików serwisów firmowych, a z niego dopiero po ssh do właściwego katalogu (chodzi o odseparowanie serwisów firmy od stron użytkowników). Choć na serwerze są inne konta, są to wyłącznie konta ftp (powłoka: /bin/false). PHP jest tak ustawione, że każdy użytkownik ma własny katalog /tmp ze swoimi uprawnieniami, natomiast użytkownik, na którego konto dokonano włamania nie ma takiego katalogu. Nie jest też w virtual host. Konto, na które dokonano włamania jest kontem pośrednim. Pliki, które zmieniono nie są wyświetlane i brak do nich dostępu (jedynie jako root po zalogowaniu przez ssh lub bezpośrednio po ftp).
Po głębszym zastanowieniu był to jakiś exploit na vsftpd, który umożliwił wejście bez konieczności logowania na konto użytkownika o UID 1000 czyli pierwszego jaki zostaje zainicjowany w trakcie instalacji systemu.

bagsiur, szpuni, Dzięki za linki. Na pewno z nich skorzystam.