Using the Log Forwarding Built-in Actions to Create Dynamic Address Group to Slow Down Attackers

cancel
Showing results for 
Search instead for 
Did you mean: 
Community Team Member
Did you find this article helpful? Yes No
100% helpful (2/2)

log-forwarding-attackers_LIVEcommunity.jpg

 

This article was written and developed by Cyber Elite expert @SteveCantwell


There is a configuration area within the Log Forwarding Profile that is powerful to slow down the baddies. I am not sure if 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.

 

At the moment, 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. I never got that far.

 

However, I found (for me) a much easier way. 

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

 

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

 

  1. Create a TAG called "Bad US and Foreign ppl", and used purple for the tag color.
  2. Create a Dynamic Address Group (called All Bad Ppl), and use the tag just created, to populate the address group.
  3. Create a Log Fwd Profile, (called Stop Bad Ppl), looking at the Traffic Log, but otherwise unconfigured Log Fwding Profile

 

For the three 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.... 😛

 

kiwi_0-1633428882940.png

 

 

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 two 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.

 

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

 

But that is NOT how the PANW FW works.

 

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 stopped way in the beginning of the process. Less CPU cycles are being used and I keep the bad people out. 

 

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

 

kiwi_1-1633428882960.png

 

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 for reading!

 

@SteveCantwell 

 
Rate this article:
(1)
Register or Sign-in
Contributors
Article Dashboard
Version history
Last update:
3 weeks ago
Updated by: