Linux Hardening

From Public wiki of Kevin P. Inscoe
Revision as of 16:09, 29 March 2018 by Kinscoe (talk | contribs) (Created page with "==Summary== A look at Linux hardening in the AWS or cloud environment. This article refers to Redhat Enterprise Linux (RHEL) versions 5-7, CentOS versions 5-7 and Amazon Linu...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


A look at Linux hardening in the AWS or cloud environment. This article refers to Redhat Enterprise Linux (RHEL) versions 5-7, CentOS versions 5-7 and Amazon Linux all versions.

Operating system hardening is a long, detailed and constantly evolving topic. As such we will not discuss on this article database, general or web application security practises. Here we will focus on the Linux, its operating and network software and its related settings.

Because this is a cloud environment we won't look at physical security or hardware issues.

Further references

General practise


To protect against attacks and to reduce the attack vector footprint for compromised systems multi-tier architecture or "n-tier" deployment approach is still best practise. For example in a web application a front end should consist of a proxy on one environment of instances, the web or application server in another and the back-end database in yet another with the appropriate level of network separation between each component. In general co-location of software on the same instance is a bad practise.


Software installed

A general practice in any type of server hardening is to install only what is actually required particularly in production environments. This aso usually means to not install compilers and other such development tools on production environments.

This should be proved in staging first before implementing in production by reducing suspected un-needed software and ensuring by QA process the application continues to work as expected.

Services running

As well as reducing the software installed sometimes you cannot remove everything in particular some services like Apache web server. Make sure that services that are not needed but have dependencies requiring them to be installed are not running. Use commands like:

To see what services are enable at boot:

$ sudo chkconfig
abrt-ccpp       0:off   1:off   2:off   3:on    4:off   5:on    6:off
abrt-oops       0:off   1:off   2:off   3:on    4:off   5:on    6:off
abrtd           0:off   1:off   2:off   3:on    4:off   5:on    6:off
acpid           0:off   1:off   2:on    3:on    4:on    5:on    6:off
atd             0:off   1:off   2:off   3:on    4:on    5:on    6:off
auditd          0:off   1:off   2:on    3:on    4:on    5:on    6:off

Disable and stop un-needed services:

$ sudo chkconfig  ypbind off
$ sudo service ypbind off
Xinetd and inetd.conf

If running the older /etc/inetd.conf file, be sure to disable unnecessary services by removing them (or commenting them out) from the inetd.conf file. For example, to remove telnet access, remove the following line:

telnet  stream  tcp    nowait  root  /usr/sbin/telnetd  telnetd

On systems running scripts from the xinetd.d directory, disable the services by changing the script from ‘disable = no’ to ‘disable = yes’. On redhat type systems the xinetd directory is in in /etc/xinetd.d.

service rsync
        disable = yes
        flags           = IPv6
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/bin/rsync
        server_args     = --daemon
        log_on_failure  += USERID

You will need to send a HUP signal to the inetd process after modifying the configuration files (kill -HUP processID)

Removed poorly authenticated and un-encrypted network commands

Under most network configurations, user names, passwords, FTP / telnet / rsh commands and transferred files can be captured by anyone on the same network using a packet sniffer. The common solution to this problem is to use either OpenSSH , SFTP, or FTPS (FTP over SSL), which adds SSL or TLS encryption to FTP.

To remove outdated and in-secure services: NIS:

sudo yum erase inetd xinetd ypserv tftp-server telnet-server rsh-serve

Note that sometimes the telnet client is used for troubleshooting and it is appropriate for it to remain installed for that purpose. The package name is simply "telnet".


Keep patches up to date with

$ sudo yum update


Individual accounts are preferred over service accounts.

Expire accounts when individual no longer requires access or leaves the company or project.

Use chage command to list or change account details related to password changes and expiration.

sudo chage --list kinscoe
Last password change                                    : Jan 13, 2014
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

You can set expiration date when the account is created --expiredate option to useradd.

sudo useradd -e 2017-07-30 someuser

Separate partitions for file systems

Separate Disk Partitions or EBS volumes

Separation of the operating system files from user files may result into a better and secure system.

One such reason is to protect against hard links attempting to access alternate directory paths. This is mostly defended now by SELinux in RHEL 6 and later. See article

Make sure the following filesystems are mounted on separate partitions:


In AWS with prebuilt AMI's this is not always practical (although it can be done) so at the very least it is recommended to mount /home and the rest of the operating system separately.

The second reason to use a separate partition for running services and data is to protect against execution and SUID attacks particularly for web server and FTP server roots.

Edit /etc/fstab file and make sure you add the following configuration options:

  • noexec – Do not set execution of any binaries on this partition (prevents execution of binaries but allows scripts).
  • nodev – Do not allow character or special devices on this partition (prevents use of device files such as zero, sda etc).
  • nosuid – Do not set SUID/SGID access on this partition (prevent the setuid bit).

Sample /etc/fstab entry to to limit user access on /dev/sda5 (ftp server root directory):

/dev/xvdeg1  /ftpdata          ext4    defaults,nosuid,nodev,noexec 1 2

Disable Unwanted SUID and SGID Binaries

See also

All SUID/SGID bits enabled on a file can be misused when the SUID/SGID executable has a security problem or bug. All local or remote user can use such file. It is a good practise to find all such files.

Use the find command as follows:

#See all set user id files:
find / -perm +4000

# See all group id files
find / -perm +2000

# Or combine both in a single command
find / \( -perm -4000 -o -perm -2000 \) -print
find / -path -prune -o -type f -perm +6000 -ls

World-writable files

Ensure you do not have world-writable files on the system. If world-writable files are truly required (for example sharing between accounts) consider revising the design of the application such that the service account is in the same unix group as the individuals who are accessing application files. The make the files group-writable. You can also use ACL's fir finer grain access control. In the majority if not in all cases world-writable files are the result of a poor design and are not truly required. In many cases world-writable files are left behind from troubleshooting access issues and they were never cleaned up.

Use the following command to find all world writable and sticky bits set files:

find /dir -xdev -type d \( -perm -0002 -a ! -perm -1000 \) -print

You need to investigate each reported file and either set correct user and group permission or remove it.

Files owned by non-existent accounts

Files not owned by any existent account or group can pose a security risk or more importantly may be a sign of an already impending attack.

Some recommend commenting out or disabling revoked users in the local passwd file so that you can track file ownership to revoked accounts.

sudo passwd -l accountName

If user-id's (UID) appear in files that have never been issued an account locally that may be sign of an attack that has begun.

Keep in mind if NFS is used the UID may belong to a remote account. This is a good reason for using organized, separate and pre-defined UID and group-id's (GID) such as can be used in NIS.

Locate files on the local system which do not belong to a valid user and a valid group. You will need to run this on every local non-NFS filesystem mount:

sudo find /dir -xdev \( -nouser -o -nogroup \) -ls


One caveat for Kerberos is that time is required to be in sync between clients and the kservers. ktickets in particular will expire in a short amount of time. See the next paragraph on time synchronization.

Kerberos performs authentication as a trusted third party authentication service by using cryptographic shared secret under the assumption that packets traveling along the insecure network can be read, modified, and inserted. Kerberos builds on symmetric-key cryptography and requires a key distribution center. You can make remote login, remote copy, secure inter-system file copying and other high-risk tasks safer and more controllable using Kerberos. So, when users authenticate to network services using Kerberos, unauthorized users attempting to gather passwords by monitoring network traffic are effectively thwarted. For more in Kerberos see

Kerberos is provided through AWS Directory Services.

Time correction and synchronization

The system time should always be correct and ideally all in the same time zone for event detection, correlation and management.

The recommended time synchronization method on Linux systems in AWS is to use NTP. More on NTP in the AWS environment see

Software firewalls

Note that the firewall running in Linux may have to be disabled to allow certains kinds of network communication. In RHEL 5 and 6 this is user-mode process called iptables (service name is iptables for IPv4 and ip6tables for IPv6). In RHEL 7 it is re-worked and referred to as firewalld. In addition there may exists policies enforced on RHEL called selinux. selinux is not a firewall per se but rather a set of policies controlling access to system resources including but not limited to network communication.


Otherwise known as Netfilter. Introduced in Linux kernel 2.4 and still used. See also, iptables to allow Apache and Tomcat ports and Disable iptables and firewalld.

Work in progress


See also Disable iptables and firewalld.


Security Enhanced Linux (SELinux) which is built into RHEL and CentOS provides a flexible Mandatory Access Control (MAC). Under standard Linux Discretionary Access Control (DAC), an application or process running as a user (UID or SUID) has the user’s permissions to objects such as files, sockets, and other processes. Running a MAC kernel protects the system from malicious or flawed applications that can damage or destroy the system.

The default settings for RHEL are usually quite restrictive however RHEL 5 by default SELinux is set to Permissive only which means it only reports violations of policy but does not enforce them. In RHEL 6 and above it is enforced and restrictive. Note that in Amazon Linux it appears SELinux is not installed by default:

To install SELinux:


To tell if SELinux is running and enforcing:

$ getenforce

Enable SELinux in RHEL 6 & 7:

For Redhat 6 and 7 see -

Edit file /etc/selinux/config and change line "SELINUX=" to "enforcing" and SELINUXTYPE to "targeted".

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
# SELINUXTYPE= can take one of three two values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected.
#     mls - Multi Level Security protection.

This won't take effect until the next reboot so until then to enable it now:

$ sudo setenforce 1
$ sudo getenforce   

For more on SELinux see

See also Disable SELinux.

SSH access and practise

OpenSSH while secure is prone to many automated attacks and as such should not be available externally without some kind of IP address limiting or control.

AWS has Security Groups to prevent such access however this can also can be controlled within the instance as well by updating /etc/sysconfig/iptables to accept connection only from and, enter:

-A RH-Firewall-1-INPUT -s -m state --state NEW -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -s -m state --state NEW -p tcp --dport 22 -j ACCEPT

We have a defined set of internal HMH subnets available at HMH internal office subnets.

Brute force is a method of defeating a cryptographic scheme by trying a large number of possibilities using a single or distributed computer network. There are a number of brute force attack scripts that can be run if external unfettered access to SSH is required. We won't go into detail only list them for further research.

fail2ban is probably the most popular of them.

  • DenyHosts is a Python based security tool for SSH servers. It is intended to prevent brute force attacks on SSH servers by monitoring invalid login attempts in the authentication log and blocking the originating IP addresses.
  • Fail2ban is a similar program that prevents brute force attacks against SSH.
  • BlockHosts Automatic blocking of abusive IP hosts. (This software is now over 10 years old).

Note also that is a devops trend to not even turn on OpenSSH except to perform troubleshooting. Code can be deployed by a variety of means without using terminal access in repeatable patterns. If software fails and a post-mortem is required it is possible to mount (or take snapshot and redeploy) the root and deployment EBS volumes from the failing system on another instance for evaluation.

SSH settings

/etc/ssh/sshd_config on all servers

  • Turn on privilege separation (UsePrivilegeSeparation yes and VerifyReverseMapping yes)
  • Prevent the use of insecure home directory and key file permissions (StrictModes yes)
  • Only Use SSH Protocol 2. SSH protocol version 1 (SSH-1) has man-in-the-middle attacks problems and security vulnerabilities. SSH-1 is obsolete and should be avoided. (Protocol 2)
  • Disable .rhosts Files. Don’t read the user’s ~/.rhosts and ~/.shosts files. (IgnoreRhosts yes)
  • Disable root logins (PermitRootLogin no)
  • Disable password logins (PasswordAuthentication no)
  • Set the idle-timeout (TCPKeepAlive, ClientAliveInterval and ClientAliveCountMax)
  • Disable Host-Based Authentication (HostbasedAuthentication no)
  • Enable a Warning Banner (Banner /etc/issue)
  • Chroot SSHD (Lock Down Users To Their Home Directories). By default users are allowed to browse the server directories such as /etc/, /bin and so on. With the release of OpenSSH 4.8p1 or 4.9p1, you no longer have to rely on third-party tools such as rssh or complicated chroot(1) setups to lock users to their home directories. See more at (ChrootDirectory)

These are of lesser risk but included for completeness.

  • Disable port forwarding on servers except during software installs (AllowTcpForwarding no and X11Forwarding no)

Passwords and SSH keys

In general best practise is to not use password logins. In RHEL 5 by defaut password logins to SSH are allowed and used. In RHEL 6 and beyond SSH keys are required. Amazon Linux keys are also required for SSH access.

Key storage


Key rotation


Root logins

In general best practise is to not login to root directly. In AWS instances by default root logins are usually not permitted. Instead one logins to a non-root account and performs a sudo command to elevate privileges. In addition this non-root logins requires a key supplied by AWS only one time so it must be stored.

Single sign-on and federated logins


Running privileged commands and preventing privilege escalation

Privilege escalation is the act of exploiting a bug, design flaw or configuration oversight in an operating system or software application to gain elevated access to resources that are normally protected from an application or user.

Shell command should always be run using the sudo command as opposed to changing to the root user and running the commands directly. The root use should only be used for system rescues.

Services should be run in a chroot jail when possible.

Stack exploits

Stack smashing, stack canaries and Stack-Smashing Protection (SSP).

This is mostly the C compiler's job but the kernel can detect and prevent some forms of stack pollution.

See also, and

Enable Address Space Layout Randomization (ASLR):

Set the /proc/sys/kernel/randomize_va_space to 2. This should be the default in RHEL/CentOS 5 and above. See also

sudo echo "2" > /proc/sys/kernel/randomize_va_space

You can also use the sysctl command:

sudo sysctl -w kernel.randomize_va_space = 2

Reload the sysctl config into the kernel using command:

sudo sysctl -p

To survive reboots by adding following line to /etc/sysctl.conf file:

kernel.randomize_va_space = 2

Buffer overflow

Enable ExecShield buffer overflows protection.

ExecShield is security Linux kernel patch to avoid worms and other problems and has been present and enabled in the Linux kernel for a 15 years now.

Exec Shield is a project that got started at Red Hat, Inc in late 2002 with the aim of reducing the risk of worm or other automated remote attacks on Linux systems. The first result of the project was a security patch for the Linux kernel that adds an NX bit to x86 CPUs. While the Exec Shield project has had many other components, some people refer to this first patch as Exec Shield.

To enable ExecShield protection:

sudo sysctl -w kernel.exec-shield = 1

Reload the sysctl config into the kernel using command:

sudo sysctl -p

To survive reboots by adding following line to /etc/sysctl.conf file:

kernel.exec-shield = 1

Network attacks

Review running and open ports

sudo netstat -atulpn
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name   
tcp        0      0     *                   LISTEN      1379/snmpd          
tcp        0      0       *                   LISTEN      1873/rsync          
tcp        0      0      *                   LISTEN      1612/mysqld         
tcp        0      0       *                   LISTEN      1189/rpcbind        
tcp        0      0     *                   LISTEN      1211/rpc.statd      
tcp        0      0        *                   LISTEN      1462/sshd           
tcp        0      0      *                   LISTEN      12251/master        
tcp        0     52              ESTABLISHED 27519/sshd  

Remove any ports and services that are not required. Some services are controlled by xinetd rather than service command.

More on xinetd - TBD

TCP SYN Cookie Protection

Turn On TCP SYN Cookie Protection:

sudo sysctl -w net.ipv4.tcp_syncookies = 1

Reload the sysctl config into the kernel using command:

sudo sysctl -p

To survive reboots by adding following line to /etc/sysctl.conf file:

net.ipv4.tcp_syncookies = 1

IP Spoofing

Red Hat Enterprise Linux 6 and above invalidate and discard packets when the route for outbound traffic differs from the route of incoming traffic to help prevent spoofing. RHEL6's (and RHEL7's) default setting is more strict than RHEL5's, as RHEL6 follows the Strict Reverse Path Forwarding filtering recommended in RFC 3704 - Ingress Filtering for Multihomed Networks. See notes at

