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

How Networks and Network Attacks Work

To attack a network there is a need to understand fully, the rules and protocols that a network follows.
Once you have a good understanding of these, you can start to understand how various attacks work.

When the time comes that you know how these attacks work, then and only then, can you go about securing it, with a confident
knowledge that you know what it is you are defending against.

The aim of this paper is to help explain how a network operates and how various attacks work.

———————————————————————————————————————–

For a network to operate effectively, there is a requirement for a set of rules that everything on that network must follow.

It must have its own language that everything on it understands and it must have it own way of transmitting things in this
language to other parts of its network. However as there are many networks in many different countries this standard needs to
be a universal one, to allow networks to talk to other networks across the world.

If someone from England was to phone up someone in Russia the chances are they wouldn’t be able to communicate too well.
But if a network were to send a data packet to a network in Russia, it would be received and processed in the correct way.

This is because all networks follow protocols defined by what is known as the Open Systems Interconnection model (OSI)

The OSI Model:

The OSI model provide a set of rules and protocols that enable any network following them to talk to any other network that
also follows them.

The rules that make up the OSI are arranged into seven different layers that are all interconnected with each other.

These are:

1) Physical Layer

2) Data Link Layer

3) Network Layer

4) Transport Layer

5) Session Layer

6) Presentation Layer

7) Application Layer

I’ve always found it easier to look on these as different stages a data packet must pass through, at each stage something
is added to the packet and when it is received the same thing is taken away from it by the corresponding stage in the other
network

Physical Layer:

As its name suggests this is the physical connection between two pieces of hardware. So we are talking about the actual Ethernet cable and Network Interface Card (NIC) – hubs are also considered layer one devices. Its major function is to
communicate raw bit streams (The Ones and Zeros). It is responsible for the activation and deactivation of these bit stream
communications. It is also responsible for the defining of the actual cable attachments to the NIC’s and how they work.
This is the lowest layer.

Data Link:

This layer is what deals with the transfer of the data between two points on the network. If the Physical layer
is what is used to pass the raw bits, this is what actually sends them on their way. It also provides error and flow control
of the data packets that are sent and received. MAC addressing is found here – layer 2 switches are also found here – funnily enough. (A MAC address is commonly called a Layer 2 address due to where is sits in the OSI model)

Network Layer:

I will go into more depth on this later on. This layer provides the addressing and routing of the data and acts as a
kind of middle ground between the upper layers and the lower layers.

Transport Layers:

Again this will be explained in more detail later. This is where TCP comes into the process by providing a reliable
and stable method of passing the data packet.

Session Layer:

This is what actually establishes the connections between network applications and then maintains that connection. It also keeps the sessions separate. (A session loosely refers to a connection, so if you are viewing a web page via IE and also sending an email via Outlook then there will be two separate sessions. This layer will ensure data from one session will not end up in the other session.)

Presentation Layer:

This is what translates the data provided by the application in use, into a format that the rest of the
OSI model understands and can work with and vice versa when the data is received, it translates it back into a language
for the application to work with. So to go back to our web page an email example, data is sent in binary over a network, however, if this was displayed in IE and Outlook in this format you would be pretty confused, so something needs to translate the data into an email or a web page and pass it up to the correct application. This layer also handles encryption
and compression.

Application Layer:

This is used for applications that can support and use network services such as, DNS, FTP, TELNET, SMTP
and NetBIOS type applications

So when you send a data packet it starts at the application layer, then the presentation layer wraps its bit of information
around the packet, then the session layer does the same and so on until the packet reaches the Physical layer where it
is passed to where ever it needs to go.

This whole process is known as Encapsulation.

That’s the seven layers of the OSI model.

Now that we know about the methods used to pass data, lets talk about what it actually is that gets passed around.

