|
|
Subscribe / Log in / New account

Linux adds router denial-of-service prevention

By Jake Edge
March 17, 2010

The recently completed Linux 2.6.34 merge window included a patch to eliminate a type of denial-of-service attack against routers. The "Generalized TTL Security Mechanism" (GTSM) is described in RFC 5082 as a means to protect routers from CPU-utilization attacks—essentially overloading the router with bogus Border Gateway Protocol (BGP) packets. With the addition of a simple socket option, those attacks can be easily thwarted.

Time-to-live (or TTL) is an eight-bit field in an IP packet that is initially set to some value (by default 64) on the sending host. Each host that forwards the packet decrements it, and if it ever reaches zero, the packet is discarded. The idea is to eliminate the possibility of immortal packets that continue to be forwarded in some kind of Internet loop eventually consuming all of the bandwidth. Tools like traceroute and ping can change the TTL values of the packets they send to provide different kinds of information about the network.

Since TTL is already a part of IP, it can be extended in compatible ways. The idea behind GTSM is that two applications negotiate to use a minimum TTL value that they will accept, any packets that have a lower value will be discarded. Because routers that are communicating via BGP—the core Internet routing protocol—are typically adjacent (i.e. one hop from each other), and TTL spoofing is considered to be more-or-less impossible, the TTL value can be used to eliminate spoofed packets. By setting the minimum TTL value to 255, and sending their packets with a TTL of 255, two routers can ensure that they only process BGP packets from each other.

BGP sessions typically use an MD5-based signature to authenticate the sender. Prior to GTSM, an attacker could spoof IP packets to a router, which looked like they came from one of its peers. It would then do the MD5 calculation and find out that, in fact, the packet was bogus. But that takes CPU time. Enough spoofed packets may tie up the CPU such that real messages get lost. GTSM allows routers to drop the spoofed packets without ever calculating the MD5 hash.

The Linux patch is rather simple and the implementation is the same as that for BSD kernels. A new option (IP_MINTTL) is added that can be used with setsockopt() to change the minimum TTL for a socket. If set, the TCP code checks the value and discards packets that have smaller TTLs. The patch does not add support for various other protocols (e.g. UDP) nor for the IPv6 equivalent, which is IPV6_MINHOPLIMIT.

Applications would need to negotiate the use of GTSM via some higher-level protocol and, as the RFC points out, need to authenticate the peer before enabling GTSM. Another kind of denial-of-service could be performed if a bogus packet initiating IP_MINTTL is processed.

It is interesting to see a basic IP building-block like TTL being repurposed to stop these kinds of attacks. The idea has been around for a bit, with the first RFC being accepted in 2004. As with many Internet security techniques, it only came about after these CPU-utilization attacks became widespread. Each time attackers find a new hole, various folks find some kind of fix. It is a non-stop game of whack-a-mole, and one that isn't likely to end soon.


Index entries for this article
SecurityInternet/Routers
SecurityLinux kernel


to post comments

Linux adds router denial-of-service prevention

Posted Mar 18, 2010 8:30 UTC (Thu) by sitaram (guest, #5959) [Link]

> TTL spoofing is considered to be more-or-less impossible

I didn't understand that at first. A better way to put it (again, from the RFC) is "...a TTL (or Hop Limit) value of 255 is non-trivial to spoof".

That makes more sense. 255 is the hardest to spoof, because it means one of your immediate neighbours must be compromised. Smaller TTLs are progressively easier, since the set of routers (from which you need to compromise just one, to fake the TTL) grows in size.

Linux adds router denial-of-service prevention

Posted Mar 18, 2010 8:58 UTC (Thu) by ekj (guest, #1524) [Link] (2 responses)

It's an interesting mechanism, and one usable for a lot more than protecting router-protocols.

Since TTL is a 8-bit field, there's no way it can be set higher than 255, and if the routers around you work properly, they will decrement TTL by (atleast) one for every packet coming trough. (exception: "transparent"-mode where routers pretend not to be there)

By insisting, at the kernel-level, that packets coming in to a certain socket must have a minimum remaining TTL, you can in essence say: "only accept packets to this socket, from machines which are 'close' to me. Where 'close' is interpreted in a network-sense.

I have a home-network with a router, and a second router that serves as my gateway to the internet.

If those both work correctly, it means I can never get a package from the internet, with a TTL higher than 253. Services which are intended for home-use-only, could insist on a minimum TTL of 254, and I'd be protected against any kind of bullshit coming from outside.

The same thing is true at work: I've got servers here which provide services, services which are never intended to be used from out of building. Yes, sure, there's a firewall dealing with that. But those can have bugs of their own, and are frequently misconfigured. This would be a useful additional layer.

Linux adds router denial-of-service prevention

Posted Mar 18, 2010 14:31 UTC (Thu) by jengelh (guest, #33263) [Link]

>there's no way it can be set higher than 255, and if the routers around you work properly, they will decrement TTL by (atleast) one for every packet coming trough. (exception: "transparent"-mode where routers pretend not to be there)

Hm. So all you need is a tunnel (gre, esp, whatever) to the router and you can send it TTL=255 messages from afar :-/

Linux adds router denial-of-service prevention

Posted Mar 18, 2010 14:38 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

You can already see this fact used in link-local protocols, in two (unfortunately contradictory) ways.

Some protocols require that TTL is 1. This means that a conforming implementation, connected to properly functioning routers, never leaks packets onto the wider network (whether or not that is the Internet) regardless of router (mis) configuration because the router will reduce TTL to zero and discard the packet. It is fairly trivial for a knowledgeable attacker to spoof such packets if he can deliver them to your network.

Some protocols require that TTL is 255, because as observed here, packets which are somehow routed onto your network from elsewhere will not have this TTL value and so can be discarded. In this case attackers can't spoof you, but a lot of care is needed to ensure that no misconfigured router spills all the packets onto the Internet (or else, that when it does so no harm results)

Info from Stephen Hemminger

Posted Mar 20, 2010 17:20 UTC (Sat) by jake (editor, #205) [Link]

Stephen Hemminger has more information about the GTSM patch on his blog. As he quite rightly points out, I should have credited him for the patch in the article—a very unfortunate oversight.

jake


Copyright © 2010, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds