Snort mailing list archives
Re: Snort only partially alerting
From: Frank Calone <fc10011001 () gmail com>
Date: Wed, 26 Jun 2013 16:31:29 -0400
Fellow Snorters, After much testing and with special thanks to Joel, I have an update on the problem I had with Snort only partially alerting. I was unaware during the first few weeks of running snort that the packet datagram was being truncated for some reason, but not in all cases. We had an older Snort app that was flagging alerts which our new server was not. I was running snort in the background with this command: /usr/sbin/snort -A fast -d -D -i p1p1 -u snort -g snort -c /etc/snort/snort.conf -l /var/log/snort -G 3 I suspect this message in the "messages" log folder (This is a CENTOS box) may have been tied to the truncating error: Jun 24 17:20:04 security1 rsyslogd-2177: imuxsock begins to drop messages from pid 10279 due to rate-limiting I started running Snort in the foreground as part of my testing. Then I received this error message: (snort_decoder) WARNING: IP dgm len > captured len I performed binary captures at the same time while doing an Internet download to compare results using TCPDUMP and Snort as follows (the IP below is fake. it represents my PC's address): snort -l ./logall -b -i p1p1 src 57.8.5.15 or dst 57.8.5.15 tcpdump -i p1p1 -N -w tcpdump.jun26.v1.pcap src 57.8.5.15 or dst 57.8.5.15 Doing a playback with snort -dvr showed clearly that the snort log capture had a problem. Joel recommended starting snort with an option to force the capture length. This then resulted in normal looking binary captures and to my delight, an alert showed up when I tested an Internet download (that a rule I have should detect)! The fix was using -P on the command line, here is how I start it now: /usr/sbin/snort -A fast -d -D -P 9000 -i p1p1 -u snort -g snort -c /etc/snort/snort.conf -l /var/log/snort -G 3 The default packet capture length is 1514, though for some reason I wasn't even getting that. This override has for the moment resolved my problem!!! I would highly recommend starting Snort in the foreground on occasion just to see if there are error messages you may not be aware of. Now I can finally get into doing the real work...Yeah!...oh no, I'm afraid of all the work this is going to bring about. Guess I'll be working late tonight!!! Frank On Wed, Jun 19, 2013 at 2:14 PM, James Lay <jlay () slave-tothe-box net> wrote:
Hi again Frank. I would absolutely do the below: turn up some kind of sniffer on our CentOS box to see what is being passed to it on that interface, paying attention to the datagram sizes. If we have a hardware issue, nothing else is going to work well ;) After verifying good hardware, then I'd do the repost to the mailing list. I'd post the rules, the output of snort when you find one that slipped by (run it in the foreground then ctrl-c to get the info). If you can get a small packet capture ready just in case one of the dev's wants it offline that would help. Hope that works out Frank. James On 2013-06-19 10:54, Frank Calone wrote:James, I do have the full rules list as I have downloaded it and have pulled out some Java related ones to use on our Appliance with Snort on it. It already flagged one nice item! In my testing I even have used the exact same rule for the exe alerting on the appliance, so I really dont see where doing anything with the rules will help me at this time. The two rules I show below are very simple and just looking for plain text. I will look into the archive discussions to see what I can find about logging. I want to wait on that though until I just get the alerting to work. No need to worry about logging if the alerts are being missed. That is a good tip though and I will look though the last couple of months archives. So, at this time you would agree I have these options: 1) turn up some kind of sniffer on our CentOS box to see what is being passed to it on that interface, paying attention to the datagram sizes. 2) contact the Snort development team asking for help. 3) Repost this message again to the user list (how much of the thread?). 4) other options you may be thinking about???? Frank On Wed, Jun 19, 2013 at 12:41 PM, James Lay <jlay () slave-tothe-box net [5]> wrote: Ahhh...ok youre wanting to do a full packet capture once the rulesfire...gotcha. Three things I would do: Download both the latest snort rules and emerging threats rules, extract them into a dir, and grep for exe..there are a bunch of rules identifying executables and you can use those to your advantage and tweaking. Search the Snort mailing list archive to include last month...Im certain there was a discussion that hit upon full captures using snort when it fires on certain alerts. Lastly, if the mailing list archive doesnt give a solution, post the below info to the group (scrub/obfuscate the real IPs however)...the Sourcefire Engineers should have an answer on why this isnt working (it looks good to me and should be working correctly). Thanks Frank...hope this helps. James On 2013-06-19 10:07, Frank Calone wrote: James,I do appreciate your thoughts on this. The engine is very current (2.9.4.5). Im running CentOS and have 4 processors and a total of 4 GB memory. I have none of the distribution rules loaded. I am only running 2 rules looking for exes. The logging as I understand it was only to do packet captures for the session that was "tagged" due to an alert. So, here is the startup command: /usr/sbin/snort -A fast -d -D -i p1p1 -u snort -g snort -c /etc/snort/snort.conf -l /var/log/snort2 -G 1 Here are the 2 rules: alert tcp $EXTERNAL_NET !20 -> $HOME_NET any (msg:"Snort_Windows exe down loaded [not DOS mode] not recognized mirror"; content:"This program cannot be ru n in DOS mode"; logto:"/var/log/snort/logto/**sid3000000.log"; flowbits:set,tagged ; tag:session,0,packets,1000,**seconds; sid:3000000; rev:5;) alert tcp $EXTERNAL_NET !20 -> $HOME_NET any (msg:"Snort_Win32 exe downloa ded [Win32 req]"; content:"This program must be run under Win32"; logto:"/var/lo g/snort/logto/sid3000001.log"; flowbits:set,tagged; tag:session,0,packets,1000,s econds; sid:3000001; rev:5;) I have been unable to get the "logto" option to work. I realize the manual says it will not work when the startup command is set to binary logging. This is just a leftover from various testing I have been doing with the logging. My understanding is that the flowbits set tagged causes snort to say this session needs to be logged when an alert occurs. The tab session, 0 , packets, 1000, seconds is causing the session (all packets) to be captured in its entirety for up to 1000 seconds is necessary. This has worked when we get hits, though on large binary captures (in the 50 MB sizes I am not convinced I am getting everything. I say this because the html header info notes the "content size". So I am able to determine how much was captured. Smaller file sizes this has worked fine. Larger ones I usually dont get the exact value noted. Im noting this just so you can see what we are trying to do. The bigger problem is not getting the alert at all. As you can see our testing is very simple looking for plain text. Our network guy supposedly put a network sniffer on our tap last night and he said that the mirror looks to be working fine. Full packets are showing up. I suppose I could try to run wireshark on our Snort system to see what it sees coming in. If there is a way to enable the pcap component of Snort to do this, please do let me know how you would run it to see what is showing up to Snort. Based on what our network guy has just told us, I am lead to believe there is a problem in the way our Snort server is handling the data stream. I was only using 2 rules and yet it only occasionally flags the exes. I was not doing a binary capture on all of the packets, just the specific sessions that alerted. I feel like I am at wits end as to what is going wrong here. I have performance monitoring turned on and near as I can see the system is usually 90% idle and memory usage never gets above 250 MB. I setup stream5 memcap to 1 GB. Im scratching my head as to why then the datagram length is being truncated. I do appreciate whatever suggestions you might have on this. It seems like what I am trying to do ought to work. Yesterday I even removed the session tagging in the rule to just get the Snort application to alert on everything with no extra logging (see rules below). I tried just 2 rules with one being even simpler (going to the youtube web site, I replaced my PCs IP address with the 57.n.n.n one you see in the rule below for non-displosure requirements). Every time I refreshed my web page for youtube the alerts worked just fine. When I downloaded putty.exe my new Snort server never alerted and yet our IBM appliance with Snort alerted each and every time. Im ready to pull my hair out. alert tcp EXTERNAL_NET any -> $HOME_NET any (msg:"Snort_DOS exe downloaded [DOS req]"; content:"This program cannot be run in DOS mode"; sid:3000001; rev:5;) alert tcp 57.198.5.15 any -> $EXTERNAL_NET any (msg:"Youtube"; content:"www.youtube.com [1] [1]"; sid:1999987;) Frank On Wed, Jun 19, 2013 at 11:07 AM, James Lay <jlay () slave-tothe-box net [2] [2]> wrote: On 2013-06-19 08:44, Frank Calone wrote:James,Thanks for the tips. I have looked through the entire Snort manual. Ive also used the site to search for specific keywords and such. I look at all the user group postings now for well over a month (since we first tried using Snort). I just am not a pro at what you guys are doing. The manual says Snort can do binary packet capture of everything. When I turned that on, that is when I saw the problem (error message showing up). I did not get that error message in the syslog when I was running snort the other way (as the manual recommends starting it). Yet, this looks to explain well the randomness of my hits. We have an appliance that monitors web as its main purpose, but it also has a snort engine that we have been using. We look for exes and it does a good job of that. The problem is it does not log at all. We are wanting to log so we can pull the exe out, then can do MD5,AV Totals, and other tests to determine if it is malicious. This other appliance then tells me what I ought to be alerting on. Yet, I only get an occasional hit. If the packets are not complete with payload (datagram issue), that would explain my problem. I am not convinced our network tap is giving me everything, though my boss thinks it is. So, when I turned up full capture yesterday with Snort, I could see I was mostly just getting the header. What I dont know here is whether Snort itself is truncating the packets or if it is the network appliance that is giving us our tap. I really think this is the heart of my issue and I need to figure out which is the problem. So when you suggest a pcap capture I am presuming you are suggesting using a networking appliance or other tool to see what I am getting on the wire correct? There isnt some other setting within Snort that I need to be using to do this is there?Hi Frank, I can totally see where doing a full packet capture using snort would cause issues..its busy logging packets instead of doing its IDS job. I would suggest using tcpdump or tshark to do a full packet capture off the tap (maybe just plug in a laptop running linux and either of the above) for an hour and see if you get full data. Id also recommend making sure the Snort engine is up to date as well as the rulesets. I would not use Snort as a full packet capture plus IDS at the same time. Hope that helps. JamesLinks: ------ [1] http://www.youtube.com/ [3] [2] mailto:jlay@slave-tothe-box.**net <jlay () slave-tothe-box net> [4]Links: ------ [1] http://www.youtube.com/ [2] mailto:jlay@slave-tothe-box.**net <jlay () slave-tothe-box net> [3] http://www.youtube.com/ [4] mailto:jlay@slave-tothe-box.**net <jlay () slave-tothe-box net> [5] mailto:jlay@slave-tothe-box.**net <jlay () slave-tothe-box net>
------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev
_______________________________________________ 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://sourceforge.net/mailarchive/forum.php?forum_name=snort-users Please visit http://blog.snort.org to stay current on all the latest Snort news!
Current thread:
- Snort only partially alerting Frank Calone (Jun 18)
- Re: Snort only partially alerting James Lay (Jun 18)
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- Message not available
- Re: Snort only partially alerting Frank Calone (Jun 26)
- Re: Snort only partially alerting waldo kitty (Jun 26)
- Message not available
- Re: Snort only partially alerting James Lay (Jun 18)
- <Possible follow-ups>
- Snort only partially alerting Frank Calone (Jun 21)
- Re: Snort only partially alerting Joel Esler (Jun 21)
- Re: Snort only partially alerting Joel Esler (Jun 21)
- Re: Snort only partially alerting Joel Esler (Jun 21)
- Re: Snort only partially alerting Frank Calone (Jun 21)
- Re: Snort only partially alerting Joel Esler (Jun 21)