Blacklisting hosts which attempt to communicate with a closed port
-
Hi
I'm trying to set up a very basic rule in Snort.
I have various ports which are open in pfSense, to forward to various servers behind a NAT.
I want to trigger an alert (and then blacklist) any external host that attempts to communicate with a port that's closed.
I've tried to create a custom ruleset (below), but while they validate ok when I try to add them into Snort, Snort then doesn't start (there's a red cross against the interface, which stays red even if you click it).
I suspect I've got the syntax wrong or something, but any pointers on what I've got wrong would be appreciated.
Thanks,
Andrew
Custom rules:
portvar BLOCK_TCP ![… list of open ports separated by commas ...]
portvar BLOCK_UDP ![… list of open ports separated by commas ...]
alert tcp $EXTERNAL_NET any -> $HOME_NET $BLOCK_TCP (msg:"Block closed TCP"; sid:9000000;)
alert udp $EXTERNAL_NET any -> $HOME_NET $BLOCK_UDP (msg:"Block closed UDP"; sid:9000001;) -
Where are you defining the PORTVAR variables? You should not do that in the rules file. The Snort GUI code is not expecting them there. To use variables, first define pfSense Aliases for the ports, then go to the VARIABLES tab in Snort and use the aliases you defined as values for any of the pre-defined variables in the PORTS section down at the bottom of the page. For example, click the in the red text box beside "Define FINGER Ports" and type the name of your ports alias there. At this time the Snort package does not allow creation of custom variables on the VARIABLES tab.
Another option is to add your custom PORTVARS to the configuration template file in /usr/local/pkg/snort/snort_conf_template.inc.
Your rule text is also missing the classtype: parameter. There are some defined classtypes (defined in the classification.config file).
alert tcp $EXTERNAL_NET any -> $HOME_NET $BLOCK_TCP (msg:"Block closed TCP"; sid:9000000; classtype:attempted-recon; ) -
Yes, I put the portvars in the rules file, so that looks to be the problem.
I imagine the pre defined variables have other purposes and are used by other rules so I can't just pick two random ones and repurpose them?
If that's right, I imagine it's best to update the conf template file.
If I do that, is it still possible to cross refer to an existing pfSense alias? If so, what syntax do I need to use please? The open ports are already defined as aliases so for consistency it would be much easier to cross refer to them rather than repeat the definition.
Thanks for your help.
-
p.s. The reason I'm trying to do this is to replicate functionality on the previous Watchguard XTM series firewall that the pfSense is replacing. On the Watchguard, there was a feature whereby any host sending incoming packets that were blocked were blacklisted for a period of time. What I really want to do is block the hosts that appear in the firewall log on the pfSense, but I'm not sure that's possible, hence trying to do it by reference to closed ports. If it's possble for snort to blacklist hosts appearing in the firewall log, that's ideally what I'd like to do. However, I'm assuming that's not possible?
Re the port based approach, on my new setup, I have the pfSense box which sits between the incoming internet connection and a Draytek router that provides DHCP and NAT to the local network. So, in effect, I'm doubly NATed. Of course, when the Draytek NATs the requests from the local network, it chooses unused ports to allow it to distinguish the traffic, so when external hosts reply to those sessions it's using ports which are outside of my open ports list.
How do I distinguish a fresh incoming connection on a blocked port from a legitimate response to an outgoing connection? Presumably I can check for the SYN flag? However, that's only going to work for TCP and not UDP?
-
There is no functionality within Snort to pull hosts from the firewall log and blacklist them.
I think your approach with trying to keep up with ports is doomed to failure – meaning you will likely wind up blocking legitimate traffic. I'm not sure I agree with the premise doing something like what you describe buys you much security, especially when weighed against all the trouble it will take to implement. Why not just let Snort do its thing and sniff traffic looking for bad stuff? Set your firewall to block all unsolicited inbound traffic and let it do its thing. If you must have some open ports, restrict the source hosts to specific IP addresses or ranges if that's possible. For most things inbound on a private system you should use VPN anyway. If you must provide some public services, then put the target servers in a proper DMZ and secure them properly and keep them patched.
Bill
-
Thanks Bill.
Most of my sensitive stuff is behind a VPN. It's only a few limited things which are exposed via open ports. Still, I agree with what you're saying.
Re the /usr/local/pkg/snort/snort_conf_template.inc files, is there a syntax I can use to define portvars that cross-refer back to existing pfSense aliases please?
-
No, there is no way to put Aliases in the template. At the time the template is being read/used by the code, all Aliases have already been de-referenced into their actual string values. In other words, they are no longer "aliases" at that point.
You will have to put them as straight strings just as if you were using Snort on a plain FreeBSD box with no GUI.
Bill