When information is getting passed around the network it is transmitted in small chunk of data called a Packet.( In truth the terminology changes depending on where in the OSI model the data is – at layers 7, 6, 5 and 4 it is simply called Data, at layer 3 it is called a Packet, at layer 2 it is called a Frame and then at layer one it is referred to a bits (binary bits that is). To avoid confusion data in transit is generically called a Datagram or a Packet.

As the packet passes through each layer small bits of data are added to it or taken away from it depending on if the
packet is being transmitted or received.

A data packet has both a body and a header. The Body obviously contains the message that is being passed, whilst the
header contains things like: The Source IP address, the destination IP address, the total data length, what protocols
are being used, checksum information. See here for more info on headers:

http://www.networksorcery.com/enp/protocol/ip.htm

Network Attacks:

To understand how most network attacks operate it is necessary to go into more detail about some of the layers used.

Network layer:

The rules that govern this layer to ensure that the addressing is correct and efficient is what’s called Internet Protocol (IP)

Everything That is connected to the internet has an IP address. An IP address is made up of four bytes that can be no
greater than 255. E.g. 100.100.100.100.

They can be no bigger that 255 as this is the highest number that binary goes to in one byte and all numbers are converted to binary as far as computers are concerned.

128 —- 64—- 32—- 16—- 8—- 4—- 2—- 1
————————————————————-
–1——- 1—– 1—– 1—– 1—– 1—- 1—- 1

This number 11111111 would be the highest number in binary for one byte as 1 byte long (8 bits make a byte, so eight 1’s make the byte)

If you add the numbers above the ones up, you will see it comes to 255

128 +64 + 32 + 16 + 8 + 4 + 2 + 1 = 255

128 —- 64—- 32—- 16—- 8—- 4—- 2—- 1
————————————————————-
–0——- 0—– 0—– 0—– 0—– 0—- 0—- 1

This would equal the number 1. If there is a zero under the number it is discounted, only where there is a 1 is the value
added.

128 —- 64—- 32—- 16—- 8—- 4—- 2—- 1
————————————————————-
–0——- 0—– 0—– 0—– 1—– 1—- 1—- 1

So this would equal 15. 8 + 4 + 2 + 1 = 15

A bit off topic there but that is how binary works; hence that is how an IP address is looked at by your computer.
If you need a number bigger that 255 that is where hex comes in. Hex will be explained later when we talk about MAC addresses

Anyway, in the network layer, both IP packets and Internet Control Messaging Protocol (ICMP) packets exist.

IP packets are used for the actual sending of data, whilst the ICMP packets are there for diagnostic and messaging/notification purposes.
If there is a problem with the delivery or receipt of an IP packet, an ICMP packet can be sent to tell the other system that
there has been a problem.

ICMP can also be used to test the connectivity of something on the network in the form of an Echo Request commonly known as
a Ping. This is a quick and easy way to test if a host is up and running and how latent the connection is between you.
If you send an Echo Request get an Echo Reply the host has to be alive and reachable. If you send an Echo request and if you don’t get anything back then it generally (but not always) means the host is down. Unlike TCP there doesn’t have to
be an established connection to allow ICMP packets to transmit, so systems can be configured to ignore ICMP packets
as a security measure.

The final thing to mention on this topic is IP fragmentation.

Most networks have a limit on the size of IP packet that can be transmitted, so the network layer can break the packet down

A normal packet may look like this:

______________________
| Header | DATA DATA DATA |
———————————–

This may be too big to be transmitted, so the network layer will break it down like so:

______________
| Header | Data 1 |
——– ————–

______________
| Header | Data 2 |
——– ————–

______________
| Header | Data 3 |
——– ————–

It is a simplified explanation of it as in real life Offsets are used instead of 1 2 and 3.
To reconstruct the packet at the receiving station the network layer will put them back in order 1,2 and 3 and
pass it on up to the Transport Layer.

Which, strangely enough, brings us nicely on to the transport layer.

The Transport Layer:

The two major set of rules in this layer are the TCP (Transport Control Protocol) and UDP (User Datagram Protocol) protocols

Most services on a network and on the internet will use the TCP protocol, these include things such as; HTTP, FTP, SMTP.
Although each one of these is a protocol in its own right, to actually transfer the data it is being asked to, it will use TCP.

The reason for this is because TCP provides a very reliable, two-way connection between hosts on a network or Internet.

TCP will ensure that all the data is received and in the correct order, if packets are missing or corrupted
it will hold on to these packets until they have been re-sent and only then will it pass it up to the next layer.

To be able to do all this TCP uses a system known as flags.

There are 6 flags in total, they are:

URG………………..Urgent………………..Used for priority data

ACK………………..Acknowledgment….Acknowledges a connection and is usually turned on

PSH………………..Push……………………Tell the recipient to push the data through rather than
buffer it

RST………………..Reset……………………Resets the connection

SYN………………..Synchronize…………..Synchronizes sequence numbers at the beginning of the
connection (REMEMBER THIS)

FIN………………..Finish…………………….Closes a connection

What makes TCP such a reliable connection is that, unlike UDP it establishes a connection before sending the data packet.
It does this by way of a three-way handshake using the flag described above.

Say we have computer ‘A’ and ‘B’. ‘A’ wants to send something to ‘B’, here is what happens:

First,’A', will send a packet with the SYN flag turned on to ‘B’

‘B’ will then send a packet back with the SYN and ACK flags turned on

Then ‘A’ will send another packet back with just the ACK flag turned on.

(After this has been completed every packet will have the ACK flag turned on.)

This is basically computer ‘A’ saying to ‘B’, “Hi, I have a message for you, do you want it?”
Then ‘B’ says ” OK, im ready send it”
Then ‘A’ says” OK, here it comes”

There is a little bit more to it than that which we will look at next.

The reason that the packets had the SYN flag turned on was to enable the two machines to Synchronize sequence numbers.

Sequence Numbers:

Sequence numbers are used to ensure that the packets arrive in the correct order and to determine if any packets have gone missing somewhere along the line. This is what makes TCP so good. They also allow data from an established and authenticated sessoon to be accepted.

The First SYN packet that is sent to open a connection, will look like this:

SYN Packet
Syn = On
Ack = Off
Seq#000001
Ack# 0

Notice the Sequence number (Seq#) is 000001 and the Acknowledgment Number (Ack#) is 0

So this arrives at ‘B’ and ‘B’ now send a SYN/ACK Packet back to ‘A’, so called because both the SYN flag and the ACK flag will be turned on.

SYN/ACK Packet
Syn = On
Ack = On
Seq#111111
Ack# 000002

Now, this bit can get a bit confusing.

The original sequence number from ‘A’ now becomes ‘B’s Acknowledgment number (Ack#) as it is acknowledging the data sent, it will also increment it accordingly.

Computer ‘A’ knows that he sent a packet with a sequence number of 000001 to ‘B’, so now when the next packet is received from ‘B’ he will be expecting it to have and Ack# of 000002 – he gets this as expected and knows that it is authentic and from B. Also he now has the sequence number ‘B’ is using – 111111, so the next packet that he sends to ‘B’ he knows that he needs to increment it and place this in the ack# field.

So the third and last part of the handshake will be like this:

ACK Packet
Syn = Off
Ack = On
Seq# 00002
Ack# 111112

When ‘B’ sent back the second packet, he had increased it by 1- that now becomes ‘A’s sequence number for the third packet.

Now that both station are aware of each others sequence numbers the mail data that needs to be sent can safely be transmitted safe in the knowledge that error and missing packets will be detected.

I hope that wasn’t to confusing. It is important to understand the sequence number concept for when I move onto TCP/IP Hijacking later on.

The last layer (and what is used in our first attack) is the Data Link Layer.

The Data Link Layer

This is where Ethernet comes into the network layers. This layer provides a standard method of addressing for all Ethernet connected devices on the network. These address are commonly known a Media Access Control addresses or MAC addresses.

Every single Ethernet device is assigned a unique MAC address in the factory where it is made.

Usually the address is in Hex format, i.e. 00-30-BD-07-AC-32

Sometimes the address is also referred to as the Hardware address as it is unique to each piece of hardware.

The reason for this is so that any hardware on a network will have an address that will never change, unlike an IP address, which can change very regularly.

When a data packet is sent over Ethernet it will have in its header the source address and the destination address.

There is a special address that can be used with Ethernet to broadcast to all Ethernet devices on the network, this is all the 1’s in binary, 11111111 which as we now converts to 255 but remember IP address have 4 bytes in them so the broadcast address will be 255.255.255.255.

On the layer above (the network layer) the addressing system used there is IP but on this layer we use MAC addresses for local transmission. There is a requirement to know someones MAC address before we can send data to it providing the destination host is on the same LAN segment – if it is not then the requirement is to know the MAC address of the default gateway.

This is where a protocol know as the Address Resolution Protocol (ARP) comes into effect.

This protocol designs a table know as an ARP table to link MAC address to IP addresses and looks (in an edited version) something similar to this

192.168.2.2———————> 00-30-BD-07-CA-37
192.168.2.3———————> 00-20-CA-24-BD-12
192.168.2.4———————> 00-30-00-33-30-BD

and so on.

To establish this table ARP messages need to be sent around the network via the broadcast address 255.255.255.255.

There are two main ARP messages – ARP request and ARP reply.

When a packet comes to this layer, it looks at the header and to see what the destination IP address is. It will now send out an ARP request message saying, ” Who does the IP address 192.168.2.2 belong to?”
The computer that is on that network who has that IP address, will receive the ARP request via the broadcast IP, know it has got the IP that it is looking for and reply with an ARP reply message, saying “Yep I have the IP 192.168.2.2, here is my MAC address 00-30-BD-07-CA-37″

This will now get cached in the ARP table and next time a data packet comes down with the destination IP of 192.168.2.2, it will know the correct MAC address to send it to and send it using this straight away.

The ARP broadcast happens at very regular intervals to keep the table up to date.

If an ARP reply message comes in with a new MAC address for a certain IP address, it will overwrite it there and then (unless it has been marked as permanent) – Even if it didn’t send out an ARP request message…

Can anyone see the security flaw here and potential for a possible exploit? If not keep reading.

Switched/Unswitched Networks

On the data link layer also exists a method to distinguish between switched and unswitched networks.

The definition of an unswitched network is that – Every Ethernet packet will pass to every host on the network as a Hub will broadcast all traffic out of all ports except for the port the traffic was received on. All the hardware on this network is expected to only look at the destination address to see if it is meant for them or not. If it is, it will read the data part of the packet and the layer process will begin. If it is not meant for it, it should just ignore it.

Again, can anyone see the security flaw here?

If you set a computer on a network to promiscuous mode it will look at the data part of all packets whether it is addresses to it or not

This is what programs such as TCPDump and Ethereal/Wireshark utilize.

This method of attacking a network is known, as Sniffing and it can be a very useful way of gathering information such as Passwords, user names etc especially with services that don’t use encryption by default – Telnet, POP3 and FTP for example.

The security implications are quite obvious here and the way to fix them is to get a switched network.

Switched Networks:

The idea of a switched network is to ensure that only the packet addresses to a certain computer is sent to it.

This is done by the switch knowing what MAC address is plugged into which port on the switch and only sending data addressed to it out on that port

So say the switch has 3 ports, three computers are plugged into it with three different MAC address, I will use 1 2 and 3 to represent the Mac’s here.

The switch receives a data packet addressed to the MAC address of 1.
(If it were an unswitched network it would now send this data packet out of all ports to all computers.)

But this switch knows that computer with the MAC address of 1 is plugged into port 2, so it will only send the data packet out of port 2.

(Technically the switch will initially flood the traffic out of all ports until it finds out which port the MAC address is on, and then from here on in it will only send it out of the relevant port – this is not too much of a concern though as the first packets destined for the host are likely to be ARP requests anyway – which are broadcast packets….)

Seems like a foolproof way to send data packets, doesn’t it? Well there is a way around it.

Spoofing:

So far the security measures have been concerned with the destination IP/MAC address, what they cant verify is if the source address is correct.

This type of spoofing is simply fooling the switch into thinking that a data packet has come from somewhere it didn’t – normally a device it trusts.

So if you can send a data packet out and make a switch think it has come from somewhere else, you have successfully spoofed its source address.

To spoof an address we need to let the network know that the address you are going to use, is alive and well on the network and let it know an IP and MAC address.

Where are these kept? Yep, the ARP table. You may recall me saying earlier that when an ARP reply arrives with a known IP address but a different MAC address all it will do is overwrite the old MAC address with the new one! Even if it has not sent out an ARP request broadcast..

This is called ARP poisoning.

Say we have two computers on a network, old faithful ‘A’ and ‘B’.

They will each have an ARP cache; ‘A’ will have ‘B’s IP address and Mac address and in return ‘B’ will have ‘A’s IP and MAC address.

Think back to the three-port switch, we will be the third computer on that switch.
For the sake of simplicity we will have the MAC addresses of 1,2 and 3 belonging to computers A, B and C respectively. So we will be C with the MAC of 3.

We will have used a program such as TCPDump to capture all the ARP messages that have been sent and we can know see the IP addresses and MAC addresses of ‘A’ and ‘B’. (Failing this, the results of a ping will add the MAC and IP address to your ARP table, providing you are on the same network)

What we now need to do now, is make ‘A’ think we are ‘B’ and also make ‘B’ think we are ‘A’.
So now matter what, the switch will send all the data packets to us.

So, we send an ARP reply out to ‘A’ saying that we are ‘B’ and have a MAC address of 3 (remember our actual MAC is 3, so the switch will send all packets out to us) So now any packets that ‘A’ wants to send to ‘B’, he will now address to the MAC of 3. (aka us) as per his ARP cache.

The beauty of this attack is that at this exact point of the attack ‘B’ can still send traffic as normal to all other hosts – all we are doing is making host ‘A’ address the packets to us instead of host ‘B’. The switch is not attacked or exploited in anyway – it carries on doing what it is meant to do and sends the packets to the MAC address host ‘A’ has addressed them too..It is a good idea to keep a constant stream of forged ARP replies running to host ‘A’ as if host ‘B’ was to send a packet to host ‘A’ then its ARP cache would be updated to reflect the true ARP information.

There are a few tools that will do this for us DSniff and Nemesis are two of the most common.

We still have an issue though in that the data that ‘A’ is sending to ‘B’ is not getting there as it is coming to us. We need to turn IP forwarding on to allow the data to reach ‘B’. Obviously this will only allow us to sniff half of the traffic – traffic from ‘A’ that is being sent to ‘B’ – host B still has the correct MAC address for host A so it will not be sent to us…

We now need to do the same thing to B and send him a fake ARP Reply informing him that host ‘A’ has the MAC address of 3. This will ensure we get the return traffic and as long as we have IP Forwarding enabled and have fired Ethereal/TCPDump up we will have a log of all traffic sent between the two hosts and neither of them will be aware that there is a ‘Man in the Middle’ sniffing their traffic.

We need to ensure the regular sending of the ARP replies to the two hosts to ensure that the relevant ARP caches always have our MAC address in them.

You can do this for every computer on the network should you so wish, as far as they are concerned they are sending a data packet addressed to 3, and the switch will duly oblige and send the data straight to you.

This site has a very good example of ARP poisoning:

http://www.oxid.it/downloads/apr-intro.swf

Imagine what you could do if one of the computers was a gateway for that sites Internet traffic?

Hijacking a TCP/IP Connection.

For this attack you will need to understand how the sequence numbers work, so if you didn’t understand it before, go back and re-read it!

For this to work it is essential the attacker is on the same network as the victim.

When a packet is received after a connection has been established, it has to have the correct sequence number, if the number has already been used the packet will be dropped. If it is higher than what was expected but still within the defined limits then it will be stored in case it was from a message that has been fragmented and may need to be put back together.

If the sending stations sequence number is not what the receiving station expected and vice versa, all data packets are not passed up through the layers and you have a form of denial of service. If this happens the connection will still remain established.

Here’s how this attack works:

We will use hosts ‘A’ and ‘B’ again for this.

We need to sniff all packets coming from the victim computer (’A') with a utility such as TCPDump.
From these sniffed packets we can get the sequence number that ‘A’ is up to.

Now we send a packet with the source address spoofed to make it looked like it came from ‘A’ to ‘B’ with the correct sequence number. (TCPDump again)

When ‘B’ receives this packet, believing it cam from ‘A’ he will respond to this data packet, after increasing the sequence number.

Now ‘A’ didn’t send the packet, we did, so when the packet from ‘B’ arrives with the wrong sequence number it will keep it for reconstruction purposes as the sequence number will be higher but to all intents and purposes he will ignore it.

But what will happen now, if ‘A’ sends a packet to ‘B’? His sequence number will be one that has already been used (by us) so ‘B’ will drop the packet. So no matter what ‘A’ sends now, it will always be ignored. And everything B sends to A will be stored for later use, as the sequence number will be too high.

But as we sent out the first packet that caused all this, we have the correct sequence number that ‘B’ is expecting, so we have in effect hijacked the connection because we can carry on talking to ‘B’ and whatever ‘A’ sends will be ignored! And we have caused a denial of service (DoS) between two computers on this network.

There is another similar method whereby you sniff a connection, spoof get the relevant sequence numbers, spoof the source address and send a packet with the RST (reset) flag turned on, when you send this you will reset the connection. Again causing a DoS state that can be hijacked as long as you have the correct sequence number.

I hope this has been an informative paper and helps people to understand network protocols and very basic attacks a bit more thoroughly.

Nokia.

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

Code: Select all

This paper is the work of The Master Jedi Pimpsor AKA thehorse13, who has kindly consented to it being hosted here on the TAZ.

NMAP v3.48 tutorial lesson 1 of ? rev 1.0 by TheHorse13

PREFACE
======================
I’d like to start by saying that I will be covering many of the basic functions along with examples and explanations why you would want to use the tool in each scenario. In addition, I will hit on several advanced features for those who are familiar with the tool but not to the point where advanced knowledge of the application is grasped.

I will be borrowing verbage (in some cases) from the developer because I feel that the developer has worded things in such ways that I cannot improve upon. By no means is this a cut & paste tutorial but I would like to make everyone aware that I will be borrowing info where it makes sense.

NMAP
=====================
NMAP is designed to allow system administrators and curious individuals to scan large networks to determine which hosts are up and what services they are offering. nmap supports a large number of scanning techniques such as: UDP, TCP connect(), TCP SYN (half open), ftp proxy (bounce attack), Reverse-ident, ICMP (ping sweep), FIN, ACK sweep, Xmas

Tree, SYN sweep, IP Protocol, and Null scan. See the Scan Types section for more details.

Nmap also offers a number of advanced features such as remote OS detection via TCP/IP fingerprinting, stealth scanning, dynamic delay and retransmission calculations, parallel scanning, detection of down hosts via parallel pings, decoy scanning, port filtering detection, direct (non-portmapper) RPC scanning, fragmentation scanning, and flexible target and port specification.

NMAP supported platforms
=====================
Linux, Microsoft Windows, FreeBSD, OpenBSD, Solaris, IRIX, Mac OS X, HP-UX, NetBSD, Sun OS,

Amiga. You’ll find RPMs, binaries and so on, thus, installation is very flexible.
You’ll find all installation details and downloads here:

http://www.insecure.org/nmap/nmap_download.html

NMAP OPTIONS
=====================
A simple nmap -h will reveal all of the supported switches. These will vary slightly on

older builds.

* -sS TCP SYN stealth port scan (default if privileged (root))
-sT TCP connect() port scan (default for unprivileged users)
* -sU UDP port scan
-sP ping scan (Find any reachable machines)
* -sF,-sX,-sN Stealth FIN, Xmas, or Null scan (experts only)
-sV Version scan probes open ports determining service & app names/versions
-sR/-I RPC/Identd scan (use with other scan types)
Some Common Options (none are required, most can be combined):
* -O Use TCP/IP fingerprinting to guess remote operating system
-p <range> ports to scan. Example range: ‘1-1024,1080,6666,31337′
-F Only scans ports listed in nmap-services
-v Verbose. Its use is recommended. Use twice for greater effect.
-P0 Don’t ping hosts (needed to scan

www.microsoft.com

and others)
* -Ddecoy_host1,decoy2[,...] Hide scan using many decoys
-6 scans via IPv6 rather than IPv4
-T <Paranoid|Sneaky|Polite|Normal|Aggressive|Insane> General timing policy
-n/-R Never do DNS resolution/Always resolve [default: sometimes resolve]
-oN/-oX/-oG <logfile> Output normal/XML/grepable scan logs to <logfile>
-iL <inputfile> Get targets from file; Use ‘-’ for stdin
* -S <your_IP>/-e <devicename> Specify source address or network interface
–interactive Go into interactive mode (then press h for help)
–win_help Windows-specific features

EXAMPLES oF BASIC SCANS
=====================

Example 1 (NOTE: You must have root priviledges to run the SYN stealth scan, which is the

-sS switch)

Let’s say that you want to know what ports are open on a host and you want to know what OS is running on the host. This can be done by typing the following NMAP command. (NOTE: the position of switches makes no difference. You can order switches any way you like.)

[root@locahost]#nmap -v -sS -O -p 1-65535 192.168.1.100

nmap – the command to run it
-v for verbose
-sS for SYN stealth scan
-p for ports you want to scan (I used all IANA ports)
-O OS detection
192.168.1.100 – the host

Here is the output from this command. Let’s take a closer look at what is returned in addition to what we have asked for.

Starting nmap 3.48 (

http://www.insecure.org/nmap

) at 2003-10-25 19:20 Eastern Daylight

Time
Host IS~TOWER (192.168.1.101) appears to be up … good.
Initiating SYN Stealth Scan against IS~TOWER (192.168.1.101) at 19:20
Adding open port 445/tcp
Adding open port 5800/tcp
Adding open port 21/tcp
Adding open port 5900/tcp
Adding open port 1025/tcp
Adding open port 135/tcp
Adding open port 1027/tcp
Adding open port 139/tcp
The SYN Stealth Scan took 13 seconds to scan 65535 ports.
For OSScan assuming that port 21 is open and port 1 is closed and neither are firewalled
Interesting ports on IS~TOWER (192.168.1.101):
(The 65527 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
21/tcp open ftp
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
1025/tcp open NFS-or-IIS
1027/tcp open IIS
5800/tcp open vnc-http
5900/tcp open vnc
Device type: general purpose
Running: Microsoft Windows 95/98/ME|NT/2K/XP
OS details: Microsoft Windows Millennium Edition (Me), Windows 2000 Professional or Advanced

Server, or Windows XP
TCP Sequence Prediction: Class=random positive increments
Difficulty=8231 (Worthy challenge)
IPID Sequence Generation: Incremental

Nmap run completed — 1 IP address (1 host up) scanned in 14.851 seconds

The first thing you’ll notice is that NMAP will resolve the hostname of the box you scan if possible. In this case, the host, 192.168.1.101 is named “IS~TOWER”.
The next line we see is the type of scan we have performed. The switch -sS is a SYN Stealth scan and the duration of the scan, which is what we have done.
You may also notice that NMAP has posted what appears to be redundant information. This is intentional. The first section is the port scan where ports will appear in no particular order, the second is the service scan, where the ports are arranged in ascending order along with what NMAP feels is the associated service.
It also tells you that the other ports that you specified for scanning are closed, thus, they have been omitted. This is a good thing because you don’t need to see 65,535 closed port statements wiz down your screen.

Additionally, NMAP is telling you that it is making some assumptions while trying to identify the remote OS. Look closely at the output and you will see that it assumes that port 21 (FTP typically) is open and port 1 (TCP/UDP port service multiplexer) is closed and there is no firewall in place.

But what if port 21 is closed and there is a firewall in place?

NMAP will then select the first port you select as the port that it will assume is closed (example scan ports 400-500 it will assume 400 is closed) and it will pick the first open port it comes across as the open port used in OS identification.
Now, with a firewall in place, NMAP will not be able to properly fingerprint the OS (in most cases) so it will warn of this fact by stating that the OS identification will be less accurate and in some cases, if it cannot indentify the OS, it will output an NMAP “fingerprint” which we will examine very closely in later lessons.

The Device type field is attempting to tell you what the device is used for such as a router, etc but I have found this field less than accurate many times.

The OS indentifier field is the footprint match that NMAP has returned for the target machine. Notice that when a windows OS is identified that it gives you a number of possibilies and not an exact match. This is because the stack on these OSes respond the same way, thus it is difficult to pinpoint the exact MS OS in use. The OS Details line is the one to be concerned with when looking at your results, not “Running:”

The TCP Sequence prediction is run to see how each IP sequence number is handled during the connection (or how NMAP feels this happens). The theory being that if you can predict the sequence, you can poison the connection be injecting your own packets into the stream.
A good OS will always have random sequence numbers. NMAP also tells you what it feels the difficulty is in penetrating the box. The difficulty number will be accompanied with a small blurp which ranges from easy to good luck.

The last thing it tells you is how the IPID sequence generation is handled. Give the Nmap arguments -v -O” against a host and it should say “IPID Sequence Generation: whatever”. IPID classes Nmap understands include “incremental” (most machines), “duplicated IPID” (mostly stupid devices like printers), “Broken little-endian incremental” (Windows), “Randomized” (OpenBSD), and “Random positive increments”.

Well that is the end of lesson one which covers a basic scan and what the results mean. By no means is this supposed to be perfect so if you feel I missed something or failed to explain something with enough detail, please let me know. Also, add anything you like.

Next lesson will deal exclusively with scanning options and how to form the proper syntax for specific scans.

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

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

Code: Select all

This paper is the work of The Master Jedi Pimpsor AKA thehorse13, who has kindly consented to it being hosted here on the TAZ.

BEFORE WE BEGIN
==========================
The tutorial below is a prerequisite for this mini tutorial. It does have outdated information so I will give you the updated content now. Please read all the new content here all the info in the old tutorial. Life will be much easier for you.
http://tazforum.thetazzone.com/viewtopic.php?t=691

In the Getting The Software Section of the old tut…
==========================
Go to

www.nessus.org

and follow the instructions for downloading the installation script. This is done in place of using the FTP method mentioned in the tutorial.

For the NessusWX client, the windows front-end to the Nessus engine, go to

http://nessuswx.nessus.org

and download the windows binary. As of this writing 1.4.5b is the latest release.

In the Installation of Nessus Engine Section
==========================
Tennable has gone to a licensing model which means that at the end of the installation, it will ask you for a serial number that you must register to receive via e-mail.

Note that the SharUtils RPM must be installed before Nessus will compile properly. Do an rpm –qi sharutils before you attempt to install the engine to verify that you have the RPM installed.

Ignore step 3. The Nessus daemon is added in such a way that you can now enable/disable it from the service menu when you type setup at the command line. If at any time you want to fire up Nessus without enabling it to start at boot (it takes the service a long time to fire up because it loads the plugins when you start the process) simply go to /usr/local/sbin and type nessusd –D. This will start the process and load the plugins and will not load Nessus the next time you boot. Personally, this is how I do it as I don’t need to use Nessus continuously on my lab host.

Mini tut starts here:
==================================
Sometimes you may want to tweak or run nasls from the the command line. There are several ways you can go about doing this. We’re going to assume you simply want to run a single nasl.

/usr/local/lib/nessus/plugins is where my .nasl files are stored on the Nessus server. In most cases, this is where you will find them unless you used an RPM build of Nessus for installation. There are close to 8,000 plugins in this directory. If you “ls” this directory, be prepared to see a whole lot of stuff fly by. It’s not very practical. I typically use the W32 NessusWX GUI to find a plugin that I want to run/modify and then jump over to the Nessus server to run it at the command prompt. Please do not confuse what I’m about to demonstrate as a scheduling a Nessus job on the console.

[root@localhost]#nasl –h

nasl — Copyright (C) 2002 – 2004 Tenable Network Security

Usage : nasl [-vh] [-p] [ -t target ] [-T trace_file] [-SX] script_file …
-h : shows this help screen
-p : parse only – do not execute the script
-D : run the ‘description part’ only
-L : ‘lint’ the script (extended checks)
-t target : Execute the scripts against the target(s) host
-T file : Trace actions into the file (or ‘-’ for stderr)
-s : specifies that the script should be run with ’safe checks’ enabled
-v : shows the version number
-S : sign the script
-X : Run the script in ‘authenticated’ mode.

As you can see, there are just a hand full of options. Most are self explanatory.

We are going to do assume that you want to run the HALO server detection NASL. This is a very simple NASL used to find a HALO game server.

NOTE: Some NASLs have dependencies and may not fire properly when run individually. Keep this in mind when selecting individual NASLs for testing or modifying.

code:——————————————————————————–[root@localhost]#pico halo_detection.nasl
#
# Copyright (C) 2004 Tenable Network Security
#

if(description)
{
script_id(12117);
script_version (”$Revision: 1.1 $”);

name["english"] = “HALO Network Server Detection”;
script_name(english:name["english"]);

desc["english"] = ”
The remote host is running a version of HALO Network Server.
The Server is used to host Internet and Local Area Network (LAN)
games.

Solution: Ensure that this sort of network gaming is in alignment
with Corporate and Security Policies.

Risk Factor: Low”;

script_description(english:desc["english"]);
summary["english"] = “Detects HALO Tournament Server”;
script_summary(english:summary["english"]);
script_category(ACT_GATHER_INFO);

script_copyright(english:”This script is Copyright (C) 2004 Tenable Network Security”);

family["english"] = “General”;
script_family(english:family["english"]);
exit(0);
}

# start script
port = 2302;

sock = open_sock_udp(port);
if ( ! sock ) exit(0);

send (socket:sock, data:raw_string(0×5C, 0×73, 0×74, 0×61, 0×74, 0×75, 0×73, 0×5C) );

r = recv(socket:sock, length:512, timeout:3);

if ( ! r ) exit(0);

# OK, there are two modes…mode 1 is when the server is actively serving up a game
# in which case you’ll get a long verbose reply from the server
# in mode 2, the server is in IDLE state and is not actively serving a game
# in mode 2, the server will just send back a quick 5 byte error msg to client

# mode 1
if (egrep(string:r, pattern:”hostname.*gamever.*maxplayers”)) {
security_note(port);
}

# mode 2
if ( (strlen(r) == 5) && (ord(r[0]) == 0xFE) && (ord(r[0]) == 0xFE) ) security_note(port);
——————————————————————————–

For those familiar with PERL regular expressions, you’ll notice similarities in the NASL (Nessus Attack Scripting Language) language. Looking at this example we can see that it checks port 2302 and establishes a connection. Once connected it sends the string of data expecting a certain response. Within that response the script looks for static values seen in the mode 1 section (hostname, maxplayers, etc.) if the server is in use. In mode 2, if the server is sitting idle, the plugin looks for the error message via raw data strings and the value of 5.

When modifying NASLs to suit a custom need, you must change a few things. The first is the plugin ID. Typically when I modify a NASL, I change the Plugin ID to something in the 50,000 range. If you submit your NASL to Tennable and they publish it, they will assign it a plugin ID typically in the 10,000 – 19,000 range. Second, the name must obviously change so you don’t harm the original (the name field within the NASL and the actual file name). Next, change the script revision number. This is more for completeness rather than need. Make a note to the NASL that you modified it under the copyright section. DO NOT remove the original copyright. You can (and should) modify the plugin description to reflect what it does now. You can also edit the family the plugin belongs to so it can be used as a safe check, destructive test, etc.. All of these values are listed in the above NASL.

Now for some fun:
=========================
Let’s say that we have reports that someone is running a bunch of HALO gaming servers and an NMAP scan (or whatever scanner) shows that some hosts have something unusual running on port 5400 instead of the default halo port. Simply change the port values as such:

port = 2302;

should read

port = 5400;

and your nasl will now search for halo on port 5400. You can save your nasl as halo_detect_5400.nasl and you can now test it by typing the following on the Nessus server:

[root@localhost]#nasl –t 10.10.10.10 halo_detect_5400.nasl –T –

This tells Nessus to scan host 10.10.10.10 with your modified halo NASL and report the result to the screen. You can send the output to a file if you wish but this is a little quicker.

Now, let’s say that you like the results and want to use this NASL in the NessusWX W32 client. Two things must be done. The first is that you must restart the Nessus service so it reads your plugin for use. I typically HUP the service as such:

[root@localhost]#ps –ef | grep nessus

root 23875 1 0 04:29? 00:00:00 nessusd:waiting for incoming connections
[root@localhost]# kill –HUP 23875

The Nessus service will now restart (takes some time on older hosts) and your plugin will be ready to use.

On the NessusWX client, you must reconnect to the Nessus server once it returns to a normal state. You can search for your plugin using the description or expanding the tree where you identified the family. I simply search for the plugin ID I assigned it and enable it when I get the search results.

At this point you can configure the scan range within the NessusWX client that you wish to let your NASL loose on. Running a single NASL will be fast as all hell (usually) and your results can be seen and manipulated a number of ways.

I hope this mini tut gives you an idea of how to modify, run and include custom NASLs using the nasl command and the NessusWX client.

Any errors, comments, etc., please let me know.

–TH13

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

Code: Select all

This paper is the work of The Master Jedi Pimpsor AKA thehorse13, who has kindly consented to it being hosted here on the TAZ.

Nessus Installation on Red Hat Linux

BEFORE WE BEGIN
===============================
I understand that there are many ways to install and configure Nessus. This tutorial covers only one of them. This tutorial makes several assumptions:
1. You are competent with Windows, Linux and basic networking. If you don’t know how to use command line FTP for example, then this tutorial will be of no use to you.
2. You have 2 computers, one with a Windows and the other with Red Hat, both in good working order. It also assumes that you have at least one supported compiler such as GCC installed on your Red Hat Box.
3. This tutorial is written by me with no references or “borrowed” material. If something doesn’t work or something isn’t clear, yell at me because I am 100% responsible.

GETTING THE SOFTWARE
===============================
First, go to

http://nessuswx.nessus.org/archive/…4.4-install.exe

and download the NessusWX client on to your Windows box. The current version as of this writing is 1.4.4.

Now, on your Red Hat box, from the directory of your choice, ftp to ftp.nessus.org and login anonymously. Once there, path to /pub/nessus/nessus-2.0.7/nessus-installer/ and download nessus-installer.sh

INSTALLATION OF THE NESSUS ENGINE
===============================
Now that you have all of the software, it’s time to install. Let’s begin with the Nessus engine because it requires most of the work.

1. From the directory where you downloaded nessus-installer.sh, simply type: sh nessus-installer.sh. The Nessus installation script will tell you that you need root priviledges to complete the install, press ENTER to continue if you are logged in as root already.
2. Nessus will ask where you want it installed. /usr/local is the default so just hit ENTER when you see the prompt. At this point, Nessus will tell you that it is ready to compile. Hit ENTER and sit back while it compiles. It will take a little while. When it is finished, you’ll see a screen detailing the next steps. Hit ENTER.
3. Now, at this point you have to decide if you want Nessus to start up each time you boot your box or if you just want to start it when you feel like it. To start it when you feel like it, use /usr/local/sbin/nessusd –D. If you want to start it automatically when your box boots up, add /usr/local/sbin/nessusd –D & to /etc/rc.local.
4. Now, decide how you want to handle updating the plugins. You can do it each time the box boots by adding /user/local/sbin/nessus-update-plugins & to /etc/rc.local. You can also copy the nessus-update-plugins script to /etc/cron.daily and it will go out each day and grab the updates.
5. OK, we now have to generate a certificate so go to /usr/local/sbin/ and type nessus-mkcert. This will prompt you for a bunch of information that you would see when generating any SSL certificate. Answer all the questions.
6. Now you have to add a user by running nessus-adduser from /usr/local/sbin. When run, provide a login ID of your choice. When it asks for pass or cert, hit ENTER to accept pass as the auth method. When asked for a password, provide it one. Next you will see a blurb about user rules. Simply hit Ctrl – d and Nessus will verify your input. Type in “y” and Nessus will inform you that the user has been added.

Well now all you have to do is reboot the box to launch Nessus or you need to start the deamon manually as shown in step 3.

INSTALLATION OF NESSUSWX CLIENT
===============================
OK, now all you have to do is run the installer. On the first screen, click next to continue. Next click the checkbox if you agree to the license, then hit next to continue. The next screen shows the install path, click next to continue. Select Binaries Only, then click next. The next screen names the program group, hit next to continue. It now has all the info to begin installation. Hit next and it will begin. Once this is done, look for the eyeball icon on your desktop. Launch it. It will ask about a nessusdb and all you need to do is say yes to create it.

OK, now you need to configure a session:
1) Form the mune pulldowns, select COMMUNICATIONS, then CONNECT. Enter the IP address of your Nessus server then enter the username you created on the Nessus server. You need to use password authentication and it is your choice to save the password or not. Once you do that, hit CONNECT. Accept the certificate however you like (I always do perminant because I trust the source).
2) From the menu pulldowns, select SESSION then NEW.
3) This will open a window to enter your list of target hosts. Add your hosts in here.
4) Now, each tab has tons of options so I will hit on the key ones for now. Hit the portscan tab and enter the range 1-65535.
5) Hit the plug-ins tab and check “use session specific plugin set”, then hit the select plugins button, then select either all plug-ins (bad idea for a production box that you want to scan) or Non-DOS. Click OK.
6) Now, right click on your session (green book icon) and select EXECUTE.
7) On the next pop-up hit the EXECUTE button and you should see your scan underway.

