RFC (make up a number not in use) - Blueprint for setting up snort + pfblocker
-
@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
-
@BBcan17:
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_NETYes that's how you add aliases (add a whitelist).
Yes it does need to be defined in the scope that you use it, eg portvar for ports, when used in custom.rules.
As long as you have the loopback,all the networks (10.0.0.0/8, which brings me to what are you doing with a /8 and a /16? routing for a whole country?), the dns servers, and the public IPs (preferably with their subnet) HOME_NET should work. That's what it's supposed to do on its own when setting up the list automatically.
Who in here doesn't believe that the draft for IPv8 is in the process of getting completed? Mark my words, preferably chisel them in stone, just in case the EMP knocks out all technology: IPv8 will use a distributed DNS system, and will force only encrypted connections from host>host. Do NOT forget I told you that, 15 years before it was implemented.
Joe says that Jack is Jack, Joshua says that Jack is Jack, Daphne says Jack is not Jack. Per the NTP website (which I WILL NOT sideload, please go and read it there if you don't believe me), a person with a single watch knows the time, but a person with two watches is never sure.
-
@jflsakfja:
[Who in here doesn't believe that the draft for IPv8 is in the process of getting completed? Mark my words, preferably chisel them in stone, just in case the EMP knocks out all technology: IPv8 will use a distributed DNS system, and will force only encrypted connections from host>host. Do NOT forget I told you that, 15 years before it was implemented.
[/quote]Not saying IPv8 draft isn't being worked… But isn't the IPv8 address space 43bit? With IPv6 rolling (at 128bit) isn't there going to be a reluctance to move that direction even if the draft is being completed? Or will the IPv8 draft be worked to fit inside the IPv6 address space?
Rick
-
Not saying IPv8 draft isn't being worked… But isn't the IPv8 address space 43bit? With IPv6 rolling (at 128bit) isn't there going to be a reluctance to move that direction even if the draft is being completed? Or will the IPv8 draft be worked to fit inside the IPv6 address space?
Rick
IPv8 will not have addresses in the traditional context. Your domain is your address. Hosts join a domain based on what hosts trust they belong in that domain. If the hosts trusted to be authoritative for that domain trust the new host, then it is added to the domain, and they in turn announce to other hosts that a new host has joined. Not authoritative hosts then query the new host, and if they determine that the host truelly belongs in that domain (based on how routing to the host is done, its personal key, and a few other factors), then they start adding it to their tables. Hosts can then query any host for any host, and then agree on a key exchange (for the mandatory encrypted connections). If your host and my host agree that the keys other hosts delivered (multiple hosts) belong to each other, then your host trust my host, queries the dns for how to directly get here, then cut all other hosts from the communication and set up the encrypted connections. In the future, it first queries my host, and if the host responds OK, new connections are set up. If the host doesn't respond, then a new query is done for my host. Think of it as failover at the dns level.
In the rare occurance that a hostile host is added to a domain (all the first level failguards failed) then the authoritative hosts are no longer trusted for adding new hosts to their domain. There is a process to trust them in the future, but their credibility is reduced. After a certain threshold, those hosts are no longer trusted.It's an extremely complicated system to explain, and the only thing I can say helps in the explanation is that the dns is part of the IP (Internet Protocol, not IP addresses).
-
I jokingly used your JF initials a few posts back… if you are not JF, you certainly have read his stuff and are following his path!
If you are JF, damn glad to know you are still around. Read a lot of your stuff in years gone by.Rick
