|
Description |
This article describes how to work around an issue where web connections are not blocked as intended, and explains how to effectively block the established web connections when switching from different networks to FortiGate affiliated networks. |
|
Scope |
FortiGate. |
|
Solution |
At first, a user establishes a web connection while being on an untrusted network. Subsequently, the user transitions to FortiGate's secure network environment. The existing web connection remains functional even if the website is categorized as blocked within the FortiGate network's web filter profile. Ideally, the site should be blocked immediately upon the network transition, but the web connection persists unblocked, regardless of the network change. In this scenario, the user initially visited the website (www.fortinet.com) while connected to the (10.0.4.0/24) network. Subsequently, the user transitioned to the FortiGate protected network (192.168.1.0/24). Despite this change, users retained the ability to access the website without any interruption.
The Forward Traffic log displays that the sites with 'fortinet' in the URL header are blocked by the web profile.
The log may indicate a successful block action for the established web connection to www.fortinet.com, but this is a false positive report, as the website remains accessible despite the information recorded in the log.
In this case, the contents of the domain are retrieved from the apps.global.fortinet.com, which is hosted at the IP address 140.86.220.9.
Upon packet analysis, it was observed that the attempts to negotiate TLS version 1 were effectively blocked, consistent with what the log had indicated. Notably, reset packets in the TCP flags were detected from the server's end.
The Forward Traffic log displays that the sites with 'fortinet' in the URL header are blocked by the web profile.
The cause of this is certificate inspection used in the firewall policy to examine the exchange of hello messages at the beginning of an SSL handshake.
FortiGate validates the information in the SNI (Server Name Indication) field of the client's request against the information in the CN and SAN fields of the server's certificate.
In this scenario, content is fetched from SNI apps.global.fortinet.com. It is checked against the Common Name (CN) and Subject Alternative Name (SAN) fields in the server certificates. The outcome remains consistent whether it involves other SNIs like 'site.fortinet.com', 'www.fortinet.com' or 'apps.global.fortinet.com'. It fails to block the SNI associated with the SSL client request for the established web connection.
Browsers were able to negotiate a TLS version 1.2 connection using an alternative port within their TCP sockets due to browser support for ALPN h2. ALPN h2 stands for 'Application-Layer Protocol Negotiation' with 'HTTP/2.' It is a mechanism used in secure web connections to negotiate the use of the HTTP/2 protocol at the application layer. This enables faster and more efficient communication between web servers and browsers.
This means that, when packets flowed, the browser maintained a secure connection with the newer TLS version to the web server without any blockage from the web filter.
In this situation, an established web connection fetches the content from apps.global.fortinet.com (140.86.220.9). The intended web site can be blocked:
diagnose system session filter src 192.168.1.2 diagnose system session clear
 Flow-Based Mode Inspection (Default)
When Firewall policy is configured, by default, it is configured in Flow-Based Inspection Mode.
config firewall policy edit 1 set name "Web Filter - Block" set uuid ab4ef1f8-3a82-51ee-7514-c660af63f723 set srcintf "internal1" set dstintf "wan1" set action accept set srcaddr "192.168.1.2/32" set dstaddr "all" set schedule "always" set service "ALL" set utm-status enable set ssl-ssh-profile "certificate-inspection" set webfilter-profile "Block - *fortinet*" set logtraffic all set nat enable next end Flow-based inspection mode examines the packet as it passes through FortiGate, without any buffering. As each packet arrives, it is processed and forwarded without waiting for the complete file or web page.
Packets are analyzed and forwarded as they are received. Original traffic is not altered. See Flow mode inspection: default mode in the FortiGate cookbook. This decreases the probability of experiencing a timeout error.
In this scenario, the flow-based inspection is unable to process and analyze the SSL client request for the established web session, www.fortinet.com. As a result, it is not able to to block web traffic. The permanent solution to this issue is to configure the proxy mode inspection.
Proxy-Based Mode Inspection
When proxy-based inspection is enabled, FortiGate buffers traffic and examines it as a whole before determining an action. Because FortiGate examines the data as a whole, it can examine more points of data than it does when using flow-based inspection.
config firewall policy edit 1 set name "Web Filter - Block" set uuid ab4ef1f8-3a82-51ee-7514-c660af63f723 set srcintf "internal1" set dstintf "wan1" set action accept set srcaddr "192.168.1.2/32" set dstaddr "all" set schedule "always" set service "ALL" set utm-status enable set inspection-mode proxy set ssl-ssh-profile "certificate-inspection" set webfilter-profile "Block - *fortinet*" set logtraffic all set nat enable next end In TCP connections, the FortiGate proxy generates the SYN-ACK to the client, and completes the three-way handshake with the client, before creating a second, new connection to the server. The proxy analyzes the headers and may change the headers, such as the HTTP host and URL, for web filtering. If a security profile decides to block the connection, the proxy can send a replacement message to the client. This adds latency to the overall transmission speed.
Due to this, proxy-based inspection offers a higher level of thoroughness compared to flow-based inspection, resulting in reduced occurrences of false positives and false negatives.
A feature is available within the web filtering advanced proxy option settings to filter the cookies from web traffic.
Additionally, sessions that have proxy-based features configured are not offloaded to the network processor. Instead, the FortiGate CPU manages packet processing and inspection using both the IPS engine and the FortiOS proxy. In the context of SSL/TLS encryption and decryption, the FortiGate CPU can leverage the content processors if SSL deep inspection is configured
Consequently, proxy-based inspection modes inspect the packet before it establishes connection the web server. As a result, it was able to analyze every client request and effectively block the web pages upon the network switch.
 |
