Rule Set 5: All Internet Control Message Protocol (ICMP) data should be denied. Pings, formally
known as ICMP Echo requests, are used by internal systems administrators to ensure
that clients and servers can communicate. There is virtually no legitimate use for ICMP outside
the network, except to test the perimeter routers. ICMP uses port 7 to request a
response to a query (e.g., “Are you there?”) and can be the first indicator of a malicious
attack. It’s best to make all directly connected networking devices “black holes” to external
probes. Traceroute uses a variation on the ICMP Echo requests, so restricting this one port
provides protection against two types of probes. Allowing internal users to use ICMP
requires configuring two rules, as shown in Table 6-10.
The first of these two rules allows internal administrators (and users) to use ping. Note that
this rule is unnecessary if internal permissions rules like those in rule set 2 is used. The second
rule in Table 6-10 does not allow anyone else to use ping. Remember that rules are processed
in order. If an internal user needs to ping an internal or external address, the firewall
allows the packet and stops processing the rules. If the request does not come from an internal
source, then it bypasses the first rule and moves to the second.
Rule Set 6: Telnet (terminal emulation) access to all internal servers from the public networks
should be blocked. Though not used much in Windows environments, Telnet is still
useful to systems administrators on Unix/Linux systems. But the presence of external
requests for Telnet services can indicate an attack. Allowing internal use of Telnet requires
the same type of initial permission rule you use with ping. See Table 6-11. Note that this
rule is unnecessary if internal permissions rules like those in rule set 2 is used.
Rule Set 7: When Web services are offered outside the firewall, HTTP traffic (and HTTPS
traffic) should be blocked from the internal networks via the use of some form of proxy
access or DMZ architecture. With a Web server in the DMZ you simply allow HTTP to
access the Web server, and use rule set 8, the cleanup rule (which will be described shortly),
to prevent any other access. In order to keep the Web server inside the internal network,
direct all HTTP requests to the proxy server and configure the internal filtering router/firewall
only to allow the proxy server to access the internal Web server. The rule shown in
Table 6-12 illustrates the first example.
This rule accomplishes two things: it allows HTTP traffic to reach the Web server, and it
prevents non-HTTP traffic from reaching the Web server. It does the latter via the cleanup
rule (Rule 8). If someone tries to access the Web server with non-HTTP traffic (other than
port 80), then the firewall skips this rule and goes to the next.
Proxy server rules allow an organization to restrict all access to a device. The external firewall
would be configured as shown in Table 6-13.
The effective use of a proxy server of course requires that the DNS entries be configured as
if the proxy server were the Web server. The proxy server is then configured to repackage
any HTTP request packets into a new packet and retransmit to the Web server inside
the firewall. The retransmission of the repackaged request requires that the rule shown in
Table 6-14 enables the proxy server at 10.10.10.5 to send to the internal router, assuming
the IP address for the internal Web server is 10.10.10.10. Note that in situations where an
internal NAT server is used, the rule for the inbound interface uses the externally routable
address, because the device performs rule filtering before it performs address translation.
For the outbound interface, however, the address is in the native 192.168.x.x format.
The restriction on the source address then prevents anyone else from accessing the Web
server from outside the internal filtering router/firewall.