Tampilkan postingan dengan label freebsd. Tampilkan semua postingan
Tampilkan postingan dengan label freebsd. Tampilkan semua postingan

Selasa, 28 Desember 2010

Trying PC-BSD 8.2-BETA1

After reading PC-BSD 8.2-BETA1 Available for Testing last week I decided to give the latest version of PC-BSD a try on my ESXi server. I failed earlier to get the installation to succeed using PC-BSD 8.1, but I had no real issues with the new BETA1 based on FreeBSD 8.2 PRERELEASE. (PC-BSD will publish their final 8.2 version when the main FreeBSD project publishes 8.2 RELEASE.)

For this test I downloaded the 64 bit network installation .iso and installed the OS within ESXi. I decided to try a few new features offered by the PC-BSD installer, namely ZFS and disk encryption for user data as shown in the top screenshot. When I booted the VM I was prompted to enter the passphrase I used when installing the OS:

da0 at mpt0 bus 0 scbus0 target 0 lun 0
da0: Fixed Direct Access SCSI-2 device
da0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit)
da0: Command Queueing enabled
da0: 16384MB (33554432 512 byte sectors: 255H 63S/T 2088C)
Enter passphrase for da0p4:
GEOM_ELI: Device da0p4.eli created.
GEOM_ELI: Encryption: AES-XTS 128
GEOM_ELI: Crypto: software
Trying to mount root from zfs:tank0

That was cool. In addition to encryption, I need to learn more about how PC-BSD uses jails to support ports and packages. This is different compared to any other BSD I have seen.

PC-BSD is also supposed to be desktop-friendly, so I tried my "can I see a YouTube video out of the box" test. The screenshot at right shows it worked.

I should note that before I could connect remotely using SSH, I had to disable the Pf firewall. (I could also have reconfigured the firewall if I wanted it to stay active.)

Now that I have a working PC-BSD OS in my lab, I'll try to learn more about it. I'll probably wait until the RELEASE version arrives.

Trying VirtualBSD 8.1

Reece Tarbert sent an email announcing the availability of VirtualBSD 8.1, a version of FreeBSD 8.1 aimed at demonstrating FreeBSD on the desktop. It's a 1.3 GB zipped VMWare image that expands to 4.1 GB.

I downloaded the image via Bittorrent, expanded the image, and then used the VMWare Converter to transfer the VM from my laptop to my ESXi server. I accepted all the defaults and successfully converted the VM. However, after booting the VM I noticed the kernel did not recognize the network card. I shut down the VM, removed the NIC, and added a new e1000 NIC. After booting that version the VM recognized the NIC and got an IP address via DHCP from my Cisco 3750 switch.

One of my definitions of "desktop ready" is whether I can see YouTube videos out-of-the-box. As the screen capture shows, VirtualBSD worked without incident.

If you're wondering about PC-BSD, I plan to give version 8.2 a try soon. As I Tweeted last month, I had trouble with the installer and couldn't install 8.1 to my ESXi server. I could try installing to VMWare Workstation and then converting that VM too.

Kamis, 09 Desember 2010

Splunk 4.x on FreeBSD 8.x using compat6x Libraries

Two years ago I posted Splunk on FreeBSD 7.0 showing how to use the FreeBSD compat6x libraries to run the 3.4 version of Splunk compiled for FreeBSD 6.x. I decided to try this again, except using the newest Splunk on an amd64 FreeBSD system.

As you can see below, it took me only a few minutes to get the system running thanks to the precompiled compat6x-amd64 package. If I needed to install on i386, I could have used the ports tree.

r200a# uname -a

FreeBSD r200a.taosecurity.com 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:36:49
UTC 2010 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64

r200a# pkg_add -r ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-stable
/misc/compat6x-amd64-6.4.604000.200810_3.tbz
Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-stable
/misc/compat6x-amd64-6.4.604000.200810_3.tbz... Done.

*******************************************************************************
* *
* Do not forget to add COMPAT_FREEBSD6 into *
* your kernel configuration (enabled by default). *
* *
* To configure and recompile your kernel see: *
* http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig.html *
* *
*******************************************************************************

r200a# pkg_add splunk-4.1.6-89596-freebsd-6.2-amd64.tgz
----------------------------------------------------------------------
Splunk has been installed in:
/opt/splunk

To start Splunk, run the command:
/opt/splunk/bin/splunk start

To use the Splunk Web interface, point your browser at:
http://r200a.taosecurity.com:8000

Complete documentation is at http://www.splunk.com/r/docs
----------------------------------------------------------------------

r200a# /opt/splunk/bin/splunk start --accept-license
Copying '/opt/splunk/etc/myinstall/splunkd.xml.cfg-default' to '/opt/splunk/etc/myinstall/splunkd.xml'.
Copying '/opt/splunk/etc/openldap/ldap.conf.default' to '/opt/splunk/etc/openldap/ldap.conf'.
/opt/splunk/etc/auth/audit/private.pem
/opt/splunk/etc/auth/audit/public.pem
['openssl', 'genrsa', '-out', '/opt/splunk/etc/auth/audit/private.pem', '1024']
/opt/splunk/etc/auth/audit/private.pem generated.
/opt/splunk/etc/auth/audit/public.pem generated.
Generating RSA private key, 1024 bit long modulus
.........++++++
............................++++++
e is 65537 (0x10001)
writing RSA key

/opt/splunk/etc/auth/distServerKeys/private.pem
/opt/splunk/etc/auth/distServerKeys/trusted.pem
['openssl', 'genrsa', '-out', '/opt/splunk/etc/auth/distServerKeys/private.pem', '1024']
/opt/splunk/etc/auth/distServerKeys/private.pem generated.
/opt/splunk/etc/auth/distServerKeys/public.pem generated.
Generating RSA private key, 1024 bit long modulus
.............++++++
............................................++++++
e is 65537 (0x10001)
writing RSA key


This appears to be your first time running this version of Splunk.
Moving '/opt/splunk/share/splunk/search_mrsparkle/modules.new' to '/opt/splunk/share/splunk/search_mrsparkle/modules'.
Creating: /opt/splunk/var/lib
Creating: /opt/splunk/var/run/splunk
Creating: /opt/splunk/var/run/splunk/upload
Creating: /opt/splunk/var/spool/splunk
Creating: /opt/splunk/var/spool/dirmoncache
Creating: /opt/splunk/var/lib/splunk/authDb
Creating: /opt/splunk/var/lib/splunk/hashDb
Checking databases...
Validated databases: _audit, _blocksignature, _internal, _thefishbucket, history, main, sample, summary

Splunk> The IT Search Engine.

Checking prerequisites...
Checking http port [8000]: open
Checking mgmt port [8089]: open
Checking configuration... Done.
Checking index directory... Done.
Checking databases...
Validated databases: _audit, _blocksignature, _internal, _thefishbucket, history, main, sample, summary
All preliminary checks passed.

Starting splunk server daemon (splunkd)... Done.
Starting splunkweb... /opt/splunk/share/splunk/certs does not exist. Will create
Generating certs for splunkweb server
Generating a 1024 bit RSA private key
............++++++
.................++++++
writing new private key to 'privkeySecure.pem'
-----
Signature ok
subject=/CN=r200a.taosecurity.com/O=SplunkUser
Getting CA Private Key
writing RSA key
Done.

If you get stuck, we're here to help.
Look for answers here: http://www.splunk.com/base/Documentation

The Splunk web interface is at http://r200a.taosecurity.com:8000

And that's it! I pointed my Web browser to the FreeBSD server and I accessed Splunk. Kudos to Splunk for providing a free version of their product to run in this manner!

Postscript: I realized Splunk installs to /opt, which on this system lives in /, which is small. So, I made this change after stopping Splunk:

r200a# mv /opt /nsm/
r200a# ln -s /nsm/opt/ /opt

That put Splunk in the larger /nsm partition. I should have created the symlink before installing, but no real harm was done anyway.

Kamis, 18 November 2010

The Problem Is with Gmail

In my last post I lamented a problem with Sendmail on FreeBSD. I was trying to troubleshoot a problem sending email from FreeBSD's periodic scripts to Gmail. I've determined that, as crazy as this sounds, Gmail is broken. (Some of you are probably not surprised. If you want to skip the drama and see the bottom line, scroll to the bottom of the post.)

Let me start my case by showing network transcripts of one successful "periodic" email and one unsuccessful "periodic" email. I'm not going to change any email addresses in this post.

The following email is delivered successfully. Computer vm.taosecurity.com sits behind NAT so the public IP is 73.128.35.11. The entries prior to the SMTP transactions (e.g. 074.125.091.027.00025-073.128.035.011.57184: and similar) were added by Tcpflow, which I used to render the transcript manually.

074.125.091.027.00025-073.128.035.011.57184: 220 mx.google.com ESMTP my6si2476635qcb.101

073.128.035.011.57184-074.125.091.027.00025: EHLO vm.taosecurity.com

074.125.091.027.00025-073.128.035.011.57184: 250-mx.google.com at your service, [73.128.35.11]
250-SIZE 35651584
250-8BITMIME
250-ENHANCEDSTATUSCODES
250 PIPELINING

073.128.035.011.57184-074.125.091.027.00025: MAIL From:<analyst@vm.taosecurity.com> SIZE=917

074.125.091.027.00025-073.128.035.011.57184: 250 2.1.0 OK my6si2476635qcb.101

073.128.035.011.57184-074.125.091.027.00025: RCPT To:<taosecurity@gmail.com>
DATA

074.125.091.027.00025-073.128.035.011.57184: 250 2.1.5 OK my6si2476635qcb.101
354 Go ahead my6si2476635qcb.101

073.128.035.011.57184-074.125.091.027.00025: Received: from vm.taosecurity.com (localhost [127.0.0.1])
.by vm.taosecurity.com (8.14.4/8.14.4) with ESMTP id oAJ66xa2021306
.for <root@vm.taosecurity.com>; Fri, 19 Nov 2010 01:06:59 -0500 (EST)
.(envelope-from analyst@vm.taosecurity.com)
Received: (from root@localhost)
.by vm.taosecurity.com (8.14.4/8.14.4/Submit) id oAJ66xF4021296
.for root; Fri, 19 Nov 2010 01:06:59 -0500 (EST)
.(envelope-from analyst)
Date: Fri, 19 Nov 2010 01:06:59 -0500 (EST)
From: analyst <analyst@vm.taosecurity.com>
Message-Id: <201011190606.oAJ66xF4021296@vm.taosecurity.com>
To: root@vm.taosecurity.com
Subject: vm.taosecurity.com security run output

Checking setuid files and devices:

Checking for uids of 0:
root 0
toor 0

Checking for passwordless accounts:

Checking login.conf permissions:

vm.taosecurity.com login failures:

vm.taosecurity.com refused connections:

-- End of security output --

073.128.035.011.57184-074.125.091.027.00025: .

074.125.091.027.00025-073.128.035.011.57184: 250 2.0.0 OK 1290128829 my6si2476635qcb.101

073.128.035.011.57184-074.125.091.027.00025: QUIT

074.125.091.027.00025-073.128.035.011.57184: 221 2.0.0 closing connection my6si2476635qcb.101

The following email fails to be delivered. Computer r200b has the public IP address 73.128.35.11 as shown. Again the lines are prepended by Tcpflow headers.

074.125.091.027.00025-073.128.035.011.19228: 220 mx.google.com ESMTP f23si2500736qcq.34

073.128.035.011.19228-074.125.091.027.00025: EHLO r200b.taosecurity.com

074.125.091.027.00025-073.128.035.011.19228: 250-mx.google.com at your service, [73.128.35.11]
250-SIZE 35651584
250-8BITMIME
250-ENHANCEDSTATUSCODES
250 PIPELINING

073.128.035.011.19228-074.125.091.027.00025: MAIL From:<richard@r200b.taosecurity.com> SIZE=1658

074.125.091.027.00025-073.128.035.011.19228: 250 2.1.0 OK f23si2500736qcq.34

073.128.035.011.19228-074.125.091.027.00025: RCPT To:<taosecurity@gmail.com>
DATA

074.125.091.027.00025-073.128.035.011.19228: 250 2.1.5 OK f23si2500736qcq.34
354 Go ahead f23si2500736qcq.34

