DDoS атака срещу RDP услуги: разпознайте и преодолейте. Успешен опит от Туча

Нека ви разкажем една страхотна история за това как "трети страни" се опитаха да се намесят в нашите клиенти и как този проблем беше решен.

Как започна всичко

Всичко започна сутринта на 31 октомври, последния ден от месеца, когато мнозина отчаяно се нуждаят от време да решат спешни и важни въпроси.

Един от партньорите, който поддържа няколко виртуални машини на клиентите, които обслужва в нашия облак, съобщи, че от 9:10 до 9:20 няколко Windows сървъра, работещи на нашия украински сайт наведнъж, не приемат връзки към услугата за отдалечен достъп, потребителите не можеха да получат достъп до своите настолни компютри, но след няколко минути проблемът сякаш изчезна от само себе си.

Повишихме статистиката на комуникационните канали, но не открихме изблици на трафик или повреди. Разгледахме статистиката за натоварването на изчислителните ресурси - няма аномалии. И какво беше това?

След това друг партньор, който хоства още сто сървъра в нашия облак, съобщи за същите проблеми, които някои от техните клиенти отбелязаха, докато се оказа, че като цяло сървърите са налични (отговарят правилно на ping-test и други заявки), но услугата отдалеченият достъп на тези сървъри или приема нови връзки, или ги отхвърля, докато говорихме за сървъри на различни сайтове, трафикът към които идва от различни канали за предаване на данни.

Нека да разгледаме този трафик. На сървъра пристига пакет с искане за установяване на връзка:

xx:xx:xx.xxxxxx IP xxx.xxx.xxx.xxx.58355 > 192.168.xxx.xxx.3389: Flags [S], seq 467744439, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0

Сървърът получава този пакет, но връзката е отхвърлена:

xx:xx:xx.xxxxxx IP 192.168.xxx.xxx.3389 > xxx.xxx.xxx.xxx.58355: Flags [R.], seq 0, ack 467744440, win 0, length 0

Това означава, че проблемът очевидно не е причинен от неизправности в инфраструктурата, а от нещо друго. Може би всички потребители имат проблеми с лицензирането на отдалечен работен плот? Може би някакъв зловреден софтуер е успял да проникне в системите им и днес е активиран, както беше преди няколко години. XData и Петя?

Докато го подреждахме, получихме подобни заявки от още няколко клиенти и партньори.
Какво всъщност се случва на тези машини?

Регистрите на събитията са пълни със съобщения за опит за отгатване на парола:

Обикновено такива опити се регистрират на всички сървъри, където стандартният порт (3389) се използва за услугата за отдалечен достъп и е разрешен достъп отвсякъде. Интернет е пълен с ботове, които непрекъснато сканират всички налични точки за връзка и се опитват да отгатнат паролата (това е причината, поради която силно препоръчваме използването на сложни пароли вместо „123“). Въпреки това, интензивността на тези опити този ден беше твърде висока.

Какво трябва да направя?

Препоръчвате на клиентите да прекарват много време в промяна на настройките на огромен брой крайни потребители, за да превключат към различен порт? Не е добра идея, клиентите няма да са доволни. Препоръчвате да разрешите достъп само през VPN? В бързане и паника, повишаване на IPSec връзки за тези, които не са ги повдигнали - може би такова щастие не се усмихва и на клиентите. Въпреки че, трябва да кажа, това във всеки случай е благотворителен въпрос, ние винаги препоръчваме да скриете сървъра в частна мрежа и сме готови да помогнем с настройките, а за тези, които обичат да го разберат сами, споделяме инструкции за настройка на IPSec / L2TP в нашия облак в режим от сайт до сайт или път -войн и ако някой иска да настрои VPN услуга на собствения си Windows сървър, той винаги е готов да сподели съвети как да настрои стандартен RAS или OpenVPN. Но колкото и готини да бяхме, не беше най-доброто време да обучаваме клиентите, защото трябваше да коригираме проблема възможно най-бързо с възможно най-малко смущения за потребителите.

Решението, което внедрихме, беше следното. Ние настройваме анализа на преминаващия трафик по такъв начин, че да проследяваме всички опити за установяване на TCP връзка към порт 3389 и да избираме адреси от него, които се опитват да установят връзки с повече от 150 различни сървъра в нашата мрежа за 16 секунди - това са източниците на атака (разбира се, ако някой от клиентите или партньорите има реална нужда да установи връзки с толкова много сървъри от един и същ източник, винаги можете да добавите такива източници към „белия списък“. Освен това, ако в един клас C мрежа за тези 150 секунди са идентифицирани повече от 32 адреса, има смисъл да се блокира цялата мрежа.Блокирането е зададено за 3 дни и ако през това време не са извършени атаки от този източник, този източник се премахва от "черен списък" автоматично Списъкът с блокирани източници се актуализира на всеки 300 секунди.

Този списък е достъпен тук: https://secure.tucha.ua/global-filter/banned/rdp_ddos, можете да изградите своите ACL въз основа на него.

Ние сме готови да споделим изходния код на такава система, в него няма нищо супер сложно (това са няколко прости скрипта, компилирани само за няколко часа „на коляно“), и в същото време може да се адаптира и се използва не само за защита срещу такава атака, но и за откриване и блокиране на всякакви опити за сканиране на мрежата: следвайте тази връзка.

Освен това направихме някои промени в настройките на системата за мониторинг, която сега следи по-отблизо реакцията на контролната група от виртуални сървъри в нашия облак при опит за установяване на RDP връзка: ако реакцията не последва в рамките на секунда , това е повод да се обърне внимание.

Решението се оказа доста ефективно: вече няма оплаквания както от клиенти и партньори, така и от системата за мониторинг. Нови адреси и цели мрежи редовно попадат в черен списък, което показва, че атаката продължава, но вече не засяга работата на нашите клиенти.

Единият в областта не е воин

Днес научихме, че други оператори са се сблъскали с подобен проблем. Някой все още вярва, че Microsoft е направила някои промени в кода на услугата за отдалечен достъп (ако си спомняте, подозирахме същото още първия ден, но отхвърлихме тази версия много скоро) и обещава да направи всичко възможно, за да намери решение. . Някой просто игнорира проблема и съветва клиентите да се защитят (променят порта за връзка, скрият сървъра в частна мрежа и т.н.). И още в първия ден ние не само решихме този проблем, но и създадохме известна основа за по-глобална система за откриване на заплахи, която планираме да разработим.

Специални благодарности на клиенти и партньори, които не мълчаха и не седяха на брега на реката в очакване трупът на врага да изплува по нея един ден, а веднага ни обърнаха внимание на проблема, което ни даде възможност да елиминирайте го в същия ден.

Източник: www.habr.com