BLUE STUDY

Kevin Fenzi (kevin@tummy.com)
Dave Wreski (dave@nic.com)
v1.1.0 2000년 3월 8일
장범수 bschang@kldp.org
2000년 5월 9일

-----------------------------------------------------------------------------------
이 문서는 Linux System 관리자가 상대하게 되는 보안 이슈에 대한 일반적 개론을 밝힌다. 일반적인 보안 철학 등과 Linux System을 침입자로부터 보호할 방법 등의 특정 보기를 몇 가지 적어 놓았다. 보안에 관계된 자료들과 Program을 구할 수 있는 곳도 적어 놓았다. 개선 사항, 건설적인 비평, 첨가 사안, 그리고 수정안 등을 감사한 마음으로 수용하겠다. 여러분의 의견은 두 저자 모두에게 "Security HOWTO"를 Mail의 제목에 써서 보내 주기 바란다
-----------------------------------------------------------------------------------

5. File과 File System 보안

System을 On-Line으로 접속시키기 전에, 몇 분 동안이나마 준비와 계획을 하는 것은 여러분의 System과 Data를 보호하는 것에 큰 도움을 준다.

SUID/SGID를 사용자의 Home Directory에서 쓰게 할 이유가 전혀 없다. Root가 아닌 다른 사용자들이 자료를 쓸 수 있도록, 쓰기가 허락된 (writable로 되어 있는) Partition에는 /etc/fstab에 nosuid Option을 적어 놓도록 한다. 이런 방법 등으로 어차피 필요 없어야 하는 -- Program의 실행을 금지하며, Block Device의 형성을 못하도록 -- /var를 포함해서, 사용자의 Home Partition에는 nodev와 noexec을 Option으로 적어 놓도록 한다.

만약 NFS를 써서 File System을 Network로 송출 (export)하는 경우라면, /etc/exports를 최대 한도로 제한하도록 조정하도록 한다. 이것은 와일드카드를 쓰지 않는 것과, Root Write Access를 허락하지 않는 것과, 가능하면 읽기 전용의 File System만을 송출하도록 하는 것을 의미한다.

사용자의 File 생성 umask를 가능한 제한된 값으로 조정한다. [umask 값]을 참조한다.

NFS 등의 Network File System을 Mount한다면, /etc/exports를 조정해서 적절한 제한을 주도록 한다. 보통 'nodev'와 'nosuid'를 쓰는 것이 바람직하고, 'noexec'까지도 고려하는 것이 좋다.

기본값인 "무제한 (unlimited)"이 아닌 값으로 File System의 기본값을 제한한다. 자원 제한 PAM 모듈과 /etc/pam.d/limits.comf를 사용함으로써 사용자 각각의 제한치를 조정한다. 예를 들면, users Group을 위한 제한은 다음과 같을 수 있다.

@users hard core 0
@users hard nproc 50
@users hard rss 5000

이 경우는 Core File의 생성을 금하며, Process의 수를 50으로 제한하며, 사용자 한 사람 당 Memory 사용을 5 MG로 제한함을 말한다.

/var/log/wtmp와 /var/rin/utmp File들은 System 모든 사용자의 접속 기록을 가지고 있다. 이들은 사용자가 (혹은 잠재적 침입자가) 언제, 어디서 System에 들어왔는가를 조사하기 위한 작업 사용되므로 이 File들의 보안과 보전은 철저히 유지되어야만 된다. 일반적인 System 작동에 영향을 주는 경우가 없도록 함과 동시에 644 허가권을 가지고 있어야 한다.

보호되어야만 하는 File들을 실수로 지우거나 덧쓰는 경우가 없도록 하기 위해서 Immutable Bit (불변의 Bit)를 사용한다. 또한 이 방법은 File에 -- /etc/passwd나 /etc/shadow를 조작하는 방법의 일부가 되는, -- Symbolic Link를 만드는 것을 방지한다. Immutable Bit에 대한 추가 정보는 chattr(1)의 man 페이지를 참조하도록 할 것.

SUID와 SGID는 잠재적인 보안 위험 요소이기 때문에 철저하게 감시되어야 만 한다. 이 Program들은 이 들을 사용하는 사용자들에게 특별 권한을 부여해 주기 때문에, 보안에 불안 요소를 주는 이러한 Program들이 설치되는 일이 없도록 해야 한다. Cracker들이 좋아하는 트릭 중 의 하나는 SUID Root 프로그램을 침탈하고 그 후에 -- 원래의 문제점이 고쳐진 후에라도 -- SUID Program을 통해 뒷문의 개구멍으로 들어오는 것이다.

