{"id":31924,"date":"2019-10-31T21:44:01","date_gmt":"2019-10-31T18:44:01","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy\/"},"modified":"2019-10-31T21:44:01","modified_gmt":"2019-10-31T18:44:01","slug":"ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy","status":"publish","type":"post","link":"https:\/\/prohoster.info\/hu\/blog\/administrirovanie\/ddos-v-pomoshh-kak-my-provodim-stress-i-nagruzochnye-testy","title":{"rendered":"DDoS a seg\u00edts\u00e9g\u00fcnkre: hogyan v\u00e9gezz\u00fck a stressz- \u00e9s terhel\u00e9si teszteket","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"DDoS
\n
\nA Variti c\u00e9g bot- \u00e9s DDoS-t\u00e1mad\u00e1sok elleni v\u00e9delmet fejleszt, valamint stressz- \u00e9s terhel\u00e9ses tesztel\u00e9st v\u00e9gez. A HighLoad++ 2018 konferenci\u00e1n arr\u00f3l besz\u00e9lt\u00fcnk, hogyan v\u00e9dhetj\u00fck meg er\u0151forr\u00e1sainkat a k\u00fcl\u00f6nf\u00e9le t\u00e1mad\u00e1sokt\u00f3l. R\u00f6viden: izol\u00e1lja a rendszer r\u00e9szeit, haszn\u00e1ljon felh\u0151szolg\u00e1ltat\u00e1sokat \u00e9s CDN-t, \u00e9s friss\u00fclj\u00f6n rendszeresen. De specializ\u00e1lt v\u00e9delmi c\u00e9gek n\u00e9lk\u00fcl nem boldogulhat. \ud83d\ude42<\/i>
\n<\/a><\/noindex>
\nA sz\u00f6veg elolvas\u00e1sa el\u0151tt ismerkedjen meg a r\u00f6vid \u00f6sszefoglal\u00f3kkal a konferencia weboldal\u00e1n<\/a><\/noindex>.
\nHa pedig nem szeret olvasni, vagy csak meg szeretn\u00e9 n\u00e9zni a vide\u00f3t, az el\u0151ad\u00e1sunk felv\u00e9tele az al\u00e1bbi spoiler alatt tal\u00e1lhat\u00f3.<\/p>\n

Az el\u0151ad\u00e1s videofelv\u00e9tele<\/b>

\r\n \"Vide\u00f3\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Sok c\u00e9g m\u00e1r tud terhel\u00e9ses tesztel\u00e9st v\u00e9gezni, de nem mindenki v\u00e9gez stressz-tesztel\u00e9st. N\u00e9h\u00e1ny \u00fcgyfel\u00fcnk azt hiszi, hogy a weboldaluk sebezhetetlen, mert van highload rendszer\u00fck, \u00e9s az j\u00f3l v\u00e9di a t\u00e1mad\u00e1sokt\u00f3l. Mi azonban megmutatjuk, hogy ez nem teljesen igaz.
\nTerm\u00e9szetesen a tesztel\u00e9s el\u0151tt mindig megkapjuk az \u00fcgyf\u00e9l enged\u00e9ly\u00e9t, al\u00e1\u00edr\u00e1ssal \u00e9s pecs\u00e9ttel, \u00e9s a mi seg\u00edts\u00e9g\u00fcnkkel DDoS-t\u00e1mad\u00e1st senkire nem lehet ir\u00e1ny\u00edtani. A tesztel\u00e9st az \u00fcgyf\u00e9l \u00e1ltal v\u00e1lasztott id\u0151pontban v\u00e9gezz\u00fck, amikor a weboldal l\u00e1togatotts\u00e1ga minim\u00e1lis, \u00edgy a hozz\u00e1f\u00e9r\u00e9si probl\u00e9m\u00e1k nem befoly\u00e1solj\u00e1k az \u00fcgyfeleket. Tov\u00e1bb\u00e1, mivel a tesztel\u00e9si folyamat sor\u00e1n b\u00e1rmi elromolhat, folyamatos kapcsolatban \u00e1llunk az \u00fcgyf\u00e9llel. Ez lehet\u0151v\u00e9 teszi, hogy ne csak az el\u00e9rt eredm\u00e9nyekr\u0151l sz\u00e1moljunk be, hanem v\u00e1ltoztat\u00e1sokra is lehet\u0151s\u00e9g ny\u00edljon a tesztel\u00e9s sor\u00e1n. A tesztel\u00e9s befejez\u00e9sekor mindig k\u00e9sz\u00edt\u00fcnk egy jelent\u00e9st, amelyben felv\u00e1zoljuk a felfedezett hi\u00e1nyoss\u00e1gokat \u00e9s aj\u00e1nl\u00e1sokat adunk a weboldal gyenge pontjainak megsz\u00fcntet\u00e9s\u00e9re. <\/p>\n

Hogyan dolgozunk<\/h3>\n

\nA tesztel\u00e9s sor\u00e1n botnetet emul\u00e1lunk. Mivel olyan \u00fcgyfelekkel dolgozunk, akik nincsenek a h\u00e1l\u00f3zatunkban, hogy a teszt ne \u00e9rjen v\u00e9get az els\u0151 percben a limitek vagy v\u00e9delem aktiv\u00e1l\u00f3d\u00e1sa miatt, a terhel\u00e9st nem egy IP-r\u0151l, hanem a saj\u00e1t alh\u00e1l\u00f3zatunkr\u00f3l ind\u00edtjuk. Ezen t\u00falmen\u0151en, jelent\u0151s terhel\u00e9s el\u0151id\u00e9z\u00e9s\u00e9hez van egy el\u00e9g er\u0151s tesztkiszolg\u00e1l\u00f3nk is.<\/p>\n

A postul\u00e1tumok<\/h3>\n

<\/p>\n

Sok \u2014 nem jelenti azt, hogy j\u00f3<\/b>
\nMin\u00e9l kisebb terhel\u00e9st tudunk el\u00e9rni, amikor a rendszer meghib\u00e1sodik, ann\u00e1l jobb. Ha siker\u00fcl el\u00e9rni, hogy a weboldal egy m\u00e1sodperces vagy ak\u00e1r egy perces egyetlen k\u00e9r\u00e9st\u0151l is le\u00e1lljon, az nagyszer\u0171. Mert a balsors t\u00f6rv\u00e9nye szerint a felhaszn\u00e1l\u00f3k vagy a t\u00e1mad\u00f3k v\u00e9letlen\u00fcl ebbe a sebezhet\u0151s\u00e9gbe fognak belebotlani. <\/p><\/blockquote>\n

A r\u00e9szleges hiba jobb, mint a teljes.<\/b>
\nMindig javasoljuk heterog\u00e9n rendszerek l\u00e9trehoz\u00e1s\u00e1t. \u00c9s a sz\u00e9tv\u00e1laszt\u00e1snak pontosan a fizikai szinten kell megt\u00f6rt\u00e9nnie, nem csup\u00e1n kont\u00e9neriz\u00e1l\u00e1ssal. Fizikai sz\u00e9tv\u00e1laszt\u00e1s eset\u00e9n, m\u00e9g ha a weboldalon valami meghib\u00e1sodik is, nagyobb a val\u00f3sz\u00edn\u0171s\u00e9ge, hogy a teljes m\u0171k\u00f6d\u00e9s nem szakad meg, \u00e9s a felhaszn\u00e1l\u00f3k hozz\u00e1f\u00e9rnek legal\u00e1bb a funkci\u00f3k egy r\u00e9sz\u00e9hez.<\/p><\/blockquote>\n

A helyes architekt\u00fara a stabilit\u00e1s alapja.<\/b>
\nA rendszer hiba\u00e1ll\u00f3s\u00e1g\u00e1t \u00e9s k\u00e9pess\u00e9g\u00e9t, hogy elviselje a t\u00e1mad\u00e1sokat \u00e9s terhel\u00e9seket, a tervez\u00e9si szakaszban kell be\u00e9p\u00edteni, gyakorlatilag az els\u0151 blokkdiagramok skiccel\u00e9sekor a jegyzetf\u00fczetben. Mert ha v\u00e9gzetes hib\u00e1k cs\u00fasznak be, akkor k\u00e9s\u0151bb kijav\u00edtani \u0151ket lehets\u00e9ges, de nagyon neh\u00e9z.<\/p><\/blockquote>\n

J\u00f3nak kell lennie nemcsak a k\u00f3dnak, hanem a konfigur\u00e1ci\u00f3nak is.<\/b>
\nSokan \u00fagy gondolj\u00e1k, hogy egy j\u00f3 fejleszt\u0151csapat garancia a szolg\u00e1ltat\u00e1s hiba\u00e1ll\u00f3s\u00e1g\u00e1ra. A j\u00f3 fejleszt\u0151csapat val\u00f3ban sz\u00fcks\u00e9ges, de sz\u00fcks\u00e9g van megfelel\u0151 \u00fczemeltet\u00e9sre \u00e9s j\u00f3 DevOps-ra is. Teh\u00e1t sz\u00fcks\u00e9g van szakemberekre, akik helyesen konfigur\u00e1lj\u00e1k a Linuxot \u00e9s a h\u00e1l\u00f3zatot, \u00e9s megfelel\u0151en \u00edrj\u00e1k meg a konfigur\u00e1ci\u00f3kat az nginx-ben, be\u00e1ll\u00edtj\u00e1k a korl\u00e1tokat \u00e9s \u00edgy tov\u00e1bb. Ellenkez\u0151 esetben a rendszer j\u00f3l m\u0171k\u00f6dik a teszten, de a termel\u00e9sben egy id\u0151 ut\u00e1n minden t\u00f6nkremegy.<\/p><\/blockquote>\n

A terhel\u00e9s- \u00e9s stressztesztel\u00e9s elt\u00e9r\u00e9sei.<\/b>
\nA terhel\u00e9s tesztel\u00e9s lehet\u0151v\u00e9 teszi a rendszer m\u0171k\u00f6d\u00e9si hat\u00e1rainak felt\u00e1r\u00e1s\u00e1t. A stressztesztel\u00e9s a rendszer gyenge pontjainak keres\u00e9s\u00e9re ir\u00e1nyul, \u00e9s arra haszn\u00e1lj\u00e1k, hogy a rendszert megbonts\u00e1k, \u00e9s megn\u00e9zz\u00e9k, hogyan viselkedik a k\u00fcl\u00f6nf\u00e9le r\u00e9szek meghib\u00e1sod\u00e1sa sor\u00e1n. A folyamat sor\u00e1n a terhel\u00e9s t\u00edpusa \u00e1ltal\u00e1ban ismeretlen a megrendel\u0151 sz\u00e1m\u00e1ra a stressztesztel\u00e9s kezdete el\u0151tt.<\/p><\/blockquote>\n

<\/p>\n

Az L7 t\u00e1mad\u00e1sok jellegzetess\u00e9gei.<\/h3>\n

\nA terhel\u00e9seket \u00e1ltal\u00e1ban L7 \u00e9s L3&4 szint\u0171 terhel\u00e9sekre osztjuk. Az L7 a fels\u0151 alkalmaz\u00e1si szinten jelentkez\u0151 terhel\u00e9s, amit leggyakrabban HTTP-k\u00e9nt \u00e9rtenek, de mi minden TCP protokollszint\u0171 terhel\u00e9st \u00e9rtenek alatta.
\nAz L7 t\u00e1mad\u00e1soknak vannak bizonyos megk\u00fcl\u00f6nb\u00f6ztet\u0151 jellemz\u0151ik. El\u0151sz\u00f6r is, ezek k\u00f6zvetlen\u00fcl az alkalmaz\u00e1sra ir\u00e1nyulnak, \u00edgy h\u00e1l\u00f3zati eszk\u00f6z\u00f6kkel neh\u00e9z lehet azokat elh\u00e1r\u00edtani. Az ilyen t\u00e1mad\u00e1sok logik\u00e1t haszn\u00e1lnak, \u00e9s ennek k\u00f6sz\u00f6nhet\u0151en rendk\u00edv\u00fcl hat\u00e9konyan, m\u00e9g viszonylag alacsony forgalom mellett is k\u00e9pesek CPU-t, mem\u00f3ri\u00e1t, diszket, adatb\u00e1zist \u00e9s egy\u00e9b er\u0151forr\u00e1sokat fogyasztani.<\/p>\n

HTTP Flood<\/h3>\n

\nB\u00e1rmilyen t\u00e1mad\u00e1s eset\u00e9n k\u00f6nnyebb terhel\u00e9st gener\u00e1lni, mint kezelni, \u00e9s ez az L7 eset\u00e9ben is \u00edgy van. A t\u00e1mad\u00e1s forgalm\u00e1t nem mindig k\u00f6nny\u0171 megk\u00fcl\u00f6nb\u00f6ztetni a legitim forgalomt\u00f3l, \u00e9s a legt\u00f6bb esetben ezt a frekvencia alapj\u00e1n lehet csak meg\u00e1llap\u00edtani, de ha mindez j\u00f3l van megtervezve, a napl\u00f3k alapj\u00e1n nem lehet kimutatni, hol van a t\u00e1mad\u00e1s \u00e9s hol a legitim k\u00e9r\u00e9sek.
\nEls\u0151 p\u00e9ldak\u00e9nt n\u00e9zz\u00fck meg a HTTP Flood t\u00e1mad\u00e1st. A grafikonn l\u00e1that\u00f3, hogy az ilyen t\u00e1mad\u00e1sok \u00e1ltal\u00e1ban nagyon intenz\u00edvek, az al\u00e1bbi p\u00e9ld\u00e1ban a cs\u00facs forgalom meghaladta a 600 ezer k\u00e9r\u00e9st percenk\u00e9nt.<\/p>\n

\"DDoS
\n
\nA HTTP Flood a legegyszer\u0171bb m\u00f3dja a terhel\u00e9s gener\u00e1l\u00e1s\u00e1nak. \u00c1ltal\u00e1ban valamilyen terhel\u00e9s tesztel\u0151 eszk\u00f6zt haszn\u00e1lnak, p\u00e9ld\u00e1ul ApacheBench-t, \u00e9s be\u00e1ll\u00edtj\u00e1k a k\u00e9r\u00e9st \u00e9s a c\u00e9lt. Ezzel az egyszer\u0171 megk\u00f6zel\u00edt\u00e9ssel nagy a val\u00f3sz\u00edn\u0171s\u00e9ge annak, hogy a szerver cache-el\u00e9s\u00e9vel tal\u00e1lkozunk, de ezt k\u00f6nnyen meg lehet ker\u00fclni. P\u00e9ld\u00e1ul v\u00e9letlenszer\u0171 karakterek hozz\u00e1ad\u00e1s\u00e1val a k\u00e9r\u00e9shez, ami arra k\u00e9nyszer\u00edti a szervert, hogy folyamatosan \u00faj oldalt adjon vissza.
\nA terhel\u00e9s gener\u00e1l\u00e1sa sor\u00e1n nem szabad elfelejteni a user-agentet sem. Sok n\u00e9pszer\u0171 tesztel\u0151 eszk\u00f6z user-agentjeit a rendszeradminisztr\u00e1torok kisz\u0171rik, \u00e9s ilyenkor a terhel\u00e9s egyszer\u0171en nem jut el a backendhez. A hozz\u00e1adott, r\u00e9szben vagy teljesen \u00e9rv\u00e9nyes b\u00f6ng\u00e9sz\u0151fejl\u00e9cek haszn\u00e1lat\u00e1val jelent\u0151sen jav\u00edthat\u00f3 az eredm\u00e9ny.
\nA HTTP Flood t\u00e1mad\u00e1sok, b\u00e1rmennyire egyszer\u0171ek is, saj\u00e1t h\u00e1tr\u00e1nyaikkal rendelkeznek. El\u0151sz\u00f6r is, a terhel\u00e9s gener\u00e1l\u00e1s\u00e1hoz nagy teljes\u00edtm\u00e9ny sz\u00fcks\u00e9ges. M\u00e1sodszor, az ilyen t\u00e1mad\u00e1sok rendk\u00edv\u00fcl k\u00f6nnyen \u00e9szlelhet\u0151k, k\u00fcl\u00f6n\u00f6sen, ha egyetlen c\u00edmr\u0151l sz\u00e1rmaznak. Ennek eredm\u00e9nyek\u00e9nt a k\u00e9r\u00e9sek azonnal kisz\u0171r\u00e9sre ker\u00fclnek, ak\u00e1r a rendszeradminisztr\u00e1torok, ak\u00e1r a szolg\u00e1ltat\u00f3 szintj\u00e9n. <\/p>\n

Mit \u00e9rdemes keresni<\/h3>\n

\nA lek\u00e9rdez\u00e9sek m\u00e1sodpercenk\u00e9nti sz\u00e1m\u00e1nak cs\u00f6kkent\u00e9s\u00e9hez, an\u00e9lk\u00fcl hogy a hat\u00e9konys\u00e1g cs\u00f6kkenne, egy kis kreativit\u00e1sra van sz\u00fcks\u00e9g, \u00e9s \u00e9rdemes felfedezni a weboldalt. Nemcsak a csatorn\u00e1t vagy a szervert lehet terhelni, hanem az alkalmaz\u00e1s egyes r\u00e9szeit is, p\u00e9ld\u00e1ul az adatb\u00e1zisokat vagy a f\u00e1jlrendszereket. Emellett \u00e9rdemes megvizsg\u00e1lni azokat a helyeket az oldalon, ahol nagy sz\u00e1m\u00edt\u00e1sok zajlanak: kalkul\u00e1torok, term\u00e9kaj\u00e1nl\u00f3 oldalak \u00e9s egyebek. V\u00e9g\u00fcl gyakran el\u0151fordul, hogy egy php-script gener\u00e1lja az oldalt t\u00f6bb sz\u00e1zezer sorb\u00f3l. Egy ilyen script is jelent\u0151sen terheli a szervert, \u00e9s t\u00e1mad\u00e1si c\u00e9lpontt\u00e1 v\u00e1lhat.<\/p>\n

Hol keress\u00fcnk<\/h3>\n

\nAmikor a tesztel\u00e9s el\u0151tt \u00e1tvizsg\u00e1ljuk az er\u0151forr\u00e1st, akkor els\u0151sorban mag\u00e1ra az oldalra \u00f6sszpontos\u00edtunk. Mindenf\u00e9le bevitelmez\u0151t, neh\u00e9z f\u00e1jlokat keres\u00fcnk \u2014 gyakorlatilag mindent, ami probl\u00e9m\u00e1t okozhat az er\u0151forr\u00e1snak \u00e9s lass\u00edthatja annak m\u0171k\u00f6d\u00e9s\u00e9t. Itt seg\u00edtenek a Google Chrome \u00e9s Firefox egyszer\u0171 fejleszt\u0151i eszk\u00f6zei, amelyek megmutatj\u00e1k az oldal v\u00e1laszidej\u00e9t.
\nAzt is vizsg\u00e1ljuk a szubdomainjeinket. P\u00e9ld\u00e1ul, ha van egy online bolt, abc.com, \u00e9s van egy admin.abc.com szubdomainje. Val\u00f3sz\u00edn\u0171leg ez egy adminisztr\u00e1ci\u00f3s fel\u00fclet, amely bejelentkez\u00e9st ig\u00e9nyel, de ha erre terhel\u00e9st enged\u00fcnk, probl\u00e9m\u00e1kat okozhat a f\u0151 er\u0151forr\u00e1s sz\u00e1m\u00e1ra.
\nA weboldalnak lehet api.abc.com szubdomainje. Val\u00f3sz\u00edn\u0171leg ez egy mobilalkalmaz\u00e1sok sz\u00e1m\u00e1ra k\u00e9sz\u00fclt er\u0151forr\u00e1s. Az alkalmaz\u00e1s megtal\u00e1lhat\u00f3 az App Store-ban vagy a Google Playen, l\u00e9trehozhatunk egy speci\u00e1lis sz\u00e1m\u00edt\u00f3g\u00e9pes hozz\u00e1f\u00e9r\u00e9si pontot, felt\u00e9rk\u00e9pezhetj\u00fck az API-t, \u00e9s regisztr\u00e1lhatunk tesztfi\u00f3kokat. A probl\u00e9ma az, hogy sokan \u00fagy gondolj\u00e1k, hogy minden, ami bejelentkez\u00e9st ig\u00e9nyel, v\u00e9dve van a szolg\u00e1ltat\u00e1smegtagad\u00e1sos t\u00e1mad\u00e1sokkal szemben. \u00c1ll\u00edt\u00f3lag a bejelentkez\u00e9s a legjobb CAPTCHA, de ez nem igaz. 10-20 tesztfi\u00f3k l\u00e9trehoz\u00e1sa egyszer\u0171, \u00e9s ha ezeket l\u00e9trehoztuk, hozz\u00e1f\u00e9r\u00fcnk a bonyolult \u00e9s nem v\u00e9dett funkci\u00f3khoz.
\nTerm\u00e9szetesen megvizsg\u00e1ljuk a t\u00f6rt\u00e9nelmet, a robots.txt-et \u00e9s a WebArchive-t, ViewDNS-t, r\u00e9gi verzi\u00f3kat keres\u00fcnk. N\u00e9ha az t\u00f6rt\u00e9nik, hogy a fejleszt\u0151k kiadt\u00e1k p\u00e9ld\u00e1ul a mail2.yandex.net-t, de a r\u00e9gi verzi\u00f3, a mail.yandex.net, megmaradt. Ez a mail.yandex.net m\u00e1r nem t\u00e1mogatott, nincs r\u00e1jdolgoz\u00e1s, de tov\u00e1bbra is fogyasztja az adatb\u00e1zist. Ennek megfelel\u0151en a r\u00e9gi verzi\u00f3 seg\u00edts\u00e9g\u00e9vel hat\u00e9konyan kihaszn\u00e1lhat\u00f3k a backend er\u0151forr\u00e1sok \u00e9s minden, ami a tov\u00e1bbi megjelen\u00edt\u00e9st szolg\u00e1lja. Term\u00e9szetesen ez nem mindig fordul el\u0151, de hasonl\u00f3 helyzetekkel m\u00e9g mindig viszonylag gyakran tal\u00e1lkozunk.
\nTerm\u00e9szetesen, elemezz\u00fck az \u00f6sszes k\u00e9relem param\u00e9tereit, a cookie strukt\u00far\u00e1j\u00e1t. Mondjuk, be lehet \u00e1gyazni egy JSON t\u00f6mbbe valamilyen \u00e9rt\u00e9ket a cookie-ban, l\u00e9trehozni egy nagy m\u00e9lys\u00e9get, \u00e9s ezzel sok\u00e1ig m\u0171k\u00f6d\u00e9sre b\u00edrni az er\u0151forr\u00e1st.<\/p>\n

Keres\u00e9si terhel\u00e9s<\/h3>\n

\nAmi el\u0151sz\u00f6r eszembe jut a weboldal vizsg\u00e1latakor, az az adatb\u00e1zis megterhel\u00e9se, mivel a keres\u00e9s szinte mindenhol jelen van, \u00e9s sajnos szinte mindenhol gyeng\u00e9n v\u00e9dett. Valami\u00e9rt a fejleszt\u0151k nem ford\u00edtanak elegend\u0151 figyelmet a keres\u00e9sre. De itt van egy javaslat \u2014 nem szabad egys\u00e9ges k\u00e9r\u00e9seket tenni, mert tal\u00e1lkozhatunk a gyors\u00edt\u00f3t\u00e1raz\u00e1ssal, mint a HTTP \u00e1rad\u00e1s eset\u00e9n.
\nAz adatb\u00e1zisba t\u00f6rt\u00e9n\u0151 v\u00e9letlenszer\u0171 k\u00e9r\u00e9sek v\u00e9grehajt\u00e1sa sem mindig hat\u00e9kony. Sokkal jobb l\u00e9trehozni egy kulcssz\u00f3list\u00e1t, amely a keres\u00e9shez kapcsol\u00f3dik. Ha visszat\u00e9r\u00fcnk egy p\u00e9lda online boltj\u00e1ra: mondjuk, az oldal gumiabroncsokat \u00e1rul, \u00e9s lehet\u0151v\u00e9 teszi a gumiabroncsok sug\u00e1r\u00e1nak, a t\u00edpus\u00e1nak \u00e9s egy\u00e9b param\u00e9tereinek megad\u00e1s\u00e1t. Ennek megfelel\u0151en a relev\u00e1ns szavak kombin\u00e1ci\u00f3i sokkal bonyolultabb k\u00f6r\u00fclm\u00e9nyek k\u00f6z\u00f6tt m\u0171k\u00f6dtetik az adatb\u00e1zist.
\nEzen k\u00edv\u00fcl \u00e9rdemes haszn\u00e1lni a pagin\u00e1ci\u00f3t: a keres\u00e9snek sokkal nehezebb \u00e1tadni az utols\u00f3 el\u0151tti tal\u00e1lati oldalt, mint az els\u0151t. Teh\u00e1t a pagin\u00e1ci\u00f3val kicsit v\u00e1ltozatosabb\u00e1 tehetj\u00fck a terhel\u00e9st.
\nAz al\u00e1bbi p\u00e9lda bemutatja a keres\u00e9si terhel\u00e9st. L\u00e1that\u00f3, hogy a teszt els\u0151 m\u00e1sodperc\u00e9t\u0151l kezdve t\u00edz k\u00e9r\u00e9s m\u00e1sodpercenk\u00e9nt a weboldal lefagyott \u00e9s nem v\u00e1laszolt.<\/p>\n

\"DDoS
\n<\/p>\n

Mi van, ha nincs keres\u00e9s?<\/h3>\n

\nHa nincs keres\u00e9s, az nem jelenti azt, hogy az oldal nem tartalmaz m\u00e1s sebezhet\u0151 bemeneti mez\u0151ket. Ilyen mez\u0151 lehet a bejelentkez\u00e9s. Manaps\u00e1g a fejleszt\u0151k szeretnek bonyolult hash-eket k\u00e9sz\u00edteni, hogy megv\u00e9dj\u00e9k a felhaszn\u00e1l\u00f3nevek adatb\u00e1zis\u00e1t a rainbow table t\u00e1mad\u00e1sok ellen. Ez j\u00f3, de ezek a hash-ek nagy CPU er\u0151forr\u00e1st ig\u00e9nyelnek. Nagy mennyis\u00e9g\u0171 hamis bejelentkez\u00e9si k\u00eds\u00e9rlet a processzor le\u00e1ll\u00e1s\u00e1t okozhatja, ami miatt az oldal m\u0171k\u00f6d\u00e9se megsz\u0171nik.
\nA weboldalon l\u00e9v\u0151 k\u00fcl\u00f6nf\u00e9le komment\u00e1rok \u00e9s kapcsolatfelv\u00e9teli \u0171rlapok lehet\u0151s\u00e9get adnak nagyon nagy sz\u00f6vegek elk\u00fcld\u00e9s\u00e9re vagy egyszer\u0171en t\u00f6meges spammel\u00e9sre. N\u00e9ha az oldalak elfogadnak be\u00e1gyazott f\u00e1jlokat, bele\u00e9rtve a gzip form\u00e1tumot is. Ilyen esetben p\u00e9ld\u00e1ul fogunk egy 1 TB-os f\u00e1jlt, gzip-pel n\u00e9h\u00e1ny b\u00e1jtra vagy kilob\u00e1jtokra t\u00f6m\u00f6r\u00edtj\u00fck, \u00e9s elk\u00fcldj\u00fck az oldalra. Ut\u00e1na ez kicsomagol\u00f3dik, \u00e9s nagyon \u00e9rdekes hat\u00e1st kelt. <\/p>\n

Rest API<\/h3>\n

\n\u00c9rdemes lenne egy kis figyelmet szentelni az olyan n\u00e9pszer\u0171 szolg\u00e1ltat\u00e1soknak, mint a Rest API. A Rest API v\u00e9delme sokkal nehezebb, mint egy egyszer\u0171 weboldal\u00e9. A Rest API eset\u00e9ben m\u00e9g a jelsz\u00f3tipr\u00f3k \u00e9s m\u00e1s illegitim tev\u00e9kenys\u00e9gek ellen alkalmazott ban\u00e1lis v\u00e9delmi m\u00f3dszerek sem hat\u00e9konyak.
\nA Rest API-t nagyon k\u00f6nny\u0171 felt\u00f6rni, mert k\u00f6zvetlen\u00fcl az adatb\u00e1zisra hivatkozik. Ennek k\u00f6vetkezt\u00e9ben egy ilyen szolg\u00e1ltat\u00e1s le\u00e1ll\u00e1sa s\u00falyos k\u00f6vetkezm\u00e9nyekkel j\u00e1rhat a v\u00e1llalkoz\u00e1sra n\u00e9zve. Az a helyzet, hogy a Rest API \u00e1ltal\u00e1ban nemcsak a f\u0151 weboldalra van r\u00e1kapcsolva, hanem a mobilalkalmaz\u00e1sra, valamint k\u00fcl\u00f6nb\u00f6z\u0151 bels\u0151 \u00fczleti forr\u00e1sokra is. Ha ezek mind le\u00e1llnak, annak hat\u00e1sa sokkal s\u00falyosabb, mint egy egyszer\u0171 weboldal le\u00e1ll\u00e1sa eset\u00e9n. <\/p>\n

Terhel\u00e9s neh\u00e9z tartalomra<\/h3>\n

\nHa azt javasolj\u00e1k nek\u00fcnk, hogy tesztelj\u00fcnk egy egyszer\u0171 egyoldalas alkalmaz\u00e1st, landingt, n\u00e9vjegy-oldalt, amelyeknek nincs \u00f6sszetett funkcionalit\u00e1suk, akkor keress\u00fck a neh\u00e9z tartalmakat. P\u00e9ld\u00e1ul nagy k\u00e9peket, amelyeket a szerver szolg\u00e1ltat, bin\u00e1ris f\u00e1jlokat, pdf-dokument\u00e1ci\u00f3t \u2014 mindezt megpr\u00f3b\u00e1ljuk let\u00f6lteni. Az ilyen tesztek j\u00f3l megterhelik a f\u00e1jlrendszert \u00e9s elz\u00e1rj\u00e1k a csatorn\u00e1kat, ez\u00e9rt hat\u00e9konyak. Teh\u00e1t ha nem is terheled le a szervert nagym\u00e9ret\u0171 f\u00e1jlok let\u00f6lt\u00e9s\u00e9vel alacsony sebess\u00e9ggel, akkor egyszer\u0171en csak elz\u00e1rod a c\u00e9lkiszolg\u00e1l\u00f3 csatorn\u00e1j\u00e1t, \u00e9s \u00edgy el\u00e9rhetetlens\u00e9g l\u00e9p fel.
\nEgy ilyen teszt p\u00e9ld\u00e1j\u00e1n l\u00e1that\u00f3, hogy 30 RPS sebess\u00e9gn\u00e9l a weboldal nem v\u00e1laszolt, vagy 500-as szerver hib\u00e1kat adott vissza.<\/p>\n

\"DDoS
\n
\nNe felejts\u00fck el a szerverek be\u00e1ll\u00edt\u00e1sait sem. Gyakran tal\u00e1lkozunk azzal, hogy valaki v\u00e1s\u00e1rol egy virtu\u00e1lis g\u00e9pet, telep\u00edt r\u00e1 Apache-ot, minden alap\u00e9rtelmezetten van be\u00e1ll\u00edtva, elhelyez egy PHP-alkalmaz\u00e1st, \u00e9s itt az eredm\u00e9ny. <\/p>\n

\"DDoS
\n
\nItt a terhel\u00e9s a gy\u00f6k\u00e9rbe ment, \u00e9s mind\u00f6ssze 10 RPS-t tett ki. V\u00e1rtunk 5 percet, \u00e9s a szerver le\u00e1llt. Az ok\u00e1t igaz\u00e1b\u00f3l nem tudni, de felt\u00e9telezhet\u0151, hogy egyszer\u0171en mem\u00f3ri\u00e1t fogyasztott el, \u00e9s ez\u00e9rt nem tudott v\u00e1laszolni.<\/p>\n

Hull\u00e1m alap\u00fa<\/h3>\n

\nAz elm\u00falt egy-k\u00e9t \u00e9vben a hull\u00e1m t\u00e1mad\u00e1sok meglehet\u0151sen n\u00e9pszer\u0171v\u00e9 v\u00e1ltak. Ennek oka, hogy sok szervezet k\u00fcl\u00f6nb\u00f6z\u0151 eszk\u00f6z\u00f6ket v\u00e1s\u00e1rol a DDoS elleni v\u00e9delem \u00e9rdek\u00e9ben, amelyeknek statisztik\u00e1k felhalmoz\u00e1s\u00e1hoz van sz\u00fcks\u00e9g\u00fck az t\u00e1mad\u00e1sok kisz\u0171r\u00e9s\u00e9nek megkezd\u00e9s\u00e9hez. Ez\u00e9rt az els\u0151 30-40 m\u00e1sodpercben nem sz\u0171rik meg a t\u00e1mad\u00e1st, mert adatokat gy\u0171jtenek \u00e9s tanulnak. Ennek megfelel\u0151en ezekben a 30-40 m\u00e1sodpercben annyi k\u00e9r\u00e9s \u00e9rkezik, hogy az er\u0151forr\u00e1s hossz\u00fa ideig le\u00e1ll, am\u00edg az \u00f6sszes k\u00e9r\u00e9s rendez\u0151dik.
\nA k\u00f6vetkez\u0151 t\u00e1mad\u00e1s eset\u00e9ben 10 perces id\u0151intervallum volt, ezut\u00e1n pedig egy \u00faj, \u00e1talak\u00edtott t\u00e1mad\u00e1shull\u00e1m \u00e9rkezett.<\/p>\n

\"DDoS
\n
\nTeh\u00e1t a v\u00e9delem megtanulta a sz\u0171r\u00e9st, de j\u00f6tt egy \u00faj, teljesen m\u00e1s t\u00e1mad\u00e1shull\u00e1m, \u00e9s a v\u00e9delem ism\u00e9t tanulni kezdett. Gyakorlatilag a sz\u0171r\u00e9s le\u00e1ll, a v\u00e9delem hat\u00e1stalann\u00e1 v\u00e1lik, \u00e9s a weboldal el\u00e9rhetetlenn\u00e9 v\u00e1lik.
\nA hull\u00e1m t\u00e1mad\u00e1sokra jellemz\u0151k a rendk\u00edv\u00fcl magas cs\u00facs\u00e9rt\u00e9kek, el\u00e9rheti a sz\u00e1zezer vagy ak\u00e1r egymilli\u00f3 k\u00e9r\u00e9st m\u00e1sodpercenk\u00e9nt, az L7 szinten. Ha az L3&4-r\u0151l besz\u00e9l\u00fcnk, ott sz\u00e1z gigabit forgalom is lehet, vagy ennek megfelel\u0151en sz\u00e1z milli\u00f3 csomag m\u00e1sodpercenk\u00e9nt.
\nEzeknek a t\u00e1mad\u00e1soknak a probl\u00e9m\u00e1ja a szinkroniz\u00e1ci\u00f3. A t\u00e1mad\u00e1sok botnetb\u0151l \u00e9rkeznek, \u00e9s ahhoz, hogy egy nagyon nagy, egyszeri cs\u00facsot l\u00e9trehozzunk, magas szint\u0171 szinkroniz\u00e1ci\u00f3 sz\u00fcks\u00e9ges. Ez a koordin\u00e1ci\u00f3 azonban nem mindig siker\u00fcl: n\u00e9ha ki egy parabolikus cs\u00facs keletkezik, amely meglehet\u0151sen csek\u00e9lynek t\u0171nik.<\/p>\n

Nem csak HTTP<\/h3>\n

\nA L7-es szinten k\u00edv\u00fcl az HTTP mellett m\u00e1s protokollokat is szeret\u00fcnk haszn\u00e1lni. \u00c1ltal\u00e1ban egy norm\u00e1l weboldal, k\u00fcl\u00f6n\u00f6sen egy szok\u00e1sos t\u00e1rhely eset\u00e9n, nyitott a levelez\u00e9si protokollokra \u00e9s a MySQL-re. A levelez\u00e9si protokollok kev\u00e9sb\u00e9 \u00e9rz\u00e9kenyek a terhel\u00e9sre, mint az adatb\u00e1zisok, de \u0151ket is el\u00e9g hat\u00e9konyan meg lehet terhelni, ami CPU t\u00falterhel\u00e9shez vezethet a szerveren.
\nTeljesen re\u00e1lisan el\u00e9rt\u00fck a c\u00e9lunkat a 2016-os SSH sebezhet\u0151s\u00e9g kihaszn\u00e1l\u00e1s\u00e1val. Mostanra ezt a sebezhet\u0151s\u00e9get szinte mindenki jav\u00edtotta, de ez nem jelenti azt, hogy az SSH nem terhelhet\u0151. Terhelhet\u0151. Csak egy hatalmas mennyis\u00e9g\u0171 bejelentkez\u00e9si k\u00e9r\u00e9st k\u00fcld\u00fcnk, az SSH szinte az \u00f6sszes CPU-t elfogyasztja a szerveren, \u00e9s a weboldal m\u00e1r egy-k\u00e9t k\u00e9rd\u00e9s m\u00e1sodpercenk\u00e9nt \u00f6sszeomlik. Ennek megfelel\u0151en az egy-k\u00e9t k\u00e9r\u00e9s a napl\u00f3kb\u00f3l semmilyen m\u00f3don nem k\u00fcl\u00f6nb\u00f6ztethet\u0151 meg a legitim terhel\u00e9st\u0151l.
\nSz\u00e1mos kapcsolat, amelyet a szervereken nyitunk, tov\u00e1bbra is relev\u00e1ns. Kor\u00e1bban az Apache volt ezzel probl\u00e9m\u00e1s, manaps\u00e1g viszont az nginx is gyakran \u00edgy van, mivel sokszor alap\u00e9rtelmezetten van be\u00e1ll\u00edtva. Az nginx \u00e1ltal fenntarthat\u00f3 nyitott kapcsolatok sz\u00e1ma korl\u00e1tozott, \u00edgy amint ezt a sz\u00e1mot el\u00e9rj\u00fck, az \u00faj kapcsolatokat m\u00e1r nem fogadja el, \u00e9s ennek k\u00f6vetkezt\u00e9ben a weboldal nem m\u0171k\u00f6dik.
\nA tesztklaszter\u00fcnk elegend\u0151 CPU-val rendelkezik, hogy megt\u00e1madja az SSL k\u00e9zfog\u00e1st. Elvileg, ahogy a gyakorlat mutatja, a botnetek is n\u00e9ha szeretik ezt csin\u00e1lni. Egyfel\u0151l vil\u00e1gos, hogy SSL n\u00e9lk\u00fcl nem lehet meg\u00faszni, mivel ez befoly\u00e1solja a Google tal\u00e1lati sorrendj\u00e9t \u00e9s a biztons\u00e1got. M\u00e1sfel\u0151l azonban az SSL-nek sajnos van egy CPU-val kapcsolatos probl\u00e9m\u00e1ja. <\/p>\n

L3&4<\/h3>\n

\nAmikor L3&4 szint\u0171 t\u00e1mad\u00e1sr\u00f3l besz\u00e9l\u00fcnk, akkor rendszerint a csatorna szint\u0171 t\u00e1mad\u00e1sr\u00f3l van sz\u00f3. Az ilyen t\u00edpus\u00fa terhel\u00e9s szinte mindig megk\u00fcl\u00f6nb\u00f6ztethet\u0151 a legitim terhel\u00e9st\u0151l, kiv\u00e9ve ha SYN-flood t\u00e1mad\u00e1sr\u00f3l van sz\u00f3. A SYN-flood t\u00e1mad\u00e1sok probl\u00e9m\u00e1ja a v\u00e9delmi eszk\u00f6z\u00f6kkel az \u00f3ri\u00e1si mennyis\u00e9gben rejlik. A maxim\u00e1lis L3&4 \u00e9rt\u00e9k 1,5-2 Tbit\/s volt. Ilyen forgalmat m\u00e9g a nagyobb c\u00e9gek, p\u00e9ld\u00e1ul az Oracle \u00e9s a Google is nehezen tudnak kezelni.
\nSYN \u00e9s SYN-ACK<\/p>\n

\u00c1ltal\u00e1ban a t\u00e1mad\u00f3knak nincs olyan erej\u00fck, mint nek\u00fcnk, ez\u00e9rt a t\u00e1mad\u00e1sok szervez\u00e9s\u00e9hez amplifik\u00e1ci\u00f3t alkalmazhatnak. Ez azt jelenti, hogy a t\u00e1mad\u00f3 \u00e1tn\u00e9zi az internetet, \u00e9s olyan sebezhet\u0151 vagy rosszul konfigur\u00e1lt szervereket keres, amelyek p\u00e9ld\u00e1ul egy SYN-csomagra h\u00e1rom SYN-ACK-kal v\u00e1laszolnak. A c\u00e9l szerver c\u00edm\u00e9nek hamis\u00edt\u00e1s\u00e1val egy csomag seg\u00edts\u00e9g\u00e9vel a teljes\u00edtm\u00e9nyt, mondjuk, h\u00e1romszoros\u00e1ra n\u00f6velhetj\u00fck, \u00e9s a forgalmat az \u00e1ldozatra ir\u00e1ny\u00edthatjuk.<\/h3>\n

\nAz amplifik\u00e1ci\u00f3k probl\u00e9m\u00e1ja a neh\u00e9z \u00e9szlelhet\u0151s\u00e9g\u00fckben rejlik. Az utols\u00f3 p\u00e9ld\u00e1k k\u00f6z\u00f6tt eml\u00edthetj\u00fck a h\u00edres memcached sebezhet\u0151s\u00e9get. R\u00e1ad\u00e1sul manaps\u00e1g sz\u00e1mos IoT eszk\u00f6z, IP kamera is megjelent, amelyek szint\u00e9n alap\u00e9rtelmezetten vannak be\u00e1ll\u00edtva, \u00e9s alap\u00e9rtelmezetten helytelen\u00fcl, ez\u00e9rt ezek az eszk\u00f6z\u00f6k gyakran szolg\u00e1lnak a t\u00e1mad\u00f3k sz\u00e1m\u00e1ra.<\/p>\n

\"DDoS
\n
\nBonyolult SYN-flood <\/p>\n

\"DDoS
\n<\/p>\n

SYN-flood<\/h3>\n

\nA SYN-flood tal\u00e1n a leg\u00e9rdekesebb t\u00edpus\u00fa t\u00e1mad\u00e1s a fejleszt\u0151k sz\u00e1m\u00e1ra. A probl\u00e9ma, hogy a rendszergazd\u00e1k gyakran IP-alap\u00fa blokkol\u00e1st haszn\u00e1lnak v\u00e9dekez\u00e9sre. Ennek k\u00f6vetkezt\u00e9ben nemcsak azok a rendszergazd\u00e1k szenvednek, akik scriptek alapj\u00e1n cselekszenek, hanem sajnos egyes v\u00e9delmi rendszerek is, amelyeket nagy p\u00e9nz\u00e9rt v\u00e1s\u00e1rolnak meg.
\nEz a m\u00f3dszer katasztrof\u00e1lis k\u00e1rokat okozhat, hiszen ha a t\u00e1mad\u00f3k hamis\u00edtj\u00e1k IP address<\/a>, akkor a c\u00e9g le fogja tiltani a saj\u00e1t alh\u00e1l\u00f3zat\u00e1t. Amikor a t\u0171zfal letiltja a saj\u00e1t klaszter\u00e9t, k\u00fcls\u0151 interakci\u00f3k t\u00f6rnek \u00f6ssze, \u00e9s az er\u0151forr\u00e1s megs\u00e9r\u00fcl.
\nK\u00f6nnyen el\u00e9rhetj\u00fck a saj\u00e1t h\u00e1l\u00f3zat blokkol\u00e1s\u00e1t. Ha a kliens irod\u00e1j\u00e1ban van Wi-Fi-h\u00e1l\u00f3zat, vagy ha az er\u0151forr\u00e1sok m\u0171k\u00f6d\u00e9s\u00e9t k\u00fcl\u00f6nb\u00f6z\u0151 monitoroz\u00e1sokkal m\u00e9rik, akkor figyelembe vessz\u00fck ennek a monitoroz\u00e1si rendszernek vagy az iroda Wi-Fi kliens\u00e9nek az IP-c\u00edm\u00e9t, \u00e9s ezt haszn\u00e1ljuk forr\u00e1sk\u00e9nt. Az er\u0151forr\u00e1s l\u00e1tsz\u00f3lag el\u00e9rhet\u0151, de a c\u00e9lzott IP-c\u00edmek le vannak tiltva. \u00cdgy p\u00e9ld\u00e1ul letilthat\u00f3 a HighLoad konferencia Wi-Fi-h\u00e1l\u00f3zata, ahol a c\u00e9g \u00faj term\u00e9k\u00e9t mutatj\u00e1k be \u2014 \u00e9s ez bizonyos \u00fczleti \u00e9s gazdas\u00e1gi k\u00f6lts\u00e9geket von maga ut\u00e1n.
\nA tesztel\u00e9s sor\u00e1n nem haszn\u00e1lhatunk memcached-alap\u00fa amplifik\u00e1ci\u00f3t k\u00fcls\u0151 forr\u00e1sokkal, mert meg\u00e1llapod\u00e1sok vannak arr\u00f3l, hogy csak enged\u00e9lyezett IP-c\u00edmekhez hozz\u00e1adott forgalmat fognak kezelni. Ennek megfelel\u0151en a SYN \u00e9s SYN-ACK r\u00e9v\u00e9n v\u00e9gz\u00fcnk amplifik\u00e1ci\u00f3t, amikor egy SYN elk\u00fcld\u00e9s\u00e9re a rendszer k\u00e9t-h\u00e1rom SYN-ACK-kal v\u00e1laszol, \u00e9s ennek k\u00f6vetkezt\u00e9ben a t\u00e1mad\u00e1s k\u00e9tszeres\u00e9re-h\u00e1romszoros\u00e1ra n\u0151. <\/p>\n

Eszk\u00f6z\u00f6k<\/h3>\n

\nAz egyik f\u0151 eszk\u00f6z, amit haszn\u00e1lunk az L7 szint\u0171 terhel\u00e9shez, a Yandex-tank. K\u00fcl\u00f6n\u00f6sen \u00e1gy\u00fak\u00e9nt egy fantomot haszn\u00e1lunk, emellett van n\u00e9h\u00e1ny szkript a l\u0151szerek gener\u00e1l\u00e1s\u00e1ra \u00e9s az eredm\u00e9nyek elemz\u00e9s\u00e9re.
\nA h\u00e1l\u00f3zati forgalom elemz\u00e9s\u00e9re a Tcpdumpot, a szerver elemz\u00e9s\u00e9re pedig az Nmapot haszn\u00e1ljuk. Az L3&4 szint\u0171 terhel\u00e9s l\u00e9trehoz\u00e1s\u00e1ra az OpenSSL-t alkalmazzuk, valamint egy kis saj\u00e1t var\u00e1zslatot a DPDK k\u00f6nyvt\u00e1rral. A DPDK egy Intel k\u00f6nyvt\u00e1r, amely lehet\u0151v\u00e9 teszi a h\u00e1l\u00f3zati interf\u00e9sz k\u00f6zvetlen haszn\u00e1lat\u00e1t a Linux verem megker\u00fcl\u00e9s\u00e9vel, \u00edgy n\u00f6velve a hat\u00e9konys\u00e1got. Term\u00e9szetesen a DPDK-t nemcsak az L3&4, hanem az L7 szinten is haszn\u00e1ljuk, mert lehet\u0151v\u00e9 teszi, hogy nagyon magas terhel\u00e9st hozzunk l\u00e9tre, ak\u00e1r t\u00f6bb milli\u00f3 k\u00e9rd\u00e9ssel m\u00e1sodpercenk\u00e9nt egy g\u00e9pr\u0151l.
\nMi is haszn\u00e1lunk bizonyos forgalomgener\u00e1torokat \u00e9s speci\u00e1lis eszk\u00f6z\u00f6ket, amelyeket specifikus tesztekhez \u00edrunk. Ha visszaeml\u00e9kez\u00fcnk az SSH sebezhet\u0151s\u00e9gre, akkor a fent eml\u00edtett k\u00e9szlettel az nem lehet kihaszn\u00e1lni. Ha a levelez\u00e9si protokollt t\u00e1madjuk, akkor levelez\u00e9si seg\u00e9dprogramokat haszn\u00e1lunk, vagy egyszer\u0171en \u00edrunk r\u00e1juk szkripteket.<\/p>\n

\n

K\u00f6vetkeztet\u00e9sek<\/h3>\n

\n\u00d6sszegz\u00e9s\u00fcl szeretn\u00e9m mondani:<\/p>\n