Раскажам вам прахалодную гісторыю аб тым, як "трэція асобы" спрабавалі перашкодзіць працы нашых кліентаў, і як гэтая праблема была вырашана.
Як усё пачалося
А пачалося ўсё з раніцы 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 и Пецька?
Пакуль разбіраліся, атрымалі аналагічныя звароты ад яшчэ некалькіх кліентаў і партнёраў.
А што ўвогуле адбываецца на гэтых машынах?
У часопісах рэгістрацыі падзей поўна паведамленняў аб спробе падабраць пароль:
Звычайна такія спробы рэгіструюцца на ўсіх серверах, дзе для службы выдаленага доступу выкарыстоўваецца стандартны порт (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