Linux Security Measures [part 1]
Linux Security Measures
Part 1
Written By: Nitro
Email: noixtirdoe@aaahawk.com
2 July 2002
This is my first tutorial, and I decided to do it on something that I am currently
learning: linux security. Now the techniques/practices I use are not the only ones,
however, they are pretty common. The techniques/practices I use are also ones I
read about in various tutorials, so I will be incorporating some of the pieces from
the other tuts. You can look at my bibliography at the end of my tutorial to see
my resources.
+--------------------------------------------+
| Contents:
|
| 1. Shutting down services
| 2. Commenting-out startup scripts
| 3. Deleting default usernames
| 4. Permissions
| 5. SUID/SGID programs
| 6. Logs
| 7. IPV4 settings (brief overview)
| 8. Closing
| 9. Bibliography
+--------------------------------------------+
1. Shutting down services
First off, to find out what services we have running on our computer, we use the 'grep'
command. Example:
$ grep -v "^#" /etc/inetd.conf
By using the '-v' option of grep, we tell it to look for all lines that DO NOT match
"^#" in the file /etc/inetd.conf.
So in effect, grep outputs all of the lines in the inetd.conf file that are not commented
out, thus we get all the services running on our computer.
time
time
ftp
telnet
shell
login
talk
ntalk
pop3
finger
If you are just going to be a home user that surfs the internet, you probably don't want
all if any of these services running. So what do we do to get rid of the services we don't
want? Easy. You want to open /etc/inetd.conf in your text editor of choice (i.e., vi),
and put comments (#) on the lines where the services you don't want are. Example:
$ vi /etc/inetd.conf
#time
#time
#ftp
#telnet
#shell
#login
#talk
#ntalk
#pop3
#finger
See the "#" symbols in front of the services? You just commented them out, so now they
won't run.
Type (without quotes):
':wq'
to write (save) and quit vi. Now we need to restart inetd so our new settings take
effect:
$ ps -x # find /usr/bin/inetd's PID
PID TTY STAT TIME COMMAND
332 ? s 0:00 /usr/sbin/inetd
Ah, inetd's PID is 332. So how do we restart it? Check this out:
$ kill -HUP 332 # restarts /usr/sbin/inetd
There we go. Take a look at your services that are running now:
$ ps -x # see if the services we shutdown are still running...
Nope. They're not running anymore. That's a good thing.
2. Commenting-out startup scripts
In Linux, there is a directory called '/etc/rc.d' that holds the files that tells your
system what to run at boot time. All you have to do is comment-out the scripts you don't
need (just like we did for our Internet services).
3. Deleting default usernames
You really want to get rid of any default usernames that come with Linux. The only ones
you really need are 'root' (obviously) and your own usernames (and the usernames you
create). To delete usernames, do this (as root):
root# userdel -r <username>
This brings me to another security point. You are going to need to manage which users
you want to be able to 'su' up to root. My suggestion is to change the group that
/bin/su runs under (which is default 'root'). Second, you are going to want to change
the mode of /bin/su to something a little more secure; say something like an SUID root
file, root has read, write, and execute permissions, group 'wheel' has read and
execute permissions, while other users not in group 'wheel' have no access whatsoever.
How do we do that you ask? Like this:
root# /bin/chgrp wheel /bin/su
root# /bin/chmod 4750 /bin/su
Now 'su' will only be permitted to users in the group 'wheel' (and root of course).
So how do you change what groups users belong to? Well, you would use the
'usermod' program. However, you must add ALL the groups <user> belongs to first, then
you can add other groups. You have to remember to include all groups the user belongs
to, or he/she will only belong to one group. Here is the command you can use to modify
a user account:
root# usermod -G users,wheel,<other_groups> <username>
Also with this command, you must remember not to leave any whitespace in between groups
and commas. And that is how you can add users to different groups. Check out
'man usermod' for more information regarding this.
4. Permissions
File permissions are the heart and soul of Linux security. You don't want an unauthorized
user gaining access to a root file and modifying it, deleting it, or even backdooring your
binaries. You have to lock these down big time; one slip up and you might have a lot of
trouble on your hands. One thing you should change file permissions on are all of your
world-writable files/directories. You should really only have world-writable directories
and files in some rare conditions (i.e., your 'tmp' directories and 'tmp' files).
So how do we find world-writable files? Try this:
$ find / -perm -0002 -type f -ls
To find world-writable directories:
$ find / -perm -0002 -type d -ls
The 'find' command searches the root directory for files with world-writable permissions
(-perm -0002), searches for -type f (files), and on the second line searches for
-type d (directories), then the '-ls' tells find to output the results in the form of
'ls -dils'.
So let's say we found two world-writable files in the directory /home/nitro. They
are called 'linuxsecurity.txt' and 'testscript.txt'. (I am assuming /home/nitro
is our present directory).
-rw-rw-rw 1 nitro users 4096 Jul 2 10:34 linuxsecurity.txt
-rw-rw-rw 1 nitro users 4096 Jul 2 11:29 testscript.txt
As they are now, anybody in the group 'users' and anybody else who is not in group 'users'
can read and write to those files.
NOTE: if you don't know about permissions and how they are set up, I strongly recommend
that you 'man chmod' to learn more.
So, what permissions should we give to these files? I think we'll give the owner read
and write permissions, and everybody else has no access.
$ chmod 0600 linuxsecurity.txt testscript.txt
Do an 'ls -l' to see your new permissions:
$ ls -l
-rw------- 1 nitro users 4096 Jul 2 10:34 linuxsecurity.txt
-rw------- 1 nitro users 4096 Jul 2 13:56 testscript.txt
Now those files can only be read from and written to by the owner (in
this case, 'nitro'). You should go through your Linux OS and look at all the file
permissions and make modifications if you feel it's necessary.
5. SUID/SGID programs
I will start out by explaining what SUID (setuid) programs are. In short, they are
programs that run as a different user. So let's say user 'nitro' executes
/usr/sbin/traceroute; since traceroute is SUID root, nitro essentially is the root
user for as long as the program is running. Now having traceroute SUID root isn't
that big of a security risk, but I might make it 'chmod 4750' and change the group
to 'wheel' so only members of 'wheel' can execute the program as SUID root.
The main risk with letting anybody use SUID root programs is that you might get a
malicious user on your computer who has an exploit to overflow a buffer in a
SUID root program.
This is a little beyond the scope of this paper, however, I am talking about security
and SUID root programs; so what happens if a user runs a buffer overflow exploit on a
SUID root program? Well, the buffer will overflow with information and once that
happens, the malicious user can send commands via his/her exploit through the SUID root
program. The malicious user now has root access to your computer.
Going back to 'traceroute', I don't know of any times that someone wrote an exploit that
gained root access through it. So I'm pretty confident that you can keep traceroute
SUID root and not have very many problems, if any.
SGID programs are the same as SUID programs, just that instead of having different user
permissions while running the program, you have different group permissions.
What we need to do is find all SUID and SGID programs and if need be, alter them.
root# find / -type f -perm +6000 -ls
'find' looks in the root directory for all normal files with permissions of '6000'.
Permissions of '6000' means to look for SUID/SGID files (hopefully you read 'man chmod'
by now). '6000', in "human format" would be ---s--s--, however, since we told the
computer to find '-perm +6000', we are looking for any and all files with SUID/SGID set,
no matter if they are '-rwsrwsrwx' or '---s--s---'; we are looking for all files in
between those sets of permissions. Refer to 'man find' for more information.
Now that we have a list of SUID/SGID files, we can go through and 'chmod -s' all files
we don't think need to run as root.
Some files you can leave as SUID root are:
traceroute, ping, su, passwd, screen
6. Logs
By default, there are only two logs in Linux: 'syslog' and 'messages'. I am going to
show you how to make your own logs so you can log what you want.
Logs are made from two daemons: 'klogd' and 'syslogd'. 'klogd' intercepts and logs
linux kernel messages, and 'syslogd' logs all system messages. To configure your logs,
you must edit /etc/syslog.conf; this file tells 'syslogd' what to log and where to put
it.
Do a 'man syslog.conf' to learn more about the log configuration. Here is an example
of my own /etc/syslog.conf file:
# all info and notices
*.=info;*.=notice /usr/adm/messages
# all debug messages
*.=debug /usr/adm/debug
# all error messages
*.=err /usr/adm/syslog
# all alert messages sent directly to me
*.=alert root,nitro
# all emergency messages sent directly to me
*.=emerg root,nitro
# connections and logins
authpriv.*;auth.* /admin/nitro/auth.log
authpriv.*;auth.* /var/log/secure
# mail messages
mail.info;mail.notice /var/log/maillog
# daemon messages
daemon.info;daemon.notice /var/log/daemon.log
# send all logs to sys.log
*.* /admin/nitro/sys.log
I think it's pretty self-explanatory, I made my own logs to log what I wanted.
So now we have to make sure our logs are secure and can't be altered by anyone except
root. You should 'chmod 0660' or 'chmod 0600' all your logs so only root can write to
them. Then you should 'chattr +a' all of them so your logs can only be appended to.
Read 'man chattr' for more information. You also want to make your /etc/syslog.conf
file super-secure so no one can alter or even look at it to find out where your logs are.
I would suggest a 'chmod 0000' and a 'chattr +a' for /etc/syslog.conf; you can always
'chmod 0600' and 'chattr -a' when you (root) need to alter syslog.conf.
7. IPV4 settings
You can find the ipv4 settings in the /proc/sys/net/ipv4 directory. These files control
various things that have to do with the internet (ICMP, IP, TCP). I am going to list
some of the most common ones and tell you how to make them act the way you want. This
list isn't complete, but the ones I don't mention you can look up and learn about on
your own.
ICMP settings
--------------
icmp_echo_ignore_all:
If this option is set to '1' (on), it tells the kernel to ignore icmp echo requests.
If it is set to '0' (off), then it allows icmp echo requests. To enable this option,
type in your shell (as root):
root# echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all
This command writes a '1' to the icmp_echo_ignore_all file. To disable (to allow icmp echo
requests), type:
root# echo "0" > /proc/sys/net/ipv4/icmp_echo_ignore_all
icmp_echo_ignore_broadcasts:
If set to '1' (on), your computer will ignore icmp echo broadcasts. If you have this
set to '0', your computer may be used to receive icmp packets set to broadcast, and then
send them (like a router) to their destination. This could be abused by a malicious remote
user to use your computer as a gateway for sending DoS attacks through.
icmp_destunreach_rate:
A value of zero disables replying to packets that are trying to reach destinations
unreachable. Any positive number sets the maximum package rate in hundredths of seconds.
You should keep this disabled unless you are using this computer as a router.
icmp_echoreply_rate, icmp_paramprob_rate, and icmp_timeexceed_rate have the same
parameters as icmp_destunreach_rate.
IP settings
------------
ip_autoconfig:
This file is set to '1' if your computer received its IP configuration by RARP, BOOTP,
DHCP, or similar. Otherwise it's set to '0'.
ip_default_ttl:
Time to Live for IPV4 interfaces. Set to max number of hops a packet may travel.
Example:
root# echo "30" > /proc/sys/net/ipv4/ip_default_ttl
ip_dynaddr:
Enable dynamic IP addresses. Useful for dialup, but can be used with any connection
(as far as I know). '1' enables, '0' disables.
ip_forward:
Enable or disable the forwarding of packets between interfaces. Use this (enabled) if
your system is properly firewalled and is being used as a router/gateway between your
internal network and the Internet (or other network). For normal users, this should
be disabled (set to '0').
ip_local_port_range:
Range of ports used by TCP and UDP to choose a local port. Default range of ports is
1024-4999 (as all ports 0-1023 are reserved). To change:
root# echo "5000-10000" > /proc/sys/net/ipv4/ip_local_port_range
The range can be any numbers you want except the reserved ones.
ip_no_pmtu_disc:
Global switch to turn path MTU discovery off. '1' for no path MTU discovery, '0' to allow
path MTU discovery.
ip_masq_debug:
Enable/disable debugging of IP masquerading.
ipfrag_high_thresh and ipfrag_low_thresh:
Maximum memory used to reassemble IP fragments. When ipfrag_high_thresh bytes of memory
is allocated, the fragment handler will toss packets until ipfrag_low_thresh is reached.
ipfrag_time:
Time in seconds to keep an IP fragment in memory. Example:
root# echo "30" > /proc/sys/net/ipv4/ipfrag_time
TCP settings
-------------
tcp_retrans_collapse: On retransmit, try to send larger packets to work around bugs in
certain TCP stacks. Set to '0' to disable, '1' to enable.
tcp_keepalive_probes:
Number of 'keep alive' probes TCP sends out (when enabled) before it determines the
connection was lost.
tcp_keepalive_time:
How often TCP sends out 'keep alive' messages (when enabled). Default is two hours.
tcp_sack:
Select acknowledgements. Used to convey extended acknowledgement information from the
receiver to the sender over an established TCP connection. See RFC 2018 for more
information.
tcp_retries1:
Defines how often an answer to a TCP connection request is retransmitted before giving up.
tcp_retries2:
Defines how often a TCP packet is retransmitted before giving up.
tcp_timestamps:
Enable timestamps. See RFC 1323 section 3.2 for more information.
tcp_stdurg:
Enable the strict RFC 793 interpretation of the TCP urgent pointer field. Enabling this
option may lead to interoperability problems. It is disabled by default.
tcp_syncookies:
Send out 'syncookies' when the SYN backlog queue of a socket overflows. This prevents
SYN flood attacks when enabled. It is disable by default, so make sure you:
root# echo "1" > /proc/sys/net/ipv4/tcp_syncookies
to turn it on.
tcp_window_scaling:
See RFC 1323 for more information.
tcp_fin_timeout:
The amount of time in seconds it takes to receive a final FIN packet before the socket is
closed. Although it is a violation of the TCP specification, I doubt anyone will complain
because, when enabled, this option can prevent DoS attacks.
tcp_max_ka_probes:
Indicates how many keep alive probes are sent per slow timer run. Do not set it too high
or your probes will be sent in quick bursts.
tcp_max_syn_backlog:
Length of the per-socket backlog queue. When syncookies are enabled, the packets are still
answered and the maximum queue is ignored.
8. Closing
This is the end of my first tutorial on linux security; I hope that I can continue making
other parts to this tutorial, so if you have any feedback, questions, problems, requests
for what should be on my next tutorial, etc, just email me (noixtirdoe@aaahawk.com)
I hope you have learned alot, or if you are already an expert in linux security, I would
love to read your tuts as well ;)
9. Bibliography
a. Bronc Buster's tutorial on linux security. It can be found at:
http://hackersplayground.org/papers/linuxsecure.txt
b. IPV4 security.
http://hr.uoregon.edu/davidrl/Docume...stems/proc.txt
c. there are probably other places I got information from, just can't remember.
-Nitro-
the attachment is a copy of the tutorial...I put it here cuz the formatting is bad when I posted to AO lol
