Kartais stringame, taip jau būna visiems. Kartais dažniau, kartais rečiau. Kai stringame, būna liūdna. Priežasčių strigimams būna įvairių, tai šito ir neslėpsim. Geriau parašysim dėl ko stringame ir ką darome, kad daugiau nestrigtume. Gal pasirodys įdomu kažkam iš adminų, juo labiau kad artėja sisteminių administratorių diena. Todėl pasidalinsim savo patirtimis, gal kažkam pravers.

Labai smagu ir linksma administruoti serverius. Pats nuostabiausias pasaulyje užsiėmimas. Ypač 4 ar 5 nakties, nes tada naudotojai miega ir nepastebi. O dieną, kai adminas miega, tai visi sako, kad adminas nieko neveikia.

PoPo.lt tinklaraščiai sukasi labai optimizuotame serveryje. Kitaip ir būti negalėtų, nes tinklaraščių čia daug, kai kurie iš jų nepaprastai populiarūs (neišduosime kiek, bet kai kurie ne patys didžiausi portalai kai kuriems blogeriams galėtų pavydėti skaitytojų skaičiaus). Todėl rūpinamės, kad viskas gerai dirbtų. Serverio resursų yra perteklius, įprastu metu (kai nevyksta DoS) procesorių resursų naudojimas neviršija kelių procentų. Ir visvien paskui užeina koks DoS ir tada jau kartais būna strigimų, kada kuriam laikui serveris atrodo vos gyvas.

Per sekundę kartais aptarnauti tenka dešimtis ar netgi šimtus užklausų (čia skaičiuojam dinaminį, Apache/PHP generuotą turinį, neskaičiuodami statinio, kurį sukešuoja Varnish). Tai yra daug, juo labiau kad ir WordPress nėra labai lengvas ir greitas daiktas – tai juk sudėtinga ir daug galinti tinklaraščių sistema. Techniškai žiūrint, tur būt galėtume per dieną parodyti visus mūsų blogofermos tos dienos straipsnius visiems Lietuvos gyventojams, kurie tik naudoja Internetą.

Bet kai ant mūsų užleidžia DoS atakas, tai pasidaro sudėtinga. Nepaisant to, beveik visada pavyksta dirbti taip gerai, kad niekas nei nepastebi, kad vyksta kažkas neįprasto. Gal dėl to, kad DoS atakas atlaikyti pasidarė kasdienybė. Kartais ta kasdienybė visgi išlenda į paviršių, tada būna sunkiau.

Toliau čia jau verta skaityti tik adminams ir webmasteriams. Blogeriams geriau neverta, nes pvz., apie IP blokavimą tai nėra prasmės net skaityt (tas žemesniam lygmenyje daroma, negu WordPress). Bet gal visvien bus truputį įdomu kažkam. Gal blogeriams apie WordPress pluginus bus įdomu.

DoS atakos ir laužimaisi

Išties bet kuriam serveriui baisiausias dalykas yra DoS atakos, nes piko metu apkrovos išauga dešimtis ar šimtus kartų. Mums jos tapo kasdienėmis dar prieš kelerius metus (tuo metu prasidėjo DoS prieš daugumą Lietuvos portalų), tačiau po Ukrainos įvykių viskas labai sustiprėjo. Itin pasijuto, kai pas mus atsidarė pora tinklaraščių – Laisvoji Ukraina ir Free Ukraine (gaila kad rašo dabar retai). Kartu su tuo ėmė kartotis ir brute force laužimųsi bandymai (ar tikrai gerus slaptažodžius turite? Pasirūpinkit, kad nebūtų kokie nors „qwerty“ ar „12345“).

Tokios brute force ar DoS užklausos žiauriai kerta per serverį, nes resursų suėda be galo daug (DoS specialiai daroma taip, kad užklausa sukeltų kuo didesnę apkrovą serveriui), o atakų metu užklausų eina dešimtys ar šimtai per sekundę. Nenuostabu, kad gal net apie pusę įsilaužimams skirtų užklausų eina iš okupuotų Ukrainos teritorijų, Luhansko ir Donecko interneto tiekėjų. Dar dalis iš Kijevo, bet atrodo kad čia tik tiekėjo adresas, o užklausos visvien iš to paties Luhansko ir Donecko. Kita dalis DoS ir laužimųsi – iš Rusijos. Dar pasitaiko šiokie tokie kiekiai iš atsitiktinių šalių, kaip Prancūzija, Šveicarija, Venesuela ir panašiai.

