Snort 2.9.4.6 Pkg v 2.5.9
-
[When doing some research yesterday i noticed someone had a list of ip addresses with the service/port next to them for the host attribute table. A suggestion i have is to have a viewlist tab with what has been setup there. I will post an example later in the day
[/quote]That's a good idea. There definitely needs to be a better way to view/edit the Host Attribute Table. What's there now was just quick and easy to get the feature out the door. I will be happy to entertain suggestions for improvement.
Bill
The table i saw looked like this
192.168.1.1, Linux, 23|tcp|telnet 53|tcp|domain 443|tcp|ssl/http
192.168.1.2, Linux, 23|tcp|telnet 53|tcp|domain 443|tcp|ssl/http
192.168.1.7, FreeBSD, 22|tcp|ssh 53|tcp|domain 80|tcp|http 3000|tcp|http 3128|tcp|http-proxy 3306|tcp|mysql 5000|tcp|http-proxy 8443|tcp|httpAn example for a view table. Just an idea 8)
-
Could it be an idea to have a list of IP's that could be monitored for triggering events?
Like clients having IP's that gets triggered in Snort and then be able to send alerts to either the admin or both admin and client?
Like you have been caught in the firewall triggering this event: bla bla bla. Contact Support for solving issues.
Another good idea! Maybe something where you could enter an IP or IP block and an associated contact e-mail. A cron job would fire periodically, review the Alerts table, and fire off an e-mail to the contact.
It would take a little thought to be able to keep track of who was notified and when. You would not want to spam the contact with e-mail notes over and over. Might be better to spawn this idea off into a new and separate package that used a MySQL backend to store the data. And like barnyard2 with Snort, the MySQL backend would be on a different box. You don't want your firewall becoming a DB server. The new package could still scan the Snort alert log, but just do all of its other processing in the MySQL backend someplace else.
I'm not familiar with all the options in barnyard2, either. Could be that such a capability exists there already with the right plugin.
Bill
-
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…
-
Could it be an idea to have a list of IP's that could be monitored for triggering events?
Like clients having IP's that gets triggered in Snort and then be able to send alerts to either the admin or both admin and client?
Like you have been caught in the firewall triggering this event: bla bla bla. Contact Support for solving issues.
Another good idea! Maybe something where you could enter an IP or IP block and an associated contact e-mail. A cron job would fire periodically, review the Alerts table, and fire off an e-mail to the contact.
It would take a little thought to be able to keep track of who was notified and when. You would not want to spam the contact with e-mail notes over and over. Might be better to spawn this idea off into a new and separate package that used a MySQL backend to store the data. And like barnyard2 with Snort, the MySQL backend would be on a different box. You don't want your firewall becoming a DB server. The new package could still scan the Snort alert log, but just do all of its other processing in the MySQL backend someplace else.
I'm not familiar with all the options in barnyard2, either. Could be that such a capability exists there already with the right plugin.
Bill
Or have it log the event and have the events sent to a log server and let that server notify set on the applicable criteria. I do that with my firewall already. I have it parse the alerts and notify me only on the ones I really want to.
-
Hi,
Same time double alert.
Is this normal?
-
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
-
Hi,
Same time double alert.
Is this normal?No, that would not be normal. My first thought is perhaps two instances of Snort are running against the same interface. Run this command from the firewall console (via SSH or directly from the console if you have a keyboard and monitor connected):
ps -ax | grep snortYou should see exactly one instance of Snort for each interface on your firewall where you have it enabled. You will also have one line showing the actual command you just typed. Ignore that one. The others will have long command-line arguments shown with them. How many instances of Snort show up when running the command?
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 snort -
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
