chroot에서 named (bind)를 실행하는 것이 왜 보안에 중요한가? 아니면 아닐까요?

나는 bind와 함께 놀고 있는데 왜이 소프트웨어가 예를 들어 chroot에서 실행되는 CentOS에 있는지 궁금해하기 시작했습니다. 나를 오해하지 마십시오. 바인드가 무엇이며 chroot (jail)가 무엇인지 알고 있습니다. 그러나 내 주요 질문은 chroot가 너무 안전하지 않은 동안 bind 실행입니다.

교도소없이 다른 서비스 나 소프트웨어를 설치하지 않고 설치하는 것이 정말 유해합니까? 시스템에는 chroot없이 실행되는 많은 프로세스가 있으며 그중 하나의 타협은 매우 위험하다고 생각하지만 chroot없이 실행되는 다른 소프트웨어보다 더 위험한 이름은 무엇입니까?

@Some Guy가 언급했듯이 역사적 관점에서 이것에 대해 생각해야합니다.

역사적 관점은 단일 운영 체제에서 단일 하드웨어가 수십 가지의 다른 서비스라는 점이었습니다. 하나의 서비스가 손상된 경우 해당 하드웨어의 모든 것이 손상된 것입니다.

가상화를 사용하면 문제가 훨씬 줄어 듭니다. VM에서 벗어날 수는 없지만 사소한 것은 아닙니다. VM에서 분리하는 것은 확실히 어렵습니다. 루트 권한으로 실행되는 프로세스가 chroot에서 분리하는 것이 어렵습니다. 따라서 내 바인드 서버가 자체 VM에서 실행 중입니다. 이 경우에는 chroot가 중요하지 않습니다. 데미지는 VM이라는 사실에 의해 이미 피해가 제한되어 있기 때문입니다.

chroot는 VM과 같은 것을 만들려는 매우 약한 시도입니다. 루트 권한이있는 모든 프로세스에서 Chroot를 이스케이프 할 수 있습니다. chroot는 의도 된 것이 아니며 보안 메커니즘으로 작동하지 않습니다. BSD 교도소 또는 LXC가있는 chroot는 OS 레벨 가상화를 제공하고 보안 기능을 제공합니다. 그러나 요즘에는 전체 머신의 새로운 VM을 스핀 업하기가 너무 쉬워서 설정하거나 OS 레벨 가상화 툴을 사용하는 방법을 배우는 데는 가치가 없을 수도 있습니다.

이전 버전의 바인드는 권한을 삭제하지 않았습니다. 유닉스에서는 루트 계정 만이 1024 미만의 포트를 열 수 있으며, udp / 53 및 tcp / 53에서 수신 대기해야한다는 사실을 알고 있습니다. 바인드는 루트로 시작하고 권한을 삭제하지 않기 때문에 전체 시스템이 손상 될 수 있습니다. 요즘 거의 모든 소프트웨어가 소켓을 열고 루트 권한이 필요한 다른 작업을 수행 한 다음 실행중인 사용자를 권한이없는 계정으로 변경합니다. 권한이 삭제되면 손상된 시스템의 영향이 호스트 시스템보다 훨씬 낮습니다.

다른 답변은 꽤 좋지만 레이어의 보안 개념을 언급하지는 않습니다. 시스템에 추가하는 모든 보안 계층은 공격자가 극복해야하는 또 다른 계층입니다. chroot에 BIND를 넣으면 장애물이 하나 더 추가됩니다.

BIND에 악용 가능한 취약점이 있으며 누군가가 임의 코드를 실행할 수 있다고 가정하십시오. 그들이 루트에 있다면, 시스템에서 다른 것을 얻기 전에 그것을 벗어나야합니다. 언급 한 바와 같이 chroot-breaking에는 루트 권한이 필요합니다. BIND는 루트로 실행되지 않으며 chroot에는 최소한의 도구 만 사용할 수있어 옵션을 더욱 제한하고 본질적으로 시스템 호출 만 남겨 둡니다. 에스컬레이션 권한에 대한 시스템 호출이없는 경우 공격자는 DNS 레코드를보고 있습니다.