Kad ir kiek serveris galėtų atlaikyti, kai jau prasideda kas nors panašaus į DoS, tai serveris arba sugeba atlaikyti bet kiek, tegul ir mėtydamas kartais kokias nors 503 klaidas, arba jei nesugeba, tai būna blogai. Čia ne kokie spamo srautai. Kai jau padosina, tai visko būna per daug. Tiesiog daugiau, nei galima. Nelinkim to niekam.

Nuo tokių atakų iš dalies padeda Varnish serveris, kuris nuima nuo Apache tą dalį darbo, kuri susijusi su duomenų persiuntimu klientams. Taip pat Varnish gerai servuoja ir sugeneruotus puslapius, paveiksliukus ir panašiai. Tai reiškia, kad atakų metu, net jei Apache stringa, Varnish servuoja toliau.

Dar verta padaryti tokią direktyvą į httpd.conf, apsaugai nuo visokių besilaužiančių (o kadangi slaptažodžio patikrinimas labai CPU-ėdrus, tai su tais laužimaisis tas pat kaip su DoS):

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} POST
    RewriteCond %{REQUEST_URI} .(wp-login|wp-signup)\.php*
    RewriteCond %{HTTP_REFERER} !.*popo.lt.* [OR]
    RewriteCond %{HTTP_USER_AGENT} ^$
    RewriteRule (.*) http://popo.lt/$1 [R=301,L]
</ifModule>

Nepatariam dėti ant komentarų šitos apsaugos, nes kai pabandėm, paskui aukšto rango politikai skundėsi, jog jiems komentarai neveikia. Pasirodo, kartais naršyklės su kai kuriomis WordPress temomis nenurodo refererio, nors turėtų nurodyti. Bet nuo laužimųsi, spaminių registracijų ir dalies DoS labai neblogai padeda. Nuo spamo komentarų irgi labai padėjo, bet kaip pamatėm, kartu nuo tikrų komentarų irgi labai apsaugojo, tik kad netinkamai.

Spameriai ir kova su jais

Dar vienas baisus dalykas yra spameriai. Jie nesukuria tokių baisių pikų kaip atakuotojai, kurie nori palaužti serverį, bet sukuria nuolatines didžiules apkrovas. Gal net kokius 99% serverio apkrovimo sudaro spamerių sukurtas apkrovimas.

Kai kurie iš spamerių yra kultūringi (visi jie šlykštūs, bet kai kurie yra dar 100 kartų šlykštesni). Tie, kurie kultūringi, duoda serveriui saikingai užklausų. Pavyzdžiui, 1 užklausą per 10 sekundžių. Tie spameriai kurie yra brutualūs, duoda spamo tiek daug, kad viskas pasidaro panašu į DoS ataką, pvz., 30 spamo komentarų per sekundę. Bet tegul dauguma spamerių nėra brutualūs, jų yra nepaprastai daug, šimtai ir tūkstančiai skirtingų spamerių. Žodžiu, jei spamerių nebūtų, tai serverio resursų reiktų 100 gal kartų mažiau. Gaunasi taip, kad ne tiek blogeriams ir jų skaitytojams serveris turi dirbti, kiek spamo užklausas aptarnauti, o paskui dar tą spamą filtruoti, kad jis kur nereikia nepakliūtų ir būtų išnaikintas su WP pluginais.

Su spameriais kovoti sunku, bet atradom, kad visgi įmanoma. Pirmiausiai tai nuo spamerių padeda švara, nes jie kaip tarakonai, užuodžia kur leidžiamos ir nevalomos šiukšlės. Ir tada jau pasipila kaip liūtis iš debesies. Todėl kartais reikia peržiūrėti visus blogus, kuriuose kaupiasi komentarai ir pažiūrėti ar nėra leidžiama spameriams skelbtis. Spamo robotai per savo paiešką aptinka kur skelbiami spamo komentarai ir ten paskui jau supuola kaip musės prie šūdo. Todėl senuose ir neprižiūrėtuose bloguose atjungiame komentavimą.

