Very lame  ;D
Dunno how I've missed that one… Will do it right away!

It says a change is required, but it doesn't say how the change should look like:

Untitled.png
Untitled.png_thumb

No, the settings under System -> User manager is for authentication to the web gui. Packages such as Dansguardian require seperate configuration.

There is a bug in the Snort binary with regards to SSL detection.  That might be what is happening here if the URL is https://.  You can Google some references to the bug by looking for "client HELO after server HELO".  This bug will hopefully be fixed in a later Snort binary release.  For now I recommend suppressing this particular alert.

As BBcan17 mentioned, peruse the threads here in the Packages forum for advice on how to tune Snort by suppressing common false positives.

Bill

@BBcan17:

@bmeeks:

Have performed a "save" operation after disabling the writing to the system log and also tried restarting Suricata?  Look in the suricata.yaml file for the interface and see if syslog output is showing as enabled.

Hi Bill,

Sorry for sounding the alarm. I was looking at the General Settings tab for System logs which was not enabled. I have now disabled the system logs for Wan and Lan interfaces.  :o

I don't recall the logs going to the System.log with the previous Suricata Package. I didn't play with the Suricata settings for awhile now.

Here is what is in the yaml file for "syslog"

grep -A4 -n "syslog" /usr/pbi/suricata-amd64/etc/suricata/suricata_30898_bce0/suricata.yaml
73:  - syslog:
74-      enabled: no
75-      identity: suricata
76-      facility: auth
77-      level: Info
–
225:  - syslog:
226-      enabled: yes
227-      facility: auth
228-      format: "[%i] <%d> – "
229-

I can't remember exactly when I enabled that, but it's been there at least since one of the earlier BETA releases.  Suricata has two distinct and different logging paths.  One is for alerts.  Those can go to syslog or not.  The other is for Suricata operations-related stuff like startup, shutdown, etc.  That always goes to the suricata.log file on pfSense, but can optionally go to the system log (syslog) as well if enabled.  That's why there are two different parts of the suricata.yaml file that reference syslog.

Bill

@cyber7:

Thank you dvserg :)

Could you tell me, if I have "other" exe files on the site, how I allow global access to the site's exe files?

kind regards
cyber7

Only Exe? May be allow this site as domain without copy-paste each EXE URL's?
Or, of course, you can use Expressions:
(..safe.com/files/..exe)

@wlm2048:

See if you have "/var/db/pkgpinghosts", and if so, delete the lines in it that say anything about tinydns, and then delete the "/tmp/tmpHOSTS" file. The latter will be recreated.

Thank you, You made my day/week!

Are you using IPv6?

Absolutely not!

Works wonders. Thanks!!

Hi,

I think you can export and import certificates and the CA from SYSTEM –> Cert Manager.
Exporting Cert and Key and importing on the other pfsense machine.

Or just make a backup of the running pfsense config and import this backup into the other pfsense. Perhaps you have the possibility to just import certificates and not all the other config.

Unfortunately I cannot help you any further since I do not have any access to a pfsense machine anymore. My new company does not use pfsense .... :(

LOL check out https://forum.pfsense.org/index.php?topic=77032.0

TL;DR will be there in 2.2.

Thanks for your assistance bmeeks!

Hi Mike,

If you tune the rules, you shouldn't get too many False Positives (as you said, "probably one every two weeks or so").

With that said, I run Snort with the "Never Clear" setting, and just remove the ones as they come.

I like this approach better because if you leave the Blocks alone, you will see a lot of repeat offenders and it will Block faster as its already in the Snort2c table.
Snort is not a true-inline IPS so removing IPs will let some packets thru if they weren't already blocked.

So tuning Snort is the best approach to managing a good IPS system.

What kind of Dynamic IPs are you seeing?

I submitted a post to add more Search Lookups to the DNS lookup page which can make it easier to diagnose IP addresses.. See below..

https://forum.pfsense.org/index.php?topic=73406.msg404649#msg404649

@Atlantisman:

I am on 2.1.3 i386, it looks like barnyard2 was having a problem with the SCADA rules and at least one other rule set. I took everything back to only VRT rules and barnyard started right up.

Thanks.

I can investigate the SCADA rules.  Those particular messages in your log post were just warnings, though.  They would not prevent a startup.  It was that fatal error trying to read one of the Emerging Threats Web Server rules that killed it.  The ET rules have had a few errors creep into them lately, and Snort (and now apparently Barnyard2 as well) can choke and refuse to start up if a rule with an error is encountered.

Bill

found the issue.

When the pkg gets re-installed via the system upgrade the conf file does not get restored. You have to go to the web ui of sarg in pfsense and click save and the conf file gets recreated.

Heads up team! :)

@KyferEz:

I recently used a guilde to setup Squid3, Dansguardian, and HAVP. It's working well, except I am having trouble with it blocking Netflix on Android.

I ran into an issue with Netflix not working on Android during one of my many, many iterations of trying to get a stable pfsense+squid+dansguardian config. It may be the same issue that you're having. I think it was related to the flawed dansguardian package that was available via the pfsense webconfigurator. I think it was Marcello's build of the dansguardian binary that fixed it (among other problems). I've gone around and around with pfsense+squid+dansguardian, though so my memory could be faulty on the exact cause/solution, however.

At any rate, the setup that seems to give me the best stability so far is:
pfsense (I'm currently at 2.1.2, FWIW)
Squid3-dev (I'm at 3.3.10 pkg 2.2.2)
Dansguardian (I used 2.12.0.3_2 pkg v.0.1.8 and then updated the dansguardian binary with Marcellos' build)

These threads have some info:
https://forum.pfsense.org/index.php?topic=58442.0
https://forum.pfsense.org/index.php?topic=43786.0

This is my version of the fix, which seems to be somewhat different from some of the others' versions. Note, this is for 64-bit, NOT 32-bit systems:
killall dansguardian
rm -rf /usr/local/etc/dansguardian
ln -s /usr/pbi/dansguardian-amd64/etc/dansguardian /usr/local/etc/dansguardian
cd /usr/pbi/dansguardian-amd64/sbin
fetch http://e-sac.siteseguro.ws/pfsense/8/amd64/dansguardian
/usr/local/etc/rc.d/dansguardian.sh start

Read the above threads for more context and for the variation that others have been using, though.

Hopefully, this will get you moving again. Unfortunately, I'm unable to give you any more details right now and won't be monitoring the forums for at least several days. I think the fix for you is probably going to be replacing the dansguardian binary with Marcello's version, though.

Good luck!

@gscasny:

Nice on the 2.0.. Do you know if it's compiled with JSON (libjansson) support?

My first private test of 2.0 was not, but I think I can include it in the production release.

Bill

@BBcan17:

Thanks Bill we all appreciate the work you do in Maintaining these packages so well !

I just tested in a VM with multiple engines (HTTP_INSPECT for my test).  All the previous settings are now retained when Snort is disabled on an interface.  When you enable it again, the old settings are still there.

Note this behavior is different for a DELETE operation.  If you delete a Snort interface on the INTERFACES tab, then all Snort settings belonging to that deleted interface are permanently removed.  It does prompt for a confirmation before deleting the interface, though.

Bill