[KLUG Members] IPChains problem

[members@kalamazoolinux.org]

>> >>>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??  
On it. If they were behind it, I'd write different rules. :)

>Are you also going to support SMTP?
Not right now.

>Is the computer also going to be a workstation for someone?  
No.

>>Are you supporting ssh so that you can remotely administer the computer?
Yes.

>> >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.  
Whatever. It's not relevent in this case.

>...For a server you would probably want to respond to the messages
>since people are going to know it is there anyway.
Exactly. Let's move on.

>>>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....
And since the packets I'm concerned about are coming from the machine
we're talking about, it follows that the output chain is at least a 
legitimate place to place a rule, right?

>> >>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...  
No, probably a mere typo. I meant
-P input DENY
  and let's confine our discussion to the input chain, if that's all
we're going to use, and assume ACCEPT as the policy for forward nad output.

>> >-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.
According to the documentation on IPChains, this simply permits anything on
the loopback 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. 
Seems to be a prerequisite for running a web server.

>> >-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
It would be nice, except we my be using this machine as an ftp client in
addition to using it as a server.

>> >-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.
You're right, my error.

>>>-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
Won't that make it hard to run DNS in and out of this machine?

>> >-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....
Um, I ended with the DENY.

>Are all the dns servers behind a firewall ...
None are.