• Configure R5 to permit TCP, UDP, and ICMP packets sourced from behind the VLAN 58 interface.
• Do not create explicit access-list entries to permit returning TCP, UDP, and ICMP traffic.
• Ensure that Telnet and ICMP traffic originated from the router are also permitted by the access-list, but do not create any entries in the interface access-lists.
• Ensure RIP routing traffic is also permitted by your configuration.
Configuration
R5:
no ip access-list extended OUTBOUND ip access-list extended OUTBOUND permit tcp any any reflect MIRROR permit icmp any any reflect MIRROR permit udp any any reflect MIRROR deny ip any any log
!
no ip access-list extended INBOUND ip access-list extended INBOUND permit udp any any eq 520 evaluate MIRROR
!
interface Serial 0/0
ip access-group INBOUND in ip access-group OUTBOUND out
!
interface Serial 0/1
ip access-group INBOUND in ip access-group OUTBOUND out
!
! Local policy to divert telnet connections over the loopback
!
no ip access-list extended LOCAL_TRAFFIC ip access-list extended LOCAL_TRAFFIC permit tcp any any eq 23
permit icmp any any echo
!
route-map DIVERT_LOCAL
match ip address LOCAL_TRAFFIC set ip next-hop 150.1.5.254
!
ip local policy route-map DIVERT_LOCAL
Verification
Note
Reflexive access-lists add “stateful” behavior to the IOS packet filtering features.
The overall idea is simple: when a packet matches an ACL entry, instruct the router to create a “mirrored” entry in the access list applied in the opposite direction. For example, if a packet hits an inbound ACL, take the
source/destination IP addresses and ports, swap them, and add dynamic entries to the outbound access list with the new parameters. This procedure
automatically permits returning traffic for symmetric flows. It will not work for
“non-standard” TCP applications, which are complicated protocols such as RCP, TFTP, and H323, which open dynamic channels with no way for a router to predict their behavior.
The reflexive access list implementation is as follows. When you configure a regular ACL entry for TCP, UDP, or ICMP traffic, you may add the command
“reflect <ACL_NAME>”. When a packet matches this entry, the router adds the dynamic “mirrored” ACL entry to the ACL named <ACL_NAME>. Later, you can add the command “evaluate <ACL_NAME>” in the access-list applied in the opposite direction. This command instructs the router to evaluate the entries in the dynamically populated ACL to find a match for returning packet. There is no need to pre-create the dynamically populated ACL, the IOS creates it automatically.
Note that you may only reflect UDP, TCP and ICMP session traffic. All dynamic entries persist as long as the session is active. When a session becomes
inactive, the router ages out the corresponding entry in the time specified by the global command:
ip reflexive-list timeout <TIMEOUT>
The default timeout value is 300 seconds.
Note the important feature that the dynamic access list is only populated when a packet hits an ACL entry. Also recall that locally generated router traffic does not match any outgoing ACLs. Thus, if you use reflexive ACLs, you may need to account for that feature and provide any of the following workarounds:
1) Create a static entry in the inbound access-list to permit the returning routing traffic. This works for protocols like RIP, OSPF, and EIGRP which send
broadcast hello packets.
2) Use local policy routing to divert the local traffic across the loopback interface and make it re-enter the router, in effect, becoming transit traffic. This will cause a match for the outgoing ACLs and populate dynamic entries. This works for unicast session traffic, such as Telnet sessions off the router, ICMP packet flows, or BGP connections.
For verification, source ICMP packets off R5 and originate a telnet session. In both cases, look at the dynamically populated access-list MIRROR.
Rack1R5#ping 150.1.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/61/64 ms
Rack1R5#show ip access-list MIRROR Reflexive IP access list MIRROR
permit icmp host 150.1.3.3 host 155.1.0.5 (20 matches) (time left 296)
Rack1R5#telnet 150.1.3.3 Trying 150.1.3.3 ... Open
User Access Verification
Password:
Rack1R3>exit
[Connection to 150.1.3.3 closed by foreign host]
Rack1R5#show ip access-list MIRROR Reflexive IP access list MIRROR
permit tcp host 150.1.3.3 eq telnet host 155.1.0.5 eq 12864 (77 matches) (time left 2)
permit icmp host 150.1.3.3 host 155.1.0.5 (20 matches) (time left 282)
Next, check the total statistics accumulated by all access-lists. Note the matches for RIP updates.
Rack1R5#show ip access-list Extended IP access list INBOUND
10 permit udp any any eq rip (185 matches) 20 evaluate MIRROR
Extended IP access list LOCAL_TRAFFIC
10 permit tcp any any eq telnet (20 matches) 20 permit icmp any any echo (5 matches) Reflexive IP access list MIRROR
permit icmp host 150.1.3.3 host 155.1.0.5 (20 matches) (time left 272) Extended IP access list OUTBOUND
10 permit tcp any any reflect MIRROR (20 matches) 20 permit icmp any any reflect MIRROR (5 matches) 30 permit udp any any reflect MIRROR
40 deny ip any any log
11.7 Filtering Fragmented Packets
• Ensure R3 prevents fragmented packets from reaching its local HTTP server.
• Only configure the Frame-Relay interface for this task.
Configuration
R3:
no ip access-list extended NO_FRAGMENTS ip access-list extended NO_FRAGMENTS permit udp any any eq rip
deny ip any any fragments permit tcp any any eq 80
!
interface Serial 1/0
ip access-group NO_FRAGMENTS in
Verification
Note
By default, the IP protocol allows packet fragmenting. This feature has been a long time known weakness, exploited by various types of attacks (e.g. ping of death). Overlapping fragments, fragments exceeding the assembly buffer, and fragments arriving out of order, are just a few examples of traffic that can
severely degrade end system performance when an attacker sends them at high rates.
Additionally, fragmented packets are often used to bypass IDS or firewall systems. The attacker splits a packet in such a way that the firewall or IDS system is not able to extract information about something like the port numbers.
Advanced firewalls and IDS systems support packet stream reassembly, but this procedure may degrade overall security system performance.
Due to these reasons, it is a good practice to avoid traffic fragmentation in your network and protect your servers against fragmented packets. One solution would be to configure matching MTU values and enable the PMTU Discovery process.
The IOS firewall is able to classify IP packets as one of the following:
1) Non-fragmented packets or initial fragments. These packets have a fragment offset of zero and commonly contain some upper-level protocol payload (TCP) to allow the extraction of information about application ports.
2) Non-initial fragments have a non-zero fragment offset and are the remaining parts of a fragmented packets. These packets do not have upper level protocol port information and the IOS firewall cannot match them against ACL entries configured with TCP/UDP port numbers. Instead of matching the port numbers, the firewall uses only Layer 3 information in an ACL entry (e.g. source/destination IP addresses) to match against the source/destination IP addresses in the
packet.
This is why any non-initial fragment sourced from 1.1.1.1 to 2.2.2.2 matches the following ACL entry:
permit tcp host 1.1.1.1 host 2.2.2.2 eq 80
Even though it does not contain any port information, the firewall only matches the source and destination IP addresses for non-initial fragments.
You can match non-initial fragments using the fragments keyword in your ACL entry, for example:
deny ip any host 2.2.2.2 fragments
permit tcp host 1.1.1.1 host 2.2.2.2 eq 80
This configuration ensures that only non-fragmented packets and initial fragments may reach port 80 of the target system.
You can configure R5 so that outgoing TCP packets are fragmented. To
accomplish this, ensure that PMTU Discovery is disabled on SW2 and the MTU is set to a minimum value on the Frame-Relay interface of R5. This will force R5 to fragment TCP/IP packets exceeding 68 bytes in size. You may need to
remove the inbound ACL on R5 to permit returning traffic for the HTTP connection.
After this configuration, try connecting to R3 on port 80 from SW2 and download a file from the flash memory. The IP+TCP header size is 40 bytes and the
payload size is most likely more than 28 bytes (the “GET” command and the URL) so the packets will surely exceed the IP MTU.
R3:
ip http server ip http path flash:
Rack1SW2(config)#no ip tcp path-mtu-discovery
Rack1R5(config)#interface Serial 0/0 Rack1R5(config-if)#ip mtu 68
Rack1R5(config-if)#no ip access-group INBOUND in
Rack1SW2#copy http://admin:cisco@150.1.3.3/c3640-jk9o3s-mz.124-13a.bin null:
%Error opening http://admin:cisco@150.1.3.3/c3640-jk9o3s-mz.124-13a.bin (I/O error)
Rack1SW2#
The connection times out, and looking at the access-list statistics on R3 you can see exactly why. The reason is the packets are denied.
Rack1R3#show ip access-lists Extended IP access list NO_FRAGMENTS
10 permit udp any any eq rip (234 matches) 20 deny ip any any fragments (27 matches) 30 permit tcp any any eq www (24 matches)
Now change the MTU back to normal and try downloading again:
Rack1R5(config)#interface Serial 0/0 Rack1R5(config-if)#ip mtu 1500
Rack1SW2#copy http://admin:cisco@150.1.3.3/c3640-jk9o3s-mz.124-13a.bin null:
Loading http://admin:cisco@150.1.3.3/c3640-jk9o3s-mz.124-13a.bin
Now R5 does not fragment the packets and the connection completes normally.