|
|
|
|
Last Updated: 16-Feb-2006
What is IPCop
IPCop is a stripped-down Linux intended exclusively for use as a full-featured, highly secure firewall / Internet access gateway.
What prompted me to set up an IPCop box
IPCop is much more reliable than the Linksys BEFW11S4 v.4 wireless/router I had been using (entirely inadvertently, I assure you ;) The BEFW11S4 was ok for Internet surfing - after I finally worked out all the different kinds of traffic we used that would cause it to freeze, including Multicast in RealPlayer. However, the BEFW11S4 was hopeless for trying to run any kind of server - it was far too flaky, and kept losing the port forwarding, or crashing. Also rather annoying was the way its DNS server would become unresponsive for periods of time, so you couldn't reach Websites unless you set up each computer individually with its own DNS servers (not the address of the Linksys box). </rant>
Installation (and hardware)
IPCop will run on old hardware that would otherwise be considered obsolete; even as little as a 386DX with 32MB of RAM and a 300MB hard disk (IPCop cares more about memory than processing power). However, if you plan on serving 10 or more clients or running features such as Intrusion Detection Logging, I recommend at least a Pentium-75MHz, 64MB of RAM, and 600MB hard disk. I decided to install IPCop on an AMD Thunderbird 700MHz box, with 64MB of RAM and a spare Seagate 600MB IDE HDD I had lying around. IPCop needs seperate network cards for each of its security zones, so I opted to use two network cards, one for my internal private network, and one for the external Internet-side network (consisting of my Ethernet Speedstream DSL adapter).
Initially, I tried to install on one Kingston KNE100TX "Tulip" 21143-based NIC and one Linksys LNE100TX ver4.1 NIC, but the version of Linux IPCop is based on (at least) did not detect the Linksys network card by default, so I was unable to configure a network interface for my DSL adapter. Rather than mess around with trying to install drivers for the NIC on an unfamiliar Linux and forgo the convenient installation wizard, I decided to switch to two Kingston LNE100TX "Tulip" 21143-chipset-based NICs and reinstall off the CD, wiping the first installation (it's pretty fast, especially with the 24X CD-ROM I had mounted on it). This went better, and allowed me to configure both network interface cards.
Troubleshooting slow downloads
For some reason, my DSL performance dropped from over 2Mbps to around 768Kbps when downloading. CPU utilization was below 1%, sufficient memory was available, etc, but for some reason my downloads were very slow. To cut a long story short, it turns out the short 18" RJ45 cable I was using between the IPCop box and the Speedstream ADSL adapter was impeding performance. I suspected that there might be a problem when I decided to use it, because the minimum specified 10/100BaseT cable length between nodes is 2.5 meters (some people recommend at least 2 feet, which is still more than what I had), but I expected it to either work fine, or not at all. It does conform to the EIA/TIA 568B twisted pair network cable color code standards, so I figure it's intended for use in a patch panel, in conjunction with a longer wiring run. I replaced the much-too-short 18" patch cable between my IPCop gateway box and the Ethernet DSL adapter with a 10' Cat5 Ethernet cable I found, and suddenly my download speed jumped up to 2.4Mbps again. This likely applies to Smoothwall and Monowall boxes as well.
Distributed Computing on Your Router
The computer I loaded IPCop on, a 700MHz AMD Thunderbird, is extreme overkill for the purpose it's being put to. Even under heavy multi-threaded downloads, and running the Snort Intrusion Detection System, CPU utilization rarely reaches 3%. I prefer not to let idle CPU cycles go to waste, especially when I can score points on my favorite distributed computing project, so I decided to load Folding@Home on it. The question was how to load the FAH504-Linux.exe client on it, since the only file transfer method IPCop supports is SFTP via Ssh (well, aside from using a floppy disk). I found a simple solution in the WinSCP Freeware SFTP and SCP client for Windows, which was easy to install, and allowed me to move on to copying the file.
First I logged into the router (192.168.0.1:81 in my case, since it uses port 81, not 80) and enabled SSH Access (under the System drop-down menu). Then I ran WinSCP and supplied the IP address of the IPCop router as the Host name (192.168.0.1), the default port for IPCop SSH (222, not 22), the root login and password, and hit login. It worked quite nicely, showing local files in the left-hand windowpane, and remote files in the right-hand windowpane. Uploaded the FAH client to a /home/folding_at_home directory on the remote system. The next step is configuring F@H user settings via SSH.
I have a Linux box, so I used its copy of SSH to log into the IPCop box. However, if you're running Windows, there's a Linux-like environment for Windows called Cygwin that runs inside of Windows and gives you access to common Linux tools (among other things). Logged into the remote system via SSH ("ssh -l root 192.168.0.1 -p 222"; that's a lowercase L before root), and ran the command-line configuration on Folding@Home (team 14 for Ars Technica, etc).
Testing & Conclusion
I haven't been able to overload IPCop, even running Bittorrent downloads (e.g. of Linux .ISOs) with over 100 active file streams. Ok, so I managed to interrupt streaming music to network computers once, briefly, when I loaded up a saved Firefox session with 31 tabs open to various gallery sites with dozens of large images on each page, and the computer downloaded/checked all the images simultaneously, but I haven't bothered to configure traffic-shaping yet, so it's pretty normal that Firefox sucked most of the bandwidth out of the Internet connection. The streaming music resumed once it finished loading the tabs, and looking at the IPCop resources, it appears that burst of network traffic didn't increase memory or CPU utilization appreciably.
It performs well (from my point of view) on GRC.com's Shields Up! port scanning test - I have it set to respond to ping, and port 113 is closed rather than stealthed, but I'm not convinced that's an issue, especially since I'm port forwarding to a webserver on my internal network on port 80, which reveals me anyway. With the Intrusion Detection System set up, I see a lot of logs of various types of intrusion attempts that have been blocked by the Snort.org rules. Ping requests (matching certain rules) and various web server attacks seem to be the most common. So far I haven't experienced any problems with legitimate traffic being blocked.
IPCop is highly configurable and works as advertised.
Related
Return to Wireball.com homepage.
S p ä m b ö † - b ä i † (by Wpoison)
This page is copyright ©2006 David N. MacCarter. All rights reserved.
All brand and product names are trademarks or registered trademarks of their respective companies.
E-mail the Webmaster
Please note - by company policy, spam* is deleted without being read. Thank you for your understanding.
* - Unsolicited mass e-mailings
Hits since 23 February 2006:
FastCounter by bCentral
|
|
|
