BSD DevCenter
oreilly.comSafari Books Online.Conferences.


OpenBSD 3.9: Blob-Busters Interviewed
Pages: 1, 2, 3, 4

What is the current status of the trunk interface?

Reyk Floeter: The trunk interface has been introduced in the previous 3.8 release with basic functionality and some initial problems. Many internal changes, like VLAN-size MTUs (if supported by the physical ports) and some new functionality are available in the 3.9 release.

The most important improvement for the 3.9 release is proper multicast support. Now, it's possible to use CARP and PFSYNC on a trunk device without limitations. Personally, I use this on redundant firewalls with additional layer 2 redundancy -- redundant firewalls, redundant network interfaces and even redundant network switches connected to the firewalls thanks to trunk in the new failover mode.

The trunk failover mode is an alternative mode to the initial round-robin interface scheduler. Instead of distributing the traffic to the connected trunk ports, only one active interface is used at the same time. If the first active interface (the master port) fails, the next active interface will be used. The failover mode does not gain any performance but works great for layer 2 redundancy without the requirement of trunk support by the network switches (mcbride even tested it with simple hubs!).

What's new in hostapd?

Reyk Floeter: hostapd has been heavily improved for the 3.9 release. I did some cleanup and implemented some nice new features. An important internal change is the internal handling of wireless nodes. I modified hostapd and the entire net80211 framework in OpenBSD to use collision-proof and fast red-black trees instead of the hash tables before. This is a proactive security improvement, which also fixes some problems in the net80211 framework.

Furthermore, the daemon now supports multiple wireless interfaces and I extended the event rule syntax to allow interface-specific rules. With the benefit that the daemon now handles roaming between internal interfaces correctly.

While playing with mrouted, the multicast router daemon, I figured out that hostapd missed a configuration option to define a higher multicast TTL. Now it's possible to forward hostapd messages to other, non-local network segments. This is very cool for remote Wireless Intrusion Detection Systems (WIDS) using hostapd as a real-time sensor. Another advantageous feature in conjunction with WIDS is the new rate keyword for event rules. It allows to detect flooding attacks (like the void11" 802.11 deauthentication attack I released some years ago) and works similar to the max-src-conn-rate option in PF.

What's the status of ipsecctl in 3.9?

Hans-Joerg Hoexer: The main goal for 3.9 was to improve the interaction with isakmpd(9). For example, reyk@ added pre-shared secret authentication. Moreover, with 3.8, it was still necessary to use an isakmpd.policy file in certain situations, this limitation is now gone.

Markus@ added support for tunneling using IP in IP. This does not provide any security mechanisms but allows [you] to setup easy tunneling without using gif(4) interfaces.

Small improvements include support for transport mode when using manual keying, using interface names when specifying addresses, and a more relaxed syntax. For example, it does not matter anymore in which order you specify source and destination address.

A new version of FTP proxy has been included. Why?

Camiel Dobbelaar: The new FTP proxy (previously known as pftpx) has a couple of advantages.

It handles the passing of all data connections automatically via anchors. The user only has to setup the anchors and the rules for the control (port 21) connections, which is simple enough. With the previous proxy, the user had to setup rules for all possible data connections as well, which could be quite hard with non-standard configurations.

Lots of FTP clients expect data connections to have the same IP addresses as the control connection. If they have an FTP session with server X, they refuse data transfers to/from proxy Y for security reasons. The new proxy [uses] the NAT features of PF to make sure that the addresses are always the same and should therefore satisfy all FTP clients. The old proxy did not have NAT tricks at its disposal, making some clients fail in mysterious ways.

Those are the biggies. Other advantages are that it handles IPv6, the extended FTP modes, and that PF queuing can be used for data connections.

HTTP proxy authentication support has been added to netcat. When should we use this feature? Is this a first step toward a proxy framework for PF?

Damien Miller: No, it is a useful tool for making connections out from behind proxies through, especially SSH connections. For example, adding this to your ~/.ssh/config will make ssh connect through an authenticating HTTP proxy:

ProxyCommand nc -x proxy:8080 -P proxyuser -X connect %h %p

Not all proxies allow connections to port 22 where OpenSSH usually listens. You can always make it listen on another, high-numbered port to work around this.

It seems there are no new features in PF this time. What's going on?

Henning Brauer: Well, we don't hack on PF because we hack on PF, we solve problems or add features we miss. There weren't any big problems to solve or features we miss.

I saw that you bumped PF state, byte, and packet counters to u_int64_t. Why?

Henning Brauer: Consistency, since they were 64 bit in most places already, and overflow concerns. The u_int32_t counter we had before could wrap around. While that has no bad consequences for PF, it might lead to wrong data in accounting systems and the like using this information from PF.

What type of work have you done on Apache?

Henning Brauer: Lots of cleanup. Pretty boring to do, not visible for the end user. Except that we might have fixed a bug or two while doing so.

TRACE was disabled. Why? Is there anything else that you would like to disable or remove from the codebase?

Chad Loder: TRACE was disabled because there have been two Apache vulnerabilities related to this feature: VU#867593 and CAN-2005-2088.

We looked at various ways to support disabling TRACE using configuration options. I asked around on the mailing lists if anyone uses TRACE, nobody does, so we just decided to rip it out entirely. Nobody has complained yet, so I'm pretty sure nobody was using it.

Where has libresolv gone?

Henning Brauer: It only ever was a stub with nothing in it, because some software incorrectly assumed it always had to link libresolv. We found that these days the stub libresolv just confused some configure script.

I saw that the in-base libpcap was updated with most features of a recent version from Why didn't you just import the latest version?

Damien Miller: The libpcap has a heap of portability goop in it, so we just took the important bits of the new API and implemented those, based on the sources. The API is good, but there is too much abstraction in the sources, so we cleaned it up a little.

Pretty much anything recent that previously needed an updated libpcap should compile against the in-tree one now.

Why did you choose to compile system libraries with debugging symbols? How much does this approach increase RAM usage? What about performance?

Henning Brauer: The added debug symbols help debugging issues, since now we get tracebacks with function names instead of addresses (that can change). It does not increase RAM usage at all and does not have performance impacts. It just costs some space on the hard disk.

What persuaded you into auditing the whole source tree to fix the wrong uses of queue(3)?

Otto Moerbeek: It all started after Pedro found a filesystem bug that happened because an element was removed from a list twice. The list was implemented using the macros from sys/queue.h. Now, I was more or less aware that it was easy to use these macros in a wrong way, but the test program Pedro made showed that it was really easy for the data structures to become corrupt: a linear list could become circular, for example. This caused a hang, because the kernel was busy running though the list trying to find the end.

So, we did a few things: one, improved the manual pages and included a warning for various things developers should not do; two, audited the source tree for wrong usage of the queue macros; and three, introduced strict versions of the macros that detect wrong usage [at] run-time. The strict macros are not enabled by default, but both developers and others are encouraged to run with them.

All this enabled us to find real bugs and fix them.

Pages: 1, 2, 3, 4

Next Pagearrow

Sponsored by: