Comments 75
Все проблемные машины были 2008 / 2008 R2?
Большинство — таки да, 2008R2, но, смутно припоминается, что были среди них и другие Windows-системы. В течение 24 часов предоставим точный ответ. :-)
Да, большинство — Windows Server 2008R2, но был случай и с одной Windows 10 (да, некоторые клиенты держат в облаке Windows 10, видимо, им так нравится).
А какая лицензия позволяет в вашем облаке держать клиентскую, а не серверную версию Windows?
Если у клиента есть своя лицензия — он ее приносит с собой и использует. По условиям принимаемой клиентами публичной оферты мы не несём ответственности за всё, что происходит внутри виртуального сервера и даже не имеем права анализировать, что на нём работает. Клиент получил виртуальный сервер, а дальше он может делать с ним что угодно, пока на его деятельность не поступает жалоб со стороны.
Т.е. там, где вы это позволяете (только Flex+, я так понимаю?), вы лицензируете виртуальные машины индивидуально, гипервизоры не лицензируете?
А и так, и эдак выходит: те, кто покупают у нас по программе SPLA лицензию на Windows Server Standard — тех лицензируем индивидуально, а ещё у нас есть целый ряд гипервизоров с лицензией Windows Server Datacenter — это для тех, для кого услуга (TuchaBit) подразумевает выделение такой лицензии.
Те машины, что лицензированы через SPLA (даже которые по отдельности), они же под вашим управлением?)
Никак нет. У нас вообще очень малый процент машин, к которым мы имеем право доступа. Такое право мы имеем только в том случае, если
1) клиентом выбран расширенный уровень поддержки как дополнительная платная услуга (тогда административный доступ есть и у нас, и у клиента), или
2) если ему оказывается так называемая «поддержка по гарантии» (тогда административный доступ есть только у нас, клиенту он предоставляется по первому требованию, но тогда «поддержка по гарантии» анулируется и дальнейшая поддержка может оказываться уже только как услуга расширенной поддержки).
Во всех остальных случаях мы не имеем прав доступа к этим машинам и к данным, которые там размещены. Мы заинтересованы в том, чтобы у нас не было даже технической возможности получить этот доступ, потому клиентам часто рекомендуем использовать системы шифрования дисковых разделов.
1) клиентом выбран расширенный уровень поддержки как дополнительная платная услуга (тогда административный доступ есть и у нас, и у клиента), или
2) если ему оказывается так называемая «поддержка по гарантии» (тогда административный доступ есть только у нас, клиенту он предоставляется по первому требованию, но тогда «поддержка по гарантии» анулируется и дальнейшая поддержка может оказываться уже только как услуга расширенной поддержки).
Во всех остальных случаях мы не имеем прав доступа к этим машинам и к данным, которые там размещены. Мы заинтересованы в том, чтобы у нас не было даже технической возможности получить этот доступ, потому клиентам часто рекомендуем использовать системы шифрования дисковых разделов.
Жаль вас разочаровывать, но у вас должен быть доступ внутрь всех машин, лицензированных по SPLA, для соблюдения Customer shall not permit End User… to access, maintain, or otherwise use the Products, except for the sole purpose of accessing the functionality of the Products in the form of Software Services in accordance with the terms of this agreement. (Т.е. нельзя пиратить ПО Microsoft)
Дело в том, что Customer is responsible for all of its obligations under this agreement regardless of the physical location of the servers involved in providing the Software Service. Customer will be responsible to Microsoft for any unauthorized installation, use, copying, access or distribution of the Products by the End User.
Но, конечно, если у вас уже был аудит и сказал, что всё хорошо, тогда наверное действительно соглашение соблюдается)
Дело в том, что Customer is responsible for all of its obligations under this agreement regardless of the physical location of the servers involved in providing the Software Service. Customer will be responsible to Microsoft for any unauthorized installation, use, copying, access or distribution of the Products by the End User.
Но, конечно, если у вас уже был аудит и сказал, что всё хорошо, тогда наверное действительно соглашение соблюдается)
So what? Let's read it carefully: "… accessing the functionality of the Products in the form of Software Services in accordance with the terms of this agreement" — what exactly obliges the provider to manage the software?
The users are "accessing the functionality" — that's exactly what they're doing. There is no violation in letting them to have full administrative access to their operating systems. There are hundreds (if not thousands) of companies providing Microsoft's products to their end users according to SPLA terms — don't you think that they don't give their customers full administrative access to their systems? ;-)
Я не про административный доступ пользователей, а про административный доступ у вас: вы должны следить, чтобы внутри машин, лицензированных по SPLA не было ПО Microsoft, на которое у вас (не у вашего клиента — это важно) нет лицензий. Вон у UltraVDS явно есть какая-то «служба интеграции с вашим личным кабинетом», например — наверное позволяет им выполнять код внутри VM, который можно в т.ч. для аудита использовать.
Интересно… Не совсем понятно, как это следует из процитированного Вами текста, но мы всё же зададим этот вопрос дистрибьютору. Спасибо!
Мне наш поставщик такое отвечал (тоже специально спрашивал):
"...under the SPLA program, as the service provider, you are the licensee, not the End Customer.
The End customer should only have access to the functionality of the product.
As the service provider you have day to day management and control per the agreement"
«At your datacenter, the same applies...The End User will only have access to the functionality of the products.
You will have management and control of the server and software installed on it- not the End User.»
"...under the SPLA program, as the service provider, you are the licensee, not the End Customer.
The End customer should only have access to the functionality of the product.
As the service provider you have day to day management and control per the agreement"
«At your datacenter, the same applies...The End User will only have access to the functionality of the products.
You will have management and control of the server and software installed on it- not the End User.»
Спасибо, этот аспект мы проясним.
Пока дистрибьютер говорит вот чего:
Видимо, имеется в виду таки физический доступ к серверам. Мы ещё их расспросим, сообщим о результатах.
В данном соглашении написано только про доступ к серверам.
По этому как такого доступа внутрь ВМ Вам не нужно иметь.
Видимо, имеется в виду таки физический доступ к серверам. Мы ещё их расспросим, сообщим о результатах.
Напишем официальный запрос в Microsoft, пожалуй. :-)
Если будет такая возможность процитируйте ответ и сюда, очень интересная эта тема
Привет! Как у вас там дела? Написали? Получили что в ответ?
Привет!
В Microsoft мы ещё в прошлом году отправили первый запрос, чтобы получить разъяснения касательно того, должны ли у провайдера быть права доступа к машине. Microsoft подумал-подумал и где-то через месяц прислал ответ, из которого следовало, что вопрос они так и не поняли. :-( Мы сердечно поблагодарили их за ответ на вопрос, который мы не задавали, и сформулировали вопрос немного иначе. Ответ так и не поступил. Отправили повторный запрос. До сих пор ждём ответ.
Мне уже кажется, что они сами не вполне знают, что ответить. Возможно, вопрос этот сейчас вызывает ожесточённые споры где-то внутри корпорации. А возможно — товарищи просто забили :-)
— В.М.
В Microsoft мы ещё в прошлом году отправили первый запрос, чтобы получить разъяснения касательно того, должны ли у провайдера быть права доступа к машине. Microsoft подумал-подумал и где-то через месяц прислал ответ, из которого следовало, что вопрос они так и не поняли. :-( Мы сердечно поблагодарили их за ответ на вопрос, который мы не задавали, и сформулировали вопрос немного иначе. Ответ так и не поступил. Отправили повторный запрос. До сих пор ждём ответ.
Мне уже кажется, что они сами не вполне знают, что ответить. Возможно, вопрос этот сейчас вызывает ожесточённые споры где-то внутри корпорации. А возможно — товарищи просто забили :-)
— В.М.
Использовать средства защиты? Ips?
Версия винды тут не причем. Да и не DDOS это, а попытка подобрать пароль, для того чтобы запустить шифровальщик. Отказ обслуживания это скорее неожиданный побочный эффект.
Это однозначно так.
Но очень интересным является то, что в первые дни интенсивность атаки резко вырастала с 9-10 по Киеву и к 18-19 уже падала. Сейчас уже стало более-менее ровно, а в первые дни именно так и было. Объяснить это включаемыми и выключаемыми компьютерами, явящимися частью какого-то ботнета, было бы можно, но атакующие долбят из самых разных часовых поясов.
Очень странно, но до вот этого сообщения, я нигде не встречал жалобы на что-то отличное от 2008 R2. Попытки подобрать пароль на открытые миру RDP-службы и так ведутся постоянно.
Вот как выглядит этот отказ в обслуживании: сервер явно отправляет RST, при этом внутри машины особой нагрузки нет. Попыток подключения — около 2-х в секунду — не так уж и много, как мне кажется.
Вот как выглядит этот отказ в обслуживании: сервер явно отправляет RST, при этом внутри машины особой нагрузки нет. Попыток подключения — около 2-х в секунду — не так уж и много, как мне кажется.
Есть некоторая вероятность, что у клиента, который столкнулся с этим явлением на Windows 10, проблема заключалась в другом, так как он столкнулся с ней ещё до 31 октября, а устранить её смог только после наката обновлений на систему. Мы по этой причине, когда начался этот флуд, сперва даже подумали, что у всех остальных тоже хорошо бы накатить обновления. На одной машине клиент их установил — его, вроде, отпустило, мы обрадовались и начали рекомендовать делать это всем остальным, но через полчаса проблема проявилась и у тех, кто обновился.
Версия винды тут очень даже при чем.
Достаточно долгое время имею несколько ханипотов смотрящих рдп в дикий интернет.
Они находятся внутри одной подсети (т.е под стандартный сканер должны попадать в одно и то же время) но с разными версиями винды.
Брутят понятное дело всегда. Но именно с Denial of Service по изложенной в статье причине столкнулся 22 числа и только на машинах под управлением Server 2008.
Достаточно долгое время имею несколько ханипотов смотрящих рдп в дикий интернет.
Они находятся внутри одной подсети (т.е под стандартный сканер должны попадать в одно и то же время) но с разными версиями винды.
Брутят понятное дело всегда. Но именно с Denial of Service по изложенной в статье причине столкнулся 22 числа и только на машинах под управлением Server 2008.
Я всегда думал, что выставлять RDP наружу не хорошая идея, даже для одного сервера. Атут у людей под сотю серверов, но желания поставить хотябы банальный шлюз и поднять VPN фантазии не хватает…
Мы там писали об этом: всегда рекомендуем пользователям прятать такие машины в частную сеть и ходить к ним через VPN. Но далеко не все согласны: им надо "удобно", с этим приходится считаться.
Что помешает злоумышленнику точно так же долбиться в VPN, пытаясь подобрать логин/пароль к нему?
Ничего не помешает. Но и злоумышленник никому не помешает, в отличие от ситуации, когда он долбит по службе удаленного доступа и не даёт ей принимать соединения.
Ребята открыли для себя настройку на микротике блокировщика за частые подключения.
Добро пожаловать в ряды системных администраторов.
Добро пожаловать в ряды системных администраторов.
Никак нет у нас везде D-Link, TPLink и Planet. ;-)
Ладно, если без сарказма, то анализировать трафик нужно было централизованно, а не на каком-то одном маршрутизаторе, так как площадок несколько, точки входа в них разные и хотелось видеть общую картину по всей сети, а не разные картины на разных граничных узлах сети.
Не, это не микротик, это fail2ban повторно открыли :)
Такая себе шутка. fail2ban не анализирует транзитный трафик и не может отследить, что какой-то клиент подключается к Windows-серверу и пытается подобрать пароль. Но неплохо, что fail2ban открыли для себя Вы. =)
Fail2ban вообще не анализирует трафик. Он анализирует лог на наличие сигнатуры. Откуда этот лог появился — fail2ban без разницы. На основании фактов обнаружения и частости обнаружения сигнатуры принимается решение о выполнении действия (срабатывает триггер). В Вашем случае — блокирование по Ip. Каким образом будет исполнено действие fail2ban также без разницы — на срабатывание триггера будет запущен скрипт. Слить события для анализа и написать скрипт для блокировки — на мой взгляд именено это и было Вами проделано.
В данном случае нужно подсчитать, к скольки целям обратился один и тот же источник за короткий промежуток времени. Не просто увидеть, что были обращения от одного и того же источника, а точно быть уверенными в том, что его поведение ещё более нетипично. Увы, fail2ban тут никак не подходит.
Для получения требуемого — простой препроцессор-фильтр по частости. Можно прямо с сислога маршрутизаторов. Далее штатный механизм. Бонус — документированность. Больше тревог вызывает нагрузочная способность данных конструкций, т.к. в ирл под серьезной нагрузкой реалтайм анализ будет невозможен.
Всё классно, но зачем в этой схеме fail2ban, если вокруг него придется городить то же самое, что получилось у нас, но без fail2ban? :-)))
А это уже вопрос философский… Закон сохранения велосипедомассы достаточно универсален. Если решение не будет тиражироваться, поддерживаться, развиваться, то да — ни к чему. Решение требовалось здесь и сейчас, решение было предложено.
Если же планируется дальнейшая эксплуатация — целесообразно минимизировать объем логики, который требуется поддерживать и документировать своими силами.
Если же планируется дальнейшая эксплуатация — целесообразно минимизировать объем логики, который требуется поддерживать и документировать своими силами.
На самом деле подходит, несколько лет назад натыкался тут на статью реализации распределенного fail2ban, думаю что поиском ее можно найти.
Примерно по этому же (и по такому как и вы) пути тоже пришлось пройти и был написан свой велосипед для централизации атак. На Linux серверах и ханипотах висит процесс отслеживающий аномальную сетевую активность (типа попытки подключения по 3389 к unix серверу или бруту ssh или запросу административных путей на вебе) и отправлении события в общую БД. в БД запросы централизованно анализируются и на основе статистики со всей подсети (или всех обслуживаемых хостов) принимается решение о блокировке. После чего данные вносятся в базу заблоченных адресов (ссыль на которую я кидал ниже) с настраиваемым весом угроз и собственно таймером блокировки. Далее тот же демон запущенный на хосте забирает информацию о заблоченных адресах и локально блокирует им доступ через iptables. Также эту информацию забирает BRAS и также блокирует доступ ко всей своей подсети
Примерно по этому же (и по такому как и вы) пути тоже пришлось пройти и был написан свой велосипед для централизации атак. На Linux серверах и ханипотах висит процесс отслеживающий аномальную сетевую активность (типа попытки подключения по 3389 к unix серверу или бруту ssh или запросу административных путей на вебе) и отправлении события в общую БД. в БД запросы централизованно анализируются и на основе статистики со всей подсети (или всех обслуживаемых хостов) принимается решение о блокировке. После чего данные вносятся в базу заблоченных адресов (ссыль на которую я кидал ниже) с настраиваемым весом угроз и собственно таймером блокировки. Далее тот же демон запущенный на хосте забирает информацию о заблоченных адресах и локально блокирует им доступ через iptables. Также эту информацию забирает BRAS и также блокирует доступ ко всей своей подсети
Статья вроде 5 летней давности. Моя.
Была в песочнице. И оказалась нафиг не кому не нужна.
awsswa.livejournal.com/32594.html
Была в песочнице. И оказалась нафиг не кому не нужна.
awsswa.livejournal.com/32594.html
у нас тоже последнюю неделю долюят с тех же сетей что в вашем списке, но не рдп, а 25, 443, 139 и 445 порты… устанавливают куча соединений и сервер больше не может устьановить «нужные» соединения
для службы удалённого доступа используется стандартный порт (3389)
На наши терминальные сервера было несколько попыток атак подбора пароля, хотя порты были нестандартными. Так что, порт здесь не при чем.
Одна попытка увенчалась успехом. Но ущерб был минимальным. Хоть логин/пароль для входа в систему за трое суток удалось подобрать, но конкретно на этом сервере профайла этого пользователя не было (профайлы не переносимые). Да и система разграничения доступа была более-менее четко настроена. Поэтому злоумышленнику (тоже с Украины) не удалось зашифровать слишком много. Только незащищенную часть файлопомойки (а кто там хранил важную инфу, тот сам себе злобный Буратино) и один логический (не системный) диск одного диспетчерского АРМ (просто забыли закрыть доступ после завершения настроечных работ). Вот последнее — уже серьезнее: на этом диске крутился рабочий проект сбора телеметрии, а резервная копия лежала как раз в незащищенной файлопомойке. Пришлось ставить более старый проект с отсутствующими некоторыми объектами и 2 недели допиливать его до актуальности.
Потом еще наблюдали такую картину: идет атака подбора паролей, но с разных IP (диапазон весьма широкий — не кустарь работал, как в прошлый раз, а целый ботнет), причем, очень редко и почти незаметно: 2-3 попытки в минуту.
Это я к чему: Отследить скриптами такую активность (редкие попытки с разных IP) и пресечь ее будет весьма затруднительно.
Тем и хорош «самодельный самокат», что алгоритм можно менять как угодно. Чтоб отфильтровать такие вот редкие попытки, можно брать данные не за 2.5 минуты, а за несколько часов. Отслеживать продолжительность сессии (с момента первого SYN до финального RST). Взвешивать среднюю продолжительность и количество таких сессий. Если их как-то слишком много, а средняя продолжительность (или объём переданных данных) совсем малая — банить.
У нас просто задача была в том, чтобы отфильтровать те запросы, которые создают помехи в работе, потому алгоритм фильтрования именно таков. Но его легко адаптировать для других задач.
У нас просто задача была в том, чтобы отфильтровать те запросы, которые создают помехи в работе, потому алгоритм фильтрования именно таков. Но его легко адаптировать для других задач.
Если их как-то слишком много, а средняя продолжительность (или объём переданных данных) совсем малая — банить.
Так кого банить?
Повторяю: Атака велась ботнетом с разных адресов. С очень разных. Из сотен выявленных адресов было обнаружено, кажется, всего 2-3 пары совпадений, да и то разнесенных на часы.
Так что, выявить атаку можно, можно предпринять допмеры по защите. Но автоматически купировать ее блоком по IP в данном случае нельзя.
Мы поступили просто: Настроили брандмауэр на разрешение подключения по RDP только с IP из белого списка. Благо, подключения шли только через местных провайдеров. Но для хостинга, понятное дело, такое не подходит.
Или, как вариант, разрешать подключения по RDP только внутри VPN. Мы своим клиентам всегда советуем поднимать IPSec, но не все готовы (немножко больше телодвижений для пользователя, особенно — если пользователь мобильный и потому site-to-site между офисом и облачной средой задачу не решит).
Вот VPN удавалось поднять только через PPTP. Через L2TP/IPSec никак не выходило. То шлюзовое оборудование не работает по этим протоколам, то с Traffic Inspector конфликтует.
Кстати, главный разработчик TI — мой сосед по лестничной площадке. Так он подтвердил, что подружить шлюз TI с L2TP/IPSec — та еще задача для потомственных шаманов в третьем поколении.
Кстати, главный разработчик TI — мой сосед по лестничной площадке. Так он подтвердил, что подружить шлюз TI с L2TP/IPSec — та еще задача для потомственных шаманов в третьем поколении.
Трудно сказать, почему так, мы с их шлюзами не сталкивались. Может, если бы столкнулись, окажется, что и наши предки были шаманами. :-) Чаще всего клиенты поднимают site-to-site туннель с Mikrotik, там этот самый IPSec очень легко заводится. Ну и road-warriors с обычным Windows, куда же без них.
Так это Вам повезло :)
Мы пользуем TI уже лет 15, или около того. Лучше всего работала 1-я версия. Во второй начались проблемы с построением отчетов. Такое ощущение, что часть трафика просто в отчеты не попадает. Или я не умею их готовить. Но в целом тоже работало нормально.
Но потом все сайты стали переходить на HTTPS, а TI фильтрует по URL только HTTP. В результате куча народа сидят в ОК и других соцсетях, а начальство ругается. И они нас уговорили перейти на 3-ю версию. Мол там MITM и фильтрация по HTTPS тоже работает.
В результате перестали работать некоторые счетчики — трафик обновлений программ должен идти с нулевым весом, но идет с полным. MITM так и не смогли настроить — с терминальных серверов либо нет фильтрации, либо вообще рубит всё (а с обычных компов все работает). И скрипты обслуживания выполнялись не полностью — иногда приходилось их запускать по несколько раз, чтобы отработали. Но скрипты — то немногое, что они по заявке все же починили.
А остальное бесит до такой степени, что хочется снести этот TI и оставить голый виндовый брендмауэр. И без всякого контроля трафика. Или даже просто поставить железный роутер — тот же Mikrotik. Но пока не знаю, как заставить его переключаться на резервного провайдера, если через основного связи нет.
И еще не удается пробросить через шлюз SSH. Т.е. он пробрасывается и даже какая-то движуха через него идет, но все искажено полностью и ничего не работает. Причину так и не понял, но подозреваю, что TI и здесь виноват.
Мы пользуем TI уже лет 15, или около того. Лучше всего работала 1-я версия. Во второй начались проблемы с построением отчетов. Такое ощущение, что часть трафика просто в отчеты не попадает. Или я не умею их готовить. Но в целом тоже работало нормально.
Но потом все сайты стали переходить на HTTPS, а TI фильтрует по URL только HTTP. В результате куча народа сидят в ОК и других соцсетях, а начальство ругается. И они нас уговорили перейти на 3-ю версию. Мол там MITM и фильтрация по HTTPS тоже работает.
В результате перестали работать некоторые счетчики — трафик обновлений программ должен идти с нулевым весом, но идет с полным. MITM так и не смогли настроить — с терминальных серверов либо нет фильтрации, либо вообще рубит всё (а с обычных компов все работает). И скрипты обслуживания выполнялись не полностью — иногда приходилось их запускать по несколько раз, чтобы отработали. Но скрипты — то немногое, что они по заявке все же починили.
А остальное бесит до такой степени, что хочется снести этот TI и оставить голый виндовый брендмауэр. И без всякого контроля трафика. Или даже просто поставить железный роутер — тот же Mikrotik. Но пока не знаю, как заставить его переключаться на резервного провайдера, если через основного связи нет.
И еще не удается пробросить через шлюз SSH. Т.е. он пробрасывается и даже какая-то движуха через него идет, но все искажено полностью и ничего не работает. Причину так и не понял, но подозреваю, что TI и здесь виноват.
Аж захотелось разослать клиентам письмо, мол, нет ли у Вас в инфраструктуре этого чуда техники, чтобы попробовать.
Или, если хотите, возьмите у нас пробный период, а мы попробуем подружить Ваш TI с нашим хозяйством.
Спасибо, но пока что необходимости нет. У нас пока что другая проблема — импортозамещать ПО заставляют.
Если найдется клиент с TI — отпишитесь, пожалуйста. А то, честно говоря, засилье багов в последних версиях и сборках TI напрочь убивают желание разбираться кто виноват во всех косяках и что делать. Проще принять, что во всем виноват TI, ничего с этим не поделать и смириться :)
Тем более, что техподдержка у них стала платная по годовой подписке. Т.е. сообщить о баге, конечно, можно. Но если подписка на ТП закончилась, то исправленную версию все равно не скачаешь :) А так хорошо начиналось. Даже была бесплатная персональная (однопользовательская) версия, которую можно было применять для фильтрации контента. Я у детей ставил, чтобы на порносайты не забрели случайно.
Если найдется клиент с TI — отпишитесь, пожалуйста. А то, честно говоря, засилье багов в последних версиях и сборках TI напрочь убивают желание разбираться кто виноват во всех косяках и что делать. Проще принять, что во всем виноват TI, ничего с этим не поделать и смириться :)
Тем более, что техподдержка у них стала платная по годовой подписке. Т.е. сообщить о баге, конечно, можно. Но если подписка на ТП закончилась, то исправленную версию все равно не скачаешь :) А так хорошо начиналось. Даже была бесплатная персональная (однопользовательская) версия, которую можно было применять для фильтрации контента. Я у детей ставил, чтобы на порносайты не забрели случайно.
185.104.209.71 Долбился в smtp/smtps 4 ноября около 8 вечера
И почему-то числа с 25 октября начало расти число подключений на почтовый сервер.
И почему-то числа с 25 октября начало расти число подключений на почтовый сервер.
Эдак мы составим полную карту чьего-то ботнета :-)
Ну, самое простое: взломать серверные аккаунты и сделать через него релей спама. Как раз по SMTP.
Но с этим всё должно быть просто.
1. Если почтовый сервер оконечный, то релей должен быть запрещен. Если нет, то должна быть включена аутентификация по SMTP.
2. Дополнительная проверка по обратному резольвингу PTR-записей в MX-записи отметает почти 100% подключений ботнета. Но не все.
3. Если есть возможность — включить SPF-контроль.
4. Ну и включить всякие эвристики по полям «To:», «Cc:», «Bcc:». Например, ограничить допустимое число получателей, рубить письма с большим числом чередований кириллицы и латиницы.
Когда у нас был свой SMTP я еще экспериментировал с динамическим выявлением массовых рассылок:
www.courierms.ru/forum/viewtopic.php?t=1840
Результат был неплох (после всех фильтров улавливало еще свыше 30% спама), но от эмуляции к боевой эксплуатации так и не перешли, а потом отказались от своего почтового сервера в пользу PDD на Яндексе. А жаль — спама сейчас гораздо больше.
Так что, защитить SMTP от спама и релея несколько проще, чем RDP от подбора паролей. Да и ущерб от взлома SMTP не критичны. Разве что начнут экстремистскую литературу и приглашения на митинги рассылать. Тогда: да… чревато.
Но с этим всё должно быть просто.
1. Если почтовый сервер оконечный, то релей должен быть запрещен. Если нет, то должна быть включена аутентификация по SMTP.
2. Дополнительная проверка по обратному резольвингу PTR-записей в MX-записи отметает почти 100% подключений ботнета. Но не все.
3. Если есть возможность — включить SPF-контроль.
4. Ну и включить всякие эвристики по полям «To:», «Cc:», «Bcc:». Например, ограничить допустимое число получателей, рубить письма с большим числом чередований кириллицы и латиницы.
Когда у нас был свой SMTP я еще экспериментировал с динамическим выявлением массовых рассылок:
www.courierms.ru/forum/viewtopic.php?t=1840
Результат был неплох (после всех фильтров улавливало еще свыше 30% спама), но от эмуляции к боевой эксплуатации так и не перешли, а потом отказались от своего почтового сервера в пользу PDD на Яндексе. А жаль — спама сейчас гораздо больше.
Так что, защитить SMTP от спама и релея несколько проще, чем RDP от подбора паролей. Да и ущерб от взлома SMTP не критичны. Разве что начнут экстремистскую литературу и приглашения на митинги рассылать. Тогда: да… чревато.
У себя закрыл следующие сети:
С них долбили на 22, 80, 443 порт. до 1600 соединений единовременно.
С них долбили на 22, 80, 443 порт. до 1600 соединений единовременно.
Тоже столкнулся с этим, правда началось еще 22 числа.
Вот мой список (ок 7000) адресов с которых ведутся атаки. Правда в нем не только попытки подключения к рдп на 3389, но и брут ssh/telnet а так же попытки захода на /wp-admin /phpmyadmin и прочих запросов административных путей.
Вот мой список (ок 7000) адресов с которых ведутся атаки. Правда в нем не только попытки подключения к рдп на 3389, но и брут ssh/telnet а так же попытки захода на /wp-admin /phpmyadmin и прочих запросов административных путей.
А что если создать "песочницу" с кредами admin:admin и пусть боты себе балуются.
Honeypot вроде назывется...
Да была такая одно время. Не помню уже, сколько майнилок на ней одновременно было запущено на 1 ядре :-)
А есть какие-то наработки/рецепты по организации «липучки»?
Можете что-нить посоветовать, чтобы она выглядела как работающая внутри сети (а иначе могут не клюнуть), но при этом не несла сама угрозу прочим при взломе?
Можете что-нить посоветовать, чтобы она выглядела как работающая внутри сети (а иначе могут не клюнуть), но при этом не несла сама угрозу прочим при взломе?
Полагаю, зависит от того, что именно должно входить в понятие «выглядела как рабочая». Просто отвечала на попытки соединения по порту 3389? Можно просто взять линукс и на порт 3389 повесить что угодно (netcat, например). Но, наверное, этого недостаточно, так что можно просто взять виртуалку с Windows, посадить её в отдельную частную сеть, а между ней и основной сетью повесить шлюз, который будет только пропускать входящие соединения к ней, но не будет выпускать никаких исходящих соединений из неё. И мониторить это дело. Как-то так, возможно.
… посадить её в отдельную частную сеть, а между ней и основной сетью повесить шлюз, который будет только пропускать входящие соединения к ней, но не будет выпускать никаких исходящих соединений из неё. И мониторить это дело. Как-то так, возможно.
Да… хорошая идея с внутренним шлюзом. Надо подумать, как это можно реализовать. Просто роутеры SOHO-сегмента не умеют блокировать исходящий трафик. Столкнулся с этим при настройке Keenetic.
Придется брать что-то более гибкое, типа того же Mikrotik. Или брать «мыльницу», но ставить ее WANом к «липучке». А на внешнем шлюзе настраивать проброс нужных портов как раз через внутренний шлюз. Как-то так. Но только как? :D
Виртуализация тут как раз очень в тему: на одном и том же физическом компе поднимаются 2 виртуалки: одна — собственно, Windows, которая по сети подключена только ко второй, больше никуда, а вторая — Linux, который имеет интерфейс и во внутреннюю сеть, где первая, и во внешнюю. И там уже iptables какой-нибудь, который будет пробрасывать на Windows всё входящие соединения, а исходящие из этой внутренней сети не выпускать. И всё. :-)
настройки системы мониторинга, которая теперь более пристально следит за реакцией контрольной группы виртуальных серверов в нашем облаке на попытку установить RDP-подключение
Скажите, а как именно вы автоматически диагностируете работоспособность RDP-сервера?
1. Успешное подключение к TCP порту 3389 в пределах заданного таймаута — это не критерий работоспособности, увы.
2. Даже принятие правильного логина/пароля не может являться критерием (это Windows, рабочий стол может просто «висеть» без каких-либо логов в системе).
Поткой установить TCP-соединение мы мониторим не столько работу терминального сервера как такового, а только удостоверяемся в том, что сама служба, которая должна принять соединение, чувствует себя хорошо. Если её «задудосили», она несколько секунд (или даже минут) не может принимать новые соединения вообще и система отправляет RST. Мы на этой контрольной группе проверяем, удалось ли кому-то обойти блокировки. Поначалу, когда список фильтров только начал формироваться, время от времени мониторилка показывала, что этим серверам начинало плохеть, но в течение нескольких минут обновлялись фильтры и серверы эти попускало. Сейчас, когда отфильтровано уже много источников этого безобразия, система мониторинга, тьфу-тьфу, помалкивает.
За пару часов на коленке можно написать скрипт powershell, который читает security logs и добавляет ip злоумышленника в правило windows firewall. Например вот такой serverfault.com/questions/233222/ban-ip-address-based-on-x-number-of-unsuccessful-login-attempts Конкретно у этого скрипта есть значительный недостаток — список добавленных адресов не виден в консоли Firewall, но он работает. Основное его преимущество — в такой блок лист не смогут попасть лигитимные ip и он будет работать даже если rdp на не стандартном порту.
Sign up to leave a comment.
DDoS-атака на RDP-службы: распознать и побороть. Успешный опыт от Tucha