[Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris]

Lloyd L Chambers Lloyd.Chambers at sun.com
Tue Feb 26 09:52:53 PST 2008


No, I'm just suggesting that ANY non-loopback port is a risk, and  
issuing a warning would be worthwhile:

NOTE:  port dddd is a non-local port.  Be sure your firewall setup  
blocks inappropriate access to this port.

On Feb 25, 2008, at 12:29 PM, Roy Lyseng wrote:

>
>
> Lloyd L Chambers wrote:
>> Roy,
>> Thanks.  Does memcached issue a warning in the log if it starts  
>> listening on ports at risk?
>
> No. Do you know a way to identify ports that are at risk? I guess we  
> would need to communicate with firewalls in order to do this.
>
> Roy
>> 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

---
Lloyd L Chambers
lloyd.chambers at sun.com
Sun Microsystems, Inc






More information about the opensolaris-arc mailing list