Henry's Security Page

This site does not collect any personal information from or about you.

This is my security page. It was designed for a specific company, so there's lots of information, links and tools missing. It's heavily oriented toward AIX. But I think this may be a good resource for some people, so please take advantage of what is presented, if it is helpful and appropriate.

Contents
Selections marked with this symbol contain new items or content.

1. Questions

2. Answers

3. Philosophy

4. Tools and Resources

5. Unix Command Help

6. Virus Checkers

7. Security Checklists

8.
SENDMAIL

The noncommercial versions of sendmail.
The commercial versions of sendmail.
The new sendmail features anti spam control.

9. Correspondence

The Questions

1 No ~/.rhosts file.
2 No /etc/hosts.equiv file.
3 Only 1 user per login ID.
4 Disable rsh, rlogin, rexec, and rcopy.
5 Do not allow remote logons as root.
6 Remove compilers from non-development systems.
7 Remove sendmail and X-Windows binaries where possible. GUIDELINES
8 Do not have a writable ftp home directory.
9 Your umask should be 077.
10 Default ACLs should be NONE.
11 No world/other write permissions on home directories.
12 Nothing in /etc world-writable except utmp.
13 Recent audit trail available for review.
14 Ensure that your operating system has not been compromised.
15 No guest accounts.
16 No joes.
17 Execute CRACK every month.
18 Remove unused and expired accounts regularly.
19 Beware of inappropriate account names.
20 Review the wording of your banners.
21 Passwords should not be easy to guess.
22 Do not export NFS file systems to everyone.
23 Anonymous ftp and trivial ftp should be disabled, when possible.
24 Default cgi scripts (eg. phf) not installed unless specifically needed.
25 Change default SNMP community strings to a strong password.
26 A security package insatlled and in use.
27 CERT and manufacturer packages should be reviewed or installed monthly.
28 No ICMP redirect messages if host is routing packets.
29 No dual-homed hosts unless necessary.
30 All external connections must be via approved gateways.
31 Adhere to the appropriate modem guidelines.
32 Unauthorized sniffers are prohibited.
33 Lock up all confidential information.

The Answers

1A user's ~/.rhosts file allows the account owner to create a set of trusted users, or even hosts, that can log on to that account without a password.
2This is a file that contains a list of hosts, one per line. When a user from a remote host attempts to access this machine, using rlogin rsh or rcp, the host checks this file. If the host that is requesting access is not here, a password is requested and required. The target machine then checks it's own /etc/passwd file. If it contains a line with the username requesting remote access or services, the action is permitted, and no password is requested. Please note that the target machine's own /etc/password file is checked; the user's own /etc/password file, on their host, is never checked.
To gain access,

The corrosponding service must be available on the target.
The host must have a valid entry.
There must be an entry in the target's password file.
The user cannot be requesting root on the target.

Even so, /etc/hosts.equiv relies upon a web of trust. If one machine is compromised, a hole may be opened to other targets. It is also true that users with names other than root may have administrative privileges, or be able to su.
In addition, a line with a + (a single plus sign) in it will allow any user in the world to log on to the target machine if there is a corrosponding entry in it's /etc/passwd file!
Ahem. It gets worse. You might expect that putting a machine name/user name pair in /etc/hosts.equiv would allow that user to log in to the target machine from a particular host. What actually happens is that the named user on the host can log in to any account on the target system! Don't confuse /etc/hosts.equiv with an rhosts file!
hosts.equiv can be very handy; it's especially useful if you have a cluster of machines with a significent overlapping user base, but it can also be a helpful link for abusers.
3the company does not permit shared accounts. Do not let someone else use your login ID or give anyone your password. Instead, make an account, if someone needs access to your workstation, and delete it as soon as it's no longer needed. Or, get the system administrator to create an account if you do not have the correct privilages. Remember to give the administrator plenty of notice when possible. Unless your account was compromised without your knowledge, you may be considered responsible for the actions taken by that user ID.
4The remote shell and remote login daemons wait for a username, which is automatically transmitted from the invoking program. Since no passwords are transmitted, they are not susceptible to sniffing. However, they both rely on the concept of a trusted user or trusted host.
You should disable the server services by commenting out the appropriate lines in inetd.conf, the lines that load rsh, rlogin, rexec and rcp.
It is not necessary to disable the client programs by removing execution bits.
Remote copying and execution daemons allow a trusted user to copy files or execute programs without being logged in to the target machine.
These services are holdovers from (typically) academic computing clusters.

