Hello Autosnort users and readers of this blog.
I wanted to assure you that yes, I am still out there, I haven't abandoned this blog or this project and do not intend on doing so any time soon. I have just taken a very long holiday hiatus. Autosnort dev and regularly scheduled postings as well as responses to bugs and problems regarding autosnort will continue in the new year. I'm just taking a long moment's reprieve for the holiday to enjoy it among family and friends.. I know its a little late, but I hope you all enjoyed your holidays and I wish you all a happy new year.
Cheers,
DA
Sunday, December 30, 2012
Monday, December 10, 2012
We have pulled pork; the rest is just barbecue sauce.
Hello AS users,
Today I would like to announce a new autosnort build and introduce support and integration of pulled pork.
For those who do not know, pulled pork is a perl script written by JJ Cummings of Sourcefire. The script is the recommended method for open-source snort users to manage, download, and configure rules for snort deployments.
What does pulled pork integration mean for you and autosnort? Its even easier to get started.
- The old rule tarball method is still available (e.g. point the script to a VRT tarball to unpack), but now, in addition to the tarball method, you may choose to use pulled pork to build an initial ruleset based off of the Sourcefire base ruleset "Security over Connectivity".
- If you provide autosnort with an oink code (registered user or VRT subscription) you are then given a choice to try to download the latest rules tarball, or a the rules tarball from the previous version of snort.
The reason I do this instead of automatically downloading the latest rule tarball from snort.org is to work around the 30-day wait period registered users have to wait when a new version of snort comes out.
To summarize a blog post in which I had described this problem in detail, when a new version of snort comes out, a rule tarball that has compatible SO rules is immediately made available for VRT rule subscription holders. Registered users have to wait 30 days from the release to gain access to a VRT tarball with compatible SO rules. If you choose to download/process rules from the tarball for the previous version of snort, autosnort will only process text rules to ensure compatibility with the latest version of snort -- this is to prevent the dreaded "my SO rules don't work" phase for registered users.
Some may wonder "It's taken an awful long time to integrate just this functionality. Have you been slacking off?" Well, no more than I usually do, but there is a very good reason for the delay in this release -- I've taken a long look at the rest of the script and decided to re-write large portions of the script.
A significant problem most users had with autosnort was that if you fat-fingered at any point during the script, autosnort would happily plow forward, giving you a broken install upon reboot. I finally decided to go through the script and write some fault tolerance into the script -- key portions of the script are now sort of "encapsulated" into while/true loops -- meaning that you MUST give the script a valid answer for it to progress.
For example, as a part of the rule management routine in autosnort, I decided to keep the old VRT rule tarball import (e.g. untar it and drop everying into /usr/local/snort)
Before, if a user gave the script an invalid directory path and/or nonexistent file, the script would go forward without a care in the world.
This time around however the script does the following:
-checks to see if the file exists. if the file doesn't exist, you are told to try again
-if it exists, tries to untar it. if the file cannot be untarred (e.g. not a .tar.gz) it informs the user and the user is given the chance to try again
For the pulled pork phase we do the same kind of error checking:
-if pulled pork fails to download rules for any reason, we inform the user and loop back to the choice between using pulled pork for rule management, or importing a VRT rule tarball through the old method.
Pulled pork integration is going to gradually be released for all supported operating systems (e.g. Debian, Ubuntu, BT5 and CentOS. The pilot release is going to be on CentOS, with releases to other OSes trickling in behind it.
As always, the code has been posted to github under the CentOS directory
autosnort-centOS-ppinteg.sh
readme
Interesting, but useless statistics:
-file size of the shell script has nearly doubled from the old autosnort centOS script
-originally:24.5KB
-now: 42.3KB
-diff: 17.8
-lines of code (includes comments and blank lines for readability)
-original: 553
-now: 879
-diff: 326
Today I would like to announce a new autosnort build and introduce support and integration of pulled pork.
For those who do not know, pulled pork is a perl script written by JJ Cummings of Sourcefire. The script is the recommended method for open-source snort users to manage, download, and configure rules for snort deployments.
What does pulled pork integration mean for you and autosnort? Its even easier to get started.
- The old rule tarball method is still available (e.g. point the script to a VRT tarball to unpack), but now, in addition to the tarball method, you may choose to use pulled pork to build an initial ruleset based off of the Sourcefire base ruleset "Security over Connectivity".
- If you provide autosnort with an oink code (registered user or VRT subscription) you are then given a choice to try to download the latest rules tarball, or a the rules tarball from the previous version of snort.
The reason I do this instead of automatically downloading the latest rule tarball from snort.org is to work around the 30-day wait period registered users have to wait when a new version of snort comes out.
To summarize a blog post in which I had described this problem in detail, when a new version of snort comes out, a rule tarball that has compatible SO rules is immediately made available for VRT rule subscription holders. Registered users have to wait 30 days from the release to gain access to a VRT tarball with compatible SO rules. If you choose to download/process rules from the tarball for the previous version of snort, autosnort will only process text rules to ensure compatibility with the latest version of snort -- this is to prevent the dreaded "my SO rules don't work" phase for registered users.
Some may wonder "It's taken an awful long time to integrate just this functionality. Have you been slacking off?" Well, no more than I usually do, but there is a very good reason for the delay in this release -- I've taken a long look at the rest of the script and decided to re-write large portions of the script.
A significant problem most users had with autosnort was that if you fat-fingered at any point during the script, autosnort would happily plow forward, giving you a broken install upon reboot. I finally decided to go through the script and write some fault tolerance into the script -- key portions of the script are now sort of "encapsulated" into while/true loops -- meaning that you MUST give the script a valid answer for it to progress.
For example, as a part of the rule management routine in autosnort, I decided to keep the old VRT rule tarball import (e.g. untar it and drop everying into /usr/local/snort)
Before, if a user gave the script an invalid directory path and/or nonexistent file, the script would go forward without a care in the world.
This time around however the script does the following:
-checks to see if the file exists. if the file doesn't exist, you are told to try again
-if it exists, tries to untar it. if the file cannot be untarred (e.g. not a .tar.gz) it informs the user and the user is given the chance to try again
For the pulled pork phase we do the same kind of error checking:
-if pulled pork fails to download rules for any reason, we inform the user and loop back to the choice between using pulled pork for rule management, or importing a VRT rule tarball through the old method.
Pulled pork integration is going to gradually be released for all supported operating systems (e.g. Debian, Ubuntu, BT5 and CentOS. The pilot release is going to be on CentOS, with releases to other OSes trickling in behind it.
As always, the code has been posted to github under the CentOS directory
autosnort-centOS-ppinteg.sh
readme
Interesting, but useless statistics:
-file size of the shell script has nearly doubled from the old autosnort centOS script
-originally:24.5KB
-now: 42.3KB
-diff: 17.8
-lines of code (includes comments and blank lines for readability)
-original: 553
-now: 879
-diff: 326
Monday, December 3, 2012
Snort 2.9.4 release today and the dreaded "My SO rules don't work!" phase has begun.
Just in from the snort release team, looks like snort 2.9.4 just went out today:
- autosnort is going to automatically download the latest snort version. This means that if you are new to snort today and you are running autosnort on a fresh OS install, you're getting snort 2.9.4 today.
- you can still use the 2.9.3.1 ruleset for registered users if you don't have a VRT subscription however you've now entered the dreaded "my SO rules don't work" phase:
- Since the VRT only updates the free rule releases to registered users 30 days *after* the paying users, this means that when a new version of snort comes out you do not have VRT rules tarball for the newest version of snort immediately, and usually will be waiting 30 days for them to release a rule tarball with SO rules that are compatible with the newest version of snort, unless you have a VRT rule subscription.
- Snort will realize that the SO rules provided do not match the version of snort installed (e.g. you provide the autosnort script a 2.9.3.1 rule tarball) and will refuse to run upon reboot, giving you an error that looks something like this in /var/log/messages or /var/log/syslog depending on your distro:
This will mean that you will lose SO rule coverage for the next 30 days, but unfortunately, there's no way around it -- aside from buying a VRT rule subscription.
Some may wonder why the VRT does this? Well, making snort rules is not easy -- At all. I know; I've met the people that write these rules and I know the hours that they keep, the amount of work they put in, and just how little thanks they get in return -- still, Sourcefire and the VRT need to make money somehow, and they do so via provided accurate rules that have to meet strict quality assurance guidelines in a timely manner; you can't really fault them for the amount of effort that goes into making sure the rules work and work well.
With that being said, I hope to have pulledpork integration working in the near future to be able to remedy this. Happy snorting, everyone!
Snort 2.9.4 is now available on snort.org, atWhat this means for you:
http://www.snort.org/snort-downloads/ in the Latest Release section.
************
Please note:
2.9.3.1 & later packages are signed with a new PGP key
(that key is signed with the previous key).
************
Snort 2.9.4 includes changes for the following:
[*] New additions
* Consolidation of IPv6 -- now only a single build supports both
IPv4 & IPv6, and removal of the IPv4 "only" code paths.
* File API and improvements to file processing for HTTP downloads
and email attachments via SMTP, POP, and IMAP to facilitate
broader file support
* Use of address space ID for tracking Frag & Stream connections
when it is available with the DAQ
* Logging of packet data that triggers PPM for post-analysis via
Snort event
* Decoding of IPv6 with PPPoE
* Added an API call to add a service to a host in the attribute table.
Remove the unused live attribute update code.
[*] Improvements
* Update to Stream5 PAF for handling gaps in the sequence numbers of
packets being reassembled.
* Selection of the Stream TCP policy based on the server rather than
the destination of first packet seen by Snort
* Allow disabling of global thresholds via a count of -1
* Prevent blocking duplicate SYNs when using inline normalization
* Add SSLv3 backwards compatibility support for SSLv2 ClientHello
messages
* Allow active responses to packets without data (eg, a TCP SYN)
* Changed logic of option evaluations for shared library rules that
use a custom evaluation function to match that of the builtin logic
when the NOT_FLAG is used. The 'NOT' matching now happens within
each of the individual rule option evaluation functions.
* Updated SMTP preprocessor to better handle commands that have
corresponding data on a subsequent line to reduce false positives.
3 commands fall into this category - X-EXPS, XEXCH50, and BDAT.
* Improve support for encapsulated & tunneling protocols to block or
fastpath a connection within the tunnel rather applying that to
the whole tunnel.
Please see the Release Notes and ChangeLog for more details.
Please submit bugs, questions, and feedback to bugs@snort.org.
Happy Snorting!
The Snort Release Team
- autosnort is going to automatically download the latest snort version. This means that if you are new to snort today and you are running autosnort on a fresh OS install, you're getting snort 2.9.4 today.
- you can still use the 2.9.3.1 ruleset for registered users if you don't have a VRT subscription however you've now entered the dreaded "my SO rules don't work" phase:
- Since the VRT only updates the free rule releases to registered users 30 days *after* the paying users, this means that when a new version of snort comes out you do not have VRT rules tarball for the newest version of snort immediately, and usually will be waiting 30 days for them to release a rule tarball with SO rules that are compatible with the newest version of snort, unless you have a VRT rule subscription.
- Snort will realize that the SO rules provided do not match the version of snort installed (e.g. you provide the autosnort script a 2.9.3.1 rule tarball) and will refuse to run upon reboot, giving you an error that looks something like this in /var/log/messages or /var/log/syslog depending on your distro:
snort[1497]: FATAL ERROR: The dynamic detection library "/usr/local/snort/lib/snort_dynamicrules/web-misc.so" version 1.0 compiled with dynamic engine library version 1.16 isn't compatible with the current dynamic engine library "/usr/local/snort/lib/snort_dynamicengine/libsf_engine.so" version 1.17.The only solution I can provide you, snort of purchasing a VRT subscription is for you to delete the SO rules that snort is currently using. Autosnort installs your SO rules in the /usr/local/snort/lib/snort_dynamicrules/ directory. run the command:
rm -rf /usr/local/snort/lib/snort_dynamicrules/*.soAfterwards either restart snort, via the following command:
/usr/local/snort/bin/snort -D -u snort -g snort -c /usr/local/snort/etc/snort.conf -i eth1(or the interface you are sniffing traffic on)or simply reboot your sensor and let rc.local take care of things on reboot.
This will mean that you will lose SO rule coverage for the next 30 days, but unfortunately, there's no way around it -- aside from buying a VRT rule subscription.
Some may wonder why the VRT does this? Well, making snort rules is not easy -- At all. I know; I've met the people that write these rules and I know the hours that they keep, the amount of work they put in, and just how little thanks they get in return -- still, Sourcefire and the VRT need to make money somehow, and they do so via provided accurate rules that have to meet strict quality assurance guidelines in a timely manner; you can't really fault them for the amount of effort that goes into making sure the rules work and work well.
With that being said, I hope to have pulledpork integration working in the near future to be able to remedy this. Happy snorting, everyone!
Sunday, December 2, 2012
What's on my table right now, and how you can help if you want
I've already been asked a couple of times how people can help or contribute to autosnort, so this blog post is a rehash of what I sent to a user in an e-mail today. If you feel the need to contribute, or want to help out, here are the main things I'm working on currently, in order of priority:
1) Pulledpork.pl integration - I want to tear out the portion of the script that asks for the VRT tarball. Its far too easy to mess it up, and if it gets messed up you end up with a snort install that won't work because it has no rules to trigger against and either have to re-run the entire script, or manually untar the rules, copy them and copy the right SO rules for your distro.
- Want to use pulled pork as a solution for *initial rule setup*
- Give the user an initial ruleset, the scope of the project does not creep into configuration management, stays limited to initial snort installation and setup
- Will not support utilizing pulled pork with ET rules or Bleeding snort rules - considering this to be configuration management and outside of the scope of autosnort.
- Want to keep the VRT tarball check and insert a failsafe check that checks if the VRT rules tarball exists where the user says it is and if it doesn't, tells the user to try again instead of pushing forward.
2) Giving users a choice of where to log events and giving them their second choice: log to syslog
- configure snort.conf to log to syslog, disable barnyard installation
- user would then configure syslog config to forward IDS events to their SIEM
- the 'lightweight' alternative to MySQL, Barnyard and a web front-end
3) Giving users a choice of web front-ends to install and giving them their third choice: the BASE web frontend
- BASE has been around for a really long time
- Not very pretty, but very well documented
4) another web front-end choice: Aanval
- Aanval is another web front-end that looks very promising
- Can work with snort, suricata and syslog messages
5) snorby
- installation process is very, very painful
- likely to be very difficult to get set up right across multiple distros
- is highly a functional web front-end and looks amazing; the effort is worth it.
6) See if autosnort can be made compatible with earlier OS releases -- CentOS/Redhat 5.x, Ubuntu 10 and 11.04 LTS releases, BT5 r2, etc.
7) Expanding OS support upon request
This doesn't include bug fixes. If bugs are found, they jump to the top of the stack and have to be dealt with first.
So if you feel the need to help out there's tons that needs to be done. Pick any one of the 7 on the to-do list above.
The scripts are all on github, same as always and freely available for you to download.
In terms of beta testing, etc here are some of my recommendations:
1. Use virtual machines. Set up installations for Operating Systems you want to Beta for or develop against. Upon initial install, Take a snapshot of the OS so you can revert back to it. This will make testing new features and fixes much easier on you.
-ensure your VMs have at least 512mb of ram (1gb recommended) about 14gb of hdd (can be less if you're pressed for space) and at a minimum of two virtual NICs -- one for snort to bind to and the other for network access.
2. Good tools for the trade
-On windows, I use notepad ++ for writing the scripts, WinSCP for SCP transfers and MRemoteNG for managing multiple putty sessions to multiple autosnort boxes
-If you use linux for writing the scripts, gedit does an amazing job for writing, the command line scp command will do you just as well, and look at terminator for a tabbed terminal interface that can be split any way you'd like
-If on a mac textwrangler comes recommended as an editor, Fugu or the cli tools for SCP transfers, and iterm2 for tabbed terminal sessions that can be split any way you'd like.
3. Get a registered user account on snort.org
-Makes it easier to get your snort rule tarballs, specially if pulled pork integration takes off.
If you want to donate money to the cause, please just donate your money elsewhere -- I'm not try to say that I don't need your money, but there are worthier causes than mine. Donate your money to charity, use it to buy yourself something nice, or use it to buy something for someone you love. This project is just my way of trying to make network security a little bit easier and I am in no way looking to gain anything monetarily from it.
Don't feel obligated to do any of this, and if you realize midway in that you're in too deep, ask questions. If I don't know it, I'll try to point you in the right direction. Some people in the IT community would like to think that they were born with a keyboard in their hands and are too good to answer "noob" questions. Everyone starts out as a "noob" and you only become better by asking questions.
...That being said, don't be afraid to research, in fact, make sure that you research before you ask questions, as the question may have already been answered. This is called asking questions the smart way (note: while the material of that article may seem a bit scathing, the information contained within is very, very valuable).
Thank you for your continued support,
DA
1) Pulledpork.pl integration - I want to tear out the portion of the script that asks for the VRT tarball. Its far too easy to mess it up, and if it gets messed up you end up with a snort install that won't work because it has no rules to trigger against and either have to re-run the entire script, or manually untar the rules, copy them and copy the right SO rules for your distro.
- Want to use pulled pork as a solution for *initial rule setup*
- Give the user an initial ruleset, the scope of the project does not creep into configuration management, stays limited to initial snort installation and setup
- Will not support utilizing pulled pork with ET rules or Bleeding snort rules - considering this to be configuration management and outside of the scope of autosnort.
- Want to keep the VRT tarball check and insert a failsafe check that checks if the VRT rules tarball exists where the user says it is and if it doesn't, tells the user to try again instead of pushing forward.
2) Giving users a choice of where to log events and giving them their second choice: log to syslog
- configure snort.conf to log to syslog, disable barnyard installation
- user would then configure syslog config to forward IDS events to their SIEM
- the 'lightweight' alternative to MySQL, Barnyard and a web front-end
3) Giving users a choice of web front-ends to install and giving them their third choice: the BASE web frontend
- BASE has been around for a really long time
- Not very pretty, but very well documented
4) another web front-end choice: Aanval
- Aanval is another web front-end that looks very promising
- Can work with snort, suricata and syslog messages
5) snorby
- installation process is very, very painful
- likely to be very difficult to get set up right across multiple distros
- is highly a functional web front-end and looks amazing; the effort is worth it.
6) See if autosnort can be made compatible with earlier OS releases -- CentOS/Redhat 5.x, Ubuntu 10 and 11.04 LTS releases, BT5 r2, etc.
7) Expanding OS support upon request
This doesn't include bug fixes. If bugs are found, they jump to the top of the stack and have to be dealt with first.
So if you feel the need to help out there's tons that needs to be done. Pick any one of the 7 on the to-do list above.
The scripts are all on github, same as always and freely available for you to download.
In terms of beta testing, etc here are some of my recommendations:
1. Use virtual machines. Set up installations for Operating Systems you want to Beta for or develop against. Upon initial install, Take a snapshot of the OS so you can revert back to it. This will make testing new features and fixes much easier on you.
-ensure your VMs have at least 512mb of ram (1gb recommended) about 14gb of hdd (can be less if you're pressed for space) and at a minimum of two virtual NICs -- one for snort to bind to and the other for network access.
2. Good tools for the trade
-On windows, I use notepad ++ for writing the scripts, WinSCP for SCP transfers and MRemoteNG for managing multiple putty sessions to multiple autosnort boxes
-If you use linux for writing the scripts, gedit does an amazing job for writing, the command line scp command will do you just as well, and look at terminator for a tabbed terminal interface that can be split any way you'd like
-If on a mac textwrangler comes recommended as an editor, Fugu or the cli tools for SCP transfers, and iterm2 for tabbed terminal sessions that can be split any way you'd like.
3. Get a registered user account on snort.org
-Makes it easier to get your snort rule tarballs, specially if pulled pork integration takes off.
If you want to donate money to the cause, please just donate your money elsewhere -- I'm not try to say that I don't need your money, but there are worthier causes than mine. Donate your money to charity, use it to buy yourself something nice, or use it to buy something for someone you love. This project is just my way of trying to make network security a little bit easier and I am in no way looking to gain anything monetarily from it.
Don't feel obligated to do any of this, and if you realize midway in that you're in too deep, ask questions. If I don't know it, I'll try to point you in the right direction. Some people in the IT community would like to think that they were born with a keyboard in their hands and are too good to answer "noob" questions. Everyone starts out as a "noob" and you only become better by asking questions.
...That being said, don't be afraid to research, in fact, make sure that you research before you ask questions, as the question may have already been answered. This is called asking questions the smart way (note: while the material of that article may seem a bit scathing, the information contained within is very, very valuable).
Thank you for your continued support,
DA
Friday, November 30, 2012
How to fix problems with Snort Report on CentOS and Debian (update and addendum)
I spent the last 5 hours or so troubleshooting snort report on CentOS due to problems with how SELinux does not like apache requesting read operations to files owned by root in /var/www/html in spite of having read and execute access to everything in the snort report directory, and other oddities.
Bare in mind I am not a PHP dev by nature and frankly, had no idea what the hell was wrong here, hence why it took me so long to troubleshoot the issues I ran across here. my troubleshooting boils down to two things you MUST do on CentOS for snort report to run properly:
1) /etc/php.ini must have the short_open_tag = On in order to parse the php scripts for snort report properly. per the php.ini comments:
; This directive determines whether or not PHP will recognize code between
; <? and ?> tags as PHP source which should be processed as such. It's been
; recommended for several years that you not use the short tag "short cut" and
; instead to use the full <?php and ?> tag combination. With the wide spread use
; of XML and use of these tags by other languages, the server can become easily
; confused and end up parsing the wrong code in the wrong context. But because
; this short cut has been a feature for such a long time, it's currently still
; supported for backwards compatibility, but we recommend you don't use them.
What this boils down to is that php best practices weren't followed when snort report was written and this could cause interference with other web apps being hosted on the same box. Generally speaking for our case, you'll only be using a single web front end for a snort sensor, and I would hope you are not hosting other web applications on the same system.
on centos, the short_open_tag directive was found on line 229, and is set to "Off" by default, and resulted in some fugly half-rendered pages being generated. to fix this:
1. open up php.ini in an editor of your choice
2. navigate to line 229 and change the short_open_tag option to On
3. save the file and either reload or restart httpd for this to take effect.
2) SELinux does not like it when apache plays with files in /var/www/html that are owned by root and will not allow this to happen.
This took a little while to troubleshoot. I started by looking in /var/log/httpd/error_log finding several permission denied requests for a php require_once statement for srconf.php, snort report's config file. This turns out to be somewhat of a red herring.
I changed permissions on srconf multiple times and got the same results even with 777 permissions. It wasn't until I saw a post regarding how to troubleshooting require_once errors referring to file permissions saying that SELinux may be the culprit that I thought to suspect SELinux.
A quick look at /var/log/audit/audit.log and searching for srconf.php reveals that SELinux is smacking your hand anytime you try to use the srconf.php file, thus causing snortreport to sit there with a mostly blank page.
There are two fixes to this problem -- the wrong way and the right way
First, the wrong way:
Disable SELinux and change ownership of the snortreport directory and all files therein to the Apache user and group. Don't do this. Turning off SELinux was never the correct answer before, therefore I'm not making it the correct answer now. and because its the wrong answer, I leave it as an exercise for you to figure out how to do this and why this is a bad idea.
Now, the right way:
Inform SELinux that yes, httpd should be able to access these files and stop freaking out about it
1. cd to /var/www/html
2. run the command: chcon -R -t httpd_sys_rw_content_t snortreport-1.3.3/
what this does: we're telling SELinux that httpd is perfectly fine in requesting read and write operations to files located in this directory and to just let it happen.
After performing these two fixes, you should have a pefectly functioning snort report interface on CentOS.
Edit: Strange. I thought I had posted my update. Sorry about that!
Anyhow, you may be experiencing the same problems described on Debian 6 systems running snort report as well. Unfortunately, Debian has the same php.ini configuration as redhat short_open_tag is set to Off. If you set this to on, this will allow the snort report web UI to render properly.
On Debian, the php.ini file is located in /etc/php5/apache2/php.ini. the short_open_tag directive is in roughly the same spot as it is in CentOS either line 226 or 229. Chance the option from Off to On to resolve this issue.
I'm currently in the process of doing some testing here. It's been suggested on the snort mailing lists that simply used sed on all of snort report's php files to replace all entries of <? to <?php should resolve this issue. If this is the case, I may submit a bug report to symmetrix to resolve this issue permanently.
Until the bug is reported and resolved to snort report maintainers at symmetrix, utilize the fixes above to resolve the issue of the snort report UI failing to render on Debian and CentOS.
Bare in mind I am not a PHP dev by nature and frankly, had no idea what the hell was wrong here, hence why it took me so long to troubleshoot the issues I ran across here. my troubleshooting boils down to two things you MUST do on CentOS for snort report to run properly:
1) /etc/php.ini must have the short_open_tag = On in order to parse the php scripts for snort report properly. per the php.ini comments:
; This directive determines whether or not PHP will recognize code between
; <? and ?> tags as PHP source which should be processed as such. It's been
; recommended for several years that you not use the short tag "short cut" and
; instead to use the full <?php and ?> tag combination. With the wide spread use
; of XML and use of these tags by other languages, the server can become easily
; confused and end up parsing the wrong code in the wrong context. But because
; this short cut has been a feature for such a long time, it's currently still
; supported for backwards compatibility, but we recommend you don't use them.
What this boils down to is that php best practices weren't followed when snort report was written and this could cause interference with other web apps being hosted on the same box. Generally speaking for our case, you'll only be using a single web front end for a snort sensor, and I would hope you are not hosting other web applications on the same system.
on centos, the short_open_tag directive was found on line 229, and is set to "Off" by default, and resulted in some fugly half-rendered pages being generated. to fix this:
1. open up php.ini in an editor of your choice
2. navigate to line 229 and change the short_open_tag option to On
3. save the file and either reload or restart httpd for this to take effect.
2) SELinux does not like it when apache plays with files in /var/www/html that are owned by root and will not allow this to happen.
This took a little while to troubleshoot. I started by looking in /var/log/httpd/error_log finding several permission denied requests for a php require_once statement for srconf.php, snort report's config file. This turns out to be somewhat of a red herring.
I changed permissions on srconf multiple times and got the same results even with 777 permissions. It wasn't until I saw a post regarding how to troubleshooting require_once errors referring to file permissions saying that SELinux may be the culprit that I thought to suspect SELinux.
A quick look at /var/log/audit/audit.log and searching for srconf.php reveals that SELinux is smacking your hand anytime you try to use the srconf.php file, thus causing snortreport to sit there with a mostly blank page.
There are two fixes to this problem -- the wrong way and the right way
First, the wrong way:
Disable SELinux and change ownership of the snortreport directory and all files therein to the Apache user and group. Don't do this. Turning off SELinux was never the correct answer before, therefore I'm not making it the correct answer now. and because its the wrong answer, I leave it as an exercise for you to figure out how to do this and why this is a bad idea.
Now, the right way:
Inform SELinux that yes, httpd should be able to access these files and stop freaking out about it
1. cd to /var/www/html
2. run the command: chcon -R -t httpd_sys_rw_content_t snortreport-1.3.3/
what this does: we're telling SELinux that httpd is perfectly fine in requesting read and write operations to files located in this directory and to just let it happen.
After performing these two fixes, you should have a pefectly functioning snort report interface on CentOS.
Edit: Strange. I thought I had posted my update. Sorry about that!
Anyhow, you may be experiencing the same problems described on Debian 6 systems running snort report as well. Unfortunately, Debian has the same php.ini configuration as redhat short_open_tag is set to Off. If you set this to on, this will allow the snort report web UI to render properly.
On Debian, the php.ini file is located in /etc/php5/apache2/php.ini. the short_open_tag directive is in roughly the same spot as it is in CentOS either line 226 or 229. Chance the option from Off to On to resolve this issue.
I'm currently in the process of doing some testing here. It's been suggested on the snort mailing lists that simply used sed on all of snort report's php files to replace all entries of <? to <?php should resolve this issue. If this is the case, I may submit a bug report to symmetrix to resolve this issue permanently.
Until the bug is reported and resolved to snort report maintainers at symmetrix, utilize the fixes above to resolve the issue of the snort report UI failing to render on Debian and CentOS.
bug fixes,clarifications and feature requests
I had a conversation with a user of autosnort by the name of Guillaume a few days ago regarding a couple of bugs to fix and features to integrate into the script, specifically for CentOS. bug fixes will be released shortly after this post.
First, the bugs:
1) line 105 of autosnort for CentOS was a yum -y upgrade command. the difference between update and upgrade are minor, however they could be enough of a problem to some users to warrant an explanation:
yum upgrade performs software updates against CentOS and also removes packages installed that have been marked as obsolete either as part of an upgrade to a new software version or at the whim of the distro maintainers.
yum update just performs maintenance updates on the system. obsolete packages are left alone. For this purpose, I have changed the yum statement from upgrade to update.
2) the rm statement for removing the epel repo rpm file (line 127) was malformed and was attempting to delete a url. this of course would never succeed and has been fixed.
3) the copy statement (321, 325) for so rules somehow isn't copying so rules to the correct directory. this has been resolved.
Next, some clarifications:
Guillaume noticed that for the interface that snort is configured to listen on, that the options -arp and -multicast are configured for that interface. he cautioned me that this would lead to this interface to not responding to requests if there is an ip address assigned on the interface.
I've taken Sourcefire's own 3D training as well as the snort/rule writing courses. this is the recommended configuration for dedicated IDS system. If you are going to dedicate a system to sniffing network traffic, you always want to ensure that you have at least two dedicated network interfaces available:
1) an interface that is dedicated solely to sniffing traffic. We aren't going to respond to ANYTHING for ANYONE on this interface. this is the interface you have connected to your hub, tap, span port, etc. whose sole job it is to grab traffic, and give it to snort for analysis, hopefully without choking on it. Connections to or from your sensor should never be seen or attempted on this interface.
2) the secondary or "management" interface you will use to talk to the host via ssh http/https or other secure means you will use to analyze the events snort has recorded, or use to forward events to a central location.
it is never recommended (and on 3d boxes damn near impossible) to have your sniffing and management traffic on the same interface. it is also recommended to not have your sniffing interface respond to multicast or arp requests for opsec reasons: you do not need your users or potential attackers who have exploited their way onto your network to know that you're listening.
I never really clarified this on any of the documentation except the portion of the script that asks you to specify the sniffing interface so I hope this helps to clarify why the script does this -- I will be adding this to the requirements portion of the autosnort readme, albeit in a much more condensed form.
feature requests:
Guillaume has requested that GRO and LRO Generic and Large Receive Offload be disabled via ethtool for all script versions per the recommendations of the snort user guide. The snort user guide was written by professionals, I can't really argue against it, so expect changes to the script soon to ensure ethtool is installed and gro/lro is disabled with the exception of backtrack -- If you want an explanation as to why, check the readme I have included with the backtrack version of autosnort. To paraphrase it, the goals for the backtrack autosnort script were simply to update the snort installation, and not provide a full IDS deployment.
Guillaume also requested replacing the VRT tarball request with pulledpork. I had plans to do this eventually, but it will be a little while before this is done. mark my words, that its in the works.
I'm also getting requests for other web front ends, including base and snorby -- again, they are definitely in the works, but will be a while off due to time constraints -- I have a day job unfortunately and only really have time to work on this project over the weekend, and even then I still have family and friends I love dearly. I ask that you be patient and know that though I am dedicated to this project, I am still a man.
Thanks for your support, I hope you continue to enjoy autosnort while I continue to improve upon it.
Cheers,
DA
First, the bugs:
1) line 105 of autosnort for CentOS was a yum -y upgrade command. the difference between update and upgrade are minor, however they could be enough of a problem to some users to warrant an explanation:
yum upgrade performs software updates against CentOS and also removes packages installed that have been marked as obsolete either as part of an upgrade to a new software version or at the whim of the distro maintainers.
yum update just performs maintenance updates on the system. obsolete packages are left alone. For this purpose, I have changed the yum statement from upgrade to update.
2) the rm statement for removing the epel repo rpm file (line 127) was malformed and was attempting to delete a url. this of course would never succeed and has been fixed.
3) the copy statement (321, 325) for so rules somehow isn't copying so rules to the correct directory. this has been resolved.
Next, some clarifications:
Guillaume noticed that for the interface that snort is configured to listen on, that the options -arp and -multicast are configured for that interface. he cautioned me that this would lead to this interface to not responding to requests if there is an ip address assigned on the interface.
I've taken Sourcefire's own 3D training as well as the snort/rule writing courses. this is the recommended configuration for dedicated IDS system. If you are going to dedicate a system to sniffing network traffic, you always want to ensure that you have at least two dedicated network interfaces available:
1) an interface that is dedicated solely to sniffing traffic. We aren't going to respond to ANYTHING for ANYONE on this interface. this is the interface you have connected to your hub, tap, span port, etc. whose sole job it is to grab traffic, and give it to snort for analysis, hopefully without choking on it. Connections to or from your sensor should never be seen or attempted on this interface.
2) the secondary or "management" interface you will use to talk to the host via ssh http/https or other secure means you will use to analyze the events snort has recorded, or use to forward events to a central location.
it is never recommended (and on 3d boxes damn near impossible) to have your sniffing and management traffic on the same interface. it is also recommended to not have your sniffing interface respond to multicast or arp requests for opsec reasons: you do not need your users or potential attackers who have exploited their way onto your network to know that you're listening.
I never really clarified this on any of the documentation except the portion of the script that asks you to specify the sniffing interface so I hope this helps to clarify why the script does this -- I will be adding this to the requirements portion of the autosnort readme, albeit in a much more condensed form.
feature requests:
Guillaume has requested that GRO and LRO Generic and Large Receive Offload be disabled via ethtool for all script versions per the recommendations of the snort user guide. The snort user guide was written by professionals, I can't really argue against it, so expect changes to the script soon to ensure ethtool is installed and gro/lro is disabled with the exception of backtrack -- If you want an explanation as to why, check the readme I have included with the backtrack version of autosnort. To paraphrase it, the goals for the backtrack autosnort script were simply to update the snort installation, and not provide a full IDS deployment.
Guillaume also requested replacing the VRT tarball request with pulledpork. I had plans to do this eventually, but it will be a little while before this is done. mark my words, that its in the works.
I'm also getting requests for other web front ends, including base and snorby -- again, they are definitely in the works, but will be a while off due to time constraints -- I have a day job unfortunately and only really have time to work on this project over the weekend, and even then I still have family and friends I love dearly. I ask that you be patient and know that though I am dedicated to this project, I am still a man.
Thanks for your support, I hope you continue to enjoy autosnort while I continue to improve upon it.
Cheers,
DA
Monday, November 19, 2012
Quick update :
There has been a question or two on how the script is handling the VRT rule tarball -- e.g. there should be some error checking in place instead of having the user re-run the script, do the steps manually or cut that portion out of the script to do it themselves. I agree wholeheartedly and in the somewhat near future will be adding in a check to ensure your rule tarball exists on the file system where you said it was and if its not there, loop through until you give it a valid rule tarball.
Expect an update in the somewhat near future (sorry folks, I still have a day job -- however if you're interested in submitting a patch for this functionality... feel free to contribute!)
There has been a question or two on how the script is handling the VRT rule tarball -- e.g. there should be some error checking in place instead of having the user re-run the script, do the steps manually or cut that portion out of the script to do it themselves. I agree wholeheartedly and in the somewhat near future will be adding in a check to ensure your rule tarball exists on the file system where you said it was and if its not there, loop through until you give it a valid rule tarball.
Expect an update in the somewhat near future (sorry folks, I still have a day job -- however if you're interested in submitting a patch for this functionality... feel free to contribute!)
Friday, November 16, 2012
Expanded OS support: Ubuntu 12.10
Hello AS users,
I wanted to post a quick update regarding expansion of OS support for autosnort. The Autosnort script WILL install autosnort to Ubuntu 12.10 with no issues. The only thing the script will do is warn you that the OS version is not 12.04 and ask if you would like to continue.
I would like to confirm that after a quick test run on an Ubuntu 12.10 virtual machine that autosnort will gladly handle a full snort install for Ubuntu 12.10 as well.
Cheers,
DA
edit: added an official OS check for Ubuntu 12.10 and a ubuntu-specific readme to the github repo. It's official now!
I wanted to post a quick update regarding expansion of OS support for autosnort. The Autosnort script WILL install autosnort to Ubuntu 12.10 with no issues. The only thing the script will do is warn you that the OS version is not 12.04 and ask if you would like to continue.
I would like to confirm that after a quick test run on an Ubuntu 12.10 virtual machine that autosnort will gladly handle a full snort install for Ubuntu 12.10 as well.
Cheers,
DA
Wednesday, November 14, 2012
Hi there folks,
Doing a quick post to announce autosnort support for Debian. Practically all of the code from the Ubuntu version of autosnort was able to be re-used to enable fast turn-around on pushing out this script. I assure you that this script was tested against both Debian 32 and 64-bit. and appears to be working just fine.
The Debian build for autosnort can be found here
As always, PLEASE let me know if you run into any issues with the script. Thanks and happy snorting!
Doing a quick post to announce autosnort support for Debian. Practically all of the code from the Ubuntu version of autosnort was able to be re-used to enable fast turn-around on pushing out this script. I assure you that this script was tested against both Debian 32 and 64-bit. and appears to be working just fine.
The Debian build for autosnort can be found here
As always, PLEASE let me know if you run into any issues with the script. Thanks and happy snorting!
Monday, November 12, 2012
First Post
I decided after two posts to the snort.org blog and abusing connections at Sourcefire (Thanks Joel!), that making a blog for Autosnort would probably be a good idea, so here I am.
From now on, you can expect posts regarding autosnort here.
So... to start, what exactly is autosnort? To boil it down, autosnort is a shell script that will take a supported operating system and give you a fully updated, fully functional snort installation with minimal effort.
I created the script in response to quite a few people giving snort a bad rap for being hard to install and configure properly. So now, new users and veteran users alike now have an automated method of installing the latest version of snort with minimal effort.
Currently, there are three versions of the script - one for Ubuntu 12.04, CentOS 6.3 and Backtrack 5 r3. If you are interested in using autosnort, contributing code (e.g. scripts for other operating systems, etc) please check out the autosnort github for more information, including a detailed readme.
The readme in the autosnort github has most of the gritty details of what exactly the script will do for each operating system to achieve its goals and what it will not do for you.
Some things I am currently working on regarding autosnort:
1. A release for Debian 6, 32 and 64-bit
2. A release for pentoo linux
3. Support for other snort front-ends (e.g. BASE, snorby, squil, aanval, etc.)
4. A barebones installation that sends events to syslog for SIEM integration (e.g. I don't want a pretty web front-end, just give me the alerts for event correlation)
If there are any questions, my contact information is also in the readme, but for good measure:
email: deusexmachina667@gmail.com
twitter: @da_667
Thanks and happy snorting! (well, not THAT kind.)
From now on, you can expect posts regarding autosnort here.
So... to start, what exactly is autosnort? To boil it down, autosnort is a shell script that will take a supported operating system and give you a fully updated, fully functional snort installation with minimal effort.
I created the script in response to quite a few people giving snort a bad rap for being hard to install and configure properly. So now, new users and veteran users alike now have an automated method of installing the latest version of snort with minimal effort.
Currently, there are three versions of the script - one for Ubuntu 12.04, CentOS 6.3 and Backtrack 5 r3. If you are interested in using autosnort, contributing code (e.g. scripts for other operating systems, etc) please check out the autosnort github for more information, including a detailed readme.
The readme in the autosnort github has most of the gritty details of what exactly the script will do for each operating system to achieve its goals and what it will not do for you.
Some things I am currently working on regarding autosnort:
1. A release for Debian 6, 32 and 64-bit
2. A release for pentoo linux
3. Support for other snort front-ends (e.g. BASE, snorby, squil, aanval, etc.)
4. A barebones installation that sends events to syslog for SIEM integration (e.g. I don't want a pretty web front-end, just give me the alerts for event correlation)
If there are any questions, my contact information is also in the readme, but for good measure:
email: deusexmachina667@gmail.com
twitter: @da_667
Thanks and happy snorting! (well, not THAT kind.)
Subscribe to:
Posts (Atom)