|
| 1 | +# cf-pcap |
| 2 | + |
| 3 | +## Enable the feature platform wide |
| 4 | + |
| 5 | +Set the rep property `diego.rep.enable_cf_pcap` to true (defaults to false) and |
| 6 | +re-deploy diego. |
| 7 | + |
| 8 | +This will set a file capability on the cf-pcap binary which is always inside the |
| 9 | +app container to allow the binary to perform packet captures. |
| 10 | + |
| 11 | +## Usage |
| 12 | + |
| 13 | +<!-- TODO: fix path --> |
| 14 | +The binary is placed in `/etc/cf-assets/...` and can be executed by any regular |
| 15 | +user. Invoking the binary will cause it to emit raw pcap on stdout which can |
| 16 | +mess up your terminal so make sure to redirect it into a file. The accepted |
| 17 | +parameters are: |
| 18 | + |
| 19 | +* `-interface`: the network interface on which to capture (usually `lo` or |
| 20 | + `eth0`). |
| 21 | +* `-snaplen`: how many bytes to capture of each packet. |
| 22 | +* `-filter`: pcap-filter to specify which packets to capture. |
| 23 | +* `-v`: more verbose output. |
| 24 | + |
| 25 | +## Notes in network traffic in app containers |
| 26 | + |
| 27 | +When envoy is enabled, all traffic passes through both interfaces in the app |
| 28 | +container. First, envoy receives it on `eth0` and terminates TLS, then it |
| 29 | +forwards the traffic to the app via the `lo` device in plain text. For SSH |
| 30 | +traffic the same thing happens, but envoy won't terminate the SSH encryption. |
| 31 | + |
| 32 | +To avoid capturing the SSH traffic which contains the just captured bytes, thus |
| 33 | +indefinitely capturing the same content over and over again, cf-pcap will try to |
| 34 | +determine the correct port to filter out. This is done on a best-effort basis |
| 35 | +and failure to determine the correct filter will not stop the capture from |
| 36 | +happening. |
| 37 | + |
| 38 | +## Capturing traffic locally |
| 39 | + |
| 40 | +SSH into the app instance you would like to capture traffic from. To capture the |
| 41 | +plain-text HTTP traffic for an app listening on port 8080 you specify the |
| 42 | +loopback interface and filter for TCP traffic on port 8080. Once you've copied |
| 43 | +the file to your local machine you can print out the captured traffic your |
| 44 | +tcpdumps `-r` to read form a previous capture file: |
| 45 | + |
| 46 | +<!-- TODO: correct paths and output --> |
| 47 | +``` |
| 48 | +$ cf ssh $app |
| 49 | +vcap@app $ cf-pcap -interface lo -filter "tcp port 8080" > capture01.pcap |
| 50 | +... |
| 51 | +^C |
| 52 | +... |
| 53 | +vcap@app $ ^D |
| 54 | +$ scp $app:capture01.pcap . |
| 55 | +$ tcpdump -Xr capture01.pcap |
| 56 | +``` |
| 57 | + |
| 58 | +## Capturing traffic remotely |
| 59 | + |
| 60 | +Similar to the local capture, you start cf-pcap with the details on what you |
| 61 | +want to capture but this time wrap it in the `-c` of cf-ssh. This will send the |
| 62 | +pcap output to stdout and you can redirect the content to a local file. |
| 63 | +Afterwards, you can again use tcpdumps `-r` to inspect the content: |
| 64 | + |
| 65 | +``` |
| 66 | +cf ssh $app -c "cf-pcap -interface lo -filter 'tcp port 8080'" > capture02.pcap |
| 67 | +... |
| 68 | +^C |
| 69 | +... |
| 70 | +$ tcpdump -Xr capture02.pcap |
| 71 | +``` |
0 commit comments