[ Site Index] [ Linux Index] [ Feedback ]
Broadband Networking and Linux
SUBTITLE: Broadband networking
I've been on the internet for eleven years, modulo a six month disconnect, and I've had a connection to my home since 1993 -- starting out with a UUCP dialup connection over a V22bis modem running at a staggering 2400 baud. I've now reached the point where I am hopelessly dependent on the internet for work; this column is filed via email every month, for example, and I get to do most of my research online. (After all, Linux is quintessentially an internet success story; without the support the internet provides for collaborative working, Linux simply wouldn't exist.)
Until this month, my internet connectivity consisted of two halves: a dialup modem connection into Demon Internet, and a co-located server -- a box running linux, owned by myself, sitting in an ISP's rack space. Note that Demon was my choice of ISP not only through loyalty (I signed up in their first six months, back when they were the first ISP in the UK to offer TCP/IP connectivity at a sane price), but because they provide a fixed IP address. Most ISPs give you an IP address from a pool that they maintain whenever you connect, so your address probably varies with every dialup session. Demon's practice of handing out a fixed IP address for each customer is a boon to those of us who have co-located servers -- it makes authentication a tad easier (although I'll have more to say on that subject later).
I'm not happy with the modem connection, though. For one thing, it's slow: running flat-out, my 33.6K modem can transfer up to 300Mb in a 24 hour period. (No downloads of CD-ROM images of linux distributions here!) For another thing, it costs -- even given 1p/minute off-peak rates, that's one pound per 20Mb.
But this year, things are changing in the UK. OFTEL, the regulatory regime responsible for keeping BT's monopoly under control, seems to have finally cottoned on to the idea that consumers want flat-rate dialup. They've also mandated the unbundling of the local loop -- that is, BT will have to give other telcos direct access to that mile of copper wire in the ground that links your home to the telephone exchange. Under pressure, BT have agreed to provide an ADSL (asychronous DSL) service for consumers wanting broadband data -- ADSL connections will be on-line all the time, twenty four hours a day, at a flat rate. (Your ISP will charge for this, passing on a chunk of the money to BT in return for BT wiring you up.)
ADSL speeds are roughly 256Kb download and 64Kb upload -- it's asymmetric, like the old V23 modems that downloaded at 1200 baud but could only transmit 75 bits per second upstream. Note also that ADSL speed will vary with the distance between you and your nearest ADSL-capable telephone exchange -- the further away you are, the slower it goes. ADSL is a star network, like 10baseT ethernet; you get your own line into the exchange (equivalent to your ethernet hub).
There's also competition from the cable TV companies. If you have digital cable TV, chances are that your local cableco is reserving a couple of channels for data. Plug a cable modem into their network and you can get broadband internet connectivity at roughly 256Kb download (burstable to 512Kb) and 128Kb upload. One disadvantage is that this is a ring network, like thinnet; you and your neighbours tap into a cable loop, so if someone else is hogging the bandwidth, your throughput may drop.
All the ISPs working on broadband consumer connections are relying on caches to moderate their demands on external networks; they expect most of the traffic to be web surfers browsing graphics-rich sites, so they try to make sure that as little traffic as possible needs to be forwarded to the internet at large. They're also adopting acceptable use policies that basically boil down to "thou shalt not run a server on our network".
Well, that's fine by me; I have a colocated box specifically to host my public servers. I want the benefits of broadband networking so that I can talk to that server, surf the web faster than I can today, and not have to wait thirty seconds while the modem connects. But what are the drawbacks?
For starters, the obvious one is that none of the broadband suppliers (except Demon Internet, whose ADSL trial is not available in my area) support anything except Windows 95 or Windows 98. But let's leap over that objection -- TCP/IP networking is pretty standard, and the broadband suppliers allocate dynamic IP addresses via DHCP (dynamic host configuration protocol) which Linux understands. The appropriate response is to set up a "sacrificial" Windows box that the engineer can install software onto when they come to install your connection -- then to copy the configuration details onto your Linux system.
In general, your Linux system sees a cable modem or an ADSL router as just another router -- one which presents an ethernet or USB interface and which has an IP address. You tell your Linux box that the cable modem or ADSL router is a network gateway and route all TCP/IP traffic through it; the router then copes with the arcana of moving packets back and forth between your system and the outside world. USB support is a bit problematic -- read, Linux doesn't support it yet -- but most cable modems (and BT's business ADSL offering) use 10BaseT ethernet; you plug it into your hub or use a crossover cable to connect it to your Linux system directly.
I acquired my cable modem connection from Telewest. I'd have preferred an ADSL connection via Demon Internet, but it isn't available in my area yet: and I need the bandwidth now, not in a year's time. Getting the box hooked up was moderately annoying, but do-able. Basically, a bunch of Telewest engineers turned up at the appointed time. After drilling a hole in the walls to get the cable into my office, they installed a white box -- a SurfBoard SB3100 cable modem. This box resembles a modem, but instead of a serial cable it presents a 10BaseT ethernet port to your PC. (This port is wired crossover-style to talk to another computer's 10BaseT port, instead of talking to a hub -- although it isn't labelled as such. Being too smart for my own good I'd provided a hub, then spent an hour scratching my head and wondering why nothing was working.)
Telewest's service has three extremely annoying gotchas. For starters, you will require a Windows 95/98 system to plug into the cable modem. They won't install it if you can't show them one! There's a written checklist for the engineers to follow, and they have to verify that you are running the right software. Never mind that they supply nothing that won't work perfectly well with Linux (or MacOS, or an Acorn Archimedes for that matter) -- Windows is the One True Way.
Rather more seriously, although they provide dynamic IP addresses, Telewest require the MAC address of the ethernet card you're going to plug into the cable modem. This is a fixed parameter of your hardware, burned into the ethernet card's ROM. Want to change machines or use a different ethernet card? You'll have to talk to Telewest's support line -- and although they're patient and polite, they insist on talking you through a fixed script of questions before they'll even think of discussing anything else with you.
The IP address allocation takes place inside the cable modem itself, which runs a DHCP server. If you've got Red Hat on your Linux box, look into pump(8) (which acquires an IP address via DHCP; if you're using Debian or Corel Linux, look into dhcpcd, a DHCP daemon that can also grab DHCP addresses for the local machine. You just point dhcpcd or pump at the ethernet interface the cable modem is plumbed into, and it grabs an address for you.
In use, the cable modem connection has two pleasing advantages over a normal modem. That download speeds of 40-70Kb per second are nice almost goes without saying; but the other fun thing is that it's on all the time. No more waiting for a dialout connection! Or is there? That brings me to feature #3 of the Telewest Blue Yonder service that I'm not entirely happy about -- their routing. My colocated server sits in a rack fed from a Cableinet leased line. My cable modem is also fed via a Cableinet leased line. So why the hell can't Cableinet route packets from one machine to another? This sort of bizarre internal routing snafu wouldn't be tolerated in any other industry -- much less a snafu that hasn't been fixed a week after a complaint was first lodged. One symptom of the demand for broadband networking is that providers are rushing to keep up with demand -- and as a result, sometimes there are problems. Caveat Emptor!
There is a problem with broadband connections -- a problem that the telcos and cablecos don't talk about much. You are on the net twenty four hours a day, seven days a week. This means that you will be port-scanned by automated cracking tools on a regular (daily, or more frequent) basis. Not "might" be port-scanned -- you *will* be port-scanned. There are cracker toolkits out there that script kiddies run from their own broadband systems, or ones that they've compromised and gained a root login on. These tools ping every host from a broad range of IP addresses. Whenever they get an answer, they attempt to create connections to a bunch of well-known TCP/IP ports on that machine, and analyse the pattern of responses to work out what operating system it may be running. They can then exploit any known weaknesses to gain a root login on the victim's machine.
Such toolkits are so heavily automated that a dyslexic capuchin monkey with attention-deficit disorder could use one, and the goons responsible probably don't live on the same side of the planet as you do. In fact, the machine doing the probing probably belongs to a hapless victim who doesn't know that they've been taken over. You can't stop this happening, and you can't ignore it, because if you ignore it your machine will be hacked sooner or later. This is an occupational hazard of running a leased line or a colocated server -- but people who do those things usually have an inkling of the risks involved when they're shelling out thousands of pounds a year for the service. Now, Joe Public can share in the fun!
The solution to this problem is to run a firewall.
SUBTITLE: Firewalls
A firewall is basically a machine with two network connections -- an inward-facing one, and a public one. Packets coming in on one interface are filtered (checked against a set of rules about what to let through), and either discarded or passed on to the other interface. I would strongly recommend that before you even think about firewalling, you should read "Practical UNIX and Internet Security" (Garfinkel and Spafford, pub. O'Reilly & Associates Inc., ISBN 1-56592-148-8) and if possible the classic book on the subject, "Firewalls and Internet Security: Repelling the Wily Hacker" (Cheswick and Bellovin, pub. Addison-Wesley, ISBN 0-201-63357-4). If nothing else, your Linux distribution probably comes with a copy of the Linux-Security HOWTO, a document that covers (in some detail, albeit tersely) the high points of how to secure a Linux system that's going to be exposed on the net, and the Firewall-HOWTO, the subject matter of which should be obvious. Finally, go look at Linux.com's security articles. If you're not paranoid now, you will be by the time you've finished reading these monographs.
In general, it's best if the firewall machine does nothing else. You don't want to configure your desktop workstation as a firewall; if you do, any attack on the firewall is likely to compromise your personal files. Moreover, you'll be running additional software -- with who-knows-what possible back doors or buffer overrun vulnerabilities -- on the machine that's most likely to come under attack.
Luckily, you can build a firewall for not very much money. The easiest way to go about it is to buy an ancient PC (a Pentium 75 will do, happily). Fit it with 12-32Mb of RAM (no need for more!), a floppy disk drive, and two cheap NE2000 ethernet cards. As your broadband connection won't go over about 2Mbps, there's no point using 100Mbps cards; elderly ISA-bus 10BaseT cards will do fine. You don't want a hard disk or CDROM in this machine; its job is to boot off a floppy, then run continuously for months on end, forwarding packets from one ethernet card to another.
(A stripped-down elderly PC should cost 30-50 pounds, and you can expect to pay 5-15 pounds for each interface card. This price is comparable to a month's subscription to an ADSL or cable modem service, and it will save you endless misery if you come under attack.)
The firewall box should be connected to your cable modem via a crossover 10BaseT cable, or via a hub. Your workstation (or home network) should be connected to the other ethernet interface on the firewall box. (It's a good idea to ensure that the firewall is physically between the internal network and the external gateway -- that is, you don't plug the gateway into the same hub as everything else.) Finally, we need to install some appropriate software on the firewall.
SUBTITLE: What firewalls do
The Linux kernel makes a fine firewall, with some customization, but it is not appropriate to use a standard Linux distribution such as Red Hat or SuSE or Debian. General-purpose distributions come with too many bells and whistles, representing potential vulnerabilities. When setting up a firewall, you want just the kernel, and a minimum of necessary tools to configure its behaviour and handle logging.
Linux has a number of firewalling systems, each relevent to a different release. Linux 2.0.x kernels used ipfwadm to specify firewalling rules. This was replaced by the more general ipchains system in the 2.2 kernel series. When kernel 2.4 is out (or right now, if you live on the bleeding edge), another system of specifying packet filtering rules will come in. In general, though, all of them have certain common characteristics.
Firewalls rely on a kernel that can keep track of two or more network devices (usually ethernet interfaces, but you can use PPP -- or anything else -- as well). Packets can be routed from one interface to the other. In addition, the kernel can filter packets in accordance with a table of rules. The rules are applied to each packet in order and a conclusion is reached (that the packet should be allowed through, or that it should be rejected). In general, a firewall starts with a single rule that rejects all incoming packets. Additional rules are then specified that override the original 'reject' rule -- for example, we can specify that TCP packets on port 80 are to be accepted (which you'd want if you're running an HTTP server on the inside of your firewall). You can also specify where you are willing to accept connections from -- for example, you might specify that TCP packets on port 80 will be accepted only from a local network.
The firewall can usually also do network address translation (masquerading). Connections from a host behind the firewall are received by the firewall. It works out that the packet is destinated for the outside world, and assigns a port to handle this connection. All data coming in on this connection goes out on the port, and the masquerading kernel ensures that data coming in on that port goes back to the correct host.
There exist specialised Linux distributions that are tuned for duty as a firewall; the Linux Router Project's Materhorn release (2.9.4 of the software -- also at lrp.c0wz.com) is one example. Materhorn consists of a bootable floppy disk image with utilities. When booted, it creates a RAMdisk, and provides the appropriate tools for configuring a firewall using ipchains (the Kernel 2.2 packet filtering ruleset). It's documented, too.
An easier alternative is Coyote Linux, a distribution specifically intended to set up firewalls between a home network and a broadband connection provided via ethernet. As with Materhorn, Coyote linux fits on a single floppy; the difference is that it provides shell scripts (or a Windows setup wizard, if you want to pay money for the non-free version) to configure the system. It is able to cope with dynamic IP address allocation via DHCP, and is set up to masquerade a bunch of machines on the inside of the firewall. (Masquerading allows machines behind a gateway to use external internet services. The gateway keeps track of where the connections are going, so that to the outside world they all appear to originate from the single gateway machine: but packets coming back get returned to the correct host on the other side of the gateway.)
It is possible to install an ssh daemon on your firewall. Ssh (secure shell) is an rlogin replacement; it provides textual terminal access to a UNIX or Linux host. Unlike rlogin or telnet, ssh connections are encrypted; you need to install public keys on the ssh server host, but once they're there you can connect to that machine from your client without worrying unduly about network packet sniffers capturing your keystrokes and password. Note that the ssh tools themselves are not open source; however, they've been cloned by the open source community, and OpenSSH is readily available.
I plan to connect a custom-build firewall running Coyote linux to the cable modem Real Soon Now -- as soon as I can get the MAC address for my ethernet card changed over, in fact. (Guess why I don't like ISPs that provide dynamic IP?)
SUBTITLE: Virtual Private Networks
An interesting point about ssh is that it allows you to forward TCP/IP connections on a given port from the client host to the server (and back again). This lets you set up an encrypted "tunnel". You can designate an IP address on the inside of your firewall as being one end of the tunnel; packets sent to it reappear at the other end of the tunnel (on the ssh server) and proceed from there. The traffic isn't aware that it's being routed all over the place -- as far as it's concerned, the ends of the tunnel are a single network hop apart. In transit, they're encrypted -- meaning nobody can snoop on your data. The connection running over this tunnel is often called a VPN -- Virtual Private Network -- because it's a virtual network, layered on top of a real one.
By running an VPN, you can effectively make your colocated server appear as a machine on your local network, behind your firewall. This is not without its risks -- you want to ensure that the colocated box is nailed down! In fact, you probably want to keep it at arm's length, unless it, too, has a separate firewall box (in which case your VPN runs from behind your home firewall to the server on the other side of your remote firewall).
There are several ways to run VPNs other than ssh. There are easy-to-use dedicated VPN daemons that you can install; some of these support PPTP, point-to-point tunneling protocol (a protocol designed to support VPNs, with or without encryption). IPsec allows for packet-level encryption of IP packets; when used in conjunction with PPTP it provides an encrypted VPN. Tinc (from tinc.nl.linux.org) is a self-contained VPN daemon designed to create encrypted VPNs; unlike PPTP-based VPNs, tinc encapsulates network packets in UDP packets, rather than glomming them into TCP or PPP over TCP. Vpnstarter (http://detached.net/vpnstarter/) is another VPN kit. There's a VPN kit built into Coyote Linux (see above), using PPTP and supporting Network Address Translation (NAT, also known as masquerading) so that all the hosts on the inside of the firewall can use the VPN; this may be the easiest solution to setting up a firewalled local network inside a cable modem or ADSL connection, talking to an external colocated server. More on this in a couple of months -- once Telewest sort out their routing tables!
[ Site Index] [ Linux Index] [ Feedback ]