Hello AS and regular snort users,
I wanted to announce that I have developed an init script compatible with CentOS/Redhat variants for autosnort installations (of course, this script can easily be adapted to other snort snort installations.
This init script can be used to replace /etc/rc.local as the primary method of starting up snort and barnyard2, and includes the added bonus of allow you to start/stop/restart snort and barnyard2 without requiring a reboot or sourcing /etc/rc.local if you need to make changes to snort or barnyard2. To add this script to CentOS 6.x perform the following tasks as root (or via sudo/root permissions):
1. Copy the snortbarn script to /etc/init.d
2. Edit the variables near the top of the script to suit your snort installation (the only variable that you should need to modify is the snort_iface variable if you installed snort/barnyard2 via autosnort)
3. Make the snortbarn script is executable for the root user (chmod 700 snortbarn)
4. Run chkconfig --add snortbarn
5. Remove the entries for ifconfig, snort, and barnyard2 from /etc/rc.local (note: you may want to make a backup of the rc.local script in case you run into bugs/problems with the init script!)
6. Kill your current snort/barnyard processes that ran from rc.local (killall snort && killall barnyard2)
7. Run the command "service snortbarn start"
8. check the process list to ensure that snort and barnyard2 are running after calling the init script. ( "ps -ef | grep snort" will return snort and barnyard2, if either/both processes are running. If only one process or the other is visible, something is wrong)
Troubleshooting steps: I'm not entirely sure why but there are CRLF/LF formatting problems with this script. If you get a bunch of errors stating that a file/command doesn't exist, try running dos2unix on the file to resolve the CRLF/LF errors.
If you install the init script and upon reboot find that only the snort process is running, it is because the init script for snortbarn ran BEFORE the init script for mysqld ran. To Determine when mysqld is configured to run it its runlevels, check /etc/init.d/mysqld. You'll want to pay attention to this line in particular:
# chkconfig: - 64 36
the first number, 64 indicates what number the rc startup script will get on startup. Linux rc scripts determine what services run or are killed on a particular run level. Every rc script as a K for Kill order, an S for Start order, followed by a number and the name of the symlinked script from /etc/init.d. RC scripts are read in numeric order. So if the rc script for snortbarn has an S number lower than 64, it will run before mysqld. snort will start up fine, but barnyard fails because it has no database to connect to.
To remedy this, you can modify the /etc/init.d/mysqld script to have a lower number than the snortbarn script in any of the /etc/rc[2-5].d directories, or modify the snortbarn script to have a higher number than the mysqld directory. This is a little confusing, so let's look at an example:
run this command: ls -al /etc/rc?.d/S*snortbarn
this command shows you each runlevel snortbarn is configured to start on.
now, run this command: ls -al /etc/rc?.d/S*mysqld
this command shows you the runlevels mysqld is set to run on. Don't worry about how many results you get.
If mysqld's number is higher than snortbarn's number, the mysqld process will not be running before snort and barnyard are configured to run. No database running means barnyard2 won't run. Let's say snortbarn had a number of 63, and mysqld has a number of 64. edit /etc/init.d/mysqld and change the chkconfig to something like this:
# chkconfig: - 62 36
save your changes and run chkconfig --add mysqld. This should fix the problem.
I've added the above documention to the other notes section of the CentOS readme. The snortbarn script is now available via github.
Special Note: Would like to thank Tactical FLEX/Aanval for hosting the initial version of this init script that I based this one off of. Would also like to thank Mike Miller for the initial idea of moving away from rc.local and building out a legitimate init script for autosnort.
Happy Snorting,
DA667
Sunday, March 31, 2013
Saturday, March 30, 2013
Hammering out Aanval
Hello Autosnort Users,
Today I would like to announce support for Tactical Flex's Aanval Web Console on CentOS and Debian platforms in addition to last weekend's Ubuntu release
I've implemented the same changes for the CentOS and Debian scripts that I've implemented on the Ubuntu script, namely the modularization of autosnort, starting with the web interface choices snortreport and aanval.
I've updated the readme files in each operating system's directory to more of a "release notes" format, that will be easier to read and follow.
One issue that I'd like to write about that I encountered while working on getting Aanval running on CentOS in particular is SELinux. Most people see SELinux as an annoying hindrance that keeps them from getting done what they want to get done. I use to be one of those people as well. But with a little bit of research, most problems with SELinux can be resolved easily, without disabling it or setting it to permissive mode (making it essentially useless).
I ran into a problem during aanval installation where it failed to connect to the mysql database on localhost with the creds I gave it. Thinking I fat-fingered the creds, I did it again and it immediately failed again.
At this point, I check the logs. Nothing interesting in /var/log/messages or the httpd error_logs, so I move to the audit log. For those of you who are not aware, SELinux usually logs to /var/log/audit/audit.log. It's log format is pretty strange, but its easy enough to pick out the relevant pieces to determine if SELinux is interfering with what you you need your system to do. run tail -f on audit.log and try entering the database credentials again and an entry pops up for SELinux, denying access to 3306/tcp for the httpd process. I do a google search for a small portion of the audit log message, and immediately get a relevant result. Long story short, run this command:
This explicitly states to SELinux that the httpd process requesting connections to the database/database port are perfectly fine. Always remember: disabling SELinux is NEVER the answer.
Happy Easter and Happy Snorting,
DA667
Today I would like to announce support for Tactical Flex's Aanval Web Console on CentOS and Debian platforms in addition to last weekend's Ubuntu release
I've implemented the same changes for the CentOS and Debian scripts that I've implemented on the Ubuntu script, namely the modularization of autosnort, starting with the web interface choices snortreport and aanval.
I've updated the readme files in each operating system's directory to more of a "release notes" format, that will be easier to read and follow.
One issue that I'd like to write about that I encountered while working on getting Aanval running on CentOS in particular is SELinux. Most people see SELinux as an annoying hindrance that keeps them from getting done what they want to get done. I use to be one of those people as well. But with a little bit of research, most problems with SELinux can be resolved easily, without disabling it or setting it to permissive mode (making it essentially useless).
I ran into a problem during aanval installation where it failed to connect to the mysql database on localhost with the creds I gave it. Thinking I fat-fingered the creds, I did it again and it immediately failed again.
At this point, I check the logs. Nothing interesting in /var/log/messages or the httpd error_logs, so I move to the audit log. For those of you who are not aware, SELinux usually logs to /var/log/audit/audit.log. It's log format is pretty strange, but its easy enough to pick out the relevant pieces to determine if SELinux is interfering with what you you need your system to do. run tail -f on audit.log and try entering the database credentials again and an entry pops up for SELinux, denying access to 3306/tcp for the httpd process. I do a google search for a small portion of the audit log message, and immediately get a relevant result. Long story short, run this command:
setsebool -P httpd_can_network_connect_db 1 This explicitly states to SELinux that the httpd process requesting connections to the database/database port are perfectly fine. Always remember: disabling SELinux is NEVER the answer.
Happy Easter and Happy Snorting,
DA667
Sunday, March 17, 2013
Dropping the hammer on the Aanval (The Aanval Update)
Hello Autosnort Users,
I am proud to announce a new, pilot release of Autosnort that will give users another web interface choice: Aanval!
For those of you who have no idea who or what Aanval is, Aanval can serve as a web UI choice for snort and/or suricata as well as a SIEM for events sent to it via syslog. There's the free edition that supports one sensor, and their commercial releases that support a large number of sensors and/or varying sources.
Aanval is a product of Tactical FLEX -- They're a nice bunch of people. I have yet to meet any of them in person, but I have spoken with both the CEO and the designer of the console over twitter a few times. They are very nice, very personable, and down-to-earth. If you get around to installing Aanval, be sure to drop them a line to let them know how awesome their console is!
This Autosnort release introduces some change you need to be aware of, so let's get to it:
-As indicated above this is a PILOT release. I've tested it extensively over the weekend, but I can't plan for every contingency and problem. Try it out, let me know if you run into problems. The bugs you report help me, other Autosnort users, and the open-source community overall.
-The new version of the script begins an effort for me to attempt to modularize Autosnort a little bit. Individual interface choices are their own child shell scripts now, called from the main shell script. This is a design choice I made to make it easier to add new and troubleshoot existing functionality.
-When I refer to "main" and child shell scripts, I mean, the main script is the large Autosnort script we all know and love. The child shell scripts are much smaller shell scripts dedicated to a single purpose, like installing one particular web interface. For this update, there are two child shell scripts:
snortreport.sh -- as the name implies is responsible for installing Snort Report
aanval.sh -- responsible for installing aanval
-The main autosnort script should be able to be ran anywhere, but the child shell script for the interface you wish to install must be placed into the /root directory for the script to complete successfully.
-As a matter of good practice, I would advise having the main and the child scripts in /root when you run it. The main script expects to find the child script in /root when you make it to the interface choices menu, and call the child script for the interface you wish to install. The script checks to see that the child script completed with an exit state of 0. If it does not, the main script will NOT continue.
-As another matter of good practice, I've decided that from here on out, I will keep the latest version of Autosnort available via github as well as one previous version back. This way, if you find there is some major problem with the current version of Autosnort, and you find that I am not working fast enough to resolve your problem, you can at least try to install the previous version to see if that works for you instead. In the Ubuntu Autosnort directory, there should be a Previous_Rel directory that contains the last version of Autosnort.
I've updated the readme in the Ubuntu directory to reflect this information. Provided there are no major deal-breaking problems in this pilot release, I hope to push support for Aanval to Debian and CentOS in the near future as well.
Update:
Aanval Post-Setup notes:
- It is highly advised that you reboot your system before continuing to the aanval console to continue the installation via the web interface. I ran into a problem prior to rebooting where the aanval console would not recognize that the php mysql module did exist and was loaded until the system was rebooted.
- During the initial setup, aanval will want to know the name of the aanvaldb user and password.
Username:snort
Password:password you gave the snort database user during the autosnort installation
- Aanval has a set of processes that are used to bring events over from the snort database that barnyard2 will dump to, and bring them over to the aanvaldb that aanval reads from. The console interface will let you know if they are not running. To start them, navigate to /var/www/aanval/apps and run idsBackground.pl -start --- I plan on adding an rc.local entry that will do this for you in the near future!
- In order for Aanval to manage events for your snort sensor you need to enable it on the aanval console. click the gear symbol in the lower corner of the web interface. This will bring you to a page called configuration. Click the "Settings" option under the "Snort" section. On the next page, check the enabled checkbox and enter the information for the snort database:
database name: snort
database hostname: localhost
database username: snort
database password: the password you assigned to the snort database user during autosnort installation
then click update. It may take a few minute for intrusion events to show up on the aanval interface. Be patient, they'll start coming in shortly!
- At this time, Autosnort does not support the sensor configuration options that Aanval includes. This is a limitation on my part; I need to figure out where Aanval expects to find the rule files, snort.conf and other configuration files before this will be possible!
- For more guidance and information specific to aanval, pay the folks at Tactical FLEX a visit at aanval.com
Happy St. Patty's day and happy snortin' to ye.
I am proud to announce a new, pilot release of Autosnort that will give users another web interface choice: Aanval!
For those of you who have no idea who or what Aanval is, Aanval can serve as a web UI choice for snort and/or suricata as well as a SIEM for events sent to it via syslog. There's the free edition that supports one sensor, and their commercial releases that support a large number of sensors and/or varying sources.
Aanval is a product of Tactical FLEX -- They're a nice bunch of people. I have yet to meet any of them in person, but I have spoken with both the CEO and the designer of the console over twitter a few times. They are very nice, very personable, and down-to-earth. If you get around to installing Aanval, be sure to drop them a line to let them know how awesome their console is!
This Autosnort release introduces some change you need to be aware of, so let's get to it:
-As indicated above this is a PILOT release. I've tested it extensively over the weekend, but I can't plan for every contingency and problem. Try it out, let me know if you run into problems. The bugs you report help me, other Autosnort users, and the open-source community overall.
-The new version of the script begins an effort for me to attempt to modularize Autosnort a little bit. Individual interface choices are their own child shell scripts now, called from the main shell script. This is a design choice I made to make it easier to add new and troubleshoot existing functionality.
-When I refer to "main" and child shell scripts, I mean, the main script is the large Autosnort script we all know and love. The child shell scripts are much smaller shell scripts dedicated to a single purpose, like installing one particular web interface. For this update, there are two child shell scripts:
snortreport.sh -- as the name implies is responsible for installing Snort Report
aanval.sh -- responsible for installing aanval
-The main autosnort script should be able to be ran anywhere, but the child shell script for the interface you wish to install must be placed into the /root directory for the script to complete successfully.
-As a matter of good practice, I would advise having the main and the child scripts in /root when you run it. The main script expects to find the child script in /root when you make it to the interface choices menu, and call the child script for the interface you wish to install. The script checks to see that the child script completed with an exit state of 0. If it does not, the main script will NOT continue.
-As another matter of good practice, I've decided that from here on out, I will keep the latest version of Autosnort available via github as well as one previous version back. This way, if you find there is some major problem with the current version of Autosnort, and you find that I am not working fast enough to resolve your problem, you can at least try to install the previous version to see if that works for you instead. In the Ubuntu Autosnort directory, there should be a Previous_Rel directory that contains the last version of Autosnort.
I've updated the readme in the Ubuntu directory to reflect this information. Provided there are no major deal-breaking problems in this pilot release, I hope to push support for Aanval to Debian and CentOS in the near future as well.
Update:
Aanval Post-Setup notes:
- It is highly advised that you reboot your system before continuing to the aanval console to continue the installation via the web interface. I ran into a problem prior to rebooting where the aanval console would not recognize that the php mysql module did exist and was loaded until the system was rebooted.
- During the initial setup, aanval will want to know the name of the aanvaldb user and password.
Username:snort
Password:password you gave the snort database user during the autosnort installation
- Aanval has a set of processes that are used to bring events over from the snort database that barnyard2 will dump to, and bring them over to the aanvaldb that aanval reads from. The console interface will let you know if they are not running. To start them, navigate to /var/www/aanval/apps and run idsBackground.pl -start --- I plan on adding an rc.local entry that will do this for you in the near future!
- In order for Aanval to manage events for your snort sensor you need to enable it on the aanval console. click the gear symbol in the lower corner of the web interface. This will bring you to a page called configuration. Click the "Settings" option under the "Snort" section. On the next page, check the enabled checkbox and enter the information for the snort database:
database name: snort
database hostname: localhost
database username: snort
database password: the password you assigned to the snort database user during autosnort installation
then click update. It may take a few minute for intrusion events to show up on the aanval interface. Be patient, they'll start coming in shortly!
- At this time, Autosnort does not support the sensor configuration options that Aanval includes. This is a limitation on my part; I need to figure out where Aanval expects to find the rule files, snort.conf and other configuration files before this will be possible!
- For more guidance and information specific to aanval, pay the folks at Tactical FLEX a visit at aanval.com
Happy St. Patty's day and happy snortin' to ye.
Friday, March 8, 2013
Snort 2.9.4.1 and some Minor Enhancements
Hello Autosnort Users,
As most of you may know, snort 2.9.4.1 released a few days ago. I didn't find out until about a day after it released. Since then I've been busy testing autosnort against all supported operating systems to ensure that everything continues to work like clockwork.
Here are the new features as reported on Snort.org:
Just to serve as a reminder for new autosnort users, If you are using the registered user ruleset from snort.org, we're in the 30-day holding period before a rule tarball with compatible SO rules will be released. This comes into play when autosnort walks you through installing your rules manually or via pulled pork.
During this time you will have to use a 2.9.4.0 rule tarball and disable the SO rules. If you choose to do this via pulledpork in the autosnort script, this is done for you automatically if you download the 2.9.4.0 rule tarball -- it is pulled down and pulled pork is configured to install text-based rules only.
If you happen to have a VRT subscription oink code, you can install the latest rule tarballs with no issues whatsoever.
Normally I would have had the blog post out sooner to correspond to the release of 2.9.4.1, but I made a couple of minor tweaks to the script that I've been meaning to do as well. So here are the improvements I have made:
1. During the snortreport install for all versions of the script, instead installing snortreport to /var/www/snortreport-1.3.3 (for Ubuntu/Debian) or /var/www/html/snortreport-1.3.3 (for CentOS), removed the trailing version number.
Now the directory path is /var/www/snortreport or /var/www/html/snortreport. This has been done to make it easier to point your web browser at the snort report front-end post-install. Now all you should have to type in your web browser is http://[ip address]/snortreport to gain access to the web UI.
2. Updated the online scripts to pull the barnyard2 source tarball from the barnyard2 github.
It was brought to my attention a little while ago over e-mail that the version of barnyard2 I was using in the script, as well as where I was downloading it from was a little dated and no longer recommended, so I rectified that. autosnort should be installing the latest master tarball via github now.
That's all for now.
Happy Snorting.
p.s: Most of you will notice that new code has been posted for every version BUT the BT5r3 version of the script that's because quite frankly, the BT5r3 version of the script had no need to be updated whatsoever. I tested the script and it works perfectly fine as-is. The backtrack script does not install a web front-end, or barnyard2. That can change if there's enough of a desire for it...
As most of you may know, snort 2.9.4.1 released a few days ago. I didn't find out until about a day after it released. Since then I've been busy testing autosnort against all supported operating systems to ensure that everything continues to work like clockwork.
Here are the new features as reported on Snort.org:
[*] Improvements
* Updated File processing for partial HTTP content and MIME attachments.
* Addition of new config option max_attribute_services_per_host and improve memory usage within attribute table.
* Handle excessive overlaps in frag3.
* Stream API updates to return session key for a session.
* Reduce false positives for TCP window slam events.
* Updates to provide better encoding for TCP packets generated for respond and react.
* Disable non-ethernet decoders by default for performance reasons. If needed, use --enable-non-ether-decoders with configure.
Just to serve as a reminder for new autosnort users, If you are using the registered user ruleset from snort.org, we're in the 30-day holding period before a rule tarball with compatible SO rules will be released. This comes into play when autosnort walks you through installing your rules manually or via pulled pork.
During this time you will have to use a 2.9.4.0 rule tarball and disable the SO rules. If you choose to do this via pulledpork in the autosnort script, this is done for you automatically if you download the 2.9.4.0 rule tarball -- it is pulled down and pulled pork is configured to install text-based rules only.
If you happen to have a VRT subscription oink code, you can install the latest rule tarballs with no issues whatsoever.
Normally I would have had the blog post out sooner to correspond to the release of 2.9.4.1, but I made a couple of minor tweaks to the script that I've been meaning to do as well. So here are the improvements I have made:
1. During the snortreport install for all versions of the script, instead installing snortreport to /var/www/snortreport-1.3.3 (for Ubuntu/Debian) or /var/www/html/snortreport-1.3.3 (for CentOS), removed the trailing version number.
Now the directory path is /var/www/snortreport or /var/www/html/snortreport. This has been done to make it easier to point your web browser at the snort report front-end post-install. Now all you should have to type in your web browser is http://[ip address]/snortreport to gain access to the web UI.
2. Updated the online scripts to pull the barnyard2 source tarball from the barnyard2 github.
It was brought to my attention a little while ago over e-mail that the version of barnyard2 I was using in the script, as well as where I was downloading it from was a little dated and no longer recommended, so I rectified that. autosnort should be installing the latest master tarball via github now.
That's all for now.
Happy Snorting.
p.s: Most of you will notice that new code has been posted for every version BUT the BT5r3 version of the script that's because quite frankly, the BT5r3 version of the script had no need to be updated whatsoever. I tested the script and it works perfectly fine as-is. The backtrack script does not install a web front-end, or barnyard2. That can change if there's enough of a desire for it...
Sunday, March 3, 2013
Modifications to autosnort offline scripts: support for Debian 6 32/64-bit
Hello Autosnort users,
I wanted to inform you all that I've recently made changes to autosnort offline scripts to include support for Debian 6 32-bit and 64-bit. I was able to make some minor changes to both scripts to do OS checks to fix issues specific to Debian while re-using code for portions of the script that are identical to the Ubuntu 12.04 32/64-bit offline install.
I've tested the scripts against Ubuntu 12.04 and Debian 6 -- 32 and 64-bit versions with a completely base install with absolutely no updates or extra packages added whatsoever -- with the exception of sshd.
The steps are pretty much exactly the same as the first version of the offline script:
1. Run the stage 1 shell script with create-sidmap.pl and dpkgorder text file for your OS and arch on a system with internet access that is as close to identical to your offline system as possible (meaning same ARCH, same OS version, and SAME installed packages), or to an system that is a completely baselined OS install with the same OS and arch as the offline operating system you plan to use the stage 2 shell script on.
2. Copy the rule tarball and the tarball created from the stage 1 shell script on your offline system. Answer the prompts, just like the regular, online autosnort installation script.
3. Reboot and you should be golden.
The dpkgorder file is a complete list of .deb files for each supported operating system (Debian or Ubuntu) and each supported arch (i686 or x86_64) that assumes a base OS install with nothing but sshd on it.
If you run the stage1 shell script from a completely base install of the same operating system and arch as your offline IDS system, you'll have absolutely everything you need to get snort and snort report up and running.
If you choose to to clone an exact copy of the offline system to run the stage1.sh script, that's fine too, you just have to make absolutely sure the two operating systems are as close to identical as you can get them to ensure that there aren't any missing packages, because if there's one thing I've learned from this whole offline installation endeavor is that a single missing dependency will cause the whole house of cards to come tumbling down, leaving you with a VERY ugly mess.
While I had the luxury of a VM, a baseline snapshot and a revert icon (I had to revert the Debian vms for testing more times than I can count this weekend), some of you won't have that luxury, so pay VERY close attention!
The scripts were committed right before this blog post and should be available via the autosnort github, located under the Ubuntu 12.04/offline directory.
The README should answer any remaining questions you might have or clarify steps pretty well. As always, if you have any further questions, I can be reached via twitter @da_667 or deusexmachina667 at gmail dot com.
Thank you all for using autosnort, and happy snorting!
~DA
I wanted to inform you all that I've recently made changes to autosnort offline scripts to include support for Debian 6 32-bit and 64-bit. I was able to make some minor changes to both scripts to do OS checks to fix issues specific to Debian while re-using code for portions of the script that are identical to the Ubuntu 12.04 32/64-bit offline install.
I've tested the scripts against Ubuntu 12.04 and Debian 6 -- 32 and 64-bit versions with a completely base install with absolutely no updates or extra packages added whatsoever -- with the exception of sshd.
The steps are pretty much exactly the same as the first version of the offline script:
1. Run the stage 1 shell script with create-sidmap.pl and dpkgorder text file for your OS and arch on a system with internet access that is as close to identical to your offline system as possible (meaning same ARCH, same OS version, and SAME installed packages), or to an system that is a completely baselined OS install with the same OS and arch as the offline operating system you plan to use the stage 2 shell script on.
2. Copy the rule tarball and the tarball created from the stage 1 shell script on your offline system. Answer the prompts, just like the regular, online autosnort installation script.
3. Reboot and you should be golden.
The dpkgorder file is a complete list of .deb files for each supported operating system (Debian or Ubuntu) and each supported arch (i686 or x86_64) that assumes a base OS install with nothing but sshd on it.
If you run the stage1 shell script from a completely base install of the same operating system and arch as your offline IDS system, you'll have absolutely everything you need to get snort and snort report up and running.
If you choose to to clone an exact copy of the offline system to run the stage1.sh script, that's fine too, you just have to make absolutely sure the two operating systems are as close to identical as you can get them to ensure that there aren't any missing packages, because if there's one thing I've learned from this whole offline installation endeavor is that a single missing dependency will cause the whole house of cards to come tumbling down, leaving you with a VERY ugly mess.
While I had the luxury of a VM, a baseline snapshot and a revert icon (I had to revert the Debian vms for testing more times than I can count this weekend), some of you won't have that luxury, so pay VERY close attention!
The scripts were committed right before this blog post and should be available via the autosnort github, located under the Ubuntu 12.04/offline directory.
The README should answer any remaining questions you might have or clarify steps pretty well. As always, if you have any further questions, I can be reached via twitter @da_667 or deusexmachina667 at gmail dot com.
Thank you all for using autosnort, and happy snorting!
~DA
Subscribe to:
Posts (Atom)