Standard Security Environment

Standard CSAIL Linux security practices

minimum password complexity:

Per-host failed ssh connections:

Reactive port filtering blocks remote hosts by IP after 4 failed ssh Reactive port filtering blocks remote hosts by IP after 4 failed ssh authorization attempts within 20min (may be for one user or four different users). Lock clears at minimum of 7 minutes of last failed attempt.

System wide failed password attempts:

To prevent distributed password guessing across a large number of connected systems individual password authentication is centrally blocked using the following policy:

Linux security patches:

Any vendor updates marks as “security updates” are automatically applied daily and at reboot. Systems are not automatically rebooted for kernel patches though the message of the day displayed on login is updated to indicate if there is a “reboot needed”. Optionally a class of system could be configured to reboot either as soon as kernel updates happen or at a given time of day if a kernel update has been applied.

Physical access

CSAIL Physical access

Server rooms in Stata are prox card controlled cabinets are locked but keying is common (all keys open all racks). After business hours there are two more locked prox carded doors, but during the day these doors are unlocked.

MGHPCC Physical access

It is strongly recommended secured data be stored in MGHPCC

CSAIL also has server space in the Massachusetts Green High Performance Computing Center (MGHPCC https://www.mghpcc.org) which has extensive physical security and access controls, which unfortunately require a facility access account to even see, but the short version is:

There’s a security desk which checks identification against an restrictive access list to check out the following keys:

TIG (or most of TIG) has access. Path to a server involves security check, leaving ID at desk, general access locked door, machine-room locked door, “pod” locked door.