그러므로, 여러분 System에 있는 모든 SUDI/SGID를 찾아내서, 그것들이 무엇인지 추적함으로써 --잠재적인 침입자를 의미할 수 있는-- 어떠한 변화라도 알 수 있도록 한다. 다음의 명령어를 사용하면 System에 있는 모든 SUID/SGID Program을 찾아낼 수 있다.

root# find / -type f \( -perm -04000 -o -perm -02000 \)

데비안 디스트리뷰션을 쓰면 어떤 SUID 문서가 존재하는지 매일 밤 확인하는 작업 (Job)을 실행할 수 있고. 그 결과를 전날 밤의 결과와 비교를 할 수가 있다. /var/log/suid*를 보면 이 작업의 일지를 볼 수 있다. 원한다면 의심스러운 SUID나 SGID 허가권을 가진 Program을 chmod를 써서 지우거나 바꿀 수 있을 것이다.

chmod를 사용하면 의심쩍은 Program의 SUID나 SGID 허가권을 제한적으로 지울 수 있고, 필요함이 나중에라도 확실하게 느껴진다면 다시 복구해 주면 된다.

만약 Cracker가 System의 사용권을 얻고 -- 특히 System File 등의 -- World-Writable File들을 마음대로 변경할 수 있게 된다면 그야말로 이 것은 심각한 보안 개구멍이 존재하게 된 것이라고 할 수 있다. 덧붙이면 -- Cracker들이 마음대로 File을 덧붙이거나 지울 수가 있게 되므로 -- World-Writable Directory 또한 위험한 존재인 것이다. World-Writable File 모두를 찾기 위해서는 다음의 명령어를 사용한다.

root# find / -perm -2 -type l -ls

그리고 이 File들이 왜 "쓰기 가능 (Writable)"으로 설정되어 있는지 반드시 파악하도록 한다. 정상적인 운영의 경우에 있어서, /dev의 일부와 Symbolic Link를 포함한 여러 File들은 World-Writable로 되어 있어야 할 것이다. (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.)

주인이 없는 무소속의 File들 또한 침입자가 System에 들어왔다는 징후일 수 있다. 주인이 없거나 Group에 소속되어 있지 않은 File들은 다음의 명령어를 쓰면 찾아낼 수 있다.

root# find / -nouser -o -nogroup -print

Remote Host (.rhosts) File들은 절대로 있으면 안 되는 것이기 때문에, 이것들을 찾는 것은 System 관리자 임무의 일부가 되어야만 한다. 주지할 것은 Cracker가 여러분 Network에 침투하기 위해서는 단 한 개의 불안전한 계정이 필요할 뿐이라는 것이다. System의 모든 Remote Host File들은 다음의 명령어로 찾을 수 있다.

root# find /home -name .rhosts -print

마지막으로, 무턱대고 System File의 허가권을 바꾸지 말고, 어떤 File이 무슨 작업을 하도록 되어 있는 가를 정확히 이해하도록 한다. 단순한 작동의 이유만으로 File의 허가권을 바꾸는 일이 없도록 해야 한다. 허가권을 바꾸기 전에 File이 왜 이러한 허가권을 가지고 있는지 알도록 해야 한다.

5.1 umask 조정

umask 명령어는 System File이 만들어질 때의 허가권 기본값을 정하기 위해서 사용된다. umask에는 정하려는 File Mode의 십진 전수 (Octal Complement)를 사용한다. 만약 허가권 기본값을 정하지 않은 상태에서 File이 형성된 게 된다면, 사용자가 모르는 사이에 허가권을 가지면 안 되는 누군가에게 읽기 쓰기 허가권을 주게 될 수가 있다. 일반적으로 umask 값은 022 027, 그리고 (제일 제한적인) 077 등이 있다. umask는 일반적으로 /etc/profile에서 조정되고, System의 모든 사용자에게 적용된다. 문서 생성 기본값 (File creation mask)은 7.7.7.에서 원하는 수를 빼면 나온다. 다시 설명하면, 7.7.7.로 umask값을 정해 준 경우에는 새로 만들어지는 모든 문서는 (소유자를 포함한) 모든 사용자들에 게 읽기, 쓰기, 실행권을 주지 않게 된다. umask값이 666이라면, 새로 만들어지는 모든 문서는 111의 (허가권의) 기본값을 가지게 된다. umask값을 033으로 정해 준 예를 들겠다. [11. 십진 전수]

# Set the user's default umask

umask 033

특히 Root의 umask 값은 077로 정해서 읽기, 쓰기, 실행을 -- Root가 직접 chmod를 써서 바꿔 주지 않는 한 -- 다른 사용자가 못하도록 만드는 것이 좋다. 하여간 위의 예인 033인 경우, 새로 만들어지는 Directory들은 -- 777에서 033을 뺀 -- 744 허가권을 가질 것이다. Root의 mask 값은 077이 되므로, 다른 사용자가 --chmod를 써서 뚜렷이 명시하며 바꿔 주지 않는 한 -- 읽고 쓰고 실행할 수 없도록 만들어 주는 것이다 033 umask를 정해 놓은 후에 만들어지는 문서들은 644 허가권을 가지게 된다.

Redhat을 쓴다면 -- Redhat의 사용자의 Group ID 구성 방법 (User Private Group rules)을 따른다는 가정 하에 -- umask는 002라도 좋다. 기본 구성은 한 Group 당 한 사용자로 되어 있기 때문이다.

5.2 File 허가권 (File Permissions)

System 관리를 할 권리가 없는 사용자나 Group이 System File을 임의로 편집하는 일이 없도록 하는 것은 당연히 중요한 것이다.

Unix는 File과 File에 대한 Access 관리를 owner, group, 그리고 other라는 세 가지 특성으로 구분한다. 언제나 정확히 하나의 소유자 (owner)가 존재하며, Group의 Member 수는 일정하지 않으며, 나머지 사용자들은 other가 된다.

Unix 허가권에 대한 간단한 설명:

소유권 (Ownership) - 어떤 사용자나 Group이 Node와 상위 Node의 허가권에 대한 조정을 할 수 있는 권한을 말한다.
허가권 (permission) - 특정 종류의 Access가 가능하도록 정해 주거나 변경될 수 있는 Bit다. Directory에 대한 허가권은 File에 대한 허가권과는 다른 의미를 가질 수가 있다.

읽기 허가권 (Read):

File의 내용을 볼 수 있는 것이 가능하다.
Directory를 읽는 것이 가능하다.

쓰기 허가권 (Write):

File에 만들거나 변경을 하는 것이 가능하다.
Directory에 있는 File을 지우거나 이동하는 것이 가능하다.

실행 허가권(Execute):

이진 Program (binary)이나 Shell Script를 실행할 수 있다.
읽기 허가권이 있다면 Directory를 탐색하는 것이 가능하다.

문서 성질의 보존 (Save Text Attribute): (Directory의 경우)

"Sticky Bit"는 Directory에 적용될 경우에는 다른 뜻을 가지게 된다. Directory에 Sticky Bit가 붙을 때에는 사용자는 -- 설령 사용자가 Directory에 일반적인 쓰기 허가권이 있더라도 -- 소유권이 있거나 확실하게 쓰기 허가권이 허락된 File 만 지울 수 있게 된다. 이것은 /tmp 따위의 -- World-Writable이면서도 일반 사용자가 무조건 File을 지우면 좋지 않을 -- Directory 등을 위해 쓰여진다. Sticky Bit는 긴 Directory Listing (ls -l)에서 t로 표시된다.

SUID의 성질 (File의 경우)

이것은 File의 set-user-id 허가권을 정의할 때 사용된다. 소유자 허가권에 set-user-id Access Mode가 붙으면 --그리고 File이 실행 가능한 File이라면-- 이 File을 실행하는 Process는 Process를 만든 사용자가 사용할 수 있는 System Resource를 쓸 수 있는 권한이 부여된다. 이것은 "buffer overflow: 이하 Buffer 범람"을 사용하는 많은 침탈법의 재료로 쓰여진다.

SGID의 성질 (File의 경우)

Group 허가권에 붙은 경우에는 이 Bit가 "set-group-id"를 관리하게 된다. 이것은 Group이 영향을 받는다는 점을 제외한다면 SUID와 같은 역할을 하는 것이다. 영향을 받으려면 역시 File은 실행 가능하도록 정의되어야 한다.

