Which Snort rules for WAN vs LAN ?
-
Hi,
I configured snort via bmeeks beginner guide and everything is working but it suggests running the rules on the WAN. I am using it in a home network but if i enable rules on the WAN which leads to a lot of alerts for things that would never make it into my network because there are basically no ports open on the firewall.
My thinking is i would want to run most of my rules on the LAN so that i can detect/block any devices that are compromised trying to call out.
On the WAN i am thinking i would want to run only rules that detect/protect the pfSense device itself from being compromised.
Therein lies my problem, I dont really know which packages are suitable to run on the WAN. I am guessing it would not be a good idea to run the exact same (ALL) rules on WAN and LAN. From reading around it seems like there are a couple that people have suggested "emerging-ciarmy.rules" perhaps. But i havent really found any justification and i dont know what each of these rulesets really do to make an informed decision on which ones i should pick specifically for theWAN
I use 2.3.2-RELEASE-p1 on Netgate SG-2440.
Heres the list i can pick from :
Enabled Ruleset: Snort GPLv2 Community Rules
Snort GPLv2 Community Rules (VRT certified)
Enabled Ruleset: ET Open Rules Enabled Ruleset: Snort Text Rules Enabled Ruleset: Snort SO Rules
emerging-activex.rules snort_app-detect.rules snort_browser-ie.so.rules
emerging-attack_response.rules snort_attack-responses.rules snort_browser-other.so.rules
emerging-botcc.portgrouped.rules snort_backdoor.rules snort_exploit-kit.so.rules
emerging-botcc.rules snort_bad-traffic.rules snort_file-executable.so.rules
emerging-chat.rules snort_blacklist.rules snort_file-flash.so.rules
emerging-ciarmy.rules snort_botnet-cnc.rules snort_file-image.so.rules
emerging-compromised.rules snort_browser-chrome.rules snort_file-java.so.rules
emerging-current_events.rules snort_browser-firefox.rules snort_file-multimedia.so.rules
emerging-deleted.rules snort_browser-ie.rules snort_file-office.so.rules
emerging-dns.rules snort_browser-other.rules snort_file-other.so.rules
emerging-dos.rules snort_browser-plugins.rules snort_file-pdf.so.rules
emerging-drop.rules snort_browser-webkit.rules snort_indicator-shellcode.so.rules
emerging-dshield.rules snort_chat.rules snort_malware-cnc.so.rules
emerging-exploit.rules snort_content-replace.rules snort_malware-other.so.rules
emerging-ftp.rules snort_ddos.rules snort_netbios.so.rules
emerging-games.rules snort_deleted.rules snort_os-linux.so.rules
emerging-icmp.rules snort_dns.rules snort_os-other.so.rules
emerging-icmp_info.rules snort_dos.rules snort_os-windows.so.rules
emerging-imap.rules snort_experimental.rules snort_policy-other.so.rules
emerging-inappropriate.rules snort_exploit-kit.rules snort_policy-social.so.rules
emerging-info.rules snort_exploit.rules snort_protocol-dns.so.rules
emerging-malware.rules snort_file-executable.rules snort_protocol-nntp.so.rules
emerging-misc.rules snort_file-flash.rules snort_protocol-other.so.rules
emerging-mobile_malware.rules snort_file-identify.rules snort_protocol-scada.so.rules
emerging-netbios.rules snort_file-image.rules snort_protocol-snmp.so.rules
emerging-p2p.rules snort_file-java.rules snort_protocol-tftp.so.rules
emerging-policy.rules snort_file-multimedia.rules snort_protocol-voip.so.rules
emerging-pop3.rules snort_file-office.rules snort_pua-p2p.so.rules
emerging-rbn-malvertisers.rules snort_file-other.rules snort_server-apache.so.rules
emerging-rbn.rules snort_file-pdf.rules snort_server-iis.so.rules
emerging-rpc.rules snort_finger.rules snort_server-mail.so.rules
emerging-scada.rules snort_ftp.rules snort_server-mysql.so.rules
emerging-scan.rules snort_icmp-info.rules snort_server-oracle.so.rules
emerging-shellcode.rules snort_icmp.rules snort_server-other.so.rules
emerging-smtp.rules snort_imap.rules snort_server-webapp.so.rules
emerging-snmp.rules snort_indicator-compromise.rules
emerging-sql.rules snort_indicator-obfuscation.rules
emerging-telnet.rules snort_indicator-scan.rules
emerging-tftp.rules snort_indicator-shellcode.rules
emerging-tor.rules snort_info.rules
emerging-trojan.rules snort_local.rules
emerging-user_agents.rules snort_malware-backdoor.rules
emerging-voip.rules snort_malware-cnc.rules
emerging-web_client.rules snort_malware-other.rules
emerging-web_server.rules snort_malware-tools.rules
emerging-web_specific_apps.rules snort_misc.rules
emerging-worm.rules snort_multimedia.rulessnort_mysql.rules
snort_netbios.rules
snort_nntp.rules
snort_oracle.rules
snort_os-linux.rules
snort_os-mobile.rules
snort_os-other.rules
snort_os-solaris.rules
snort_os-windows.rules
snort_other-ids.rules
snort_p2p.rules
snort_phishing-spam.rules
snort_policy-multimedia.rules
snort_policy-other.rules
snort_policy-social.rules
snort_policy-spam.rules
snort_policy.rules
snort_pop2.rules
snort_pop3.rules
snort_protocol-dns.rules
snort_protocol-finger.rules
snort_protocol-ftp.rules
snort_protocol-icmp.rules
snort_protocol-imap.rules
snort_protocol-nntp.rules
snort_protocol-other.rules
snort_protocol-pop.rules
snort_protocol-rpc.rules
snort_protocol-scada.rules
snort_protocol-services.rules
snort_protocol-snmp.rules
snort_protocol-telnet.rules
snort_protocol-tftp.rules
snort_protocol-voip.rules
snort_pua-adware.rules
snort_pua-other.rules
snort_pua-p2p.rules
snort_pua-toolbars.rules
snort_rpc.rules
snort_rservices.rules
snort_scada.rules
snort_scan.rules
snort_server-apache.rules
snort_server-iis.rules
snort_server-mail.rules
snort_server-mssql.rules
snort_server-mysql.rules
snort_server-oracle.rules
snort_server-other.rules
snort_server-samba.rules
snort_server-webapp.rules
snort_shellcode.rules
snort_smtp.rules
snort_snmp.rules
snort_specific-threats.rules
snort_spyware-put.rules
snort_sql.rules
snort_telnet.rules
snort_tftp.rules
snort_virus.rules
snort_voip.rules
snort_web-activex.rules
snort_web-attacks.rules
snort_web-cgi.rules
snort_web-client.rules
snort_web-coldfusion.rules
snort_web-frontpage.rules
snort_web-iis.rules
snort_web-misc.rules
snort_web-php.rules
snort_x11.rules
-
Did you get an answer on this? I'm looking for the same answer (also on the same hardware, but on v2.4.2p1). Hoping bmeeks could give some quick advice.
I have a WAN running the CIARMY and the RBS (which seems empty?). But this information is from 2013 and not sure if it's relevant any more.
-
That guide is a bit dated. I now recommend home users run Snort on the LAN interface. The main reason is that with NAT, when you run Snort on the WAN, you can't identify which client on your LAN is the "offender" when Snort detects something. Everything for your LAN shows up having the external WAN IP address in the alerts because Snort sees traffic before the NAT is "undone" when running on the WAN. If you run Snort on the LAN, then it sees traffic after the NAT has been "undone" so you can see the actual LAN client IP addresses in alerts.
Unless you have poked the firewall full of holes with ill-advised rules, I would not worry too much about your pfSense box getting compromised from the WAN side. Out of the box it accepts no inbound traffic on the WAN (meaning inbound from the Internet).
Bill
-
Gah. I meant to mention that I have Snort running on LAN already, and I'm comfortable picking rules that are appropriate for LAN usage.
But it's the WAN side that I just want to be a little more protected, other than relying on states. This is a SMB installation. I'm not running any servers through pfSense except OpenVPN. I'm having difficulty identifying which rules are appropriate to run purely on the WAN side. I'm assuming that there is still a valid concept for putting Snort on WAN if there are no WAN services running..?
-
Gah. I meant to mention that I have Snort running on LAN already, and I'm comfortable picking rules that are appropriate for LAN usage.
But it's the WAN side that I just want to be a little more protected, other than relying on states. This is a SMB installation. I'm not running any servers through pfSense except OpenVPN. I'm having difficulty identifying which rules are appropriate to run purely on the WAN side. I'm assuming that there is still a valid concept for putting Snort on WAN if there are no WAN services running..?
For the WAN in a typical home network where there is no unsolicited inbound traffic (excepting something like OpenVPN), I think it is perfectly safe to trust the firewall's default "deny all inbound" rule set. No need for Snort on the WAN unless you just want to see some alerts in your logs. Snort on the WAN lives on the WAN NIC side of the firewall, so that means it will see inbound traffic before the firewall does. So Snort will alert on stuff that your firewall is going to block anyway.
With that said, I run two sets of Emerging Threats rules on my WAN with Snort. And I do that only to generate some alert noise in my Snort logs. For one thing I use those alerts when I'm working on the package code to make sure display data formats correctly. I also just like to bring up the ALERTS tab and see some fresh stuff. Security wise the alerts on my WAN are meaningless as I have no Internet-facing services or ports open. The two ET categories I run on the WAN are ET-CIARMY and ET-DSHIELD. And one more time just to be sure, I don't run these rules on the WAN for any security reason. I run them just to purposely generate daily alerts in my Snort logs so I can test with them for code development and such.
Bill
-
Bill/bmeeks, that's perfect and good information - exactly along the lines of what I was thinking also. I am in a small medical installation, not home, so I do want some of this "noise" to show up, even if just for my own satisfaction of preemptive acknowledgement of blocking.
To that end, I'll run the same rules as you suggest; I'm noticing the ET-CIARMY is already reasonably noisy.
It would be super-cool if you could possibly find the time to update the first post of the sticky for New Users in this category, as there is a lot of information that is now outdated/superceded - new users have a rough time identifying the basics. In fact, the current pfSense tutorial/guide for Snort was the best I've found, but not many references to it within this forum. Coupling a link to that page, plus a brief overview of WAN/LAN suggestions, would be ideal - rather than reading a day's worth of scattered posts from 2013 onwards.
