Всеки който се занимава професионално с web hosting знае каква заплаха представляват заразените потребители с malware, web shells etc. В обшият случей се използва maldet един не лош скрипт. Той се отличава с 3 неща

  1. Ужасно бавен е
  2. Ужасно бавен е и ако го пуснеш в мониторинг режим ще се изгаври със сървъра ти
  3. Поддържа собствена база данни с md5/hex дефиници за кофти код.

Точно последната му характеристика го прави полезен, тъй като освен всичко друго може да събмитваш файлове който не са били засечени досега и на по късен етап ще влязат в базите данни. Както споделих в точка 1 и 2 скоростта му е шокиращо ниска – при ниско натоварване на машината 70к файла се сканираха за около час и половина. Поради тази причина започнах да помагам на моя добър приятел ShadowX с malmon – алтернатива на maldet написана на python с малко по голяма гъвкавост. За съжаление от липса на време (основно но не само) не сме довършили проекта, който към момента не е много използваем – има доста бъгове които трябва да се изчистят. През изминалите дни имах проблеми с клиенти заразени с CryptoPHP които имаха огромни public_html файлове ~60к+ inod-а на потребител. Тъй като сумарно трябваше да се сканират над 200к файла което по груби сметки щеше да отнеме 5+ часа реших да тунинговам конфигурацията на maldet, за да намаля файловете които ще се сканират до някаква по разумна бройка и време. Докато чоплех конфа забелязах следните редове


# 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

Интересно… Явно има възможност да използва ClamAV – който също не се отличава с голямата си скорост но пък защо да не пробвам. На бързо го инсталирах


/scripts/update_local_rpm_versions --edit target_settings.clamav installed

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

Пускам maldet-а върху малка папка – не виждам разлика в скоростта и поведението – използваше си неговият perl-ски скенер вместо този на clamav. След кратко ровене из сорса на maldet открих следните редове

 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

Мдааа направих един which clamscan и за моя голяма изненада открих че clamav изобщо не е в PATH-a ами тъпият Cpanel го е оставил само в /usr/local/cpanel/3rdparty/bin/ от където той си използва бинарките. Един бърз ln реши проблема:

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

При повторно сканиране maldet вече горно съобщава

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

След като вече използва ClamAV maldet приключва сканирането си 3-4-5 пъти по бързо в сравнение с преди. Теста показа – 70к inod-а ги изтъркла за около 25 мин което си е около 3 пъти и половина по бързо в сравнение с преди.

Преди да почна с поредният random hate към 50 с’тинки OS искам да кажа, че ежедневно ми се налага да я администрирам и я познавам от първо лице единствено число доста добре. Днес отделих време за да изтествам новата магическа нечувана и невиждана функция за диструбитивен ъпгрейд (псевдо) 😀 . Първото нещо което ме изуми е, че RedHat в своята безкрайна мъдрост са решили да прекратят поддръжката на х86 архитектурата 🙄 . Напълно съм наясно че сме 2014-та година и сървърни процесори с  32 бита инструкции липсват отдавна. Мда ама какво правят потребителите на малки VPS-и  – х64 лапа повече рам, както и да го погледнеш ако имаш тънка виртуална машинка с 512МБ-1ГБ рам ще се бориш за всеки мегабай от нея и няма да прахосаш 20-30% от нея просто за да използваш по големият сет от инструкции. Препсувах тъй като си бях инсталил х86 CentOS и дръпнах един х64. Веднага видях разлика в ISO-тата – ~100MB при minimal 6.5. Препсувах още един път. Инсталирах си отново виртуалката като реших да видим RedHat колко добре са си свършили работата – изнесох /var и /usr на отделни LVM дялове 😈 . След инсталацията обнових всички пакети инсталирах си и apache, php, mysql и bind – беше интересно дали ще запалят сървисите. Отворих си като добра ученичка ръководството на CentOS за ъпдейта и започнах прилежно да го следва стъпка по стъпка. Когато стигнах до момента да започне реалното надграждане тая пумия ме изряза, че  имам критичен проблем 🙄 . Преглеждам детайлният изход – мдаааа /usr неможе да е на отделен дял 😆 знаех си, че няма да бъда разочарован от Jim Whitehurst и компания. Освен „екстремният“ проблем имаше доста съобщения за неподписани пакети, файлове за конфизи които не съответстват и прочие. WTF дори не бях ползват 3-ти хранилища всичко от техните огледала смъкнах не бях правил никакви настройки просто елементарен yum install. Вече всичко беше ясно затова съвсем безцеремонно форсирах upgrade. Рестартирах отново прилежно както ме подкани накрая скрипта и всичко приключи заради /usr дяла. Бях твърде мързелив, че се пробвам да го фиксна, така или иначе всичко беше само с научна цел няма как продуктов сървър да го надграждам към момента. Хванах преинсталирах си виртуалката като този път всичко си го набутах в 1 дял. Също си взех поука, никакви ъпдейти никакви допълнителни сървъси, след инсталацията директен ъпгрейд. На финалната стъпка отново изскочи досаният диалог който ми каза, че имам доста High проблеми – невалидни пакети, конфизи и прочие но може да продължи. Знаех си че по начало не ги правят както трябва нещата. Рестартирах отново и зачаках – о какво чудо ъпгрейда приключи успешно. И всичко работеше или поне зареждането на системата така и не пробвах да инсталирам допълнителни пакети, но halt командата си зависваше – хух все пак трябваше да има бъг 💡 . След тая цялата тарапана реших да инсталирам на чисто Centos 7 да видим дали ще ръмжи за /boot дял в LVM – 6.5 не позволява такава дързост. Стартирах си ISO-то и бях меко казано шокиран от инсталатора – всичко беше крайно не удобно „подредено“, напълно алогично с цел да е красиво. След известна борба успях със заветната цел и аха да се инсталира и гръмна, че трябва да си изнеса /boot-а извън LVM-a 👿 Това е крайно не сериозно и досадно, ако поради някаква причина забравиш да си увеличиш размера на boot дяла от 200МБ и понатрупаш стари ядра какво се случва.

