Roy, Thanks. Does memcached issue a warning in the log if it starts listening on ports at risk?
Lloyd On Feb 25, 2008, at 2:20 AM, Roy Lyseng wrote: > 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 --- Lloyd L Chambers lloyd.chambers at sun.com Sun Microsystems, Inc
