chroot 어디까지 의미가 있을까요?

오리주둥이의 이미지

이번에 서버를 새로 설치하게 되었습니다.

chroot로 특정 디렉토리 이상 벗어나지 못하도록 작업하던 와중에 몇가지 의문 ( 또는 약간의 회의 )이 들어서 여러분들의 의견을 듣고 싶습니다.

1. 서버 전체를 해킹당하지 않기 위한 설정이 새로 설치하는것과 같지는 않은가?

현재 chroot을 통해 서버에 적용된 jail은 ssh, ftp 까지 입니다.
특정 디렉토리에 사용자 계정이 존재하고 jail을 위한 bash, user 등의 디렉토리들이 있고 home 디렉토리도 있습니다.
문제는 apache와 mysql을 chroot로 돌리는 것인데 이 부분에서 진행을 멈추고 문서들을 찾고 검토하는 중에 잠시 의아한 생각이 들었습니다.

먼저 apache와 mysql 까지 jail 시킬 디렉토리로 옮기고 필요한 라이브러리를 옮기는등 성공을 하더라도
결국 해킹을 당하게 되면 chroot로 설정한 디렉토리는 어쨌든 새로 만들어야 하는것 아닌가 하는것입니다.
그렇게 하려면 mysql과 apache를 새로 설치하고 다시 chroot로 작동하기 위해 반복적인 작업을 해야하는데
이렇게 된다면 서버를 새로 설치하는 시간외에는 동일한 시간이 발생하는것 아닌가 하는 것입니다.

물론 chroot를 적용한 디렉토리를 최초로 적용 후 백업을 받아놓는경우도 있겠습니다만
이것은 아래의 2 항목과도 함께 생각을 해보려고 합니다.

2. apm을 chroot로 적용했다면 발생하는 문제들에 대해서는..

실제로 apm을 적용해보지 않고 ( 경험해보지 않고 ) 섣부른 판단이겠지만 새로운 라이브러리가 필요하거나 새로운 버전으로의 업데이트가 필요할 경우에 대해서
고민해봤는데 이게 생각보다 좀 끔찍했습니다.

또한 서로의 의존성을 생각했을때 chroot가 적용되지 않는다면 해결할 수 있는 상황이 빠르겠지만
chroot가 적용되었을 경우 여러가지 문제로 이것을 해결하는 상황이 더 복잡해진다는 판단이 들었습니다.

여기서 간단히 '관리자의 노력으로 해결 가능합니다' 라는 답변을 할 수 있지만 노력의 여하를 떠나 서비스가 되고 있는 상태에서라면
상당히 고민스러운 부분일것 같습니다.

3. 서버자체가 해킹당하지 않았더라도 결국 chroot가 적용된 디렉토리는 해킹당하는 것은 변함이 없지 않은가?

보안을 통해 그 피해를 최소화 하고자 하는것이 목적인 chroot가 apm을 새로 설치하고 다시 chroot를 적용하는것은 해킹을 당했을때 새로 서버를 밀고
설치하는것과 큰 차이가 있을까 하는 생각이 들었습니다.

가장 중요한것은 계정의 빠른 복구와 피해의 최소화가 목적인데 해킹 당했을때 계정은 이미 그 피해로 인해 악성코드가 심어져 있고 번져 있다면
복구의 의미보다는 재건의 의미가 되는것 아닌가 합니다.

4. 해킹은 주로 어떻게 이루어지는가?

요즘의 해킹 추세는 apache의 nobody 권한을 획득하여 root권한을 획득하는 방법보다는
웹어플리케이션의 보안취약점을 통해 들어와서 root권한을 획득하는것이 대부분인 것으로 알고 있습니다.
결국 계정이 해킹당해서 chroot 디렉토리까지 해킹을 당한다면 최상위까지 해킹을 당할 확률은 적을것으로 판단이 되는데
여러분들의 생각은 어떠신가요?

결론적으로 chroot디렉토리까지만 해킹을 당하지만 복구에 드는 시간은 큰 차이가 없는것 아닌가 하는것과
이미 해킹당해 악성코드가 심겨져 버린 사용자의 복구가 더 급선무가 아닌가 하는 생각입니다.
1일 백업이든 7일 백업이든 대부분의 경우는 사용자가 간파하지 못하고 있다가 백업본 까지 동일하게 악성코드가 들어가버리는 경우가 허다하다보니
이런 여러가지 생각을 하게 되었습니다.

개인적으로 저의 결론은
apm은 상위디렉토리에 평소처럼 운영을 하고 사용자 계정을 통해 들어왔을경우 root 권한을 획득해도 그 디렉토리내부까지만 막도록 ssh, ftp, 계정 까지만 막는것 이상은
chroot의 의미가 없지 않을까 하는것입니다.

송효진의 이미지

웹호스팅 서비스 주체일 경우
제 결론은 mod_become 과 ssh 미제공 입니다.
ssh 를 제공하지 않을 것이기 때문에 암호 자체를 만들지 않습니다.
ftp 는 가상계정으로 충분히 복잡한 암호를 만들어 줍니다.

직접 서비스 하는 서버일 경우
역시 암호 자체를 만들지 않습니다. rsa 키 로그인 설정만을 해 두고,
외부에는 모조리 제공하지 않습니다.
협업이 필요한 경우를 html 코딩에 한정하고,
html 템플릿을 적용하여 디자인 디렉토리를 완전히 분리하고,
ftp 가상계정을 해당 디렉토리에 한정하여 설정합니다.
프로그래밍 상의 보안구멍은 귀찮지 않고 당연하게 느껴질 정도로 철저히 점검하려 노력합니다.

'어쩔 수 없이 제공해야 하는 것' 이 보안구멍이라고 생각하기에
'불편해도 따르라' 고 하는게 보안지침이라고 생각합니다.

emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇 개 안돼요~
http://xenosi.de/

오리주둥이의 이미지

답변 감사합니다.

ssh 미제공은 사용자들의 특성상 불가능 합니다.
일단은 apm은 그대로 운영하고 사용자 계정쪽만 chroot로 막기로 했습니다.

송효진의 이미지

php 파일 하나로 된 browser 하나 설치되면 상황 종료;;;
안하는 것과 마찬가지라고 생각됩니다.

emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇 개 안돼요~
http://xenosi.de/

오리주둥이의 이미지

네. 저도 그렇게 생각합니다.
apache 역시 마찬가지겠지요.

이렇게 결론을 내리게 된 이유는 chroot 자체가 최상위 서버까지 뚫리는것을 막기위함이긴 하나
어차피 jail된 디렉토리가 파토나면 상황은 동일하다 ( 다만 OS의 재설치만 제외하고 ) 는 결론을 내렸습니다.
그것은 큰 의미가 없다고 개인적으로 판단을 하였습니다.
월요일부터 오늘까지도 계속 생각해봤는데 이것이 과연 보안일까? 하는 생각까지 가더군요.

사족.
머... apm을 chroot 로 돌리는것 자체도 너무 까다롭고 제약이 많더라.. 가 사실 더 큰 이유입니.. ㅡ.ㅡ;;;;;;;;;;;;;;;;;;

tsgates의 이미지

That is just because you are not keeping POLP for each service. See, http://pdos.csail.mit.edu/~max/docs/okws.pdf for serious discussions.