OSS and Security @ WORK
Back from vacation 
I did pack 2.8.6.0, but it never made it to the public before I went on vacations :/
You can find 2.8.6.1 here:
http://debs.gamelinux.org/snort/hardy/
-*> Snort! <*-
Version 2.8.6.1 IPv6 GRE (Build 39)
As Kacper stated here, PRADS 0.2.0 has been released!
You can download some debian packages here, or you can check out the GIT repo here.
Bug reports, issues, thoughts or any comments are very welcome!
Enjoy!
As Ubuntu 10.04 (Lucid Lynx) is the next LTS (Long Time Support) version of Ubuntu that is coming out soon (April 29, 2010), I have started to look at how sguil and my dot deb packages will work.
I installed Lucid Lynx yesterday and installed my server and sensor debs on it.
Some first notes:
* MySQL is not eating the create_sguildb.sql (Just remove the comments)
* Lucid (and Karmic) does not ship with tclx8.3(Installing the Hardy version worked just fine)
(I filled a bug report to Ubuntu, hoping to get tclx8.3 into the final release…)
So, from my first tests, it seems to work fine!
I have yet to test the sguil-client on Lucid, and also I did not get to test with extensive amount of traffic and operations on the Lucid test server.
So, looking promising
Saturday 18 Jun 2005 Matthew J. Shelton released PADS. PADS is a great tool, and the security industry really needs a good open source passive asset tool. But since 2005, PADS development has stopped, and there are no place to send new signature or patches/bugs too, and hope that they will get added/fixed. Also, logical, there are no new features being added…
I have used PADS in my Sguil setup, but have seen that it lacks stuff that I wanted to have there, and also, there has been some problems running PADS on newer operation systems. I have a copy of the pads-1.2-sguil-mods.tar.gz, and I added it to github yesterday, fixed some issues when writing data to the FIFO file for Sguil, added some patches, among vorants vlan patch. I compiled it on Ubuntu Hardy and Jaunty (x86_64), and it has been running fine for 12+ hours.
If you try out my version of PADS and have issues, I will try to solve them. I see there are some, in stuff that I don’t use, and if I one day find the urge, I’ll fix them on my own.
I should probably also mention, shamelessly again, that there is a project that takes PADS to the next level and then some more….
You can read about PRADS here and what more it can do for you.
Loglevel: INFO
I have packed snort 2.8.5.3 for Ubuntu Hardy and Jaunty:
http://debs.gamelinux.org/snort/hardy/
http://debs.gamelinux.org/snort/jaunty/
-*> Snort! <*-
Version 2.8.5.3 IPv6 (Build 124)
Loglevel: INFO
I have packed snort 2.8.5.1 for Ubuntu Hardy and Jaunty:
http://debs.gamelinux.org/snort/hardy/
http://debs.gamelinux.org/snort/jaunty/
I have changed the way I pack snort. I no longer pack the pgsql and mysql versions. I have also dropped prelude support. If you need them, drop me a line, and I’ll see what I can do. Its just my belief, that one should log in unified/2 format for speed, and let barnyard/2 take care of the rest
I also compile snort with IPv6.
-*> Snort! Version 2.8.5.1 IPv6 (Build 114) <*-
I see sloppy Administrators do this again and again…
They might update the Linux-Xen enabled Kernel on Dom0, but often DomU keeps the same for different reasons.
Running a (para) virtual environment, the freedom of running different Linux distributions, is often a goal. If one keeps a single architect environment stack, like Ubuntu Hardy Dom0 and DomU’s or CentOS 5.x Dom0 and DomU, keeping kernels in DomU up to date is low hassle.
The hassle starts to arise when you deploy mixed environments, like running Ubuntu Hardy as Dom0 and CentOS 5.x as DomU, or vice versa. You could setup CentOS or Ubuntu to use each others Kernel packages, though that seemed a bit overkill for my setup. Having a Debian Etch DomU on a Ubuntu Hardy Dom0 is fixable with pointing Etch to grab the Kernel from Hardy via an apt-repo.
PyGrub solves some hassles, so I recommend reading up on that and verifying that CVE-2007-4993 is not affecting you.
But for the cases where I have a bit hassle, and I dont want to use PyGrub, I wrote a small bash script to update the Linux Kernels.
Get the script here, and update/change/modify or learn from it, before you use it.
It Powers down the DomU if it is booted, and mounts the Logical Volume of the DomU, before it copies the kernel modules to the DomU filesystem. Runs depmod and unmounts the filesystem. Then it gives you the small change you need to update your xen-domU.cfg with (I dont use pygrub).
BTW: This paper has a nice walk through from Xen DomU to Xen Dom0 bypassing SELinux http://invisiblethingslab.com/pub/xenfb-adventures-10.pdf. Recommended read
Now go and update some Kernels!
Saturday 18th of April, I woke up to check my Sguil on my honeypot/net installation. I noticed that I was missing packets in my pcap files. I popped into the box to have a look, and it I noticed that Snort 2.8.4 had segfaulted. Mather of fact, it had done so 4 times in about 2 weeks.
Note: I use snort (snort -b) to dump pcap’s on this setup, and it was only this snort process that segfaulted, not snort in normal IDS or IPS mode.
I checked the last packets that snort was able to dump, and noticed that in each segfault, the same last packet was recorded. So I extracted it, and used tcpreplay to replay the traffic, and Snort segfaulted.
Contacting Sourcefire, I did a core dump of snort, a gdb backtrace, and sent it off… Lurene Grenier handled my issue, and worked on the bug that I hit.
I have been having some long days, so It took my a while to replicate and send of the data that Sourcefire needed. Sourcefire and Lurene replied quickly and gave me a good confidence that they take security and bug issues seriously
I don’t want to go into details on the bug, even though its not a direct security issue, it only has to do with how I’m using snort on the system to dump pcaps for all traffic. If your using snort without a “snort.conf” and just logging packets to a file, its easy to fix the problem by compiling snort with –enable-ipv6.
Guess I’d better change to daemonlogger on this setup too. Daemonlogger is aimed at doing traffic dumping to file.
I confirmed the bug on Ubuntu Hardy, but its likely to be valid on other setups.
Snort and Daemonlogger rules btw!
There is nothing like fresh baked software…
To play with OpenVAS 2.0 from svn on a Ubuntu Hardy/Intrepid/Jaunty host is easier than one would think. I post this, so more people can see how easy it is, and maybe get the urge to test it.
(I might have had some libs pre-installed, poke me if this doesn’t work for you…)
$ sudo aptitude install bison libglib2.0-dev subversion build-essential libgnutls-dev libpcap-dev libgpgme11-dev cmake
$ mkdir openvas ; cd openvas/
$ svn checkout https://svn.wald.intevation.org/svn/openvas/trunk/openvas-libraries
$ svn checkout https://svn.wald.intevation.org/svn/openvas/trunk/openvas-libnasl
$ svn checkout https://svn.wald.intevation.org/svn/openvas/trunk/openvas-server
$ svn checkout https://svn.wald.intevation.org/svn/openvas/trunk/openvas-plugins
$ cd openvas-libraries/ ; ./configure
$ make
$ sudo make install$ sudo echo “include /usr/local/lib/” >> /etc/ld.so.conf
$ sudo ldconfig$ cd ../openvas-libnasl/ ; ./configure
$ make
$ sudo make install
$ cd ../openvas-server/ ; ./configure
$ make
$ sudo make install
$ cd ../openvas-plugins/ ; ./configure
$ make
$ sudo make install# Make a Certificate
$ /usr/local/sbin/openvas-mkcert# Add a user
$ /usr/local/sbin/openvas-adduser# Try out the server with:
$ sudo /usr/local/sbin/openvasd -D
You should also install Nikto to get the extra web application vulnerability tests: http://www.cirt.net/nikto/nikto-current.tar.gz
or fresh from SVN
$ cd /usr/local/
$ sudo svn co http://svn2.assembla.com/svn/Nikto_2/trunk/ nikto-trunk
$ sudo ln -s /usr/local/nikto-trunk/nikto.pl /usr/local/bin/nikto
I also got the OpenVAS client from svn. On your Linux (Ubuntu Intrepid/Jaunty) desktop:
$ sudo aptitude install subversion build-essential cmake bison libgpgme11-dev
$ mkdir openvas; cd openvas
$ svn checkout https://svn.wald.intevation.org/svn/openvas/trunk/openvas-libraries
$ svn co https://svn.wald.intevation.org/svn/openvas/trunk/openvas-client
$ cd openvas-libraries ; ./configure
$ make
$ sudo make install
$ sudo echo “include /usr/local/lib/” >> /etc/ld.so.conf
$ sudo ldconfig
$ cd ../openvas-client ; ./configure
$ make
$ sudo make install
# To try it out:
$ /usr/local/bin/OpenVAS-Client
And you should keep an eye out for new Network Vulnerability Tests (NVTs) from OpenVAS. You should just run openvas-nvt-sync on your OpenVAS server, and thing should get updated.
Now scan your host(s)….
—
Updated 1. September 2009:
* Added ‘cmake, libgpgme11-dev and openvas-libraries’ to the client install
* Added nikto from svn
* Added Jaunty
I packed snort 2.8.4 for Ubuntu, Hardy (8.04) and Intrepid (8.10).
The snort Ubuntu packages can be found here:
http://debs.gamelinux.org/snort/
Please let me know if you find any errors or If you have suggestions on further enhancements.
Snort rules are not shipped with the debs. You should download them yourself from snort.org.
This work is licensed under a Creative Commons License.
·
XHTML
·
CSS