Manual Tests: Security Keystone Authentication
Adding keystone authentication sub domain for Security TCs. Change-Id: Ib3e179de4b814bce6b246686a956da588c12ec68
This commit is contained in:
fhernan2
Abraham Arce
parent
87b9e6e8da
commit
cfb8bee920
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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=<your admin 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: <type current pass>
|
||||
New Password: <Empty>
|
||||
Repeat New Password: <Empty>
|
||||
|
||||
~~~~~~~~~~~~~~~~~
|
||||
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 <interface name> <IPv4> 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 <interface name> --out <name of the file>.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
|
||||
Loading…
Reference in New Issue