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.

Read More

SANS WhatWorks in Incident Detection Summit 2009 Web Site Active

The Web site for the SANS WhatWorks in Incident Detection Summit 2009 is live. I created a rough agenda to provide an idea of the structure of the two-day event. I am still working on speakers but I will probably have too few slots to accommodate all the people I would like to appear! As I secure speakers for the event I will submit them to SANS so they can update the Web site.

The registration link is also active.

Thanks to those of you who posted thoughts to my earier blog post. I also created a twitter.com/sansincdet account, so feel free to post ideas there too.

Read More

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.

Read More

Renesys Blog on Routing Vulnerabilities

I've been writing about the routing infrastructure monitoring company Renesys for several years. James Cowie's post Staring Into the Gorge contains some real gems:

Here We Go Again.

Imagine an innocent BGP message, sent from a random small network service provider's border router somewhere in the world. It contains a payload that is unusual, but strictly speaking, conformant to protocol. Most of the routers in the world, when faced with such a message, pass it along. But a few have a bug that makes them drop sessions abruptly and reopen them, flooding their neighbors with full-table session resets every time they hear the offending message. The miracle of global BGP ensures that every vulnerable router on earth gets a peek at the offending message in under 30 seconds. The global routing infrastructure rings like a bell, as BGP update rates spike by orders of magnitude in the blink of an eye. Links congest. Small routing hardware falls over and dies. It takes hours for things to return to normal...

At 17:07:26 UTC on Monday, CNCI (AS9354), a small network service provider in Nagoya, Japan, advertised a handful of BGP updates containing an empty AS4PATH attribute...

This one seems to have bitten Cisco's IOS XR, a relatively newborn "from scratch" rewrite of the venerable IOS, destined to run on big iron, like the CSR-1 or the 12000 series...

The global mesh of BGP-speaking routers that we call the Internet has inherent vulnerabilities that stem from the software quality and policy weaknesses of its weakest participants, and the amplification potential of its best-connected participants. Running sloppy software at the edge of the routing mesh (in enterprises, say) is unlikely to give anyone the ability to propagate large amounts of instability or partition the Internet. But closer to the core, I think we have a serious problem to contemplate.

Remember, if you can get just one provider to listen to you, and not filter your announcements, you can get your message into the ear of just about every BGP-speaking router on the planet within about thirty seconds. And if some subpopulation of those routers can be reset, they act as amplifiers for your instability. Power law outage-size distributions are not a myth — they are a logical consequence of the structure of the Internet, the importance of a few key participants in carrying global traffic, and their reliance for interconnection on technologies that are clearly still in the shaking-out-the-obvious-bugs mode.

So that is really cool. I liked the following too:

I was at USENIX last week, and sat in on a great workshop on security metrics, where Sandy Clark gave a somewhat controversial presentation on the interaction between software quality and the timing of exploit appearances...

[O]ne of the strongest predictors of a significantly large time to the emergence of the first zero-day exploit for a new version of software is the degree to which the release represents a substantial rewrite of the code. Doing a rewrite seems to start a "honeymoon period," during which time the system in question is safer from exploitation than it has been in a long time. In fact, the magnitude of the protective effect is so significant, that you might ask yourself whether a dollar spent in pursuit of higher quality code is actually better spent rewriting the code periodically, to whatever quality standard you can achieve.

That sounds like an argument for diversity to me. Writing new software introduces diversity, and the attackers have to decide if they want to spend resources to understand the new target sufficiently to exploit it.

Read More

New Must-Read Blog Series from Mike Cloppert

Mike Cloppert has started a series of posts on security intelligence on the SANS Forensics Blog. Part 1 includes multiple worthwhile definitions, and Part 2 follows with a great, correct explanation of risk and its components. Keep your eyes on his section of the blog for at least three more posts. Awesome work Mike.

Read More

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.

Read More

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.

Read More