Ще ви разкажем една интересна история за това как "трети лица" се опитаха да попречат на работата на нашите клиенти, и как беше решен този проблем.
Как всичко започна
Всичко започна сутринта на 31 октомври, в последния ден на месеца, когато на много хора спешно им беше необходимо да приключат важни въпроси.
Един от партньорите, който държи в нашето облако няколко виртуални машини на клиенти, които обслужва, съобщи, че от 9:10 до 9:20 няколко Windows сървъра, работещи на нашата украинска площадка, не приемаха връзки от услугата за дистанционен достъп, потребителите не можеха да влязат в своите работни настолни компютри, но след няколко минути проблемът сякаш се реши сам.
Проверихме статистиката на работата на комуникационните канали, но не открихме нито пик на трафика, нито падания. Проверихме статистиката на натоварването на изчислителните ресурси - никакви аномалии. И какво беше това?
След това друг партньор, който хоства в нашето облако още около сто сървъра, също съобщи за подобни проблеми, които някои от техните клиенти отбелязаха, като същевременно се установи, че общо сървърите са налични (правилно отговарят на ping тест и други заявки), но услугата за дистанционен достъп на тези сървъри понякога приема нови връзки, а понякога ги отхвърля, като става дума за сървъри на различни площадки, трафикът към които идва от различни канали за пренос на данни.
Нека погледнем този трафик. Пакет с искане за установяване на връзка идва на сървъра:
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 и Petya?
Докато се разбирахме, получихме подобни обаждания от още няколко клиенти и партньори.
Какво всъщност се случва на тези машини?
В дневниците на регистриране на събитията има много съобщения за опити за подбиране на парола:
Обикновено подобни опити се регистрират на всички сървъри, където за услугата за дистанционен достъп се използва стандартният порт (3389) и е разрешен достъпът от всякъде. В Интернет има изобилие от ботове, които постоянно сканират всички налични точки за свързване и се опитват да подберат парола (по именно тази причина ние настоятелно препоръчваме да се използват сложни пароли вместо "123"). Въпреки това, интензивността на тези опити в този ден беше твърде висока.
Какво да правим?
Да препоръчаме на клиентите да отделят много време, за да променят настройките на огромен брой крайни потребители, за да преминат на друг порт? Не е много добра идея, клиентите няма да се зарадват. Да препоръчаме разрешаване на достъпа само чрез VPN? В спешност и паника да наложим IPSec-съединения, където те не са наложени, – вероятно и това няма да донесе късмет на клиентите. Въпреки това, трябва да се каже, че в каквото и да е било, ние винаги препоръчваме да скрием сървъра в частна мрежа и сме готови да помогнем с настройките, а за любителите да се занимават сами, споделяме инструкции за настройка на IPSec/L2TP в нашето облако в режим site-to-site или road-warrior, а ако някой желае да създаде VPN-услуга на своя собствен Windows-сървър – винаги сме готови да споделим съвети относно настройка на стандартен RAS или OpenVPN. Но, каквито и да сме страхотни, това не беше най-доброто време за просветителска работа сред клиентите, тъй като трябваше да се разреши проблема възможно най-бързо с минимално напрежение за потребителите.
Решението, което внедрихме, беше следното. Наложихме анализ на входящия трафик по такъв начин, че да следим всички опити за установяване на TCP-соединение на порт 3389 и да избираме адресите, които в рамките на 150 секунди се опитват да се свържат с повече от 16 различни сървъра в нашата мрежа – това са източниците на атаката (разбира се, ако някой от клиентите или партньорите има реална нужда да установи връзки с толкова много сървъри от един и същ източник, винаги може да добавим такива източници в «белия списък». В същото време, ако в една мрежа клас C за тези 150 секунди се установят повече от 32 адреса, има смисъл да блокираме цялата мрежа. Блокировката се установява за 3 дни, а ако през това време не са извършвани атаки от този източник, той автоматично се премахва от «черния списък». Списъкът на блокираните източници се актуализира на всеки 300 секунди.
Т този списък е достъпен на следния адрес: , можете да изградите ACL на базата на него.
Готови сме да споделим изходния код на такава система, в него няма нищо изключително сложно (това са няколко прости скрипта, съставени буквално за няколко часа «на коляно»), и в същото време може да се адаптира и използва не само за защита от такава атака, но и за откриване и блокиране на всякакви опити за сканиране на мрежата:
Освен това внесохме някои промени в настройките на системата за мониторинг, която сега по-внимателно следи реакцията на контролна група виртуални сървъри в нашето облако на опити за установяване на RDP-връзка: ако реакцията не последва в рамките на секунда – това е повод за внимание.
Решението се оказа достатъчно ефективно: вече няма оплаквания нито от страна на клиентите и партньорите, нито от страната на системата за мониторинг. В «черния списък» редовно попадат нови адреси и цели мрежи, което показва, че атаката продължава, но вече не влияе на работата на нашите клиенти.
Один в поле не воин
Днес установихме, че и други оператори се сблъскват с подобен проблем. Някои все още смятат, че Microsoft е направила някакви промени в кода на услугата за отдален достъп (ако помните, ние заподозряхме същото в първия ден, но бързо отхвърлихме тази версия) и обещават да направят всичко възможно, за да намерят решение възможно най-скоро. Някои просто игнорират проблема и съветват клиентите да се защитават сами (да променят порта за свързване, да скрият сървъра в частна мрежа и т.н.). А ние в първия ден не само, че решихме този проблем, но и създадохме основа за по-глобална система за откриване на заплахи, която планираме да развиваме.
Отделно благодаря на клиентите и партньорите, които не мълчаха и не седяха на брега на реката в очакване на трупа на врага, а веднага ни обърнаха внимание на проблема, което ни даде възможност да го отстраним още същия ден.
Източник: habr.com
