Cisco ASA 8.2 — журналы 106015 (запретить) и 106100 (разрешить) для одного и того же пакета

Question

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

Answer 1

ACL оценивается до отслеживания соединения и оценки NAT (проверьте выходные данные packet-tracerмоделирования этого трафика), и поскольку трафик попадает под это правило, он регистрируется в соответствии с вашими указаниями в permit ip any any log.

Answer 2

Это ожидаемое поведение:

https://www.cisco.com/c/en/us/td/docs/security/asa/syslog/b_syslog/syslog-messages-101001-to-199021.html

Когда строка списка доступа имеет аргумент log, ожидается, что этот идентификатор сообщения может быть вызван из-за несинхронизированного пакета, достигшего ASA и оцененного списком доступа. Например, если на ASA получен пакет ACK (для которого в таблице подключений нет TCP-соединения), ASA может сгенерировать сообщение 106100, указывающее, что пакет был разрешен; однако позже пакет корректно отбрасывается из-за отсутствия соответствующего соединения.