ONLamp.com
oreilly.comSafari Books Online.Conferences.

advertisement


OpenBSD 3.6 Live
Pages: 1, 2, 3

FB: What is your opinion about caller ID technology?

Bob Beck: Short answer: it sucks dead moose through bent straws.

Long answer: for spam fighting? I don't think it will work well. SPF and caller ID don't stop spam--all they do is make sure that the envelope-from of a message comes from a place that the DNS for the supposedly sending domain says it should, or could, come from. That doesn't mean it's not a spam message. It's a nice thing for AOL or MSN to be able to provide people with a mechanism to identify their outgoing SMTP addresses. (Of course there are other ways they could actually do that, like publishing a whitelist?) My other big problem with these mechanisms is they break mail forwarding. Yes, I know there's another proposal to get around that problem too--but that involves more changes to MTAs, and I would hope to see some benefit for that in exchange for such a change. Truth be told, I haven't, and I've looked.

As you can imagine, I've received a bunch of suggestions to "make spamd do SPF! wouldn't it be cool!" I agree it might be cool, but cool alone doesn't cut it; it needs to work to justify its existence, code complexity, and maintenance with some actual benefit. So I did a little experiment around the middle of September. I have a spamd box in front of a large domain with about a hundred thousand users or so. It runs greylisting only, no blacklists. This machine consistently sits at about 40,000 greylist entries in spamdb, with a 4-hour expiry time. So figure on about 10,000 connections an hour in the greylist, the vast majority of which are spambot-generated spam that never retries. I wrote a small Perl script using the reference SPF implementation (Mail::SPF) to walk through my greylist. I was interested in two things:

  1. How many greylist entries were being sent with an envelope-from sender where the sending domain published an SPF record indicating it was relayed from an unauthorized IP.
  2. How many greylist entries were being sent with an envelope-from sender where the sending domain published an SPF record indicating it was relayed from an authorized site (and what did these messages appear to be).

The result was very interesting. Obviously if there was lots of case 1, it would be a compelling argument to add functionality to spamd to do this. Out of my approximately 40,000 entries in my greylist, there were about 25 connections that showed this. So really, for all that cost of DNS lookups and code complexity, I would have blocked 25 spams. Big deal :)

No. 2 was even more interesting. There were about 1,500 greylist entries where the envelope from indicated a valid or at least possibly permitted sending IP in SPF. But then it gets fun. Take a look at the sender and recipient, and turn on spamd debugging, and take a look at the content. Almost all of these were spam.

What's my conclusion? SPF and caller ID does two things, which I would do if I were writing spam software:

  1. Encourages spammers to publish SPF records (and they have).

    If I were a spammer, I would publish SPF records for my throwaway domains to allow the places I'm spamming from. There's a nice site about SPF that tells me how to do it :) The biggest SPF adopters I see on my site (from No. 2 above) are spammers.

  2. Encourages spammers not to spam from SPF-publishing addresses.

(And don't forget, this is what AOL and MSN *really* care about.) If I were a spammer and were completely untalented and didn't have a throwaway domain, if I were sending a message with a random valid domain as the source, I would first do a quick DNS lookup to see if the domain published SPF records. If it does, pick a different random domain. Not that hard, and not that expensive. The result is I don't use AOL or MSN addresses. While this is good for AOL or MSN, it doesn't really do much for the average mail site maintainer. True, you could say, "I will only accept mail from sites with SPF records," but right now that means "I will only accept mail that is 90 percent spam," because while lots of people have SPF records, other than MSN and AOL and their ilk, most of the mail flying around out there from SPFed domains, at least that hits my server, is spam!

I sometimes wish my sense of ethics was surgically removed at birth so I could write spam software. I'd make more money to pay someone else to shovel the s### out of my basement and fight with the insurance people ;)

FB: And what about its proposed license?

Bob Beck: When you consider the Microsoft patent issues, not only does it not work well for stopping spam, but it's also probably going to end up being free-implementation hostile like VRRP anyway. I don't want to have to get drunk and make up another IETF-bashing song about SPF/caller ID/MARID/blah blah ...

Wait, what's that noise I hear? It's a band of zealots screaming, "It's not for stopping spam, it's for stopping forgery!" after reading this. Right--but people are touting it to stop spam and I don't think it will. It also can't stop forgery, only make it a bit more difficult. When I don't want my mail to be forged, I do it the way God intended man to have secure conversations: strong cryptography--not the DNS. (I'm crossing myself saying, "PGP, IPSec, SSH.") :)

FB: NAT-Traversal support has been added to isakmpd. What is it?

Hkan Olsson: NAT-Traversal addresses the problem that IPsec has with NAT.

The normal operation of NAT is to multiplex (modify) the TCP or UDP port number to distinguish between different hosts/ports on the inside network--typically to "hide" a number of hosts behind a single, externally visible IP address.

