scap-security-guide April 2012

scap-security-guide@lists.fedorahosted.org

12 participants
70 discussions

[PATCH 1/4] Added content referenced in Trac ticket #38.
by Willy Santos 26 Apr '12

26 Apr '12

Signed-off-by: Willy Santos <wsantos(a)redhat.com> --- rhel6/src/input/services/imap.xml | 172 ++++++++++++++++++++++++++++++++++++- 1 files changed, 170 insertions(+), 2 deletions(-) diff --git a/rhel6/src/input/services/imap.xml b/rhel6/src/input/services/imap.xml index 93dedce..cb6c644 100644 --- a/rhel6/src/input/services/imap.xml +++ b/rhel6/src/input/services/imap.xml @@ -40,6 +40,174 @@ removing it provides a safeguard against its activation. <oval id="package_dovecot_removed" /> </Rule> -</Group> -</Group> +</Group>  + +<Group id="configure_dovecot"> +<title>Configure Dovecot if Necessary</title> +<description>If the system will operate as an IMAP or +POP3 server, the dovecot software should be configured securely by following +the recommendations below. +</description> + +<Rule id="dovecot_support_necessary_protocols"> +<title>Support Only the Necessary Protocols</title> +<description>Dovecot supports the IMAP and POP3 protocols, as well as +SSL-protected versions of those protocols. Configure the Dovecot server +to support only the protocols needed by your site. Edit <tt>/etc/dovecot.conf</tt>. +Add or correct the following lines, replacing <tt>PROTOCOL</tt> with +only the subset of protocols (<tt>imap</tt>, <tt>imaps</tt>, +<tt>pop3</tt>, <tt>pop3s</tt>) required: +<pre>protocols = PROTOCOL</pre> +If possible, require SSL protection for all transactions. The SSL +protocol variants listen on alternate ports (995 instead of 110 for +pop3s, and 993 instead of 143 for imaps), and require SSL-aware clients. +An alternate approach is to listen on the standard port and require the +client to use the STARTTLS command before authenticating. +</description> + +<rationale> +Configuring Dovecot to only support the protocols the protocols needed by +your site reduces the risk of an attacker using one of the unused protocols +to base an attack.</rationale> +<ident cce="4384-4" /> +<ident cce="3887-7" /> +<ident cce="4530-2" /> +<ident cce="4547-6" /> + +</Rule> + +<Group id="dovecot_enable_ssl"> +<title>Enable SSL Support</title> +<description>SSL should be used to encrypt network traffic between the +Dovecot server and its clients. Users must authenticate to the Dovecot +server in order to read their mail, and passwords should never be +transmitted in clear text. In addition, protecting mail as it is +downloaded is a privacy measure, and clients may use SSL certificates +to authenticate the server, preventing another system from impersonating +the server. +</description> + +<Rule id="dovecot_configure_ssl_cert"> +<title>Configure Dovecot to Use the SSL Certificate</title> +<description>These options tell Dovecot where to find the TLS +configuration, allowing clients to make encrypted connections. + +Edit <tt>/etc/dovecot.conf</tt> and add or correct the following +lines (ensuring they reference the appropriate files): +<pre>ssl_cert_file = /etc/pki/tls/imap/servercert.pem +ssl_key_file = /etc/pki/tls/imap/serverkey.pem +ssl_ca_file = /etc/pki/tls/CA/cacert.pem +</pre> +</description> +<rationale> +SSL certificates are used by the client to authenticate the identity +of the server, as well as to encrypt credentials and message traffic. +Not using SSL to encrypt mail server traffic could allow unauthorized +access to credentials and mail messages since they are sent in plain +text over the network. +</rationale> + + +</Rule> + +<Rule id="dovecot_disable_plaintext_auth"> +<title>Disable Plaintext Authentication</title> +<description>To prevent Dovecot from attempting plaintext +authentication of clients, edit <tt>/etc/dovecot.conf</tt> and add +or correct the following line: +<pre>disable_plaintext_auth = yes</pre> +</description> +<rationale> +Using plain text authentication to the mail server could allow an +attacker access to credentials by monitoring network traffic. +</rationale> +<ident cce="4552-6" /> +<oval id="dovecot_disable_plaintext_auth" /> +</Rule> + +</Group>  + +<Group id="dovecot_enable_code_flaw_protect"> +<title>Enable Dovecot Options to Protect Against Code Flaws</title> +<description>IMAP and POP3 are remote authenticated protocols, meaning that +the server must accept remote connections from anyone, but provide substantial +services only to clients who have successfully authenticated. To protect +against security problems, Dovecot splits these functions into separate +server processes. The <tt>imap-login</tt> and/or <tt>pop3-login</tt> +processes accept connections from unauthenticated users, and only spawn +<tt>imap</tt> or <tt>pop3</tt> processes on successful authentication. + +However, the <tt>imap-login</tt> and <tt>pop3-login</tt> processes +themselves may contain vulnerabilities. Since each of these processes +operates as a daemon, handling multiple sequential client connections +from different users, bugs in the code could allow unauthenticated users +to steal credential data. If the <tt>login_process_per_connection</tt> option +is enabled, then a separate <tt>imap-login</tt> or <tt>pop3-login</tt> +process is created for each new connection, protecting against this class +of problems. This option has an efficiency cost, but is strongly recommended. + +If the <tt>mail_drop_priv_before_exec</tt> option is on, the <tt>imap-login</tt> +or <tt>pop3-login</tt> process will drop privileges to the userâs ID after +authentication and before executing the <tt>imap</tt> or <tt>pop3</tt> +process itself. Under some very limited circumstances, this could protect +against privilege escalation by authenticated users. However, if the +mail executable option is used to run code before starting each userâs session, +it is important to drop privileges to prevent the custom code from running as root. +</description> + +<Rule id="dovecot_login_process_per_conn_yes"> +<title>login_process_per_connection set to yes</title> +<description>Setting <tt>login_process_per_connection = yes</tt>, prevents +possible bugs in the code from allowing unauthenticated users to steal +credential data when handling multiple sequential client connections +from different users by creating a separate <tt>imap-login</tt> or +<tt>pop3-login</tt> process for each new connection. + +Edit <tt>/etc/dovecot.conf</tt> and add or correct the following line: +<pre>login_process_per_connection = yes</pre> +</description> +<rationale> +This setting could protect against an attacker trying to exploit a bug in +the dovecot code.</rationale> +<ident cce="4410-7" /> +<oval id="dovecot_login_process_per_conn_yes" /> +</Rule> + +<Rule id="dovecot_mail_drop_priv_before_exec_yes"> +<title>mail_drop_priv_before_exec set to yes</title> +<description>Setting <tt>mail_drop_priv_before_exec = yes</tt>, causes +the <tt>imap-login</tt> or <tt>pop3-login</tt> process will drop +privileges to the userâs ID after authentication and before executing +the <tt>imap</tt> or <tt>pop3</tt> process itself. + +Edit <tt>/etc/dovecot.conf</tt> and add or correct the following line: +<pre>mail_drop_priv_before_exec = yes</pre> +</description> +<rationale> +This setting could protect against privilege escalation by authenticated +users.</rationale> +<ident cce="4371-1" /> +<oval id="dovecot_mail_drop_priv_before_exec_yes" /> +</Rule> + +</Group>  + +<Group id="dovecot_allow_imap_access"> +<title>Allow IMAP Clients to Access the Server</title> +<description>The default iptables configuration does not allow inbound +access to any services. This modification will allow remote hosts to +initiate connections to the IMAP daemon, while keeping all other ports +on the server in their default protected state. + +Edit <tt>/etc/sysconfig/iptables</tt>. Add the following line, ensuring +that it appears before the final <tt>LOG</tt> and <tt>DROP</tt> lines +for the <tt>RH-Firewall-1-INPUT</tt> chain: +<pre>-A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 143 -j ACCEPT</pre> +</description> + +</Group>  + +</Group>  + +</Group>  -- 1.7.7.6

