|
|
| Home > LAN > |
Firewalls FAQ |
Section 2 of 4 - Prev - Next
All sections - 1 - 2 - 3 - 4
data or passwords being sniffed.
3.3 What are proxy servers and how do they work?
A proxy server (sometimes referred to as an application gateway or
forwarder) is an application that mediates traffic between a protected
network and the Internet. Proxies are often used instead of router-based
traffic controls, to prevent traffic from passing directly between networks.
Many proxies contain extra logging or support for user authentication. Since
proxies must ``understand'' the application protocol being used, they can
also implement protocol specific security (e.g., an FTP proxy might be
configurable to permit incoming FTP and block outgoing FTP).
Proxy servers are application specific. In order to support a new protocol
via a proxy, a proxy must be developed for it. One popular set of proxy
servers is the TIS Internet Firewall Toolkit (``FWTK'') which includes
proxies for Telnet, rlogin, FTP, X-Window, HTTP/Web, and NNTP/Usenet news.
SOCKS is a generic proxy system that can be compiled into a client-side
application to make it work through a firewall. Its advantage is that it's
easy to use, but it doesn't support the addition of authentication hooks or
protocol specific logging. For more information on SOCKS, see
http://www.socks.nec.com/.
3.4 What are some cheap packet screening tools?
The Texas AMU security tools include software for implementing screening
routers. Karlbridge is a PC-based screening router kit available from
ftp://ftp.net.ohio-state.edu/pub/kbridge/. A version of the Digital
Equipment Corporation ``screend'' kernel screening software is available for
BSD-derived operating systems. There are numerous kernel-level packet
screens, including ipf, ipfw, and ipfwadm. Typically, these are included in
various free Unix implementations, such as FreeBSD, OpenBSD, NetBSD, and
Linux. You might also find these tools available in your commercial Unix
implementation. If you're willing to get your hands a little dirty, it's
completely possible to build a secure and fully functional firewall for the
price of hardware and some of your time.
3.5 What are some reasonable filtering rules for a kernel-based packet
screen?
This example is written specifically for ipfwadm on Linux, but the
principles (and even much of the syntax) applies for other kernel interfaces
for packet screening on ``open source'' Unix systems.
There are four basic categories covered by the ipfwadm rules:
-A
Packet Accounting
-I
Input firewall
-O
Output firewall
-F
Forwarding firewall
ipfwadm also has masquerading (-M) capabilities. For more information on
switches and options, see the ipfwadm man page.
3.5.1 Implementation
Here, our organization is using a private (RFC 1918) Class C network
192.168.1.0. Our ISP has assigned us the address 201.123.102.32 for our
gateway's external interface and 201.123.102.33 for our external mail
server. Organizational policy says:
* Allow all outgoing TCP connections
* Allow incoming SMTP and DNS to external mail server
* Block all other traffic
The following block of commands can be placed in a system boot file (perhaps
rc.local on Unix systems).
ipfwadm -F -f
ipfwadm -F -p deny
ipfwadm -F -i m -b -P tcp -S 0.0.0.0/0 1024:65535 -D 201.123.102.33 25
ipfwadm -F -i m -b -P tcp -S 0.0.0.0/0 1024:65535 -D 201.123.102.33 53
ipfwadm -F -i m -b -P udp -S 0.0.0.0/0 1024:65535 -D 201.123.102.33 53
ipfwadm -F -a m -S 192.168.1.0/24 -D 0.0.0.0/0 -W eth0
/sbin/route add -host 201.123.102.33 gw 192.168.1.2
3.5.2 Explanation
* Line one flushes (-f) all forwarding (-F) rules.
* Line two sets the default policy (-p) to deny.
* Lines three through five are input rules (-i) in the following format:
ipfwadm -F (forward) -i (input) m (masq.) -b (bi-directional) -P
protocol)[protocol]-S (source)[subnet/mask] [originating ports]-D
(destination)[subnet/mask][port]
* Line six appends (-a) a rule that permits all internal IP addresses out
to all external addresses on all protocols, all ports.
* Line eight adds a route so that traffic going to 201.123.102.33 will be
directed to the internal address 192.168.1.2.
3.6 What are some reasonable filtering rules for a Cisco?
The example in figure 4 shows one possible configuration for using the
Cisco as filtering router. It is a sample that shows the implementation of
as specific policy. Your policy will undoubtedly vary.
Figure 4: Packet Filtering Router
[\begin{figure} \begin{center} \includegraphics {firewalls-faq4} \end{center}\end{figure}]
In this example, a company has Class C network address 195.55.55.0. Company
network is connected to Internet via IP Service Provider. Company policy is
to allow everybody access to Internet services, so all outgoing connections
are accepted. All incoming connections go through ``mailhost''. Mail and DNS
are only incoming services.
3.6.1 Implementation
* Allow all outgoing TCP-connections
* Allow incoming SMTP and DNS to mailhost
* Allow incoming FTP data connections to high TCP port (>1024)
* Try to protect services that live on high port numbers
Only incoming packets from Internet are checked in this configuration. Rules
are tested in order and stop when the first match is found. There is an
implicit deny rule at the end of an access list that denies everything. This
IP access list assumes that you are running Cisco IOS v. 10.3 or later.
no ip source-route
!
interface ethernet 0
ip address 195.55.55.1
no ip directed-broadcast
!
interface serial 0
no ip directed-broadcast
ip access-group 101 in
!
access-list 101 deny ip 127.0.0.0 0.255.255.255 any
access-list 101 deny ip 10.0.0.0 0.255.255.255 any
access-list 101 deny ip 172.16.0.0 0.15.255.255 any
access-list 101 deny ip 192.168.0.0 0.0.255.255 any
access-list 101 deny ip any 0.0.0.255 255.255.255.0
access-list 101 deny ip any 0.0.0.0 255.255.255.0
!
access-list 101 deny ip 195.55.55.0 0.0.0.255
access-list 101 permit tcp any any established
!
access-list 101 permit tcp any host 195.55.55.10 eq smtp
access-list 101 permit tcp any host 195.55.55.10 eq dns
access-list 101 permit udp any host 192.55.55.10 eq dns
!
access-list 101 deny tcp any any range 6000 6003
access-list 101 deny tcp any any range 2000 2003
access-list 101 deny tcp any any eq 2049
access-list 101 deny udp any any eq 2049
!
access-list 101 permit tcp any 20 any gt 1024
!
access-list 101 permit icmp any any
!
snmp-server community FOOBAR RO 2
line vty 0 4
access-class 2 in
access-list 2 permit 195.55.55.0 0.0.0.255
3.6.2 Explanations
* Drop all source-routed packets. Source routing can be used for address
spoofing.
* Drop directed broadcasts, which are used in smurf attacks.
* If an incoming packet claims to be from a local net, loopback network,
or private network, drop it.
* All packets which are part of already established TCP-connections can
pass through without further checking.
* All connections to low port numbers are blocked except SMTP and DNS.
* Block all services that listen for TCP connections on high port
numbers. X-windows (port 6000+), OpenWindows (port 2000+) are a few
candidates. NFS (port 2049) runs usually over UDP, but it can be run
over TCP, so you should block it.
* Incoming connections from port 20 into high port numbers are supposed
to be FTP data connections.
* Access-list 2 limits access to router itself (telnet & SNMP)
* All UDP traffic is blocked to protect RPC services
3.6.3 Shortcomings
* You cannot enforce strong access policies with router access lists.
Users can easily install backdoors to their systems to get over ``no
incoming telnet'' or ``no X'' rules. Also crackers install telnet
backdoors on systems where they break in.
* You can never be sure what services you have listening for connections
on high port numbers.
* Checking the source port on incoming FTP data connections is a weak
security method. It also breaks access to some FTP sites. It makes use
of the service more difficult for users without preventing bad guys
from scanning your systems.
Use at least Cisco version 9.21 so you can filter incoming packets and check
for address spoofing. It's still better to use 10.3, where you get some
extra features (like filtering on source port) and some improvements on
filter syntax.
You have still a few ways to make your setup stronger. Block all incoming
TCP-connections and tell users to use passive-FTP clients. You can also
block outgoing ICMP echo-reply and destination-unreachable messages to hide
your network and to prevent use of network scanners. Cisco.com use to have
an archive of examples for building firewalls using Cisco routers, but it
doesn't seem to be online anymore. There are some notes on Cisco access
control lists, at least, at
ftp://ftp.cisco.com/pub/mibs/app_notes/access-lists.
3.7 What are the critical resources in a firewall?
It's important to understand the critical resources of your firewall
architecture, so when you do capacity planning, performance optimizations,
etc., you know exactly what you need to do, and how much you need to do it
in order to get the desired result.
What exactly the firewall's critical resources are tends to vary from site
to site, depending on the sort of traffic that loads the system. Some people
think they'll automatically be able to increase the data throughput of their
firewall by putting in a box with a faster CPU, or another CPU, when this
isn't necessarily the case. Potentially, this could be a large waste of
money that doesn't do anything to solve the problem at hand or provide the
expected scalability.
On busy systems, memory is extremely important. You have to have enough RAM
to support every instance of every program necessary to service the load
placed on that machine. Otherwise, the swapping will start and the
productivity will stop. Light swapping isn't usually much of a problem, but
if a system's swap space begins to get busy, then it's usually time for more
RAM. A system that's heavily swapping is often relatively easy to push over
the edge in a denial-of-service attack, or simply fall behind in processing
the load placed on it. This is where long email delays start.
Beyond the system's requirement for memory, it's useful to understand that
different services use different system resources. So the configuration that
you have for your system should be indicative of the kind of load you plan
to service. A 700 MHz processor isn't going to do you much good if all
you're doing is netnews and mail, and are trying to do it on an IDE disk
with an ISA controller.
Table 1: Critical Resources for Firewall
Services
Service Critical Resource
Email Disk I/O
Netnews Disk I/O
Web Host OS Socket Performance
IP Routing Host OS Socket Performance
Web Cache Host OS Socket Performance, Disk I/O
3.8 What is a DMZ, and why do I want one?
``DMZ'' is an abbreviation for ``demilitarized zone''. In the context of
firewalls, this refers to a part of the network that is neither part of the
internal network nor directly part of the Internet. Typically, this is the
area between your Internet access router and your bastion host, though it
can be between any two policy-enforcing components of your architecture.
A DMZ can be created by putting access control lists on your access router.
This minimizes the exposure of hosts on your external LAN by allowing only
recognized and managed services on those hosts to be accessible by hosts on
the Internet. Many commercial firewalls simply make a third interface off of
the bastion host and label it the DMZ. The point is that the network is
neither ``inside'' nor ``outside''.
For example, a web server running on NT might be vulnerable to a number of
denial-of-service attacks against such services as RPC, NetBIOS and SMB.
These services are not required for the operation of a web server, so
blocking TCP connections to ports 135, 137, 138, and 139 on that host will
reduce the exposure to a denial-of-service attack. In fact, if you block
everything but HTTP traffic to that host, an attacker will only have one
service to attack.
This illustrates an important principle: never offer attackers more to work
with than is absolutely necessary to support the services you want to offer
the public.
3.9 How might I increase the security and scalability of my DMZ?
A common approach for an attacker is to break into a host that's
vulnerable to attack, and exploit trust relationships between the vulnerable
host and more interesting targets.
If you are running a number of services that have different levels of
security, you might want to consider breaking your DMZ into several
``security zones''. This can be done by having a number of different
networks within the DMZ. For example, the access router could feed two
ethernets, both protected by ACLs, and therefore in the DMZ.
On one of the ethernets, you might have hosts whose purpose is to service
your organization's need for Internet connectivity. These will likely relay
mail, news, and host DNS. On the other ethernet could be your web server(s)
and other hosts that provide services for the benefit of Internet users.
In many organizations, services for Internet users tend to be less carefully
guarded and are more likely to be doing insecure things. (For example, in
the case of a web server, unauthenticated and untrusted users might be
running CGI or other executable programs. This might be reasonable for your
web server, but brings with it a certain set of risks that need to be
managed. It is likely these services are too risky for an organization to
run them on a bastion host, where a slip-up can result in the complete
failure of the security mechanisms.)
By putting hosts with similar levels of risk on networks together in the
DMZ, you can help minimize the effect of a breakin at your site. If someone
breaks into your web server by exploiting some bug in your web server,
they'll not be able to use it as a launching point to break into your
private network if the web servers are on a separate LAN from the bastion
hosts, and you don't have any trust relationships between the web server and
bastion host.
Now, keep in mind that we're running ethernet here. If someone breaks into
your web server, and your bastion host is on the same ethernet, an attacker
can install a sniffer on your web server, and watch the traffic to and from
your bastion host. This might reveal things that can be used to break into
the bastion host and gain access to the internal network.
Splitting services up not only by host, but by network, and limiting the
level of trust between hosts on those networks, you can greatly reduce the
likelihood of a breakin on one host being used to break into the other.
Succinctly stated: breaking into the web server in this case won't make it
any easier to break into the bastion host.
You can also increase the scalability of your architecture by placing hosts
on different networks. The fewer machines that there are to share the
available bandwidth, the more bandwidth that each will get.
3.10 What is a `single point of failure', and how do I avoid having one?
An architecture whose security hinges upon one mechanism has a single
point of failure. Software that runs bastion hosts has bugs. Applications
have bugs. Software that controls routers has bugs. It makes sense to use
all of these components to build a securely designed network, and to use
them in redundant ways.
If your firewall architecture is a screened subnet, you have two packet
filtering routers and a bastion host. (See question 3.2 from this section.)
Your Internet access router will not permit traffic from the Internet to get
all the way into your private network. However, if you don't enforce that
rule with any other mechanisms on the bastion host and/or choke router, only
one component of your architecture needs to fail or be compromised in order
to get inside. On the other hand, if you have a redundant rule on the
bastion host, and again on the choke router, an attacker will need to defeat
three mechanisms.
Further, if the bastion host or the choke router needs to invoke its rule to
block outside access to the internal network, you might want to have it
trigger an alarm of some sort, since you know that someone has gotten
through your access router.
3.11 How can I block all of the bad stuff?
For firewalls where the emphasis is on security instead of connectivity,
you should consider blocking everything by default, and only specifically
allowing what services you need on a case-by-case basis.
If you block everything, except a specific set of services, then you've
already made your job much easier. Instead of having to worry about every
security problem with everything product and service around, you only need
to worry about every security problem with a specific set of services and
products. :-)
Before turning on a service, you should consider a couple of questions:
* Is the protocol for this product a well-known, published protocol?
* Is the application to service this protocol available for public
inspection of its implementation?
* How well known is the service and product?
* How does allowing this service change the firewall architecture? Will
an attacker see things differently? Could it be exploited to get at my
internal network, or to change things on hosts in my DMZ?
When considering the above questions, keep the following in mind:
* ``Security through obscurity'' is no security at all. Unpublished
protocols have been examined by bad guys and defeated.
* Despite what the marketing representatives say, not every protocol or
service is designed with security in mind. In fact, the number that are
is very few.
* Even in cases where security is a consideration, not all organizations
have competent security staff. Among those who don't, not all are
willing to bring a competent consultant into the project. The end
result is that otherwise-competent, well-intended developers can design
insecure systems.
* The less that a vendor is willing to tell you about how their system
really works, the more likely it is that security (or other) problems
exist. Only vendors with something to hide have a reason to hide their
designs and implementations.
3.12 How can I restrict web access so users can't view sites unrelated to
work?
A few years ago, someone got the idea that it's a good idea to block
``bad'' web sites, i.e., those that contain material that The Company views
``inappropriate''. The idea has been increasing in popularity, but there are
several things to consider when thinking about implementing such controls in
your firewall.
* It is not possible to practically block everything that an employer
deems ``inappropriate''. The Internet is full of every sort of
material. Blocking one source will only redirect traffic to another
source of such material, or cause someone to figure a way around the
block.
* Most organizations do not have a standard for judging the
appropriateness of material that their employees bring to work, i.e.,
books, magazines, etc. Do you inspect everyone's briefcase for
``inappropriate material'' every day? If you do not, then why would you
inspect every packet for ``inappropriate material''? Any decisions
along those lines in such an organization will be arbitrary. Attempting
to take disciplinary action against an employee where the only standard
is arbitrary typically isn't wise, for reasons well beyond the scope of
this document.
* Products that perform site-blocking, commercial and otherwise, are
typically easy to circumvent. Hostnames can be rewritten as IP
addresses. IP addresses can be written as a 32-bit integer value, or as
four 8-bit integers (the most common form). Other possibilities exist,
as well. Connections can be proxied. Web pages can be fetched via
email. You can't block them all. The effort that you'll spend trying to
implement and manage such controls will almost certainly far exceed any
level of damage control that you're hoping to have.
The rule-of-thumb to remember here is that you cannot solve social problems
with technical solutions. If there is a problem with someone going to an
``inappropriate'' web site, that is because someone else saw it and was
offended by what he saw, or because that person's productivity is below
expectations. In either case, those are matters for the personnel
department, not the firewall administrator.
4 Various Attacks
4.1 What is source routed traffic and why is it a threat?
Normally, the route a packet takes from its source to its destination is
determined by the routers between the source and destination. The packet
itself only says where it wants to go (the destination address), and nothing
about how it expects to get there.
There is an optional way for the sender of a packet (the source) to include
information in the packet that tells the route the packet should take to get
to its destination; thus the name ``source routing''. For a firewall, source
routing is noteworthy, since an attacker can generate traffic claiming to be
from a system ``inside'' the firewall. In general, such traffic wouldn't
route to the firewall properly, but with the source routing option, all the
routers between the attacker's machine and the target will return traffic
along the reverse path of the source route. Implementing such an attack is
quite easy; so firewall builders should not discount it as unlikely to
happen.
In practice, source routing is very little used. In fact, generally the main
legitimate use is in debugging network problems or routing traffic over
specific links for congestion control for specialized situations. When
building a firewall, source routing should be blocked at some point. Most
commercial routers incorporate the ability to block source routing
specifically, and many versions of Unix that might be used to build firewall
bastion hosts have the ability to disable or ignore source routed traffic.
4.2 What are ICMP redirects and redirect bombs?
An ICMP Redirect tells the recipient system to over-ride something in its
routing table. It is legitimately used by routers to tell hosts that the
host is using a non-optimal or defunct route to a particular destination,
i.e. the host is sending it to the wrong router. The wrong router sends the
host back an ICMP Redirect packet that tells the host what the correct route
should be. If you can forge ICMP Redirect packets, and if your target host
pays attention to them, you can alter the routing tables on the host and
possibly subvert the security of the host by causing traffic to flow via a
path the network manager didn't intend. ICMP Redirects also may be employed
for denial of service attacks, where a host is sent a route that loses it
connectivity, or is sent an ICMP Network Unreachable packet telling it that
it can no longer access a particular network.
Many firewall builders screen ICMP traffic from their network, since it
limits the ability of outsiders to ping hosts, or modify their routing
tables.
Before you decide to completely block ICMP, you should be aware of how the
TCP protocol does ``Path MTU Discovery'', to make certain that you don't
break connectivity to other sites. If you can't safely block it everywhere,
you can consider allowing selected types of ICMP to selected routing
devices. If you don't block it, you should at least ensure that your routers
and hosts don't respond to broadcast ping packets.
4.3 What about denial of service?
Denial of service is when someone decides to make your network or firewall
useless by disrupting it, crashing it, jamming it, or flooding it. The
problem with denial of service on the Internet is that it is impossible to
prevent. The reason has to do with the distributed nature of the network:
every network node is connected via other networks which in turn connect to
other networks, etc. A firewall administrator or ISP only has control of a
few of the local elements within reach. An attacker can always disrupt a
connection ``upstream'' from where the victim controls it. In other words,
if someone wanted to take a network off the air, they could do it either by
taking the network off the air, or by taking the networks it connects to off
the air, ad infinitum. There are many, many, ways someone can deny service,
ranging from the complex to the brute-force. If you are considering using
Internet for a service which is absolutely time or mission critical, you
should consider your fall-back position in the event that the network is
down or damaged.
TCP/IP's UDP echo service is trivially abused to get two servers to flood a
network segment with echo packets. You should consider commenting out unused
entries in /etc/inetd.conf of Unix hosts, adding no ip small-servers to
Cisco routers, or the equivalent for your components.
4.4 What are some common attacks, and how can I protect my system against
them?
Each site is a little different from every other in terms of what attacks
are likely to be used against it. Some recurring themes do arise, though.
4.4.1 SMTP Server Hijacking (Unauthorized Relaying)
This is where a spammer will take many thousands of copies of a message and
send it to a huge list of email addresses. Because these lists are often so
bad, and in order to increase the speed of operation for the spammer, many
have resorted to simply sending all of their mail to an SMTP server that
will take care of actually delivering the mail.
Of course, all of the bounces, spam complaints, hate mail, and bad PR come
for the site that was used as a relay. There is a very real cost associated
with this, mostly in paying people to clean up the mess afterward.
The Mail Abuse Prevention System , Netscape
Proxy , and
http-gw from the TIS firewall toolkit. Most of these can also proxy
other protocols (such as gopher and ftp), and can cache objects
fetched, which will also typically result in a performance boost for
the users, and more efficient use of your connection to the Internet.
Essentially all web clients (Mozilla, Internet Explorer, Lynx, etc.)
have proxy server support built directly into them.
5.3 How do I make SSL work through the firewall?
SSL is a protocol that allows secure connections across the Internet.
Typically, SSL is used to protect HTTP traffic. However, other protocols
(such as telnet) can run atop SSL.
Enabling SSL through your firewall can be done the same way that you would
allow HTTP traffic, if it's HTTP that you're using SSL to secure, which is
usually true. The only difference is that instead of using something that
will simply relay HTTP, you'll need something that can tunnel SSL. This is a
feature present on most web object caches.
You can find out more about SSL from Netscape
.
5.4 How do I make DNS work with a firewall?
Some organizations want to hide DNS names from the outside. Many experts
don't think hiding DNS names is worthwhile, but if site/corporate policy
mandates hiding domain names, this is one approach that is known to work.
Another reason you may have to hide domain names is if you have a
non-standard addressing scheme on your internal network. In that case, you
have no choice but to hide those addresses. Don't fool yourself into
thinking that if your DNS names are hidden that it will slow an attacker
down much if they break into your firewall. Information about what is on
your network is too easily gleaned from the networking layer itself. If you
want an interesting demonstration of this, ping the subnet broadcast address
on your LAN and then do an ``arp -a.'' Note also that hiding names in the
DNS doesn't address the problem of host names ``leaking'' out in mail
headers, news articles, etc.
This approach is one of many, and is useful for organizations that wish to
hide their host names from the Internet. The success of this approach lies
on the fact that DNS clients on a machine don't have to talk to a DNS server
on that same machine. In other words, just because there's a DNS server on a
Section 2 of 4 - Prev - Next
All sections - 1 - 2 - 3 - 4
| Back to category LAN - Use Smart Search |
| Home - Smart Search - About the project - Feedback |
© allanswers.org | Terms of use