Conversations with security people

May 19, 2008

I’m in London right now for EUSecWest, and I thought I’d ask a few people who are making presentations here this week a few questions about what they’re doing. Some of their answers are quite interesting.

Sebastian Muñiz on Da IOS Rootkit - This is getting a lot of attention. I don’t know why people freak out so much about this kind of thing. He knows the right places to hook, and pretty soon everyone else will too.

Justin Ferguson on exploiting Perl and Python runtimes - Really interesting. The upshot is that it’s possible to write scripts that exploit bugs in the script interpreter itself. Generally people believe that you’re safe from this sort of thing. In addition to pretty much every shared hosting provider that allows customers to upload CGI scripts, one of the most high profile companies in the world is also: Google. They have a new thing called AppEngine where you can create your own web applications in Python. Obviously you’re not supposed to be able to interact directly with their underlying servers… but judging from what Ferguson says Enforcing that is going to require them to find all the bugs in Python. That’s hard. Though he hasn’t looked at WPF yet, I saw Shane Macaulay blue screen Windows Vista through managed C# code at Bluehat last summer while trying to demo some software during his presentation. So not only is corruption of the heap and stack metadata data possible, but the kernel can be manipulated too… at least on Windows.

Collin Mulliner on Near Field Communication - Ever seen those rechargeable cards that store money? They’re putting them in phones now. And it’s based on RFID. Yeah.

Alexander Klink on SSL/X.509 vulnerabilities - There are some problems with the way clients handle certificates in some cases. It’s possible to track users this way. I suspect this will not be a big long term problem, as much of it has already been fixed.

Alberto Revelli on obtaining GUI access with SQL injection bugs - Most databases have some way for you to run arbitrary code through SQL statements. Find out how to do it

Saumil Shah on IE and Firefox exploits - Saumil makes an interesting point. Browser exploits do not need to be reliable to be effective. The next generation of malware distribution networks are going to keep trying different exploits until one works. Anti-virus he says, is useless for defending against these attacks.

Lots of interesting stuff going on here.


Bittorrent vs. Broadband providers: A proposal for peace

April 18, 2008

It’s time stop spewing rhetoric and get real

I’m tired of reading the endless propaganda put forth by telecoms about “bandwidth hogs”. The issue of fair allocation of limited bandwidth needs to be dealt with.

another satisfied customer

The latest story in this sad saga is Bell deciding to throttle its customers. Bell says 5% of users account for a third of the traffic, resulting in poor performance for the other 95%. The bell case differs from the widely publicized Comcast case in that Bell is applying their traffic shaping policy to business customers as well. Many other ISPs are actively reducing speeds of Bittorrent traffic. Bittorrent users have responded by evading the filters. Providers will just tweak their filters to compensate.

The telecoms have some fair gripes, not that they ever talk honestly about them in public. Read on to learn the actual issues.

As utilization approaches 100%, throughput approaches zero

A 10 megabit pipe cannot deliver 1 megabit of traffic to 10 customers at the same time. ISPs incur significant cost overhead because of this immutable property of computer networking. Once you factor in all the segments traffic needs to pass through in a city wide network, it can take 10 megabit of raw bandwidth to give you 5 megabit of actual throughput.

ISPs cannot survive without overselling available bandwidth

There is not enough bandwidth to guarantee every user a dedicated amount. ISPs rely on the fact that not everyone uses shared resources at the same time, just like banks rely on the fact that not everyone shows up to get their money at the same time.

It’s not worth it for an ISP to sell bandwidth for $100 per month to a single customer that it could sell for $500 per month to five customers. Their best customers are the ones who barely turn their computers on.

Network usage varies over time

All networks have high and low usage times. There is a pattern to it. The average office network is more active during office hours and less active at night and on weekends. The average residential ISP is more active when people are home and less active when they are at work. There is more traffic during the day than in the middle of the night for the simple reason that most people sleep at night.

Windows update schedules installs at 3am for good reason. There is a lot of traffic on Patch Tuesday.

Remember when dial-up ISPs gave you a certain amount of peak hours and unlimited off-peak hours? Just because we’re not on dial-up anymore hasn’t made this problem go away.

