Reject | block What's the difference ?
-
Thank you but it will be better if you want to explain that more.
-
With reject, a TCP RST or ICMP port unreachable for UDP is returned to the sender.
With block, the packet is dropped silently.
With reject, a reply is sent back to the sending program/system telling it that the "packet was dropped". That is the "friendly" version, but it means that the sending program/system knows that the packet got through to a firewall and was dropped. So that gives an outside attacker some knowledge that they have reached something. IMHO you don't want to use reject on WAN.
With block, the packet is dropped and nothing is sent back to the sending program/system. So an attacker cannot know if they ever reached their destination or a firewall. It looks to the attacker as if the IP address has nothing there at all.
-
With reject, a TCP RST or ICMP port unreachable for UDP is returned to the sender.
With block, the packet is dropped silently.
With reject, a reply is sent back to the sending program/system telling it that the "packet was dropped". That is the "friendly" version, but it means that the sending program/system knows that the packet got through to a firewall and was dropped. So that gives an outside attacker some knowledge that they have reached something. IMHO you don't want to use reject on WAN.
With block, the packet is dropped and nothing is sent back to the sending program/system. So an attacker cannot know if they ever reached their destination or a firewall. It looks to the attacker as if the IP address has nothing there at all.
Thank you…now it's clear .
-
For local blocking on the LAN is it best to use reject or block?
Since reject sends a rejection message back to the sender, wouldn't that be better?
I'm using the reject/drop to stop chromecasts and Vizio TVs from using the google DNS.
-
In most cases Reject is more used when troubleshooting , to see what really happening , you can use Reject to troubleshoot your rule and to see what is happening and then you can replace it by block to minimize truffic on the Network .
-
For blocking on the LAN I prefer reject, so that local requests don't have to wait for timeouts.
-
Rejecting on the WAN can be used as a reflection attack.
-
Thanks
I'll use block on WAN and reject on LAN.
-
Reject is a lot more user-friendly on "trusted" interfaces.
I am not sold that "stealth" provides any tangible security benefits from the outside either.
My edge responds to pings from any. I don't lose any sleep.
-
I am with Derelict on the whole "stealth" I don't buy it either… If you ping my wan it answers.. But I don't see the point in a reject on wan - no reason to tell the bot looking for ftp or rdp or ssh that hey not open ;) Why would I double the noise by answering it with a sorry not open response?
But on a trusted interface - reject can speed something up vs the client having to wait for timeout and sending retrans on something that is never going to work because its blocked, etc.
