Snort 2.9.4.6 Pkg v 2.5.9

bmeeks

OK, fresh installation and then restore from config file get the same resultant.
So I installed fresh installation and installed snort. It works. But when I added my supperss list I received the same error.

In my case problem is when I have this two line:
suppress gen_id 120, sig_id 3
suppress gen_id 120, sig_id 3, track by_src, ip X.X.X.X

then Alerts tab doesn't work.

Unfortunately you are likely hitting a problem with the PHP version on 2.0.1, and this may not be fixable without upgrading. Getting a "string offset error" as you described sounds most like a PHP incompatibility with some function being called in the Snort GUI code. Something is apparently different in the way 2.0.3 and 2.1 boxes handle the PHP code as compared to the older 2.0.1 boxes.

I will take a look at the offending line (snort.inc, line 180) to see for sure. If it is something I might can address easily, I will post back.

UPDATE: I looked at the code, and from what I can see (unless I'm blindly overlooking something simple) the code is OK. The variable being set on the line where you see the error on 2.0.1 is declared earlier as an array(). From Google searches on the error, that is supposed to be the cause (using a variable as if it's an array without actually declaring it as such). That does not appear to be the case here. Furthermore, it seems to work OK on 2.0.3 and 2.1 machines. My only guess at this point is something strange in the PHP version installed on 2.0.1.

Bill

shinzo

Here's a new one for you.

Jun 29 02:43:43 kernel: em0: promiscuous mode disabled
Jun 28 02:43:43 kernel: pid 25038 (snort), uid 0: exited on signal 11
Jun 28 02:43:43 snort[25038]: SMTP reload: Changing the file_depth requires a restart.
Jun 28 02:43:43 snort[25038]: SMTP reload: Changing the file_depth requires a restart.
Jun 28 02:43:41 php: /snort/snort_alerts.php: [Snort] Snort RELOAD CONFIG for RED(em0)…
Jun 28 02:43:41 check_reload_status: Syncing firewall

i dont even use the smtp preprocessor

bmeeks

@shinzo:

Here's a new one for you.

Jun 29 02:43:43 kernel: em0: promiscuous mode disabled
Jun 28 02:43:43 kernel: pid 25038 (snort), uid 0: exited on signal 11
Jun 28 02:43:43 snort[25038]: SMTP reload: Changing the file_depth requires a restart.
Jun 28 02:43:43 snort[25038]: SMTP reload: Changing the file_depth requires a restart.
Jun 28 02:43:41 php: /snort/snort_alerts.php: [Snort] Snort RELOAD CONFIG for RED(em0)…
Jun 28 02:43:41 check_reload_status: Syncing firewall

i dont even use the smtp preprocessor

These two messages are informational warnings:

Jun 28 02:43:43	snort[25038]: SMTP reload: Changing the file_depth requires a restart.
Jun 28 02:43:43	snort[25038]: SMTP reload: Changing the file_depth requires a restart.

I believe they are bogus. I searched through the Snort binary's source code and couldn't find why this was triggered. In fact, I could never find the "file_depth" parameter at all associated with the SMTP Preprocessor.

The "…exited on signal 11..." message obviously means Snort died hard. I'm guessing this may have happened after an automatic rules update and a newly enabled rule might have caused it, but there are lots of other possibilities. Try starting Snort from the command line using this command --

/usr/local/etc/rc.d/snort.sh restart

This may show a better error message.

Bill

shinzo

I went as far back as i could so u can see the chain of events. I doubled checked, and the smtp normalizer was on. I disabled it, i will let you know if it happens again. Seems to happen after a update, but it doesnt happen all the time.

