[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: eth1 - iptables do not work

On 2008-10-09 Tamas Hegedus wrote:
> echo "1" > /proc/sys/net/ipv4/ip_forward

You shouldn't enable IP forwarding before the policies for your chains
have been set. Better do something like this:

echo "0" > /proc/sys/net/ipv4/ip_forward

iptables -P INPUT DROP

echo "1" > /proc/sys/net/ipv4/ip_forward

> iptables -P INPUT ACCEPT
> iptables -F INPUT
> iptables -P OUTPUT ACCEPT
> iptables -F OUTPUT
> iptables -P FORWARD DROP
> iptables -F FORWARD

"iptables -P INPUT ACCEPT" is a bad choice for a firewall. Don't do that
in a productive environment. Use "iptables -P INPUT DROP" instead and
whitelist what you want to accept. And you can use "iptables -F" to
flush all default chains in the filter table in one go.

iptables -P INPUT DROP
iptables -P FORWARD DROP

iptables -F

> iptables -F -t nat

You should also set the policies for the nat table:

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT

> iptables -F -t mangle

Same goes for the mangle table, unless you don't have it in your kernel
(which is advisable if you don't want to use it in the first place).

> # Flush the user chain.. if it exists
> if [ "`iptables -L | grep drop-and-log-it`" ]; then
>    iptables -F drop-and-log-it
> fi
> # Delete all User-specified chains
> iptables -X

Flushing user-defined chains is pointless if you're deleting them

> iptables -A drop-and-log-it -j REJECT

As a suggestion, it's better to reject like this, IMHO:

iptables -A drop-and-log-it -p tcp -j REJECT --reject-with tcp-reset
iptables -A drop-and-log-it -p udp -j REJECT --reject-with icmp-port-unreachable
iptables -A drop-and-log-it -j DROP

> iptables -A OUTPUT -o lo -j ACCEPT
> iptables -A OUTPUT -o $EXTIF -s $EXTIP -j ACCEPT
> iptables -A OUTPUT -o $EXTIF -s $INTNET -j ACCEPT
> iptables -A OUTPUT -j drop-and-log-it

This is the source of your problem, AFAICS. You allow outgoing packets
only on external and loopback interfaces, and reject everything else
with your drop-and-log-it rule. That means: packets coming in on port
22/tcp reach the SSH daemon, but the response packets are dropped by
your firewall. Therefore your internal client is unable to establish a

Personally, unless you have rather high security requirements, I'd
suggest to just accept everything in the OUTPUT chain. The packets
handled by this chain originated from the host anyway, and only the
firewall admins should have accounts on that box. Keep things simple.
However, if you want to restrict outgoing traffic from the firewall host
itself, I'd suggest to use something like this instead:

iptables -P OUTPUT DROP

iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# allow particular outbound connections, e.g. DNS
iptables -A OUTPUT -p udp --dport 53 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 -m state --state NEW -j ACCEPT
# reject everything else
iptables -A OUTPUT -p tcp -j REJECT --reject-with tcp-reset
iptables -A OUTPUT -p udp -j REJECT --reject-with icmp-port-unreachable

Ansgar Wiechers
"The Mac OS X kernel should never panic because, when it does, it
seriously inconveniences the user."

Reply to: