From: Information Security (InformationSecurityFEDERATEDINV.COM)
Date: Wed Oct 01 2003 - 12:25:45 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

OK, sounds like folks pretty much confirmed that blocking ICMP blocks
Group Policy updates for at least some users. Personally, this seems
pretty significant to me since loss of group policy updates is a
"silent" failure--you don't know about it until something quits working.
So I've compiled a few responses I recieved in the hopes they'd help
someone else as well (thanks to all!):

------

We did experience the same problem you are referring to. Microsoft gave
us a document of required traffic for an AD domain and it did not
include ICMP.

179442 How to Configure a Firewall for Domains and Trusts
http://support.microsoft.com/?id=179442

We verified that we had all of the required traffic open internally and
the problem still existed. I issued a "secedit /refreshpolicy" command
and sniffed the traffic and sure enough a ICMP request went out.
Microsoft did some internal research and came back with this. They also
promised to update the document above.

227260 How a Slow Link Is Detected for Processing User Profiles and
Group Policy http://kb/article.asp?id=Q227260

Other problems were occurring at this time. For instance when we right
clicked on a user in the AD for users and computers and selected "Add
members to a group.." the Object Picker would give an error and did not
show up. After restoring ICMP the problems went away.

------
We saw experienced similar restrictions after stopping all ICMP traffic
on our network. Besides the loss of Ping and Tracert, we also lost
almost all remote connectivity to VPN users. The workaround we are
preparing to present to leadership here is to open up ICMP ONLY for
packets that are between 30 and 90 bytes large and then explicitly
stopping 40 byte packets. Effectively returning most of our much missed
ICMP traffic to the network. We're testing for tracert, we've been using
a UDP tracert program but some people want to return to the old ICMP
tracert. We used Ethereal to capture packets and inspect their sizes to
determine the sizes to allow. If you can track down what ICMP packets
you need to allow through you can configure the routers to block the
rest. Hope that helps!
------

You can Disable Slow Link Detection by Setting the Group Policy
componenet to 0 in the Default Domain Policy. It can be found under
Computer Configuration\Administrativ Templates\System\Group Policy\Group
Policy Slow Link Detection. This may allow you to bypass the need for
ICMP in your VPN machines. You could also set this policy at a lowere
level as long as that OU contained all of the remote PCs. The only
problem is it would need to apply the new policy before it takes affect
which would not occur as long as ICMP remained disabled. Good Luck, HTH.

-----

I can tell you that we saw the same problem. The solution was to open
ICMP up to everything except for the packet size that Nachi uses (92
bytes, I believe).

-----

-----Original Message-----
From: Information Security
Sent: Tuesday, September 30, 2003 11:01 AM
To: NTBUGTRAQLISTSERV.NTBUGTRAQ.COM
Subject: ICMP Ping and Group Policy Update

In response to Nachi, we blocked ICMP Pings to & from our VPN. However,
it appears that this also has disabled group policy updates for remote
VPN users. We ran network traces and saw the ICMP packets, I think
they're part of the negotiation phase where the server tries to
determine if the client is on a slow link.

I suspect a lot of networks cranked down on ICMP after Nachi. Can
anyone else confirm this behavior? Does anyone have a workaround or
configuration setting to override/bypass this feature?

Thanks!

----
Are You "Certifiable"? Summer's Hottest Certification Just Got HOTTER!

With a growth rate exceeding 110%, the TICSA security practitioner
certification is one of the hottest IT credentials available. And now,
for a limited time, you can save 33% off of the TICSA certification
exam! To learn more about the TICSA certification, and to register as a
TICSA candidate online, just go to

http://www.trusecure.com/offer/s0100/

----

-----
Wondering as to whether the list is running? The NTBugtraq archives are
updated first before messages are emailed to subscribers. Check the
archives first to see if you have missed any messages;

http://www.ntbugtraq.com/archives

-----

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]