Secure Internet Firewalls With OpenBSD (tutorial)
This half-day talk will cover the details of setting up a secure firewall using
After an overview of OpenBSD installation and administration and why it's
the presenter will cover standard services, network security, firewall
configuration, packet filtering,
routing, bridging, Kerberos, SSH, VPN using manual and automatic keying,
address hiding with
NAT, logging, intrustion detection, and ongoing maintainance. OpenBSD has its
filtering with many features including packet sanitization, which will be
covered in depth.
The talk is aimed at people with any UNIX/Linux (not necessarily BSD)
and who are e.g., comfortable with vi/emacs for editing config files, not
dependant upon some
window-based tool :-). The details of the presentation will be adjusted to the
in attendance, not vice versa.
Hans van de
Looy and Brenda Langedijk,
Using the FreeBSD ports collection to
perform network forensic analysis (tutorial)
This tutorial will be a real hands-on interactive do-it-yourself
session. So those of you who do not want to really participate and train
your skills, stay at home or (better still) join another tutorial.
The presenters will first talk a bit about forensic research and discuss
some tools that are available out there (focusing on open source
variants). After that "brief" introduction they will provide you with a
case ready for analysis. The organisation will provide access to a local
area network and hopefully access to a local ftp server and the Internet
as well. This way you will be able to download and install tools on your
(we really hope FreeBSD although another OS could be used as well)
system, that you will use to analyse the data provided. During the
session the presenters will give you hints and try to help you progress.
The goal of the session is to give the audience some insight into
forensic research and a real feeling for the kind of difficulties you
will encounter while searching for clues, trying to build your case.
FreeBSD GEOM (tutorial)
The new DARPA sponsored GEOM subsystem adds pluggability and
modularity to disk I/O manipulations. This for the first time
provides an UNIX operation system with an modular and extensible
facility for manipulating disk-access requests. Amongst the things
which can be seamlessly integrated using GEOM are disk-partitioning,
RAID facilities, cryptographic protection. This tutorial will
provide an overview of the architecture and implementation, as well
as the tradeoffs and choices made.
Device Drivers (tutorial)
No abstract submitted.
BSD: Past, Present and Future
Virtual Private Networks using FreeBSD - a
People want to, for more than one reason, work at home, sharing information
from the corporate network. Companies want to link their networks together
over the internet. But nobody wants their private traffic to be readable on
the internet. Various solutions have been made, and one of them is IPSec.
IPSec stands for 'IP Security'. It provides authentication and encryption
of networktraffic. But there's more to secure your data. It makes no sense
to encrypt your data and have your endpoint compromised. Thus a firewall is
needed as well. On both ends. And some more issues to cover.
This little piece of paper shows us how FreeBSD can help us with this. All-
though there are some differences between the various BSD's, it will
reasonly apply to Open- and NetBSD as well.
and Henning Brauer,
Running and tuning of OpenBSD network servers in a
Heavily loaded network servers can experience resource exhaustion. At
best, resource exhaustion will slow server response, but left
uncorrected, it can result in a crash of the server.
In order to understand and prevent such situations, a knowledge of the
internal operation of the operating system is required, especially how
memory management works.
This paper will provide an understanding of the memory management of
OpenBSD, how to monitor the current status of the system, why crashes
occur and how to prevent them.
Experienced network administrators and interested kernel hackers.
Good knowledge in the TCP/IP suite, basic understandig of memory
management under UNIX and basic understandig of an UNIX kernel.
Xperteyes - keeping your system under control
How would life change if you had every morning some lists of points where
your computers would fail the criteria set by the system administrators,
their boss, the EDP-auditor and the software manufacturers. So if you had
yesterday installed a powerful tool for managing your network, today you
would notice that the install log (owned by root) has mode 07777. Or if a
user leaves the company, a check is performed that his account is also
removed from the database, and his name is removed from the cron users.
With this new tool, xperteyes, this is easily possible. In some minutes all
relevant properties of many objects are read and stored. In a separate step
(which may be performed on another machine) all these properties can be
checked through a configuration script, which will take also a few minutes.
Naturally, a graphical interface is available for viewing the properties,
the checks and the results. The results can also be viewed in HTML. For the
more daring system administrators it is possible to (automatically) repair
some of the properties.
The tool is currently running on Mac OS X, Linux and Windows, implemented
in Python with some extensions in C. The main object's properties that are
- the properties of files, directories and other objects in the file
- /etc/passwd, /etc/group, etc.
- the windows registry and the windows user/group/machine database
- the Mac OS netinfo tree
But, if you want to check later on e.g. file magic, such extensions can be
implemented in less than one hour, depending on the amount of code that can
The checks that may be performed are partly predefined. These are simple
checks like checking that a single property has a predefined value, or its
value belongs to some range. More complex checks, like is_hardlink or
uid_valid are also available. And comparing objects collected at different
times or from different systems is possible. But it is likely that these
checks are not enough. If you add the file magic to your object's
properties, you want to check it. Well, you can easily define new checks
yourself, once you have formulated them (that's the difficult part).
Some areas where this tool can be deployed are:
- Checking, initially and daily, the configuration of one system
- Checking the effect of (un)installing some packages
- Keeping two systems "identical" (clustering)
Package views - a more
flexible infrastructure for third-party software
Firstly, conventional systems for installation of third party software,
including FreeBSD's ports system, NetBSD's pkgsrc, and OpenBSD's ports
system, are analysed and compared. In addition, other approaches and
infrastructure layouts within the industry are examined.
One of the main problems faced by users of the various systems is the means
by which multiple versions of a package, or packages which "conflict" with
each other, can be installed at the same time.
Following that, a new system is proposed, which has been implemented in
NetBSD's pkgsrc implementation:
- to allow any number of different versions of packages to co-exist
at any one time
- to provide support for dynamic packing lists
- to allow the testing of different versions of packages on a single
machine at any one time
- to allow more dynamic conflict detection at install time
- whilst continuing to use the existing pkg_install(1) tools
The new system is laid out in detail, including the practical aspects of
managing a large number of third party packages across a number of
different Operating Systems, all within the same pkgsrc framework.
The advantages and disadvantages of the new infrastructure are discussed,
as are the lessons learned from its deployment.
In last year's Regensburg city marathon, each of the 5000+ runners was able
to view a personal video of him/herself reaching the goal. A cluster of 45
machines running the NetBSD operating system turned
5 hours of video material into single mpeg snippets.
Topics discussed in the presentation are:
- deployment of the operating system and applicationi software on the
- details on the tasks performed by the cluster - decomposing the
input mpeg stream(s), reassembling images for each runner based on the time
he went through the goal
- experiences gained during the cluster project - application based,
plus lots of graphsand images from monitoring the cluster
- facts & numbers - lots of them :)
Before describing how NetBSD uses cross compilers to build the system, I
will discuss more traditional users of cross compilers, which largely is
the embedded software group (I will focus mainly on the ports of the FSF
tools.) NetBSD is changing, or perhaps only adding to this, as a
significant portion of commercial NetBSD users are using embedded
A large majority of NetBSD 1.6 snapshots and releases will be built via
cross compiled methods, theoretically buildable on nearly any modern
platform, using a simple-to-use cross-build system, nominally called
"./build.sh", that has been developed by the NetBSD project, to make it
possible to build NetBSD releases with a single, simple command. I will
discuss the pros and cons of this approach, many of which are true of every
cross compile environment. I will compare the NetBSD 1.5 and NetBSD 1.6
release processes, explaining the autobuild process used by the 1.6 release
team to build virtually daily snapshots of all cross buildable ports.
Monitoring the world with NetBSD
There are many papers and publications on monitoring your network and
systems. Most of the time they fail to present a monitoring strategy that
is both practical and general. Whilst I don't wish to restate what is
already generally known, I do feel that most sites are lacking in a really
solid monitoring framework.
At my current site and at previous locations, I have used NetBSD along with
a range of free tools to build a customized system for proactive
notifications and failure management. I would like to talk about the
evolution of this system over the years, the decisions I took and why I
took them, ending with a look at the current deployment and some thoughts
for the future.
My aim is to try and present advice that folks can take back and drop into
place at their sites with a very minimum implementation time and be getting
a meaningful return very quickly. I want to distill a lot of different
documentation into a set of notes that people can use almost as a set of
design philisophies along with the practicum.
and precise timekeeping in SMP kernels
The FreeBSD timecounters are an architecture-independt implementation
of a binary timescale using whatever hardware support is at hand.
The timecounter timescale converts to other time representations
using cheap multiply and shift operations and provides for sufficient
precision and resolution to cater for all future needs.. The math
and implementation will be described, including the features which
support NTP PLL/FLL time synchronization, lockless multi-cpu operation
and on-the-fly change in hardware support.
MTA Performance on *BSD: Sendmail,
Postfix and Exim on (Free|Net)BSD and MacOS X
Three popular SMTP Message Transfer Agents (MTAs) will be tested on three
different implementations of BSD Unix. Standard performance tuning
enhancements will be made and benchmarked for comparison on all
three platforms. Details regarding hardware, OS, software, and testing
configurations will be provided, including selections of configuration
files, selections from sample test runs, etc....
The MTAs to be tested are sendmail (open source, see
<http://www.sendmail.org/>), postfix (see <http://www.postfix.org/>), and
Exim (see <http://www.exim.org/>). The OS platforms to be tested are
FreeBSD (see <http://www.freebsd.org/>), NetBSD (see
<http://www.netbsd.org/>), and MacOS X (see
<http://www.apple.com/macosx/>). The testing tools will most likely include
SPECmail2001 (see <http://www.spec.org/osg/mail2001/>), Postal (see
<http://www.coker.com.au/postal/>), mstone (see
<http://www.mozilla.org/projects/mstone/>), and smtpsink/smtpstone (from
postfix, see <http://www.postfix.org/>).
Complete charts and graphs will be generated, and conclusions regarding the
relative performance of each MTA relative to each OS will be presented.
Directions for future testing will also be presented.
Note that no testing of anti-spam or anti-virus features will be attempted.
Also note that different machines will be used for each OS, and therefore
test results across OSes are not likely to be comparable.
Finally, note that OpenBSD is not being tested, partly for reasons of
expediency and partly because the author believes that it is not likely to
perform radically different than NetBSD in this application.
Securing syslogd on FreeBSD
For its complete life span, FreeBSD, it has used the de-facto standard of
Logging: syslog. The syslog concept is clear, flexible and sound. And, as I
may say, FreeBSD implementation is old, but alive. Recently however, the
syslog-protocol is formally defined in RF3164. An IETF has done so, to be
able to define some security extensions on top of it. Two extensions exist,
on paper: syslog-sign and syslog-reliable. To update FreeBSD implementation
to this standard, and to implement the security extensions is work in
Although the FreeBSD implementation of syslog(d) has more security-options
then most commercial counterparts, faking syslog, as it is based on UDP, is
simple. Several kind of attacks are know; e.g. replaying normal system
messages, after it is taken down by a hacker. With syslog-sign, a digital
signature is calculated of each message. And by sending a set of those
signatures as one normal syslog message afterwards, syslog-sign can detect
and signal most attacks. Even when somebody does change the logfiles on
disk it is impossible to change them unnoticed, as the signatues befome
false. Furthermore, I would like to emphasise the possibility of
intermixing it with other/historical syslog implementations! And, as
FreeBSD has always been a secure platform which can bridge with other
systems, implementing syslog-sign will keep FreeBSD on the leading edge.
The author has used FreeBSD's implementation of syslog, to assure the
standard indeed describes "the actual average protocol on all NIX'en". And
has started a project to updating FreeBSD implementation, to make a 100%
match possible. Based on that, several security enhancements will be
implemented soon. The design and implementation of syslog-sign will be
presented. As are others extensions, like a kerberos'ed version of syslog
which is under study.
By implementing security-enhancements that are based on standards, instead
of just changing the code, will improve the functionally of syslog and make
it secure. But it also helps FreeBSD to continue the history of
BSD-Unix. It does follow the standard, or it makes it. When FreeBSD adopts
the security-enhanced syslog protocols quickly, it's implementation of
syslog will continue BSD's preferred method of logging for another decade,
Using SCTP with Partial
Reliability for MPEG-4 Multimedia Streaming
SCTP (Stream Control Transmission Protocol) [1,2], is a new IP transport
protocol. It is reliable and connection-oriented as TCP, but has a set of
new features that make it well suited for a wide class of applications,
among them multimedia streaming. SCTP is record-oriented, providing
built-in framing capabilities, and can multiplex multiple data streams into
one connection, thus avoiding head-of-line blocking and providing a natural
framework for multi-streamed systems like MPEG-4. It can provide ordered
or unordered delivery. Further, a sender that implements Partial
Reliability SCTP (PR-SCTP) can optionally choose the retransmission
behavior on a per packet basis, in a continuos spectrum from TCP-like
reliability with multiple retransmissions to UDP-like unreliability with no
retransmission at all. In any case PR-SCTP retains all the benefits of
SCTP: TCP-friendly congestion control and congestion avoidance, plus
multi-homing fail-over capabilities.
The MPEG-4 standard is becoming a popular format for streaming multimedia
on the Internet. MPEG-4 encodes the bitstream in groups of different frame
types (I, P and B-frames), where the I-frame is independent, while the P
and B-frames depend on the I-frame in the group. This means that loosing
an I-frame (for example due to network congestion) forces the player to
skip to the next frame group, with a noticeable worsening of the video
quality. The transport protocol utilized by MPEG is RTP, which in turn is
layered on top of UDP. RTP, being concerned with real-time traffic like
multimedia streaming, does not provide reliable delivery.
Lately an implementation of SCTP has been imported in the IPv6/IPsec stack
developed by KAME, providing kernel-level SCTP for all *BSD flavours .
This paper describes our work on FreeBSD to modify the open source MPEG-4
streamer and player found in MPEG4IP  to utilize PR-SCTP as transport
instead of RTP/UDP, enforcing differentiated Partial Reliability per frame
type. Various congestion scenarios show the improved playout quality of the
client player, due to the increment of the number of I-frames that PR-SCTP
allows to salvage from congestion.
 RFC 2960.
All For One Port, One Port For All
The BSD systems each offer a different ports system. FreeBSD has the
largest number of ports, OpenBSD ports provide a few extra features and
NetBSD uses pkgsrc. Even though these ports systems originate from the
same root, enough changes have been included to make them incompatible.
The result is that a port has to be written and maintained for each BSD
variant. The number of ports available greatly depends on the willingness
of someone to create and maintain a port while a lot of work is repeated
over and over again by the different maintainers. Obviously this is an
One serious attempt has been made to reunite the ports systems:
OpenPackages. Unfortunately, this project has stalled. There are several
reasons why this route is very unlikely to succeed. The main one is that
none of the BSD distributions wants to switch to a different system that
suddenly makes all their existing ports unusable. Political and personal
preferences add enough controversy to make any attempt at merging fail.
An alternative is to introduce a new system that exists next to the
traditional ports systems. This provides the possibility for a gradual
shift towards a better solution. One by one the ports can be transferred
to this new system. There is no risc of making existing ports obsolete.
Each maintainer is free to stick with the traditional system or choose to
start using the new one, with the advantage of providing the port for all
BSD systems at once.
The A-A-P project is providing this solution. A-A-P uses a recipe that is
similar to the structure of a makefile, but much more powerful and
flexible. A recipe is easier to understand than the tricks a port includes
to use "make" for something it wasn't designed for. One of the strong
advantages of A-A-P is that it handles the details of the packaging system.
This is important, because many developers have expressed they are
struggling with packaging their application. A-A-P takes care of
downloading required files and tools, thereby avoiding the need to edit a
script and run "cvsup". This is quicker and more reliable. Many ports
done with A-A-P will also work on Linux and other Unix-like systems.
Further advantages of using A-A-P for ports will be explained, while the
disadvantages and potholes will not be concealed.
Advanced VPN support on FreeBSD systems
Currently, the VPN support offered by FreeBSD is quite limited: it provides a
way to establish tunnels but it does not consider the problems of multiple
VPNs concurrently deployed on the same machine. Our implementation enables the
provisioning of VPN services on FreeBSD by extending its routing capabilities.
Primarily, our implementation provides support for multiple IP routing tables
(one for each VPN) in order to avoid conflicts between overlapping address
spaces of different VPNs.
User-space programs (route, zebra, etc) can select the proper instance when
accessing/updating a routing table through a modified routing sockets
interface. At the kernel level, the different VPN flows are identified on
per-interface basis. Once a packet is recognized as belonging to a given VPN,
the forwarding routine selects the proper routing table to look up. We also
modified several user-level applications to allow the exploitation of the new
routing infrastructure, such as "route", "netstat", "zebra", and "ifconfig".
Authentication in FreeBSD 5.0
Over the past year, support for advanced user authentication in FreeBSD has
grown considerably through the systematic integration of PAM in almost all
authentication-related utilities. Administrators can now choose from a
wide variety of both software- and hardware- based authentication methods
for both local and remote access. In the course of this presentation, we
will discuss and demonstrate a selection of these methods and the ways in
which they can be put to fruitful use.
A shared write-protected
NFS root file system for a cluster of diskless
Managing three diskless network clients can be done manually. Manually
managing ten is still possible, but tedious. Manually managing hundreds is
close to impossible.
When we got ten disk- (and head-)less network computers of a new type that
we wanted to use as computing nodes for a parallel virtual machine for a
practical course, I decided to set them up with a shared root file system.
However, a BSD root file system has to be unique and writable for every
client machine for a couple of reasons (for example to write log files,
create communication sockets for some daemons, set device node ownership at
login and logout and change timestamps), so that a single writable shared
root file system does not work.
As an alternate solution, I placed most writable directories onto (virtual)
memory file systems. The program area and configuration files need only to
be exported by the server for read only access. This way, the system
programs, system libraries, and the configuration are protected against
malicious users, even if they should gain root
privileges on the client machine.
This presentation elaborates on the problems I encountered and the
solutions I implemented, using stock NetBSD 1.5 as the client operating
system, with just a small script and a few configuration lines added.
Finally, I compare my solution to different possibility, namely using a
kernel embedded root file system.
Using BSD for current and next
generation voice telephonyservices
This presentation will cover how to use GNU Bayonne with BSD related
operating systems, including particularly FreeBSD and NetBSD, which are
what I am most familiar with. A presentation of issues related to
telephony drivers and voice telephony hardware support for BSD and what is
needed to make voice telephony services work under BSD will be provided.
During this presentation I will introduce the telephony application server
of the GNU Project, "GNU Bayonne". This presentation will cover what GNU
Bayonne is and how it fits into the overall strategy of enterprise and
carrier class telephony solutions for current and next generation IP based
telephone networks using free software running on free operating systems,
such as xBSD systems, GNU/Linux, etc.
GNU Bayonne is composed of three servers and each of these (Bayonne,
Olorin, and Babylon) will be discussed in detail, including their
architecture and how to configure, operate, and create applications for GNU
Bayonne servers to produce real-world telephony solutions for xBSD
operating systems. The scripting language of GNU Bayonne will be covered,
as well as how to integrate GNU Bayonne servers with traditional scripting
languages such as tcl, Perl, Python, and Guile.
GNU Bayonne will also be demonstrated live running under FreeBSD (4.5) as
part of this presentation. Examples and scripted applications used for
real world applications people can deploy using GNU Bayonne under xBSD,
such as voice mail and debit calling, will also be demonstrated.
Porting NetBSD to JavaStation-NC
This paper summarizes experience in porting NetBSD to JavaStation-NC, a
network computer class machine built on the microSPARC-IIep processor.
microSPARC-IIep is a sun4m with an integrated PCI controller. This makes
it unique amongst sparc32 systems as other sun4c and sun4m models are SBus
based. It is sufficiently similar to
sun4m to reuse a lot of the existing code and sufficiently different to
require a non-trivial porting effort. Generic and flexible
machine-independent infrastructure and drivers provided by NetBSD were
crucial to completing the port in short time despite the author's lack of
any previous experience with NetBSD kernel internals.
Low-level support for CPU timers, interrupt related code and the like was
implemented. Existing memory management code for sun4m was directly
applicable. OpenFirmware support in the kernel and the boot loader,
already borrowed from the sparc64 port but never tested, was completed.
After machine-dependent parts of PCI framework were implemented, the driver
for Happy Meal Ethernet was available for free. EBus support was borrowed
from the sparc64 port, though differences in OpenFirmware prevented sharing
of the EBus driver proper, but sparc and sparc64 can share drivers' EBus
attachment code. The driver for CS4231 audio was reworked to support EBus
attachment and is shared with sparc64.
Existing sparc framebuffer, keyboard and mouse drivers don't support the
NetBSD machine-independent Workstation Console subsystem yet, but for the
JavaStation-NC with its PS/2 keyboard and mouse using Workstation Console
code was a natural choice, only the framebuffer driver had to be written.
driver for the InteGraphics Systems IGA1682 video card was developed and
the plan is to support the CyberPro2010 card in this driver as well, thus
providing a framebuffer driver for NetBSD/netwinder.
More work on the IGS driver is required to support acceleration and other
models of InteGraphics cards. The Xigs server from XFree86 that currently
supports only CyberPro 5050 seems like an ideal starting point for X
support, though no work has been done yet.
Support for other microSPARC-IIep based systems would be nice, but requires
access to the hardware. Besides several esoteric JavaStation prototypes
the other widely available machine based on this processor is the CP1200
Compact PCI board. The same processor is also used in the SunRay
appliance, though feasibility of SunRay support is questionable due to
firmware issues and extremely small memory.
MacOS X on a budget
Many BSD users may have an interest in Mac OS X, but cannot justify buying
a new Macintosh computer. They need a solution for a tight budget.
The presenter has previously demonstrated Mac OS X running on a home-built
system, constructed mostly from old parts, with a total parts cost of EUR
600. The presenter has built several such systems, including a server which
cost EUR 300 in parts. While it is not difficult to create a Mac OS X
installation on a system not supported by Apple, there are numerous traps
and gotchas to avoid.
This session describes the process of creating a Mac OS X system on a
- What processors and motherboards are supported?
- What disk configurations are needed?
- Which peripherals work and which don't?
- What software is needed for unsupported systems?
- How much will it cost?
- Which second-hand systems give best results?
... and so on.
FreeBSD Network stack virtualization
General-purpose operating systems, such as UNIX variants and clones,
traditionally maintain a single instance of each supported network protocol
family within the kernel network stack. However, the capability of
simultaneously supporting multiple independent instances of network stack or
protocol suite can be highly desirable in many applications, such as VPN
provisioning, virtual hosting or network simulation.
This session will provide an overview of design, implementation and
performance aspects of an experimental framework for FreeBSD network stack
virtualization. It will be explained how various parts of existing kernel
code were extended to support grouping of network interfaces and user
processes in isolated entities called virtual images. Further, it will be
described how basic CPU resource usage scheduling and accounting on per
virtual image basis was implemented, and finally, the
methods for managing and monitoring the virtualized kernel infrastructure
will be presented.
As the virtualization framework was implemented entirely within the kernel
while retaining the complete API/ABI compatibility with the existing
userland binaries, this session will be especially interesting for kernel
hackers. However, system administrators will also have the opportunity to
learn about a new approach for partitioning system resources, particularly
on the network layer.