Are IoC feeds processed before Access Control policy?

[Danny]

Our access control policy blocks specific countries in the source column of rule #1 (Geo block).
We also have IoC Feeds for that countries' IP addresses in place.

Our firewall log shows:

Rule #1 (Geo Block) isn't listed within 'Matched Rules', just IPS and Threat Prevention:

Usually Access Control gets processed before Threat Prevention while it absolutely makes sense to block blacklisted IP addresses before Access Control. Since IoC Feeds are configured and installed with the Threat Prevention policy I'm trying to understand how IoC feeds work before Access Control.

[Timothy_Hall]

You've asked a very good question as this runs counter to my understanding of the Order of Operations as well. After some digging I think I figured it out.

From sk103154: How to block traffic coming from known malicious IP addresses which was the precursor to the newer Custom feeds:

The traffic is blocked using the Anti-DoS feature (named "Rate Limiting for DoS mitigation" in R77.X Security Gateway Technical Administration Guide - refer to sk112454 - How to configure Rate Limiting rules for DoS Mitigation).

The DoS mitigation features are implemented directly by SecureXL/sim and can match IP addresses to block before the packet even reaches the Access Control policy in the F2F path, I assume they are doing this feeds enforcement alongside the anti-spoofing enforcement inside SecureXL which would be pretty easy to add on.  It looks to me like when they introduced the Custom Feeds feature they retained the SecureXL-based enforcement mechanism from the older "drop malicious IP" feature.

[Peter_Elmer]

Hello @Danny , @Timothy_Hall ,

let me share what I found:

Where in packet processing is the enforcement of IP addresses listed in IoC feeds taking place?

ATRG for Anti-Virus and AntiBot documents that ‘IP reputation’ engine is ignited by CMI Loader. CMI Loader is taking elements from Protocol Parsers (see IPS ATRG for details sk95193). Reading the text below the diagram of sk92264 you see that ‘on new connection arrival’ we check IP address against ‘IP Reputation’.

Extract from sk92264

"On new connection arrival, in the first packet, before the Security rulebase:
- Malware rulebase matches a profile for Anti-Bot and Anti-Virus
- IP is classified by reputation IP address"

Conclusion

If you enable Anti-Virus and AntiBot you enable IP reputation verification software instance. As stated above ‘on new connection arrival’ this engine is called FIRST – BEFORE check for HTTPS Inspection and/or Access Control and/or Threat Prevention rule base. This is to save cycles on rule base processing in case the traffic is send from a source listed in the IP reputation IoC list.

best regards

pelmer

[Timothy_Hall]

Confirms more or less what I suspected earlier in the thread, thanks Peter!

[Peter_Elmer]

Hello @Timothy_Hall ,

this was my intention 😊 I wanted to back up your statement with the sk 

greetings from Milano

pelmer

[Timothy_Hall]

One more question @Peter_Elmer: Is this early IP reputation IoC list check performed in sim/SecureXL/SND or in a Firewall Worker/instance/fwk?  I would suspect the latter.

[Peter_Elmer]

Hello @Timothy_Hall ,

it is my understanding that only capabilities documented in sk112454 are integrated in SecureXL when looking at the two flow diagrams documented in the sk. 

-pelmer