Access List
Question 1
Explanation
The first answer is not correct because the 10.0.0.0 network range is not correct. It should be 10.0.0.0. to 10.255.255.255.
Question 2
Explanation
Logging-enabled access control lists (ACLs) provide insight into traffic as it traverses the network or is dropped by network devices. Unfortunately, ACL logging can be CPU intensive and can negatively affect other functions of the network device. There are two primary factors that contribute to the CPU load increase from ACL logging: process switching of packets that match log-enabled access control entries (ACEs) and the generation and transmission of log messages.
Process switching is the slowest switching methods (compared to fast switching and Cisco Express Forwarding) because it must find a destination in the routing table. Process switching must also construct a new Layer 2 frame header for every packet. With process switching, when a packet comes in, the scheduler calls a process that examines the routing table, determines which interface the packet should be switched to and then switches the packet. The problem is, this happens for the every packet.
Reference: http://www.cisco.com/web/about/security/intelligence/acl-logging.html
Question 3
Explanation
If you use the “debug ip packet” command on a production router, you can bring it down since it generates an output for every packet and the output can be extensive. The best way to limit the output of debug ip packet is to create an access-list that linked to the debug. Only packets that match the access-list criteria will be subject to debug ip packet. For example, this is how to monitor traffic from 1.1.1.1 to 2.2.2.2
| access-list 100 permit ip 1.1.1.1 2.2.2.2 debug ip packet 100 |
Note: The “debug ip packet” command is used to monitor packets that are processed by the routers routing engine and are not fast switched.
Question 4
Question 5
Question 6
Explanation
+ The question asks to “always” block traffic (every week) so we must use keyword “periodic”.
+ Traffic should be blocked to 11:59 PM, which means 23:59
Note: The time is specified in 24-hour time (hh:mm), where the hours range from 0 to 23 and the minutes range from 0 to 59
Only answer B satisfies these two requirements so it is the best answer. In fact, all the above answers are not correct as the access-list should deny web traffic, not allow them as shown in the answers.
Question 7
Question 8
Question 9
Explanation
The established keyword is only applicable to TCP access list entries to match TCP segments that have the ACK and/or RST control bit set (regardless of the source and destination ports), which assumes that a TCP connection has already been established in one direction only. Let’s see an example below:
Suppose you only want to allow the hosts inside your company to telnet to an outside server but not vice versa, you can simply use an “established” access-list like this:
| access-list 100 permit tcp any any established access-list 101 permit tcp any any eq telnet ! interface S0/0 ip access-group 100 in ip access-group 101 out |
Note:
Suppose host A wants to start communicating with host B using TCP. Before they can send real data, a three-way handshake must be established first. Let’s see how this process takes place:
1. First host A will send a SYN message (a TCP segment with SYN flag set to 1, SYN is short for SYNchronize) to indicate it wants to setup a connection with host B. This message includes a sequence (SEQ) number for tracking purpose. This sequence number can be any 32-bit number (range from 0 to 232) so we use “x” to represent it.
2. After receiving SYN message from host A, host B replies with SYN-ACK message (some books may call it “SYN/ACK” or “SYN, ACK” message. ACK is short for ACKnowledge). This message includes a SYN sequence number and an ACK number:
+ SYN sequence number (let’s called it “y”) is a random number and does not have any relationship with Host A’s SYN SEQ number.
+ ACK number is the next number of Host A’s SYN sequence number it received, so we represent it with “x+1”. It means “I received your part. Now send me the next part (x + 1)”.
The SYN-ACK message indicates host B accepts to talk to host A (via ACK part). And ask if host A still wants to talk to it as well (via SYN part).
3. After Host A received the SYN-ACK message from host B, it sends an ACK message with ACK number “y+1” to host B. This confirms host A still wants to talk to host B.
Question 10
Explanation
Reflexive access lists provide filtering on upper-layer IP protocol sessions. They contain temporary entries that are automatically created when a new IP session begins. They are nested within extended, named IP access lists that are applied to an interface. Reflexive access lists are typically configured on border routers, which pass traffic between an internal and external network. These are often firewall routers. Reflexive access lists do not end with an implicit deny statement because they are nested within an access list and the subsequent statements need to be examined.
Reference: http://www.cisco.com/en/US/docs/ios-xml/ios/sec_data_acl/configuration/15-1s/sec-access-list-ov.html
Question 11
Explanation
The command “ipv6 traffic-filter access-list-name { in | out }” applies the access list to incoming or outgoing traffic on the interface.
Question 12
Question 13
Explanation
When the ACL logging feature is configured, the system monitors ACL flows and logs dropped packets and statistics for each flow that matches the deny conditions of the ACL entry.
The log and log-input options apply to an individual ACE and cause packets that match the ACE to be logged. The sample below illustrates the initial message and periodic updates sent by an IOS device with a default configuration using the log ACE option.
*May 1 22:12:13.243: %SEC-6-IPACCESSLOGP: list ACL-IPv4-E0/0-IN permitted tcp 192.168.1.3(1024) -> 192.168.2.1(22), 1 packet
Reference: https://www.cisco.com/c/en/us/about/security-center/access-control-list-logging.html
From the example above we can see when an ACL drops a packet, it generates a level 6 Syslog (%SEC-6-)
