Consider better security defaults

[hadley]

Not sure what these should be. Some ideas:

• Create non-root user
• Add basic firewall
• Other stuff from here: https://www.digitalocean.com/community/tutorials/an-introduction-to-securing-your-linux-vps

[sckott]

• firewall Maybe start with the easiest solution (ufw) https://www.digitalocean.com/community/tutorials/how-to-setup-a-firewall-with-ufw-on-an-ubuntu-and-debian-cloud-server which they describe as generally a good choice
• non-root user hmmm, after reading the bit on this, still not sure if needed or not, or should it definitely be done? @cboettig any thoughts?
• ssh login they say prefer ssh keys over passwords, which we should suggest to users i think

[cboettig]

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.

[sckott]

@cboettig thanks for the quick feedback and the script share!

[sckott]

We still need to consider better security defaults whether or not a user uses docker, right?

[hadley]

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.

[sckott]

right, ok

[hadley]

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):

• Create a new user with adduser
• Configure user for passwordless login (should just be copying a file)
• Add line to sudo config
• Modify default ssh port - I think using the same non-standard port for all droplets would be fine.
• Disable root login via ssh
• Reload ssh

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.

[cboettig]

Just a note I've updated my script, though could no doubt be much improved.

• It does the user configurations for ssh Hadley mentions above (though with 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).
• It sets up the firewall, expecting you to define the ports used for SSH and RStudio (or it will use the defaults).
• Runs some other things, including a system update.

(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

[hadley]

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

[cboettig]

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 [email protected]
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
#46 (comment).

Carl Boettiger
UC Santa Cruz
http://carlboettiger.info/

[hadley]

Is there a significant number we should use for the ssh port?

[cboettig]

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 [email protected]
wrote:

Is there a significant number we should use for the ssh port?

—
Reply to this email directly or view it on GitHub
#46 (comment).

Carl Boettiger
UC Santa Cruz
http://carlboettiger.info/

[hadley]

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 [email protected]
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 <[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');>
wrote:

Is there a significant number we should use for the ssh port?

—
Reply to this email directly or view it on GitHub
#46 (comment).

Carl Boettiger
UC Santa Cruz
http://carlboettiger.info/

—
Reply to this email directly or view it on GitHub
#46 (comment).

http://had.co.nz/

[cboettig]

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 [email protected]
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 [email protected]
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 <
[email protected]
javascript:_e(%7B%7D,'cvml','[email protected]');>
wrote:

Is there a significant number we should use for the ssh port?

—
Reply to this email directly or view it on GitHub
#46 (comment).

Carl Boettiger
UC Santa Cruz
http://carlboettiger.info/

—
Reply to this email directly or view it on GitHub
#46 (comment).

http://had.co.nz/

—
Reply to this email directly or view it on GitHub
#46 (comment).

Carl Boettiger
UC Santa Cruz
http://carlboettiger.info/

[hadley]

How does this look for a basic config? It:

• sets up a non-root login (analogsea) with sudo privileges (will need to update all existing scripts to use sudo)
• sets custom port for ssh (6737 = substr(gsub("[a-f]", "", digest::digest("analogsea")), 1, 4)), forbids root login, and only allows password-less login for analogsea user
• sets shell to bash

If 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

[hadley]

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

[cboettig]

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.

[hadley]

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:

• Keeps ssh port as 22
• Explicitly disables PasswordAuthentication
• Sets up automatic security updates

[cboettig]

nice!

On Mon, Oct 20, 2014 at 2:25 PM, Hadley Wickham [email protected]
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_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 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
#46 (comment).

Carl Boettiger
UC Santa Cruz
http://carlboettiger.info/

[sckott]

looks great @hadley - should we allow input to modify this setup within analogsea, or just tell users to ssh in and change as needed?

[hadley]

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

[cboettig]

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 [email protected]
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
#46 (comment).

Carl Boettiger
UC Santa Cruz
http://carlboettiger.info/

[sckott]

@hadley sounds good

[hadley]

@cboettig I don't think a firewall is sufficiently useful that we should install it by default.

[hadley]

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.

[cboettig]

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" [email protected] 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
#46 (comment).

[sckott]

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?

[hrbrmstr]

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?

[sckott]

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

[hrbrmstr]

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.

[sckott]

thanks