1 0

[PATCH 0/4] M1 IMAP content
by Willy Santos 26 Apr '12

26 Apr '12

These patches are for the initial XCCDF and OVAL content. NOTE: Some of the content here is wrong and corrected in a future patch. I could not figure out how to include the corrections patch with this batch, I will submit it by itself immediately after this one. Willy Santos (4): Added content referenced in Trac ticket #38. OVAL check for disabling plaintext authentication in Dovecot. OVAL check for Dovecot setting login_process_per_connection. OVAL check for Dovecot setting mail_drop_priv_before_exec. .../checks/dovecot_disable_plaintext_auth.xml | 28 ++++ .../checks/dovecot_login_process_per_conn_yes.xml | 28 ++++ .../dovecot_mail_drop_priv_before_exec_yes.xml | 28 ++++ rhel6/src/input/services/imap.xml | 172 +++++++++++++++++++- 4 files changed, 254 insertions(+), 2 deletions(-) create mode 100644 rhel6/src/input/checks/dovecot_disable_plaintext_auth.xml create mode 100644 rhel6/src/input/checks/dovecot_login_process_per_conn_yes.xml create mode 100644 rhel6/src/input/checks/dovecot_mail_drop_priv_before_exec_yes.xml -- 1.7.7.6

1 0

[PATCH 0/1] Added 800-53 content to partition rules.
by Willy Santos 26 Apr '12

26 Apr '12

This commit was missed this morning when others of the kind got committed and ACKd by Shawn Wells. In the interest of preserving this information and working from the the same base, I'm submitting for ACK. See Shawn's commment below on the previous ACK: "Given that we're converting the mappings from NIST over to the CCIs (which get us things like NIST 800-53 and OS SRG for free) these patches will have a short lifespan, however they do provide us with a foundation for identifying what potential CCIs the rules apply to. Ack for the patchset, so that these can provide a base for mapping to appropriate CCIs." Willy Santos (1): Added 800-53 references where missing. rhel6/src/input/system/permissions/partitions.xml | 14 +++++++------- 1 files changed, 7 insertions(+), 7 deletions(-) -- 1.7.7.6

