4/18    Some thoughts about securing a machine.  Feel free to add your
        expert opinions. --ricky
        * Securing a machine that allows interactive logins by users
          is _very_ hard.
        * Reduce suid binary to absolute bare minimum.
        * Perform automatic _remote_ checksums from a machine that is
          separate and is not accessible by regular users.  Usually,
          NFS is recommended for this.  Basically, have a remote
          machine regularly check critical files on the machine and
          alert root if anything changed.
          \_ This existed a while ago, called Tripwire. Started as a
             a research project and grew to a startup. Many people tried
             it but gave it. The concept is easy, but in practice, it takes
             damn too much time. All of the above suggestions are good,
             but in the end, if the cost of manageability is high, no
             one will care. Lastly root and politburo aren't paid to do any
             of the above stuff and most people have better use of their
             time so... why cares. Would YOU like to volunteer
                \_ Why are suggestions being taken as a demand that they
                   do it.  If alumni (or "members") do all this stuff, aren't
                   they just "fucking the undergrads" ?
                   \_ No.  If they storm into the machine room or the office
                      and insist that it be done there way and be done right
                      this minute, then they are fucking the undergrads.
                      Historically, asking nicely and accepting a polite `No.'
                      is not one of the strong suits of the alumni.  Though
                      anecdotal, it's also worth noting that the amount a
                      given alumnus bitches appears to be inversely
                      proportional to the amount of meaningful contributions
                      (time, money, hardware, etc.) he makes to the
                      organization. -dans
                      \_ so you contribute absolutely nothing, eh?  -tom
                         \_ Ah let me clarify that.  The amount a given
                            alumnus bitches at the current undergrads appears
                            to be inversely proportional to the amount of
                            meaningful contributions he makes to the
                            organization.  If the alumni bitch at each other,
                            it has no bearing on the CSUA or its future.
                            -dans
             doing these things ricky? You should attend politburo.
             \_ Agreed, I tried to set up a modern version of tripwire on
                hosts I administered in my last job, and it's nigh unusable.
                It smacks of overengineering, and has too many features
                apparently added by marketing folks trying to sell to the
                enterprise software market.  Furthermore, if you want to be
                really secure, running _remote_ checksums isn't good enough
                since the credentials for soda are likely the same as the
                credentials for other CSUA hosts.  Thus, checksumming soda's
                binaries from screwdriver takes a non-trivial amount of work
                for a trivial gain.  Also, what happens when people trojan
                libraries not binaries?  Should we checksum those to?  Which
                libs? -dans
                \_ ideally you checksum everything, and flag what is 'volatile'
                   and likely to change from day to day.
                   \_ ideally, yes, but that's a really time consuming,
                      tedious, manual process.  Unless you have some '1337 tool
                      to do that for us.  If so, please post a url. -dans
             \_ I have used aide, a tripwire-like tool that checksums files
                in two ways. It works pretty well, and isn't that difficult to
                use.  I found it annoying if I didn't check/update signatures
                before doing package upgrades, which meant I couldn't tell
                whether the changes were intentional from the update or if
                someone had done something to the binaries the same day.
                While there are certain more-secure "ideal" ways to set things
                up (binary on immutable media, running on a separate system,
                database on immutable media, etc.) A simple "on this system"
                "aide running out of /usr/sbin" "database stored locally" while
                not great from a security standpoint, as long as one doesn't
                rely on the lack of warnings and messages to mean you are
                secure, is still a useful tool.
        * Educate users about ssh.  For example, unless the user is
          extremely certain that their private keys are safe (resides
          in encrypted partition, etc.) having empty passphrase is a
          bad idea.  Assuming above is met, using passphrase protected
          key pair and setting up authorized_keys is safer than using
          passwords.
          \_ Education works the best, when people are willing to
             be educated. Do you think people like to be educated?
        \_ It's also vital to keep up with patches to OS and utilities.
           \- ssh wont solve the problem. the problem is a combination of
              clueless users and users who dont care about security [and
              are willing to login from machines with kbd sniffers]
              combined with the close to inevitability of local account ->
              local exploit -> root. i think sloda should adopt the
              position: 1. soda will be broken into and should not be
              trusted ... meaning it should not be used as an outbound
              stepping stone ... no rsh, rlogin, ssh, telnet. i suppose
              you can leave ftp on and i guess scp. 2. do what you can
              about prevention [applying patches etc but also invest some
              in rapid detection. tripwire is a piece of crap but there are
              other tools to do this with ... i maintain checksums on about
              50 things [in some cases OSes, in other cases various data
              trees] and while i dont look at all the data everyday, with
              disk being cheap i can store enough snapshots i can at least
              go back and tell a story if there is a problem found at some
              point. even a half asses checksumming system will get you
              pretty far ... and would certainly pickup a trojaned daemon
              or client. we have some not-very-portable hacks to address the
              case of trojaned libs [these check low level information in
              inodes and compare them to higher level queries and look
              for inconsistencies ... like say in the link count] but these
              are probably not worth the effort ... they were crafted for
              very specific rootkits.