Linux Security.
This document covers many key security issues that affect Linux today. We
are trying to consolidate much of this general information in one place, and
provide a summary which a System Admininistrator can use for reference. Many of
the examples and descriptions in this document refer specifically to the Red
Hat distribution, but may be used with any Linux\Unix distribution as well.
Improving security at your site will be a progressive process, since securing
your systems is not going to happen overnight. Even if you feel that your
network is very secure, you may find tools and information in this document
that will give you another perspective.
|
11. Firewalls. |
|
|
12. Viruses. |
|
|
13. Mail relay. |
|
1. Steps that can be taken to
prevent an Intrusion.
Below is a list of various steps that may be used to prevent an intrusion
before it occurs:
a). As soon as Linux is installed all the Patches should be applied. Red Hat 6.1 and above now have an update agent which can automatically apply patches to the operating systems. http://www.redhat.com/support/manuals/RHL-6.2-Manual/ref-guide/ch-up2date.html
Unfortunately earlier releases do not have this functionality and require the root to perform this task manually with scripts. The following web site can be used to search for all the latest bugs and their resolution. http://bugzilla.redhat.com/bugzilla/query.cgi However it is recommended to apply to e-mail groups that can keep you up to date regarding security patches on a daily basis. Click her to view some of the more common groups.
b). When the system is booted in single user mode, there is no need to enter a password. Although this is not a bug it should be disabled in a desktop environment to prevent users from unintentionally logging into the system as root. This can be modified to prompt for the root password. Just add the following line:
(It may be placed underneath the line #System Initialization.)
/etc/inittab
~~:S:wait:/sbin/sulogin
c). Disabling all the daemons that are not required is another step that is good practice. If you don't plan to use telnet then disabling it will make the computer more secure. These settings can be located in the file /etc/inetd.conf All Linux installations always come with telnet set up as the default terminal session connection. It is recommended to disable this daemon and to instead install SSH (Secure shell). It will encrypt the entire connection, most important it will not reveal the password.
(Please note, in order for these changes to take effect you have to
execute these commands: ps aux | grep inetd
kill -HUP 263 (This could be a different number)
d). It is also recommended to enable the shadow file, since only the administrator will have access to this file. This will make breaking into Linux more difficult because the /etc/shadow file will have no read access to the users, but the /etc/passwd will still be readable by everyone allowing it to work. If you wish , run the following command on the shadow file "chmod go-rwx /etc/shadow" to make sure the permissions are set properly.
e). Changing the /etc/lilo.conf file permissions using "chmod go-rw file" to root access only is highly recommended.
f). /etc/rc.d/init.d is a location that contains links to start the various daemons, however they can be removed using the "TKSYSV" application, such that non of them start automatically. Here is a list of Kernel levels and daemons that can be started:
|
Daemon |
Kernel Level |
|
Kerneld |
2, 3, 4, 5 |
|
Apmd |
2, 3, 4, 5 |
|
Network |
2, 3, 4, 5 |
|
Rando |
2, 3, 4, 5 |
|
Portmap |
3, 4, 5 |
|
Nfsfs |
3, 4, 5 |
|
Syslog |
2, 3, 4, 5 |
|
Atd |
3, 4, 5 |
|
Crond |
2, 3, 4, 5 |
|
Inet |
3, 4, 5 |
|
Lpd |
2, 3, 4, 5 |
|
Nfs |
3, 4, 5 |
|
Keytable |
2, 3, 4, 5 |
|
Gpm |
2, 3, 4, 5 |
|
Sound |
3, 4, 5 |
|
Linuxconf |
2, 3, 4, 5 |
|
Local |
2, 3, 5 |
g). Downloading all the latest patches and applying them is also very important, especially since there may be a lot of new vulnerabilities that came about since the vendor released this version on CD. They tend to be behind on patches because it takes a lot of time to burn CD's, unlike the internet which is updated very frequently. (Please click here for a very detailed discussion and examples of configuring the Kernel.)
h). Most systems that do not check passwords before accepting them, probably have at least one password that can be easily guessed. If the Intruder can compromise a single account, he will then attempt to gain root access to the system. Unix/Linux use the DES encryption algorithm which encrypts the passwords in the /etc/shadow file, and the entry in the password file which has the user-ID '0' is the super-user account. If a user chooses a password that consist of words that can be found in the dictionary, they can be guessed very easily. It up to the Administrator to ensure that users passwords are strong enough and thus not allow weak passwords. This is why it is a good idea to run a password checking program on your systems which will notify a user if a weak password is found. Two famous ones are Crack and John the Ripper. Some Universities have Crack set up in the Cron and automatically let their users know that their password is weak and it should be changed.
i). Changing or disabling default account passwords should be a priority when a new system is installed. Please note that crackers have entire lists of default accounts and their passwords, which makes an easy target. Also when performing product upgrades, some products may change the password back to a new default, thus it is a good idea to change the default account passwords after applying updates. Remove any entries for unused accounts from the password file. To disable an account, change the password field in the /etc/passwd file to an asterisk '*'. If you choose a more secure alternative, then the same thing can be done in the /etc/shadow file.
j). Sendmail has a number of vulnerabilities, which is why it is important to be up-to-date it and use something like smrsh, because an intruder sending a carefully designed email message may be able to execute arbitrary commands with root privilege or relay e-mail. Please click here to learn more.
k). Use of TFTP (Trivial File Transfer Protocol) to obtain password files may be possible. To test your system for this vulnerability, connect to your system using tftp and try:
get /etc/motd
If you can do this, anyone else on the network can probably get your password file. To avoid the problem, disable tftpd. If you must have tftpd, ensure that it is configured with restricted access. For further information, see: ftp://info.cert.org/pub/cert_advisories/CA-91:18.Active.Internet.tftp.Attacks
l). Anonymous FTP - In addition to making sure that you are running the most recent version of ftpd, please check your anonymous FTP configuration. Note that you should not use your system's standard password file or group file as the password file or group file for FTP. The anonymous FTP root directory and its two subdirectories, etc and bin, should not be owned by ftp. For more details about a properly configuring ftp please go to:
ftp://info.cert.org/pub/tech_tips/anonymous_ftp_config
m). Check for inappropriate entries in /etc/aliases file.
n). Check for inappropriate export settings if your network is using NFS.
- wherever possible, file systems should be exported read-only.
- the exports file should not contain a "localhost" entry.
- the exports file should not export an NFS server to itself or to any netgroups that include the NFS server.
- export only to fully qualified hostnames, and only to hosts that require them.
- ensure that export lists do not exceed 256 characters (after the aliases have been expanded) or that all security patches relating to this problem have been applied.
ftp://info.cert.org/pub/cert_advisories/CA-94:15.NFS.Vulnerabilities
o). Check if there are any vulnerable protocols and services, and if they can not be patched, then filtering certain TCP/IP services at a firewall or router could be an option. The following URL can be useful in this regard. ftp://info.cert.org/pub/tech_tips/packet_filtering
For a complete checklist, please go to: ftp://info.cert.org/pub/tech_tips/AUSCERT_checklist1.1
p). Checking of the log files for any remote connections, or unusual activity especially the security logs should be done on a regular basis.
q). Setuid shell scripts like setuid root can pose potential security problems, and should not be used.
(Please click here for more details.)
Check for setuid and setgid files on the entire system with the following commands.
find / -user root -perm -4000 -print or find / -user root -perm -4000 -print -xdev (To prevent searching the entire tree.)
find / -group grpName -perm -2000 -print
r). Check the system binaries to make sure that they haven't been altered, especially the ones referenced in /etc/inetd.conf
It is a good idea to check the entries that execute a shell program (for example, /bin/sh or /bin/csh) because they are most likely to have been compromised. Then comparing the versions on your systems with known good copies, such as those from the initial installation media can be a useful tip. However the standard sum command and the timestamps associated with the programs are not sufficient to determine whether the programs have been replaced. Using cpm to compare two binary files is sufficient. Also using md5sum, and Tripwire to do a checksum test is quite adequate.
s). If one of the hosts on the local network has been compromised. The intruder may have installed a sniffer, which will listen on the Ethernet port for things like password, login, su and record all this information. On a local network all the trafic is broadcast, which is what makes this possible. Thus every packet will travel through every computer of that network. This includes programs like regular POP, even syslog unless it is the secure version which uses encryption prior to sending data. This type of attack can be prevented using SSH which will encrypt the entire session. (Please click here.)
t). Check all the files that are run by 'cron' and 'at.', because this is where intruders tend to leave their back doors. Also please makesure that none of these programs have write permission, and check for '+' (sign) entries and inappropriate non-local host names in /etc/hosts.equiv, /etc/hosts.lpd, and in all .rhosts files.
u). Check the system for unusual or hidden files that start with a period and are normally not shown by 'ls', since these can be used to hide tools and password cracking programs. The find command can be used to print a list all of these hidden files.
find / -name ".*" -print -xdev | cat -v
v). It is good practice when downloading each package from an unknown source, to verify that it has not been corrupted or tampered with. If you choose to examine only the md5 sum which should be adequate, the following command may be used:
rpm --checksig --nopgp packagename.rpm or rpm -K --nopgp packagename.rpm
RPM also has the ability to verify all the packages it has installed on the system. It can detect missing files, file size changes, trojan horses, etc. All this is part of the Linux installation.
Also, it is good practice to zip the following files onto a floppy disk, because if a system is compromised they will not match.
/var/lib/rpm/fileindex.rpm & /var/lib/rpm/packages.rpm and the RPM binary itself.
Using the following command you may verify if your system has been compromised:
Rpm -Va
w). If the package is not an RPM but the source code, they usually include a signature file, which can be used to verify that no one has tapered with it. To verify a signature, you will first need to get the PGP program, and then the PGP public key from the site you will be downloading from. For example the RedHat Public Key PGP can be download from http://www.redhat.com/about/contact.html
You may download PGP from http://web.mit.edu/network/pgp.html
pgp –kv (Shows all keys.)
pgp –ka key.asc (Adds a key to your key ring.)
pgp signedFile originalFile (Checks the file.)
pgp –b signedFile (Checks the signed file.)
You may also use GPG which is very similar, but requires a GPG public key from the site you will download the files from.
You may download GPG from http://www.gnupg.org/
gpg –list-keys (Shows all keys.)
gpg –import key.asc (Adds a key.)
gpg –verify file.sig originalFile (Checks if the original file is the true original file.)
Before using these program, you will need to install either a command version of pgp or gpg. Then you will need to add the public key from each web site you will be downloading the files from.
Response should be: Distribution Key Signature made, and Signature verified.
Good signature from -----
i. For PGP International use the RSA distribution key.
ii. For the US/Can PGP version use the DSA distribution key.
iii. For GnuPG/GPG use the DSA distribution key.
(Also removing never used packages is good practice /bin/rpm -e <packagename>)
The third option is using the MD5sum command.
"md5sum filename"
You should see a message like: ada1298347912749812742198372198 filename
(You may then check if the checksum is correct by searching the http://search.cert.org/ web site, but it is better to run a checksum on all the significant files and keep the output for a future date if you are not using software like Tripwire.)
x). Prevention of intrusion means having a combination of various mechanism that need to be set up before hand, if they are to be effective at the early stage of an attempt. Host based detection is very important since the auditing will show events that occur on a larger scale. Logging of these various events will reveal which events have already take place.
This package can be used as starting point to protect against intrusion: http://trinux.sourceforge.net/
Additional guidelines provided by CERT: ftp://info.cert.org/pub/tech_tips/UNIX_configuration_guidelines
Other tools which can also be used for detection include:
Tripwire - used to determine if any files have been modified on your system, such as running checksums on all the important binary files, configuration files. It works best when installed onto a floppy and it is physically write protected with the little tab on the disk. This is one of the best tools to detect intruders, otherwise you may not even notice the system was compromised. Since there are a lot of file changes on a daily basis, you need to choose them carefuly, especially tracking binaries is important. http://www.visualcomputing.com
Sentry intrusion - used to detect if someone is portscanning your network. http://www.psionic.com/abacus/abacus_sentry.html
Klaxton - sets up a trap for the intruder and notifies the administrator when it is activated. http://www.eng.auburn.edu/users/doug/second.html
A reasonable level of computer security should be maintained on all systems,
otherwise it will make all other systems vulnerable to an attack. Checking of
log files on a constant basis is good practice, and running software like
tripwire regularly will prevent an incident before it occurs. If an incident
does occur, the logging software should be installed and tested ahead of time
to help narrow down the issue. Tripwire can verify the integrity of programs
and data, or RPM which can also be used to determine the integrity of the programs
or data. Also the System accounting logs need to be configured correctly
initially, so that there is dependable information about what has occurred on a
given system. Using a firewall to increase the security of intrusion
attempts is beneficial, but logging at the firewall should also be configured.
Performing standard backups of Systems should be mandatory in case the machine
altered has data files deleted from it, or the exploit has gone beyond the
recovery of this system. Finally it is important to perform random checks of
machines without the use of software, because in the end only the Administrator
can make the final call if a computer has been compromised.
2. What to do if an Intrusion
is detected.
The first thing that needs to be established is being certain that an actual attack has occurred, and to what extent. The more people that get involved the better, since it will spread the load of work and increase confidence that the system was compromised. File integrity checking is a very good way to check for trojan horses or file modification. RPM can be used to check for this type of attack. Some signs to look for are failed log in's, logins during abnormal hours, new accounts that should not be there, repeated failed attempts and su entries from strange places. Also system logs that indicate no activity has occurred for a long period of time, slow system performance, system reboots, presence of new binary files, changes in permissions, changes in file size, system configuration changes in the /etc, strange suid and sgid files, new directories, missing files, repeated probes of available services, repeated login attempts from remote hosts. The procedure of detecting an intruder can be almost impossible if no preparation has been done ahead of time to detect intruders.
a). If the root account has been compromised, first the damage needs to be assessed at a glance. To temporarily disallow any remote access to the computer, except the root during this stage. You may simply add the file /etc/nologin with a message that will be displayed to any users trying to log in. Then change the root password.
b). Lock out the intruder by all means possible. If possible disconnect the system from the external source immediately by disconnecting the network cable. If the computer can not be disconnected from the network, using software like Tcpwrappers will allow you to block the IP address of the external machine.
c). Make a backup of the system that is being exploited. With Linux systems it is common to backup the configuration files, log files, and user data.
d). To generate a list of the most recently modified files, you may use the following command:
/usr/bin/find / -ctime -l -print
Always investigate if Linux has been rebooted, since it is a robust operating system and there should be very little need for doing so.
e). The command rpm -V can be used to verify a package. It compares the information about files installed from a package with the same information from the original package. It also varifies the size, MD5 sum, permissions, type, owner and group for each file. This can also be useful if you suspect that your RPM databases are corrupt.
"rpm – V package " (Verifies that all the files in the package are as they were when they were originally installed.)
"rpm -Va " (Verifies all the installed packages.)
If everything verified properly there will be no output. If there are any discrepancies they will be displayed. The format of the output is a string of 8 characters, a possible "c" denoting a configuration file, and then the file name. Each of the 8 characters represents the result of a comparison of one attribute of the file to the value of that attribute recorded in the RPM database. A single "." (period) means the test passed. The following characters denote failure of certain tests:
5 -- MD5 checksum
S -- File size
L -- Symbolic link
T -- File modification time
D -- Device
U -- User
G -- Group
M -- Mode (includes permissions and file type)
f). Search the system for new or modified setuid root files.
find / -user root -perm -4000 -print
g). Security tools such as COPS and Tripwire can be used to check for security & configuration weaknesses.
h). Check for unexpected ASCII files in the /dev directory. Some Trojan binaries rely on configuration files, which are often found in /dev
i). Check for any modifications to /etc/rc* files and /etc/shutdown files. Some intruders have modified /etc/rc files to ensure that the sniffer restarts after a shutdown or reboot. Others have modified the shutdown sequence to remove all traces of compromise.
j). You may also use the different steps that were provided in the
section above "Preventing an Intrusion"
k). If the root account was compromised, then the next best thing an Administrator should do is reinstall the system from the vendor's media, and apply all the patches especially the one that is believed to have caused the compromise. If the attack was toward a regular user, then the system should not need to be reinstalled but investigated thoroughly to figure out if a patch for the system is required.
l). Restore the configuration files, log files, and user data.
m). Change the password on all accounts.
For additional information, please have a look at the URL: http://www.cert.org/tech_tips/root_compromise.html
3. Preventing the intrusion
from reoccurring in the future.
Since there are thousands of people constantly working on fixes, this makes Linux more secure by default then any commercial operating system. However no operating system in the world is secure by default which is why it is good practice not to rely on a single security mechanism such as a Firewall, but use layered security. A packet with the TCP ACK bit set (as is done with established connections) will likely get through a packet-filtering firewall. The returned RST packet from a port that had no established session can be taken as proof of life on that port. Most likely TCP wrappers will not detect this type of probe. Encrypting as much as possible makes it more difficult when using sniffers. Even if you have all the latest fixes applied that does not indicate that your system is secure, since in the next couple minutes someone may come out with something new, thus continued monitoring is good practice.
Some of the things an Administrator can do after an intrusion are:
a). Keep evidence of the attack, create a log of what happened in a personal log and how it was resolved.
b). Try to determine when the system was compromised, this may even require checking past backups.
c). If you are able to determine what means the attacker used to get into your system you should try to close this hole. Checking for a patch should be the first priority, and then applying the fix.
d). Check the security list pages to see if there are any new common exploits http://www.redhat.com/errata
e). If the exploit is not repaired, chances are the attacker will be back, but trying the same thing on other machines of your network. Thus make sure the patch is applied to all the other computers as well.
f). A good explanation of the steps to take once a system has been compromised is available from CERT at http://www.cert.org/tech_tips/root_compromise.html
g). If the incident was more serious, it may be a good idea to notify the UofT response team with some information about the incident, and to prevent the same attack to other Administrators. UofT Computing and Networking Services - http://www.utoronto.ca/security/contact.html
h). Secondly the Administrator of the site that attacked your system should be notified politely with a quick e-mail, applicable log entries with dates to make them aware their system has also been compromised. The contact of the remote site Administrator can be obtained from the internic database or using the following URL: To trace an intruder you may use the following URL: http://network-tools.com/
This should prevent the intruder from using that system in the future, since most Administrators will investigate and apply a fix on their network. As already stressed, it is a good idea to belong to security mailing lists and keep current on security fixes.
Case locks are a more expensive way of securing your computer, but they may be worth investing if the computer is your Primary Server. A cheaper alternative may be to secure a computer in the bios using a password, and most new x86 computers can even disable the booting from a floppy disk. OpenFirmware can be configured on Macs, and new Suns. PROM for Sun. EEPROM can be set on SPARCS to prompt for a password. Although these are great deterrents, they will not stop someone that can open the case and move some jumpers around.
Another security feature built into Linux, is the ability to specify authorized usernames that are allowed to reboot a computer using Ctrl-Alt-Del. All it takes is modifying the /etc/shutdown.allow file.
Screen Saver lock is a good idea if the computer remains idle for a certain amount of time. Xlock will lock the X display. Vlock will allow the user to lock a terminal, while still allowing other users to come in and use the computer, however someone may still come in and reboot the computer disrupting your work.
For an introduction to TCP/IP http://www.sunworld.com/sunworldonline/swol-11-1995/swol-11-sysadmin.html
a). NFS (Network File System) - gives us the ability to share a file system to many computers. It's most common use at Universities is to hold users home directories, which would allow them to log in from any computer and have access to their home files. However it has a number of vulnerabilities if it is not configured properly such as; Anyone with superuser privilages has the ability to read all the data of the local filesystem, and it is very easy to snif the information that goes across. Another security issue is that NFS does not deal well with impersonification of users, and most of the permission checking over NFS are done in the clients kernel. This means that the intruder can temporarily assign to his/her own computer the Internet address of the victim. No further authentication procedure would be requested, and the intruder could now issue NFS requests and it would not matter even if the Uid was false. It permits servers running nfsd and mountd to export entire filesystems to other hosts without nfs built into their kernels. Mountd keeps track of the mounted filesystems in the /etc/mtab, and can be viewed with the showmount command on the Server. Never export your entire root directory, export only directories you need to export and export read-only wherever possible. You can make nfsd map the remote root account to a madeup user, denying them total access to the files exported. However, since individual users need to have access to their own (or at least the same uid) files, the remote superuser can login or su to their account and have total access to their files. It should be disabled on all the clients. In fact NFS is available for DOS and Windows too.
Explanation of NFS How-to-NFS.
NFS - quick overview of the installation:
"On Server" - you should log in as the root and edit the file /etc/rc.d/init.d/inet and above the "if" section add a line
/sbin/portmap (now portmap will run automatically when the computer is rebooted.)
Next you need to edit the file /etc/exports and add the following line to the file above, & it will export this directory form that machine to some bunch of machines you specify with read access.
/home *.blue.edu (r).
Next you need to create a file /etc/exportsfs and in it type:
#!/bin/sh
killall -HUP /usr/sbin/rpc.mountd
killall -HUP /usr/sbin/rpc.nfsd
This way you can execute this script each time you make a change on the server, also type in "chmod 555 exportsfs" to set the proper permissions.
"On Client" - you need to log in as the root, and edit the file /etc/fstab, then add the line servername.blue.edu:/home /mnt/homemadeup nfs ……….
"showmount" will allow you to display which filesystems are mounted.
mountd (keeps track of mounted filesystems) + nfsd = is used to export filesystems to other machines.
- You can make your nfsd map the remote root user (uid=0) to the nobody user, denying them total access to the files exported. However, since individual users have access to their own (or at least the same uid) files, the remote superuser can login or su to their account and have total access to their files.
- it is possible to use a firewall or a gateway to prevent external access to NFS by filtering TCP port 111, UDP port 111 (portmapper), TCP port 2049, and UDP port 2049 (nfsd) on your firewall or gateway to prevent external access.
- if you are exporting filesystems using NFS, be sure to configure /etc/exports with the most restrictive access possible. This means not using wildcards, not allowing root access, and exporting read-only wherever possible. Verify who can mount these filesystems using /usr/sbin/showmount -e localhost.
b). TCFS (Transparent Cryptography File System) - http://tcfs.dia.unisa.it/ is a way of encrypting an entire directory tree and making it transparent to the users. Each directory is protected by a cryptographic key, which is what makes this much more secure. TCFS enforces threshold sharing by generating an encryption key for each group and giving each member of the group a share using a Threshold Secret Sharing Scheme. A member of the group that intends to become active does so by pushing her/his share of the group key into the kernel. The TCFS module checks if the number of shares available is above the threshold and, if it is so, it attempts to reconstruct the group encryption key. By the properties of the Threshold Secret Sharing Scheme, it is guaranteed that, if enough shares are available, the group encryption key is correctly reconstructed. Once the group encryption key has been reconstructed, the files owned by the group become accessible. Each time a member decides to become inactive, her share of the group encryption key is removed. The TCFS module is used to check if the number of shares available has gone under thethreshold and if so, the group encryption key is removed from the TCFS module and files owned by the group become unaccessible.
c). NIS (Network Information System) - can be used to
distribute information to a group of machines, the service called ypbind is needed
for NIS. The NIS master holds the information tables and converts them into NIS
map files. These maps are then served over the network, allowing NIS client
machines to get login, password, home directory and shell information (all the
information in a standard /etc/passwd file), among other information. NIS is
very insecure, however there is now a replacement NIS+, which can be used
instead since it has many security improvements.
- used when you have a standalone LAN, and want to store all client addresses in a single central machine to simplify administration or if you wish to give each user the same login account and password on each machine automatically.
- you would need to configure a Maser Server, optionaly Slave servers containing copies of NIS Database and then clients.
- same as in the NFS the portmap daemon must be runnin in addition the time service should be marked to run in the /etc/inetd.conf
- it is important to note that you will not be able to use shadow passwords, thus you would need to remove entries from the /etc/shadow and copy them back to the /etc/passwd, otherwise you would need to remove the shadow passwords entirely. NIS was never meant to be secure, but to simply simplify things. This means that any server can act as the authentic one, and that anyone that can guess the name of your NIS domain could get a copy of the passwd file. However if you must use it, explicitly define which host ad users can connect and control the use of the /etc/netgroup file.
http://sunsite.unc.edu/LDP/HOWTO/NIS-HOWTO.html
NIS - quick overview of the installation:
"Master Server" - it is the program "ypserv", first you would need to log in as the root and edit the /var/yp/securenets and delete the line that leaves NIS open to everyone "255.255.255.0 128.100.9.0" (The zeros represent items that can change, also leave the local hosts alone.)
- edit the file /etc/ypserv.conf however if you are using DNS instead, then instead of filling out the host file abo e simply change the DNS entry to yes. Now type in "/etc/rc.d/init.d/ypserv start"
- to generate the NIS database type "/usr/lib/yp/ypinit -m"
"Client" - it is the program "ypbind" and it must be running all the time.
- log in as the root and edit the /etc/rc.d/rc.local and at the end of the text file add the following line "/usr/sbin/ypbind"
"Slave Server"
- although not necessary, will guarantee access to the master NIS server.
- log in as the root and edit the /etc/yp.conf and add a line to point to the NIS MasterServer
Eg. "ypservername #.#.#.#"
Then in the /var directory create "yp" directory and edit the "/etc/rc.d/rc.local" and at the end of the file add a line: /bin/domainname fictionaldomain
(This fictional name is used to make intruders listening in a bit more secure, and gain access to passwd file on NIS server. Then restart the computer and on the Slave server you must type the below to activate it:
/usr/lib/yp/ypinit -s masterhost
d). Check the /etc/securetty file for the list of tty's that root is permitted to login from. The absense of this file indicates root is permitted to login from anywhere. Using a program like "Sudo" will allow a system administrator to provide restricted root access to certain commands for certain people on their systems. It may be downloaded from: http://www.courtesan.com/courtesan/products/sudo/
e). Before you put a Linux system on any network, disable unnecessary Services. /etc/inetd.conf should have any services that are not being used disabled by commenting them out with a # at the beginning of the line. Then any services that are still running from inetd can be wrapped using TCP Wrappers. The first services that should be disabled are exec, login, shell since these protocols are extremely insecure and had the most exploits in the past. RPC services tend to also be insecure, and have typically been replaced by a newer equivilent service. Useing rpcinfo -p hostname will list the RPC services running on a host. Also the files in /etc/rc.d/rcX.d are actually symbolic links to directory /etc/rc.d/init.d and renaming the files in the init.d directory with a lower-case "s" will disable a service for that runlevel. However using graphical tools like tksysv, or linuxconf can also accomplish this.
f). Disable the use of $HOME/.rhosts files, which may allow unauthorized access from a remote system and instead replace it by a functionally equivilent SSH file called .shosts.
g). Regular port scanning of machines is very common, and can reveal open ports to a hacker in seconds. Thus using Tcp-Wrappers is a great idea. First tcpd is invoked from inetd.conf, and it checks that the host which is requesting the service is permitted and only then executes the real service like ftp.
h). Many services can be configured to not accept connections from hosts that do not have valid DNS (Domain Name Service) entries. Further information on securing DNS can be obtained from http://www.psionic.com/papers/dns-linux.html
The article below contain information on how to prevent being DNS spoofed.
http://www.sunworld.com/swol-11-1997/swol-11-bind.html
i). Some network services can now be configured to run in a restricted environment, called a "chroot jail". This is an isolated environment seperated from the real operating system. Services such as Apache or bind can be operated in this environment. A special root directory is created, with a complete installation of all the programs and libraries necessary to execute the service. The intention is to prevent someone from obtaining root privilege on the real operating system, due to a bug in the service. Thus this service is used instead in the chroot jail. http://www.ssc.com/lg/issue30/tag_chroot.html
Red Hat contains packages that can be used to install BIND in a chroot jail. ftp://ftp.tux.org/pub/tux/jam/ Generally a good practice is to configure a separate user for BIND. This not only restricts the amount of damage an intruder can do after exploiting a security hole in BIND, but also allows administration of the zone files without having to be root.
j). Samba (Session Message Block Protocol) - is an implementation of the Common Internet File System (CIFS), which will allow file and printer access to Microsoft Windows users. The advantage it has over NFS is that it does file locking which would not allow several people to access a file at the same time and try to make changes at the same time. It comes with two server daemons and two client components.
The server component smbd allows file and printer sharing. Another server component nmbd; mangases & distributs Netbios information, provides a list of file services, and printer services for sharing across the network. The client component smbclient allow the client to access the sharing component, and nmblookup allow the client to access the nmbd. It is important that the latest version of Samba is installed, since there were a lot of vulnerabilities in the previous versions of this program. Only install run the services that are needed on your operating system. Please read the configuration section carefully to make SAMBA as restrictive as possible. The latest version can be downloaded from http://www.samba.org
To check if samba is installed type: rpm -q samba
k). The setenv - path environment variable defines the location the shell searches for programs, this should be limited to the root account as much as possible. Especially never have a path statement to a writable directory by the users, as this could allow an attacker to insert a binary in the roots search path and give them access.
l). R-utilities are subject to many sorts of attacks and should not be used by the root account. These include; rlogin, rsh, rexec, etc..
m). The .rhosts file in a home directory is not a good idea, because if someone manages to bring down one of your machines then they can use another computer and give it the same name and log in as the root, because authentication is based on machine names.
n). Sudo - allows the execution of commands as root, and at the same time keeps a log of who did what. Although this may seem great, it has several issues since any program that offers a shell escape would give a user root access, this includes most editors, and even cat.
o). Using TCP Wrappers to control incomming connections is an excellent idea. Then setting up two files /etc/hosts.allow "ALL:127." & /etc/hosts.deny "ALL:ALL" preventing TCP external connections to your computer. Alternatively if no remote computer needs to connect to a machine, then renaming the file /etc/rc.d/rc3.d/S50inet will prevent the inetd server daemon from starting.
p). Identd - is a very useful program to have since it can tell a remote user, the username of the person using the TCP service and trying to hack into their site. This would save lots of time looking through logs. It is usually run out of inetd.
Below is a list of the most common Network Attacks:
DOS attack - it stands for Denial of Service attack, which involves system freezing, rebooting, and termination of your connection. The worst case scenario is damage to pentium chips on older machines. Any platform using the TCP/IP protocol may be vulnerable. Tools such as Teardrop and Land, enable a remote user to launch a denial-of service attack. Most common effect is causing the victims machine to crash.
ICMP attack - is a protocol used when closing a connection between two computes. If one of the computers is unable to keep the current connection it lets the second computer know it is closing the link by sending a Destination_Unreachable ICMP packet. Upon receiving this packet, the second computer would know to close the link. Once a computer lets another computer know it is closing a link by sending a Destination_Unreachable ICMP packet. This second computer would know to close the link. In a client attack, a remote computer will send a Destination_Unreachable packet with a spoofed address of the Server you are connected to, to your computer. After your computer receives this packet, the connection would close on your computer. You would only see that you have been disconnected on the client side. On the Server Side, a remote computer would send a spoofed Destination_Unreachable packet that would appear to come from you, to the server. The server would then terminate the connection, and the server side would only show a lost connection. To protect agains this type of attack, you need to have the protection of a firewall which will block all incoming ICMP packets, or simply blocking Destination_Unreachable packets on port 3.
Win Nuke TCP/IP attack - involves sending a packet to port 139 that contains out of bounds data, the computer will freeze or the hard drive may become unbootable. Port 139 is the windows netbios port, which was designed to be used across LAN/WAN. There is no checking done on the incoming packets of this port. Using a Firewall, it is possible to set filtering or blocking of Port 139 from Untrusted hosts.
TCP/IP Land attack - involves sending spoofed packets saying they are from your computer to your computer, most often on ports 139 and/or 113. As with TCP/IP flooding only opens ports that are vulnerable to this attack. Windows on receiving data to itself from itself causes a stack dump. Attacked systems may get a windows protection error (blue screen), a frozen or locked up screen program or system, or a black screen. Setting a firewall to block all local host 255.255.255.255 connections on port 113 and 139, from local host 0.0.0.0 will resolve this issue. The Land tool relies on the use of forged packets, packets where the attacker deliberately falsifies the origin address. With the current IP protocol technology, it is impossible to eliminate IP-spoofed packets. However, you can reduce the likelihood of your site's networks being used to initiate forged packets by filtering outgoing packets that have a source address different from that of your internal network. Currently, the best method to reduce the number of IP-spoofed packets exiting your network is to install filtering on your routers that requires packets leaving your network to have a source address from your internal network. This type of filter prevents a source IP spoofing attack from your site by filtering all outgoing packets that contain a source address from a different network. A detailed description of this type of filtering is available in the Internet Draft "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing" from http://secur.ibelgique.com/secur/dos/draft-ferguson-ingress-filtering-03.txt
http://www.cisco.com/warp/public/770/land-pub.shtml
http://linuxtoday.com/news_story.php3?ltsn=2000-02-23-027-06-SC
TCP/IP Teardrop attack - is an attack which is done from unix shells, or linux PC’s. It sends an invalid packet header and when your computer receives it, it believes that it is one size, but the packet received is of a different size. Windows will set and wait for a corrected packet to be received. Unfortunately while the system waits for this corrected packet, nothing else can be done. The system will eventually show a blue screen windows protection error. This type of attack may be stopped with the use of a firewall, or a fix which has been released.
UDP OOB (Out of Bounds) attack - it is done on port 138, which is very similar to the attack to TCP/IP 139. The attack, is done in the same way, exploiting the same bug, with similar effects such as the Windows protection error (blue screen). Firewall blocking inbound UDP on port 138 is one way of ensuring this is not exploited.
UDP Bonk - is very similar to the teardrop attack. The teardrop attack uses misinformation about packet size in the hearder of a TCP/IP packet, while this attack also sends misinformation about the packet size, except as a UDP packet. It involves sending a malformed packet which is the incorrect size, spoofing from your computer, to your computer. Setting up a firewall to block incoming UDP packets from unknown hosts and to block all incoming UDP’s from your own host address 255.255.255.255.
a). Checking system logs such as /var/log/messages is one of the best ways of making sure that a host has not been compromised. Using the Syslog system daemon program can be beneficial, since it can log system events like login/logout, system messages, and kernel messages. To find out where it is logging the various messages you may look at the /etc/syslog.conf file. However the default is /var/log/ Secondly once a computer has been compromised, the log data can be of little use, since it most likely has already been modified by the intruder. It is therefore a good idea to store the log files remotely, a more secure implementation is available at
http://www.core-sdi.com/ENGLISH/CoreLabs/ssyslog/index.html
b). There are also various commands that can be used to view information about a particular host. The command "last" can be used to view information such as; last logged in users, and lastb which shows a list of failed login attempts if /var/log/btmp exists
/var/run/utmp - can be used to find out who is currently on the system and it is used by the Who command.
/var/log/wtmp - is used by both last and lastb commands to find out; type of login, user name, hostname of remote computer, time entry was made, and ip address of remote host. Thus it can be used to determine when and from where an intruder has entered a system. The files wtmp & utmp should have their permissions set to 644.
c). A portable Linux distribution that fits on a single floppy disk http://www.trinux.org/ could be used to gain access to a host, and therefore booting from a floppy disk should be disabled.
Below is a list of the most common Host Attacks:
Spoofing - it involves tricking a computer into believing that you are someone else, usually involves forging your IP source address. A firewall can be configured to prevent internal IP addresses from entering from the outside. http://www.psionic.com/papers/dns-linux.html
or Understanding the low level TCP details from http://www.unitedcouncil.org/spoof/IPSpoofing.txt
DOS (Denial of Service) - is when an attacker prevents authorized users from accessing a service. This is done by making a resource too busy to answer a legitimate request, or by denying all access to the machine. Man in the middle attack is another type of DOS attack involving keeping the host busy from replying, while the intruder is impersonating that host.
SYN Flooding - is a network DOS attack which uses a loophole in the TCP connection. Linux kernel 2.0.30 has some configuration options to prevent this from occurring and denying users access to the host or it's services.
Spamming attack - involves using your e-mail host to send out large
amounts of unsolicited e-mail causing network clogging.
Ping 'o Death - is caused by an incoming ICMP Echo request that is larger than the kernel data structures that store this information. Thus anything larger then 65510 bytes would cause a system to crash, applying a fix should resolve this.
Teardrop - it involves a bug that is present in the IP fragmentation code, but has been fixed in kernel version 2.0.33 of Linux.
Pentim F00F Bug - is an attack on a genuine Pentium CPU, excluding PII, clones etc.. It involves sending a series of assemply codes to the CPU and it reboots the computer, however Kernel 2.0.33 or above has a fix for this.
Ping Flooding - is a simple DOS attack which involves the intruder sending a flood of ICMP packets to a host, if the machine has a better bandwidth then you would be unable to communicated on a network.
Smurfing - is just a variation of ping flooding where an intruder sends ICMP packets to a broadcast address with your hosts IP address, thus allowing the intruder to flood your computers without being detected. http://www.quadrunner.com/~chuegen/smurf.txt
Please note that tcpdum can be used to determeine where the packets are really coming from. It is a useful tool to have, and can be downloaded from : http://ftp.ee.lbl.gov/tcpdum.tar.Z
Encryption usually involves an algorithm that is used to scramble
data that is going to be sent to another host. In the past, this has not been
implemented in too many programs due to various restrictions such as slow
CPU's, low bandwidth connections, etc.. Now that technology has breached this
threshold, encryption is becoming a priority in securing all communication,
especially with the evolution of the Internet. The intent of this document was
not to explain the details of ecryption, but to briefly mention some of the
advantages of using it in maintaining System security. With the use of PGP, it
is possible to verify if files were modified, or to encrypt e-mail messages
which travel through at least a dozen computers over the world before reaching
a destination. Using SSH will allow a secure connection between two hosts,
therefore any data that is sent between them is secure. The list of the various
programs is so long that it would take too long to mention all of them, but by
the end of this document you should be familiar with the main ones that are in
use today.
The permissions set on files play a major role in system security. This
is why we have provided a brief description of these basic concepts, and then
discuss some common mistakes that could compromise a systems security.
File security:
|
Field 1 |
2 |
3 |
4 |
5 |
6 |
7 |
|
d(rwx)(rwx)(rwx) |
25 |
root |
users |
1024 |
Aug 20 1:13 |
Home |
Field#1 - represents the permissions for a file/directory. The permissions come in groups of three in the following order user, then group, and other.
Field#2 - represents the number of hard links to this file/directory, in this case most likely has 25 directories below it.
Field#3 - This is the owner of the file/directory, in this case root.
Field#4 - This is the group the file/directory belongs to, thus users group.
Field#5 - File/directory size
Field#6 - Last time modified.
Field#7 - File/directory name.
(Please note that there is always one owner of a file/directory, many group members and then there is everyone else.)
R - contents can only be read
W - contents can be modified, appended and deleted.
X - if it is a shell script or a binary file it can be executed.
S - file/directory has special setuid or setgid permissions, it is only used in executing scripts or binaries.
l - means that access is denied to read, write or execute depending on it's position.
Setuid/setgid - means that the file that is executed by any user is run with the system resources/permissions of the owner of that file/directory. Set User-ID (SUID) or Set Group-ID (SGID) are the type of files most often attacked by an intruder, because they are typically owned by the root. When a regular user executes them, they obtain root permissions as long as the program is running. This is why it needs to be used with extreme caution since it is the cause of many buffer overflow exploits resulting in root privilage shell. An attempt at buffer overflow is usually attempted to open up a new shell with root privilages. One should never modify non-setuid binary to have setuid permissions simply for convenience. If you use setgid, then upon execution of a binary file, the permission of the file is granted access based on the permission granted to that group, even though you may be an ordinary user for that instant you get granted the permissions of that group. Shell scripts which are setuid are a security risk, and should not be used because they can give a cracker a root shell if a buffer overflow occurs. This is thus disabled in the kernel from operating to prevent intrusion by causing a buffer overflow.
Setgid 's' on a directory, would mean that any files created in that directory would have the same group ownership as the directory itself. This is useful since multiple users would have a common directory that they could all work in and have access to. Thus users from different groups may now work on a common project, since any files created there will give them permissions of that common directory.
Chmod g+s nameofdirectory
SetGid bit on a file works the same way as Setuid, except instead of applying the files owner, it is applied to the file's group setting this will allow a program to be run with the permissions of that program's group. To enable eighter one, you need to use the chmod command. To make a program SETUID prefix whatever permission value you are about to assign it with a 4 and SETGID with a 2. To make the
To SETUID on the program ls, you would type in :
Chmod 4755 /bin/ls (Only used for demonstration purposes.)
Users should not be allowed to run setuid/setgid programs from their home directories. This is something that can be prevented using the nosuid option in the /etc/fstab for partitions writable by users. In addition it is possible to restrict the execution of programs using noexec on user's homer partition, but most students need to have this functionality. To keep things simple Linux doesn't use the user's name, but the UID to set file ownership. And the passswd file is used to perform a mapping between user's UID and login so that it can make directory listings more human readable. chmod 4755 /usr/bin/passwd you will have the ability to write to the /etc/passwd file, even though you have only read access to it. However this program is an exception, since it has an extra security feature which only permits the user to change their own password and not other users. This is why when the shadow file is enabled, even though the passwd binary file has the setuid set, it is still safe to use it. Crackers favorite is to leave 'setuid root programs' which will give them a back door even if the original issue was patched.
It is therefore good practice to have a list of all the setuid/setgid
programs to be aware if any changes have occurred.
This can be done with the following command: find / -type f -perm +6000 -ls
The files created by the root, automatically get the group ownership of the directory they were created in. The security implication of this is that anyone who now belongs to this group has rights. Also a lot of systems tend to overlook the /tmp directory where SUID shell scripts programs can exist and be executed.
http://www.redhat.com/support/docs/tips/urls/txt/intruder_detect_checklist
Here are three excellent examples of things that should not be done:
Chmod 4755 /bin/vi (Now when you execute files as a regular user you have the ability to save files you only have read access to.)
Chmod 4511 /usr/bin/passwd (However although passwd does the exact same function as vi during it's execution to allow the modification of the /etc/passwd since you become the administrator for that instant.)
Chmod 4755 /usr/bin/bash (This modification would allow anyone regular user to open up a new shell as the root, very dangerous.)
Now type: gnome-terminal (# indicates that you now have root access.)
World writable files can also be a security risk, and can be located with the following command:
find / -perm -2 ! -type l -ls (However for some files in /dev this is normal.)
An unowned file can also be an indication someone got into your system. The following command will list them:
find / -nouser -o -nogroup
Sticky bit 't' - is used on directories, it allows any user to delete only their own file even if that user has write access to that directory.
Eg. /tmp
Chmod +t nameofdirectory
Symbolic mode uses letters
|
r w x |
r w - |
r - - |
Absolute mode uses octal values, thus numbers.
|
1 1 1 |
1 1 0 |
1 0 0 |
Octal Equivalent is (7) (6) (4) since 2^0+2^1+2^2
Directory permissions:
3 -wx -write to a file you know the name of.
5 r-x -list all files in directory.
7 rwx -list files in directory, write in it and delete them.
Please note that in directory permissions, if the x is not there you can't do much. Also + means to add to the existing permissions, - means to remove from the existing permissions and = means to set a new permission. Prior to setting permissions you should note that there are three classes the owner (u), group (g), and anyone who is not a member of the group is other (o). To modify all three types of users you may use all (a) instead.
Chown - used to change the ownership of a file to a different user.
Chgrp - used to change the group to which a file belongs to.
(Please note that when you use the -R option, the command descends through all the subdirectories and any links it encounters, the permissions is changed on the file to which these links point to. Also in order for a regular user to change a files group ownership, this user needs to be a member of both of these groups.)
Umask - is set to keep the default file or directory creation permissions from not being restrictive enough. It is usually set in /etc/profile and is set to 022. Thus if your default file permission is 777, this would set the allowed permissions to 755 by substracting umask mask. Thus the root's umast should be at least 022, to disable write and execute permissions to other users. It is important to note that if inetd is started at boot time, and it's bootmask is not set then any services it controls will start with that umask. Thus a service like Telnet may allow too lenient permissions, it is therefore a good idea to create a file that gets run at system boot up before any others which set the umask.
World writable directories - directories which are usually used for temporary files like /tmp, like the ones created by a printer daemon, X11, give the potential of being exploited by writing into a prexisting file if the user guesses the name of the files written to this directory.
Passwd file - is used to store user and group names to map the proper ID to the username.
Shadow file - contains the username and the password. It can be enabled with /usr/bin/pwconv. In Red Hat 4.2 or above the PAM modules will automatically adapt to this change. To check for good passwords, it is a good idea to have the module pam_cracklib enabled, it is part of PAM and will check if it is too easy to guess. Please click here for documentation about the Shadow Password.
SSLeay - has Apache SSL extensions, and can be downloaded from ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL
HTML password protecting - information about this is available at: http://www.apache.org/docs/misc/security_tips.html
Current Exploits - there is nothing easier than for someone to try a list of the latest exploits on a bunch of computers that have not been patched, which is why it is important to apply the latest patches all the time. One place is http://www.rootshell.com
CGI binary attack on the web - this is another way that an intruder can gain access to a system which is why it is a good idea to only allow users that wish to execute CGI scripts using a program called " ". Additional information can be obtained from
http://www-genome.wi.mit.edu/WWW/faq/www-security-faq.html
http://www.apache.org/docs/misc/security_tips.html
Protecting the Files:
- it is never a good idea to specify personal directories before system directories in the path, since it may provide a means to execute a Trojan horse.
- system configuration files and shared binaries must be protected against write and modification privilages. Therefore they should never be writable by a group or everyone.
- restrict the modification of system start-up scripts
- protect audit log files from modification, thus make sure that the /var/log is readable only since it contains all the log files.
- when using NFS, the /etc/fstab should have the required restrictions such as nodev, nosuid, or even noexec.
- ulimit -s new-size or setting up the /etc/security/limits.conf can be used to restrict the file space. Quotas on accounts should be set to prevent DOS attacks.
- the /etc/shadow should only be readable by root.
9. Kernel
Security.
PAM (Pluggable Authentication Modules) is shipped with the newer versions of Red Hat Linux, and some of the basic things that can be done with PAM is enable shadow passwords, allow users to log in at specific times and from specific locations, set resource limits on the number of processes, the amount of memory such that DoS attacks will be prevented, even disable the use of .rhosts file from the user's home directories. PAM also allows for the system to just plug in a shadow module when using shadow passwords and no longer requires the recompilation of the binaries in order to support the shadow file.
For more information about PAM please click here.
There is a bug in the Linux kernel capability model for versions up to
and including 2.2.15 that allows local users to get root. It is important to
upgrade the kernel to a higher version asp., the procedure for doing so is
described below. You can check your version using the command:
uname -a
The Servers should especially be well protected. Most of the security that
is done at present is to prevent a regular user at becoming a root, but it
would be best if this ability was simply removed in the future. The goal is to
restrict the following; make user stack area non executable, restrict links
& pipes in /tmp, and restrict accessibility to /proc. It is a good idea to
have the following enabled in the Kernel:
IP: Drop source routed frames (Config_ip_nosr) - will protect a system from data entering your system from a router since it would need to inspect the packet and no just forward it on.
IP: Firewalling (Config_ip_Firewall) - will allow you to configure your computer as a firewall, and do masquerading.
IP: forwarding/gatewaying (Config_ip_forward) - will make a linux box become a router, and you can forward data from one network to another, thus bypassing a firewall and should be used in conjunction with firewall software. Since kernel 2.0.33 the files in /proc always appear to be of length zero which is a new security feature.
IP: firewall packet logging (Config_ip_firewall_verbose) - will give the option to view information about the sender, recipient, port number when a firewall is configured.
IP: always defragment (Config_ip_always_defrag) - although it is usually disabled, but if you are building a firewall or masquerading then this should be enabled. When data is sent from one host to another, it does not always get sent as a single packed of data, but it is fragmented into several and the port numbers are only stored in the first fragment, which means that someone would be able to insert information into the remaining packets of a connection which should not be there. It could therefore prevent a teardrop attack of an internal host.
IP: syn cookies (Config_syn_cookies) - SYN attack is a denial of service (DOS) attack that consumes all of the resources of a computer and forcing a reboot. This should be enabled.
Packet Signatures (Config_NCPFS_Packet_Signing) - with this enabled in kernel version 2.1, it will sign NCP packets for stronger security if you choose to use it.
Secondly Server kernel-level functions can be added in to show last commands executed in reverse order "lastcomm", and turing on logging of processes with action. To manage these kernel-level functions you need to get the package from the URL: ftp://sunsite.unc.edu:/pub/Linux/system/admin/accounts/acct-1.3.73.tar.gz
Kernel Security Configuration - since the kernel controls the computer, it is important that it is very secure. You may wish to look at the two URL's below.
http://www.kernel.org/pub/linux/libs/security/linux-privs/README (Great)
(There are various programs that can be downloaded to check a system for common exploits from http://rootshell.com/beta/exploits.html)
Upgrading to the latest version of RedHat is recommended.
Option 1:
If you don't have a CD bootable computer, you need to download the boot.img
- then from the RedHat CD you can get the rawrite.exe and use it in a Windows type of environment to create a Bootable Disk.
- Type: rawrite
- Type: boot.img
- Insert a blank disk and press enter.
- If you're using Linux to creat the bootable disk type, note do no mount the floppy device. Simply go to the location containing the boot.ini file and the type:
dd if=boot.img of=/dev/fd0 bs=1440k
or
mkfs -t ext2 /dev/fd0 1440
or
mkbootdisk --device /dev/fd0 #ofKernel
Format:
fdformat /dev/fd0H1440
Option 2:
The alternative is to download the ISO image of the whole CD and then using a CD-Burner the image can be opened using the Cd-Writer software and then placed on to the CD. To find the ".iso" image of RH6.2 go to URL:
ftp://ftp.crc.ca/pub/systems/linux/redhat/ftp.redhat.com/current/iso/
If the bios is modified, the computer will simply boot of the CD and begin the installation.
ncftp ftp.utoronto.ca/mirror/linux/redhat/redhat-6.2/i386/RedHat
(You only need to download the files in the RedHat directory to do the upgrade.)
get -R RedHat
Now insert the boot disk and simply follow the instructions.
English > Keyboard type "US" > Local HD >
/dev/hda2/RedHat > Upgrade
(Please note that you will find the /tmp/upgrade.log after it is complete.)
Updating the Kernel + Patches after the Upgrade.
(This URL lists all the security updates.)
http://www.redhat.com/support/errata/index.html
a). Create a boot disk : mkbootdisk --device /dev/fd0 kernel#
b). First choose one of the mirror ftp sites from http://www.redhat.com/download/mirror.html such as the one below.
c). ncftp ftp://ftp.utoronto.ca/mirror/linux/redhat/updates/6.2/i386/
(Note that the updates directory contains the RPM updates.)
get -R i386
d). Once all the patches have been downloaded, remove any of the kernel patches since they can be troublesom. Unless it is absolutely necessary to apply them.
Type: rm *kernel*.rpm
e). Next update all the non kernel packages, thus only the ones that have already been installed.
Rpm -Fvh *.rpm
f). Update the Kernel and Modules.
(Note that upgrading the Kernel is not recommended since it can be more trouble then it is worth and should only be done if new functionality is obtained that is required or a security issue has been released.)
First delete the " /usr/src/linux " directory such that when the RPM's are installed, the source code will not uncompress accidentally and mix with the older files.
You must install the new kernels, instead of performing an upgrade as a an added safety step. This way the old kernel and modules will still be there and you should be able to boot back into the old version if required. Secondly please make sure that you apply only the same revision number of the kernel RPM files. Also, although in the example below we have use .0.1 , it should be much higher now.
Rpm -ivh kernel-pcmcic*.0.1.i386.rpm
Rpm -ivh kernel-ibc*.0.1.i386.rpm
Rpm -ivh kernel-2*.0.1.i386.rpm
(Please note that if you find that there are conflicts between the old and new kernel-pcmica packages you can try to force the install.
"rpm -ivh --force kernel-pcmcic*.0.1.i386.rpm"
(Updating Extra kernel patches is optional and is up the the individual to install.)
rpm -Uvh kernel-smp*.0.1.i386.rpm
rpm -Uvh kernel-BOOT*.0.1.i386.rpm
rpm -Uvh kernel-doc*.0.1.i386.rpm
rpm -Uvh kernel-utils*.0.1.i386.rpm
g). Please note that once the kernel has been installed, the RPM should have created the proper symbolic link from the vmlinuz with the new kernel# that has been installed.
Type: ls -l /boot/vmlinuz*
h). If you are using SCSI device, then you need to initial the RAM disk.
Type: mkinitrd /boot/initrd-#.img new#
"This will create an initial RAM disk in /boot/initrd-#.img
i). open the "/etc/lilo.conf " file and make the necessary changes.
Eg.
boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
linear
default=linux
#This is the Latest Kernel (For Testing.)
image=/boot/vmlinuz-2.2.14-6.0.1
label=linux
read-only
root=/dev/hda2
#This is the Older Kernel.
image=/boot/vmlinuz-2.2.14-5.0
label=linux-old
read-only
root=/dev/hda2
j). Type: lilo -v
This will write the changes to the boot sector that LILO is installed on.
Then make a new bootdisk: mkbootdisk --device /dev/fd0 Kernel#
Type: shutdown -r now
(Reboots the computer and starts up with the new kernel.)
k). Xfree86 patches
If you have applied these patches as well, they can also be applied separately in the following manner:
1. Get a list of what is installed:
Rpm -qa | grep -I Xfree86
- Apply the patch
Rpm -Uvh --force X_Free86*.rpm
- If you use the X11 Server then type:
- Cd /usr/X11R6/bin
Ln -s XF86_SVGA X
5. Then to check type: ls -l /etc/X11
l). Making the kernel modularized.
1. With the introduction of kernel 2.0.x, custom kernel modularization became possible which includes the ability to add certain hardware components, or filesystems which are not used frequently. These modules would then load them on demand.
First you must install the kernel-headers and kernel-source packages. Then proceed issuing all commands from " /usr/src/linux/"
2. First confirm that these packages have been installed since they are required to continue.
Rpm -ivh kernel-headers*.rpm (To check: rpm -ql kernel-headers )
Rpm -ivh kernel-source*.rpm
Rpm -ivh make-3.78.1-4*.rpm ("Build Manager")
Rpm -ivh egcs-l*.rpm ("C-compiler")
Rpm -ivh glibc-devel*.rpm ("C-Libraries")
Typing the command below will create a '.config' file which will determine which components to include in the new kernel. Choose one of the three commands below , then you will be prompted with options such as Y=Yes, N=No, & M=Module If you simply press enter it will be left as the default or whichever letter is capitalized in the list.
make config - text driven
make menuconfig - menu driven
make xconfig - X-Windows graphically driven.
Note that to use kerneld - Choose Yes to "Kerneld support" Also to use kernle modules, choose Yes to "module version CONFIG_MODVERSIONS support.)
(Enable loadable module support)
(Set version info on all symbols & modules)
(Kernel module loader.)
3. (Please note that ' make oldconfig' will get back the old configuratin file .oldconf)
4. If the " /usr/src/linux/.config" file has already been created previously then you don't need to enter the following commands:
'make mrproper'
(This will remove any configuration files from previous builds that may be scattered around the source tree.)
'make xconfig'
(This will make create the .config file)
5. 'make dep'
(makes the dependencies)
'make clean'
(Prepares the source tree for the build)
'make boot'
(Builds the kernel.)
'make modules'
(Builds any modules you configured in the .config file, and creates & updates the source code modules '/usr/src/linux/modules/ ' directory.
(Please note that it is recommended to make a backup copy of the old modules directory.)
mv /lib/modules/# /lib/modules/old_#
'make modules_install'
(Installs the new modules in /lib/modules/kernelRelease#/ )
6. Now simply add the new kernel that was created into the /etc/lilo.conf
file as above, thus allowing you to use the previous kernel if you choose to.
Then execute:
' cp /usr/src/linux/arch/i386/boot/zImage /boot/vmlinuz# '
(Will copy the new kernel to the proper location.)
lilo -v
shutdown -r now
7. That's it, now if you wish to add more modules into the kernel. You don't need to recompile the kernel to do so, simply adding aliases to the ' /etc/conf.modules ' file will enable this. Eg. 'alias iso9660 isofs'
Also please make sure that /etc/rc.d/rc.sysinit has a line with
/sbin/depmod -a
(Please note that in the case of a monolithic kernel (one doesn't use the kerneld) you need to comment out that line, and don't choose 'm' for any of the options when creating the .config file.)
Additional info can be found by:
Man conf.modules
In the modules.txt
Depmod -v (Lists locations of modules.)
You can test if certain modules will work by typing:
insmod modulename.o (Adds the module, which will only be available until the comptuer is rebooted.)
rmmod modulename.o (Remove the module.)
lsmod (Lists all the modules.)
Additional commands:
rpm -q kernel
ls -lratc /boot
ls -ratc /boot
top
10. Writing
Secure Code.
The internet is a great source to learn how to write secure code, how vulnerabilities
are created, and how to prevent them. Below are some links which are a good
starting point for writing secure code:
Auditing existing code for vulnerabilities: http://www.pobox.com/~kragen/security-holes.html
Writing secure setuid programs: http://seclab.cs.ucdavis.edu/~bishop/secprog.html
Mechanisms for designing secure software: http://www.homeport.org/~adam/review.html
Program code exploits - currently there is a group of people called the Linux Security Audit group which audits various packages that vendors ship with their distributions. Their archive can be located at http://www.nas.nasa.gov/Pubs/Mail/archive/linux-security-audit/ Buffer overflow is common in programs since common coding does not check for over flows when buffers are not large enough. When this occurs the executing program's functions return address on the stack can be tricked to point to another location causing a new shell to open with the setuid of the user that owns it.
Directory exploit - by being able to predict a temporary filename that will be created in the world writable directory /tmp it is possible for a user to reveal confidential information about a system. There are many programs that use the /tmp directory, and once in a while an exploit comes out. The original solution was to use the sticky bit, which would only allow the original owner of that file to write to it. However a standard trick is to create a symlink that has the name of the expected file name and instead points to a different one some place else which does something else beside what it is suppose to do. There are methods that allow you to gain access to the rights of the user opening that file. When writing code, the solution is to have a libc function that securely creates a temp file and passes a file descriptor to that file. Another solution is to make distributions set the temporary files to $HOME/tmp instead. Also using mkstemp programs already exist which can be used to make the temporary file created more secure.
Preventing Buffer Overflows - this is an attempt to exploit a bug in a program that doesn't allow enough space to store the data in a buffer, and then using this advantage to write past the end of the buffer in another memory space. This is very common in programs that use an array declared auto, and can cause a return from written pas the end of the arry to jump to a random address. Never create a setuid or setgid shell script since it is a security problem, instead, write a C program and make it suid or sgid as appropriate. A full explanation can be found at http://l0pht.com/advisories/bufero.html
Also: http://reality.sgi.com/nate/machines/security/
Restricting the directory /proc will prevent regular users from seeing information about other peoples processes, and any current network connections. This will make it more secure but may bring about some drawbacks. http://www.false.com/security/linux/index.html
CGIWrap - is a program which will allow anonymous users to use CGI scripts and HTML forms without compromising the security of the web server. The scripts are run with the permissions of the user who owns the script, but in addition there are various security checks which are performed and prevent the script from being executed if they fail. http://www.unixtools.org/cgiwrap/
Firewall - is software or hardware that filters and limits access to the protected computers of an internal network. It is usually used to keep intruders from the Internet from gaining entry to the internal network. In Linux, it can be built right into kernels 2 and higher, 'ipfwadm' is one such program that uses kernel based packet filtering. It allows you to log traffic, block it or let it come through. You can accept or deny packets based on their source, destination address, port number, protocol, including TCP, UDP, ICMP, and even monitor the number of bytes transferred. Even if there is a firewall it is a common mistake to believe that this makes the machines behind it secure, this is because services which are allowed back into the network can still be exploited. The latest version is most likely included with your distribution of Linux. IP chains is another package which is a complete rewrite of the 'ipfwadm' utility, and it is intended to be used with Kernel version 2.1 or higher. It was written since it can deal with fragments, has additional specifications on many protocols, can make changes on the fly, allows inverse rules, and is easier to manage. Ipfwadm is specific to 2.0 version of the Kernel and IP Chains to Version 2.2 plus there are a lot of improvements.
There are many different types of firewalls available, such as:
Packet Filter Firewall – this type of firewall looks at each packet of data that is entering or leaving the internal network and either accepts or rejects it based on a set of rules that have been defined. These rules may be based upon an IP address, port type (such as port 21 for ftp), or both. Although a packet filter firewall is effective, they can be tricky to configure. The more complex the filter rules are, the more likely it is that an error in configuration will be made and thus lessen the security of the firewall.
Application Gateway - this type of firewall applies specific security measures on specific types of applications. For instance, an application gateway can be configured to allow http traffic but block everything else.
Proxy Server - is a computer that hides the IP addresses of an internal network from the outside world. This way a web server sending a web page over to your web browser will not connect with your computer directly, but instead to the Proxy server which will pass the information to your computer. A proxy server also caches Internet requests, thus if a reapeated request to the same site can be processed faster.
Stateful Inspection - it examines the state of any active network connections and based on this information determines what packets to accept or reject. This is an active process that does not rely on static rules. It is the easiest to configure and has become one of the most popular firewall types.
Socks - allow the hosts on one side of a socks server to gain full access to hosts on the other side without direct IP reachability. http://www.socks.nec.com/
Choke - a device such as a router that performs packet filtering. Routers can be programmed at lower levels than general purpose operating systems like Unix and thus don't have their vulnerabilities and are designed for high speed.
Masquerading - involves setting up a linux box which has a fake IP address, to which packets are transferred from a real IP address. http://sunsite.unc.edu/LDP/HOWTO/mini/IP-Masquerade.html or http://ipmasq.home.ml.org
General Firewall Information: http://www.nwfusion.com/reviews/0719bg.html
Firewall Buyers Guide: http://www2.nwfusion.com/cgi-bin/gate2?nwfusion|firewalls/bg.html
Firewall Design - http://www.sunworld.com/swol-01-1996/swol-01-firewall.html
General Information about Firewalls - http://www.3com.com/nsc/500619.html
Using Linux as a Firewall - http://linux.samiam.org/firewall.html
Firewall Mailing List : http://www.lists.gnac.net/firewalls/
Graphical Firewall for Linux: http://www.ifi.unizh.ch/ikm/SINUS/sf-doc/
"GREAT Web Site Security – IP Chains, Ports, ETC: http://www.xmission.com/~howardm/security.html
Firewall Toolkit - is a full featured firewall available for linux 'FWTK' which consists of a set of programs to facilitate the building of network firewalls and it's components can either be used separately or in combination with other firewall components. http://www.tis.com/prodserv/fwtk/fwtkoverview.html
Some of the things you should check for is whether the firewall is capable of preventing common attacks such as IP Spoofing, Fragmentation attacks, Denial of Service, etc. Also Administration should be centrally controlled. Please have a look at the links we have provided above, since this is not the intent of this document.
A virus is simply a computer program that is intentionally written to attach itself to other programs or disk boot sectors, and replicate whenever those programs are executed or when infected disks are accessed. Although there are not a lot of viruses on Linux, they have been around for some time. Below we have provided some examples of viruses which exist because of some vulnerabilities of operating systems that have not been patched. However if the operating system is kept up to date with the latest security patches, Antivirus software should not be required.
Worms - are not triggered by user actions, they attach themselves to other programs without changing them. The Internet worm has gained access to more than 6K Unix systems, and flooded the internet with too many access requests.
http://www.cert.garr.it/alerts/msg00085.html
ADM Worm for Linux x86 - The worm propagate's itself, and is only a few working binaries. The main file is called "admw0rm" which is a shell script. When run, along with portscanning, it hunts for files with a *.html suffix, overwriting their contents and wiping contents of log files. It scans for IMAP ports, POP, rsh/rlogin, telnet, ftp, gopher ports and keeps a log in /tmp/outro. It works on Buffer overflows of the SUID root daemons that have not been patched. To disinfect it would simply require deleting all the new binaries created in /tmp. This worm infected Redhat 5.2 computers, although has not been tested on higher releases. For interest the code can be obtained from Bugtraq or http://www.freelsd.net/ADM/
http://www.cert.org/summaries/CS-98.05.html
Trojan Horse - a program that is unauthorized, not self replicating, it has a misleading name, it is a binary that sounds great, and the idea is to get people to download it and run as root. Then when the root is not paying attention you compromise their system. One great example is the tcp-wrappers which was distributed to various ftp servers. Thus even though the binary may do what it is supose to do, it also does something else compromizing security. This is where MD5 checksums come in handy, and PGP for RPM files.
http://www.hicom.net/~oedipus/virus32.html
Current Antivirus Software for Linux can be located at the following site: http://linuxtoday.com/stories/6119.html
An SMTP mail server is considered to be running an open mail relay if it
accepts messages from users that do not have an account on the mail server, and
are not the true originators of the e-mail. These open relays are frequently
used by spammers to send large quantities of unsolicited bulk e-mail, while
hiding their true identity.
Stop Mail Relay http://maps.vix.com/tsi/
ftp://info.cert.org/pub/cert_advisories/CA-97.05.sendmail
To determine which version of sendmail is running, you may use telnet to
connect to the SMTP port (25) on your system:
telnet ServerName 25
It is recommended to use smrsh (sendmail restricted shell) which controls the way incoming messages can interact with the operating system. When configured correctly it will prevent an intruder from using pipes and execute arbitrary commands.
Qmail - since version 0.91 it prevented relay by default, and only accepted valid destination addresses.
Sendmail V.5 - has lots of security holes, and preventing relay from unauthorized users is not possible and thus needs to be updated to the latest version. Starting with sendmail-8.9, anti-relaying was enabled by default, which prevented remote hosts from using the mail server to forward spam to other hosts. Linux kernel versions through 2.2.15 will allows local users to get root. Sendmail is one of the programs that can be attacked in this manner, which is why the kernel must be upgraded to version 2.2.16
Sendmail V.8 - Since version 8.8.4 it requires adding in anti-relay configurations and removelocal portion of check_rcpt, or limiting mail server access only to users that are authenticated with a POP password. Sendmail Version 8.9.0 and above, prevent relay by default, plus it has "Anti-Spam" capabilities which can also be obtained seperately for the lower versions. Unfortunately some of these solutions will require the configuration of a list of domains to which realy is allowed or rejection of mail may occur.
Simple Mail Transport Protocol (SMTP) - this is one of the most vulnerable protocols and which is why it is important to keep up with the security exploits. http://www.sendmail.org
14. Security Sources\ Mailing
Lists.
Latest Patches - can be located at the Linux vendor's errata in their Updates archive. The announcement list from each vendor describes the procedure for finding proper updates.
UofT Computing and Networking Services - http://www.utoronto.ca/security/contact.html
This web site - http://www.eecg.toronto.edu/~asosin/secr_links.html
Red Hat - linux-alert-request@redhat.com with a subject of 'subscribe'
Linux-specific Security Issues linux-security-request@redhat.com with "subscribe linux-security" in subject.
BUGTRAQ listserv@netspace.org .
CERT Advisories cert-advisory-request@cert.org
WWW Security www-security@ns.rutgers.edu
Firewalls Discussion List majordomo@lists.gnac.com with "subscribe firewalls" in the body.
List of Security lists - http://www.faqs.org/faqs/computer-security/secmaillist/
Large Number of Security Programs - http://www.cs.purdue.edu/coast/hotlist/
Current exploits that are being used - http://www.rootshell.com/
Lists vulnerabilities affecting a specific platform - http://www.infilsec.com/vulnerabilities/
Linux Pluggable Authentication modules - http://www.kernel.org/pub/linux/libs/pam/
15. Useful software\ Security
Tools that can be installed to improve the security of each computer.
Below are three web sites equipped with scanners to check the security of your ports:
http://www.sdesign.com/cgi-bin/fwtest.cgi
http://trojanscanner.com/cgi-bin/nph-portscanner
https://grc.com/x/ne.dll?bh0bkyd2
Documentation of the type of port scans that can be performed on a
system:
http://www.2600.com/phrack/p51/ and http://www.dhp.com/~fyodor/nmap/
The following is a list of the most frequently used programs with RedHat:
chage - change user password expiry information
chgrp - change the group ownership of files
chown - change the user and group ownership of files
gpasswd - administer the /etc/group file
groupadd - Create a new group
groupdel - Delete a group
groupmod - Modify a group
groups - display the groups a user is in
grpck - verify integrity of group files
grpconv - convert to and from shadow passwords
grpunconv - convert to and from shadow passwords
lastlog
newusers - update and create new users in batch
nologin - prevent non-root users from logging into the system
passwd - update a user's authentication tokens
pwck
pwconf
pwconv - convert to and from shadow passwords
pwunconv - convert to and from shadow passwords
showmount - used to check that the configuration of the /etc/exports files on the hosts are correct.
su - run a shell as a different user
useradd - Create a new user or update default new user information
userdel - Delete a user account and related files
usermod - Modify a user account
vigr - edit the password or group files
vipw - edit the password or group files
Security Tools:
Various Security tools can be obtained from the following archive: http://www.cs.purdue.edu/coast/hotlist/
(Then please choose Tools on the website.)
SATAN (Security Administrator Tool for Analyzing Networks)
- is a program with a web interface, which scans different ports looking for the most known vulnerabilities from the CERT advisories. Just because it doesn't find anything, that does not mean that there are none. http://www.trouble.org/~zen/satan/satan.html
SAINT (Security Administrator's Integrated Network Tool)
- is a program that gathers information about remote hosts by examining their services, such as NFS, NIS, ftp, finger, etc. The information lists incorrectly configured network services, well known bugs in systems, hardware/software used, and their utilities. The results can be looked at with Netscape or any HTML web browser. http://www.wwdsi.com/saint/
Rhino9 (Auditing Tool)
- is a program that allows you to check the kernel, all accounts without a password, list every SUID program on a system and which pose a possible vulnerability, check for a sniffer promisc mode, check the permissions of vital directories, check for Inetd backdoor, seachr for .rhosts files, check exports, list current listening ports, check for anonymous ftp, check for trusted xhost, check X11amp, check for TCP wrapped ports, and can e-mail the results.
S3 (System Security Scanner)
- is a program that allows the Administrator to find system vulnerabilities such as file permissions, network services, account setups, operating system configurations, and users passwords.
Gabriel
- is a program designed to detect scans and attacks from programs such as SATAN can be downloaded from: http://www.COAST.com
Kikstart
- is a great tool that comes with Linux on the RedHat CD and can be used to automate the installation process. Most administrators will copy a section of the CD to a hard-drive where they modify the installation to take all the manual work of making all these changes. This is especially useful when patches need to be applied and permissions need to be changed.
TCP-wraper
- runs tcpd also know as tcp daemon, which was not done in older Linux. It allows logging of requests, and restricts access to individual computers. It can restrict it to the point where only a range of IP addresses would be capable of connecting to this system remotely.
(Some copies of the file tcp_wrappers_7.6.tar.gz have been modified by an intruder and contain a Trojan horse.)
Portsentry and logcheck.
Configure portsentry to drop routes of attacking machines.
Cron an ipchains -F (flush) to run every once in a while.
/sbin/ipchains -A input -j REJECT -i eth0 -p icmp -s 0.0.0.0/0 -d your external IP
/sbin/ipchains -A output -j REJECT -i eth0 -p icmp -s 0.0.0.0/0 -d your external IP
http://www.psionic.com/abacus/portsentry/
TripWire:
1. ./install.sh (Runs the installation script, and uses the default values.)
install.cfg - sets the configuration variables which specify the target directories where the installer will copy files.
install.sh - is the installation script, which begins the installation
/pkg - is the directory containing the files required for the installation of the program.
2. Make a backup copy of the install.sh file and install.cfg, if you plan to modify them. Also note that the ./install.sh will execute the install.cfg file to generate your configuration file, it will also locate any special configuration needs for your install.
3. To perform an unattended install, you need to type in the command below.
./install.sh /download/tripwire/install.cfg -s "sitepassphrase" -l "localpassphrase" -f -n
4. Compile any changes you made with twadmin.
5. After the installation:
Edit twcfg.txt
6. Edit the policy file, then sign the edited policy and config. files.
Eg. to sign the config. file type:
./twadmin --create-cfgfile --site-keyfile ../key/site.key twcfg.txt
7. Delete the plain text copy to hide the locatoins of Tripwire's files and prevent anyone from creating a second config. file.
8. Initialize the Tripwire database file
9. Run the first integrity check.
10. The installation process used the shell script "install.cfg", to create an encoded signed configuration file "tw.cfg" and a text copy "twcfg.txt" in the Tripwire /bin directory.
Once you completed the installation, you can make any additional changes to cwcfg.txt
11. POLFILE - Policy file, DBFILE - database file, REPORTFILE - report files,
SITEKEYFILE - site file & LOCALKEYFILE - local key files. This is where these files reside, using the paths specified in the twcfg.txt
12. Edit the Policy File. Any decisions you have recorded about what files to protect and what file properties you want to monitor will be useful in this procedure. This procedure tells you how to express your decisions for Tripwire operations.
13. Open the policy file twpol.txt with a text editor, then follow the syntax shown and read the comments carefully. When you are ready to use it for the first time, you will need to create it with the following command:
./twadmin --create-polfile ../policy/twpol.txt
This is the only time you will use the --create-polfile mode.
14. After creating the first policy file, the next step will be to create the baseline Tripwire database. In Database Initialization mode, tripwire reads the policy file, generates a database base on its contents, and then signs the resulting database, putting it in the location specified by the configuration file's DBFILE variable.
The integrity of the system should not be compromised, prior to installing tripwire.
Run the tripwire program in Database Initialization mode using the following command :
./tripwire --init
When this command has executed, the database is ready and you can check system integrity and review the report file.
Although there are many thousands of programs that can be used to increase computer security, we have provided a list of what we feel as some of the best ones out there. This does not mean that they are the only ones you should use, but they will be adequate to have sufficient security.