At this point, you are golden. When the scan is done you can preview it or you can generate a report. I usually select HTML output.

In conclusion, I left out *tons* of options and configs but this tutorial is only intended to get you scanning. You’ll need to look into the docs to explore all this tool has to offer.

Happy scanning!

Oh yeah, if someone spots a mistake, let me know and I’ll fix the tut.

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

Code: Select all

This paper is the work of The Master Jedi Pimpsor AKA thehorse13, who has kindly consented to it being hosted here on the TAZ.

NMAP v3.48 tutorial lesson 5 of 5 rev 1.0 by TheHorse13

PREFACE ***PLEASE READ AND UNDERSTAND THIS*** (Will be repeated at the top of each lesson)
======================
I’d like to start by saying that I will be covering many of the basic functions along with examples and explanations why you would want to use the tool in each scenario. In addition, I will hit on several advanced features for those who are familiar with the tool but not to the point where advanced knowledge of the application is grasped.

***I will be borrowing verbage (in some cases)*** from the developer because I feel that the developer has worded things in such ways that I cannot improve upon. By no means is this a cut & paste tutorial but I would like to make everyone aware that I will be borrowing info where it makes sense.

NOTE: TheHorse13 takes no responsibility in regards to your use of the information presented in the NMAP tutorial series. If you get into trouble, then obviously you aren’t as 31337 as you thought.

