Snort 2.9.4.6 Pkg v 2.5.9
-
Hi,
I just updated snort on my two firewalls. But I have problem when I go to Services > Snort > Alerts, then I get white side with "Fatal error: Cannot use string offset as an array in /usr/local/pkg/snort/snort.inc on line 180". I have this problem on both firewalls.My firewalls:
Version 2.0.1-RELEASE (i386)
built on Mon Dec 12 17:53:52 EST 2011
FreeBSD 8.1-RELEASE-p6Snort 2.9.4.6 pkg v. 2.5.9
NOTE:
First I deleted old snort package and then installed new.
Then I downloaded newest rule from SNORT.ORG and started snort on my both interfaces. -
Upgrade to 2.0.3 release and install again.
-
Sorry but for some reason I can't upgrade my firewalls to 2.0.3.
-
Fresh install then and copy you configuration ?
-
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.Xthen Alerts tab doesn't work.
-
Why not make it simple and use IMAP on the server so the emails can be searched and are serverside? Very easy and simple. And you could monitor the "sent Items" folder for new mails on every platform and gadget…
If you mean on the firewall itself, I'm not sure a lot of folks would agree with that paradigm. The usual idea in security circles is your firewall has the absolute minimum in terms of services so as to present a very small attack surface. So adding stuff like mail clients, databases, etc., opens up vulnerabilities.
pfSense already treads on the fine line there sometimes with all the packages available for it (Squid, Snort, etc.). Security purists would argue that a firewall should only contain the firewall code, and anything else should be a separate box. On the other hand, I understand and appreciate the utility of something more consolidated in the vein of a UTM type appliance running several related services. So to each his own as we say.
I have posted about this particular issue in the past.
IMHO this would be a great opportunity to take advantage of the BSD-jails (aka as "containers" in VM lingo, to differentiate them from hypervisors), at least until the newest BSD sandboxing technology becomes available.
http://en.wikipedia.org/wiki/FreeBSD_jail
http://www.freebsd.org/cgi/man.cgi?query=jail&sektion=8I haven't used BSD jails in recent years, but for the past 3 years I've been constantly using Linux's LXC containers.
-
Why not make it simple and use IMAP on the server so the emails can be searched and are serverside? Very easy and simple. And you could monitor the "sent Items" folder for new mails on every platform and gadget…
If you mean on the firewall itself, I'm not sure a lot of folks would agree with that paradigm. The usual idea in security circles is your firewall has the absolute minimum in terms of services so as to present a very small attack surface. So adding stuff like mail clients, databases, etc., opens up vulnerabilities.
pfSense already treads on the fine line there sometimes with all the packages available for it (Squid, Snort, etc.). Security purists would argue that a firewall should only contain the firewall code, and anything else should be a separate box. On the other hand, I understand and appreciate the utility of something more consolidated in the vein of a UTM type appliance running several related services. So to each his own as we say.
I have posted about this particular issue in the past.
IMHO this would be a great opportunity to take advantage of the BSD-jails (aka as "containers" in VM lingo, to differentiate them from hypervisors), at least until the newest BSD sandboxing technology becomes available.
http://en.wikipedia.org/wiki/FreeBSD_jail
http://www.freebsd.org/cgi/man.cgi?query=jail&sektion=8I haven't used BSD jails in recent years, but for the past 3 years I've been constantly using Linux's LXC containers.
The jails could be a workable idea. However, the Spoink plugin on Snort does some things to implement the blocking that might be problematic from within a jail. I honestly don't know enough to say for sure, though. Other packages may work fine from within a jail.
Bill
-
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.Xthen 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
-
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 firewalli dont even use the smtp preprocessor
-
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 firewalli 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 restartThis may show a better error message.
Bill
-
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 … -
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_pktsNotice 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
-
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.
-
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?
-
Check the System Log what's going on.
-
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
-
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
 -
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 barnyard2Barnyard2 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.logPost 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
-
So it updated and it didnt crash. I can only assume that line was the issue. Thanks for the help
-
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
