This is a description of the kernel configuration options that relate to security, and an explanation of what they do, and how to use them.
As the kernel controls your computer's networking, it is important that it be very secure, and not be compromised. To prevent some of the latest networking attacks, you should try to keep your kernel version current. You can find new kernels at ftp://ftp.kernel.org or from your distribution vendor.
There is also a international group providing a single unified crypto patch to the mainstream Linux kernel. This patch provides support for a number of cryptographic subsystems and things that cannot be included in the mainstream kernel due to export restrictions. For more information, visit their web page at: http://www.kerneli.org
For 2.0.x kernels, the following options apply. You should see these
options during the kernel configuration process. Many of the comments
here are from ./linux/Documentation/Configure.help
, which is
the same document that is referenced while using the Help facility during
the make config
stage of compiling the kernel.
This option should be on if you intend to run any firewalling or masquerading on your Linux machine. If it's just going to be a regular client machine, it's safe to say no.
If you enable IP forwarding, your Linux box essentially becomes a router. If your machine is on a network, you could be forwarding data from one network to another, and perhaps subverting a firewall that was put there to prevent this from happening. Normal dial-up users will want to disable this, and other users should concentrate on the security implications of doing this. Firewall machines will want this enabled, and used in conjunction with firewall software.
You can enable IP forwarding dynamically using the following command:
root# echo 1 > /proc/sys/net/ipv4/ip_forward
and disable it with the command:
root# echo 0 > /proc/sys/net/ipv4/ip_forward
Keep in mind the files in /proc are "virtual" files and the shown size
of the file might not reflect the data output from it.
a "SYN Attack" is a denial of service (DoS) attack that consumes all the resources on your machine, forcing you to reboot. We can't think of a reason you wouldn't normally enable this. In the 2.2.x kernel series this config option merely allows syn cookies, but does not enable them. To enable them, you have to do:
root# echo 1 > /proc/sys/net/ipv4/tcp_syncookies <P>
This option is necessary if you are going to configure your machine as a firewall, do masquerading, or wish to protect your dial-up workstation from someone entering via your PPP dial-up interface.
This option gives you information about packets your firewall received, like sender, recipient, port, etc.
This option should be enabled. Source routed frames contain the entire path to their destination inside of the packet. This means that routers through which the packet goes do not need to inspect it, and just forward it on. This could lead to data entering your system that may be a potential exploit.
Generally this option is disabled, but if you are building a firewall or a masquerading host, you will want to enable it. When data is sent from one host to another, it does not always get sent as a single packet of data, but rather it is fragmented into several pieces. The problem with this is that the port numbers are only stored in the first fragment. This means that someone can insert information into the remaining packets that isn't supposed to be there. It could also prevent a teardrop attack against an internal host that is not yet itself patched against it.
This is an option that is available in the 2.2.x kernel series that will sign NCP packets for stronger security. Normally you can leave it off, but it is there if you do need it.
This is a really neat option that allows you to analyze the first 128 bytes of the packets in a user-space program, to determine if you would like to accept or deny the packet, based on its validity.
For 2.2.x kernels, many of the options are the same, but a few new
ones have been developed. Many of the comments here are from
./linux/Documentation/Configure.help
, which is the same
document that is referenced while using the Help facility during
the make config
stage of compiling the kernel. Only the newly-
added options are listed below. Consult the 2.0 description for a
list of other necessary options. The most significant change in the
2.2 kernel series is the IP firewalling code. The ipchains
program is now used to install IP firewalling, instead of the
ipfwadm
program used in the 2.0 kernel.
For most people, it's safe to say no to this option. This option allows you to connect a user-space filter to any socket and determine if packets should be allowed or denied. Unless you have a very specific need and are capable of programming such a filter, you should say no. Also note that as of this writing, all protocols were supported except TCP.
Port Forwarding is an addition to IP Masquerading which allows some forwarding of packets from outside to inside a firewall on given ports. This could be useful if, for example, you want to run a web server behind the firewall or masquerading host and that web server should be accessible from the outside world. An external client sends a request to port 80 of the firewall, the firewall forwards this request to the web server, the web server handles the request and the results are sent through the firewall to the original client. The client thinks that the firewall machine itself is running the web server. This can also be used for load balancing if you have a farm of identical web servers behind the firewall.
Information about this feature is available from http://www.monmouth.demon.co.uk/ipsubs/portforwarding.html (to browse the WWW, you need to have access to a machine on the Internet that has a program like lynx or Netscape). For general info, please see ftp://ftp.compsoc.net/users/steve/ipportfw/linux21/
Using this option, user-space programs can attach a filter to any
socket and thereby tell the kernel that it should allow or disallow
certain types of data to get through the socket. Linux socket
filtering works on all socket types except TCP for now. See the
text file ./linux/Documentation/networking/filter.txt
for
more information.
The 2.2 kernel masquerading has been improved. It provides additional support for masquerading special protocols, etc. Be sure to read the IP Chains HOWTO for more information.
There are a few block and character devices available on Linux that will also help you with security.
The two devices /dev/random
and /dev/urandom
are provided by the
kernel to provide random data at any time.
Both /dev/random
and /dev/urandom
should be secure enough to use in
generating PGP keys, ssh
challenges, and other applications where
secure random numbers are required. Attackers should be unable to
predict the next number given any initial sequence of numbers from these
sources. There has been a lot of effort put in to ensuring that the
numbers you get from these sources are random in every sense of the word.
The only difference between the two devices, is that /dev/random
runs out of random bytes
and it makes you wait for more to be accumulated. Note that on some
systems, it can block for a long time waiting for new user-generated
entropy to be entered into the system. So you have to use care before
using /dev/random
. (Perhaps the best thing to do is to use it when
you're generating sensitive keying information, and you tell the user to
pound on the keyboard repeatedly until you print out "OK, enough".)
/dev/random
is high quality entropy, generated from measuring the
inter-interrupt times etc. It blocks until enough bits of random data
are available.
/dev/urandom
is similar, but when the store of entropy is running low,
it'll return a cryptographically strong hash of what there is. This
isn't as secure, but it's enough for most applications.
You might read from the devices using something like:
root# head -c 6 /dev/urandom | mimencode
This will print six random characters on the console, suitable for
password generation. You can find mimencode
in the metamail
package.
See /usr/src/linux/drivers/char/random.c
for a description of the
algorithm.
Thanks to Theodore Y. Ts'o, Jon Lewis, and others from Linux-kernel for helping me (Dave) with this.