Тъй като от netenberg изобщо не оправдаха очакванията ми за fantastico 3 та реших да го разкарам тоталка. Въпреки кореспонденцията която водихме преди много време и насоките които им дадох за подобряване на продукта им до конкурентно способно ниво на softaculous и installatron се стигна до момента в който трябваше да бъде деинсталиран техният плъгин от Cpanel сървърите ми. Тъй като няма инструкции как се премахва това недоразумения вдигнах тикет на support-а те ми дадоха следните инструкции.

rm -rf /var/netenberg/fantastico_de_luxe/
rm -rf /usr/local/cpanel/whostmgr/docroot/cgi/fantastico/
rm -rf /usr/local/cpanel/3rdparty/fantastico*
rm -rf /usr/local/cpanel/base/frontend/*/fantastico
rm -f /usr/local/cpanel/base/frontend/x/cells/fantastico.html
rm -f /usr/local/cpanel/whostmgr/docroot/cgi/addon_fantastico.cgi

Изпълних си командите за чистиха се файловете им като осъзнах нещо важно пичовете изобщо не споменаха как се де регистрира плъгина им от контролният панел 🙄  😆 Мдаа педераски номер но се случва то и аз трябваше да гледам повече. Също така имаше останала една камара техни файлове явно се надяват да се върна като техен клиент, тъй като имали най много скриптове за инсталация както каза съпорт (не думай това е най важното направо) :mrgreen: . Та нека да продължим с пълното изкормване:

Това е най важната стъпка която трябва да се направи преди да затриете всичко останало тъй като после ще се окажете бе плъгин но с икона в контролния панел тъй като все е още е регистриран.

/usr/local/cpanel/bin/unregister_cpanelplugin /var/netenberg/fantastico_f3/fantastico_f3
rm -rf /usr/local/cpanel/3rdparty/fantastico_f3
rm -rf /usr/local/cpanel/base/frontend/*/fantastico_f3
rm -rf /usr/local/cpanel/bin/fantastico_f3.cpanelplugin
rm -rf /usr/local/cpanel/whostmgr/addonfeatures/fantastico_f3
rm -rf /usr/local/cpanel/whostmgr/addonsfeatures/fantastico_f3
rm -rf /usr/local/cpanel/whostmgr/docroot/addon_plugins/fantastico_f3.jpg
rm -rf /usr/local/cpanel/whostmgr/docroot/cgi/addon_fantastico_f3.php
rm -rf /usr/local/cpanel/whostmgr/docroot/cgi/fantastico_f3
rm -rf /var/cpanel/apps/fantastico_f3_cpanel.conf
rm -rf /var/cpanel/apps/fantastico_f3_whm.conf
rm -rf /var/netenberg/fantastico_f3

В случей че сте пропуснали стъпката unregister_cpanelplugi се налага да се играе още една допълнителна стъпка:

mkdir --parents /var/netenberg/fantastico_f3
cd /var/netenberg/fantastico_f3 && curl -O http://174.120.165.106/fantastico_f3/sources.tar.bz2
cd /var/netenberg/fantastico_f3 && tar --bzip2 --extract --file sources.tar.bz2
/usr/local/cpanel/bin/unregister_cpanelplugin  fantastico_f3
rm -rf /var/netenberg/

Воала вече fantastico е извън играта и можете да спите спокойно. Причините поради които го смених с конкурентен продукт са 3 и то много семпли

  • Нямат API с което мога да си комуникирам ако искам да правя допълнения или някакви други магии
  • нямат hooks при определени действия да мога да се закачам и да дописвам функционалност
  • кофти support доста бавен и не много адекватен в отговорите си

ps. paper_lantern и x3 имаше останала икона която се разкарва с

rm  /usr/local/cpanel/base/frontend/paper_lantern/dynamicui/dynamicui_fantastico_f3.conf
rm /usr/local/cpanel/base/frontend/x3/dynamicui/dynamicui_fantastico_f3.conf

Всеки който се занимава професионално с 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 пъти и половина по бързо в сравнение с преди.

Днес реших да направя няколко теста върху чиста 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 не са изплзвали подобно решение за множество файлове.

Търсенето в Linux на файлове като цяло си е доста лесно с командата find която разполага с вградени инструменти намирането на файлове по големи от определен размер например:


find / -type f -size +10M

По горният пример ще ни намери всички файлове по големи от определен размер което до някъде е приемливо но нас като цяло ни интересува целият път на файлът отделно че ако опитате по горният пример, ще получите доста съобщения за грешки заради проблеми с достъпа или файлове забранени за четене. В общи линии решаването на съответните 2 проблема става лесно с допълването на по горната команда по следният начин:

find / -type f -size +10M -exec ls -lh {} \; 2> /dev/null | awk '{ print $NF ": " $5 }'

 

 

/dev/random

Имах една доста интересна закачка закачка – трябваше да създам огромен брой случайно генерирани пароли като имах изискване да са с определена дължина да съдържат големи малки букви и цифри, нормални неща. Звучи лесно нали и в общи линии е. Използвах /dev/urandom за оснонвата генерация и след това с един кратък конвейер филтрирах до желания брой знаци и видове знаци които трябва да се използват. Стига съм увъртал в основната скрипта е конвейера :

cat /dev/urandom | tr -dc '[:alnum:]' | fold -w 20| head -n 1

Така нека да разгледаме малко по подробно какво се случва тука. Взимаме изхода на cat /dev/urandom. След това го филтрираме да се показват само малки, големи букви и цифри. След това с fold ограничаваме дължината на низовете до желания от нас брой. Накрая лимитираме да се показва само 1 ред от целия изход. В общи линии лесно като 1-2-3. Ако искате да повишите сложността на паролата и със специалените символи в регуляярни израз на tr може да се използва :graph: или :print: вместо :alnum:, които включват всички символи без или със space.

cat /dev/urandom | tr -dc '[:graph:]' | fold -w 20 | head -n 1
Enhanced by Zemanta