>> We're going to dive into it
>> in a little bit more detail.
>> First, we'll do a filter with ip.addr=.
Basically, what I'm doing with
this filter is I'm showing all traffic
that is coming from or to 191.681.167.
That's great, but the problem is that I'm
remote desktopped into this machine.
It's going to show me, as you can see here,
some UDP traffic that I'm not really interested
in and to port 3389,
which I'm not interested in
because the main point is to show
you what the Nmap scan looks like.
I'm going to add to this filter a little
bit more and we'll do.
I've added where
IP address is 1.167,
and which requires two ampersands,
ip.protocol or ip.protol is
not equal to UDP because I'm
not interested in UDP traffic.
Hit "Enter". Down here at the bottom,
you can see that now it's only displaying
2,524 packets, that's good.
We've loaded it only to TCP traffic,
as you can see under the protocol column.
It's only traffic related to 1.167, and of course,
it's going to grab the target machine too,
>> which is 1.10.
>> Now, I want to filter a little bit more.
As I said, we will run a default Nmap scan,
which is a SYN scan.
As you learned in the last lesson about TCP flags,
we'll filter a little bit more doing
a TCP flags syn equals,
with two equal signs and a one.
Now if you look at the bottom,
it's displaying 1,044 packets essentially.
This really has filtered it down to
the stuff that we're most interested in.
You see the source is our scanning station.
Destination is the target host,
and in cases where the target host responded,
you can see that
the destination and the source have flipped.
Anyway, the main thing I want to show you
here is if you click on
that raw packet in
the filter and you
go down here to transmission control protocol,
TCP, you can see the source port,
destination port,
and if I scroll down a little bit further,
you see where the flags are set.
You can see right out here to the right,
it shows a SYN flag,
and right here,
you see all of
the flags that you can set in a TCP packet.
The SYN flag is set to a 1.
That's pretty much all I wanted to show you
in that particular scan.
Now, we're going to set up a different scan,
I'll go ahead and close Wireshark actually.
I want to save the scan,
minimize the target host,
clear the screen, and
actually, I'm going to go back to
the target host and fire up Wireshark again,
and go ahead and start the capture.
The last scan we did a TCP SYN scan,
this scan, we're going to run a UDP scan,
so I'll do Nmap- sU-p for the ports,
and again, you don't have to remember all this stuff.
I'm going to show you a lot more detail about it later.
These are some just common UDP ports that
are generally open and available on a 2012 R2 server,
especially if they're a domain controller,
and IP address is 192.168.1.10.
That scan, well,
it didn't take very long to complete,
so we'll go back to our target host.
I'll stop the scan or I'll stop the capture.
We'll do another display filter.
Again, we'll do a ip.addr
equals 167 for the scanning station,
capturing a lot of our remote desktop packets.
I'll add to that or do an ip protocol.
This time, we're going to switch it up
and make it only UDP traffic,
and you can see that it's now only
displaying 294 of those packets.
I'm going to add to that and do a UDP.
What I've done here is
UDP destination port does not equal 3,389,
because 3,389 is the port that RDP talks on,
or terminal services or remote desktop or Windows VDI,
whatever you want to call it.
>> Okay, so that limited it to 186 packets,
but you can see that it's still
showing the source port
of 3389, so we want to get rid of that too.
We'll do a UDP source port does not equal 3389.
That cleared out all of the source and destination
of port 3389, UDP.
What we're left with here is
only 19 packets and that is of our UDP scan.
You can see the results of that.
I'll go ahead and choose one of these.
You can double-click on it to open it up
>> if you want to.
>> There's the scan, destination port 138.
In this case, we see that there is
a response to port 138 UDP.
My main point was I wanted to show you how to filter
out unnecessary UDP traffic,
especially in this case,
Windows Remote Desktop,
and show you the results of a UDP scan and Nmap.
I'm actually going to go ahead
>> and close Wireshark again.
>> You actually can clear out the results,
but just for continuity sake,
I'll close it out.
All right, so we'll fire up Wireshark again.
While that's starting, I'll minimize the target host.
On my Nmap scanning station,
I'll clear the screen.
This is the last scan that I wanted to
show you and maybe the most interesting,
and that is Nmap.
Well, first I got to make sure I started the capture.
Oh, I didn't, so
I'm going to fire up the capture again.
We'll do Nmap -sX.
That is an Nmap xmas scan
which sets the push,
the TCP fin,
the TCP push and urgent flags.
We'll do it against the target.
That's done.
Open back up the target.
I'll stop the capture.
All right, so now we're going to filter
out those results.
I'll show you what it looks like from
a protocol analyzer capture standpoint.
All right, so we'll start with the same filter
that we started with last time and that is ip.addr
equals 192.168.1.167 which is
the scanning station that limited it
down to 2484 packets.
Then we'll add the
TCP protocol equals ip.
Ip proto equals TCP.
Dropped it down to 2244 packets.
We want to look at TCP flags.
fin equals 1,
and TCP flags push equals 1,
and TCP flags urgent equals one.
Now we're dropped down to 1000 packets
and you can see the source is 1.167, destination 1.10.
Out here you can see that the fin push and
urge flags are set in the TCP header.
Just click on one of them.
Again, down here at the bottom,
I'll click on Transmission Control Protocol,
shows the source and destination ports.
I'm going to go down here to the flags.
You can see that the urgent is set,
the push is set, and the fin is set.
For now, that's really all I wanted to show you.
The point is that you saw how fast that happened.
You can see how Wireshark comes in really
handy grabbing and evaluating
packets as they're sent and received on the wire.
I really wanted to drive home what we talked about in
the TCP/IP section in the previous lesson,
that Nmap really does
crafts packets and put them on
the wire against target hosts.
If you're using a tool like Wireshark,
you can evaluate the results of
those scans in great detail.
This is just a primer if you're from the UK.
I hope that you decide that Wireshark is
worthwhile and you give it
a shot and delve into much more detail than this.
Thanks so much for watching this,
and I look forward to seeing you in the next video.
In this lesson, we talked about what Wireshark
is and a little about its history and use.
Next, we talked about why we,
as IT professionals, should use it.
Then we discussed why you should consider
playing around with Wireshark alongside Nmap.
Finally, we did a lab on just that.
Thanks so much for going through this lesson with
me and I'll see you again in the next one.