In enterprise network usually dedicated servers are used to provide DHCP, DNS, TFTP, and FTP services. The clients are not usually on the same subnet as those servers. The clients used to broadcast messages to locate the servers and get services.
Now look at the figure below, Laptop0 is attempting to acquire an IPv4 address from a DHCP server using a broadcast message but it is failed to get the IP address. The Laptop0 is now configured the Automatic Private IP Addressing (APIPA). Router0 is not configured as a DHCPv4 server and it cannot forward the broadcast message. The DHCPv4 server is configured but located on a different network, so Laptop0 cannot receive an IP address using DHCP.
The Figure 2 below illustrates release and renew the process of the IP address, first we have released the IP addressing information with ipconfig /release command and then again trying to get the IP address from DHCP server using ipconfig /renew command but again attempting to renew its IPv4 address failed.
Notice when the IPv4 address is released the address is shown to be 0.0.0.0. With ipconfig /renew command laptop0 broadcast a DHCPDISCOVER message but it is unable to locate the DHCPv4 server. Because routers do not forward broadcasts so, the request is not successful.
So, we can solve this problem to add DHCPv4 servers on all the subnets. But, this solution creates additional cost and administrative overhead over the network. So, what is a better solution?
A better solution is the Cisco IOS helper-address configuration. The Cisco IOS helper enables a router to forward DHCPv4 broadcasts to the DHCPv4 server. When a router is configured to forward address assignment/parameter requests, it is called DHCPv4 relay agent.
Now, look at the example topology, When Laptop0 send a request to locate a DHCPv4 server to Router0. If Router0 configured as a DHCPv4 relay agent, it would forward the request to the DHCPv4 server located on subnet 172.16.0.0/24 network.
DHCPv4 Relay Agent Configuration
The figure below illustrates the Relay Agent configuration on Router0. The command for configuring a relay agent is ip helper-address interface configuration mode command.
After the configuration as a DHCPv4 relay agent, Router accepts broadcast requests for the DHCPv4 service and then forwards those requests as a unicast to the IPv4 address configured with ip helper-address. The show ip interface command is used to verify the configuration.
Now you can verify the IP address configuration on Laptop0 and Laptop1. Both are now able to acquire an IPv4 address from the DHCPv4 server. The figure below illustrates the IPv4 address leased from DHCPv4 server to Laptop0.
The ip helper-address command also forward Port 37 for Time, Port 49 for TACACS, Port 53 for DNS, Port 67 for DHCP/BOOTP client, Port 68 for DHCP/BOOTP server, Port 69 for TFTP, Port 137 for NetBIOS name service and Port 138 for NetBIOS datagram service.
A Cisco router can be configured as a DHCPv4 server. The DHCPv4 server assigns and manages IPv4 addresses from specified address pools within the router to DHCPv4 clients. The steps for configuring the DHCPv4 server on Cisco routers are the following:
Excluding IPv4 Addresses
The router configured as the DHCPv4 server assigns all IPv4 addresses in an address pool unless configured to exclude specific addresses. Typically, some IPv4 addresses in a pool are assigned to network devices manually. So, these addresses should be excluded from being assigned by the DHCPv4 server. Use the following command to exclude particular addresses from being assigned by DHCPv4.
ip dhcp excluded-address <FIRST_IP LAST_IP>
We can exclude a single address or a range of addresses using the first and last addresses of the range. The addresses assigned to the router, including the servers, printers, and other devices that have been manually configured, must be excluded.
Creating a DHCPv4 Pool
After Excluding IP addresses, create and define an IPv4 address pool to assign. The command for creating a DHCPv4 pool is ip dhcp pool <pool-name>. Create a pool with a meaningful name. The ip dhcp pool will also put the router into configuration mode. The prompt of the DHCPv4 mode is Router(dhcp-config)#.
Configuring other network Parameters
We configure several parameters after creating a DHCPv4 pool and entering it into DHCPv4 mode. Some of these parameters are optional, while others must be configured. The address pool and default gateway router must be configured. The DNS server, domain name, DHCP lease duration, and NetBIOS Wins server configuration are optional. The command for these parameters is the following:
Router(dhcp-config)# network <netwowrk address>
This command will attach the IP address pool to the DHCPv4 pool created earlier. The next compulsory command is defaulter-router. The command syntax is the following:
Using the above command, we configure the network’s default router or gateway. Typically, the gateway is the LAN interface of the router closest to the client devices. One gateway is usually required for a network, but we can also configure multiple gateways.
The DNS server, domain name, DHCP lease duration, and NetBIOS Wins server configuration are optional for DHCPv4. The commands for these optional parameters are the following:
The figure below shows a sample configuration with basic DHCPv4 parameters configured on router Router0, a DHCPv4 server for the 192.168.1.0/24 LAN.
The DHCPv4 service is, by default, enabled on most Cisco IOS. If someone needs to disable the DHCP service, use the “no service dhcp” command in global configuration mode. To re-enable the service, use the “service dhcp” command in global configuration mode.
Verifying DHCPv4
In the above example, we have configured the DHCPv4 server on Router0 to provide DHCPv4 services to the corresponding LAN. We can verify the DHCPv4 configuration using different commands.
We can use the show running-config command to display the DHCPv4 configuration. We can also use the | pipe to display only the parameter associated with the DHCPv4 configuration; for example, show running-config | begin dhcp. The figure below illustrates the output of this command.
We can verify the DHCP operation using the show ip dhcp binding command. The output of this command is shown in the figure below. It displays a list of all IPv4 addresses to MAC address bindings provided by the DHCPv4 service.
Another command for DHCP operation verification is show ip dhcp server statistics. This command verifies that messages are being received or sent by the router. This command also shows the counter about the number of DHCPv4 messages that have been sent and received.
We can also use the command show ip dhcp pool <pool-name>. The figure below illustrates the output of this command.
We can also verify the DHCPv4 process from the computer running and connected to the DHCPv4 server. As shown in the Figure below, using the ipconfig /all command, we can verify the computer’s IP address information. If an IP address is issued on the computer, it will display the TCP/IP parameters.
In the figure, you can see the output of the ipconfig /all command. The computer-issued IP address is 192.168.1.11, and the DHCP server address is 192.168.1.1. It automatically received an IPv4 address, subnet mask, default gateway, and DNS server address from that pool.
As discussed in the previous lesson, DHCPv4 clients and servers exchange messages to exchange IP address information. The format of all DHCPv4 messages is common and based on the BOOTP specification.
The DHCP v4 uses UDP port numbers 67 and 68 with BOOTP. Post 68 is the DHCPv4 source port number, while port 67 is the destination port. DHCP messages contain a special option in the option field that differentiates them from BOOTP messages. The figure below illustrates the DHCPv4 message format.
OP Code –This is an 8-bit field specifying the message type. It has two different states: a value of 1 indicates a REQUEST message, and a value of 2 indicates a REPLY message.
Hardware Type– This is also an 8-bit field that identifies the type of hardware used in the network. This field identifies the hardware address type.
Hardware Address Length—This is another 8-bit field to identify a DHCP client’s address length.
Hops—This field counts and controls the relay agent and message forwarding. This client set the field to 0 before transmitting a request.
Transaction Identifier– The client uses this field to match the request with replies received from DHCPv4 servers.
Seconds– This field identifies the elapsed time in seconds since a client began attempting to get the IP address on a lease basis or renew a previous lease. The DHCPv4 servers use this field to prioritize replies when multiple client requests are outstanding.
Flags—As shown in the figure, this is a 16-bit field of the DHCPv4 message. A client without an IPv4 address uses this field when sending a request. Only one bit (leftmost) out of 16 bits is used: the broadcast flag. If this flag is set to 1, the DHCP server sends a reply by broadcast. The remaining bits of the flags field are reserved for future use.
CIADDR—This is the client IP address field used during lease renewal when the client’s address is valid and usable. The client puts its own IPv4 address in this field if it has a valid IPv4 address while in the bound state; otherwise, it sets the field to 0.
YIADDR – ‘your’ (client) IPv4 address assigned by the server to the client.
SIADDR—This is the IP address of the following server for the client to use in the configuration and bootstrap process, which may be the same server sending this reply. The sending server always includes its IPv4 address in a particular field called the Server Identifier DHCPv4 option.
GIADDR– This is a gateway or relay agent IP address. The IP address may be the interface IP of the relay agent through which the DHCP message was received. It facilitates communications of DHCPv4 requests and replies between the client and a server that are on different subnets or networks.
CHADDR – This field matches responses from servers with previously transmitted requests and specifies the physical layer of the client system.
Server Name– Used by the server sending a DHCPOFFER or DHCPACK message. The server may optionally put its name in this field. This can be a simple text nickname or a DNS domain name, such as dhcpserver.netacad.net.
SNAME: Server hostname, sending a DHCPOFFER or DHCPACK message. This can be a simple text nickname or a DNS domain name.
Boot Filename– The client uses a boot file name optionally to request a particular type of boot file in a DHCPDISCOVER message and a server also used this in a DHCPOFFER to fully specify a boot file directory and filename
DHCP Options– This is an optional field that holds several parameters required for basic DHCP operation. The length of this field is not fixed. Both the client and server use this field.
Every device on the Internet, and every device on any network, needs a unique IP address. Network administrators can assign static IP addresses to routers, servers, and printers whose locations are not likely to change. The IP addresses assigned to these devices are usually not changed. The static addresses also enable administrators to manage these devices remotely because the network administrator can easily access a device when they determine its IP address.
The users in an organization and a network usually change locations physically and logically. So, it is very difficult and time-consuming for network administrators to assign new IP addresses every time an employee changes their location. Also, manually assigning and setting the correct network parameters is not easy for mobile employees working from remote locations.
The Dynamic Host Configuration Protocol (DHCP) server was introduced to assign IP addresses automatically. Using a centralized DHCP server, administrators can assign IP addresses dynamically from a single server. The DHCP server makes IP address management effective and ensures consistency across the organization and its branch offices. DHCP has two versions: DHCPv4 for IPv4 addresses and DHCPv6 for IPv6 addresses. Our focus will be on DHCPv4 in detail.
DHCPv4 can assign IPv4 addresses, including other network parameters dynamically. A dedicated server for DHCPv4 is a useful, time-saving, and easy-to-manage tool for network administrators. Although, in a small office and organization, a Cisco router can be configured to provide DHCPv4 services without a dedicated server. A Cisco IOS also provides an “Easy IP” like a full-featured DHCPv4 server. DHCPv4 has three different address allocation mechanisms:
Manual Allocation– The DHCPv4 communicates with a pre-allocated IPv4 address assigned manually to the network devices.
Automatic Allocation– DHCPv4 automatically assigns IPv4 addresses to a device permanently from a pool of available addresses.
Dynamic Allocation– DHCPv4 dynamically assigns IPv4 addresses from a pool of addresses for a limited period. The server assigns an address to a device on lease bases for a specific period.
Using dynamic allocation, clients lease IP addressing information from a DHCP server for a specific period. The administrator defines the lease time according to the network resources and requirements and sets the leases to time out at different intervals. When the lease expires, the client must ask for another address, although the client is typically reassigned to the same address. The figure below illustrates the DHCP process.
DHCPv4 Operation
As the figure above illustrates, when a client computer communicates with a DHCPv4 server, the server assigns or leases an IPv4 address to that client, and the client connects to the network with that leased IP address until the lease expires.
Usually, IP servers assign IP addresses on a lease basis; therefore, the client must contact the DHCP server periodically to renew the lease. When a lease expires, the DHCP server adds the IP address to the pool, where it can be reallocated as needed. When the client boots or wants to connect and join a network, it begins the process to obtain an IP address on lease bases. The client starts the process with a broadcast DHCPDISCOVER message.
DHCP Discover (DHCPDISCOVER)
The client does not have a valid IPv4 address at bootup; therefore, it uses the DHCPDISCOVER message to find the DHCPv2 server for IP address information. It uses Layer 2 and Layer 3 broadcast addresses to communicate with the server. The figure below illustrates the DHCPDISCOVER message.
DHCP Offer (DHCPOFFER)
Once the DHCPv4 server receives a DHCPDISCOVER message from the client, it reserves the available IPv4 address for that client and creates an ARP packet containing the requesting client’s MAC address and the leased IPv4 address for that client.
The figure below illustrates the DHCPOFFER message to the requesting client. The DHCPOFFER message is sent as a unicast message, using the server’s Layer 2 MAC address as the source and the client’s Layer 2 MAC address as the destination.
DHCP Request (DHCPREQUEST)
The client accepts the first DHCPOFFER message received and sends back a DHCPREQUEST message to the server. Many large networks use multiple DHCPv4 servers, so the DHCPREQUEST serves as a binding receipt notice to the chosen server for the offered information.
The message also implicitly declines any other servers that may have provided the client with a binding offer. The message is also sent back as a broadcast to inform all available servers in the network. The DHCPREQUEST is also used for lease renewal.
DHCP Acknowledgment (DHCPACK)
The server replies with a DHCPACK message to finish the DHCP session. DHCPACKt verifies the lease information with an ICMP ping to the leased address to check that it is not used elsewhere.
If the address is not being used, a new ARP entry for the client lease will be created, and a unicast DHCPACK message will be sent. This message is a duplicate DHCPOFFER message, excluding a change in the message type field.
After receiving the DHCPACK, it records the address configuration information and performs an ARP lookup for the assigned address. If there is no response to the ARP, the client knows that the IPv4 address is valid and starts using it as its own. The figure below illustrates the DHCPACK message.
Lease Renewal
When the lease period has expired, the client sends a DHCPREQUEST message as unicast directly to the DHCPv4 server that previously offered the IPv4 address. If a DHCPACK is not received within a particular time, the client sends DHCPREQUEST messages as broadcasts to get and renew an IP address from other DHCPv4 servers.
When the server receives the DHCPREQUEST message from the client, the server verifies the lease information using a DHCPACK message. The figure below illustrates the DHCP renewal process of DHCPv4.
IPv6 ACLs are similar to IPv4 ACLs. If you can understand IPv4 access lists, IPv6 ACLs are not difficult for you to understand and configure. IPv4 has two types of ACLs: standard and extended. Both can either be numbered or named ACLs, but IPv6 ACLs are only one type, similar to IPv4 extended-named ACLs in function and configuration. IPv6 has no numbered ACLs. IPv6 ACLs cannot share the same name as IPv4 ACLs.
Comparing IPv4 and IPv6 ACLs
There are three major differences between IPv4 and IPv6 ACLs.
Applying an IPv6 ACL
IPv4 uses the command ip access-group command to link and apply an ACL to an IPv4 interface but IPv6 uses the ipv6 traffic-filter command to perform the same task for IPv6 interfaces.
Wildcard Masks and IPv6 Prefix length
IPv6 ACLs do not use wildcard masks. It uses the prefix length to indicate how much of an IPv6 source or destination address should be matched.
Additional Default Statements
The major difference between IPv4 and IPv6 ACL is an implicit permit statement. Each IPv6 ACL required two implicit permit statements at the end. At the end of every IPv4 standard or extended ACL, the implicit permit statement is deny any or deny ip any any.
The IPv6 also has the similar deny ipv6 any any statement at the end of each IPv6 ACL, but it also includes two other implicit statements, which is “permit icmp any any nd-na” and “permit icmp any any nd-ns”
The “permit icmp any any nd-na” and “permit icmp any any nd-ns” allow the IPv6 equivalent of ARP for IPv4. We have already discussed ARP in previous articles. ARP resolves the Layer2 MAC addresses while the IPv6 uses ICMP Neighbor Discovery (ND) messages to accomplish the same task.
ND has two types of messages: Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages, which are encapsulated in IPv6 packets and use IPv6 network layer services, but ARP uses layer2 services.
So, IPv6 ACLs need to implicitly permit ND packets for both directions on an interface. Therefore, both Neighbor Discovery – Neighbor Advertisement (nd-na) and Neighbor Discovery – Neighbor Solicitation (nd-ns) messages are permitted. The figure below illustrates the ND process.
Configuring IPv6 ACLs
We use a topology similar to the previous IPv4, except for the IPv6 addressing scheme. The addressing scheme is shown in topology in the figure below. There are seven subnets with the/64 prefix. You can verify the IPv6 interface configuration using the show ipv6 interface brief command in the interface configuration mode.
Recall that we can set the IPv6 address on the router interface using the “IPv6 address <Ipv6 address/ prefix> “ for example, If I want to set the IP address on router0 interface fa0/0, the command should be: R0(config-if)# IPv6 address 2001:DACA:1::1/64
The command syntax for IPv6 is similar to the syntax used for an IPv4 extended ACL. The difference between both command syntax is using the IPv6 prefix-length instead of an IPv4 wildcard mask. The command syntax for IPv6 ACLs is the following:
You can see that the parameter is similar to IPv4 syntax parameter except for the prefix/prefix-length. The steps for IPv6 ACL configuration are the following:-
Use theipv6 access-list <name>command to create an IPv6 ACL. The name can be alphanumeric, case sensitive, and must be unique and there is no need for a standard or extended option.
From the IPv6 named ACL configuration mode, use the permit or deny statements to specify one or more conditions to decide if a packet is forwarded or dropped.
Apply the ACL to Interface using ipv6 traffic-filter
The figure below illustrates the steps to create an IPv6 ACL with a simple example. The first statement names the IPv6 access list NO- ACCESS-SERVER. Similar to IPv4 named ACLs. The second statement denies all IPv6 packets from the 2001:DACA:4::/64 to server0. The third statement allows all other IPv6 packets.
Applying an IPv6 ACL to an Interface
When configuring the access control list, you must link to an interface using the ipv6 traffic-filter command. The syntax linking ACL to an interface is following:
R2(config-if)# ipv6 traffic-filter <access-list-name>{ in| out }
The figure below illustrates the NO-ACCESS-SERVER configured previously and the commands used to apply the IPv6 ACL outbound to the fa0/0 interface. To remove an ACL from an interface, first, enter the no ipv6 traffic-filtercommand on the interface, and then enter the global no ipv6 access-list command to remove the ACL. Like IPv4 ACL IPv6 ACL also uses an access-class command to apply an access list to VTY ports. To apply the above-configured ACL use the following commands on router2.
R2(config)#interface FastEthernet 0/0
R2(config-if) ipv6 traffic-filter NO-ACCESS-SERVER0 in
R2(config-if)exit
R2(config)
Verifying IPv6 ACLs
We can use similar commands to verify an IPv6 access list to those used for IPv4 ACLs. We can use the show ipv6 interface command to verify and confirm that ACL is configured inbound or outbound on the interface.
We can use the show access-lists command to displays and verify all access lists configured on the router including both IPv4 and IPv6 ACLs. The difference here is the sequence number; the sequence numbers of IPv6 ACLs occur at the end of the statement and not the beginning as with IPv4 access lists.
The IPv6 ACEs appear in the order they were entered during configuration. They are not always incremented by 10. The IPv6 access lists are also processed and displayed in the order the statements are entered. We can also verify the IPv6 ACL configuration using the show running-config command.
As discussed earlier, we can troubleshoot the ACL error using the show commands. The wrong-order ACEs are the most common ACL errors. This article will discuss some common errors in ACL configuration
ACL Error – Example 1
In the figure, host 192.168.2.2 has no HTTP or HTTPS access with 192.168.4.2. When entering the show access-lists command, matches are shown for the first deny statement, which indicates that traffic has matched this statement.
Now, look at the order of the entries. Host 192.168.2.2 has no connectivity with 192.168.4.2 because of the rule process ID 10 order in the access list. When the router processes ACLs from the top to down, statement 10 denies host 192.168.2.2 for TCP traffic, so statement 20 can never be matched. Statements 10 and 20 should be reversed. The third line allows all other non-TCP traffic under IP, such as ICMP, UDP, etc.
ACL Errors – Example 2
The network 192.168.2.0/24 cannot use TFTP to connect to the 192.168.4.2 server.
The 192.168.2.0/24 network cannot use TFTP to connect to 192.168.4.2 because TFTP uses UDP. However, when we use the show access-list command, the statement has no permit entry for UDP traffic.
The access list allows all other TCP traffic, and UDP is implicitly denied. The implied deny any statement does not appear in the show access-lists output, so matches are not shown. The third statement must be changed to ip any any instead of tcp any any.
ACL Errors – Example 3
In the topology in the figure, the 192.168.1.0/24 network can use Telnet to connect to 192.168.4.0/24, but this is not according to policy; this connection should not be allowed. The results of the show access-lists command show that the permit statement has been matched.
The 192.168.1.0/24 network can use Telnet because the Telnet port number in statement 10 of access-list 101 is listed incorrectly in the ACL statement.
It currently denies any source packet with a port number equal to Telnet. To deny Telnet traffic inbound on fa0/0, we need to deny the destination port number equal to Telnet. For example, deny TCP or any eq telnet.
When a router receives a packet, it starts comparing the information in the packet header with the ACL. If the information in the packet header and an ACL entry match, the rest of the entries in ACLs are skipped, and the packet is permitted or denied as configured by the matching entry. If the information in the packet header does not match an ACE, the packet is tested with the next ACE in the list. The matching process continues until the end of the list is reached.
When the matching process ends, and no match is found, the implied statement is applied to the packet. This statement is not shown in the output. This implicit deny matches all packets that have no match found and results in a “deny” action, so Instead of proceeding in or out of an interface, the router discards and drops all of these remaining packets. This statement is referred to as the “implicit deny any” statement. So, due to this statement, an ACL should have at least one permit statement. Otherwise, the ACL blocks all traffic. The figure below illustrates the inbound ACL logic process.
Outbound ACL Logic
The outbound ACL logic is a little different than the inbound ACL logic. The figure below illustrates the outbound ACL logic. The router receives the traffic and sends it to the routing table. The routing table processes the packet if the packet is not routable the route drop the packet, if the packet is routable then the router sends the packet for ACL matching. Next, the router checks whether the outbound interface is grouped to an ACL. If the outbound interface is not grouped to an ACL, the packet is sent directly to the outbound interface.
If the outbound interface is grouped to an outbound ACL, the packet is not sent directly to the outbound interface until it is matched with the ACEs in the ACL linked to that interface. Based on the ACL matching process, the packet is permitted or denied.
ACL Logic Operations
When a router receives a frame at the router interface, it checks the destination Layer 2 address to see if it matches its interface Layer 2 address or whether the frame is a broadcast frame. If the frame address is accepted, the frame information is stripped off, and the router checks for an ACL on the inbound interface. If an ACL exists on the inbound interface, the packet is tested against the entries in the list.
If the packet matches an entry, it is either permitted or denied. If the packet is permitted in ACEs, it is then checked against routing table entries to decide the destination interface. If a routing table entry exists for the destination address, the packet is switched to the outgoing interface; otherwise, it is dropped.
When the routing table forwards a packet to the outgoing interface, the router checks whether the outgoing interface has an ACL linked. If an ACL exists, the packet is tested against the entries in the list. If the packet matches an entry in the list, it is either permitted or denied. Suppose there is no ACL on the outbound interface or the packet is permitted. In that case, the packet is encapsulated in the new Layer 2 protocol and forwarded out the interface to the next device.
Standard ACL Decision Process
Standard ACLs examine only the packet’s source IP address; they do not check the packet’s destination or consider the ports involved. Cisco IOS tests the address against the conditions in the ACL one by one. The first match decides whether the packet is accepted or rejected. Because Cisco IOS stops testing conditions after the first match is found, the order of the conditions is serious. If no conditions match, the address is rejected.
Extended ACL Decision Process
The extended ACL decides using the source and destination addresses, protocol, and port numbers. The ACL first filters traffic on the source address, then on the port and protocol of the source. It then filters traffic on the destination address, then on the port and protocol of the destination, and finally makes a permit or denies decision. The ACEs are processed one after the other, So no-decision
The number of extended ACLs starts from 100 to 199 and 2000 to 2699, providing 799 possible extended numbered ACLs. We can also create extended ACLs with the name. Extended ACLs are used more than standard ACLs because of greater control and facilities.
Extended ACLs check packet source addresses, destination addresses, protocols, and port numbers. For example, an extended ACL can simultaneously allow FTP traffic from a network to a specific destination while denying all other traffic and web browsing.
Configuring Extended ACLs
Extended ACLs can filter protocols and port numbers. Network administrators can build extremely specified extended ACLs using either the port number or the name of well-known port numbers. The extended ACLs use logical operations such as eq for equal, neq for not equal, gt for greater than, and lt for less than.
The configuration steps for extended ACLs are not different than standard ACLs. Like the standard ACLs, first, we configure ACLs, and then they are activated on an interface. The command syntax and parameters are more complex than standard ACLs due to additional features.
The order in which the statements are entered during configuration is the order in which they are displayed and processed. The command syntax for configuring Extended ACL is the following:
access-list <access-list-number> {deny | permit | remark} protocol {source source-wildcard} [operator port <port-number or name>] {destination destination-wildcard} [operator port [ port-number or name>]
The parameter detail is the following:-
access-list-number – The parameter identifies the access list using a number. The range of extended ACL is from 100 to 199 and from 2000 to 2699.
deny – it denies access if the condition is matched.
Permit – it permits access if the condition is matched.
Remarks – This parameter is used to enter a remark and comment to the access list
protocol – The common protocol is ICMP, IP, TCP and UDP. The IP keyword is used to match any protocol.
Source – This parameter specifies the number of the network or host from which the packet is being sent.
Source-wildcard – wildcard bits are applied to the source address. It is opposite to the subnet mask.
destination – This parameter specifies the destination host or network, which is the packet’s destination.
destination wild-card – This is the wildcard for the destination network.
operator – This is an optional parameter for comparing source or destination port. The possible operands are lt, gt, eq, neq, and range.
established – This is also an optional parameter for the TCP protocol only. It shows the established TCP connection.
Note:- You can see that there are many keywords and parameters for extended ACLs, but it is unnecessary to use them all when configuring an extended ACL.
Example-1 Extended ACL Configuration
In this example, suppose you are a network administrator and want to allow website browsing only from the network 192.168.2.0/24. The web traffic uses port 80 for HTTP and port 443 for HTTPS traffic. The HTTP traffic requires flow back into the network from the website accessed by the clients.
The administration also wants to restrict this return traffic to HTTP exchange from the requested website while denying all other traffic. The figure below illustrates the ACL configuration for the same.
ACL 101 allows requests to port 80 (HTTP) and port 443 (HTTPS), while ACL 104 blocks all incoming traffic except for previously established connections. The permit statement in ACL 104 allows inbound traffic using the established parameter.
The established parameter also allows traffic that originates from the 192.168.2.0/24 network to return to that network. Without an established parameter, clients can send traffic to a web server but not receive traffic returning from the web server.
Applying Extended ACLs to Interfaces
In the previous example, you configured the ACL to allow users from the 192.168.2.0/24 network to browse HTTP and HTTPS websites. The ACL is configured, but it will not filter traffic until it is applied to an interface.
Just like standard ACL, it is necessary to consider whether the traffic to be filtered is going in or out. So when a user in the network 192.168.2.0/24 accesses a website on the server, traffic goes out to router3. When a user in the network 192.168.2.0/24 receives data from the server, traffic is coming into the local router.
In the above topology, Router3 has three interfaces. Remember that an extended ACL should be applied close to the source, so the closest interface to the source in this topology is fa0/1. Web request traffic from users on the 192.168.10.0/24 LAN is inbound to the fa0/0 interface, and return traffic from established connections to users on the LAN is outbound from the fa0/0 interface. So we will apply the ACL to the fa0/0 interface in both directions, as shown in the figure below.
Example- 2 Restrict FTP Connection
In this example, we must deny FTP traffic from subnet 192.168.1.0 and allow all other traffic to server0. The FTP uses TCP port 20 and 21, therefore the ACL requires both port name keywords FTP and ftp-data or eq 20 and eq 21 to deny FTP. So if we use name, then the command would be.
I have already discussed the implied deny in standard ACL. This ACL also contains implied deny, so to prevent the implied deny any statement at the end of the ACL from blocking all traffic, the permit ip any any statement must be added to the end.
The ACL should be applied inbound on the Fa0/1 interface to filter traffic from the 192.168.1.0/24 LAN as it enters the router interface. The figure below illustrates the configuration of the above-discussed ACL.
Example-3 Restrict Telnet Connection
Like FTP traffic, we can also configure and restrict telnet to any network or individual host. The example below denies Telnet traffic from any source to 192.168.4.2 (Server0) but allows all other IP traffic. The ACL will be configured on Router2, interface Fa0/0 outbound. The permit statement has also been added to ensure no other traffic is blocked.
Creating Named Extended ACLs
Just like named standard ACLs, we can configure named extended ACLs similarly. For creating named standard ACLs, follow the steps below.
Enter into global configuration mode.
Use the ip access-list extended<name> command to define a name for the extended ACL and enter to named ACL configuration mode.
In named ACL configuration mode, enter the conditions to permitordeny
Exit the named ACL mode and apply the ACL to the desired interface.
Return to privileged EXEC mode and verify the ACL with the show access-lists namecommand as well as using show running-config
Save the entries in the configuration file with the copy running-config startup-config
To remove a named extended ACL, use the no ip access-list extended <name> in the global configuration command.
Example of Named Extended ACL
The figure below illustrates the named extended ACLs for FTP services. We have already configured this ACL for network 192.168.1.0/24 to restrict accessing the FTP services of server0.
So, let us create the same ACL with a name for the same network. The named ACL denies the users on the 192.168.1.0/24 LAN access to the FTP service to the server and allows all other traffic. The figure below illustrates the configuration.
Verifying Extended ACLs
ACL verification is an essential step in the ACL configuration. When ACL has been configured and applied to an interface, use show commands to verify the configuration. We can verify the ACLs using “show access-list” command, “show running-config” command and “show ip interface <interface-number>” command.
The extended ACLs do not implement the same internal logic and hashing function as standard ACLs. The output and sequence numbers are the order in which the statements were entered. Host entries are not automatically listed before range entries. The show ip interface verify the ACL on the interface and the direction in which it was functional.
After verifying the ACL configuration, confirm that the ACLs work according to plan. Check to block and permit traffic as expected.
Editing Extended ACLs
As discussed earlier, extended ACL editing is the same as standard ACL editing. The methods of editing extended ACL are the following:
Using Text editor– Copy the ACL and paste it into the text editor where the changes are made. Remove the current access list using the no access-list Copy and paste back the modified ACL into the configuration.
Using Sequence numbers– This method deletes the sequence numbers and then re-enter the correct statement using the sequence number. Enter into named ACL configuration mode using ip access-list extended <name>. If the ACL is numbered instead of named, use the ACL number in place of the name parameter. ACEs can be inserted or removed.
Social engineering is a non-technical way for a criminal to collect information on a target. It is an art of gaining entrée to buildings, systems, or data by exploiting human psychology instead of breaking in or using technical hacking techniques.
For example, instead of finding software vulnerability, a social engineer might call an employee and act as an IT support person, trying to dodge the employee into exposing his password. A social engineer usually manipulates people into breaking standard security rules and best practices to gain access to systems, networks, and physical locations or for financial gain.
Social engineers often use the People’s willingness but also victimize people on their weaknesses. For example, an attacker calls to authorize an employee with an urgent problem that requires immediate network access. Using name-dropping techniques, the attacker can request the employee’s pride and raise authority. These are some types of social engineering attacks:
Type of Social Engineering
Pretexting
When an attacker calls someone and lies to them to gain access to confidential data, for example, it involves an attacker who pretends to get personal or financial data to confirm the recipient’s identity.
Quid pro quo
When a social engineer requests personal information from a party in exchange for something, it is a quid pro quo. For example, a hacker calls random numbers within an organization and pretends to be calling back from tech support. Ultimately, the attacker will find someone with a real issue who they will then pretend to help. The attacker finds the target, target information, and password through this.
Baiting
When an attacker leaves a device infected with malware, such as a USB drive, Then someone finds the USB, finder then picks up the device and loads it onto a computer, accidentally installing the malware.
Water-holding
When a criminal attempts to compromise a specific group of people by infecting websites with malware that targets users accessing the website.
Diversion theft
The social engineers trick a delivery or courier company into going to the wrong pickup or drop-off place, thus intercepting the transaction.
Honey trap
The social engineer has shown himself as an attractive person who interacts with a person online, fakes an online relationship, and gathers sensitive information through that relationship.
Tailgating Piggybacking
Tailgating is also known as piggybacking.Piggybacking is a physical security breach where an unauthorized person follows an authorized person to enter a secured premises.
Rogue
Rogue security software is a type of malware that tricks targets into paying for the fake removal of malware.
Phishing, Spear Phishing, Vishing, and Scareware – we have already discussed these types.
Social Engineering Tactics
There are several tactics in social engineering tactics, including:
Intimidation– The secretary of a senior official receives a call stating that her/his boss is about to give an important presentation, but the required file is corrupt. The cybercriminals ask for the file to be sent to them via email or other mail.
Consensus– Criminals create a site with fake testimonials promoting a product, indicating it is safe.
Scarcity and Urgency – Criminals usually offer a limited opportunities, and People will take action when they think there is a limited quantity or a limited time and become victims
Familiarity/Liking– People to do what another person asks if the victims like that person.
Trust– Criminals build a relationship with a victim. For example, as a security expert criminal calls the victim offering advice and help. While helping, the criminals get important information from the victim’s computer.
Security backholes can affect web browsers. The web browser displays pop-up promotions collects identity information, or installs adware, viruses, or spyware. A cybercriminal can hack a browser’s executable file, a browser’s components, and plugins.
Browser Plugins
A browser plugin is a software that acts as an add-on to a browser and installs extra functions in the browser. Browser plugins allow a browser to show additional unavailable content by default. For example, the Macromedia Flash Player and Shockwave are browser plugins.
These browser plugins display attractive graphics, cartoons, and animations that improve the look of a web page. Browser Plugins also display the content developed using the software.
Quicktime Player and Acrobat Reader are also popular plugin applications. Most plugins are available and free for download. To install a plugin, you visit the plugin’s website and click on a link that will download the installer for the plugin.
Download and save the installer. Once you have a copy of the installer, open it and follow the prompts to install the plugin on your system. You may have to restart your web browser to enable the plugin’s other functionality.
As Flash and Shockwave content became popular, the criminals examined these plugins and software, determined vulnerabilities, and exploited Flash Player. The successful operation causes a system crash or allows a criminal to get control of the affected system, which expects data losses to occur. The criminals also continue investigating the more popular plugins and protocols for vulnerabilities.
SEO Poisoning
Search engines assign page ranking and present vital results based on users’ search queries. Depending on the site content, it may show higher or lower in the search result list. Search Engine Optimization (SEO), is used to improve the ranking of a website in search engines.
Many legitimate organizations and companies are working to optimize websites to better rank on search engines. SEO poisoning is a technique that uses cybercriminals to make a malicious website appear higher in search results.
The goal of SEO poisoning is to redirect more traffic to malicious websites. These sites perform different harmful activities, such as malware hosting and social engineering.
Browser Hijacker
Browser hijacking is malware that modifies a web browser‘s settings without a user’s permission. It redirects the user to the cybercriminals’ websites. This software aims to help cyber criminals.
The browser hijacker is usually part of the drive-by download, a software program that automatically downloads to the victims’ computers when a user visits a harmful site. To avoid browser hijacking, read the user agreements carefully when downloading software. It usually changes the default search engine and homepage.
For example, a browser redirects the victim’s homepage to the hijacker’s search page and then redirects the victim’s search to links the hijacker wants the victim to visit. The hijacker also causes slow loading because it installs multiple toolbars in the browsers. The hijacker also displays multiple pop-up advertisements without the users’ permission.
Defending Against Email and Browser Attacks
Educating the end-user about being cautious towards unknown email(s) and using host/server filters is helpful against defending spam and emails. The organization must also educate its employees about the dangers of opening email attachments containing viruses or worms.
Do not suppose that email attachments are safe. Even if the mail is from trusted sources, the virus can use the sender’s computer to spread itself. Always scan email attachments before opening them.
Defending against spam is not easy, but reducing its effect is possible. For example, ISPs and Email service providers filter spam emails. Antivirus and email software also automatically do email filtering. This software detects and removes spam from an email inbox.
The Anti-Phishing Working Group (APWG), founded in 2003, is an international consortium focused on eliminating the identity theft and fraud that result from phishing and email spoofing. The APWG also keeps all software updated and makes sure that the latest patches keep away vulnerabilities.
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept”, you consent to the use of ALL the cookies.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Duration
Description
cookielawinfo-checkbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
