opening up an ipchain

[Pascal Hambourg]

Hello,

Alex Feldman a écrit :
> 
> I know nothing about ipchains.

Fine, here we're talking about iptable, the successor of ipchains. :-)

> *****************************************************************
> 
> iptables --policy INPUT   DROP
> iptables --policy OUTPUT  ACCEPT
> iptables --policy FORWARD DROP
> 
> iptables -t nat --policy POSTROUTING ACCEPT
> iptables -t nat --policy PREROUTING ACCEPT

+ iptables -t nat --policy OUTPUT ACCEPT

> 
> #---------------------------------------------------------------
> # The loopback interface should accept all traffic
> # Necessary for X-Windows and other socket based services
> #---------------------------------------------------------------
> 
> iptables -A INPUT  -i lo -j ACCEPT
> iptables -A OUTPUT -o lo -j ACCEPT
> 
> #---------------------------------------------------------------
> 
> iptables -A INPUT -p tcp -i eth0 --dport 25 --sport 1024:65535 -m state 
> --state NEW -j ACCEPT
> 
> iptables -A INPUT -p udp -i eth0 --sport 53 --dport 1024:65535 -j ACCEPT
> iptables -A INPUT -p tcp -i eth0 --sport 53 --dport 1024:65535 -j ACCEPT

These two rules are possibly harmful : they allow any incoming packet to 
a non privileged local port from any host using source port 53. Better 
deal with DNS replies in the generic rule allowing established/related 
connections.

> iptables -A INPUT -p tcp -i eth0 --dport 80 --sport 1024:65535 -m state 
> --state NEW -j ACCEPT
> 
> #---------------------------------------------------------------
> # Allow previously established connections
> #---------------------------------------------------------------
> iptables -A INPUT -j ACCEPT -m state --state ESTABLISHED,RELATED -i eth0 
> -p tcp

Don't restrict this rule to TCP. It's also needed for other protocols : 
DNS replies using UDP, ICMP ping and traceroute replies, ICMP signalling 
messages...

> *********************************************************************
> 
> Some of this I copied off the web, and I do not understand why I need
> all of it, e.g., all the 1024:65535 port identifiers.

"--sport 1024:65535" means that connections to your services should are 
expected to come from unprivileged source ports, which is usually true. 
However it's not really useful.

> However, I would like to open up the computer further, maybe not all the
> way but for the moment that would be OK, to my own laptop via its mac
> address - I figure that would be pretty safe, but if not, I'd like to
> hear why not.

It is not safe because it is very easy to spoof a MAC address.

>  So I added the line:
> 
> iptables -A INPUT -m mac --mac-source XX:XX:XX:XX:XX:XX -j ACCEPT
> 
> and some variations on it, like with "-p all" in there, at various
> places in the file, but none of them worked (and they all had my real
> mac address in there, I just took it out before I displayed this to the
> world).

Be aware that this will work only when the client and the server are on 
the same network (link layer). MAC addresses don't go through routers.

> Is the problem that I have it in the wrong place in the chain, or
> something else?  I really don't understand the difference between -A and
> -I,

-A = append at the end of the chain
-I = insert at the beginning (or explicit location) of the chain

> especially since the basic file seems to work even though the first
> thing I do is drop all input, and then allow some back later.

No, you don't drop first then allow later, else nothing would work. The 
first three commands (--policy or -P) just set the default policy of the 
chains to DROP. The default policy tells what to do when the packet 
doesn't match any rule with a "terminal" target and reaches the end of 
the chain. So it's rules first then default policy, regardless of the 
location of the --policy commands in the script.