Re: Default Policy = DROP. Help-me

[This message seems to have been silently discarded, so I try to send it
again]

Hello,

Ansgar -59cobalt- Wiechers a écrit :
> On 2007-10-24 Yuri Rodrigues wrote:
>
>>I usually browse the Internet, get ssh servers for my network and get my
>>ssh server when I am in a remote location. But can not access servers
>>ssh from my server firewall. Somebody help me with that firewall?
[...]
> Ouch. *Never* flush the chains before setting the default policies.
> Also *never* enable IP forwarding before setting the default policies.

I guess you mean "before setting default policies to DROP". Order does
not matter so much when you set them to ACCEPT.

> It's usually safe to set the default policies in the nat and mangle
> tables to ACCEPT (for filtering there's the filter table).

Agreed. There is absolutely no reason to set the policy in nat table to
DROP. Things are less clean about the mangle table, as some people like
to do some early filtering in mangle/PREROUTING.

> [...]
>
>>#### Servidor SSH Intranet ####
>>$iptables -A INPUT -i $intranet -p tcp --dport 22 -j ACCEPT
>>$iptables -A INPUT -i $intranet -p tcp --syn --dport 22 -j ACCEPT
>>$iptables -A INPUT -i $intranet -p tcp --dport 22 -j LOG --log-prefix "SSH INTRA: "
>>$iptables -A OUTPUT -o $intranet -d $rede -p tcp --sport 22 -j ACCEPT

What's the use of the 2nd and 3rd rules ? All TCP traffic to port 22 is
already accepted by the 1st rule.

> echo "0" > /proc/sys/net/ipv4/ip_forward
>
> $iptables -t filter -P INPUT DROP
> $iptables -t filter -P OUTPUT DROP
> $iptables -t filter -P FORWARD DROP
>
> $iptables -t nat -P PREROUTING ACCEPT
> $iptables -t nat -P POSTROUTING ACCEPT
>
> $iptables -t mangle -P PREROUTING ACCEPT
> $iptables -t mangle -P POSTROUTING ACCEPT

What about the other chains in the nat and mangle tables ?

> $iptables -F
> $iptables -t nat -F
> $iptables -t mangle -F
>
> echo "1" > /proc/sys/net/ipv4/ip_forward
>
> $iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
>
> $iptables -A INPUT -i lo -j ACCEPT
>
> # Allow SSH
> $iptables -A FORWARD -p tcp -i $intranet --dport 22 -m state --state NEW -j ACCEPT
> $iptables -A INPUT -p tcp --dport 22 -i $internet -m state --state NEW -j ACCEPT
> $iptables -A INPUT -p tcp --dport 22 -i $intranet -m state --state NEW -j ACCEPT
> $iptables -A OUTPUT -p tcp --dport 22 -o $internet -m state --state NEW -j ACCEPT
>
> # Just enable masquerading, the rest is already handled by the filter table.
> $iptables -t nat -A POSTROUTING -j MASQUERADE

Don't you forget to accept RELATED,ESTABLISHED traffic in OUTPUT and
FORWARD and outgoing traffic on the loopback interface ?

>>#### Bloqueando pacotes fragmentados ####
>>$iptables -A INPUT -f -i $internet -j LOG --log-prefix "Fragmentos: "
>>$iptables -A INPUT -f -i $internet -j DROP
>>echo "Bloquando pacotes fragmentados ..................... [ OK ]"
>
> You know that you're breaking IP here, do you?

Don't worry, packet reassembly occurs before the INPUT chain. So these
rules just do nothing.

>>#### Protecao contra ping flood ####
>>$iptables -A INPUT -p icmp -m limit --limit 1/s -j ACCEPT
>>echo "Protecao contra ping flood ......................... [ Ok ]"
>
> A limit rule does not protect against ping floods. "ping flood" means
> that the attacker is sending so much echo-requrests that they consume
> your entire bandwidth. There's exactly nothing you can do on your
> firewall to protect you from that.

Except when you're on a link with asymmetric up/down bandwith such as
ADSL. If you're on a 128/512 kbit/s link, a 128 kbit/s flood ping is not
enough to fill your dowstream but enough to fill your upstream. By
limiting the incoming echo request (and *not any* ICMP type) rate, you
can limit the outgoing echo reply rate and avoid consume all your
upstream bandwidth.

--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org