%20%D0%B8%20106100%20(%D1%80%D0%B0%D0%B7%D1%80%D0%B5%D1%88%D0%B8%D1%82%D1%8C)%20%D0%B4%D0%BB%D1%8F%20%D0%BE%D0%B4%D0%BD%D0%BE%D0%B3%D0%BE%20%D0%B8%20%D1%82%D0%BE%D0%B3%D0%BE%20%D0%B6%D0%B5%20%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%B0.png)
Я вижу трафик с многочисленных внутренних конечных точек, где конечная точка отправляет RST или FIN/ACK хосту в Интернете. Эти соединения связаны с прозрачным прокси, который не обрабатывает их должным образом. Вместо того, чтобы иметь с ними дело, он просто пересылает их в ASA. ASA никогда раньше не наблюдал эти соединения.
ASA (8.2) видит этот трафик и генерирует событие 106015 (нет соединения) и отклоняет трафик. Это именно то, чего я ожидаю. Однако ASA также регистрирует событие 106100, которое сообщает, что трафик разрешен. Есть ACE, который указывает "permit ip any any log".
На основании данных о трафике было подтверждено, что движение было запрещено и не разрешено.
Почему же тогда происходит событие 106100? Это полностью сбивает нас с толку, поскольку кажется, что ASA разрешила трафик, хотя на самом деле нет. Если ASA сбрасывает трафик из-за отсутствия существующего соединения, зачем ему вообще приближаться к ACL, не говоря уже о создании журнала разрешений?
Вот вопросы по журналам:
: %ASA-6-106015: Deny TCP (no connection) from 10.x.x.x/62938 to 216.x.x.x/80 flags FIN ACK on interface inside
: %ASA-6-106100: access-list inside permitted tcp inside/10.x.x.x(62938) -> outside/216.x.x.x(80) hit-cnt 1 first hit [0x62c4905, 0x0]
Временные метки двух событий идентичны.
Буду признателен за любые советы, спасибо.
Редактировать: Разъяснение
согласно этой статье Cisco о потоке пакетов.
http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/113396-asa-packet-flow-00.html
«Если поток пакетов не соответствует существующему соединению, то проверяется состояние TCP. Если это пакет SYN или пакет UDP, то счетчик соединений увеличивается на единицу, и пакет отправляется на проверку ACL. Если это не пакет SYN, то пакет отбрасывается, а событие регистрируется».
Исходя из описанного поведения, я все еще не уверен, почему я вижу журнал 106100, указывающий на то, что трафик разрешен.
решение1
ACL оценивается до отслеживания соединения и оценки NAT (проверьте выходные данные packet-tracer
моделирования этого трафика), и поскольку трафик попадает под это правило, он регистрируется в соответствии с вашими указаниями в permit ip any any log
.
решение2
Это ожидаемое поведение:
Когда строка списка доступа имеет аргумент log, ожидается, что этот идентификатор сообщения может быть вызван из-за несинхронизированного пакета, достигшего ASA и оцененного списком доступа. Например, если на ASA получен пакет ACK (для которого в таблице подключений нет TCP-соединения), ASA может сгенерировать сообщение 106100, указывающее, что пакет был разрешен; однако позже пакет корректно отбрасывается из-за отсутствия соответствующего соединения.