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 � 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: https://www.kerneli.org/
7.1. 2.0 Kernel Compile Options
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.
Network Firewalls (CONFIG_FIREWALL)
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.
IP: forwarding/gatewaying (CONFIG_IP_FORWARD)
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.
IP: syn cookies (CONFIG_SYN_COOKIES)
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:
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.
IP: Drop source routed frames (CONFIG_IP_NOSR)
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.
IP: masquerading (CONFIG_IP_MASQUERADE) If one of the computers on your
local network for which your Linux box acts as a firewall wants to send
something to the outside, your box can "masquerade" as that host, i.e., it
forewords the traffic to the intended destination, but makes it look like it
came from the firewall box itself. See https://www.indyramp.com/masq for more information.
IP: ICMP masquerading (CONFIG_IP_MASQUERADE_ICMP) This option adds ICMP
masquerading to the previous option of only masquerading TCP or UDP traffic.
IP: transparent proxy support (CONFIG_IP_TRANSPARENT_PROXY) This enables
your Linux firewall to transparently redirect any network traffic originating
from the local network and destined for a remote host to a local server,
called a "transparent proxy server". This makes the local computers think they
are talking to the remote end, while in fact they are connected to the local
proxy. See the IP-Masquerading HOWTO and https://www.indyramp.com/masq for more information.
IP: always defragment (CONFIG_IP_ALWAYS_DEFRAG)
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.
Packet Signatures (CONFIG_NCPFS_PACKET_SIGNING)
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.
7.2. 2.2 Kernel Compile Options
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.
Socket Filtering (CONFIG_FILTER)
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
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
https://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/
Socket Filtering (CONFIG_FILTER)
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.
IP: Masquerading
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.
7.3. Kernel Devices
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.
[an error occurred while processing this directive]