SGID Attribute (Directory의 경우)

만약 SGID를 Directory에 사용하면 ("chmod g+s Directory"를 씀), 그 Directory 안의 File들은 Directory 소유 Group의 값을 기본 Group 값으로 가지게 된다.

여러분 - File의 소유자 (owner)

Group - 여러분이 가입되어 있는 Group (group)

나머지 모든 이 - File의 소유자나 File을 소유한 Group에 속하지 않은 나머지 사용자 (other)

File의 보기:

-rw-r--r-- 1 kevin users 114 Aug 28 1997 .zlogin

1번 Bit     (-) Directory인가?         (아니다)
2번 Bit     (r) 소유자에 읽기권?         (있다. 케빈이 읽을 수 있다)
3번 Bit     (w) 소유자가 쓰기권?         (있다. 케빈이 읽을 수 있다)
4번 Bit     (-) 소유자에 실행권?         (없다)
5번 Bit     (r) Group에 읽기권?     (있다. users라는 Group)
6번 Bit     (-) Group에 쓰기권?     (없다)
7번 Bit     (-) Group에 실행권?     (없다)
8번 Bit     (r) 모든 이에 읽기권?         (있다. 모든 이가 읽을 수 있다)
9번 Bit     (-) 모든 이 쓰기권?         (없다)
10번 Bit     (-) 모든 이에 실행권?         (없다)

아래에는 필요한 만큼만의 최소한의 허가권을 부여한 보기를 적어 놓았다. 더 큰 허가권을 주는 것이 가능하지만, 설명된 작업 용도에 알맞은 최소 한도로 예를 설정해 놓은 것임을 밝혀 둔다.

-r--------     소유자의 읽기 허가권이 File에 있다.
--w-------     소유자가 File을 변경하거나 지울 수 있다.
---x------     소유자가 File (Program)을 실행할 수 있지만, 읽기권도 있어야 실행되는 Shell Script는 실행하지 못한다.
---s------     실세의 사용자 ID를 가진 개인이라면 실행할 수 있다. (setuid 참조)
-------s--     실세의 사용자 ID를 가진 Group이라면 실행할 수 있다. (setgid 참조)
-rw------T     "최근 바뀐 시간 (last modified time)" 정보가 갱신되지 않는다. Swap File 등에 사용된다.
---t------     상관없음 (전에는 Sticky Bit였음)

Directory의 보기:

drwxr-xr-x 3 kevin users 512 Sep 19 13:47 .public_html/

1번 Bit     (d) Directory인가?         (그렇다. 많은 File을 가지고 있다)
2번 Bit     (r) 소유자의 읽기권?         (있다. 케빈)
3번 Bit     (w) 소유자의 쓰기권?         (있다. 케빈)
4번 Bit     (x) 소유자의 실행권?         (있다. 케빈)
5번 Bit     (r) Group의 읽기권?         (있다. users Group)
6번 Bit     (-) Group의 쓰기권?         (없다)
7번 Bit     (x) Group의 실행권?         (있다. users Group)
8번 Bit     (r) 다른 이의 읽기권?         (있다. 아무나 읽을 수 있다)
9번 Bit     (-) 다른 이의 쓰기권?         (없다)
10번 Bit     (x) 다른 이의 실행권?         (있다. 아무나 실행할 수 있다)

아래는 최소의 허가권을 준 사용 보기이다. 여기에 설명되어 있는 것 보다 허가권을 더 주는 것은 가능하지만, 아래에 설명하는 정도는 최소 한도로 필요하다.

dr--------     내용은 보여질 수 있지만, File Attribute는 읽을 수 없게 된다.
d--x------     Directory는 실행 패스 (path)에 넣어져서 사용될 수 있다.
dr-x------     File Attribute는 이제 소유자에 의해서 읽혀질 수 있다.
d-wx------     Directory 현 위치에 있지 않아도 File은 만들어지고 지워질 수 있다.
d------x-t     쓰기 Access를 가진 다른 사용자들이 File을 함부로 지우는 것을 막는다. /tmp Directory에 사용된다.
d---s--s--     아무런 작용을 하지 않는다. (SUID와 SGID 참조)

