Anyone? I work in an IT shop so a lot of our traffic are updates, it would be great if the 206 requests were pulled out of the cache rather than across the internet.

Thank you for the reply but I found what was the problem.

In the Interface / Lan menu, I had the IPv4 configuration type set to "Track Interface" for some reasons.

I set it to "None" and the rules got automatically added in the Firewall/Rules section after enabling pfBlocker.

Thanks.

This script needs an update.

Also, you can modify the path to lockfile on the GUI.  :-[

Have you tried setting the logging option to either "Encode" or "Allow" ?

strip: The whitespace characters are stripped out of the URL. This is the behavior recommended by RFC2396. deny: The request is denied. The user receives an "Invalid Request" message. allow: The request is allowed and the URI is not changed. The whitespace characters remain in the URI. encode: The request is allowed and the whitespace characters are encoded according to RFC1738. chop:The request is allowed and the URI is chopped at the first whitespace.

With "squid3-dev" you could try with "forwarded_for transparent" typed into "Custom ACLS (Before_Auth)" field (and with the "Disable X-Forward" not selected off course.)

I don't have a theory to explain what caused the out-of-memory message.  If this was a single event, it may just have been due to the phase of the moon relative to the spontaneous decay of a Higgs boson …  ;).

If, on the other hand, it is a repeatable error for you, then some further investigation is called for.  I assume from the info provided in your first post this is a pfSense 2.2-BETA box.  Do you have any other packages running besides Snort?

Bill

Thanks Guys!

@wbennett77:

I have Snort Alerts added on my Dashboard but it doesn't show the most recent alerts. Is this normal?

Cheers!

The Dashboard widget should show the most recent alerts, but it shows a composite consisting of all interfaces.  So if you have Snort enabled on LAN and WAN, and the "lines to display" in the widget set for 5, then it will show the 5 most recent alerts without regard to interface.  Stated another way, if the WAN had the most recent 5 alerts, then the widget would only show those. It would not show any of the LAN alerts if they were older than the most 5 recent WAN alerts.  The reverse is also true.

Bill

varnish sucks, after few days of troubleshooting and wildguessing i've installed squid3 and settled everything in 15 minutes.

http://serverfault.com/questions/542416/having-two-subdomains-on-one-public-ip-addres-behind-pfsense-router

the third answer for squid3 was correct.

I've found Snorby to get the rule text right most of the time.  Glad you found that rules setting.  I forgot to point it out.  If you find out something from your other queries that you think needs changing in the Snort and Suricata packages with respect to Barnyard2, post back here or send me a PM.

Bill

Look here. Does this help?

Hi,

Thanks, my switches do support RADIUS, so I will see about switching that on.

I was kind of expecting that pfSense would have the same kind of support for enabling RADIUS for any connectivity to it, maybe that was an incorrect assumption.

Regards,
Rob.

Oh nevermind, maybe they are not realted after all… when i saw IE User-Agent thought it was the CVE-2014-6332...

Still... packet capture some of those and we will check if its FP or what it is...

F.

On page Serivce –> Proxy server. Add custom option
include /usr/local/etc/squid/my.conf

On my.conf write
http_port virtual_ip:port

restart squid
squid -k reconfigure

check open port
netstat -an

@Hollander:

1. The thread you posted is clear. Except for the part about 'changeSID'. I have no clue what I am seeing, as in: it doesn't fit in my limited brain; either you have enabled SID's, or you have disabled them. Why the third list?

The modifysid option is for actually changing the text of the rule body.  For example, you could change the "alert" keyword to "drop".  This will have more meaning once a true IPS mode is implemented.  Then, "alert" rules will simply print messages in the logs and on the ALERTS tab; but "drop" rules will be the ones that actually drop (or block) the offending traffic.  Today on pfSense any "alert" causes a block, but on a true IPS that is not the case.  Alerts are like notices and "drop" rules are the only ones that should block traffic.  You might for example only want alerts for rules that identify older versions of Java or something, but you would want drops for rules that identify known malware phoning home.

As the Snort and Suricata packages exist today, the modifysid function is not really necessary yet.

@Hollander:

2. Do you have thoughts on keeping separate SID-lists for Snort and Suricata? Or 'one list fits all'? (Does it? I don't know).

This is an admin decision.  Just remember that there are many, many Snort rules that contain keywords or rule options that Suricata does not recognize.  No sense even trying to load those rules on Suricata.

@Hollander:

3. Do you have thoughts on the lists having exclusive SID's (-> if a SID is on list 1 it shouldn't be on list two, and vice versa), or are there good reasons to do things differently?

If you are using only literal SIDs in the files, then it does not make sense to put the same SID in both files.  However, when you use the more advanced PCRE options; it is conceivable to match the same SID.  In those situations, the setting of the SID STATE ORDER control becomes important.

@Hollander:

4. How can one manage the part of new SID's appearing after an update? Is there a 'new SID's added during update' list somewhere? Because these need to be processed into the github-list one way or the other I guess(?)

Each time the rules are updated the vendors post an updated Change Log on their web sites.

Bill

The Devs have removed the package. See the following link:

https://github.com/pfsense/pfsense-packages/commit/87019e8afcb46a9be8edc461168287f6a9b92cc4