[Information]/[Fortinet] Fortigate

[Fortinet] FortiAnalyer Log 분석 - Firewall Action

starterr 2024. 8. 19. 16:50
반응형

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.

 

 

https://docs.fortinet.com/document/fortigate/7.4.1/fortios-log-message-reference/2/2-log-id-traffic-allow#aanchor556

 

2 - LOG_ID_TRAFFIC_ALLOW | FortiOS Log Message Reference

 

docs.fortinet.com

 

 

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:

https://docs.fortinet.com/document/fortigate/6.4.0/parallel-path-processing-life-of-a-packet/466137/introduction

 

Introduction | Parallel Path Processing (Life of a Packet)

 

docs.fortinet.com

 

 

[Fortinet/TS] Procedure for HA manual synchronization (HA 동기화 절차 및 트러블슈팅)

 

[Fortinet/TS] Procedure for HA manual synchronization (HA 동기화 절차 및 트러블슈팅)

DescriptionThis article describes the methods used to force the synchronization on the cluster before proceeding to rebuild the HA.ScopeHigh Availability synchronization.SolutionFor this procedure, it is recommended to have access to all units through SSH

infoofit.tistory.com

 

[Fortinet] Fortigate CLI Commands - DNS 설정

 

[Fortinet] Fortigate CLI Commands - DNS 설정

DNS CLI DNS settings can be configured with the following CLI command:config system dns set primary set secondary set dns-over-tls {enable | disable | enforce} set ssl-certificate set domain set ip6-primary set ip6-secondary set timeout set retry set dns-

infoofit.tistory.com

 

반응형