Oricine care este angajat în web hosting știe ce amenințare sunt utilizatori infectate cu malware, coji de web etc. În cazuri această utilizare generală h nu un script rău. acesta dispune de 3 lucruri

  1. Este teribil de lent
  2. Este teribil de lent și, dacă-l lăsa în modul de monitorizare va izgavri server de tine
  3. Își menține propria bază de date de definiție MD5 / hex de cod rău.

Ultima caracteristică doar o face utilă, pentru că în afară de orice altceva poate sabmitvash fișiere care nu au fost detectate până în prezent, iar într-o etapă ulterioară va intra în bazele de date. Așa cum am împărtășit la punctul 1 și 2 Viteza este foarte scăzută – la încărcare mică fișierul mașină 70K este scanat timp de aproximativ o oră și jumătate. Din acest motiv, am început să ajute bunul meu prieten cu ShadowX Malmo – maldet alternativă scrisă în Python cu puțină flexibilitate. Din păcate, lipsa de timp (în principal, dar nu numai) nu am terminat proiectul, care în acest moment nu este foarte ușor de utilizat – există mai multe bug-uri care trebuie să fie eliminate. In ultimele zile am avut probleme cu clienții infectați cu CryptoPHP care au avut fișiere de mari public_html ~ 60k + inod-și Utilizator. Din moment ce numărul total a trebuit să fie scanat peste 200k fișier care aproximativ ar lua 5+ ore am decis să tune configurația maldet, pentru a diminua fișierele care vor fi scanate într-un număr mai rezonabil și timp. In timp ce iau confit observat următoarele linii

# 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

Interesant… Se pare că există posibilitatea de a utiliza ClamAV – care oferă, de asemenea, viteza mare, dar de ce nu încercați. A instalat rapid

/scripts/update_local_rpm_versions --edit target_settings.clamav installed

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

Maldet-rula și într-un dosar mic – Nu văd nici o diferență în viteză și comportament – El folosește său de scanare sa-perl de schi în loc de cea a CLAMAV. După o scurtă cernerea prin sursa de maldet a constatat următoarele linii

 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

Da a făcut o care 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 пъти и половина по бързо в сравнение с преди.

Înainte de a fi început cu o altă ură aleatoare la 50 OS s'tinki Vreau să spun, că în fiecare zi trebuie să se administreze o cunosc first-person singular destul de bine. Astăzi am petrecut timp pentru a iztestvam magie noua facilitate neauzit și nevăzut de upgrade distrubitiven (pseudo) 😀 . Primul lucru pe care ma uimit este, că RedHat în înțelepciunea sa infinită s-au decis să întrerupă sprijinul pentru arhitectura x86 🙄 . Напълно съм наясно че сме 2014-та година и сървърни процесори с 32 instrucțiuni pic lung lipsă. Мда ама какво правят потребителите на малки VPS-и – x64 labei mai mult de RAM, așa cum te uiți la ea, dacă aveți mașină virtuală subțire, cu 512 MB-1GB de RAM va lupta pentru fiecare ea megabay și nu deșeuri 20-30% Doar pentru a utiliza un set mare de instrucțiuni. Prepsuvah pentru că am fost instalil CentOS x86 și x64 tras o. Imediat am văzut o diferență în ISO-lea – ~ 100MB minim при 6.5. Prepsuvah o mai mult timp. Am instalat din nou virtualkata am decis să văd cât de bine RedHat au făcut treaba – I-am dat / var și / usr partiții LVM separate pentru 😈 . După instalare, modernizate toate pachetele instalate și apache, PHP, mysql и bind – a fost interesant faptul că va prinde serviciu de foc. Deschis ca un lider bun student al CentOS pentru a actualiza și a început cu sârguință să urmeze pas cu pas. Când am ajuns la momentul în care, pentru a începe upgrade-ul real acest rasi ma sculptat, че имам критичен проблем 🙄 . Examinați ieșire detaliată – mdaaaa / usr nu poate este o partiție separată 😆 am știut, N-aș fi dezamăgit în Jim Whitehurst și compania. salva “extremă” problema a fost destul de mesaje nesemnate pachete, Fișierele konfizi care nu se potrivesc, etc.. WTF nu a fost folosit chiar noi arhive treia tot de la oglinzile lor tras mea nu am făcut nici o setare doar simplu yum install. Acum, totul a fost clar de upgrade, astfel destul de familiar forțat. Refaceți cu atenție ca și în cele din urmă am prompt scenariul și a fost peste tot pentru partiția / usr. Am fost prea leneș, care încearcă să Fix, oricum era numai în scopuri științifice, nici un produs server mod de a face upgrade la momentul respectiv. Am prins reinstalați virtualkata data asta tot ceea ce-l împinge în 1 acțiune. De asemenea, am luat o lecție, nu actualizează orice sarvasi suplimentară, după instalare de upgrade directă. Pasul final a venit din nou dialogul DOSA, care mi-a spus, Am o mulțime de probleme de mare – pachetele invalide, konfizi etc, dar ar putea continua. Am știut că la început nu le fac lucruri greșite. Am reporni din nou și am așteptat – oh ce un upgrade miracol finalizat cu succes. Și a funcționat, sau cel puțin de încărcare și nu au încercat să instaleze pachete suplimentare, dar comanda oprire depinde – sys încă a trebuit să fie un bug 💡 . Dupa ce tot acest Tarapoto a decis să instaleze un Centos curat 7 pentru a vedea dacă ne maraitul pentru partiția / boot în MVS – 6.5 nu permite o astfel de aroganță. ISO-am lansa și am fost șocat ușor de către instalator – nu a fost extrem de confortabil “ordonat”, complet ilogic frumos. След известна борба успях със заветната цел и аха да се инсталира и гръмна, че трябва да си изнеса /boot-а извън LVM-a 👿 Това е крайно не сериозно и досадно, ако поради някаква причина забравиш да си увеличиш размера на boot дяла от 200МБ и понатрупаш стари ядра какво се случва.

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

