Всеки който се занимава професионално с 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 в нашият случай

 

По подразбиране когато си инсталирате Munin в Cpanel липсват няколко благи конфига които трябва да си ги направим на ръка. За мен един от тях е мониторинга на температурата  на дисковете.

В общи линии конфигурацията е тривиална

1. Трябва да определим типа на нашите дискове – той може да бъде един от следните : ata, scsi, sat[,auto][,N][+TYPE], usbcypress[,X], usbjmicron[,x][,N], usbsunplus, marvell, areca,N/E, 3ware,N, hpt,L/M/N, megaraid,N, cciss,N, auto, test. Най лесният начин за това е чрез cat на „/proc/ide“ или „/proc/scsi“. При мен:


# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: WDC WD1003FBYZ-0 Rev: 01.0
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: WDC WD1003FBYX-0 Rev: 01.0
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi4 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: TOSHIBA DT01ACA1 Rev: MS2O
  Type:   Direct-Access                    ANSI  SCSI revision: 05

 

 

Както се вижда имам 3 диска тип ATA.

2. За да почнем да следим температурата трябва да опишем в munin node дисковете ни. В файла /etc/munin/plugin-conf.d/hddtemp_smartctl добавяте записи от следният тип


# cat /etc/munin/plugin-conf.d/hddtemp_smartctl
[hddtemp_smartctl]
user root
env.drives sda sdb
env.args_sda -d ata
env.args_sdb -d ata

 

Можем да ударим тест на нашият бъдещ конфиг по следният начин


# env drives="sda sdb sdc" args_sda="-d ata" args_sdb="-d ata" args_sdc="-d ata"  /etc/munin/plugins/hddtemp_smartctl
sda.value 32
sdb.value 33
sdc.value 33

 

Ако получите стойности значи всичко е ок. Ако получите грешка трябва да проверите дали всичко правилно описано. Следва да рестартирате munin nod-а ви и да изчакте 10-15 мин да се популират малко данни и да почне да се чертае графика. Можете да проверите /var/log/munin/munin-node.log за грешки и по лесното им отстраняване.

Ако искате да получавате email при критична температура на дисковете трябва да добавите описание за критична такава:

[example.com]
    address 127.0.0.1
    use_node_name yes
    hddtemp_smartctl.sda.critical 55
    hddtemp_smartctl.sdb.critical 55

Днес реших да направя няколко теста върху чиста Cpanel инсталация за която имах необходимост от няколко потребителя. Тъй като не исках да натоварвам работещите сървъри с пакетиране архивиране и трансфер на файловете използвах архивите от предишната вечер. Трансферирах си всички архиви в /home и установих че Cpanel не предлага възстановяването на повече 1 акаунт едновременно както през GUI така и през CLI. През GUI тъй като нямаше как да се получи номера реших да се изхитря с cli скрипта restorepkg. Използването му е безкрайно просто

/scripts/restorepkg username.tar.gz

Като действието се повтаря за всеки потребител по отделно. При опит да използвам * вместо името на потребителя скрипта деректно ме отряза затова трябва да се подходи малко по елегантно –


archives=$(ls /home/ | grep tar.gz)

for archive in $archives

do

/scripts/restorepkg --force $archive

done

Сега бързо обяснение. Правим си списък с всички архиви и го блъскаме в променливата archives след това обхождаме списъка елемент по елемент като стартираме разпакетирането за всеки архив по отделно. Нищо кой знае колко сложно интересно защо пичовете от Cpanel не са изплзвали подобно решение за множество файлове.