Archive for August 2008
I’ve been asked a couple of times today about the presentation given by Alex Pilosov and Tony Kapela at Defcon, entitled ‘Internet-Scale Man in the Middle Attack‘ – essentially along the lines of, ‘is the Internet broken now?’
The paper doesn’t really say anything that people who are familiar with BGP and its use on the Internet don’t already know. In terms of new content, all it presents is a nifty way of hiding the attacker from showing up in traceroutes by messing with TTL values. This means that to detect the attack requires looking at the AS path, something the average customer doesn’t have access to. The fact the majority of the paper isn’t new information doesn’t make it any less true, of course.
The basic problem is this – every BGP speaker, that is every hosting provider and ISP on the Internet, trusts everyone they directly communicate with. This isn’t actually strictly true, as I’ll come to later, but I suspect the number of those who configure their routers in a more optimal way are in a statistically insignificant minority. This means that I can tell your ISP that the best way to access the BBC News site, for example, is via my network. I can then alter the news stories you’re requesting before they reach you, making you believe that David Ike was right all along, and the Queen has been exposed as a baby-eating reptile. Or something along those lines, anyway…
Fortunately for our customers, their routers aren’t quite so vulnerable – which isn’t to say they are completely unaffected. The most likely source of such an attack is at a peering exchange point, such as LINX or MaNAP. Knowing this, we auto-generate prefix-list filters based on data we obtain from the RIPE database. This means that each peer is only allowed to advertise those IP ranges which we know belong to them or a customer of theirs, and any other advertisements are simply dropped. If they try to say they look after the BBC News range, that particular advertisement is simply ignored, whilst we continue to send them traffic they really are responsible for.
Unfortunately, the same filtering can’t be applied to upstream providers. Here there is no choice but to take what the provider says at face value. As the majority of providers are pretty good at checking the ranges advertised to them by each customer, this is generally OK, but inevitably there is always the possibility of misconfiguration, either by human error or a rogue member of staff. Whilst this is a realistic possibility, it’s on nothing like the scale suggested by the aforementioned paper.
Fundamentally, the message is this: if you have a competent provider, don’t panic. Ask your provider what kind of filtering they use with their peers. If all they do is check for ‘max prefixes’, ie, limit the number of prefixes a peer can send them, it’s time to start looking elsewhere.
Red Hat have released a security advisory detailing an intrusion on their servers. The attacker apparently managed to sign some compromised OpenSSH packages.
There is a parallel Fedora announcement, and although it seems that Fedora wasn’t affected they are issuing new package signing keys as a precaution. Red Hat use a hardware device for signing their packages, so they can make sure no further compromised packages can be created without having to re-distribute new signing keys.
Red Hat Network wasn’t compromised, so although the signed packages were created, there is no risk to those whose only means of obtaining packages is via RHN (ie, most Red Hat users).
Whilst there certainly isn’t any need to panic, this is sure to cause concern amongst those running Red Hat.
I’ve just put up an long-ish article I’ve written comparing five different server distributions. I fully realise that by doing so I’m opening myself up to hundreds of flames from outraged fans of <insert OS here>, all complaining that I’ve treated their pet distro unfairly.
Given that I’ll probably be accused of bias anyway, I better declare mine: the server that is serving you this page runs Ubuntu, as does the one running the main Bashton site. Many of our internal-facing servers run CentOS. My desktop runs Ubuntu, and my laptop runs Debian. Other staff have their own bias of course (particularly those who are Debian developers..), but as it was just me writing the article I don’t see that as relevant.
Please make your comments here and hopefully we can start some form of a useful debate, rather than the ‘distro X is the best’ discussions these things usually descend into.
There’s a great article over at Forbes on the real cost of servers. The main thrust of the article, and something that shouldn’t be too surprising for anyone who’s been working in IT for a while – the actual cost of the server is much less than the cost of running it, even when excluding IT staffing costs.
“One company’s IT department decided to invest $22 million in blade servers but forgot to inform facilities. The facility investment required to merely plug-in the blades was an unplanned $54 million. An additional unplanned $30 million was required to run the blades over three years. So what appeared to be a $22 million decision was really an enterprise decision of over $106 million.”
Red Hat Enterprise 5 ships with Python 2.4. As it uses this for the majority if its inbuilt scripts, it’s probably not such a good idea to just change it.
With this in mind, I built the following Python 2.5 RPMs, which create the python executable as /usr/bin/python25. This means that where necessary, you can use Python 2.5, but the system scripts will continue to use 2.4. If you do want to use Python 2.5 by default, by all means make /usr/bin/python a symlink to this – but don’t complain to me if ‘bad things’ happen.
64-bit RPMs:
python25-2.5.1-bashton1.x86_64.rpm
python25-devel-2.5.1-bashton1.x86_64.rpm
python25-libs-2.5.1-bashton1.x86_64.rpm
python25-test-2.5.1-bashton1.x86_64.rpm
python25-tools-2.5.1-bashton1.x86_64.rpm
Source RPM:
python25-2.5.1-bashton1.src.rpm
