>> Welcome to the Nmap scan techniques lab.
We have a lot to cover here,
so let's get started.
In the following lab, we'll go through all of
the main scan techniques used in Nmap,
which are the SYN scan,
the TCP full connect scan, UDP scans,
a combination of SYN scans, and UDP scans,
and we'll finish with the IP protocol scan.
There are a couple of times in the lab when I refer
to a SYN scan as a TCP scan,
this is technically accurate since a SYN scan is
a type of TCP scan, because it uses TCP at Layer 4.
But please understand the difference between
the SYN scan, and a TCP full connect scan.
I do point out the differences,
but just don't want you to be confused. Let's do it.
Welcome to the Nmap scan techniques lab.
The first thing I want to do was show you, in general,
where I like to place
my scan techniques in my Nmap statement.
I'll do the following.
[NOISE]
Don't get too hung up in all the extra details here.
But basically, we're doing a SYN scan.
I'm doing ports 1-100 of
this host, and then I'm outputting to output.nmap.
The main point here is that,
I like to put the scan technique at the beginning of
the Nmap scan. I'll run this.
[NOISE] There it is.
I'll clear the screen.
[NOISE] I'll do another one just to drive it home.
[NOISE] Do a TCP [NOISE] scan.
[NOISE] Make it fast,
meaning that it's going to scan the a
100 most popular ports,
We'll go through all the port scanning techniques
in the next lesson.
[NOISE] I'll output it to XML this time.
[NOISE] Again, the main point here is that,
I'm putting the scan technique
right at the beginning of my scan.
It's not necessary, but it's really helpful and it
sets you up for success in your scans.
[NOISE] Since all the other stuff
afterwards depends on your scan technique.
Also, notice here that the TCP connect scan is
a lot slower than the default SYN scan,
it took 23 seconds.
I'll clear the screen again.
[NOISE] Now, I want to just prove to you
that the Nmap SYN scan is the default.
I'll do a regular Nmap scan
that IP address with no scan techniques specified.
Hit enter. There's the results,
>> 979 filtered ports.
>> There's a latency, host is up,
MAC address, and it took 5.45 seconds.
That was just a simple Nmap, and then the target.
Now modify that and we'll do nmap-sS,
which is a SYN scan, [NOISE] hit enter.
The results of this scan should basically be the same.
It took 5.62 seconds, and you can see that there's
979 filtered ports just like
the other scan we did without
specifying the scan technique.
[NOISE] Clear the screen.
Now, I want to show you basically that
a TCP connect scan is slower than an Nmap SYN scan.
If you remember, the SYN scan that we
just ran took 5.45 seconds,
so I'll do nmap-sT over the same host.
[NOISE] It's slow enough
that I might actually cut some of it.
There you go. That was way slower than a SYN scan.
My point there is that,
the SYN scan is the default.
But if your user does not have raw-packet privileges,
if you don't have a privileged user,
or you're not running it as an administrator,
the TCP scan is
a default scan technique,
>> and so it's just a lot slower.
>> The results are basically the same,
but it just took a lot longer to get to those results.
You can see up here that I'm running
>> my command prompt as
>> an administrator whenever possible.
If I were you, I'd prefer
a TCP SYN scan over a full connect scan.
I'll clear the screen again.
I'm going to run a couple of UDP scans here.
They're slower than a SYN scan, and sometimes,
even much slower than a TCP scan.
Then the other point I want to drive home is that,
if you use the UDP scan,
which is a -sU,
TCP ports are not scanned by
default so it only scans UDP.
Let's do it, nmap-sU.
[NOISE] If it's slow,
I'll cut it from the video and just show
>> you the results.
>> It wasn't as slow as the TCP connect scan.
In this case, it was 17.27 seconds.
I'll run it against another host,
and that is my default gateway, which is a firewall.
[NOISE] I'll do a fast scan,
which will only scan a 100 ports.
[NOISE] Again, if this is too slow,
I'll cut the video, and just show you the results.
>> There's the results. It took 112 seconds,
so that was way slower than the previous scan,
which scanned 1,000 ports.
That just goes to show you that different UDP
scans against different devices
>> can respond differently.
>> The other thing I wanted to touch on
was the results here.
[NOISE] I blew through
the commands, but didn't really talk about the results.
You can see in the previous scan that we have a port
53, 123, 137, 389.
Those are the open ports from host 1.10.
Notice that they're all UDP.
In other words, when you do sU UDP scan technique,
you're only going to get UDP responses.
I'll clear the screen.
Since a UDP scan only gives you UDP results,
which makes sense, a lot
of times what you're going to wanna do is
combine UDP scan with a TCP scan.
We'll do a nmap -sU for UDP,
sS, I'll do a fast scan, hit "Enter".
That was pretty fast,
but you can see in the results I have got
TCP and UDP responses open ports.
I did do a fast, so it was only 100 ports.
It would have been a lot slower if I did
the standard 1,000 and left
that dash capital F out. I'll do another one.
We'll do a nmap,
first I'll clear the screen.
I'll a nmap -sU sS.
I don't want you to get to hung up on this,
but basically here,
I chose ports 1 through 1,024,
so this will scan UDP ports, and
TCP ports of 1 through 1,024 of this host, this target.
It took 10.13 seconds. That was pretty fast.
You can see all the results there.
I got all the way up to port 389 and UDP.
Now I'm going to show you an IP protocol scan.
This is really good, because it can inform you of
protocols worth further investigation.
Some operating systems that are non RFC
compliant won't respond correctly though,
so just because it doesn't show open,
doesn't mean you shouldn't run
additional in different types of scans against it.
I'll show you what I mean in a second.
Do it nmap, the scan technique is sO.
I'll run the scan as it is,
>> and it might be really slow,
>> so if it is, I'll cut the video,
>> and show you the results.
>> In fact, I think that the scan is
so slow that I might stop
it and show you again how you can speed up the scan,
especially if it's a device that's
>> on your local network.
>> I'm already tired of waiting for that,
so I hit "Control C" to stop
it and we'll do the same thing,
but I'm going to put timing of T5, which is insane.
Don't do this at work or school because it's
definitely going to hit an IDS if there is one.
That was a lot faster, six-and-half seconds.
If I were to let that other scan run,
it probably to take in I don't know,
maybe more than a minute to run.
The main thing I want to show you here
is that protocol 1,
which is ICMP, is open.
Protocols 6, which is TCP,
is open, and so that gives you really good information.
If I run a ping against that same device,
which is 192.168.1.254,
it's very possible that I'll get a response since ICMP
was open, and I did.
Also TCP shows to be open,
so means that it'll probably respond with a lot of
good information with an sS or a SYN scan
and see all the open ports running the SYN scan.
I'm going to do another IP protocols
scan against the different host.
Still 1.1, make it insane.
Again on this one we see ICMP and TCP open.
I'll do one more. We'll do it against 1.10.
This is an example of maybe some non-RFC compliance.
This is my internal Windows Server at 1.10,
and it is only showing ICMP to be open.
There's no other responses even
>> though we know that there
>> was responses and open ports with the SYN scan.
That's the end of our scan techniques lab.
Play around with the scans,
and if you can install Wireshark on
your scanning station and/or
your target and look at the packets.
Thank you so much, and I'll see you in the next one.
We walked through all of the main scan techniques
used in Nmap,
which are the SYN scan,
the TCP connect scan, UDP scans,
a combination of SYN, and UDP scans,
and we finish with several IP protocol scans.
I showed you why I like to put
the scan technique at the beginning
>> of my Nmap statement.
>> I talked to you about the speed, and
reliability of the results of the various scans.
Thank you so much for going through
this lesson with me and I'll see you
>> in the next lesson.