[보안] 파일시스템 보안 관련

<<<<<<     파일과 파일시스템 보안    >>>>>>>>

파일과 파일시스템 보안

시스템을 온라인으로 접속시키기 전에, 몇 분 동안이나마 준비와 계획을 하는 것은

여러분의 시스템과데이타를 보호하는 것에 큰 도움을 줄 수 있다.

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 hardcore0

@users hardnproc 50

@users hardrss 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 kevinusers 114 Aug 281997 .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-x3 kevinusers 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 쉘 스크립트는 심각한 보안 위험요소이며, 그런 이유 때문에 커널이 받아들이지

않도록 되어있다. 여러분이 얼마나 쉘 스크립트가 안전하다고 생각을 하던 간에, 이것

은 크랙커에게 루트 쉘을주는 침탈 도구가 될 수 있다.