Snort 2.9.4.6 pkg v. 2.6.1 cannot get VRT updates

shpokas

Hi!
I see most topics are about snort. Hopefully because snort is the most wanted package, not because it has a lot of problems :)

I just installed snort, registered myself and got OINK code. But snort cannot get VRT updates, because it does not specify version number in snapshot file…

This is the line from update log file.
Starting rules update… Time: 2013-12-04 10:59:05
Downloading Snort VRT md5 file 'snortrules-snapshot-.tar.gz.md5'…

Note there is no version number.

Should I configure that myself and how?

Thanks for your time!
shpokas

fragged

Try reinstalling Snort. Also make sure you are on either 2.0.3 or 2.1 version of pfSense.

shpokas

Thanks for reply!
Reinstalled snort at least three times, no change.
pfSense is 2.1, actually, fresh install, just a week ago. i386/32-bit.

bmeeks

@shpokas:

Thanks for reply!
Reinstalled snort at least three times, no change.
pfSense is 2.1, actually, fresh install, just a week ago. i386/32-bit.

Something is definitely not right with the install. The rule file version set up near the top of the snort.inc file. The file is located in /usr/local/pkg/snort. I am currently not able to check the source code now, but can later tomorrow. In older versions the value is hard-coded. In the latest version it is grabbed from the Snort binary using some bash magic.

Bill

shpokas

got any chance to check the script?

bmeeks

@shpokas:

got any chance to check the script?

Sorry for the late reply. For version 2.6.1 of the Snort package, the rules snapshot version is set in the file /usr/local/pkg/snort/snort_check_for_rule_updates.php. Here is the section of code that gets the binary version of Snort and uses it to construct the rules snapshot filename.

/* Grab the Snort binary version programmatically and use it to construct */
/* the proper Snort VRT rules tarball and md5 filenames.                  */
exec("/usr/local/bin/snort -V 2>&1 |/usr/bin/grep Version | /usr/bin/cut -c20-26", $snortver);
// Save the version with decimal delimiters for use in extracting the rules
$snort_version = $snortver[0];
// Create a collapsed version string for use in the tarball filename
$snortver[0] = str_replace(".", "", $snortver[0]);
$snort_filename = "snortrules-snapshot-{$snortver[0]}.tar.gz";

Open up this file in the editor under Diagnostics…Edit and see if it matches the above. If you want, you can hard-code the rules snapshot by changing the line:

$snort_filename = "snortrules-snapshot-{$snortver[0]}.tar.gz";

to read

$snort_filename = "snortrules-snapshot-2946.tar.gz";

However, this should not be necessary. I suspect something else went south with your installation somehow. As a test, open a console session with the firewall and issue this command from a console prompt.

/usr/bin/grep Version | /usr/bin/cut -c20-26

It should return the string "2.9.4.6". Let me know what you find out.

Bill

shpokas

Well, looks like things are not working as expected (did anyone tested?).

Indeed, file /usr/local/pkg/snort/snort_check_for_rule_updates.php contains line
exec("/usr/local/bin/snort -V 2>&1 |/usr/bin/grep Version | /usr/bin/cut -c20-26", $snortver);

Executing /usr/local/bin/snort -V 2>&1 |/usr/bin/grep Version yields just
Ambiguous output redirect.

Should this be filed as a bug? :-\

Obviously, snort deploys some fancy outputting as grep has no impact on it's output

