Hacking

Hacking is an ART OF EXPLOITATION.

Nessus

One of Good Network Vulnerability Scanner.

Accunetix

Web Application Scanner.

BeEF

Do You Love BeEF, Its an Browser Based Exploitation Framework.

Wikileaks

WikiLeaks is an international, online, non-profit[2] organisation which publishes secret information, news leaks, and classified media from anonymous sources.

Showing posts with label ICMP. Show all posts
Showing posts with label ICMP. Show all posts

Thursday, July 25, 2013

PING - Network Tool Tutorial - 3

Before reading this tutorial please go through Part - 1 & Part - 2

In previous tutorial we seen

ping gives us three major information

-Host Reachability
-Network Congestion
-Time To Live

in that we discussed about what is "Host Reachability", Now we will be seeing Network Congestion

Network Congestion:

Another very precious information provided by the Ping command is the time taken for a packet to reach the destination and come back. This measure is called the RTT (Round Trip Time) or "response time" and is displayed in milliseconds. 
It should not be mistaken for the latency or delay defined as the one-way time taken for a packet to travel across the network between two hosts. 

The response time will affect network applications performance. High response times will lead to poor performances.
When a network application is slow, a first basic troubleshooting step is to get the reponse time between the client and the server to know if the network is the reason of the slowness. 

We should not forget another information related to the response time: the packet loss. A packet is declared as lost if the ICMP message has been discard on the way or if is returned after the timeout value equal to 2 seconds by default. Packet losses will lead to a high TCP retransmission rate with the consequence of a slow or interrupted network application.
In a LAN environment, there shouldn't be any packet loss.

What affects the response time and Packet loss?

-The Network Media
-Network Devices
-Physical Remoteness
-Source and Destination Devices

Time - to - Live

The TTL or Time-To-Live gives you an indication of the number of routers between the source and destination. 
The TTL is used to prevent an IP packet from looping inside an IP network and causing a network meltdown. 
The initial TTL packet value for an IP packet is 255 and then it is decremented by 1 each time it encounters a router. When this value reaches 0, the packet is discarded by a router. The TTL value is contained in each IP packet including ICMP packets. The TTL value given by the ping command is in fact the TTL value of an echo_response packet. 
By default, Windows will decrease the TTL by 128 and Ubuntu Linux by 192.

Let us study three scenarios where A pings B. B is a router (first case), 
A Microsoft Windows machine (case 2) and a Ubuntu Linux machine (case 3). 

The TTL value is initially 255 and then decreased as described as above.

Case 1:
When A pings B, it receives a TTL of 251 because the packets crossed 4 routers (-4).
TTL=255-4=251.  


PING B

Pinging B [1.1.1.1] with 32 bytes of data: 

Reply from 1.1.1.1: bytes=32 time=18 ms TTL=251 
Reply from 1.1.1.1: bytes=32 time=21 ms TTL=251 
Reply from 1.1.1.1: bytes=32 time=20 ms TTL=251 
Reply from 1.1.1.1: bytes=32 time=33 ms TTL=251 

Ping statistics for 1.1.1.1: 
      Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), 
Approximate round trip times in milli-seconds: 
      Minimum = 18ms, Maximum = 33ms, Average = 23ms

-------------------------------------------------------

Case 2:
When A pings B, it receives a TTL of 124 because the packets crossed 3 routers (-3) and a Windows machine (-128).
TTL=255-3-128=124.


PING B

Pinging B [1.1.1.1] with 32 bytes of data: 

Reply from 1.1.1.1: bytes=32 time=18 ms TTL=125 
Reply from 1.1.1.1: bytes=32 time=21 ms TTL=125 
Reply from 1.1.1.1: bytes=32 time=20 ms TTL=125 
Reply from 1.1.1.1: bytes=32 time=33 ms TTL=125 

Ping statistics for 1.1.1.1: 
      Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), 
Approximate round trip times in milli-seconds: 
      Minimum = 18ms, Maximum = 33ms, Average = 23m 

------------------------

Case 3:
When A pings B, it receives a TTL of 62 because the packets crossed 3 routers (-3) and an Ubuntu machine (-192).
TTL=255-3-192=60. 


PING B

Pinging B [1.1.1.1] with 32 bytes of data: 

Reply from 1.1.1.1: bytes=32 time=18 ms TTL=60 
Reply from 1.1.1.1: bytes=32 time=21 ms TTL=60 
Reply from 1.1.1.1: bytes=32 time=20 ms TTL=60 
Reply from 1.1.1.1: bytes=32 time=33 ms TTL=60 

Ping statistics for 1.1.1.1: 
      Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), 
Approximate round trip times in milli-seconds: 
      Minimum = 18ms, Maximum = 33ms, Average = 23ms

-------

Use wireshark to go in-depth analysis of PING Command.

(Taken from openmaniak.com)


PING - Network Tool Tutorial - 2

OUTPUT ANALYSIS:

In previous tutorial PING - Network Tool Tutorial - 1 we seen how PING Command works

if you want to clearly understand about PING command go through Tutorial - 1.

we catched echo_request and echo_response by using wireshark(A Popular Network Sniffing Tool)


ping gives us three major information

-Host Reachability
-Network Congestion
-Time To Live

Host Reachability

The Ping results in the previous tutorial show that four ICMP packets have been sent and four received. This result indicates you that the host is alive at the ICMP level. However, no other information, such as whether or not a a webserver is running, is given.

What's does it mean if I receive a negative result?
Let's see an example:


C:\>ping www.abcdefg.com

Pinging abcdefg.com [192.168.88.15] with 32 bytes of data:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.88.15:
      Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Host www.abcdefg.com, which has IP address 192.168.88.15, did not answer to the Ping command. It's interesting to note that the negative answer does not always mean that the recipient is not alive (in our example, it is alive and runs a webserver). In this case, the result simply means that the host just doesn't answer to ICMP request.

What could be the reason for this "no-answer" ?
It is not always possible to know the exact reason behind a "no-answer". As a matter of fact, there may be a lot of different reasons. In the following picture, we summarize the four major reasons.


In the first case, an external firewall blocks the ICMP requests. ICMP can be used as a first step in an attack because it can determine the alive hosts before attacking. In this case the network behind the firewall is hidden from the external world even it is well alive.

Blocking ICMP messages is a first security recommendation to secure a network. The external firewall is more often used to secure professional network because it is expensive and requires advanced skills for configuring.

In the second case, the workstation has a personal firewall that blocks the ICMP message. A personal firewall is recommended for home computers for the same reasons mentioned above.

In the thrid case, the "pinged" machine is not connected to the IP network, for instance, because the network cable is unplugged.
The echo_request message will be discarded on the last router of the layer 3 device before the remote host.

In the fourth case, the host is down or has its network card deactivated. Such as in the previous case, the echo_request message will die on the last router of the layer 3 device before the remote host.

------------

If a device called Geneva can ping another called Dallas, does it mean that the opposite, in other words Dallas can ping Geneva, is always true?

The response is no. As you can see below, you can have a firewall only preventing echo_request in a single direction.

When Dallas pings Geneva, the ICMP echo_request is blocked on the firewall and Dallas receives no answer from Geneva.

When Geneva pings Dallas, the ICMP echo_request reaches Dallas and Geneva receives the echo_response in return, so the ping is successful. In this case, the ICMP packets are not blocked since the firewall only stops echo_request coming from outside. Here, we have an echo_request from inside and an echo_response from outside.


Remaining things will be seen in tutorial -3..

(Taken from openmaniak.com)

PING - Network Tool Tutorial - 1

Ping is a well known tool that is used to check the network connectivity between two systems.
ping tool is by default available in both windows,MAC and linux/unix systems.

The ping was created in 1983 by Mike Muuss who wrote an article "The Story of Ping Program" before dying in 2000 in a car accident

The ping uses an ICMP(Internet control message protocol) protocol which has been created to check IP connectivity and get information about other machines in an IP network.

Functioning of PING

Ping sends very small packets to target host who will answer by sending packets back. The ICMP packets send to target host are called as "echo_request" and packets sent back called as "echo_response".

There are also a lot of icmp packets types which are described below


Case Study:

Let's examine a case study where two machines called Paris and Berlin ping a machine called "www.google.ch".

The Wireshark sniffer is located on the way between Berlin and "www.google.ch". It will be used to capture the packets content.

Paris is a Linux Ubuntu machine and Berlin a Microsoft XP Machine


Ping from the Linux machine (Paris) to "www.google.ch":

Paris: ping www.google.ch

PING www.google.ch (209.85.135.105) 56(84) bytes of data.
64 bytes from www.google.ch(209.85.135.105): icmp_seq=1 ttl=255 time=1.19 ms
64 bytes from www.google.ch (209.85.135.105): icmp_seq=2 ttl=255 time=1.25 ms
64 bytes from www.google.ch (209.85.135.105): icmp_seq=3 ttl=255 time=1.26 ms
64 bytes from www.google.ch (209.85.135.105): icmp_seq=4 ttl=255 time=1.29 ms

--- www.google.ch ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 1.192/1.250/1.290/0.044 ms

Ping from the Windows machine (Berlin) to "www.google.ch":

Berlin: ping www.google.ch 

Pinging www.google.ch [209.85.135.105] with 32 bytes of data:

Reply from 209.85.135.105: bytes=32 time=18 ms TTL=250
Reply from 209.85.135.105: bytes=32 time=21 ms TTL=250
Reply from 209.85.135.105: bytes=32 time=20 ms TTL=250
Reply from 209.85.135.105: bytes=32 time=33 ms TTL=250

Ping statistics for 209.85.135.105:
      Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
      Minimum = 18ms, Maximum = 33ms, Average = 23ms

What information can be learnt from the outputs above?

- Is the remote host alive? => Host reachability
- Is the network speed good? => Network congestion
- Is the remote host far? => Travel length

we will see remaining things "OUTPUT ANALYSIS" for full details about how to interpret the results of the ping command.

We can also say that the Ping tool will provide us the same information independently of the OS on which it is installed. However there are some little differences in the default settings and arguments of the Ping commands.

Let's see a summary of data captured by Wireshark



This Wireshark capture gives us the following information:

- The packets have been recognized as ICMP packets. protocol column
- Four ICMP packets have been sent (echo_request) and four ICMP packets have been received (echo_reply). info column
- A packet value of 74 bytes which is composed of the headers (42 bytes) and the ICMP data part (32 bytes by default on Windows). length column

Remaining things we will be seeing Ping tutorial  2 ..