On Thu, Sep 02, 1999 at 10:53:49AM -0700, Patrick Olson wrote:
> > Make sure you're allowing ident connections. Even if you don't answer
> > them, you want to refuse connections rather than dropping the packets.
> > Some systems will timeout the connection attempt.
> I'm a little confused here, what is an ident connection? After looking
> through /etc/services and /etc/protocols, my best guess was you meant the
> auth port, 113. Is this what you meant?
Yes. It's a protocol which allows a system to ask a system with which
it has a TCP connection to give it some information about who's on the
other end of that connection. This is useful for auditing purposes,
although you can only trust the information as much as you can trust the
remote site (and some sites refuse to give out any useful information).
> > You may also want to reject packets from IP addresses you own and from
> > the private IP addresses that aren't arriving on appropriate interfaces,
> > and anything going out of your network that doesn't have the IP address
> > of the masquerading host. The -i option is useful for this.
> I don't actually own any IP addresses, as far as I know. You're right
> about things arriving on the wrong interface, I'll have to take care of
> that. I think it's going to significantly increase the number of rules,
> so I'll wait until I have these right before adding more.
If you accept correct local packets first and then ban anything else
it's fairly simple, although my firewall trusts local machines entirely
so I may be missing something.
> How would I prevent things going out that don't have the IP address of the
> masquerading host since it gets a different IP address on ppp0 every time
> it connects? Can I get away with using "localhost"? I'm sure I don't
> want outgoing packets to have the IP address of eth0!
What I do is to deny any packets with addresses in my private network.
A more paranoid thing would be to use the ip-up and ip-down scripts to
add and remove the appropriate rules each time. It's not that much of a
problem because the remote end of the link will probably do a fair bit
of the work for you.
> Would something like this work?
> # allow me to use fetchmail
> ipchains -A input -d localhost 110 -s pop3.isp.com 110 ! -y -j ACCEPT
> ipchains -A output -s localhost 110 -d pop3.isp.com 110 -j ACCEPT
You can't use localhost like that. Any packets going out over PPP are
not going to have a source address of localhost (think about where
answers are going to get sent to).
Also note that ! is a shell metacharacter, so you need to say '!' rather
than !.
> I'm especially sensitive about e-mail, as I am the only one here who has
> an e-mail address. I can't block all SMTP, or I wouldn't be able to send.
> I am trying to avoid letting any of the other computers on the LAN send
> mail at all, because it would probably look like it was coming from me
> since they don't have any e-mail addresses.
Assuming they can't log into your machine, you could reject all SMTP and
POP traffic not on loopback or PPP and control the remote address (but
not local) for traffic going over PPP.
> > Similarly, you could control who gets to connect which way.
> How's this?
> ipchains -A input -s proxy.isp.com 3128 ! -y -j ACCEPT
> ipchains -A output -d proxy.isp.com 3128 -j ACCEPT
Seems reasonable.
A useful trick when building firewalls is to use tcpdump to see what's
flowing over the interface and compare that to your expectations.
--
Mark Brown mailto:broonie@tardis.ed.ac.uk (Trying to avoid grumpiness)
http://www.tardis.ed.ac.uk/~broonie/
EUFS http://www.eusa.ed.ac.uk/societies/filmsoc/
Attachment:
pgpZgqf_qQa2n.pgp
Description: PGP signature