Ĉiu kiu estas engaĝita en ttt retprovizanton scias kion minaco estas infektitaj uzantoj kun malware, TTT konkoj ktp. En kazoj Ĉi Ĝenerala uzo h Ne malbona skripto. ĝi prezentas 3 aferoj

  1. Estas terure malrapida
  2. Estas terure malrapida kaj se ĝi enlasis monitoreo reĝimo estos izgavri servilo vi
  3. Subtenas lian propran datumbazon de MD5 / deksesuma difino de malbona kodo.

Nur lasta karakteriza faras ĝin utila, ĉar krom io alia povas sabmitvash dosierojn kiuj ne estis detektitaj ĝis nun, kaj ĉe pli posta stadio venos en datumbazoj. Kiel mi dividis en punkto 1 kaj 2 rapido estas ŝoke malalta – ĉe malalta ŝarĝo la maŝino 70K dosiero estas skanita por proksimume horo kaj duono. Tial mi komencis helpi mian bonan amikon kun ShadowX Malmö – Alternativa maldet skribita en Python kun malmulta flexibilidad. Bedaŭrinde, manko de tempo (ĉefe sed ne nur) Ni ne finis la projekton, kiuj nuntempe ne estas tre uzebla – ekzistas multaj bugs kiu devas esti malbarita. En la pasintaj tagoj mi havis problemojn kun klientoj infektita kun CryptoPHP kiu havis grandegan dosierojn public_html ~ 60k + inod-kaj Uzanto. Ekde entute devis esti skanita super 200k dosiero kiu malglate prenus 5+ horoj mi decidis agordi la agordo de maldet, malpliigi la dosieroj kiuj estos escaneados al pli racia nombro kaj tempo. Dum pluki confit rimarkis la sekvajn liniojn

# 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

interese… Ŝajne estas eblo uzi ClamAV – kiu ankaŭ havas granda rapido sed kial ne provi. A rapide instalita

/scripts/update_local_rpm_versions --edit target_settings.clamav installed

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

Maldet-kontrolita kaj sur malgranda dosierujo – Mi vidas neniun diferencon en rapido kaj konduto – Li uzas sian sia perl-skio skanilo anstataŭ tiun de ClamAV. Post mallonga cribado tra fonto de maldet trovis la sekvajn liniojn

 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

Yep faris kiu 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 пъти и половина по бързо в сравнение с преди.

Antaŭ ĝi komencis kun alia hazarda malamo al 50 s'tinki VIN Mi signifas, ke ĉiutage mi devas administri ŝin scii unua persono singulara sufiĉe bone. Hodiaŭ mi pasigis tempon al iztestvam nova magia senekzempla kaj nevidataj trajto distrubitiven altgradigo (pseŭdo) 😀 . La unua afero kiu miris min estas, ke RedHat en lia senfina saĝo decidis descontinuar subtenon por x86 arkitekturo 🙄 . Напълно съм наясно че сме 2014-та година и сървърни процесори с 32 iom longan instruon mankas. Мда ама какво правят потребителите на малки VPS-и – x64 piedo pli de memoro RAM, kiel vi rigardas ĝin se vi havas maldikan virtuala maŝino kun 512MB-1GB de RAM batalos por ĉiu megabay gxin kaj ne malŝpari 20-30% Nur uzi grandan aron de instrukcioj. Prepsuvah ĉar mi instalil CentOS x86 kaj x64 tiris unu. Tuj mi vidis diferencon en ISO-a – ~ 100MB minimuma при 6.5. Prepsuvah pli tempo. Mi instalis denove virtualkata mi decidis vidi kiom bone RedHat faris sian laboron – Mi donis / var kaj / usr apartaj LVM vandoj 😈 . Post instalado altgradigita ĉiuj pakoj instalitaj kaj apache, php, mysql и ligos – estis interesa kiu ekbrulas servo. Malfermiĝis kiel bona studento gvidado de CentOS ĝisdatigi kaj komencis diligente sekvi paŝon post paŝo. Kiam mi alvenis la momento por komenci la reala ĝisdatigo tiu monto leonoj skulptitaj mi, че имам критичен проблем 🙄 . Revizii detala eligo – mdaaaa / usr ĝi ne estas aparta subdisko 😆 mi sciis, Mi ne estos seniluziigita en Jim Whitehurst kaj kompanio. ŝpari “ekstrema” problemo estis tute mesaĝojn sensigna pakoj, konfizi dosierojn kiuj ne kongruas, ktp. WTF ne eĉ uzas trian deponejoj ĉiu el siaj speguloj tiris mian mi ne estus farinta ajnan agordojn nur simplaj yum install. Nun ĉio estis klara do tute senceremonie pelis altgradigo. Rekomenci denove diligente mi fine instigas la skripton kaj ĝi estis ĉie por / usr subdisko. Mi estis tro mallaborema, kiuj provas Fix, ĉiuokaze ĝi estis nur por sciencaj celoj neniel servilo produkto ĝisdatigi tiutempe. Mi kaptis reinstali vian virtualkata tiu tempo ĉiu baton ĝin 1 kunhavigi. Ankaŭ mi prenis lecionon, ne ĝisdatigas ajnan aldonan sarvasi, post instalado rekta ĝisdatigo. La fina paŝo denove venadis Dosa dialogon kiu rakontis al mi, Mi havas multajn problemojn Alta – nevalida pakoj, konfizi ktp sed povus daŭrigi. Mi sciis, ke en la komenco ne faras ilin malĝusta aferoj. Mi reboot denove kaj atendis – ho kia miraklo ĝisdatigo kompletigita sukcese. Kaj ĝi laboris, aŭ almenaŭ boto kaj ne provis instali kromajn pakaĵojn, sed halto komando dependas – sys ankoraŭ devis esti cimo 💡 . Post tiu tuta Tarapoto decidis instali pura CentOS 7 ĉu ni grumblante por / boot dispartigo en LVM – 6.5 ne permesas tian arogantecon. ISO-mi lanĉi ĝin kaj mi milde ŝokis la instalilo – ne estis ege komfortaj “ordigita”, tute nelogike bela. След известна борба успях със заветната цел и аха да се инсталира и гръмна, че трябва да си изнеса /boot-а извън LVM-a 👿 Това е крайно не сериозно и досадно, ако поради някаква причина забравиш да си увеличиш размера на boot дяла от 200МБ и понатрупаш стари ядра какво се случва.

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

