05.27.09
Posted in OpenSourceSoftware, Security, PRADS at 1:23 pm by Edward Bjarte Fjellskål
PRADS is finally getting somewhere!
Since last time, Kacper Wysocki has joined the project, working mostly on the OS SYN/SYN-ACK fingerprinting and the DBI implementation and being a great resource in all aspects of the project.
So, at this stage, PRADS now has implemented:
* OS fingerprinting, both SYN and SYN+ACK (IP/TCP) (Compatible with p0f fingerprints)
* TCP service fingerprinting (Signatures from/compatible with pads)
* TCP discovery of hosts (SYN and SYN+ACK)
* UDP discovery of hosts (Work to be done on UDP service detection)
* UDP OS fingerprinting
* ARP discovery of hosts
* MAC vendor fingerprinting (from ARP data)
* ICMP discovery of host
* ICMP OS fingerprinting
* perl DBI support (sqlite (default), MySQL, PostgreSQL, Oracle, MSSQL…)
* Daemon mode
* Some packet statistics (received,dropped,drop-rate and dropped by interface)
All this is done passively.
ICMP and UDP fingerprinting is not 100% accurate, but it gives an indication and therefor added for building up a higher confidence level for a “total” OS detection/fingerprinting.
One of my main goals, was to use PRADS with my Sguil setup. PRADS would be replacing PADS and also giving OS info to the Sguil console. Also I would like PRADS to populate the attribute_table for Snort automatically. See http://snort.org/docs/ for more info on the attribute_table and why you should need it.
PRADS was also intended to work separately, and now that we have support for different databases through perl DBI, it should be ready for a GUI (WebGUI maybe..). The GUI could extract the info, and maybe draw a “real-time” map of your network… First off I believe, would be the need for grouping stuff by OS, Services and IP/mask etc.
Some near future TODOs:
* TCP Service discovery/matching needs polishing for performance
* UDP Service detection (To the extent it is possible of doing so)
* Client application detection/fingerprinting
* Performance optimization all over
* Code clean up
* WebGUI or some GUI
We would also very much like help on verifying/adding fingerprints (SYN, SYN-ACK, ICMP and UDP). Testing and feedback on ideas/thoughts would also be much appreciated 
“Know your assets!”
Permalink
05.14.09
Posted in Information, OpenSourceSoftware, SuSE, Debian, Ubuntu, Redhat, Virtualization, CentOS, Security at 5:30 pm by Edward Bjarte Fjellskål
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!
Permalink
05.01.09
Posted in Information, OpenSourceSoftware, Ubuntu, Snort at 7:00 am by Edward Bjarte Fjellskål
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!
Permalink