Bold text – Command syntax
Underlined text – Important information

PREREQUISIT
======================
Please read the past four tutorials if you are new to NMAP. They are all in the Anti-Online tutorials forum.

IN THIS LESSON
=====================
You have seen basic, intermediate and advanced scanning techniques used thus far. You have also seen some of the footprints left behind by NMAP and how to avoid doing so. Building on this information, there will be times when you conduct scans with NMAP and the application will return something that looks like a giant pile of crypto babble. We will go over what this really is and what to do with the information. We will also use some other less used NMAP scans to quietly probe network devices for vulnerabilities as well as some logging features.

This is the final lesson in the NMAP series. I covered what I feel are useful features although there are others that I have not hit upon. As many of you know Fyoder is going to write a book on the application. That should tell you what this tool is capable of doing. I hope that this short series of tutorials have been helpful to both beginners and advanced users.

NMAP Fingerprints – What is This?
======================

From time to time, you will scan a particular host and you will receive output that looks like cryptobabble. Let’s look at an example.

[haxor@localhost]# NMAP -v -sV -O -p 1-1024 192.168.0.44

Starting nmap 3.48 (

http://www.insecure.org/nmap/

) at 2003-11-20 09:05 EST
Interesting ports on 192.168.0.44:
(The 1017 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE VERSION
21/tcp open ftp Microsoft ftpd 5.0
80/tcp open http Microsoft IIS webserver 5.0
135/tcp open msrpc Microsoft Windows msrpc
139/tcp open netbios-ssn
443/tcp open ssl Microsoft IIS SSL
445/tcp open microsoft-ds Microsoft Windows 2000 microsoft-ds
1024/tcp open kdm?
No exact OS matches for host (If you know what OS is running on it, see

http://www.insecure.org/cgi-bin/nmap-submit.cgi

).
TCP/IP fingerprint:
SInfo(V=3.48%P=i686-pc-linux-gnu%D=11/20%Time=3FBCCA2B%O=21%C=1)
TSeq(Class=RI%gcd=1%SI=3085%IPID=I%TS=0)
TSeq(Class=RI%gcd=1%SI=1DA1%IPID=I%TS=0)
TSeq(Class=RI%gcd=2%SI=16BB%IPID=I%TS=0)
T1(Resp=Y%DF=Y%W=FFFF%ACK=S++%Flags=AS%Ops=MNNT)
T2(Resp=Y%DF=N%W=1000%ACK=S%Flags=AR%Ops=WNMETL)
T2(Resp=Y%DF=N%W=400%ACK=S%Flags=AR%Ops=WNMETL)
T3(Resp=Y%DF=N%W=400%ACK=S++%Flags=UAPR%Ops=WNMETL
)
T3(Resp=Y%DF=N%W=1000%ACK=S++%Flags=UAPR%Ops=WNMET
L)
T3(Resp=Y%DF=N%W=800%ACK=S++%Flags=UAPR%Ops=WNMETL
)
T4(Resp=Y%DF=N%W=800%ACK=S%Flags=AR%Ops=WNMETL)
T4(Resp=Y%DF=N%W=C00%ACK=S%Flags=AR%Ops=WNMETL)
T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=N%W=400%ACK=S%Flags=AR%Ops=WNMETL)
T6(Resp=Y%DF=N%W=800%ACK=S%Flags=AR%Ops=WNMETL)
T6(Resp=Y%DF=N%W=1000%ACK=S%Flags=AR%Ops=WNMETL)
T7(Resp=Y%DF=N%W=800%ACK=S++%Flags=UAPR%Ops=WNMETL
)
T7(Resp=Y%DF=N%W=1000%ACK=S++%Flags=UAPR%Ops=WNMET
L)
PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPC
K=E%UCK=F%ULEN=134%DAT=E)

