Snort 2.9.4.6 pkg v2.6.0 Update

Supermule

Its running and blocking!!

THAAAAAAAAAAAAAAAAAANK YOU!! :-*

bmeeks

Its running and blocking!!

THAAAAAAAAAAAAAAAAAANK YOU!! :-*

OK! Thanks for the feedback.

There is one small bug uncovered thus far with the new FQDN Alias support. I worked that one with another user who successfully tested a fix. I will hold up pushing out that update while I wait to see if anything else surfaces. That bug is sort of minor and only affects folks using the FQDN Alias with a particular configuration.

Bill

Supermule

No worries! I will provide peadback asap if something pops up!

Cino

Thanks for the updates/fixes Bill!! Snort is running pretty smooth and no dup processes =D

digdug3

Updated fine a few days ago, but today Snort won't start on all of my three interfaces.
All interfaces get the same fatal error:

FATAL ERROR: /usr/pbi/snort-i386/etc/snort/snort_35802_em2/snort.conf(194) => Invalid port number.

pfSense 2.1 i386 snort 2.9.4.6 pkg v2.60

Reinstalling the package gives the same error.

bmeeks

@digdug3:

Updated fine a few days ago, but today Snort won't start on all of my three interfaces.
All interfaces get the same fatal error:

FATAL ERROR: /usr/pbi/snort-i386/etc/snort/snort_35802_em2/snort.conf(194) => Invalid port number.

pfSense 2.1 i386 snort 2.9.4.6 pkg v2.60

Reinstalling the package gives the same error.

Sounds like maybe something is corrupted in your configuration. Get a console prompt and open that file in vi. Goto line 194 and see what is shown. Post the results back if you can. The error message gives the offending line number in the text. It is 194 in this case. Did you make any changes to the configuration or edit any Aliases that may be referenced in Snort?

Bill

digdug3

No, no changes. Even put back the backup from a day before, same problems.

Here are the lines at #194 (all interfaces hang at the same line):
Line 194 is in bold:

preprocessor ftp_telnet_protocol: ftp server default
….
....
cmd_validity STRU < char FRP >
cmd_validity ALLO < int [ char R int ] >
cmd_validity TYPE < { char AE [ char NTC ] | char I | char L [ number ] } >
cmd_validity MDTM < [ date nnnnnnnnnnnnnn[.n[n[n]]] ] string >
cmd_validity PORT < host_port >

preprocessor ftp_telnet_protocol: ftp client default
max_resp_len 256
bounce yes
ignore_telnet_erase_cmds yes
telnet_cmds yes

digdug3

Ok, found the problem… (Thanks for hinting me about the aliases)
In v2.0.3 I added the FTP ports alias:
20,21 AND 15002:15018

That last one (with the semicolom) isn't supported anymore for the FTP preprocessor in the last version of the Snort package(?).

After removing the port range the interfaces all started again.

bmeeks

@digdug3:

Ok, found the problem… (Thanks for hinting me about the aliases)
In v2.0.3 I added the FTP ports alias:
20,21 AND 15002:15018

That last one (with the semicolom) isn't supported anymore for the FTP preprocessor in the last version of the Snort package(?).

After removing the port range the interfaces all started again.

Probably my bad with the last update. The port range should work. Post back exactly what your Alias looks like and let me reproduce the condition in my test VMs so I can fix it.

Thanks for reporting it,

Bill

digdug3

Here is the alias as attachment.

alias.png_thumb

bmeeks

@digdug3:

Here is the alias as attachment.

Thanks for the information. It will be a few days, but I will see if I can fix this. I have some other conflicting activities the next few days.

Bill

digdug3

Take your time. Workaround was simple. Just add the ports one by one in the alias and all was working again.
I think it is more important to fix the snort blocking issues in pfsense 2.1

bmeeks

@digdug3:

Take your time. Workaround was simple. Just add the ports one by one in the alias and all was working again.
I think it is more important to fix the snort blocking issues in pfsense 2.1

Ermal has committed to take a run at that soon. He did confirm the problem is with the filter_reload() code and not in the Snort package itself. The bad news in this good news is that means an update to pfSense itself, so we are probably looking at 2.1.1 or something for the fix.

Bill

Supermule

Then I wished they would incoporate the widescreen theme as well since it makes pfsense much better!

VoidLabs

@bmeeks:

@newbieuser1234:

Do you know roughly how often the filter_reload happens? Snort still blocks effectively correct, just allows the offending IP to attack again after the filter_reload happens?

No I don't, but I also don't think it is necessarily on a regularly scheduled basis. I really don't know much about that process. Guess I need to dig in and learn.

Bill

Filter reload is done every 15 mins.

From /etc/crontab :


0,15,30,45      *       *       *       *       root    /etc/rc.filter_configure_sync

Each time filter_configure_sync is called, the snort2c table is cleared:


[2.1-RELEASE][root@necro.necronet.local]/root(6): pfctl -t snort2c -T show
   209.31.45.2
[2.1-RELEASE][root@necro.necronet.local]/root(7): /etc/rc.filter_configure_sync
[2.1-RELEASE][root@necro.necronet.local]/root(8): pfctl -t snort2c -T show

maverick_slo

I do not have that entry in my crontab…
Checked 2 pfsense production boxes, snort is working as expected...

newbieuser1234

Something weird I noticed is on package 2.5.9 with 2.1 on 64, it is blocking just fine. But on 32 bit 2.6 on 2.1, I have the blocking issue where the table gets wiped. Do you still think it's the function filter reload? I thought it was a 2.1 issue, but maybe it's a 2.6 snort issue?

fragged

The behavior has been the same since 2.1 Snapshots. I'm running 64 bit and filter_reload will clear the snort2c table.

It's not a huge issue as the offending host will get blocked again if it tries anything fishy.

newbieuser1234

Are you running snort 2.5.9 or 2.6?

fragged

Currently 2.6.0, but also 2.5.9 and earlier before and they all behave the same in this regard.