Messages

1

pfBlockerNG / Re: When should I block inbound?

« on: January 03, 2018, 05:00:07 pm »

You only need to add rules to the Inbound, if you have any open WAN ports that you would like to filter on.

To add to this, I think most guides say to use Deny Both because while you may start out with the default case of all unsolicited inbound WAN traffic being blocked, as soon as a single port is open for service, the game is afoot.  So, if you start out with Deny Both, then at least you're covered if something changes on the WAN and you forget to change your pfB protection.

Personally, I use Floating for my pfB lists and have them attached to both WAN\LAN...

2

pfBlockerNG / Re: pfBlockerNG list alerts are logged under the incorrect rule\alias

« on: January 03, 2018, 04:22:44 pm »

When Deduplication is enabled you will have better results, even with the upcoming release.  Plus I don't really see a reason not to enable Deduplication.... There are some use cases for an "Alias Native" which doesn't use deduplication.

So first, De-dup was NOT enabled - I chg'd this and now have much better results - THANK YOU.  Next, you read my mind - as when to not use de-dup.  You mentioned "Alias Native" which I can research here but please also feel free to discuss that or other situations where de-dup would\should not be used.

Thanks again...really appreciate the help...OH, by the way - pfB really does kick ass...killer package...one of the reasons I choose pfSense...there are many reasons why but pfB is definitely one of the tops...

3

pfBlockerNG / Re: pfBlockerNG list alerts are logged under the incorrect rule\alias

« on: January 03, 2018, 04:05:51 pm »

Ahhh...ok...so at present, the Alerts tab doesn't have actual logged IP <--> list data - it does a xref lookup for the IP in a given set of lists and first hit - BAM - that's the one it shows.  Yeah, that gets kinda dicey when trying to understand what's really going on especially when these lists contain a bunch of dups.

Sounds like this is being resolved though int he next version where, if I understand you correctly, the actual hit data will be what's logged and therefore, what is present to the user...is that correct?

4

pfBlockerNG / pfBlockerNG list alerts are logged under the incorrect rule\alias

« on: January 03, 2018, 03:14:38 pm »

The following is being observed on v2.4.1-amd64 and 2.4.2-amd64.

My pfBlockerNG setup has two IPv4 aliases - one for production lists and the other for test lists.  The prodAlias has several lists while the testAlias currently has only one list - "alien".

The test procedure is as follows: (A) prodAlias = ENABLED, testAlias = DISABLED; alerts logged properly; (B) prodAlias = ENABLED, testAlias = ENABLED; alerts logged to incorrect alias;  (C) go back to prodAlias = ENABLED, testAlias = DISABLED; alerts go back to being logged properly.

Also, there were several pre-existing alerts that, prior to enabling the testAlias, were all logged properly as belonging to the prodAlias.  After enabling the testAlias, all of the pre-existing alerts were magically changed to as belonging to the testAlias.  Then if I go back and disable the testAlias, the pre-existing alerts go back to as belonging to the prodAlias.

I have triple-checked that the "alien" list is not in the prodAlias.  I have also scoured the UI to find any setting that indicates a knob for this behavior - did not find anything.

What is even stranger is that both aliases do show hits in the pfBlockerNG widget and when I click on the "Packets" link in the widget, I do get some hits for the "alien" list but using the proper alias.

Really strange behavior here...

I presume this is a defect?  Has anyone else seen or heard of this?

5

General Questions / Re: ICMPv6 incorrectly blocked by default rule

« on: January 03, 2018, 02:31:34 pm »

@jimp - that did it - many thanks.

Also, is there anyway to have that ipv6-master switch not log traffic?

6

General Questions / ICMPv6 incorrectly blocked by default rule

« on: December 29, 2017, 08:32:34 pm »

I have configured block all-IPv6 rules at the bottom of the 3 FW rule sections: Floating, WAN, & LAN.  All three rules are all encompassing meaning they match ANY source, ANY destination, and ANY protocol.  And finally, all set to NOT log hits.

Despite this, I still see a bunch of log entries for blocked ICMPv6 traffic on both the WAN & LAN interfaces due to the implicit block rule.  I believe it is the implicit rule because (1) if I disable the logging of hits to implicit block rules, the log entries stop; (2) the rule name shown in the log is not one of the names I entered in my explicit rules; and (3) the little torso icon is NOT present in these log entries.

