RE: 'Generic' Firewall Rulesets?
> Moreover, I have no idea what a 'good' ruleset to simply allow FTP
> requests from my machine (such as those made by an FTP client on my
> machine, apt-get, etc.) are reasonably secure. And, in my case, I have
> incoming FTP disabled, but is there a way to block packets at the
> firewall (from people requesting FTP services on my computer), while
> allowing my FTP requests to go unhindered?
This is really rather simple. you just stop packets that have your IP and
port 20:21, while you allow packets with your IP (and a random port), and a
random other IP with the ports 20:21.
> In fact, I couldn't really find any good information on general firewall
> construction. I could find information on how to set a rule for the
> firewall; but now I need to find information on *what* kind of rules are
> good, and why (and what is bad, and why).
generally speaking (well, in my opinion, anyway), doing an nmap on yourself,
then closing off any ports you don't like (or, heck, removing the service in
its entirety), and leaving everything else alone would be sufficient for a
home-user. a good firewall is one that improves your security, but doesn't
get in your way. a firewall that denies anything except a few services is
secure in and of itself, but it requires a lot of maintenance.
Actually, one thing that SHOULD be default deny on all firewall rulesets,
are local IP ranges coming in from the internet. Example:
eth0 = adsl
eth1 = local net
allow everything on eth1 (my computers, no need to not trust them)
deny all local IP ranges on eth0 (local IPs coming from the internet? eep!)
> Another Example: From what I understand, all TCP/UDP ports above 1024
> are 'user' ports, and have no services attatched to them. What kind of
> possible security problems/other risks are involved by having these
> ports essentially 'open' to the world? What is the tradeoff with
> closing them off?
since there usually isn't any services ON those ports, leaving them open
won't do anything to your security (well, usually... you *can* get a trojan
or something onto your box, but in that case you've got other serious
issues, too). The tradeoff with closing them off is best described with an
example. Say you're on irc, and you want to DCC Send something to someone.
unless you specify HIS ip as open as you send it, it'll probably be stopped
dead in its tracks. this creates a lot of hassle for you, not to mention
frustration (wtf doesn't <insert action> work? *checks firewall logs* oh
> For my particular situation, the computer is connected directly to the
> internet on a campus network. I want to be able to have a good 'basic'
> firewall ruleset that will allow me to do my normal tasks as though
> there were no firewall active, yet filter out all incoming connection
> requests (such as telnet, ftp, etc.). I'm running kernel 2.4.0-test9; I
> have iptables figured out and can apply rulesets just fine. It's
> knowing what rules make sense and what ones don't that I need help on.
if you want to disallow telnet, ftp etc, take a shot at removing those
services first. Basic rule of security is: if you don't need it, don't run
> I'm more interested in learning how to create a good firewall than
> simply having one. (So I can make one from scratch should I ever have a
> specific need).
as i mentioned earlier, having a firewall creates a false sense of security.
a firewall doesn't stop everything imaginable, altho it does stop a lot of
it. it'll probably stop you too a few times :) what's more important is
teaching yourself some basic rules of security (what services to run, what
packages are known for exploits (sendmail...) and avoid those), and just
abide by that. a firewall is just a means to an end, not the end of all
> Thanks for any help offered. I hope I didn't run in too many circles!
When you are having a bad day, and it seems like everybody is trying to piss
you off, remember that it takes 42 muscles to produce a frown, but only 4
muscles to work the trigger of a good sniper rifle.