Nmap run completed — 1 IP address (1 host up) scanned in 23.524 seconds.

Hmmmm, what could this mess be? This mess is what NMAP uses to try and fingerprint the stack. You see, certain stack implementations respond differently when presented with an improper TCP flag, etc.. NMAP has a database of stack fingerprints which is based on RFCs for proper responses and also how specific proprietary stacks respond to the probes that NMAP makes when fingerprinting. What each of these lines represents is a tutorial by itself but if anyone is interested, here is a link that explains it:
http://www.insecure.org/nmap/nmap-f…ng-article.html

NOTE: To view the content of the NMAP stack fingerprints file, open it in a text editor of your choice. The locations are:
WIN32: %NMAP directory%nmap-os-fingerprints
*NIX: default install directory: /usr/local/share/nmap/nmap-os-fingerprints

Now then, as you can see, NMAP is having a small issue identifying a Windows box. I have included this example on purpose to reinforce the fact that the NMAP fingerprinting feature is *NOT* fool proof.

Now, if you know what kind of box you are hitting and NMAP does not recognize it, you can send the fingerprint to Fyodor (NMAP developer) and it will be added to the fingerprint file in future builds. If you want it right away, you can add it to the nmap-os-fingerprints file on your local machine. Just follow the format of the other entries and you are good to go. This method is also helpful if you don’t want others outside your organization to see how a specific device responds to NMAP fingerprinting. Developers and the like would most likely want to keep this information hush hush for as long as possible.One thing to note is that NMAP will overwrite the fingerprints file when you install a newer release, so keep that in mind if you choose to add entries locally.

Here is the link to submit NMAP fingerprints:

http://www.insecure.org/cgi-bin/nmap-submit.cgi

NOTE: Per the application developer, ¡§Be careful to not submit fingerprints generated when scanning through firewalls, NAT devices (on your end!) or load balancers without telling that in the Notes section.¡¨

NMAP LOGGING CAPABILITIES
============================

NMAP is capable of logging in several different formats. Personally, I use the human readable format but you do have the option of XML and grepable format. Without getting too deep into this, here are the appropriate switches for each logging method. They can be added anywhere in the NMAP command you issue.
-oN <logfilename> This logs the results of your scans in a normal
human readable form into the file you specify as an argument.

