4 ms·

I honestly do not understand why you need a deploy account with sudo access. I much prefer a deploy accound which DOES NOT have sudo access. I add firewall ru

I honestly do not understand why you need a deploy account with sudo access. I much prefer a deploy accound which DOES NOT have sudo access. I add firewall rules transparently redirecting 80/443 to non-privileged ports that the webapp is actually listening to. Hence no need to be root / sudo'ed for the deploy account. You then could get a bit fancier and set the login shell for the deploy account to /bin/false or something fancy (like a fake honeypot shell) to add a bit of "defense in depth" in case someone exploiting a hole in your web server manages tries to drop down to a shell. You'd then use another account to do the (automated) deploy/start/stop/update/patch whatever. I'd also say that during the first five minutes you should set the default firewalling rules to REJECT anything and then only whitelist what is actually allowed.

shabble 14y ago
> I'd also say that during the first five minutes you should set the default firewalling rules to REJECT anything and then only whitelist what is actually allowed. At which point your 'net connection blips and suddenly you wish you'd paid extra for console access.
- pavel_lishin 14y ago
  That's how I felt about the line where he recommends only allowing the deploy user to connect from a certain number of white-listed IPs. That's great and secure until you get a phone call while you're at the airport or on vacation, and then you hope that you can SSH into a machine at the office just so you can tunnel through from a white-listed IP.
  - shabble 14y ago
    Yeah, I've always felt nervous about doing whitelisting (and to some extent, things like fail2ban) for reasons like that. Having a couple of backup hosts / friends with shell-servers listed who you can bounce through might mitigate it somewhat though, whilst still avoiding 90% of the portscans-from-(china|mars) stuff. One idea I had was to enable something annoying and kooky like port-knocking or OTP pass/connection enabled 'backdoor entrance' for emergencies, but ended up being too lazy, and realised it was just expanding the attack surface. To my original point, we had an interesting setup for one network where the firewall changes were all manipulated via a script which required the change to be applied, and then confirmed after a short delay with a different command, otherwise after 5 minutes the ruleset would revert to the previous known-working one. It definitely saved some downtime/late night DC trips.
  - krenel 14y ago
    I had to do that and enabling the forwarding of the authentication agent with the -A option in the ssh client was very handy: $ ssh -A -t office_user@office ssh production_user@production I have the same private key in all my machines, so this worked transparently avoiding the IP restriction of iptables of the production machine.
toast0 14y ago
On FreeBSD (and other BSDs?), you can change the privileged port range with a sysctl setting, so you don't need to muck about with the settings, just let any user bind to 80 or higher.

shabble 14y ago

> I'd also say that during the first five minutes you should set the default firewalling rules to REJECT anything and then only whitelist what is actually allowed. At which point your 'net connection blips and suddenly you wish you'd paid extra for console access.

pavel_lishin 14y ago
That's how I felt about the line where he recommends only allowing the deploy user to connect from a certain number of white-listed IPs. That's great and secure until you get a phone call while you're at the airport or on vacation, and then you hope that you can SSH into a machine at the office just so you can tunnel through from a white-listed IP.
- shabble 14y ago
  Yeah, I've always felt nervous about doing whitelisting (and to some extent, things like fail2ban) for reasons like that. Having a couple of backup hosts / friends with shell-servers listed who you can bounce through might mitigate it somewhat though, whilst still avoiding 90% of the portscans-from-(china|mars) stuff. One idea I had was to enable something annoying and kooky like port-knocking or OTP pass/connection enabled 'backdoor entrance' for emergencies, but ended up being too lazy, and realised it was just expanding the attack surface. To my original point, we had an interesting setup for one network where the firewall changes were all manipulated via a script which required the change to be applied, and then confirmed after a short delay with a different command, otherwise after 5 minutes the ruleset would revert to the previous known-working one. It definitely saved some downtime/late night DC trips.
- krenel 14y ago
  I had to do that and enabling the forwarding of the authentication agent with the -A option in the ssh client was very handy: $ ssh -A -t office_user@office ssh production_user@production I have the same private key in all my machines, so this worked transparently avoiding the IP restriction of iptables of the production machine.

toast0 14y ago

On FreeBSD (and other BSDs?), you can change the privileged port range with a sysctl setting, so you don't need to muck about with the settings, just let any user bind to 80 or higher.