Unable to block ICMP

Check this thread (posted by me):

http://forums.fedoraforum.org/forum/showthread.php?t=152539

Could anyone help me here with the problem please ?

Ronald

Ronald,

use "iptables -A INPUT -p icmp -j DROP" instead of "iptables -A OUTPUT -p icmp -j DROP"

Best regards,

Thomas

2007/4/15, Ronald <[email protected]>:

Ronald,

the subject of your mail is "Unable to block ICMP", so I just told you how to block the ICMP (by looking at the rules you posted on the link you gave).

Best regards,

Thomas

PS: Please use "answer to All", so that everybody get the answer and can follow this thread

2007/4/15, Ronald <[email protected]>:

Thomas d'Otreppe schreef:

Well, what I actually wanted (which I probably explained wrong) is that my ports that are not in use (closed) are being invisible (no ICMP echo). That better?

On the forum you are using this ruleset:

iptables -P INPUT ACCEPT
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -p tcp --dport 631 -j DROP
iptables -A INPUT -p tcp --dport 445 -j DROP
iptables -A INPUT -p tcp --dport 139 -j DROP
iptables -A INPUT -p tcp --dport 6000 -j DROP
iptables -A INPUT -p icmp -j DROP
iptables -A OUTPUT -p icmp -j DROP

Personally, I wouldn't want to do this. Why don't you DROP everything by default and open up what you need, instead of ACCEPTing everything but trying to DROP some ports/icmp?

Such ruleset would look like this:

$ipt -P INPUT DROP
[..ACCEPT rules here..]

Or like this:

[$ipt -P INPUT ACCEPT]
[..ACCEPT rules here..]
$ipt -A INPUT -j <DROP|REJECT [reject-with ...]>

IMHO that would be easier: for my IP, the website you mentioned shows "steathed" (except for ports that I know are open) for the ports that were scanned.

Grts,
Rob

ICMP echo is not a per-port operation. I don't know what the site you quote means by 'closed'. Also, blocking all ICMP is never a really good
idea: (recently updated)

http://www.av8.net/ICMPTypes.txt

I agree with the other posters': that you should block TCP and UDP connections to all ports by default, and open only those that you trust are exposable to the world, or better, just to whomever you have to expose them to.

I suggest searching for instructions on how to do linux firewalls, and following them, rather than trying to roll your own rules by trial and error.

		--Dean

Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   

Dean Anderson schreef:

That is correctly my setup now, but some applications like skype require to have everything opened above 1024. Furthermore, this setup would be really easy. I only block what I don't want and allow everything else, closed ports are being shown as stealth. Once an application is started it will open a port and I don't have to reconfigure my firewall. I have this in Windows, like this (with Comodo):

- Block incoming traffic, with destination port 135,445,etc etc
- Block outgoing icmp traffic
- Allow all (the rest)

This is the most easy way, all applications just work without reconfiguring the firewall. And closed ports are stealth. But since you guys say so, I'll keep it this way (Drop all accept some)

Thanks

Bad idea. All you're going to achive is that everybody knows "there is something that is frantically trying to be invisible", which is kind of a beacon instead of "blending into the crowd".

If you want to be invisible, pull your network cable. As soon as you talk to the outside, you're going to be visible.

Greetings
Marc

-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190

I agree. Moreover, a non-existent host is signaled by ICMP errors in normal operation.

Say your packet reaches the router attached to network containing target IP address and there's no host on that very IP address. Then router will issue an ARP request and won't get any answer. In this case, it should send back a Host Unreachable ICMP message.

It's a very common mistake around to think that probing non existing hosts don't generate any answer...

http://sid.rstack.org/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE

Hi Ronald,

I don't know why your ports are 'closed' instead of 'stealthed', but it has nothing to do with ICMP. ICMP doesn't use ports, so it's impossible to send a ping to a port, especially a TCP or UDP port as those are completly different protocols.

Are you using the 'Stealth Test'? This test sends TCP and UDP packets to your IP, but no ICMP packets. There's a test called 'TCP ping packet', but this has nothing to do with ICMP echo request, so dropping ICMP will not solve your problem.

BTW: Dropping *all* incoming ICMP packets is a bad idea. You should ACCEPT ICMP type 3 (destination unreachable), type 11 (time exceeded) and perhaps type 12 (parameter problem), as those ICMP packets indicate transmission errors you (your applications) probably want to know about.

I just tried the 'Stealth Test' on pcflank.com and the result is 'stealthed' for all tests, but the following could be the interesting part:

"We have sent following packets to TCP:1 port of your machine:"

If my interpretation is correct, it means that the packets are sent to port 1/tcp (and the UDP packet to port 1/udp).

Add the following line to your rules:

iptables -A INPUT -p tcp --dport 1 -j DROP

Then, the test should result in 'stealthed' for all TCP tests, but 'closed' for the UDP test.

michael

Michael Hissler schreef:

That is weird, if you block ICMP outgoing in comodo, all the closed ports are shown as stealthed. This is really confusing ...

Ronald wrote:

[...]

What is comodo?

Which scan test are you using? If it's a UDP scan this is not weird. If a closed port (i.e. a port no service is listening on) is contacted, an ICMP port unreachable message is sent back. By blocking this ICMP message (or blocking all outgoing ICMP traffic), you get the same result as if you blocked the incoming packet: the sender doesn't get a response and so the port is 'stealthed'.
If it's a TCP scan, the kernel sends back a TCP Reset. In this case blocking ICMP should have no effect (in this case: yes, it's weird).

BTW: If you block traffic to ports services are listening on, but accept traffic to closed ports, someone who scans your IP knows:

1. You are there. He gets ICMP port unreachable messages or TCP Reset for the closed but unblocked (not 'stealthed') ports.
2. He knows which ports you are running services on (-> the ports he doesn't get the ICMP messages or TCP Reset).

This may not be what you want.

You wrote that skype requires to have everything open above port 1024. This can't be true!
Skype works perfectly if you accept all outgoing traffic and

a) configure skype to use a certain port and accept incoming traffic to this port,

or (better)

b) drop *all* incoming traffic and use connection tracking. This lets pass all incoming packets belonging to a connection initialized by your computer:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT (you can leave out the ',RELATED' but then you'll run into trouble with e.g. FTP and ICMP error messages)

michael

Michael Hissler schreef:

THANKS! That:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Was just what I was looking for :D . I recompiled my kernel with support for it and it works amazing :D . Way to go :)

Ronald