Like anyone using Linux, the hacker often has jobs, scripts or other tasks, that they want to run periodically. You might, for example, want to schedule automatic regular file backups of your system, or maybe you want to rotate log files as we did in Chapter 11. The hacker, on the other hand, may also want to have their system run the MySQLscanner.sh script from Chapter 8 every night or while they’re at work or school. These are all examples of scheduling automatic jobs. Scheduling jobs allows you to run tasks without having to think about it, and you can schedule jobs to run when you’re otherwise not using your system so you have plenty of free resources.
The Linux admin—or the hacker for that matter—may also want to set certain scripts or services to start automatically when their system boots up. In Chapter 12, we looked at using the PostgreSQL database in association with the hacker/pentest framework Metasploit. Rather than manually starting the PostgreSQL database every time before starting Metasploit, you can have PostgreSQL—or any service or script—start automatically when the system boots up.
In this chapter, you’ll learn more about how to use the cron daemon and crontab to set up scripts to run automatically, even while the system is unattended. You’ll also learn how to set up startup scripts that automatically run whenever the system is booted, which will provide you with the necessary services that you’ll need to run during your busy day of hacking.
The cron daemon and the cron table (crontab) are the most useful tools for scheduling regular tasks. The first, crond, is a daemon that runs in the background. The cron daemon checks the cron table for which commands to run at specified times. We can alter the cron table to schedule a task or job to execute regularly on a particular day or date, at a particular time daily, or every so many weeks or months.
To schedule these tasks or jobs, enter them into the cron table file, located at /etc/crontab. The cron table has seven fields: the first five are used to schedule the time to run the task, the sixth field specifies the user, and the seventh field is used for the absolute path to the command you want to execute. If we were using the cron table to schedule a script, we could simply put the absolute path to the script in the seventh field.
Each of the five time fields represents a different element of time: the minute, hour, day of the month, month, and day of the week, in that order. Every element of time must be represented numerically, so March is represented as 3 (you cannot simply input “March”). Days of the week begin at 0, which is Sunday, and end at 7, which is also Sunday. Table 16-1 summarizes this.
Table 16-1: Time Representations for Use in the crontab
Field |
Time unit |
Representation |
1 |
Minute |
0–59 |
2 |
Hour |
0–23 |
3 |
Day of the month |
1–31 |
4 |
Month |
1–12 |
5 |
Day of the week |
0–7 |
So, if we had written a script to scan the globe for vulnerable open ports and wanted it to run every night at 2:30 AM, Monday through Friday, we could schedule it in the crontab file. We will walk through the process of how to get this information into the crontab shortly, but first let’s discuss the format we need to follow, shown in Listing 16-1.
M H DOM MON DOW USER COMMAND
30 2 * * 1-5 root /root/myscanningscript
Listing 16-1: The format for scheduling commands
The crontab file helpfully labels the columns for you. Note that the first field provides the minute (30), the second field provides the hour (2), the fifth field provides the days (1-5, or Monday through Friday), the sixth field defines the user (root), and the seventh field is the path to the script. The third and fourth fields contain asterisks (*) because we want this script to run every day Monday through Friday regardless of the day of the month or the month.
In Listing 16-1, the fifth field defines a range for the day of the week by using a dash (-) between the numbers. If you want to execute a script on multiple noncontiguous days of the week, you can separate those days with commas (,). Thus, Tuesday and Thursday would be 2,4.
To edit crontab, you can run the crontab command followed by the -e (edit) option:
kali >crontab -e
Select an editor. To change later, run 'select-editor'.
1. /bin/nano <----easiest
2. /usr/bin/mcedit
3. /usr/bin/vim.basic
4. /usr/bin/vim.gtk
5. /usr/bin/vim.tiny
Choose 1-5 [1]:
The first time you run this command, it will ask which editor you would like to use. The default is /bin/nano, the 1 option. If you choose this option, it will open directly to crontab.
Another option, and often a better one for the newcomer to Linux, is to open crontab directly in your favorite text editor, which you can do like so:
kali >leafpad /etc/crontab
I’ve used this command to open crontab in Leafpad. You can see a snippet of the file in Listing 16-2.
# /etc/crontab: system-wide crontab
# Unlike any other crontab, you don't have to run the 'crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# which no other crontabs do.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron II ( cd / && run-parts
47 6 * * 7 root test -x /usr/sbin/anacron II ( cd / && run-parts
52 6 1 * * root test -x /usr/sbin/anacron II ( cd / && run-parts
#
Listing 16-2: The crontab file in use in a text editor
Now, to set a new regularly scheduled task, you simply need to enter a new line and save the file.
Let’s view this utility first from the system administrator’s perspective. As a system administrator, you’d often want to run backups of all your files after hours, while the system is not being used and resources are readily available. (System backups tend to require system resources that are in short demand during business hours.) The ideal time might be in the middle of the night on the weekend. Rather than having to log in at 2 AM on Saturday night/Sunday morning (I’m sure you have other priorities at that time), you could schedule the backup to start automatically at that time, even though you’re not at your computer.
Note that the hour field uses a 24-hour clock rather than using AM and PM, so 1 PM is, for example, 13:00. Also, note that the days of the week (DOW) start with Sunday (0) and end with Saturday (6).
To create a job, you simply need to edit the crontab file by adding a line in the prescribed format. So, say you wanted to create a regular backup job using a user account named “backup.” You would write a script for backing up the system and save it as systembackup.sh in the /bin directory, then schedule this backup to run every Saturday night/Sunday morning at 2 AM by adding the following line to crontab:
00 2 * * 0 backup /bin/systembackup.sh
Note that the * wildcard is used to indicate “any,” and using it in place of a digit for the day of the month, month, or day of the week is read as “all” days or months. If you read across this line, it says
The cron daemon will then execute that script every Sunday morning at 2 AM, every month.
If you only wanted the backup to run on the 15th and 30th of every month, regardless of what days of the week those dates fell on, you could revise the entry in crontab to appear as follows:
00 2 15,30 * * backup /root/systembackup.sh
Note that the day of the month (DOM) field now has 15,30. This tells the system to run the script only on the 15th and 30th of every month, so around every two weeks. When you want to specify multiple days, hours, or months, you need to list them separated by a comma, as we did here.
Next, let’s assume the company requires you to be especially vigilant with its backups. It can’t afford to lose even a day of data in the event of power outage or system crash. You would then need to back up the data every weeknight by adding the following line:
00 23 * * 1-5 backup /root/systembackup.sh
This job would run at 11 PM (hour 23), every day of the month, every month, but only on Monday through Friday (days 1–5). Especially note that we designated the days Monday through Friday by providing an interval of days (1-5) separated by a dash (-). This could have also been designated as 1,2,3,4,5; either way works perfectly fine.
Now that you understand the basics of scheduling a job with the crontab command, let’s schedule the MySQLscanner.sh script, which seeks out open MySQL ports, that you built in Chapter 8. This scanner searches for systems running MySQL by looking for open port 3306.
To enter your MySQLscanner.sh to the crontab file, edit the file to provide the particulars of this job, just as we did with the system backups. We’ll schedule it to run during the day while you’re at work so it doesn’t take up resources when you’re using your home system. To do this, enter the following line in your crontab:
00 9 * * * user /usr/share/MySQLsscanner.sh
We’ve set up the job to run at 00 minutes, at the ninth hour, every day of the month (*), every month (*), every day of the week (*), and to run it as a regular user. We simply need to save this crontab file to schedule the job.
Now, let’s say you wanted to be particularly careful and only run this scanner on weekends and at 2 AM when it’s less likely that anyone is watching the network traffic. You also only want it to run in the summer, June through August. Your job would now look like this:
00 2 * 6-8 0,6 user /usr/share/MySQLsscanner.sh
You would add this to your crontab like so:
# /etc/crontab: system-wide crontab
# Unlike any other crontab, you don't have to run the 'crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# which none of the other crontabs do.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron II ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron II ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron II ( cd / && run-parts --report /etc/cron.monthly )
00 2 * 6-8 0,6 user /usr/share/MySQLsscanner.sh
Now, your MySQLscanner.sh will only run on weekends in June, July, and August at 2 AM.
The crontab file has some built-in shortcuts you can use instead of a specifying the time, day, and month every time. These include the following:
So, if you wanted the MySQL scanner to run every night at midnight, you could add the following line to the crontab file:
@midnight user /usr/share/MySQLsscanner.sh
Whenever you start your Linux system, a number of scripts are run to set up the environment for you. These are known as the rc scripts. After the kernel has initialized and loaded all its modules, the kernel starts a daemon known as init or init.d. This daemon then begins to run a number of scripts found in /etc/init.d/rc. These scripts include commands for starting many of the services necessary to run your Linux system as you expect.
Linux has multiple runlevels that indicate what services should be started at bootup. For instance, runlevel 1 is single-user mode, and services such as networking are not started in runlevel 1. The rc scripts are set to run depending on what runlevel is selected:
0 Halt the system
1 Single-user/minimal mode
2–5 Multiuser modes
6 Reboot the system
You can add services for the rc.d script to run at startup using the update-rc.d command. This command enables you to add or remove services from the rc.d script. The syntax for update-rc.d is straightforward; you simply list the command followed by the name of the script and then the action to perform, like so:
kali >update-rc.d <name of the script or service> <remove|defaults|disable|enable>
As an example of how you can use update-rc.d, let’s assume you always want the PostgreSQL database to start upon system boot so that your Metasploit framework can use it to store pentesting and hacking results. You would use update-rc.d to add a line to your rc.d script to have it up and running every time you boot your system.
Before you do that, let’s check whether PostgreSQL is running on your system already. You can do so using the ps command and piping it to a filter looking for PostgreSQL using grep, like so:
kali >ps aux | grep postgresql
root 3876 0.0 0.0 12720 964pts/1 S+ 14.24 0.00 grep postgresql
This output tells us that the only process ps found running for PostgreSQL was the very command we ran looking for it, so there is no PostgreSQL database running on this system presently.
Now, let’s update our rc.d to have PostgreSQL run automatically at bootup:
kali >update-rc.d postgresql defaults
This adds the line to the rc.d file. You need to reboot the system for the change to take place. Once you’ve done that, let’s again use the ps command with grep to look for a PostgreSQL process:
kali >ps aux | grep postgresql
postgresql 757 0.0 0.1 287636 25180 ? S March 14
0.00 /usr/lib/postgresql/9.6/bin/postgresql -D
/var/lib/postgresql/9.6/main
-c config_file=/etc/postgresql/9.6/main/postgresql.conf
root 3876 0.0 0.0 12720 964pts/1 S+ 14.24 0.00 grep postgresql
As you can see, PostgreSQL is running without you ever entering any commands manually. It automatically starts when your system boots up, ready and waiting to be used with your Metasploit!
If you’re more comfortable working from a GUI to add services at startup, you can download the rudimentary GUI-based tool rcconf from the Kali repository, like so:
kali >apt-get install rcconf
Once it has completed its installation, you can start rcconf by entering the following:
kali >rcconf
This will open a simple GUI like the one in Figure 16-1. You can then scroll through the available services, select the ones you want to start upon bootup, and click OK.
Figure 16-1: The rcconf GUI for adding services to startup
In this figure, you can see the PostgreSQL service listed second from last. Press the spacebar to select this service, press TAB to highlight <Ok>, and then press ENTER. The next time you boot Kali, PostgreSQL will start automatically.
Both system administrators and hackers often need to schedule services, scripts, and utilities to run at regular intervals. Linux enables you to schedule nearly any script or utility to run on a regular basis using the cron daemon, which runs these jobs from the cron table. In addition, you can have services start automatically at bootup by using the command update-rc.d or the GUI-based tool rcconf to update the rc.d scripts.
