Previously published – Author unknown

The following example 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.

[Packet filtering access router]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.

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 lists 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
!
interface serial 0
ip access-group 101 in
!
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 255.255.255.0

Explanations
• Drop all source-routed packets. Source routing can be used for address spoofing.

• If incoming packet claims to be from local net, 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 TCP connections in high port numbers. X-windows (port 6000+), Open Windows (port 2000+) are few candidates. NFS (port 2049) runs usually over UDP, but it can be run over TCP, so you have better 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

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 connections on high port numbers.

• Checking source port on incoming FTP data connections is a weak security method. It also breaks access to some FTP sites. It makes users more difficult to use their backdoors, but doesn’t prevent 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.cisco.com/pub/mibs/app_notes/access-lists.

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.

For example, a web server running on NT might be vulnerable to a number of denial-of-service attacks against such services as NetBIOS and SMB. These services are not required for the operation of a web server, so blocking TCP connections to ports 135 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.

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.

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 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.

Various Attacks
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 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.

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.

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.

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.

SMTP Session Hijacking
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 Transport Security Initiative maintains a complete description of the problem, and how to configure about every mailer on the planet to protect against this attack.

Exploiting Bugs in Applications
Various versions of web servers, mail servers, and other Internet service software contain bugs that allow remote (Internet) users to do things ranging from gain control of the machine to making that application crash and just about everything in between.

The exposure to this risk can be reduced by running only necessary services, keeping up to date on patches, and using products that have been around a while.

Bugs in Operating Systems
Again, these are typically initiated by users remotely. Operating systems that are relatively new to IP networking tend to be more problematic, as more mature operating systems have had time to find and eliminate their bugs.

An attacker can often make the target equipment continuously reboot, crash, lose the ability to talk to the network, or replace files on the machine.

Here, running as few operating system services as possible can help. Also, having a packet filter in front of the operating system can reduce the exposure to a large number of these types of attacks.

And, of course, choosing a stable operating system will help here as well. When selecting an OS, don’t be fooled into believing that “the pricier, the better”. Free operating systems are often much more robust than their commercial counterparts

How do I…

Do I really want to allow everything that my users ask for?

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, and 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 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”, and 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.

How do I make Web/HTTP work through my firewall?

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, 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.

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 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