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

Network Services Unless we are connected to an isolated network where every machine is secure and trusted, we must assume that all the information we send and receive across the network can be intercepted by a third party (i.e. someone other than us and the intended recipient of the data). Network Services One way a hacker may try to gain unauthorized access to our system is by exploiting weaknesses in the network services that we are running on our Red Hat Linux system. These are programs - often run in the background with no controlling terminal (called “daemons” in Unix, and “services” in Microsoft Windows) - that provide services to other computers. Examples include file transfer protocol (ftp), Web, Network File System (NFS), and print servers. Enabling and disabling services The first and easiest way of reducing our vulnerability is to disable all the services that we don’t need. In particular, we need to be very careful about older services that send sensitive information (such as user names and passwords) across the network without any form of encryption (in plain text). Also, services that gratuitously hand out information about our system should be avoided where possible. The following tables will help you to decide which services you need to run. Service TCP/UDP Port number Description Red Hat Package Security Level Run it? echo 7 Sends received characters back to sender. xinetd None. No. (Unless you really need to debug remote terminal problems) daytime 13 Sends current date and time as ASCII string back to sender. xinetd None. No. Use NTP for time synchronisation. It is more accurate and has better security features. chargen 19 Generates continuous stream of ASCII characters for testing terminals. xinetd None. No. (Unless you really need to debug remote terminal problems) chargen 20 (data) 21 (control) Random ports >1023 File Transfer Protocol. Allows transfer of files to and from remote systems. vsftp or wu-ftpd Weak. user names and passwords sent in plain text. “Anonymous FTP” allows access with no password. No. Use FTP instead. ssh 22 Secure shell. Allows remote system to Openssh Good. Data is encrypted and Only if remote access to 415
Note: If you are looking for good and quality webspace to host and run your java application check professional java hosting services

System Integrity Setting up Tripwire to Run Automatically We’ve already seen how logwatch is set up to run automatically every day at 04:02. We can very easily set up Tripwire to run at the same time. Create a two-line script called /etc/cron. daily/run-tripwire containing the following lines: #!/bin/sh /usr/sbin/tripwire –check Make sure the script is owned by root and has permissions of 500 (r-x——) so it is executable only by root. This script invokes Tripwire and gets it to check the system’s integrity according to the rules in the policy file, and using the database we just created as its baseline. When cron runs this script at 04:02 every day its output is sent to root (or whoever is configured in the MAILTO variable in /etc/crontab). Updating the Tripwire Database We’ll test the script by running it now. Type /etc/cron.daily/run-tripwire on the command line as root, and check that Tripwire runs successfully. Examine the output produced carefully, and we should see that Tripwire has spotted the addition of the run-tripwire script to /etc/cron.daily and flagged it as a critical change. To stop Tripwire from reporting this change, which we made and know is OK, as a policy violation every time it runs, we need to update Tripwire’s database. We do this by running tripwire –update, specifying a Tripwire report file that we wish to use for the update. To see what files are available, run ls-ltr/var/lib/tripwire/report; choose the last report listed as this will be the most recent one. The command to run (all on one line) is then: # tripwire –update –twrfile /var/lib/tripwire/report/rh9-20030209- 040304.twr replacing the report filename with the most recent .twr file on your system. This will produce a text file and start vi for us so we can edit the file. Each proposed database update is tagged with [x], and if we don’t want the update to be made, we simply delete the ‘x’. If we don’t want to use vi, then add –visual gedit to the command and Tripwire will start the graphical editor instead. When we exit the editor, we’re asked for the local passphrase, and then updates are applied to the database. Subsequent Tripwire integrity checks should no longer warn us about the change to /etc/cron.daily. Network Security Virtually all Red Hat Linux 9 systems will be connected to other computers via a network at some time. This may be a permanent connection through a network adapter to a LAN (Local Area Network), an “always on” connection to the Internet, or a dial-up connection to an Internet Service Provider that is active only when required. Whatever the connection, we need to make sure that a hacker cannot use it to gain access to our system, or mount a “denial of service” attack that prevents legitimate use of our computing resources. In this section, we’ll look at some of the techniques that we can use to secure our system and make life hard for the potential hacker. 414
Note: If you are looking for good and quality webspace to host and run your java application check professional java hosting services

