Bárki, aki részt vesz tárhely tudja, milyen veszélyt jelent a fertőzött felhasználók malware, web kagyló stb. Azokban az esetekben jelen általános használatra h Nem rossz script. Jellemzője 3 a dolgok

  1. Szörnyen lassú
  2. Ez szörnyen lassú, és ha hagyja, hogy a monitoring módban izgavri szerver
  3. Megtartja saját adatbázisa md5 / hex meghatározása rossz kód.

Csak a múlt tulajdonság teszi hasznos, mert eltekintve bármi mást sabmitvash fájlokat, amelyeket nem mutattak ki eddig, és egy későbbi szakaszban lépnek adatbázisok. Amint azt a közös pont 1 és 2 sebesség megdöbbentően alacsony – kis terhelés a gép 70K fájl beolvasása körülbelül egy és fél óra. Emiatt kezdtem, hogy segítsen a jó barát ShadowX Malmö – alternatív maldet írt python kevés rugalmasságot. Sajnos, az idő rövidsége (elsősorban, de nem kizárólag) mi nem fejezte be a projekt, amely abban a pillanatban nem nagyon használható – sok hibát, hogy tisztázni kell. Az elmúlt napokban nem volt probléma az ügyfelek fertőzött CryptoPHP aki nagy fájlok public_html ~ 60k + inod-és felhasználói. Mivel összesen kellett szkennelni alatt 200K fájl, amely nagyjából tartana 5+ órát úgy döntöttem, hogy beállítsa a konfiguráció maldet, hogy csökkentse a fájlok lesznek vizsgálva, hogy egy ésszerű számban és időben. Míg szedés confit észrevette a következő sorokat

# 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

érdekes módon… Úgy látszik, van egy lehetőség, hogy használni ClamAV – amely szintén tartalmaz nagy sebességgel, de miért nem próbálja. A gyorsan telepíthető

/scripts/update_local_rpm_versions --edit target_settings.clamav installed

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

Maldet-futás és egy kis mappa – Nem látok különbséget a sebesség és a viselkedés – Ő használja az ő perl-ski szkenner helyett, hogy a clamav. Egy rövid szitálás forrása maldet talált a következő sorokat

 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

Ja tett amely clamscan és nagy meglepetésemre rájöttem, hogy clamav nem található elérési út, mi egy hülye Cpanel elhagyta őt csak a/usr/helyi/cpanel/3rdparty/bin/a házmester binarkite ahol. Egy gyors erősít a probléma ln:

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

Scan most maldet felső jelentések bíró

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

Után már használ ClamAV maldet véget ér a beolvasás 3-4-5 szer gyorsabb, mint korábban. A vizsgálat azt mutatta – 70k-izt″rkla inod őket a 25 min, ami körülbelül 3 és fél-szer gyorsabb, mint korábban.

Mielőtt elkezdte egy másik véletlenszerű gyűlöletet 50 s'tinki OS értem, hogy minden nap azt kell beadni neki, hogy az első személy egyes szám meglehetősen jól. Ma töltöttem időt iztestvam új mágikus hallott és látott funkció distrubitiven frissítés (ál) 😀 . Az első dolog, ami lenyűgözött engem, hogy RedHat végtelen bölcsességében úgy döntött, hogy hagyja abba támogatása x86 architektúra 🙄 . Én vagyok tisztában, hogy mi vagyunk az évben 2014 és kiszolgáló processzorok 32 kicsit hosszú használati hiányzik. Igen, de a felhasználók mit egy kis VPS és – x64 mancs több RAM, ahogy nézzük, ha vékony a virtuális gép 512-1 GB RAM harcolni fog minden megabay, és nem pazaroljuk 20-30% Csak, hogy egy nagy sor utasítást. Prepsuvah mert én instalil CentOS x86 és x64 kihúzott egy. Azonnal láttam a különbséget ISO-edik – ~ 100MB minimum при 6.5. Prepsuvah még egyszer. Telepítettem újra virtualkata úgy döntöttem, hogy milyen jól RedHat volna a munkát – Adtam a / var és / usr külön LVM partíciók 😈 . A telepítés után frissíteni az összes telepített csomagok és apache, php, mysql и kötődnek – Érdekes volt, hogy kifogja a tűzoltóság. Nyitott, mint egy jó tanuló vezetésével CentOS frissítéséhez és elkezdte szorgalmasan követni lépésről lépésre. Amikor elérte a pillanatban kezdődik a tényleges frissítés a hegyi oroszlán faragott nekem, Nekem van egy kritikus probléma 🙄 . Tekintse át részletes kimenet – mdaaaa / usr ez nem egy külön partíción 😆 Tudtam, Nem lennék csalódott Jim Whitehurst és a társaság. megment “szélső” probléma meglehetősen üzenetek aláíratlan csomagok, konfizi fájlokat, amelyek nem felelnek meg, stb. WTF nem is használja a harmadik adattárak mindent a tükör húztam nem tettem volna semmilyen beállítást csak egyszerű yum install. Most minden világos volt, így elég teketória nélkül kényszerű frissítési. Ismét újraindítani szorgalmasan végül kéri a forgatókönyvet, és ez volt az egész / usr partíció. Túl lusta voltam, hogy megpróbálja megjavítani, egyébként ez csak tudományos célra semmilyen módon kiszolgáló termék frissíteni idején. Elkaptam újratelepítését virtualkata ezúttal mindent lök a 1 részvény. Szintén vettem egy leckét, nem frissíti minden további sarvasi, telepítés után közvetlen frissítés. Az utolsó lépés ismét jött DOSA párbeszéd, aki azt mondta, Van egy csomó bajt Nagy – érvénytelen csomagokat, konfizi stb, de tudta folytatni. Tudtam, hogy az elején nem teszik őket rossz dolgokat. Azt indítsd újra a gépet, és vártam – ó, milyen csoda frissítés sikeresen befejeződött. És működött, vagy legalábbis csomagtartó, és nem próbált további csomagok telepítését, de halt parancsot függ – sys még volt, hogy egy hiba 💡 . Miután ez az egész Tarapoto úgy döntött, hogy telepíteni egy tiszta Centos 7 hogy ha morogva a / boot partíció LVM – 6.5 nem teszi lehetővé az ilyen arrogancia. ISO-én indít el, és nagyon enyhén sokkolt a telepítő – nem volt rendkívül kényelmes “takaros”, teljesen logikátlan, hogy gyönyörű. Után néhány harc kezelt-hoz felszerel a tömítéssel dédelgetett cél és igen, Meg kell oldania ki/boot-és azon túl-👿 egy LVM rendkívül súlyos, és nem zavaró, Ha részére némely ok ön elfelejt-hoz növekszik a méret, a rendszerindító partíció a 200 MB, és néhány régi magok mi történik.