073.128.035.011.19228-074.125.091.027.00025: Received: from r200b.taosecurity.com (localhost [127.0.0.1])
.by r200b.taosecurity.com (8.14.4/8.14.4) with ESMTP id oAJ17UwM063291
.for <root@r200b.taosecurity.com>; Thu, 18 Nov 2010 20:07:30 -0500 (EST)
.(envelope-from richard@r200b.taosecurity.com)
Received: (from root@localhost)
.by r200b.taosecurity.com (8.14.4/8.14.4/Submit) id oAJ17UKs063248
.for root; Thu, 18 Nov 2010 20:07:30 -0500 (EST)
.(envelope-from richard)
Date: Thu, 18 Nov 2010 20:07:30 -0500 (EST)
From: Richard Bejtlich <richard@r200b.taosecurity.com>
Message-Id: <201011190107.oAJ17UKs063248@r200b.taosecurity.com>
To: root@r200b.taosecurity.com
Subject: r200b.taosecurity.com security run output

Checking setuid files and devices:

Checking for uids of 0:

root 0
toor 0

Checking for passwordless accounts:

Checking login.conf permissions:

r200b.taosecurity.com kernel log messages:
+++ /tmp/security.QW4ZT9Yc.2010-11-18 20:07:29.000000000 -0500

+bge0: promiscuous mode enabled
+bge0: promiscuous mode disabled
+bge0: promiscuous mode enabled
+bge0: promiscuous mode disabled
+bge0: promiscuous mode enabled
+bge0: promiscuous mode disabled
+bge0: promiscuous mode enabled

r200b.taosecurity.com login failures:

Nov 17 07:51:58 r200b sshd[53170]: error: connect_to 73.128.35.11 port 80: failed.
Nov 17 07:52:02 r200b sshd[53170]: error: connect_to 73.128.35.11 port 80: failed.

r200b.taosecurity.com refused connections:

Checking for a current audit database:

Database created: Thu Nov 18 19:05:00 EST 2010

Checking for packages with security vulnerabilities:

0 problem(s) in your installed packages found.

-- End of security output --

073.128.035.011.19228-074.125.091.027.00025: .

074.125.091.027.00025-073.128.035.011.19228: 550-5.7.1 [73.128.35.11] The IP you're using to send mail is not authorized to
550-5.7.1 send email directly to our servers. Please use the SMTP relay at your
550-5.7.1 service provider instead. Learn more at
550 5.7.1 http://mail.google.com/support/bin/answer.py?answer=10336 f23si2500736qcq.34

073.128.035.011.19228-074.125.091.027.00025: QUIT

Darn. As you can see, Gmail claims "The IP you're using to send mail is not authorized to send email directly to our servers." Is that true? Didn't I just send email from the same IP address, as far as Gmail was concerned?

There is basically no difference between these emails, other than the contents of the security reports in each. (Hint, hint.)

I can prove the Gmail error message is bogus.

Let's start by showing both computers can send email to Gmail. If I don't send email using the periodic scripts, I can send email to Gmail from both systems successfully.

First, the message from host vm succeeds (and I saw it in my Inbox).

vm# mail -v -s "From vm" taosecurity@gmail.com
Test from vm.
.
EOT
taosecurity@gmail.com... Connecting to [127.0.0.1] via relay...
220 vm.taosecurity.com ESMTP Sendmail 8.14.4/8.14.4; Fri, 19 Nov 2010 01:31:20 -0500 (EST)
>>> EHLO vm.taosecurity.com
250-vm.taosecurity.com Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-DELIVERBY
250 HELP
>>> MAIL From:<analyst@vm.taosecurity.com> SIZE=58
250 2.1.0 <analyst@vm.taosecurity.com>... Sender ok
>>> RCPT To:<taosecurity@gmail.com>
>>> DATA
250 2.1.5 <taosecurity@gmail.com>... Recipient ok
354 Enter mail, end with "." on a line by itself
>>> .
250 2.0.0 oAJ6VKaj021400 Message accepted for delivery
taosecurity@gmail.com... Sent (oAJ6VKaj021400 Message accepted for delivery)
Closing connection to [127.0.0.1]
>>> QUIT
221 2.0.0 vm.taosecurity.com closing connection

vm# grep oAJ6VKaj021400 /var/log/maillog

Nov 19 01:31:20 vm sm-mta[21400]: oAJ6VKaj021400: from=<analyst@vm.taosecurity.com>,
size=393, class=0, nrcpts=1, msgid=<201011190631.oAJ6VKlp021399@vm.taosecurity.com>,
proto=ESMTP, daemon=Daemon0, relay=localhost [127.0.0.1]

Nov 19 01:31:20 vm sendmail[21399]: oAJ6VKlp021399: to=taosecurity@gmail.com, ctladdr=analyst
(1001/1001), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30058, relay=[127.0.0.1]
[127.0.0.1], dsn=2.0.0, stat=Sent (oAJ6VKaj021400 Message accepted for delivery)

Nov 19 01:31:21 vm sm-mta[21402]: oAJ6VKaj021400: to=<taosecurity@gmail.com>,
ctladdr=<analyst@vm.taosecurity.com> (1001/1001), delay=00:00:01, xdelay=00:00:01,
mailer=esmtp, pri=30393, relay=gmail-smtp-in.l.google.com. [74.125.91.27], dsn=2.0.0, stat=Sent
(OK 1290130290 g35si2521350qcs.118)

Second, the message from r200b succeeds (and I saw it in my Inbox).

r200b:/root# mail -v -s "From r200b" taosecurity@gmail.com
Test from r200b.
.
EOT
taosecurity@gmail.com... Connecting to [127.0.0.1] via relay...
220 r200b.taosecurity.com ESMTP Sendmail 8.14.4/8.14.4; Thu, 18 Nov 2010 20:31:01 -0500 (EST)
>>> EHLO r200b.taosecurity.com
250-r200b.taosecurity.com Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-DELIVERBY
250 HELP
>>> MAIL From:<richard@r200b.taosecurity.com> SIZE=64
250 2.1.0 <richard@r200b.taosecurity.com>... Sender ok
>>> RCPT To:<taosecurity@gmail.com>
>>> DATA
250 2.1.5 <taosecurity@gmail.com>... Recipient ok
354 Enter mail, end with "." on a line by itself
>>> .
250 2.0.0 oAJ1V1Xx063384 Message accepted for delivery
taosecurity@gmail.com... Sent (oAJ1V1Xx063384 Message accepted for delivery)
Closing connection to [127.0.0.1]
>>> QUIT
221 2.0.0 r200b.taosecurity.com closing connection

r200b:/root# grep oAJ1V1Xx063384 /var/log/maillog

Nov 18 20:31:01 r200b sm-mta[63384]: oAJ1V1Xx063384: from=<
richard@r200b.taosecurity.com>, size=417, class=0, nrcpts=1, msgid=<
201011190131.oAJ1V1SP063383@r200b.taosecurity.com>, proto=ESMTP, daemon=Daemon0,
relay=localhost [127.0.0.1]

Nov 18 20:31:01 r200b sendmail[63383]: oAJ1V1SP063383: to=taosecurity@gmail.com, ctladdr=richard
(1001/1001), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30064, relay=[127.0.0.1]
[127.0.0.1], dsn=2.0.0, stat=Sent (oAJ1V1Xx063384 Message accepted for delivery)

Nov 18 20:31:02 r200b sm-mta[63386]: oAJ1V1Xx063384: to=<taosecurity@gmail.com>,
ctladdr=<richard@r200b.taosecurity.com> (1001/1001), delay=00:00:01, xdelay=00:00:01,
mailer=esmtp, pri=30417, relay=gmail-smtp-in.l.google.com. [74.125.91.27], dsn=2.0.0, stat=Sent
(OK 1290130252 m5si2493978qcu.183)

As you can see, both computers, vm and r200b, can send email fine to Gmail.

Now this will blow your mind. What happens when I manually send an email with the content of the periodic email that Gmail refused to accept from r200b?

Let's send it from vm, which so far has had no trouble talking to Gmail under any circumstances, whether sending manual email or its own periodic output.

vm# mail -v -s "From vm, fake periodic output for blog" taosecurity@gmail.com
Checking setuid files and devices:

Checking for uids of 0:
root 0
toor 0

Checking for passwordless accounts:

Checking login.conf permissions:

r200b.taosecurity.com kernel log messages:
+++ /tmp/security.QW4ZT9Yc.2010-11-18 20:07:29.000000000 -0500
+bge0: promiscuous mode enabled
+bge0: promiscuous mode disabled
+bge0: promiscuous mode enabled
+bge0: promiscuous mode disabled
+bge0: promiscuous mode enabled
+bge0: promiscuous mode disabled
+bge0: promiscuous mode enabled

r200b.taosecurity.com login failures:
Nov 17 07:51:58 r200b sshd[53170]: error: connect_to 73.128.35.11 port 80: failed.
Nov 17 07:52:02 r200b sshd[53170]: error: connect_to 73.128.35.11 port 80: failed.

r200b.taosecurity.com refused connections:

Checking for a current audit database:

Database created: Thu Nov 18 19:05:00 EST 2010

Checking for packages with security vulnerabilities:

0 problem(s) in your installed packages found.

-- End of security output --
.
EOT
taosecurity@gmail.com... Connecting to [127.0.0.1] via relay...
220 vm.taosecurity.com ESMTP Sendmail 8.14.4/8.14.4; Fri, 19 Nov 2010 02:03:17 -0500 (EST)
>>> EHLO vm.taosecurity.com
250-vm.taosecurity.com Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-DELIVERBY
250 HELP
>>> MAIL From:<analyst@vm.taosecurity.com> SIZE=1026
250 2.1.0 <analyst@vm.taosecurity.com>... Sender ok
>>> RCPT To:<taosecurity@gmail.com>
>>> DATA
250 2.1.5 <taosecurity@gmail.com>... Recipient ok
354 Enter mail, end with "." on a line by itself
>>> .
250 2.0.0 oAJ73HIk021517 Message accepted for delivery
taosecurity@gmail.com... Sent (oAJ73HIk021517 Message accepted for delivery)
Closing connection to [127.0.0.1]
>>> QUIT
221 2.0.0 vm.taosecurity.com closing connection

vm# grep oAJ73HIk021517 /var/log/maillog

Nov 19 02:03:17 vm sm-mta[21517]: oAJ73HIk021517: from=<analyst@vm.taosecurity.com>,
size=1361, class=0, nrcpts=1, msgid=<201011190703.oAJ73G8n021516@vm.taosecurity.com>,
proto=ESMTP, daemon=Daemon0, relay=localhost [127.0.0.1]

Nov 19 02:03:17 vm sendmail[21516]: oAJ73G8n021516: to=taosecurity@gmail.com, ctladdr=analyst
(1001/1001), delay=00:00:01, xdelay=00:00:00, mailer=relay, pri=31026, relay=[127.0.0.1]
[127.0.0.1], dsn=2.0.0, stat=Sent (oAJ73HIk021517 Message accepted for delivery)

Nov 19 02:03:18 vm sm-mta[21519]: oAJ73HIk021517: to=<taosecurity@gmail.com>,
ctladdr=<analyst@vm.taosecurity.com> (1001/1001), delay=00:00:01, xdelay=00:00:01,
mailer=esmtp, pri=31361, relay=gmail-smtp-in.l.google.com. [74.125.91.27], dsn=5.0.0,
stat=Service unavailable

Nov 19 02:03:18 vm sm-mta[21519]: oAJ73HIk021517: oAJ73IIk021519: DSN: Service unavailable

What's up with that, Gmail? If I sniff the traffic I can see Gmail refuse it again:

074.125.091.027.00025-073.128.035.011.58727: 220 mx.google.com ESMTP o12si2579217qcs.143

073.128.035.011.58727-074.125.091.027.00025: EHLO vm.taosecurity.com

074.125.091.027.00025-073.128.035.011.58727: 250-mx.google.com at your service, [73.128.35.11]
250-SIZE 35651584
250-8BITMIME
250-ENHANCEDSTATUSCODES
250 PIPELINING

073.128.035.011.58727-074.125.091.027.00025: MAIL From:<analyst@vm.taosecurity.com> SIZE=1361

073.128.035.011.58727-074.125.091.027.00025: MAIL From:<analyst@vm.taosecurity.com> SIZE=1361

074.125.091.027.00025-073.128.035.011.58727: 250 2.1.0 OK o12si2579217qcs.143

