iptables command ignored?

Hi,

I appear to have a bit of a problem with iptables on debian 4.0. I'm
trying to open and close some ports but the commands I entered appear to
be ignored so I have made a little test.

I entered the following in a terminal window:

iptables -A INPUT -s 127.0.0.1 -p icmp -j DROP

That should, I hope, drop all packets on lo but when I ping lo I get:

ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.223 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.183 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.180 ms

--- 127.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.180/0.195/0.223/0.022 ms

I have four NICs on my machine. So, just in case ping works because of
the other NICs I did this:

iptables -A INPUT -s 127.0.0.1 -p icmp -j DROP
iptables -A INPUT -s 192.168.0.1 -p icmp -j DROP
iptables -A INPUT -s 192.168.1.101 -p icmp -j DROP
iptables -A INPUT -s 192.168.2.102 -p icmp -j DROP
iptables -A INPUT -s 192.168.3.103 -p icmp -j DROP

That should drop all packets from any NIC on my machine if I understand
things correctly. However, when I ping I get this:

ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.176 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.168 ms

--- 127.0.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms

Its like the computer has ignored the "iptables" command. However, when
I delete those rules iptables does not complain.

So, what's going on? Why can't I drop packets?

Thanks.

On 09/27/2007 12:41 AM, AAW wrote:
> Hi,
>
> I appear to have a bit of a problem with iptables on debian 4.0. I'm
> trying to open and close some ports but the commands I entered appear to
> be ignored so I have made a little test.
>
> I entered the following in a terminal window:
>
> iptables -A INPUT -s 127.0.0.1 -p icmp -j DROP
>
> That should, I hope, drop all packets on lo but when I ping lo I get:
>
> ping 127.0.0.1
> PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
> 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.223 ms
> 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.183 ms
> 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.180 ms
>
> --- 127.0.0.1 ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 2000ms
> rtt min/avg/max/mdev = 0.180/0.195/0.223/0.022 ms
>
> I have four NICs on my machine. So, just in case ping works because of
> the other NICs I did this:
>
> iptables -A INPUT -s 127.0.0.1 -p icmp -j DROP
> iptables -A INPUT -s 192.168.0.1 -p icmp -j DROP
> iptables -A INPUT -s 192.168.1.101 -p icmp -j DROP
> iptables -A INPUT -s 192.168.2.102 -p icmp -j DROP
> iptables -A INPUT -s 192.168.3.103 -p icmp -j DROP
>
> That should drop all packets from any NIC on my machine if I understand
> things correctly. However, when I ping I get this:
>
> ping 127.0.0.1
> PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
> 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.176 ms
> 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.168 ms
>
> --- 127.0.0.1 ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 999ms
>
> Its like the computer has ignored the "iptables" command. However, when
> I delete those rules iptables does not complain.
>
> So, what's going on? Why can't I drop packets?
>
> Thanks.

Do a Yahoo search for iptables or netfilter tutorials.

Most probably you have another rule on the INPUT chain that accepts the
ICMP packets before your rule to block them is reached. Consider this
for example:

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -s 127.0.0.1 -p icmp -j DROP

Any ICMP packets sent through the loopback device get accepted before
processing gets to rule 2--the rule that would drop them.

If you're unsure of what is in your INPUT chain, look at it:

iptables -L INPUT

In fact, this is very useful when building a firewall script:

iptables -L

Several programs are available to make firewall management easier:
firestarter, shorewall, gnome-lokkit, kmyfirewall, ferm, fiaif,
filtergen and more.

AAW <(E-Mail Removed)_remove> writes:
(snip)
> iptables -A INPUT -s 127.0.0.1 -p icmp -j DROP
(snip)
> Its like the computer has ignored the "iptables" command. However, when
> I delete those rules iptables does not complain.
>
> So, what's going on? Why can't I drop packets?

What happens with,

iptables -I INPUT -s 127.0.0.1 -p icmp -j DROP

... ? Maybe there were other rules that acted before yours. Rules are
ordered. To see what rules are acting, look at:

iptables -L INPUT

Mark

On 2007-09-27 07:41, AAW wrote:
> Hi,
>
> I appear to have a bit of a problem with iptables on debian 4.0. I'm
> trying to open and close some ports but the commands I entered appear to
> be ignored so I have made a little test.
>
> I entered the following in a terminal window:
>
> iptables -A INPUT -s 127.0.0.1 -p icmp -j DROP
>
> That should, I hope, drop all packets on lo but when I ping lo I get:

> So, what's going on? Why can't I drop packets?
>
> Thanks.

You are putting it last in the chain, try -I to "insert" drop
before anything else accept it.

I know near nothing about this, so don't take it as fact, but I have found
the same problems when adding block rules, they just don't bite unless I
insert them, or put them in the script that build the firewall at startup.