Kartais neapdairūs blogeriai leidžia spamo komentarus, nes pagalvoja, kad čia tikri komentuotojai. Paskui nustemba, kai tokių menamai tikrų komentuotojų po kelių mėnesių pasidaro šimtai ar netgi tūkstančiai per dieną.

Buvo tokių atvejų, kai rasdavome kokiame nors bloge 100-200 tūkstančių spamo komentarų, per kokį pusmetį susikaupusių (nors kad virš milijono būtų tai gal ir nebuvo dar). Tada belieka tik trint komentarus per SQL užklausas, tiesiai iš duomenų bazės. Šitaip kartais gali ir gerų komentarų išsitrinti kažkiek. Ką padarysi. Serveris turi veikti, todėl spamo negalima toleruoti.

Gerai apsišlavus, spamo srautas paskui smarkiai sumažėja, nes spameriai irgi nenori švaistyti savo resursų beprasmiškai. Kokia nauda siųsti milijonus spamo komentarų, jei netgi vienas iš milijono nepraeis. Jei švara palaikoma, tai jau vien dėl to spamo srautas būna bent kelis kartus mažesnis.

Antras dalykas yra spamerių blokavimas. Pradžioje atrodo kad spamerių naudojamų IP adresų yra begalybė, todėl beprasmiška kovoti. Tačiau jei pradedam blokuoti spamerių adresus, tai paaiškėja, kad jų ne taip daug. Blokuojam ant serverio POST užklausas subnetams, iš kurių eina spamas, „X.X.X.*“, tai užblokavus jau pirmą šimtą aktyviausių, jau pasijunta palengvėjimas. Po to kai užblokavom apie 1000 spameriškų subnetų, spamo srautas kuriam laikui sumažėjo gal 50 kartų. Teko aišku padirbėti. Paskui porą mėnesių neblokavom daugiau naujų subnetų, tačiau spamo srautas visvien liko bent kelis kartus mažesnis, negu buvo iki tol.

Tuos spamerių IP adresus blokuoti labai verta, nes kiek tikrinome, tai iš daugelio IP adresų ir subnetų metų metais eina spamo komentarai. Užblokuoji tokius vieną kartą ir tada jau metų metais negali jie siųsti spamo. Gerai dar būtų, jei jiems vidurius paleistų, bet deja neturim aparato diarėjos spinduliams pagal IP nutaikyt.

Darbas kapstyti po skirtingų blogų komentarus ir žiūrėti ar spamas ar ne spamas, o paskui spamerių IP blokuoti, yra nuobodus, bet atsiperka labai gerai. Spameriškų IP adresų (ir juo labiau subnetų) kiekis nėra begalinis, galima susidoroti.

WordPress pluginai kovai su spamu

Dar vienas paprastas būdas kovoti su spamu, tai pasižiūrėti kokius savo elektroninio pašto adresus spameriai nurodo. Kažkada atradome, kad per porą metų nebuvo nei vieno nespaminio komentaro iš @mail.ru ir @yandex.ru (kas buvo, tai buvo truputis kelerių metų senumo komentarų), tai juos užblokavome visoje blogofermoje. Iškart spamo nukrito koks penktadalis. Tai labai nemažai. Penktadalis spamo užklausų, skaičiuojant pagal apkrovas – tai bent kelis kartus daugiau, nei visas tikrų PoPo.lt blogų lankytojų srautas. Patariame visiems tuos adresus blokuoti, nes nors ir ne stebuklas, bet paprasta ir malonu kaip skanus saldainis.

Galų gale lieka dar kiti WordPress pluginai. Akismet yra daugelio mėgstamas, bet pastebėjom, kad keistai elgiasi kartais. Kažkodėl pagal juos Lietuva yra spamerių šalis (nors ant PoPo.lt mes beveik nematome lietuviško spamo). Daugybė komentarų per Akismet gali nukeliauti į /dev/null, todėl gali atrodyti, kad apsaugo gerai, bet mes nepatariame tuo patikėti iškart. Nes nuo tikrų komentarų Akismet irgi apsaugo labai gerai. Viena iš išeičių – kartu su Akismet naudoti Conditional CAPTCHA pluginą.

