When trying to determine what an is actually running on an unknown port, everyone first relies on their /etc/services file. You can get fairly up to date and complete ones which help a great deal (from apps like NMAP, or downloadable from www.portsdb.org, don't rely on the stock ones from Microsoft, most UNIX vendors or from RFC 1700.) I am assuming you are referring to ports that don't have a listing in services, or do, but the description is poor, incomplete, or just doesn't make sense. In this case, you have to start poking at the port to see how it responds when you send it data. The most important this to remember here, is that this type of scanning may very easily crash/kill/hang/reset a poorly written daemon or service. You will get some testers that say a good pen test will always require identifying unknown ports. I would agree, but I let my clients know up front what the risks are. Nothing spoils a relationship quicker than crashing an important system. With that said, you can start out quick and easy with a few small scripts wrapped around netcat or Perl + IO::Socket. As Yonatan Bokovza recommended, good strings to send are: QUIT\n or GET /\n. One thing you may want to use instead of \n is \x0d\x0a , which is the ASCII hex representation of carriage return then newline. This should cover a wider range of systems (YMMV.) Using these two strings, you will get a fair amount of feedback, usually in the form of error messages, which you can then try and hunt down from various resources. It becomes tricky when the daemon/service you are querying doesn't return error messages or responds to a binary protocol. You will get a lot more information by running something Like Saurik's NMAP+V patch, which was already mentioned, as it sends many more types of query strings, including a some binary stuff. Although this adds more risk to the test, because there is a greater chance that the daemon/service will choke on the greater amount of input. I am not sure about it's continued development status. HTH, Chris ------------------------------------------------------------------- Chris Winter Consultant Security Practice cwinterat_private Cell: 410 258-4817 Mentor Technologies-- innovators of vLab(r) technology, provides: ** high-end internetworking, skills-based learning services and solutions. ** high-end internetworking design, management, and security consulting. We're high tech, high touch, high performance; the total internetworking solutions company. Visit us at www.mentortech.com -------------------------------------------------------------------- ----- Original Message ----- From: "Erik Norman" <erik.normanat_private> To: "pen test" <pen-testat_private> Sent: Monday, July 02, 2001 6:13 AM Subject: Port identification methodology > Hi all, > > I have a question regarding methodology while performing a > PT. It concerns identifying programs/services. > > Imagine a full nmap scan has been performed. A handfull > of open ports was found on a particular server. The > usual 25, 53, 80 etc are identified, but one or two ports > stand out from the crowd. Looking in various 'common ports' > files does not provide a hint what the port is used for. > > Connecting with telnet yields no text, and a tcpdump > dump does not provide any text (in clear anyway). > > > Now what!??? > > How should one approach this? > > > /Erik > > -------------------------------------------------------------------------- ------------ > > This list is provided by the SecurityFocus Security Intelligence Alert (SIA) Service > For more information on SecurityFocus' SIA service which automatically alerts you to > the latest security vulnerabilities please see: > > https://alerts.securityfocus.com/ > > -------------------------------------------------------------------------------------- This list is provided by the SecurityFocus Security Intelligence Alert (SIA) Service For more information on SecurityFocus' SIA service which automatically alerts you to the latest security vulnerabilities please see: https://alerts.securityfocus.com/
This archive was generated by hypermail 2b30 : Thu Jul 05 2001 - 16:17:51 PDT