As I had mentioned a few blog posts ago updates to autosnort and/or support for snorby were probably going to be staggered out across platforms, since I have to do testing to ensure that things aren't horribly broken on release, that I have the right packages for the right platform that puts the right stuff in the right place, etc.
That being said, porting over the changes to autosnort and support for snorby to Debian went fast. Like, really fast. I should have figured this would be the case since Ubuntu and Debian share similarity in packages installed and package management utilized. It was almost quite literally a copy/paste job -- copy the code from ubuntu autosnort and it its child shell scripts, integrate it in with debian's existing scripts (and some custom things that Debian needs to work right) and just test it to make sure nothing exploded in a fit of errors and incompatibility.
Therefore, it brings me great pleasure to release a new version of autosnort for Debian as well as a snorby child shell script for Debian-based systems, and code improvements to debian autosnort and child shell scripts.
I'm not going to bother going over all of the changes I made to the script(s), since more or less the changes are practically identical to the ubuntu/autosnorby post I made yesterday (e.g. code cleanup, doing things that make sense to make the code easier to manage, installing relevant packages only when they are needed for a particular interface/function, etc.) except to note that I fixed a small bug in the remote database/experimental distributed sensor installation support (In both Ubuntu and Debian)
Speaking of the distributed installation support, I have a rough guide to doing a distributed install. This is very, very rough right now, expect some official or at least "better" guidance soon:
1. Perform a standard autosnort install on your "master console" system, and choose the interface you wish to install. Bear in mind that aanval requires licensing to support more than one snort sensor, and that snort report doesn't really clearly delinate which sensor an event came from. Reboot.
2. Edit /etc/mysql/my.cnf and reconfigure mysql to accept connections globally (e.g. listen on 0.0.0.0; also note that you'd better have a security measure of some sort up to limit connections to your other sensors (e.g. a firewall) if you plan on having this system accessible in *any* way over the internet)
3. run mysql -uroot -p[password here]
GRANT ALL ON snort.* TO snort@'184.108.40.206' IDENTIFIED BY 'my_password';
snort@'220.127.116.11' should be the snort database user on the remote sensor you plan to have store events on your master console, likewise the IDENTIFIED BY 'my_password'; should be the password you place into barnyard2.conf to talk to the master console.
4. Run the autosnort installer on your barebones sensor (choose option 2 to NOT install apache or mysql), somewhere down the line, the script will ask if you have a remote database that barnyard2 will be logging into. Enter the username (snort), the remote database name (snort), the remote database ip (e.g. the management interface for your 'master console' sensor), and the password you entered above on the mysql statement on the master console
5. finish the autosnort install (when it gets to the what interface do you want to install phase, just select option 6 for no interface at all.)
6. On the barebones sensor, install mysql-client (apt: apt-get install mysql-client) and try to connect to the database on the master console:
mysql -uroot -psnort -h [master console ip address]
If you get output, and a list of database tables, that's a very good sign. Otherwise you have some troubleshooting to do. note that by default autosnort installs libmysqlclient to allow barnyard2 to talk to the remote database, however, I'm having you install mysql-client in the event you want to troubleshoot and verify that you can talk to the database as a regular user. libmysqlclient won't let you test things out with manual queries, etc.
I can't re-iterate this enough, but allowing mysql to listen globally opens up some security risks (which is why I've trying to move to having the traffic SSL wrapped and tunneled between sensors/consoles...), so I would most definitely make sure the network your barebone sensor and master consoles are talking over is protected, trusted, and your master console host is firewalled to hell and back, only allowing 3306/tcp connections from your barebone sensors. Know the risks before you take this leap.
Check out the autosnort github and happy snorting!