Każdy, kto profesjonalnie zajmuje się hostingiem, zna zagrożenie ze strony zainfekowanych użytkowników złośliwym oprogramowaniem, powłoki internetowe itp. W ogólnym przypadku jest używany maldet niezły skrypt. Wyróżnia się 3 rzeczy

  1. Jest strasznie powolny
  2. Jest strasznie powolny, a jeśli przełączysz go w tryb monitorowania, zadziała na twoim serwerze
  3. Obsługuje własną bazę danych z definicjami md5 / hex dla złego kodu.

Jest to jego ostatnia funkcja, która czyni ją użyteczną, ponieważ między innymi możesz przesyłać pliki, które nie zostały dotychczas wykryte i wejdą do baz danych na późniejszym etapie.. Jak już wspominałem 1 i 2 jego prędkość jest szokująco niska – przy niskim obciążeniu komputera, zeskanowano 70 000 plików w około półtorej godziny. Z tego powodu zacząłem pomagać mojemu przyjacielowi ShadowX malmon ( malmon ) – alternatywa dla maldeta napisanego w pythonie z nieco większą elastycznością. Niestety z braku czasu (głównie ale nie tylko) nie ukończyliśmy projektu, co obecnie nie jest zbyt użyteczne – istnieje wiele błędów, które należy usunąć. W ciągu ostatnich kilku dni miałem problemy z klientami zainfekowanymi CryptoPHP, którzy mieli ogromne pliki public_html ~ 60k + inod na użytkownika. Ponieważ w sumie trzeba było przeskanować ponad 200 000 plików, co z grubsza zabrałoby 5+ godziny postanowiłem dostroić konfigurację maldet, aby zredukować pliki, które będą skanowane do rozsądnej liczby i czasu. Gdy podniosłem conf, zauważyłem następujące wiersze

# Attempt to detect the presence of ClamAV clamscan binary
# and use as default scanner engine; up to four times faster
# scan performance and superior hex analysis. This option
# only uses ClamAV as the scanner engine, LMD signatures
# are still the basis for detecting threats.
# [ 0 = disabled, 1 = enabled; enabled by default ]
clamav_scan=1

Ciekawy… Najwyraźniej istnieje możliwość korzystania ClamAV – co również nie różni się dużą prędkością, ale dlaczego nie spróbować. Szybko to zainstalowałem

/scripts/update_local_rpm_versions --edit target_settings.clamav installed

/scripts/check_cpanel_rpms --fix --targets=clamav

Maldet uruchamiam na małym folderze – Nie widzę różnicy w szybkości i zachowaniu – użył skanera perla zamiast clamav. Po krótkim przejrzeniu źródła maldetu znalazłem następujące wiersze

 clamscan=`which clamscan 2> /dev/null`
 if [ -f "$clamscan" ] && [ "$clamav_scan" == "1" ]; then
        eout "{scan} found ClamAV clamscan binary, using as scanner engine..." 1
    for hit in `$clamscan -d $inspath/sigs/rfxn.ndb -d $inspath/sigs/rfxn.hdb $clamav_db -r --infected --no-summary -f $find_results 2> /dev/null | tr -d ':' | sed 's/.UNOFFICIAL//' | awk '{print$2":"$1}'`; do

Hmmm, zrobiłem jeden który clamscan i ku mojemu wielkiemu zdziwieniu odkryłem, że clamav wcale nie jest w ŚCIEŻCE, ale głupi Cpanel zostawił go tylko w / usr / local / cpanel / 3rdparty / bin /, z którego używa swoich plików binarnych. Szybkie rozwiązanie problemu:

ln -s /usr/local/cpanel/3rdparty/bin/clamscan /usr/bin/clamscan

Podczas ponownego skanowania Maldet już zgłasza powyższe

{scan} found ClamAV clamscan binary, using as scanner engine...

Po użyciu maldetu ClamAV kończy skanowanie 3-4-5 razy szybciej niż wcześniej. Test wykazał – 70k inod-a przetarł je przez około 25 min, co jest około 3 półtora razy szybciej niż wcześniej.