-oX <logfilename> This logs the results of your scans in XML form
into the file you specify as an argument.

-oG <logfilename> This logs the results of your scans in a grepable
form into the file you specify as an argument.

-oA <basefilename> This tells Nmap to log in ALL the major formats
(normal, grepable, and XML). You give a base for the filename, and the output files will be base.nmap, base.gnmap, and base.xml.

-oS <logfilename> thIs l0gz th3 r3suLtS of YouR ScanZ iN a s|<ipT
kiDd|3 f0rM iNto THe fiL3 U sPecfy 4s an arGuMEnT! U kAn gIv3 the 4rgument “-” (wItHOUt qUOteZ) to sh00t output iNT0 stDouT!@!!. Just a note that this option is more for fun than anything else. The developer has a sense of humor and it is pretty funny to add this switch just to see what the output looks like. ƒº

THE GRAND FINALE – AN NMAP SESSION USING A NUMBER OF ADVANCED SWITCHES
==================================================
=========

OK, let’s say that you are auditing a network because, of course, you wouldn’t be attacking one. The firewall admin says that they have a tight firewall and nothing can get around it. However, you notice a CHUBB institute certificate on his wall so already you know that he barely knows which shoe goes on the right foot. You setup shop outside the network and you begin to probe the network. Now, even though you know that one dumdum is working at the company, there could be smarter people lurking around so your paranoia will serve you well. The first thing we do is a port scan to determine if the firewall allows inbound DNS connections for whatever purpose (Zone transfers, etc.).

[haxor@localhost]# NMAP -v -sS -g 53 -p 53 66.99.104.198

Let’s look at the command. We specified s SYN scan with a source port of 53 (DNS) and a destination port of 53 on the host specified. Note that I didn’t try to hide my identity because this is an audit, not an attack. We could have easily used a decoy or zombie scan (covered in earlier tutorials). Now, a decent firewall will immediately dump this source routed traffic. It will examine the contents to determine if this is malicious traffic and typically black hole the traffic.

Let’s say that this turns up nothing. Hmmm, let’s try something else.

[haxor@localhost]# NMAP -v -sU -g 53 -p 53 66.99.104.198

Notice that we are now using the UDP scan switch here. Let’s say that again, we are shot down. Not to worry, there are other avenues. Let’s try this:

[haxor@localhost]# NMAP -v -sS -g 20 -p 23 66.99.104.198

You’ll notice that I now specified an FTP data channel source port. Success!! We will assume that the IP address we hit is a static NAT address which will dump us to a box that sits on the inside of the network. Static NATing to internal addresses is much more common than you may think. If the box is listening, we can *easily* begin to chip away at it and eventually gain access. If we are able to, then GAME OVER. We can safely download a rootkit and anything else we like to the host. We can even go as far as setting up a reverse telnet session using Netcat (but that’s another story). So we now know that the device being used to guard the perimeter of this network is vulnerable to source routed packets that seem to be coming from a legitimate FTP session. This is hole #1. Let’s continue.

OK, so here we are, and we now tell the admin that not only can we poke holes in his network, we now tell him that it will be very difficult if at all possible to see us do it. We tell him that he can watch the logs and we still will be able to sneak under the radar screen.

Let’s make some assumptions. First, let’s say you were doing some traffic analysis and you have a pretty good idea what normal traffic looks like. There are many ways to do this, but different tools are involved. Now, let’s say that all of our precision scans turned up nothing so we’re gonna have to scan the entire class C range that we know is registered to them (because we did a whois on the domain and got all kinds of juicy info). Now, we’re not going to scan the ENTIRE class C range in one sweep. This would be like driving a bus through a library while trying to sneak out. Let’s be a bit more clever. Again, we can use the zombie or decoy switches learned earlier but for this example, we’re going to leave them out.

[haxor@localhost]# NMAP -v -n -T Paranoid -data_length 64 –randomize_hosts -oN haxor -sV -p 1-65535 66.99.104.198-203

OK, what we’ve done here is tell NMAP to never do a reverse DNS lookup (-n) and use Paranoid scans ( -T Paranoid serializes scans and waits 5 minutes between scans before continuing to the next host in hopes of not triggering an IDS) and we specified a data length consistent with normal traffic (–data_length 64) and we want it to randomize hosts (–randomize_hosts) and we want it logged in human readable format (-oN)to haxor and we specified a service scan for the entire IANA range for the host range of 198-203.

WHEW!!! Now, go relax and have a nice glass of beer while NMAP writes a nice file with any available goodies for further review.