/bb

AAW <(E-Mail Removed)_remove> wrote:
> Hi,

> I appear to have a bit of a problem with iptables on debian 4.0. I'm
> trying to open and close some ports but the commands I entered appear to
> be ignored so I have made a little test.

> I entered the following in a terminal window:

> iptables -A INPUT -s 127.0.0.1 -p icmp -j DROP

Wrong table. Try

iptables -I OUTPUT -p icmp -s 127.0.0.1 -j DROP

> That should, I hope, drop all packets on lo but when I ping lo I get:

> ping 127.0.0.1
> PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
> 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.223 ms

Regards-
--
Clifford Kite

Mumia W. wrote:
>
> Do a Yahoo search for iptables or netfilter tutorials.

I’m working my way throught he HOW TO to try and learn iptalbes (that’s
where the “iptables -A INPUT -s 127.0.0.1 -p icmp -j DROP� came from).

>
> Most probably you have another rule on the INPUT chain that accepts

Yeap, I should use –I not –A and then it works. So, thanks for your
reply and to the other who replied. Most appricated.


..ui

Hello,

Clifford Kite a écrit :
>
>>iptables -A INPUT -s 127.0.0.1 -p icmp -j DROP
>
> Wrong table.

I guess you mean "wrong chain".

> Try
>
> iptables -I OUTPUT -p icmp -s 127.0.0.1 -j DROP

Why ? Packets sent through the loopback interface have to traverse both
OUTPUT and INPUT chains, and therefore may be dropped in either chain.

To the OP : the proper way to match packets on the loopback interface is
to use -i|-o lo, not -s|-d. As you understood, traffic on this interface
may use any local address as source and destination (don't forget the
whole 127.0.0.0/8 block).

Pascal Hambourg <boite-a-(E-Mail Removed)> wrote:
> Hello,

> Clifford Kite a écrit :
>>
>>>iptables -A INPUT -s 127.0.0.1 -p icmp -j DROP
>>
>> Wrong table.

> I guess you mean "wrong chain".

Right, I failed to "Count two, think blue."

>> Try
>>
>> iptables -I OUTPUT -p icmp -s 127.0.0.1 -j DROP

> Why ? Packets sent through the loopback interface have to traverse both
> OUTPUT and INPUT chains, and therefore may be dropped in either chain.

My reason is found in man iptables, search for locally. Backed up by
a test which showed this rule worked in that it prevented a ping from
being sent.

Also this appears to me as not a case of "through" the loopback interface,
the packets were _originated_ by the host (locally). That doesn't seem
to mean they must be considered input or output except by designation.
The man pages said output and output appeared to work while input didn't.

> To the OP : the proper way to match packets on the loopback interface is
> to use -i|-o lo, not -s|-d. As you understood, traffic on this interface
> may use any local address as source and destination (don't forget the
> whole 127.0.0.0/8 block).

You're right that using -i lo works, and silently, i.e., without the
"ping: sendmsg: Operation not permitted" message produced by my
suggestion. Since that qualifies as drop, I concede - again.

Regards-
--
Clifford Kite
/* The wealth of a nation is created by the productive labor of its
* citizens. */

Clifford Kite a écrit :
>>
>>>>iptables -A INPUT -s 127.0.0.1 -p icmp -j DROP
>>>
>>>Wrong chain [corrected]. Try
>>>
>>> iptables -I OUTPUT -p icmp -s 127.0.0.1 -j DROP
>
>>Why ? Packets sent through the loopback interface have to traverse both
>>OUTPUT and INPUT chains, and therefore may be dropped in either chain.
>
> My reason is found in man iptables, search for locally. Backed up by
> a test which showed this rule worked in that it prevented a ping from
> being sent.

Sure it works in OUTPUT. But it works in the INPUT chain too, as a
packet traverses both chains when it loops back.

> Also this appears to me as not a case of "through" the loopback interface,
> the packets were _originated_ by the host (locally).

Originated by and _destined to_ the host. Hence the INPUT chain. The
packet is sent through the loopback interface and received through the
same interface.

> That doesn't seem
> to mean they must be considered input or output except by designation.
> The man pages said output and output appeared to work while input didn't.

It works in both chains.

>>To the OP : the proper way to match packets on the loopback interface is
>>to use -i|-o lo, not -s|-d. As you understood, traffic on this interface
>>may use any local address as source and destination (don't forget the
>>whole 127.0.0.0/8 block).
>
> You're right that using -i lo works, and silently, i.e., without the
> "ping: sendmsg: Operation not permitted" message produced by my
> suggestion.

You get the error message because you drop in the OUTPUT chain. If you
use -o lo in OUTPUT you'll get the message too. Whether the rule matches
the interface or the address has no effect on the way the DROP target works.