W TRAKCIE Ochrona CMSów Joomla/Wordpress przed wrzutkami plików z zawartością base64_decode i eval?

Witam,
Napotkałem się (nie ja pierwszy zapewne) z problemem uporczywego infekowania CMSów Joomla i Wordpress. W dniu wczorajszym przy zabawie na serwerze innego usługodawcy zauważyłem że podczas uploadu plików Wordpressa serwer FTP odmówił zapisania zainfekowanych plików z zawartością base54_decode i eval. Bardzo pozytywnie mnie to zaskoczyło. Czy planujecie wprowadzić podobne zabezpieczenie uniemożliwiające nieautoryzowanemu umieszczaniu takich plików na waszych serwerach?

 

@yakusa witaj na naszym forum

W sprawie blokady zainfekowanych plików na serwerach w home.pl, to posiadamy bardzo podobne rozwiązanie. Wszystkie pliki wysyłane na serwer FTP w home.pl, skanowane są w poszukiwaniu wirusów oraz innego złośliwego oprogramowania. Podczas wysyłania zainfekowanych plików na serwer FTP wyświetlany jest poniższy komunikat błędu:

Code:

426 File Infected

Przesłanie oznaczonego w ten sposób pliku na serwer FTP jest niemożliwe. Oznaczony w ten sposób plik zostanie pominięty podczas przesyłania go na serwer FTP.

Więcej informacji: https://pomoc.home.pl/baza-wiedzy/blokada-zainfekowanych-plikow-podczas-wysylki-na-serwer-ftp/

 

Aż sprawdzę zaraz w działaniu tego ficzersa
Ale powstaje pytanie czy istnieje jakiś sposób aby ta sama funkcjonalność blokowała próby "wrzutu" takiego pliku na serwer?

 

Wspomniana w artykule funkcjonalność obejmuję tylko protokół FTP, w sprawie jak to nazwałeś "wrzutów" plików na serwer, to przyczyną najczęściej są niezaktualizowane aplikacje znajdujące się na serwerze (tak zwane dziury w skryptach). Serwery w home.pl są odpowiednio zabezpieczone przed złośliwym oprogramowaniem. Zawartość serwerów jest na bieżąco skanowana w poszukiwaniu zainfekowanych i niebezpiecznych plików.

 

Zarówno funkcje eval() jak i base64_decode() są pełnoprawnymi funkcjami php i np. w kodzie plików CMS Joomla znajdzie się sporo skryptów wywołujących te funkcje. Nie ma więc jasno wskazanej informacji aby te pliki były niebezpieczne, gdyż mogą to być np. pliki poczty.

Podejrzane mogą być pliki, gdzie na początku lub na końcu pliku pojawia się nowy tag zaczynający skrypt php zawierający w sobie połączenie eval i base64_decode z zadeklarowaną już treścią w base64. W ten sposób złośliwe roboty/skrypty ułatwiają sobie działanie.

 

Z Joomlą nie pomogę, ale jeśli posiada Pan Wordpressa, proponuje instalacje i konfiguracje wtyczki All In One WP Security, której odpowiednia konfiguracja znacząco podnosi bezpieczeństwo naszego cms, także przed atakami, o których Pan wspomniał.

ps. Jeśli interesuje Pana głębiej problem bezpieczeństwa i zabezpieczeń stron, proponuję także zapoznać się z usługą CloudFlare, szczególnie jeśli chodzi o ataki Bruteforce ale nie tylko

Co do funkcji eval, to jest ona potencjalnie niebezpieczna i jeśli Pana skrypty z niej korzystają proponuję z nich zrezygnować na rzecz innych bądź samemu przerobić dany kawałek kodu jeśli pozwalają umiejętności, aby z eval nie korzystać

inne funkcje oprócz eval(), które są w stanie wykonać zdalnie kod (potencjalnie niebezpieczny) to:

exec()
passhtru()
shell_exec()
popen()
proc_open()
pcntl_exec()
assert()
preg_replace()
create_function()

Nieprawidłowe zastosowanie tych funkcji w naszej aplikacji naraża ja na ataki tzw backdoor, czyli z jakimi Pan się próbuje obecnie zmierzyć. Oczywiście metod potencjalnych ataków jest dużo więcej, stąd bardzo ważna jest dbalość o podstawowe zasady bezpieczeństwa jak chociażby prawidłowe prawa naszych plików na serwerze. Wspomniana przeze mnie wtyczka jest wstanie to na nas wymusić, bądź poinformować nas o tym co tez powinniśmy zmienić bądź poprawić.

 

Niestety w sieci wiele osób używa gotowych skryptów które niekoniecznie są pisane w sposób bezpieczny, dlatego tak często dochodzi do takich sytuacji. Mając darmowe rozwiązania musimy się niestety z takimi sytuacjami liczyć mimo, że jest kilka sposobów na teoretyczne zabezpieczenie się przed nimi.

 

Ma Pan rację jednak nawet mając odpowiednie umiejętności, ciężko zawsze samemu pisać daną wtyczkę, a już tym bardziej CMS Jeżeli chodzi o Wordpressa proponuję zawsze instalować wtyczki umieszczane na ich stronach i nie instalować dodatków z zewnętrznych źródeł. Nie daje nam to 100% pewności, ze są to skrypty 100% bezpieczne ale zwiększa nam to znacznie pewność, że jednak są Unikał bym także wszelkich modyfikacji wtyczek przez innych użytkowników (ostatnio jest to dość popularne) gdzie istnieje prawdopodobieństwo, ze jedyna modyfikacją jest wstrzyknięcie tam potencjalnie niebezpiecznego kodu :]