Alapvetően én nem várok semmit, és én vagyok még mindig csalódott a CentOS.

Ami esküszöm RHEL és CentOS szar-és van néhány dolog, hogy ők találták elég írástudó. Például, hozzátéve, számos további IP-s egy nagyon szép munkát a miénk. Általában, ha kell hozzá egy nagy számú címek volna összeszámlálása egy bash skriptche amelyben ciklus végezze el a műveletet, hogy a kéz nem működik. CentOS / RHEL nép rájött, nagyon jó sor fájl. Általában, hozzon létre egy / etc / sysconfig / network-scripts / ifcfg-eth0-range0. Itt helyett eth0 hálózati adapter neve, ha nem eth0. Majd adja hozzá a következő tartalommal

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

mivel az érvek

  • IPADDR_START – kezdő IP-címe
  • IPADDR_END – végleges cím
  • HÁLÓZATI MASZK – alhálózati maszk
  • CLONENUM_START – számozás kezdődik a hálózati csatoló eth0:0 a mi esetünkben

 

CentOS, de kevésbé érdekes a beállítás a híd adapterek. Elfogadom, hogy már telepítve van a híd-utils csomagot és eth0 (ez az én például) készlet, így nézzük meg az alapvető lépéseket,

  1. Másolási beállításokat eth0 br0 (Már itt, ha szüksége van egy másik elnevezése adapterek a kijavítására)
  2. Zanestvate rögzíti eth0 konfigurációs fájl br0
  3. zamestvate típusú Ethernet adapter a híd
  4. Eltávolítása a MAC címét a konfigurációs br0
  5. Meghatározott eth0 konfiguráció, hogy mi lesz egy híd 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

Ma sutinrta kezdett hozzá a standard dist frissíteni a Debian szerver és Dovecot meghalt a következő hibaüzenet 🙂

[….] Kezdve IMAP / POP3 mail szerver: dovecotError: foglalat() nem sikerült: Cím család által nem támogatott protokoll
Hiba: szolgáltatás(pop3-bejelentkezést): hallgat(::, 110) nem sikerült: Cím család által nem támogatott protokoll
Hiba: foglalat() nem sikerült: Cím család által nem támogatott protokoll
Hiba: szolgáltatás(pop3-bejelentkezést): hallgat(::, 995) nem sikerült: Cím család által nem támogatott protokoll
Hiba: foglalat() nem sikerült: Cím család által nem támogatott protokoll
Hiba: szolgáltatás(imap-bejelentkezés): hallgat(::, 143) nem sikerült: Cím család által nem támogatott protokoll
Hiba: foglalat() nem sikerült: Cím család által nem támogatott protokoll
Hiba: szolgáltatás(imap-bejelentkezés): hallgat(::, 993) nem sikerült: Cím család által nem támogatott protokoll
Halálos: Nem sikerült elindítani a hallgatók
nem sikerült!

 

Ако се загледате внимателно в нея грешката вади очите на човек hallgat(::, 993) nem sikerült nyilvánvalóan igyekezett hallgatni az IPv6 címet, hogy megtiltottam 😈 . A megoldás egyaránt ochevdino, mint maga a hiba – трябва да накараме dovecot да работи само на ipv4, което се постига с следният ред в /etc/dovecot/dovecot.conf
listen=0.0.0.0
След което удряме един бърз рестарт на Dovecot и всичко е по реда си и можем да продължим с дистрибутивният ъпгрейд