Ĉiu, kiu traktas profesie kun reteja gastigado, konas la minacon prezentitan de infektitaj uzantoj kun malware, retaj ŝeloj ktp. En la ĝenerala kazo ĝi estas uzata maldeto ne malbona skripto. Ĝi distingiĝas per 3 aferoj

  1. Ĝi estas terure malrapida
  2. Ĝi estas terure malrapida kaj se vi metas ĝin en monitoradon, ĝi skoldos vian servilon
  3. Elportas propran datumbazon kun md5 / heksaj difinoj por malbona kodo.

Ĝi estas ĝia lasta trajto, kiu faras ĝin utila, ĉar, interalie, vi povas sendi dosierojn, kiuj ĝis nun ne estis detektitaj kaj eniros la datumbazojn en posta stadio.. Kiel mi dividis en punkto 1 kaj 2 ĝia rapideco estas ŝoke malalta – ĉe malalta maŝina ŝarĝo, 70k dosieroj estis skanitaj en ĉirkaŭ unu horo kaj duono. Por tio mi komencis helpi mian bonan amikon ShadowX Malmo – alternativo al maldet skribita en pitono kun iom pli da fleksebleco. Bedaŭrinde pro manko de tempo (ĉefe sed ne nur) ni ne kompletigis la projekton, kio ne tre uzeblas nuntempe – estas multaj eraroj, kiuj devas esti forigitaj. En la pasintaj tagoj mi havis problemojn kun klientoj infektitaj per CryptoPHP, kiuj havis grandegajn publik_html-dosierojn ~ 60k + uzantajn inodojn. Ĉar entute pli ol 200k dosieroj devis esti skanitaj, kio daŭras proksimume 5+ horojn mi decidis agordi la agordon de maldeto, redukti la dosierojn skanitajn al akceptebla nombro kaj tempo. Dum mi reprenis la konfiton, mi rimarkis la jenajn 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

Interesaj… Ŝajne estas ebleco uzi ClamAV – kiu ankaŭ ne diferencas pro sia alta rapideco sed kial ne provu ĝin. Mi rapide instalis ĝin

/scripts/update_local_rpm_versions --edit target_settings.clamav installed

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

Mi kuras la maldetekton sur malgranda dosierujo – Mi ne vidas diferencon en rapideco kaj konduto – li uzis sian perlan skanilon anstataŭ la klamon. Post mallonga fosado tra la fonto de maldeto, mi trovis la jenajn 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

Hmmm, mi faris unu kiu clamscan kaj al mia granda surprizo mi trovis, ke clamav tute ne estas en la PATRO, sed la stulta Cpanel lasis ĝin nur en / usr / local / cpanel / 3rdparty / bin / de kie li uzas siajn binarojn.. Rapida ln solvis la problemon:

ln -s /usr/local/cpanel/3rdparty/bin/clamscan /usr/bin/clamscan

Kiam re-skanado, maldeto jam raportas ĉi-supre

{scan} found ClamAV clamscan binary, using as scanner engine...

Post jam uzado de ClamAV-maldeto, ĝi finas sian skanadon 3-4-5 fojojn pli rapide ol antaŭe. La testo montris – 70k inod-a frotis ilin por ĉ 25 min kiu temas 3 fojojn kaj duonon pli rapide ol antaŭe.

