On 2007-10-29 Pascal Hambourg wrote: > 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
