Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

What is the check mode of Linux scheduled tasks?

2025-01-15 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

Share

Shulou(Shulou.com)06/02 Report--

This article mainly introduces "what is the checking mode of Linux scheduled tasks". In daily operation, I believe that many people have doubts about the checking methods of Linux scheduled tasks. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "what is the checking mode of Linux scheduled tasks?" Next, please follow the editor to study!

# # Crontab

Most people have used Crontab:crontab-e /-l, so I won't introduce it here and I won't dwell on how to use it.

For a complete list of crontab, it's best to start with the scheduled task files saved by crontab.

# Crontab related files

The files related to Crontab are under / etc and / var/spool/cron/ respectively:

/ etc/

/ etc/cron.hourly/0anacron: anacron will talk about it below.

/ etc/cron.d/0hourly: comes with it, which actually uses run-parts to execute the script under / etc/cron.hourly

. (there may be other users who put scheduled tasks below)

/ etc/cron.allow: equivalent to whitelist, restrict class configuration. Users who are not in this category cannot use crontab.

/ etc/cron.deny: it is equivalent to a blacklist and restricts class configuration, where users cannot use crontab

/ etc/crontab: system-level scheduled task configuration, which can be understood as a scheduled task that everyone uses together, and the ownership is the system rather than a specific user.

The configuration under the / etc/cron.d/: folder is the same as / etc/crontab. If you have a scheduled task that you don't want to write directly to / etc/crontab, you can choose to create a new file and put it in / etc/cron.d/ (no other configuration is needed, it takes effect directly).

/ etc/cron.hourly/: is executed by / etc/cron.d/0hourly. Inside are executable files or shell scripts.

/ etc/cron.daily, / etc/cron.weekly, / etc/cron.monthly: seems to have something to do with crontab? It's actually anacron's! I'll talk about it next.

/ var/spool/cron/: holds the crontab of each user, and ownership is specific to the user (note the comparison with / etc/crontab). This is the file we created / edited when using crontab-e, so the file name is the user name, and it is executed with the permission of the file name (that is, the user name). For example, if you create a file called Tr0y below, you will perform the scheduled tasks in this file as Tr0y. It is important to note that if you forcibly create a file with a user name that does not exist in this directory, such as test, but you do not have that user, the scheduled tasks in test will not be performed. Another thing to note is that / var/spool/cron/ is owned by root, so there is no way for ordinary users to create files directly below, only by adding sudo or through crontab-e.

... (crontab of each user)

Note that / etc/cron.allow has a higher priority than / etc/cron.deny, so you only need to choose one configuration to limit it. Generally speaking, the users of the system are relatively reliable, so the default is / etc/cron.deny, and the content is empty, so that everyone can use crontab. If neither of these restriction files exists, then only root can use crontab.

Finally, it is important to note that cron does not recursive folders, so it is useless for you to create folders under / etc/cron.d/ and / var/spool/cron/ and put configuration files in them. Why mention this in particular? Because I've seen attackers do this before.

# Defense recommendations

