Taming the beasts… aka suricata blueprint

BBcan177

@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.rules

emerging-rbn-malvertisers.rules
emerging-rbn.rules

You 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.

A Former User

@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

BBcan177

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.csv

Aggressive IP list:
https://sslbl.abuse.ch/blacklist/sslipblacklist_aggressive.csv

Mr. Jingles

@BBcan177:

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.

Mr. Jingles

@BBcan177:

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.csv

Aggressive IP list:
https://sslbl.abuse.ch/blacklist/sslipblacklist_aggressive.csv

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?

Mr. Jingles

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

A Former User

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

Mr. Jingles

@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

A Former User

Text copied from edit rules tab, so the columns are:
SID PROTOCOL SOURCE DESTINATION EXPLANATION

WAN 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.

BBcan177

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:

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.

BBcan177

@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.

dgcom

If non-transparent proxy is being used, there is no real point in running Snort or Suricata with blocking enabled on LAN interface - all connections will be between internal hosts and LAN interface IP where proxy is listening. By default, those are whitelisted and if you decide to block internal hosts, you will cut off them from the internet completely…

Cino

@dgcom:

If non-transparent proxy is being used, there is no real point in running Snort or Suricata with blocking enabled on LAN interface - all connections will be between internal hosts and LAN interface IP where proxy is listening. By default, those are whitelisted and if you decide to block internal hosts, you will cut off them from the internet completely…

I'm not understanding this. Are you saying that they be able to alert correctly since they are going thru a proxy? I run a non-transparent proxy, using wpad.. Snort and Suricata have been alerting correctly and block external IPs when needed. During testing, ET Policy were the block of my alerts on the LAN interface..

dgcom

When internal client goes through non-transparent proxy, Suricata will only see internal IPs on LAN interface.
If there is some alert - let's say malicious JavaScript - it will alert, but since all IPs are local (ex. 192.168.1.1:55555 -> 192.168.1.1:8080), it won't block anything. For this to block, you have to catch this connection on WAN interface.

A Former User

@dgcom:

If non-transparent proxy is being used, there is no real point in running Snort or Suricata with blocking enabled on LAN interface - all connections will be between internal hosts and LAN interface IP where proxy is listening. By default, those are whitelisted and if you decide to block internal hosts, you will cut off them from the internet completely…

Are you talking about a transparent firewall running snort/suricata? There are uses for this, no it's not for everyone. By default snort/suricata has difficulty determining its IPs when running in transparent mode, so no hosts will be whitelisted. Ask yourself. What would you pick? System compromise or system getting cut off from the internet? If an internal server is infected somehow and starts spewing exploits here and there, the acceptable way of dealing with it is cutting off its network access. Care! There have been cases (supposedly) in the past where malware was (allegedly) designed to that if you pulled the ethernet cable it would start destroying the system's filesystem.

A transparent snort/suricata system comes in handy when you don't want hosts on the network being able to access it in any way. How will you attack the upstream gateway if you don't know there IS an upstream gateway?

dgcom

Hmm… I thought, I clearly wrote:

If non-transparent proxy is being used…

Let me try one more time - if you do NOT run proxy (Squid or anything else) in transparent mode - which means internal machine browser have to specify proxy in the browser, which, in turn, means that internal machine will connect to proxy in order to request any web page - in this case, running Snort/Suricata riles, which check any protocols, which proxy can rely (ex. HTTP, HTTPS, FTP) is possible in alert mode only. Even if you check to block, by default connections will not be blocked, because they are only between internal machine and LAN interface IP and those IPs are whitelisted by Snort/Suricata as internal network.

See example in the attached screenshot. In there, 192.168.15.56 is the internal IP of the pfSense, which has Snort listening on port 8080 and 192.168.15.174 is the client, receiving obfuscated JavaScript in the web response. Snort will not block this because all IPs are internal.

In this case, if such blocking is required, appropriate rules should be activated on WAN interface, but you will not see internal IP in the alerts.

Sample1.jpg_thumb

A Former User

Transparent or not the proxy will still not be blocked, since it's a known IP by snort/suricata. (WAN interface).

It will block the external host though, as long as it can see inside the protocol (ie no TLS).

If you want to block internal hosts, then just change the pass list to a different one. Snort/suricata will think all systems are to be blocked (even internal IP ones) if you have it listening on an internal interface.

EDIT:brain fart :p

dgcom

Transparent or not the proxy will still not be blocked, since it's a known IP by snort/suricata. (WAN interface).

Sorry, not sure I understand you - do you have your proxy listening on WAN interface?

If you want to block internal hosts, then just change the pass list to a different one. Snort/suricata will think all systems are to be blocked (even internal IP ones) if you have it listening on an internal interface.

What is "it" in here? Proxy?

Entire internal network is in the pass list by default.

A Former User

Snort/suricata WAN interface. No matter what proxy you run internally, eventually it must connect to the outside to pull data in. That's when the alerts will fire up. Snort/suricata will try to ban both source+destination (if you did not set it up like that, you should) and since the destination (proxy) is listed on its (snort/suricata's) pass list, it (proxy) will not be blocked. The outside IP will though.

WRT the listening, I was talking about snort/suricata.

"Entire internal network is in the pass list by default." I am aware of that, that's why I said change the pass list. If you tell suricata these are the networks you should NOT ban, but do NOT include the private IPs in that list, suricata will notice the alert, check to see if a private IP is on the pass list, NOT see the IP there, therefore will proceed to ban the internal IP. Most likely the proxy (pfsense) will be banned as well, so that IP should be on the pass list.

If I still fail to see the point, my apologies, it was a long day.

dgcom

Yeah, I think we speak different languages.

I am not talking about WAN interface, not sure why you brought it in.

I am talking about Snort/Suricata instance on LAN interface. In case of non-transparent proxy it does not see external IPs, period.