As you saw in the section on FTP in Chapter 3, this protocol can be a real pain to support through a firewall. This is because the protocol actually uses two ports while transferring files. To review, you are stuck with the
following:
Standard FTP: All inbound service ports above 1023 must be left open to support data connection.
Passive FTP: All outbound service ports above 1023 must be left open to support data connection.
In a world of the lesser of two evils, it is usually better to support only passive FTP. This is supported by all Web browsers and most graphic FTP programs. It is typically not supported by command-line FTP programs.
In order to support passive FTP, you must allow all internal hosts to access any TCP ports above 1023 on systems located out on the Internet. Not the best security stance, but it is certainly far better than the standard FTP alternative.
If there are specific services you wish to block, you can create these access list entries before the entry that opens all outbound ports. Since the rules are processed in order, the deny rules would be processed first, and the traffic would be dropped. For example, let’s say you wish to block access to X11 and Open Windows servers, but you want to open the remaining upper ports for passive FTP use. In this case you would create the following rules: access-list 101 deny any any eq 2001
access-list 101 deny any any eq 2002 access-list 101 deny any any eq 6001 access-list 101 deny any any eq 6002 access-list 101 permit any any gt 1023
The only problem here is that you would receive random FTP file transfer failures when the client attempted to use ports 2001, 2002, 6001, or 6002. This would probably not happen often, but intermittent failures are usually the most annoying.
mail server. The mail server also runs the local DNS process. Additionally, you would like to provide unrestricted outbound access to all TCP services.
Figure 6.4: Using access lists on a simple network
Your access list rules would look something like those that follow. Lines starting with an exclamation point (!) are considered comments or remarks by the Cisco IOS.
! Stop any inbound spoofing
access-list 1 deny 206.121.73.0 0.0.0.255 ! Let in replies to established connection
access-list 101 permit tcp any 206.121.73.0 0.0.0.255 gt 1023 est ! Look for port scanning
access-list 101 deny tcp any any eq 19 log ! Allow in SMTP mail to the mail server
access-list 101 permit tcp any 206.121.73.21 0.0.0.0 eq 25 ! Allow in DNS traffic
access-list 101 permit tcp any 206.121.73.21 0.0.0.0 eq 53 access-list 101 permit udp any 206.121.73.21 0.0.0.0 eq 53 ! Allow in HTTP to the web server
access-list 101 permit tcp any 206.121.73.20 0.0.0.0 eq 80 ! Let in replies if an internal user pings an external host access-list 101 permit icmp any any echo-reply
! Allow for flow control
access-list 101 permit icmp any any source-quench ! Let in replies if an internal user runs traceroute access-list 101 permit icmp any any time-exceeded ! Insure that our internal users do not spoof
access-list 2 permit 206.121.73.0 0.0.0.255 ! Let out replies from the web server
access-list 102 permit tcp 206.121.73.20 0.0.0.0 any gt 1023 est ! Let out replies from the mail/DNS server
access-list 102 permit tcp 206.121.73.21 0.0.0.0 any gt 1023 est ! Let out DNS traffic from the DNS server
access-list 102 permit udp 206.121.73.21 0.0.0.0 any eq 53 ! Block all other UDP traffic except for DNS permitted above access-list 102 deny udp 206.121.73.0 0.0.0.255 any
! Allow a single host to create Telnet sessions to the router
access-list 102 permit tcp 206.121.73.200 0.0.0.0 206.121.73.1 0.0.0.0 eq 23 ! Block all other hosts from creating Telnet sessions
! to the router
access-list 102 deny tcp any 206.121.73.1 0.0.0.0 eq 23 ! Allow all TCP traffic through
access-list 102 permit ip 206.121.73.0 0.0.0.255 any
Once this list has been entered (or pasted) in global configuration mode, you would first go to configuration mode for the serial interface and enter the commands
ip access-group 1 in ip access-group 101 in
You would then go to configuration mode for the Ethernet interface and enter the commands ip access-group 2 in
ip access-group 102 in
When you’re finished, your access lists will be active and your router should begin filtering traffic. You should test your configuration immediately to make sure that all is working as you expect.
A Few Comments on Our Sample Access Lists
The third access list is labeled “look for port scanning.” This is accomplished by logging a specific port so that any activity is displayed on the console terminal. As mentioned, routers typically have very poor logging capability. You do not want to log too much information—it may scroll off the screen before you catch it. By monitoring a port that you know an attacker will check (port 19 is chargen, or Character Generator, which has quite a few vulnerabilities), you can strike a good balance between not logging too much information and still catching suspect traffic.
Lines 12 and 13 limit outbound replies to only the Web and mail servers. Since these are the only two systems offering services, they are the only two that should be sending replies back to Internet hosts. Lines 14 and 15 limit UDP traffic to DNS and only from the DNS server. Since UDP is unreliable, it is also insecure. These filters limit your vulnerability to a single system. Of course, this means that all internal hosts will need to use the mail system for DNS resolution.
Lines 16 and 17 specify that only a single host can gain remote access to the router. This will help to strengthen the device’s protection even further. Remember that when you use telnet to manage the router (without enabling any router-to-router encryption), all information (including passwords) is sent clear text. These filters help to insure that even if someone does compromise the passwords, they are only useful from a single remote system (unless of course the attacker fakes his IP address, but we will not go there).
Finally, the access rules end by stating, “Let out any TCP traffic we have not explicitly denied.” If there are TCP services you wish to filter, you could enter these test conditions prior to this last rule.
Tip Do not save your changes right away. Perform your testing with the changes in active memory only. If you have inadvertently locked yourself out of the device, you can simply power cycle it to return to the last saved configuration. Just remember to save the new configuration once you know the changes are acceptable!
Dynamic Access Lists
Exceptions can arise for any security policy, and dynamic access lists are a reflection of that necessity. Also called lock-and-key, this feature creates dynamic extended access lists. However, it can also be used with standard and static extended access lists.
Users are authenticated through a challenge mechanism.
In larger networks lock-and-key provides a simplified method for management. Router processing of access lists is decreased.
Fewer exploitable openings occur in the router infrastructure. Here is an example of how lock-and-key works:
1. Let’s say a vacationing administrator must remotely connect to the network to perform troubleshooting. The administrator opens a telnet session to the router.
2. The router performs a user authentication process (either by itself or through a separate security system like TACACS+ or RADIUS).
3. Upon successful authentication, the administrator is logged out of the telnet session, and the router makes a temporary entry in the dynamic access list.
4. The administrator now has access into the internal network and makes the required changes.
5. Once finished, the administrator initiates a new telnet session and manually clears the temporary entry. The administrator could have also specified an idle or absolute timeout value for the entry; in which case the router would have automatically cleared the entry after it had expired.
For example, consider the following code, starting with the command to configure a dynamic access list: access-list {access-list-number} dynamic {dynamic-name} {deny or permit}
telnet {source} {source-wildcard} {destination} {destination-wildcard} precedence {precedence} tos {tos} established log
In practice, even if administrative policy is to manually clear the entry, a timeout value is an easily configurable reassurance that a potential security hole is closed.
Spoofing
The temporary entry in the dynamic access list created by lock-and-key is an opening that makes the router susceptible to spoofing. One method of countering this threat is to enable encryption on the router and on the remote router servicing the remote host (in our example, the router acting as the administrator’s immediate gateway). With an encrypted connection, the host IP address is hidden from any potential hackers within the encrypted traffic, and therefore can’t be spoofed.
Reflexive Access Lists
As of IOS 11.3, Cisco routers support reflexive access lists. Reflexive access lists are made to be a replacement for the static establish command. When reflexive access lists are used, the router creates a dynamic state table of all active sessions.
The ability to generate a state table pushes the Cisco router into the realm of a true firewall. By monitoring state, the router is in a far better position to make filter determinations than equivalent devices that only support static filtering.
In order to use reflexive access lists, you must use access list names, not range identifier numbers. This is not a big deal, as using a name allows you to be far more descriptive in labeling your access lists.
The syntax for creating a reflexive access list is
permit {protocol} {source} {mask} {destination} {mask} reflect {name} So you could create a reflexive access list using the following parameters: permit ip any any reflect ipfilter
Let’s assume that you only wish to allow in SMTP to a single internal host, as well as any replies to active sessions that were established by any system on your internal network. In this situation, you could create the following in global configuration mode:
ip access-list extended inboundfilters permit tcp any 206.121.73.21 0.0.0.0 eq 25 evaluate tcptraffic
This would allow inbound replies to active sessions and inbound SMTP sessions to be established.
The only caveat with reflexive access lists is that entries are purged from the table after 300 seconds of inactivity. While this is not a problem for most protocols, the FTP control session (port 21) can sit idle for a far longer period of time during a file transfer. You can increase this timeout value using the following command:
ip reflexive-list timeout {timeout in seconds}
TCP Intercept
DoS (denial-of-service) attacks have become quite prevalent recently. The most popular way to implement this attack is using the SYN flood. A hacker creates a SYN flood by initiating a large quantity of connection requests in a short amount of time. Because the connection requests don’t come from valid addresses, the server can’t complete the connection. The result is that the server is so tied up in attempting to respond to invalid requests that it has no resources left to answer legitimate requests for services (such as Web, FTP, and e-mail).
Cisco’s TCP intercept component resolves this problem by answering all incoming connection requests itself. If successful, it opens a connection with the server and links the two connections together. If the connection request is not legitimate, the connection request is dropped—and a threshold counter is incremented. Once the limit on this counter is reached, all additional connection requests from that particular address are automatically dropped.