Saturday, January 31, 2009

Upgrading FreeBSD Packages

In my last post I discussed upgrading from FreeBSD 7.0 to 7.1. In this post I'll mention packages that needed to be updated.

In the last post I showed two installed packages using the native pkg_info command.

neely# pkg_info
cdrtools-2.01_6 CD/CD-R[W] and ISO-9660 image creation and extraction tools
dvd+rw-tools-7.0 DVD burning software

At this point I could have used pkg_delete to remove them, and added the newest packages via pkg_add. Because that is easy, I decided to show an alternative that might be better for systems with many packages.

I decided to use Portupgrade to update packages installed on the system. Portupgrade was not on the box so I added it via pkg_add. I used the -n switch to do a "dry run" to see what version would be added.

neely# pkg_add -vrn portupgrade
scheme: [ftp]
user: []
password: []
host: [ftp.freebsd.org]
port: [0]
document: [/pub/FreeBSD/ports/i386/packages-7.1-release/Latest/portupgrade.tbz]
---> ftp.freebsd.org:21
looking up ftp.freebsd.org
connecting to ftp.freebsd.org:21
<<< 220 Welcome to freebsd.isc.org.
>>> USER anonymous
<<< 331 Please specify the password.
>>> PASS richard@neely.taosecurity.com
<<< 230 Login successful.
>>> PWD
<<< 257 "/"
>>> CWD pub/FreeBSD/ports/i386/packages-7.1-release/Latest
<<< 250 Directory successfully changed.
>>> MODE S
<<< 200 Mode set to S.
>>> TYPE I
<<< 200 Switching to Binary mode.
setting passive mode
>>> PASV
<<< 227 Entering Passive Mode (204,152,184,73,191,203)
opening data connection
initiating transfer
>>> RETR portupgrade.tbz
<<< 150 Opening BINARY mode data connection for portupgrade.tbz (132387 bytes).
Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-7.1-release/Latest
/portupgrade.tbz...Waiting for final status
x +CONTENTS
x +COMMENT
x +DESC
x +DISPLAY
x +MTREE_DIRS
x man/man1/pkg_deinstall.1.gz
x man/man1/pkg_fetch.1.gz
x man/man1/pkg_glob.1.gz
x man/man1/pkg_sort.1.gz
x man/man1/pkgdb.1.gz
x man/man1/pkgdu.1.gz
x man/man1/portcvsweb.1.gz
x man/man1/portsclean.1.gz
x man/man1/portsdb.1.gz
x man/man1/portupgrade.1.gz
x man/man1/portversion.1.gz
x man/man5/pkgtools.conf.5.gz
x man/man1/pkg_which.1.gz
x man/man1/portinstall.1.gz
x man/man1/ports_glob.1.gz
x sbin/pkg_deinstall
x sbin/pkg_fetch
x sbin/pkg_glob
x sbin/pkg_sort
x sbin/pkg_which
x sbin/pkgdb
x sbin/pkgdu
x sbin/portcvsweb
x sbin/portinstall
x sbin/ports_glob
x sbin/portsclean
x sbin/portsdb
x sbin/portupgrade
x sbin/portversion
x lib/ruby/site_ruby/1.8/pkg.rb
x lib/ruby/site_ruby/1.8/pkgdb.rb
x lib/ruby/site_ruby/1.8/pkgdbtools.rb
x lib/ruby/site_ruby/1.8/pkginfo.rb
x lib/ruby/site_ruby/1.8/pkgmisc.rb
x lib/ruby/site_ruby/1.8/pkgtools.rb
x lib/ruby/site_ruby/1.8/pkgtsort.rb
x lib/ruby/site_ruby/1.8/pkgversion.rb
x lib/ruby/site_ruby/1.8/portinfo.rb
x lib/ruby/site_ruby/1.8/ports.rb
x lib/ruby/site_ruby/1.8/portsdb.rb
x etc/pkgtools.conf.sample
x etc/pkgtools.status-pkg.sh
x share/zsh/site-functions/_pkgtools
x share/examples/pkgtools/bash/complete.sample
x share/examples/pkgtools/tcsh/complete.sample
x share/doc/pkgtools/ChangeLog
x share/doc/pkgtools/NEWS
x share/doc/pkgtools/README
x libdata/ldconfig/portupgrade
<<< 226 File send OK.
tar command returns 0 status
Done.
Package 'portupgrade-2.4.6,2' depends on 'ruby-1.8.6.287,1' with 'lang/ruby18' origin.
and was not found.
Package 'portupgrade-2.4.6,2' depends on 'db41-4.1.25_4' with 'databases/db41' origin.
and was not found.
Package 'portupgrade-2.4.6,2' depends on 'ruby18-bdb-0.6.4' with 'databases/ruby-bdb' origin.
and was not found.
pkg_add: 1 package addition(s) failed

Notice pkg_add used ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-7.1-release/Latest as its installation location. I could have altered this behavior by setting an environment variable thus:

setenv PACKAGESITE ftp://ftp2.freebsd.org/pub/FreeBSD/ports/i386/packages-7-stable/Latest/

I didn't do that here, however, so I'm installing the version as released with 7.1.

neely# pkg_add -vr portupgrade
...edited...
Trying to record dependency on package 'ruby-1.8.6.287,1' with 'lang/ruby18' origin.
Trying to record dependency on package 'db41-4.1.25_4' with 'databases/db41' origin.
Trying to record dependency on package 'ruby18-bdb-0.6.4' with 'databases/ruby-bdb' origin.
Package portupgrade-2.4.6,2 registered in /var/db/pkg/portupgrade-2.4.6,2

------------------------------------------------------------------------------
Fill ALT_PKGDEP section in pkgtools.conf file for portupgrade
be aware of alternative dependencies you use.
E.g.
ALT_PKGDEP = {
'www/apache13' => 'www/apache13-modssl',
'print/ghostscript-gnu' => 'print/ghostscript-gpl',
}

Note also, portupgrade knows nothing how to handle ports with different
suffixes (E.g. -nox11). So you should explicitly define variables
(E.g. WITHOUT_X11=yes) for the ports in /etc/make.conf or pkgtools.conf
(MAKE_ARGS section) files.
------------------------------------------------------------------------------

Great, now let's see what needs to be updated.

neely# pkg_version -v
cdrtools-2.01_6 ? orphaned: sysutils/cdrtools
db41-4.1.25_4 ? orphaned: databases/db41
dvd+rw-tools-7.0 ? orphaned: sysutils/dvd+rw-tools
portupgrade-2.4.6,2 ? orphaned: ports-mgmt/portupgrade
ruby-1.8.6.287,1 ? orphaned: lang/ruby18
ruby18-bdb-0.6.4 ? orphaned: databases/ruby-bdb

