Comment by some_random
2 years ago
I know some people do network monitoring for hands-on-keyboard shells (presumably) by measuring packet timing, I wonder if this will mess with those detections and if so by how much.
2 years ago
I know some people do network monitoring for hands-on-keyboard shells (presumably) by measuring packet timing, I wonder if this will mess with those detections and if so by how much.
I hope that kind of thing goes the way of other corporate efforts to break/backdoor encryption for the sake of "security". IMO, it's really the wrong way to go about security. Sure it would be nice to know if some automated script is being used to log into a machine, but better design can mean that information isn't important.
This has nothing to do with breaking encryption and of all the sketchy corporate surveillance tooling that's deployed for security purposes (so say nothing of HR purposes) monitoring for shells on the network seems about as benign as it comes.
It's only benign if we don't see new policies that say "everyone must disable keystroke obfuscation so we can still spy on traffic".
If a company's security strategy relies on the ability to tell if a given stream of encrypted bytes is shell traffic, and that it can be fooled by timing obfuscation, they need a better strategy. Attackers won't care to follow a "no timing obfuscation" policy.
1 reply →
What non-malicious use case is there for this?
Network monitoring for unauthorized/unusual access, reading more into how this works I don't think this would actually change anything, you can probably still discern scripted vs manual shells it would just be a bit harder.
presumably for checking compliance with a policy that forbids it