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

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

Chapter 12: Security Computer security is a vast topic, and detailed coverage is beyond the scope of this book. However, we will show you that, with a little planning and a few basic tools, it is possible to secure your Red Hat Linux system against the most likely threats. It really is worth taking the time to understand the basic principles of computer security, so you can be confident that your system is not vulnerable to accidental damage or malicious attack. What Is Meant by Computer Security? In a nutshell, computer security is about the protection of computing assets against threats such as theft, accidental loss, unauthorized access by a third party, and “denial of service” (whereby legitimate users of computing assets are prevented from doing so). Computing assets include things such as: Computer hardware Information stored on a computer (personal details, financial information, customer information, intellectual property, etc.) CPU, memory, storage, and network resources Computing services (Web sites, FTP, and Print servers) The concepts involved in computer security are straightforward; we need to identify what we want to protect and the threats we want to protect them from, figure out how much effort to put into our protection schemes, and, once we’ve implemented them, regularly test the effectiveness of our protection. The details of how this is done can get very technical, and really serious security requirements (such as government, banks, airlines, and so on) need highly advanced skills and equipment to address them. However, where the security requirements are more modest, such as those for the normal home or business user, they are within reach of the competent beginner. In the following sections, we’ll show you how to enhance the security of your Red Hat Linux system. Identifying What Is Valuable The first step in planning the security of your Red Hat Linux system is to identify what you have on that system that is of value to you. You’ll probably want to include the computer hardware itself (even though Red Hat Linux will happily run on machines considered by others to be nothing more than scrap), but it’s a little less clear with the information stored on the system. To help you draw up a list, consider how much effort it would take to re-create information if it was lost, and what the impact would be if the information fell into the hands of an unauthorized person – possibly with malicious intent. Think about the confidentiality of your data. Consider also the impact of unauthorized changes to your data; if you run a business, maybe your website gets hacked and displays prices twice that of your competitors, or perhaps someone does a “search and replace” operation on your homework essay and you don’t check it before sending it in. Think about the integrity of your data. Even if your data is secure, and hasn’t been modified by unauthorized people, you, and other authorized people, still need to be able to access it. One way of guaranteeing that your company’s website won’t get 395

Hint: If you are looking for high quality and reliable webspace provider to host and run your jsp hosting application check Sandzak jsp web hosting provider

Summary Summary In this chapter we’ve looked at how to administer and manage our Linux systems using Perl. We started by introducing the basic principals of function and syntax, before swiftly moving on to more practical topics such as interacting with your system, and using Perl to facilitate in your day-to-day administration by automating common and monotonous tasks. We’ll end our coverage of Perl here, though we’ll meet it again in the coming chapters, where it is utilized to facilitate a number of our examples. 394

Hint: If you are looking for high quality and reliable webspace provider to host and run your jsp hosting application check Sandzak jsp web hosting provider

And Finally… To make this statement easier to understand, I will break it up into a simpler syntax: @keys = keys %$files; @sorted = sort { $files->{$b} <=> $files->{$a} } @keys; foreach $key (@sorted) { $list .= pack (“A15A*”, $files->{$_}, $_) . “n”; } That’s it for the application, but we are not done with Perl just yet! In the next section, we will implement a Web-based system administration application that you can use to monitor your system. But more significantly, it will illustrate how easy it is to design and develop a comprehensive application in Perl. And Finally… We’d like to give you a taste of something a little different. To begin with Perl can seem very complex – we don’t dispute that; we’ve been through it too. And you can’t really hope to understand everything from just a few pages toward the end of this book. However, Perl is really very powerful, when used correctly, and can make your administrative life a great deal easier, especially when used in conjunction with other tools and technologies. As a demonstration of this and, we feel, an appropriate ending to our Perl chapter, we’d like to touch upon a small application we’ve written and included in the code download (from www.wrox.com for this book). It’s a simple systems administration assistant, with a graphical user interface, that we hope you might find a use for when you’re working on your system. To install it you simply need to run the sysadmin-install.pl script that’s in the download. It will install a thttpd server, and the necessary code files. Once it’s up and running it looks something like this: We’ll be talking about it in more detail in Chapter 13, and there’s a blow-by-blow account of how it was put together also available for download from the website. 393
Note: If you are looking for best hosting provider to host and run your tomcat application check Astra tomcat hosting services

