Am looking for an ipaq or similar sized unit which can server as a firewall (need to be able to be equipped with two NICs). I figure there's some old duron or celeron model that will fit the bill but don't know enough about all the older network appliance and thin client options to know what to look for. I'll be putting Linux on it so I can have logging and use IPTABLEs and NAT. My old duron with it's roaring fans and 300W power supply works great but the noise and size of the thing is getting me down. Suggestions?
What I'm using at home is what is left of an ancient laptop. No case, no keyboard, no display. Admin by SSH from the LAN side only, with a backup of a remote serial console running off the serial port.
Very little logging is needed. That laptop I'm using is a 386SX-16 and is more than adequate for a cable connection while drawing just
40 Watts (including the hard drive). There are plenty of 'firewall optimized' distributions, some small enough to _run_ from a single floppy. google is your friend. Remember that the _ONLY_ thing that should be running on the firewall is the firewall itself. No user crap - and specifically, no X. It's amazing how little resources are needed when you get rid of the eye-candy. Think about it - if it's not installed (never mind not running), it can't be exploited.
I have my laptop, a Compaq armada e500, running as a server now. When I close the lid(screen) it only draws 15 or 16 watts
It has one ethernet connection, a disk of a 7 gig, more than enough to run Win XP , apache mysql, an ftp and mail server and any other facility you might need. It has a telephone modem , so it can have a fax server too. Nice to try out things, like a virtual office. More disk space than you will ever need. Backup via the intranet.
Running it only costs me 2.30 euro a month in electricity. Of course: you will need a replacement laptop sometime...
Laptops are designed to be power-lean and silent. why don't they make desktops that way ?
There are many products in the market. Try a very small unit, cheap but good enough: you do not need a 'mainfream', If you know what I mean. Look for it in Internet (about boards): have in mind that there is going a change of platforms, from 32 bits to 64 bits. Linux it is OK. Regards.
The Internet side of the firewall is generally a 10 Megabit Ethernet style connection - and only with rare exception is the data rate in excess of that. A 16 bit ISA bus - used on the 80386SX can handle 15 MegaByte per second. A 32 bit ISA bus can handle anything a cable/DSL connection can provide without raising a sweat. The main problem with the ISA bus is handling 100 Megabit LANs as there were not that many interface cards capable of that speed (ex: 3C515). Laptops also make it difficult to have two independent network cards - difficult, but hardly impractical. I think the remnants of the laptop I'm using was an Acer (I got it from a spare parts table at a yard sale) - certainly it's a 386SX-16 with two
10BaseT network cards and a modem (for a backup connection to the world) and a second serial port used as a backup connection for administration. It is more than adequate.
Your firewall will need more recourses if it has a display of a police officer directing characters riding in toy cars representing traffic that the firewall is passing. Most people find that the firewall itself works quite well without this crap. Likewise, the firewall does not need to mail self-congratulatory messages to every user announcing that it has blocked "an attack" from some random address out in the world. The connection was blocked - it's over - get on with your life. Nothing you can do will cause the Internet Police to come an arrest the owner of the remote computer.
I was considering the laptop option however since most old laptops have only USB 1.1 ports, I didn't think there was a way to host two ethernet ports. I found the IPAQ has the same problem so no dice there either. How have those of you using laptops gotten around this problem?
Moe, This is a marginally related question. My only experience with firewalls has been the use of a router (basic functions) and a software firewall to augment. Please give me your opinion on using this simple combination to protect and administer a Freenet (or similar) server. Do you think this would be adequate or would I be better off learning how to build a proper firewall? ~Thx
If all you expose inbound is port 80, and you're running a locked down OS, and you're locking down the application you expose, then a NAT Router with port 80 forwarded inbound (and only port 80), would limit your exposure/exploit paths.
The NAT routers only "route" traffic, they don't really inspect to ensure that the HTTP traffic is really HTTP traffic.
If you can, on your NAT Router, block all outbound ports except DNS and HTTP (since many AV solutions get updates over HTTP).
My personal preference would be for a simple box connected to the Internet side of things that only permits those connections INBOUND that the administrator wants to allow. If you are providing a web server, then someone connecting to your Internet address should ONLY be able to connect to port 80 and/or 443 or where ever you are running that server. There's no need for them to connect to your gopher server, or finger, or telnet, or SSH or any other port, period. You can do this connecting the server directly, (and allowing _your_ administrative connection via a different interface), depending on your skill level.
Two things - know how to build a proper _server_ (which mean one that has the needed applications and no more than that), _and_ know how to build the firewall. The first point is important - if it's not installed, it can't be exploited. Our "public" servers all run from 'read-only' media as an added precaution, and any volatile data is mounted 'noexec'. It's much harder to exploit that way. Anything uploaded from "outside" gets dropped into a directory with d-w-rwx--- permissions - the 'w' to allow the data to be written by a user with NO other permissions anywhere else on the file system, and the 'rwx' to allow the data to be removed by a cron job by a group with only one user and transferred to a quarantine area where outsiders have no access. The 'un-trusted' user (often 'guest' but I've also seen them named 'intruder' or 'hostile') only belongs to a separate group that is otherwise unused. This avoids access through the 'others' permissions (-------rwx) that is granted if you are not the owner or a member of the group.
For the server, this would be fine. Use the O/S you are comfortable with, the one that you can secure. As a combined server and firewall, I'd be a little less enthused, but that's mainly because I don't "know" the firewall capabilities as well as I'd want to. For a firewall alone, I'd usually recommend an O/S designed for this function rather than a general purpose design. I mentioned using Linux on my home firewall, and it's a stripped version using a local compile. I'm using that simply because I have experience with that O/S and feel comfortable with it. I would never consider using an 'out-of-box' 'popular' distribution simply because that 'out-of-box' install has much unneeded stuff/features/etc.
True - this is a function of the server itself. It can (and must) be bolted down to not permit _ANYTHING_ except the allowed service. For a web server, this means for example, not allowing relaying or uploading.
If you must allow uploading by your authenticated users, then any such uploads should be to a special uploads directory where users do NOT have 'read' permissions, and anything put into this directory should be whisked away to a quarantine area for inspection before such material is available to anyone else (and that specifically includes uploaded mail, to avoid becoming a spam source).
Here, I disagree - the server should not be running a client (other than DNS) over the same hose. (This also helps blocking relaying.) If you are not accepting user "files" from the world (files really meaning _anything_ other than usernames and passwords if needed, and the desired URL), then your AV work (if needed) should be performed on a separate internal box where you create the files that may be downloaded from your server. My preference for uploading files to the server is that this be done by a separate interface that will only accept connections from a very restricted number of your systems.