Check with Network Engineering before changing the default.

For RHEL 6 and 7 use:

sudo sysctl -w net.ipv4.conf.default.rp_filter = 2
sudo sysctl -w net.ipv4.conf.all.rp_filter = 2

Reload the sysctl config into the kernel using command:

sudo sysctl -p

To survive reboots by adding following line to /etc/sysctl.conf file:

net.ipv4.conf.all.rp_filter = 2
net.ipv4.conf.default.rp_filter = 2

For RHEL 5:

The sysctl net.ipv4.conf.default.rp_filter selects the default RPF filtering setting for IPv4 networking. (It can be overridden per network interface through net.ipv4.conf.INTERFACE.rp_filter).

RHEL7, RHEL6, and RHEL5 ship with a default /etc/sysctl.conf that sets this sysctl to 1, but the meaning of this value is different between the RHEL6 and the RHEL5 kernel.

In RHEL5, the sysctl is documented as follows:


rp_filter - BOOLEAN

1 - do source validation by reversed path, as specified in RFC1812
       Recommended option for single homed hosts and stub network
       routers. Could cause troubles for complicated (not loop free)
       networks running a slow unreliable protocol (sort of RIP),
       or using static routes.

0 - No source validation.

       conf/all/rp_filter must also be set to TRUE to do source validation on the interface

       Default value is 0. Note that some distributions enable it in startup scripts.

