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

[nkmz]

Мы используем Cisco AnyConnect VPN на ASA 5525-x.
Два дня назад мы обнаружили в журналах ASA нечто похожее на брутфорс-атаку: --- 6|31 мая 2021|08:35:34|725007|193.27.228.247|60734|||SSL-сессия с внешним клиентом:193.27.228.247/60734 к a.a.a.a/443 прерван
6|31 мая 2021|08:35:34|716039|||||Группа <DfltGrpPolicy> Пользователь <*****> IP <193.27.228.247> Аутентификация: отклонена, Тип сеанса: WebVPN.
6|31 мая 2021 г.|08:35:34|113015|||||Аутентификация пользователя AAA отклонена: причина = Пользователь не найден: локальная база данных: пользователь = *****: IP-адрес пользователя = 193.27.228.247 --- Есть ли способы защитить наше устройство?

[licensing]

Я также проверил ту же самую попытку хоста на нескольких своих устройствах. Мне удалось заблокировать этот трафик. Вот что я сделал: 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 Я не знаю, является ли это лучшим способом блокирования такого трафика, но именно так я остановил эти попытки брутфорса. Спасибо

[jfnk]

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

[jfnk]

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

[nkmz]

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

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"...

[iscinteianu]

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

[Da ICS16]

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

[Ken Stieers]

Если вы используете 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

[Da ICS16]

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

[Ken Stieers]

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