undefined | Better HN

0 pointssnowwrestler12y ago0 comments

That's what I was afraid of.

Let's say I have a small captive group of more savvy users--just the site admins, for instance. Are any of these approaches worth looking into for them?

0 comments

4 comments · 2 top-level

infogulch12y ago· 2 in thread

For admins, put the site behind a firewall with only SSH ports open, make them SSH into it, set up a SOCKS proxy, and connect through localhost.

lsc12y ago

socks is overly complex for the problem, especially if you have several sites you do this for. Port forwarding is simple, and you can port forward to many different sites and the routing is obvious.

ssh -L1234:localhost:80 adminhost.yourdomain.com

then hit http://localhost:1234/ in your browser to reach port 80 on adminhost.yourdomain.com.

Simple and clear. The user isn't accidentally going to do their personal browsing over the admin network.

Make sure that the server on adminhost is only listening on localhost (and/or that port 80 is firewalled off to the outside world)

This is what I do everywhere I need to trust a http interface.

I even make customers do it some places (e.g. if they have access to VNC for KVM guests) but it does require a certain caliber of user.

snowwrestlerOP12y ago

Sorry, by "admins" I meant folks who log into the Web administrative interface through a browser, but have elevated permissions. Specifically, can I reduce the chance that a cert attack will allow MITM for these users' browser sessions. We do very carefully protect shell access on the server itself.

rx4g12y ago

Actually, without installing extra software, you can drop all the root CAs and do Trust-on-First-Use (TOFU) with a limited set of browsers. It's possible with Firefox desktop, for example. Painful and error-prone, but doable. As with the SSH model, as long as you trust your initial authentication, future authNs where the pubkey changes will give you a warning because it will necessarily be a new cert.

j / k navigate · click thread line to collapse