FortiAnalyer Firewall Action Log 분석
The status of the session
It will generate a single log for a session. Always from the initiator to the responder (source is always the one that made the request - ie client), destination is always the responder (ie server). It doesn’t make a second log for reply traffic.
- deny : Session was denied
- accept : Allowed Forward session
- start : Session starts (log message was created when the session was created)
- dns : DNS query return error
- ip-conn : Failed connection attempts
- close : Local-traffic session allowed ( The session ended successfully with FIN ACK )
- timeout : Allowed session was timeout ( tcp handshake never finished (no syn-ack received))
- client-rst : Session reset by client
- server-rst : Session reset by server
Client or Server Reset means instead of a FIN packet, an RST packet is received, either from the initiator (client-rst) or responder (server-rst). This is an anomaly end of a session. Basically at some point the client or server starts rejecting the connection for some reason.
Fortigate Firewall Action : server-rst
Server-RST means the server abruptly or intentionally closed a TCP connection, not the Client.
If the Client closes the connection, it should show Client-RST.
Server-RST means that the traffic was allowed by the policy, but the end was "non-standard",
that is the session was ended by RST sent from server-side.
This could be noticed due to many reasons.
1) Client doesn't send any data for "N"-seconds and server closed the connection.
> Here the Client implies actual Client PC or FGT based on the config. There is a chance that MTU issues can sometimes cause packet drop and cause a server RST but this very rare.
2) In case of FGT Proxy (explicit or transparent) involved, if the traffic direction is UPLOAD (Client > Server), proxy buffering caused timeout with the server. This issue could be avoided by enabling comforting options to keep the session alive. For SMTP it is called "Splice" iirc.
3) An issue with SSL negotiation :
Between the Client > Server (if no proxy involved)
Between FGT > Server (If proxy involved, SSL deep inspection also can play a role here).
In case if the SSL failed to negotiate and the server choose to close the connection by RST, the log can show connection closed by Server.
If you only see the initial TCP handshake and then the final packets in the sniffer, that means the traffic is being offloaded. You can temporarily disable it to see the full session in captures:
config firewall policy
edit <policy-id>
set auto-asic-offload disable
end
Firewall Action vs Security Action
The blocking/allowing is done at a different layer. Firewall policy matching is done on source/destination interface/address, schedule (time of day), protocol (TCP/UDP/...), src/dst ports, optionally user identity. If the matching policy says DENY, the processing stops there and the packet is blocked.
If the policy says ACCEPT, the traffic is either allowed (no UTM), or sent for further UTM processing. UTM profiles will then look at actual payloads in the packets and decide whether to block or allow the traffic.
If you block at the policy level, the traffic flow will typically be just an unresponded SYN from client (no SYN-ACK or anything further). Blocking at the UTM level will see the TCP handshake finished, and then you'll see one or more packets with data, for as long as it takes for the UTM profile to identity that the traffic should be blocked. (undesired FQDN in a first HTTP GET request; blocked FQDN in ServerCertificate in TLS; some byte pattern in the payload identifying some XYZ protocol, etc.)
If you want to learn more how packets are processed, read this:
'Fortinet > Fortigate' 카테고리의 다른 글
Fortigate IP Range 객체 추가 CLI (0) | 2024.10.16 |
---|---|
Fortigate SNMP 설정, 서버 연동 방법 - FGT 방화벽 (1) | 2024.09.17 |
Fortigate CLI 기본 Commands - 시스템 확인, PING, HA, DHCP, SESSION, DEBUG (0) | 2024.09.17 |
Fortigate CLI Commands - DNS 설정 (0) | 2024.09.17 |
Fortigate Procedure for HA manual synchronization (HA 동기화 절차 및 트러블슈팅) (0) | 2024.09.17 |