%20%EB%B0%8F%20106100(%ED%97%88%EC%9A%A9)%20%EB%A1%9C%EA%B7%B8.png)
RST 또는 FIN/ACK가 끝점에서 인터넷의 호스트로 전송되는 수많은 내부 끝점에서 트래픽이 표시됩니다. 이러한 연결은 이를 제대로 처리하지 않는 투명 프록시와 관련되어 있습니다. 이를 처리하는 대신 단순히 ASA로 전달합니다. ASA는 이전에 이러한 연결을 관찰한 적이 없습니다.
ASA(8.2)는 이 트래픽을 확인하고 106015 이벤트(연결 없음)를 생성하고 트래픽을 거부합니다. 이것이 바로 제가 기대하는 것입니다. 그러나 ASA는 트래픽이 허용됨을 나타내는 106100 이벤트도 기록합니다. "모든 로그에 대한 IP 허용"이라는 ACE가 있습니다.
트래픽 캡쳐 결과를 토대로 트래픽이 거부되어 허용되지 않는 것으로 확인되었습니다.
그렇다면 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 패킷인 경우 연결 카운터가 1만큼 증가하고 ACL 확인을 위해 패킷이 전송됩니다. SYN 패킷이 있으면 패킷이 삭제되고 이벤트가 기록됩니다."
이 설명된 동작을 토대로 트래픽이 허용되었음을 나타내는 106100 로그가 표시되는 이유가 여전히 확실하지 않습니다.
답변1
ACL은 연결 추적 및 NAT 평가(이 트래픽 시뮬레이션 결과 확인 packet-tracer) 전에 평가되고 있으며 트래픽이 해당 규칙에 도달하기 때문에 에서 지시한 대로 기록됩니다 permit ip any any log.
답변2
이는 예상되는 동작입니다.
액세스 목록 줄에 로그 인수가 있으면 비동기화된 패킷이 ASA에 도달하고 액세스 목록에서 평가되기 때문에 이 메시지 ID가 트리거될 수 있습니다. 예를 들어 ASA에서 ACK 패킷이 수신되면(연결 테이블에 TCP 연결이 없음) ASA는 패킷이 허용되었음을 나타내는 메시지 106100을 생성할 수 있습니다. 그러나 일치하는 연결이 없기 때문에 나중에 패킷이 올바르게 삭제됩니다.