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.
