drop or reject

Dropping throws the packets into the bit bucket and takes no further action. Rejecting will do the same but send an ICMP response back to the originating host. So it is most likely in your best interest to keep on droppin'.

Reply to
dbooss
Loading thread data ...

I've always believed that dropping things was better than rejecting except, possibley where I was testing our network from the outside.

Are there circumstances anyone can think of where reject would be preferable?

TIA

Reply to
Robin Lynn Frank

The thing that no one here has said is that one action will close both the source and destination (by default that is typically reject), unless specified otherwise by the device. Dropping packets doesn't close the connection, rejecting does. On some devices, you can close just the destination and not the source as a means of freeing up sockets but keeping the remote source in the dark about the status of the device. But it's hard to comment on the question going this far into detail without more information. Anyway, word to your mother.

Reply to
Munpe Q

Doesn't much matter since if the port is closed, it's closed. But dropping packets is, in fact, a dead giveaway that the system exists.

Reply to
CyberDroog

Well, it depends what the original sender does. If he runs normal IP he will wait until timeout and the send again until he gives up. If he gets the ICMP response he knows it immediately and won't try again. The ICMP response won't hurt you and the overall traffic should be less than if you drop...

Gerald

Reply to
Gerald Vogt

Agreed. The only benefit I've ever seen is reducing the possibility of operating system fingerprinting - it's hard to identify a system that doesn't respond. But those that assume that dropping packets is effective at hiding a system haven't tried using traceroute (the real version, not the b0rken windoze version, though even that should provide the clue).

Old guy

Reply to
Moe Trin

So you are saying discarding WAN ping on my router is not a good idea?

Reply to
Trinity

I see no option to set it to "not reachable" or whatever so I should just enable "WAN Ping" and let anyone ping me? That isn't what security websites say to do. They say to drop pings. You guys giving good info or not? I hear usnet is full of BS and want to make sure I'm getting good info. No offense intended.

Reply to
Trinity

Well, yes. There is no benefit. A legimite ping for management purposes won't work which may be bad occasionally (ICMP does have a purpose beyond "ping" in IP else it wouldn't be there). It probably retries a couple of times after each timeout. A ping from the bad guy cannot harm you either (the "ping of death" is ancient history...): if you answer he knows you are there, if you don't answer he knows you are there, too. So no benefit here either.

Gerald

Reply to
Gerald Vogt

OK, if it makes no real dif then I'll just leave it set to discard WAN pings.

Reply to
Connected

The primary statement I'm making is that dropping packets doesn't hide your system. I am not making a statement on the religions issue of whether or not you should drop or reject packets. I really don't care what you do, but I want you to understand one fact:

DROPPING PACKETS DOES NOT HIDE YOUR COMPUTER

Ping has been so abused that it has lost much of the usefulness. Many network administrators now drop pings because of that abuse issue. When one of my users complains about not being able to connect somewhere, I have quite enough other tools available to determine roughly where the problem may lie, so I don't count on ping working. Some things are blindingly obvious, some are subtle, but people who don't understand networking or the underlying principles don't think of them. That's fine with me.

For a while, there was a web page on the (US) National Security Agency web site that had the following recommendations:

deny icmp any any echo deny icmp any any redirect deny icmp any any mask-request permit icmp any

That was derived from a page in the Cisco Security Guide. That NSA web page now 404s. The ICMP deny list at our border is in fact more extensive than that (but then, are you aware of how many different types of ICMP messages there are). But those recommendations don't relate to the point I'm trying to make understood. It's really simple.

DROPPING PACKETS DOES NOT HIDE YOUR COMPUTER

Old guy

Reply to
Moe Trin

I basically agree with this - initially we were just blocking pings (not ICMP) from idiots that were slinging endless ping packets at our block. When we got to perhaps a hundred 'deny' rules, we said the hell with it, and now block ICMP type 8 inbound to everyone except the NOC at our upstream.

Agreed

This sounds like a toy firewall on a home grade system. You probably don't need to be offering any services, so disabling pings inbound may be a good idea.

As noted in the response to your post to my article, NSA did recommend that. But what is also recommended is that if you are not offering network services, you should _disable_ them, which blocks inbound packets. Do you really want to share your hard drive or printer with someone on another continent?

----------------------------------------------------- There are three very simple rules about services and open ports:

#1 - if you don't know what it is, disable it, and see if anything breaks.

#2 - if nothing breaks, then you didn't need that.

#3 - if it appears to have 'broken' some function or service, look in the logs, and identify the specific problem.

------------------- For a firewall, there are three very simple rules you should be following when trying to configure them:

#1 - If you don't know what it is, block it, and see if anything breaks.

#2 - If while denying the connection, nothing breaks, then you didn't need that.

