Taming the beasts… aka suricata blueprint
-
1. Good idea on putting the Pass list into the IR_ category! Snort/Suricata processses a 'copy' of all the packets. So even if it was blocked by the Firewall, Snort/Suricata will still see it. Keep an eye on the Snort/Suricata alerts, and click on the "!" to see if the IP is listed or has the range blocked. I have noticed that over 90% of what Snort/Suricata Blocks is already being blocked by the Firewall Blocklists.
Hopefully when pfSense moves to 2.2 and they add NetMap api, it will allow a true-inline process for Snort/Suricata.
Thank you BB ;D
Ah, ok, so a package comes in, the firewall is the very first line of defense and in the millisecond it will take the firewall to block it, it will also send it to snort which will analyze it and will also block the IP - which is already blocked by the firewall.
So what we are doing right now is more or less a preparation for when 2.2. comes? As in: Jflsak sad he wants the firewall to do the work that the firewall can do, so Snort won't be wasting CPU (and speed) when not necessary. But if I understand you correctly currently that is still not the case, we will have to wait for 2.2, hence it is just 'preparing for'.
2. Suricata will load the Snort VRT ruleset except for about 600 rules. You can see that in the Suricata logs (which ones failed due to regex issues) I would still use the ruleset in Suricata.
(on another note, I still plan on staying with Snort for the time being)On that other note: why, if I may ask? I thought consensus was sort of Snort is no longer to be trusted?
3. I get them occasionally. Maybe Bill has some suggestions.
I hope ;D
-
Floating Rules are good if you have multiple interfaces, so you can define these in the Floating Tab so that they are in effect for several Interfaces at one time.
I am sure I am once again stupid, but: Interface Groups do exactly the same?
For example, I have MultiWAN, in which both my WAN's are. In the MultiWAN-tab I have set some rules that apply to both WAN's at the same time. Floating rules can do that too, so when would one use Interface Groups, and when would one use Floating Rules ???
-
@Hollander:
I wasn't clear enough, since I could hit geenstijl.nl, but not the movies they embed there. They are hosted on one of their other sites, dumpert.nl. And that one was blocked. The IP lookup turned out this was cloudflare. So I added a floating rule IR_PASS (which, magically, also appears in the dashboard widget :P ) that will use the IR_PASS alias to contain hosts that I might consider 'false positives'.
Just curious, btw, BB: why is cloudflare spamming you (or, better said: how?) I thought this was a reputable service? Obviously not, but I don't know why? I mean, large sites use cloudflare(?)
Here is what I show being blocked by that IP (IP may be different for you as cloudflare is a CDN and the IP could be different in your Country.
From these results, really makes you wonder if you would feel comfortable going to those websites? Note, the IPs below are from the ET Paid IQRisk Blocklist. No other lists show that Ip for me, so I am curious which list is blocking on your end?
grep "^141.101.116." pf/*
pf/ET_IPrep.txt:141.101.116.0/24
<snip>pf/e_tspywarecnc:141.101.116.17As an Economist, you should already know that answer ;) Money, Bones, Bread, Fins, Moola, Dinero
Why would they kicks spammers off of their network and lose revenue. Spread the word and block/boycott them all.
What happens is a Spammer sets up shop on a Hosting Service and Spams for as long as they can, after they get blocked, they move to another Hosting Service or just setup a new domain and new IPs. (Sadly, those IPs get recycled to some legit sites and people wonder why they are on a Blocklist when they just got these new IP addresses.)
I have had spamming issues from several Hosting Services HOSTNOC, OVH, Burstnet.
I am currently blocking the whole Burstnet network (3000 servers) as I was getting spammed for months without them doing anything about it. If you want to see how bad it is, take a look at this Google Group:
https://groups.google.com/forum/#!forum/news.admin.net-abuse.email
(and for a good laugh… ;D )</snip>Thank you ;D
I will use your CLI-examples to try and do that myself, and report back here what mine says for that site, dumpert.nl.
So if I understand you correctly the site dumpert.nl (part of a reputable news paper company group in The Netherlands) is not to be expected to be blamed, it is the fact that they are 'outsourcing' their hosting 'in the cloud' and the cloud provider is making a mess of it, hence risking dumpert.nl to be contaminated with crap ware.
-
I think both Snort or Suricata are both good options. The rules generally work for either, so the rules to disable are similar except for the Suricata Stream and other rules specific to Suricata. Suricata is a lot more involved and have a lot of new options not available in Snort.
I think the issue with Snort is when Cisco bought them, and the worry is that they close it to open-source at some time in the future. If that happens, everyone would either have to pay up, or switch to Suricata. As Suricata is harder to configure, getting it working now gets you ahead of the game.
So its all about choice and I think thats what Bill has said numerous times.
I think the Floating Tab also allows "Match" (instead of "pass", "Block" or "reject") these are necessary for things like Traffic Shaper to work. So if you use "Interface groups", I believe its probably the same in the end.
Yes lots of reputable sites do that. Take "Yahoo" as an example. Their site is laden with links to other sites and they are known to have issue for spyware excetera. But again, look at Yahoo's financial issues and they need the revenue.
Sometime, you visit a site, and it redirects to another IP just to popup an "Advert" or a drive-by installation of malicious software.
Also look at Dropbox, these malicious groups are using dropbox to push their malware as most people would assume anything from dropbox is safe? :o :o The next steps after IP blocking would be DNS Sinkholing or URL filtering, so that we can stop "known" URLs that lead to reputable sites but are still malicious.
-
@Hollander:
3. How do you get rid of all these log lines about traffic being blocked:
–- 255.255.255.255:10001 UDP
--- 239.255.255.250:1900 UDP
--- 224.0.0.252:5355 UDPThey were gone for months, but suddenly the log is being flooded with them again. Ever since I started with pfSense these lines appear to bug me every so many months.
Is snort/suricata blocking them or if it pfsense default block rule? if its snort or suricata, you can suppress them base on the rule that is being triggered:
#SURICATA IPv4 padding required
suppress gen_id 1, sig_id 2200007, track by_dst, ip 224.0.0.22 -
@Hollander:
I am sure I am once again stupid, but: Interface Groups do exactly the same?
For example, I have MultiWAN, in which both my WAN's are. In the MultiWAN-tab I have set some rules that apply to both WAN's at the same time. Floating rules can do that too, so when would one use Interface Groups, and when would one use Floating Rules ???
Floating rules are rules that can be active on multiple interfaces at the same time, by just merely CTRL+clicking multiple interfaces (extremely easy to add a new interface to an existing rule).
Not only that, floating rules are the first rules that are evaluated. Remember that rules are evaluated top to bottom (not only floating rules, ALL rules). pf(sense) starts from the top of the floating rules tab and works it's way down, then moves on to your interface's tab's top and works it's way down.
If you are going to block a packet, there is no need to pass that packet through the entire "firewall" stack. Passing it from rule to rule saying "does this match this rule?nope, move on to the next one" only to find out 100 rules later that "yes it does match this rule!hm, the rule says block, so I should throw this packet in the trash" will quickly guarantee that some networking "expert" out there will quickly tell you "spitWell there's your problem! You need an i3 for that", while in reality taking away bits and pieces from the work the system has to do makes even the slowest cpu you can afford, EXTREMELY capable. I've said it once, and I'll say it again: MOST people will NEVER need anything more than a p4/atom. You can't imagine the things that little atom box that could, well, could do (no pun intended).Floating rules help us in implementing these principles. The less work a system has to do, the more efficient it is at doing it.
A couple of years back I set up a couple of remote syslog servers at one on The Company's facilities. I was arguing to the networking/security "experts" (outside The Company) that I don't need a quad socket 12 cores per socket server to log a couple of damned lines. They kept saying "sysloging is one of the most difficult things you can do. Once you grow past a couple dozen of servers it will quickly bring down any server you throw at it", recommending about setting up at LEAST a single socket quad core CPU.
I was pointed at and laughed when I implemented the sysloging on a small ARM box, and curiously enough it kept up with the load. What they failed to see was that instead of requiring a dedicated power line to the sysloging servers, they each consumed less than 10W. A 24/7 10W load is NOTHING compared to what a recommended system would suck down. The trick to proving that industry leaders are complete and utter idiots is knowing your job and constantly thrive to be the best at it. The BEST! A "take no prisoners" approach to training/learning at your job, is the only secure way of achieving your goals.Oh, by the way, the trick to the ARM servers was filter the messages as early as possible (at the individual servers), then pass the actually needed logs on to the ARM servers WITHOUT passing them on to mysql. Ask yourself. Can I identify an attack/needed-to-identify-action using this line of syslog, merely by looking at it 5 years later? How about if I combine it with the lines above it and below it? If the answer is no, then that line should NOT be logged. It should be discarded as soon as possible (the start of syslog's directives is a great spot!). The EU Logging Standard (European Commission Information Systems Security Policy, Standard on Logging and Monitoring, page 12, technically page 11 section 8.4 Network Firewalls, continues to page 12) says to even log packets that are blocked by the default block rule. The multi-trillion $/€ question is: Why? There is no need to log those packets, since those packets will be discarded anyway. Log a single line per minute of those packets coming in. Then have the evidence that an attacker is still trying to penetrate/DoS your network. You keep the penpushers happy, and you keep your syslog servers happy. Logging 1 line is faster than logging 1,000 lines.
IF<<< (an infinitely huge IF,extremely likely this is NOT the case you are in) you need to analyze logs at the end of a time period for something particular, then import the logs in mysql all at once. If (an infinitely small if, almost a singularity, and most likely this IS the case you are in) you merely need logs to prove that IP 192.168.1.1 was poking at your ssh server, then you DON'T need to import the logs to mysql, EVER. Nope, not in a trillion years. A script grepping (zgrepping, why waste space?) your logs for a particular IP between 2 set time periods and spitting out the lines it's mentioned, is (educated guess based on my years of field experience) about 100 times faster than analyzing logs through a giant database containing billions and billions of logged entries. Yes a database system is designed for this. No you will NOT perform these lookups more than 3 times a day => you don't need the database system (and cluster, and load balancer that come with the contract).
Yet again we prove the industry leaders know nothing about the job they do. Yet again they will deny it, again and again. To keep a system performing at the top of it's potential, you need to KISS (not wanting to offend anyone, it's not directed at anyone in particular, well, maybe at the industry leaders, it's mentioned as in the KISS principle). Keep It Simple, Stupid. The KISS principle in the case of having to deal with multiple interface blocking type rules is:
- Evaluate those packets as soon as possible
- Simple to add/remove interfaces
- No need to duplicate rules to other interfaces.
In other words, floating quick rules :D
-
I'm over 25 years in the IT business as an engineer, consultant and many more functions, and I must say, you are so right.
-
@jflsakfja:
The trick to proving that industry leaders are complete and utter idiots is knowing your job and constantly thrive to be the best at it. The BEST! A "take no prisoners" approach to training/learning at your job, is the only secure way of achieving your goals.
Thank God I'm retired and no longer have to deal with this. YOU are SO right.
What I found to be most frustrating was that its not just the industry leaders… It's our/your own IT department VPs and AVPs too. Professional Executives who are the reason for PEBKAC and have NO IT history/experience. And some are such "utter idiots" that even when you prove them to be so, they don't see it. Don't confuse them with the facts, their minds are made up. And If you do get the upper hand on the point in case their fallback is always budget. Everything has to go through the budget filter. What they say: "We want to build the safest, most secure system for our customers". What they mean: "We want to build the cheapest, worst system we can get away with". And then when that wasn't enough... the real scumbag execs and lawyers brought in "arm's length". Don't listen to your talented "in-house" IT folks - Hire a consultant so when we do it "our way" (read cheap) and it does get compromised/falls apart/doesn't work, you can blame the consultant!!
Sorry, it was that time; Rant:30
<soap box="" mode="" off="">So now, I leave the training/learning to you folks and sit here and absorb it. Thank you. Its a pleasure.
Rick</soap>
-
@jflsakfja:
@Hollander:
I am sure I am once again stupid, but: Interface Groups do exactly the same?
For example, I have MultiWAN, in which both my WAN's are. In the MultiWAN-tab I have set some rules that apply to both WAN's at the same time. Floating rules can do that too, so when would one use Interface Groups, and when would one use Floating Rules ???
Floating rules are rules that can be active on multiple interfaces at the same time, by just merely CTRL+clicking multiple interfaces (extremely easy to add a new interface to an existing rule).
Your posts are always a pleasure to read, Jfl :P
As to your ARM-example; I do recognize it. I am an economist, but I have been involved in huge ERP-projects for over a decade. Trust me, ERP-projects need more economists; a retrained history student that suddenly, after 4 weeks of courses, is a 'senior financial consultant', can se-rious-ly mess up global ERP-projects in which we need to implement the full scale of accounting and controlling, all the way up to consolidation and hyperinflation accounting and resulting in financial analytics. If you want to have the servers and the ERP-systems to do that au-to-ma-ti-cally (which you want, if you have say a 1000 locations/100 different GAAP's/150 different currencies/ around the globe that need to report their results 3 days after month end), you don't get anywhere with a former history student that says that a simple journal entry is too complex and we 'need to discuss this on a higher, more strategical level').
Many times companies turned to me for second opinions on blueprints. For a simple reason: because they couldn't believe the crap all these 'global system integrators' were saying (and yes, these are the tens of thousands employees type of companies I am referring to :-[ ). The clients take them 'because they have global coverage' (needed if you have to do a global roll out), and then they are bravely waiting for their turn to be screwed. The biggest scam of all, the one I always saw returning, is that the blueprint consists, for 50-90%, of this line: 'not possible in the standard system, custom development is needed'. Then you have this situation: a Fortune500 company invests 500 million in the project (hardware (global, again), licenses, consultants to set it all up). Accepts that it will take 5-10 years to roll it all out. And after signing the contract finally, after a long and difficult, frustrating birth, gets a blueprint in which it is said that that top of the bill ERP-system can not send customer profitability in real time to the data warehouse. 'This is custom development, because the standard system can not do that'.
I've made many enemies over the years when I came in for second opinions: usually, I just made sure both the customer and the former history student-now 'sr. financial consultants' were in the same room, after which I opened a development box and customized the required functionality on the scene.
I've made ma-ny enemies over the years with all these 'integrators' who have 23 years old 'senior' punks on staff who know nothing except for saying that they have 'tens of thousands of years of experience' ;D ;D ;D
Of course, I also learned over the years that most VP's are either corrupt or incompetent or both; in the end, there's always somebody in the top who doesn't care about the truth, who doesn't care that the company is ripped off. You don't need to be an Einstein to understand what's behind that. (From an economical point of view, btw: it all boils down to ownership of the company. So called 'agency problems'. Nobody gives a sh*t if he is playing with not his own money, and gets away with it).
Anyway, so: I recognize your ARM-example all too well :P
If I may, JFL: as much as I agree with your point of view on doing things efficiently (I have to, I am an economist ;D ), sofar I still don't see a difference re Floating Rules versus Interface Groups: as easily as I can add an interface to a an existing Floating Rule, just as easily can I add an interface to an existing Interface Group (to which then the rules for that Group also apply). And since then the Floating Rule won't handle it but the Interface Group will, it is not a matter of pushing rules through the Firewall landscape, as the Floating Rule doesn't handle the packet, but the first stop will be the Interface Group.
You know by now that I am the eternal noob, famous for asking stupid questions ;D
-
@Hollander:
1. Does it make sense that if IR_PRI1 is blocking that Snort is also still blocking IP's based on Dshield (which is in IR_PRI1)?
You can "uncheck" these ET rules as pfIPRep already includes these lists. No need for Snort/Suricata to be looking at these. You should also enable the "Port Scanning Pre-Processor" to ban IPs that scan your IP for Open Ports.
I am sure that jflsakfja has already said to disable them, but I noticed from your post that you indicated "dShield".
(Pro Rules)
etpro-botcc.portgrouped.rules
etpro-botcc.rules
etpro-ciarmy.rules
etpro-compromised.rules
etpro-drop.rules
etpro-dshield.rules(These are discontinued and are blank, so you can skip these also)
etpro-rbn-malvertisers.rules
etpro-rbn.rules(Subscriber Rules)
emerging-botcc.portgrouped.rules
emerging-botcc.rules
emerging-ciarmy.rules
emerging-compromised.rules
emerging-dshield.rulesemerging-rbn-malvertisers.rules
emerging-rbn.rulesYou will also notice in the pfiprep script the Collect line for Snort/Suricata. This will load all of the IPs in those Rulesets and remove any duplicates. I am noticing that there are some IPs in these Rules that are not in their ET COMP, ET Block or ET IPREP. I have asked their support desk for the reason why, but still waiting for a reply.
So I would recommend enabling the Snort/Suricata (i386/AMD64) rule accordingly. Only need to have one of them enabled.
-
@Hollander:
If I may, JFL: as much as I agree with your point of view on doing things efficiently (I have to, I am an economist ;D ), sofar I still don't see a difference re Floating Rules versus Interface Groups: as easily as I can add an interface to a an existing Floating Rule, just as easily can I add an interface to an existing Interface Group (to which then the rules for that Group also apply). And since then the Floating Rule won't handle it but the Interface Group will, it is not a matter of pushing rules through the Firewall landscape, as the Floating Rule doesn't handle the packet, but the first stop will be the Interface Group.
I've always set up the floating rules instead of interfaces groups. If the rules are evaluated as you say (first, multiple interfaces,simple to maintain) then I'm assuming it's the same thing as a floating rule, minus the create a new interface group part before using it.
If someone more experienced says that's the way to go, then by all means I stand corrected and that's the way to go.
I posted the easiest way to achieve what we need to achieve, from my point of view. If others want to interject please go ahead offering your opinion, I won't bite :D
-
Abuse.ch has launched a new Blocklist service. SSL Blacklist (SSLBL) is designed to aid in detecting botnet traffic that uses SSL to communicate
You can add the conservative or aggressive IP Blocklist to pfiprep to help mitigate these SSL risks.
See the following link:
https://sslbl.abuse.ch/blacklist/Conservative IP list:
https://sslbl.abuse.ch/blacklist/sslipblacklist.csvAggressive IP list:
https://sslbl.abuse.ch/blacklist/sslipblacklist_aggressive.csv -
You can "uncheck" these ET rules as pfIPRep already includes these lists. No need for Snort/Suricata to be looking at these. You should also enable the "Port Scanning Pre-Processor" to ban IPs that scan your IP for Open Ports.
I am sure that jflsakfja has already said to disable them, but I noticed from your post that you indicated "dShield".
Thanks BB ;D
I have not yet disabled the Snort/Suricata rules, as doing that currently is cumbersome given the way this works (have to click each rule twice, wait for pfSense, etc: it will take hours and hours this way). JFL commented the same in his setup post, and asked if Bmeeks could change that. I understood from Bill that he will change it, so I awaiting that change.
-
Abuse.com has launched a new Blocklist service. SSL Blacklist (SSLBL) is designed to aid in detecting botnet traffic that uses SSL to communicate
You can add the conservative or aggressive IP Blocklist to pfiprep to help mitigate these SSL risks.
See the following link:
https://sslbl.abuse.ch/blacklist/Conservative IP list:
https://sslbl.abuse.ch/blacklist/sslipblacklist.csvAggressive IP list:
https://sslbl.abuse.ch/blacklist/sslipblacklist_aggressive.csvThat's great, BB ;D
The noob at it again: to which categories do you need to add these in the script? Simply copy line X in the script and change the URL?
-
I was wondering, is there some wisdom in what to enable on what interface? I know Bmeeks uses Snort both on LAN and WAN, albeit different kind of rules on both types of interfaces. Enabling on LAN makes sense as you can see which LAN client triggers an alert, enabling on WAN obviously makes sense to prevent stuff coming in. At the same time, it is said that setting the same rules on WAN and LAN is overkill, so I arrive at the question: which rules should one set on WAN, and which one on LAN?
Thank you from the eternal noob for the zillion-th time ;D
-
In order to determine what rules to enable for lan facing and wan facing interfaces, you need to go through the rules one by one, looking at their sources and destinations. I'm having a hard time keeping up as it is, imagine that as well :p
The easy way out is to enable 2 identical interfaces, one on wan and one on lan. We've already trimmed down suricata enough for that to run OK, assuming you have at least a decent amount of RAM (4GB).
Whether an internal facing interface is really needed, it's another question. Most "malware" rules have rules for both directions (in + out) so the wan one should spot something fishy easily. If you have multiple lan interfaces, that add yet another question. How will pfsense analyze traffic from LAN1 to LAN2? It needs an internal facing interface.
Questions, questions. Answer 1 and 1000 will pop up :p
-
@jflsakfja:
In order to determine what rules to enable for lan facing and wan facing interfaces, you need to go through the rules one by one, looking at their sources and destinations. I'm having a hard time keeping up as it is, imagine that as well :p
The easy way out is to enable 2 identical interfaces, one on wan and one on lan. We've already trimmed down suricata enough for that to run OK, assuming you have at least a decent amount of RAM (4GB).
Whether an internal facing interface is really needed, it's another question. Most "malware" rules have rules for both directions (in + out) so the wan one should spot something fishy easily. If you have multiple lan interfaces, that add yet another question. How will pfsense analyze traffic from LAN1 to LAN2? It needs an internal facing interface.
Questions, questions. Answer 1 and 1000 will pop up :p
Thank you ;D
Well, if the rulesets are available somewhere for import in MS Excel, and if I would really understand what I need to look for (the part in bold in your reply, which I don't quite understand yet, as in: what do I need to look for exactly?), I could try to filter out in Excel the rules that need to go on WAN, versus the ones that need to go on LAN.
I'm more than willing to attempt an effort at that, but you would need to give this noob slightly more detailed instructions on what to look for :P
-
Text copied from edit rules tab, so the columns are:
SID PROTOCOL SOURCE DESTINATION EXPLANATIONWAN facing rule:
2017397 http $EXTERNAL_NET any $HOME_NET any ET DOS Apple CoreText Exploit Specific string
Notice the red text in the source. It means a source that is not us(= every other on the Internet => WAN facing)LAN facing rule:
2017920 udp $HOME_NET 123 $EXTERNAL_NET any ET DOS Possible NTP DDoS Multiple MON_LIST Seq 0 Response Spanning Multiple Packets IMPL 0x02
Notice the blue text in the source. It means a source that is us (=> internally facing)BOTH facing rule: (WAN+LAN, must be duplicate)
2017919 udp any any any 123 ET DOS Possible NTP DDoS Inbound Frequent Un-Authed MON_LIST Requests IMPL 0x03
Notice the green text in the source. It means a source that is any(ie we are not sure if it's us or them) => it needs to be duplicated to both internally and externally facing interface/s. -
That's great, BB ;D
The noob at it again: to which categories do you need to add these in the script? Simply copy line X in the script and change the URL?
You can add a new line below the Abuse Palevo list as follows:
collect "$sch4" "AbuseSSLBL|tier1|https://sslbl.abuse.ch/blacklist/|sslipblacklist.csv|process|yes|yes|faf"
I am showing the conservative list in this example, you can also use the aggressive one if you choose. I am away until early next week so I can't provide any advice until I test it my self. There are not that many IPs in the aggressive file, so even if there are FPs, probably wouldn't be many to deal with.
In regards to disabling those rules. The ones I posted above, you can disable the whole category in the category tab for the WAN interface, you don't need to do this one rule at a time.
-
@Hollander, you have to jump in and learn some Linux CLI like the "grep" command. Google it and you will see how powerful this command is.
The rules files are located in these folders depending on your OS type and Snort/Suricata:
Snort64. /usr/pbi/snort-amd64/etc/snort/rules
Snort32. /usr/pbi/snort-i386/etc/snort/rules
Suri64. /usr/pbi/suricata-amd64/etc/suricata/rules
Suri32. /usr/pbi/suricata-i386/etc/suricata/rules
So as an example:
grep "$EXTERNAL_NET" /usr/pbi/suricata-amd64/etc/suricata/rules/*
Note to add a "" to escape special characters, as $ is used as a variable name.
