Variti разработва защита срещу ботове и DDoS атаки, а също така провежда тестове за стрес и натоварване. На конференцията HighLoad++ 2018 говорихме как да защитим ресурсите от различни видове атаки. Накратко: изолирайте части от системата, използвайте облачни услуги и CDN и актуализирайте редовно. Но все пак няма да можете да се справите със защита без специализирани фирми :)
Преди да прочетете текста, можете да прочетете кратките резюмета .
А ако не обичате да четете или просто искате да гледате видеото, записът на нашия репортаж е по-долу под спойлера.
Видеозапис на репортажа
Много компании вече знаят как да правят тестове за натоварване, но не всички правят стрес тестове. Някои от нашите клиенти смятат, че сайтът им е неуязвим, защото имат система с високо натоварване и тя защитава добре от атаки. Показваме, че това не е съвсем вярно.
Разбира се, преди да проведем тестове, ние получаваме разрешение от клиента, подписано и подпечатано и с наша помощ не може да бъде извършена DDoS атака срещу никого. Тестването се извършва в избрано от клиента време, когато трафикът към неговия ресурс е минимален и проблемите с достъпа няма да засегнат клиентите. Освен това, тъй като винаги нещо може да се обърка по време на процеса на тестване, ние имаме постоянен контакт с клиента. Това ви позволява не само да докладвате постигнатите резултати, но и да промените нещо по време на тестването. След приключване на тестването винаги изготвяме протокол, в който посочваме откритите недостатъци и даваме препоръки за отстраняване на слабостите на сайта.
Как работим
При тестване ние емулираме ботнет. Тъй като работим с клиенти, които не се намират в нашите мрежи, за да гарантираме, че тестът няма да приключи в първата минута поради задействане на ограничения или защита, ние доставяме товара не от един IP, а от нашата собствена подмрежа. Плюс това, за да създадем значително натоварване, ние разполагаме със собствен доста мощен тестов сървър.
Постулати
Твърде много не означава добро
Колкото по-малко натоварване можем да доведем ресурс до отказ, толкова по-добре. Ако можете да накарате сайта да спре да функционира при една заявка в секунда или дори една заявка в минута, това е чудесно. Тъй като според закона на подлостта, потребителите или нападателите случайно ще попаднат в тази конкретна уязвимост.
Частичният отказ е по-добър от пълния отказ
Ние винаги съветваме системите да бъдат хетерогенни. Освен това си струва да ги разделите на физическо ниво, а не само чрез контейнеризиране. В случай на физическо разделяне, дори ако нещо се повреди на сайта, има голяма вероятност той да не спре да работи напълно и потребителите ще продължат да имат достъп до поне част от функционалността.
Добрата архитектура е в основата на устойчивостта
Устойчивостта на грешки на даден ресурс и способността му да издържа на атаки и натоварвания трябва да бъдат определени на етапа на проектиране, всъщност на етапа на изчертаване на първите блок-схеми в бележник. Защото ако се появят фатални грешки, е възможно да се коригират в бъдеще, но е много трудно.
Не само кодът трябва да е добър, но и конфигурацията
Много хора смятат, че добрият екип за разработка е гаранция за толерантно към грешки обслужване. Наистина е необходим добър екип за разработка, но трябва да има и добри операции, добри DevOps. Тоест имаме нужда от специалисти, които правилно ще конфигурират Linux и мрежата, ще напишат правилно конфигурации в nginx, ще зададат лимити и т.н. В противен случай ресурсът ще работи добре само при тестване и в един момент всичко ще се счупи в производството.
Разлики между натоварване и стрес тестване
Тестването на натоварването ви позволява да идентифицирате границите на функциониране на системата. Стрес тестът е насочен към намиране на слабости в дадена система и се използва, за да се разбие тази система и да се види как ще се държи в процеса на отказ на определени части. В този случай естеството на натоварването обикновено остава неизвестно за клиента преди началото на стрес теста.
Отличителни черти на L7 атаките
Обикновено разделяме видовете товари на товари на нива L7 и L3&4. L7 е натоварване на ниво приложение, най-често означава само HTTP, но имаме предвид всяко натоварване на ниво TCP протокол.
L7 атаките имат някои отличителни характеристики. Първо, те идват директно в приложението, тоест е малко вероятно да бъдат отразени чрез мрежови средства. Такива атаки използват логика и поради това консумират CPU, памет, диск, база данни и други ресурси много ефективно и с малко трафик.
HTTP наводнение
В случай на всяка атака, товарът е по-лесен за създаване, отколкото за справяне, а в случая на L7 това също е вярно. Не винаги е лесно да се разграничи трафикът на атака от легитимния трафик и най-често това може да стане по честота, но ако всичко е планирано правилно, тогава от логовете е невъзможно да се разбере къде е атаката и къде са легитимните заявки.
Като първи пример помислете за HTTP Flood атака. Графиката показва, че подобни атаки обикновено са много мощни; в примера по-долу пиковият брой заявки надхвърля 600 хиляди в минута.
HTTP Flood е най-лесният начин за създаване на натоварване. Обикновено е необходим някакъв вид инструмент за тестване на натоварването, като ApacheBench, и задава заявка и цел. С такъв прост подход има голяма вероятност да попаднете в кеширане на сървъра, но е лесно да го заобиколите. Например добавяне на произволни низове към заявката, което ще принуди сървъра постоянно да обслужва нова страница.
Също така не забравяйте за потребителския агент в процеса на създаване на товар. Много потребителски агенти на популярни инструменти за тестване се филтрират от системни администратори и в този случай натоварването може просто да не достигне бекенда. Можете значително да подобрите резултата, като вмъкнете повече или по-малко валиден хедър от браузъра в заявката.
Колкото и прости да са 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 вече не се поддържа, не му се разпределят ресурси за разработка, но той продължава да използва базата данни. Съответно, използвайки старата версия, можете ефективно да използвате ресурсите на бекенда и всичко, което стои зад оформлението. Разбира се, това не винаги се случва, но все пак се сблъскваме с това доста често.
Разбира се, ние анализираме всички параметри на заявката и структурата на бисквитките. Можете, да речем, да изхвърлите някаква стойност в JSON масив вътре в бисквитка, да създадете много вложени елементи и да накарате ресурса да работи неоправдано дълго време.
Натоварване при търсене
Първото нещо, което идва на ум, когато проучвате сайт, е да заредите базата данни, тъй като почти всеки има търсене и за почти всеки, за съжаление, е слабо защитен. По някаква причина разработчиците не обръщат достатъчно внимание на търсенето. Но тук има една препоръка - не трябва да правите заявки от един и същи тип, защото може да срещнете кеширане, какъвто е случаят с HTTP flood.
Правенето на произволни заявки към базата данни също не винаги е ефективно. Много по-добре е да създадете списък с ключови думи, които са подходящи за търсенето. Ако се върнем към примера с онлайн магазин: да кажем, че сайтът продава автомобилни гуми и ви позволява да зададете радиуса на гумите, вида на автомобила и други параметри. Съответно, комбинации от подходящи думи ще принудят базата данни да работи в много по-сложни условия.
Освен това си струва да използвате пагинация: много по-трудно е търсенето да върне предпоследната страница от резултатите от търсенето, отколкото първата. Тоест, с помощта на пагинация можете леко да разнообразите товара.
Примерът по-долу показва натоварването при търсене. Вижда се, че още от първата секунда на теста със скорост от десет заявки в секунда, сайтът падна и не отговори.
Ако няма търсене?
Ако няма търсене, това не означава, че сайтът не съдържа други уязвими полета за въвеждане. Това поле може да е оторизация. В днешно време разработчиците обичат да правят сложни хешове, за да защитят базата данни за влизане от атака с дъгова таблица. Това е добре, но такива хешове консумират много ресурси на процесора. Голям поток от фалшиви авторизации води до повреда на процесора и в резултат на това сайтът спира да работи.
Наличието на сайта на всякакви форми за коментари и обратна връзка е причина да изпращате много големи текстове там или просто да създавате масов флуд. Понякога сайтовете приемат прикачени файлове, включително във формат gzip. В този случай вземаме файл от 1TB, компресираме го до няколко байта или килобайта с помощта на gzip и го изпращаме на сайта. След това се разкопчава и се получава много интересен ефект.
API за почивка
Бих искал да обърна малко внимание на такива популярни услуги като Rest API. Осигуряването на Rest API е много по-трудно от обикновен уебсайт. Дори тривиалните методи за защита срещу груба сила на парола и друга нелегитимна дейност не работят за Rest API.
Rest API е много лесен за разбиване, защото има директен достъп до базата данни. В същото време провалът на такава услуга води до доста сериозни последици за бизнеса. Факт е, че Rest API обикновено се използва не само за основния уебсайт, но и за мобилното приложение и някои вътрешни бизнес ресурси. И ако всичко това падне, тогава ефектът е много по-силен, отколкото в случай на обикновена повреда на уебсайта.
Зарежда се тежко съдържание
Ако ни бъде предложено да тестваме обикновено приложение от една страница, целева страница или уебсайт с визитка, който няма сложна функционалност, ние търсим тежко съдържание. Например големи изображения, които сървърът изпраща, двоични файлове, pdf документация - ние се опитваме да изтеглим всичко това. Такива тестове зареждат добре файловата система и запушват каналите и следователно са ефективни. Тоест, дори ако не изключите сървъра, изтегляйки голям файл с ниска скорост, вие просто ще запушите канала на целевия сървър и след това ще възникне отказ на услуга.
Пример за такъв тест показва, че при скорост от 30 RPS сайтът спря да отговаря или генерира 500-ни сървърни грешки.
Не забравяйте за настройката на сървърите. Често можете да откриете, че човек е купил виртуална машина, инсталирал е там Apache, конфигурирал е всичко по подразбиране, инсталирал е PHP приложение и по-долу можете да видите резултата.
Тук натоварването отиде до корена и възлизаше само на 10 RPS. Изчакахме 5 минути и сървърът се срина. Вярно е, че не е напълно известно защо е паднал, но има предположение, че просто е имал твърде много памет и затова е спрял да реагира.
Базиран на вълни
През последните година-две вълновите атаки станаха доста популярни. Това се дължи на факта, че много организации купуват определен хардуер за DDoS защита, който изисква определено време за натрупване на статистика, за да започне филтрирането на атаката. Тоест те не филтрират атаката в първите 30-40 секунди, защото трупат данни и се учат. Съответно за тези 30-40 секунди можете да стартирате толкова много на сайта, че ресурсът ще лежи дълго време, докато всички заявки бъдат изчистени.
В случая на атаката по-долу имаше интервал от 10 минути, след което пристигна нова, модифицирана част от атаката.
Тоест защитата се научи, започна да филтрира, но пристигна нова, напълно различна част от атаката и защитата започна да се учи отново. Всъщност филтрирането спира да работи, защитата става неефективна и сайтът е недостъпен.
Вълновите атаки се характеризират с много високи стойности на върха, могат да достигнат сто хиляди или милион заявки в секунда, в случай на L7. Ако говорим за L3&4, тогава може да има стотици гигабита трафик или, съответно, стотици mpps, ако броите в пакети.
Проблемът с подобни атаки е синхронизацията. Атаките идват от ботнет и изискват висока степен на синхронизация, за да се създаде много голям еднократен скок. И тази координация не винаги работи: понякога резултатът е някакъв параболичен връх, който изглежда доста жалък.
Не само HTTP
В допълнение към HTTP на L7, обичаме да използваме и други протоколи. Като правило, обикновен уебсайт, особено обикновен хостинг, има пощенски протоколи и MySQL, които стърчат. Протоколите за поща са обект на по-малко натоварване от базите данни, но те също могат да бъдат заредени доста ефективно и в крайна сметка да претоварят процесора на сървъра.
Съвсем реалистично постигнахме успех с SSH уязвимостта от 2016 г. Сега тази уязвимост е коригирана за почти всички, но това не означава, че натоварването не може да бъде изпратено до SSH. Мога. Просто има огромно натоварване от авторизации, SSH изяжда почти целия процесор на сървъра и след това уебсайтът се срива от една или две заявки в секунда. Съответно тези една или две заявки, базирани на регистрационните файлове, не могат да бъдат разграничени от легитимно зареждане.
Много връзки, които отваряме в сървъри, също остават актуални. Преди Apache беше виновен за това, сега nginx всъщност е виновен за това, тъй като често е конфигуриран по подразбиране. Броят на връзките, които nginx може да поддържа отворени, е ограничен, така че отваряме този брой връзки, nginx вече не приема нова връзка и в резултат на това сайтът не работи.
Нашият тестов клъстер има достатъчно процесор, за да атакува SSL ръкостискане. По принцип, както показва практиката, ботнетите понякога също обичат да правят това. От една страна е ясно, че не можете без SSL, защото Google резултати, класиране, сигурност. От друга страна, SSL за съжаление има проблем с процесора.
L3&4
Когато говорим за атака на нива L3 и 4, обикновено говорим за атака на ниво връзка. Такова натоварване почти винаги се различава от легитимното, освен ако не е SYN-flood атака. Проблемът със SYN-flood атаките за инструменти за сигурност е големият им обем. Максималната стойност на L3&4 беше 1,5-2 Tbit/s. Този вид трафик е много труден за обработка дори за големи компании, включително Oracle и Google.
SYN и SYN-ACK са пакети, които се използват при установяване на връзка. Следователно SYN-наводнението е трудно да се разграничи от легитимно зареждане: не е ясно дали това е SYN, дошъл да установи връзка, или е част от наводнение.
UDP-наводнение
Обикновено нападателите нямат възможностите, които имаме ние, така че усилването може да се използва за организиране на атаки. Тоест атакуващият сканира интернет и намира или уязвими, или неправилно конфигурирани сървъри, които например в отговор на един SYN пакет отговарят с три SYN-ACK. Чрез подправяне на адреса на източника от адреса на целевия сървър е възможно да се увеличи мощността, да речем, три пъти с един пакет и да се пренасочи трафикът към жертвата.
Проблемът с усилванията е, че са трудни за откриване. Последните примери включват сензационния случай с уязвимия memcached. Освен това сега има много IoT устройства, IP камери, които също са предимно конфигурирани по подразбиране и по подразбиране са конфигурирани неправилно, поради което атакуващите най-често правят атаки през такива устройства.
Трудно SYN-наводнение
SYN-flood е може би най-интересният тип атака от гледна точка на разработчиците. Проблемът е, че системните администратори често използват IP блокиране за защита. Освен това блокирането на IP засяга не само системните администратори, които действат с помощта на скриптове, но и, за съжаление, някои системи за сигурност, които са закупени за много пари.
Този метод може да се превърне в катастрофа, защото ако нападателите сменят IP адресите, компанията ще блокира собствената си подмрежа. Когато защитната стена блокира собствения си клъстер, изходът ще се провали при външни взаимодействия и ресурсът ще се провали.
Освен това не е трудно да блокирате собствената си мрежа. Ако офисът на клиента има 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 атаки.
- Необходимо е да се изолират някои части на системата от други. Ако имате търсене, трябва да го преместите на отделни машини, тоест дори не на Docker. Защото ако търсенето или оторизацията се провалят, поне нещо ще продължи да работи. В случай на онлайн магазин, потребителите ще продължат да намират продукти в каталога, ще преминават от агрегатора, ще купуват, ако вече са упълномощени, или ще упълномощават чрез OAuth2.
- Не пренебрегвайте всички видове облачни услуги.
- Използвайте CDN не само за оптимизиране на мрежовите закъснения, но и като средство за защита срещу атаки при изчерпване на канала и просто наводняване в статичен трафик.
- Необходимо е да се използват специализирани услуги за защита. Не можете да се защитите от L3 и 4 атаки на ниво канал, защото най-вероятно просто нямате достатъчен канал. Също така е малко вероятно да се преборите с L7 атаки, тъй като те могат да бъдат много големи. Освен това търсенето на малки атаки все още е прерогатив на специални услуги, специални алгоритми.
- Актуализирайте редовно. Това се отнася не само за ядрото, но и за SSH демона, особено ако ги отворите навън. По принцип всичко трябва да се актуализира, защото е малко вероятно да можете да проследите определени уязвимости сами.
Източник: www.habr.com