They are all, however, very susceptible to IP spoofing.
They will respond to requests as root.
A user who leaves a computer unattended opens a hole to the entire cluster.
They can be an easy, wide-open path leading straight to the collapse of your web of trust, especially if users' home directories are exported via NFS.
These services are a bad idea. If you feel you must use them, be certain of your reasoning. First, be sure that there is no other alternative. Then stop, find a more secure method, and re-examine your reasoning.
5Ownership of the root account is the Holy Grail of the cracking community. Crackers employ a variety of tools, from sophisticated scripts to social engineering which may be as simple as looking for a password that's written on a post-it note, or calling a user and asking for it. You would be surprised at how often these attacks succeed. To reduce the likelihood of a superuser compromise, ensure that the root account can only log on from the console. Set up a small subset of accounts that are allowed to su, to root or to any other account. Remote users of the root account (a minimal, trusted group) should login via their own account, if they need remote access, then su to root. Better yet, use the sudo program, and a limited group of sudoers who are permitted to execute commands, individually, as root. Make sure that all su activity is logged. Logs should be regularly reviewed, backed up, and shipped off-site or saved on WORM media. Then, make sure that the console is in a secure area. You should never leave root logged on when the console is unattended, even if the keyboard is locked! These steps will make "The Quest" harder.
6A member of the the company security team says: Compilers can and should be on development and support systems, where needed. Our intent is to discourage them from being left on customer systems, like web servers. Your use of compilers in your [working] environment is OK.
A generalized approach to security may be stated as follows:

If you don't know what it is, don't touch it.
If a package is on your system, and you don't use it, consider whether the potential benefits, weighed against resource requirements and the facility's possible liabilities, justify it's presence.
If you can't justify it, consider removing it, especially if the facility is a known source of weakness.
Be sure you know what you're doing, though. See item #1 on this list.

One way of looking at this issue is that the purpose of security is simply to ensure that:

You have continued and uninterrupted access to all authorized resources.
And that unauthorized people are unable to access or use them.
Thus, regular backups, maintenance, and sensible allocation of resources are as much a part of security as access lists and strong passwords. We want to maintain a logical and reasoned balance that protects the company resources and does not create a de facto denial-of-service attack on our own resources, rendering them, and us, less productive and valuable to the company. 7The the company security team says: We want to minimize [risk], not eliminate valuable services. Where sendmail and X11 are needed, they can be run, but extra attention should be paid to the configuration of the hosts and servers that run them. A security package is strongly encouraged, even required, on hosts that run sendmail. Good security tools monitor, check permissions and control accress rights to machines. Again, see this.

I. X-Windows Guidelines

Make sure security is enabled. Type xhost with no other parameters from your current session. You should see the following:

access control enabled, only authorized clients can connect
loopback
XXXXXXXX.ims.yourcompany.com, Where XXXXXXXX is your system name.

Start the server with the -T option, to prevent killing the window with the CTRL-ALT-BKSP sequence.
Use an authentication method.

II. Sendmail Guidelines

Make sure you are using the latest version.
Make sure you always install the latest manufacturer's patches quickly.
Use TCP Wrappers to control access.
Run sendmail behind smap, part of the firewall toolkit.
Read about vulnerabilities here.
You may also want to follow CERT advisories.
Set the privacy options to goaway. (Slow link sometimes, but worth it!)
Do not allow mail to files or programs.
Do not allow debug, kill, or wiz commands.
Restrict expand and verify options. (Must send HELO first; must be reverse authenticated.)
Make sure only root can access or modify alias and database files.
When possible, consider not using the daemon to listen for incoming mail if all you do is send.
Consider the feasibility of receiving mail on one centrally-managed server and telnetting in to get your mail. That way, only one server has to be managed, instead of multiple workstations.
8A bit of behavior that you may want to guard against is the use of your machine, both by "crackers" and by (perhaps) your own scruple-impared users, to exchange warez, or pirated software. Do not give the world a place to store and exchange files unless uploads are necessary. Consider using an ftp password (instead of anonymous ftp) if you do have this need, and monitor this area carefully and daily. Look for new directories, especially ones containing "special" characters. A popular directory name, leading to an unauthorized tree is ... which is easy to miss.
It is best to restrict ftp by:

Run in a chrooted environment with limited privileges.
Make a copy of ls and put it in the restricted path.
Use a limited password file, not a copy of your "real" password file.
Establish a quota, where appropriate.
Clean your upload tree regularly via a cron job, maybe even daily.
Log access and read your logs.
9By default, your files will be created -rw-------, which will give read and write permission to the owner, and no permissions to group or other. It's easy to change permissions, and that will force you to make a decision about why you are allowing other people access to your files, instead if giving it to them by default.
10The default ACLs on your home directory for ims:staff and system:anyuser should be NONE. This will prevent unauthorized users from listing your directory and "cruising" for information they are not authorized to have. Remember: it's easy to set up project groups that will allow you to add rights for specific sets of users. In general, ACLs are more secure and robust than tradtional unix file permissions.
11Your home directory is the start of the personal file space allocated to you for your work. You and the system administrator can write here. Nobody else should be able to place or copy files here, nor erase existing files. If others (including your group) need to do this, create a single directory or tree devoted to a specific purpose.
12The /etc directory traditionally contains system configuration files, and the binaries for most administrative commands. This directory also contains a (binary) log file called utmp that contains data about currently logged-in users. The login program makes entries that init cleans out at logout. This file needs to be world-writable, and AIX still keeps it in /etc. Nothing else in that directory should be world-writable.
13The following procedure assumes you are using AIX:

Make sure you have the following files:

/var/adm/syslog
/etc/security/failedlogin
/var/adm/sulog
/var/adm/cron/log
/var/spool/mqueue/syslog
and use touch to create them if you don't.
Edit /etc/syslog.conf to include the following lines:

mail.debug /usr/spool/mqueue/syslog
# *.crit /var/adm/syslog
# *.alert /var/adm/syslog
*.debug /var/adm/syslog # Everything ABOVE is logged
# *.info /var/adm/syslog
# *.warn /var/adm/syslog

Add this line to the end of /etc/rc.tcpip, if it's not already there:
start /etc/syslogd "$src_running"
This will ensure that logging resumes every time you restart your computer. However, if you want to enable logging immediately,

Do a ps -ef | grep syslogd as root to make sure that syslogd is not already running. If it is,

Execute refresh -s syslogd to make sure that syslog will now be writing to the correct files.
OR

execute /etc/syslogd as root.
14How do you know that a hacker has not compromised your system, and replaced the login program with a trojan horse that allows that person access? There's only one real way.