Antaŭ ol mi komencas kun alia hazarda malamo 50 maldika OS mi volas diri, ke mi devas ĉiutage administri ĝin kaj mi konas ĝin unuavice unuopa tute bone. Hodiaŭ mi prenis la tempon por testi la novan magian malkaŝitan kaj neviditan funkcion por detrua ĝisdatigo (pseŭdo) 😀 . La unua afero, kiu mirigis min, estis, ke RedHat per sia malfinia saĝo decidis ĉesi subteni la x86-arkitekturon 🙄 . Напълно съм наясно че сме 2014-та година и сървърни процесори с 32 bitaj instrukcioj mankas delonge. Мда ама какво правят потребителите на малки VPS-и – x64 paw pli da kadro, kaj ankaŭ rigardu ĝin, se vi havas maldikan virtualan maŝinon kun 512MB-1GB RAM, vi batalos por ĉiu megabito kaj vi ne malŝparos 20-30% de ĝi nur por uzi laŭ la granda aro de instrukcioj. Mi fuŝis ĉar mi havis x86 CentOS instalitan kaj tiris x64. Mi tuj vidis diferencon en ISOoj – ~ 100MB при minimuma 6.5. Mi malbenis ankoraŭ unu fojon. Mi reinstalis mian virtualan maŝinon kaj decidis vidi kiel bone RedHat faris sian laboron – Mi eksportis / var kaj / usr por apartigi LVM-subdiskojn 😈 . Post la instalado, mi ĝisdatigis ĉiujn pakaĵojn kaj instalis apache, php, mysql и ligi – estis interese se ili ŝaltus la servojn. Kiel bona studento, mi malfermis la gvidilon CentOS pri la ĝisdatigo kaj diligente sekvis ĝin paŝon post paŝo.. Kiam mi alvenis al la punkto, kie komenciĝis la vera ĝisdatigo, ĉi tiu puma fortranĉis min, че имам критичен проблем 🙄 . Mi revizias la detalan eligon – mdaaaa / usr ne povas esti sur aparta subdisko 😆 Mi sciis, ke mi ne estos seniluziigita pri Jim Whitehurst kaj kompanio. Escepte “la ekstrema” problemo estis multaj mesaĝoj pri ne subskribitaj pakoj, konfiskaj dosieroj, kiuj ne kongruas ktp. WTF Mi eĉ ne uzis la 3-an repositoriojn ĉion el iliaj speguloj Mi forprenis Mi ne faris ajnajn agordojn nur simplan yum-instaladon. Ĉio estis jam klara, do mi senĝene pelis la ĝisdatigon. Mi rekomencis diligente denove dum la skripto finfine instigis min kaj ĉio finiĝis pro la / usr-dispartigo. Mi estis tro mallaborema, ke mi provas ripari ĝin, ĉiuokaze ĝi estis ĉio nur por sciencaj celoj, ne ekzistas maniero ĝisdatigi produktan servilon nuntempe. Mi kaptis reinstali mian virtualon kaj ĉi-foje mi enŝovis ĉion 1 titolo. Mi ankaŭ lernis lecionon, neniuj ĝisdatigoj neniuj aldonaj servoj, post instalado rekta ĝisdatigo. En la fina paŝo reaperis la ĝena dialogo, kiun li diris al mi, ke mi havas sufiĉe altajn problemojn – nevalidaj pakoj, konfiskoj kaj tiel plu, sed povas daŭri. Mi sciis komence, ke ili ne agas bone. Mi rekomencis kaj atendis – Ho kia miraklo la ĝisdatigo finiĝis sukcese. Kaj ĉio funkciis aŭ almenaŭ la sistemo ekis kaj mi neniam provis instali pliajn pakaĵojn, sed la halto-komando pendis – ĉu li ankoraŭ devis havi eraron 💡 . Post ĉiu ĉi tiu bruo, mi decidis instali Centos pure 7 ni vidu ĉu ĝi kreskos por / ekigi subdiskon en LVM – 6.5 ne permesas tian aŭdacon. Mi ekigis mian ISO-on kaj ŝokis la instalilon por diri la malplej – ĉio estis ekstreme maloportuna “ordigita”, tute nelogika por esti bela. Post iom da lukto mi sukcesis kun la amata celo kaj aha instali kaj eksplodi, ke mi devas eltiri mian / boton el LVM 👿 Ĉi tio estas ege ne serioza kaj ĝena, se vi iel forgesas pliigi la grandecon de la ekkuro de 200 MB kaj amasigi malnovajn kernojn, kio okazas.