[2.1-RELEASE][edited]: /usr/local/bin/snort -V | /usr/bin/grep Version

   ,,_     -*> Snort! <*-
  o"  )~   Version 2.9.4.6 GRE (Build 73) FreeBSD
   ''''    By Martin Roesch & The Snort Team: http://www.snort.org/snort/snort-team
           Copyright (C) 1998-2013 Sourcefire, Inc., et al.
           Using libpcap version 1.0.0
           Using PCRE version: 8.33 2013-05-28
           Using ZLIB version: 1.2.3

[2.1-RELEASE][edited]:

This is on the contrary to other programs, like grep itself

[2.1-RELEASE][edited]: grep --version | grep Cop
Copyright 1988, 1992-1999, 2000, 2001 Free Software Foundation, Inc.

[2.1-RELEASE][edited]: grep --version 
grep (GNU grep) 2.5.1-FreeBSD

Copyright 1988, 1992-1999, 2000, 2001 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[2.1-RELEASE][edited]:

bmeeks

@shpokas:

Well, looks like things are not working as expected (did anyone tested?).

Indeed, file /usr/local/pkg/snort/snort_check_for_rule_updates.php contains line
exec("/usr/local/bin/snort -V 2>&1 |/usr/bin/grep Version | /usr/bin/cut -c20-26", $snortver);

Executing /usr/local/bin/snort -V 2>&1 |/usr/bin/grep Version yields just
Ambiguous output redirect.

Should this be filed as a bug? :-\

No, not a bug. My fault that I gave you the /bin/sh syntax, but the default command-line shell is tsh. It does not honor the same syntax. To replicate the command you would need to run the other shell. Have you tried completely removing Snort by clicking the X icon on the Installed Packages tab, and then reinstalling it? I can't reproduce your issue of not being able to download rules. I have it working on 2.0.3, 2.1 32-bit and 2.1 64-bit virtual machines. All download the Snort 2946 rules snapshot just fine.

If you want to force-fit the rules version, then make the edits I suggested in the snort_check_for_rule_updates.php file and save it.

Bill

shpokas

@bmeeks:

No, not a bug. My fault that I gave you the /bin/sh syntax, but the default command-line shell is tsh. It does not honor the same syntax. To replicate the command you would need to run the other shell.

tsh? tcsh?
Did not find tsh on my pfSense with find / -iname tsh
actually, my and root's default shell is tcsh

[2.1-RELEASE][admin@pfsense]/root(2): tcsh
[2.1-RELEASE][admin@pfsense]/root(1):  /usr/local/bin/snort -V 2>&1 |/usr/bin/grep Version 
Ambiguous output redirect.

Have you tried completely removing Snort by clicking the X icon on the Installed Packages tab, and then reinstalling it?

Yes. No effect. I can try to fix version by hand, of course. But I'd rather understand why it does not work in the first place.
And I have replicated the same problem on another pfSense installation - I have two, actually.

shpokas

Update
changing script easily fixes the problem, still, I am sure this is a bug.

// exec("/usr/local/bin/snort -V 2>&1 |/usr/bin/grep Version | /usr/bin/cut -c20-26", $snortver);
// Save the version with decimal delimiters for use in extracting the rules
$snortver[0]="2.9.4.6";

bmeeks

@shpokas:

@bmeeks:

No, not a bug. My fault that I gave you the /bin/sh syntax, but the default command-line shell is tsh. It does not honor the same syntax. To replicate the command you would need to run the other shell.

tsh? tcsh?
Did not find tsh on my pfSense with find / -iname tsh
actually, my and root's default shell is tcsh
[2.1-RELEASE][admin@pfsense]/root(2): tcsh
[2.1-RELEASE][admin@pfsense]/root(1):  /usr/local/bin/snort -V 2>&1 |/usr/bin/grep Version 
Ambiguous output redirect.

Sorry. Typing too fast. Meant tcsh. This command does not run "as written" from a plain command line. It does work within PHP, though, because it uses a different shell.

Bill

bmeeks

@shpokas:

Update
changing script easily fixes the problem, still, I am sure this is a bug.

I will try again to reproduce with a clean install. There are many users here on the Forum using this package, and it is working for them. This is the first report of this problem.

Give me the sequence of steps you perform in order for an install and then rule update.

Thanks,
Bill

shpokas

@bmeeks:

Give me the sequence of steps you perform in order for an install and then rule update.
Thanks,
Bill

I am truly baffled. I installed pfSense in a virtual machine and snort rule update works there.
But in my two production installations it does not ::)
I was surprised to see that I am probably the only one with this problem. I am not in a position to trash the router and setup again, but something is not right, yet I have to figure this out.
Actually, it got even worse. In one installation after I fixed version variable, updates are downloaded, but update status still shows as N/A.
SNORT VRT RULES –> N/A

The other one works fine.

Thanks for help, though.

bmeeks

@shpokas:

@bmeeks:

Give me the sequence of steps you perform in order for an install and then rule update.
Thanks,
Bill

I am truly baffled. I installed pfSense in a virtual machine and snort rule update works there.
But in my two production installations it does not ::)
I was surprised to see that I am probably the only one with this problem. I am not in a position to trash the router and setup again, but something is not right, yet I have to figure this out.
Actually, it got even worse. In one installation after I fixed version variable, updates are downloaded, but update status still shows as N/A.
SNORT VRT RULES –> N/A

The other one works fine.

Thanks for help, though.

The same type of code is used in both places to determine the version of the rules snapshot file to check and download (both the MD5 hash file and the actual rules tar ball). So whatever is going on will likely affect both places in your system. Are there any other packages or other customizations installed on the non-working machines? Perhaps something is altering the way PHP is behaving with its shell.

You can hand-fix the same version variable for the update status in the file /usr/local/www/snort/snort_download_updates.php. Make the change like you did in the other file.

BTW, virtual machines are where I do all my testing of new releases. I do run a production instance for my home network firewall, but I usually install there after a package update is pushed to the pfSense package repository.

Bill

shpokas

In the end, after removing-rebooting-reinstalling and manual version fixing, it just does not start :)
I'm kind of tired.

bmeeks

@shpokas:

In the end, after removing-rebooting-reinstalling and manual version fixing, it just does not start :)
I'm kind of tired.

This is truly baffling. Is your box an Intel CPU or AMD? That should not matter, but just wondering.

You said it worked for you in a VMware virtual machine, but not on your physical machine. That is weird. Are you using the exact same install media in both cases, or is one an ISO and the other a burned CD or USB memory stick? Just looking for any variables to see if something sticks out.

Bill

shpokas

I have two physical pfSense boxes and a test one on VM.
Update works only in VM. Snort works only in VM and in one physical box.

@bmeeks:

This is truly baffling. Is your box an Intel CPU or AMD? That should not matter, but just wondering.

Intel(R) Pentium(R) 4 CPU 3.06GHz
@bmeeks:

You said it worked for you in a VMware virtual machine, but not on your physical machine. That is weird. Are you using the exact same install media in both cases, or is one an ISO and the other a burned CD or USB memory stick? Just looking for any variables to see if something sticks out.

Should be the same media as I downloaded iso just once.
Actually, the "working" box had been installed a long time ago and only upgraded to 2.1.
"Problematic" one is fresh install :)

Now I have discovered that symlink to /usr/local/bin/snort is gone :-[
But that's not all. When I execute /usr/pbi/snort-i386/.sbin/snort, nothing happens. With switches or without, just nothing. Size of the file is the same as on the other machine where snort is working.
Time to reinstall again.
Will be back with update 8)

bmeeks

@shpokas:

"Problematic" one is fresh install :)

Now I have discovered that symlink to /usr/local/bin/snort is gone :-[
But that's not all. When I execute /usr/pbi/snort-i386/.sbin/snort, nothing happens. With switches or without, just nothing. Size of the file is the same as on the other machine where snort is working.
Time to reinstall again.
Will be back with update 8)
[/quote]

That really sounds like the PBI package manager is hosed up somehow. The new 2.1 pfSense uses PBI packages that more or less put each installed package in its own chroot environment. This way the packages can't interfere with each other's shared libraries and such. As you have noticed, there should be a working symlink from /usr/local/bin/snort pointing to /usr/pbi/snort-i386/.sbin/snort. If that symlink won't properly execute the command "snort -V", then that is what is wrong with the update process. Can also be why Snort won't start properly either.

Bill