073.128.035.011.58727-074.125.091.027.00025: RCPT To:<taosecurity@gmail.com>
DATA

074.125.091.027.00025-073.128.035.011.58727: 250 2.1.5 OK o12si2579217qcs.143
354 Go ahead o12si2579217qcs.143

073.128.035.011.58727-074.125.091.027.00025: Received: from vm.taosecurity.com (localhost [127.0.0.1])
.by vm.taosecurity.com (8.14.4/8.14.4) with ESMTP id oAJ73HIk021517
.for <taosecurity@gmail.com>; Fri, 19 Nov 2010 02:03:17 -0500 (EST)
.(envelope-from analyst@vm.taosecurity.com)
Received: (from root@localhost)
.by vm.taosecurity.com (8.14.4/8.14.4/Submit) id oAJ73G8n021516
.for taosecurity@gmail.com; Fri, 19 Nov 2010 02:03:16 -0500 (EST)
.(envelope-from analyst)
Date: Fri, 19 Nov 2010 02:03:16 -0500 (EST)
From: analyst <analyst@vm.taosecurity.com>
Message-Id: <201011190703.oAJ73G8n021516@vm.taosecurity.com>
To: taosecurity@gmail.com
Subject: From vm, fake periodic output for blog

Checking setuid files and devices:

Checking for uids of 0:
root 0
toor 0

Checking for passwordless accounts:

Checking login.conf permissions:

r200b.taosecurity.com kernel log messages:
+++ /tmp/security.QW4ZT9Yc.2010-11-18 20:07:29.000000000 -0500
+bge0: promiscuous mode enabled
+bge0: promiscuous mode disabled
+bge0: promiscuous mode enabled
+bge0: promiscuous mode disabled
+bge0: promiscuous mode enabled
+bge0: promiscuous mode disabled
+bge0: promiscuous mode enabled

r200b.taosecurity.com login failures:
Nov 17 07:51:58 r200b sshd[53170]: error: connect_to 73.128.35.11 port 80: failed.
Nov 17 07:52:02 r200b sshd[53170]: error: connect_to 73.128.35.11 port 80: failed.

r200b.taosecurity.com refused connections

Checking for a current audit database:

Database created: Thu Nov 18 19:05:00 EST 2010

Checking for packages with security vulnerabilities:

0 problem(s) in your installed packages found.

-- End of security output --

073.128.035.011.58727-074.125.091.027.00025: .

074.125.091.027.00025-073.128.035.011.58727: 550-5.7.1 [73.128.35.11] The IP you're using to send mail is not authorized to
550-5.7.1 send email directly to our servers. Please use the SMTP relay at your
550-5.7.1 service provider instead. Learn more at
550 5.7.1 http://mail.google.com/support/bin/answer.py?answer=10336 o12si2579217qcs.143

073.128.035.011.58727-074.125.091.027.00025: QUIT

The transcript ends with the bogus "The IP you're using to send mail is not authorized to send email directly to our servers." message. So what's the bottom line?

Gmail appears to be filtering email based on content, providing a bogus "The IP you're using to send mail is not authorized to send email directly to our servers." message.

Does anyone have another explanation? I would love to hear it. Thank you.

Incidentally, I am considering workarounds that WOULD use my ISP's SMTP server and hopefully avoid this problem. Also, I don't expect to see this issue using the Gmail Web interface. It must be a filter Gmail applies when users talk to their SMTP servers directly.

FreeBSD Sendmail Problem

Thanks for the help with my script issue recently. I was wondering if anyone has seen this problem with Sendmail? I aliased root to "taosecurity at gmail dot com" as shown below. (I used the real email address on the computer.) This is a fresh install of FreeBSD 8.1.

$ uname -a
FreeBSD vm.taosecurity.com 8.1-RELEASE FreeBSD 8.1-RELEASE #0: \
Mon Jul 19 02:55:53 UTC 2010 \
root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386

vm# diff -u /etc/aliases /etc/aliases.orig
--- /etc/aliases 2010-11-18 10:30:37.000000000 -0500
+++ /etc/aliases.orig 2010-11-18 10:30:26.000000000 -0500
@@ -18,7 +18,6 @@
# root's email from here.

# root: me@my.domain
-root: taosecurity at gmail dot com

# Basic system aliases -- these MUST be present
MAILER-DAEMON: postmaster
vm# newaliases
/etc/mail/aliases: 28 aliases, longest 21 bytes, 300 bytes total

My /etc/mail and /var/spool directories are pristine from the factory"

vm# ls -al /etc/mail
total 300
drwxr-xr-x 2 root wheel 512 Oct 31 11:28 .
drwxr-xr-x 20 root wheel 2048 Nov 18 10:30 ..
-rw-r--r-- 1 root wheel 6818 Jul 18 22:25 Makefile
-rw-r--r-- 1 root wheel 2905 Jul 18 22:25 README
-rw-r--r-- 1 root wheel 634 Jul 18 22:25 access.sample
-rw-r--r-- 1 root wheel 1695 Nov 18 10:30 aliases
-rw-r----- 1 root wheel 65536 Nov 18 10:30 aliases.db
-rw-r--r-- 1 root wheel 58276 Jul 18 22:25 freebsd.cf
-rw-r--r-- 1 root wheel 4118 Jul 18 22:25 freebsd.mc
-r--r--r-- 1 root wheel 40751 Jul 18 22:25 freebsd.submit.cf
-r--r--r-- 1 root wheel 901 Jul 18 22:25 freebsd.submit.mc
-r--r--r-- 1 root wheel 5657 Jul 18 22:25 helpfile
-rw-r--r-- 1 root wheel 409 Jul 18 22:25 mailer.conf
-rw-r--r-- 1 root wheel 253 Jul 18 22:25 mailertable.sample
-rw-r--r-- 1 root wheel 58276 Jul 18 22:25 sendmail.cf
-r--r--r-- 1 root wheel 40751 Jul 18 22:25 submit.cf
-rw-r--r-- 1 root wheel 582 Jul 18 22:25 virtusertable.sample

vm# ls -al /var/spool
total 16
drwxr-xr-x 8 root wheel 512 Jul 18 22:23 .
drwxr-xr-x 23 root wheel 512 Nov 12 11:45 ..
drwxrwx--- 2 smmsp smmsp 512 Nov 18 10:00 clientmqueue
drwxrwxr-x 2 uucp dialer 512 Nov 12 16:45 lock
drwxr-xr-x 2 root daemon 512 Jul 18 22:23 lpd
drwxr-xr-x 2 root daemon 512 Nov 18 10:31 mqueue
drwx------ 2 root daemon 512 Jul 18 22:23 opielocks
drwxr-xr-x 3 root daemon 512 Jul 18 22:23 output

I can send email when testing as root (email addr "obfuscated"):

vm# date | sendmail -v -Am postmaster
postmaster... aliased to root
root... aliased to taosecurity at gmail dot com
taosecurity at gmail dot com... Connecting to gmail-smtp-in.l.google.com. via esmtp...
220 mx.google.com ESMTP n10si1312258qcu.1
>>> EHLO vm.taosecurity.com
250-mx.google.com at your service, [98.218.35.11]
250-SIZE 35651584
250-8BITMIME
250-ENHANCEDSTATUSCODES
250 PIPELINING
>>> MAIL From: SIZE=29
250 2.1.0 OK n10si1312258qcu.1
>>> RCPT To:
>>> DATA
250 2.1.5 OK n10si1312258qcu.1
354 Go ahead n10si1312258qcu.1
>>> .
250 2.0.0 OK 1290094272 n10si1312258qcu.1
taosecurity at gmail dot com... Sent (OK 1290094272 n10si1312258qcu.1)
Closing connection to gmail-smtp-in.l.google.com.
>>> QUIT
221 2.0.0 closing connection n10si1312258qcu.1

That worked. However, I cannot send email as a user:

$ date | sendmail -v -Am postmaster
postmaster... aliased to root
root... aliased to taosecurity at gmail.com
collect: Cannot write ./dfoAIFVDIG019327 (bfcommit, uid=1001, gid=25): Permission denied
queueup: cannot create queue file ./qfoAIFVDIG019327, euid=1001, fd=-1, fp=0x0: Permission denied

Behavior is the same on FreeBSD 7.3 with a fresh install.

I did a ton of research and usually found references to incorrect permissions, etc. In fact, in this post I got the idea to check directories using mtree:

r200a# mtree -p /var -e -U -f /etc/mtree/BSD.var.dist
run changed
permissions expected 0755 found 0777 modified
r200a# mtree -p /var -e -U -f /etc/mtree/BSD.sendmail.dist
./var missing (created)
./var/spool missing (created)
./var/spool/clientmqueue missing (created)

Computer r200a was another FreeBSD system where I tried to fix this problem. However, these changes made no difference.

Any ideas? Thank you.

Update: The reason I investigated this activity was I found errors like this in /var/log/messages on another FreeBSD system, r200b:

Nov 13 03:01:11 r200b sm-mta[40505]: oAD81AUR040505: Losing ./qfoAD81AUR040505: savemail panic
Nov 13 03:01:11 r200b sm-mta[40505]: oAD81AUR040505: SYSERR(root): savemail: cannot save rejected email anywhere

As you can see, whatever was trying to send email using sm-mta was failing.

Sabtu, 13 November 2010

Calling FreeBSD Startup Script Experts

Has anyone encountered this situation? I've found several startup scripts on FreeBSD that result in duplicate arguments passed during startup. For example:

vm# uname -a
FreeBSD vm.taosecurity.com 7.3-RELEASE FreeBSD 7.3-RELEASE #0:
Sun Mar 21 06:15:01 UTC 2010
root@walker.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386

vm# pkg_info
sancp-1.6.1_3 A network connection profiler

vm# cat /etc/rc.conf

# -- sysinstall generated deltas -- # Fri Nov 12 16:36:42 2010
# Created: Fri Nov 12 16:36:42 2010
# Enable network daemons for user convenience.
# Please make all changes to this file, not to /etc/defaults/rc.conf.
# This file now contains just the overrides from /etc/defaults/rc.conf.
defaultrouter="10.10.1.1"
hostname="vm.taosecurity.com"
ifconfig_em0="inet 10.10.1.13 netmask 255.255.255.0"
sshd_enable="YES"
sancp_enable="YES"
sancp_interface="em0"

vm# cat /usr/local/etc/rc.d/sancp
#!/bin/sh
#

# PROVIDE: sancp
# REQUIRE: DAEMON
# BEFORE: LOGIN
# KEYWORD: shutdown

# Add the following lines to /etc/rc.conf to enable sancp:
# sancp_enable (bool): Set to YES to enable sancp
# Default: NO
# sancp_flags (str): Extra flags passed to sancp
# Default: -D
# sancp_conf (str): Sancp configuration file
# Default: /usr/local/etc/sancp.conf
# sancp_interface (str): Default: none - MUST BE SET
#
...edited, all comments...

. /etc/rc.subr

name="sancp"
rcvar=`set_rcvar`

command="/usr/local/bin/sancp"

start_precmd=start_precmd

start_precmd()
{
if [ -z "${sancp_interface}" ]; then
err 1 "sancp_interface must set."
fi
}

# set some defaults
load_rc_config $name

: ${sancp_enable="NO"}
: ${sancp_flags="-D"}
: ${sancp_conf="/usr/local/etc/sancp.conf"}
: ${sancp_interface=""}

command_args="${sancp_flags} -c ${sancp_conf} -i ${sancp_interface}"

run_rc_command "$1"

Now look what happens when I start sancp:

vm# /usr/local/etc/rc.d/sancp start
Starting sancp.
(4287) sancp daemonized successfully!

vm# ps -auxww | grep sancp
root 4287 0.0 0.9 4420 2264 ?? Ss 9:53PM 0:00.00
/usr/local/bin/sancp -D -D -c /usr/local/etc/sancp.conf -i em0

That's right, TWO instances of "-D".

I think it has something to do with this, extracted from sh -x output when starting the script another time:


