3 ms·

> 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 allow

by 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.

by shabble 14y ago

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.