Create a Post
Showing results for 
Search instead for 
Did you mean: 

How to completely exclude some specific traffic from being checked

Hello community,

Our internal Systems performing periodic vulnerability scanning are heavily impacting our corporate Firewall.

A part from building Policy Rules where this traffic is first handled on the top, is there a way to completely exclude this traffic from being checked by the Firewall Blade, and partially trasforming the Gateway for some traffic in just a Router? If yes, what is the way? Would it be by creating custom "Implied Rules"?

I found the SKs related to the modification of the file user_def, SK 30919, but the Syntax and Examples are not much clear to me. Also the SK 92281 about the Location of the file "implied_rules.def", does not mention how to create custom "implied rules".

Do you have any hints or experience to share?



0 Kudos
3 Replies

I don't see how Implied rules would help you, if a usual rule cannot help. These are the same rules, but just "implied", not explicitly configured.

Implied rules - Rules that are based on settings in the Global Properties menu

Then you need to check that traffic from the scanner is accelerated by SecureXL. If a rule for the scanner is at the top, if this traffic is accelerated by SecureXL and it still affects firewall... Maybe there is a way to limit the scanner and not DoS the gateway? Or you can just connect the scanner to the same networks, where targets of the scanner are located, then it will just DoS scan targets.

0 Kudos

The best you can do here is limit the amount of bandwidth/connections the auditors consume in the firewall via the fw samp command which requires SecureXL to be enabled.  Here is a excerpt from my book covering this exact situation:

Your new internal auditor, Jim Profit, has discovered the wonders of the nmap and
Nessus attack tools, and is thoroughly enjoying blasting your underpowered firewall with
ridiculous amounts of port scan traffic aimed at your organization’s various DMZ
networks. Jim’s internal workstation has a static IP address of and is
targeting various destination DMZ networks that can be summarized as
You want to let Jim do his job (as no one ever wants an auditor upset with them), but you
need to ensure acceptable firewall performance for everyone else. You decide to limit
Jim’s workstation to 100 new connection requests per second. The command to do this
would be:

fw samp add -a d -l r -n Limit_Jim_Profit_PortScanning quota \
source cidr: destination cidr: service any \
new-conn-rate 100 flush true

(Note: the ‘\’ character at the end of lines 1 & 2 of this command is a backslash
and allows us to continue the same command on a new line)

Key arguments for our sample fw samp add command:

-a d (action drop)
-l r (regular logging)
-n Limit_Jim_Profit_PortScanning (name of rule)
new-conn-rate 100 (limit new connection rate to 100/sec)
flush true (make this new Rate Limiting rule take effect immediately)

We can check the status of our rules with the command fw samp get:

We can check the status of enforcement with cat /proc/ppk/dos:

But we have done all this, and Jim is still laughing gleefully as he pummels our
firewall with well over 100 connection requests per second! Why isn’t our new quota
working? Remember these quotas were originally designed to blunt the effects of DoS
attacks, which tend to arrive most often on the external interface(s) of the firewall. By
default these quotas will only be enforced on the firewall’s external interfaces. To
enforce our quota on all firewall interfaces (and abruptly halt Jim’s grating laughter), run
the sim_dos ctl -x 0 command.

Second Edition of my "Max Power" Firewall Book
Now Available at

Updated 2023 IPS/AV/ABOT R81.20 Course now
available at

FYI even traffic accepted by Implied Rules are checked, it just saves you the trouble from having to manage them Smiley Happy

0 Kudos


Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events