Goals

• Availability - Keep the services up and running.
• Integrity - Prevent our Internet presence from being vandalized or subverted.
• Traceability - Track who did what, when. Needed for change control and as a best practice.
• Authenticity - Making sure admins really are who they say they are is important. Otherwise, this is a lower priority for us; most stuff is cleartext and public.
• Privacy - Generally not a priority for us. Most of what we do is public by nature and intent. Still, some things (e.g., root password) will need to be protected.

Account Restrictions

• All people have their own user account on the system.
• No direct root logins. Login to user account first, then sudo. This gives us both enhanced security and traceability.

sudo to shell

It is proposed that we strictly avoid sudo'ing to a shell (e..g., "sudo /bin/sh"), or wrap such things in an automatic invocation of script(1) to log the entire shell session. Traceability again.

Yes, this make things more difficult, but traceability is needed when there are multiple admins. Note: I could be coaxed off this requirement if sudo would fire up a capture program (like script) when 'sudo <shell>' is used.

• I much prefer autostarting script if 'sudo shell' is run - flexible and easy. Creating time/original user named logfile in standard location would be ideal. (e.g. 2006_02_10_11_53_billm.log) -- DrewVanZandt - 10 Feb 2006

• Some things that require shell redirection don't work without this - however those can be put into a script and run 'sudo script'. But then the script is fungable after the run, so what's been gained is worth debating. -- BillMcGonigle - 08 Feb 2006

OTP for sudo

• OTP (OPIE or some other S/Key) for sudo access. -- MikeLedoux - 13 Feb 2006 Are there any links for those who aren't familar with these? -- BruceDawson - 13 Feb 2006 Both implement your standard challenge/response one time password, and plug in to sudo fairly easily. A quick search didn't find any information that doesn't presume familiarity, I'll see if I can come up with something better tonight. -- MikeLedoux - 13 Feb 2006

Firewall

• iptables - unless there is some other level of firewalling available to us.
  • even if there is a hardware firewall, don't trust it. To expound, only allow incoming access on the minimum number of ports to get us going. We should restrict ssh access to a limited number of IP's to avoid being DDOS'ed with ssh scans. -- BillMcGonigle - 09 Feb 2006
  • Allowed Ports From Anywhere
    • 25/tcp
    • 80/tcp
    • 443/tcp
    • 53/udp
  • Allowed IP's for port 22 ssh
    • 217.160.248.65 -- BillMcGonigle - 09 Feb 2006
    • Recommend moving SSH to nonstandard port. Scripted attacks only hit 22. -- DrewVanZandt - 10 Feb 2006
      • I've been port-scanned for ssh running on non-standard ports. -- BillMcGonigle - 11 Feb 2006
    • All except non-routable IP's. But run ssh on a non-standard, non-privileged port.
      • I postulate that restricting ssh access to a small set of IP's is more secure than having it open to the world. It avoids all the script-kiddie issues, for instance. So, there should be arguments here for why we'd want to accept a less-secure method in the face of known attacks. -- BillMcGonigle - 11 Feb 2006
    • Suggest running SSH on a nonstandard port -- ColeTuininga - 10 Feb 2006
  • Allowed Ports for our backup DNS, currenly LINUX.CODEMETA.COM (199.125.76.10)
    • 53/tcp

Remote Access

• SSH - Require public key authentication, require entries in AllowedUsers in sshd_config. Inconvenient for adding new accounts, but the number of accounts will be very low and we don't have time to deal with getting cracked. -- BillMcGonigle - 11 Feb 2006
• Opinion - I am aware this could cause flames, sorry. Cracking will probably not be from password guessing etc. (especially if on nonstandard port, and we stick to decent passwords e.g. gpw or whatever) - it will be a vulnerability in a service we run. Minimal exposure to the outside world would be good. :-)