CONCLUSION
==================
I have covered quite a few commands and scenarios but there are many more that I have not. I could write a book on the many features NMAP has to offer (like it has a TCP dump type feature using the (-packet_trace switch). Like I mentioned, a book is coming out on its use. My tutorials are designed to give you a solid understanding of its use along with some very handy scan techniques. I hope you enjoyed the series.

I didn’t get a change to really clean up the formatting, so if something bothers you let me know. Also, if there is something you wanted covered but I didn’t hit on it, let me know and I will post a mini tut on the feature or technique.

–TH13

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

Code: Select all

This paper is the work of The Master Jedi Pimpsor AKA thehorse13, who has kindly consented to it being hosted here on the TAZ.

NMAP v3.48 tutorial lesson 4 of ? rev 1.0 by TheHorse13

PREFACE ***PLEASE READ AND UNDERSTAND THIS*** (Will be repeated at the top of each lesson)
======================
I’d like to start by saying that I will be covering many of the basic functions along with examples and explanations why you would want to use the tool in each scenario. In addition, I will hit on several advanced features for those who are familiar with the tool but not to the point where advanced knowledge of the application is grasped.

***I will be borrowing verbage (in some cases)*** from the developer because I feel that the developer has worded things in such ways that I cannot improve upon. By no means is this a cut & paste tutorial but I would like to make everyone aware that I will be borrowing info where it makes sense.

NOTE: TheHorse13 takes no responsibility in regards to your use of the information presented in the NMAP tutorial series. If you get into trouble, then obviously you aren’t as 31337 as you thought.

Bold text – Command syntax
Underlined text – Important information

PREREQUISIT
======================
Please read the past three tutorials if you are new to NMAP. They are all in the Anti-Online tutorials forum.

IN THIS LESSON
=====================
Now that you know how to use NMAP we are going to cover some advanced functionality along with what kind of footprints the application leaves behind. As you may have guessed, one of the topics in this tutorial is how to hide the source of your NMAP footprints. You will benefit from this info because you will see what types of scans NMAP users may use against you and you will also see what results are returned (or logged) when you attempt to enumerate networks. You will also see why NMAP can be most effective in mapping trust relationships on hosts between filtering devices such as firewall and/or routers.

I will be using a default install of Snort 2.0.0 build 72 on Red Hat 9 as a component in this tutorial. I will not be covering any features of Snort but rather what an admin will see if you hit a box that is running Snort. I could have used my own IDS setup but that would require another tutorial along with this series. Besides, I don’t want anyone seeing exactly how my IDS infrastructure responds to scans.

NOTE: Unless otherwise specified, assume that you are in a switched network environment.

Let’s start by just throwing a basic scan at a host that happens to have Snort running. Your IP is 192.168.1.100.

[haxor@localhost]# NMAP –v –sV -O -p 22 192.168.1.254

Snort will generate several alerts, including this one:

[**] SCAN nmap TCP [**]
11/07-01:33:18.752219 192.168.1.100:55464 -> 192.168.1.254:22
TCP TTL:46 TOS:0×0 ID:12633 IpLen:20 DgmLen:60
***A**** Seq: 0×18D5EF65 Ack: 0×0 Win: 0xC00 TcpLen: 40
TCP Options (4) => WS: 10 NOP MSS: 265 TS: 1061109567 0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
=+=+=+=+=+=+=+=+=+=+=

Hmmmm, notice the first line. [**]SCAN nmap TCP[**]. Then notice the source, 192.168.1.100:55464. Well folks, you’ve been made. Game over. Or is it?

Let’s try this again only let’s make a small change to our command. Again, your IP is 192.168.1.100

[haxor@localhost]# NMAP –v –sV –O –D 192.168.2.10 -p 22 192.168.1.254

Notice that we used the –D switch for decoy. This generates the following log entry in Snort:

[**] SCAN nmap TCP [**]
11/07-12:01:08.582551 192.168.2.10:35522 -> 192.168.1.254:22
TCP TTL:46 TOS:0×0 ID:1902 IpLen:20 DgmLen:60
***A**** Seq: 0×2B740381 Ack: 0×0 Win: 0xC00 TcpLen: 40
TCP Options (4) => WS: 10 NOP MSS: 265 TS: 1061109567 0
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
=+=+=+=+=+=+=

Notice how Snort thinks the traffic source IP was the decoy you specified, 192.168.2.10, not your true IP address of 192.168.1.100.

One additional thing you can do is add multiple decoys so that it appears that traffic is coming from a number of decoys.

[haxor@localhost]# NMAP –v –sV –O –D 192.168.2.10, 192.168.3.10 -p 22 192.168.1.254

This will generate log entries in Snort that show NMAP scans coming from the two decoys you specified.

Important: Be sure that your decoy machine(s) is/are up otherwise you may end up SYN flooding the target.

Another crafty way to hide yourself is with the –b FTP bounce option. Now, this issue has been addressed years ago and is rare in the wild but you can still find vulnerable FTP servers out there that will gladly bounce traffic for you. Because this is not really popular anymore, I’ll give you a quick explanation on how it works.
Because the RFC for FTP has proxy support, you are able to use an FTP server to bounce traffic. As *Hobbit* wrote back in 1995, this protocol flaw “can be used to post virtually untraceable mail and news, hammer on servers at various sites, fill up disks, try to hop firewalls, and generally be annoying and hard to track down at the same time.” What we will exploit this for is to (surprise, surprise) scan TCP ports from a “proxy” ftp server. Thus you could connect to an ftp server behind a firewall, and then scan ports…”.

The syntax is simple:

[haxor@localhost]# NMAP –v –sV –O –b anonymous:nopassword@fux0red.com:21 -p 22 192.168.1.254

You will see NMAP connect up and begin to proxy out traffic. Also, NMAP will inform you if a server is able to conduct this type of proxy operation. Typically, when you hit a server that will not do this, NMAP will tell you that the FTP server sucks and cannot be used for this purpose. The actual syntax looks something like this:

Hint: if your bounce scan target hosts aren’t reachable from here, remember to use -P0 so we don’t try and ping them prior to the scan

Starting nmap 3.48 (

http://www.insecure.org/nmap/

) at 2003-11-10 12:54 EST
Resolved ftp bounce attack proxy to 10.10.10.112 (Crack-House).
Host 192.168.1.254 appears to be up … good.
Attempting connection to

ftp://anonymous:ff@10.10.10.112:21

Connected:220-Microsoft FTP Service
220 Crack House – Da Masta Gangstaz
Login credentials accepted by ftp server!
Initiating TCP ftp bounce scan against 192.168.1.254 at 12:54
Your ftp bounce server sucks, it won’t let us feed bogus ports!

Anyway, this is the message you will see 99% of the time. I just wanted to include the syntax and output for learning purposes.

IDLESCANNING: THE NMAP HOLY GRAIL
=========================

Of all the features that NMAP has, this one is my favorite. This scan allows you to gather information about target hosts *without* sending packets. Yes, you read correctly. The most important thing to note is that NMAP reports vulnerability info based on the zombie’s perspective, that is, the machine you are using to idlescan the target. The benefit of this is that the zombie host may have a trust relationship with a target behind a router or firewall, while you, the attacker (or security auditor) obviously has no trust. For more information, along with a diagram, see

http://www.insecure.org/nmap/idlescan.html

Let’s go to work here. The scenario is that I am auditing the perimeter defenses of a subnet that has a router sitting between my subnet and the target subnet. There are about 50 hosts on my network and one of the boxes has a trust relationship with a box on another subnet.
Because we don’t want to be identified by the crafty folks watching the IDS logs, we’re going to use the idlescan technique. Now, the IDS will still log a hit but it will appear to come from the zombie host, not you. This may or may not raise attention based on how you probe the target host. Here we go.

First, let’s assume that you found the host that has the trust relationship. This is a paper on to itself so just bear with me. Now, Snort is positioned on the same network as the target machine.

You = 192.168.1.100
Zombie = 192.168.1.50
Target = 192.168.10.10
Snort = 192.168.10.5

[haxor@localhost]# NMAP –v –P0 –p 1-65535 -sI 192.168.1.50 192.168.10.10

Important: To be sure that an initial ping is not sent by using the –P0 switch, which tells NMAP not to send out an ICMP request to the target host.

Starting nmap 3.48 (

http://www.insecure.org/nmap/

) at 2003-11-10 12:54 EST
Idlescan using zombie 192.168.1.50 (192.168.1.50:80); Class: Incremental
Interesting ports on 192.168.10.10:
(The 65522 ports scanned but not shown below are in state: closed)
Port State Service
21/tcp open ftp
25/tcp open smtp
80/tcp open http
111/tcp open sunrpc
135/tcp open loc-srv
443/tcp open https
1027/tcp open IIS
1030/tcp open iad1
2306/tcp open unknown
5631/tcp open pcanywheredata
7937/tcp open unknown
7938/tcp open unknown
36890/tcp open unknown

Nmap run completed — 1 IP address (1 host up) scanned in 2594.472 seconds

Can you guess what Snort shows after this scan? Nada, zippo, nothing. It also appears that 192.168.1.50 has permit ACLs on the router as we suspected. All that is left is to compromise this host (which would be a joke for a number of reasons, but again, that’s another tutorial).

NOTE: If the box running Snort and the zombie are hooked up to the same hub as your host running NMAP then you are owned before you begin. Even with the –P0 switch, NMAP will send ICMP traffic to the zombie, which will result in every port on the hub seeing the traffic. This includes the box running Snort. Snort will immediately see this as NMAP activity and will nail you as the source. Be sure you understand networking before you decide to be cute with this application.

NOTE: There are plenty of things you can do to prevent this type of attack. This technique is shown here so that you can see how mis-configured hardware can easily lead to complete compromise. Also, how to use NMAP to identify mis-configured networking hardware.

Next lesson will show how NMAP can be used to identify mis-configured firewalls and how to determine which ACLs are in use.

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

Code: Select all

This paper is the work of The Master Jedi Pimpsor AKA thehorse13, who has kindly consented to it being hosted here on the TAZ.

NMAP v3.48 tutorial lesson 3 of ? rev 1.0 by TheHorse13

PREFACE (Will be repeated at the top of each lesson)
======================
I’d like to start by saying that I will be covering many of the basic functions along with examples and explanations why you would want to use the tool in each scenario. In addition, I will hit on several advanced features for those who are familiar with the tool but not to the point where advanced knowledge of the application is grasped.

I will be borrowing verbage (in some cases) from the developer because I feel that the developer has worded things in such ways that I cannot improve upon. By no means is this a cut & paste tutorial but I would like to make everyone aware that I will be borrowing info where it makes sense.

Bold text – Command syntax
Underlined text – Important information

NOTE: TheHorse13 takes no responsibility in regards to your use of the information presented in the NMAP tutorial series. If you get into trouble, then obviously you aren’t as 1337 as you thought.

PREREQUISIT
======================
Read Lesson one – The Basics and Lesson 2 – More Basics, both found in the Tutorial Forum.

IN THIS LESSON
=====================
This lesson deals with typical output observed when scanning outside of your network. Note that we are still using the basic and most common command set without any of the advanced features.

OH NO, WHAT ARE FILTERED AND UNFILTERED PORTS?
====================
Now that you have a grasp on the basic operation of NMAP and the base command line options, let’s take a look at some things that may pop up during your scans. Using NMAP internally is wonderful but the true power of the application is only seen when used *outside* of your network. The reason I say this is because there are many more potential targets…..errrrrr……..servers that need remediation out on the open internet.

Important – When you use basic NMAP functionality to perform scans against a host that is not yours, be prepared to be identified quickly. All good administrators can spot a standard port scan a mile away.

OK, let’s use a basic scan against a host and let’s take a peek at the output.

[haxor@localhost]# NMAP –v –sV -O -p 21,135,139,445,5800,5900 207.96.37.20

NOTE: Output edited for brevity

PORT STATE SERVICE
21/tcp open ftp
135/tcp filtered msrpc
139/tcp filtered netbios-ssn
445/tcp open microsoft-ds
5800/tcp unfiltered vnc-http
5900/tcp filtered vnc

The result of running nmap is usually a list of interesting ports on the machine(s) being scanned (if any). The state is either “open”, “filtered”, or “unfiltered”. Open means that the target machine will accept connections on that port. Filtered means that a firewall, filter, or other network obstacle is covering the port and preventing nmap from determining whether the port is open. Unfiltered means that the port is known by nmap to be closed and no fire wall/filter seems to be interfering with nmap’s attempts to determine this.

As we can see, this person has closed down the typical NetBIOS ports but forgot to do so to the CIFS service on port 445. This poor admin could have left just enough room for an attacker to enumerate some useful information from this host. We also see that FTP is waiting cheerfully for connections, while VNC is filtered. Oh yes, the HTTP vnc service appears to be closed but nothing seems to be standing in the way. Again. Another potential chink in the armor should the service suddenly become available.

LOOKS LIKE I HIT A FIREWALL
======================
From time to time you may see something like this:

[haxor@localhost]# NMAP –v –sV -O -p 1-65535 207.96.37.21

Starting nmap 3.48 (

http://www.insecure.org/nmap/

) at 2003-11-04 14:50 EST
Host 207.96.37.198 appears to be up … good.
Initiating SYN Stealth Scan against 207.96.37.21 at 14:50
The SYN Stealth Scan took 186 seconds to scan 65535 ports.
Warning: OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port
All 65535 scanned ports on 207.96.37.198 are: closed
Device type: firewall|general purpose
Running (JUST GUESSING) : Cisco PIX 6.X|5.X (90%), Stratus VOS (90%)
Aggressive OS guesses: Cisco PIX 506 Firewall (90%), Cisco PIX 515 or 525 running 6.1(4) – 6.2(1) (90%), Cisco PIX Firewall Version 6.2(2) – 6.3 (90%), Cisco Secure PIX Firewall Version 5.0(2) (90%), Stratus VOS Release 14.3.1ae (90%)
No exact OS matches for host (test conditions non-ideal).

Nmap run completed — 1 IP address (1 host up) scanned in 204.288 seconds

Well, well, well, what do we have here? NMAP does an excellent job of identifying firewalls and other network gear. This scan is on the money but you’ll have to do some more probing in order to pinpoint the exact model and exact IOS in use. The problem you have now is that the firewall admin now sees that you have port scanned his/her firewall. But maybe, just maybe there are ways to probe without raising attention. We will cover these techniques in the next lesson. Lesson 4 will be the first advanced lesson in this series. It will cover anonymous scanning, connectionless scanning and other techniques that avoid detection.

As always, comments good, bad and indifferent are welcome.

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

Code: Select all

This paper is the work of The Master Jedi Pimpsor AKA thehorse13, who has kindly consented to it being hosted here on the TAZ.

NMAP v3.48 tutorial lesson 2 of ? rev 1.0 by TheHorse13

PREFACE (Will be repeated at the top of each lesson)
======================
I’d like to start by saying that I will be covering many of the basic functions along with examples and explanations why you would want to use the tool in each scenario. In addition, I will hit on several advanced features for those who are familiar with the tool but not to the point where advanced knowledge of the application is grasped.

I will be borrowing verbage (in some cases) from the developer because I feel that the developer has worded things in such ways that I cannot improve upon. By no means is this a cut & paste tutorial but I would like to make everyone aware that I will be borrowing info where it makes sense.

PREREQUISIT
======================
Read Lesson one – The Basics, found in the Tutorial Forum.

IN THIS LESSON
=====================
This lesson will still be at the beginner level so those who are advanced users, look for later lessons where things like connectionless scans are covered.

We will look at some additional scanning techniques and when to use them. We will focus only on internal scans at this point. We will look at output when you hit firewalls, routers and other devices between you and your target in later lessons.

SUBNET, PORT RANGES AND MULTIPLE HOST SCANS
=====================
In lesson 1, we saw a very basic scan that produced results for a single host. Let’s take that same example and add a small twist. You now have an entire subnet that needs to be scanned to pinpoint all of the machines that have remote control services running. In the organization, PCAnywhere is the only supported remote access solution and you now have to track down those who are not in compliance. Being a vigilant security professional, you immediately grab your trusty NMAP tool and go to work.

NOTE: Some folks are quite crafty and don’t run services on the typical port associated with the service. But for now, we will make two assumptions for this example. First, all remote control services are running on the ports that are typically associated with them.

We will assume that three additional remote control services are running out there. They will be, 1) Terminal Services, 2) VNC and 3) LapLink. The subnet you will scan is a class C network so the network is 192.168.1.0 and the subnet mask is 255.255.255.0

OK, let’s create the syntax to discover these services
[haxor@locahost]# NMAP –v –sV -p 1547,5631,3389,5900 192.168.1.0/24

OK, let’s look over what we are doing here.
NMAP – obviously the command
-v – I typically recommend using the verbose switch. If you leave it out, your output will only show the ordered port list and a few less details on scan time responses and other details that may be useful to you.
-sV – Since the default privileged mode scan is sS (SYN Stealth, or half-open scan- a scan where only the SYN flag is sent in the packet) -sV will cause NMAP to communicate with the box to identify the running services that it finds. This feature was added in NMAP-3.48.
-p – Ports can be expressed individually separated by commas, as ranges separated by dashes or a combination such as –p 1547,1567,3300-3350
hosts 192.168.1.0/24 – now, without starting another tutorial subject, subnet masks must be expressed as bits. For example, 255.255.255.0 is a 24 bit mask, 255.255.0.0 is a 16 bit mask, etc. A single host does not require a subnet mask but if you want to be technical, it would be 32 and would work if given as part of the command. You can also use the “*” key like this: -p 192.168.1.* This is the same as 192.168.1.0/24.

Now then, in the interest of post length, I’ll let you play with the multiple host syntax and specific port/port range functionality. You’ll notice that you will get a complete record for each host that is alive and should a host not respond, NMAP will notify you that the host appears to be down and NMAP is skipping it.

One more function that I’d like to cover is the multiple host scan syntax.

[haxor@locahost]# NMAP –v –sV -p 1547,5631,3389,5900 192.168.1.10,11,12

Notice that I just added additional host ID numbers separated by commas. NMAP will recognize this as a multiple host scan. You can also use the same idea when scanning a range of hosts.

[haxor@locahost]# NMAP –v –sV -p 1547,5631,3389,5900 192.168.1.10-15

This will tell NMAP to scan the specified ports using the IP range 192.168.1.10 thru 15. You’ll notice that port and host expressions are the same. This makes learning the command line switches a bit easier.

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

Code: Select all

This paper is the work of The Master Jedi Pimpsor AKA thehorse13, who has kindly consented to it being hosted here on the TAZ.

PREFACE:
=================================================
I’d like to start by saying that I will be covering many of the basic functions along with examples and explanations why you would want to use the tool in each scenario. In addition, I will hit on several advanced features for those who are familiar with the tool but not to the point where advanced knowledge of the application is grasped. I will be borrowing verbage (in some cases) from the developer because I feel that the developer has worded things in such ways that I cannot improve upon. By no means is this a cut & paste tutorial but I would like to make everyone aware that I will be borrowing info where it makes sense. For those who have been around here for awhile, you know that I preface my tutorials with this advanced warning in the event that someone finds a sentence or two from the original man pages for the app.

SCOPE: Part 1 in a series of 5 – Basic Port and Host Probing
=================================================
The scope of this tutorial is limited to the more popular options used with packet crafting. I will not be covering *every* switch and combination thereof or I would be writing a 500 page book. If there is a particular switch/switch combo you don’t see covered, PM me and I will be happy to write a companion tutorial. Also, HPING has many other uses (port scanner, stack auditing, fire-walking, etc., etc.). I am also going to assume that readers of this tutorial already have a firm grasp on networking and standard protocols. If you do not, you wont benefit much from this series of tutorials. Like my NMAP series, I will start with very basic techniques and ramp up to the more complex in the last two. Again, all input, good or bad, is welcome.

Tool: HPING:

http://www.hping.org/download.html

=================================================

Using HPING for host detection begins with just sending a packet and waiting for the reply. If no reply is received, the host is down, the packet has been filtered or the packet has been dropped. We will use this rule of thumb throughout the series of tutorials. Also, unless otherwise noted, the target host is going to be a W2K3 server.

PART I

TCP SYN Packet Probe:
=================================================
Packets with the SYN bit flagged typically won’t be filtered or dropped if the target port is open. Normally, an open port will receive this packet and return the expected SYN/ACK-flagged packet. Closed ports will normally return a packet flagged with the RST/ACK bits set. Let’s try this command out.

[root@HorseyLand-Labs]#hping 10.10.10.10 -S -c 1 -p 21

Switches defined:
-S = Set the SYN flag.
-c 1 = Packet count. In this example, I only sent one.
- p 21 = The port on the remote host I want to send the packet to.

HPING 10.10.10.10 (eth0 10.10.10.10): S set, 40 headers + 0 data bytes
len=46 ip=10.10.10.10 ttl=128 DF id=25618 sport=21 flags=SA seq=0 win=16616 rtt=0.4 ms

NOTE: The return packet info begins with len=46.

The above packet was sent to a host to check if port 21 (File Transfer Protocol) is open, and apparently it was. As we expected, a packet was returned with the SYN/ACK bits flagged. Of course the remote host is now expecting another packet from your host with the ACK bit flagged in order to complete the 3-way handshake required for TCP/IP connections.

Let’s dissect the information returned and see what each item means.

S set – The SYN flag is set.
40 headers + 0 data bytes – Shows you that no data was added to the body of the packet.
len – The size, in bytes, of the data captured from the data link layer excluding the data link header size. This may not match the IP datagram size due to low level transport layer padding.
ip – The target IP address.
ttl – The default time-to-live setting on the packet. It will hop 128 times before dropping off the face of the Earth.
DF – The “don’t fragment” bit is set
id = This is the IP identification
sport = This is the target port
flags = The flags set on the response
seq = The sequence 32bit number in the TCP header.
win = The TCP window size.
rtt = round trip time in milliseconds.

Now that you see what a normal response is to a SYN packet sent to an open port, let’s try to send the same packet to a closed port.

[root@HorseyLand-Labs]#hping 10.10.10.10 -S –c 1 -p 2

HPING 10.10.10.10 (eth0 10.10.10.10): S set, 40 headers + 0 data bytes
len=46 ip=10.10.10.10 ttl=128 DF id=25927 sport=2 flags=RA seq=0 win=16616 rtt=0.5 ms

The above packet, flagged with the SYN bit was sent to a closed port, port 2. Notice that the RST/ACK flag is set on the return packet. This is the expected behavior because the port is not accepting TCP/IP connections

TCP ACK packet: Is the host alive?
=================================================

When a packet with the ACK (acknowledge) bit flagged is sent to a host, if the host is alive, it should respond with another packet with the RST (reset) bit flagged. The beauty of this technique is that it doesn’t make a difference whether the port you sent the ACK-flagged packet to is open or closed. If the host is alive, it should respond with a RST-flagged packet.

NOTE: Many vendors are aware of this technique and have built in mechanisms to defeat it.

[root@HorseyLand-Labs]#hping 10.10.10.10 -A –c 1 -p 123

Switches defined:
-A = Set the ACK flag.
-c 1 = Packet count. In this example, I only sent one.
- p 123 = The port on the remote host I want to send the packet to.

HPING 10.10.10.10 (eth0 10.10.10.10): A set, 40 headers + 0 data bytes
len=46 ip=10.10.10.10 ttl=128 id=26250 sport=123 flags=R seq=0 win=0 rtt=1.3 ms

Notice the returned packet, flagged with the RST (reset) bit flagged. This indicates that our host is alive and that TCP ACK-flagged packets are allowed through.

TCP SYN/ACK packet: Another way to see if the host is alive.
==================================================

This technique sends a packet with the SYN and ACK bits flagged. This technique is geared more towards host operating system detection but I wanted to mention it here for two reasons. One, because you can use it to see if a host is alive and two, I want you to become familiar with it for later use. When a host receives a packet flagged with the SYN/ACK bits, it returns a packet flagged with the RST bit flagged. This will be the case whenever a port is open or closed.

[root@HorseyLand-Labs]#hping 10.10.10.10 -SA –c 1 -p 123

HPING 10.10.10.10 (eth0 10.10.10.10): SA set, 40 headers + 0 data bytes
len=46 ip=172.29.94.4 ttl=62 DF id=266 sport=123 flags=R seq=0 win=0 rtt=0.3 ms

By now you should be able to identify the switches I’m using. In later tutorials, I will not reference basic switches as I did early in this tutorial.

That’s all for part I. Look for part II within the next week or so.

–TH13