|
Yep, something else I have seen in smarter networking
environments is a honeypot system where you trap all ICMP traffic bound for
non-routable internal networks and then a script that shuts the ports
down on the switches of the machines sending that traffic. Someone with an
infected machine who all of a sudden can't get network connectivity is bound to
yell for help at which point the boys with the stuffed pillow cases show up....
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Desmond Sent: Sunday, January 01, 2006 5:11 PM To: [email protected] Subject: RE: [ActiveDir] icmp's The whole block ICMP
thing is I think in many ways dating to the blaster and nachi outbreaks when
routers were getting driven to 100% CPU as hundreds of machines were slamming
ICMP and RPC traffic across them. Newer gear has the ability to rate limit ICMP
traffic. All your admins need to do is rate limit ICMP to something like
512kb/sec and drop on exceed. Problem solved. In the event yuou have an outbreak
because you don't do patch management, go in the router and set the drop limit
to something like 64kb/sec or worst case put the ACL to shutdown ICMP all
together. Either way your better off than no ICMP 24/7....
From: [EMAIL PROTECTED] on behalf of joe Sent: Sun 1/1/2006 3:17 PM To: [email protected] Subject: RE: [ActiveDir] icmp's I don't often find myself in the position of defending the
Exchange folks but this isn't just an Exchange thing, the ICMP echo has been a
"are you alive" test for a very long time. I understand why they do it, I have
written several scripts and tools that do something similar. It can be
considerably faster. When you are testing suitability or capability of a
bunch of systems, sending an ICMP ping to see if the machine is live
is considerably faster in many circumstances than sending higher level
calls, both for machines that are live or dead. This is especially true if using
netbios calls, in that case querying can cause a system to hang where a
simple ICMP ping tells you right away if you should even bother.
Blocking all ICMP in an internal network is generally silly
in my opinion unless something is abusing it at the time. It is often a
thoughtless reactive, "well we will certainly stop those viruses" knee jerk. Its
like stripping all zip files in an email system because a virus is operating
through zips. We don't a better way and we don't have the ability and/or time to
think up a better way so lets get out the sledgehammer...
Once you use ICMP you can go on to use higher level forms
of testing. It is also a great way for diagnostician's to try and work out
network issues... is ICMP ECHO getting through? No, well then we don't have to
look at complicated upper level issues, we can focus on core basic network
connectivity.
One thing the Exchange folks did that I am not in agreement
with is if a DC is a config DC and is operating poorly Exchange will really
avoid switching for config functionality if the ping is still there. That isn't
a stateless connection so I can understand the reluctance but it can be a
serious pain at times.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Sunday, January 01, 2006 1:18 PM To: [email protected] Subject: RE: [ActiveDir] icmp's “Note Exchange doesn't take kindly to ICMP echo being disabled either. If Excha us nge can't ping a DC, DSACCESS does not see that DC unless you have specially configured it.”
Which, I always thought was a pretty funny way of doing things anyway. As you are well aware, Ping doesn’t mean alive and healthy. I know of many people who have spent hours to days troubleshooting a problem just to find that the machine that they first suspected as being the problem pinged just fine. Sadly, it was dead from the neck up and port 389 and 3268 were non-responsive (along with all of the other really important stuff).
Rick From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of joe
I would agree, the old style logon scripts should be fine, UNLESS you have implemented your own speed sensing based on icmp in the logon script (many of us did that long before MS did it for those who didn't figure it out).
Note Exchange doesn't take kindly to ICMP echo being disabled either. If Exchange can't ping a DC, DSACCESS does not see that DC unless you have specially configured it. If you never want to fail outside of a segment then that is the way to do it, but most people would rather fail over to any DC versus say, nah, those are two far away even though none of my local DCs are available if things go pear shaped.
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Al
Mulnick I personally haven't heard it referred to as "legacy". I think that may be because it wasn't a legacy method when I last heard it ;)
I haven't tested this, so your mileage may vary but: the "legacy" method would have been created and designed for a time before ICMP was the norm. As such, I wouldn't expect that to break if ICMP was disabled. Several things will break, but I don't believe that's one of them.
Test it. You'll know for sure then right? Besides, I don't imagine a lot of networks out there are configured with ICMP disabled like that.
Al On 12/31/05, Tom Kern <[EMAIL PROTECTED]> wrote: Thats it.
Isn't that the way its refered to in MS-speak?
I hope i didn't just make that
up... On 12/30/05, Brian Desmond <[EMAIL PROTECTED] > wrote: presumably setting the scriptPath attribute
on accounts...
|
- RE: [ActiveDir] icmp's Brian Desmond
- RE: [ActiveDir] icmp's joe
- RE: [ActiveDir] icmp's Brian Desmond
- RE: Re: [ActiveDir] icmp's Darren Mar-Elia
- RE: Re: [ActiveDir] icmp's joe
- RE: Re: [ActiveDir] icmp's Ulf B. Simon-Weidner
- RE: Re: [ActiveDir] icmp's Rick Kingslan
