Generally, to make FTP work through the firewall, you either set up a proxy server, such as the TIS firewall toolkit’s ftp-gw or Microsoft’s Proxy Server, or you permit incoming connections to the network at a restricted port range and otherwise restrict incoming connections using something like "established" screening rules. You then modify the FTP client to bind the data port to a port within that range. Obviously, you must be able to modify the FTP client application on internal hosts.
If FTP downloads are all you wish to support, you might want to consider declaring FTP a "dead protocol" and letting your users download files via the Web instead. The user interface certainly is nicer, and this setup gets around the ugly callback port problem. If you choose the FTP-via-Web approach, your users won’t be able to FTP files out, which may be a problem, depending on your setup.
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 RFC1579 for more information.) Other sites prefer to build client versions of the FTP program that are linked against a SOCKS library.
HOW DO I MAKE TELNET WORK THROUGH MY FIREWALL?
You can support Telnet either by using an application proxy, such as the TIS firewall toolkit’s tn-gw or Microsoft’s Proxy Server, or by simply configuring a router to permit outgoing connections using something like the "established" screening rules. An application proxies could be a standalone proxy running on the bastion host or a SOCKS server and a modified client.
HOW DO I MAKE FINGER AND WHOIS WORK THROUGH MY FIREWALL?
Many firewall administrators permit connections to the finger port from only trusted machines, which issues finger requests in the form of finger user@host.domain@firewall. This approach works only with the standard Unix version of finger. You can restrict access to services to specific machines by using either tcp_wrappers or netacl from the TIS firewall toolkit. This approach does not work on all systems because some finger servers do not permit user@host@host fingering.
Many sites block inbound finger requests for a variety of reasons, most often because of past security bugs in the finger server (the Morris internet worm made these bugs famous) and because of the risk of revealing proprietary or sensitive information in a user’s finger information. In general, if your users are accustomed to putting proprietary or sensitive information in their .plan files, you have a more serious security problem than a firewall can solve.
HOW DO I MAKE GOPHER, ARCHIE, AND OTHER SERVICES WORK THROUGH MY FIREWALL?
The majority of firewall administrators support gopher and Archie through Web proxies. Proxies such as the TIS firewall toolkit’s http-gw converts 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.
Many new services are constantly cropping up. Often they are not designed with security in mind, and their designers cheerfully tell you that if you want to use them, you need to let port xxx through your router. Unfortunately, not everyone can do that, and a number of interesting new toys are difficult to use for people behind firewalls. RealAudio, which requires direct UDP access, is a particularly egregious example; remember that Microsoft’s Proxy Server handles RealAudio. If you find yourself faced with one of these problems, remember to find out as much as you can about the security risks that the service may present before you 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.
WHAT ARE THE ISSUES ABOUT X-WINDOWS THROUGH A FIREWALL?
X-Windows is a very useful system, but it unfortunately has some major security flaws. Remote systems that can gain or spoof access to a workstation’s X display can monitor a user’s keystrokes and download copies of the contents of their windows.
Although attempts have been made to overcome problems — for example, 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 TIS FWTK 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 a user requests an X connection on the virtual X server, the user is presented with a pop-up menu asking whether it is OK to allow the connection. Although this setup is a little unaesthetic, it’s entirely in keeping with the rest of X.
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 says only where it wants to go (the destination address) and nothing about how it expects to get there.
The sender of a packet (the source) has the option to include information in the packet that tells the route the packet should follow to get to its destination; thus the name "source routing." For a firewall, source routing is noteworthy, because an attacker can generate traffic that claims 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 return traffic along the reverse path of the source route. Implementing such an attack is quite easy; so firewall builders should not discount the possibility.
In practice, source-routing is used very little. In fact, its main legitimate use is in debugging network problems or routing traffic over specific links to control congestion in special situations. When building a firewall, you should block source routing at some point. Most commercial routers incorporate the specific ability to block source routing, and many versions of Unix that you might use to build firewall bastion hosts have the ability to disable or ignore source-routed traffic.
WHAT ARE ICMP REDIRECTS AND REDIRECT BOMBS?
An ICMP redirect tells the recipient system to override something in its routing table. This feature is legitimately used by routers to tell hosts that the host is using a non-optimal or defunct route to a particular destination; that is, the host is sending it to the wrong router. The wrong router sends the host 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 host’s routing tables and possibly subvert its security by changing the paths traffic uses. ICMP redirects may also be used in denial-of-service attacks, in which a host is sent a route that loses it connectivity or a host 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, because screening limits outsiders’ ability to ping hosts and modify their routing tables.
WHAT ABOUT DENIAL OF SERVICE?
A denial-of-service attack occurs when someone makes your network or firewall useless by disrupting it, crashing it, jamming it, or flooding it. Denial of service is impossible to prevent because of the distributed nature of the network: every network node is connected via other networks, which in turn connect to other networks. A firewall administrator or ISP has control of only 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, someone who wants to take a network off the air can either take the network off the air directly or take the network it connects to off the air, or the network that connects to that network off the air, ad infinitum. Hackers can deny service in many ways, ranging from the complex to the brute-force.
If you are considering using the Internet for a service that is absolutely time- or mission-critical, you should consider your fallback position in the event that the network is down or damaged. Microsoft has released hotfixes that address certain types of denial-of-service attacks such as SYN Flooding and giant Ping packets. Be sure to regularly watch for new Service Packs, because they offer new security enhancements that you should put on your systems.
Order Your SQL Fundamentals CD Today! Learn how to use SQL Server, understand Office integration techniques and dive into the essentials of SQL Express and Visual Basic with this free SQL Fundamentals CD.
You've Deployed SharePoint...Now What? This one-day free online conference delivers the technical knowledge needed to kick MOSS up a notch. In one information-packed day, independent SharePoint experts will present practical, real-world information and provide take-away, ready-to-use solutions
What Would You Do If You Ran Microsoft? ITTV's 2008 inaugural video contest, "If I Ran Microsoft..." is your chance to tell it like it is. Be goofy or be serious, but don"t miss this chance to have fun, win prizes, and go viral in a major way.
Maximize Your SharePoint Investment This web seminar discusses how true bi-directional replication of SharePoint content from one server to another enables branch offices to maintain access to current SharePoint content.
Windows IT Pro
Register