To confirm this, I then added new block rules on both the WAN & LAN interfaces that specifically targets ICMPv6(any) - no joy...the log entries persist on both interfaces.

I really want to keep the log for default rule hits as this is a good trap to discover any potential rule leakage.  And while the logging part of this isn't really a biggie, I do wonder why the FW appears to not be blocking traffic as it should be.

Couple of final points: (a) The rule ID for both LAN & WAN log entries is the same; (b) the only rule that shows any evaluations is the block all-v6 floating rule - all other block v6 rules show no evaluations at all.

Let me know your thoughts - thanks.

7

IDS/IPS / Re: Snort alert log entry timestamp delta between GUI and syslog

« on: December 12, 2017, 03:39:37 pm »

Hi Bill,

Yeah - really strange.  I considered the clog aspect as well but if that were part of this, then you would expect there to be skew consistent across the whole file which I do not see.

I do think the 5m delay for the block resulting from the 12:00 related syslog message is due to the rules updating - I figure maybe the BLOCK_THIS IPC message somehow got head-of-line blocked due to Snort grinding through rule updates.  I believe Snort is single-threaded and if so, then this might make even more sense.  Would be curious to hear your comments on that possibility...

In any event, still doesn't explain the different timestamps on the syslog messages... *scratches head*

8

IDS/IPS / Re: Snort alert log entry timestamp delta between GUI and syslog

« on: December 11, 2017, 09:01:17 pm »

UPDATE

In reviewing more of the logs, I found that coincidentally - or possibly cause\effect...not sure - but Snort began updating the rulesets just prior to the 12:00-timestamped version of the alert.  I'm not sure if this update and subsequent Snort restart plays a role in this but I gotta believe it might.

Curious to hear feedback...

9

IDS/IPS / Snort alert log entry timestamp delta between GUI and syslog

« on: December 11, 2017, 08:19:49 pm »

I have alerts logged to syslog and with one alert in particular, the GUI version has a timestamp about 5.5h earlier than the same alert in syslog.  The natural question is why would I think these are the same alerts - here's my reasoning:

• The alert is on the LAN side and I see very few alerts on the LAN side to begin with.
• Every other data field for this alert is the exact same with the only difference being the timestamp - even down to the destination port #.
  
• While it is definitely probable to see same non-well-known src\dst port # re-used, it is highly unlikely to see that re-use occur with 2 different sessions between the same 2 machines running the same L4 protocol AND the same L7 protocol\application within the span of just a few hours (basic prob is roughly > 1 in a few hundred thousand).
• To support this statement, captures taken of my machine communicating with a variety of hosts\services illustrate the rarity of seeing the same src\dst non-well-known port # re-use.  I definitely see it occur but it's always involving at least one element being different - i.e. the L4 protocol, the L7 protocol\application, etc.

One thought I had was a delta due to different timezones being used for the 2 log entries however this doesn't fit because (1) All other GUI\syslog entry timestamps match; (2) The time delta does not equal an integer of hours as you would expect with a timezone mis-match (time delta here is 5h:35m:5s).

Another interesting thing about this alert is that it did not trigger a block until exactly 5m after the alert BUT the relevant port # (in this direction, the src_port) is different than it's counterpart in the alert log entries (in that direction, the dst_port).

All log entries\captures are included herein.

ALERT syslog entry
Dec 11 12:06:10 IP_MASKED snort[35645]: [124:3:1] (smtp) Attempted response buffer overflow: 726 chars [Classification: Attempted User Privilege Gain] [Priority: 1] {TCP} 98.139.211.125:587 -> IP_MASKED:62123

FW BLOCK syslog entry
Dec 11 12:11:06 IP_MASKED filterlog: 18,,,1000000110,igb1,match,block,in,4,0x0,,64,37027,0,DF,6,tcp,64,IP_MASKED,98.139.211.125,54848,587,0,S,4159647144,,65535,,mss;nop;wscale;nop;nop;TS;sackOK;eol

10

IDS/IPS / Snort passlist not read after adding FQDN to alias

« on: December 04, 2017, 04:55:11 pm »

Setup

• pfSense: v2.4.1
• Snort: v3.2.9.5_3

Issue

After adding an FQDN entry to an alias then used to define a passlist, the alias portion of the passlist is silently ignored.  Steps to reproduce are shown below.

I understand that passlists do not support FQDNs however, the system should at least throw some kind of error or better yet, maybe just read the alias and ignore the invalid entries. The current behavior is possibly the worst of all in that the silent ignore leaves the user thinking the passlist is being employed when in reality it is not thereby creating a precarious situation where one could get locked out of their own system.
Steps to reproduce