+ _rc_conf_loaded=true
+ [ -f /etc/rc.conf.d/sancp ]
+ : YES
+ : -D
+ : /usr/local/etc/sancp.conf
+ : em0
+ command_args=-D -c /usr/local/etc/sancp.conf -i em0
+ run_rc_command start
+ _return=0
+ rc_arg=start
+ [ -z sancp ]
+ shift 1
+ rc_extra_args=
+ _rc_prefix=
+ eval _override_command=$sancp_program
+ _override_command=
+ command=/usr/local/bin/sancp
+ _keywords=start stop restart rcvar
+ rc_pid=
+ _pidcmd=
+ _procname=/usr/local/bin/sancp
+ [ -n /usr/local/bin/sancp ]
+ [ -n ]
+ _pidcmd=rc_pid=$(check_process /usr/local/bin/sancp )
+ [ -n rc_pid=$(check_process /usr/local/bin/sancp ) ]
+ _keywords=start stop restart rcvar status poll
+ [ -z start ]
+ [ -n ]
+ eval rc_flags=$sancp_flags
+ rc_flags=-D
...edited...
+ echo Starting sancp.
Starting sancp.
+ [ -n ]
+ _doit=/usr/local/bin/sancp -D -D -c /usr/local/etc/sancp.conf -i em0
+ [ -n ]
+ [ -n ]
+ _run_rc_doit /usr/local/bin/sancp -D -D -c /usr/local/etc/sancp.conf -i em0
+ debug run_rc_command: doit: /usr/local/bin/sancp -D -D -c /usr/local/etc/sancp.conf -i em0
+ eval /usr/local/bin/sancp -D -D -c /usr/local/etc/sancp.conf -i em0
+ /usr/local/bin/sancp -D -D -c /usr/local/etc/sancp.conf -i em0
(4075) sancp daemonized successfully!

That "rc_flags=-D" looks suspicious to me.

So what, two instances of -D, you might think. The problem is with more complicated scripts I'm seeing lots of command line arguments duplicated. It's not "clean" and I want to know what this is happening.

Incidentally, I get similar behavior on FreeBSD 8.1. I tried 7.3 here to see if there was a difference.

Any ideas? I've been looking at /etc/rc.subr to see if I can figure out how _run_rc_doit gets built.

For reference, the /usr/local/etc/sancp.conf file is stock:

vm# grep -v ^# /usr/local/etc/sancp.conf

# snort pcap filter format # description
var ip 8 # ether proto 0x0800 # ip traffic
var arp 1544 # ether proto 0x0806 # arp traffic
var loopback 144 # ether proto 0x9000 # Loopback: used to test ethernet interfaces
var 802.3 1024 # ether proto 0x0004 # IEEE 802.3 traffic

var pixfw1 10.10.10.1
var pixfw2 10.10.10.2
var webserver1 10.10.11.24
var webserver2 10.10.11.25
var webserver3 10.10.11.26
var dnsserver1 10.10.11.27
var dnsserver2 10.10.11.28
var mailserver1 10.10.11.29
var mailserver2 10.10.11.30
var proxyserver 10.10.11.30
var ntpserver 210.121.2.64

var icmp 1
var tcp 6
var udp 17

var http 80
var https 443
var ssh 22
var telnet 23
var irc_ports 6665-6667
var dns 53
var highports 1024-65535

known_ports tcp http,https,ssh,telnet,irc_ports,dns
known_ports udp dns

default realtime=log

default stats=log

default pcap=log

default limit=0

default timeout=120

default tcplag=0 # after a tcp connection would normally be considered closed

default rid=0

default status=0

default node=2

default strip-80211=enable

ip any any icmp any any, realtime=pass, pcap=pass, status=1, rid=23, timeout=1500 # test rule

arp any any any any any, ignore # ignore arp traffic
loopback any any any any any, ignore # ignore local ethernet loopback test packets
802.3 any any any any any, ignore # ignore IEEE 802.3 traffic on the switch

ip pixfw1 pixfw2 105 0 0, pcap pass, realtime=pass, status=100, rid=1 #2003-12-14 18:21:53

ip pixfw1 ntpserver 17 123 123, realtime=pass, status=200, rid=2 #2003-12-14 18:21:53
ip pixfw2 ntpserver 17 123 123, realtime=pass, status=200, rid=3 #2003-12-14 18:21:53

ip pixfw2 any tcp highports 80, realtime=pass, status=201, rid=4 #2003-12-14 18:21:53
ip pixfw2 any udp highports 443, realtime=pass, status=202, rid=6 #2003-12-14 18:21:53
ip pixfw2 any udp highports 53, realtime=pass, status=203, rid=5 #2003-12-14 18:21:53

ip proxyserver any tcp highports any, realtime=pass, status=299, rid=8 #2003-12-14 18:21:53

ip any webserver1 6 any 80, realtime=pass, status=301, rid=9 #2003-12-14 19:19:27
ip any webserver1 6 any 443, realtime=pass, status=302, rid=10 #2003-12-14 19:19:27

ip any webserver2 6 any 80, realtime=pass, status=301, rid=11 #2003-12-14 19:19:27
ip any webserver2 6 any 443, realtime=pass, status=302, rid=12 #2003-12-14 19:19:27

ip any webserver3 6 any 80, realtime=pass, status=301, rid=13 #2003-12-14 19:19:27
ip any webserver3 6 any 443, realtime=pass, status=302, rid=14 #2003-12-14 19:19:27

ip any dnsserver1 17 any 53, realtime=pass, status=303, rid=15 #2003-12-14 19:19:27
ip any dnsserver2 17 any 53, realtime=pass, status=303, rid=16 #2003-12-14 19:19:27

ip any mailserver1 6 any 25, realtime=pass, status=304, rid=17 #2003-12-14 19:19:27
ip mailserver1 any 6 any 25, realtime=pass, status=204, rid=18 #2003-12-14 19:19:27

ip any mailserver2 6 any 25, realtime=pass, status=304, rid=19 #2003-12-14 19:19:27
ip mailserver2 any 6 any 25, realtime=pass, status=204, rid=20 #2003-12-14 19:19:27


Selasa, 21 September 2010

NYCBSDCon 2010 Registration Open

Registration for NYCBSDCon 2010 is now open. As usual George and friends have assembled a great schedule! If you're in the New York city area or within travel distance, check it out.

Sabtu, 06 Maret 2010

Keeping FreeBSD Applications Up-to-Date in BSD Magazine

The March 2010 BSD Magazine includes an article I wrote titled Keeping FreeBSD Applications Up-to-Date.

It's a sequel to my article in the January 2010 BSD Magazine titled Keeping FreeBSD Up-to-Date: OS Essentials.

With these two articles published, they replace the versions I wrote in 2005.

I wrote these articles to demonstrate the variety of ways a system administrator can keep the FreeBSD operating system and applications up-to-date, with examples showing commands and effects.

Sabtu, 12 Desember 2009

Keeping FreeBSD Up-to-Date in BSD Magazine

Keep your eyes open for the latest printed BSD Magazine, with my article Keeping FreeBSD Up-To-Date: OS Essentials. This article is something like 18 pages long, because at the last minute the publishers had several authors withdraw articles. The publishers decided to print the extended version of my article, so it's far longer than I expected! We're currently editing the companion piece on keeping FreeBSD applications up-to-date. I expect to also submit an article on running Sguil on FreeBSD 8.0 when I get a chance to test the latest version in my lab.

Minggu, 06 Desember 2009

Troubleshooting FreeBSD Wireless Problem

My main personal workstation is a Thinkpad x60s. As I wrote in Triple-Boot Thinkpad x60s, I have Windows XP, Ubuntu Linux, and FreeBSD installed. However, I rarely use the FreeBSD side. I haven't run FreeBSD on the desktop for several years, but I like to keep FreeBSD on the laptop in case I encounter a situation on the road where I know how to solve a problem with FreeBSD but not Windows or Linux. (Yes I know about [insert favorite VM product here]. I use them. Sometimes there is no substitute for a bare-metal OS.)

When I first installed FreeBSD on the x60s (named "neely" here), the wireless NIC, an Intel(R) PRO/Wireless 3945ABG, was not supported on FreeBSD 6.2. So, I used a wireless bridge. That's how the situation stayed until I recently read M.C. Widerkrantz's FreeBSD 7.2 on the Lenovo Thinkpad X60s. It looked easy enough to get the wireless NIC running now that it was supported by the wpi driver. I had used freebsd-update to upgrade the 6.2 to 7.0, then 7.0 to 7.1, and finally 7.1 to 7.2. This is where the apparent madness began.

I couldn't find the if_wpi.ko or wpifw.ko kernel modules in /boot/kernel. However, on another system (named "r200a") which I believe had started life as a FreeBSD 7.0 box (but now also ran 7.2), I found both missing kernel modules. Taking a closer look, I simply counted the number of files on my laptop /boot/kernel and compared that list to the number of files on the other FreeBSD 7.2 system.

$ wc -l boot-kernel-neely.06dec09a.txt
545 boot-kernel-neely.06dec09a.txt
$ wc -l boot-kernel-r200a.06dec09a.txt
1135 boot-kernel-r200a.06dec09a.txt

Wow, that is a big difference. Apparently, the upgrade process from 6.2 to 7.x did not bring almost 600 files, now present on a system that started life running 7.x.

Since all I really cared about was getting wireless running on the laptop, I copied the missing kernel modules to /boot/kernel on the laptop. I added the following to /boot/loader.conf:

legal.intel_wpi.license_ack=1
if_wpi_load="YES"

After rebooting I was able to see the wpi0 device.

wpi0: mem 0xedf00000-0xedf00fff irq 17 at device 0.0 on pci3
wpi0: Ethernet address: [my MAC]
wpi0: [ITHREAD]
wpi0: timeout resetting Tx ring 1
wpi0: timeout resetting Tx ring 3
wpi0: timeout resetting Tx ring 4
wpi0: link state changed to UP

I think I will try upgrading the 7.2 system to 8.0 using freebsd-update, then compare the results to a third system that started life as 7.0, then upgraded from 7.2 to 8.0. If the /boot/kernel directories are still different, I might reinstall 8.0 on the laptop from media or the network.

Jumat, 27 November 2009

Celebrate FreeBSD 8.0 Release with Donation

With the announcement of FreeBSD 8.0, it seems like a good time to donate to the FreeBSD Foundation, a US 501(c)3 charity. The Foundation funds and manages projects, sponsors FreeBSD events, Developer Summits and provides travel grants to FreeBSD developers. It also provides and helps maintain computers and equipment that support FreeBSD development and improvements.

I just donated $100. Will anyone match me? Thank you!

Minggu, 27 September 2009

6th Issue of BSD Magazine

The 6th issue of BSD Magazine is available now. This edition has several great articles. I liked Jan Stedehouder's article on Triple booting Windows 7, Ubuntu 9.04 and PC-BSD 7.1, Christian Brueffer's article on FreeBSD Security Event Auditing, and the Questions and Answer Session of the BSD Certification Group Community with Dru Lavigne and Mikel King.

I've been working with the editor at BSD Magazine to publish my articles on keeping FreeBSD up-to-date, so I expect to see them in print within the next few months.

Kamis, 10 September 2009

Open Source Vulnerability Disclosure with FreeBSD

The purpose of this post is not to bash Microsoft, but I am going to point out why I prefer relying on open source platforms, especially for sensitive systems. One of the advantages of the open source model is that anyone can identify and evaluate changes. This is especially true of open source projects like FreeBSD. Let's look at a recent security advisory in ntpd to demonstrate what I mean.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

=============================================================================
FreeBSD-SA-09:11.ntpd Security Advisory
The FreeBSD Project

Topic: ntpd stack-based buffer-overflow vulnerability

Category: contrib
Module: ntpd
Announced: 2009-06-10
Credits: Chris Ries
Affects: All supported versions of FreeBSD.
Corrected: 2009-06-10 10:31:11 UTC (RELENG_7, 7.2-STABLE)
2009-06-10 10:31:11 UTC (RELENG_7_2, 7.2-RELEASE-p1)
2009-06-10 10:31:11 UTC (RELENG_7_1, 7.1-RELEASE-p6)
2009-06-10 10:31:11 UTC (RELENG_6, 6.4-STABLE)
2009-06-10 10:31:11 UTC (RELENG_6_4, 6.4-RELEASE-p5)
2009-06-10 10:31:11 UTC (RELENG_6_3, 6.3-RELEASE-p11)
CVE Name: CVE-2009-1252

For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit .

We very clearly see all affected FreeBSD versions which are not end of life.

I. Background

The ntpd(8) daemon is an implementation of the Network Time Protocol (NTP)
used to synchronize the time of a computer system to a reference time
source.

