FAQ TOC |
Previous Section |
Next Section
It's entirely possible that the answer is ``no''. Each site has its own
policies about what is and isn't needed, but it's important to
remember that a large part of the job of being an organization's
gatekeeper is education . Users want streaming video,
real-time chat, and to be able to offer services to external customers
that require interaction with live databases on the internal network.
That doesn't mean that any of these things can be done without
presenting more risk to the organization than the supposed ``value''
of heading down that road is worth. Most users don't want to put
their organization at risk. They just read the trade rags, see
advertisements, and they want to do those things, too. It's important
to look into what it is that they really want to do, and to help them
understand how they might be able to accomplish their real objective
in a more secure manner.
You won't always be popular, and you might even find yourself being
given direction to do something incredibly stupid, like ``just open up
ports foo through bar''. If that happens, don't worry about it. It
would be wise to keep all of your exchanges on such an event so that
when a 12-year-old script kiddie breaks in, you'll at least be able to
separate yourself from the whole mess.
There are three ways to do it.
- 1.
- Allow ``established'' connections out via a router, if you are
using screening routers.
- 2.
- Use a web client that supports SOCKS, and run SOCKS on your
bastion host.
- 3.
- Run some kind of proxy-capable web server on the bastion host.
Some options include
Squid
![[*]](foot_motif.gif)
,
Apache,
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.
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.
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 machine, there's nothing wrong with
(and there are often advantages to) redirecting that machine's DNS
client activity to a DNS server on another machine.
First, you set up a DNS server on the bastion host that the outside
world can talk to. You set this server up so that it claims to be
authoritative for your domains. In fact, all this server knows is what
you want the outside world to know; the names and addresses of your
gateways, your wildcard MX records, and so forth. This is the ``public''
server.
Then, you set up a DNS server on an internal machine. This server also
claims to be authoritative for your domains; unlike the public server,
this one is telling the truth. This is your ``normal'' nameserver, into
which you put all your ``normal'' DNS stuff. You also set this server up
to forward queries that it can't resolve to the public server (using a
``forwarders'' line in /etc/named.boot on a Unix machine, for example).
Finally, you set up all your DNS clients (the /etc/resolv.conf
file on a Unix box, for instance), including the ones on the machine
with the public server, to use the internal server. This is the key.
An internal client asking about an internal host asks the internal
server, and gets an answer; an internal client asking about an
external host asks the internal server, which asks the public server,
which asks the Internet, and the answer is relayed back. A client on
the public server works just the same way. An external client,
however, asking about an internal host gets back the ``restricted''
answer from the public server.
This approach assumes that there's a packet filtering firewall between
these two servers that will allow them to talk DNS to each other, but
otherwise restricts DNS between other hosts.
Another trick that's useful in this scheme is to employ wildcard PTR
records in your IN-ADDR.ARPA domains. These cause an an
address-to-name lookup for any of your non-public hosts to return
something like ``unknown.YOUR.DOMAIN'' rather than an error. This
satisfies anonymous FTP sites like ftp.uu.net that insist on having a
name for the machines they talk to. This may fail when talking to
sites that do a DNS cross-check in which the host name is matched
against its address and vice versa.
Generally, making FTP work through the firewall is done either using a
proxy server such as the firewall toolkit's ftp-gw or by permitting
incoming connections to the network at a restricted port range, and
otherwise restricting incoming connections using something like
``established'' screening rules. The FTP client is then modified to bind
the data port to a port within that range. This entails being able to
modify the FTP client application on internal hosts.
In some cases, if FTP downloads are all you wish to support, you might
want to consider declaring FTP a ``dead protocol'' and letting you users
download files via the Web instead. The user interface certainly is
nicer, and it gets around the ugly callback port problem. If you
choose the FTP-via-Web approach, your users will be unable to FTP
files out, which, depending on what you are trying to accomplish, may
be a problem.
A different approach is to use the FTP ``PASV'' option to indicate
that the remote FTP server should permit the client to initiate
connections. The PASV approach assumes that the FTP server on the
remote system supports that operation. (See ``Firewall-Friendly
FTP'' [1].)
Other sites prefer to build client versions of the FTP program that
are linked against a SOCKS library.
Telnet is generally supported either by using an application proxy
such as the firewall toolkit's tn-gw, or by simply configuring a
router to permit outgoing connections using something like the
``established'' screening rules. Application proxies could be in the
form of a standalone proxy running on the bastion host, or in the form
of a SOCKS server and a modified client.
Many firewall admins permit connections to the finger port from only
trusted machines, which can issue finger requests in the form of:
finger user@host.domain@firewall. This approach only works with the
standard Unix version of finger. Controlling access to services and
restricting them to specific machines is managed using either
tcp_wrappers or netacl from the firewall toolkit. This approach will
not work on all systems, since some finger servers do not permit
user@host@host fingering.
Many sites block inbound finger requests for a variety of reasons,
foremost being past security bugs in the finger server (the Morris
internet worm made these bugs famous) and the risk of proprietary or
sensitive information being revealed in user's finger information. In
general, however, if your users are accustomed to putting proprietary
or sensitive information in their .plan files, you have a more
serious security problem than just a firewall can solve.
The majority of firewall administrators choose to support gopher and
archie through web proxies, instead of directly. Proxies such as the
firewall toolkit's http-gw convert gopher/gopher+ queries
into HTML and vice versa. For supporting archie and other queries,
many sites rely on Internet-based Web-to-archie servers, such as
ArchiePlex. The Web's tendency to make everything on the Internet look
like a web service is both a blessing and a curse.
There are many new services constantly cropping up. Often they are
misdesigned or are not designed with security in mind, and their
designers will cheerfully tell you if you want to use them you need to
let port xxx through your router. Unfortunately, not everyone can do
that, and so a number of interesting new toys are difficult to use for
people behind firewalls. Things like RealAudio, which require direct
UDP access, are particularly egregious examples. The thing to bear in
mind if you find yourself faced with one of these problems is to find
out as much as you can about the security risks that the service may
present, before you just allow it through. It's quite possible the
service has no security implications. It's equally possible that it
has undiscovered holes you could drive a truck through.
The X Windows System is a very useful system, but unfortunately has
some major security flaws. Remote systems that can gain or spoof
access to a workstation's X display can monitor keystrokes that a user
enters, download copies of the contents of their windows, etc.
While attempts have been made to overcome them (E.g., MIT ``Magic
Cookie'') it is still entirely too easy for an attacker to interfere
with a user's X display. Most firewalls block all X traffic. Some
permit X traffic through application proxies such as the DEC CRL X
proxy (FTP crl.dec.com). The firewall toolkit includes a proxy for X,
called x-gw, which a user can invoke via the Telnet proxy, to create a
virtual X server on the firewall. When requests are made for an X
connection on the virtual X server, the user is presented with a
pop-up asking them if it is OK to allow the connection. While this is
a little unaesthetic, it's entirely in keeping with the rest of X.
RealNetworks maintains some information about how to get RealAudio
working through your firewall. It would be unwise to
make any changes to your firewall without understanding what
the changes will do, exactly, and knowing what risks the new changes
will bring with them.
The best way to do this is to allow very limited connectivity between
your web server and your database server via a specific protocol that
only supports the level of functionality you're going to use.
Allowing raw SQL, or anything else where custom extractions could be
performed by an attacker isn't generally a good idea.
Assume that an attacker is going to be able to break into your web
server, and make queries in the same way that the web server can. Is
there a mechanism for extracting sensitive information that the web
server doesn't need, like credit card information? Can an attacker
issue an SQL select and extract your entire proprietary
database?
``E-commerce'' applications, like everything else, are best designed
with security in mind from the ground up, instead of having security
``added'' as an afterthought. Review your architecture critically, from
the perspective of an attacker. Assume that the attacker knows
everything about your architecture. Now ask yourself what needs to be
done to steal your data, to make unauthorized changes, or to do
anything else that you don't want done. You might find that you can
significantly increase security without decreasing functionality by
making a few design and implementation decisions.
Some ideas for how to handle this:
- Extract the data you need from the database on a regular basis
so you're not making queries against the full database, complete
with information that attackers will find interesting.
- Greatly restrict and audit what you do allow between the web
server and database.
If your site firewall policy is sufficiently lax that you're willing
to manage the risk that someone will exploit a vulnerability in your
web server that will result in partial or complete exposure of your
database, then there isn't much preventing you from doing this.
However, in many organizations, the people who are responsible for
tying the web front end to the database back end simply do not have
the authority to take that responsibility. Further, if the
information in the database is about people, you might find yourself
guilty of breaking a number of laws if you haven't taken reasonable
precautions to prevent the system from being abused.
In general, this isn't a good idea. See question 5.11 for
some ideas on other ways to accomplish this objective.
IP multicast is a means of getting IP traffic from one host to a set
of hosts without using broadcasting; that is, instead of every host
getting the traffic, only those that want it will get it, without each
having to maintain a separate connection to the server. IP unicast is
where one host talks to another, multicast is where one host talks to
a set of hosts, and broadcast is where one host talks to all hosts.
The public Internet has a multicast backbone (``MBone'') where users
can engage in multicast traffic exchange. Common uses for the MBone
are streams of IETF meetings and similar such interaction. Getting
one's own network connected to the MBone will require that the
upstream provider route multicast traffic to and from your network.
Additionally, your internal network will have to support multicast
routing.
The role of the firewall in multicast routing, conceptually, is no
different from its role in other traffic routing. That is, a policy
that identifies which multicast groups are and aren't allowed must be
defined and then a system of allowing that traffic according to policy
must be devised. Great detail on how exactly to do this is beyond the
scope of this document. Fortunately, RFC 2588 [2]
discusses the subject in more detail. Unless your firewall product
supports some means of selective multicast forwarding or you have the
ability to put it in yourself, you might find forwarding multicast
traffic in a way consistent with your security policy to be a bigger
headache than it's worth.
FAQ TOC |
Previous Section |
Next Section