IPsec does not work well with NAT for a number of reasons; perhaps most obvious is that the IPsec protocols do not have port numbers (being neither TCP nor UDP).

The solution--i.e, "NAT-Traversal"--is to encapsulate the IPsec packets inside normal UDP packets, normally on port 4500. This traffic, being UDP, works well with NAT.

There is thus far no finished IETF standard describing how NAT-T should be done. The OpenBSD IKE daemon (isakmpd) currently implements roughly the -02 and -03 NAT-T drafts from the IETF IPSEC working group. This seems to match what most other vendors do.

FB: Does it interact with PF?

Hkan Olsson: Yes, and it is fairly straightforward. IPsec packets using NAT-T are to be matched on UDP port 4500 instead of (or in addition to) IP protocol 50 (ESP).

FB: Sometimes I read on the PF mailing list that someone hit the queues limit number with his ruleset. Is there any plan to increase the max number of queues that PF can handle?

Henning Brauer: Completely pointless. The number of queues is not limited because we like to impose limits ... the time resolution of the kernel is limited; we cannot reasonably break down the network traffic to an arbitrary number of queues, they would simply not work as intended. That said, there is at least some ideas for the PRIQ scheduler to allow people to specify more queues than now. As it is only about priorities and not bandwidth, the time resolution is not such a big factor there.

FB: I'm very interested in the pfctl optimizer feature. How does it work?

Mike Frantzen: The basic premise behind the ruleset optimizer is that it doesn't matter which rule passes or blocks a packet as long as it gets passed or blocked like intended. To that end the optimizer will split the ruleset into superblocks of adjacent rules that it can safely reorder. For example:

pass in  proto tcp to $BOB port ssh   keep state
pass in  proto tcp to $JIM port ssh   keep state
pass in  proto tcp to $BOB port smtp  keep state
pass in  proto tcp to $JIM port www   keep state
pass in  proto tcp to $BOB port ident keep state

Those five rules can safely be reordered without changing the meaning of the ruleset. So what ... The kernel implements skip steps such that if a packet does not match part of a rule (for instance, the port), then the kernel will skip over the next rules that it knows cannot match. So in the above example, we would reorder the rules to:

pass in  proto tcp to $BOB port ssh   keep state
pass in  proto tcp to $BOB port smtp  keep state
pass in  proto tcp to $BOB port ident keep state
pass in  proto tcp to $JIM port ssh   keep state
pass in  proto tcp to $JIM port www   keep state

When the kernel is evaluating a packet against the first rule and the packet is not destined to $BOB, then the kernel will skip over all of the next $BOB rules. In the unordered case, the kernel would have evaluated five rules. In the optimized case, the kernel will only evaluate two to four rules.

The ruleset optimizer can also remove duplicate rules, rules that are a subset of another rule, and it can automatically combine rules with different IP addresses into a single rule with a table lookup. The optimizer can even look at the statistics of the currently running ruleset and use that as feedback to direct the optimization of "quick" rules.

Most people get a 10 to 30 percent decrease in effective ruleset size. Some script generated rulesets get cut by 300 percent.

Here I should probably plug my employer, NFR Security. I wrote the ruleset optimizer under the auspices of NFR's intrusion prevention system that incorporates PF.

FB: NMBCLUSTERS is gone. How does the kernel manage networking memory now?

Henning Brauer: Well, NMBCLUSTERS was the (fixed) size of the mbuf cluster pool. Now, there is an initial size for it, and whenever it is used up beyond a certain point, the pool is grown. The growing happens outside interrupt context, of course.

FB: It seems that OpenBSD is moving toward the Cisco replacement market. Why have you added support for T1/E1 hardware?

Henning Brauer: We are not moving toward any market. We solve problems, often our own ones.

There is increasing demand to terminate T1/E1/T3/E3 lines on OpenBSD machines. So we contacted some vendors; Cyclades provided two cards (for that, support is still to be written), and Sangoma provided [many] cards and sent us one of their engineers, Alex, to the hackathon. He and a few of us worked together to get the driver into a shape where it could be committed to OpenBSD, and in it went.

FB: Is there any plan for DSL hardware support too?

Henning Brauer: I do not see the point; the DSL-Ethernet bridges are the devices to use IMHO.

FB: I found this post, which includes a link to a patch for in-kernel PPPoE. Is there any chance to see a kernel side PPPoE implementation in the tree?

Todd C. Miller: I don't use PPPoE myself, but this has been a topic of discussion among the OpenBSD developers. The consensus was to do this in pieces by updating the lmc(4) driver first and then adding bits specific to PPPoE.

FB: What is the generic framework IEEE 802.11 introduced in this release?

Todd C. Miller: OpenBSD 3.6 ships with an IEEE 802.11 networking stack originally developed by Atsushi Onoe (NetBSD) and heavily modified by Sam Leffler (FreeBSD). Previously, most popular 802.11 chipsets (prism, lucent, aeronet) did most of the actual 802.11 protocol themselves. More recently, the trend has been toward chipsets that require almost everything be done in software (presumably for cost reasons).

