Snort and OSSEC – UNIX intrusion detection
Many of you have probably used snort for network intrusion detection. Snort is the most popular open-source NIDS, and features many detection plugins. For me, I haven't given much thought to what NIDS I'd use, and just installed snort on the system I maintain.
The problem
One problem with snort however is that it's only passive: it detects intrusion attempts, reports them to syslog, and sits back. This is not what I want, as I'm not always monitoring my syslog. At the least, I want email alerts when something strange happens. Even better, I'd like the IDS to perform soms actions to restrict malicious traffic once it starts. By blocking all packets from someone who is port scanning, for example.
A solution
A solution to the first problem is to install swatch: a tool that watches the syslog, and sends email alerts. Using regular expressions, you define about which log entries you want to be alerted. Nice, but requires a lot of configuration, probably doesn't catch all alerts you want to know about, and still doesn't solve the passivity of the system. There are solutions that both notify and implement counter-measures, turning snort into an Intrusion Prevention System (IPS) instead of just an IDS. Most well-known are SnortSam and Snort_inline.
A better solution
However, three is also OSSEC. OSSEC is a HIDS (Host-based Intrusion Detection System), and as such it does not watch the network traffic, but just the host. This means it checks the integrity of important files, and watches syslog. The good thing is, it knows about snort, and knows what its syslog messages look like. The better thing is, it is easily configured to perform actions, and by default adds firewall rules to drop traffic from IP addresses snort reports to be port scanning. OSSEC is configured by a large number of well-structured XML files, and operates in a distributed way. You can perform a standalone installation, or a server-agent setup. For my Xen machines, the dom0 is the server and the domUs are agents, reporting to the server. This works great, since when the domU machines report malicious traffic, the dom0 will drop all the traffic from the attacker's IP, protecting all domUs and dom0.
And, OSSEC sends email alerts to inform you about what's going on. What severity an alert must have for the admin to be emailed can be configured. One caveat however, some alerts ignore these settings and are emailed anyway (as can be configured in the alert's XML file).
I've attached two patches to the config to make OSSEC aware of denied AXFR requests by BIND (which it would otherwise email about), and to ignore unexpectedly terminated SSH sessions.
Xen on Debian Lenny
A few months ago, I tried to install Xen on Debian Lenny (testing). Xen is a hypervisor: it runs on the CPU in a lower ring than Linux, and regulates the resource access by virtual machines. These virtual machines aren't so virtual with Xen, as they have direct access to the CPU, memory, and any other devices you assign to them. With Xen, you run multiple OSs in parallel.
The problem
Installation of the hypervisor and xend went fine, and I created a few domUs with debootstrap. However, I couldn't get them to boot. After some googling I found that the xennified kernels in Lenny are only dom0 kernels, not domU for some reason. So, I installed kernels from Etch (2.6.18), and everything worked. Sort of.
This week I have to install a new server with Xen however, and I wasn't happy with my mixed Lenny/Etch solution. Since Lenny is testing and a lot changes in the package base, I decided to try Xen with Lenny again. I installed Lenny on a test PC, installed the xen-linux-system metapackage along with the xen-tools, and kernel 2.6.26-xen. I installed a domU machine with debootstrap/lenny, and tried to boot it. It wouldn't give me a console however. It went through the init scripts until the point where you'd expect a login prompt. Weird.
A solution
Some googling again, and it seems that the udev package, which is required, isn't installed by debootstrap.
- Mount the harddisk image:
mount -o loop /var/xen/domains/[domain]/disk.img /mnt/tmp - Enter the mounted filesystem:
cd /mnt/tmp - Download udev and libvolume-id0:
aptitude download udev libvolume-id0 - chroot into the mounted filesystem:
chroot /mnt/tmp - Install the packages:
dpkg -i *.deb - Umount:
cd /; umount /mnt/tmp
A better solution
Now you have a working lenny image. The other way is much easier (with thanks to Bernard): when creating the image, pass the --role=udev option to xen-create-image.
[Note: as of this writing, Lenny is expected to be released as stable within 2-4 days. So, the xen behaviour could still change]