유닉스 계열의 퍼미션 설정
컨텐츠 정보
- 17,982 조회
- 12 추천
- 목록
본문
http://www.superuser.co.kr/security/linux-security-howto/howto_05.htm
5. 파일과 파일시스템 보안
시스템을 온라인으로 접속시키기 전에, 몇 분 동안이나마 준비와 계획을 하는 것은 여러분의 시스템과 데이타를 보호하는 것에 큰 도움을 준다.
* SUID/SGID를 사용자의 홈 디렉토리에서 쓰게 할 이유가 전혀 없다. 루트가 아닌 다른 사용자들이 자료를 쓸 수 있도록, 쓰기가 허락된 (writable로 되어 있는) 파티션에는 /etc/fstab에 nosuid 옵션을 적어 놓도록 한다. 이런 방법 등으로 어차피 필요 없어야 하는 -- 풀그림의 실행을 금지하며, 블록 디바이스의 형성을 못하도록 -- /var를 포함해서, 사용자의 홈 파티션에는 nodev와 noexec을 옵션으로 적어 놓도록 한다.
*
*
만약 NFS를 써서 파일시스템을 네트워크로 송출 (export)하는 경우라면, /etc/exports를 최대 한도로 제한하도록 조정하도록 한다. 이것은 와일드카드를 쓰지 않는 것과, 루트 쓰기 엑세스 (root write access)를 허락하지 않는 것과, 가능하면 읽기 전용의 파일시스템만을 송출하도록 하는 것을 의미한다.
*
사용자의 파일 생성 umask를 가능한 제한된 값으로 조정한다. [umask 값]을 참조한다.
*
NFS 등의 네트워크 파일시스템을 마운트한다면, /etc/exports를 조정해서 적절한 제한을 주도록 한다. 보통 'nodev'와 'nosuid'를 쓰는 것이 바람직하고, 'noexec'까지도 고려하는 것이 좋다.
*
기본값인 "무제한 (unlimited)"이 아닌 값으로 파일시스템의 기본값을 제한한다. 자원 제한 PAM 모듈과 /etc/pam.d/limits.comf를 사용함으로서 사용자 각각의 제한치를 조정한다. 예를 들면, users 그룹을 위한 제한은 다음과 같을 수 있다.
@users hard core 0
@users hard nproc 50
@users hard rss 5000
이 경우는 코어 파일의 생성을 금하며, 프로세스의 수를 50으로 제한하며, 사용자 한 사람 당 메모리 사용을 5 메가로 제한함을 말한다.
*
/var/log/wtmp와 /var/rin/utmp 파일들은 시스템 모든 사용자의 접속 기록을 가지고 있다. 이들은 사용자가 (혹은 잠재적 침입자가) 언제, 어디서 시스템에 들어왔는가를 조사하기 위한 작업 사용되므로 이 파일들의 보안과 보전은 철저히 유지되어야만 된다. 일반적인 시스템 작동에 영향을 주는 경우가 없도록 함과 동시에 644 허가권을 가지고 있어야 한다.
*
보호되어야만 하는 파일들을 실수로 지우거나 덧쓰는 경우가 없도록 하기 위해서 이뮤타블 비트 (immutable bit: 불변의 비트)를 사용한다. 또한 이 방법은 파일에 -- /etc/passwd나 /etc/shadow를 조작하는 방법의 일부가 되는, -- 심볼릭 링크를 만드는 것을 방지한다. 이뮤타블 비트에 대한 추가 정보는 chattr(1)의 man 페이지를 참조하도록 할 것.
*
SUID와 SGID는 잠재적인 보안 위험 요소이기 때문에 철저하게 감시되어야 만 한다. 이 풀그림들은 이 들을 사용하는 사용자들에게 특별 권한을 부여해 주기 때문에, 보안에 불안 요소를 주는 이러한 풀그림들이 설치되는 일이 없도록 해야 한다. 크랙커들이 좋아하는 트릭 중 의 하나는 SUID 루트 프로그램을 침탈하고 그 후에 -- 원래의 문제점이 고쳐진 후에라도 -- SUID 풀그림을 통해 뒷문의 개구멍으로 들어오는 것이다.
그러므로, 여러분 시스템에 있는 모든 SUDI/SGID를 찾아내서, 그것들이 무엇인지 추적함으로서 --잠재적인 침입자를 의미할 수 있는-- 어떠한 변화라도 알 수 있도록 한다. 다음의 명령어를 사용하면 시스템에 있는 모든 SUID/SGID 풀그림을 찾아낼 수 있다.
root# find / -type f \\( -perm -04000 -o -perm -02000 \\)
데비안 디스트리뷰션을 쓰면 어떤 SUID 문서가 존재하는지 매일 밤 확인하는 작업 (Job)을 실행할 수 있고. 그 결과를 전날 밤의 결과와 비교를 할 수가 있다. /var/log/suid*를 보면 이 작업의 일지를 볼 수 있다. 원한다면 의심스러운 SUID나 SGID 허가권을 가진 풀그림을 chmod를 써서 지우거나 바꿀 수 있을 것이다.
chmod를 사용하면 의심쩍은 풀그림의 SUID나 SGID 허가권을 제한적으로 지울 수 있고, 필요함이 나중에라도 확실하게 느껴진다면 다시 복구해 주면 된다.
*
만약 크랙커가 시스템의 사용권을 얻고 -- 특히 시스템 파일 등의 -- 월드-라이타블(World-writable) 파일들을 마음대로 변경할 수 있게 된다면 그야말로 이 것은 심각한 보안 개구멍이 존재하게 된 것이라고 할 수 있다. 덧붙이면 -- 크랙커들이 마음대로 파일을 덧붙이거나 지울 수가 있게 되므로 -- 월드-라이타블 디렉토리 또한 위험한 존재인 것이다. 월드-라이타블 파일 모두를 찾기 위해서는 다음의 명령어를 사용한다.
root# find / -perm -2 -type l -ls
그리고 이 파일들이 왜 "쓰기 가능 (라이타블)"으로 설정되어 있는지 반드시 파악하도록 한다. 정상적인 운영의 경우에 있어서, /dev의 일부와 심볼릭 링크를 포함한 여러 파일들은 월드-라이타블로 되어 있어야 할 것이다. (In the normal course of operation, several files will be writable, including some world-writable, including from /dev, and symbolic links. some from /dev, and symbolic links, thus the ! -type l which excludes these from the previous find command.)
*
주인이 없는 무소속의 파일들 또한 침입자가 시스템에 들어왔다는 징후일 수 있다. 주인이 없거나 그룹에 소속되어 있지 않은 파일들은 다음의 명령어를 쓰면 찾아낼 수 있다.
root# find / -nouser -o -nogroup -print
*
리모트 호스트 (.rhosts) 파일들은 절대로 있으면 안되는 것이기 때문에, 이것들을 찾는 것은 시스템 관리자 임무의 일부가 되어야만 한다. 주지할 것은 크랙커가 여러분 네트워크에 침투하기 위해서는 단 한 개의 불안전한 계정이 필요할 뿐이라는 것이다. 시스템의 모든 리모트 호스트 파일들은 다음의 명령어로 찾을 수 있다.
root# find /home -name .rhosts -print
*
마지막으로, 무턱대고 시스템 파일의 허가권을 바꾸지 말고, 어떤 파일이 무슨 작업을 하도록 되어 있는 가를 정확히 이해하도록 한다. 단순한 작동의 이유만으로 파일의 허가권을 바꾸는 일이 없도록 해야 한다. 허가권을 바꾸기 전에 파일이 왜 이러한 허가권을 가지고 있는지 알도록 해야 한다.ㅌㅊ
5.1 umask 조정
umask 명령어는 시스템 파일이 만들어질 때의 허가권 기본값을 정하기 위해서 사용된다. umask에는 정하려는 파일 모드의 십진 전수 (Octal Complement)를 사용한다. 만약 허가권 기본값을 정하지 않은 상태에서 파일이 형성된 게 된다면, 사용자가 모르는 사이에 허가권을 가지면 안되는 누군가에게 읽기 쓰기 허가권을 주게 될 수가 있다. 일반적으로 umask 값은 022 027, 그리고 (제일 제한적인) 077 등이 있다. umask는 일반적으로 /etc/profile에서 조정되고, 시스템의 모든 사용자에게 적용된다. 문서 생성 기본값 (File creation mask)은 7.7.7.에서 원하는 수를 빼면 나온다. 다시 설명하면, 7.7.7.로 umask값을 정해 준 경우에는 새로 만들어지는 모든 문서는 (소유자를 포함한) 모든 사용자들에 게 읽기, 쓰기, 실행권을 주지 않게 된다. umask값이 666이라면, 새로 만들어지는 모든 문서는 111의 (허가권의) 기본값을 가지게 된다. umask값을 033으로 정해 준 예를 들겠다. [11. 십진 전수]
# Set the user's default umask
umask 033
특히 루트의 umask 값은 077로 정해서 읽기, 쓰기, 실행을 -- 루트가 직접 chmod를 써서 바꿔 주지 않는 한 -- 다른 사용자가 못하도록 만드는 것이 좋다. 하여간 위의 예인 033인 경우, 새로 만들어지는 디렉토리들은 -- 777에서 033을 뺀 -- 744 허가권을 가질 것이다. 루트의 mask 값은 077이 되므로, 다른 사용자가 --chmod를 써서 뚜렷이 명시하며 바꿔 주지 않는 한 -- 읽고 쓰고 실행할 수 없도록 만들어 주는 것이다 033 umask를 정해 놓은 후에 만들어지는 문서들은 644 허가권을 가지게 된다.
레드 햇을 쓴다면 -- 레드 햇의 사용자의 그룹 ID 구성 방법 (User Private Group rules)을 따른다는 가정 하에 -- umask는 002라도 좋다. 기본 구성은 한 그룹 당 한 사용자로 되어 있기 때문이다.
5.2 파일 허가권 (File Permissions)
시스템 관리를 할 권리가 없는 사용자나 그룹이 시스템 파일을 임의로 편집하는 일이 없도록 하는 것은 당연히 중요한 것이다.
유닉스는 파일과 파일에 대한 엑세스 관리를 owner, group, 그리고 other라는 세 가지 특성으로 구분한다. 언제나 정확히 하나의 소유자 (owner)가 존재하며, 그룹의 멤버 수는 일정하지 않으며, 나머지 사용자들은 other가 된다.
유닉스 허가권에 대한 간단한 설명:
소유권 (Ownership) - 어떤 사용자나 그룹이 노드와 상위 노드의 허가권에 대한 조정을 할 수 있는 권한을 말한다.
허가권 (permission) - 특정 종류의 엑세스가 가능하도록 정해 주거나 변경될 수 있는 비트다. 디렉토리에 대한 허가권은 파일에 대한 허가권과는 다른 의미를 가질 수가 있다.
읽기 허가권 (Read):
* 파일의 내용을 볼 수 있는 것이 가능하다.
* 디렉토리를 읽는 것이 가능하다.
쓰기 허가권 (Write):
* 파일에 만들거나 변경을 하는 것이 가능하다.
* 디렉토리에 있는 파일을 지우거나 이동하는 것이 가능하다.
실행 허가권(Execute):
* 이진 풀그림 (binary)이나 쉘 스크립트를 실행할 수 있다.
* 읽기 허가권이 있다면 디렉토리를 탐색하는 것이 가능하다.
문서 성질의 보존 (Save Text Attribute): (디렉토리의 경우)
"스틱키 비트 (sticky bit)"는 디렉토리에 적용될 경우에는 다른 뜻을 가지게 된다. 디렉토리에 스틱키 비트가 붙을 때에는 사용자는 -- 설령 사용자가 디렉토리에 일반적인 쓰기 허가권이 있더라도 -- 소유권이 있거나 확실하게 쓰기 허가권이 허락된 파일 만 지울 수 있게 된다. 이것은 /tmp 따위의 -- 월드-라이타블이면서도 일반 사용자가 무조건 파일을 지우면 좋지 않을 -- 디렉토리 등을 위해 쓰여진다. 스틱키 비트는 긴 디렉토리 리스팅 (ls -l)에서 t로 표시된다.
SUID의 성질 (파일의 경우)
이것은 파일의 set-user-id 허가권을 정의할 때 사용된다. 소유자 허가권에 set-user-id 엑세스 모드가 붙으면 --그리고 파일이 실행 가능한 파일이라면-- 이 파일을 실행하는 프로세스는 프로세스를 만든 사용자가 사용할 수 있는 시스템 리소스를 쓸 수 있는 권한이 부여된다. 이것은 "버퍼 오버플로우 (buffer overflow: 이하 버퍼 범람)"을 사용하는 많은 침탈법의 재료로 쓰여진다.
SGID의 성질 (파일의 경우)
그룹 허가권에 붙은 경우에는 이 비트가 "set-group-id"를 관리하게 된다. 이것은 그룹이 영향을 받는다는 점을 제외한다면 SUID와 같은 역할을 하는 것이다. 영향을 받으려면 역시 파일은 실행 가능하도록 정의되어야 한다.
SGID 어트리뷰트 (디렉토리의 경우)
만약 SGID를 디렉토리에 사용하면 ("chmod g+s 디렉토리"를 씀), 그 디렉토리 안의 파일들은 디렉토리 소유 그룹의 값을 기본 그룹 값으로 가지게 된다.
여러분 - 파일의 소유자 (owner)
그룹 - 여러분이 가입되어 있는 그룹 (group)
나머지 모든 이 - 파일의 소유자나 파일을 소유한 그룹에 속하지 않은 나머지 사용자 (other)
파일의 보기:
-rw-r--r-- 1 kevin users 114 Aug 28 1997 .zlogin
1번 비트 (-) 디렉토리인가? (아니다)
2번 비트 (r) 소유자에 읽기권? (있다. 케빈이 읽을 수 있다)
3번 비트 (w) 소유자가 쓰기권? (있다. 케빈이 읽을 수 있다)
4번 비트 (-) 소유자에 실행권? (없다)
5번 비트 (r) 그룹에 읽기권? (있다. users라는 그룹)
6번 비트 (-) 그룹에 쓰기권? (없다)
7번 비트 (-) 그룹에 실행권? (없다)
8번 비트 (r) 모든 이에 읽기권? (있다. 모든 이가 읽을 수 있다)
9번 비트 (-) 모든 이 쓰기권? (없다)
10번 비트 (-) 모든 이에 실행권? (없다)
아래에는 필요한 만큼만의 최소한의 허가권을 부여한 보기를 적어 놓았다. 더 큰 허가권을 주는 것이 가능하지만, 설명된 작업 용도에 알맞은 최소 한도로 예를 설정해 놓은 것임을 밝혀 둔다.
-r-------- 소유자의 읽기 허가권이 파일에 있다.
--w------- 소유자가 파일을 변경하거나 지울 수 있다.
---x------ 소유자가 파일 (풀그림)을 실행할 수 있지만, 읽기권도 있어야
실행되는 쉘 스크립트는 실행하지 못한다.
---s------ 실세의 사용자 ID를 가진 개인이라면 실행할 수 있다.
(setuid 참조)
-------s-- 실세의 사용자 ID를 가진 그룹이라면 실행할 수 있다.
(setgid 참조)
-rw------T "최근 바뀐 시간 (last modified time)" 정보가 갱신되지 않는다.
스왑 파일 등에 사용된다.
---t------ 상관없음 (전에는 스틱키 비트였음)
디렉토리의 보기:
drwxr-xr-x 3 kevin users 512 Sep 19 13:47 .public_html/
1번 비트 (d) 디렉토리인가? (그렇다. 많은 파일을 가지고 있다)
2번 비트 (r) 소유자의 읽기권? (있다. 케빈)
3번 비트 (w) 소유자의 쓰기권? (있다. 케빈)
4번 비트 (x) 소유자의 실행권? (있다. 케빈)
5번 비트 (r) 그룹의 읽기권? (있다. users 그룹)
6번 비트 (-) 그룹의 쓰기권? (없다)
7번 비트 (x) 그룹의 실행권? (있다. users 그룹)
8번 비트 (r) 다른 이의 읽기권? (있다. 아무나 읽을 수 있다)
9번 비트 (-) 다른 이의 쓰기권? (없다)
10번 비트 (x) 다른 이의 실행권? (있다. 아무나 실행할 수 있다)
아래는 최소의 허가권을 준 사용 보기이다. 여기에 설명되어 있는 것 보다 허가권을 더 주는 것은 가능하지만, 아래에 설명하는 정도는 최소 한도로 필요하다.
dr-------- 내용은 보여질 수 있지만, 파일 어트리뷰트는 읽을 수 없게 된다.
d--x------ 디렉토리는 실행 패스 (path)에 넣어져서 사용될 수 있다.
dr-x------ 파일 어트리뷰트는 이제 소유자에 의해서 읽혀질 수 있다.
d-wx------ 디렉토리 현 위치에 있지 않아도 파일은 만들어지고
지워질 수 있다.
d------x-t 쓰기 엑세스를 가진 다른 사용자들이 파일을 함부로 지우는 것을
막는다. /tmp 디렉토리에 사용된다.
d---s--s-- 아무런 작용을 하지 않는다. (SUID와 SGID 참조)
(보통 /etc 안에 있는) 시스템 설정 파일 (system configuration files)들은 640 (-rw-r-----) 모드이면서 동시에 루트 소유로 되어 있다. [12] 이것은 여러분 사이트의 보안 필요에 따라서 바꾸면 된다. 시스템 파일은 절대로 다른 어떤 그룹이나 누구라도 쓸 수 있도록 하면 안된다. /etc/shadow를 포함한 시스템 파일의 일부는 루트만이 읽기 허가권을 가져야 하고, /etc 안의 디렉토리들은 다른 이들이 읽지 못하도록 해야 한다.
SUID 쉘 스크립트:
SUID 쉘 스크립트는 심각한 보안 위험 요소이며, 그런 이유 때문에 커널이 받아들이지 않도록 되어 있다. 여러분이 얼마나 쉘 스크립트가 안전하다고 생각을 하던 간에, 이것은 크랙커에게 루 트 쉘을 주는 침탈 도구가 될 수 있다.
5.3 완결성의 검사
트립와이어 (Tripwire), 에이드 Aide, 오사이리스 (Osiris) 등의 완결성 (Integrity) 유지용 검사 도구를 사용하는 것은 지역 사용자가 펼치는 (그리고 네트워크를 통해서 들어오는) 공격을 탐지해 내는 매우 좋은 방법이다. 트립와이어, 에이드, 오사이리스 등은 중요한 이진 파일들과 설정 파일들의 첵섬 (checksum) 값을 검출해서 이전에 만들어 놓은 데이타베이스와 비교한다. 파일에 변화가 있으면 표시가 날 것이다. 이러한 풀그림을 쓰는 경우에는 플로피에 설치하고 쓰기 방지 탭을 사용해서 쓰는 것이 좋다. 이렇게 해 놓으면 침입자는 이러한 검사 풀그림에 손을 대거나 데이타베이스를 바꾸지 못하게 된다. 일단 한 번 설치했으면, 일상적인 보안 관리 임무의 일부분으로서 관례적, 주기적으로 실행하는 것이 좋다.
트립와이어 등의 검사 풀그림을 매일 밤 플로피에서 돌리고 아침에 메일로 결과를 받도록 다음과 같이 크론탭을 설정할 수 있다.
# set mailto
MAILTO=kevin
# run Tripwire
15 05 * * * root /usr/local/adm/tcheck/tripwire
이와 같이 하면 매일 아침 5:15am에 리포트를 보내 줄 것이다.
이러한 검사기는 여러분이 직접 침입자를 눈치채기 훨씬 전에 미리 자동으로 알려주는 귀중한 존재가 될 수 있다. 하지만 일반적 시스템 안에서는 많은 파일이 항시 바뀌므로 변한 것이 여러분의 일 때문인가, 아니면 크랙커의 행동인가를 파악하는 것에 신중을 기하도록 한다.
오픈 소스 버전으로 만들어진 트립와이어 (Tripwire)는 http://www.tripwire.org에서 무료로 구할 수 있다. 매뉴얼과 고객 지원은 따로 구입해야 한다.
에이드(Aide)는 http://www.cs.tut.fi/~rammer/aide.html를 참조할 것.
오사이리스 (Osiris)는 http://www.shmoo.com/osiris/를 참조할 것. 1086:
5.4 트로이의 목마
트로이의 목마는 호머의 일리어드에 나오는 전설적인 책략에서 비롯된 이름이다. 그럴듯해 보이는 어떤 풀그림이나 이진 파일을 업로드해 놓고, 다른 사람들이 그것을 다운 받아서 루트로서 돌리도록 한다. 그런 뒤에 사용자가 신경을 주지 않는 틈을 타서 시스템에 깨고 들어오는 것이다. 방금 받은 이진 파일이 관리자가 애초에 기대했던 어떤 일을 한다고 생각하는 사이에 --정말로 그런 척 하기도 한다-- 한편으로는 보안을 깨고 들어오는 것이다.
여러분의 컴퓨터에 무슨 풀그림을 설치하였는지는 잘 살피도록 해야 한다. 레드 햇은 RPM 파일의 MD5 첵섬과 PGP 시그니춰를 제공하므로, 설치하고 있는 풀그림이 진짜인지 확인할 수 있다. 다른 배포본도 비슷한 방법을 쓴다. 소스도 있거나 잘 알려진 것이 아닌 한, 루트의 권한으로 어떤 이진 파일도 실행되어서는 안 된다! 일반 대중이 정밀한 조사를 할 수 있도록 소스를 공개할 크랙커는 없다시피 하므로.
귀찮을 수도 있지만, 풀그림의 소스를 정품 배포 장소에서 가져왔는지 확인하도록 하라. 풀그림이 루트에서 실행될 상황이라면 여러분이나 믿을 만한 누군가가 소스를 훑어보고 확인하도록 해야 한다.
Copyright(c) 2001, 수퍼유저코리아 All Right Reserved.
서버구축(운용)상담 : e-mail : webmaster@superuser.co.kr
5. 파일과 파일시스템 보안
시스템을 온라인으로 접속시키기 전에, 몇 분 동안이나마 준비와 계획을 하는 것은 여러분의 시스템과 데이타를 보호하는 것에 큰 도움을 준다.
* SUID/SGID를 사용자의 홈 디렉토리에서 쓰게 할 이유가 전혀 없다. 루트가 아닌 다른 사용자들이 자료를 쓸 수 있도록, 쓰기가 허락된 (writable로 되어 있는) 파티션에는 /etc/fstab에 nosuid 옵션을 적어 놓도록 한다. 이런 방법 등으로 어차피 필요 없어야 하는 -- 풀그림의 실행을 금지하며, 블록 디바이스의 형성을 못하도록 -- /var를 포함해서, 사용자의 홈 파티션에는 nodev와 noexec을 옵션으로 적어 놓도록 한다.
*
*
만약 NFS를 써서 파일시스템을 네트워크로 송출 (export)하는 경우라면, /etc/exports를 최대 한도로 제한하도록 조정하도록 한다. 이것은 와일드카드를 쓰지 않는 것과, 루트 쓰기 엑세스 (root write access)를 허락하지 않는 것과, 가능하면 읽기 전용의 파일시스템만을 송출하도록 하는 것을 의미한다.
*
사용자의 파일 생성 umask를 가능한 제한된 값으로 조정한다. [umask 값]을 참조한다.
*
NFS 등의 네트워크 파일시스템을 마운트한다면, /etc/exports를 조정해서 적절한 제한을 주도록 한다. 보통 'nodev'와 'nosuid'를 쓰는 것이 바람직하고, 'noexec'까지도 고려하는 것이 좋다.
*
기본값인 "무제한 (unlimited)"이 아닌 값으로 파일시스템의 기본값을 제한한다. 자원 제한 PAM 모듈과 /etc/pam.d/limits.comf를 사용함으로서 사용자 각각의 제한치를 조정한다. 예를 들면, users 그룹을 위한 제한은 다음과 같을 수 있다.
@users hard core 0
@users hard nproc 50
@users hard rss 5000
이 경우는 코어 파일의 생성을 금하며, 프로세스의 수를 50으로 제한하며, 사용자 한 사람 당 메모리 사용을 5 메가로 제한함을 말한다.
*
/var/log/wtmp와 /var/rin/utmp 파일들은 시스템 모든 사용자의 접속 기록을 가지고 있다. 이들은 사용자가 (혹은 잠재적 침입자가) 언제, 어디서 시스템에 들어왔는가를 조사하기 위한 작업 사용되므로 이 파일들의 보안과 보전은 철저히 유지되어야만 된다. 일반적인 시스템 작동에 영향을 주는 경우가 없도록 함과 동시에 644 허가권을 가지고 있어야 한다.
*
보호되어야만 하는 파일들을 실수로 지우거나 덧쓰는 경우가 없도록 하기 위해서 이뮤타블 비트 (immutable bit: 불변의 비트)를 사용한다. 또한 이 방법은 파일에 -- /etc/passwd나 /etc/shadow를 조작하는 방법의 일부가 되는, -- 심볼릭 링크를 만드는 것을 방지한다. 이뮤타블 비트에 대한 추가 정보는 chattr(1)의 man 페이지를 참조하도록 할 것.
*
SUID와 SGID는 잠재적인 보안 위험 요소이기 때문에 철저하게 감시되어야 만 한다. 이 풀그림들은 이 들을 사용하는 사용자들에게 특별 권한을 부여해 주기 때문에, 보안에 불안 요소를 주는 이러한 풀그림들이 설치되는 일이 없도록 해야 한다. 크랙커들이 좋아하는 트릭 중 의 하나는 SUID 루트 프로그램을 침탈하고 그 후에 -- 원래의 문제점이 고쳐진 후에라도 -- SUID 풀그림을 통해 뒷문의 개구멍으로 들어오는 것이다.
그러므로, 여러분 시스템에 있는 모든 SUDI/SGID를 찾아내서, 그것들이 무엇인지 추적함으로서 --잠재적인 침입자를 의미할 수 있는-- 어떠한 변화라도 알 수 있도록 한다. 다음의 명령어를 사용하면 시스템에 있는 모든 SUID/SGID 풀그림을 찾아낼 수 있다.
root# find / -type f \\( -perm -04000 -o -perm -02000 \\)
데비안 디스트리뷰션을 쓰면 어떤 SUID 문서가 존재하는지 매일 밤 확인하는 작업 (Job)을 실행할 수 있고. 그 결과를 전날 밤의 결과와 비교를 할 수가 있다. /var/log/suid*를 보면 이 작업의 일지를 볼 수 있다. 원한다면 의심스러운 SUID나 SGID 허가권을 가진 풀그림을 chmod를 써서 지우거나 바꿀 수 있을 것이다.
chmod를 사용하면 의심쩍은 풀그림의 SUID나 SGID 허가권을 제한적으로 지울 수 있고, 필요함이 나중에라도 확실하게 느껴진다면 다시 복구해 주면 된다.
*
만약 크랙커가 시스템의 사용권을 얻고 -- 특히 시스템 파일 등의 -- 월드-라이타블(World-writable) 파일들을 마음대로 변경할 수 있게 된다면 그야말로 이 것은 심각한 보안 개구멍이 존재하게 된 것이라고 할 수 있다. 덧붙이면 -- 크랙커들이 마음대로 파일을 덧붙이거나 지울 수가 있게 되므로 -- 월드-라이타블 디렉토리 또한 위험한 존재인 것이다. 월드-라이타블 파일 모두를 찾기 위해서는 다음의 명령어를 사용한다.
root# find / -perm -2 -type l -ls
그리고 이 파일들이 왜 "쓰기 가능 (라이타블)"으로 설정되어 있는지 반드시 파악하도록 한다. 정상적인 운영의 경우에 있어서, /dev의 일부와 심볼릭 링크를 포함한 여러 파일들은 월드-라이타블로 되어 있어야 할 것이다. (In the normal course of operation, several files will be writable, including some world-writable, including from /dev, and symbolic links. some from /dev, and symbolic links, thus the ! -type l which excludes these from the previous find command.)
*
주인이 없는 무소속의 파일들 또한 침입자가 시스템에 들어왔다는 징후일 수 있다. 주인이 없거나 그룹에 소속되어 있지 않은 파일들은 다음의 명령어를 쓰면 찾아낼 수 있다.
root# find / -nouser -o -nogroup -print
*
리모트 호스트 (.rhosts) 파일들은 절대로 있으면 안되는 것이기 때문에, 이것들을 찾는 것은 시스템 관리자 임무의 일부가 되어야만 한다. 주지할 것은 크랙커가 여러분 네트워크에 침투하기 위해서는 단 한 개의 불안전한 계정이 필요할 뿐이라는 것이다. 시스템의 모든 리모트 호스트 파일들은 다음의 명령어로 찾을 수 있다.
root# find /home -name .rhosts -print
*
마지막으로, 무턱대고 시스템 파일의 허가권을 바꾸지 말고, 어떤 파일이 무슨 작업을 하도록 되어 있는 가를 정확히 이해하도록 한다. 단순한 작동의 이유만으로 파일의 허가권을 바꾸는 일이 없도록 해야 한다. 허가권을 바꾸기 전에 파일이 왜 이러한 허가권을 가지고 있는지 알도록 해야 한다.ㅌㅊ
5.1 umask 조정
umask 명령어는 시스템 파일이 만들어질 때의 허가권 기본값을 정하기 위해서 사용된다. umask에는 정하려는 파일 모드의 십진 전수 (Octal Complement)를 사용한다. 만약 허가권 기본값을 정하지 않은 상태에서 파일이 형성된 게 된다면, 사용자가 모르는 사이에 허가권을 가지면 안되는 누군가에게 읽기 쓰기 허가권을 주게 될 수가 있다. 일반적으로 umask 값은 022 027, 그리고 (제일 제한적인) 077 등이 있다. umask는 일반적으로 /etc/profile에서 조정되고, 시스템의 모든 사용자에게 적용된다. 문서 생성 기본값 (File creation mask)은 7.7.7.에서 원하는 수를 빼면 나온다. 다시 설명하면, 7.7.7.로 umask값을 정해 준 경우에는 새로 만들어지는 모든 문서는 (소유자를 포함한) 모든 사용자들에 게 읽기, 쓰기, 실행권을 주지 않게 된다. umask값이 666이라면, 새로 만들어지는 모든 문서는 111의 (허가권의) 기본값을 가지게 된다. umask값을 033으로 정해 준 예를 들겠다. [11. 십진 전수]
# Set the user's default umask
umask 033
특히 루트의 umask 값은 077로 정해서 읽기, 쓰기, 실행을 -- 루트가 직접 chmod를 써서 바꿔 주지 않는 한 -- 다른 사용자가 못하도록 만드는 것이 좋다. 하여간 위의 예인 033인 경우, 새로 만들어지는 디렉토리들은 -- 777에서 033을 뺀 -- 744 허가권을 가질 것이다. 루트의 mask 값은 077이 되므로, 다른 사용자가 --chmod를 써서 뚜렷이 명시하며 바꿔 주지 않는 한 -- 읽고 쓰고 실행할 수 없도록 만들어 주는 것이다 033 umask를 정해 놓은 후에 만들어지는 문서들은 644 허가권을 가지게 된다.
레드 햇을 쓴다면 -- 레드 햇의 사용자의 그룹 ID 구성 방법 (User Private Group rules)을 따른다는 가정 하에 -- umask는 002라도 좋다. 기본 구성은 한 그룹 당 한 사용자로 되어 있기 때문이다.
5.2 파일 허가권 (File Permissions)
시스템 관리를 할 권리가 없는 사용자나 그룹이 시스템 파일을 임의로 편집하는 일이 없도록 하는 것은 당연히 중요한 것이다.
유닉스는 파일과 파일에 대한 엑세스 관리를 owner, group, 그리고 other라는 세 가지 특성으로 구분한다. 언제나 정확히 하나의 소유자 (owner)가 존재하며, 그룹의 멤버 수는 일정하지 않으며, 나머지 사용자들은 other가 된다.
유닉스 허가권에 대한 간단한 설명:
소유권 (Ownership) - 어떤 사용자나 그룹이 노드와 상위 노드의 허가권에 대한 조정을 할 수 있는 권한을 말한다.
허가권 (permission) - 특정 종류의 엑세스가 가능하도록 정해 주거나 변경될 수 있는 비트다. 디렉토리에 대한 허가권은 파일에 대한 허가권과는 다른 의미를 가질 수가 있다.
읽기 허가권 (Read):
* 파일의 내용을 볼 수 있는 것이 가능하다.
* 디렉토리를 읽는 것이 가능하다.
쓰기 허가권 (Write):
* 파일에 만들거나 변경을 하는 것이 가능하다.
* 디렉토리에 있는 파일을 지우거나 이동하는 것이 가능하다.
실행 허가권(Execute):
* 이진 풀그림 (binary)이나 쉘 스크립트를 실행할 수 있다.
* 읽기 허가권이 있다면 디렉토리를 탐색하는 것이 가능하다.
문서 성질의 보존 (Save Text Attribute): (디렉토리의 경우)
"스틱키 비트 (sticky bit)"는 디렉토리에 적용될 경우에는 다른 뜻을 가지게 된다. 디렉토리에 스틱키 비트가 붙을 때에는 사용자는 -- 설령 사용자가 디렉토리에 일반적인 쓰기 허가권이 있더라도 -- 소유권이 있거나 확실하게 쓰기 허가권이 허락된 파일 만 지울 수 있게 된다. 이것은 /tmp 따위의 -- 월드-라이타블이면서도 일반 사용자가 무조건 파일을 지우면 좋지 않을 -- 디렉토리 등을 위해 쓰여진다. 스틱키 비트는 긴 디렉토리 리스팅 (ls -l)에서 t로 표시된다.
SUID의 성질 (파일의 경우)
이것은 파일의 set-user-id 허가권을 정의할 때 사용된다. 소유자 허가권에 set-user-id 엑세스 모드가 붙으면 --그리고 파일이 실행 가능한 파일이라면-- 이 파일을 실행하는 프로세스는 프로세스를 만든 사용자가 사용할 수 있는 시스템 리소스를 쓸 수 있는 권한이 부여된다. 이것은 "버퍼 오버플로우 (buffer overflow: 이하 버퍼 범람)"을 사용하는 많은 침탈법의 재료로 쓰여진다.
SGID의 성질 (파일의 경우)
그룹 허가권에 붙은 경우에는 이 비트가 "set-group-id"를 관리하게 된다. 이것은 그룹이 영향을 받는다는 점을 제외한다면 SUID와 같은 역할을 하는 것이다. 영향을 받으려면 역시 파일은 실행 가능하도록 정의되어야 한다.
SGID 어트리뷰트 (디렉토리의 경우)
만약 SGID를 디렉토리에 사용하면 ("chmod g+s 디렉토리"를 씀), 그 디렉토리 안의 파일들은 디렉토리 소유 그룹의 값을 기본 그룹 값으로 가지게 된다.
여러분 - 파일의 소유자 (owner)
그룹 - 여러분이 가입되어 있는 그룹 (group)
나머지 모든 이 - 파일의 소유자나 파일을 소유한 그룹에 속하지 않은 나머지 사용자 (other)
파일의 보기:
-rw-r--r-- 1 kevin users 114 Aug 28 1997 .zlogin
1번 비트 (-) 디렉토리인가? (아니다)
2번 비트 (r) 소유자에 읽기권? (있다. 케빈이 읽을 수 있다)
3번 비트 (w) 소유자가 쓰기권? (있다. 케빈이 읽을 수 있다)
4번 비트 (-) 소유자에 실행권? (없다)
5번 비트 (r) 그룹에 읽기권? (있다. users라는 그룹)
6번 비트 (-) 그룹에 쓰기권? (없다)
7번 비트 (-) 그룹에 실행권? (없다)
8번 비트 (r) 모든 이에 읽기권? (있다. 모든 이가 읽을 수 있다)
9번 비트 (-) 모든 이 쓰기권? (없다)
10번 비트 (-) 모든 이에 실행권? (없다)
아래에는 필요한 만큼만의 최소한의 허가권을 부여한 보기를 적어 놓았다. 더 큰 허가권을 주는 것이 가능하지만, 설명된 작업 용도에 알맞은 최소 한도로 예를 설정해 놓은 것임을 밝혀 둔다.
-r-------- 소유자의 읽기 허가권이 파일에 있다.
--w------- 소유자가 파일을 변경하거나 지울 수 있다.
---x------ 소유자가 파일 (풀그림)을 실행할 수 있지만, 읽기권도 있어야
실행되는 쉘 스크립트는 실행하지 못한다.
---s------ 실세의 사용자 ID를 가진 개인이라면 실행할 수 있다.
(setuid 참조)
-------s-- 실세의 사용자 ID를 가진 그룹이라면 실행할 수 있다.
(setgid 참조)
-rw------T "최근 바뀐 시간 (last modified time)" 정보가 갱신되지 않는다.
스왑 파일 등에 사용된다.
---t------ 상관없음 (전에는 스틱키 비트였음)
디렉토리의 보기:
drwxr-xr-x 3 kevin users 512 Sep 19 13:47 .public_html/
1번 비트 (d) 디렉토리인가? (그렇다. 많은 파일을 가지고 있다)
2번 비트 (r) 소유자의 읽기권? (있다. 케빈)
3번 비트 (w) 소유자의 쓰기권? (있다. 케빈)
4번 비트 (x) 소유자의 실행권? (있다. 케빈)
5번 비트 (r) 그룹의 읽기권? (있다. users 그룹)
6번 비트 (-) 그룹의 쓰기권? (없다)
7번 비트 (x) 그룹의 실행권? (있다. users 그룹)
8번 비트 (r) 다른 이의 읽기권? (있다. 아무나 읽을 수 있다)
9번 비트 (-) 다른 이의 쓰기권? (없다)
10번 비트 (x) 다른 이의 실행권? (있다. 아무나 실행할 수 있다)
아래는 최소의 허가권을 준 사용 보기이다. 여기에 설명되어 있는 것 보다 허가권을 더 주는 것은 가능하지만, 아래에 설명하는 정도는 최소 한도로 필요하다.
dr-------- 내용은 보여질 수 있지만, 파일 어트리뷰트는 읽을 수 없게 된다.
d--x------ 디렉토리는 실행 패스 (path)에 넣어져서 사용될 수 있다.
dr-x------ 파일 어트리뷰트는 이제 소유자에 의해서 읽혀질 수 있다.
d-wx------ 디렉토리 현 위치에 있지 않아도 파일은 만들어지고
지워질 수 있다.
d------x-t 쓰기 엑세스를 가진 다른 사용자들이 파일을 함부로 지우는 것을
막는다. /tmp 디렉토리에 사용된다.
d---s--s-- 아무런 작용을 하지 않는다. (SUID와 SGID 참조)
(보통 /etc 안에 있는) 시스템 설정 파일 (system configuration files)들은 640 (-rw-r-----) 모드이면서 동시에 루트 소유로 되어 있다. [12] 이것은 여러분 사이트의 보안 필요에 따라서 바꾸면 된다. 시스템 파일은 절대로 다른 어떤 그룹이나 누구라도 쓸 수 있도록 하면 안된다. /etc/shadow를 포함한 시스템 파일의 일부는 루트만이 읽기 허가권을 가져야 하고, /etc 안의 디렉토리들은 다른 이들이 읽지 못하도록 해야 한다.
SUID 쉘 스크립트:
SUID 쉘 스크립트는 심각한 보안 위험 요소이며, 그런 이유 때문에 커널이 받아들이지 않도록 되어 있다. 여러분이 얼마나 쉘 스크립트가 안전하다고 생각을 하던 간에, 이것은 크랙커에게 루 트 쉘을 주는 침탈 도구가 될 수 있다.
5.3 완결성의 검사
트립와이어 (Tripwire), 에이드 Aide, 오사이리스 (Osiris) 등의 완결성 (Integrity) 유지용 검사 도구를 사용하는 것은 지역 사용자가 펼치는 (그리고 네트워크를 통해서 들어오는) 공격을 탐지해 내는 매우 좋은 방법이다. 트립와이어, 에이드, 오사이리스 등은 중요한 이진 파일들과 설정 파일들의 첵섬 (checksum) 값을 검출해서 이전에 만들어 놓은 데이타베이스와 비교한다. 파일에 변화가 있으면 표시가 날 것이다. 이러한 풀그림을 쓰는 경우에는 플로피에 설치하고 쓰기 방지 탭을 사용해서 쓰는 것이 좋다. 이렇게 해 놓으면 침입자는 이러한 검사 풀그림에 손을 대거나 데이타베이스를 바꾸지 못하게 된다. 일단 한 번 설치했으면, 일상적인 보안 관리 임무의 일부분으로서 관례적, 주기적으로 실행하는 것이 좋다.
트립와이어 등의 검사 풀그림을 매일 밤 플로피에서 돌리고 아침에 메일로 결과를 받도록 다음과 같이 크론탭을 설정할 수 있다.
# set mailto
MAILTO=kevin
# run Tripwire
15 05 * * * root /usr/local/adm/tcheck/tripwire
이와 같이 하면 매일 아침 5:15am에 리포트를 보내 줄 것이다.
이러한 검사기는 여러분이 직접 침입자를 눈치채기 훨씬 전에 미리 자동으로 알려주는 귀중한 존재가 될 수 있다. 하지만 일반적 시스템 안에서는 많은 파일이 항시 바뀌므로 변한 것이 여러분의 일 때문인가, 아니면 크랙커의 행동인가를 파악하는 것에 신중을 기하도록 한다.
오픈 소스 버전으로 만들어진 트립와이어 (Tripwire)는 http://www.tripwire.org에서 무료로 구할 수 있다. 매뉴얼과 고객 지원은 따로 구입해야 한다.
에이드(Aide)는 http://www.cs.tut.fi/~rammer/aide.html를 참조할 것.
오사이리스 (Osiris)는 http://www.shmoo.com/osiris/를 참조할 것. 1086:
5.4 트로이의 목마
트로이의 목마는 호머의 일리어드에 나오는 전설적인 책략에서 비롯된 이름이다. 그럴듯해 보이는 어떤 풀그림이나 이진 파일을 업로드해 놓고, 다른 사람들이 그것을 다운 받아서 루트로서 돌리도록 한다. 그런 뒤에 사용자가 신경을 주지 않는 틈을 타서 시스템에 깨고 들어오는 것이다. 방금 받은 이진 파일이 관리자가 애초에 기대했던 어떤 일을 한다고 생각하는 사이에 --정말로 그런 척 하기도 한다-- 한편으로는 보안을 깨고 들어오는 것이다.
여러분의 컴퓨터에 무슨 풀그림을 설치하였는지는 잘 살피도록 해야 한다. 레드 햇은 RPM 파일의 MD5 첵섬과 PGP 시그니춰를 제공하므로, 설치하고 있는 풀그림이 진짜인지 확인할 수 있다. 다른 배포본도 비슷한 방법을 쓴다. 소스도 있거나 잘 알려진 것이 아닌 한, 루트의 권한으로 어떤 이진 파일도 실행되어서는 안 된다! 일반 대중이 정밀한 조사를 할 수 있도록 소스를 공개할 크랙커는 없다시피 하므로.
귀찮을 수도 있지만, 풀그림의 소스를 정품 배포 장소에서 가져왔는지 확인하도록 하라. 풀그림이 루트에서 실행될 상황이라면 여러분이나 믿을 만한 누군가가 소스를 훑어보고 확인하도록 해야 한다.
Copyright(c) 2001, 수퍼유저코리아 All Right Reserved.
서버구축(운용)상담 : e-mail : webmaster@superuser.co.kr
관련자료
-
링크
댓글 0
등록된 댓글이 없습니다.
