Outline of Security Issues
University of Florida
Department of Statistics
 
10/01/98
Purpose:    The purpose of this document is to serve as a focus tool in the implementation of better security within the department.  There are many issues to consider and many directions to take.  This is simply an outline proposing where we might want to go and the issues related to getting there.  This is all up for discussion and dissection.
Easy Objective:    "The Club effect" -- Provide enough up-front visible security so that any would-be cracker would rather move on to some other easy target (Math Department) than take time with us.

Primary Objective:    Implement and maintain a base line security model by which user data and research data is secured from inappropriate access.  This model would address the following areas...

Policy & Procedures

User accounts
 

Who gets an account? 
  • Statistics faculty, staff, & students
  • Non-Statistics faculty, staff, & students
  • Research Collaborators

    • Account Closures 

  • 3 months after departure
  • 6 month extension with sponsorship
  • Account dumps to CD or tape

    • User Data 

  • "users" files (aka machines file)
  • LDAP directory
  • What data to store about a user

    •  
    Passwords 
  • Password Length (8 char min?)
  • Character requirements?
  • Dictionary checks
  • Expiring passwords?
  • Password Reuse?

    • System Procedures 
    Need to define what procedures we as system staff need to follow that could impact security overall.  Our system staff has grown to the point where we need a concerted effort to be sure we maintain consistency across the entire system.  A breakdown in one area of the system is a breakdown in the entire system. 

  • Backups (frequency and storage)
  • Monitoring (each responsible for monitoring their specific domains)

    • etc.
     

    Securing the Environment

    Local Sessions / Remote Sessions
     

    Primary concern for local sessions is the encryption of the authentication process over the local network used by various services.  Secondary concern would be the encryption of the data itself as it moves over the local network. 

    Remote sessions can be defined as client/server interaction with a machine outside the stat.ufl.edu domain.  This includes home users who dialup via GatorLink or some other ISP, remote users from networks outside the ufl.edu domain, and on campus users (research collaborators for example)  in other departments who have need to interact with our system. 

    In most cases the same issues apply equally to both local session and remote sessions.   For remote sessions we should be in a position to support additional platforms not in use locally; i.e. Linux, NT. 

    SSH for rlogin, rexec, rcp, X 

  • Workstations
  • PCs (which clients, freeware vs. commercial)
  • Macs (?)
  • Reduce inetd service dependencies on in.telnetd, in.rshd, in.rexecd, in.rlogind, etc. (note: I don't see us completely removing the in.telnetd entry as we should have a mechanism in place for "local" login to a machine (besides console) in case of the failure of SSH.  Controlled and logged by tcp_wrappers and restricted simply to picard@somemachine (for example).  This would be a back door for system staff.  Comments???

    • SMB Services 

  • secure login for SAMBA
  • independent passwd map, NIS make
  • SMB browsing (do/don't)
  • access restrictions by domain.

    • Hummingbird Exceed (X on the PC) 

  • investigate security mechanisms provided by the vendor
  • investigate use in conjunction with SSH.

    • Mail Services (POP, IMAP) 
    Non-issue for most workstation mail clients as they'll use local file services to access mail not in a client/server relationship. 

  • Supported Apps for POP, IMAP
  •     Communicator
  •     Pine/PC-Pine
  • Investigate use of SSL, APOP, KPOP to encypt authentication

    •  
    FTP 
  • Anonymous FTP
  • Account FTP to only primary servers.
  • Adequate logging of FTP access.

    • Finger 

  • Restricted to only the primary servers.
  • Adequate logging of finger access.
    		•
     

    The Front Door
     

    For each service we need to define who has authority to access our system from the outside coming in. 

    To shutout our recent cracker we took the drastic measure of shutting down telnet, rlogin, rexec, etc from all remote sites only trusting nerdc, cise, and vpha.   With SSH in place we can continue such a policy and only allow encrypted remote sessions to our hosts.  This does place additional burden on remote users and I don't know of any other department on campus with such a stringent policy.  Key to making this work is to provide educational material and resources (access to the proper tools) available to remote users by way of a web page that describes our policy and they're options for interaction with our system. 

    SSH is only part of the game.  Remote email via POP and IMAP apply as well as many other services.

    System Monitoring and Intrusion Detection
     
     

    Should develop a set of automated scripts that run periodically from cron that would go out over the system and look for suspicious activities in the logs, against running processes, etc.  Lots of details to fill in here....
     
  • Make good use of Meter logs
  • Look for root sessions
  • Look for IRC type activities
  • etc...

    • Tools

  • tripwire to check for changed system binaries
  • lsof to show open files/connections (only allow to run as root)
  • etc...
    		•

    User Education
     
     

    We should provide a series of web pages for the purpose of educating our local and remote users to the importance of good security practices.
     
  • Define reasons for security
  • Provide access to proper tools with detailed instructions on their use
  • Provide information on proper management of local file system and file permissions.
  • etc...
    		•
     

    Additional Considerations
     

    NFS 
    NIS vs NIS+  (should at least change our NIS domain name from stat to something less guessable) 
    Single authenticating login via LDAP or Kerberos. 

    Resources
     

    SSH HomePage 
    SSH FAQ (don't know if this is official or the most updated?) 
    TTSSH Win95 client   (documentation)
    Win95 SSH Client     (documentation)
    Crypto DLL for Win95 required for Win95 client above 
    RedHat RPM SSH 1.2.26 
    SAMBA
    SAMBA Encryption Document
    Solaris Security FAQ 
    RootShell.com 
    Squirrel.com Security Links 
    Wietse's collection of tools and papers 
    Dan Farmer's Security Links