So what is a "firewall"? It's a vague term that can mean
anything that acts as a protective barrier between us and the outside world.
This can be a dedicated system, or a specific application that provides this
functionality. Or it can be a combination of components, including various
combinations of hardware and software. Firewalls are built from
"rules" that are used to define what is allowed to enter and
exit a given system or network. Let's look at some of the possible components
that are readily available for Linux, and how we might implement a reasonably
safe firewalling strategy.
In Step 1 above, we have turned off all services we don't need. In our
example, there were a few we still needed to have running. In this
section, we will take the next step here and decide which we need to leave
open to the world. And which we might be able to restrict in some way. If we can
block them all, so much the better, but this is not always practical.
What we want to do now is restrict connections and traffic so that we only
allow the minimum necessary for whatever our particular situation is. In
some cases we may want to block all incoming "new" connection
attempts. Example: we want to run X, but don't
want anyone from outside to access it, so we'll block it completely from
outside connections. In other situations, we may want to limit, or restrict,
incoming connections to trusted sources only. The more restrictive, the
better. Example: we want to ssh into our system from
outside, but we only ever do this from our workplace. So we'll limit
sshd connections to our workplace address range. There are
various ways to do this, and we'll look at the most common ones.
We also will not want to limit our firewall to any one application. There is
nothing wrong with a "layered" defense-in-depth approach. Our
front line protection will be a packet filter -- either
ipchains or iptables
(see below). Then we can use additional tools and mechanisms to reinforce
our firewall.
We will include some brief examples. Our rule of thumb will be to deny
everything as the default policy, then open up just what we need. We'll try
to keep this as simple as possible since it can be an involved and complex
topic, and just stick to some of the most basic concepts. See the
Links section for further reading on this
topic.
"Packet filters" (like ipchains)
have the ability to look at individual packets, and make decisions based
on what they find. These can be used for many purposes. One common purpose
is to implement a firewall. Common packet filters on Linux are ipchains which
is standard with 2.2 kernels, and iptables which
is available with the more recent 2.4 kernels.
iptables has more advanced packet filtering
capabilities and is recommended for anyone running a 2.4 kernel. But either
can be effective for our purposes. ipfwadm is
a similar utility for 2.0 kernels (not discussed here).
If constructing your own ipchains or
iptables firewall rules seems a bit daunting,
there are various sites that can automate the process. See the
Links section. Also the included examples may be
used as a starting point.
And your distribution may be including a
utility of some kind for generating a firewall script.
This may be
adequate, but it is still recommended to know the proper syntax and
how the various mechanisms work as such tools rarely do more than a
few very simple rules.
| Various examples are given below. These are presented for illustrative
purposes to demonstrate some of the concepts being discussed here.
While they might also be useful as a starting point for your own
script, please note that they are not meant to be all encompassing.
You are strongly encouraged to understand how the scripts work, so
you can create something even more tailored for your own situation.
The example scripts are just protecting inbound connections to one interface
(the one connected to the Internet). This may be adequate for many simple
home type situations, but, conversely, this approach is not adequate for
all situations!
|
ipchains can be used with either 2.2 or 2.4
kernels. When ipchains is in place, it checks
every packet that moves through the system. The packets move across different
"chains", depending where they originate and where they are
going. Think of "chains" as rule sets. In advanced
configurations, we could define our own custom chains. The three default
built-in chains are input, which is incoming traffic,
output, which is outgoing traffic, and
forward, which is traffic being forwarded from one
interface to another (typically used for "masquerading").
Chains can be manipulated in various ways to control the flow of traffic in
and out of our system. Rules can be added at our discretion to achieve
the desired result.
At the end of every "chain" is a "target". The
target is specified with the -j option to the command. The
target is what decides the fate of the packet and essentially terminates that
particular chain. The most common targets are mostly self-explanatory:
ACCEPT, DENY,
REJECT, and MASQ.
MASQ is for "ipmasquerading".
DENY and REJECT essentially do the
same thing, though in different ways. Is one better than the other? That is
the subject of much debate, and depends on other factors that are beyond the
scope of this document. For our purposes, either should suffice.
ipchains has a very flexible configuration. Port
(or port ranges), interfaces, destination address, source address can be
specified, as well as various other options. The man page explains these
details well enough that we won't get into specifics here. Traffic entering our system from the Internet, enters via the
input chain. This is the one that we need as tight as we
can make it. Below is a brief example script for a hypothetical system. We'll let the
comments explain what this script does. Anything starting with a
"#" is a comment. ipchains rules
are generally incorporated into shell scripts, using shell variables to
help implement the firewalling logic.
#!/bin/sh
#
# ipchains.sh
#
# An example of a simple ipchains configuration.
#
# This script allows ALL outbound traffic, and denies
# ALL inbound connection attempts from the outside.
#
###################################################################
# Begin variable declarations and user configuration options ######
#
IPCHAINS=/sbin/ipchains
# This is the WAN interface, that is our link to the outside world.
# For pppd and pppoe users.
# WAN_IFACE="ppp0"
WAN_IFACE="eth0"
## end user configuration options #################################
###################################################################
# The high ports used mostly for connections we initiate and return
# traffic.
LOCAL_PORTS=`cat /proc/sys/net/ipv4/ip_local_port_range |cut -f1`:\
`cat /proc/sys/net/ipv4/ip_local_port_range |cut -f2`
# Any and all addresses from anywhere.
ANYWHERE="0/0"
# Let's start clean and flush all chains to an empty state.
$IPCHAINS -F
# Set the default policies of the built-in chains. If no match for any
# of the rules below, these will be the defaults that ipchains uses.
$IPCHAINS -P forward DENY
$IPCHAINS -P output ACCEPT
$IPCHAINS -P input DENY
# Accept localhost/loopback traffic.
$IPCHAINS -A input -i lo -j ACCEPT
# Get our dynamic IP now from the Inet interface. WAN_IP will be our
# IP address we are protecting from the outside world. Put this
# here, so default policy gets set, even if interface is not up
# yet.
WAN_IP=`ifconfig $WAN_IFACE |grep inet |cut -d : -f 2 |cut -d \ -f 1`
# Bail out with error message if no IP available! Default policy is
# already set, so all is not lost here.
[ -z "$WAN_IP" ] && echo "$WAN_IFACE not configured, aborting." && exit 1
# Accept non-SYN TCP, and UDP connections to LOCAL_PORTS. These are
# the high, unprivileged ports (1024 to 4999 by default). This will
# allow return connection traffic for connections that we initiate
# to outside sources. TCP connections are opened with 'SYN' packets.
$IPCHAINS -A input -p tcp -s $ANYWHERE -d $WAN_IP $LOCAL_PORTS ! -y -j ACCEPT
# We can't be so selective with UDP since that protocol does not
# know about SYNs.
$IPCHAINS -A input -p udp -s $ANYWHERE -d $WAN_IP $LOCAL_PORTS -j ACCEPT
## ICMP (ping)
#
# ICMP rules, allow the bare essential types of ICMP only. Ping
# request is blocked, ie we won't respond to someone else's pings,
# but can still ping out.
$IPCHAINS -A input -p icmp --icmp-type echo-reply \
-s $ANYWHERE -i $WAN_IFACE -j ACCEPT
$IPCHAINS -A input -p icmp --icmp-type destination-unreachable \
-s $ANYWHERE -i $WAN_IFACE -j ACCEPT
$IPCHAINS -A input -p icmp --icmp-type time-exceeded \
-s $ANYWHERE -i $WAN_IFACE -j ACCEPT
###################################################################
# Set the catchall, default rule to DENY, and log it all. All other
# traffic not allowed by the rules above, winds up here, where it is
# blocked and logged. This is the default policy for this chain
# anyway, so we are just adding the logging ability here with '-l'.
# Outgoing traffic is allowed as the default policy for the 'output'
# chain. There are no restrictions on that.
$IPCHAINS -A input -l -j DENY
echo "Ipchains firewall is up `date`."
##-- eof ipchains.sh
|
To use the above script would require that it is executable (i.e.
chmod +x ipchains.sh), and run by root to build the
chains, and hence the firewall.
To summarize what this example did was to start by setting some shell
variables in the top section, to be used later in the script. Then we set
the default rules (ipchains calls these "policies") of denying
all inbound and forwarded traffic, and of allowing all our own outbound
traffic. We had to open some holes in the high, unprivileged ports so
that we could have return traffic from connections that bigcat initiates to
outside addresses. If we connect to someone's web server, we want that HTML
data to be able to get back to us, for instance. The same applies to other
network traffic. We then allowed a few specific types of the ICMP protocol
(most are still blocked). We are also logging any inbound traffic that
violates any of our rules so we know who is doing what. Notice that we are
only using IP address here, not hostnames of any kind. This is so that
our firewall works, even in situation where there may be DNS failures.
Also, to prevent any kind of DNS spoofing.
See the ipchains man page for a full explanation
of syntax. The important ones we used here are:
-A input: Adds a rule to the
"input" chain. The default chains are input, output, and forward.
|
-p udp: This rule only applies to the
"UDP" "protocol". The -p
option can be used with tcp, udp or icmp protocols.
|
-i $WAN_IFACE: This rule applies to the specified
interface only, and applies to whatever chain is referenced (input, output,
or forward).
|
-s <IP address> [port]: This rule only
applies to the source address as specified. It can optionally have a port
(e.g. 22) immediately afterward, or port range, e.g. 1023:4999.
|
-d <IP address> [port]: This rule only
applies to the destination address as specified. Also, it may include port or
port range.
|
-l : Any packet that hits a rule with this option
is logged (lower case "L").
|
-j ACCEPT: Jumps to the "ACCEPT"
"target". This effectively terminates this chain
and decides the ultimate fate for this particular packet, which in this
example is to "ACCEPT" it. The same is
true for other -j targets like DENY.
|
By and large, the order in which command line options are specified is not
significant. The chain name (e.g. input) must come first
though.
Remember in Step 1 when we ran netstat, we had
both X and print servers running among other things. We don't want these
exposed to the Internet, even in a limited way. These are still happily
running on bigcat, but are now safe and sound behind our
ipchains based firewall. You probably have other
services that fall in this category as well.
The above example is a simplistic all or none approach. We allow all our own
outbound traffic (not necessarily a good idea), and block all inbound
connection attempts from outside. It is only protecting one interface, and
really just the inbound side of that interface. It would more than likely
require a bit of fine tuning to make it work for you. For a more advanced set
of rules, see the Appendix. And you might
want to read http://tldp.org/HOWTO/IPCHAINS-HOWTO.html.
Whenever you have made changes to your firewall, you should verify its
integrity. One step to make sure your rules seem to be doing what you
intended, is to see how ipchains has interpreted
your script. You can do this by opening your xterm
very wide, and issuing the following command:
# ipchains -L -n -v | less
|
The output is grouped according to chain. You should also find a way to scan
yourself (see the Verifying section below). And
then keep an eye on your logs to make sure you are blocking what is
intended.
iptables is the next generation packet filter for
Linux, and requires a 2.4 kernel. It can do everything
ipchains can, but has a number of noteworthy
enhancements. The syntax is similar to ipchains in
many respects. See the man page for details.
The most noteworthy enhancement is "connection tracking", also
known as "stateful inspection". This gives
iptables more knowledge of the state of each
packet. Not only does it know if the packet is a TCP or UDP packet, or
whether it has the SYN or ACK flags set, but also if it is part of an existing
connection, or related somehow to an existing connection. The implications
for firewalling should be obvious.
The bottom line is that it is easier to get a tight firewall with
iptables, than with
ipchains. So this is the recommended way to go.
Here is the same script as above, revised for
iptables:
#!/bin/sh
#
# iptables.sh
#
# An example of a simple iptables configuration.
#
# This script allows ALL outbound traffic, and denies
# ALL inbound connection attempts from the Internet interface only.
#
###################################################################
# Begin variable declarations and user configuration options ######
#
IPTABLES=/sbin/iptables
# Local Interfaces
# This is the WAN interface that is our link to the outside world.
# For pppd and pppoe users.
# WAN_IFACE="ppp0"
WAN_IFACE="eth0"
#
## end user configuration options #################################
###################################################################
# Any and all addresses from anywhere.
ANYWHERE="0/0"
# This module may need to be loaded:
modprobe ip_conntrack_ftp
# Start building chains and rules #################################
#
# Let's start clean and flush all chains to an empty state.
$IPTABLES -F
# Set the default policies of the built-in chains. If no match for any
# of the rules below, these will be the defaults that IPTABLES uses.
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -P INPUT DROP
# Accept localhost/loopback traffic.
$IPTABLES -A INPUT -i lo -j ACCEPT
## ICMP (ping)
#
# ICMP rules, allow the bare essential types of ICMP only. Ping
# request is blocked, ie we won't respond to someone else's pings,
# but can still ping out.
$IPTABLES -A INPUT -p icmp --icmp-type echo-reply \
-s $ANYWHERE -i $WAN_IFACE -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type destination-unreachable \
-s $ANYWHERE -i $WAN_IFACE -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type time-exceeded \
-s $ANYWHERE -i $WAN_IFACE -j ACCEPT
###################################################################
# Set the catchall, default rule to DENY, and log it all. All other
# traffic not allowed by the rules above, winds up here, where it is
# blocked and logged. This is the default policy for this chain
# anyway, so we are just adding the logging ability here with '-j
# LOG'. Outgoing traffic is allowed as the default policy for the
# 'output' chain. There are no restrictions on that.
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A INPUT -m state --state NEW -i ! $WAN_IFACE -j ACCEPT
$IPTABLES -A INPUT -j LOG -m limit --limit 30/minute --log-prefix "Dropping: "
echo "Iptables firewall is up `date`."
##-- eof iptables.sh
|
The same script logic is used here, and thus this does pretty much the same
exact thing as the ipchains script in the
previous section. There are some subtle differences as to syntax. Note the
case difference in the chain names for one (e.g. INPUT vs input). Logging is
handled differently too. It has its own "target" now
(-j LOG), and is much more flexible.
There are some very fundamental differences as well, that might not be so
obvious. Remember this section from the ipchains
script:
# Accept non-SYN TCP, and UDP connections to LOCAL_PORTS. These are the high,
# unprivileged ports (1024 to 4999 by default). This will allow return
# connection traffic for connections that we initiate to outside sources.
# TCP connections are opened with 'SYN' packets. We have already opened
# those services that need to accept SYNs for, so other SYNs are excluded here
# for everything else.
$IPCHAINS -A input -p tcp -s $ANYWHERE -d $WAN_IP $LOCAL_PORTS ! -y -j ACCEPT
# We can't be so selective with UDP since that protocol does not know
# about SYNs.
$IPCHAINS -A input -p udp -s $ANYWHERE -d $WAN_IP $LOCAL_PORTS -j ACCEPT
|
We jumped through hoops here with ipchains so
that we could restrict unwanted, incoming connections as much as possible. A
bit of a kludge, actually.
That section is missing from the iptables version.
It is not needed as connection tracking handles this quite nicely, and then
some. This is due to the "statefulness" of
iptables. It knows more about each packet than
ipchains. For instance, it knows whether the
packet is part of a "new" connection, or an
"established" connection, or a "related"
connection. This is the so-called "stateful inspection" of
connection tracking.
There are many, many features of iptables that
are not touched on here. For more reading on the Netfilter project and
iptables, see http://netfilter.samba.org.
And for a more advanced set of rules, see the Appendix.
Tcpwrappers provides much the same desired results
as ipchains and
iptables above, though works quite differently.
Tcpwrappers actually intercepts the connection
attempt, then examines its configurations files, and decides whether to
accept or reject the request. Tcpwrappers
controls access at the application level, rather than the socket level
like iptables and ipchains.
This can be quite effective, and is a standard component on most Linux
systems.
Tcpwrappers consists of the configuration
files /etc/hosts.allow and
/etc/hosts.deny. The functionality is provided by the
libwrap library.
Tcpwrappers first looks to see if access is
permitted in /etc/hosts.allow, and if so, access is
granted. If not in /etc/hosts.allow, the file
/etc/hosts.deny is then checked to see if access is
not allowed. If so, access is denied. Else,
access is granted. For this reason,
/etc/hosts.deny should contain only one uncommented
line, and that is: ALL: ALL. Access should then be
permitted through entries in /etc/hosts.allow, where
specific services are listed, along with the specific host addresses allowed
to access these services. While hostnames can be used here, use of hostnames
opens the limited possibility for name spoofing.
Tcpwrappers is commonly used to protect services
that are started via inetd (or
xinetd). But also any program
that has been compiled with libwrap support, can
take advantage of it. Just don't assume that all programs have built in
libwrap support -- they do not. In fact, most
probably don't. So we will only use it in our examples here to protect
services start via inetd. And then rely on our
packet filtering firewall, or other mechanism, to protect non-(x)inetd
services.
Below is a small snippet from a typical inetd.conf file:
# Pop and imap mail services et al
#
#pop-2 stream tcp nowait root /usr/sbin/tcpd ipop2d
#pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d
#imap stream tcp nowait root /usr/sbin/tcpd imapd
#
|
The second to last column is the tcpwrappers
daemon -- /usr/sbin/tcpd. Immediately after is the daemon
it is protecting. In this case, POP and
IMAP mail servers. Your distro probably has
already done this part for you. For the few applications that have built-in
support for tcpwrappers via the
libwrap library, specifying the daemon as above
is not necessary.
We will use the same principles here: default policy is to deny everything,
then open holes to allow the minimal amount of traffic necessary.
So now with your text editor, su to root and open
/etc/hosts.deny. If it does not exist, then create
it. It is just a plain text file. We want the following line:
If it is there already, fine. If not, add it in and then save and close file.
Easy enough. "ALL" is one of the keywords that
tcpwrappers understands. The format is
$SERVICE_NAME : $WHO, so we are denying all connections to
all services here. At least all services that are using
tcpwrappers. Remember, this will primarily be
inetd services. See man 5
hosts_access for details on the syntax of these files. Note the
"5" there!
Now let's open up just the services we need, as restrictively as we can,
with a brief example:
ALL: 127.0.0.1
sshd,ipop3d: 192.168.1.
sshd: .myworkplace.com, hostess.mymomshouse.com
|
The first line allows all "localhost" connections.
You will need this. The second
allows connections to the sshd and
ipop3d services from IP addresses that start with
192.168.1., in this case the private address range for
our hypothetical home LAN. Note the trailing ".". It's
important. The third line allows connections to only our
sshd daemon from any host associated with
.myworkplace.com. Note the leading "." in
this example. And then also, the single host
hostess.mymomshouse.com. In summary, localhost and all
our LAN connections have access to any and all tcpwrappered services on
bigcat. But only our workplace addresses, and our mother can use
sshd on bigcat from outside connections. Everybody
else is denied by the default policy in /etc/hosts.deny.
The types of wild cards above (.myworkplace.com and
192.168.1.) are not supported by
ipchains and iptables,
or most other Linux applications for that matter. Also,
tcpwrappers can use hostnames in place of
IP addresses which is quite handy in some situations. This does
not work with ipchains and
iptables.
You can test your tcpwrappers configuration
with the included tcpdchk utility (see the man page). Note
that at this time this does not work with xinetd,
and may not even be included in this case.
There is nothing wrong with using both tcpwrappers
and a packet filtering firewall like ipchains. In
fact, it is recommended to use a "layered" approach. This
helps guard against accidental misconfigurations. In this case, each
connection will be tested by the packet filter rules first, then
tcpwrappers.
Remember to make backup copies before editing system configuration files,
restart the daemon afterward, and then check the logs for error messages.
As mentioned, xinetd is an
enhanced inetd . It has much of the
same functionality, with some notable enhancements. One is that
tcpwrappers support can be
compiled in, eliminating the need for explicit references to
tcpd. Which means /etc/hosts.allow
and /etc/hosts.deny are automatically in effect.
Don't
assume this is the case though. A little testing, then viewing the logs
should be able to tell you whether tcpwrappers
support is automatic or not.
Some of xinetd's other enhancements: specify
IP address to listen on, which is a very effective method of access control;
limit the rate of incoming connections and the total number of simultaneous
connections; limit services to specific times of day. See the
xinetd and xinetd.conf
man pages for more details.
The syntax is quite different though. An example from
/etc/xinetd.d/tftp:
service tftp
{
socket_type = dgram
bind = 192.168.1.1
instances = 2
protocol = udp
wait = yes
user = nobody
only_from = 192.168.1.0
server = /usr/sbin/in.tftpd
server_args = /tftpboot
disable = no
}
|
Notice the bind statement. We are only listening on,
or "binding" to, the private, LAN interface here. No outside
connections can be made since the outside port is not even opened. We are
also only accepting connections from 192.168.1.0, our LAN.
For xinetd's purposes, this denotes any IP
address beginning with "192.168.1". Note that the syntax is different
from inetd. The server
statement in this case is the tftp daemon,
in.tftpd. Again, this assumes that
libwrap/tcpwrappers support is compiled into
xinetd. The user running the
daemon will be "nobody". Yes, there is a user account called
"nobody", and it is wise to run such daemons as non-root users
whenever possible. Lastly, the disable statement is
xinetd's way of turning services on or off. In
this case, it is "on". This is on here only as an example. Do
NOT run tftp as a public service as it is unsafe.
Portsentry
works quite differently than the other tools discussed so far.
Portsentry does what its name implies --
it guards ports. Portsentry is configured with the
/etc/portsentry/portsentry.conf file.
Unlike the other applications discussed above, it does this by actually
becoming the listening server on those ports. Kind of like baiting a trap.
Running netstat -taup as root while
portsentry is running, will show
portsentry as the LISTENER on
whatever ports portsentry is configured for. If
portsentry senses a connection attempt, it blocks
it completely. And then goes a step further and blocks the route to that host
to stop all further traffic. Alternately, ipchains
or iptables can be used to block the host
completely. So it makes an excellent tool to stop port scanning of a range of
ports.
But portsentry has limited flexibility as to
whether it allows a given connection. It is pretty much all or nothing. You
can define specific IP addresses that it will ignore in
/etc/portsentry/portsentry.ignore. But you cannot allow
selective access to individual ports. This is because only one server can
bind to a particular port at the same time, and in this case that is
portsentry itself. So it has limited usefulness as a
stand-alone firewall. As part of an overall firewall strategy, yes, it can
be quite useful. For most of us, it should not be our first line of defense,
and we should only use it in conjunction with other tools.
Suggestion on when portsentry might be useful:
As a second layer of defense, behind either
ipchains or iptables.
Packet filtering will catch the packets first, so that anything that gets
to portsentry would indicate a misconfiguration.
Do not use in conjunction with inetd services --
it won't work. They will butt heads.
As a way to catch full range ports scans. Open a pinhole or two in the
packet filter, and let portsentry catch these
and re-act accordingly.
If you are very sure you have no exposed public servers
at all, and you just want to know who is up to what. But do not assume
anything about what portsentry is protecting.
By default it does not watch all ports, and may even leave some very
commonly probed ports open. So make sure you configure it accordingly.
And make sure you have tested and verified your set up first, and that
nothing is exposed.
All in all, the packet filters make for a better firewall.
The dictionary defines "proxy" as "the authority or power
to act on behalf of another". This pretty well describes software proxies as
well. It is an intermediary in the connection path. As an example, if we
were using a web proxy like "squid" (http://www.squid-cache.org/),
every time we browse to a web site, we
would actually be connecting to our locally running squid server.
Squid in turn, would relay our request to the ultimate, real destination. And
then squid would relay the web pages back to us. It is
a go-between. Like "firewalls", a "proxy" can refer
to either a specific application, or a dedicated server which runs a proxy
application.
Proxies can perform various duties, not all of which have much to do with
security. But the fact that they are an intermediary, makes them a good place
to enforce access control policies, limit direct connections through a
firewall, and control how the network behind the proxy looks to the Internet.
So this makes them strong candidates to be part of an overall firewall
strategy. And, in fact, are sometimes used instead of packet filtering
firewalls. Proxy based firewalls probably make more sense where many users
are behind the same firewall. And it probably is not high on the list of
components necessary for home based systems.
Configuring and administering proxies can be complex, and is beyond the scope of
this document. The Firewall and Proxy Server HOWTO, http://tldp.org/HOWTO/Firewall-HOWTO.html, has examples
of setting up proxy firewalls. Squid usage is discussed at
http://squid-docs.sourceforge.net/latest/html/book1.htm
Some servers may have their own access control features. You should check
this for each server application you run. We'll only look at a few of the
common ones in this section. Man pages, and other application specific
documentation, is your friend here. This should be done whether you have
confidence in your firewall or not. Again, layers
of protection is always best.
BIND - a very common package that provides name
server functionality. The daemon itself is "named". This only
requires full exposure to the Internet if you are providing DNS look ups
for one or more domains to the rest of the world. If you are not sure what
this means, you do not need, or want, it exposed. For
the overwhelming majority of us this is the case. It is a very common
crack target.
But it may be installed, and can be useful in a caching only mode. This
does not require full exposure to the Internet. Limit the interfaces
on which it "listens" by editing
/etc/named.conf (random example shown):
options {
directory "/var/named";
listen-on { 127.0.0.1; 192.168.1.1; };
version "N/A";
};
|
The "listen-on" statement is what limits where named
listens for DNS queries. In this example, only on localhost and bigcat's
LAN interface. There is no port open for the rest of the world. It just
is not there. Restart named after making changes.
X11 can be told not to allow TCP connections by using the
-nolisten tcp command line option. If using
startx, you can make this automatic by placing
alias startx="startx -- -nolisten tcp" in your
~/.bashrc, or the system-wide file,
/etc/bashrc, with your text editor. If using
xdm (or variants such as
gdm, kdm, etc),
this option would be specified in
/etc/X11/xdm/Xservers (or comparable) as
:0 local /usr/bin/X11/X -nolisten tcp.
gdm actually uses
/etc/X11/gdm/gdm.conf.
If using xdm (or comparable) to start X
automatically at boot, /etc/inittab can
be modified as: xdm -udpPort 0, to further
restrict connections. This is typically near the bottom of
/etc/inittab.
Recent versions of sendmail can be told to
listen only on specified addresses:
# SMTP daemon options
O DaemonPortOptions=Port=smtp,Addr=127.0.0.1, Name=MTA
|
The above excerpt is from /etc/sendmail.cf which can
be carefully added with your text editor. The
sendmail.mc directive is:
dnl This changes sendmail to only listen on the loopback device 127.0.0.1
dnl and not on any other network devices.
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')
|
In case you would prefer to build a new sendmail.cf,
rather than edit the existing one. Other mail server daemons likely have
similar configuration options. Check your local documentation.
SAMBA connections can be restricted in
smb.conf:
bind interfaces = true
interfaces = 192.168.1. 127.
hosts allow = 192.168.1. 127.
|
This will only open, and allow, connections from localhost (127.0.0.1),
and the local LAN address range. Adjust the LAN address as needed.
The CUPS print daemon can be told where
to listen for connections. Add to /etc/cups/cupsd.conf:
This will only open a port at the specified address and port number.
xinetd can force daemons to listen only
on a specified address with its "bind" configuration
directive. For instance, an internal LAN interface address.
See man xinetd.conf for this and other syntax.
There are various other control mechanisms as well.
As always, anytime you make system changes, backup the configuration file
first, restart the appropriate daemon afterward, and then check the
appropriate logs for error messages. The final step after getting your firewall in place, is to verify that it
is doing what you intended. You would be wise to do this anytime you make
even minor changes to your system configuration. So how to do this? There are several things you can do. For our packet filters like ipchains and
iptables, we can list all our rules, chains,
and associated activity with iptables -nvL | less
(substitute ipchains if appropriate). Open
your xterm as wide as possible to avoid wrapping long lines. This should give you an idea if your chains are doing what you think they
should. You may want to perform some of the on-line tasks you normally do
first: open a few web pages, send and retrieve mail, etc. This will, of
course, not give you any information on tcpwrappers or
portsentry. tcpdchk can
be used to verify tcpwrappers configuration
(except with xinetd).
And then, scan yourself. nmap is the scanning
tool of choice and may be available via your distribution
, or from
http://www.insecure.org/nmap/nmap_download.html. nmap is very
flexible, and essentially is a "port prober". In other words,
it looks for open ports, among other things. See the
nmap man page for details.
If you do run nmap against yourself (e.g.
nmap localhost), this should tell you what ports are
open -- and visible locally only! Which hopefully by now, is
quite different from what can be seen from the outside. So, scan yourself,
and then find a trusted friend, or site (see the Links
section), to scan you from the outside. Make sure you are not
violating your ISPs Terms of Service by port scanning. It may not be allowed,
even if the intentions are honorable. Scanning from outside is the best way
to know how the rest of the world sees you. This should tell you how well
that firewall is working. See the nmap section in
the Appendix for some examples on nmap usage.
One caveat on this: some ISPs may filter some ports, and you will not know
for sure how well your firewall is working. Conversely, they make it look
like certain ports are open by using web, or other, proxies. The scanner
may see the web proxy at port 80 and mis-report it as an open port on your
system.
Another option is to find a website that offers full
range testing. http://www.hackerwhacker.com is
one such site. Make sure that any such site is not just scanning a relatively
few well known ports.
Repeat this procedure with every firewall change, every system upgrade or new
install, and when any key components of your system changes.
You may also want to enable logging all the denied traffic. At least
temporarily. Once the firewall is verified to be doing what you think it
should, and if the logs are hopelessly overwhelming, you may want to disable
logging.
If relying on portsentry at all, please read the
documentation. Depending on your configuration it will either drop the
route to the scanner, or implement a
ipchains/iptables rule
doing the same thing. Also, since it "listens" on the
specified ports, all those ports will show as "open". A false
alarm in this case.
Linux does a lot of logging. Usually to more than one file. It is not always
obvious what to make of all these entries -- good, bad or indifferent? Firewall
logs tend to generate a fair amount of each. Of course, you are wanting to
stop only the "bad", but you will undoubtedly catch some
harmless traffic as well. The 'net has a lot of background noise.
In many cases, knowing the intentions of an incoming packet are almost
impossible. Attempted intrusion? Misbehaved protocol? Mis-typed IP address?
Conclusions can be drawn based on factors such as destination port, source
port, protocol, and many other variables. But there is no substitute for
experience in interpreting firewall logs. It is a black art in many cases.
So do we really need to log? And how much should we be trying to log? Logging
is good in that it tells us that the firewall is functional. Even if we
don't understand much of it, we know it is doing "something".
And if we have to, we can dig into those logs and find whatever data might be
called for.
On the other hand, logging can be bad if it is so excessive, it is difficult
to find pertinent data, or worse, fills up a partition. Or if we over re-act
and take every last entry as an all out assault. Some perspective is a great
benefit, but something that new users lack almost by definition. Again, once
your firewall is verified, and you are perplexed or overwhelmed, home
desktop users may want to disable as much logging as possible. Anyone with
greater responsibilities should log, and then find ways to extract the
pertinent data from the logs by filtering out extraneous information.
Not sure where to look for log data? This could conceivably be
many places depending on how your distribution configured the various daemons
and syslogd. Most logging is done in
/var/log/*. Check that directory with ls -l
/var/log/ and see if you can tell the most active logs by size and
timestamp. Also, look at /etc/syslog.conf to see where
the default logs are. /var/log/messages is a good place
to look for starters.
Portsentry and tcpwrappers
do a certain amount of logging that is not adjustable.
xinetd has logging enhancements that can be turned
on. Both ipchains and
iptables, on the other hand, are very flexible as
to what is logged. For ipchains the -l option can
be added to any rule. iptables uses the
-j LOG target, and requires its own, separate rule instead.
iptables goes a few steps further and allows
customized log entries, and rate limiting. See the man page. Presumably, we
are more interested in logging blocked traffic, so we'd confine logging to
only our DENY and REJECT rules.
So whether you log, and how much you log, and what you do with the logs, is
an individual decision, and probably will require some trial and error so
that it is manageable. A few auditing and analytical tools can be quite
helpful:
Some tools that will monitor your logs for you and notify you when necessary.
These likely will require some configuration, and trial and error, to make
the most out of them:
Let's take a quick look at where to run our firewall scripts from. Portsentry can be run as an init process, like
other system services. It is not so important when this is done.
Tcpwrappers will be automatically be invoked by
inetd or xinetd, so not
to worry there either.
But the packet filtering scripts will have to be started somewhere. And many
scripts will have logic that uses the local IP address. This will mean that
the script must be started after the interface has come up and been assigned
an IP address. Ideally, this should be immediately after the interface is up.
So this depends on how you connect to the Internet. Also, for protocols like
PPP or DHCP that may
be dynamic, and get different IP's on each re-connect, it is best to have
the scripts run by the appropriate daemon.
For PPP, you probably have an
/etc/ppp/ip-up file. This will be executed every
time there is a connect or re-connect. You should put the full path to your
firewall script here. Check the local documentation for the correct
location. Debian use files in /etc/ppp/ip-up.d/, so
either put the script itself there, or a symlink to it. Red Hat uses
/etc/ppp/ip-up.local for any user defined, local
PPP configuration.
For DHCP, it depends on which client.
dhcpcd will execute
/etc/dhcpcd/dhcpcd-<interface>.exe (e.g.
dhcpcd-eth0.exe) whenever a lease is obtained or renewed. So this is where to
put a reference to your firewall script. For
pump, the main
configuration file is /etc/pump.conf.
Pump will run whatever script is defined by the
"script" statement any time there is a new or renewed lease:
script /usr/local/bin/ipchains.sh
|
If you have a static IP address (i.e. it never changes), the placement is not
so important and should be before the interface comes
up! In this section we looked at various components that might be used to
construct a "firewall". And learned that a firewall is as
much a strategy and combination of components, as it is any one particular
application or component. We looked at a few of the most commonly available
applications that can be found on most, if not all, Linux systems. This is
not a definitive list. This is a lot of information to digest at all at one time and expect anyone
to understand it all. Hopefully this can used as a starting point, and
used for future reference as well. The packet filter firewall examples can be
used as starting points as well. Just use your text editor, cut and paste
into a file with an appropriate name, and then run chmod
+x against it to make it executable. Some minor editing of the
variables may be necessary. Also look at the Links section for sites and utilities that can be
used to generate a custom script. This may be a little less daunting.
Now we are done with Steps 1, 2 and 3. Hopefully by now you have already
instituted some basic measures to protect your system(s) from the various and
sundry threats that lurk on networks. If you haven't implemented any of the
above steps yet, now is a good time to take a break, go back to the top, and
have at it. The most important steps are the ones above.
A few quick conclusions... "What is best iptables,
ipchains, tcpwrappers,
or portsentry?" The quick answer is that
iptables can do more than any of the others. So
if you are using a 2.4 kernel, use
iptables. Then,
ipchains if using a 2.2 kernel. The long answer is
"it just depends on what you are doing and what the objective
is". Sorry. The other tools all have some merit in any given
situation, and all can be effective in the right situation.
"Do I really need all these packages?" No, but please combine
more than one approach, and please follow all the above recommendations.
iptables by itself is good, but in conjunction
with some of the other approaches, we are even stronger. Do not rely on any
single mechanism to provide a security blanket. "Layers" of
protection is always best. As is sound administrative practices. The best
iptables script in the world is but one piece of
the puzzle, and should not be used to hide other system weaknesses.
"If I have a small home LAN, do I need to have a firewall on each
computer?" No, not necessary as long as the LAN gateway has a properly
configured firewall. Unwanted traffic should be stopped at that point. And as
long as this is working as intended, there should be no unwanted traffic on
the LAN. But, by the same token, doing this certainly does no harm. And on
larger LANs that might be mixed platform, or with untrusted users, it would
be advisable.
|
|