Ah, I don't have a ports tree on this system. Even though I'm not building anything using the ports tree (I'm installing packages), I still need a local copy of the ports tree to know what is current. I install it using Portsnap.

neely# portsnap fetch
Looking up portsnap.FreeBSD.org mirrors... 2 mirrors found.
Fetching public key from portsnap2.FreeBSD.org... done.
Fetching snapshot tag from portsnap2.FreeBSD.org... done.
Fetching snapshot metadata... done.
Fetching snapshot generated at Sat Jan 31 19:15:45 EST 2009:
922e444be604245dd2c5567a0394f2ec588a710724529c100% of 55 MB 94 kBps 00m00s
Extracting snapshot... done.
Verifying snapshot integrity... done.
Fetching snapshot tag from portsnap2.FreeBSD.org... done.
Fetching snapshot metadata... done.
Updating from Sat Jan 31 19:15:45 EST 2009 to Sat Jan 31 20:26:31 EST 2009.
Fetching 3 metadata patches.. done.
Applying metadata patches... done.
Fetching 0 metadata files... done.
Fetching 8 patches..... done.
Applying patches... done.
Fetching 0 new ports or files... done.

neely# portsnap extract
...edited...
Building new INDEX files... done.

In the future to update I would change extract to update.

Now I can see what needs updating.

neely# pkg_version -v
cdrtools-2.01_6 < needs updating (port has 2.01_7)
db41-4.1.25_4 = up-to-date with port
dvd+rw-tools-7.0 < needs updating (port has 7.1)
portupgrade-2.4.6,2 = up-to-date with port
ruby-1.8.6.287,1 = up-to-date with port
ruby18-bdb-0.6.4 = up-to-date with port

I decided to run Portupgrade and tell it to only use packages (PP):

neely# portupgrade -varRPP
---> Session started at: Sat, 31 Jan 2009 22:37:43 -0500
[Rebuilding the pkgdb in /var/db/pkg ... - 6 packages found (-0 +6) ...... done]
[Updating the portsdb in /usr/ports ... - 19698 port entries found
.........1000.........2000.........3000.........4000.........5000.........
6000.........7000.........8000.........9000.........10000.........11000.........
12000.........13000.........14000.........15000.........16000.........17000.....
....18000.........19000...... ..... done]
---> Checking for the latest package of 'sysutils/cdrtools'
** No such file or directory - /usr/ports/packages/All
---> Fetching the package(s) for 'cdrtools-2.01_7' (sysutils/cdrtools)
---> Fetching cdrtools-2.01_7
++ Will try the following sites in the order named:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-7.1-release/
---> Invoking a command: /usr/bin/fetch -o '/var/tmp/portupgradepS4h9CcR/cdrtools-
2.01_7.tbz' 'ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-7.1-release/All/cdrtools-2.01_7.tbz'
/var/tmp/portupgradepS4h9CcR/cdrtools-2.01_7.t100% of 767 kB 86 kBps
---> Downloaded as cdrtools-2.01_7.tbz
---> Identifying the package /var/tmp/portupgradepS4h9CcR/cdrtools-2.01_7.tbz
---> Saved as /usr/ports/packages/All/cdrtools-2.01_7.tbz
---> Listing the results (+:done / -:ignored / *:skipped / !:failed)
+ cdrtools-2.01_7
---> Packages processed: 1 done, 0 ignored, 0 skipped and 0 failed
---> Found a package of 'sysutils/cdrtools': /usr/ports/packages/All/cdrtools-
2.01_7.tbz (cdrtools-2.01_7)
---> Located a package version 2.01_7 (/usr/ports/packages/All/cdrtools-2.01_7.tbz)
---> Upgrade of sysutils/cdrtools started at: Sat, 31 Jan 2009 22:38:08 -0500
---> Upgrading 'cdrtools-2.01_6' to 'cdrtools-2.01_7' (sysutils/cdrtools) using a package
---> Updating dependency info
---> Modifying /var/db/pkg/dvd+rw-tools-7.0/+CONTENTS
---> Uninstallation of cdrtools-2.01_6 started at: Sat, 31 Jan 2009 22:38:08 -0500
---> Fixing up dependencies before creating a package
---> Backing up the old version
---> Uninstalling the old version
---> Deinstalling 'cdrtools-2.01_6'
pkg_delete: package 'cdrtools-2.01_6' is required by these other packages
and may not be deinstalled (but I'll delete it anyway):
dvd+rw-tools-7.0
[Updating the pkgdb in /var/db/pkg ... - 5 packages found (-1 +0)
(...) done]
---> Uninstallation of cdrtools-2.01_6 ended at: Sat, 31 Jan 2009 22:38:12 -0500
(consumed 00:00:03)
---> Installation of cdrtools-2.01_7 started at: Sat, 31 Jan 2009 22:38:12 -0500
---> Installing the new version via the package

===========================================================================

Note: The location of the cdrtools `defaults' files has been set to

/usr/local/etc

This is the FreeBSD ports standard config file location, NOT the cdrtools
standard location, which is /etc/default.

The reason for this is that FreeBSD ports and packages should not use
configuration files outside of /usr/local.

===========================================================================

---> Removing temporary files and directories
---> Removing old package'
---> Installation of cdrtools-2.01_7 ended at: Sat, 31 Jan 2009 22:38:14 -0500 (consumed 00:00:01)
---> Cleaning out obsolete shared libraries
[Updating the pkgdb in /var/db/pkg ... - 6 packages found (-0 +1) . done]
---> Upgrade of sysutils/cdrtools ended at: Sat, 31 Jan 2009 22:38:16 -0500
(consumed 00:00:07)
---> ** Upgrade tasks 2: 1 done, 0 ignored, 0 skipped and 0 failed
---> Checking for the latest package of 'sysutils/dvd+rw-tools'
---> Fetching the package(s) for 'dvd+rw-tools-7.1' (sysutils/dvd+rw-tools)
---> Fetching dvd+rw-tools-7.1
++ Will try the following sites in the order named:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-7.1-release/
---> Invoking a command: /usr/bin/fetch -o '/var/tmp/portupgradeFKkYF29e/dvd+rw-
tools-7.1.tbz' 'ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-7.1-release
/All/dvd+rw-tools-7.1.tbz'
/var/tmp/portupgradeFKkYF29e/dvd+rw-tools-7.1.100% of 101 kB 52 kBps
---> Downloaded as dvd+rw-tools-7.1.tbz
---> Identifying the package /var/tmp/portupgradeFKkYF29e/dvd+rw-tools-7.1.tbz
---> Saved as /usr/ports/packages/All/dvd+rw-tools-7.1.tbz
---> Skipping cdrtools-2.01_7 (already installed)
---> Listing the results (+:done / -:ignored / *:skipped / !:failed)
+ dvd+rw-tools-7.1
- cdrtools-2.01_7
---> Packages processed: 1 done, 1 ignored, 0 skipped and 0 failed
---> Found a package of 'sysutils/dvd+rw-tools': /usr/ports/packages/All/dvd+rw-
tools-7.1.tbz (dvd+rw-tools-7.1)
---> Located a package version 7.1 (/usr/ports/packages/All/dvd+rw-tools-7.1.tbz)
---> Upgrade of sysutils/dvd+rw-tools started at: Sat, 31 Jan 2009 22:38:22 -0500
---> Upgrading 'dvd+rw-tools-7.0' to 'dvd+rw-tools-7.1' (sysutils/dvd+rw-tools) using a package
---> Updating dependency info
---> Uninstallation of dvd+rw-tools-7.0 started at: Sat, 31 Jan 2009 22:38:22 -0500
---> Fixing up dependencies before creating a package
---> Backing up the old version
---> Uninstalling the old version
---> Deinstalling 'dvd+rw-tools-7.0'
[Updating the pkgdb in /var/db/pkg ... - 5 packages found (-1 +0)
(...) done]
---> Uninstallation of dvd+rw-tools-7.0 ended at: Sat, 31 Jan 2009 22:38:26 -0500 (consumed 00:00:04)
---> Installation of dvd+rw-tools-7.1 started at: Sat, 31 Jan 2009 22:38:26 -0500
---> Installing the new version via the package
---> Removing temporary files and directories
---> Removing old package'
---> Installation of dvd+rw-tools-7.1 ended at: Sat, 31 Jan 2009 22:38:27 -0500 (consumed 00:00:01)
---> Cleaning out obsolete shared libraries
[Updating the pkgdb in /var/db/pkg ... - 6 packages found (-0 +1)
. done]
---> Upgrade of sysutils/dvd+rw-tools ended at: Sat, 31 Jan 2009 22:38:29 -0500
(consumed 00:00:07)
---> ** Upgrade tasks 2: 2 done, 0 ignored, 0 skipped and 0 failed
---> Listing the results (+:done / -:ignored / *:skipped / !:failed)
+ sysutils/cdrtools (cdrtools-2.01_6)
+ sysutils/dvd+rw-tools (dvd+rw-tools-7.0)
---> Packages processed: 2 done, 0 ignored, 0 skipped and 0 failed
---> Session ended at: Sat, 31 Jan 2009 22:38:31 -0500 (consumed 00:00:48)

When done I check the results:

neely# pkg_version -v
cdrtools-2.01_7 = up-to-date with port
db41-4.1.25_4 = up-to-date with port
dvd+rw-tools-7.1 = up-to-date with port
portupgrade-2.4.6,2 = up-to-date with port
ruby-1.8.6.287,1 = up-to-date with port
ruby18-bdb-0.6.4 = up-to-date with port

That's it!


Richard Bejtlich is teaching new classes in DC and Europe in 2009. Register before free seats are taken!

Upgrading FreeBSD 7.0 to 7.1

My last post on upgrading FreeBSD was Updating FreeBSD 7.0-BETA2 to 7.0-BETA3.

In this post I'll describe how I migrated a test install of FreeBSD 7.0-RELEASE #0 to FreeBSD 7.0-RELEASE-p7 #0, and then from there to FreeBSD 7.1-RELEASE #0.

Here's what I started with.

neely# uname -a
FreeBSD neely.taosecurity.com 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24
19:59:52 UTC 2008 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386

To update to the latest version of 7.0, I ran freebsd-update. First I run without switches to show available options.

neely# freebsd-update
usage: freebsd-update [options] command ... [path]

Options:
-b basedir -- Operate on a system mounted at basedir
(default: /)
-d workdir -- Store working files in workdir
(default: /var/db/freebsd-update/)
-f conffile -- Read configuration options from conffile
(default: /etc/freebsd-update.conf)
-k KEY -- Trust an RSA key with SHA256 hash of KEY
-r release -- Target for upgrade (e.g., 6.2-RELEASE)
-s server -- Server from which to fetch updates
(default: update.FreeBSD.org)
-t address -- Mail output of cron command, if any, to address
(default: root)
Commands:
fetch -- Fetch updates from server
cron -- Sleep rand(3600) seconds, fetch updates, and send an
email if updates were found
upgrade -- Fetch upgrades to FreeBSD version specified via -r option
install -- Install downloaded updates or upgrades
rollback -- Uninstall most recently installed updates

Notice the -s switch. If you decide to pick a specific server, how do you choose? This neat trick gives you options:

$ host -t srv _http._tcp.update.freebsd.org
_http._tcp.update.freebsd.org has SRV record 1 25 80 update2.FreeBSD.org.
_http._tcp.update.freebsd.org has SRV record 1 10 80 update1.FreeBSD.org.

Note results vary depending on what servers are available at any point in time.

Now I start the update process.

neely# freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 2 mirrors found.
Fetching metadata signature for 7.0-RELEASE from update2.FreeBSD.org... done.
Fetching metadata index... done.
Fetching 2 metadata patches.. done.
Applying metadata patches... done.
Fetching 2 metadata files... done.
Inspecting system... done.
Preparing to download files... done.
Fetching 27 patches.....10....20... done.
Applying patches... done.

The following files will be updated as part of updating to 7.0-RELEASE-p9:
/boot/kernel/if_faith.ko
/boot/kernel/if_fwip.ko
/boot/kernel/if_stf.ko
/boot/kernel/ip_mroute.ko
/boot/kernel/ipfw.ko
/boot/kernel/kernel
/boot/kernel/pf.ko
/boot/kernel/random.ko
/usr/bin/dig
/usr/bin/host
/usr/bin/nslookup
/usr/bin/nsupdate
/usr/bin/openssl
/usr/include/netinet/tcp.h
/usr/include/netinet6/in6.h
/usr/include/netinet6/nd6.h
/usr/lib/libssl.a
/usr/lib/libssl.so.5
/usr/libexec/ftpd
/usr/libexec/lukemftpd
/usr/sbin/dnssec-keygen
/usr/sbin/dnssec-signzone
/usr/sbin/lwresd
/usr/sbin/named
/usr/sbin/named-checkconf
/usr/sbin/named-checkzone
/usr/sbin/named-compilezone
/usr/sbin/ntpd
/usr/sbin/rndc-confgen

WARNING: FreeBSD 7.0-RELEASE is approaching its End-of-Life date.
It is strongly recommended that you upgrade to a newer
release within the next 2 months.

neely# freebsd-update install
Installing updates... done.
neely# reboot

After I reboot I am running FreeBSD 7.0-RELEASE-p7 #0.

neely# uname -a
FreeBSD neely.taosecurity.com 7.0-RELEASE-p7 FreeBSD 7.0-RELEASE-p7 #0: Sun Dec 21
12:33:45 UTC 2008 root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386

For my own reference I see what packages are installed.

neely# pkg_info
cdrtools-2.01_6 CD/CD-R[W] and ISO-9660 image creation and extraction tools
dvd+rw-tools-7.0 DVD burning software

Now I will upgrade to 7.1.

neely# freebsd-update upgrade -r 7.1-RELEASE
Looking up update.FreeBSD.org mirrors... 2 mirrors found.
Fetching metadata signature for 7.0-RELEASE from update2.FreeBSD.org... done.
Fetching metadata index... done.
Fetching 1 metadata patches. done.
Applying metadata patches... done.
Inspecting system... done.

The following components of FreeBSD seem to be installed:
kernel/generic world/base world/dict world/doc world/games world/info
world/manpages

The following components of FreeBSD do not seem to be installed:
src/base src/bin src/cddl src/compat src/contrib src/crypto src/etc
src/games src/gnu src/include src/krb5 src/lib src/libexec src/release
src/rescue src/sbin src/secure src/share src/sys src/tools src/ubin
src/usbin world/catpages world/proflibs

Does this look reasonable (y/n)? y

Fetching metadata signature for 7.1-RELEASE from update2.FreeBSD.org... done.
Fetching metadata index... done.
Fetching 1 metadata patches. done.
Applying metadata patches... done.
Fetching 1 metadata files... done.
Inspecting system...done.
Fetching files from 7.0-RELEASE for merging... done.
Preparing to download files...done.
Fetching 10989 patches.....10....20....30....40....50....60....70....80....90....100....110
...edited...
810....6820....6830....6840....6850....6860.. done.
Applying patches... done.
Fetching 4516 files... failed.

That doesn't look good. Maybe the server was loaded? Based on a few searches I decide to start the process again.

neely# freebsd-update upgrade -r 7.1-RELEASE
Looking up update.FreeBSD.org mirrors... 2 mirrors found.
Fetching metadata signature for 7.0-RELEASE from update2.FreeBSD.org... done.
Fetching metadata index... done.
Fetching 1 metadata patches. done.
Applying metadata patches... done.
Fetching 1 metadata files... done.
Inspecting system... done.

The following components of FreeBSD seem to be installed:
kernel/generic world/base world/dict world/doc world/games world/info
world/manpages

The following components of FreeBSD do not seem to be installed:
src/base src/bin src/cddl src/compat src/contrib src/crypto src/etc
src/games src/gnu src/include src/krb5 src/lib src/libexec src/release
src/rescue src/sbin src/secure src/share src/sys src/tools src/ubin
src/usbin world/catpages world/proflibs

Does this look reasonable (y/n)? y

Fetching metadata signature for 7.1-RELEASE from update2.FreeBSD.org... done.
Fetching metadata index... done.
Fetching 1 metadata patches. done.
Applying metadata patches... done.
Fetching 1 metadata files... done.
Inspecting system... done.
Fetching files from 7.0-RELEASE for merging... done.
Preparing to download files... done.
Fetching 3312 patches.....10....20....30....40....50....60....70....80....90....
...edited...
2620....2630....2640....2650....2660....2670....2680....2690... done.
Applying patches... done.
Fetching 1433 files...done.
Attempting to automatically merge changes in files... done.

The following changes, which occurred between FreeBSD 7.0-RELEASE and
FreeBSD 7.1-RELEASE have been merged into /etc/group:
--- current version
+++ new version
@@ -1,6 +1,6 @@
-# $FreeBSD: src/etc/group,v 1.35 2007/06/11 18:36:39 ceri Exp $
+# $FreeBSD: src/etc/group,v 1.35.6.1 2008/11/25 02:59:29 kensmith Exp $
#
wheel:*:0:root,richard
daemon:*:1:
kmem:*:2:
sys:*:3:
Does this look reasonable (y/n)? y

The following changes, which occurred between FreeBSD 7.0-RELEASE and
FreeBSD 7.1-RELEASE have been merged into /etc/master.passwd:
--- current version
+++ new version
@@ -1,6 +1,6 @@
-# $FreeBSD: src/etc/master.passwd,v 1.40 2005/06/06 20:19:56 brooks Exp $
+# $FreeBSD: src/etc/master.passwd,v 1.40.18.1 2008/11/25 02:59:29 kensmith Exp $
#
root:$1$qmgoobYq$tNDy/Y2N8QDJVjFk5E.NB.:0:0::0:0:Charlie &:/root:/bin/csh
toor:*:0:0::0:0:Bourne-again Superuser:/root:
daemon:*:1:1::0:0:Owner of many system processes:/root:/usr/sbin/nologin
operator:*:2:5::0:0:System &:/:/usr/sbin/nologin
Does this look reasonable (y/n)? y

The following changes, which occurred between FreeBSD 7.0-RELEASE and
FreeBSD 7.1-RELEASE have been merged into /etc/passwd:
--- current version
+++ new version
@@ -1,6 +1,6 @@
-# $FreeBSD: src/etc/master.passwd,v 1.40 2005/06/06 20:19:56 brooks Exp $
+# $FreeBSD: src/etc/master.passwd,v 1.40.18.1 2008/11/25 02:59:29 kensmith Exp $
#
root:*:0:0:Charlie &:/root:/bin/csh
toor:*:0:0:Bourne-again Superuser:/root:
daemon:*:1:1:Owner of many system processes:/root:/usr/sbin/nologin
operator:*:2:5:System &:/:/usr/sbin/nologin
Does this look reasonable (y/n)? y
The following files will be removed as part of updating to 7.1-RELEASE-p2:
/etc/rc.d/kernel
/usr/include/netgraph/atm/ng_atmpif.h
/usr/sbin/pkg_check
/usr/sbin/pkg_sign
/usr/share/doc/de_DE.ISO8859-1/books/handbook/portsnap.html
...edited...
The following files will be added as part of updating to 7.1-RELEASE-p2:
/boot/gptboot
/boot/kernel/cmx.ko
/boot/kernel/cmx.ko.symbols
...edited...
The following files will be updated as part of updating to 7.1-RELEASE-p2:
/.cshrc
/.profile
/COPYRIGHT
/bin/[
/bin/cat
...edited...
/var/named/etc/namedb/named.root
/var/yp/Makefile.dist

neely# freebsd-update install -r 7.1-RELEASE
Installing updates...
Kernel updates have been installed. Please reboot and run
"/usr/sbin/freebsd-update install" again to finish installing updates.
neely# reboot

After rebooting I run install again.

$ su -
Password:
neely# freebsd-update install
Installing updates...... done.
neely# reboot

$ uname -a
FreeBSD neely.taosecurity.com 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1
14:37:25 UTC 2009 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386

All done! If I want to see if any other patches are available I can run fetch again.

$ su -
Password:

neely# freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 2 mirrors found.
Fetching metadata signature for 7.1-RELEASE from update2.FreeBSD.org... done.
Fetching metadata index... done.
Fetching 2 metadata patches.. done.
Applying metadata patches... done.
Fetching 2 metadata files... done.
Inspecting system... done.
Preparing to download files... done.

No updates needed to update system to 7.1-RELEASE-p2.

Looks like that's it.


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

Friday, January 30, 2009

Advice to Bloggers

Recently a blog reader asked two questions as he started his own new blog:

1. Do you think I should stick to just one topic? i.e. Digital Forensics?

2. Do you think blogging is a good way to learn more about a topic of interest or should you only blog about a topic you already know a lot about?


I addressed some of these issues in my post Why Blog?, but I'll add the following.

I recommend writing about a handful of topics, but stick to topics within a certain theme. For example, my blog covers "digital security and the practices of network security monitoring, incident response, and forensics." Although I love martial arts and ice hockey, I don't write about that here. I also do not address politics, family, religion, or any other non-technical issues in this forum. I believe blog readers prefer me to stay on my listed subjects; they can visit other sites for non-technical information.

I believe it is ok to write about subjects that are outside your core expertise, but you need to warn the reader that you are a beginner. Do not presume to be an authority on a subject that is new to you. Tell the reader and let him or her be the judge. If you don't know a lot about a topic, but you want to solicit assistance, say that in your post.

If you make a habit of discussing topics that are foreign to you, you will probably not be respected, however. I don't think many readers want to visit a blog that is constantly asking how to accomplish a task. Most readers want to learn something or see a new viewpoint, not be asked questions all the time.



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

Northrop Grumman's Timothy McKnight on Security

Ken Bradley sent me a link to Northrop Grumman's Timothy McKnight on Security and Identity Management by Katherine Walsh of CSO Magazine. It's an older article but I liked this part:

CSO: Can you tell me about the formation of the Cyber Threat Analysis Intelligence Group and its role at Northrop Grumman?

McKnight: That team's focus is on the nation-state threat, which the DoD is now terming the "advanced persistent threat." These are well resourced, highly targeted attacks at corporations and governments [by groups] that are looking primarily to steal intellectual property and gain competitive advantage.

The Cyber Threat Analysis Intelligence Group is made up of techies and people with government analyst backgrounds. Their job is to focus on the technologies that are considered the crown jewels of Northrop Grumman. They look at the technologies we provide for the government, who the biggest threat to those technologies is, who needs them the most, how they [may be] targeting that information and what can we do to protect against it. That group is deploying customized solutions to handle all of that.


Notice this group is asset-centric and threat-centric, i.e., they look to see what matters to the company (and what might matter to an adversary) and they also identify who might want to steal it.

This is in stark contrast to the vulnerability-centric stance of most security shops. Sure, you always need to know your weaknesses, but the idea of paying attention to what matters to you, and by extension, what information a threat might want to exfiltrate/degrade/deny, is excellent. I expect the work this group does also helps NG to Unify Against Threats.


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

Virtualized Network Security Monitoring Platforms

Yesterday a blog reader asked:

Looking back at previous blogs, notably

http://taosecurity.blogspot.com/2005/12/network-monitoring-platforms-on-vmware.html

I see that you have, in your classes, used VM's to run your network monitoring tools from. Have you progressed this idea into a production environment or do you still feel that running tools in this configuration, be they on a Linux host or not, would still be too much of a compromise.

The scenario i work under means that i cannot have my sensors connected to the Internet which makes keeping them upto date difficult and i was looking at creating a generic VM that i could keep live and up to date on an Internet facing terminal and then copy to my production environment as and when i wish to deploy new verions of tools or updated signatures.

Grateful for your thoughts


The reader is correct; whenever I deploy NSM platforms as VMs, it's only for demo or class purposes. I do not use NSM platforms as VMs in production, where my "NSM VM" might be deployed alongside other production VMs. I make the following arguments.

  1. Most NSM platforms I deploy require at least 3 NICs, and possibly 5. My VMs actively use 1 NIC for management via SSH, 2 NICs for connection to a traditional network tap, and potentially 2 more NICs for tapping a backup or high-available link paired with the first tap. Most VM server platforms are designed to share a small number of NICs among many virtual machines for management and serving content. The NSM in VM concept stretches or breaks that model.

  2. NICs on NSM platforms are not performing periodic data transmission or reception; they are usually always receiving data. The monitoring NICs on a NSM platform are used to sniff network traffic. On anything but the most trivial network, these NICs are constantly listening for network traffic. This also stretches, if not breaks, the traditional VM model.

  3. Hard drives on NSM platforms are constantly writing, incurring high storage I/O costs. NSM platform are constantly writing full content Pcap data to disk, in addition to session records, IDS alerts, and other data. The full content collection requirement alone strains the idea of having a NSM VM writing data while other VMs on the same physical hardware compete for resources.

  4. Some NSM applications are RAM- and CPU-intensive. Snort in 2009 is not the same as Snort in 1999. If you've looked at the resources consumed by Snort 2.x, you'll see a large footprint. NSM platforms also run session data collection tools (like SANCP), other alert data tools (maybe Bro), and other tools, so they are already doing their own part to share resources among many competing interests.

  5. If you consider why virtualization is attractive, you'll see virtualizating a NSM appliance doesn't fit the model. Virtualization is supposed to be helpful for making more efficient use of underutilized hardware. The classic case involves a rack of servers each using a fraction of their resources. Why not virtualize those servers and reduce your overall computing footprint? That model makes sense. It does not make sense to take a platform which is already monopolizing its available resources and shoehorn it into a virtual server.


There are obvious benefits to virtualization in general, such as easy creation/destruction of VMs, the ability to snapshot/introduce a change/roll back, and so on. At this point, those advantages do not compensate for the disadvantages I outlined.


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

Raffy Marty Teaching Security Visualization

Raffy Marty, author of Applied Security Visualization is teaching a Security Visualization and Log Analysis Workshop at SOURCEBoston on 9-10 March. Raffy's a great instructor and this is the first class I've seen on the topic. Check it out!


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

Monday, January 26, 2009

Why Network Taps

My colleagues and I are spending some time justifying the installation of network taps, instead of using SPAN ports, to gain access to network traffic. This is an old discussion. See my Dec 07 post Expert Commentary on SPAN and RSPAN Weaknesses and Net Optics' page Tap vs SPAN. For a different perspective see Scott Haugdahl's Is Spanning Bad? and Is RSPAN Bad?.

I'm using the following points when discussing the situation.

  1. Taps free SPAN ports for tactical, on-demand monitoring, especially intra-switch monitoring. Many switches have only two ports capable of SPAN, and some offer only one. If you commit a SPAN port for permanent monitoring duties, and you need to reassign it for some sort of troubleshooting on a VLAN or other aspect of the traffic, you have to deny traffic to your sensor while the SPAN port is doing other work. Keep your SPAN ports free so you can do intra-switch monitoring when you need it.

  2. Taps provide strategic, persistent monitoring. Installing a tap means you commit to a permanent method of access to network traffic. Once the tap is installed you don't need to worry about how you are going to access network traffic again. Taps should really be part of any network deployment, especially at key points in the network.

  3. Selected taps do not permit injected traffic onto the monitored link. Depending on the tap you deploy, you will find that it will not be physically capable of transmitting traffic from the sensor to the monitored link. This is not true of SPAN ports. Yes, you can configure SPAN ports to not transmit traffic, and that is the norm. However, from my consulting days I can remember one location where I was told to deploy a sensor on a box with one NIC. Yes, one NIC. That meant the same NIC used for remote SSH access also connected to a switch SPAN port. Yes, I felt dirty.

  4. What taps see is not influenced by configuration (as is the case with SPAN ports); i.e., what you see is really what is passing on the link. This is key, yet underestimated. If you own the sensor connected to a SPAN port, but not the switch, you are at the mercy of the switch owner. If the switch owner mistakenly or intentionally configures the SPAN port to not show all the traffic it should, you may or may not discover the misconfiguration. I have seen this happen countless times. With a network tap, there's no hiding the traffic passing on the monitored link. Many shops have been surprised by what is traversing a link when the finally take a direct look at the traffic.

  5. Taps do not place traffic on a switch data plane, like a SPAN port does. This point is debatable. Depending on switch architecture, SPAN ports may or may not affect the switch's ability to pass traffic. By that I mean a SPAN port may not receive all traffic when the switch is loaded, because forwarding may take precedence over SPANning.


There are other reasons to prefer network taps, but I'll direct you to the links I provided. Those are good resources.


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

Saturday, January 24, 2009

DC BSDCon 2009 Registration Reminder

Recently I posted that I will be speaking at DC BSDCon 2009, on 6 February 2009. I'll be discussing something about Network Security Monitoring that applies to FreeBSD.

As a reminder, registration ends 31 Jan 09 (next Saturday) and is limited to the first 150 attendees.


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

Sunday, January 18, 2009

Reader Questions: Internal or External MSSP

Another reader asked the following:

As I am doing research for building a security operations center one of the things I am being asked to do is compare building things internally versus having an MSSP take on certain network monitoring functions. There is the suggestion that it is less expensive and more desirable to have a MSSP provide monitoring services for firewall and IDS devices. In addition the thinking is that the MSSP should provide log managment services for other logs that are being sent to our log managment platform (not sure what this service offering means).

I do not personally agree that this is the best approach. First of all they are planning on obtaining these services from a vendor we currently utilize that already is supposed to be providing some of these services and they don't appear to be providing anything useful. I've had discussions with a network security analyst that has been in this environment for quite some time and he said he routinely finds issues on his own that the vendor does not catch. (not surprisingly this is found with open source tools). I strongly believe in developing internal employees with business knowledge and relationships to do this type of work. If you asked me today who I would recommend to focus on network security monitoring I could easily pick individuals that have the mindset to do this type of work. I don't think an outside service provider could provide the same business value as a properly trained internal team.

Thoughts? [Obviously what I am describing is only one component of security operations, but it is the primary component that really doesn't exist here. I know from experience that ignorance is not bliss from my days at [company X] and the types of things we were finding on our network].


Last year I wrote Internall Security Staff Matters. I argued that, especially for large and complex organizations, the amount of business knowledge required for a security analyst to be successful makes internal security staff very important. In situations where no security monitoring happens, any assistance is welcome -- whether internal or external.

One could argue that certain functions are ripe for outsourcing. Device administration, usually for commercial gear, can often be done cheaply by outsiders. Certain triage and entry-level 24x7 functions can be done by outsiders, but I would argue that those jobs should not simply be tripwires. In other words, those workers should have clearly defined roles that do not result in every odd activity being escalated to the experts or ignored for reasons of insufficient experience.

For large organizations like mine I favor a small team of experts, each of whom brings a unique skill set to the group. For example, we have individuals specializing in NSM, advanced threats, live response, reverse engineering, logs, incident response planning and constituent relationship management, and so on. Beyond people we have high-fidelity NSM data, logs, and the growing ability to acquire live response and other host-centric evidence. I don't see an external provider being service-effective given the nature of our business. I also don't see an outsider being cost-effective, given the quotes we were cited earlier in our planning processes.


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

Reader Questions on Network Security Monitoring

A regular blog reader and Network Security Monitoring practitioner sent me these questions last month, so I'd like to answer them here.

1. Are all alert data created equal?

This question originates with my employment at an MSSP where we process many types of alert data from Dragon IDS, Cisco IPS and ISS. Snort and Sourcefire strangely are underrepresented. My question is if Dragon IDS, Cisco IPS, ISS, Snort and Sourcefire all looked at the same full-content data, would they all produce the same results? I think not and would like to empirically verify this theory.


Testing detection systems is a complicated topic. I am not sure what methodology a place like NSS Labs uses. I bet they get varying results depending on the product. If you read A Tool for Offline and Live Testing of Evasion Resilience. in Network Intrusion Detection Systems you will see big differences between Snort and Bro, for example.

2. When is an analyst no longer an analyzer of data but an analyzer of dashboards?

This question also originates with my employment at an MSSP because like I said, we process so many disparate alert types and there is only so much time in a shift that it is challenging for an analyst to really spend quality time with a piece of data and conclusively determine what happened. Therefore the analysts evolve into analyzers of dashboards instead of data in order to promptly assess alerts and determine if there was a legitimate attack or not.


I would say you are an analyzer of dashboards when you cannot do the following:

  • Determine how a product generated an indicator

  • See the underlying activity that produced the indicator, whether it is network traffic or raw log messages

  • Research activity for which there is no indicator, i.e., you can only see indicators and not any activity for which an alert did not fire



3. If all you have is alert data, can you positively confirm that you have been compromised?

I know the answer to this one, but am including it for emphasis of the point that alert data alone does not lend itself to digital situational awareness. Alert data + session data is the bare minimum as far as I am concerned. At least with this combination you can observe the egress sessions, in other words, what did the attacker do next?


You are right. If you only have alert data, you cannot validate a security incident.

Thank you for your questions!


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

Contract BSD Associate-or-better FreeBSD Sys Admin

I am looking to hire a FreeBSD system administrator, with BSD Associate or better experience, for long-term contract work.

My team operates a small number of Network Security Monitoring (NSM) sensors running FreeBSD and open source tools. We plan to expand our sensor deployment from the low double digits to the high double digits, and perhaps the low triple digits.

The ideal candidate will be able to examine our current deployment and suggest improvements for our next generation NSM platform.

He or she will implement a simplified software installation process, with the idea that the NSM platform should be an in-house "appliance."

He or she must be able to properly select, configure, test, and maintain software deployed on FreeBSD.

The ideal candidate has experience administering large numbers of FreeBSD systems, with emphasis on keeping software up-to-date in a consistent and repeatable manner.

Although you will be working within the security team, the candidate does not need security experience. We are looking for system administration experience, although familiarity with open source security tools is a plus. We want a professional sys admin, rather than a security professional.

The candidate does not need to be located in the United States, but he or she must be fluent in English and comfortable working with a geographically distributed team. Preference will be given to qualified candidates who are willing to work in Cincinnati, Ohio (US).

If you are interested, please send your resume to taosecurity at gmail dot com.


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

Friday, January 16, 2009

Integrity Attacks Begin as Mistakes


Last year I wrote First They Came for Bandwidth, where I described a progression through three attack types:

  • First they came for bandwidth... These are attacks on availability, executed via denial of service attacks starting in the mid 1990's and monetized later via extortion.

  • Next they came for secrets... These are attacks on confidentiality, executed via disclosure of sensitive data starting in the late 1990's and monetized as personally identifiable information and accounts for sale in the underground.

  • Now they are coming to make a difference... These are attacks on integrity, executed by degrading information starting at the beginning of this decade. These attacks will manifest as changes to trusted data such that those alterations benefit the party making the change. This sort of attack undermines the trustworthiness of data.


The scariest part is the last attack can be the hardest to detect and recover.


I thought about this when I read this entry in the newest Risks Digest as Software glitch causes incorrect medication dosages:

Patients at VA health centers were given incorrect doses of drugs, had needed treatments delayed and may have been exposed to other medical errors due to the glitches that showed faulty displays of their electronic health records, according to internal documents obtained by The Associated Press under the Freedom of Information Act.

The VA's recent glitches involved medical data -- vital signs, lab results, active meds -- that sometimes popped up under another patient's name on the computer screen. Records also failed to clearly display a doctor's stop order for a treatment, leading to reported cases of unnecessary doses of intravenous drugs such as blood-thinning heparin.

According to interviews and the VA's internal memos, the glitches began after the VA distributed its annual software upgrade last August [2008].

By early October, hospitals began reporting the troubling problems: When doctors pulled up electronic records of different patients within 10 minutes of each other to offer treatment advice, the medical information of the first patient sometimes displayed under the second person's name. In some records, a doctor's stop order for intravenous injections also failed to
clearly display.


Ref: Veterans given wrong drug doses due to glitch (MSNBC)

The next step is intentional alteration of records.

If we think it's tough to maintain availability and confidentiality, wait until we security people are tasked with validating the integrity of data. It will happen after a celebrity dies or a group of "normal people" do, unfortunately en masse.


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

Thursday, January 08, 2009

Happy 6th Birthday TaoSecurity Blog

Today, 8 January 2009, is the 6th birthday of TaoSecurity Blog. I wrote my first post on 8 January 2003 while working as an incident response consultant for Foundstone. 2339 posts (averaging 390 per year) later, I am still blogging.

I don't have any changes planned here. I plan to continue blogging, especially with respect to network security monitoring, incident detection and response, network forensics, and FreeBSD when appropriate. I especially enjoy reading your comments and engaging in informed dialogues. Thanks for joining me these 6 years -- I hope to have a ten year post in 2013!

Don't forget -- today is Elvis Presley's birthday. Coincidence? You decide.

The image shows Elvis training with Ed Parker, founder of American Kenpo. As I like to tell my students, Elvis' stance is so wide it would take him a week to react to an attack. Then again, he's Elvis.

I studied Kenpo in San Antonio, TX and would like to return to practicing, along with ice hockey, if my shoulders cooperate!


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

Monday, January 05, 2009

Metasploit 3.2 on Windows XP

I've been an infrequent yet admiring user of Metasploit for about four years, but I've never tried it on Windows. It strikes me as being something I "just shouldn't do," like running Nmap on Windows or (shudder) Snort on Windows. However, while preparing labs for my upcoming class, I thought I would give version 3.2 a try. It worked very well, at least for the simple test I ran.

After installing the .exe and launching the new app, I saw this window:



I decided to try exploiting a vulnerable Samba server:



When I set the parameters I ran the exploit:



When I got my session I interacted with a root shell on the victim.



By identifying the process started on the victim (PID 2216) and running lsof, you can see the vulnerable service which Metasploit attacked.

Incidentally, my take on why having these sorts of tools available is In Defense of HD Moore, from three years ago.

Great work Metasploit team!


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

Recommendation for an Introduction to Unix

A regular blog reader asked me for recommendations on books to learn Unix, and which Unix to learn. I still remember asking my "Unix and Solaris Fundamentals" instructor in 1997 to recommend a book on Unix for me. I thought I would share my response here.

I think, as a beginner, you have to decide what you want to learn. I'll try to keep this description generic yet answer the reader's question. The person who asked the question requested an emphasis on the command line, rather than administration using GUIs.

As you might have guessed, I recommend trying FreeBSD. In fact FreeBSD 7.1 was released today. FreeBSD is a great OS for beginners, especially those who want to rely on the command line.

I am reluctant to suggest trying to learn a new OS without a good reference, but luckily a modern and thorough book arrived a little over a year ago. Michael Lucas' book Absolute BSD, 2nd Ed is probably the best pure introductions to Unix administration available. (I mean that of all the books out there, regardless of OS, Michael's book is the best, especially for beginners.)

Four years ago I posted reasons I like FreeBSD, if you want to see my overall thoughts on the OS.

After reading Michael's book, I suggest deploying services by reading Building a Server with FreeBSD 7
by Bryan J. Hong. Brian wrote a cookbook for building various servers on FreeBSD 7.x.

I don't recommend running FreeBSD on the desktop. I prefer my desktop to "just work," and I work in a GUI environment (although I tend to install software via command line anyway). I used to run FreeBSD on my laptop, but now I use Ubuntu. For me, Ubuntu "just works." I don't worry about anything. That's what I want in a more fluid environment like a desktop. PC-BSD is an option on the desktop, but I don't run it.

If you're more inclined to use Linux everywhere, then I suggest Debian on servers and Ubuntu on your desktop. The nice aspect of pairing these two is that Ubuntu is essentially Debian underneath. Ubuntu (or even Debian) is also more likely to be natively supported for many desktop applications, whereas FreeBSD might be a little less supported.


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

IPv6 Tunnel on Windows XP Using Freenet6

Almost two years ago I described testing IPv6 using Freenet6 on FreeBSD. This morning I decided to try the same on Windows XP and document the process here.

I needed to use a tunnel method like Freenet6 because the test host is behind NAT.

First, visit go6.net and click "Free IPv6 Connectivity with Freenet6". Register yourself a user account. To install on my Windows XPSP3 32-bit system I downloaded "Gateway6 Client 6.0-BETA4 Windows Installer 32-bit". I installed and accepted the defaults:



When I first tried installing the software I got an error which denied installing the TUN driver. I had to back out of the installation and change this local group policy key using gpedit.msc:



I changed "Do not allow installation" to "Warn but allow installation" under Local Computer Policy -> Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> Devices: Unsigned driver installation behavior.



Once The Freenet6 client was running I configured it with the username and password I registered, and I set broker.freenet6.net as my Gateway6 address. Once I connected I could visit ipv6.google.com, and even check my IPv6 address online.



You may notice I installed the ShowIP Firefox addon. I learned about that from Command Information. It's a good way to try to keep track of the IP address you're using to access IPv4 or IPv6 sites.

I was also able to access sites from cmd.exe, using ping6 to ping ipv6.google.com and ftp to connect to the IPv6-only FTP server at ftp6.netbsd.org.



I think the Freenet6 client is a good way for people behind NAT (or in the case of the test VM here, two NATs) to access IPv6-enabled sites.


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

Friday, January 02, 2009

BGPMon On Illegitimate Route Announcement

In November I posted BGPMon on BGP Table Leak by Companhia de Telecomunicacoes do Brasil Central. A lot of people saw that activity but the overall effect was negligible to nonexistent.

Yesterday I received a more personalized alert from BGPMon:

You Receive this email because you are subscribed to BGPmon.net.
For more details about these updates please visit:
http://bgpmon.net/showupdates.php

====================
WithDraw of More Specific (Code: 23)
2 number of peer(s) detected this updates for your prefix 3.0.0.0/8:
Update details: 2009-01-01 08:33 (UTC)
3.3.3.3/32
====================
Possible Prefix Hijack (Code: 11)
2 number of peer(s) detected this updates for your prefix 3.0.0.0/8:
Update details: 2009-01-01 08:31 (UTC)
3.3.3.3/32
Announced by: AS15475 (NOL)
Transit AS: 8452 (TEDATA TEDATA)
ASpath: 29073 9009 19151 4788 8452 15475

Checking WHOIS data for AS15475 shows:

% Information related to 'AS15475'

aut-num: AS15475
as-name: NOL
descr: Nile Online
descr: Giza,Egypt
descr: For any abuse complain contact abuse@nile-online.com

So, an ISP in Giza, Egypt announced a 3.3.3.3/32 route to the Internet. That looks like some kind of test. I used to be amazed to see a /32 route appear like this in global BGP tables, but now that I know most ISPs don't filter anything I am not so surprised anymore. Previously I would have thought one of the AS in the AS path would have filtered this.


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

Thursday, January 01, 2009

Predictions for 2009

I better get with the program and post my 2009 predictions before any more of the new year slips by. I plan to build on my Predictions for 2008 in Hindsight and add a few new thoughts.

  1. Expect greater government involvement in assessing the security of private sector networks. I wasn't inventing this a year ago, and I'm not inventing it now. I'm extrapolating from a trend line. My post Letters You Will Need to Know: 201 CMR 17.00 is just the latest example of increasingly aggressive government involvement in private sector security matters.

  2. Expect to start learning about IPv6, or be confused quickly. 2009 is not the year of IPv6, but we're getting there. The US Department of Defense is already grappling with IPv6, despite the compliance charade of mid-2008. Wider adoption of Microsoft Vista and its tunnel mechanisms, along with IPv6-active consumer devices, are driving IPv6 in one form or the other into our lives.

  3. Expect at least one cloud security incident to affect something you value. This is not the great Cloud Security blog, but I know many of us are already depending on cloud services. In 2007 and 2008 we started suffering denial when services suffered problems of availability. Next will be disclosure and then degradation. For more on these terms read First They Came for Bandwidth...

  4. Expect network security to matter again. I may be a little late on this one, given problems we had with DNS, BGP, and even SSL in 2008. I think these sorts of problems demonstrate that there's lots of vulnerability left outside the platform, operating system, and applications. As IPv6 becomes more important this one is going to the top of the list, probably in 2010.

  5. Expect to buy fewer "new" security products. We need to get back to basics by answering the sorts of questions that appeared in my post Marcus Ranum on Network Security. In tough economic times, managers are not going to spend on new equipment if they still don't know what the stuff you just bought does. Spend more time on consolidation and specialization and less time on looking for the next security silver bullet.


Good luck in 2009 everyone. It's going to be a good year -- "fine in '09"!


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

Predictions for 2008 in Hindsight

In late 2007 I posted Predictions for 2008, my first foray into the world of prognostication. I'd like to review what I said to see how those ideas panned out.

  1. Expect greater government involvement in assessing the security of private sector networks. This is happening but not to the extent I expected. I predict more of this in 2009.

  2. Expect greater military involvement in defending private sector networks. This also started to happen, as noted in my post Predictions Panning Out. I now think this point will happen more slowly than #1.

  3. Expect increased awareness of external threats and less emphasis on insider threats. I nailed this one. In my posts More on 2008 Predictions and Insider Threat Prediction Materializing I documented several cases. Looking to a recent Jeremiah Grossman post as well, I doubt all those Web app hackers are insiders!

  4. Expect greater attention paid to incident response and network forensics, and less on prevention. You can't expect people to stop thinking about prevention, but detection and especially response are huge right now. Check out the results of the SANS coolest security jobs survey. IR and forensics are at the top.

  5. Expect talk of an "IPv6 gap," especially with respect to China. I missed this one. I really expected the Chinese to brag about their IPv6 network and for our politicians to push for some kind of upgrade to "catch" them. I wonder if President Obama will advocate IPv6 as part of his Internet infrastructure initiatives?




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