You are here : Home » Learning security » Operating Systems » GNU Linux » Linux filesystem security scans

Linux filesystem security scans

D 5 December 2010     H 09:09     A Emeric Nasi     C 0 messages


License : Copyright Emeric Nasi, some rights reserved
This work is licensed under a Creative Commons Attribution 4.0 International License.
Creative Commons License

Either they are intentional or not, system misconfiguration can lead to very big problems. For example :

  • Corruption or deletion of important system files
  • Integrity failure (ex. eavesdropping on private data)
  • Privilege escalation
  • Backdoor/rootkit installation

To avoid these problems you should regularly scan your system for known "misconfiguration patterns". This article will explain how to do so using bash on a GNU Linux system.

I. General system scan

In this section I will describe commands that can be used to have a general overview of your system’s security potential risks.

I.1 Setuid et Setgid files

Files with the setuid bit set are not necessarily evil, and setgid folders are really useful and can improve your system’s security. However an awfully huge lot of exploits takes advantage of vulnerabilities in setuid files because it is an easy way to escalate privileges (when exploiting a setuid bit file belonging to root). You should always have a look at those files and ensure that each one really needs to have the setuid bits on and are known to be secure and stable.

List all setuid files :
find /   -perm -4000 2>/dev/null
List all setuid files owned by root :
find /   -perm -4000 -user root 2>/dev/null
List all setgid files :
find /   -perm -4000 2>/dev/null
List all setgid files owned by root :
find /   -perm -4000 -user root 2>/dev/null

I.2 World writable files

The other big danger on filesystems is bad rights management (it can be admin mistakes). A world writable file owned by root can lead to easy privileges escalation or system corruption.
List all world writable files:
find   /  ! -type l -perm -002  2>/dev/null

Note: I use the "! -type l" options to avoid to list symlinks (that are described as world writable files).

I.3 Opened socket connections

In Linux system, everything is a file, even sockets. And every admin should have a regular look at the opened connections on a machine.
The classical way to list all transport layer connections would be to use netstat :
netstat -tupl

However I prefer the lsof tool that offers way more possibilities and is cabable of describing precisely any opened file on the system (lsof is for "list opened files". Sockets are files, so a nice way to monitor your opened connections would be to use the next command :
lsof | grep -E "IPv4|IPv6|COMMAND.*USER" |  sed -r  "s/ +/ /g" | cut -d " " -f 1,2,3,5,8,9 | column -t | sed "s/.*/ &/"

That command will list all IPv4 and IPv6 opened connections and display the corresponding command, pid, user, the connexion type, the transport layer protocol used and the connection description (IP address and port). The column and sed part is just for nice formatting ;-).

I.4 Broken Symbolic links

It can be useful to be able to list the broken symlinks on the system (example, for a cleaning task).
Example, list all broken symlinks in /usr directory :
find -L  /usr -type l -maxdepth 8 2>/dev/null

I.5 Sticky bit files

The sticky bit is important, it should always be set on world writable folders to prevent a user from removing a file he doesn’t own.
List all sticky bit files on the system :
find /  -perm -1000 2>/dev/null

II. Potential threats scan

After the general scan, you can do more detailed scan to find abnormal configurations or real dangers.

II.1 File access rights risks

Some files should never be world writable or even world readable.
For example the directories /bin, /sbin, /boot, /etc, /lib, /root, /usr should never be world writable. A world writable file in these directories could lead to system trojaning/corruption.
Here is a simple way to scan all these folders for world writable files.

  1. #/bin/bash
  2. ww_scan_dirs="/bin /sbin /boot /etc /lib /root /usr "
  3. for ww_scan_dir in $ww_scan_dirs
  4. do
  5. for file in ` find $ww_scan_dir ! -type l -perm -002 `
  6. do
  7. echo "DANGER : $file is world writable, files in $ww_scan_dir shouldn't be."
  8. done | sort
  9. done
  10. unset ww_scan_dir
  11. unset ww_scan_dirs

Another concern about world writable directories is that, when allowed (ex insind /var or /tmp) they must have the sticky bit on to prevent unauthorized file deletion.

  1. for file in `find / -type d -perm -002 ! -perm -1000 2>/dev/null`
  2. do
  3. echo"DANGER : $file is a world writable directory, it should have the sticky bit on."
  4. done | sort

II.2 file ownership risks

Are you sure that all system files are really owned by root? You can imagine the potential disaster for your system if not.Here is a way to verify that.

  1. for file in `find /root $find_options ! -user root 2>/dev/null`
  2. do
  3. echo"DANGER : $file doesn't belong to root. It mustn't be in the /root folder."
  4. done | sort

It is also interesting to verify if all files belong to an existing user and group.

  1. #!/bin/bash
  2. for file in `find / $find_options -nouser 2>/dev/null`
  3. do
  4. echo"DANGER : No user corresponds to $file numeric user ID."
  5. done | sort
  6. for file in `find / $find_options -nogroup 2>/dev/null`
  7. do
  8. echo "DANGER : No group corresponds to $file numeric group ID."
  9. done | sort