1. Use / etc/cron.allow to specify who can use crontab (it's best not to use blacklisted / etc/cron.deny). It should be noted that this file must be owned by root.

two。 When checking crontab, check: / etc/crontab, / etc/cron.d/*, / var/spool/cron/*, respectively.

3. Check if there are anacron scheduled tasks other than / etc/cron.hourly/0anacron (mentioned below)

# # Anacron

People may use Anacron less, so they will talk more.

The biggest difference from Crontab is that it performs scheduled tasks that are left behind. For example, suppose you set a Crontab scheduled task to be executed at 6 o'clock every Saturday night. But there was a power outage from 5: 00 to 7: 00 on Saturday night, so this scheduled task was equivalent to this round of non-execution. But if you are using Anacron, it will check and perform scheduled tasks that have not been performed. In fact, Anacron is executed by crond (Crontab Service) once an hour, and then Anacron checks whether the relevant scheduled task has been executed, and if there is any work that has not been executed, the scheduled task is executed.

Anacron is really just a program, unlike Crontab, which is executed using crond services. As mentioned earlier in Crontab, there is a set of scheduled tasks that are executed every hour: / etc/cron.d/0hourly, and this scheduled task is actually executed with run-parts to execute the script under / etc/cron.hourly, which comes with a 0anacron, which is actually the Anacron mentioned in this section. So Anacron actually relies on Crontab to execute on a regular basis. 0anacron is as follows:

#! / bin/sh# Check whether 0anacron was run today alreadyif test-r / var/spool/anacron/cron.daily; then day=cat / var/spool/anacron/cron.dailyfiif [date +% Y%m%d = "$day"]; then exit 0transf #-this is the logic I mentioned to detect whether a scheduled task has been executed-- # Do not run jobs when on battery powerif test-x / usr/bin/on_ac_power Then / usr/bin/on_ac_power > / dev/null 2 > & 1 if test $?-eq 1; then exit 0 fifi/usr/sbin/anacron-s

# so this script actually executes anacron-s.

You may wonder why the name should be preceded by a 0. According to the Internet, scheduled tasks starting with 0 will be executed first, which prevents Anacron from mistakenly thinking that Crontab is not executed after some Crontab scheduled tasks have been executed, resulting in repeated execution of some scheduled tasks. It is also for this purpose that the command is preceded by nice to give it priority to get cpu for execution.

# related files of Anacron

/ etc/anacrontab: similar to / etc/crontab, comes with it, and executes / etc/cron.daily, / etc/cron.weekly, / etc/cron.monthly through run-parts.

/ var/spool/anacron/: records the execution time of the above, and the content is the year, month and day.

/ var/spool/anacron/cron.daily

/ var/spool/anacron/cron.monthly

/ var/spool/anacron/cron.weekly

Anacrontab can specify the location of / etc/anacrontab with the-t parameter. The default is / etc/anacrontab.

Briefly explain the content of / etc/anacrontab:

Random delay time before SHELL=/bin/shPATH=/sbin:/bin:/usr/sbin:/usr/binMAILTO=rootRANDOM_DELAY=45 # execution (minutes) Distract the pressure on the server) START_HOURS_RANGE=3-22 # the time period during which commands are allowed to be executed (here it is 3: 00-22:00) 1 5 cron.daily nice run-parts / etc/cron.daily# 1: how often (days) # 5: fixed delay time (minutes) # cron.daily: scheduled task name, set at will Mainly look at log (/ var/log/cron may be useful) # nice run-parts / etc/cron.daily: the core of scheduled tasks-commands to be executed

It's similar to / etc/cron.d/0hourly, and the logic of adding 0 before the name is the same.

Take cron.daily as an example, compare with the above configuration, and summarize the running process of Anacron:

Crond reads / etc/crontab, / var/spool/cron/*, / etc/cron.d/*, are executed according to the set time

When you execute to / etc/cron.d/0hourly, execute all executables under / etc/cron.hourly/, including 0anacron

0anacron executes anacron

Anacron read / etc/anacrontab, which specifies that the cron.daily execution interval is 1 day

Retrieve the time when the last anacron was executed from / var/spool/anacron/cron.daily

Compare the current time with the time obtained in the previous step, if the difference is more than 1 day (including 1 day), then prepare to execute the specified scheduled task.

According to the setting of / etc/anacrontab, there should be a delay of 5 minutes + n minutes before execution (n is a random number not exceeding 45)

After the delay reaches the point, start executing the specified command, that is, nice run-parts / etc/cron.daily

The execution is complete.

Finally, anacrontab can only be configured with root permissions.

# Defense recommendations

The execution of anacrontab is relatively Buddhist, and the fastest execution is once a day (unless-f is added to force each round of checks), so malware usually does not want to use this for persistence. But it's hard to say, who made it more hidden than crontab?

Check if there are any scheduled tasks under / etc/anacrontab that are suspected of malice.

Check whether / etc/cron.hourly/0anacron customizes the location of the anacrontab scheduled task file with-t, and check the custom file if any.

# # at

At relies on atd service execution, which is a bit like crontab, but now it seems that atd is not enabled by default, so you may need to systemctl start atd it. The biggest difference between it and the first two is that the at is one-time and will only be run once after it is set.

# related files of at

/ etc/at.allow: equivalent to whitelist, restrict class configuration. Users who are not in this category cannot use at.

/ etc/at.deny: it is equivalent to a blacklist and restricts class configuration, where users cannot use at

/ var/spool/at/: saves the folder for timing tasks. Below, use the file name of a specific format to store the details of the scheduled task, including commands, environment variables, path when setting the scheduled task, and so on.

/ var/spool/at/spool: it is said to be the folder where the output is saved. As for what the output is and when it will be output here, it is unknown.

Example: a000030196c020. No information has been found on the format of this file name for the time being, but after my tests, the format should be: a (fixed) + 00011 (+ 1 for each task) + minutes from 1970-01-01 08:00:00 to the execution time of the task (8 digits, the number of digits is not enough to fill 0 in the front) (note that the calculations are all in hexadecimal)

The above two restriction files, crontab, are similar, but allow has a higher priority than deny. If neither of these two restriction files exist, then only root can use at.

Of course, you can also create new timing tasks without at, just create a new file under / var/spool/at/, note that the permission must have x, and must be root to create this, as for the file name, must follow the above rules can be identified. For example, if we want to create a scheduled task that will be executed at 08:00:00 on 2030-01-01. First calculate the time difference:

In [27]: import datetimeIn [28]: delta = datetime.datetime.strptime ('2030-01-01-01 08 Y-%m-%d% H:%M:%S ")-datetime.datetime.strptime (' 1970-01-01 0...: 8 Y-%m-%d% H:%M:%S") In [29]: hex (delta.days * 24 * 60) # turn minute Out [29]: '0x1e187e0'

Complete to 8 digits: 01e187e0.

So the format of this scheduled task should be aqus00012 (previous task + 1) + 01e187e0 (time difference) = a0001201e187e0:

➜at atq➜ at vim a0001201e187e0 ➜at atq18 Tue Jan 1 08:00:00 2030 a root

If you are more sensitive, you will think that the 8-bit hex, will there be a millennium bug-like bug? 0xffffffff = 4294967295, 4.3 billion years, well, you can't wait.

Finally, I would like to make a few points:

If the execution of the at scheduled task is not successful, it seems to become a scheduled task starting with = (originally starting with a)

Execution time in the past scheduled tasks will not be executed

When writing at scheduled tasks directly, you should pay attention to these three lines at the beginning:

#! / bin/sh # shell# atrun uid=0 gid=0 # should indicate the permissions of the owner of the scheduled task, and who is the recipient when # mail root 0 # triggers the logic of sending email

4. There is also a batch command associated with at, which sets the at scheduled task to run only when the cpu load is less than 0.8, and the file name starts with b. In fact, the principle is the same, batch also uses at to configure scheduled tasks:

➜at echo 'echo > / dev/pts/8' | batch & & lsjob 32 at Mon Aug 3 17:35:00 2020b000200195ff5f spool

The readability of at is very good, for example, you can send yourself a birthday wish:

➜~ echo 'echo > / dev/pts/8' | at 00:00 September 7job 1 at Mon Aug 3 14:02:00 2020➜ ~ atq1 Mon Sep 7 00:00:00 2020 a root ➜~ ls / var/spool/at/a000010195fe8a spool➜ ~ cat / varSpoolAccord A000010195fe8aAccording to an atrun uid=0 gid=0# mail root 0...cd atrun uid=0 gid=0# mail root 0...cd / root | {echo' Execution directory inaccessible' > & 2 exit 1}. Echo > / dev/pts/8... At this point, the study on "what is the way to check Linux scheduled tasks" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Development

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report