Geresnis ir vis dar nepasenstantis pluginas yra NoSpamNX, kuris gal net 80% spamo numeta į ten kur reikia ir tas spamo identifikavimas yra be jokių false positive atvejų. Šitas pluginas labai geras, bet yra buve atvejų kadaise, kai užblokuodavo komentarų formas kažkaip. Tada irgi negerai, nes komentavimas neveikia. Dabar jau turi būti pasitaisę, nes dar prieš kelis metus jie tvarkė tą problemą, bet mes dar nedrįstam šito plugino įjungti visiems defaultiškai (kai kuriem blogam kartais įjungiam rankomis, jei pamatom betvarkydami serverį, kad kažkurį blogą spameriai puola, o pabandžius pluginas veikia ir netrukdo).

Aišku, ir tie 20% likusio spamo, kurį NoSpamNX praleidžia, gali būti šimtai spamo komentarų per dieną. Tokiu atveju patariame kartu su NoSpamNX naudoti mūsų padarytą negerų žodžių sąrašą (konfigūracijoje įvesti), jis kažkiek palengvina gyvenimą nes dar kelis kartus sumažina spamo kiekį. Bet tada pasitaiko gal netgi koks 1% atvejų, kai ir tikras komentaras į spamą pakliūna.

Galų gale dar yra SI Captcha pluginas, kuris irgi visai veikia. Bent jau mūsų pagalbos bloge jis labai gerai padeda apsisaugoti nuo spamo. Bet lankytojams jis nėra patogus, nes įvedinėti tuos kodus yra labai užknisantis dalykas. Jei mūsų straipsniai čia būtų smarkiau komentuojami, tai nenaudotume.

Žodžiu, WordPress pluginai irgi padeda nuo spamo, o jei spameriams nesigauna spamą skleisti, tai jie per daug neįsisiautėja. Šitaip kokius 90% serverio resursų galima atlaisvinti, vien su spamu apsitvarkius, net ne iki galo, o tik šiaip, kad būtų ramiau. Tik reikia gana nuolatinės priežiūros ir kažkiek padirbėti.

Kita dalis – Apache direktyvos ir optimizavimas. Neseniai pašalinome .htaccess palaikymą. Tai labai patogu kai viską galima pakonfigūruoti vos prireikia, bet jei leidi AllowOverride direktyvą, tai Apache kiekvieno kreipimosi metu ieško visų .htaccess per visą direktorijų medžio šaką, kurioje yra failas, į kurį kreipiamasi. Kreipimųsi į diską nuo to daugėja 10x. Bendras serverio našumas, perkėlus viską į httpd.conf, padidėjo gal porą-trejetą kartų. Tai yra daug, labai pasijunta.

Apache, Varnish ir kiti fokusai

DoS atakų metu Apache sesijų skaičius kartais išauga neįtikėtinai. Pagal nutylėjimą Apache nustatytas MaxClients parametras yra smarkiai per didelis, kaip stiprią ir nuolatinę apkrovą turinčioms sistemoms (nebent jūsų serveris bus koks mainfreimas). Vienas klientas – tai apie 200 megabaitų ramo ar daugiau. 5 klientai yra gigabaitas. Atrodo kad galima naudoti swap, bet tai tiktų tik silpno apkrovimo sistemoms, kuriose lieka laiko tam, kad kažką swapint iš atminties ir atgal, o tarpuose palaukti. Čia taip nesigauna, nes niekas neduoda palaukti.

Jei tik prasideda swap naudojimas, kietai apkrautoje sistemoje serveris pereina į mūšos režimą (thrashing, pirmyn-atgal tarp disko ir atminties) ir tada būna baisu, nes viskas ima dirbti daug lėčiau, o dėl to sesijų ima kauptis dar daugiau. O kai sesijų ima kauptis dar daugiau, tai viskas dar labiau eina į diską, o dėl to dar viskas gaunasi lėčiau. Ir taip toliau, ir taip toliau. Mirties spiralė, nuo kurios serveris gali uždusti labai staigiai.

Prieš daug metų kartais turėdavom tokią bėdą su thrashingu, kai būdavo DoS ar itin intensyvūs spamo robotai. Jos neliko kai MaxClients padarėme labai mažą (vos kelios dešimtys), kad net maksimalaus apkrovimo metu swap nebūtų naudojamas. Kai sistema gauna begales užklausų nuolat, nei vienas httpd demonas niekada neturi pakliūti į swapą, nes tai reikš perėjimą į mirties spiralę. Default nustatymai httpd.conf faile yra netinkami nuolat kietai apkrautoms sistemoms ir ypač dideliems ilgiau trunkantiems pikiniams šuoliams.

