Open hadley opened 9 years ago
Yeah, I think we've been reading the same digitalocean docs ;-)
Here's what I've been doing: http://www.carlboettiger.info/2014/09/08/server-security-basics.html
Happy to learn more from others. I started drafting a script (very minimal, not working yet) to help automate some of this, though I think it may be hard to automate some steps (e.g. tripwire config, though maybe that's not necessary unless the user is gonna be checking the logs regularly.
I'm hoping to get a more professional consultation on this stuff eventually. Computer security is above my pay grade.
@cboettig thanks for the quick feedback and the script share!
We still need to consider better security defaults whether or not a user uses docker, right?
Yes, I think so. I think more functions along the lines of install.r
would be useful - then we can just tell people, this is what we recommend you do after starting a droplet.
right, ok
I think the first step should be to set up a non-root user. I think we can make this seamless by using Sys.info()[["user"]]
to use the same user name as your local login. Then (following along from https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-14-04):
adduser
I think using root is fine (for now) inside containers, but we should be a bit stricter at the top level. The only potential downside I see to this is that since we're changing ssh defaults, it may mean some small breakage if you're connecting to a droplet that you created previously.
Then apply @cboettig's script to install ufw and set up a minimal firewall. (I think we also need to allow http so that we can talk to RStudio by default)
We're already defaulting to using ssh keys if they're available. The main question is if we should require them or not. If required, we need to tweak droplet_create()
and ensure password-based logins on the server are disabled.
Just a note I've updated my script, though could no doubt be much improved.
sed
edits, @hadley 's suggestion of just scp in an etc/ssh/sshd_config
file is probably preferable, though still has to be edited interactively to get the correct username to whitelist and the correct ssh port to configure). Requires ssh keys (perhaps that's not ideal; digitalocean certainly seems to think it has enough users who prefer getting emailed passwords to make that the default). (Obviously the script is more of a starting place to adapt than something designed for analogsea directly, just thought I'd note that it was somewhat more useful than it was earlier. Feedback/critique always appreciated) https://github.com/cboettig/dockerfiles/blob/master/setup.sh
Looks like provides some good suggestions for setting up non root user with sudo privileges: https://www.digitalocean.com/community/tutorials/how-to-use-cloud-config-for-your-initial-server-setup
Very nice! I really like the approach they take here, that's really how it should be done.
On Wed, Oct 15, 2014 at 2:00 PM, Hadley Wickham notifications@github.com wrote:
Looks like provides some good suggestions for setting up non root user with sudo privileges: https://www.digitalocean.com/community/tutorials/how-to-use-cloud-config-for-your-initial-server-setup
— Reply to this email directly or view it on GitHub https://github.com/sckott/analogsea/issues/46#issuecomment-59275413.
Carl Boettiger UC Santa Cruz http://carlboettiger.info/
Is there a significant number we should use for the ssh port?
Good question. Presumably the function we use will allow the user to choose their own value for the port, in which case it's tempting to make the default into the ssh default (22) for consistency. For a more secure default I guess we simply want to pick something that isn't commonly used for another purpose (or more strictly speaking, hasn't been registered as the default for some other protocol, see: http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml )
On Fri, Oct 17, 2014 at 7:25 AM, Hadley Wickham notifications@github.com wrote:
Is there a significant number we should use for the ssh port?
— Reply to this email directly or view it on GitHub https://github.com/sckott/analogsea/issues/46#issuecomment-59520261.
Carl Boettiger UC Santa Cruz http://carlboettiger.info/
I don't think we should allow people to choose their own ports. It adds a lot of extra hassle for very little extra security.
On Friday, October 17, 2014, Carl Boettiger notifications@github.com wrote:
Good question. Presumably the function we use will allow the user to choose their own value for the port, in which case it's tempting to make the default into the ssh default (22) for consistency. For a more secure default I guess we simply want to pick something that isn't commonly used for another purpose (or more strictly speaking, hasn't been registered as the default for some other protocol, see:
http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml )
On Fri, Oct 17, 2014 at 7:25 AM, Hadley Wickham <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:
Is there a significant number we should use for the ssh port?
— Reply to this email directly or view it on GitHub https://github.com/sckott/analogsea/issues/46#issuecomment-59520261.
Carl Boettiger UC Santa Cruz http://carlboettiger.info/
— Reply to this email directly or view it on GitHub https://github.com/sckott/analogsea/issues/46#issuecomment-59535851.
I was thinking flexibility might be more along the lines of a user who just happens to be running some other service on the port we happen to choose; I imagine that's the main reason applications let you specify different ports. But that's really unlikely (unless we chose some really silly value) so I guess not worth the hassle
On Fri, Oct 17, 2014 at 10:55 AM, Hadley Wickham notifications@github.com wrote:
I don't think we should allow people to choose their own ports. It adds a lot of extra hassle for very little extra security.
On Friday, October 17, 2014, Carl Boettiger notifications@github.com wrote:
Good question. Presumably the function we use will allow the user to choose their own value for the port, in which case it's tempting to make the default into the ssh default (22) for consistency. For a more secure default I guess we simply want to pick something that isn't commonly used for another purpose (or more strictly speaking, hasn't been registered as the default for some other protocol, see:
http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml )
On Fri, Oct 17, 2014 at 7:25 AM, Hadley Wickham < notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:
Is there a significant number we should use for the ssh port?
— Reply to this email directly or view it on GitHub https://github.com/sckott/analogsea/issues/46#issuecomment-59520261.
Carl Boettiger UC Santa Cruz http://carlboettiger.info/
— Reply to this email directly or view it on GitHub https://github.com/sckott/analogsea/issues/46#issuecomment-59535851.
— Reply to this email directly or view it on GitHub https://github.com/sckott/analogsea/issues/46#issuecomment-59550557.
Carl Boettiger UC Santa Cruz http://carlboettiger.info/
How does this look for a basic config? It:
sudo
)substr(gsub("[a-f]", "", digest::digest("analogsea")), 1, 4)
), forbids root login, and only allows password-less login for analogsea userIf we use this system, it will make it harder to access older droplets, because we'll need to change the defaults for user name and ssh port. I think that's ok - it's a one time breaking change, and substantially improves the default security.
#cloud-config
users:
- name: analogsea
ssh-authorized-keys:
- ssh-rsa <SSH-KEY>
sudo: ['ALL=(ALL) NOPASSWD:ALL']
groups: sudo
shell: /bin/bash
write_files:
- path: /etc/ssh/sshd_config
content: |
Port 6737
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 1024
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin no
AllowUsers analogsea
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes
@wch has convinced me that a non-standard port is probably not that important. It adds a lot of extra hassle for only minimal extra security.
This looks pretty good to me. I think you may need to add PasswordAuthentication no
explicitly when you have UsePAM yes
(even though I think UsePAM
makes sense here), otherwise one can still authenticate using passwords instead of ssh key.
After a bit more discussion with @wch, we have
#cloud-config
users:
- name: analogsea
ssh-authorized-keys:
- ssh-rsa <SSH-KEY>
sudo: ['ALL=(ALL) NOPASSWD:ALL']
groups: sudo
shell: /bin/bash
write_files:
- path: /etc/apt/apt.conf.d/20auto-upgrades
content: |
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
- path: /etc/ssh/sshd_config
content: |
Port 22
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 1024
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin no
AllowUsers analogsea
StrictModes yes
PasswordAuthentication no
ChallengeResponseAuthentication no
RSAAuthentication yes
PubkeyAuthentication yes
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes
runcmd:
- apt-get update
- apt-get install -y unattended-upgrades
Compared to the previous version, this:
PasswordAuthentication
nice!
On Mon, Oct 20, 2014 at 2:25 PM, Hadley Wickham notifications@github.com wrote:
After a bit more discussion with @wch https://github.com/wch, we have
cloud-configusers:
- name: analogsea ssh-authorized-keys:
- ssh-rsa
sudo: ['ALL=(ALL) NOPASSWD:ALL'] groups: sudo shell: /bin/bashwrite_files: - path: /etc/apt/apt.conf.d/20auto-upgrades content: | APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1";
- path: /etc/ssh/sshd_config content: | Port 22 Protocol 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsakey UsePrivilegeSeparation yes KeyRegenerationInterval 3600 ServerKeyBits 1024 SyslogFacility AUTH LogLevel INFO LoginGraceTime 120 PermitRootLogin no AllowUsers analogsea StrictModes yes PasswordAuthentication no ChallengeResponseAuthentication no RSAAuthentication yes PubkeyAuthentication yes IgnoreRhosts yes RhostsRSAAuthentication no HostbasedAuthentication no PermitEmptyPasswords no X11Forwarding yes X11DisplayOffset 10 PrintMotd no PrintLastLog yes TCPKeepAlive yes AcceptEnv LANG LC* Subsystem sftp /usr/lib/openssh/sftp-server UsePAM yesruncmd:
- apt-get update
- apt-get install -y unattended-upgrades
Compared to the previous version, this:
- Keeps ssh port as 22
- Explicitly disables PasswordAuthentication
- Sets up automatic security updates
— Reply to this email directly or view it on GitHub https://github.com/sckott/analogsea/issues/46#issuecomment-59842423.
Carl Boettiger UC Santa Cruz http://carlboettiger.info/
looks great @hadley - should we allow input to modify this setup within analogsea
, or just tell users to ssh in and change as needed?
@sckott I'll make it a little configurable, once I turn it into an R function. But this is a script that's run once on droplet creation, so it's not possible to modify after the fact.
Do you want to install & configure a ufw
firewall at this time as well?
Would either mean hardwiring the port used for RStudio or providing a way
to ufw enable
it later.
On Mon, Oct 20, 2014 at 2:36 PM, Hadley Wickham notifications@github.com wrote:
@sckott https://github.com/sckott I'll make it a little configurable, once I turn it into an R function. But this is a script that's run once on droplet creation, so it's not possible to modify after the fact.
— Reply to this email directly or view it on GitHub https://github.com/sckott/analogsea/issues/46#issuecomment-59843822.
Carl Boettiger UC Santa Cruz http://carlboettiger.info/
@hadley sounds good
@cboettig I don't think a firewall is sufficiently useful that we should install it by default.
This now appears to be working - you can use the default ubuntu config with droplet_create(cloud_config = "ubuntu")
.
I think the next question is whether we should enable this by default (I think so), and if so, how should we manage the transition? One option is to change the default in droplet_create()
to cloud_config = "ubuntu"
and then change the default username in droplet_ssh
to analogsea. This will make it harder to connect to old droplets, but I think the tradeoff is worth it.
I like this plan
Carl Boettiger http://carlboettiger.info
sent from mobile device; my apologies for any terseness or typos On Oct 21, 2014 8:11 AM, "Hadley Wickham" notifications@github.com wrote:
This now appears to be working - you can use the default ubuntu config with droplet_create(cloud_config = "ubuntu").
I think the next question is whether we should enable this by default (I think so), and if so, how should we manage the transition? One option is to change the default in droplet_create() to cloud_config = "ubuntu" and then change the default username in droplet_ssh to analogsea. This will make it harder to connect to old droplets, but I think the tradeoff is worth it.
— Reply to this email directly or view it on GitHub https://github.com/sckott/analogsea/issues/46#issuecomment-59943285.
Hmmm, I wonder why ssh-authorized-keys
(to allow specific ssh keys) is not included in the config file. Is there a reason why not?
late to the party (mostly due to me resurrecting harbor
and re-doing the analogsea
harbor
interface within harbor
for it.
I have empirical evidence (this is part of what I do for a living ;-) that changing the default port to something besides 22 does in fact enhance security greatly. It's a tiny obfuscation step but thwarts a big percentage of opportunistic attackers. It won't stop a determined one but nothing will, so it's worth it to change it.
I will agree that having a different universal default ssh port embedded in analogsea
is not going to improve security since once various attacker groups who scan the internet find it out (and will since I commented in here now — apologies, but I get followed around :-)
Why am I blathering on about ports? All my droplets but 1 (which is a partial honeypot as well as a functioning web server) use a different ssh port and was pretty much unable to use droplet_ssh()
@sckott any issues if I (eventually…can't promise a timeline right now) add a port='default'
parameter to the functions in https://github.com/sckott/analogsea/blob/master/R/droplet-ssh.R and if it's not default
then have the functions use the specified port? That way, folks like me who make a droplet outside of this pkg or reconfig one that uses this pkg can still use the commands for automation (and, eventually, harbor
) but "regular" folk won't even need to worry about it?
+1 for other than 22 port - what should that port be? a random port number between number x and y?
the port
param sounds good to me.
Aye. It could be a small-ish range, too. We could also add some links to things like https://github.com/fail2ban/fail2ban or add a helper function to install it on images. I'll noodle over some possibilities.
thanks
Not sure what these should be. Some ideas: