Fundamentals Of Ethical Hacking Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Explain the directory and file structures of Linux OS. Also discuss the directory and File permission facilities available in LINUX.

What is meant by Linux rootkit attack? Explain any two tools that can be used to audit suspected rootkit attacks in Linux.

What is meant by hardening a Linux System? Explain the basic system hardening tasks.

2. Answers

The structure of the LINUX OS is basing it rational on the usage of each file.

It is easier to find something if you know where he is (more or less), this option also allows the sharing of parts of the code between the various dynamic libraries installed software that they are guides all pre-agreed.

In Linux there is only one categorized directory structure. All the rest of the directory starts from the root directory, and it is represented by the sign '/'. Afterwards it expands into sub-directories.

The partitions are located within the main directory (root) and when we "mounting" them to be below other known path.

The directory structure in Linux is the same structure as it is in the other directories. It is located below the root folder. No matter if the location of the system file will be mounted.

The folders and subfolders are organized in such way that they will be under the root file system

bin - These files are essential executable that using all the system users. Contains some utilities which require in the single mode user

boot - The files that are needed in order that the system will be able to boot up. Among these files, there is the core system.

dev - These are a collection of virtual files, which are being used as interface for hardware devices.

Etc - These files are the configuration files into most of the software and the system (equivalent to the windows registry)

home - These are the users' home folders/directories, which contain their files

lib - Directories necessary modules (drivers) for the core system. Contains the library files

Mnt - Docking points (mount) of foreign file systems (tree folders that are not part of Linux).

Media - Docking point for removable devices (CD, floppy, etc.)

Opt - Optional files and software (usually empty)

Proc - Virtual file system, which acts as an interface to the core system running processes

Root - User's home directory root, the directory structure begin with this file system.

Sbin - Essential executables, which are used primarily by the root user, and used in the boot process

tmp - Temporary file storage space. It can be writable by all users on the system

Usr - All programs and information that are not essential for system boot.

Var - This directory is mainly for the various system files such as, e-mail, print jobs in queue, logs, etc…

sys - this contains file that related to the system and firmware

It is very important to mention that normal users (not "root users") by default cannot change any of the files and the guides in the guides listed here, except two: Our Home Library files guide the tmp files.

Anchoring filesystems treatment

In Unix, unlike Windows - The name of each drive is in its own directory tree, there is only one directory tree, which is starting from the guide root (/).

Mapped root directory (or docked - mounted) partition a disk. Other barriers may be rooted as

Each guide is in the file system.

Docking may be used to deploy the system folders of different disks, or to access foreign file systems

(Windows, floppy, CD and even file sharing networks). Usually foreign file systems under agunot

2.1.1. Layout of the directory structure

2.1.2. The directory and File permission facilities available in LINUX

Linux is associating a file /directory with a user & a group.





















The type of the file

The user Permissions

The group Permissions

The Other Permissions

There are 3 sets of permissions in Linux file system:

The owner file

The group file

Other - meaning everyone else

The permissions that will be indicated will appear using the letters r, w or x:

The "r" letter stands for "read"

The "w" letter stands for "write"

The "x" letter stands for "execute"

***The "s" letter stands for "setuid" It can only be found in the execute field.***

If there is a dash "-" in the places where a letter should be, it means that there is no permission for the speciphic location. This may be found in any field whether read, write, or execute field.

When there is a dash "-"in the start of the result line it indicates that it's a file.

When there is a "d" at the start of the result line it indicates that it's a directory.

When there is an "l" at the start of the result line it indicates that it's a link.

I created a text file on my system under the home folder and gave it the name: "test.txt"

For checking the result we will type and execute the following:

ls -l test.txt

-rwx-rw-r- 1 asaf test 1256 March 24 18:18 test.txt

The file belong to the user who called asaf, the name of the group is test, the size of it is 1,256 bytes, the last time that the file had any modification is in March 24, 18:18, and the filename is asaf.txt.

By getting the result of dash at the beginning we can learn that it's a file