Logs
Jun 28 02:45:09 php: /snort/snort_interfaces.php: [Snort] Snort START for RED(em0)…
Jun 28 02:45:09 php: /snort/snort_interfaces.php: [Snort] Building new sig-msg.map file for WAN…
Jun 28 02:45:02 php: /snort/snort_preprocessors.php: [Snort] Building new sig-msg.map file for WAN…
Jun 28 02:45:02 php: /snort/snort_interfaces.php: [Snort] Updating rules configuration for: WAN …
Jun 28 02:45:02 php: /snort/snort_interfaces.php: Toggle (snort starting) for WAN(RED)...
Jun 28 02:44:53 php: /snort/snort_preprocessors.php: [Snort] Updating rules configuration for: WAN …
Jun 28 02:43:43 kernel: pid 25038 (snort), uid 0: exited on signal 11
Jun 28 02:43:43 snort[25038]: SMTP reload: Changing the file_depth requires a restart.
Jun 28 02:43:43 snort[25038]: SMTP reload: Changing the file_depth requires a restart.
Jun 28 02:43:41 php: /snort/snort_alerts.php: [Snort] Snort RELOAD CONFIG for RED(em0)…
Jun 28 02:35:27 php: /snort/snort_interfaces.php: [Snort] Snort START for RED(em0)…
Jun 28 02:35:27 php: /snort/snort_interfaces.php: [Snort] Building new sig-msg.map file for WAN…
Jun 28 02:35:20 php: /snort/snort_interfaces.php: [Snort] Updating rules configuration for: WAN …
Jun 28 02:35:20 php: /snort/snort_interfaces.php: Toggle (snort starting) for WAN(RED)...
Jun 28 02:34:44 kernel: pid 12518 (snort), uid 0: exited on signal 11
Jun 28 02:34:43 snort[12518]: SMTP reload: Changing the file_depth requires a restart.
Jun 28 02:34:43 snort[12518]: SMTP reload: Changing the file_depth requires a restart.
Jun 28 02:34:42 php: /snort/snort_alerts.php: [Snort] Snort RELOAD CONFIG for RED(em0)…
Jun 28 02:34:33 php: /snort/snort_preprocessors.php: [Snort] Building new sig-msg.map file for WAN…
Jun 28 02:34:26 php: /snort/snort_preprocessors.php: [Snort] Updating rules configuration for: WAN …
Jun 28 02:34:15 php: /snort/snort_preprocessors.php: [Snort] Building new sig-msg.map file for WAN…
Jun 28 02:34:05 php: /snort/snort_preprocessors.php: [Snort] Updating rules configuration for: WAN …
Jun 28 02:32:56 php: /snort/snort_preprocessors.php: [Snort] Building new sig-msg.map file for WAN…
Jun 28 02:32:47 php: /snort/snort_preprocessors.php: [Snort] Updating rules configuration for: WAN …
Jun 28 02:32:04 php: /snort/snort_preprocessors.php: [Snort] Building new sig-msg.map file for WAN…
Jun 28 02:31:56 php: /snort/snort_preprocessors.php: [Snort] Updating rules configuration for: WAN …

bmeeks

@shinzo:

I went as far back as i could so u can see the chain of events. I doubled checked, and the smtp normalizer was on. I disabled it, i will let you know if it happens again. Seems to happen after a update, but it doesnt happen all the time.

Snort rules and the preprocessors are inexorably intertwined with dependencies on dependencies with each other.. :D

That means as you get rule updates, and particular rules are enabled that might have previously been disabled, or new rules are added, or existing ones have new rule options added; you can run into a situation where a required preprocessor is not enabled but needed. There is also the case that certain configuration changes can only be read by Snort on a full restart. When these two circumstances line up you can get some Snort shutdowns. It's a complicated beast with many moving parts (the binary side, I mean).

You can try posting the error (changing file_depth requires restart) on the Snort mailing list to see if someone has seen it. I will do some more research myself. I did find, today while working on the new multi-engine configuration upgrade, a typo in the snort.inc file in the section that generates the stream5_tcp parameters in the snort.conf file. A pair of braces {} are missing from a quoted string. I doubt that's at play in your case, but who knows? If you want to correct the typo and see if it matters, here's how.

Open /usr/local/pkg/snort/snort.inc in an editor (vi from command line is best since we need to find a specific line number)

Locate line 3137 in the file. It's a long line. The very end is shown below.

Bad Ending

{$stream5_no_reassemble_async}$stream5_dont_store_lg_pkts

Notice the final variable $stream5_dont_store_lg_pkts is missing the enclosing braces {}. Add those and save the file. It should then look like this:

Good Ending

{$stream5_no_reassemble_async}{$stream5_dont_store_lg_pkts}

Bill

shinzo

I made the correction. I will see in the morning after the update if it crashes again. Its most likely because i am running the current_events rule. Most of those are off except for the dns ampliication. Every time it updates, it usually adds a new rule in there which is enabled by default.

masli

The new Snort , is working well. However , there is small issue which is the snort interface did not auto start after system restart I have to restart it manually. Any advice?

traxxus

Check the System Log what's going on.

bmeeks

@masli:

The new Snort , is working well. However , there is small issue which is the snort interface did not auto start after system restart I have to restart it manually. Any advice?

If you have more than one Snort-enabled interface and are running a large rule set, it can take Snort up to a couple of minutes to get cranked up on all the interfaces. So depending on how quickly you navigate to the Snort Interfaces tab after startup, you may find an interface still showing the red "stopped" icon. But if you go view the System Log you should see some evidence of the interfaces coming up. Eventually, if you refresh the Snort Interfaces tab a time or two, the icons should all be green (for running).

If not, then as suggested by others, check the System Log to see if any messages printed there will give a clue.

Bill

cjbujold