Each segment is a possible bottleneck

Everyone talks as if the internet literally has three tiers: The Backbone, The ISP, and The User. In a way this is true, but most end users misunderstand this simplification. The architecture of your ISP looks something like this:

Customers in a large building or a residential neighborhood are connected to a switch somewhere. An uplink connection of some kind connects it to a regional switch. The regional switch is connected to the ISPs backbone network, which is connected to the internet.

Each switch or router can handle a limited number of connections. If too much load is placed on a device, all customers downstream of that device will suffer. The unacceptable performance of Shaw in my previous post is for this exact reason. I’ve experienced this problem at my home (since corrected) with Novus. It’s a common problem because an ISP would have to be out of its mind to refuse a new customer because the switch he is connected to needs to be upgraded. As with most things in life, cheap equipment generally handle less traffic than expensive equipment.

What telecoms don’t tell you: Not all routes cost the same money

Telecoms don’t like to discuss how they are connected to the internet. They’ll be offended if you even ask. They’ll only tell you that they’re connected straight to the backbone, with bigger pipe the competition, and bigger than your insignificant needs are for sure. But the truth is there is no central internet “backbone” because nobody owns the internet. There are two ways to get on the net: Transit (buying your way) and peering.

Transit is something everyone is familiar with. You pay a company that is already connected to the internet to connect you. They agree to carry all traffic you send them and deliver to you all traffic sent to you from the rest of the internet. In such a relationship your traffic is not worthy of trading, so you pay the other party to carry it.

If you had a lot of users you would have the option of peering with other networks instead of paying them. Peering is an agreement which two networks agree to directly exchange traffic because they see value in the other. It’s usually done in order to save costs. Peering agreements are arbitrary contracts. They could, for example, require the party which sent more traffic than it received to pay for that traffic. Or maybe the peers don’t bother billing each other at all. Essentially peering is an agreement to trade traffic.

Big ISPs like Comcast and Bell definitely engage in peering.

Obviously peering is a good thing. But there is one crucial limit to peering. Your peers don’t allow you to send them traffic for any destination. You may only send them traffic for destinations they advertise. And of course, they’re only going to advertise their own network. So if you are peered with say, Microsoft, they’re not going to carry your traffic to Google for you. To send traffic to Google you have to peer with them directory, or send it to one of your transit providers.

What does this have to do with bandwidth hogs? Simple. Bittorrent clients often have choices. It could get data from many different hosts. And right now it has no information on peering agreements. If it could tell that talking to one of those hosts is free, it could choose it over hosts that cost the ISP money.

Conclusion

Telecoms can do much better than stupid, draconian solutions. But it requires them to be honest about what they sell.


Which ISP sucks least?

April 10, 2008

Look at this sad network performance.

C:\>ping -n 10 24.82.128.1

Pinging 24.82.128.1 with 32 bytes of data:

Reply from 24.82.128.1: bytes=32 time=41ms TTL=254
Reply from 24.82.128.1: bytes=32 time=70ms TTL=254
Reply from 24.82.128.1: bytes=32 time=159ms TTL=254
Reply from 24.82.128.1: bytes=32 time=94ms TTL=254
Reply from 24.82.128.1: bytes=32 time=60ms TTL=254
Reply from 24.82.128.1: bytes=32 time=349ms TTL=254
Reply from 24.82.128.1: bytes=32 time=29ms TTL=254
Reply from 24.82.128.1: bytes=32 time=36ms TTL=254
Reply from 24.82.128.1: bytes=32 time=533ms TTL=254
Reply from 24.82.128.1: bytes=32 time=28ms TTL=254

Ping statistics for 24.82.128.1:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 28ms, Maximum = 533ms, Average = 139ms

Is it just me or are the major cable and DSL providers in the Vancouver area ripping us off? This has been going on for a week now, with the worst performance during prime time. A shaw support tech informed me this area needs to be “segmented”. In otherwords the company has oversold its infrastructure.

