Synopsis

When it comes to the security regarding routers, switches or on the basic ISP layers, we talk about ACLs.  They are generally used to control/manage the inbound and outbound traffic.  In this blog, we will be looking into basic configuration of standard IP ACLs also known as Access Lists or in some cases filters.

Understanding ACL

Access Control List as the name suggests is a list that grants or denies permissions to the packets trying to access services attached to that computer hardware.  ACLs are usually implemented on the fire-wall router, that decides about the flow of traffic.  If the packet matches the specified paramaters, then it is allowed to travel inside the network else the packet is dropped there with.

Why ACL?

There are several other purposes for understanding this basic block of networking.  ACLs help in prioritizing the traffic for specific cases (to ensure Quality of Services), limiting or sometimes restricting remote users from accessing the network, managing and debugging VPN and many other tricks.

Hierachy

In some cases, there is a set of conditions that the data packet must meet inorder to be allowed inside the network.  While mentioning those requirements, the hierachy of the conditions is to be kept accounted for.  If the packet does meet upto the first set of rules, the ACL will stop further examining the packet and will be allowed therewith.  So make sure you first lay down a structure in a proper order form or your ACL can be rendered useless.  In case you want to define a new condition/rule, it is appended at the end of the ACL.  Also, you can not delete any specific statement after it has been configured.  The only way to alter it is to delete the access list and reconfigure it to the router.

Standard ACL

The Standard ACLs have the range between 1-99 and 1300-1999.  This list was used for basic filtering i.e the router checks the address of the source IP and makes the decission whether to allow the traffic or discard it.

Configuring

To configure a standard list, we have the following code:

router(config) # access-list access-list-number {permit | deny} {source [source-wildcard] | host hostname |any}

Here, access-list-numberis a numeric number (in our case ranging between 1-99 or 1300-1999) as mentioned above.  The next parameter, permit|deny speaks for itself.  The third parameter could either be the source addresses that are to be checked or could be a specific host, or any that means to look out for all traffic.

One thing that needs mentioning here is the source-wildcard.  In simple words, it masks the source address with an inverse mask.

Or you could use the numbered ACL;

router(config)# ip access-list standard {access-list-name}
router(config-std-nacl)# [sequence-number] {permit | deny} {source [source-wildcard] | host hostname | any}

After the definition, the ACL is to be applied to the interface.  In previous software versions, out was default, but in latest releases, the direction needs to be mentioned.

router(config-std-nacl)# interface ip access-group number {in|out}

The keyword in will apply the ACL to all the inbound traffic through the interface, whereas the out will look after the outgoing traffic.

Another working example from Cisco;

R1:

Define an access-list 1 allowing the network 155.1.0.0 and it’s corresponding subnet mask

router(config)# access-list 1 permit 155.1.0.0 0.0.255.255

then, you have to apply this access-list 1 to the interface of your choice, it is ethernet0/100 in our case;

router(config)# interface GigabitEthernet0.100
router(config-if)# ip access-group 1 in

Standard ACLs only allow you to match source IP addresses based on “base” IP address and wildcard mask. Because of that “aggregate” behavior, standard ACLs are commonly configured at network nodes close to the “protected” object. One very common task is finding a required base IP address and wildcard mask pair based on a set of requirements.

The commands that we commonly use for checking ACLs are;

router# show ip interface GigabitEthernet0.100 | include access [here we have used the 'pipe | sign'

The output of the above command is below:

 Outgoing Common access list is not set 
 Outgoing access list is not set 
 Inbound Common access list is not set Inbound access list is 1 
 IP access violation accounting is disabled

Let’s us have an example from Juniper networks in which we will deny the ssh and telnet protocols.;

You first have to go in the [edit] menu and apply the family inet filter named {local_acl} and define the terminal_access setting:

 router# set firewall family inet filter local_acl term terminal_access from source-address 192.168.1.0/24 
 router# set firewall family inet filter local_acl term terminal_access from protocol tcp> 
 router# set firewall family inet filter local_acl term terminal_access from port ssh 
 router# set firewall family inet filter local_acl term terminal_access from port telnet 
 router# set firewall family inet filter local_acl term terminal_access then accept 
 router# set firewall family inet filter local_acl term terminal_access_denied from protocol tcp 
 router# set firewall family inet filter local_acl term terminal_access_denied from port ssh 
 router# set firewall family inet filter local_acl term terminal_access_denied from port telnet 
 router# set firewall family inet filter local_acl term terminal_access_denied then log 
 router# set firewall family inet filter local_acl term terminal_access_denied then reject 
 router# set firewall family inet filter local_acl term default-term then accept 
 router# set interfaces lo0 unit 0 family inet filter input local_acl 
 router# set interfaces lo0 unit 0 family inet address 127.0.0.1/32

References and Further Reading

Cisco IOS Security Configuration Guide

Configuring a Filter to Block Telnet and SSH Access