Брутфорс-атака на ASA webvpn

Reply to Брутфорс-атака на ASA webvpn on Mon, 02 Mar 2026 21:16:48 GMT

Ken Stieers — Mon, 02 Mar 2026 21:16:48 GMT

Обе ссылки, которые я разместил, содержат разделы, которые также применимы к FTD. Если вы используете AD в качестве окончательного источника входа, то при попытке входа большего количества пользователей, чем разрешено, они будут заблокированы. Лучший способ укрепить FTD — использовать групповой URL и переключить профиль подключения DefaultWEBVPNGroup на НЕ использовать AD.

Reply to Брутфорс-атака на ASA webvpn on Mon, 02 Mar 2026 21:16:47 GMT

Da ICS16 — Mon, 02 Mar 2026 21:16:47 GMT

Здравствуйте
[, @Ken Stieers]
. Мы используем FTD. Можно ли предотвратить блокировку AD? Если да, пожалуйста, поделитесь своими рекомендациями и расскажите, как это сделать. С уважением.

Reply to Брутфорс-атака на ASA webvpn on Mon, 02 Mar 2026 21:16:46 GMT

Ken Stieers — Mon, 02 Mar 2026 21:16:46 GMT

Если вы используете ASA, вам необходимо обновить версию до последней.
Новые версии имеют функции, которые могут блокировать IP-адреса на основе неудачных попыток входа.
Вам нужно будет настроить их в соответствии с настройками вашего AD... если AD блокирует пользователя после 3 неудачных попыток, а ASA блокирует IP-адрес после 10 попыток, у вас всегда будут заблокированные пользователи... поэтому оба этих числа необходимо настроить в соответствии с тем, что вам удобно.
https://www.cisco.com/c/en/us/support/docs/security/secure-firewall-asa/222315-configure-threat-detection-services-for.html
Вышеуказанное работает только в том случае, если попытки входа в систему происходят с одних и тех же IP-адресов... если они используют несколько разных IP-адресов и распределены по времени, эти правила могут не сработать.
Вы также можете рассмотреть другие варианты усиления безопасности, например, перемещение пользователей в групповой URL. См. раздел «Конфигурация ASA» на этой странице:
https://www.cisco.com/c/en/us/support/docs/security/secure-client/221880-implement-hardening-measures-for-secure.html

Reply to Брутфорс-атака на ASA webvpn on Mon, 02 Mar 2026 21:16:45 GMT

Da ICS16 — Mon, 02 Mar 2026 21:16:45 GMT

Как предотвратить блокировку пользователя AD при брутфорсе пользователя через VPN? Спасибо.

Reply to Брутфорс-атака на ASA webvpn on Mon, 02 Mar 2026 21:16:44 GMT

iscinteianu — Mon, 02 Mar 2026 21:16:44 GMT

Мы обнаружили аналогичную попытку с того же IP-адреса: 193.27.228.247. Мы применили другой подход, используя uRPF для блокировки пакетов, исходящих с этого IP-адреса. Мы добавили статический маршрут через внутренний интерфейс к хосту 193.27.228.247, чтобы при поступлении пакета на внешний интерфейс URPF сравнивал исходный IP-адрес с таблицей маршрутизации и видел, что маршрут для этого IP проходит через другой интерфейс (внутренний). В связи с этим ASA отбрасывает пакет как поддельный. Ионут

Reply to Брутфорс-атака на ASA webvpn on Mon, 02 Mar 2026 21:16:43 GMT

nkmz — Mon, 02 Mar 2026 21:16:43 GMT

Мы успешно заблокировали трафик брутфорса:

object-group network brute_force
network-object host 193.27.228.247 access-list brute_force_attack extended deny ip object-group brute_force any access-group brute_force_attack in interface outside
control-plane--- Вы можете просмотреть/добавить/отредактировать это правило доступа к управлению в ASDM:
Конфигурация> Управление устройством> Правила доступа к управлению В журналах:

4 июня 2021 г. 11:05:47 106023 193.27.228.247 56816 a.a.a.a 443 Deny tcp src outside:193.27.228.247/56816 dst identity: a.a.a.a/443 by access-group "brute_force_attack"...

Reply to Брутфорс-атака на ASA webvpn on Mon, 02 Mar 2026 21:16:42 GMT

jfnk — Mon, 02 Mar 2026 21:16:42 GMT

Вот что я читал:
CLI Book 2: Руководство по настройке CLI брандмауэра Cisco ASA Series, 9.6 — Правила доступа [брандмауэры Cisco ASA 5500-X Series] — Cisco Правила доступа к управлению Вы можете настроить правила доступа, которые контролируют трафик управления, предназначенный для ASA. Правила контроля доступа для трафика управления к устройству (определяемые такими командами, как
http
,
ssh
или
telnet
) имеют более высокий приоритет, чем правило доступа к управлению, применяемое с опцией
control-plane
. Поэтому такой разрешенный трафик управления будет пропускаться, даже если он явно запрещен ACL к устройству. В отличие от обычных правил доступа, в конце набора правил управления для интерфейса нет неявного запрета. Вместо этого любое соединение, которое не соответствует правилу доступа к управлению, оценивается с помощью обычных правил контроля доступа.

Reply to Брутфорс-атака на ASA webvpn on Mon, 02 Mar 2026 21:16:41 GMT

jfnk — Mon, 02 Mar 2026 21:16:41 GMT

Вчера меня предупредили об этом, и я быстро создал аналогичный список доступа. Однако, когда я немного больше почитал об этом, я обнаружил, что списки доступа контрольной плоскости не имеют подразумеваемого правила запрета, поэтому «permit ip any any» не нужен. Фактически, это может (хотя я не уверен на 100%) непреднамеренно привести к предоставлению более широкого доступа для управления. Чтобы быть уверенным, я вернулся и удалил эту строку. Это по-прежнему работало (т. е. блокировало адрес 193.27.228.247, но позволяло другим устанавливать VPN-соединения).

Reply to Брутфорс-атака на ASA webvpn on Mon, 02 Mar 2026 21:16:40 GMT

licensing — Mon, 02 Mar 2026 21:16:40 GMT

Я также проверил ту же самую попытку хоста на нескольких своих устройствах. Мне удалось заблокировать этот трафик. Вот что я сделал: object-group network BLOCKED-NETWORKS network-object host 193.27.228.247 access-list anyconnect_deny extended deny ip object-group BLOCKED-NETWORKS any access-list anyconnect_deny extended permit ip any any access-group anyconnect_deny in interface outside control-plane Я не знаю, является ли это лучшим способом блокирования такого трафика, но именно так я остановил эти попытки брутфорса. Спасибо