I experienced that the signature 3050 is firing if SYN requests followed by SYN/ACK packets are logged (traditional Half Open SYN attack), or if only SYN packets are received (service down). There is no subsignature to distinguish between both problems.
Any idea to get more informations out of the sensor? Would be a great help to analyse what going on...
You could get the sensor to start IP Logging all packets to and from the ip addresses.
If the floods are coming from the same source IP all of the time then you may setup the signature to automatically IPLOG when the signature fires. Then all packets to and from the source address will be IP Logged.
If, however, the floods are coming from different source IPs which is fairly common in a true Half open Syn Attack then you may try the following:
As soon as you see the alarm you may use nrConfigure to enter a RecordOfLogAddress to record all packets to and from the destination ip address of the alarm. (Different from the automatic IP Logging which logs from the source of the alarm. In this case you would want to log for the destination of the alarm). Wait about a minute then remove the configuration to keep the sensor from constantly being overloaded.
Then use ethereal to analyze the resulting IPLOG to see if the SYN attack was still underway and see if the SYN ACK packets were there.
Well this is a bit to complicated. I'm using a perl script which is running snoop and is counting SYN requests only, true half open SYN attacks listing the source ip addresses and counter per ip address, and complete hand shakes.
The problem with this script is, that it must be started manually. If the IDS would distinguish between both pattern if woud be easy to run a script over the log file and check whats going on.
By the way, the signature is named as Half Open Syn Attack and only SYN packets are not an attack, so the IDS is not working as specified, but on the other site it is very handy to get informed if a server process is down.
What version of software are you running and what product is this? (i.e. is this the IDSM or the appliance?) The reason I'm asking is that the two code bases behave slightly different on this signature. Neither of them should be aggregating unacknowledged SYN packets. There is a possibility that we have a bug in the software and I need to know where to look so that I can see what is going on.
we are running CICSO Secure IDS version 18.104.22.168 and 2.5(1).
It is absolutely OK to aggregate unacknowledged SYN packets, but it must be visible in the signature or subsignature. Unacknowledged SYN packets are a good indicator is your server is down or out of capacity.
I agree that would be a good piece of information to have. We are adding the capability to develop custom signatures with the release of CSIDS 3.0(1)S4 and although we do not currently have an engine that would allow you to develop such a signature we will have in future releases.
As far as the 3050 signature is concerned it was meant to capture specifically the half open syn flood that was used in the mid 90's known as the Panix attack.
In the 3.0 release we have included a "Net Flood" signature engine that will allow you to develop personalized flood signatures for your network's traffic. These flood signatures are meant to be geared to the more prevalent problem in today's networks of bandwidth exhaustion.
3.0 is currently in the final throws of QA and should be available in the very near future. In the meantime I don't know which signature set your on with the 2.5(1) sensor, but 2.5(1)S3 is available on CCO.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in HA
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationCo...
I am currently unable to specify "crypto keyring" command when configuring VPN connection on my cisco 2901 router.
The following licenses have been activated on my router :