9 ms·

Gosniff: A TUI-Based Tcpdump

102 points by gojiberries 4y ago

bakul 4y ago
Looks pretty good! Some suggestions: it should support tcpdump's command line arguments and start with them as defaults. It would be neat if packets from different interfaces can be shown in different windows.
accrual 4y ago
I like how each packet is broken out into layers. Would be helpful for learning about new protocols on the wire.
- tptacek 4y ago
  This, for what it's worth, is a side-effect of using gopacket, which is a deceptively powerful library. You essentially have a big chunk of `tcpdump`'s encoding available to you any time you're working with packet buffers in Go, because of that library; for instance, to debug our BPF-based UDP stuff, there's an interface that shuttles packet snapshots over perf buffers and about 30 lines of Go code to read and decode those buffers. I was surprised at how much I got "for free" just by importing gopacket. It's great, more people should do cool stuff with it.
T3OU-736 4y ago
Neat project. How does it compare to Wireshark' console cousin tshark?
- tptacek 4y ago
  Once nice thing about this is that it's memory-safe, which is something you really want for a packet capture tool.
  - T3OU-736 4y ago
    Hrm. Interesting point. There have been a fair number of parser CVEs, but GoLang isn't immune to some of the (based on an admittedly cursory look) parser issues.
    - tptacek 4y ago
      A protocol analyzer implemented in anything short of formally-verified code is going to be "vulnerable" to logic errors, such that it might print (or not print) the wrong things. But a protocol analyzer implemented in C standard a decent chance of coughing up RCE.
      - T3OU-736 4y ago
        (Playing devil's advocate): What would the RCE accomplish? "Parse this packet and get a reverse shell on analyst's workstation?" To be clear: I am not in any way attempting to disparage the project. It is damned cool, and as a neophyte Go practitioner myself, I very much appreciate its existance and utility. Just working through all the edge cases :)
        tptacek 4y ago
        Yes, that's what it would accomplish.
        jpalomaki 4y ago
        I assume one reason for these console versions is that people run them directly on the server. Maybe sometimes even as root.
- freedomben 4y ago
  My thoughts as well. Tshark supports a ton of dissectors. How does this project compare? Being in go, can it reuse the Wireshark dissectors that are written in C?
synergy20 4y ago
reminds me of termshark at https://github.com/gcla/termshark https://github.com/gcla/termshark also written in golang
- miki725 4y ago
  +1 on termshark. It is pretty sweet. Much simpler to use compared to tshark/tcpdump imo since it avoids most of the cli flags complexity and uses familiar Wireshark filters
infamousclyde 4y ago
Hey everyone, I'm the original author of this library. This is actually my first software project ever-- I'm a full-time officer in the military who was just messing around. It's extremely flattering to see this shared so publicly, but I feel the need to pre-emptively apologize to readers. This is just a hobby project for now, but I would appreciate feedback.
- jrexilius 4y ago
  Well done. At first glance the UI looks well organized. Will give a test drive. Thanks for putting your work out there!
- gojiberries 4y ago
  This is really well done! I found it on /r/golang and wanted to submit it to HN because it worked so well. Thanks for making such an awesome tool.
- kretaceous 4y ago
  Thank you for your service and your project! Looks really well done. I have always wanted to make something using the Charm ecosystem. A question to everyone: Can anyone explain the networking part of this a bit? I see the `gopacket` package has been used. Is it only capable of "readonly" operations like this? I'm trying to make a cross-platform system wide URL-based blocker and was wondering if this (gopacket) could achieve that. Any good resources for studying about the same? I've seen projects do the same for Linux with proxies.
- tptacek 4y ago
  Keep rolling with it; there's an opportunity for someone to start a memory-safe protocol analyzer written in a higher-level language than C with a decent TUI, and have it snowball into something big. Best of luck!
mmh0000 4y ago
tshark[0][1] has been the go-to standard for CLI packet analysis for a long time. It'd be really nice if Gosniff provided some kind of documentation on how it differentiates itself from tshark. [0] https://tshark.dev/ https://tshark.dev/ [1] https://blog.wireshark.org/2014/07/to-infinity-and-beyond-capturing-forever-with-tshark/ https://blog.wireshark.org/2014/07/to-infinity-and-beyond-ca...
- GekkePrutser 4y ago
  Tshark is CLI, this is TUI, that seems to be big differentiator. Though tshark seems more mature
pnutjam 4y ago
Great project, have you seen what Etherape does? It would be interesting to include a text based scaling of what's talking to your computer.

102 points by gojiberries 4y ago

Looks pretty good! Some suggestions: it should support tcpdump's command line arguments and start with them as defaults. It would be neat if packets from different interfaces can be shown in different windows.

accrual 4y ago

I like how each packet is broken out into layers. Would be helpful for learning about new protocols on the wire.

tptacek 4y ago
This, for what it's worth, is a side-effect of using gopacket, which is a deceptively powerful library. You essentially have a big chunk of `tcpdump`'s encoding available to you any time you're working with packet buffers in Go, because of that library; for instance, to debug our BPF-based UDP stuff, there's an interface that shuttles packet snapshots over perf buffers and about 30 lines of Go code to read and decode those buffers. I was surprised at how much I got "for free" just by importing gopacket. It's great, more people should do cool stuff with it.

T3OU-736 4y ago

Neat project. How does it compare to Wireshark' console cousin tshark?

tptacek 4y ago
Once nice thing about this is that it's memory-safe, which is something you really want for a packet capture tool.
- T3OU-736 4y ago
  Hrm. Interesting point. There have been a fair number of parser CVEs, but GoLang isn't immune to some of the (based on an admittedly cursory look) parser issues.
  - tptacek 4y ago
    A protocol analyzer implemented in anything short of formally-verified code is going to be "vulnerable" to logic errors, such that it might print (or not print) the wrong things. But a protocol analyzer implemented in C standard a decent chance of coughing up RCE.
    - T3OU-736 4y ago
      (Playing devil's advocate): What would the RCE accomplish? "Parse this packet and get a reverse shell on analyst's workstation?" To be clear: I am not in any way attempting to disparage the project. It is damned cool, and as a neophyte Go practitioner myself, I very much appreciate its existance and utility. Just working through all the edge cases :)
      - tptacek 4y ago
        Yes, that's what it would accomplish.
      - jpalomaki 4y ago
        I assume one reason for these console versions is that people run them directly on the server. Maybe sometimes even as root.
freedomben 4y ago
My thoughts as well. Tshark supports a ton of dissectors. How does this project compare? Being in go, can it reuse the Wireshark dissectors that are written in C?

synergy20 4y ago

reminds me of termshark at https://github.com/gcla/termshark https://github.com/gcla/termshark also written in golang

miki725 4y ago
+1 on termshark. It is pretty sweet. Much simpler to use compared to tshark/tcpdump imo since it avoids most of the cli flags complexity and uses familiar Wireshark filters

infamousclyde 4y ago

Hey everyone, I'm the original author of this library. This is actually my first software project ever-- I'm a full-time officer in the military who was just messing around. It's extremely flattering to see this shared so publicly, but I feel the need to pre-emptively apologize to readers. This is just a hobby project for now, but I would appreciate feedback.

jrexilius 4y ago
Well done. At first glance the UI looks well organized. Will give a test drive. Thanks for putting your work out there!
gojiberries 4y ago
This is really well done! I found it on /r/golang and wanted to submit it to HN because it worked so well. Thanks for making such an awesome tool.
kretaceous 4y ago
Thank you for your service and your project! Looks really well done. I have always wanted to make something using the Charm ecosystem. A question to everyone: Can anyone explain the networking part of this a bit? I see the `gopacket` package has been used. Is it only capable of "readonly" operations like this? I'm trying to make a cross-platform system wide URL-based blocker and was wondering if this (gopacket) could achieve that. Any good resources for studying about the same? I've seen projects do the same for Linux with proxies.
tptacek 4y ago
Keep rolling with it; there's an opportunity for someone to start a memory-safe protocol analyzer written in a higher-level language than C with a decent TUI, and have it snowball into something big. Best of luck!

mmh0000 4y ago

tshark[0][1] has been the go-to standard for CLI packet analysis for a long time. It'd be really nice if Gosniff provided some kind of documentation on how it differentiates itself from tshark. [0] https://tshark.dev/ https://tshark.dev/ [1] https://blog.wireshark.org/2014/07/to-infinity-and-beyond-capturing-forever-with-tshark/ https://blog.wireshark.org/2014/07/to-infinity-and-beyond-ca...

GekkePrutser 4y ago
Tshark is CLI, this is TUI, that seems to be big differentiator. Though tshark seems more mature

pnutjam 4y ago

Great project, have you seen what Etherape does? It would be interesting to include a text based scaling of what's talking to your computer.