Detecting SSH Tunnels (2017) | Hacker News Reader

Detecting SSH Tunnels (2017)

trisul.org

83 pointsapitman36 comments

Note: thinly-veiled advertisement.

The Great Firewall certainly can detect and block SSH too, but there are ways around that as discussed at https://news.ycombinator.com/item?id=36531485

Not saying you are wrong to point out. But isnt all corporate blogs advertisements?

Some is thicker veiled than others.

the word you're looking for is "public relations", or PR. it's a different group of people than advertising.

> different

intersecting sets.

mmm, in a larger organization not really, proper subsets of marcomm, marketing communications. advertising people are called "creatives" where PR people are much more devious.

Along with gfw.report, Project X on github and their telegram channel also contain their latest report on gfw.

Reminder to run some continuous streams through your ssh tunnels so your keystroke patterns aren’t detected as easily.

That sort of obfuscation is a feature now. Perhaps in the future it'll be able to mimic any "legitimate business activity".

https://news.ycombinator.com/item?id=37307708

I keep hoping for a QUIC transport option for SSH with regular TLS. Just to make the life of all these middleboxes way more difficult.

It's already pretty easy to use SSH over TLS using stunnel or any other thing that can do TLS to TCP proxies (socat, haproxy).

On some external system you just setup stunnel/socat/haproxy to listen on port 443 with TLS and proxy to TCP port 22, then just use openssh with openssl s_client as the proxy command.

Although not the same as what you desire (which I fully agree with) - I implemented a encrypted TCP program tunneling app which tunnels over HTTP(S) websockets [1]. This should frustrate middleboxes, but would rather it be as native as HTTP(S) itself.

[1]: https://github.com/nnathan/monopiped

The zeek/bro rule this is based on is here in the talk https://youtu.be/K986WVvtNF4?t=903

https://github.com/zeek/zeek

If you can communicate from inside to the outside in any way, then it is possible to build a tunnel. Even if the communication goes through written letters.

So if that's your concern, perhaps address the communication, not the ssh tunnel.

The good'ol social tunnel. "The inside wo/man"

If you are able to capture a flow from begin to end, you can use something like the entropy of the flow to guess if a tunnel is encrypted or not..

If you capture beginning to end, look inside packet #1 :)

SSH protocol version exchange is before key exchange. Is this not easily identified in both Clint and server side packet analysis?

I appreciate that SSH can be obsfucated via an SSL tunnel but the article didn't come at that angle.

The article itself even states: >with SSH everything goes dark right after the initial capabilities exchange.

So... What say about before the exchange?

They want to consider normal connections legitimate, and only detect tunnels.

Forgive me, my grok ability is low right now. I read the section about detecting TTY traffic, and in my mind, TTY traffic would be an example of a legit normal connection. Engineer accessing the system, etc.

I routinely use both forward and reverse tunnels in my day-to-day ssh use.

Why not just outright ban the use of normal SSH and enforce all legitimate SSH activity to go through a wrapper program that reports to a monitoring service?

It could be a 4-line bash alias, any SSH activity that doesn't go through your wrapper could be considered suspicious

I think we should be installing subdermal surveillance implants in all tier 2 workers and lower.

The plebs can't be trusted to respect our wealth and superiority.

You're aware that (Open)SSH can have its behavior, including port forwards, modified at runtime after launch?

See e.g. https://linux.die.net/man/1/ssh section "Escape Characters" and "~C' Open command line. Currently this allows the addition of port forwardings ..."

That's basically the end goal of most SSL and security enterprise product pushers: a crappier, less usable un-automatable replacement of SSH. (Example: teleport).

Of course any concerns about the vulnerabilities in their closed source implementations are handwaved away.

Oh boy. The things the security people do to justify their existence.

The future may be your actual traffic through ssh tunneled through https with esni to a server behind Cloudflare. Unless you want pseudo security tools to mess with your traffic.

Sir, you will have to change your password bi-weekly. You will also have to change your password on the next login.

I know you're joking, but NIST no longer recommends password rotation as a policy. If you are somewhere that still requires that, send them https://www.bleepingcomputer.com/news/security/aligning-your...

Dear sir, the "NIST" organization that you mentioned is not a recognized authority in Japan. In Japan, one has to follow NISC guidelines, not NIST.

I'm resetting passwords of you both to cool down a bit.

And the password is limited to eight characters maximum and it must have uppercase, lowercase and punctuation in order to limit the amount of rainbow you have to calculate.

The password update app will news SSL protocols and cryptography that are vastly out of date.

There will be no synchronization of passwords across various systems used in the company so you will have to memorize multiple passwords which means writing them down.

> With HTTPS/SSL, security tools can get atleast a look at the unencrypted certificates and perform checks

Isn't this mitigated in newer TLS versions?

It's not mitigated by TLS itself.

It's a separate addition. Chrome has already started their gradual rollout of ECH (previously known as ESNI). Though I haven't seen nice server-side implementations/automation.

Encrypted client hello, but not server hello, then. I suppose that makes sense. Thanks!

I use cloudflare's WARP (BoringTun) for free. It's a must on public wifi. Don't remember having problems with it.

Why not disable ssh tunnel if you don't want it

Reply on news.ycombinator.com