In RHEL6 and RHEL7 there are three possible values for this setting:


rp_filter - INTEGER
        0 - No source validation.
        1 - Strict mode as defined in RFC3704 Strict Reverse Path 
            Each incoming packet is tested against the FIB and if the interface
            is not the best reverse path the packet check will fail.
            By default failed packets are discarded.
        2 - Loose mode as defined in RFC3704 Loose Reverse Path 
            Each incoming packet's source address is also tested against the FIB
            and if the source address is not reachable via any interface
            the packet check will fail.

        Current recommended practice in RFC3704 is to enable strict mode 
        to prevent IP spoofing from DDos attacks. If using asymmetric routing
        or other complicated routing, then loose mode is recommended.

        The max value from conf/{all,interface}/rp_filter is used 
        when doing source validation on the {interface}.

        Default value is 0. Note that some distributions enable it
        in startup scripts.

with the value 2 corresponding to the behaviour that value 1 provided in RHEL5.


Add following line in “/etc/sysctl.conf” file to ignore ping or broadcast request.

# Ignore ICMP request:
net.ipv4.icmp_echo_ignore_all = 1

# Ignoring broadcasts request


# Make sure spoofed packets get logged
net.ipv4.conf.all.log_martians = 1

Load new settings or changes, by running following command

sudo sysctl -p


Intrusion Detection Systems


Logwatch and logcheck

Monitor Suspicious Log Messages With Logwatch / Logcheck

Read your logs using logwatch or logcheck. These tools make your log reading life easier. You get detailed reporting on unusual items in syslog via email. A sample syslog report:

 ################### Logwatch 7.3 (03/24/06) ####################
        Processing Initiated: Fri Oct 30 04:02:03 2009
        Date Range Processed: yesterday
                              ( 2009-Oct-29 )
                              Period is day.
      Detail Level of Output: 0
              Type of Output: unformatted
           Logfiles for Host:
 --------------------- Named Begin ------------------------
 **Unmatched Entries**
    general: info: zone Transfer started.: 3 Time(s)
    general: info: zone refresh: retry limit for master ttttttttttttttttttt#53 exceeded (source ::#0): 3 Time(s)
    general: info: zone Transfer started.: 4 Time(s)
    general: info: zone refresh: retry limit for master ttttttttttttttttttt#53 exceeded (source ::#0): 4 Time(s)
 ---------------------- Named End -------------------------
  --------------------- iptables firewall Begin ------------------------
 Logged 87 packets on interface eth0
   From - 1 packet to tcp(8080)
   From 59.www.zzz.yyy - 1 packet to tcp(22)
   From 60.32.nnn.yyy - 2 packets to tcp(45633)
   From - 5 packets to tcp(8000,8080,8800)
 ---------------------- iptables firewall End -------------------------
 --------------------- SSHD Begin ------------------------
 Users logging in through sshd:
    root: 6 times
 ---------------------- SSHD End -------------------------
 --------------------- Disk Space Begin ------------------------
 Filesystem            Size  Used Avail Use% Mounted on
 /dev/sda3             450G  185G  241G  44% /
 /dev/sda1              99M   35M   60M  37% /boot
 ---------------------- Disk Space End -------------------------
 ###################### Logwatch End #########################


