Stephan Schwab - networking tag

Interesting idea from the US: instead gas tax breaks use the same money for highspeed networks

Sat, 03 May 2008 19:47:46 GMT

The context of this is the upcoming election of the next US president and although I'm not a US citizen and have anything to say about this particular topic it does refer to a thought I carry with me since the early days of running an Internet Access Provider in Germany back in 1994.

Dave Winer in Scripting News for 5/2/2008:
And the money we’d give up for Federal gasoline tax could be better spent on putting high capacity network lines under our streets to increase communication. Some of the car trips must be to exchange information that coud be replaced by moving packets around at gigabit speeds. It wouldn’t cost much to retrofit a few cities with really high speed lines, then we could get to work on developing the services that would make life more interesting, fun and efficient.

Virtual machines as crash test dummies to detect infections

Mon, 25 Sep 2006 03:45:26 GMT

This could be the most important milestone in the history of intrusion detection systems ever. FireEye announced a new appliance that uses virtual machines as crash test dummies to detect infected devices on a network:

FireEye technology uses virtual machines as a sort of crash test dummy for network security. Potentially damaging network traffic is sent into the virtual machines where the impact can be analyzed. If suspicious traffic is revealed, a responsible course of action can be taken to stop the network infection. No actual machines are harmed in this process and the damaged virtual machine is fully restored for reuse.

Although FireEye's website doesn't tell much yet about how it works Dark Reading, a ZD Net blog and Security Vibes provide some more information.

Apparently the appliance executes several virtual machines (VM) with instances of the Windows operating system and Windows applications used in the enterprise. Those VMs are then used as targets for the potentially harmful traffic. If a VM gets infected it should reveal suspicious network traffic and then the appliance takes action.

According to the information currently available the appliance is not in-band, but connected to a monitoring port on a switch to be able to see all packets passing through the switch. If harmful traffic is found the switch port it originated from is turned off.

Further the VMs resemble the different releases of operating systems the enterprise uses. That means one VM for each combination of Windows version (NT, Win 2000, XP) and service pack. That's quite a lot of VMs.

This sounds almost too good to be true. I can think of a lot of questions about how this really works and how it will scale. The idea by itself is brilliant. There is no doubt about that.

Some of my first thoughts about the implementation challenges were:

A 100 mbps link, if fully used, transmits about 750 MB per minute. That's slightly more than the content of a CD-ROM. On a typical DSL link with 256 kbps utilization it would still be 1.9 MB per minute.

The appliance has to send this amount of traffic simultaneously to all the VMs and check whether any of them shows strange outgoing traffic short after. If there are 10 VMs we are talking about 19 MB per minute that have to be processed in the case of the tiny DSL link. For the fully utilized 100 mbps link it would be 7.3 GB per minute.

Further the appliance needs to remember where the data came from. Without that knowledge it can't shut down the switch port of the infected device. Not every virus or worm starts sending packets right away. What if it waits an hour or a day?

As the appliance needs to wait for VMs to be become infected, it has to clean up and restart the infected VM in a clean state. That takes a moment. What will happen, if there are already several viruses or worms active in the network or new infections happen shortly after another? The load of the appliance and its memory requirements will increase. For every infected VM a fresh copy needs to be available in the background. I guess there will be a limit on how many infections can be detected or handled.

I'm not saying it's impossible to create such a device. But it is definitely a big challenge. And if FireEye has made it, then it will be a big success.

WiFi phone for Skype

Mon, 25 Sep 2006 03:43:45 GMT

As more and more WiFi hotspots appear all over the world it was only a question of when for the WiFi phone to be available. Now Netgear introduces the Netgear Skype WiFi Phone. You can use it to call anyone on Skype without a PC and via Skype-out regular phone number. It displays the contact list in the same way the Skype client on Windows or Mac OS X does. You can see who is online and select the contact to make the call.

It can be pre-ordered at the Skype store or Amazon. Here is the press release from Netgear.

That's quite an interesting move. It might be a very useful device for frequent travelers and be a blow to cell phone companies that bill horrendous roaming charges. This phone has now gotten on my watch list. Currently I use Vonage's softphone on my laptop and the Vonage service with a VoIP phone adapter in the office and at home. Calls between all the numbers in my account are free - just as Skype is free as well.

The only drawback, and it's a big one, is that this phone is not usable at hotspots that require you to visit a website first in order to use the hotspot. Unfortunately a lot of hotspots at hotels and airports are implemented that way.

No default route for PPTP connections

Fri, 28 Jul 2006 17:10:00 GMT

Ever wondered how you can avoid Mac OS X' PPTP client to set the default route to the remote gateway? It's a bit annoying that you loose your Internet access, if you connect to PPTP server that doesn't allow your packets through to the Internet.

Bitflux has a good description about how to tell OS X' PPTP client not to change your default route. In short:

Create the directory /etc/ppp/peers, if it doesn't already exist. Then place a file with the exact name of your PPTP connection in there. Write nodefaultroute to that file and when you fire up your PPTP connection your default route will stay untouched.