Re: Limiting ssh access: by MAC Address?
On Wed, 4 Jan 2023, ?ngel wrote: There are no transparent proxies for https. They would either pass traffic without inspecting it, or they would need to break the TLS connection to MITM it, and -unless the client has installed a CA for the proxy- cause all https connections to fail due to untrusted certificate. I suggest you read up about the problem that ESNI is supposed to solve. As someone who runs a https transparent proxy that does SNI inspection and egress filtering, I can assure you they do exist and will break ovpn running on port 443. You might argue that it's not a proxy - it doesn't and cannot cache content - but so much content is dynamic now anyway that caching isn't particularly useful except for things like debian packages. Egress filtering is still possible. It's frustrating that so much effort goes into defeating government level inspection of end user traffic and so little goes into defeating the countless IoT trojan horses in our homes. Indeed, I wouldn't be surprised if the long term result of the current trajectory is authoritarian regimes using phones to spy on people in their homes with no way to block it (other than turn the phone off - but that already works today so ESNI isn't needed)
Re: Limiting ssh access: by MAC Address?
On Wed, 4 Jan 2023, Jeffrey Walton wrote: The preauth scheme does not hide the service like your TOTP scheme. However, it looks like both schemes achieve the same thing - they both avoid the costly key exchange. Avoiding the key exchange is a big win since those public key operations are so costly. My scheme doesn't remove the need for any auth. What it does do is limit the noise in the logs. Given that the DNS query won't come from the same address as the intended connection you have to open the service to everything temporarily. I was getting anything from thousands to hundreds of thousands of login attempts per day on a service that didn't accept passwords. I now have an aggressive firewall policy that blocks any ip that sends three SYN that dont get an ACK in an hour. (with a couple of ports that will remove a ban where external connections are expected) Roughly 300 ips got added yesterday and 30 managed to remove themselves. (incoming connections are totally blocked from china, russia and a handful of other countries along with some netblocks that I've manually added) My quick grep of the firewall logs suggests than I'm seeing 10x as many attempts to connect to telnet than I am to ssh so I guess ssh is finally becoming secured from password guessing and people are giving up on trying (except possibly targetted attacks on servers that accept passwords) I'm also, as far as possible, moving to ipv6. That also cuts down on the noise a lot. So hiding services just isn't as valuable to me now as it was four years ago. I'm still generating 40MB of firewall logs a day that get backed up though.
Re: Limiting ssh access: by MAC Address?
On 5/1/23 12:56, Jeffrey Walton wrote: On Wed, Jan 4, 2023 at 11:34 PM Gareth Evans wrote: On 3 Jan 2023, at 22:07, Tom Browder wrote: I ... would like to access my home server from my laptop ... On 5 Jan 2023, at 04:13, Jeffrey Walton wrote: ... Avoiding the key exchange is a big win since those public key operations are so costly. Costly in what sense and circumstances? Public key operations for key exchange dominate the cpu cost of a session. Key exchange is the limiting factor in how many connections a server can handle. It has always been this way, even for SSL/TLS and IPSec. For your typical home user with no expectation of high numbers of connections, the issue is more to limit the crap that turns up in the logs from failed login attempts. Requiring a valid client certificate to be presented before, or instead of, a username/password works perfectly for this. I have some recollection that the validation of a client certificate is not a high cost exercise? -- Jeremy
Re: Limiting ssh access: by MAC Address?
On Wed, Jan 4, 2023 at 11:34 PM Gareth Evans wrote: > > > On 3 Jan 2023, at 22:07, Tom Browder wrote: > > I ... would like to access my home server from my laptop ... > > > > On 5 Jan 2023, at 04:13, Jeffrey Walton wrote: > > ... > > Avoiding the key exchange is a big win > > since those public key operations are so costly. > > Costly in what sense and circumstances? Public key operations for key exchange dominate the cpu cost of a session. Key exchange is the limiting factor in how many connections a server can handle. It has always been this way, even for SSL/TLS and IPSec. In contrast, bulk encryption is cheap. Bulk encryption is the block or stream cipher, and the mac calculations. One of the reasons x25519 is so valuable is how efficient it is. Here are some benchmarks from Crypto++ on a Core i5 10th gen Ice Lake machine: Scheme |ms/op| megacycle/op DH-2048|0.565| 1.977 ECDH p256 |0.456| 1.595 x25519 |0.039| 0.138 In the numbers above, lower is better. x25519 is about 15x faster than DH over integers, and about 11x faster than DH over EC. Key exchange is measured in megacycles per operation. That is, how many million-cycles is needed for an operation. Here, the operation is exponentiation in a finite field. In contrast, bulk encryption is measured in cycles per byte. Jeff
Re: Limiting ssh access: by MAC Address?
> On 3 Jan 2023, at 22:07, Tom Browder wrote: > I ... would like to access my home server from my laptop ... > On 5 Jan 2023, at 04:13, Jeffrey Walton wrote: > ... > Avoiding the key exchange is a big win > since those public key operations are so costly. Costly in what sense and circumstances? For interactive, real-user-at-the-end ssh logins, key checking delays are negligible in my experience - certainly no longer than it would take to type a password... Kind regards, Gareth > > Jeff
Re: Limiting ssh access: by MAC Address?
On Wed, Jan 4, 2023 at 5:45 PM Tim Woodall wrote: > > On Wed, 4 Jan 2023, Jeffrey Walton wrote: > > > On Wed, Jan 4, 2023 at 2:20 PM Tim Woodall wrote: > >> ... > >> > >> I've also thought about TOTP dns requests as a type of port knocking : a > >> dns request to .knock.example.com would open the ssh port for a > >> minute. Small local webpage to do the TOTP port knock in javascript > >> should work anywhere. Something else that has been on my todo list for > >> years. > > > > That is kind of clever. Do you know of any papers that discuss it? > > I don't know of any papers that discuss it and I certainly didn't write > one. > > This is what I imagined: > > .knock.example.com > > bind (because that's what I use) configured to forward knock.example.com > to an internal address. > > Small program listens and responds to all queries with 127.0.0.1 (just > found my c++ program to do this written in 2018 - I'd probably use > python now). Because this program is only hit from a trusted server, > it's unlikely to suffer exploitable issues. Malformed packets, for > example, will not make it past the bind instance. > > program also checks totp and if it matches expected value (possibly with > a threshold) then update an ipset with a catchall address. > > iptables rule something like > iptables -t filter -A INPUT -m set --match-set sshok src -m state --state NEW > -j ACCEPT > (you probably don't want to open everything) > > and some sort of cron job to delete the catchall address > > You could, of course, also do the same by hitting a webserver that > checks the URL for the totp but DNS is more reliable - you can usually > get DNS packets through even where ISPs block running servers and that > can trigger constructing a tunnel to a server that can listen to > incoming connections. Also DNS better hides where you're connecting > from. > > Finally, dns port knocking will work with anything that connects to a > dns name as the name lookup must happen before the connection although > in that case the returned address needs to be the target address, not > 127.0.0.1 I was talking to Peter Gutmann about SSH hardening. He shared a recent RFC pro SSH preauth: https://datatracker.ietf.org/doc/draft-gutmann-ssh-preauth/ . The preauth scheme does not hide the service like your TOTP scheme. However, it looks like both schemes achieve the same thing - they both avoid the costly key exchange. Avoiding the key exchange is a big win since those public key operations are so costly. Jeff
Re: Limiting ssh access: by MAC Address?
On 2023-01-04 at 19:20 +, Tim Woodall wrote: > It doesn't work through a transparent proxy unfortunately (at least the > android client doesn't) which I assume was doing SNI snooping - but I've > only encountered that once in the UK so far. > > My plan was to write something that used a dns request to tell ovpn to > expect an HTTPS wrapped ovpn stream - but it's one of those projects > that I'll probably never actually get around to. You can do this with stunnel, see https://www.stunnel.org/static/stunnel.html#EXAMPLES However, openvpn supports running directly as https://, so if you place it on port 443 it is indistinguishable from a normal https server for networks restricting the ports.* (Maybe you were using udp?) There are no transparent proxies for https. They would either pass traffic without inspecting it, or they would need to break the TLS connection to MITM it, and -unless the client has installed a CA for the proxy- cause all https connections to fail due to untrusted certificate. (*) an advanced filtering solution might be able to notice that the traffic patterns don't match with those of https but are likely a VPN.
Re: Limiting ssh access: by MAC Address?
On Wed, 4 Jan 2023, Jeffrey Walton wrote: On Wed, Jan 4, 2023 at 2:20 PM Tim Woodall wrote: ... I've also thought about TOTP dns requests as a type of port knocking : a dns request to .knock.example.com would open the ssh port for a minute. Small local webpage to do the TOTP port knock in javascript should work anywhere. Something else that has been on my todo list for years. That is kind of clever. Do you know of any papers that discuss it? I don't know of any papers that discuss it and I certainly didn't write one. This is what I imagined: .knock.example.com bind (because that's what I use) configured to forward knock.example.com to an internal address. Small program listens and responds to all queries with 127.0.0.1 (just found my c++ program to do this written in 2018 - I'd probably use python now). Because this program is only hit from a trusted server, it's unlikely to suffer exploitable issues. Malformed packets, for example, will not make it past the bind instance. program also checks totp and if it matches expected value (possibly with a threshold) then update an ipset with a catchall address. iptables rule something like iptables -t filter -A INPUT -m set --match-set sshok src -m state --state NEW -j ACCEPT (you probably don't want to open everything) and some sort of cron job to delete the catchall address You could, of course, also do the same by hitting a webserver that checks the URL for the totp but DNS is more reliable - you can usually get DNS packets through even where ISPs block running servers and that can trigger constructing a tunnel to a server that can listen to incoming connections. Also DNS better hides where you're connecting from. Finally, dns port knocking will work with anything that connects to a dns name as the name lookup must happen before the connection although in that case the returned address needs to be the target address, not 127.0.0.1
Re: Limiting ssh access: by MAC Address?
On 2023-01-04 at 16:03 +, Joe wrote: > I actually use ssh for remote access if I can, but it only allows TCP > forwarding, so I can get to email but not to anything that requires > DNS or UDP. A VPN connection gives full access to all network > protocols. > The VPN will have a pre-defined IP address in your private network, so > access can be fine-tuned using a firewall if required. The VPN endpoint > appears in the server as another network interface. Actually, you can do the same with ssh. Have a look at -w and Tunnel configuration option of ssh. It is a little known feature, but this allows you to use ssh like a VPN. It does however require some configuration at *both* sides of the ssh connection, specially if you want to run it as non-root. Regards
Re: Limiting ssh access: by MAC Address?
On Wed, Jan 4, 2023 at 2:20 PM Tim Woodall wrote: > ... > > I've also thought about TOTP dns requests as a type of port knocking : a > dns request to .knock.example.com would open the ssh port for a > minute. Small local webpage to do the TOTP port knock in javascript > should work anywhere. Something else that has been on my todo list for > years. That is kind of clever. Do you know of any papers that discuss it? Jeff
Re: Limiting ssh access: by MAC Address?
On Wed, 4 Jan 2023, Joe wrote: On Tue, 3 Jan 2023 17:06:30 -0500 Tom Browder wrote: Is it possible to use UFW to limit ssh access to a server by an external host by its MAC address? I now have a permanent IPv4 address for my home IP router and would like to access my home server from my laptop when away from home, but allow no other external access. Is that possible? Another thought is to use a VPN. Indeed. I use openvpn and take advantage of its feature that it can listen on port 443 and then forward web traffic to a server. One thing this can do is help hide the ovpn instance (in my case I also listen on the default port so not really relevant) but also can help where public wifi restricts the ports that can connect. It doesn't work through a transparent proxy unfortunately (at least the android client doesn't) which I assume was doing SNI snooping - but I've only encountered that once in the UK so far. My plan was to write something that used a dns request to tell ovpn to expect an HTTPS wrapped ovpn stream - but it's one of those projects that I'll probably never actually get around to. I've also thought about TOTP dns requests as a type of port knocking : a dns request to .knock.example.com would open the ssh port for a minute. Small local webpage to do the TOTP port knock in javascript should work anywhere. Something else that has been on my todo list for years.
Re: Limiting ssh access: by MAC Address?
On Wed, Jan 4, 2023 at 01:06 john doe wrote: > On 1/3/23 23:06, Tom Browder wrote: ... This is in addition to the other answers. > > If you have a server which is publicly available, you can only > "restrict" by IP, rate limiting, port nocking and having your server... Thanks, John Doe, and all the others who answered. FYI, I have other remote servers and all use PKI for access and do they do not allow password access. I do use fail2ban. I also will follow the other suggestions. Thanks for all the help. Debian users are the best! -Tom
Re: Limiting ssh access: by MAC Address?
On 1/3/23 23:06, Tom Browder wrote: Is it possible to use UFW to limit ssh access to a server by an external host by its MAC address? I now have a permanent IPv4 address for my home IP router and would like to access my home server from my laptop when away from home, but allow no other external access. Is that possible? This is in addition to the other answers. If you have a server which is publicly available, you can only "restrict" by IP, rate limiting, port nocking and having your server properly secured and isolated. -- John Doe
Re: Limiting ssh access: by MAC Address?
On 1/3/23 14:06, Tom Browder wrote: Is it possible to use UFW to limit ssh access to a server by an external host by its MAC address? I now have a permanent IPv4 address for my home IP router and would like to access my home server from my laptop when away from home, but allow no other external access. Is that possible? Thanks. -Tom I do remote SSH access. "SSH Mastery" by Lucas was very helpful: https://mwl.io/nonfiction/tools#ssh David
Re: Limiting ssh access: by MAC Address?
On Tue, 3 Jan 2023 17:30:48 -0500 Dan Ritter wrote: > Tom Browder wrote: > > Is it possible to use UFW to limit ssh access to a server by an > > external host by its MAC address? > > > > I now have a permanent IPv4 address for my home IP router and would > > like to access my home server from my laptop when away from home, > > but allow no other external access. Is that possible? > > Not via MAC address, no. MAC addresses are only visible inside a > local area network, and disappear when routing happens to a new > network. > > You should use an SSH public/private key, that you have tested > before you leave, and you should use something like this in your > sshd config: > > allow_users tomb > > which will narrow the range of acceptable users (before any > other user auth happens) to just people who know your username. > > Just a slight bit of obvious polish on that: set up a user name specifically for this, with no link at all to your real name, email name etc. Use something like a password if you like, (near) random letters. Also use a long passphrase for the private key, mine is around thirty characters. You can also use an unusual port, with either the server accepting ssh on that port, or the router translating it to 22 when forwarding. Before anyone puts finger to keyboard, this improves security only microscopically (though I've only ever been portscanned once in 25 years, I think ISPs frown on it) but it does keep the logs clean, no small advantage. -- Joe
Re: Limiting ssh access: by MAC Address?
On Tue, 3 Jan 2023, Dan Ritter wrote: Tom Browder wrote: Is it possible to use UFW to limit ssh access to a server by an external host by its MAC address? I now have a permanent IPv4 address for my home IP router and would like to access my home server from my laptop when away from home, but allow no other external access. Is that possible? Not via MAC address, no. MAC addresses are only visible inside a local area network, and disappear when routing happens to a new network. You should use an SSH public/private key, that you have tested before you leave, and you should use something like this in your sshd config: allow_users tomb which will narrow the range of acceptable users (before any other user auth happens) to just people who know your username. This! And further you can set: cat /etc/ssh/sshd_config.d/no_password.conf PasswordAuthentication no and you'll be completely safe from password guessing attacks too. (you can edit sshd_config rather than snippits in sshd_config.d) I have keys on multiple devices - I use juiceSSH mostly but also connectbot on android devices. Just make sure your keys are labelled in authorized_keys sensibly. If you lose a device you want to know which key to remove if there are lots.
Re: Limiting ssh access: by MAC Address?
On Tue, Jan 3, 2023 at 5:07 PM Tom Browder wrote: > > Is it possible to use UFW to limit ssh access to a server by an external host > by its MAC address? > > I now have a permanent IPv4 address for my home IP router and would like to > access my home server from my laptop when away from home, but allow no other > external access. Is that possible? No, not by filtering MAC or IP addresses since your laptop will be on a different network. The MAC address you see will most likely be that of your router. If it's not the router, then it's your firewall placed behind the router. If you want strong authentication assurances, then setup PublicKey-only authentication. I run it on nearly all my machines, and use it locally and remotely. Here's what you need. Notice the conf files are placed in sshd/, and not ssh/. sshd/ is the local server config, and ssh/ is the client software config. $ cat /etc/ssh/sshd_config.d/10-pubkey_auth.conf # Enable public key PubkeyAuthentication yes # Disable passwords PasswordAuthentication no ChallengeResponseAuthentication no KerberosAuthentication no KerberosOrLocalPasswd no GSSAPIAuthentication no UsePAM no $ cat /etc/ssh/sshd_config.d/20-no_root_login.conf PermitRootLogin no If you want to stop unlimited [failed] authentication attempts, then checkout tools like fail2ban. Jeff
Re: Limiting ssh access: by MAC Address?
Tom Browder wrote: > Is it possible to use UFW to limit ssh access to a server by an external > host by its MAC address? > > I now have a permanent IPv4 address for my home IP router and would like to > access my home server from my laptop when away from home, but allow no > other external access. Is that possible? Not via MAC address, no. MAC addresses are only visible inside a local area network, and disappear when routing happens to a new network. You should use an SSH public/private key, that you have tested before you leave, and you should use something like this in your sshd config: allow_users tomb which will narrow the range of acceptable users (before any other user auth happens) to just people who know your username. -dsr-
Re: Limiting ssh access: by MAC Address?
Tom Browder (12023-01-03): > Is it possible to use UFW to limit ssh access to a server by an external > host by its MAC address? > > I now have a permanent IPv4 address for my home IP router and would like to > access my home server from my laptop when away from home, but allow no > other external access. Is that possible? It is easy to limit the MAC <-> IP address mapping, no need for a firewall, ip neigh is enough. Then it is easy to limit SSH to a certain IP address. Of course, it only works if the host is on the same local network. And of course, it is absolutely not an efficient security measure. Regards, -- Nicolas George signature.asc Description: PGP signature
Re: Limiting ssh access: by MAC Address?
On Tue, Jan 03, 2023 at 05:06:30PM -0500, Tom Browder wrote: > Is it possible to use UFW to limit ssh access to a server by an external > host by its MAC address? "External" meaning not on your Local Area Network? In that case, no. The MAC address of a host that's not on your LAN is not visible. It's not contained within the packets you receive. You only see the MAC address of your router, specifically of the interface that sits on your LAN. Not of the hosts beyond the router.