more clarification on SSH configuration
[ach-master.git] / src / practical_settings.tex
index 41a4a62..a275eb2 100644 (file)
@@ -158,11 +158,11 @@ You should redirect everything to httpS:// if possible. In Nginx you can do this
 \label{sec:ms-iis}
 
 
-\todo{screenshots? registry key settings? }
+\todo{Daniel: add screenshots and registry keys}
 
 \begin{description}
 
-\item[Tested with Version:] \todo{version?}
+\item[Tested with Version:] \todo{Daniel: add tested version}
 
 \item[Settings:] \mbox{}
 
@@ -297,7 +297,13 @@ If you still want to force strong encryption use
   tls_cipher_list: <...recommended ciphersuite...>
 \end{lstlisting}
 
-cyrus-imapd loads hardcoded 1024 bit DH parameters using get\_rfc2409\_prime\_1024() by default. If you want to load your own DH parameters add them PEM encoded to the certificate file given in tls\_cert\_file. Do not forget to re-add them after updating your certificate.
+cyrus-imapd loads hardcoded 1024 bit DH parameters using get\_rfc2409\_prime\_1024() by default. If you want to load your own DH parameters add them PEM encoded to the certificate file given in tls\_cert\_file. Do not forget to re-add them after updating your certificate.\\
+
+To prevent unencrypted connections on the STARTTLS ports you can set
+\begin{lstlisting}[breaklines]
+  allowplaintext: 0
+\end{lstlisting}
+This way MUAs can only authenticate after STARTTLS if you only provide plaintext and SASL PLAIN login methods. Therefore providing CRAM-MD5 or DIGEST-MD5 methods is not recommended.\\
 
 \paragraph*{cyrus.conf}\mbox{}\\
 
@@ -314,6 +320,7 @@ To support POP3S/IMAPS on ports 995/993 add
   pop3s        cmd="pop3d -s" listen="pop3s" prefork=1
 \end{lstlisting}
 
+
 \paragraph*{Limitations}\mbox{}\\
 
 cyrus-imapd currently (2.4.17, trunk) does not support elliptic curves. ECDHE will not work even if defined in your cipher list.\\