The 3 next places are telling us what are the permissions that the file has for the owner "rwx" - meaning these are what the user can do to the file, which is to read the file, writing to the file, and execute the file. If he wants, he can also change the access permissions.

The next 3 spaces with the letters "rw" indicates the permissions for the file's group "rw" meaning that the users that belong to this group will have permissions of reading and writing the file. (They will not be able to execute the file)

The next 3 spaces with the letter "r" indicates the permissions for the file's other "r" meaning that all the other users will have permissions of reading the file. (They will not be able to write or execute the file)

2.1.3. Directory permissions

There is a difference between the permission that is granted to the directories and the permission that is granted to the files. The permissions that required for directories are:

When the user is using the following command "ls" he will get to view the files that are located within the folder he will need to have a "read".

When a user wants to open the files in a folder he will only be allowed to read the files if is familiar with the file names. He will need to have "execute-only" permission.

In order for a user to make the following changes: deleting a file, creating a file or modifying any files or subfolders, even if the file or subfolder he will need to have a "write" permission.

When a user wants to cd into a directory he will need to have "execute" permission.

Changing file ownership - superuser

There is a built in feature that meant to increase the security in Linux. The feature basically set a rule that allows the make a change to the ownership of the file just if you are the superuser or you are have a root permission.

For example:

Let's say that we have a program that has the ability of changing the way of accessing the sensitive and important files that belong to the system.

In this case we will be able to make changes to the ownership of the application file to root and then after if we will start the application; we will be able to get permission to all the files that the application was modified by the application in a root level.

If we wish to modify a file or directory ownership, we need to login as root, or su to root, and then we need to run the following command:

chown <username> <filename>

If we wish to modify a file or folder ownership of test.txt to another user "asaf", we will need to run the following command:

chown asaf test.txt

If we wish to modify the group file using the identical code, we will need to type the following:

chgrp <new group> <filename>

If we wish to change the group of the file test.txt to administrator , we will need to run the following command:

chgrp admin test.txt

If we wish to compare Linux to Windows we can see a big difference in the way that partitions are viewed. In Linux we won't be able to view a device or a partition until we will mount it. But in Windows, all the different devices and partitions are detected when we boot up the computer and each device or partition will be assigned with a drive letter.

Although this way of operating does not look an easy way to get access to your devices partitions it allows the user to be very flexible with managing the files and directories.

For example:

In Linux, the /usr directory, (which contains most of the system executables) we have the option off mounting it off for a different computer (using the internet) or to a different partition on the same computer. The system won't be able to see what were the changes since the /usr will be under the local directory, it will be a part of the local directory structure.

In windows, if we will try to move the directory c:\windows\system to another partition or drive. We will face many registry and system errors.

Answer 2:

Before I will explain on the meaning of a Linux rootkit attack I would like to start with the term rootkit.


The term "rootkit" comes from combining the words: "root" and "kit".

In Linux, the meaning when using the word "root" is to a very strong, "Administrator" account. The word "kit" is with regards to few programs or utilities that have the ability to give someone access to a computer in root-level and to maintain this access.

Another meaning of a "rootkit", aside the root-level access, is that the existence, of the rootkit should not be detectable.

The term "rootkit" is linked to software that has 1 tool or few tools that provides an access to a computer continuously and it has the option to be used by a 3rd party. The software can run in the background and can be hidden from the administrators.

When the access has been granted to the computer system the 3rd party user will be able to alter files, or execute processes without the knowledge of the user.

Meaning of Linux rootkit attack

"Linux rootkit attack" meaning that an attacker managed to install rootkit software on the desired PC and after that he managed to get access into the root-level, it can be done by taking advantage of a known vulnerability or by acquire a password (can get the password by cracking the encryption or by using social engineering techniques).

After the attacker had managed to successfully install the rootkit he will be able to cover his tracks with the ongoing intrusion and to keep up with the privileged access to the pc by bypassing regular authentication and authorization processes.

