Ще ви разкажем интересна история за това как "трети страни" се опитваха да попречат на работата на нашите клиенти и как този проблем беше решен.
Как започна всичко
Всичко започна на сутринта на 31 октомври, в последния ден на месеца, когато много хора се опитват да приключат спешни и важни въпроси.
Един от партньорите, който държи в нашето облако няколко виртуални машини на свои клиенти, докладва, че между 9:10 и 9:20 няколко Windows сървъра, работещи на нашата украинска площадка, не приемаха връзки за Remote Desktop, потребителите не можеха да влязат в своите работни плотове, но след няколко минути проблемът сякаш сам по себе си изчезна.
Проверихме статистиката на каналите за свързаност, но не открихме нито рязко увеличаване на трафика, нито спадове. Погледнахме и натоварването на изчислителните ресурси – никакви аномалии. И какво всъщност се случи?
След това друг партньор, който хоства в нашето облако още около сто сървъра, съобщи за подобни проблеми, които някои от техните клиенти също отбелязаха, като стана ясно, че сървърите всичките са достъпни (положително отговарят на ping теста и други запитвания), но Remote Desktop услугата на тези сървъри понякога приема нови връзки, а понякога ги отказва, като става въпрос за сървъри на различни площадки, трафикът към които постъпва от различни канали за предаване на данни.
Нека погледнем този трафик. Пакет с искане за установяване на връзка достига до сървъра:
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
Това означава, че проблемът явно не се дължи на някакви неизправности в инфраструктурата, а на нещо друго. Може би всички потребители имат проблеми с лицензията на Remote Desktop? Може би в тяхната система се е внедрило злонамерено софтуерно, което днес се е активирало, както преди две години с 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
