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

TCP/IP Port 49683 and 61748 found open on server

I recently installed some security scanning software on my network and have been receiving reports from a domain controller on the network that udp ports 61748 and 49683 are open and closed depending on when the report is run.  The security software ties these two ports to two known Trojans KiLo and Fenster respectively.  

I've done some research to see how I can identify whether those Trojans are installed and based on my research have not found anything on the server to suggest it has been compromised.  What I'd like to do to satisfy my curiosity is to figure out what those port are being used for--it may be some app I have installed...

My question is:  What is the best way to log the use of ports over time to see what application is using those ports?

Thanks,
Scott
0
blackgoo73
Asked:
blackgoo73
  • 5
  • 3
  • 2
1 Solution
 
Toni UranjekConsultant/TrainerCommented:
Hi blackgoo73,

I suggest that you use Port Reporter which will create very informative log files but it might cause additional load on your server.
Download: http://www.microsoft.com/downloads/details.aspx?FamilyId=69BA779B-BAE9-4243-B9D6-63E62B4BCD2E&displaylang=en

More info:
"Availability and description of the Port Reporter tool"
http://support.microsoft.com/kb/837243

HTH

Toni
0
 
blackgoo73Author Commented:
Thanks--great tool...  Now it won't run on my box???  Here is the Dr. Watson report, any ideas?

Event Type:      Information
Event Source:      DrWatson
Event Category:      None
Event ID:      4097
Date:            11/11/2008
Time:            11:54:28 AM
User:            N/A
Computer:      Domain Controller
Description:
The application, , generated an application error The error occurred on 11/11/2008 @ 11:54:28.168 The exception generated was c0000005 at address 00402FBA (<nosymbols>)

portreporter-drwatson.txt
0
 
Toni UranjekConsultant/TrainerCommented:
No, I don't know why it does not run. You might take another approach, are these ports currently open?
Use netstat command, do ports 61748 and 49683 appear on list? Which security scanner did you use, did you use any other port scanning tool to reproduce results (like nmap or portqry). Did you scan your computer with antivirus software and Rootkit Revealer?
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
blackgoo73Author Commented:
I tried netstat and have issued an interval switch and >tofile switch just to see when the ports are open and listening.

The scan produced no results.  The RootKitRevealer won't install and gives me an i/o error that from my research states it is a known issue with no resolution for win2k sp4 machines (which is what this machine is).

Any other thoughts?

Thanks.
0
 
blackgoo73Author Commented:
Oh, sorry the scanning software is gfi languard v.8.0
0
 
Toni UranjekConsultant/TrainerCommented:
Are you sure that scanning result are reliable? Can you reproduce scan result with another port scanner? UDP scans are unreliable and can easily produce false positives.
0
 
blackgoo73Author Commented:
Good question.  I just ran the test again and it came up with an open udp port so I went directly to that server and issued a netstat -n -a.  The foreign address result for that port was "*" so not open...  Do you think it is reasonable to assume it is a false positive?


0
 
jahboiteCommented:
If the netstat statistic show the udp ports in question then there are services listening on those ports and they are open.  A star is shown for the foreign address because, being a connectionless protocol, there is no "established" state for udp ports.
Try issuing "netstat -ano" which will list a process id associated with that port and then look-up the process id in Task Manager.

Also you might use something like wireshark http://wireshark.org to capture packets between the scanning machine and the domain controller whilst performing a scan.  One the scan has finished, you can stop capturing and filter the list of captured packets by using a display filter such as "udp.port eq 49683 or udp.port eq 61748" and confirm the result of the scan.

You might also use a different network scanner for a second opinion - such as the venerable nmap http://nmap.org.
A command such as
nmap -sUV -PN -n --version-intensity 9 -p61748,49683 --packet-trace <IP_ADDRESS>
will try to determine whether there is a known service listening on those ports.
0
 
blackgoo73Author Commented:
jahboite,

Thanks for your suggestion on the -ano (especially the "o").  Although I could not run the o switch on my  win2k sp4 box I could run it on another win2k3 domain controller.  Upon running it on there I found the same behavior.  I then checked another domain controller on another domain and the same behavior was there too.  All the open ports (about 2500 of them) were associated with the dns process.  I checked around on the net as to why this would be the case and learned something about windows dns along the way.  

I've blogged about this whole experience and gave you some claim to fame so I could remember this later as it is rather interesting.

http://www.scottieskillet.com/blog/2008/11/14/windows-dns-server-uses-2500-port-in-the-ephemeral-range/

Thanks for your help...
0
 
jahboiteCommented:
Nice!  Though, a word of caution:  Binding to a socket to send a UDP datagram is not the same as binding to it to listen for incoming datagrams.  The former doesn't change the listening state of the port, the latter means the port is open.  Therefore, if a port scanner determines the port to be open, then it *SHOULD* be bound by a listening service and not one simply using the port to send data as in the case of a DNS resolver.

I'm not familiar with GFI's scanner, but I can tell you that an nmap UDP scan is unlikely to show a listening port as open without performing version detection.  This is because very few services that listen on UDP ports respond to an emtpty datagram - as sent by nmap's -sU scan.  In these cases, nmap will not receive a reply to the probe and will accordingly mark the port as "open|filtered" - meaning "it may be open (and not responding to an empty datagram) or it may be filtered (the probe was dropped by a firewall) - I can't tell because I didn't get a response".
It will, however, mark a non-listening port as "closed" upon receipt of an ICMP port unreachable packet from the target operating system, for example.

With version detection, nmap will send udp datagrams with various data payloads - one or more of which MAY elicit a response from the listening service.  A good example would be the dns service listening on UDP port 53 which will, in many cases, ignore an empty datagram, but respond to the "DNSVersionBindReq" probe.  At this point the port will be marked as "open" and it will likely tell you what implementation of DNS service is listening.

It's possible that the GFI scanner was confused when, having sent its probes, it saw a dns request originating from that port.  This is unlikely to be the case in a layer 2 switched environment, but in other cases would point to a poor implementation of the scanner.

With this in mind, I hope that you'll consider running GFI again and using something like wireshark to capture the traffic between the scanning machine and the target.  Then, if you get an open port in the report, you can find the response in the captued traffic and determine the nature of the listening service or the reason for the false positive.

I'd also highly recommend performing the port scan with nmap which will give accurate results.
0

Featured Post

What Security Threats Are We Predicting for 2018?

Cryptocurrency, IoT botnets, MFA, and more! Hackers are already planning their next big attacks for 2018. Learn what you might face, and how to defend against it with our 2018 security predictions.

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