Ĝenerale mi atendis nenion kaj mi ankoraŭ seniluziiĝas kun CentOS.

Колкото и да псувам RHEL и CentOS shit-а има някой неща които са им измислени доста грамотно. Например добавянето на голям брой допълнителни IP-та е доста приятна задачка. По принцип ако трябва да добавя голям брой адреси бих си разписал едно bash скриптче в което в цикъл да извършва въпросната операция че на ръка не си е работа. При Centos/RHEL хората са го измислили доста приятно range файл. В общи линии създаваме файл /etc/sysconfig/network-scripts/ifcfg-eth0-range0. Ĉi tie ni anstataŭas eth0 per la nomo reto adaptilo se ĝi ne estas eth0. Poste ni aldonas la jenan enhavon

IPADDR_START=192.168.0.129
IPADDR_END=192.168.0.254
NETMASK=255.255.255.128
CLONENUM_START=0

kiel la argumentoj

  • IPADDR_START – hejma IP-adreso
  • IPADDR_END – fina adreso
  • RETARO – neta masko
  • CLONENUM_START – numerado, de kiu komenci la retan adaptilon et0:0 en nia kazo

 

La Centos estas iom interesa pri la aro de pontaj adaptiloj. Mi supozas, ke la ponto-utiloj kaj eth0 estas jam instalitaj (en ĉi tio estas en mia ekzemplo) estas agordita, do ni rigardu la bazajn paŝojn

  1. Kopiu la etajn agordojn al br0 (ĉi tie jam se vi bezonas alian nomadon de viaj adaptiloj, vi povas korekti ĝin)
  2. Vi registras la enskribojn por eth0 en la agordodosiero de br0
  3. anstataŭigu la Ethernet-adaptilon per Bridge
  4. Vi forigas la MAC-adreson de la br0-agordo
  5. Vi specifas en la etenda agordo, ke ni havos pontan adaptilon br0

Por ŝpari tempon, mi pentris ĝin kiel elementan bazan manuskripton

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

Ĉi-matene mi komencis fari la norman dist-ĝisdatigon sur Debian-servilo kaj Dovecot mortis kun la sekva eraro 🙂

[….] Komencante retpoŝtan servilon IMAP / POP3: dovecotError: soklo() malsukcesis: Adreso familio ne subtenata de protokolo
Eraro: servo(pop3-ensaluto): aŭskultu(::, 110) malsukcesis: Adreso familio ne subtenata de protokolo
Eraro: soklo() malsukcesis: Adreso familio ne subtenata de protokolo
Eraro: servo(pop3-ensaluto): aŭskultu(::, 995) malsukcesis: Adreso familio ne subtenata de protokolo
Eraro: soklo() malsukcesis: Adreso familio ne subtenata de protokolo
Eraro: servo(imap-ensaluti): aŭskultu(::, 143) malsukcesis: Adreso familio ne subtenata de protokolo
Eraro: soklo() malsukcesis: Adreso familio ne subtenata de protokolo
Eraro: servo(imap-ensaluti): aŭskultu(::, 993) malsukcesis: Adreso familio ne subtenata de protokolo
Fatala: Malsukcesis komenci aŭskultantoj
malsukcesis!

 

Ако се загледате внимателно в нея грешката вади очите на човек aŭskultu(::, 993) malsukcesis ŝajne provante aŭskulti la ipv6-adreson mi malpermesis 😈 . La solvo estas same evidenta kiel la eraro mem – ni devas fari kolombon nur funkcii sur ipv4, kiu estas atingita per la sekva ordo en /ktp / Dovecot / dovecot.conf
aŭskultu = 0.0.0.0
Poste ni trafis rapidan rekomencon de Dovecot kaj ĉio estas en ordo kaj ni povas daŭrigi per la distribua ĝisdatigo