Žodžiu, jei norit kad serveris ant didelių pikų nedustų, o skraidytų kaip skraidęs, nustatykit kietas ribas su MaxClients ir panašiais parametrais (paskaičiuokit kiek ramo turit skirt kiekvienam klientui, nustebsit kad labai nedaug išties galima aptarnauti), Timeout sumažinkit dešimt kartų. PHP skriptams vykdymo laikų ribojimus irgi uždėti reikia, nes geriau retkarčiais kažkam išlįs Varnish 503 Unavailable, negu visiškai užmuš Apache serverį.

Galų gale Varnish reverse proxy. Labai geras dalykas pastatyti, nors vietoje jo iš principo galima naudoti ir atskirą Apache proxy režime, ir Squid, ir Nginx, ir dar ką nors. Net ne tiek svarbu ką naudosit (mes tai Varnish labai patariam), svarbu kad atsirastų truputis statinio kontento kešavimo ir būtų nuimti sesijų kabojimai. Net sunku pasakyti, kiek kartų tai pagerina našumą, gal 10, o gal ir dar daugiau. Statinis kontentas kešuojamas per Varnish taip gerai, kad pažiūrėjus į Apache logus, atrodo, jog išvis niekas nežiūri jokių paveiksliukų, jokio CSS, jokio JavaScript, išvis nieko, visi tik pliką sugeneruotą HTML turinį ima iš serverio.

Bet reikia turėt omeny, kad su gerais dalykais irgi kartais būna bajerių, taip ir su Varnish. Ir tiuningas pas tokius daiktus kartais gana subtilus (Varnish dar ir konfigai baisūs). Bet visada malonu matyti, kaip 0,05% CPU naudojantis Varnish sugeba aptarnauti didžiąją dalį visų užklausų, gal kokius 95% ar daugiau.

Varnish dokumentacijoje kažkur nurodo kad cmd line demono parametras -t yra tas pats kas default_ttl, bet tai ne visai gryna tiesa (bent jau pas mūsiškį Varnish). Nustatykit cmd line -t parametrą, kad nebūtų tuščia ir nemažai gali pasikeisti. Paskutinis mūsų pastrigimas, kuris buvo prieš kelias dienas, tuokart buvo išspręstas, tiesiog nurodant tą parametrą. Paaiškėjo, kad per DoS ataką kažkokiu būdu ėmė dusint patį Varnish kešą, taip užmušdami jau ne Apache, o patį Varnish, kuris nuo DoS turi apsaugoti (pakilimas iki 70-80% CPU naudojimo, t.y., kokį tūkstantį kartų). Taip ir išsprendėm, kai nustatėm tą minimum ttl per Varnish paleidimo parametrus. Net neaišku, kodėl to reikėjo. Kartais tenka tiesiog ieškoti kažkokio sprendimo, kol surasi.

Kartais būna ir visai kvailų dalykų. Prieš kelerius metus vieni antivirusų kūrėjai daugelį adminų visame pasaulyje pradžiugino. Tokie Comodo, kad juos kur peklon. Paleisti tūkstančius GET užklausų per sekundę į serverį – čia visai be proto reikia būti. Blogiau net už spamerius. Tegul serverio jie ir nesugebėdavo savo crawlinimais visai užmušti, bet tuo metu tiesiog puslapiai pusiau kreivai pasikraudavo, su kas antru paveiksliuku ir iš kas antro karto, nes kas antrai užklausai nelikdavo resursų. Mes tada labai nustebom, kai supratom, kad čia ne DoS ir ne spamas, o kažkokia antivirusų firma. Tokie antivirusų kūrėjai blogesni už virusus, su kuriais jie kovoja.

Žodžiu, ne toks jau paprastas tas adminų darbas. Kai viskas veikia, tai visiems atrodo, kad taip ir turi būti. O kai neveikia, tai keikia adminus. Nepagalvoja dažnai žmonės, kiek reikia dirbti ir aiškintis, kad sistema gerai veiktų ir darytų ką reikia metų metais.

Pasidalinkite mūsų straipsniu...

Facebook

Twitter

Google+