Skip to content. | Skip to navigation

Personal tools

Navigation

You are here: Home / Wiki / Securitynotes

Securitynotes

This file contains notes about the security of the tesbed, and what should be done to enhance it. These notes are fairly old, so if there are conflicts with more actively maintained files like setup*.*, believe the latter. For newer info, see the files "security-all.ppt" and "build-operate.ppt" in http://www.cs.utah.edu/flux/testbed-docs/internals/

  1. Switches/Infrastucture hardware:
    1. Rules need to be set up on the control switch to restrict the IP/MAC that can be used on each port
    2. SNMP on the switches, power contollers, and anything else that uses it should be restricted to boss's IP/switch port.
  1. Firewalling:
    1. Block outgoing connections from testbed nodes to the CS network
      • This is because something on this network may have (misguided) trust in them (especially boss/ops) (note: This may be less important when we're on our own subnets, as CS shouldn't be trusting them at all)
    2. May want to block outgoing connections on specific ports to all IPs - for example, the SMTP port, to prevent people from using testbed nodes as spam mailhubs. Then again, this may be too restrictive, while giving few/no real advantages.
  1. Filesystems:
    1. Home directories should be exported only to nodes currently running experiments that the user is involved in (will be secure because of item 1.1)
    2. Home directories on ops should be mounted with the 'nosuid' and 'nodev' options on ops and boss - users could, on their test nodes, create set-uid root programs, or make device nodes that they are allowed to read an write to. The same is true for whatever filesystem you place /proj on; it should be mounted nosuid.
    3. Remove suidperl binary on ops (doesn't get installed on latest FreeBSD versions anyway) - See FreeBSD mount manpage for reason. Related to item 3.2
    4. All testbed nodes, and ops (any maybe boss too?) should NOT be able to mount our NFS server(s) or CS's. Could happen either through firewalling or rules on the NFS servers.

  1. Passwords
    1. Testbed node root passwords are problematic. Testbed nodes should definitely have a root password that is not used anywhere else. Maybe they should have no root password (an invalid hash, not a blank one) and just trust boss to login as root via ssh. If someone who has local_root for a project crack a node's root password, then they can get root on other project's nodes, or the same node later, when another project owns it. Then again, maybe we don't need to set our security stanards quite that high.
    2. It would be reasonable to share a root password between boss and the Cisco's. Having root on boss will mean that someone will have access through SNMP, etc. to the ciscos, and having the enable passwork to the ciscos will allow someone to bypass our protections in section 1 and spoof boss, so they are essentailly equivalent.
    3. ops should have a unique root password - we don't want to have it the same as the testbed nodes (easy access to crack), but we want to make root compromise of ops not lead to the root compromise of boss.
  1. User policies:
    1. Flux'ers accounts on ops and testbed nodes should not have standard passwords (people may be able to get encrypted string and crack).
    2. No accounts on ops should have 'special privileges' - we need to assume that any account on ops can be compromised
    3. NO special passwords should be typed on ops or the testbed nodes. This means don't telnet to the switches, ssh to any machines other than the testbed nodes, etc.