Kiel ĵuri RHEL kaj CentOS fek-tie estas kelkaj aferoj kiu ili inventis tre klera. Ekzemple, aldonante kelkajn kromajn IP-s estas sufiĉe bela tasko de nia. Ĝenerale, se vi bezonas aldoni grandan nombron da adresoj mi estus kalkulita kiel bash skriptche en kiuj ciklo efektivigi la operacion kiu mano ne funkciis. En CentOS / RHEL popolo li eltrovis sufiĉe bona gamo dosieron. Ĝenerale, krei dosieron / etc / sysconfig / reto-skriptoj / 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 в нашият случай

 

En CentOS-sed malpli interesa en la agordo de la ponto adaptiloj. Mi akceptas ke estas jam instalita ponto-utils pako kaj eth0 (tio estas en mia ekzemplo) aro, do ni rigardu la bazaj paŝoj

  1. Kopio agordojn en eth0 br0 (tie jam se vi bezonas alian nomanta adaptadores korekti ĝin)
  2. Zanestvate registras eth0 agorda dosiero br0
  3. zamestvate tipo de Ethernet adaptilo en la Ponto
  4. Forigante la MAC de la agordo br0
  5. Eki eth0 agordo kiun ni havos ponto adaptador 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

Hodiaŭ sutinrta komencis fari la norma dist ĝisdatigi Debian-servilo kaj Dovecot mortis la jenan eraron 🙂

[….] Komencante IMAP / POP3 ejon servilo: dovecotError: ingo() malsukcesis: Adreso familio ne subtenata de protokolo
eraro: servo(POP3-login): aŭskulti(::, 110) malsukcesis: Adreso familio ne subtenata de protokolo
eraro: ingo() malsukcesis: Adreso familio ne subtenata de protokolo
eraro: servo(POP3-login): aŭskulti(::, 995) malsukcesis: Adreso familio ne subtenata de protokolo
eraro: ingo() malsukcesis: Adreso familio ne subtenata de protokolo
eraro: servo(IMAP-login): aŭskulti(::, 143) malsukcesis: Adreso familio ne subtenata de protokolo
eraro: ingo() malsukcesis: Adreso familio ne subtenata de protokolo
eraro: servo(IMAP-login): aŭskulti(::, 993) malsukcesis: Adreso familio ne subtenata de protokolo
fatalaj: Malsukcesis komenci aŭskultantoj
malsukcesis!

 

Ако се загледате внимателно в нея грешката вади очите на човек aŭskulti(::, 993) malsukcesis evidente provis aŭskulti la ipv6 address ke mi malpermesis 😈 . La solvo estas same ochevdino kiel sin eraro – трябва да накараме dovecot да работи само на ipv4, което се постига с следният ред в /etc/dovecot/dovecot.conf
listen=0.0.0.0
След което удряме един бърз рестарт на Dovecot и всичко е по реда си и можем да продължим с дистрибутивният ъпгрейд