Install the operating system from factory media.
Make a backup of the initially installed system.
If you are using AIX, you can use the mksysb utility or initiate a level 0 dump. For help with commands, go here.
Then, use tripwire to ensure that critical files have not been changed.
15A guest account, that is used by a number of people, especially when the password is not changed after each user, is simply not a good idea. Shared accounts are generally a bad idea. Every ID should be tracable to a single person. This is why you should also not log in as root unless you must, if the root account is shared by administrators. If multiple administrators share root responsibilities, and they su to root from their own accounts, any problemss will be tracable to the correct user. This also holds true for guest accounts. Many systems used to come with a guest account that had, by default, an easily-guessable password. If you must have guest accounts, change the password regularly and only allow guests to operate in a chrooted environment.
16A joe is an account whose password is the same as it's userid. This is a very, very bad idea.
17Crack checks password files for a variety of weaknesses. It's a popular tool among both crackers and administrators. You should run it every month, before someone else does. You can get it here.
18Unused and expired accounts are a common source of unauthorized access. AIX will allow the administrator to set expiration dates for all accounts and passwords. If you force people to change their password regularly, accounts will, by default, expire. Basically, creating an account is like giving someone a key to your house. We suggest that you keep track of who has access to your system as closely as you keep track of your house keys.
19Accounts named ftp, telnet, www, host, user or guest are a common starting point for intrusion attempts. Some (lame) people may consider them an invitation.
20In AIX, you can change the welcome banner that is displayed before someone logs in. It's in the /etc/security/login.cfg file. The screen that displays after login is /etc/motd. Both of these files should only be writable by a system administrator.
There is a widly-distributed urban legand circulating, purporting that a cracker broke into a system, and was caught, essentially red-handed. The evidence was supposed to have been sufficient to convict him without a doubt, but (so the story goes) he was released because the initial contact banner said Welcome to XYZ.COM. This story is nothing but myth. Several well respected people have have carefully investigated this, and nobody has ever been able to produce an actual case.
That doesn't mean this can't happen. Please. Make sure that none of your banners contain

Any wording that can reasonably be considered to be an invitation, or
Any wording that can be considered to be a challange.
Please avoid phrases like Welcome to the company. I use this banner:

O----------------------------------------------------------------O O O O This machine is to be used by authorized personnel only, O O and only for management-approved purposes. O O O O----------------------------------------------------------------O O O O Management reserves the right to monitor content and activity O O at any time with no further notification. O O O O----------------------------------------------------------------O

It's a good idea to warn people that content and activity may be monitored. It still doesn't mean that you can do so without management approval, but this particular wording allows us to act when necessary, and lessens the chance of a lawsuit.
If you are the administrator of a workstation that others may log on to (a shared, non-afs workstation) you must also specifically tell users, in the banner, whether or not they may store the company Confidential files on this system. AFS administrators: You must do this on your systems also.
21What we will do is present you with a list of unacceptable password components, and the reason we discourage each one. Then, we'll suggest a password construction method that some of use.

Password must be at least 8 characters long.
The longer the password, the harder it is to break.

Your password should not equal, contain or even resemble your logon id.
Password must contain at least one "special" character.
Characters, such as / . & @ # and etc. complicate dictionary attacks.

Password mixes upper and lower case.
This discourages guessing.

Password has >=2 numeric characters <6.
A few numeric characters makes guessing harder. Too many makes it easier.

Password contains no known dictionary word in any language.
CRACK uses built-in dictionaries, and allows you to create your own, to break passwords quickly and efficiently. The closer your password is to a "real" word, the easier and faster this process is.

Password contains no proper nouns.
See crack, above.

Password contains no personal information.
Items such as your license plate, social security number, etc. make it easier to add a "social engineering" element to other strategies, if you include them as part of your password, improving the speed and efficiency of the cracking methodology.

Password should contain no simple patterns.
Patterns, such as qwerty are already part of various dictionaries, and it's easier to add more. Patterns are the bane of cryptogrophy.

Password should not be one of the above, appended, prepended or backward.
Algorithms are being improved all the time. Koobeton is, in reality, no more secure than Notebook as a password. It will be cracked almost as quickly.

Your password should be changed regularly, in accordance with your department's policy.
The maximum password age on VM is 120 days so that may be a good default maximum to consider.

There should be an alphabetic or other non-numeric character in the first and last position to make them harder to crack.
Contain no more than three consecutive characters from your previous password.
Contain no more than two identical consecutive characters.
Your password on external systems should be completely different from your the company password(s).

So, how do you create a good password? Here is one password:
DO NOT USE THIS, OR ANY OTHER PUBLISHED PASSWORD!

