Regardless of the type of firewall you deploy, you will have to test and
maintain it carefully.You need to actively monitor your firewall so that you can
discover scanning attacks, connection attempts, and general weaknesses. Of
course, you will have to scan your firewall to ensure that all extraneous ports
and daemons are closed.You can use a scanner such as Nessus (www.nessus.org) to
do this. However, even an application such as Nessus cannot implement the
specific attacks necessary to truly test your firewall. You may never know that
a hacker has entered your network unless you carefully monitor your firewall
logs. Doing so is sometimes an unglamorous, thankless job. However, using
applications such as Firedaemon and Fwlogwatch, you can receive automatic
alerts. Fwlogwatch can even automatically reconfigure your firewall for you in
case of a scanning attack. Even if you choose to not automatically block traffic
Testing Firewalls
Before you can start logging access to your
firewall, you need to ensure that you have configured it correctly in the first
place. Even if you have extensive experience configuring firewalls, you will
have to test your implementation when you first install it.
In fact,
experienced professionals know that they have to continually test a firewall to
ensure that it is properly configured, and that its current configuration
protects the network. It is not enough to just check or read the
Ipchains/Iptables rules and then think that you have properly tested the
firewall. You need to actively send packets and monitor your firewall and
internal network to be sure. Before you learn about applications that can help
you test your firewall, you first need to consider some of the actual attacks,
problems, and issues to look for. When testing your firewall, consider the
following: Internet Protocol (IP) spoofing Many hackers outside of the firewall
try to imitate internal network hosts in order to bypass authentication. Open
ports/daemons Many firewalls and/or routers allow unnecessary ports to remain
open, which can expose your firewall to threats unnecessarily. Monitoring system
hard drives, RAM, and processors If your firewall runs out of disk space, or
begins to run low on memory, your network may become incapacitated. Check your
servers performance regularly using standard tools (df, vmstat, top, and so
forth).
Suspicious users, logins, and login times Even if you allow only
interactive login at your firewall, monitor it carefully to determine who has
logged on. It is vital that you know exactly who is controlling the flow of
packets on your network. Check the rules database One of the common moves by a
hacker is to alter the rules database in subtle ways that make it easier for the
hacker to gain access to the network. Check your rules and compare them
carefully to ensure that no unauthorized changes have occurred.
Verify
connectivity After you have configured or reconfigured your firewall, make sure
that these changes do not cause problems for management and employees. Remain
informed concerning the operating system Bugs may be discovered in the kernel
and/or daemons that you are using. If you do not keep current concerning the
tools you are using, you may end up exposing yourself to hackers. Port scans If
you are relatively new to securing firewalls, you will be amazed to find out how
many times your firewall will be scanned. Logging all scans can consume an
unnecessary amount of hard drive space and processor time. Still, the proper
amount of logging will help you remain informed and will help you document scans
that may be preludes to an attack
IP Spoofing
Your firewall
should not allow any packets to pass from outside the network into your internal
network if the source address is the same as any host in your internal network.
Suppose, for example, that your external network interface card (NIC) has the IP
address of 128.1.2.3.4/16, and your internal NIC has the address of
192.168.1.0/24.You then need to find a way to test your firewall to see if any
traffic is passing through the external interface from, say, the 192.168.1.1 IP
address.
If such packets are able to traverse your firewall, then a
hacker can configure his or her system to use your firewall as a default gateway
and participate on your network. Leaving your packet-filtering firewall open to
spoofing attacks largely obviates the reason for having a firewall, so you
should take every step to test exactly what your firewall drops and allows. If
you require, for example, your end users to have access to the World Wide Web,
you will find that it is necessary to allow ephemeral ports (any port over 1023)
to access the Internet. However, if you are using private IP addresses (e.g.,
the 192.168.45.0 network), no system outside of the firewall should ever be able
to assume this IP address and access your internal networks ephemeral
ports.
Open Ports/Daemons
Your firewall should be as secure
as possible. Disable all unused services and con-figure the used ones with
security in mind. If you are running Squid or another proxy server on the
firewall, make sure that only this port is open. Daemons such as Telnet, File
Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP) and others should be
shut down in almost all situations. In many situations, you may require the
ability to remotely administer your firewall. Still, consider disabling all
login to the outside interface. In many situations, it is best to allow only
interactive logins at your firewall.
This way, you need only secure the
firewalls physical security. If you must, use only a relatively secure login
application, such as Secure Shell (SSH).You could also consider Kerberos,
although this requires you to open several additional ports. Even using one-
time passwords (OTP) at the firewall is a solution, although the use of OTP does
not encrypt the data that subsequently passes from your system to the router. If
you do need to leave certain ports open, be prepared to conduct regular scans of
your firewall to test the daemons listening on these ports. As suggested
earlier, applications such as Nessus (www.nessus.org) are ideal in this type of
situation.
Monitoring System Hard
Drives, RAM, and
Processors Firewall logs can consume hard drive space, especially in busy
networks. If you configured your firewall to log both accepted incoming and
outgoing access, you will find that your log files will grow very large in a
short period of time.You may need to cut back on your log settings. However, if
you cannot do this, regularly use the df -h command to discover the total amount
of hard drive space you have left.You could, for example, create a simple
crontab entry that sends you this information automatically every Monday at
8:05: 5 8 * * mon df -h | mail -s « HDRIVE » security.manager@yournetwork.com Of course, keeping the cron
daemon enabled on your firewall can present its own problems, because it will
require you to ensure that this daemon is not subject to bugs that can cause a
security problem.Any daemon, such as Cron, that acts automatically can cause
problems if misconfigured, so carefully review all default scripts, and you will
be in good shape. It is an additional service, after all.
You will have
to make the decision yourself. Following is a quick overview of standard Linux
tools that can help you determine if your system is becoming overburdened:
vmstat Informs you about the amount of random RAM and virtual RAM used on the
system. top Used to inform you about the processes that occupy the largest
percentage of CPU time.The busiest processes rise to the top of the display. The
Gtop and Ktop applications, both available from www.rpmfind.net, are graphical
versions that are somewhat easier to use than the original
Suspicious
Users, Logins, and Login Times
Use the who and last commands to learn
about who has logged in to the firewall. In addition, manually check the
/etc/passwd and /etc/shadow files to determine if any users have been added. An
application such as Tripwire can be extremely helpful if you wish to remain
informed about any changes to such files.
Check the Rules
Database
Determine if any unauthorized changes have been made to your
database.When you first created your firewall, you should have created a backup
using either the ipchains-save or iptables-save commands. Use the diff command
to compare the two files to see if any changes have occurred.You may also use
md5 to generate fingerprints of the configuration files to see whether any
unauthorized changes have been made to them.
Truly talented hackers are
interested in entering a network and then controlling it without your
knowledge.Accordingly, many will deactivate certain logging rules on your
firewall, and then activate them again. If you leave the ipchains or iptables
commands on your system, this will be very easy.To at least slow down the
hacker, try removing these applications from the system.This way, the hacker
will at least be forced to install these applications on your system before he
or she can manipulate it. If you have Tripwire installed, you will then be
informed of massive changes to the hard drive.
Management and End
Users
After you install your firewall, check with various managers
and employees to ensure that your firewall rules are working properly.You may
have to further adjust your firewall to ensure that the right services are
available to the company. You may have to inform people about certain services
that are no longer available by design. Otherwise, you will receive help desk
calls informing you that service has been interrupted. Employee education is
often necessary whenever you make any changes to the firewall. Otherwise, you
will receive complaints that the network is down, when in fact it is behaving
according to your design.
In order to cut down on ill will and employee
frustration, find ways to carefully and tactfully inform employees concerning
changes. Consider the following suggestions: Contact management and make sure
that they understand and agree with the changes you are making. Many times,
upper management will ask for certain changes and not quite understand how this
will affect the end user. Decisions to cut off certain services (e.g.,Web
traffic, or access to outside Post Office Protocol v3 [POP3] accounts) may
negatively affect the companys ability to conduct business, or may cause
unnecessary problems with employee morale. Make sure that upper management
understands the ramifications of any suggestions they make. Warn employees
before any changes to the security policy/firewall rules will occur. Remind
employees that changes have occurred. Use e-mail, word of mouth, and employee
area bulletin boards toremind people about changes.
Remain Informed
Concerning the Operating System
New bugs are found every day in any
operating system. It is possible that a bug may be found in Ipchains/Iptables or
the kernel that could be exploited. If you do not subscribe to the appropriate
mailing lists (see www.cert.org and www.sans.org), you should. It is also likely
that the version of Linux you are using has a newsgroup associated with it. The
following are some additional strategies: Join mailing lists associated with
your operating system. Carefully consider upgrades.
Update only when you
are certain that an upgrade enhances both your systems security and
functionality. Do not upgrade simply because an upgrade exists. Just because an
upgrade offers a new feature does not mean that this upgrade will allow your
system to remain secure. Added features often add complexity to your system, and
such changes open a security hole unless you take the time to properly study the
changes and alter your systems configuration. Network with fellow systems
administrators. Share your concerns and solutions with others.You will find that
doing so will greatly increase your awareness of the many security solutions
that exist.
Port Scans
Ipchains/Iptables-based firewalls
are classic examples of packet-filtering firewalls. This type of firewall has
traditionally been vulnerable to scanning attacks; they can simply allow scans
to occur without informing anyone, because packet filters generally do not pay
attention to Transmission Control Protocol (TCP)-based connections.They are
interested, rather, in filtering out IP addresses and ports (i.e., they pay
attention to the Network layer of the Open System Interconnection Reference
Model OSI/RM). The introduction of log analysis software such as Firelogd and
Fwlogdaemon have made it possible to detect and block such scans, all the while
sending an alert to the systems administrator.
This type of software can
help reduce a firewalls exposure to distributed denial-of- service (DDoS)
attacks, because it helps the firewall completely drop certain hosts. However,
this strategy introduces new problems, because it is possible for attackers to
spoof source IP addresses and assume the identity of hosts you trust.The result
is that hackers can use your own strategies against you and make your own
software conduct a DoS attack against you by blocking your network from its own
Domain Name System (DNS) servers, default gateways, and other hosts that you
trust implicitly. However, most adjunct software, such as Fwlogwatch, provides
ways to exclude trusted hosts from being blocked
Be first to comment this article
