Linux Basics for Hackers is an indispensable guide to help you learn the basics of Linux and use them in the field of cyber security.
1835 
Process management is an important part of the Linux operating system. The ability to effectively manage processes allows for stable and efficient operation of the system. In our complete guide, we’ll cover the key aspects of process management in Linux and show you how to use various tools and commands to monitor and optimize process performance. Understanding Processes: Processes in Linux are units of work that are executed in the operating system. Understanding their nature and interactions allows them to be better managed. We will look at different types of processes, such as background processes, daemons, and interactive processes, and explore their properties and characteristics. Process Management: We will explore various tools and commands for managing processes in Linux. Using the ps command, we will be able to view active processes and their attributes. The kill command allows you to stop unwanted or suspended processes. We will also look at the top command, which provides detailed statistics of processes and their use of system resources.
Priority management: Process priorities determine which processes receive more CPU time and system resources. We’ll show you how to set and change process priorities using the nice and renice commands, allowing you to effectively manage process execution and resource allocation. Monitoring and Debugging Processes: To optimize the performance of a Linux system, it is important to be able to monitor and debug processes. We will look at tools such as strace and ltrace that help analyze the interaction of processes with system resources and libraries. We’ll also look at other tools like vmstat and iostat that help monitor system resources and performance. Final guidelines: Effective process management in Linux is an important part of system optimization and stable operation. Using our comprehensive guide, you’ll gain all the information and skills you need to effectively manage processes on your Linux system and keep it running at optimal performance. In this section, you will learn how to manage these processes. First, you’ll learn how to view and find processes, and how to discover which processes are using the most resources. You will then learn how to manage processes by running them in the background, prioritizing them and killing them when necessary (without blood). Finally, you will learn how to schedule processes to run on specific days, dates, and times.
In most cases, the first step in process management is to review your system’s startup processes. The main tool for viewing processes and one with Linux.
An admin’s best friends are the PS team. Run it at the command line to see which 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 kernel of the operating system that controls almost everything, assigns a unique process identifier (PID) to each process sequentially as the processes are created. When working with these processes in Linux, you often need to specify their PID, so it is much more important to note the PID of the process than the name of the process.
By itself, the ps command doesn’t really give you much information. Running the ps command without any parameters lists the processes started (said to be called) by the currently logged in user (root in our case) and which processes are running on that terminal. It simply says that the bash shell is open and running, and that we ran the ps command. We want and need a lot more information, especially about the processes that other users and the system are running in the background. Without this information, we know very little about what is actually going on in our system.
Running the ps command with the aux options will show all processes running on the system for all users, as shown in Listing 61. Note that you do not prefix these options with a dash (-) and that everything is in lowercase; since Linux is exceptional, using large woud parameters will give you significantly different results.
kali >psaux 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 61: Using the auxoptions to see processes for all user
As you can see, this command now lists so many processes that they probably start from the bottom of the screen. The first process is init, listed in the last column.
Process is the command we ran to display ps aux. Many details (PID, %CPU, TIME, COMMAND, etc.) may vary on your system, but should be in the same format.
For our purposes, here are the most important columns in this output:
USER: The user who called the process
PID: Process ID
%CPU: Percentage of CPU used by this process
%MEM: Percentage of memory used by this process
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 ID to your advantage.
When we query processes or perform certain actions on them, we usually don’t want all processes to be displayed on the screen. It’s just a problem of too much information. Most often, we want to find information on one process. To do this, we can use the grep filtering command that I introduced in Chapter 1.
To demonstrate, we will use the Metasploit exploit framework, the most widely used exploit framework and almost every hacker’s best friend.
This is installed on your Kali system, so run Metasploit from the following:
kali >msfconsole
After running the exploit framework, let’s see if we can find it in the process list. To do this, use the ps aux command and then pass it (|) to make grep look for msfconsole as in listing 62.
kali >psaux|grepmsfconsole 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 62: Filtering a pssearch to find a particular process
From the filtered output, you should see all processes matching the term msfconsole in this list. First the PostgreSQL database which is the Metasploit database is displayed, then the msfconsole program itself from /usr/bin/msfconsole. Finally, you should see the grep command you used to find msfconsole. Note that the output did not include the list of column headers from ps. Since the msfconsole keyword is not in the header, it is not displayed. Regardless, the results are displayed in the same format.
From this you can learn some important information. If, for example, you want to know how much resources Metasploit is using, you can refer to the third column (the CPU column) to see that it is using 35.1 percent of your CPU, and refer to the fourth column to see that it is using 15 .2 percent of your system memory. This is not much at all. This is a demanding beast!
When you type the ps command, the processes are listed in the order they were started, and because the kernel assigns PIDs in the order they started, you see the 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, as it displays processes ordered by resource usage, starting with the largest. Unlike the ps command, which gives us a one-time snapshot of processes, the top part updates the list dynamically—by default, every 10 seconds.
You can observe and control these resource-intensive processes, as shown in Listing 63.
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 63: Finding the greediest processes with top
System administrators often maintain a terminal overhead to control the process’s resource usage. As a hacker, you can do the same, especially if you have multiple tasks running on your system. While you’re working on top, pressing the H or ? will bring up a list of interactive commands, and pressing the Q key will exit from the top. You’ll soon be using top again to manage your processes in “Changing Process Priority with Nice” on page 65 and “Killing Processes” on page 66.
Hackers often need multiprocessing, and an operating system like Kali is perfect for that. A hacker can have a port scanner running while simultaneously running a vulnerability scanner and an exploit. This requires a hacker to manage these processes effectively to make the best use of system resources and complete the task. In this section, I will show you how to manage multiple processes.
You won’t often hear the word nice used in the context of hackers, but here you will. The nice command is used to affect the process priority for the kernel. As you saw when we ran the ps command, there are multiple processes running on the system at the same time, all competing for available resources. The kernel will have the final say on the priority of the process, but you can comfortably assume that the process should be raised in priority.
The idea behind using the term nice is that when you use it, you’re defining how “nice” you will be to other users: if your process is using most of the system’s resources, you’re not very nice.
Nice values range from –20 to +19, with zero as the default (see Figure 61). A high nice value means a low priority, and a low nice value means a high priority (when you don’t treat other users and processes so well). When a process is started, it inherits the nice value of its parent process. The owner of a process can lower the priority of a process, but cannot increase its priority. Of course, superuser or root can arbitrarily set a nice value to whatever they want.
When you start a process, you can set the priority level using the nice command, and then change the priority after the process has started using the renice command. The syntax of these two commands is slightly different and can be confusing. The nice command requires you to increase the nice value, while the renice command wants the absolute nice value.
Let’s look at an example to demonstrate this.
Setting the priority when starting a process
To demonstrate, let’s say we have a process named slowprocess located at /bin/slowprocess. If we wanted it to speed up its completion, we could start the process with a nice command:
kali >nice -n -10 /bin/slowprocess
This command will increase the pleasant value by -10, increasing its priority and allocating more resources.
On the other hand, if we want to be nice to our fellow users and processes and give a slow process a lower priority, we could positively increase its nice value by 10:
kali >nice -n 10 /bin/slowprocess
Try the process you’re currently running, then run ps to see how it changes, if at all.
The renice command takes absolute values from -20 to 19 and sets the priority to that level, not increasing or decreasing from the level it started with. Also, renice requires the PID of the process you are targeting, not the name. So, if a slowprocess is using an excessive amount of resources on your system and you want to give it a lower priority, thereby giving other processes a higher priority and more resources, you can restore the slow process (which has a PID of 6996) and give it a much higher nice value
Example:
Kali >renice 20 6996
As in nice, only the root user can restore a process to a negative value to give it a higher priority, but any user can be nice and deprioritize with renice.
You can also use the top utility to change the nice value. When the above utility is running, simply press the R key and then provide the PID and a nice value. Listing 64 shows the top utility in action. When I press the R key and supply the PID and a nice value, I get the following output:
When I press the R key, I am prompted for PID ➊ with the text renice PID [value] for the value. The result should then change to reflect the new priorities.
Sometimes a process consumes too many system resources, exhibits unusual behavior or, in the worst case, hangs. A process that exhibits this type of behavior is often called a zombie process. For you, probably the most problematic symptom will be wasted zombie resources that could be better allocated to useful processes.
When you identify a problematic process, you can stop it using the kill command. There are many different ways to kill a program, and each has its own kill number.
The kill team has 64 different kill signals, and each one does something a little different. Here we’ll focus on a few that you’re likely to find most useful. Syntax for
The kill command is a PID kill signal where the signal switch is optional. If no signal flag is provided, the default value is SIGTERM. Table 61 lists common kill signals
Table 61: Commonly used kill signals
With the help of the top command, you can determine which processes use too many resources; often these processes are legitimate, but there may be malicious resource-hogging processes that you want to kill.
If you just want to restart the process with a HUP signal, enter the -1 option with kill, for example:
kali >kill -1 6996
In the case of a zombie or malicious process, you will most likely want to send a kill -9 signal, an absolute kill signal, to the process. This ensures that the process is terminated.
kali >kill -9 6996
If you don’t know the PID of the process, you can use the killall command to kill the process. This command takes a process name, not a PID, as an argument.
For example, you could kill a hypothetical zombie process like this:
kali >killall -9 zombieprocess
Finally, you can also complete the process in the top command. Just 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 in a shell. All commands that are executed are executed inside this shell, even if they are executed from the GUI. When you execute a command, the shell waits for the command to complete before offering another command line.
Sometimes you may want to run a process in the background rather than waiting for it to complete in this terminal. For example, we want to work on the script in a text editor and therefore 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 the newscript. While we are working in the text editor, the terminal is busy running the text editor. If we go back to the terminal, we can see that it launches our text editor and that we don’t have a new command that allows us to enter more commands.
Of course, we could open another terminal to run more commands, but a better option to save resources and screen real estate is to run a text editor running in the background. Running a process in the background simply means that it will continue to run without needing a terminal. In this way, the terminal is freed for other duties. To run a text editor in the background, just add an ampersand (&) to the end of the command.
Example:
kali >leafpad newscript &
Now when the text editor opens, the terminal returns a new command line so we can type other commands on our system as well as edit our new script. This is effective for any process that can run for a significant amount of time when you want to 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 bring back to the foreground, as shown below.
kali >fg 1234
If you don’t know the PID, you can use the ps command to find it.
Linux sysadmins and hackers alike often need to schedule processes to run at specific times of the day. A system administrator might want to schedule a system backup every Saturday night at 2 AM. A hacker might want to set up a script to run to perform reconnaissance on a regular basis, finding open ports or vulnerabilities. On Linux, you can achieve this in at least two ways: with at and crond.
The at command is a daemon – a background process – useful for scheduling a task to run once at some point in the future. Krond is better suited for scheduling tasks that run daily, weekly, or monthly, and we’ll cover this in detail in Chapter 16.
We use the at background service to schedule the execution of a command or set of commands in the future. The syntax is simply the at command followed by the process runtime. The time argument can be provided in various formats. Table 62 contains the most common formats in time.
Table 62: Time formats accepted by the at command
When you enter the at background service with the specified time, at goes interactive and you are greeted with the at> prompt. This is where you enter the command you want to execute at the specified time:
kali >at7:20am at >/root/myscanningscript
This piece of code will schedule myscanningscript to run 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 optimally manage your Linux installation. A hacker often needs to find processes on a target they want to kill, such as antivirus software or a firewall. They will also need to manage and prioritize multiple processes in an attack.
We used materials from the book “LINUX BASICS FOR HACKERS” written by William Pollock
1835 
1139 
1143 
1095 
1036 
908 
983 
781 
867