This topic is to discuss the following lesson:
Hello,
There is a typo:
"R1(config-ext-nacl)#deny ip 224.0.0.0 31.255.255.255 any
Let me explain these statements:
224.0.0.0 /4 is the multicast range." ( I think it should be 15.255.255.255 instead)
Hello sales2161
Yes you are correct, I’ll let Rene know.
Thanks!
Laz
Hi,
is this scenario relevant int he real world, in our production network, all our routers site behind fortigate firewalls,
Hello Walter
The idea of an infrastructure access list is more of a concept than an actual implementation strategy. The idea is to ensure that there are some fundamental best practices that should be enabled at the edge of your network, to protect and secure it. Now at the very least, if you simply have a router, you must employ these as simple access lists on that router, ensuring that you are blocking the appropriate ICMP packets, private addresses, and fragments, to name a few.
Now if you have a firewall or some sort of security appliance on the edge of the network, in most cases, these restrictions are already in place thanks to the default settings on the firewall. If not, then these restrictions should be configured on the security device at the edge of your network.
The concept is described here simply as a minimum security precaution that should be ensured on any network edge device.
I hope this has been helpful!
Laz
Hi Laz,
thanks helped alot.
WN
1 Like
Laz!! Does cisco share a guide with best practices on how to implement ACL in this kind of scenario? Very interesting lesson guys!
Hello Carlos
Yes, Cisco does have documentation that describes general guidelines and best practices in this regard. The following document describes many of these best practices:
https://www.cisco.com/c/en/us/support/docs/ip/access-lists/43920-iacl.html
I hope this has been helpful!
Laz
Hi Rene / Laz,
In the first part of infrastructure ACLs you mention only allowing certain types of ICMP.
I was wondering how you figured out which keywords to use. In my IOSv version there are ± 50 keywords available. The Cisco documentation I have found says these keywords match ICMP types & codes but does not specify which ones exactly. Could I for example use the keyword traceroute instead of time-exceeded and unreachable?
Hello Jurrian
Yes indeed, there are many options to choose from when creating an ACL used to filter ICMP traffic. Most of these options correspond to the various ICMP Type and Code fields found within the ICMP header. These are two 8-bit fields that are used to specify the nature of the control message. Specifically, the kind of message is identified by the value of the Type field, and the Code field gives additional context information for the message.
For example, take a look at this partial list of options for an ICMP ACL:
R-1(config-ext-nacl)#permit icmp any any ?
<0-255> ICMP message type
administratively-prohibited Administratively prohibited
alternate-address Alternate address
conversion-error Datagram conversion
dod-host-prohibited Host prohibited
dod-net-prohibited Net prohibited
dscp Match packets with given dscp value
echo Echo (ping)
echo-reply Echo reply
fragments Check non-initial fragments
general-parameter-problem Parameter problem
host-isolated Host isolated
host-precedence-unreachable Host unreachable for precedence
host-redirect Host redirect
The administratively-prohibited keyword corresponds with an ICMP control message with Type 3 Code 9. Similarly, the host-isolated keyword corresponds with Type 3, Code 8.
To see all of the types and codes available, take a look at this IANA ICMP parameters list:
https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml
Keep in mind that some type and code combinations have been deprecated.
Remember that ICMP is much more than simply a ping or a traceroute. It is a control protocol that supports the IP suite. It is used to send error messages and operational information that enables and supplements IP connectivity. If you choose to filter some types of ICMP messages using ACLs, you must first fully understand their purpose before attempting to apply any such filtering.
I hope this has been helpful!
Laz
HI Laz, Team,
Could you help me understand this access list:
R1(config-ext-nacl)#permit tcp host 3.3.3.3 host 1.1.1.1 eq bgp
R1(config-ext-nacl)#permit tcp host 3.3.3.3 eq bgp host 1.1.1.1
I thought it will be like this:
R1(config-ext-nacl)#permit tcp host 3.3.3.3 host 1.1.1.1 eq bgp
R1(config-ext-nacl)#permit tcp host 1.1.1.1 host 3.3.3.3 eq bgp
Kind Regards,
Martin
Hello Martin
Let’s take a look at the topology again:
All ACLs that we are creating in this lesson are in an inbound direction relative to R1. So they would be typically applied on the Fa0/0 interface in an incoming direction.
That means that by definition, the source IP in our ACL can never be 1.1.1.1. So for that reason alone, you wouldn’t want to apply something like this:
…since you’re only filtering incoming traffic, that is, traffic coming from the Internet towards R1. If you do, then it will never be matched, because 1.1.1.1 would never be a source of incoming traffic.
The purpose of this access list is to allow BGP sessions to take place. In a BGP session, one router acts as a listener (or server), while the other initiates the connection (as a client). The listening router listens on TCP port 179 for incoming BGP connections. The router initiating the connection uses a random high-numbered port as its source port but connects to port 179 on the listening router. Because we don’t know if R1 is the listener or the client, we must allow for both contingencies, and that is why both statements are included.
I hope this has been helpful!
Laz
1 Like
Hi Laz,
Thanks for the explanation 
Best Regards,
Martin
1 Like