Changes

Choose a hosting provider

802 bytes added, 9 years ago
*The user does not have physical access to the server
*The host is not responsible for data loss or downtime if the physical server fails
*The user is responsible for detecting and reporting hardware faults on some providers
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].
*The contract can be terminated by the host and access to the server can be terminated or suspended depending on the host's terms of use.
*Processing power will be limited over a dedicated server but, depending on the hosting provider, should be capable of running small to medium capacity websites
*Bandwidth will also be restricted
*Potential risk of provider, law enforcement or other state forces accessing contents of virtual server without user's awareness.
*The user will not have access to the outer server and will thus not be able to harden it
===Threats===
*Social engineering attack
*Password Bruteforcebrute force*Service interruption through Denial denial of Service service attack
*System software exploits
*SSL spoofingman-in-the-middle attacks
*Data loss or data theft
===Mitigation===
'''Password Managementmanagement''' is the core of any security strategy. For Dedicated the dedicated and VPS hosting options, there are several modes of control that administrator can apply.
<ol>
<li>
For more detail, refer to the guide [http://www.linux-faqs.info/security/force-strong-passwords| Force strong passwords]
<li>
Use password aging, : the <tt>chaging </tt> command on Linux servers allows checking of password age by user and setting of password aging parameters [http://linoxide.com/linux-command/password-expire-chage-command/| link].
</li>
<li>
Failed login attempts should result in the In some cases it may be prudent to enabled account locking of the associated user accountfor accounts that have been under particularly concerted attacks. On Linux systems, the faillog command can be used to check failures and to set failure limits. For more details see [http://www.cyberciti.biz/tips/rhel-centos-fedora-linux-log-failed-login.html| Faillog]. Great care should be taken when enabling user locking as an attacker can simply deny users access to their own services by intentionally locking an account. Generally it is better practice to ban the attacker before the need for account locking is encountered.
</li>
<li>
Use Password Management software - a tool such as Keepass, or KeepassX for Linux and Mac, allows users to easily generate, store and mange complex difficult to crack passwords. Refer to this guide for details on [https://securityinabox.org/en/keepass_main| Keepass]
</li>
</ol>
'''User Management''' on Dedicated dedicated or VPS systems allow administrators fine grained control of user login and access permissions.
<ol>
<li>
Root user login should be disabled by default- the <tt>sudo</tt> package should be installed and all superuser actions should be run through it.
</li>
<li>
</li>
<li>
Private keys should be used for SSH login access. The following guide gives details on generating and setting up public/private keys for SSH login, [http://support.suso.com/supki/SSH_Tutorial_for_Linux| SSH tutorial]. Once SSH keys have been set up for all relevant users, disabling password-based logins should be considered.
</li>
<li>
<ol>
<li>
System software must always be uptodateup to date. Critical patches are released by software vendors and operating system providers on a regular basis. These handle Updates frequently contain fixes for potential exploitsvulnerabilities and bugs, if your system is not uptodate up to date it may be vulnerableat risk. The clearest A recent example of this is the SSL bug [https://heartbleed.com|HeartBleed].
</li>
<li>
Retrieved from "https://learn.equalit.ie/wiki/Special:MobileDiff/374...387"