I run a number of Sguil deployments, of which some are on hardware that is extremely under-utilized, so I set out to determine what it would take to run multiple Sguil deployments on the same server.

The required configuration changes were relatively simple for most of the processes (Sguil agents, Snort, DaemonLogger, PADS, Barnyard) until I got to SANCP. The FreeBSD package at the time of this writing (v1.6.1_4) doesn't utilize a PID file, nor does it have a configuration option for defining one. This makes it very difficult to run multiple instances since without a PID file the rc.subsystem defaults to checking for the process name in the process table; thus leading to sancp already running? errors.

On a recently built FreeBSD 8.1 amd64 server I'm experiencing segmentation faults when I ctrl-c out of tcpdump on a busy network interface:

lab# tcpdump -ni bce1

tcpdump: WARNING: bce1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bce1, link-type EN10MB (Ethernet), capture size 96 bytes
01:52:39.537261 IP 192.168.20.114.51589 > 192.168.20.56.1344: tcp 291
^c

280 packets captured
1622 packets received by filter
822 packets dropped by kernel
Segmentation fault (core dumped)

If I run tcpdump through gdb the issue appears to be when calling free() in libc:

Program received signal SIGSEGV, Segmentation fault.
0x0000000800b276a7 in free () from /lib/libc.so.7
(gdb) bt
#0  0x0000000800b276a7 in free () from /lib/libc.so.7
#1  0x00000008006f5ac5 in pcap_cleanup_live_common () from /lib/libpcap.so.7
#2  0x00000008006f67b8 in pcap_create () from /lib/libpcap.so.7
#3  0x00000008006f563e in pcap_close () from /lib/libpcap.so.7

Anyone run into this before?

I was able to track down the cause of the seg faults, but not the reason (perhaps the libc library wasn't compiled correctly for the amd64 arch in the FreeBSD 8.1 release?)

If "BPF Zero Copy" is enabled then tcpdump will seg fault when the process is exiting. To test yourself enable it by adding the following to /etc/sysctl.conf

net.bpf.zerocopy_enable=1

then reboot to pick up the change.

-Dave

After spending multiple hours trying to diagnose a performance issue with NFS in my lab, I've suddenly stumbled upon a situation in which I can honestly say, I'm completely bewildered.

When copying a 256MB test file to the NFS mount the transfer takes ~70 seconds, which equates to roughly 3.6MB/s, i.e. very slow. The client and sever hardware is modern and equipped with Gigabit NICs and an accompanying Gigabit switch. With this hardware I'd expect average transfer speeds of 30-40MB/s, with the hard drives being the bottleneck.

So here's where it gets strange...

Hacme Shipping is a ColdFusion Web Application from the Foundstone, Inc series of vulnerable "Hacme" tools. As its name implies, Hacme Shipping is a mock Shipping application much like one you would find major on-line retailers using, except loaded with insecure code (on purpose!).

So in continuing the theme of my previous post, which detailed the process of Installing Hacme Bank, this article will hopefully provide another easy to follow, step-by-step guide to installing and configuring the application.

Whether you're evaluating a new vulnerability assessment tool, or looking to hone your application hacking skills, the Hacme Bank application by FoundStone, Inc offers a perfect "victim" for you to use as a testing target. Hacme Bank simulates an online banking website with the added bonus of having numerous vulnerabilities purposely designed in for you to discover.

In this write-up I'll walk you through the necessary steps for getting the application up and running on a Windows XP Professional VMWare image. I prefer this setup for a couple of reasons. First, if an unrecoverable error condition occurs (while hurling malicious packets at the application perhaps?) you can simply revert the Virtual Machine back to a known good state. Second, by positioning Hacme Back on an isolated machine I'm able to use my everyday penetration testing rig as the attack platform.

This is a continuation of my collection of articles pertaining to dual-booting Leopard and Kubuntu on a MacBook Pro. This article is just a quick rundown of the software packages that are always installed on my laptop.

Awhile back I wrote about adding custom tags to the Markdown Plugin in which I created two new custom tags, a "Note" and a "Warning" block. This time around I'm adding an additional custom Markdown tag which is an "Update" tag for when you want to signify that a portion of a previously published article has been altered.

In this article I'll be tinkering with one of Movable Types default plugins, John Gruber's Markdown, which is one of the text formatting choices available when working in the Entry Editor.

The brilliance of Markdown comes from it's powerful translations, combined with it's utter ease of use. Granted, it's not your typical WYSIWYG and did pose a slight comfort curve (the time and effort it takes to adjust to a new way of editing; for me at least!), but after writing only three articles with it I'm hooked!

Due to the recent growing popularity of dual-booting the MacBook Pro I decided to move the Kubuntu portion of my Leopard and Kubuntu on a MacBook Pro article into it's own entry. My hope is to find the time to tweak this article enough so it provides a thorough, step-by-step walk-through that others can use.

Thanks to a fun personality quirk of mine I find myself re-imaging my MacBook Pro on a regular basis, so I figured documenting the process would be a brilliant idea. The goal is actually twofold: to streamline the process for myself and to provide a baseline for folks attempting to re-create any of my experiments on their own MBPs.

The directions which follow apply to my dual boot MacBook Pro, your mileage may vary...