Ipchains Woes

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Craig White
Date:  
Subject: Ipchains Woes
On Wed, 2002-02-27 at 22:03, Steve Holmes wrote:
> More developments. I took the same script I put in a previous message and
> added the line:
> ipchains -A input -p udp --dport 1024:65535 -j ACCEPT
> Now everything seem to work from the inside point of view.
>
> One question now, that sounds awfully wide open to me. I'm not familiar
> enough with a complete map of tcp and udp ports to know what is safe to
> have open and which should be closed. The obvious ones, I don't allow in
> unless I specifically want them like ftp, telnet, ssh, mail(25), pop3,
> imap, etc. I understand them well but these upper ports are more unknown
> to me. I open them up and I get responses from DNS lookups and the other
> stuff works.
>
> Does this all make sense? Should I pare down the upper ports?
>
> In summary, the scripts that open things up is as follows:
> ipchains -A input -p tcp ! -y --dport 1024:65535 -j ACCEPT
> ipchains -A input -p udp --dport 1024:65535 -j ACCEPT
> (Assuming no typos here).
>
> Appreciate the help thus far; we're getting there. Once I get this
> finally worked out, I'm gonna stick this into the endoshield script which
> has a lot of neet options and that script will work with ipchains and
> iptables when I go to iptables later on.
>

----
You definitely want to block 6000:6010 - the xfs server on the external
interface -

ports ftp, telnet, ssh, mail, pop3, imap are allow privileged ports
(under 1024) - so you only need to expose those that need to be accessed
from the internet.

Example, you are using this box to receive email for your domain...

/sbin/ipchains -A input -j ACCEPT -p tcp -s $UNIVERSE -d $UNIVERSE smtp

(of course, your smtp server must be configured to accept mail for your
domain but this is a ruleset for ipchains to allow it).

Personally, I see no reason to allow the udp traffic into the external
interface at all on those ports (as your last rule set would do).

Don't forget that it pays to be granular - you are more likely to trust
the internal lan than the public interface...so you can have 2 different
rule sets - 1 that accepts basically anything on the internal lan
adaptor and that which is permitted on the external lan interface. I
can't tell you how invaluable that the rulesets that David Ranch
publishes helped me - I only need to comment out or uncomment the
specific rulesets and I don't have to think about things such as the
order of things. You really should take a look at that and forget the
endoshield.

Craig