[unisog] Determining local servers and banners
bsmithsweeney at nyu.edu
Fri Apr 8 15:34:37 GMT 2005
Reynold McGuire wrote:
>Is that script and DB Schema something you can share?
>Sounds like a good idea to me... I have been playing with the idea of that,
>so far all I have running is a perl program I wrote to collect all of the
>arp cache from my edge devices and record the data in a postgresql db,
>hostname,ipa,mac,routerid,router port,mac vendor,date & time... that way we
>can find 'offending' users on our nets.
> Reynold McGuire
> Network Coordinator
> Suffolk University, Network Services Group
> Phone : 617.994.4277
> Fax : 617.573.8747
>PGP Public Key:
>echo "send pgp key" | mail rmcguire at suffolk.edu
>5779 6001 FAC8 91EE FD93 6779 B408 1296 F6FF CD7E
>From: unisog-bounces at lists.sans.org
>[mailto:unisog-bounces at lists.sans.org]On Behalf Of Are Leif Garn}sjordet
>Sent: Wednesday, April 06, 2005 1:43 AM
>To: UNIversity Security Operations Group
>Subject: Re: [unisog] Determining local servers and banners
>On Mon, 4 Apr 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
>>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
>>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
>>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'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.
>We here at the University of Oslo have a perl based system as you
>describe. All our scans is saved a postgress db with a apache frontend. We
>pingscan all subnetts around the clock and portscan active hosts with
>nmap. At all times we have some TCP & UDP scanns going (not sure how many
>but can check). I think we managed to UDP scan all our 15 000 active nodes
>in about 3 months. Every node is at least tcp scanned once a week.
>This system is mainly used to find non complient computers (win95/NT4/Pre
>OSX MACs, non standard Samba etc) and "rough" services (smtp, ftp,
>At the moment we are looking to cross check the database against our
>router logs, we want to find machines "firewalling" us...
Interesting...how many active hosts are you scanning? We too have been
doing some active exploit detection here using nmap+amap, with an eye
towards keeping that data for comparison later.
I asked about number of hosts because I'm working on getting active
scans to run A) more accurately, and B) within a reasonable (1 week)
amount of time. Would you mind sharing your nmap timing options, and
what your associated % of host response is? And I too would be
interested in seeing your database setup, if it's available.
Even though right now we're only getting data back from2 about 5k of our
30k active hosts, the follow-up amap gives us real good data on FTP
"quiet" backdoors, so I would still recommend it to anyone looking for
this type of compromise. Those machines with FTP banners generally
point us at hosts that could turn into DDoS clients, brute-force
password attackers, etc. . I've also noticed a tendency for
script-kiddie FTP backdoors to have some rudimentary portscan detection,
so more and more I'm having to nmap from one host and amap from another.
We're also keeping track of "common" ports used by ftp backdoors on our
network and attempting to identify patterns of non-bannered ports on
those obviously compromised hosts that will help to identify others
compromised in more subtle ways. Unfortunately, with the number of
hosts we've got, real OS/applications fingerprinting seems too slow to
Sr. Network Security Analyst
ITS Technology Security Services, New York University
bsmithsweeney at nyu.edu
More information about the unisog