Кампанія Variti распрацоўвае абарону ад робатаў і DDoS-нападаў, а таксама праводзіць стрэс- і нагрузачнае тэставанне. На канферэнцыі HighLoad++ 2018 мы расказвалі, як засцерагчы рэсурсы ад рознага віду нападаў. Калі коратка: ізалюйце часткі сістэмы, выкарыстоўвайце хмарныя сэрвісы і CDN і рэгулярна абнаўляйцеся. Але без спецыялізаваных кампаній з абаронай вы ўсё роўна не зладзіцеся 🙂
Перад чытаннем тэксту можаце азнаёміцца з кароткімі тэзамі .
А калі вы не любіце чытаць ці проста хочаце паглядзець відэа, запіс нашага даклада ніжэй пад спойлерам.
Відэазапіс даклада
Многія кампаніі ўжо ўмеюць рабіць нагрузачныя тэсціравання, але не ўсё робяць стрэс-тэставанні. Некаторыя нашы заказчыкі думаюць, што іх сайт непаражальны, таму што ў іх ёсць highload сістэма, і яна добра абараняе ад нападаў. Мы ж паказваем, што гэта не зусім праўда.
Зразумела, перад правядзеннем тэстаў мы атрымліваем дазвол ад заказчыка, з подпісам і пячаткай, і з нашай дапамогай DDoS-напад зрабіць ні на каго нельга. Тэставанне праводзіцца ў абранае замоўцам час, калі наведвальнасць яго рэсурсу мінімальная, а праблемы з доступам не адаб'юцца на кліентах. Акрамя таго, паколькі ў працэсе тэсціравання заўсёды можа пайсці нешта не так, у нас ёсць пастаянны кантакт з заказчыкам. Гэта дазваляе не толькі паведамляць аб дасягнутых выніках, але і нешта мяняць падчас тэсціравання. Пры завяршэнні тэставання мы заўсёды складаем справаздачу, у якой паказваем на выяўленыя недахопы і даем рэкамендацыі па ўхіленні слабых месцаў сайта.
Як мы працуем
Пры правядзенні тэсціравання мы эмулюем ботнет. Паколькі мы працуем з кліентамі, якія не размяшчаюцца ў нашых сетках, то для таго, каб тэст не скончыўся на першай жа хвіліне з-за спрацоўвання лімітаў або абароны, мы падаем нагрузку не з аднаго IP, а з уласнай падсеткі. Плюс, для стварэння значнай нагрузкі ў нас ёсць свой дастаткова магутны тэставы сервер.
Пастулаты
Шмат - не значыць добра
Чым меншай нагрузкай мы зможам давесці рэсурс да адмовы, тым лепш. Калі атрымаецца зрабіць так, што сайт спыніць функцыянаваць ад аднаго запыту ў секунду, ці нават ад аднаго запыту ў хвіліну, гэта цудоўна. Таму што па законе подласці карыстачы ці зламыснікі выпадкова патрапяць менавіта ў гэтую ўразлівасць.
Частковая адмова лепшая за поўную
Мы заўсёды раім рабіць сістэмы гетэрагеннымі. Прычым падзяляць іх варта менавіта фізічна, а не толькі кантэйнірызацыяй. У выпадку фізічнага падзелу, нават калі на сайце нешта адмовіць, то вялікая верагоднасць, што ён не спыніць працу цалкам, і ў карыстальнікаў захаваецца доступ хаця б да часткі функцыяналу.
Правільная архітэктура - аснова ўстойлівасці
Адмаўстойлівасць рэсурсу і яго здольнасць вытрымліваць напады і нагрузкі павінны закладвацца на этапе праектавання, фактычна на этапе малявання першых блок-схем у нататніку. Бо калі закрадваюцца фатальныя памылкі, выправіць іх у далейшым можна, але вельмі складана.
Добрым павінен быць не толькі код, але і канфіг
Многія думаюць, што добрая каманда распрацоўкі гэта гарантыя адмоваўстойлівасці сэрвісу. Добрая каманда распрацоўкі сапраўды неабходна, але павінна быць яшчэ і добрая эксплуатацыя, добры DevOps. Гэта значыць патрэбныя спецыялісты, якія правільна сканфігуруюць Linux і сетку, правільна напішуць канфігі ў nginx, наладзяць ліміты і іншае. У адваротным выпадку рэсурс будзе добра працаваць толькі на цесцю, а ў прадакшэне ў нейкі момант усё зламаецца.
Адрозненні нагрузачнага і стрэс-тэставанні
Нагрузачнае тэсціраванне дазваляе выявіць межы функцыянавання сістэмы. Стрэс-тэставанне накіравана на пошук слабых месцаў сістэмы і выкарыстоўваецца для таго, каб гэтую сістэму зламаць і паглядзець, як яна будзе паводзіць сябе ў працэсе адмовы тых ці іншых частак. Пры гэтым пры характар нагрузкі звычайна застаецца невядомым для замоўца да пачатку стрэс-тэставанні.
Адметныя рысы L7 нападаў
Віды нагрузкі мы звычайна дзелім на нагрузкі на ўзроўні L7 і L3&4. L7 - гэта нагрузка на ўзроўні прыкладання, часцей за ўсё пад ёй разумеюць толькі HTTP, мы ж маем на ўвазе любую нагрузку на ўзроўні пратаколу TCP.
У L7 нападаў ёсць вызначаныя адметныя рысы. Па-першае, яны прыходзяць непасрэдна ў дадатак, гэта значыць адлюстраваць іх сеткавымі сродкамі ці наўрад атрымаецца. Такія напады задзейнічаюць логіку, і за кошт гэтага вельмі эфектыўна і пры невялікім трафіку спажываюць ЦПУ, памяць, дыск, базу даных і іншыя рэсурсы.
HTTP Flood
У выпадку любога нападу нагрузку прасцей стварыць, чым апрацаваць, і ў выпадку з L7 гэта таксама дакладна. Трафік атакі не заўсёды проста адрозніць ад легітымнага, і часцей за ўсё гэта ўдаецца зрабіць па частотнасці, але калі ўсё спланавана пісьменна, то па логах зразумець, дзе атака, а дзе легітымныя запыты, немагчыма.
У якасці першага прыкладу разгледзім напад HTTP Flood. З графіка відаць, што звычайна такія напады вельмі магутныя, у прыкладзе ніжэй пікавы лік запытаў пераўзыходзіў 600 тысяч у хвіліну.
HTTP Flood - гэта самы просты спосаб стварыць нагрузку. Звычайна для яго бярэцца нейкая прылада нагрузачнага тэставання, напрыклад, ApacheBench, і задаюцца запыт і мэта. Пры такім простым падыходзе вялікая верагоднасць нарвацца на кэшаванне сервера, але яго лёгка абыйсці. Напрыклад, дадаўшы выпадковыя радкі ў запыт, што прымусіць сервер увесь час аддаваць свежую старонку.
Таксама не варта забываць пра user-agent падчас стварэнняў нагрузкі. Многія user-agent папулярных інструментаў тэсціравання фільтруюцца сістэмнымі адміністратарамі, і ў такім выпадку нагрузка можа проста не дайсці да бэкенда. Значна палепшыць вынік можна, устаўляючы ў запыт больш-менш валідны загаловак з браўзэра.
Пры ўсёй прастаце нападу HTTP Flood маюць і свае недахопы. Па-першае, для стварэння нагрузкі патрабуюцца вялікія магутнасці. Па-другое, такія напады вельмі лёгка выяўляюцца, асабліва калі ідуць з аднаго адрасу. У выніку, запыты адразу ж пачынаюць фільтравацца альбо сістэмнымі адміністратарамі, альбо нават на ўзроўні правайдэра.
што шукаць
Каб знізіць колькасць запытаў у секунду і пры гэтым не страціць у эфектыўнасці, трэба праявіць крыху фантазіі і даследаваць сайт. Так, нагружаць можна не толькі канал або сервер, але і асобныя часткі дадатку, напрыклад, базы дадзеных або файлавыя сістэмы. Таксама можна пашукаць месцы на сайце, якія робяць вялікія вылічэнні: калькулятары, старонкі з падборам прадуктаў і іншае. Нарэшце, часта бывае, што на сайце ёсць нейкі php-скрыпт, які генеруе старонку з некалькіх сотняў тысяч радкоў. Такі скрыпт таксама ў значнай ступені нагружае сервер і можа стаць мішэнню для нападу.
Дзе шукаць
Калі мы скануем рэсурс перад правядзеннем тэсціравання, то ў першую чаргу глядзім, вядома, на сам сайт. Мы шукаем разнастайныя палі ўводу, цяжкія файлы - увогуле ўсё, што можа стварыць праблемы рэсурсу і запавольвае яго працу. Тут дапамагаюць банальныя сродкі распрацоўкі ў Google Chrome і Firefox, якія паказваюць час адказаў старонкі.
Таксама мы скануем паддамены. Напрыклад, ёсць нейкая анлайн-крама, abc.com, і ў яго ёсць паддамен admin.abc.com. Хутчэй за ўсё гэта адмінка з аўтарызацыяй, але калі ў яе пусціць нагрузку, то яна можа стварыць праблемы для асноўнага рэсурсу.
У сайта можа быць паддамен api.abc.com. Хутчэй за ўсё, гэта рэсурс для мабільных дадаткаў. Прыкладанне можна знайсці ў App Store або Google Play, паставіць спецыяльны пункт доступу, прэпараваць API і зарэгістраваць тэставыя акаўнты. Праблема ў тым, што часта людзі думаюць, што ўсё, што абаронена аўтарызацыяй, непаражальнае для нападаў на адмову ў абслугоўванні. Нібыта аўтарызацыя гэта найлепшая CAPTCHA, але гэта не так. Зрабіць 10-20 тэставых акаўнтаў проста, а стварыўшы іх, мы атрымліваем доступ да складанага і непрыкрытага функцыяналу.
Натуральна, мы глядзім на гісторыю, на robots.txt і WebArchive, ViewDNS, шукаем старыя версіі рэсурса. Часам бывае так, што распрацоўшчыкі выкацілі, скажам, mail2.yandex.net, а старая версія, mail.yandex.net, засталася. Гэты mail.yandex.net перастае падтрымлівацца, на яго не адводзяцца рэсурсы распрацоўкі, але ён працягвае спажываць базу даных. Адпаведна з дапамогай старой версіі можна эфектыўна задзейнічаць рэсурсы бэкенда і ўсяго таго, што стаіць за вёрсткай. Вядома, так адбываецца не заўсёды, але з такім мы сутыкаемся ўсё роўна даволі часта.
Натуральна, мы прэпаруем усе параметры запыту, структуру cookie. Можна, скажам, запуліць у JSON масіў усярэдзіне cookie нейкае значэнне, стварыць вялікую ўкладзенасць і прымусіць рэсурс працаваць неразумна доўга.
Нагрузка ў пошук
Першае, што прыходзіць у галаву пры даследаванні сайта, гэта нагрузіць базу дадзеных, паколькі пошук ёсць амаль ва ўсіх, і амаль ва ўсіх ён, нажаль, абаронены дрэнна. Чамусьці распрацоўшчыкі не надаюць пошуку дастатковую ўвагу. Але тут ёсць адна рэкамендацыя - не варта рабіць аднатыпныя запыты, таму што можна сутыкнуцца з кэшаваннем, як і ў выпадку з HTTP flood.
Рабіць выпадковыя запыты ў базу даных таксама не заўсёды эфектыўна. Значна лепш стварыць спіс ключавых слоў, якія адносяцца да пошуку. Калі вяртацца да прыкладу інтэрнэт-крамы: дапусцім, сайт гандлюе аўтамабільнай гумай і дазваляе задаваць радыус шын, тып машыны і іншыя параметры. Адпаведна камбінацыі рэлевантных слоў прымусяць базу дадзеных працаваць у нашмат больш складаных умовах.
Акрамя таго, варта выкарыстоўваць пагінацыю: пошуку значна складаней аддаць перадапошнюю старонку выдачы, чым першую. Гэта значыць з дапамогай пагінацыі можна крыху разнастаіць нагрузку.
На прыкладзе ніжэй паказваем нагрузку ў пошук. Відаць, што з першай жа секунды цеста на хуткасці дзесяць запытаў у секунду сайт лёг і не адказваў.
Калі пошуку няма?
Калі пошуку няма, тое гэта не значыць, што сайт не ўтрымоўвае ў сабе іншых уразлівых палёў уводу. Такім полем можа аказацца аўтарызацыя. Цяпер распрацоўшчыкі любяць рабіць складаныя хешы, каб абараніць базу лагінаў ад атакі па вясёлкавых табліцах. Гэта добра, але такія хэшы спажываюць вялікія рэсурсы CPU. Вялікі паток ілжывых аўтарызацый прыводзіць да адмовы працэсара, і як следства, на выхадзе сайт перастае працаваць.
Прысутнасць на сайце разнастайных формаў для каментароў і зваротнай сувязі - гэта нагода адправіць туды вельмі вялікія тэксты або проста стварыць масавы флуд. Часам сайты прымаюць укладзеныя файлы, у тым ліку ў фармаце gzip. У такім выпадку, мы бярэм файл памерам 1Тб, з дапамогай gzip сціскаем яго да некалькіх байт ці кілабайт і адпраўляем на сайт. Далей ён разархівуецца і атрымоўваецца вельмі цікавы эфект.
API адпачынку
Жадалася бы надаць трохі ўвагі такім папулярным сягоння сэрвісам, як Rest API. Абараніць Rest API нашмат складаней, чым звычайны сайт. Для Rest API не працуюць нават банальныя спосабы абароны ад перабору пароляў і іншай нелігітымнай актыўнасці.
Rest API вельмі проста зламаць, таму што ён звяртаецца непасрэдна да базы дадзеных. Пры гэтым выснова такога сэрвісу са строю цягне за сабой дастаткова цяжкія наступствы для бізнесу. Справа ў тым, што на Rest API звычайна завязаны не толькі галоўны сайт, але і мабільнае прыкладанне, нейкія ўнутраныя бізнес-рэсурсы. І калі гэта ўсё падае, то эфект значна мацней, чым у выпадку са выхадам са строю простага сайта.
Нагрузка на цяжкі кантэнт
Калі нам прапануюць тэставаць нейкі звычайны аднастаронкавы дадатак, лендынг, сайт-візітку, у якіх няма складанага функцыяналу, мы шукаем цяжкі кантэнт. Напрыклад, вялікія карцінкі, якія аддае сервер, бінарныя файлы, pdf-дакументацыю, - мы спрабуем усё гэта выпампоўваць. Такія тэсты добра грузяць файлавую сістэму і забіваюць каналы, і таму эфектыўныя. Гэта значыць нават калі вы не пакладзеце сервер, спампоўваючы вялікі файл на невялікіх хуткасцях, тыя вы проста заб'яце канал мэтавага сервера і тады наступіць адмова ў абслугоўванні.
На прыкладзе такога тэсту бачна, што на хуткасці 30 RPS сайт перастаў адказваць, альбо выдаваў 500-я памылкі сервера.
Не варта забываць і пра настройку сервераў. Часта можна сустрэць, што чалавек купіў віртуалку, паставіў туды Apache, наладзіў усё па змаўчанні, размясціў php-дадатак, і ніжэй можна ўбачыць вынік.
Тут нагрузка ішла ў корань і складала ўсяго 10 RPS. Мы пачакалі 5 хвілін, і сервер упаў. Да канца, праўда, невядома, чаму ён упаў, але ёсць здагадка, што ён проста аб'еўся памяці, і таму перастаў адказваць.
Wave based
У апошнія год-два дастаткова папулярнымі сталі хвалевыя атакі. Гэта злучана з тым, што шматлікія арганізацыі купляюць тыя ці іншыя жалязякі для абароны ад DDoS, якія патрабуюць вызначанага часу назапашвання статыстыкі для пачатку фільтраванні нападу. Гэта значыць яны не фільтруюць напад у першыя 30-40 секунд, таму што назапашваюць дадзеныя і навучаюцца. Адпаведна ў гэтыя 30-40 секунд на сайт можна запусціць столькі, што рэсурс будзе ляжаць працяглы час, пакуль не разграбуць усе запыты.
У выпадку з атакай ніжэй быў інтэрвал 10 хвілін, пасля чаго прыляцела новая, перайначаная порцыя атакі.
Гэта значыць абарона навучылася, запусціла фільтраванне, але прыляцела новая, зусім іншая порцыя нападу, і абарона зноў пачала навучанне. Фактычна, фільтраванне перастае працаваць, абарона становіцца неэфектыўнай, і сайт недаступны.
Для хвалевых нападаў характэрны вельмі высокія значэнні на піку, яна можа дасягаць ста тысяч або мільёна запытаў у секунду, у выпадку з L7. Калі казаць пра L3&4, то тамака могуць быць сотні гігабіт трафіку, ці, адпаведна, сотні mpps, калі лічыць у пакетах.
Праблема ж такіх нападаў у сінхранізацыі. Напады ідуць з ботнэту, і для таго, каб стварыць вельмі вялікі разавы пік, патрабуецца высокая ступень сінхранізацыі. І гэтая каардынацыя не заўсёды атрымліваецца: часам на выхадзе атрымліваецца нейкі парабалічны пік, які выглядае даволі шкада.
Ня HTTP адзіным
Апроч HTTP на ўзроўні L7, мы кахаем эксплуатаваць і іншыя пратаколы. Як правіла, у звычайнага вэб-сайта, тым больш у звычайнага хостынгу, вонкі тырчаць паштовыя пратаколы і MySQL. Паштовыя пратаколы схільныя нагрузкам у меншай ступені, чым базы дадзеных, але іх таксама можна нагружаць дастаткова эфектыўна і на выхадзе атрымліваць перагружаны CPU на серверы.
Мы цалкам рэальна з дапамогай уразлівасці SSH 2016 дамагаліся поспеху. Цяпер гэтая ўразлівасць амаль ва ўсіх папраўленая, але гэта не значыць, што ў SSH нельга падаваць нагрузку. Можна. Проста падаецца вялізная нагрузка аўтарызацый, SSH з'ядае амаль увесь CPU на серверы і далей вэб-сайт складаецца ўжо ад аднаго-двух запытаў у секунду. Адпаведна гэтыя адзін-два запыты па логах ніяк нельга адрозніць ад легітымнай нагрузкі.
Застаюцца актуальнымі і мноства злучэнняў, якія мы адчыняем у серверах. Раней гэтым грашыў Apache, зараз гэтым фактычна грашыць і nginx, паколькі ён часта наладжваецца па дэфолце. Колькасць злучэнняў, якія nginx можа трымаць адчыненымі, лімітавана, адпаведна мы адчыняем гэтую колькасць злучэнняў, новае злучэнне nginx ужо не прымае, і на вынахадзе сайт не працуе.
Наш тэставы кластар валодае дастатковым CPU, каб атакаваць SSL handshake. У прынцыпе, як паказвае практыка, ботнэты таксама часам любяць гэта рабіць. З аднаго боку, зразумела, што без SSL не абысціся, таму што выдача Google, ранжыраванне, бяспека. З іншага боку, у SSL, нажаль, ёсць праблема з CPU.
L3&4
Калі мы гаворым аб нападзе на ўзроўнях L3&4, мы гаворым, як правіла, аб нападзе на ўзроўні канала. Такая нагрузка амаль заўсёды адрозная ад легітымнай, калі гэта не напад SYN-flood. Праблема SYN-flood нападаў для сродкаў абароны складаецца ў вялікім аб'ёме. Максімальная велічыня L3&4 складала 1,5-2 Тбіт/з. Такі трафік вельмі складана апрацаваць нават буйным кампаніям, у тым ліку Oracle і Google.
SYN і SYN-ACK - гэта пакеты, якія выкарыстоўваюцца пры ўсталёўцы злучэння. Таму SYN-flood і складана адрозніць ад легітымнай нагрузкі: незразумела, гэта SYN, які прыйшоў на ўсталёўку злучэння, ці частка флуду.
UDP-flood
Звычайна ў зламыснікаў няма тых магутнасцяў, якія ёсць у нас, таму для арганізацыі нападаў можа выкарыстоўвацца ампліфікацыя. Гэта значыць зламыснік скануе інтэрнэт і знаходзіць або ўразлівыя, або няправільна настроеныя серверы, якія, напрыклад, у адказ на адзін SYN-пакет, адказваюць трыма SYN-ACK. Падрабляючы адрас крыніцы з адраса мэтавага сервера, можна з дапамогай аднаго пакета павялічыць магутнасць, скажам, у тры разы, і перанакіраваць трафік на ахвяру.
Праблема ампліфікацый заключаецца ў іх складаным выяўленні. З апошніх прыкладаў можна прывесці нашумелы выпадак з уразлівым memcached. Плюс, цяпер з'явілася мноства прылад IoT, IP-камер, якія таксама ў асноўным настроены па дэфолце, і па дэфолце яны настроены няправільна, таму праз такія прылады зламыснікі і робяць напады часцей за ўсё.
Няпросты SYN-flood
SYN-flood, мусіць, самы цікавы выгляд з усіх нападаў з пункта гледжання распрацоўніка. Праблема ў тым, што часта сістэмныя адміністратары выкарыстоўваюць для абароны блакіроўку па IP. Прычым блакіроўкай па IP пакутуюць не толькі сісадміны, якія дзейнічаюць па скрыптах, але і, нажаль, некаторыя сістэмы абароны, якія купляюцца за вялікія грошы.
Такі метад можа абярнуцца катастрофай, бо калі зламыснікі падменяць IP-адрасы, то кампанія заблакуе ўласную падсетку. Калі Firewall заблакуе ўласны кластар, на выхадзе будуць разбурацца знешнія ўзаемадзеянні, і рэсурс зламаецца.
Прычым дабіцца блакіроўкі ўласнай сеткі нескладана. Калі ў офісе кліента ёсць WI-Fi-сетка, або калі працаздольнасць рэсурсаў вымяраецца з дапамогай розных маніторынгаў, то мы бярэм IP-адрас гэтай сістэмы маніторынгу ці офіснага Wi-Fi кліента, і выкарыстоўваем яго ў якасці крыніцы. На выхадзе рэсурс быццам бы даступны, але мэтавыя IP-адрасы заблакаваны. Так, можа быць заблакаваная Wi-Fi-сетка канферэнцыі HighLoad, дзе прэзентуецца новы прадукт кампаніі, – і гэта цягне пэўныя бізнес-і эканамічныя выдаткі.
Падчас тэсціравання мы не можам выкарыстоўваць ампліфікацыю праз memcached нейкімі знешнімі рэсурсамі, таму што ёсць дамоўленасці па падачы трафіку толькі ў дазволеныя IP-адрасы. Адпаведна мы выкарыстоўваем ампліфікацыю праз SYN і SYN-ACK, калі на адпраўку аднаго SYN сістэма адказвае двума-трыма SYN-ACK, і на выхадзе атака памнажаецца ў два-тры разы.
Інструменты
Адзін з асноўных інструментаў, якім мы карыстаемся для нагрузкі на ўзроўні L7, – гэта Yandex-tank. У прыватнасці, у якасці гарматы выкарыстоўваецца фантом, плюс ёсць некалькі скрыптоў для генерацыі патронаў і для аналізу вынікаў.
Для аналізу сеткавага трафіку выкарыстоўваецца Tcpdump, для аналізу сервера - Nmap. Для стварэння нагрузкі на ўзроўні L3&4 выкарыстоўваецца OpenSSL і крыху ўласнай магіі з бібліятэкай DPDK. DPDK – гэта бібліятэка ад Intel, якая дазваляе працаваць з сеткавым інтэрфейсам, абыходзячы стэк Linux, і тым самым павялічвае эфектыўнасць. Натуральна, DPDK мы выкарыстаем не толькі на ўзроўні L3&4, але і на на ўзроўні L7, таму што яна дазваляе ствараць вельмі высокі струмень нагрузкі, у межах некалькіх мільёнаў запытаў у секунду з адной машыны.
Таксама мы выкарыстоўваем пэўныя трафік-генератары і спецыяльныя інструменты, якія пішам пад спецыфічныя тэсты. Калі ўспомніць уразлівасць пад SSH, то прыведзеным вышэй наборам яна не можа быць праэскпулатаваная. Калі мы атакуем паштовы пратакол, то бярэм паштовыя ўтыліты ці проста пішам на іх скрыпты.
Высновы
У якасці вынікаў хацелася б сказаць:
- Апроч класічнага нагрузачнага тэставання трэба абавязкова праводзіць і стрэс-тэставанне. У нас ёсць рэальны прыклад, калі субпадрадчык партнёра правёў толькі нагрузачнае тэсціраванне. Яно паказала, што рэсурс вытрымлівае штатную нагрузку. Але затым з'явілася няштатная нагрузка, наведвальнікі сайта сталі крыху інакш выкарыстоўваць рэсурс, — і на выхадзе субпадрадчык лёг. Такім чынам, шукаць уразлівасці варта, нават калі вы ўжо абаронены ад DDoS-нападаў.
- Неабходна ізаляваць адны часткі сістэмы ад іншых. Калі ў вас ёсць пошук, яго трэба вынесці на асобныя машыны, гэта значыць нават не ў докер. Таму што калі адмовіць пошук ці аўтарызацыя, то хаця б нешта працягне працаваць. У выпадку з інтэрнэт-крамой карыстальнікі працягнуць знаходзіць тавары па каталогу, пераходзіць з агрэгатара, купляць, калі яны ўжо аўтарызаваны, ці аўтарызоўвацца праз OAuth2.
- Не варта грэбаваць разнастайнымі хмарнымі сэрвісамі.
- Выкарыстоўвайце CDN не толькі для аптымізацыі сеткавых затрымак, але і як сродак абароны ад нападаў на вычарпанне канала і проста флуду ў статыку.
- Неабходна выкарыстоўваць спецыялізаваныя сервісы абароны. Ад L3&4 нападаў на ўзроўні канала самі вы не абараніцеся, таму што ў вас, хутчэй за ўсё, проста няма дастатковага канала. Ад L7 нападаў вы таксама ці наўрад адаб'ецеся, паколькі яны бываюць вельмі вялікімі. Плюс, пошук маленькіх нападаў гэта ўсёткі прэрагатыва адмысловых сэрвісаў, адмысловых алгарытмаў.
- Рэгулярна абнаўляйцеся. Гэта датычыцца не толькі ядра, але і SSH daemon, асабліва калі яны ў вас адкрыты вонкі. У прынцыпе, абнаўляць трэба наогул усё, таму што адсочваць тыя ці іншыя ўразлівасці самастойна вы ці наўрад зможаце.
Крыніца: habr.com