ACE connection limit and remote TCP security scans

ecthompson · ‎03-23-2011

We are currently running remote TCP security scans on our networks and are running into a major problem where when the scans are taking place the ACE connection resource usage sky rockets and easily reaches the maximum 4 million connections. This means that anyone can run a simple TCP scan and take down our ACE by maxing the connection limit. We have the following parameter-map applied to all of our policies but it does not help to clear the connection count on the ACE in a reasonable amount of time. parameter-map type connection CONNECTION_TIMEOUT set timeout inactivity 300 set tcp timeout half-closed 60 I should note that we do have normalization turned off because it causes way more problems then it's worth (no resolution with TAC). Does anyone have an tips on how to accommodate security scan's on networks behind the ACE while not saturating the connection count limit?

ohynderi · ‎03-24-2011

Hi,

With normalization disabled, only solution that i see to "mitigate" this is configuring a very agressive idle timeout. Half-closed and embrionic timeout being not used when normalization id disabled. Are you doing a port scanning? How may vip do you actually have on your ACE?

Thanks,

Olivier

ecthompson · ‎03-27-2011

For vips, this particular context only has one class C applied to a class-map. Not all IP's are in use but regardless the ACE creates connections for those as well. I've set the timeout inactivity to 120 seconds and I still see connections from the remote scanning host idling well over 45mins for connections destined to the vip's. Is turning on normalization my only option? I know there are others who have turned off normalization due to performance and connectivity issues so there must be other ways around this. Thanks for your help.

ohynderi · ‎03-28-2011

Idle timeout should be working even if normalization is disabled. Will those connections stay till the default idel timeout is reached (1h for tcp conn)? I am wondering if you could be hitting CSCsz52933. Maybe better to open a service request if you want to investigate this.

Thanks,

Olivier