Using the Log Forwarding Built-In Actions to create Dynamic Address Group to Slow down Attackers.

S.Cantwell — Thu, 06 Jun 2019 22:12:43 GMT

Howdy Group

There is configuration area within the Log Fowarding Profile that is powerful to slow down the baddies.

I am not sure how many people are using it.

The premise is

1) I am using an EDL from Spamhaus to dynamically deny access to the public IPs of my NAT'd network.

2) I have a rule that denies Foreign Countries (US based FW) from attempting to access my hardware.

3) I have very good use of rules, so any source address from Internet that does not match, hits my clean up rule.

Presently, I have logs that show X amount of hits on my Spammers, No Foreign Countries, or CleanUp rules.

I know these IPs/users are in constant vigil, trying to access my system(s), port scan, whatever they try is all bad.

I have thought for a long time, about trying to the use the Log Forwarding Profile, to fwd to a http server, to create an EDL.

Then my newly created "Bad EDL" would stop people. Never got that far.

But I found (for me) a much easier way.

Is it advanced?? Maybe, but I wanted to share out and get comments/thoughts.

I have 3 rules (Spammers, No Foreign Countries, CleanUp) that I started with logging at session end (for testing)

create a TAG called "Bad US and Foreign ppl", and used purple for the tag color.

create a Dynamic Address Group (called All Bad Ppl), and use the tag just created, to populate the address group.

create a Log Fwd Profile, (called Stop Bad Ppl), looking at the Traffic Log, but otherwise unconfigured Log Fwding Profile

For the 3 rules I have listed, I modified the security policies to use a Log Fwd Profile, called Stop Bad Ppl

In the new Log Fwd Profile, I used the Built-in Actions, which allows for ADDING or REMOVING a tag to a Src or Dst Address.

I did Src Address (because I want to ADD a TAG to the Src addresses that are ill fated attempting to access my FW.)

I added my TAG called "Bad US and Foreign ppl" to the Built-In Actions.

There is a timeout period (if left to 0, will default to 30 days.) Oh my... think about what can be done.... 😛

My DAG (Dynamic Address Group called All Bad People), which is associated with the "Bad US and Foreign ppl" tag, will populate with every Spammer, Foreign Country, or CleanUp src address. (My rules are very simple..all 3 rules would only have SC (source country) from the Internet, so my Src Zone is Untrusted-L3.

From there, what would you want to do.

For me, there were 2 possibilities..

1) create a rule called No "Bad Ppl" that if anyone (for 30 days, based on the timeout) tries to access/port scan/whatever to my public IP (of FW) or any other offending type of traffic, they all will be denied.

( Commentary, so what I created was a new rule that essentially blocked what would already have been denied/dropped by c configured policies...)

But that is NOT how the PANW FW works. Go DEEPER!!

2) The way the FW works is that the DoS Protection rules are viewed/read/acted upon while the session is first being setup.

So... If you have a bunch of BAD ppl, why make the FW even create a session setup to be off-loaded to the fastpath (security policy processing) only to be denied by security policy?

No!! What I did (and think it was good) was to create a DoS policy with:

Untrust-L3 (src add of "All Bad Ppl" DAG (dynamic address grp) talking to "any" Zone, "any" Address, DENY

The end result:

The DoS Protection Policy will now block all "Bad US and Foreign ppl" in the DAG group, for 30 days. And there is no expressed logging of DoS denied traffic, because it never makes it through the security policy.

It is stops waaaay in the beginning of the process. Less CPU cycles stop keep the bad people out.

No more (or smaller number of ) hits on a continual basis from repeated script kiddies and nmap wannabes.

I started this yesterday, and today, I have 274 Bad Ppl who are now being denied.

I expect that number to grow to whatever the max my DAG can hold (1000 on my test VM firewall)

Thank you.

Steve Cantwell

Re: Using the Log Forwarding Built-In Actions to create Dynamic Address Gro

DLONGPRÉ — Thu, 01 Oct 2020 02:08:28 GMT

@S.Cantwell

Very good post Steve!

So, the end goal of this is to "drop" packets by a DoS Policy, instead the Security Policy, isn't?

I understand that "tagged" IP sources within the DAG have been already blocked once by the your Security Policy, right ?

Very good stuff so far... I'm planning to use DAG associated with sinkhole DNS mechanism to block dynamically infected inside host.

Thanks !

Dominic.

topic Re: Using the Log Forwarding Built-In Actions to create Dynamic Address Gro in General Topics

Using the Log Forwarding Built-In Actions to create Dynamic Address Group to Slow down Attackers.

Re: Using the Log Forwarding Built-In Actions to create Dynamic Address Gro