This article explains which are the Linux commands most used by attackers and how to defend against these attacks. Although the solutions are based on Linux they work on other Unix-like systems as well.
The commands were obtained from a study by D. Ramsbrock, R. Berthier and M. Cukie from the University of Maryland, and Kippo SSH logs from miscellaneous sources.Linux CommandsOnce an attacker compromises a host, he performs tasks that can be classified in stages or states: Check software configuration, install a program, download a file, etc.These 'states' are related with the commands below. Some commands retrieve system information, other commands download files from external sources, other commands can change the system configuration, etc.
- cat [/etc/* | .bash_history | /proc/cpuinfo]. Concatenate files and print on the standard output.
- chmod. Change file mode bits.
- cp. Copy files and directories.
- curl. Transfer a URL.
- export. Bash builtin command to set environment variables.
- ftp. Internet file transfer program.
- history. GNU History Library
- id. Print real and effective user and group IDs
- ifconfig. Configure a network interface.
- kill. Send a signal to a process.
- last. Show listing of last logged in users.
- lwp-download. Fetch large files from the web.
- mail. Send and receive Internet mail.
- mkdir. Make directories
- mv. Move (rename) files.
- nano. Nano's ANOther editor, an enhanced free Pico clone.
- passwd. Change user password.
- perl. Practical Extraction and Report Language.
- php. PHP Command Line Interface 'CLI'.
- pico. Simple text editor in the style of the Alpine Composer.
- ps. Report a snapshot of the current processes.
- python. An interpreted, interactive, object-oriented programming language.
- rm. Remove files or directories.
- sshd. OpenSSH SSH daemon.
- tar. GNU 'tar' saves many files together into a single tape or disk archive, and can restore individual files from the archive.
- uname. Print system information
- unzip. List, test and extract compressed files in a ZIP archive
- uptime. Tell how long the system has been running.
- useradd. Create a new user or update default new user information.
- userdel. Delete a user account and related files.
- vi. Screen-oriented text editor.
- vim. Vi IMproved, a programmers text editor.
- wget. The non-interactive network downloader.
- whoami. Print effective userid.
- w. Show who is logged on and what they are doing.
Countermeasures
How can we protect our system against the execution of sensitive commands? Obviously, we cannot restrict execution to all the commands above. Some of them are essential for daily tasks (cd, mv, cp, ps, etc.). Nevertheless, other commands are potentially harmful (useradd, userdel, kill).As we will see later, the command-line editors are also important (vi, vim, pico, nano). Keep in mind that the combination of other commands can also be used as a primitive editor (id >> victim-info.txt, cat /etc/passwd >> victim-info.txt).But let's focus on the critical commands. We can restrict their execution and apply other security measures to obstruct the attacker's activities.
Restrict Execution with Permissions
The easiest method to limit the execution is to play with UNIX file permissions.For example, to disable execution of wget:
$ chgrp root:root /usr/bin/wget$ chmod 0710 /usr/bin/wget
Now, only root or someone in the sudo group can run wget.If we need to restrict execution of wget command to a special user group we can do something like:
$ groupadd spusers$ usermod -aG spusers bob$ usermod -aG spusers alice$ chgrp spusers /usr/bin/wget$ chmod 0710 /usr/bin/wget
Restricted Shell
Another solution is to use Restricted Shells. For example, a bash restricted shell provides an additional layer of security to bash by disallowing some features, such as:
- Changing directories with the cd builtin.
- Setting or unsetting the values of the SHELL, PATH, ENV, or BASH_ENV variables.
- Specifying command names containing slashes.
- Specifying a filename containing a slash as an argument to the . builtin command.
- Redirecting output using the >, >|, <>, >&, &>, and >> redirection operators.
- Adding or deleting builtin commands with the -f and -d options to the enable builtin.
Unfortunately, it is not secure. A determined user can bypass it if he finds out a way to spawn another shell without restrictions. For example, using vi:
$ vi:set shell=/bin/bash:shell
Hardening Restricted ShellWe can fix the limitations of the restricted shells by controlling the access to certain commands, such as shells and vi editor. But we may end up using some esoteric solution as:
$ chsh --shell /bin/rbash bob$ mkdir -p /usr/local/rbash/bin$ find /bin -exec ln -s {} /usr/local/rbash{} ;$ grep -v "^#" /etc/shells | while read shell; do rm /usr/local/rbash"${shell}"; done$ echo "export PATH=/usr/local/bin:/usr/local/rbash/bin:/usr/bin" >> /home/bob/.bash_profile$ chmod 750 /usr/bin/{vi,vim*}
Certainly, this is not the most recommended way to restrict command execution, but it may work as an easy temporary solution.
Other
Technologies such as SELinux or Virtualization Technologies (KVM, QEMU, VirtualBox, etc.) are safer solutions than the above, but their installation and use are beyond the scope of this document. Please, refer to their official documentation.They take more effort than the other approaches but they may worth it. It only depends on the value of the system to protect.
Auditing Command Execution
The next step in hardening our system against these attacks is to deploy security auditing. The Linux Audit system provides a way to track security-relevant information on the system.First, we install auditd package:
$ apt-get install auditd
The configuration files are stored in /etc/audit. The rules are defined in /etc/audit/audit.rules.For example, if we want to monitor the execution of wget and curl add:
-w /usr/bin/wget -p x -k crit_execs-w /usr/bin/ftp -p x -k crit_execs
Then, restart auditd service to reload the rules:
$ service auditd restart
Now we can review the audited activity with ausearch:
$ ausearch -k crit_execs -itype=PATH msg=audit(11/22/2016 00:28:21.709:16) : item=1 name=(null) inode=61 dev=fe:00 mode=file,755 ouid=root ogid=root rdev=00:00type=PATH msg=audit(11/22/2016 00:28:21.709:16) : item=0 name=/usr/bin/wget inode=8311 dev=fe:03 mode=file,755 ouid=root ogid=root rdev=00:00type=CWD msg=audit(11/22/2016 00:28:21.709:16) : cwd=/home/bobtype=EXECVE msg=audit(11/22/2016 00:28:21.709:16) : argc=(null) a0=wgettype=SYSCALL msg=audit(11/22/2016 00:28:21.709:16) : arch=x86_64 syscall=execve success=yes exit=0 a0=20fb228 a1=20fd668 a2=20f8e08 a3=0 items=2 ppid=6847 pid=6854 auid=bob uid=bob gid=bob euid=bob suid=bob fsuid=bob egid=bob sgid=bob fsgid=bob tty=tty2 ses=5 comm=wget exe=/usr/bin/wget key=crit_execs----type=PATH msg=audit(11/22/2016 00:28:25.865:18) : item=1 name=(null) inode=61 dev=fe:00 mode=file,755 ouid=root ogid=root rdev=00:00type=PATH msg=audit(11/22/2016 00:28:25.865:18) : item=0 name=/usr/bin/wget inode=8311 dev=fe:03 mode=file,755 ouid=root ogid=root rdev=00:00type=CWD msg=audit(11/22/2016 00:28:25.865:18) : cwd=/home/alicetype=EXECVE msg=audit(11/22/2016 00:28:25.865:18) : argc=(null) a0=wgettype=SYSCALL msg=audit(11/22/2016 00:28:25.865:18) : arch=x86_64 syscall=execve success=yes exit=0 a0=1125488 a1=11233c8 a2=1121e08 a3=0 items=2 ppid=6857 pid=6862 auid=alice uid=alice gid=alice euid=alice suid=alice fsuid=alice egid=alice sgid=alice fsgid=alice tty=tty2 ses=6 comm=wget exe=/usr/bin/wget key=crit_execs
Or parse it with aureport:
$ ausearch -k crit_execs --raw | aureport --summary --user -iUser Summary Report===========================total auid===========================1 bob1 alice
Additional Security Measures
Besides to restrict execution and system auditing, there are a few additional security measures that can be applied to limit these attacks.
Securing temporary partitions
Sometimes, the attackers download and execute files from temporary directories. We can disable the execution by mounting these directories with noexec option.Open /etc/fstab and configure it to mount /tmp with tmpfs:
tmpfs /tmp tmpfs nodev,nosuid,noexec,noatime,size=2G 0 0
Another temporary directory used is /var/tmp. The problem is that according to the FHS:
The files and directories located in /var/tmp must not be deleted when the system is booted.
Here we have two options: dedicate one partition for /var/tmp or create a file and mount it as /var/tmp. If we go with the latter, simpler one, we can proceed as follows:
$ dd if=/dev/zero of=/var/tmp.fs bs=1 count=0 seek=4G$ mkfs.ext4 /var/tmp.fs$ mount -o loop,rw,nodev,nosuid,noexec /var/tmp.fs /var/tmp$ chmod 1777 /var/tmp
Then we edit /etc/fstab to make it permanent:
/var/tmp /var/tmp.fs ext4 rw,nodev,nosuid,noexec,noatime 0 0
Drop Outgoing Connections
After breaking into a system, the attacker nearly always opens an outbound network connection. Why? Sometimes because they need their precious hacking tools, generally compressed files with network scanners, password crackers, IRC bots, etc. Another reason is because they send data from their victims back to their infrastructure.Not always is possible, but if the system does not need to open outbound connections we can block them with a firewall. The following example drops any new connections made from the system. Is a dangerous option that must be applied with caution.
$ iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT$ iptables -P OUTPUT DROP
We can also narrow down the scope of the outbound connections. These rules only allow DNS requests and HTTP/S connections from the system:
$ iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT$ iptables -A OUTPUT -p udp --dport 53 -m conntrack --ctstate NEW -j ACCEPT$ iptables -A OUTPUT -p tcp --dport 53 -m conntrack --ctstate NEW -j ACCEPT$ iptables -A OUTPUT -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT$ iptables -A OUTPUT -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT$ iptables -P OUTPUT DROP
An ideal scenario would combine the ports with ranges of trusted IP addresses for better security.This will be always better than having unrestricted output traffic. We just have to adjust the rules to our policies.
Conclusion
We have described some techniques to restrict command execution on Unix-like systems and how to detect abnormal activities with security auditing.These measures will not stop all attacks. As security analysts, we will have security incidents, sooner or later. We need to be prepared and to have a disaster recovery plan.