i2bGc3h&
This is not a word, simple pattern, or modified pattern in any language. I started with the first 8 words in Genesis, In the beginning, God created the heavens and... I built a password by using the first letters of each word. Then I substituted a 2 for the word the, left the G capitalized, substituted a 3 for the the, and substituted an ampersand for the final word, that being a common representation for the word and. This is a common way to construct a reasonably strong password that you can remember.
Here's what the Underground Guide to Computer Security has to say about choosing a password,
plus comments on other interesting access-control technology.
There are some alternate versions of passwd available that enforce rigid passwords, but we I have not been able to make one work with our AIX/AFS setup. If you have, please- humble me! :-)
AIX allows you to enforce some password restrictions. On 3.2.5 these restrictions must be implemented system-wide; on 4.1 they can be instituted on a per-user basis. The system administrator can manually edit the /etc/security/passwd file to circumvent this restriction. These characteristics are normally set in /etc/security/login.cfg. The standard password restrictions that AIX makes available are:

maxage Maximum time between password changes (password aging).

minage Minimum time between password changes.

maxexpired Disable an account with an expired password after x week(s).

pwdwarntime Warn user about an expiring password x days in advance.

minlen Passwords must be at least x characters long.

minalpha Password must contain at least x alphabetic characters.

minother Password must contain at least x alphabetic characters.

mindiff At least x characters in the new password must not be in the old password.

maxrepeats At most x characters in the new password may be in the old password.
22This information, from the SATAN FAQ, is unavailable here.

23 Trivial ftp is an old and well documented weakness. Unfortunately, X-stations rely upon it. A security official says For x stations that do not have their own storage and use tftp to load their boot information, on AIX you can configure tftp to serve only a limited number of IP addresses. You can also configure it to serve only a limited number of files.
On AIX, this is accomplished via the /etc/tftpaccess.ctl file, which should look something like this:

This is an acceptable configuration.

You should try to avoid distributing files via anonymous ftp when possible. Many departments use a single server, often on the dmz to distribute files. If you must distribute files in this manner, make sure that ftp operates in a limited, chrooted environment, and that it does not contain a copy of the real password file. For more help about securing anonymous ftp, contact me.

The tftp protocol has received a lot of bad press. Deservedly so. If you're running a tftp daemon, it can be used to transfer any file on your computer, with no authentication at all. Unless tftp is restricted. Therein lies the key. The tftp protocol is needed to run X windows and boot remote workstations.

To see if you are running tftp unprotected, try this:
tftp 127.0.0.1
tftp> get /etc/passwd tmp
You should receive a file not found error, or the machine should just hang. If not (if you DO manage to copy your passwd file into the file ./tmp) you are running a very dangerous protocol indeed! Update your version asap.

24 CGI scripting is an invaluable tool. However, you should subject all CGI scripts to code review for known weaknesses that may be exploited, before making a CGI tool available on your web server. Of course, this goes for Java, JavaScript and other "languages" as well. The difference with CGI is that a small set of example scripts comes with most web servers, and some administrators install them, by default, without checking them because they didn't write them; they came from the manufacturer and are percieved as "part of the package". One case is as well-known as it is potentially destructive. That is the "phf bug". CERT has released an advisory about it, and people with an interest in hands-on security experience have written exploits in perl and C. You should check your http tree immediately, see if this script is available, and remove it if it is. It could give unauthorized people access to files you never intended to release, including your password file.

25 SNMP is a valuable protocol for remotely managing network devices. Of course, you don't want anybody else to "manage" your devices for you, so be sure to change your SNMP community string from "public" to a unique value. The manual will tell you how to do this for individual devices. An example of the snmp daemon configuration file, with instructions, is here.

26 I'm sorry, but this propritary tool was developed internally, and is not available to the public. This link remains purely for my convenience.

27 CERT makes it's advisories available here. the company releases patches here.

28 If one machine sends ICMP redirect messages out, it can corrupt the routing tables in other machines on the network. Fortunately, this is not a default. You can learn more about the protocol here. This FAQ is very useful, though it may take a while to load. Look for What are ICMP redirects and redirect bombs?.

