Snort 2.9.4.6 Pkg v 2.5.9
-
A simple script to send the mail using supplied credentials. Nothing more.
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.
Bill
-
35928 ?? SNs 0:18.39 /usr/pbi/snort-amd64/bin/snort -R 5428 -D -q -l /var/log/snort/snort_em05428 --pid-path /var/run --nolock-pidfile -G 5428 -c /usr/pbi/snort-a 74130 ?? Ss 0:34.05 /usr/pbi/snort-amd64/bin/snort -R 5428 -E -q -l /var/log/snort/snort_em05428 --pid-path /var/run --nolock-pidfile -G 5428 -c /usr/pbi/snort-a 76150 ?? Ss 0:08.80 /usr/pbi/snort-amd64/bin/snort -R 47828 -D -q -l /var/log/snort/snort_em147828 --pid-path /var/run --nolock-pidfile -G 47828 -c /usr/pbi/snor 77552 ?? Ss 0:00.30 /usr/pbi/snort-amd64/bin/snort -R 12845 -D -q -l /var/log/snort/snort_em1_vlan212845 --pid-path /var/run --nolock-pidfile -G 12845 -c /usr/pb 25231 0 R+ 0:00.00 grep snortYou have two duplicate Snort processes running (well, I really mean running on the same interface). They are:
35928 ?? SNs 0:18.39 /usr/pbi/snort-amd64/bin/snort -R 5428 -D -q -l /var/log/snort/snort_em05428 --pid-path /var/run --nolock-pidfile -G 5428 -c /usr/pbi/snort-a 74130 ?? Ss 0:34.05 /usr/pbi/snort-amd64/bin/snort -R 5428 -E -q -l /var/log/snort/snort_em05428 --pid-path /var/run --nolock-pidfile -G 5428 -c /usr/pbi/snort-aNotice both are on interface em0 (I can tell by looking at the log path, since it names that with the interface name in the string). It looks like one is in daemon mode (the one with -D in the command string) and the other is not. Both are running against the same interface using the same rules, so that's why you are getting the duplicate alerts. I would do a pkill on process ID 74130, or else just reboot the firewall if you can. I've never seen that condition before and have no idea how it could have happened. The second set of two Snort processes on interface em1 are OK. One is the primary and the other is a VLAN running on em1, so they are really like two separate interfaces. Those first two; however, are not differentiated by a VLAN.
Bill
-
I could not. did not happen. (2.1 x64)
And return 2.0.3 x86.
Same system, same rules. No problem. But i seen double logging to system logs.
My rules:
Wan:Blue(+ET Cairmy&ET RBN)
LAN&VLAN:Red
All other rules are the default
-
I could not. did not happen. (2.1 x64)
I'm not sure what you mean with the reply above. Do you mean you could not kill the process, or you could not reboot the firewall? Or did you do one or the other and it still did the same thing?
One other related question, you mention "rolling back" to 2.0.3, so did you upgrade the firewall and Snort together or separately? If you are going from 32-bit to 64-bit, then I would definitely remove Snort (and all packages), upgrade the firewall OS, then reinstall the packages. I can see where, if you upgraded to 64-bit firmware with the packages in place, this could have happened. The firmware upgrade always does a "reinstall" of existing packages. The problem is that 2.1 packages are PBI form and they get stored in a different path. So if the old Snort 2.9.4.1 was left installed from the 32-bit image, then you upgraded to a 64-bit image in-place, you could wind up with two Snort installs in different directories using the same configuration. The package reinstall step the 64-bit firmware upgrade does would have installed Snort in the new PBI path (since the platform would be 2.1). But if you never removed the 32-bit version, it could be left hanging around in /usr/local/etc/snort.
Snort on any 2.0.x platform stores its config in /usr/local/etc/snort. A Snort install on 2.1 pfSense will put its config in /usr/pbi/snort-i386 or /usr/pbi/snort-amd64 depending on platform. Both will reference and use the same config.xml file data and thus would fire up on the same interface. This could maybe explain your scenario.
If you are game to try, remove Snort completely (click the X icon on Installed Packages), upgrade the firewall to 2.1 64-bit, then reinstall Snort from Available Packages.
And return 2.0.3 x86.
Same system, same rules. No problem. But i seen double logging to system logs.Double-logging of system log entries is and has been a quirk of 2.0.x. Note that even some non-Snort things are also double logged (for example, the web configurator login at the very bottom of your screenshot).
Bill
-
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
