[unisog] Determining local servers and banners
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 == 18' and src net '( 192.168.1
> or 192.168.2 )'
You might want to refine this somewhat, as 'tcp=18' will miss some
things. I suggest using
tcp&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
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
I don't follow you here. FTP's strictly TCP. Did you mean something else?
University of Minnesota
More information about the unisog