Autokey is a security model for authenticating Network Time Protocol
(NTP) servers to clients, using public key cryptography.

II. Problem Description

The ntpd(8) daemon is prone to a stack-based buffer-overflow when it is
configured to use the 'autokey' security model.

III. Impact

This issue could be exploited to execute arbitrary code in the context of
the service daemon, or crash the service daemon, causing denial-of-service
conditions.

The Background, Problem Description, and Impact are very clear.

IV. Workaround

Use IP based restrictions in ntpd(8) itself or in IP firewalls to
restrict which systems can send NTP packets to ntpd(8).

Note that systems will only be affected if they have the "autokey" option
set in /etc/ntp.conf; FreeBSD does not ship with a default ntp.conf file,
so will not be affected unless this option has been explicitly enabled by
the system administrator.

The workaround is NOT the "solution." Using an IP firewall does not make the FreeBSD "unaffected." The vulnerability is present with or without a firewall.

V. Solution

Perform one of the following:

1) Upgrade your vulnerable system to 6-STABLE, or 7-STABLE, or to the
RELENG_7_2, RELENG_7_1, RELENG_6_4, or RELENG_6_3 security branch
dated after the correction date.

2) To patch your present system:

The following patches have been verified to apply to FreeBSD 6.3, 6.4,
7.1, and 7.2 systems.

a) Download the relevant patch from the location below, and verify the
detached PGP signature using your PGP utility.

[FreeBSD 6.3]
# fetch http://security.FreeBSD.org/patches/SA-09:11/ntpd63.patch
# fetch http://security.FreeBSD.org/patches/SA-09:11/ntpd63.patch.asc

[FreeBSD 6.4 and 7.x]
# fetch http://security.FreeBSD.org/patches/SA-09:11/ntpd.patch
# fetch http://security.FreeBSD.org/patches/SA-09:11/ntpd.patch.asc

b) Execute the following commands as root:

# cd /usr/src
# patch < /path/to/patch
# cd /usr/src/usr.sbin/ntp/ntpd
# make obj && make depend && make && make install
# /etc/rc.d/ntpd restart

VI. Correction details

The following list contains the revision numbers of each file that was
corrected in FreeBSD.

CVS:

Branch Revision
Path
- -------------------------------------------------------------------------
RELENG_6
src/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.8.3
RELENG_6_4
src/UPDATING 1.416.2.40.2.9
src/sys/conf/newvers.sh 1.69.2.18.2.11
src/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.8.1.2.2
RELENG_6_3
src/UPDATING 1.416.2.37.2.16
src/sys/conf/newvers.sh 1.69.2.15.2.15
src/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.20.2
RELENG_7
src/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.18.3
RELENG_7_2
src/UPDATING 1.507.2.23.2.4
src/sys/conf/newvers.sh 1.72.2.11.2.5
src/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.18.2.2.1
RELENG_7_1
src/UPDATING 1.507.2.13.2.9
src/sys/conf/newvers.sh 1.72.2.9.2.10
src/contrib/ntp/ntpd/ntp_crypto.c 1.1.1.3.18.1.2.2
- -------------------------------------------------------------------------

Subversion:

Branch/path Revision
- -------------------------------------------------------------------------
stable/6/ r193893
releng/6.4/ r193893
releng/6.3/ r193893
stable/7/ r193893
releng/7.2/ r193893
releng/7.1/ r193893
- -------------------------------------------------------------------------

Administrators and users have multiple options to fix the system. Not listed is using FreeBSD Update to perform a binary update, which I personally prefer. Furthermore, using this information, we can determine exactly what the problem is.

First, we can download http://security.freebsd.org/patches/SA-09:11/ntpd.patch and see the patch itself in clear text.

Second, we can visit the http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/ntp/ntpd/ntp_crypto.c CVS tree for ntp_crypto.c to find the vulnerable code. We can then review changes between vulnerable and patched versions ourselves.

VII. References

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1252

The latest revision of this advisory is available at
http://security.FreeBSD.org/advisories/FreeBSD-SA-09:11.ntpd.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)

iEYEARECAAYFAkovjOwACgkQFdaIBMps37KRpwCfaQF9q8KhElv6LqgFv3DX2h9c
hbEAn2Q0X8Qv8r5OySnhlAw2pMxlxkXK
=Mh2u
-----END PGP SIGNATURE-----

Overall, I prefer this level of transparency. If you think that exposing this level of information is "bad for security," consider the following.

  1. First class intruders know about vulnerabilities before anyone else because they are constantly performing funded research to find them. They produce and test their own exploits.

  2. Second class intruders only need a hint to direct their resources towards identifying vulnerabilities. In other words, once they hear of a weakness in a protocol or service, they swing their attention to that target and develop exploits. They produce and test their own exploits.

  3. Third class intruders know how to reverse engineer vulnerabilities from binary patches released by the vendor. They produce and test their own exploits.

  4. Fourth class intruders use exploits leaked from higher classes to determine if systems are vulnerable. They test others' exploits.

  5. Administrators without Blue and Red teaming capabilities have to trust that the vendor is honest and competent. They can't test anything so they don't know if they are really vulnerable or not, pre- or post-patch.


So, keeping source code hidden only really hinders fourth class intruders to a certain degree, and it definitely hinders administrators who lack Blue and Red capabilities.

Selasa, 25 Agustus 2009

Draft Version of New Keeping FreeBSD Applications Up-To-Date

This is a follow-up to my recent post Draft Version of New Keeping FreeBSD Up-To-Date. I updated the draft Keeping FreeBSD Up-To-Date document at http://www.taosecurity.com/kfbutd7.pdf to include new sections on building a kernel and userland on one system and installing on another, and upgrading from one major version of FreeBSD to another via binary upgrades (e.g., 7.1 to 8.0 BETA3, since that just became available).

I have also published another draft document titled Keeping FreeBSD Applications Up-To-Date at http://www.taosecurity.com/kfbautd7.pdf. That is a follow-up to my 2004 article of the same name that use FreeBSD 5.x for the examples.

The new document includes the following.

Sections:
---------
Introduction
FreeBSD Handbook
A Common Linux Experience
Simple Package Installation on FreeBSD
Checking for Vulnerable Packages with Portaudit
FreeBSD Package Repositories
Updating Packages by Deletion and Addition
Introducing the FreeBSD Ports Tree
Updatng the FreeBSD Ports Tree
Installing Portupgrade
Updating Packages Using Portupgrade
Removing Packages
Identifying and Removing Leaf Packages
Preparing to Build and Install Packages Using the Ports Tree
Building and Installing Packages Using the Ports Tree: A Simple Example
Building and Installing Packages Using the Ports Tree: A More Complicated Example
Install Packages Built on One System to Another System
Installing Screen Using a Remote FreeBSD Ports Tree
Reading /usr/ports/UPDATING
My Common Package Update Process
Conclusion

As with the last document, this one reflects my personal system administration habits. For example, I use Portupgrade, although others might prefer Portmaster or Portmanager or something else.

If you'd like to read this draft and provide any comments here, I would appreciate them.

On a related note, I'd like to point to the 2006 article The FreeBSD Ports System by Michel Talon. I found it interesting because it takes a deep look at the ports tree and make comparison to Debian systems.

Sabtu, 22 Agustus 2009

Draft Version of New Keeping FreeBSD Up-To-Date

Four years ago I wrote an article titled Keeping FreeBSD Up-To-Date. The goal was to document various ways that a FreeBSD 5.2 system could be updated and upgraded using tools from that time, in an example-drive way that complemented the FreeBSD Handbook.

I decided to write an updated version that starts with a FreeBSD 7.1 RELEASE system and ends by running FreeBSD 7.2-STABLE. Sections include:

Sections:
---------
Introduction
FreeBSD Handbook
The Short Answer
Understanding FreeBSD Versions
Learning About Security Issues
Starting with the Installation
Installing Gnupg and Importing Keys
Installing Source Code
Installing CVSup
Applying Kernel Patches Manually
Applying Userland Patches Manually
Using CVSup to Apply Patches
Using Csup to Apply Patches
FreeBSD Update to Upgrade FreeBSD within Versions
STABLE: The End of the Line for a Single Version
What Comes Next?
Conclusion

Looking at the sections, I noted that it might be good to add a section on using FreeBSD Update to upgrade to 8.0, assuming you're starting with a non-7.2-STABLE system. From what I've read, that isn't possible? (Anyone know for sure?)

It would also be nice to publish the final version once 8.0 is RELEASEd so I could incorporate that.

If you'd like to read the document and provide feedback, I'd appreciate constructive comments. The draft is available as a .pdf at http://www.taosecurity.com/kfbutd7.pdf. Thank you.

Kamis, 20 Agustus 2009

Updating FreeBSD Using CVSup through HTTP Proxy

If you've used CVS before, you know that CVS doesn't play well with HTTP proxies. I was looking for a way to run cvsup on FreeBSD behind a proxy when I found a post on the FreeBSD China mailing list. It described using Proxychains with Desproxy to tunnel CVS over a SOCKS proxy through HTTP.

Here's how I followed the instructions in my lab environment.

First I installed Proxychains from the FreeBSD port. You can see my HTTP proxy is 172.16.2.1 port 3128.

freebsd7# setenv HTTP_PROXY http://172.16.2.1:3128
freebsd7# pkg_add -vr proxychains
...edited...
extract: Package name is proxychains-3.1
extract: CWD to /usr/local
extract: /usr/local/bin/proxychains
extract: /usr/local/bin/proxyresolv
extract: /usr/local/etc/proxychains.conf
extract: /usr/local/lib/libproxychains.so.3
extract: /usr/local/lib/libproxychains.so
extract: /usr/local/lib/libproxychains.la
extract: /usr/local/lib/libproxychains.a
extract: execute '/sbin/ldconfig -m /usr/local/lib'
extract: CWD to .
Running mtree for proxychains-3.1..
mtree -U -f +MTREE_DIRS -d -e -p /usr/local >/dev/null
Attempting to record package into /var/db/pkg/proxychains-3.1..
Package proxychains-3.1 registered in /var/db/pkg/proxychains-3.1


Next I installed Desproxy from source.

freebsd7# mkdir /usr/local/src
freebsd7# fetch http://downloads.sourceforge.net/project/desproxy/desproxy/desproxy-0.1.0-
pre3/desproxy-0.1.0-pre3.tar.gz
desproxy-0.1.0-pre3.tar.gz 100% of 51 kB 96 kBps
freebsd7# mkdir /usr/local/desproxy
freebsd7# tar -xzvf desproxy-0.1.0-pre3.tar.gz
x desproxy-0.1.0-pre3/
x desproxy-0.1.0-pre3/Makefile.in
x desproxy-0.1.0-pre3/AUTHORS
x desproxy-0.1.0-pre3/Changes
x desproxy-0.1.0-pre3/config.h.in
x desproxy-0.1.0-pre3/configure
x desproxy-0.1.0-pre3/configure.in
x desproxy-0.1.0-pre3/install-sh
x desproxy-0.1.0-pre3/doc/
x desproxy-0.1.0-pre3/doc/config-en.html
x desproxy-0.1.0-pre3/doc/manual-en.html
x desproxy-0.1.0-pre3/src/
x desproxy-0.1.0-pre3/src/Makefile.in
x desproxy-0.1.0-pre3/src/desproxy-dns.c
x desproxy-0.1.0-pre3/src/desproxy-inetd.c
x desproxy-0.1.0-pre3/src/util.c
x desproxy-0.1.0-pre3/src/desproxy.c
x desproxy-0.1.0-pre3/src/desproxy.h
x desproxy-0.1.0-pre3/src/socket2socket.c
x desproxy-0.1.0-pre3/src/util.h
x desproxy-0.1.0-pre3/src/desproxy-socksserver.c
x desproxy-0.1.0-pre3/INSTALL
x desproxy-0.1.0-pre3/COPYING
freebsd7# cd desproxy-0.1.0-pre3
freebsd7# ./configure --prefix=/usr/local/desproxy
checking for gcc... gcc
checking for C compiler default output... a.out
...edited...
freebsd7# make install
Using binary dir: /usr/local/desproxy/bin
Using locale dir: /usr/local/desproxy/share/locale
Making directories...
Copying binaries...
desproxy installed
desproxy-inetd installed
desproxy-dns installed
desproxy-socksserver installed
socket2socket installed

*************************************
* This version lacks locale support *
* locales won't be installed *
*************************************

*******************
* Installation OK *
*******************

Before I could start desproxy-socksserver, I needed to edit my Squid proxy configuration. Here's where it gets tricky. If I can control my proxy, can't I figure another way around it? Stay with me for now. I made two changes. I added a variable for port 5999 for CVS:

acl CVS_ports port 5999

Next I added port 5999 as a "safe port":

acl Safe_ports port 5999 # CVS added by RMB 20 Aug 09

Finally I modified what ports were allowed the CONNECT method. By default only 443 is allowed.

# Deny CONNECT to other than CVS ports
http_access allow CONNECT CVS_ports
http_access deny CONNECT !SSL_ports

I thought you might be able to get CVSup to point to port 443 using the -p option, but if you try that you get an error:

Reserved port 443 not permitted

I wonder if this could be removed from the source code?

Assuming you could get CVSup to talk port 443, you could have it point to a host on the Internet under your control. That host could listen on port 443, then forward what it receives to the CVS server using Netcat. I think this would work. I found the following in cvsup-snap-16.1h/client/src/Main.m3

PROCEDURE CheckPort(port: INTEGER) =
BEGIN
IF port = IP.NullPort
OR NOT (FIRST(IP.Port) <= port AND port <= LAST(IP.Port)) THEN
ErrMsg.Fatal("Invalid port " & Fmt.Int(port));
END;
IF port < 1024 THEN
ErrMsg.Fatal("Reserved port " & Fmt.Int(port) & " not permitted");
END;
END CheckPort;

I think if I removed the second check, for "Reserved port", that would remove my problem. To make things easier I just changed 1024 to 10.

To install the modified cvsup-without-gui, I did a 'make fetch' and 'make extract', modified the source, and then did 'make install'.

On a remote host I can run the following using the redir app:

# redir --laddr=[MY_BOUNCE_BOX] --lport=443 --caddr=[CVS server IP] --cport=5999

Then I set the IP in my supfile to be MY_BOUNCE_BOX.

If you can set up this sort of redirection, you can remove the proxy changes outlined earlier.

In the following case, let's assume you can make the necessary proxy changes so you don't have to bounce through a remote host listening for port 443.

Now start desproxy-socksserver. Basically port 1080 is listening on the localhost, and it will forward what it receives to port 3128 (Squid) on the proxy server.

freebsd7# /usr/local/desproxy/bin/desproxy-socksserver 172.16.2.1 3128 1080

-----------------------------------
desproxy-socksserver 0.1.0-pre3

(C) 2003 Miguelanxo Otero Salgueiro
-----------------------------------

TCP port 1080 Bound & Listening
Press to Quit

Now configure Proxychains. Here is my configuration file.

freebsd7# grep -v \# proxychains.conf

random_chain

chain_len = 1

tcp_read_time_out 15000
tcp_connect_time_out 8000

[ProxyList]
socks5 127.0.0.1 1080

There is another problem here. If you can't resolve DNS inside your environment, this will fail. There is a 'proxy_dns' option in Proxychains, but I got an error when using it:

|DNS-response|: freebsd7.localdomain is not exist
|DNS-request| cvsup7.FreeBSD.org
|R-chain|-<>-172.16.134.128:1080-<><>-4.2.2.2:53-<--timeout
|DNS-response|: cvsup7.FreeBSD.org is not exist
Unknown host "cvsup7.FreeBSD.org"

One way around this is to replace cvsup7.FreeBSD.org, or whatever you want to use, with the IP address of the CVS server. Start desproxy-socksserver.

freebsd7# /usr/local/desproxy/bin/desproxy-socksserver 172.16.2.1 3128 1080

-----------------------------------
desproxy-socksserver 0.1.0-pre3

(C) 2003 Miguelanxo Otero Salgueiro
-----------------------------------

TCP port 1080 Bound & Listening
Press to Quit

Connection request from 172.16.134.128, port 63950
Connection #0: bidirectional connection stablished

Connection request from 172.16.134.128, port 53812
Connection #1: bidirectional connection stablished

Connection #0: end of connection
Connection #1: end of connection

Start proxychains and tell it to run cvsup:

freebsd7# proxychains cvsup -g -L 2 /usr/local/etc/freebsd7-example.supfile
ProxyChains-3.1 (http://proxychains.sf.net)
Parsing supfile "/usr/local/etc/freebsd7-example.supfile"
Connecting to cvsup4.FreeBSD.org
|R-chain|-<>-172.16.134.128:1080-<><>-204.152.184.73:5999-<><>-OK
|R-chain|-<>-172.16.134.128:1080-<><>-204.152.184.73:5999-<><>-OK
Connected to cvsup4.FreeBSD.org
Rejected by server: Access limit exceeded; try again later
Will retry at 17:45:22

That's not cool. That is actually a CVS server error. Let's try new CVSup host in the supfile.

freebsd7# proxychains cvsup -g -L 2 /usr/local/etc/freebsd7-example.supfile
ProxyChains-3.1 (http://proxychains.sf.net)
Parsing supfile "/usr/local/etc/freebsd7-example.supfile"
Connecting to cvsup7.FreeBSD.org
|R-chain|-<>-172.16.134.128:1080-<><>-64.215.216.140:5999-<><>-OK
|R-chain|-<>-172.16.134.128:1080-<><>-64.215.216.140:5999-<><>-OK
Connected to cvsup7.FreeBSD.org
Server software version: SNAP_16_1h
Negotiating file attribute support
Exchanging collection information
Establishing multiplexed-mode data connection
Running
Updating collection src-all/cvs

So, it worked. I would be interested in knowing if anyone has other methods to get CVSup to work through a HTTP proxy? Most people seem to use SSH tunnels, but what if that is not an option?

Update:

It turns out you do NOT need to use desproxy-socksserver. For example, use the following proxychains.conf:

freebsd7# grep -v \# /usr/local/etc/proxychains.conf

random_chain

chain_len = 1

proxy_dns

tcp_read_time_out 15000
tcp_connect_time_out 10000

[ProxyList]
http 172.16.2.1 3128

Notice the use of 'http' here instead of 'socks5'. Also, the IP address here is the IP address of the Squid proxy server, whereas the earlier examples pointed to the desproxy-socksserver.

Again I bounce off an Internet host that will send traffic sent to port 443 (to get through the default CONNECT and port settings on Squid):

# redir --laddr=[MY_BOUNCE_BOX] --lport=443 --caddr=[CVS server IP] --cport=5999

Then you can run proxychains by itself.
freebsd7# proxychains cvsup -p 443 -g -L 2 /usr/local/etc/freebsd7-example.supfile
ProxyChains-3.1 (http://proxychains.sf.net)
Parsing supfile "/usr/local/etc/freebsd7-example.supfile"
|DNS-response|: freebsd7.localdomain is not exist
Connecting to MY_BOUNCE_BOX
|R-chain|-<>-172.16.2.1:3128-<><>-MY_BOUNCE_BOX:443-<><>-OK
|R-chain|-<>-172.16.2.1:3128-<><>-MY_BOUNCE_BOX:443-<><>-OK
Connected to MY_BOUNCE_BOX
Server software version: SNAP_16_1h
Negotiating file attribute support
Exchanging collection information
Establishing multiplexed-mode data connection
Running
Updating collection src-all/cvs
Checkout src/COPYRIGHT
Checkout src/LOCKS
...truncated...

If you look at a few packets you can see the setup of the connection.

14:48:04.461432 IP 172.16.134.128.65097 > 172.16.2.1.3128: P 1:39(38) ack 1 win 65535
0x0000: 4500 004e 0ec9 4000 4006 4b3f ac10 8680 E..N..@.@.K?....
0x0010: ac10 0201 fe49 0c38 f690 a51d 2952 c059 .....I.8....)R.Y
0x0020: 5018 ffff 3942 0000 434f 4e4e 4543 5420 P...9B..CONNECT.
0x0030: 0000 0000 0000 0000 0000 0000 003a 3434 MY_BOUNCE_BOX:44
0x0040: 3320 4854 5450 2f31 2e30 0d0a 0d0a 3.HTTP/1.0....
14:48:04.461991 IP 172.16.2.1.3128 > 172.16.134.128.65097: . ack 39 win 64240
0x0000: 4500 0028 d1a2 0000 8006 888b ac10 0201 E..(............
0x0010: ac10 8680 0c38 fe49 2952 c059 f690 a543 .....8.I)R.Y...C
0x0020: 5010 faf0 443f 0000 P...D?..
14:48:04.535724 IP 172.16.2.1.3128 > 172.16.134.128.65097: P 1:40(39) ack 39 win 64240
0x0000: 4500 004f d1a3 0000 8006 8863 ac10 0201 E..O.......c....
0x0010: ac10 8680 0c38 fe49 2952 c059 f690 a543 .....8.I)R.Y...C
0x0020: 5018 faf0 3a58 0000 4854 5450 2f31 2e30 P...:X..HTTP/1.0
0x0030: 2032 3030 2043 6f6e 6e65 6374 696f 6e20 .200.Connection.
0x0040: 6573 7461 626c 6973 6865 640d 0a0d 0a established....
...edited...
14:48:04.639664 IP 172.16.134.128.65097 > 172.16.2.1.3128: . ack 40 win 65535
0x0000: 4500 0028 0ece 4000 4006 4b60 ac10 8680 E..(..@.@.K`....
0x0010: ac10 0201 fe49 0c38 f690 a543 2952 c080 .....I.8...C)R..
0x0020: 5010 ffff 3f09 0000 0000 0000 0000 P...?.........
14:48:04.837943 IP 172.16.2.1.3128 > 172.16.134.128.65097: P 40:78(38) ack 39 win 64240
0x0000: 4500 004e d1a7 0000 8006 8860 ac10 0201 E..N.......`....
0x0010: ac10 8680 0c38 fe49 2952 c080 f690 a543 .....8.I)R.....C
0x0020: 5018 faf0 6a4f 0000 4f4b 2031 3720 3020 P...jO..OK.17.0.
0x0030: 534e 4150 5f31 365f 3168 2043 5653 7570 SNAP_16_1h.CVSup
0x0040: 2073 6572 7665 7220 7265 6164 790a .server.ready.
14:48:04.839209 IP 172.16.134.128.65097 > 172.16.2.1.3128: P 39:61(22) ack 78 win 65535
0x0000: 4500 003e 0ecf 4000 4006 4b49 ac10 8680 E..>..@.@.KI....
0x0010: ac10 0201 fe49 0c38 f690 a543 2952 c0a6 .....I.8...C)R..
0x0020: 5018 ffff 4731 0000 5052 4f54 4f20 3137 P...G1..PROTO.17
0x0030: 2030 2053 4e41 505f 3136 5f31 680a .0.SNAP_16_1h.

So, you can tunnel CVS through HTTP using proxychains, as long as you bounce off a remote host that listens on port 443. That assumes you have to get around proxy restrictions that only allow CONNECT to port 443.

Three Free Issues of BSD Magazine in .pdf Format

Karolina at BSD Magazine wanted me to let you know that she has posted three free .pdf issues online. The three cover FreeBSD, OpenBSD, and NetBSD. Apparently BSD Magazine has survived a publishing scare and will continue for the foreseeable future. I may also have an article for FreeBSD out soon.

Senin, 13 Juli 2009

FreeBSD Pf and Tftp-proxy

Several IP-enabled devices in the lab use TFTP to retrieve configuration files from various locations on the Internet. This pains me. You can probably imagine what these devices are. Unfortunately I don't control how these devices work.

I run Sguil at my lab gateway to the Internet. I watch traffic right before the gateway, before it is NAT'd. I really don't care what's on the other side. I mostly care what is leaving the network, so I concentrate my NSM activities there.

I noticed one of these TFTP-enabled devices trying to retrieve a file repeatedly. I looked closer at the traffic (thanks to Sguil I keep a record of traffic leaving for the Internet) and noticed I never saw any replies. Simultaneously I received an email from tech support for this device. They told me to unplug all Internet devices from my cable modem and plug the troublesome device into the cable modem overnight (!) My answer to that: "heck no."

I decided to run an experiment with a TFTP client inside the lab and a TFTP server on the Internet. By watching traffic on the internal and external sides of the gateway, I could see TFTP requests making it to the TFTP server on the Internet, and TFTP replies coming from the server back to the gateway. However, the TFTP replies never appeared on the internal side of the gateway.