II.3 Special files risks

"Special" files like devices, socket and symlinks should be considered carefully. For example you should verify that devices are only stored in special directories like /dev or .../udev/ which can be done using the next script :

  1. #!/bin/bash
  2. device_scan_dirs="/bin /sbin /lib /boot /etc /home /root /sys /usr /var /tmp /mnt /media /proc"
  3. for device_scan_dir in $device_scan_dirs
  4. do
  5. for file in `find $device_scan_dir $find_options -type b -o -type c 2>/dev/null`
  6. do
  7. [[ "$file" =~ ^/lib/udev/devices/ ]] || echo "DANGER : $file is a device and should be in /dev (or /lib/udev/devices)."
  8. done | sort
  9. done
  10. unset device_scan_dir
  11. unset device_scan_dirs

Symlinks should also be checked carefully as they are often exploited to gain root privileges. For example, the presence of a symlink inside the /tmp folder is not dangerous in itself but if that symlink was intentionally created by an attacker to imitate the name of tmp files generated by an insecure program, this symlink could lead to the corruption of a system file or to privilege escalation. If you want to check your /tmp directory for symlinks :

  1. #!/bin/bash
  2. for file in `find /tmp $find_options -type l `
  3. do
  4. echo"RISK : $file is a symbolic link inside the /tmp folder"
  5. done | sort

II.4 Extreme dangers detection

There are a few configurations (intentionally or not) that are sure to lead to system "0wn3rship". If you detect one of these patterns on you computer, you should repair it right away (however it might already be too late!).
Check if there are any files with SetUID bit on in the /tmp folder :

  1. for file in `find /tmp $find_options -perm -4000 `
  2. do
  3. echo "EXTREME DANGER : $file is setuid and shouldn't be in /tmp folder."
  4. done | sort

Check if there are any files that are world writable and have setuid bit on (That should never happen. However if it does, the admin may live a nightmare...)

  1. for file in `find / $find_options -perm -4002 2>/dev/null`
  2. do
  3. echo "EXTREME DANGER : $file is setuid and world writable."
  4. done | sort

Some files should never be readable by anyone but root :

  1. #!/bin/bash
  2. nonReadableFiles="/etc/master.passwd /etc/shadow /etc/shadow- /etc/gshadow /etc/sudoers /var/log/messages "
  3. for nonReadableFile in $nonReadableFiles
  4. do
  5. [ -f "$nonReadableFile" ] && [[ $(ls -gn "$nonReadableFile") =~ ^.......r..\ .*$ ]] && echo "EXTREME DANGER : $nonReadableFile should not be readeable by others."
  6. done
  7. unset nonReadableFile
  8. unset nonReadableFiles

II.5 POSIX file capabilities risks

POSIX file capabilities are enabled by default on most modern Linux distribs, however they are not without dangers. You may want to read first what are POSIX file capabilities and after that why they are dangerous.

It is not easy to scan your system for dangerous capabilities because the tool used for that getcap for example, are quite buggy and poorly documented. Here is an example of a script looking for dangerous file capabilities on the entire system.

  1. #!/bin/bash
  2. totalCaps=$(find / -type f -print0 2>/dev/null | xargs -0 getcap 2>/dev/null)
  3. echo "Number of files with capabilities : $(echo "$totalCaps" | wc -l)"
  4. dangerousCaps="cap_chown cap_dac_override cap_fowner cap_module cap_sys_admin cap_setuid cap_setfcap"
  5. for line in $totalCaps
  6. do
  7. for dangerousCap in $dangerousCaps
  8. do
  9. [[ "$line" =~ ^.*=\ .*$dangerousCap ]] && echo "RISK : $(echo "$line" | cut -d "=" -f 1) has or inherits the $dangerousCap capability"
  10. done
  11. { [[ "$line" =~ ^.*=ep ]] || [[ "$line" =~ ^.*=eip ]] || [[ "$line" =~ ^.*=ei ]]; } && echo "DANGER : $(echo "$line" | cut -d "=" -f 1) has or inherits all capabilities"
  12. done
  13. unset line
  14. unset dangerousCaps
  15. unset dangerousCap

III Glyptodon

In the present article, I mentioned a few misconfiguration scans that could or should be done regularly on any GNU Linux computer. I think you realized that there are many more scans that are possible and that it can be fastidious to manually launch them everyday. But do not worry, I went trough this before and, lucky you, I created a open source tool that can do all that for you, log this information and sends an email report. I called this tool Glyptodon
Glyptodon executes all the scans mentioned in this article and many more. Plus it is actually the only tool scanning for POSIX file capabilities linked risks. Glyptodon is also compatible with "abnormal" file names (like files containing spaces).
You can find more infos about Glyptodon here, and download the latest version here.
And remember my website is participative so do not hesitate to write or email any improvement or critics about any tool or article.

Any message or comments?

This forum is moderated before publication: your contribution will only appear after being validated by an administrator.

Who are you?
Your post