Linux System Security: Lab 9 Checklist - Prof. Wayne Summers, Lab Reports of Data Structures and Algorithms

A checklist for securing linux systems, covering topics such as securing accounts and groups, the file system, and services that run on the system. It includes instructions for setting passwords, disabling remote root logins, checking file ownerships and permissions, and configuring services like ftp and ssh.

Typology: Lab Reports

Pre 2010

Uploaded on 08/04/2009

koofers-user-lbm
koofers-user-lbm 🇺🇸

5

(3)

10 documents

1 / 6

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Lab 9 – Securing Linux Systems
Materials Needed:
4) Computer
5) Internet connection
6) Root access to Linux account
Assignment:
The original checklist was written by Gene Schultz of Berkeley Lab and has been copyrighted in
2003 by the Regents of the University of California. All rights are reserved. (http://www.lbl.gov/
ICSD/Security/systems/redhat-linux-checklist_v7.html)
Baseline Security Measures
A. Securing Your System’s Accounts and Groups
1. Assign a strong root password.
%syZ12Ghy#! would be a very strong password, but do not use this particular example as your password!
The root account is the most important to protect, and the danger of it being compromised is high, given
that powerful password crackers such as John the Ripper are freely available.
To change the root password, obtain a root shell, and then enter passwd
2. Ensure direct remote root logins are disabled. /etc/securetty should list only the
console tty (tty<#>).
To find the console number, login locally and enter # tty
Local root users will be able to logon directly, but to gain root access remote
root users will have to enter
su –
3. Disable remote root logins for FTP users.The best thing for security is to not run FTP
server at all. If you must run an FTP server, limit opportunities for attackers by
locking out certain accounts frequently used by attackers. /etc/ftpusers specifies
users who are not permitted to do an FTP login. At a minimum, all default accounts
(including root) should be listed in /etc/ftpusers, such as in the following example:
#cat /etc/ftpusers
root
adm
sysop
daemon
lp
4. Prevent nonadministrative accounts from logging in.
If the console is not physically secure, you should limit who can login and what service they can use.
/etc/security/access.conf defines the users who can login using particular services. For
example, to keep everyone but root from logging in and using the console, add the following entry to this
file:
-:ALL EXCEPT root :console
pf3
pf4
pf5

Partial preview of the text

Download Linux System Security: Lab 9 Checklist - Prof. Wayne Summers and more Lab Reports Data Structures and Algorithms in PDF only on Docsity!

Lab 9 – Securing Linux Systems

Materials Needed:

4) Computer

5) Internet connection

6) Root access to Linux account

Assignment:

The original checklist was written by Gene Schultz of Berkeley Lab and has been copyrighted in

2003 by the Regents of the University of California. All rights are reserved. (http://www.lbl.gov/

ICSD/Security/systems/redhat-linux-checklist_v7.html)

Baseline Security Measures

