tcpdump is amazing (2016)(jvns.ca)
jvns.ca
tcpdump is amazing (2016)
https://jvns.ca/blog/2016/03/16/tcpdump-is-amazing/
86 comments
It is especially great, because it allows fast analytics on historical data with ClickHouse: https://www.ntop.org/ntop/historical-traffic-analysis-at-sca...
Their website says it's GPL but I ran into some issue the last time I tried to try it out, it wanted a paid proprietary license or something?
Kind of an unfortunate name. At first I thought it was "NToPNG" and was slightly confused.
Highly recommend documentation by F5 it's a goldmine, e.g.
K2289: Using advanced tcpdump filters https://support.f5.com/csp/article/K2289
K2289: Using advanced tcpdump filters https://support.f5.com/csp/article/K2289
Shoutout to the lesser-known tcpflow, which reassembles the complete contents of a TCP connection by paying attention to sequence numbers. Very handy!
I used tcpflow extensively about 17 jobs ago. I had a Linux box on a hub segment with Windows servers running a .NET application, used for realtime capture and monitoring application traffic in a test environment. I had an independent implementation of the framing protocol and message format written in Ruby, and if my decoder choked, then it was either my problem or their problem. Early on, it was always my problem, but after about 6 weeks, it was their problem 70% of the time. Great way to uncover subtle bugs, at the upfront cost of a 2nd independent implementation.
> I mentioned really briefly that tcpdump lets you save pcap files. This is awesome because literally every network analysis tool in the universe understands pcap files. pcap files are like freshly baked chocolate chip cookies. Everybody loves them.
OMG, yes, very well put. When I get a bug report with a pcap file I'm happy because I know I'll be able to see exactly what happened.
Speaking of which: for one of my libraries, I want to make a diagnostic tool that replays an interaction. My library mostly operates at the TCP level (also some UDP), so I need to reconstruct the TCP flows in my tool to feed to my library. Either I need an easy-to-use Rust library to do that directly from pcap files [1] or some format that represents bytes moving over the flow (like sets of lines with a timestamp, flow id, and pretty hexdump of the bytes) with a tool that produces it from pcap. This seems like something that should exist? Wireshark's "Analyze > Follow > TCP Stream"’s "Save As…", "entire stream", "hex dump" is kind of what I want, but it doesn't have timestamps, and it doesn't have a way to put everything (multiple flows, UDP packets also) in one file. Seems like there should be something under "Export Packet Dissections" [2] but I haven't found quite the right thing there either.
[1] https://crates.io/crates/pnet looks promising but it wasn't as obvious as I hoped how to plug it in for what I want.
[2] https://www.wireshark.org/docs/wsug_html_chunked/ChIOExportS...
OMG, yes, very well put. When I get a bug report with a pcap file I'm happy because I know I'll be able to see exactly what happened.
Speaking of which: for one of my libraries, I want to make a diagnostic tool that replays an interaction. My library mostly operates at the TCP level (also some UDP), so I need to reconstruct the TCP flows in my tool to feed to my library. Either I need an easy-to-use Rust library to do that directly from pcap files [1] or some format that represents bytes moving over the flow (like sets of lines with a timestamp, flow id, and pretty hexdump of the bytes) with a tool that produces it from pcap. This seems like something that should exist? Wireshark's "Analyze > Follow > TCP Stream"’s "Save As…", "entire stream", "hex dump" is kind of what I want, but it doesn't have timestamps, and it doesn't have a way to put everything (multiple flows, UDP packets also) in one file. Seems like there should be something under "Export Packet Dissections" [2] but I haven't found quite the right thing there either.
[1] https://crates.io/crates/pnet looks promising but it wasn't as obvious as I hoped how to plug it in for what I want.
[2] https://www.wireshark.org/docs/wsug_html_chunked/ChIOExportS...
Now I know that some people get pcap files with bug report and I'm jealous
Does that help? I don't want to replay the packets on a network. Instead, I want to feed them to my library without having to deal with reconstructing the TCP stream from the packets myself. I don't see anything for that in that suite.
tcpflow (mentioned in another thread here) seems much closer in that it does reconstruct TCP flows from pcap, but it doesn't timestamp stuff (it'd be nice to have an idea if some client->server data or some server->client data came first as well as just relate to timeouts), and I'd prefer to put everything in one file (both directions of TCP data, UDP packets).
Maybe I "just" need to figure out that Rust library I mentioned in the grandparent, and maybe create my own intermediate format that has just the data I want for my library. (I can discard TCP retransmissiony stuff, MACs, etc. to focus on what a library sees through the kernel socket interfaces.)
tcpflow (mentioned in another thread here) seems much closer in that it does reconstruct TCP flows from pcap, but it doesn't timestamp stuff (it'd be nice to have an idea if some client->server data or some server->client data came first as well as just relate to timeouts), and I'd prefer to put everything in one file (both directions of TCP data, UDP packets).
Maybe I "just" need to figure out that Rust library I mentioned in the grandparent, and maybe create my own intermediate format that has just the data I want for my library. (I can discard TCP retransmissiony stuff, MACs, etc. to focus on what a library sees through the kernel socket interfaces.)
tcpflow stores all captured data in files that have names of the form:
[timestampT]sourceip.sourceport-destip.destport[--VLAN][cNNNN]
where: timestamp is an optional timestamp of the time that the first packet was seen
.B t
Prepends each filename with a Unix timestamp (seconds since epoch).
.B T
Prepends each filename with an ISO-8601 timestamp.tcpdump is the kind of tool I'm glad is in my toolbox, but I hate when I have to get it out. Not because it's hard to use, and this article / Julia does a great a job at explaining the basics, but every time I've had to use it in the past was because something was really wrong and none of the partner teams I've had to work with either knew how to troubleshoot or had the tools to do it. If you run any kind of network connected infra, it's worth the investment in learning how tcpdump and Wireshark work.
I've realised this recently reading various stories about what seem like amazing debug stories but boiled down to understanding how to use tcpdump or wireshark or some other profiling/logging tool but they are amazing because most devs simply don't know how to use them (or even if to use them).
This is probably part of the reason why Google is super fast and most software is super slow.
Same for IT teams. I should be able to assume that any answer to a network question includes the relevant info from the wireshark trace not just, "I can't see anything wrong with it"!
This is probably part of the reason why Google is super fast and most software is super slow.
Same for IT teams. I should be able to assume that any answer to a network question includes the relevant info from the wireshark trace not just, "I can't see anything wrong with it"!
It's not even that the best debug stories boil down to understanding and using tcpdump, but there's a real, giant divide between people who know how to troubleshoot and those who don't. Slinging code is relatively easy if you know the language, but odds are your app talks to a database, or makes a web call, or uses memory, and knowing how you interact at that layer is the difference between good and bad experiences, and uptime or not when things fail. I'm no electrician, but I know how to check my circuit box when something in my house won't power on, and then how to swap power cables, etc.
absolutely. the tcpdump is as simple as possible and no simpler.
Is there a way to place the BPF filter after IP packet reassembly?
Otherwise, matching for TCP port, etc. fails to capture fragments which do not have the TCP header and the resulting file is missing some data.
Otherwise, matching for TCP port, etc. fails to capture fragments which do not have the TCP header and the resulting file is missing some data.
TCP tries really hard to avoid fragmentation, by setting the DF flag and reducing the MSS when it sees a PTB error.
Of course that sometimes fails, so if you still have TCP fragmented segments, the next best thing is to filter by source/destination address, saving to a PCAP file, then run tshark on that file with the "-2" flag which does packet reassembly.
(I don't know if tshark can be made to do on-the-fly reassembly, that would require keeping a buffer of un-reassembled fragments until the rest of the packets are seen.)
Of course that sometimes fails, so if you still have TCP fragmented segments, the next best thing is to filter by source/destination address, saving to a PCAP file, then run tshark on that file with the "-2" flag which does packet reassembly.
(I don't know if tshark can be made to do on-the-fly reassembly, that would require keeping a buffer of un-reassembled fragments until the rest of the packets are seen.)
I'm not sure, but you can probably just capture all ip fragments and do a second pass with something later?
When I was running a webserver with worldwide audience and 40+ Gbps traffic (most of that was our apk though), I saw no more than a couple fragments per second; unless there was some UDP reflection DDoS going on and I was getting fragments from that.
Lots of high profile sites don't even accept ip fragmentation because it's too costly to deal with.
When I was running a webserver with worldwide audience and 40+ Gbps traffic (most of that was our apk though), I saw no more than a couple fragments per second; unless there was some UDP reflection DDoS going on and I was getting fragments from that.
Lots of high profile sites don't even accept ip fragmentation because it's too costly to deal with.
The direct answer to your question is "no", because tcpdump isn't stateful. It reads fragments one at a time, prints them, and forgets about them.
Obligatory advice that you shouldn't run tcpdump, tshark or wireshark as root or with sudo. Instead, set up least privileges (e.g. with capabilities) or at least use the tcpdump flag `-Z` (may be enabled by default at compile time in your distribution). Debian has a group called "wireshark" for this use case by default.
Why is that?
These other responses are great justification to always dig into what someone's threat model is. I've had so many "security" conversations get resolved something like this:
other dev: this is insecure
me: what's your threat model?
other dev: <convoluted, opportunistic-only highly-timing-sensitive scenario that assumes attacker has gained internal network access>
me: you do realize all our boxes have an "admin:password"-esque standard login available and passwordless sudo. if they're on our network they can already just do basically anything.
People (well, devs) love to think about security in very fine-grained detail, and honestly that's good. We should all be thinking about this. But your security is only as good as your weakest link, and when your security policy already literally codifies "we will trust the firewall to make intranet security less annoying/complicated" then unless you want to go change that or your threat model is describing an attack on that security model, then please don't try to get overly clever.
Now - that said - I do wish more orgs just did defense-in-depth from the beginning. It's so easy to provision certs nowadays that there's almost no reason not to do mTLS etc even in something like a homelab setting.
other dev: this is insecure
me: what's your threat model?
other dev: <convoluted, opportunistic-only highly-timing-sensitive scenario that assumes attacker has gained internal network access>
me: you do realize all our boxes have an "admin:password"-esque standard login available and passwordless sudo. if they're on our network they can already just do basically anything.
People (well, devs) love to think about security in very fine-grained detail, and honestly that's good. We should all be thinking about this. But your security is only as good as your weakest link, and when your security policy already literally codifies "we will trust the firewall to make intranet security less annoying/complicated" then unless you want to go change that or your threat model is describing an attack on that security model, then please don't try to get overly clever.
Now - that said - I do wish more orgs just did defense-in-depth from the beginning. It's so easy to provision certs nowadays that there's almost no reason not to do mTLS etc even in something like a homelab setting.
This isn't a convoluted, timing-sensitive scenario; it's more like, there is the possibility that if you have tcpdump running anywhere, an attacker can strobe a packet that will trip a memory corruption vulnerability in some tcpdump printer, which is not, like, out of the realm of possibility.
These tools are parsing untrusted input (tshark and wireshark are parsing a very large number of different protocols), and considering these are all written in a memory unsafe language (C), they are at a high risk of remote command execution vulnerabilities. And since they don't actually require root permissions, just permission to access raw sockets and a few other network related things, it's simply best practices to use as little privileges as possible and only as much as necessary.
While the principle itself is sound, this is seriously exaggerating the threat. I mean sure the tools are written in C, but so is your whole network stack.
Have your prod boxes set up with proper permissions for sure but there's hardly a practical risk doing this in dev/testing.
Have your prod boxes set up with proper permissions for sure but there's hardly a practical risk doing this in dev/testing.
I find it even more convenient to just add my user account to the correct group. Now I can call tcpdump anytime without having to invoke sudo. I get more security and convenience at the same time, so why not do it? I recommend giving the nmap binary the right capabilities for exactly the same reason.
Sure, the attack surface of tcpdump is much smaller than wireshark, so the issue is not as pronounced, but wireshark indeed had a lot of vulnerabilities in the past: https://www.cvedetails.com/vulnerability-list/vendor_id-4861...
It has tons of dissectors which aren't nearly as battle tested as my network stack.
Sure, the attack surface of tcpdump is much smaller than wireshark, so the issue is not as pronounced, but wireshark indeed had a lot of vulnerabilities in the past: https://www.cvedetails.com/vulnerability-list/vendor_id-4861...
It has tons of dissectors which aren't nearly as battle tested as my network stack.
I agree in theory, but on my personal machine (and probably most other peoples' machines) all the interesting things are accessible by my account anyway. I'm not worried about malware changing my system configuration, I'm worried about a trojan stealing my passwords, keylogger watching what I type, stealer exfiltrating my data, or ransomware encrypting it. All of these don't really need a root account. Maybe the solution would be to use `sudo -u safe_tcpdump_user tcpdump`?
I'm also going to add that I have passwordless sudo, so there's no meaningful difference in my case.
I'm also going to add that I have passwordless sudo, so there's no meaningful difference in my case.
Root escalation was kinda Big Deal in the days of multi-user systems and cohosting. Now I think it's mostly important in the context of breaking out from unprivileged services that would normally have no access to broader filesystem.
[deleted]
Weird security posture to be advertising to the world when two clicks gets me your first and last name
Assuming you care about infosec from your profile, privilege escalation is definitely something you want to avoid especially if you're using these tools in for example a CTF engagement where the first thing I'll be doing is enumerating my adversaries
Assuming you care about infosec from your profile, privilege escalation is definitely something you want to avoid especially if you're using these tools in for example a CTF engagement where the first thing I'll be doing is enumerating my adversaries
tcpdump is risky because it parses (way, way) more protocols than your network stack does, and because tcpdump's parsers are tooling-grade code, not kernel network code.
I mean yes it's relatively more risky but no it's not risky enough for me to not do occasional sudo tcpdump -X on an unconfigured machine in a problematic spot. The risk of me getting targeted by tcpdump zero-day while diagnosing some UDP broadcast problem on a LAN is diminutively low. Your situation is likely very different.
No, I mean, I generally agree, it's not high on my list of threat vectors, but the general advice to be mindful about a giant memory-unsafe blob of tooling-grade protocol parsers written by hundreds of different people over 3 decades seems astute.
Tcpdump is a unique codebase, has its own flaws/issues, and most certainly can be vulnerable, even if the overall stack is not.
Run nothing as root, unless absolutely required. And this had nothing to do with C or rust, running rust based software, any software as root, when not required,is unnecessary, and risky as well.
Nothing is safe. Behave that way, or you do your oeg, and yourself, wrong. And its not OK to treat a dev env as fine to get compromised.
Many orgs get borked by someone taking over dev machines, or infra, and sliding in that way.
Run nothing as root, unless absolutely required. And this had nothing to do with C or rust, running rust based software, any software as root, when not required,is unnecessary, and risky as well.
Nothing is safe. Behave that way, or you do your oeg, and yourself, wrong. And its not OK to treat a dev env as fine to get compromised.
Many orgs get borked by someone taking over dev machines, or infra, and sliding in that way.
I think the point is that so what if you don't run these tools as root?
If a malicious actor compromises your normal user account, they can also compromise your configuration files and alias sudo or set up a keylogger or do all kinds of nasty stuff.
Going from standard user to root isn't much of a challenge for all but the most minimal infections in almost every standard setup for common Linux distributions.
Malicious hackers don't need anything other than your current user permissions anyway; your API/ssh keys/crypto wallets are all stored in your home directory or other places a malicious program can get access to.
There are exceptions, but I very much doubt that most people develop on QubesOS levels of Linux security.
There is no practical antivirus software on Linux that will catch anyone sophisticated enough to exploit tcpdump. You need a LOT of know-how to run a "safe" Linux system that you're more likely to learn as a sysadmin than as a developer. Security is hard, especially on the Linux desktop, and it will be as long as attempts to add it are met with responses like "they're trying to take our freedom away".
Common internet resources aren't much better ("just disable selinux") and current solutions for usability problems in this space (i.e. sandboxed applications not being able to access the directories you chose because they don't correspond to what the dev expected) aren't very great either.
I definitely think we should use the resources for secure desktop computing that we do have, which includes running tshark and friends at the lowest level of privilege possible, but I can definitely understand why people ask "why should I bother" when most of their setup runs at Windows XP levels of security out of the box.
If a malicious actor compromises your normal user account, they can also compromise your configuration files and alias sudo or set up a keylogger or do all kinds of nasty stuff.
Going from standard user to root isn't much of a challenge for all but the most minimal infections in almost every standard setup for common Linux distributions.
Malicious hackers don't need anything other than your current user permissions anyway; your API/ssh keys/crypto wallets are all stored in your home directory or other places a malicious program can get access to.
There are exceptions, but I very much doubt that most people develop on QubesOS levels of Linux security.
There is no practical antivirus software on Linux that will catch anyone sophisticated enough to exploit tcpdump. You need a LOT of know-how to run a "safe" Linux system that you're more likely to learn as a sysadmin than as a developer. Security is hard, especially on the Linux desktop, and it will be as long as attempts to add it are met with responses like "they're trying to take our freedom away".
Common internet resources aren't much better ("just disable selinux") and current solutions for usability problems in this space (i.e. sandboxed applications not being able to access the directories you chose because they don't correspond to what the dev expected) aren't very great either.
I definitely think we should use the resources for secure desktop computing that we do have, which includes running tshark and friends at the lowest level of privilege possible, but I can definitely understand why people ask "why should I bother" when most of their setup runs at Windows XP levels of security out of the box.
> Malicious hackers don't need anything other than your current user permissions anyway; your API/ssh keys/crypto wallets are all stored in your home directory or other places a malicious program can get access to.
I mean, are you really running tcpdump on your local computer? I imagine you would be running it on the server you are trying to debug. So the security setup would plausibly be a bit different than that.
But generally i agree. Good practise not to run things as root, especially this type of tooling, but its not exactly putting your private key into a public git repo level of insecurity by any means.
I mean, are you really running tcpdump on your local computer? I imagine you would be running it on the server you are trying to debug. So the security setup would plausibly be a bit different than that.
But generally i agree. Good practise not to run things as root, especially this type of tooling, but its not exactly putting your private key into a public git repo level of insecurity by any means.
> I mean, are you really running tcpdump on your local computer?
I did several times when I needed to debug or record some traffic because I couldn't figure out why some application wasn't communicating right. Wireshark quickly got overwhelmed with packets so I used tcpdump instead.
I'm most likely running tcpdump on (near) production servers because it's often a tool of last result, but sometimes it's just the right tool for the job (or just as good a tool as the fancier ones, and why not stick to the universal solution?).
I did several times when I needed to debug or record some traffic because I couldn't figure out why some application wasn't communicating right. Wireshark quickly got overwhelmed with packets so I used tcpdump instead.
I'm most likely running tcpdump on (near) production servers because it's often a tool of last result, but sometimes it's just the right tool for the job (or just as good a tool as the fancier ones, and why not stick to the universal solution?).
> Run nothing as root, unless absolutely required.
Good advice, to be sure. Especially anything getting network input[1].
In a reddit thread once, I pointed out that there is no need for any server/service program to have any access to the file holding the startup configuration. There really isn't.
If the user needs to write that configuration, use a different program with elevated privileges that do nothing but write that file.
When the server starts up and needs to read config, it should start up as a user with elevated privileges, read the entire file in the first 3 lines of `main()`, then drop privileges and continue execution as normal. It will never be able to access that file during the rest of its execution.
I don't think I've ever had a comment downvoted on reddit so hard!
[1] No need to say "untrusted network input" - all input is untrusted unless you are literally in control of both parties.
Good advice, to be sure. Especially anything getting network input[1].
In a reddit thread once, I pointed out that there is no need for any server/service program to have any access to the file holding the startup configuration. There really isn't.
If the user needs to write that configuration, use a different program with elevated privileges that do nothing but write that file.
When the server starts up and needs to read config, it should start up as a user with elevated privileges, read the entire file in the first 3 lines of `main()`, then drop privileges and continue execution as normal. It will never be able to access that file during the rest of its execution.
I don't think I've ever had a comment downvoted on reddit so hard!
[1] No need to say "untrusted network input" - all input is untrusted unless you are literally in control of both parties.
This would add complexity and in particular couple the application to a specific combination of operating system/privileges model/file system. How great is the benefit, really? How many things are exploited by the application writing to its own startup config?
> This would add complexity
It would add fair bit of code, sure, but nicely isolated and not complex: It's three extra lines of code in the main function, and a separate utility to write the config.
Balance that against the fact that the server then never writes its own config - that code is moved into the configuration-writing application, which removes complexity from the server application.
> and in particular couple the application to a specific combination of operating system/privileges model/file system.
It does indeed couple it to those systems that are sufficiently POSIX-like; however if you are writing a server that doesn't run on a Linux or BSD-derived system, you are out in the left field anyway.
> How great is the benefit, really? How many things are exploited by the application writing to its own startup config?
Well, the comment I made was in a thread discussing a vulnerability in the Microsoft Teams application[1] which was exploitable to retrieve the user's secrets[2] from their config file.
So, that particular comment was very much on-topic and in-context.
[1] Not sure if it was on all platforms or not.
[2] Or something - I forget exactly what was leaked.
It would add fair bit of code, sure, but nicely isolated and not complex: It's three extra lines of code in the main function, and a separate utility to write the config.
Balance that against the fact that the server then never writes its own config - that code is moved into the configuration-writing application, which removes complexity from the server application.
> and in particular couple the application to a specific combination of operating system/privileges model/file system.
It does indeed couple it to those systems that are sufficiently POSIX-like; however if you are writing a server that doesn't run on a Linux or BSD-derived system, you are out in the left field anyway.
> How great is the benefit, really? How many things are exploited by the application writing to its own startup config?
Well, the comment I made was in a thread discussing a vulnerability in the Microsoft Teams application[1] which was exploitable to retrieve the user's secrets[2] from their config file.
So, that particular comment was very much on-topic and in-context.
[1] Not sure if it was on all platforms or not.
[2] Or something - I forget exactly what was leaked.
most methods of getting persistence involve writing to some config file somewhere. Having your app not have rights to write to any sort of config or code files probably is fairly beneficial.
How much is probably going to depends on how everything is configured, what your threat model is, what service it is, and a million other things.
How much is probably going to depends on how everything is configured, what your threat model is, what service it is, and a million other things.
Interesting idea, I quite like it. At the same time we have things like kubernetes, where most people store secrets in the environment variables that every single process in the container can read.
This is what HAProxy does. At least the reading then dropping privileges. The admin writes the config themselves (or uses their own tool).
At the defcon ctf in 2016(?) One of the teams used a Wireshark 0day to pwn another team and see/use all of their flags.
tell me more
Sometimes when no other options exist, and I need to capture untrusted traffic as root, I use 'tcpdump -i eth0 -s0 -n -w some.pcap' to save the packets to a .pcap. Just recording the frames shouldn't (invoke any parsing code although I have never actually checked). Then I open the .pcap with wire/tshark or even tcpdump in some safer sandbox.
You can also send the pcap to stdout and pipe it to stdin of a tshark running as non-root. And if you provide the right capture filters on tcpdump you can even have the tcpdump in an ssh session piping to a local tshark so you don’t even have to have tshark on the server.
Wireshark is also able to capture traffic of remote interfaces over ssh.
I was delighted when I discovered that you can also pipe stdin into Wireshark (GUI). I've not seen a lot of GUI applications that support this flow.
e.g.
e.g.
> wireshark -k -i <(ssh -l root remote-host "dumpcap -P -w - -f 'not tcp port 22'")
I prefer a ‘not host <x>’ filter using info found in $SSH_CONNECTION to filtering all port 22 out, but yeah, good stuff.
You’re parsing untrusted input. Doing it with the smallest set of privileges possible seems like a common sense thing to do.
Quick reference to add permissions: https://wiki.archlinux.org/title/Wireshark#Capturing_privile...
On FreeBSD, tcpdump runs with Capsicum, which may be sufficient sandboxing.
So you're just gonna make a claim and pretend you don't need to give a reason why?
You don't need wireshark to view packet data, use -X and -XX
this is my favorite use of tcpdump, as a "just show me basic prints" live version of wireshark, which is like 90% of the time mostly what I want. Usually when I'm debugging stuff and am reaching for wireshark/tcpdump, I'm mostly just trying to figure out if traffic is hitting the right ports at all, and then only sometimes do I even care about metadata (packet size / count etc) and it's very rare I care about actual payload (not that you can even usually see it easily nowadays anyway since everything is TLS).
recent example: used tcpdump -X to debug why my wireguard setup wasn't working, since with UDP you just kind of get a shrug as to why or at what hop the udp packet got lost or filtered. So I ssh'd to all the middle boxes and just tcpdumped the UDP ports I was interested in.
recent example: used tcpdump -X to debug why my wireguard setup wasn't working, since with UDP you just kind of get a shrug as to why or at what hop the udp packet got lost or filtered. So I ssh'd to all the middle boxes and just tcpdumped the UDP ports I was interested in.
Yeah but it's pretty useless for tracking what https requests get made or pretty much anything that uses encryption. You can filter by https GET requests but you won't be able to see what's inside them.
I wrote about how I decrypt TLS streams in Wireshark for debugging purposes here: https://www.benburwell.com/posts/intercepting-golang-tls-wit...
It won't apply to every situation, but might provide some building blocks you can adapt to your environment.
It won't apply to every situation, but might provide some building blocks you can adapt to your environment.
you shouldn't even be able to see the method (GET/POST etc.) as that is inside the encrypted TLS body. You will be able to see timings and approximate sizes, as well as potentially the hostname from the SNI but that's about it.
SSLKEYLOGFILE can help.
Also SSLDump [1]
[1] - https://linux.die.net/man/1/ssldump
[1] - https://linux.die.net/man/1/ssldump
Sure, but https is not the only protocol. tcpdump is also pretty useless at debugging OpenGL.
https is only one protocol. There are hundreds or thousands of other protocols that tcpdump works fine with. Some of these protocols are underneath https, including tcp, which is in the name of the tool. So while tcpdump may not function as a tlsdump and can't see into your tls connection, it does a lot of other things great.
You may as well complain that your screwdriver is no good for cutting wood. Clearly you need a different tool.
https is only one protocol. There are hundreds or thousands of other protocols that tcpdump works fine with. Some of these protocols are underneath https, including tcp, which is in the name of the tool. So while tcpdump may not function as a tlsdump and can't see into your tls connection, it does a lot of other things great.
You may as well complain that your screwdriver is no good for cutting wood. Clearly you need a different tool.
i used to use tcpdump all of the of time for local development.
with everything moving to https, sometimes even local environments, it's basically been useless now however.
with everything moving to https, sometimes even local environments, it's basically been useless now however.
You know what else is neat? netsh on windows. Let's you do circular size limited packet captures and associate every packet with the originating/destination process.
But yes, tcpdump and strace/ltrace are the ultimate tool for "I have no idea what the problem is, let me find out exactly what is happening" when troubleshooting.
But yes, tcpdump and strace/ltrace are the ultimate tool for "I have no idea what the problem is, let me find out exactly what is happening" when troubleshooting.
I used to use netsh to capture on Windows boxes but the workflow for getting the data into pcap format was awful. Lately I’ve been using RawCap[0]. It’s a single EXE that works on stock versions of Windows and produces pcap files. It has no capture-time filtering options, which is a bummer, but it’s quicker for me to get data to look at than the netsh / convert to pcap workflow.
[0] https://www.netresec.com/?page=Blog&month=2020-01&post=RawCa...
[0] https://www.netresec.com/?page=Blog&month=2020-01&post=RawCa...
> tcpdump and strace/ltrace are the ultimate tool for "I have no idea what the problem is, let me find out exactly what is happening" when troubleshooting.
And the ability to do that type of troubleshooting when the shit hits the fan is becoming more and more rare. I regularly run into devs, even so-called “senior” devs, these days who don’t know how it’s useful to look at packets or system calls and whose minds are blown that anyone would know details that far down the stack. It would be depressing if it wasn’t so good for job security.
And the ability to do that type of troubleshooting when the shit hits the fan is becoming more and more rare. I regularly run into devs, even so-called “senior” devs, these days who don’t know how it’s useful to look at packets or system calls and whose minds are blown that anyone would know details that far down the stack. It would be depressing if it wasn’t so good for job security.
Packet capture on Linux has something that I wish I could get in more systems: kernel timestamping. This increases the accuracy of the timestamps a lot, since you lose the context switch to userspace.
I wish the same thing was available for i2c and uart reads, for example.
I wish the same thing was available for i2c and uart reads, for example.
I used tcpdump a fair bit, with -T rtp, to pull our RTP sequence numbers, which I could then look for any discontinuities.
It's a great way of finding shitty network devices like Juniper SRXs which just randomly and silently drop packets in the middle of flows.
It's a great way of finding shitty network devices like Juniper SRXs which just randomly and silently drop packets in the middle of flows.
Discussed at the time:
Tcpdump is amazing - https://news.ycombinator.com/item?id=11302992 - March 2016 (102 comments)
Tcpdump is amazing - https://news.ycombinator.com/item?id=11302992 - March 2016 (102 comments)
[deleted]
I recently discovered netsniff-ng and it's really great too. It seems to recognize more protocols than tcpdump, like PTP. I use them both now.
What's the [Berke]?
I suppose it should be a link to some resource about Berkeley Packet Filters (https://en.m.wikipedia.org/wiki/Berkeley_Packet_Filter).
I'd imagine it's the Berkeley Packet Filter which underpins tcpdump, but he got distracted half way through?
Filter rules syntax is here:
https://biot.com/capstats/bpf.html
Filter rules syntax is here:
https://biot.com/capstats/bpf.html
tcpdump is amazing. Question though; does anyone know why an ACK flag is displayed as a . instead of as A? I've not been able to find the reason for that.
Probably because it would be visually noisy to do anything else, since ACK is set on almost every segment.
Seems like OP fell in love with tshark
What a nice coincidence - I used it for debugging a UDP connection earlier today.
> sudo tcpdump -n udp port 8125 -v -X -i lo
> sudo tcpdump -n udp port 8125 -v -X -i lo
Edit: Forgot the nprobe [2] (same author), allowing flow data creation and export, expecially where L3 flow capable devices are not usable (e.g. intra-VLAN)
[1] https://www.ntop.org/products/traffic-analysis/ntop/
[2] https://www.ntop.org/products/netflow/nprobe/