Stealth Rule with Reject instead of Drop does not make any difference!

[Yasushi Kono]

Hi experts,

I tried to configure the Stealth Rule with Reject in the Action column instead of Drop as described in the courseware.

One question is: What is the intention to use Drop instead of Reject?
The majority of people thinks that Drop is safer than Reject because the Hacker would not get any packets sent back to him. But this is completely wrong. As far as you do not get a packet, you KNOW that there is a Stealth Rule blocking the traffic. If a machine does not exist at all, you will get an information from the destination router (Destination Host unreachable or Destination Port unreachable).

I tested both cases. Check Point does not make great difference between Drop and Reject. It drops the packet even if you configured Reject.

Is someone there who experienced a different behaviour?

Thank you in advance.
Kind regards,
Yasushi

[northlandboy]

I don't follow your thinking at all. If I don't get any reply to a packet, then it is not possible to "KNOW that there is a stealth rule". I can't prove that at all - it's a possibility, but I can't know that for certain. That system might not be up, routing might not be working, various other things could be happening. If I get a Reject, then I do know for certain that there is a device there.

You do configure your routers to not send destination unreachable ICMP packets, right? "no ip unreachables" or something like that on a Cisco router. Standard router configuration for internet visible systems.

I have used reject in the past for some internal-internal traffic, where I wanted to force an ident reject, since it was slowing down SMTP connections. That seemed to work as advertised - a reject was returned, and the packet was dropped.

[dsb.nepo]

I haven't tested this with the Stealth Rule, but my expirence are the following.
I have some rules with REJECT instead of DROP so the application comes quickly back with a 'Unable to connect' instead of 'timout to connect'.

Think about spoofed traffic (udp and MS Message PopUp's that claim to come from a DOD network).
With a reject you can even help others in distributed DOS attacs.

[Yasushi Kono]

Originally Posted by northlandboy

I don't follow your thinking at all. If I don't get any reply to a packet, then it is not possible to "KNOW that there is a stealth rule". I can't prove that at all - it's a possibility, but I can't know that for certain. That system might not be up, routing might not be working, various other things could be happening. If I get a Reject, then I do know for certain that there is a device there.

Hi northlandboy,

ok, my statement was not accurate enough. Let me try to say it more precise: You actually do not know for sure that there is a Stealth Rule if you do not get any response back. At this point you are right. The Stealth Rule could be the reason if you don't get any NACK packets back to you.

But the last of your sentences I quoted is in my humble opinion not correct. If you try to ftp to a server which does not exist anymore, what NACK packet do you get? The router in front of your imaginary server will respond with a "Destination unreachable" packet. So, this ICMP packet is NOT at all a proof of the existence of the server.

Because I am not a Native English speaker, I could have confused your statements. Should this be the case, sorry for that.

Kind regards,
Yasushi

[northlandboy]

But you won't get an ICMP unreachable packet if you have followed best practice with the configuration of your routers. If you're prepared to pay the big dollars for Check Point licensing, then I would expect that you would also take the time to properly configure your network devices.

So then if you try to FTP to a server that does not exist, you will simply be sending SYN packets, and nothing will come back at all. No ICMP errors, no RST packets.

I'm not really sure what the advantage of configuring REJECT instead of DROP would be either. I don't understand how it would help with DDOS attacks either - networks would then be receiving a bunch of RST packets for which they had never sent out a SYN packet.

[Yasushi Kono]

You are absolutely right in telling that REJECT is not best practice. I do not recommend to use REJECT instead of DROP, but I felt that the reason why it is more safe to use DROP was not precise enough: Some guys out there were arguing that TCP/IP is designed to not to send NACK packets if the server they want to access to is not existing. Thus, they concluded that with REJECT they will expose the existence of a host you wanted to hide, which is not true due to RFC792.

One reason not to use REJECT would be that your firewall has to send millions of NACK packets per day which could lead in a considerable decrease of the system performance.

Thanks for your participation on that discussion.
Kind regards,
Yasushi