Professional Documents
Culture Documents
Search Search
Search Search
com/archive/feature/113671
Linux.com
Search
Search Search
Articles
Case studies
Features
News
NewsVac
Reviews
Documentation
What Are Linux HOWTOs?
Where Can I Get Linux HOWTOs?
HOWTO Translations
Categorized List of HOWTOs
Single list of HOWTOs
Single list of mini-HOWTOs
Unmaintained HOWTOs
Writing and Submitting a HOWTO
Copyright Information
Distributions
Forums
About Us
What is Linux?
Download Linux
Feeds
Features
NewsVac
Forums
News
1 of 9 08/26/2010 05:17 PM
Linux.com :: Securing a fresh Linux install, part 2 http://www.linux.com/archive/feature/113671
Video
Comments
Special Offers
Linux
Application Dev
Programming
Software
Email:
Submit
Feature
Securing a fresh Linux install, part 2
In the first article in this series we began looking at ways to secure a new
Linux server, starting with locking down services. Next, let's look at securing
files and monitoring system logs.
SUID and SGID files
SUID and SGID files are executables which, when run by a normal user, may
have access to resources not normally available to the user running the
program. For example, an SUID program could have the permissions:
The s in the owner's permission field in place of the usual x indicates that
2 of 9 08/26/2010 05:17 PM
Linux.com :: Securing a fresh Linux install, part 2 http://www.linux.com/archive/feature/113671
/usr/sbin/foo is SUID. If run by a normal user, the executable will run with the
privileges of the owner of the file, in this case root. In this case the program
will have access to the same system resources as root.
Here there is an s in the place of the group's executable bit, meaning the file is
SGID and will be executed with the group permissions of the foo group.
This command finds all SUID or SGID files and lists them in a file called
SUID_files.txt. You can unset SUID or SGID privileges with the command chmod
-s /usr/sbin/foo, but be warned, unsetting the SUID or SGID bit on some
programs may mean that they will no longer run. Periodically check for new
files.
There should be no reason for users to have SUID files in their home
directories so you should use the nosuid option in /etc/fstab for the partition
containing users $HOME directories. For example:
Files should be world readable or writable only for very good reasons. You
should check for such files the way we did above for SGID and SUID files:
Again, check through the list and remove permissions from files that do not
need to be world readable or writable, and run checks regularly for new world
readable or writable files.
Ownerless files can be an indication that someone has gained access to your
system. You should check regularly using the command # find / -nouser -o -nogroup.
If you find any ownerless files, either delete them, or, if you know what they
are and wish to keep them, assign them to an appropriate user and group. For
3 of 9 08/26/2010 05:17 PM
Linux.com :: Securing a fresh Linux install, part 2 http://www.linux.com/archive/feature/113671
example, assign myfile to the user foo and the group bar you would issue the
command # chown foo.bar myfile
Using umask
The umask command can be used to determine the permissions given to newly
created files on your system. Addng the line umask 022 to the /etc/profile file tells
the system that any files created by users should have the permissions 0644,
or -rw-r--r--. This means users must explicitly make a file executable by using
chmod in their $HOME directory.
With chattr, root can set files to be read-only or append-only. Setting the
immutable bit (making a file read-only) ensures that a file cannot be altered,
even by root (of course root can remove the immutable bit and then alter the
file, so it's not watertight). Setting the append-only bit ensures that the
existing contents of a file cannot be changed, only added to. It is a good idea to
set the append-only bit on log files: # chattr +a /var/log/messages.
You can set the immutable bit to make it more difficult to replace important
executables or change critical configuration files:
# chattr +i /usr/bin/ps
# chattr +i /etc/services
The attributes of files set by chattr can be displayed using the lsattr utility.
System logs
In order to trace any unwanted activity on your computer, you should keep
complete and accurate logs. On Linux machines, logging is handled by the
syslog daemon, syslogd. Syslogd reads its configuration from the
/etc/syslog.conf file. You can set the facilities to be logged, the log priority, and
the files in which to log information here. The default values in most
distributions do not give you enough information.
4 of 9 08/26/2010 05:17 PM
Linux.com :: Securing a fresh Linux install, part 2 http://www.linux.com/archive/feature/113671
# Mark logs:
mark.* -/var/log/marklog
Note the dash before the log files' names. This tells syslogd not to sync after
every log. The disadvantage of this is that log information may be lost in the
event of a system crash. Removing the dash, however, can cause a performance
loss with heavy logging.
If you want to be able to track logs in real time, you can open a log file using
the command tail -f /var/log/messages. Alternatively you can have a permanent log
console by adding the line
*.* /dev/tty8
to the end of your syslog.conf file. This displays logs in real time on /dev/tty8.
(Be sure that tty8 exists, of course!)
In order to keep accurate logs, ensure that your system clock is accurate at all
times. You should look to using Network Time Protocol (NTP) to maintain your
system clock's accuracy. The easiest way to do this is to regularly run ntpdate
some.time.server from a cron job.
5 of 9 08/26/2010 05:17 PM
Linux.com :: Securing a fresh Linux install, part 2 http://www.linux.com/archive/feature/113671
Finally, although it's not really related to your system logs, make sure you
redirect root's mail to your normal user account so you don't miss any
important warning mail messages sent to root. You should do this either by
placing the line:
root: foo@mydomain.com
In the third and final part of this series we'll look at security considerations for
some important networking tools.
Related Links
Sponsored links:
Comments
Note: Comments are owned by the poster. We are not responsible for their
content.
6 of 9 08/26/2010 05:17 PM
Linux.com :: Securing a fresh Linux install, part 2 http://www.linux.com/archive/feature/113671
[URL=http://www.back.painreliefnetwork.net/lowbac<nobr>k<wbr></nobr>
pain.htm] Low back pain [/URL]
[URL=http://blog.gala.net/uploads/painreliefback/<nobr>b<wbr></nobr>
ackpainrelief.htm] Back pain relief [/URL]
[URL=http://www.weblog.ro/usercontent/13155/profi<nobr>l<wbr></nobr>
es/kneepainrelief.htm] Knee pain relief [/URL]
[URL=http://www.info.painreliefnetwork.net/Pain-R<nobr>e<wbr></nobr>
lief.html] Pain relief [/URL]
[URL=http://www.sitefights.com/community/scifi/pa<nobr>i<wbr></nobr>
nrelief/painreliefpreved.htm] Pain relief [/URL]
[URL=http://www.info.painreliefnetwork.net/Medica<nobr>t<wbr></nobr>
ion-Pain-Relief.html] Medication pain relief [/URL]
[URL=http://www.info.painreliefnetwork.net/Natura<nobr>l<wbr></nobr>
-Pain-Relief.html] Natural pain relief [/URL]
Corrections?
(1) World readable files are very common on Linux. It's world writable files
that should be rare. It is true if you want files private, like your home directory
7 of 9 08/26/2010 05:17 PM
Linux.com :: Securing a fresh Linux install, part 2 http://www.linux.com/archive/feature/113671
for example it should not be world readable -- and there are certain files
in<nobr> <wbr></nobr>/etc and elsewhere that should not be world readable
but ths is not a blanket statement.
(2) A umask of 022 seems just wrong to me. This is no security at all pretty
much. In fact it contradicts what you said a few paragraphs earlier about not
wanting world readable files. If you want security use 007, 027, or 077
depending on your needs, how you setup shares, and your group structure.
These are two basic mistakes. It makes me wonder how much the author really
knows about security. I think your articiles are about an important topic, but
please present the topic with a little more care.
Rob
8 of 9 08/26/2010 05:17 PM
Linux.com :: Securing a fresh Linux install, part 2 http://www.linux.com/archive/feature/113671
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya
9 of 9 08/26/2010 05:17 PM