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.



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

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!)

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!

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!

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.)