STATUS: Subject to change
|Bob Beck||PF, it is not just for firewalls anymore *and* spamd - spam deferral daemon|
|Corey Benninger||A Beginner`s Guide to Security with Ruby on Rails in BSD|
|Jason Dixon||BSD Is Dying - A cautionary tale of sex and greed|
|Kristaps Johnson||BSD Virtualisation with sysjail|
|Johnny C. Lam||The "hidden dependency" problem.|
|Bjorn Nelson||A Build System for FreeBSD|
|Marco Peereboom||Bio & Sensors in OpenBSD|
|Brian A. Seklecki||A Scalable Framework for Compact Flash Booting NetBSD Network Appliances|
|Murray Stokely||Challenges that we face at Google|
|Russell Sutherland||Back to the Future: BSD on the Edge of the Enterprise|
|Wietse Venema||Postfix as a Secure Programming Example|
|Jason Wright||OpenBSD on sparc64|
Speaker bios and talk topics details
Bob Beck has beein working with and hacking on unix since his undergraduate days. He has been involved in OpenBSD ever since an unsuccessful attempt to buy Theo de Raadt a pizza in 1995. Bob has a consulting company based in Edmonton, Alberta, Canada that deals with all things fun and profitable in computing, security, and training, as well as a day job at the University of Alberta where he brings many pieces of written code into practical use.
Bob Beck runs a bunch of big central services at the University of Alberta. Many of these (and his preference) are set up to scale as simple clusters of small machines. Many of these use pf with carp and pfsync as front ends for load balancing and redundancy.
This talk goes over various options and configuration of pf for building large scalable services set up for redundancy and failover. It also demonstrates several examples of large scale services set up in this way.
Spamd is a small, non-forking minimal smtp implementation used for spam deferral. It can be used both to blacklist connections to a tarpit for known spam sources, or greylist smtp connections from previously seen MTA`s.
Like many common greylisting implementations, spamd will greylist based the incoming tuple of connecting IP address, envelope-from, and envelope-to addresses. Unlike many other greylisting implementations, spamd uses the packet filtering mechansims in pf to control the greylisting of mail connections, and whitelists known MTA`s, once seen.
This talk covers spamd, its implementation, its use for greylisting and its impact on production mail services, as well as some examples of tricks which can be used to improve its spam stopping abilities.
Corey Benninger, CISSP, is a Security Consultant with Foundstone, a division of McAfee, where he commonly performs web application assessments for leading financial institutions and Fortune 500 companies. He also is involved with teaching Ultimate Hacking Exposed courses to clients throughout the United States. Prior to joining Foundstone, Corey worked on developing web applications for a nation wide medical tracking system as well as infrastructure applications for an internet service provider. He has spoken on security topics at BlackHat and the NYC local OWASP chapter.
Ruby on Rails is rapidly becoming the choice for developers looking to quickly write web applications. This presentation will take a look at the security aspects of Ruby on Rails. It will cover common deployment and programming considerations with a focus towards deployment on BSD platforms. The goal is to help first time Ruby on Rails users understand the security concerns of common configuration, deployment, and programmatic features.
As the principal of DixonGroup Consulting LLC, Jason Dixon focuses on solving real-world security and infrastructure challenges with free and open source software. Like any good administrator, he gravitates towards software that makes his job simple. In particular, much of his work has focused on secure networking and application development using Open Source projects like those distributed under the BSD license.
A tongue-in-cheek look at the history and future of the BSD movement. Modeled after the presentation styles of Lessig and Hardt, the talk provides a light-hearted introspection of the leaders, technologies, and community that forges ahead despite having been left for dead some 15 years past.
I work privately and academically in computer science and mathematics, systems and theory: as a researcher for the Institute of Mathematics and Computer Science of the Univ. of Latvia, mainly in distributed theory and machine intelligence; for a small business, Gradient Inc, in security and distributed systems; and for the bsd.lv open source projects. On weekends, I work as a bouncer at a club in Riga.
Lightweight system virtualisation is a valuable tool. Administrators may cordon vulnerable services requiring privilege; ISPs may provide their customers root-control over full system installations; operators may test products that require a network of like applications, without needing multiple physical machines; and so on.
We present sysjail, a virtualiser for OpenBSD and NetBSD built entirely in user-space. sysjail provides near-equivalence to FreeBSD`s jail using the systrace device to intercept and filter relevant system calls and chroot to provide a file-system barrier. Like jail, it may run standalone applications or full system installations. Unlike jail, it is based entirely in user-space with a backing library designed for system extension.
In this talk, we hope to demonstrate the flexibility of sysjail in normal environments, and the future of sysjail as providing many heterogeneous system types (via compat) on one host, all centrally managed.
Johnny C. Lam is a full-time BSD system administrator for several small NYC businesses. In his spare time, he is a senior pkgsrc developer whose main area of work is improving the portability and the capabilities of pkgsrc. He has been directly involved in pkgsrc development since 1999, and he has organized two pkgsrcCon conferences in Europe to promote a better understanding of pkgsrc infrastructure development within the developer and user communities. In his extra-spare time, he plays Ultimate.
Suppose you install OpenSSL, build and install Mutt, then later remove OpenSSL -- should running "mutt" still work? Not if the mutt binary is linked against the OpenSSL libraries. What if you built Mutt and didn't even know it used SSL at all? What if you didn't even want SSL support in the first place?
This is the "hidden dependency" problem which affects all package management systems which build and install from sources. In the example, Mutt has a dependency on OpenSSL which you may not even know existed, and only because you built and installed OpenSSL before Mutt. I will present some approaches to solving this problem, as well as the way taken by NetBSD`s pkgsrc using a mixture of package options and the (in)famous buildlink/wrapper framework. I will also present ideas for development of a new wrapper system for pkgsrc that will also be suitable for use in other package management systems, e.g. FreeBSD Ports.
Bjorn Nelson is currently working at Morgan Stanley as an Integration Engineer. Currently working on completing an Undergraduate Degree at Baruch College in Statistics, Bjorn has become really interested in the world of Statistics and is trying to find new ways to apply this to the world of computers. When a log file is not present or other methods run dry, Statistics can step in to find trends, correlations, and explained variation helping one to get to an answer.
Bjorn Nelson will be providing a overview of a FreeBSD Build System, put together at Baruch College while working there. This implementation of a FreeBSD Build System results in being able to reinstall or upgrade an entire FreeBSD Base OS in under ten minutes. There are some management and security implications of this that will be gone over as well as some tweaks that were realized of the standard FreeBSD Build System. Some of these tweaks concern building multiple kernels simultaneously, optimizing mergemaster by using RCS, and fetching multiple distfiles in parallel allowing for individual failures. This presentation is not necessarily a new technology but rather one implementation based on observations and building on what works. Many attendees may have ideas and experiences in certain areas which are encouraged to be shared.
Marco Peereboom got involved with Open Source UNIXi in `96. After years of patching and hacking he decided to look for alternatives that suited his needs better and became interested in the OpenBSD project in 2001. After working on fixing up the SCSI mid-layer and working on mpt(4) he ended up as a committer on all things SCSI. He now works all over the tree scratching whatever itches.
He works for a large computer manufacturer in central Texas as a Sr. engineer where he has held several software and hardware development positions. His work has been concentrated on a wide range of server and storage products. In his spare time he enjoys hacking the OpenBSD kernel around a busy social schedule.
The talk will touch on complexities inherent to dealing with RAID and how OpenBSD solved these problems. The bio framework seamlessly integrates RAID management into the core operating system by reusing existing APIs and tools.
RAID management is often considered black magic by users and IP by hardware vendors. This talk will try to chip away at that notion by demonstrating, with working code, that server management issues are mostly self induced.
Brian A. Seklecki is a system and network administrator at Collaborative Fusion, Inc. in Pittsburgh, Pennsylvania, US. When he is not hard at work pushing his open source agenda or contributing time to The NetBSD Foundation answering questions on mailing list, news groups, #NetBSD on EFNet IRC, writing documentation, submitting bug reports, and testing new code, he can be found mountain biking in Western Pennsylvania in even the worst of weather conditions.
BSD has long served as the reference platform for many new networking technologies. The first implementations of TCP/IP were developed on BSD and BSD led the way on Ipv6 development. NetBSD set the Internet2 Land Speed World Record. Today BSD has the most robust, stable, secure TCP/IP stack of an F/OSS operation system. BSD development models and practices are the watchword of network security. Traces of BSD technology are found in dozens of commercially sold products. So why are organizations so slow to deploy BSD based network appliances internally?
This talk/tutorial will:
- Define __Network Appliance__ through comparison of commercial product offerings to their BSD equivalent.
- Identify the issues and challenges that impair wide-spread adoption of BSD network appliances in small-to-medium size organizations.
- Explore the specific features and subsystems of NetBSD that make it the best choice among BSDs for embedded network appliances.
- Step through the procedures and caveats of adopting a generic NetBSD release to boot off of CF media.
- Discuss a reference design framework that addresses scalability, management, and enterprise-class deployments of NetBSD network appliances.
- Identify areas for future development efforts.
Murray Stokely has served the FreeBSD Project as a core team member, release engineer, and handbook editor. Professionally, he has worked for Walnut Creek CDROM, BSDi, Wind River Systems, and now Google. Interests include release engineering, package and installation tools, documentation architecture, and advocacy.
I want to talk about some challenges that we face at Google, some technologies we use, and the needs for large scale 21st century computing. Things like GFS, Map Reduce, and other Google technologies for distributed computation. Also I will talk about some BSD use inside of Google, summer of code, and other topics.
Russell Sutherland, has devoted most of his waking life to the University of Toronto, first as an Engineering student, and in recent decades a mathematics teacher and staff member in the Computing and Networking Services group. Short naps have been spent working in both the nuclear and renewable energy sectors. Russell has played with Unix for many years, beginning with Bell Labs version 6, in 1978. In his spare time he reads theological literature.
I have been running FreeBSD on a cluster of standard Intel based servers as an economical and functional alternative to "normal" dedicated/expensive (Cisco/Foundry/Juniper) routers on the edge of our campus for the past 3 years. Using Zebra/Quagga and ipfw/dummynet we have set up a system which is both flexible in terms of meeting our external routing and packet filtering needs.
We are the largest University in Canada, serving a body of some 70,000 students and 11,000 staff and faculty. There are an estimated 50000 machines which are served by our external routing cluster.
Wietse Venema is a research staff member at the IBM T.J.Watson research center. After completing his Ph.D. in physics he changed career to computer science and never looked back. Wietse is known for his software such as the TCP Wrapper and the POSTFIX mail system. He co-authored the SATAN network scanner and the Coroner's Toolkit (TCT) for forensic analysis, and co-authored a book on Forensic Discovery. Wietse received awards from the System Administrator's Guild (SAGE) and from the Netherlands UNIX User Group (NLUUG). He served a two-year term as chair of the international Forum of Incident Response and Security Teams (FIRST).
Wietse presents the main thoughts and mechanisms that went into the design and implementation of the open source Postfix mail system, and how this design made it possible to expand the system by five times without losing its desirable properties: performance, security, robustness and ease of use.
Jason Wright has been a developer with the OpenBSD project since late 1997. His work focuses mainly on the kernel where he has written drivers for just about every kind of device (serial, IDE, USB, ethernet, video, PCI, and more). He is also the current maintainer of the OpenBSD/sparc64 port.
OpenBSD runs on a wide variety of architectures. I, with some prodding and a lot of help, decided to try and tackle the SPARC version 9 (aka sparc64) port. There have been many hurdles along the way: getting hardware, getting documentation, getting time, etc. I will discuss our solutions to these problems from the beginning of the port up to the present: from single-user to production ready.