В общи линии нищо не очаквах и пак съм разочарован от CentOS.

Колкото и да псувам RHEL и CentOS shit-а има някой неща които са им измислени доста грамотно. Например добавянето на голям брой допълнителни IP-та е доста приятна задачка. По принцип ако трябва да добавя голям брой адреси бих си разписал едно bash скриптче в което в цикъл да извършва въпросната операция че на ръка не си е работа. При Centos/RHEL хората са го измислили доста приятно range файл. В общи линии създаваме файл /etc/sysconfig/network-scripts/ifcfg-eth0-range0. Тук заменяме eth0 със името мрежовият адаптер ако не е eth0. След което добавяме следното съдържание

IPADDR_START=192.168.0.129
IPADDR_END=192.168.0.254
NETMASK=255.255.255.128
CLONENUM_START=0

като аргументите са

  • IPADDR_START – начален IP адрес
  • IPADDR_END – краен адрес
  • NETMASK – мрежова маска
  • CLONENUM_START – номерация от която да започнат мрежовите адаптер eth0:0 в нашият случай

 

В Centos-а е малко интересен в сетъпа на bridge адаптери. Приемам че вече е инсталиран bridge-utils пакета и eth0 (в това е в моя пример) е конфигуриран, така че нека да разгледаме основните стъпки

  1. Копираме настройките на eth0 в br0 (тук вече ако ви трябват друго именуване на адаптерите си го коригирате)
  2. Занествате записите за eth0 в конфигурационният файл на br0
  3. замествате типа на адаптера от Ethernet на Bridge
  4. Махате MAC адреса от br0 конфигурацията
  5. Задавате в eth0 конфигурацията че ще се имаме мостов адаптер br0

За да спестя време си го разписах като елементарно bash скриптче


cd /etc/sysconfig/network-scripts/
cp ifcfg-eth0 ifcfg-br0
sed -i 's/eth0/br0/' ifcfg-br0
sed -i 's/Ethernet/Bridge/' ifcfg-br0
sed -i '/HWADDR/d' ifcfg-br0
echo 'BRIDGE="br0"' >> ifcfg-eth0

Днес сутинрта започнах да си правя стандартния dist upgrade на един Debian сървър и Dovecot умря със следната грешка 🙂

[….] Starting IMAP/POP3 mail server: dovecotError: socket() failed: Address family not supported by protocol
Error: service(pop3-login): listen(::, 110) failed: Address family not supported by protocol
Error: socket() failed: Address family not supported by protocol
Error: service(pop3-login): listen(::, 995) failed: Address family not supported by protocol
Error: socket() failed: Address family not supported by protocol
Error: service(imap-login): listen(::, 143) failed: Address family not supported by protocol
Error: socket() failed: Address family not supported by protocol
Error: service(imap-login): listen(::, 993) failed: Address family not supported by protocol
Fatal: Failed to start listeners
failed!

 

Ако се загледате внимателно в нея грешката вади очите на човек  listen(::, 993) failed очевидно се опитва да слуша на ipv6 адрес който съм забранил 😈 . Решението е също толкова очевдино колкото и самата грешка – трябва да накараме dovecot да работи само на ipv4, което се постига с следният ред в /etc/dovecot/dovecot.conf
listen=0.0.0.0
След което удряме един бърз рестарт на Dovecot и всичко е по реда си и можем да продължим с дистрибутивният ъпгрейд