If someone wrote a small background program that monitored the performance of critical services such as my next hop router and my ISP’s DNS and sent that back to a central site I’d gladly run it. It would be nice to know which ISP sucks the least. The anadoctal evidence available now isn’t good enough. I heard some calls for community based monitoring of ISPs as use of deep packet inspection and throttling by providers has increased, but I don’t see much action.


Bandwidth monitoring and accounting with OpenBSD and pf

April 9, 2008

I’m sure this isn’t the only way to do it. Add this rule to pf.conf:

table <usage> const { 192.168.1.1 }
pass on $ext_if from any to <usage> label "accounting"

To see stats: pfctl -vv -t usage -T show
To clear stats: pfctl -t usage -T zero


Open source web framework “Hello, World” benchmark

March 7, 2008

I thought it would be fun to compare the response times of open source web frameworks. These come from ApacheBench 2.0.40-dev running on Linux (CentOS 5) inside VMWare. My computer is a dual Xeon E5345 @2.33GHz. The guest OS has 4GB of RAM and 1 virtual CPU. The purpose of this test is to determine the relative speed differences between frameworks for common tasks. Each test consisted of 10,000 requests. Concurrency was 1.

To provide a baseline for comparison, I built apache 2.2.8 and tested the index page.

Apache static file: 2991.65 Requests/sec with a time per request of 0.334ms.

Now on to the frameworks. First up is Ruby on Rails. The setup was about as basic as you can get. A simple view with no layout is rendered. The controller contains no code. Production environment was used. For the first test I ran against a single port in the mongrel cluster.

Rails on Mongrel: 485.85 requests/sec with a time per request of 2.058ms.

There’s a problem with this test. This is not a realistic way to run a rails site. You need to put a reverse proxy out front.

Rails on Mongrel behind Apache: 299.55 requests/sec with a time per request of 3.338ms.

Next up is PHP. There are a lot of different frameworks written in PHP. First I tested a simple PHP script that just prints hello world. I used the recommended php.ini.

PHP on Apache: 2518.25 requests/sec with a time per request of 0.397.

That’s not too far away from the static results. But to compare this to a framework is unfair. A full MVC framework does more by default. Common tasks such as mapping the URLs handlers, dealing with session cookies, and parsing templates add some overhead. It’s better to compare individual PHP frameworks.

The Symfony Project:

I used the sf_sandbox.tgz sample. I stripped out the graphics and CSS until I had a simple, un-styled, “Hello World”

Symfony: 32.21 requests/sec with a time per request of 31.048ms.

That’s so slow. I wonder how other PHP based frameworks do.

CakePHP: 34.90 requests/sec with a time per request of 28.657ms.

Also crappy performance. I’ll have to check with these projects to make sure there are no serious problems with my config.

Next is the Perl based Catalyst framework. I’m just testing the default index page.

Catalyst built-in server: 138.75 requests/sec with a time per request of 7.207ms.

Normally Catalyst is run in production under Apache/mod_perl.

Catalyst on Apache: 140.67 requests/sec with a time per request of 7.109ms.

I tried editing the Root controller to return “Hello World” rather than the larger welcome message. Results improved by about 6%.

I also want to try TurboGears but I’m having trouble getting it to run.

Conclusion: These preliminary results are not what I expected. Ruby has a reputation of being slow yet it outperformed the competition. The next step is to do a better job of setting up the tests to make sure each framework is producing exactly the same content and is performing the same amount of session and caching work.


This game rules

November 9, 2007

For a crappy little flash game, this one is awesome!


Finally, someone is fighting against non-transferrable software licences

September 16, 2007

Timothy S. Vernor filed suit against AutoCAD because AutoCAD used the DMCA to have his eBay account suspended for selling used copies of the popular software.

Non-transferrable software licences are unfair. The worst offenders are network appliance vendors who insist that the software powering their devices non-transferrable. They want to prevent their products from being sold second hand for a fraction of their cost. If you bought anything else pre-owned you would rightly expect better treatment from the manufacturer. You would receive warrenty service for a used Xbox as long as you have the original proof of purchase. Hard disk makers provide fair warrenty service in allowing anyone to send in a defective drive and receive a refurblished replacement.

