[sf-lug] Cool little security check

[Rick Moen]

Quoting aaronco36 (aaronco36 at SDF.ORG):

(I have to say, your learned chasing down of links continues to be kind
of awesome, Aaron.  Thank you for the Nmap Cheat Sheet, among other
things.)

> Instead of using this ShieldsUp security check on one's own machine,
> IMHO, you might also want to seriously consider getting more
> up-to-speed with the Nmap Network exploration tool and security /
> port scanner.

Heartily recommended.  I'm not familiar with the GUI front-end Zenmap
for it, but can include some real-world nmap results, below.  

As with all such information, how to interpret and use that information
is a separate problem.  Approached mindlessly, it could lead you to
doing self-defeating things like blocking ping.  ;->

To get meaningful results using nmap, one must have a second machine on
the same wireless or wired network as the target machine.  The phrase
'on the same network' entails absence between the two machines of any
router or other device that would filter traffic between them, because
that could easily lead to a false report of no services found when they
were in fact happily listening on the _local_ network for connections.

It suffices to have the two machines being wirelessly connected to, and
getting DHCP leases from the same WAP (2018 commodity networking) or
both on the same wired ethernet network getting DHCP leases from the
same DHCP server (1990 commodity networking).  But the point is, you
need that second machine, and it must be _local_ to the target.

And, note:  Since Steve Gibson's flashy little toy ShieldsUp is not
local to your and my machines at all, its results are inherently at risk
of telling you mostly meaningless crap, unless you're absolutely certain
there's no port-blocking between you and grc.com.

(In fairness, though, arguably what you are seeking is knowledge of what
ports on your machine are reachable specifically from the _Internet_, 
so maybe excluding services that aren't reachable only because of
port-blocking is appropriate -- if you don't care about the possiblility
of your machine being attacked by security-compromised local machines,
which IMO you should.)

By the way, completely aside from ShieldsUp being a proprietary black
box, and aside from its alleged results being at risk of sabotage by
port-blocking, I heard Gibson speak at the time he put ShieldsUp online,
and he really didn't have any idea what he's talking about.  He reminded
me of the quip attributed to 19th Century American journalist Artemus
Ward:  'It ain't so much the things we don't know that get us in
trouble.  It's the things we know that ain't so.'


> Sure, there *is* a learning-curve for effectively using Nmap to
> port-scan one's own machine as compared to using ShieldsUp for the
> same!

Although you _can_ make nmap port-scan the local machine (localhost, 
IP address 127.0.0.1, the machine nmap itself runs on), that would lead
to some peculiar and misleading results, because it would tell you what
network services are reachable _locally_.  It's fine to know what's
usable locally (and you really ought to know without needing nmap to
know it), but... er... why are you really doing this?  Are you worried
about the attack surface the machine poses to _itself_?

If you do a local nmap of a machine running the MySQL database, nmap
will correctly report the existence of an active network listener on TCP
port 3306.  That's because MySQL's default configuration binds the
listener process to the _loopback interface only_, i.e., mysqld accepts
connections only from localhost aka IP address 127.0.0.1, thus making it
a local facility reachable by other _local_ processes, like PHP or
Python scripts and all that.

But that's absolutely not the same as port 3306 being accessable from
_other_ network locations, which is typically what you want to know when
you port-scan a machine.  So, port-scanning localhost can be misleading;
you might conclude remote-accessible network services are active when in
fact they're deliberately local-accessible only.


So, you'll note a question I keep bringing up in various ways:  What are
you actually setting out to accomplish, and why?  If trying to gain a
bit of knowledge, why _that_ bit of knowledge?  What are you going to do
with it, and why do that thing?  This is never more important than in
security, where just adding more layers of complicated machinery is
actively harmful, standing in the way of your understanding what's going
on and often shooting you in the foot.


At my mother-in-law Cheryl's invitation, in 2003, I nmapped her Windows
ME box to see what on it was listening on the network.  (Answer: lots of
juicy, probably vulnerable stuff.)  For each scan, I've added a note
mentioning the scan type.  For more on that, see
https://nmap.org/book/man-port-scanning-techniques.html .



[RM note: Following is a TCP connect scan, signified by -sT]

guido:/home/rick# nmap -vv -sT -sR -O -I -oN nmap.log -n 10.0.1.3