A rootkit is a program (or combination of several programs) designed to take fundamental control (“root” access) of an operating system, without authorization by the system’s owners Most rootkits use the power of the kernel to hide themselves, they are only visible from within the kernel.


chkrootkit is a tool to locally check for signs of a rootkit.

Type the following command to install chkrootkit

sudo yum install chkrootkit

Start looking for rootkits, enter:

$ sudo chkrootkit

Look for suspicious strings, enter:

$ sudo chkrootkit -x | less

You need to specify the path for the external commands used by chkrootkit such as awk, grep and others. Mount /mnt/safe using nfs in read-only mode and set /mnt/safe binaries PATH as trusted one, enter:

$ sudo chkrootkit -p /mnt/safe


rkhunter (Rootkit Hunter) is a Unix-based tool that scans for rootkits, backdoors and possible local exploits. rkhunter is a shell script which carries out various checks on the local system to try and detect known rootkits and malware. It also performs checks to see if commands have been modified, if the system startup files have been modified, and various checks on the network interfaces, including checks for listening applications.

Type the following command to install rkhunter:

sudo yum install rkhunter

The following command option tells rkhunter to perform various checks on the local system:

sudo rkhunter --check

The following command option causes rkhunter to check if there is a later version of any of its text data files:

$ sudo rkhunter --update

The following option tells rkhunter which directories to look in to find the various commands it requires:

$ sudo rkhunter --check --bindir /mnt/safe


Zeppoo allows you to detect rootkits on i386 and x86_64 architecture under Linux, by using /dev/kmem and /dev/mem. Moreover it can also detect hidden tasks, connections, corrupted symbols, system calls and so many other things. eppo is not included in the redhat base repos but can be downloaded source at

Linux Host-based IDS applications

Host-based intrusion detection (HIDS) applications



Once a free and open source project it is now a commercial product.



Osiris now SNARE

Once an open and free project now a commercial product.


Best practise is to configure logging and auditing to collect all attack vector attempts. This is also useful to find out software misconfiguration which may open your system to various attacks.

By default syslog stores data in /var/log/ directory.

rsyslog vs syslog-ng

Linux kernel by default uses syslog. This is a very minimal implementation and a better process bases system logger should be used. There are two options: rsyslog and syslog-ng.

rsyslog is a very basic but capable system logger.

syslog-ng is very robust and is recommended however it requires a more complex configuration.


Linux log files and locations


  • /var/log/messages - The default location for most log messages out of the box.
  • /var/log/syslog -
  • /var/log/boot.log - A log of boot up messages
  • /var/log/cloud-init.log or /var/log/cloud-init-output.log - Output produced by cloud-init process in Redhat from AWS.
  • /var/log/auth.log – Authentication logs.
  • /var/log/kern.log – Kernel logs.
  • /var/log/cron.log – Crond logs (cron job).
  • /var/log/maillog – Mail server logs.
  • /var/log/mysqld.log – MySQL database server log file.
  • /var/log/secure – Authentication log (login failures go here).
  • /var/log/utmp or /var/log/wtmp : Login records file. This is a binary file and not readable in a text editor. Use commands who, last and lastb to access them.
  • /var/log/yum.log: Yum log files.

How to send logs to a remote loghost

Central syslog host for analysis and archival.


Log rotation





System Accounting with auditd

The auditd is provided for system auditing.

It is responsible for writing audit records to the disk.

During startup, the rules in /etc/audit.rules are read by this daemon. You can open /etc/audit.rules file and make changes such as setup audit file log location and other option. With auditd you can answers the following questions:

  • System startup and shutdown events (reboot / halt).
  • Date and time of the event.
  • User responsible for the event (such as trying to access /path/to/topsecret.dat file).
  • Type of event (edit, access, delete, write, update file & commands).
  • Success or failure of the event.
  • Records events that Modify date and time.
  • Find out who made changes to modify the system’s network settings.
  • Record events that modify user/group information.
  • See who made changes to a file etc.

Monitor user activities

GNU acct tools

There are two useful tools that come as a part of the GNU acct tools-set called ‘psacct‘ and ‘acct‘. They are used for monitoring user activities and processes on a system.

For documentation the GNU acct tools see

See also

sudo yum install psacct

accton - turns process accounting on or off

sudo /sbin/accton

ac - print statistics about users’ connect time

Some examples of using ac

sudo ac --individual-totals 
        thorner                             12.11
        ec2-user                            27.70
        jobs                                96.08
        kinscoe                            378.79
        nveeder                            183.54
        jdeprin                            390.98
        sysoper                            176.06
        total     1265.25

Print usage per day.

sudo ac -d -p
Jul  6  total        5.22
        kinscoe                              3.47
        jdeprin                              9.37
Jul  7  total       12.84
        jdeprin                              0.55
Jul  8  total        0.55
        kinscoe                              8.21
Jul 10  total        8.21
        kinscoe                              2.74
        jdeprin                              2.78
Today   total        5.52

Display per day login time of a particular user. Can be used to spot unusual trends.