Even though the rootkits can be used for difference of purposes, they got the reputation of a malware, hiding applications that fit the computer's resources or stealing passwords without the awareness of the administrators and the users. The most common targets of the rootkits are firmware, hypervisor, kernel, and user-mode applications.

It is very hard to locate installed rootkit, because the rootkit may be able to corrupt the software that is being used to find it.

There are few detection methods such as:

Using another "clean" operating system;

Behavioral-based methods

Difference scanning and memory dump analysis.

Signature scanning

We still need to bear in mind that the removal of the rootkit can be long and complicated and sometimes impossible, mainly for situations where the rootkit is part of the kernel, Format the system and to reinstall the operating system can be sometimes the only way to clean the system.

Examples of rootkit:

Fu or FuTo - Has the ability of "stealth" any process.

2. AFX Windows Rootkit 2003 - Has the ability of hiding processes and folders from the system.

3. Vanquish - Has the ability of hiding processes and folders from the system. uses a different method of concealment mechanism then the AFX.

Tools that can be used to audit suspected rootkit attacks in Linux:

As explained earlier rootkits are softwares that were programed to hide their existence from the OS and from a user. Mostly it can be done using end-runs for the common system APIs. The reason is that the attacker will be able to steal sensitive information, for example: bank account details, passwords, etc…

Finding the rootkit is not enough. Most of attackers are going free without being punished. The nature of the Internet makes it easy for hackers to cover their tracks and even if we have found them it is difficult to prove it.

There are few tools that can help us find whether a system was attacked with a rootkit attack.

Using external software that available in the market

Many of the antiviruses software have added some basic level of rootkit detection to their products. We can find few free types of software with standalone rootkit detection tools that were offer for usage long time ago.

Here are few examples for application with abilities to detect these rootkit softwares.

McAfee's Rookit Detecting tool:

This software is programmed and designed to find and to remove rootkits which are operating in a system.

It can detect files that were infected, changes in the registry and processes which might not be visible.

Sophos Anti-Rootkit

This anti rootkit tool is a free tool that can detect and remove the threat.

It uses an advanced rootkit detection technology.

Panda Anti-Rootkit

This anti rootkit tool has the ability to shows system resources that they are hidden, can identify between the familiar and the unfamiliar rootkits. IceSword

This anti rootkit tool has the ability to detect using a special process viewer, startup manager and port enumerator the changes that a rootkit can do. It offers a set of tools that might assist to detect a rootkit that operates on your system.

Operation of detecting tools:

The softwares that are we can use operates in such way that they are scanning the scan results from the system and checking if a conflict is exists or mismatching views.

One of the first ways that were used to detect these rootkit attacks is to put a full list with all the files on the volume while inside the operating system, and after that to boot up and load the recovery console. After that we put another file list so we can compare the 2 different files.

Analyzing the results:

If we have found a file in the second list but we couldn't find it in the first file (and it is not windows file that is hidden by default), so most likely it is the bad file that we were looking for.

The newest tools for detecting rootkit are using the same method but they are not requiring the user from exiting the operating system to get usable results.

We need to bar in mind that rootkits, are like viruses in the manner of that they are a moving target. An anti-rootkit program that is up to date and can protect you today might be not useful in the future because new threats are being released all the time. Many rootkit programmers are writing their programs in such way that they will avoid detection of some existing programs.


Linux allows us to capture logs from system and many different program and protocols, using these useful tool, the logs we will be able to trace back and understand what the changes that accrue were and at what time and more information that each different log is providing.

Most of the logs are kept in the /var/log directory.

More information about who has logged in to the system, we can find in the lastlog file. Which located in the /var/log/lastlog file this file tracks the last login of user accounts into the system.

Some software (such as httpd) have a directory within /var/log/ for their own log files.

There is an option to rotate the log file using dedicated software for it such as logrotate. There are also softwares that helping us to monitors all of these logs such as the logwatch software.

Here are the few examples for the more common Linux log files name and usage:

/var/log/message: In this log we will find the general messages and stuff that related to the system.

/var/log/auth.log: In this log we will find information with regards to the authentication.

/var/log/kern.log: In this log we will find information about the kernel operation.

/var/log/cron.log: In this log we will find information about Crond logs (cron job) which are execute scheduled commands in the system.

/var/log/maillog: In this log we will find information about the mail server logs

/var/log/qmail/ : In this log we will find information about the qmail log directory (there will be more files inside this directory)

/var/log/httpd/: In this log we will find information about the apache access and error logs directory

/var/log/lighttpd: In this log we will find information about the lighttpd access and error logs directory

/var/log/boot.log : In this log we will find information about the system boot log

/var/log/mysqld.log: In this log we will find information about the MySQL database server log file

/var/log/secure: In this log we will find information about the Authentication log

/var/log/utmp or /var/log/wtmp : In this log we will find information about the login records file

/var/log/yum.log: In this log we will find information about the yum log files used for the date and time information.

Tail Command

The tail command is a very friendly and useful command that allows the user to follow the running output of a log file. For example: if we wish to follow my /var/log/secure log and to watch for security issues we will type the command tail -f /var/log/secure. The f switch tells tail to follow. If we won't add the f switch tail it will just list down the outputs all at once (as if we just issued less /var/log/secure.)

There is a lot of information that we can get from reading log files. At the moment that you will know about the different logs that Linux is offering and what is the usage of each log we will realize that the Linux OS makes the reading of the logs files easy.

Answer 3

As we are all commonly aware, security is negatively correlated with convenience. This relationship is one that can easily be explained by the fact that for the convenience of ase of use of a system by the end user, the less secure it is going to be. System security is always a very fine and delicate balance between convenience and perks on the one hand versus security and removal of unnecessary risks.

Linux is a feature-rich although unfortunately extremely insecure operating system. While this offers very much convenience in the sense that the system can start executing files almost all at once and Web-based tools work immediately, it also leaves the system vulnerable to numerous security threats. This is precisely why there lies the imperative need to secure the Linux system through modifying the system to make it highly secure, a process also more commonly known as hardening.

Before we embark on the list of mutiple tasks that need to be performed for hardening a system, the following two points have to be considered in depth. Firstly, before the system is even implemented on the network, hardening activities must be completed as any system that is attached to a network before the hardening activities are completed could already have been modified before, thus already compromising on the security. Secondly, successful hardening means the system should be open only as to what is required to function adequately and on that same note, users should only be allowed the minimal amount of access as required. With these two principles laid out, we can then proceed next to the basic system hardening tasks.

System hardening can be easily reviewed through the following set of activities, listed in their respective systematic order:

1. Initial planning and preparation or essentially what needs to be done before commencing

2. Securing the hardware or essentially controlling physical access to the hardware system and its parts

3. Installation or essentially installing Linux and system software and all security patches

4. Securing services and daemons or essentially ensuring the daemons' settings reduce and eradicate where possible security risks

5. Securing local file systems or essentially determining permissions and removal of anything insecure

6. Controlling root access or essentially restricting root access to the system console and a select pool of administrators

7. Configuring user authentication or essentially specifying how users must identify upon log in

8. Setting up access remotely or essentially specifying user identification from remote systems as well as other network-based access control

9. Installation of continual monitoring of systems to detect any unauthorized changes to the system

With the lists of tasks all laid out, we can now proceed to cover the scope of work required in each of these elements in more detail.

Initial planning and preparation

Firstly, determine how the system's disks are partitioned, and locations of the various file systems as these systems provide organic security perimeters that you can utilize to your advantage. Where required, operating system files can be placed on separate file systems, away from user files. Secondly, determine what software will be running on the system and also note the software dependencies. Thirdly, structure the system's user account and group structure for instances where access needs to be granted to a select group of users to a particular resource.

Then, acquire all software required to install and configure the system, including all new security patches and updates that can easily be obtained online, preferably from official Linus resources or official independent resources if you are savvy enough to identify between an official and unofficial source.

Be ready to document the entire hardening process, so that you can trace back systematically if something does not go as you plan, and also so the other administrators of the system comprehend the configuration of the system.

