Enigiemand wat handel professioneel met web hosting weet wat die bedreiging verteenwoordig besmet gebruikers wat met hierdie malware, web skulpe ens. In obset hier gebruik maldet een slegte script. Dit verskil 3 dinge

  1. Vreeslik stadig
  2. Regtig stadig en as jy dit laat gaan in monitor af sal, shauri server wat jy
  3. Hou sy eie databasis met die md5/hex, definitiewe slegte kode.

Dit is die laasgenoemde funksie maak dit nuttig, want onder ander dinge, kan symitar lêers wat nog nie ontdek is so ver en op'n later stadium sal kry in die databasis. As gedeel in die punt 1 en 2 sy spoed is skokkend laag – by lae las op die motor 70K lêer geskandeer vir'n uur en'n half. Vir hierdie rede, het ek begin om te help om my goeie vriend, ShadowX met Malmö – alternatiewe maldet geskryf in python met'n bietjie van buigsaamheid. Ongelukkig, as gevolg van'n gebrek van die tyd (meestal, maar nie net) ons doen nie dovrsili projek, wat is tans nie baie nuttig – daar is nogal'n baie van die foute om skoon te maak. Oor die afgelope paar dae het ek het probleme gehad met kliënte besmet is met CryptoPHP wat'n groot public_html lêers ~60K+ inod-gebruiker. So in samewerking moes word nagegaan op 200k lêer wat groot rekeninge sal dit neem 5+ uur het ek besluit tuningova opset maldet, om te verminder die lêers wat sal nagegaan word in'n meer redelike plek en tyd. Terwyl die kies van konfa opgemerk die volgende lyne

# 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

Interessant… Natuurlik, dit is moontlik om te gebruik ClamAV – wat is nie'n hoë spoed, maar nie hoekom nie om te probeer. Vinnig ek stel

/scripts/update_local_rpm_versions --edit target_settings.clamav installed

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

Vrylating maldet-'n klein gids – Ek sien geen verskil in spoed en gedrag – gebruik dit perl-ish skandeerder plaas vir clamav. Na'n kort grawe in die kode maldet ek het gevind dat die volgende lyne

 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

Mdaaa, ek het een wat 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 пъти и половина по бързо в сравнение с преди.

Voor ek begin met'n ander ewekansige % % 50 ’tinky OS ek bedoel, elke dag het ek het haar administrasie, en weet dat dit van die eerste persoon enkelvoud is redelik goed. Vandag het ek het die tyd om te estestven nuwe magie sechuana en nog nooit tevore gesien funksies te werk distrubition (pseudo) 😀 . Die eerste ding wat my opgeval het, was dit, dat RedHat in hul oneindige wysheid besluit om te staak hierdie diens x86 argitektuur 🙄 . Напълно съм наясно че сме 2014-та година и сървърни процесори с 32 bietjie van die gebruiker ontbreek vir'n lang tyd. Мда ама какво правят потребителите на малки VPS-и – 64-bietjie meer RAM kloue, as jy kyk na dit, as jy het'n dun virtuele trimmer met 512MB-1GB ram sal veg vir elke megaball van haar en nie voorstel 20-30% dit is om te gebruik'n groot stel van instruksies. Prasowej sedert ek installeer x86 CentOS en lig een 64-bit. Ek het gesien die verskil in die ISO-oktaan – ~100MB minimum 6.5. Prasowej een meer tyd. Ek het dit geïnstalleer weer virtualita, het ek besluit om te sien RedHat, hoe goed het die werk – Ek het /var en /usr op'n aparte LVM mure 😈 . Na die installasie ek opgedateer al die pakkette ek het geïnstalleer en apache, php, mysql en bind – het gewonder of om die lig van sylvinite. Ek het dit soos'n goeie meisie gids tot CentOS vir die opgradering en begin getrou aan sy behoeftes stap vir stap. Toe ek by die punt om te begin om die werklike gradeer hierdie pumie my izraza, че имам критичен проблем 🙄 . "Die bees het gesê uitset – mdaaaa /usr is nie'n aparte afdeling 😆 ek geweet het, dit sal nie teleurgesteld wees Jim Whitehurst en maatskappy. In bykomend “een van die” die probleem is, was daar nogal'n baie van die boodskappe oor unsigned pakkette, lêers vir confidi wat nie ooreenstem met, en so aan. WTF was nie eens in die guns van'n 3de bron van al hul spieëls Smirna het nie enige instellings, net die basiese yum installeer. Alles was duidelik, so duidelik forsarah op te gradeer. Herlaai weer gehoorsaam as ek gevra word, ten slotte, die skrif, en dit eindig as gevolg van die /usr partisie. Ek is te lui, wat om te probeer om te fiksna, така или иначе всичко беше само с научна цел няма как продуктов сървър да го надграждам към момента. Хванах преинсталирах си виртуалката като този път всичко си го набутах в 1 дял. Също си взех поука, никакви ъпдейти никакви допълнителни сървъси, след инсталацията директен ъпгрейд. На финалната стъпка отново изскочи досаният диалог който ми каза, че имам доста High проблеминевалидни пакети, конфизи и прочие но може да продължи. Знаех си че по начало не ги правят както трябва нещата. Рестартирах отново и зачакахо какво чудо ъпгрейда приключи успешно. И всичко работеше или поне зареждането на системата така и не пробвах да инсталирам допълнителни пакети, но halt командата си зависвашехух все пак трябваше да има бъг 💡 . След тая цялата тарапана реших да инсталирам на чисто Centos 7 да видим дали ще ръмжи за /boot дял в LVM – 6.5 не позволява такава дързост. Стартирах си ISO-то и бях меко казано шокиран от инсталаторавсичко беше крайно не удобноподредено”, напълно алогично с цел да е красиво. Na'n paar stryd daarin geslaag om met die gekoesterde doel te bereik, en ja, om te installeer en te klap, wat jy nodig het om te sit /boot buite van LVM-'n 👿 Hierdie uiters ernstige en irriterende, as vir een of ander rede vergeet om te verhoog die grootte van die boot partisie van 200MB en paratroopas ou pitte, wat gebeur.

