When you fire up Wireshark and monitor your network connection, do you see the dreaded "data" type packets being sent around?
You can check by going to Statistics -> Protocol Hierarchy and seeing if the "data" category appears. Or you can just put "data" in the filter bar and hit Apply.
I read that this is the most suspicious kind of traffic to be on your network, because "data" is just what Wireshark calls packets that it does not understand - often because the packets are using an unknown protocol/format (and, for 99% of people, there is no legitimate reason for a program to be sending packets like this).
I do see these "data packets" on my own network (pic related), but why are all but one of them shown as black and red? That color coding means "bad TCP" in Wireshark... could something like my router be blocking them?
If you don't know what you're looking at in Wireshark or have a significant understanding of how network protocol and handling works you're wasting your time. So much stuff can generate perfectly fine packets that look suspicious.
You're like the normies that go into C:/Windows and start deleting stuff because it looks suspicious.
>>53628190
wireshark has a huge number of dissectors for understanding all the known kinds of TCP and UDP traffic. If your computer is sending "data" packets, it pretty much means that those packets are using a custom or nonstandard protocol, or are sending a standard protocol over a nonstandard port. Neither of which should be happening if you aren't doing something like torrenting as you use Wireshark.
I did a Windows 8.1 install with KMSPico as a crack and I noticed that there were suddenly a lot of data packets being sent on the PC once I activated with KMSPico. So I uninstalled it after upgrading to a legit Win10 and the "data" section went away.
>>53628424
> Neither of which should be happening if you aren't doing something like torrenting as you use Wireshark
Or suddenly using winbox (8291) or any other kind of stuff like it. I completely agree with >>53628190 if you don't understand it - don't try to elaborate it, please, you only getting more confused and trying to confuse those around you.
>>53628424
>wireshark has a huge number of dissectors for understanding all the known kinds of TCP and UDP traffic.
No, it certainly does not. It has a lot of such dissectors, yes, but not NEARLY REMOTELY dissectors for "all known kinds". Try monitoring the communication for a multiplayer game and see what it reports.
By and large, wireshark has dissectors for open protocols, and thoroughly reversed engineered proprietary protocols such as SMB. There are tons and tons of proprietary protocols in use by proprietary programs, and wireshark does not and never will support more than a handful of them.
>>53628507
>>53628558
>allowing proprietary closed-source protocols to be used on your network
disgusting
>>53628190
>>53628507
>>53628558
Fine, then. The packets could be good or bad. How would one actually detect suspicious traffic using Wireshark, then?
>>53628827
You don't unless you're an intelligent human being willing to research and understand the individual protocols/applications involved, which rules you out.
>>53630168
oh, so you dont know then
ok
OP may be a little misguided but he does have a point. If you were secretly doing something malicious over a network you would most likely not want your packets to be readily dissectable by wireshark, and so they would this be found under the Data category.
Also, it is oftentimes not even that hard to reverse engineer a proprietary protocol for dissection in Wireshark. IIRC there are a few popular tools out there that can do it automatically.
But he's completely wrong in implying that all packets in the Data section are malicious.
>>53631253
>If you were secretly doing something malicious over a network you would most likely not want your packets to be readily dissectable by wireshark, and so they would this be found under the Data category.
If you were secretly doing something malicious over a network, you would encrypt your shit, and your footprint would be lost in the sea of [SSL traffic] that wireshark cannot decrypt.
>>53628000
No, because i use GNU/Linux.
>>53631396
Couldn't you encrypt your proprietary/unknown-protocol packets just as securely as with SSL/TLS (if not more so), though? Or just make it nigh impossible to reverse engineer and dissect the packets?
>>53631404
Wireshark is available for linux you know
>>53632072
>Couldn't you encrypt your proprietary/unknown-protocol packets just as securely as with SSL/TLS
Yes.
>(if not more so)
No.
Once you do encrypt it like this, it doesn't matter a single bit whether the encrypted protocol is well-understood or not. It's not more secure in the proprietary version, it's not less secure either, it's just all the same.
>Or just make it nigh impossible to reverse engineer and dissect the packets?
Why bother? This takes work. Just throwing SSL at it is much, much simpler and does the job at least as well. What is more, the SSL will ensure that your data does not stand out, which the heavily obfuscated but unencrypted protocol does not.
>>53628827
More by checking where the traffic is going, what on your computer is sending it, what the contents is (so actually inspecting the packets).
>>53632118
> it doesn't matter a single bit whether the encrypted protocol is well-understood or not. It's not more secure in the proprietary version, it's not less secure either, it's just all the same.
>the SSL will ensure that your data does not stand out, which the heavily obfuscated but unencrypted protocol does not.
So you can't have a custom protocol that is both heavily obfuscated and encrypted at the same time? Because I would think that that would be more secure than just TLS/SSL on its own, and - judging by the responses ITT - 99% of people don't see Wireshark's "data" packets as suspicious, anyway.
>>53632536
Sure you can, but it doesn't gain you anything. At all.
Wireshark isn't going to see through that SSL layer, so what you put inside it doesn't matter, period.
>Because I would think that that would be more secure than just TLS/SSL on its own
Why?
>>53632650
>Why?
I guess because you wouldn't be able to tell that an obfuscated packet is encrypted at all until you are able to reverse engineer and dissect it? The obfuscation would be one layer of security, and the encryption would be another.