In practice it’s a moot point as people (rightly) can’t be stopped from selling the hardware. If you buy any of these items off eBay don’t expect support even if you have everything in the original box. Some companies won’t even allow you to download security updates without a service contract. Shame on them.

I hope Timothy wins.


OpenBSD gets layer 7 load balancing

September 16, 2007

Just when I thought it was impossible to make a good HTTP load balancer with OpenBSD I noticed hoststated.

This avoids the problem of losing the client IP address by giving you a mechanism for manipulating HTTP headers. Now we won’t be needing more expensive solutions.


Reliable web business

September 13, 2007

I have worked for 10 years in companies that live or die by the uptime and reliability of their web sites. In that time a lot of things have changed. The tools for building feature rich web applications are better than ever. Frameworks such as Rails and Catalyst make web development much, much less painful than it once was. The Model/View/Controller design used by these excellent frameworks has even influenced traditional client side GUI application development practices, as anyone who has used Windows Presentation Foundation can see.

Despite better tools, web startups run into performance trouble. With a single machine running everything, highly dynamic sites can’t handle many users. Adding a second machine dedicated to the database gives a little relief, but not much. Over a period of a few months the server goes from locking up every other week, to at least each week, to every few days, until finally it’s hard to go 24 hours without downtime. Owners should have taken action, but usually squirm a bit like a lobster in a slowly heating pot. They keep rebooting, maybe trying to go with a faster server, or more memory. Many never realize how dramatically performance problems reduce their chance of big success.

Downtime kills web business. If you are down, or even slow, those who would have become your customers will go elsewhere. They will find satisfaction at a competitor and they won’t be back.

If this sounds like your current situation, you need to do something about it before it’s too late.

If you can get your hands on faster hardware within 48 hours, do it. Don’t wait. You must act immediately to stop the bleeding.

The next step is to put a solution in place enables redundancy and capacity planning. This not only allows you to keep sleeping next time your server crashes at 4am, it also makes it easy to predict when you will need more power so you can order new servers well in advance instead of settling for whatever is available right now.

This solution is supported by 3 components: Centralized Storage, Load Balancing, and Monitoring.

Load Balancing

Load balancing spreads incoming requests over multiple servers. I have used several different methods. Each method has advantages and drawbacks.

Round Robin DNS

When a browser goes to your domain, it asks its name server to fetch the IP address of your domain. It then connects. It is possible to have more than one IP address for a name. In such cases, the browser will connect to one of them at random.

Reverse NAT

It is possible to use reverse NAT such as that found in pf to redirect incoming connections to a pool of web servers. Using OpenBSD it is easy to setup a redundant pair of systems. The drawback to this layer 3 method is that your web servers can’t see the true IP address of the client. Everything comes from the reverse NAT device, so IP address based ACLs and GeoIP features are broken.

Reverse Proxy

The reverse proxy is an excellent solution because it works at the application (HTTP) layer. When the reverse proxy accepts an incoming connection it waits for the request to come in and then initiates its own request on behalf of the client. It can add headers to its request, so the back end web servers can know the real IP address of the client. Perlbal, Apache, and Big IP make excellent reverse proxies. I will write about each of these in more detail in a future post.

Centralized Storage

Depending on what features your site has, you may already have centralized storage. If your site stores all state and dynamic content in a SQL database then you’ll be fine. If there is anything stored on the file system it will have to be moved into the database, or MogileFS, which I will discuss in another post.

Monitoring

One important aspect of operations is real time monitoring for problems. You need to know immediately if your site is down so you can take action. You also need to have resource usage history for troubleshooting and capacity planning.

Nagios

Nagios will monitor your services for uptime, but it lacks performance graphs. It has some neat network maps, including a cool looking but useless 3D map.

Cacti

A better monitoring solution is Cacti. I recommend it over Nagios. There is excellent support for monitoring nearly every service you can think of. The graphs are very readable.

Throw in some smart power and you’ll have a very reliable and easy to manage site.


Don’t be cheap with RAM for your servers

August 8, 2007

Don’t put non-ECC RAM into a SunFire X2100. I was having problems with the network mysteriously failing under OpenBSD. On linux I experienced random panics. My advice, use the correct memory.