Network security

Computer Network Diagnostics, Part 3

November 12, 2012 by Adrian Stolarski

Previously, we took the principles of DHCP and DNS servers. We already know how to operate, inter alia. We also have data on how computers communicate over a network. Today we can finally move on and take care of other things. In total, we probably will return to the DHCP server and DNS name resolution through, but we will know the tools for network analysis and how to display its statistics. Also we will finish our discussion on this, as it happens, however, that there is something in our web browser. And then we’ll see how much we really take it and can go on. At the end we are left with the correct configuration of DHCP and DNS servers. In this way, I see these articles. So we start?

We’re going on, or a few words about HTTP

So, yes, we know how our network communicates with other computers, we know how most of the services work. We were able to understand the principles of operation of the DNS. Next everything is really easy. The browser is sending a query to the web server, which is selected by our website. This query will be sent by either HTTP or HTTPS. Both protocols use a combination of the TCP family, including in the case we are dealing HTTP port 80 on the server, and in the case of HTTPS with port 443 despite the fact that a web page appeared, its appearance did not happen in the same way as the other. In this case, it really was a statement of the connection between the socket that supports our browser and the web server process, which in the case of Linux, is called a web server daemon.

As is often the case in science, this statement is of course its name. The name is a three-way-handshake. A three-way-handshake consists of a certain TCP SYN segments that are exchanged from the client to the server. In addition, it also consists of segments of the SYN ACK, which sends the server to each client. ACK segments are sent from the client to the server. So that it looks at a glance:

First: The client sends to the server TCP SYN request.

Second: The server sends a TCP ACK response.

Third: A customer sends an ACK in response to the data received from the server.

Of course, each of these segments is sent by the appropriate router IP packet through the gates on both sides, both the internal network and the external network. Thanks to the two machines and the initial exchange of segments between them, it is possible to truly have two-way communication between machines. How to see the operating system? In fact, as a separate two-way communication channel. In computing the channel it carries the name of the virtual circuit.

And now it’s time for another tool, used for the diagnosis of computer networks. All established connections and all information on the statistics we used the protocol to take a look at any time, using the netstat. Here’s an example of the netstat output:

Active Internet connections (w / o servers)

Proto Recv-Q Send-Q Local Address Foreign Address State

tcp 1 0 localhost: 33851 localhost: http CLOSE_WAIT

tcp 0 0 localhost: http localhost: 33849 FIN_WAIT2

tcp 0 0 localhost: http localhost: 33851 FIN_WAIT2

tcp 1 0 localhost: 33852 localhost: http CLOSE_WAIT

tcp 0 0 localhost: http localhost: 33852 FIN_WAIT2

tcp 1 0 localhost: 33849 localhost: http CLOSE_WAIT

Active UNIX domain sockets (w / o servers)

Proto RefCnt Flags Type State I-Node Path

unix 19 [] DGRAM 10270 / dev / log

unix 2 [] DGRAM 2005 @ / usr / org / kernel / udev / udevd

unix 2 [] DGRAM 10639 @ / org / freedesktop / hal / udev_event

unix 3 [] STREAM CONNECTED 33836 @ / tmp/dbus-zZYWdSwl6E

unix 3 [] STREAM CONNECTED 33835

unix 3 [] STREAM CONNECTED 33753 / var / run / dbus / system_bus_socket

unix 3 [] STREAM CONNECTED 33752

unix 3 [] STREAM CONNECTED 33703 / tmp/orbit-root/linc-6d1-0-552891ab74d84

unix 3 [] STREAM CONNECTED 33702

unix 3 [] STREAM CONNECTED 33699 / tmp/orbit-root/linc-

However, all information about the program netstat can be seen by typing in the Linux command: “man netstat”. The most popular option is to use the netstat command “netstat-a-s-s’. Here is a sample output after using this command:


703 total packets received

0 Forwarded

0 incoming packets discarded

631 incoming packets delivered

705 requests sent out

177 dropped because of missing route


290 ICMP messages received

0 input ICMP message failed.

ICMP input histogram:

echo requests: 145

echo replies: 145

290 ICMP messages sent

0 ICMP messages failed

ICMP output histogram:

echo request: 145

echo replies: 145


InType0: 145

InType8: 145

OutType0: 145

OutType8: 145


31 active connections openings

30 passive connection openings

1 failed connection attempts

14 connection resets received

0 Established connections

333 segments received

333 segments send out

0 segments retransmited

0 bad segments received.

15 resets sent


8 packets received

0 packets to unknown port received.

0 packet receive errors

80 packets sent



15 TCP sockets finished time wait in fast timer

4 delayed ACKs sent

51 packets queued to recvmsg Directly prequeue.

Directly 110046 bytes received in process context from prequeue

14 packet headers predicted

10 packets header predicted and queued to user Directly

78 Acknowledgments not containing data payload received

27 predicted Acknowledgments

13 connections reset due to unexpected data


InMcastPkts: 15

OutMcastPkts: 17

InBcastPkts: 57

OutBcastPkts: 57

After the handshake, the client begins to communicate. Then it sends HTTP requests, which consist of the GET. The server then acknowledges receipt of the packet, and enriches the GET command carrying packages containing ACK packets. Then it sends them to the page you want to really see. The number and ACK packets rules are determined by the initial size of the TCP window.

Of course, this communication can be seen with our own eyes. Just use telnet. We can run it and tell it to connect to the selected web site on port 80 or port 443 Telnet is a console application, and as an example we can try to connect with our host. To this end, we spend in the console command:

# Telnet localhost 80

Once connected, simply type GET to see the html code selected by our website. Now let us look at the events which took place after the start of the computer to display in the web browser of our favorite website. Is it really is a lot of them, whether it’s just a few simple steps and events, linked together in a logical whole? I suggest you write a simple algorithm that shows how it really works. Here it is:

First The client sends a DHCPDISCOVER request to the network.

Second DHCP servers respond with DHCPOFFER.

3rd The client requests from the DHCP server to provide data for yourself – DHCPREQUEST.

4th The DHCP server provides the client with all the necessary data using DHCPACK.

5th The client request extends the physical address of the gateway via ARP-request.

6th Gateway returns customer ARP-reply response, which is included in the physical address of the Internet gateway.

7th Now, the client sends a request to one of the two DNS servers in the following order: first the master server is queried, and then the backup server.

8th DNS servers respond to the client.

9th Client starts something called a tripartite handshake with the server by sending a TCP SYN packet to him.

10th The server then sends a confirmation to the client to establish the handshake and request a regenerative connection with SYN ACK packet.

11th The client sends to the server you want to connect a confirmation with an ACK.

12th Now, the server confirms the client’s ACK.

13th At the end of the communication, the server sends the HTTP client browser code page.

As you can see, so far we considered only the optimistic scenario, which means that all communication has really gone as planned. But that is not always the case. The truth is that rarely is any message sent in one segment, and each segment of the message is placed in only one frame network. Sometimes, just because this is happening, there is a certain confusion between the client and server. Then the server sends to the client usually request retransmission of data or provide other information which are mostly related to error handling. So usually the actual number of frames is much greater than in the case of optimistic communication between the client and the server. In most Linux distributions, each is accompanied by at least one network sniffer. With this program, you can track in real time from another machine on the same domain packet traffic collision and exchange of information among all the machines that are in it.

Unfortunately, as is often the case in life, everything is not always so beautiful and colorful as it might seem. Sometimes, instead of the expected content of our website, we get the messages and information that you are not able to open the website. Fortunately, this series of articles presents a number of tools that help you manage professionally any of the networks.

In this article, we will describe only one of the problems that we encounter. If indeed this is the case, as has been described, the first source of the problems that we encounter is a physical network device, such as a network adapter, antenna for WiFi, router, or the medium through which all communication takes place on the network.

The most common failure encountered in computer networks is damage to the famous RJ-45 cable. Although it may be that both the adapter and cables are all right. Then the first thing you should check is the ifconfig output, which certainly will show what happened and whether there is any communication. If nothing happens, we should try to manually set the network mask and the logical address of the network card, or simply run a setup program and try to reconfigure dynamic receiving a logical address on the card. If you manually set the logical address all right, we can go further. Perhaps there is an error somewhere locally or on the DHCP server. The main local problems with computer networking equipment is damaged or incorrect configuration of TCP / IP client. If there is no problem with the local IP address of your machine, then you should try to make sure all TCP / IP components function properly.

I’ll also briefly describe a second method to determine this type of action and reaction. A very good method is to ping the local address and then our IP address, as it is seen on the network. If it works, then use the ping on the network gateway or router, and then on any of the hosts from the outside. But the ping program will be a lot more …


Slowly we go farther and farther from our reflections on computer network diagnostics. You already know a lot about the principles of their operation and the way they held communication. In addition, the simplified algorithm developed ways of making calls over computer networks. As you noted this is not as difficult as it might initially seem. I hope that at the end of the series, we will be able to talk freely about most of the configuration interfaces and devices in the network and on the problems we face in everyday life and everyday network administrator and computer systems.

In the next article in this series we will shake the principle of operation of the ping and traceroute, and also do a small summary of the lessons learned so far. We cordially invite you to read the following articles, which even by InfoSec standards are really unusual. Good Luck!

Posted: November 12, 2012
Adrian Stolarski
View Profile

Adrian Stolarski is a freelance security tech blogger, specializing in Java, PHP, and JQuery. In his own words, he does the hard work of training the unemployed. Currently, he handles Evaluation Visualization for real-time systems with XWT and Eclipse RAP. If he sees that something works, he asks how it works and why it works, then sets out to make it work better. A researcher for InfoSec Institute, he currently lives in Poland, but plans to move to London.