Port 135

First of all, I've been lurking this forum for a while as a guest. It seems every time I google something security-related, I find a helpful thread on this forum, so thanks all.

I'm running XP sp3, freshly installed. I'm behind an SPI router (linksys with OpenWRT).

Port Explorer said svchost was using local port 135 (which is supposed to be related to RPC?) to listen from local address 0.0.0.0 to remote address 0.0.0.0, remote port 0. (Correct my phraseology if necessary.) So I followed the relevant suggestions here -- http://www.hsc.fr/ressources/breves/min_srv_res_win.en.html
And all that did was change the local address to 127.0.0.1, the port is still listening.

Should I close it? If so, how?

These are the only services I have running:
- DHCP Client
- Event Log
- Logical Disk Manager
- Network Connections Manager
- OpenDNSCrypt
- Plug and Play
- RPC
- Secondary Login
- Security Accounts Manager
- Audio
- WMI
- WZC

I did these registry tweaks related to RPC:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rpc]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rpc\Linkage]
"Bind"=hex(7):31,00,00,00,00,00

And in [...RpcSs], I added REG_SZ ListedOnInternet = N


And another ports question -- Is it a bad thing that OpenDNSCrypt is always listening on some ports? (Port Explorer lists opendnsinterface.exe and dnscrypt-proxy.exe). It's probably supposed to be doing that, but does that leave me vulnerable?

 

For more information on port 135, see https://www.grc.com/freeware/dcom.htm. A utility that closes the port is available there as well.

 

Thanks! That did it. Yesterday I already did this to disable DCOM -- http://www.updatexp.com/dcom-windows-xp.html
I guess the dcombobulator did another thing not mentioned there.

Before closing 135, I clicked "Am I vulnerable?" and it tried ShieldsUp on the port. Result: port was stealthed. So I guess listening to 0.0.0.0 didn't really count as listening?


And I guess I shouldn't be worried about the DnsCrypt listening ports?

 

I'm not familiar with opendnsinterface.exe or what ports it opens. As for dnscrypt-proxy.exe, it does listen on port 53. Why it's necessary I don't know. The IP shows as 0.0.0.0 because there is no connection to any real IP. In this case, 0.0.0.0 basically means listening for any connection. Unless an actual IP is named, most anything listening will be shown as using 0.0.0.0. Remote port 0 means any remote port.

As for being at risk from the open port, it's theoretically possible but not that likely. In order to utilize the open port for an attack, an exploit that targets the specific application or service behind it is necessary. Few attackers would waste time and resources attacking something this uncommon, government agencies being the only likely exception. That said, it is part of your attack surface, since it is exposed. You have several options for hardening this particular component. One option is a firewall rule that only allows inbound and outbound connections to the specific IP it's using. Software firewalls shine here. You can also use DropMyRights with dnscrypt-proxy.exe. It will run constrained. With DMR, even if dnscrypt-proxy.exe is successfully exploited, it has very little access to the rest of your system.

 

The 0.0.0.0 was svchost, port 135 (which is no longer listening thanks to dcombobulator).
Most of the dnscrypt/opendns instances are going to the loopback (but one goes from 0.0.0.0 to the opendns server, and another goes from loopback to 0.0.0.0).

So inbound only to loopback, and outbound only to loopback and the opendns server? What do I do about the 0.0.0.0's when setting the rules?

I'll try with my router, otherwise I'll do it with Windows Firewall (I'm assuming I don't need a third-party one just to make a simple rule like that).

I duckduckgo'd that just now and from the sounds of it, that program is only useful if you log in as an admin. I log in as a restricted user (in fact this might have been the place where I originally heard that advice).

 

DNS, whether it's done directly or uses dnscrypt-proxy requires allowing both inbound and outbound to the DNS servers IP, remote port 53. The local port will vary through a fairly large range. Loopback/localhost traffic can be a bit confusing here. All of this takes place on the PC. The router sees none of that traffic. All the router will see is the LAN IP of the PC and the ports being used. Only a software firewall can control loopback/localhost traffic. Some do it well. Some either don't filter it at all or appear to have hard coded rules that permit all localhost traffic. Whether or not you actually need a software firewall depends on how much importance you place on controlling outbound and loopback traffic. If you use services like Tor or local web filtering proxies like Proxomitron or Privoxy, software firewalls can be invaluable for preventing leaks and blocking connections that bypass the proxy or anonymizing service.

Depending on how your network is set up, you can make firewall rules in the router that allow DNS traffic (both directions) only to the OpenDNS IPs and blocks all other traffic to remote port 53.

I can't comment on the permission/access difference between a restricted user and the permission changes from using DMR. For a comparison, the screenshot below, taken from process explorer, is for dnscrypt-proxy.exe, run as constrained by DropMyRights. I'm running as administrator.