[Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris]
Roy Lyseng
Roy.Lyseng at sun.com
Tue Feb 26 09:59:38 PST 2008
Lloyd L Chambers wrote:
> 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.
Not sure if I appreciate this. Setting up memcached to listen on a
loopback interface does not make sense, as it is always used in
machine-to-machine communication. Is there any other product that
actually do this?
BTW, I guess you really mean interface, and not port?
Thanks,
Roy
>
> 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