A. Securing Your System’s Accounts and Groups

  1. Assign a strong root password. %syZ12Ghy#! would be a very strong password, but do not use this particular example as your password! The root account is the most important to protect, and the danger of it being compromised is high, given that powerful password crackers such as John the Ripper are freely available.  To change the root password, obtain a root shell, and then enter passwd
  2. Ensure direct remote root logins are disabled. /etc/securetty should list only the console tty (tty<#>).  To find the console number, login locally and enter # tty  Local root users will be able to logon directly, but to gain root access remote root users will have to enter su –
  3. Disable remote root logins for FTP users.The best thing for security is to not run FTP server at all. If you must run an FTP server, limit opportunities for attackers by locking out certain accounts frequently used by attackers. /etc/ftpusers specifies users who are not permitted to do an FTP login. At a minimum, all default accounts (including root) should be listed in /etc/ftpusers , such as in the following example: #cat /etc/ftpusers root adm sysop daemon lp
  4. Prevent nonadministrative accounts from logging in. If the console is not physically secure, you should limit who can login and what service they can use. /etc/security/access.conf defines the users who can login using particular services. For example, to keep everyone but root from logging in and using the console, add the following entry to this file: -:ALL EXCEPT root :console
  1. Delete unneeded default accounts. Unneeded default accounts provide a potential avenue of attack. Default accounts you should strongly consider deleting include: bin daemon adm lp sync mail news uucp Caution: always test deletion of default accounts on nonproduction hosts before deleting them on production systems.
  2. Limit who can use the su command. Include everyone allowed to use the su command in the root group in /etc/group and then enter **# cd ** # chgrp root su # chmod o-x su
  3. Use chage to set password aging for each account. chage changes number of days between password changes and the date of last password change. -m means minimum number of days between password changes. - M means maximum number of days between password changes.  To set password expiration (with an advance warning to users), enter **# chage -M90 -W5 **  To check the last time a user password was changed, enter $ chage -l C. Securing Your System’s File System
  4. Check ownerships on system directories and files. a. Root should own all files in every system directory (/bin, /sbin, /dev, /etc, /var, and so on).  To change ownership, enter: **# chown user **
  5. Root (or possibly some other system group) should be the group owner of all files in every system directory.  To change group ownership, enter: **# chgrp group **
  6. Check permissions on system directories and files. World-writeable system files and directories are a worst-case scenario for security.  To discover world-writeable system files and directories, enter # find / -perm -002 -type f -print  To remove the world-writeable permission from a file, enter **# chmod o-w **

# /etc/rc.d/init.d/xinetd restart (only if the service is an xinetd-based service) b. If your system is not a mail server, there is a good chance that it does not need to run sendmail at all:  If so, turn off sendmail using the syntax shown above. c. Some mail clients such as elm, however, may need sendmail:

  1. If so, stop sendmail from running in daemon mode by editing etc/sysconfig/sendmail to have the following entry: DAEMON=no
  2. Next, restart the sendmail daemon by entering # /etc/rc.d/init.d/sendmail restart d. If your system is not a DNS server, it should not run the DNS service.  To do this, stop named and remove the DNS software: **# /etc/rc.d/init.d/named stop

rpm -e caching-nameserver

rpm -e bind**

e. If you need to run FTP, but do not need anonymous FTP, disable anonymous FTP:

  1. Edit /etc/ftpaccess such that the following line: **class all real,guest,anonymous *** is changed to: **class all real ***
  2. You need to also remove the FTP anonymous home directory by entering: # rpm -e anonftp f. If you need to run anonymous FTP:
  3. Enter anonftp in /var/ftp/pub/ The /bin and /etc directories need to be root-owned and to have permissions of 111. /pub should also be owned by root and should have permissions of 2555.
  4. Set up access through /etc/hosts.deny|allow by including the following entry: in.ftpd : ALL
  5. Additionally, to run anonymous FTP more securely, use /etc/ftpaccess to restrict operations (e.g., to prevent anonymous users from modifying file contents): chmod no guest,anonymous delete no guest,anonymous overwrite no guest,anonymous rename no guest,anonymous g. If you need an incoming directory (something that is not good for security, since it allows anyone to deposit just about any type of file):
  6. allow only write and execute access to it: # mkdir -m 333 /home/ftp/incoming
  7. Additionally, add the following entries in /etc/ftpaccess : upload /home/ftp /incoming yes root ftp 0600 nodirs noretrieve /home/ftp /incoming/ (Note: The first entry allows files to be uploaded to the /incoming directory, but they will be UID root and GID FTP, mode 0600, and subdirectories cannot be created below this directory. The second prevents anonymous users from downloading any files from /incoming .) h. If you need to run the NFS service, make NFS access as secure as possible.
  8. First, specify allowed addresses and/or address ranges in /etc/hosts.allow For example, to allow NFS mounts only by LBLnet hosts, include the following entry: portmap : 131.243.0.0/255.255.0.0 128.3.0.0/255.255.0.
  9. Do not allow the root volume to be NFS-mounted. Additionally, create entries in /etc/exports that allow read-only, not read/write access, per the following:

** ro ro** i. If you have a workstation that does not need to run any services (http, ftp, and so forth) that need to be accessed by other remote users, the best thing to do is disable xinetd altogether by entering: **# /etc/rc.d/init.d/xinetd stop

/sbin/chkconfig xinetd off**

IMPORTANT NOTE: If you need to run a Web server, you’ll need to ensure that it runs securely. An insecure Web server can be one of the easiest ways an attacker can gain unauthorized access to the host on which the Web server runs. See the Apache Web Guideline.

  1. Pare down trusted access to the minimum needed, but none at all if possible. a. To remove all trusted access, remove all entries in: –~.rhosts –/etc/hosts.equiv b. Find (and later remove) unnecessary user ~.rhosts files by running the following commands: # find / -name .rhosts -print # find / -name hosts.equiv -print
  2. Set up remote access to your host via ssh. a. Add sshd : LOCAL in /etc/hosts.allow to allow SSH access b. Each user must create an SSH key pair* by entering ssh-keygen -t dsa and then entering a passphrase (the first letters of each word from a fairly long phrase) for SSH access. A public-private key pair will be generated; by default, both will be saved in the path $HOME/.ssh. id_dsa.pub will hold the public key and /id_dsa will hold the private key. c. Now copy id_dsa.pub to the path, as follows: /.ssh/authorized_keys2 [fn5] d. Be sure to chmod /.ssh/id_dsa to 400, since it holds the private key. Chmoding /.ssh/id_dsa.pub to 444 is also a good idea.
  3. Substitute ssh for r-utility programs.  Enter: # ln -s /usr/bin/scp /usr/bin/rcp # ln -s /usr/bin/ssh /usr/bin/rsh # ln -s /usr/bin/slogin /usr/bin/rlogin E. Setting Up Host-based Firewall Protection
  4. Set up a quick and easy host-based firewall. To do so: a. Enter setup* b. Choose Firewall Configuration c. Set the firewall to the level of security you want (high, medium, or low)
  5. Or if you need a more sophisticated and precise host-based firewall:  Configure IPTables.