Anacron is the cron for desktops and laptops. Anacron does not expect the system to be running 24 x 7 like a server. When you want a background job to be executed automatically on a machine that is not running 24 x 7, you should use anacron.

CentOS/RHEL 6.x has changed how the default system maintenance cronjobs are scheduled. These are the cron jobs responsible for things like rotating logs and indexing files on the filesystem. That is routine jobs that are best scheduled to run at off peak times when the server is not busy doing more important things like serving money making websites. First, a look at how the jobs are scheduled. We just follow the trail:

* Previously, in CentOS/RHEL 5.x system maintenance cronjobs were scheduled using the /etc/crontab file. This is no longer the case in CentOS 6.x. /etc/crontab is empty by default.
* Anacron is installed by default and is responsible for maintenance cron jobs. Anacron was originally created for running cron jobs on systems that aren’t switched on 24/7 i.e. desktop or workstation PCs. So why Redhat chose to include it by default in an enterprise operating system designed for servers that are always on is anyone’s guess.
* Anacron is run by crond via the 0anacron file in /etc/cron.hourly. Anacron does NOT run as it’s own daemon.
* Anacron is configured using /etc/anacrontab and executes the commands in the cron.daily/weekly/monthly directories:
* Just like how cron has /etc/crontab, anacron has /etc/anacrontab, /etc/anacrontab file has the anacron jobs mentioned in the following format.

————————————————————————————–SHELL=/bin/shPATH=/sbin:/bin:/usr/sbin:/usr/binMAILTO=root# the maximal random delay added to the base delay of the jobsRANDOM_DELAY=45# the jobs will be started during the following hours onlySTART_HOURS_RANGE=20-22#period in days delay in minutes job-identifier command1 5 cron.daily nice run-parts /etc/cron.daily7 25 cron.weekly nice run-parts /etc/cron.weekly@monthly 45 cron.monthly nice run-parts /etc/cron.monthly
————————————————————————————–

$–> Field 1 is Recurrence period: This is a numeric value that specifies the number of days.

1 – daily
7 – weekly
30 – monthly
N – This can be any numeric value. N indicates number of days
@monthly’ for a job that needs to be executed monthly.

$–> Field 2 is Delay: This indicates the delay in minutes. i.e X number of minutes anacron should wait before executing the job after the the machine starts.

$–> Field 3 is Job identifier: It is the name for the job’s timestamp file. It should be unique for each job. This will be available as a file under the /var/spool/anacron directory. This file will contain a single line that indicates the last time when this job was executed.

$–> Field 4 is command: Command or shell script that needs to be executed.

START_HOURS_RANGE :- Interval, when scheduled jobs can be run, in hours, In case the time interval is missed, for example due to a power failure, the scheduled jobs are not executed that day.

RANDOM_DELAY :- maximum number of minutes that will be added to the delay in minutes variable which is specified for each job, The minimum delay value is set, by default, to 6 minutes. If RANDOM_DELAY is, for example, set to 12, then between 6 and 12 minutes are added to the delay in minutes for each job in that particular anacrontab. RANDOM_DELAY can also be set to a value below 6, including 0. When set to 0, no random delay is added. This proves to be useful when, for example, more computers that share one network connection need to download the same data every day.

So if you want to schedule system maintenance cron jobs to run at off peak times you will have to tweak the START_HOURS_RANGE in /etc/anacrontab Or if you want more fine grained control you could just ditch anacron altogether and use /etc/cron.d/dailyjobs

Cron and Anacron has its own advantages and disadvantages. Depending on your requirement, use one of them.

Cron

* Minimum granularity is minute (i.e Jobs can be scheduled to be executed every minute)
* Cron job can be scheduled by any normal user ( if not restricted by super user )
* Cron expects system to be running 24 x 7. If a job is scheduled, and system is down during that time, job is not executed.
* Ideal for servers.
* Use cron when a job has to be executed at a particular hour and minute.

Anacron

* Minimum granularity is only in days.
* Anacron can be used only by super user ( but there are workarounds to make it usable by normal user ).
* Anacron doesn’t expect system to be running 24 x 7. If a job is scheduled, and system is down during that time, it start the jobs when the system comes back up.
* Ideal for desktops and laptops.
* Use anacron when a job has to be executed irrespective of hour and minute.

In a cPanel server, you may find logs are often stored differently comapring a control panel less server. Even Plesk saves logs in different paths. Here is a list of services and their log path that may help you finding the logs.

If they are running cPanel (I usually look for the ‘/scripts’ directory) then run /scripts/securetmp This will remount the ‘/tmp’ and ‘/var/tmp’ as ‘noexec’.

# /scripts/securetmp

Sometimes cPanel has an issue with /tmp permissions. Run the following:

# ls -al /

if you see: drwxr-xr-x 5 root root xxxxx mon xx xx:xx /tmp
You’ll need to chmod the /tmp directory to 1777 in order to set the sticky bit.