앞서 언급 한 상황은 SomeGuy가 언급 한 것처럼 다소 가능성이 낮습니다. BIND는 요즘 취약점이 거의 없으며 대부분 원격 실행이 아닌 DoS 유형 시나리오로 제한됩니다. 즉, chroot에서 실행하는 것은 상당수의 OS에서 기본 구성이므로 조금씩 강화 된 보안을 유지하기 위해 어떤 노력도 기울일 가능성이 없습니다.

전문

나는 사람들이 인터넷을 통해 오해를 되풀이하고 있다고 들었습니다.

우선; 단순히 .. 인해, 이는 얼마나 많은 실수로 발견 한 거기 원인과 결과 , 결국 뭔가를 사용하는 다른 의도 한 목적과?

Chroot 감옥이란 무엇인가?

Chroot는 처음에 프로세스 또는 사용자의 루트 디렉토리를 변경하도록 설계되었습니다 (알 수없는 소스에서 소프트웨어를 컴파일하는 데 적합). 이를 통해 손쉬운 청소를 포함한 빠른 테스트 베드 어플라이언스뿐만 아니라 기본 시스템에 보안 을 제공 할 수 있습니다. 그 이후로 몇 년이 지났으며, 개념과 묵시적 용도도 마찬가지로 변경되었습니다.

chroot를 사용하고있다 효과적으로 , 그리고에 대한 코드베이스에서 바로 여러 프로그램과 라이브러리 (즉 openSSHd, 아파치 + mod_security2 / mod_chroot, 비둘기장, 센드 메일, OpenVPN을, pam_chroot, 그리고 훨씬 더 ). 이러한 모든 주류 응용 프로그램이 잘못된 보안 솔루션을 구현했다고 가정하면 사실이 아닙니다.

chroot는 파일 시스템 가상화를위한 솔루션입니다. chroot jail 내부에서 프로세스 실행 지침을 준수하는 한 chroot에서 쉽게 벗어날 수 있다는 가정도 마찬가지입니다.

chroot 교도소를 확보하기위한 몇 가지 단계

즉 , 루트로 프로세스를 실행 하지 마십시오 . 그러면 루트 에스컬레이션 벡터가 열릴 수 있습니다 (chroot 내부 또는 외부에서도 마찬가지 임). chroot 외부 의 다른 프로세스와 동일한 사용자를 사용하여 chroot 내부 에서 프로세스를 실행하지 마십시오 . 공격 영역을 제한하고 프라이버시를 제공하기 위해 각 프로세스와 사용자를 고유 한 Chroot로 분리합니다. 필요한 파일, 라이브러리 및 장치 만 마운트하십시오. 마지막으로 chroot는 기본 시스템 보안을 대체하지 않습니다. 시스템을 완전히 보호하십시오.

또 다른 중요한 참고 사항 : 많은 사람들이 OpenVZ가 고장 나거나 전체 시스템 가상화와 비교하여 동일하지 않다고 생각합니다. 그들은 본질적으로 Chroot이고 멸균 된 공정 테이블을 가지고 있기 때문에 이러한 가정을합니다. 하드웨어 및 장치에 대한 보안 조치가 마련되어 있습니다. 대부분 은 chroot에서 구현할 수 있습니다.

모든 관리자가 전용 서버 또는 전체 시스템 가상화에서 필요한 모든 커널 매개 변수를 보호하는 데 필요한 지식 수준을 가지고있는 것은 아닙니다. 이는 OpenVZ를 배포한다는 것은 고객이 애플리케이션을 배포하기 전에 시도하고 보호해야 할 공격 영역이 훨씬 적다는 것을 의미합니다. 좋은 호스트는 이러한 매개 변수를 안전하게 보호하고 노드 또는 데이터 센터의 모든 사람뿐만 아니라 인터넷 전체에 더 좋습니다.

