At any given time, a Linux system typically has hundreds, or sometimes even thousands, of processes running simultaneously. A process is simply a program that’s running and using resources. It includes a terminal, web server, any running commands, any databases, the GUI interface, and much more. Any good Linux administrator—and particularly a hacker—needs to understand how to manage their processes to optimize their systems. For example, once a hacker takes control of a target system, they might want to find and stop a certain process, like an antivirus application or firewall. To do so, the hacker would first need to know how to find the process. The hacker might also want to set a scanning script to run periodically to find vulnerable systems, so we’ll also look at how to schedule such a script.
In this chapter, you’ll learn to manage those processes. First, you’ll learn to view and find processes and how to discover which processes are using the most resources. Then, you’ll learn to manage processes by running them in the background, prioritizing them, and killing them if necessary (no blood involved). Finally, you’ll learn to schedule processes to run on specified days and dates and at specific times.
In most cases, the first step in managing processes is to view what processes are running on your system. The primary tool for viewing processes—and one of the Linux administrator’s best friends—is the ps command. Run it in your command line to see what processes are active:
kali >ps
PID TTY TIME CMD
39659 pts/0 00:00:01 bash
39665 pts/0 00:00:00 ps
The Linux kernel, the inner core of the operating system that controls nearly everything, assigns a unique process ID (PID) to each process sequentially, as the processes are created. When working with these processes in Linux, you often need to specify their PIDs, so it is far more important to note the PID of the process than the name of the process.
Alone, the ps command doesn’t really provide you with much information. Running the ps command without any options lists the processes started (said to be invoked) by the currently logged-in user (in our case, root) and what processes are running on that terminal. Here, it simply says that the bash shell is open and running and that we ran the ps command. We want and need far more information than that, particularly on those processes run by other users and by the system in the background. Without this information, we know very little of what is actually taking place on our system.
Running the ps command with the options aux will show all processes running on the system for all users, as shown in Listing 6-1. Note that you don’t prefix these options with a dash (-) and that everything is in lowercase; because Linux is case-sensitive, using uppercase options woud give you significantly different results.
kali >ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
Root 1 0.0 0.4 202540 6396 ? Ss Apr24 0:46 /sbin/init
Root 2 0.0 0.0 0 0 ? S Apr24 0:00 [kthreadd]
Root 3 0.0 0.0 0 0 ? S Apr24 0:26 [ksoftirqd/0]
--snip--
root 39706 0.0 0.2 36096 3204 pts/0 R+ 15:05 0:00 ps aux
Listing 6-1: Using the aux options to see processes for all users
As you can see, this command now lists so many processes, they likely run off the bottom of your screen. The first process is init, listed in the final column, and the last process is the command we ran to display, ps aux. Many of the details (PID, %CPU, TIME, COMMAND, and so on) may be different on your system but should have the same format. For our purposes, here are the most important columns in this output:
USER The user who invoked the process
PID The process ID
%CPU The percent of CPU this process is using
%MEM The percent of memory this process is using
COMMAND The name of the command that started the process
In general, to perform any action on a process, we must specify its PID. Let’s see how to use this identifier to our advantage.
When we inquire about or perform an action on processes, we usually don’t want all of the processes displayed on the screen. It’s simply a problem of too much information. Most often, we want to find information on a single process. To do so, we can use the filtering command grep, which I introduced in Chapter 1.
To demonstrate, we’ll use the Metasploit exploitation framework, the most widely used exploitation framework and nearly every hacker’s good friend. This comes installed on your Kali system, so start Metasploit with the following:
kali >msfconsole
Once the exploitation framework has been started, let’s see whether we can find it in the list of processes. To do so, use the ps aux command and then pipe it (|) to grep looking for the string msfconsole, as in Listing 6-2.
kali >ps aux | grep msfconsole
root 39756 0.0 0.0 4304 716 pts/2 Ss+ 15:13 0:00 sh -c service
postgresql start && msfdb init & msfconsole
root 39759 35.1 15.2 4304 227888 pts/2 Sl+ 15:13 1:36 ruby /usr/bin/
msfconsole
root 39892 0.0 0.0 4304 940 pts/2 S+ 15:18 0:00 grep msfconsole
Listing 6-2: Filtering a ps search to find a particular process
From the filtered output in this listing, you should see all the processes that match the term msfconsole. The PostgreSQL database, which is the database Metasploit uses, is shown first, then the msfconsole program itself from /usr/bin/msfconsole. Finally, you should see the grep command you used to look for msfconsole. Notice that the output did not include the column header list from ps. Since the keyword, msfconsole, is not in the header, it is not displayed. Even so, the results are displayed in the same format.
From this, you can learn some important information. If, for example, you need to know how many resources Metasploit is using, you can consult the third column (the CPU column), to see that it’s using 35.1 percent of your CPU, and consult the fourth column to see that it’s using 15.2 percent of your system memory. That’s quite a bit. It’s a demanding beast!
When you enter the ps command, the processes are displayed in the order they were started, and since the kernel assigns PIDs in the order they have started, what you see are processes ordered by PID number.
In many cases, we want to know which processes are using the most resources. This is where the top command comes in handy because it displays the processes ordered by resources used, starting with the largest. Unlike the ps command, which gives us a one-time snapshot of the processes, top refreshes the list dynamically—by default, every 10 seconds. You can watch and monitor those resource-hungry processes, as shown in Listing 6-3.
kali >top
top - 15:31:17 up 2 days, ^;50, 4 users, load average: 0.00, 0.04, 0.09
Tasks: 176 total, 1 running, 175 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.3 us, 0.7 sy, ).) ni, 97.4 id, 0.0 wa, 0.0 hi 0.0 si 0.0
KiB Mem : 1491220 total, 64848 free, 488272 used, 938100 buff/cache
KiB Swap : 1046524 total, 1044356 free, 2168 used. 784476 avail MEM
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
39759 root 20 0 893180 247232 11488 S 0.7 16.6 1:47.88 ruby
39859 root 20 0 27308 16796 14272 S 0.3 1.2 1:47.88 postgres
39933 root 20 0 293936 61500 29108 S 0.7 4.1 1:47.88 Xorg
--snip--
Listing 6-3: Finding the greediest processes with top
System administrators often keep top running in a terminal to monitor use of process resources. As a hacker, you may want to do the same, especially if you have multiple tasks running on your system. While you have top running, pressing the H or ? key will bring up a list of interactive commands, and pressing Q will quit top. You’ll use top again soon to manage your processes in “Changing Process Priority with nice” on page 65 and “Killing Processes” on page 66.
Hackers often need to multiprocess, and an operating system like Kali is ideal for this. The hacker may have a port scanner running while running a vulnerability scanner and an exploit simultaneously. This requires that the hacker manage these processes efficiently to best use system resources and complete the task. In this section, I'll show you how to manage multiple processes.
You don’t often hear the word nice used in the context of hackers, but here you will. The nice command is used to influence the priority of a process to the kernel. As you saw when we ran the ps command, numerous processes run on the system at once, and all of them are contending for the available resources. The kernel will have final say over the priority of a process, but you can use nice to suggest that a process should be elevated in priority.
The idea behind the use of the term nice is that, when you use it, you’re determining how “nice” you’ll be to other users: if your process is using most of the system resources, you aren’t being very nice.
The values for nice range from –20 to +19, with zero being the default value (see Figure 6-1). A high nice value translates to a low priority, and a low nice value translates to a high priority (when you’re not being so nice to other users and processes). When a process is started, it inherits the nice value of its parent process. The owner of the process can lower the priority of the process but cannot increase its priority. Of course, the superuser or root user can arbitrarily set the nice value to whatever they please.
Figure 6-1: Niceness priority values
When you start a process, you can set the priority level with the nice command and then alter the priority after the process has started running with the renice command. The syntax for these two commands is slightly different and can be confusing. The nice command requires that you increment the nice value, whereas the renice command wants an absolute value for niceness. Let’s look at an example to demonstrate this.
For demonstration purposes, let’s assume we have a process named slowprocess that’s located at /bin/slowprocess. If we wanted it to speed up its completion, we could start the process with the nice command:
kali >nice -n -10 /bin/slowprocess
This command would increment the nice value by -10, increasing its priority and allocating it more resources.
On the other hand, if we want to be nice to our fellow users and processes and give slowprocess a lower priority, we could increment its nice value positively by 10:
kali >nice -n 10 /bin/slowprocess
Give this a try on a process you have currently running and then run ps to see how it changes, if at all.
The renice command takes absolute values between –20 and 19 and sets the priority to that particular level, rather than increasing or decreasing from the level at which it started. In addition, renice requires the PID of the process you are targeting rather than the name. So, if slowprocess is using an inordinate amount of resources on your system and you want to give it a lower priority, thus allowing other processes a higher priority and more resources, you could renice the slowprocess (which has a PID of 6996) and give it a much higher nice value, like so:
kali >renice 20 6996
As with nice, only the root user can renice a process to a negative value to give it higher priority, but any user can be nice and reduce priority with renice.
You can also use the top utility to change the nice value. With the top utility running, simply press the R key and then supply the PID and the nice value. Listing 6-4 shows the top utility running. When I press the R key and supply the PID and nice value, I get the following output:
Listing 6-4: Changing a nice value when top is in use
When I press the R key, I’m asked for the PID ➊ with the text renice PID [value] to value. The output should then change to reflect the new priorities.
At times, a process will consume way too many system resources, exhibit unusual behavior, or—at worst—freeze. A process that exhibits this type of behavior is often referred to as a zombie process. For you, probably the most problematic symptom will be wasted resources used by the zombie that could be better allocated to useful processes.
When you identify a problematic process, you may want to stop it with the kill command. There are many different ways to kill a program, and each has its own kill number.
The kill command has 64 different kill signals, and each does something slightly different. Here, we focus on a few you will likely find most useful. The syntax for the kill command is kill-signal PID, where the signal switch is optional. If you don’t provide a signal flag, it defaults to SIGTERM. Table 6-1 lists the common kill signals
Table 6-1: Commonly Used Kill Signals
Signal name |
Number for option |
Description |
SIGHUP |
1 |
This is known as the Hangup (HUP) signal. It stops the designated process and restarts it with the same PID. |
SIGINT |
2 |
This is the Interrupt (INT) signal. It is a weak kill signal that isn’t guaranteed to work, but it works in most cases. |
SIGQUIT |
3 |
This is known as the core dump. It terminates the process and saves the process information in memory, and then it saves this information in the current working directory to a file named core. (The reasons for doing this are beyond the scope of this book.) |
SIGTERM |
15 |
This is the Termination (TERM) signal. It is the kill command’s default kill signal. |
SIGKILL |
9 |
This is the absolute kill signal. It forces the process to stop by sending the process’s resources to a special device, /dev/null. |
Using the top command, you can identify which processes are using too many resources; often, those processes will be legitimate, but there may be malicious processes taking resources that you’ll want to kill.
If you just want to restart a process with the HUP signal, enter the -1 option with kill, like so:
kali >kill -1 6996
In the case of a zombie or a malicious process, you likely want to send the kill -9 signal, the absolute kill signal, to the process. This makes certain that the process is terminated.
kali >kill -9 6996
If you don’t know a process’s PID, you can use the killall command to kill the process. This command takes the name of the process, instead of the PID, as an argument.
For example, you could terminate a hypothetical zombieprocess like this:
kali >killall -9 zombieprocess
Finally, you can also terminate a process in the top command. Simply press the K key and then enter the PID of the offending process.
In Linux, whether you’re working from the command line or the GUI, you’re working within a shell. All commands that run are executed from within that shell, even if they run from the graphical interface. When you execute a command, the shell waits until the command is completed before offering another command prompt.
At times, you may want a process to run in the background, rather than having to wait for it to complete in that terminal. For instance, say we want to work on a script in a text editor and so have called our text editor (leafpad) by entering the following:
kali >leafpad newscript
In this case, the bash shell will open the leafpad text editor to create newscript. While we work in the text editor, the terminal is occupied with running the text editor. If we return to the terminal, we should see that it is running our text editor and that we have no new prompt to allow us to enter more commands.
We could, of course, open another terminal to run more commands, but a better option to save resources and screen real estate is to start the text editor running in the background. Running a process in the background simply means that it will continue to run without needing the terminal. In this way, the terminal is freed up for other duties.
To start the text editor in the background, just append an ampersand (&) to the end of the command, like so:
kali >leafpad newscript &
Now, when the text editor opens, the terminal returns a new command prompt so we can enter other commands on our system while also editing our newscript. This is effective for any process that may run for a significant length of time when you want use the terminal. As a hacker, you’ll find this useful for running multiple terminals with multiple tasks, to save resources and screen space.
If you want to move a process running in the background to the foreground, you can use the fg (foreground) command. The fg command requires the PID of the process you want to return to the foreground, as shown next.
kali >fg 1234
If you don’t know the PID, you can use the ps command to find it.
Both Linux system administrators and hackers often need to schedule processes to run at a particular time of day. A system administrator might want to schedule a system backup to run every Saturday night at 2 AM, for example. A hacker might want to set a script to run to perform reconnaissance on a regular basis, finding open ports or vulnerabilities. In Linux, you can accomplish this in at least two ways: with at and crond.
The at command is a daemon—a background process—useful for scheduling a job to run once at some point in the future. The crond is more suited for scheduling tasks to occur every day, week, or month, and we’ll cover this in detail in Chapter 16.
We use the at daemon to schedule the execution of a command or set of commands in the future. The syntax is simply the at command followed by the time to execute the process. The time argument can be provided in various formats. Table 6-2 contains the most common at time formats.
Table 6-2: Time Formats Accepted by the at Command
Time format |
Meaning |
at 7:20pm |
Scheduled to run at 7:20 PM on the current day |
at 7:20pm June 25 |
Scheduled to run at 7:20 PM on June 25 |
at noon |
Scheduled to run at noon on the current day |
at noon June 25 |
Scheduled to run at noon on June 25 |
at tomorrow |
Scheduled to run tomorrow |
at now + 20 minutes |
Scheduled to run in 20 minutes from the current time |
at now + 10 hours |
Scheduled to run in 10 hours from the current time |
at now + 5 days |
Scheduled to run in five days from the current date |
at now + 3 weeks |
Scheduled to run in three weeks from the current date |
at 7:20pm 06/25/2019 |
Scheduled to run at 7:20 PM on June 25, 2019 |
When you enter the at daemon with the specified time, at goes into interactive mode and you are greeted with an at> prompt. Here is where you enter the command you want executed at the specified time:
kali >at 7:20am
at >/root/myscanningscript
This code snippet will schedule myscanningscript to execute today at 7:20 AM.
Managing processes in Linux is a key skill for every Linux user and hacker. You must be able to view, find, kill, prioritize, and schedule processes to manage your Linux instance optimally. A hacker often will need to find processes on the target they want to kill, such as the antivirus software or a firewall. They will also need to manage multiple processes in an attack and prioritize them.
