[KLUG Members] IPChains problem

[Adam Williams]

>>>I want to stop anything BUT http (80) ssh (22), DNS (53) ftp
>>>(20/21), and ICMP messages (the consequences of blocking those
>>>are fairly clear and nasty) for getting IN or OUT of this box.
>>I agree with using the input chain.  This is the easiest to work
>>with!  
>Like looking for a lost item under a streetlight when it has not been 
>lost there... oh, but it's easier to look there. :)
>The chains exist for a purpose. In the posted rulest, I was simply
>following that purpose. 
>>Just remember that the input can be from the outside or from
>>the inside.  The firewall is the reference point not the interface
>>(well usually). 
>Then what is the intent of the output chain?

If you box 'generates' traffic the output chains is a good safety
mechanism.  But a firewall doesn't "create" traffic, so in the sense of
a pure firewall 'output' plays a small role.

>>>If someone wants to take the time to read the ruleset and 
>>>provide some insight I would be most grateful.
>>>I'll take a look.
>>Post it and lets see
>Posted days ago, in the first message of this thread.

Yep, I found it.

>>Here is an example of a script that I did for ipchains.  It seems to
>>work pretty good.  
>That's fine, Rusty, but unfortunately it is also not really relevent.
>This is a very different problem, and configuration. 
>>A couple of other things.... first I would always block ICMP.  
>Something specifically reccomended AGAINST in all the documentation I've
>read. Also, we don't WANT to "cloak" ourselves in this case. 

One shouldn't block ICMP as a whole,  or you'll miss diagnostic
messages. 

>>Second, I would not open up inbound ftp, only outbound.  
>Not really in the cards, since this is intended to be a public FTP 
>server! :)
>We need to stick to the problem at hand.
>>>There really isn't much reason to much on the OUTPUT chain.  The
>>>input chain is the most effective place to "block" traffic.
>There's EVERY reason to do it there if that's whatt he problem 
>dictates. If it's not, then we'll drop it.
>>I found that the best way to handle it is to deny everything then
>>open what you want.  ....
>That's fine. Consider this ruleset:
>-F input
>-A input DENY
>-A input -s 0/0 -d 0/0 -i lo -j ACCEPT
>-A input -s 0/0 -d 0/0 80 -p tcp -y -j ACCEPT
>-A input -s 0/0 -d 0/0 20 -p tcp -y -j ACCEPT
>-A input -s 0/0 -d 0/0 21 -p tcp -y -j ACCEPT
>-A input -s 0/0 -d 0/0 -p icmp -y -j ACCEPT
>-A input -s thedns 53 -b -j ACCEPT
>-A input -l -j DENY
>Compare it with the opening statement in this message, please. 
>Note:
>1. I didn't see the point in starting every line with "ipchains",
>   I show the rest of each line above.

Right.

>2. "thedns" is the address of our DNS server. I'd have one rule for 
>   each DNS server I am using. 
>   -A input -d 0/0 53 -b -j ACCEPT
>   would be added if we were running a DNS server on the host.

Right.

>This may be a lot closer to what is needed than the original ruleset,
>but if so, some questions remain. I await comment on the above.

Does the above work?  It certainly seems correct.