Se você é usuário do memcached e implantou instâncias no Amazon EC2, pode ter recebido uma mensagem da Amazon no fim de semana (nós recebemos uma em 7/8/2010) indicando que você pode ter uma "Possível configuração insegura do Memcached". Aqui está o corpo da mensagem que recebemos:
Enviamos este e-mail para informá-lo de que observamos que você pode estar executando o memcached em uma configuração insegura. Especificamente, notamos que você tem pelo menos um grupo de segurança que permite que toda a Internet tenha acesso à porta mais comumente usada pelo memcached (11211).
Recentemente, a comunidade de segurança tem dado muita atenção à falta de controles de acesso no memcached e, recentemente, algumas explorações foram publicadas. Isso destacou a importância da execução de controles de acesso rigorosos. Embora não tenhamos conhecimento de nenhum acesso não autorizado às suas instâncias do Amazon EC2, acreditamos que sua equipe técnica deva analisar o problema imediatamente.
Sugerimos que você audite suas configurações de grupo de segurança e restrinja o acesso apenas às instâncias e aos endereços IP que precisam de acesso. A maioria dos usuários autoriza apenas outras instâncias do Amazon EC2 a acessar seu servidor memcached. Se precisar acessar seu servidor memcached de fora do Amazon EC2, você também pode autorizar apenas endereços confiáveis a acessar seu grupo de segurança.
Se precisar de assistência adicional, você pode entrar em contato com nossa equipe de Suporte Premium enviando um e-mail para aws-security-support@amazon.com.
Atenciosamente,
A equipe da Amazon Web Services
Excelente e-mail e serviço da equipe da AWS, e a correção sugerida é perfeita.
Esta postagem tem o objetivo de fornecer algumas informações sobre o problema e a aludida "atenção recente" que o problema recebeu. O problema é relevante para todos os usuários do memcached, não apenas para os que estão implementando no Amazon EC2.
A vulnerabilidade
A gênese desse boletim foi quase certamente o resultado do desenvolvimento do go-derper pela equipe da sensepost, destacado no blackhat USA 2010 em 30 de julho de 2010.
A vulnerabilidade destacada pode ser resumida da seguinte forma: se você implantar o memcached em um servidor, deixar a porta TCP na qual o memcached está configurado para escutar (11211, por padrão) exposta à Internet, deixar o protocolo ASCII do memcached ativado E não estiver usando a autenticação SASL com o protocolo binário do memcached, então há uma maneira trivial para que os bandidos recuperem e substituam a maior parte do conteúdo do seu cache. go-derper.rb é um aplicativo Ruby simples, criado pela sensepost, que pode ser usado para explorar a vulnerabilidade.
Eliminação da vulnerabilidade
Vamos examinar a vulnerabilidade, cláusula por cláusula, e destacar o que pode ser feito para eliminá-la, começando pelo topo:
"Se você implantar o memcached em um servidor,"
Pode parecer bobagem considerar isso, mas existem opções. Nem todo mundo precisa implantar e configurar o memcached em um servidor para usar a tecnologia. Se estiver implantando o memcached em uma plataforma de nuvem, por exemplo, você pode simplesmente aproveitar uma imagem pré-construída ou até mesmo um serviço complementar.
Executamos o serviço de complemento do memcached para o Heroku (ele próprio executado na infraestrutura da Amazon), o principal provedor de nuvem de plataforma como serviço para aplicativos Ruby. Como gerenciamos o complemento memcached, nossa profunda experiência com o memcached é implicitamente utilizada em nome dos milhares de aplicativos implantados no Heroku que utilizam nosso complemento memcached.
Além disso, estamos trabalhando em estreita colaboração com nossos amigos da RightScale para disponibilizar imagens pré-configuradas do memcached para aqueles que desejam implementar imagens pré-configuradas do memcached e do base de membrana instâncias no Amazon AWS.
Se você estiver usando uma dessas opções de implementação, garantimos que a configuração é segura.
"[se você] deixar a porta TCP na qual o memcached está configurado para escutar (11211, por padrão) exposta à Internet,"
Se você tiver implantado sua própria instância do memcached, em seu próprio equipamento ou em um ambiente de computação em nuvem, precisará garantir que um firewall esteja protegendo o sistema.
A Amazon fornece um rico conjunto de recursos para expressar e aplicar o controle de acesso para instâncias em execução no EC2.
O cofundador da NorthScale, Dustin Sallings, também se manifestou no fim de semana. blog fornece muitos detalhes adicionais, especialmente com relação ao firewall.
"[se você] deixar o protocolo ASCII do memcached ativado,"
Conforme desenvolvido, o exploit go-derper depende do uso do protocolo ASCII.
O Memcached fornece um protocolo ASCII e um protocolo binário. O protocolo binário foi co-desenvolvido pelo próprio Trond Norbye, da NorthScale, enquanto trabalhava na SUN Microsystems.
O fato dessa vulnerabilidade é que ela também existe no protocolo binário, mas o protocolo binário oferece suporte à autenticação e ao controle de acesso, fornecendo um mecanismo para proteger os dados.
O protocolo ASCII, o protocolo original desenvolvido para o memcached, não tem nenhum recurso de autenticação ou controle de acesso e, portanto, não é adequado para uso na Internet pública. Esse protocolo foi desenvolvido explicitamente para uso atrás de um firewall, como um sistema protegido de "back-end".
No caso improvável de você ter algum bom motivo para disponibilizar a porta do memcached para qualquer host na Internet pública, mas desejar controlar o acesso aos dados, desative o suporte ao protocolo ASCII (e ative a autenticação SASL no protocolo binário, conforme descrito a seguir). A distribuição NorthScale do memcached facilita a configuração do memcached para NÃO vincular o ouvinte do protocolo ASCII à porta do memcached.
"E [se] você não estiver usando a autenticação SASL com o protocolo binário do memcached,"
Conforme mencionado acima, o protocolo binário do memcached em versões recentes do memcached oferece suporte à autenticação e à autorização de acesso por meio do protocolo SASL.
A distribuição NorthScale do memcached facilita muito o aproveitamento desse recurso. A criação de um novo "bucket" em nossa distribuição do memcached fornece o recurso de multilocação (permitindo que vários aplicativos se vinculem com segurança a um único cluster do memcached) e serve como veículo para a vinculação de credenciais SASL. É esse recurso que nos permite oferecer suporte seguro a milhares de usuários adicionais do memcached no Heroku sem executar milhares de servidores individuais.
Se você estiver usando uma versão mais antiga do memcached (a maioria das distribuições Linux vem com versões antiquadas do software) e precisar de suporte a acesso autenticado, deverá procurar uma versão mais recente do software. Eu certamente recomendo nossa distribuição.
O contexto histórico do memcached
A vulnerabilidade não é surpreendente. O memcached foi criado inicialmente por Brad Fitzpatrick para uso no LiveJournal, em um ambiente em que o controle sobre os servidores e a segurança da rede era gerenciado por uma equipe competente de administradores de sistemas. Com muitas linhas de defesa à frente do memcached, não havia necessidade de criar mais uma camada de segurança no próprio memcached, cujo preço inevitável seria o esforço de desenvolvimento (esforço mais bem gasto na criação de recursos para blogs) e o desempenho (em um ambiente em que muitos milhões de transações do memcached são processadas por dia, e cada microssegundo conta).
Em um mundo perfeito, todas as pessoas que desenvolvem e implantam software deveriam entender completamente as características de todos os componentes subjacentes da infraestrutura de software dos quais seu software depende; ter um sólido entendimento de segurança de rede, formulação e aplicação de políticas; e auditar regularmente seu ambiente operacional enquanto rastreiam ameaças emergentes. Poucos sistemas seriam implantados. Na verdade, acho que é justo dizer que alguns dos aplicativos da Web mais populares da Internet atualmente nunca teriam visto a luz do dia sob essas restrições.
No mundo real, há muitos softwares interessantes sendo desenvolvidos e implantados por pessoas que não são, e que frequentemente não têm recursos para contratar, administradores de sistema experientes e especialistas em segurança de rede. Elas só querem colocar seu software ou serviço nas mãos do maior número possível de usuários, o mais rápido possível. Se e quando os bilhões de operações por segundo se materializarem, então os microssegundos poderão ser extraídos, esperamos que por uma equipe competente de administradores de sistemas que a organização possa atrair e pagar.
Uma observação sobre a computação em nuvem
Em última análise, essa é uma das promessas da computação em nuvem, conforme descrito em um de nossos white papers. A computação em nuvem não se trata apenas de transformar capital em despesas operacionais ou de aproveitar as economias de escala dos provedores de serviços. Os provedores de hospedagem gerenciada têm feito isso há mais de uma década. Em última análise, a computação em nuvem permite que os desenvolvedores de software desenvolvam e implantem software sem precisar adquirir conhecimento especializado em administração de sistemas e segurança de rede. Em última análise, o mundo é um lugar melhor como resultado. Mais desenvolvedores são capacitados para criar e fornecer soluções de software.
A Amazon demonstrou parte do valor que fornece à sua base de clientes: ela rastreou uma vulnerabilidade recém-destacada que é amplamente relevante (dada a ampla implantação do memcached) para seus usuários, identificou usuários específicos em risco (possível, dados os metadados usados para configurar as instâncias de máquinas virtuais que, em última análise, são a base dos sistemas em execução no EC2) e os notificou em tempo hábil sobre como lidar com o problema. Sério valor agregado.
Onde você obtém o memcached?
A equipe da NorthScale fornece a grande maioria do código-fonte contribuído para os projetos de código aberto memcached e membase. Respeitamos o desejo claramente expresso pela comunidade maior de desenvolvimento do memcached de que o núcleo do memcached deve permanecer bruto, rápido e mais adequado para aqueles que sabem o que estão fazendo.
Também disponibilizamos versões comercialmente suportadas, certificadas e menos "brutas" desses sistemas, facilitando a implantação, a configuração, a segurança e o gerenciamento do software pelas organizações. Embora a comunidade de desenvolvimento do memcached não queira que a base de código seja poluída com recursos de "facilidade de uso", há uma comunidade potencial muito maior de usuários do software que ficará melhor com a presença desses recursos. O mesmo vale para coisas como replicação e reconfiguração de cluster ao vivo. Muitos usuários desejam esses recursos, mas a comunidade principal prefere mantê-los fora do memcached propriamente dito. Nós os disponibilizamos gratuitamente em nossa distribuição e disponibilizamos o código-fonte em projetos relacionados (por exemplo, http://github.com/northscale/bucket_engine).
