Re: Messenger Service on W2K server

From: David Williams (davidwnh@ncia.net)
Date: 10/16/02


From: "David Williams" <davidwnh@ncia.net>
Date: Tue, 15 Oct 2002 23:25:47 -0400


Gary,

Thanks for the info on blocking UDP-135! Looks like you were instrumental in
this solution.

Looking at item #3 Are you in effect breaking DCOM on the server in which
you have made these settings? That I can't say for sure since the article
says always "Y" for that reg entry and doesn't explain the consequences of
"N". However it looks like this is to be used in conjunction with the others
reg settings in the article for a different, however related purpose. The
article you refer to seems to me to be referring to a way to restrict dcom
on an application server for example so that it forces dcom to use specific
ports when allocating them dynamically so that you don't have to leave the
entire high range of ports available on your firewall.
I may be wrong, I'm no expert on this subject but this does seem to be
conflicting to me.

As to messenger breaking anything, I think it is more that you just won't
receive any directed alerts sent via the alerter service or net send or some
third party application(like DirectAdvertiser). It is always best to just
disable the service if it is not used. Also a lot of programs allow alerts
to be sent via email as well as alerter so that may be a viable solution for
some.

Well anyhow thanks and hopefully blocking alone UDP-135 solves this for most
in any case...that is till the spammers find another way!

"Gary Flynn" <flynngn@jmu.edu> wrote in message
news:3DACBAE9.56BD241D@jmu.edu...
> Couple followup notes that may be of interest.
>
> 1) From the DirectAdvertisor test page, the first packet is sent to
> UDP-135 whether or not other ports are open. I took out the
> router filters blocking 137-139,445 and the initial packet was
> still sent to UDP-135. There was speculation on my part that the
> way the messages were sent depended on what ports were available.
> I haven't tested the demo version to see if its the same.
>
> 2) After the intial packet to UDP-135, which looks as though contains
> the message data, there is a back and forth exchange on high UDP
> ports that Ethreal labels an RPC "who are you" conversation.
>
> 3) Using the information in "Using DCOM with Firewalls", I added the
> following registry entry:
>
>
HKEY_LOCAL_MACHINE/Software/Microsoft/RPC/Internet/PortsInternetAvailable
>
> and set its value to "N" (without the quotes). After doing so,
> the DirectAdvertisor demo page was not able to send me a message.
>
> This may be an alternative to shutting down the Messenger service
> altogether if that causes local problems. I've seen some people say
> it might be used for things like spooler messages.
>
> Of course, if the Messenger service functionality is desired from
> remote systems, access will have to be controlled via an external
> device like a firewall or they'll have to live with abuse. Perhaps
> Microsoft will offer a patch that will allow the service to be
> configured with the list of allowed IP addresses that can use the
> service. And perhaps set the default so that only addresses on the
> local network (as defined by the computer's IP address and subnet
> mask) can access the Messenger service. Or disable the Messenger
> service network access altogether by default.
>
> 4) I tried removed the following registry entries and rebooting the
> computer but the message was still received. I was hoping removing
> the UDP affiliated one would prevent the problem without having
> to stop the Messenger service:
>
> HKEY_LOCAL_MACHINE/Software/Microsoft/RPC/ClientProtocols/
>
> ncadg_ip_udp
> ncacn_ip_tcp
> ncacn_http
> ncacn_np
>
> 5) I'm monitoring both UDP and TCP network traffic now to see if there
> are any other uses for UDP-135. I had thought previously everything
> used 135-TCP. If so, maybe UDP-135 can be blocked without affecting
> other services. However, if Messenger can also be contacted on
> the TCP port....
>
> 6) Does anyone have any resources indicating what applications may
> break if the Messenger service is shut down? If it isn't accessible
> via IP?
>
> All tests performed on XP Home.
>
> Useful RPC References:
>
> Microsoft RPC
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rpc/rpc/ove
rviews.asp
>
> Using DCOM with Firewalls
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndcom/html
/msdn_dcomfirewall.asp
>
> --
> Gary Flynn
> Security Engineer - Technical Services
> James Madison University
>
> Please R.U.N.S.A.F.E.
> http://www.jmu.edu/computing/runsafe



Relevant Pages

  • Re: Windows Messenger Pop-up spam
    ... if all that ever used those ports was Messenger. ... But the thread isn't about blocking all ports and all services, it's about Messenger spam. ... The original question wasn't about overall, general security...it was about blocking spam to the Messenger service. ...
    (Security-Basics)
  • Re: DCOM
    ... > And DCOM is only one of the vulnerabilities that can be reached via TCP 135. ... > won't cause TCP or UDP 135 to be stealthed or blocked, because the RPC ... > endpoint mapper is the service that is really listening on those ports. ... > The reason for considering disabling DCOM or RPC would be to protect you ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Port 1026
    ... Related Ports: ... wide open to the external Internet. ... If Microsoft wants to allow DCOM ... configuration of your firewall rules. ...
    (comp.security.unix)
  • Re: DCOM
    ... You can stealth 135 with a firewall right now, ... DCOM, and XP SP2 has little to do with either one. ... change the fact that TCP and UDP ports 135 are listening, ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Port 1026
    ... Related Ports: ... wide open to the external Internet. ... If Microsoft wants to allow DCOM ... configuration of your firewall rules. ...
    (comp.os.linux.security)