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 _______________________________________________ vox-tech mailing list [EMAIL PROTECTED] http://lists.lugod.org/mailman/listinfo/vox-tech
