Comments 41
Это работа ради работы?
В Wiki Mikrotik есть статья «Bruteforce login prevention» как сделать ip firewall filter для защиты от брутфорса.
Или я чего-то не понял?
В Wiki Mikrotik есть статья «Bruteforce login prevention» как сделать ip firewall filter для защиты от брутфорса.
Или я чего-то не понял?
В какой-то степени да, это скорее работа ради опыта, но это не умоляет ценности.
Я не прав в том, что опустил эту деталь в самый низ и не сказал об этом сразу.
Я использую механику защиты от брутфорса предлагаемую Микротиком, но мне не нравится как она работает.
Во первых: брутфорсер бывает хитрый, он высчитывает таймаут stage1, и делает так что его ip не попадают в блэклист.
Во вторых: что бы эта механика работала лучше я бы сделал более трех этапов проверки перед баном(штук 6 или даже 9, чем больше тем лучше), но это нагромождение.
Поясню, интересный факт, при отправке почты через мобильные сети, по какой-то причине последовательно прилетает 3 SYNа, то есть фактически устанавливается 3 соединения и ip src сразу попадает аж на третий этап(заключительный этап), который держит его там, допустим, 2 минуты. При попытке отправить еще что-нибудь, он попадает в банлист. Это неприятно, особенно для директора с его iphone.
Я не прав в том, что опустил эту деталь в самый низ и не сказал об этом сразу.
Я использую механику защиты от брутфорса предлагаемую Микротиком, но мне не нравится как она работает.
Во первых: брутфорсер бывает хитрый, он высчитывает таймаут stage1, и делает так что его ip не попадают в блэклист.
Во вторых: что бы эта механика работала лучше я бы сделал более трех этапов проверки перед баном(штук 6 или даже 9, чем больше тем лучше), но это нагромождение.
Поясню, интересный факт, при отправке почты через мобильные сети, по какой-то причине последовательно прилетает 3 SYNа, то есть фактически устанавливается 3 соединения и ip src сразу попадает аж на третий этап(заключительный этап), который держит его там, допустим, 2 минуты. При попытке отправить еще что-нибудь, он попадает в банлист. Это неприятно, особенно для директора с его iphone.
И да, забыл сказать.
Цифры полученные в первом SQL запросе (с которого начиналась статья) были при уже включенном «Bruteforce login prevention».
Цифры полученные в первом SQL запросе (с которого начиналась статья) были при уже включенном «Bruteforce login prevention».
По-хорошему, количество записей в банлисте нужно ограничить. Возможна ситуация когда добавится много правил и будет тормозить маршрутизация, либо тормозить процесс изменения этого списка.
Возможно. Есть идеи как отследить торможение маршрутизации и процесс добавления в список?
Пока банлист держит запись сутки, буду наблюдать за динамикой появления новых записей.
Пока банлист держит запись сутки, буду наблюдать за динамикой появления новых записей.
Через систему мониторинга отслеживать среднюю загрузку CPU (это можно отследить по SNMP), но это только примерная будет оценка, если выше 60-70% тогда начинайте искать проблему.
С изменением банлиста — логировать на график время работы вашего обновляющего скрипта, а также сделать триггер на время отработки скрипта, если оно раза в три больше обычного то паниковать.
С изменением банлиста — логировать на график время работы вашего обновляющего скрипта, а также сделать триггер на время отработки скрипта, если оно раза в три больше обычного то паниковать.
В крайней версии openssh ключи DSA объявлены deprecated.
Вам лучше сделать обратную фишку: отследить длительность сессии и легитимные адреса подключающиеся к вашему RDP и уже получив список легитимных адресов и длительности автоматически корректировать время интервала блокировки нарушителей.
Это будет уже искусственный интеллект )
Как предлагаете отслеживать длительность сессии? Есть вариант вычислять время между приходом SYN и FIN, с соответствующими src:sport dst:dport, но FIN может и не прилететь.
Автоматически корректировать таймаут, да, идея хорошая, пожалуй нарушителей можно вычислить и по другим признакам, обычно атаки проходят в промежутках времени и повторяются в скором времени. Надо понаблюдать.
Как предлагаете отслеживать длительность сессии? Есть вариант вычислять время между приходом SYN и FIN, с соответствующими src:sport dst:dport, но FIN может и не прилететь.
Автоматически корректировать таймаут, да, идея хорошая, пожалуй нарушителей можно вычислить и по другим признакам, обычно атаки проходят в промежутках времени и повторяются в скором времени. Надо понаблюдать.
Ну в том же микротике отследить длительность сессии можно и так (буду писать для sstp, его просто и быстро накидать на лабораторном столе, а то рабочие столы у меня не подключаются без обёртки в виде IKEv2 или ipsec/vpn):
1) сначала отлавливаем соединение с состоянием новое и помечаем соединение
2) далее отлавливаем соединение в состоянии установлено и пометкой созданной шагом выше, сохраняем адрес источника.
/ip firewall mangle
add action=mark-connection chain=prerouting connection-state=new dst-port=443 new-connection-mark=«SSTP connect» passthrough=yes protocol=tcp
add action=add-src-to-address-list address-list=sstp-login address-list-timeout=10m chain=prerouting connection-mark=«SSTP connect» connection-state=established dst-port=\
443 protocol=tcp
Время можно поставить и меньше, но тогда будет увеличена нагрузка на процессор микротика (у меня это подопытное крутится в виде виртуалки на отдельном лабораторном сервере, поэтому я могу его очень сильно нагружать).
Если соединение установлено, то время существования адреса постоянно будет близко к заданному вами значению (в моём примере это получается около 9 минут, связано с временем удержания соединения в клиенте sstp соединения равному 60 секунд).
Таким образом вы получите адреса подключившиеся к вашему с достаточно длительным сроком работы (отдельным сборщиком логов собираем раз в 10 минут все адреса из таблицы микротика в БД и там уже считаем длительность их подключения к вашему сервису, хотя это можно прокрутить и на микротике, но после вчерашнего корпоратива голова как-то не варит написать полное решение ;) ).
1) сначала отлавливаем соединение с состоянием новое и помечаем соединение
2) далее отлавливаем соединение в состоянии установлено и пометкой созданной шагом выше, сохраняем адрес источника.
/ip firewall mangle
add action=mark-connection chain=prerouting connection-state=new dst-port=443 new-connection-mark=«SSTP connect» passthrough=yes protocol=tcp
add action=add-src-to-address-list address-list=sstp-login address-list-timeout=10m chain=prerouting connection-mark=«SSTP connect» connection-state=established dst-port=\
443 protocol=tcp
Время можно поставить и меньше, но тогда будет увеличена нагрузка на процессор микротика (у меня это подопытное крутится в виде виртуалки на отдельном лабораторном сервере, поэтому я могу его очень сильно нагружать).
Если соединение установлено, то время существования адреса постоянно будет близко к заданному вами значению (в моём примере это получается около 9 минут, связано с временем удержания соединения в клиенте sstp соединения равному 60 секунд).
Таким образом вы получите адреса подключившиеся к вашему с достаточно длительным сроком работы (отдельным сборщиком логов собираем раз в 10 минут все адреса из таблицы микротика в БД и там уже считаем длительность их подключения к вашему сервису, хотя это можно прокрутить и на микротике, но после вчерашнего корпоратива голова как-то не варит написать полное решение ;) ).
Для RDP у меня есть другая идея.
Все тот же Rsyslog должен собирать логи windows, отправляемые, например, с помощью evtsys(связка мне уже знакома, я использовал её ранее). Но для хранения тут уже понадобится mongodb, логи windows по своему формату не очень читаемы. До прикручивания монги я еще не добрался, но руки чешутся. При таком решении, анализ можно будет проводить уже на уровне аудита системы и открываются широкие перспективы.
Все тот же Rsyslog должен собирать логи windows, отправляемые, например, с помощью evtsys(связка мне уже знакома, я использовал её ранее). Но для хранения тут уже понадобится mongodb, логи windows по своему формату не очень читаемы. До прикручивания монги я еще не добрался, но руки чешутся. При таком решении, анализ можно будет проводить уже на уровне аудита системы и открываются широкие перспективы.
А я вам снова посоветую ELK-стек, и специальный компонент для windows-серверов winlogbeat
www.elastic.co/videos/getting-started-with-winlogbeat
www.elastic.co/videos/getting-started-with-winlogbeat
Простите великодушно, но задача из разряда «как приличной девушке ходить ночью топлесс, отгоняя приставал газовым баллончиком. выбираем баллончик». 21 век. В интернете повсеместно ssl, любая китайская мыльница умеет в l2tp/ipsec, у микротиков vpn на любой вкус, а вы о брутфорсе-пробросе rdp. Не надо так
Хе-хе, прикольная аналогия.
Я рассматривал этот вариант первым делом, как только приступил к своим обязанностям.
Но понял, что мои секьюрные рвения никто не оценил. Так как прикручивание клиентов через ipsec/l2tp несет за собой много неудобств для самих пользователей и как следствие головную боль админу. Это в первую очередь, но положим мы справились. А теперь представьте что вы приехали в гости, и вам нужно срочно подключиться по RDP к вашему рабочему серверу и выполнит некоторые действия в 1С, делать на смартфоне это мука, а что бы подключится с компа, вам нужно сначала настроить ipsec/l2tp ) но вы не админ, или админ но у вас нет ключа-сертификата или PSK. И снова головная боль админу, а он катается на лыжах где-нибудь в лесу :)
Про маршрутизацию в туннель и совместимость адресного пространства дома и работы я даже и говорить не буду, это жопа жопная для простого человека(не админа).
Я рассматривал этот вариант первым делом, как только приступил к своим обязанностям.
Но понял, что мои секьюрные рвения никто не оценил. Так как прикручивание клиентов через ipsec/l2tp несет за собой много неудобств для самих пользователей и как следствие головную боль админу. Это в первую очередь, но положим мы справились. А теперь представьте что вы приехали в гости, и вам нужно срочно подключиться по RDP к вашему рабочему серверу и выполнит некоторые действия в 1С, делать на смартфоне это мука, а что бы подключится с компа, вам нужно сначала настроить ipsec/l2tp ) но вы не админ, или админ но у вас нет ключа-сертификата или PSK. И снова головная боль админу, а он катается на лыжах где-нибудь в лесу :)
Про маршрутизацию в туннель и совместимость адресного пространства дома и работы я даже и говорить не буду, это жопа жопная для простого человека(не админа).
вы приехали в гости, и вам нужно срочно подключиться по RDP к вашему рабочему серверу
Не нужно такого хотеть.
Сейчас есть автоматические вирусы, которые заходят в 1С по RDP и шифруют базу. Ни с телефона, ни с гостевого компьютера никогда не делайте этого.
Полностью поддержу, что нужно ходить только через vpn.
Заранее можно озаботиться максимально широким спектром настроек для различных устройств (заскриншотить ключевые моменты и добавить в доку). И сделать для всех потенциальных пользователей аккаунты (вероятно, в пределе — для всех) и сервис самовосстановления данных по смс.
В остальном — rdp наружу — это практически 100% дыра в безопасности. Т.к. может быть и уязвимость в tcp стеке рдп-сервера, так и в протоколе rdp
А плодить jump-терминалы — так себе идея
Заранее можно озаботиться максимально широким спектром настроек для различных устройств (заскриншотить ключевые моменты и добавить в доку). И сделать для всех потенциальных пользователей аккаунты (вероятно, в пределе — для всех) и сервис самовосстановления данных по смс.
В остальном — rdp наружу — это практически 100% дыра в безопасности. Т.к. может быть и уязвимость в tcp стеке рдп-сервера, так и в протоколе rdp
А плодить jump-терминалы — так себе идея
Все не так сложно с впн. Если время будет — напишу статью как это нормально сделать, с фэйловером туннелей, разделением доступа, win/mac-удаленщиками и прочими глупостями. Пока надо добить черновик про бэкап postgresql-баз 1с средствами bacula. Не переключайтесь.
А по теме простое правило. Выставляйте что-то через dnat только в крайнем случае.
А по теме простое правило. Выставляйте что-то через dnat только в крайнем случае.
1. Algo VPN разворачивается за минуты.
2. Блок «белого» адресного пространства для п. 1 решает все вопросы несовместимости адресов.
3. Доступ к RDP только с заданного в п. 2 блока адресов решает все вопросы с безопасностью протокола RDP.
ps: это не отменяет целенаправленной атаки с подменой адреса, но это уже другой разговор.
2. Блок «белого» адресного пространства для п. 1 решает все вопросы несовместимости адресов.
3. Доступ к RDP только с заданного в п. 2 блока адресов решает все вопросы с безопасностью протокола RDP.
ps: это не отменяет целенаправленной атаки с подменой адреса, но это уже другой разговор.
И кстати хоть в публикации идет речь про RDP, но это все лишь частный случай, просто пример предоставленный для демонстрации плюшек получаемых при сборе и анализе логов маршрутизатора.
Широкий простор для мечты и для жизни,
Логи в БД открывают для нас…
Широкий простор для мечты и для жизни,
Логи в БД открывают для нас…
Это вопрос философский теперь. Работает ли вообще бан по ip?
Учитываем, что
- умные брутеры уже давным-давно пользуются широкими пудами адресов (бот-неты, провайдеры с динамическим ip, в конце-концов, облачные провайдеры с виртуалками с эфемерными ip)
- потихонечку — распространение ipv6 (не напасешься ОЗУ и проца, чтобы лочить эти адреса)
- провайдеров, предоставляющих "серые" ip клиентам и использующие nat для выхода в интернет, а таковых на российском рынке большинство (что мобильные операторы, что стационарные — вроде Ростелеком).
Представьте себе радость генерального, когда он с мобильного телефона не сможет зайти на сервер, потому что случайно пошарил адрес с брутфорсером ?!?!?!
| 194.113.106.150 | 12345 | 67 |
| 194.113.106.152 | 12345 | 167 |
| 194.113.106.153 | 12345 | 190 |
| 194.113.106.154 | 12345 | 192 |
| 194.113.106.155 | 12345 | 190 |
| 194.113.106.156 | 12345 | 216 |
| 194.113.106.158 | 12345 | 124 |Наглядный пример широкого пула адресов. Возможно и шире, надо подумать как за этим следить.
Серые адреса да, проблема, но я пока не видел, что бы с них прилетали подобные атаки.
Работает. На почтовике в логе:
86.47.96.237 [01A8] 12:17:57 >>> 535 5.7.8 Authentication credentials invalid
выясняем кто:
PEER_AS | IP | BGP Prefix | AS Name
174 | 86.47.96.237 | 86.40.0.0/13 | COGENT-174 — Cogent Communications, US
В ФВ блочим 86.40.0.0/13.
Работает автоматически, ибо достали.
Очен редко бывают жалобы о том, что почта перестала ходить.., тогда выясняем откуда её посылают и делаем исключение на конкретный адрес оставив остальную часть адресов в запрете.
86.47.96.237 [01A8] 12:17:57 >>> 535 5.7.8 Authentication credentials invalid
выясняем кто:
PEER_AS | IP | BGP Prefix | AS Name
174 | 86.47.96.237 | 86.40.0.0/13 | COGENT-174 — Cogent Communications, US
В ФВ блочим 86.40.0.0/13.
Работает автоматически, ибо достали.
Очен редко бывают жалобы о том, что почта перестала ходить.., тогда выясняем откуда её посылают и делаем исключение на конкретный адрес оставив остальную часть адресов в запрете.
Вот, вот. Была у меня мысль написать в публикации именно про бан при работе с smtp, но побоялся быть банальным. Хотя изначально реализовал именно защиту smtp, аналогичным в способом, только с другими интервалами и счетчиками.
Эм… Очень интересно почитать про грамотную реализацию SMTP бана. Опять же — у меня есть подозрения, что ее сделать корректно не получится, без нежелательного отключения крупных почтовиков типа gmail/yandex/mail etc.
Считаю если можно перенаправить логи smtp на связку rsyslog->БД, не сложно будет изловить негодяя подбирающего пароль и отправить в бан.
В моем случае я пока не научился перенаправлять логи Лотус Домино куда либо, да и логи там надо сказать скудные, по сравнению с IceWarp. В Лотусе все логи складываются в свою БД, надо научится к ней подключаться внешними тогда можно будет и анализировать.
Логи почтовика лучше чтения содержимого пакетов, так как шифрованый smtp уже не особо почитаешь. А так на микротике есть возможность читать на лету не шифрованный smtp, я например использую такую связку: если в пакете smtp присутствует фраза AUTH LOGIN то запускается цепочка аналогичная «Bruteforce login prevention».
Мы ведь говорим именно про брут smtp?
В моем случае я пока не научился перенаправлять логи Лотус Домино куда либо, да и логи там надо сказать скудные, по сравнению с IceWarp. В Лотусе все логи складываются в свою БД, надо научится к ней подключаться внешними тогда можно будет и анализировать.
Логи почтовика лучше чтения содержимого пакетов, так как шифрованый smtp уже не особо почитаешь. А так на микротике есть возможность читать на лету не шифрованный smtp, я например использую такую связку: если в пакете smtp присутствует фраза AUTH LOGIN то запускается цепочка аналогичная «Bruteforce login prevention».
Мы ведь говорим именно про брут smtp?
А так на микротике есть возможность читать на лету не шифрованный smtp, я например использую такую связку: если в пакете smtp присутствует фраза AUTH LOGIN то запускается цепочка аналогичная «Bruteforce login prevention».
Мы ведь говорим именно про брут smtp?
А можно чуть подробнее?
да, тоже интересно, но в теории такое скриптингом внутри микротика реализуется на ура.
Практика показала, что неэффективно использовать механику последовательного добавления в src-address-list`ы по типу «Bruteforce login prevention». Часто случаются ложные срабатывания, часто случается что брутфорсер остается незамеченным.
Поэтому вычисление негодяя я реализовал по предложенной в статье схеме, через собранные логгером метаданные.
Есть два правила, оба они размещены выше, того, которое разрешает прохождение уже установленных соединений, так как AUTH LOGIN прилетает именно в ESTABLISHED пакетах. Ну и дропать надо опять же установленное соединение. Не знаю как на других почтовых серверах, но на лотусе я наблюдал как в рамках одного TCP соединения происходит подбор паролей до 1000 попыток(возможно бывало и больше), абсолютно безнаказанно.
На микротике работают такие правила:
Поэтому вычисление негодяя я реализовал по предложенной в статье схеме, через собранные логгером метаданные.
Есть два правила, оба они размещены выше, того, которое разрешает прохождение уже установленных соединений, так как AUTH LOGIN прилетает именно в ESTABLISHED пакетах. Ну и дропать надо опять же установленное соединение. Не знаю как на других почтовых серверах, но на лотусе я наблюдал как в рамках одного TCP соединения происходит подбор паролей до 1000 попыток(возможно бывало и больше), абсолютно безнаказанно.
На микротике работают такие правила:
add action=drop chain=forward comment="drop smtp brute force" connection-state=invalid,established,related,new,untracked dst-address=192.168.y.x dst-port=25,110 in-interface="VLAN55 - RT_INET" log=yes log-prefix=DROP_SMTP_BRUTE protocol=tcp src-address-list=smtp_banlist
add action=log chain=forward connection-state=established,related,untracked content="AUTH LOGIN" dst-address=192.168.y.x dst-port=25 in-interface="VLAN55 - RT_INET" log=yes log-prefix=SMTP_AUTH_LOGIN protocol=tcp src-address-list=!white_list_brute
Сам бился над подобным вопросом, как лучше банить брутфорсеров, в итоге сильно модифицировал решение с вики микротика.
Но любой бан по IP приводит к большому количеству, порой, очень неприятных эффектов: от ложных срабатываний до не срабатывания в тех случаях, когда это необходимо.
Причём, это будет в любом случае, а модификация способов определения бан/не бан позволяет только сократить эти эффекты, но исключить их не удастся.
Данный же способ — зло, т.к. достаточно представить терминальник, на котором работают 5 человек с одного офиса, а потом, у их провайдера происходит авария и 3-4 обрыва соединения за день… итого, 20 новых подключений за день, IP в бан, а 5 юзеров не смогут работать))
Но любой бан по IP приводит к большому количеству, порой, очень неприятных эффектов: от ложных срабатываний до не срабатывания в тех случаях, когда это необходимо.
Причём, это будет в любом случае, а модификация способов определения бан/не бан позволяет только сократить эти эффекты, но исключить их не удастся.
Данный же способ — зло, т.к. достаточно представить терминальник, на котором работают 5 человек с одного офиса, а потом, у их провайдера происходит авария и 3-4 обрыва соединения за день… итого, 20 новых подключений за день, IP в бан, а 5 юзеров не смогут работать))
Почему же сразу «зло»? если включить фантазию, то возможности реализации аналитики с помощью SQL и bash сильно выше чем возможности которые дает сам Микротик. Или вы считаете что вам удалось модифицировать «зло» предложенное вендором в менее злое «зло» чем возможно сделать с помощью накопленных данных SQL и всего что можно только запустить на linux?
Вопрос блокировки офиса с 5 сотрудниками решается быстро. Три варианта:
1 Если они имеют статический ip то просто вносятся в белый лист
2 Если нет статики им ставится железка поднимающая туннель
3 Если нет денег на новую железку, они звонят мне, говорят что у них не работает и я за пару кликов удаляю их из банлиста.
К тому же, редко случается когда у провайдера падает канал пять раз в день, на моей памяти ни разу. Плюс ко всему, представление которым мы выбираем данные из БД можно переписать под свои реалии.
По поводу «сократить эти эффекты» согласен. Нет антибиотиков которые бы не убивали микрофлору кишечника. Но слышал, врачи говорят, при внутримышечном введении кишечник страдает меньше.
Вопрос блокировки офиса с 5 сотрудниками решается быстро. Три варианта:
1 Если они имеют статический ip то просто вносятся в белый лист
2 Если нет статики им ставится железка поднимающая туннель
3 Если нет денег на новую железку, они звонят мне, говорят что у них не работает и я за пару кликов удаляю их из банлиста.
К тому же, редко случается когда у провайдера падает канал пять раз в день, на моей памяти ни разу. Плюс ко всему, представление которым мы выбираем данные из БД можно переписать под свои реалии.
По поводу «сократить эти эффекты» согласен. Нет антибиотиков которые бы не убивали микрофлору кишечника. Но слышал, врачи говорят, при внутримышечном введении кишечник страдает меньше.
Давайте честно — port knocking гораздо более надёжное решение, чем бан по ip.
Проблема только в том, что придется оборачивать rdp подключение в скрипты.
И это нормально можно сделать только на полноценных клиентах (win/lin/mac).
Для мобильных клиентов — не знаю.
Ещё можно было бы трафик гнать через ssh туннель, но это оставляется возможность брута ssh реквизитов
Проблема только в том, что придется оборачивать rdp подключение в скрипты.
И это нормально можно сделать только на полноценных клиентах (win/lin/mac).
Для мобильных клиентов — не знаю.
Ещё можно было бы трафик гнать через ssh туннель, но это оставляется возможность брута ssh реквизитов
Все таки лучше VPN пока ничего не придумали. У нас как-то у одного сотрудника на его ноуте никак не получалось создать подключение к офисному vpn, но на телефоне замечательно подключалось. Так что он на ноуте через телефон выходил на офис.
Cat, буфер обмена, блокнот, ftp с помощью drag'n'drop…
Зачем же так сложно, с вашего же линукса scp файла на Микротик. А не заработало у вас скорее всего из-за (виндового) перевода строки.
Зачем же так сложно, с вашего же линукса scp файла на Микротик. А не заработало у вас скорее всего из-за (виндового) перевода строки.
Навевает анекдот про группу школьников в зоопарке «А слона то я и не заметил.»
Нет, это был не перевод строки, ftp на микроте отключен и заблокирован правилами, катнуть, копипастнуть, перетащить быстрее чем включать ftp.
Затык, мне кажется, был в процедуре создании пользователя и привязки pub_rsa, когда я его делал через winbox — не получилось, когда создал его через консоль — получилось.
Нет, это был не перевод строки, ftp на микроте отключен и заблокирован правилами, катнуть, копипастнуть, перетащить быстрее чем включать ftp.
Затык, мне кажется, был в процедуре создании пользователя и привязки pub_rsa, когда я его делал через winbox — не получилось, когда создал его через консоль — получилось.
Извиняюсь, не туда ткнул для ответа.
Как удалить комментарий?
Как удалить комментарий?
Sign up to leave a comment.
Использование базы данных лога Mikrotik для пресечения брутфорса