1076
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 10 Aug 2023
1076 points (98.4% liked)
Technology
60084 readers
2675 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 2 years ago
MODERATORS
Far from trivial unless you’re willing to brick ssh completely, or at least cripple a bunch of non-VPN uses for tunneling. Of course it’s trivial to just block ssh outright, or block tunneling above a certain bandwidth. But that would also block, as an example, most remote IDE sessions, loopback-only server management frontends, etc.
The Kremlin could maybe have something set up that looks for accesses to stuff inside Russia from outside Russia, then flag that IP as suspicious as being a VPN endpoint outside Russia.
So, okay, take this scenario:
IP A, user inside Russia.
IP B, VPS outside Russia.
IP C, service inside Russia that state can monitor.
User in Russia on IP A has an SSH tunnel to VPS on IP B with SOCKS that they control.
That's fine as long as user is only browsing the Internet outside Russia. But if you're routing all traffic through the VPS and you use any sites in Russia, the Great Russian Firewall can see the following:
IP A has a long-running SSH connection to IP B.
IP B is accessing stuff in Russia.
You could maybe also do heavier-weight traffic analsysis on top of that if you see 1 and 2, or gather data over a longer period of time, but seeing 1 and 2 alone are probably enough to block IP A to IP B connections.
That can be defeated by using two external VPSes, opening an SSH tunnel to the first one, and then talking to SOCKS on the second (maybe with another SSH connection linking the two). But that's increasing complexity and cost.
A marginal increase, perhaps. You don’t need a separate VPS - just a second IP. Accept incoming traffic on port 22 on one, and set the default route for outbound traffic to the other.