Re: [patch] Oracle Enterprise Manager Agent cleanup

[David Fifield <david () bamsoftware com>]

On Fri, Jun 18, 2010 at 01:32:37PM -0700, Fyodor wrote:
> 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.

Thinking about this more, I agree with out. I just made a commit to
change the name to oem-agent. There are a few others that I want to
canonicalize, like xml-rpc, but I think it can wait until the next round
of service integration.

> 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.

Agreed. Some options for the interface are

portrule = shortport.http
portrule = shortport.special("http")
portrule = http.portrule

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/