Securing the hardware

Many people tend to overlook securing the physical system when it comes to securing online systems. This is crucial as important and sensitive systems should not be placed in publicly accessible places where access can be easily compromised.

Ideally, place the physical system in an area which can be locked, where there is minimal risks of accidental damage and if possible, with an uninterruptible power supply.

Thereafter, to prevent intruders from altering the BIOS setting of your computer, ensure you assign a BIOS password.


Install the basic operating system configuration, the minimal with as little as possible to boot the system as anything extraneous only provides more holes for security lapses. Then, install all security patches acquired. Once done, backup the source code before removing it from the system.

The next step is to build for the system, a custom kernel which disables any features that are not needed. Some areas to look into include features under code maturity level options, general setup, binary emulations of other systems, block devices, networking options, network device support, IrDA (infrared) support, file systems - network file systems and kernel hacking. After, backup the kernel source code directory before removing it from the system.

Finally, configure the settings for the system boot process, disallowing any boot time user intervention.

Securing services and daemons

Securing system services involve the following lists: removing or disabling unnecessary services; determining access and logging in for all services, giving room for only the minimum access requirements, running services with chroot within a restricted directory; creating a special user to run server processes; using only secure versions of daemons where possible to obtain; restricting facility and service access to administrators of the system; limiting the number of daemon processes; and securing all services, regardless of how minor they seem.

Securing local file systems

To secure the local file system, an audit has to be conducted and a number of settings changed to provide only the required minimal system access. Similarly, in order to take advantage of all security elements furnished by the system, mount options that do so should be chosen. Finally, if you have very sensitive data, it is always best to encrypt it with a long, strong password.

Controlling root access

To ensure only authorized access to the root account, consider the following: allow only direct root logins from the system console thus disallowing the same from all locations; choose and set a secure root password and perhaps even come up with a scheme for changing the password from time to time, restricting the group of people who are savvy to the root password to just a handful of main administrators, restrict the use of the su command to solely this same group with the Pluggable Authentication Modules (PAM) system, and allow ordinary users controlled privileges with the use extraneous software. Configuring user authentication

Configuring user authentication and user accounts is the next logical step to configuring root access. Determine user account controls such as password decay settings, expiration of account, resource limitation, limitations to host and/or terminal. Where possible, set up defaults before adding any user accounts.

You will also need to implement initialization files for default users with the correct definitions for the PATH environment variable. System-wide login initialization files also need to be put in place.

Additionally, examine the password file for all accounts, to ensure they have a disabled password and /bin/false or another non-login shell and remove all unnecessary accounts. Then, amend the settings of all other security features that may be utilized for user accounts.

Setting up remote access

Disable hosts.equiv and .rhosts-based password-less authentication, as well as rlogin, rsh, telnet, ftp, rcp, and similar insecure remote access commands. Ensure users use ssh for access from remote locations and the related facilities for copying of files.

If remote access is allowed, it is imperative to configure PAM adequately for the relevant commands. Most importantly, ensure that root access from remote locations is disallowed.

Installation of continual monitoring of systems

Before the hardening process is finished, a scheme must be established to allow for continual monitoring including examining the data that monitoring collects.

A couple of considerable tasks include installing Tripwire facility, installing and enabling process accounting in the Linux acct package and configuring the syslog facility by determining the severity level and/or end location of each message facility.

Now that the hardening process is almost complete, the last things that remains include performing a full system backup, removing source codes and compilers, and signing up for a couple of security-related subscriber lists so you keep yourself updated of the latest security news or security patch release.

There will be service providers in the market who will tell you that there is no one set of actions, procedures, or settings, you can make that will secure your system, in an attempt to sell you their customized solutions. But by putting the above steps in place, you can at least be reassured with the fact that you have the basic security systems in place for first-level intruders. Similarly, certainly not all of us can afford the highest-end security system for our precious homes but we can at least ensure we keep our doors locked and valuable items in a safe in the very least.