System Integrity and contain both letters and numbers. See the Tripwire manual for more information. ——————————————— Creating key files… (When selecting a passphrase, keep in mind that good passphrases typically have upper and lower case letters, digits and punctuation marks, and are at least 8 characters in length.) Enter the site keyfile passphrase: Verify the site keyfile passphrase: Generating key (this may take several minutes)…Key generation complete. (When selecting a passphrase, keep in mind that good passphrases typically have upper and lower case letters, digits and punctuation marks, and are at least 8 characters in length.) Enter the local keyfile passphrase: Verify the local keyfile passphrase: Generating key (this may take several minutes)…Key generation complete. ———————————————– Signing configuration file… Please enter your site passphrase: Wrote configuration file: /etc/tripwire/tw.cfg A clear-text version of the Tripwire configuration file /etc/tripwire/twcfg.txt has been preserved for your inspection. It is recommended that you delete this file manually after you have examined it. ———————————————- Signing policy file… Please enter your site passphrase: Wrote policy file: /etc/tripwire/tw.pol A clear-text version of the Tripwire policy file /etc/tripwire/twpol.txt has been preserved for your inspection. This implements a minimal policy, intended only to test essential Tripwire functionality. You should edit the policy file to describe your system, and then use twadmin to generate a new signed copy of the Tripwire policy. 11. The final step in initialization is to run the command tripwire — init. We are prompted for the local passphrase, then Tripwire scans all the files listed in the configuration file and gathers baseline data against which all future scans are run. This may take several minutes, so be patient: Note It is vital that we are confident the system is in a sound state before initializing the database, otherwise there’s little point in using Tripwire. After the database is initialized, it’s a good idea to put a copy on write-once media (e.g. CD-ROM) so that it cannot be altered: # tripwire –init Please enter your local passphrase: Parsing policy file: /etc/tripwire/tw.pol Generating the database… *** Processing Unix File System *** Wrote database file: /var/lib/tripwire/rh9.twd The database was successfully generated. 413

Hint: If you are looking for very good and affordable webspace to host and run your tomcat hosting application check Sandzak.com tomcat web hosting provider

System Integrity 7. 8. 9. 10. print $line; } # Print the statistics on STDERR, so they won’t get redirected by > print STDERR “Number of additions: $Additionsn”; print STDERR “Number of removals: $Removalsn”; Create a text file containing this script and call it /usr/local/bin/cleanpol.pl, and make it executable by running the following command: Note Depending on the examples you’ve followed earlier in the book, you may need to acquire root privileges at this point. # chmod +x /usr/local/bin/cleanpol.pl Now we can use this Perl script to produce a customized Tripwire policy file: # cd /etc/tripwire # mv twpol.txt twpol.txt.orig # /usr/local/bin/cleanpol.pl twpol.txt … Number of additions: 38 Number of removals: 125 This little script saved us from making 163 manual changes to the Tripwire policy file! (The number of changes made on your system will vary depending on which packages you have installed.) You can review the changes that were made with the diff command: diff twpol.txt.orig twpol.txt Now, use gedit, or your favorite text editor, to review the contents of the updated /etc/tripwire/twpol.txt file. In particular, there may be a problem with the line defining the policy for /sbin/e2fsadm. If the cleanpol.pl script uncommented this line, then the note tune2fs? at the end of the line is treated by Tripwire as a relative path to a file, and the policy file is rejected. Simply delete this note. In other words: /sbin/e2fsadm -> $(SEC_CRIT) ; tune2fs? becomes: /sbin/e2fsadm -> $(SEC_CRIT) ; Now we have set up the Tripwire policy file, the next step is to initialize the Tripwire database. This is done by running the twinstall.sh script in /etc/tripwire: # ./twinstall.sh This script asks us to enter site and local passphrases (a term used to describe a long “password”), generates encryption keys and cryptographically secures the configuration and policy files to prevent unauthorized changes: [root@rh9 tripwire]# ./twinstall.sh ——————————————— The Tripwire site and local passphrases are used to sign a variety of files, such as the configuration, policy, and database files. Passphrases should be at least 8 characters in length 412

Hint: If you are looking for very good and affordable webspace to host and run your tomcat hosting application check Sandzak.com tomcat web hosting provider