In a way it is similar to the prevalence of software modems these days. With the 802.11 framework we can support the older cards that are "smart" as well as the newer "dumb" ones. Note that "smart" doesn't necessarily mean better. When the stack is done in software, we have more control over things, allowing for host-base access points (HostAP) and alternate encryption schemes.

Currently only the ADMtek ADM8211 driver uses the 802.11 framework, but in time I expect the other wireless drivers to be converted as well.

FB: This release adds the support for ADMtek ADM8211 802.11b wireless adapters. What is the plan for other chips and technologies like 802.11g?

Todd C. Miller: The relative dearth of supported 802.11g chipsets is really due to a lack of documentation and/or firmware. For instance, there is a driver for the Intel 802.11g (Centrino) chipset but it requires a firmware image that is only available via click-through license, which prevents us from shipping the firmware. Likewise, there is a Linux driver for the Prism 802.11g chipset, but it also requires a firmware image for which there is no legal source. The 802.11b cards we support have firmware stored in flash memory, but newer designs omit the flash to save money. Without the firmware there is little point in having drivers for the hardware. While there are people putting pressure on vendors to release their firmware under an acceptable license, so far they haven't had much luck.

FB: Most security-sensible people use IPSEC to protect wireless networks. Do you think that the new WPA (Wi-Fi Protected Access) could make it unnecessary?

Todd C. Miller: I have not looked at WPA in enough detail to have a very informed opinion on this. It is certainly an improvement over WEP (but [that's not] saying much). I do know that Sam Leffler has changes to the 802.11 framework to support WPA, though I don't know if he has integrated those into FreeBSD yet.

FB: Mike Frantzen has introduced a new feature called StackGhost on the Sparc platform. How does it work?

Mike Frantzen: Sparc is a weird, fun computer architecture. The return address is saved on the stack when a programmer calls a function on most architectures. And thus a buffer overflow will overwrite the return pointer in order to execute an exploit. But Sparc is weird. To greatly simplify the explanation, Sparc puts the return address in a list of registers. Then the kernel is the one that actually writes userland's return addresses to the stack once the function calls go deep enough to exhaust all of the registers.

So StackGhost will go ahead and XOR a random 32-bit number into the return address before written to the stack, and it will remove the random number when it retrieves it from the stack. When an attacker overwrites the return address with a pointer into his exploit payload, his pointer will be off by that random 32-bit number and the program will crash instead of running his exploit. The performance impact is about 1 percent, and it requires no changes to userland, not even a recompile.

FB: Is there any chance to port it to other platforms?

Mike Frantzen: StackGhost takes advantage of a nuance of the Sparc architecture. Sparc64 would obviously be fairly easy. Similar nuances exist in Itanium but would be more difficult to take advantage of. And I'm told there might be games we could play on HPPA or M88k.

FB: Is there any other OS that uses it?

Mike Frantzen: Not that I know of. StackGhost itself is pretty easy to implement. The really hard part is making GDB usable under StackGhost, which was done by Mark Kettenis.

FB: Why have you developed strtonum(3), another function to convert strings to numbers?

Todd C. Miller: We developed strtonum(3) for the same reason we added strlcpy(3) and strlcat(3)--the existing mechanisms were difficult or impossible to use safely. The most common function used to convert a string to a number, atoi(3), provides no way to check for error conditions such as overflow, underflow, or invalid input. While strtol(3) and its variants do provide ways to detect this, they lack the ease of use of atoi(3) and so tend not to be used. With strtonum(3), a programmer can easily replace existing calls to atoi(3) and get bounds checking and error detection for free. As an added benefit, using strtonum(3) makes people think about [which] upper and lower bounds actually make sense for the given input.

FB: I was wondering if you ever thought to replace the old plain text logs format with something like Bruce Schneier's Cryptographic Support for Secure Logs. Tampering with logs is pretty easy, and this has gone unaddressed for years.

Damien Miller: It doesn't make sense to change the log format to something other than text. The best thing about syslog is that you can wield the entire range of Unix text-processing tools over syslog output, and even do it in real time (using tail -f). I'm also quite concerned about adding more complexity to syslogd--it is one of the really critical parts of the system, and it must be robust in the face of all sorts of untrusted input. That being said, there may be a way to add some sort of simple integrity stamps (perhaps based on Schneier's design) to the log in a textual format. It could be a good project for someone who is interested.

I think that a more practical problem to solve is how to export logs off a system in a secure fashion. If the log data is no longer on a system, then it cannot be retrospectively compromised. Also, log information is more useful when it is centralized and available for event correlation. It might be cool to add some simple way for syslogd to automatically set up IPsec SAs for when exporting logs to an external host, probably using the code from bgpd. But, I don't have any immediate plans to work on this.

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 the BSD DevCenter.



Sponsored by: