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
Friday, February 22, 2013
Autosnort offline build Ubuntu 12.04 i386/x86_64 available!
Hello Autosnort Users!
It's been a long time since I've posted. My day job keeps me plenty busy. I apologize for the last of responsiveness over e-mail. If I haven't gotten to you it's not because I'm an unsociable jerk it's that I'm quite literally exhausted at the end of the day. I do work for the federal government right now helping them with their infosec things and my days are NEVER boring, suffice to say.
That being said, I wanted to announce that after what seems like forever I have new updates to autosnort, namely an offline version of the script that I've released for ubuntu 12.04 today.
Some of you may be wondering why would I go through the trouble? What good is it? How does it help me?
Well, to the average user, it's not likely to be terribly helpful, but to users in situations where you have to sneakernet software from point A to point B, or from a network with good internet access to one without internet access or very limited internet access, even for hackers and infosec enthusiasts that are participating in "Capture the Flag" events with limited internet access, an offline build of autosnort providing the latest version of snort and snort rules easily seems like a godsend.
The offline script, or scripts I should say, come in two stages:
Stage 1: as-offline-stage1.sh
When this script is ran on a system that is identical to your offline system (meaning a system running the same operating system (Ubuntu), Version (12.04), and architecture (32-bit/i386 || 64-bit/x86_64)), it will download all the required packages via apt-get, download them (without installing them on this system), grab the latest version of snort and daq as well as barnyard2, snortreport, and libdnet.
A copy of the perl script, create-sidmap.pl and dpkorder$arch.txt (where $arch is either x86_64 or i386) should be placed on this system as well; the script expects to find these two files so that they can be included in the tar file that has all the packages (.deb and .tar.gz) needed for the stage2/offline installer script.
Stage 2: as-offline-stage2.sh
This script is ran on the offline system you plan on installing snort to. The script requires the tarball generated from the stage1 script as well as a VRT rules tarball to work properly.
Essentially the script installs all the .deb packages in the CORRECT order, then installs all the downloaded source packages, much the same as the online version of the autosnort script (yay for code re-use!)
The end-product is a fully functional snort install, just like the online autosnort script.
Please note that create-sidmap.pl is a part of the Oinkmaster suite. In layman's terms, the Oinkmaster suite is a precursor to PulledPork. The Oinkmaster suite is released under the BSD license, by Sourcefire. I just want to make it abundantly clear here and now that this is NOT my software and if requested by the original creator of the script I will comply and remove it. It is included on my github page currently as a convenience and nothing more.
The reason the create-sidmap script is included is to assist offline users in generating a new sid-msg.map file. I noticed in the process of creating this script, that barnyard2 would log alerts just fine, but then snortreport wouldn't show me what the alert's message was only "snort alert [sid number]" which was very unhelpful. I eventually discovered this is due to the sid-msg.map file. Essentially, the sid-msg.map file is responsible for "mapping" the snort SID to the snort msg field in the rule, thus giving you the rule sid and message when you look at a rule via snortreport or the web interface of your choice instead of "snort alert" followed by the sid number. create-sidmap.pl resolves this problem quite easily.
I hope you all find the scripts useful!
Until next time, happy snorting.
It's been a long time since I've posted. My day job keeps me plenty busy. I apologize for the last of responsiveness over e-mail. If I haven't gotten to you it's not because I'm an unsociable jerk it's that I'm quite literally exhausted at the end of the day. I do work for the federal government right now helping them with their infosec things and my days are NEVER boring, suffice to say.
That being said, I wanted to announce that after what seems like forever I have new updates to autosnort, namely an offline version of the script that I've released for ubuntu 12.04 today.
Some of you may be wondering why would I go through the trouble? What good is it? How does it help me?
Well, to the average user, it's not likely to be terribly helpful, but to users in situations where you have to sneakernet software from point A to point B, or from a network with good internet access to one without internet access or very limited internet access, even for hackers and infosec enthusiasts that are participating in "Capture the Flag" events with limited internet access, an offline build of autosnort providing the latest version of snort and snort rules easily seems like a godsend.
The offline script, or scripts I should say, come in two stages:
Stage 1: as-offline-stage1.sh
When this script is ran on a system that is identical to your offline system (meaning a system running the same operating system (Ubuntu), Version (12.04), and architecture (32-bit/i386 || 64-bit/x86_64)), it will download all the required packages via apt-get, download them (without installing them on this system), grab the latest version of snort and daq as well as barnyard2, snortreport, and libdnet.
A copy of the perl script, create-sidmap.pl and dpkorder$arch.txt (where $arch is either x86_64 or i386) should be placed on this system as well; the script expects to find these two files so that they can be included in the tar file that has all the packages (.deb and .tar.gz) needed for the stage2/offline installer script.
Stage 2: as-offline-stage2.sh
This script is ran on the offline system you plan on installing snort to. The script requires the tarball generated from the stage1 script as well as a VRT rules tarball to work properly.
Essentially the script installs all the .deb packages in the CORRECT order, then installs all the downloaded source packages, much the same as the online version of the autosnort script (yay for code re-use!)
The end-product is a fully functional snort install, just like the online autosnort script.
Please note that create-sidmap.pl is a part of the Oinkmaster suite. In layman's terms, the Oinkmaster suite is a precursor to PulledPork. The Oinkmaster suite is released under the BSD license, by Sourcefire. I just want to make it abundantly clear here and now that this is NOT my software and if requested by the original creator of the script I will comply and remove it. It is included on my github page currently as a convenience and nothing more.
The reason the create-sidmap script is included is to assist offline users in generating a new sid-msg.map file. I noticed in the process of creating this script, that barnyard2 would log alerts just fine, but then snortreport wouldn't show me what the alert's message was only "snort alert [sid number]" which was very unhelpful. I eventually discovered this is due to the sid-msg.map file. Essentially, the sid-msg.map file is responsible for "mapping" the snort SID to the snort msg field in the rule, thus giving you the rule sid and message when you look at a rule via snortreport or the web interface of your choice instead of "snort alert" followed by the sid number. create-sidmap.pl resolves this problem quite easily.
I hope you all find the scripts useful!
Until next time, happy snorting.
Tuesday, January 29, 2013
New year, new ideas (introduction to while/true case statements)
Howdy Autosnort users,
It's been a while since I've posted anything meaty to the blog. My day job keeps me very busy and the projects I've been working on have been very intense. At this point I really only have time to work on autosnort over weekends. I appreciate all the support and questions and identification of bugs or problems with the script; you're helping me, the snort community and the greater open source community just by asking questions and reporting bugs, so thank you very much. I may not be very fast to respond, but I will ALWAYS do what I can as soon as I can.
That being said, I'm going to post a quick tutorial to bash while/true loops, and how they can be used to provide some fault tolerance in your shell scripts (or at least how it's helped me tremendously)
First and foremost, what is a while true loop? A while true loop is a do while statement that is configured to loop infinitely. While do loops usually go something like this:
the function below prints the value of x, then increments it by 1. Once x is greater than 10, the loop, then the script exits. This script will print numbers 0-10, one on each line.
A while true loop looks something like this:
this statement is much much simpler, but lets run through it anyhow. The do/while statement is just "while true; do" which, in english, means while true is true (which will ALWAYS be the case) do the statement below
The statement below just prints "Hello!" ad infinitum. If you were to run the script above, you'd have to kill the script or Ctrl+C the script to stop it. Not very useful, huh? What if I told you that you could control whether or not the loop progresses or not with certain keywords?
The keywords break and continue in a loop are ways to control how a bash loop progresses. The break statement says "Stop the loop now, jump immediately to done, do not process anymore lines in the loop." while the continue statement says "Stop here, go back to the beginning statement in the loop."
Are you starting to see how this can be useful?
Case statements can be used to give the use of a script a menu or "branch" a script, performing a certain action when a variable, or output is a certain value.
the above statement asks the user to input 1 or 2 as an option for the case statement. that value is stored in the variable case1. The case statement is basically a large collection of if/then statements -- "if the value of case1 equals 1, then do this. if it equals 2, then do this. if it equals anything else, this is a catch-all statement to do, usually indicating the user picked an invalid choice."
Nothing too mind-breaking. This is stuff you're taught in your intro to UNIX classes in college. The fun part comes combining the concept of a case statement with a while true loop. and using continue or break keywords to continue the loop or break it:
Let me break down what's going on above:
We begin with a while true statement, starting off our "infinite" loop. The next statement tells the user to select 1 or 2 as options in our case statement. This is normally where you'd print a menu (if a user is expected to interact here) and explain what the options do, or just launch straight into your case selection if this is a fully automated script. After printing the statement and taking the user's input, we go straight into our case statement. The statement says "If case1 equals 1 do this, if it equals 2, then do this, if it equals anything else, do this."
What's different between this case statement and the previous one I used as an example is the existence of the keywords break and continue in these statements. The break statement says "Terminate the loop and jump straight to done." No more processing, no more looping, just move on. The break statement at the end of option 1 and 2 is a way of identifying that these are the only valid cases for this bit of bash code, that in order to continue script execution, the value of case1 must be "1" or "2" (or the user has to cancel the script via kill or ctrl+c). the continue statement in our catch-all case is a way if forcing the user to select a valid choice to continue script execution. In this way it's a sort of safety net that doesn't allow the script to continue unless a valid choice is made. It's a safety net for accidents, fat-fingering or hitting the wrong keys.
Soon as I figured out how to do this, I littered them throughout the script to make the script more fault tolerant. Instead of throwing an error and exiting in a case statement, autosnort just loops back and informs the user their choice was invalid, or didn't work for whatever reason, instead of blindly plowing forward, or exiting, leaving the user with a mess. It's still imperfect, but MUCH improved over the original version.
Currently I'm working on nesting multiple while/true case statements together, something like this:
See if you can figure it out on your own. I hope to implement multiple output options (web UIs, etc.) in this manner to make the script more foolproof, and offer more choices to users.
Until next time,
Happy snorting!
It's been a while since I've posted anything meaty to the blog. My day job keeps me very busy and the projects I've been working on have been very intense. At this point I really only have time to work on autosnort over weekends. I appreciate all the support and questions and identification of bugs or problems with the script; you're helping me, the snort community and the greater open source community just by asking questions and reporting bugs, so thank you very much. I may not be very fast to respond, but I will ALWAYS do what I can as soon as I can.
That being said, I'm going to post a quick tutorial to bash while/true loops, and how they can be used to provide some fault tolerance in your shell scripts (or at least how it's helped me tremendously)
First and foremost, what is a while true loop? A while true loop is a do while statement that is configured to loop infinitely. While do loops usually go something like this:
#!/bin/bashx is a variable initialized to zero in the example above. The while statement reads "while x is less than or equal to 10 do the function below.
x=0
while [ $x -le 10 ]; do
echo "$x"
x=$(( $x + 1 ))
done
exit 0
the function below prints the value of x, then increments it by 1. Once x is greater than 10, the loop, then the script exits. This script will print numbers 0-10, one on each line.
A while true loop looks something like this:
#!/bin/bash
while true; do
echo "Hello!"
done
exit 0
this statement is much much simpler, but lets run through it anyhow. The do/while statement is just "while true; do" which, in english, means while true is true (which will ALWAYS be the case) do the statement below
The statement below just prints "Hello!" ad infinitum. If you were to run the script above, you'd have to kill the script or Ctrl+C the script to stop it. Not very useful, huh? What if I told you that you could control whether or not the loop progresses or not with certain keywords?
The keywords break and continue in a loop are ways to control how a bash loop progresses. The break statement says "Stop the loop now, jump immediately to done, do not process anymore lines in the loop." while the continue statement says "Stop here, go back to the beginning statement in the loop."
Are you starting to see how this can be useful?
Case statements can be used to give the use of a script a menu or "branch" a script, performing a certain action when a variable, or output is a certain value.
#!/bin/bash
read -p "this is a case statement!
Your choices are:
1
2
Please enter your choice: " case1
case $case1 in
1)
echo "you have chosen case statement 1!"
;;
2)
echo "you have chosen case statement 2!"
;;
*)
echo "invalid choice!"
;;
esac
exit 0
the above statement asks the user to input 1 or 2 as an option for the case statement. that value is stored in the variable case1. The case statement is basically a large collection of if/then statements -- "if the value of case1 equals 1, then do this. if it equals 2, then do this. if it equals anything else, this is a catch-all statement to do, usually indicating the user picked an invalid choice."
Nothing too mind-breaking. This is stuff you're taught in your intro to UNIX classes in college. The fun part comes combining the concept of a case statement with a while true loop. and using continue or break keywords to continue the loop or break it:
while true; do
read -p "this is a case statement var choices are 1 or 2." case1
case $case1 in
1)
echo "this is a result of selecting 1."
break;
;;
2)
echo "this is a result of selecting 2."
break;
;;
*)
echo "invalid choice!"
continue;
;;
esac
done
exit 0
Let me break down what's going on above:
We begin with a while true statement, starting off our "infinite" loop. The next statement tells the user to select 1 or 2 as options in our case statement. This is normally where you'd print a menu (if a user is expected to interact here) and explain what the options do, or just launch straight into your case selection if this is a fully automated script. After printing the statement and taking the user's input, we go straight into our case statement. The statement says "If case1 equals 1 do this, if it equals 2, then do this, if it equals anything else, do this."
What's different between this case statement and the previous one I used as an example is the existence of the keywords break and continue in these statements. The break statement says "Terminate the loop and jump straight to done." No more processing, no more looping, just move on. The break statement at the end of option 1 and 2 is a way of identifying that these are the only valid cases for this bit of bash code, that in order to continue script execution, the value of case1 must be "1" or "2" (or the user has to cancel the script via kill or ctrl+c). the continue statement in our catch-all case is a way if forcing the user to select a valid choice to continue script execution. In this way it's a sort of safety net that doesn't allow the script to continue unless a valid choice is made. It's a safety net for accidents, fat-fingering or hitting the wrong keys.
Soon as I figured out how to do this, I littered them throughout the script to make the script more fault tolerant. Instead of throwing an error and exiting in a case statement, autosnort just loops back and informs the user their choice was invalid, or didn't work for whatever reason, instead of blindly plowing forward, or exiting, leaving the user with a mess. It's still imperfect, but MUCH improved over the original version.
Currently I'm working on nesting multiple while/true case statements together, something like this:
#!/bin/bash
while true; do
read -p "this is a case statement var choices are 1 or 2." case1
case $case1 in
1)
echo "this is a result of selecting 1."
break;
;;
2)
while true; do
read -p "this is another case statement. var choices are 1 or 2." case2
case $case2 in
1)
echo "result of the second case statement"
break;
;;
2) echo "NARF!"
break;
;;
*)
echo "Invalid choice!"
continue;
;;
esac
done
break;
;;
*)
echo "invalid choice!"
continue;
;;
esac
done
exit 0
See if you can figure it out on your own. I hope to implement multiple output options (web UIs, etc.) in this manner to make the script more foolproof, and offer more choices to users.
Until next time,
Happy snorting!
Subscribe to:
Posts (Atom)