1 2

[PATCH 0/1] M1 SSH content
by Willy Santos 26 Apr '12

26 Apr '12

This patch contains the updated SSH XCCDF and OVAL content referenced in Trac ticket #28 for Milestone 1. Willy Santos (1): Added SSH content and related OVAL check referenced in Trac ticket #28. rhel6/src/input/checks/iptables_sshd_disabled.xml | 42 +++++++++++++++ rhel6/src/input/services/ssh.xml | 59 +++++++++++++++++++++ 2 files changed, 101 insertions(+), 0 deletions(-) create mode 100644 rhel6/src/input/checks/iptables_sshd_disabled.xml -- 1.7.7.6

1 0

Seeking Input - CCI-001488 - What do do when audit fails?
by Shawn Wells 26 Apr '12

26 Apr '12

(apologies if this is a dupe, received a bounce on my original posting) CCI-001488 requires that we do something when the auditd system fails. Right now we have no rules for that. For Red Hat's LSPP profiles we set failure mode to panic. Thoughts? Objections? -Shawn

3 2

attempt 2... Re: Seeking Input: CCI-001459 Remediation - Temp Account Termination
by Shawn Wells 26 Apr '12

26 Apr '12

Received a bounce on my original EMail on this, looks like the interwebs between @redhat.com @fedorahosted.org broke for awhile today.

2 1

Seeking Input: Required packages
by Shawn Wells 26 Apr '12

26 Apr '12

A number of the CCI's state the system shall "support the capability to...", such as "shall have the capability to centralize audit records" in CCI-000154. To ensure we support this capability we need to ensure a certain amount of packages are installed (in this case, audit). I'd like to generate a set of required/recommended packages for a base installation that SSG needs. For example, iptables and audit would be on the top of the list. We've tap danced around the idea of creating a recommended minimum packages before, however now there seems to be a pressing requirement to do so. What are everyone's thoughts on this? I've long been for it. Note we shouldn't say "install *_only_* these packages," but rather "you'll need MINIMALLY these packages to secure your system"

2 1

[PATCH 2/4] OVAL check for disabling plaintext authentication in Dovecot.
by Willy Santos 25 Apr '12

25 Apr '12

Signed-off-by: Willy Santos <wsantos(a)redhat.com> --- .../checks/dovecot_disable_plaintext_auth.xml | 28 ++++++++++++++++++++ 1 files changed, 28 insertions(+), 0 deletions(-) create mode 100644 rhel6/src/input/checks/dovecot_disable_plaintext_auth.xml diff --git a/rhel6/src/input/checks/dovecot_disable_plaintext_auth.xml b/rhel6/src/input/checks/dovecot_disable_plaintext_auth.xml new file mode 100644 index 0000000..ecc4795 --- /dev/null +++ b/rhel6/src/input/checks/dovecot_disable_plaintext_auth.xml @@ -0,0 +1,28 @@ +<def-group> + <definition class="compliance" + id="dovecot_disable_plaintext_auth" version="1"> + <metadata> + <title>Disable Plaintext Authentication in Dovecot</title> + <affected family="unix"> + <platform>Red Hat Enterprise Linux 6</platform> + </affected> + <reference ref_id="CCE-4552-6" source="CCE" /> + <description>Plaintext authentication of mail clients should be disabled.</description> + </metadata> + <criteria comment="Disable Plaintext Authentication in Dovecot"> + <criterion test_ref="test_dovecot_disable_plaintext_auth" /> + </criteria> + </definition> + <ind:textfilecontent54_test check="all" check_existence="all_exist" + comment="Tests the value of the disable_plaintext_auth[\s]*(<:nocomment:>*) setting in the /etc/dovecot.conf file" + id="test_dovecot_disable_plaintext_auth" version="1"> + <ind:object object_ref="obj_dovecot_disable_plaintext_auth" /> + </ind:textfilecontent54_test> + <ind:textfilecontent54_object id="obj_dovecot_disable_plaintext_auth" + version="1"> + <ind:path>/etc</ind:path> + <ind:filename>dovecot.conf</ind:filename> + <ind:pattern operation="pattern match">^[\s]*disable_plaintext_auth[\s]*=[\s]*yes\s*$</ind:pattern> + <ind:instance datatype="int">1</ind:instance> + </ind:textfilecontent54_object> +</def-group> -- 1.7.7.6

1 0

[PATCH 0/1] M1 SSH content
by Willy Santos 25 Apr '12

25 Apr '12

1 0

Seeking Input: CCI-001459 Remediation - Temp Account Termination
by Shawn Wells 25 Apr '12

25 Apr '12

Hey Guys, CCI-001459 requires that temp accounts be terminated after a organizationally defined period of time. Right now we don't have a check/control that implements that. I'd like to add prose that recommends that -ALL- accounts be locked after 60 (or 90... or 120..) days of inactivity. This would allow us to automatically meet CCI-001459 and enforces that inactive accounts should (eventually and automatically) be frozen. Thoughts? My thinking is that 90 days of inactivity is a good number. -Shawn

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

scap-security-guide April 2012