You cannot protect from these attacks at all apart from upgrading.

• TTL wont work as you could count hops to the target with traceroute and alter starting ttl accordingly.

• Source IP filtering wont work as its pretty easy to figure out that between 2 routers in a traceroute there is a /30 (most ISPs). Sure loopbacks are used a lot of the time for BGP peerings, but sometimes it is the interface ips. I havent thought through a loopback hack scenario, but there quite possibly could be a practical attack.

• Dont forget theres also telnet, ssh, snmp, rsvp, ldp etc etc… its not just bgp!

• Does this even require an open (post 3-way) tcp socket???

I think the biggest problem with this is that it demonstrates a lack of vulnerability testing from within the vendor. Its just a matter of time until more bugs are found as people now have a focus on these particular products.

Not good at all for a ‘core’ router vendor!!

In my tests it turns out that having a firewall filter does seem to block these packets without crashing the kernel. Of course it’s easy to spoof these packets, but still some form of protection.

See video here: http://www.toonk.nl/blog/?p=522

If you haven’t patched yet, pretty soon might be a good time for some emergency maintenance.

However, the JunOS hardware firewalling capabilities don’t provide a way to filter a packet based on TCP Options/Option Kind. So (that I see), there’s no way to use firewall to block just the exploit.

It seems that a valid packet can be spoofed, regardless of firewall: bad guy can use a fake source address.

As a result, there is no workaround, other than having no RE TCP listening ports. This is not feasible for border routers that require certain protocols.

The example shown above, its clear you are using a JUNOS O-Series (olive). Olives lack ASICs and such which can perform packet filtering before packets are punted to the routing engine.

Just curious if you’ve tried this against a Juniper that has a simple firewall police that would drop any packets destined to the RE below a particular TTL value. I’m curious if the magic packet is able to proceed through and break the RE.

Anyone who can refute what Juniper stated in the bulletin about countermeasures, please let us know.

Director of Front: You’re kidding right? Not sure where to get started on how wrong that statement is.

If your network relies upon a few M7i’s…you probably should be upgrading your code.

As for “TTL” security.. JunOS platform doesn’t support TTL security. There’s a “hack” that works on some platforms.

Most of Junipers’ hardware-based routing platforms don’t support setting a firewall rule based on TTL, other than T-Series, M320/M120.

It may be easy to discover eBGP boundaries via traceroute due to folks typically using /30s or /31s (cough, what we all should be using), but that doesn’t mean you can still attack either end of the router. Using BGP TTL security validation, you can implement packet filters that examine the IP TTL of any inbound TCP/179 (BGP) sessions. This way, any packet coming on for TCP 179, even if it is spoofed would still be tossed because its TTL will be < 255. This is a best practice which has been going on for years and anyone not implementing it would be foolish.

@ANTON DELPORT: On your second point about anti-spoofing and egress filtering, this has been raised enough that we have answered the question in the main article.