I did some research and determined that FreeBSD's Pf firewall can't handle TFTP traffic by default. Here is why:

18:13:31.205435 IP my.public.ip.addr.64212 > tftp.server.public.ip.69: 17 RRQ "test.txt" octet
18:13:31.282363 IP tftp.server.public.ip.51186 > my.public.ip.addr.64212: UDP, length 29
18:13:31.284161 IP my.public.ip.addr.57880 > tftp.server.public.ip.51186: UDP, length 4

You see the TFTP request to port 69 UDP. The reply, however, comes from port 51186 UDP to port 64212 UDP. Pf doesn't automatically know that packet 2 is associated with the TFTP request in packet 1.

Fortunately, FreeBSD and other operating systems ship with tftp-proxy(8). I tried following the example in the man page, but I ended up adding the following to the configuration file /etc/pf.conf. $local192 is the LAN from which I expect to see TFTP requests.

no nat on $ext_if to port tftp

rdr-anchor "tftp-proxy/*"

rdr on $int_if proto udp from $local192 to port tftp -> \
$int_if port 6969

anchor "tftp-proxy/*"

I added the following to /etc/inetd.conf.

acmsoda dgram udp wait root /usr/libexec/tftp-proxy tftp-proxy -v

acmsoda is the name in /etc/services for port 6969.

I had to enable /etc/inetd in /etc/rc.conf.

inetd_enable="YES"
inetd_flags="-wW -C 60 -a 172.16.2.1"

Without the -a flag, tftp-proxy would be listening on all interfaces, and I don't want that.

Now I was ready to reload Pf and restart /etc/inetd.conf.

r200a:/root# pfctl -Fa -f /etc/pf.conf

r200a:/root# /etc/rc.d/inetd restart

I checked to ensure port 6969 UDP was listening.

r200a:/root# sockstat -4 | grep 6969
root inetd 161 5 udp4 172.16.2.1:6969 *:*

Now I was able to retrieve my test file via TFTP.

tftp> get test.txt
getting from tftp.server.public.ip:test.txt to test.txt [octet]
sent RRQ
received DATA
Received 25 bytes in 0.1 seconds [2000 bits/sec]

I wanted to note that the man page recommended this addition to inetd.conf:

inetd(8) must be configured to spawn the proxy on the port that packets
are being forwarded to by pf(4). An example inetd.conf(5) entry follows:

127.0.0.1:6969 dgram udp wait root \
/usr/libexec/tftp-proxy tftp-proxy

That didn't work for me; I saw this error in /var/log/messages.

Jul 13 17:11:56 r200a inetd[99738]: 127.0.0.1:6969/udp: unknown service

By specifying the port only and using -a to bind inetd where I needed it, I avoided this error. There's probably another way around this though.

The final step will be seeing this TFTP-enabled device updating itself during the next 24 hours.


Richard Bejtlich is teaching new classes in Las Vegas in 2009. Late Las Vegas registration ends 22 July.

Senin, 23 Februari 2009

VirtualBSD: FreeBSD 7.1 Desktop in a VM

Want to try FreeBSD 7.1 in a comfortable, graphical desktop, via a VMWare VM? If your answer is yes, visit www.virtualbsd.info and download their 1.5 GB VM. I tried it last night and got it working with VMware 1.0.8 by making the following adjustments:

Edit VirtualBSD.vmx to say

#virtualHW.version = "6"
virtualHW.version = "4"

and VirtualBSD.vmdk to say

#ddb.virtualHWVersion = "6"
ddb.virtualHWVersion = "4"

and you will be able to use the VM on VMware Server 1.0.8.


Richard Bejtlich is teaching new classes in Europe in 2009. Register by 1 Mar for the best rates.

Selasa, 03 Februari 2009

Notes on Installing Sguil Using FreeBSD 7.1 Packages

It's been a while since I've looked at the Sguil ports for FreeBSD, so I decided to see how they work.

In this post I will talk about installing a Sguil sensor and server on a single FreeBSD 7.1 test VM using packages shipped with FreeBSD 7.1.

To start with the system had no packages installed.

After running pkg_add -vr sguil-sensor, I watched what was added to the system. I'm only going to document that which I found interesting.

The sguil-sensor-0.7.0_2 package installed the following into /usr/local.

x bin/sguil-sensor/log_packets.sh
x bin/sguil-sensor/example_agent.tcl
x bin/sguil-sensor/pcap_agent.tcl
x bin/sguil-sensor/snort_agent.tcl
x etc/sguil-sensor/example_agent.conf-sample
x etc/sguil-sensor/pcap_agent.conf-sample
x etc/sguil-sensor/snort_agent.conf-sample
x etc/sguil-sensor/log_packets.conf-sample
x share/doc/sguil-sensor <- multiple files, omitted here
x etc/rc.d/example_agent
x etc/rc.d/pcap_agent
x etc/rc.d/snort_agent

Note that you have to copy

pcap_agent.conf-sample
log_packets.conf-sample
snort_agent.conf-sample

to

pcap_agent.conf
log_packets.conf
snort_agent.conf

and edit each, prior to starting

pcap_agent.tcl
log_packets.sh
snort_agent.tcl

via

rc.d/pcap_agent
cron
rc.d/snort_agent

Also, as noted in the configuration options, PADS and SANCP are not installed by default, so the package doesn't include them:

===> The following configuration options are available for sguil-sensor-0.7.0_2:
SANCP=off (default) "Include sancp sensor"
PADS=off (default) "Include pads sensor"
===> Use 'make config' to modify these settings


The snort-2.8.2.1_1 package installed the following.

x man/man8/snort.8.gz
x bin/snort
x etc/snort/classification.config-sample
x etc/snort/gen-msg.map-sample
x etc/snort/reference.config-sample
x etc/snort/sid-msg.map-sample
x etc/snort/snort.conf-sample
x etc/snort/threshold.conf-sample
x etc/snort/unicode.map-sample
x src/snort_dynamicsrc/bitop.h
x src/snort_dynamicsrc/debug.h
x src/snort_dynamicsrc/pcap_pkthdr32.h
x src/snort_dynamicsrc/preprocids.h
x src/snort_dynamicsrc/profiler.h
x src/snort_dynamicsrc/sf_dynamic_common.h
x src/snort_dynamicsrc/sf_dynamic_meta.h
x src/snort_dynamicsrc/sf_dynamic_preproc_lib.c
x src/snort_dynamicsrc/sf_dynamic_preproc_lib.h
x src/snort_dynamicsrc/sf_dynamic_preprocessor.h
x src/snort_dynamicsrc/sf_snort_packet.h
x src/snort_dynamicsrc/sf_snort_plugin_api.h
x src/snort_dynamicsrc/sfghash.h
x src/snort_dynamicsrc/sfhashfcn.h
x src/snort_dynamicsrc/sfsnort_dynamic_detection_lib.c
x src/snort_dynamicsrc/sfsnort_dynamic_detection_lib.h
x src/snort_dynamicsrc/str_search.h
x src/snort_dynamicsrc/stream_api.h
x lib/snort/dynamicengine/libsf_engine.so
x lib/snort/dynamicengine/libsf_engine.so.0
x lib/snort/dynamicengine/libsf_engine.la
x lib/snort/dynamicengine/libsf_engine.a
x lib/snort/dynamicrules/lib_sfdynamic_example_rule.so
x lib/snort/dynamicrules/lib_sfdynamic_example_rule.so.0
x lib/snort/dynamicrules/lib_sfdynamic_example_rule.la
x lib/snort/dynamicrules/lib_sfdynamic_example_rule.a
x lib/snort/dynamicpreprocessor/lib_sfdynamic_preprocessor_example.a
x lib/snort/dynamicpreprocessor/lib_sfdynamic_preprocessor_example.la
x lib/snort/dynamicpreprocessor/lib_sfdynamic_preprocessor_example.so
x lib/snort/dynamicpreprocessor/lib_sfdynamic_preprocessor_example.so.0
x lib/snort/dynamicpreprocessor/libsf_dcerpc_preproc.a
x lib/snort/dynamicpreprocessor/libsf_dcerpc_preproc.la
x lib/snort/dynamicpreprocessor/libsf_dcerpc_preproc.so
x lib/snort/dynamicpreprocessor/libsf_dcerpc_preproc.so.0
x lib/snort/dynamicpreprocessor/libsf_dns_preproc.a
x lib/snort/dynamicpreprocessor/libsf_dns_preproc.la
x lib/snort/dynamicpreprocessor/libsf_dns_preproc.so
x lib/snort/dynamicpreprocessor/libsf_dns_preproc.so.0
x lib/snort/dynamicpreprocessor/libsf_ftptelnet_preproc.a
x lib/snort/dynamicpreprocessor/libsf_ftptelnet_preproc.la
x lib/snort/dynamicpreprocessor/libsf_ftptelnet_preproc.so
x lib/snort/dynamicpreprocessor/libsf_ftptelnet_preproc.so.0
x lib/snort/dynamicpreprocessor/libsf_smtp_preproc.a
x lib/snort/dynamicpreprocessor/libsf_smtp_preproc.la
x lib/snort/dynamicpreprocessor/libsf_smtp_preproc.so
x lib/snort/dynamicpreprocessor/libsf_smtp_preproc.so.0
x lib/snort/dynamicpreprocessor/libsf_ssh_preproc.a
x lib/snort/dynamicpreprocessor/libsf_ssh_preproc.la
x lib/snort/dynamicpreprocessor/libsf_ssh_preproc.so
x lib/snort/dynamicpreprocessor/libsf_ssh_preproc.so.0
x lib/snort/dynamicpreprocessor/libsf_ssl_preproc.a
x lib/snort/dynamicpreprocessor/libsf_ssl_preproc.la
x lib/snort/dynamicpreprocessor/libsf_ssl_preproc.so
x lib/snort/dynamicpreprocessor/libsf_ssl_preproc.so.0
x share/examples/snort/classification.config-sample <- copied to classification.config
x share/examples/snort/create_db2
x share/examples/snort/create_mssql
x share/examples/snort/create_mysql
x share/examples/snort/create_oracle.sql
x share/examples/snort/create_postgresql
x share/examples/snort/gen-msg.map-sample <- copied to gen-msg.map
x share/examples/snort/reference.config-sample <- copied to reference.config
x share/examples/snort/sid-msg.map-sample <- copied to sid-msg.map
x share/examples/snort/snort.conf-sample <- copied to snort.conf
x share/examples/snort/threshold.conf-sample <- copied to threshold.conf
x share/examples/snort/unicode.map-sample <- copied to unicode.map
x share/doc/snort <- multiple files, omitted here
x etc/rc.d/snort

These are the configuration options for Snort.

===> The following configuration options are available for snort-2.8.2.2_2:
DYNAMIC=on (default) "Enable dynamic plugin support"
FLEXRESP=off (default) "Flexible response to events"
FLEXRESP2=off (default) "Flexible response to events (version 2)"
MYSQL=off (default) "Enable MySQL support"
ODBC=off (default) "Enable ODBC support"
POSTGRESQL=off (default) "Enable PostgreSQL support"
PRELUDE=off (default) "Enable Prelude NIDS integration"
PERPROFILE=off (default) "Enable Performance Profiling"
SNORTSAM=off (default) "Enable output plugin to SnortSam"
===> Use 'make config' to modify these settings

I'm glad dynamic plugin support is enabled, but disappointed to see performance profiling disabled. The --enable-timestats option isn't available via the port at all, apparently.

The FreeBSD port/package can't ship with rules, so you need to download your own rules from Sourcefire, along with any Emerging Threats rules you might want to enable. You then need to edit the snort.conf file to account for your HOME_NET and rule preferences.

The barnyard-sguil-0.2.0_5 package installed the following.

x bin/barnyard
x etc/barnyard.conf-sample <- copied to etc/barnyard.conf by the port
x share/doc/barnyard <- multiple files, omitted here
x etc/rc.d/barnyard

I noticed the barnyard.conf only contained

output sguil

Usually we need something like this:

output sguil: sensor_name sensornamegoeshere

When done the following packages are installed:

