Copy the .dat files to /usr/pbi/ntopng-amd64/local/share/ntopng/httpdocs/geoip instead of the path listed in the error message.  Something like:

pushd  /usr/pbi/ntopng-amd64/local/share/ntopng/httpdocs mkdir geoip cp -vp /root/*dat ./geoip/

The geoip stuff works for me after that.  Note you will have to do this after every package reinstall or pfSense update.

I also noticed the two methods for setting the password don't play nice together (ntopng gui 'manage users' vs pfsense 'ntopng settings').  Actually there's a third method too, via the console: http://blog.redbranch.net/2013/12/12/reset-ntopng-admin-password/

I have AC-BNFA-NQ as standard..

"The rules update process will only restart Snort if it is detected as running during the update process."

That's what I expected, therefore I controlled this box some minutes ago, but all three snort-interfaces were up and running, strange indeed…

Ok, thank you for answer

In the future, with a botched for some reason squid, try:

squid -k shutdown

cd /var/squid/cache

rm -rf *

squid -z

Then reboot and reinstall squid package.

I'm afraid there are no guides for the pfSense haProxy gui that are really usefull..
Anyway you should really consider using the haproxy 1.5 package. It has way more options than all 1.4 packages combined..
If you find a bug, (there aren't any critical left that i know of), let me know..

Create 1 backend for the 2 servers. Then create 1 frontend to listen on the desired port, and use the backend, and it should already start working.. Enable checking on the backend to have haproxy actually perform checks, and activate stats to see if backends are seen as 'up'.

That should basically be enough to get started.

@Hollander:

Thanks Bill  ;D

ps -ax came back empty, and the directory is gone too: both good.

CPU is normal at 4% now. I just tried again: install Snort: CPU back to 100% due to fetch. I know that if you say it isn't Snort then it isn't Snort, yet it's a weird coincident that keeps on repeating itself. So I had to uninstall Snort again.

I am eagerly awaiting until JFL will find the time to write the SuricataTutorialNG (NG = © BB ;D ), so I can try to replace Snort with Suricata.

You have something wrong in your configuration someplace.  I don't know what it may be, though.  I have never seen that behavior with any of VM testing over the last two years.  Are you using IPv4 or IPv6 addresses?

Bill

@ypmict:

Hi…
I am also facing this problem, I am using :
pfsense 2.0.1
snort 2.9.6.2 pkg v3.1.4 (using the free oinkcode)

the error log says :

Starting rules update...  Time: 2014-11-10 10:33:28
Downloading Snort VRT rules md5 file snortrules-snapshot-2923.tar.gz.md5...
Snort VRT rules md5 download failed.
Server returned error code 422.
Server error message was:
Snort VRT rules will not be updated.

...anyone know what the problem is?
I also try to register different account for oinkcode.. but still shows error...
thanks

Snort is no longer supported on pfSense versions older than 2.1.  You say you are running 2.0.1, so Snort is now broken and unsupported on that version.  You should upgrade your pfSense to version 2.1.5.

Bill

Any one haves any idea?

Thank you
Best Regards

Hi there,

/var/squid/logs/access.log exists.
But the problem is that I cannot generate reports
please see the images below for more information

2.png_thumb
2.png
1.png_thumb
1.png

Thank you Bill, it seems that reverting the pfSense conf to the previous one before Snort update solved the problem: pfSense reinstalled all the packages (including Snort but omitting NUT!) and all seems working now.

Strange thing the failed reinstall of the NUT package: my machine is not "messed up" with a lot of configurations or packages. The log said "unable to reinstall nut, take appropriate action".

I simply reinstalled the NUT package and the configuration was there!

Edit: now pfSense is dropping the PPPoE connection approximately every 30 minutes :(

You can try this too : https://www.countryipblocks.net/country_selection.php

Altho it offers a false sense of security; your malware these days will come from G5 hosting compagnies or amazonaws, cloudfront, cloudflare…etc....

F.

this config ran for about a week, then the same "out of space' error occurred again.

something is screwy with diskd vs freebsd

for now ive gone back to the ufs option, but im sure i will be inspired to fiddle again soon

Thanks!

Best regards

Thanks man

I agree with Wolf666.  Enabling Snort on the LAN for a home firewall is the best choice.  You don't usually have any unsolicited inbound traffic allowed on a home setup, so Snort on the WAN does not really help any more than having it just on the LAN.  What you are more worried about is an internal machine picking up malware and/or that malware calling home to the mother ship for additional instructions.  Snort on the LAN would see this and alert you.  Plus, if you configure the blocking IP to BOTH on the SETTINGS tab for the interface, then the far-end of the conversation will be blocked but the LAN end will not be as it is generally in the default PASS LIST unless you change something.  However, you will see the local IP address as well as the far-end IP in the alert.

Bill

@JohnKap:

Hi all.

I have an alias set up "Trusted_IPs", with a list of IP addresses I want snort to ignore - 3 in total.

Under the Pass Lists tab, I have created a single pass list and included the "Trusted_IPs" alias. (see attached).

Snort will block an IP address in the trusted alias list, error messages are:

(http_inspect) UNKNOWN METHOD - 11/07/14-09:24:08 (http_inspect) NO CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE - 11/07/14-09:54:34

I have restarted both snort & pfsense to ensure cache's are cleared and tables are updated, yet snort will continue to block.

Any ideas what I've overlooked.

thanks

The best course of action here is to disable those rules entirely.  Click the X beside the GID:SID on the ALERTS tab. That will permanently disable them.  They are well known false positives.

The reason you still see blocks may be because of the setting for WHICH IP TO BLOCK on the SETTINGS tab for the interface.  If set to BOTH (the new default), then your PASS LIST IP should not be blocked, but the other end of the conversation will be blocked and thus communcations will still be stopped.

Bill

@Heli0s:

If that's the case, is there a good way to protect my network from port scans? I've tried a few online port scans and some are picked up and some are not.

Not that I am aware of.  On the other hand, if you have a carefully configured firewall that allows only exactly what is necessary to get in, why worry about a port scan?  If those ports are not open, so what?  What seems to happen a lot recently is the port scan preprocessor is overly sensitive and triggers on some normal and harmless stuff.  I think in an attempt to reduce the sensitivity and prevent those false positives, some of the older port scans are no longer detected.  So all in all the utility of the port scan preprocessor seems to be degrading in my view.

If you still want to use it, then you will need to tinker with all the settings for the preprocessor.  That's why I added them to the GUI several revisions back.  They will allow you to tweak it so maybe it works for you without triggering on too many false positives.

Bill