Sniff HTTP Traffic to a specific port

Leonard
2 min readJul 13, 2017

--

This is more of a note for me to reference in future.

tcpdump -s 0 -A ‘tcp dst port 80 and (tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504f5354)’

This simpler one also works:

tcpdump -n dst port 80

Other useful commands when troubleshooting network:
https://rationallyparanoid.com/articles/tcpdump.html

I just completed integration to one of the PRSPs (Premium rate service providers) in Kenya for Mobile VAS services i.e. USSD and SMS services. Mostly PRSPs don’t usually have weird connectivity requirement and you would just make a HTTP/SMPP request to them for SMS and USSD.

But this particular was special and they required a VPN between our server and theirs and some other weird requirements that I will rant about in future.

So we configured the VPNs and completed the network requirements and connectivity and went straight to consuming and sending requests and that is where things became tough.

For HTTP traffic I use POSTman to simulate external traffic and it has never disappointed. But here was a situation where a request from POSTMan had a 200 response while a request from our partner was resulting in a 400.

Of course debugging begins:

Application level Debugging:

  • Check routes/Endpoints — Okay
  • Check access and error logs — Nothing weird

Host Level:

We are running apache 2.4.7 on an ubuntu server and so:

  • Check virtualhosts (Default and custom) — All okay
  • Check apache logs (Access and Error) — (400 Bad request noted)

Network level:

In order to check the requests at the network level, the following tcpdump command helped

tcpdump -s 0 -A ‘tcp dst port 80 and (tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504f5354)’

  • -s 0: Don’t limit the amount of payload data that is printed out. Print it all.
  • -A: Print packets in ASCII
  • and tcp port http: Only capture HTTP packets.
  • This is where I noted difference in HTTP headers being forwarded.

As per RFC Standards:

A client MUST include a Host header field in all HTTP/1.1 request messages. An HTTP/1.1 proxy MUST ensure that any request message it forwards does contain an appropriate Host header field that identifies the service being requested by the proxy. All Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message which lacks a Host header field

Difference between POSTMan and external traffic were mainly the Host Header hence the 400 request.

After fixing the Host header we were back in business!

Back to <code>

--

--