What an administrator thinks of security

Section 1
Why care?
Section 2
What it means to be "secure" and why one can't.
Section 3
The Middle road.
Section 4
Other things.


There are more computers today than ever before. This is not likely to change. As a society we are increasingly dependant upon increasingly powerful machines. The tasks we set these machines range from arithmetic when we don't feel like doing it ourselves to sorting and indexing datastreams so complex we can see neither their beginning nor end.
This dependance on computers has changed our perception greatly. The idea of a 'personal computer' is incredibly new; with this perception comes a grave amount of trust in these same machines. The penny reminds, anything trusted is bound into the pursuit of profit. However, 'profit' also has changed, to some it still means "money", while to others (most notably to those who wish to break into our machines) profit means "skillz".
Anything used to acquire profit may be used to acquire profit illegitimately. And so there is infinite incentive to acquire access to other machines. Along comes the Unix operating system. It was designed by notorioulsy non-profit minded people. It has an astoundingly powerful suite of programming languages, shells, communications protocols, and user interfaces ready to run. Finally, it has an open network on which to run. This is an interesting combination.



In order to have a computer which cannot be broken into there are two things one may do. Turn it off or take it away from the network. Large companies have taken their machines off of the network by means of the firewall, which is a method of screening all packets on a network away from your personal network. The idea of a 'secure' machine is a myth; there are only machines which are too difficult or too risky to be worth taking the time to get into. A prime example of this rule in action comes from the recent defacement of www.rootshell.com. They are a group whose sole existence is to bring to light security problems (of course this means they are a haven for 'script kiddies' but that is another topic); they in theory know more about the problems associated with running a computer on a network than anyone; but they too have been owned.
What does this mean for us? As a university, our prime attribute is our freedom of information exchange; thus a firewall is perhaps undesirable. But, we can identify the leading causes of risk and minimize them.
From whom are we as a university at risk? One might jump to the conclusion that every hacker in the world is after any machine they can get to; this is not true. Take the term 'hacker' and subdivide it into two categories: the 'real hacker' and the cracker. The former knows at least C, lisp[*], and more Unix fundamentals than anyone should. With this knowledge, these people (if they so desire) may work their way into a system as an exercise and wipe the system utterly clean of their tracks; perhaps even fixing problems with it along the way. Here is some text from a "HowTo" on becoming a hacker:
Not just anyone that can crack a password file, and log into a unix machine can call themselves a hacker. Ok, you can get root access to a box! You still are not a hacker! You need to know why you are a hacker first, and then have your 'code' and 'style'. You need a purpose and a reason for hacking into any box. The true hacker knows why he is doing what he does, and is doing it for reasons like knowledge, free information, and ACCESS. The true hacker will turn one hack into access to many different systems and providers and keep this access for future learning and more FREE information.
The latter group (cracker, script kiddie, etc) comprises about 95% of the threat commonly called 'hackers.' These are people who are younger (13-21), male, and desire more than anything to be noticed. They use the fairly blatant holes in Unix and TCP/IP as means to this end. This group is easy to find; they publish many web pages showing their skillz, post to hacking news groups, and are on IRC religiously. Their comparative lack of knowledge make them dangerous. If one breaks into a system successfully, they may well not know any Unix and immediately attempt commands like "DIR" or "EXPLORER.EXE" [*].
It is against this group that most of our efforts must concentrate for the moment. However, what can we do?



Let us assume we are faced with a multiuser system on a network. The main defense against attack for these machines is not expensive, complex, nor does it require more than a second's thought: it is the password. No matter how well a system is configured, if one can guess/acquire a password to it, all is lost. This rule, simple to say and understand, is almost impossible to implement. There are astoundingly acute computer users on this campus; unfortunately most of their passwords are trivial. Any password that contains a proper noun is breakable. Any password which has an algorithmic basis is crackable (eq 1q2w3e, qwerty, and even perhaps 1z/0) because they are easy for a machine to brute force guess. One might think this leaves nothing to work with. This is not true, one may use the following characters: (dont use a colon) !@#$%^&*()-+-=\|`~/?'";,. My personal favorite is to use the first character of each word in a book. This leaves a group of characters easy to remember, yet seemingly random. So, enough about passwords.
In order to decide what one must do to have a 'secure' system (note the quotes) one needs to know what services are necessary on the machine. The /etc/services and /etc/inetd.conf list these services for you. All of the Unixes represented here (most commonly for us SunOS/Solaris, Irix, AIX, and Linux) come with all the BSD derived communication protocols rsh, rlogin, and rexec. These services are evil. They allow commands to be run on another system without authentication. If you need them, consider replacing them with their secure analog, ssh. (it is possible to replace rsh,etc with ssh and keep the conveinance of rlogin; but remember to make a somewhat more restrictive /etc/hosts[.allow/.deny/ ] file) Doing this of course places that much more pressure on your password. pop, is another hot spot of attack because it is the perfect point for brute force attack; furthermore, it transmits passwords by clear text! so that a decent sniffer can render all the time you spent securing your system useless. (Of course this is a smaller concern on a switched network.) Even the wonderful program finger is potentially a problem because an intelligent person, using it, may know more about the habits of users on a system than they themselves know. The Sun RPC services are notoriously problematic (examples include using ypbind overflows, ttdbserver, mountd). Sendmail is another grave point of attack because of its suid origin. As a general rule; anything that is not necessary is a risk and should be deleted.
All these concerns work with using outside services to gain access. Now let us look at the system itself. There are two main points of attack in the quest to gain super user access on a box: overly permissive file/directory rights and set uid executables. As a result, the /tmp directory is an ideal place to stage an attack. Other places may include /var/adm on some Sun's, /var/dt/appmanager, /usr/local/lib/, the scratch directory for Tex. As a quick checkout of where you may be vulnerable, try 'find / -perm +o+w -print'
Setuid programs pose multiple potential problems. If they were not well written, when faced with extraneous input they may break out into a shell with different rights than the originial user (like root). They may also be used to change the rights/ownership of other files to inappropriate values. (eq the ttdbserver, infod, sendmail etc). Hunt these down with 'find / -perm +s -print'.
What else is to be done? Check your logs. They live in /var/adm and/or /var/log. Change the default syslog configuration to make multiple copies of your logs so that if someone manages to wipe your logs in /var/log you may see it elsewhere.
If you find something on your system, either in your logs or running that is suspicious/definite. The best thing to do is immediately remove the system from the network and get the word out. The reason for this is that if a singe machine is affected on the network, it becomes the perfect bouncing off point to attack other machines. Things like mail which will deny many services to off campus use will no longer matter; but if the machine is not one the network all is well.



Here come some links and examples of logs etc...
A concatenation of logs with attempted imap attacks, portscans, pop attacks, telnet and rlogins.
Lots of concatenated telnet requests from some moron.
Sentry, a portscan scanner
ssh
Other cool toys
Rootshell, script kiddie land

Trey Belew
Last modified: Wed Dec 9 15:59:35 EST 1998