cancel
Showing results for 
Search instead for 
Did you mean: 
Create a Post
Highlighted
mschilt
Ivory

Blocking parts of the internet / Performance considerations

Hi

I want to block some parts of the big bad internet. CP has this cute script that was built for dshield but uses "fw samp" to block connections using the quota functionality. Now quota sucks because it kills connection templates and I love having them.

I am now thinking of rebuilding the dshield script for my purpose by using the accelerated drop functionality (sim dropcfg -f blog_very_very_bad_networks.cfg)

Since drop templates are applied after connection templates or connection table lookups there could be some glitches (or I kill already established connections based on my list of very bad IP addresses).

Is this the most elegant way of dropping traffic from a large list of networks or hosts (list.txt, cidr notation) or is there a better solution?

 

Thanks.

-Manuel

 

0 Kudos
8 Replies
Admin
Admin

Re: Blocking parts of the internet / Performance considerations

The various mechanisms are fairly similar in terms of performance impact in R80.x.
dshield actually modifies a specific Dynamic Object, which is another approach you can take as well that is SecureXL friendly.
This doesn't require hacking the dshield script, but you can write a script that updates your own dynamic object easily enough and use a rule with that object in your policy.
0 Kudos
mschilt
Ivory

Re: Blocking parts of the internet / Performance considerations

hmm.. dynamic objects are a good point but GW is still on R77.30 and dynamic objects AFAIK still kill connection templates with that version. On the other side dropcfg is still there but were removed in R80.20.  Looks like there is no real elegant/sustainable solution.

We implemented the droplist with SAM Rules so far but the load on the CPUs running SND/SecureXL was just too high to keep up with the load (high packet rate, everything logged, limited numer of CPU cores).

Droprules using dropcfg seem a little less CPU intensive to me because we heavily use connection templates and  connection table lookups happen before the droplist so in theory there should be less CPU impact.. for quote you also need to have counters even when you set thresholds to zero. counters should not be needed for drop templates (in theory.. have no clue how this is really implemented)

0 Kudos
Danny
Pearl

Re: Blocking parts of the internet / Performance considerations

If your are speaking of geographical parts of the world I would recommend using Geo Policy / Geo location objects to easily block them.

mschilt
Ivory

Re: Blocking parts of the internet / Performance considerations

good idea but does not fit my needs as the dark corners of the internetz are not very country specific.

 

0 Kudos
Employee+
Employee+

Re: Blocking parts of the internet / Performance considerations

sk103154 - How to block traffic coming from known malicious IPs

Why do you think "fw samp quota" kills templates?
0 Kudos
Danny
Pearl

Re: Blocking parts of the internet / Performance considerations

OpenDBL is also worth to be mentioned.

0 Kudos
mschilt
Ivory

Re: Blocking parts of the internet / Performance considerations

Hey Danny.

Thanks for the link. Did not know that. Looks like a great framework to download and integrate all kinds of blacklists. 

R80.20 Version uses dynamic objects while R77.30 Version uses FW samp.

The R77.30 version is doing exactly what I am using at the moment.

-Manuel

 

 

0 Kudos

Re: Blocking parts of the internet / Performance considerations

Hi @mschilt,

The SecureXL penalty box is a mechanism that performs an early drop of packets arriving from suspected sources. This mechanism is supported starting in R75.40VS.

Why not sam policy rules?

The SAM policy rules consume some CPU resources on Security Gateway. We recommend to set an expiration that gives you time to investigate, but does not affect performance. The best practice is to keep only the SAM policy rules that you need. If you confirm that an activity is risky, edit the Security Policy, educate users, or otherwise handle the risk. Or better use SecureXL penalty box from a performance point of view.

The purpose of this feature is to allow the Security Gateway to cope better under high load, possibly caused by a DoS/DDoS attack. These commands „fwaccel dos“ and „fwaccel6 dos“  control the Rate Limiting for DoS mitigation techniques in SecureXL on the local security gateway or cluster member.

In version R80.20, the penalty box feature is now supported in VSX mode and each virtual system can be independently configured for penalty box operation.

Attention!

In R80.20, all "sim erdos" commands are no longer supported. They have been replaced with equivalent commands which can be found under "fwaccel dos". Penalty box is configured separately for IPv4 and IPv6. IPv4 configuration is performed using the "fwaccel dos" command. IPv6 configuration is performed using the "fwaccel6 dos" command.

Control the IP blacklist in SecureXL with R80.20 and above. The blacklist blocks all traffic to and from the specified IP addresses. It is an easy way to block certain IP addresses quickly and eficiently on SecureXL level.

The blacklist drops occur in SecureXL, which is more efficient than an Access Control Policy or SAM rule to drop the packets. This can be very helpful e.g. with DoS attacks to block an IP on SecureXL level.

For example, the traffic from and to IP 1.2.3.4 should be blocked at SecureXL level.

On gateway set the IP 1.2.3.4 to Secure XL blacklist:

fwaccel dos blacklist -a 1.2.3.4

clipboard_image_0.png

On gateway displays all IP's on the SecureXL blacklist:

# fwaccel dos blacklist -s

clipboard_image_1.png

On gateway delete the IP 1.2.3.4 from Secure XL blacklist:

 fwaccel dos blacklist -d 1.2.3.4

clipboard_image_2.png

 

 

Tags (1)
0 Kudos