|
ANTON
|
2011-07-23 11:02:37, 조회 : 261, 추천 : 49 |
1. stack overflow
2. heap overflow
3. frame pointer overflow
4. integer overflow
[ eip ] [ ebp ] [ int 4 ][ long 4 ] [ stack ]
int b;
long i;
char buf[1024];
----
char *buf;
buf = malloc(1024);
...
char *buf2;
buf2 = malloc(1024);
0xbffff
0x8048??
[ buf 1024 ] [ buf2 1024 ]chroot의 의미와 개요
chroot는 새로운 루트 디렉토리를 설정하여 실제로 chroot된 프로세스는
이 디렉토리의 상위 디렉토리로는 접근할 수 없고 오직 이 하위의 디렉토리로만
접근할 수 있게 해주는 보안에는 매우 효과적인 시스템 함수이다. 즉 하나의
프로세스를 실행시킬 때 이 프로세스가 접근할 수 있는 영역을 프로세스 생성
시기에 미리 제한시킬 수 있게 해주는 것이다. 잘 살펴 보면 이 함수를 이용하여
만들어진 동명의 chroot라는 명령어도 존재하는데 이는 프롬프트상에서 프로세스를
실행시킬 때도 이러한 작업을 가능하게 해주기 위해서이다. 아직 chroot가 잘 이해가
안된다면 글의 뒷부분의 wrapper 코드를 보면 쉽게 이해 할 수 있으리라고 생각된다.
chroot의 장점
이전에 소개 했던 웹 서버의 문제점을 해결해 주고 있다.
chroot된 디렉토리가 웹 서버 프로세스의 루트 디렉토리로 인식되기 때문에 불필요한 파일이나 디렉토리로의
접근을 제한할 수 있다.
앞에서 소개했듯이 루트 권한의 프로세스가 nobody 권한의 자식 프로세스를 생성시켜서 컨트롤을 넘기기 전에
공격 당하여 루트의 권한으로 작업을 한다고 하더라도 이러한 작업이 chroot된 디렉토리를 벗어 날 수 없기
때문에 시스템에 큰 영향을 미치지 못한다. 물론 이는 chroot된 디렉토리 이하에는 시스템을 침입하는데 사용할만한
파일이나 디렉토리가 없고 단순히 html파일, 그림 파일, CGI파일 등이 있을 뿐이기 때문이다.
기존의 웹 서버의 경우 사용자들의 홈 페이지들이나 웹 서비스를 하기 위한 프로그램(웹 BBS, DB와 연동된 웹
서비스의 DB)들이 디스크에 흩어져 있었다. 이는 물론 기존의 웹 서버나 생성된 자식 프로세스가 디스크의
어디든지 접근할 수 있었기 때문이다. 그러나 chroot를 이용하여 웹 서비스를 하게 될 경우에는 하나의 큰
디스크 파티션을 지시하는 디렉토리를 chroot하여 만들기 때문에 모든 웹 서비스 관련 파일들을 이 디스크 파티션에
모아 두게 된다. 그러면 실제로 웹 서버는 이 디스크 파티션, 정확하게는 이 디스크 파티션을 지시하는 chroot된
디렉토리 밖을 못 벗어 나면서 동작했기 때문에 이 디스크만 정기적으로 백업을 받아 둔다면 시스템이 죽거나
디스크가 망가지더라도 다른 호스트의 빈 디스크에 백업을 풀어서 즉시 웹 서버를 복구시킬 수 있게 된다.
이때의 복구 시간은 단순히 백업 데이터를 새로운 디스크에 복사하는 시간만이 소요되게 될 것이다. 물론 새로이
옮긴 호스트의 DNS entry에 문제가 생긴 호스트의 이름을 alias시켜 놓으면 기존에 웹 서비스를 이용하던 사람들은
전혀 문제를(호스트가 옮겨지고 데이터를 저장하고 있던 디스크가 바뀌었다는 사실) 느끼지 못할 것이다.
즉 투명성(transparency)을 보장할 수 있다는 것이다.
만일 이와 같이 하지 않고 웹 자료들이 여러 디스크에 분산되어 있다고 가정하면 이중 어느 하나의 디스크가
망가지게 되면 이 디스크에 있는 웹 자료만 복구시키는 문제도 지저분할 뿐만 아니라 시스템이 파괴될 경우에는
더욱 더 전체 웹 서비스의 복구 시간은 길어질 것이며 관리자들에게 큰 부담을 주게 될 것이다.
chroot의 단점
chroot를 사용하는 방법은 보안을 위해서는 매우 훌륭한 방법이지만 이 또한 약간의 문제를 내포하고 있는 것이
사실이다. 이를 여기서 간단히 언급하고 넘어가도록 하자.
설치하기가 까다롭다고 말할 수 있다(물론 노련한 관리자라면 큰 문제는 되지 않을 것이다). 뒷 부분에서 언급하겠지만
이진 파일들을 bin디렉토리에 가져다 놓을 때 그냥 시스템에 있는 것을 복사하게 되면 이들은 모두 공유 라이브러리를
사용하고 있기 때문에 이들이 필요로 하고 있는 모든 라이브러리를 usr/lib에 복사 할 필요가 있다. 특히 웹에서는
CGI를 이용하고 있기 때문에 이러한 일은 매우 피곤하다. 그래서 대부분의 경험자들은 이진 파일들은 정적으로
컴파일 하는 것을 추천하고 있다. 이 경우에는 공유 라이브러리를 사용할 필요가 전혀 없기 때문에 관리하기가
깔끔하고 편리하다. 물론 웹에서 이용될 모든 이진 파일들을 정적으로 다시 컴파일해주어야 하므로 초기 설치
시에 좀 시간이 소요되는 단점이 있다. 뒤에서 보일 예제는 정적으로 컴파일하지 않는 방법을 소개하고 있다.
기존에 이미 웹 서버가 설치 되어 있는 상태에서 chroot를 이용한 서버를 설치할 경우에는 chroot를 이용하는 장
점을 살리기 힘들 수 있다. 하지만 관리자의 재량에 따라 불가능한 것은 아니다. 이 말은 이미 기존의 웹 서버가
있다면 개인들이 각각의 홈 디렉토리에 자신의 홈 페이지를 만들어 놓았을 것인데 이 홈 페이지들이 chroot에서
이용하는 파일 시스템이나 chroot의 tree 바깥에 있을 수 있다는 것이다. 이에 대한 해결책을 소개하면 다음과 같다.
만일 사용자들의 홈 페이지가 chroot를 이용하는 tree 바깥에 있지만 같은 파일 시스템 상에 있다면 하드 링크를
이용해서 해결 할 수 있다(chroot tree이하에서 바깥으로의 소프트 링크는 동작하지 않는다). 하지만 완전히 다른
파일 시스템에 사용자들의 홈 페이가 있을 경우에는 loop back 마운트(로컬 파일 시스템에서 다른 로컬 파일
시스템으로의 마운트)를 이용하여 해결 할 수 있다. loop back 마운트에 대한 자세한 설명은 생략하도록 하겠다.
chroot를 이용한 웹 서버 설치 과정
이제 chroot을 이용하여 새로운 웹 서버 프로그램을 설치하는 방법에 대해 소개해 보도록 하겠다.
아래의 예제는 솔라리스 2.5 머신에서 모든 프로그램은 공유 라이브러리를 이용하게 컴파일하였다는
가정하에서 직접 설치한 과정을 정리하여 본 것이다. 이 과정은 솔라리스 2.5의 경우이므로 모든 운영체제에
적용되는 것은 아니지만 기본적인 과정을 잘 이해한다면 다른 운영체제라도 큰 문제가 되지는 않을 것이라
믿고, 또 발생할 수 있는 사소한 문제들은 관리자의 재량으로 해결할 수 있을 것이라고 생각된다.
chroot는 임의의 디렉토리를 새로운 루트 디렉토리로 만드는 것이기 때문에 디스크에 대한 용량이 충분한 디스크를
하나 선정한다.
# df -k
파일시스템 K바이트 사용 가용 용량 설치지점
/dev/dsk/c0t0d0s0 86879 21416 56783 28% /
/dev/dsk/c0t0d0s6 480919 417695 15134 97% /usr
/proc 0 0 0 0% /proc
fd 0 0 0 0% /dev/fd
/dev/dsk/c0t1d0s7 1952573 135576 1621747 6% /WWW
/dev/dsk/c0t0d0s5 288855 212963 47012 82% /opt
/dev/dsk/c0t0d0s7 724031 227921 423710 35% /usr1
swap 409672 224 409448 1% /tmp
여기서는 /WWW라는 디렉토리에 chroot를 하기로 하겠다.
먼저 아래와 같은 디렉토리를 만들도록 하자.
# pwd
/WWW
# ls
총 28 2 cgi-bin/ 2 etc/ 2 logs/
2 HOME_PAGE/ 2 conf/ 2 home/ 6 src/
2 bin/ 2 dev/ 4 icons/ 2 usr/
위의 디렉토리들을 간단히 설명하면 다음과 같다.
HOME_PAGE
이 웹 서버에 접근했을 때 기본적으로 찾는 디렉토리로 설정
bin
이진 파일들을 가져다 놓을 디렉토리
cgi-bin
CGI 프로그램을 가져다 놓을 디렉토리
conf
httpd의 설정 파일을 가져다 놓을 디렉토리
dev
디바이스 파일을 가져다 놓을 디렉토리
etc
passwd나 group파일을 가져다 놓을 디렉토리
home
개인 홈페이지나 웹 서비스 관련 DB등의 자료들을 가져다 놓을 디렉토리
icons
아이콘을 놓을 디렉토리
logs
httpd가 만들 로그 파일을 저장할 디렉토리
usr
usr/lib나 usr/tmp를 위한 디렉토리
src
httpd를 컴파일 할 디렉토리
자신이 원하는 웹 서버 프로그램을 가져와 /WWW/src 밑에서 컴파일하자. 본인이 사용한 아파치 웹 서버 소스
프로그램은 다음에서 구할 수 있다.
http://www.apache.org
기본적인 설치 과정은 웹 서버를 설치할 때와 동일하지만, 다음의 설치 과정에만 주의하면 된다. 앞에서 만들어진
conf라는 디렉토리에 아래의 파일들을 가져다 놓는다.
# ls conf
총 36 12 httpd.conf 14 srm.conf
4 access.conf 6 mime.types
conf밑에 있는 httpd.conf에서는 다음과 같이 해주어야 한다.
#ServerRoot /usr/local/etc/httpd
# for chroot()
ServerRoot /
이것 이외의 설정은 기존의 설정과 동일하다. 좀더 자세한 아파치 서버의 기본적인 설정 방법은 월간 Internet
1996년 10월 호를 참고하기 바란다.
src에서 컴파일한 httpd를 bin밑으로 옮겨두고 이 httpd가 이용하는 공유 라이브러리들을 실제 /usr/lib에서
/WWW/usr/lib밑에 복사해 둔다. httpd가 사용하는 이진 파일은 ldd라는 명령어로 조사한다.
# ldd httpd
libsocket.so.1 =>/usr/lib/libsocket.so.1
libnsl.so.1 => /usr/lib/libnsl.so.1
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libintl.so.1 => /usr/lib/libintl.so.1
libw.so.1 => /usr/lib/libw.so.1
이것을 하는 이유는 기존의 라이브러리 파일이 있던 /usr/lib라는 디렉토리는 httpd 데몬에게는 더 이상 보이지
않기 때문이다. 따라서, httpd 데몬에게 루트 디렉토리인 /WWW밑에 새로운 usr/lib을 만들어 필요한 라이브러리들을
복사해 두어야 하는 것이다.
etc 밑에는 /etc/passwd, /etc/group, /etc/netconfig를 복사한다. 이 때, 주의해야 할 점은 패스워드 파일의 패스워드
부분을 x로 막아 놓는다. 솔라리스는 shadow passwd를 사용하기 때문에 사실 이렇게 할 필요는 없지만 이를 이용하지
않은 경우는 패스워드의 암호화된 부분은 반드시 삭제 시켜야 한다. 그리고 불필요한 사용자는 삭제하는 것이 좋다.
dev 밑에는 필요한 디바이스 파일을 만들어 놓는다. 솔라리스의 경우에는 다음과 같이 만들 수 있는데 이는 운영체제에
따라서 달라질 수 있는 요소가 가장 크기 때문에 다른 운영체제를 이용하는 경우에는 조심할 필요가 있다.
# mknod /www/httpd/dev/ip c 11 3
# mknod /www/httpd/dev/tcp c 11 42
# mknod /www/httpd/dev/ticotsord c 105 1
# mknod /www/httpd/dev/udp c 11 41
# mknod /www/httpd/dev/zero c 13 12
# mknod /www/httpd/dev/null 13 2
# ls
총 0 0 null 0 ticotsord 0 zero
0 ip 0 tcp 0 udp
이렇게 하면 디바이스 파일을 생성할 수 있다. 만약에 major, minor 숫자를 모르는 경우에는 실제 /dev 밑에 있는
파일을 아래와 같이 살펴보면 된다.
# ls -lL /dev/zero
0 crw-rw-rw- 1 root sys 13, 12 5월 8일 04:48 /dev/zero
참고로 zero는 동적 로더(dynamic loader)에 의해서 사용되는 것이며 나머지는 네트웍(network)에 사용되는 것이다.
CGI 프로그램을 웹 서버가 제공할 지에 대해 결정한 후 CGI 프로그램을 사용자들이 이용할 수 있게 하려면, CGI
프로그램이 사용하는 이진 파일을 조사한 후, CGI 프로그램이 사용하는 이진 파일과 그에 따른 라이브러리를 /WWW/bin,
/WWW/usr/lib에 각각 넣어 주여야 한다. 그렇지 않으면 CGI 프로그램에 필요한 이진 파일들(sh, perl등)을 chroot된
새로운 루트 디렉토리에서 찾지 못하게 되므로 CGI 프로그램을 이용할 수 없게 된다. 우선 기본적인 sh과 perl을
컴파일한 후 bin 밑에 넣어 준다. 여기서는 정적으로 컴파일하지 않는 경우이므로 sh와 perl이 이용하는
라이브러리들을 확인하여 usr/lib에 복사하여 둔다.
다음은 기본적으로 넣어 두면 CGI 사용에 유용한 프로그램들이다.
cat comm cp csplit cut
du expand find fmt fold
grep head join locate ls
mkdir mv nl od paste
pr rm rmdir sort split
sum tail touch tr unexpand
uniq wc xargs
본인의 경우는 bin에 csh, sh, perl, httpd만을 넣어 두었는데 이들이 필요로 하는 라이브러리들은 다음과 같았다.
# pwd
/WWW
# ls usr
총 4 2 lib/ 2 tmp/
# ls usr/lib
총 3322 2 libmapmalloc.so@ 78 libw.so.1*
48 ld.so* 14 libmapmalloc.so.1* 32 nss_compat.so.1*
288 ld.so.1* 2 libmp.so@ 22 nss_dns.so.1*
2 libc.so@ 32 libmp.so.1* 42 nss_files.so.1*
1312 libc.so.1* 2 libnsl.so@ 48 nss_nis.so.1*
2 libdl.so@ 1136 libnsl.so.1* 58 nss_nisplus.so.1*
6 libdl.so.1* 2 libsocket.so@ 2 straddr.so@
2 libintl.so@ 136 libsocket.so.1* 20 straddr.so.2*
32 libintl.so.1* 2 libw.so@
마지막으로 httpd 데몬을 실행시키기 위한 wrapper를 만든다. 다음은 wrapper의 소스 코드이다.
#include <stdio.h>
main(int argc, char *argv[])
{
if (chdir(argv[1])) {
fprintf(stderr,"change directory to %s failed !",argv[1]);
exit(1);
}
if (chroot(argv[1])) {
fprintf(stderr,"chroot %s failed !",argv[1]);
exit(1);
}
execl("/bin/httpd","httpd","-f","/conf/httpd.conf",(char *)0);
exit(0);
}
이 프로그램의 의미는 다음에 오는 실행 방법을 보면 확실히 이해 할 수 있을 것이다.
다음의 과정은 /WWW이하 디렉토리와 파일의 소유를 가상의 사용자인 www으로 한다. 물론 www이라는 사용자는
/etc/passwd에 등록되어 있어야 한다. 이것은 nobody를 등록시킨 과정과 동일하게 하면 된다.
# grep www /etc/passwd
www:x:1000:1000:WWW server:/www/httpd:
# grep webgroup /etc/group
webgroup::1000:web
# chown -R www /WWW
# chgrp -R webgroup /WWW
# chmod -R 755 /WWW
이제 wrapper 프로그램 파일을 만들어서 부팅 스크립트에 추가해 주기만 하면 된다.
# pwd
/etc/rc3.d
# ls
총 1258 4 S15nfs.server* 2 S97wrapper*
4 README 2 S98smbd*
# cat S97wrapper
#!/bin/sh
# for httpd wrapper daemon
if [ -f /WWW/bin/httpd_wrapper ]
then
echo "start httpd wrapper"
/WWW/bin/httpd_wrapper
echo "/WWW/bin/httpd_wrapper"
fi
결론
지금까지 chroot를 이용하여 아파치 웹 서버를 설치하는 방법에 대하여 설명하였다.
이 설명이 완벽하진 못하리라 생각이 되고 실제로 이를 구현하다 보면 글로써 설명하기에는 좀 곤란한 여러 가지
문제를 많이 경험하리라고 예상이 된다. 일반적으로 chroot를 이용하는 경우는 안전한 FTP archive를 설치할 경우에
많이 사용되어 오던 방법이었다. 여기서는 이를 웹에 적용시켜 보았는데 솔직히 FTP archive보다 웹 서버가 더
어렵다는 것을 인정하고 싶다. 웹이 좀 까다로운 이유는 웹이 CGI를 이용하기 때문인데 웹의 유용성을 위해서
관리자가 좀 수고한다는 생각을 하면 그래도 해볼만한 것이고 웹 서버를 안전하게 설치해야 할 경우에는 이 방법을
추천하고 싶다.
|
|
|
