New Autosnort Release, support for more distros and much more!

Hello,

Lots to talk about, so let's get started.

I finally got around to finishing testing for the new, improved, and much cleaned up build of Autosnort that I had been hyping for a little while. For those who didn't see the last blog post, or the screen shot, I've done a bit of housekeeping with Autosnort.

Instead of puking the output for every single command all over the screen buffer, Autosnort's output has been significantly minimized and cleaned up where it could be cleaned up. Output is now very metasploit-like:

[*] are things that the script is doing
[*] are things the user should pay attention to
[*] are successful results
[*] are unsuccessful results

"Okay, so what if something goes wrong? All I have is a generic 'something went wrong' comment." Well, instead of hoping whatever you need was caught in the screen buffer, autosnort now logs the output of the ENTIRE installation to /var/log/autosnort_install.log, and /var/log/[interface you chose to install here -- for example, snort_install.log], So now, instead of having to hope the screen buffer caught the relevant bits of a problem with my script, you now have an entire log of what the script was actually doing for review, or to send to me to debug the script and get it to work properly.

The script will now actually tell you where I installed things, instead of you having to hunt and guess (sorry about that..)

Additionally, this release sees support for Ubuntu 13.04 and Debian 7. Currently in the process of Verifying support for Kali Linux (Backtrack's newer, younger sibling), but since it's all supposed to based off Debian and follows the Debian software methodology, it should be pretty straightforward.

The child installer scripts all got this little makeover, and as previously mentioned also have logging built in, and write to their own log files in /var/log.

The only thing of note that changed here in addition to the minimizing of output would be that I finally added a prompt to run Aanval's BPU processes on boot via rc.local. That's something I've been meaning to do for a while.

So now that this is over with, the next step would be for me to focus on Getting CentOS updated -- Snorby and the cleaned up autosnort script. That is next up on my plate before enabling anymore features on any platform. period.

After that is finished, here's what I'd like to focus on:

- All web interfaces should have SSL/HTTPS enabled by default. No exceptions.
- Remove database/barebone sensors should have a method to secure database transactions to the "Master Console"
+ some point way far down the line, I want to begin experimenting with p0f. The project has recently gotten some new blood (as mentioned in a recent shmoocon), and there are some interesting possibilities I can think of where p0f and snort could play incredibly well off of one another:
--have p0f run for a set period of time, sample traffic off the network, fingerprint operating systems and write results to a database
--script something out that takes the database results and helps write frag3/stream5 reassembly policies based off p0f results.

Same as always, the scripts are available via The Autosnort Github Repo

That's about it for now. Happy snorting, hope you enjoy the new release!

DA_667

Autosnorby, updates to autosnort, and the updated to-do list

Hello Snort and Autosnort users.

I've got a lot to talk about today, so let's get started.

First and foremost, I've finally managed to work in support for snorby into autosnort. The snorby script installs the necessary packages, a compatible version of ruby (via rvm), all the necessary gems and configures the right files with the right info needed to get snorby up and running. Additionally, I've managed to work out away to drop privileges from the root database user to another user (the snort user in our case)

One thing to be aware of: the delayed_job and the sensor cache jobs do NOT start up on boot. Initial runs of the script had me trying to put commands into rc.local to start the delayed_job and sensorcachejob commands on startup... but they aren't working. I'm working on having a reliable method to start them on boot, but until that is discovered, any time the system is restarted, you'll want to, at a minimum start the delayed_job script:

cd /var/www/snorby && ruby script/delayed_job start

optionally, these commands run the Sensor and Daily cachejobs as well:

cd /var/www/snorby && rails runner 'Snorby::Jobs::SensorCacheJob.new(false).perform; Snorby::Jobs::DailyCacheJob.new(false).perform'

There are options to start the snorby worker process via the web UI, but I find the direct approach to my liking.

Another note is that at first you may notice alerts coming in and displaying properly in the events tab, but the dashboard may not updated at first. If this is the case, on the dashboard page, there is an option to force cache update. Select this option, wait 10 seconds, and reload the page. the graphs should update.

Next up on the list, is the main autosnort script itself. I've done a bit of spring cleaning.

- I've reduced the number of packages installed by default with autosnort.
--By default all we install are the packages necessary to install daq, libdnet, snort, and barnyard 2 with the ability to write to a remote database (more on this in a minute)
--I introduced a quick check that asks the user if they plan on installing a web interface as a part of the autosnort installation, or if they just want a stripped-down barebones install. If you're not sure what option to pick, select option 1.

- I've added a couple of functions to the script near the beginning for pulled pork to facilitate code re-use. this is because:

-- I've added support to download snort rules from previous versions of snort; up to four versions prior.

Why: I ran into a little problem recently where the free rules for version 2.9.4.5 were not available yet, and snort version 2.9.4.6 had just came out. The current version of the script only checks for the current version of snort rules, and one version prior. So now, you have a choice for four versions of rules:

1) the current version (if you have a VRT subscription oink code; e.g. 2.9.4.6)
2) the previous version (the kind that registered users usually get access to; e.g. 2.9.4.5)
3) two more prior versions (in the event that they are needed and/or a similar situation arises)