• Create an alias with a few IP addresses.
• Create a passlist that references the above alias.
• Go to the desired interface config and set it to use the above passlist.
• Click the View List button to confirm the passlist is being read as expected.
• Save changes and Restart the interface.
• Add an FQDN to the alias previously created - be sure to Apply after saving changes.
• Go to the interface config where the passlist was installed and click the View List button to check the passlist.  It should no longer appear as expected - i.e. the alias portion of the list is ignored.
• Remove the FQDN just added - be sure to Apply after saving changes.
• Go to the interface config where the passlist was installed and click the View List button to check the passlist.  The list should be read as expected.

NOTE: The issue occurs when the FQDN is saved as opposed to when those changes are applied (i.e. using the Apply button) as one might expect.

11

IDS/IPS / Re: Turning off rule(s) does not stop blocking

« on: November 20, 2017, 01:20:22 pm »

Incredible explanation - beyond awesome - Thank you...

12

IDS/IPS / Re: Turning off rule(s) does not stop blocking

« on: November 19, 2017, 06:15:14 pm »

bmeeks---

Agreed that my original post is confusing - I am going to re-test everything and then clarify as needed.  Before doing so however, I want to clarify disabling vs. suppression.

My understanding of what suppress does is as follows: Disables the alert for a given rule and if blocking is enabled, then it also also disables the blocking for that rule.  Please correct if this is inaccurate.

Next is the question of the delta between disabling and suppression - the only difference I see is that disabling is basically suppression + the added benefit of not wasting resources for analysis of the rule in question.  Feel free to also correct if this is inaccurate.

Finally, when to use one over the other.  In this forum post, jflsakfja states that the "correct" method for dealing with false positives is to disable rather than suppress.  Would you agree with this or is your view that suppression is better?

Thanks again for your help...

13

IDS/IPS / Re: Turning off rule(s) does not stop blocking

« on: November 17, 2017, 07:56:05 pm »

UPDATE w/ screenshots.

The attached screenshots show the alerts for a blocked host as well as the host block log entry - both despite the rules in question being disabled (120:3 & 120:8).  Also note in the alert screenshot, the entries have the little yellow "X" indicating that the rule for that log entry is supposed to be in force-disabled state.

14

IDS/IPS / Turning off rule(s) does not stop blocking

« on: November 17, 2017, 04:58:25 pm »

System Setup:

• pfSense v2.4.1
• Snort v3.2.9.5_3
• Celeron J1900 w/ 4GB RAM

Initial state: Snort running on LAN interface w/ no categories enabled, no pre-processor rules disabled, and nothing in the suppression list.

Issue: When trying to access a given site, the site fails to load and I observe several blocked hosts due to a variety of issues.  After some research, I disable several rules on the LAN interface based on the recommended suppression lists found in many forum posts that discuss recommended initial setups and how to combat false-positives.  I then restart Snort on the LAN interface and clear the blocked hosts.

Upon trying to access the same site, I observe similar behavior however this time, the blocked hosts are due solely to (http_inspect) NO CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE.  In looking through the pre-processor rules for the LAN interface, the above message appears to be due to rule 120:3 which I confirm has already been disabled due to the work performed above.  I decide to head over to the pre-processor tab and disable the HTTP_INSPECT pre-processor.  I again restart Snort on the LAN interface and clear the blocked hosts.

This time, when trying to access the desired host, all is well.....So, why?

I mean I understand why disabling the HTTP_INSECT pre-processor solved the issue but I don't understand why it is required...or maybe it isn't required and I'm just not understanding something here.

I did go and inspect the other pre-processor rules and nothing else jumped out as a possible culprit.  I do remember reading in at least one of the forum posts that some rules cannot be disabled and therefore are not shown in the GUI.  Is this what is occurring here?

Switching gears for a moment, another issue I'm seeing is that despite the suppression list being empty, I do not see any alerts regarding the above blocking.  At one point in my testing, the suppression list did have some entries but I cleared those out manually and then re-executed the above steps to ensure I had good test data.  However, still no joy...even after clearing out the suppression list and restarting Snort on the LAN interface...no alerts.

Thanks in advance for any help and insight you can provide.


PS: Before posting this, I did exercise a fair degree of diligence in trying to find the answers so apologies if I missed anything obvious.