Snort 2.9.2.3 pkg v. 2.5.0 Issues

Fesoj

Which sides are you blocking on the WAN interface? If you block src and dst you can effectively shoot yourself in the foot. It seems that snort 2.9.2.3 has more sensitive preprocessors and I had to suppress a few more rules for my box compared to 2.9.0.x.

So looking at the alerts should tell you whether your WAN IP was part of an alert message. My 2.9.2.3/2.5.0 box has currently an uptime of more than 7 hours with typically about 5 clients and everything looks fine.

dwood

Blocking src only, kill states and checksum enabled. The WAN IP being blocked was x.x.x.0 effectively blocking everything over that connetion. My uptime was several hours, about 20 users before the alert was triggered. I had to remove Snort but can throw it back on later for a log if required. My concern was IP6 blocking as I need to learn more about IP6 before I'm able to manage it on a router ;-)

Cheers
D.

mschiek01

@Fesoj:

Which sides are you blocking on the WAN interface? If you block src and dst you can effectively shoot yourself in the foot. It seems that snort 2.9.2.3 has more sensitive preprocessors and I had to suppress a few more rules for my box compared to 2.9.0.x.

So looking at the alerts should tell you whether your WAN IP was part of an alert message. My 2.9.2.3/2.5.0 box has currently an uptime of more than 7 hours with typically about 5 clients and everything looks fine.

Same here source only with "kill states and checksum" both selected. This has now happened on multiple installations. Some installations have static wans others have dynamic. I do not see a common pattern at all.

uptime on boxes varies from days to weeks. I have turned off auto updates for snort rules as well. Still have not found a common thread.

Fesoj

On the WAN side, I am blocking destination addresses only (because offenders are typically coming from the inside, and I want to block their outside contact on the WAN interface, but there is a corresponding handling on the LAN side to vet my clients :(). Of course this depends on what you actually want to block and which rules are active.

You need to look at each rule, if the source is s.th. like $HOME_NET, then you might have to do the blocking on the LAN side, maybe sometimes you could simply suppress the alert.

mschiek01

@Fesoj:

On the WAN side, I am blocking destination addresses only (because offenders are typically coming from the inside, and I want to block their outside contact on the WAN interface, but there is a corresponding handling on the LAN side to vet my clients :(). Of course this depends on what you actually want to block and which rules are active.

You need to look at each rule, if the source is s.th. like $HOME_NET, then you might have to do the blocking on the LAN side, maybe sometimes you could simply suppress the alert.

I agree with you but, this is the alert trigger right before snort blocked the wan ip.

Jul 17 13:28:04 snort[40189]: [1:2500062:2570] ET COMPROMISED Known Compromised or Hostile Host Traffic TCP (32) [Classification: Misc Attack] [Priority: 2] {TCP} 59.175.218.166:31157 -> nn.nn.nn.nnn

This clearly show the source is 59.175.218.166 but snort blocked the wan ip instead.

eri--

Fixed on 2.0.x you can just upgrade in 10 minutes.
You need a new binary.
The match of the ip against a CIDR net specification was being done wrong.

Other than that it should behave now and you WAN shouold not be blocked.

The only thing i am not sure is since HOME_NET contents are used for whitelist of alert_pf maybe that is a bit wide as whitelist by default?
Probably just put listening interface IP all gateway/dns/vpns(what was clicked) and no include the CIDR and theother interfaces!

EDIT: 2.1 is still building.
EDIT2: There is a method to specify that the binary should be reinstalled but it would mean for us to keep a copy of each and every freebsd port that pfSense has pkg.

Fesoj

The only thing i am not sure is since HOME_NET contents are used for whitelist of alert_pf maybe that is a bit wide as whitelist by default?

Yes, I see what you mean. You need to be able to block entries from the HOME_NET. E.g. if a company policy says no to eMule, Bittorrent, etc., then it makes sense to block local machines on the LAN side, which is sometimes better than reporting with subsequent hard consequences… So, I'd say HOME_NET is not necessarily white.

UPDATE: ... but gateways, DNS servers, WAN side ips probably should.

Cino

@ermal:

but i did another (de)install, saved every paged.. then rebooted

That is not necessary anymore Cino :)
Everything will just get magically applied.

Good to know!!! Old habit from the old days

@ermal:

Fixed on 2.0.x you can just upgrade in 10 minutes.
You need a new binary.
The match of the ip against a CIDR net specification was being done wrong.

Other than that it should behave now and you WAN shouold not be blocked.

The only thing i am not sure is since HOME_NET contents are used for whitelist of alert_pf maybe that is a bit wide as whitelist by default?
Probably just put listening interface IP all gateway/dns/vpns(what was clicked) and no include the CIDR and theother interfaces!

EDIT: 2.1 is still building.
EDIT2: There is a method to specify that the binary should be reinstalled but it would mean for us to keep a copy of each and every freebsd port that pfSense has pkg.

i'm leaning to agree also.. interface IPs/gw/dns/vnps are the way to go.. If we need to add the subnet, then we manually do that via a whitelist. With the added Alias feature in snort, shouldnt be a big issue… Unless whitelist can't accept CIDR (which it noted it can't, haven't really tested that)... then there would be issue if you want to exclude a whole subnet (VPN, IPv6 Subnet)..

idk, maybe by default HOME_NET would just be interfaces, then add a couple of options within whitelist/netlist page to add interface subnets also.

dwood

Fired up 2.5.0 on two different installations (AMD64, 2.0.1) So far, so good.

Ermal, can you sort blocked IPs the same as in the alerts? Alerts on both interfaces are listed so the most recent is at the top of the page (perfecto), however blocked IPs are randomly sorted.

Question: With all the new suppression entries required, is there a way to add a descriptor above each suppress entry? I notice the add feature from the alerts list leaves a space between each entry added to the suppress list. Could find nothing on this one in the docs.

Cheers,
Dennis.

Cino

@dwood:

Question: With all the new suppression entries required, is there a way to add a descriptor above each suppress entry? I notice the add feature from the alerts list leaves a space between each entry added to the suppress list. Could find nothing on this one in the docs.

sure:


# **** Main Suppress List ****
# ****************************
#
# HTTP INSPECT Suppress
#
# DOUBLE DECODING ATTACK
suppress gen_id 119, sig_id 2
# suppress gen_id 119, sig_id 3
# NON-RFC DEFINED CHAR
suppress gen_id 119, sig_id 14
# suppress gen_id 119, sig_id 19
# suppress gen_id 119, sig_id 32
# suppress gen_id 119, sig_id 31
# NO CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE
suppress gen_id 120, sig_id 3
# HTTP RESPONSE GZIP DECOMPRESSION FAILED
suppress gen_id 120, sig_id 6
# INVALID CONTENT-LENGTH OR CHUNK SIZE
suppress gen_id 120, sig_id 8

Cino

If I disable all my suppression rules I'm able to reproduce the WAN IP blocking on the fly.. I did notice that new snort binary was built at 2012-Jul-17 21:37:45. Did this include the changes you made or will the next will?

miles267

What happened to the snort Whitelist UI screen? It used to allow you to input into unique dialog boxes a description and IP or CIDR. No all Alias IPs are crammed into a single, narrow dialog box. This seems like a step backward.

dwood

Thanks Cino :-) Just what I was looking for.

