For a basic snort signature such as that, I started with
alert udp any any -> 192.168.1.0/24 53 (msg:"Incoming DNS request!";sid:9000000;priority:1;),
however I dont seem to submit this as I receive "No supported snort options found to generate signature". The Custom Attack Guide (v6.1, the version I am running) states: "msg rule option and a unique SID are mandatory for a Snort Custom Attack". When adding a test content: section in, the rule is applied successfully, and it looks to be the case that the content: section is required, going against your requirements. Saying that, however, is there anything content-wise in the DNS traffic you are looking for? If it is just generic traffic, would you not be better off filtering the traffic that is not allowed (or if it is allowed, then your sensor may get swamped, dealing with numerous DNS requests?). Is there any specific business driver behind this, or are you just running some tests for learning purposes?
thanks for your reply!
I've ran into the same trouble when submitting a snort signature without content filtering. I then tried to build a McAfee Custom Attack signature. Seems it's working more or less properly...
This signature for a 'technical experiment' if I may call it that. I was intending to use it to capture dns packets originating from a guest wlan where we have to log certain user activities. Thought abusing the sensor might be a possibility. As it turns out - it doesn't really do the intended job. The problem is that I loose most requests/responses due to the alert aggregation
An issue I didn't think about is the possibility to get the sensor swamped by dns traffic. Thanks for the advice!!
After all it helped the learning process
Something I'm trying right now is using the packet capture feature with a very narrow capture filter. So far this seems to be a goable way. I've set Packet Capture to send the log after 10MB to the manager.
Does anyone know if the sensor keeps on capturing after these 10MB where uploaded to the manager?
Thanks again for your help! I really appreciate it!
If there is a requirement to log certain user activities it is likely that you will need to think about another way of monitoring. One idea of the top of my head is the potential use of a hub or SPAN port whereby the traffic could be mirrored to another host (could be a cheap laptop), with Wireshark running on it. If the Wireless Access Point is connected directly to a firewall or Layer 3 device, you could insert a cheap hub between them (or segregate off a VLAN on a switch you have). Essentially, as the DNS sig you are trying to configure is generic, there is a manual element of work either way, after the packets have been captured.
The IPS isnt really designed for this purpose in all honesty.
With regard to the narrow capture filter and the 'send log after 10M' - what settings are you referring to? Given the nature of DNS, I doubt you would get up to 10M in one flow, which is what would be captured each time the alert triggered - even with zone transfer activity or larger DNS responses, 10M would be rare.
Let me know if I have misunderstood what you are trying to achieve :-)
We're already thinking about placing a workstation running linux and tcpdump in that network segment to capture those DNS packets.
But at the moment the test using the sensors packet capturing abiliities works quite fine.
That trial using a signature to capture those packets was a dead end, but at least a good learning opportunity
I was refering to the dedicated packet capturing setting: "/Domain/Device List/sensor1 >Packet Capturing >Enable"
Where I'm using the settings "Send Captured Packets To: The Manager" and "Maximum Capture Size: (MB) 10"
Now I've adjusted the Capture Size to 2MB, as it seens it takes a very long time to fill 10MB with DNS query packets only (not entire flows).
The one thing I still don't know is, if the sensor will continue capturing traffic after uploading the previously captured packets.
catch ya mate!
Ah! In that case the packet capture status should show the number of captured packets increasing - if this stops, then it looks like the capture has stopped (or you could just leave it running and see if more files appear on the manager!). I havent got access to an M-series myself at present, so I cant play around with this - let me know how you get on though!