@@ -323,11 +330,6 @@ Currently there is no way to prefer server ciphers or to disable compression.\\
 There is a working patch for all three features:
 \url{https://bugzilla.cyrusimap.org/show_bug.cgi?id=3823}\\
 
-There is no way to prevent unencrypted connections on the STARTTLS ports. You can prevent usage of plaintext login by setting
-\begin{lstlisting}[breaklines]
-  allowplaintext: 0
-\end{lstlisting}
-in imapd.conf. But note that SASL PLAIN/LOGIN is still available!\\
 
 
 
@@ -643,31 +645,39 @@ There already is a working patch to provide support:\\
 % do we need to documment starttls in detail?
 %\subsubsection{starttls?}
 
-\subsection{SSH}
-
+\subsection{OpenSSH}
+\paragraph*{sshd_config}
 \begin{lstlisting}[breaklines]
+       # ...
+
        Protocol 2
        PermitEmptyPasswords no
        PermitRootLogin no
        StrictModes yes
        HostKey /etc/ssh/ssh_host_rsa_key
-       Ciphers aes256-ctr
-       MACs hmac-sha2-512,hmac-sha2-256,hmac-ripemd160
+       Ciphers aes256-gcm@openssh.com aes128-gcm@openssh.com aes256-ctr aes128-ctr
+       MACs umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160
        KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
 \end{lstlisting}
 
 % XXX: curve25519-sha256@libssh.org only available upstream(!)
-Note: older linux systems won't support SHA2, PuTTY does not support RIPE-MD160.
+Note: Older linux systems won't support SHA2. PuTTY (Windows) does not support RIPE-MD160. Curve25519, AES-GCM and UMAC are only available upstream (OpenSSH 6.1). DSA host keys have been removed on purpose, the DSS standard does not support for DSA keys stronger than 1024bit
+\footnote{\url{https://bugzilla.mindrot.org/show_bug.cgi?id=1647}} 
+which is far below current standards (see section \ref{section:keylengths}). Legacy systems can use this configuration and simply omit unsupported ciphers, key exchange algorithms and MACs.
 \\
 
 
 \subsection{VPNs}
 \todo{write this subsection}
 \subsubsection{IPSec}
+\label{section:IPSECgeneral}
+
 
 \todo{cm: check if there are downgrade attacks for checkpoint \& co} \\
-\todo{cm: reference the paper describing how complex IPSec is and that it can't be checked properly} \\
-\todo{cm: change this to a table format: Variant ((A,B), (recommendations, recommendations))} \\
+
+\begin{description}
+
+\item[Settings:] \mbox{}
 
 \paragraph*{Assumptions}\mbox{}\\
 
@@ -683,11 +693,33 @@ against fake certificates.
 If you need to use Pre-Shared Key authentication:
 
 \begin{enumerate}
-\item Choose a \textbf{random} PSK of 20 characters or more (\todo{length, references!})
+\item Choose a \textbf{random}, \textbf{long enough} PSK (see below)
 \item Use a \textbf{separate} PSK for any IPSEC connection
 \item Change the PSKs regularily
 \end{enumerate}
 
+The size of the PSK should not be shorter than the output size of
+the hash algorithm used in IKE \footnote{It is used in a HMAC, see
+  \url{http://www.ietf.org/rfc/rfc2104.txt}.}.
+
+For a key composed of upper- and lowercase letters, numbers, and two
+additional symbols \footnote{64 possible values = 6 bits}, that gives
+the following minimum lengths in characters:
+
+\begin{table}[h]
+  \centering
+  \small
+  \begin{tabular}{lc}
+    \toprule
+    IKE Hash & PSK length \\
+    \midrule
+    SHA256 & 43 \\
+    SHA384 & 64 \\
+    SHA512 & 86 \\
+    \bottomrule
+  \end{tabular}
+\end{table}
+
 \paragraph*{Cryptographic Suites}\mbox{}\\
 
 IPSEC Cryptographic Suites are pre-defined settings for all the
@@ -695,85 +727,220 @@ items of a configuration; they try to provide a balanced security
 level and make setting up VPNs easier.
 
 When using any of those suites, make sure to enable ``Perfect Forward
-Secrecy`` for Phase 2, as this is not specified in the suites.
-
-\verb|Suite-B-GCM-256| \footnote{\url{http://tools.ietf.org/html/rfc6379}}
-would be roughly equivalent to ``Configuration A``, but keep in mind
-that it uses NIST elliptic curves for the Diffie-Hellman key exchange.
-
-\verb|Suite-B-GCM-128| or
-\verb|VPN-B| \footnote{\url{http://tools.ietf.org/html/rfc4308}} would
-be roughly equivalent to ``Configuration B``; again,
-\verb|Suite-B-GCM-128| uses NIST elliptic curves, \verb|VPN-B| does
-not.
+Secrecy`` for Phase 2, as this is not specified in the suites. The
+equivalents to the recommended ciphers suites in section
+\ref{section:recommendedciphers} are:
 
-\todo{Aaron: make an example for how to include images}
-\todo{cm: screenshots of Checkpoint settings}
+\begin{table}[h]
+  \centering
+  \small
+  \begin{tabular}{lll}
+    \toprule
+    Configuration A & Configuration B & Notes\\
+    \midrule
+    \verb|Suite-B-GCM-256|\footnote{\url{http://tools.ietf.org/html/rfc6379}} &
+\verb|Suite-B-GCM-128| & Uses NIST elliptic curves
+\\ & \verb|VPN-B|\footnote{\url{http://tools.ietf.org/html/rfc4308}} &
+\\
+    \bottomrule
+  \end{tabular}
+\end{table}
 
 \paragraph*{IKE or Phase 1}\mbox{}\\
 
+Alternatively to the pre-defined cipher suites, you can define your
+own, as described in this and the next section.
+
 IKE or Phase 1 is the mutual authentication and key exchange phase.
 
 Use only ``main mode``, as ``aggressive mode`` has known security
 vulnerabilities \footnote{\url{http://ikecrack.sourceforge.net/}}.
 
-Encryption Algorithm: AES or CAMELLIA
+\todo{how to make footnotes in a table appear in the output document?}
 
-Hash Algorithm: SHA2-256, SHA2-384 or SHA2-512
+\begin{table}
+  \centering
+  \small
+  \begin{tabular}{lll}
+    \toprule
+    & Configuration A & Configuration B \\
+    \midrule
+    Mode & Main Mode & Main Mode \\
+    Encryption & AES-256 & AES-256, CAMELLIA-256 \\
+    Hash & SHA2-* & SHA2-*, SHA1 \\
+    DH Group & Group 14--18 \footnote{2048--8192 bit DH},
+    19--21\footnote{(256--521 bit ECDH)} & Group 14--21 \\
+    Lifetime & \todo{need recommendations; 1 day seems to be common
+      practice} & \\
+    \bottomrule
+  \end{tabular}
+\end{table}
 
-DH Group: Group 14--18 (2048--8192 bit DH), or 19-21 (256--521 bit
-ECDH)
+\paragraph*{ESP or Phase 2}\mbox{}\\
 
-Lifetime: \todo{need recommendations; 1 day seems to be common practice}
+ESP or Phase 2 is where the actual data are protected.
 
-\todo{what about CAST?}
+\todo{make the tables appear right here!}
 
-\paragraph*{ESP or Phase 2}\mbox{}\\
+\begin{table}
+  \centering
+  \small
+  \begin{tabular}{lll}
+    \toprule
+    & Configuration A & Configuration B \\
+    \midrule
+    Perfect Forward Secrecy & yes & yes \\
+    Encryption & AES-GCM-16, AES-CTR, AES-CCM-16, AES-256 & AES-GCM-16, AES-CTR, AES-CCM-16, AES-256, CAMELLIA-256 \\
+    Hash & SHA2-* (or none for AES-GCM) & SHA2-*, SHA1 (or none for AES-GCM) \\
+    DH Group & Same as Phase 1 & Same as Phase 1 \\
+    Lifetime & \todo{need recommendations; 1-8 hours is common} & \\
+    \bottomrule
+  \end{tabular}
+\end{table}
+
+\item[References:] \mbox{}
+
+``A Cryptographic Evaluation of IPsec'', Niels Ferguson and Bruce
+  Schneier: \url{https://www.schneier.com/paper-ipsec.pdf}
+
+\end{description}
 
-Enable ``Perfect Forward Secrecy`` with a DH Group equivalent to the
-one chosen for IKE.
+\subsubsection{Check Point FireWall-1}
+   
+\begin{description}
+\item[Tested with Version:] \mbox{}
+
+\begin{itemize}
+\item R77 (should work with any currently supported version)
+\end{itemize}
+
+\item[Settings:] \mbox{}
 
-Encryption Algorithm: AES-GCM-16, AES-CTR, AES-CCM-16, AES-CBC, SEED
-or CAMELLIA \todo{order of this list?}
+Please see section \ref{section:IPSECgeneral} for guidance on
+parameter choice. In this section, we will configure a strong setup
+according to ``Configuration A''.
 
-Hash Algorithm: none (if using AES-GCM), HMAC-SHA-SHA256 or longer
-\todo{what about AES-XCBC-MAC?}
+This is based on the concept of a ``VPN Community'', which has all the
+settings for the gateways that are included in that community.
+Communities can be found in the ``IPSEC VPN'' tab of SmartDashboard.
 
-Lifetime: \todo{need recommendations; 1--8 hours seems to be common practice}
+\todo{make those graphics prettier -- whoever has the right LaTeX
+  mojo, please do!}
+
+\includegraphics{checkpoint_1.png}
+
+Either chose one of the encryption suites here, or proceed to
+``Custom Encryption...'', where you can set encryption and hash for
+Phase 1 and 2:
+
+\includegraphics{checkpoint_2.png}
+
+The Diffie-Hellman groups and Perfect Forward Secrecy Settings can be
+found under ``Advanced Settings'' / ``Advanced VPN Properties'':
+
+\includegraphics{checkpoint_3.png}
+
+\item[Additional settings:]
+
+For remote Dynamic IP Gateways, the settings are not taken from the
+community, but set in the ``Global Properties'' dialog under ``Remote
+Access'' / ``VPN Authentication and Encryption''. Via the ``Edit...''
+button, you can configure sets of algorithms that all gateways support:
+
+\includegraphics{checkpoint_4.png}
+
+Please note that these settings restrict the available algorithms for
+\textbf{all} gateways, and also influence the VPN client connections.
+
+%\item[Justification for special settings (if needed):]
+
+%\item[Limitations:]
+
+\item[References:]\mbox{}
+
+\begin{itemize}
+
+\item Check Point
+  \href{https://sc1.checkpoint.com/documents/R77/CP_R77_VPN_AdminGuide/html_frameset.htm}{VPN
+    R77 Administration Guide} (may require a
+  UserCenter account to access)
+
+\end{itemize}
+
+% \item[How to test:]
+
+\end{description}
 
 
 \subsubsection{OpenVPN}
+
+\begin{description}
+
+\item[Tested with Version:] OpenVPN 2.3.2 from Debian backports linked against openssl (libssl.so.1.0.0) 
+
 \todo{cm: please write this subsubsection}
-\todo{We suppose user uses easy-rsa which is roughly used in all HOWTO\footnote{http://openvpn.net/index.php/open-source/documentation/howto.html}}
+\todo{We suppose user uses easy-rsa which is roughly used in all HOWTO\footnote{\url{http://openvpn.net/index.php/open-source/documentation/howto.html}}}
+
+
+\item[Additional settings:] \mbox{}
 
 \paragraph{Fine tuning at installation level}
 
 When installing an OpenVPN server instance, you are probably using {\it easy-rsa} tools to generate the crypto stuff needed.
-From the directory where you will run them, you can enhance you configuration by changing the following variables in {\it Vars}
+From the directory where you will run them, you can enhance you configuration by changing the following variables in \verb|vars|:
 
 \begin{lstlisting}[breaklines]
 export KEY_SIZE=2048 
+export KEY_EXPIRE=365
+export CA_EXPIRE=1826
 \end{lstlisting}
 
-This will enhance the security of the key exchange steps by using RSA keys with a length of 2048 bits.
-\todo{Shouldn't we need to reduce CA and certificate lifetime?  Per default 10y!!}
+This will enhance the security of the key generation by using RSA keys
+with a length of 2048 bits, and set a lifetime of one year for the
+keys and five years for the CA certificate.
+
+In addition, edit the \verb|pkitool| script and replace all occurences
+of \verb|sha1| with \verb|sha256|, to sign the certificates with
+SHA256.
 
 \paragraph{Server Configuration}
 
 In the server configuration file, you can select the algorithm that will be used for traffic encryption.
 Based on previous recommendation established in that document, select AES with a 256 bits key in CBC mode.
 
+Note that TLS is used only for negotiation bla bla bla...
+
+\todo{cm: explain how openvpn crypto works; make configA/B sections/tables}
+
+\item[Settings:] \mbox{}
+
+% openvpn --show-ciphers
+% --show-tls
+
+\todo{cm: changelog 2.3.1: ``Switch to IANA names for TLS ciphers'' --
+give both types of strings?}
+
 \begin{lstlisting}[breaklines]
 cipher AES-256-CBC   # AES
 
 # TLS Authentication
 tls-auth ta.key
-tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA
+tls-cipher EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EDH+CAMELLIA256:EECDH:EDH+aRSA:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED:!AES128:!CAMELLIA128:!ECDSA:AES256-SHA
 
 auth SHA512
+
+reneg-bytes XXX
+reneg-pkts XXX
+reneg-sec XXX
+
 \end{lstlisting}
 
+% tls-cipher is a list, C&P the string!
+% what about: TLS-DHE-RSA-WITH-AES-256-CBC-SHA
+% DH params/DH key sizes
+
 \todo{Explain a little bit tls-auth and auth directives + TEST}
+\todo{also test with network-damager?}
 
 The following ciphers are avaible and recommended\footnote{You can retrieve the list of supported algorithm on your OpenVPN installation thanks to the command {\it openvpn --show-ciphers}}
 \begin{lstlisting}[breaklines]
@@ -786,6 +953,7 @@ CAMELLIA-256-CBC
 SEED-CBC
 \end{lstlisting}
 
+
 \paragraph{Client Configuration}
 
 Client and server have to use identical configuration otherwise they can't communicate.
@@ -793,13 +961,36 @@ The {\it cipher} directive has then to be identical in both server and client co
 
 \begin{lstlisting}[breaklines]
 cipher AES-256-CBC   # AES
+
+remote-cert-tls server # http://openvpn.net/index.php/open-source/documentation/howto.html#mitm
+
+tls-remote server.example.com
+
 \end{lstlisting}
 
 \todo{what about tls-auth keys/ta.key? }. 
 \todo{what about auth sha512 ?}
 
+\item[Justification for special settings (if needed):]
+
+\item[References:] \url{http://openvpn.net/index.php/open-source/documentation/security-overview.html}
+
+\item[How to test:]
+\todo{write me please}
+
+
+\end{description}
+
+
 \subsubsection{PPTP}
-\todo{cm: please write this subsubsection}
+
+PPTP is considered insecure, Microsoft recommends to ``use a more secure VPN
+tunnel''\footnote{\url{http://technet.microsoft.com/en-us/security/advisory/2743314}}.
+
+There is a cloud service that cracks the underlying MS-CHAPv2
+authentication protocol for the price of USD~200\footnote{\url{https://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/}},
+and given the resulting MD4 hash, all PPTP traffic for a user can
+be decrypted.
 
 \subsubsection{Cisco IPSec}
 \todo{write this subsubsection}
@@ -830,8 +1021,11 @@ seclayer-tcp    3495/tcp    # securitylayer over tcp
 
 
 \subsection{IPMI, ILO and other lights out management solutions}
-\todo{write this!! Recommendation. Empfehlung: nie ins Internet, nur in ein eigenes mgmt VLAN, das via VPN erreichbar ist!!
-Adi?? }
+
+
+We \textbf{strongly} recommend that any remote management system for servers such as ILO, IPMI and similar never be connected to a public IP address.
+Consider creating a management VLAN and access that only via a VPN.
+
 
 \subsection{SIP}
 \todo{AK: ask Klaus. Write this section, Klaus??? }