2007
A HACKING ODYSSEY PART 2:
NETWORK SCANNING & NMAP CONTINUED...
1) TCP
Connect –sT
This is the ‘scan by the rules’ option and will try to establish a full
and RFC compliant TCP connection to the remote host on the necessary
port. If the connection is successful then the port is reported as
being open. Although this is the most reliable scan type it is also the
most risky for a would-be attacker as the connection will be recorded
by the remote system due to it being a complete connection.
The syntax for this would be: nmap –sT 80.80.80.80. (obviously
substitute 80.80.80.80 for the IP address you want to scan)
2) TCP SYN scan -sS
The SYN scan is a little stealthier than the Connect scan as it
does not establish a full TCP connection. Instead of completing the
full TCP three-way handshake it will only go through half of it.
If you have read the above paper I linked to you will understand the
three-way TCP handshake:
SYN
SYN-ACK
ACK
The initiating host sends a packet marked with a SYN flag, next the
receiving host will respond with a SYN-ACK and finally to complete the
three-way handshake the initiating host will send an ACK packet. (This
ACK is then flagged in all subsequent packets for that connection –
remember this for later)
In plain speak the SYN packet saying ‘I have some data for you, do
you want it?’ to with the receiving station will send a SYN-ACK which
means ‘Yes I do, please send it’ and the initiating host responds with
the ACK which means ‘OK, here it comes’.
Now if we send the initial SYN packet and the remote host responds
with the SYN-ACK packet as it should BUT we do not send the expected
ACK packet, then we have not completed a valid connection. If we send a
FIN packet, which tells the remote host to tear down any connection it
may have, and then our connection attempt may not get logged due to the
connection being terminated before it was complete.
The fact that the remote host responded with a SYN-ACK on the port
we sent the SYN packet to is enough to tell us that there is a service
listening on that port and that is all we need to find out…
Some modern firewalls and routers will recognise this pattern of
packets (SYN, SYN-ACK, FIN) as a SYN scan though and may still log it.
The syntax for a TCP SYN scan is: nmap –sS 80.80.80.80
3)TCP ACK scan -sA
Following on from the packets we have sent and received so far, it
makes sense to try and send an ACK packet and see what we get. This is
where we start to break the rules of TCP connections. So far we have
complied with the RFC rules that dictate a valid TCP connection starts
with a SYN, then has a SYN-ACK and then has an ACK (which we bent a
little on the last scan by not sending a final ACK but the connection
was still initiated by the book)
By sending an ACK packet first we hope to get past any packet filters
that may be filtering our normal SYN/SYN-ACK packets.
Some older non-stateful packet filters base their decision on what
packets to allow and what to drop solely on the TCP control bit (the
SYN/ACK etc). If you were on an internal LAN that allowed all outgoing
traffic but denied all inbound traffic you would not be able to do
anything on the Internet as nothing would reach you, i.e. when you
wanted to view a web page the data would not get to you as your packet
filter would be blocking it all..
To get around this problem non-stateful packet filters such as a
border router or a low end firewall will look at the TCP control bit
and see if it is a SYN or an ACK; if it is a SYN then it must be
someone trying to originate a connection from the Internet, hence it
will drop the packet. However if the ACK bit is set, then by the RFC
rules it must belong to a connection that is already established, and
since it won’t let SYN packets in, only out, the connection must have
been established by an internal host therefore it will allow the packet
through.
However there is a slight difference with this type of scan – our
first two scans (TCP Connect and SYN) will determine if a port is open
by the response it receives from the remote host. If a SYN-ACK comes
back the port obviously is open and replying to the SYN packet as
normal, however when a SYN packet is destined to a port that is closed
the remote host will send a RST (Reset) packet back. Nmap will
determine the port state by these responses and show you the port as
open or closed accordingly.
If you send a packet that does not comply with the RFC rules (such
as an ACK packet that does not follow a SYN, SYN-ACK) then it will
respond with a RST packet and reset the connection.
Can anyone see where we are going to run into trouble here? If we
send a TCP ACK packet to a remote host, as it does not comply with the
rules we will get a RST packet back…..but we have just said that if a
port is closed a RST packet will also be sent back…..so no matter if
the port is open or closed the remote host will always send a RST
packet back to an ACK scan probe……….what use is this ACK scan then?
The ACK scan is used to test non-stateful packet filtering rules.
So say a border router has been configured to block all packets to
ports 100-200 but to allow them on port 80, further to this established
connections are allowed on all ports over 1024.
When we scan this with an ACK scan the packet filtering device will
drop all packets destined to ports 100 – 200 as this is what it has
been told to do – so we will either get no response or an ICMP
Destination Unreachable response back, either way Nmap will know the
probe failed. When it gets to port 80 the packet filter will let the
traffic through and the host on the other side of the packet filter
will send a RST packet because as we know an ACK packet is not a valid
way to start a TCP connection – if a RST packet comes back Nmap knows
the packet filter must have allowed the packet through (otherwise
either an ICMP unreachable or nothing at all would have come back) and
will mark it as UNfiltered. When it gets to port 1024 and over as the
packet filter has been told to allow established connections through
(packets with the ACK flag) all of our probes will be allowed to
traverse the packet filter and we will get back a load of RST packets –
therefore Nmap will flag the ports as UNfiltered.
Going off this output we will be able to determine that port 80 and
all ports over 1024 will accept incoming packets that are part of a
valid connection.
This type of scan does not actually tell us if a port is open or
closed on the remote host; it only tells us if the packet filter device
allowed the packet through or dropped them, as even if there was a Web
Server running on the host behind the packet filter, it will still send
a RST packet back when a probe comes to port 80……likewise if there was
no Web Server running then a RST packet will still come back.
The theory of the ACK scan can be quite confusing if you are new to
TCP connections and packet filters but just remember that it will only
tell us if a packet filter will allow the packets into the network, it
will not tell us if the port is actually open on the remote host.
The syntax for the ACK scan is: nmap –sA 80.80.80.80
The output will be something similar to the following:
| Code: |
PORT STATE SERVICE 53/tcp UNfiltered domain 80/tcp UNfiltered http 443/tcp UNfiltered https 1025/tcp UNfiltered NFS-or-IIS 1026/tcp UNfiltered LSA-or-nterm 1027/tcp UNfiltered IIS 1029/tcp UNfiltered ms-lsa 1030/tcp UNfiltered iad1 1031/tcp UNfiltered iad2 1032/tcp UNfiltered iad3 1033/tcp UNfiltered netinfo 1040/tcp UNfiltered netsaint |
If there is no mention of the port then it is
deemed to be blocked by the packet filtering device, if it says
UNFiltered then obviously the packet filter let the ACK packet through.
Original Tutorial
by nokia for TheTAZZone-TAZForum
Originally posted on March 2nd, 2007 here
Do not use, republish, in whole or in part, without the consent of
the Author. TheTAZZone policy is that Authors retain the rights to the
work they submit and/or post...we do not sell, publish, transmit, or
have the right to give permission for such...TheTAZZone merely retains
the right to use, retain, and publish submitted work within it's
Network.