На 28 февруари станахме свидетели на най-мащабната DDoS атака в историята на интернет. Добре познатия на всички сайт за хостване на проекти на разработчици GitHub попадна от лошата ѝ страна и принудително бе спрян, макар и за кратко.
Обемът на атаката е измерен на 1.35 Tbps (терабита в секунда), постигнати чрез средно 126.9 милиона пакети в секунда.
За атаката не е използвана ботмрежа, а много по-прост и лесен за експлоатация метод – използването на отговори от Memcached сървъри.
Нова механика за блокиране
Най-интересното в случая е самата механика зад атаката. Тя няма нужда от дистрибуцията на зловреден код до стотици хиляди устройства. Вместо това, авторите ѝ се възползват от лошо подсигурени и публично достъпни Memcached сървъри – машини, които оптимизират работата на бази данни като запомнят най-често достъпваната информация в RAM паметта си. Освен това, те имат и друга особеност – заявка от едва няколко байта може да получи отговор в размер на стотици килобайти.
По този начин, всеки атакуващ може да изпрати малък брой заявки към различни Memcached сървъри и да замени IP-то на изпращача с това на фирмените ви сървъри. Така вие ще получите огромен обем данни, усилен от неправилно внедрената UDP функционалност на Memcached услугата. Това дава и името на този тип атака – amplification attack (атака чрез усилване).
Защо е разумно да очакваме още такива инциденти
Въпреки че amplification атаките не са нищо ново, тази използва хиляди неправилно конфигурирани сървъри, за да изпълни целите си.
“Предимството” на този вектор е, че е достъпен – няма мрежи за поддръжка и няма нужда от заразата на стотици хиляди машини, за да се достигне достатъчно голям обем от трафик. Като много други, той разчита на грешките в човешкия фактор.
Не е ясно на колко по-мащабни атаки ще станем свидетели докато се изчисти проблемът с публично достъпни memcached сървъри. Заради това е нужно да се действа сега – като скролирате до края на статията.
Съвети за потребители, системни администратори и разработчици
IP spoofing-a все още е разрешен от голяма част от интернет доставчиците, а филтрирането на фалшифициран трафик на потребителско ниво е почти непосилно за повечето. Ако използвате Memcached е нужно да станете част от решението преди да станете част от проблема:
Препоръките са дадени от CloudFlare в публикацията им относно инцидента.
Потребители:
- Обновете софтуера си – последната версия на решението забранява UDP комуникация поначало.
- Ако използвате стара версия, можете да използвате –listen 127.0.0.1 при старт, за да накарате сървъра да „слуша“ изцяло локално или –U 0, за да забраните UDP изцяло.
- Използвайте следните команди, за да тествате дали сървърът ви е уязвим – ако получите празен отговор, значи всичко е наред:
$ echo -en “\x00\x00\x00\x00\x00\x01\x00\x00stats\r\n” | nc -q1 -u 127.0.0.1 11211
STAT pid 21357
STAT uptime 41557034
STAT time 1519734962
Системни администратори:
- Поставете сървъра зад защитна стена и не позволявайте UDP или TCP достъп до него.
- Използвайте описаните горе инструкции, за да забраните приемането на UDP пакети и да тествате за уязвимост. За да тествате TCP, можете да използвате nmap.
Разработчици:
- Ограничете използването на UDP комуникация в софтуера си, особено незащитена чрез оторизация такава. Има редица примери за това защо не трябва да го правите – DNS, NTP, Chargen, SSDP, а сега и Memcached. Ако използвате UDP, то е задължително да връщате по-малки като размер отговори на потребителските заявки.
Присъединете се към дискусията ТУК