멤캐시드 사용자이고 Amazon EC2에 인스턴스를 배포한 경우, 주말(2010년 8월 7일에 받은 메시지)에 Amazon으로부터 "안전하지 않은 멤캐시드 구성이 있을 수 있습니다."라는 메시지를 받았을 수 있습니다. 다음은 저희가 받은 메시지 본문입니다:
안전하지 않은 구성으로 memcached를 실행하고 있을 수 있음을 알려드리기 위해 이 이메일을 보냈습니다. 특히, 전체 인터넷이 memcached에서 가장 일반적으로 사용하는 포트(11211)에 액세스할 수 있도록 허용하는 보안 그룹이 하나 이상 있는 것으로 확인되었습니다.
최근 보안 커뮤니티에서는 멤캐시에 대한 접근 제어가 부족하다는 점에 대해 많은 관심을 기울이고 있으며, 최근 몇 가지 익스플로잇이 공개되기도 했습니다. 이로 인해 엄격한 액세스 제어를 통한 실행의 중요성이 강조되었습니다. Amazon EC2 인스턴스에 대한 무단 액세스는 아직 확인되지 않았지만, 기술팀에서 즉시 이 문제를 검토해야 한다고 생각합니다.
보안 그룹 설정을 감사하고 액세스가 필요한 인스턴스와 IP 주소로만 액세스를 제한하는 것이 좋습니다. 대부분의 사용자는 다른 Amazon EC2 인스턴스만 멤캐시된 서버에 액세스할 수 있도록 승인합니다. Amazon EC2 외부에서 멤캐시드 서버에 액세스해야 하는 경우, 신뢰할 수 있는 주소만 보안 그룹에 액세스하도록 승인할 수도 있습니다.
추가 지원이 필요한 경우 다음 주소로 이메일을 보내 프리미엄 지원팀에 문의할 수 있습니다. aws-security-support@amazon.com.
감사합니다,
아마존 웹 서비스 팀
AWS 팀의 훌륭한 이메일과 서비스, 그리고 제안된 수정 사항이 적중했습니다.
이 포스팅은 이 문제에 대한 배경 지식과 이 문제가 "최근 주목받고 있는" 암시적인 내용을 제공하기 위한 것입니다. 이 문제는 Amazon EC2에 배포하는 사용자뿐만 아니라 멤캐시드의 모든 사용자와 관련이 있습니다.
취약점
이 게시판의 탄생은 센스포스트 팀이 고더퍼를 개발한 것이 거의 확실합니다. 블랙햇 USA 2010 컨퍼런스에서 2010년 7월 30일에 개최되었습니다.
강조 표시된 취약점은 다음과 같이 요약할 수 있습니다. 서버에 memcached를 배포하고, memcached가 수신하도록 구성된 TCP 포트(기본적으로 11211)를 인터넷에 노출된 상태로 두고, memcached ASCII 프로토콜을 사용하도록 설정하고, memcached 이진 프로토콜로 SASL 인증을 사용하지 않는 경우 악당이 캐시의 내용 대부분을 검색하고 대체할 수 있는 간단한 방법이 존재한다는 것입니다. go-derper.rb 는 센스포스트에서 만든 간단한 루비 애플리케이션으로, 취약점을 익스플로잇하는 데 사용할 수 있습니다.
취약점 제거
취약점을 조항별로 살펴보고 취약점을 제거하기 위해 무엇을 할 수 있는지 맨 위부터 살펴보자:
"서버에 멤캐시를 배포하는 경우"
생각하기에 따라서는 어리석어 보일 수도 있지만 실제로는 여러 가지 옵션이 있습니다. 멤캐시드 기술을 사용하기 위해 모든 사람이 직접 서버에 배포하고 구성해야 하는 것은 아닙니다. 예를 들어 클라우드 플랫폼에 멤캐시를 배포하는 경우 미리 구축된 이미지나 애드온 서비스를 활용하면 됩니다.
당사는 루비 애플리케이션을 위한 선도적인 서비스형 플랫폼 클라우드 제공업체인 Heroku(자체적으로 Amazon 인프라에서 실행됨)를 위한 memcached 애드온 서비스를 운영합니다. 멤캐시드 애드온을 관리하기 때문에, 멤캐시드 애드온을 활용하는 Heroku에 배포된 수천 개의 애플리케이션을 대신하여 멤캐시에 대한 심층적인 전문 지식이 암묵적으로 제공됩니다.
또한, 사전 구성된 멤캐시드 이미지를 배포하고자 하는 사용자를 위해 사전 구성된 멤캐시드 이미지를 사용할 수 있도록 RightScale과 긴밀히 협력하고 있습니다. 멤베이스 인스턴스를 생성합니다.
이러한 배포 옵션 중 하나를 사용하는 경우 구성이 안전한지 확인했습니다.
"[멤캐시가 수신하도록 구성된 TCP 포트(기본값 11211)를 인터넷에 노출된 상태로 두는 경우]"
자체 장비 또는 클라우드 컴퓨팅 환경에 멤캐시드 인스턴스를 배포한 경우 방화벽이 시스템을 보호하고 있는지 확인해야 합니다.
Amazon은 EC2에서 실행되는 인스턴스에 대한 액세스 제어를 표현하고 적용하기 위한 다양한 기능을 제공합니다.
노스케일의 공동 창업자 더스틴 살링스(Dustin Sallings)도 주말 동안 의견을 보탰습니다. 블로그 는 특히 방화벽과 관련하여 훌륭한 추가 세부 정보를 제공합니다.
"[멤캐시드 ASCII 프로토콜을 활성화한 상태로 두면]"
빌드된 대로, go-derper 익스플로잇은 ASCII 프로토콜의 사용에 의존합니다.
멤캐시드는 ASCII 프로토콜과 바이너리 프로토콜을 모두 제공합니다. 바이너리 프로토콜은 노스케일의 트론드 노비가 SUN 마이크로시스템즈에서 근무할 당시 공동 개발했습니다.
이 취약점은 바이너리 프로토콜에도 존재하지만, 바이너리 프로토콜은 인증 및 액세스 제어를 지원하여 데이터를 보호하는 메커니즘을 제공한다는 것이 사실입니다.
멤캐시드용으로 개발된 원래 프로토콜인 ASCII 프로토콜은 인증이나 액세스 제어 기능이 없으므로 공용 인터넷에 걸기에는 적합하지 않습니다. 이 프로토콜은 방화벽 뒤에서 '백엔드' 보호 시스템으로 사용하기 위해 명시적으로 개발되었습니다.
퍼블릭 인터넷의 모든 호스트가 memcached 포트를 사용할 수 있도록 해야 하지만 데이터에 대한 액세스를 제어하려는 경우, ASCII 프로토콜 지원을 비활성화해야 합니다(다음에 설명된 대로 바이너리 프로토콜에서 SASL 인증을 활성화해야 합니다). 멤캐시의 노스스케일 배포를 사용하면 멤캐시드 포트에 ASCII 프로토콜 리스너를 바인딩하지 않도록 멤캐시를 쉽게 구성할 수 있습니다.
"그리고 멤캐시드 바이너리 프로토콜로 SASL 인증을 사용하지 않는 경우"
위에서 언급했듯이, 최신 버전의 memcached 바이너리 프로토콜은 SASL 프로토콜을 통한 인증 및 접근 권한 부여를 지원합니다.
멤캐시드의 노스스케일 배포를 사용하면 이 기능을 매우 쉽게 활용할 수 있습니다. memcached 배포에 새로운 "버킷"을 생성하면 멀티테넌시 기능(여러 애플리케이션이 단일 memcached 클러스터에 안전하게 바인딩할 수 있도록 함)과 SASL 자격 증명 바인딩을 위한 수단 역할을 모두 제공합니다. 이 기능 덕분에 수천 대의 개별 서버를 실행하지 않고도 수천 명의 멤캐시드 애드온 사용자를 Heroku에서 안전하게 지원할 수 있습니다.
구 버전의 멤캐시드(대부분의 리눅스 배포판에는 구 버전의 소프트웨어가 함께 제공됨)를 사용 중이고 인증된 액세스 지원이 필요한 경우 최신 버전의 소프트웨어를 살펴봐야 합니다. 저는 확실히 저희 배포판을 추천합니다.
멤캐시된 역사적 맥락
이 취약점은 놀라운 일이 아닙니다. 멤캐시드는 처음에 서버와 네트워크 보안을 숙련된 시스템 관리자 팀이 관리하는 환경에서 Brad Fitzpatrick이 LiveJournal에서 사용하기 위해 구축했습니다. 멤캐시드 앞에 많은 방어선이 있기 때문에 멤캐시드 자체에 또 다른 보안 계층을 구축할 필요가 거의 없었으며, 그 대가는 개발 노력(블로그 기능을 구축하는 데 더 많은 노력을 기울여야 함)과 성능(하루에 수백만 개의 멤캐시드 트랜잭션이 처리되고 마이크로초 단위가 중요한 환경에서는)이 불가피하게 희생될 수밖에 없었습니다.
완벽한 세상이라면 소프트웨어를 개발하고 배포하는 모든 사람이 소프트웨어가 의존하는 모든 기본 소프트웨어 인프라 구성 요소의 특성을 완전히 이해하고, 네트워크 보안, 정책 수립 및 정책 시행에 대해 확고하게 이해하고, 새로운 위협을 추적하면서 운영 환경을 정기적으로 감사해야 합니다. 배포되는 시스템은 거의 없습니다. 사실, 오늘날 인터넷에서 가장 인기 있는 웹 애플리케이션 중 일부는 이러한 제약 조건이 없었다면 빛을 보지 못했을 것이라고 해도 과언이 아닐 것입니다.
실제 세계에서는 숙련된 시스템 관리자나 네트워크 보안 전문가를 고용할 자원이 없는 사람들이 흥미로운 소프트웨어를 개발하고 배포하는 경우가 많습니다. 이들은 가능한 한 많은 사용자에게 가능한 한 빨리 소프트웨어나 서비스를 제공하기를 원할 뿐입니다. 초당 수십억 건의 작업이 현실화되면 유능한 시스템 관리자 팀이 조직이 유치하고 감당할 수 있는 비용으로 마이크로초 단위의 작업을 처리할 수 있기를 희망합니다.
클라우드 컴퓨팅에 대한 부연 설명
이는 궁극적으로 클라우드 컴퓨팅의 백서에서 설명한 바와 같이 클라우드 컴퓨팅의 약속 중 하나입니다. 클라우드 컴퓨팅은 단순히 자본을 운영 비용으로 전환하거나 서비스 제공업체의 규모의 경제를 활용하는 것에 그치지 않습니다. 관리형 호스팅 제공업체는 10년 넘게 이를 수행해 왔습니다. 클라우드 컴퓨팅은 궁극적으로 소프트웨어 개발자가 시스템 관리 및 네트워크 보안에 대한 전문 지식을 쌓지 않고도 소프트웨어를 개발 및 배포할 수 있도록 지원합니다. 그 결과 세상은 궁극적으로 더 나은 곳이 되었습니다. 더 많은 개발자가 소프트웨어 솔루션을 구축하고 제공할 수 있는 역량을 갖추게 됩니다.
(멤캐시의 광범위한 배포를 고려할 때) 사용자들에게 널리 관련성이 있는 새로 부각된 취약점을 추적하고, 위험에 처한 특정 사용자를 식별하고(궁극적으로 EC2에서 실행 중인 시스템의 기반이 되는 가상 머신 인스턴스를 구성하는 데 사용되는 메타데이터를 고려할 때 가능) 적시에 문제 해결 방법을 정확히 알려주는 등 Amazon은 고객 기반에 제공하는 가치의 일부를 입증했습니다. 상당한 부가가치를 창출합니다.
멤캐시는 어디서 구하나요?
노스케일 팀은 멤캐시드 및 멤베이스 오픈 소스 프로젝트에 기여한 소스 코드의 대부분을 제공합니다. 우리는 멤캐시드의 핵심은 원시적이고 빠르며 자신이 무엇을 하고 있는지 아는 사람들에게 가장 적합해야 한다는 대규모 멤캐시드 개발 커뮤니티의 분명한 열망을 존중합니다.
또한 상업적으로 지원되고 인증된, '원시'가 아닌 버전의 시스템을 제공함으로써 조직이 소프트웨어를 더 쉽게 배포, 구성, 보안 및 관리할 수 있도록 합니다. 멤캐시드 개발 커뮤니티는 코드 베이스가 '사용 편의성' 기능으로 오염되는 것을 원하지 않지만, 이러한 기능이 있으면 훨씬 더 많은 잠재적 소프트웨어 사용자 커뮤니티가 더 큰 이득을 볼 수 있습니다. 복제 및 실시간 클러스터 재구성 같은 기능도 마찬가지입니다. 많은 사용자가 이러한 기능을 원하지만, 핵심 커뮤니티는 이러한 기능을 멤캐시드에서 제외하는 것을 선호합니다. 저희는 배포판에서 이러한 기능을 자유롭게 사용할 수 있도록 하고 관련 프로젝트(예: http://github.com/northscale/bucket_engine)에서 소스 코드를 제공합니다.