Starting nmap 3.27 ( www.insecure.org/nmap/ ) at 2003-08-15 12:14 PDT
Host 10.0.1.3 appears to be up ... good.
Initiating Connect() Scan against 10.0.1.3 at 12:14
Adding open port 1025/tcp
Adding open port 135/tcp
Adding open port 5000/tcp
Adding open port 139/tcp
The Connect() Scan took 27 seconds to scan 1623 ports.
Initiating RPCGrind Scan against 10.0.1.3 at 12:14
The RPCGrind Scan took 1 second to scan 0 ports.
For OSScan assuming that port 135 is open and port 1 is closed and neither are firewalled
Interesting ports on 10.0.1.3:
(The 1619 ports scanned but not shown below are in state: closed)
Port       State       Service (RPC)           Owner
135/tcp    open        loc-srv
139/tcp    open        netbios-ssn
1025/tcp   open        NFS-or-IIS
5000/tcp   open        UPnP
Remote operating system guess: Windows Millennium Edition (Me), Win 2000, or Win XP
OS Fingerprint:
TSeq(Class=RI%gcd=1%SI=291C%IPID=I%TS=0)
T1(Resp=Y%DF=Y%W=FAF0%ACK=S++%Flags=AS%Ops=MNWNNT)
T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
T3(Resp=Y%DF=Y%W=FAF0%ACK=S++%Flags=AS%Ops=MNWNNT)
T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)

TCP Sequence Prediction: Class=random positive increments
                         Difficulty=10524 (Worthy challenge)
TCP ISN Seq. Numbers: 8FD98AA3 8FDA8C00 8FDBE4D8 8FDD619C 8FDE97DA 8FDFE990
IPID Sequence Generation: Incremental

Nmap run completed -- 1 IP address (1 host up) scanned in 30.647 seconds




[RM note: Following is a UDP scan, signified by -sU]

guido:/home/rick# nmap -vv -sU -sR -O -n -oN nmap3.log -n 10.0.1.3

Starting nmap 3.27 ( www.insecure.org/nmap/ ) at 2003-08-15 12:22 PDT
Host 10.0.1.3 appears to be up ... good.
Initiating UDP Scan against 10.0.1.3 at 12:22
The UDP Scan took 15 seconds to scan 1471 ports.
Adding open port 138/udp
Adding open port 135/udp
Adding open port 1031/udp
Adding open port 500/udp
Adding open port 137/udp
Adding open port 1900/udp
Adding open port 123/udp
Adding open port 1032/udp
Initiating RPCGrind Scan against 10.0.1.3 at 12:22
The RPCGrind Scan took 9 seconds to scan 0 ports.
Warning:  OS detection will be MUCH less reliable because we did not
find at least 1 open and 1 closed TCP port
Interesting ports on 10.0.1.3:
(The 1463 ports scanned but not shown below are in state: closed)
Port       State       Service (RPC)
123/udp    open        ntp
135/udp    open        loc-srv
137/udp    open        netbios-ns
138/udp    open        netbios-dgm
500/udp    open        isakmp
1031/udp   open        iad2
1032/udp   open        iad3
1900/udp   open        UPnP
Too many fingerprints match this host for me to give an accurate OS
guess
TCP/IP fingerprint:
SInfo(V=3.27%P=i686-pc-linux-gnu%D=8/15%Time=3F3D330D%O=-1%C=-1)
T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)



Nmap run completed -- 1 IP address (1 host up) scanned in 28.496 seconds



[RM note: Following is a TCP ACK scan, signified by -sA]

guido:/home/rick# nmap -vv -sA -sR -O -n -oN nmap2.log -n 10.0.1.3

Starting nmap 3.27 ( www.insecure.org/nmap/ ) at 2003-08-15 12:23 PDT
Host 10.0.1.3 appears to be up ... good.
Initiating ACK Scan against 10.0.1.3 at 12:23
The ACK Scan took 3 seconds to scan 1623 ports.
Initiating RPCGrind Scan against 10.0.1.3 at 12:23
The RPCGrind Scan took 0 seconds to scan 0 ports.
Warning:  OS detection will be MUCH less reliable because we did not
find at least 1 open and 1 closed TCP port
All 1623 scanned ports on 10.0.1.3 are: UNfiltered
Too many fingerprints match this host for me to give an accurate OS
guess
TCP/IP fingerprint:
SInfo(V=3.27%P=i686-pc-linux-gnu%D=8/15%Time=3F3D334B%O=-1%C=-1)
T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)


Nmap run completed -- 1 IP address (1 host up) scanned in 8.380 seconds




Once you have the list of listening ports, now you may need to do
research to find out what running on that machine is offering remote
network services, why, and whether you want to stop that.  MS-Windows
people tend to be helpless to control what's running on their machines,
so at best they gravitate towards complicated measures like wrapping
everything in a 'firewall'.  On an open-source OS, we don't need to do
that.