- If the user has elected to not install a web interface, the script asks them if they have a remote database they want barnyard to log to. I haven't officially tested this feature yet, but theorhetically, this allows for distributed installations... Any volunteers to test this? :)

- The child shell scripts all have functionality to install the packages necessary for them to work individually Again to reduce clutter and excess packages installed by autosnort (e.g. reduce attack surface)

- thanks to DK1844, I have a couple of code cleaniness fixes that I have added, and future todo list items.

I've achieved most of the stuff I intended to do when I initially started this little project, but I still have more that I can do.

Speaking of to-do list items:

- SSL for all web interfaces (generate a default, self-signed SSL cert, use mod-rewrite and mod-ssl to force ssl usage for all web interfaces)
- Further testing with distributed installations (Can I get a master console to register events from a remote system?)
- Encrypted comms between master console and remote sensor (e.g. have barnyard dump database updates to the master console over a secure channel)
- Kali Linux testing! Since Kali is fully compliant with Debian standards, will the debian autosnort script work with it?


The updates to autosnort.sh, snorby, aanval, snortreport and base child shell scripts are being pushed to ubuntu tonight, with support for other operating systems (debian and centOS) to come soon.

Report bugs, problems, praise, feature requests, etc. to:

deusexmachina667 [at] gmail [dot] com

As always the code is on my github repo.

Happy snorting,

DA_667

New AS release, New init scripts, bug fixes and more!

Hello AS users,

Got a lot to talk about today, so let's get down to business:

First and foremost I've finally gotten around to writing half-decent documentation for autosnort. I've pushed a pdf file to github featuring documentation with screenshots on how to install Autosnort via vmware player, including an interesting hack on how to get bridging to work on multiple interfaces on vmware player 5.

I chose CentOS as the vmware player operating system, but the instructions should be easy to follow for Debian Ubuntu or Backtrack. Any major differences were noted. All said and done it was about 23 pages of documentation with screenshots peppered in.

I focused on using VMware player this time around, and generally speaking the VMware player guidance can be used just as well for VMware Fusion or Workstation. I may do an alternate document for ESXi and/or Virtualbox in the near future.

I've also included general troubleshooting steps and things you *should* see after running autosnort.

Next in line is an update to the autosnort script for Debian, Ubuntu, and CentOS. Banyard2.13 BETA2 has changed how barnyard2 behaves. As a result of this, I had to change how arguments are passed to barnyard2 in Autosnort. The details are available for each operating system's readme files. Suffice to say, everything works fine now.

Finally, I've gotten around to testing and posting init scripts for Ubuntu and Debian to control snort and barnyard2. The Ubuntu and Debian init scripts support start, stop and restart functions and are pretty easy to implement. Implemtation details are also available via the Readme files for Ubuntu and Debian Autosnort scripts, but suffice to say, its incredibly easy.

I may release a modification to the init script that detects if you installed aanval and automatically start/stop the BPUs along with snort and barnyard2, but that will come a little later.

The documentation, new scripts, readmes and init scripts should all be available via github as of now.

Cheers,

DA