diff --git a/doc/source/manual_tests/security/index.rst b/doc/source/manual_tests/security/index.rst index 798a9ca..eabf622 100644 --- a/doc/source/manual_tests/security/index.rst +++ b/doc/source/manual_tests/security/index.rst @@ -15,7 +15,8 @@ Subdomains .. toctree:: :maxdepth: 2 + security_file_access + security_https_suite + security_keystone_auth security_OAM_suite security_VM_password_protection - security_https_suite - security_file_access diff --git a/doc/source/manual_tests/security/security_keystone_auth.rst b/doc/source/manual_tests/security/security_keystone_auth.rst new file mode 100644 index 0000000..c07161d --- /dev/null +++ b/doc/source/manual_tests/security/security_keystone_auth.rst @@ -0,0 +1,886 @@ +======================= +Keystone Authentication +======================= + +.. contents:: + :local: + :depth: 1 + +----------------------------------- +SECURITY_keystone_authentication_01 +----------------------------------- + +:Test ID: SECURITY_keystone_authentication_01 +:Test Title: Nova user Passwords are protected. +:Tags: keystone + +~~~~~~~~~~~~~~~~~~ +Testcase Objective +~~~~~~~~~~~~~~~~~~ + +The objective of this test is to verify that CGCS admin password is not stored +in clear text. + +~~~~~~~~~~~~~~~~~~~ +Test Pre-Conditions +~~~~~~~~~~~~~~~~~~~ + +At least 2 Controllers + 1 compute. + +~~~~~~~~~~ +Test Steps +~~~~~~~~~~ + +1. Login to controller-0. At the prompt, type: + +.. code:: bash + + $ keyring get CGCS admin + +2. On controller-0 node enter as admin user + +.. code:: bash + + $ source /etc/nova/openrc + +3- Make sure that a file and a directory are created in the following path: + +.. code:: bash + + /opt/platform/.keyring/.CREDENTIAL + + /opt/platform/.keyring/(keyring specific directory with encrypted passwords) + +4- Type: + +.. code:: bash + + $ more /etc/nova/openrc + +Something similar to the next plain text should be displayed: + +.. code:: bash + + controller-0:~$ more /etc/nova/openrc + unset OS_SERVICE_TOKEN + + export OS_ENDPOINT_TYPE=internalURL + export CINDER_ENDPOINT_TYPE=internalURL + + export OS_USERNAME=admin + export OS_PASSWORD=`TERM=linux /opt/platform/.keyring/18.03/.C + REDENTIAL 2>/dev/null` + export OS_AUTH_URL=http://192.168.204.2:5000/v3 + + export OS_PROJECT_NAME=admin + export OS_USER_DOMAIN_NAME=Default + export OS_PROJECT_DOMAIN_NAME=Default + export OS_IDENTITY_API_VERSION=3 + export OS_REGION_NAME=RegionOne + export OS_INTERFACE=internal + + if [ ! -z """"${OS_PASSWORD}"""" ]; then + export PS1='[\u@\h \W(keystone_$OS_USERNAME)]\$ ' + else + echo 'Openstack Admin credentials can only be loaded from the active controller.' + export PS1='\h:\w\$ ' fi + +5- Go to horizon > admin > platform > host inventory - and swact host 0. + +6- On controller-1 node enter as admin user: + +.. code:: bash + + $ source /etc/nova/openrc + +you should found the same /etc/nova/openrc content. + +7- After sourcing the openrc, type: + +.. code:: bash + + $ env + +~~~~~~~~~~~~~~~~~ +Expected Behavior +~~~~~~~~~~~~~~~~~ + +* It should return, the Horizon admin password. + +* Logged in as an admin successfully. + +* Files and directories created successfully. + +* Admin does not have the password stored in clear text. + +* Logged in as an admin successfully and content should be the same as Ctr-0. + +.. code:: bash + + You should be able to find; + OS_PASSWORD= + +----------------------------------- +SECURITY_keystone_authentication_02 +----------------------------------- + +:Test ID: SECURITY_keystone_authentication_02 +:Test Title: Change admin password. +:Tags: keystone + +~~~~~~~~~~~~~~~~~~ +Testcase Objective +~~~~~~~~~~~~~~~~~~ + +Verify admin password change in different scenarios (SWACT/lock/unlock standby +controller, in Active controller and empty password). + +~~~~~~~~~~~~~~~~~~~ +Test Pre-Conditions +~~~~~~~~~~~~~~~~~~~ + +At least 2 Controllers + 1 compute. + +~~~~~~~~~~ +Test Steps +~~~~~~~~~~ + +* Change admin password via cli: + +.. code:: bash + + $ openstack user password set + +* SWACT to standby controller and make sure the controller come up fine. + +At the prompt, type: + +.. code:: bash + + $ keyring get CGCS admin + +* Lock standby controller (system host-lock controller-1) + +* Change admin password via cli: + +.. code:: bash + + $ openstack user password set + +* At the prompt, type: + +.. code:: bash + + $ keyring get CGCS admin"" + +* Unlock standby controller (system host-unlock controller-1) + +* Change admin password via cli: + +.. code:: bash + + $ openstack user password set + +* Reboot standby controller. + +* To recover from reboot loop lock/unlock standby controller. + +* At the prompt, type: + +.. code:: bash + + $ keyring get CGCS admin + +* Change admin password via cli on Active controller: + +.. code:: bash + + $ openstack user password set + +* Logg in/out from active controller. + +Try to change admin password via cli on Active controller with empty string: + +.. code:: bash + + $ openstack user password set + Current password: + New Password: + Repeat New Password: + +~~~~~~~~~~~~~~~~~ +Expected Behavior +~~~~~~~~~~~~~~~~~ + +* Admin password is changed successfully. + +* After SWACT the standby controller became active. + +* It should return, the Horizon admin password. + +* Verify standby controller is locked. + +* Admin password is changed successfully. + +* Verify the password is changed (keyring get CGCS) + +* Verify the standby controller comes up fine. + +* Admin password is changed successfully. + +* Verify that the standby controller goes into reboot loop. + +* Verify after lock/unlock it recovers. + +* Verify the password is changed (keyring get CGCS) + +* Admin password is changed successfully. + +* You are able to logged in/out to active controller successfully. + +* Verify empty string is not accepted for keystone admin password and controller get back with following message: + +.. code:: bash + + No password was supplied, authentication will fail when a suer does not have a pasword. + Specify both the current password and a ne password + +----------------------------------- +SECURITY_keystone_authentication_03 +----------------------------------- + +:Test ID: SECURITY_keystone_authentication_03 +:Test Title: Adding users to keystone user list via horizon. +:Tags: keystone + +~~~~~~~~~~~~~~~~~~ +Testcase Objective +~~~~~~~~~~~~~~~~~~ + +Go through Horizon Adding users to keystone user list via horizon. + +~~~~~~~~~~~~~~~~~~~ +Test Pre-Conditions +~~~~~~~~~~~~~~~~~~~ + +At least 2 Controllers + 1 compute. + +~~~~~~~~~~ +Test Steps +~~~~~~~~~~ + +* From horizon as admin user go to identity tab -> users. + +* Hit ""+ Create User"" button. + +* Enter at least required fields: + +:: + + User Name: + Password: + Confirm Password: + Primary Project."" + Enter ""Create User"" button. + Refresh Identity --> Users List and make sure the new user is displayed. + +~~~~~~~~~~~~~~~~~ +Expected Behavior +~~~~~~~~~~~~~~~~~ + +* Identity /Users "" Frame is displayed successfully. + +* Create user pop up window is displayed. + +* Required fields were entered successfully. + +* Horizon got back with message saying the new user is created successfully. + +* The new user is displayed successfully in identity --> User list. + +----------------------------------- +SECURITY_keystone_authentication_04 +----------------------------------- + +:Test ID: SECURITY_keystone_authentication_04 +:Test Title: Token expiration default 3600. +:Tags: keystone + +~~~~~~~~~~~~~~~~~~ +Testcase Objective +~~~~~~~~~~~~~~~~~~ + +Verify that token_expiration system service-parameter default is set 3600 +value. + +~~~~~~~~~~~~~~~~~~~ +Test Pre-Conditions +~~~~~~~~~~~~~~~~~~~ + +a) At least 1 Controller. + +b) Set token_expiration value for users. + +~~~~~~~~~~ +Test Steps +~~~~~~~~~~ + +* Login to controller-0. At the prompt, type: + +.. code:: bash + + $ sudo su + +* On controller-0 node enter as super user + +.. code:: bash + + $ /etc/keystone/keyston.cof + +* Make sure that file exists and verify the expiration field, from Token should be: 3600 + +* Type: + +.. code:: bash + + $ cat /etc/keystone/keystone.conf | grep ""expiration="" and check the result + Something similar to the next plain text should be displayed: + controller-0:~# cat /etc/keystone/keystone.conf | grep ""expiration="" + expiration=3600" + +~~~~~~~~~~~~~~~~~ +Expected Behavior +~~~~~~~~~~~~~~~~~ + +* Verify file that keyston.conf + +* Verify that expiration is the value of 3600 + +----------------------------------- +SECURITY_keystone_authentication_05 +----------------------------------- + +:Test ID: SECURITY_keystone_authentication_05 +:Test Title: keystone fernet path and file. +:Tags: keystone + +~~~~~~~~~~~~~~~~~~ +Testcase Objective +~~~~~~~~~~~~~~~~~~ + +Verify proper keystone path and file. + +~~~~~~~~~~~~~~~~~~~ +Test Pre-Conditions +~~~~~~~~~~~~~~~~~~~ + +a) At least 1 Controller. + +b) See documentation on [0] + +~~~~~~~~~~ +Test Steps +~~~~~~~~~~ + +1. In order to verify the Fernet path and file. Login to controller-0. At the +prompt, type: + +.. code:: bash + + $ sudo su + +2. On controller-0 node enter as super user to check the information inside +keyston.con under /etc/keystone/"" look for the fernet_tokens section and the +key_repository path"" the key_repository could be not always in the same path + +In this case key_repository coul be verify at: + +.. code:: bash + + $ controller-0:/opt/cgcs/keystone/fernet-keys + +3. Then Verify that fernet keys exist: + +.. code:: bash + + $controller-0:/opt/cgcs/keystone/fernet-keys #ls + +4. Verify the fernet keys format: + +.. code:: bash + + controller-0:/opt/cgcs/keystone/fernet-keys #cat 0 + G4bR3-2CoQGiKLDBWPwL0ZriLTYFEbLeSSFLNv5p30= + +~~~~~~~~~~~~~~~~~ +Expected Behavior +~~~~~~~~~~~~~~~~~ + +* Verify file that keyston.conf. + +* Verify fernet path for fernet-keys. + +* Verify Fernet Keys are generated and with the format. + +----------------------------------- +SECURITY_keystone_authentication_06 +----------------------------------- + +:Test ID: SECURITY_keystone_authentication_0 +:Test Title: Fernet tokens after controller SWACT. +:Tags: keystone + +~~~~~~~~~~~~~~~~~~ +Testcase Objective +~~~~~~~~~~~~~~~~~~ + +Fernet tokens must be available on the system after SWACT (active/inactive +Controller). + +~~~~~~~~~~~~~~~~~~~ +Test Pre-Conditions +~~~~~~~~~~~~~~~~~~~ + +a) At least 1 Controller. + +b) See documentation on [0] + +~~~~~~~~~~ +Test Steps +~~~~~~~~~~ + +* Before SWACT verify Fernet Tokens and formats. + +* Login to controller-0. At the prompt, type: + +.. code:: bash + + $ sudo su"" + +* On controller-0 node enter as super user to check the information inside keyston.con under /etc/keystone/ look for the kernet_tokens section and the key_repository path the key_repository could be not always in the same path. + +In this case key_repository coul be verify at: + +.. code:: bash + + $controller-0:/opt/cgcs/keystone/fernet-keys + +* Then Verify that fernet keys exist: + +.. code:: bash + + $controller-0:/opt/cgcs/keystone/fernet-keys# ls + 0 1 + +* Verify the fernet keys format: + +.. code:: bash + + controller-0:/opt/cgcs/keystone/fernet-keys# cat 0 + -G4bR3-2CoQGiKLDBWPwL0ZriLTYFEbLeSSFLNv5p30= + +* SWACT the controllers, from the active controller Verify the Fernet path, files and format. + +~~~~~~~~~~~~~~~~~ +Expected Behavior +~~~~~~~~~~~~~~~~~ + +* Fernet Tokens should remain after SWACT controllers. + +----------------------------------- +SECURITY_keystone_authentication_07 +----------------------------------- + +:Test ID: SECURITY_keystone_authentication_07 +:Test Title: Fernet instead of UUID. +:Tags: keystone + +~~~~~~~~~~~~~~~~~~ +Testcase Objective +~~~~~~~~~~~~~~~~~~ + +Fernet instead of UUID. + +~~~~~~~~~~~~~~~~~~~ +Test Pre-Conditions +~~~~~~~~~~~~~~~~~~~ + +a) At least 1 Controller. + +b) See documentation on [0] + +~~~~~~~~~~ +Test Steps +~~~~~~~~~~ + +* Login to controller-0. At the prompt: + +1. Type + +.. code:: bash + + $ sudo su"" + +On controller-0 node enter as super user +2- type: + +.. code:: bash + + $ /etc/keystone/keyston.conf + +Make sure that file exists and verify the Token provider should be: fernet"" + +3- Type: + +.. code:: bash + + $ cat /etc/keystone/keystone.conf | grep ""provider"" and check the result + +Something similar to the next plain text should be displayed: + +.. code:: bash + + controller-0:/etc/keystone# cat /etc/keystone/keystone.conf | grep provider" provider=fernet + +~~~~~~~~~~~~~~~~~ +Expected Behavior +~~~~~~~~~~~~~~~~~ + +* Verify file that keyston.conf. + +* Verify the provider is set to fernet and not UUID. + +----------------------------------- +SECURITY_keystone_authentication_08 +----------------------------------- + +:Test ID: SECURITY_keystone_authentication_08 +:Test Title: Key Rotation Test. +:Tags: keystone + +~~~~~~~~~~~~~~~~~~ +Testcase Objective +~~~~~~~~~~~~~~~~~~ + +The key rotation is performed. + +~~~~~~~~~~~~~~~~~~~ +Test Pre-Conditions +~~~~~~~~~~~~~~~~~~~ + +a) At least 1 Controller. + +b) See documentation on [0] + +~~~~~~~~~~ +Test Steps +~~~~~~~~~~ + +:: + + Login to controller-0. At the prompt, type: + 1- $ sudo su" + On Active controller-0 node enter as super user + 2- $ /etc/keystone/keyston.conf + 3- Add to this keystone.conf file under fernet_tokens section: + token_expiration=24 + rotation_frequency=6 + max_active_keys=4 + 4.- Initialize fernet key repositories: + # keystone-manage fernet_setup --keystone-user keystone --keystone-group keystone + 5.- Initialize Credential repo: + # keystone-manage credential_setup --keystone-user keystone --keystone-group keystone + 6.- Check for actual existing fernet keys in this path: + /opt/cgcs/keystone/fernet-keys + 7.- Rotate the fernet keys: + # keystone-manage fernet_rotate --keystone-user keystone --keystone-group keystone + 8.- Check that a new fernet key has been added, you can compare the actual time when you have executed the cmd in order to know if already was created: + #sudo timedatectl status + +~~~~~~~~~~~~~~~~~ +Expected Behavior +~~~~~~~~~~~~~~~~~ + +* Verifye that Key Rotation has been assigned another key in the path: + +.. code:: bash + + /opt/cgcs/keystone/fernet-keys" + +----------------------------------- +SECURITY_keystone_authentication_09 +----------------------------------- + +:Test ID: SECURITY_keystone_authentication_09 +:Test Title: Verify log under /var/log/horizon.log that all passwords are masked. +:Tags: keystone + +~~~~~~~~~~~~~~~~~~ +Testcase Objective +~~~~~~~~~~~~~~~~~~ + +Verify log under /var/log/horizon.log that all passwords are masked. + +~~~~~~~~~~~~~~~~~~~ +Test Pre-Conditions +~~~~~~~~~~~~~~~~~~~ + +At least 1 Controller + 1 compute. + +~~~~~~~~~~ +Test Steps +~~~~~~~~~~ + +* Login to controller-0 using system admin user + +* Verify all the passwords from horizon.log inside /var/log/horizon.log are masked or ( ********** ) + +.. code:: bash + + $cat /var/log/horizon.log + +* Look for passwords and should be masked + +.. code:: bash + + "password": ********" + "fake_password": ********" + +~~~~~~~~~~~~~~~~~ +Expected Behavior +~~~~~~~~~~~~~~~~~ + +* Confirm that passwords are masked ( ***** ) in the logs from horizon.log + +----------------------------------- +SECURITY_keystone_authentication_10 +----------------------------------- + +:Test ID: SECURITY_keystone_authentication_10 +:Test Title: Encryption on Management network communication. +:Tags: MITM_Virtual + +~~~~~~~~~~~~~~~~~~ +Testcase Objective +~~~~~~~~~~~~~~~~~~ + +Verify that communication over Starlingx Management network is encrypted and +not showing any sensitive information in plain text. + +~~~~~~~~~~~~~~~~~~~ +Test Pre-Conditions +~~~~~~~~~~~~~~~~~~~ + +a) At least 1 VM Controller + 1 VM Compute. + +b) Kali Security OS installed on libvirt Virtual Machine having access to the +MGMT network (Kali will act as a MITM Virtual Machine). + +~~~~~~~~~~ +Test Steps +~~~~~~~~~~ + +* In your HOST where the Virtual nodes resides type "ifconfig" and identified what network interfaces are up and running. + +.. code:: bash + + $ ifconfig + + e.g. + ... + rename4 Link encap:Ethernet HWaddr a0:36:9f:f7:be:a0 + inet addr:10.219.128.122 Bcast:10.219.128.255 Mask:255.255.255.0 + inet6 addr: fe80::6b2:8085:4bf2:da74/64 Scope:Link + UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 + RX packets:3067876 errors:0 dropped:14209 overruns:0 frame:0 + TX packets:9113396 errors:0 dropped:0 overruns:0 carrier:0 + collisions:0 txqueuelen:1000 + RX bytes:233256569 (233.2 MB) TX bytes:10462546810 (10.4 GB) + + virbr0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 + inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0 + UP BROADCAST MULTICAST MTU:1500 Metric:1 + RX packets:0 errors:0 dropped:0 overruns:0 frame:0 + TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 + collisions:0 txqueuelen:1000 + RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) + + virbr1 Link encap:Ethernet HWaddr fe:54:00:21:c0:24 + inet addr:10.10.10.1 Bcast:10.10.10.255 Mask:255.255.255.0 + inet6 addr: fe80::848f:cdff:fe4c:fb59/64 Scope:Link + UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 + RX packets:298794 errors:0 dropped:0 overruns:0 frame:0 + TX packets:606395 errors:0 dropped:0 overruns:0 carrier:0 + collisions:0 txqueuelen:1000 + RX bytes:61810994 (61.8 MB) TX bytes:2124955052 (2.1 GB) + + virbr2 Link encap:Ethernet HWaddr fe:54:00:6e:a7:90 + inet addr:192.168.204.1 Bcast:192.168.204.255 Mask:255.255.255.0 + inet6 addr: fe80::4403:aaff:fe5f:63ff/64 Scope:Link + UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 + RX packets:3858083 errors:0 dropped:6 overruns:0 frame:0 + TX packets:980 errors:0 dropped:0 overruns:0 carrier:0 + collisions:0 txqueuelen:1000 + RX bytes:2071553276 (2.0 GB) TX bytes:85710 (85.7 KB) + +* (Double check network interfaces up) + +* Create in your Kali Virtual Machine a NIC with the same "Bridge name" and "device model" used by the 2 nodes that you are going to connect. + +**Brief explanation:** + +* Use Case When Kali is going to be MITM machine between Controller-0 and compute-0 (see previous step for interfaces list): + +* Configure Kali VM NIC with "Bridge name: virbr2", "Device model: e1000" (where virbr2 is the interface used by Compute-0 and Controller-0 MGMT network) + +* Controller-0 node configured with "virbr2 bridge" "Ethernet", "IP: 192.168.204.3", MAC: 52:54:00:6e:a7:90. (Once Controller-0 is up, virbr2 interface will be used, however, when prompting ifconfig the Controller-0 will assign an interface with another name; something like Interface ens7) + +* Compute-0 node configured with "Bridge name:ens7" "Ethernet", "IP: 192.168.204.90", MAC: 52:54:00:11:d0:6b. (Once Compute-0 is up, virbr2 interface will be used, however, when prompting ifconfig the Compute-0 will assign an interface with another name; something like ens7) + +* Set interface IP for Kali MITM attack. + +* Login to your Kali VM. + +* Check network interfaces up by typing: + +.. code:: bash + + $ ifconfig + +or + +.. code:: bash + + $ ip link show"" + +* Assign an IP to the network interface where Controller-0 and Compute-0 are using: + +.. code:: bash + + $ sudo ifconfig netmask 255.255.255.0 + + e.g. + + $ sudo ifconfig eth2 192.168.204.200 netmask 255.255.255.0 + +* Make sure connectivity between Kai and nodes by pinging Controller-0 and Compute-0 nodes. + +.. code:: bash + + e.g. + Ping Controller-0: 192.168.204.3 + Ping Compute-0: 192.168.204.90"" + +* Once you create connectivity between Kali Virtual machine and Starlingx nodes go to Kali VM --> Applications --> 09 - Sniffing & Spoofing -->Ettercap. + +* Go to Menu banner --> Sniff --> Unified Sniffing. + +* Select Network interface to sniff. + +.. code:: bash + + e.g. + Network interface : eth2"" + +* Go to Menu Banner --> MITM --> ARP Poisoning, and select the "Sniff remote connections" checkbox. + +* Go to Menu Banner --> Hosts --> Scan for hosts option. + +* Go to Menu Banner --> Hosts --> Hosts list. + +* On Host list tab, highlight the server IP that you want to monitor and hit under "Add to Target 1" button. + +.. code:: bash + + e.g. + Following with the example the Server ip would be the Controller-0: 192.168.204.3."" + +* On Host list tab, highlight the client IP that you want to monitor and hit under "Add to Target 2" button. + +* Go to Menu Banner --> Targets --> Current Targets. + +* Go to Applications --> 09 - Sniffing & Spoofing --> netsniff-ng. + +* Type following command: + +.. code:: bash + + $ netsniff-ng --in --out .pcap + e.g. + $ netsniff-ng --in eth2 --out pickup-ctl0-cmp0.pcap"" + +** DO YOUR intended commands/actions in order to exercise your network ** + +* Once you executed the intended commands in order to exercise the network go to the terminal where the netsniff-ng app is running and stop the process. + +* Go to Applications --> 09 - Sniffing & Spoofing --> Wireshark. + +* Once the Wireshark application is opened, go to File and open the .pcap file generated by your sniffing command. + +* Go to Wireshark menu banner and select Analyze --> Display Filters. + +* Work with filters in order to analyze the security of protocols/Ports/IP version you are looking for. + +~~~~~~~~~~~~~~~~~ +Expected Behavior +~~~~~~~~~~~~~~~~~ + +* Network interfaces were displayed successfully. + +.. code:: bash + + i.e. + Where: + - rename4 interface is Intel network. + - virbr1 interface used to connect Host with Controler-0 interface (OAM) + - virbr2 interface used to connect to the MGMT network (controller-0 with Compute-0). + +* Interface that is going to be used by the Controller-0 and the Compute-0 are up and running, as well as the one who will act as a MITM in Kali VM. + +* Interfaces are shown in Kali VM successfully. + +* IP network interface assigned successfully in Kali VM. + +* Connectivity between Kali Virtual machine and nodes was successfully. + +* Ettercap application is opened successfully. + +* A pop Up window asking for Network interface to used should be opened successfully. + +* The Kali VM started to monitor and sniffing the proper interface successfully. + +* ARP spoofing should be done successfully where the MAC address from the Server and Client are set in Kali acting as a MITM attacker. + +* Ettercap application should scan their hosts who has connectivity. + +* A list of hosts with IP, MAC Address should be displayed. + +* Server IP address should be marked as a Target 1 successfully. + +Client IP address should be marked as a Target 2 successfully. + +* Target 1/2 should be displayed successfully. + +* netsniff-ng command prompt should be displayed. + +* The command should be executed successfully and you would be monitoring the targets. + +* MGMT Network is excercised successfully. + +* The netsniff-ng program should be stopped and you would be seeing a message saying: + +.. code:: bash + + [1]+ Stopped netsniff-ng --in eth2 --out pickup-ctl0-cmp0.pcap + +* Wireshark should be opened successfully. + +* .pcap file should be opened by Wireshark successfully. + +* You were able to analyze Secure connectivity between Client and Server communications. If there is unsecure communications open a defect. + +~~~~~~~~~~~ +References: +~~~~~~~~~~~ + +[0] - https://docs.openstack.org/keystone/pike/admin/identity-fernet-token-faq.html