-----BEGIN PGP SIGNED MESSAGE----- Setting aside Michael's rather exuberant comments (both those about RPC, and the BO stuff); 1027 and 1030 in the poster's system are, 99.9% assured, something like IIS Manager, Exchange Administrator, DNS Manager, etc... NT applications which also act like servers, running via RPC, thereby opening high ports (above 1024). If they're started up dynamically from the GUI, they're port numbers will change depending on the order they're started. If they're fired up from the Startup Group, or via the registry, then they're port numbers may be the same after each boot. Running Netstat -an 1 and starting and stopping the various GUIs an NT machine offers will allow you to see the ports opened and closed. There's a utility which Microsoft put together (its pretty crude) that will query the RPC end point mapper (TCP135) and return a list of available services. This does nothing to tell you what is listening to what port, simply what RPC services may be available from a given box. Email me if you want a copy of it (although you can get the same thing by simply learning to understand the registry). Most NT applications which use RPC rely on NT authentication in order to work, meaning they're not typically simply listening for any old connection. This typically means a connection via TCP139 to Net Logon is required prior to being able to use them (IPC$). The means that blocking access to that port may prevent some brute force attempts. Some services, however, like Exchange Server Information Store and Directory Store services (required to use Outlook in RPC mode) are RPC-based (begin connection via TCP135), but are able to perform authentication directly via they're dynamically (or statically) assigned ports (returned by the connection to TCP135). The bare minimum for any exposed NT box is to have router ACLs preventing access to T/U 135 and 137-139. This, of course, after applying the latest TCPIP.sys which not only improves ISNs (to reduce the risk of spoofing), but should also permit the use of the registry entry referred to in; http://support.microsoft.com/support/kb/articles/Q217/3/36.ASP which allows you to disable source routing. This fix was included in SP5, but since its a TCPIP registry parameter, and since the latest HotFix to TCPIP should be applicable to any system running SP4 or higher. See; http://www.microsoft.com/security/bulletins/MS99-046.asp for more details on the HotFix. Now after all of this is said and done, I have to comment on Christoph's message. Are things in Switzerland so bad these days?? Do all of your customers have BO and NetBus running on them? Do all security consultants that you know have defective versions of Norman Data Defense and Norton AntiVirus? There is only one solution to the problems presented by the scan results you saw on the machine in question. DESTROY THE HARD DRIVE, REPLACE IT WITH ANOTHER, KEEP THE MACHINE TURNED OFF UNTIL YOU; 1. Define a Security Policy, within which, detection of BO or NetBus is considered a total compromise. 2. Implement Router ACLs on the net connection (at a minimum). 3. Do your customer a favor and suggest they find some competent consulting advice. This isn't a flame because your message states clearly you don't know what you're doing. Cheers, Russ - NTBugtraq Editor Search the NTBugtraq Archives - http://ntbugtraq.ntadvice.com/archives -----BEGIN PGP SIGNATURE----- Version: PGP 6.0.2 iQCVAwUBOBO8OhBh2Kw/l7p5AQHlCQQAgPKqeLWovIXFeLPP6XbOn90kh9incFfn KTs0U+Cj9QrZYM32quf5rspUOt1TLcsNA7BxQaoS+F5E3AUkd5fCw4cNZB5oTYci tc/QDaAeQhY9py+Olj3pnHdgvW+fVoDCzRykcYxAJcOwrdMkXHoUQbVDbHwBjtKo dkkVXiKQApE= =lZvy -----END PGP SIGNATURE-----
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:44:56 PDT