On Thu, 20 Dec 2001, Carl Parrish wrote:

> Is there anything like nmap on a *default* install of Redhat? I guess I 
> don't really need all the features of nmap. I just need to figure out if 
> a port is open and if its been active. Problem is I didn't set the 
> server up and don't know what's installed. any ideas of tools I should 
> look for? Or should I just install something? Is there any way to look 
> up past activity on a port?
> 
> Carl P.
> 
> ________________________________________________
> See http://PLUG.phoenix.az.us/navigator-mail.shtml if your mail doesn't post to the list quickly and you use Netscape to write mail.
> 
> PLUG-discuss mailing list  -  PLUG-discuss@lists.PLUG.phoenix.az.us
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
> 


Hey Carl:

As was mentioned before, netstat can help you.

netstat -l

or, I like to do

netstat -nap

the -p is helpful to tell you what process is bound to that
"listening" port

lsof can also be helpful (especially if somebody trojaned your netstat,
but didn't think about lsof :)

If you really don't trust the box, then you might want to go ahead and
nmap it from another, trusted host.  You might want to include the full
range of ports, as nmap will default to only scanning 1-1024 and ports
listed in nmap's (rather comprehensive) services file.  People like to
bind rogue services to all sorts of weird port numbers, usually high
numbered, as non-stateful firewalls often allow connections to ephemeral
ports.

Also, always good to see what's in a ps axf command, and maybe what lurks
in your startup scripts and cron.

If you really don't trust the box, then in addition to the nmap scan, I
wouldn't trust anything the running kernel told you (or told your
userspace tools like ps, netstat, etc.).  Rather, I'd boot from trusted
media (like a rescue disk) or pull the drive and mount it in a trusted
host.  Then you can really be certain that what you see is what you
get/have ;)  But that's me, YPMV (your paranoia may vary) ;D

I might also throw a sniffer on the network(s) that the host is connected
to and capture all traffic for a period.  Then you could see illicit icmp,
udp, ecp, etc. traffic going on, in addition to the tcp stuff you scanned
for with nmap.  You could scan udp with nmap...but that can take a
painfully long time :)  UDP has no way to say "rst" on its own ;)  Anyhow,
if you do sniff the traffic, you probably want a snaplen of 1514 or so
(1500 MTU for ethernet, plus the 14 bytes for the ethernet frame
header).  If it's a real busy network segment, then you might not be able
to do that.  In that case you could set a snaplen of 96 or something and
get all the headers, and a little peak at the contents.  Of course, when
you see something interesting on the wire, you'll be kicking yourself for
not having the whole packets.  Ah, the trials and tribulations of a
network voyeur ;D

Good luck,

Wes

-- 
Wes Bateman, GCIA
Chief Security Officer
ManISec, Inc. - "Managed Internet Security Services"
http://www.manisec.com
wes@manisec.com