Follow-up to the last post, If you wait the icons do turn green for snort, however the barnyard icon never turns green in my case. When I look at the log Barnyard seems to be started but this is not shown on the screen. Is Barnyard really working???? How can I verify if it is working?

Jul 1 10:02:01 SnortStartup[43369]: Snort START for Accra -Snort(2472_em0)…
Jul 1 10:02:01 check_reload_status: Syncing firewall
Jul 1 10:02:02 check_reload_status: Reloading filter
Jul 1 10:03:38 kernel: em0: promiscuous mode enabled
Jul 1 10:03:42 SnortStartup[17594]: Barnyard2 START for Accra -Snort(2472_em0)…

Thanks

cjb

![2013-07-01 10-07-24 AM.png](/public/imported_attachments/1/2013-07-01 10-07-24 AM.png)
![2013-07-01 10-07-24 AM.png_thumb](/public/imported_attachments/1/2013-07-01 10-07-24 AM.png_thumb)

bmeeks

@cjbujold:

Follow-up to the last post, If you wait the icons do turn green for snort, however the barnyard icon never turns green in my case. When I look at the log Barnyard seems to be started but this is not shown on the screen. Is Barnyard really working???? How can I verify if it is working?

Jul 1 10:02:01 SnortStartup[43369]: Snort START for Accra -Snort(2472_em0)…
Jul 1 10:02:01 check_reload_status: Syncing firewall
Jul 1 10:02:02 check_reload_status: Reloading filter
Jul 1 10:03:38 kernel: em0: promiscuous mode enabled
Jul 1 10:03:42 SnortStartup[17594]: Barnyard2 START for Accra -Snort(2472_em0)…

Thanks

cjb

One way is from the console. Issue this command and see if a barnyard2 process shows up –

ps -ax |grep barnyard2

Barnyard2 on my system is very noisy (as in logs lots of semi-useless startup messages). If it is actually starting, you should see a number of system log messages.

Make sure your database credentials are correctly set and that it can connect to the MySQL database. From the console on the firewall, grep the system log for any barnyard2 messages as follows:

grep barnyard /var/log/system.log

Post back any pertinent findings or clues. Could be a shared library issue where something stepped on a library barnyard2 needs. Is this a 2.0.x or 2.1 pfSense box?

Bill

shinzo

So it updated and it didnt crash. I can only assume that line was the issue. Thanks for the help

cjbujold

Bill,

I am using PFSense 2.0.3-RELEASE (amd64)

Here is what I receive when I check for Barnyard

$ ps -ax |grep barnyard2
34971 ?? S 0:00.00 sh -c ps -ax |grep barnyard2
35558 ?? S 0:00.00 grep barnyard2

$ grep barnyard /var/log/system.log
Jul 1 08:37:15 protector php: /snort/snort_interfaces.php: Toggle (barnyard starting) for WAN(Accra -Snort)…
Jul 1 08:40:44 protector php: /snort/snort_interfaces.php: Toggle (barnyard starting) for WAN(Accra -Snort)...
Jul 1 08:52:14 protector php: /snort/snort_interfaces.php: Toggle (barnyard starting) for WAN(Accra -Snort)...

Thanks for the help

cjb

bmeeks

@shinzo:

So it updated and it didnt crash. I can only assume that line was the issue. Thanks for the help

Thanks for the feedback. I've fixed that line in my source code repository. I have that one and another small fix I will submit in the near future, but won't bump the package version number so it won't show as a new package update.

I am making good progress on the multi-engine configurations. I'm finished with HTTP_INSPECT, FRAG3 and STREAM5. Also saw Snort 2.9.5 was posted yesterday by the Snort.org guys. Will most likely wait and release the new multi-engine Snort with an update to the 2.9.5 binary, but need to wait until the 2.9.5 rules are available for the registered, free users at Snort.org. Don't want to repeat the mistake of last time when the binary got updated ahead of the new rules being available for the registered users (the subscriber users always get the latest rules immediately).

Bill

bmeeks

@cjbujold:

Bill,

I am using PFSense 2.0.3-RELEASE (amd64)

Here is what I receive when I check for Barnyard

$ ps -ax |grep barnyard2
34971 ?? S 0:00.00 sh -c ps -ax |grep barnyard2
35558 ?? S 0:00.00 grep barnyard2

$ grep barnyard /var/log/system.log
Jul 1 08:37:15 protector php: /snort/snort_interfaces.php: Toggle (barnyard starting) for WAN(Accra -Snort)…
Jul 1 08:40:44 protector php: /snort/snort_interfaces.php: Toggle (barnyard starting) for WAN(Accra -Snort)...
Jul 1 08:52:14 protector php: /snort/snort_interfaces.php: Toggle (barnyard starting) for WAN(Accra -Snort)...

Thanks for the help

cjb