(보통 /etc 안에 있는) System 설정 File (system configuration files)들은 640 (-rw-r-----) Mode이면서 동시에 Root 소유로 되어 있다. [12] 이것은 여러분 사이트의 보안 필요에 따라서 바꾸면 된다. System File은 절대로 다른 어떤 Group이나 누구라도 쓸 수 있도록 하면 안 된다. /etc/shadow를 포함한 System File의 일부는 Root만이 읽기 허가권을 가져야 하고, /etc 안의 Directory들은 다른 이들이 읽지 못하도록 해야 한다.

SUID Shell Script:

SUID Shell Script는 심각한 보안 위험 요소이며, 그런 이유 때문에 Kernel이 받아들이지 않도록 되어 있다. 여러분이 얼마나 Shell Script가 안전하다고 생각을 하던 간에, 이것은 Cracker에게 root Shell을 주는 침탈 도구가 될 수 있다.

5.3 완결성의 검사

Tripwire, Aide, Osiris등의 완결성 (Integrity) 유지용 검사 도구를 사용하는 것은 지역 사용자가 펼치는 (그리고 Network를 통해서 들어오는) 공격을 탐지해 내는 매우 좋은 방법이다. Tripwire, Aide, Osiris 등은 중요한 이진 File들과 설정 File들의 checksum 값을 검출해서 이전에 만들어 놓은 Database와 비교한다. File에 변화가 있으면 표시가 날 것이다. 이러한 Program을 쓰는 경우에는 Floppy에 설치하고 쓰기 방지 탭을 사용해서 쓰는 것이 좋다. 이렇게 해 놓으면 침입자는 이러한 검사 Program에 손을 대거나 Database를 바꾸지 못하게 된다. 일단 한 번 설치했으면, 일상적인 보안 관리 임무의 일부분으로서 관례적, 주기적으로 실행하는 것이 좋다.

Tripwire 등의 검사 Program을 매일 밤 Floppy에서 돌리고 아침에 Mail로 결과를 받도록 다음과 같이 crontab을 설정할 수 있다.

# set mailto
MAILTO=Kevin

# run Tripwire
15 05 * * * root /usr/local/adm/tcheck/Tripwire

이와 같이 하면 매일 아침 5:15am에 Report를 보내 줄 것이다.

이러한 검사기는 여러분이 직접 침입자를 눈치채기 훨씬 전에 미리 자동으로 알려주는 귀중한 존재가 될 수 있다. 하지만 일반적 System 안에서는 많은 File이 항시 바뀌므로 변한 것이 여러분의 일 때문인가, 아니면 Cracker의 행동인가를 파악하는 것에 신중을 기하도록 한다.

Open Source Version으로 만들어진 Tripwire는 무료로 구할 수 있다. Manual과 고객 지원은 따로 구입해야 한다.

Aide는 여기를 참조할 것.

Osiris는 이곳을 참조할 것. 1086:

5.4 트로이의 목마

트로이의 목마는 호머의 일리어드에 나오는 전설적인 책략에서 비롯된 이름이다. 그럴듯해 보이는 어떤 Program이나 이진 File을 Upload해 놓고, 다른 사람들이 그것을 다운 받아서 Root로서 돌리도록 한다. 그런 뒤에 사용자가 신경을 주지 않는 틈을 타서 System에 깨고 들어오는 것이다. 방금 받은 이진 File이 관리자가 애초에 기대했던 어떤 일을 한다고 생각하는 사이에 --정말로 그런 척 하기도 한다-- 한편으로는 보안을 깨고 들어오는 것이다.

여러분의 컴퓨터에 무슨 Program을 설치하였는지는 잘 살피도록 해야 한다. Redhat은 RPM File의 MD5 Checksum과 PGP Signiture를 제공하므로, 설치하고 있는 Program이 진짜인지 확인할 수 있다. 다른 배포본도 비슷한 방법을 쓴다. Source도 있거나 잘 알려진 것이 아닌 한, Root의 권한으로 어떤 이진 File도 실행되어서는 안 된다! 일반 대중이 정밀한 조사를 할 수 있도록 Source를 공개할 Cracker는 없다시피 하므로.

귀찮을 수도 있지만, Program의 Source를 정품 배포 장소에서 가져왔는지 확인하도록 하라. Program이 Root에서 실행될 상황이라면 여러분이나 믿을 만한 누군가가 Source를 훑어보고 확인하도록 해야 한다.

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.