Nmap Development mailing list archives

Previous By Date Next
Previous By Thread Next

Re: [patch] Oracle Enterprise Manager Agent cleanup

From: Fyodor <fyodor () insecure org>
Date: Fri, 18 Jun 2010 13:32:37 -0700
On Tue, Jun 15, 2010 at 06:46:55PM -0600, David Fifield wrote:

On Mon, Jun 14, 2010 at 12:12:11PM -0400, Matt Selsky wrote:

After:

3872/tcp open  oem-agent Oracle Enterprise Manager Agent 10.2.0.3.0
3872/tcp open  ssl/oem-agent Oracle Enterprise Manager Agent 10.2.0.3.0


Thanks, it's applied in r18147. The only change is that I used the
service name "http" instead of "oem-agent", because that's our
convention for HTTP-based services.


Maybe we should reconsider this convention?  I can see some advantages
to using the actual defined IANA name in this case:

o Consistency with nmap-services file.  oem-agent is too new to be in
  our nmap-services, but next time we sync with
  http://www.iana.org/assignments/port-numbers (I added a todo task for
  that), we'll have it.  It seems like the same service should be
  named consistently whether you use version detection or not, but would
  we really want to list it as "http" in nmap-services?  Using
  oem-agent in this no-service-detection case gives more useful
  information, IMHO, and is also in line with the IANA assignment.

o Consistency with how we treat other specific services running on a
  general data transfer protocol.  For example, we use "nfs", "rpcbind",
  and the like rather than "sunrpc" for all of the services using that
  protocol.  In fact, we even have a whole file (nmap-rpc) for
  distinguishing RPC services from each other.  Similarly, we give the
  specific names for MSRPC/SMB services.  And for SSL, we tunnel through
  that to get the specific service name (though we do print and keep
  track of the fact that it is SSL tunneled).

o When reading the Nmap results, I often focus on the service field.
  I'd usually rather see the specific service names than the higher level
  data exchange protocols they use, like a bunch of "http" entries.

o When browsing nmap-service-probes I do see other protocols listed specifically even though they use http.  For 
example, IPP has dozens of match lines like:

match ipp m|^HTTP/1\.0 200 OK\r\nContent-Type: text/html\r\n\r\n<HTML><HEAD><META HTTP-EQUIV=\"Content-type\" 
CONTENT=\"text/html; charset=iso-8859-1\">\r\n<TITLE>IBM Infoprint Color (\d+)</TITLE>| p/IBM Infoprint Color $1 ippd/ 
d/printer/

Perhaps we should treat ipp like oem-agent (whichever way we end up
going).

I can see Tom Sellers' point that labeling the service as http makes
it easier for our http-* scripts to find it and that some of those
scripts might be relevant to this service.  But we could resolve that
in other ways.  Already the rules for detecting http services are
getting more complex and less consistent:

http-auth.nse:portrule = shortport.port_or_service({80, 443, 8080}, 
                                                   {"http","https"})
http-date.nse:portrule = shortport.port_or_service({80, 443, 631, 8080}, 
                                                   {"http", "https", "ipp", "http-alt"})
http-favicon.nse:portrule = shortport.port_or_service({80, 443, 8080, 8443},
                                                   {"http", "https", "http-alt", "https-alt"})

I think we should have a shortport function for detecting http
services in any case.  And if we do that anyway, it would be easy to
add the services which we know use http.  If desired, we could note
that the services are http-based in nmap-services and/or the extrainfo
field of nmap-service-probes.

So I can see both sides of this issue.  But for me, I think oem-agent
may deserve its specific service name because:

o It has an official port amd service name registered by the IANA

o It's not a traditional web server which provides HTML pages to
  browser clients.  It seems to be a service which other Oracle
  infrastructure talks to.  It just happens to use HTTP for its data
  transfer.

Cheers,
Fyodor
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/
Previous By Date Next
Previous By Thread Next

Current thread: