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

System Integrity The numbers specify when cron should run the command described by the rest of the line. There are five fields which are, from left to right, minute, hour, day of month, month, and day of week. Where an asterisk is used, this means “I don’t care”. So the four scheduled jobs in the default Red Hat Linux 9 crontab are run at the following times: Scheduled Time Interpretation 01 * * * * 01 minutes past each hour 02 4 * * * 04:02 every day 22 4 * * 0 04:22 every Sunday (1=Monday, 2=Tuesday, etc., Sunday=0 or 7) 42 4 1 * * 04:42 on the 1st day of every month The jobs are essentially similar; run the run-parts script as root and pass the name of a directory (e.g. /etc/cron. hourly for the job run at 1 minute past each hour). The run-parts script simply runs every executable file it finds in the directory that it is given (except files ending in the characters ~ or ,, and a few other exceptions). If we look in the /etc/cron. daily directory, we’ll see a file called 00-logwatch, which is a symbolic link to the logwatch command. All this means that, at 04:02 every day, the root user will be mailed a message containing summaries of important information entered into various log files in /var/log the previous day. This is all set up for us when Red Hat Linux is installed, but now we know how it works, we can adjust the configuration to suit. If, for example, we’d like more information in the messages, we can simply edit /etc/log.d/logwatch.conf and change the Detail = Low line to Detail = High. Maybe we’d like the message to be sent at a different time, say 00:15. Easy -just delete the file 00-logwatch from /etc/cron.daily (so the 04:02 daily cron job no longer runs) and add the following line to /etc/crontab: 15 00 * * * root /usr/sbin/logwatch It’s as simple as that. System Integrity Once a hacker has gained access to a system, they will often want to install modified versions of system files to ensure their continued access and to gather more information that will help them achieve their objectives. If our security analysis has identified this threat as one we need to consider, we need to have some means of identifying when our system may have been compromised in this way, so we can take remedial action (restore the compromised file from a trusted backup). But if we’re checking the system for modified files, we’ll not only identify files modified by intruders, we’ll also identify files that may have been inadvertently modified by authorized individuals, or that have become corrupt due to hardware problems (e.g. bad blocks appearing on disk drives). Enter tripwire… Tripwire Tripwire is an Open Source system integrity checker that is available for Red Hat Linux. It is a useful weapon in the system administrator’s armory, so this section will take you through obtaining it and setting it up. Note that when Tripwire scans the system to detect changes, it’s doing a lot of work and will hit the processor(s) and file I/O hard. 409
Hint: If you are looking for high quality webhost to host and run your jsp application check Vision web hosting jsp services

Monitoring Security # The ‘Service’ option expects either the name of a filter # (in /etc/log.d/scripts/services/*) or ‘All’. # The default service(s) to report on. This should be left as All for # most people. Service = All # If you only cared about FTP messages, you could use these 2 lines # instead of the above: #Service = ftpd-messages # Processes ftpd messages in /var/log/messages #Service = ftpd-xferlog # Processes ftpd messages in /var/log/xferlog # Maybe you only wanted reports on PAM messages, then you would use: #Service = pam_pwdb # PAM_pwdb messages - usually quite a bit #Service = pam # General PAM messages… usually not many # You can also choose to use the ‘LogFile’ option. This will cause # logwatch to only analyze that one logfile.. for example: #LogFile = messages # will process /var/log/messages. This will run all the filters that # process that logfile. This option is probably not too useful to # most people. Setting ‘Service’ to ‘All’ above analyizes all LogFiles # anyways… As we read through the file, we see that most of the lines are comments (since they start with the # sign, and that’s a widely used way of introducing comments in most script and configuration files). So, out of all those lines, the only entries that are in effect are: LogDir = /var/log MailTo = root Print = No Range = yesterday Detail = Low These are highlighted in bold in the example. If we consult the man page for logwatch (run the command man logwatch), we can see that logwatch will check the log files in /var/log, looking for entries from the previous day, and e-mail a report containing a low level of detail to root. If we’ve run our system for a few days and checked root mail, we’ll have seen messages from logwatch, so how is this happening? Scheduling of unattended jobs on Red Hat Linux 9, and most other Unix flavors, is handled by the cron daemon. This daemon looks for files containing information about what to run and when to run it in the directories /var/spool/cron and /etc/cron.d, and in the file /etc/crontab. On Red Hat Linux 9, the /etc/crontab file is the one that is configured by default. If we examine the contents of this file, we see that there are a few lines of environment information, and some other lines starting with numbers: SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # run-parts 01 * * * * root run-parts /etc/cron.hourly 02 4 * * * root run-parts /etc/cron.daily 22 4 * * 0 root run-parts /etc/cron.weekly 42 4 1 * * root run-parts /etc/cron.monthly 408
Hint: If you are looking for high quality webhost to host and run your jsp application check Vision web hosting jsp services

Monitoring Security here is the default contents (it’s seems quite long, doesn’t it?): ######################################################## # This was written and is maintained by: # Kirk Bauer # # Please send all comments, suggestions, bug reports, # etc, to kirk@kaybee.org. # ######################################################## # NOTE: # All these options are the defaults if you run logwatch with no # command-line arguments. You can override all of these on the # command-line. # You can put comments anywhere you want to. They are effective for the # rest of the line. # this is in the format of = . Whitespace at the beginning # and end of the lines is removed. Whitespace before and after the = sign # is removed. Everything is case *insensitive*. # Yes = True = On = 1 # No = False = Off = 0 # Default Log Directory # All log-files are assumed to be given relative to this directory. # This should be /var/log on just about all systems… LogDir = /var/log # Default person to mail reports to. Can be a local account or a # complete email address. MailTo = root # If set to ‘Yes’, the report will be sent to stdout instead of being # mailed to above person. Print = No # if set, the results will be saved in instead of mailed # or displayed. #Save = /tmp/logwatch # Use archives? If set to ‘Yes’, the archives of logfiles # (i.e. /var/log/messages.1 or /var/log/messages.1.gz) will # be searched in addition to the /var/log/messages file. # This usually will not do much if your range is set to just # ‘Yesterday’ or ‘Today’… it is probably best used with # Archives = Yes # Range = All # The default time range for the report… # The current choices are All, Today, Yesterday Range = yesterday # The default detail level for the report. # This can either be Low, Med, High or a number. # Low = 0 # Med = 5 # High = 10 Detail = Low 407
Note: If you are looking for good and quality webspace to host and run your java application check professional java hosting services

Monitoring Security Monitoring Security There are several ways of monitoring the security of your Red Hat system, allowing you to spot security breaches and other potential problems. System Logs /var/log The Red Hat Linux system maintains several log files that record system activity. Most of the interesting ones reside in /var/log. Here’s a table describing the most important log files: File in /var/log Contents View with btmp Record of all bad logins attempts. Updated by login program if it exists. lastb command cron Messages sent to syslogd from the cron daemon (which schedules jobs on Unix systems). Normal text viewing tools dmesg Kernel messages (from boot) Normal text viewing tools lastlog Last login times for all users. lastlog command messages Messages sent to syslogd with level of info or higher, except those from mail, cron or authentication related messages. Normal text viewing tools secure Messages sent to syslogd from authpriv (i.e. authentication and security messages that should only be visible to privileged users). Normal text viewing tools wtmp Record of all logins and logouts. last command Important Note that several of these files are maintained by the kernel logging daemon syslogd. The behavior of this daemon is controlled by the configuration file /etc/syslog.conf, and we can customize it if we don’t like the defaults (which are pretty good). For more information on configuring syslog, check its man page. Important The files /var/log/btmp and /var/log/wtmp are updated only if they exist (i.e. the programs that update these files won’t create them for you). The default Red Hat Linux 9 installation has /var/log/wtmp, so all logins and logouts are logged, but not /var/log/btmp. A diligent system administrator will regularly review the contents of these log files, either using tools such as gedit, if the file is a plain text file, or the appropriate command such as last or lastlog if the file contains formatted data. However, regularly trawling through log files for the occasional message of significance is very tedious. Fortunately, there’s an automated tool called logwatch that takes away much of the tedium. Even better for us, Red Hat include a sensible default setup so it’s up and running out of the box. logwatch Logwatch is a tool for searching through log files for interesting messages and summarizing them elsewhere. We will look at the default configuration provided with Red Hat Linux 9. The configuration files for logwatch are in /etc/log.d. The main configuration file is called logwatch.conf, and 406
Note: If you are looking for good and quality webspace to host and run your java application check professional java hosting services

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