[vox-tech] Password Security...

[ME]

William Perdue said:
> Hello, I'm William...

Hello William. I see others have provided you with much information on
this,  so I will try not to duplicate their work.

> I've been having some trouble with my security in my server.... I am
> running Red Hat Linux 9 with the Linux SSH Client software.

This is a good start, but running of SSH is insufficient to make a system
secure. SSH is designed to provide an encrypted session between two
*trusted* machines over a hostile or insecure network.

If you ever used ssh from a machine which you did not trust (such as an
Internet cafe, a library, a university lab, a "friend's" machine or
similar systems, then you effectively trust the people who installed the
OS, any applications and all users who have ever physically touched that
machine in the past. There are method to install key-loggers in software
which grab your keystrokes from the keyboard (these are available for many
OS) and there are also hardware devices like keyboard wedges which sit
inline from the keyboard cable to the computer which may hold a few K of
keystrokes-- keeping only keystrokes which have up to, say 18 characters
with a tab or return followed by up to 18 characters and a tab or return.
Then when you press a certain combination of keystroked, the device will
"re-type" (send these stored sequences) through the keyboard interface to
the system as though they were typed by a user. In this way, they can open
a word processor and then press this key-sequence and then see all of the
text captured which looks like passwords dumped into a file. These devices
can be very small.

The next ting to do is examine the kinds of services you are running. Were
you running any services which known holes or exploits exist? Look up the
version of the service, and then check the new versions' "Changes" to see
what new bug fixes exist. Frequently, they will mark "security fixes" in
these changelogs.

When it comes to people gaining unauthorized access you can break attacks
down into various methods. I prefer to use "remote vs. non-remote" as a
key, as much of the security software out there will help one or the other
but not both.

Remote exploits/holes have to do with insecurities in services, or
insecurities in how humans try to use those services (like the ssh example
above.) In this area, social engineering, buffer overruns, stack attacks,
heap attacks, etc. For these, you can install kernel patches for
protection form such vulnerabilities and increase the level of security on
your system, but they require you to know how to configure and build a
kernel. You should also remain up-to-date on the versions of service you
run and make sure you stay up-to-date. If a service supports running
"setuid-non-root" and "chroot" then consider using these to better
insulate yourself.

Non-remote exploits/holes includes such things as "local user attacks"
when a user has a non-root account on the system. One example is use of
symlinks and predictable file name used by services running as root or
other users/groups with privs to overwrite critical files, and then having
a symlink point from the destination file to the file to be overwritten.
Then when the service is forced to write a file (say in /tmp) the symlink
redirects it, to say, /etc/passwd and destroys the password file (which
may effectively be a Denial of Service, but in many systems, when there is
an invalid /etc/password file, logging in as root will not prompt for a
password.)

There are other attacks which local users can perform on a system to
increase privs, but most require the local user have one or more of the
following:
* services running on the local machine with weaknesses like running as
root or another user/group with privs to overwrite critical files, and
risks like writing to predictable filename which are in a space that is
accessible for writing by other users,
* Applications/programs which are set with chmod to be "setuid=owner"
where the owner has more privs than normal users (You can try to eliminate
every setuid program on your machine, and it is possible to do this in
many cases, but I think you will always end up with "init" being
setuid=root)
* Various lib attacks
* Other kinds of attacks which can be performed by local users, and many
are found in various root-kits which are collections of software which can
be used to attack known local security risks.

A sub-class of attack which is considered non-remote is one of physical
access. With all OS that I know about, physical access to the actual
computer is a security risk. At the very least, a user with physical
access can provide a "Denial of Service" by unplugging it. At higher
levels, they can install hard3ware and trojans the machine. At still
higher levels, they can steal your data by removing the hard drive. With a
different path, they can "reset your root password" through rebooting and
performing other actions where they boot with a shell that has root access
through other media or by using your own boot loader against you.

Looking at these 2 groups and one subgroup, you can often finds software
or hardware or procedures which must be followed by humans to better
secure each.

> Looking through my logs, I found that a hacker got hold of my Root
> password... it was _not_ the default (it was 17 characters) .... the
> server
> sits behind my router with a local IP address
>
> My Firewall is set at a high level  and The Server config is far from the
> defaults...

Firewall means nothing if you have exposed services with security holes or
followed insecure procedures in authentication, or permitted users to have
access to the system who willingly or unwillingly provide access to others
through their account.

A common way to view security is in layers. Security is not a solid brick
which blocks attack. A rather nice book on security is "Secrets and Lies"
which is a fine read for the non-technical when security comes into play.
Another book which is more technical is written by a professor at Davis (I
think): Computer Security- Art and Science, which is also a nice read but
a bit more technical.

> My Question: could they have obtained my root password?..

As with any OS, there are often methods to steal credentials from other
users. I have tried to outline a few above, and others here have covered
other methods.

> Another thing,,, Is there an easy way I can figure out if they installed
> any software on my server, like a trapdoor that would allow access now
> that
> I have changed the password?

Others have mentions software that you can install before a breaking to
help with this, another piece of software like this is "aide"

Beyond this, you can perform a google search for various "md5checksum"
tools which allow you to run scripts which compares the files on your
system with the files from a trusted RPM to see if any are changes. These
tools are limited, since they mostly check libs and bins but do not check
conf or other files. Conf files can weaken a system by being trojaned or
by setting preferences which weaken a system (like configure of ssh to
allow root logins and setting the encryption to be very weak and force
only sshv1 support.) However, in addition to not checking the config
files, they may also skip checking files which were installed separate
from the system installer (such as root kits, and other mal-ware.)

The only way to be 100% certain if you have no auditing procedure which
notifies you (such as through to a remote logger which is made "secure"
(yes, yes, I know)) when files are altered without your permission.

Another attack can come from the actual vendor of the software you are
installing. Each piece of software could possibly be trojaned by coders or
people who gain access to the src repository or package repository. This
can  include all code from the kernel through to command-line tools,
through to "X", but these are not as common as many of the others
mentioned.

(If you find something omitted in this message, you should check the other
posts in this thread, since I tried to avoid duplication of fellow
poster's ideas.)

HTH,
-ME