System Integrity Tripwire to check a file or directory (optional whitespace, string beginning with /), then we should check that the file or directory exists. If not, we should comment out the line to prevent Tripwire from generating an error. Similarly, if we find a line in the policy file that looks like a commented out file (optional whitespace, #, optional whitespace, string beginning with /), then we should check if the file or directory exists. If it does, then we’ll remove the comment to reinstate the file. 6. We’ll write the script as a filter, so it reads configuration lines from STDIN and writes to STDOUT. Any lines that don’t look like either of the types of line we’re interested in are passed through unmodified. It would be nice to know how much work we’ve saved ourselves by counting up the number of lines that the script modifies. Here’s the script (hopefully your new knowledge of Perl will give you an idea of the structure that we’ve employed, even if the details are still a bit beyond you - they’ll come with practice): #! /usr/bin/perl -w # Filter for Tripwire policy file. Looks for lines that # start with optional whitespace and a filename, and # comments them out if the file does not exist. Also # looks for commented out lines containing filename and # removes comment if they do exist. $Additions = 0; $Removals = 0; # Read each line from stdin into the $line variable while ($line = ) { # Look for lines that match a pattern (the Perl # pattern matching characters are enclosed in []) # start with optional white space [ ^s* ] # then a ‘#’ [ # ] # then more optional white space [ s* ] # then a string starting with ‘/’ that doesn’t # contain white space [ /S+ ] # # The last part of the pattern is enclosed in () # so that if the pattern matches, we can access # this part through the $1 variable. # # This pattern matches a commented out entry/ if ( $line =~ /^s*#s*(/S+)/ ) { # Found commented out entry. If the file exists, # strip off the comment character. if ( -e $1 ) { $line =~ s/^s*#//; $Additions++; } # Now look for a line that’s like the above but # without the ‘#’ comment character. } elsif ( $line =~ /^s*(/S+)/ ) { # Found entry that starts with ” /”. If file # does not exist, then comment out entry. if ( ! -e $1 ) { $line = “# ” . $line; $Removals++; } } # Output the line (whether modified or not) 411
Note: If you are looking for reliable and quality webspace company to host and run your servlet application check professional servlet hosting services

System Integrity Try it Out: Downloading, Configuring, and Running Tripwire 1. 2. 3. 4. Tripwire is available in RPM format for Red Hat Linux, which makes installation very straightforward. It’s available on the Red Hat Linux 9 CD-ROMs, but as an interesting exercise, we’ll try using the rpm command’s built-in FTP and HTTP client. We’ll use the rpm command to download and install the Tripwire RPM with a single command! Open a terminal window and switch to the root user and type in the following command (all on one line): Note You’ll need to change the httpproxy IP address and httpport port number to suit your Internet connection (omit them if you don’t need to go through a proxy server to access the Internet). # rpm -iv –httpproxy 10.4.65.2 –httpport 3128 http://ftp.redhat.com/pub/redhat/linux/9/en/os/i386/RedHat/RPMS/tripwire- 2.3.1-17.i386.rpm The command also assumes that you’re running on an Intel architecture machine. If not, replace the occurrences of i386 with your machine’s architecture. After a few minutes (depending on the speed of your Internet connection), you should see the message Preparing packages for installation… followed by tripwire-2.3.1-17, and be returned to the command prompt. You can confirm that the Tripwire package was installed by running the following command: # rpm -q tripwire If all is well, you’ll get the package version information back; if not, you’ll get a message saying that package tripwire is not installed (in which case, just download the RPM in the conventional way, and try again). Now we’ve got tripwire installed, we can go on to configure its policies and complete the setup. Before diving in to the configuration, we should take time to read the README file in /usr/share/doc/tripwire-2.3.1, and the twintro and twpolicy man pages to familiarize ourselves with the required configuration tasks. These can be divided into three distinct steps: Setting up the policy file Initializing the Tripwire database Configuring Tripwire to run periodically and report system integrity violations Let’s begin with the policy file. Tripwire’s policy file defines which files and directories tripwire should monitor for changes, and what sort of changes are significant. For some files, e.g. /bin/login, any change in file contents, modification date, or ownership is suspicious, but we’d expect them to be accessed frequently. Other files, such as log files, are expected to grow in size, but not change ownership. The policy file that is installed with the RPM in /etc/tripwire/twpol. txt tells Tripwire to monitor many files that probably don’t exist on our system, so we’ll get lots of spurious error messages when we run an integrity check. What we really need to do is edit the policy file so that files and directories that don’t exist aren’t monitored, and conversely, if there are files and directories that do exist but are commented out in the policy file are reinstated. It would be tedious to do this by hand, so let’s use our new-found knowledge of Perl to write a script to do it for us. 5. The algorithm we need to employ is straightforward. If we find a line that looks like an instruction to 410
Note: If you are looking for reliable and quality webspace company to host and run your servlet application check professional servlet hosting services

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