how to block brute force attacks on reverse tunnels?

[Jan Schermer]

I use Shorewall rule for stuff like this,you would do this on the internet-facing host:

ACCEPT        all               fw              tcp     22      -       -       s:3/min:2

https://shorewall.org/ConnectionRate.html


This limits the connection rate to the tunnel ports.
Another option is some form of port knocking (but I’m not a fan of those).
Or just do a proper VPN and only expose the ports to the VPN clients...

Jan

> On 25. 4. 2024, at 19:44, Jochen Bern <Jochen.Bern at binect.de> wrote:
> 
> On 25.04.24 17:15, openssh-unix-dev-request at mindrot.org digested:
>> Subject: how to block brute force attacks on reverse tunnels?
>> From: Steve Newcomb <srn at coolheads.com>
>> Date: 25.04.24, 17:14
>> For many years I've been running ssh reverse tunnels on portable Linux,
>> OpenWRT, Android etc. hosts so they can be accessed from a server whose
>> IP is stable (I call such a server a "nexus host"). Increasingly there's
>> a problem with brute force attacks on the nexus host's tunnel ports. The
>> attack is forwarded to the portable tunneling host, where it fails, but
>> it chews up a lot of resources and wants to be stopped. At the portable
>> tunneling host, fail2ban can't be used to block the attacker's IP because
>> when the attack arrives, it appears to the ssh daemon to be arriving from
>> localhost (127.0.0.1). I'm not sure the attacker's IP can even be known
>> at the portable host (openssh developers: can it?), and anyway it needs
>> to be blocked by the nexus host before it can chew up yet more bandwidth.
> 
> I take it that checking users/clients as they show up at the hub server's door in the first place is, for some reason, infeasible?
> 
> (We have solutions in prod where devices on customer premises similarly create a tunnel(-end) on our server to connect to their sshd, *but* users have to authenticate as they SSH or VPN to that server in the first place and the tunnel is restricted to localhost or VPN client pool IPs.)
> 
> Kind regards,
> -- 
> Jochen Bern
> Systemingenieur
> 
> Binect GmbH
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev