Disable/Change DoS Settings

[jonsellars]

I was wondering if it would be possible to disable or change the DoS settings on the CSS. At the moment, it is flagging valid hosts for a SYN attack and I'd like to either change the definition of "SYN attack" to a higher count than 10 packets or disable that feature alltogether. Any help would be greatly appreciated. Thanks.

[Gilles Dufour]

the syn attack is not triggered by the amount of syn packet but by the fact 1 tcp handshake from this particular host did not complete within 16sec.

It is not configurable and you can't disable it.

You should investigate why it takes more than 16sec for the tcp handshake to complete.

Does the server have a route to return the syn/ack to the client ?

Thanks,

Gilles.

[jonsellars]

Thanks for the response Gilles.

We've been looking at this and have started to zero in on the cause of the incomplete handshakes.

The issue we see now is that in our environment, there is no way to completely eliminate incomplete handshakes. Our hosts are connected over a private satellite network which is obviously sensitive to atmospheric attenuation. This being the case, there will always be the opportunity to have incomplete handshakes and the hosts will then be flagged for a SYN attack.

Here's some background on the issue. The sites that are on the CSS SYN Attack List either have been connected or will end up connecting after subsequent attempts. All of the sites have been connected and transacting with our server at one time or another so the routes are intact.

One of our technical requirements is that when a site connects, it needs to stay on the particular port and server for at least 24 hours. Any jumping from port to port is unacceptable which is exactly what we've seen from sites that have been flagged for SYN attacks.

I have a couple questions. First, how exactly does the CSS treat a host that has been flagged for a SYN attack? From what we've experienced, it seems that it reclaims all resources allocated for the site (FCBs) as well as removing it from the sticky table. If this is the case, is there any way to get the CSS to not drop the site from the sticky table so that it doesn't have the opportunity to connect to a different port/server on subsequent connection attemps?

Thanks in advance for any information.

[Gilles Dufour]

actually you can just ignore the syn attack.

All the dos protection feature does is logged a message and send a RESET to the server for the connection that failed.

No subsequent SYN will be blocked.

If your connection needs to stay up for 24 hours, you need to make sure the CSS does not time out the connection.

By default there is 8 or 16 sec idle timeout.

If you have a CSS1150x, you can use the command 'flow-timeout-multiplier' to increase the timeout.

Gilles.

[jonsellars]

Thanks again for the reply.

It seems we have a separate issue entirely then.

The behavior we're seeing is that a small number of sites are somehow able to bounce back and forth between multiple ports. I have set the flow-timeout-multiplier to 10800 and the sticky-inact-timeout to 2880. These setting should hold each connection for 48 hours before releasing them. What conditions could allow a connection to disconnect and then comeback to be distributed to another port by the CSS.

The only common link we've found between the effected sites are the SYN Attacks.

I am using CSS 11503s with version 7.4.

[Gilles Dufour]

I would have to look at the config and a sniffer trace showing the problem.

The only possible issue is if your sticky table gets full, then the CSS will delete old entries whatever the inact-timeout configured.

There is a command to verify this "sho sticky-stats".

Gilles.

[jonsellars]

Attached is the output from the show sticky-stats and show run commands on my CSS. The sticky stats indicates that we haven't run out of space in the sticky table before. We've never had more than 1100 separate sites connected to this system.