Merge branch 'network-blockage-refactor' into 'master'

refactor: network blockage

See merge request !114

content/cloud/faq/index.md

@@ -114,20 +114,27 @@ What can I do?
 - Use backup/data storage services provided by MUNI or CESNET (e. g. https://it.muni.cz/sluzby/zalohovani-bacula ).
 
 ## I can't access my cloud VMs. MetaCentrum OpenStack network security protection
-Access to the MetaCentrum cloud is protected by security teams [CSIRT-MU](https://csirt.muni.cz/?lang=en) and [CSIRT-CESNET](https://csirt.cesnet.cz/en/index).
+Access to the MetaCentrum cloud is protected by [CSIRT-MU](https://csirt.muni.cz/?lang=en) and [CSIRT-CESNET](https://csirt.cesnet.cz/en/index) security teams.
 
-Some interactions with allocated virtual servers may cause cloud access blockage. This is caused by the fact, that legal SSH access to a new virtual machine (VM) which is being allocated is very similar to a (SSH) brute-force attack.
+Some interactions with allocated cloud resources may cause cloud access blockage. This is caused by the fact, that legal SSH access to a new virtual machine (VM) which is being allocated is very similar to a (SSH) brute-force attack.
 
 A newly created VM will respond to SSH connection attempts in different ways as it moves through the setup stages:
 * A) VM is booting and network is being established. At this stage, there is no functional connection point, and connection attempts will timeout.
 * B) SSH connection is being set. At the start of its lifetime, a VM runs the cloud-init process, which enables SSH authentication with the user's SSH key. A connection is refused, because it can't verify the user.
 * C) Connection is finally successfull. All setup processes are finished.
 
-When a brute-force attack is attempted, repeated unsuccessful (unauthorized) connections to the VM are made, and either timeout or refused are returned. If the attacker guesses the right credentials, he/she will eventually get connect passed.
+When a (ssh) brute-force attack is attempted, scenario is very similar. Repeated unsuccessful (unauthorized) connections to the VM are made (resulting in connection reset or timeout). Once the attacker passes the right credentials, gets connected and logged.
 
-Therefore, when security systems discover a suspicious series of unsuccessfull connections, they block Your IP address to the allocated cloud VMs. This can also happen, if You were the one who initiated them by mistake.
+Therefore, when security systems discover such suspicious series of unsuccessfull connections followed by successful one, they likely block Your IP address to the allocated cloud VMs. 
 
 ### Best practices for accessing cloud resources without getting blocked
+
+The key practices helping to avoid source IP address blockage are:
+ * connect to cloud infrastructure via single public facing jump / bastion node (using [sshuttle](https://github.com/sshuttle/sshuttle#readme) or [ssh ProxyJump](https://www.jeffgeerling.com/blog/2022/using-ansible-playbook-ssh-bastion-jump-host) or eventually [ssh ProxyCommand](https://blog.ruanbekker.com/blog/2020/10/26/use-a-ssh-jump-host-with-ansible/))
+ * use OpenStack API to watch whether VM is ACTIVE
+ * relax public IP try-connect loop timing
+ * configure SSH client to [reuse connection for instance with `-o ControlMaster=auto -o ControlPersist=60s`]()
+
 As an example, consider a group of virtual machines, where at least one has access to the internet using an IPv4 or IPv6 public address, and they are connected by an internal network (e.g. 10.0.0.0/24).
 
 To access the VM with a public address: