В данном случае нужно подсчитать, к скольки целям обратился один и тот же источник за короткий промежуток времени. Не просто увидеть, что были обращения от одного и того же источника, а точно быть уверенными в том, что его поведение ещё более нетипично. Увы, fail2ban тут никак не подходит.
Такая себе шутка. fail2ban не анализирует транзитный трафик и не может отследить, что какой-то клиент подключается к Windows-серверу и пытается подобрать пароль. Но неплохо, что fail2ban открыли для себя Вы. =)
Никак нет. У нас вообще очень малый процент машин, к которым мы имеем право доступа. Такое право мы имеем только в том случае, если
1) клиентом выбран расширенный уровень поддержки как дополнительная платная услуга (тогда административный доступ есть и у нас, и у клиента), или
2) если ему оказывается так называемая «поддержка по гарантии» (тогда административный доступ есть только у нас, клиенту он предоставляется по первому требованию, но тогда «поддержка по гарантии» анулируется и дальнейшая поддержка может оказываться уже только как услуга расширенной поддержки).
Во всех остальных случаях мы не имеем прав доступа к этим машинам и к данным, которые там размещены. Мы заинтересованы в том, чтобы у нас не было даже технической возможности получить этот доступ, потому клиентам часто рекомендуем использовать системы шифрования дисковых разделов.
Трудно сказать, почему так, мы с их шлюзами не сталкивались. Может, если бы столкнулись, окажется, что и наши предки были шаманами. :-) Чаще всего клиенты поднимают site-to-site туннель с Mikrotik, там этот самый IPSec очень легко заводится. Ну и road-warriors с обычным Windows, куда же без них.
Или, как вариант, разрешать подключения по RDP только внутри VPN. Мы своим клиентам всегда советуем поднимать IPSec, но не все готовы (немножко больше телодвижений для пользователя, особенно — если пользователь мобильный и потому site-to-site между офисом и облачной средой задачу не решит).
Тем и хорош «самодельный самокат», что алгоритм можно менять как угодно. Чтоб отфильтровать такие вот редкие попытки, можно брать данные не за 2.5 минуты, а за несколько часов. Отслеживать продолжительность сессии (с момента первого SYN до финального RST). Взвешивать среднюю продолжительность и количество таких сессий. Если их как-то слишком много, а средняя продолжительность (или объём переданных данных) совсем малая — банить.
У нас просто задача была в том, чтобы отфильтровать те запросы, которые создают помехи в работе, потому алгоритм фильтрования именно таков. Но его легко адаптировать для других задач.
Есть некоторая вероятность, что у клиента, который столкнулся с этим явлением на Windows 10, проблема заключалась в другом, так как он столкнулся с ней ещё до 31 октября, а устранить её смог только после наката обновлений на систему. Мы по этой причине, когда начался этот флуд, сперва даже подумали, что у всех остальных тоже хорошо бы накатить обновления. На одной машине клиент их установил — его, вроде, отпустило, мы обрадовались и начали рекомендовать делать это всем остальным, но через полчаса проблема проявилась и у тех, кто обновился.
А и так, и эдак выходит: те, кто покупают у нас по программе SPLA лицензию на Windows Server Standard — тех лицензируем индивидуально, а ещё у нас есть целый ряд гипервизоров с лицензией Windows Server Datacenter — это для тех, для кого услуга (TuchaBit) подразумевает выделение такой лицензии.
Если у клиента есть своя лицензия — он ее приносит с собой и использует. По условиям принимаемой клиентами публичной оферты мы не несём ответственности за всё, что происходит внутри виртуального сервера и даже не имеем права анализировать, что на нём работает. Клиент получил виртуальный сервер, а дальше он может делать с ним что угодно, пока на его деятельность не поступает жалоб со стороны.
Да, большинство — Windows Server 2008R2, но был случай и с одной Windows 10 (да, некоторые клиенты держат в облаке Windows 10, видимо, им так нравится).
Ладно, если без сарказма, то анализировать трафик нужно было централизованно, а не на каком-то одном маршрутизаторе, так как площадок несколько, точки входа в них разные и хотелось видеть общую картину по всей сети, а не разные картины на разных граничных узлах сети.
Мы там писали об этом: всегда рекомендуем пользователям прятать такие машины в частную сеть и ходить к ним через VPN. Но далеко не все согласны: им надо "удобно", с этим приходится считаться.
Это однозначно так.
Но очень интересным является то, что в первые дни интенсивность атаки резко вырастала с 9-10 по Киеву и к 18-19 уже падала. Сейчас уже стало более-менее ровно, а в первые дни именно так и было. Объяснить это включаемыми и выключаемыми компьютерами, явящимися частью какого-то ботнета, было бы можно, но атакующие долбят из самых разных часовых поясов.
Аж захотелось разослать клиентам письмо, мол, нет ли у Вас в инфраструктуре этого чуда техники, чтобы попробовать.
Или, если хотите, возьмите у нас пробный период, а мы попробуем подружить Ваш TI с нашим хозяйством.
Ну, по всей видимости, то же самое получится через несколько апдейтов и у нас. :-)
Всё классно, но зачем в этой схеме fail2ban, если вокруг него придется городить то же самое, что получилось у нас, но без fail2ban? :-)))
В данном случае нужно подсчитать, к скольки целям обратился один и тот же источник за короткий промежуток времени. Не просто увидеть, что были обращения от одного и того же источника, а точно быть уверенными в том, что его поведение ещё более нетипично. Увы, fail2ban тут никак не подходит.
1) клиентом выбран расширенный уровень поддержки как дополнительная платная услуга (тогда административный доступ есть и у нас, и у клиента), или
2) если ему оказывается так называемая «поддержка по гарантии» (тогда административный доступ есть только у нас, клиенту он предоставляется по первому требованию, но тогда «поддержка по гарантии» анулируется и дальнейшая поддержка может оказываться уже только как услуга расширенной поддержки).
Во всех остальных случаях мы не имеем прав доступа к этим машинам и к данным, которые там размещены. Мы заинтересованы в том, чтобы у нас не было даже технической возможности получить этот доступ, потому клиентам часто рекомендуем использовать системы шифрования дисковых разделов.
У нас просто задача была в том, чтобы отфильтровать те запросы, которые создают помехи в работе, потому алгоритм фильтрования именно таков. Но его легко адаптировать для других задач.
Если у клиента есть своя лицензия — он ее приносит с собой и использует. По условиям принимаемой клиентами публичной оферты мы не несём ответственности за всё, что происходит внутри виртуального сервера и даже не имеем права анализировать, что на нём работает. Клиент получил виртуальный сервер, а дальше он может делать с ним что угодно, пока на его деятельность не поступает жалоб со стороны.
Ладно, если без сарказма, то анализировать трафик нужно было централизованно, а не на каком-то одном маршрутизаторе, так как площадок несколько, точки входа в них разные и хотелось видеть общую картину по всей сети, а не разные картины на разных граничных узлах сети.
Никак нет у нас везде D-Link, TPLink и Planet. ;-)
Мы там писали об этом: всегда рекомендуем пользователям прятать такие машины в частную сеть и ходить к ним через VPN. Но далеко не все согласны: им надо "удобно", с этим приходится считаться.
Это однозначно так.
Но очень интересным является то, что в первые дни интенсивность атаки резко вырастала с 9-10 по Киеву и к 18-19 уже падала. Сейчас уже стало более-менее ровно, а в первые дни именно так и было. Объяснить это включаемыми и выключаемыми компьютерами, явящимися частью какого-то ботнета, было бы можно, но атакующие долбят из самых разных часовых поясов.
В нашем случае изобрести свой простенький самокат для анализа оказалось в самом деле намного быстрее (ну да, сани — летом, детям — мороженое).