Difference between revisions of "Choose a hosting provider"

(Mitigation)
Line 32: Line 32:
 
*The user does not have physical access to the server
 
*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 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 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.
 
*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.
Line 47: Line 48:
 
*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
 
*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
 
*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
 
*The user will not have access to the outer server and will thus not be able to harden it
  
 
===Threats===
 
===Threats===
 
*Social engineering attack
 
*Social engineering attack
*Password Bruteforce
+
*Password brute force
*Service interruption through Denial of Service attack
+
*Service interruption through denial of service attack
 
*System software exploits
 
*System software exploits
*SSL spoofing
+
*SSL man-in-the-middle attacks
 
*Data loss or data theft
 
*Data loss or data theft
  
 
===Mitigation===
 
===Mitigation===
'''Password Management''' is the core of any security strategy. For Dedicated and VPS hosting options, there are several modes of control that administrator can apply.
+
'''Password management''' is the core of any security strategy. For the dedicated and VPS hosting options, there are several modes of control that administrator can apply.
 
<ol>
 
<ol>
 
<li>
 
<li>
Line 67: Line 69:
 
For more detail, refer to the guide [http://www.linux-faqs.info/security/force-strong-passwords| Force strong passwords]
 
For more detail, refer to the guide [http://www.linux-faqs.info/security/force-strong-passwords| Force strong passwords]
 
<li>
 
<li>
Use password aging, the chaging 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].
+
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>
 
<li>
 
<li>
Failed login attempts should result in the locking of the associated user account. 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]
+
In some cases it may be prudent to enabled account locking for 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>
 
<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]
+
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>
 
</li>
 
</ol>
 
</ol>
'''User Management''' on Dedicated or VPS systems allow administrators fine grained control of user login and access permissions.
+
'''User Management''' on dedicated or VPS systems allow administrators fine grained control of user login and access permissions.
 
<ol>
 
<ol>
 
<li>
 
<li>
Root user login should be disabled by default
+
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>
Line 85: Line 87:
 
</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]
+
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>
 
<li>
 
<li>
Line 94: Line 96:
 
<ol>
 
<ol>
 
<li>
 
<li>
System software must always be uptodate. Critical patches are released by software vendors and operating system providers on a regular basis. These handle potential exploits, if your system is not uptodate it may be vulnerable. The clearest example of this is the SSL bug [https://heartbleed.com|HeartBleed].
+
System software must always be up to date. Critical patches are released by software vendors and operating system providers on a regular basis. Updates frequently contain fixes for potential vulnerabilities and bugs, if your system is not up to date it may be at risk. A recent example of this is the SSL bug [https://heartbleed.com HeartBleed].
 
</li>
 
</li>
 
<li>
 
<li>

Revision as of 16:30, 18 May 2014

Criteria

  • Price - relative services offered
  • Reputation - are they well known, have they had security breaches or reports of poor support, do they adhere to certain principles inline with that of your organisation - such as data privacy or protection of human rights defenders.
  • Specialisation - do they work in the field of human rights, software applications or general hosting
  • Is mail provided
  • Hardware specifications
  • Operating systems offered
  • Supported provided
  • Readily discusses your security concerns and which security features and processes they offer with their hosting.
  • Provides the most recent stable versions of all server software.
  • Provides reliable methods for backup and recovery.
  • Provides encryption options for hosting of sites or mail

Secure hosting setups

Depending on available skill level the following secure system setups are possible:

 [Expand

High Technical

 [Expand

Intermediary Technical

 [Expand

Basic Technical

 [Expand

Comparison Matrix


Back to front page