topic Re: DoS policy notify in General Topics

DoS policy notify

BigPalo — Tue, 11 Sep 2018 14:18:03 GMT

Hi,

We have configured a DoS policy in order to limit the connections to several internal services.

So when we launch a test in order to check that the connections are being limit we dont see any logs or event reporting it.

But looking in policy statistics we see that its being applied.

how can we verify that the policy DoS is working???? should we see any log or event about DoS?

thanks

Re: DoS policy notify

BPry — Tue, 11 Sep 2018 17:19:54 GMT

@BigPalo,

Within the threat logs your subtype will be flood. This will show you whenever one of your policies are triggered.

( subtype eq flood )

Then if you want to get notified you would just setup Log Forwarding profiles.

Re: DoS policy notify

BigPalo — Wed, 12 Sep 2018 06:41:31 GMT

Hi BPry,

We dont know any event in "Threat logs" about this test. What are the causes to not show anything in "threat" logs?

Re: DoS policy notify

BPry — Wed, 12 Sep 2018 13:20:35 GMT

@BigPalo,

Are you sure that you are at least hitting the 'alert' value if not the 'activate' or the 'maximum'? The DoS Protection rules should show hits regardless of if you passed any of these values, as the profiles are actively evalutating the traffic.

Re: DoS policy notify

BigPalo — Thu, 13 Sep 2018 09:13:11 GMT

I attach the config:

DoS Protection Policy

We dont see any log after testing the profile:

Counter DoS. And DoS rule with 610 current, no drops.

Why is not limiting the connections??

Re: DoS policy notify

Remo — Thu, 13 Sep 2018 09:26:17 GMT

Hi @BigPalo

The max rate that you specified to 200 does only apply for TCP-SYN packets and not for already established sessions. If you want to limit the concurrent sessions you will find the corresponding configuration in the "ressource protection" tab.

Re: DoS policy notify

BPry — Thu, 13 Sep 2018 14:48:14 GMT

@BigPalo,

To go along with what @Remo mentioned; you are also running this as Classified and specifying a TCP-Syn alarm rate of 180 packets per second. That's quite a lot for one client to generate to actually trigger an alarm in a production environment, and I wouldn't expect this to actually trigger in most enviroments.

Have you actually went through and baselined expected traffic volume? Keep in mind that your DoS profile will show a hit for any traffic that matches that policy and is analyzed; that doesn't mean that it's dropped traffic 610 times.

When initially setting up a DoS Profile I would highly recommend setting an incredibly high 'Activate' and 'Max' rate; then play around with the Alarm rate to see where you actually triggering the DoS Profile. This ensures that you aren't dropping anyones traffic until you actually know what your baseline is, and you can set your Activate and Max rates accordingly. The Session Limit you can't really play with, you need to properly baseline expected session levels before setting a session limit or you may see yourself dropping traffic that you don't necessary want to.

Re: DoS policy notify

BigPalo — Mon, 17 Sep 2018 08:18:29 GMT

Yes, one thing:

The configuration we are looking for does not require (and should not) limit the number of concurrent connections. We should only control the growth of connections over time. The idea is that, before an 'avalanche' of connections to a specific service, only 200 (for example) are allowed every 2 seconds, although after a few seconds / minutes, there are, for example, 2500 concurrent connections.

We have done tests (using j-meter), we observe that the DoS policy is executed, but we do not have logs or any trace or historical evidence, only We can see in real time, reviewing the status of the application of DoS policies.

Re: DoS policy notify

BPry — Tue, 18 Sep 2018 17:06:40 GMT

@BigPalo wrote:

We have done tests (using j-meter), we observe that the DoS policy is executed, but we do not have logs or any trace or historical evidence, only We can see in real time, reviewing the status of the application of DoS policies.

Explain this one for me a bit.if the DoS policy is activated then this will be recorded. If you are flooding the interface or running into limitations on your box then that's a different issue all together; but a properly functioning firewall will always record when a DoS policy hits an 'Activate', 'Max', or session limit event.

Re: DoS policy notify

BigPalo — Wed, 19 Sep 2018 07:37:10 GMT

Hi Bpry,

Yes, in this thread you can see the screenshot about how SYN flood (max) is enabled. So we see that the DoS policy is being applied but we dont see any "floof" event in threat logs. So we also would like to know how to find event about flooding in PA.

Re: DoS policy notify

BPry — Wed, 19 Sep 2018 14:10:12 GMT

@BigPalo,

I replied to your other post too early (btw please don't do separate posts for the same issue like this, it makes everything far more confusing when people come across your post with the search functionality).

So what you're showing is that your policy is getting hit, but I think you're getting the different policy types mixed up. Your classified profile accounts for one IP hitting the alarm activate or max values. It appears per your previous comments and your expectation of how you expect this to function would dictate that you actually wish to setup an aggregate policy instead of a classified. The section that you've highlited saying there is 610 sessions is the total session count for this policy. As you've configured it unless one of the sole source IPs hit above 180/s. The highlited rate of 15 that you've pointed out also doesn't come close to actually triggering your policy as configured.

The difference here is that you're currently limiting a sole source ip from hitting the target destination at the specified rates. That means that 172.16.1.1 gets 180/s and then 172.16.1.2 gets 180/s but collectively the firewall as you currently have the policies set don't care how many sessions collectively occur. If you switched this to an aggregate then it would be all traffic is only allowed to get to a specified rate.

Once you've actually triggered the policy limit you can find the information in the threat logs when using the query ( subtype eq flood ), where you will see either 'Session Limit Event' if you've hit a resource limit or a variation of 'TCP/ICMP/UDP Flood' to indicate if you've hit a connection rate limit.

Again I would expect with your specified rate limits what you're actually looking for is an aggregate policy. If you aren't looking at an aggregate ppolicy and you actually want a classified policy, there is currently no provided results that your hitting the values you've set in the profile.

Re: DoS policy notify

BigPalo — Thu, 20 Sep 2018 14:42:33 GMT

Hi Bpry,

Sorry for duplicate threads. You can delete the another one.

The point is that we can see that the policy DoS is getting hits. But we dont see any threat events type "flood" when we launch j-meter.

So it could be that flood threat event is only generated with "zone protection" limit, and not with DoS policy?????

Should DoS limit SYN obverloaded generate an event in threat logs??

Re: DoS policy notify

BPry — Thu, 20 Sep 2018 17:02:10 GMT

@BigPalo,

Right... again 'hits' against the profile are not the same as actually triggering the DoS protection. You keep talking about jmeter, but you haven't actually shown that you know that jmeter is actually launching enough traffic to trigger your DoS profile. Simply lowering your connection 'alarm' rate would allow you to verify/see that the DoS policies are working as expected and see exactly the alerts that I'm mentioning in the threat logs. I'm not confident that jmeter running on one host would be able to actually generate enough sessions to trigger the policy as you have it configured, your values are simply too high for a classified policy.

Both Zone and DoS policies will trigger a log whenever either is actually activated; that's not a configurable piece, they trigger they log.

Re: DoS policy notify

BigPalo — Fri, 21 Sep 2018 06:12:53 GMT

We changed the limits values lowe and it still not generating a threat food event.

We can see in counter DoS rule the number of packets matched in DoS policy that why we think the alarm should be generated.