Всеки който се занимава професионално с 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 – Ami szintén nem különbözteti meg a nagy sebesség, de miért nem próbálja. A gyors telepítettem

/scripts/update_local_rpm_versions --edit target_settings.clamav installed

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

A Maldet egy kis mappán fut – Nem látok különbséget a sebesség ben és a viselkedésben – A Perl-ski szkennerét használta clamav helyett.. Miután egy rövid ásás át a Maldet fajta, megtaláltam a következő sorokat

 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

Csináltam egyet. Melyik Clamscan És az én nagy meglepetés rájöttem, hogy ClamAV egyáltalán nem path-a jól a hülye Cpanel hagyta, hogy csak a / usr / helyi / rész / 3rdparty / ahonnan használja a bicarks. Egy gyors b-ben oldja meg a problémát:

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

Az újraszkennelés során a Maldet már

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

A ClamAV Maldet használata után befejezi a 3-4-5 Az idő gyorsabb, mint korábban. A vizsgálat azt mutatta, – 70K Inod-A esett őket körülbelül 25 Min, amely körül 3 És fél gyorsabb, mint korábban..

Mielőtt elkezdenék egy másik véletlenszerű gyűlölet 50 A ' Tinky OS úgy értem, че ежедневно ми се налага да я администрирам и я познавам от първо лице единствено число доста добре. Днес отделих време за да изтествам новата магическа нечувана и невиждана функция за диструбитивен ъпгрейд (псевдо) 😀 . Първото нещо което ме изуми е, че 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: dovecotHiba: Aljzat() Nem sikerült: A protokoll által nem támogatott címcsalád
Error: service(pop3-login): listen(::, 110) Nem sikerült: A protokoll által nem támogatott címcsalád
Error: Aljzat() Nem sikerült: A protokoll által nem támogatott címcsalád
Error: service(pop3-login): listen(::, 995) Nem sikerült: A protokoll által nem támogatott címcsalád
Error: Aljzat() Nem sikerült: A protokoll által nem támogatott címcsalád
Error: service(imap-login): listen(::, 143) Nem sikerült: A protokoll által nem támogatott címcsalád
Error: Aljzat() Nem sikerült: A protokoll által nem támogatott címcsalád
Error: service(imap-login): listen(::, 993) Nem sikerült: A protokoll által nem támogatott címcsalád
Fatal: Failed to start listeners
Nem sikerült!

 

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