Netgate SG-1000 microFirewall

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - cyberzeus

Pages: [1]
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?

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.

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} -> 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,,54848,587,0,S,4159647144,,65535,,mss;nop;wscale;nop;nop;TS;sackOK;eol

IDS/IPS / Snort passlist not read after adding FQDN to alias
« on: December 04, 2017, 04:55:11 pm »
  • pfSense: v2.4.1
  • Snort: v3.2.9.5_3


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.

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 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.  :o  ??? ::)

Pages: [1]