In die Algemeen, enigiets nie verwag nie en hoewel ek is teleurgesteld in CentOS.

As psuvm RHEL en CentOS kak-en daar is iemand dinge wat uitgevind is baie bekwaam. Byvoorbeeld, die toevoeging van'n groot aantal van bykomende IP-adresse is nogal'n aangename taak. In die Algemeen, as jy nodig het om by te voeg'n groot aantal van die adresse ek raspisal een bash script wat in die siklus van die operasie wat die hande nie werk nie. In Centos/RHEL mense vorendag gekom met'n mooi mooi verskeidenheid lêer. In die Algemeen, die skep van die lêer /etc/sysconfig/netwerk-skrifte/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-maar dit is'n bietjie interessant in setype brug adapters. Stem saam dat jy reeds geïnstalleer die brug-utils pakket en eth0 (hierdie in my voorbeeld) ingestel, so, laat ons kyk na die basiese stappe

  1. Ons kopieer die instellings vir eth0 in br0 (hier, as jy'n ander benaming adapter om dit op te los)
  2. Senectute inskrywings vir eth0 in die konfigurasielêer op br0
  3. samestate adapter tipe Ethernet-Brug
  4. Die verwydering van die MAC-adres van die br0 opset
  5. Stel in die opset van eth0 dat jy'n oorbrug adapter 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

Vandag sutirtha ek doen'n standaard dist opgradering op'n enkele bediener Debian en Dovecot gesterf het met die volgende fout 🙂

[….] Begin IMAP/POP3 e-pos bediener: dovecotError: sok() misluk: Spreek familie nie ondersteun deur protokol
Fout: diens(pop3-login): luister(::, 110) misluk: Spreek familie nie ondersteun deur protokol
Fout: sok() misluk: Spreek familie nie ondersteun deur protokol
Fout: diens(pop3-login): luister(::, 995) misluk: Spreek familie nie ondersteun deur protokol
Fout: sok() misluk: Spreek familie nie ondersteun deur protokol
Fout: diens(imap-login): luister(::, 143) misluk: Spreek familie nie ondersteun deur protokol
Fout: sok() misluk: Spreek familie nie ondersteun deur protokol
Fout: diens(imap-login): luister(::, 993) misluk: Spreek familie nie ondersteun deur protokol
Noodlottige: Versuim het om te begin luisteraars
misluk!

 

Ако се загледате внимателно в нея грешката вади очите на човек luister(::, 993) misluk natuurlik probeer om te luister na die ipv6-adres dat ek gestremd is 😈 . Die oplossing acidini as die fout self – трябва да накараме dovecot да работи само на ipv4, което се постига с следният ред в /etc/dovecot/dovecot.conf
listen=0.0.0.0
След което удряме един бърз рестарт на Dovecot и всичко е по реда си и можем да продължим с дистрибутивният ъпгрейд