149 lines
15 KiB
HTML
149 lines
15 KiB
HTML
<!--startcut ==============================================-->
|
|
<!-- *** BEGIN HTML header *** -->
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
<HTML><HEAD>
|
|
<title>Security and the Linux Router Project LG #67</title>
|
|
</HEAD>
|
|
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#0000AF"
|
|
ALINK="#FF0000">
|
|
<!-- *** END HTML header *** -->
|
|
|
|
<CENTER>
|
|
<A HREF="http://www.linuxgazette.com/">
|
|
<IMG ALT="LINUX GAZETTE" SRC="../gx/lglogo.png"
|
|
WIDTH="600" HEIGHT="124" border="0"></A>
|
|
<BR>
|
|
|
|
<!-- *** BEGIN navbar *** -->
|
|
<IMG ALT="" SRC="../gx/navbar/left.jpg" WIDTH="14" HEIGHT="45" BORDER="0" ALIGN="bottom"><A HREF="evans.html"><IMG ALT="[ Prev ]" SRC="../gx/navbar/prev.jpg" WIDTH="16" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="index.html"><IMG ALT="[ Table of Contents ]" SRC="../gx/navbar/toc.jpg" WIDTH="220" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><A HREF="../index.html"><IMG ALT="[ Front Page ]" SRC="../gx/navbar/frontpage.jpg" WIDTH="137" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="http://www.linuxgazette.com/cgi-bin/talkback/all.py?site=LG&article=http://www.linuxgazette.com/issue67/fevola.html"><IMG ALT="[ Talkback ]" SRC="../gx/navbar/talkback.jpg" WIDTH="121" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><A HREF="../faq/index.html"><IMG ALT="[ FAQ ]" SRC="./../gx/navbar/faq.jpg"WIDTH="62" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="gilliam.html"><IMG ALT="[ Next ]" SRC="../gx/navbar/next.jpg" WIDTH="15" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><IMG ALT="" SRC="../gx/navbar/right.jpg" WIDTH="15" HEIGHT="45" ALIGN="bottom">
|
|
<!-- *** END navbar *** -->
|
|
<P>
|
|
</CENTER>
|
|
|
|
<!--endcut ============================================================-->
|
|
|
|
<H4 ALIGN="center">
|
|
"Linux Gazette...<I>making Linux just a little more fun!</I>"
|
|
</H4>
|
|
|
|
<P> <HR> <P>
|
|
<!--===================================================================-->
|
|
|
|
<center>
|
|
<H1><font color="maroon">Security and the Linux Router Project</font></H1>
|
|
<H4>By <a href="mailto:mf@agate.net">Mark Fevola</a></H4>
|
|
</center>
|
|
<P> <HR> <P>
|
|
|
|
<!-- END header -->
|
|
|
|
|
|
|
|
|
|
Exploits are about as prolific as kernel updates. Well okay, maybe not that common. Still, vulnerabilities are abundant for any OS no matter what the platform, and the vulnerabilities in Linux are no exception. The Linux Router Project (and Linux-based routers in general) have some unique security issues that Cisco and other proprietary routers do not have, because of the nature of the PC hardware and the Linux kernel. For example, buffer overflows are common with Linux, while hardware routers are almost immune to them. The LRP sysadmin must take care to recognize and address these vulnerabilities.
|
|
<p>
|
|
So on the one hand we have a different router for everything: ISDN, Ethernet, frame relay T1, xDSL, PPP, ..., even a [cable modem/portmapping router/Ethernet hub with a nifty graphic HTML interface], each device unique and purposeful for each unique and specialized routing application. And the source code and hardware is confidential and proprietary.
|
|
<p>
|
|
On the other hand we have a general purpose x86 processor that can do anything with the right software, and the Linux Router Project is a perfect application. It is creating an open alternative to proprietary routers in the same way that a grass-roots effort made Linux an alternative to proprietary Unices. The LRP is an actual Linux kernel, streamlined to facilitate routing in all its forms, and adaptable to just about any networking situation:
|
|
<ul>
|
|
<li>Speed and efficiency: No bloat, nothing unnecessary. Just routing, routing, routing.
|
|
<li>Disaster/Failure recovery: If for example you have an SMC NIC in your LRP box and it dies, you're able to stick a Netgear in it without trouble; simply load the tulip.o module instead.
|
|
<li>Security: The kernel touches all the hardware, the networking subsystem, the storage, the human interface. I'll get to this in a minute.
|
|
</ul>
|
|
<p>
|
|
Traditionally, firewalls and routers are discrete entities with one box being a router, another box being a filtering firewall, another box a proxy server or what have you. Each service has its own unique hardware, specially designed for the function it performs. In recent times the hardware for these devices started coalescing, much like the way ATA IDE is now built into the motherboard and treated as a part of the motherboard even though four years ago it was an ISA card.
|
|
<p>
|
|
Eventually these multipurpose routers will introduce a new discipline in security --and security means a million things. There's physical security, core (kernel, internal) security, network (routing) security. If the industry avoids proprietary hardware, it should rethink its security. Here's part of the plan:
|
|
<p>
|
|
<h3>I. Physical Security</h3>
|
|
<p>
|
|
<ol>
|
|
<li><STRONG><i>Policy.</i></STRONG> First write a Security and Audit Policy. You can't take over the world unless you have a plan. Enforce it. Start with a map of the network, and list:
|
|
<ul>
|
|
<li>What services are running on what machines
|
|
<li>Who gets what access levels
|
|
<li>Where the machines are located
|
|
<li>Other rules, e.g., passwords are eight characters one non-alphanumeric, etc.
|
|
</ul>
|
|
...even detail how often to hand-pass the bright red passwords floppy. When you see all these lists in front of you the rest of the plan flows--when you know <EM>what services run where</EM>--it's easy to make filtering rules.
|
|
<p>
|
|
<li><STRONG><i>Backups.</i></STRONG> Back up the LRP floppy. Don't waste time backing up the conf files, just blow an image (a la 'dd') of the entire disk. It's the best and fastest way to copy it. Be careful because some flavors of the LRP disk are larger than 1.44M and thus need to be mounted on (copied from) /dev/fd0u1680 or similar. Create the device with 'mknod' if you don't see it. There's no such thing as backing up too much.
|
|
<p>
|
|
<li><STRONG><i>Physical Security and Location.</i></STRONG> Since the LRP's facsimile for non-volatile RAM is a floppy disk, we need to lock the headless box in a room with no keyboard so no one can flip out the true floppy in favor of a counterfeit. Nor can they flip the floppy out and destroy it: a low-tech DoS attack. This plan works with Ciscos too, though there is no bogus quickboot. If sequestering the computer is not an option, crack the case and move the floppy drive back a couple centimeters. Insert the LRP disk and cover the drive with small plastic faceplate. This is called 'security by obscurity'.
|
|
<p>
|
|
<li><STRONG><i>Go Up.</i></STRONG> Real machine rooms have (in addition to restricted access, halon, backup power, air conditioning and wire conduits) devices in racks. Cosmetically the racks and raised floors are for cable management; practically the racks are for air flow, alien invasion, fires, floods, mop buckets, spilled coffee. Put the LRP router on a table. Even an old pallet works.
|
|
<p>
|
|
<li><STRONG><i>BIOS password.</i></STRONG> Remember that this box is also a PC. Use BIOS passwords. I'm not sure if any BIOSes on 486 boards have universal passwords so be careful.
|
|
</ol>
|
|
<p>
|
|
<h3>II. Core Kernel Security</h3>
|
|
<p>
|
|
Vulnerabilities between the Linux kernel and router routers differ. <A HREF="http://www.cert.org/summaries/index.html">CERT data</A> reports that the most common attacks are denial of service (DoS) and scanning. DoS attacks are easy to do and hard to defeat. Buffer overflows (uncommon) and DoS attacks (common) are possible in both worlds just the same. Port scanning can come from inside or outside. Scanning, though not an 'attack' per se, could easily be construed in a court of law as network reconnaissance, or even a denial of service, depending on the intensity. To my knowledge we have yet to see precedents.
|
|
<p>
|
|
We solve these two problems in the kernel with security patches and nmap. Of the main LRP distros, <A HREF="http://leaf.sourceforge.net/pub/oxygen/">Oxygen kernels</A> include the <A HREF="http://www.openwall.com/linux/">Openwall patch</A> --in fact Oxygen is continuously upgraded. If you see a vulnerability, rest assured it's in the latest Oxygen. According to David Douthitt, the brain behind Oxygen, the kernel itself protects "against IP spoofing, unusual packet addresses (martians), and [rejects] ICMP redirects and ICMP echo requests." --Even so, standard filtering (network security, below) should include these rules as well.
|
|
<p>
|
|
<A HREF="http://www.insecure.org/nmap/">nmap</A>: I call this <A HREF="http://www.fish.com/satan/">SATAN</A>'s successor. It's the touchstone security tool. nmap scans any set of TCP or UDP ports on any set of IP addresses to test and find vulnerabilities in your own network. nmap reveals unnecessary services running on the LRP box. There <i>are</i> unnecessary services running on some out-of-the-box LRP distros (e.g., discard, daytime, time). A quick trip to <A HREF="http://www.securityfocus.com/">SecurityFocus.com</A> or <A HREF="http://www.rootshell.com/">Rootshell.com</A> can tell you how to exploit them.
|
|
<p>
|
|
CERT does not discuss other common vulnerabilities from your own users on your own network such as filesystem security or sniffing. Filesystem stuff like fdisk, mke2fs or fstab does not warrant discussion here (though I do suggest that LRP developers include the chattr command with future LRP releases that allow non-root logins), and sniffing won't matter if you only log into the LRP box from the console. --Whoops, it's headless! We <i>will</i> worry about sniffing.
|
|
<p>
|
|
Ethernet sniffing is dangerous. In many cases it is possible to sniff other logical networks on shared cable modem Ethernet segments. Maybe even your neighbor's dynamic PPP connection from another dialup. Viruses and scans and every one of the eleventeen thousand "UNICODE bugs" are already so rampant we can expect sniffing to become much more common and widespread --maybe become a category for CERT if it isn't already. It's interesting how a lack of IP addresses peripherally facilitates cracking...
|
|
<p>
|
|
Encryption and authentication (<A HREF="http://www.ssh.com/products/ssh/">ssh</A>, <A HREF="http://www.openssl.org/">ssl</A>, <A HREF="http://www.ietf.org/html.charters/smime-charter.html">smime</A>, PGP) circumvent sniffing. But since any encryption can be broken over time the best we can hope for is that our data becomes obsolete before the encryption does. We protect the data for the most important window possible --such as a telnet session. Who cares if someone decodes it a year from now? Too many routers rely on password authentication that is subject to brute force attacks or worse, depending on the interface. Here the LRP wins. It supports ssh.
|
|
<p>
|
|
<h3>III. Network and External Routing Security</h3>
|
|
Physical Security and Core Security, though LRP specific (above) can and should be used in any situation. The following is a list of border security rules, pretty much universal, i.e., not LRP-specific. I include it here for completeness in my discussion of security types and will not go into great detail.
|
|
<p>
|
|
Schema for a typical business infrastructure border router:
|
|
<ul>
|
|
<li>Prevent RFC1918 private network addresses (192.168.0.0 and friends) from entering or leaving
|
|
<li>Block unapproved routing protocols to and from any destination
|
|
<li>Block access to NETBIOS over TCP/IP ports
|
|
<li>Block source-routed packets
|
|
<li>Prohibit spoofing of internal networks
|
|
<li>Filter or reject all TCP packets that are not connection open attempts
|
|
<li>Allow ICMPs to particular IP addresses
|
|
<li>Permit internal machines to service internal machines, especially nameservice and ssh
|
|
<li>Allow ssh to all hosts that support it
|
|
<li>Drop and log everything else
|
|
</ul>
|
|
<p>
|
|
The short answer is: "Block Everything." Allow access only to ports where services are running, such as port 80 for the webserver, port 22 for ssh. Wrap and chroot whenever possible (e.g., BIND). Running X on Internet-accessible machines is a big no-no.
|
|
<p>
|
|
Back to routing. Routing is not an easy task for the beginner, hence we have HTML interfaces for Circuit City routers and such. We also have Windows(tm). For others we have the LRP. The text-based LRP menu interface presents familiar annotated /etc/conf.files --simple for the Linux (Unix, Freenix) user but intimidating as a cryptic command line for anyone else. Other one-disk router approaches hold the same disadvantageous learning curve. However, the LRP brings the mysterious Routing Tao closer to geeks than other routers: The commands are familiar. Unlike a Cisco command line 'conf term', LRP configurations and commands don't get old and stale after not touching them for a year. For the non-geek the trade off between a thousand dollar router and the LRP is money versus time.
|
|
<p>
|
|
So you can buy a specialized router router, or you can tweak your vacuum-tube hardware and add wizbang features and compile modules into the LRP kernel and customize. The tradeoff is flexibility versus security. The LRP replaces non-volatile RAM with a floppy and embedded hardware with a kernel: Just keep some special security challenges in mind.
|
|
|
|
|
|
|
|
|
|
<!-- *** BEGIN bio *** -->
|
|
<SPACER TYPE="vertical" SIZE="30">
|
|
<P>
|
|
<H4><IMG ALIGN=BOTTOM ALT="" SRC="../gx/note.gif">Mark Fevola</H4>
|
|
<CITE>Mark earned a BA in Technical Writing and a minor in Computer
|
|
Science, Magna Cum Laude from the University of Maine. In 1994 he brought
|
|
the commercial Internet to the State of Maine by founding the oldest Maine
|
|
ISP. He spells grey with an 'e', never wears watches, hates mushrooms,
|
|
reads books, and collects minerals.</CITE>
|
|
|
|
<!-- *** END bio *** -->
|
|
|
|
<!-- *** BEGIN copyright *** -->
|
|
<P> <hr> <!-- P -->
|
|
<H5 ALIGN=center>
|
|
|
|
Copyright © 2001, Mark Fevola.<BR>
|
|
Copying license <A HREF="../copying.html">http://www.linuxgazette.com/copying.html</A><BR>
|
|
Published in Issue 67 of <i>Linux Gazette</i>, June 2001</H5>
|
|
<!-- *** END copyright *** -->
|
|
|
|
<!--startcut ==========================================================-->
|
|
<HR><P>
|
|
<CENTER>
|
|
<!-- *** BEGIN navbar *** -->
|
|
<IMG ALT="" SRC="../gx/navbar/left.jpg" WIDTH="14" HEIGHT="45" BORDER="0" ALIGN="bottom"><A HREF="evans.html"><IMG ALT="[ Prev ]" SRC="../gx/navbar/prev.jpg" WIDTH="16" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="index.html"><IMG ALT="[ Table of Contents ]" SRC="../gx/navbar/toc.jpg" WIDTH="220" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><A HREF="../index.html"><IMG ALT="[ Front Page ]" SRC="../gx/navbar/frontpage.jpg" WIDTH="137" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="http://www.linuxgazette.com/cgi-bin/talkback/all.py?site=LG&article=http://www.linuxgazette.com/issue67/fevola.html"><IMG ALT="[ Talkback ]" SRC="../gx/navbar/talkback.jpg" WIDTH="121" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><A HREF="../faq/index.html"><IMG ALT="[ FAQ ]" SRC="./../gx/navbar/faq.jpg"WIDTH="62" HEIGHT="45" BORDER="0" ALIGN="bottom"></A><A HREF="gilliam.html"><IMG ALT="[ Next ]" SRC="../gx/navbar/next.jpg" WIDTH="15" HEIGHT="45" BORDER="0" ALIGN="bottom" ></A><IMG ALT="" SRC="../gx/navbar/right.jpg" WIDTH="15" HEIGHT="45" ALIGN="bottom">
|
|
<!-- *** END navbar *** -->
|
|
</CENTER>
|
|
</BODY></HTML>
|
|
<!--endcut ============================================================-->
|