https://learn.equalit.ie/mw/api.php?action=feedcontributions&feedformat=atom&user=Billlearn.equalit.ie - User contributions [en]2026-05-21T21:18:02ZUser contributionsMediaWiki 1.23.1https://learn.equalit.ie/wiki/Np1secNp1sec2015-09-23T17:54:28Z<p>Bill: This changes update the existing protocol paper to bring it into line with the current implementation of the np1sec protocol</p>
<hr />
<div>[[File:Np1sec-web.jpg|frameless|center|(n+1)sec]]<br />
<div class="noautonum">__TOC__</div><br />
{{DISPLAYTITLE:(n+1)sec}}<br />
===Abstract===<br />
<br />
''In this document we present the first public draft of ''(n+1)sec'' - a secure multi-party communication protocol developed by eQualit.ie with support from the [https://www.opentechfund.org/ Open Technology Fund] and [https://crypto.cat/ Cryptocat]. We include the design rationale, choice of security features, adversarial models, schematic and high level specification of sub-protocols. A subsequent document will present security proofs and implementation details.''<br />
<br />
=I. INTRODUCTION=<br />
<br />
<span style="font-size:200%">T</span>he ''(n+1)sec'' project was inspired by [https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html Off-The-Record] messaging protocol and subsequent efforts to explore a multiparty use-case for OTR in [GUVGC09]. ''(n+1)sec'' is currently developed for [https://github.com/cryptocat/cryptocat/wiki/mpOTR-Project-Plan Cryptocat] - a browser based XMPP chat platform and assumes its use-cases. Most importantly, ''(n+1)sec'' allows for secure multi-party key exchange and end-to-end encrypted communications without extensive computational requirements from the client. You can follow and contribute to the implementation of [https://github.com/equalitie/np1sec np1sec] on our Github pages. Future protocol iterations will consider a variety of other real-world use cases and be platform independent. Please use the [[Talk:Np1sec|Discussion]] page to ask questions and leave comments.<br />
<br />
In the following section we summarise relevant publications and describe their influence on this protocol. In [[#III._Design_rationale|Section III]], we describe our approach and choice of security features. In [[#IV._Security_Properties|Section IV]], we review the security properties within this protocol. In [[#V._Chat_Session_Model|Section V]] we give basic mathematical definition needed to model the chat session and security proofs for various security aspects of the protocol. [[#IV._Adversarial_Models|Section VI]] provides formal definitions and references to the adversarial models for each property. In [[#VII._Protocol_High_Level_Design|Section VII]] we describe various parts of the protocol and present choices for each sub protocol. In [[#VIII._''(n+1)sec''_Protocol:_Step_by_Step|Section VIII]], we present each of the ''(n+1)sec'' protocol steps at various stages in schematic and algorithmic format. We present our choice of primitives in [[#iX._Cryptographic_Primitives|Section IX]]. Finally, we define the work that [[#Next_Steps|remains to be done]] on this protocol and [[#XI._Acknowledgements|acknowledge]] the good people who have helped us get here.<br />
<br />
= II. History and literature review =<br />
<br />
<span style="font-size:200%">T</span>wo-party Off The Record messaging (OTR) was introduced in [BGB04] as an alternative to PGP for secure casual Internet chat by providing necessary forward secrecy and deniable transcript features. The paper proposes the use of symmetric encryption and message authentication in OTR for confidentiality and integrity, and the Diffie-Hellman key exchange for authenticating the other party in the chat. Since publication in 2004, it has defined the standard for secure Internet chat attracting a lot of academic attention and security analysis. The OTR protocol is now at [https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html Version 3] and the [https://otr.cypherpunks.ca/index.php#downloads libotr software libraries] are continuously updated. Our research and literature review focused on the protocol presented in [BGB04] and the subsequent proposal for a multiparty use-case in [GUVGC09].<br />
<br />
In [RGK05], researchers point out that OTR’s approach to authenticate renewed ephemeral session keys is provided by the property of confidentiality and is therefore dependent on the secrecy of the conversation. Hence, breaking the secrecy of the conversation (e.g. by leaking the session key) will lead to false authentication as well. They offer two authenticated deniable key exchange protocols, which also provide forward secrecy, as a replacement for OTR’s original key exchange. Furthermore, they argue that forgeability and malleability do not have any mathematical consequence in improving deniability if the parties have been authenticated by a deniable key exchange scheme. They argue that as these properties pose potential security threats, it is desirable to omit them from the protocol entirely.<br />
<br />
An alternative appears in [BS07], using the Schnorr zero-knowledge proof and signature algorithm, to introduce a 4-round challenge-based authentication scheme that grants deniability to the two-round authenticated protocol described in [BVS05].<br />
<br />
[ACMP10] offers a more efficient protocol than [BS07] in the sense that ephemeral Diffie-Hellman elements are reusable to regenerate keys when some of the participants change. As such, it offers a one-round protocol to generate a key for a subgroup of the original conversation.<br />
<br />
An unauthenticated exchange of the OTR version identifier can pose a threat to authenticity as shown in [BM]: the adversary can force clients to downgrade to an older, (potentially insecure) version of the protocol. They also note the Diffie-Hellman key exchange failure in delivering authentication in the presence of an active adversary. Furthermore, they show that the early publication of MAC keys for the purpose of forgeability can easily enable the active adversary to forge messages during the conversation (instead of the intended forgeability after the conversation has ended). Finally, they argue that in an environment where the adversary is controlling the whole network, she can effectively disarm the protocol of its forgeability property.<br />
<br />
Various attempts have been made to construct an efficient multiparty (known as group) authenticated key exchange protocol. OTR authors proposed a generalisation of two-party OTR to a multiparty use-case in [GUVGC09]. However, they did not specify the cryptographic primitives, neither did they give a formal definition of the adversaries nor the proof of the algorithm’s security (reduction). Although a more robust key exchange is proposed, some primary performance analysis of the implementation of the key agreement protocol has been shown to be impractically slow, especially on mobile devices [Gun13a][Git11].<br />
<br />
[LVH13] proposes GOTR as an alternative to [GUVGC09] with a goal of improving on some of its security properties. A notable change is the use of p2p private channels to send message digest so as to establish transcript consistency and implicit message origin authenticity between users. GOTR also strives to improve on repudiability by considering deniability against an 'online judge' as well as forgeability for the entire transcript by a single party (this is possible in [GUVGC09] as long as a deniable AKE is being used). The idea of online repudiabilty relies on the judge controlling up to '''N-2''' parties while the two remaining "honest" parties are allowed to collude. This is slightly unusual for both repudiability and honesty. [LVH13] also proposes an involved contributory BD based key agreement scheme, which disregard room consistency and turns GOTR into a broadcast scheme (c.f. [[#Appendix_B:_Other_design_possibilities|Appendix B]]).<br />
<br />
=III. Design rationale =<br />
<br />
<span style="font-size:200%">O</span>ur approach for ''(n+1)sec'' design was based on the following requirements, in order of importance:<br />
<br />
# A protocol that is provably secure in a sufficiently strong adversarial model that addresses confidentiality, authenticity and forward secrecy<br />
# Applicable to the [https://github.com/cryptocat/cryptocat/wiki/Design-and-Functionality Cryptocat XMPP use-case]<br />
# Providing some degree of deniability when it does not negatively impact usability or our [[#IV._Security_Properties|security goals]]<br />
# Addressing security flaws in [BGB04] and [GUVGC09]<br />
<br />
We designate the protocol suggested in [GUVGC09] as our starting point and apply various modifications to reach a desirable protocol satisfying the above stated goals. <br />
<br />
A significant portion of our research suggested a better performing, more secure alternative to the key exchange protocol suggested in [GUVGC09]. Based on conclusions in [BM] and [RGK05], we are making the following design changes:<br />
<br />
* Using a more secure deniable key exchange algorithm, instead of naive Diffie-Hellman<br />
<br />
In designing ''(n+1)sec''’s deniable authentication and key agreement protocol, we have followed [ACMP10] by choosing a provably secure authenticated key exchange method and replacing the signature-based authentication with a deniable one. We have chosen the protocol introduced in [ACMP10] instead of [BS07], due to its superior efficiency. We abstract out the method where parties communicate their secret for additional flexibility.<br />
<br />
* Using a more practical algorithm, rather than the peer-to-peer signature key exchange<br />
<br />
We have chosen the two round SKEME-based Triple Diffie-Hellman deniable key authentication instead of the Schnorr signature scheme suggested in [BS07] because it saves us two critical rounds for authentication (even though it offers a slightly weaker form of deniability). We have also modified the protocol to represent the chat condition where participants sequentially join and leave the chat.<br />
<br />
* Omitting forgeability and malleability from the protocol and refraining from broadcasting the expired ephemeral authentication keys.<br />
<br />
Following conclusions in [RGK05] we have dropped forgeability (mandatory publication of ephemeral signature/MAC keys) and malleability from our requirements since protocol deniability is based on a deniable key exchange. This significantly improves protocol efficiency, a primary focus for ''(n+1)sec''. The deniability of the authentication scheme prevents users not present in a chat session from forging a part of the transcript, however it allows them to forge a whole session with false participants and a complete transcript.<br />
<br />
Another major departure from the suggested protocol in [GUVGC09] is in-session transcript authentication, which happens every time a participant receives or sends a message. Transcript authentication (referred to as transcript consistency check from here on) is an optimistic approach based on the assumption that the chat server is mandated to provides a reliable and orderly message delivery, as it is in the case of XMPP protocol. We can ensure transcript consistency whenever the underlying transport layer guarantees the reliable delivery of the messages in the same order for all participants. If however, the underlying protocol does not guarantee reliability either in delivery or order, we report the discrepancy in user's transcript compared to their peers but we do not attempt to correct the transport protocol's action (we offer detection but not recovery).<br />
<br />
We also equip ''(n+1)sec'' with heartbeat to ensure in-session forward secrecy, periodical consistency check and freshness. <br />
<br />
We propose the possibility of using block-based, rather than stream-based, encryption for the symmetric encryption primitives. <br />
<br />
Finally, other protocol design possibilities considered and the rationale for not pursuing them further is discussed in [[#Appendix_B:_Other_design_possibilities|Appendix B: Other design possibilities]]<br />
<br />
= IV. Security Properties =<br />
<br />
<span style="font-size:200%">F</span>ollowing from the design rationales proposed in Section[[''(n+1)sec''#Design_rationale|III]], we give an informal description of the properties which ''(n+1)sec'' aims to secure in a multi-party chat session:<br />
<br />
* <span>'''Participant deniable authenticity'''</span> based on their long term persistent identity: While a participant in a chat can be sure of another participant’s authenticity, they cannot prove their confidence to anybody else who has not actively participated in the chat session or who has not interacted with the authenticator prior to the session.<br />
* <span>'''Message origin authenticity'''</span> against both outsider intrusion and the impersonation of existing participants by other malicious participants in the session. This means that the user can be assured of the authenticity of the sender of each original message even if other participants in the room try to impersonate the sender and send messages on their behalf.<br />
* <span>'''Confidentiality'''</span> of the conversation so its content is not accessible or readable by an outsider.<br />
* <span>'''Forward secrecy'''</span> of the conversation, so its content remains inaccessible in the event that the long term private key of a participant (which represents their long term identity) is compromised after session key establishment. In addition in-session forward secrecy means that compromise of the ephemeral keys of a participant, or the session key during chat session which is live for long time, would reveal only a fraction of the transcript.<br />
* <span>'''Room consistency'''</span>, where all participants are confident that they have been participating in the same room; they are confident that everybody in the room believes that everybody else sees the same participant list as they do.<br />
* <span>'''Transcript consistency'''</span>, where all participants are confident that they have been participating in the same conversation; as the conversation continues, they are confident that they have been seeing the same sequence of messages.<br />
<br />
For each of these requirements, it is necessary to formalize the above mentioned properties against an adversarial model which addresses the requirements stated in [[#Design_rationale|Section III]]. The next section will introduce formal definitions covering these elements.<br />
<br />
= V. Chat Session Model =<br />
<br />
In modelling the chat session, in terms of the adversarial models and protocol specifications, the notation of [ACMP10] is followed. This notation is common to other publication on group key exchange such as [GBNM11], and is adherred to for consistency. <br />
<br />
<span>'''Definition V.1 Multi-party chat session'''</span>'': Let <math>\mathcal{U} = \{U_1,...,U_m\}</math> be the set of possible participants. A multi-party chat session is an ordered pair <math>S := (\mathcal{S}, sid)</math> in which <math>\mathcal{S} \subset \mathcal{U}</math> and <math>sid</math> is the unique session id. Without loss of generality we assume <math>\mathcal{S} = \{U_1,...,U_n\}</math> and we interchangeably refer to party <math>U_i</math> by index ''i''. Furthermore, it is assumed that party <math>U_i</math> is presented and identified verifiably by a long-term persistence key pair <math>(LPK_{U_i}, LSK_{U_i})</math>.''<br />
<br />
<span>'''Definition V.2 sub session'''</span> After session ''S'' is established, A subset of participants <math>\mathcal{T}\subset \mathcal{S}</math> might want to start a session in which parties in <math>\mathcal{T}\backslash\mathcal{S}</math> are excluded (for example when those parties leave the chatroom). In such a setting we say <math>T := (\mathcal{T}, sid^T)</math> is a subsession of ''S''. When there is no need to specify the subsession of choice, we use <math>spid</math> to refer to <math>sid^T</math>.<br />
<br />
<span>'''Definition V.3''' ''An'' '''authenticated group key exchange (AGKE)'''</span> ''is Algorithm <math>\Pi</math> which each honest party will execute in order to communicate (by means of sending, receiving or computing) a cryptographic secret - namely a key - among the other parties of a session. By <math>\Pi^S_i</math> (or <math>\Pi_i</math> when the underlying session is understood) we are referring to an instance of <math>\Pi</math> which the party <math>U_i</math> executes to achieve the collective goal. Further more we define'':<br />
<br />
* <span>'''Session id as seen by <math>U_i</math>'''</span>'': Session id <math>sid</math> will be derived during the execution of the protocol. The session id is computed by <math>\Pi^S_i</math> (the instance of the protocol run by <math>U_i</math> for session ''S'') and is indicated by <math>sid^S_i</math>, or <math>sid_i</math> when there is no concern of confusion''<br />
* <span>'''Participant list'''</span>'': <math>plist^S_i</math> is the list of participants which <math>U_i</math> believes are participating in the chat session ''S''.'' When there is no ambiguity in the underlying session, we simply use <math>plist_i</math> notation.<br />
* <span>'''key id'' is the serial number given to the P2P keys generated during the process of key exchange, is computed as <math>Hash(U_i|y_i|U_j|y_j)</math>.<br />
* <span>'''Ephemeral key list'''</span>'': <math>klist^S_i</math> is the list of ephemeral public key <math>y_j = g^{x_j}</math>'s of all participants which <math>U_i</math> believes they are using in the chat session ''S''.'' When there is no ambiguity in the underlying session, we simply use <math>klist_i</math> notation instead. We use the notaion of <math>plist_i|klist_i</math> to represent ordered concatenation of <math>U_i|y_i</math> pairs as in <math>U_1|y_1|\dots|U_n|y_n</math>. The order is assumed to be computable by all participants (lexicographically ordered using long term public key of participants, for example).<br />
* <span>'''Session key of <math>\Pi^S_j</math> as seen by <math>U_i</math>'''</span>'': <math>sk^S_i</math> (or <math>sk_i</math>) is the session key of session ''S'' as computed by <math>\Pi_i</math>. It represents the cryptographic secret computed by AGKE, it can be a set of secrets. The essential defining factor is that it should become common knowledge for the session participants at the end of AGKE execution. Similarly we define <math>subk_i</math> to represent the subsession key''<br />
* <span>'''Accepted state'''</span>'': A party enters the accepted state if it has computed <math>sk^S_i</math> and has detected no errors in the protocol.''<br />
* <span>'''Partnered instances'''</span>'': Two instances <math>\Pi^S_i</math> and <math>\Pi^S_j</math> are considered partnered if and only if both instances have accepted <math>sid_i=sid_j</math> and <math>plist_i = plist_j</math>.''<br />
<br />
* A <span>'''correct'''</span>'' AKGE algorithm is an AKGE which, when all <math>\Pi^S_i</math> instances of AKE algorithm are initiated with access to a network which correctly forwards all messages without modification, all participants ultimately are partnered and all compute equal <math>sk^S_i</math>’s''.<br />
<br />
When underlying session are not considered we may omit the super script <math>\_^S</math> from all above notations.<br />
<br />
= VI. Threat Models and Adversarial Goals =<br />
<span style="font-size:200%">A</span>dversarial models are explained as a game, in which the adversary's possibilitiy of winning the game should be considered in terms of their ability to break the cryptographic primitives.<br /><br />Accordingly to the requirements discussed in Section [[''(n+1)sec''#Security_Properties|IV]], it is necessary to examine the algorithm in terms of following threat cases:<br />
<br />
# Deniable Authenticated key exchange (including a forward secrecy adversary)<br />
# Message origin authenticity<br />
# Confidentiality<br />
# Transcript consistency<br />
<br />
The following sections will define adversarial scenarios which represent the above threats.<br />
<br />
==Deniable Authenticated Key Exchange Adversary==<br />
Following the approach in [BoSt06] the model is divided into two adversaries: ''Authenticated Group Key Exchange'' and the ''Deniability Adversary''.<br />
<br />
As deniability is not our primary focus, we wil consider a weaker deniability adversarial model, which limits possible input similarly to the limitations considered by [GKR06]. This provision would disallow an input from the 'judge' and therefore saves an extra round of communication within the protocol.<br />
<br />
Because he t''(n+1)sec'' protocol runs a peer-to-peer key exchange and establishes parallel deniable authentication, we use the adversarial model from [ACMP10] for ''authenticated group key exchange''. This ensures the security of both group and peer-to-peer keys independently. The protocol also takes advantage of "single<br />
round computation of a subgroup key". Meaning that when a participant leaves the session remaining participants can re-establish a (sub)session with only one round of communication. In this circumstance, the model must also consider an adversary's attack against the subgroup key.<br />
<br />
We do not attempt to model resistance against internal key compromise impersonation (KCI) as defined [GBNM11].<br />
<br />
===Authenticated Key Exchange Adversary===<br />
====Adversarial power====<br />
<br />
The following set of functions model the AKE adversarial threats. The adversary for the authenticated key exchange can mount an attack through a sequence of call to the functions, outlined below. The limitation on the order and condition of calling these functions is defined per adversary. We will re-use these definitions to demonstrate similar routes for other adversaries considered by the threat models in later sections.<br />
<br />
* <span>'''Execute(<math>plist</math>)'''</span>: asks all parties in the <math>plist</math> to run (a new) AGKE protocol and <math>\mathcal{A}</math> will receive the execution transcript, i.e.<math>\mathcal{A}</math> can eavesdrop.<br />
* <span>'''Send(<math>\Pi^S_i,m</math>)/(<math>U_i,m</math>)'''</span> sends a message ''m'' to the instance <math>\Pi^S_i</math>. We assume that ''m'' contains information to identify the sender <math>U_j</math>. <math>\mathcal{A}</math> will receive the execution transcript. Specifically, by sending <math>plist</math> messages it forces <math>U_i</math> to initiate <math>\Pi^S_i</math>.<br />
* <span>'''SKE(<math>\Pi^S_i, spid_i</math>)''': asks <math>\Pi^S_i</math> to compute the subgroup key for the <math>spid_i</math> subsession. In response, <math>\Pi^S_i</math> will either send a message or compute the subgroup key <math>k_{spid_i}</math> depending on the state of <math>\Pi^S_i</math>. This can be invoked only once per input. <br />
* <span>'''RevealGK(<math>\Pi^S_i</math>)''': <math>\Pi^S_i</math> gives <math>sk_i</math> to <math>\mathcal{A}_a</math> if it has accepted (as defined in Definition III.3).<br />
* <span>'''RevealSK(<math>\Pi^S_i, T</math>)''': <math>\Pi^S_i</math> gives the <math>subk^T_i</math> to <math>\mathcal{A}_a</math> if it has been computed for subsession ''T''.<br />
* <span>'''Corrupt(<math>U_i</math>)'''</span>: <math>U_i</math> gives its long term secret key to <math>\mathcal{A}_a</math> (but not the session key).<br />
<!--This is the power for KCI * <span>'''%% \item {\bf RevealState(<math>\Pi_i</math>)}: reveal the internal state of <math>\Pi_i</math> to <math>\mathcal{A}_a</math> (no longer available after acceptance).--><br />
<br />
====Adversary's challenges====<br />
<br />
The following set of functions model the adversary's challenges. These reveal either a random value or a key. The adversary's advantage in distinguishing the cases should be translatable into an attack against the GDH primitive for the protocol to be considered secure.<br />
<br />
* <span>'''TestGK(<math>\Pi^S_i</math>)'''</span>: To the ultimate goal of challenging the confidentially of <math>sk_i</math>, <math>\mathcal{A}</math> can run TestGK(<math>\Pi^S_i</math>) against ''U''. As a the result a random bit ''b'' is chosen, if <math>b = 1</math> then <math>\mathcal{A}_a</math> is given <math>sk_i</math> the session key, otherwise a random value from the same probability distribution is given to <math>\mathcal{A}</math>. Obviously, this can only be invoked once and only on accepted participants.<br />
* <span>'''TestSK(<math>\Pi^S_i</math>)'''</span>: To the ultimate goal of challenging the confidentially of <math>subk^T_i</math>, <math>\mathcal{A}</math> can run TestSK(<math>\Pi^S_i</math>) against ''U''. The result depends on a a random chosen bit ''b'', if <math>b = 1</math> then <math>\mathcal{A}</math> is given <math>subk^{T}_i</math> the subsession key, otherwise a random value from the same probability distribution is given to <math>\mathcal{A}</math>.<br />
<br />
=== Definition of Adversaries and their advantages ===<br />
<br />
The following terminology is useful in simplifying the elimination of trivial adversarial threats. <br />
<br />
'''Definition VI.1''' Accepted <math>\Pi^S_i</math> is '''fresh''' if none of the following is true:<br />
* RevealGK(<math>\Pi_j^s</math>) for <math>U_j \in plist</math>.<br />
* Corrupt(<math>U_j</math>) invoked for any <math>U_j \in plist</math> before any Send(<math>\Pi^S_i,.</math>).<br />
<br />
'''Definition VI.2''' A pair of <math>\Pi^S_i, spid^S_i</math> is '''fresh''', if <math>\Pi^S_i</math> is accepted and if none of the following is true:<br />
* RevealSK(<math>\Pi_j^s, spid^S_i</math>) for <math>U_j \in plist</math>.<br />
* Corrupt(<math>U_j</math>) invoked for any <math>U_j \in plist</math> before any Send(<math>\Pi^S_i,.</math>).<br />
<br />
'''Definition VI.3''' An ''AKE Adversary for the join key agreement'' <math>\mathcal{A}_{join}</math> is a probabilistic polynomial time algorithm (ppt) which can invoke all the functions given above with a<br />
condition that the TestGK is invoked '''at least once''' against a fresh instance <math>\Pi^S_i</math> which stays fresh until the end of the game. The game ends when <math>\mathcal{A}_{join}</math> outputs its guess for ''b''. We say a key exchange protocol is secure if the following function is negligible:<br />
<center><br />
<math><br />
max_{\forall \mathcal{A}_{join}}|2Pr(Output(\mathcal{A}_{join}) = b) - 1|<br />
</math><br />
</center><br />
<br />
Similarly we define <math>\mathcal{A}_{leave}</math> the Adversary leaving the session:<br />
<br />
'''Definition VI.4''' An ''AKE Adversary for the leave key agreement'' <math>\mathcal{A}_{leave}</math> is a ppt which can invoke all the functions given above with the condition that one of the invocations of TestSK is invoked against a fresh instance <math>(\Pi^S_i, spid_i)</math> which stays fresh till the the end of the game. The game ends when <math>\mathcal{A}_{join}</math> outputs its guess for ''b'' for that invocation. We say a key exchange protocol is secure if the following function is negilgible:<br />
<center><br />
<math><br />
max_{\forall \mathcal{A}_{leave}}|2Pr(Output(\mathcal{A}_{leave}) = b) -1|<br />
</math><br />
</center><br />
<br />
===Forward Secrecy Adversary===<br />
<br />
We do not define an independent forward secrecy adversary. Forward secrecy can be derived by resistance against the confidentiality adversary as well incorporating a forward secure key exchange as described in [GBN10]. The adversaries of Definition VI.3 and VI.4, are able to ''Corrupt'' users after the communication of DH secrets. Therefore they can trivially break an AKE without forward secrecy. In this sense, the resistance against forward secrecy adversary is included in AKE adversarial model.<br />
<br />
===Deniability Adversary===<br />
<br />
We use the deniability adversary of [BoSt06], however following the path of [GRK06], we limit the security input of the deniability adversary in order to prevent the adversary from receiving input from the ''judge''.<br />
<br />
'''Definition VI.5''' A '''Deniability Adversary '' <math>\mathcal{A}_{deny}</math> with bound <math>q_c</math> and security input <math>Aux</math> is a ppt algorithm which can invoke Send and Reveal as desired and Corrupt as many as <math>q_c</math> times. At the end, <math>\mathcal{A}_{deny}</math> will output a transcript <math>T_{\mathcal{A}_{deny}}(Aux)</math>.<br />
<br />
'''Definition VI.6''' For each <math>\mathcal{A}_{deny}</math>, we define a ''simulator'' <math>\mathcal{S}_{deny}</math>, is a ppt algorithm which receives the same input as <math>\mathcal{A}_{deny}</math>. It can invoke ''Corrupt'' <math>q_c</math> times in addition to ''Send'' and ''Reveal'' but only against corrupted instances. It terminates by outputting a transcript <math>T_{\mathcal{S}_{deny}(Aux)}</math>. <br />
<br />
'''Definition VI.7''' A ''deniability judge'' <math>\mathcal{J}</math> with security input <math>Aux</math> is a ppt algorithm which can invoke arbitrary number of deniability adversaries <math>\mathcal{A}_{deny}</math> with security input <math>Aux</math>. On each execution of <math>\mathcal{A}_{deny}</math> a corresponding <math>\mathcal{S}_{deny}</math> runs with the same input. At the end a confidential random bit ''b'' is generated, and either <math>T_{\mathcal{A}_{deny}}(Aux)</math> or <math>T_{\mathcal{S}_{deny}}(Aux)</math> is presented to <math>\mathcal{J}</math> based on whether <math>b = 1</math> or 0 respectively. <br />
<br />
'''Definition VI.8''' We call a Group AKE deniable with respect to input set <math>Aux</math>, if the following advantage is negligible:<br />
<math><br />
max_{\forall \mathcal{J}}|2Pr(Output(\mathcal{J}, Aux) = b) -1|<br />
</math><br />
<br />
Similar to [GRK06], we claim that the AKE presented in this paper is deniable when <math>Aux</math> is equal to the set of valid messages eavesdropped by <math>\mathcal{A}_{deny}</math> during other sessions. This, in particular, excludes a transcript computed by <math>\mathcal{J}</math> such as a group element whose discrete logarithm is only known to <math>\mathcal{J}</math> (This means <math>\mathcal{A}_{deny}</math> is given <math>g^a</math> but is unaware of ''a'').<br />
<br />
==Secure Multiparty Channel Adversary==<br />
The desirable way to define an adversary for a multiparty chat session is a secure channel model similar to the two-party secure channels described in [CaKr01] and [KPW13]. However, defining such a model is outside of our current scope. It is desirable to later improve the security of the protocol bu considering such a model at a later stage. At present, we use a per message model for confidentiality and origin authenticity.<br />
<br />
==Message Origin Authentication Adversary==<br />
<br />
<span style="font-size:200%">A</span>s each participant executes a sign and encrypt function before sending their authenticated ephemeral signing key, the message origin adversary model is based on a typical adversary for a signature scheme such as the one presented in [PVY00].<br />
<br />
===Adversarial power===<br />
<br />
In addition to adversarial functions defined in section 1.1.1. we must define the following function to allow for the adversary using the chosen-message attack.<br />
<br />
* <span>'''MakeSend(<math>\Pi^S_i,\Pi^S_j, m</math>)'''</span> causes the <math>\Pi^S_i</math> to sign and send a valid message ''m'' to instance <math>\Pi^S_j</math>. <math>\mathcal{A}</math> will receive the transcript including the signature.<br />
<br />
===Definition of Adversary===<br />
<br />
'''Definition VI.9''': ''Message Origin Authentication Adversary'' <math>\mathcal{A}</math> is a polynomial time algorithm which has access to the '''Corrupt''', '''Send''', '''Reveal''' and '''MakeSend''' functions. The output of the algorithm should be a message ''m'' sent to instance <math>\Pi^S_j</math>. The scheme is secure against Message Origin Adversary if the probability in which <math>\Pi^S_j</math> believes that ''m'' has originated from an uncorrupted participant <math>U_i</math> is negligible.<br />
<br />
==Message Confidentiality Adversary ==<br />
<br />
The goal of adversary <math>\mathcal{A}_{conf}</math> is to read, at least, part of the communications transcript during the session.<br />
<br />
===Adversary's challenges===<br />
The following set of functions model the confidentiality adversary's challenges. These reveal either a random value or an encrypted message. The adversary's advantage in distinguishing the cases should be translatable into an attack against the block cipher, AES in this case.<br />
<br />
* <span>'''TestM(<math>\Pi^S_i, m</math>)'''</span>: To the ultimate goal of challenging the indistinguishibility of <math>E(m)></math>, <math>\mathcal{A}_{conf}</math> can execute TestM(<math>\Pi^S_i, m</math>) against <math>U_i</math>. As a result a random bit ''b'' is chosen, if <math>b = 1</math> then <math>\mathcal{A}_{conf}</math> is given <math>E_{s_k}(m)<math>, the encrypted message, otherwise a random value from the same probability distribution is given to <math>\mathcal{A}_{conf}</math>.<br />
<br />
===Definition of Adversaries and their advantages===<br />
<br />
'''Definition 1''' A ''Confidentiality Adversary'' <math>\mathcal{A}_{conf}</math> is a ppt which can invoke all the functions given in sections [[''(n+1)sec''#Adversarial_power|IV.1.1.1]] and [[''(n+1)sec''#Adversarial_power|IV.1.1.3]] with the condition that one of the invocations of TestM is invoked against an instance <math>\Pi^S_i</math> where all instances in session ''s'' are fresh and stay fresh till the end of the game. The game ends when <math>\mathcal{A}_{conf}</math> outputs its guess for ''b'' for that invocation. We say that the protocol is secure if the following function is negligible:<br />
<center><br />
<math><br />
max_{\forall {A}_{conf}}|2Pr(Output(\mathcal{A}_{conf}) = b) -1|<br />
</math><br />
</center><br />
<br />
==Consistency Adversary==<br />
In ''(n+1)sec'' protocol, we attempt to ensure the consistency among participants all along the session incrementally, i.e. assuring consistency after receiving each message in a timely manner. However, we do not model the incremental aspect of consistency into the adversarial model, for the sake of simplicity.<br />
<br />
'''Definition 1''' ''Transcript Consistency Adversary'' <math>\mathcal{A}_{cons}</math> is given the ability to invoke all functions in sections [[''(n+1)sec''#Adversarial_power|IV.1.1.1]] and [[''(n+1)sec''#Adversarial_power|IV.1.1.3]]. We say the protocol is secure against ''Consensus Adversary'' if at least two uncorrupted accepted instances <math>\Pi^S_i, \Pi^S_j</math> possess the transcripts chain <math>TransChain_{\Pi^S_i}(l) \neq TransChain_{\Pi^S_j}(l)</math> and they believe they have the <math>TransChain_{\Pi^S_i}(l) = TransChain_{Pi^S_j}(l) with non-negligible probability.<br />
<br />
For definition of <math>TransChain_{\Pi^S_i}(l)</math> see Section [[''(n+1)sec''#Definitions_and_assumptions|VII.4.1]].<br />
<br />
= VII. Protocol High Level Design =<br />
<br />
<span style="font-size:200%">T</span>o achieve the security properties listed in [[#IV._Security_Properties|Section IV]], we break the protocol into the following sub-protocols:<br />
<br />
# <span>'''Deniable authenticated signature key and session key exchange'''</span>, where participants deniably authenticate each other and agree on session key(s), while also exchanging ephemeral signing keys<br />
# <span>'''Communication'''</span>, where parties send authenticated confidential messages<br />
# <span>'''Transcript consistency verification'''</span>, where parties verify that all have received and seen an identical transcript in the same order, since the start of the chat session after receiving each messages.<br />
<br />
Our choice of sub-protocols for ''(n+1)sec'' followed suggestions made in [BGB04] and [GUVGC09], except where there has been a practical or security-related reason to deviate from those recommendations.<br />
<br />
In the following section we briefly describe our choice of the sub-protocols for each of the required tasks for a multi-party chat session.<br />
<br />
== '''VII.1 Design of Deniable Authenticated Signature Key Exchange'''==<br />
<br />
We have chosen our deniable signature key exchange protocol following the conclusions in [Gun13b] - by identifying a secure key exchange protocol that satisfies our needs. We then apply the triple Diffie-Hellman authenticated exchange to grant it properties of deniability [Ma13]. Subsequently, one can apply the same approach presented in [Gun13b] to communicate ephemeral signature keys during the key establishment process. However, for efficiency, we use the same ephemeral Diffie-Hellman private and public values used to deniably authenticate users and generate secret shares to produce ephemeral signatures.<br />
<br />
For the choice of the base authenticated key exchange protocol, we suggest a variant based on [ACMP10]. The rationale for the choice is laid out as follows:<br />
<br />
* The base design of the protocol in [ACMP10] is the same as the base for [BVS05] (recommended by [Gun13a]). However, the protocol presented in [ACMP10] is simpler.<br />
* [ACMP10] offers a peer-to-peer key exchange with no extra rounds, if needed.<br />
* [BVS05] and [ACMP10] are superior to the widely studied [BCPQ01] and its dynamic variation [BCP01] both in security and performance (<math>O(1)</math> rounds).<br />
* [BVS05] has been suggested by [Gun13b] for the reason described in [Gun13a]. We believe that the new deniable authentication approach, as it is similar to the SKEME protocol, satisfies the properties of deniability which [BVS05] considered crucial aside from the cooperating judge.<br />
* Security analysis of [GBNM11] and [BCGNP08] has found that [BVS05] is provably secure against all attacks (including the insider attacks) that the papers consider.<br />
* It is a two-round protocol and hence offers competitive efficiency considering the security property that it provides.<br />
<!--* [BVS05] has existed for years and its various security aspects have been investigated by several researchers including [GBNM11] and [BCGNP08] which gives [BVS05] an advantage over newer algorithms.!--><br />
* [ACMP10] only needs one round of key re-agreement in the case of a participant leaving the chat, while [BVS05] enforces re-computation of Diffie-Hellman ephemeral keys and hence needs a minimum of two rounds plus overhead of re-authenticating the new ephemeral keys. This can significantly improve the efficiency of casual chat sessions where participants frequently enter and exit the chat.<br />
* Although the Schnorr based algorithm suggested in [BVS05] satisfies a more comprehensible deniable model, triple Diffie-Hellman authenticated key exchange only needs two rounds of communication and can be done alongside the key agreement steps, while the Schnorr based algorithm of [BVS05] needs four rounds.<br />
* Although key exchange algorithms based on the standard model are considered theoretically more secure than those based on the random oracle model, there has been no proposal for a 2-round protocol in the standard model that promises forward secrecy. Therefore, due to the importance of usability and efficiency in our approach, we opted to for a ROM based protocol such as described by [BVS05] and [ACMP10].<br />
<br />
===VII.1a Sharing a secret among the group===<br />
All AGKE descriptions take the necessary steps to share a common secret confidentially among the group members along side other operations such as authentication and insuring partnership. To insure forward secrecy these methods mostly rely upon a P2P Deffie-Hellman key exchange. Most AGKE descriptions rely on sharing an equation and solving a specific linear system described in [[''(n+1)sec''#GroupEnc and GroupDec Functions|IX.4]].<br />
<br />
We abstract this step as GroupEnc/GroupDec primitive, to allow for alternative designs which do not interact with the rest of the protocol and might offer other benefits. For example the "Naive peer-to-peer" primitive [[''(n+1)sec''#GroupEnc_and_GroupDec Functions|IX.4]] trades simplicity and generalizability (to a broadcast scheme c.f. [[''(n+1)sec''#VII.2 Other design possibilities|Section VII.2]]) for bandwidth consumption. <br />
<br />
== '''VII.3 Message Authentication''' ==<br />
<br />
As message authentication needs to be resistant to malicious insiders, following the outline of [GUVGC09], ''(n+1)sec'' signs each message using a public key signature scheme. The messages are signed with the ephemeral key of the sender. The authenticity of the origin can be verified by the public ephemeral key of the party distributed during the key exchange period.<br />
<br />
== '''VII.4 Transcript Ordering and Consistency''' ==<br />
<br />
Since each message sent by any one participant is signed by the ephemeral private key generated for that specific session, it is not possible for the internal or external adversary to forge a message on behalf of an uncorrupted participant.<br />
<br />
However, if the adversary is controlling the network structure, denial or delay of service is always possible. The consistency of the transcript (i.e. all participants see the same transcript in the same order) relies on the means of transport guaranteeing reliable delivery, with a single order, to every participant. In other words, we are verifying the ''reception'' of the message by the intended ''recipients''.<br />
<br />
By assuring transcript consistency, we also preventing <math>U_i</math> from sending different messages to <math>U_j</math>, <math>U_k</math> while they believe they are seeing the same conversation. In absence of transcript consistency, when a central server is managing the chatroom, this attack requires <math>U_i</math> to conspire with server, which is permeable in ''(n+1)sec'' threat model in accordance with the definition of transcript consistency in [GUVGC09].<br />
<br />
The protocol offered in this document examines the transcript for such consistency. In the case that the underlying transport fails to provide this level of consistency, clearly the consistency test will fail. In this sense, failure of consistency does not distinguish between malicious activities or the absence of a reliable transport.<br />
<br />
''(n+1)sec'' performs transcript authentication whenever a message is received. This is to guarantee consistency and protect the protocol against the transcript consistency attack. The procedure is similar to the procedure described in [GUVGC09], with two major differences:<br />
<br />
* We require additionally that message order be preserved for the following reasons:<br />
<br />
# XMPP, as the main protocol considered for this design, delivers messages to all clients in the same order.<br />
# The ''(n+1)sec'' protocol detects if the adversary has manipulated the order of the messages rather than only dropping undesirable messages<br />
# It is simpler to authenticate an ordered transcript compared to an unordered transcript.<br />
<br />
* We also require that each participant updates all other participants about their view of the session transcript every time they send a message, along with requiring heartbeat, this ensures that participants are aware whether or not they are all seeing the same transcript during the session.<br />
<br />
There are some cases where XMPP can fail our reliability assumption. In such cases, our consistency checks will fail. More advanced end-to-end recovery techniques are able to rescue such a scenario. We do not specify such techniques currently, though later versions of the protocol may rectify this.<br />
<br />
=== Definitions and assumptions ===<br />
'''Transport assumption''':<br />
We assume the central server reliably delivers messages to everyone, including the original sender, in the same order.<br />
<br />
'''Definition''' Each message ''M'' (sent after session S has been established) has an implicit server-sequence-number ''seqnum(M)'', a receive-parent: ''parent(M)'' (or recv-parent) the seqnum of last message the sender has received before sending ''M'' and a sender-sequence-number ''own-seqnum(M)''. We interchangeable use ''m'' when refering to both a message and its seqnum.<br />
<br />
Once a message ''M'' with seqnum ''m'' is received by instance <math>\Pi^S_i</math> from the server (including participants own messages sent), a <math>TranscriptChain^S_i[m]</math> may be calculated recursively as follows:<br />
<br />
<math>TrascriptChain^S_i[m] := (M, Hash(TranscriptChain^S_i[m - 1]))</math><br />
<br />
(we define TrascriptChain[0] = (sk^S_i, sid_i))<br />
<br />
A new message ''M'' contains ''p'' the seqnum of recv-parent of ''m'', <math>Hash(TranscriptChain^S_i[p])</math> and ''own-seqnum(M)''.<br />
<br />
* We say instance <math>\Pi^S_i</math> has ''accepted'' message ''m'' if it has been received by <math>\Pi^S_i</math>, then decrypted-verified.<br />
<br />
* We say instances <math>\Pi^S_i</math> and <math>\Pi^S_j</math> have reached mutual consistency for message ''m'' if both accepted message ''m'' and have calculated the same hash of <math>TranscriptChain(m)</math> and verified <math>H_j(TranscriptChain^S_i[m])) == H_i(TranscriptChain^S_i[m])</math>. <br />
<br />
* We say session ''S'' has reached consistency on message ''m'', if all instances <math>\Pi^S_i, \Pi^S_j \in plist^S</math>, <math>\Pi^S_i</math> and <math>\Pi^S_j</math> have reached mutual consistency.<br />
<br />
=== Server order ===<br />
All clients see the same message order from the server. All messages are sent to all users. Aside from the presence messages (messages which indicate a user is joining or leaving a chatroom or if they have been inactive for a long time) sent by the server, messages are sent by users.<br />
<br />
All messages in a room have a unique sequence number (0, 1, ...). We assume that the server is unaware of sequence numbers (e.g. XMPP MUC); clients must allocate them implicitly when receiving messages.<br />
<br />
= VIII. ''(n+1)sec'' Protocol: Step by Step =<br />
<br />
<span style="font-size:200%">I</span>n this section we present the ''(n+1)sec'' protocol in algorithmic format. All user IDs should be considered the modulo number of participants in the room.<br />
<br />
Deniable authentication is derived from the Triple Diffie-Hellman algorithm presented in [Sys14]. Joining the room is a variation of the two-round mBD+P protocol presented in [ACMP10] where the authentication step has been made deniable. Leaving the room is the one-round mBD+S from [ACMP10]. In both cases, we have added a key confirmation round (round 3) as recommended by [ChMa10] to provide mutual authentication as defined in [GBNM11].<br />
<br />
==VIII.1 Schematic view of the key exchange==<br />
<br />
The protocol computes a unified session key for all participants. This imposes, in particular, the necessity that all <math>plist_i</math>' is identical for all participants.However, as consistent view is part of ''(n+1)sec'' security model, it does not impose extra limitation on the protocol. For more information please see [[#Participatory_vs_individually_independent_computation_of_group_keys|Appendix B: Participatory vs individually independent computation of group keys]].<br />
<br />
For simplicity, group operation is written multiplicatively (even though it is actually an elliptic curve point operation traditionally represented by addition).<br />
<br />
Whenever our design deviates from [ACMP10], it is marked in {{Font color|black|yellow|yellow}}. We have abstracted out the steps mentioned in [ACMP10] as an independent primitive in {{Font color|black|pink|pink}}, however the resulting computation is identical with the one in [ACMP10] protocol:<br />
<br />
'''Algorithm 1'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="center"|Round<br />
!align="center"|Step<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="center"|1<br />
|align="center"|1<br />
|align="right"|Generate ephemeral DH private key<br />
|align="center"|<math> x_i \leftarrow [0, order(g)]</math><br />
|align="center"|Computation<br />
|-<br />
|align="center"|<br />
|align="center"|2<br />
|align="right"|Generate DH key for BD, Triple DH and Signature<br />
|align="center"|<math>y_i \leftarrow g^{x_i}</math><br />
|align="center"|Computation<br />
|-<br />
|align="center"|<br />
|align="center"|3<br />
|align="right"|Broadcast User identity and the DH key<br />
|align="center"|<math>(U_i, y_i)</math><br />
|align="center"|Broadcast<br />
|-<br />
|align="center"|2<br />
|align="center"|4<br />
|align="right"|Compute Session Id<br />
|align="center"|<math>sid_i \leftarrow (U_1|y_1|\dots|U_n|y_n)</math><br />
|align="center"|Receive<br />
|-''(n+1)sec''<br />
|align="center"|<br />
|align="center"|5<br />
|align="right"|Generate Triple Diffie-Hellman P2P keys<br />
|align="center"|{{Font color|black|yellow|<math>k_{i,j} \leftarrow H({y_j}^{LSK_{U_i}},LPK_{U_j}^{x_i},y_j^{x_i}) \; \forall j \neq i</math>}}<br />
|align="center"|Computation<br />
|-<br />
|align="center"|<br />
|align="center"|6<br />
|align="right" |Generate key confirmations<br />
|align="center"|{{Font color|black|yellow|<math>kc_i \leftarrow (H(k_{i,1}, U_1),\dots,H(k_{i,n}, U_n))</math>}}<br />
|align="center"|Computation<br />
|-<br />
|align="center"|<br />
|align="center"|7<br />
|align="right"|Generate secret shares<br />
|align="center"|<math>z'_i \leftarrow (H(k_{i,j}, sid_i) \, \textrm{for} \, j \neq i \, \textrm{and} \, j \in \{1,\dots,n\})</math><br />
|align="center"|Computation<br />
|-<br />
|align="center"|<br />
|align="center"|8<br />
|align="right" |Encrypt shares<br />
|align="center"|{{Font color|black|pink|<math>z_i \leftarrow GroupEnc(k_{i,j} \, \textrm{for} \, j \neq i \, \textrm{and} \, j \in \{1,\dots,n\}, z'_i)</math>}}<br />
|align="center"|Computation<br />
|-<br />
|align="center"|<br />
|align="center"|9<br />
|align="right"|Sign identity, shares<br />
|align="center"|<math>\sigma_i \leftarrow Sign_{x_i}(U_i, z_i, sid)</math><br />
|align="center"|Computation<br />
|-<br />
|align="center"|<br />
|align="center"|10<br />
|align="right"|Broadcast encrypted shares and confirmation<br />
|align="center"|<math>(U_i, z_i, \sigma_i,</math>{{Font color|black|yellow|<math>kc_i</math>}}'')''<br />
|align="center"|Broadcast<br />
|-<br />
|align="center"|3<br />
|align="center"|11<br />
|align="right"|Check the validity of key confirmation<br />
|align="center"|{{Font color|black|yellow|<math>H(k_{j,i},U_i) \stackrel{?}{=} kc_j[U_i] \; \forall j \neq k</math>}}<br />
|align="center"|Receive<br />
|-<br />
|align="center"|<br />
|align="center"|12<br />
|align="right"|Check signatures<br />
|align="center"|<math>Verify_{y_j}(\sigma_j) \; \forall j \neq i</math><br />
|align="center"|Computation<br />
|-<br />
|align="center"|<br />
|align="center"|13<br />
|align="right"|Check Session Ids<br />
|align="center"|<math>sid_j \stackrel{?}{=} sid_i \; \forall j \neq i</math><br />
|align="center"|Computation<br />
|-<br />
|align="center"|<br />
|align="center"|14<br />
|align="right"| Generate session key<br />
|align="center"|{{Font color|black|pink|<math>sk_{i} \leftarrow H(GroupDec(k_{i,l} \forall l, z_j ) \forall j, sid_i)=H(z'_1, \dots, z'_n, sid_i) </math>}}<br />
|align="center"|Computation<br />
|-<br />
|align="center"|3<br />
|align="center"|15<br />
|align="right"| Broadcast session confirmation<br />
|align="center"|{{Font color|black|yellow|<math>(sc_{i} \leftarrow H(sk_i,U_i), sigma_i \leftarrow Sign_{x_i}(sc_{i}))</math>}}<br />
|align="center"|Broadcast<br />
|-<br />
|align="center"|-<br />
|align="center"|16<br />
|align="right"|Check the validity of session confirmation<br />
|align="center"|{{Font color|black|yellow|<math>H(sk_{i},U_j) \stackrel{?}{=} sc_j \; \forall j \neq i</math>}}<br />
|align="center"|Receive<br />
|-<br />
|align="center"|<br />
|align="center"|17<br />
|align="right"|Check signatures<br />
|align="center"|{{Font color|black|yellow|<math>Verify_{y_j}(\sigma_j) \; \forall j \neq i</math>}}<br />
|align="center"|Computation<br />
|}<br />
<br />
===Triple Diffie-Hellman authentication===<br />
''(n+1)sec'' uses a varient of Triple Diffie-Hellman (TDH) protocol also employed in Textsecure protocol [Mo13] to carry out mutual deniable authentication as well as peer-to-peer secret key exchange. It can be seen as a variation of [SoKi00] key exchange, however, unlike SoKi00], as it does not multiply all three DH secrets and therefore is not suspticble to attacks mentioned in [BoMa10].<br />
<br />
By using TDH secret both in p2p key as well as in key confirmation step, (n+1)sec both implicitly and explicitly authenticate the peers.<br />
<br />
In Algorithm 1, TDH and the original group key exchange from [ACMP10] has been combined to provide a deniable authenticated group key exchange. Here, we single out TDH Algorithm 1.1 for better presentation of the protocol for the reader. Note, that the users run step 5 differently based on their order in the group. This measure ensures that the P2P key is computed the same between two parties, i.e, <math>k_{i,j} = k_{j,i}</math>.<br />
<br />
'''Algorithm 1.1''' Triple Diffie-Hellman between <math>U_i</math> and <math>U_j</math> assuming i < j<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="center"|Round<br />
!align="center"|Step<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="center"| 1<br />
|align="center"|1<br />
|align="right"|Generate ephemeral DH private key<br />
|align="center"|<math> x_i \leftarrow [0, order(g)]</math><br />
|align="center"|Computation<br />
|-<br />
|align="center"|<br />
|align="center"|2<br />
|align="right" | Generate ephemeral DH public key<br />
|align="center"|<math>y_i \leftarrow g^{x_i}</math><br />
|align="center"|Computation<br />
|-<br />
|align="center"|<br />
|align="center"|3<br />
|align="right" | Broadcast User identity and the DH key<br />
|align="center"|<math>(U_i, y_i)</math><br />
|align="center"|Broadcast<br />
|-<br />
|align="center"|2<br />
|align="center"|4<br />
|align="right" |Receive other party id and ephemeral DH public key<br />
|align="center"|<math>(U_j|y_j)</math><br />
|align="center"|Receive<br />
|-''(n+1)sec''<br />
|align="center"|<br />
|align="center"|5<br />
|align="right"|Generate Triple Diffie-Hellman P2P keys<br />
|align="center"|<math>k_{i,j} \leftarrow H({y_j}^{LSK_{U_i}},LPK_{U_j}^{x_i},y_j^{x_i})</math><br />
|align="center"|Computation<br />
|-<br />
|align="center"|<br />
|align="center"|6<br />
|align="right" |Send key confirmation to other party<br />
|align="center"|<math>kc_i \leftarrow H(k_{i,j}, U_j)</math><br />
|align="center"|Broadcast<br />
|-<br />
|align="center"| -<br />
|align="center"|7<br />
|align="right"|Receive and Check the validity of key confirmation<br />
|align="center"|<math>kc_j \stackrel{?}{=} H(k_{j,i}, U_i)</math><br />
|align="center"|Receive<br />
|}<br />
<br />
===''GroupEnc'' and ''GroupDec'' functions===<br />
For the high level design of the protocol we do not specify the primitives for ''GroupEnc'' and ''GroupDec'' used in steps '''8''' and '''14''' of Alogrithm 1 as a part of the protocol, as we do not specifies the Hash function and the block cipher. We explain their property here. We choose a candidate in section IX.4.<br />
<br />
The ''GroupEnc'' and ''GroupDec'' functions are primitives which are called collectively by all instances involved in the session and are supposed to satisfies the following goal:<br />
<br />
'''Definition''': Let <math>\mathcal{S} := \{U_1,...,U_n\}</math> and for each <math>i,j</math>, let <math>k_{i,j}</math> be a secret shared between and only between <math>U_i</math> and <math>U_j</math>. The goal of group <math>\mathcal{S}</math> is that:<br />
<br />
# Each member of group <math>U_i</math> to generate and share a secret <math>z'_i</math> among the member of group ''G'' using public channel <math>\mathcal{C}</math>.<br />
# <math>z'_i</math> remains unknown for any <math>\mathcal{A} \not \in G</math> eavesdropping the channel <math>\mathcal{C}</math>.<br />
<br />
To this end each member <math>U_i</math> compute <math>z_i := GroupEnc(k_{i,j} \, \textrm{for} \, j \neq i \, \textrm{and} \, j \in \{1,...,n\}, z'_i)</math> and broadcast <math>z_i</math> on <math>\mathcal{C}</math>. Later on when <math>U_i</math> receives all <math>z_j</math>. It recovers all secrets <math>z'_i</math> by computing <math>GroupDec(k_{i,j} \, \textrm{for} \, j \neq i \, \textrm{and} \, j \in \{1,...,n\}, z_i)</math>.<br />
<br />
===(n+1)sec key exchange vs original Flexible Group Key Exchange of [ACMP10]===<br />
Although in higher level view of (n+1)sec we generalized the process of key exchange using ''GroupEnc''/''GroupDec'' abstraction, at lower level our choice of primitive for this functions make the group key computation processes of ''(n+1)sec'' and the original key exchange algorithm the same. Hence, the steps marked pink in Algorithm 1, only differ in from [ACMP10] but not in result.<br />
<br />
(n+1)run a deniable mutual authentication protocol along side with the key exchange protocol, this results in communicating extra key confirmation data along side of other data exchanged during the course of running the protocol. As we will show in the proof, these data has effect on the usual run of the algorithm.<br />
<br />
The only step that ''(n+1)sec'' runs differently compare to the original algorithm (beside generating extra data), is computation of mutual secret, between <math>U_i</math> and <math>U_j</math>. In original, algorithm it is simply <math>g^{x_i}{x_j}</math>. In ''(n+1)sec'', it is the triple DH secret <math>H({y_j}^{LSK_{U_i}},LPK_{U_j}^{x_i},y_j^{x_i})</math>. We will prove that this change does not compromise any of the protocol proprieties.<br />
<br />
The main difference between the two key exchange algorithms is in the key used for signature. In original algorithm, parties use their long term private key to sign their contribution, while in ''(n+1)sec'' they use their ephemeral keys. However, because the ephemeral keys has been authenticated before used for verification, we prove that the authenticity of signatures in both algorithms are equivalent under CDH assumption.<br />
<br />
==VIII.2 Chatroom Setup==<br />
<br />
In almost any practical case, participants join the chat sequentially. It is assumed that multiple participants cannot join simultaneously. For the sake of efficiency one can adjust the implementation to have a threshold time to wait and thus start a chat with more participants. However, this makes the implementation significantly more complicated without any evident efficiency benefit.<br />
<br />
Therefore, our assumption is that a secure chat is always set up when a participant starts the chat room. Additional participants would be added sequentially using Algorithm [[#VIII.3_Joining|VIII.3]], as they enter the chat. Algorithm [[#Chatroom_setup|1]] describes the chat room setup protocol.<br />
<br />
'''Algorithm 2'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right"|Generate ephemeral DH private key of the room initiator<br />
|align="center"|<math> x_i \leftarrow [0, order(g)]</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"|Generate DH key for BD, Triple DH and Signature<br />
|align="center"|<math>y_i \leftarrow g^{x_i}</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Set participant list<br />
|align="center"|<math>plist \leftarrow [U_i]</math><br />
|align="center"|Computation<br />
|}<br />
<br />
=== VIII.3 Join ===<br />
<br />
Joining a chat involves two different procedures: the Join procedure, described in Algorithm [[''(n+1)sec''#Join|2]], which runs on the new participant’s instance, and an Accept New Participant Procedure, described in Algorithm [[''(n+1)sec''#Protocol_for_other_participants_already_in_the_chat_to_accept_the_newcomer|3]], which runs on the clients of participants that are already in the chat.<br />
<br />
When a new participant <math>U_{n+1}</math> joins the chat, current participants can still use their established authenticated ephemeral public key (to derive the <math>sessionKey_{new}</math> and as their signature verification key). Confidentiality of <math>sessionKey_{old}</math> is guarded against the new participant by Diffie-Hellman key shares hashed alongside the session id (which is dependent on the list of participants). The new participant cannot combine the old and new shares to recover <math>sessionKey_{old}</math>. The fact that old participants do not need to compute new ephemeral keys (and re-verify their ephemeral identities) decreases the computational complexity of the protocol.<br />
<br />
The new participant needs to authenticate everybody already in the room and hand them their ephemeral key. All the parties already in the room only need to authenticate the new participant and need to send to them their ephemeral DH key. These procedures are described in Algorithm 3 and 4. After initial authentication step, all parties follow the same procedure to initiate a new session following Algorithm 5.<br />
<br />
==== Authentication Step for new Joining party====<br />
<br />
'''Algorithm 3'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right"|Generate ephemeral DH private key<br />
|align="center"|<math> x_i \leftarrow [0, order(g)]</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"|Generate DH key for BD, Triple DH and Signature<br />
|align="center"|<math>y_i \leftarrow g^{x_i}</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"|Broadcast User identity and the DH key<br />
|align="center"|<math>(U_i, y_i)</math><br />
|align="center"|Broadcast<br />
|-<br />
|align="right"| Receive other users' id/key<br />
|align="center"|<math>plist_i|klist_i \leftarrow (U_1|y_1|\dots|U_n|y_n)\cup(U_i,y_i)</math><br />
|align="center"|Receive<br />
|-<br />
|align="right"|Generate Triple Diffie-Hellman P2P keys<br />
|align="center"|<math>k_{i,j} \leftarrow H({y_j}^{LSK_{U_i}},LPK{U_j}^{x_i},y_j^{x_i})</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"|Generate key confirmations<br />
|align="center"|<math>kc_i \leftarrow ((U_1,H(k_{i,1}, U_1)),\dots,(U_n,H(k_{i,n}, U_n)))</math><br />
|align="center"|Computation<br />
|}<br />
<br />
After this step joining user will proceed to "initiate new session" by Algorithm 5.<br />
<br />
====Authentication Step for parties in the room====<br />
For other participants to a accept a new participant only, the authentication step is different. After current participants authenticate the new user, they proceed to update session.<br />
<br />
'''Algorithm 4'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right"| broadcast all user's identities <br />
|align="center"|<math> (U_1|y_1|\dots|U_n|y_n) </math><br />
|align="center"|Broadcast<br />
|-<br />
|align="right"| Receive other users' id/key and update participant list<br />
|align="center"|<math>(plist_i|klist_i) \cup (U_j|y_j)</math><br />
|align="center"|Receive<br />
|-<br />
|align="right"|Generate Triple Diffie-Hellman P2P key for the new participant<br />
|align="center"|<math>k_{i,j} \leftarrow H({y_j}^{LSK_{U_i}},LP_{U_j}^{x_i},y_j^{x_i})</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"|Generate key confirmations<br />
|align="center"|<math>kc_{i,j}\leftarrow (U_i,H(k_{i,j}, U_i)) </math><br />
|align="center"|Computation<br />
|}<br />
<br />
After this step users will proceed to "initiate new session" using Algorithm 5.<br />
<br />
==== Initiate new session ====<br />
<br />
'''Algorithm 5'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right"|Compute Session Id<br />
|align="center"|<math>sid_i \leftarrow H(U_1|y_1|\dots|U_n|y_n)</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Cancel any pending request for establishing a session with the same Id<br />
|align="center"|AxeNewSessionRequestTimer<math>(sid_i)</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"|Generate secret shares<br />
|align="center"|<math>z'_i \leftarrow (H(k_{i,j}, sid_i) \, \textrm{for} \, j \neq i \, \textrm{and} \, j \in \{1,\dots,n\})</math><br />
|align="center"|Computation<br />
|-<br />
|align="right" |Encrypt shares<br />
|align="center"|<math>z_i \leftarrow GroupEnc(k_{i,j} \, \textrm{for} \, j \neq i \, \textrm{and} \, j \in \{1,\dots,n\}, z')</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"|Sign identity, shares<br />
|align="center"|<math>\sigma_i \leftarrow Sign_{x_i}(U_i, z_i, sid)</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"|Broadcast key shares and confirmation (if any)<br />
|align="center"|<math>(U_i, z_i, \sigma_i, kc_i)</math><br />
|align="center"|Broadcast<br />
|-<br />
|align="right"| Receive other user(s)' key shares and confirmation of unauthenticated users or Time out<br />
|align="center"|Wait to Receive (<math>U_j|z_j,\sigma_1,kc_{ji}) </math> for <math> U_j</math> unauthenticated or Timeout by(2<math>\times</math>BROADCAST_LATENCY+INTERACTION_GRACE_INTERVAL, Drop inactive users, queue a new session request)<br />
|align="center"|Receive<br />
|-<br />
|align="right"|Check the validity of key confirmation of unauthenticated users<br />
|align="center"|<math>kc_j[U_i] \stackrel{?}{=} H(k_{i,j}, U_i)</math> for unauthenticated <math> U_j</math> <br />
|align="center"|Computation<br />
|-<br />
|align="right"|Check signatures<br />
|align="center"|<math>Verify_{y_i}(\sigma_j)</math> for ''j'' in {1,...,''n''}<br />
|align="center"|Computation<br />
|-<br />
|align="right"|Check Session Ids<br />
|align="center"|<math>sid_j \stackrel{?}{=} sid_i \; \forall j \neq i</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Generate session key<br />
|align="center"|<math>sk_{i} \leftarrow H(GroupDec(k_{i,l} \forall l, z_j ) \forall j, sid_i)=H(z'_1, \dots, z'_n, sid_i)</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Broadcast session confirmation<br />
|align="center"|{{Font color|black|yellow|<math>(sc_{i} \leftarrow H(sk_i,U_i), sigma_i \leftarrow Sign_{x_i}(sc_{i}))</math>}}<br />
|align="center"|Broadcast<br />
|-<br />
|align="right"|Check the validity of session confirmation<br />
|align="center"|{{Font color|black|yellow|<math>H(sk_{i},U_j) \stackrel{?}{=} sc_j \; \forall j \neq i</math>}}<br />
|align="center"|Receive<br />
|-<br />
|align="right"|Check signatures<br />
|align="center"|{{Font color|black|yellow|<math>Verify_{y_j}(\sigma_j) \; \forall j \neq i</math>}}<br />
|align="center"|Computation<br />
|-<br />
|align="right"| Initiate the TranscriptChain<br />
|align="center"|<math>TrascriptChain^S_i[0] \leftarrow (sk^S_i, sid_i)</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Initiate the last_sender_seq_num array<br />
|align="center"|<math>last\_sender\_seq\_num \leftarrow (0,...,0)</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Initiate the own_seq_num to 0<br />
|align="center"|<math>own\_seq\_num \leftarrow 0 </math><br />
|align="center"|Computation<br />
|}<br />
<br />
==== Sending and receiving messages while joining is in progress ====<br />
<br />
In situations where a prolonged joining process (due to connection problems or malicious activities) has an adverse effect on the user experience, it might be desirable to enable that joining users can communicate with the parties in the room, while maintaining minimum assurances of authenticity, confidentiality, forward secrecy, as well as consistency only among participants.<br />
<br />
Consistency aspects of ''(n+1)sec'', both for the room view (''plist'') and for the transcript, are reached through group agreement. However, there are times when group agreement may be hard or impossible to reach either due to latency in a single participant's connection or due to a single participant broadcasting incorrect confirmation data (such as wrong ''plist'', ''sid'', key share, etc).<br />
<br />
We offer an extension to the ''(n+1)sec'' protocol to tackle this problem during the joining process. When a new participant joins the room, they send their DH key shares to the other participants. The other participants send their ephemeral key in return. They then send their key confirmation and key share. If this extension is to be considered, as soon as each user receives a key confirmation from another user, who is not currently part of the session, ''(n+1)sec'' displays a message highlighting the fact that although the user is not part of the session part of the conversation (from users' who confirmed the new user's identity) is being shared with them (through P2P encryption using the key derived from DH Key). The protocol, however, does not honour their input in the consistency check until a new session including the new user is set up. Each client can decide whether to disable this option.<br />
<br />
The user remains in the list of those not part of the current session, but receives the session messages until a new session is set up. Similarly, when a user receives a message from a user who is not part of the session, ''(n+1)sec'' will decrypt the message and display it with a disclaimer that the user is not yet part of the session and that some participants may not receive the same message.<br />
<br />
This is less secure model in which a room is a forwardly secure authenticated communication channel while a session is a subset of the room, which additionally offers a consistent view of the room and consistent messages among participants. The detail of the process is depicted in Secthoin VIII.5<br />
<br />
===VIII.4 Leave===<br />
Leaving a chatroom involves a message from a leaving party indicating its intention to leave which, as with all other messages, contains the hash of TranscriptChain and one procedure for those who are staying in the chatroom (Procedure Farewell) which is described in Table [[''(n+1)sec''#Leave]]. <br />
<br />
====Farewell====<br />
<br />
Run by exiting user.<br />
<br />
'''Algorithm 6'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right"| Send farewell message<br />
|align="center"|Send("Leaving!")<br />
|align="center"|Broadcast<br />
|-<br />
|align="right"| Wait to receive hashes of TranscriptChain or Timeout<br />
|align="center"|Wait to Receive() or Timeout by((2 <math>\times</math>BROADCAST_LATENCY)+INTERACTION_GRACE_INTERVAL)<br />
|align="center"|Receive<br />
|}<br />
<br />
====Shrink====<br />
<br />
When the remaining participants receive the farewell message they need to reply with the Hash of TranscriptChain of the last message seen by the leaving user. They also need to re-run the one round key update algorithm. However, they only need a notice from the server that the user is leaving to initiate a subsession excluding the leaving user. <br />
<br />
Additionally, failure to receive a heartbeat from a user will result in executing Algorithm [[''(n+1)sec''#Shrink]] excluding users who did not update their key.<br />
<br />
'''Algorithm 7'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right"| Send Hash of TranscriptChain of last message seen by leaving user<br />
|align="center"|Send(<math>H(TranscriptChain^S_i[Parent(m_{farewell})])</math>)<br />
|align="center"|Broadcast<br />
|-<br />
|align="right"| Remove leaving user's id/key and update participant list<br />
|align="center"|<math>(plist_i|klist_i) \backslash (U_j|y_j)</math><br />
|align="center"|Computation<br />
|}<br />
<br />
Users will proceed to "initiate new session" steps.<br />
<br />
=== VIII.5 Secure Send and Receive ===<br />
<br />
After the session key is established, participants will use Algorithms [[''(n+1)sec''#Send|5]] and [[''(n+1)sec''#Receive|6]] to communicate securely.<br />
<br />
On Send, the protocol checks the status of the new ephemeral Diffie-Hellman and key share using messages it receives from participants. It (re)sends any missing pieces. It also informs other participants which part of the key share has been received by the participant. This information is needed in order to enforce in-session forward secrecy. The metadata flag indicates if the message being sent only contains meta data (e.g. heartbeat) or actual user communication.<br />
<br />
On Receive, the protocol updates who has seen which pieces of the key shares. The protocol also generates a new group key if the new key shares have been received from all participants. Those who have not updated their key shares eventually time out via their heartbeat interval.<br />
<br />
====Send====<br />
<br />
'''Algorithm 8'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right" | prepend session id and sender id<br />
|align="center"|<math> m \leftarrow (sid, U_i, m) </math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Generate new DH Key or new secret share if needed and append<br />
|align="center"|<math> m \leftarrow (m,s) </math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Increment own sequence number<br />
|align="center"|<math> own\_seq\_num \leftarrow own\_seq\_num+1 </math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Append the hash of the TranscriptChain, up to the parent of the message being sent<br />
|align="center"|<math> m \leftarrow </math> (''m'', <math>H(H(parent(m)), H(TransciptChain^S_i[parent(m)-1]))</math>, <math>parent\_id(m)</math>, <math>own\_seq\_num</math>)<br />
|align="center"|Computation<br />
|-<br />
|align="right" |Generate a random nonce and append to the message<br />
|align="center"|<math> m \leftarrow (m, rand(128bit)) </math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Sign the message and append the signature<br />
|align="center"|<math> m \leftarrow (m, Sign_{x_i}(m))</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"|Encrypt<br />
|align="center"|<math>e \leftarrow Enc_{k_{sid}}(m)</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Broadcast the message<br />
|align="center"|<math>(sid_i, e)</math><br />
|align="center"|Broadcast<br />
|-<br />
|align="right"|Reset Heartbeat timeout timer<br />
|align="center"|ResetHeartbeatTimer()<br />
|align="center"|Computation<br />
|-<br />
|align="right"|Set ACK timeout timer if the message has user content<br />
|align="center"|<math>meta\_only \stackrel{?}=</math> False then ResetHeartbeatTimer()<br />
|align="center"|Computation<br />
|}<br />
<br />
====Receive====<br />
<br />
'''Algorithm 9'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right"| Decrypt message<br />
|align="center"|<math> sid_{rec}, sender\_id, m, s, h, parent\_id, sender\_seq\_num, sigma \leftarrow Dec_k(m) </math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Check signature<br />
|align="center"|<math> Verify_{sender\_id}(m,\sigma) </math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Compute message sequence number<br />
|align="center"|<math> seqnum(m) \leftarrow </math> ComputeSeqNum(''m'')<br />
|align="center"|Computation<br />
|-<br />
|align="right"| Verify session id and transcript consistency and sender sequence number, issue a warning in case of failure<br />
|align="center"|<math> sid_i \stackrel{?}{=} sid_{rec} \; </math> and <math> \; h \stackrel{?}{=} H(H(parent(m)), H(TranscriptChain^S_i[parent(m)-1])) </math> and <math> sender\_seq\_num \stackrel{?}{>} last\_own\_seq\_nums[sender\_id] </math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Update TranscriptChain if possible<br />
|align="center"|<math> TranscriptChain^S_i[seqnum(m)] = (H(m), H(TranscriptChain^S_i[seqnum(m)-1])) </math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Update sender sequence number record<br />
|align="center"|<math>last\_own\_seq\_nums[sender\_id] \leftarrow sender\_seq\_num </math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Update sender's ephemeral key or share secret<br />
|align="center"|<math>y_j \leftarrow s \; \textrm { or } \; z_{j} \leftarrow s</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| If all users' share are received, generate session key<br />
|align="center"|<math>sk_{i} \leftarrow H(GroupDec(k_{i,j}, z_j \; \forall j),sid_i, U_j) \; \forall j \neq i</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Update ack timeout timer<br />
|align="center"|AxeAckTimeoutTimer<math>(parent(m),sender_i)</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Update rekey timeout timer<br />
|align="center"| ResetRekeyTimeOut(<math>sender_i</math>)<br />
|align="center"|Computation<br />
|-<br />
|align="right"| If the message has content set up ACK timer<br />
|align="center"|<math>meta\_only \stackrel{?}= True</math> then <math>SetACKTimer(m)</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| return m<br />
|align="center"|If <math>meta\_only \stackrel{?}{=} False</math> then return ''m''<br />
|align="center"| Computation<br />
|}<br />
<br />
==== Out of Session Send and Receive ====<br />
Due to nature of the key exchange algorithm, (n+1)sec support confidential P2P communication. This in particular enables the user to share the conversation with joining user(s) who confirmed their identity to the user but have not established a session yet. It is worth mentioning that every session keeps a ''list future sessions to transition to'' this is equivalent to the list of ''confirmed but yet to join users''. If the extension discussed in section VIII.3 is enabled it will make use of this list to implement the following changes:<br />
* When a user send a message ''Extended Send'' is invoked instead, it sends the message to the session using ''Send'' but also to the prospective participants, using ''P2P Send''.<br />
* When a message is received, ''Extended Receive'' is called which check if the user has the correct key to decrypt the message. If the message is encrypted by session key and user has the session key then it calls the normal receive. If the message is encrypted by a p2p key that the user share, it calls ''P2P Receive''. Otherwise, it simply ignores the message.<br />
<br />
'''Algorithm 9.1 Extended Send'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right" | If we are part of a session id in the room call ''Send''<br />
|align="center"| Send<br />
|align="center"| Broadcast<br />
|-<br />
|align="right"| For all confirmed users not in session call ''P2P Send''<br />
|align="center"| P2P Send<br />
|align="center"|Broadcast<br />
|}<br />
<br />
'''Algorithm 9.2 Extended Receive'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right" | If ''m'' has session id call ''Receive''<br />
|align="center"| if ''m'' has ''sid'' then Receive<br />
|align="center"| Computation<br />
|-<br />
|align="right"| If ''m'' has key id, call ''P2P Receive''<br />
|align="center"| P2P Send<br />
|align="center"|Computation<br />
|}<br />
<br />
'''Algorithm 9.3 P2P Send'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right" | Prepend key id and sender id<br />
|align="center"|<math> m \leftarrow (key\_id, U_i, m) </math><br />
|align="center"|Computation<br />
|-<br />
|align="right" |Generate a random nonce and append to the message<br />
|align="center"|<math> m \leftarrow (m, rand(128bit)) </math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Sign the message and append the signature<br />
|align="center"|<math> m \leftarrow (m, Sign_{x_i}(m))</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"|Encrypt<br />
|align="center"|<math>e \leftarrow Enc_{k_{key\_id}}(m)</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Broadcast the message<br />
|align="center"|<math>(key\_id, e)</math><br />
|align="center"|Broadcast<br />
|}<br />
<br />
'''Algorithm 9.4 P2P Receive'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right"| Decrypt message<br />
|align="center"|<math> key_{id}, sender\_id, m, sigma \leftarrow Dec_{k_{key\_id}}(m) </math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Check signature<br />
|align="center"|<math> Verify_{sender\_id}(m,\sigma) </math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| return m<br />
|align="center"|return ''m''<br />
|align="center"|Computation<br />
|}<br />
<br />
===VIII.6 Reaching Consistency ===<br />
<br />
The protocol provisions two procedures to reach consistency in different cases: (a) reaching consistency for arbitrary messages during the course of a conversation, and (b) reaching consistency when an instance <math>\Pi^S_i</math> leaves. Case (b) may be viewed as a special instance of case (a) plus the additional premise that <math>\Pi^S_i</math> must reach consistency as soon as possible (because they want to leave), and that they don't care about reaching consistency for any subsequent messages that they might receive after their final "farewell" message.<br />
<br />
Reaching consistency for arbitrary messages during the course of a conversation:<br />
<br />
'''Algorithm 10'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right"| Receive ''m'' with parent ''p'' from <math>\Pi^S_j</math><br />
|align="center"|<math> m \leftarrow seqnum(M), p \leftarrow parentnum(m)</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Compare hash of TranscriptChain_j[p] with own value of it, issue a warning if it fails.<br />
|align="center"|<math>H(TranscriptChain^S_j[p]) \stackrel{?}{=} H(TranscriptChain^S_i[p])</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Compute TranscriptChain^S_i[m] <br />
|align="center"|<math>plist \leftarrow [U_i]</math><br />
|align="center"|Computation<br />
|}<br />
<br />
Case '''(b)''': when an instance <math>\Pi^S_i</math> wants to part, they send a "farewell" message ''m'' which contains <math>Hash(TranscriptChain^S_i[p])</math>.<br />
* Everyone should include <math>Hash(TranscriptChain_j[p])</math> in their re-key message<br />
* When ''<math>\Pi^S_i</math>'' reaches mutual consistency for p may leave or otherwise (if received hashes and their owns are non-matching) shows a warning.<br />
** <math>\Pi^S_i</math> won't have a chance to reach consistency for the messages receives after ''p''<br />
<br />
===VIII.7 In-session Forward Secrecy===<br />
To ensure forward secrecy in long living chat sessions, ''(n+1)sec'' provides a session key update throughout the session. Each message sent to the session by each participant contains meta data described in [[#VIII.5.1 (n+1)sec Message Structure]]. Prior to sending any message, ''(n+1)sec'' determines the content of meta data, and piggy backs to that message according to the following algorithm:<br />
<br />
'''Algorithm 10.1 Compute meta data'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right"| Initiate meta data with current state of knowledge of new ephemeral keys and secret shares<br />
|align="center"|<math> meta\_data \leftarrow ustate_i[j]</math> for all ''j'' in {1,...''n}<br />
|align="center"|Computation<br />
|-<br />
|align="right"| Include the new ephemeral key if participant <math>U_j</math> has not receive it<br />
|align="center"|If <math>ustate_i[j] \stackrel{?}{=} 0</math> ''meta_data'' \leftarrow <math>y_{i_{new}}</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| If (all) participants have sent their ephemeral keys compute the shared secret<br />
|align="center"|If <math>ustate_{j}[i] \stackrel{?}{=} 1</math> for all ''j''<br />
in {1,...''n}, then <math> meta\_data \leftarrow (meta\_data, GroupEnc(k_{i_j} \, \textrm{for} \, j \neq i \, \textrm{and} \, j \in \{1,\dots,n\}, z'))</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Return meta data<br />
|align="center"|return ''meta_data''<br />
|align="center"|Computation<br />
|}<br />
<br />
===VIII.8 Heartbeat and Timeout ===<br />
<br />
Heartbeat is an empty message which contains only meta data. The meta data consists of information used to compute a new key and the most updated hash of transcript chain.<br />
<br />
The protocol sends a heart beat only if the user has not sent any messages for a specific period of time.<br />
<br />
The heartbeat is necessary to ensure three properties:<br />
<br />
- Periodic transcript consistency check.<br />
- In session forward secrecy.<br />
- Freshness<br />
<br />
To achieve these goals three time out periods are defined when heart beat sending is required. Additionally, we define an interval to model the latency in the underlying transport. These should be defined to cover common cases (e.g. 95th-percentile):<br />
<br />
* ACK_GRACE_INTERVAL: When <math>\Pi^S_i</math> a receives a non-empty message it needs to inform the group about the transcript update no later than ACK_GRACE_INTERVAL time. Therefore if <math>\Pi^S_i</math> f <math>U_i</math> does not send a message ACK_GRACE_INTERVAL seconds after receiving a non empty message,<math>\Pi^S_i</math> will send a heartbeat.<br />
<br />
* REKEY_GRACE_INTERVAL, to ensure in session forward secrecy, the protocol requires that each <math>U_i</math> updates their DH ephemeral key as well as group key. After a session is established or it was rekeyed, each <math>\Pi^S_i</math> needs to send its new DH ephemeral key no later than REKEY_GRACE_INTERVAL. Therefore if <math>\Pi^S_i</math> has not sent any message by that<br />
period of time, it issues an empty message. Similarly after receiving all ephemeral keys from all participants, <math>\Pi^S_i</math> needs to send its secret for computation of new key no later than REKEY_GRACE_INTERVAL.<br />
<br />
* INTERACTION_GRACE_INTERVAL, to ensure establishment of a session in timely manner, when immediate contribution of participants is required (for example sending key confirmation, contribution to the session secret), this values indicate that how long an active participants should wait till it decide to drop the non-contributing inactive participants from the participant list.<br />
<br />
* BROADCAST_LATENCY: Modelling the amount of time which a message takes to reach the server and broadcast to the other clients. It should be based on the transport considered.<br />
<br />
==== Failure to heartbeat and inactivity timers ====<br />
<br />
Whenever, a message ''m'' is received a timer of (2*BROADCAST_LATENCY)+ACK_GRACE_INTERVAL) period is set. If the <math>H(Transcript_j[m'])</math> for a <math>m' \ge m</math> is received from all participants, the timer is cancelled. Otherwise at the time out, the protocol issues a local UI warning and cancel the warning if/when such a hash is received and is consistence among participants.<br />
<br />
When a new session key is computed as well as when <math>\Pi^S_i</math> receives new ephemeral DH values from all users, a timer of (2*BROADCAST_LATENCY)+REKEY_GRACE_INTERVAL period is set. It is cancelled when all user contributions are received (ephemeral keys or session key secrets). Otherwise, the <math>\Pi^S_i</math> excludes users who failed to contribute from the <math>plist</math> exclude those users from the plist and call '''initiate new session'''. This measure is taken to ensure that users do not block in-session forward secrecy due to loss of connection or being under attack.<br />
<br />
==== Timing out during an interactive session ====<br />
<br />
''(n+1)sec'' by design assumes the participants are trusted in being commited to the goal fo creating a secure chatroom. In this sense, ''(n+1)sec'' provide little defens against party which trying to sabotage a room by mounting various denial of service approaches. However, there are situation where a party is genuinely affected (by external adversary) or by connection problem. Under such assumption, situations we expect that all other parties, reach a consensus, that a participant has connectivity problem and agree on leave them out of the room.<br />
<br />
Timeout sub protocol is designed to deal with such a situation. When a new session is requested (for join, leave, etc) each participant wait for (2*BROADCAST_LATENCY)+INTERACTION_GRACE_INTERVAL, they omit non-participating participants from the plist, and wait for PLIST_UPDATE_GRACE_INTERVAL. so other participants also reach to the same conclusion and updates their plists, then they initiate a new session.<br />
<br />
==== Drop inactive users, queue a new session request ====<br />
'''Algorithm 10.XX'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right"| Drop inactive users<br />
|align="center"|<math> plist_i \leftarrow plist_i \backslash inactive\_participant\_list</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Recompute Session Id<br />
|align="center"|<math>sid_i \leftarrow H(U_1|y_1|\dots|U_{n_{active}}|y_{n_{active}})</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Set up timer to request a new session<br />
|align="center"|SetTimer(PLIST_UPDATE_GRACE_INTERVAL, initiate new session)<br />
|align="center"|Computation<br />
|}<br />
<br />
When a participant receives a request for initiating new session, it checks their most current view of participant list (the one with eliminated timed out users) and if it matched then they go ahead with initiating the session, otherwise decline halt the request.<br />
<br />
====VIII.9 (n+1)sec Message Dictionary====<br />
<br />
All (n+1)sec messages have the following format<br />
<br />
:o3np1sec:Base64EnocodedMessage<br />
<br />
The Base64EncodedMessage is decoded to sub data fields. There is no delimiter, the fields can be split based on the data size. We use commas (',') only for the purposes of readability in this document. The data types are described as follows.<br />
<br />
Bytes (DTByte):<br />
1 byte unsigned value<br />
Shorts (DTSHort):<br />
2 byte unsigned value, big-endian<br />
Length (DTLength):<br />
4 byte unsigned value, big-endian<br />
HashBlock (DTHash):<br />
32 byte data<br />
Opaque variable-length data (DTOpaque):<br />
4 byte unsigned len, big-endian<br />
len byte data<br />
<br />
All messages have mandatory version and message type fields:<br />
<br />
version (DTShort), message type (DTShort), type-specific part<br />
<br />
"version" is equal to 0001.<br />
<br />
"message type" is chosen from the following list:<br />
UNKNOWN =0x00, //Invalid<br />
JOIN_REQUEST =0x0a, //Session establishement<br />
PARTICIPANTS_INFO =0x0b,<br />
JOINER_AUTH =0x0c,<br />
GROUP_SHARE =0x0d,<br />
SESSION_CONFIRMATION =0x0e, //In session messages<br />
IN_SESSION_MESSAGE =0x10,<br />
P2P_MESSAGE =0x20,<br />
<br />
many messages use "participant id" which is defined as follows:<br />
<br />
participant nickname, participant fingerprint (DTHash)<br />
<br />
participant nickname is a string. Its size can be determined by the length of the participant id - 32. The participant finger print is a 32bit representation of an ed25519 public key.<br />
<br />
"participant info" is defined as<br />
<br />
participant id, ephemeral public key (DTHash), authenticated (DTByte)<br />
<br />
From the point of view of the sender of the message the participant is authenticated if "authenticated" is 1. Unauthenticated if it is 0.<br />
<br />
The following sections will describe the type-specific part for each type of messagee information about the joiner.<br />
<br />
=====Join Request=====<br />
<br />
participant id, ephemeral publick key (DTHash)<br />
<br />
representing the joiner's information. <br />
<br />
=====Participant Info=====<br />
<br />
session id (DTHash), session view (DTOpaque), key_confirmation(DTOpaque), sender's share(DTHash)<br />
<br />
"session view" consists of<br />
<br />
participant0_info (DTOpeque), participant1_info (DTOpeque), ..., partcipantn_info(DTOpeque)<br />
<br />
where "participant0,...,participantn" are all participants in the session (represented by session id).<br />
<br />
"key confirmation" consists of a hash of a triple dh token between the sender and the joining participant and the "participant id" of the joining user.<br />
<br />
the sender's share is computed as described in the algorithm.<br />
<br />
=====Joiner Auth=====<br />
<br />
session id (DTHash), key_confirmation (DTOpeque), signature<br />
<br />
"key confirmation" consists of a hash of a triple dh token between the sender and the joining participant and the "participant id" of the joining user.<br />
<br />
<br />
=====Group Share=====<br />
<br />
session id (DTHash), sender share (DTHash), signature (DTHash)<br />
<br />
=====Session Confirmation=====<br />
<br />
session id (DTHash), session confirmation (DTHash), next session ephemeral key (DTHash)<br />
<br />
"session confirmation" is a hash(Session key|sender nickname), the next session ephemeral key is the 32bit public key that the user is going to use in the next session.<br />
<br />
=====(n+1)sec in session Message Structure=====<br />
<br />
Every (n+1)sec message sent after establishment of a session has the following format:<br />
<br />
:o3np1sec:Base64EnocodedMessage<br />
<br />
The message has the following structure.<br />
<br />
sid (DTHash), Encrypted part of the message, Signature (DTHashx2)<br />
<br />
Encrypted message can be decrypted by the session key<br />
<br />
sender_index (DTLength), own_sender_id (DTLength), parent_id (DTLength), hash of TranscriptChain of the message (DTHash), nonce (DTHash), message load<br />
<br />
"session ID" and the "sender_index" are prepended in part to address concerns of [Da01].<br />
<br />
"own_sender_id" is the sequential id assigned to each message by its sender, used for transcript consistency check.<br />
<br />
"parent_id" is the global sequential id of the last message seen by the sender before sending the message.<br />
<br />
The message also includes the "hash of TranscriptChain" of the parent of the message as "additional authenticated data". <br />
<br />
<math>H(TransciptChain[parent(m)])</math><br />
<br />
Note that we send the entry in the chain indexed by <math>parent(m)</math> rather than <math>m</math>. This is because a hash may only be calculated once the subject is actually received back from the server (i.e. gets a sequence number). This differs from some other concepts of "message ID" that may be calculated locally.<br />
<br />
"nonce" is a random 128 bit value, appended to prevent any possibility of replay or brute force attack.<br />
<br />
"message load" is a multi-field message and has the following structure:<br />
sub_message_type(DTShort)<br />
sub_message(DTOpeque) [Optional]<br />
<br />
current sub message types are:<br />
USER_MESSAGE: 0001<br />
follewed by the plain text typed by user and handled to (n+1)sec by the chat client(DTOpaque)<br />
LEAVE_MESSAGE 0002<br />
followed by nothing.<br />
<br />
If there is no message load, then the message is just an ack, acknowledging receipt of other messages.<br />
<br />
====(n+1)sec P2P Message Structure====<br />
<br />
Every p2p (n+1)sec message sent after exchange of the ephemeral public keys has the following format.<br />
<br />
:o3np1sec:Base64EnocodedMessage<br />
<br />
The Base64EncodedMessage is decoded as:<br />
<br />
version (DTShort), sid (DTHash), Encrypted part of the message, Signature (DTHashx2)<br />
keyid, Encrypted part of the message, Signature<br />
<br />
Encrypted message can be decrypted by the p2p key and has the following structure<br />
<br />
Signed Message consists of following parts<br />
<br />
keyid, sender id, received id, nonce, User message, <br />
<br />
The "Key ID" and the "sender ID" are prepended in part to address concerns of [Da02]. The nonce is a random 128 bit value, appended to prevent any possibility of replay or brute force attack.<br />
<br />
User message is the plain text typed by user and handled to (n+1)sec by the chat client.<br />
<br />
====VIII.10 (n+1)sec Message Handling====<br />
<br />
This section explains the rule - based on which - (n+1)sec governs the order when multiple participants try to join or leave a session simultaneously. Every participant in a chat room has either the status of a "joiner" or a "participant" of a confirmed session exclusively. Based on the user status and the message received, a specific subprotocol needs to be run by the user which is explained in the following sections.<br />
<br />
If the message has a session id of a session that the user is part of, then message handling is governed by the finite state machine table described below. Otherwise, the messages should be handled as follows:<br />
<br />
=====Joiner====<br />
<br />
The Joiner will ignores all messages without session id.<br />
<br />
<br />
If the message has a session id - of wich the joiner is not a party - the joiner will react as follows:<br />
<br />
* ''Participant Info'': the joiner begins a session by appending itself to the list.<br />
* ''Session Confirmation'': re-try to join.<br />
<br />
=====Confirmed Participant======<br />
<br />
If the received message does not have a session id, then it is a JOIN_REQUEST and can be handled by the current session's finite state machine.<br />
<br />
If the received message has a session id, but the confirmed participant is not part of the session then the participant will ignore the message. (The participant is - in this case - leaving the session).<br />
<br />
=====Finite State Table=====<br />
{| class="wikitable"<br />
|-<br />
! State/Message !! JOIN_REQUEST !! PARTICIPANTS_INFO !! !! JOINER_AUTH !! GROUP_SHARE !! SESSION_CONFIRMATION !! IN_SESSION_MESSAGE !!<br />
|-<br />
| JOIN_REQUESTED || || auth_and_reshare || || || confirm_or_resession || ||<br />
|-<br />
| RE_SHARED || || confirm_auth_add_update_share_repo || confirm_auth_add_update_share_repo || || ||<br />
|-<br />
| GROUP_KEY_GENERATED || || || || || confirm_auth_add_update_share_repo || ||<br />
|-<br />
| IN_SESSION || init_a_session_with_new_user || || || || mark_confirmed_and_may_move_session || receive ||<br />
|-<br />
| DEAD || || || || || mark_confirmed_and_may_move_session || receive ||<br />
|}<br />
<br />
=====Session transmission=====<br />
<br />
The session changes when all users have confirmed a session. When a user leaves while another user trys to join, the leave protocol will take priority and a new participant info message is sent to the joining user after all leaving users have left. When multiple users are joining, when the confirmed participant receives the first joiner auth, it will halt the protocol for other joining users. When the session is confirmed, the new participant info list will be sent to the remaining joining users.<br />
<br />
= '''IX Cryptographic Primitives''' =<br />
<br />
==IX.1 Hash Function==<br />
SHA256 is being used as the hash function and the random oracle. SHA256 provides a sufficiently secure hash primitive for the level of security provided by ''(n+1)sec'' and is widely implemented.<br />
<br />
==IX.2 Message Origin Authentication ==<br />
ED25519 has been chosen as the signature primitive due to its efficiency and more secure implementability over other elliptic-curve digital signature algorithms. [Be11]<br />
<br />
==IX.3 Message Encryption ==<br />
We are using AES-256 in Galois/Counter Mode (GCM) with a shared group key for message encryption, we are following the suggestion by the original OTR protocol of using counter mode. However, unlike OTR, <math>(n+1)sec</math> does not support per message forgeability (although the whole transcript is forgeable), it is not prohibitive to use the same key for encryption and authentication.<br />
<br />
The added authentication, spares P@P send and receive routines from using digital signature.<br />
<br />
With GCM mode, the authenticated encryption is generically secure by the result (and assumptions) of [Kr00].<br />
<br />
==IX.4 GroupEnc and GroupDec Functions ==<br />
The ''GroupEnc'' and ''GroupDec'' functions defined in Section VIII.1, facilitate the collective generation of a secret(s) shared by the group. Here we mention two examples of such functions, and specify the functions for ''(n+1)sec' protocol:<br />
<br />
* '''Naive peer-to-peer GroupEnc/Dec''':<br />
The simplest path to design such primitives is to encrypt <math>z'_i</math> using the p2p encryption secret between each pair of participants:<br />
<br />
<math>GroupEnc((k_{i,1},...,k_{i,n}),z'_i) := (E_{k_{i,1}}(z'_i),...,E_{k_{i,n}}(z'_i))</math><br />
<math>GroupDec((k_{i,1},...,k_{i,n}),(z_1,...,z_n)) := (D_{k_{i,1}}(z_1[i]),...,D_{k_{i,n}}(z_n[i]))</math><br />
<br />
* '''Linear System based GroupEnc/Dec''':<br />
<br />
Another possibility is that each user generates k linear equations of l variables such if the system of <math>k.n</math> equations has m independent equations then m < l. The remaining equations should be generated using the mutual secrets <math>k_{i,j}</math>.<br />
<br />
An example of such a system is used by [BuDe95]. In which <math>k = 1, l = n+1, m = n</math> as follows:<br />
<br />
Each user U_i generate equations (k_{i,i-1}+k_{i,i+1}=a_i) so the system for n equation <math>n+1</math> variable will be:<br />
<br />
<math>\matrix{ x_1 + x_2 = a_1 \\<br />
x_2+x_3= a_2 \\<br />
\vdots \\<br />
x_n + x_{n-1} = a_n \\}</math><br />
<br />
Then each participant adds the equation of <math>x_i = k_{i,i+1}</math> to the system and solves the derived system of <math>n+1</math>-equation <math>n+1</math>-unknown to recover the secrets.<br />
<br />
in such a system:<br />
<br />
<math>z'_i := k_{i,i-1} = k{i-1,i}</math><br />
<math>GroupEnc((k_{i,1},...,k_{i,n}),z'_i, z'_{i+1}) := z'_{i} \oplus z'_{i+1}</math><br />
<br />
''(n+1)sec'' uses the modification of the primitive suggested in [ACMP10] to guard the confidentiality of the p2p and the subgroup keys:<br />
<br />
<math><br />
z'_i := H(k_{i,i-1}, sid_i)<br />
</math><br />
<br />
While the naive peer to peer primitive is easier to understand and analyse, the second system gives the flexibility for the implementor to decide the trade off between the amount of data (number of equations) vs. the redundancy in the system (if some equations are not delivered the user can still compute a subset of secrets).<br />
<br />
= X. Next Steps =<br />
<span style="font-size:200%">T</span>his document is the first public draft of the ''(n+1)sec'' protocol. We are genuinely hoping to receive a lot of feedback and review on this work and have chosen the wiki format to support [[Talk:Nsec|Discussion]]. Ongoing tasks for the team include mathematical proofs of resistance to the adversarial model presented herein as well as technical implementation details. This is currently scheduled for the end of December, 2014. The [https://github.com/equalitie/np1sec np1sec] software library will be initially implemented in [https://github.com/cryptocat/cryptocat/ Cryptocat] and (with your help) further developed to suit a variety of use-cases in the near future.<br />
<br />
= XI. Acknowledgements =<br />
The eQualit.ie team would like to give special thanks and note to the effort and dedication offered by Trevor Perrin and Ximin Luo to this project. They have been actively involved throughout the year and the result would not have been the same without their contribution. The team would also like to express thanks to Joseph Bonneau for his constructive comment and critisim to improve the protocol and its presentation. George Kadianakis for helping with the security proof and pointing out flaws and attack; Arlo Breault for his work on implementation of the protocol in the [https://github.com/equalitie/np1sec np1sec] software library; David Goulet for valuable advice as well as continued assistance and support offered to the project; Prof. Payman Mohassel for his help and advice on the security model and the proof; Prof. Jermey Clark, Prof. Matthew Green and Frederic Jacobs for their constructive participation in the design debates; Prof. Mark Manulis for suggesting the GKA. eQualit.ie expresses gratitude to Nadim Kobeissi, Cryptocat founder and developer who initiated the project and for sharing his experience and giving advice on secure browser based chat. Last but not least we would like to thank the Open Technology Fund for supporting the project.<br />
<br />
= XII. References =<br />
<br />
<div class="references"><br />
<br />
<HarvardReferences><br />
<br />
[*ACMP10] Michel Abdalla, Céline Chevalier, Mark Manulis, and David Pointcheval. “Flexible Group Key Exchange with on-Demand Computation of Subgroup Keys.” In ''Third African International Conference on Cryptology (AfricaCrypt ’10)'', edited by Dan Bernstein and Tanja Lange, 6055:351–368. LNCS. Stellenbosch, South Africa, 2010: Springer. <br />
<br />
[*Be11] Bernstein, Daniel J.; Duif, Niels; Lange, Tanja; Schwabe, Peter; Yang, Bo-Yin. "High-Speed High-Security Signatures.","CHES","978-3-642-23950-2","http://dblp.uni-trier.de/db/conf/ches/ches2011.html#BernsteinDLSY11". 2011. pages: 124-142","6917","Lecture Notes in Computer Science","Springer".<br />
<br />
[*BS07] Bohli, Jens-Matthias, and Rainer Steinwandt. 2007. “Deniable Group Key Agreement.” In ''VIETCRYPT'', edited by Phong Q. Nguyen, 4341:298–311. Lecture Notes in Computer Science. Springer. http://dblp.uni-trier.de/db/conf/vietcrypt/vietcrypt2006.html#BohliS06.<br />
<br />
[*BVS05] Bohli, Jens-Matthias, Maria Isabel Gonzalez Vasco, and Rainer Steinwandt. 2005. “Secure Group Key Establishment Revisited.” ''IACR Cryptology ePrint Archive'' 2005: 395. http://dblp.uni-trier.de/db/journals/iacr/iacr2005.html#BohliVS05a.<br />
<br />
[*BM] Bonneau, Joseph, and Andrew Morrison. “Finite-State Security Analysis of OTR Version 2.” http://www.jbonneau.com/doc/BM06-OTR_v2_analysis.pdf<br />
<br />
[*BGB04] Borisov, Nikita, Ian Goldberg, and Eric Brewer. 2004. “Off-the-Record Communication, or, Why Not to Use PGP.” In ''Proceedings of the 2004 ACM Workshop on Privacy in the Electronic Society'', 77–84. WPES ’04. New York, NY, USA<br />
<br />
[*BCGNP08] Colin Boyd, Yvonne Cliff, Juan Gonzalez Nieto, and <span>KennethG.</span> Paterson. 2008. “Efficient One-Round Key Exchange in the Standard Model.” In ''Information Security and Privacy'', edited by Yi Mu, Willy Susilo, and Jennifer Seberry, 5107:69–83. Lecture Notes in Computer Science. Springer Berlin Heidelberg.<br />
<br />
[*BoMa10] Boyd, Colin; Mathuria, Anish. "Protocols for Authentication and Key Establishment","3642077161, 9783642077166",2010, Springer Publishing Company, Incorporated, 1st edition<br />
<br />
[*BCP01] Emmanuel Bresson, Olivier Chevassut, and David Pointcheval. 2001. “Provably Authenticated Group Diffie-Hellman Key Exchange - the Dynamic Case.” In ''Advances in Cryptology - Proceedings of ASIACRYPT ’01'', edited by Colin Boyd, 2248:290–309. LNCS. Gold Coast, Australia: Springer. <br />
<br />
[*BCPQ01] Emmanuel Bresson, Olivier Chevassut, David Pointcheval, and Jean-Jacques Quisquater. 2001. “Provably Authenticated Group Diffie-Hellman Key Exchange.” In ''Proceedings of the 8th ACM Conference on Computer and Communications Security (CCS ’01)'', edited by Mike Reiter, 255–264. Philadelphia, Pennsylvania.<br />
<br />
[*CaKr01] Ran Canetti, Hugo Krawczyk. 2001. “Analysis of Key-Exchange Protocols and Their Use for Building Secure Channels” “EUROCRYPT Conference. Lecture Notes in Computer Science”. Edited by Birgit Pfitzmann. <br />
<br />
[*ChMa10] Qingfeng Cheng, Chuangui Ma, "Security Weakness of Flexible Group Key Exchange with On-Demand Computation of Subgroup Keys", CoRR, 2010, http://arxiv.org/abs/1008.1221<br />
<br />
[*Da14] George Danezis, Should Group Key Agreement be Symmetric and Contributory, http://conspicuouschatter.wordpress.com/2014/06/28/should-group-key-agreement-be-symmetric-and-contributory/<br />
<br />
[*Da02] Davis, Don,"Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML.","USENIX Annual Technical Conference, General Track","1-880446-09-X","http://dblp.uni-trier.de/db/conf/usenix/usenix2001g.html#Davis01","2002-09-022001", page 65-78<br />
<br />
[*GUVGC09] Ian Goldberg, Berkant Ustao<span>\</span>uglu, Matthew D. Van Gundy, and Hao Chen. 2009. “Multi-Party Off-the-Record Messaging.” In ''Proceedings of the 16th ACM Conference on Computer and Communications Security'', 358–368. CCS ’09. New York, NY, USA: ACM. <br />
<br />
[*GBN10] M. Choudary Gorantla, Colin Boyd, and Juan Manuel González Nieto. 2010. ''One Round Group Key Exchange with Forward Security in the Standard Model''. http://eprint.iacr.org/2010/083.pdf<br />
<br />
[*GBNM11] M. Choudary Gorantla, Colin Boyd, Juan Manuel González Nieto, and Mark Manulis. 2011. “Modeling Key Compromise Impersonation Attacks on Group Key Exchange Protocols.” 'ACM Trans. Inf. Syst. Secur.<br />
<br />
[*Gun13a] Matthew Van Gundy. April 2013. “[OTR-dev] Improved Deniable Signature Key Exchange for mpOTR.” <br />
http://matt.singlethink.net/projects/mpotr/improved-dske.pdf<br />
<br />
[*Gun13b] Matthew Van Gundy March 2013. “[OTR-dev] Improved Deniable Signature Key Exchange for mpOTR.”<br />
http://lists.cypherpunks.ca/pipermail/otr-dev/2013-March/001676.html.<br />
<br />
[*Kr00], "Krawczyk, Hugo","The order of encryption and authentication for protecting communications (Or: how secure is SSL?), 2001, Published: Cryptology ePrint Archive, Report 2001/045 http://eprint.iacr.org/<br />
<br />
[*KPW13] Hugo Krawczyk and Kenneth G. Paterson, Hoeteck Wee. 2013. “On the Security of the TLS Protocol: A Systematic Analysis” in<br />
''IACR Cryptology ePrint Archive''.<br />
<br />
[*LVH13] Liu, Hong; Vasserman, Eugene Y.; Hopper, Nicholas. "Improved Group Off-the-record Messaging" from the ''Proceedings of the 12th ACM Workshop on Workshop on Privacy in the Electronic Society'', 978-1-4503-2485-4, 'ACM', New York, NY, USA. 2013<br />
<br />
[*Mo13] Marlinspike, Moxie,"Simplifying OTR deniability" blogpost, Open Whispersystems, https://whispersystems.org/blog/simplifying-otr-deniability/<br />
<br />
[*Sys14] Marlinspike, Moxie et al. Whisper Systems. 2014. “TextSecure ProtocolV2.” Accessed March 2. https://github.com/WhisperSystems/TextSecure/wiki/ProtocolV2.<br />
<br />
[*RGK05] Mario Di Raimondo, Rosario Gennaro, and Hugo Krawczyk. 2005. “Secure Off-the-Record Messaging.” In ''WPES'', 81–89. Alexandria, VA, USA. http://dl.acm.org/citation.cfm?doid=1102199.1102216<br />
<br />
[*KiSo00] Song, Boyeon; Kim, Kwangjo, "Two-Pass Authenticated Key Agreement Protocol with Key Confirmation","Progress in Cryptology —INDOCRYPT 2000","978-3-540-41452-0","http://dx.doi.org/10.1007/3-540-44495-5_21","2000"; "237-249",1977 "Lecture Notes in Computer Science",Springer Berlin Heidelber.<br />
<br />
[*Git11] https://github.com/hellais/cryptocat<br />
<br />
</HarvardReferences><br />
<br />
</div><br />
<br />
=Appendices=<br />
<br />
==Appendix A: Asynchronous communication and Forward Secrecy==<br />
<br />
The protocol is primarily targeted to synchronous cases, however, with some modification it can be used for asynchronous cases.<br />
<br />
Provided that the participants are not concerned with authenticating the list of participants (it is OK if Eve impersonates Bob as long as she is unable to read Bob’s messages). Participants can communicate using their pairwise exchanged ephemeral Diffie-Hellman keys until all participants finish the second round of authentication.<br />
<br />
As soon as a deniable handshake has been established among a set of participants any subset of them can communicate and authenticate their messages using the “session key” and their ephemeral signature key.<br />
<br />
The protocol does not enforce explicitly a time limit on renewing the session key shares and can be used for an asynchronous high latency transport after the key establishment state.<br />
<br />
The downside of using a session key for a long time is that a compromised session key will reveal all past communication during that session. This does not pose an imminent threat when the life span of a chat is short. However, in the context of asynchronous high latency transport, it is a more serious concern.<br />
<br />
The protocol requires the participants to pre-emptively update their ephemeral signature/shares and propagate them as part of the messages they are already sending. Subsequently, they also update their key share with their neighbours as soon as the neighbours also propagate their new ephemeral signature keys.<br />
<br />
As the assumption of having a continuous heartbeat might not be realistic in various asynchronous cases, implementations can assume specific deadlines for dropping users who did not communicate their new keys or shares.<br />
<br />
==Appendix B: Other design possibilities==<br />
During the process of designing ''(n+1)sec'' we have considered and debated other design possibilities which we will describe in this section along side our arguments in favour of the choices made.<br />
<br />
===Group Key Scheme vs Broadcast Scheme===<br />
We say a group key scheme (as defined in [[#V._Chat_Session_Model|Section V]]) is correct if all accepted instances of <math>\Pi^S_i</math> end up with the same participant lists <math>plist_i</math> and compute the same session id. <br />
<br />
By contrast, a broadcast scheme refers to a scheme in which each participant is broadcasting a message to a set of participants of their choice from a set of potential participants. Each participant will have its own different <math>plist_i</math> which is able to broadcast as well. See GOTR by [LVH13] For an example of such scheme where each participant chooses there own circle of audiances. <!--In such protocol we define <math>plist_{union} := \cup{i \in {interested participants}} plist_i</math>.--> <br />
<br />
Therefore, in the context of a chat room, broadcasting scheme participants do not have the same view of the room and consequently we cannot compute a unified session id <math>sid</math> based on the list of the participants (as opposed to the group key scheme). In a group key scheme, it is the name of the chat room plus a set of ephemeral keys and the set of ephemeral public keys which uniquely identifies the session. There are advantages and disadvantages to each of these schemes, which we enumerate here:<br />
<br />
# Chat room simulation: A group scheme simulates a normal chat room in the absence of an authentication adversary, where the participants all have the same view of who is in the chat room when they start talking. This is not the case in a broadcasting scheme as participants keep different participant lists. This is in conflict with the security assumptions of the authentication properties from the original proposal for ''(n+1)sec''.<br />
# Consistency: In a group key exchange, the consistency of the participant list (and session id) is provided by the group key exchange protocol. In such a protocol, extra measures need to be taken only to assure the transcript's consistency, i.e. verification of the consistency of delivery and order of messages exchanged between participants. In a broadcast scheme, a new notion needs to be defined and enforced so that a minimum consistency of a conversation can be simulated. For example, as broadcasting to a subset of potential participants is allowed, the notion needs to deal with a situation in which A receives the DH public key of B but wants to send a message to the "room" before it receives the DH key of C.<br />
# Delayed join and leave: In a group scheme, until all participants confirm their identical view of a new participant list (due to a member joining or leaving the room), they need to assume the status quo. This might delay a new participant from joining a chat or, if no further measure is taken, enable a participant to deny join/leave for the whole group. While various mitigation methods are possible against such attacks (all summarized under the umbrella term "Denial of Service" ) they are not included in threat model considered in ''(n+1)sec'' protocol. <br />
<br />
Based on the above differences, we selected a group key scheme for the proposed protocol. This is primarily because room consistency is one of the main security properties desired. However, when it is critical, the sub-protocol described by [[#Sending_and_receiving_messages_ while_joining_is_in_progress|Section VIII.2 Sending and receiving messages while joining is in progress]] allows for communication with users while they are waiting for the join procedure to complete.<br />
<br />
===Participatory vs individually independent computation of group key(s)===<br />
Most AKGE offer some degree of contributiveness in computing the group secret. This roughly means that (at least in the absence of an insider) the group secret is derived using contribution from all members of the group. There has been criticism of the importance of this property such as in [Da14]. In this section we consider briefly the arguments for each side and describe the rational for our choice.<br />
<br />
[[Category: np1sec]]</div>Billhttps://learn.equalit.ie/wiki/Np1secNp1sec2014-12-18T22:31:08Z<p>Bill: /* VIII.6 Reaching Consistency */</p>
<hr />
<div>[[File:Np1sec-web.jpg|frameless|center|(n+1)sec]]<br />
<div class="noautonum">__TOC__</div><br />
{{DISPLAYTITLE:(n+1)sec}}<br />
===Abstract===<br />
<br />
''In this document we present the first public draft of ''(n+1)sec'' - a secure multi-party communication protocol developed by eQualit.ie with support from the [https://www.opentechfund.org/ Open Technology Fund] and [https://crypto.cat/ Cryptocat]. We include the design rationale, choice of security features, adversarial models, schematic and high level specification of sub-protocols. A subsequent document will present security proofs and implementation details.''<br />
<br />
=I. INTRODUCTION=<br />
<br />
<span style="font-size:200%">T</span>he ''(n+1)sec'' project was inspired by [https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html Off-The-Record] messaging protocol and subsequent efforts to explore a multiparty use-case for OTR in [GUVGC09]. ''(n+1)sec'' is currently developed for [https://github.com/cryptocat/cryptocat/wiki/mpOTR-Project-Plan Cryptocat] - a browser based XMPP chat platform and assumes its use-cases. Most importantly, ''(n+1)sec'' allows for secure multi-party key exchange and end-to-end encrypted communications without extensive computational requirements from the client. You can follow and contribute to the implementation of [https://github.com/equalitie/np1sec np1sec] on our Github pages. Future protocol iterations will consider a variety of other real-world use cases and be platform independent. Please use the [[Talk:Np1sec|Discussion]] page to ask questions and leave comments.<br />
<br />
In the following section we summarise relevant publications and describe their influence on this protocol. In [[#III._Design_rationale|Section III]], we describe our approach and choice of security features. In [[#IV._Security_Properties|Section IV]], we review the security properties within this protocol. In [[#V._Chat_Session_Model|Section V]] we give basic mathematical definition needed to model the chat session and security proofs for various security aspects of the protocol. [[#IV._Adversarial_Models|Section VI]] provides formal definitions and references to the adversarial models for each property. In [[#VII._Protocol_High_Level_Design|Section VII]] we describe various parts of the protocol and present choices for each sub protocol. In [[#VIII._''(n+1)sec''_Protocol:_Step_by_Step|Section VIII]], we present each of the ''(n+1)sec'' protocol steps at various stages in schematic and algorithmic format. We present our choice of primitives in [[#iX._Cryptographic_Primitives|Section IX]]. Finally, we define the work that [[#Next_Steps|remains to be done]] on this protocol and [[#XI._Acknowledgements|acknowledge]] the good people who have helped us get here.<br />
<br />
= II. History and literature review =<br />
<br />
<span style="font-size:200%">T</span>wo-party Off The Record messaging (OTR) was introduced in [BGB04] as an alternative to PGP for secure casual Internet chat by providing necessary forward secrecy and deniable transcript features. The paper proposes the use of symmetric encryption and message authentication in OTR for confidentiality and integrity, and the Diffie-Hellman key exchange for authenticating the other party in the chat. Since publication in 2004, it has defined the standard for secure Internet chat attracting a lot of academic attention and security analysis. The OTR protocol is now at [https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html Version 3] and the [https://otr.cypherpunks.ca/index.php#downloads libotr software libraries] are continuously updated. Our research and literature review focused on the protocol presented in [BGB04] and the subsequent proposal for a multiparty use-case in [GUVGC09].<br />
<br />
In [RGK05], researchers point out that OTR’s approach to authenticate renewed ephemeral session keys is provided by the property of confidentiality and is therefore dependent on the secrecy of the conversation. Hence, breaking the secrecy of the conversation (e.g. by leaking the session key) will lead to false authentication as well. They offer two authenticated deniable key exchange protocols, which also provide forward secrecy, as a replacement for OTR’s original key exchange. Furthermore, they argue that forgeability and malleability do not have any mathematical consequence in improving deniability if the parties have been authenticated by a deniable key exchange scheme. They argue that as these properties pose potential security threats, it is desirable to omit them from the protocol entirely.<br />
<br />
An alternative appears in [BS07], using the Schnorr zero-knowledge proof and signature algorithm, to introduce a 4-round challenge-based authentication scheme that grants deniability to the two-round authenticated protocol described in [BVS05].<br />
<br />
[ACMP10] offers a more efficient protocol than [BS07] in the sense that ephemeral Diffie-Hellman elements are reusable to regenerate keys when some of the participants change. As such, it offers a one-round protocol to generate a key for a subgroup of the original conversation.<br />
<br />
An unauthenticated exchange of the OTR version identifier can pose a threat to authenticity as shown in [BM]: the adversary can force clients to downgrade to an older, (potentially insecure) version of the protocol. They also note the Diffie-Hellman key exchange failure in delivering authentication in the presence of an active adversary. Furthermore, they show that the early publication of MAC keys for the purpose of forgeability can easily enable the active adversary to forge messages during the conversation (instead of the intended forgeability after the conversation has ended). Finally, they argue that in an environment where the adversary is controlling the whole network, she can effectively disarm the protocol of its forgeability property.<br />
<br />
Various attempts have been made to construct an efficient multiparty (known as group) authenticated key exchange protocol. OTR authors proposed a generalisation of two-party OTR to a multiparty use-case in [GUVGC09]. However, they did not specify the cryptographic primitives, neither did they give a formal definition of the adversaries nor the proof of the algorithm’s security (reduction). Although a more robust key exchange is proposed, some primary performance analysis of the implementation of the key agreement protocol has been shown to be impractically slow, especially on mobile devices [Gun13a][Git11].<br />
<br />
[LVH13] proposes GOTR as an alternative to [GUVGC09] with a goal of improving on some of its security properties. A notable change is the use of p2p private channels to send message digest so as to establish transcript consistency and implicit message origin authenticity between users. GOTR also strives to improve on repudiability by considering deniability against an 'online judge' as well as forgeability for the entire transcript by a single party (this is possible in [GUVGC09] as long as a deniable AKE is being used). The idea of online repudiabilty relies on the judge controlling up to '''N-2''' parties while the two remaining "honest" parties are allowed to collude. This is slightly unusual for both repudiability and honesty. [LVH13] also proposes an involved contributory BD based key agreement scheme, which disregard room consistency and turns GOTR into a broadcast scheme (c.f. [[#Appendix_B:_Other_design_possibilities|Appendix B]]).<br />
<br />
=III. Design rationale =<br />
<br />
<span style="font-size:200%">O</span>ur approach for ''(n+1)sec'' design was based on the following requirements, in order of importance:<br />
<br />
# A protocol that is provably secure in a sufficiently strong adversarial model that addresses confidentiality, authenticity and forward secrecy<br />
# Applicable to the [https://github.com/cryptocat/cryptocat/wiki/Design-and-Functionality Cryptocat XMPP use-case]<br />
# Providing some degree of deniability when it does not negatively impact usability or our [[#IV._Security_Properties|security goals]]<br />
# Addressing security flaws in [BGB04] and [GUVGC09]<br />
<br />
We designate the protocol suggested in [GUVGC09] as our starting point and apply various modifications to reach a desirable protocol satisfying the above stated goals. <br />
<br />
A significant portion of our research suggested a better performing, more secure alternative to the key exchange protocol suggested in [GUVGC09]. Based on conclusions in [BM] and [RGK05], we are making the following design changes:<br />
<br />
* Using a more secure deniable key exchange algorithm, instead of naive Diffie-Hellman<br />
<br />
In designing ''(n+1)sec''’s deniable authentication and key agreement protocol, we have followed [ACMP10] by choosing a provably secure authenticated key exchange method and replacing the signature-based authentication with a deniable one. We have chosen the protocol introduced in [ACMP10] instead of [BS07], due to its superior efficiency. We abstract out the method where parties communicate their secret for additional flexibility.<br />
<br />
* Using a more practical algorithm, rather than the peer-to-peer signature key exchange<br />
<br />
We have chosen the two round SKEME-based Triple Diffie-Hellman deniable key authentication instead of the Schnorr signature scheme suggested in [BS07] because it saves us two critical rounds for authentication (even though it offers a slightly weaker form of deniability). We have also modified the protocol to represent the chat condition where participants sequentially join and leave the chat.<br />
<br />
* Omitting forgeability and malleability from the protocol and refraining from broadcasting the expired ephemeral authentication keys.<br />
<br />
Following conclusions in [RGK05] we have dropped forgeability (mandatory publication of ephemeral signature/MAC keys) and malleability from our requirements since protocol deniability is based on a deniable key exchange. This significantly improves protocol efficiency, a primary focus for ''(n+1)sec''. The deniability of the authentication scheme prevents users not present in a chat session from forging a part of the transcript, however it allows them to forge a whole session with false participants and a complete transcript.<br />
<br />
Another major departure from the suggested protocol in [GUVGC09] is in-session transcript authentication, which happens every time a participant receives or sends a message. Transcript authentication (referred to as transcript consistency check from here on) is an optimistic approach based on the assumption that the chat server is mandated to provides a reliable and orderly message delivery, as it is in the case of XMPP protocol. We can ensure transcript consistency whenever the underlying transport layer guarantees the reliable delivery of the messages in the same order for all participants. If however, the underlying protocol does not guarantee reliability either in delivery or order, we report the discrepancy in user's transcript compared to their peers but we do not attempt to correct the transport protocol's action (we offer detection but not recovery).<br />
<br />
We also equip ''(n+1)sec'' with heartbeat to ensure in-session forward secrecy, periodical consistency check and freshness. <br />
<br />
We propose the possibility of using block-based, rather than stream-based, encryption for the symmetric encryption primitives. <br />
<br />
Finally, other protocol design possibilities considered and the rationale for not pursuing them further is discussed in [[#Appendix_B:_Other_design_possibilities|Appendix B: Other design possibilities]]<br />
<br />
= IV. Security Properties =<br />
<br />
<span style="font-size:200%">F</span>ollowing from the design rationales proposed in Section[[''(n+1)sec''#Design_rationale|III]], we give an informal description of the properties which ''(n+1)sec'' aims to secure in a multi-party chat session:<br />
<br />
* <span>'''Participant deniable authenticity'''</span> based on their long term persistent identity: While a participant in a chat can be sure of another participant’s authenticity, they cannot prove their confidence to anybody else who has not actively participated in the chat session or who has not interacted with the authenticator prior to the session.<br />
* <span>'''Message origin authenticity'''</span> against both outsider intrusion and the impersonation of existing participants by other malicious participants in the session. This means that the user can be assured of the authenticity of the sender of each original message even if other participants in the room try to impersonate the sender and send messages on their behalf.<br />
* <span>'''Confidentiality'''</span> of the conversation so its content is not accessible or readable by an outsider.<br />
* <span>'''Forward secrecy'''</span> of the conversation, so its content remains inaccessible in the event that the long term private key of a participant (which represents their long term identity) is compromised after session key establishment. In addition in-session forward secrecy means that compromise of the ephemeral keys of a participant, or the session key during chat session which is live for long time, would reveal only a fraction of the transcript.<br />
* <span>'''Room consistency'''</span>, where all participants are confident that they have been participating in the same room; they are confident that everybody in the room believes that everybody else sees the same participant list as they do.<br />
* <span>'''Transcript consistency'''</span>, where all participants are confident that they have been participating in the same conversation; as the conversation continues, they are confident that they have been seeing the same sequence of messages.<br />
<br />
For each of these requirements, it is necessary to formalize the above mentioned properties against an adversarial model which addresses the requirements stated in [[#Design_rationale|Section III]]. The next section will introduce formal definitions covering these elements.<br />
<br />
= V. Chat Session Model =<br />
<br />
In modelling the chat session, in terms of the adversarial models and protocol specifications, the notation of [ACMP10] is followed. This notation is common to other publication on group key exchange such as [GBNM11], and is adherred to for consistency. <br />
<br />
<span>'''Definition V.1 Multi-party chat session'''</span>'': Let <math>\mathcal{U} = \{U_1,...,U_m\}</math> be the set of possible participants. A multi-party chat session is an ordered pair <math>S := (\mathcal{S}, sid)</math> in which <math>\mathcal{S} \subset \mathcal{U}</math> and <math>sid</math> is the unique session id. Without loss of generality we assume <math>\mathcal{S} = \{U_1,...,U_n\}</math> and we interchangeably refer to party <math>U_i</math> by index ''i''. Furthermore, it is assumed that party <math>U_i</math> is presented and identified verifiably by a long-term persistence key pair <math>(LPK_{U_i}, LSK_{U_i})</math>.''<br />
<br />
<span>'''Definition V.2 sub session'''</span> After session ''S'' is established, A subset of participants <math>\mathcal{T}\subset \mathcal{S}</math> might want to start a session in which parties in <math>\mathcal{T}\backslash\mathcal{S}</math> are excluded (for example when those parties leave the chatroom). In such a setting we say <math>T := (\mathcal{T}, sid^T)</math> is a subsession of ''S''. When there is no need to specify the subsession of choice, we use <math>spid</math> to refer to <math>sid^T</math>.<br />
<br />
<span>'''Definition V.3''' ''An'' '''authenticated group key exchange (AGKE)'''</span> ''is Algorithm <math>\Pi</math> which each honest party will execute in order to communicate (by means of sending, receiving or computing) a cryptographic secret - namely a key - among the other parties of a session. By <math>\Pi^S_i</math> (or <math>\Pi_i</math> when the underlying session is understood) we are referring to an instance of <math>\Pi</math> which the party <math>U_i</math> executes to achieve the collective goal. Further more we define'':<br />
<br />
* <span>'''Session id as seen by <math>U_i</math>'''</span>'': Session id <math>sid</math> will be derived during the execution of the protocol. The session id is computed by <math>\Pi^S_i</math> (the instance of the protocol run by <math>U_i</math> for session ''S'') and is indicated by <math>sid^S_i</math>, or <math>sid_i</math> when there is no concern of confusion''<br />
* <span>'''Participant list'''</span>'': <math>plist^S_i</math> is the list of participants which <math>U_i</math> believes are participating in the chat session ''S''.'' When there is no ambiguity in the underlying session, we simply use <math>plist_i</math> notation.<br />
* <span>'''key id'' is the serial number given to the P2P keys generated during the process of key exchange, is computed as <math>Hash(U_i|y_i|U_j|y_j)</math>.<br />
* <span>'''Ephemeral key list'''</span>'': <math>klist^S_i</math> is the list of ephemeral public key <math>y_j = g^{x_j}</math>'s of all participants which <math>U_i</math> believes they are using in the chat session ''S''.'' When there is no ambiguity in the underlying session, we simply use <math>klist_i</math> notation instead. We use the notaion of <math>plist_i|klist_i</math> to represent ordered concatenation of <math>U_i|y_i</math> pairs as in <math>U_1|y_1|\dots|U_n|y_n</math>. The order is assumed to be computable by all participants (lexicographically ordered using long term public key of participants, for example).<br />
* <span>'''Session key of <math>\Pi^S_j</math> as seen by <math>U_i</math>'''</span>'': <math>sk^S_i</math> (or <math>sk_i</math>) is the session key of session ''S'' as computed by <math>\Pi_i</math>. It represents the cryptographic secret computed by AGKE, it can be a set of secrets. The essential defining factor is that it should become common knowledge for the session participants at the end of AGKE execution. Similarly we define <math>subk_i</math> to represent the subsession key''<br />
* <span>'''Accepted state'''</span>'': A party enters the accepted state if it has computed <math>sk^S_i</math> and has detected no errors in the protocol.''<br />
* <span>'''Partnered instances'''</span>'': Two instances <math>\Pi^S_i</math> and <math>\Pi^S_j</math> are considered partnered if and only if both instances have accepted <math>sid_i=sid_j</math> and <math>plist_i = plist_j</math>.''<br />
<br />
* A <span>'''correct'''</span>'' AKGE algorithm is an AKGE which, when all <math>\Pi^S_i</math> instances of AKE algorithm are initiated with access to a network which correctly forwards all messages without modification, all participants ultimately are partnered and all compute equal <math>sk^S_i</math>’s''.<br />
<br />
When underlying session are not considered we may omit the super script <math>\_^S</math> from all above notations.<br />
<br />
= VI. Threat Models and Adversarial Goals =<br />
<span style="font-size:200%">A</span>dversarial models are explained as a game, in which the adversary's possibilitiy of winning the game should be considered in terms of their ability to break the cryptographic primitives.<br /><br />Accordingly to the requirements discussed in Section [[''(n+1)sec''#Security_Properties|IV]], it is necessary to examine the algorithm in terms of following threat cases:<br />
<br />
# Deniable Authenticated key exchange (including a forward secrecy adversary)<br />
# Message origin authenticity<br />
# Confidentiality<br />
# Transcript consistency<br />
<br />
The following sections will define adversarial scenarios which represent the above threats.<br />
<br />
==Deniable Authenticated Key Exchange Adversary==<br />
Following the approach in [BoSt06] the model is divided into two adversaries: ''Authenticated Group Key Exchange'' and the ''Deniability Adversary''.<br />
<br />
As deniability is not our primary focus, we wil consider a weaker deniability adversarial model, which limits possible input similarly to the limitations considered by [GKR06]. This provision would disallow an input from the 'judge' and therefore saves an extra round of communication within the protocol.<br />
<br />
Because he t''(n+1)sec'' protocol runs a peer-to-peer key exchange and establishes parallel deniable authentication, we use the adversarial model from [ACMP10] for ''authenticated group key exchange''. This ensures the security of both group and peer-to-peer keys independently. The protocol also takes advantage of "single<br />
round computation of a subgroup key". Meaning that when a participant leaves the session remaining participants can re-establish a (sub)session with only one round of communication. In this circumstance, the model must also consider an adversary's attack against the subgroup key.<br />
<br />
We do not attempt to model resistance against internal key compromise impersonation (KCI) as defined [GBNM11].<br />
<br />
===Authenticated Key Exchange Adversary===<br />
====Adversarial power====<br />
<br />
The following set of functions model the AKE adversarial threats. The adversary for the authenticated key exchange can mount an attack through a sequence of call to the functions, outlined below. The limitation on the order and condition of calling these functions is defined per adversary. We will re-use these definitions to demonstrate similar routes for other adversaries considered by the threat models in later sections.<br />
<br />
* <span>'''Execute(<math>plist</math>)'''</span>: asks all parties in the <math>plist</math> to run (a new) AGKE protocol and <math>\mathcal{A}</math> will receive the execution transcript, i.e.<math>\mathcal{A}</math> can eavesdrop.<br />
* <span>'''Send(<math>\Pi^S_i,m</math>)/(<math>U_i,m</math>)'''</span> sends a message ''m'' to the instance <math>\Pi^S_i</math>. We assume that ''m'' contains information to identify the sender <math>U_j</math>. <math>\mathcal{A}</math> will receive the execution transcript. Specifically, by sending <math>plist</math> messages it forces <math>U_i</math> to initiate <math>\Pi^S_i</math>.<br />
* <span>'''SKE(<math>\Pi^S_i, spid_i</math>)''': asks <math>\Pi^S_i</math> to compute the subgroup key for the <math>spid_i</math> subsession. In response, <math>\Pi^S_i</math> will either send a message or compute the subgroup key <math>k_{spid_i}</math> depending on the state of <math>\Pi^S_i</math>. This can be invoked only once per input. <br />
* <span>'''RevealGK(<math>\Pi^S_i</math>)''': <math>\Pi^S_i</math> gives <math>sk_i</math> to <math>\mathcal{A}_a</math> if it has accepted (as defined in Definition III.3).<br />
* <span>'''RevealSK(<math>\Pi^S_i, T</math>)''': <math>\Pi^S_i</math> gives the <math>subk^T_i</math> to <math>\mathcal{A}_a</math> if it has been computed for subsession ''T''.<br />
* <span>'''Corrupt(<math>U_i</math>)'''</span>: <math>U_i</math> gives its long term secret key to <math>\mathcal{A}_a</math> (but not the session key).<br />
<!--This is the power for KCI * <span>'''%% \item {\bf RevealState(<math>\Pi_i</math>)}: reveal the internal state of <math>\Pi_i</math> to <math>\mathcal{A}_a</math> (no longer available after acceptance).--><br />
<br />
====Adversary's challenges====<br />
<br />
The following set of functions model the adversary's challenges. These reveal either a random value or a key. The adversary's advantage in distinguishing the cases should be translatable into an attack against the GDH primitive for the protocol to be considered secure.<br />
<br />
* <span>'''TestGK(<math>\Pi^S_i</math>)'''</span>: To the ultimate goal of challenging the confidentially of <math>sk_i</math>, <math>\mathcal{A}</math> can run TestGK(<math>\Pi^S_i</math>) against ''U''. As a the result a random bit ''b'' is chosen, if <math>b = 1</math> then <math>\mathcal{A}_a</math> is given <math>sk_i</math> the session key, otherwise a random value from the same probability distribution is given to <math>\mathcal{A}</math>. Obviously, this can only be invoked once and only on accepted participants.<br />
* <span>'''TestSK(<math>\Pi^S_i</math>)'''</span>: To the ultimate goal of challenging the confidentially of <math>subk^T_i</math>, <math>\mathcal{A}</math> can run TestSK(<math>\Pi^S_i</math>) against ''U''. The result depends on a a random chosen bit ''b'', if <math>b = 1</math> then <math>\mathcal{A}</math> is given <math>subk^{T}_i</math> the subsession key, otherwise a random value from the same probability distribution is given to <math>\mathcal{A}</math>.<br />
<br />
=== Definition of Adversaries and their advantages ===<br />
<br />
The following terminology is useful in simplifying the elimination of trivial adversarial threats. <br />
<br />
'''Definition VI.1''' Accepted <math>\Pi^S_i</math> is '''fresh''' if none of the following is true:<br />
* RevealGK(<math>\Pi_j^s</math>) for <math>U_j \in plist</math>.<br />
* Corrupt(<math>U_j</math>) invoked for any <math>U_j \in plist</math> before any Send(<math>\Pi^S_i,.</math>).<br />
<br />
'''Definition VI.2''' A pair of <math>\Pi^S_i, spid^S_i</math> is '''fresh''', if <math>\Pi^S_i</math> is accepted and if none of the following is true:<br />
* RevealSK(<math>\Pi_j^s, spid^S_i</math>) for <math>U_j \in plist</math>.<br />
* Corrupt(<math>U_j</math>) invoked for any <math>U_j \in plist</math> before any Send(<math>\Pi^S_i,.</math>).<br />
<br />
'''Definition VI.3''' An ''AKE Adversary for the join key agreement'' <math>\mathcal{A}_{join}</math> is a probabilistic polynomial time algorithm (ppt) which can invoke all the functions given above with a<br />
condition that the TestGK is invoked '''at least once''' against a fresh instance <math>\Pi^S_i</math> which stays fresh until the end of the game. The game ends when <math>\mathcal{A}_{join}</math> outputs its guess for ''b''. We say a key exchange protocol is secure if the following function is negligible:<br />
<center><br />
<math><br />
max_{\forall \mathcal{A}_{join}}|2Pr(Output(\mathcal{A}_{join}) = b) - 1|<br />
</math><br />
</center><br />
<br />
Similarly we define <math>\mathcal{A}_{leave}</math> the Adversary leaving the session:<br />
<br />
'''Definition VI.4''' An ''AKE Adversary for the leave key agreement'' <math>\mathcal{A}_{leave}</math> is a ppt which can invoke all the functions given above with the condition that one of the invocations of TestSK is invoked against a fresh instance <math>(\Pi^S_i, spid_i)</math> which stays fresh till the the end of the game. The game ends when <math>\mathcal{A}_{join}</math> outputs its guess for ''b'' for that invocation. We say a key exchange protocol is secure if the following function is negilgible:<br />
<center><br />
<math><br />
max_{\forall \mathcal{A}_{leave}}|2Pr(Output(\mathcal{A}_{leave}) = b) -1|<br />
</math><br />
</center><br />
<br />
===Forward Secrecy Adversary===<br />
<br />
We do not define an independent forward secrecy adversary. Forward secrecy can be derived by resistance against the confidentiality adversary as well incorporating a forward secure key exchange as described in [GBN10]. The adversaries of Definition VI.3 and VI.4, are able to ''Corrupt'' users after the communication of DH secrets. Therefore they can trivially break an AKE without forward secrecy. In this sense, the resistance against forward secrecy adversary is included in AKE adversarial model.<br />
<br />
===Deniability Adversary===<br />
<br />
We use the deniability adversary of [BoSt06], however following the path of [GRK06], we limit the security input of the deniability adversary in order to prevent the adversary from receiving input from the ''judge''.<br />
<br />
'''Definition VI.5''' A '''Deniability Adversary '' <math>\mathcal{A}_{deny}</math> with bound <math>q_c</math> and security input <math>Aux</math> is a ppt algorithm which can invoke Send and Reveal as desired and Corrupt as many as <math>q_c</math> times. At the end, <math>\mathcal{A}_{deny}</math> will output a transcript <math>T_{\mathcal{A}_{deny}}(Aux)</math>.<br />
<br />
'''Definition VI.6''' For each <math>\mathcal{A}_{deny}</math>, we define a ''simulator'' <math>\mathcal{S}_{deny}</math>, is a ppt algorithm which receives the same input as <math>\mathcal{A}_{deny}</math>. It can invoke ''Corrupt'' <math>q_c</math> times in addition to ''Send'' and ''Reveal'' but only against corrupted instances. It terminates by outputting a transcript <math>T_{\mathcal{S}_{deny}(Aux)}</math>. <br />
<br />
'''Definition VI.7''' A ''deniability judge'' <math>\mathcal{J}</math> with security input <math>Aux</math> is a ppt algorithm which can invoke arbitrary number of deniability adversaries <math>\mathcal{A}_{deny}</math> with security input <math>Aux</math>. On each execution of <math>\mathcal{A}_{deny}</math> a corresponding <math>\mathcal{S}_{deny}</math> runs with the same input. At the end a confidential random bit ''b'' is generated, and either <math>T_{\mathcal{A}_{deny}}(Aux)</math> or <math>T_{\mathcal{S}_{deny}}(Aux)</math> is presented to <math>\mathcal{J}</math> based on whether <math>b = 1</math> or 0 respectively. <br />
<br />
'''Definition VI.8''' We call a Group AKE deniable with respect to input set <math>Aux</math>, if the following advantage is negligible:<br />
<math><br />
max_{\forall \mathcal{J}}|2Pr(Output(\mathcal{J}, Aux) = b) -1|<br />
</math><br />
<br />
Similar to [GRK06], we claim that the AKE presented in this paper is deniable when <math>Aux</math> is equal to the set of valid messages eavesdropped by <math>\mathcal{A}_{deny}</math> during other sessions. This, in particular, excludes a transcript computed by <math>\mathcal{J}</math> such as a group element whose discrete logarithm is only known to <math>\mathcal{J}</math> (This means <math>\mathcal{A}_{deny}</math> is given <math>g^a</math> but is unaware of ''a'').<br />
<br />
==Secure Multiparty Channel Adversary==<br />
The desirable way to define an adversary for a multiparty chat session is a secure channel model similar to the two-party secure channels described in [CaKr01] and [KPW13]. However, defining such a model is outside of our current scope. It is desirable to later improve the security of the protocol bu considering such a model at a later stage. At present, we use a per message model for confidentiality and origin authenticity.<br />
<br />
==Message Origin Authentication Adversary==<br />
<br />
<span style="font-size:200%">A</span>s each participant executes a sign and encrypt function before sending their authenticated ephemeral signing key, the message origin adversary model is based on a typical adversary for a signature scheme such as the one presented in [PVY00].<br />
<br />
===Adversarial power===<br />
<br />
In addition to adversarial functions defined in section 1.1.1. we must define the following function to allow for the adversary using the chosen-message attack.<br />
<br />
* <span>'''MakeSend(<math>\Pi^S_i,\Pi^S_j, m</math>)'''</span> causes the <math>\Pi^S_i</math> to sign and send a valid message ''m'' to instance <math>\Pi^S_j</math>. <math>\mathcal{A}</math> will receive the transcript including the signature.<br />
<br />
===Definition of Adversary===<br />
<br />
'''Definition VI.9''': ''Message Origin Authentication Adversary'' <math>\mathcal{A}</math> is a polynomial time algorithm which has access to the '''Corrupt''', '''Send''', '''Reveal''' and '''MakeSend''' functions. The output of the algorithm should be a message ''m'' sent to instance <math>\Pi^S_j</math>. The scheme is secure against Message Origin Adversary if the probability in which <math>\Pi^S_j</math> believes that ''m'' has originated from an uncorrupted participant <math>U_i</math> is negligible.<br />
<br />
==Message Confidentiality Adversary ==<br />
<br />
The goal of adversary <math>\mathcal{A}_{conf}</math> is to read, at least, part of the communications transcript during the session.<br />
<br />
===Adversary's challenges===<br />
The following set of functions model the confidentiality adversary's challenges. These reveal either a random value or an encrypted message. The adversary's advantage in distinguishing the cases should be translatable into an attack against the block cipher, AES in this case.<br />
<br />
* <span>'''TestM(<math>\Pi^S_i, m</math>)'''</span>: To the ultimate goal of challenging the indistinguishibility of <math>E(m)></math>, <math>\mathcal{A}_{conf}</math> can execute TestM(<math>\Pi^S_i, m</math>) against <math>U_i</math>. As a result a random bit ''b'' is chosen, if <math>b = 1</math> then <math>\mathcal{A}_{conf}</math> is given <math>E_{s_k}(m)<math>, the encrypted message, otherwise a random value from the same probability distribution is given to <math>\mathcal{A}_{conf}</math>.<br />
<br />
===Definition of Adversaries and their advantages===<br />
<br />
'''Definition 1''' A ''Confidentiality Adversary'' <math>\mathcal{A}_{conf}</math> is a ppt which can invoke all the functions given in sections [[''(n+1)sec''#Adversarial_power|IV.1.1.1]] and [[''(n+1)sec''#Adversarial_power|IV.1.1.3]] with the condition that one of the invocations of TestM is invoked against an instance <math>\Pi^S_i</math> where all instances in session ''s'' are fresh and stay fresh till the end of the game. The game ends when <math>\mathcal{A}_{conf}</math> outputs its guess for ''b'' for that invocation. We say that the protocol is secure if the following function is negligible:<br />
<center><br />
<math><br />
max_{\forall {A}_{conf}}|2Pr(Output(\mathcal{A}_{conf}) = b) -1|<br />
</math><br />
</center><br />
<br />
==Consistency Adversary==<br />
In ''(n+1)sec'' protocol, we attempt to ensure the consistency among participants all along the session incrementally, i.e. assuring consistency after receiving each message in a timely manner. However, we do not model the incremental aspect of consistency into the adversarial model, for the sake of simplicity.<br />
<br />
'''Definition 1''' ''Transcript Consistency Adversary'' <math>\mathcal{A}_{cons}</math> is given the ability to invoke all functions in sections [[''(n+1)sec''#Adversarial_power|IV.1.1.1]] and [[''(n+1)sec''#Adversarial_power|IV.1.1.3]]. We say the protocol is secure against ''Consensus Adversary'' if at least two uncorrupted accepted instances <math>\Pi^S_i, \Pi^S_j</math> possess the transcripts chain <math>TransChain_{\Pi^S_i}(l) \neq TransChain_{\Pi^S_j}(l)</math> and they believe they have the <math>TransChain_{\Pi^S_i}(l) = TransChain_{Pi^S_j}(l) with non-negligible probability.<br />
<br />
For definition of <math>TransChain_{\Pi^S_i}(l)</math> see Section [[''(n+1)sec''#Definitions_and_assumptions|VII.4.1]].<br />
<br />
= VII. Protocol High Level Design =<br />
<br />
<span style="font-size:200%">T</span>o achieve the security properties listed in [[#IV._Security_Properties|Section IV]], we break the protocol into the following sub-protocols:<br />
<br />
# <span>'''Deniable authenticated signature key and session key exchange'''</span>, where participants deniably authenticate each other and agree on session key(s), while also exchanging ephemeral signing keys<br />
# <span>'''Communication'''</span>, where parties send authenticated confidential messages<br />
# <span>'''Transcript consistency verification'''</span>, where parties verify that all have received and seen an identical transcript in the same order, since the start of the chat session after receiving each messages.<br />
<br />
Our choice of sub-protocols for ''(n+1)sec'' followed suggestions made in [BGB04] and [GUVGC09], except where there has been a practical or security-related reason to deviate from those recommendations.<br />
<br />
In the following section we briefly describe our choice of the sub-protocols for each of the required tasks for a multi-party chat session.<br />
<br />
== '''VII.1 Design of Deniable Authenticated Signature Key Exchange'''==<br />
<br />
We have chosen our deniable signature key exchange protocol following the conclusions in [Gun13b] - by identifying a secure key exchange protocol that satisfies our needs. We then apply the triple Diffie-Hellman authenticated exchange to grant it properties of deniability [Ma13]. Subsequently, one can apply the same approach presented in [Gun13b] to communicate ephemeral signature keys during the key establishment process. However, for efficiency, we use the same ephemeral Diffie-Hellman private and public values used to deniably authenticate users and generate secret shares to produce ephemeral signatures.<br />
<br />
For the choice of the base authenticated key exchange protocol, we suggest a variant based on [ACMP10]. The rationale for the choice is laid out as follows:<br />
<br />
* The base design of the protocol in [ACMP10] is the same as the base for [BVS05] (recommended by [Gun13a]). However, the protocol presented in [ACMP10] is simpler.<br />
* [ACMP10] offers a peer-to-peer key exchange with no extra rounds, if needed.<br />
* [BVS05] and [ACMP10] are superior to the widely studied [BCPQ01] and its dynamic variation [BCP01] both in security and performance (<math>O(1)</math> rounds).<br />
* [BVS05] has been suggested by [Gun13b] for the reason described in [Gun13a]. We believe that the new deniable authentication approach, as it is similar to the SKEME protocol, satisfies the properties of deniability which [BVS05] considered crucial aside from the cooperating judge.<br />
* Security analysis of [GBNM11] and [BCGNP08] has found that [BVS05] is provably secure against all attacks (including the insider attacks) that the papers consider.<br />
* It is a two-round protocol and hence offers competitive efficiency considering the security property that it provides.<br />
<!--* [BVS05] has existed for years and its various security aspects have been investigated by several researchers including [GBNM11] and [BCGNP08] which gives [BVS05] an advantage over newer algorithms.!--><br />
* [ACMP10] only needs one round of key re-agreement in the case of a participant leaving the chat, while [BVS05] enforces re-computation of Diffie-Hellman ephemeral keys and hence needs a minimum of two rounds plus overhead of re-authenticating the new ephemeral keys. This can significantly improve the efficiency of casual chat sessions where participants frequently enter and exit the chat.<br />
* Although the Schnorr based algorithm suggested in [BVS05] satisfies a more comprehensible deniable model, triple Diffie-Hellman authenticated key exchange only needs two rounds of communication and can be done alongside the key agreement steps, while the Schnorr based algorithm of [BVS05] needs four rounds.<br />
* Although key exchange algorithms based on the standard model are considered theoretically more secure than those based on the random oracle model, there has been no proposal for a 2-round protocol in the standard model that promises forward secrecy. Therefore, due to the importance of usability and efficiency in our approach, we opted to for a ROM based protocol such as described by [BVS05] and [ACMP10].<br />
<br />
===VII.1a Sharing a secret among the group===<br />
All AGKE descriptions take the necessary steps to share a common secret confidentially among the group members along side other operations such as authentication and insuring partnership. To insure forward secrecy these methods mostly rely upon a P2P Deffie-Hellman key exchange. Most AGKE descriptions rely on sharing an equation and solving a specific linear system described in [[''(n+1)sec''#GroupEnc and GroupDec Functions|IX.4]].<br />
<br />
We abstract this step as GroupEnc/GroupDec primitive, to allow for alternative designs which do not interact with the rest of the protocol and might offer other benefits. For example the "Naive peer-to-peer" primitive [[''(n+1)sec''#GroupEnc_and_GroupDec Functions|IX.4]] trades simplicity and generalizability (to a broadcast scheme c.f. [[''(n+1)sec''#VII.2 Other design possibilities|Section VII.2]]) for bandwidth consumption. <br />
<br />
== '''VII.3 Message Authentication''' ==<br />
<br />
As message authentication needs to be resistant to malicious insiders, following the outline of [GUVGC09], ''(n+1)sec'' signs each message using a public key signature scheme. The messages are signed with the ephemeral key of the sender. The authenticity of the origin can be verified by the public ephemeral key of the party distributed during the key exchange period.<br />
<br />
== '''VII.4 Transcript Ordering and Consistency''' ==<br />
<br />
Since each message sent by any one participant is signed by the ephemeral private key generated for that specific session, it is not possible for the internal or external adversary to forge a message on behalf of an uncorrupted participant.<br />
<br />
However, if the adversary is controlling the network structure, denial or delay of service is always possible. The consistency of the transcript (i.e. all participants see the same transcript in the same order) relies on the means of transport guaranteeing reliable delivery, with a single order, to every participant. In other words, we are verifying the ''reception'' of the message by the intended ''recipients''.<br />
<br />
By assuring transcript consistency, we also preventing <math>U_i</math> from sending different messages to <math>U_j</math>, <math>U_k</math> while they believe they are seeing the same conversation. In absence of transcript consistency, when a central server is managing the chatroom, this attack requires <math>U_i</math> to conspire with server, which is permeable in ''(n+1)sec'' threat model in accordance with the definition of transcript consistency in [GUVGC09].<br />
<br />
The protocol offered in this document examines the transcript for such consistency. In the case that the underlying transport fails to provide this level of consistency, clearly the consistency test will fail. In this sense, failure of consistency does not distinguish between malicious activities or the absence of a reliable transport.<br />
<br />
''(n+1)sec'' performs transcript authentication whenever a message is received. This is to guarantee consistency and protect the protocol against the transcript consistency attack. The procedure is similar to the procedure described in [GUVGC09], with two major differences:<br />
<br />
* We require additionally that message order be preserved for the following reasons:<br />
<br />
# XMPP, as the main protocol considered for this design, delivers messages to all clients in the same order.<br />
# The ''(n+1)sec'' protocol detects if the adversary has manipulated the order of the messages rather than only dropping undesirable messages<br />
# It is simpler to authenticate an ordered transcript compared to an unordered transcript.<br />
<br />
* We also require that each participant updates all other participants about their view of the session transcript every time they send a message, along with requiring heartbeat, this ensures that participants are aware whether or not they are all seeing the same transcript during the session.<br />
<br />
There are some cases where XMPP can fail our reliability assumption. In such cases, our consistency checks will fail. More advanced end-to-end recovery techniques are able to rescue such a scenario. We do not specify such techniques currently, though later versions of the protocol may rectify this.<br />
<br />
=== Definitions and assumptions ===<br />
'''Transport assumption''':<br />
We assume the central server reliably delivers messages to everyone, including the original sender, in the same order.<br />
<br />
'''Definition''' Each message ''M'' (sent after session S has been established) has an implicit server-sequence-number ''seqnum(M)'', a receive-parent: ''parent(M)'' (or recv-parent) the seqnum of last message the sender has received before sending ''M'' and a sender-sequence-number ''own-seqnum(M)''. We interchangeable use ''m'' when refering to both a message and its seqnum.<br />
<br />
Once a message ''M'' with seqnum ''m'' is received by instance <math>\Pi^S_i</math> from the server (including participants own messages sent), a <math>TranscriptChain^S_i[m]</math> may be calculated recursively as follows:<br />
<br />
<math>TrascriptChain^S_i[m] := (M, Hash(TranscriptChain^S_i[m - 1]))</math><br />
<br />
(we define TrascriptChain[0] = (sk^S_i, sid_i))<br />
<br />
A new message ''M'' contains ''p'' the seqnum of recv-parent of ''m'', <math>Hash(TranscriptChain^S_i[p])</math> and ''own-seqnum(M)''.<br />
<br />
* We say instance <math>\Pi^S_i</math> has ''accepted'' message ''m'' if it has been received by <math>\Pi^S_i</math>, then decrypted-verified.<br />
<br />
* We say instances <math>\Pi^S_i</math> and <math>\Pi^S_j</math> have reached mutual consistency for message ''m'' if both accepted message ''m'' and have calculated the same hash of <math>TranscriptChain(m)</math> and verified <math>H_j(TranscriptChain^S_i[m])) == H_i(TranscriptChain^S_i[m])</math>. <br />
<br />
* We say session ''S'' has reached consistency on message ''m'', if all instances <math>\Pi^S_i, \Pi^S_j \in plist^S</math>, <math>\Pi^S_i</math> and <math>\Pi^S_j</math> have reached mutual consistency.<br />
<br />
=== Server order ===<br />
All clients see the same message order from the server. All messages are sent to all users. Aside from the presence messages (messages which indicate a user is joining or leaving a chatroom or if they have been inactive for a long time) sent by the server, messages are sent by users.<br />
<br />
All messages in a room have a unique sequence number (0, 1, ...). We assume that the server is unaware of sequence numbers (e.g. XMPP MUC); clients must allocate them implicitly when receiving messages.<br />
<br />
= VIII. ''(n+1)sec'' Protocol: Step by Step =<br />
<br />
<span style="font-size:200%">I</span>n this section we present the ''(n+1)sec'' protocol in algorithmic format. All user IDs should be considered the modulo number of participants in the room.<br />
<br />
Deniable authentication is derived from the Triple Diffie-Hellman algorithm presented in [Sys14]. Joining the room is a variation of the two-round mBD+P protocol presented in [ACMP10] where the authentication step has been made deniable. Leaving the room is the one-round mBD+S from [ACMP10].<br />
<br />
==VIII.1 Schematic view of the key exchange==<br />
<br />
The protocol computes a unified session key for all participants. This imposes, in particular, the necessity that all <math>plist_i</math>' is identical for all participants. However, as consistent view is part of ''(n+1)sec'' security model, it does not impose extra limitation on the protocol. For more information please see [[#Participatory_vs_individually_independent_computation_of_group_keys|Appendix B: Participatory vs individually independent computation of group keys]].<br />
<br />
For simplicity, group operation is written multiplicatively (even though it is actually an elliptic curve point operation traditionally represented by addition).<br />
<br />
Whenever our design deviates from [ACMP10], it is marked in {{Font color|black|yellow|yellow}}. We have abstracted out the steps mentioned in [ACMP10] as an independent primitive in {{Font color|black|pink|pink}}:<br />
<br />
'''Algorithm 1'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="center"|Round<br />
!align="center"|Step<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="center"|1<br />
|align="center"|1<br />
|align="right"|Generate ephemeral DH private key<br />
|align="center"|<math> x_i \leftarrow [0, order(g)]</math><br />
|align="center"|Computation<br />
|-<br />
|align="center"|<br />
|align="center"|2<br />
|align="right"|Generate DH key for BD, Triple DH and Signature<br />
|align="center"|<math>y_i \leftarrow g^{x_i}</math><br />
|align="center"|Computation<br />
|-<br />
|align="center"|<br />
|align="center"|3<br />
|align="right"|Broadcast User identity and the DH key<br />
|align="center"|<math>(U_i, y_i)</math><br />
|align="center"|Broadcast<br />
|-<br />
|align="center"|2<br />
|align="center"|4<br />
|align="right"|Compute Session Id<br />
|align="center"|<math>sid_i \leftarrow (U_1|y_1|\dots|U_n|y_n)</math><br />
|align="center"|Receive<br />
|-''(n+1)sec''<br />
|align="center"|<br />
|align="center"|5<br />
|align="right"|Generate Triple Diffie-Hellman P2P keys<br />
|align="center"|{{Font color|black|yellow|<math>k_{i,j} \leftarrow H({y_j}^{LSK_{U_i}},LPK_{U_j}^{x_i},y_j^{x_i}) \; \forall j \neq i</math>}}<br />
|align="center"|Computation<br />
|-<br />
|align="center"|<br />
|align="center"|6<br />
|align="right" |Generate key confirmations<br />
|align="center"|{{Font color|black|yellow|<math>kc_i \leftarrow (H(k_{i,1}, U_1),\dots,H(k_{i,n}, U_n))</math>}}<br />
|align="center"|Computation<br />
|-<br />
|align="center"|<br />
|align="center"|7<br />
|align="right"|Generate secret shares<br />
|align="center"|<math>z'_i \leftarrow (H(k_{i,j}, sid_i) for j \in \{1,\dots,n\})</math><br />
|align="center"|Computation<br />
|-<br />
|align="center"|<br />
|align="center"|8<br />
|align="right" |Encrypt shares<br />
|align="center"|{{Font color|black|pink|<math>z_i \leftarrow GroupEnc(k_{i_j} for j \in \{1,\dots,n\}, z')</math>}}<br />
|align="center"|Computation<br />
|-<br />
|align="center"|<br />
|align="center"|9<br />
|align="right"|Sign identity, shares<br />
|align="center"|<math>\sigma_i \leftarrow Sign_{x_i}(U_i, z_i, sid)</math><br />
|align="center"|Computation<br />
|-<br />
|align="center"|<br />
|align="center"|10<br />
|align="right"|Broadcast encrypted shares and confirmation<br />
|align="center"|<math>(U_i, z_i, \sigma_i,</math>{{Font color|black|yellow|<math>kc_i</math>}}'')''<br />
|align="center"|Broadcast<br />
|-<br />
|align="center"|-<br />
|align="center"|11<br />
|align="right"|Check validity of key confirmation<br />
|align="center"|{{Font color|black|yellow|<math>kc_k[j] \stackrel{?}{=} kc_j[k] \; \forall j \neq k</math>}}<br />
|align="center"|Receive<br />
|-<br />
|align="center"|<br />
|align="center"|12<br />
|align="right"|Check signatures<br />
|align="center"|<math>Verify_{y_i}(\sigma_j) \; \forall j \neq i</math><br />
|align="center"|Computation<br />
|-<br />
|align="center"|<br />
|align="center"|13<br />
|align="right"|Check Session Ids<br />
|align="center"|<math>sid_j \stackrel{?}{=} sid_i \; \forall j \neq i</math><br />
|align="center"|Computation<br />
|-<br />
|align="center"|<br />
|align="center"|14<br />
|align="right"| Generate session key<br />
|align="center"|{{Font color|black|pink|<math>sk_{i} \leftarrow H(GroupDec(k_{i,j}, z_j \; \forall j),sid_i, U_j) \; \forall j \neq i</math>}}<br />
|align="center"|Computation<br />
|}<br />
<br />
===Triple Diffie-Hellman authentication===<br />
''(n+1)sec'' uses a varient of Triple Diffie-Hellman (TDH) protocol also employed in Textsecure protocol [Mo13] to carry on mutual deniable authentication as well as peer-to-peer secret key exchange. It can be seen as a variation of [SoKi00] key exchange, however, unlike SoKi00], as it does not multiply all three DH secrets and therefore is not suspticble to attacks mentioned in [BoMa10].<br />
<br />
By using TDH secret both in p2p key as well as in key confirmation step, (n+1)sec both implicitly and explicitly authenticate the peers.<br />
<br />
In Algorithm 1, TDH and the original group key exchange from [ACMP10] has been combined to provide a deniable authenticated group key exchange. Here, we single out TDH Algorithm 1.1 for better presentation of the protocol for the reader.<br />
<br />
'''Algorithm 1.1''' Triple Diffie-Hellman between <math>U_i</math> and <math>U_j</math><br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="center"|Round<br />
!align="center"|Step<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="center"| 1<br />
|align="center"|1<br />
|align="right"|Generate ephemeral DH private key<br />
|align="center"|<math> x_i \leftarrow [0, order(g)]</math><br />
|align="center"|Computation<br />
|-<br />
|align="center"|<br />
|align="center"|2<br />
|align="right" | Generate ephemeral DH public key<br />
|align="center"|<math>y_i \leftarrow g^{x_i}</math><br />
|align="center"|Computation<br />
|-<br />
|align="center"|<br />
|align="center"|3<br />
|align="right" | Broadcast User identity and the DH key<br />
|align="center"|<math>(U_i, y_i)</math><br />
|align="center"|Broadcast<br />
|-<br />
|align="center"|2<br />
|align="center"|4<br />
|align="right" |Receive other party id and ephemeral DH public key<br />
|align="center"|<math>(U_j|y_j)</math><br />
|align="center"|Receive<br />
|-''(n+1)sec''<br />
|align="center"|<br />
|align="center"|5<br />
|align="right"|Generate Triple Diffie-Hellman P2P keys<br />
|align="center"|<math>k_{i,j} \leftarrow H({y_j}^{LSK_{U_i}},LPK_{U_j}^{x_i},y_j^{x_i}) \; \forall j \neq i</math>}}<br />
|align="center"|Computation<br />
|-<br />
|align="center"|<br />
|align="center"|6<br />
|align="right" |Send key confirmation to other party<br />
|align="center"|<math>kc_i \leftarrow H(k_{i,j}, U_j)</math><br />
|align="center"|Broadcast<br />
|-<br />
|align="center"| -<br />
|align="center"|7<br />
|align="right"|Receive and Check validity of key confirmation<br />
|align="center"|<math>kc_j \stackrel{?}{=} H(k_{i,j}, U_i)</math><br />
|align="center"|Receive<br />
|}<br />
<br />
===''GroupEnc'' and ''GroupDec'' functions===<br />
For the high level design of the protocol we do not specify the primitives for ''GroupEnc'' and ''GroupDec'' used in steps '''XX''' and '''XX''' as part of the protocol, as we do not specifies the Hash function and the block cipher. We explain their property here. We choose a candidate in section IX.4.<br />
<br />
The ''GroupEnc'' and ''GroupDec'' functions are primitives which are called collectively by all instances involved in the session and are supposed to satisfies the following goal:<br />
<br />
'''Definition''': Let <math>\mathcal{S} := \{U_1,...,U_n\}</math> and for each <math>i,j</math>, let <math>k_{i,j}</math> be a secret shared between and only between <math>U_i</math> and <math>U_j</math>. The goal of group <math>\mathcal{S}</math> is that:<br />
<br />
# Each member of group <math>U_i</math> to generate and share a secret <math>z'_i</math> among the member of group ''G'' using public channel <math>\mathcal{C}</math>.<br />
# <math>z'_i</math> remains unknown for any <math>\mathcal{A} \not \in G</math> eavesdropping the channel <math>\mathcal{C}</math>.<br />
<br />
To this end each member <math>U_i</math> compute <math>z_i := GroupEnc(k_{i,j} for j \in \{1,...,n\}, z'_i)</math> and broadcast <math>z_i</math> on <math>\mathcal{C}</math>. Later on when <math>U_i</math> receives all <math>z_j</math>. It recovers all secrets <math>z'_i</math> by computing <math>GroupDec(k_{i,j} for j \in \{1,...,n\}, z'_i)</math>.<br />
<br />
===(n+1)sec key exchange vs original Flexible Group Key Exchange of [ACMP10]===<br />
Although in higher level view of (n+1)sec we generalized the process of key exchange using ''GroupEnc''/''GroupDec'' abstraction, at lower level our choice of primitive for this functions make the group key computation processes of ''(n+1)sec'' and the original key exchange algorithm the same. Hence, the steps marked pink in Algorithm 1, only differ in from [ACMP10] but not in result.<br />
<br />
(n+1)run a deniable mutual authentication protocol along side with the key exchange protocol, this results in communicating extra key confirmation data along side of other data exchanged during the course of running the protocol. As we will show in the proof, these data has effect on the usual run of the algorithm.<br />
<br />
The only step that ''(n+1)sec'' runs differently compare to the original algorithm (beside generating extra data), is computation of mutual secret, between <math>U_i</math> and <math>U_j</math>. In original, algorithm it is simply <math>g^{x_i}{x_j}</math>. In ''(n+1)sec'', it is the triple DH secret <math>H({y_j}^{LSK_{U_i}},LPK_{U_j}^{x_i},y_j^{x_i})</math>. We will prove that this change does not compromise any of the protocol proprieties.<br />
<br />
The main difference between the two key exchange algorithms is in the key used for signature. In original algorithm, parties use their long term private key to sign their contribution, while in ''(n+1)sec'' they use their ephemeral keys. However, because the ephemeral keys has been authenticated before used for verification, we prove that the authenticity of signatures in both algorithms are equivalent under CDH assumption.<br />
<br />
==VIII.2 Chatroom Setup==<br />
<br />
In almost any practical case, participants join the chat sequentially. It is assumed that multiple participants cannot join simultaneously. For the sake of efficiency one can adjust the implementation to have a threshold time to wait and thus start a chat with more participants. However, this makes the implementation significantly more complicated without any evident efficiency benefit.<br />
<br />
Therefore, our assumption is that a secure chat is always set up when a participant starts the chat room. Additional participants would be added sequentially using Algorithm [[#VIII.3_Joining|VIII.3]], as they enter the chat. Algorithm [[#Chatroom_setup|1]] describes the chat room setup protocol.<br />
<br />
'''Algorithm 2'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right"|Generate ephemeral DH private key of the room initiator<br />
|align="center"|<math> x_i \leftarrow [0, order(g)]</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"|Generate DH key for BD, Triple DH and Signature<br />
|align="center"|<math>y_i \leftarrow g^{x_i}</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Set participant list<br />
|align="center"|<math>plist \leftarrow [U_i]</math><br />
|align="center"|Computation<br />
|}<br />
<br />
=== VIII.3 Join ===<br />
<br />
Joining a chat involves two different procedures: the Join procedure, described in Algorithm [[''(n+1)sec''#Join|2]], which runs on the new participant’s instance, and an Accept New Participant Procedure, described in Algorithm [[''(n+1)sec''#Protocol_for_other_participants_already_in_the_chat_to_accept_the_newcomer|3]], which runs on the clients of participants that are already in the chat.<br />
<br />
When a new participant <math>U_{n+1}</math> joins the chat, current participants can still use their established authenticated ephemeral public key (to derive the <math>sessionKey_{new}</math> and as their signature verification key). Confidentiality of <math>sessionKey_{old}</math> is guarded against the new participant by Diffie-Hellman key shares hashed alongside the session id (which is dependent on the list of participants). The new participant cannot combine the old and new shares to recover <math>sessionKey_{old}</math>. The fact that old participants do not need to compute new ephemeral keys (and re-verify their ephemeral identities) decreases the computational complexity of the protocol.<br />
<br />
The new participant needs to authenticate everybody already in the room and hand them their ephemeral key. All the parties already in the room only need to authenticate the new participant and need to send to them their ephemeral DH key. These procedures are described in Algorithm 3 and 4. After initial authentication step, all parties follow the same procedure to initiate a new session following Algorithm 5.<br />
<br />
==== Authentication Step for new Joining party====<br />
<br />
'''Algorithm 3'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right"|Generate ephemeral DH private key<br />
|align="center"|<math> x_i \leftarrow [0, order(g)]</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"|Generate DH key for BD, Triple DH and Signature<br />
|align="center"|<math>y_i \leftarrow g^{x_i}</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"|Broadcast User identity and the DH key<br />
|align="center"|<math>(U_i, y_i)</math><br />
|align="center"|Broadcast<br />
|-<br />
|align="right"| Receive other users' id/key<br />
|align="center"|<math>plist_i|klist_i \leftarrow (U_1|y_1|\dots|U_n|y_n)\cup(U_i,y_i)</math><br />
|align="center"|Receive<br />
|-<br />
|align="right"|Generate Triple Diffie-Hellman P2P keys<br />
|align="center"|<math>k_{i,j} \leftarrow H({y_j}^{LSK_{U_i}},LPK{U_j}^{x_i},y_j^{x_i})</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"|Generate key confirmations<br />
|align="center"|<math>kc_i \leftarrow (H(k_{i,1}, U_1),\dots,H(k_{i,n}, U_n))</math><br />
|align="center"|Computation<br />
|}<br />
<br />
After this step joining user will proceed to "initiate new session" by Algorithm 5.<br />
<br />
====Authentication Step for parties in the room====<br />
For other participants to a accept a new participant only, the authentication step is different. After current participants authenticate the new user, they proceed to update session.<br />
<br />
'''Algorithm 4'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right"| broadcast all user's identities <br />
|align="center"|<math> (U_1|y_1|\dots|U_n|y_n) </math><br />
|align="center"|Broadcast<br />
|-<br />
|align="right"| Receive other users' id/key and update participant list<br />
|align="center"|<math>(plist_i|klist_i) \cup (U_j|y_j)</math><br />
|align="center"|Receive<br />
|-<br />
|align="right"|Generate Triple Diffie-Hellman P2P key for the new participant<br />
|align="center"|<math>k_{i,j} \leftarrow H({y_j}^{LSK_{U_i}},LP_{U_j}^{x_i},y_j^{x_i})</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"|Generate key confirmations<br />
|align="center"|<math>kc_{i,j}\leftarrow H(k_{i,j}, U_i) </math><br />
|align="center"|Computation<br />
|}<br />
<br />
After this step users will proceed to "initiate new session" using Algorithm 5.<br />
<br />
==== Initiate new session ====<br />
<br />
'''Algorithm 5'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right"|Compute Session Id<br />
|align="center"|<math>sid_i \leftarrow H(U_1|y_1|\dots|U_n|y_n)</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Cancel any pending request for establishing a session with the same Id<br />
|align="center"|AxeNewSessionRequestTimer<math>(sid_i)</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"|Generate secret shares<br />
|align="center"|<math>z'_i \leftarrow (H(k_{i,j}, sid_i) for j \in \{1,\dots,n\})</math><br />
|align="center"|Computation<br />
|-<br />
|align="right" |Encrypt shares<br />
|align="center"|<math>z_i \leftarrow GroupEnc(k_{i_j} for j \in \{1,\dots,n\}, z')</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"|Sign identity, shares<br />
|align="center"|<math>\sigma_i \leftarrow Sign_{x_i}(U_i, z_i, sid)</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"|Broadcast key shares and confirmation (if any)<br />
|align="center"|<math>(U_i, z_i, \sigma_i, kc_i)</math><br />
|align="center"|Broadcast<br />
|-<br />
|align="right"| Receive other user(s)' key shares and confirmation of unauthenticated users or Time out<br />
|align="center"|Wait to Receive (<math>U_j|z_j,\sigma_1,kc_{ji}) </math> for <math> U_j</math> unauthenticated or Timeout by(2<math>\times</math>BROADCAST_LATENCY+INTERACTION_GRACE_INTERVAL, Drop inactive users, queue a new session request)<br />
|align="center"|Receive<br />
|-<br />
|align="right"|Check validity of key confirmation of unauthenticated users<br />
|align="center"|<math>kc_i[j] \stackrel{?}{=} H(k_{j,i}, U_j)</math> for unauthenticated <math> U_j</math> <br />
|align="center"|Computation<br />
|-<br />
|align="right"|Check signatures<br />
|align="center"|<math>Verify_{y_i}(\sigma_j)</math> for ''j'' in {1,...,''n''}<br />
|align="center"|Computation<br />
|-<br />
|align="right"|Check Session Ids<br />
|align="center"|<math>sid_j \stackrel{?}{=} sid_i \; \forall j \neq i</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Generate session key<br />
|align="center"|<math>sk_{i} \leftarrow H(GroupDec(k_{i,j}, z_j \; \forall j),sid_i, U_j) \; \forall j \neq i</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Initiate the TranscriptChain<br />
|align="center"|<math>TrascriptChain^S_i[0] \leftarrow (sk^S_i, sid_i)</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Initiate the last_sender_seq_num array<br />
|align="center"|<math>last\_sender\_seq\_num \leftarrow (0,...,0)</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Initiate the own_seq_num to 0<br />
|align="center"|<math>own\_seq\_num \leftarrow 0 </math><br />
|align="center"|Computation<br />
|}<br />
<br />
==== Sending and receiving messages while joining is in progress ====<br />
<br />
In situations where a prolonged joining process (due to connection problems or malicious activities) has an adverse effect on the user experience, it might be desirable to enable that joining users can communicate with the parties in the room, while maintaining minimum assurances of authenticity, confidentiality, forward secrecy, as well as consistency only among participants.<br />
<br />
Consistency aspects of ''(n+1)sec'', both for the room view (''plist'') and for the transcript, are reached through group agreement. However, there are times when group agreement may be hard or impossible to reach either due to latency in a single participant's connection or due to a single participant broadcasting incorrect confirmation data (such as wrong ''plist'', ''sid'', key share, etc).<br />
<br />
We offer an extension to the ''(n+1)sec'' protocol to tackle this problem during the joining process. When a new participant joins the room, they send their DH key shares to the other participants. The other participants send their ephemeral key in return. They then send their key confirmation and key share. If this extension is to be considered, as soon as each user receives a key confirmation from another user, who is not currently part of the session, ''(n+1)sec'' displays a message highlighting the fact that although the user is not part of the session part of the conversation (from users' who confirmed the new user's identity) is being shared with them (through P2P encryption using the key derived from DH Key). The protocol, however, does not honour their input in the consistency check until a new session including the new user is set up. Each client can decide whether to disable this option.<br />
<br />
The user remains in the list of those not part of the current session, but receives the session messages until a new session is set up. Similarly, when a user receives a message from a user who is not part of the session, ''(n+1)sec'' will decrypt the message and display it with a disclaimer that the user is not yet part of the session and that some participants may not receive the same message.<br />
<br />
This is less secure model in which a room is a forwardly secure authenticated communication channel while a session is a subset of the room, which additionally offers a consistent view of the room and consistent messages among participants. The detail of the process is depicted in Secthoin VIII.5<br />
<br />
===VIII.4 Leave===<br />
Leaving a chatroom involves a message from a leaving party indicating its intention to leave which, as with all other messages, contains the hash of TranscriptChain and one procedure for those who are staying in the chatroom (Procedure Farewell) which is described in Table [[''(n+1)sec''#Leave]]. <br />
<br />
====Farewell====<br />
<br />
Run by exiting user.<br />
<br />
'''Algorithm 6'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right"| Send farewell message<br />
|align="center"|Send("Leaving!")<br />
|align="center"|Broadcast<br />
|-<br />
|align="right"| Wait to receive hashes of TranscriptChain or Timeout<br />
|align="center"|Wait to Receive() or Timeout by((2 <math>\times</math>BROADCAST_LATENCY)+INTERACTION_GRACE_INTERVAL)<br />
|align="center"|Receive<br />
|}<br />
<br />
====Shrink====<br />
<br />
When the remaining participants receive the farewell message they need to reply with the Hash of TranscriptChain of the last message seen by the leaving user. They also need to re-run the one round key update algorithm. However, they only need a notice from the server that the user is leaving to initiate a subsession excluding the leaving user. <br />
<br />
Additionally, failure to receive a heartbeat from a user will result in executing Algorithm [[''(n+1)sec''#Shrink]] excluding users who did not update their key.<br />
<br />
'''Algorithm 7'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right"| Send Hash of TranscriptChain of last message seen by leaving user<br />
|align="center"|Send(<math>H(TranscriptChain^S_i[Parent(m_{farewell})])</math>)<br />
|align="center"|Broadcast<br />
|-<br />
|align="right"| Remove leaving user's id/key and update participant list<br />
|align="center"|<math>(plist_i|klist_i) \backslash (U_j|y_j)</math><br />
|align="center"|Computation<br />
|}<br />
<br />
Users will proceed to "initiate new session" steps.<br />
<br />
=== VIII.5 Secure Send and Receive ===<br />
<br />
After the session key is established, participants will use Algorithms [[''(n+1)sec''#Send|5]] and [[''(n+1)sec''#Receive|6]] to communicate securely.<br />
<br />
On Send, the protocol checks the status of the new ephemeral Diffie-Hellman and key share using messages it receives from participants. It (re)sends any missing pieces. It also informs other participants which part of the key share has been received by the participant. This information is needed in order to enforce in-session forward secrecy. The metadata flag indicates if the message being sent only contains meta data (e.g. heartbeat) or actual user communication.<br />
<br />
On Receive, the protocol updates who has seen which pieces of the key shares. The protocol also generates a new group key if the new key shares have been received from all participants. Those who have not updated their key shares eventually time out via their heartbeat interval.<br />
<br />
====VIII.5.1 (n+1)sec Message Structure====<br />
<br />
Every (n+1)sec message sent after establishment of a session has the following format:<br />
<br />
np1sec:3Base64EnocodedMessage:3<br />
<br />
The Base64EncodedMessage is decoded as:<br />
<br />
sid, Encrypted part of the message<br />
<br />
Encrypted message can be decrypted by the session key and has the following structure<br />
<br />
Signed message, Signature corresponding to the signed message<br />
<br />
Signed Message consists of following parts<br />
<br />
sid, sender ID, User message, meta message, hash of TranscriptChain of the message, naunce<br />
<br />
The "session ID" and the "sender ID" are prepended in part to address concerns of [Da01]. The nuance is a random 128 bit value, appended to prevent any possibility of replay or brute force attack.<br />
<br />
User message is the plain text typed by user and handled to (n+1)sec by the chat client.<br />
<br />
meta message contains a message has the following format<br />
<br />
meta_only , ustate_1, ..., ustate_n, current_load<br />
<br />
If meta_only flag is true then User message is ignored and client is informed not display anything<br />
<br />
<math>ustate_i</math> flag = {0: sender has no key update from <math>U_i</math>, 1: sender has received a new ephemeral key from <math>U_i</math>, 2: user has received secret share from <math>U_i</math>}<br />
<br />
current_load = (load_flag, load)<br />
<br />
load_flag = 0 no load<br />
load_flag = 1 load contains new ephemeral public key from sender<br />
load_flag = 2 load contains new secret share from the sender<br />
<br />
The message also include "hash of TranscriptChain" of parent of the message as "additional authenticated data". <br />
<br />
<math>H(TransciptChain[parent(m)])</math><br />
<br />
Note that we send the entry in the chain indexed by <math>parent(m)</math> rather than <math>m</math>. This is because a hash may only be calculated once the subject is actually received back from the server (i.e. gets a sequence number). This differs from some other concepts of "message ID" that may be calculated locally.<br />
<br />
====(n+1)sec P2P Message Structure====<br />
<br />
Every (n+1)sec message sent after establishment of a session has the following format:<br />
<br />
np1sec:3Base64EnocodedMessage:3<br />
<br />
The Base64EncodedMessage is decoded as:<br />
<br />
keyid, Encrypted part of the message<br />
<br />
Encrypted message can be decrypted by the session key and has the following structure<br />
<br />
Signed message, Signature corresponding to the signed message<br />
<br />
Signed Message consists of following parts<br />
<br />
keyid, sender ID, User message, naunce<br />
<br />
The "Key ID" and the "sender ID" are prepended in part to address concerns of [Da02]. The nuance is a random 128 bit value, appended to prevent any possibility of replay or brute force attack.<br />
<br />
User message is the plain text typed by user and handled to (n+1)sec by the chat client.<br />
<br />
====Send====<br />
<br />
'''Algorithm 8'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right" | prepend session id and sender id<br />
|align="center"|<math> m \leftarrow (sid, U_i, m) </math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Generate new DH Key or new secret share if needed and append<br />
|align="center"|<math> m \leftarrow (m,s) </math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Increment own sequence number<br />
|align="center"|<math> own\_seq\_num \leftarrow own\_seq\_num+1 </math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Append the hash of the TranscriptChain, up to the parent of the message being sent<br />
|align="center"|<math> m \leftarrow </math> (''m'', <math>H(H(parent(m)), H(TransciptChain^S_i[parent(m)-1]))</math>, <math>parent\_id(m)</math>, <math>own\_seq\_num</math>)<br />
|align="center"|Computation<br />
|-<br />
|align="right" |Generate a random nuance and append to the message<br />
|align="center"|<math> m \leftarrow (m, rand(128bit)) </math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Sign the message and append the signature<br />
|align="center"|<math> m \leftarrow (m, Sign_{x_i}(m))</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"|Encrypt<br />
|align="center"|<math>e \leftarrow Enc_{k_{sid}}(m)</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Broadcast the message<br />
|align="center"|<math>(sid_i, e)</math><br />
|align="center"|Broadcast<br />
|-<br />
|align="right"|Reset Heartbeat timeout timer<br />
|align="center"|ResetHeartbeatTimer()<br />
|align="center"|Computation<br />
|-<br />
|align="right"|Set ACK timeout timer if the message has user content<br />
|align="center"|<math>meta\_only \stackrel{?}=</math> False then ResetHeartbeatTimer()<br />
|align="center"|Computation<br />
|}<br />
<br />
====Receive====<br />
<br />
'''Algorithm 9'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right"| Decrypt message<br />
|align="center"|<math> sid_{rec}, sender\_id, m, s, h, parent\_id, sender\_seq\_num, sigma \leftarrow Dec_k(m) </math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Check signature<br />
|align="center"|<math> Verify_{sender\_id}(m,\sigma) </math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Compute message sequence number<br />
|align="center"|<math> seqnum(m) \leftarrow </math> ComputeSeqNum(''m'')<br />
|align="center"|Computation<br />
|-<br />
|align="right"| Verify session id and transcript consistency and sender sequence number, issue a warning in case of failure<br />
|align="center"|<math> sid_i \stackrel{?}{=} sid_{rec} \; </math> and <math> \; h \stackrel{?}{=} H(H(parent(m)), H(TranscriptChain^S_i[parent(m)-1])) </math> and <math> sender\_seq\_num \stackrel{?}{>} last\_own\_seq\_nums[sender\_id] </math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Update TranscriptChain if possible<br />
|align="center"|<math> TranscriptChain^S_i[seqnum(m)] = (H(m), H(TranscriptChain^S_i[seqnum(m)-1])) </math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Update sender sequence number record<br />
|align="center"|<math>last\_own\_seq\_nums[sender\_id] \leftarrow sender\_seq\_num </math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Update sender's ephemeral key or share secret<br />
|align="center"|<math>y_j \leftarrow s \; \textrm { or } \; z_{j} \leftarrow s</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| If all users' share are received, generate session key<br />
|align="center"|<math>sk_{i} \leftarrow H(GroupDec(k_{i,j}, z_j \; \forall j),sid_i, U_j) \; \forall j \neq i</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Update ack timeout timer<br />
|align="center"|AxeAckTimeoutTimer<math>(parent(m),sender_i)</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Update rekey timeout timer<br />
|align="center"| ResetRekeyTimeOut(<math>sender_i</math>)<br />
|align="center"|Computation<br />
|-<br />
|align="right"| If the message has content set up ACK timer<br />
|align="center"|<math>meta\_only \stackrel{?}= True</math> then <math>SetACKTimer(m)</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| return m<br />
|align="center"|If <math>meta\_only \stackrel{?}{=} False</math> then return ''m''<br />
|align="center"| Computation<br />
|}<br />
<br />
==== Out of Session Send and Receive ====<br />
Due to nature of the key exchange algorithm, (n+1)sec support confidential P2P communication. This in particular enables the user to share the conversation with joining user(s) who confirmed their identity to the user but have not established a session yet. It is worth mentioning that every session keeps a ''list future sessions to transition to'' this is equivalent to the list of ''confirmed but yet to join users''. If the extension discussed in section VIII.3 is enabled it will make use of this list to implement the following changes:<br />
* When a user send a message ''Extended Send'' is invoked instead, it sends the message to the session using ''Send'' but also to the prospective participants, using ''P2P Send''.<br />
* When a message is received, ''Extended Receive'' is called which check if the user has the correct key to decrypt the message. If the message is encrypted by session key and user has the session key then it calls the normal receive. If the message is encrypted by a p2p key that the user share, it calls ''P2P Receive''. Otherwise, it simply ignores the message.<br />
<br />
'''Algorithm 9.1 Extended Send'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right" | If we are part of a session id in the room call ''Send''<br />
|align="center"| Send<br />
|align="center"| Broadcast<br />
|-<br />
|align="right"| For all confirmed users not in session call ''P2P Send''<br />
|align="center"| P2P Send<br />
|align="center"|Broadcast<br />
|}<br />
<br />
'''Algorithm 9.2 Extended Receive'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right" | If ''m'' has session id call ''Receive''<br />
|align="center"| if ''m'' has ''sid'' then Receive<br />
|align="center"| Computation<br />
|-<br />
|align="right"| If ''m'' has key id, call ''P2P Receive''<br />
|align="center"| P2P Send<br />
|align="center"|Computation<br />
|}<br />
<br />
'''Algorithm 9.3 P2P Send'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right" | Prepend key id and sender id<br />
|align="center"|<math> m \leftarrow (key\_id, U_i, m) </math><br />
|align="center"|Computation<br />
|-<br />
|align="right" |Generate a random nuance and append to the message<br />
|align="center"|<math> m \leftarrow (m, rand(128bit)) </math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Sign the message and append the signature<br />
|align="center"|<math> m \leftarrow (m, Sign_{x_i}(m))</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"|Encrypt<br />
|align="center"|<math>e \leftarrow Enc_{k_{key\_id}}(m)</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Broadcast the message<br />
|align="center"|<math>(key\_id, e)</math><br />
|align="center"|Broadcast<br />
|}<br />
<br />
'''Algorithm 9.4 P2P Receive'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right"| Decrypt message<br />
|align="center"|<math> key_{id}, sender\_id, m, sigma \leftarrow Dec_{k_{key\_id}}(m) </math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Check signature<br />
|align="center"|<math> Verify_{sender\_id}(m,\sigma) </math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| return m<br />
|align="center"|return ''m''<br />
|align="center"|Computation<br />
|}<br />
<br />
===VIII.6 Reaching Consistency ===<br />
<br />
The protocol provisions two procedures to reach consistency in different cases: (a) reaching consistency for arbitrary messages during the course of a conversation, and (b) reaching consistency when an instance <math>\Pi^S_i</math> leaves. Case (b) may be viewed as a special instance of case (a) plus the additional premise that <math>\Pi^S_i</math> must reach consistency as soon as possible (because they want to leave), and that they don't care about reaching consistency for any subsequent messages that they might receive after their final "farewell" message.<br />
<br />
Reaching consistency for arbitrary messages during the course of a conversation:<br />
<br />
'''Algorithm 10'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right"| Receive ''m'' with parent ''p'' from <math>\Pi^S_j</math><br />
|align="center"|<math> m \leftarrow seqnum(M), p \leftarrow parentnum(m)</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Compare hash of TranscriptChain_j[p] with own value of it, issue a warning if it fails.<br />
|align="center"|<math>H(TranscriptChain^S_j[p]) \stackrel{?}{=} H(TranscriptChain^S_i[p])</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Compute TranscriptChain^S_i[m] <br />
|align="center"|<math>plist \leftarrow [U_i]</math><br />
|align="center"|Computation<br />
|}<br />
<br />
Case '''(b)''': when an instance <math>\Pi^S_i</math> wants to part, they send a "farewell" message ''m'' which contains <math>Hash(TranscriptChain^S_i[p])</math>.<br />
* Everyone should include <math>Hash(TranscriptChain_j[p])</math> in their re-key message<br />
* When ''<math>\Pi^S_i</math>'' reaches mutual consistency for p may leave or otherwise (if received hashes and their owns are non-matching) shows a warning.<br />
** <math>\Pi^S_i</math> won't have a chance to reach consistency for the messages receives after ''p''<br />
<br />
===VIII.7 In-session Forward Secrecy===<br />
To ensure forward secrecy in long living chat sessions, ''(n+1)sec'' provides a session key update throughout the session. Each message sent to the session by each participant contains meta data described in [[#VIII.5.1 (n+1)sec Message Structure]]. Prior to sending any message, ''(n+1)sec'' determines the content of meta data, and piggy backs to that message according to the following algorithm:<br />
<br />
'''Algorithm 10.1 Compute meta data'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right"| Initiate meta data with current state of knowledge of new ephemeral keys and secret shares<br />
|align="center"|<math> meta\_data \leftarrow ustate_i[j]</math> for all ''j'' in {1,...''n}<br />
|align="center"|Computation<br />
|-<br />
|align="right"| Include the new ephemeral key if participant <math>U_j</math> has not receive it<br />
|align="center"|If <math>ustate_i[j] \stackrel{?}{=} 0</math> ''meta_data'' \leftarrow <math>y_{i_{new}}</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| If (all) participants have sent their ephemeral keys compute the shared secret<br />
|align="center"|If <math>ustate_{j}[i] \stackrel{?}{=} 1</math> for all ''j''<br />
in {1,...''n}, then <math> meta\_data \leftarrow (meta\_data, GroupEnc(k_{i_j} for j \in \{1,\dots,n\}, z'))</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Return meta data<br />
|align="center"|return ''meta_data''<br />
|align="center"|Computation<br />
|}<br />
<br />
===VIII.8 Heartbeat and Timeout ===<br />
<br />
Heartbeat is an empty message which contains only meta data. The meta data consists of information used to compute a new key and the most updated hash of transcript chain.<br />
<br />
The protocol sends a heart beat only if the user has not sent any messages for a specific period of time.<br />
<br />
The heartbeat is necessary to ensure three properties:<br />
<br />
- Periodic transcript consistency check.<br />
- In session forward secrecy.<br />
- Freshness<br />
<br />
To achieve these goals three time out periods are defined when heart beat sending is required. Additionally, we define an interval to model the latency in the underlying transport. These should be defined to cover common cases (e.g. 95th-percentile):<br />
<br />
* ACK_GRACE_INTERVAL: When <math>\Pi^S_i</math> a receives a non-empty message it needs to inform the group about the transcript update no later than ACK_GRACE_INTERVAL time. Therefore if <math>\Pi^S_i</math> f <math>U_i</math> does not send a message ACK_GRACE_INTERVAL seconds after receiving a non empty message,<math>\Pi^S_i</math> will send a heartbeat.<br />
<br />
* REKEY_GRACE_INTERVAL, to ensure in session forward secrecy, the protocol requires that each <math>U_i</math> updates their DH ephemeral key as well as group key. After a session is established or it was rekeyed, each <math>\Pi^S_i</math> needs to send its new DH ephemeral key no later than REKEY_GRACE_INTERVAL. Therefore if <math>\Pi^S_i</math> has not sent any message by that<br />
period of time, it issues an empty message. Similarly after receiving all ephemeral keys from all participants, <math>\Pi^S_i</math> needs to send its secret for computation of new key no later than REKEY_GRACE_INTERVAL.<br />
<br />
* INTERACTION_GRACE_INTERVAL, to ensure establishment of a session in timely manner, when immediate contribution of participants is required (for example sending key confirmation, contribution to the session secret), this values indicate that how long an active participants should wait till it decide to drop the non-contributing inactive participants from the participant list.<br />
<br />
* BROADCAST_LATENCY: Modelling the amount of time which a message takes to reach the server and broadcast to the other clients. It should be based on the transport considered.<br />
<br />
==== Failure to heartbeat and inactivity timers ====<br />
<br />
Whenever, a message ''m'' is received a timer of (2*BROADCAST_LATENCY)+ACK_GRACE_INTERVAL) period is set. If the <math>H(Transcript_j[m'])</math> for a <math>m' \ge m</math> is received from all participants, the timer is cancelled. Otherwise at the time out, the protocol issues a local UI warning and cancel the warning if/when such a hash is received and is consistence among participants.<br />
<br />
When a new session key is computed as well as when <math>\Pi^S_i</math> receives new ephemeral DH values from all users, a timer of (2*BROADCAST_LATENCY)+REKEY_GRACE_INTERVAL period is set. It is cancelled when all user contributions are received (ephemeral keys or session key secrets). Otherwise, the <math>\Pi^S_i</math> excludes users who failed to contribute from the <math>plist</math> exclude those users from the plist and call '''initiate new session'''. This measure is taken to ensure that users do not block in-session forward secrecy due to loss of connection or being under attack.<br />
<br />
==== Timing out during an interactive session ====<br />
<br />
''(n+1)sec'' by design assumes the participants are trusted in being commited to the goal fo creating a secure chatroom. In this sense, ''(n+1)sec'' provide little defens against party which trying to sabotage a room by mounting various denial of service approaches. However, there are situation where a party is genuinely affected (by external adversary) or by connection problem. Under such assumption, situations we expect that all other parties, reach a consensus, that a participant has connectivity problem and agree on leave them out of the room.<br />
<br />
Timeout sub protocol is designed to deal with such a situation. When a new session is requested (for join, leave, etc) each participant wait for (2*BROADCAST_LATENCY)+INTERACTION_GRACE_INTERVAL, they omit non-participating participants from the plist, and wait for PLIST_UPDATE_GRACE_INTERVAL. so other participants also reach to the same conclusion and updates their plists, then they initiate a new session.<br />
<br />
==== Drop inactive users, queue a new session request ====<br />
'''Algorithm 10.XX'''<br />
<br />
{| border="1" cellspacing="0" cellpadding="5" align="center"<br />
!align="right"|Description<br />
!align="center"|Pseudo-code<br />
!align="center"|Type<br />
|-<br />
|align="right"| Drop inactive users<br />
|align="center"|<math> plist_i \leftarrow plist_i \backslash inactive\_participant\_list</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Recompute Session Id<br />
|align="center"|<math>sid_i \leftarrow H(U_1|y_1|\dots|U_{n_{active}}|y_{n_{active}})</math><br />
|align="center"|Computation<br />
|-<br />
|align="right"| Set up timer to request a new session<br />
|align="center"|SetTimer(PLIST_UPDATE_GRACE_INTERVAL, initiate new session)<br />
|align="center"|Computation<br />
|}<br />
<br />
When a participant receives a request for initiating new session, it checks their most current view of participant list (the one with eliminated timed out users) and if it matched then they go ahead with initiating the session, otherwise decline halt the request.<br />
<br />
= '''IX Cryptographic Primitives''' =<br />
<br />
==IX.1 Hash Function==<br />
SHA256 is being used as the hash function and the random oracle. SHA256 provides a sufficiently secure hash primitive for the level of security provided by ''(n+1)sec'' and is widely implemented.<br />
<br />
==IX.2 Message Origin Authentication ==<br />
ED25519 has been chosen as the signature primitive due to its efficiency and more secure implementability over other elliptic-curve digital signature algorithms. [Be11]<br />
<br />
==IX.3 Message Encryption ==<br />
We are using AES-256 in Galois/Counter Mode (GCM) with a shared group key for message encryption, we are following the suggestion by the original OTR protocol of using counter mode. However, unlike OTR, <math>(n+1)sec</math> does not support per message forgeability (although the whole transcript is forgeable), it is not prohibitive to use the same key for encryption and authentication.<br />
<br />
The added authentication, spares P@P send and receive routines from using digital signature.<br />
<br />
With GCM mode, the authenticated encryption is generically secure by the result (and assumptions) of [Kr00].<br />
<br />
==IX.4 GroupEnc and GroupDec Functions ==<br />
The ''GroupEnc'' and ''GroupDec'' functions defined in Section VIII.1, facilitate the collective generation of a secret(s) shared by the group. Here we mention two examples of such functions, and specify the functions for ''(n+1)sec' protocol:<br />
<br />
* '''Naive peer-to-peer GroupEnc/Dec''':<br />
The simplest path to design such primitives is to encrypt <math>z'_i</math> using the p2p encryption secret between each pair of participants:<br />
<br />
<math>GroupEnc((k_{i,1},...,k_{i,n}),z'_i) := (E_{k_{i,1}}(z'_i),...,E_{k_{i,n}}(z'_i))</math><br />
<math>GroupDec((k_{i,1},...,k_{i,n}),(z_1,...,z_n)) := (D_{k_{i,1}}(z_1[i]),...,D_{k_{i,n}}(z_n[i]))</math><br />
<br />
* '''Linear System based GroupEnc/Dec''':<br />
<br />
Another possibility is that each user generates k linear equations of l variables such if the system of <math>k.n</math> equations has m independent equations then m < l. The remaining equations should be generated using the mutual secrets <math>k_{i,j}</math>.<br />
<br />
An example of such a system is used by [BuDe95]. In which <math>k = 1, l = n+1, m = n</math> as follows:<br />
<br />
Each user U_i generate equations (k_{i,i-1}+k_{i,i+1}=a_i) so the system for n equation <math>n+1</math> variable will be:<br />
<br />
<math>\matrix{ x_1 + x_2 = a_1 \\<br />
x_2+x_3= a_2 \\<br />
\vdots \\<br />
x_n + x_{n-1} = a_n \\}</math><br />
<br />
Then each participant adds the equation of <math>x_i = k_{i,i+1}</math> to the system and solves the derived system of <math>n+1</math>-equation <math>n+1</math>-unknown to recover the secrets.<br />
<br />
in such a system:<br />
<br />
<math>z'_i := k_{i,i-1} = k{i-1,i}</math><br />
<math>GroupEnc((k_{i,1},...,k_{i,n}),z'_i, z'_{i+1}) := z'_{i} \oplus z'_{i+1}</math><br />
<br />
''(n+1)sec'' uses the modification of the primitive suggested in [ACMP10] to guard the confidentiality of the p2p and the subgroup keys:<br />
<br />
<math><br />
z'_i := H(k_{i,i-1}, sid_i)<br />
</math><br />
<br />
While the naive peer to peer primitive is easier to understand and analyse, the second system gives the flexibility for the implementor to decide the trade off between the amount of data (number of equations) vs. the redundancy in the system (if some equations are not delivered the user can still compute a subset of secrets).<br />
<br />
= X. Next Steps =<br />
<span style="font-size:200%">T</span>his document is the first public draft of the ''(n+1)sec'' protocol. We are genuinely hoping to receive a lot of feedback and review on this work and have chosen the wiki format to support [[Talk:Nsec|Discussion]]. Ongoing tasks for the team include mathematical proofs of resistance to the adversarial model presented herein as well as technical implementation details. This is currently scheduled for the end of December, 2014. The [https://github.com/equalitie/np1sec np1sec] software library will be initially implemented in [https://github.com/cryptocat/cryptocat/ Cryptocat] and (with your help) further developed to suit a variety of use-cases in the near future.<br />
<br />
= XI. Acknowledgements =<br />
The eQualit.ie team would like to give special thanks and note to the effort and dedication offered by Trevor Perrin and Ximin Luo to this project. They have been actively involved throughout the year and the result would not have been the same without their contribution. The team would also like to express thanks to Joseph Bonneau for his constructive comment and critisim to improve the protocol and its presentation. George Kadianakis for helping with the security proof and pointing out flaws and attack; Arlo Breault for his work on implementation of the protocol in the [https://github.com/equalitie/np1sec np1sec] software library; David Goulet for valuable advice as well as continued assistance and support offered to the project; Prof. Payman Mohassel for his help and advice on the security model and the proof; Prof. Jermey Clark, Prof. Matthew Green and Frederic Jacobs for their constructive participation in the design debates; Prof. Mark Manulis for suggesting the GKA. eQualit.ie expresses gratitude to Nadim Kobeissi, Cryptocat founder and developer who initiated the project and for sharing his experience and giving advice on secure browser based chat. Last but not least we would like to thank the Open Technology Fund for supporting the project.<br />
<br />
= XII. References =<br />
<br />
<div class="references"><br />
<br />
<HarvardReferences><br />
<br />
[*ACMP10] Michel Abdalla, Céline Chevalier, Mark Manulis, and David Pointcheval. “Flexible Group Key Exchange with on-Demand Computation of Subgroup Keys.” In ''Third African International Conference on Cryptology (AfricaCrypt ’10)'', edited by Dan Bernstein and Tanja Lange, 6055:351–368. LNCS. Stellenbosch, South Africa, 2010: Springer. <br />
<br />
[*Be11] Bernstein, Daniel J.; Duif, Niels; Lange, Tanja; Schwabe, Peter; Yang, Bo-Yin. "High-Speed High-Security Signatures.","CHES","978-3-642-23950-2","http://dblp.uni-trier.de/db/conf/ches/ches2011.html#BernsteinDLSY11". 2011. pages: 124-142","6917","Lecture Notes in Computer Science","Springer".<br />
<br />
[*BS07] Bohli, Jens-Matthias, and Rainer Steinwandt. 2007. “Deniable Group Key Agreement.” In ''VIETCRYPT'', edited by Phong Q. Nguyen, 4341:298–311. Lecture Notes in Computer Science. Springer. http://dblp.uni-trier.de/db/conf/vietcrypt/vietcrypt2006.html#BohliS06.<br />
<br />
[*BVS05] Bohli, Jens-Matthias, Maria Isabel Gonzalez Vasco, and Rainer Steinwandt. 2005. “Secure Group Key Establishment Revisited.” ''IACR Cryptology ePrint Archive'' 2005: 395. http://dblp.uni-trier.de/db/journals/iacr/iacr2005.html#BohliVS05a.<br />
<br />
[*BM] Bonneau, Joseph, and Andrew Morrison. “Finite-State Security Analysis of OTR Version 2.” http://www.jbonneau.com/doc/BM06-OTR_v2_analysis.pdf<br />
<br />
[*BGB04] Borisov, Nikita, Ian Goldberg, and Eric Brewer. 2004. “Off-the-Record Communication, or, Why Not to Use PGP.” In ''Proceedings of the 2004 ACM Workshop on Privacy in the Electronic Society'', 77–84. WPES ’04. New York, NY, USA<br />
<br />
[*BCGNP08] Colin Boyd, Yvonne Cliff, Juan Gonzalez Nieto, and <span>KennethG.</span> Paterson. 2008. “Efficient One-Round Key Exchange in the Standard Model.” In ''Information Security and Privacy'', edited by Yi Mu, Willy Susilo, and Jennifer Seberry, 5107:69–83. Lecture Notes in Computer Science. Springer Berlin Heidelberg.<br />
<br />
[*BoMa10] Boyd, Colin; Mathuria, Anish. "Protocols for Authentication and Key Establishment","3642077161, 9783642077166",2010, Springer Publishing Company, Incorporated, 1st edition<br />
<br />
[*BCP01] Emmanuel Bresson, Olivier Chevassut, and David Pointcheval. 2001. “Provably Authenticated Group Diffie-Hellman Key Exchange - the Dynamic Case.” In ''Advances in Cryptology - Proceedings of ASIACRYPT ’01'', edited by Colin Boyd, 2248:290–309. LNCS. Gold Coast, Australia: Springer. <br />
<br />
[*BCPQ01] Emmanuel Bresson, Olivier Chevassut, David Pointcheval, and Jean-Jacques Quisquater. 2001. “Provably Authenticated Group Diffie-Hellman Key Exchange.” In ''Proceedings of the 8th ACM Conference on Computer and Communications Security (CCS ’01)'', edited by Mike Reiter, 255–264. Philadelphia, Pennsylvania.<br />
<br />
[*CaKr01] Ran Canetti, Hugo Krawczyk. 2001. “Analysis of Key-Exchange Protocols and Their Use for Building Secure Channels” “EUROCRYPT Conference. Lecture Notes in Computer Science”. Edited by Birgit Pfitzmann. <br />
<br />
[*Da14] George Danezis, Should Group Key Agreement be Symmetric and Contributory, http://conspicuouschatter.wordpress.com/2014/06/28/should-group-key-agreement-be-symmetric-and-contributory/<br />
<br />
[*Da02] Davis, Don,"Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML.","USENIX Annual Technical Conference, General Track","1-880446-09-X","http://dblp.uni-trier.de/db/conf/usenix/usenix2001g.html#Davis01","2002-09-022001", page 65-78<br />
<br />
[*GUVGC09] Ian Goldberg, Berkant Ustao<span>\</span>uglu, Matthew D. Van Gundy, and Hao Chen. 2009. “Multi-Party Off-the-Record Messaging.” In ''Proceedings of the 16th ACM Conference on Computer and Communications Security'', 358–368. CCS ’09. New York, NY, USA: ACM. <br />
<br />
[*GBN10] M. Choudary Gorantla, Colin Boyd, and Juan Manuel González Nieto. 2010. ''One Round Group Key Exchange with Forward Security in the Standard Model''. http://eprint.iacr.org/2010/083.pdf<br />
<br />
[*GBNM11] M. Choudary Gorantla, Colin Boyd, Juan Manuel González Nieto, and Mark Manulis. 2011. “Modeling Key Compromise Impersonation Attacks on Group Key Exchange Protocols.” 'ACM Trans. Inf. Syst. Secur.<br />
<br />
[*Gun13a] Matthew Van Gundy. April 2013. “[OTR-dev] Improved Deniable Signature Key Exchange for mpOTR.” <br />
http://matt.singlethink.net/projects/mpotr/improved-dske.pdf<br />
<br />
[*Gun13b] Matthew Van Gundy March 2013. “[OTR-dev] Improved Deniable Signature Key Exchange for mpOTR.”<br />
http://lists.cypherpunks.ca/pipermail/otr-dev/2013-March/001676.html.<br />
<br />
[*Kr00], "Krawczyk, Hugo","The order of encryption and authentication for protecting communications (Or: how secure is SSL?), 2001, Published: Cryptology ePrint Archive, Report 2001/045 http://eprint.iacr.org/<br />
<br />
[*KPW13] Hugo Krawczyk and Kenneth G. Paterson, Hoeteck Wee. 2013. “On the Security of the TLS Protocol: A Systematic Analysis” in<br />
''IACR Cryptology ePrint Archive''.<br />
<br />
[*LVH13] Liu, Hong; Vasserman, Eugene Y.; Hopper, Nicholas. "Improved Group Off-the-record Messaging" from the ''Proceedings of the 12th ACM Workshop on Workshop on Privacy in the Electronic Society'', 978-1-4503-2485-4, 'ACM', New York, NY, USA. 2013<br />
<br />
[*Mo13] Marlinspike, Moxie,"Simplifying OTR deniability" blogpost, Open Whispersystems, https://whispersystems.org/blog/simplifying-otr-deniability/<br />
<br />
[*Sys14] Marlinspike, Moxie et al. Whisper Systems. 2014. “TextSecure ProtocolV2.” Accessed March 2. https://github.com/WhisperSystems/TextSecure/wiki/ProtocolV2.<br />
<br />
[*RGK05] Mario Di Raimondo, Rosario Gennaro, and Hugo Krawczyk. 2005. “Secure Off-the-Record Messaging.” In ''WPES'', 81–89. Alexandria, VA, USA. http://dl.acm.org/citation.cfm?doid=1102199.1102216<br />
<br />
[*KiSo00] Song, Boyeon; Kim, Kwangjo, "Two-Pass Authenticated Key Agreement Protocol with Key Confirmation","Progress in Cryptology —INDOCRYPT 2000","978-3-540-41452-0","http://dx.doi.org/10.1007/3-540-44495-5_21","2000"; "237-249",1977 "Lecture Notes in Computer Science",Springer Berlin Heidelber.<br />
<br />
[*Git11] https://github.com/hellais/cryptocat<br />
<br />
</HarvardReferences><br />
<br />
</div><br />
<br />
=Appendices=<br />
<br />
==Appendix A: Asynchronous communication and Forward Secrecy==<br />
<br />
The protocol is primarily targeted to synchronous cases, however, with some modification it can be used for asynchronous cases.<br />
<br />
Provided that the participants are not concerned with authenticating the list of participants (it is OK if Eve impersonates Bob as long as she is unable to read Bob’s messages). Participants can communicate using their pairwise exchanged ephemeral Diffie-Hellman keys until all participants finish the second round of authentication.<br />
<br />
As soon as a deniable handshake has been established among a set of participants any subset of them can communicate and authenticate their messages using the “session key” and their ephemeral signature key.<br />
<br />
The protocol does not enforce explicitly a time limit on renewing the session key shares and can be used for an asynchronous high latency transport after the key establishment state.<br />
<br />
The downside of using a session key for a long time is that a compromised session key will reveal all past communication during that session. This does not pose an imminent threat when the life span of a chat is short. However, in the context of asynchronous high latency transport, it is a more serious concern.<br />
<br />
The protocol requires the participants to pre-emptively update their ephemeral signature/shares and propagate them as part of the messages they are already sending. Subsequently, they also update their key share with their neighbours as soon as the neighbours also propagate their new ephemeral signature keys.<br />
<br />
As the assumption of having a continuous heartbeat might not be realistic in various asynchronous cases, implementations can assume specific deadlines for dropping users who did not communicate their new keys or shares.<br />
<br />
==Appendix B: Other design possibilities==<br />
During the process of designing ''(n+1)sec'' we have considered and debated other design possibilities which we will describe in this section along side our arguments in favour of the choices made.<br />
<br />
===Group Key Scheme vs Broadcast Scheme===<br />
We say a group key scheme (as defined in [[#V._Chat_Session_Model|Section V]]) is correct if all accepted instances of <math>\Pi^S_i</math> end up with the same participant lists <math>plist_i</math> and compute the same session id. <br />
<br />
By contrast, a broadcast scheme refers to a scheme in which each participant is broadcasting a message to a set of participants of their choice from a set of potential participants. Each participant will have its own different <math>plist_i</math> which is able to broadcast as well. See GOTR by [LVH13] For an example of such scheme where each participant chooses there own circle of audiances. <!--In such protocol we define <math>plist_{union} := \cup{i \in {interested participants}} plist_i</math>.--> <br />
<br />
Therefore, in the context of a chat room, broadcasting scheme participants do not have the same view of the room and consequently we cannot compute a unified session id <math>sid</math> based on the list of the participants (as opposed to the group key scheme). In a group key scheme, it is the name of the chat room plus a set of ephemeral keys and the set of ephemeral public keys which uniquely identifies the session. There are advantages and disadvantages to each of these schemes, which we enumerate here:<br />
<br />
# Chat room simulation: A group scheme simulates a normal chat room in the absence of an authentication adversary, where the participants all have the same view of who is in the chat room when they start talking. This is not the case in a broadcasting scheme as participants keep different participant lists. This is in conflict with the security assumptions of the authentication properties from the original proposal for ''(n+1)sec''.<br />
# Consistency: In a group key exchange, the consistency of the participant list (and session id) is provided by the group key exchange protocol. In such a protocol, extra measures need to be taken only to assure the transcript's consistency, i.e. verification of the consistency of delivery and order of messages exchanged between participants. In a broadcast scheme, a new notion needs to be defined and enforced so that a minimum consistency of a conversation can be simulated. For example, as broadcasting to a subset of potential participants is allowed, the notion needs to deal with a situation in which A receives the DH public key of B but wants to send a message to the "room" before it receives the DH key of C.<br />
# Delayed join and leave: In a group scheme, until all participants confirm their identical view of a new participant list (due to a member joining or leaving the room), they need to assume the status quo. This might delay a new participant from joining a chat or, if no further measure is taken, enable a participant to deny join/leave for the whole group. While various mitigation methods are possible against such attacks (all summarized under the umbrella term "Denial of Service" ) they are not included in threat model considered in ''(n+1)sec'' protocol. <br />
<br />
Based on the above differences, we selected a group key scheme for the proposed protocol. This is primarily because room consistency is one of the main security properties desired. However, when it is critical, the sub-protocol described by [[#Sending_and_receiving_messages_ while_joining_is_in_progress|Section VIII.2 Sending and receiving messages while joining is in progress]] allows for communication with users while they are waiting for the join procedure to complete.<br />
<br />
===Participatory vs individually independent computation of group key(s)===<br />
Most AKGE offer some degree of contributiveness in computing the group secret. This roughly means that (at least in the absence of an insider) the group secret is derived using contribution from all members of the group. There has been criticism of the importance of this property such as in [Da14]. In this section we consider briefly the arguments for each side and describe the rational for our choice.<br />
<br />
[[Category: np1sec]]</div>Billhttps://learn.equalit.ie/wiki/Secure_connectionsSecure connections2014-05-28T19:10:47Z<p>Bill: </p>
<hr />
<div>When communicating data to/from a server it is important that the infromation not be susceptible to man-in-the-middle attacks. If data is communicated over open, plain text mediums such as FTP or HTTP then that data can be intercepted and read by any entity on any of the networks that the information passes through; this can included Local Area Networks, ISPs, or National Entities<br />
<br />
There are a number of steps that can be taken to protect communication channels to and from the server, though no system is 100% secure.<br />
<br />
<ol><br />
<li><br />
'''SSL'''<br />
If your website does not have an SSL certificate then all web traffic direct to your site will be unencrypted and potentially subject to snooping, either at the ISP level, at the level of your hosting provider or at a level that specifically targets your site's users locally (ie: local interception of their communications on a coffee shop's wireless network). <br />
<br />
Secure Socket Layer(SSL) is a cryptographic protocol which allows secure client-server interactions. Once a secure session has been established between the client, for example your web browser, and the server, your website in this case, all the information that passes between the two is unreadable to external parties.<br />
<br />
In order, to provide SSL for your website you must purchase an SSL certificate. This is a digital document that is signed by a recognised certificate reseller that uniquely belongs to your domain. <br />
<br />
An added benefit of SSL certificates is that they can aid in preventing SSL spoofing. This occurs where a malicious websites pretend to be a legitimate website or a server pretends to be a legitimate holder of the SSL cert. <br />
<br />
Most modern browsers will give a warning if an SSL cert has expired or is invalid - as in that it may be a spoof certificate.<br />
<br />
One of the most commonly used SSL software packages on the Internet, OpenSSL, suffered a major security flaw in the shape of the [http://heartbleed.com/ Heart Bleed bug]. This left most websites using a certain version of OpenSSL open to an exploit. This incident highlights that no technology is 100% secure and requires constant monitoring.<br />
<br />
</li><br />
<li><br />
'''SFTP'''<br />
When transfering files to or from a remote server it is integral to security to use an SFTP client. This stands for Secure File Tranfer Protocol. In a similar manner to SSL it ensures that the communications to and from the server are not open to external individuals.<br />
<br />
An excellent client is [http://cyberduck.io/ Cyberduck]<br />
</li><br />
<li><br />
'''SSH'''<br />
When connecting directly to a server, for example for command line access, it is imperative to use the Secure SHell protocol. As the telnet protocol provides no level of security and should be disabled. For further information see [http://www.openssh.com/ openSSH docs].<br />
<br />
For windows a good client is [http://www.putty.org/ putty] for mac and linux the Terminal can be used.<br />
</li><br />
<ol></div>Billhttps://learn.equalit.ie/wiki/Choose_a_hosting_providerChoose a hosting provider2014-05-28T19:06:39Z<p>Bill: </p>
<hr />
<div>__NOTOC__<br />
===Criteria===<br />
<br />
There are several aspects which should be considered when selecting a service host. Below is a general list, this [https://pad.riseup.net/p/rh_ispq document] gives detailed information on each area. eQualit.ie has developed a [https://wiki.deflect.ca/wiki/ISP_reviews review] of existing providers based on experiences with our Deflect network.<br />
<br />
*Price - for most groups the cost of the infrastructure will be a major determining factor. however, there are a large number of competitive offers and though this is an important factor it should be used as a boundary to decide what is available not as the sole reason to purchase a service.<br />
*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.<br />
*Specialisation - do they work in the field of human rights, software applications or general hosting<br />
*Is mail provided - for many organisation it is not an option to run their own mail server, however, is they do not wish to sue a free service such as [https://riseup.net Riseup] or [https://gmail.com gmail], or if they wish to have domain specific email - such as info@mywebsite.org - then it is worth considering services that provide free email accounts.<br />
*Hardware specifications - does the server fits my needs? For most websites basic servers are enough but websites with high traffic can demand more stable or dedicated hardware.<br />
*Operating systems offered - different operating systems provide different functionality and integration with other applications. They also have different degrees of vulnerability and support.<br />
*Supported provided - this is an essential aspect when choosing a hosting company. It should also be considered in terms of language support, whether support is provided for software and/or hardware issues.<br />
*Readily discusses your security concerns and which security features and processes they offer with their hosting.<br />
*Provides the most recent stable versions of all server software.<br />
*Provides reliable methods for backup and recovery.<br />
*Provides encryption options for hosting of sites or mail<br />
<br />
===Features===<br />
It is quite important to consider the possibilities offered by your provider's control panel. If you need to write a support ticket everytime the server has to reboot, it wont be an efficient process, especially during a crises. Possible features to look out for include<br />
<br />
* Automated operating system installs, this feature is hugely useful if it will be necessary to reinstall the operating system on your server. it avoids the need for dedicated time from one of your team members.<br />
* Server boot and reboot, when installing new applications or updating existing software components, or as a means to resolve an issue, the ability to remotely restart your server can be critical. This is dependent on the type of server you are using. <br />
* Remote console (sometimes known as KVM), this is invaluable in diagnosing issues with your server's physical hardware but equally is a necessity if you wish to perform full disk encryption as a password will have to be entered before the machine has full booted up.<br />
* Server and network statistics, this information helps you track your server and/or website giving you detailed information for debugging, tracking attacks or discovering who is visiting your site.<br />
* Dynamic components (e.g. adding extra disk space, RAM without rebuilding the machine or having to order a new service)<br />
* Server access is the means by which you can physically connect to your server. Options iclude SSH, SSH key, SFTP or web based<br />
<br />
==Secure hosting setups==<br />
Depending on available skill level the following secure system setups are possible:<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===Dedicated Server===<br />
For a [[Dedicated_Hosting | Dedicated Hosting]] system, the user can either run their own physical hardware or rent this hardware from a provider. The former solution offers total control of the physical hardware, however, there are significant downsides to this approach and should be avoided; it is only recommend under special circumstances such as [[Sensitive_Data | storing sensitive data]]. In the latter case, the hosting agent provides the hardware but the user has total control of the server via remote access. In this scenario, the provider is responsible for replacement of hardware parts that fail or malfunction - this support is generally done through a ticket system and relies on the user to report errors.<br />
<br />
'''Examples'''<br />
* http://www.ovh.com/ca/en/dedicated-servers/hosting/<br />
* http://www.soyoustart.com/ie/offers.xml<br />
* http://www.hetzner.de/en/hosting/produktmatrix/rootserver<br />
* http://www.coolhousing.net/hosting-dedicated-servers.html<br />
<br />
'''Benefits'''<br />
*User has total control of the system's software<br />
*User has total control of access rights<br />
*User has control of physical network connection, allowing them to whitelist or block connection from allowed or spurious connections<br />
*Financial cost of hardware malfunction is not an issue as the host is responsible for replacing/repairing failing hardware<br />
*The host can be chosen to place the server in a different jurisdiction from that of the user to prevent seizure<br />
<br />
'''Downsides'''<br />
*The user does not have physical access to the server<br />
*The host is not responsible for data loss or downtime if the physical server fails<br />
*The user is responsible for detecting and reporting hardware faults on some providers<br />
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].<br />
*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.<br />
<br />
===VPS===<br />
A Virtual Private Server(VPS) is an instance of a Virtual Operating System running on a much larger server. Typically multiple VPS will be run on a single server. In a VPS environment, you have a dedicated virtual private server but do not control the server on which it is hosted. Resources will be limited, you can not control or harden the outer server.<br />
<br />
'''Examples'''<br />
* https://www.linode.com/pricing<br />
* https://chhost.net/virtual-server/<br />
* https://www.tilaa.com/orders/add<br />
<br />
'''Benefits'''<br />
*The cost of this type of server will typically be significantly cheaper than a dedicated server<br />
*Depending on the host, the server will be capable of running most standard server software, up to a certain limit<br />
*Hardware is managed by the hosting provider unless self hosting<br />
*If self hosting, a single server can be used for multiple purposes and to provide multiple distinct servers<br />
<br />
'''Downsides'''<br />
*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<br />
*Bandwidth will also be restricted<br />
*Potential risk of provider, law enforcement or other state forces accessing contents of virtual server without user's awareness. <br />
*The user will not have access to the outer server and will thus not be able to harden it<br />
<br />
===Threats===<br />
*Social engineering attack<br />
*Password brute force<br />
*Service interruption through denial of service attack<br />
*System software exploits<br />
*SSL man-in-the-middle attacks<br />
*Data loss or data theft<br />
<br />
===Mitigation===<br />
'''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.<br />
<br />
For more details [[Access_Restrictions#Dedicated/VPS_Hosting| see]]<br />
<br />
'''User Management''' on dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<br />
For more details see [[Access_Restrictions#Dedicated/VPS_HOSTING| see]]<br />
<br />
'''System and Software Management''' is primarily concerned with ensuring that the physical system and its software is setup in the most mangeable, maintainable way and that attention is paid to keeping everything up to date to avoid potential vulnerabilities.<br />
<br />
For more details see [[System_Management| see]]<br />
<br />
'''Webserver Setup''' is an important consideration when hosting a website. There are a variety of steps that can be taken to lock down a webserver and to make sure that no vulnerabilities or accidental leaks occur. <br />
<br />
For more details [[Webserver_setup| see]]<br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted platform===<br />
For organisation that wish to setup their own custom site based on an existing platform such as Wordpress.com, there are a setup of steps that should be taken to ensure a good level of security. The [[Choosing_A_Host | choosing a hosting provider]] guide should also be consulted.<br />
<br />
'''Benefits'''<br />
* Hardware is managed and maintained by the hosting provider<br />
* There is no need to build custom software<br />
* Using an install of an existing platform, such as Wordpress.com, means that software patching and bug fixing is handled by a dedicated group <br />
* Once the solution is setup, secured and configured management is minimal<br />
* The software platform will provide support for the core functionalities of managing a website such as user creation, content uploading and provide mechanisms for exporting/backup<br />
<br />
'''Downsides'''<br />
* The provider must be carefully chosen based on the information in this [https://pad.riseup.net/p/rh_ispq document]<br />
* Software updates must be performed by the organisation<br />
* Backup is the organisations responsibility<br />
* No support is provided for configuring or managing the platform<br />
<br />
'''Platform Security'''<br />
<ol><br />
<li><br />
Limiting access - Making smart choices that reduce possible entry points available to a malicious person.<br />
<br />
For more details see [[Access_Restrictions#Dedicated/VPS_HOSTING| see]]<br />
</li><br />
<li>Containment - Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.<br />
</li><br />
<li>Preparation and knowledge - Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.<br />
</li><br />
<li><br />
Password management - the core component of any digital security strategy is control and management of passwords.<br />
<br />
For more details [[Access_Restrictions#Dedicated/VPS_Hosting| see]]<br />
</li><br />
<li><br />
Software updates and system control - allows the user to lock down the system and restrict what applications are running.<br />
<br />
For more details see [[System_Management| see]]<br />
</li><br />
</ol><br />
<br />
===Shared Hosting===<br />
In a [[Shared_Hosting|Shared Hosting]] environment, your and other website owners shared one server. This includes sharing the physical server and the software applications within the server. Shared hosting services are affordable because the cost to operate the server is shared between you and these other owners. There are, however, a number of down sides, such as being slower.<br />
<br />
'''Examples:'''<br />
* http://www.easyweb.com<br />
* http://www.dreamhost.com/web-hosting/<br />
* http://wpengine.com/ (wordpress only)<br />
<br />
'''Benefits'''<br />
* Host provided support for software and hardware<br />
* Reduced technical needs for organisation<br />
* Standardised software components<br />
<br />
'''Downsides'''<br />
* Heavily relies on the hosting providers technical and support abilities<br />
* Danger that compromise to another unrelated site could compromise user's site.<br />
* Your security is tied to that of others using the same system<br />
* Limited or no control over security procedures - relies heavily on abilities of hosting provider<br />
<br />
===Threat Mitigation===<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
For a basic setup providing a content distribution platform such as a blog users have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
<br />
'''Examples:'''<br />
* [http://wordpress.com/ Wordpress]<br />
* [https://www.tumblr.com/ Tumblr]<br />
* [https://www.journoportfolio.com/ Journo Portfolio]<br />
* [http://www.joomla.org/ Joomla] <br />
<br />
'''Benefits'''<br />
* Host provided support for software and hardware<br />
* Very low technical needs for organisation<br />
* Easy setup and quick start<br />
<br />
'''Downsides'''<br />
* Heavily relies on the hosting providers technical and support abilities<br />
* No control over system software or hardware<br />
* Limited security options<br />
<br />
===Threat Mitigation===<br />
<br />
<ol><br />
<li><br />
'''Strong Passwords''' are a core element of any system. The access password for the host should be restricted to those individuals with the organisation that work directly with the server.<br />
<br />
Safe password creation and storage procedures should be followed, as described [[Access_Restrictions#Dedicated/VPS_Hosting|here]]<br />
</li><br />
<li><br />
'''Malware''' is core vulnerability for the devices used by those managing and logging into the hosted system. Malware, keyloggers and viruses provided a straightforward means of attack.<br />
<br><br />
The attacker does not need to hack or compromise the server, instead via infection through phishing emails or malicious websites the attacker can log and store the passwords and other critical information.<br />
<br><br />
To mitigate this threat all individuals who work with or have login access to the server must have anti-virus installed, a firewall and have an up to date system. For more information [|see]<br />
</li><br />
<li><br />
'''Two factor Authentication''' should be enabled where available as this will make compromising a system significantly more difficult.<br />
</li><br />
<li><br />
'''Wordpress Security''' is described in detail in the following [http://codex.wordpress.org/Hardening_WordPress guide]. <br />
</li><br />
</ol><br />
</div><br />
<br />
</div><br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''Dedicated Server'''<br />
| style="padding: 5px;"| '''Virtual Private Server'''<br />
| style="padding: 5px;"| '''Shared Hosting'''<br />
| style="padding: 5px;"| '''Cloud Service'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Requires Intermediary technical skill<br />
| style="padding: 5px;"| Intermediary/Basic<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows disk/data encryption<br />
| style="padding: 5px;"| Allows encryption within VPS<br />
| style="padding: 5px;"| Limited or no control of data encryption<br />
| style="padding: 5px;"| Depends on provider but usually not provided<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| SSH and private key login<br />
| style="padding: 5px;"| Enforce secure login for VPS<br />
| style="padding: 5px;"| Login via CPanel or Custom interface - some hosts offer 2 factor auth<br />
| style="padding: 5px;"| Depends<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| User access control and restriction<br />
| style="padding: 5px;"| User control<br />
| style="padding: 5px;"| Control via user accounts added through management software<br />
| style="padding: 5px;"| Control via management software<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| Allows only shared SSL cert, most host provide shared cert<br />
| style="padding: 5px;"| Most host platforms will provide SSL support by default<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Total control of applications and software<br />
| style="padding: 5px;"| Control of software within VM, limited access to hardware depending on type of VM<br />
| style="padding: 5px;"| Application control only via management interface<br />
| style="padding: 5px;"| Depends on cloud server - certain services with provide data access restrictions but this is a non-ideal scenario<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Manually maintained and updated<br />
| style="padding: 5px;"| Server is patched but VPS remains responsibility of user<br />
| style="padding: 5px;"| Patches and updates provided by host - though may lag behind depending on quality of hosting<br />
| style="padding: 5px;"| Depending on scale of provider - patching and support will be provided to protect their reputation<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Limited supported - hardware support and replacement depending on provider<br />
| style="padding: 5px;"| Similar to dedicated support<br />
| style="padding: 5px;"| Support is generally in terms of management software - hardware is automatically monitored by hosts<br />
| style="padding: 5px;"| Similar to shared though support is specific to the platform hosting<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Anti-ddos and brute forcing via fail2ban, botnetdbp deployment<br />
| style="padding: 5px;"| Provider may or may not mitigate DDoS attacks<br />
| style="padding: 5px;"| DDoS attacks will receive some or limited mitigation depending on quality of host, generally they will not protect against large scale attacks and may force the website to be removed<br />
| style="padding: 5px;"| Depending on the provider if the attack crosses their threshold for protection they may shut down the website or ask it to leave<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/Webserver_setupWebserver setup2014-05-28T19:01:43Z<p>Bill: </p>
<hr />
<div>===Apache hardening===<br />
<br />
As well as considering the physical server and it's operating system users must thinking in terms of application security. Especially for those applications which either contain sensitive data or those that provide access routes to the machine for an attacker.<br />
<br />
Below is a set of guides for Apache webserver hardening.<br />
<ul><br />
<li><br />
[http://www.tecmint.com/apache-security-tips/ 13 Apache Web Server Security and Hardening Tips]<br />
<li><br />
[http://xianshield.org/guides/apache2.0guide.html Apache 2.0 Hardening Guide]<br />
</li><br />
</ul><br />
<br />
<br />
===Database hardening===<br />
<br />
A key approach discussed elsewhere in protecting data, both at rest - on disk - and in use - in memory, is to encrypt these data stores either as part of full disk encryption or as individual restricted encrypted mount points.<br />
<br />
Below are further guides for specific hardening techniques for the MySQL database system.<br />
<ul><br />
<li><br />
[http://www.greensql.com/content/mysql-security-best-practices-hardening-mysql-tips MySQL Security Best Practices]<br />
</li><br />
<li><br />
[http://rochakchauhan.com/blog/2013/11/19/security-and-hardening-tips-for-mysql/ Security and Hardening Tips for MySQL]<br />
</li><br />
<li><br />
[http://www.securethelock.com/2014/01/09/12-steps-for-hardening-mysql-from-attackers/ 12 steps for Hardening MySQL from Attackers]<br />
</li><br />
</ul></div>Billhttps://learn.equalit.ie/wiki/Webserver_setupWebserver setup2014-05-28T19:01:21Z<p>Bill: </p>
<hr />
<div>===Apache hardening===<br />
<ul><br />
As well as considering the physical server and it's operating system users must thinking in terms of application security. Especially for those applications which either contain sensitive data or those that provide access routes to the machine for an attacker.<br />
<br />
Below is a set of guides for Apache webserver hardening.<br />
<li><br />
[http://www.tecmint.com/apache-security-tips/ 13 Apache Web Server Security and Hardening Tips]<br />
<li><br />
[http://xianshield.org/guides/apache2.0guide.html Apache 2.0 Hardening Guide]<br />
</li><br />
</ul><br />
<br />
<br />
===Database hardening===<br />
<br />
A key approach discussed elsewhere in protecting data, both at rest - on disk - and in use - in memory, is to encrypt these data stores either as part of full disk encryption or as individual restricted encrypted mount points.<br />
<br />
Below are further guides for specific hardening techniques for the MySQL database system.<br />
<ul><br />
<li><br />
[http://www.greensql.com/content/mysql-security-best-practices-hardening-mysql-tips MySQL Security Best Practices]<br />
</li><br />
<li><br />
[http://rochakchauhan.com/blog/2013/11/19/security-and-hardening-tips-for-mysql/ Security and Hardening Tips for MySQL]<br />
</li><br />
<li><br />
[http://www.securethelock.com/2014/01/09/12-steps-for-hardening-mysql-from-attackers/ 12 steps for Hardening MySQL from Attackers]<br />
</li><br />
</ul></div>Billhttps://learn.equalit.ie/wiki/Webserver_setupWebserver setup2014-05-28T19:00:52Z<p>Bill: </p>
<hr />
<div>===Apache hardening===<br />
<br />
As well as considering the physical server and it's operating system users must thinking in terms of application security. Especially for those applications which either contain sensitive data or those that provide access routes to the machine for an attacker.<br />
<br />
Below is a set of guides for Apache webserver hardening.<br />
<li><br />
[http://www.tecmint.com/apache-security-tips/ 13 Apache Web Server Security and Hardening Tips]<br />
<li><br />
[http://xianshield.org/guides/apache2.0guide.html Apache 2.0 Hardening Guide]<br />
</li><br />
</ul><br />
<ul><br />
<br />
===Database hardening===<br />
<br />
A key approach discussed elsewhere in protecting data, both at rest - on disk - and in use - in memory, is to encrypt these data stores either as part of full disk encryption or as individual restricted encrypted mount points.<br />
<br />
Below are further guides for specific hardening techniques for the MySQL database system.<br />
<li><br />
[http://www.greensql.com/content/mysql-security-best-practices-hardening-mysql-tips MySQL Security Best Practices]<br />
</li><br />
<li><br />
[http://rochakchauhan.com/blog/2013/11/19/security-and-hardening-tips-for-mysql/ Security and Hardening Tips for MySQL]<br />
</li><br />
<li><br />
[http://www.securethelock.com/2014/01/09/12-steps-for-hardening-mysql-from-attackers/ 12 steps for Hardening MySQL from Attackers]<br />
</li><br />
</ul></div>Billhttps://learn.equalit.ie/wiki/Choose_a_hosting_providerChoose a hosting provider2014-05-28T19:00:05Z<p>Bill: </p>
<hr />
<div>__NOTOC__<br />
===Criteria===<br />
<br />
There are several aspects which should be considered when selecting a service host. Below is a general list, this [https://pad.riseup.net/p/rh_ispq document] gives detailed information on each area. eQualit.ie has developed a [https://wiki.deflect.ca/wiki/ISP_reviews review] of existing providers based on experiences with our Deflect network.<br />
<br />
*Price - for most groups the cost of the infrastructure will be a major determining factor. however, there are a large number of competitive offers and though this is an important factor it should be used as a boundary to decide what is available not as the sole reason to purchase a service.<br />
*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.<br />
*Specialisation - do they work in the field of human rights, software applications or general hosting<br />
*Is mail provided - for many organisation it is not an option to run their own mail server, however, is they do not wish to sue a free service such as [riseup.net Riseup] or [gmail.com gmail], or if they wish to have domain specific email - such as info@mywebsite.org - then it is worth considering services that provide free email accounts.<br />
*Hardware specifications - does the server fits my needs? For most websites basic servers are enough but websites with high traffic can demand more stable or dedicated hardware.<br />
*Operating systems offered - different operating systems provide different functionality and integration with other applications. They also have different degrees of vulnerability and support.<br />
*Supported provided - this is an essential aspect when choosing a hosting company. It should also be considered in terms of language support, whether support is provided for software and/or hardware issues.<br />
*Readily discusses your security concerns and which security features and processes they offer with their hosting.<br />
*Provides the most recent stable versions of all server software.<br />
*Provides reliable methods for backup and recovery.<br />
*Provides encryption options for hosting of sites or mail<br />
<br />
===Features===<br />
It is quite important to consider the possibilities offered by your provider's control panel. If you need to write a support ticket everytime the server has to reboot, it wont be an efficient process, especially during a crises. Possible features to look out for include<br />
<br />
* Automated operating system installs, this feature is hugely useful if it will be necessary to reinstall the operating system on your server. it avoids the need for dedicated time from one of your team members.<br />
* Server boot and reboot, when installing new applications or updating existing software components, or as a means to resolve an issue, the ability to remotely restart your server can be critical. This is dependent on the type of server you are using. <br />
* Remote console (sometimes known as KVM), this is invaluable in diagnosing issues with your server's physical hardware but equally is a necessity if you wish to perform full disk encryption as a password will have to be entered before the machine has full booted up.<br />
* Server and network statistics, this information helps you track your server and/or website giving you detailed information for debugging, tracking attacks or discovering who is visiting your site.<br />
* Dynamic components (e.g. adding extra disk space, RAM without rebuilding the machine or having to order a new service)<br />
* Server access is the means by which you can physically connect to your server. Options iclude SSH, SSH key, SFTP or web based<br />
<br />
==Secure hosting setups==<br />
Depending on available skill level the following secure system setups are possible:<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===Dedicated Server===<br />
For a [[Dedicated_Hosting | Dedicated Hosting]] system, the user can either run their own physical hardware or rent this hardware from a provider. The former solution offers total control of the physical hardware, however, there are significant downsides to this approach and should be avoided; it is only recommend under special circumstances such as [[Sensitive_Data | storing sensitive data]]. In the latter case, the hosting agent provides the hardware but the user has total control of the server via remote access. In this scenario, the provider is responsible for replacement of hardware parts that fail or malfunction - this support is generally done through a ticket system and relies on the user to report errors.<br />
<br />
'''Examples'''<br />
* http://www.ovh.com/ca/en/dedicated-servers/hosting/<br />
* http://www.soyoustart.com/ie/offers.xml<br />
* http://www.hetzner.de/en/hosting/produktmatrix/rootserver<br />
* http://www.coolhousing.net/hosting-dedicated-servers.html<br />
<br />
'''Benefits'''<br />
*User has total control of the system's software<br />
*User has total control of access rights<br />
*User has control of physical network connection, allowing them to whitelist or block connection from allowed or spurious connections<br />
*Financial cost of hardware malfunction is not an issue as the host is responsible for replacing/repairing failing hardware<br />
*The host can be chosen to place the server in a different jurisdiction from that of the user to prevent seizure<br />
<br />
'''Downsides'''<br />
*The user does not have physical access to the server<br />
*The host is not responsible for data loss or downtime if the physical server fails<br />
*The user is responsible for detecting and reporting hardware faults on some providers<br />
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].<br />
*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.<br />
<br />
===VPS===<br />
A Virtual Private Server(VPS) is an instance of a Virtual Operating System running on a much larger server. Typically multiple VPS will be run on a single server. In a VPS environment, you have a dedicated virtual private server but do not control the server on which it is hosted. Resources will be limited, you can not control or harden the outer server.<br />
<br />
'''Examples'''<br />
* https://www.linode.com/pricing<br />
* https://chhost.net/virtual-server/<br />
* https://www.tilaa.com/orders/add<br />
<br />
'''Benefits'''<br />
*The cost of this type of server will typically be significantly cheaper than a dedicated server<br />
*Depending on the host, the server will be capable of running most standard server software, up to a certain limit<br />
*Hardware is managed by the hosting provider unless self hosting<br />
*If self hosting, a single server can be used for multiple purposes and to provide multiple distinct servers<br />
<br />
'''Downsides'''<br />
*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<br />
*Bandwidth will also be restricted<br />
*Potential risk of provider, law enforcement or other state forces accessing contents of virtual server without user's awareness. <br />
*The user will not have access to the outer server and will thus not be able to harden it<br />
<br />
===Threats===<br />
*Social engineering attack<br />
*Password brute force<br />
*Service interruption through denial of service attack<br />
*System software exploits<br />
*SSL man-in-the-middle attacks<br />
*Data loss or data theft<br />
<br />
===Mitigation===<br />
'''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.<br />
<br />
For more details [[Access_Restrictions#Dedicated/VPS_Hosting| see]]<br />
<br />
'''User Management''' on dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<br />
For more details see [[Access_Restrictions#Dedicated/VPS_HOSTING| see]]<br />
<br />
'''System and Software Management''' is primarily concerned with ensuring that the physical system and its software is setup in the most mangeable, maintainable way and that attention is paid to keeping everything up to date to avoid potential vulnerabilities.<br />
<br />
For more details see [[System_Management| see]]<br />
<br />
'''Webserver Setup''' is an important consideration when hosting a website. There are a variety of steps that can be taken to lock down a webserver and to make sure that no vulnerabilities or accidental leaks occur. <br />
<br />
For more details [[Webserver_setup| see]]<br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted platform===<br />
For organisation that wish to setup their own custom site based on an existing platform such as Wordpress.com, there are a setup of steps that should be taken to ensure a good level of security. The [[Choosing_A_Host | choosing a hosting provider]] guide should also be consulted.<br />
<br />
'''Benefits'''<br />
* Hardware is managed and maintained by the hosting provider<br />
* There is no need to build custom software<br />
* Using an install of an existing platform, such as Wordpress.com, means that software patching and bug fixing is handled by a dedicated group <br />
* Once the solution is setup, secured and configured management is minimal<br />
* The software platform will provide support for the core functionalities of managing a website such as user creation, content uploading and provide mechanisms for exporting/backup<br />
<br />
'''Downsides'''<br />
* The provider must be carefully chosen based on the information in this [https://pad.riseup.net/p/rh_ispq document]<br />
* Software updates must be performed by the organisation<br />
* Backup is the organisations responsibility<br />
* No support is provided for configuring or managing the platform<br />
<br />
'''Platform Security'''<br />
<ol><br />
<li><br />
Limiting access - Making smart choices that reduce possible entry points available to a malicious person.<br />
<br />
For more details see [[Access_Restrictions#Dedicated/VPS_HOSTING| see]]<br />
</li><br />
<li>Containment - Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.<br />
</li><br />
<li>Preparation and knowledge - Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.<br />
</li><br />
<li><br />
Password management - the core component of any digital security strategy is control and management of passwords.<br />
<br />
For more details [[Access_Restrictions#Dedicated/VPS_Hosting| see]]<br />
</li><br />
<li><br />
Software updates and system control - allows the user to lock down the system and restrict what applications are running.<br />
<br />
For more details see [[System_Management| see]]<br />
</li><br />
</ol><br />
<br />
===Shared Hosting===<br />
In a [[Shared_Hosting|Shared Hosting]] environment, your and other website owners shared one server. This includes sharing the physical server and the software applications within the server. Shared hosting services are affordable because the cost to operate the server is shared between you and these other owners. There are, however, a number of down sides, such as being slower.<br />
<br />
'''Examples:'''<br />
* http://www.easyweb.com<br />
* http://www.dreamhost.com/web-hosting/<br />
* http://wpengine.com/ (wordpress only)<br />
<br />
'''Benefits'''<br />
* Host provided support for software and hardware<br />
* Reduced technical needs for organisation<br />
* Standardised software components<br />
<br />
'''Downsides'''<br />
* Heavily relies on the hosting providers technical and support abilities<br />
* Danger that compromise to another unrelated site could compromise user's site.<br />
* Your security is tied to that of others using the same system<br />
* Limited or no control over security procedures - relies heavily on abilities of hosting provider<br />
<br />
===Threat Mitigation===<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
For a basic setup providing a content distribution platform such as a blog users have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
<br />
'''Examples:'''<br />
* [http://wordpress.com/ Wordpress]<br />
* [https://www.tumblr.com/ Tumblr]<br />
* [https://www.journoportfolio.com/ Journo Portfolio]<br />
* [http://www.joomla.org/ Joomla] <br />
<br />
'''Benefits'''<br />
* Host provided support for software and hardware<br />
* Very low technical needs for organisation<br />
* Easy setup and quick start<br />
<br />
'''Downsides'''<br />
* Heavily relies on the hosting providers technical and support abilities<br />
* No control over system software or hardware<br />
* Limited security options<br />
<br />
===Threat Mitigation===<br />
<br />
<ol><br />
<li><br />
'''Strong Passwords''' are a core element of any system. The access password for the host should be restricted to those individuals with the organisation that work directly with the server.<br />
<br />
Safe password creation and storage procedures should be followed, as described [[Access_Restrictions#Dedicated/VPS_Hosting|here]]<br />
</li><br />
<li><br />
'''Malware''' is core vulnerability for the devices used by those managing and logging into the hosted system. Malware, keyloggers and viruses provided a straightforward means of attack.<br />
<br><br />
The attacker does not need to hack or compromise the server, instead via infection through phishing emails or malicious websites the attacker can log and store the passwords and other critical information.<br />
<br><br />
To mitigate this threat all individuals who work with or have login access to the server must have anti-virus installed, a firewall and have an up to date system. For more information [|see]<br />
</li><br />
<li><br />
'''Two factor Authentication''' should be enabled where available as this will make compromising a system significantly more difficult.<br />
</li><br />
<li><br />
'''Wordpress Security''' is described in detail in the following [http://codex.wordpress.org/Hardening_WordPress guide]. <br />
</li><br />
</ol><br />
</div><br />
<br />
</div><br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''Dedicated Server'''<br />
| style="padding: 5px;"| '''Virtual Private Server'''<br />
| style="padding: 5px;"| '''Shared Hosting'''<br />
| style="padding: 5px;"| '''Cloud Service'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Requires Intermediary technical skill<br />
| style="padding: 5px;"| Intermediary/Basic<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows disk/data encryption<br />
| style="padding: 5px;"| Allows encryption within VPS<br />
| style="padding: 5px;"| Limited or no control of data encryption<br />
| style="padding: 5px;"| Depends on provider but usually not provided<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| SSH and private key login<br />
| style="padding: 5px;"| Enforce secure login for VPS<br />
| style="padding: 5px;"| Login via CPanel or Custom interface - some hosts offer 2 factor auth<br />
| style="padding: 5px;"| Depends<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| User access control and restriction<br />
| style="padding: 5px;"| User control<br />
| style="padding: 5px;"| Control via user accounts added through management software<br />
| style="padding: 5px;"| Control via management software<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| Allows only shared SSL cert, most host provide shared cert<br />
| style="padding: 5px;"| Most host platforms will provide SSL support by default<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Total control of applications and software<br />
| style="padding: 5px;"| Control of software within VM, limited access to hardware depending on type of VM<br />
| style="padding: 5px;"| Application control only via management interface<br />
| style="padding: 5px;"| Depends on cloud server - certain services with provide data access restrictions but this is a non-ideal scenario<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Manually maintained and updated<br />
| style="padding: 5px;"| Server is patched but VPS remains responsibility of user<br />
| style="padding: 5px;"| Patches and updates provided by host - though may lag behind depending on quality of hosting<br />
| style="padding: 5px;"| Depending on scale of provider - patching and support will be provided to protect their reputation<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Limited supported - hardware support and replacement depending on provider<br />
| style="padding: 5px;"| Similar to dedicated support<br />
| style="padding: 5px;"| Support is generally in terms of management software - hardware is automatically monitored by hosts<br />
| style="padding: 5px;"| Similar to shared though support is specific to the platform hosting<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Anti-ddos and brute forcing via fail2ban, botnetdbp deployment<br />
| style="padding: 5px;"| Provider may or may not mitigate DDoS attacks<br />
| style="padding: 5px;"| DDoS attacks will receive some or limited mitigation depending on quality of host, generally they will not protect against large scale attacks and may force the website to be removed<br />
| style="padding: 5px;"| Depending on the provider if the attack crosses their threshold for protection they may shut down the website or ask it to leave<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/Choose_a_hosting_providerChoose a hosting provider2014-05-27T18:15:06Z<p>Bill: /* Features */</p>
<hr />
<div>__NOTOC__<br />
===Criteria===<br />
<br />
There are several aspects which should be considered when selecting a service host. Below is a general list, this [https://pad.riseup.net/p/rh_ispq document] gives detailed information on each area. eQualit.ie has developed a [https://wiki.deflect.ca/wiki/ISP_reviews review] of existing providers based on experiences with our Deflect network.<br />
<br />
*Price - for most groups the cost of the infrastructure will be a major determining factor. however, there are a large number of competitive offers and though this is an important factor it should be used as a boundary to decide what is available not as the sole reason to purchase a service.<br />
*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.<br />
*Specialisation - do they work in the field of human rights, software applications or general hosting<br />
*Is mail provided - for many organisation it is not an option to run their own mail server, however, is they do not wish to sue a free service such as [riseup.net Riseup] or [gmail.com gmail], or if they wish to have domain specific email - such as info@mywebsite.org - then it is worth considering services that provide free email accounts.<br />
*Hardware specifications - does the server fits my needs? For most websites basic servers are enough but websites with high traffic can demand more stable or dedicated hardware.<br />
*Operating systems offered - different operating systems provide different functionality and integration with other applications. They also have different degrees of vulnerability and support.<br />
*Supported provided - this is an essential aspect when choosing a hosting company. It should also be considered in terms of language support, whether support is provided for software and/or hardware issues.<br />
*Readily discusses your security concerns and which security features and processes they offer with their hosting.<br />
*Provides the most recent stable versions of all server software.<br />
*Provides reliable methods for backup and recovery.<br />
*Provides encryption options for hosting of sites or mail<br />
<br />
===Features===<br />
It is quite important to consider the possibilities offered by your provider's control panel. If you need to write a support ticket everytime the server has to reboot, it wont be an efficient process, especially during a crises. Possible features to look out for include<br />
<br />
* Automated operating system installs, this feature is hugely useful if it will be necessary to reinstall the operating system on your server. it avoids the need for dedicated time from one of your team members.<br />
* Server boot and reboot, when installing new applications or updating existing software components, or as a means to resolve an issue, the ability to remotely restart your server can be critical. This is dependent on the type of server you are using. <br />
* Remote console (sometimes known as KVM), this is invaluable in diagnosing issues with your server's physical hardware but equally is a necessity if you wish to perform full disk encryption as a password will have to be entered before the machine has full booted up.<br />
* Server and network statistics, this information helps you track your server and/or website giving you detailed information for debugging, tracking attacks or discovering who is visiting your site.<br />
* Dynamic components (e.g. adding extra disk space, RAM without rebuilding the machine or having to order a new service)<br />
* Server access is the means by which you can physically connect to your server. Options iclude SSH, SSH key, SFTP or web based<br />
<br />
==Secure hosting setups==<br />
Depending on available skill level the following secure system setups are possible:<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===Dedicated Server===<br />
For a [[Dedicated_Hosting | Dedicated Hosting]] system, the user can either run their own physical hardware or rent this hardware from a provider. The former solution offers total control of the physical hardware, however, there are significant downsides to this approach and should be avoided; it is only recommend under special circumstances such as [[Sensitive_Data | storing sensitive data]]. In the latter case, the hosting agent provides the hardware but the user has total control of the server via remote access. In this scenario, the provider is responsible for replacement of hardware parts that fail or malfunction - this support is generally done through a ticket system and relies on the user to report errors.<br />
<br />
'''Examples'''<br />
* http://www.ovh.com/ca/en/dedicated-servers/hosting/<br />
* http://www.soyoustart.com/ie/offers.xml<br />
* http://www.hetzner.de/en/hosting/produktmatrix/rootserver<br />
* http://www.coolhousing.net/hosting-dedicated-servers.html<br />
<br />
'''Benefits'''<br />
*User has total control of the system's software<br />
*User has total control of access rights<br />
*User has control of physical network connection, allowing them to whitelist or block connection from allowed or spurious connections<br />
*Financial cost of hardware malfunction is not an issue as the host is responsible for replacing/repairing failing hardware<br />
*The host can be chosen to place the server in a different jurisdiction from that of the user to prevent seizure<br />
<br />
'''Downsides'''<br />
*The user does not have physical access to the server<br />
*The host is not responsible for data loss or downtime if the physical server fails<br />
*The user is responsible for detecting and reporting hardware faults on some providers<br />
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].<br />
*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.<br />
<br />
===VPS===<br />
A Virtual Private Server(VPS) is an instance of a Virtual Operating System running on a much larger server. Typically multiple VPS will be run on a single server. In a VPS environment, you have a dedicated virtual private server but do not control the server on which it is hosted. Resources will be limited, you can not control or harden the outer server.<br />
<br />
'''Examples'''<br />
* https://www.linode.com/pricing<br />
* https://chhost.net/virtual-server/<br />
* https://www.tilaa.com/orders/add<br />
<br />
'''Benefits'''<br />
*The cost of this type of server will typically be significantly cheaper than a dedicated server<br />
*Depending on the host, the server will be capable of running most standard server software, up to a certain limit<br />
*Hardware is managed by the hosting provider unless self hosting<br />
*If self hosting, a single server can be used for multiple purposes and to provide multiple distinct servers<br />
<br />
'''Downsides'''<br />
*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<br />
*Bandwidth will also be restricted<br />
*Potential risk of provider, law enforcement or other state forces accessing contents of virtual server without user's awareness. <br />
*The user will not have access to the outer server and will thus not be able to harden it<br />
<br />
===Threats===<br />
*Social engineering attack<br />
*Password brute force<br />
*Service interruption through denial of service attack<br />
*System software exploits<br />
*SSL man-in-the-middle attacks<br />
*Data loss or data theft<br />
<br />
===Mitigation===<br />
'''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.<br />
<br />
For more details [[Access_Restrictions#Dedicated/VPS_Hosting| see]]<br />
<br />
'''User Management''' on dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<br />
For more details see [[Access_Restrictions#Dedicated/VPS_HOSTING| see]]<br />
<br />
'''System and Software Management'''<br />
<br />
For more details see [[System_Management| see]]<br />
<br />
'''Webserver Setup'''<br />
<br />
For more details [[Webserver_setup| see]]<br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted platform===<br />
For organisation that wish to setup their own custom site based on an existing platform such as Wordpress.com, there are a setup of steps that should be taken to ensure a good level of security. The [[Choosing_A_Host | choosing a hosting provider]] guide should also be consulted.<br />
<br />
'''Platform Security'''<br />
<ol><br />
<li><br />
Limiting access - Making smart choices that reduce possible entry points available to a malicious person.<br />
</li><br />
<li>Containment - Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.<br />
</li><br />
<li>Preparation and knowledge - Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.<br />
</li><br />
<li><br />
Passwords<br />
</li><br />
<li><br />
File Permissions<br />
</li><br />
<li><br />
Admin user<br />
</li><br />
<li><br />
SSL<br />
</li><br />
<li><br />
SFTP client<br />
</li><br />
<li><br />
Platform updates<br />
</li><br />
</ol><br />
Hosting install of pre-built software platform, such as Wordpress,<br />
<br />
===Shared Hosting===<br />
In a [[Shared_Hosting|Shared Hosting]] environment, your and other website owners shared one server. This includes sharing the physical server and the software applications within the server. Shared hosting services are affordable because the cost to operate the server is shared between you and these other owners. There are, however, a number of down sides, such as being slower.<br />
<br />
'''Examples:'''<br />
* http://www.easyweb.com<br />
* http://www.dreamhost.com/web-hosting/<br />
* http://wpengine.com/ (wordpress only)<br />
<br />
===Threat Mitigation===<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
For a basic setup providing a content distribution platform such as a blog users have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
<br />
<br />
===Threat Mitigation===<br />
<br />
<ol><br />
<li><br />
'''Strong Passwords''' are a core element of any system. The access password for the host should be restricted to those individuals with the organisation that work directly with the server.<br />
<br />
Safe password creation and storage procedures should be followed, as described [[Access_Restrictions#Dedicated/VPS_Hosting|here]]<br />
</li><br />
<li><br />
'''Malware''' is core vulnerability for the devices used by those managing and logging into the hosted system. Malware, keyloggers and viruses provided a straightforward means of attack.<br />
<br><br />
The attacker does not need to hack or compromise the server, instead via infection through phishing emails or malicious websites the attacker can log and store the passwords and other critical information.<br />
<br><br />
To mitigate this threat all individuals who work with or have login access to the server must have anti-virus installed, a firewall and have an up to date system. For more information [|see]<br />
</li><br />
<li><br />
'''Two factor Authentication''' should be enabled where available as this will make compromising a system significantly more difficult.<br />
</li><br />
<li><br />
'''Wordpress Security''' is described in detail in the following [http://codex.wordpress.org/Hardening_WordPress guide]. <br />
</li><br />
</ol><br />
</div><br />
<br />
</div><br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''Dedicated Server'''<br />
| style="padding: 5px;"| '''Virtual Private Server'''<br />
| style="padding: 5px;"| '''Shared Hosting'''<br />
| style="padding: 5px;"| '''Cloud Service'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Requires Intermediary technical skill<br />
| style="padding: 5px;"| Intermediary/Basic<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows disk/data encryption<br />
| style="padding: 5px;"| Allows encryption within VPS<br />
| style="padding: 5px;"| Limited or no control of data encryption<br />
| style="padding: 5px;"| Depends on provider but usually not provided<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| SSH and private key login<br />
| style="padding: 5px;"| Enforce secure login for VPS<br />
| style="padding: 5px;"| Login via CPanel or Custom interface - some hosts offer 2 factor auth<br />
| style="padding: 5px;"| Depends<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| User access control and restriction<br />
| style="padding: 5px;"| User control<br />
| style="padding: 5px;"| Control via user accounts added through management software<br />
| style="padding: 5px;"| Control via management software<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| Allows only shared SSL cert, most host provide shared cert<br />
| style="padding: 5px;"| Most host platforms will provide SSL support by default<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Total control of applications and software<br />
| style="padding: 5px;"| Control of software within VM, limited access to hardware depending on type of VM<br />
| style="padding: 5px;"| Application control only via management interface<br />
| style="padding: 5px;"| Depends on cloud server - certain services with provide data access restrictions but this is a non-ideal scenario<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Manually maintained and updated<br />
| style="padding: 5px;"| Server is patched but VPS remains responsibility of user<br />
| style="padding: 5px;"| Patches and updates provided by host - though may lag behind depending on quality of hosting<br />
| style="padding: 5px;"| Depending on scale of provider - patching and support will be provided to protect their reputation<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Limited supported - hardware support and replacement depending on provider<br />
| style="padding: 5px;"| Similar to dedicated support<br />
| style="padding: 5px;"| Support is generally in terms of management software - hardware is automatically monitored by hosts<br />
| style="padding: 5px;"| Similar to shared though support is specific to the platform hosting<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Anti-ddos and brute forcing via fail2ban, botnetdbp deployment<br />
| style="padding: 5px;"| Provider may or may not mitigate DDoS attacks<br />
| style="padding: 5px;"| DDoS attacks will receive some or limited mitigation depending on quality of host, generally they will not protect against large scale attacks and may force the website to be removed<br />
| style="padding: 5px;"| Depending on the provider if the attack crosses their threshold for protection they may shut down the website or ask it to leave<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/Choose_a_hosting_providerChoose a hosting provider2014-05-27T17:30:55Z<p>Bill: </p>
<hr />
<div>__NOTOC__<br />
===Criteria===<br />
<br />
There are several aspects which should be considered when selecting a service host. Below is a general list, this [https://pad.riseup.net/p/rh_ispq document] gives detailed information on each area. eQualit.ie has developed a [https://wiki.deflect.ca/wiki/ISP_reviews review] of existing providers based on experiences with our Deflect network.<br />
<br />
*Price - for most groups the cost of the infrastructure will be a major determining factor. however, there are a large number of competitive offers and though this is an important factor it should be used as a boundary to decide what is available not as the sole reason to purchase a service.<br />
*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.<br />
*Specialisation - do they work in the field of human rights, software applications or general hosting<br />
*Is mail provided - for many organisation it is not an option to run their own mail server, however, is they do not wish to sue a free service such as [riseup.net Riseup] or [gmail.com gmail], or if they wish to have domain specific email - such as info@mywebsite.org - then it is worth considering services that provide free email accounts.<br />
*Hardware specifications - does the server fits my needs? For most websites basic servers are enough but websites with high traffic can demand more stable or dedicated hardware.<br />
*Operating systems offered - different operating systems provide different functionality and integration with other applications. They also have different degrees of vulnerability and support.<br />
*Supported provided - this is an essential aspect when choosing a hosting company. It should also be considered in terms of language support, whether support is provided for software and/or hardware issues.<br />
*Readily discusses your security concerns and which security features and processes they offer with their hosting.<br />
*Provides the most recent stable versions of all server software.<br />
*Provides reliable methods for backup and recovery.<br />
*Provides encryption options for hosting of sites or mail<br />
<br />
===Features===<br />
It is quite important to consider the possibilities offered by your provider's control panel. If you need to write a support ticket everytime the server has to reboot, it wont be an efficient process, especially during a crises. Possible features to look out for include<br />
<br />
* Automated operating system installs, this feature is hugely useful if it will be necessary to reinstall the operating system on your server. it avoids the need for dedicated time from one of your team members.<br />
* Server boot and reboot, when installing new applications or updating existing software components, or as a means to resolve an issue, the ability to remotely restart your server can be critical. This is dependent on the type of server you are using. <br />
* Remote console (sometimes known as KVM), this is invaluable in diagnosing issues with your server's physical hardware but equally is a necessity if you wish to perform full disk encryption as a password will have to be entered before the machine has full booted up.<br />
* Server and network statistics, this information helps you track your server and/or website giving you detailed information for debugging, tracking attacks or discovering who is visiting your site.<br />
* Dynamic components (e.g. adding extra disk space, RAM without rebuilding the machine or having to order a new service)<br />
* Server access (varies between SSH, SFTP or web based)<br />
*<br />
<br />
==Secure hosting setups==<br />
Depending on available skill level the following secure system setups are possible:<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===Dedicated Server===<br />
For a [[Dedicated_Hosting | Dedicated Hosting]] system, the user can either run their own physical hardware or rent this hardware from a provider. The former solution offers total control of the physical hardware, however, there are significant downsides to this approach and should be avoided; it is only recommend under special circumstances such as [[Sensitive_Data | storing sensitive data]]. In the latter case, the hosting agent provides the hardware but the user has total control of the server via remote access. In this scenario, the provider is responsible for replacement of hardware parts that fail or malfunction - this support is generally done through a ticket system and relies on the user to report errors.<br />
<br />
'''Examples'''<br />
* http://www.ovh.com/ca/en/dedicated-servers/hosting/<br />
* http://www.soyoustart.com/ie/offers.xml<br />
* http://www.hetzner.de/en/hosting/produktmatrix/rootserver<br />
* http://www.coolhousing.net/hosting-dedicated-servers.html<br />
<br />
'''Benefits'''<br />
*User has total control of the system's software<br />
*User has total control of access rights<br />
*User has control of physical network connection, allowing them to whitelist or block connection from allowed or spurious connections<br />
*Financial cost of hardware malfunction is not an issue as the host is responsible for replacing/repairing failing hardware<br />
*The host can be chosen to place the server in a different jurisdiction from that of the user to prevent seizure<br />
<br />
'''Downsides'''<br />
*The user does not have physical access to the server<br />
*The host is not responsible for data loss or downtime if the physical server fails<br />
*The user is responsible for detecting and reporting hardware faults on some providers<br />
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].<br />
*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.<br />
<br />
===VPS===<br />
A Virtual Private Server(VPS) is an instance of a Virtual Operating System running on a much larger server. Typically multiple VPS will be run on a single server. In a VPS environment, you have a dedicated virtual private server but do not control the server on which it is hosted. Resources will be limited, you can not control or harden the outer server.<br />
<br />
'''Examples'''<br />
* https://www.linode.com/pricing<br />
* https://chhost.net/virtual-server/<br />
* https://www.tilaa.com/orders/add<br />
<br />
'''Benefits'''<br />
*The cost of this type of server will typically be significantly cheaper than a dedicated server<br />
*Depending on the host, the server will be capable of running most standard server software, up to a certain limit<br />
*Hardware is managed by the hosting provider unless self hosting<br />
*If self hosting, a single server can be used for multiple purposes and to provide multiple distinct servers<br />
<br />
'''Downsides'''<br />
*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<br />
*Bandwidth will also be restricted<br />
*Potential risk of provider, law enforcement or other state forces accessing contents of virtual server without user's awareness. <br />
*The user will not have access to the outer server and will thus not be able to harden it<br />
<br />
===Threats===<br />
*Social engineering attack<br />
*Password brute force<br />
*Service interruption through denial of service attack<br />
*System software exploits<br />
*SSL man-in-the-middle attacks<br />
*Data loss or data theft<br />
<br />
===Mitigation===<br />
'''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.<br />
<br />
For more details [[Access_Restrictions#Dedicated/VPS_Hosting| see]]<br />
<br />
'''User Management''' on dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<br />
For more details see [[Access_Restrictions#Dedicated/VPS_HOSTING| see]]<br />
<br />
'''System and Software Management'''<br />
<br />
For more details see [[System_Management| see]]<br />
<br />
'''Webserver Setup'''<br />
<br />
For more details [[Webserver_setup| see]]<br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted platform===<br />
For organisation that wish to setup their own custom site based on an existing platform such as Wordpress.com, there are a setup of steps that should be taken to ensure a good level of security. The [[Choosing_A_Host | choosing a hosting provider]] guide should also be consulted.<br />
<br />
'''Platform Security'''<br />
<ol><br />
<li><br />
Limiting access - Making smart choices that reduce possible entry points available to a malicious person.<br />
</li><br />
<li>Containment - Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.<br />
</li><br />
<li>Preparation and knowledge - Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.<br />
</li><br />
<li><br />
Passwords<br />
</li><br />
<li><br />
File Permissions<br />
</li><br />
<li><br />
Admin user<br />
</li><br />
<li><br />
SSL<br />
</li><br />
<li><br />
SFTP client<br />
</li><br />
<li><br />
Platform updates<br />
</li><br />
</ol><br />
Hosting install of pre-built software platform, such as Wordpress,<br />
<br />
===Shared Hosting===<br />
In a [[Shared_Hosting|Shared Hosting]] environment, your and other website owners shared one server. This includes sharing the physical server and the software applications within the server. Shared hosting services are affordable because the cost to operate the server is shared between you and these other owners. There are, however, a number of down sides, such as being slower.<br />
<br />
'''Examples:'''<br />
* http://www.easyweb.com<br />
* http://www.dreamhost.com/web-hosting/<br />
* http://wpengine.com/ (wordpress only)<br />
<br />
===Threat Mitigation===<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
For a basic setup providing a content distribution platform such as a blog users have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
<br />
<br />
===Threat Mitigation===<br />
<br />
<ol><br />
<li><br />
'''Strong Passwords''' are a core element of any system. The access password for the host should be restricted to those individuals with the organisation that work directly with the server.<br />
<br />
Safe password creation and storage procedures should be followed, as described [[Access_Restrictions#Dedicated/VPS_Hosting|here]]<br />
</li><br />
<li><br />
'''Malware''' is core vulnerability for the devices used by those managing and logging into the hosted system. Malware, keyloggers and viruses provided a straightforward means of attack.<br />
<br><br />
The attacker does not need to hack or compromise the server, instead via infection through phishing emails or malicious websites the attacker can log and store the passwords and other critical information.<br />
<br><br />
To mitigate this threat all individuals who work with or have login access to the server must have anti-virus installed, a firewall and have an up to date system. For more information [|see]<br />
</li><br />
<li><br />
'''Two factor Authentication''' should be enabled where available as this will make compromising a system significantly more difficult.<br />
</li><br />
<li><br />
'''Wordpress Security''' is described in detail in the following [http://codex.wordpress.org/Hardening_WordPress guide]. <br />
</li><br />
</ol><br />
</div><br />
<br />
</div><br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''Dedicated Server'''<br />
| style="padding: 5px;"| '''Virtual Private Server'''<br />
| style="padding: 5px;"| '''Shared Hosting'''<br />
| style="padding: 5px;"| '''Cloud Service'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Requires Intermediary technical skill<br />
| style="padding: 5px;"| Intermediary/Basic<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows disk/data encryption<br />
| style="padding: 5px;"| Allows encryption within VPS<br />
| style="padding: 5px;"| Limited or no control of data encryption<br />
| style="padding: 5px;"| Depends on provider but usually not provided<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| SSH and private key login<br />
| style="padding: 5px;"| Enforce secure login for VPS<br />
| style="padding: 5px;"| Login via CPanel or Custom interface - some hosts offer 2 factor auth<br />
| style="padding: 5px;"| Depends<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| User access control and restriction<br />
| style="padding: 5px;"| User control<br />
| style="padding: 5px;"| Control via user accounts added through management software<br />
| style="padding: 5px;"| Control via management software<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| Allows only shared SSL cert, most host provide shared cert<br />
| style="padding: 5px;"| Most host platforms will provide SSL support by default<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Total control of applications and software<br />
| style="padding: 5px;"| Control of software within VM, limited access to hardware depending on type of VM<br />
| style="padding: 5px;"| Application control only via management interface<br />
| style="padding: 5px;"| Depends on cloud server - certain services with provide data access restrictions but this is a non-ideal scenario<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Manually maintained and updated<br />
| style="padding: 5px;"| Server is patched but VPS remains responsibility of user<br />
| style="padding: 5px;"| Patches and updates provided by host - though may lag behind depending on quality of hosting<br />
| style="padding: 5px;"| Depending on scale of provider - patching and support will be provided to protect their reputation<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Limited supported - hardware support and replacement depending on provider<br />
| style="padding: 5px;"| Similar to dedicated support<br />
| style="padding: 5px;"| Support is generally in terms of management software - hardware is automatically monitored by hosts<br />
| style="padding: 5px;"| Similar to shared though support is specific to the platform hosting<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Anti-ddos and brute forcing via fail2ban, botnetdbp deployment<br />
| style="padding: 5px;"| Provider may or may not mitigate DDoS attacks<br />
| style="padding: 5px;"| DDoS attacks will receive some or limited mitigation depending on quality of host, generally they will not protect against large scale attacks and may force the website to be removed<br />
| style="padding: 5px;"| Depending on the provider if the attack crosses their threshold for protection they may shut down the website or ask it to leave<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/Choose_a_hosting_providerChoose a hosting provider2014-05-26T20:00:11Z<p>Bill: /* Threat Mitigation */</p>
<hr />
<div>__NOTOC__<br />
===Criteria===<br />
<br />
There are several aspects which should be considered when selecting a service host. Below is a general list, this [https://pad.riseup.net/p/rh_ispq document] gives detailed information on each area. eQualit.ie has developed a [https://wiki.deflect.ca/wiki/ISP_reviews review] of existing providers based on experiences with our Deflect network.<br />
<br />
*Price - relative services offered<br />
*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.<br />
*Specialisation - do they work in the field of human rights, software applications or general hosting<br />
*Is mail provided<br />
*Hardware specifications<br />
*Operating systems offered<br />
*Supported provided<br />
*Readily discusses your security concerns and which security features and processes they offer with their hosting.<br />
*Provides the most recent stable versions of all server software.<br />
*Provides reliable methods for backup and recovery.<br />
*Provides encryption options for hosting of sites or mail<br />
<br />
===Features===<br />
It is quite important to consider the possibilities offered by your provider's control panel. If you need to write a support ticket everytime the server has to reboot, it wont be an efficient process, especially during a crises. Possible features to look out for include<br />
<br />
* Automated operating system installs<br />
* Server boot and reboot<br />
* Remote console (sometimes known as KVM)<br />
* Server and network statistics<br />
* Dynamic components (e.g. adding extra disk space, RAM without rebuilding the machine or having to order a new service)<br />
* Server access (varies between SSH, SFTP or web based)<br />
*<br />
<br />
==Secure hosting setups==<br />
Depending on available skill level the following secure system setups are possible:<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===Dedicated Server===<br />
For a [[Dedicated_Hosting | Dedicated Hosting]] system, the user can either run their own physical hardware or rent this hardware from a provider. The former solution offers total control of the physical hardware, however, there are significant downsides to this approach and should be avoided; it is only recommend under special circumstances such as [[Sensitive_Data | storing sensitive data]]. In the latter case, the hosting agent provides the hardware but the user has total control of the server via remote access. In this scenario, the provider is responsible for replacement of hardware parts that fail or malfunction - this support is generally done through a ticket system and relies on the user to report errors.<br />
<br />
'''Examples'''<br />
* http://www.ovh.com/ca/en/dedicated-servers/hosting/<br />
* http://www.soyoustart.com/ie/offers.xml<br />
* http://www.hetzner.de/en/hosting/produktmatrix/rootserver<br />
* http://www.coolhousing.net/hosting-dedicated-servers.html<br />
<br />
'''Benefits'''<br />
*User has total control of the system's software<br />
*User has total control of access rights<br />
*User has control of physical network connection, allowing them to whitelist or block connection from allowed or spurious connections<br />
*Financial cost of hardware malfunction is not an issue as the host is responsible for replacing/repairing failing hardware<br />
*The host can be chosen to place the server in a different jurisdiction from that of the user to prevent seizure<br />
<br />
'''Downsides'''<br />
*The user does not have physical access to the server<br />
*The host is not responsible for data loss or downtime if the physical server fails<br />
*The user is responsible for detecting and reporting hardware faults on some providers<br />
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].<br />
*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.<br />
<br />
===VPS===<br />
A Virtual Private Server(VPS) is an instance of a Virtual Operating System running on a much larger server. Typically multiple VPS will be run on a single server. In a VPS environment, you have a dedicated virtual private server but do not control the server on which it is hosted. Resources will be limited, you can not control or harden the outer server.<br />
<br />
'''Examples'''<br />
* https://www.linode.com/pricing<br />
* https://chhost.net/virtual-server/<br />
* https://www.tilaa.com/orders/add<br />
<br />
'''Benefits'''<br />
*The cost of this type of server will typically be significantly cheaper than a dedicated server<br />
*Depending on the host, the server will be capable of running most standard server software, up to a certain limit<br />
*Hardware is managed by the hosting provider unless self hosting<br />
*If self hosting, a single server can be used for multiple purposes and to provide multiple distinct servers<br />
<br />
'''Downsides'''<br />
*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<br />
*Bandwidth will also be restricted<br />
*Potential risk of provider, law enforcement or other state forces accessing contents of virtual server without user's awareness. <br />
*The user will not have access to the outer server and will thus not be able to harden it<br />
<br />
===Threats===<br />
*Social engineering attack<br />
*Password brute force<br />
*Service interruption through denial of service attack<br />
*System software exploits<br />
*SSL man-in-the-middle attacks<br />
*Data loss or data theft<br />
<br />
===Mitigation===<br />
'''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.<br />
<br />
For more details [[Access_Restrictions#Dedicated/VPS_Hosting| see]]<br />
<br />
'''User Management''' on dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<br />
For more details see [[Access_Restrictions#Dedicated/VPS_HOSTING| see]]<br />
<br />
'''System and Software Management'''<br />
<br />
For more details see [[System_Management| see]]<br />
<br />
'''Webserver Setup'''<br />
<br />
For more details [[Webserver_setup| see]]<br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted platform===<br />
For organisation that wish to setup their own custom site based on an existing platform such as Wordpress.com, there are a setup of steps that should be taken to ensure a good level of security. The [[Choosing_A_Host | choosing a hosting provider]] guide should also be consulted.<br />
<br />
'''Platform Security'''<br />
<ol><br />
<li><br />
Limiting access - Making smart choices that reduce possible entry points available to a malicious person.<br />
</li><br />
<li>Containment - Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.<br />
</li><br />
<li>Preparation and knowledge - Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.<br />
</li><br />
<li><br />
Passwords<br />
</li><br />
<li><br />
File Permissions<br />
</li><br />
<li><br />
Admin user<br />
</li><br />
<li><br />
SSL<br />
</li><br />
<li><br />
SFTP client<br />
</li><br />
<li><br />
Platform updates<br />
</li><br />
</ol><br />
Hosting install of pre-built software platform, such as Wordpress,<br />
<br />
===Shared Hosting===<br />
In a [[Shared_Hosting|Shared Hosting]] environment, your and other website owners shared one server. This includes sharing the physical server and the software applications within the server. Shared hosting services are affordable because the cost to operate the server is shared between you and these other owners. There are, however, a number of down sides, such as being slower.<br />
<br />
'''Examples:'''<br />
* http://www.easyweb.com<br />
* http://www.dreamhost.com/web-hosting/<br />
* http://wpengine.com/ (wordpress only)<br />
<br />
===Threat Mitigation===<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
For a basic setup providing a content distribution platform such as a blog users have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
<br />
<br />
===Threat Mitigation===<br />
<br />
<ol><br />
<li><br />
'''Strong Passwords''' are a core element of any system. The access password for the host should be restricted to those individuals with the organisation that work directly with the server.<br />
<br />
Safe password creation and storage procedures should be followed, as described [[Access_Restrictions#Dedicated/VPS_Hosting|here]]<br />
</li><br />
<li><br />
'''Malware''' is core vulnerability for the devices used by those managing and logging into the hosted system. Malware, keyloggers and viruses provided a straightforward means of attack.<br />
<br><br />
The attacker does not need to hack or compromise the server, instead via infection through phishing emails or malicious websites the attacker can log and store the passwords and other critical information.<br />
<br><br />
To mitigate this threat all individuals who work with or have login access to the server must have anti-virus installed, a firewall and have an up to date system. For more information [|see]<br />
</li><br />
<li><br />
'''Two factor Authentication''' should be enabled where available as this will make compromising a system significantly more difficult.<br />
</li><br />
<li><br />
'''Wordpress Security''' is described in detail in the following [http://codex.wordpress.org/Hardening_WordPress guide]. <br />
</li><br />
</ol><br />
</div><br />
<br />
</div><br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''Dedicated Server'''<br />
| style="padding: 5px;"| '''Virtual Private Server'''<br />
| style="padding: 5px;"| '''Shared Hosting'''<br />
| style="padding: 5px;"| '''Cloud Service'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Requires Intermediary technical skill<br />
| style="padding: 5px;"| Intermediary/Basic<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows disk/data encryption<br />
| style="padding: 5px;"| Allows encryption within VPS<br />
| style="padding: 5px;"| Limited or no control of data encryption<br />
| style="padding: 5px;"| Depends on provider but usually not provided<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| SSH and private key login<br />
| style="padding: 5px;"| Enforce secure login for VPS<br />
| style="padding: 5px;"| Login via CPanel or Custom interface - some hosts offer 2 factor auth<br />
| style="padding: 5px;"| Depends<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| User access control and restriction<br />
| style="padding: 5px;"| User control<br />
| style="padding: 5px;"| Control via user accounts added through management software<br />
| style="padding: 5px;"| Control via management software<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| Allows only shared SSL cert, most host provide shared cert<br />
| style="padding: 5px;"| Most host platforms will provide SSL support by default<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Total control of applications and software<br />
| style="padding: 5px;"| Control of software within VM, limited access to hardware depending on type of VM<br />
| style="padding: 5px;"| Application control only via management interface<br />
| style="padding: 5px;"| Depends on cloud server - certain services with provide data access restrictions but this is a non-ideal scenario<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Manually maintained and updated<br />
| style="padding: 5px;"| Server is patched but VPS remains responsibility of user<br />
| style="padding: 5px;"| Patches and updates provided by host - though may lag behind depending on quality of hosting<br />
| style="padding: 5px;"| Depending on scale of provider - patching and support will be provided to protect their reputation<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Limited supported - hardware support and replacement depending on provider<br />
| style="padding: 5px;"| Similar to dedicated support<br />
| style="padding: 5px;"| Support is generally in terms of management software - hardware is automatically monitored by hosts<br />
| style="padding: 5px;"| Similar to shared though support is specific to the platform hosting<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Anti-ddos and brute forcing via fail2ban, botnetdbp deployment<br />
| style="padding: 5px;"| Provider may or may not mitigate DDoS attacks<br />
| style="padding: 5px;"| DDoS attacks will receive some or limited mitigation depending on quality of host, generally they will not protect against large scale attacks and may force the website to be removed<br />
| style="padding: 5px;"| Depending on the provider if the attack crosses their threshold for protection they may shut down the website or ask it to leave<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/Choose_a_hosting_providerChoose a hosting provider2014-05-26T19:59:16Z<p>Bill: /* Mitigation */</p>
<hr />
<div>__NOTOC__<br />
===Criteria===<br />
<br />
There are several aspects which should be considered when selecting a service host. Below is a general list, this [https://pad.riseup.net/p/rh_ispq document] gives detailed information on each area. eQualit.ie has developed a [https://wiki.deflect.ca/wiki/ISP_reviews review] of existing providers based on experiences with our Deflect network.<br />
<br />
*Price - relative services offered<br />
*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.<br />
*Specialisation - do they work in the field of human rights, software applications or general hosting<br />
*Is mail provided<br />
*Hardware specifications<br />
*Operating systems offered<br />
*Supported provided<br />
*Readily discusses your security concerns and which security features and processes they offer with their hosting.<br />
*Provides the most recent stable versions of all server software.<br />
*Provides reliable methods for backup and recovery.<br />
*Provides encryption options for hosting of sites or mail<br />
<br />
===Features===<br />
It is quite important to consider the possibilities offered by your provider's control panel. If you need to write a support ticket everytime the server has to reboot, it wont be an efficient process, especially during a crises. Possible features to look out for include<br />
<br />
* Automated operating system installs<br />
* Server boot and reboot<br />
* Remote console (sometimes known as KVM)<br />
* Server and network statistics<br />
* Dynamic components (e.g. adding extra disk space, RAM without rebuilding the machine or having to order a new service)<br />
* Server access (varies between SSH, SFTP or web based)<br />
*<br />
<br />
==Secure hosting setups==<br />
Depending on available skill level the following secure system setups are possible:<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===Dedicated Server===<br />
For a [[Dedicated_Hosting | Dedicated Hosting]] system, the user can either run their own physical hardware or rent this hardware from a provider. The former solution offers total control of the physical hardware, however, there are significant downsides to this approach and should be avoided; it is only recommend under special circumstances such as [[Sensitive_Data | storing sensitive data]]. In the latter case, the hosting agent provides the hardware but the user has total control of the server via remote access. In this scenario, the provider is responsible for replacement of hardware parts that fail or malfunction - this support is generally done through a ticket system and relies on the user to report errors.<br />
<br />
'''Examples'''<br />
* http://www.ovh.com/ca/en/dedicated-servers/hosting/<br />
* http://www.soyoustart.com/ie/offers.xml<br />
* http://www.hetzner.de/en/hosting/produktmatrix/rootserver<br />
* http://www.coolhousing.net/hosting-dedicated-servers.html<br />
<br />
'''Benefits'''<br />
*User has total control of the system's software<br />
*User has total control of access rights<br />
*User has control of physical network connection, allowing them to whitelist or block connection from allowed or spurious connections<br />
*Financial cost of hardware malfunction is not an issue as the host is responsible for replacing/repairing failing hardware<br />
*The host can be chosen to place the server in a different jurisdiction from that of the user to prevent seizure<br />
<br />
'''Downsides'''<br />
*The user does not have physical access to the server<br />
*The host is not responsible for data loss or downtime if the physical server fails<br />
*The user is responsible for detecting and reporting hardware faults on some providers<br />
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].<br />
*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.<br />
<br />
===VPS===<br />
A Virtual Private Server(VPS) is an instance of a Virtual Operating System running on a much larger server. Typically multiple VPS will be run on a single server. In a VPS environment, you have a dedicated virtual private server but do not control the server on which it is hosted. Resources will be limited, you can not control or harden the outer server.<br />
<br />
'''Examples'''<br />
* https://www.linode.com/pricing<br />
* https://chhost.net/virtual-server/<br />
* https://www.tilaa.com/orders/add<br />
<br />
'''Benefits'''<br />
*The cost of this type of server will typically be significantly cheaper than a dedicated server<br />
*Depending on the host, the server will be capable of running most standard server software, up to a certain limit<br />
*Hardware is managed by the hosting provider unless self hosting<br />
*If self hosting, a single server can be used for multiple purposes and to provide multiple distinct servers<br />
<br />
'''Downsides'''<br />
*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<br />
*Bandwidth will also be restricted<br />
*Potential risk of provider, law enforcement or other state forces accessing contents of virtual server without user's awareness. <br />
*The user will not have access to the outer server and will thus not be able to harden it<br />
<br />
===Threats===<br />
*Social engineering attack<br />
*Password brute force<br />
*Service interruption through denial of service attack<br />
*System software exploits<br />
*SSL man-in-the-middle attacks<br />
*Data loss or data theft<br />
<br />
===Mitigation===<br />
'''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.<br />
<br />
For more details [[Access_Restrictions#Dedicated/VPS_Hosting| see]]<br />
<br />
'''User Management''' on dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<br />
For more details see [[Access_Restrictions#Dedicated/VPS_HOSTING| see]]<br />
<br />
'''System and Software Management'''<br />
<br />
For more details see [[System_Management| see]]<br />
<br />
'''Webserver Setup'''<br />
<br />
For more details [[Webserver_setup| see]]<br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted platform===<br />
For organisation that wish to setup their own custom site based on an existing platform such as Wordpress.com, there are a setup of steps that should be taken to ensure a good level of security. The [[Choosing_A_Host | choosing a hosting provider]] guide should also be consulted.<br />
<br />
'''Platform Security'''<br />
<ol><br />
<li><br />
Limiting access - Making smart choices that reduce possible entry points available to a malicious person.<br />
</li><br />
<li>Containment - Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.<br />
</li><br />
<li>Preparation and knowledge - Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.<br />
</li><br />
<li><br />
Passwords<br />
</li><br />
<li><br />
File Permissions<br />
</li><br />
<li><br />
Admin user<br />
</li><br />
<li><br />
SSL<br />
</li><br />
<li><br />
SFTP client<br />
</li><br />
<li><br />
Platform updates<br />
</li><br />
</ol><br />
Hosting install of pre-built software platform, such as Wordpress,<br />
<br />
===Shared Hosting===<br />
In a [[Shared_Hosting|Shared Hosting]] environment, your and other website owners shared one server. This includes sharing the physical server and the software applications within the server. Shared hosting services are affordable because the cost to operate the server is shared between you and these other owners. There are, however, a number of down sides, such as being slower.<br />
<br />
'''Examples:'''<br />
* http://www.easyweb.com<br />
* http://www.dreamhost.com/web-hosting/<br />
* http://wpengine.com/ (wordpress only)<br />
<br />
===Threat Mitigation===<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
For a basic setup providing a content distribution platform such as a blog users have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
<br />
<br />
===Threat Mitigation===<br />
<br />
<ol><br />
<li><br />
'''Strong Passwords''' are a core element of any system. The access password for the host should be restricted to those individuals with the organisation that work directly with the server.<br />
<br />
Safe password creation and storage procedures should be followed, as described [|here]<br />
</li><br />
<li><br />
'''Malware''' is core vulnerability for the devices used by those managing and logging into the hosted system. Malware, keyloggers and viruses provided a straightforward means of attack.<br />
<br><br />
The attacker does not need to hack or compromise the server, instead via infection through phishing emails or malicious websites the attacker can log and store the passwords and other critical information.<br />
<br><br />
To mitigate this threat all individuals who work with or have login access to the server must have anti-virus installed, a firewall and have an up to date system. For more information [|see]<br />
</li><br />
<li><br />
'''Two factor Authentication''' should be enabled where available as this will make compromising a system significantly more difficult.<br />
</li><br />
<li><br />
'''Wordpress Security''' is described in detail in the following [http://codex.wordpress.org/Hardening_WordPress guide]. <br />
</li><br />
</ol><br />
</div><br />
<br />
</div><br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''Dedicated Server'''<br />
| style="padding: 5px;"| '''Virtual Private Server'''<br />
| style="padding: 5px;"| '''Shared Hosting'''<br />
| style="padding: 5px;"| '''Cloud Service'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Requires Intermediary technical skill<br />
| style="padding: 5px;"| Intermediary/Basic<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows disk/data encryption<br />
| style="padding: 5px;"| Allows encryption within VPS<br />
| style="padding: 5px;"| Limited or no control of data encryption<br />
| style="padding: 5px;"| Depends on provider but usually not provided<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| SSH and private key login<br />
| style="padding: 5px;"| Enforce secure login for VPS<br />
| style="padding: 5px;"| Login via CPanel or Custom interface - some hosts offer 2 factor auth<br />
| style="padding: 5px;"| Depends<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| User access control and restriction<br />
| style="padding: 5px;"| User control<br />
| style="padding: 5px;"| Control via user accounts added through management software<br />
| style="padding: 5px;"| Control via management software<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| Allows only shared SSL cert, most host provide shared cert<br />
| style="padding: 5px;"| Most host platforms will provide SSL support by default<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Total control of applications and software<br />
| style="padding: 5px;"| Control of software within VM, limited access to hardware depending on type of VM<br />
| style="padding: 5px;"| Application control only via management interface<br />
| style="padding: 5px;"| Depends on cloud server - certain services with provide data access restrictions but this is a non-ideal scenario<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Manually maintained and updated<br />
| style="padding: 5px;"| Server is patched but VPS remains responsibility of user<br />
| style="padding: 5px;"| Patches and updates provided by host - though may lag behind depending on quality of hosting<br />
| style="padding: 5px;"| Depending on scale of provider - patching and support will be provided to protect their reputation<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Limited supported - hardware support and replacement depending on provider<br />
| style="padding: 5px;"| Similar to dedicated support<br />
| style="padding: 5px;"| Support is generally in terms of management software - hardware is automatically monitored by hosts<br />
| style="padding: 5px;"| Similar to shared though support is specific to the platform hosting<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Anti-ddos and brute forcing via fail2ban, botnetdbp deployment<br />
| style="padding: 5px;"| Provider may or may not mitigate DDoS attacks<br />
| style="padding: 5px;"| DDoS attacks will receive some or limited mitigation depending on quality of host, generally they will not protect against large scale attacks and may force the website to be removed<br />
| style="padding: 5px;"| Depending on the provider if the attack crosses their threshold for protection they may shut down the website or ask it to leave<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/Choose_a_hosting_providerChoose a hosting provider2014-05-26T19:57:31Z<p>Bill: /* Mitigation */</p>
<hr />
<div>__NOTOC__<br />
===Criteria===<br />
<br />
There are several aspects which should be considered when selecting a service host. Below is a general list, this [https://pad.riseup.net/p/rh_ispq document] gives detailed information on each area. eQualit.ie has developed a [https://wiki.deflect.ca/wiki/ISP_reviews review] of existing providers based on experiences with our Deflect network.<br />
<br />
*Price - relative services offered<br />
*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.<br />
*Specialisation - do they work in the field of human rights, software applications or general hosting<br />
*Is mail provided<br />
*Hardware specifications<br />
*Operating systems offered<br />
*Supported provided<br />
*Readily discusses your security concerns and which security features and processes they offer with their hosting.<br />
*Provides the most recent stable versions of all server software.<br />
*Provides reliable methods for backup and recovery.<br />
*Provides encryption options for hosting of sites or mail<br />
<br />
===Features===<br />
It is quite important to consider the possibilities offered by your provider's control panel. If you need to write a support ticket everytime the server has to reboot, it wont be an efficient process, especially during a crises. Possible features to look out for include<br />
<br />
* Automated operating system installs<br />
* Server boot and reboot<br />
* Remote console (sometimes known as KVM)<br />
* Server and network statistics<br />
* Dynamic components (e.g. adding extra disk space, RAM without rebuilding the machine or having to order a new service)<br />
* Server access (varies between SSH, SFTP or web based)<br />
*<br />
<br />
==Secure hosting setups==<br />
Depending on available skill level the following secure system setups are possible:<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===Dedicated Server===<br />
For a [[Dedicated_Hosting | Dedicated Hosting]] system, the user can either run their own physical hardware or rent this hardware from a provider. The former solution offers total control of the physical hardware, however, there are significant downsides to this approach and should be avoided; it is only recommend under special circumstances such as [[Sensitive_Data | storing sensitive data]]. In the latter case, the hosting agent provides the hardware but the user has total control of the server via remote access. In this scenario, the provider is responsible for replacement of hardware parts that fail or malfunction - this support is generally done through a ticket system and relies on the user to report errors.<br />
<br />
'''Examples'''<br />
* http://www.ovh.com/ca/en/dedicated-servers/hosting/<br />
* http://www.soyoustart.com/ie/offers.xml<br />
* http://www.hetzner.de/en/hosting/produktmatrix/rootserver<br />
* http://www.coolhousing.net/hosting-dedicated-servers.html<br />
<br />
'''Benefits'''<br />
*User has total control of the system's software<br />
*User has total control of access rights<br />
*User has control of physical network connection, allowing them to whitelist or block connection from allowed or spurious connections<br />
*Financial cost of hardware malfunction is not an issue as the host is responsible for replacing/repairing failing hardware<br />
*The host can be chosen to place the server in a different jurisdiction from that of the user to prevent seizure<br />
<br />
'''Downsides'''<br />
*The user does not have physical access to the server<br />
*The host is not responsible for data loss or downtime if the physical server fails<br />
*The user is responsible for detecting and reporting hardware faults on some providers<br />
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].<br />
*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.<br />
<br />
===VPS===<br />
A Virtual Private Server(VPS) is an instance of a Virtual Operating System running on a much larger server. Typically multiple VPS will be run on a single server. In a VPS environment, you have a dedicated virtual private server but do not control the server on which it is hosted. Resources will be limited, you can not control or harden the outer server.<br />
<br />
'''Examples'''<br />
* https://www.linode.com/pricing<br />
* https://chhost.net/virtual-server/<br />
* https://www.tilaa.com/orders/add<br />
<br />
'''Benefits'''<br />
*The cost of this type of server will typically be significantly cheaper than a dedicated server<br />
*Depending on the host, the server will be capable of running most standard server software, up to a certain limit<br />
*Hardware is managed by the hosting provider unless self hosting<br />
*If self hosting, a single server can be used for multiple purposes and to provide multiple distinct servers<br />
<br />
'''Downsides'''<br />
*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<br />
*Bandwidth will also be restricted<br />
*Potential risk of provider, law enforcement or other state forces accessing contents of virtual server without user's awareness. <br />
*The user will not have access to the outer server and will thus not be able to harden it<br />
<br />
===Threats===<br />
*Social engineering attack<br />
*Password brute force<br />
*Service interruption through denial of service attack<br />
*System software exploits<br />
*SSL man-in-the-middle attacks<br />
*Data loss or data theft<br />
<br />
===Mitigation===<br />
'''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.<br />
<br />
For more details [[Access_Restrictions#Dedicated/VPS_Hosting| see]]<br />
<br />
'''User Management''' on dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<br />
For more details see [[Access_Restrictions#Dedicated/VPS_HOSTING| see]]<br />
<br />
'''System and Software Management'''<br />
<br />
For more details see [[System_management| see]]<br />
<br />
'''Webserver Setup'''<br />
<br />
For more details [[Webserver_setup| see]]<br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted platform===<br />
For organisation that wish to setup their own custom site based on an existing platform such as Wordpress.com, there are a setup of steps that should be taken to ensure a good level of security. The [[Choosing_A_Host | choosing a hosting provider]] guide should also be consulted.<br />
<br />
'''Platform Security'''<br />
<ol><br />
<li><br />
Limiting access - Making smart choices that reduce possible entry points available to a malicious person.<br />
</li><br />
<li>Containment - Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.<br />
</li><br />
<li>Preparation and knowledge - Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.<br />
</li><br />
<li><br />
Passwords<br />
</li><br />
<li><br />
File Permissions<br />
</li><br />
<li><br />
Admin user<br />
</li><br />
<li><br />
SSL<br />
</li><br />
<li><br />
SFTP client<br />
</li><br />
<li><br />
Platform updates<br />
</li><br />
</ol><br />
Hosting install of pre-built software platform, such as Wordpress,<br />
<br />
===Shared Hosting===<br />
In a [[Shared_Hosting|Shared Hosting]] environment, your and other website owners shared one server. This includes sharing the physical server and the software applications within the server. Shared hosting services are affordable because the cost to operate the server is shared between you and these other owners. There are, however, a number of down sides, such as being slower.<br />
<br />
'''Examples:'''<br />
* http://www.easyweb.com<br />
* http://www.dreamhost.com/web-hosting/<br />
* http://wpengine.com/ (wordpress only)<br />
<br />
===Threat Mitigation===<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
For a basic setup providing a content distribution platform such as a blog users have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
<br />
<br />
===Threat Mitigation===<br />
<br />
<ol><br />
<li><br />
'''Strong Passwords''' are a core element of any system. The access password for the host should be restricted to those individuals with the organisation that work directly with the server.<br />
<br />
Safe password creation and storage procedures should be followed, as described [|here]<br />
</li><br />
<li><br />
'''Malware''' is core vulnerability for the devices used by those managing and logging into the hosted system. Malware, keyloggers and viruses provided a straightforward means of attack.<br />
<br><br />
The attacker does not need to hack or compromise the server, instead via infection through phishing emails or malicious websites the attacker can log and store the passwords and other critical information.<br />
<br><br />
To mitigate this threat all individuals who work with or have login access to the server must have anti-virus installed, a firewall and have an up to date system. For more information [|see]<br />
</li><br />
<li><br />
'''Two factor Authentication''' should be enabled where available as this will make compromising a system significantly more difficult.<br />
</li><br />
<li><br />
'''Wordpress Security''' is described in detail in the following [http://codex.wordpress.org/Hardening_WordPress guide]. <br />
</li><br />
</ol><br />
</div><br />
<br />
</div><br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''Dedicated Server'''<br />
| style="padding: 5px;"| '''Virtual Private Server'''<br />
| style="padding: 5px;"| '''Shared Hosting'''<br />
| style="padding: 5px;"| '''Cloud Service'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Requires Intermediary technical skill<br />
| style="padding: 5px;"| Intermediary/Basic<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows disk/data encryption<br />
| style="padding: 5px;"| Allows encryption within VPS<br />
| style="padding: 5px;"| Limited or no control of data encryption<br />
| style="padding: 5px;"| Depends on provider but usually not provided<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| SSH and private key login<br />
| style="padding: 5px;"| Enforce secure login for VPS<br />
| style="padding: 5px;"| Login via CPanel or Custom interface - some hosts offer 2 factor auth<br />
| style="padding: 5px;"| Depends<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| User access control and restriction<br />
| style="padding: 5px;"| User control<br />
| style="padding: 5px;"| Control via user accounts added through management software<br />
| style="padding: 5px;"| Control via management software<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| Allows only shared SSL cert, most host provide shared cert<br />
| style="padding: 5px;"| Most host platforms will provide SSL support by default<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Total control of applications and software<br />
| style="padding: 5px;"| Control of software within VM, limited access to hardware depending on type of VM<br />
| style="padding: 5px;"| Application control only via management interface<br />
| style="padding: 5px;"| Depends on cloud server - certain services with provide data access restrictions but this is a non-ideal scenario<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Manually maintained and updated<br />
| style="padding: 5px;"| Server is patched but VPS remains responsibility of user<br />
| style="padding: 5px;"| Patches and updates provided by host - though may lag behind depending on quality of hosting<br />
| style="padding: 5px;"| Depending on scale of provider - patching and support will be provided to protect their reputation<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Limited supported - hardware support and replacement depending on provider<br />
| style="padding: 5px;"| Similar to dedicated support<br />
| style="padding: 5px;"| Support is generally in terms of management software - hardware is automatically monitored by hosts<br />
| style="padding: 5px;"| Similar to shared though support is specific to the platform hosting<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Anti-ddos and brute forcing via fail2ban, botnetdbp deployment<br />
| style="padding: 5px;"| Provider may or may not mitigate DDoS attacks<br />
| style="padding: 5px;"| DDoS attacks will receive some or limited mitigation depending on quality of host, generally they will not protect against large scale attacks and may force the website to be removed<br />
| style="padding: 5px;"| Depending on the provider if the attack crosses their threshold for protection they may shut down the website or ask it to leave<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/Choose_a_hosting_providerChoose a hosting provider2014-05-26T19:57:00Z<p>Bill: /* Mitigation */</p>
<hr />
<div>__NOTOC__<br />
===Criteria===<br />
<br />
There are several aspects which should be considered when selecting a service host. Below is a general list, this [https://pad.riseup.net/p/rh_ispq document] gives detailed information on each area. eQualit.ie has developed a [https://wiki.deflect.ca/wiki/ISP_reviews review] of existing providers based on experiences with our Deflect network.<br />
<br />
*Price - relative services offered<br />
*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.<br />
*Specialisation - do they work in the field of human rights, software applications or general hosting<br />
*Is mail provided<br />
*Hardware specifications<br />
*Operating systems offered<br />
*Supported provided<br />
*Readily discusses your security concerns and which security features and processes they offer with their hosting.<br />
*Provides the most recent stable versions of all server software.<br />
*Provides reliable methods for backup and recovery.<br />
*Provides encryption options for hosting of sites or mail<br />
<br />
===Features===<br />
It is quite important to consider the possibilities offered by your provider's control panel. If you need to write a support ticket everytime the server has to reboot, it wont be an efficient process, especially during a crises. Possible features to look out for include<br />
<br />
* Automated operating system installs<br />
* Server boot and reboot<br />
* Remote console (sometimes known as KVM)<br />
* Server and network statistics<br />
* Dynamic components (e.g. adding extra disk space, RAM without rebuilding the machine or having to order a new service)<br />
* Server access (varies between SSH, SFTP or web based)<br />
*<br />
<br />
==Secure hosting setups==<br />
Depending on available skill level the following secure system setups are possible:<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===Dedicated Server===<br />
For a [[Dedicated_Hosting | Dedicated Hosting]] system, the user can either run their own physical hardware or rent this hardware from a provider. The former solution offers total control of the physical hardware, however, there are significant downsides to this approach and should be avoided; it is only recommend under special circumstances such as [[Sensitive_Data | storing sensitive data]]. In the latter case, the hosting agent provides the hardware but the user has total control of the server via remote access. In this scenario, the provider is responsible for replacement of hardware parts that fail or malfunction - this support is generally done through a ticket system and relies on the user to report errors.<br />
<br />
'''Examples'''<br />
* http://www.ovh.com/ca/en/dedicated-servers/hosting/<br />
* http://www.soyoustart.com/ie/offers.xml<br />
* http://www.hetzner.de/en/hosting/produktmatrix/rootserver<br />
* http://www.coolhousing.net/hosting-dedicated-servers.html<br />
<br />
'''Benefits'''<br />
*User has total control of the system's software<br />
*User has total control of access rights<br />
*User has control of physical network connection, allowing them to whitelist or block connection from allowed or spurious connections<br />
*Financial cost of hardware malfunction is not an issue as the host is responsible for replacing/repairing failing hardware<br />
*The host can be chosen to place the server in a different jurisdiction from that of the user to prevent seizure<br />
<br />
'''Downsides'''<br />
*The user does not have physical access to the server<br />
*The host is not responsible for data loss or downtime if the physical server fails<br />
*The user is responsible for detecting and reporting hardware faults on some providers<br />
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].<br />
*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.<br />
<br />
===VPS===<br />
A Virtual Private Server(VPS) is an instance of a Virtual Operating System running on a much larger server. Typically multiple VPS will be run on a single server. In a VPS environment, you have a dedicated virtual private server but do not control the server on which it is hosted. Resources will be limited, you can not control or harden the outer server.<br />
<br />
'''Examples'''<br />
* https://www.linode.com/pricing<br />
* https://chhost.net/virtual-server/<br />
* https://www.tilaa.com/orders/add<br />
<br />
'''Benefits'''<br />
*The cost of this type of server will typically be significantly cheaper than a dedicated server<br />
*Depending on the host, the server will be capable of running most standard server software, up to a certain limit<br />
*Hardware is managed by the hosting provider unless self hosting<br />
*If self hosting, a single server can be used for multiple purposes and to provide multiple distinct servers<br />
<br />
'''Downsides'''<br />
*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<br />
*Bandwidth will also be restricted<br />
*Potential risk of provider, law enforcement or other state forces accessing contents of virtual server without user's awareness. <br />
*The user will not have access to the outer server and will thus not be able to harden it<br />
<br />
===Threats===<br />
*Social engineering attack<br />
*Password brute force<br />
*Service interruption through denial of service attack<br />
*System software exploits<br />
*SSL man-in-the-middle attacks<br />
*Data loss or data theft<br />
<br />
===Mitigation===<br />
'''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.<br />
<br />
For more details [[Access_Restrictions#Dedicated/VPS_Hosting| see]]<br />
<br />
'''User Management''' on dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<br />
For more details see [[Access_Restrictions#Dedicated/VPS_HOSTING| see]]<br />
<br />
'''System and Software Management'''<br />
<br />
For more details see [[System_management| see]]<br />
'''Webserver Setup'''<br />
<br />
For more details [[Webserver_setup| see]]<br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted platform===<br />
For organisation that wish to setup their own custom site based on an existing platform such as Wordpress.com, there are a setup of steps that should be taken to ensure a good level of security. The [[Choosing_A_Host | choosing a hosting provider]] guide should also be consulted.<br />
<br />
'''Platform Security'''<br />
<ol><br />
<li><br />
Limiting access - Making smart choices that reduce possible entry points available to a malicious person.<br />
</li><br />
<li>Containment - Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.<br />
</li><br />
<li>Preparation and knowledge - Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.<br />
</li><br />
<li><br />
Passwords<br />
</li><br />
<li><br />
File Permissions<br />
</li><br />
<li><br />
Admin user<br />
</li><br />
<li><br />
SSL<br />
</li><br />
<li><br />
SFTP client<br />
</li><br />
<li><br />
Platform updates<br />
</li><br />
</ol><br />
Hosting install of pre-built software platform, such as Wordpress,<br />
<br />
===Shared Hosting===<br />
In a [[Shared_Hosting|Shared Hosting]] environment, your and other website owners shared one server. This includes sharing the physical server and the software applications within the server. Shared hosting services are affordable because the cost to operate the server is shared between you and these other owners. There are, however, a number of down sides, such as being slower.<br />
<br />
'''Examples:'''<br />
* http://www.easyweb.com<br />
* http://www.dreamhost.com/web-hosting/<br />
* http://wpengine.com/ (wordpress only)<br />
<br />
===Threat Mitigation===<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
For a basic setup providing a content distribution platform such as a blog users have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
<br />
<br />
===Threat Mitigation===<br />
<br />
<ol><br />
<li><br />
'''Strong Passwords''' are a core element of any system. The access password for the host should be restricted to those individuals with the organisation that work directly with the server.<br />
<br />
Safe password creation and storage procedures should be followed, as described [|here]<br />
</li><br />
<li><br />
'''Malware''' is core vulnerability for the devices used by those managing and logging into the hosted system. Malware, keyloggers and viruses provided a straightforward means of attack.<br />
<br><br />
The attacker does not need to hack or compromise the server, instead via infection through phishing emails or malicious websites the attacker can log and store the passwords and other critical information.<br />
<br><br />
To mitigate this threat all individuals who work with or have login access to the server must have anti-virus installed, a firewall and have an up to date system. For more information [|see]<br />
</li><br />
<li><br />
'''Two factor Authentication''' should be enabled where available as this will make compromising a system significantly more difficult.<br />
</li><br />
<li><br />
'''Wordpress Security''' is described in detail in the following [http://codex.wordpress.org/Hardening_WordPress guide]. <br />
</li><br />
</ol><br />
</div><br />
<br />
</div><br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''Dedicated Server'''<br />
| style="padding: 5px;"| '''Virtual Private Server'''<br />
| style="padding: 5px;"| '''Shared Hosting'''<br />
| style="padding: 5px;"| '''Cloud Service'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Requires Intermediary technical skill<br />
| style="padding: 5px;"| Intermediary/Basic<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows disk/data encryption<br />
| style="padding: 5px;"| Allows encryption within VPS<br />
| style="padding: 5px;"| Limited or no control of data encryption<br />
| style="padding: 5px;"| Depends on provider but usually not provided<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| SSH and private key login<br />
| style="padding: 5px;"| Enforce secure login for VPS<br />
| style="padding: 5px;"| Login via CPanel or Custom interface - some hosts offer 2 factor auth<br />
| style="padding: 5px;"| Depends<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| User access control and restriction<br />
| style="padding: 5px;"| User control<br />
| style="padding: 5px;"| Control via user accounts added through management software<br />
| style="padding: 5px;"| Control via management software<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| Allows only shared SSL cert, most host provide shared cert<br />
| style="padding: 5px;"| Most host platforms will provide SSL support by default<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Total control of applications and software<br />
| style="padding: 5px;"| Control of software within VM, limited access to hardware depending on type of VM<br />
| style="padding: 5px;"| Application control only via management interface<br />
| style="padding: 5px;"| Depends on cloud server - certain services with provide data access restrictions but this is a non-ideal scenario<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Manually maintained and updated<br />
| style="padding: 5px;"| Server is patched but VPS remains responsibility of user<br />
| style="padding: 5px;"| Patches and updates provided by host - though may lag behind depending on quality of hosting<br />
| style="padding: 5px;"| Depending on scale of provider - patching and support will be provided to protect their reputation<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Limited supported - hardware support and replacement depending on provider<br />
| style="padding: 5px;"| Similar to dedicated support<br />
| style="padding: 5px;"| Support is generally in terms of management software - hardware is automatically monitored by hosts<br />
| style="padding: 5px;"| Similar to shared though support is specific to the platform hosting<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Anti-ddos and brute forcing via fail2ban, botnetdbp deployment<br />
| style="padding: 5px;"| Provider may or may not mitigate DDoS attacks<br />
| style="padding: 5px;"| DDoS attacks will receive some or limited mitigation depending on quality of host, generally they will not protect against large scale attacks and may force the website to be removed<br />
| style="padding: 5px;"| Depending on the provider if the attack crosses their threshold for protection they may shut down the website or ask it to leave<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/System_ManagementSystem Management2014-05-26T19:55:52Z<p>Bill: Created page with "'''Software Management''' <ol> <li> System software must always be up to date. Critical patches are released by software vendors and operating system providers on a regular ba..."</p>
<hr />
<div>'''Software Management'''<br />
<ol><br />
<li><br />
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].<br />
</li><br />
<li><br />
Minimising installed software is an important step in reducing potential vulnerabilities. The system should have the bare minimum of packages and software installed to support its purpose.<br />
</li><br />
</ol><br />
'''System Management'''<br />
<ol><br />
<li><br />
Firewall can be enabled via [http://www.netfilter.org/projects/iptables/ iptables] the guides [http://www.tecmint.com/basic-guide-on-iptables-linux-firewall-tips-commands/ here] and [http://www.cyberciti.biz/faq/category/iptables/ here] describe iptables configuration.<br />
</li><br />
<li><br />
To protect the server it is important to audit the open ports on the machine. To check listening ports you can run<br />
<br><br />
netstat -tulpn<br />
<br />
<br />
</li><br />
<li><br />
Logging and Auditing is a key aspect of server security. All hacking, brute force, DDoS or other attacks should be captured, monitored and analysed. <br />
<br><br />
This [http://www.cyberciti.biz/faq/linux-log-files-location-and-how-do-i-view-logs-files/ guide] describes the location and purpose of common Linux log files.<br />
<br />
<br><br />
<br />
To ensure that information is not lost, overwritten or that the logs do not grow infinitely the tool [http://www.thegeekstuff.com/2010/07/logrotate-examples/ Logrotate] can be used.<br />
<br><br />
<br />
Installing a tool like Logwatch allows you to monitor and respond to suspicious activity. The following [https://www.digitalocean.com/community/articles/how-to-install-and-use-logwatch-log-analyzer-and-reporter-on-a-vps guide] describes installing and configuring Logwatch.<br />
</li><br />
<li><br />
[http://selinuxproject.org/page/Main_Page Security Enhanced Linux(SELinux)] is a kernel level security control mechanism, which enforces a set of rules and procedures for the system. SELinux provides fine grained control for access rights and permissions.<br />
<br><br />
To check if it is enabled run<br />
<br><br />
<i><br />
sestatus<br />
</i><br />
<br><br />
To enable run<br />
<br><br />
<i><br />
setenforce enforcing<br />
</i><br />
<br><br />
To adjust the SELinux config is available at<br />
<br><br />
<i><br />
/etc/selinux/config <br />
</i><br />
</li><br />
<li><br />
[http://www.fail2ban.org/wiki/index.php/Main_Page Fail2ban] is an excellent tool that can be used both to combat simple DDoS attacks but also to detect and block brute force login attempts.<br />
</li><br />
</ol><br />
<ul></div>Billhttps://learn.equalit.ie/wiki/Secure_hosting_guideSecure hosting guide2014-05-26T19:55:45Z<p>Bill: /* Step 3: Plan for contingency and threat mitigation */</p>
<hr />
<div>__NOTOC__<br />
<br />
This document is the result of a collaborative project between [http://www.huridocs.org/ Huridocs] and [https://equalit.ie eQualit.ie]. <br />
<br />
==Useful References==<br />
* [https://github.com/OpenInternet/MyWebsiteIsDown/blob/master/MyWebsiteIsDown.md What to do when your website goes down]<br />
* [http://en.flossmanuals.net/wordpress/ Building a Wordpress site] and then [http://moz.com/blog/the-definitive-guide-to-wordpress-security Guide to secure Wordpress set-up]<br />
* [http://en.flossmanuals.net/video-hosting-guide-t/index/ Independent video hosting]<br />
<br />
=Introduction=<br />
Hosting a website that can withstand various malicious attacks and unauthorised access attempts is not an easy task. There are several approaches to mitigating digital threats and reducing your site's vulnerabilities. There is no one-fits-all solution however and the site's owners or administrators should plan for various contingencies well in advance, in lieu of their financial situation and technical expertise. This guide attempts to describe several scenarios and various approaches for secure hosting. <br />
<br />
==Step 1: Decide on your level of technical expertise==<br />
A lot of choices made within this guide will depend on your level of technical expertise dealing with server configuration and maintenance. You should evaluate your situation honestly and try not to exceed this level. We will use the following key to differentiate the difficulty associated with each type of activity. <br />
<br />
*'''High Technical''' - multiple experiences of server administration, can confidently install/update server software; apache, mysql, mail server OR access to a consultant with these skills. Do not attempt to learn as you go!<br />
*'''Intermediate Technical''' - some experience of server administration, can install and manage web services software via guides, can use ssh and commandline interface<br />
*'''Basic Technical''' - no experience with server management. Can use software management interfaces such as CPanel<br />
<br />
'''Required''' - basic knowledge about Internet infrastructure and addressing is required should you want to maintain anything on the Internet (Facebook, twitter, other social networks exempted) that is bound to last the test of time. Please read through [https://learn.equalit.ie/wiki/How_does_the_Internet_actually_work%3F HOW DOES THE INTERNET ACTUALLY WORK?] to get the basics and go on from there. You need to know a little bit about architecture before building your house.<br />
<br />
==Step1: What are you planning to host?==<br />
*[[Website]] - standalone website, blog, forum<br />
<br />
==Step 2: What are your hosting options==<br />
Each category will include details of hosting options for additional reference we include here core hosting types and a methodology for choosing a hosting provider:<br />
<br />
*[[Choose a hosting provider]]<br />
*[[Choose a name registrar]]<br />
*[[Geography, lesgislation and terms of service]]<br />
<br />
==Step 3: Plan for contingency and threat mitigation==<br />
For each form of system use relevant threats and strategies to mitigate them are include. These approaches are ordered in terms of technical ability requirements. The following topics are relevant to all setups:<br />
<br />
*[[System_Management|System Management]]<br />
*[[Data_Backup|Data backup and recovery]]<br />
*[[Access Restrictions]]<br />
*[[Data Encryption]]<br />
*[[Monitoring]]<br />
*[[Webserver setup]]<br />
*[[Secure connections]]<br />
*[[Brute_Force_DDOS| Denial of Service and Brute Force attacks]]<br />
<br />
<br />
<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/Webserver_setupWebserver setup2014-05-26T19:54:21Z<p>Bill: Created page with "Apache hardening''' As well as considering the physical server and it's operating system users must thinking in terms of application security. Especially for those applicatio..."</p>
<hr />
<div>Apache hardening'''<br />
<br />
As well as considering the physical server and it's operating system users must thinking in terms of application security. Especially for those applications which either contain sensitive data or those that provide access routes to the machine for an attacker.<br />
<br />
Below is a set of guides for Apache webserver hardening.<br />
<li><br />
[http://www.tecmint.com/apache-security-tips/ 13 Apache Web Server Security and Hardening Tips]<br />
<li><br />
[http://xianshield.org/guides/apache2.0guide.html Apache 2.0 Hardening Guide]<br />
</li><br />
</ul><br />
<ul><br />
'''Database hardening'''<br />
<br />
A key approach discussed elsewhere in protecting data, both at rest - on disk - and in use - in memory, is to encrypt these data stores either as part of full disk encryption or as individual restricted encrypted mount points.<br />
<br />
Below are further guides for specific hardening techniques for the MySQL database system.<br />
<li><br />
[http://www.greensql.com/content/mysql-security-best-practices-hardening-mysql-tips MySQL Security Best Practices]<br />
</li><br />
<li><br />
[http://rochakchauhan.com/blog/2013/11/19/security-and-hardening-tips-for-mysql/ Security and Hardening Tips for MySQL]<br />
</li><br />
<li><br />
[http://www.securethelock.com/2014/01/09/12-steps-for-hardening-mysql-from-attackers/ 12 steps for Hardening MySQL from Attackers]<br />
</li><br />
</ul></div>Billhttps://learn.equalit.ie/wiki/Choose_a_hosting_providerChoose a hosting provider2014-05-26T15:33:39Z<p>Bill: /* Criteria */</p>
<hr />
<div>__NOTOC__<br />
===Criteria===<br />
<br />
There are several aspects which should be considered when selecting a service host. Below is a general list, this [https://pad.riseup.net/p/rh_ispq document] gives detailed information on each area. eQualit.ie has developed a [https://wiki.deflect.ca/wiki/ISP_reviews review] of existing providers based on experiences with our Deflect network.<br />
<br />
*Price - relative services offered<br />
*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.<br />
*Specialisation - do they work in the field of human rights, software applications or general hosting<br />
*Is mail provided<br />
*Hardware specifications<br />
*Operating systems offered<br />
*Supported provided<br />
*Readily discusses your security concerns and which security features and processes they offer with their hosting.<br />
*Provides the most recent stable versions of all server software.<br />
*Provides reliable methods for backup and recovery.<br />
*Provides encryption options for hosting of sites or mail<br />
<br />
===Features===<br />
It is quite important to consider the possibilities offered by your provider's control panel. If you need to write a support ticket everytime the server has to reboot, it wont be an efficient process, especially during a crises. Possible features to look out for include<br />
<br />
* Automated operating system installs<br />
* Server boot and reboot<br />
* Remote console (sometimes known as KVM)<br />
* Server and network statistics<br />
* Dynamic components (e.g. adding extra disk space, RAM without rebuilding the machine or having to order a new service)<br />
* Server access (varies between SSH, SFTP or web based)<br />
*<br />
<br />
==Secure hosting setups==<br />
Depending on available skill level the following secure system setups are possible:<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===Dedicated Server===<br />
For a [[Dedicated_Hosting | Dedicated Hosting]] system, the user can either run their own physical hardware or rent this hardware from a provider. The former solution offers total control of the physical hardware, however, there are significant downsides to this approach and should be avoided; it is only recommend under special circumstances such as [[Sensitive_Data | storing sensitive data]]. In the latter case, the hosting agent provides the hardware but the user has total control of the server via remote access. In this scenario, the provider is responsible for replacement of hardware parts that fail or malfunction - this support is generally done through a ticket system and relies on the user to report errors.<br />
<br />
'''Examples'''<br />
* http://www.ovh.com/ca/en/dedicated-servers/hosting/<br />
* http://www.soyoustart.com/ie/offers.xml<br />
* http://www.hetzner.de/en/hosting/produktmatrix/rootserver<br />
* http://www.coolhousing.net/hosting-dedicated-servers.html<br />
<br />
'''Benefits'''<br />
*User has total control of the system's software<br />
*User has total control of access rights<br />
*User has control of physical network connection, allowing them to whitelist or block connection from allowed or spurious connections<br />
*Financial cost of hardware malfunction is not an issue as the host is responsible for replacing/repairing failing hardware<br />
*The host can be chosen to place the server in a different jurisdiction from that of the user to prevent seizure<br />
<br />
'''Downsides'''<br />
*The user does not have physical access to the server<br />
*The host is not responsible for data loss or downtime if the physical server fails<br />
*The user is responsible for detecting and reporting hardware faults on some providers<br />
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].<br />
*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.<br />
<br />
===VPS===<br />
A Virtual Private Server(VPS) is an instance of a Virtual Operating System running on a much larger server. Typically multiple VPS will be run on a single server. In a VPS environment, you have a dedicated virtual private server but do not control the server on which it is hosted. Resources will be limited, you can not control or harden the outer server.<br />
<br />
'''Examples'''<br />
* https://www.linode.com/pricing<br />
* https://chhost.net/virtual-server/<br />
* https://www.tilaa.com/orders/add<br />
<br />
'''Benefits'''<br />
*The cost of this type of server will typically be significantly cheaper than a dedicated server<br />
*Depending on the host, the server will be capable of running most standard server software, up to a certain limit<br />
*Hardware is managed by the hosting provider unless self hosting<br />
*If self hosting, a single server can be used for multiple purposes and to provide multiple distinct servers<br />
<br />
'''Downsides'''<br />
*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<br />
*Bandwidth will also be restricted<br />
*Potential risk of provider, law enforcement or other state forces accessing contents of virtual server without user's awareness. <br />
*The user will not have access to the outer server and will thus not be able to harden it<br />
<br />
===Threats===<br />
*Social engineering attack<br />
*Password brute force<br />
*Service interruption through denial of service attack<br />
*System software exploits<br />
*SSL man-in-the-middle attacks<br />
*Data loss or data theft<br />
<br />
===Mitigation===<br />
'''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.<br />
<ol><br />
<li><br />
Enforce strong password - a strong password should contain Upper and Lower case characters, Numbers and Special Characters and should be long; greater than 20 characters. It is also possible to restrict the use of previously used passwords. On Linux systems the following command can be used to force complex passwords for users:<br />
</li><br />
password required pam_cracklib.so minlen=12 lcredit=1 ucredit=1 dcredit=2 ocredit=1<br />
<br />
For more detail, refer to the guide [http://www.linux-faqs.info/security/force-strong-passwords Force strong passwords]<br />
<li><br />
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].<br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
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]<br />
</li><br />
</ol><br />
'''User Management''' on dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<ol><br />
<li><br />
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.<br />
</li><br />
<li><br />
Secure Shell(SSH) login should be forced, telnet and ftp login access should be disabled by default. To upload files to the server securely user can use Secure FTP(SFTP) clients. <br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
File permissions should be restricted for critical files. User should only be allowed access to files relevant to their work. Execution as root should be restricted. Discussion of [http://www.linux.com/learn/tutorials/309527-understanding-linux-file-permissions linux file permissions].<br />
</li><br />
</ol><br />
'''Software Management'''<br />
<ol><br />
<li><br />
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].<br />
</li><br />
<li><br />
Minimising installed software is an important step in reducing potential vulnerabilities. The system should have the bare minimum of packages and software installed to support its purpose.<br />
</li><br />
</ol><br />
'''System Management'''<br />
<ol><br />
<li><br />
Firewall can be enabled via [http://www.netfilter.org/projects/iptables/ iptables] the guides [http://www.tecmint.com/basic-guide-on-iptables-linux-firewall-tips-commands/ here] and [http://www.cyberciti.biz/faq/category/iptables/ here] describe iptables configuration.<br />
</li><br />
<li><br />
To protect the server it is important to audit the open ports on the machine. To check listening ports you can run<br />
<br><br />
netstat -tulpn<br />
<br />
<br />
</li><br />
<li><br />
Logging and Auditing is a key aspect of server security. All hacking, brute force, DDoS or other attacks should be captured, monitored and analysed. <br />
<br><br />
This [http://www.cyberciti.biz/faq/linux-log-files-location-and-how-do-i-view-logs-files/ guide] describes the location and purpose of common Linux log files.<br />
<br />
<br><br />
<br />
To ensure that information is not lost, overwritten or that the logs do not grow infinitely the tool [http://www.thegeekstuff.com/2010/07/logrotate-examples/ Logrotate] can be used.<br />
<br><br />
<br />
Installing a tool like Logwatch allows you to monitor and respond to suspicious activity. The following [https://www.digitalocean.com/community/articles/how-to-install-and-use-logwatch-log-analyzer-and-reporter-on-a-vps guide] describes installing and configuring Logwatch.<br />
</li><br />
<li><br />
[http://selinuxproject.org/page/Main_Page Security Enhanced Linux(SELinux)] is a kernel level security control mechanism, which enforces a set of rules and procedures for the system. SELinux provides fine grained control for access rights and permissions.<br />
<br><br />
To check if it is enabled run<br />
<br><br />
<i><br />
sestatus<br />
</i><br />
<br><br />
To enable run<br />
<br><br />
<i><br />
setenforce enforcing<br />
</i><br />
<br><br />
To adjust the SELinux config is available at<br />
<br><br />
<i><br />
/etc/selinux/config <br />
</i><br />
</li><br />
<li><br />
[http://www.fail2ban.org/wiki/index.php/Main_Page Fail2ban] is an excellent tool that can be used both to combat simple DDoS attacks but also to detect and block brute force login attempts.<br />
</li><br />
</ol><br />
<ul><br />
'''Apache hardening'''<br />
<br />
As well as considering the physical server and it's operating system users must thinking in terms of application security. Especially for those applications which either contain sensitive data or those that provide access routes to the machine for an attacker.<br />
<br />
Below is a set of guides for Apache webserver hardening.<br />
<li><br />
[http://www.tecmint.com/apache-security-tips/ 13 Apache Web Server Security and Hardening Tips]<br />
<li><br />
[http://xianshield.org/guides/apache2.0guide.html Apache 2.0 Hardening Guide]<br />
</li><br />
</ul><br />
<ul><br />
'''Database hardening'''<br />
<br />
A key approach discussed elsewhere in protecting data, both at rest - on disk - and in use - in memory, is to encrypt these data stores either as part of full disk encryption or as individual restricted encrypted mount points.<br />
<br />
Below are further guides for specific hardening techniques for the MySQL database system.<br />
<li><br />
[http://www.greensql.com/content/mysql-security-best-practices-hardening-mysql-tips MySQL Security Best Practices]<br />
</li><br />
<li><br />
[http://rochakchauhan.com/blog/2013/11/19/security-and-hardening-tips-for-mysql/ Security and Hardening Tips for MySQL]<br />
</li><br />
<li><br />
[http://www.securethelock.com/2014/01/09/12-steps-for-hardening-mysql-from-attackers/ 12 steps for Hardening MySQL from Attackers]<br />
</li><br />
</ul><br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted platform===<br />
For organisation that wish to setup their own custom site based on an existing platform such as Wordpress.com, there are a setup of steps that should be taken to ensure a good level of security. The [[Choosing_A_Host | choosing a hosting provider]] guide should also be consulted.<br />
<br />
'''Platform Security'''<br />
<ol><br />
<li><br />
Limiting access - Making smart choices that reduce possible entry points available to a malicious person.<br />
</li><br />
<li>Containment - Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.<br />
</li><br />
<li>Preparation and knowledge - Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.<br />
</li><br />
<li><br />
Passwords<br />
</li><br />
<li><br />
File Permissions<br />
</li><br />
<li><br />
Admin user<br />
</li><br />
<li><br />
SSL<br />
</li><br />
<li><br />
SFTP client<br />
</li><br />
<li><br />
Platform updates<br />
</li><br />
</ol><br />
Hosting install of pre-built software platform, such as Wordpress,<br />
<br />
===Shared Hosting===<br />
In a [[Shared_Hosting|Shared Hosting]] environment, your and other website owners shared one server. This includes sharing the physical server and the software applications within the server. Shared hosting services are affordable because the cost to operate the server is shared between you and these other owners. There are, however, a number of down sides, such as being slower.<br />
<br />
'''Examples:'''<br />
* http://www.easyweb.com<br />
* http://www.dreamhost.com/web-hosting/<br />
* http://wpengine.com/ (wordpress only)<br />
<br />
===Threat Mitigation===<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
For a basic setup providing a content distribution platform such as a blog users have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
<br />
<br />
===Threat Mitigation===<br />
<br />
<ol><br />
<li><br />
'''Strong Passwords''' are a core element of any system. The access password for the host should be restricted to those individuals with the organisation that work directly with the server.<br />
<br />
Safe password creation and storage procedures should be followed, as described [|here]<br />
</li><br />
<li><br />
'''Malware''' is core vulnerability for the devices used by those managing and logging into the hosted system. Malware, keyloggers and viruses provided a straightforward means of attack.<br />
<br><br />
The attacker does not need to hack or compromise the server, instead via infection through phishing emails or malicious websites the attacker can log and store the passwords and other critical information.<br />
<br><br />
To mitigate this threat all individuals who work with or have login access to the server must have anti-virus installed, a firewall and have an up to date system. For more information [|see]<br />
</li><br />
<li><br />
'''Two factor Authentication''' should be enabled where available as this will make compromising a system significantly more difficult.<br />
</li><br />
<li><br />
'''Wordpress Security''' is described in detail in the following [http://codex.wordpress.org/Hardening_WordPress guide]. <br />
</li><br />
</ol><br />
</div><br />
<br />
</div><br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''Dedicated Server'''<br />
| style="padding: 5px;"| '''Virtual Private Server'''<br />
| style="padding: 5px;"| '''Shared Hosting'''<br />
| style="padding: 5px;"| '''Cloud Service'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Requires Intermediary technical skill<br />
| style="padding: 5px;"| Intermediary/Basic<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows disk/data encryption<br />
| style="padding: 5px;"| Allows encryption within VPS<br />
| style="padding: 5px;"| Limited or no control of data encryption<br />
| style="padding: 5px;"| Depends on provider but usually not provided<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| SSH and private key login<br />
| style="padding: 5px;"| Enforce secure login for VPS<br />
| style="padding: 5px;"| Login via CPanel or Custom interface - some hosts offer 2 factor auth<br />
| style="padding: 5px;"| Depends<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| User access control and restriction<br />
| style="padding: 5px;"| User control<br />
| style="padding: 5px;"| Control via user accounts added through management software<br />
| style="padding: 5px;"| Control via management software<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| Allows only shared SSL cert, most host provide shared cert<br />
| style="padding: 5px;"| Most host platforms will provide SSL support by default<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Total control of applications and software<br />
| style="padding: 5px;"| Control of software within VM, limited access to hardware depending on type of VM<br />
| style="padding: 5px;"| Application control only via management interface<br />
| style="padding: 5px;"| Depends on cloud server - certain services with provide data access restrictions but this is a non-ideal scenario<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Manually maintained and updated<br />
| style="padding: 5px;"| Server is patched but VPS remains responsibility of user<br />
| style="padding: 5px;"| Patches and updates provided by host - though may lag behind depending on quality of hosting<br />
| style="padding: 5px;"| Depending on scale of provider - patching and support will be provided to protect their reputation<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Limited supported - hardware support and replacement depending on provider<br />
| style="padding: 5px;"| Similar to dedicated support<br />
| style="padding: 5px;"| Support is generally in terms of management software - hardware is automatically monitored by hosts<br />
| style="padding: 5px;"| Similar to shared though support is specific to the platform hosting<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Anti-ddos and brute forcing via fail2ban, botnetdbp deployment<br />
| style="padding: 5px;"| Provider may or may not mitigate DDoS attacks<br />
| style="padding: 5px;"| DDoS attacks will receive some or limited mitigation depending on quality of host, generally they will not protect against large scale attacks and may force the website to be removed<br />
| style="padding: 5px;"| Depending on the provider if the attack crosses their threshold for protection they may shut down the website or ask it to leave<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/Brute_Force_DDOSBrute Force DDOS2014-05-26T15:24:54Z<p>Bill: </p>
<hr />
<div>As well as hacking attacks on servers and infrastructures a common approach to block access by users to content is to perform a Distributed Denial of Service(DDoS) attack. This is a very effective tactic if the attacker has access to either their own botnet infractructure or the financial resources to pay for such an attack.<br />
<br />
As DDoS attacks become more common the price of such attacks has dramatically plummeted with many individuals offering such attacks for as little as $10/day - depending on the target. <br />
<br />
There are a number of mechanisms and tools available for DDoS mitigation depending on the type of hosting.<br />
<br />
==Shared Hosting==<br />
<br />
In this scenario, unless the provider offers DDoS mitigation services, it is best to seek the aid of an external group. Several groups provide free online services that offer complete DDoS protection for NGO, Journalist, Activist or Civil Society websites. The following roups provide completely free services.<br />
<br />
'''Deflect.ca'''<br />
Is a free(and will always be free) open source non-commerical system made for activists by activists. Sign up for a site is straight forward, simply visit [https://deflect.ca Deflect].<br />
<br />
Deflect is sensitive to the special requirements of its users and can upon request securely destroy all logs. <br />
<br />
'''CloudFlare'''<br />
This is a commerical system which also provides free services for civil society websites. As the site is commericial users are subject to their terms and conditions. It is a large, successful provider with many commercial clients. It is in its best interest to provide a strong service but free clients may not receive the same level of support as those who pay.<br />
<br />
'''Project Shield'''<br />
Is Google's offering in the DDoS mitigation space. Again it is backed by a large corporation with a great deal of resources at their disposal. For civil society websites its service is free. Project Shield is currently invite-only.<br />
<br />
==Dedicated/VPS Hosting==<br />
<br />
As above all websites can benefit from the special services of the above groups if they qualify for free protection. This is by far the simplest approach and places the work load with experienced professionals.<br />
<br />
If, however, the user wishes to set up their own anti-DDoS system there are a number of open source tools that can help.<br />
<br />
'''BotnetDBP'''<br />
Is a suite of tools that evolves from the original fail2ban to offer a range of functionality. The core elements are a fast banning system, Banjax/Swabber, which is plugged into the Apache Traffic Server(ATS) proxy system. A machine learning tool, learn2ban, which is capable of identifying malicious botnet requesters based on pre-built models of attacks. And finally, Challenger, which offers the ability to respond to botnet, or suspected botnet, requests with either a Javascript challenge or a by serving a captcha page to determine the legitimacy of the request.<br />
<br />
More information can be found [https://wiki.deflect.ca/wiki/BotnetDBP here]<br />
<br />
'''Open Source Deflect'''<br />
<br />
Deflect itself can be deployed by individuals or groups to create their very own Deflect network. All is required is to follow the [https://wiki.deflect.ca/wiki/Deflect_DIY Deflect DIY]<br />
<br />
'''Fail2ban'''<br />
Is a regex based banning tool that is extremely effective against DoS and brute force attacks. It is used in conjunction with IPTables to ban malicious requests that match its defined regular expressions. It can be found [http://www.fail2ban.org/wiki/index.php/Main_Page here]. fail2ban's default configuration enables it to block attackers attempting to brute force username and password combinations to the SSH service. If a server's SSH port is exposed to the open internet, then it is strongly advised that fail2ban or a similar tool be installed. <br />
<br />
Against brute force password attacks fail2ban is an extremely useful tool. It can be set to ban IP Address that repeatedly attempt to access certain website pages, such as the login or admin pages.</div>Billhttps://learn.equalit.ie/wiki/Secure_connectionsSecure connections2014-05-26T15:24:13Z<p>Bill: </p>
<hr />
<div>When communicating data to/from a server it is important that the infromation not be susceptible to man-in-the-middle attacks. If data is communicated over open, plain text mediums such as FTP or HTTP then that data can be intercepted and read by any entity on any of the networks that the information passes through; this can included Local Area Networks, ISPs, or National Entities<br />
<br />
There are a number of steps that can be taken to protect communication channels to and from the server, though no system is 100% secure.<br />
<br />
<ol><br />
<li><br />
'''SSL'''<br />
If your website does not have an SSL certificate then all web traffic direct to your site will be unencrypted and potentially subject to snooping, either at the ISP level, at the level of your hosting provider or at a level that specifically targets your site's users locally (ie: local interception of their communications on a coffee shop's wireless network). <br />
<br />
Secure Socket Layer(SSL) is a cryptographic protocol which allows secure client-server interactions. Once a secure session has been established between the client, for example your web browser, and the server, your website in this case, all the information that passes between the two is unreadable to external parties.<br />
<br />
In order, to provide SSL for your website you must purchase an SSL certificate. This is a digital document that is signed by a recognised certificate reseller that uniquely belongs to your domain. <br />
<br />
An added benefit of SSL certificates is that they can aid in preventing SSL spoofing. This occurs where a malicious websites pretend to be a legitimate website or a server pretends to be a legitimate holder of the SSL cert. <br />
<br />
Most modern browsers will give a warning if an SSL cert has expired or is invalid - as in that it may be a spoof certificate.<br />
<br />
One of the most commonly used SSL software packages on the Internet, OpenSSL, suffered a major security flaw in the shape of the [http://heartbleed.com/ Heart Bleed bug]. This left most websites using a certain version of OpenSSL open to an exploit. This incident highlights that no technology is 100% secure and requires constant monitoring.<br />
<br />
</li><br />
<li><br />
'''SFTP'''<br />
When transfering files to or from a remote server it is integral to security to use an SFTP client. This stands for Secure File Tranfer Protocol. In a similar manner to SSL it ensures that the communications to and from the server are not open to external individuals.<br />
</li><br />
<li><br />
'''SSH'''<br />
When connecting directly to a server, for example for command line access, it is imperative to use the Secure SHell protocol. As the telnet protocol provides no level of security and should be disabled. For further information see []<br />
</li><br />
<ol></div>Billhttps://learn.equalit.ie/wiki/Data_EncryptionData Encryption2014-05-26T15:22:46Z<p>Bill: </p>
<hr />
<div>There are a number of options for data encryption for secure server hosting, however, for Shared Hosting or CPanel style hosts encryption options are very limited. For Dedicated/VPS hosting, administrator's have the option of encrypting the entire disk or encrypting portions where sensitive file data will be stored. We will explore both approaches, noting benefits and downsides for both.<br />
<br />
==Whole Disk Encryption==<br />
The major issue with whole disk encryption is that a reboot will require the entry of a password before the system is mounted. To be able to do this your provider would need to give access to the machine via a KVM, which allows remote access to a keyboard console as the machine boots. This is a non-standard setup and some providers may charge additional fees for it.<br />
<br />
Advanced users using whole-disk encryption may set up the DropBear SSH daemon in their boot loader, which allows for the use <br />
<br />
The significant benefit to whole disk encryption that if the machine is seized by outside parties they will have no access to the operating system or disk itself. This means that no data on the machine will be leaked in that eventuality. This also denies attackers the ability to modify most local system binaries to attempt to intercept passwords, provide backdoors or log user actions. <br />
<br />
<ol><br />
<li><br />
The [https://code.google.com/p/cryptsetup/ Linux Unified Key System(LUKS)] also for both full and partial disk encryption.<br />
<br />
An in-depth tutorial for LUKS setup can be found [https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system here] and a simpler one can be found [http://www.hermann-uwe.de/blog/howto-disk-encryption-with-dm-crypt-luks-and-debian here]<br />
</li><br />
</ol><br />
==Data Store Encryption==<br />
An alternative to whole disk encryption is to encrypt specific portions of the disk containing the most sensitive data that must be protected. Care should be taken to encrypt both data at rest (ie a database, MySQL etc.) and "scratch" or temporary data storage (search engine technologies such as Solr, Memcached data stores etc.).<br />
<br />
This removes the need for entry of a boot password on reboot but it does leave any elements of the disk not encrypted open to access if the machine is seized or compromised.<br />
<br />
<ol><br />
<li><br />
The tool [http://www.arg0.net/encfs encfs] runs in the user space and allows the creation of encrypted partitions. These partitions can be mounted once the system has been booted. The tool allows for very strict control over which users can access mounted information once a partition has been decrypted and is suited to applications where a specific user/process accesses the encrypted data. <br />
<br />
The encrypted partitions can be defined at variable sizes and the sensitive datastores and applications can be run from within them once the partition has been mounted.<br />
<br />
A guide for setting up <tt>encfs</tt> can be found [http://www.howtoforge.com/encrypt-your-data-with-encfs-debian-squeeze-ubuntu-11.10 here]. <br />
</li><br />
<li><br />
The Linux kernel offers support for <tt>ecryptfs</tt> partitions. These partitions are mounted like any other local filesystem, but with the benefit of the device being encrypted while unmounted. These partitions are mounted like other filesystems and not in user space so they cannot be mounted by unprivileged users. <br />
</li><br />
<li><br />
The LUKS tool can also be set to encrypted only specific partitions and mounted in a similar way to <tt>encfs</tt>.<br />
</ol></div>Billhttps://learn.equalit.ie/wiki/Access_RestrictionsAccess Restrictions2014-05-26T15:22:01Z<p>Bill: </p>
<hr />
<div>Restricting access to data based on roles, rights and responsibilities is an integral part of any security policy. It is equally true in the framing of secure hosting.<br />
<br />
In this circumstance, access should be clearly separated into roles at different levels. When hosting a web application a separate password and user should be used for database access by the web application. The web application should never have root access to any other domain. In a similar way, real world users should be divided into roles and categories and non-should be granted full root access.<br />
<br />
==Dedicated/VPS Hosting==<br />
<br />
'''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.<br />
<ol><br />
<li><br />
Enforce strong password - a strong password should contain upper and lower case characters, numbers and special characters and should be long; greater than 20 characters. It is also possible to restrict the use of previously used passwords. On Linux systems the following command can be used to force complex passwords for users:<br />
</li><br />
password required pam_cracklib.so minlen=12 lcredit=1 ucredit=1 dcredit=2 ocredit=1<br />
<br />
For more detail, refer to the guide [http://www.linux-faqs.info/security/force-strong-passwords Force strong passwords]<br />
<li><br />
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].<br />
</li><br />
<li><br />
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]<br />
</li><br />
<li><br />
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]<br />
</li><br />
</ol><br />
'''User Management''' on Dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<ol><br />
<li><br />
Root user login should be disabled by default<br />
</li><br />
<li><br />
Secure Shell(SSH) login should be forced, telnet and ftp login access should be disabled by default. To upload files to the server securely user can use Secure FTP(SFTP) clients. <br />
</li><br />
<li><br />
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]<br />
</li><br />
<li><br />
File permissions should be restricted for critical files. User should only be allowed access to files relevant to their work. Execution as root should be restricted. Discussion of [http://www.linux.com/learn/tutorials/309527-understanding-linux-file-permissions linux file permissions].<br />
</li><br />
</ol><br />
<br />
==Shared Hosting==<br />
<ol><br />
<li>'''Password Management'''<br />
For shared hosting password managment is a core defence against attack. The administrator password should fit the criteria above for a strong password - long, variance in characters containing no dictionary words.<br />
<br />
As above [https://securityinabox.org/en/keepass_main Keepass] can be used to generate and store a complex admin password. This has the secondary advantage of limiting access to the admin password to those who are trusted with the Keepass store.<br />
</li><br />
<li><br />
'''Restrict IP addresses'''<br />
<br />
Depending on what version of CPanel your provider offers, it is possible to lock down access via [http://docs.cpanel.net/twiki/bin/view/AllDocumentation/WHMDocs/DenyAccess Host Access Control] option. This allows you limit access to very specific IP addresses.<br />
</li><br />
<li><br />
'''User management'''<br />
User accounts on a Shared Hosting system should be restricted only to those whose core responsibility is for updating or maintaining the organisations site.<br />
Access information should, however, also be stored by the Organisation as part of their regular backups - in the event that the responsible party leaves the Organisation.<br />
</li><br />
</ol></div>Billhttps://learn.equalit.ie/wiki/Geography,_lesgislation_and_terms_of_serviceGeography, lesgislation and terms of service2014-05-26T15:20:34Z<p>Bill: </p>
<hr />
<div>For Activists, Journalists, NGOs or any Civil Society online participants, legal and geographic jurisdiction should be forefront when considering where to host their websites.<br />
<br />
==Legal Jurisdictions==<br />
The Internet has introduced a dislocated sense of legal jurisdiction, in some cases the problem of applying one countries laws to a different jurisdiction is not a new conception. Over time many countries have developed contracts, treaties and agreements with other states governing extradition of individuals who are wanted for breach of one country's legal code but are currently residing in another country. <br />
<br />
There have been a number of cases in the last decade ranging from extremely high profile, Julian Assange and Edward Snowden, to limited attention paid, [https://en.wikipedia.org/wiki/Gary_McKinnon Gary McKinnion].<br />
<br />
In many countries a core weapon used for censorship, oppression and repression is the judiciary and the enacting or novel use of laws designed to restrict freedoms. This is a very effective tactic and the results can be seen in countries such as Vietnam where a number of individuals have been tried for publishing material consider by the authorities to be illegal; either because of content - deemed anti-governmental - or method of publishing - publication under pseudonyms.<br />
<br />
Publication within the Jurisdiction of a given country can leave the publishers open to legal punishment.<br />
<br />
Ultimately, hosting a site in a different political or legal jurisdiction can not prevent recriminations against journalist, organisation or activists with country. It can prevent the ability to physical take the site or publication offline.<br />
<br />
This can be hampered in part by the use of intermediary resellers. For example, in the case of Cambodia hosting platforms are located outside of the country, however, access to these services is done through local resellers who are subject to Cambodian law. These resellers are chosen largely for language and immediacy of access to support.<br />
<br />
In determining the current laws that are applied or may be applied to your work or your locale there are a number of resources provided by monitoring groups that can be used as a starting point. This information is far from complete and is often only able to report on what legal tools have been used in the past.<br />
<br />
<ol><br />
<li><br />
[http://defendersdays.civilrightsdefenders.org/ Civil Rights Defenders]<br />
</li><br />
<li><br />
[http://www.iltb.net/ Indian Law and Technology blog]<br />
</li><br />
<li><br />
[http://www.openrightsgroup.org/ Open Rights Group]<br />
</li><br />
<li><br />
[https://supporters.eff.org/ Electronic Frontier Foundation (EFF)]<br />
</li><br />
<li><br />
[https://www.cpj.org/ Committee to protect Journalists]<br />
</li><br />
<li><br />
[http://freedomhouse.org/ Freedom House]<br />
</li><br />
<li><br />
[http://witness.org/ Witness]<br />
</li><br />
<li><br />
[http://www.frontlinedefenders.org/ Frontline Defenders]<br />
<li><br />
[http://www.lwob.org/Pages/Default.aspx Lawyers without Borders]<br />
</li><br />
<li><br />
[https://iscproject.org/country-assessments/ ISC Project]<br />
</li><br />
<li><br />
Many countries have specialised legal aide and free legal advice centres that can be contacted to help determine what laws may apply to your work<br />
</li><br />
</ol><br />
<br />
==Geographic Areas==<br />
<br />
Locating a server within a groups own geographic area, where their adversary is the authority or power groups within that geography will leave the site open to infrastructural attacks or censorship. <br />
<br />
As the site is located within the country's own infrastructure it is subject to all censorship applied by the state, ISP or national gateway.<br />
<br />
==Publishing and Content Legislation==<br />
<br />
Censorship through legal means is a prevalent form of suppression and a cause of self censorship. It is extremely important that organisations, journalists and individual take responsibility for their own education in terms of awareness of new digital laws as well as past applications and precedents set in prosecution.<br />
<br />
==Terms and Conditions==<br />
<br />
Carefully choice should be made in terms of the provider themselves. A strong reputation for support, quality and security is important but as to is alignment with your organisations goals.<br />
<br />
Ultimately, a contract is agreed between your organisation and the service provider. This contract governs how, when, and under what circumstances service will or won't be provided. <br />
<br />
If your provider has a history of discontinuing service to activists, journalist or civil society groups, or request that they self censor - then it is important to establish this at the outset. It is necessary to determine with your provider what content they might prohibit or what rules govern the extent to which they will support activists in publishing their work.<br />
<br />
There are already a number of service providers that aim to support the activists, NGO and non-profit world. Amongst them are [https://greenhost.net/about-us/ Green Host], [https://help.riseup.net/en/about-us Riseup] and [https://leap.se/en/about-us Leap].</div>Billhttps://learn.equalit.ie/wiki/WebsiteWebsite2014-05-26T15:19:04Z<p>Bill: </p>
<hr />
<div>==Definition==<br />
A website could be an organisation's main information portal - where they can publish material about themselves, their work and projects and articles or reports that they have produced. It can also take the simpler form of a standalone blog where content is shared with their intended audience, or may be represented as a forum or wiki where user generated content is published and shared. <br />
<br />
An organisation usually depends entirely on their main website as their presence on the Internet and expects it to function at all times.<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===DIY CMS===<br />
There are numerous well developed and 'continually maintained' content mangement systems that you can install and configure from scratch. They differ between their application and intended purpose, the majority however relying on a [http://en.wikipedia.org/wiki/LAMP_(software_bundle) LAMP] or [http://en.wikipedia.org/wiki/WAMP#Variants_and_equivalents_on_other_platforms WAMP] backend. Each CMS has its own particular requirements for webserver, database server and PHP configurations, as well as security considerations for them. <br />
<br />
'''Benefits'''<br />
*Total control of the CMS software, plug-ins, themes and preferred configuration<br />
*Fine-grained access control and modification of CMS features<br />
<br />
'''Downsides'''<br />
*A whole software ecosystem to learn with every new CMS<br />
*Responsibility for software updates and malware protection<br />
*Responsibility for data security <br />
<br />
'''Examples'''<br />
* [http://codex.wordpress.org/Installing_WordPress Wordpress.com] installation<br />
* [https://civicrm.org/ CiviCRM] is an open source CRm environment intended for civil society use.<br />
* [https://www.djangoproject.com/ Custom Django app], allows for creation quickly of high content, high functionality websites. Django's security systems re well [https://docs.djangoproject.com/en/dev/topics/security/ documented] and well integrated. Development of a Django app will require developer time and potentially also some design work.<br />
* [https://drupal.org/ Custom Drupal site], again a ready made configurable solution, with a developed sense of security integration - though as with the other solutions security relies on a holistic approach including server side security.<br />
'''Hosting Requirements'''<br />
*[[Choose_a_hosting_provider#High_Technical]]<br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted CMS===<br />
<br />
'''Benefits'''<br />
* Dependent on hosting package, support and updates will be handled by provider reducing need for tech knowledge<br />
* Straightforward and fast to setup<br />
* Greater usability for low tech users<br />
* Potential lower cost<br />
<br />
'''Downsides'''<br />
* Subject to terms and conditions of provider - controversial information or information that draws large scale attacks such as DDoS may cause provider to rescind service.<br />
* No control of hardware systems<br />
* Reliant on provider for software security updates to be applied<br />
* Limited control of jurisdiction or geography area that site is hosted within.<br />
* Reliance on providers support, which may not be available in local language<br />
<br />
'''Examples'''<br />
* [http://wordpress.com/ Wordpress.com]<br />
* [http://wpengine.com/ WPEngine]<br />
* [http://tumblr.com Tumblr]<br />
'''Hosting Requirements'''<br />
*[[Choose_a_hosting_provider#High_Technical]]<br />
*[[Choose_a_hosting_provider#Intermediary_Technical]]<br />
<br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
<br />
===Hosted website===<br />
For a basic setup providing a content distribution platform such as a blog user's have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
<br />
Care should be taken when considering a free service that offers a hosted CMS. Some free hosted CMS will not offer a good experience as sites that are problematic or troublesome may be taken offline without notice and with no recourse as the provider is under no obligation to serve the user. <br />
<br />
'''Benefits'''<br />
* No technical barrier to entry<br />
* Support provided by commerical company, with an interest in protecting their reputation both in terms of uptime but also in terms of avoiding security breaches<br />
* Greater likelihood of support in local language - at least in terms of documentation<br />
<br />
'''Downsides'''<br />
* Lack of control of any systems underlying website<br />
* Reliance on provider for support<br />
* Subject to providers terms and conditions, which may restrict publications<br />
<br />
'''Examples'''<br />
* [http://squarespace.com SquareSpace]<br />
* <br />
*<br />
'''Hosting Requirements'''<br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''DIY CMS'''<br />
| style="padding: 5px;"| '''Hosted CMS'''<br />
| style="padding: 5px;"| '''Hosted Website'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Intermediary technical skill<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| <br />
| style="padding: 5px;"| <br />
| style="padding: 5px;"| <br />
|-<br />
<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
[[Category: Secure Hosting ]]</div>Billhttps://learn.equalit.ie/wiki/Choose_a_hosting_providerChoose a hosting provider2014-05-26T15:17:27Z<p>Bill: </p>
<hr />
<div>__NOTOC__<br />
===Criteria===<br />
<br />
There are several aspects which should be considered when selecting a service host. Below is a general list, this [https://pad.riseup.net/p/rh_ispq document] gives detailed information on each area.<br />
<br />
*Price - relative services offered<br />
*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.<br />
*Specialisation - do they work in the field of human rights, software applications or general hosting<br />
*Is mail provided<br />
*Hardware specifications<br />
*Operating systems offered<br />
*Supported provided<br />
*Readily discusses your security concerns and which security features and processes they offer with their hosting.<br />
*Provides the most recent stable versions of all server software.<br />
*Provides reliable methods for backup and recovery.<br />
*Provides encryption options for hosting of sites or mail<br />
<br />
===Features===<br />
It is quite important to consider the possibilities offered by your provider's control panel. If you need to write a support ticket everytime the server has to reboot, it wont be an efficient process, especially during a crises. Possible features to look out for include<br />
<br />
* Automated operating system installs<br />
* Server boot and reboot<br />
* Remote console (sometimes known as KVM)<br />
* Server and network statistics<br />
* Dynamic components (e.g. adding extra disk space, RAM without rebuilding the machine or having to order a new service)<br />
* Server access (varies between SSH, SFTP or web based)<br />
*<br />
<br />
==Secure hosting setups==<br />
Depending on available skill level the following secure system setups are possible:<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===Dedicated Server===<br />
For a [[Dedicated_Hosting | Dedicated Hosting]] system, the user can either run their own physical hardware or rent this hardware from a provider. The former solution offers total control of the physical hardware, however, there are significant downsides to this approach and should be avoided; it is only recommend under special circumstances such as [[Sensitive_Data | storing sensitive data]]. In the latter case, the hosting agent provides the hardware but the user has total control of the server via remote access. In this scenario, the provider is responsible for replacement of hardware parts that fail or malfunction - this support is generally done through a ticket system and relies on the user to report errors.<br />
<br />
'''Examples'''<br />
* http://www.ovh.com/ca/en/dedicated-servers/hosting/<br />
* http://www.soyoustart.com/ie/offers.xml<br />
* http://www.hetzner.de/en/hosting/produktmatrix/rootserver<br />
* http://www.coolhousing.net/hosting-dedicated-servers.html<br />
<br />
'''Benefits'''<br />
*User has total control of the system's software<br />
*User has total control of access rights<br />
*User has control of physical network connection, allowing them to whitelist or block connection from allowed or spurious connections<br />
*Financial cost of hardware malfunction is not an issue as the host is responsible for replacing/repairing failing hardware<br />
*The host can be chosen to place the server in a different jurisdiction from that of the user to prevent seizure<br />
<br />
'''Downsides'''<br />
*The user does not have physical access to the server<br />
*The host is not responsible for data loss or downtime if the physical server fails<br />
*The user is responsible for detecting and reporting hardware faults on some providers<br />
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].<br />
*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.<br />
<br />
===VPS===<br />
A Virtual Private Server(VPS) is an instance of a Virtual Operating System running on a much larger server. Typically multiple VPS will be run on a single server. In a VPS environment, you have a dedicated virtual private server but do not control the server on which it is hosted. Resources will be limited, you can not control or harden the outer server.<br />
<br />
'''Examples'''<br />
* https://www.linode.com/pricing<br />
* https://chhost.net/virtual-server/<br />
* https://www.tilaa.com/orders/add<br />
<br />
'''Benefits'''<br />
*The cost of this type of server will typically be significantly cheaper than a dedicated server<br />
*Depending on the host, the server will be capable of running most standard server software, up to a certain limit<br />
*Hardware is managed by the hosting provider unless self hosting<br />
*If self hosting, a single server can be used for multiple purposes and to provide multiple distinct servers<br />
<br />
'''Downsides'''<br />
*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<br />
*Bandwidth will also be restricted<br />
*Potential risk of provider, law enforcement or other state forces accessing contents of virtual server without user's awareness. <br />
*The user will not have access to the outer server and will thus not be able to harden it<br />
<br />
===Threats===<br />
*Social engineering attack<br />
*Password brute force<br />
*Service interruption through denial of service attack<br />
*System software exploits<br />
*SSL man-in-the-middle attacks<br />
*Data loss or data theft<br />
<br />
===Mitigation===<br />
'''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.<br />
<ol><br />
<li><br />
Enforce strong password - a strong password should contain Upper and Lower case characters, Numbers and Special Characters and should be long; greater than 20 characters. It is also possible to restrict the use of previously used passwords. On Linux systems the following command can be used to force complex passwords for users:<br />
</li><br />
password required pam_cracklib.so minlen=12 lcredit=1 ucredit=1 dcredit=2 ocredit=1<br />
<br />
For more detail, refer to the guide [http://www.linux-faqs.info/security/force-strong-passwords Force strong passwords]<br />
<li><br />
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].<br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
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]<br />
</li><br />
</ol><br />
'''User Management''' on dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<ol><br />
<li><br />
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.<br />
</li><br />
<li><br />
Secure Shell(SSH) login should be forced, telnet and ftp login access should be disabled by default. To upload files to the server securely user can use Secure FTP(SFTP) clients. <br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
File permissions should be restricted for critical files. User should only be allowed access to files relevant to their work. Execution as root should be restricted. Discussion of [http://www.linux.com/learn/tutorials/309527-understanding-linux-file-permissions linux file permissions].<br />
</li><br />
</ol><br />
'''Software Management'''<br />
<ol><br />
<li><br />
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].<br />
</li><br />
<li><br />
Minimising installed software is an important step in reducing potential vulnerabilities. The system should have the bare minimum of packages and software installed to support its purpose.<br />
</li><br />
</ol><br />
'''System Management'''<br />
<ol><br />
<li><br />
Firewall can be enabled via [http://www.netfilter.org/projects/iptables/ iptables] the guides [http://www.tecmint.com/basic-guide-on-iptables-linux-firewall-tips-commands/ here] and [http://www.cyberciti.biz/faq/category/iptables/ here] describe iptables configuration.<br />
</li><br />
<li><br />
To protect the server it is important to audit the open ports on the machine. To check listening ports you can run<br />
<br><br />
netstat -tulpn<br />
<br />
<br />
</li><br />
<li><br />
Logging and Auditing is a key aspect of server security. All hacking, brute force, DDoS or other attacks should be captured, monitored and analysed. <br />
<br><br />
This [http://www.cyberciti.biz/faq/linux-log-files-location-and-how-do-i-view-logs-files/ guide] describes the location and purpose of common Linux log files.<br />
<br />
<br><br />
<br />
To ensure that information is not lost, overwritten or that the logs do not grow infinitely the tool [http://www.thegeekstuff.com/2010/07/logrotate-examples/ Logrotate] can be used.<br />
<br><br />
<br />
Installing a tool like Logwatch allows you to monitor and respond to suspicious activity. The following [https://www.digitalocean.com/community/articles/how-to-install-and-use-logwatch-log-analyzer-and-reporter-on-a-vps guide] describes installing and configuring Logwatch.<br />
</li><br />
<li><br />
[http://selinuxproject.org/page/Main_Page Security Enhanced Linux(SELinux)] is a kernel level security control mechanism, which enforces a set of rules and procedures for the system. SELinux provides fine grained control for access rights and permissions.<br />
<br><br />
To check if it is enabled run<br />
<br><br />
<i><br />
sestatus<br />
</i><br />
<br><br />
To enable run<br />
<br><br />
<i><br />
setenforce enforcing<br />
</i><br />
<br><br />
To adjust the SELinux config is available at<br />
<br><br />
<i><br />
/etc/selinux/config <br />
</i><br />
</li><br />
<li><br />
[http://www.fail2ban.org/wiki/index.php/Main_Page Fail2ban] is an excellent tool that can be used both to combat simple DDoS attacks but also to detect and block brute force login attempts.<br />
</li><br />
</ol><br />
<ul><br />
'''Apache hardening'''<br />
<br />
As well as considering the physical server and it's operating system users must thinking in terms of application security. Especially for those applications which either contain sensitive data or those that provide access routes to the machine for an attacker.<br />
<br />
Below is a set of guides for Apache webserver hardening.<br />
<li><br />
[http://www.tecmint.com/apache-security-tips/ 13 Apache Web Server Security and Hardening Tips]<br />
<li><br />
[http://xianshield.org/guides/apache2.0guide.html Apache 2.0 Hardening Guide]<br />
</li><br />
</ul><br />
<ul><br />
'''Database hardening'''<br />
<br />
A key approach discussed elsewhere in protecting data, both at rest - on disk - and in use - in memory, is to encrypt these data stores either as part of full disk encryption or as individual restricted encrypted mount points.<br />
<br />
Below are further guides for specific hardening techniques for the MySQL database system.<br />
<li><br />
[http://www.greensql.com/content/mysql-security-best-practices-hardening-mysql-tips MySQL Security Best Practices]<br />
</li><br />
<li><br />
[http://rochakchauhan.com/blog/2013/11/19/security-and-hardening-tips-for-mysql/ Security and Hardening Tips for MySQL]<br />
</li><br />
<li><br />
[http://www.securethelock.com/2014/01/09/12-steps-for-hardening-mysql-from-attackers/ 12 steps for Hardening MySQL from Attackers]<br />
</li><br />
</ul><br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted platform===<br />
For organisation that wish to setup their own custom site based on an existing platform such as Wordpress.com, there are a setup of steps that should be taken to ensure a good level of security. The [[Choosing_A_Host | choosing a hosting provider]] guide should also be consulted.<br />
<br />
'''Platform Security'''<br />
<ol><br />
<li><br />
Limiting access - Making smart choices that reduce possible entry points available to a malicious person.<br />
</li><br />
<li>Containment - Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.<br />
</li><br />
<li>Preparation and knowledge - Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.<br />
</li><br />
<li><br />
Passwords<br />
</li><br />
<li><br />
File Permissions<br />
</li><br />
<li><br />
Admin user<br />
</li><br />
<li><br />
SSL<br />
</li><br />
<li><br />
SFTP client<br />
</li><br />
<li><br />
Platform updates<br />
</li><br />
</ol><br />
Hosting install of pre-built software platform, such as Wordpress,<br />
<br />
===Shared Hosting===<br />
In a [[Shared_Hosting|Shared Hosting]] environment, your and other website owners shared one server. This includes sharing the physical server and the software applications within the server. Shared hosting services are affordable because the cost to operate the server is shared between you and these other owners. There are, however, a number of down sides, such as being slower.<br />
<br />
'''Examples:'''<br />
* http://www.easyweb.com<br />
* http://www.dreamhost.com/web-hosting/<br />
* http://wpengine.com/ (wordpress only)<br />
<br />
===Threat Mitigation===<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
For a basic setup providing a content distribution platform such as a blog users have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
<br />
<br />
===Threat Mitigation===<br />
<br />
<ol><br />
<li><br />
'''Strong Passwords''' are a core element of any system. The access password for the host should be restricted to those individuals with the organisation that work directly with the server.<br />
<br />
Safe password creation and storage procedures should be followed, as described [|here]<br />
</li><br />
<li><br />
'''Malware''' is core vulnerability for the devices used by those managing and logging into the hosted system. Malware, keyloggers and viruses provided a straightforward means of attack.<br />
<br><br />
The attacker does not need to hack or compromise the server, instead via infection through phishing emails or malicious websites the attacker can log and store the passwords and other critical information.<br />
<br><br />
To mitigate this threat all individuals who work with or have login access to the server must have anti-virus installed, a firewall and have an up to date system. For more information [|see]<br />
</li><br />
<li><br />
'''Two factor Authentication''' should be enabled where available as this will make compromising a system significantly more difficult.<br />
</li><br />
<li><br />
'''Wordpress Security''' is described in detail in the following [http://codex.wordpress.org/Hardening_WordPress guide]. <br />
</li><br />
</ol><br />
</div><br />
<br />
</div><br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''Dedicated Server'''<br />
| style="padding: 5px;"| '''Virtual Private Server'''<br />
| style="padding: 5px;"| '''Shared Hosting'''<br />
| style="padding: 5px;"| '''Cloud Service'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Requires Intermediary technical skill<br />
| style="padding: 5px;"| Intermediary/Basic<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows disk/data encryption<br />
| style="padding: 5px;"| Allows encryption within VPS<br />
| style="padding: 5px;"| Limited or no control of data encryption<br />
| style="padding: 5px;"| Depends on provider but usually not provided<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| SSH and private key login<br />
| style="padding: 5px;"| Enforce secure login for VPS<br />
| style="padding: 5px;"| Login via CPanel or Custom interface - some hosts offer 2 factor auth<br />
| style="padding: 5px;"| Depends<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| User access control and restriction<br />
| style="padding: 5px;"| User control<br />
| style="padding: 5px;"| Control via user accounts added through management software<br />
| style="padding: 5px;"| Control via management software<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| Allows only shared SSL cert, most host provide shared cert<br />
| style="padding: 5px;"| Most host platforms will provide SSL support by default<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Total control of applications and software<br />
| style="padding: 5px;"| Control of software within VM, limited access to hardware depending on type of VM<br />
| style="padding: 5px;"| Application control only via management interface<br />
| style="padding: 5px;"| Depends on cloud server - certain services with provide data access restrictions but this is a non-ideal scenario<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Manually maintained and updated<br />
| style="padding: 5px;"| Server is patched but VPS remains responsibility of user<br />
| style="padding: 5px;"| Patches and updates provided by host - though may lag behind depending on quality of hosting<br />
| style="padding: 5px;"| Depending on scale of provider - patching and support will be provided to protect their reputation<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Limited supported - hardware support and replacement depending on provider<br />
| style="padding: 5px;"| Similar to dedicated support<br />
| style="padding: 5px;"| Support is generally in terms of management software - hardware is automatically monitored by hosts<br />
| style="padding: 5px;"| Similar to shared though support is specific to the platform hosting<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Anti-ddos and brute forcing via fail2ban, botnetdbp deployment<br />
| style="padding: 5px;"| Provider may or may not mitigate DDoS attacks<br />
| style="padding: 5px;"| DDoS attacks will receive some or limited mitigation depending on quality of host, generally they will not protect against large scale attacks and may force the website to be removed<br />
| style="padding: 5px;"| Depending on the provider if the attack crosses their threshold for protection they may shut down the website or ask it to leave<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/Choose_a_hosting_providerChoose a hosting provider2014-05-26T15:15:01Z<p>Bill: /* Criteria */</p>
<hr />
<div>__NOTOC__<br />
===Criteria===<br />
<br />
There are several aspects which should be considered when selecting a service host. Below is a general list, this [https://pad.riseup.net/p/rh_ispq document] gives detailed information on each area.<br />
<br />
*Price - relative services offered<br />
*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.<br />
*Specialisation - do they work in the field of human rights, software applications or general hosting<br />
*Is mail provided<br />
*Hardware specifications<br />
*Operating systems offered<br />
*Supported provided<br />
*Readily discusses your security concerns and which security features and processes they offer with their hosting.<br />
*Provides the most recent stable versions of all server software.<br />
*Provides reliable methods for backup and recovery.<br />
*Provides encryption options for hosting of sites or mail<br />
<br />
===Features===<br />
It is quite important to consider the possibilities offered by your provider's control panel. If you need to write a support ticket everytime the server has to reboot, it wont be an efficient process, especially during a crises. Possible features to look out for include<br />
<br />
* Automated operating system installs<br />
* Server boot and reboot<br />
* Remote console (sometimes known as KVM)<br />
* Server and network statistics<br />
* Dynamic components (e.g. adding extra disk space, RAM without rebuilding the machine or having to order a new service)<br />
* Server access (varies between SSH, SFTP or web based)<br />
*<br />
<br />
==Secure hosting setups==<br />
Depending on available skill level the following secure system setups are possible:<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===Dedicated Server===<br />
For a [[Dedicated_Hosting | Dedicated Hosting]] system, the user can either run their own physical hardware or rent this hardware from a provider. The former solution offers total control of the physical hardware, however, there are significant downsides to this approach and should be avoided; it is only recommend under special circumstances such as [[Sensitive_Data | storing sensitive data]]. In the latter case, the hosting agent provides the hardware but the user has total control of the server via remote access. In this scenario, the provider is responsible for replacement of hardware parts that fail or malfunction - this support is generally done through a ticket system and relies on the user to report errors.<br />
<br />
'''Examples'''<br />
* http://www.ovh.com/ca/en/dedicated-servers/hosting/<br />
* http://www.soyoustart.com/ie/offers.xml<br />
* http://www.hetzner.de/en/hosting/produktmatrix/rootserver<br />
* http://www.coolhousing.net/hosting-dedicated-servers.html<br />
<br />
'''Benefits'''<br />
*User has total control of the system's software<br />
*User has total control of access rights<br />
*User has control of physical network connection, allowing them to whitelist or block connection from allowed or spurious connections<br />
*Financial cost of hardware malfunction is not an issue as the host is responsible for replacing/repairing failing hardware<br />
*The host can be chosen to place the server in a different jurisdiction from that of the user to prevent seizure<br />
<br />
'''Downsides'''<br />
*The user does not have physical access to the server<br />
*The host is not responsible for data loss or downtime if the physical server fails<br />
*The user is responsible for detecting and reporting hardware faults on some providers<br />
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].<br />
*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.<br />
<br />
===VPS===<br />
A Virtual Private Server(VPS) is an instance of a Virtual Operating System running on a much larger server. Typically multiple VPS will be run on a single server. In a VPS environment, you have a dedicated virtual private server but do not control the server on which it is hosted. Resources will be limited, you can not control or harden the outer server.<br />
<br />
'''Examples'''<br />
* https://www.linode.com/pricing<br />
* https://chhost.net/virtual-server/<br />
* https://www.tilaa.com/orders/add<br />
<br />
'''Benefits'''<br />
*The cost of this type of server will typically be significantly cheaper than a dedicated server<br />
*Depending on the host, the server will be capable of running most standard server software, up to a certain limit<br />
*Hardware is managed by the hosting provider unless self hosting<br />
*If self hosting, a single server can be used for multiple purposes and to provide multiple distinct servers<br />
<br />
'''Downsides'''<br />
*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<br />
*Bandwidth will also be restricted<br />
*Potential risk of provider, law enforcement or other state forces accessing contents of virtual server without user's awareness. <br />
*The user will not have access to the outer server and will thus not be able to harden it<br />
<br />
===Threats===<br />
*Social engineering attack<br />
*Password brute force<br />
*Service interruption through denial of service attack<br />
*System software exploits<br />
*SSL man-in-the-middle attacks<br />
*Data loss or data theft<br />
<br />
===Mitigation===<br />
'''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.<br />
<ol><br />
<li><br />
Enforce strong password - a strong password should contain Upper and Lower case characters, Numbers and Special Characters and should be long; greater than 20 characters. It is also possible to restrict the use of previously used passwords. On Linux systems the following command can be used to force complex passwords for users:<br />
</li><br />
password required pam_cracklib.so minlen=12 lcredit=1 ucredit=1 dcredit=2 ocredit=1<br />
<br />
For more detail, refer to the guide [http://www.linux-faqs.info/security/force-strong-passwords| Force strong passwords]<br />
<li><br />
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].<br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
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]<br />
</li><br />
</ol><br />
'''User Management''' on dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<ol><br />
<li><br />
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.<br />
</li><br />
<li><br />
Secure Shell(SSH) login should be forced, telnet and ftp login access should be disabled by default. To upload files to the server securely user can use Secure FTP(SFTP) clients. <br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
File permissions should be restricted for critical files. User should only be allowed access to files relevant to their work. Execution as root should be restricted. Discussion of [http://www.linux.com/learn/tutorials/309527-understanding-linux-file-permissions| linux file permissions].<br />
</li><br />
</ol><br />
'''Software Management'''<br />
<ol><br />
<li><br />
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].<br />
</li><br />
<li><br />
Minimising installed software is an important step in reducing potential vulnerabilities. The system should have the bare minimum of packages and software installed to support its purpose.<br />
</li><br />
</ol><br />
'''System Management'''<br />
<ol><br />
<li><br />
Firewall can be enabled via [http://www.netfilter.org/projects/iptables/| iptables] the guides [http://www.tecmint.com/basic-guide-on-iptables-linux-firewall-tips-commands/| here] and [http://www.cyberciti.biz/faq/category/iptables/| here] describe iptables configuration.<br />
</li><br />
<li><br />
To protect the server it is important to audit the open ports on the machine. To check listening ports you can run<br />
<br><br />
netstat -tulpn<br />
<br />
<br />
</li><br />
<li><br />
Logging and Auditing is a key aspect of server security. All hacking, brute force, DDoS or other attacks should be captured, monitored and analysed. <br />
<br><br />
This [http://www.cyberciti.biz/faq/linux-log-files-location-and-how-do-i-view-logs-files/| guide] describes the location and purpose of common Linux log files.<br />
<br />
<br><br />
<br />
To ensure that information is not lost, overwritten or that the logs do not grow infinitely the tool [http://www.thegeekstuff.com/2010/07/logrotate-examples/| Logrotate] can be used.<br />
<br><br />
<br />
Installing a tool like Logwatch allows you to monitor and respond to suspicious activity. The following [https://www.digitalocean.com/community/articles/how-to-install-and-use-logwatch-log-analyzer-and-reporter-on-a-vps| guide] describes installing and configuring Logwatch.<br />
</li><br />
<li><br />
[http://selinuxproject.org/page/Main_Page| Security Enhanced Linux(SELinux)] is a kernel level security control mechanism, which enforces a set of rules and procedures for the system. SELinux provides fine grained control for access rights and permissions.<br />
<br><br />
To check if it is enabled run<br />
<br><br />
<i><br />
sestatus<br />
</i><br />
<br><br />
To enable run<br />
<br><br />
<i><br />
setenforce enforcing<br />
</i><br />
<br><br />
To adjust the SELinux config is available at<br />
<br><br />
<i><br />
/etc/selinux/config <br />
</i><br />
</li><br />
<li><br />
[http://www.fail2ban.org/wiki/index.php/Main_Page| Fail2ban] is an excellent tool that can be used both to combat simple DDoS attacks but also to detect and block brute force login attempts.<br />
</li><br />
</ol><br />
<ul><br />
'''Apache hardening'''<br />
<br />
As well as considering the physical server and it's operating system users must thinking in terms of application security. Especially for those applications which either contain sensitive data or those that provide access routes to the machine for an attacker.<br />
<br />
Below is a set of guides for Apache webserver hardening.<br />
<li><br />
[http://www.tecmint.com/apache-security-tips/| 13 Apache Web Server Security and Hardening Tips]<br />
<li><br />
[http://xianshield.org/guides/apache2.0guide.html| Apache 2.0 Hardening Guide]<br />
</li><br />
</ul><br />
<ul><br />
'''Database hardening'''<br />
<br />
A key approach discussed elsewhere in protecting data, both at rest - on disk - and in use - in memory, is to encrypt these data stores either as part of full disk encryption or as individual restricted encrypted mount points.<br />
<br />
Below are further guides for specific hardening techniques for the MySQL database system.<br />
<li><br />
[http://www.greensql.com/content/mysql-security-best-practices-hardening-mysql-tips| MySQL Security Best Practices]<br />
</li><br />
<li><br />
[http://rochakchauhan.com/blog/2013/11/19/security-and-hardening-tips-for-mysql/| Security and Hardening Tips for MySQL]<br />
</li><br />
<li><br />
[http://www.securethelock.com/2014/01/09/12-steps-for-hardening-mysql-from-attackers/| 12 steps for Hardening MySQL from Attackers]<br />
</li><br />
</ul><br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted platform===<br />
For organisation that wish to setup their own custom site based on an existing platform such as Wordpress.com, there are a setup of steps that should be taken to ensure a good level of security. The [[Choosing_A_Host | choosing a hosting provider]] guide should also be consulted.<br />
<br />
'''Platform Security'''<br />
<ol><br />
<li><br />
Limiting access - Making smart choices that reduce possible entry points available to a malicious person.<br />
</li><br />
<li>Containment - Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.<br />
</li><br />
<li>Preparation and knowledge - Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.<br />
</li><br />
<li><br />
Passwords<br />
</li><br />
<li><br />
File Permissions<br />
</li><br />
<li><br />
Admin user<br />
</li><br />
<li><br />
SSL<br />
</li><br />
<li><br />
SFTP client<br />
</li><br />
<li><br />
Platform updates<br />
</li><br />
</ol><br />
Hosting install of pre-built software platform, such as Wordpress,<br />
<br />
===Shared Hosting===<br />
In a [[Shared_Hosting|Shared Hosting]] environment, your and other website owners shared one server. This includes sharing the physical server and the software applications within the server. Shared hosting services are affordable because the cost to operate the server is shared between you and these other owners. There are, however, a number of down sides, such as being slower.<br />
<br />
'''Examples:'''<br />
* http://www.easyweb.com<br />
* http://www.dreamhost.com/web-hosting/<br />
* http://wpengine.com/ (wordpress only)<br />
<br />
===Threat Mitigation===<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
For a basic setup providing a content distribution platform such as a blog users have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
<br />
<br />
===Threat Mitigation===<br />
<br />
<ol><br />
<li><br />
'''Strong Passwords''' are a core element of any system. The access password for the host should be restricted to those individuals with the organisation that work directly with the server.<br />
<br />
Safe password creation and storage procedures should be followed, as described [|here]<br />
</li><br />
<li><br />
'''Malware''' is core vulnerability for the devices used by those managing and logging into the hosted system. Malware, keyloggers and viruses provided a straightforward means of attack.<br />
<br><br />
The attacker does not need to hack or compromise the server, instead via infection through phishing emails or malicious websites the attacker can log and store the passwords and other critical information.<br />
<br><br />
To mitigate this threat all individuals who work with or have login access to the server must have anti-virus installed, a firewall and have an up to date system. For more information [|see]<br />
</li><br />
<li><br />
'''Two factor Authentication''' should be enabled where available as this will make compromising a system significantly more difficult.<br />
</li><br />
<li><br />
'''Wordpress Security''' is described in detail in the following [http://codex.wordpress.org/Hardening_WordPress| guide]. <br />
</li><br />
</ol><br />
</div><br />
<br />
</div><br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''Dedicated Server'''<br />
| style="padding: 5px;"| '''Virtual Private Server'''<br />
| style="padding: 5px;"| '''Shared Hosting'''<br />
| style="padding: 5px;"| '''Cloud Service'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Requires Intermediary technical skill<br />
| style="padding: 5px;"| Intermediary/Basic<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows disk/data encryption<br />
| style="padding: 5px;"| Allows encryption within VPS<br />
| style="padding: 5px;"| Limited or no control of data encryption<br />
| style="padding: 5px;"| Depends on provider but usually not provided<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| SSH and private key login<br />
| style="padding: 5px;"| Enforce secure login for VPS<br />
| style="padding: 5px;"| Login via CPanel or Custom interface - some hosts offer 2 factor auth<br />
| style="padding: 5px;"| Depends<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| User access control and restriction<br />
| style="padding: 5px;"| User control<br />
| style="padding: 5px;"| Control via user accounts added through management software<br />
| style="padding: 5px;"| Control via management software<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| Allows only shared SSL cert, most host provide shared cert<br />
| style="padding: 5px;"| Most host platforms will provide SSL support by default<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Total control of applications and software<br />
| style="padding: 5px;"| Control of software within VM, limited access to hardware depending on type of VM<br />
| style="padding: 5px;"| Application control only via management interface<br />
| style="padding: 5px;"| Depends on cloud server - certain services with provide data access restrictions but this is a non-ideal scenario<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Manually maintained and updated<br />
| style="padding: 5px;"| Server is patched but VPS remains responsibility of user<br />
| style="padding: 5px;"| Patches and updates provided by host - though may lag behind depending on quality of hosting<br />
| style="padding: 5px;"| Depending on scale of provider - patching and support will be provided to protect their reputation<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Limited supported - hardware support and replacement depending on provider<br />
| style="padding: 5px;"| Similar to dedicated support<br />
| style="padding: 5px;"| Support is generally in terms of management software - hardware is automatically monitored by hosts<br />
| style="padding: 5px;"| Similar to shared though support is specific to the platform hosting<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Anti-ddos and brute forcing via fail2ban, botnetdbp deployment<br />
| style="padding: 5px;"| Provider may or may not mitigate DDoS attacks<br />
| style="padding: 5px;"| DDoS attacks will receive some or limited mitigation depending on quality of host, generally they will not protect against large scale attacks and may force the website to be removed<br />
| style="padding: 5px;"| Depending on the provider if the attack crosses their threshold for protection they may shut down the website or ask it to leave<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/Choose_a_hosting_providerChoose a hosting provider2014-05-26T15:14:47Z<p>Bill: /* Criteria */</p>
<hr />
<div>__NOTOC__<br />
===Criteria===<br />
<br />
There are several aspects which should be considered when selecting a service host. Below is a general list, this [https://pad.riseup.net/p/rh_ispq |document] gives detailed information on each area.<br />
<br />
*Price - relative services offered<br />
*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.<br />
*Specialisation - do they work in the field of human rights, software applications or general hosting<br />
*Is mail provided<br />
*Hardware specifications<br />
*Operating systems offered<br />
*Supported provided<br />
*Readily discusses your security concerns and which security features and processes they offer with their hosting.<br />
*Provides the most recent stable versions of all server software.<br />
*Provides reliable methods for backup and recovery.<br />
*Provides encryption options for hosting of sites or mail<br />
<br />
===Features===<br />
It is quite important to consider the possibilities offered by your provider's control panel. If you need to write a support ticket everytime the server has to reboot, it wont be an efficient process, especially during a crises. Possible features to look out for include<br />
<br />
* Automated operating system installs<br />
* Server boot and reboot<br />
* Remote console (sometimes known as KVM)<br />
* Server and network statistics<br />
* Dynamic components (e.g. adding extra disk space, RAM without rebuilding the machine or having to order a new service)<br />
* Server access (varies between SSH, SFTP or web based)<br />
*<br />
<br />
==Secure hosting setups==<br />
Depending on available skill level the following secure system setups are possible:<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===Dedicated Server===<br />
For a [[Dedicated_Hosting | Dedicated Hosting]] system, the user can either run their own physical hardware or rent this hardware from a provider. The former solution offers total control of the physical hardware, however, there are significant downsides to this approach and should be avoided; it is only recommend under special circumstances such as [[Sensitive_Data | storing sensitive data]]. In the latter case, the hosting agent provides the hardware but the user has total control of the server via remote access. In this scenario, the provider is responsible for replacement of hardware parts that fail or malfunction - this support is generally done through a ticket system and relies on the user to report errors.<br />
<br />
'''Examples'''<br />
* http://www.ovh.com/ca/en/dedicated-servers/hosting/<br />
* http://www.soyoustart.com/ie/offers.xml<br />
* http://www.hetzner.de/en/hosting/produktmatrix/rootserver<br />
* http://www.coolhousing.net/hosting-dedicated-servers.html<br />
<br />
'''Benefits'''<br />
*User has total control of the system's software<br />
*User has total control of access rights<br />
*User has control of physical network connection, allowing them to whitelist or block connection from allowed or spurious connections<br />
*Financial cost of hardware malfunction is not an issue as the host is responsible for replacing/repairing failing hardware<br />
*The host can be chosen to place the server in a different jurisdiction from that of the user to prevent seizure<br />
<br />
'''Downsides'''<br />
*The user does not have physical access to the server<br />
*The host is not responsible for data loss or downtime if the physical server fails<br />
*The user is responsible for detecting and reporting hardware faults on some providers<br />
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].<br />
*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.<br />
<br />
===VPS===<br />
A Virtual Private Server(VPS) is an instance of a Virtual Operating System running on a much larger server. Typically multiple VPS will be run on a single server. In a VPS environment, you have a dedicated virtual private server but do not control the server on which it is hosted. Resources will be limited, you can not control or harden the outer server.<br />
<br />
'''Examples'''<br />
* https://www.linode.com/pricing<br />
* https://chhost.net/virtual-server/<br />
* https://www.tilaa.com/orders/add<br />
<br />
'''Benefits'''<br />
*The cost of this type of server will typically be significantly cheaper than a dedicated server<br />
*Depending on the host, the server will be capable of running most standard server software, up to a certain limit<br />
*Hardware is managed by the hosting provider unless self hosting<br />
*If self hosting, a single server can be used for multiple purposes and to provide multiple distinct servers<br />
<br />
'''Downsides'''<br />
*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<br />
*Bandwidth will also be restricted<br />
*Potential risk of provider, law enforcement or other state forces accessing contents of virtual server without user's awareness. <br />
*The user will not have access to the outer server and will thus not be able to harden it<br />
<br />
===Threats===<br />
*Social engineering attack<br />
*Password brute force<br />
*Service interruption through denial of service attack<br />
*System software exploits<br />
*SSL man-in-the-middle attacks<br />
*Data loss or data theft<br />
<br />
===Mitigation===<br />
'''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.<br />
<ol><br />
<li><br />
Enforce strong password - a strong password should contain Upper and Lower case characters, Numbers and Special Characters and should be long; greater than 20 characters. It is also possible to restrict the use of previously used passwords. On Linux systems the following command can be used to force complex passwords for users:<br />
</li><br />
password required pam_cracklib.so minlen=12 lcredit=1 ucredit=1 dcredit=2 ocredit=1<br />
<br />
For more detail, refer to the guide [http://www.linux-faqs.info/security/force-strong-passwords| Force strong passwords]<br />
<li><br />
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].<br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
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]<br />
</li><br />
</ol><br />
'''User Management''' on dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<ol><br />
<li><br />
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.<br />
</li><br />
<li><br />
Secure Shell(SSH) login should be forced, telnet and ftp login access should be disabled by default. To upload files to the server securely user can use Secure FTP(SFTP) clients. <br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
File permissions should be restricted for critical files. User should only be allowed access to files relevant to their work. Execution as root should be restricted. Discussion of [http://www.linux.com/learn/tutorials/309527-understanding-linux-file-permissions| linux file permissions].<br />
</li><br />
</ol><br />
'''Software Management'''<br />
<ol><br />
<li><br />
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].<br />
</li><br />
<li><br />
Minimising installed software is an important step in reducing potential vulnerabilities. The system should have the bare minimum of packages and software installed to support its purpose.<br />
</li><br />
</ol><br />
'''System Management'''<br />
<ol><br />
<li><br />
Firewall can be enabled via [http://www.netfilter.org/projects/iptables/| iptables] the guides [http://www.tecmint.com/basic-guide-on-iptables-linux-firewall-tips-commands/| here] and [http://www.cyberciti.biz/faq/category/iptables/| here] describe iptables configuration.<br />
</li><br />
<li><br />
To protect the server it is important to audit the open ports on the machine. To check listening ports you can run<br />
<br><br />
netstat -tulpn<br />
<br />
<br />
</li><br />
<li><br />
Logging and Auditing is a key aspect of server security. All hacking, brute force, DDoS or other attacks should be captured, monitored and analysed. <br />
<br><br />
This [http://www.cyberciti.biz/faq/linux-log-files-location-and-how-do-i-view-logs-files/| guide] describes the location and purpose of common Linux log files.<br />
<br />
<br><br />
<br />
To ensure that information is not lost, overwritten or that the logs do not grow infinitely the tool [http://www.thegeekstuff.com/2010/07/logrotate-examples/| Logrotate] can be used.<br />
<br><br />
<br />
Installing a tool like Logwatch allows you to monitor and respond to suspicious activity. The following [https://www.digitalocean.com/community/articles/how-to-install-and-use-logwatch-log-analyzer-and-reporter-on-a-vps| guide] describes installing and configuring Logwatch.<br />
</li><br />
<li><br />
[http://selinuxproject.org/page/Main_Page| Security Enhanced Linux(SELinux)] is a kernel level security control mechanism, which enforces a set of rules and procedures for the system. SELinux provides fine grained control for access rights and permissions.<br />
<br><br />
To check if it is enabled run<br />
<br><br />
<i><br />
sestatus<br />
</i><br />
<br><br />
To enable run<br />
<br><br />
<i><br />
setenforce enforcing<br />
</i><br />
<br><br />
To adjust the SELinux config is available at<br />
<br><br />
<i><br />
/etc/selinux/config <br />
</i><br />
</li><br />
<li><br />
[http://www.fail2ban.org/wiki/index.php/Main_Page| Fail2ban] is an excellent tool that can be used both to combat simple DDoS attacks but also to detect and block brute force login attempts.<br />
</li><br />
</ol><br />
<ul><br />
'''Apache hardening'''<br />
<br />
As well as considering the physical server and it's operating system users must thinking in terms of application security. Especially for those applications which either contain sensitive data or those that provide access routes to the machine for an attacker.<br />
<br />
Below is a set of guides for Apache webserver hardening.<br />
<li><br />
[http://www.tecmint.com/apache-security-tips/| 13 Apache Web Server Security and Hardening Tips]<br />
<li><br />
[http://xianshield.org/guides/apache2.0guide.html| Apache 2.0 Hardening Guide]<br />
</li><br />
</ul><br />
<ul><br />
'''Database hardening'''<br />
<br />
A key approach discussed elsewhere in protecting data, both at rest - on disk - and in use - in memory, is to encrypt these data stores either as part of full disk encryption or as individual restricted encrypted mount points.<br />
<br />
Below are further guides for specific hardening techniques for the MySQL database system.<br />
<li><br />
[http://www.greensql.com/content/mysql-security-best-practices-hardening-mysql-tips| MySQL Security Best Practices]<br />
</li><br />
<li><br />
[http://rochakchauhan.com/blog/2013/11/19/security-and-hardening-tips-for-mysql/| Security and Hardening Tips for MySQL]<br />
</li><br />
<li><br />
[http://www.securethelock.com/2014/01/09/12-steps-for-hardening-mysql-from-attackers/| 12 steps for Hardening MySQL from Attackers]<br />
</li><br />
</ul><br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted platform===<br />
For organisation that wish to setup their own custom site based on an existing platform such as Wordpress.com, there are a setup of steps that should be taken to ensure a good level of security. The [[Choosing_A_Host | choosing a hosting provider]] guide should also be consulted.<br />
<br />
'''Platform Security'''<br />
<ol><br />
<li><br />
Limiting access - Making smart choices that reduce possible entry points available to a malicious person.<br />
</li><br />
<li>Containment - Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.<br />
</li><br />
<li>Preparation and knowledge - Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.<br />
</li><br />
<li><br />
Passwords<br />
</li><br />
<li><br />
File Permissions<br />
</li><br />
<li><br />
Admin user<br />
</li><br />
<li><br />
SSL<br />
</li><br />
<li><br />
SFTP client<br />
</li><br />
<li><br />
Platform updates<br />
</li><br />
</ol><br />
Hosting install of pre-built software platform, such as Wordpress,<br />
<br />
===Shared Hosting===<br />
In a [[Shared_Hosting|Shared Hosting]] environment, your and other website owners shared one server. This includes sharing the physical server and the software applications within the server. Shared hosting services are affordable because the cost to operate the server is shared between you and these other owners. There are, however, a number of down sides, such as being slower.<br />
<br />
'''Examples:'''<br />
* http://www.easyweb.com<br />
* http://www.dreamhost.com/web-hosting/<br />
* http://wpengine.com/ (wordpress only)<br />
<br />
===Threat Mitigation===<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
For a basic setup providing a content distribution platform such as a blog users have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
<br />
<br />
===Threat Mitigation===<br />
<br />
<ol><br />
<li><br />
'''Strong Passwords''' are a core element of any system. The access password for the host should be restricted to those individuals with the organisation that work directly with the server.<br />
<br />
Safe password creation and storage procedures should be followed, as described [|here]<br />
</li><br />
<li><br />
'''Malware''' is core vulnerability for the devices used by those managing and logging into the hosted system. Malware, keyloggers and viruses provided a straightforward means of attack.<br />
<br><br />
The attacker does not need to hack or compromise the server, instead via infection through phishing emails or malicious websites the attacker can log and store the passwords and other critical information.<br />
<br><br />
To mitigate this threat all individuals who work with or have login access to the server must have anti-virus installed, a firewall and have an up to date system. For more information [|see]<br />
</li><br />
<li><br />
'''Two factor Authentication''' should be enabled where available as this will make compromising a system significantly more difficult.<br />
</li><br />
<li><br />
'''Wordpress Security''' is described in detail in the following [http://codex.wordpress.org/Hardening_WordPress| guide]. <br />
</li><br />
</ol><br />
</div><br />
<br />
</div><br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''Dedicated Server'''<br />
| style="padding: 5px;"| '''Virtual Private Server'''<br />
| style="padding: 5px;"| '''Shared Hosting'''<br />
| style="padding: 5px;"| '''Cloud Service'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Requires Intermediary technical skill<br />
| style="padding: 5px;"| Intermediary/Basic<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows disk/data encryption<br />
| style="padding: 5px;"| Allows encryption within VPS<br />
| style="padding: 5px;"| Limited or no control of data encryption<br />
| style="padding: 5px;"| Depends on provider but usually not provided<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| SSH and private key login<br />
| style="padding: 5px;"| Enforce secure login for VPS<br />
| style="padding: 5px;"| Login via CPanel or Custom interface - some hosts offer 2 factor auth<br />
| style="padding: 5px;"| Depends<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| User access control and restriction<br />
| style="padding: 5px;"| User control<br />
| style="padding: 5px;"| Control via user accounts added through management software<br />
| style="padding: 5px;"| Control via management software<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| Allows only shared SSL cert, most host provide shared cert<br />
| style="padding: 5px;"| Most host platforms will provide SSL support by default<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Total control of applications and software<br />
| style="padding: 5px;"| Control of software within VM, limited access to hardware depending on type of VM<br />
| style="padding: 5px;"| Application control only via management interface<br />
| style="padding: 5px;"| Depends on cloud server - certain services with provide data access restrictions but this is a non-ideal scenario<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Manually maintained and updated<br />
| style="padding: 5px;"| Server is patched but VPS remains responsibility of user<br />
| style="padding: 5px;"| Patches and updates provided by host - though may lag behind depending on quality of hosting<br />
| style="padding: 5px;"| Depending on scale of provider - patching and support will be provided to protect their reputation<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Limited supported - hardware support and replacement depending on provider<br />
| style="padding: 5px;"| Similar to dedicated support<br />
| style="padding: 5px;"| Support is generally in terms of management software - hardware is automatically monitored by hosts<br />
| style="padding: 5px;"| Similar to shared though support is specific to the platform hosting<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Anti-ddos and brute forcing via fail2ban, botnetdbp deployment<br />
| style="padding: 5px;"| Provider may or may not mitigate DDoS attacks<br />
| style="padding: 5px;"| DDoS attacks will receive some or limited mitigation depending on quality of host, generally they will not protect against large scale attacks and may force the website to be removed<br />
| style="padding: 5px;"| Depending on the provider if the attack crosses their threshold for protection they may shut down the website or ask it to leave<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/Choose_a_hosting_providerChoose a hosting provider2014-05-26T15:14:34Z<p>Bill: /* Criteria */</p>
<hr />
<div>__NOTOC__<br />
===Criteria===<br />
<br />
There are several aspects which should be considered when selecting a service host. Below is a general list, this [https://pad.riseup.net/p/rh_ispq | document] gives detailed information on each area.<br />
<br />
*Price - relative services offered<br />
*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.<br />
*Specialisation - do they work in the field of human rights, software applications or general hosting<br />
*Is mail provided<br />
*Hardware specifications<br />
*Operating systems offered<br />
*Supported provided<br />
*Readily discusses your security concerns and which security features and processes they offer with their hosting.<br />
*Provides the most recent stable versions of all server software.<br />
*Provides reliable methods for backup and recovery.<br />
*Provides encryption options for hosting of sites or mail<br />
<br />
===Features===<br />
It is quite important to consider the possibilities offered by your provider's control panel. If you need to write a support ticket everytime the server has to reboot, it wont be an efficient process, especially during a crises. Possible features to look out for include<br />
<br />
* Automated operating system installs<br />
* Server boot and reboot<br />
* Remote console (sometimes known as KVM)<br />
* Server and network statistics<br />
* Dynamic components (e.g. adding extra disk space, RAM without rebuilding the machine or having to order a new service)<br />
* Server access (varies between SSH, SFTP or web based)<br />
*<br />
<br />
==Secure hosting setups==<br />
Depending on available skill level the following secure system setups are possible:<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===Dedicated Server===<br />
For a [[Dedicated_Hosting | Dedicated Hosting]] system, the user can either run their own physical hardware or rent this hardware from a provider. The former solution offers total control of the physical hardware, however, there are significant downsides to this approach and should be avoided; it is only recommend under special circumstances such as [[Sensitive_Data | storing sensitive data]]. In the latter case, the hosting agent provides the hardware but the user has total control of the server via remote access. In this scenario, the provider is responsible for replacement of hardware parts that fail or malfunction - this support is generally done through a ticket system and relies on the user to report errors.<br />
<br />
'''Examples'''<br />
* http://www.ovh.com/ca/en/dedicated-servers/hosting/<br />
* http://www.soyoustart.com/ie/offers.xml<br />
* http://www.hetzner.de/en/hosting/produktmatrix/rootserver<br />
* http://www.coolhousing.net/hosting-dedicated-servers.html<br />
<br />
'''Benefits'''<br />
*User has total control of the system's software<br />
*User has total control of access rights<br />
*User has control of physical network connection, allowing them to whitelist or block connection from allowed or spurious connections<br />
*Financial cost of hardware malfunction is not an issue as the host is responsible for replacing/repairing failing hardware<br />
*The host can be chosen to place the server in a different jurisdiction from that of the user to prevent seizure<br />
<br />
'''Downsides'''<br />
*The user does not have physical access to the server<br />
*The host is not responsible for data loss or downtime if the physical server fails<br />
*The user is responsible for detecting and reporting hardware faults on some providers<br />
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].<br />
*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.<br />
<br />
===VPS===<br />
A Virtual Private Server(VPS) is an instance of a Virtual Operating System running on a much larger server. Typically multiple VPS will be run on a single server. In a VPS environment, you have a dedicated virtual private server but do not control the server on which it is hosted. Resources will be limited, you can not control or harden the outer server.<br />
<br />
'''Examples'''<br />
* https://www.linode.com/pricing<br />
* https://chhost.net/virtual-server/<br />
* https://www.tilaa.com/orders/add<br />
<br />
'''Benefits'''<br />
*The cost of this type of server will typically be significantly cheaper than a dedicated server<br />
*Depending on the host, the server will be capable of running most standard server software, up to a certain limit<br />
*Hardware is managed by the hosting provider unless self hosting<br />
*If self hosting, a single server can be used for multiple purposes and to provide multiple distinct servers<br />
<br />
'''Downsides'''<br />
*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<br />
*Bandwidth will also be restricted<br />
*Potential risk of provider, law enforcement or other state forces accessing contents of virtual server without user's awareness. <br />
*The user will not have access to the outer server and will thus not be able to harden it<br />
<br />
===Threats===<br />
*Social engineering attack<br />
*Password brute force<br />
*Service interruption through denial of service attack<br />
*System software exploits<br />
*SSL man-in-the-middle attacks<br />
*Data loss or data theft<br />
<br />
===Mitigation===<br />
'''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.<br />
<ol><br />
<li><br />
Enforce strong password - a strong password should contain Upper and Lower case characters, Numbers and Special Characters and should be long; greater than 20 characters. It is also possible to restrict the use of previously used passwords. On Linux systems the following command can be used to force complex passwords for users:<br />
</li><br />
password required pam_cracklib.so minlen=12 lcredit=1 ucredit=1 dcredit=2 ocredit=1<br />
<br />
For more detail, refer to the guide [http://www.linux-faqs.info/security/force-strong-passwords| Force strong passwords]<br />
<li><br />
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].<br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
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]<br />
</li><br />
</ol><br />
'''User Management''' on dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<ol><br />
<li><br />
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.<br />
</li><br />
<li><br />
Secure Shell(SSH) login should be forced, telnet and ftp login access should be disabled by default. To upload files to the server securely user can use Secure FTP(SFTP) clients. <br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
File permissions should be restricted for critical files. User should only be allowed access to files relevant to their work. Execution as root should be restricted. Discussion of [http://www.linux.com/learn/tutorials/309527-understanding-linux-file-permissions| linux file permissions].<br />
</li><br />
</ol><br />
'''Software Management'''<br />
<ol><br />
<li><br />
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].<br />
</li><br />
<li><br />
Minimising installed software is an important step in reducing potential vulnerabilities. The system should have the bare minimum of packages and software installed to support its purpose.<br />
</li><br />
</ol><br />
'''System Management'''<br />
<ol><br />
<li><br />
Firewall can be enabled via [http://www.netfilter.org/projects/iptables/| iptables] the guides [http://www.tecmint.com/basic-guide-on-iptables-linux-firewall-tips-commands/| here] and [http://www.cyberciti.biz/faq/category/iptables/| here] describe iptables configuration.<br />
</li><br />
<li><br />
To protect the server it is important to audit the open ports on the machine. To check listening ports you can run<br />
<br><br />
netstat -tulpn<br />
<br />
<br />
</li><br />
<li><br />
Logging and Auditing is a key aspect of server security. All hacking, brute force, DDoS or other attacks should be captured, monitored and analysed. <br />
<br><br />
This [http://www.cyberciti.biz/faq/linux-log-files-location-and-how-do-i-view-logs-files/| guide] describes the location and purpose of common Linux log files.<br />
<br />
<br><br />
<br />
To ensure that information is not lost, overwritten or that the logs do not grow infinitely the tool [http://www.thegeekstuff.com/2010/07/logrotate-examples/| Logrotate] can be used.<br />
<br><br />
<br />
Installing a tool like Logwatch allows you to monitor and respond to suspicious activity. The following [https://www.digitalocean.com/community/articles/how-to-install-and-use-logwatch-log-analyzer-and-reporter-on-a-vps| guide] describes installing and configuring Logwatch.<br />
</li><br />
<li><br />
[http://selinuxproject.org/page/Main_Page| Security Enhanced Linux(SELinux)] is a kernel level security control mechanism, which enforces a set of rules and procedures for the system. SELinux provides fine grained control for access rights and permissions.<br />
<br><br />
To check if it is enabled run<br />
<br><br />
<i><br />
sestatus<br />
</i><br />
<br><br />
To enable run<br />
<br><br />
<i><br />
setenforce enforcing<br />
</i><br />
<br><br />
To adjust the SELinux config is available at<br />
<br><br />
<i><br />
/etc/selinux/config <br />
</i><br />
</li><br />
<li><br />
[http://www.fail2ban.org/wiki/index.php/Main_Page| Fail2ban] is an excellent tool that can be used both to combat simple DDoS attacks but also to detect and block brute force login attempts.<br />
</li><br />
</ol><br />
<ul><br />
'''Apache hardening'''<br />
<br />
As well as considering the physical server and it's operating system users must thinking in terms of application security. Especially for those applications which either contain sensitive data or those that provide access routes to the machine for an attacker.<br />
<br />
Below is a set of guides for Apache webserver hardening.<br />
<li><br />
[http://www.tecmint.com/apache-security-tips/| 13 Apache Web Server Security and Hardening Tips]<br />
<li><br />
[http://xianshield.org/guides/apache2.0guide.html| Apache 2.0 Hardening Guide]<br />
</li><br />
</ul><br />
<ul><br />
'''Database hardening'''<br />
<br />
A key approach discussed elsewhere in protecting data, both at rest - on disk - and in use - in memory, is to encrypt these data stores either as part of full disk encryption or as individual restricted encrypted mount points.<br />
<br />
Below are further guides for specific hardening techniques for the MySQL database system.<br />
<li><br />
[http://www.greensql.com/content/mysql-security-best-practices-hardening-mysql-tips| MySQL Security Best Practices]<br />
</li><br />
<li><br />
[http://rochakchauhan.com/blog/2013/11/19/security-and-hardening-tips-for-mysql/| Security and Hardening Tips for MySQL]<br />
</li><br />
<li><br />
[http://www.securethelock.com/2014/01/09/12-steps-for-hardening-mysql-from-attackers/| 12 steps for Hardening MySQL from Attackers]<br />
</li><br />
</ul><br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted platform===<br />
For organisation that wish to setup their own custom site based on an existing platform such as Wordpress.com, there are a setup of steps that should be taken to ensure a good level of security. The [[Choosing_A_Host | choosing a hosting provider]] guide should also be consulted.<br />
<br />
'''Platform Security'''<br />
<ol><br />
<li><br />
Limiting access - Making smart choices that reduce possible entry points available to a malicious person.<br />
</li><br />
<li>Containment - Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.<br />
</li><br />
<li>Preparation and knowledge - Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.<br />
</li><br />
<li><br />
Passwords<br />
</li><br />
<li><br />
File Permissions<br />
</li><br />
<li><br />
Admin user<br />
</li><br />
<li><br />
SSL<br />
</li><br />
<li><br />
SFTP client<br />
</li><br />
<li><br />
Platform updates<br />
</li><br />
</ol><br />
Hosting install of pre-built software platform, such as Wordpress,<br />
<br />
===Shared Hosting===<br />
In a [[Shared_Hosting|Shared Hosting]] environment, your and other website owners shared one server. This includes sharing the physical server and the software applications within the server. Shared hosting services are affordable because the cost to operate the server is shared between you and these other owners. There are, however, a number of down sides, such as being slower.<br />
<br />
'''Examples:'''<br />
* http://www.easyweb.com<br />
* http://www.dreamhost.com/web-hosting/<br />
* http://wpengine.com/ (wordpress only)<br />
<br />
===Threat Mitigation===<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
For a basic setup providing a content distribution platform such as a blog users have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
<br />
<br />
===Threat Mitigation===<br />
<br />
<ol><br />
<li><br />
'''Strong Passwords''' are a core element of any system. The access password for the host should be restricted to those individuals with the organisation that work directly with the server.<br />
<br />
Safe password creation and storage procedures should be followed, as described [|here]<br />
</li><br />
<li><br />
'''Malware''' is core vulnerability for the devices used by those managing and logging into the hosted system. Malware, keyloggers and viruses provided a straightforward means of attack.<br />
<br><br />
The attacker does not need to hack or compromise the server, instead via infection through phishing emails or malicious websites the attacker can log and store the passwords and other critical information.<br />
<br><br />
To mitigate this threat all individuals who work with or have login access to the server must have anti-virus installed, a firewall and have an up to date system. For more information [|see]<br />
</li><br />
<li><br />
'''Two factor Authentication''' should be enabled where available as this will make compromising a system significantly more difficult.<br />
</li><br />
<li><br />
'''Wordpress Security''' is described in detail in the following [http://codex.wordpress.org/Hardening_WordPress| guide]. <br />
</li><br />
</ol><br />
</div><br />
<br />
</div><br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''Dedicated Server'''<br />
| style="padding: 5px;"| '''Virtual Private Server'''<br />
| style="padding: 5px;"| '''Shared Hosting'''<br />
| style="padding: 5px;"| '''Cloud Service'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Requires Intermediary technical skill<br />
| style="padding: 5px;"| Intermediary/Basic<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows disk/data encryption<br />
| style="padding: 5px;"| Allows encryption within VPS<br />
| style="padding: 5px;"| Limited or no control of data encryption<br />
| style="padding: 5px;"| Depends on provider but usually not provided<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| SSH and private key login<br />
| style="padding: 5px;"| Enforce secure login for VPS<br />
| style="padding: 5px;"| Login via CPanel or Custom interface - some hosts offer 2 factor auth<br />
| style="padding: 5px;"| Depends<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| User access control and restriction<br />
| style="padding: 5px;"| User control<br />
| style="padding: 5px;"| Control via user accounts added through management software<br />
| style="padding: 5px;"| Control via management software<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| Allows only shared SSL cert, most host provide shared cert<br />
| style="padding: 5px;"| Most host platforms will provide SSL support by default<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Total control of applications and software<br />
| style="padding: 5px;"| Control of software within VM, limited access to hardware depending on type of VM<br />
| style="padding: 5px;"| Application control only via management interface<br />
| style="padding: 5px;"| Depends on cloud server - certain services with provide data access restrictions but this is a non-ideal scenario<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Manually maintained and updated<br />
| style="padding: 5px;"| Server is patched but VPS remains responsibility of user<br />
| style="padding: 5px;"| Patches and updates provided by host - though may lag behind depending on quality of hosting<br />
| style="padding: 5px;"| Depending on scale of provider - patching and support will be provided to protect their reputation<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Limited supported - hardware support and replacement depending on provider<br />
| style="padding: 5px;"| Similar to dedicated support<br />
| style="padding: 5px;"| Support is generally in terms of management software - hardware is automatically monitored by hosts<br />
| style="padding: 5px;"| Similar to shared though support is specific to the platform hosting<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Anti-ddos and brute forcing via fail2ban, botnetdbp deployment<br />
| style="padding: 5px;"| Provider may or may not mitigate DDoS attacks<br />
| style="padding: 5px;"| DDoS attacks will receive some or limited mitigation depending on quality of host, generally they will not protect against large scale attacks and may force the website to be removed<br />
| style="padding: 5px;"| Depending on the provider if the attack crosses their threshold for protection they may shut down the website or ask it to leave<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/Data_EncryptionData Encryption2014-05-26T15:12:19Z<p>Bill: </p>
<hr />
<div>There are a number of options for data encryption for secure server hosting, however, for Shared Hosting or CPanel style hosts encryption options are very limited. For Dedicated/VPS hosting, administrator's have the option of encrypting the entire disk or encrypting portions where sensitive file data will be stored. We will explore both approaches, noting benefits and downsides for both.<br />
<br />
==Whole Disk Encryption==<br />
The major issue with whole disk encryption is that a reboot will require the entry of a password before the system is mounted. To be able to do this your provider would need to give access to the machine via a KVM, which allows remote access to a keyboard console as the machine boots. This is a non-standard setup and some providers may charge additional fees for it.<br />
<br />
Advanced users using whole-disk encryption may set up the DropBear SSH daemon in their boot loader, which allows for the use <br />
<br />
The significant benefit to whole disk encryption that if the machine is seized by outside parties they will have no access to the operating system or disk itself. This means that no data on the machine will be leaked in that eventuality. This also denies attackers the ability to modify most local system binaries to attempt to intercept passwords, provide backdoors or log user actions. <br />
<br />
<ol><br />
<li><br />
The [https://code.google.com/p/cryptsetup/| Linux Unified Key System(LUKS)] also for both full and partial disk encryption.<br />
<br />
An in-depth tutorial for LUKS setup can be found [https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system| here] and a simpler one can be found [http://www.hermann-uwe.de/blog/howto-disk-encryption-with-dm-crypt-luks-and-debian| here]<br />
</li><br />
</ol><br />
==Data Store Encryption==<br />
An alternative to whole disk encryption is to encrypt specific portions of the disk containing the most sensitive data that must be protected. Care should be taken to encrypt both data at rest (ie a database, MySQL etc.) and "scratch" or temporary data storage (search engine technologies such as Solr, Memcached data stores etc.).<br />
<br />
This removes the need for entry of a boot password on reboot but it does leave any elements of the disk not encrypted open to access if the machine is seized or compromised.<br />
<br />
<ol><br />
<li><br />
The tool [http://www.arg0.net/encfs| encfs] runs in the user space and allows the creation of encrypted partitions. These partitions can be mounted once the system has been booted. The tool allows for very strict control over which users can access mounted information once a partition has been decrypted and is suited to applications where a specific user/process accesses the encrypted data. <br />
<br />
The encrypted partitions can be defined at variable sizes and the sensitive datastores and applications can be run from within them once the partition has been mounted.<br />
<br />
A guide for setting up <tt>encfs</tt> can be found [http://www.howtoforge.com/encrypt-your-data-with-encfs-debian-squeeze-ubuntu-11.10| here]. <br />
</li><br />
<li><br />
The Linux kernel offers support for <tt>ecryptfs</tt> partitions. These partitions are mounted like any other local filesystem, but with the benefit of the device being encrypted while unmounted. These partitions are mounted like other filesystems and not in user space so they cannot be mounted by unprivileged users. <br />
</li><br />
<li><br />
The LUKS tool can also be set to encrypted only specific partitions and mounted in a similar way to <tt>encfs</tt>.<br />
</ol></div>Billhttps://learn.equalit.ie/wiki/Choose_a_hosting_providerChoose a hosting provider2014-05-25T18:29:27Z<p>Bill: </p>
<hr />
<div>__NOTOC__<br />
===Criteria===<br />
<br />
There are several aspects which should be considered when selecting a service host. Below is a general list, this [https://pad.riseup.net/p/rh_ispq| document] gives detailed information on each area.<br />
<br />
*Price - relative services offered<br />
*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.<br />
*Specialisation - do they work in the field of human rights, software applications or general hosting<br />
*Is mail provided<br />
*Hardware specifications<br />
*Operating systems offered<br />
*Supported provided<br />
*Readily discusses your security concerns and which security features and processes they offer with their hosting.<br />
*Provides the most recent stable versions of all server software.<br />
*Provides reliable methods for backup and recovery.<br />
*Provides encryption options for hosting of sites or mail<br />
<br />
===Features===<br />
It is quite important to consider the possibilities offered by your provider's control panel. If you need to write a support ticket everytime the server has to reboot, it wont be an efficient process, especially during a crises. Possible features to look out for include<br />
<br />
* Automated operating system installs<br />
* Server boot and reboot<br />
* Remote console (sometimes known as KVM)<br />
* Server and network statistics<br />
* Dynamic components (e.g. adding extra disk space, RAM without rebuilding the machine or having to order a new service)<br />
* Server access (varies between SSH, SFTP or web based)<br />
*<br />
<br />
==Secure hosting setups==<br />
Depending on available skill level the following secure system setups are possible:<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===Dedicated Server===<br />
For a [[Dedicated_Hosting | Dedicated Hosting]] system, the user can either run their own physical hardware or rent this hardware from a provider. The former solution offers total control of the physical hardware, however, there are significant downsides to this approach and should be avoided; it is only recommend under special circumstances such as [[Sensitive_Data | storing sensitive data]]. In the latter case, the hosting agent provides the hardware but the user has total control of the server via remote access. In this scenario, the provider is responsible for replacement of hardware parts that fail or malfunction - this support is generally done through a ticket system and relies on the user to report errors.<br />
<br />
'''Examples'''<br />
* http://www.ovh.com/ca/en/dedicated-servers/hosting/<br />
* http://www.soyoustart.com/ie/offers.xml<br />
* http://www.hetzner.de/en/hosting/produktmatrix/rootserver<br />
* http://www.coolhousing.net/hosting-dedicated-servers.html<br />
<br />
'''Benefits'''<br />
*User has total control of the system's software<br />
*User has total control of access rights<br />
*User has control of physical network connection, allowing them to whitelist or block connection from allowed or spurious connections<br />
*Financial cost of hardware malfunction is not an issue as the host is responsible for replacing/repairing failing hardware<br />
*The host can be chosen to place the server in a different jurisdiction from that of the user to prevent seizure<br />
<br />
'''Downsides'''<br />
*The user does not have physical access to the server<br />
*The host is not responsible for data loss or downtime if the physical server fails<br />
*The user is responsible for detecting and reporting hardware faults on some providers<br />
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].<br />
*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.<br />
<br />
===VPS===<br />
A Virtual Private Server(VPS) is an instance of a Virtual Operating System running on a much larger server. Typically multiple VPS will be run on a single server. In a VPS environment, you have a dedicated virtual private server but do not control the server on which it is hosted. Resources will be limited, you can not control or harden the outer server.<br />
<br />
'''Examples'''<br />
* https://www.linode.com/pricing<br />
* https://chhost.net/virtual-server/<br />
* https://www.tilaa.com/orders/add<br />
<br />
'''Benefits'''<br />
*The cost of this type of server will typically be significantly cheaper than a dedicated server<br />
*Depending on the host, the server will be capable of running most standard server software, up to a certain limit<br />
*Hardware is managed by the hosting provider unless self hosting<br />
*If self hosting, a single server can be used for multiple purposes and to provide multiple distinct servers<br />
<br />
'''Downsides'''<br />
*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<br />
*Bandwidth will also be restricted<br />
*Potential risk of provider, law enforcement or other state forces accessing contents of virtual server without user's awareness. <br />
*The user will not have access to the outer server and will thus not be able to harden it<br />
<br />
===Threats===<br />
*Social engineering attack<br />
*Password brute force<br />
*Service interruption through denial of service attack<br />
*System software exploits<br />
*SSL man-in-the-middle attacks<br />
*Data loss or data theft<br />
<br />
===Mitigation===<br />
'''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.<br />
<ol><br />
<li><br />
Enforce strong password - a strong password should contain Upper and Lower case characters, Numbers and Special Characters and should be long; greater than 20 characters. It is also possible to restrict the use of previously used passwords. On Linux systems the following command can be used to force complex passwords for users:<br />
</li><br />
password required pam_cracklib.so minlen=12 lcredit=1 ucredit=1 dcredit=2 ocredit=1<br />
<br />
For more detail, refer to the guide [http://www.linux-faqs.info/security/force-strong-passwords| Force strong passwords]<br />
<li><br />
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].<br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
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]<br />
</li><br />
</ol><br />
'''User Management''' on dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<ol><br />
<li><br />
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.<br />
</li><br />
<li><br />
Secure Shell(SSH) login should be forced, telnet and ftp login access should be disabled by default. To upload files to the server securely user can use Secure FTP(SFTP) clients. <br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
File permissions should be restricted for critical files. User should only be allowed access to files relevant to their work. Execution as root should be restricted. Discussion of [http://www.linux.com/learn/tutorials/309527-understanding-linux-file-permissions| linux file permissions].<br />
</li><br />
</ol><br />
'''Software Management'''<br />
<ol><br />
<li><br />
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].<br />
</li><br />
<li><br />
Minimising installed software is an important step in reducing potential vulnerabilities. The system should have the bare minimum of packages and software installed to support its purpose.<br />
</li><br />
</ol><br />
'''System Management'''<br />
<ol><br />
<li><br />
Firewall can be enabled via [http://www.netfilter.org/projects/iptables/| iptables] the guides [http://www.tecmint.com/basic-guide-on-iptables-linux-firewall-tips-commands/| here] and [http://www.cyberciti.biz/faq/category/iptables/| here] describe iptables configuration.<br />
</li><br />
<li><br />
To protect the server it is important to audit the open ports on the machine. To check listening ports you can run<br />
<br><br />
netstat -tulpn<br />
<br />
<br />
</li><br />
<li><br />
Logging and Auditing is a key aspect of server security. All hacking, brute force, DDoS or other attacks should be captured, monitored and analysed. <br />
<br><br />
This [http://www.cyberciti.biz/faq/linux-log-files-location-and-how-do-i-view-logs-files/| guide] describes the location and purpose of common Linux log files.<br />
<br />
<br><br />
<br />
To ensure that information is not lost, overwritten or that the logs do not grow infinitely the tool [http://www.thegeekstuff.com/2010/07/logrotate-examples/| Logrotate] can be used.<br />
<br><br />
<br />
Installing a tool like Logwatch allows you to monitor and respond to suspicious activity. The following [https://www.digitalocean.com/community/articles/how-to-install-and-use-logwatch-log-analyzer-and-reporter-on-a-vps| guide] describes installing and configuring Logwatch.<br />
</li><br />
<li><br />
[http://selinuxproject.org/page/Main_Page| Security Enhanced Linux(SELinux)] is a kernel level security control mechanism, which enforces a set of rules and procedures for the system. SELinux provides fine grained control for access rights and permissions.<br />
<br><br />
To check if it is enabled run<br />
<br><br />
<i><br />
sestatus<br />
</i><br />
<br><br />
To enable run<br />
<br><br />
<i><br />
setenforce enforcing<br />
</i><br />
<br><br />
To adjust the SELinux config is available at<br />
<br><br />
<i><br />
/etc/selinux/config <br />
</i><br />
</li><br />
<li><br />
[http://www.fail2ban.org/wiki/index.php/Main_Page| Fail2ban] is an excellent tool that can be used both to combat simple DDoS attacks but also to detect and block brute force login attempts.<br />
</li><br />
</ol><br />
<ul><br />
'''Apache hardening'''<br />
<br />
As well as considering the physical server and it's operating system users must thinking in terms of application security. Especially for those applications which either contain sensitive data or those that provide access routes to the machine for an attacker.<br />
<br />
Below is a set of guides for Apache webserver hardening.<br />
<li><br />
[http://www.tecmint.com/apache-security-tips/| 13 Apache Web Server Security and Hardening Tips]<br />
<li><br />
[http://xianshield.org/guides/apache2.0guide.html| Apache 2.0 Hardening Guide]<br />
</li><br />
</ul><br />
<ul><br />
'''Database hardening'''<br />
<br />
A key approach discussed elsewhere in protecting data, both at rest - on disk - and in use - in memory, is to encrypt these data stores either as part of full disk encryption or as individual restricted encrypted mount points.<br />
<br />
Below are further guides for specific hardening techniques for the MySQL database system.<br />
<li><br />
[http://www.greensql.com/content/mysql-security-best-practices-hardening-mysql-tips| MySQL Security Best Practices]<br />
</li><br />
<li><br />
[http://rochakchauhan.com/blog/2013/11/19/security-and-hardening-tips-for-mysql/| Security and Hardening Tips for MySQL]<br />
</li><br />
<li><br />
[http://www.securethelock.com/2014/01/09/12-steps-for-hardening-mysql-from-attackers/| 12 steps for Hardening MySQL from Attackers]<br />
</li><br />
</ul><br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted platform===<br />
For organisation that wish to setup their own custom site based on an existing platform such as Wordpress.com, there are a setup of steps that should be taken to ensure a good level of security. The [[Choosing_A_Host | choosing a hosting provider]] guide should also be consulted.<br />
<br />
'''Platform Security'''<br />
<ol><br />
<li><br />
Limiting access - Making smart choices that reduce possible entry points available to a malicious person.<br />
</li><br />
<li>Containment - Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.<br />
</li><br />
<li>Preparation and knowledge - Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.<br />
</li><br />
<li><br />
Passwords<br />
</li><br />
<li><br />
File Permissions<br />
</li><br />
<li><br />
Admin user<br />
</li><br />
<li><br />
SSL<br />
</li><br />
<li><br />
SFTP client<br />
</li><br />
<li><br />
Platform updates<br />
</li><br />
</ol><br />
Hosting install of pre-built software platform, such as Wordpress,<br />
<br />
===Shared Hosting===<br />
In a [[Shared_Hosting|Shared Hosting]] environment, your and other website owners shared one server. This includes sharing the physical server and the software applications within the server. Shared hosting services are affordable because the cost to operate the server is shared between you and these other owners. There are, however, a number of down sides, such as being slower.<br />
<br />
'''Examples:'''<br />
* http://www.easyweb.com<br />
* http://www.dreamhost.com/web-hosting/<br />
* http://wpengine.com/ (wordpress only)<br />
<br />
===Threat Mitigation===<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
For a basic setup providing a content distribution platform such as a blog users have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
<br />
<br />
===Threat Mitigation===<br />
<br />
<ol><br />
<li><br />
'''Strong Passwords''' are a core element of any system. The access password for the host should be restricted to those individuals with the organisation that work directly with the server.<br />
<br />
Safe password creation and storage procedures should be followed, as described [|here]<br />
</li><br />
<li><br />
'''Malware''' is core vulnerability for the devices used by those managing and logging into the hosted system. Malware, keyloggers and viruses provided a straightforward means of attack.<br />
<br><br />
The attacker does not need to hack or compromise the server, instead via infection through phishing emails or malicious websites the attacker can log and store the passwords and other critical information.<br />
<br><br />
To mitigate this threat all individuals who work with or have login access to the server must have anti-virus installed, a firewall and have an up to date system. For more information [|see]<br />
</li><br />
<li><br />
'''Two factor Authentication''' should be enabled where available as this will make compromising a system significantly more difficult.<br />
</li><br />
<li><br />
'''Wordpress Security''' is described in detail in the following [http://codex.wordpress.org/Hardening_WordPress| guide]. <br />
</li><br />
</ol><br />
</div><br />
<br />
</div><br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''Dedicated Server'''<br />
| style="padding: 5px;"| '''Virtual Private Server'''<br />
| style="padding: 5px;"| '''Shared Hosting'''<br />
| style="padding: 5px;"| '''Cloud Service'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Requires Intermediary technical skill<br />
| style="padding: 5px;"| Intermediary/Basic<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows disk/data encryption<br />
| style="padding: 5px;"| Allows encryption within VPS<br />
| style="padding: 5px;"| Limited or no control of data encryption<br />
| style="padding: 5px;"| Depends on provider but usually not provided<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| SSH and private key login<br />
| style="padding: 5px;"| Enforce secure login for VPS<br />
| style="padding: 5px;"| Login via CPanel or Custom interface - some hosts offer 2 factor auth<br />
| style="padding: 5px;"| Depends<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| User access control and restriction<br />
| style="padding: 5px;"| User control<br />
| style="padding: 5px;"| Control via user accounts added through management software<br />
| style="padding: 5px;"| Control via management software<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| Allows only shared SSL cert, most host provide shared cert<br />
| style="padding: 5px;"| Most host platforms will provide SSL support by default<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Total control of applications and software<br />
| style="padding: 5px;"| Control of software within VM, limited access to hardware depending on type of VM<br />
| style="padding: 5px;"| Application control only via management interface<br />
| style="padding: 5px;"| Depends on cloud server - certain services with provide data access restrictions but this is a non-ideal scenario<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Manually maintained and updated<br />
| style="padding: 5px;"| Server is patched but VPS remains responsibility of user<br />
| style="padding: 5px;"| Patches and updates provided by host - though may lag behind depending on quality of hosting<br />
| style="padding: 5px;"| Depending on scale of provider - patching and support will be provided to protect their reputation<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Limited supported - hardware support and replacement depending on provider<br />
| style="padding: 5px;"| Similar to dedicated support<br />
| style="padding: 5px;"| Support is generally in terms of management software - hardware is automatically monitored by hosts<br />
| style="padding: 5px;"| Similar to shared though support is specific to the platform hosting<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Anti-ddos and brute forcing via fail2ban, botnetdbp deployment<br />
| style="padding: 5px;"| Provider may or may not mitigate DDoS attacks<br />
| style="padding: 5px;"| DDoS attacks will receive some or limited mitigation depending on quality of host, generally they will not protect against large scale attacks and may force the website to be removed<br />
| style="padding: 5px;"| Depending on the provider if the attack crosses their threshold for protection they may shut down the website or ask it to leave<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/Choose_a_hosting_providerChoose a hosting provider2014-05-25T18:28:32Z<p>Bill: </p>
<hr />
<div>__NOTOC__<br />
===Criteria===<br />
<br />
There are several aspects which should be considered when selecting a service host. Below is a general list, this [https://pad.riseup.net/p/rh_ispq| document] gives detailed information on each area.<br />
<br />
*Price - relative services offered<br />
*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.<br />
*Specialisation - do they work in the field of human rights, software applications or general hosting<br />
*Is mail provided<br />
*Hardware specifications<br />
*Operating systems offered<br />
*Supported provided<br />
*Readily discusses your security concerns and which security features and processes they offer with their hosting.<br />
*Provides the most recent stable versions of all server software.<br />
*Provides reliable methods for backup and recovery.<br />
*Provides encryption options for hosting of sites or mail<br />
<br />
===Features===<br />
It is quite important to consider the possibilities offered by your provider's control panel. If you need to write a support ticket everytime the server has to reboot, it wont be an efficient process, especially during a crises. Possible features to look out for include<br />
<br />
* Automated operating system installs<br />
* Server boot and reboot<br />
* Remote console (sometimes known as KVM)<br />
* Server and network statistics<br />
* Dynamic components (e.g. adding extra disk space, RAM without rebuilding the machine or having to order a new service)<br />
* Server access (varies between SSH, SFTP or web based)<br />
*<br />
<br />
==Secure hosting setups==<br />
Depending on available skill level the following secure system setups are possible:<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===Dedicated Server===<br />
For a [[Dedicated_Hosting | Dedicated Hosting]] system, the user can either run their own physical hardware or rent this hardware from a provider. The former solution offers total control of the physical hardware, however, there are significant downsides to this approach and should be avoided; it is only recommend under special circumstances such as [[Sensitive_Data | storing sensitive data]]. In the latter case, the hosting agent provides the hardware but the user has total control of the server via remote access. In this scenario, the provider is responsible for replacement of hardware parts that fail or malfunction - this support is generally done through a ticket system and relies on the user to report errors.<br />
<br />
'''Examples'''<br />
* http://www.ovh.com/ca/en/dedicated-servers/hosting/<br />
* http://www.soyoustart.com/ie/offers.xml<br />
* http://www.hetzner.de/en/hosting/produktmatrix/rootserver<br />
* http://www.coolhousing.net/hosting-dedicated-servers.html<br />
<br />
'''Benefits'''<br />
*User has total control of the system's software<br />
*User has total control of access rights<br />
*User has control of physical network connection, allowing them to whitelist or block connection from allowed or spurious connections<br />
*Financial cost of hardware malfunction is not an issue as the host is responsible for replacing/repairing failing hardware<br />
*The host can be chosen to place the server in a different jurisdiction from that of the user to prevent seizure<br />
<br />
'''Downsides'''<br />
*The user does not have physical access to the server<br />
*The host is not responsible for data loss or downtime if the physical server fails<br />
*The user is responsible for detecting and reporting hardware faults on some providers<br />
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].<br />
*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.<br />
<br />
===VPS===<br />
A Virtual Private Server(VPS) is an instance of a Virtual Operating System running on a much larger server. Typically multiple VPS will be run on a single server. In a VPS environment, you have a dedicated virtual private server but do not control the server on which it is hosted. Resources will be limited, you can not control or harden the outer server.<br />
<br />
'''Examples'''<br />
* https://www.linode.com/pricing<br />
* https://chhost.net/virtual-server/<br />
* https://www.tilaa.com/orders/add<br />
<br />
'''Benefits'''<br />
*The cost of this type of server will typically be significantly cheaper than a dedicated server<br />
*Depending on the host, the server will be capable of running most standard server software, up to a certain limit<br />
*Hardware is managed by the hosting provider unless self hosting<br />
*If self hosting, a single server can be used for multiple purposes and to provide multiple distinct servers<br />
<br />
'''Downsides'''<br />
*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<br />
*Bandwidth will also be restricted<br />
*Potential risk of provider, law enforcement or other state forces accessing contents of virtual server without user's awareness. <br />
*The user will not have access to the outer server and will thus not be able to harden it<br />
<br />
===Threats===<br />
*Social engineering attack<br />
*Password brute force<br />
*Service interruption through denial of service attack<br />
*System software exploits<br />
*SSL man-in-the-middle attacks<br />
*Data loss or data theft<br />
<br />
===Mitigation===<br />
'''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.<br />
<ol><br />
<li><br />
Enforce strong password - a strong password should contain Upper and Lower case characters, Numbers and Special Characters and should be long; greater than 20 characters. It is also possible to restrict the use of previously used passwords. On Linux systems the following command can be used to force complex passwords for users:<br />
</li><br />
password required pam_cracklib.so minlen=12 lcredit=1 ucredit=1 dcredit=2 ocredit=1<br />
<br />
For more detail, refer to the guide [http://www.linux-faqs.info/security/force-strong-passwords| Force strong passwords]<br />
<li><br />
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].<br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
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]<br />
</li><br />
</ol><br />
'''User Management''' on dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<ol><br />
<li><br />
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.<br />
</li><br />
<li><br />
Secure Shell(SSH) login should be forced, telnet and ftp login access should be disabled by default. To upload files to the server securely user can use Secure FTP(SFTP) clients. <br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
File permissions should be restricted for critical files. User should only be allowed access to files relevant to their work. Execution as root should be restricted. Discussion of [http://www.linux.com/learn/tutorials/309527-understanding-linux-file-permissions| linux file permissions].<br />
</li><br />
</ol><br />
'''Software Management'''<br />
<ol><br />
<li><br />
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].<br />
</li><br />
<li><br />
Minimising installed software is an important step in reducing potential vulnerabilities. The system should have the bare minimum of packages and software installed to support its purpose.<br />
</li><br />
</ol><br />
'''System Management'''<br />
<ol><br />
<li><br />
Firewall can be enabled via [http://www.netfilter.org/projects/iptables/| iptables] the guides [http://www.tecmint.com/basic-guide-on-iptables-linux-firewall-tips-commands/| here] and [http://www.cyberciti.biz/faq/category/iptables/| here] describe iptables configuration.<br />
</li><br />
<li><br />
To protect the server it is important to audit the open ports on the machine. To check listening ports you can run<br />
<br><br />
netstat -tulpn<br />
<br />
<br />
</li><br />
<li><br />
Logging and Auditing is a key aspect of server security. All hacking, brute force, DDoS or other attacks should be captured, monitored and analysed. <br />
<br><br />
This [http://www.cyberciti.biz/faq/linux-log-files-location-and-how-do-i-view-logs-files/| guide] describes the location and purpose of common Linux log files.<br />
<br />
<br><br />
<br />
To ensure that information is not lost, overwritten or that the logs do not grow infinitely the tool [http://www.thegeekstuff.com/2010/07/logrotate-examples/| Logrotate] can be used.<br />
<br><br />
<br />
Installing a tool like Logwatch allows you to monitor and respond to suspicious activity. The following [https://www.digitalocean.com/community/articles/how-to-install-and-use-logwatch-log-analyzer-and-reporter-on-a-vps| guide] describes installing and configuring Logwatch.<br />
</li><br />
<li><br />
[http://selinuxproject.org/page/Main_Page| Security Enhanced Linux(SELinux)] is a kernel level security control mechanism, which enforces a set of rules and procedures for the system. SELinux provides fine grained control for access rights and permissions.<br />
<br><br />
To check if it is enabled run<br />
<br><br />
<i><br />
sestatus<br />
</i><br />
<br><br />
To enable run<br />
<br><br />
<i><br />
setenforce enforcing<br />
</i><br />
<br><br />
To adjust the SELinux config is available at<br />
<br><br />
<i><br />
/etc/selinux/config <br />
</i><br />
</li><br />
<li><br />
[http://www.fail2ban.org/wiki/index.php/Main_Page| Fail2ban] is an excellent tool that can be used both to combat simple DDoS attacks but also to detect and block brute force login attempts.<br />
</li><br />
</ol><br />
<ul><br />
'''Apache hardening'''<br />
<br />
As well as considering the physical server and it's operating system users must thinking in terms of application security. Especially for those applications which either contain sensitive data or those that provide access routes to the machine for an attacker.<br />
<br />
Below is a set of guides for Apache webserver hardening.<br />
<li><br />
[http://www.tecmint.com/apache-security-tips/| 13 Apache Web Server Security and Hardening Tips]<br />
<li><br />
[http://xianshield.org/guides/apache2.0guide.html| Apache 2.0 Hardening Guide]<br />
</li><br />
</ul><br />
<ul><br />
'''Database hardening'''<br />
<br />
A key approach discussed elsewhere in protecting data, both at rest - on disk - and in use - in memory, is to encrypt these data stores either as part of full disk encryption or as individual restricted encrypted mount points.<br />
<br />
Below are further guides for specific hardening techniques for the MySQL database system.<br />
<li><br />
[http://www.greensql.com/content/mysql-security-best-practices-hardening-mysql-tips| MySQL Security Best Practices]<br />
</li><br />
<li><br />
[http://rochakchauhan.com/blog/2013/11/19/security-and-hardening-tips-for-mysql/| Security and Hardening Tips for MySQL]<br />
</li><br />
<li><br />
[http://www.securethelock.com/2014/01/09/12-steps-for-hardening-mysql-from-attackers/| 12 steps for Hardening MySQL from Attackers]<br />
</li><br />
</ul><br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted platform===<br />
For organisation that wish to setup their own custom site based on an existing platform such as Wordpress.com, there are a setup of steps that should be taken to ensure a good level of security. The [[Choosing_A_Host | choosing a hosting provider]] guide should also be consulted.<br />
<br />
'''Platform Security'''<br />
<ol><br />
<li><br />
Limiting access - Making smart choices that reduce possible entry points available to a malicious person.<br />
</li><br />
<li>Containment - Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.<br />
</li><br />
<li>Preparation and knowledge - Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.<br />
</li><br />
<li><br />
Passwords<br />
</li><br />
<li><br />
File Permissions<br />
</li><br />
<li><br />
Admin user<br />
</li><br />
<li><br />
SSL<br />
</li><br />
<li><br />
SFTP client<br />
</li><br />
<li><br />
Platform updates<br />
</li><br />
</ol><br />
Hosting install of pre-built software platform, such as Wordpress,<br />
<br />
===Shared Hosting===<br />
In a [[Shared_Hosting|Shared Hosting]] environment, your and other website owners shared one server. This includes sharing the physical server and the software applications within the server. Shared hosting services are affordable because the cost to operate the server is shared between you and these other owners. There are, however, a number of down sides, such as being slower.<br />
<br />
'''Examples:'''<br />
* http://www.easyweb.com<br />
* http://www.dreamhost.com/web-hosting/<br />
* http://wpengine.com/ (wordpress only)<br />
<br />
===Threat Mitigation===<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
For a basic setup providing a content distribution platform such as a blog users have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
<br />
<br />
===Threat Mitigation===<br />
<br />
<ol><br />
<li><br />
'''Strong Passwords''' are a core element of any system. The access password for the host should be restricted to those individuals with the organisation that work directly with the server.<br />
<br />
Safe password creation and storage procedures should be followed, as described [|here]<br />
</li><br />
<li><br />
'''Malware''' is core vulnerability for the devices used by those managing and logging into the hosted system. Malware, keyloggers and viruses provided a straightforward means of attack.<br />
<br><br />
The attacker does not need to hack or compromise the server, instead via infection through phishing emails or malicious websites the attacker can log and store the passwords and other critical information.<br />
<br><br />
To mitigate this threat all individuals who work with or have login access to the server must have anti-virus installed, a firewall and have an up to date system. For more information [|see]<br />
</li><br />
<li><br />
'''Two factor Authentication''' should be enabled where available as this will make compromising a system significantly more difficult.<br />
</li><br />
<li><br />
'''Wordpress Security''' is described in detail in the following [http://codex.wordpress.org/Hardening_WordPress| guide]. <br />
</li><br />
</div><br />
<br />
</div><br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''Dedicated Server'''<br />
| style="padding: 5px;"| '''Virtual Private Server'''<br />
| style="padding: 5px;"| '''Shared Hosting'''<br />
| style="padding: 5px;"| '''Cloud Service'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Requires Intermediary technical skill<br />
| style="padding: 5px;"| Intermediary/Basic<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows disk/data encryption<br />
| style="padding: 5px;"| Allows encryption within VPS<br />
| style="padding: 5px;"| Limited or no control of data encryption<br />
| style="padding: 5px;"| Depends on provider but usually not provided<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| SSH and private key login<br />
| style="padding: 5px;"| Enforce secure login for VPS<br />
| style="padding: 5px;"| Login via CPanel or Custom interface - some hosts offer 2 factor auth<br />
| style="padding: 5px;"| Depends<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| User access control and restriction<br />
| style="padding: 5px;"| User control<br />
| style="padding: 5px;"| Control via user accounts added through management software<br />
| style="padding: 5px;"| Control via management software<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| Allows only shared SSL cert, most host provide shared cert<br />
| style="padding: 5px;"| Most host platforms will provide SSL support by default<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Total control of applications and software<br />
| style="padding: 5px;"| Control of software within VM, limited access to hardware depending on type of VM<br />
| style="padding: 5px;"| Application control only via management interface<br />
| style="padding: 5px;"| Depends on cloud server - certain services with provide data access restrictions but this is a non-ideal scenario<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Manually maintained and updated<br />
| style="padding: 5px;"| Server is patched but VPS remains responsibility of user<br />
| style="padding: 5px;"| Patches and updates provided by host - though may lag behind depending on quality of hosting<br />
| style="padding: 5px;"| Depending on scale of provider - patching and support will be provided to protect their reputation<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Limited supported - hardware support and replacement depending on provider<br />
| style="padding: 5px;"| Similar to dedicated support<br />
| style="padding: 5px;"| Support is generally in terms of management software - hardware is automatically monitored by hosts<br />
| style="padding: 5px;"| Similar to shared though support is specific to the platform hosting<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Anti-ddos and brute forcing via fail2ban, botnetdbp deployment<br />
| style="padding: 5px;"| Provider may or may not mitigate DDoS attacks<br />
| style="padding: 5px;"| DDoS attacks will receive some or limited mitigation depending on quality of host, generally they will not protect against large scale attacks and may force the website to be removed<br />
| style="padding: 5px;"| Depending on the provider if the attack crosses their threshold for protection they may shut down the website or ask it to leave<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/Choose_a_hosting_providerChoose a hosting provider2014-05-25T18:28:05Z<p>Bill: /* Basic Technical */</p>
<hr />
<div>__NOTOC__<br />
===Criteria===<br />
<br />
There are several aspects which should be considered when selecting a service host. Below is a general list, this [https://pad.riseup.net/p/rh_ispq| document] gives detailed information on each area.<br />
<br />
*Price - relative services offered<br />
*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.<br />
*Specialisation - do they work in the field of human rights, software applications or general hosting<br />
*Is mail provided<br />
*Hardware specifications<br />
*Operating systems offered<br />
*Supported provided<br />
*Readily discusses your security concerns and which security features and processes they offer with their hosting.<br />
*Provides the most recent stable versions of all server software.<br />
*Provides reliable methods for backup and recovery.<br />
*Provides encryption options for hosting of sites or mail<br />
<br />
===Features===<br />
It is quite important to consider the possibilities offered by your provider's control panel. If you need to write a support ticket everytime the server has to reboot, it wont be an efficient process, especially during a crises. Possible features to look out for include<br />
<br />
* Automated operating system installs<br />
* Server boot and reboot<br />
* Remote console (sometimes known as KVM)<br />
* Server and network statistics<br />
* Dynamic components (e.g. adding extra disk space, RAM without rebuilding the machine or having to order a new service)<br />
* Server access (varies between SSH, SFTP or web based)<br />
*<br />
<br />
==Secure hosting setups==<br />
Depending on available skill level the following secure system setups are possible:<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===Dedicated Server===<br />
For a [[Dedicated_Hosting | Dedicated Hosting]] system, the user can either run their own physical hardware or rent this hardware from a provider. The former solution offers total control of the physical hardware, however, there are significant downsides to this approach and should be avoided; it is only recommend under special circumstances such as [[Sensitive_Data | storing sensitive data]]. In the latter case, the hosting agent provides the hardware but the user has total control of the server via remote access. In this scenario, the provider is responsible for replacement of hardware parts that fail or malfunction - this support is generally done through a ticket system and relies on the user to report errors.<br />
<br />
'''Examples'''<br />
* http://www.ovh.com/ca/en/dedicated-servers/hosting/<br />
* http://www.soyoustart.com/ie/offers.xml<br />
* http://www.hetzner.de/en/hosting/produktmatrix/rootserver<br />
* http://www.coolhousing.net/hosting-dedicated-servers.html<br />
<br />
'''Benefits'''<br />
*User has total control of the system's software<br />
*User has total control of access rights<br />
*User has control of physical network connection, allowing them to whitelist or block connection from allowed or spurious connections<br />
*Financial cost of hardware malfunction is not an issue as the host is responsible for replacing/repairing failing hardware<br />
*The host can be chosen to place the server in a different jurisdiction from that of the user to prevent seizure<br />
<br />
'''Downsides'''<br />
*The user does not have physical access to the server<br />
*The host is not responsible for data loss or downtime if the physical server fails<br />
*The user is responsible for detecting and reporting hardware faults on some providers<br />
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].<br />
*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.<br />
<br />
===VPS===<br />
A Virtual Private Server(VPS) is an instance of a Virtual Operating System running on a much larger server. Typically multiple VPS will be run on a single server. In a VPS environment, you have a dedicated virtual private server but do not control the server on which it is hosted. Resources will be limited, you can not control or harden the outer server.<br />
<br />
'''Examples'''<br />
* https://www.linode.com/pricing<br />
* https://chhost.net/virtual-server/<br />
* https://www.tilaa.com/orders/add<br />
<br />
'''Benefits'''<br />
*The cost of this type of server will typically be significantly cheaper than a dedicated server<br />
*Depending on the host, the server will be capable of running most standard server software, up to a certain limit<br />
*Hardware is managed by the hosting provider unless self hosting<br />
*If self hosting, a single server can be used for multiple purposes and to provide multiple distinct servers<br />
<br />
'''Downsides'''<br />
*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<br />
*Bandwidth will also be restricted<br />
*Potential risk of provider, law enforcement or other state forces accessing contents of virtual server without user's awareness. <br />
*The user will not have access to the outer server and will thus not be able to harden it<br />
<br />
===Threats===<br />
*Social engineering attack<br />
*Password brute force<br />
*Service interruption through denial of service attack<br />
*System software exploits<br />
*SSL man-in-the-middle attacks<br />
*Data loss or data theft<br />
<br />
===Mitigation===<br />
'''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.<br />
<ol><br />
<li><br />
Enforce strong password - a strong password should contain Upper and Lower case characters, Numbers and Special Characters and should be long; greater than 20 characters. It is also possible to restrict the use of previously used passwords. On Linux systems the following command can be used to force complex passwords for users:<br />
</li><br />
password required pam_cracklib.so minlen=12 lcredit=1 ucredit=1 dcredit=2 ocredit=1<br />
<br />
For more detail, refer to the guide [http://www.linux-faqs.info/security/force-strong-passwords| Force strong passwords]<br />
<li><br />
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].<br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
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]<br />
</li><br />
</ol><br />
'''User Management''' on dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<ol><br />
<li><br />
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.<br />
</li><br />
<li><br />
Secure Shell(SSH) login should be forced, telnet and ftp login access should be disabled by default. To upload files to the server securely user can use Secure FTP(SFTP) clients. <br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
File permissions should be restricted for critical files. User should only be allowed access to files relevant to their work. Execution as root should be restricted. Discussion of [http://www.linux.com/learn/tutorials/309527-understanding-linux-file-permissions| linux file permissions].<br />
</li><br />
</ol><br />
'''Software Management'''<br />
<ol><br />
<li><br />
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].<br />
</li><br />
<li><br />
Minimising installed software is an important step in reducing potential vulnerabilities. The system should have the bare minimum of packages and software installed to support its purpose.<br />
</li><br />
</ol><br />
'''System Management'''<br />
<ol><br />
<li><br />
Firewall can be enabled via [http://www.netfilter.org/projects/iptables/| iptables] the guides [http://www.tecmint.com/basic-guide-on-iptables-linux-firewall-tips-commands/| here] and [http://www.cyberciti.biz/faq/category/iptables/| here] describe iptables configuration.<br />
</li><br />
<li><br />
To protect the server it is important to audit the open ports on the machine. To check listening ports you can run<br />
<br><br />
netstat -tulpn<br />
<br />
<br />
</li><br />
<li><br />
Logging and Auditing is a key aspect of server security. All hacking, brute force, DDoS or other attacks should be captured, monitored and analysed. <br />
<br><br />
This [http://www.cyberciti.biz/faq/linux-log-files-location-and-how-do-i-view-logs-files/| guide] describes the location and purpose of common Linux log files.<br />
<br />
<br><br />
<br />
To ensure that information is not lost, overwritten or that the logs do not grow infinitely the tool [http://www.thegeekstuff.com/2010/07/logrotate-examples/| Logrotate] can be used.<br />
<br><br />
<br />
Installing a tool like Logwatch allows you to monitor and respond to suspicious activity. The following [https://www.digitalocean.com/community/articles/how-to-install-and-use-logwatch-log-analyzer-and-reporter-on-a-vps| guide] describes installing and configuring Logwatch.<br />
</li><br />
<li><br />
[http://selinuxproject.org/page/Main_Page| Security Enhanced Linux(SELinux)] is a kernel level security control mechanism, which enforces a set of rules and procedures for the system. SELinux provides fine grained control for access rights and permissions.<br />
<br><br />
To check if it is enabled run<br />
<br><br />
<i><br />
sestatus<br />
</i><br />
<br><br />
To enable run<br />
<br><br />
<i><br />
setenforce enforcing<br />
</i><br />
<br><br />
To adjust the SELinux config is available at<br />
<br><br />
<i><br />
/etc/selinux/config <br />
</i><br />
</li><br />
<li><br />
[http://www.fail2ban.org/wiki/index.php/Main_Page| Fail2ban] is an excellent tool that can be used both to combat simple DDoS attacks but also to detect and block brute force login attempts.<br />
</li><br />
</ol><br />
<ul><br />
'''Apache hardening'''<br />
<br />
As well as considering the physical server and it's operating system users must thinking in terms of application security. Especially for those applications which either contain sensitive data or those that provide access routes to the machine for an attacker.<br />
<br />
Below is a set of guides for Apache webserver hardening.<br />
<li><br />
[http://www.tecmint.com/apache-security-tips/| 13 Apache Web Server Security and Hardening Tips]<br />
<li><br />
[http://xianshield.org/guides/apache2.0guide.html| Apache 2.0 Hardening Guide]<br />
</li><br />
</ul><br />
<ul><br />
'''Database hardening'''<br />
<br />
A key approach discussed elsewhere in protecting data, both at rest - on disk - and in use - in memory, is to encrypt these data stores either as part of full disk encryption or as individual restricted encrypted mount points.<br />
<br />
Below are further guides for specific hardening techniques for the MySQL database system.<br />
<li><br />
[http://www.greensql.com/content/mysql-security-best-practices-hardening-mysql-tips| MySQL Security Best Practices]<br />
</li><br />
<li><br />
[http://rochakchauhan.com/blog/2013/11/19/security-and-hardening-tips-for-mysql/| Security and Hardening Tips for MySQL]<br />
</li><br />
<li><br />
[http://www.securethelock.com/2014/01/09/12-steps-for-hardening-mysql-from-attackers/| 12 steps for Hardening MySQL from Attackers]<br />
</li><br />
</ul><br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted platform===<br />
For organisation that wish to setup their own custom site based on an existing platform such as Wordpress.com, there are a setup of steps that should be taken to ensure a good level of security. The [[Choosing_A_Host | choosing a hosting provider]] guide should also be consulted.<br />
<br />
'''Platform Security'''<br />
<ol><br />
<li><br />
Limiting access - Making smart choices that reduce possible entry points available to a malicious person.<br />
</li><br />
<li>Containment - Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.<br />
</li><br />
<li>Preparation and knowledge - Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.<br />
</li><br />
<li><br />
Passwords<br />
</li><br />
<li><br />
File Permissions<br />
</li><br />
<li><br />
Admin user<br />
</li><br />
<li><br />
SSL<br />
</li><br />
<li><br />
SFTP client<br />
</li><br />
<li><br />
Platform updates<br />
</li><br />
</ol><br />
Hosting install of pre-built software platform, such as Wordpress,<br />
<br />
===Shared Hosting===<br />
In a [[Shared_Hosting|Shared Hosting]] environment, your and other website owners shared one server. This includes sharing the physical server and the software applications within the server. Shared hosting services are affordable because the cost to operate the server is shared between you and these other owners. There are, however, a number of down sides, such as being slower.<br />
<br />
'''Examples:'''<br />
* http://www.easyweb.com<br />
* http://www.dreamhost.com/web-hosting/<br />
* http://wpengine.com/ (wordpress only)<br />
<br />
===Threat Mitigation===<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
For a basic setup providing a content distribution platform such as a blog users have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
<br />
<br />
===Threat Mitigation===<br />
<br />
<ol><br />
<li><br />
'''Strong Passwords''' are a core element of any system. The access password for the host should be restricted to those individuals with the organisation that work directly with the server.<br />
<br />
Safe password creation and storage procedures should be followed, as described [|here]<br />
</li><br />
<li><br />
'''Malware''' is core vulnerability for the devices used by those managing and logging into the hosted system. Malware, keyloggers and viruses provided a straightforward means of attack.<br />
<br><br />
The attacker does not need to hack or compromise the server, instead via infection through phishing emails or malicious websites the attacker can log and store the passwords and other critical information.<br />
<br><br />
To mitigate this threat all individuals who work with or have login access to the server must have anti-virus installed, a firewall and have an up to date system. For more information [|see]<br />
</li><br />
<li><br />
'''Two factor Authentication''' should be enabled where available as this will make compromising a system significantly more difficult.<br />
</li><br />
<li><br />
'''Wordpress Security''' is described in detail in the following [http://codex.wordpress.org/Hardening_WordPress| guide]. <br />
</li><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''Dedicated Server'''<br />
| style="padding: 5px;"| '''Virtual Private Server'''<br />
| style="padding: 5px;"| '''Shared Hosting'''<br />
| style="padding: 5px;"| '''Cloud Service'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Requires Intermediary technical skill<br />
| style="padding: 5px;"| Intermediary/Basic<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows disk/data encryption<br />
| style="padding: 5px;"| Allows encryption within VPS<br />
| style="padding: 5px;"| Limited or no control of data encryption<br />
| style="padding: 5px;"| Depends on provider but usually not provided<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| SSH and private key login<br />
| style="padding: 5px;"| Enforce secure login for VPS<br />
| style="padding: 5px;"| Login via CPanel or Custom interface - some hosts offer 2 factor auth<br />
| style="padding: 5px;"| Depends<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| User access control and restriction<br />
| style="padding: 5px;"| User control<br />
| style="padding: 5px;"| Control via user accounts added through management software<br />
| style="padding: 5px;"| Control via management software<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| Allows only shared SSL cert, most host provide shared cert<br />
| style="padding: 5px;"| Most host platforms will provide SSL support by default<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Total control of applications and software<br />
| style="padding: 5px;"| Control of software within VM, limited access to hardware depending on type of VM<br />
| style="padding: 5px;"| Application control only via management interface<br />
| style="padding: 5px;"| Depends on cloud server - certain services with provide data access restrictions but this is a non-ideal scenario<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Manually maintained and updated<br />
| style="padding: 5px;"| Server is patched but VPS remains responsibility of user<br />
| style="padding: 5px;"| Patches and updates provided by host - though may lag behind depending on quality of hosting<br />
| style="padding: 5px;"| Depending on scale of provider - patching and support will be provided to protect their reputation<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Limited supported - hardware support and replacement depending on provider<br />
| style="padding: 5px;"| Similar to dedicated support<br />
| style="padding: 5px;"| Support is generally in terms of management software - hardware is automatically monitored by hosts<br />
| style="padding: 5px;"| Similar to shared though support is specific to the platform hosting<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Anti-ddos and brute forcing via fail2ban, botnetdbp deployment<br />
| style="padding: 5px;"| Provider may or may not mitigate DDoS attacks<br />
| style="padding: 5px;"| DDoS attacks will receive some or limited mitigation depending on quality of host, generally they will not protect against large scale attacks and may force the website to be removed<br />
| style="padding: 5px;"| Depending on the provider if the attack crosses their threshold for protection they may shut down the website or ask it to leave<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/Choose_a_hosting_providerChoose a hosting provider2014-05-25T18:27:46Z<p>Bill: /* Basic Technical */</p>
<hr />
<div>__NOTOC__<br />
===Criteria===<br />
<br />
There are several aspects which should be considered when selecting a service host. Below is a general list, this [https://pad.riseup.net/p/rh_ispq| document] gives detailed information on each area.<br />
<br />
*Price - relative services offered<br />
*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.<br />
*Specialisation - do they work in the field of human rights, software applications or general hosting<br />
*Is mail provided<br />
*Hardware specifications<br />
*Operating systems offered<br />
*Supported provided<br />
*Readily discusses your security concerns and which security features and processes they offer with their hosting.<br />
*Provides the most recent stable versions of all server software.<br />
*Provides reliable methods for backup and recovery.<br />
*Provides encryption options for hosting of sites or mail<br />
<br />
===Features===<br />
It is quite important to consider the possibilities offered by your provider's control panel. If you need to write a support ticket everytime the server has to reboot, it wont be an efficient process, especially during a crises. Possible features to look out for include<br />
<br />
* Automated operating system installs<br />
* Server boot and reboot<br />
* Remote console (sometimes known as KVM)<br />
* Server and network statistics<br />
* Dynamic components (e.g. adding extra disk space, RAM without rebuilding the machine or having to order a new service)<br />
* Server access (varies between SSH, SFTP or web based)<br />
*<br />
<br />
==Secure hosting setups==<br />
Depending on available skill level the following secure system setups are possible:<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===Dedicated Server===<br />
For a [[Dedicated_Hosting | Dedicated Hosting]] system, the user can either run their own physical hardware or rent this hardware from a provider. The former solution offers total control of the physical hardware, however, there are significant downsides to this approach and should be avoided; it is only recommend under special circumstances such as [[Sensitive_Data | storing sensitive data]]. In the latter case, the hosting agent provides the hardware but the user has total control of the server via remote access. In this scenario, the provider is responsible for replacement of hardware parts that fail or malfunction - this support is generally done through a ticket system and relies on the user to report errors.<br />
<br />
'''Examples'''<br />
* http://www.ovh.com/ca/en/dedicated-servers/hosting/<br />
* http://www.soyoustart.com/ie/offers.xml<br />
* http://www.hetzner.de/en/hosting/produktmatrix/rootserver<br />
* http://www.coolhousing.net/hosting-dedicated-servers.html<br />
<br />
'''Benefits'''<br />
*User has total control of the system's software<br />
*User has total control of access rights<br />
*User has control of physical network connection, allowing them to whitelist or block connection from allowed or spurious connections<br />
*Financial cost of hardware malfunction is not an issue as the host is responsible for replacing/repairing failing hardware<br />
*The host can be chosen to place the server in a different jurisdiction from that of the user to prevent seizure<br />
<br />
'''Downsides'''<br />
*The user does not have physical access to the server<br />
*The host is not responsible for data loss or downtime if the physical server fails<br />
*The user is responsible for detecting and reporting hardware faults on some providers<br />
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].<br />
*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.<br />
<br />
===VPS===<br />
A Virtual Private Server(VPS) is an instance of a Virtual Operating System running on a much larger server. Typically multiple VPS will be run on a single server. In a VPS environment, you have a dedicated virtual private server but do not control the server on which it is hosted. Resources will be limited, you can not control or harden the outer server.<br />
<br />
'''Examples'''<br />
* https://www.linode.com/pricing<br />
* https://chhost.net/virtual-server/<br />
* https://www.tilaa.com/orders/add<br />
<br />
'''Benefits'''<br />
*The cost of this type of server will typically be significantly cheaper than a dedicated server<br />
*Depending on the host, the server will be capable of running most standard server software, up to a certain limit<br />
*Hardware is managed by the hosting provider unless self hosting<br />
*If self hosting, a single server can be used for multiple purposes and to provide multiple distinct servers<br />
<br />
'''Downsides'''<br />
*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<br />
*Bandwidth will also be restricted<br />
*Potential risk of provider, law enforcement or other state forces accessing contents of virtual server without user's awareness. <br />
*The user will not have access to the outer server and will thus not be able to harden it<br />
<br />
===Threats===<br />
*Social engineering attack<br />
*Password brute force<br />
*Service interruption through denial of service attack<br />
*System software exploits<br />
*SSL man-in-the-middle attacks<br />
*Data loss or data theft<br />
<br />
===Mitigation===<br />
'''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.<br />
<ol><br />
<li><br />
Enforce strong password - a strong password should contain Upper and Lower case characters, Numbers and Special Characters and should be long; greater than 20 characters. It is also possible to restrict the use of previously used passwords. On Linux systems the following command can be used to force complex passwords for users:<br />
</li><br />
password required pam_cracklib.so minlen=12 lcredit=1 ucredit=1 dcredit=2 ocredit=1<br />
<br />
For more detail, refer to the guide [http://www.linux-faqs.info/security/force-strong-passwords| Force strong passwords]<br />
<li><br />
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].<br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
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]<br />
</li><br />
</ol><br />
'''User Management''' on dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<ol><br />
<li><br />
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.<br />
</li><br />
<li><br />
Secure Shell(SSH) login should be forced, telnet and ftp login access should be disabled by default. To upload files to the server securely user can use Secure FTP(SFTP) clients. <br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
File permissions should be restricted for critical files. User should only be allowed access to files relevant to their work. Execution as root should be restricted. Discussion of [http://www.linux.com/learn/tutorials/309527-understanding-linux-file-permissions| linux file permissions].<br />
</li><br />
</ol><br />
'''Software Management'''<br />
<ol><br />
<li><br />
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].<br />
</li><br />
<li><br />
Minimising installed software is an important step in reducing potential vulnerabilities. The system should have the bare minimum of packages and software installed to support its purpose.<br />
</li><br />
</ol><br />
'''System Management'''<br />
<ol><br />
<li><br />
Firewall can be enabled via [http://www.netfilter.org/projects/iptables/| iptables] the guides [http://www.tecmint.com/basic-guide-on-iptables-linux-firewall-tips-commands/| here] and [http://www.cyberciti.biz/faq/category/iptables/| here] describe iptables configuration.<br />
</li><br />
<li><br />
To protect the server it is important to audit the open ports on the machine. To check listening ports you can run<br />
<br><br />
netstat -tulpn<br />
<br />
<br />
</li><br />
<li><br />
Logging and Auditing is a key aspect of server security. All hacking, brute force, DDoS or other attacks should be captured, monitored and analysed. <br />
<br><br />
This [http://www.cyberciti.biz/faq/linux-log-files-location-and-how-do-i-view-logs-files/| guide] describes the location and purpose of common Linux log files.<br />
<br />
<br><br />
<br />
To ensure that information is not lost, overwritten or that the logs do not grow infinitely the tool [http://www.thegeekstuff.com/2010/07/logrotate-examples/| Logrotate] can be used.<br />
<br><br />
<br />
Installing a tool like Logwatch allows you to monitor and respond to suspicious activity. The following [https://www.digitalocean.com/community/articles/how-to-install-and-use-logwatch-log-analyzer-and-reporter-on-a-vps| guide] describes installing and configuring Logwatch.<br />
</li><br />
<li><br />
[http://selinuxproject.org/page/Main_Page| Security Enhanced Linux(SELinux)] is a kernel level security control mechanism, which enforces a set of rules and procedures for the system. SELinux provides fine grained control for access rights and permissions.<br />
<br><br />
To check if it is enabled run<br />
<br><br />
<i><br />
sestatus<br />
</i><br />
<br><br />
To enable run<br />
<br><br />
<i><br />
setenforce enforcing<br />
</i><br />
<br><br />
To adjust the SELinux config is available at<br />
<br><br />
<i><br />
/etc/selinux/config <br />
</i><br />
</li><br />
<li><br />
[http://www.fail2ban.org/wiki/index.php/Main_Page| Fail2ban] is an excellent tool that can be used both to combat simple DDoS attacks but also to detect and block brute force login attempts.<br />
</li><br />
</ol><br />
<ul><br />
'''Apache hardening'''<br />
<br />
As well as considering the physical server and it's operating system users must thinking in terms of application security. Especially for those applications which either contain sensitive data or those that provide access routes to the machine for an attacker.<br />
<br />
Below is a set of guides for Apache webserver hardening.<br />
<li><br />
[http://www.tecmint.com/apache-security-tips/| 13 Apache Web Server Security and Hardening Tips]<br />
<li><br />
[http://xianshield.org/guides/apache2.0guide.html| Apache 2.0 Hardening Guide]<br />
</li><br />
</ul><br />
<ul><br />
'''Database hardening'''<br />
<br />
A key approach discussed elsewhere in protecting data, both at rest - on disk - and in use - in memory, is to encrypt these data stores either as part of full disk encryption or as individual restricted encrypted mount points.<br />
<br />
Below are further guides for specific hardening techniques for the MySQL database system.<br />
<li><br />
[http://www.greensql.com/content/mysql-security-best-practices-hardening-mysql-tips| MySQL Security Best Practices]<br />
</li><br />
<li><br />
[http://rochakchauhan.com/blog/2013/11/19/security-and-hardening-tips-for-mysql/| Security and Hardening Tips for MySQL]<br />
</li><br />
<li><br />
[http://www.securethelock.com/2014/01/09/12-steps-for-hardening-mysql-from-attackers/| 12 steps for Hardening MySQL from Attackers]<br />
</li><br />
</ul><br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted platform===<br />
For organisation that wish to setup their own custom site based on an existing platform such as Wordpress.com, there are a setup of steps that should be taken to ensure a good level of security. The [[Choosing_A_Host | choosing a hosting provider]] guide should also be consulted.<br />
<br />
'''Platform Security'''<br />
<ol><br />
<li><br />
Limiting access - Making smart choices that reduce possible entry points available to a malicious person.<br />
</li><br />
<li>Containment - Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.<br />
</li><br />
<li>Preparation and knowledge - Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.<br />
</li><br />
<li><br />
Passwords<br />
</li><br />
<li><br />
File Permissions<br />
</li><br />
<li><br />
Admin user<br />
</li><br />
<li><br />
SSL<br />
</li><br />
<li><br />
SFTP client<br />
</li><br />
<li><br />
Platform updates<br />
</li><br />
</ol><br />
Hosting install of pre-built software platform, such as Wordpress,<br />
<br />
===Shared Hosting===<br />
In a [[Shared_Hosting|Shared Hosting]] environment, your and other website owners shared one server. This includes sharing the physical server and the software applications within the server. Shared hosting services are affordable because the cost to operate the server is shared between you and these other owners. There are, however, a number of down sides, such as being slower.<br />
<br />
'''Examples:'''<br />
* http://www.easyweb.com<br />
* http://www.dreamhost.com/web-hosting/<br />
* http://wpengine.com/ (wordpress only)<br />
<br />
===Threat Mitigation===<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
For a basic setup providing a content distribution platform such as a blog users have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
<br />
<br />
===Threat Mitigation===<br />
<br />
<ol><br />
<li><br />
'''Strong Passwords''' are a core element of any system. The access password for the host should be restricted to those individuals with the organisation that work directly with the server.<br />
<br />
Safe password creation and storage procedures should be followed, as described [|here]<br />
</li><br />
<li><br />
'''Malware''' is core vulnerability for the devices used by those managing and logging into the hosted system. Malware, keyloggers and viruses provided a straightforward means of attack.<br />
<br><br />
The attacker does not need to hack or compromise the server, instead via infection through phishing emails or malicious websites the attacker can log and store the passwords and other critical information.<br />
<br><br />
To mitigate this threat all individuals who work with or have login access to the server must have anti-virus installed, a firewall and have an up to date system. For more information [|see]<br />
</li><br />
<li><br />
'''Two factor Authentication''' should be enabled where available as this will make compromising a system significantly more difficult.<br />
</li><br />
<li><br />
'''Wordpress Security''' is described in detail in the following [http://codex.wordpress.org/Hardening_WordPress| guide]. <br />
</li><br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''Dedicated Server'''<br />
| style="padding: 5px;"| '''Virtual Private Server'''<br />
| style="padding: 5px;"| '''Shared Hosting'''<br />
| style="padding: 5px;"| '''Cloud Service'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Requires Intermediary technical skill<br />
| style="padding: 5px;"| Intermediary/Basic<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows disk/data encryption<br />
| style="padding: 5px;"| Allows encryption within VPS<br />
| style="padding: 5px;"| Limited or no control of data encryption<br />
| style="padding: 5px;"| Depends on provider but usually not provided<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| SSH and private key login<br />
| style="padding: 5px;"| Enforce secure login for VPS<br />
| style="padding: 5px;"| Login via CPanel or Custom interface - some hosts offer 2 factor auth<br />
| style="padding: 5px;"| Depends<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| User access control and restriction<br />
| style="padding: 5px;"| User control<br />
| style="padding: 5px;"| Control via user accounts added through management software<br />
| style="padding: 5px;"| Control via management software<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| Allows only shared SSL cert, most host provide shared cert<br />
| style="padding: 5px;"| Most host platforms will provide SSL support by default<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Total control of applications and software<br />
| style="padding: 5px;"| Control of software within VM, limited access to hardware depending on type of VM<br />
| style="padding: 5px;"| Application control only via management interface<br />
| style="padding: 5px;"| Depends on cloud server - certain services with provide data access restrictions but this is a non-ideal scenario<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Manually maintained and updated<br />
| style="padding: 5px;"| Server is patched but VPS remains responsibility of user<br />
| style="padding: 5px;"| Patches and updates provided by host - though may lag behind depending on quality of hosting<br />
| style="padding: 5px;"| Depending on scale of provider - patching and support will be provided to protect their reputation<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Limited supported - hardware support and replacement depending on provider<br />
| style="padding: 5px;"| Similar to dedicated support<br />
| style="padding: 5px;"| Support is generally in terms of management software - hardware is automatically monitored by hosts<br />
| style="padding: 5px;"| Similar to shared though support is specific to the platform hosting<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Anti-ddos and brute forcing via fail2ban, botnetdbp deployment<br />
| style="padding: 5px;"| Provider may or may not mitigate DDoS attacks<br />
| style="padding: 5px;"| DDoS attacks will receive some or limited mitigation depending on quality of host, generally they will not protect against large scale attacks and may force the website to be removed<br />
| style="padding: 5px;"| Depending on the provider if the attack crosses their threshold for protection they may shut down the website or ask it to leave<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/Choose_a_hosting_providerChoose a hosting provider2014-05-25T18:18:25Z<p>Bill: /* Mitigation */</p>
<hr />
<div>__NOTOC__<br />
===Criteria===<br />
<br />
There are several aspects which should be considered when selecting a service host. Below is a general list, this [https://pad.riseup.net/p/rh_ispq| document] gives detailed information on each area.<br />
<br />
*Price - relative services offered<br />
*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.<br />
*Specialisation - do they work in the field of human rights, software applications or general hosting<br />
*Is mail provided<br />
*Hardware specifications<br />
*Operating systems offered<br />
*Supported provided<br />
*Readily discusses your security concerns and which security features and processes they offer with their hosting.<br />
*Provides the most recent stable versions of all server software.<br />
*Provides reliable methods for backup and recovery.<br />
*Provides encryption options for hosting of sites or mail<br />
<br />
===Features===<br />
It is quite important to consider the possibilities offered by your provider's control panel. If you need to write a support ticket everytime the server has to reboot, it wont be an efficient process, especially during a crises. Possible features to look out for include<br />
<br />
* Automated operating system installs<br />
* Server boot and reboot<br />
* Remote console (sometimes known as KVM)<br />
* Server and network statistics<br />
* Dynamic components (e.g. adding extra disk space, RAM without rebuilding the machine or having to order a new service)<br />
* Server access (varies between SSH, SFTP or web based)<br />
*<br />
<br />
==Secure hosting setups==<br />
Depending on available skill level the following secure system setups are possible:<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===Dedicated Server===<br />
For a [[Dedicated_Hosting | Dedicated Hosting]] system, the user can either run their own physical hardware or rent this hardware from a provider. The former solution offers total control of the physical hardware, however, there are significant downsides to this approach and should be avoided; it is only recommend under special circumstances such as [[Sensitive_Data | storing sensitive data]]. In the latter case, the hosting agent provides the hardware but the user has total control of the server via remote access. In this scenario, the provider is responsible for replacement of hardware parts that fail or malfunction - this support is generally done through a ticket system and relies on the user to report errors.<br />
<br />
'''Examples'''<br />
* http://www.ovh.com/ca/en/dedicated-servers/hosting/<br />
* http://www.soyoustart.com/ie/offers.xml<br />
* http://www.hetzner.de/en/hosting/produktmatrix/rootserver<br />
* http://www.coolhousing.net/hosting-dedicated-servers.html<br />
<br />
'''Benefits'''<br />
*User has total control of the system's software<br />
*User has total control of access rights<br />
*User has control of physical network connection, allowing them to whitelist or block connection from allowed or spurious connections<br />
*Financial cost of hardware malfunction is not an issue as the host is responsible for replacing/repairing failing hardware<br />
*The host can be chosen to place the server in a different jurisdiction from that of the user to prevent seizure<br />
<br />
'''Downsides'''<br />
*The user does not have physical access to the server<br />
*The host is not responsible for data loss or downtime if the physical server fails<br />
*The user is responsible for detecting and reporting hardware faults on some providers<br />
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].<br />
*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.<br />
<br />
===VPS===<br />
A Virtual Private Server(VPS) is an instance of a Virtual Operating System running on a much larger server. Typically multiple VPS will be run on a single server. In a VPS environment, you have a dedicated virtual private server but do not control the server on which it is hosted. Resources will be limited, you can not control or harden the outer server.<br />
<br />
'''Examples'''<br />
* https://www.linode.com/pricing<br />
* https://chhost.net/virtual-server/<br />
* https://www.tilaa.com/orders/add<br />
<br />
'''Benefits'''<br />
*The cost of this type of server will typically be significantly cheaper than a dedicated server<br />
*Depending on the host, the server will be capable of running most standard server software, up to a certain limit<br />
*Hardware is managed by the hosting provider unless self hosting<br />
*If self hosting, a single server can be used for multiple purposes and to provide multiple distinct servers<br />
<br />
'''Downsides'''<br />
*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<br />
*Bandwidth will also be restricted<br />
*Potential risk of provider, law enforcement or other state forces accessing contents of virtual server without user's awareness. <br />
*The user will not have access to the outer server and will thus not be able to harden it<br />
<br />
===Threats===<br />
*Social engineering attack<br />
*Password brute force<br />
*Service interruption through denial of service attack<br />
*System software exploits<br />
*SSL man-in-the-middle attacks<br />
*Data loss or data theft<br />
<br />
===Mitigation===<br />
'''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.<br />
<ol><br />
<li><br />
Enforce strong password - a strong password should contain Upper and Lower case characters, Numbers and Special Characters and should be long; greater than 20 characters. It is also possible to restrict the use of previously used passwords. On Linux systems the following command can be used to force complex passwords for users:<br />
</li><br />
password required pam_cracklib.so minlen=12 lcredit=1 ucredit=1 dcredit=2 ocredit=1<br />
<br />
For more detail, refer to the guide [http://www.linux-faqs.info/security/force-strong-passwords| Force strong passwords]<br />
<li><br />
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].<br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
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]<br />
</li><br />
</ol><br />
'''User Management''' on dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<ol><br />
<li><br />
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.<br />
</li><br />
<li><br />
Secure Shell(SSH) login should be forced, telnet and ftp login access should be disabled by default. To upload files to the server securely user can use Secure FTP(SFTP) clients. <br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
File permissions should be restricted for critical files. User should only be allowed access to files relevant to their work. Execution as root should be restricted. Discussion of [http://www.linux.com/learn/tutorials/309527-understanding-linux-file-permissions| linux file permissions].<br />
</li><br />
</ol><br />
'''Software Management'''<br />
<ol><br />
<li><br />
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].<br />
</li><br />
<li><br />
Minimising installed software is an important step in reducing potential vulnerabilities. The system should have the bare minimum of packages and software installed to support its purpose.<br />
</li><br />
</ol><br />
'''System Management'''<br />
<ol><br />
<li><br />
Firewall can be enabled via [http://www.netfilter.org/projects/iptables/| iptables] the guides [http://www.tecmint.com/basic-guide-on-iptables-linux-firewall-tips-commands/| here] and [http://www.cyberciti.biz/faq/category/iptables/| here] describe iptables configuration.<br />
</li><br />
<li><br />
To protect the server it is important to audit the open ports on the machine. To check listening ports you can run<br />
<br><br />
netstat -tulpn<br />
<br />
<br />
</li><br />
<li><br />
Logging and Auditing is a key aspect of server security. All hacking, brute force, DDoS or other attacks should be captured, monitored and analysed. <br />
<br><br />
This [http://www.cyberciti.biz/faq/linux-log-files-location-and-how-do-i-view-logs-files/| guide] describes the location and purpose of common Linux log files.<br />
<br />
<br><br />
<br />
To ensure that information is not lost, overwritten or that the logs do not grow infinitely the tool [http://www.thegeekstuff.com/2010/07/logrotate-examples/| Logrotate] can be used.<br />
<br><br />
<br />
Installing a tool like Logwatch allows you to monitor and respond to suspicious activity. The following [https://www.digitalocean.com/community/articles/how-to-install-and-use-logwatch-log-analyzer-and-reporter-on-a-vps| guide] describes installing and configuring Logwatch.<br />
</li><br />
<li><br />
[http://selinuxproject.org/page/Main_Page| Security Enhanced Linux(SELinux)] is a kernel level security control mechanism, which enforces a set of rules and procedures for the system. SELinux provides fine grained control for access rights and permissions.<br />
<br><br />
To check if it is enabled run<br />
<br><br />
<i><br />
sestatus<br />
</i><br />
<br><br />
To enable run<br />
<br><br />
<i><br />
setenforce enforcing<br />
</i><br />
<br><br />
To adjust the SELinux config is available at<br />
<br><br />
<i><br />
/etc/selinux/config <br />
</i><br />
</li><br />
<li><br />
[http://www.fail2ban.org/wiki/index.php/Main_Page| Fail2ban] is an excellent tool that can be used both to combat simple DDoS attacks but also to detect and block brute force login attempts.<br />
</li><br />
</ol><br />
<ul><br />
'''Apache hardening'''<br />
<br />
As well as considering the physical server and it's operating system users must thinking in terms of application security. Especially for those applications which either contain sensitive data or those that provide access routes to the machine for an attacker.<br />
<br />
Below is a set of guides for Apache webserver hardening.<br />
<li><br />
[http://www.tecmint.com/apache-security-tips/| 13 Apache Web Server Security and Hardening Tips]<br />
<li><br />
[http://xianshield.org/guides/apache2.0guide.html| Apache 2.0 Hardening Guide]<br />
</li><br />
</ul><br />
<ul><br />
'''Database hardening'''<br />
<br />
A key approach discussed elsewhere in protecting data, both at rest - on disk - and in use - in memory, is to encrypt these data stores either as part of full disk encryption or as individual restricted encrypted mount points.<br />
<br />
Below are further guides for specific hardening techniques for the MySQL database system.<br />
<li><br />
[http://www.greensql.com/content/mysql-security-best-practices-hardening-mysql-tips| MySQL Security Best Practices]<br />
</li><br />
<li><br />
[http://rochakchauhan.com/blog/2013/11/19/security-and-hardening-tips-for-mysql/| Security and Hardening Tips for MySQL]<br />
</li><br />
<li><br />
[http://www.securethelock.com/2014/01/09/12-steps-for-hardening-mysql-from-attackers/| 12 steps for Hardening MySQL from Attackers]<br />
</li><br />
</ul><br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted platform===<br />
For organisation that wish to setup their own custom site based on an existing platform such as Wordpress.com, there are a setup of steps that should be taken to ensure a good level of security. The [[Choosing_A_Host | choosing a hosting provider]] guide should also be consulted.<br />
<br />
'''Platform Security'''<br />
<ol><br />
<li><br />
Limiting access - Making smart choices that reduce possible entry points available to a malicious person.<br />
</li><br />
<li>Containment - Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.<br />
</li><br />
<li>Preparation and knowledge - Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.<br />
</li><br />
<li><br />
Passwords<br />
</li><br />
<li><br />
File Permissions<br />
</li><br />
<li><br />
Admin user<br />
</li><br />
<li><br />
SSL<br />
</li><br />
<li><br />
SFTP client<br />
</li><br />
<li><br />
Platform updates<br />
</li><br />
</ol><br />
Hosting install of pre-built software platform, such as Wordpress,<br />
<br />
===Shared Hosting===<br />
In a [[Shared_Hosting|Shared Hosting]] environment, your and other website owners shared one server. This includes sharing the physical server and the software applications within the server. Shared hosting services are affordable because the cost to operate the server is shared between you and these other owners. There are, however, a number of down sides, such as being slower.<br />
<br />
'''Examples:'''<br />
* http://www.easyweb.com<br />
* http://www.dreamhost.com/web-hosting/<br />
* http://wpengine.com/ (wordpress only)<br />
<br />
===Threat Mitigation===<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
For a basic setup providing a content distribution platform such as a blog user's have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
===Threat Mitigation===<br />
strong passwords, 2 factor auth,<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''Dedicated Server'''<br />
| style="padding: 5px;"| '''Virtual Private Server'''<br />
| style="padding: 5px;"| '''Shared Hosting'''<br />
| style="padding: 5px;"| '''Cloud Service'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Requires Intermediary technical skill<br />
| style="padding: 5px;"| Intermediary/Basic<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows disk/data encryption<br />
| style="padding: 5px;"| Allows encryption within VPS<br />
| style="padding: 5px;"| Limited or no control of data encryption<br />
| style="padding: 5px;"| Depends on provider but usually not provided<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| SSH and private key login<br />
| style="padding: 5px;"| Enforce secure login for VPS<br />
| style="padding: 5px;"| Login via CPanel or Custom interface - some hosts offer 2 factor auth<br />
| style="padding: 5px;"| Depends<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| User access control and restriction<br />
| style="padding: 5px;"| User control<br />
| style="padding: 5px;"| Control via user accounts added through management software<br />
| style="padding: 5px;"| Control via management software<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| Allows only shared SSL cert, most host provide shared cert<br />
| style="padding: 5px;"| Most host platforms will provide SSL support by default<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Total control of applications and software<br />
| style="padding: 5px;"| Control of software within VM, limited access to hardware depending on type of VM<br />
| style="padding: 5px;"| Application control only via management interface<br />
| style="padding: 5px;"| Depends on cloud server - certain services with provide data access restrictions but this is a non-ideal scenario<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Manually maintained and updated<br />
| style="padding: 5px;"| Server is patched but VPS remains responsibility of user<br />
| style="padding: 5px;"| Patches and updates provided by host - though may lag behind depending on quality of hosting<br />
| style="padding: 5px;"| Depending on scale of provider - patching and support will be provided to protect their reputation<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Limited supported - hardware support and replacement depending on provider<br />
| style="padding: 5px;"| Similar to dedicated support<br />
| style="padding: 5px;"| Support is generally in terms of management software - hardware is automatically monitored by hosts<br />
| style="padding: 5px;"| Similar to shared though support is specific to the platform hosting<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Anti-ddos and brute forcing via fail2ban, botnetdbp deployment<br />
| style="padding: 5px;"| Provider may or may not mitigate DDoS attacks<br />
| style="padding: 5px;"| DDoS attacks will receive some or limited mitigation depending on quality of host, generally they will not protect against large scale attacks and may force the website to be removed<br />
| style="padding: 5px;"| Depending on the provider if the attack crosses their threshold for protection they may shut down the website or ask it to leave<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/Choose_a_hosting_providerChoose a hosting provider2014-05-25T18:11:19Z<p>Bill: /* Mitigation */</p>
<hr />
<div>__NOTOC__<br />
===Criteria===<br />
<br />
There are several aspects which should be considered when selecting a service host. Below is a general list, this [https://pad.riseup.net/p/rh_ispq| document] gives detailed information on each area.<br />
<br />
*Price - relative services offered<br />
*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.<br />
*Specialisation - do they work in the field of human rights, software applications or general hosting<br />
*Is mail provided<br />
*Hardware specifications<br />
*Operating systems offered<br />
*Supported provided<br />
*Readily discusses your security concerns and which security features and processes they offer with their hosting.<br />
*Provides the most recent stable versions of all server software.<br />
*Provides reliable methods for backup and recovery.<br />
*Provides encryption options for hosting of sites or mail<br />
<br />
===Features===<br />
It is quite important to consider the possibilities offered by your provider's control panel. If you need to write a support ticket everytime the server has to reboot, it wont be an efficient process, especially during a crises. Possible features to look out for include<br />
<br />
* Automated operating system installs<br />
* Server boot and reboot<br />
* Remote console (sometimes known as KVM)<br />
* Server and network statistics<br />
* Dynamic components (e.g. adding extra disk space, RAM without rebuilding the machine or having to order a new service)<br />
* Server access (varies between SSH, SFTP or web based)<br />
*<br />
<br />
==Secure hosting setups==<br />
Depending on available skill level the following secure system setups are possible:<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===Dedicated Server===<br />
For a [[Dedicated_Hosting | Dedicated Hosting]] system, the user can either run their own physical hardware or rent this hardware from a provider. The former solution offers total control of the physical hardware, however, there are significant downsides to this approach and should be avoided; it is only recommend under special circumstances such as [[Sensitive_Data | storing sensitive data]]. In the latter case, the hosting agent provides the hardware but the user has total control of the server via remote access. In this scenario, the provider is responsible for replacement of hardware parts that fail or malfunction - this support is generally done through a ticket system and relies on the user to report errors.<br />
<br />
'''Examples'''<br />
* http://www.ovh.com/ca/en/dedicated-servers/hosting/<br />
* http://www.soyoustart.com/ie/offers.xml<br />
* http://www.hetzner.de/en/hosting/produktmatrix/rootserver<br />
* http://www.coolhousing.net/hosting-dedicated-servers.html<br />
<br />
'''Benefits'''<br />
*User has total control of the system's software<br />
*User has total control of access rights<br />
*User has control of physical network connection, allowing them to whitelist or block connection from allowed or spurious connections<br />
*Financial cost of hardware malfunction is not an issue as the host is responsible for replacing/repairing failing hardware<br />
*The host can be chosen to place the server in a different jurisdiction from that of the user to prevent seizure<br />
<br />
'''Downsides'''<br />
*The user does not have physical access to the server<br />
*The host is not responsible for data loss or downtime if the physical server fails<br />
*The user is responsible for detecting and reporting hardware faults on some providers<br />
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].<br />
*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.<br />
<br />
===VPS===<br />
A Virtual Private Server(VPS) is an instance of a Virtual Operating System running on a much larger server. Typically multiple VPS will be run on a single server. In a VPS environment, you have a dedicated virtual private server but do not control the server on which it is hosted. Resources will be limited, you can not control or harden the outer server.<br />
<br />
'''Examples'''<br />
* https://www.linode.com/pricing<br />
* https://chhost.net/virtual-server/<br />
* https://www.tilaa.com/orders/add<br />
<br />
'''Benefits'''<br />
*The cost of this type of server will typically be significantly cheaper than a dedicated server<br />
*Depending on the host, the server will be capable of running most standard server software, up to a certain limit<br />
*Hardware is managed by the hosting provider unless self hosting<br />
*If self hosting, a single server can be used for multiple purposes and to provide multiple distinct servers<br />
<br />
'''Downsides'''<br />
*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<br />
*Bandwidth will also be restricted<br />
*Potential risk of provider, law enforcement or other state forces accessing contents of virtual server without user's awareness. <br />
*The user will not have access to the outer server and will thus not be able to harden it<br />
<br />
===Threats===<br />
*Social engineering attack<br />
*Password brute force<br />
*Service interruption through denial of service attack<br />
*System software exploits<br />
*SSL man-in-the-middle attacks<br />
*Data loss or data theft<br />
<br />
===Mitigation===<br />
'''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.<br />
<ol><br />
<li><br />
Enforce strong password - a strong password should contain Upper and Lower case characters, Numbers and Special Characters and should be long; greater than 20 characters. It is also possible to restrict the use of previously used passwords. On Linux systems the following command can be used to force complex passwords for users:<br />
</li><br />
password required pam_cracklib.so minlen=12 lcredit=1 ucredit=1 dcredit=2 ocredit=1<br />
<br />
For more detail, refer to the guide [http://www.linux-faqs.info/security/force-strong-passwords| Force strong passwords]<br />
<li><br />
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].<br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
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]<br />
</li><br />
</ol><br />
'''User Management''' on dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<ol><br />
<li><br />
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.<br />
</li><br />
<li><br />
Secure Shell(SSH) login should be forced, telnet and ftp login access should be disabled by default. To upload files to the server securely user can use Secure FTP(SFTP) clients. <br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
File permissions should be restricted for critical files. User should only be allowed access to files relevant to their work. Execution as root should be restricted. Discussion of [http://www.linux.com/learn/tutorials/309527-understanding-linux-file-permissions| linux file permissions].<br />
</li><br />
</ol><br />
'''Software Management'''<br />
<ol><br />
<li><br />
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].<br />
</li><br />
<li><br />
Minimising installed software is an important step in reducing potential vulnerabilities. The system should have the bare minimum of packages and software installed to support its purpose.<br />
</li><br />
</ol><br />
'''System Management'''<br />
<ol><br />
<li><br />
Firewall can be enabled via [http://www.netfilter.org/projects/iptables/| iptables] the guides [http://www.tecmint.com/basic-guide-on-iptables-linux-firewall-tips-commands/| here] and [http://www.cyberciti.biz/faq/category/iptables/| here] describe iptables configuration.<br />
</li><br />
<li><br />
To protect the server it is important to audit the open ports on the machine. To check listening ports you can run<br />
<br><br />
netstat -tulpn<br />
<br />
<br />
</li><br />
<li><br />
Logging and Auditing<br />
</li><br />
<li><br />
Anti-intrusion system,<br />
</li><br />
<li><br />
[http://selinuxproject.org/page/Main_Page| Security Enhanced Linux(SELinux)] is a kernel level security control mechanism, which enforces a set of rules and procedures for the system. SELinux provides fine grained control for access rights and permissions.<br />
<br><br />
To check if it is enabled run<br />
<br><br />
<i><br />
sestatus<br />
</i><br />
<br><br />
To enable run<br />
<br><br />
<i><br />
setenforce enforcing<br />
</i><br />
<br><br />
To adjust the SELinux config is available at<br />
<br><br />
<i><br />
/etc/selinux/config <br />
</i><br />
</li><br />
<li><br />
[http://www.fail2ban.org/wiki/index.php/Main_Page| Fail2ban] is an excellent tool that can be used both to combat simple DDoS attacks but also to detect and block brute force login attempts.<br />
</li><br />
</ol><br />
<ul><br />
'''Apache hardening'''<br />
<br />
As well as considering the physical server and it's operating system users must thinking in terms of application security. Especially for those applications which either contain sensitive data or those that provide access routes to the machine for an attacker.<br />
<br />
Below is a set of guides for Apache webserver hardening.<br />
<li><br />
[http://www.tecmint.com/apache-security-tips/| 13 Apache Web Server Security and Hardening Tips]<br />
<li><br />
[http://xianshield.org/guides/apache2.0guide.html| Apache 2.0 Hardening Guide]<br />
</li><br />
</ul><br />
<ul><br />
'''Database hardening'''<br />
<br />
A key approach discussed elsewhere in protecting data, both at rest - on disk - and in use - in memory, is to encrypt these data stores either as part of full disk encryption or as individual restricted encrypted mount points.<br />
<br />
Below are further guides for specific hardening techniques for the MySQL database system.<br />
<li><br />
[http://www.greensql.com/content/mysql-security-best-practices-hardening-mysql-tips| MySQL Security Best Practices]<br />
</li><br />
<li><br />
[http://rochakchauhan.com/blog/2013/11/19/security-and-hardening-tips-for-mysql/| Security and Hardening Tips for MySQL]<br />
</li><br />
<li><br />
[http://www.securethelock.com/2014/01/09/12-steps-for-hardening-mysql-from-attackers/| 12 steps for Hardening MySQL from Attackers]<br />
</li><br />
</ul><br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted platform===<br />
For organisation that wish to setup their own custom site based on an existing platform such as Wordpress.com, there are a setup of steps that should be taken to ensure a good level of security. The [[Choosing_A_Host | choosing a hosting provider]] guide should also be consulted.<br />
<br />
'''Platform Security'''<br />
<ol><br />
<li><br />
Limiting access - Making smart choices that reduce possible entry points available to a malicious person.<br />
</li><br />
<li>Containment - Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.<br />
</li><br />
<li>Preparation and knowledge - Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.<br />
</li><br />
<li><br />
Passwords<br />
</li><br />
<li><br />
File Permissions<br />
</li><br />
<li><br />
Admin user<br />
</li><br />
<li><br />
SSL<br />
</li><br />
<li><br />
SFTP client<br />
</li><br />
<li><br />
Platform updates<br />
</li><br />
</ol><br />
Hosting install of pre-built software platform, such as Wordpress,<br />
<br />
===Shared Hosting===<br />
In a [[Shared_Hosting|Shared Hosting]] environment, your and other website owners shared one server. This includes sharing the physical server and the software applications within the server. Shared hosting services are affordable because the cost to operate the server is shared between you and these other owners. There are, however, a number of down sides, such as being slower.<br />
<br />
'''Examples:'''<br />
* http://www.easyweb.com<br />
* http://www.dreamhost.com/web-hosting/<br />
* http://wpengine.com/ (wordpress only)<br />
<br />
===Threat Mitigation===<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
For a basic setup providing a content distribution platform such as a blog user's have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
===Threat Mitigation===<br />
strong passwords, 2 factor auth,<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''Dedicated Server'''<br />
| style="padding: 5px;"| '''Virtual Private Server'''<br />
| style="padding: 5px;"| '''Shared Hosting'''<br />
| style="padding: 5px;"| '''Cloud Service'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Requires Intermediary technical skill<br />
| style="padding: 5px;"| Intermediary/Basic<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows disk/data encryption<br />
| style="padding: 5px;"| Allows encryption within VPS<br />
| style="padding: 5px;"| Limited or no control of data encryption<br />
| style="padding: 5px;"| Depends on provider but usually not provided<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| SSH and private key login<br />
| style="padding: 5px;"| Enforce secure login for VPS<br />
| style="padding: 5px;"| Login via CPanel or Custom interface - some hosts offer 2 factor auth<br />
| style="padding: 5px;"| Depends<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| User access control and restriction<br />
| style="padding: 5px;"| User control<br />
| style="padding: 5px;"| Control via user accounts added through management software<br />
| style="padding: 5px;"| Control via management software<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| Allows only shared SSL cert, most host provide shared cert<br />
| style="padding: 5px;"| Most host platforms will provide SSL support by default<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Total control of applications and software<br />
| style="padding: 5px;"| Control of software within VM, limited access to hardware depending on type of VM<br />
| style="padding: 5px;"| Application control only via management interface<br />
| style="padding: 5px;"| Depends on cloud server - certain services with provide data access restrictions but this is a non-ideal scenario<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Manually maintained and updated<br />
| style="padding: 5px;"| Server is patched but VPS remains responsibility of user<br />
| style="padding: 5px;"| Patches and updates provided by host - though may lag behind depending on quality of hosting<br />
| style="padding: 5px;"| Depending on scale of provider - patching and support will be provided to protect their reputation<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Limited supported - hardware support and replacement depending on provider<br />
| style="padding: 5px;"| Similar to dedicated support<br />
| style="padding: 5px;"| Support is generally in terms of management software - hardware is automatically monitored by hosts<br />
| style="padding: 5px;"| Similar to shared though support is specific to the platform hosting<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Anti-ddos and brute forcing via fail2ban, botnetdbp deployment<br />
| style="padding: 5px;"| Provider may or may not mitigate DDoS attacks<br />
| style="padding: 5px;"| DDoS attacks will receive some or limited mitigation depending on quality of host, generally they will not protect against large scale attacks and may force the website to be removed<br />
| style="padding: 5px;"| Depending on the provider if the attack crosses their threshold for protection they may shut down the website or ask it to leave<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/Choose_a_hosting_providerChoose a hosting provider2014-05-25T18:10:21Z<p>Bill: /* Mitigation */</p>
<hr />
<div>__NOTOC__<br />
===Criteria===<br />
<br />
There are several aspects which should be considered when selecting a service host. Below is a general list, this [https://pad.riseup.net/p/rh_ispq| document] gives detailed information on each area.<br />
<br />
*Price - relative services offered<br />
*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.<br />
*Specialisation - do they work in the field of human rights, software applications or general hosting<br />
*Is mail provided<br />
*Hardware specifications<br />
*Operating systems offered<br />
*Supported provided<br />
*Readily discusses your security concerns and which security features and processes they offer with their hosting.<br />
*Provides the most recent stable versions of all server software.<br />
*Provides reliable methods for backup and recovery.<br />
*Provides encryption options for hosting of sites or mail<br />
<br />
===Features===<br />
It is quite important to consider the possibilities offered by your provider's control panel. If you need to write a support ticket everytime the server has to reboot, it wont be an efficient process, especially during a crises. Possible features to look out for include<br />
<br />
* Automated operating system installs<br />
* Server boot and reboot<br />
* Remote console (sometimes known as KVM)<br />
* Server and network statistics<br />
* Dynamic components (e.g. adding extra disk space, RAM without rebuilding the machine or having to order a new service)<br />
* Server access (varies between SSH, SFTP or web based)<br />
*<br />
<br />
==Secure hosting setups==<br />
Depending on available skill level the following secure system setups are possible:<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===Dedicated Server===<br />
For a [[Dedicated_Hosting | Dedicated Hosting]] system, the user can either run their own physical hardware or rent this hardware from a provider. The former solution offers total control of the physical hardware, however, there are significant downsides to this approach and should be avoided; it is only recommend under special circumstances such as [[Sensitive_Data | storing sensitive data]]. In the latter case, the hosting agent provides the hardware but the user has total control of the server via remote access. In this scenario, the provider is responsible for replacement of hardware parts that fail or malfunction - this support is generally done through a ticket system and relies on the user to report errors.<br />
<br />
'''Examples'''<br />
* http://www.ovh.com/ca/en/dedicated-servers/hosting/<br />
* http://www.soyoustart.com/ie/offers.xml<br />
* http://www.hetzner.de/en/hosting/produktmatrix/rootserver<br />
* http://www.coolhousing.net/hosting-dedicated-servers.html<br />
<br />
'''Benefits'''<br />
*User has total control of the system's software<br />
*User has total control of access rights<br />
*User has control of physical network connection, allowing them to whitelist or block connection from allowed or spurious connections<br />
*Financial cost of hardware malfunction is not an issue as the host is responsible for replacing/repairing failing hardware<br />
*The host can be chosen to place the server in a different jurisdiction from that of the user to prevent seizure<br />
<br />
'''Downsides'''<br />
*The user does not have physical access to the server<br />
*The host is not responsible for data loss or downtime if the physical server fails<br />
*The user is responsible for detecting and reporting hardware faults on some providers<br />
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].<br />
*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.<br />
<br />
===VPS===<br />
A Virtual Private Server(VPS) is an instance of a Virtual Operating System running on a much larger server. Typically multiple VPS will be run on a single server. In a VPS environment, you have a dedicated virtual private server but do not control the server on which it is hosted. Resources will be limited, you can not control or harden the outer server.<br />
<br />
'''Examples'''<br />
* https://www.linode.com/pricing<br />
* https://chhost.net/virtual-server/<br />
* https://www.tilaa.com/orders/add<br />
<br />
'''Benefits'''<br />
*The cost of this type of server will typically be significantly cheaper than a dedicated server<br />
*Depending on the host, the server will be capable of running most standard server software, up to a certain limit<br />
*Hardware is managed by the hosting provider unless self hosting<br />
*If self hosting, a single server can be used for multiple purposes and to provide multiple distinct servers<br />
<br />
'''Downsides'''<br />
*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<br />
*Bandwidth will also be restricted<br />
*Potential risk of provider, law enforcement or other state forces accessing contents of virtual server without user's awareness. <br />
*The user will not have access to the outer server and will thus not be able to harden it<br />
<br />
===Threats===<br />
*Social engineering attack<br />
*Password brute force<br />
*Service interruption through denial of service attack<br />
*System software exploits<br />
*SSL man-in-the-middle attacks<br />
*Data loss or data theft<br />
<br />
===Mitigation===<br />
'''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.<br />
<ol><br />
<li><br />
Enforce strong password - a strong password should contain Upper and Lower case characters, Numbers and Special Characters and should be long; greater than 20 characters. It is also possible to restrict the use of previously used passwords. On Linux systems the following command can be used to force complex passwords for users:<br />
</li><br />
password required pam_cracklib.so minlen=12 lcredit=1 ucredit=1 dcredit=2 ocredit=1<br />
<br />
For more detail, refer to the guide [http://www.linux-faqs.info/security/force-strong-passwords| Force strong passwords]<br />
<li><br />
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].<br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
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]<br />
</li><br />
</ol><br />
'''User Management''' on dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<ol><br />
<li><br />
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.<br />
</li><br />
<li><br />
Secure Shell(SSH) login should be forced, telnet and ftp login access should be disabled by default. To upload files to the server securely user can use Secure FTP(SFTP) clients. <br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
File permissions should be restricted for critical files. User should only be allowed access to files relevant to their work. Execution as root should be restricted. Discussion of [http://www.linux.com/learn/tutorials/309527-understanding-linux-file-permissions| linux file permissions].<br />
</li><br />
</ol><br />
'''Software Management'''<br />
<ol><br />
<li><br />
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].<br />
</li><br />
<li><br />
Minimising installed software is an important step in reducing potential vulnerabilities. The system should have the bare minimum of packages and software installed to support its purpose.<br />
</li><br />
</ol><br />
'''System Management'''<br />
<ol><br />
<li><br />
Firewall can be enabled via [http://www.netfilter.org/projects/iptables/| iptables] the guides [http://www.tecmint.com/basic-guide-on-iptables-linux-firewall-tips-commands/| here] and [http://www.cyberciti.biz/faq/category/iptables/| here] describe iptables configuration.<br />
</li><br />
<li><br />
To protect the server it is important to audit the open ports on the machine. To check listening ports you can run<br />
<br><br />
netstat -tulpn<br />
<br />
<br />
</li><br />
<li><br />
Logging and Auditing<br />
</li><br />
<li><br />
Anti-intrusion system,<br />
</li><br />
<li><br />
[http://selinuxproject.org/page/Main_Page| Security Enhanced Linux(SELinux)] is a kernel level security control mechanism, which enforces a set of rules and procedures for the system. SELinux provides fine grained control for access rights and permissions.<br />
<br><br />
To check if it is enabled run<br />
<br><br />
sestatus<br />
<br><br />
To enable run<br />
<br><br />
setenforce enforcing<br />
<br><br />
To adjust the SELinux config is available at<br />
<br><br />
/etc/selinux/config <br />
</li><br />
<li><br />
[http://www.fail2ban.org/wiki/index.php/Main_Page| Fail2ban] is an excellent tool that can be used both to combat simple DDoS attacks but also to detect and block brute force login attempts.<br />
</li><br />
</ol><br />
<ul><br />
'''Apache hardening'''<br />
<br />
As well as considering the physical server and it's operating system users must thinking in terms of application security. Especially for those applications which either contain sensitive data or those that provide access routes to the machine for an attacker.<br />
<br />
Below is a set of guides for Apache webserver hardening.<br />
<li><br />
[http://www.tecmint.com/apache-security-tips/| 13 Apache Web Server Security and Hardening Tips]<br />
<li><br />
[http://xianshield.org/guides/apache2.0guide.html| Apache 2.0 Hardening Guide]<br />
</li><br />
</ul><br />
<ul><br />
'''Database hardening'''<br />
<br />
A key approach discussed elsewhere in protecting data, both at rest - on disk - and in use - in memory, is to encrypt these data stores either as part of full disk encryption or as individual restricted encrypted mount points.<br />
<br />
Below are further guides for specific hardening techniques for the MySQL database system.<br />
<li><br />
[http://www.greensql.com/content/mysql-security-best-practices-hardening-mysql-tips| MySQL Security Best Practices]<br />
</li><br />
<li><br />
[http://rochakchauhan.com/blog/2013/11/19/security-and-hardening-tips-for-mysql/| Security and Hardening Tips for MySQL]<br />
</li><br />
<li><br />
[http://www.securethelock.com/2014/01/09/12-steps-for-hardening-mysql-from-attackers/| 12 steps for Hardening MySQL from Attackers]<br />
</li><br />
</ul><br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted platform===<br />
For organisation that wish to setup their own custom site based on an existing platform such as Wordpress.com, there are a setup of steps that should be taken to ensure a good level of security. The [[Choosing_A_Host | choosing a hosting provider]] guide should also be consulted.<br />
<br />
'''Platform Security'''<br />
<ol><br />
<li><br />
Limiting access - Making smart choices that reduce possible entry points available to a malicious person.<br />
</li><br />
<li>Containment - Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.<br />
</li><br />
<li>Preparation and knowledge - Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.<br />
</li><br />
<li><br />
Passwords<br />
</li><br />
<li><br />
File Permissions<br />
</li><br />
<li><br />
Admin user<br />
</li><br />
<li><br />
SSL<br />
</li><br />
<li><br />
SFTP client<br />
</li><br />
<li><br />
Platform updates<br />
</li><br />
</ol><br />
Hosting install of pre-built software platform, such as Wordpress,<br />
<br />
===Shared Hosting===<br />
In a [[Shared_Hosting|Shared Hosting]] environment, your and other website owners shared one server. This includes sharing the physical server and the software applications within the server. Shared hosting services are affordable because the cost to operate the server is shared between you and these other owners. There are, however, a number of down sides, such as being slower.<br />
<br />
'''Examples:'''<br />
* http://www.easyweb.com<br />
* http://www.dreamhost.com/web-hosting/<br />
* http://wpengine.com/ (wordpress only)<br />
<br />
===Threat Mitigation===<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
For a basic setup providing a content distribution platform such as a blog user's have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
===Threat Mitigation===<br />
strong passwords, 2 factor auth,<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''Dedicated Server'''<br />
| style="padding: 5px;"| '''Virtual Private Server'''<br />
| style="padding: 5px;"| '''Shared Hosting'''<br />
| style="padding: 5px;"| '''Cloud Service'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Requires Intermediary technical skill<br />
| style="padding: 5px;"| Intermediary/Basic<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows disk/data encryption<br />
| style="padding: 5px;"| Allows encryption within VPS<br />
| style="padding: 5px;"| Limited or no control of data encryption<br />
| style="padding: 5px;"| Depends on provider but usually not provided<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| SSH and private key login<br />
| style="padding: 5px;"| Enforce secure login for VPS<br />
| style="padding: 5px;"| Login via CPanel or Custom interface - some hosts offer 2 factor auth<br />
| style="padding: 5px;"| Depends<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| User access control and restriction<br />
| style="padding: 5px;"| User control<br />
| style="padding: 5px;"| Control via user accounts added through management software<br />
| style="padding: 5px;"| Control via management software<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| Allows only shared SSL cert, most host provide shared cert<br />
| style="padding: 5px;"| Most host platforms will provide SSL support by default<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Total control of applications and software<br />
| style="padding: 5px;"| Control of software within VM, limited access to hardware depending on type of VM<br />
| style="padding: 5px;"| Application control only via management interface<br />
| style="padding: 5px;"| Depends on cloud server - certain services with provide data access restrictions but this is a non-ideal scenario<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Manually maintained and updated<br />
| style="padding: 5px;"| Server is patched but VPS remains responsibility of user<br />
| style="padding: 5px;"| Patches and updates provided by host - though may lag behind depending on quality of hosting<br />
| style="padding: 5px;"| Depending on scale of provider - patching and support will be provided to protect their reputation<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Limited supported - hardware support and replacement depending on provider<br />
| style="padding: 5px;"| Similar to dedicated support<br />
| style="padding: 5px;"| Support is generally in terms of management software - hardware is automatically monitored by hosts<br />
| style="padding: 5px;"| Similar to shared though support is specific to the platform hosting<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Anti-ddos and brute forcing via fail2ban, botnetdbp deployment<br />
| style="padding: 5px;"| Provider may or may not mitigate DDoS attacks<br />
| style="padding: 5px;"| DDoS attacks will receive some or limited mitigation depending on quality of host, generally they will not protect against large scale attacks and may force the website to be removed<br />
| style="padding: 5px;"| Depending on the provider if the attack crosses their threshold for protection they may shut down the website or ask it to leave<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/Choose_a_hosting_providerChoose a hosting provider2014-05-25T18:08:10Z<p>Bill: /* High Technical */</p>
<hr />
<div>__NOTOC__<br />
===Criteria===<br />
<br />
There are several aspects which should be considered when selecting a service host. Below is a general list, this [https://pad.riseup.net/p/rh_ispq| document] gives detailed information on each area.<br />
<br />
*Price - relative services offered<br />
*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.<br />
*Specialisation - do they work in the field of human rights, software applications or general hosting<br />
*Is mail provided<br />
*Hardware specifications<br />
*Operating systems offered<br />
*Supported provided<br />
*Readily discusses your security concerns and which security features and processes they offer with their hosting.<br />
*Provides the most recent stable versions of all server software.<br />
*Provides reliable methods for backup and recovery.<br />
*Provides encryption options for hosting of sites or mail<br />
<br />
===Features===<br />
It is quite important to consider the possibilities offered by your provider's control panel. If you need to write a support ticket everytime the server has to reboot, it wont be an efficient process, especially during a crises. Possible features to look out for include<br />
<br />
* Automated operating system installs<br />
* Server boot and reboot<br />
* Remote console (sometimes known as KVM)<br />
* Server and network statistics<br />
* Dynamic components (e.g. adding extra disk space, RAM without rebuilding the machine or having to order a new service)<br />
* Server access (varies between SSH, SFTP or web based)<br />
*<br />
<br />
==Secure hosting setups==<br />
Depending on available skill level the following secure system setups are possible:<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===Dedicated Server===<br />
For a [[Dedicated_Hosting | Dedicated Hosting]] system, the user can either run their own physical hardware or rent this hardware from a provider. The former solution offers total control of the physical hardware, however, there are significant downsides to this approach and should be avoided; it is only recommend under special circumstances such as [[Sensitive_Data | storing sensitive data]]. In the latter case, the hosting agent provides the hardware but the user has total control of the server via remote access. In this scenario, the provider is responsible for replacement of hardware parts that fail or malfunction - this support is generally done through a ticket system and relies on the user to report errors.<br />
<br />
'''Examples'''<br />
* http://www.ovh.com/ca/en/dedicated-servers/hosting/<br />
* http://www.soyoustart.com/ie/offers.xml<br />
* http://www.hetzner.de/en/hosting/produktmatrix/rootserver<br />
* http://www.coolhousing.net/hosting-dedicated-servers.html<br />
<br />
'''Benefits'''<br />
*User has total control of the system's software<br />
*User has total control of access rights<br />
*User has control of physical network connection, allowing them to whitelist or block connection from allowed or spurious connections<br />
*Financial cost of hardware malfunction is not an issue as the host is responsible for replacing/repairing failing hardware<br />
*The host can be chosen to place the server in a different jurisdiction from that of the user to prevent seizure<br />
<br />
'''Downsides'''<br />
*The user does not have physical access to the server<br />
*The host is not responsible for data loss or downtime if the physical server fails<br />
*The user is responsible for detecting and reporting hardware faults on some providers<br />
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].<br />
*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.<br />
<br />
===VPS===<br />
A Virtual Private Server(VPS) is an instance of a Virtual Operating System running on a much larger server. Typically multiple VPS will be run on a single server. In a VPS environment, you have a dedicated virtual private server but do not control the server on which it is hosted. Resources will be limited, you can not control or harden the outer server.<br />
<br />
'''Examples'''<br />
* https://www.linode.com/pricing<br />
* https://chhost.net/virtual-server/<br />
* https://www.tilaa.com/orders/add<br />
<br />
'''Benefits'''<br />
*The cost of this type of server will typically be significantly cheaper than a dedicated server<br />
*Depending on the host, the server will be capable of running most standard server software, up to a certain limit<br />
*Hardware is managed by the hosting provider unless self hosting<br />
*If self hosting, a single server can be used for multiple purposes and to provide multiple distinct servers<br />
<br />
'''Downsides'''<br />
*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<br />
*Bandwidth will also be restricted<br />
*Potential risk of provider, law enforcement or other state forces accessing contents of virtual server without user's awareness. <br />
*The user will not have access to the outer server and will thus not be able to harden it<br />
<br />
===Threats===<br />
*Social engineering attack<br />
*Password brute force<br />
*Service interruption through denial of service attack<br />
*System software exploits<br />
*SSL man-in-the-middle attacks<br />
*Data loss or data theft<br />
<br />
===Mitigation===<br />
'''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.<br />
<ol><br />
<li><br />
Enforce strong password - a strong password should contain Upper and Lower case characters, Numbers and Special Characters and should be long; greater than 20 characters. It is also possible to restrict the use of previously used passwords. On Linux systems the following command can be used to force complex passwords for users:<br />
</li><br />
password required pam_cracklib.so minlen=12 lcredit=1 ucredit=1 dcredit=2 ocredit=1<br />
<br />
For more detail, refer to the guide [http://www.linux-faqs.info/security/force-strong-passwords| Force strong passwords]<br />
<li><br />
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].<br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
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]<br />
</li><br />
</ol><br />
'''User Management''' on dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<ol><br />
<li><br />
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.<br />
</li><br />
<li><br />
Secure Shell(SSH) login should be forced, telnet and ftp login access should be disabled by default. To upload files to the server securely user can use Secure FTP(SFTP) clients. <br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
File permissions should be restricted for critical files. User should only be allowed access to files relevant to their work. Execution as root should be restricted. Discussion of [http://www.linux.com/learn/tutorials/309527-understanding-linux-file-permissions| linux file permissions].<br />
</li><br />
</ol><br />
'''Software Management'''<br />
<ol><br />
<li><br />
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].<br />
</li><br />
<li><br />
Minimising installed software is an important step in reducing potential vulnerabilities. The system should have the bare minimum of packages and software installed to support its purpose.<br />
</li><br />
</ol><br />
'''System Management'''<br />
<ol><br />
<li><br />
Firewall can be enabled via [http://www.netfilter.org/projects/iptables/| iptables] the guides [http://www.tecmint.com/basic-guide-on-iptables-linux-firewall-tips-commands/| here] and [http://www.cyberciti.biz/faq/category/iptables/| here] describe iptables configuration.<br />
</li><br />
<li><br />
To protect the server it is important to audit the open ports on the machine. To check listening ports you can run<br />
<br />
netstat -tulpn<br />
<br />
<br />
</li><br />
<li><br />
Logging and Auditing<br />
</li><br />
<li><br />
Anti-intrusion system,<br />
</li><br />
<li><br />
[http://selinuxproject.org/page/Main_Page| Security Enhanced Linux(SELinux)] is a kernel level security control mechanism, which enforces a set of rules and procedures for the system. SELinux provides fine grained control for access rights and permissions.<br />
<br />
To check if it is enabled run<br />
<br />
sestatus<br />
<br />
To enable run<br />
<br />
setenforce enforcing<br />
<br />
To adjust the SELinux config is available at<br />
<br />
/etc/selinux/config <br />
</li><br />
<li><br />
[http://www.fail2ban.org/wiki/index.php/Main_Page| Fail2ban] is an excellent tool that can be used both to combat simple DDoS attacks but also to detect and block brute force login attempts.<br />
</li><br />
</ol><br />
<ul><br />
'''Apache hardening'''<br />
<br />
As well as considering the physical server and it's operating system users must thinking in terms of application security. Especially for those applications which either contain sensitive data or those that provide access routes to the machine for an attacker.<br />
<br />
Below is a set of guides for Apache webserver hardening.<br />
<li><br />
[http://www.tecmint.com/apache-security-tips/| 13 Apache Web Server Security and Hardening Tips]<br />
<li><br />
[http://xianshield.org/guides/apache2.0guide.html| Apache 2.0 Hardening Guide]<br />
</li><br />
</ul><br />
<ul><br />
'''Database hardening'''<br />
<br />
A key approach discussed elsewhere in protecting data, both at rest - on disk - and in use - in memory, is to encrypt these data stores either as part of full disk encryption or as individual restricted encrypted mount points.<br />
<br />
Below are further guides for specific hardening techniques for the MySQL database system.<br />
<li><br />
[http://www.greensql.com/content/mysql-security-best-practices-hardening-mysql-tips| MySQL Security Best Practices]<br />
</li><br />
<li><br />
[http://rochakchauhan.com/blog/2013/11/19/security-and-hardening-tips-for-mysql/| Security and Hardening Tips for MySQL]<br />
</li><br />
<li><br />
[http://www.securethelock.com/2014/01/09/12-steps-for-hardening-mysql-from-attackers/| 12 steps for Hardening MySQL from Attackers]<br />
</li><br />
</ul><br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted platform===<br />
For organisation that wish to setup their own custom site based on an existing platform such as Wordpress.com, there are a setup of steps that should be taken to ensure a good level of security. The [[Choosing_A_Host | choosing a hosting provider]] guide should also be consulted.<br />
<br />
'''Platform Security'''<br />
<ol><br />
<li><br />
Limiting access - Making smart choices that reduce possible entry points available to a malicious person.<br />
</li><br />
<li>Containment - Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.<br />
</li><br />
<li>Preparation and knowledge - Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.<br />
</li><br />
<li><br />
Passwords<br />
</li><br />
<li><br />
File Permissions<br />
</li><br />
<li><br />
Admin user<br />
</li><br />
<li><br />
SSL<br />
</li><br />
<li><br />
SFTP client<br />
</li><br />
<li><br />
Platform updates<br />
</li><br />
</ol><br />
Hosting install of pre-built software platform, such as Wordpress,<br />
<br />
===Shared Hosting===<br />
In a [[Shared_Hosting|Shared Hosting]] environment, your and other website owners shared one server. This includes sharing the physical server and the software applications within the server. Shared hosting services are affordable because the cost to operate the server is shared between you and these other owners. There are, however, a number of down sides, such as being slower.<br />
<br />
'''Examples:'''<br />
* http://www.easyweb.com<br />
* http://www.dreamhost.com/web-hosting/<br />
* http://wpengine.com/ (wordpress only)<br />
<br />
===Threat Mitigation===<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
For a basic setup providing a content distribution platform such as a blog user's have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
===Threat Mitigation===<br />
strong passwords, 2 factor auth,<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''Dedicated Server'''<br />
| style="padding: 5px;"| '''Virtual Private Server'''<br />
| style="padding: 5px;"| '''Shared Hosting'''<br />
| style="padding: 5px;"| '''Cloud Service'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Requires Intermediary technical skill<br />
| style="padding: 5px;"| Intermediary/Basic<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows disk/data encryption<br />
| style="padding: 5px;"| Allows encryption within VPS<br />
| style="padding: 5px;"| Limited or no control of data encryption<br />
| style="padding: 5px;"| Depends on provider but usually not provided<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| SSH and private key login<br />
| style="padding: 5px;"| Enforce secure login for VPS<br />
| style="padding: 5px;"| Login via CPanel or Custom interface - some hosts offer 2 factor auth<br />
| style="padding: 5px;"| Depends<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| User access control and restriction<br />
| style="padding: 5px;"| User control<br />
| style="padding: 5px;"| Control via user accounts added through management software<br />
| style="padding: 5px;"| Control via management software<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| Allows only shared SSL cert, most host provide shared cert<br />
| style="padding: 5px;"| Most host platforms will provide SSL support by default<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Total control of applications and software<br />
| style="padding: 5px;"| Control of software within VM, limited access to hardware depending on type of VM<br />
| style="padding: 5px;"| Application control only via management interface<br />
| style="padding: 5px;"| Depends on cloud server - certain services with provide data access restrictions but this is a non-ideal scenario<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Manually maintained and updated<br />
| style="padding: 5px;"| Server is patched but VPS remains responsibility of user<br />
| style="padding: 5px;"| Patches and updates provided by host - though may lag behind depending on quality of hosting<br />
| style="padding: 5px;"| Depending on scale of provider - patching and support will be provided to protect their reputation<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Limited supported - hardware support and replacement depending on provider<br />
| style="padding: 5px;"| Similar to dedicated support<br />
| style="padding: 5px;"| Support is generally in terms of management software - hardware is automatically monitored by hosts<br />
| style="padding: 5px;"| Similar to shared though support is specific to the platform hosting<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Anti-ddos and brute forcing via fail2ban, botnetdbp deployment<br />
| style="padding: 5px;"| Provider may or may not mitigate DDoS attacks<br />
| style="padding: 5px;"| DDoS attacks will receive some or limited mitigation depending on quality of host, generally they will not protect against large scale attacks and may force the website to be removed<br />
| style="padding: 5px;"| Depending on the provider if the attack crosses their threshold for protection they may shut down the website or ask it to leave<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/Choose_a_hosting_providerChoose a hosting provider2014-05-25T17:51:23Z<p>Bill: </p>
<hr />
<div>__NOTOC__<br />
===Criteria===<br />
<br />
There are several aspects which should be considered when selecting a service host. Below is a general list, this [https://pad.riseup.net/p/rh_ispq| document] gives detailed information on each area.<br />
<br />
*Price - relative services offered<br />
*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.<br />
*Specialisation - do they work in the field of human rights, software applications or general hosting<br />
*Is mail provided<br />
*Hardware specifications<br />
*Operating systems offered<br />
*Supported provided<br />
*Readily discusses your security concerns and which security features and processes they offer with their hosting.<br />
*Provides the most recent stable versions of all server software.<br />
*Provides reliable methods for backup and recovery.<br />
*Provides encryption options for hosting of sites or mail<br />
<br />
===Features===<br />
It is quite important to consider the possibilities offered by your provider's control panel. If you need to write a support ticket everytime the server has to reboot, it wont be an efficient process, especially during a crises. Possible features to look out for include<br />
<br />
* Automated operating system installs<br />
* Server boot and reboot<br />
* Remote console (sometimes known as KVM)<br />
* Server and network statistics<br />
* Dynamic components (e.g. adding extra disk space, RAM without rebuilding the machine or having to order a new service)<br />
* Server access (varies between SSH, SFTP or web based)<br />
*<br />
<br />
==Secure hosting setups==<br />
Depending on available skill level the following secure system setups are possible:<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===Dedicated Server===<br />
For a [[Dedicated_Hosting | Dedicated Hosting]] system, the user can either run their own physical hardware or rent this hardware from a provider. The former solution offers total control of the physical hardware, however, there are significant downsides to this approach and should be avoided; it is only recommend under special circumstances such as [[Sensitive_Data | storing sensitive data]]. In the latter case, the hosting agent provides the hardware but the user has total control of the server via remote access. In this scenario, the provider is responsible for replacement of hardware parts that fail or malfunction - this support is generally done through a ticket system and relies on the user to report errors.<br />
<br />
'''Examples'''<br />
* http://www.ovh.com/ca/en/dedicated-servers/hosting/<br />
* http://www.soyoustart.com/ie/offers.xml<br />
* http://www.hetzner.de/en/hosting/produktmatrix/rootserver<br />
* http://www.coolhousing.net/hosting-dedicated-servers.html<br />
<br />
'''Benefits'''<br />
*User has total control of the system's software<br />
*User has total control of access rights<br />
*User has control of physical network connection, allowing them to whitelist or block connection from allowed or spurious connections<br />
*Financial cost of hardware malfunction is not an issue as the host is responsible for replacing/repairing failing hardware<br />
*The host can be chosen to place the server in a different jurisdiction from that of the user to prevent seizure<br />
<br />
'''Downsides'''<br />
*The user does not have physical access to the server<br />
*The host is not responsible for data loss or downtime if the physical server fails<br />
*The user is responsible for detecting and reporting hardware faults on some providers<br />
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].<br />
*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.<br />
<br />
===VPS===<br />
A Virtual Private Server(VPS) is an instance of a Virtual Operating System running on a much larger server. Typically multiple VPS will be run on a single server. In a VPS environment, you have a dedicated virtual private server but do not control the server on which it is hosted. Resources will be limited, you can not control or harden the outer server.<br />
<br />
'''Examples'''<br />
* https://www.linode.com/pricing<br />
* https://chhost.net/virtual-server/<br />
* https://www.tilaa.com/orders/add<br />
<br />
'''Benefits'''<br />
*The cost of this type of server will typically be significantly cheaper than a dedicated server<br />
*Depending on the host, the server will be capable of running most standard server software, up to a certain limit<br />
*Hardware is managed by the hosting provider unless self hosting<br />
*If self hosting, a single server can be used for multiple purposes and to provide multiple distinct servers<br />
<br />
'''Downsides'''<br />
*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<br />
*Bandwidth will also be restricted<br />
*Potential risk of provider, law enforcement or other state forces accessing contents of virtual server without user's awareness. <br />
*The user will not have access to the outer server and will thus not be able to harden it<br />
<br />
===Threats===<br />
*Social engineering attack<br />
*Password brute force<br />
*Service interruption through denial of service attack<br />
*System software exploits<br />
*SSL man-in-the-middle attacks<br />
*Data loss or data theft<br />
<br />
===Mitigation===<br />
'''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.<br />
<ol><br />
<li><br />
Enforce strong password - a strong password should contain Upper and Lower case characters, Numbers and Special Characters and should be long; greater than 20 characters. It is also possible to restrict the use of previously used passwords. On Linux systems the following command can be used to force complex passwords for users:<br />
</li><br />
password required pam_cracklib.so minlen=12 lcredit=1 ucredit=1 dcredit=2 ocredit=1<br />
<br />
For more detail, refer to the guide [http://www.linux-faqs.info/security/force-strong-passwords| Force strong passwords]<br />
<li><br />
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].<br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
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]<br />
</li><br />
</ol><br />
'''User Management''' on dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<ol><br />
<li><br />
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.<br />
</li><br />
<li><br />
Secure Shell(SSH) login should be forced, telnet and ftp login access should be disabled by default. To upload files to the server securely user can use Secure FTP(SFTP) clients. <br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
File permissions should be restricted for critical files. User should only be allowed access to files relevant to their work. Execution as root should be restricted. Discussion of [http://www.linux.com/learn/tutorials/309527-understanding-linux-file-permissions| linux file permissions].<br />
</li><br />
</ol><br />
'''Software Management'''<br />
<ol><br />
<li><br />
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].<br />
</li><br />
<li><br />
Minimising installed software is an important step in reducing potential vulnerabilities. The system should have the bare minimum of packages and software installed to support its purpose.<br />
</li><br />
</ol><br />
'''System Management'''<br />
<ol><br />
<li><br />
Firewall, iptables<br />
</li><br />
<li><br />
Check listening ports<br />
</li><br />
<li><br />
Logging and Auditing<br />
</li><br />
<li><br />
Anti-intrusion system,<br />
</li><br />
<li><br />
SELinux<br />
</li><br />
<li><br />
fail2ban<br />
</li><br />
</ol><br />
<ul><br />
'''Apache hardening'''<br />
<br />
As well as considering the physical server and it's operating system users must thinking in terms of application security. Especially for those applications which either contain sensitive data or those that provide access routes to the machine for an attacker.<br />
<br />
Below is a set of guides for Apache webserver hardening.<br />
<li><br />
[http://www.tecmint.com/apache-security-tips/| 13 Apache Web Server Security and Hardening Tips]<br />
<li><br />
[http://xianshield.org/guides/apache2.0guide.html| Apache 2.0 Hardening Guide]<br />
</li><br />
</ul><br />
<ul><br />
'''Database hardening'''<br />
<br />
A key approach discussed elsewhere in protecting data, both at rest - on disk - and in use - in memory, is to encrypt these data stores either as part of full disk encryption or as individual restricted encrypted mount points.<br />
<br />
Below are further guides for specific hardening techniques for the MySQL database system.<br />
<li><br />
[http://www.greensql.com/content/mysql-security-best-practices-hardening-mysql-tips| MySQL Security Best Practices]<br />
</li><br />
<li><br />
[http://rochakchauhan.com/blog/2013/11/19/security-and-hardening-tips-for-mysql/| Security and Hardening Tips for MySQL]<br />
</li><br />
<li><br />
[http://www.securethelock.com/2014/01/09/12-steps-for-hardening-mysql-from-attackers/| 12 steps for Hardening MySQL from Attackers]<br />
</li><br />
</ul><br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted platform===<br />
For organisation that wish to setup their own custom site based on an existing platform such as Wordpress.com, there are a setup of steps that should be taken to ensure a good level of security. The [[Choosing_A_Host | choosing a hosting provider]] guide should also be consulted.<br />
<br />
'''Platform Security'''<br />
<ol><br />
<li><br />
Limiting access - Making smart choices that reduce possible entry points available to a malicious person.<br />
</li><br />
<li>Containment - Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.<br />
</li><br />
<li>Preparation and knowledge - Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.<br />
</li><br />
<li><br />
Passwords<br />
</li><br />
<li><br />
File Permissions<br />
</li><br />
<li><br />
Admin user<br />
</li><br />
<li><br />
SSL<br />
</li><br />
<li><br />
SFTP client<br />
</li><br />
<li><br />
Platform updates<br />
</li><br />
</ol><br />
Hosting install of pre-built software platform, such as Wordpress,<br />
<br />
===Shared Hosting===<br />
In a [[Shared_Hosting|Shared Hosting]] environment, your and other website owners shared one server. This includes sharing the physical server and the software applications within the server. Shared hosting services are affordable because the cost to operate the server is shared between you and these other owners. There are, however, a number of down sides, such as being slower.<br />
<br />
'''Examples:'''<br />
* http://www.easyweb.com<br />
* http://www.dreamhost.com/web-hosting/<br />
* http://wpengine.com/ (wordpress only)<br />
<br />
===Threat Mitigation===<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
For a basic setup providing a content distribution platform such as a blog user's have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
===Threat Mitigation===<br />
strong passwords, 2 factor auth,<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''Dedicated Server'''<br />
| style="padding: 5px;"| '''Virtual Private Server'''<br />
| style="padding: 5px;"| '''Shared Hosting'''<br />
| style="padding: 5px;"| '''Cloud Service'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Requires Intermediary technical skill<br />
| style="padding: 5px;"| Intermediary/Basic<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows disk/data encryption<br />
| style="padding: 5px;"| Allows encryption within VPS<br />
| style="padding: 5px;"| Limited or no control of data encryption<br />
| style="padding: 5px;"| Depends on provider but usually not provided<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| SSH and private key login<br />
| style="padding: 5px;"| Enforce secure login for VPS<br />
| style="padding: 5px;"| Login via CPanel or Custom interface - some hosts offer 2 factor auth<br />
| style="padding: 5px;"| Depends<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| User access control and restriction<br />
| style="padding: 5px;"| User control<br />
| style="padding: 5px;"| Control via user accounts added through management software<br />
| style="padding: 5px;"| Control via management software<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| Allows only shared SSL cert, most host provide shared cert<br />
| style="padding: 5px;"| Most host platforms will provide SSL support by default<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Total control of applications and software<br />
| style="padding: 5px;"| Control of software within VM, limited access to hardware depending on type of VM<br />
| style="padding: 5px;"| Application control only via management interface<br />
| style="padding: 5px;"| Depends on cloud server - certain services with provide data access restrictions but this is a non-ideal scenario<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Manually maintained and updated<br />
| style="padding: 5px;"| Server is patched but VPS remains responsibility of user<br />
| style="padding: 5px;"| Patches and updates provided by host - though may lag behind depending on quality of hosting<br />
| style="padding: 5px;"| Depending on scale of provider - patching and support will be provided to protect their reputation<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Limited supported - hardware support and replacement depending on provider<br />
| style="padding: 5px;"| Similar to dedicated support<br />
| style="padding: 5px;"| Support is generally in terms of management software - hardware is automatically monitored by hosts<br />
| style="padding: 5px;"| Similar to shared though support is specific to the platform hosting<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Anti-ddos and brute forcing via fail2ban, botnetdbp deployment<br />
| style="padding: 5px;"| Provider may or may not mitigate DDoS attacks<br />
| style="padding: 5px;"| DDoS attacks will receive some or limited mitigation depending on quality of host, generally they will not protect against large scale attacks and may force the website to be removed<br />
| style="padding: 5px;"| Depending on the provider if the attack crosses their threshold for protection they may shut down the website or ask it to leave<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/Choose_a_hosting_providerChoose a hosting provider2014-05-18T19:42:22Z<p>Bill: </p>
<hr />
<div>__NOTOC__<br />
===Criteria===<br />
*Price - relative services offered<br />
*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.<br />
*Specialisation - do they work in the field of human rights, software applications or general hosting<br />
*Is mail provided<br />
*Hardware specifications<br />
*Operating systems offered<br />
*Supported provided<br />
*Readily discusses your security concerns and which security features and processes they offer with their hosting.<br />
*Provides the most recent stable versions of all server software.<br />
*Provides reliable methods for backup and recovery.<br />
*Provides encryption options for hosting of sites or mail<br />
<br />
==Secure hosting setups==<br />
Depending on available skill level the following secure system setups are possible:<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===Dedicated Server===<br />
For a [[Dedicated_Hosting | Dedicated Hosting]] system, the user can either run their own physical hardware or rent this hardware from a provider. The former solution offers total control of the physical hardware, however, there are significant downsides to this approach and should be avoided; it is only recommend under special circumstances such as [[Sensitive_Data | storing sensitive data]]. In the latter case, the hosting agent provides the hardware but the user has total control of the server via remote access. In this scenario, the provider is responsible for replacement of hardware parts that fail or malfunction - this support is generally done through a ticket system and relies on the user to report errors.<br />
<br />
'''Benefits'''<br />
*User has total control of the system's software<br />
*User has total control of access rights<br />
*User has control of physical network connection, allowing them to whitelist or block connection from allowed or spurious connections<br />
*Financial cost of hardware malfunction is not an issue as the host is responsible for replacing/repairing failing hardware<br />
*The host can be chosen to place the server in a different jurisdiction from that of the user to prevent seizure<br />
<br />
'''Downsides'''<br />
*The user does not have physical access to the server<br />
*The host is not responsible for data loss or downtime if the physical server fails<br />
*The user is responsible for detecting and reporting hardware faults on some providers<br />
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].<br />
*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.<br />
<br />
===VPS===<br />
A Virtual Private Server(VPS) is an instance of a Virtual Operating System running on a much larger server. Typically multiple VPS will be run on a single server. In a VPS environment, you have a dedicated virtual private server but do not control the server on which it is hosted. Resources will be limited, you can not control or harden the outer server.<br />
<br />
'''Benefits'''<br />
*The cost of this type of server will typically be significantly cheaper than a dedicated server<br />
*Depending on the host, the server will be capable of running most standard server software, up to a certain limit<br />
*Hardware is managed by the hosting provider unless self hosting<br />
*If self hosting, a single server can be used for multiple purposes and to provide multiple distinct servers<br />
<br />
'''Downsides'''<br />
*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<br />
*Bandwidth will also be restricted<br />
*Potential risk of provider, law enforcement or other state forces accessing contents of virtual server without user's awareness. <br />
*The user will not have access to the outer server and will thus not be able to harden it<br />
<br />
===Threats===<br />
*Social engineering attack<br />
*Password brute force<br />
*Service interruption through denial of service attack<br />
*System software exploits<br />
*SSL man-in-the-middle attacks<br />
*Data loss or data theft<br />
<br />
===Mitigation===<br />
'''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.<br />
<ol><br />
<li><br />
Enforce strong password - a strong password should contain Upper and Lower case characters, Numbers and Special Characters and should be long; greater than 20 characters. It is also possible to restrict the use of previously used passwords. On Linux systems the following command can be used to force complex passwords for users:<br />
</li><br />
password required pam_cracklib.so minlen=12 lcredit=1 ucredit=1 dcredit=2 ocredit=1<br />
<br />
For more detail, refer to the guide [http://www.linux-faqs.info/security/force-strong-passwords| Force strong passwords]<br />
<li><br />
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].<br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
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]<br />
</li><br />
</ol><br />
'''User Management''' on dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<ol><br />
<li><br />
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.<br />
</li><br />
<li><br />
Secure Shell(SSH) login should be forced, telnet and ftp login access should be disabled by default. To upload files to the server securely user can use Secure FTP(SFTP) clients. <br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
File permissions should be restricted for critical files. User should only be allowed access to files relevant to their work. Execution as root should be restricted. Discussion of [http://www.linux.com/learn/tutorials/309527-understanding-linux-file-permissions| linux file permissions].<br />
</li><br />
</ol><br />
'''Software Management'''<br />
<ol><br />
<li><br />
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].<br />
</li><br />
<li><br />
Minimising installed software is an important step in reducing potential vulnerabilities. The system should have the bare minimum of packages and software installed to support its purpose.<br />
</li><br />
</ol><br />
'''System Management'''<br />
<ol><br />
<li><br />
Firewall, iptables<br />
</li><br />
<li><br />
Check listening ports<br />
</li><br />
<li><br />
Logging and Auditing<br />
</li><br />
<li><br />
Anti-intrusion system,<br />
</li><br />
<li><br />
SELinux<br />
</li><br />
<li><br />
fail2ban<br />
</li><br />
</ol><br />
<ul><br />
'''Apache hardening'''<br />
<br />
As well as considering the physical server and it's operating system users must thinking in terms of application security. Especially for those applications which either contain sensitive data or those that provide access routes to the machine for an attacker.<br />
<br />
Below is a set of guides for Apache webserver hardening.<br />
<li><br />
[http://www.tecmint.com/apache-security-tips/| 13 Apache Web Server Security and Hardening Tips]<br />
<li><br />
[http://xianshield.org/guides/apache2.0guide.html| Apache 2.0 Hardening Guide]<br />
</li><br />
</ul><br />
<ul><br />
'''Database hardening'''<br />
<br />
A key approach discussed elsewhere in protecting data, both at rest - on disk - and in use - in memory, is to encrypt these data stores either as part of full disk encryption or as individual restricted encrypted mount points.<br />
<br />
Below are further guides for specific hardening techniques for the MySQL database system.<br />
<li><br />
[http://www.greensql.com/content/mysql-security-best-practices-hardening-mysql-tips| MySQL Security Best Practices]<br />
</li><br />
<li><br />
[http://rochakchauhan.com/blog/2013/11/19/security-and-hardening-tips-for-mysql/| Security and Hardening Tips for MySQL]<br />
</li><br />
<li><br />
[http://www.securethelock.com/2014/01/09/12-steps-for-hardening-mysql-from-attackers/| 12 steps for Hardening MySQL from Attackers]<br />
</li><br />
</ul><br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted platform===<br />
For organisation that wish to setup their own custom site based on an existing platform such as Wordpress.com, there are a setup of steps that should be taken to ensure a good level of security. The [[Choosing_A_Host | choosing a hosting provider]] guide should also be consulted.<br />
<br />
'''Platform Security'''<br />
<ol><br />
<li><br />
Limiting access - Making smart choices that reduce possible entry points available to a malicious person.<br />
</li><br />
<li>Containment - Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.<br />
</li><br />
<li>Preparation and knowledge - Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.<br />
</li><br />
<li><br />
Passwords<br />
</li><br />
<li><br />
File Permissions<br />
</li><br />
<li><br />
Admin user<br />
</li><br />
<li><br />
SSL<br />
</li><br />
<li><br />
SFTP client<br />
</li><br />
<li><br />
Platform updates<br />
</li><br />
</ol><br />
Hosting install of pre-built software platform, such as Wordpress,<br />
<br />
===Shared Hosting===<br />
In a [[Shared_Hosting|Shared Hosting]] environment, your and other website owners shared one server. This includes sharing the physical server and the software applications within the server. Shared hosting services are affordable because the cost to operate the server is shared between you and these other owners. There are, however, a number of down sides, such as being slower.<br />
<br />
<br />
===Threat Mitigation===<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
For a basic setup providing a content distribution platform such as a blog user's have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
===Threat Mitigation===<br />
strong passwords, 2 factor auth,<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''Dedicated Server'''<br />
| style="padding: 5px;"| '''Virtual Private Server'''<br />
| style="padding: 5px;"| '''Shared Hosting'''<br />
| style="padding: 5px;"| '''Cloud Service'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Requires Intermediary technical skill<br />
| style="padding: 5px;"| Intermediary/Basic<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows disk/data encryption<br />
| style="padding: 5px;"| Allows encryption within VPS<br />
| style="padding: 5px;"| Limited or no control of data encryption<br />
| style="padding: 5px;"| Depends on provider but usually not provided<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| SSH and private key login<br />
| style="padding: 5px;"| Enforce secure login for VPS<br />
| style="padding: 5px;"| Login via CPanel or Custom interface - some hosts offer 2 factor auth<br />
| style="padding: 5px;"| Depends<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| User access control and restriction<br />
| style="padding: 5px;"| User control<br />
| style="padding: 5px;"| Control via user accounts added through management software<br />
| style="padding: 5px;"| Control via management software<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| Allows only shared SSL cert, most host provide shared cert<br />
| style="padding: 5px;"| Most host platforms will provide SSL support by default<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Total control of applications and software<br />
| style="padding: 5px;"| Control of software within VM, limited access to hardware depending on type of VM<br />
| style="padding: 5px;"| Application control only via management interface<br />
| style="padding: 5px;"| Depends on cloud server - certain services with provide data access restrictions but this is a non-ideal scenario<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Manually maintained and updated<br />
| style="padding: 5px;"| Server is patched but VPS remains responsibility of user<br />
| style="padding: 5px;"| Patches and updates provided by host - though may lag behind depending on quality of hosting<br />
| style="padding: 5px;"| Depending on scale of provider - patching and support will be provided to protect their reputation<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Limited supported - hardware support and replacement depending on provider<br />
| style="padding: 5px;"| Similar to dedicated support<br />
| style="padding: 5px;"| Support is generally in terms of management software - hardware is automatically monitored by hosts<br />
| style="padding: 5px;"| Similar to shared though support is specific to the platform hosting<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Anti-ddos and brute forcing via fail2ban, botnetdbp deployment<br />
| style="padding: 5px;"| Provider may or may not mitigate DDoS attacks<br />
| style="padding: 5px;"| DDoS attacks will receive some or limited mitigation depending on quality of host, generally they will not protect against large scale attacks and may force the website to be removed<br />
| style="padding: 5px;"| Depending on the provider if the attack crosses their threshold for protection they may shut down the website or ask it to leave<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/Choose_a_hosting_providerChoose a hosting provider2014-05-18T19:41:39Z<p>Bill: /* High Technical */</p>
<hr />
<div>__NOTOC__<br />
===Criteria===<br />
*Price - relative services offered<br />
*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.<br />
*Specialisation - do they work in the field of human rights, software applications or general hosting<br />
*Is mail provided<br />
*Hardware specifications<br />
*Operating systems offered<br />
*Supported provided<br />
*Readily discusses your security concerns and which security features and processes they offer with their hosting.<br />
*Provides the most recent stable versions of all server software.<br />
*Provides reliable methods for backup and recovery.<br />
*Provides encryption options for hosting of sites or mail<br />
<br />
==Secure hosting setups==<br />
Depending on available skill level the following secure system setups are possible:<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===Dedicated Server===<br />
For a [[Dedicated_Hosting | Dedicated Hosting]] system, the user can either run their own physical hardware or rent this hardware from a provider. The former solution offers total control of the physical hardware, however, there are significant downsides to this approach and should be avoided; it is only recommend under special circumstances such as [[Sensitive_Data | storing sensitive data]]. In the latter case, the hosting agent provides the hardware but the user has total control of the server via remote access. In this scenario, the provider is responsible for replacement of hardware parts that fail or malfunction - this support is generally done through a ticket system and relies on the user to report errors.<br />
<br />
'''Benefits'''<br />
*User has total control of the system's software<br />
*User has total control of access rights<br />
*User has control of physical network connection, allowing them to whitelist or block connection from allowed or spurious connections<br />
*Financial cost of hardware malfunction is not an issue as the host is responsible for replacing/repairing failing hardware<br />
*The host can be chosen to place the server in a different jurisdiction from that of the user to prevent seizure<br />
<br />
'''Downsides'''<br />
*The user does not have physical access to the server<br />
*The host is not responsible for data loss or downtime if the physical server fails<br />
*The user is responsible for detecting and reporting hardware faults on some providers<br />
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].<br />
*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.<br />
<br />
===VPS===<br />
A Virtual Private Server(VPS) is an instance of a Virtual Operating System running on a much larger server. Typically multiple VPS will be run on a single server. In a VPS environment, you have a dedicated virtual private server but do not control the server on which it is hosted. Resources will be limited, you can not control or harden the outer server.<br />
<br />
'''Benefits'''<br />
*The cost of this type of server will typically be significantly cheaper than a dedicated server<br />
*Depending on the host, the server will be capable of running most standard server software, up to a certain limit<br />
*Hardware is managed by the hosting provider unless self hosting<br />
*If self hosting, a single server can be used for multiple purposes and to provide multiple distinct servers<br />
<br />
'''Downsides'''<br />
*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<br />
*Bandwidth will also be restricted<br />
*Potential risk of provider, law enforcement or other state forces accessing contents of virtual server without user's awareness. <br />
*The user will not have access to the outer server and will thus not be able to harden it<br />
<br />
===Threats===<br />
*Social engineering attack<br />
*Password brute force<br />
*Service interruption through denial of service attack<br />
*System software exploits<br />
*SSL man-in-the-middle attacks<br />
*Data loss or data theft<br />
<br />
===Mitigation===<br />
'''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.<br />
<ol><br />
<li><br />
Enforce strong password - a strong password should contain Upper and Lower case characters, Numbers and Special Characters and should be long; greater than 20 characters. It is also possible to restrict the use of previously used passwords. On Linux systems the following command can be used to force complex passwords for users:<br />
</li><br />
password required pam_cracklib.so minlen=12 lcredit=1 ucredit=1 dcredit=2 ocredit=1<br />
<br />
For more detail, refer to the guide [http://www.linux-faqs.info/security/force-strong-passwords| Force strong passwords]<br />
<li><br />
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].<br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
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]<br />
</li><br />
</ol><br />
'''User Management''' on dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<ol><br />
<li><br />
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.<br />
</li><br />
<li><br />
Secure Shell(SSH) login should be forced, telnet and ftp login access should be disabled by default. To upload files to the server securely user can use Secure FTP(SFTP) clients. <br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
File permissions should be restricted for critical files. User should only be allowed access to files relevant to their work. Execution as root should be restricted. Discussion of [http://www.linux.com/learn/tutorials/309527-understanding-linux-file-permissions| linux file permissions].<br />
</li><br />
</ol><br />
'''Software Management'''<br />
<ol><br />
<li><br />
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].<br />
</li><br />
<li><br />
Minimising installed software is an important step in reducing potential vulnerabilities. The system should have the bare minimum of packages and software installed to support its purpose.<br />
</li><br />
</ol><br />
'''System Management'''<br />
<ol><br />
<li><br />
Firewall, iptables<br />
</li><br />
<li><br />
Check listening ports<br />
</li><br />
<li><br />
Logging and Auditing<br />
</li><br />
<li><br />
Anti-intrusion system,<br />
</li><br />
<li><br />
SELinux<br />
</li><br />
<li><br />
fail2ban<br />
</li><br />
</ol><br />
<ul><br />
'''Apache hardening'''<br />
<br />
As well as considering the physical server and it's operating system users must thinking in terms of application security. Especially for those applications which either contain sensitive data or those that provide access routes to the machine for an attacker.<br />
<br />
Below is a set of guides for Apache webserver hardening.<br />
<li><br />
[http://www.tecmint.com/apache-security-tips/| 13 Apache Web Server Security and Hardening Tips]<br />
<li><br />
[http://xianshield.org/guides/apache2.0guide.html| Apache 2.0 Hardening Guide]<br />
</li><br />
</ul><br />
<ul><br />
'''Database hardening'''<br />
<br />
A key approach discussed elsewhere in protecting data, both at rest - on disk - and in use - in memory, is to encrypt these data stores either as part of full disk encryption or as individual restricted encrypted mount points.<br />
<br />
Below are further guides for specific hardening techniques for the MySQL database system.<br />
<li><br />
[http://www.greensql.com/content/mysql-security-best-practices-hardening-mysql-tips| MySQL Security Best Practices]<br />
</li><br />
<li><br />
[http://rochakchauhan.com/blog/2013/11/19/security-and-hardening-tips-for-mysql/| Security and Hardening Tips for MySQL]<br />
</li><br />
<li><br />
[http://www.securethelock.com/2014/01/09/12-steps-for-hardening-mysql-from-attackers/| 12 steps for Hardening MySQL from Attackers]<br />
</li><br />
</ol><br />
<ul><br />
'''Web app'''<br />
<li><br />
</li><br />
</ol><br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted platform===<br />
For organisation that wish to setup their own custom site based on an existing platform such as Wordpress.com, there are a setup of steps that should be taken to ensure a good level of security. The [[Choosing_A_Host | choosing a hosting provider]] guide should also be consulted.<br />
<br />
'''Platform Security'''<br />
<ol><br />
<li><br />
Limiting access - Making smart choices that reduce possible entry points available to a malicious person.<br />
</li><br />
<li>Containment - Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.<br />
</li><br />
<li>Preparation and knowledge - Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.<br />
</li><br />
<li><br />
Passwords<br />
</li><br />
<li><br />
File Permissions<br />
</li><br />
<li><br />
Admin user<br />
</li><br />
<li><br />
SSL<br />
</li><br />
<li><br />
SFTP client<br />
</li><br />
<li><br />
Platform updates<br />
</li><br />
</ol><br />
Hosting install of pre-built software platform, such as Wordpress,<br />
<br />
===Shared Hosting===<br />
In a [[Shared_Hosting|Shared Hosting]] environment, your and other website owners shared one server. This includes sharing the physical server and the software applications within the server. Shared hosting services are affordable because the cost to operate the server is shared between you and these other owners. There are, however, a number of down sides, such as being slower.<br />
<br />
<br />
===Threat Mitigation===<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
For a basic setup providing a content distribution platform such as a blog user's have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
===Threat Mitigation===<br />
strong passwords, 2 factor auth,<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''Dedicated Server'''<br />
| style="padding: 5px;"| '''Virtual Private Server'''<br />
| style="padding: 5px;"| '''Shared Hosting'''<br />
| style="padding: 5px;"| '''Cloud Service'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Requires Intermediary technical skill<br />
| style="padding: 5px;"| Intermediary/Basic<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows disk/data encryption<br />
| style="padding: 5px;"| Allows encryption within VPS<br />
| style="padding: 5px;"| Limited or no control of data encryption<br />
| style="padding: 5px;"| Depends on provider but usually not provided<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| SSH and private key login<br />
| style="padding: 5px;"| Enforce secure login for VPS<br />
| style="padding: 5px;"| Login via CPanel or Custom interface - some hosts offer 2 factor auth<br />
| style="padding: 5px;"| Depends<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| User access control and restriction<br />
| style="padding: 5px;"| User control<br />
| style="padding: 5px;"| Control via user accounts added through management software<br />
| style="padding: 5px;"| Control via management software<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| Allows only shared SSL cert, most host provide shared cert<br />
| style="padding: 5px;"| Most host platforms will provide SSL support by default<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Total control of applications and software<br />
| style="padding: 5px;"| Control of software within VM, limited access to hardware depending on type of VM<br />
| style="padding: 5px;"| Application control only via management interface<br />
| style="padding: 5px;"| Depends on cloud server - certain services with provide data access restrictions but this is a non-ideal scenario<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Manually maintained and updated<br />
| style="padding: 5px;"| Server is patched but VPS remains responsibility of user<br />
| style="padding: 5px;"| Patches and updates provided by host - though may lag behind depending on quality of hosting<br />
| style="padding: 5px;"| Depending on scale of provider - patching and support will be provided to protect their reputation<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Limited supported - hardware support and replacement depending on provider<br />
| style="padding: 5px;"| Similar to dedicated support<br />
| style="padding: 5px;"| Support is generally in terms of management software - hardware is automatically monitored by hosts<br />
| style="padding: 5px;"| Similar to shared though support is specific to the platform hosting<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Anti-ddos and brute forcing via fail2ban, botnetdbp deployment<br />
| style="padding: 5px;"| Provider may or may not mitigate DDoS attacks<br />
| style="padding: 5px;"| DDoS attacks will receive some or limited mitigation depending on quality of host, generally they will not protect against large scale attacks and may force the website to be removed<br />
| style="padding: 5px;"| Depending on the provider if the attack crosses their threshold for protection they may shut down the website or ask it to leave<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/Choose_a_hosting_providerChoose a hosting provider2014-05-18T19:37:38Z<p>Bill: /* High Technical */</p>
<hr />
<div>__NOTOC__<br />
===Criteria===<br />
*Price - relative services offered<br />
*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.<br />
*Specialisation - do they work in the field of human rights, software applications or general hosting<br />
*Is mail provided<br />
*Hardware specifications<br />
*Operating systems offered<br />
*Supported provided<br />
*Readily discusses your security concerns and which security features and processes they offer with their hosting.<br />
*Provides the most recent stable versions of all server software.<br />
*Provides reliable methods for backup and recovery.<br />
*Provides encryption options for hosting of sites or mail<br />
<br />
==Secure hosting setups==<br />
Depending on available skill level the following secure system setups are possible:<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===Dedicated Server===<br />
For a [[Dedicated_Hosting | Dedicated Hosting]] system, the user can either run their own physical hardware or rent this hardware from a provider. The former solution offers total control of the physical hardware, however, there are significant downsides to this approach and should be avoided; it is only recommend under special circumstances such as [[Sensitive_Data | storing sensitive data]]. In the latter case, the hosting agent provides the hardware but the user has total control of the server via remote access. In this scenario, the provider is responsible for replacement of hardware parts that fail or malfunction - this support is generally done through a ticket system and relies on the user to report errors.<br />
<br />
'''Benefits'''<br />
*User has total control of the system's software<br />
*User has total control of access rights<br />
*User has control of physical network connection, allowing them to whitelist or block connection from allowed or spurious connections<br />
*Financial cost of hardware malfunction is not an issue as the host is responsible for replacing/repairing failing hardware<br />
*The host can be chosen to place the server in a different jurisdiction from that of the user to prevent seizure<br />
<br />
'''Downsides'''<br />
*The user does not have physical access to the server<br />
*The host is not responsible for data loss or downtime if the physical server fails<br />
*The user is responsible for detecting and reporting hardware faults on some providers<br />
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].<br />
*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.<br />
<br />
===VPS===<br />
A Virtual Private Server(VPS) is an instance of a Virtual Operating System running on a much larger server. Typically multiple VPS will be run on a single server. In a VPS environment, you have a dedicated virtual private server but do not control the server on which it is hosted. Resources will be limited, you can not control or harden the outer server.<br />
<br />
'''Benefits'''<br />
*The cost of this type of server will typically be significantly cheaper than a dedicated server<br />
*Depending on the host, the server will be capable of running most standard server software, up to a certain limit<br />
*Hardware is managed by the hosting provider unless self hosting<br />
*If self hosting, a single server can be used for multiple purposes and to provide multiple distinct servers<br />
<br />
'''Downsides'''<br />
*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<br />
*Bandwidth will also be restricted<br />
*Potential risk of provider, law enforcement or other state forces accessing contents of virtual server without user's awareness. <br />
*The user will not have access to the outer server and will thus not be able to harden it<br />
<br />
===Threats===<br />
*Social engineering attack<br />
*Password brute force<br />
*Service interruption through denial of service attack<br />
*System software exploits<br />
*SSL man-in-the-middle attacks<br />
*Data loss or data theft<br />
<br />
===Mitigation===<br />
'''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.<br />
<ol><br />
<li><br />
Enforce strong password - a strong password should contain Upper and Lower case characters, Numbers and Special Characters and should be long; greater than 20 characters. It is also possible to restrict the use of previously used passwords. On Linux systems the following command can be used to force complex passwords for users:<br />
</li><br />
password required pam_cracklib.so minlen=12 lcredit=1 ucredit=1 dcredit=2 ocredit=1<br />
<br />
For more detail, refer to the guide [http://www.linux-faqs.info/security/force-strong-passwords| Force strong passwords]<br />
<li><br />
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].<br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
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]<br />
</li><br />
</ol><br />
'''User Management''' on dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<ol><br />
<li><br />
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.<br />
</li><br />
<li><br />
Secure Shell(SSH) login should be forced, telnet and ftp login access should be disabled by default. To upload files to the server securely user can use Secure FTP(SFTP) clients. <br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
File permissions should be restricted for critical files. User should only be allowed access to files relevant to their work. Execution as root should be restricted. Discussion of [http://www.linux.com/learn/tutorials/309527-understanding-linux-file-permissions| linux file permissions].<br />
</li><br />
</ol><br />
'''Software Management'''<br />
<ol><br />
<li><br />
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].<br />
</li><br />
<li><br />
Minimising installed software is an important step in reducing potential vulnerabilities. The system should have the bare minimum of packages and software installed to support its purpose.<br />
</li><br />
</ol><br />
'''System Management'''<br />
<ol><br />
<li><br />
Firewall, iptables<br />
</li><br />
<li><br />
Check listening ports<br />
</li><br />
<li><br />
Logging and Auditing<br />
</li><br />
<li><br />
Anti-intrusion system,<br />
</li><br />
<li><br />
SELinux<br />
</li><br />
<li><br />
fail2ban<br />
</li><br />
</ol><br />
<ul><br />
'''Apache hardening'''<br />
<br />
As well as considering the physical server and it's operating system users must thinking in terms of application security. Especially for those applications which either contain sensitive data or those that provide access routes to the machine for an attacker.<br />
<br />
Below is a set of guides for Apache webserver hardening.<br />
<li><br />
[http://www.tecmint.com/apache-security-tips/| 13 Apache Web Server Security and Hardening Tips]<br />
<li><br />
[http://xianshield.org/guides/apache2.0guide.html| Apache 2.0 Hardening Guide]<br />
</li><br />
</ul><br />
<ol><br />
'''Database'''<br />
<li><br />
</li><br />
</ol><br />
<ol><br />
'''Web app'''<br />
<li><br />
</li><br />
</ol><br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted platform===<br />
For organisation that wish to setup their own custom site based on an existing platform such as Wordpress.com, there are a setup of steps that should be taken to ensure a good level of security. The [[Choosing_A_Host | choosing a hosting provider]] guide should also be consulted.<br />
<br />
'''Platform Security'''<br />
<ol><br />
<li><br />
Limiting access - Making smart choices that reduce possible entry points available to a malicious person.<br />
</li><br />
<li>Containment - Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.<br />
</li><br />
<li>Preparation and knowledge - Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.<br />
</li><br />
<li><br />
Passwords<br />
</li><br />
<li><br />
File Permissions<br />
</li><br />
<li><br />
Admin user<br />
</li><br />
<li><br />
SSL<br />
</li><br />
<li><br />
SFTP client<br />
</li><br />
<li><br />
Platform updates<br />
</li><br />
</ol><br />
Hosting install of pre-built software platform, such as Wordpress,<br />
<br />
===Shared Hosting===<br />
In a [[Shared_Hosting|Shared Hosting]] environment, your and other website owners shared one server. This includes sharing the physical server and the software applications within the server. Shared hosting services are affordable because the cost to operate the server is shared between you and these other owners. There are, however, a number of down sides, such as being slower.<br />
<br />
<br />
===Threat Mitigation===<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
For a basic setup providing a content distribution platform such as a blog user's have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
===Threat Mitigation===<br />
strong passwords, 2 factor auth,<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''Dedicated Server'''<br />
| style="padding: 5px;"| '''Virtual Private Server'''<br />
| style="padding: 5px;"| '''Shared Hosting'''<br />
| style="padding: 5px;"| '''Cloud Service'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Requires Intermediary technical skill<br />
| style="padding: 5px;"| Intermediary/Basic<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows disk/data encryption<br />
| style="padding: 5px;"| Allows encryption within VPS<br />
| style="padding: 5px;"| Limited or no control of data encryption<br />
| style="padding: 5px;"| Depends on provider but usually not provided<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| SSH and private key login<br />
| style="padding: 5px;"| Enforce secure login for VPS<br />
| style="padding: 5px;"| Login via CPanel or Custom interface - some hosts offer 2 factor auth<br />
| style="padding: 5px;"| Depends<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| User access control and restriction<br />
| style="padding: 5px;"| User control<br />
| style="padding: 5px;"| Control via user accounts added through management software<br />
| style="padding: 5px;"| Control via management software<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| Allows only shared SSL cert, most host provide shared cert<br />
| style="padding: 5px;"| Most host platforms will provide SSL support by default<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Total control of applications and software<br />
| style="padding: 5px;"| Control of software within VM, limited access to hardware depending on type of VM<br />
| style="padding: 5px;"| Application control only via management interface<br />
| style="padding: 5px;"| Depends on cloud server - certain services with provide data access restrictions but this is a non-ideal scenario<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Manually maintained and updated<br />
| style="padding: 5px;"| Server is patched but VPS remains responsibility of user<br />
| style="padding: 5px;"| Patches and updates provided by host - though may lag behind depending on quality of hosting<br />
| style="padding: 5px;"| Depending on scale of provider - patching and support will be provided to protect their reputation<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Limited supported - hardware support and replacement depending on provider<br />
| style="padding: 5px;"| Similar to dedicated support<br />
| style="padding: 5px;"| Support is generally in terms of management software - hardware is automatically monitored by hosts<br />
| style="padding: 5px;"| Similar to shared though support is specific to the platform hosting<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Anti-ddos and brute forcing via fail2ban, botnetdbp deployment<br />
| style="padding: 5px;"| Provider may or may not mitigate DDoS attacks<br />
| style="padding: 5px;"| DDoS attacks will receive some or limited mitigation depending on quality of host, generally they will not protect against large scale attacks and may force the website to be removed<br />
| style="padding: 5px;"| Depending on the provider if the attack crosses their threshold for protection they may shut down the website or ask it to leave<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/Choose_a_hosting_providerChoose a hosting provider2014-05-18T18:43:09Z<p>Bill: /* High Technical */</p>
<hr />
<div>__NOTOC__<br />
===Criteria===<br />
*Price - relative services offered<br />
*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.<br />
*Specialisation - do they work in the field of human rights, software applications or general hosting<br />
*Is mail provided<br />
*Hardware specifications<br />
*Operating systems offered<br />
*Supported provided<br />
*Readily discusses your security concerns and which security features and processes they offer with their hosting.<br />
*Provides the most recent stable versions of all server software.<br />
*Provides reliable methods for backup and recovery.<br />
*Provides encryption options for hosting of sites or mail<br />
<br />
==Secure hosting setups==<br />
Depending on available skill level the following secure system setups are possible:<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===Dedicated Server===<br />
For a [[Dedicated_Hosting | Dedicated Hosting]] system, the user can either run their own physical hardware or rent this hardware from a provider. The former solution offers total control of the physical hardware, however, there are significant downsides to this approach and should be avoided; it is only recommend under special circumstances such as [[Sensitive_Data | storing sensitive data]]. In the latter case, the hosting agent provides the hardware but the user has total control of the server via remote access. In this scenario, the provider is responsible for replacement of hardware parts that fail or malfunction - this support is generally done through a ticket system and relies on the user to report errors.<br />
<br />
'''Benefits'''<br />
*User has total control of the system's software<br />
*User has total control of access rights<br />
*User has control of physical network connection, allowing them to whitelist or block connection from allowed or spurious connections<br />
*Financial cost of hardware malfunction is not an issue as the host is responsible for replacing/repairing failing hardware<br />
*The host can be chosen to place the server in a different jurisdiction from that of the user to prevent seizure<br />
<br />
'''Downsides'''<br />
*The user does not have physical access to the server<br />
*The host is not responsible for data loss or downtime if the physical server fails<br />
*The user is responsible for detecting and reporting hardware faults on some providers<br />
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].<br />
*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.<br />
<br />
===VPS===<br />
A Virtual Private Server(VPS) is an instance of a Virtual Operating System running on a much larger server. Typically multiple VPS will be run on a single server. In a VPS environment, you have a dedicated virtual private server but do not control the server on which it is hosted. Resources will be limited, you can not control or harden the outer server.<br />
<br />
'''Benefits'''<br />
*The cost of this type of server will typically be significantly cheaper than a dedicated server<br />
*Depending on the host, the server will be capable of running most standard server software, up to a certain limit<br />
*Hardware is managed by the hosting provider unless self hosting<br />
*If self hosting, a single server can be used for multiple purposes and to provide multiple distinct servers<br />
<br />
'''Downsides'''<br />
*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<br />
*Bandwidth will also be restricted<br />
*Potential risk of provider, law enforcement or other state forces accessing contents of virtual server without user's awareness. <br />
*The user will not have access to the outer server and will thus not be able to harden it<br />
<br />
===Threats===<br />
*Social engineering attack<br />
*Password brute force<br />
*Service interruption through denial of service attack<br />
*System software exploits<br />
*SSL man-in-the-middle attacks<br />
*Data loss or data theft<br />
<br />
===Mitigation===<br />
'''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.<br />
<ol><br />
<li><br />
Enforce strong password - a strong password should contain Upper and Lower case characters, Numbers and Special Characters and should be long; greater than 20 characters. It is also possible to restrict the use of previously used passwords. On Linux systems the following command can be used to force complex passwords for users:<br />
</li><br />
password required pam_cracklib.so minlen=12 lcredit=1 ucredit=1 dcredit=2 ocredit=1<br />
<br />
For more detail, refer to the guide [http://www.linux-faqs.info/security/force-strong-passwords| Force strong passwords]<br />
<li><br />
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].<br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
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]<br />
</li><br />
</ol><br />
'''User Management''' on dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<ol><br />
<li><br />
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.<br />
</li><br />
<li><br />
Secure Shell(SSH) login should be forced, telnet and ftp login access should be disabled by default. To upload files to the server securely user can use Secure FTP(SFTP) clients. <br />
</li><br />
<li><br />
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. <br />
</li><br />
<li><br />
File permissions should be restricted for critical files. User should only be allowed access to files relevant to their work. Execution as root should be restricted. Discussion of [http://www.linux.com/learn/tutorials/309527-understanding-linux-file-permissions| linux file permissions].<br />
</li><br />
</ol><br />
'''Software Management'''<br />
<ol><br />
<li><br />
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].<br />
</li><br />
<li><br />
Minimising installed software is an important step in reducing potential vulnerabilities. The system should have the bare minimum of packages and software installed to support its purpose.<br />
</li><br />
</ol><br />
'''System Management'''<br />
<ol><br />
<li><br />
Firewall, iptables<br />
</li><br />
<li><br />
Check listening ports<br />
</li><br />
<li><br />
Logging and Auditing<br />
</li><br />
<li><br />
Anti-intrusion system,<br />
</li><br />
<li><br />
SELinux<br />
</li><br />
<li><br />
fail2ban<br />
</li><br />
</ol><br />
<ol><br />
'''Apache hardening'''<br />
<li><br />
</li><br />
</ol><br />
<ol><br />
'''Database'''<br />
<li><br />
</li><br />
</ol><br />
<ol><br />
'''Web app'''<br />
<li><br />
</li><br />
</ol><br />
<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted platform===<br />
For organisation that wish to setup their own custom site based on an existing platform such as Wordpress.com, there are a setup of steps that should be taken to ensure a good level of security. The [[Choosing_A_Host | choosing a hosting provider]] guide should also be consulted.<br />
<br />
'''Platform Security'''<br />
<ol><br />
<li><br />
Limiting access - Making smart choices that reduce possible entry points available to a malicious person.<br />
</li><br />
<li>Containment - Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.<br />
</li><br />
<li>Preparation and knowledge - Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.<br />
</li><br />
<li><br />
Passwords<br />
</li><br />
<li><br />
File Permissions<br />
</li><br />
<li><br />
Admin user<br />
</li><br />
<li><br />
SSL<br />
</li><br />
<li><br />
SFTP client<br />
</li><br />
<li><br />
Platform updates<br />
</li><br />
</ol><br />
Hosting install of pre-built software platform, such as Wordpress,<br />
<br />
===Shared Hosting===<br />
In a [[Shared_Hosting|Shared Hosting]] environment, your and other website owners shared one server. This includes sharing the physical server and the software applications within the server. Shared hosting services are affordable because the cost to operate the server is shared between you and these other owners. There are, however, a number of down sides, such as being slower.<br />
<br />
<br />
===Threat Mitigation===<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
For a basic setup providing a content distribution platform such as a blog user's have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
===Threat Mitigation===<br />
strong passwords, 2 factor auth,<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''Dedicated Server'''<br />
| style="padding: 5px;"| '''Virtual Private Server'''<br />
| style="padding: 5px;"| '''Shared Hosting'''<br />
| style="padding: 5px;"| '''Cloud Service'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Requires Intermediary technical skill<br />
| style="padding: 5px;"| Intermediary/Basic<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows disk/data encryption<br />
| style="padding: 5px;"| Allows encryption within VPS<br />
| style="padding: 5px;"| Limited or no control of data encryption<br />
| style="padding: 5px;"| Depends on provider but usually not provided<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| SSH and private key login<br />
| style="padding: 5px;"| Enforce secure login for VPS<br />
| style="padding: 5px;"| Login via CPanel or Custom interface - some hosts offer 2 factor auth<br />
| style="padding: 5px;"| Depends<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| User access control and restriction<br />
| style="padding: 5px;"| User control<br />
| style="padding: 5px;"| Control via user accounts added through management software<br />
| style="padding: 5px;"| Control via management software<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| Allows only shared SSL cert, most host provide shared cert<br />
| style="padding: 5px;"| Most host platforms will provide SSL support by default<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Total control of applications and software<br />
| style="padding: 5px;"| Control of software within VM, limited access to hardware depending on type of VM<br />
| style="padding: 5px;"| Application control only via management interface<br />
| style="padding: 5px;"| Depends on cloud server - certain services with provide data access restrictions but this is a non-ideal scenario<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Manually maintained and updated<br />
| style="padding: 5px;"| Server is patched but VPS remains responsibility of user<br />
| style="padding: 5px;"| Patches and updates provided by host - though may lag behind depending on quality of hosting<br />
| style="padding: 5px;"| Depending on scale of provider - patching and support will be provided to protect their reputation<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Limited supported - hardware support and replacement depending on provider<br />
| style="padding: 5px;"| Similar to dedicated support<br />
| style="padding: 5px;"| Support is generally in terms of management software - hardware is automatically monitored by hosts<br />
| style="padding: 5px;"| Similar to shared though support is specific to the platform hosting<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Anti-ddos and brute forcing via fail2ban, botnetdbp deployment<br />
| style="padding: 5px;"| Provider may or may not mitigate DDoS attacks<br />
| style="padding: 5px;"| DDoS attacks will receive some or limited mitigation depending on quality of host, generally they will not protect against large scale attacks and may force the website to be removed<br />
| style="padding: 5px;"| Depending on the provider if the attack crosses their threshold for protection they may shut down the website or ask it to leave<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/Choose_a_hosting_providerChoose a hosting provider2014-05-16T22:37:05Z<p>Bill: /* Mitigation */</p>
<hr />
<div>__NOTOC__<br />
===Criteria===<br />
*Price - relative services offered<br />
*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.<br />
*Specialisation - do they work in the field of human rights, software applications or general hosting<br />
*Is mail provided<br />
*Hardware specifications<br />
*Operating systems offered<br />
*Supported provided<br />
*Readily discusses your security concerns and which security features and processes they offer with their hosting.<br />
*Provides the most recent stable versions of all server software.<br />
*Provides reliable methods for backup and recovery.<br />
*Provides encryption options for hosting of sites or mail<br />
<br />
==Secure hosting setups==<br />
Depending on available skill level the following secure system setups are possible:<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===Dedicated Server===<br />
For a [[Dedicated_Hosting | Dedicated Hosting]] system, the user can either run their own physical hardware or rent this hardware from a provider. The former solution offers total control of the physical hardware, however, there are significant downsides to this approach and should be avoided; it is only recommend under special circumstances such as [[Sensitive_Data | storing sensitive data]]. In the latter case, the hosting agent provides the hardware but the user has total control of the server via remote access. In this scenario, the provider is responsible for replacement of hardware parts that fail or malfunction - this support is generally done through a ticket system and relies on the user to report errors.<br />
<br />
'''Benefits'''<br />
*User has total control of the system's software<br />
*User has total control of access rights<br />
*User has control of physical network connection, allowing them to whitelist or block connection from allowed or spurious connections<br />
*Financial cost of hardware malfunction is not an issue as the host is responsible for replacing/repairing failing hardware<br />
*The host can be chosen to place the server in a different jurisdiction from that of the user to prevent seizure<br />
<br />
'''Downsides'''<br />
*The user does not have physical access to the server<br />
*The host is not responsible for data loss or downtime if the physical server fails<br />
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].<br />
*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.<br />
<br />
===VPS===<br />
A Virtual Private Server(VPS) is an instance of a Virtual Operating System running on a much larger server. Typically multiple VPS will be run on a single server. In a VPS environment, you have a dedicated virtual private server but do not control the server on which it is hosted. Resources will be limited, you can not control or harden the outer server.<br />
<br />
'''Benefits'''<br />
*The cost of this type of server will typically be significantly cheaper than a dedicated server<br />
*Depending on the host, the server will be capable of running most standard server software, up to a certain limit<br />
*Hardware is managed by the hosting provider unless self hosting<br />
*If self hosting, a single server can be used for multiple purposes and to provide multiple distinct servers<br />
<br />
'''Downsides'''<br />
*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<br />
*Bandwidth will also be restricted<br />
*The user will not have access to the outer server and will thus not be able to harden it<br />
<br />
===Threats===<br />
*Social engineering attack<br />
*Password Bruteforce<br />
*Service interruption through Denial of Service attack<br />
*System software exploits<br />
*SSL spoofing<br />
*Data loss or data theft<br />
<br />
===Mitigation===<br />
'''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.<br />
<ol><br />
<li><br />
Enforce strong password - a strong password should contain Upper and Lower case characters, Numbers and Special Characters and should be long; greater than 20 characters. It is also possible to restrict the use of previously used passwords. On Linux systems the following command can be used to force complex passwords for users:<br />
</li><br />
password required pam_cracklib.so minlen=12 lcredit=1 ucredit=1 dcredit=2 ocredit=1<br />
<br />
For more detail, refer to the guide [http://www.linux-faqs.info/security/force-strong-passwords| Force strong passwords]<br />
<li><br />
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].<br />
</li><br />
<li><br />
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]<br />
</li><br />
<li><br />
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]<br />
</li><br />
</ol><br />
'''User Management''' on Dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<ol><br />
<li><br />
Root user login should be disabled by default<br />
</li><br />
<li><br />
Secure Shell(SSH) login should be forced, telnet and ftp login access should be disabled by default. To upload files to the server securely user can use Secure FTP(SFTP) clients. <br />
</li><br />
<li><br />
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]<br />
</li><br />
<li><br />
File permissions should be restricted for critical files. User should only be allowed access to files relevant to their work. Execution as root should be restricted. Discussion of [http://www.linux.com/learn/tutorials/309527-understanding-linux-file-permissions| linux file permissions].<br />
</li><br />
</ol><br />
'''Software Management'''<br />
<ol><br />
<li><br />
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].<br />
</li><br />
<li><br />
Minimising installed software is an important step in reducing potential vulnerabilities. The system should have the bare minimum of packages and software installed to support its purpose.<br />
</li><br />
</ol><br />
'''System Management'''<br />
<ol><br />
<li><br />
Firewall, iptables<br />
</li><br />
<li><br />
Check listening ports<br />
</li><br />
<li><br />
Logging and Auditing<br />
</li><br />
<li><br />
Anti-intrusion system,<br />
</li><br />
<li><br />
SELinux<br />
</li><br />
<li><br />
fail2ban<br />
</li><br />
</ol><br />
'''Apache'''<br />
'''Database'''<br />
'''Web app'''<br />
brief desc for these three with link to web app guide<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted platform===<br />
For organisation that wish to setup their own custom site based on an existing platform such as Wordpress.com, there are a setup of steps that should be taken to ensure a good level of security. The [[Choosing_A_Host | choosing a hosting provider]] guide should also be consulted.<br />
<br />
'''Platform Security'''<br />
<ol><br />
<li><br />
Limiting access - Making smart choices that reduce possible entry points available to a malicious person.<br />
</li><br />
<li>Containment - Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.<br />
</li><br />
<li>Preparation and knowledge - Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.<br />
</li><br />
<li><br />
Passwords<br />
</li><br />
<li><br />
File Permissions<br />
</li><br />
<li><br />
Admin user<br />
</li><br />
<li><br />
SSL<br />
</li><br />
<li><br />
SFTP client<br />
</li><br />
<li><br />
Platform updates<br />
</li><br />
</ol><br />
Hosting install of pre-built software platform, such as Wordpress,<br />
<br />
===Shared Hosting===<br />
In a [[Shared_Hosting|Shared Hosting]] environment, your and other website owners shared one server. This includes sharing the physical server and the software applications within the server. Shared hosting services are affordable because the cost to operate the server is shared between you and these other owners. There are, however, a number of down sides, such as being slower.<br />
<br />
<br />
===Threat Mitigation===<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
For a basic setup providing a content distribution platform such as a blog user's have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
===Threat Mitigation===<br />
strong passwords, 2 factor auth,<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''Dedicated Server'''<br />
| style="padding: 5px;"| '''Virtual Private Server'''<br />
| style="padding: 5px;"| '''Shared Hosting'''<br />
| style="padding: 5px;"| '''Cloud Service'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Requires Intermediary technical skill<br />
| style="padding: 5px;"| Intermediary/Basic<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows disk/data encryption<br />
| style="padding: 5px;"| Allows encryption within VPS<br />
| style="padding: 5px;"| Limited or no control of data encryption<br />
| style="padding: 5px;"| Depends on provider but usually not provided<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| SSH and private key login<br />
| style="padding: 5px;"| Enforce secure login for VPS<br />
| style="padding: 5px;"| Login via CPanel or Custom interface - some hosts offer 2 factor auth<br />
| style="padding: 5px;"| Depends<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| User access control and restriction<br />
| style="padding: 5px;"| User control<br />
| style="padding: 5px;"| Control via user accounts added through management software<br />
| style="padding: 5px;"| Control via management software<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| Allows only shared SSL cert, most host provide shared cert<br />
| style="padding: 5px;"| Most host platforms will provide SSL support by default<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Total control of applications and software<br />
| style="padding: 5px;"| Control of software within VM, limited access to hardware depending on type of VM<br />
| style="padding: 5px;"| Application control only via management interface<br />
| style="padding: 5px;"| Depends on cloud server - certain services with provide data access restrictions but this is a non-ideal scenario<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Manually maintained and updated<br />
| style="padding: 5px;"| Server is patched but VPS remains responsibility of user<br />
| style="padding: 5px;"| Patches and updates provided by host - though may lag behind depending on quality of hosting<br />
| style="padding: 5px;"| Depending on scale of provider - patching and support will be provided to protect their reputation<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Limited supported - hardware support and replacement depending on provider<br />
| style="padding: 5px;"| Similar to dedicated support<br />
| style="padding: 5px;"| Support is generally in terms of management software - hardware is automatically monitored by hosts<br />
| style="padding: 5px;"| Similar to shared though support is specific to the platform hosting<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Anti-ddos and brute forcing via fail2ban, botnetdbp deployment<br />
| style="padding: 5px;"| Provider may or may not mitigate DDoS attacks<br />
| style="padding: 5px;"| DDoS attacks will receive some or limited mitigation depending on quality of host, generally they will not protect against large scale attacks and may force the website to be removed<br />
| style="padding: 5px;"| Depending on the provider if the attack crosses their threshold for protection they may shut down the website or ask it to leave<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/Choose_a_hosting_providerChoose a hosting provider2014-05-16T22:36:10Z<p>Bill: /* Mitigation */</p>
<hr />
<div>__NOTOC__<br />
===Criteria===<br />
*Price - relative services offered<br />
*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.<br />
*Specialisation - do they work in the field of human rights, software applications or general hosting<br />
*Is mail provided<br />
*Hardware specifications<br />
*Operating systems offered<br />
*Supported provided<br />
*Readily discusses your security concerns and which security features and processes they offer with their hosting.<br />
*Provides the most recent stable versions of all server software.<br />
*Provides reliable methods for backup and recovery.<br />
*Provides encryption options for hosting of sites or mail<br />
<br />
==Secure hosting setups==<br />
Depending on available skill level the following secure system setups are possible:<br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==High Technical==<br />
<div class="mw-collapsible-content"><br />
===Dedicated Server===<br />
For a [[Dedicated_Hosting | Dedicated Hosting]] system, the user can either run their own physical hardware or rent this hardware from a provider. The former solution offers total control of the physical hardware, however, there are significant downsides to this approach and should be avoided; it is only recommend under special circumstances such as [[Sensitive_Data | storing sensitive data]]. In the latter case, the hosting agent provides the hardware but the user has total control of the server via remote access. In this scenario, the provider is responsible for replacement of hardware parts that fail or malfunction - this support is generally done through a ticket system and relies on the user to report errors.<br />
<br />
'''Benefits'''<br />
*User has total control of the system's software<br />
*User has total control of access rights<br />
*User has control of physical network connection, allowing them to whitelist or block connection from allowed or spurious connections<br />
*Financial cost of hardware malfunction is not an issue as the host is responsible for replacing/repairing failing hardware<br />
*The host can be chosen to place the server in a different jurisdiction from that of the user to prevent seizure<br />
<br />
'''Downsides'''<br />
*The user does not have physical access to the server<br />
*The host is not responsible for data loss or downtime if the physical server fails<br />
*The time taken to repair a hardware malfunction depends on the provider chosen. See [[Choosing_A_Host | Choosing a hosting provider]].<br />
*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.<br />
<br />
===VPS===<br />
A Virtual Private Server(VPS) is an instance of a Virtual Operating System running on a much larger server. Typically multiple VPS will be run on a single server. In a VPS environment, you have a dedicated virtual private server but do not control the server on which it is hosted. Resources will be limited, you can not control or harden the outer server.<br />
<br />
'''Benefits'''<br />
*The cost of this type of server will typically be significantly cheaper than a dedicated server<br />
*Depending on the host, the server will be capable of running most standard server software, up to a certain limit<br />
*Hardware is managed by the hosting provider unless self hosting<br />
*If self hosting, a single server can be used for multiple purposes and to provide multiple distinct servers<br />
<br />
'''Downsides'''<br />
*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<br />
*Bandwidth will also be restricted<br />
*The user will not have access to the outer server and will thus not be able to harden it<br />
<br />
===Threats===<br />
*Social engineering attack<br />
*Password Bruteforce<br />
*Service interruption through Denial of Service attack<br />
*System software exploits<br />
*SSL spoofing<br />
*Data loss or data theft<br />
<br />
===Mitigation===<br />
'''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.<br />
<ol><br />
<li><br />
Enforce strong password - a strong password should contain Upper and Lower case characters, Numbers and Special Characters and should be long; greater than 20 characters. It is also possible to restrict the use of previously used passwords. On Linux systems the following command can be used to force complex passwords for users:<br />
</li><br />
password required pam_cracklib.so minlen=12 lcredit=1 ucredit=1 dcredit=2 ocredit=1<br />
<br />
For more detail, refer to the guide [http://www.linux-faqs.info/security/force-strong-passwords| Force strong passwords]<br />
<li><br />
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].<br />
</li><br />
<li><br />
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]<br />
</li><br />
<li><br />
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]<br />
</li><br />
</ol><br />
'''User Management''' on Dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<ol><br />
<li><br />
Root user login should be disabled by default<br />
</li><br />
<li><br />
Secure Shell(SSH) login should be forced, telnet and ftp login access should be disabled by default. To upload files to the server securely user can use Secure FTP(SFTP) clients. <br />
</li><br />
<li><br />
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]<br />
</li><br />
<li><br />
File permissions<br />
</li><br />
</ol><br />
'''Software Management'''<br />
<ol><br />
<li><br />
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].<br />
</li><br />
<li><br />
Minimising installed software is an important step in reducing potential vulnerabilities. The system should have the bare minimum of packages and software installed to support its purpose.<br />
</li><br />
</ol><br />
'''System Management'''<br />
<ol><br />
<li><br />
Firewall, iptables<br />
</li><br />
<li><br />
Check listening ports<br />
</li><br />
<li><br />
Logging and Auditing<br />
</li><br />
<li><br />
Anti-intrusion system,<br />
</li><br />
<li><br />
SELinux<br />
</li><br />
<li><br />
fail2ban<br />
</li><br />
</ol><br />
'''Apache'''<br />
'''Database'''<br />
'''Web app'''<br />
brief desc for these three with link to web app guide<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Intermediary Technical==<br />
<div class="mw-collapsible-content"><br />
===Hosted platform===<br />
For organisation that wish to setup their own custom site based on an existing platform such as Wordpress.com, there are a setup of steps that should be taken to ensure a good level of security. The [[Choosing_A_Host | choosing a hosting provider]] guide should also be consulted.<br />
<br />
'''Platform Security'''<br />
<ol><br />
<li><br />
Limiting access - Making smart choices that reduce possible entry points available to a malicious person.<br />
</li><br />
<li>Containment - Your system should be configured to minimize the amount of damage that can be done in the event that it is compromised.<br />
</li><br />
<li>Preparation and knowledge - Keeping backups and knowing the state of your WordPress installation at regular intervals. Having a plan to backup and recover your installation in the case of catastrophe can help you get back online faster in the case of a problem.<br />
</li><br />
<li><br />
Passwords<br />
</li><br />
<li><br />
File Permissions<br />
</li><br />
<li><br />
Admin user<br />
</li><br />
<li><br />
SSL<br />
</li><br />
<li><br />
SFTP client<br />
</li><br />
<li><br />
Platform updates<br />
</li><br />
</ol><br />
Hosting install of pre-built software platform, such as Wordpress,<br />
<br />
===Shared Hosting===<br />
In a [[Shared_Hosting|Shared Hosting]] environment, your and other website owners shared one server. This includes sharing the physical server and the software applications within the server. Shared hosting services are affordable because the cost to operate the server is shared between you and these other owners. There are, however, a number of down sides, such as being slower.<br />
<br />
<br />
===Threat Mitigation===<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
<br />
==Basic Technical==<br />
<div class="mw-collapsible-content"><br />
For a basic setup providing a content distribution platform such as a blog user's have the option of using existing free services such as Wordpress, Journoportfolio or similar.<br />
===Threat Mitigation===<br />
strong passwords, 2 factor auth,<br />
</div><br />
</div><br />
<br />
<div class="toccolours mw-collapsible mw-collapsed" style="width:800px"><br />
==Comparison Matrix==<br />
<div class="mw-collapsible-content"><br />
<br />
<div class="mw-collapsible-content"><br />
{| class="wikitable" width="60%"<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| '''Dedicated Server'''<br />
| style="padding: 5px;"| '''Virtual Private Server'''<br />
| style="padding: 5px;"| '''Shared Hosting'''<br />
| style="padding: 5px;"| '''Cloud Service'''<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| High technical skill<br />
| style="padding: 5px;"| Requires Intermediary technical skill<br />
| style="padding: 5px;"| Intermediary/Basic<br />
| style="padding: 5px;"| Basic<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows disk/data encryption<br />
| style="padding: 5px;"| Allows encryption within VPS<br />
| style="padding: 5px;"| Limited or no control of data encryption<br />
| style="padding: 5px;"| Depends on provider but usually not provided<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| SSH and private key login<br />
| style="padding: 5px;"| Enforce secure login for VPS<br />
| style="padding: 5px;"| Login via CPanel or Custom interface - some hosts offer 2 factor auth<br />
| style="padding: 5px;"| Depends<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| User access control and restriction<br />
| style="padding: 5px;"| User control<br />
| style="padding: 5px;"| Control via user accounts added through management software<br />
| style="padding: 5px;"| Control via management software<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Allows SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| SSL cert, must setup and provide own cert<br />
| style="padding: 5px;"| Allows only shared SSL cert, most host provide shared cert<br />
| style="padding: 5px;"| Most host platforms will provide SSL support by default<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Total control of applications and software<br />
| style="padding: 5px;"| Control of software within VM, limited access to hardware depending on type of VM<br />
| style="padding: 5px;"| Application control only via management interface<br />
| style="padding: 5px;"| Depends on cloud server - certain services with provide data access restrictions but this is a non-ideal scenario<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Manually maintained and updated<br />
| style="padding: 5px;"| Server is patched but VPS remains responsibility of user<br />
| style="padding: 5px;"| Patches and updates provided by host - though may lag behind depending on quality of hosting<br />
| style="padding: 5px;"| Depending on scale of provider - patching and support will be provided to protect their reputation<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Limited supported - hardware support and replacement depending on provider<br />
| style="padding: 5px;"| Similar to dedicated support<br />
| style="padding: 5px;"| Support is generally in terms of management software - hardware is automatically monitored by hosts<br />
| style="padding: 5px;"| Similar to shared though support is specific to the platform hosting<br />
|-<br />
| style="padding: 10px;"| <br />
| style="padding: 5px;"| Anti-ddos and brute forcing via fail2ban, botnetdbp deployment<br />
| style="padding: 5px;"| Provider may or may not mitigate DDoS attacks<br />
| style="padding: 5px;"| DDoS attacks will receive some or limited mitigation depending on quality of host, generally they will not protect against large scale attacks and may force the website to be removed<br />
| style="padding: 5px;"| Depending on the provider if the attack crosses their threshold for protection they may shut down the website or ask it to leave<br />
|}<br />
</div><br />
</div><br />
</div><br />
<br />
<br />
[[Secure_hosting_guide|Back to front page]]<br />
<br />
[[Category: Secure Hosting]]</div>Billhttps://learn.equalit.ie/wiki/Access_RestrictionsAccess Restrictions2014-05-16T22:35:04Z<p>Bill: /* Dedicated/VPS Hosting */</p>
<hr />
<div>Restricting access to data based on roles, rights and responsibilities is an integral part of any security policy. It is equally true in the framing of secure hosting.<br />
<br />
In this circumstance, access should be clearly separated into roles at different levels. When hosting a web application a separate password and user should be used for database access by the web application. The web application should never have root access to any other domain. In a similar way, real world users should be divided into roles and categories and non-should be granted full root access.<br />
<br />
==Dedicated/VPS Hosting==<br />
<br />
'''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.<br />
<ol><br />
<li><br />
Enforce strong password - a strong password should contain Upper and Lower case characters, Numbers and Special Characters and should be long; greater than 20 characters. It is also possible to restrict the use of previously used passwords. On Linux systems the following command can be used to force complex passwords for users:<br />
</li><br />
password required pam_cracklib.so minlen=12 lcredit=1 ucredit=1 dcredit=2 ocredit=1<br />
<br />
For more detail, refer to the guide [http://www.linux-faqs.info/security/force-strong-passwords| Force strong passwords]<br />
<li><br />
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].<br />
</li><br />
<li><br />
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]<br />
</li><br />
<li><br />
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]<br />
</li><br />
</ol><br />
'''User Management''' on Dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<ol><br />
<li><br />
Root user login should be disabled by default<br />
</li><br />
<li><br />
Secure Shell(SSH) login should be forced, telnet and ftp login access should be disabled by default. To upload files to the server securely user can use Secure FTP(SFTP) clients. <br />
</li><br />
<li><br />
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]<br />
</li><br />
<li><br />
File permissions should be restricted for critical files. User should only be allowed access to files relevant to their work. Execution as root should be restricted. Discussion of [http://www.linux.com/learn/tutorials/309527-understanding-linux-file-permissions| linux file permissions].<br />
</li><br />
</ol><br />
<br />
==Shared Hosting==<br />
<ol><br />
<li>'''Password Management'''<br />
For shared hosting password managment is a core defence against attack. The administrator password should fit the criteria above for a strong password - long, variance in characters containing no dictionary words.<br />
<br />
As above [https://securityinabox.org/en/keepass_main| Keepass] can be used to generate and store a complex admin password. This has the secondary advantage of limiting access to the admin password to those who are trusted with the Keepass store.<br />
</li><br />
<li><br />
'''Restrict IP addresses'''<br />
<br />
Depending on what version of CPanel your provider offers, it is possible to lock down access via [http://docs.cpanel.net/twiki/bin/view/AllDocumentation/WHMDocs/DenyAccess| Host Access Control] option. This allows you limit access to very specific IP addresses.<br />
</li><br />
<li><br />
'''User management'''<br />
User accounts on a Shared Hosting system should be restricted only to those whose core responsibility is for updating or maintaining the organisations site.<br />
Access information should, however, also be stored by the Organisation as part of their regular backups - in the event that the responsible party leaves the Organisation.<br />
</li><br />
</ol></div>Billhttps://learn.equalit.ie/wiki/Access_RestrictionsAccess Restrictions2014-05-16T22:34:47Z<p>Bill: /* Dedicated/VPS Hosting */</p>
<hr />
<div>Restricting access to data based on roles, rights and responsibilities is an integral part of any security policy. It is equally true in the framing of secure hosting.<br />
<br />
In this circumstance, access should be clearly separated into roles at different levels. When hosting a web application a separate password and user should be used for database access by the web application. The web application should never have root access to any other domain. In a similar way, real world users should be divided into roles and categories and non-should be granted full root access.<br />
<br />
==Dedicated/VPS Hosting==<br />
<br />
'''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.<br />
<ol><br />
<li><br />
Enforce strong password - a strong password should contain Upper and Lower case characters, Numbers and Special Characters and should be long; greater than 20 characters. It is also possible to restrict the use of previously used passwords. On Linux systems the following command can be used to force complex passwords for users:<br />
</li><br />
password required pam_cracklib.so minlen=12 lcredit=1 ucredit=1 dcredit=2 ocredit=1<br />
<br />
For more detail, refer to the guide [http://www.linux-faqs.info/security/force-strong-passwords| Force strong passwords]<br />
<li><br />
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].<br />
</li><br />
<li><br />
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]<br />
</li><br />
<li><br />
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]<br />
</li><br />
</ol><br />
'''User Management''' on Dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<ol><br />
<li><br />
Root user login should be disabled by default<br />
</li><br />
<li><br />
Secure Shell(SSH) login should be forced, telnet and ftp login access should be disabled by default. To upload files to the server securely user can use Secure FTP(SFTP) clients. <br />
</li><br />
<li><br />
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]<br />
</li><br />
<li><br />
File permissions should be restricted for critical files. User should only be allowed access to files relevant to their work. Execution as root should be restricted. Discussion of [http://www.linux.com/learn/tutorials/309527-understanding-linux-file-permissions| linux file permissions].<br />
</li><br />
</ol><br />
<br />
==Shared Hosting==<br />
<ol><br />
<li>'''Password Management'''<br />
For shared hosting password managment is a core defence against attack. The administrator password should fit the criteria above for a strong password - long, variance in characters containing no dictionary words.<br />
<br />
As above [https://securityinabox.org/en/keepass_main| Keepass] can be used to generate and store a complex admin password. This has the secondary advantage of limiting access to the admin password to those who are trusted with the Keepass store.<br />
</li><br />
<li><br />
'''Restrict IP addresses'''<br />
<br />
Depending on what version of CPanel your provider offers, it is possible to lock down access via [http://docs.cpanel.net/twiki/bin/view/AllDocumentation/WHMDocs/DenyAccess| Host Access Control] option. This allows you limit access to very specific IP addresses.<br />
</li><br />
<li><br />
'''User management'''<br />
User accounts on a Shared Hosting system should be restricted only to those whose core responsibility is for updating or maintaining the organisations site.<br />
Access information should, however, also be stored by the Organisation as part of their regular backups - in the event that the responsible party leaves the Organisation.<br />
</li><br />
</ol></div>Billhttps://learn.equalit.ie/wiki/Access_RestrictionsAccess Restrictions2014-05-16T22:33:05Z<p>Bill: /* Dedicated/VPS Hosting */</p>
<hr />
<div>Restricting access to data based on roles, rights and responsibilities is an integral part of any security policy. It is equally true in the framing of secure hosting.<br />
<br />
In this circumstance, access should be clearly separated into roles at different levels. When hosting a web application a separate password and user should be used for database access by the web application. The web application should never have root access to any other domain. In a similar way, real world users should be divided into roles and categories and non-should be granted full root access.<br />
<br />
==Dedicated/VPS Hosting==<br />
<br />
'''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.<br />
<ol><br />
<li><br />
Enforce strong password - a strong password should contain Upper and Lower case characters, Numbers and Special Characters and should be long; greater than 20 characters. It is also possible to restrict the use of previously used passwords. On Linux systems the following command can be used to force complex passwords for users:<br />
</li><br />
password required pam_cracklib.so minlen=12 lcredit=1 ucredit=1 dcredit=2 ocredit=1<br />
<br />
For more detail, refer to the guide [http://www.linux-faqs.info/security/force-strong-passwords| Force strong passwords]<br />
<li><br />
Use password aging, the chaging command on Linux servers allows checking of password age by user and setting of password aging parameters[link for tutorial on chaging]<br />
</li><br />
<li><br />
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]<br />
</li><br />
<li><br />
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]<br />
</li><br />
</ol><br />
'''User Management''' on Dedicated or VPS systems allow administrators fine grained control of user login and access permissions.<br />
<ol><br />
<li><br />
Root user login should be disabled by default<br />
</li><br />
<li><br />
Secure Shell(SSH) login should be forced, telnet and ftp login access should be disabled by default. To upload files to the server securely user can use Secure FTP(SFTP) clients. <br />
</li><br />
<li><br />
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]<br />
</li><br />
<li><br />
File permissions should be restricted for critical files. User should only be allowed access to files relevant to their work. Execution as root should be restricted. Discussion of [http://www.linux.com/learn/tutorials/309527-understanding-linux-file-permissions| linux file permissions].<br />
</li><br />
</ol><br />
<br />
==Shared Hosting==<br />
<ol><br />
<li>'''Password Management'''<br />
For shared hosting password managment is a core defence against attack. The administrator password should fit the criteria above for a strong password - long, variance in characters containing no dictionary words.<br />
<br />
As above [https://securityinabox.org/en/keepass_main| Keepass] can be used to generate and store a complex admin password. This has the secondary advantage of limiting access to the admin password to those who are trusted with the Keepass store.<br />
</li><br />
<li><br />
'''Restrict IP addresses'''<br />
<br />
Depending on what version of CPanel your provider offers, it is possible to lock down access via [http://docs.cpanel.net/twiki/bin/view/AllDocumentation/WHMDocs/DenyAccess| Host Access Control] option. This allows you limit access to very specific IP addresses.<br />
</li><br />
<li><br />
'''User management'''<br />
User accounts on a Shared Hosting system should be restricted only to those whose core responsibility is for updating or maintaining the organisations site.<br />
Access information should, however, also be stored by the Organisation as part of their regular backups - in the event that the responsible party leaves the Organisation.<br />
</li><br />
</ol></div>Billhttps://learn.equalit.ie/wiki/Geography,_lesgislation_and_terms_of_serviceGeography, lesgislation and terms of service2014-05-16T22:31:21Z<p>Bill: </p>
<hr />
<div>For Activists, Journalists, NGOs or any Civil Society online participants, legal and geographic jurisdiction should be forefront when considering where to host their websites.<br />
<br />
==Legal Jurisdictions==<br />
The Internet has introduced a dislocated sense of legal jurisdiction, in some cases the problem of applying one countries laws to a different jurisdiction is not a new conception. Over time many countries have developed contracts, treaties and agreements with other states governing extradition of individuals who are wanted for breach of one country's legal code but are currently residing in another country. <br />
<br />
There have been a number of cases in the last decade ranging from extremely high profile, Julian Assange and Edward Snowden, to limited attention paid, [https://en.wikipedia.org/wiki/Gary_McKinnon| Gary McKinnion].<br />
<br />
In many countries a core weapon used for censorship, oppression and repression is the judiciary and the enacting or novel use of laws designed to restrict freedoms. This is a very effective tactic and the results can be seen in countries such as Vietnam where a number of individuals have been tried for publishing material consider by the authorities to be illegal; either because of content - deemed anti-governmental - or method of publishing - publication under pseudonyms.<br />
<br />
Publication within the Jurisdiction of a given country can leave the publishers open to legal punishment.<br />
<br />
Ultimately, hosting a site in a different political or legal jurisdiction can not prevent recriminations against journalist, organisation or activists with country. It can prevent the ability to physical take the site or publication offline.<br />
<br />
This can be hampered in part by the use of intermediary resellers. For example, in the case of Cambodia hosting platforms are located outside of the country, however, access to these services is done through local resellers who are subject to Cambodian law. These resellers are chosen largely for language and immediacy of access to support.<br />
<br />
In determining the current laws that are applied or may be applied to your work or your locale there are a number of resources provided by monitoring groups that can be used as a starting point. This information is far from complete and is often only able to report on what legal tools have been used in the past.<br />
<br />
<ol><br />
<li><br />
[http://defendersdays.civilrightsdefenders.org/| Civil Rights Defenders]<br />
</li><br />
<li><br />
[http://www.iltb.net/| Indian Law and Technology blog]<br />
</li><br />
<li><br />
[http://www.openrightsgroup.org/| Open Rights Group]<br />
</li><br />
<li><br />
[https://supporters.eff.org/| Electronic Frontier Foundation (EFF)]<br />
</li><br />
<li><br />
[https://www.cpj.org/| Committee to protect Journalists]<br />
</li><br />
<li><br />
[http://freedomhouse.org/| Freedom House]<br />
</li><br />
<li><br />
[http://witness.org/| Witness]<br />
</li><br />
<li><br />
[http://www.frontlinedefenders.org/| Frontline Defenders]<br />
<li><br />
[http://www.lwob.org/Pages/Default.aspx| Lawyers without Borders]<br />
</li><br />
<li><br />
[https://iscproject.org/country-assessments/| ISC Project]<br />
</li><br />
<li><br />
Many countries have specialised legal aide and free legal advice centres that can be contacted to help determine what laws may apply to your work<br />
</li><br />
</ol><br />
<br />
==Geographic Areas==<br />
<br />
Locating a server within a groups own geographic area, where their adversary is the authority or power groups within that geography will leave the site open to infrastructural attacks or censorship. <br />
<br />
As the site is located within the country's own infrastructure it is subject to all censorship applied by the state, ISP or national gateway.<br />
<br />
==Publishing and Content Legislation==<br />
<br />
Censorship through legal means is a prevalent form of suppression and a cause of self censorship. It is extremely important that organisations, journalists and individual take responsibility for their own education in terms of awareness of new digital laws as well as past applications and precedents set in prosecution.<br />
<br />
==Terms and Conditions==<br />
<br />
Carefully choice should be made in terms of the provider themselves. A strong reputation for support, quality and security is important but as to is alignment with your organisations goals.<br />
<br />
Ultimately, a contract is agreed between your organisation and the service provider. This contract governs how, when, and under what circumstances service will or won't be provided. <br />
<br />
If your provider has a history of discontinuing service to activists, journalist or civil society groups, or request that they self censor - then it is important to establish this at the outset. It is necessary to determine with your provider what content they might prohibit or what rules govern the extent to which they will support activists in publishing their work.<br />
<br />
There are already a number of service providers that aim to support the activists, NGO and non-profit world. Amongst them are [https://greenhost.net/about-us/| Green Host], [https://help.riseup.net/en/about-us| Riseup] and [https://leap.se/en/about-us| Leap].</div>Billhttps://learn.equalit.ie/wiki/Geography,_lesgislation_and_terms_of_serviceGeography, lesgislation and terms of service2014-05-16T21:45:03Z<p>Bill: </p>
<hr />
<div>For Activists, Journalists, NGOs or any Civil Society online participants, legal and geographic jurisdiction should be forefront when considering where to host their websites.<br />
<br />
==Legal Jurisdictions==<br />
The Internet has introduced a dislocated sense of legal jurisdiction, in some cases the problem of applying one countries laws to a different jurisdiction is not a new conception. Over time many countries have developed contracts, treaties and agreements with other states governing extradition of individuals who are wanted for breach of one country's legal code but are currently residing in another country. <br />
<br />
There have been a number of cases in the last decade ranging from extremely high profile, Julian Assange and Edward Snowden, to limited attention paid, [https://en.wikipedia.org/wiki/Gary_McKinnon| Gary McKinnion].<br />
<br />
In many countries a core weapon used for censorship, oppression and repression is the judiciary and the enacting or novel use of laws designed to restrict freedoms. This is a very effective tactic and the results can be seen in countries such as Vietnam where a number of individuals have been tried for publishing material consider by the authorities to be illegal; either because of content - deemed anti-governmental - or method of publishing - publication under pseudonyms.<br />
<br />
Publication within the Jurisdiction of a given country can leave the publishers open to legal punishment.<br />
<br />
Ultimately, hosting a site in a different political or legal jurisdiction can not prevent recriminations against journalist, organisation or activists with country. It can prevent the ability to physical take the site or publication offline.<br />
<br />
This can be hampered in part by the use of intermediary resellers. For example, in the case of Cambodia hosting platforms are located outside of the country, however, access to these services is done through local resellers who are subject to Cambodian law. These resellers are chosen largely for language and immediacy of access to support.<br />
<br />
==Geographic Areas==<br />
<br />
Locating a server within a groups own geographic area, where their adversary is the authority or power groups within that geography will leave the site open to infrastructural attacks or censorship. <br />
<br />
As the site is located within the country's own infrastructure it is subject to all censorship applied by the state, ISP or national gateway.<br />
<br />
==Publishing and Content Legislation==<br />
<br />
Censorship through legal means is a prevalent form of suppression and a cause of self censorship. It is extremely important that organisations, journalists and individual take responsibility for their own education in terms of awareness of new digital laws as well as past applications and precedents set in prosecution.<br />
<br />
==Terms and Conditions==<br />
<br />
Carefully choice should be made in terms of the provider themselves. A strong reputation for support, quality and security is important but as to is alignment with your organisations goals.<br />
<br />
Ultimately, a contract is agreed between your organisation and the service provider. This contract governs how, when, and under what circumstances service will or won't be provided. <br />
<br />
If your provider has a history of discontinuing service to activists, journalist or civil society groups, or request that they self censor - then it is important to establish this at the outset. It is necessary to determine with your provider what content they might prohibit or what rules govern the extent to which they will support activists in publishing their work.<br />
<br />
There are already a number of service providers that aim to support the activists, NGO and non-profit world. Amongst them are [https://greenhost.net/about-us/| Green Host], [https://help.riseup.net/en/about-us| Riseup] and [https://leap.se/en/about-us| Leap].</div>Billhttps://learn.equalit.ie/wiki/Secure_connectionsSecure connections2014-05-16T21:36:55Z<p>Bill: </p>
<hr />
<div>When communicating data to/from a server it is important that the infromation not be susceptible to man-in-the-middle attacks. If data is communicated over open, plain text mediums such as FTP or HTTP then that data can be intercepted and read by any entity on any of the networks that the information passes through; this can included Local Area Networks, ISPs, or National Entities<br />
<br />
There are a number of steps that can be taken to protect communication channels to and from the server, though no system is 100% secure.<br />
<br />
<ol><br />
<li><br />
'''SSL'''<br />
If your website does not have an SSL certificate then all web traffic direct to your site will be unencrypted and potentially subject to snooping. <br />
<br />
Secure Socket Layer(SSL) is a cryptographic protocol which allows secure client-server interactions. Once a secure session has been established between the client, for example your web browser, and the server, your website in this case, all the information that passes between the two is unreadable to external parties.<br />
<br />
In order, to provide SSL for your website you must purchase an SSL certificate. This is a digital document that is signed by a recognised certificate reseller that uniquely belongs to your domain. <br />
<br />
An added benefit of SSL certificates is that they can aid in preventing SSL spoofing. This occurs where a malicious websites pretend to be a legitimate website or a server pretends to be a legitimate holder of the SSL cert. <br />
<br />
Most modern browsers will give a warning if an SSL cert has expired or is invalid - as in that it may be a spoof certificate.<br />
<br />
One of the most commonly used SSL software packages on the Internet, OpenSSL, suffered a major security flaw in the shape of the [http://heartbleed.com/| Heart Bleed bug]. This left most websites using a certain version of OpenSSL open to an exploit. This incident highlights that no technology is 100% secure and requires constant monitoring.<br />
<br />
</li><br />
<li><br />
'''SFTP'''<br />
When transfering files to or from a remote server it is integral to security to use an SFTP client. This stands for Secure File Tranfer Protocol. In a similar manner to SSL it ensures that the communications to and from the server are not open to external individuals.<br />
</li><br />
<li><br />
'''SSH'''<br />
When connecting directly to a server, for example for command line access, it is imperative to use the Secure SHell protocol. As the telnet protocol provides no level of security and should be disabled. For further information see []<br />
</li><br />
<ol></div>Bill