Protocol Signatures

[s_milidrag]

Kindly ask if someone can explain in more detail "Protocol Signature" option in https/http/dns/telnet/smtp ... service objects.

What is the difference in matching between https without protocol signature enable (default option) and with protocol signature enabled.

Thanks 

[PhoneBoy]

Without the protocol signature, the traffic would merely be accepted based on port number.
The protocol signature does a bit deeper inspection to validate it is HTTPS or whatever.
It's similar in principle to what App Control does, but these protocol signatures do not require using Application Control as they are done as part of the Firewall.

[Oliver_Fink]

And as far as I experienced at a migration from R77.30 to R80.30 protocol signatures may not be added to application groups. I am not amused. 😒 

[HeikoAnkenbrand]

Protocol signatures are used in part of PSL/PXL.

Packets may arrive out of order or may be legitimate retransmissions of packets that have not yet received an acknowledgment. In some cases a retransmission may also be a deliberate attempt to evade IPS detection by sending the malicious payload in the retransmission. Security Gateway ensures that only valid packets are allowed to proceed to destinations. It does this with Passive Streaming Library (PSL) technology.

If you set the protocol it will be analyzed by PSL/PXL to specify the protocol type such as http, ftp, imap, etc. 

More read here:

R80.x Security Gateway Architecture (Content Inspection)

[s_milidrag]

Thanks Heiko,

So recommendation is in inbound and outbound firewall rules to always use services (http, https, dns, smtp....) with protocol signature enabled ?

S.M.

[Timothy_Hall]

If the first packet of a new connection matches all other rule criteria and the destination port number of a service with "Protocol Signature" enabled, in order to determine if the rule matches, the connection attempt is now allowed to proceed through its TCP 3-way handshake and pass a few data packets.  Note that this occurs even though no rule has been conclusively matched yet.  The data packets are evaluated by the protocol parser and the protocol type determined (HTTP, FTP, IMAP, etc.); this process causes additional overhead in the firewall vs. attempting to just match against a service object that does not have "Protocol Signature" checked, which is simply a port number match against the first packet of a new connection with no need to let the connection initially proceed further. 

As the protocol has now been conclusively determined, the firewall looks at the protocol defined in the matched service object and if it is a match against what was detected in the connection that's great, all criteria in that particular rule have now been matched and whatever action specified in the rule is executed, usually it will be an Accept.

However if the protocol type does not match after all this, it is simply not a match against that particular rule and evaluation proceeds down the rule base looking for another rule match.  Generally one will not be found and the connection will be dropped and killed, even though it was initially allowed to proceed just far enough to determine the protocol.  This behavior will look strange to scanning tools like nmap and Nessus who will report that port as "open" even though there are additional restrictions being imposed on the connection such as protocol type, application, URL category etc.

From a rulebase lookup optimization perspective, it is beneficial to use service objects that do NOT have Protocol Signature selection selected in the first/Network layer in the case of ordered layers, then invoke applications or services with Protocol Signature set in the next layer which is typically the APCL/URLF ordered layer.  In the case of inline/unified layers use services without Protocol Signature set in the top/parent layer, then invoke Protocol Signatures/APCL/URLF/Content Awareness in the sub-rules/sub-layers of that parent rule.  Structuring rules like this allows the firewall to efficiently drop traffic based solely on the first packet of a connection and a straight port number match, with no need to let the connection proceed further for protocol evaluation (causing overhead) then ultimately dropping it.  This approach also tends to make auditors much happier because they won't mistakenly see large numbers of ports as "open" in their scan results.

Before anyone freaks out about this "letting the connection start" behavior, it is clearly documented right in the SmartConsole itself.  See attached screenshot.

[s_milidrag]

So if packet in rule base is not matched by service with protocol signature enabled it will not be analyzed by Content Inspection engine (PSL/PXL) ?