OK, your barnyard2 instance is not starting up. It's trying, but then dies badly since there is no further logging. My first guess is that something (another package perhaps) has stepped on a shared library. Try removing (deleting) and reinstalling Snort to see if that helps. Just click the "save settings on deinstall" checkbox on the Global Settings tab first, and you won't lose your Snort configuration. It's possible, though, that the Snort remove and reinstall still won't fix the shared library if it's marked as "in use" by another package.

If that does not work (or you have already tried it), then we need to try starting barnyard2 from the command line to see if it will give us some clues. From a console prompt just type "barnyard2" and ENTER. If it makes it far enough into starting, it will fuss about no configuration file. However, I'm going to guess it barfs first with a missing or wrong version library. Post back with the results.

Bill

P.S. – I don't remember the details, but seems like another user had barnyard2 troubles a while back that were traced to a shared library conflict. You might try a search on the Forum to see if you find it. It was maybe 2 or 3 months back (definitely from this year, though).

shinzo

I am making good progress on the multi-engine configurations. I'm finished with HTTP_INSPECT, FRAG3 and STREAM5. Also saw Snort 2.9.5 was posted yesterday by the Snort.org guys. Will most likely wait and release the new multi-engine Snort with an update to the 2.9.5 binary, but need to wait until the 2.9.5 rules are available for the registered, free users at Snort.org. Don't want to repeat the mistake of last time when the binary got updated ahead of the new rules being available for the registered users (the subscriber users always get the latest rules immediately).

Bill

Good to hear that they are finished. Can you post screenshots of how they are going to look?. Yes it would be best to hold out on the update until everyone is able to get the rules. The snort manual got updated too which is nice also. Anyway thanks again.

cjbujold

barnyard problem update

Tried removing and re-installing package same error the error is:

/libexec/ld-elf.so.1: Shared object "libmysqlclient.so.18" not found required by "barnyard2".

How can I install it, since a re-install does not do the trick.

Thanks for the help

cjb

fragged

It's a problem with the 2.0.X package manager system. With 2.1's PBI's things usually remove and install in a more sane way. With 2.0.X packages might share some of the additional components and things might break because of that.

bmeeks

@fragged:

It's a problem with the 2.0.X package manager system. With 2.1's PBI's things usually remove and install in a more sane way. With 2.0.X packages might share some of the additional components and things might break because of that.

fragged is correct. On the 2.0.x platform, libraries such as MySQL and others are shared among applications. It's a condition not all that unlike the "DLL Hell" that existed in Windows where different versions of the same DLL stored in different places caused all kinds of grief.

The 2.1 platform with PBI sort of puts each application and all of its "shared libraries" into a type of "jail" where they appear to be shared for the application, but really aren't. Each app has its own copy of the libraries in a dedicated directory tree isolated from other apps.

First up, run this command on the console to see what version of MySQL is actually installed on your box:

pkg_info | grep mysql

It should come back and say mysql-client-5.5.30. My guess is yours will come back with something different. If it does, then run this command to see what installed the version you have (the backslashes and asterisks are required and act as wildcards):

pkg_info \*mysql*\

Look for the "Required by:" line. That will show what other package might be using MySQL on your box. Again, the correct response there would be:

Required by:
barnyard2-1.12

Run the commands above and post back one more time. You can also check out this post from jimp showing the best way to fix these shared library issues on 2.0.x: http://forum.pfsense.org/index.php/topic,63253.msg342512.html#msg342512

Bill

cjbujold

barnyard issue:

Ran the first command and got back the following:

mysql-client-5.1.53-multitreaded sql database(client)
mysql-client-5.1.57-multitreaded sql database(client)
mysql-client-5.5.29-multitreaded sql database(client)
mysql-client-5.6.30-multitreaded sql database(client)

Ran the second command and got back:

pkg_info: No match

Then removed snort again and ran from the shell the command:

pkg_delete -f *snort* *barny* *mysql*

Re-installed snort

and Now I receive the following error in the log and barnyard does not start

Jul 4 10:29:05 barnyard2[8071]: Writing PID "8071" to file "/var/run/barnyard2_em02472.pid"
Jul 4 10:29:05 barnyard2[8071]: FATAL ERROR: database mysql_error: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)
Jul 4 10:29:05 barnyard2[8071]: FATAL ERROR: database mysql_error: Can't connect to local MySQL server through socket '/tmp/mysql.sock' (2)

This is the setting for MYSQL in Snort for barnyard

output database: alert, mysql, dbname=snort user=snort host=localhost password=xyz

When I re-run the first command I now get:

mysql-client-5.5.30-multitreaded sql database(client) - This is good!!!

The second command still comes with "No Match" - Not so GOOD!!!

Any suggestions on how to fix? Thanks

cjb