1. Introduction
2. Criteria
3. Analysis
   • Risk Assessment
   • Password Integrity
   • Packet Filtering
   • Intrusion Detection
   • Physical Security
   • Personnel Security
4. Conclusions and Recommendations

Introduction

I'm running a security analysis on a web server I recently set up in my dorm room. The machine is a fairly standard system with a Pentium II processor and 128MB RAM. I've installed RedHat Linux 8.0 along with the latest version of Apache Web Server. The machine also runs an FTP daemon to facilitate remote file transfer. Currently, the machine isn't actively hosting any webpages, but the domain http://www.bravermusic.com currently points to it and the website for that domain is under construction by a third party. I figured it would be wise to run some basic security integrity checks on the machine before any private information were put on it

Criteria

I will be checking the following security aspects of the system. Although some of the tests are unnecessary for a system as rudimentary as this one, the criteria used will hopefully be flexible and useful as more demand is put on the server in the future.

1. Risk Assessment - Assessing what sort of attacks might be conducted on the system and who would be interested in compromising the system.
   
   
2. Password Integrity - Testing the ease with which user passwords on the system could be hacked.
   
   
3. Packet Firewalling/Filtering - Working to prevent DoS attacks and other malicious packets from disrupting the system.
   
   
4. Intrusion Detection - Examination of the logging services of the system and the ease with which a possible intrusion might be detected.
   
   
5. Physical Security - Assessing the security of the physical console.
   
   
6. Personnel Security - Assessing the risk posed by individuals who have legitimate access to the system and the possibility of legitimate users accidentally providing private information to intruders.

Risk Assessment

Because the system is both newly deployed and relatively un-utilized, the risk of outside attack is fairly minimal. The server currently holds no information besides what is standard with the installed components. However, there two possible and not insignificant risks are noteworthy. One, there is the risk of an intruder who may be looking for an inroad to the UNC system or a computer from which to launch DOS or similar attacks. Two, there is the risk of either casual or intentional hackers who might find a way to intrude on the system now and, in the future when there may be private or valuable information on the system, use the knowledge they've gained of the system to break back in. These two types of risks will be the primary focus of security strategies for this system.

Password Integrity

One of the primary defenses against intrusion will be the authentication process integrated into Linux. Currently there are only three user accounts that have been created plus the root account (see Personnel). I assigned the passwords for all four accounts, so I know for certain that they are between 6 and 10 characters long and contain a mixture of letters, numbers and special characters. Also, the passwords are 'shadow'ed on the server, so the password file is not readable to anyone who might be able to hack into the machine. Obviously, since I assigned the passwords, I feel confident in their integrity. Nevertheless, I'm sure pride has been the downfall of security experts far more proficient than I, so I ran John the Ripper, a password cracking program that came with our Real World Linux Security book, to ensure that my confidence was well placed. I left John the Ripper running for almost 48 hours and none of the passwords were cracked. I don't have access to a more powerful, commercial cracking utility, but, at least for now, I feel confident that the integrity of the passwords, not to mention their limited number, make the system reasonably secure against password cracking.

Firewalling/Packet Filtering

Currently, there is no dedicated firewall between the system and the outside network. For now, I am relying on RedHat's built-in firewall software, ipchains, to filter malicious packets. I've been monitoring security and system logs and have noticed, since the server was first brought online, requests from several unknown IP addresses. Since this was before a domain name was assigned to the server and the requests were not HTTP related, I decided to err on the side of caution and place those IP address on the block list for ipchains. Since doing so, there have been no further requests from those IP addresses. This may be paranoia but, at the very least, I know that ipchains is working properly. This area of security will probably develop further after content is added to the server and it's location on the Internet is more widely known. As an additional note, the system currently has the added benefit of being behind the filtering systems of the UNC network, which makes this area somewhat less critical for the time being.

Intrusion Detection

Detection of intrusion is another critical component of this system's security, particularly to guard against the risk mentioned second; someone who may break into the system now, and use the knowledge gained later when it is more valuable. To help with this area of security, I've installed Psionic's Trisentry Suite to streamline the logging functions of Redhat and Apache and to monitor possible intrusions. The Trisentry Suite is composed of three programs, PortSentry, HostSentry and LogCheck, that I experimented some with last semester while taking INLS183. So far, the programs seem to be doing a proper job of monitoring possible port intrusions and reporting important system events to the administrator account. I tried pinging a couple of ports, 21 and 80, and noted that the TriSentry Suite logged the event. I didn't want to go too crazy while on the UNC system, but I feel confident that the system is properly logging events and that intrusion attempts would be reported.

Physical Security

Currently, this is probably the least important of the six areas I've outlined for security of the system. This is partly because any information lost due to physical damage or intrusion would be easily replaceable, and, even more, there are currently no other options for physical security because I have no where to store the server besides my dorm room. Nevertheless, physical security is crucial to any security strategy and will, eventually, become a large consideration in the strategy for this particular system. The server is currently stored in my dorm room, which is locked whenever either my roommate or I are not in the room. The dorm itself is protected by security alarms and fire alarm and suppression systems. The machine is not secured nor do I lock the console when it's not in use.

Personnel Security

Finally, another critical component of any security strategy is considering the human factor. Currently, as mentioned earlier, there are only three user accounts set up on the system and the ftp server does not allow anonymous login. Only three people, including myself, log in to the system (hence three accounts). One of these individuals is a trusted friend and competent computer user. The other is the owner of the domain name and is designing the content for the site he wishes to host. I know the latter much less personally and, as such, I have limited the permissions associated with his account to his home directory. I have also moved Apache's default directory to a subdirectory of the user's home account. As such, I don't have to risk the possibility of accidental or intentional damage to the system and the user is still able to upload html files for the site. As my close friend, I have added his username to the 'webdev' group I created, which gives him access to more of the system, including some of the php and mysql functionality that I've added. Nevertheless, because he is not a Linux user, he neither needs nor desires access to more critical parts of the system. Finally, the last user account, mine, has full access to the system and I am the only person who knows the root password. Because of the limited number of people using the system, I have been able to carefully monitor both the account permissions and the amount of information shared to other users. This is probably the most effective part of the current security model, but that will inevitably change if more users need to log onto the system.

Conclusions and Recommendations

Fortunately, security on this system is not critical. There is little or no private or valuable information currently stored on the server and there is little to entice would-be hackers to attempt to compromise the system. However, since this is a system that I would like to continue to develop and, eventually, could potentially be a more worthwhile endeavor for said hackers, developing a security plan for the system early is far better than doing so late. In addition, it gives me an opportunity to practice what I'm learning in class and to see it implemented in a real-world situation. As such, the considerations that were raised while analyzing this system are as follows:

• Physical security will undoubtedly be one of the first aspects that will dramatically change when the server is more broadly utilized. Ensuring that the system is well protected will become important and, even now, it would be wise for me to get into the habit of locking the console when I'm not using it.
• It may become more efficient and secure to have a dedicated firewall after I graduate and leave UNC, especially if there are more demands made on the HTTP and FTP daemons.
• I would still like a more streamlined way of dealing with logging system and security information. Even with a system as small as this, there seems to be a great deal of information being logged constantly and part of becoming more effective in securing the system will be learning to sift out the important information from the chaff.
• Eventually, I will not be able to monitor the passwords as closely. It will be important to have a coherent password policy in place if more users are logging into the system.