Hi Lloyd, it is indeed possible to configure memcached to listen to local addresses only. If the administrator decides to configure memcached to listen on a publicly available address, a security hole may be opened.
There was a substantial discussion on Memcached and security during the first ARC case (LSARC/2007/385). These issues were raised during that case (followed by my responses): Terrence Miller wrote: > tm-1 Can the client and server be on the same machine. If so, > can that system be configured to not accept requests > from the network. The server may be configured to listen on a user-defined port. A firewall may be configured to block that port. You can also configure memcached to listen on a specific interface, in particular the localhost interface. > > tm-2 Can an attack on the server cause it to overload its host > machine. I think that will be very difficult. Processing overhead is very light, it is actually more probable that the attacker will saturate the network. Besides, the memcached server is usually part of a backend system, residing on the same level as a backend database server and having an application server or web server in front. An attacker may attempt to fill the cache with garbage objects that invalidate the "valid" objects. This may become a problem if the attacker gets network access to the memcached server. > > tm-3 Does your documentation state the requirement for protecting > any network connecting clients to server. We do not provide documentation in addition to that provided by the community. > > tm-4 How hard is it to write a firewall rule that blocks all > memcached traffic. The server is usually listening on a single TCP socket, so it should be easy to write a firewall rule that blocks the associated port. As an option, the memcached server may also listen on a UDP socket, but this can also easily be protected. > > tm-5 Will the firewall requirements change with new releases. Impossible to say. The community designs and implements changes to the product. We ended up adding information to release notes that warn administrators about potential security holes when listening on publicly available ports. Hope this answers your questions, Roy James Gates wrote: > > > -------- Original Message -------- > Subject: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris > Date: Fri, 22 Feb 2008 11:04:10 -0800 > From: Lloyd L Chambers <Lloyd.Chambers at Sun.COM> > To: James Gates <James.Gates at Sun.COM> > CC: Dan Mick <Dan.Mick at Sun.COM>, lsarc-ext at Sun.COM > References: <47BC5F15.3050205 at sun.com> <47BC8D4A.2000804 at sun.com> > <47BC97BB.8020607 at sun.com> <Pine.GSO.4.61.0802201416370.1507 at izimbra> > <47BCCD03.9060108 at sun.com> <47BDAF65.1030802 at sun.com> > > Sounds terrific! > > llc01 Are there any security issues with the memcached daemons, given > that they're listening on ports? If I understand correctly, 10.0.0.x > is a LAN address, which exposes the IP only to the local subnet. > Still, can you say if there are concerns here? > > Lloyd Chambers > LSARC > > > On Feb 21, 2008, at 9:05 AM, James Gates wrote: > >> I've added the following summary to the details section of the 1pager: >> >> memcached is a high-performance, distributed memory object >> caching >> system, generic in nature, but intended for use in speeding up >> dynamic web applications by alleviating database load. >> >> Danga Interactive developed memcached to enhance the speed of >> LiveJournal.com, a site which was already doing 20 million+ >> dynamic page views per day for 1 million users with a bunch of >> webservers and a bunch of database servers. memcached dropped the >> database load to almost nothing, yielding faster page load times >> for users, better resource utilization, and faster access to the >> databases on a memcache miss. >> >> How it Works >> >> First, you start up the memcached daemon on as many spare >> machines >> as you have. The daemon has no configuration file, just a few >> command line options, only 3 or 4 of which you'll likely use: >> >> # ./memcached -d -m 2048 -l 10.0.0.40 -p 11211 >> >> This starts memcached up as a daemon, using 2GB of memory, and >> listening on IP 10.0.0.40, port 11211. Because a 32-bit process >> can only address 4GB of virtual memory (usually significantly >> less, depending on your operating system), if you have a 32-bit >> server with 4-64GB of memory using PAE you can just run multiple >> processes on the machine, each using 2 or 3GB of memory. >> >> Now, in your application, wherever you go to do a database query, >> first check the memcache. If the memcache returns an undefined >> object, then go to the database, get what you're looking for, and >> put it in the memcache. >> >> >> Dan Mick wrote: >>> David.Comay at Sun.COM wrote: >>>>> I have asked Roy to provide a one paragraph summary that I can add to >>>>> the 1pager. But in the meantime, you can read >>>>> http://www.danga.com/memcached/ and >>>>> http://en.wikipedia.org/wiki/Memcached >>>> >>>> >>>> Also as this is a version update to a previous case, you can find out >>>> more about memcached by looking at the earlier case, LSARC/2007/385. >>>> In particular, >>>> >>>> LSARC/2007/385/commitment.materials.final/questionnaire.txt >>>> >>>> dsc >>> yes, although one sentence in the current case is pretty low-cost. > > --- > Lloyd L Chambers > lloyd.chambers at sun.com > Sun Microsystems, Inc > > >
