Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | [Snort-users] inline advice |
|---|---|
| Date: | Thu, 23 Aug 2007 10:31:45 -0500 |
We've setup snort on a dedicated box that plays router in front of a group of web servers and colocation boxes. We've ssh port-forwarded mysql back to a dedicated mysql box, and we're using BASE to wade (literally) through the alerts. Our intention is to (a) whittle down on the rules and then (b) switch to inline and have snort drop packets that the rules catch. We're in the "whittle" phase right now. Any links or documentation on (a) this type of setup or (b) whittling down on the rules would be greatly appreciated. Immediately after starting up snort we were bombarded with a lot of port scan alerts coming from some of the internal mail servers and servers that use http to grab updated information. It seems odd that snort would trigger this normal activity as port scanning, when it doesn't flag other servers/users connecting to our internal servers to request web pages or send email. We researched a handful of the alerts and found that they are indeed false positives. Can someone clarify why snort would think our server making normal outbound connections would be flagged as port scanning? We added our internal server range of IPs to the ignore_scanners option of sfportscan, and that certainly cut down on those false positives, but we don't want to leave it like that, if one of our colocation clients were port scanning we wouldn't know it. Thanks in advance for all your help and advice.
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ Snort-users mailing list Snort-users@lists.sourceforge.net Go to this URL to change user options or unsubscribe: https://lists.sourceforge.net/lists/listinfo/snort-users Snort-users list archive: http://www.geocrawler.com/redir-sf.php3?list=snort-users
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [Snort-users] Diagnosing MySQL server has gone away messages, Jason |
|---|---|
| Next by Date: | Re: [Snort-users] Snort 2.8 Beta Available on CVS, Marc Norton |
| Previous by Thread: | [Snort-users] Snort 2.8 Beta Available on CVS, Snort Releases |
| Next by Thread: | [Snort-users] IDS Policy Manager v2.1 Released, Jeff Dell |
| Indexes: | [Date] [Thread] [Top] [All Lists] |