# chmod 1777 /tmp

If they are not running cPanel you will manually need to mount the filesystems as nonexecutable. If the user has a separate partition for /tmp, you can simply remount it with noexec,nosuid options. You can edit /etc/fstab with this options, then type “mount –o remount /tmp”. You can then create a symbolic link from /var/tmp to /tmp (“ln –s /tmp /var/tmp”). Keep in mind you will need to backup any files in /var/tmp and move them to /tmp. Pay special attention to the MySQL socket, as it will like need to be recreated. After creating the symbolic link, remove the MySQL socket and recreate it:

# mount -o rw,noexec,nodev,nosuid,remount /tmp

# rm –rf /tmp/mysql.sock

# ln –s /var/lib/mysql/mysql.sock /tmp/mysql.sock

If they do not have a separate partition for /tmp, you will need to create a loopback filesystem. Issue the following series of commands:

If the machine has cPanel on it please make sure the pkgSkipList contains the following (run /usr/sbin/up2date –configure):

kernel*;http*;perl*;mysql*;php*;mod_ssl*

You can run /scripts/checkup2date and it will add these automatically.

From here it is usually best to let cPanel install some of the needed RPM’s it knows it needs. You can accomplish this by running /scripts/rpmup

Now you can go ahead and run /usr/sbin/up2date -l to see what packages are available for install/upgrade.

Right under ‘Fetching rpm headers…’ will be all the packages available to the server. To update these run

# /usr/sbin/up2date -u

Now under ‘The following Packages were marked to be skipped by your configuration:’ it will list the packages available but are being skipped by the skiplist above. We are mostly worried about the kernel. If you see a kernel listed here, run:

# /usr/sbin/up2date -uf kernel kernel-smp kernel-utils kernel-source

Once this has completed you will want to make sure we are booting the correct kernel. Run /bin/uname -r to see which kernel is booting currently. From here run /bin/vi /boot/grub/grub.conf and you should see the newly installed kernel and more than likley others kernels that were previously installed. If the customer was already running a RedHat kernel (usually something like ‘2.4.21-15.0.4-EL’) than it is usually safe to change it to boot the new RedHat kernel you just installed. It should be listed as the very first kernel, if so all you would do is change the ‘default=x’ to ‘default=0’. If the customer was running a customer kernel (something like ‘2.6.6’ or ‘2.4.26-grsecvx’) than you would want to leave the ‘default=x’ line set to the kernel they were booting before.

If the server is running cPanel make sure it has the latest stable version by typing:

# /scripts/upcp

Make sure you restart cPanel after this (if it installed a newer version) by running: service cPanel restart

