In this article we will go through an example of how to use tcpdump to analyse http connection header redirects.
1. What is TCPDUMP
Tcpdump is a packet analyzer available in every Unix and Linux operating system. It uses libcap set of libraries to structure the binary data captured from the kernel interface.
Tcpdump is a tool used by many, if not all, network administrators to troubleshoot network, Linux and application related communication channels as it aid in discovering network or application flaws.
For most user users, it’s most basic application is to capture traffic for a specific interface and specific host or port. Medium level usage implies tasks like analyzing HTTP protcol or other layer 7 information in your VPS Linux server.
2. HTTP protocol – brief description
HTTP is the underlaying protocol for transferring web pages from web servers to client browsers. It runs on top of TCP/IP stack and is considered as OSI layer 7 protocol (although HTTP is an underlaying protocol for other protocols, but let’s stick to the point).
As with any other protocol, it is split into header section – that establish the session parameters – and the data section that is the object of the session. The headers are transfered on the network in clear text ASCII characters, in human readable format.
HTTP 1.0 and HTTP 1.1 are synchronous in nature, meaning that first request is blocking all the others and when it received the result, the next request is sent to the server – on the same TCP session.
3. TCPDUMP and HTTP analysis
Depending on the area of operation, tcpdump will help you analyse http request header or http response header to troubleshoot abnormal behavior in your web server or in the browser, or both. In other circumstances, tcpdump can be used to analyse a nested protocol like an HTTP chat application – but in all fairness most of them are encrypted or gzip compressed nowadays.
A few tcpdump options we need to focus on in order to to a proper http header analysis:
-A Print each packet (minus its link level header) in ASCII. Handy for capturing web pages. -s Snarf snaplen bytes of data from each packet rather than the default of 65535 bytes. Packets truncated because of a limited snapshot are indicated in the output with ``[|proto]'', where proto is the name of the protocol level at which the truncation has occurred. Note that taking larger snapshots both increases the amount of time it takes to process packets and, effec- tively, decreases the amount of packet buffering. This may cause packets to be lost. You should limit snaplen to the small- est number that will capture the protocol information you're interested in. Setting snaplen to 0 sets it to the default of 65535, for backwards compatibility with recent older versions of tcpdump.
Let’s discuss the above points a little. The first one is self explanatory, it prints out ASCII characters in HTTP protocol.
The second one instructs tcpdump to buffer only the first X bytes in each packets. If we will analyze HTTP headers, then we don’t need to go through the complete packet data.
Let’s see how to actually analyse http headers with tcpdump in your Linux vps server and comment afterwards:
$ sudo tcpdump -nni eth0 -s450 -A port 80 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 450 bytes 02:19:25.266488 IP 192.168.3.100.50174 > 10.1.22.2.80: Flags [S], seq 4237349077, win 65535, options [mss 1360,nop,wscale 5,nop,nop,TS val 694566367 ecr 0,sackOK,eol], length 0 E..@..@.>......d ......P............ZW.....P....... )f=......... 02:19:25.266599 IP 10.1.22.2.80 > 192.168.3.100.50174: Flags [S.], seq 276494302, ack 4237349078, win 5792, options [mss 1460,sackOK,TS val 1594697703 ecr 694566367,nop,wscale 9], length 0 E..<..@.@.V. ......d.P...z..................... '.)f=.... 02:19:25.322756 IP 192.168.3.100.50174 > 10.1.22.2.80: Flags [.], ack 1, win 4128, options [nop,nop,TS val 694566423 ecr 1594697703], length 0 E..4..@.>.p....d ......P.....z..... ....... '.>._ 02:19:25.324656 IP 192.168.3.100.50174 > 10.1.22.2.80: Flags [P.], seq 1:445, ack 1, win 4128, options [nop,nop,TS val 694566423 ecr 1594697703], length 444 E...1.@.>.%....d ......P.....z..... 7...... '.GET / HTTP/1.1 Host: domain.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:35.0) Gecko/20100101 Firefox/35.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Cookie: __utma=139744236.2020155993.1422525750.1423094188.1423158168.3; __utmz=139744236.1422525750.1.1.utmcsr=(direc 02:19:25.324749 IP 10.1.22.2.80 > 192.168.3.100.50174: Flags [.], ack 445, win 14, options [nop,nop,TS val 1594697718 ecr 694566423], length 0 E..4.)@.@... ......d.P...z...........S..... '.)f>. 02:19:25.325591 IP 10.1.22.2.80 > 192.168.3.100.50174: Flags [P.], seq 1:368, ack 445, win 14, options [nop,nop,TS val 1594697718 ecr 694566423], length 367 E....*@.@... ......d.P...z................. '.)f>.HTTP/1.1 301 Moved Permanently Server: nginx Date: Fri, 27 Feb 2015 00:19:25 GMT Content-Type: text/html Content-Length: 178 Connection: keep-alive Location: http://www.domain.com/301 Moved Permanently
301 Moved Permanently
In the first three packets there is nothing readable as they contain the TCP 3way handshake and all packets will contain IP + TCP headers and no PDU (Protocol Data Units) – as the Length 0 shows.
The fourth packet is more interesting to our task today. It is originated by the client / web browser and it contains a TCP PUSH flag ( have a look at http://en.wikipedia.org/wiki/Transmission_Control_Protocol if you are the curious type ) meaning that the browser instructs the server’s kernel to push the data to the upper level receiving application (HTTP in our case). This packet also contains the human readable data (http request header) which is telling us the browser requests the home page of “domain.com”.
The fifth packet has the same TCP PUSH flag and it contains the http reply header that reveals an HTTP 301 code – permanent move of URI – informing us and the browser that “domain.com” has moved to “www.domain.com”.
In real life, owning a Linux or Windows SSD VPS server at VPSie will give you an edge when it comes to performance of your webserver and application and, through our blog and community, we are aiming to provide our customers with enough information to help configure and troubleshooting their vps servers.
I hope you enjoyed and please share your comments.
You can actually try those steps on our platform in few minutes utilizing our PCS (Private Cloud Solution) which allows you to have VPSie(s) on a private network – NAT – Port forward – traffic control for inbound and outbound – multiple gateway IPs which you could use for the load-balancing and failover.