[unisog] Determining local servers and banners

Alan Amesbury amesbury at oitsec.umn.edu
Mon Apr 4 21:57:56 GMT 2005

Harry Hoffman wrote:

> We are in the process of writing some apps to do this but I wanted to 
> see if anyone else is doing this, how they are doing it, and perhaps 
> any potential pitfalls...
> So, we are looking to determine all servers running in our IP space 
> and then grab any banners that we may find. We currently have a way to 
> do this for TCP where we look for the Syn/Ack bits set and the src 
> networks to be ours:
> tcpdump -i eth0 -w file.dmp 'tcp[13] == 18' and src net '( 192.168.1 
> or 192.168.2 )'

You might want to refine this somewhat, as 'tcp[13]=18' will miss some 
things.  I suggest using

    tcp[13]&0x12=0x12 and ...

to specifically look for SYN/ACK, as this will show SYN/ACK packets 
regardless of the state of other TCP flags (e.g., URG and PSH).

> We read this file and feed it into a perl script which fires off a 
> bunch of nmap scans to pull back the banners of the IP/Port found to 
> be a server.
> So, this gives us TCP servers and does a pretty good job...
> We don't have a way, currently, to grab udp servers. I understand that 
> a similar setup could be done with argus and the "-M hostsvc" flags 
> and I am currently investigating this option. Is anyone doing this?

I suspect UDP will be somewhat more difficult.  By definition, a 
listening UDP port doesn't have to return a response.  Traffic *may* be 
bidirectional, if the application using the port responds, but UDP alone 
is half-duplex and stateless.  Firewalling aside, sending traffic to a 
non-listening UDP port will (should) generate an ICMP port-unreachable, 
but traffic to a listening UDP port may not generate any response at 
all.  In contrast, TCP ports respond whether they're open or closed; you 
get an attempt to complete a handshake in the former case, and a RST in 
the latter case.

I'm not sure how much information you can get out of Argus.  While I'm 
not terribly familiar with it, I recall Argus' capabilities as being 
somewhat analagous to what you might get from data collected with things 
like Flowtools.  This will show you data volume, direction, and ports 
used, but won't tell you what's *really* going on.  (Just because 
something communicates on 53/udp doesn't mean the traffic's *really* DNS 
traffic.)  Sure, it's useful data, but I don't think it provides the 
same sort of data as you describe in your active banner-grabbing above.

The "easiest" approach I can immediately think of that might work to 
locate UDP services is to blast the target with traffic, then go back 
and try to probe those ports that *didn't* elicit an ICMP port 
unreachable.  Whether you get an answer or not is still dependent on the 
application, though.  No, I don't think that's a very elegant 
solution.....  :-(

After what little thought I'm giving this, I believe it may be easier to 
capture traffic and try to determine what services are out there based 
on protocol analysis.  So, I guess I, too, would be interested in 
hearing more about what people are doing to identify rogue UDP servers.

> I'm quite interesting to hear how others are solving this problem. 
> Nmap against 65000 ports to find a "quiet" ftp server isn't really an 
> option.

I don't follow you here.  FTP's strictly TCP.  Did you mean something else?

Alan Amesbury
University of Minnesota

More information about the unisog mailing list