Taming the beasts… aka suricata blueprint

squatch04

Hey jflsakfja, or anyone else for that matter….

First off please forgive my ignorance as i am still very much trying to learn all this.

As stated by jflsakfja and on the pfSense Firewall:Rules section, "Everything that isn't explicitly passed is blocked by default. "

Well i followed the guidelines for creating rules and added only rules for ports that my home network uses.

I intentionally did not create rules for Samba shares and ICMP but i could still access my windows network shares and i could still ping internally (but not externally).
I realised that there was a couple of auto created rules in my firewall:NAT:Outbound, most likely created using the pfSense startup wizard and the OpenVPN server wizard.

| WAN 10.0.1.0/24 * * 500 WAN address * YES Auto created rule for ISAKMP - LAN to WAN
WAN 10.0.1.0/24 * * * WAN address * NO Auto created rule for LAN to WAN
WAN 127.0.0.0/8 * * * WAN address 1024:65535 NO Auto created rule for localhost to WAN
WAN 10.0.8.0/24 * * * WAN address * NO Auto created rule for OpenVPN server |

What's your advice on these rules? should i disable them? can the rules be fine-tuned to be "less vague"? My assumption is that these rules could circumvent the more fine-tuned floating and interface rules created using this thread guidelines?

A Former User

NAT rules shouldn't have an impact on the effect of other rules, as long as the NAT rules didn't automatically create other allow rules (the case for port forwarding for example).

If you didn't create any rules for samba+ICMP, but you can still use those internally, then a rule exists somewhere that allows it. I've seen a couple of posts lately that pfsense allows things it shouldn't allow. That always comes down to misconfiguration issues.

When trying to troubleshoot pfsense, please put yourself into pfsense's place. What would you do with a packet if you followed the rules below:

floating rules first
per interface rules next
NAT rules
general block everything rule

Follow the rules through that order, and I'm sure you can find out what the problem is.

squatch04

@jflsakfja:

NAT rules shouldn't have an impact on the effect of other rules, as long as the NAT rules didn't automatically create other allow rules (the case for port forwarding for example).

If you didn't create any rules for samba+ICMP, but you can still use those internally, then a rule exists somewhere that allows it. I've seen a couple of posts lately that pfsense allows things it shouldn't allow. That always comes down to misconfiguration issues.

When trying to troubleshoot pfsense, please put yourself into pfsense's place. What would you do with a packet if you followed the rules below:

floating rules first

per interface rules next

NAT rules

general block everything rule

Follow the rules through that order, and I'm sure you can find out what the problem is.

I will do that, thanks jflsakfja!

raab

So I've setup the pfIPRep rules per Cino's method here https://forum.pfsense.org/index.php?topic=78062.msg427132#msg427132

Testing an outbound rule, for example 141.101.116.122 is in IR_SEC1 and I can still ping it even though my LAN and DMZ are selected

If I select WAN then it gets dropped accordingly, why is this?

Ticking Quick also drops it, do I need to have quick ticked for all the rules?

Cino

Check Quick. I forgot to update the screenshots with that.. Without it check, it will compare the rest of your rules and the last one will win.. Which is probably the default allow all lan rule. When Quick is checked, and there is a match; it will apply that rule and stop processing the rest for that packet.

raab

@Cino:

Check Quick. I forgot to update the screenshots with that.. Without it check, it will compare the rest of your rules and the last one will win.. Which is probably the default allow all lan rule. When Quick is checked, and there is a match; it will apply that rule and stop processing the rest for that packet.

Cool, thanks for that. You're right, I just have the default LAN to ANY rule so that makes sense.

Should I have quick checked for inbound rules or just the outgoing ones?

Cino

Quick for all. This way, once there is a match (inbound or outbound) the rule will block/reject the packet right a way.

raab

@Cino:

Quick for all. This way, once there is a match (inbound or outbound) the rule will block/reject the packet right a way.

Sweet, that's what I've done, thanks for that.

Now to tackle Suricata.

Just of note, I initially tried this with 2.2-BETA but every time you modify firewall rules or aliases the tables seem to clear. At the time I didn't have quick checked so I'm unsure if it was just a gui problem (as I could still ping that same IP so assumed it was broken) but the only way to get the tables back was to run pfiprep killdb

I also had problems with downloading lists from some https sites with fetch, similar to another user a few pages back yet unsure what a self signed pfsense cert had to do with it. I had ca_root_nss installed and /etc/ssl/certs.pm was symlinked to ca_root_nss.crt from memory

raab

Been having fun with Suricata (sarcasm)

Whenever I'm using Astrill VPN to stream Netflix I get these alerts:
SURICATA IPv4 invalid checksum - 09/29/2014-22:44:21
GPL SHELLCODE x86 setuid 0 - 10/02/2014-20:39:23

Ended up adding the VPN IP to a pass list

Trying to download the Windows 10 Tech Preview ISO's from Microsoft today and I got these alerts:
ET INFO EXE - Served Attached HTTP - 10/01/2014-01:10:39
ET POLICY PE EXE or DLL Windows file download HTTP - 10/02/2014-01:10:38
ET POLICY Download Windows Help File CHM 2 - 10/02/2014-11:42:05

They were .iso files downloading via http so I don't understand those alerts

Then once I'd upgraded my Windows 8.1 -> 10 it failed to connect to my microsoft account because of this alert:
ET POLICY Internet Explorer 6 in use - Significant Security Risk

Fun and games, haha.

A Former User

You didn't ask suricata nicely, that's why it's behaving badly. Most of those alerts are known FPs, as per the list linked to in this thread. Never add something that gives up an alert to a passlist. A passlist should only contain systems under your home net and DNS servers. Not a single host more than that. In other words, it should contain the bare minimum of systems that should NOT be banned, under any circumstance. Can you imagine what would happen if suricata decided to ban the DNS servers?

If a rule repeatedly gives a bad alert on known good traffic, suricata isn't the one that must be blamed. It's the rule writer that must be blamed and held accountable. Bug him until he changes the rule. Judging by ET's past record, it's not going to happen any time soon, but one can only hope.

Please remove the host from the passlist and disable the rules following instructions in this thread.

raab

Appears I missed one alert that was in your list, however these aren't in your list:

SURICATA IPv4 invalid checksum
GPL SHELLCODE x86 setuid 0
ET POLICY Download Windows Help File CHM 2
ET INFO EXE - Served Attached HTTP
ET POLICY Internet Explorer 6 in use

Also this is another alert I was getting downloading those iso's
ET EXPLOIT Windows Media Player parsing BMP file with 0 size offset to start of image

I'm certainly not blaming suricata, I completely agree with you that some of these rules are absolutely ludicrous..

I've removed the passlist and disabled the rules instead

A Former User

Too long night, too short day ;D

Those not on my list doesn't necessarily mean they are not false positives. Don't remember if it was in this thread, or the other (snort blueprint) that someone mentioned the ipv4 checksum one.

My list is the starting point, I can't possibly cover all the use cases out there. Adding to the list rules that come from external sources (other than me) means adding yet another layer of management to the list, something I currently do not have time for. For example I promised a new thread using the new auto management files, and guess what, haven't had time to even begin typing it yet.

This thread described the process of identifying FP rules, and how to deal with them. I'm not attacking you in any way, I'm just saying that a passlist is not the solution for this specific problem. Disabling the rules if you know the alerts are coming from a trusted source, is. If a rule is repeatedly found to be an FP rule, then the rule maintainer has the obligation to correct it, if everyone bugged them about it. He can't correct something that he doesn't even know is wrong. He must correct it though, if others tell him that it's wrong. As was mentioned, don't hold your breath on it when dealing with the ET rules. There are 10 year old rules in there that I have been personally screaming at the writers to remove, for years.

Then there are the "write once, never maintain rules", eg: NT 6.1. As mentioned, directed at ET, "FFS windows 7 IS 6.1, get it into your thick skulls and delete the rule already". Windows 7 was RTM'd on August 6 2009. That's 5 years of a rule FPing, and still counting, since as far as I can tell, they don't plan to correct it. 5 years of people telling you "you are doing it wrong", yet you still don't correct it. :o

