Yusufs Lab 1

Hi

I haven´t been very active on my blog lately. Guess why? This Lab preparation is killing me…

But today I dived into Yusufs Practice Lab 1 and I did a few notes. Please comment.

/Jimmy

First of all. If you use proctorlabs gear to do Yusuf Labs you see that the naming of the device doesnt match. Here is the correct matching:
ProctorLabs Cat 3 – Yusuf Sw1
ProctorLabs Cat 2 – Yusuf Sw2
ProctorLabs R7 = Yusuf R1
ProctorLabs R8 = Yusuf R2
ProctorLabs R9 = Yusuf R3
ProctorLabs R4 = Yusuf R4
ProctorLabs R6 = Yusuf R5
ProctorLabs R5 = Yusuf R6

Also note that the interface names doesnt always match!

Q2.1 – configure NAT on ASA:s. Do not enable NAT Control. Configure static identity nat on context abc1 for web server.

Why configure identity nat? There is no NAT configured on the device, whats the purpose of adding a “static (i,o) 10.7.7.7 10.7.7.7.7” statement? It works both with and without it.

Q2.1 – “Configure static NAT on ASA2 such that Sw2 can reach dest R6 Lo0 interface using local address 192.168.10.6”

this is an ugly one! I did source translation (Telnet from Sw2:s real address TO 192.168.10.6) but I was supposed to do destination translation (telnet FROM Sw2:s natted source address 192.168.10.6). It´s SO easy to misinterprete the questions!

Q3.2 – “Configure IPSEC on ASA2 and R5. Configure high-availability IPsec peering in such wah tyat it should continue to work if euther WAN link on R5 goes down. You are not allowed to configure multiple crypto maps of mutiple peer statements. Only one crypto map with one peer statement is allowed on bith sides”.
In my opinion “high availability IPsec” is plain IPsec on router spiced up with HSRP redundancy and RRI. But here is no HSRP involved since the the requirement is to esablish ipsec between one ASA and one router.

My solution to this was to create a new loopback on R5, route the remote network (Sw2 lo0) to that loopback and apply the crypto map on this loopback. I guess the drawback with this is routing ALL traffic destined for Sw2 Lo0 to the loopback interface, not only traffic hitting the crypto map (sourced R5 lo0). I doubt that my solution would get any points on the real lab… But either way have the desired results, imho.

Q4.2 – “configure NTP on IPS Sensor”

I was unable to configure NTP. Got the same error message both in IDM and CLI:
“Error: Authenticaion failed – invalid NTP key value or ID”

This happened in CLI:


IPS(config)# service host
IPS(config-hos)# ntp-option enabled
IPS(config-hos-ena)# ntp-keys 1 md5-key cisco
IPS(config-hos-ena)# ntp-servers 10.1.1.1 key-id 1
IPS(config-hos-ena)# exit
IPS(config-hos)# exit
Apply Changes?[yes]: yes
Error: Authentication failed - invalid NTP key value or ID

There is obviously communications because these ntp debugs shows up on the NTP server R1:


R1#
Jun 27 12:54:52.811: NTP message received from 192.168.2.12 on interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.811: NTP Core(DEBUG): ntp_receive: message received
Jun 27 12:54:52.811: NTP Core(DEBUG): ntp_receive: peer is 0x00000000, next action is 3.
Jun 27 12:54:52.811: NTP Core(DEBUG): ntp_receive: doing fast answer to client.
Jun 27 12:54:52.811: NTP message sent to 192.168.2.12, from interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.811: NTP message received from 192.168.2.12 on interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.815: NTP Core(DEBUG): ntp_receive: message received
Jun 27 12:54:52.815: NTP Core(DEBUG): ntp_receive: peer is 0x00000000, next action is 3.
Jun 27 12:54:52.815: NTP Core(DEBUG): ntp_receive: doing fast answer to client.
Jun 27 12:54:52.815: NTP message sent to 192.168.2.12, from interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.815: NTP message received from 192.168.2.12 on interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.815: NTP Core(DEBUG): ntp_receive: message received
Jun 27 12:54:52.815: NTP Core(DEBUG): ntp_receive: peer is 0x00000000, next action is 3.
Jun 27 12:54:52.815: NTP Core(DEBUG): ntp_receive: doing fast answer to client.
Jun 27 12:54:52.815: NTP message sent to 192.168.2.12, from interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.819: NTP message received from 192.168.2.12 on interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.819: NTP Core(DEBUG): ntp_receive: message received
Jun 27 12:54:52.819: NTP Core(DEBUG): ntp_receive: peer is 0x00000000, next action is 3.
Jun 27 12:54:52.819: NTP Core(DEBUG): ntp_receive: doing fast answer to client.
Jun 27 12:54:52.819: NTP message sent to 192.168.2.12, from interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.919: NTP message received from 192.168.2.12 on interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.919: NTP Core(DEBUG): ntp_receive: message received
Jun 27 12:54:52.919: NTP Core(DEBUG): ntp_receive: peer is 0x00000000, next action is 3.
Jun 27 12:54:52.923: NTP Core(DEBUG): ntp_receive: doing fast answer to client.
Jun 27 12:54:52.923: NTP message sent to 192.168.2.12, from interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.923: NTP message received from 192.168.2.12 on interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.923: NTP Core(DEBUG): ntp_receive: message received
Jun 27 12:54:52.923: NTP Core(DEBUG): ntp_receive: peer is 0x00000000, next action is 3.
Jun 27 12:54:52.923: NTP Core(DEBUG): ntp_receive: doing fast answer to client.
Jun 27 12:54:52.923: NTP message sent to 192.168.2.12, from interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.927: NTP message received from 192.168.2.12 on interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.927: NTP Core(DEBUG): ntp_receive: message received
Jun 27 12:54:52.927: NTP Core(DEBUG): ntp_receive: peer is 0x00000000, next action is 3.
Jun 27 12:54:52.927: NTP Core(DEBUG): ntp_receive: doing fast answer to client.
Jun 27 12:54:52.927: NTP message sent to 192.168.2.12, from interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.927: NTP message received from 192.168.2.12 on interface 'Loopback0' (10.1.1.1).
Jun 27 12:54:52.927: NTP Core(DEBUG): ntp_receive: message received
Jun 27 12:54:52.927: NTP Core(DEBUG): ntp_receive: peer is 0x00000000, next action is 3.
Jun 27 12:54:52.927: NTP Core(DEBUG): ntp_receive: doing fast answer to client.
Jun 27 12:54:52.927: NTP message sent to 192.168.2.12, from interface 'Loopback0' (10.1.1.1).

Q5.1 Typo. “Configure AAA auth on Sw1” and “Add Sw2 ip address 192.168.8.11”. It should be Sw1 everywhere in this task.

Q5.2 CLI views assigned from ACS.
It feels abit weird that there is no pound-sign in the prompt when getting into a custom view:


R6#telnet 192.168.4.11
Trying 192.168.4.11 ... Open

Username: netop
Password:

R2>sh pars view
Current view is 'netop'
R2>configure
Configuring from terminal, memory, or network [terminal]? t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)>

Q5.3 Configure Sw2 Fa0/7 for 802.1x
Really? I was expecting the port to configure to be unused/down. Sw2 Fa0/7 is the trunk to R1. Enabling port-control here would kill alotá traffic in my network, right? 😉

Q6.0 configure CoPP on R2 allowing ping source from RFC1918-addresses only.
I created an acl, class-map and policy-map but I applied on “control-plane host” instead of “control-plane”. For verification Yusuf runs “show policy-map control-plane” which in my solution would give an empty output. But is there any difference in my solution and Yusufs? We are talking about icmp pings TO the router, why not apply int to the CoP host?

Q7.1 Web server protection.
The task was to limit the number of incoming embryonics to an internal web server, on ASA. Of course with limitations on how to ackomplish it. I missed the “Do not use ACL” which made me fail. Yusufs solution was to do “match port” in the class-map but instead I matched an access-group. To my defense I must say that “match port” would put the same limits on ALL incoming tpc/80-traffic not only the one destined for our web server.

Tagged with: ,
Posted in Cisco Security

Signuppp

[mc4wp_form id="2457"]
Website Security Test