29 A dual-homed host is a machine with connections to more than one network. A firewall is a dual-homed host; that's an example of a good use of inter-network connectivity. An example that is usually unacceptable is a computer with both a modem and an LAN connection, if they are both active simultaneously. If you are connected to a building LAN and you use your modem to dial out, you can connect a secure network to the insecure "network cloud" which might represent a threat to internal security. This is one method of "punching a hole in the firewall", a practice that will be taken seriously because the consequences can be serious.

30 Unavailable.

31 Unavailable.

32 Unavailable.

33 When you store confidential information you should protect the information against theft and unauthorized access. Keep diskettes and tapes in a locked area or storage device when they are not in use. You should not leave them exposed in unattended areas.

Links, Tools and Resources

All links checked: January 6, 1998

A collection of security links from Henry
A list of firewall vendors
IBM has a new firewall page.
Their firewall now runs on Windows NT and AIX!
The MicroSoft Security Advisor.
Here's a whitepaper outlining a purported SSL attack.
One of the first popular security tools was COPS and it's still quite good.
You can get tripwire here.
The freeware version of the Internet Security Scanner is here.
MIT's distribution of kerberos is here, but it is NOT compatible with the version of kerberos used by our AFS cell.
Have you used satan to check your machine yet?
You can use swatch to monitor syslog.
Here's a nice page by Jeffrey Ash.
You should be using the the company version of tcp wrappers but here's the version that Wietse Venema wrote.
You can restrict users to a chrooted environment.
If you don't like COPS you can try tiger. Or use both.
If you like to roll your own, you can get this firewall toolkit, but it hasn't been updated in a couple of years.
You might want to try this non-SOCKS-ified proxy system.
The latest version of wu-ftp and it's better than both the standard daemon or the original.
You should regularly run crack against any unshadowed /etc/passwd files.
You should run sendmail behind SMAP, which is part of the firewall toolkit, referenced above.
Get the latest version of sendmail here.
If you want to know what SPAM is, and how you can fight it, look here.
Want to get your message out without spamming? Look here.
A nice SNMP reference.
Search the BugTraq archives.
A really good collection of security resources.
A firewall survey.

Virus Checkers

The IBM Anti Virus Page.
Here's the home of McAfee (Now Network) Associates.
They have a very nice reference library.
The F-Prot web site where you can get the program, virus data, and information about internet hoaxes.
The Symantec (formerly Norton Anti Virus) page.
A virus primer
You can search for information about a virus here
Is it real or a hoax? Please check here or here before spreading myths
(Spreading false virus information is against company policy and can have serious consequences.)
Please read this information about the 666 virus that targets Win95 and WinNT machines.

Case Studies

Here is a case study of a Computer Caper, from the American Society for Computer Security.
A survey of 'net security security by Dan Farmer.
I suggest you read it. You have been warned.

Paranoia?

Well, you decide. If you ignore the hyperbole, this document will give you some useful information.
Worth reading. Once.

Papers

Mail your comments and suggestions here.

	1.	Questions
	2.	Answers
	3.	Philosophy
	4.	Tools and Resources
	5.	Unix Command Help
	6.	Virus Checkers

	7.	Security Checklists
	8.	SENDMAIL The noncommercial versions of sendmail. The commercial versions of sendmail. The new sendmail features anti spam control.
	9.	Correspondence

*maxage*	Maximum time between password changes (password aging).
*minage*	Minimum time between password changes.
*maxexpired*	Disable an account with an expired password after x week(s).
*pwdwarntime*	Warn user about an expiring password x days in advance.
*minlen*	Passwords must be at least x characters long.
*minalpha*	Password must contain at least x alphabetic characters.
*minother*	Password must contain at least x alphabetic characters.
*mindiff*	At least x characters in the new password must not be in the old password.
*maxrepeats*	At most x characters in the new password may be in the old password.