ASA CHAPTER 7 (Fragmented Traffic/IDENT/BGP peer across firewall)
10. Permit ICMP traffic through the firewall.
Disable fragmented packets on “DMZ” and “Outside” interfaces.
11. Handling IDENT Issues .
Configure the firewall to quickly terminate the IDENT lookup sessions
going from outside for TCP sessions initiated by inside users.
Consider both users translated using identity mappings and to the outside
interface IP address.
12. How to create BGP across the Firewall ?
• Ensure the ASA firewall runs in NAT controlled mode and RIPv2 is active
on all interfaces.
• R1 and R3 are pre-configured for eBGP peering across the firewall.
• Both routers use their Loopback1 interfaces to source the BGP session.
• Authenticate the BGP session using the password of “CISCO”.
• Ensure that R3 is allowed to initiate a BGP sessions to R1.
Fragmented IP traffic presents a potentially serious security threat. First of all,
fragment reassembly code in many OSes has been long time most vulnerable to
numerous bugs, exposing networks to the attacks such as Ping of Death.
Secondly, fragmented traffic puts higher CPU/Memory burden on the end hosts,
as it requires them to create large buffers (64K to potentially fit any fragment
size) for packet reassembly and keep them for potentially long time, while waiting
for all packet fragments. And lastly, it is a common technique to use fragmented
traffic in order to bypass security checks (such as IPS or firewall) by breaking
malicious packets into smaller fragments (this might let bypass simple firewalls,
for example).
Even if it is a good practice to avoid traffic fragmentation at any cost, it is not
possible in some situations. Two well-know examples are the use of NFSv2
(Sun’s Network File System) which transports data blocks in large UDP packets
and VPN-protected traffic, which might exceed network MTU due to
encryption/tunneling overheads.
The ASA firewall implements packet reassembly technique in order to perform
deep inspection of fragmented traffic. The firewall does not permit a fragmented
packet through, until it fully assembles it and verifies its contents. By default, the
first fragment is delayed for the duration set by fragment timeout <N>
command (5 seconds by default) until all fragments are received and assembled.
If the timeout expires before all fragments arrive, the packet is discarded. The
firewall will accept at maximum of fragment chain <limit> [interface]
fragments on the particular interface, with the default being of 24 fragments. If
the number of fragments exceeds the limit, the packet is discarded. Thus, if you
want to disable fragmented packets at all, use the command fragment chain
1to instruct the firewall dropping all fragmented packets (more than 1 fragment).
Finally, all fragments are stored in a system-wide re-assembly buffer, with the
size set using the command fragment size <N>where <N> is the maximum
number of packets held in the buffer.
-->
10. Permit ICMP traffic through the firewall.
Disable fragmented packets on “DMZ” and “Outside” interfaces.
ASA1:
!
! Remove any old configurations
!
No nat-control
clear configure access-list
access-list OUTSIDE_IN permit icmp any any
access-group OUTSIDE_IN in interface outside
!
! Disable Fragment reassembly on the mentioned interfaces
!
fragment chain 1 outside
fragment chain 1 dmz
output:
R1#ping 136.1.122.2 size 1500
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 136.1.122.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/13 ms
R1#ping 136.1.122.2 size 1510
Type escape sequence to abort.
Sending 5, 1510-byte ICMP Echos to 136.1.122.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
11. Handling IDENT Issues
Configure the firewall to quickly terminate the IDENT lookup sessions
going from outside for TCP sessions initiated by inside users.
Consider both users translated using identity mappings and to the outside
interface IP address.
-->
IDENT is the simple protocol that is designed to disclose the “owner” of the active
TCP connection. This is how IDENT works:
1) On a user’s machine, a special IDENT daemon is running and listening on port
113.
2) When a user makes an outbound connection, the remote server might initiate
reverse IDENT connection to the user’s IP address and port 113, asking for the
information on the TCP connection “owner” (to record it in the system logs).
3) The daemon returns the information and the server permits the original user’s
connection.
4) If for some reason the IDENT daemon does not respond, it’s up to the server
to decide the further connection’s fate. Nowadays, most servers would still permit
the connection.
IDENT protocol is clearly unsecure and unreliable. It might work in situations
where the user has no admin privileges over the machine he works from. In
addition to that, it requires that the user is not located behind any sort of NAT or
firewall as the translating/filtering device might not properly handle the IDENT
lookup. However, still some applications (e.g. sendmail and some FTP dameons)
continue to use IDENT lookups with their default configuration, even though they
don’t deny the hosts not running the IDENT process.
Now imagine that a user behind the ASA firewall connects to the server that does
IDENT lookups. There might be two situations:
1) User is NAT translated using the IP that “belongs” to the ASA firewall. In this
case, the reverse IDENT lookup will terminate at the ASA firewall. By default, the
ASA simply discards TCP SYN packets sent to the ports it is not listening on.
2) User’s IP has not been changed by the firewall. In this case, the IDENT
session will be attempted to the original user’s IP address. Most likely your
firewall does not permit such connections, so the TCP SYN packets will be
silently discarded.
In both cases, the original server will have to wait for reverse IDENT TCP
connection to time out, before allowing the original connection. This will result in
horrible delays to the end user. If only the firewall would send TCP RST
response instead of discarding the packets, the server would know that IDENT
lookup fails immediately, and will present user with the service prompt. You may
allow such “reset” behavior using two commands.
service resetinbound
service resetoutside
The first one will send TCP resets for sessions that are denied, but do not
terminate on the firewall. The second one will instruct the ASA to send TCP
RSTs for the sessions that are rejected by the firewall itself. Together, those two
commands will make the firewall “less stealth” but will make end-users’s life
much easier.
-->
ASA1:
!
! Reset TCP connections denied on outside interface
! or denied inbound.
!
service resetinbound
service resetoutside
!
12. How to create BGP across the Firewall ?
• Ensure the ASA firewall runs in NAT controlled mode and RIPv2 is active
on all interfaces.
• R1 and R3 are pre-configured for eBGP peering across the firewall.
• Both routers use their Loopback1 interfaces to source the BGP session.
• Authenticate the BGP session using the password of “CISCO”.
• Ensure that R3 is allowed to initiate a BGP sessions to R1.
!
When two devices peer via BGP, they both attempt to establish a TCP session
targeted at the remote port 179. After that, one of the sessions is dropped, and
the remaining is used. In case of the ASA firewall, that means you are not always
required the permit inbound BGP sessions across the firewall, since the inside
router will initiate and establish the TCP connection. However, the scenario
explicitly asks for the outside router to be able to initiate the BGP session, and
thus we configure the outside ACL respectively.
Next, in the nat-controlmode we need a static NAT entry for the inside
router. Note that we cannot change the IP address of the peer, as we are
instructed to use BGP MD5 authentication. This authentication method is
implemented via a TCP option, which carries the MD5 hash value. The secure
hash is taken over full IP and TCP header, and thus changing the IP addresses
is not allowed.
Finally, as we remember, the firewall performs TCP ISN (Initial Sequence
Number) randomization, which is not allowed when the MD5 authentication
method is used. You can disable the randomization using the legacy syntax
static (…,…) IP1 IP2 norandomseqor using the modern MPF framework
configuration, as demonstrated in the solution. The detailed discussion of the
MPF syntax is outside the scope of this particular scenario, but you can take note
that it is applied via a special tcp_mapconstruct. In addition to disabling the
randomization of the ISN, we also permit TCP Option 19, which is used to carry
the actual MD5 authentication hash. We apply the TCP map only to the BGP
traffic by creating a special class-map that only matches BGP packets (TCP
source/destination port 179).
!
-->
! Ensure full routing reachability
!
router rip
no passive-interface inside
no passive-interface outside
!
nat-control
!
! Map R1’s Loopback1 to itself
!
static (inside,outside) 150.1.1.1 150.1.1.1
!
access-list OUTSIDE_IN permit tcp any any eq bgp
access-group OUTSIDE_IN in interface outside
!
! Allow BGP MD5 Authentication option
!
tcp-map BGP_MD5
tcp-options range 19 19 allow
!
! BGP traffic
!
access-list BGP_MD5 permit tcp any any eq bgp
access-list BGP_MD5 permit tcp any eq bgp any
!
! L3 Class-Map for BGP traffic
!
class-map BGP_MD5
match access-list BGP_MD5
!
! Inspection map
!
policy-map global_policy
class BGP_MD5
set connection advanced-options BGP_MD5
set connection random-sequence-number disable
!
service-policy global_policy global
R1:
router bgp 1
neighbor 150.1.3.3 password CISCO
R2:
router bgp 2
neighbor 150.1.1.1 password CISCO
!
R3#show ip bgp summary
<snip>
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
State/PfxRcd
150.1.1.1 4 1 19 16 2 0 0 00:02:01 1
10. Permit ICMP traffic through the firewall.
Disable fragmented packets on “DMZ” and “Outside” interfaces.
11. Handling IDENT Issues .
Configure the firewall to quickly terminate the IDENT lookup sessions
going from outside for TCP sessions initiated by inside users.
Consider both users translated using identity mappings and to the outside
interface IP address.
12. How to create BGP across the Firewall ?
• Ensure the ASA firewall runs in NAT controlled mode and RIPv2 is active
on all interfaces.
• R1 and R3 are pre-configured for eBGP peering across the firewall.
• Both routers use their Loopback1 interfaces to source the BGP session.
• Authenticate the BGP session using the password of “CISCO”.
• Ensure that R3 is allowed to initiate a BGP sessions to R1.
Fragmented IP traffic presents a potentially serious security threat. First of all,
fragment reassembly code in many OSes has been long time most vulnerable to
numerous bugs, exposing networks to the attacks such as Ping of Death.
Secondly, fragmented traffic puts higher CPU/Memory burden on the end hosts,
as it requires them to create large buffers (64K to potentially fit any fragment
size) for packet reassembly and keep them for potentially long time, while waiting
for all packet fragments. And lastly, it is a common technique to use fragmented
traffic in order to bypass security checks (such as IPS or firewall) by breaking
malicious packets into smaller fragments (this might let bypass simple firewalls,
for example).
Even if it is a good practice to avoid traffic fragmentation at any cost, it is not
possible in some situations. Two well-know examples are the use of NFSv2
(Sun’s Network File System) which transports data blocks in large UDP packets
and VPN-protected traffic, which might exceed network MTU due to
encryption/tunneling overheads.
The ASA firewall implements packet reassembly technique in order to perform
deep inspection of fragmented traffic. The firewall does not permit a fragmented
packet through, until it fully assembles it and verifies its contents. By default, the
first fragment is delayed for the duration set by fragment timeout <N>
command (5 seconds by default) until all fragments are received and assembled.
If the timeout expires before all fragments arrive, the packet is discarded. The
firewall will accept at maximum of fragment chain <limit> [interface]
fragments on the particular interface, with the default being of 24 fragments. If
the number of fragments exceeds the limit, the packet is discarded. Thus, if you
want to disable fragmented packets at all, use the command fragment chain
1to instruct the firewall dropping all fragmented packets (more than 1 fragment).
Finally, all fragments are stored in a system-wide re-assembly buffer, with the
size set using the command fragment size <N>where <N> is the maximum
number of packets held in the buffer.
-->
10. Permit ICMP traffic through the firewall.
Disable fragmented packets on “DMZ” and “Outside” interfaces.
ASA1:
!
! Remove any old configurations
!
No nat-control
clear configure access-list
access-list OUTSIDE_IN permit icmp any any
access-group OUTSIDE_IN in interface outside
!
! Disable Fragment reassembly on the mentioned interfaces
!
fragment chain 1 outside
fragment chain 1 dmz
output:
R1#ping 136.1.122.2 size 1500
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 136.1.122.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/13 ms
R1#ping 136.1.122.2 size 1510
Type escape sequence to abort.
Sending 5, 1510-byte ICMP Echos to 136.1.122.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
11. Handling IDENT Issues
Configure the firewall to quickly terminate the IDENT lookup sessions
going from outside for TCP sessions initiated by inside users.
Consider both users translated using identity mappings and to the outside
interface IP address.
-->
IDENT is the simple protocol that is designed to disclose the “owner” of the active
TCP connection. This is how IDENT works:
1) On a user’s machine, a special IDENT daemon is running and listening on port
113.
2) When a user makes an outbound connection, the remote server might initiate
reverse IDENT connection to the user’s IP address and port 113, asking for the
information on the TCP connection “owner” (to record it in the system logs).
3) The daemon returns the information and the server permits the original user’s
connection.
4) If for some reason the IDENT daemon does not respond, it’s up to the server
to decide the further connection’s fate. Nowadays, most servers would still permit
the connection.
IDENT protocol is clearly unsecure and unreliable. It might work in situations
where the user has no admin privileges over the machine he works from. In
addition to that, it requires that the user is not located behind any sort of NAT or
firewall as the translating/filtering device might not properly handle the IDENT
lookup. However, still some applications (e.g. sendmail and some FTP dameons)
continue to use IDENT lookups with their default configuration, even though they
don’t deny the hosts not running the IDENT process.
Now imagine that a user behind the ASA firewall connects to the server that does
IDENT lookups. There might be two situations:
1) User is NAT translated using the IP that “belongs” to the ASA firewall. In this
case, the reverse IDENT lookup will terminate at the ASA firewall. By default, the
ASA simply discards TCP SYN packets sent to the ports it is not listening on.
2) User’s IP has not been changed by the firewall. In this case, the IDENT
session will be attempted to the original user’s IP address. Most likely your
firewall does not permit such connections, so the TCP SYN packets will be
silently discarded.
In both cases, the original server will have to wait for reverse IDENT TCP
connection to time out, before allowing the original connection. This will result in
horrible delays to the end user. If only the firewall would send TCP RST
response instead of discarding the packets, the server would know that IDENT
lookup fails immediately, and will present user with the service prompt. You may
allow such “reset” behavior using two commands.
service resetinbound
service resetoutside
The first one will send TCP resets for sessions that are denied, but do not
terminate on the firewall. The second one will instruct the ASA to send TCP
RSTs for the sessions that are rejected by the firewall itself. Together, those two
commands will make the firewall “less stealth” but will make end-users’s life
much easier.
-->
ASA1:
!
! Reset TCP connections denied on outside interface
! or denied inbound.
!
service resetinbound
service resetoutside
!
12. How to create BGP across the Firewall ?
• Ensure the ASA firewall runs in NAT controlled mode and RIPv2 is active
on all interfaces.
• R1 and R3 are pre-configured for eBGP peering across the firewall.
• Both routers use their Loopback1 interfaces to source the BGP session.
• Authenticate the BGP session using the password of “CISCO”.
• Ensure that R3 is allowed to initiate a BGP sessions to R1.
!
When two devices peer via BGP, they both attempt to establish a TCP session
targeted at the remote port 179. After that, one of the sessions is dropped, and
the remaining is used. In case of the ASA firewall, that means you are not always
required the permit inbound BGP sessions across the firewall, since the inside
router will initiate and establish the TCP connection. However, the scenario
explicitly asks for the outside router to be able to initiate the BGP session, and
thus we configure the outside ACL respectively.
Next, in the nat-controlmode we need a static NAT entry for the inside
router. Note that we cannot change the IP address of the peer, as we are
instructed to use BGP MD5 authentication. This authentication method is
implemented via a TCP option, which carries the MD5 hash value. The secure
hash is taken over full IP and TCP header, and thus changing the IP addresses
is not allowed.
Finally, as we remember, the firewall performs TCP ISN (Initial Sequence
Number) randomization, which is not allowed when the MD5 authentication
method is used. You can disable the randomization using the legacy syntax
static (…,…) IP1 IP2 norandomseqor using the modern MPF framework
configuration, as demonstrated in the solution. The detailed discussion of the
MPF syntax is outside the scope of this particular scenario, but you can take note
that it is applied via a special tcp_mapconstruct. In addition to disabling the
randomization of the ISN, we also permit TCP Option 19, which is used to carry
the actual MD5 authentication hash. We apply the TCP map only to the BGP
traffic by creating a special class-map that only matches BGP packets (TCP
source/destination port 179).
!
-->
! Ensure full routing reachability
!
router rip
no passive-interface inside
no passive-interface outside
!
nat-control
!
! Map R1’s Loopback1 to itself
!
static (inside,outside) 150.1.1.1 150.1.1.1
!
access-list OUTSIDE_IN permit tcp any any eq bgp
access-group OUTSIDE_IN in interface outside
!
! Allow BGP MD5 Authentication option
!
tcp-map BGP_MD5
tcp-options range 19 19 allow
!
! BGP traffic
!
access-list BGP_MD5 permit tcp any any eq bgp
access-list BGP_MD5 permit tcp any eq bgp any
!
! L3 Class-Map for BGP traffic
!
class-map BGP_MD5
match access-list BGP_MD5
!
! Inspection map
!
policy-map global_policy
class BGP_MD5
set connection advanced-options BGP_MD5
set connection random-sequence-number disable
!
service-policy global_policy global
R1:
router bgp 1
neighbor 150.1.3.3 password CISCO
R2:
router bgp 2
neighbor 150.1.1.1 password CISCO
!
R3#show ip bgp summary
<snip>
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
State/PfxRcd
150.1.1.1 4 1 19 16 2 0 0 00:02:01 1
No comments:
Post a Comment