Website hosting mac, affordable, php5, plesk - linux experts blog

Keeping Software Up to Date If you leave off the -quiet switch, then you’ll get some warning messages about locked accounts, and accounts where there is no valid password. We will expect several of these to show up, as accounts used for running system services such as printing and Web serving (such as lpd and apache) will normally be configured in this way to prevent anyone from logging in as those users. Important A final word of warning when using Crack, or any other password cracking program: Make sure that you are authorized to do this by the appropriate person, preferably in writing. Keeping Software Up to Date As we mentioned earlier, vulnerabilities in system software that hackers may be able to exploit to gain unauthorized access to our systems are discovered and fixed quite frequently. The Red Hat Network provides an easy way for people running Red Hat systems to be informed of important software updates and to install these updates with the minimum of hassle. Registering for Red Hat Network Note The Red Hat Network subscription demonstrated here works only for those users who have bought a Red Hat Linux boxed set. Other users will have to buy network services from Red Hat. Details can be found on their website. Before we can make use of the Red Hat Network, we need to register for it. Start the Red Hat Update Agent either by typing up2date at the command prompt, or choosing Main Menu | System Tools | Red Hat Network. You will be presented with the following Welcome screen: Simply follow the simple, step-by-step, instructions that it provides you with, and you will be able to configure your system to automatically administer the latest patches to itself, while at the same time you receive email updates of the latest security vulnerabilities that affect you. Note When choosing a user name and password, don’t use the same username or password as you do on your Red Hat Linux box! 405
Note: If you are looking for top 10 and very good webhost to host and run your jsp application check Actions jsp hosting services

Passwords 13. Next we need to make the password dictionaries that Crack will use to try and guess the passwords on our system. Do this by running . /Crack -makedict: 14. Again, make sure that this finishes with the message Crack: makedict done. Getting the Encrypted Passwords for Crack to Work On Before we can try out our newly built Crack program, we need to get it some passwords to work on. The information Crack requires is held on Red Hat Linux 9 systems in /etc/passwd and /etc/shadow, and these need merging into a single file. Fortunately, there’s a utility provided with Crack that will do just that for us. Note that we need to be root to read /etc/shadow, and since the merged file contains information useful to a potential hacker (the encrypted passwords from the shadow password file), we need to make sure that it too has restricted access. The best way to do this is to create an empty file with the correct permissions (by setting our umask), then append the sensitive data to the file. (We could create the file with default permissions and then tighten them up, but there is a theoretical chance that someone could open the file before we’ve changed the permissions.) We’ll change the ownership of the file back to the user we want to run Crack under to avoid having to do that as root. So, run the following commands to create the merged file that is suitable for Crack to work on: % su root # umask 077 # touch passwords.dat # scripts/shadmrg.sv > passwords.dat # chown user1 passwords.dat # ls -l passwords.dat # exit Running Crack All we have to do now is run the following command to start Crack guessing at the passwords our users have set to see if there are any weak ones: % ./Crack passwords.dat When you see the word Done, it doesn’t mean that Crack has finished guessing passwords. (If passwords could be guessed that quickly, we might as well not bother with them at all!) What it does mean is that Crack has started a background process running that will spend the next hours, or even days, guessing the passwords in the passwords.dat file and logging any matches that it finds. Use the following command to find the background process: % ps -ef | grep crack If we want to stop the background Crack process, the correct way to do this is to run $HOME/crack/c50a/scripts/plaster. So how do we find out how Crack is doing? Simply run the Reporter script that is in the same directory as the Crack program. To find out any passwords that have been guessed, type the following command in the command line window: % ./Reporter -quiet 404
Note: If you are looking for top 10 and very good webhost to host and run your jsp application check Actions jsp hosting services

Passwords change this. The following steps are given in the Crack 5.0a README file, so type them in at the command line prompt: % mv src/libdes src/libdes.orig % cd src/util % cp elcid.c,bsd elcid.c Note If asked to overwrite elcid.c, answer y. 9. While we’re here, there’s one other small modification to make. The Red Hat 9 shadow password file uses salts that contain characters that the shipped version of Crack interprets as invalid (since they’re not in the list of valid characters). For the purposes of this exercise, we’ll modify the routine that checks for the validity of the hashed passwords to accept these characters. The routine as shipped checks that each character in the ciphertext (hashed password) is in a list of allowed characters. We’ll switch things around so it checks that none of the characters is in a list of disallowed characters. Edit the elcid.c source file by typing gedit elcid.c. Find the function elcid_invalid (ciphertext) and make the following three changes: Change the name of the variable validchars to invalidchars. Change the value of this variable to !. Remove the ! in the line starting if ( ! strchr… to reverse the sense of the logic. When you’ve finished, it should look like this: 10. Save the changes and exit gedit. 11. Now we’re ready to compile the Crack program. This is done by invoking the Crack script with the switch -makeonly. So, change directory back to $HOME/crack/c50a and run the following command: % ./Crack -makeonly Note Note that we need to specify where to find the Crack program by giving the directory - . / means the current directory. Unlike Microsoft Windows, Linux and other Unix variants do not include the current directory on the search path unless explicitly told to do so. That’s never a good idea for the root account, as you really want to be sure the root user is running programs in the correct system locations and not others lying around that happen to have the same name. 12. When Crack is invoked with the -makeonly option, it makes the required program files. Make sure that it finishes with the message Crack: makeonly done: 403
Note: If you are looking for inexpensive but high quality provider to host and run your serlvet application check Astra servlet hosting services

Passwords 4. Now there are a few configuration changes we need to make to the Crack source code before it will build and run successfully on our Red Hat Linux system. Firstly, we need to edit the Crack script. Change to the c50a directory and open Crack in the Gnome text editor by running these commands: % cd c50a % gedit Crack 5. A text editor window will pop up. Scroll through the file to the section that says: # # now pick your compiler # 6. Red Hat Linux ships with the GNU C compiler called gcc, so the gcc 2.7.2 section is what we need to use (even though we’ve got gcc version 3.2). Place # characters at the start of the lines for vanilla unix cc to turn them into comments (a process known as commenting out the code), and remove the same characters from the corresponding lines in the “gcc 2.7.2″ section. We also need to use the stdlib crypt() routine, so remove the # from the start of the LIBS = … line. When you’ve finished, the modified Crack file should look like this: 7. Save the changes and exit gedit. 8. Red Hat Linux 9 does not use the standard DES algorithm to encrypt passwords, but uses a stronger algorithm based on MD5 (Message Digest 5). Crack is set up to use DES by default, so we need to 402
Note: If you are looking for inexpensive but high quality provider to host and run your serlvet application check Astra servlet hosting services

Passwords as we go along, rather than saving it until after we’re done. Note Crack is a 2.5MB download. If you don’t fancy downloading it, you can skip ahead to the Running Crack section, and we’ll catch up with you in a moment. Try it Out: Making a Home for the Crack Program Before we begin setting up the Crack program, we need to make a home for it. It’s best to create our own directories for programs that we build and install ourselves (as opposed to installing from RPM packages) so they don’t interfere with system installed packages. Note Crack doesn’t require root privileges to run (but we do need to be root to get at the shadow passwords to feed Crack later on), so we’ll download, configure, and build it as an ordinary, unprivileged user. 1. The first thing we’ll do is create a home for Crack. Open a terminal window (Main Menu | System Tools | Terminal) and type the following commands at the prompt: % cd % pwd % mkdir crack The cd command on its own makes the current working directory the home directory for the user running the command. This should be the current directory for a newly opened terminal session anyway, but we’ve included it here in case you’re trying this out in an existing window. The pwd command shows us the current working directory to confirm we’re where we expect to be, then the mkdir command creates a directory called crack. This is where we’re going to install the Crack program. 2. The easiest way to download the Crack program is through the Mozilla Web browser. Start the browser, then point it to ftp://ftp.cert.dfn.de/pub/tools/password/Crack/, you should be presented with a list of files in a directory. Click on the file called Crack_5.0a.tar.gz, and when a dialog box appears asking you what you want to do, select Save to disk and click OK. Browse to the crack directory you’ve just created and click OK. Note If you have trouble connecting to the FTP site listed above, you could try ftp://ftp.cerias.purdue.edu/pub/tools/unix/pwdutils/crack/ instead. 3. The next step is to unpack the downloaded file. The letters .tar.gz at the end of the file indicates that it is a TAR (Tape ARchive) format file that has been compressed with GNU Zip. (You’ll sometimes see .tgz at the end of a file to indicate the same thing.) We therefore need to uncompress and untar the file. Go back to the terminal window and type the following commands: % cd crack % tar -xzvf Crack_5.0a.tar.gz The tar command extracts the files (x switch) from a compressed tar file (z switch) called Crack_5.0a.tar.gz (-f Crack_5.0a.tar.gz) and prints the filenames as they’re extracted (v switch). Notice that the files go into directories under c50a/ and that the directories are created as required: 401
Quick Hint: If you are looking for best quality webspace to host and run your tomcat application check Vision tomcat hosting services

Passwords Now, you’re probably thinking that someone could look at the stored hashed passwords and deduce the original passwords by reversing the hash function. However, the hash functions are chosen to make this reversal practically impossible. However, that doesn’t stop someone who has access to the hashed passwords from using a program that guesses passwords to try and guess one. Early versions of Unix stored the hashed passwords with other user information in /etc/passwd. Since the user information needs to be accessible to everyone (so, for example, user names could be shown in the output of ls -l), this also made the hashed passwords available to everyone too. Modern versions of Unix, including Red Hat Linux 9 avoid this problem by keeping hashed passwords in a separate file, called the shadow password file. On Red Hat, this is /etc/shadow. Since the hashed passwords need to be accessible only to authentication programs that run with root authority, the shadow password file should be accessible only to the root user. Choosing a Strong Password Choosing a strong password is really better phrased as avoiding weak passwords. Weak passwords are ones that can be guessed, either by humans or by password cracking programs (that will quite happily try different permutations of words from password dictionaries for days on end without getting bored). So, avoid passwords that can be found in a dictionary (in any language), or variations of these (changing is to 1s, or os to 0s, or adding digits), passwords that someone who knows you may guess (name of family member or pet), or anything generated in a systematic way. Include punctuation and other symbols, and make use of the fact that Red Hat Linux 9 uses MD5 password hashes that allow passwords to be up to 15 characters long. Note However, some characters shouldn’t be included in passwords, because they can be misinterpreted as terminal control characters and cause problems when logging in. Avoid @, #, [backspace], and other control characters. For example, here are some weak passwords: Fred123 Asdfghj (simple pattern on keyboard) B10nlc (trivial modification of dictionary word) Nitsob (a pet’s name spelled backward) These would have been strong passwords until they were published in this book: Xz%!q)_2+! 3#&-Aa%yty? ap^Lj+~rZxp] However, make sure you can remember your password so you don’t have to write it down. As soon as you do that, you’re weakening it. A slip of paper under the keyboard is a dead giveaway! Checking passwords The password cracking programs that are useful to hackers are just as useful to us, as we can use them to identify weak passwords on our systems. Then we can get the offending user to change them before a hacker cracks them. One of the best known of these programs is simply called Crack. It requires a bit of work to build and install it, so we’ll go through it step-by-step here. On this occasion, we’ll explain what we’re doing 400
Quick Hint: If you are looking for best quality webspace to host and run your tomcat application check Vision tomcat hosting services

Local Security Local Security So, we’ve sorted out the physical security of our Red Hat system. We’ve enabled the BIOS password so that only those who know it can start the machine up in the first place, and we’ve taken care with the physical location so it won’t get stolen (we hope!) and the disk drives will stay nice and cool. Should we be unlucky enough to suffer a disk drive failure, we’re taking - and testing - regular backups (we discussed how to do this in the previous chapter), so we’re confident we can recover any lost information. What’s next? (Mis)using the root Account You’ll recall from the section on Threats that operator error was high on the list of potential threats. Computers have a nasty habit of doing exactly what we tell them to do, and not what we want them to do. So that this doesn’t cause us too many problems, the trick is always to work with the lowest level of authority that we need to perform a particular task. Usually, this is not the root account. Here’s a little hypothetical example to demonstrate the potential pitfalls of using the root account for everyday tasks. Don’t try this at home, as it could result in serious damage to your system! Suppose we need to maintain the contents of a directory called /home/foo/logs by deleting files that are more than 14 days old. We could write a simple script to do this: Note Remember, don’t try this at home, folks! #!/bin/bash LOGDIR=”/home/foo/logs” cd $LGODIR find . -mtime +14 -exec rm {} ; Unfortunately, we’ve made a typo in the script (the 4th line should say cd $LOGDIR); this means that when the cd command is run, its argument is blank (because the misspelled variable $LGODIR is not defined). This means that the cd command makes the current working directory our $HOME directory, not /home/foo/logs as we want. The find command then finds all the files below our $HOME directory (the current working directory) older than 14 days and deletes them. That’s a pain if we’re logged on as an ordinary user, but if we’re logged on as root, this could well delete a lot of critical configuration information. (At least root’s home directory on Red Hat Linux defaults to /root, which is a small mercy - on some other flavors of Unix, the default home directory for root is /, so running the above flawed script on one of those could well wipe out the entire operating system!) Passwords The password that we use to authenticate ourselves to the operating system when we log in is the only way we have of proving our identity, and thus keeping an intruder out. Your password is never stored on the Linux system (the operating system won’t do it). Instead, a non-reversible mathematical function called a hash is used to combine your password with a random value (called the salt), and the hashed password is stored by the system. When you try to log in, the password you type is once again hashed with the same salt and the result compared to the one stored when the password was originally set. If the values are the same, then it’s a fairly safe to assume that the password you typed is the same as the original one, and you are allowed in. 399

Hint: This post is supported by Gama web hosting php mysql provider

Hardware Failure While we’re on the subject of backups, the idea behind backing up your system is to allow you to rebuild it in case of some catastrophic event. This means that someone else can also build a copy of your system if they can get hold of your backups, so take care over the physical security of your backup media too. Hardware Failure Pay attention to the environmental conditions that your computer is working in. Computers don’t like to get hot, and excessive temperature can cause premature failure of heat sensitive components, especially hard disk drives. There are ways of preventing the failure of a disk drive from causing loss of data, and these techniques rely on keeping the information on more than one physical disk. The term Redundant Array of Independent Disks (or RAID) is widely used to describe these solutions, and the RAID level - a combination of digits and sometimes letters - indicates how the information is stored on multiple disks. RAID may be implemented in hardware (typically in the hard disk adapter) or in software. If you’re interested in RAID, have a look at the Linux-ATA-RAID HOWTO and the Software-RAID HOWTO on your system’s documentation resources, or on-line. Common RAID levels are: RAID level Data positioning 0 Data is broken up into equal size chunks (64Kbyte and 128Kbyte are common) and chunks are written to every disk in the array in turn (with four disks in the array, the 1st, 5th, 9th, …, chunks of data are written to the first disk, the 2nd, 6th and 10th to the second disk, etc.). This pattern of data placement is called “striping”, and the size of each chunk of data is called the stripe width. This gives the best performance, but worst availability, since failure of any disk will result in the loss of some data. 1 Data is copied on to pairs of disks (mirrored). Good performance and availability, but it uses twice as much disk space. 5 Data is striped across multiple disks, and protected by parity information that is also striped across the disks. Good performance for reading, but writing can be slowed by the need to update parity information. Requires extra disk capacity to store the parity information. 7 Not really RAID at all! RAID 7 is also known as JBOD (Just a Bunch Of Disks). Here the information is not configured according to RAID, and your multiple disks are simply configured as one larger logical drive. It offers no fault tolerance advantages over simply using several disks individually. 10 (or 0+1) Data is striped across multiple pairs of disks. Combines performance of RAID 0 with availability of RAID 1. Whether RAID is suitable for you depends on how valuable you consider your information to be - a decision that only you can make. Even if you do go for a hardware or software RAID solution for your Red Hat Linux system, please don’t make the mistake of thinking that you don’t need to take regular backups. Even if you set up the most extreme combination of hardware and software RAID (using software RAID to mirror data between two hardware RAID arrays, giving you effectively four copies of the data on four separate physical hard disks), the rm command can still irreversibly delete all four copies in a fraction of a second! 398

Hint: This post is supported by Gama web hosting php mysql provider

Potential Threats Hackers sometimes attempt Denial of Service attacks by sending the target system TCP/IP packets with the SYN flag set, as if they were starting up a TCP connection, but never completing the connection. The target system allocates some resources for each incoming connection, so if the hacker sends enough of these SYN packets the target system will eventually exhaust its network resources. This is sometimes called a SYN flood. If your system is compromised, a hacker may use it to launch a Denial of Service attack on some other system without your knowledge. Coordinated attacks launched against a target system from a number of compromised systems are called distributed denial of service attacks, and these have been known to cause serious problems for the target system, no matter how large they might be. Transferring Data Transferring information over a network also opens up the possibility of eavesdropping - someone other than the intended recipient may intercept the information en route. Physical Threats Theft of computer equipment can be a big problem - especially for laptop users, and certain areas may suffer from environmental problems, such as flooding, that can damage computer equipment. So, in summary our list of possible threats could look something like this: Operator error Hardware failure (particularly disk drives) Theft of equipment Unauthorized local access Unauthorized remote access Denial of service (DoS) attack Eavesdropping of network communications Environmental conditions damage Countering the Threats The list of possible threats may look a bit daunting, but each can be countered by relatively simple measures, as we’ll explain below. Hardware Physical Security of the Hardware Physical security is really just a matter of common sense. Keep computer equipment - especially portable equipment, such as laptops - secure. If the computer BIOS has the facility to configure a power-on password, use it. This at least will make it harder for someone to access your machine if it is stolen. If you are unlucky enough to have your computer stolen, then you have to rely on your backups to get back the information that you lost. You do have backups, don’t you? You have tested them, haven’t you? Better read Chapter 10! 397
Quick Hint: If you are looking for cheap and reliable provider to host and run your servlet application check Vision servlet hosting plans

Potential Threats hacked is to unplug the computers on which it runs! So, availability of your data is important too. In some environments, performance of computer systems is critical. Transaction processing systems need to meet expected response times for end users; number-crunching systems need to get their calculations done in an acceptable time; Web servers need to respond quickly to requests from Web browsers. If your system has to perform well, but is subject to - or even taking part in - a denial of service attack, then performance may be unacceptably low, so we’d better add performance to your list of things you want to protect. Your list of valuable things that you want to protect will probably include personal information, such as your e-mail address book, financial information, and any confidential information belonging to third parties that you have an obligation to protect. In determining the value of something, it is helpful to try and work out how much time and effort would be required to re-create it. If, for example, your Red Hat Linux system was badly compromised, you might need to re-install everything from trusted CD-ROMs, then validate application data as it is restored from backups. Potential Threats Now we’ve identified what we’ve got that’s valuable, the next step in planning our system security is to identify the potential threats. Despite what you may read in the press about ‘hackers’, the most common causes of data loss are operator error (”finger trouble”) and hardware failure. Nevertheless, we should still consider unauthorized access, either locally or, if the machine is connected to some sort of network (LAN or the Internet), remotely, as another potential threat. Hacking A hacker typically starts their activities by attempting to connect to your system using various TCP port numbers to try and find out where your system is vulnerable. This process is known as probing. Of course, if the hacker is somewhere out there on the Internet, they can probe your system only when you are connected, which is why people with “always on” Internet connections, such as xDSL (”broadband”), need to pay particular attention to security. A secure system will simply ignore incoming probes so the potential hacker has no indication that there is anything using the IP address they picked to probe. (Note that not all probes indicate a threat - some ISPs also probe ports on their customer’s systems.) If your system does respond to a hacker’s probes, their next step will be to identify what software is listening on the ports (for example, a Web server, FTP server, Telnet, and so on) and try to exploit any security vulnerabilities in those programs. If the hacker is successful, they will be able to gain root access to your system, and may install modified versions of standard software that will allow them back in, or to use your system to launch attacks on other systems. Since vulnerabilities in software are found and fixed on a frequent basis, it is important to check regularly for known problems with any of the software you are running and obtain updates as soon as they become available. Fortunately, Red Hat makes this extremely easy through the Red Hat Network and the up2date command. We’ll look at this later on in the chapter. Denial of Service Denial of Service attacks are designed to disrupt legitimate use of computer systems, rather than gain unauthorized access to information. These may be implemented by exploiting bugs in network services so that these services fail (for example, by sending malformed requests to a Web server, causing it to crash), or by overloading networks so that legitimate network traffic is unable to pass. 396
Quick Hint: If you are looking for cheap and reliable provider to host and run your servlet application check Vision servlet hosting plans