Miles, create an Alias list for your IPs. (under Firewall - Aliases). Then reference that alias in your whitelist. As soon as you start typing the name of your alias it will autofill in the whitelist box.

miles267

@dwood:

Thanks Cino :-) Just what I was looking for.

Miles, create an Alias list for your IPs. (under Firewall - Aliases). Then reference that alias in your whitelist. As soon as you start typing the name of your alias it will autofill in the whitelist box.

Thanks so much dwood. This is a great tip. I didn't realize it changed and that you can use these alias lists.

dwood

Miles, no worries. Ermal is the guy you need to thank for cooking up the code :-)

Ermal, I've noticed that when using the Alerts - Add to Suppress List feature, the signature is correctly added to the suppress list, but with a blank line preceding it. I've also observed that Snort will fail to start if there is a blank line in the suppress list. A bug?

Cheers,
Dennis.

dwood

After an automated update:

Jul 18 01:05:10 php: /snort/snort_interfaces.php: Interface Rule START for CABLE(re1)…
Jul 18 01:05:10 snort[46927]: FATAL ERROR: /usr/local/etc/snort/preproc_rules/sensitive-data.rules(1) Unknown ClassType: sdf
Jul 18 01:05:10 snort[46927]: FATAL ERROR: /usr/local/etc/snort/preproc_rules/sensitive-data.rules(1) Unknown ClassType: sdf
Jul 18 01:05:10 snort[46927]: Initializing rule chains…
Jul 18 01:05:10 snort[46927]: Initializing rule chains…

and with sensitive data rules toggled off, starting snort fails with this:

Jul 18 01:08:35 snort[219]: FATAL ERROR: /usr/local/etc/snort/preproc_rules/preprocessor.rules(201) Unknown ClassType: sdf
Jul 18 01:08:35 snort[219]: Initializing rule chains…

digdug3

@dwood: had the same problem.

Just removed and reinstalled with the latest binary and all is working again.

@ermail: is it possible to add the snort build number/date somewhere in the GUI? This way everybody nows exactly where they are.

mdima

@ermal:

@dwood:

Same thing here..had to remove 2.5.0. WAN IP x.x.x.0 network was being blocked. PFsense log than alerted on WAN down, and removed it from routing group (dual wan).

Cheers,
Dennis.

As i put in the other thread.
There is an issue that was solved with blocking not parsing correctly the whitelist.
Just re-install the binary.

Hi Ermal,
well, unfortunately it's still doing that, I upgraded the package few hours ago. It is blocking IPs that are in the whitelist alias, and also CARP VIPs.

Btw, managing the whitelist with an alias is awesome!

Thanks,
Michele

simby

how do i use alias?

eri--

I pushed a fix to the sensitive data rules.
Please test it after 30 minutes.

@ermail: is it possible to add the snort build number/date somewhere in the GUI? This way everybody nows exactly where they are.

I would prefer not since its not needed and you are just reporting bugs here.