The definition of a proxy is "the authority to act on behalf of another," and that’s exactly what a proxy server does. A proxy server, sometimes called 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 features or support user authentication. Because proxies must understand the application protocol being used, they can also implement protocol-specific security. For example, an FTP proxy might be configurable to permit incoming FTP and block outgoing FTP.
Proxy servers are application specific. A new protocol must be developed for every new application supported. One popular set of proxy servers is the TIS 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 about SOCKS, point your Web browser to ftp://ftp.nec.com/pub/security/socks.cstc. Check the file named Files for a description of the directory’s contents.
WHAT ARE SOME CHEAP PACKET-SCREENING TOOLS?
The Texas A&M University (TAMU) security tools include software for implementing screening routers (ftp://net.tamu.edu/pub/security/TAMU). Karlbridge is a PC-based screening router kit (ftp://ftp.net.ohio-state.edu/pub/kbridge). A version of the Digital Equipment Corporation kernel-screening software, screend, is available for BSD/386, NetBSD, and BSDI. A kernel-level packet screen called ipfilter is available for free for BSD-based systems. Many commercial routers support screening of various forms.
WHAT ARE SOME REASONABLE FILTERING RULES FOR A CISCO ROUTER?
The following example, shown in Figure 4, displays one possible configuration of a Cisco router as filtering router. It shows the implementation of a specific example policy; your policy will undoubtedly vary.
In this example, a company has Class C network address of 195.55.55.0. The company network is connected to the Internet via an ISP. The company policy allows everybody access to Internet services, so all outgoing connections are accepted. All incoming connections go through the machine called mailhost. Mail and DNS are the only incoming services.
Implementation
Here are the rules this sample implementation uses:
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
The only packets checked in this configuration are packets from the Internet. The rules are tested in order and stop when the first match is found. An implicit "deny" rule at the end of the access list denies everything else. This IP access list, shown below, assumes that you are running Cisco IOS v.10.3
or later.
1. no ip source-route
2. !
3. interface ethernet 0
4. ip address 195.55.55.1
5. !
6. interface serial 0
7. ip access-group 101 in
8. !
9. access-list 101 deny ip 195.55.55.0 0.0.0.255
10. access-list 101 permit tcp any any established
11. !
12. access-list 101 permit tcp any host 195.55.55.10 eq smtp
13. access-list 101 permit tcp any host 195.55.55.10 eq dns
14. access-list 101 permit udp any host 192.55.55.10 eq dns
15. !
16. access-list 101 deny tcp any any range 6000 6003
17. access-list 101 deny tcp any any range 2000 2003
18. access-list 101 deny tcp any any eq 2049
19. access-list 101 deny udp any any eq 204
20. !
21. access-list 101 permit tcp any 20 any gt 1024
22. !
23. access-list 101 permit icmp any any
24. !
25. snmp-server community FOOBAR RO 2
26. line vty 0 4
27. access-class 2 in
28. access-list 2 permit 195.55.55.0 255.255.255.0
Configuration Explanation
Drop all source-routed packets because source routing can be used for address spoofing.
If an incoming packet claims to be from the local network, drop the packet.
Pass without further checking all packets that are part of an already-established TCP connection.
Block all connections to low port numbers except SMTP and DNS.
Block all services that listen for TCP connections on high port numbers.
X-windows (port 6000+) and OpenWindows (port 2000+) are candidates. NFS (port 2049) runs usually over UDP, but it can be run over NFS, so block it, too.
Check incoming connections from port 20 into high port numbers; they are supposed to be FTP data connections.
Limit access to the router itself (Telnet & SNMP) with access-list 2.
Block all UDP traffic to protect RPC services.
Shortcomings
You cannot enforce strong access policies with router access lists. Users can easily install back doors to their systems to get past "no incoming Telnet" or "no X" rules. Also, some crackers can install Telnet back doors on systems after they break in.
You can never be sure what services are listening for connections on high port numbers.
Checking the source port on incoming FTP data connections is a weak security method because it makes using back doors more difficult, but it doesn’t prevent hackers from scanning your systems. Another drawback is that it breaks access to some FTP sites.
Use Cisco code version 9.21 or later (current version is 10.3) so you can filter incoming packets and check for address spoofing. It’s always best to use the most current version, because you get extra features (like filtering on source ports) and some improvements on overall filter syntax.
You still have 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 the use of network scanners. The Cisco FTP site has an archive of examples for building firewalls using Cisco routers (ftp://ftp.cisco.com/pub/acl-examples.tar.Z). Those examples are a bit out-of-date, but some perl scripts are pretty useful once they’ve been adjusted for your network.
HOW TO I MAKE WEB/HTTP WORK THROUGH MY FIREWALL?
You have three ways to make Web/HTTP work through your firewall.
Allow "established" connections an outward path via a router, if you are using screening routers.
Use a Web client that supports SOCKS and run SOCKS on your firewall.
Run some kind of proxy-capable Web server on the firewall. The TIS Firewall Toolkit (FWTK) includes a proxy called http-gw, which proxies Web, gopher/gopher+ and FTP. CERN httpd also has a proxy capability, which many sites use in combination with the server’s cache of frequently accessed pages. Microsoft has a great Proxy Server that supports most of the functions you might need. Many Web clients, including Netscape, Mosaic, Spry, and Chameleon, have proxy server support built directly into them.
HOW DO I MAKE DNS WORK WITH A FIREWALL?
Some organizations want to hide DNS names from the outside world. Although many experts don’t think hiding DNS names is worthwhile, it is one approach that is known to work. If you have a nonstandard addressing scheme on your internal network, you have no choice but to hide those addresses.
Don’t fool yourself into thinking that hiding your DNS names slows down attackers. Information about what is on your network is too easily gleaned from the networking layer itself. For an interesting demonstration, ping the subnet broadcast address on your LAN and then issue the "arp -a" command. Also note that hiding names in the DNS doesn’t address the problem that host names leak out in mail headers and news articles.
If you want to hide DNS names, you have many options. The following approach is one of many. The success of this approach lies in the fact that DNS clients on a machine don’t have to talk to a DNS server on that same machine. In other words, even though a DNS server is on a machine, you can redirect that machine’s DNS client activity to a DNS server on another machine.
First, on the bastion host, set up a DNS server that the outside world can talk to 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 server is your public server.
Then 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" name server, into which you put all your normal DNS stuff. You also set up this server to forward queries that it can’t resolve to the public server (using a forward line in the named.boot table, for example). This approach assumes that a packet-filtering firewall between these two servers lets them talk DNS to each other but otherwise restricts DNS between other hosts.
Finally, set up all your DNS clients (the resolv.conf file, for instance), including the ones on the machine with the public server, to use the internal server. This step 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.
Another trick that’s useful in this scheme is to use wildcard PTR records in your IN-ADDR.ARPA domains. That way, an address-to-name lookup for any of your non-public hosts returns a response such as "unknown.YOUR.DOMAIN" instead of returning an error. This response satisfies anonymous FTP sites like ftp.uu.net that insist on having a name for the machines they talk to. This strategy may fail when you attempt to connect to sites that do a DNS cross-check in which the host name is matched against its address and vice versa.passwords.
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