tao# pkg_info
barnyard-sguil-0.2.0_5 An output system for Snort (patched for sguil)
mysql-client-5.0.67_1 Multithreaded SQL database (client)
pcre-7.7_1 Perl Compatible Regular Expressions library
sguil-sensor-0.7.0_2 Sguil is a network security monitoring program
snort-2.8.2.1_1 Lightweight network intrusion detection system
tcl-8.4.19,1 Tool Command Language
tclX-8.4_1 Extended TCL
tcltls-1.6 SSL extensions for TCL; dynamicly loadable

Because I want this test system to host the Sguil server too, I decided to move to that phase of the testing.

Before add the sguil-server package, I need to install MySQL server 5.0. This is due to the configuration options:

===> The following configuration options are available for sguil-server-0.7.0_2:
MYSQL50=off (default) "Install mysql50 server"
===> Use 'make config' to modify these settings

I assume this is the case because the port maintainer prefers running MySQL on one system and the Sguil server on another.

Therefore, I install MySQL server 5.0 using pkg_add -vr mysql50-server.

Next I stopped MySQL via /usr/local/etc/rc.d/mysql stop. This is critical for the next step in the process.

I installed sguil-server next via pkg_add -vr sguil-server.

The sguil-server-0.7.0_2 package installed the following.

x bin/archive_sguildb.tcl
x bin/incident_report.tcl
x bin/sguild
x etc/sguil-server/autocat.conf-sample
x etc/sguil-server/sguild.access-sample
x etc/sguil-server/sguild.conf-sample
x etc/sguil-server/sguild.email-sample
x etc/sguil-server/sguild.queries-sample
x etc/sguil-server/sguild.reports-sample
x etc/sguil-server/sguild.users-sample
x lib/sguil-server/SguildAccess.tcl
x lib/sguil-server/SguildAutoCat.tcl
x lib/sguil-server/SguildClientCmdRcvd.tcl
x lib/sguil-server/SguildConnect.tcl
x lib/sguil-server/SguildCreateDB.tcl
x lib/sguil-server/SguildEmailEvent.tcl
x lib/sguil-server/SguildEvent.tcl
x lib/sguil-server/SguildGenericDB.tcl
x lib/sguil-server/SguildGenericEvent.tcl
x lib/sguil-server/SguildHealthChecks.tcl
x lib/sguil-server/SguildLoaderd.tcl
x lib/sguil-server/SguildMysqlMerge.tcl
x lib/sguil-server/SguildPadsLib.tcl
x lib/sguil-server/SguildQueryd.tcl
x lib/sguil-server/SguildReportBuilder.tcl
x lib/sguil-server/SguildSendComms.tcl
x lib/sguil-server/SguildSensorAgentComms.tcl
x lib/sguil-server/SguildSensorCmdRcvd.tcl
x lib/sguil-server/SguildTranscript.tcl
x lib/sguil-server/SguildUtils.tcl
x share/sguil-server/create_ruledb.sql
x share/sguil-server/create_sguildb.sql
x share/sguil-server/migrate_event.tcl
x share/sguil-server/migrate_sancp.tcl
x share/sguil-server/sancp_cleanup.tcl
x share/sguil-server/update_0.7.tcl
x share/sguil-server/update_sguildb_v5-v6.sql
x share/sguil-server/update_sguildb_v6-v7.sql
x share/sguil-server/update_sguildb_v7-v8.sql
x share/sguil-server/update_sguildb_v8-v9.sql
x share/sguil-server/update_sguildb_v9-v10.sql
x share/sguil-server/update_sguildb_v10-v11.sql
x share/sguil-server/update_sguildb_v11-v12.sql
x share/doc/sguil-server/CHANGES
x share/doc/sguil-server/FAQ
x share/doc/sguil-server/INSTALL
x share/doc/sguil-server/INSTALL.openbsd
x share/doc/sguil-server/LICENSE.QPL
x share/doc/sguil-server/OPENSSL.README
x share/doc/sguil-server/TODO
x share/doc/sguil-server/UPGRADE
x share/doc/sguil-server/USAGE
x share/doc/sguil-server/sguildb.dia
x etc/rc.d/sguild

What came next was very interesting. The port maintainer created a script to help set up the server. I'll show relevant excerpts.

Running pre-install for sguil-server-0.7.0_2..
This sguild install script creates a "turnkey" install
of sguild, including configuing the database and conf files
and user accounts so that sguild can be started immediately.

You may have already done all this (especially if this is an upgrade)
and may not be interested in iterating through cert creation and
everything else that the script does.

This portion of the script creates user and group accounts named "sguil".
Would you like to opt out of this portion of the install script
n
==> Pre-installation configuration of sguil-server-0.7.0_2
User 'sguil' create successfully.
sguil:*:1002:1002::0:0:User &:/home/sguil:/usr/sbin/nologin
...edited...
Running post-install for sguil-server-0.7.0_2..
This sguild install script creates a "turnkey" install
of sguild, including configuing the database and conf files
and user accounts so that sguild can be started immediately.

You may have already done all this (especially if this is an upgrade)
and may not be interested in iterating through cert creation and
everything else that the script does.

Would you like to opt out of the entire install script
and configure sguild manually yourself?
n
There are a few things that need to be done to complete the install.
First, you need to create certs so that the ssl connections between server and
sensors will work, you need to create the database, the account to access it and
the tables for the database and you need to create the directories where all the
data will be stored. (You will also need to edit the conf files for your setup.)


If you haven't already done this, I can do it for you now.
Would you like to create certs now? (y for yes, n for no)
y
Creating /usr/local/etc/sguil-server/certs ....
First we need to create a password-protected CA cert.

(The Common Name should be the FQHN of your squil server.)
Generating a 1024 bit RSA private key
.....++++++
.......................................++++++
writing new private key to 'privkey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:VA
Locality Name (eg, city) []:M
Organization Name (eg, company) [Internet Widgits Pty Ltd]:T
Organizational Unit Name (eg, section) []:O
Common Name (eg, YOUR name) []:R
Email Address []:o

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:sguil
An optional company name []:
Now we need to create the actual certificate for your server.
Signature ok
subject=/C=US/ST=VA/L=M/O=T/OU=O/CN=R/emailAddress=o
Getting CA Private Key
Enter pass phrase for privkey.pem:
Finally, we need to move the certs to the '/usr/local/etc/sguil-server/certs}' directory
and clean up the port directory as well.
mv: rename /a/ports/security/sguil-server/sguild.key to /usr/local/etc/sguil-server/certs/sguild.key:
No such file or directory
mv: rename /a/ports/security/sguil-server/sguild.pem to /usr/local/etc/sguil-server/certs/sguild.pem:
No such file or directory
rm: /a/ports/security/sguil-server/CA.pem: No such file or directory
rm: /a/ports/security/sguil-server/privkey.pem: No such file or directory
rm: /a/ports/security/sguil-server/sguild.req: No such file or directory
rm: /a/ports/security/sguil-server/file.sr1: No such file or directory

Those errors happen because the script was written with the assumption that it would be run from a ports installation, not a package installation. I emailed the ports maintainer to see if the problem can be fixed.

Is the installation of mysql brand new and unaltered?
By default, when mysql is installed, it creates five accounts.
None of those accounts are protected by passwords. That needs to be corrected.
The five accounts are:
root@localhost
root@127.0.0.1
root@tao.taosecurity.com
@localhost
@tao.taosecurity.com
I can remove all of the accounts except root@localhost (highly recommended)
and I can set the password for the root@localhost account. (If you get an error
don't worry about it. The account may not have been created to begin with.
Would you like me to do that now?
y
Enabling mysql in /etc/rc.conf and starting the server.....
It appears that mysql is already enabled!

The mysql pid is ....
Starting mysql.
Deleting users from mysql......
All done deleting.......
What would you like root@localhost's password to be?
root
Would you like to bind mysql to localhost so it only listens on that address?

y
The mysql pid is 1694.....
Stopping mysql.
Waiting for PIDS: 1694.
Starting mysql.
Would you like to create the database to store all nsm data?

y
NOTE: If you're upgrading, you do NOT want to do this! You want to upgrade.
./+INSTALL: cannot open /work/a/ports/security/sguil-server/work/sguil-0.7.0/server/sql_scripts/create_sguildb.sql:
No such file or directory

This error is similar to the previous error. I also emailed the port maintainer.

Would you like to create a user "sguild@localhost" for database access?

y
Please enter the password that you want to use for the sguild account.

sguil
Creating account for sguild with access to sguildb.....
Would you like to create the data directory and all its subdirectories?

y
What do you want the name of the main directory to be?
(Be sure to include the full path to the directory - e.g. /var/nsm)
/var/nsm
The main directory will be named '/var/nsm'.
Creating /var/nsm ....
Creating /var/nsm/archives ....
Creating /var/nsm/rules ....
Creating /var/nsm/load ....
Would you like to enable sguild in /etc/rc.conf?

y
iWriting to /etc/rc.conf....

If the sguild.conf file does not exist, I will create and edit it now.

Preparing to edit the sguild.conf file......
You still need to review all the conf files and configure sguil
per your desired setup before starting sguild. Refer to the port docs in
/usr/local/share/doc/sguil-server before proceeding.

Right now, all the conf files except sguild.conf are set to the defaults.
...edited...

That ends the need for user input. The final step advises the user on other required changes.

***********************************
* !!!!!!!!!!! WARNING !!!!!!!!!!! *
***********************************

PLEASE NOTE: If you are upgrading from a previous version,
read the UPGRADE doc (in /usr/local/share/doc/sguil-server) before proceeding!!!
Some noteworthy changes in version 0.7.0:
SSL is now required for server, sensor and client.
The sguild.conf and sguild.email files have changed.
You MUST run the upgrade_0.7.tcl script to clean up and
prepare the database before running the new version. BE SURE
TO BACK UP YOUR DATABASE BEFORE PROCEEDING!!!

If you had existing config files in /usr/local/etc/sguil-server
they were not overwritten. If this is a first time install, you
must copy the sample files to the corresponding conf file and
edit the various config files for your site. See the INSTALL
doc in /usr/local/share/doc/sguil-server for details. If this is an upgrade, replace
your existing conf file with the new one and edit accordingly.

The sql scripts for creating database tables were placed in
the /usr/local/share/sguil-server/ directory. PLEASE
NOTE: LOG_DIR is not set by this install. You MUST create the
correct LOG_DIRS and put a copy of the snort rules you use in
LOG_DIR/rules.

The sguild, archive_sguildb.tcl and incident_report.tcl scripts
were placed in /usr/local/bin/. The incident_report.tcl
script is from the contrib section. There is no documentation
and the script's variables must be edited before it is used.

A startup script, named sguild.sh was installed in
/usr/local/etc/rc.d/. To enable it, edit /etc/rc.conf
per the instructions in the script.

NOTE: Sguild now runs under the sguil user account not root!

At the end of the process the system had these packages installed.

tao# pkg_info
barnyard-sguil-0.2.0_5 An output system for Snort (patched for sguil)
mysql-client-5.0.67_1 Multithreaded SQL database (client)
mysql-server-5.0.67_1 Multithreaded SQL database (server)
mysqltcl-3.05 TCL module for accessing MySQL databases based on msqltcl
p0f-2.0.8 Passive OS fingerprinting tool
pcre-7.7_1 Perl Compatible Regular Expressions library
sguil-sensor-0.7.0_2 Sguil is a network security monitoring program
sguil-server-0.7.0_2 Sguil is a network security monitoring program
snort-2.8.2.1_1 Lightweight network intrusion detection system
tcl-8.4.19,1 Tool Command Language
tclX-8.4_1 Extended TCL
tcllib-1.10_1 A collection of utility modules for Tcl
tcltls-1.6 SSL extensions for TCL; dynamicly loadable
tcpflow-0.21_1 A tool for capturing data transmitted as part of TCP connec

If I wanted to go from here to actually run the Sguil server, I would have to manually create the database and certificates. Once the script is fixed I shouldn't have to do that.

The major configuration issue that remains is ensuring that data is being written to logical locations. This primarily means pcap data is stored in a partition that can accommodate it, and the database is located in a partition that can handle growing tables.

I think it should be clear at this point that the easiest way to try Sguil is to use NSMNow. I recommend that only for demo installations, although you can tweak the installation to put what you want in locations you like.


Richard Bejtlich is teaching new classes in DC and Europe in 2009. Register by 1 Jan and 1 Feb, respectively, for the best rates.