Application 3: What Is My System Load? scalar variables. In order to avoid this, we take a reference of the hash by using the prefix; now it is returned as one single entity. Of course, if we return a reference to a hash in this manner, we would need to de-reference it outside before we can access elements in the hash. We will discuss this process in the send_email subroutine, which we will look at next: sub send_email { my ($user, $files) = @_; my ($mail, $list, $fh); $mail = new Mail::Send; ## Creates new Mail::Send object $list = ”; ## String to hold list of files $mail->to ($user); $mail->subject (‘Disk Usage Alert’); $fh = $mail->open(); map { $list .= pack (“A15A*”, $files->{$_}, $_) . “n” } sort { $files->{$b} <=> $files->{$a} } keys %$files; ##++ ## This is a here document. It allows us to output large blocks ## of a text at once; it prints until it finds the ## ‘Message’ delimiter. ##– print $fh <close(); } Most of the code in this subroutine should be familiar to you by now; it is nearly identical to the send_email.pl application. The process_filesystem subroutine passes the username and the hash reference to this subroutine to build and send the e-mail warning message. We are making one critical assumption here, namely that the user’s e-mail address is the same as his/her home directory name. If you are adventurous, you can modify the code a bit from list_users.pl to match the home directory to the user name, and thus the e-mail address. If you look at the code carefully, you will see one very cryptic looking statement. You should read it from right to left, instead of left to right. First, we use the sort command to sort the files in descending order; compare the position of $a and $b here to the sort expression in the process_dir subroutine. We pass the resulting array to map to build a string that lists the files and sizes in a tabular format. 392
Note: If you are looking for best hosting provider to host and run your tomcat application check Astra tomcat hosting services

Application 3: What Is My System Load? program; 15 in this case. First, we create a pipe to the du command to get a list of each and every file and its associated size from the specified directory. We then iterate through this list one file at a time, ignoring all directories, with the exception of one. And that is the directory that has the same path as the user’s home directory. This signifies the end of the output, and so we exit from the loop. Looking inside the loop, we check to see if the size of the current file is greater than the minimum size, which is initially zero. And if so, we go ahead and store the file and its size in the hash. Then, immediately we determine the number of files currently stored in the hash, as we don’t want to store more than 15 files at any given point. If the number exceeds 15, we need to remove the file with the smallest size. The technique to remove this file from the hash is a simple one. We use the sort command to sort the hash by file size and store the sorted sizes in the @sorted array. Next, we reset the minimum file size to the second smallest size, so that from here on, we store only the files that are larger than this value. And then, we finally remove the smallest file from the hash using the delete command. We repeat this process for all of the files, at which point we will be left with the 15 largest files, unless, of course, there are less than 15 files in the directory. After the loop terminates, we return the list of these files, but only if the user’s total directory size is greater than the defined quota. There are a few things to note though. The first is the sort command and its syntax.sort expects to receive an array as input and returns the sorted array as output: @array = (100, 50, 25, 75); @sorted = sort { $a <=> $b }; ## @sorted = (25, 50, 75, 100); Our objective is to get the list of files in the %files hash ordered by their size, so we can remove the file with the smallest size. Unfortunately, sort cannot directly work with hashes, so we need to do things a bit differently. We can use the keys command to return an array of all the hash keys (file names): @files = keys %files; ## @files = (“/home/postgres/global”, …); Then, we pass this array to the sort command, but we need to change the logic of the sort expression to make sure that we get back an array based on the file size and not the file name. The expression within the braces determines what is sorted and how it is sorted.sort takes two values from the input at a time, internally labeled $a and $b, and compares them. In our case, $a and $b represent file names, so we use these to access their respective file sizes in the hash, which are then compared. Once sort finishes its job, it returns an array of file names sorted by their size. The next aspect we need to look at is the return command. We can use the return command to return a value or set of values back to our caller. However, the return command as seen in the subroutine is a shortcut for the following: if ($size >= $QUOTA){ return %files; ## Return reference to a hash } else { return 0; } Remember, an associative array and a regular array allow us to store multiple elements. If we were to return one of these data types from a subroutine, they would not be returned as one entity, but instead as multiple 391

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

Application 3: What Is My System Load? We have not talked about references at all in this chapter. We can use references to create complex data structures using the three basic data types that we are familiar with, namely scalars, arrays and hashes. We will look at references in more detail as we discuss this application. sub process_dir { my $dir = shift; ## Argument; from @_ or $_[0] my ($min, %files, $size, $file, @sorted); local *PIPE2; ## Localize filehandle ##++ ## Open a pipe to the /usr/bin/du command, with the -ab arguments; ## this is defined by the $DU constant. The -a switch returns sizes ## for all files, not just directories, and the -b switch returns ## the sizes in bytes — instead of the default unit blocks. ## ## Sample output: ## 140 /home/postgres/global ##– open (PIPE2, “$DU $dir |”) || die “Cannot create pipe: $!n”; $min = 0; ## Keep track of smallest file %files = (); ## Initialize hash while () { ## Read record for file ($size, $file) = /^(d+)s+(.+)s*$/; ## Get the size and file ## from du last if ($file eq $dir); ## End loop if we are finished next if (-d $file); ## Ignore if file is directory if ($size > $min) { $files{$file} = $size; ## Store each file and size ##++ ## If we have more than 15 files in the %files hash, then ## we sort the values based on the file size and delete the ## file with the smallest size. At any given time, we will ## only have that number of files in the hash. ##– if (scalar keys %files > $NO_FILES) { @sorted = sort { $files{$a} <=> $files{$b} } keys %files; $min = $files{ $sorted[1] }; delete $files{ $sorted[0] }; ## Delete smallest file } } } close (PIPE2); ## Close pipe return ($size >= $QUOTA) ? %files : 0; ## Return list only if user ## exceeded quota } This is the most complicated piece of code that we have seen to date in this chapter. Our task in this subroutine is to locate and return files from a specific user’s home directory that occupy the most disk space. The actual number of files to process is specified by the $NO_FILES constant defined at the beginning of the 390

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