|Recommended Books||Security issues||Man Pages||FAQ|
There are a number of common attacks/exploits in Linux (and UNIX) that can be reduced in risk and significance with a proper directory and partition structure.
One of the most common denial of service attacks is to fill up the disk space with junk data, this can also happen unintentionally with software that experiences a problem. This doesn't do you any good however if someone can force a legitimate application to generates massive amount of log files and feel the /var subsystem
The next big attack that takes advantage of disk setup would be /tmp races, and core dumps, programs that create links or files improperly without checking to make sure they exist first, especially programs that run as root. An attacker can then link /tmp/foo to /etc/passwd and potentially add a user account, wipe the password database out, and so on.
Mounting options can be used to mount a partition read only, not allow execution of programs, not to allow devices and other useful things. See Protective partitioning
You may encounter difficulties when using these options however, for example if you mount /usr as read only you will have not to forget to remount it before running updates. Also you need to move /usr/local to /opt as some programs in /usr/local write to this partition. It's not big deal just additional discipline, but still adds to the complexity of the system. More or less harmless options that do increase security are "nosuid" (no setuid or setgid files), "noexec" (no executables) and "nodev" (no device files).
So with this in mind we have can propose several guidelines:
Instead of jumping thou the hoops with read-only protection (which is actually very tricky for directories like /etc you can just check key files and overwrite changed files from a tarball or CD-based read-only "baseline". All changes need to be coped to this CD/tarball as well.
The idea is to minimize privileges via mount options. Among typical measure we can mention( Hardening Red Hat Enterprise Linux 5):
A example of "privilege minimized" /etc/fstab from RHEL recommendations:
LABEL=/ / ext3 defaults 1 1
LABEL=/tmp /tmp ext3 defaults,nosuid,noexec,nodev 1 2
LABEL=/var/log/audit /var/log/audit ext3 defaults,nosuid,noexec,nodev 1 2
LABEL=/home /home ext3 defaults,nosuid,nodev 1 2
LABEL=/var /var ext3 defaults,nosuid 1 2
LABEL=/boot /boot ext3 defaults,nosuid,noexec,nodev 1 2
/tmp /var/tmp ext3 defaults,bind,nosuid,noexec,nodev 1 2
tmpfs /dev/shm tmpfs defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
sysfs /sys sysfs defaults 0 0
proc /proc proc defaults 0 0
LABEL=SWAP-sda6 swap swap defaults 0 0
Besides having separate partitions for the obvious, such as SWAP and /tmp, defensive partitioning presuppose usage of ro and nosuid mounting flag and using enough separate partitions to accommodate distinct classes of application and human users. Intruders might try to create excessive generation of logging data or fill your file system with large files through FTP or mail spool or install SUID programs. Any intelligent partition scheme depends on the how the machine is used. The basic rules are:
/var/log) should also be on a separate partition.
/tmp, should be on a separate partition. This reduces the risk of a user DoS by filling up your "/" mount point and rendering the system unusable.
Here are specific recommendations based on a typical Unix partitioning scheme:
Also, for partitions in which you cannot be sure of the needed space, installing
Logical Volume Manager (
lvm-common and the needed binaries for your
kernel, this might be either
Using lvm you can create volume groups that expand multiple physical
By separating file systems into various partitions, you can fine tune permissions and functionality. Doing so will provide you greater granularity for permissions, as well as adding a layer of security for any potential bad guys to work through.
Steve Grubb suggests, and quite rightly so, that areas where users have write privileges be kept on their own partition. This allows you to prevent hard link privilege escalation attempts, prevent creative device additions, and other unsavory behavior.
Once you have your partitions broken out and sized accordingly, you can begin to restrict the various mount points as much as possible. You should add nodev, noexec, and nosuid wherever possible. An example of a decently restricted /etc/fstab file is below:/dev/VG_OS/lv_root / ext3 defaults 1 1 /dev/VG_OS/lv_tmp /tmp ext3 defaults,nosuid,noexec,nodev 1 2 /dev/VG_OS/lv_vartmp /var/tmp ext3 defaults,nosuid,noexec,nodev 1 2 /dev/data_vol/lv_home /home ext3 defaults,nosuid,nodev 1 2 /dev/VG_OS/lv_var /var ext3 defaults,nosuid 1 2 /dev/data_vol/lv_web /var/www ext3 defaults,nosuid,nodev 1 2 /dev/sda1 /boot ext3 defaults,nosuid,noexec,nodev 1 2 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 /dev/_VG_OS/lv_swap swap swap defaults 0 0
Obviously you'll need to modify this example to suit your own system. LVM, volume names, labels etc are all subject to change. Please don't copy this example verbatim and expect it to work for you.
The webserver mount can also be set noexec, however this will impact cgi based applications, as well as server side includes which rely on the execute bit hack. If you're not using cgi applications, I would recommend at least testing noexec and using it if there are no negative side-effects.
Securing local filesystems
Securing the local filesystem deals with ownership of files and directories and access rights to them. To secure the filesystem, the protection bits of files and directories must set to grant minimum access only.
Take special care with respect to inappropriate permissions regarding world-writable files and system directories and so-called setuid or setgid commands. These commands are executed with higher user privileges than the user running the command actually has. This might be necessary to access files that only root has access to (such as /bin/passwd needs to access /etc/passwd). For each of these commands, make sure that it really needs the setuid/setgid bits set. If this is not the case, disable it.
When all files on a partition definitely do not need the setuid/setgid bits, the nosuid option in /etc/fstab disables it for each file on the corresponding filesystem (/dev/hdc1 in the following example):#device mountpoint filesystemtype options dump fsckorder /dev/hda1 / ext2 defaults 1 1 ... /dev/hdc1 /mnt/cdrom iso9660 nosuid,user 1 2
Furthermore, for very sensitive data, it might make sense to encrypt that data and protect it with a passphrase. GnuPG provides a suitable package to accomplish this.
|/||yes||yes||yes||yes||good idea||Ideally you should mount / totally restricted and then have directories like /boot/ separate, this also forces you to configure the directories properly since any "dangerous" directory (for example /dev/) will be "broken" (i.e. nodev would severely break /dev/). This is only recommended if you are going all out.|
|/boot/||yes||yes||yes||ok||good idea||Critical directory with kernel images, if an attacker replaces your kernel or deletes it you have a lot of problems.|
|/bin/||yes||no||no||ok||tricky||Directory with important system binaries, do not mount noexec or nosuid, your system will not work correctly. Mounting read-only will prevent trojans, and make updating software significantly more difficult.|
|/dev/||no||yes||yes||no||yes||Mounting /dev/ with the nodev option will severely break your system, as will mounting it read only. /dev/ is usually less then a few megs, and the ability to write to device files can result in huge damage, and system compromise.|
|/etc/||yes||yes||yes||no||tricky||Critical directory with system configuration information, usually the first target for an attacker. There should be no binaries in here (although some Unix systems do keep binaries in /etc/, Linux is not one of them). Mounting it read only will not allow you to change passwords, or other important settings so is not recommended.|
|/home/||yes||good idea||yes||no||yes||/home/ is the primary area where users keep their files and work with them (assuming they can log in), if you provide services like IMAP this is where their mail folders will be. You should make it a separate partition since users have a tendency of eating up space rapidly, as well it will prevent them from making hard links to files and then using setuid programs that dump core for example and wiping out system files. Mounting it noexec is probably a good idea, however depending on the type of work users do it may seriously hamper them, mounting it nosuid is a good idea and shouldn't really affect users.|
|/lib/||yes||no||yes||ok||good idea||Most programs will rely on libraries in this directory, if they are damaged or compromised you will have a hard time cleaning up. There are executable files in here (.so's, etc.), so setting it noexec would not be advised, but setting it nosuid is probably wise.|
|/mnt/||yes||good idea||good idea||ok||no need||/mnt/ is typically used to mount removable devices, such as /mnt/floppy/ or /mnt/cdrom, as such it rarely contains anything other then a few directories, making it separate is not a real issue since anything in it will be mounted as well.|
|/opt/||yes||no||no||no||good idea||Typically this directory is used for optional packages, vendor software and the like, oftentimes this stuff needs setuid bits to work properly (a good reason to separate it since a lot of vendors have terrible software security).|
|/proc/||/proc/ is a virtual filesystem|
|/root/||yes||no||no||no||good idea||root's private playground usually, many people use it instead of /usr/local/ when testing things/etc|
|/sbin/||yes||no||no||ok||tricky||Directory with other important system binaries, do not mount noexec or nosuid or you will break your system. Mounting read-only will prevent trojans, and make updating software significantly more difficult.|
|/tmp/||yes||yes||yes||no||yes||Temporary directory for use by users and system, mount read only will break things, make it separate because many exploits consist of making hard links in tmp to files, and then having a program misbehave and destroy/modify the target file maliciously. Binaries, especially setuid binaries should not be allowed in /tmp/ since any user can modify them usually.|
|/usr/||yes||no||no||ok||good idea||This directory is where the majority of software will be installed, along with source code and other stuff typically, mounting it separately is a good idea since it tends to contain relatively important software (especially in /usr/bin and /usr/sbin). Mounting it read only will prevent an attacker from inserting trojan software, but will make upgrades significantly harder. I wouldn't bother mounting it read only unless you also mount /bin/ and /sbin/ read only.|
|/var/||yes||yes||yes||no||yes||/var/ is used for a lot of things, least of which includes system logging. This partition should be separate since attackers can attempt to fill it up by flooding the log files, and other user data is stored here, such as mail (/var/spool/mail usually). Software that stores data here includes: Mail servers (Sendmail, Postfix, etc.), INN (Usenet news), Proxy software like Squid (WWW/FTP proxy), and so on. There should be no binaries at all here, just log files and data. Setting it noexec may break programs, Red Hat 7.0 places various binaries used for anonymous ftp with WuFTPD and arpwatch binaries in /var/ for example. You can place those files on another partition and symlink the directories to within /var/.|
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes. If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner.
ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least
Copyright © 1996-2016 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.
Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: September 12, 2017