Secure an already secure protocol · Analyze: Identify one specific service / port / protocol that repeatedly displays as being attacked. I have noticed a significant amount of attacks on the ssh protocol, mainly using password dictionaries on common user names (root, sys, user, manager, ...). These attacks first check if the ssh port is open (tcp 22) after which they begin to try passwords taken from a dictionary. In some cases, non-standard doors such as the 1022 are also tested. · Research: Describe a real world scenario where that particular service would be required. The ssh sessions are used for various services ranging from remote logins on unix systems (but not only) to the copying of files up to the redirection of ports for the encrypted publication of services on the internet. Many applications that run with a text interface that we still use today have been migrated from the old telnet protocol (which send data in clear) to the ssh protocol which binds the terminal sessions on an encrypted ssl layer. · Solve: Explain in your own terms a process (Solution) that would be used to setup a secured trust relationship between the server which delivers that service and a legitimate client requester. The ssh connectivity is in itself already a fairly secure service as being encrypted, but this does not mean that the security cannot still be increased. For example it is possible to enable a blacklisting service that after a certain number of failed authentication attempts will lock the source ip (for example on unix systems the fail2ban software is widely used). Also changing the standard port and not using common user names can significantly increase security. The use of complex passwords further increases the level of security but the best solution would be to generate rsa or dsa keys and allow authentication only through those. A more complex and safe but perhaps less practical solution is to implement a vpn. We could create a closed network where only the machine that offers the service is visible, setting openvpn in order to use the udp protocol on a non-standard port and disabling from firewall the icmp response packets type 3 code 3 and 13 we will prevent udp scans (or rather all the ports will seem to be open) but above all we would make sure that these scans are very long in fact if we assume a 1 second timeout for a port , scan the 65535 ports of a host would take about 18 hours.