Zabezpieczenie serwera przed

[ubunciak]

Mamy taki problem, że poprzez dziurawe oprogramowanie klientów (prym wiedzie OsCommerce) jacyś kretyni wrzucają śmieci typu C99shell.

• W php.ini poblokowaliśmy disabled_functions,
• php chodzi na suexec suPHP,
• open_basedir oczywiście zawężony tylko do katalogu użytkownika

Co mimo wszystko znowu pozwoliło komuś na odczytanie /etc/httpd/conf/httpd.conf i dopisanie jakiegoś śmiecia. Prawdę mówiąc nie mam pojęcia jak - bawiłem się tym C99 i za ,,cukierka'' nie dało się odczytać zawartości katalogu jak i samej konfiguracji.

Macie sugestie co jeszcze zrobić aby przyblokować te śmieci?

• mod_security - strasznie obciąża serwer, a poza tym to też półśrodek
• pewnie trzeba by coś też z /tmp zrobić
• Ale jak ktoś mógł jeszcze odczytać ten konfig?

[ionicDC]

Jeśli masz uruchamiane php z prawami użytkownika i open_basedir to nie jest możliwe by z poziomu wirtualki ktoś się dostał do /etc/ - albo dziura jest w innym miejscu albo jest jakaś niewycięta funkcja.
/tmp zrób w trybie no_exec. Czy Twoi użytkownicy mają dostęp do powłoki?

[ubunciak]

/tmp - jest noexec, nawet nie zauważyłem.
Nie ma powłoki dla ludzi.
Wycięte funkcje: exec, system, passthru, shell_exec, ini_alter, popen, show_source, proc_nice, proc_terminate, proc_get_status, proc_close, pfsockopen, leak, apache_child_terminate, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, dl, symlink, escapeshellarg, escapeshellcmd, proc_close, proc_open.
Facet wrzucił jakiś syf poprzez oscommerce (google79868768767.php), następnie zaczął grzebać w powłoce ale co nie wiem, przesyłane to było przez POST, więc w logach jest tylko wywołanie skryptu.

Facet wrzucił jakiś syf poprzez oscommerce (google79868768767.php), następnie zaczął grzebać w powłoce ale co nie wiem, przesyłane to było przez POST, więc w logach jest tylko wywołanie skryptu.
W /tmp/ znalazłem zrobiony przez tego użytkownika katalog, a w nim kopię httpd.conf no i w /etc/ dopisał co chciał.

Admin też twierdzi, że wszystko gra, no ale jak gra skoro nie gra.

[shyte]

Kod: Zaznacz cały

load_file, show_source, passthru, popen, proc_open, disk_free_space, diskfreespace, leak, tmpfile, escapeshellcmd, php_uname, putenv, getmyuid, leak, listen, diskfreespace, tmpfile, link, ignore_user_abord, dl, highlight_file, source,fpaththru, virtual, posix_ctermid, posix_getcwd, posix_getegid, posix_geteuid, posix_getgid, posix_getgrgid, posix_getgrnam,posix_getgroups, posix_getlogin, posix_getpgid, posix_getpgrp, posix_getpid, posix_getppid, posix_getpwnam, posix_getpwuid, posix_getrlimit,posix_getsid, posix_getuid, posix_isatty, posix_kill, posix_mkfifo, posix_setegid, posix_seteuid, posix_setgid, posix_setpgid, posix_setsid,posix_setuid, posix_times, posix_ttyname, posix_uname, proc_open, proc_close, proc_get_status, proc_nice, proc_terminate,openssl_csr_export_to_file, openssl_csr_export, openssl_csr_new, openssl_csr_sign, openssl_error_string, openssl_free_key,openssl_get_privatekey, openssl_get_publickey, openssl_open, openssl_pkcs7_decrypt, openssl_pkcs7_encrypt, openssl_pkcs7_sign,openssl_pkcs7_verify, openssl_pkey_export_to_file, openssl_pkey_export, openssl_pkey_free, openssl_pkey_get_private,openssl_pkey_get_public, openssl_pkey_new, openssl_private_decrypt, openssl_private_encrypt, openssl_public_decrypt,openssl_public_encrypt, openssl_seal, openssl_sign, openssl_verify, openssl_x509_check_private_key, openssl_x509_checkpurpose,openssl_x509_export_to_file, openssl_x509_export, openssl_x509_free, openssl_x509_parse, openssl_x509_read, curl_version, ftp_fput,disk_total_space, getrusage, fileowner, filegroup, system, exec, shell_exec, shell, symlink, readdir, opendir, dir, disktotalspace

To powinno załatwić sprawę.
U mnie tak mam i za pomocą takich badziewi jak c99, nie można odczytać żadnych plików ani katalogów.

[ubunciak]

Niestety nie załatwiło, coś permanentnie dopisuje do php.ini linijkę z wczytywaniem jakiegoś śmiecia, który umieszcza w jednym z katalogów. Szczerze mówiąc kończą mi się pomysły gdzie jest ta dziura, coraz mniej pomysłów.

Co dziwniejsze php.ini ma prawa root/root a data modyfikacji jest sprzed kilku dni co jest ewidentną nieprawdą. Nie wiem jak można edytować plik żeby jego data się nie zmieniła? Nie wiem gdzie jeszcze wyśledzić co za syf mi to robi.

[grzesiek]

Zobacz co jest uruchomione

Kod: Zaznacz cały

pstree -pca

[ubunciak]

Nie ma nic podejrzanego. To musi być szybka akcja przez www/php choć nie wiem jak zważając na te suphp i blokowanie wszystkiego.

[Bastian]

Jestes pewnien, że w ogóle wykorzystuje php do ataków? Może to exploity jakiejś innej usługi?

[ubunciak]

Nie jestem pewien. Tak mi się tylko wydaje. Wcześniej na bank było przez www/php (dziura w oscommerce) oraz znalazłem tego C99. Potem zablokowałem wszystko j.w. ale problem nie zniknął. Gdybym jakimś oprogramowaniem mógł dociec kto i jak dopisuje śmieci do php.ini to by było łatwiej. A tak to ciężko znaleźć cokolwiek w logach.

[Bastian]

Trzeba by zacząć od tego co raportuje rkhunter albo chkrootkit, a następnie:

Kod: Zaznacz cały

netstat -lap

zeby przekonać się co tak naprawdę udostępnia Twój serwer. Do tego

Kod: Zaznacz cały

iptables -L

a potem jeszcze nmapem sprawdzić co się da wyciągnąć z Twojego serwera. Wersje oprogramowania na serwerze są uaktualniane?