If you run a server, you will undoubtedly get to a point where you need to nail down some network-related problems. Of course it would be easy to just shoot a mail to the support department, but sometimes you need to get your hands dirty. In this case,\u00a0tcpdump<\/code>\u00a0is the tool for that job. Tcpdump is a network packet analyzer that runs under the command line.<\/p>\n

This article will be split into three parts:<\/p>\n

\n
• Basic features.<\/li>\n
• Filtering based on certain traffic characteristics.<\/li>\n
• A short snippet of the more advanced features (such as logical expressions, filtering by TCP flags).<\/li>\n<\/ul>\n

  Since tcpdump is not included with most base systems, you will need to install it. However, nearly all Linux distributions have tcpdump in their core repositories. For Debian based distributions, the command to install tcpdump is:<\/p>\n

  apt-get install tcpdump\r\n<\/code><\/pre>\n
  For CentOS\/RedHat, use the following command:<\/p>\n
  yum install tcpdump\r\n<\/code><\/pre>\n
  FreeBSD offers a pre-built package which can be installed by issuing:<\/p>\n
  pkg install tcpdump\r\n<\/code><\/pre>\n
  There’s also a port available,\u00a0net\/tcpdump<\/code>\u00a0which can be installed via:<\/p>\n
  cd \/usr\/ports\/net\/tcpdump\r\nmake install clean\r\n<\/code><\/pre>\n
  If you run\u00a0tcpdump<\/code>\u00a0without any arguments, you’ll be be battered with results. Running it on a freshly spinned up instance here on AKLWEB Host for less than five seconds gives the following results:<\/p>\n
  2661 packets captured\r\n2663 packets received by filter\r\n0 packets dropped by kernel\r\n<\/code><\/pre>\n
  Before going into more details on how to filter input, you should take a look at some parameters that can be passed to tcpdump:<\/p>\n
  \n
  -i<\/code>\u00a0– Specifies the interface you want to listen on, for example:\u00a0tcpdump -i eth0<\/code>.<\/li>\n
  -n<\/code>\u00a0– Do not try to do reverse lookups on IP addresses, for example:\u00a0tcpdump -n<\/code>\u00a0(if you add another\u00a0n<\/code>\u00a0tcpdump will show you port numbers instead of names).<\/li>\n
  -X<\/code>\u00a0– Show the content of the collected packets:\u00a0tcpdump -X<\/code>.<\/li>\n
  -c<\/code>\u00a0– Only capture\u00a0x<\/code>\u00a0packets,\u00a0x<\/code>\u00a0being an arbitrary number, for example\u00a0tcpdump -c 10<\/code>\u00a0captures exactly 10 packets.<\/li>\n
  -v<\/code>\u00a0– Increase the amount of packet information you are shown, more\u00a0v<\/code>s add more verbosity.<\/li>\n<\/ul>\n
  Each of those parameters mentioned here can be combined together. If you wanted to capture 100 packets, but only on your VPN interface tun0, then the tcpdump command would look like this:<\/p>\n
  tcpdump -i tun0 -c 100 -X\r\n<\/code><\/pre>\n
  There are dozens (if not hundreds) of options in addition to those few, but they are the most common ones. Feel free to read tcpdump’s manpage on your system.<\/p>\n
  Now that you have a basic understanding of tcpdump, it’s time to look at one of tcpdump’s most awesome features: expressions. Expressions will make your life a lot easier. They are also known as BPF or Berkeley Packet Filters. Using expressions allows you to selectively display (or ignore) packets based on certain characteristics – such as origin, destination, size, or even TCP sequence number.<\/p>\n
  So far you’ve managed to limit your search to a certain amount of packets on a certain interface, but let’s be honest here: that still leaves too much background noise to effectively work with the collected data. That’s where expressions come into play. The concept is pretty straightforward, so we’ll leave out the dry theory here and support the understanding with some practical examples.<\/p>\n
  The expressions that you’ll probably be using the most are:<\/p>\n
  \n
  host<\/code>\u00a0– Look for traffic based on hostnames or IP addresses.<\/li>\n
  src<\/code>\u00a0or\u00a0dst<\/code>\u00a0– Look for traffic from or to a specific host.<\/li>\n
  proto<\/code>\u00a0– Look for traffic of a certain protocol. Works for tcp, udp, icmp, and others. Omitting the\u00a0proto<\/code>\u00a0keyword is also possible.<\/li>\n
  net<\/code>\u00a0– Look for traffic to \/ from a certain range of IP addresses.<\/li>\n
  port<\/code>\u00a0– Look for traffic to \/ from a certain port.<\/li>\n
  greater<\/code>\u00a0or\u00a0less<\/code>\u00a0– Look for traffic bigger or smaller than a certain amount of bytes.<\/li>\n<\/ul>\n
  While the manpage for\u00a0tcpdump<\/code>\u00a0just contains a few examples, the manpage for\u00a0pcap-filter<\/code>\u00a0has very detailed explanations on how each filter works and can be applied.<\/p>\n
  If you want to see how your communication with a certain server is going, then you can use the\u00a0host<\/code>\u00a0keyword, for example (including some of the parameters from above):<\/p>\n
  tcpdump -i eth0 host aklwebhost.com\r\n<\/code><\/pre>\n
  Sometimes there are computers on the network that don’t honor the MTU or spam you with large packets; filtering them out can be difficult sometimes. Expressions allow you to filter out packages that are bigger or smaller than a certain number of bytes:<\/p>\n
  tcpdump -i eth0 -nn greater 128\r\nor\r\ntcpdump -i eth0 -nn less 32\r\n<\/code><\/pre>\n
  Maybe only a certain port is of interest for you. In this case, use the\u00a0port<\/code>\u00a0expression:<\/p>\n
  tcpdump -i eth0 -X port 21\r\n<\/code><\/pre>\n
  You can also look out for port ranges:<\/p>\n
  tcdump -i eth0 -X portrange 22-25\r\n<\/code><\/pre>\n
  Since NAT gateways are pretty common, you may only look for destination ports:<\/p>\n
  tcpdump dst port 80\r\n<\/code><\/pre>\n
  If you are watching traffic to your web server, you may only want to look at TCP traffic to port 80:<\/p>\n
  tcpdump tcp and dst port 80\r\n<\/code><\/pre>\n
  You are probably asking yourself what the keyword\u00a0and<\/code>\u00a0is doing there. Good question. That brings us to the last part of this article.<\/p>\n
  tcpdump<\/code>\u00a0offers basic support for logical expressions, more specifically:<\/p>\n
  \n
  and<\/code>\u00a0\/\u00a0&&<\/code>\u00a0– Logical “and”.<\/li>\n
  or<\/code>\u00a0\/\u00a0||<\/code>\u00a0– Logical “or”.<\/li>\n
  not<\/code>\u00a0\/\u00a0!<\/code>\u00a0– Logical “not”.<\/li>\n<\/ul>\n
  Together with the ability to group expressions together, this allows you to create very powerful searches for incoming and outgoing traffic. So let’s filter out traffic coming from aklwebhost.com on port 22 or 443:<\/p>\n
  tcpdump -i eth0 src host aklwebhost.com and (dst port 22 or 443)\r\n<\/code><\/pre>\n
  Running this on the command line will give you the following error:<\/p>\n
  bash: syntax error near unexpected token `('\r\n<\/code><\/pre>\n
  That’s because there is a caveat:\u00a0bash<\/code>\u00a0tries to evaluate every character it can. This includes the\u00a0(<\/code>\u00a0and\u00a0)<\/code>\u00a0characters. In order to avoid that error, you should use single quotes around the combined expression:<\/p>\n
  tcpdump -i eth0 'src host aklwebhost.com and (dst port 22 or 443)'\r\n<\/code><\/pre>\n
  Another useful example: When debugging SSH issues with one of your users, you may want to ignore everything that’s related to your SSH session:<\/p>\n
  tcpdump '!(host $youripaddress) && port 22)'\r\n<\/code><\/pre>\n
  Again, the use cases are endless, and you can specify into extreme depths what kind of traffic that you want to see. The following command would show you only SYNACK packets of a TCP handshake:<\/p>\n
  tcpdump -i eth0 'tcp[13]=18'\r\n<\/code><\/pre>\n
  This works by looking at the thirteenth offset of the TCP header and the eighteenth byte within it.<\/p>\n
  If you made it all the way here, then you are ready for most use cases that will arise. I can barely touch the surface without going into too many details. I highly recommend that you experiment with the different options and expressions a bit further; and as usual: reference the manpage when you get lost.<\/p>\n
  Last but not least – a quick look back. Remember the beginning of this article? With the thousands of packets captured in a matter of seconds? The power of\u00a0tcpdump<\/code>\u00a0can trim that down a whole lot:<\/p>\n
  tcpdump -i eth0 tcp port 22\r\n<\/code><\/pre>\n
  The result is now:<\/p>\n
  81 packets captured\r\n114 packets received by filter\r\n0 packets dropped by kerne\r\n<\/code><\/pre>\n
  This is much saner and easier to debug. Happy networking!<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"open","ping_status":"closed","template":"","format":"standard","manualknowledgebasecat":[242,244],"manual_kb_tag":[439],"_links":{"self":[{"href":"https:\/\/support.aklwebhost.com\/wp-json\/wp\/v2\/manual_kb\/2874"}],"collection":[{"href":"https:\/\/support.aklwebhost.com\/wp-json\/wp\/v2\/manual_kb"}],"about":[{"href":"https:\/\/support.aklwebhost.com\/wp-json\/wp\/v2\/types\/manual_kb"}],"author":[{"embeddable":true,"href":"https:\/\/support.aklwebhost.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/support.aklwebhost.com\/wp-json\/wp\/v2\/comments?post=2874"}],"version-history":[{"count":2,"href":"https:\/\/support.aklwebhost.com\/wp-json\/wp\/v2\/manual_kb\/2874\/revisions"}],"predecessor-version":[{"id":2876,"href":"https:\/\/support.aklwebhost.com\/wp-json\/wp\/v2\/manual_kb\/2874\/revisions\/2876"}],"wp:attachment":[{"href":"https:\/\/support.aklwebhost.com\/wp-json\/wp\/v2\/media?parent=2874"}],"wp:term":[{"taxonomy":"manualknowledgebasecat","embeddable":true,"href":"https:\/\/support.aklwebhost.com\/wp-json\/wp\/v2\/manualknowledgebasecat?post=2874"},{"taxonomy":"manual_kb_tag","embeddable":true,"href":"https:\/\/support.aklwebhost.com\/wp-json\/wp\/v2\/manual_kb_tag?post=2874"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}