%EB%A5%BC%20%EC%8B%A4%ED%96%89%ED%95%98%EB%8A%94%20%EA%B2%83%EC%9D%B4%20%EC%99%9C%20%EC%A4%91%EC%9A%94%ED%95%9C%EA%B0%80%EC%9A%94%3F%20%EC%95%84%EB%8B%88%EB%A9%B4%20%EA%B7%B8%EB%A0%87%EC%A7%80%20%EC%95%8A%EC%9D%84%20%EC%88%98%EB%8F%84%20%EC%9E%88%EB%82%98%EC%9A%94%3F.png)
저는 바인드를 사용하고 있는데 왜 이 소프트웨어가 chroot에서 실행되는 CentOS에 있는지 궁금해지기 시작했습니다. 오해하지 마세요. 저는 바인드가 무엇인지, chroot(감옥)이 무엇인지 알고 있습니다. 하지만 내 주요 질문은 chroot 없이 바인드를 실행하는 것이 매우 안전하지 않다는 것입니다.
감옥 없이(다른 서비스나 소프트웨어보다) 설정하는 것이 정말 해로운가요? 시스템에는 chroot 없이 실행되는 많은 프로세스가 있으며 그 중 하나를 손상시키는 것은 매우 위험하다고 생각합니다. 하지만 chroot 없이 실행되는 다른 소프트웨어보다 명명된 프로세스가 더 위험한 이유는 무엇입니까?
답변1
@Some Guy가 언급했듯이 역사적 관점에서 이에 대해 생각해야 합니다.
역사적 관점에서는 단일 하드웨어가 단일 운영 체제 하에서 수십 가지의 다양한 서비스를 제공한다는 것이었습니다. 하나의 서비스가 손상되면 해당 하드웨어의 모든 것이 손상됩니다.
가상화를 사용하면 이는 문제가 훨씬 줄어듭니다. VM에서 탈출하는 것이 불가능하지는 않지만 결코 사소한 일이 아닙니다. 루트 권한으로 실행 중인 프로세스가 chroot에서 벗어나는 것보다 VM에서 벗어나는 것이 확실히 더 어렵습니다. 그래서 내 바인드 서버는 자체 VM에서 실행되고 있습니다. VM이라는 사실만으로 손상이 이미 제한되어 있기 때문에 이 경우 chroot에는 별 의미가 없습니다.
chroot는 VM과 같은 것을 생성하려는 매우 약한 시도입니다. Chroot는 루트 권한이 있는 모든 프로세스에서 탈출할 수 있습니다. chroot는 의도된 것이 아니며 보안 메커니즘으로 작동하지 않습니다. BSD 감옥 또는 LXC가 있는 chroot는 OS 수준 가상화를 제공하고 보안 기능을 제공합니다. 그러나 요즘에는 전체 시스템의 새 VM을 가동하는 것이 너무 쉽기 때문에 이러한 목적을 위해 OS 수준 가상화 도구를 설정하거나 사용하는 방법을 배우는 것은 노력할 가치가 없을 수도 있습니다.
이전 버전의 바인드는 권한을 삭제하지 않았습니다. Unix에서는 루트 계정만 1024 미만의 포트를 열 수 있으며 우리 모두 알고 있듯이 Bind는 udp/53 및 tcp/53을 수신해야 합니다. Bind는 루트로 시작하고 권한을 삭제하지 않으므로 어떠한 손상도 전체 시스템이 손상될 수 있음을 의미합니다. 요즘 거의 모든 소프트웨어는 소켓을 열고 루트 권한이 필요한 다른 작업을 수행한 다음 실행 중인 사용자를 권한이 없는 계정으로 변경합니다. 권한이 삭제되면 손상으로 인한 영향이 호스트 시스템에 훨씬 낮아집니다.
답변2
다른 답변은 꽤 좋지만 레이어 보안 개념을 언급하지 못했습니다. 시스템에 추가하는 모든 보안 계층은 공격자가 극복해야 하는 또 다른 계층입니다. chroot에 BIND를 넣으면 장애물이 하나 더 추가됩니다.
BIND에 악용 가능한 취약점이 있고 누군가가 임의의 코드를 실행할 수 있다고 가정해 보겠습니다. chroot에 있는 경우 시스템의 다른 항목에 도달하기 전에 해당 chroot에서 벗어나야 합니다. 언급했듯이 chroot를 깨기 위해서는 루트 권한이 필요합니다. BIND는 루트로 실행되지 않으며 chroot에서 사용할 수 있는 최소한의 도구가 있어야 하며 옵션을 더욱 제한하고 본질적으로 시스템 호출만 남겨 둡니다. 권한 상승을 위한 시스템 호출이 없으면 공격자는 DNS 레코드를 계속 살펴보고 있는 것입니다.
앞서 언급한 상황은 SomeGuy가 언급한 것처럼 다소 가능성이 낮습니다. BIND는 요즘 취약점이 거의 없으며 대부분 원격 실행이 아닌 DoS 유형 시나리오로 제한됩니다. 즉, chroot에서 실행하는 것은 상당수의 OS에서 기본 구성이므로 약간씩 강화된 보안을 유지하기 위해 사용자가 노력할 가능성은 거의 없습니다.
답변3
전문
사람들이 인터넷을 통해 오해를 반복하고 있다는 소식이 계속 들립니다. 따라서 좀 더 명확하게 설명하려고 노력하겠습니다.
우선;얼마나 많은 우연한 발견이 있었습니까?원인과 결과, 결국 뭔가에 이용당하게 됐어요다른의도한 목적보다?
Chroot 감옥은 무엇이었고 무엇입니까?
Chroot는 처음에 프로세스나 사용자의 루트 디렉터리를 변경하도록 설계되었습니다(알 수 없는 소스에서 소프트웨어를 컴파일하는 데 적합). 이것은 제공보안기본 시스템뿐만 아니라 간편한 청소를 포함한 빠른 테스트 베드 기기에도 적용됩니다. 그로부터 몇 년이 지났고, 개념과 암시된 용도도 마찬가지로 확실히 바뀌었습니다.
chroot가 사용되었습니다효과적으로이며 코드 베이스에 직접 포함되어 있습니다.여러 개의프로그램 및 라이브러리(예: openSSHd, apache2 + mod_security2/mod_chroot, dovecot, sendmail, openVPN, pam_chroot,그리고 훨씬 더). 이러한 모든 주류 애플리케이션이 잘못된 보안 솔루션을 구현했다고 가정하는 것은 단지사실이 아니다
chroot는 파일 시스템 가상화에 대한 솔루션입니다. 그 이상도 이하도 아닙니다. chroot 감옥에서 프로세스를 실행하는 지침을 준수하는 한 chroot에서 쉽게 벗어날 수 있다는 가정도 사실이 아닙니다.
chroot 감옥을 보호하기 위한 몇 가지 단계
즉, 그렇습니다아니다프로세스를 ROOT로 실행합니다. 이로 인해 루트 에스컬레이션 벡터가 열릴 수 있습니다(chroot 내부 또는 외부에서도 마찬가지). 프로세스를 실행하지 마십시오내부에다른 프로세스와 동일한 사용자를 사용하는 chroot밖의chroot. 공격 표면을 제한하고 개인정보를 보호하기 위해 각 프로세스와 사용자를 자신의 Chroot로 분리합니다. 필요한 파일, 라이브러리, 장치만 마운트하세요. 마지막으로 chroot는 기본 시스템 보안을 대체하지 않습니다. 시스템 전체를 안전하게 보호합니다.
또 다른 중요한 참고 사항:많은 사람들은 OpenVZ가 손상되었거나 전체 시스템 가상화와 비교할 때 동등하지 않다고 생각합니다. 그들은 본질적으로 멸균된 프로세스 테이블을 갖춘 Chroot이기 때문에 이러한 가정을 합니다. 하드웨어 및 장치에 대한 보안 조치가 마련되어 있습니다.최대그 중 chroot에서 구현할 수 있습니다.
모든 관리자가 전용 서버 또는 전체 시스템 가상화에서 필요한 모든 커널 매개변수를 보호하는 데 필요한 수준의 지식을 갖고 있는 것은 아닙니다. 이는 OpenVZ를 배포하면 고객이 애플리케이션을 배포하기 전에 시도하고 보호하고 보호해야 할 공격 표면이 훨씬 적어진다는 것을 의미합니다. 좋은 호스트는 이러한 매개변수를 잘 보호할 것이며 결과적으로 이는 노드나 데이터 센터의 모든 사람뿐만 아니라 인터넷 전체에도 더 좋습니다.
명시된 대로 chroot는 파일 시스템 가상화를 제공합니다. setuid 실행 파일, 안전하지 않은 애플리케이션, 라이브러리, 매달려 있는 소유자 없는 심볼릭 링크 등이 없는지 확인해야 합니다. 공격자가 바인드를 손상시킬 수 있는 경우 버퍼 오버런을 위한 무언가를 찾기 위해 가상 파일 시스템을 샅샅이 뒤져 파일 설명자를 가지고 놀거나 다른 방식으로 chroot 내부에 있는 무언가를 손상시킵니다. 일반적으로 권한 상승을 통해 감옥을 탈출하거나 기본 시스템에 페이로드를 주입합니다.
이런 일이 발생하는 경우 일반적으로 잘못된 업데이트, 제로데이 공격 또는관용적 인간 오류.
전체 시스템 가상화와 달리 chroot가 여전히 사용되는 이유
이 시나리오를 고려하십시오. OpenVZ를 실행하는 호스트 노드와 함께 Virtual Private Server를 실행하고 있습니다. 당신은 단순히할 수 없다커널 수준에서 작동하는 모든 것을 실행하십시오. 이는 또한 운영 체제 가상화를 사용하여 프로세스를 분리하고 추가 보안을 제공할 수 없음을 의미합니다. 따라서 당신은해야 하다이 목적으로 chroot를 사용하십시오.
또한 chroot는 사용 가능한 리소스에 관계없이 모든 시스템에서 지속 가능합니다. 간단히 말해서 모든 가상화 유형 중에서 오버헤드가 가장 적습니다. 이는 많은 저가형 제품에서 여전히 중요하다는 것을 의미합니다.
또 다른 시나리오를 고려해보세요. 가상화된 환경 내에서 아파치가 실행되고 있습니다. 각 사용자를 분리하고 싶습니다. Apache에 chroot 추가 기능(mod_chroot, mod_security 등)을 통해 가상화된 파일 시스템을 제공하는 것은 최종 사용자 간의 개인정보 보호를 최대한 보장하는 최선의 선택이 될 것입니다. 이는 또한 정보 수집을 방지하는 데 도움이 되며 또 다른 보안 계층을 제공합니다.
간단히 말해서 보안을 구현하는 것이 중요합니다.레이어. Chroot는 잠재적으로 그들 중 하나입니다. 모든 사람과 모든 시스템이 커널에 액세스할 수 있는 사치를 누리는 것은 아닙니다. 따라서 chroot아직목적을 제공합니다. 전체 시스템 가상화가 본질적으로 과잉인 다양한 애플리케이션이 있습니다.
귀하의 질문에 대한 답변으로
나는 CentOS를 특별히 사용하지 않지만 이제 Bind가 작업 전에 권한을 삭제한다는 것을 알고 있습니다. 그러나 나는 바인드가 공격 벡터의 역사와 잠재적인 취약점으로 인해 루트가 변경되었다고 가정합니다.
또한... 모든 사람이 전체 시스템/운영 체제 수준 가상화에 액세스할 수는 없기 때문에 이 응용 프로그램을 자동으로 chroot하는 것이 그렇지 않은 것보다 더 합리적입니다. 이는 이론적으로 CentOS 사용자 기반에 보안을 제공하는 데 도움이 됩니다.
운영 체제 제공업체는 모든 업체가 동일한 시스템을 실행한다고 가정하지 않습니다. 이런 식으로 그들은 전체적으로 추가적인 보안 계층을 제공하는 데 도움이 될 수 있습니다.
이유가 있다너무 많은 응용 프로그램이 이것을 사용합니다, 그리고 귀하의 OS가 기본적으로 그렇게 하는 이유는 보안 기능으로 사용되고 작동하기 때문입니다. 이전에 언급한 것처럼 신중한 준비를 통해 잠재적인 공격자가 극복해야 하는 또 다른 장애물은 대부분의 경우 chroot 감옥에만 피해를 입히는 것으로 제한하는 것입니다.
답변4
이는 부분적으로 이전 버전의 Bind에 심각하고 빈번한 보안 취약점이 있었던 역사적인 이유 때문입니다. 나는 이 주제에 관해 최신 정보를 실제로 유지하지는 못했지만, 나쁜 옛날 이후로 훨씬 개선되었다고 장담합니다.
더 실용적인 또 다른 이유는 일반적으로 인터넷에 연결된 역할로 배포되므로 더 많은 공격, 조사 및 일반적인 장난에 노출되어 있다는 것입니다.
따라서 보안 문제에 있어서 경험 법칙이 흔히 그렇듯, 후회하는 것보다 안전한 것이 더 낫습니다. 특히 chroot하는 노력이 상대적으로 적기 때문에 더욱 그렇습니다.