[lug] IP Tables

[Kevin Fenzi]

On Sat, 22 Sep 2007 12:52:35 -0700 (PDT)
horlenkarl at yahoo.com (karl horlen) wrote:

> > DROP will silently drop the packets, making the
> > remote machine think it
> > should just keep retrying. 
> > REJECT will send back a 'NO, go away' so the remote
> > site will see the
> > machine is up, but rejecting it's packets. 
> 
> That this was brought up i feel is a good thing.  From
> what i've read, i was assuming that DROPping might be
> better than REJECTING.  But there's probably a
> philosophical debate about that one.

Sure, depends on what you want to do...

> Since I GLOBALLY am denying a whole lot of stuff
> (everything that doesn't fall into any of the
> relatively small list i've specified), i have to
> choose either DROP OR REJECT.  Can't have both unless
> I start defining a bunch of rules which specify
> specifically for one or the other.

Correct. You can match particular packets and have some drop and some
reject, but you can't do both to the same packet. 

> My thought (and tell me if i was wrong) was that
> DROPping just nipped the whole thing in the bud
> quickly.  No extra queries or processing (performance
> requirements) from my server.  If you're not allowed
> to come here you shouldn't be so i'll drop you, end of
> question.

No. Thats reject. If you drop, the remote side has no idea what
happened, it just didn't get an answer. So, assuming the machine is
down or there is a network problem it keeps trying. 

reject tells it: "sorry, rejected". It could of course keep trying
anyhow, but any well behaved app would stop trying. 

> I also thought that was better from a security
> perspective.  An external request to my server for a
> request it shouldn't handle should probably receive no
> reply.  No reply "hides" the server and might prevent
> further attempts.  A reject actually notifies the
> request that "i'm alive" which gives the requestor
> "hope" to try more ports.  If someone is trying ports
> that i haven't opened then they really don't require
> or deserve a reply.

Correct. reject gives them more information about your machine. That it
exists and is setup to reject those packets. Drop doesn't give them as
much info. If thats important to you, go for dropping. 

> Now I don't know if any of my logic is completely
> correct and it probably is going to fall under the
> category of "it depends" but I like that the thread
> took a turn and it can be explored.  It helps me
> understand this better and create a better firewall.

Yeah, it sure does depend. Lots of ways to do things. ;) 

> One requirement i did leave out was a rule for icmp
> requests.   i've seen it in some examples and left off
> in others in a variety of different flavors.  Is ping
> essential?  This is probably an "it depends".  Unless
> disabling it is going to prevent something it
> shouldn't, i just assume DROP it.  But maybe it should
> be REJECTed instead. Or maybe i should be allowing
> them.

Well, ping is kind of handy to allow for network problem debugging. I
know folks who block it, then confuse themselves because they try later
to use ping as a diagnostic tool. ;) 

Also, some ICMP is needed. If you block all ICMP you are going to
potentially run into problems with some tcp connections that use things
like path mtu discovery and the like (which uses icmp). You can however
just allow those types of ICMP and still reject ping. 

> There is also the possibly that i've failed to account
> for some other port or service that I SHOULD have.  Is
> there another NON-obvious rule that SHOULD PROBABLY be
> in there?

That depends entirely on what services you are offering for the world. 

Also see my blog post about this a while back: 
http://www.tummy.com/journals/entries/kevin_20050314_131358

kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20070922/13702809/attachment.pgp>