> Ansgar -59cobalt- Wiechers a écrit :
>> On 2007-10-27 Telly Williams wrote:
>>> -A INPUT -s 127.0.0.1 -i lo -j ACCEPT
>>> -A INPUT -s XX.XXX.XXX.XXX -i lo -j ACCEPT
>>
>> No other source address than 127.0.0.1/8 is supposed to appear at the
>> loopback interface.
>
> Wrong. Any local address, including the whole range 127.0.0.0/8 and all
> addresses and aliases configured on local network interfaces may appear
> in traffic involving the loopback interface. Besides, what's the use of
> address-based filtering on the loopback interface ?
Ah, of course you're right. My bad. Make that:
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
[...]
>> Besides, you shouldn't be dropping echo-request and time-exceeded. ICMP
>> is a vital part of IP and required e.g. for troubleshooting connection
>> problems. Rather do something like this:
>>
>> iptables -N icmp_packets
>> # Allow ping, but limit it to 10 requests per second:
>> iptables -A icmp_packets -p icmp --icmp-type echo-request \
>> -m state --state NEW -m limit --limit 10/sec -j ACCEPT
>> # Allow echo replies (pong) for accepted pings:
>> iptables -A icmp_packets -p icmp --icmp-type echo-reply \
>> -m state --state ESTABLISHED -j ACCEPT
>> # Allow troubleshooting messages for all established connections:
>> iptables -A icmp_packets -p icmp --icmp-type destination-unreachable \
>> -m state --state RELATED -j ACCEPT
>> iptables -A icmp_packets -p icmp --icmp-type source-quench \
>> -m state --state RELATED -j ACCEPT
>> iptables -A icmp_packets -p icmp --icmp-type time-exceeded \
>> -m state --state RELATED -j ACCEPT
>> iptables -A icmp_packets -p icmp --icmp-type parameter-problem \
>> -m state --state RELATED -j ACCEPT
>> iptables -A icmp_packets -j DROP
>
> I used to accept source-quench, but not any more after reading that
> some DoS attacks were based on it, and I'm not so sure it's really
> useful.
Quoting from RFC 792:
| A gateway may discard internet datagrams if it does not have the
| buffer space needed to queue the datagrams for output to the next
| network on the route to the destination network. If a gateway
| discards a datagram, it may send a source quench message to the
| internet source host of the datagram. A destination host may also
| send a source quench message if datagrams arrive too fast to be
| processed. The source quench message is a request to the host to cut
| back the rate at which it is sending traffic to the internet
| destination. The gateway may send a source quench message for every
| message that it discards. On receipt of a source quench message, the
| source host should cut back the rate at which it is sending traffic to
| the specified destination until it no longer receives source quench
| messages from the gateway. The source host can then gradually
| increase the rate at which it sends traffic to the destination until
| it again receives source quench messages.
|
| The gateway or host may send the source quench message when it
| approaches its capacity limit rather than waiting until the capacity
| is exceeded. This means that the data datagram which triggered the
| source quench message may be delivered.
Long story short: source-quench messages allow two hosts to negotiate
transmission parameters when for some reason the connection turns out to
be sub-optimal.
I too heard that source-quench may be used in DoS attacks, though I'm
not aware of any, but since the above rules allow this message type only
when it's related to already established connections I believe it should
be okay. Someone correct me if I'm wrong here.
Regards
Ansgar Wiechers
--
"The Mac OS X kernel should never panic because, when it does, it
seriously inconveniences the user."
--http://developer.apple.com/technotes/tn2004/tn2118.html
--
To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
No comments:
Post a Comment