RFC (make up a number not in use) - Blueprint for setting up snort + pfblocker
-
Update:
Some people reported problems with the RBN list. I have therefore stopped using that list, as well as the rbn-malvertisers.
So, red becomes blue:
DO NOT USE! > emerging-rbn > use pfblocker with: http://doc.emergingthreats.net/pub/Main/RussianBusinessNetwork/RussianBusinessNetworkIPs.txt >>>>
DO NOT USE! > emerging-rbn > use pfblocker with: http://rules.emergingthreats.net/blockrules/rbn-ips.txtand….
DO NOT USE! > emerging-rbn-malvertisers > use pfblocker with: http://doc.emergingthreats.net/pub/Main/RussianBusinessNetwork/emerging-rbn-malvertisers.txt >>>>
DO NOT USE! > emerging-rbn-malvertisers > use pfblocker with: http://rules.emergingthreats.net/blockrules/rbn-malvertisers-ips.txtboth of those are txt format of course.
Any ideas/corrections/hints are welcomed.
These will be merged in the next update.
-
Thanks much! This thread is extremely helpful!
As I'm new to Snort, I have also followed the beginner's guide and configured the blueprint for WAN to start with. I only use IPS Policy - Security (in Blueprint config) right now (plus pfBlocker with Blueprint lists) - no ET lists yet. Next step is to add a LAN interface in order to block trojans etc. and there are only few remaining questions - grateful for your thoughts:-
I understand that the Snort Blueprint on WAN is a waste of resource if I configure Snort LAN with Blueprint settings as well. So it's recommended to use a lighter set of ETs for WAN only. Question given that meanwhile the ET lists recommended in the initial post have essentially been replaced by pfBlocklist recommendations: Would I now only configure LAN blueprint and rely on the pfBlock blueprint alias for the WAN - or would I rather keep a Snort WAN interface also and use ET rules or e.g. IPS Policy - Balance?
-
As a more general point, given that the beginner's guide recommends IPS and I'm subscribed now: Once you have a subscription to the IPS list, do additional ET lists make much sense or are they mutually exclusive?
Great work anyway! Have very few false positives but do have correct blocks :)
-
-
First answer:
Running identical setups for the LAN side and the WAN side is not ideal, but doable with lots of RAM. Following the blueprint, your memory usage should be around 500oddMB per interface. If you are running a single LAN interface and a single WAN interface (not snort interfaces, physical ones), then you don't need to run snort on the LAN side, since all traffic goes through the firewall, which will get inspected by snort anyway (make sure you set it up to ban both source+destination, it should have set up itself to recognise "its" own IPs (WAN IP, DNS).
There is still the possibility of something passing through snort, taking advantage of a vulnerability on a pc behind pfsense, and if not smart set up a remote connection to accept commands, or if smart it should be able to scan the network and use existing vulnerabilities. This is NOT a scenario you should be worried about, since we are talking about a few MBs passing through snort without it noticing anything (hint:it will notice it), in the case that it's smart, or a connection to known CnC servers will be flagged sooner or later.
Ideally you should run rules designed for LAN on the LAN, and WAN rules on the WAN. It's quite the work to go through all the rules and manually disable/enable needed ones. If you are using it for a simple home connection, just use one snort interface, on your WAN.Second answer:
It's either the normal rules or the subscription rules as far as I remember.EDIT: Trigger happy with the post button:
In the specific case of trojans, they will most likely be blocked coming in to your network (while downloading them) or they will be flagged going out. Either case, it will be obvious by your alerts+blocked tab (you do inspect them daily, right?). I'm assuming it's for a home network of 5 PCs/tablets/phones and it should be pretty obvious in that case which one got the trojan. Reformat it and it's done. Then check why it got infected.On a side note (since we are talking about trojans), never leave computer equipment unattended. When left unattended all equipment should be treated as compromised. Don't use it for typing and/or manipulating any document above PUBLIC, and as soon as possible dissassemble the aforementioned equipment, and visually inspect the printed circuit boards, cables, solder joints and connectors for signs of tampering. Solder joints tampered with should have a yellowish color if the solder used contained lead, or otherwise should have a matte surface if the solder was lead free. If the equipment is a laptop, pay special attention to the monitor bezel. Antennas need to be upright, and the bezel is an ideal place for them. If the equipment is a desktop computer, pay special attention to the keyboard, as well as the cable. If computers were left unattended while being turned off, compare their disk's smart reports for increase in attribute 12, Power Cycle Count. Compare with the count from the previous boot up. Do not leave unattended computers without first locking them (requiring a passPHRASE to let you back in).
And all that is after I'm assuming you physically disabled the firewire port on your laptop (firewire ports have direct RAM access, it's the first thing to go).
Yes I did leave my laptop unattended once. We were at a library and I was in the process of closing programs to power it down and take it with me. A friend wanted to get on facebook and I wanted to go outside for a smoke. 3 hours later it was being disassembled, even though it was within warranty (it took me a couple of hours to finish up and go home). By bedtime it was restored to a known clean image. I never trusted anyone with any of my computers after that. They always turn your friends first. I now keep it under 24 hour surveilance. Either me, or, shall we say colleagues, are always around it. ;) (colleagues doesn't mean people you work with, it means people you trust your life to. Members of the family are best to be excluded)
-
Just FYI:
I first caught wind of the new Linksys vulnerability last week. Then, a buddy of mine (going back to FIDONet days) who does security for one of the big investment firms sent this over.https://isc.sans.edu/forums/diary/Scans+Increase+for+New+Linksys+Backdoor+32764+TCP+/17336
I have a handful of Linksys boxes… but I use them purely as distributed APs. They are all on DD-WRT and behind my pfSense box. I did see evidence of the attempted scans, But I took a quick check on my tables and didn't see the offending IPs listed anywhere. Hopefully they'll show on an update soon. For now I just manually added those mentioned in the link.
Rick
edit: for those interested, I went looking and found the github post: https://github.com/elvanderb/TCP-32764
-
@jflsakfja:
First question: … If you are using it for a simple home connection, just use one snort interface, on your WAN.
Thanks! Understood - so I should be set up all right. You are right about RAM usage, pfSense has a D525 Atom + 2GB RAM exclusively and seems to feel comfortable though (pfBlock, Snort, SIProxd, openvpn).
The only thing I've been wondering is this: I have family members + friends laptop / tablets in my network. The ones in my inner LAN and able to access server resources are all on Linux. But there are Androids dialling out into the Internet etc. - and they are used out in the wild as well (airports etc.) or could get compromised by a rogue App. That's why I thought about having Snort monitor the LAN port using Blueprint, and only use the pfBlocker Blueprint aliases on the WAN interface.Correct: I look at Alerts + Blocked on a daily basis.
Correct: I have configured Snort WAN to block Both. LAN addresses will be whitelisted - but I guess I would still see the Alert then from what you are saying - and should then be able to treat the offending LAN device.@jflsakfja:
Second answer: It's either the normal rules or the subscription rules as far as I remember.
Ok I was unclear: I meant to ask whether I still need to configure Emerging Threats if I use the subscribed (i.e. quick) IPS Lists in Security mode.
@jflsakfja:
…never leave computer equipment unattended.
Will try my very best - but as the post on commercial Linksys etc routers shows it is pretty easy to buy compromised stuff in the first place :) And I would not be too sure as regards the Androids of my kids either…
-
If I could ask the most stupid questions again, for which I am famous by now ( ;D)
Why would you not run Snort on LAN? (I do, on LAN and VLAN). I am following Bmeeks recommendation in this matter: crap from the inside that wants to go out needs to be blocked as well; SPI doesn't take care of that.
And something I didn't quite understand: block both src/dest on WAN, doesn't that mean you LAN-IP gets on the block list and can't go anywhere at all anymore?
May 2014 be the year that I am no longer champion in the stupid questions department ;D ;D ;D
-
@Hollander:
Why would you not run Snort on LAN? (I do, on LAN and VLAN).
Only to not waste resources by doing redundant things.
@Hollander:
I am following Bmeeks recommendation in this matter: crap from the inside that wants to go out needs to be blocked as well; SPI doesn't take care of that.
And something I didn't quite understand: block both src/dest on WAN, doesn't that mean you LAN-IP gets on the block list and can't go anywhere at all anymore?Ok - in that case, yes. In my case, I'm not so concerned about a bit of rogue traffic going out (that would go out of the devices when at school etc. anyway and booked into third party networks) - I want to fix them. Thus them being flagged by an Alerter is good enough for me. I understand that in case of a rogue LAN device blocking Both (src/dest) still blocks the WAN dest only but the LAN src will be flagged (not blocked due to whitelisting LAN).
-
I just implemented pfBlocker with ET, Spamhaus, some of the IBlock, abuse.ch (Zeus etc), dShield and Ciarmy.
I have enabled blocking rules for the WAN and Reject rules for the LAN. I would recommend monitoring the LAN as a must.
It is taking a big load off Snort so it can process for other alerts.
An interesting point is that the .txt files used from ET are the Open rules. I have an email out to see if PRO .txt file are available. Snort is still picking up some of the ET alerts because Snort in my application is using the ET PRO ruleset.
ET also mentioned that they will be eliminating the RBN listings as they are inaccurate. I will post my findings later.
-
Further explanation on why you should NOT use snort on LAN if you only have 2 computers
I feel the need to further explain my reasoning for not running a duplicate instance on the LAN. The main reason is duplication of effort. That translates to increase resources being used for no reason.
Let's assume that your WAN IP is 1.1.1.10. Let's also assume that an attacker sits at 2.2.2.10. You go to a bad site for example, and packets start coming in from your wan side start getting copied and the copies sent to snort. In the meantime the packets start hitting your hosts behind that 1.1.1.10 address, which get access to the public internet through NAT. Internal IPs are in the range 192.168.1.x. Host 192.168.1.2 is in the process of receiving a priviledge escalation exploit. Snort sees the bad traffic, behind the scenes, as it it happening, and starts the banning process (alert,snort2c table etc…etc...). The ban was successful and the connection to host 2.2.2.10 has been interrupted, rendering the exploit delivery unsuccessful. What has actually happened though, while banning is that traffic coming from host 192.168.1.1 (ACKs for the packets coming in) was being NATed to ip 1.1.1.10. Snort saw the suspect traffic, and as instructed proceeded to ban both the destination (1.1.1.10) and the source (2.2.2.10), later realizing that 1.1.1.10 was on its whitelist, and therefore left it alone.
The same scenario can be reversed. In that case, you are the source of the exploit, and snort will effectively interrupt connections to the victim host (your source is on the whitelist, therefore not banned completely). If your WAN IP was not on the snort whitelist, then snort would set up a ban for your IP, effectively dropping all your internet traffic (that IP is not allowed to get any packets, nor send any packets).
Why the short thesis: If you only have a couple of PCs connected to a pfsense box running snort, running another instance of snort on your LAN side is simply a waste of resources. Snort will detect exploits/malware/etc coming in (it also detects if an antivirus/antimalware is being downloaded on a windows box for example) and will stop you from getting the exploit delivered to you (theoretically, assuming banning is faster than delivery, see one of my previous posts about the SSH exloit). The attack surface of your internal hosts is minimised, as well as the attack surface of the pfsense box (only accessible from lan side: webgui port/ssh/dhcp/ntp/other services you shouldn't be running on your core router (eg: freenas, as suggested)).That brings us to why you should be running internal snort interfaces (on dmz for example).
Now, hosts hostile to your network (any host that connects to a network not under your control, eg an android phone,iphone,tablet you take to work) should be isolated on a different interface (VLANs acceptable under extremely specific scenarios). Since those hosts have connected to a network not under your control, nobody can guarantee that an http session was not hijacked (Man In The Middle, MITM attack), and an exploit was delivered to it. A physical interface which only has internet access is acceptable for them.
Now, at some point in the undetermined future, the exploit decides to execute. Since the NSA was monitoring you, with the complicit help of your ISP of course, they already know you are running pfsense v2.1. They go through the documentation, and find out that the DHCP server running on that version is vulnerable to a known exploit, let's call it DHCPExploit. The exploit delivered on your phone (not DHCPExploit) is silently waiting, and the right time has come (you go home from work). Upon it's IP being refreshed, it starts executing the DHCPExploit. The ET guys though have known about this exploit and a snort rule is already in place. Snort sees the suspect traffic, and bans your phone from communicating with your pfsense box. In the NSA's words, an attack was thwarded, and the world is saved from the evil terrorists.
Snort prevents exploits (if they are known) from getting inside your network, as long as it has complete control over what goes in and out of the network. This is a reason I wet my pants everytime I read about the work being done to implement a suricata IPS on pfsense. It's one of my wet dreams coming true.In summary, if you only have interfaces connected to hosts you trust (wired, small number of hosts) you don't need an inward facing snort interface. If you have interfaces facing untrusted hosts (phones/customer's servers) then you need an inward facing interface. Again, this only applies to known exploits.
On the subject of IPs getting banned. Snort should be set up to ban both the destination and the source, AT ALL TIMES, UNDER ANY USE!!!. It should be also set up to know that it shouldn't ban itself. I'll give an example for a LAN type interface, but it also applies to a WAN type interface.
Network: 192.168.1.x
pfsense LAN interface IP: 192.168.1.1
Workstation: 192.168.1.2
Laptop:192.168.1.3
Evil terrorist: 1.1.1.1
Laptop receives exploit from evil terrorist
In this scenario, snort should be aware that it should not ban 192.168.1.1. IPs 192.168.1.3 and 1.1.1.1 were both banned (no traffic allowed for them). 192.168.1.2 still has access to 192.168.1.1, therefore still has complete network access.Laptop send exploit to evil terrorist (in case you work for the NSA, please consult me at the known telephone before handling dangerous cyber warfare weapons).
In this scenario, snort should be aware that is should not ban 192.168.1.1.IPs 192.168.1.3 and 1.1.1.1 were both banned (no traffic allowed for them). 192.168.1.2 still has access to 192.168.1.1, therefore still has complete network access.See? The same outcome for both scenarios, therefore snort should always be set up to ban both the source, as well as the destination IPs. If you have it set up any way differently than that, you are doing it wrong. Please inspect your whitelists and start using it as I say.
-
Using duplicate resources aside, monitoring both the WAN and the LAN provides more visibility for the security of your network. I am monitoring both sides and I will show you an example from this morning.
The alert in the attacheded jpeg (Alert Lan) shows an "ET Current_Events Blatantly Evil JS Function"
No Alert was generated on the WAN side. (Both Sides are using the same ruleset - Currently only the WAN is in blocking mode src/dst)If you are only monitoring the WAN side, this wouldn't have been alerted. (As the LAN made the request, you would assume that when the packets came thru the WAN side, that it would be picked up, but it doesnt always do that)
If you are only monitoring the WAN side, an Alert that is Blocked on the WAN, the only information you see is the SRC (Suspected Attacker) and the DST (Which is you WAN Address).
So which computer on your LAN side was the TARGET?The problem with only using Snort in pfSense is that things get blocked and you have no idea what it actually was. You always have to guess and use your best judgement.
As I have been using "Security Onion' for almost 3 months now, I can say that it provides more detail into what is occuring.
Take a look at the attached jpeg (SO Alert Transcript) Here is the same alert as was generated in pfSense Snort but showing the payload transcript of this alert.
Take a look at the attached jpeg (SO NetworkMiner) Here is the same alert and using "Network Miner", the file can be extracted from the Full packet capture system.
I can now conclude that this is a pull request from my mail server to Emerging Threats to get an RSS feed. The feed has some code about a threat that Snort suspects as a threat. However, this is not a false positive, as the Rule did find the correct string but it is a false alert in terms of being malicious.
I am still using pfSense snort, but am now using pfBlocker to block all of the obvious IPs before snort sees it. The WAN has block rules on the pfblocker aliases, and the LAN has Reject rules for the same pfBlocker aliases. Snort in pfSense has several disabled SIDs and Suppressions so that all alerts can be further investigated in Security Onion.
 -
Third Attachment
 -
@jflsakfja:
That brings us to why you should be running internal snort interfaces (on dmz for example).
Now, hosts hostile to your network (any host that connects to a network not under your control, eg an android phone,iphone,tablet you take to work) should be isolated on a different interface (VLANs acceptable under extremely specific scenarios).Can you elaborate on the possible use of a VLAN for this? Guess I'm trying to piece this together in my head without seeing the topology on paper…
Rick
-
Agree with you BBcan17, that's why I said only use 1 instance of snort if you are running 2 PCs. You do know which ONE of those PCs is currently connected to the network right?
Ideally you should be running PER HOST IPS systems, that is a system upstream of each host, that is then connected to the core router.
Some say "theoretically, theory and practice is the same. Practically they are not". I say "there are always exceptions to the rules, but never a rule to the exceptions".
To make myself clear: I have NEVER argued the use of an internal facing snort interface. I'm arguing its usefulness when running small networks that are trusted (wired, no external hosts entering the network at random). Rules not firing on WAN side and firing on the LAN side are to be considered DANGEROUS, not something you live and swear by. This is assuming the rule is NOT meant for use as a LAN side rule (yes there are rules that are only meant to be running on the LAN side). This particular rule SHOULD fire up on the wan side, based on what I see in the rule. The source is $EXTERNAL_NET, and the destination is $HOME_NET. Either one of those, or both, are missconfigured in your setup.
ramosel: Let's say you have a LAN, a WAN, and an ANDROID interface.
WAN should be obviously connected to a physical interface named WAN. LAN and ANDROID interface, can be on a VLAN tagged port, assuming that the management VLAN (the SINGLE port that allows you to change the switch's settings) is kept separate from them (separate, UNTAGGED interface). HP says a port that understands that it should pass traffic destined for different VLANs is a tagged port, and a port passing traffic for a single VLAN is an untagged port. Cisco insists they invented both ports.
So, 1 physical interface connected to the wan, one VLAN tagged interface connected to a managed switch's tagged port, which in turn "splits" the VLANs to different ports (3 ports always connected in this scenario, 1 only connected when you need access to the switch's management webgui, for a total of 4 connected ports).
The ANDROID interface is obviously connected to an access point for wifi access to the android phones. LAN is connected to the single host on your LAN. If you have more hosts, add more untagged ports on the switch.
Allowing the management VLAN to be on the same port that passes all network traffic opens you up to the possibility of a VLAN hop (and since the management VLAN is involved, complete control of the switch). How vulnerable your switch (AND your network topology) is to this, is another argument. -
@jflsakfja:
Now, at some point in the undetermined future, the exploit decides to execute. Since the NSA was monitoring you, with the complicit help of your ISP of course, they already know you are running pfsense v2.1.
;D
I just popped in to say 'thank you'. It is obvious you do know a lot, and it will take me a while to interpret all you write, but I do appreciate it very much that you take the time to share this knowledge.
Bye,
PS Yellow is not green. I repeat: yellow is not green. The goose is in the oven. I repeat: the goose has left the oven.
-
Thanks jflsakfja,
If you have the ram I would monitor both. I've seen strange things happen and the more info you have the better. But I agree with you on a small 1-2 desktop setup.
I am Port Mirroring ($60 Mikrotik) all of the traffic to/from pfsense LAN side. So anything on the internal side that hits pfSense gets monitored with Security Onion. I also have a Port Mirror on traffic going to/from my Server2008 ActiveDirectory DNS server. The beauty about Security Onion IDS is that you can have a Server/Sensor configuration, or a Server and hundreds of Sensor Depolyments. I have a third sensor at a remote location feeding intel thru a VPN tunnel back to the SO Server.
I have checked my $HOME_NET and $EXTERNAL_NET and they are set as "default". THe Whitelist and Suppression lists don't contain that Rule or the ET ip address. But I noticed in the rule that it has:
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any
I have set the $HTTP port var in pfSense to [80, 443]
I took a look at the payload transcript from Security Onion (Its in my orginal email)
SRC IP - Lan - Mail Server address
DST IP - 54.236.168.233
SRC Port - 56238
DST Port - 80I looked at the first 10 frames of the payload and the Src/Dst flips back and forth on these numbers.
The only other possibility could be that I am using a Virtual IP for the my second WAN address. I had to set it as a virtual address because both WANs utilize the same External Gateway. So I have configured Outbound NAT so that my outbound traffic from my mail server goes out the second address and I have port forwards to direct inbound traffic to the mail server for that IP Alias.
The Whitelist for Snort has "Virtual Aliases" on the list. But that should only stop the alias from being blocked.
Maybe the $EXTERNAL_NET needs to specifically reference the WAN IP and WAN Alias. I will need to test that out.
-
I Set the $EXTERNAL_NET to use an alias which has the two WAN addresses, but now am getting several alerts for
BAD-TRAFFIC potential dns cache poisoning attempt - mismatched txid
SRC (External DNS Provider) and DST (is my WAN address)
Does anyone know how to define the following? I cant enter that into the alias fields.
var EXTERNAL_NET !$HOME_NET
-
So I was right again?
Please post the sig_id for those rules, I'm not going to search until I find something that I think might be what you are looking for.
Don't forget that the DNS servers in use should always be whitelisted. It's not like you have a choice anyway. You either trust the DNS servers, or you don't. It's one of the reasons they don't let me finish the IPv8 draft (to those rolling their eyes, get real will you? Then get a higher access classification and study the CYCLOPS program). I decided that the DNS system should be replaced with a similar system as a bittorrent hash table. Works exactly like normal persons recognise known persons. If a number of people agree your face belongs to Jack Daniels, you sound like Jack Daniels, you move like Jack Daniels then you are Jack Daniels. Since I'm interested in the well being of the entire Internet community, I agreed to let them implement part of it in IPv7 (only the necessary parts for surveilance are implemented by them and butchered together, and it's one of the reasons Cisco will claim design for this, they are never wrong even when the shit does hit the fan).
Ouch, my head hurts but it was a necessary tangent we all had to read through. It shows why there are 13 DNS servers (masters) worldwide. Surveilance. And DNS poisoning. For the most part, nobody should be bothered by it, just trust your upstream DNS server. To the others, nothing to see here, move along.and let's see what we have for custom variables…
The easiest way is creating a new whitelist and assigning that to the external net and the home net. The defaults should work a ok, unless you are running a transparent bridge.
"var $EXTERNAL_NET !HOME_NET" doesn't look right. How about "var EXTERNAL_NET !$HOME_NET".
That goes directly in the custom.rules (where you edit the per interface rules, first option in the dropdown). Dunno if it will override the default (which should be what you are intending to do, puzzles me it doesn't work) but it definately works for other variables. I'm using it for my custom rules and is perfect for declaring custom variables.A tip on the correct usage for HOME_NET variable. This variable should include ALL your external IPs (saw you mention something about an alias) since it should recognise traffic destined for all your IPs. You can use subnets in the variable, eg: 1.1.1.0/24.
-
You were right on the WAN side not picking up the alert but …. I'll leave my other opinions alone ..lol.
You would think that to edit the HOME_NET and EXTERNAL_NET that you would do that in -
Snort Interfaces-WAN Settings, "Choose the networks Snort should inspect and whitelist."
The Drop Box links to the "WhiteList" Tab.
In the WhiteList tab, create a new List and at the Bottom enter an "Alias" which can be defined from the Firewall, Alias lists.
I created a new Alias for the External with the two external WAN ip's (all the checkmarks are whitelisting the others already?)
I created a second alias for Home_net and listed 192.168.0.0/16,10.0.0.0/8,172.16.0.0/12 (all the checkmarks are whitelisting the others already?)To enter these changes in Custom.rules would you need to use IPVAR instead of VAR? Not sure how this will affect the Whitelist?
ipvar HOME_NET [192.168.0.0/16,10.0.0.0/8,172.16.0.0/12]
ipvar EXTERNAL_NET !HOME_NET -
An easy way to check what is in the HOME_NET is to -
Snort Interfaces-WAN Settings, "Choose the networks Snort should inspect and whitelist." and choose "VIEW"
When its set to "default", all the correct entries are there including the WAN Alias that I setup previously.
(Not sure why the EXTERNAL NET doesnt have a "VIEW" button also?)If I enter the Alias entry as per my previous post it adds those aliases to the list correctly also.
So back to the drawing board on why that "Blatantly Evil JS Function" rule didn't trigger on the WAN side!!
[UPDATE]
EXTERNAL_NET should be set to "default" which is probably defined as "any".
To use "!$HOME_NET" (Still trying to see how to enter that in the alias field)
-
@jflsakfja:
You either trust the DNS servers, or you don't. It's one of the reasons they don't let me finish the IPv8 draft (to those rolling their eyes, get real will you? Then get a higher access classification and study the CYCLOPS program).
Holy smokes… I haven't seen mention of IPv8 for 10 or 12? years... Network geeks taking sides with Terrell or Fleming... lots of flame retardant underwear needed for that arena.
Rick