#3 - If the firewall appears to have 'broken' some function or service, look in the logs, and identify the specific problem. What specifically is being rejected? Then figure the smallest hole that will fix that problem. This may mean allowing connections to 'this' port, from 'that' IP address. Remember that word - you are opening a _hole_ in your defenses.

A good rule of thumb is that you should disallow everything, rather than just rule 1. It is of little use to have blocked port $FOO, when an entire _army_ of bad stuff is coming in through the other 65,000 ports that you left open to the world. This is especially true for the home user, or the inexperienced. Then you can follow rules 2 and 3 to resolve any problem that may develop. "Block everything by default, and allow needed items" is a lot safer than attempting to block specific items while allowing everything else. What you don't know (or block) _can_ hurt you.

-----------------------------------------------------

Notice the words - 'block' and 'disallow'. I really don't care how you do that. Reject, drop - it doesn't matter to me. Just don't think that by dropping unwanted packets you are going to save your bandwidth, OR magically disappear from the Internet. It doesn't work that way.

Old guy

Reply to
Moe Trin

Certainly not, because you cannot send this. Your router would drop it immediately. The upstream router has to return the "not reachable" if you are not there, because it cannot reach you. If you are connected, the router can reach you and does not return "not reachable". Whether you answer or not does not make any difference in respect of your presence. So if you answer to the ping, the other one knows you are there. If you are not answering he knows it, too. It does not really affect your security...

Gerald

Reply to
Gerald Vogt

It's a D-Link DI-604 Router on a home system.

I'm not on a Network and I don't have file and printer sharing on.

Yea, I do all that already. Thx though.

Reply to
Connected

Take a chill pill Old guy. No need to shout.

Reply to
Connected

#3 is the hardest. There are services on Windows that you cannot stop (like the RPC). Nevertheless those can be bound to specific interfaces only instead of any including the internet connection. This way the service is safe (O.K. not perfectly safe but much safer than before). Other services (microsoft-ds) can to be turned off with a registry hack. But you have to know that one. So neither can be disabled like you described.

For all the other ones that you can turn off in the services panel the most difficult thing is that many are not very well described and that nowadays unfortunately almost every average application seems to install a service or two. The effects of a disabled service are sometimes hard to identify and it can take a couple of days or so until you notice it (if you remember at that time that it could be related to a service...)

And: if you are not on the microsoft security bulletin mailing list, better leave the automatic update services running...

Gerald

Reply to
Gerald Vogt

That's an old (generic) Unix mantra, and I suppose I can re-write that to indicate binding to the loopback is an acceptable alternative.

Actually, it is a good solution. One of the Linux distributions (RH7.1 back in early 2001) used that to allow 'sendmail' to run locally, and avoid being used as a spam relay. For the system to receive mail directly over the net, you actually have to _read_ the RELEASE-NOTES file, or read the Sendmail FAQ. and then type four documented commands. Such a terrible burden! Few home users need this function (you normally receive mail from your ISP's POP server with a different application), so this was a good tradeoff.

That's why the firewall is also needed.

I do blame software companies for this. Making it easy to use should not be accomplished by ignoring petty details, like what is required to be open (and exactly why) and what might be nice to be open (and why this is needed and why it may not be a good idea). Instead, the user has to obtain an extra product - a decent firewall, because the application (or operating system) can't provide the 'easy to use' and 'easy to understand' controls. It's interesting that the after market firewall companies have no difficulty providing such a product, yet the operating systems company can't (or won't).

Actually, we're more interested in Bugtraq, because the problems get identified a lot earlier.

Old guy

Reply to
Moe Trin

Unfortunetly, a lot of people seem to believe that by sticking their head in the sand, no one can see them. It's rather a pity, because they can demonstrate to themselves that it doesn't work.

Old guy

Reply to
Moe Trin

OK, point was taken way back. The gist of what I'm getting from you is that it doesn't matter what you do, you can be seen. Is that your message?

Reply to
Connected

Yes, though it is certainly a difference security-wise if something is running only on loopback or not at all. A security vulnerability in a loopback bound service can still be exploited locally, e.g. if the user runs some malware that uses that vulnerablity for privilege elevation.

Well, they just focus on the "easy to use" meaning "turn everything on by default". That way the user does not have to know how to turn things on (I think that many users just go for the list of features in their decisions which product to use so it is important for the vendor to have everything ready...) The real problem is how to make things secure and at the same time have a usuable (easy-to-use) product. That is something that is hard to achieve and probably in an environment where visible features and time-to-market is most important not really the nut you want to crack first. Right now, most of the time adding security means adding complexity and burden for the user making things harder to use...

That's certainly better, but for the average Joe it seems to me as if getting the most current security updates is the best he can do and the ms list does post sometimes a little before the update is actually available on windows update...

Gerald

Reply to
Gerald Vogt

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.