Is it possible with the asa5516 to automatically deny a host if it starts multiple sessions to a specific destination IP and specific destination port in a predefined time frame?
When a host sends 10 tcp packets with the syn flag to a specific destination on let's say port 3389 within 30 seconds, block the source IP address in the ASA.
This should migitate failed login attempts within our network.
The feature "Preventing SYN Attack Prevention" which is found under Network Analysis Policy -> Settings -> Rate-Bassed Attack Prevention in FirePOWER Management Center 6.0.1 seems exactly what I'm looking for at first hand. Unfortunatly it's not always doing what the following article is saying:
It should block only the malicious Source IP addresses, but it's blocking all Source IP addresses when the treshold is reached multiple time simultaneously.
I used the following test set-up:
The client computer was used to login with wrong credentials on the Windows Server and when it reached the treshold and couldn't establish a connection anymore I switched the IP address of the client. Sometimes I could establish a connection (like it should) and sometimes when I had 2 or 3 IP addresses locked out because of reaching the treshold, the FirePOWER module was blocking all source IP addresses.
Cisco, can you plse explain to me why it's blocking all Source IP addresses?
Ok, the problem with the SYN Attack Prevention seems to be a bug in the Rate-Based attack preprocessor. They have created a bug ticket to fix this issue:
Any update about this problem.
I want to enable this feature and rate-based For simultaneous connection, but I am not sure how to configure it correctly.
I enabled rate-based for sumultaneous connection for 200 connectios for destination ip address - without the drop option.
In intrusion events I cas see alot of events GID:135 .
Traffic that matched access control rule with intrusion policy with drop, droped one IP because of this signature while in the NAP policy I did not check the drop check box.
What is happening?!?!
Hi Kfir, are you sure the preprocessor with GID:135 was responsible for the blocking? Was it not some other Intrustion Rule which blocked it?