Web Infrastructure/Policy

Latest revision as of 13:10, 21 December 2012

The policies on this page are aimed at administrative use of the Mer systems.

[edit] Shell Access

There are no firm guidelines for access to infrastructure systems. We operate a validated trust approach and require consensus from a number of members of the IT team to grant access.

There are multiple levels of trust:

• No shell access : This is the norm. Very few people have shell accounts to any systems. There must be an extremely compelling reason to provide shell access.
• Shell user : When granted, access will normally be at this level.
• VM root : In exceptional cases for highly trusted people with significant sysadmin knowledge we will provide root access to a virtual machine. Having root access means you take direct responsibility for the security of the machine. These users are given access to IT Private bugs.
• Superadmin : The superadmin team is the core IT team - invitation only :)

[edit] SSH Keys

Access is provided via ssh keys and not passwords.

Users are expected to take security of ssh private keys very seriously.

• Private keys are strictly private to an individual. If they are disclosed to anyone, under any circumstances please let IT know AT ONCE. It's easy to change them.
• You should have a dedicated ssh key for use for merproject.org access
• ssh keys must be protected by a strong pass phrase (ssh-agent and ssh-add makes this un-noticeable)
• ssh keys use must be confirmed before every use (ssh-add -c). This is usually a simple pop-up from ssh-askpass
• ssh private keys must never be checked into a git repo which could compromise them
• ssh public keys must never be obtained from a git repo which could lead to loose access controls
• Onward access from the jump host is by tunnel - no ssh or agent-forwarding
• The comment on your public key should be descriptive, such as an email address, as much as your pet name is funny, its not to the point.
• If you use a mobile device(phone, tablet, etc) please consider using a separate key for that device and not accessing critical infrastructure with that mobile device directly.

If you have any problems with implementing any of these rules then please talk to one of the IT team - they want you to get it right and will do their best to help you. (And it may help to know that they too will have struggled with ssh once upon a time!)

If you think you need an exception to a rule (eg group access, password access, unattended/cron access etc) then we'll be glad to help solve the problem you face. It's much better to get help to implement a secure solution than to "just" do something to make it work.

The following snippet can be usefully added to your .ssh/config (note you need to change the <USER> to your merproject.org shell account name)

Host *.merproject.org
    User <USER>
    IdentityFile ~/.ssh/id_rsa_mer
    ServerAliveInterval 60
    ForwardAgent no

Host access.merproject.org
    ProxyCommand none
    Port 2222

Host *.in.merproject.org
    ProxyCommand ssh -q access.merproject.org netcat %h 22

access fingerprint is

a7:76:65:4d:89:2d:df:02:81:68:64:2a:20:b5:56:a8

Notes:

• The strong passphrase means that if your computer is stolen then the attacker won't be able to use your key to access your account.
• The askpass confirmation means that if a man-in-the-middle attack is attempted then your agent should prompt you when you didn't just establish a connection. If this happens then refuse the request.
• Agent forwarding means a compromised jump host would be able to spoof an onward connection as your account

[edit] Bugs

The Mer IT team have 2 bug products: Mer IT Private and Mer IT. We use the private one for bugs which discuss secure or confidential information; sometimes we'll make a public bug private or a private bug public. The criteria are not well defined but in general we don't discuss specifics of our installation in public. Whilst we do not operate "security through obscurity", nor do we claim to be infallible - limiting information means that when we make errors, the information is less likely to leak and the window that we have to rectify the error without discovery should be larger.