RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1550654 - Add memcached to Securing Services section of guide
Summary: Add memcached to Securing Services section of guide
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: doc-Security_Guide
Version: 7.6
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: ---
Assignee: Mirek Jahoda
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks: 1594318
TreeView+ depends on / blocked
 
Reported: 2018-03-01 17:29 UTC by Clifford Perry
Modified: 2021-06-10 14:59 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-03-07 13:41:40 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Clifford Perry 2018-03-01 17:29:31 UTC
Document URL: 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/security_guide/index#sect-Security_Guide-Available_Network_Services-Insecure_Services

Section Number and Name: 4.3 Securing Services

Describe the issue: 
During the last week of February 2018 various articles, including update to CERT advisory, were published for DDOS attacks taking place due to memcached instances being deployed insecurely. 

Proposed is new text for a new subsection on the topic of memcached usage. 

Suggestions for improvement: 


## Configure a firewall
First and foremost setup a firewall in your LAN if memcached servers should be
accessible only from within your local network. Do not allow external traffic
to ports used by memcached (e.g. 11211 by default).

## Disable UDP
Add "-U 0 -p 11211" to OPTIONS var in your /etc/sysconfig/memcached file.

If applications are not using UDP, this is just a server-side change that does
not affect clients connected to memcached. If you don't really need UDP, please
consider switching to TCP connections for your memcached server. Otherwise, if
you do need UDP and you do need remote access to memcached servers, consider
configuring a firewall to protect memcached servers from external accesses.

## Listen to localhost traffic only
Add "-l 127.0.0.1,::1" to OPTIONS var in your /etc/sysconfig/memcached file.

If you are just using a single memcached server configured on the same machine
as your application, you may want to limit memcached to only listen to the
local interface. This does not work if you need access from other machines.


*** Additional Hardening suggestions which we may or may not want to include are: 

## Provide authentication with SASL
If changing the application is a possibility, consider adding authentication
through SASL (this is currently supported only memcached versions provided in
RHEL 7.3 and RHEL 7.4).

On the server, modify or add in /etc/sasl2/memcached.conf:
	sasldb_path: /tmp/memcached.sasldb

Add an account in the database:
	saslpasswd2 -a memcached -c cacheuser -f /tmp/memcached.sasldb

And ensure the database is accessible from the memcached user/group.

Enable SASL support by adding "-S" to your /etc/sysconfig/memcached file and
restart the memcached server if necessary.

In your applications, add the right username/password to the memcached client
configuration. This step is different depenending on the client you are
running. Most available libraries right now support only the PLAIN mechanism,
so username and password will be transferred unencrypted over the network.
Although not ideal, this solutions may prevent DDoS attacks at large, since an
attacker would need to sniff the credentials before doing requests to the
server.

## Encrypt communication with stunnel
Your memcached server may contain sensitive data. By default memcached does not
make any effort to protect your data, because it was designed to run on a local
network. However it's more common nowadays to have memcached servers in the
cloud and not all providers provide VPN and/or TLS support.

Since memcached does not support TLS by default, a workaround is to use a proxy
which provides TLS on top of the memcached protocol.

One such proxy is stunnel[1]. When installed on the server, it intercepts all
the traffic directed to the memcached server and encrypts/decrypts it with a
key. Clients, on the other hand, need another stunnel proxy so that
applications do not need to be changed to support TLS, because all the traffic
exchanged with the memcached server will pass through the local proxy, which
will send/receive encrypted messages with the proxy on the server's end.

This solution works only with the TCP protocol.

An easy way to configure stunnel is to use TLS-PSK. On the server modify or
create the /etc/stunnel/stunnel.conf file:
	pid = /var/run/stunnel.pid

	[memcached]
	accept = <public-ip>:11211
	connect = 127.0.0.1:11211
	ciphers = PSK
	PSKsecrets = /etc/stunnel/psk.txt

And create the file /etc/stunnel/psk.txt with the following content:
	user1:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

where you add as many users as you need, with the PSK secrets on the right side.

On the client, install stunnel and modify or create the
/etc/stunnel/stunnel.conf file:
	client = yes
	pid = /var/run/stunnel.pid

	[memcached]
	connect = <public-ip>:11211
	accept = 127.0.0.1:11211
	PSKsecrets = /etc/stunnel/psk.txt

And create the file /etc/stunnel/psk.txt with the right credentials:
	user1:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

You could also use certificates instead of Pre Shared Keys.
In this way, only authenticated users can reach your memcached servers and, as
a plus, your traffic is encrypted.

[1] https://www.stunnel.org/

Additional information: 
I've added Riccardo from the Product Security team to cc, who gathered this information.

Comment 2 Clifford Perry 2019-02-21 09:56:34 UTC
Riccardo, care to take a look? 

Thanks!

Comment 7 Mirek Jahoda 2019-03-07 13:41:40 UTC
Thank you all for your help.

The new section how to secure memcached is now available on the Customer Portal:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/security_guide/index#sec-Securing_memcached_against_DDoS_Attacks


Note You need to log in before you can comment on or make changes to this bug.