Change ‘PermitRootLogin yes’ to ‘PermitRootLogin no’ Make sure it is uncommented (take the ‘#’ out from the front of the line if it is there). This disables the ability to ssh into server as root. Customer must use newly created login and then ‘su’ to root if needed after login.

To display a warning banner, vi the /etc/motd file and paste the following:

# vi /etc/motd

Only authorized users may log into this commercial computer system. Users (authorized or unauthorized) have no explicit or implicit expectation of privacy. Any or all uses of this system and all files on this system may be intercepted, monitored, recorded, copied, audited, inspected, and disclosed to authorized sites, ISPs, and law enforcement personnel, as well as authorized officials of other agencies, domestic, foreign, and The Planet Information Security team. By using this system, the user consents to such interception, monitoring, recording, copying, auditing, inspection, and disclosure at the discretion of authorized site or The Planet Information Security team. Unauthorized or improper use of this system may result civil and criminal penalties. By continuing to use this system you indicate your awareness of and consent to these terms and conditions of use.

LOG OFF IMMEDIATELY if you do not agree to the conditions stated in this warning under US CODE: Title 18, U.S.C.

The /etc/securetty file allows you to specify which TTY devices the root user is allowed to login on. Remove all ttys from /etc/securetty except tty1. Which means only root is allowed to login on tty1, forcing the user have to log in as wheel and su if they need more devices as root.

LogWatch: An email gets sent out everyday that contains basic information about the server such as free space, bad login attempts to the machine, etc. It sends this report to root@localhost. If the customer does not ever check the mail on the server locally they will never see these emails. If they DO NOT have cPanel do the following to ensure they get emailed these reports ‘vi /root/.forward’. In this file put the customers primary email address in the only line in this file and save it out. This essentually forwards all of root’s email to this email address.

Note that if they are running Qmail you may need to edit /root/.qmail. Qmail uses a slightly different syntax: an ampersand (&) is placed before the e-mail address:

Note: not entirely necessary since we are doing O/S Hardening and not application hardening

Run /bin/vi /etc/httpd/conf/httpd.conf (assuming this is where the running httpd.conf file is installed) and either add the following lines, or if they already exist, change them to reflect the following

ServerTokens Prod #This will tell Apache to hide all the modules it has installed and only report that they are running Apache as the webserver)

ServerSignature Off #This will tell Apache to not show what version of Apache is running on the server when someone hits a page not found,etc).

The following files and parameters in the table are used when a new account is created with the useradd command. These settings are recorded for each user account in the /etc/shadow file. Therefore, make sure to configure the following parameters before you create any user accounts using the useradd command:

# vi /etc/login.defs

PASS_MAX_DAYS 60 Maximum number of days a password is valid.
PASS_MIN_DAYS 7 Minimum number of days before a user can change the password since the last change.
PASS_MIN_LEN n/a This parameter does not work. It is superseded by the PAM module “pam_cracklib”. See Setting Password Restrictions for more information.
PASS_WARN_AGE 7 Number of days when the password change reminder starts.

/etc/default/useradd
INACTIVE 14 Number of days after password expiration that account is disabled.
EXPIRE Account expiration date in the format YYYY-MM-DD.

Ensure that the above parameters are changed in the /etc/login.defs and /etc/default/useradd files.

The following example shows how to enforce the following password rules:

Minimum length of password must be 8
Minimum number of lower case letters must be 1
Minimum number of upper case letters must be 1
Minimum number of digits must be 1
Minimum number of other characters must be 1
Restrict the use of previous passwords

pam_cracklib.so minlen=8 Minimum length of password is 8
pam_cracklib.so lcredit=-1 Minimum number of lower case letters is 1
pam_cracklib.so ucredit=-1 Minimum number of upper case letters is 1
pam_cracklib.so dcredit=-1 Minimum number of digits is 1
pam_cracklib.so ocredit=-1 Minimum number of other characters is 1

/etc/pam.d/system-auth file and add/change the following pam_cracklib arguments highlighted in bold:

To search entire system for world writable directories, you can run the following:

# find / -path /proc -prune -o -perm -2 ! -type l -ls

The “! -type l” parameter skips all symbolic links since symbolic links are always world-writable. However, this is not a problem as long as the target of the link is not world-writable, which is checked by the above find command.

Be sure to chmod wget and permissions on var/spool/samba,mail, and vbox (world writable directories). Also check permissions on system binaries (telnet, etc).

Restrict cron/at to authorized users by creating the cron.allow file. The cron.allow file only controls administrative access to the crontab command for scheduling and modifying cron jobs

# echo root > cron.allow

# echo root > at.allow

# echo nobody >> cron.deny

# echo nobody >> at.deny

# chown root:root cron.allow at.allow

# chmod 400 cron.allow at.allow

The system crontab files are accessed by only the cron daemon (which runs with superuser privileges) and the crontab command (which has setuid to root). Allowing regular users to read or modify system crontab files can lead to elevated privileges. Therefore, do the following countermeasures:

1. At the bottom of the cPanel interface, locate and click the “Cron Jobs” icon.
2. Click on the “Standard” tab.
3. The first option calls for you to enter the email address of where you want the results of the
cron job to be sent. Simply enter the email address in the provided field and move onto the next step.
4. For “Entry 1? you will see the text “Command to run” with a text box beside. Input the command or path to the script you want to run in the field.

5. Below “Command to run”, there are five options that will allow you the set the time and intervals for your cron job. Those options are listed as follows:
Minute(s)
Hour(s)
Day(s)
Month(s)
Weekday(s)
Once you create the Cron job, a confirmation page will be displayed stating “Cron Updated”.

6. After making the appropriate selections, click the “Save Crontab” button to create the entry. If you elect to reset the changes and go back to the default settings, simply click the “Reset Changes” button.
7. Click the “Go Back” tab and you will be redirected back to the main Cron Job screen.
8. Check your email address to view the results of the cron job.

Advanced Method :-

1. From the main Cron Job screen, click the “Advanced (Unix Style) tab.
2. The first option calls for you to enter the email address of where you want the cron job results to be sent. Simply enter the email address in the provided text box.
3. From there, enter the Minute(s), Hour(s), Day(s), Month(s) Weekday and Command in the provided text boxes.
4. Next, click the “Save Crontab” button to create the entry. If want to the reset the changes and revert back to the default settings, simply click the “Reset Changes” button.
5. A confirmation page will be displayed stating “Cron Updated!” Click the “Go Back” button and you will be redirected back to the main Cron Job screen.
6.) Check your email address to view the results of the cron job.

If you want to benefit from cron jobs and use them effectively, you will need to have some familiarity with Linux commands. This is especially true when creating cron jobs in the Advanced Unix variation. For this reason, it is recommended to inquire within your web host about the files and scripts you want to run before executing them.

Sometimes there is a problem with cron jobs of cPanel 11.x + CentOS 5.x, where the crons are not saved at all with no apparent reason and without any errors. It is done because of the fact that crontab doesn’t have the correct permissions.
You can easily fix by running following comands as root user :-