ac -d kinscoe
Mar 29  total        0.35
Apr 19  total        1.19
May  2  total        0.63
May  9  total        0.11
May 19  total        5.89
May 20  total       18.43
May 23  total        3.15
Jul  7  total        3.47
Jul 10  total        8.21
Today   total        2.87
Last used commands
sudo lastcomm
locate                  root     pts/1      0.30 secs Mon Jul 11 12:24
httpd             SF    apache   __         0.02 secs Mon Jul 11 12:23
httpd             SF    apache   __         1.58 secs Mon Jul 11 11:27
httpd             SF    apache   __         0.26 secs Mon Jul 11 12:23
httpd             SF    apache   __         0.36 secs Mon Jul 11 12:23
bash               F    root     pts/1      0.00 secs Mon Jul 11 12:24
sudo              S     root     pts/1      0.00 secs Mon Jul 11 12:23
chkconfig         S     root     pts/1      0.08 secs Mon Jul 11 12:23
sudo              S     root     pts/1      0.00 secs Mon Jul 11 12:22
service           S     root     pts/1      0.00 secs Mon Jul 11 12:22
psacct                  root     pts/1      0.00 secs Mon Jul 11 12:22
touch                   root     pts/1      0.00 secs Mon Jul 11 12:22
accton            S     root     pts/1      0.00 secs Mon Jul 11 12:22

The "sa" command is used to print the summary of commands that were executed by users.

To enable this collection:

sudo chkconfig psacct on
sudo service psacct start
Starting process accounting:                               [  OK  ]
 sudo sa  
      13       3.73re       0.04cp    37971k
       4       3.71re       0.04cp    64064k   httpd*
       7       0.01re       0.01cp    23038k   ***other*
       2       0.00re       0.00cp    38048k   sudo

utmp, wtmp and btmp files

Login and login failure binary log files are stored /var/log/utmp, /var/log/wtmp and /var/log/btmp. These are binary files and not readable in a text editor.

Use commands who, last and lastb to access them.

last - Show login history.

sudo last | more
kinscoe  pts/1     Mon Jul 11 09:45   still logged in   
jdeprin  pts/0     Mon Jul 11 09:43   still logged in   
kinscoe  pts/0     Sun Jul 10 12:50 - 21:02  (08:12)    
jdeprin  pts/0      Fri Jul  8 11:59 - 12:33  (00:33)    
jdeprin  pts/0      Thu Jul  7 18:50 - 22:01  (03:11)    
kinscoe  pts/1     Thu Jul  7 11:24 - 14:52  (03:28)    
jdeprin  pts/0      Thu Jul  7 11:16 - 17:27  (06:11)    
nveeder  pts/1     Wed Jul  6 12:51 - 12:52  (00:01)    
jdeprin  pts/0      Wed Jul  6 11:03 - 16:14  (05:11)    
jdeprin  pts/0      Sun Jul  3 12:57 - 16:08  (03:11)    
jdeprin  pts/1      Sat Jul  2 13:14 - 16:25  (03:11)    
jdeprin  pts/0      Sat Jul  2 13:12 - 17:23  (04:11)    
jdeprin  pts/0    Tue Oct  6 14:20 - 14:21  (00:00)    
jdeprin  pts/2    Tue Oct  6 13:27 - 16:38  (03:11)    
sysoper  pts/1    Tue Oct  6 13:05 - 18:16  (05:11)    
jdeprin  pts/1    Tue Oct  6 12:48 - 12:48  (00:00)    
sysoper  pts/0    Tue Oct  6 10:41 - 13:52  (03:11)    
kinscoe  pts/2     Mon Oct  5 13:20 - 13:21  (00:01)    
kinscoe  pts/1     Mon Oct  5 13:18 - 13:21  (00:03)    
kinscoe  pts/0     Mon Oct  5 13:16 - 13:22  (00:05)    
kinscoe  pts/0     Fri Oct  2 12:51 - 15:47  (02:55)    
sysoper  pts/0    Thu Oct  1 15:10 - 18:21  (03:11)    

wtmp begins Thu Oct  1 15:10:15 2015

who - who is logged in?

kinscoe  pts/1        2016-07-11 09:45 (


AWS does provide encrypted EBS volumes. Linux can encrypt volumes and files using commands like OpenSSL, GnuPG, dm-crypt (and the now non-maintained TrueCrypt) however using encryption at the Amazon level would be preferred for performance and also secure (key) reasons.

Network traffic on Linux can be encrypted by

OpenVPN and IPSec are the preferred method of encrypting IP traffic.

Some examples:

IPsec -