Snort alerts - surely there's more?
-
Hi, I'm very new to pfsense and snort. I'm working in security monitoring with a commercial grade SIEM so I'm used to being able to get lots of information out of my tools. I know I can't expect everything of something that's free, but there are a few examples where I've been surprised by how little information I get. Most particularly I recently saw the alert "Access to suspicious .pw domain detected", and marked as an IOC for a trojan/virus. However, nowhere could I find exactly what domain it was referring to - and that included accessing the pfsense console playing around with the raw snort log (<3 tail and grep). Why is this not stored in the snort log? Is it stored somewhere else that I can find? Google has failed me for answering this.
-
Hi, I'm very new to pfsense and snort. I'm working in security monitoring with a commercial grade SIEM so I'm used to being able to get lots of information out of my tools. I know I can't expect everything of something that's free, but there are a few examples where I've been surprised by how little information I get. Most particularly I recently saw the alert "Access to suspicious .pw domain detected", and marked as an IOC for a trojan/virus. However, nowhere could I find exactly what domain it was referring to - and that included accessing the pfsense console playing around with the raw snort log (<3 tail and grep). Why is this not stored in the snort log? Is it stored somewhere else that I can find? Google has failed me for answering this.
On the ALERTS tab, locate the alert in question. The source and destination IP addresses will be shown. Beside each is a lowercase "i" icon. Click the icon to perform a reverse DNS lookup on the domain. If you use Barnyard2 and export the Snort data out to another SIEM tool, it should also perform any reverse DNS lookups for you. Additionally, the packet data is available in the unified2 log file for the interface when Barnyard2 is enabled.
The Snort logs contain only the "msg" section of a rule's text. For that rule, Snort is performing a regex match on the "*.pw" string. When it finds that in the DNS request, it 'fires' the rule which then prints the "message" text of the rule to the log. If you really want to perform more detailed analysis, then configure Barnyard2 in the Snort package on pfSense and export the data from the binary unified2 log to an external source. Barnyard on pfSense can export to syslog, MySQL and Bro hosts.
Bill
-
Definitely going to look into the barnyard2 thing. Regarding the reverse DNS, I had been under the impression that it wasn't exactly a reliable way of identifying what domain was involved because it couldn't properly deal with domains on shared hosting that all resolved to the same IP?
Also from what I can see, the ability to store the packets that caused a rule to fire isn't something I'll find here - is that one of the things you get when you pay the $$$ for a commercial IDS?
-
Definitely going to look into the barnyard2 thing. Regarding the reverse DNS, I had been under the impression that it wasn't exactly a reliable way of identifying what domain was involved because it couldn't properly deal with domains on shared hosting that all resolved to the same IP?
Also from what I can see, the ability to store the packets that caused a rule to fire isn't something I'll find here - is that one of the things you get when you pay the $$$ for a commercial IDS?
Correct on the rDNS if you are talking about some types of domains, but it is a start.
You will find the portion of the packet that triggered the alert in the unified2 log file (in binary format). Depending on what tool you have Barnyard2 export to, you may or may not get the packet data into the tool.
Bill
-
Do you have Snort Install on the WAN or LAN or both? Having it on the LAN will give you a little more details.
In regards to a commercial IDS, have you looked at "Security Onion" https://code.google.com/p/security-onion/wiki/IntroductionToSecurityOnion Its free and fully featured.
The Snort/Suricata on pfSense is a good first round of protection on the Network. But having a Full Packet Capture IPS, HIDS, NIDS system after the firewall can't be beat.
Security needs a multi-faceted approach. I always like to share this blog. http://dcid.me/notes/2013-jul-08
-
Thanks for the extra help BBcan.
Currently Snort is only running on WAN because I've been following guides that didn't really go in to setting it up on LAN. I'd be grateful if you could point me towards any guides which explain not just -what- to do but -why- one is choosing a particular configuration; and anything that can cover what differences I should make between my LAN and WAN Snort setups.
As for SecurityOnion, I had heard mentions of it before now but nothing that highlighted just how good it would be. Once I started reading around bmeeks' answers about barnyard2 I realised what pfsense/snort were not doing and started hunting for things that would fill in that gap - and SecurityOnion started popping up at the top of all my search results :)
It'll be a few days before I can start playing around with it but that's my next download for sure. The blog's good although you're preaching to the choir this time!
[edit] SecurityOnion looks like a bit of a resource hog - not sure I can afford to run it just yet! My current setup involves doing as much as possible in VMs with VMWare ESXi as the hypervisor. I have a Shuttle XPC with 16GB of RAM, currently running PFSense and an Ubuntu server with Samba, with a copy of Kali that gets fired up temporarily as needed. I still have plenty of resources left for SO but that's a big bite out of them and I want to know whether it's a good idea first - any tips?
-
Hi, fearnothing
With a name like that you got nothin stopping you!
I don't want to put words into Bills mouth, but I think his recommendation for Snort on pfSense would be to have a small amount of rules on the WAN, and most of the rules on the LAN side. There are a lot of forum posts to review and get more answers. I would suggest being a sponge for the next few days. ;)
I recommend Security Onion to everyone as it makes setting up a NSM system a breeze. If you had to install/config all of those tools together and keep it running and updated is no easy feat.
For a small network or Home, you can run with 4GB RAM depending on how many Rules you enable (6-8 would be great). Security Onion will run Virtualized and many do, but I always prefer to have firewalls and IDS on dedicated Hardware. Here are a few installation links.
I would recommend downloading the latest .ISO and run it in a VM to test it out. once it Boots just run [ [b]sosetup ]
Read the following.
https://code.google.com/p/security-onion/wiki/Hardware
https://code.google.com/p/security-onion/wiki/IntroductionWalkthroughYou can also go to the User Forum for help.
https://groups.google.com/forum/#!forum/security-onionAs always pfsense and SO have great people when you get stuck…
-
Currently Snort is only running on WAN because I've been following guides that didn't really go in to setting it up on LAN. I'd be grateful if you could point me towards any guides which explain not just -what- to do but -why- one is choosing a particular configuration; and anything that can cover what differences I should make between my LAN and WAN Snort setups.
Snort sees traffic "pre-NAT", so if you only run it on the WAN interface all the IP addresses you see will be either the WAN public IP address or the IP of the remote host. You will never see any local LAN host IP addresses. This means if you have a compromised internal machine that tries to "phone home" to a BOT CC server, all you get in the Snort logs is your WAN public IP and the BOT CC host destination. Without the local LAN IP address of the calling host, you have no way of easily determining which LAN host is infected. If you run Snort on the LAN, then you see both the local LAN host's IP and the remote destination host's IP in the logs. Much easier then to isolate the infected machine. So for this reason I advocate running a Snort instance on the LAN interface (or interfaces if you have multiple LAN subnets).
In fact, for a typical home network there really is no need to put Snort on the WAN at all. Even if you do, I would suggest only running a very tiny number of "blocklist" type rules that work from lists of known bad hosts. I would put all my meat and potatoes rules for malware and Trojan detection on the LAN.
Slight Edit: if you do not use NAT, then it matters not very much which interface (WAN or LAN) you choose for Snort.
Bill
-
If I went through the rules individually I could probably figure out what each one was for and decide whether I needed it on my LAN or WAN, but there are thousands of them - can you point me at any resources that could help speed up the process of choosing? Also BBcan177, I found a couple of threads from last year where you've been asking about taking the mysql output from barnyard2 in pfsense and delivering it to SecurityOnion, but I haven't discovered what solution you arrived at. Wouldn't it be better to have SecurityOnion take the raw unified2 logs instead?
-
If I went through the rules individually I could probably figure out what each one was for and decide whether I needed it on my LAN or WAN, but there are thousands of them - can you point me at any resources that could help speed up the process of choosing? Also BBcan177, I found a couple of threads from last year where you've been asking about taking the mysql output from barnyard2 in pfsense and delivering it to SecurityOnion, but I haven't discovered what solution you arrived at. Wouldn't it be better to have SecurityOnion take the raw unified2 logs instead?
Hi, this is the last post about that topic. I didn't implement it yet as I agree with you that getting the full raw unified2 logs would be great as you can pivot on that data in Security Onion.
https://forum.pfsense.org/index.php?topic=74486.msg411583#msg411583
-
Glad to know that I'm not asking completely noob-level questions! I found the Google Groups thread but not that one. How difficult would it be to get pfsense snort instances to write their unified2 entries to a remote server instead of local disk? Or (is this a complete kludge?) ssh from SO into pfsense and use rsync to copy the unified2 files say, once per minute?
-
Glad to know that I'm not asking completely noob-level questions! I found the Google Groups thread but not that one. How difficult would it be to get pfsense snort instances to write their unified2 entries to a remote server instead of local disk? Or (is this a complete kludge?) ssh from SO into pfsense and use rsync to copy the unified2 files say, once per minute?
Not possible for Snort to write the unified2 logs to a remote instance. The whole point of the unified2 logs (they are in a binary format by the way) is for speed. This lets Snort work faster and more efficiently because it does not have to wait and write out long ASCII logs. There would be a similar slowdown if it had to wait for remote connections to open for writing files. Plus, there would need to be something on the other end to receive and process the network stream. So all in all, not workable to write that data from Snort directly to a remote host. In fact, in the past Snort could write directly to MySQL databases, but the Snort team removed and deprecated that feature due to the impact it had on speed of detection.
This is where Barnyard2 enters the picture. It can open and read the local unified2 binary log and then send that data to MySQL, syslog, Bro or Sguil. The only problem at the moment with Sguil is Barnyard2 only works for a locally-hosted copy of Sguil. I hope the upstream Barnyard2 maintainers will consider changing that to allow remote Sguil connections. The instant they do, I can modify the Snort package on pfSense to take advantage of it.
Bill
-
OK, posts since last noob question just got reset back to zero :-[. Now it's beginning to make sense. Tutorials are very good at saying "Do A, then B, then C" but when you ask them why they tend to just go quiet.
-
OK, posts since last noob question just got reset back to zero :-[. Now it's beginning to make sense. Tutorials are very good at saying "Do A, then B, then C" but when you ask them why they tend to just go quiet.
[/quote]Don't despair. There are lots of knowledgeable folks here ready to help. None of us know it all. I read just today a quote that is appropriate – "everyone you meet knows something you do not". A corollary would be "all of us are noobs about lots of stuff"… ;). The whole IDS/IPS world can be a confusing maze to navigate. Add to that all the wonderful open source options out there and it can be daunting. One downside of open source software is most developers are happier writing and tweaking code than producing usable documentation. I include myself in that characterization... :-[
That last comment reminds me to mention that an update to the documentation for Snort and Suricata on the pfSense Doc Wiki is needed. I started some updates for Snort a month or two back, but have not gotten anything posted for Suricata yet. If there is a willing user out there, any help would be welcomed. You can contact the pfSense guys to get a Wiki account that allows updating.
Bill
