• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 370
  • Last Modified:

SIP on Windows 2000

I have just taken over some older windows 2000 servers that house a client server application. A recent scan from the Security Operations Center tells me that I have SIP services running and I need to justify having them or remove them. As far as I know, SIP is for IP telephony and we don't use anything like that on our servers. How do I go about disabling this? And is this wise?
  • 2
  • 2
1 Solution
Dave HoweSoftware and Hardware EngineerCommented:
it sounds unlikely - sip is (indeed) a form of voice over ip, usually on udp, and almost invariably on ports 5060 or 5061. There is some interplay between that and OCS, if you are running that, but I doubt strongly that is going to be on a win2k server.

It sounds more likely that *something* is running on port 5060 and/or 5061, and your SOC can't tell the difference between a random app on those ports and a real sip server.

I would suggest the easiest method is to use tcpview (from the sysinternals/microsoft site -
http://technet.microsoft.com/en-us/sysinternals/bb897437.aspx - and see what is running on that port. If it is non-obvious what it is that is running (its a service under svchost) then note the process id, and look THAT up using process explorer - http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

I suspect you will find that it is something harmless, but check with your SOC that they are just concerned that SOMETHING is running on 5060 (and if not, ask them what it is they *are* reporting so you can investigate further)
RBmuzacAuthor Commented:
They sent me this text of the scan:

Starting Nmap 4.76 ( http://nmap.org ) at 2009-05-04 09:02 MDT
Interesting ports on 161.X.X.X
Not shown: 988 closed ports
111/tcp  open     rpcbind
135/tcp  open     msrpc         Microsoft Windows RPC
139/tcp  open     netbios-ssn
445/tcp  open     microsoft-ds  Microsoft Windows 2000 microsoft-ds
1032/tcp open     msrpc         Microsoft Windows RPC
1095/tcp open     msrpc         Microsoft Windows RPC
1720/tcp filtered H.323/Q.931
2000/tcp filtered callbook
3372/tcp open     msdtc?
3389/tcp open     microsoft-rdp Microsoft Terminal Service
5060/tcp filtered sip
6502/tcp open     msrpc         Microsoft Windows RPC
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at http://www.insecure.org/cgi-bin/servicefp-submit.cgi :
Service Info: OS: Windows

Host script results:
|  Discover OS Version over NetBIOS and SMB: Windows 2000
|_ Discover system time over SMB: 2009-05-04 09:03:24 UTC-4

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 76.04 seconds

Honestly I don't know what to make of it. I downloaded the tools that you pointed out and  was not able to come to a conclusion. I didn't see anything with regards to port 5060. Is there anything else you can tell me about this? Thanks
Dave HoweSoftware and Hardware EngineerCommented:
ok, they have ran a very basic portscanner called "nmap"

While I say it is "basic", that isn't to say it isn't good - nmap is considered to be the best portscanner in existence, and many other pentesting applications just import its results rather than even attempting to come close to its ability - but scanning ports is *all* it can do; it gives you a list of ports that were responding with a handshake ("open") and a list of those who didn't even respond with a "RST" - which aren't open, but which they can't call definitively closed either. This is common when you attempt a tcp handshake to a udp port, which isn't ready to accept tcp, but which isn't closed either.

I would suggest initially that you re-run the test yourself - you can do this trivially, as nmap is free and available from http://nmap.org/download.html, and will run happily on a random windows xp workstation

Further, in the tcpview application, you should first untick "resolve addresses" from the options menu, then sort by state -  by clicking that title bar.

if you look down the list, you should (if there really is something listening there) see an entry for UDP under "local address" with "listening" as the state. the far left entry ("process") should give a program name, followed by a number. the number is the process ID, which can then be looked up in process explorer. TCPView is a key diagnostic tool for cases of this type, although there are more detailed tools to cover a multitude of networking and process functions also available from the microsoft site.
RBmuzacAuthor Commented:
Thanks Dave. That worked! You are the man!

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now