Russ

Author Archives: Russ

Security ‘net: Security by obscurity

This week I have two major themes to discuss on the topic of security, and one interesting bit of research. Let’s start with some further thoughts on security by obscurity.

First: Obscurity isn’t security

I’ve heard this at least a thousand times in my life as a network engineer, generally stated just about the time someone says, “well, we could hide this server…” Reality, of course, is far different; I still put curtains on my house even though they don’t increase the amount of time it takes a thief to break in. Whether or not we want to believe it, obscurity does play a positive role in security.

But there are two places where obscurity is a bad thing in the world of security. The first is the original reference of this common saying: algorithms and implementations. Hiding how you encrypt things doesn’t improve security; in fact, it decreases the overall security of the system. The second place? Communication between companies and security professionals about the types, frequency, and methods of attack. Imagine, for a moment, that you were commanding a unit on a battlefield. You hear the sounds of combat in the distance. Realizing a unit in your army is Continue reading

Securing BGP: A Case Study (4)

In part 1 of this series, I looked at the general problem of securing BGP, and ended by asking three questions. In part 2 and part 3, I considered the third question: what can we actually prove in a packet switched network. For this section, I want to return to the first question:

Should we focus on a centralized solution to this problem, or a distributed one?

There are, as you might expect, actually two different problems within this problem:

  • Assuming we’re using some sort of encryption to secure the information used in path validation, where do the keys come from? Should each AS build its own private/public key pairs, have anyone they want to validate the keys, and then advertise them? Or should there be some central authority that countersigns keys, such as the Regional Internet Registries (RIRs) so everyone has a single trust root?
  • Should the information used to validate paths be distributed or stored in a somewhat centralized database? At the extreme ends of this answer are two possibilities: every eBGP speaker individually maintains a database of path validation information, just like they maintain reachability information; or there are a few servers (like the root DNS servers) Continue reading

Research ‘net: Dirt jumper -smart

Distributed Denial of Service (DDoS) attacks are often used to hold companies—particularly wealthy companies, like financial institutions—to ransom. Given the number of botnets in the world which can be purchased by the hour, and the relative ease with which new systems can be infected (especially given the rise of the Internet of Things), it’s important to find new and innovative ways to protect against such attacks. Dirt Jumper is a common DDoS platform based on the original Dirt, widely used to initiate such attacks. Probably the most effective protection against DDoS attacks, particularly if you can’t pin down the botnet and block it on a per-IP-address basis (try that one some time) is to construct a tar pit that will consume the attacker’s resources at a rate faster than your server’s are consumed.

The paper linked here describes one such tar pit, and even goes into detail around a defect in the Dirt Jumper platform, and how the defenders exploited the defect. This is not only instructive in terms of understanding and countering DDoS attacks, it’s also instructive from another angle. If you think software is going to eat the world, remember that even hacking software has defects that Continue reading

Should Technology Mirror Business?

The essence of SDN is to create a software model of the current data network business. This quantitative model is based on volumes of data: what ‘bandwidth’ resources do I have (i.e. supply), and how can I give different quantities of this ‘bandwidth’ to different users and uses (i.e. demand)? -via circleid

I’ve been in information technology since the early 1990’s, and it’s always been like this: business tells IT what to do, and IT does it. In other words, we make technology mirror business. Which is a fine formula for success, so long as you think business is the engine of innovation. The problem is innovation doesn’t come from one department or place. In fact, innovation most often comes from the intersection of two or more things. Think about it.

When did cars first start being innovative? When they combined the technology that existed in the latest horse drawn carriages with the latest in industrial technology, including internal combustion engines and assembly line production. All three of these came from someplace else—many people don’t know the idea of interchangeable parts came out of the firearms world, rather than the automotive industry. When did innovation come into the Continue reading

Securing BGP: A Case Study (3)

To recap (or rather, as they used to say in old television shows, “last time on ‘net Work…”), this series is looking at BGP security as an exercise (or case study) in understanding how to approach engineering problems. We started this series by asking three questions, the third of which was:

What is it we can actually prove in a packet switched network?

From there, in part 2 of this series, we looked at this question more deeply, asking three “sub questions” that are designed to help us tease out the answer this third question. Asking the right questions is a subtle, but crucial, part of learning how to deal with engineering problems of all sorts. Those questions can be summed up as:

  • Is the path through this peer going to pass through someone I don’t want it to pass through?
  • Is the path this peer is advertising a valid route to the destination?

Let’s quickly look at the first of these two to see why it’s not provable in the context of a packet switched network, using the network diagram below.

bgp-sec-02

When working with BGP at Internet scale, we tend to think of an autonomous system as one “thing”—we Continue reading