University of California at Berkeley Department of Electrical Engineering & Computer Sciences Instructional & Electronics Support /share/b/pub/security.help July 20, 2015 Security on the Instructional Systems ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CONTENTS Protect yourself! Passwords SSH: Secure login and file transfers to UNIX SSH Host Keys File permissions Unattended logins X Windows Security File encryption Mail encryption "set uid" programs are not allowed in home directories .rhosts files are obsolete Off-campus Network Access Reduced Other Links Protect yourself! ---------------- Users of the UNIX systems should be aware of these features which, if used improperly, can allow people to break into an account, read or delete files, and use the account for other malicious purposes. Passwords --------- Your password is your best defense against users accessing your account from remote computers. With increasing frequency, malicious people are running "crack" programs that can guess passwords that are based on dictionary words and user information displayed by "finger" (your name, login, or etc). So you should pick a password that is not easily guessed and be careful to keep it private. You may change your password as often as you wish. SSH: Secure login and file transfers to UNIX -------------------------------------------- You should use the SSH commands "ssh", "scp" and "sftp" to login and do file transfers to our UNIX systems. For more information, see http://inst.eecs.berkeley.edu/connecting.html If you have an Instructional UNIX account, you can download SSH for your home computer from http://inst.eecs.berkeley.edu/download-ssh.html In an effort to protect our UNIX systems from outside intrusions, we deny logins from over the net unless they come from an "ssh" enabled program at your end. This protects your password from network sniffing. The standard "telnet", "rlogin" "rsh" and "rcp" programs are not allowed into any EECS computer. SSH is available on all Instructional computers. For more information, please see /share/b/pub/ssh.help SSH Host Keys ------------- The SSH hostkeys for all Instructional UNIX systems are now accessible in http://inst.eecs.berkeley.edu/~inst/hostkeys/ and /share/b/hostkeys. If you get a "man in the middle" security warning, you can check there for confirmation that we have really installed a new hostkey. For an explanation of "host keys", please see /share/b/pub/ssh.help. File permissions ---------------- UNIX file permissions on a given file can be viewed with the UNIX command "ls -al ". File permissions are controlled with the commands "chmod", "chgrp" and "umask". Users are advised to be aware of the permissions on their files and directories and to read the man pages for these commands. It is strongly discouraged to have files or directories that are writable by anyone but the owner. Unattended logins ----------------- If you login in at a workstation and then leave, you are leaving yourself open to attack. Others can sit there and use your account as if they were you. So don't leave your login sessions unattended. X Windows Security ------------------ In the early versions of X Windows, security limited access to a specified computer, but allowed EVERY user logged in at that computer to access the X Window server. If you logged in at a workstation and someone else logged into it over the network, that person could pop up an xterm on your screen or even run a program that read the keystrokes that you were typing. For example, if you typed "xhost +cory.eecs", ALL users on cory.eecs would have that same access as you to your X server. This security hole has been plugged with the "xauth" utility. When you first login at a workstation, a file called .Xauthority is automatically created or updated in your home directory. The "xauth" program accesses this file. .Xauthority contains a key, or "MAGIC-COOKIE", that "locks" your display. If another user tries to access your X server, the attempt will succeed only if that user has a copy of your key is his/her own .Xauthority file. If you are working on different computers that share your home directory (such as the Instructional systems), you do not need to use "xhost" or "xauth" at all. Wherever you are logged in, you will be referencing your own single .Xauthority file and the key that's in it. But if you wish to allow access to another user (or another account of your own), you will need to give your MAGIC-COOKIE key to that user so the user can add it to his/her .Xauthority file. Here's an example of one way to do that: ------------------------------------------------------------------------- Given: You are logged in at an Instructional workstation, say "ike.cs". You are also logged into another account, say "soda.csua". You type (ike% represents your prompt on ike): ike% xauth list | grep ike ike.cs:0 MIT-MAGIC-COOKIE-1 cc779d8af890dc478db0d03ea03b0ac7 ike.cs:0 XDM-AUTHORIZATION-1 bbf36d10c2a916f00002b979617dab11 The output of the xauth command appears on the screen. Then, on your other account, you would do the following: soda% xauth xauth> add ike.cs:0 MIT-MAGIC-COOKIE-1 cc779d8af890dc478db0d03ea03b0ac7 xauth> exit soda% setenv DISPLAY ike.cs:0 soda% xterm and an xterm window should pop up on the ike.cs console screen. Obviously, instead of typing in the whole MAGIC-COOKIE line, you could just use the mouse to paste it in. Here is a one-line method of doing that: ike% xauth extract - $DISPLAY | rsh pauli xauth merge - Thus requires that you can "rsh" from one account to the other; this is best enabled using Kerberos (see /share/b/pub/kerberos.help). Note also that the X authorization scheme has changed between different releases of X11. If the X program you are trying to run was compiled with older X libraries, then this might not work. In that case, you will probably have to fall back on host-based access control, using a command such as: ike% xhost +soda This will let _anyone_ on Soda access your X server. Some people know how to access an X server to read all keystrokes typed there, so by allowing unknow users to have access you are taking a security risk. ------------------------------------------------------------------------- Two security notes: - When typing a MAGIC-COOKIE, do it within the interactive "xauth" program. Avoid entering it on a command line, because the text of a command line can be seen by anyone using the "ps" command. - Be sure your .Xauthority file is readable and writable only by you. In an "ls" listing, it should look like: -rw------- 1 your-login 49 May 10 15:41 .Xauthority Please read "man xauth" for more details. File encryption --------------- UNIX has several commands with which you can encrypt and decrypt a file using a key (like a password) of your own choice. These commands include "crypt", "bdes -k" and "bdes -d". See "man crypt" and "man bdes" for usage. Mail encryption --------------- Mail to and from other users can be encrypted by use of the 'pgp' command. For instructions on setting this up, see 'man pgp' and http://www.pgp.com/ "set uid" programs are not allowed in home directories ------------------------------------------------------ We do not allow suid programs on exported, writable filesystems such as your home directory. This avoids the risk of this scenario: a cracker becomes superuser ("root") on one NFS client computer (such as a UNIX workstation in a lab), plants a set-uid-to-root program on the insecure NFS-mounted file system, logs into related NFS clients and servers as a non-root user and uses the program to become "root" on all those systems. We assume that the client systems in the labs are more vulnerable to root breakins than the servers are, if only because users can reach the power switch. So we limit suid programs to a filesystem that is exported read-only and is served from a system that does not allow user logins. That is the Instructional /share/b filesystem. Blocking this for "root" user (superuser) owned programs also blocks it for all other users. If you wish to run a suid program, the sys admins have to install the program on the /share/b filesystem for you. While that does create a hassle for users who wish to run their own suid programs, there is a work-around during the development of such a program. You could test the program by placing the suid binary in the /tmp directory on our UNIX computers, as /tmp is not exported and therefore not subject to the suid restriction. .rhosts files are obsolete -------------------------- .rhosts files and the related UNIX commands (rcp, rlogin, rsh, remsh, etc) are insecure and are not supported or allowed on EECS computers. These commands would bypass password security using insecure network protocols. Off-campus Network Access Reduced --------------------------------- The UC Berkeley campus network security (SNS) group has announced that as of 12:00 noon, Friday, September 12 2004, several network ports used by Windows are being blocked at the campus border. The ports that are blocked are TCP/135, TCP/139, TCP/445, TCP/593, UDP/135, UDP/137, UDP/138, and UDP/445. The impact of these blocks is that several Microsoft services including file sharing, access to Exchange mail servers, and remote desktop access will not function across the border of the campus network. This is necessary to stop the spread of several fast-moving and destructive viruses. At home, you may see error messages in Windows such as "Access denied" "The network path was not found" "Unable to connect because the RPC server is unavailable" when you try to access computers on campus. This does not prevent access to any campus WEB sites. Logins into UNIX systems are uneffected. So to transfer files between your Windows computer at home to your Instructional Windows directory on Fileservice, you can use your UNIX account as a transfer point: 1) Login to UNIX (such as cory.eecs.berkeley.edu) with SSH Secure Shell 2) Use the SSH Secure File Transfer program to copy files between your Windows PC at home and your UNIX account 3) Use the UNIX "smbclient" command to copy the files between your UNIX directory to your Windows directory. Please see http://inst.eecs.berkeley.edu/connecting.html#file_transfers for examples of how to do this. If you use a PC running Windows, it is critical that you apply patches regularly to protect yourself. Microsoft will automatically check your computer and install patches from http://windowsupdate.microsoft.com. SNS's IT Security Resources page lists additional ways to get help: http://socrates.berkeley.edu:2002/resources.html For more information about the problem from Microsoft, see: http://www.microsoft.com/security/security_bulletins/ms03-039.asp For more information on securing your computer, see: http://security.berkeley.edu/bestpractices.html For more information on email viruses, see: http://inst.eecs.berkeley.edu/cgi-bin/pub.cgi?file=email.help Other Links ----------- UCB requirements for any device connected to the Campus network = https://security.berkeley.edu/mssnd UCB requirements for storing sensitive information = https://security.berkeley.edu/mssei ResComp BeSecure = http://www.rescomp.berkeley.edu/besecure ResComp infosheet = http://www.rescomp.berkeley.edu/infosheets WEB site security = http://inews.berkeley.edu/articles/Aug-Sep2010/web-app-vulnerabilities UCB security training = http://inews.berkeley.edu/articles/Oct-Nov2010/privacy-training EECS Instructional & Electronics Support 377 & 386 Cory, 333 Soda inst@eecs.berkeley.edu