raab

Haha tell me about it.

Don't worry, I'm not taking offence and know you weren't attacking me. I'm thankful for this thread and the work that you've done with your list.

Cheers for pointing out that I should be disabling rules if I'm certain its legit traffic, rather than using a pass list

A Former User

I have finally found a bit of time to work on the next part of this guide.

Roadmap:

Provide an easy way to upload minimal configurations to pfsense and get it going. Thanks to bmeeks for implementing the behind the scenes work needed for this. What would everyone's suggestion be as to the absolute bare minimum rules? Rules that generally cause mayhem when used, or add even more "delicate" rules (rules that might trigger an FP from akamai for example).
Provide the customizations recommended in this topic as an easily uploaded file/s
Start work on custom rules for the typical pfsense+suricata usage (network gateway). This came as an inspiration after having been bitten countless times by rules not making any sense at all. That and the push towards more encryption everywhere, which renders most ET rules invalid (not saying a bug, saying that suricata can't see inside the SSL traffic). Not saying that it will be the end-all-be-all configuration, it's just a minimal configuration that will do a hell of a lot more than what the default rules do. YMMV
Since this is also a taming pfsense topic, start work on an easy way to push server banned IPs to pfsense for immediate addition to a blocked alias (or an alias to direct traffic to a "YOU HAVE BEEN A BAD, BAD BOY" page). I don't like the way I'm currently implementing this, because I believe it's dangerous to pfsense's security (you need ssh access to it from the servers, even on limited access things can go wrong), and so I want the community's input on how to best implement it. poke poke if only the pfsense devs would add a customizable update schedule to the URL tables…poke poke
I'm willing to put up with a few seconds delay if pulling in the updates instead of them getting pushed forcefully to pfsense is easier (and it should be a lot safer).
Undecided, but we do have to burn a bit of company time if they are sponsoring me working on all of these, so anyone that wishes to add something they would like to see, feel free to do so.

The way forward I believe is to publish the "main" topics on github, and keep discussions here. That makes it easy to keep track of changes (and actually see the changes) and keeps the topics well, on topic (discussions about pfsense+suricata). Anyone objecting to this should speak up now or forever hold their silence.

Sorry to disappoint certain people by not insulting anyone, but I'm tired :-\

Mr. Jingles

@jflsakfja:

Sorry to disappoint certain people by not insulting anyone, but I'm tired :-\

;D ;D ;D ;D ;D

@jflsakfja:

The way forward I believe is to publish the "main" topics on github, and keep discussions here. That makes it easy to keep track of changes (and actually see the changes) and keeps the topics well, on topic (discussions about pfsense+suricata). Anyone objecting to this should speak up now or forever hold their silence.

Message copied, Roger, I do not object, not at all, but I am to shut up in the future anyway I read ( ??? ;D )

(I don't object at all, aux contraire, because now the information has been shattered over more than 1 thread - other people adding to your work too - and I had planned a couple of hours to find out where is what these days in the first place)

@jflsakfja:

Undecided, but we do have to burn a bit of company time if they are sponsoring me working on all of these, so anyone that wishes to add something they would like to see, feel free to do so.

Yes, I have, but I have to find the note where I wrote I down.

A Former User

The main problem I see is that you can't edit the old posts. I would love to add more information to the topic as things move forward/things change, but I simply can't do so in an organized way. Expecting everyone to go through 100 pages of posts is not exactly user intuitive ;)

I also enjoy seeing people take over the "technical support"/troubleshooting for other users. It means at least a few understood what the topic is trying to do, how to do it, and are willing to contribute to it ;D. The downside to that, is that updates to the topic get pushed further back in the thread, which takes us back to the "trying to keep things organized" subject. Having the main topic be outside the thread would (IMHO) help with keeping discussions/insulting-"innocent"-passers-by organized. For example, we could have a "ridicule the industry leaders week" (*see note) without affecting the actual guides.

I'm looking at you Google, time to take your own advise** and migrate away from SHA-1 certificates on your selected sites, eg www.google.com.cy (at time of writing:PKCS #1 SHA-1 With RSA Encryption). Especially when you yourself are a CA and can just sign a new certificate with no cost, other than the 2 minutes it takes to generate/re-issue/sign a new certificate and change/revoke the old certificate. Or you can take my advice, if you think that your depreciation policy is adequate. I've been screaming since March (this year) that everybody had plenty of time to migrate away from the old (and weak) certificates, time to force everyone to move on. As usual, no industry leader should listen to the "who-the-f***-are-you" random bloke on the Internet.

**http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html which brings us to ***

***9 years is indeed a lot of time. That's why for the past few months I've been literally (not just using the word without any context), literally SCREAMING at the CAs to force everyone off the old certificates already FFS (my exact words). which takes us to ****

**** Comodo just recently (after the Heartbleed security feature*****, and after 2 all round re-issues) has finally decided to force SHA-2 certificates.

***** In open source, bugs are not bugs. They are features. A bug introduced in the most respected (previous to the Heartbleed bug, now (as the Cypriot saying goes) not even dogs will piss on it) cryptographic software would imply that someone was directly paid to put it there. Especially when the ZOMGWTFNEW1337FEATURE is not needed. We wouldn't go around accusing anyone of getting paid to subvert security software now, would we? Of course not, don't be silly. The bloke accidentally introduced a "spil your guts out" feature. See? Only open source can offer you 2in1 features****(something, lost count)

****(something, lost count) to RMS and gang: I'm a die-hard open source supporter.

Cino

Here's a laugh for you…

So I'm browsing around http://suricata-ids.org and click on their News - Planet link http://planet.suricata-ids.org/


TCP  Potentially Bad Traffic  96.43.130.12 80  x.x.x.x 38263  1:2100498  GPL ATTACK_RESPONSE id check returned root

gotta love it

A Former User

@Cino:

Here's a laugh for you…

So I'm browsing around http://suricata-ids.org and click on their News - Planet link http://planet.suricata-ids.org/
TCP  Potentially Bad Traffic  96.43.130.12 80  x.x.x.x 38263  1:2100498  GPL ATTACK_RESPONSE id check returned root
gotta love it

Analyzing the packets just before the website was blocked brings us to this: (code tags not added because they interfere with my red emphasis)
–---------------------------------------------------------------------------
"Lets kick it up notch.....

We want to search through -

all the generated alerts that have
a printable payload data
that have the following string: uid=0(root)

Easy, here is the query:

payload_printable:"uid=0(root)"

You should enter it like this in Kibana:
[–---------------------------------------------------------------------------
The rule says this:

msg:"GPL ATTACK_RESPONSE id check returned root"; content:"uid=0|28|root|29|"; classtype:bad-unknown; sid:2100498; rev:7;

The rule is not an FP rule, but a DANGEROUS FP rule. Rules based on plaintext should be banned by legislation. They are the kind of rules that wake you up in the middle of the night when it starts hitting the fan.

I'll add the rule to the list, as well as make the small correction you pointed out on github.

While we are at it, does anyone have anything to say on the proposed way forward as mentioned in a previous post of mine?](http://2.bp.blogspot.com/-u81HF0TVrr4/U_C1BmpQdwI/AAAAAAAAAhU/dJdR8iAQk-k/s1600)

Cino

I didn't have time to look at the packet capture but I will over the weekend. You explaining it is a good example on how rules are triggered by Suricata.

I think your proposed way going forward will work. Maybe start a new thread linking to github while posting links to this thread and the snort one for background info. Ideally it would be nice if we could just edit post like every other forum out there…

BBcan177

@Cino:

Here's a laugh for you…

So I'm browsing around http://suricata-ids.org and click on their News - Planet link http://planet.suricata-ids.org/
TCP  Potentially Bad Traffic  96.43.130.12 80  x.x.x.x 38263  1:2100498  GPL ATTACK_RESPONSE id check returned root
gotta love it

I have similar Alerts when Emerging Threats or Snort posts details of a rule in any of their Newsletters.

Instead of suppressing SIDs, i would probably suppress these Sites to avoid FPs.