С одной стороны схема отличная, но с другой списки только пухнут и наступит время когда оборудование 100% ляжет. Да и до этого времени уже начнутся вопросики «чего все так медленно при том что на роутере никого», а ответ простой ОЧЕНЬ длинные листы.
На всякий случай, RB4011iGS влёгкую перенёс разбухание трёх чёрных списков до примерно 50000 адресов в каждом. Никакого особого увеличения нагрузки ЦП и замедления работы при этом не наблюдал. Это ж не циска какая-нибудь, которую NAT немедленно ставит на колени. Понятно, конечно, что приглядывать за списками надо, чтобы сильно не разрастались, но, чтобы забить ими память микротика до отказа, надо очень сильно постараться.
это если брутфорс будет, а если через уязвимость(RDP и прочее)? — То к этому моменту уже перевешивать ничего не надо будет.
Во-первых, какова вероятность этого исхода? Порт случайный, на подбор даётся три попытки с одного адреса, после чего он блокируется на неделю и подбирать с него ничего больше не получится.
Но сам факт потенциальной возможности такой атаки — вы осознаете и это хорошо, так как если не хотите через Port Knocking, то возможно со временем модернизируете свой метод и потом напишете свою статью на хабре.
В связи с практической сложностью подбора случайного номера порта, его проще определить путём анализа трафика удалённого клиента к защищаемому сервису. А при таком подходе что мой способ защиты, что port knocking совершенно равнозначны. Для преодоления моего надо узнать номер порта, для преодоления port knocking'а надо установить последовательность обращений к портам. А она всегда одна и та же, что позволяет атакующему успешно выполнить replay attack. Собственно говоря, последовательность port knocking'а тоже можно подобрать, особенно если блокирование подбиральщиков этой последовательности не предусмотрено. А оно таки принципиально не предусмотрено.
Во-вторых, защита от перебора и защита от удалённого использования уязвимостей в защищаемом сервисе — это две разные задачи. Ни port knocking, ни мой способ случайного порта и блокировки попыток его подбора от удалённого использования уязвимости на 100% не защищают. Для защиты от удалённого использования уязвимости помогает только своевременная установка исправлений безопасности и использование перед сервисом верификатора протокола и передаваемых клиентом параметров (от неизвестных 0day уязвимостей).
Но потенциально — методом осторожной атаки ваша защита обходится, если много одиночных сканов по портам с разных ip.
Потенциально после повторного появления попыток подбора паролей сервис перевешивается на другой случайный порт, и осторожный атакующий снова идёт лесом. И так раз в год. Портов 64К штук, широко известных примерно 11К, остаётся 53К случайных. С таким количеством портов дурить голову осторожному атакующему можно до тех пор, пока он не помрёт от старости.
Так что пока ваш метод: 1- сложнее, …
Проще. Ровно на один скрипт порткнокинга. На стороне микротика всё примерно так же.
2- затратнее по ресурсам(есть небольшой шанс полной остановки роутера), …
Для этого на hEX с его 256Мб памяти надо натравить какой-то совершенно неимоверный ботнет с сотнями тысяч проксей.
3 — риск обхода защиты довольно высокий причем довольно простым методом ведь пару тысяч прокси не проблема.
Какая пара тысяч? hEX, не напрягаясь, заблокировал не пару, а десять тысяч проксей.
PSK ключи IPSEC можно заменить на сертификаты, которые в случае чего, можно отозвать.
Ну вот отозвал ты сотруднику сертификат, а вокруг карантин. Как будешь доставлять ему новый? По всем хорошим практикам владелец сертификата должен предстать пред ясны очи офицера безопасности, дабы тот лично смог получить от будущего владельца распечатанный и собственноручно подписанный им запрос, убедиться в соответствии владельца ключам и передать сертификат из рук в руки. А вокруг режим ХЗ самоизоляции, сотрудник и офицер встретиться лично, без риска схватить либо вирус, либо штраф в 15000₽, не могут.
я часто вижу атаки сайта, там атака на перебор часто идет с группы адресов и часто даже с разных подсетей — то в основном чтобы обойти — один IP один порт просканирует и ваша защита не сработает.
Любителей сканировать порты, не входящие в список широко известных, можно банить, например, после третьей попытки подключения. У меня сделано вот так.
Все сервисы пересажены на случайные порты.
На неделю блокируется весь трафик с адресов, с которых была хотя бы одна попытка подключения к 22,25,80,81,110,143,135-139,443,445,3128,3389,8080,8081/tcp и к ещё некоторым другим широко известным портам потенциально уязвимых сервисов.
На неделю блокируется весь трафик после третьей попытки подключения к любому порту, по любому IP-протоколу. То есть, если адрес три раза засветился в правиле по умолчанию, которое блокирует весь неразрешённый входящий трафик из интернета, в течение установленного периода времени, то весь трафик с этого адреса тоже блокируется на неделю.
Адреса для блокирования автоматически вносятся в чёрный список, блокирование трафика осуществляется по этому чёрному списку.
Вначале я опасался, что чёрный список быстро исчерпает всю доступную память микротика, но он вырос примерно до 10000 адресов и на этом его рост остановился. Пока всего занято 50Мб памяти микротика и её дальнейший рост тоже остановился.
Меры были внедрены на двух площадках примерно год тому назад, попытки подбора пароля пропали полностью.
Из практики могу сказать, что боты ловят нестандартный порт от пары часов, до пары дней — это совершенно не повышает уровень безопасности.
Но если сервис на нестандартном порту, то можно сразу же блокировать на неделю все адреса, с которых пытаются подключиться к стандартному. Причём блокировать с них весь трафик вообще, а не только к конкретному порту и/или по определённому протоколу. А можно банить на неделю не только за попытку подключения к 3389/tcp, но и к другим широко известным портам.
Поддержка Windows 7 уже прекращена. В связи с этим, полагаю, у Микрософта нет совершенно никаких обязательств в плане оповещения клиентов об уязвимостях в этой операционной системе.
Есть статистика: насколько успешно блокировались попытки доступа?
Успешно настолько, что секция от fail2ban'а просто пропала из отчёта logwatch.
Много было блокированных IP?
Прямо сейчас забаненых на неделю на одной площадке 3673, на другой — 6219. Бан происходит сразу же при попытке обращения к портам 21-23, 80, 443, 1900, 3389, 4899, 8728, 8729, 8291, 81, 135-138, 445, 5900-5999, 8080, 8081/tcp и 123, 135-137, 514/udp
Существует простой способ отсеять любителей подбора паролей без использования fail2ban.
Суть способа заключается в переносе защищаемых сервисов на какие-либо случайные порты, не входящие в перечень широко известных портов быстрого сканирования Nmap'а (флаг -F). После этого задача сводится к блокированию любителей сканировать порты.
В свою очередь, блокирование любителей сканировать порты может быть реализовано, например, с помощью МСЭ, который умеет вести динамические списки IP-адресов, фильтровать по этим спискам и вносить в них IP-адреса из правил фильтрации на определённое время. Последнее критически важно, потому что без ограничения по времени способ будет работать только до исчерпания памяти МСЭ.
Способ блокирования сканирующих заключается в занесении IP-адресов, с которых выполнялись обращения к широко известным портам к адресам защищаемых МСЭ сетей, в специальный динамический список адресов с последующим блокированием любого трафика со всех адресов из этого списка на определённое длительное время. Выполняется это с помощью двух правил. Первое правило располагается предпоследним в списке правил фильтрации перед правилами по умолчанию и вносит IP-адреса всех, попытавшихся обратиться к портам из списка широко известных портов, в динамический список адресов, например, на неделю. Второе правило располагается непосредственно перед блоком правил, разрешающих соединения извне с защищаемыми сервисами, заранее перенесёнными на случайные порты, и блокирует любой трафик с IP-адресов из вышеупомянутого динамического списка.
С целью снижения объёма памяти, расходуемой МСЭ на динамический список, его можно разделить на два. Первый список использовать для запоминания IP-адреса после первой попытки сканирования, второй — для всех последующих попыток. Первую попытку запоминать, скажем, на 30 минут, а вторую — уже на неделю. Отличить вторую и последующие попытки сканирования от первой можно по наличию IP-адреса в первом списке. Блокировать, естественно, следует только тех, чьи IP-адреса попали уже во второй список.
Описанный способ был успешно реализован мной с помощью маршрутизатора фирмы Микротик.
Mail Merge, она же «Почтовая рассылка» в Microsoft Office, Libre Office и прочих офисных пакетах представляет собой инструмент для организации массовых рассылок, позволяя автоматически сформировать кучу писем, различающихся только обращением по конкретному имени адресата письма, которое берётся из некоторого источника: электронной таблицы или базы данных. Письма генерируются из шаблона, который называется «Документ слияния», представляющего собой документ с внедрёнными полями, в которые подставляются изменяемые значения, извлекаемые из источника данных. На каждую запись источника данных из документа слияния создаётся один результирующий документ.
Фактически Mail Merge представляет собой частный случай генератора отчётов по базе данных. Огромный плюс этого инструмента заключается в том, что его использование не требует вообще никакого программирования. Надо только взять кусок заливаемого конфига, накидать в него изменяемых полей вроде конкретных адресов, имён интерфейсов и прочих различающихся частей, выбрать записи для конкретных устройств в источнике данных, и уже можно заливать эти куски в оборудование методом copy/paste.
Здесь же кроме генерации конфигов решается задача заливки конфигов на устройства.
Это да, Mail Merge заливать ничего никуда не будет, оно только для генерации однотипных кусков конфигов. Но оно позволяет решить эту задачу гораздо быстрее и удобнее написания и отладки всяких скриптов, да ещё и с промежуточной выгрузкой данных об оборудовании в yaml-файлы.
И устройства тут не однотипные. Описаны устройства двух типов. Еще хуавеи есть у меня в хозяйстве.
Все устройства не обязаны быть однотипными. В этом смысле Mail Merge ничем не отличается от любого другого генератора отчётов по базе данных и шаблону. Понятно, что для каждого типа устройств нужен свой документ слияния (шаблон), если у них разные CLI.
Когда передо мной встала задача составления конфигов для однотипных устройств, я тоже начал с написания очередной программы генерации отчётов по шаблонам. Разве что для её разработки выбрал не питон а перл. А потом, по мере роста количества того самого однотипного оборудования, мне надоело вести его базу в текстовом файле, я перенёс её в электронную таблицу LibreOffice, а для составления конфигов стал пользоваться Mail Merge.
На всякий случай, RB4011iGS влёгкую перенёс разбухание трёх чёрных списков до примерно 50000 адресов в каждом. Никакого особого увеличения нагрузки ЦП и замедления работы при этом не наблюдал. Это ж не циска какая-нибудь, которую NAT немедленно ставит на колени. Понятно, конечно, что приглядывать за списками надо, чтобы сильно не разрастались, но, чтобы забить ими память микротика до отказа, надо очень сильно постараться.
Во-вторых, защита от перебора и защита от удалённого использования уязвимостей в защищаемом сервисе — это две разные задачи. Ни port knocking, ни мой способ случайного порта и блокировки попыток его подбора от удалённого использования уязвимости на 100% не защищают. Для защиты от удалённого использования уязвимости помогает только своевременная установка исправлений безопасности и использование перед сервисом верификатора протокола и передаваемых клиентом параметров (от неизвестных 0day уязвимостей).
Потенциально после повторного появления попыток подбора паролей сервис перевешивается на другой случайный порт, и осторожный атакующий снова идёт лесом. И так раз в год. Портов 64К штук, широко известных примерно 11К, остаётся 53К случайных. С таким количеством портов дурить голову осторожному атакующему можно до тех пор, пока он не помрёт от старости.
Проще. Ровно на один скрипт порткнокинга. На стороне микротика всё примерно так же.
Для этого на hEX с его 256Мб памяти надо натравить какой-то совершенно неимоверный ботнет с сотнями тысяч проксей.
Какая пара тысяч? hEX, не напрягаясь, заблокировал не пару, а десять тысяч проксей.
Ну вот отозвал ты сотруднику сертификат, а вокруг карантин. Как будешь доставлять ему новый? По всем хорошим практикам владелец сертификата должен предстать пред ясны очи офицера безопасности, дабы тот лично смог получить от будущего владельца распечатанный и собственноручно подписанный им запрос, убедиться в соответствии владельца ключам и передать сертификат из рук в руки. А вокруг режим
ХЗсамоизоляции, сотрудник и офицер встретиться лично, без риска схватить либо вирус, либо штраф в 15000₽, не могут.Любителей сканировать порты, не входящие в список широко известных, можно банить, например, после третьей попытки подключения. У меня сделано вот так.
Вначале я опасался, что чёрный список быстро исчерпает всю доступную память микротика, но он вырос примерно до 10000 адресов и на этом его рост остановился. Пока всего занято 50Мб памяти микротика и её дальнейший рост тоже остановился.
Меры были внедрены на двух площадках примерно год тому назад, попытки подбора пароля пропали полностью.
Но если сервис на нестандартном порту, то можно сразу же блокировать на неделю все адреса, с которых пытаются подключиться к стандартному. Причём блокировать с них весь трафик вообще, а не только к конкретному порту и/или по определённому протоколу. А можно банить на неделю не только за попытку подключения к 3389/tcp, но и к другим широко известным портам.
Совершенно верно.
Да. Просто лень лишний раз раскладку переключать.
Успешно настолько, что секция от fail2ban'а просто пропала из отчёта logwatch.
Прямо сейчас забаненых на неделю на одной площадке 3673, на другой — 6219. Бан происходит сразу же при попытке обращения к портам 21-23, 80, 443, 1900, 3389, 4899, 8728, 8729, 8291, 81, 135-138, 445, 5900-5999, 8080, 8081/tcp и 123, 135-137, 514/udp
Суть способа заключается в переносе защищаемых сервисов на какие-либо случайные порты, не входящие в перечень широко известных портов быстрого сканирования Nmap'а (флаг -F). После этого задача сводится к блокированию любителей сканировать порты.
В свою очередь, блокирование любителей сканировать порты может быть реализовано, например, с помощью МСЭ, который умеет вести динамические списки IP-адресов, фильтровать по этим спискам и вносить в них IP-адреса из правил фильтрации на определённое время. Последнее критически важно, потому что без ограничения по времени способ будет работать только до исчерпания памяти МСЭ.
Способ блокирования сканирующих заключается в занесении IP-адресов, с которых выполнялись обращения к широко известным портам к адресам защищаемых МСЭ сетей, в специальный динамический список адресов с последующим блокированием любого трафика со всех адресов из этого списка на определённое длительное время. Выполняется это с помощью двух правил. Первое правило располагается предпоследним в списке правил фильтрации перед правилами по умолчанию и вносит IP-адреса всех, попытавшихся обратиться к портам из списка широко известных портов, в динамический список адресов, например, на неделю. Второе правило располагается непосредственно перед блоком правил, разрешающих соединения извне с защищаемыми сервисами, заранее перенесёнными на случайные порты, и блокирует любой трафик с IP-адресов из вышеупомянутого динамического списка.
С целью снижения объёма памяти, расходуемой МСЭ на динамический список, его можно разделить на два. Первый список использовать для запоминания IP-адреса после первой попытки сканирования, второй — для всех последующих попыток. Первую попытку запоминать, скажем, на 30 минут, а вторую — уже на неделю. Отличить вторую и последующие попытки сканирования от первой можно по наличию IP-адреса в первом списке. Блокировать, естественно, следует только тех, чьи IP-адреса попали уже во второй список.
Описанный способ был успешно реализован мной с помощью маршрутизатора фирмы Микротик.
Mail Merge, она же «Почтовая рассылка» в Microsoft Office, Libre Office и прочих офисных пакетах представляет собой инструмент для организации массовых рассылок, позволяя автоматически сформировать кучу писем, различающихся только обращением по конкретному имени адресата письма, которое берётся из некоторого источника: электронной таблицы или базы данных. Письма генерируются из шаблона, который называется «Документ слияния», представляющего собой документ с внедрёнными полями, в которые подставляются изменяемые значения, извлекаемые из источника данных. На каждую запись источника данных из документа слияния создаётся один результирующий документ.
Фактически Mail Merge представляет собой частный случай генератора отчётов по базе данных. Огромный плюс этого инструмента заключается в том, что его использование не требует вообще никакого программирования. Надо только взять кусок заливаемого конфига, накидать в него изменяемых полей вроде конкретных адресов, имён интерфейсов и прочих различающихся частей, выбрать записи для конкретных устройств в источнике данных, и уже можно заливать эти куски в оборудование методом copy/paste.
Это да, Mail Merge заливать ничего никуда не будет, оно только для генерации однотипных кусков конфигов. Но оно позволяет решить эту задачу гораздо быстрее и удобнее написания и отладки всяких скриптов, да ещё и с промежуточной выгрузкой данных об оборудовании в yaml-файлы.
Все устройства не обязаны быть однотипными. В этом смысле Mail Merge ничем не отличается от любого другого генератора отчётов по базе данных и шаблону. Понятно, что для каждого типа устройств нужен свой документ слияния (шаблон), если у них разные CLI.