|
|
 |
|
|
|
register |
bbs |
search |
rss |
faq |
about
|
|
|
meet up |
add to del.icio.us |
digg it
|
|
|
|
Common UNIX System Configurations That Can Be Expl
NOTICE: TO ALL CONCERNED Certain text files and messages contained on this site deal with activities and devices which would be in violation of various Federal, State, and local laws if actually carried out or constructed. The webmasters of this site do not advocate the breaking of any law. Our text files and message bases are for informational purposes only. We recommend that you contact your local law enforcement officials before undertaking any project based upon any information obtained from this or any other web site. We do not guarantee that any of the information contained on this system is correct, workable, or factual. We are not responsible for, nor do we assume any liability for, damages resulting from the use of any information on this site.
Common UNIX System Configuration Problems That Are Exploited
1. Weak passwords
Intruders often use finger or ruser to discover account names and
then try to guess passwords. Encourage your users to choose passwords
that are difficult to guess (for example, words that are not in any
dictionary of any language; no proper nouns, including names of "famous"
real or fictitious characters; no acronyms that are commonly used by
computer professionals; no simple variations of first or last names.)
Furthermore, inform your users not to leave any cleartext
username/password information in files on any system.
A good heuristic for choosing a password is to choose an
easy-to-remember phrase, such as "By The Dawn's Early Light", and use
the first letters to form a password. Add some punctuation or mix
case letters as well. For the phrase above, one example password
might be: bt}DeL{. (DO NOT use this sample phrase for your password.)
If intruders can get a password file, they usually move or copy it to
another machine and run password-guessing programs on it. These programs
involve large dictionary searches, and they run quickly even on slow
machines. Most systems that do not put any controls on the type of
passwords used probably have at least one password that can be easily
guessed.
If you believe that your password file may have been taken, change
all the passwords on the system. At the very least, you should change
all system passwords because an intruder may concentrate on those and
may be able to guess even a reasonably "good" password. Intruders
often use compromised accounts to attempt to gain privileged access
on vulnerable systems, so we encourage you to follow the steps in
ftp://info.cert.org/pub/tech_tips/intruder_detection_checklist
ftp://info.cert.org/pub/tech_tips/root_compromise
For further information about protecting your system from password-
based attacks, see
ftp://info.cert.org/pub/tech_tips/passwd_file_protection
2. Accounts without passwords or default passwords
Intruders exploit system default passwords that have not been changed
since installation, including accounts with vendor-supplied default
passwords. Be sure to change all default passwords when the software
is installed. Also, be aware that product upgrades can quietly change
account passwords to a new default. It is best to change the passwords
of default accounts after applying updates.
Scan your password file for extra UID 0 accounts, accounts with no
password, or new entries in the password file. Do not allow any
accounts without passwords. Remove entries for unused accounts from
the password file. To disable an account, change the password field
in the /etc/passwd file to an asterisk '*' and change the login shell
to /bin/false to ensure that an intruder cannot login to the account
from a trusted system on the network.
3. Reusable passwords
Even excellent passwords are not safe. They can be captured by programs
such as packet sniffers if the passwords are sent across networks in
cleartext (whether on a subnet, a local network, or the Internet).
We recommend using one-time passwords, especially for authenticated
access from external networks and for access to sensitive resources
like name servers and routers. For more information, see Appendix B of
the following advisory:
ftp://info.cert.org/pub/cert_advisories/CA-94:01.network.monitoring.attacks
4. Use of TFTP (Trivial File Transfer Protocol) to obtain password files
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
As mentioned in Section 1 above, if you believe your password file
may have been taken, the safest course is to change all passwords in
the system.
5. Vulnerabilities in sendmail
There have been a number of vulnerabilities identified over the years
in sendmail(8). To the best of our knowledge, the current version of
sendmail addresses those known vulnerabilities.
To determine which version of sendmail is running, use telnet to connect
to the SMTP port (25) on your system:
telnet <your hostname> 25
We encourage you to keep up to date with the latest version of sendmail
from your vendor, and ensure that it is up to date with security patches
or workarounds detailed in CERT advisories and bulletins. For
information about the latest version of sendmail, see
ftp://info.cert.org/pub/latest_sw_versions/sendmail
In addition, we encourage you to use the following tools, both of which
are distributed with the latest versions of sendmail:
(a) smrsh, the sendmail restricted shell, controls the way that
incoming mail messages can interact with your operating system.
For instance, when configured correctly, smrsh can prevent an
intruder from using pipes to execute arbitrary commands on your
system.
(b) mail.local can be used to control the way in which the /bin/mail
program is used on your system. This tool is described in CERT
advisory CA-95:02.
ftp://info.cert.org/pub/cert_advisories/CA-95:02.binmail.vulnerabilities
If you are not running a recent version of sendmail, the above tools
may also be obtained individually from a number of sources, including
ftp://info.cert.org/pub/tools/mail.local/
ftp://info.cert.org/pub/tools/smrsh/
Warning: If you are running such an old version of sendmail that you
must install these tools separately, intruders will continue to
be able to exploit vulnerabilities that were fixed in later
versions of sendmail. We urge you to upgrade to the current
version of sendmail mail and then run the tools, which are
included with the distribution.
6. Misconfigured anonymous FTP
In addition to making sure that you are running the most recent
version of ftpd, check your anonymous FTP configuration. It is
important to follow the instructions provided with the operating
system to properly configure the files and directories available
through anonymous FTP (for example, file and directory permissions,
ownership and group). 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
information about configuring anonymous FTP, see
ftp://info.cert.org/pub/tech_tips/anonymous_ftp_config
7. Inappropriate network configuration file entries
Several vendors supply /etc/hosts.equiv files with a '+' (plus sign)
entry. The '+' entry should be removed from this file because it
means that your system will trust all other systems. Other files that
should not contain a '+' entry include all .rhosts files on the
system. These files should not be world-writable.
If your /usr/lib/X11/xdm/Xsession file includes an 'xhost' command
with a '+' entry, such as
/usr/bin/X11/xhost +
remove that line. (Note that the 'xhost' command may be in a
different directory tree on your system.) If such a line remains
intact, anyone on the network can talk to the X server and
potentially insert commands into windows or read console keystrokes.
8. Inappropriate 'secure' settings in /etc/ttys and /etc/ttytab
Check the file /etc/ttys or /etc/ttytab (depending on the release of
UNIX being used). The ONLY terminal that should be set to 'secure'
should be the console.
9. Inappropriate entries in /etc/aliases (or /usr/lib/aliases)
Examine the /etc/aliases (or /usr/lib/aliases) mail alias file for
inappropriate entries. Some alias files include an alias named
'uudecode' or just 'decode.' If this alias exists on your system and
you are not explicitly using it, then you should remove it.
10. Inappropriate file and directory protections
Check your system documentation to establish the correct file and
directory protections and ownership for system files and directories.
In particular, check the '/' (root) and '/etc' directories, and all
system and network configuration files. Examine file and directory
protections before and after installing software or running
verification utilities. These procedures can cause file and directory
protections to change.
11. Old versions of system software
Older versions of operating systems often have security vulnerabilities
that are well known to intruders. To minimize your vulnerability to
attacks, keep the version of your operating system up to date and apply
security patches appropriate to your system(s) as soon as they become
available.
For information about software upgrades that fix security problems,
their sources, and their MD5 checksums, see
ftp://info.cert.org/pub/latest_sw_versions/
12. Use of setuid shell scripts
Setuid shell scripts (especially setuid root) can pose potential
security problems, a fact that has been well documented in many UNIX
system administration texts. Do not create or allow setuid shell
scripts, especially setuid root.
13. Inappropriate export settings
Use the showmount(8) utility to check that the configuration of the
/etc/exports files on your hosts are correct.
- Wherever possible, file systems should be exported read-only.
- Do not self-reference an NFS server in its own exports file. That is,
the exports file should not export an NFS server to itself nor to
any netgroups that include the NFS server.
- Do not allow the exports file to contain a "localhost" entry.
- Export file systems only to hosts that require them.
- Export only to fully qualified hostnames.
- 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.
The CERT Coordination Center is aware that intruders are using tools
that exploit a number of NFS vulnerabilities. This can result in a
root compromise, depending on the vulnerability being exploited. We
encourage you to limit your exposure to these attacks by implementing
the security measures outlined in CERT advisory CA-94:15. For this and
other information about the NFS vulnerability, see
ftp://info.cert.org/pub/cert_advisories/CA-94:15.NFS.Vulnerabilities
14. Vulnerable protocols and services
You may want to consider filtering certain TCP/IP services at your
firewall or router. For some related suggestions, please refer to
"Packet Filtering For Firewall Systems," available from
ftp://info.cert.org/pub/tech_tips/packet_filtering
Copyright 1996 Carnegie Mellon University
This material may be reproduced and distributed without permission provided
it is used for noncommercial purposes and the copyright statement is
included.
|
|
|
To the best of our knowledge, the text on this page may be freely reproduced and distributed.
If you have any questions about this, please check out our Copyright Policy.
totse.com certificate signatures
|
|
|
About | Advertise | Bad Ideas | Community | Contact Us | Copyright Policy | Drugs | Ego | Erotica
FAQ | Fringe | Link to totse.com | Search | Society | Submissions | Technology
|
|
|
|
|
|
