Strange Alert - SIP Message Flooding

I have this same problem. Also need some guidance on how to deal with these alerts.

Hey All,

This looks like the Snort IDS which is running on the appliances by default. You can disable any rules that might be triggering false positives, or tweak them if you want to adjust their settings. 

This KB article includes links to other false positives and where to disable/modify them, and includes how to download and modify the rules on the appliance: Snort IDS Best Practices. This should probably be added to that list.

The "COMMUNITY SIP TCP/IP message flooding directed to SIP proxy" is in the community-sip.rules file. It's detecting what it thinks is excessive SIP traffic (over 300 messages in 60 seconds from the same source). You will want to:

1. Download the rules from the appliance to a Windows file share using the CMC service > copysnortrules command
   1. The rules/config files are separated by interface. If you've only got one interface dedicated to your appliance, you will edit the "eth0" files.
      
2. Edit the rules/community-sip.rules file in a text editor
3. TO DISABLE the rule: Comment out the rule by placing a "# " before the line with the rule in question (line 12):
   1. # Rule for alerting common TCP/UDP flood attack:
      # alert ip any any -> any 5060 (msg:"COMMUNITY SIP TCP/IP message flooding directed to SIP proxy"; threshold: type both, track by_src, count 300,
      seconds 60; classtype:attempted-dos; sid:100000160; rev:2;)
4. TO MODIFY the threshold in the rule: change the "count" and "seconds" values (300 and 60 by default)
   1. # Rule for alerting common TCP/UDP flood attack:
      alert ip any any -> any 5060 (msg:"COMMUNITY SIP TCP/IP message flooding directed to SIP proxy"; threshold: type both, track by_src, count 300,
      seconds 60; classtype:attempted-dos; sid:100000160; rev:2;)
5. Save the changes.
6. Copy the rules back to the appliance using the service > loadsnortrules command in the CMC. 
7. Snort will be restarted and this should be disabled immediately.

If you'd like to disable Snort entirely, you can:

1. Download the rules from the appliance to a Windows file share using the CMC service > copysnortrules command
   1. The rules/config files are separated by interface. If you've only got one interface dedicated to your appliance, you will edit the "eth0" files.
2. Edit the snort.debian.conf file in a text editor
3. Change the DEBIAN_SNORT_INTERFACE value from "eth0" to "disabled":
   1. DEBIAN_SNORT_INTERFACE="disabled"
4. Save the changes.
   
5. Copy the rules back to the appliance using the service > loadsnortrules command in the CMC. 
6. Snort will attempt to restart and fail (because the interface is set to disabled), but won't be running. To enable it again, change "disabled" back to "eth0" (or whatever the name of the interface is, matching the directory structure).

Hope that helps.

Thanks for the response!  Are there any drawbacks or things we'd need to worry about by disabling Snort?   Since we're just getting up and running it seems like disabling it would be the best route right now. 

If you don't need intrusion detection functionality (lots of people have separate IDS functionality or don't want to start using it until they are ready), or want to dedicate an interface (or appliance) to that rather than using the default interface, it's safe to disable.

PS: You can always re-enable it later, so I think disabling it is safe in general, in the interest of noise reduction!

Great!  Thanks for the response!  We already have an IDS solution so it seemed redundant.

I had something interesting happen.  After booting the device, I got the strange messages again.  I did a copysnortrules and both interfaces were set to disabled.  If I do a "resetsnort" I stop getting them again.