명시된 바와 같이 chroot는 파일 시스템 가상화를 제공합니다. 공격자가 COULD 손상 바인딩을 바인딩 할 경우 setuid 실행 파일, 안전하지 않은 응용 프로그램, 라이브러리, 매달려있는 소유자없는 심볼릭 링크 등이 없는지 확인해야합니다. 다른 방법으로, 특권 에스컬레이션을 통해 또는 교도소를 기본 시스템에 주입하여 일반적으로 감옥에서 탈출하는 것을 훼손합니다.

이 경우 일반적으로 잘못된 업데이트, 제로 데이 익스플로잇 또는 관용적 인 사람 오류의 결과 입니다.

전체 시스템 가상화와 달리 chroot가 여전히 사용되는 이유

이 시나리오를 고려하십시오. 호스트 노드가 OpenVZ를 실행하면서 Virtual Private Server를 실행 중입니다. 당신은 단순히 수없는 커널 레벨에서 작동 아무것도 실행합니다. 이것은 또한 운영 체제 가상화를 사용하여 프로세스를 분리하고 추가 보안을 제공 할 수 없음을 의미합니다. 따라서이 목적으로 chroot를 사용해야 합니다.

또한 chroot는 사용 가능한 리소스에 관계없이 모든 시스템에서 지속 가능합니다. 간단히 말해서 모든 가상화 유형의 오버 헤드가 가장 적습니다. 이것은 많은 저가형 박스에서 여전히 중요하다는 것을 의미합니다.

다른 시나리오를 고려하십시오. 가상화 된 환경에서 실행중인 아파치가 있습니다. 각 사용자를 분리하려고합니다. 아파치에 chroot 애드온 (mod_chroot, mod_security 등)을 통해 가상화 된 파일 시스템을 제공하는 것은 최종 사용자 간의 최대한의 프라이버시를 보장하는 가장 좋은 옵션입니다. 또한 인텔 수집을 방지하고 또 다른 보안 계층을 제공합니다.

간단히 말해서, 계층으로 보안을 구현하는 것이 중요합니다 . Chroot는 잠재적으로 그들 중 하나입니다. 모든 사람과 모든 시스템이 커널에 액세스 할 수있는 사치가있는 것은 아니므로 chroot STILL 이 목적을 달성합니다. 전체 시스템 가상화가 본질적으로 과도하게 사용되는 다양한 응용 프로그램이 있습니다.

귀하의 질문에 대한 답변

특히 CentOS를 사용하지 않지만 Bind는 이제 작업 전에 권한을 삭제합니다. 그러나 바인드는 공격 벡터 히스토리 및 잠재적 취약점으로 인해 근절이 있다고 가정합니다.

또한 ... 모든 사람이 전체 시스템 / 운영 체제 수준 가상화에 액세스 할 수있는 것은 아니기 때문에이 응용 프로그램을 자동으로 chroot하는 것이 더 합리적입니다. 이는 이론적으로 CentOS 사용자 기반에 보안을 제공하는 데 도움이됩니다.

운영 체제 공급자는 모든 시스템이 동일한 시스템을 실행한다고 가정 할 필요가 없습니다. 이런 식으로, 그들은 추가 보안 계층을 제공 할 수 있습니다 ...

많은 응용 프로그램이 이것을 사용 하는 이유 와 OS가 보안 기능으로 사용되며 작동하기 때문에 OS가 기본적으로 분명히하는 이유가 있습니다. 앞서 언급 한 바와 같이 신중한 준비를 통해 잠재적 공격자가 대부분 극복해야 할 또 다른 장애물이되어 치트 교도소에 대한 피해를 제한합니다.

구 버전의 바인드가 심각하고 빈번한 보안 취약점을 가지고 있었던 역사적 이유 때문입니다. 나는 실제로 주제에 대해 최신 정보를 얻지 못했지만 나쁜 일 이후로 훨씬 개선되었다는 것을 베 풀었습니다.

더 실용적인 다른 이유는 일반적으로 인터넷 연결 역할에 배치되어 있기 때문에 더 많은 공격, 조사 및 일반적인 장난에 노출되기 때문입니다.

따라서 보안 문제의 경험과 마찬가지로 미안보다 안전합니다. 특히 chrooting의 노력이 적기 때문에 더욱 안전합니다.