OpenBSD 4.1: Puffy Strikes Again
Pages: 1, 2
I saw the new BSD licensed pkg-config. What are the differences with the old code?
Marc Espie: Complete rewrite from scratch in an appropriate language, namely Perl. The project was initiated by Chris Kuethe, completed by me, and tested out by lots of people. The idea is that you should not be able to see the difference from the GNU version, but it's better. For starters, the code is about 10 times smaller, and more maintainable. It's also slightly more picky, and its internal representation can do very interesting stuff that we don't use yet.
Matthieu Herrb: pkg-config is required by the configure scripts in X.Org's modular tree. So in order to make it possible to build X in the base system, we needed an implementation of pkg-config in the base system (or in Xenocara at least).
What are the goals of Xenocara (an effort to port X.Org 7.2 to OpenBSD)?
Matthieu Herrb: I should say first that Xenocara is not part of OpenBSD 4.1, which still provides X.Org 6.9 using the "old" XF4 source tree. OpenBSD-current switched to Xenocara a bit after the code freeze for 4.1.
The main goal of Xenocara is, as you said to provide a build infrastructure for recent modular X.Org releases (the current code in xenocara is based on X.Org 7.2). The modular X.Org tree is split in hundreds of individual packages that need to be built and installed separately. And there are some third-party packages (Freetype, expat, Mesa, etc.) which are not provided by X.Org anymore. Xenocara is mostly a set of BSD makefiles that drives the build of these packages in the right order, passing their configure scripts the right options to provide a working X environment that is configured appropriatly for OpenBSD.
There are also local patches to the X.Org sources in Xenocara, like we did in the past, that either fixes bugs that were not fixed in X.Org or to provide some extra functionality that X.Org is not interested in supporting (mostly legacy architectures support). Our goal is still to get as many as possible of our local changes committed back to X.Org, in order to minimize the differences. Xenocara is not a fork from X.Org.
I hope that one of the benefits of the modular X.Org, the ability to rebuild just one package individually, will make it easier for OpenBSD users and developers to hack on X and help improve the code, both functionality-wise (DRI) or security-wise.
syslogd(8) can now pipe logs directly to other programs. How would you take advantage of it?
Henning Brauer: I added that for use with log analysis tools like logsurfer (in ports). Basically, logsurfer is a fast regex engine. I use it at bsws to find unusual messages on our central log host. With syslogd being able to log to logsurfer's stdin directly, we get near real-time analysis.
Network guys will be happy to play with the new tool called hoststated. What features does it provide?
Henning Brauer: Well, initially, Pierre-Yves Ritschard finally implemented the missing userland bits for the long present loadbalancer functionality in PF--host availability can now be checked and dead hosts can be removed from the pool. Reyk Floeter then added some layer7 support, so that it now speaks http and can balance to backend servers based on cookies, parts of the URL etc, and can do the SSL crypto work too.
The bridge driver now supports the Rapid Spanning Tree Protocol (RSTP). What advantages does it provide?
Henning Brauer: In one word? It's faster. That's really what it is about. Spanning Tree (STP) just takes quite some time to cope with a failed link. Rapid Spanning Tree (RSTP) does not need re-evaluate and recalculate the entire topology in this case and can thus fail over to alternate links way faster.
What is the status of transparent IPless bridges? What can we do and what can't we do yet?
Henning Brauer: I have always considered transparent IP-less bridges a very stupid setup, and nothing changed in that.
Multiple routing tables. What does it mean for PF?
Henning Brauer: The kernel used to have one routing table per address family--one for inet, one for inet6, one for IPsec, usually. Now it can have multiple tables. From within PF, you can select which routing table should be used for the route lookup later--you can implement policy routing with this. But much more could be done--this is really only the groundwork. It could be possible, in future, to have overlapping address ranges on interfaces and place interfaces into different routing tables, forming a kind of virtual routers. And of course, the routing daemons will learn to make more use of alternate tables.
Claudio Jeker: PF is only a piece in the concept of multiple routing tables. PF is "just" used as packet classifier similar to altq. This makes it possible to classify the traffic and selecting different tables to route that traffic. Using multiple routing tables together with bgpd enables OpenBSD to implement customer VPNs in ISP networks--in Cizzz-coeee speak VRF-lite (virtual router forwarding). 4.1 only includes basic support--PF can be used as classifier and it is possible to specify the table that bgpd should use. There is still a lot missing but OpenBSD is about evolution and not revolution. Expect to get more and better support in the next release.
PF in 4.1 comes with two new default settings: keep state and flags S/SA. Why?
Claudio Jeker: More and more system use scaled TCP windows. PF's state tracking needs to match on the initial SYN packet to get the correct window scaling. When the state is created on a different packet (e.g., a SYN/ACK) the window scaling is wrong and after a few packets the connection stalls. Using keep state and flags S/SA by default should reduce misconfiguration and is therefore a saner default. It is still possible to do stateless filtering by using the no state option.
Henning Brauer: Stateless filtering just doesn't make all that much sense. Stateful is faster, and it is better. On top of that, most of the time we saw stateless filters, the "keep state" was missing on accident, which then lead to all kinds of very hard to track down errors. So in the end this is really just the "good defaults" mantra. You can use "no state" if you really want to filter statelessly.
The flags S/SA is just there so that states are only ever created by the initial SYN packet so that we see all options for the connection like window scaling--missing that can lead to failures that are very hard to find.
You introduced two socket options to play with the IP TTL field. I am wondering if we are going towards a future where each application will try to bypass the OS stack to make its own security check on its own network connections...
Claudio Jeker: The IP_MINTTL option was specially implemented for bgpd. It reduces the risk of attacks by dropping all packets that have a too small TTL. For directly connected routers the TTL can be set to 255 and so packets sent from further away are automatically dropped. This protects the long living bgpd TCP connections for RST and other TCP window attacks. It is a simple mechanism invented to protect underpowered BGP routers that are unable to use real crypto for protection.
Henning Brauer: There were two TTL related socket options added. IP_RECVTTL, when set on UDP or raw sockets, allows an application to receive the TTL of incoming packets. Nothing in the tree uses it so far.
IP_MINTTL on the other hand only works for TCP sockets (so far, it could be implemented for UDP and raw too). Applications that set the minimal acceptable TTL there, and packets with a smaller TTL are discarded. This is intended to be used to implement the ttl security hack in bgp, later generalized standardized as "Generalized TTL Security Mechanism" in RFC 3682. It is very simple: basically, the sending host sets the TTL to is maximum value, 255. The receiving host checks that the TTL, that gets decreased by each router on the way, is not smaller than it expects from the distance to the other host. So for hosts on the same IP network, the receiving host checks the TTL to be 255. This implies that the packet has not been routed at all, so that an attacker had to be on the same network segment as the target. This makes an attack much harder up to unfeasible with point-to-point links. bgpd implements this technique.
Is IPv6 still enabled by default?
Henning Brauer: Of course.
Why did you make pflog a clonable interface?
Henning Brauer: Biggest incentive: spamlogd.
spamlogd needs a pflog interface to track which mailservers you send mail to. The interference between logging and spamlogd sMTP watching was annoying--as in, all that sMTP traffic in you rlogs that you need to filter out. Aside from that, separate logging for, say, debugging, or per vlan, or whatever, on a per-rule basis is a good idea anyway. So: make pflog clonable, and teach PF to send the log traffic to specific pflog interfaces (i.e., for spamlogd).
ifconfig pflog5 create spamlogd -i pflog5 in pf: pass out log(to pflog5) to port smtp
spamlogd and pflog have been modified so they can work with alternate pflog interfaces of course, instead of hardcoded pflog0 before. And of course pflog0 no longer clutters ifconfig output on machines without pf (same for pfsync, but after 4.1) :)
Oh Bob, please tell us everything about your improvements in spam fighting!
Bob Beck: Well, there's been a number of large-ish changes to spamd.
First of all, greylisting is now the default mode of operation, and we've moved the config files to /etc/mail--so this release does show a bit of a flag day for people running spamd. Other things that changed are:
- The database now uses DB_HASH instead of DB_BTREE for (greatly) improved performance on larger systems. It will convert the first time you run it on an old db.
- Blacklist entries are no longer stored in a separate <spamd> table unless you are not using greylisting. This saves big on the number of PF table entries (and therefore kernel memory) spamd needs to consume on a larger system.
- spamd now can synchronize greylist and whitelist entries across multiple hosts using an HMAC authenticated synchronization protocol. This has worked out really nice for having multiple spamd hosts, or backup MX's.
- spamd can now trap hosts based on a substring of the destination address--the new /etc/mail/spamd.alloweddomains lets the user specify a list of domains (or suffixes of domains) for which they receive mail any destination addresses directed to the machine which do not match are trapped. This is a great use for old domains, or even old mail hosts--simply MX them to your spamd box and ensure that all spam sent to them traps the sending host, decreasing your overall spam load.
- spamd can now trap hosts that perform out of order MX access--many spam programs attempt to hit low priority MX hosts first. We can exploit this by adding a second IP address to a running spamd host with a lower priority MX record, and using the
-Moption to designate it as a low priority MX. When a connection is made to the low-priority address, spamd will trap any hosts which try a tuple (hello, from, to) that wasn't already in the spamd database, since it should have already been attempted at the higher priority MX.
We've also updated the default /etc/mail/spamd.conf examples to include a couple of useful new short-term blacklists, for those of us not running big sites.
What is the status of WEP/WPA/WPA2 support in OpenBSD 4.1?
Jonathan Gray: Most if not all drivers support some kind of hardware or software WEP. There is currently no working WPA support. WPA builds on 802.1X which in turns builds on EAP which came about due to PPP. Developers using wireless networks tend to prefer using authpf(8) for SSH based access control and IPsec if they require encryption.
From what I've heard, WPA is a compatibility nightmare, for instance to authenticate to a Cisco RADIUS server from a Windows machine you have to manually download a hotfix from Microsoft. No conference I've been to has ever required WPA/802.1X for network access, they don't want to deal with the pain of having to debug it.
So there are a few problems, one is that no one is terribly interested in developing the required code for it, and the other is that all the freely available 802.1X supplicants seem to be vastly overengineered. The focus is more towards having as much hardware as possible just working out of box than dealing with the pain of yet another IEEE state machine.
Federico Biancuzzi is a freelance interviewer. His interviews appeared on publications such as ONLamp.com, LinuxDevCenter.com, SecurityFocus.com, NewsForge.com, Linux.com, TheRegister.co.uk, ArsTechnica.com, the Polish print magazine BSD Magazine, and the Italian print magazine Linux&C.
Return to ONLamp.com.