По поводу Packet Capture. Скорость записи вряд ли можно обозначить — зависит от многих факторов: какая функциональность включена на устройстве, какой тип трафика, размер пакетов и т. д. Утилиту нужно использовать с осторожностью — при большом трафике устройство может «просесть» по производительности. Максимальный размер захвата — 2000 пакетов. Формат — .cap.
Утилита Packet Capture не предназначается для хранения информации о доступе в Интернет. Она полезна для траблшутинга локальной проблемы: доходит ли трафик вообще до устройства? проходит ли трафик устройство (т. е. появляется ли и на внутреннем, и на внешнем интерфейсе)? и т. д.
По поводу статистики по доступу в Инет. На более старших моделях (6330 и далее) данные могут храниться локально на устройстве. Для этого нужно установить дополнительный HDD. Сколько хранятся по времени — не могу сказать.
Для младших устройств (6310, 6320) предлагается использовать систему мониторинга и управления LogCenter, модуль eSight. Само собой, никто не мешает использовать этот мониторинг и для старших моделей. С LogCenter не знакомились, по времени хранения пока ответить не готов.
Прозрачная — либо клиент на сервер, либо зеркалировать LDAP-трафик на выделенный порт Huawei. Как я понял. На практике пока не проверял.
Спасибо за идею с alias!
Главная идея NGFW — глубокий анализ пакетов (DPI) c помощью встроенного IPS и разграничение доступа на уровне приложений (Application Control)
.
Как-то всё в одну кучу. DPI может иметь и обычный файрвол (не обязательно NGFW, та же инспекция на ASA, на маршрутизаторах). IPS — тоже не обязательный атрибут NGFW. Также, DPI не всегда равно IPS.
Я для себя всегда считал, что NGFW — это когда к обычному FireWall добавлена фильтрация по категориям сайтов, репутациям сайтов и по приложениям (AVC). Также NGFW — наличие интеграции с корпоративным каталогом пользователей, чтобы можно было создавать правила по именам и группам.
SPF и DKIM не помогают?
Потом, никто не отменяет проверку тела письма. Это уже офтоп относительно материала статьи, но всё же… Например, у ESA есть возможность проверять ссылки в письме. URL проверяются по тем же базам, что и на web-proxy сервере WSA. Если URL ведёт на вредоносный сайт, можно карантинить такие письма, добавлять предупреждение в заголовок письма (если не ошибаюсь) или «портить»/вырезать URL из тела письма.
Всё просто.
Каждому пользователю по 200 портов. Всего пользователей максимум 199.
200 портов умножить на 199 пользователей = 39800 портов
39800 портов + 2024 (начальный порт) — 1 (так как порт 2024 тоже используется) = 41823 (конечный порт)
Согласен, 5ая ветка стабильнее. 6.0 — не внедряли, не решились. 6.1 — есть внедрения, в принципе нормально. Была пара моментов, но не критично. Остались вопросы с активной аутентификацией. 6.2 — пока не внедряли/не обновлялись.
Обычно пинги от Anyconnect клиентов проходят без проблем даже если не подменять шлюз (использовать split tunneling). Почему у вас не работает — сложно сказать. Может быть пришлёте show runn в ЛС?
Кстати, к ассиметричному хождению может приводить правило NAT exception. Если в правиле чётко указаны ingress и egress интерфейсы, то для untranslated пакета egress интерфейс будет выбран в соответствии с правилом NAT, даже если маршрут смотрит на другой интерфейс. Если мы хотим этого избежать, в правиле NAT нужно использовать опцию route-lookup
sysopt connection permit-vpn включён по умолчанию. В show runn не отображается, но можно проверить в show runn all. Это опция позволяет обходить списки доступа для VPN-payload трафика. Если эту опцию убрать, то придётся в acl на внешнем интерфейсе в явном виде прописывать permit для удалённых VPN подсетей. Это полезно, если мы подключаем по VPN недоверенную сеть (например, какого-нибудь контрагента) и хотим оградиться от неё правилами файрвола.
По поводу ICMP появилась не плохая идея. Нет ли у вас ассиметричной маршрутизации? Может быть ICMP echo отправляются в сторону LAN через один интерфейс, а возвращаются через другой?
Используется ли у вас выделенный Management-интерфейс на ASA?
Про HSRP очень странно. Ведь у виртуального адреса mac-адрес должен быть формата 00-00-0c-07-ac-xx… Можно как-то проверить mac-таблицы на коммутаторах? Откуда берутся mac-адреса 70ca.xxe5.dd4a и 70ca.xxe5.d16a??
Про ICMP, пока задам банальные вопросы: включены ли inspect icmp, inspect icmp error и sysopt connection permit-vpn?
Добрый день. По первому вопросу пока нет идей, подумаем, если что-то появится — сообщим. Объясните, пожалуйста, поподробнее: так у вас VRRP или HSRP? Адрес 10.x.181.4 — это что за адрес? Виртуальный группы VRRP/HSRP или адрес физического интерфейса устройства?
По второму вопросу весьма странная ситуация. Получается, сервер 10.xx.111.15 шлёт DNS ответ клиенту 10.xx.32.52 (UDP порт 53 -> на порт 54874). На это клиент 10.xx.32.52 отвечает ICMP error message типа icmp port unreachable. Я думаю, нужно искать саму причину, почему DNS-сервер шлёт ответ клиенту, а клиент говорит, что ему это не нужно. Я бы посмотрел с помощью packet capture на ASA всё общение между 10.xx.32.52 и 10.xx.111.15 по порту udp 53…
Теоретически, да, можно резать заголовок. Но у меня есть чёткое подозрение, что в большинстве случаев это банально не требуется. Локальный CA перебивает политику HPKP и на этом всё заканчивается. На практике при внедрении FirePOWER мы пробовали включать дешифрацию, проблем с HPKP не встречали.
Утилита Packet Capture не предназначается для хранения информации о доступе в Интернет. Она полезна для траблшутинга локальной проблемы: доходит ли трафик вообще до устройства? проходит ли трафик устройство (т. е. появляется ли и на внутреннем, и на внешнем интерфейсе)? и т. д.
Для младших устройств (6310, 6320) предлагается использовать систему мониторинга и управления LogCenter, модуль eSight. Само собой, никто не мешает использовать этот мониторинг и для старших моделей. С LogCenter не знакомились, по времени хранения пока ответить не готов.
SecurID поддерживается, можно аутентифицировать по токенам.
Huawei_Russia
Спасибо за идею с alias!
.
Как-то всё в одну кучу. DPI может иметь и обычный файрвол (не обязательно NGFW, та же инспекция на ASA, на маршрутизаторах). IPS — тоже не обязательный атрибут NGFW. Также, DPI не всегда равно IPS.
Я для себя всегда считал, что NGFW — это когда к обычному FireWall добавлена фильтрация по категориям сайтов, репутациям сайтов и по приложениям (AVC). Также NGFW — наличие интеграции с корпоративным каталогом пользователей, чтобы можно было создавать правила по именам и группам.
Потом, никто не отменяет проверку тела письма. Это уже офтоп относительно материала статьи, но всё же… Например, у ESA есть возможность проверять ссылки в письме. URL проверяются по тем же базам, что и на web-proxy сервере WSA. Если URL ведёт на вредоносный сайт, можно карантинить такие письма, добавлять предупреждение в заголовок письма (если не ошибаюсь) или «портить»/вырезать URL из тела письма.
Каждому пользователю по 200 портов. Всего пользователей максимум 199.
200 портов умножить на 199 пользователей = 39800 портов
39800 портов + 2024 (начальный порт) — 1 (так как порт 2024 тоже используется) = 41823 (конечный порт)
По поводу ICMP появилась не плохая идея. Нет ли у вас ассиметричной маршрутизации? Может быть ICMP echo отправляются в сторону LAN через один интерфейс, а возвращаются через другой?
Используется ли у вас выделенный Management-интерфейс на ASA?
Про ICMP, пока задам банальные вопросы: включены ли inspect icmp, inspect icmp error и sysopt connection permit-vpn?
По второму вопросу весьма странная ситуация. Получается, сервер 10.xx.111.15 шлёт DNS ответ клиенту 10.xx.32.52 (UDP порт 53 -> на порт 54874). На это клиент 10.xx.32.52 отвечает ICMP error message типа icmp port unreachable. Я думаю, нужно искать саму причину, почему DNS-сервер шлёт ответ клиенту, а клиент говорит, что ему это не нужно. Я бы посмотрел с помощью packet capture на ASA всё общение между 10.xx.32.52 и 10.xx.111.15 по порту udp 53…