În ceea ce privește Jur RHEL și CentOS rahat și există unele lucruri pe care ei au inventat destul de știință de carte. De exemplu, adăugarea unui număr de suplimentare de IP-uri este un loc de muncă destul de frumos al nostru. În general, dacă aveți nevoie să adăugați un număr mare de adrese, aș fi contorizate un skriptche bash în care ciclul pentru a efectua operația care mâna nu a funcționat. La persoanele Centos / RHEL a dat seama destul de bine fișier gamă. În general, a crea un fișier / 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 в нашият случай

 

În Centos, dar mai puțin interesant în configurarea adaptoarelor punte. Accept că pachetul-pod utils este deja instalat și eth0 (acest lucru este în exemplul meu) set, așa că haideți să ne uităm la etapele de bază

  1. Setările de copiere în br0 eth0 (aici deja, dacă aveți nevoie de un alt adaptoare de denumire pentru ao corecta)
  2. Zanestvate înregistrări br0 eth0 fișier de configurare
  3. tip zamestvate de adaptor Ethernet în Podul
  4. Scoaterea adresei MAC a br0 de configurare
  5. Set în configurație eth0 că vom avea un br0 adaptor pod

За да спестя време си го разписах като елементарно 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

Astăzi sutinrta a început să facă dist standard de upgrade-un server Debian și Dovecot a murit următoarea eroare 🙂

[….] De pornire IMAP / POP3 server de mail: dovecotError: priză() a eșuat: Familia de adrese nu este acceptat de protocol
Eroare: serviciu(pop3-conectare): asculta(::, 110) a eșuat: Familia de adrese nu este acceptat de protocol
Eroare: priză() a eșuat: Familia de adrese nu este acceptat de protocol
Eroare: serviciu(pop3-conectare): asculta(::, 995) a eșuat: Familia de adrese nu este acceptat de protocol
Eroare: priză() a eșuat: Familia de adrese nu este acceptat de protocol
Eroare: serviciu(imap-conectare): asculta(::, 143) a eșuat: Familia de adrese nu este acceptat de protocol
Eroare: priză() a eșuat: Familia de adrese nu este acceptat de protocol
Eroare: serviciu(imap-conectare): asculta(::, 993) a eșuat: Familia de adrese nu este acceptat de protocol
Fatal: Nu a putut porni ascultători
a eșuat!

 

Ако се загледате внимателно в нея грешката вади очите на човек asculta(::, 993) a eșuat în mod evident, încearcă să asculte la adresa ipv6 pe care am interzis 😈 . Soluția este la fel ca ea ochevdino eroare – трябва да накараме dovecot да работи само на ipv4, което се постига с следният ред в /etc/dovecot/dovecot.conf
listen=0.0.0.0
След което удряме един бърз рестарт на Dovecot и всичко е по реда си и можем да продължим с дистрибутивният ъпгрейд