[KLUG Members] IPChains problem

[Rusty Yonkers]

> >>>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.

Are the web, ftp, and dns servers on the firewall computer or behind
it??  Are you also going to support SMTP?  Is the computer also going
to be a workstation for someone?  Are you supporting ssh so that you
can remotely administer the computer?

> >The chains exist for a purpose. In the posted rulest, I was simply
> >following that purpose. 
....
> >Then what is the intent of the output chain?

This is where we need to understand one of the main differences
between ipchains and iptables.  In ipchains the packets flow through
all three of the chains.  They enter the input chain (no matter if
they come from the inside or the outside, or even the firewall
computer itself).  They then go to the forward chain and then out of
the output chain.  There are a few additional stops along the way but
for a simple firewall these are not important.  You can do the work
in any of the chains since the packets flow through all of them.

In iptables the packets go through only one of the three chains.  If
the packet is destined for the firewall itself from the outside then
it goes through the input chain.  If the packet is originating from
the firewall to the outside, then it goes through the output chain. 
If the packet is coming from behind the firewall to the outside then
it goes through the forward chain.  If you are using iptables and the
firewall computer and the web/ftp/dns server are the same then you
would use the input and/or output chains.  if you are using iptables
and the firewall is behind the firewall then you would use the
forward chain.

> >That's fine, Rusty, but unfortunately it is also not really
> relevent.

Sorry ... did not realize that you were doing the serving (see
above).  Script is basically the same but done in reverse though so
it is not a very different problem.  Just the opposite end of things
so to speak.  

> >This is a very different problem, and configuration. 

> >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. 

This is very much something that depends on your paranoid level in
part.  As far as missing messages, for a workstation that is not
important and I would feel that it is much more important to hide the
box.  For a server you would probably want to respond to the messages
since people are going to know it is there anyway.


> >>>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.

See discussion above about ipchains and iptables....

> >>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

The above line will flush the input chain but you may want to do the
same with the output and forward chains too....

> >-A input DENY
This line needs to have a -j for it to be functional...  It will also
effectively stop everything once you put the -j in.  I think what you
are really looking for is the policy statement that will set a
default deny instead of a default accept... that would be 

#set policy to deny
	echo "Starting policy section"
	$chain -P input DENY
	$chain -P output ACCEPT
	$chain -P forward ACCEPT


> >-A input -s 0/0 -d 0/0 -i lo -j ACCEPT

I am not completely sure without a little research or a question to a
better guru but this may open everything up...... since the local
interface is where the server/workstation is at if you are going from
inside the computer to any interface.

> >-A input -s 0/0 -d 0/0 80 -p tcp -y -j ACCEPT
This rule will allow your machine to contact any machine on port 80
from any source port and any machine to connect to your machine on
port 80 from any source port. You want to limit the open ports to
those above 1024 for the initiation of the conversation.  You also
need to create separate rules for incoming and outgoing web traffic
if you are going to use the machine for a workstation as well as a
server.   You are also saying to allow syn packets.  You need to
allow these from the initiating machine but do not need these from
the responding machine.  The default for this switch is to allow the
syn packet so the switch is not needed unless you were going to be
using it to limit the syn packets.  

> >-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

FTP is handled a little differently.  You would have a rule for port
21 on the destination which would be your machine and not all
machines ie

-A input -s 0.0.0.0/0 1024: -d $myip 21 -p tcp -j ACCEPT 

and then another rule that the source is port 20 and the destination
is above 1024 like:

-A input -s $myip 20 -d 0.0.0.0/0 1024: -p tcp -j ACCEPT


> >-A input -s 0/0 -d 0/0 -p icmp -y -j ACCEPT

I think the -y command is invalid for icmp since it is a layer 3
protocol and not connection oriented so it would not have a syn
packet.

> >-A input -s thedns 53 -b -j ACCEPT
Again you want to limit the other machine to ports above 1023 for
initiating this conversation.  I would recommend structuring this
command as 

-A input -b -s 0.0.0.0/0 1024: -d $thedns 53 -p udp -j ACCEPT

Of course you need to set the value of the variable at the beginning
of the script and also put a dollar sign before the variable in the
rule statement.

> >-A input -l -j DENY
> >Compare it with the opening statement in this message, please. 

You would not want to start with the DENY because nothing would get
through then .... it will stop at that chain since everything will
fit that rule.  The chains are read from top to bottom and it will
act on the first rule that it fits.  There are times that you will
get a return but not when you jump to an ACCEPT or DENY....


> >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.
> 

Are all the dns servers behind a firewall or are they all live on the
wire?? this would make a difference on how you structure the
commands....




=====
Truth is truth ... no matter what I think...
-----------------------------------------
Department of Redundancy Department
-----------------------------------------
Devoted RedHat fan...

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com