@fsansfil:

Hey BBcan,

I know, its really well done too…

But just wanted a simple way to add more $ operator with aliases ;)

F.

This idea would require changes within the pfSense code itself, and not just the Snort or Suricata package code.

Bill

@hescalona:

mv /usr/pbi/snort-amd64/bin/barnyard2 /usr/local/bin/barnyard2

Yep, this should fix it by copying the latest barnyard2 binary over top of any older version lurking in /usr/local/bin.

Bill

@wbennett77:

Thanks Bill,
How would I identify which ET rules that are direct IP drops besides the three you spoke about?

The rule text will just be a long list of IP addresses.  It's not terribly critical that they go on just the WAN, though.

As another poster mentioned, there is some debate on the merits of where to put IDS rules (WAN, LAN or both).  I find that for most home users with NAT, putting the rules on the LAN side helps you better find any infected hosts without a lot of searching.  On the other hand, most home networks are small enough that even a brute-force search of all the machines would not take very long.  For me I just like the convenience of having the offending host's real IP immediately available in the alert message on the ALERTS tab.

Bill

I am not familar with actual pfsense version and CaptivePortal. But if I remember correct there is a possibility to give a user some credits so that this user can access the internet without logging in on CP. So you you try to use a high number of credits for each user and low timeout for resetting these credits and enabling Accounting on CP.

Not sure at all if this works.

When you are searching for "radutmp" file you find some interesting information:
http://opensource.apple.com/source/freeradius/freeradius-25/freeradius/raddb/modules/radutmp

Accounting information may be lost, so the user MAY
#  have logged off of the NAS, but we haven't noticed.
#  If so, we can verify this information with the NAS,

#  If we want to believe the 'utmp' file, then this
#  configuration entry can be set to 'no'.

check_with_nas = yes

So this part will tell us that accounting is used for simultaneous use checks and it tells us, that if the user logs of or is disconnected and the NAS (Access-Point is your case) will not tell freeradius that this user has disconnected, then freeradius will never know and this user will still exist in radutmp file. So when trying to use DD-WRT you should make sure that it works like it should and that you don't fix one problem and get a new one ;)

Perhaps you should enable CaptivePortal and use this accounting feature and authentication. On CP add the Access-Points itself to bypass so that authentication with PEAP works. Users then authenticate against freeradius to get WLAN Access and then - this is not so comfortable but should work - again on CP to get internet access. With the same username and password and then simultaneous checks can be done on freeradius with accounting enabled on CP or better use the CP built-in feature of simultaneous-checks.

Good Luck!

@Hollander:

I had the same problem, so I wil do the XML-reinstall as you said, Bill, to see if it fixes anything.

(Disabling portscan preprocessors and rebooting did not solve anything).

What is weird in my case is: it only happens on WAN1 (VDSL), not on WAN2 (Cable);

And, of course, being the noob that I am, I have no clue why my WAN1-IP would be detected as doing a port scan on some remote IP at all.

And, something even more weirder:

Source: 122.225.97.66
Destination: 81.x.x.x. => my WAN
SID: 136:1 ((spp_reputation) packets blacklisted)

And then my WAN gets blocked by Snort, and not the 122.225.97.66  ???

The update to 3.1.5 should fix the WAN IP getting blocked.  The bug fixed in that update causes Snort to ignore the new WAN IP change, so that means your new WAN IP does not get put into the default automatic PASS LIST.  As for portscan sensitivity, I have a noticed a few more than I used to get many months ago.  The GUI package code I maintain has nothing to do with that, however.  That is something triggered by the Snort binary that comes from the snort.org folks.

Bill

Found it.

/usr/local/www/

Edit Squid_monito.php using filemanager or other.

Find

<form id="paramsForm" name="paramsForm" method="post">

| Max lines: |
<select name="maxlines" id="maxlines"><option value="5">5 lines</option> <option value="200" selected="selected">200 lines</option> <option value="15">15 lines</option> <option value="20">20 lines</option> <option value="25">25 lines</option> <option value="100">100 lines</option> <option value="200">200 lines</option></select>

|
| String filter: |

! to invert the sense of matching, to select non-matching lines.");?>
|

</form>

Edit highlighted section from 10 to any other preferred number and refresh the squid monitor page.

Voila!

Related bug report: https://redmine.pfsense.org/issues/4034

Bug report for "Do not overwrite previous backups for this hostname" checkbox: https://redmine.pfsense.org/issues/4033

Feature request to differentiate automatic and manual backups: https://redmine.pfsense.org/issues/4035

Hey guys,

anyone got an idea? :/

Greets

Hey guys!

Just wanted to let you know that with the modified rule I was able to get an alert on the interface I supected to be the source of the conficker traffic. I still have to investigate the PC to confirm that it actualy is infected but the whole issue seems pretty plausible now.

Thanks again for the great help!

Malte

@dola0056:

would that be /var/log/system.log? I did check it out and have not seen any errors. The interface seems to come up and down but the red and white x remains. Also when I create a rule it doesn't work for the interface unless I remove the block offenders option and then the rule and the interface run fine.

Look under Status…System Logs.  You may need to click the Settings tab once that page is displayed and tick the box to show newest events first (that is, show events in reverse order) and expand the number of entries displayed to like 250 or more.

Now go back and try to start Snort with blocking enabled.  You should get an error message of some type in the system log.  My first thought is perhaps your system is missing the <snort2c>table.  That has happened to folks who have used the Traffic Shaper.  It seems to delete the <snort2c>system table that Snort needs for blocking – or at least it was doing that a while back.

Bill</snort2c></snort2c>

@new_to_pfsense:

Can I use this list:

(Brute Force Blocker)
http://danger.rulez.sk/projects/bruteforceblocker/blist.php

In my pfsense aliases as a URLTABLE even though the URL does not end with .txt?

new_to_pfsense - Did you ever try to add the list?  I came across the list as well, and interested in knowing what happens when its added through the gui.
Thx
Ash,

d'oh.  Thank you.  I looked at that page a dozen times but was always looking for a text field to type a value into so kept looking over that one.

Snort and IPS/IDS in general is not a turn on once and leave it running kind of solution. You need to asses if the alerts being triggered are false positives or not and add suppress / pass lists based on your needs.

@cjbujold:

Thanks de-activate the rule and everything now works.  The rule # giving the problem is in emerging web-clients rule# 2011695.

cjb

That rule is disabled by default in both ET-Open and ET-Pro packages, so that's why not too many people run in to the syntax error.  I think it has been reported a number of times, but so far has not been fixed by the authors.  You can fix the error by deleting the backslash in front of the phrase "\object.data" so the pcre expression looks like this instead:

Of course the next time your box downloads an updated Emerging Threats rules package your edit would be overwritten.  You could paste the "corrected" rule in as a custom rule and just leave it in the default disabled state in the ET web-client package.

Bill