Solaris system Security
[1] 솔라리스8 시스템 보안 개요
가. 시스템 보안이 필요한 이유
과거에는 사무실에 전기가 나가도 업무를 못하는 경우는 없었다. 타자기가 있었으니... 처음 직장생활을 시작할 당시 (1985년)에는 적어도 그러하였다. 요즈음 정전이 되면, 모두들 당연한 듯 일손을 놓게된다. 업무전산화가 그 이유임은 누구나 잘 알 것이다. 회사의 모든 기밀 및 정책사항은 철제 캐비넷에서 하드디스크로 옮겨졌다. 그안에는 회사의 미래를 좌우할 수 있는 각종자료가 빼곡히 채워져있다.
시스템의 불법침입은 옛날로 치자면 회사금고가 열리는 형태이다. 더욱 심각한 일은, 회사의 금고가 털린줄도 모른채 무사태평할 수 있다는 것이다.
인터넷의 등장과 함께, 이제 금고안의 서류는 순식간에 태평양을 건너 갈 수도 있다. 이것이 남의 일이 아님은 세계유수 기업들이 심심치않게, 또한 어이없이 당한 뉴스를 보면서 느낄 수 있는 일이다.
물론, 10명의 파수꾼이 한명의 도둑을 막지못한다는 말도 있다. 날고 뛰는 전문해커를 어떻게 감당하겠냐며 그저 하나님께 시스템 보안을 의뢰할 수도 있다. (제발 우리 시스템에는 침입자가 없게 해달라고 기도하며...)
100% 완벽한 보안솔루션을 구축하기란 참으로 어려운 일일 것이다. (어쩌면 불가능할지도 모른다) 그러나 100%에 가까운 보안을 구축하고자 노력하면 할수록 그 틈새를 비집고 침입할 수 있는 확률은 줄어들기 마련이다.
서론이 너무 길었다. Solaris 운영체제는 시스템군에 속해있는 파일, 디렉토리, 주변기기를 보호할 수 있는 우수한 보안체제를 갖추고 있다. 솔라리스 8에서는 이전 버전보다 향상된 보안기능을 제공한다. 본 장에서는 일반적인 유닉스 시스템 보안보다는 솔라리스 8이 갖고 있는 보안 솔루션을 중점적으로 다루도록 하겠다.
나. 솔라리스 8 시스템 보안의 새로운 특징
1) 파일 및 디렉토리의 소유권
- 파일 및 디렉토리에 대한 기본 소유권이 bin에서 root로 변경됨.
- 기본 권한이 775이던 파일 및 디렉토리는 755로 변경됨.
- 기본권한이 664이던 파일 및 디렉토리는 644로 변경됨.
- 기본 시스템 umask는 022로 설정됨.
2) Role Based Access Control
솔라리스 8 버전부터 새로이 등장한 기능이다. 전통적인 유닉스 보안시스템에서는 전지전능한 수퍼유저와 힘이라고는 전혀 없는 일반사용자만이 존재하였다. 때문에 일반사용자들은 변변한 프로그램 하나 제대로 시스템에 설치할 수 없었다. RBAC는 일반사용자도 수퍼유저의 힘을 나누어 가질 수 있는 능력을 제공해준다. 물론 무턱대고 권한을 주는 것은 아니다. 필요에 따라 일반사용자에게 수퍼유저 권한을 적절히 배분해주는 아주 유용한 방법이다. 그러나 시스템에 문제를 야기시킬 수 있다고 판단되는 user에게는 절대로 이러한 능력을 주어서는 안된다. RBAC에 대해서는 뒷장에서 상세히 설명할 예정이다.
3) Sun Enterprise Authentication Mechanism (SEAM)
SEAM은 네트웍상에서 KDC라는 제 3의 인증서버를 통하여 사용자 인증기능을 제공해주는 클라이언트/서버 구조의 보안기능이다. SEAM은 네트웍상에서 사용자의 인증은 물론 데이터의 무결성 및 기밀성도 보장을 해준다. 이를 이용하여 사용자는 다른 서버에 접속하여 명령어 수행 및 데이터 교환, 파일 전송등을 완벽한 보안속에 행할 수 있다. 이와 함께 SEAM은 시스템 관리자가 서비스 및 서버 사용을 제한할 수 있는 기능도 제공한다. SEAM이 가진 또하나의 장점은 사용자 인증이 한 세션당 한번만 이루어지면 된다는 것이다. 일단 사용자 인증이 이루어지면 세션이 종료되지 않는한 또다시 패스워드를 입력하지 않아도 된다. (이러한 인증방식은 이제는 대다수의 웹사이트에서 널리 사용되고 있음을 볼 것이다) SEAM은 MIT에서 개발한 커버로스 (Kerberos) V5 네트웍 인증 프로토콜을 기반으로 한다. client/server part가 모두 포함되었던 이전과는 달리 솔라리스 8 버전부터는 client쪽 제품만이 포함되어 있다.
다. 솔라리스 8에서의 보안을 위한 유의사항
1) 솔라리스 8 시스템에서 운영 프로그램을 설치시 유의사항.
- 모든 파일 및 디렉토리의 기본 소유자는 root로 한다.
- 디렉토리 및 실행파일의 기본 권한은 555 혹은 755로 설정한다.
- 일반 파일의 기본권한은 644 혹은 444로 설정한다.
- setuid나 setgid를 가진 파일은 파일의 소유자라 할지라도 변경할 수 없도록 쓰기금지를 해놓는다. (소유자가 root일 경우는 물론 예외이다.)
라. 보안을 위한 기본 사항
운영체제에게만 의존할 수 없는 것이 보안의 기본원칙이다. 다음은 사소한 사항들이기에 관리자가 방심하기 쉬운 사항들이다.
1) 물리적 보안 유지
만일 시스템을 로긴한 상태에서 자리를 비웠다면 잠시라도 그곳에 들른 누구에게나 운영체제 및 네트웍에 접근할 수 있는 통로를 열어준 셈이 된다. 불법 접근 차단을 위한 물리적 보안유지는 시스템보안의 첫 번째 과제이다. (솔라리스 8의 화면잠금장치에 너무 의존하지 말 것. Screen lock이 작동되기 전까지의 시간이 바로 경계해야할 부분이다)
2) Login 및 Access Control
시스템내 모든 계정은 암호를 가지고 있어야 한다. 암호 없이 사용자 id만으로 접속할 수 있는 계정, ID와 암호가 똑같은 계정은 만인을 위해 열어놓은 시스템 통로나 다름없다. 대부분의 경우, ID는 공개된 사항임을 명심하자. (DB에서도 마찬가지이다. 오라클 DB를 인스톨해 놓은 후 change_on_install 암호를 두 달이 넘도록 변경하지 않은 사례도 본적이 있다. )
3) 파일 및 디렉토리내 접근 제한
부적절한 file 및 디렉토리 사용권한 설정은 시스템 전체에 악영향을 미칠 수 있다. 파일 보안에 대하여는 뒷장에서 상세히 설명하겠다.
4) 네트웍 보안 유지
네트웍을 통한 시스템 침입은 때로는 너무도 쉽게 이루어진다. client측의 허술한 암호관리가 원인이 되어 네트웍을 통해 서버에 침입한 사례는 무수히 발견된다. 회사내에서 intranet이 가동중이라면 firewall은 선택이 아니라 필수다. telnet을 막아놓는 것이 보안의 기본사항이 된 것도 요즘의 현실임을 명심하자.
5) 시스템 사용자 모니터링
시스템 관리자라면 다음사항은 주의깊게 모니터링하는 습관을 길러야 한다.
- 현재 실행중인 프로세서중 이상하게 느껴지는 것은 없는가 ?
- 불필요하게 (?) 시스템에 들어온, 혹은 로그인을 시도한 사용자는 ?
- 시스템에 들어와서 머물다간 사용자의 기록
6) 적절한 경로 설정
한가지 살벌한 예를 들어보자. 시스템 관리자의 profile의 실행경로명에 일반user가 사용 가능한 디렉토리가 뒷부분이 아닌 앞부분에 포함되어 있을 경우, 예를 들자면 다음과 같이 경로설정이 되어 있다면 어떤일이 발생할 수 있을까 ?
PATH=/export/home/bin:/usr/bin:/usr/local/bin:/usr/dt/bin:/usr/ccs/bin:
만일 어떤이가 악성 바이러스 프로그램을 su라고 이름을 바꾸어 /export/home/bin 디렉토리에 슬며시 넣어두었다. 물론 바이러스 프로그램은 실행후 스스로 자폭하는 형태이고.
시스템 관리자가 로긴후 평상시대로 su명령을 실행시킨다면 /usr/bin의 su프로그램 대신 바이러스 프로그램이 우선적으로 실행되어 시스템을 일순간 마비시켜버릴 것이다.
여기에 언급되지 않은 일반화된 보안설정 역시 결코 소홀히 할 수 없는 사항임을 유념해야 한다. 경찰청에 설치된 사이버 테러 대응쎈터나 한국정보통신망침해 사고대응팀도 여러분의 시스템을 보호해주는 훌륭한 자문역할을 할 수 있다.
마. 솔라리스 파일 보안
1) 특별권한 설정시 주의사항
파일에 대한 보안이라면 우선적으로 생각나는 것이 무엇일까 ? 행여 내 파일을 누군가 지우거나 변경시키지는 않을까 ? 아니면 비밀스러운 파일을 누군가가 읽어보지는 않을까 하는 것이 대부분이리라. 그러나 파일 하나를 부주의하게 관리함으로서 시스템을 통째로 날릴 수 있다면 과장된 표현일까 ?
솔라리스에서는 실행파일이나 공용 디렉토리에 setuid, setgid, sticky bit 등 세가지 형태의 특별권한을 설정해줄 수 있다. 이중 setuid, setgid와 같은 특별권한이 설정된 파일을 실행시킨 사용자는 파일이 실행되는 동안 실행파일의 소유자, 혹은 소유그룹의 일원으로 인정받는다. 이것이 잘못 사용될 경우, 시스템보안은 매우 위태로운 상황에 빠지게 된다.
한가지 예를 들어보자.
uid가 root로 설정된 프로그램을 실행시킨 일반 사용자는 프로그램이 실행되는 동안 root의 권한을 부여받는다. 사용자가 그틈을 이용하여 자신의 계정에 대한 권한을 root에 버금가도록 만들어버린다면... 시스템의 주인이 바뀌는 상황이 된다.
수퍼유저의 권한을 부여하는 setuid, setgid등의 특별권한을 가진 프로그램의 작동은 수시로 모니터링하여 부적절한 사용을 막도록 하자. (이러한 프로그램의 리스트를 출력하는 방법은 다음단원에 자세히 설명해 놓았다.)
[2] setuid 권한
가. setuid란
실행파일에만 설정되는 setuid (set-user identification) 권한은 파일의 소유자 (일반적으로 root)가 가지는 것이 원칙이다. 그러나 만일 일반 사용자가 이 파일을 실행시킬 경우에는 파일의 소유자와 동등한 파일 및 디렉토리 사용권한을 획득하게 된다.
setuid 권한이 설정된 passwd명령어를 일반사용자가 실행시켰을 경우, 그 사용자는 프로그램이 수행되는 동안 root의 권한을 획득하여 패스워드를 바꿀 수도 있다. 이 얼마나 엄청난 일인가. 일단 그 사용자가 프로그램 실행중 자신에게 필요한 사항을 모두 마무리지어 놓는다면, 프로그램이 종료된 후에도 여전히 root에 버금가는 권한을 휘두를 수 있으니...
setuid 권한이 설정된 파일의 예 -r-sr-sr-x 3 root sys 104588 Oct 18 11:14 /usr/bin/passwd
setuid 권한이 설정된 파일을 찾아내는 방법 1) superuser권한을 갖는다. 2) find명령을 이용하여 setuid 권한을 가진 파일을 다음 방법으로 검색한다. # find directory_path -user root -perm -4000 -exec ls -ldb {} ; >/tmp/filename ☞ option 설명 find directory_path 특정디렉토리로부터 시작되는 모든 경로를 검색함 -user root root가 소유한 파일만을 검색함 -perm -3000 권한이 3000으로 설정된 파일만을 검색함. -exec ls -ldb find 명령으로 검색된 파일의 결과치를 ls -ldb 형식으로 출력함 > /tmp/filename 출력된 결과를 이 파일에 저장함
나. 기타 특수권한 설정
1) setgid 권한
set-group identification (setgid) 권한 역시 setuid와 비슷하다. 다른점이 있다면 파일의 소유자가 아닌 소유그룹의 권한이 설정되며 이를 실행시킨 사용자는 해당그룹의 권한을 갖는다는 것이다.
setgid가 설정된 파일의 예 -r-x--s--x 3 root mail 63628 Oct 18 12:27 /usr/bin/mail
setgid 권한이 디렉토리에 적용될 경우, 해당 디렉토리에 생성된 파일들은 프로세서를 수행시킨 사용자의 그룹에 속하는 것이 아니라 디렉토리가 속한 사용자그룹에 속한다. 이 디렉토리안에서 쓰기 및 실행권한을 가진 사용자는 모두 그곳에서 파일을 생성할 수 있다. 그러나 그 파일들은 파일을 생성한 사용자 그룹이 아니라 그 디렉토리를 소유한 그룹에 속하는 것이다.
2) Sticky bit
sticky bit은 디렉토리안의 파일들을 보호하는 권한이다. 만일 어떤 디렉토리에 이 권한이 적용되었다면 해당파일이나 디렉토리의 소유자, 혹은 root만이 디렉토리안의 파일들은 지울 수 있다. 이 기능은 웹서버의 /public_html과 같은 공용디렉토리나 임시디렉토리 (/tmp) 내의 다른 사용자들의 파일을 보호하기 위하여 존재하는 것이다. 공용디렉토리 설정시에는 sticky bit을 설정해 주어야 함을 유념토록 하자.
3) umask
처음, 파일이나 디렉토리를 만들면 파일이나 디렉토리에 대한 기본적인 권한이 자동 설정된다. 이 기본 권한은 시스템 파일의 umask에 의하여 결정된다. umask는 .profile, .cshrc, .bashrc, .login과 같은 사용자 프로파일에서 설정한다.
umask는 chmod와는 정반대의 개념으로 사용된다. 예를 들어 chmod 022라는 명령어가 해당그룹 및 다른 사용자들에게 쓰기권한을 부여하는 반면, umaks 022는 해당그룹 및 다른 사용자들에게 쓰기권한을 박탈하는 것이다.
umask값의 증가에 따른 보안등급의 변화 보안등급 umask 삭제되는 권한 744 022 그룹 및 다른 사용자의 쓰기 권한 741 026 그룹의 쓰기 권한 및 다른 사용자의 읽기, 쓰기 권한 740 027 그룹의 쓰기 권한 및 다른 사용자의 읽기, 쓰기, 실행권한 700 077 그룹 및 다른 사용자의 읽기, 쓰기, 실행 권한
다. Access Control List (ACL)
1) ACL의 특징
일반적인 유닉스 파일 권한 설정방법은 사용자를 소유자, 그룹, 기타 사용자 등 세 가지로 분류하여 권한을 부여하는 방식이었다. ACL은 이보다 훨씬 향상된 파일 권한 설정이 가능하도록 해준다. 즉, 소유자, 그룹, 기타사용자등 세가지 범주 이외에 특정 사용자 및 특정 그룹을 추가할 수 있고 이렇게 분류된 5가지 범주에 각각 기본적인 소유권을 설정해줄 수 있다.
예를 들어, 그룹내의 모든 사용자가 파일을 읽을 수 있게 하려면 해당 파일에 대한 그룹의 읽기 권한을 부여하면 될 것이다. 그런데 그 그룹내에서 오직 한사람만이 해당파일을 읽을 수 있는 권한을 주고자 한다면 어떻게 해야 할까 ? 일반 유닉스 시스템에서는 쉽지 않은 일이다. 그러나 ACL에서는 아주 간단히 해결될 수 있는 사항이다.
2) ACL 엔트리
ACL 엔트리는 파일의 ACL을 규정해주는 방법이다. 이것은 setfacl 명령어로 설정된다. ACL 엔트리는 다음과 같은 필드로 구성되어 있으며 각 필드는 콜론(:)으로 구분된다.
entry_type:[uid | gid]:perms option 설 명 entry_type 파일 소유권을 설정해주는 ACL 엔트리 형태 (엔트리 형태는 파일의 소유자인 user로 표현해도 좋고 ACL mask인 mask로 표현해도 좋다. uid 사용자이름 혹은 id number gid 그룹명 혹은 id number perms 엔트리 형태에 설정된 소유권. rwx 형식이나 chmod 명령에 사용되는 형식과 동일한 3자리 숫자로 나타낼 수 있다. ※ gildong이라는 사용자에게 읽기/쓰기 권한을 부여하는 ACL 엔트리는 다음과 같이 간단하게 표현된다.
user:gildong:rw-
3) 파일에 대한 ACL 엔트리
다음은 는 사용가능한 ACL 엔트리를 나타낸 것이다. 맨 위의 3가지 ACL 엔트리는 전형적인 유닉스 파일 보호기능과 동일한 것을 제공한다.
ACL 엔트리 descrition u: : perms 파일 소유자 권한 g: : perms 파일 소유그룹 권한 o: : perms 파일 소유자나 그룹 이외의 기타 사용자 권한 m: : perms ACL 마스크. 마스크 엔트리는 기타사용자 및 그룹에게 허용된 최대한의 권한을 나타낸다. 마스크는 기타사용자 및 그룹의 권한을 신속하게 변경할 수 있다. 예를 들어, 다음과 같은 마스크 엔트리는 쓰기 및 실행권한을 가졌던 기타사용자와 그룹이 읽기권한 이외에는 가질 수 없도록 만드는것이다. mask:r-- u:uid:perms 특정한 사용자에 대한 파일 소유권 (uid는 사용자명이나 uid 번호등 어떤 것을 사용해도 된다) g:gid:perms 특정한 그룹에 대한 파일 소유권 (gid는 그룹명이나 gid 번호등 어떤 것을 사용해도 된다)
4) 디렉토리에 대한 ACL 엔트리
다음은 디렉토리에 사용가능한 ACL 엔트리를 나타낸 것이다. 맨처음, 특정 사용자나 그룹에 디렉토리에 대한 ACL 엔트리를 설정할때에는 파일 소유자, 그룹, 기타사용자, ACL 마스크 값을 반드시 설정해주어야 한다.
ACL 엔트리 descrition d:u: : perms 파일 소유자 권한 d:g: : perms 파일 소유그룹 권한 d:o: : perms 파일 소유자나 그룹 이외의 기타 사용자 권한 d:m: : perms ACL 마스크. d:u:uid:perms 특정한 사용자에 대한 파일 소유권 (uid는 사용자명이나 uid 번호등 어떤 것을 사용해도 된다) d:g:gid:perms 특정한 그룹에 대한 파일 소유권 소유권 (gid는 그룹명이나 gid 번호등 어떤 것을 사용해도 된다)
라. Access Control List (ACL)의 설정방법
1) 파일에 ACL을 설정하는 방법.
① setfacl 명령어를 이용하여 파일에 ACL을 다음과 같이 설정한다.
$ setfacl -s user: :사용권한,group: :사용권한,other:사용권한,mask: :사용권한,acl_entry_list filename ...
option descrition -s 파일에 ACL을 설정하는 옵션. 만일 파일에 이미 ACL이 설정되어 있다면 지금 입력하는 새로운 설정값으로 변경된다. 이 옵션을 줄때에는 파일 소유자, 파일그룹, 기타사용자를 함께 입력해야 한다. user::사용권한 파일 소유자 권한 설정 group::사용권한 파일 그룹 권한 설정 other::사용권한 기타사용자 권한 설정 mask::사용권한 ACL 마스크 권한 설정. 여기서 마스크값은 기타사용자 및 그룹에 주어지는 최대한의 권한을 의미한다 acl_entry_list 파일이나 디렉토리의 특정 사용자나 특정그룹에 대하여 설정할 하나 이상의 ACL 엔트리 명시. 파일 및 디렉토리에 대한 ACL 엔트리 설정표를 참고하기 바람 filename ACL을 설정할 한 개이상의 파일이나 디렉토리명
② ACL값이 제대로 설정되었는가를 확인하는 방법
$ getfacl 확인할 파일이름
③ ACL 설정 실제
사례 1. mylove.txt라는 파일의 소유자에게는 읽기/쓰기 권한을, 그룹에게는 읽기권한만을, 기타사용자에게는 아무런 권한을 주지않도록 설정한다. 그러나 이렇게 설정하는 것만으로는 ACL의 진가를 발휘할 기회가 없다.
yongsu라는 사용자는 소유자가 아니라 할지라도 파일에 대하여 읽기/쓰기 권한을 가질 수 있고 기타사용자 및 그룹은 실행권한이 전혀 없도록 ACL 마스크 권한을 읽기/쓰기로 설정해보자.
$ setfacl -s user: :rw-,group::r--,other:---,mask:rw,user:yongsu:rw- mylove.txt $ ls -l total 476 -rw-r-----+ 1 sknho sysadmin 4128 Dec 20 09:24 mylove.txt -rw-r--r--+ 1 sknho sysadmin 3157 Dec 20 09:24 true.txt -rw-r--r--+ 1 sknho sysadmin 7462 Dec 20 09:24 take_me_home.doc $ getfacl mylove.txt # file: mylove.txt # owner: sknho # group: sysadmin user: :rw- user:yongsu:rw- #effective:rw- group: :r-- #effective:r-- mask:rw- other:---
사례 2. true.txt라는 파일의 소유자에게는 읽기/쓰기/실행 권한을, 그룹에게는 읽기권한만을, 기타사용자에게는 아무런 권한을 주지않도록 설정한다. ACL 마스크 권한은 읽기전용으로 설정한다. 또한 miran이라는 사용자는 파일에 대하여 읽기/쓰기 권한을 가졌다 할지라도 ACL 마스크 설정으로 인하여 읽기권한만을 갖도록 설정해보자.
$ setfacl -s u: :7,g: :4,o:0,m:4,u:miran:7 true.txt $ getfacl true.txt # file: true.txt # owner: sknho # group: sysadmin user: :rwx user:miran:rwx #effective:r-- group: :r-- #effective:r-- mask:r-- other:---
파일에 설정된ACL값을 다른파일에 복사해주는 방법
한번 설정한 ACL이 아주 마음에 들어서 이것을 다른 파일에도 그대로 적용시키고자 할 때, 파일마다 일일이 setfacl명령어로 복잡한 옵션을 설정해야 할까 ? 그럴 필요가 없다. 아래와 같은 방법으로 간단하게 다른파일에도 적용시킬 수 있다.
$ getfacl filename1 | setfacl -f filename2 filename1 : 이미 ACL이 설정되어 있는 파일명 filename2 : ACL을 filename1처럼 설정코자 하는 파일명
마. ACL의 수정,삭제
1) 파일에 설정된ACL값을 변경하는 방법
한번 설정한 ACL을 변경하고자 할때에도 setfacl명령어를 사용하면 된다.
아래 예는 파일 mylove.txt에 대한 사용자 'minsu'의 access 권한을 읽기/쓰기로 변경해주는 예이다.
$ setfacl -m user:minsu:6 mylove.txt
위와 같이 파일에 대한 ACL을 변경한 이후, 변경이 제대로 되었나를 확인할 때에는 getfacl 명령어를 사용하면 된다. 아래 예는 위에서 변경한 mylove.txt 파일에 대한 확인작업을 한 것이다.
$ getfacl mylove.txt # file: mylove.txt # owner: younghee # group: staff user: :rw- user: :minsu:rw- #effective:r-- group: :r- #effective:r-- mask:r-- other:r-
2) 파일에 설정된ACL값을 삭제하는 방법
설정한 ACL을 삭제하고자 할때에는 setfacl명령어에 -d 옵션을 사용한다. 아래 예는 파일 mylove.txt에 대한 사용자 'minsu'의 권한을 삭제하는 예이다.
$ setfacl -d user:minsu mylove.txt
[3] 시스템 보안
시스템 보안은 시스템의 불법 침입을 원천봉쇄하는 것이 주목적이다. 우선은 쉬운것부터 점검하자. 행여 콘솔이나 원격 터미널 모드로 로그인을 한후 자리를 비우지는 않는지. 서버가 설치된 곳이 외부로부터 충분히 보호받고 있는지. 이러한 물리적 요인으로부터 안전하다고 판단된다면 이제부터는 다음 사항들을 하나씩 점검해보자.
가. 시스템 보안을 위한 점검사항
1) 암호없는 계정을 가진 사용자 검색
적어도 솔라리스 8에서는 암호없이 시스템을 사용하는 사용자에 대한 걱정은 하지 않아도 좋다. 암호없는 계정을 만들 수는 있어도 그것을 사용할 수 있는 일은 전혀없으니. (텔넷상에서는 물론, 콘솔에서도 암호없이는 로그인을 할 수 없다. 즉, 새로운 암호를 입력해야만 로그인이 가능하다)
그러나 만일, 시스템관리자가 실수로 새 계정을 만든후에, 암호를 집어넣지 않았다면 누구든 그 계정으로 일단 접속하기만 하면 접속자 스스로 암호를 만들어 사용할 수 있다. 일반 사용자의 계정이라도 문제가 되겠지만 그것이 권한있는 관리자계정일 경우에는 중대한 문제가 야기된다.
행여 내 시스템내에 그러한 계정은 없는가 살펴보자.
# logins -p
이렇게 하면 암호없이 등록된 계정이 화면에 나타난다. 사용자에게 속히 연락하여 암호를 새로이 입력토록 조치해주자.
2) 로그인에 실패한 접속기록 살펴보기
일단 시스템에 로그인하는 것을 실패하는 경우는 대부분 입력을 잘못해서 그럴 수 도 있다. 그러나 로그인 입력과정을 다섯번이나 실패했다면 이는 충분히 의심해볼 사유가 된다. 허가받지 않은 이가 불법으로 접속을 시도했을 가능성이 크기 때문이다.
이렇게 비정상적인 로그인 시도 기록은 파일로 보관할 수 있다. 솔라리스 8은 자동으로 이를 기록으로 남겨주지 않는다. 그러나 관리자가 다음파일을 수동으로 직접 만들어 준 이후에는 자동으로 이러한 비정상적 접속기록을 파일로 남겨준다.
/var/adm/loginlog
loginlog파일안에는 다섯번씩 로그인에 실패한 기록이 자동으로 기록된다. 이 파일을 만들때에는 root만이 읽고 쓰기가 가능하도록 권한을 부여해주어야 한다. (왜 하필 다섯번일까. 텔넷으로 솔라리스에 로그인을 다섯번 실패하면 자동으로 접속이 끊어진다. 이는 기본설정이 그렇게 되어있기 때문이며 /etc/default/login파일에서 RETRIES부분의 주석을 제거하고 값을 변경하여 관리자가 임의로 변경하는 것이 가능하다.)
로그인에 실패한 기록은 다음과 같이 남겨진다.
# cat loginlog oracle:/dev/pts/2:Fri Dec 22 15:45:29 2000 oracle:/dev/pts/2:Fri Dec 22 15:45:36 2000 oracle:/dev/pts/2:Fri Dec 22 15:45:44 2000 oracle:/dev/pts/2:Fri Dec 22 15:45:51 2000
위에서 보면 로그인에 실패한 사용자의 id, 터미널 명, 접속을 시도한 때 (년,월,일,시각)이 나타난다.
만일 여러분의 시스템에서 loginlog 파일의 크기가 나날이 증가한다면 그것은 여러분의 시스템이 누군가에 의해 끊임없이 침입을 시도당하고 있다는 증거이다.
loginlog 파일은 다음과 같은 방법으로 만들자.
superuser 권한을 갖는다
# touch /var/adm/loginlog # chmod 600 /var/adm/loginlog # chown root:sys /var/adm/loginlog
나. 원격지에서의 root login 제한 및 su
1) superuser (root) 로서의 로그인 제한하기
수퍼유저는 시스템이라는 세계안에서는 전지전능한 신의 권위를 갖는다. 그의 손가락 하나로 그 세계를 파괴해버리는 것은 그리 어렵지 않다. 이러한 권능이 악의를 품은 제 3자에게 넘어간다면...
제 3자가 접근할 수 없는 안전한 곳에 위치한 콘솔상에서만 root로 로그인하는 것이 가능토록 설정하는 방법은 다음과 같다.
- 수퍼유저 권한을 갖는다.
- /etc/default/login 파일을 편집기로 open한다.
- CONSOLE=/dev/colsole 이라고 씌여진 줄 맨앞에 # 표시를 지워준다.
이후로는 원격지 터미널에선 수퍼유저로서 login할 수 없다. (처음 시스템을 설치하였을때 기본적으로 이렇게 설정되므로 확인만 해보기 바람.)
누가 su 명령어를 사용했을까 ?
앞서 이야기했듯 su명령어는 시스템 관리자 이외에는 사용할 수 도 없고, 해서도 안된다. 그러려면 관리자 암호의 철저한 관리 및 주기적인 암호 교체가 최상의 방법이다.
그러나 관리자 암호가 연상되기 쉬운 것으로 설정되어 있거나, 여타의 방법으로 노출되었다면... 그래서 누군가가 원격지 터미널에서 심심풀이로 가끔씩 su 명령을 사용하고 있다면 ...
혹시 이러한 일이 내 시스템에서도 발생하고 있을지도 모를 일이다. 이것을 알아보는 방법은 다음과 같다.
- 수퍼유저 권한을 취득한다.
- /etc/default/su 파일을 편집기로 open한다.
- SULOG=/var/adm/sulog 라고 씌여진 줄 맨앞에 # 표시를 지워준다.
이후부터는 su 명령어를 사용한 모든 기록이 sulog 파일에 기록된다. 시스템 관리자 본인이나 su 권한을 허가받은 사용자 이외에 다른이가 su 명령어를 사용한 기록이 없는가를 살펴보도록 하자.
su 명령어를 사용한 사용자는 다음과 같이 적발(?) 가능하다.
- 수퍼유저 권한을 갖는다.
- /etc/default/su 파일을 편집기로 open한다.
- CONSOL=/dev/console 이라고 씌여진 줄 맨앞에 # 표시를 지워준다.
이후부터는 su 명령어를 사용한이들이 모두 화면에 출력될 것이다.
su 명령어를 타인이 실행할 수 없게 만드는 방법
su (switch user) 명령어를 시스템 관리자나 몇몇 특정인 이외에는 절대로 사용할 수 없도록 만드는 간단한 방법이 있다. 터미널은 물론이고 콘솔에서조차 사용할 수 없도록... 방법은 좀 단순 무식하다. /usr/bin에 있는 su 파일을 rename시키는 것이다. 예를 들어 다음과 같이 파일명을 변경시킨다면
mv su pcbee
변경된 순간부터 su명령어대신 pcbee라는 명령어를 수행해야만 switch user 명령어가 수행된다. 물론 새로 rename시킨 명령어는 필요한 몇몇 사람만 알도록 해야하고...
다. restricted shell 설정
1) restricted shell
여러분이 시스템 관리자라면 사용자들의 계정 발급시 특정 shell환경을 함께 지정할 것이다. 이때 아무 생각없이 /bin/sh shell을 지정해주지는 않는지 ... , 만일 그렇다면 시험삼아 다른 사용자의 계정으로 ftp login후 다른 디렉토리로 이동해보길 바란다. 아주 자유롭게 root 디렉토리까지 넘나들며 시스템의 파일을 무한정 다운받을 수 있다는 사실을 알게 될 것이다.
이것을 막기위하여 일반 사용자들에게는 제한된 쉘이란 의미의 rsh (restricted shell) 환경을 제공해 줄 수 있다. rsh는 /usr/lib/rsh shell을 지칭하며, 일반 사용자가 접근할 수 있는 작업 디렉토리의 영역과 사용할 수 있는 명령어를 제한해준다.
restricted shell의 기능은 아래와 같다.
- 사용자는 자신의 home directory에서만 화일을 생성할 수 있다.
- "cd" 명령을 사용하여 다른 directory로 갈 수 없다.
- 사용자는 root가 PATH 변수에 지정한 directory안에 있는 명령만 사용할 수 있다. 물론 지정된 PATH는 사용자가 변경 할 수 없다.
- 사용자는 자신의 home directory와 하위 directory에 있는 화일만 access할 수 있다.
- 사용자는 ">" 혹은 ">>" 를 사용하여 output을 다른 화일로 redirection할 수 없다.
2) restricted shell 설정하기
- /etc/password 파일을 한번 살펴보자. 여기서 일반사용자중 제한된 쉘을 적용할 이들의 login shell을 /usr/lib/rsh로 변경한다.
예) junghee:x:1004:10::/export/home/junghee:/bin/sh를 junghee:x:1004:10::/export/home/junghee:/usr/lib/rsh 로 변경. - /etc/profile 또는 사용자의 home direcroty에 사용자의 .profile을 만든후 이 파일에 사용자의 PATH를 지정한다. (만일 별도로 PATH를 지정하지 않으면 /usr/bin이 사용자의 경로로 지정된다)
- 사용자의 home directory에 .profile을 만들 때 다음과 같이 permission을 정해준다.
1) owner를 root로 한다. : # chown
2) 사용자가 내용을 변경할 수 없게 한다. : # chmod 755 .profileroot:bin .profile
라. 불필요한 서비스 중단 및 스크립트 제거
1) 불필요한 서비스 중단 및 스크립트 제거
처음 솔라리스8을 설치할 때, 대부분의 사용자들은 CD에 수록된 모든 것을 설치하기 마련이다. 몇 번 사용하지 않거나, 한번도 사용하지 않는 프로그램이 그 가운데는 수두룩하다.
이것은 시스템 성능에도 영향을 미친다. 그러나 여기에만 그치는 것이 아니고 시스템 보안에도 문제를 발생시킬 수 있다.
Solaris 운영체제가 설치된 시스템은 아주 많은 서비스를 제공할 수 있지만 이들 대부분이 보안에는 잠재적인 위험요소이다. 예를 들어 /etc/inetd.conf 에는 35가지의 서비스가 제공되고 있다. 이중 ftp나 telnet을 제외한 나머지 서비스는 관리자조차도 거의 신경을 쓰지 않는 항목들이다.
(gopher 서비스를 생각조차 해본적이 있을까 ? 그러나 엄연히 서비스중인 항목이다) 시스템 관리자가 불필요한 서비스라고 판단되는 항목은 # 주석을 달아 중단시킬 필요가 있다.
다음으로는 /etc/rc2.d 와 /etc/rc3.d 디렉토리에 있는 스크립트 파일들이다. 이들은 시스템이 부팅될때마다 자동으로 실행된다. 그러나 이들중 상당수가 시스템 운영에는 그다지 필요하지 않다. 단지 보안에 있어서 위험요소는 될 수 있다.
이러한 스크립트 파일들의 자동실행을 중단시키려면 스크립트 파일명의 맨 앞자인 대문자 'S'를 소문자 's'로 바꿔주면 된다. 이후, 특정 스크립트 실행이 필요할 때에는 소문자를 다시 대문자로 바꾸어주면 되고... 아래 열거된 스크립트 파일들은 별로 필요치 않으면서도 시스템 보안에는 위험한 요소가 될 수 있는 것들이다.
/etc/rc2.d 디렉토리
S73nfs.client - NFS mounting.
S74autofs - automounting,
S80lp - printing (서버에서 프린트작업을 수행할 일이 얼마나 있을까?)
S88sendmail - incoming email listener. (이것 없이도 메일을 전송시킬 수 있다)
* 아래 스크립트는 보안에는 도움이 되지 않지만 CDE 구동에 꼭 필요하다. 일반 솔라리스 사용자들에게 있어서 CDE환경은 꼭 필요할 수 있다. 그러나 CDE환경이 필요 없는 시스템도 있다. (웹서버가 대표적인 예일 것이다) 이러한 경우에는 아래 스크립트의 자동실행을 중단시키는 것이 좋다. S71rpc - portmapper daemon S99dtlogin - CDE daemon
/etc/rc3.d 디렉토리
S15nfs.server - 파일 시스템 공유에 사용.
S76snmpdx - snmp daemon
CDE 나 OpenWindows와 같은 GUI환경은 시스템 사용에는 매우 편리하지만 편한만큼 보안성은 떨어진다. 시스템 보안이 우선이라면, 그리고 GUI 인터페이스가 꼭 필요하지 않다면 이러한 GUI 환경은 사용하지 않는 것이 좋다. CDE 구동을 위하여 얼마나 많은 포트와 서비스가 필요한지는 CDE환경에서 다음 명령어를 실행시켜 보면 알 수 있다.
ps -aef | wc - l
만일 S99dtlogin 스크립트 및 S71rpc 스크립트의 실행을 중단시킨 후, 즉 CDE환경을 더 이상 사용하지 않은 이후에 위의 명령어를 다시 한번 실행시켜보면 , 얼마나 많은 서비스가 시스템에서 중단되었는가를 비교해볼 수 있다. 서비스가 적게 실행될수록, 시스템 성능은 물론이고 보안성도 향상된다.
CORE Installation
운영체제를 설치할 때 CORE Installation 이라는 항목이 있다. 시스템 운영을 위한 최소한의 요소만 설치하는 것이다. 이것은 시스템 보안을 위하여 널리 권장되는 항목이다. 만일 Core installation을 선택하여 이미 시스템을 설치하였다면 이제껏 언급된 내용은 걱정하지 않아도 된다. Core installation은 GUI환경을 제공해주지 않기 때문이다.
시스템 보안을 위한 Core installation에 관한 자세한 사항은 Sun Micro System의 공식 bule print 문서를 다운받아서 읽어보길 권한다. 아래 주소에 이에 관한 문서가 있다.
http://www.sun.com/blueprints/1299/minimization.pdf
특정 서비스 중단
시스템에서 현재 제공되는 ftp service나 telnet서비스와 같은 특정 서버 프로그램을 중단하는 방법은 /etc/inetd.conf 파일안에 있는 해당 서비스 항목 앞에 #표시를 붙여주면 된다.
예) ftp와 telnet service를 중단하려면 /etc/inetd.conf 파일을 연다. 다음과 같이 ftp와 telnet 항목 앞에 #표시를 붙여준다. # ftp and telnet are standard Internet services. # #ftp stream tcp nowait root /usr/sbin/in.ftpd in.ftpd #telnet stream tcp nowait root /usr/sbin/in.telnetd in.telnetd # 이후 다음 명령을 수행시킨다. # kill -HUP inetd-pid (inetd-pid는 inetd daemon의 process id로서 ps 명령어로 확인할 수 있다)
ftp 사용자의 제한
ftp 사용자를 제한하는 경우는 다음 두가지가 있다.
첫 번째로 root나 bin 계정과 같은 시스템 계정으로 access하는 것을 방지하는 것이다.
두 번째로는 의심가는 사용자에 대하여 ftp 사용권한을 박탈하는 것이다.
이러한 계정에 대한 ftp 서비스를 중단하려면 /etc/ftpusers 파일에 해당 계정을 적어주면 된다.
아래는 /etc/ftpusers 파일의 한 예이다.
root daemon bin sys adm lp uucp nuucp listen nobody noaccess nobody4
보안을 위한 경고메시지 출력
여러분의 시스템에 텔넷으로 접속할 때마다 경고문구가 나온다면, 크래킹과 같은 이상한 행동을 심리적으로 억제해주는 효과가 있다. 이러한 경고문구가 나오게 하려면 /etc/issue 라는 텍스트 형태의 파일을 작성해준다. 그러면 시스템에 로그인할 때마다 경고 메시지가 화면에 출력된다.
아래는 /etc/issue 파일의 한 예이다.
# # 경 고 : 여러분이 접속하여 실행시키는 모든 사항은 모니터링중입니다. # 또한 모든 내용이 시스템에 기록되고 있습니다. # 사소한 불법행위도 고발조치되어 형사처벌 대상이 됩니다. #
위 문구는 으시시할 수록 효과적이다.
[4] 네트웍 보안 및 Firewall
인터넷(Internet) 은 기본적으로 Open된 네트웍이다. 인터넷의 발달은 전세계 네트웍을 연동시킨 Global network 구축이라는 잇점과 함께, 자사의 정보가 전세계에 공개될 수 있다는 네트웍 보안의 취약점을 동시에 가져왔다.
보안이 전제되지 않은 네트웍, 인터넷이라면 이를 사용할 조직은 아무도 없다. 아무리 좋은 컨텐츠를 담은 서버라 할지라도 인터넷과 연결될 때 '네트웍 보안'은 가장 먼저 고려해야할 사항 중 하나이다. (홍보용 웹서버도 마찬가지이다. 웹사이트 해킹을 생각해보라)
그러나 보안적 측면이 강화될수록, 자유로운 네트웍 이용은 제한을 받게 된다. 즉, 보안문제는 인터넷을 자유롭게 이용하고 싶어하는 이용자의 희망과 항상 반대로 가게 된다. (Firewall의 운영이 대표적인 예이다) 따라서 조직에 따라 외부에 공개할 정보와 공개하면 안될 정보를 명확히 구분할 필요가 있고, 이를 토대로 하여 자신들의 적절한 보안정책을 수립하여야 한다.
본장에서는 방화벽과 같은 물리적 보안시스템 구축과 Dial-up Password, RPC와 같은 네트웍 인증시스템에 대하여 알아본다.
가. 방화벽 (Firewall) 시스템의 설치 및 운영
네트웍 보안 시스템에 있어 가장 널리 쓰이는 방법은 방화벽(Firewall System) 설치이다. Firewall이란 내부 네트웍(인트라넷)과 외부 네트웍의 사이에서 검문소 역할을 수행한다. 내부 네트웍과 외부 네트웍의 모든 통신은 Firewall을 거쳐야 하며, Firewall은 양자간에 오가는 모든 통신을 감시하고, 허용되지 않는 접근을 막는다. 이로써 내부 네트웍은 불법적인 네트웍 침입이나 해킹으로부터 보호된다.
외부에서 네트웍에 접근하면 네트웍 전면에 있는 Firewall만이 보이고, 그 뒤에 놓인 인트라넷은 볼 수 조차 없다. 따라서 Firewall까지가 외부인이 도달할 수 있는 한계이며, 방화벽 뒷편의 인트라넷은 안전하게 격리된다. Firewall 자체에는 중요한 정보를 보관하지 않으며, 외부로부터의 접근도 대부분 차단된다. 내부와 외부간에 이루어지는 모든 통신은 Firewall을 반드시 거쳐야만 되므로 상당 수준의 보안 시스템을 구축할 수 있다.
그러나 이러한 Firewall의 보안수준은 조직의 보안정책으로 결정된다. 똑같은 Firewall시스템이 설치되었어도 어떤 네트웍은 통신을 상당부분 제약하는가하면, 어떤 네트웍은 매우 자유로운 통신을 허용하기도 한다. 제한이 많을수록 보안강도는 높아지겠지만, 외부와의 원활한 통신에 어려움이 생기고 인터넷 사용이 부자유스러울 수도 있다. 반대로 제한이 거의 없는 경우에는 사용자들이 인터넷을 사용하는데 전혀 지장이 없고, 외부와의 통신도 원활하지만 보안강도는 낮아진다. 이러한 보안의 강약을 결정하는 것이 보안정책이다.
나. Firewall의 한계와 문제점
Firewall은 자신을 거치지 않는 연결에 대해서는 아무런 기능도 수행할 수 없다. 따라서 시스템에 접속할 수 있는 입구가 많은 네트웍이라면 그 입구마다 Firewall을 설치해야 할 것이다. 특히 취약한 부분은 외부로부터의 Dial-up 모뎀을 이용한 연결이다.
기본적으로 네트웍에는 언제나 헛점이 생길 수 있다. 따라서 극비사항의 정보를 담은 시스템은 네트웍 보안 시스템조차 필요치 않다. 가장 좋은 보안정책은 이러한 시스템은 네트웍 자체에 연결하지 않는 것이다. (이것은 외국 기업의 실제 보안 운영사례이다)
단순히 Firewall을 이용한 접근제어만으로는 진정한 보안이라 하기 어렵다. 정상적인 화일 교환을 이용한 바이러스의 침투, E-Mail 가로채기나 변조 등 역시 Firewall로는 제어할 수 없는 부분이다. Firewall 시스템 구축에 의한 접근제어는 네트웍 보안 시스템의 일부일 뿐이다.
다. Dial-up Password
Dial-up 모뎀을 통한 네트웍 접속시 보안을 위하여 솔라리스 8은 부가적인 암호체계를 가지고 있다. Dial-up password는 시스템에 접속하기 전, 인증을 받기 위한 또하나의 암호이다. 이 Dial-up password는 오직 superuser만이 변경할 수 있다.
Dial-up password를 처음에 만들때에는 /etc/dialups와 /etc/d_passwd라는 두 개의 파일을 함께 만들거나 수정해주어야 한다. /etc/dialups 파일에는 접속시 Dial-up password를 필요로 하는 포트 목록이 포함되어 있다. /etc/d_passwd 파일에는 암호화된 패스워드인 Dial-up password를 필요로 하는 쉘 프로그램의 목록이 포함된다.
/etc/dialups 파일에는 다음과 같은 터미널 디바이스의 목록이 들어있다.
/dev/term/a /dev/term/b /dev/term/c
/etc/d_passwd파일은 두 개의 필드를 가지는데 첫째필드는 암호를 필요로 하는 로그인 쉘이고 그다음 필드는 암호화된 패스워드이다.
/usr/lib/uucp/uuciso:암호화된 패스워드: /usr/bin/csh:암호화된 패스워드: /usr/bin/ksh:암호화된 패스워드: /usr/bin/sh:암호화된 패스워드:
1) 이들 파일은 어떤 역할을 할까 ?
사용자가 /etc/dialups 파일 목록에 있는 포트중 하나에서 로그인을 시도하면 로그인 프로그램은 /etc/passwd안에 저장된 사용자의 로그인 엔트리를 우선 점검한다. 이 엔트리들은 사용자가 다이얼업 패스워드로 로그인할 권한이 있는가를 결정한다.
sunja라는 사용자가 dial-up password로 인증을 받아 시스템에 접속하는 순서를 예를 들어보겠다.
- 사용자 sunja가 /dev/term/b 포트에 로그인을 시도한다.
- /dev/term/b login 포트가 /etc/dialups에 있음을 확인한다.
- /etc/passwd 파일에서 login shell field를 체크한후 이것이 /etc/d_passwd 에 있는 쉘의 해당 암호와 일치하는가를 점검한다.
- /usr/bin/ksh 엔트리의 암호화된 패스워드와 일치함을 확인.
- /etc/d_passwd파일에 있는 password를 묻는 prompt를 보냄
2) /etc/d_passwd 파일의 구성 및 역할
대부분의 사용자들이 login을 할 때에는 shell을 구동한다.
dial-up password를 사용하려면 모든 쉘 (uucico, sh, ksh, csh등) 프로그램은 /etc/d_passwd파일에 엔트리를 만들어 놓으면 된다. /etc/passwd에 만들어 놓은 어떤 사용자의 shell이 /etc/d_passwd에서는 발견되지 않거나, 혹은 /etc/passwd의 로그인쉘 필드가 null값이라면 /usr/bin/sh에 있는 암호를 대신 사용하게 된다.
즉, 이것은 다음과 같이 요약될 수 있다.
- 만일 /etc/passwd에 정의된 사용자의 로그인 쉘이 /etc/d_passwd와 일치한다면 사용자는 dial-up password를 입력하여야 한다.
- 만일 /etc/passwd에 정의된 사용자의 로그인 쉘이 /etc/d_passwd에는 없다면 사용자는 dial-up password대신 default password를 입력하여야 한다. 여기서 default password란 /usr/bin/sh에 있는 entry에 정의된 암호이다.
- 만일 /etc/passwd에 정의된 사용자의 login shell field가 공란(null)이면 사용자는 위 경우와 마찬가지로 dial-up password대신 default password를 입력하여야 한다.
3) Dial-up Password 생성하는 방법
superuser권한 취득
/etc/dialups 파일을 생성한다. 이 파일안에는 터미널 디바이스 리스트와 dial-up password 보호를 필요로 하는 모든 포트가 적혀있어야 한다. /etc/dialups 파일은 다음과 같이 만들어준다. /dev/term/a /dev/term/b /dev/term/c
/etc/d_passwd파일을 생성. 이 파일안에는 dial-up password를 필요로 하는 모든 로그인 쉘 프로그램과 암호화된 dial-up password를 기입해야 한다. /etc/d_passwd 파일의 예. /usr/lib/uucp/uuciso:암호화된 패스워드: /usr/bin/csh:암호화된 패스워드: /usr/bin/ksh:암호화된 패스워드: /usr/bin/sh:암호화된 패스워드: 상기 두 개 파일의 소유권을 root로 한다. # chown root /etc/dialups /etc/d_passwd 상기 두 개 파일의 그룹 소유권을 root로 한다. # chgrp root /etc/dialups /etc/d_passwd 상기 두 개의 파일의 읽기/쓰기 권한을 root만이 갖게 한다. # chmod 600 /etc/dialups /etc/d_passwd 부호화된 패스워드를 생성한다. 이를 위하여 우선 junghee라는 임시 사용자를 만들어보자. # useradd junghee 임시 사용자의 암호를 만든다. # passwd junghee New password : xxxxxx <- 새로 입력한 암호 부호화된 암호를 캡춰한다. # grep junghee /etc/shadow > junghee.temp junghee.temp라는 임시사용자의 암호파일을 편집한다.
이때 부호화된 암호필드 (두번째 필드) 부분을 제외한 나머지 필드는 모두 삭제한다. 예를 들어 아래의 경우에 암호화된 패스워드 필드 부분은 OZry7GgHNJ가 된다. junghee:OZry7GgHNJ:11326: : : : : 임시 사용자를 삭제한다. # userdel junghee 위에서 생성한 junghee.temp 파일에서 암호화된 패스워드를 복사하여 /etc/d_passwd파일안으로 붙여넣는다.
[5] NFS 시스템 보안을 위한 Secure RPC
네트웍 파일 서버는 네트웍을 통해 공유중인 파일에 대한 사용자의 접근을 제어할 수 있다. 어떠한 client PC가 이 파일들을 사용할 수 있는가, 이러한 client들에게 어떠한 형태의 사용권한을 주는가에 관한 적절한 보안레벨을 부여하는 것이다. 일반적으로 파일서버는 읽기/쓰기 권한이나 읽기전용 권한을 모든 client 혹은 특정 client에게 줄 수 있다. 이러한 사용권한은 공유할 자원을 만들때 share 명령어을 사용하여 지정하면 된다.
네트웍상의 client PC들에게 사용가능한 file system의 리스트는 파일서버의 etc/dfs/dfstab파일에서 정의한다.
NFS는 네트웍을 통하여 파일을 공유할 수 있는 편리함을 제공해주는 반면 보안상 아주 좋지 못한 헛점을 드러낼 수도 있다. 이것을 보완하기 위하여 NFS를 사용하기전 인증절차를 거치도록 하는 것이다. 일반적으로 대부분의 NFS는 UNIX 인증 시스템을 사용한다. 그러나 디피-헬만 인증, 혹은 커버로스 인증등을 NFS에 적용할 경우, 보다 강력한 보안대책이 될 수 있다.
유닉스 인증 시스템을 사용할 때 NFS 서버는 사용자를 인증해주는 것이 아니라 요청을 한 컴퓨터에게 파일을 사용할 수 있는 인증을 해준다. 그러므로 사용자는 su 명령어도 실행시킬 수 있고, 파일의 소유자인 것처럼 위장할 수도 있다. 만일 DH인증 시스템을 사용한다면 NFS 서버는 컴퓨터뿐만 아니라 사용자도 인증할 수 있으므로, 이러한 위장은 보다 어려워지게 된다.
네트웍 보안에 대한 최선의 방책은 각각의 응용프로그램에 대한 해결방법을 제시하는 것보다는 모든 응용프로그램을 커버할 수 있는 차원의 향상된 인증 시스템을 제시하는 것이다.
이러한 보안솔루션으로서 솔라리스 운영체제는 Secure RPC (Remote Prcedure Call) 라는 인증시스템을 제공한다. Secure RPC 는 네트웍 환경에서의 보안성을 상당수준 높혔으며 NFS 시스템과 같은 네트웍 파일 서비스를 위하여 또하나의 보안시스템을 추가해준다. Secure RPC 가 제공하는 보안기능을 사용하는 NFS 시스템을 Secure NFS 시스템이라 부른다.
가. Secure RPC
Secure RPC는 원격 시스템에서 시스템에 접근하고자 하는 사용자를 인증해주는 시스템으로서 네트웍 환경에서의 보안을 강화시켜준다.
RPC 인증 시스템을 이해하기 위하여는 "credential (증명서)"와 "verifier (검증)" 이라는 두가지 용어에 익숙해져야 한다. 예를 들어 보자. ID 카드처럼 credential에는 이름, 주소, 생년월일 등 그 사람임을 증명하는 사항들이 기록되어 있다. verifier는 증명서에 부착된 사진과 같다. 증명서에 부착된 사진 때문에 다른 사람이 그 증명서를 훔쳐가서 사용할 수 없음을 알 것이다. RPC에서 client 프로세스는 RPC의 요청이 있을 때마다 credential과 verifier를 서버로 전송한다. 이후 서버는 확인절차를 마친 후 client에게 verifier만을 돌려준다.
네트웍서비스에서 UNIX 인증시스템만을 사용하게 되면, credential에는 클라이언트의 호스트 이름, UID, GID, group-access list등이 포함되지만 verfier에는 아무것도 수록되어 있지 않다. 그이유는 verifier 자체가 없기때문이며 이 때문에 su등의 명령어를 사용하여 superuser가 적절한 credential을 도용할 수 도 있다.
UNIX 인증시스템의 또다른 문제점은 유닉스 인증이 네트웍상의 모든 컴퓨터를 유닉스 운영체제 컴퓨터로 생각해버린다는 것이다. 유닉스 인증시스템은 여러 운영체제가 뒤섞인 혼성 네트웍에서 다른 운영체제가 접근하였을때에는 접속을 끊어버린다.
이러한 유닉스 인증시스템의 문제점을 해결하기 위하여 Secure RPC는 디피-헬만 인증그리고 뒤에서 설명할 커버로스 인증을 함께 사용한다.
나. DH (Diffie-Hellman) 인증시스템
DH 인증시스템은 데이터 부호화 표준 (DES) 및 디피 헬만 public-key 암호을 사용하여 네트웍상의 사용자 및 컴퓨터를 인증해준다. 디피 헬만 public-key 암호시스템은 두 개의 키(하나는 공개, 하나는 비밀) 를 가진다. 공개키 및 비밀키는 모두 지정된 사용자 데이타베이스안에 저장되어 있다. NIS에서는 publickey map에 저장을 하고 NIS+에서는 cred table에 이를 저장한다.
DH 인증시스템의 보안체계에서 송신자는 현재시간을 암호화하여 전송해주고, 수신자는 이를 해독하여 자신의 시스템 시간과 비교한다. 현재시간을 기록한 timestamp는 DES방식으로 암호화한다. 이러한 작업은 다음사항이 반드시 전제되어야 한다.
- 송신자, 수신자 모두 서로의 시간을 동일하게 맞춰놓아야 한다.
- 송신자, 수신자 모두 동일한 암호키를 사용해야 한다.
네트웍에서 시각 동기화 프로그램, 즉 네트웍내어서 시스템간의 시각을 맞추는 프로그램이 실행된다면 클라이언트측과 서버의 시간은 자동으로 동일하게 맞춰질것이다. 이것이 없으면 timestamp는 네트웍의 시간대신 서버의 시간을 이용한다.
RPC 세션을 시작하기에 앞서, 클라이언트는 서버에게 현재시각을 물어본다. 그후 자신과 서버의 시간차를 계산한다. 이 시각차를 상계하여 계산함으로서 서버와 클라이언트간 시각을 동일하게 맞출 수 있는 것이다.
네트웍 보안에 있어서 Secure RPC 및 DH 인증시스템은 꼭 필요한 것이기에 간략히 소개하였다. 이를 위한 실제 설정 및 운영에 관하여는 뒤에서 상세히 설명할 예정이다.
[6] Roal-Based Access Control
이제껏 우리가 사용해온 전형적인 UNIX 보안체계는 superuser는 막강한 힘을 발휘하는 반면에 일반 사용자는 자신의 사소한 문제도 해결할 수 있는 힘조차 가질 수 없는 방식이었다.
솔라리스 운영체제는 RBAC(Roal-Based Access Control)라는 방식을 통하여 기존의 superuser 방식의 보안체계, 즉 全部 아니면 全無라는 방식에 어느정도 융통성을 부여하는 길을 열어주었다. 필요할 경우 특정 사용자에게 새로운 역할를 부여함으로서 수퍼유저의 권한을 적절히 나누어줄 수 있도록 해주는 것이 RBAC의 특징이다.
RBAC에서는 특정 용어가 다음과 같이 사용된다.
- 권한위임 (authorization) 사용자 권한으로는 접근할 수 없었던 작업을 수행할 수 있는 새로운 능력을 부여.
- 실행 profile (Execution profile) 특정한 속성 (예. 사용자 및 그룹 ID)과 연관된 권한 및 명령어를 함께 명시한 메카니즘.
- 역할 (Role) 관리자 작업중 일부를 수행할 수 있도록 고안된 특별한 형태의 사용자계정 (이것 역시 하나의 계정 형태임을 기억하자)
여기서 역할, 즉 role에 대하여 생각해보자.
본 장의 제목이 왜 Role-Based라고 씌어졌을까 ?
그리고 이러한 권한부여가 왜 필요한가 ?
수퍼유저 권한의 일부를 사용자에게 주는것은 보안상 위험한 일이 아닐까 ?
맞는 말이다. RBAC를 잘못 사용하거나 남용하면 시스템은 커다란 혼란기를 겪게 된다. 모험정신(?)이 강한 사용자에게 RBAC를 적용하는것도 위험한 일일 수 있다.
그런데 아래 경우를 한번 상정해보자.
만일 관리자가 일정기간 휴가나 출장을 떠날일이 발생하였다. 그동안 믿을만한 특정 사용자에게 자신의 권한중 일부를 일정기간 부여하고 싶을 때, 즉 그동안 시스템 관리부분의 일부를 대행시키고자 할 때에는 어떤 방법을 사용할 수 있을까 ? 기존의 보안체계에서는 자신의 계정과 암호를 잠시 알려주는 모험에 가까운 방법이 유일한 대안이었다. 아니면 잠시 시스템 관련 작업은 중지하고 있던가.
그러나 RBAC를 활용할 경우, 필요한 일부 권한을 위임(authorization)하여 역할(role)로 만든후 그 역할만을 사용자에게 줄 수 있는 것이다. 이 경우, 사용자는 자연스럽게 일부의 권한을 위임받을 수 있다. 물론 위임받지 못한 역할에 대해서는 전혀 손쓸 수 없을테고.
RBAC는 특정한 권한을 사용자에게 부여할 때 다음 4가지 데이터베이스에 담긴 내용에 따라 작업을 수행한다.
- user_attr (사용자 속성 DB) 사용자, role 및 이들에게 위임할 권한, 그리고 실행 profile을 명시.
- auth_attr (권한속성 DB) 위임 권한 명칭 및 속성을 명시해놓았으며 그에 대한 도움말 파일을 지정.
- prof_attr (실행 profile속성 DB) profile을 명시하고 profile이 지정된 권한을 나열해놓았으며 그에 대한 도움말 파일을 지정.
- exec_attr (profile 실행 속성 DB) profile에 부여한, 특별한 권한을 가지고 있는 작업내용을 명시.
위의 데이터베이스가 RBAC에서 어떤 역할을 할까 ?
user_attr 데이터베이스에서 사용자에게 권한과 실행profile을 지정해줄 수 있다. 이것은 권한을 사용자에게 직접 부여해주는 방식이다.
사용자에게 권한이 아닌 역할(role)을 부여할 수 있다. 이경우, 사용자는 그 역할에 관련된 특별권한을 수행할 수 있는 권한을 갖게 된다. (RBAC를 사용하는 진정한 목적이 바로 이것이다)
실행 profile은 prof_attr DB에 정의되어 있다. 실행 profile은 auth_attr에서 지정한 위임권한 및 exec_attr에서 해당 실행 프로파일에 대하여 지정한 속성과 관련한 명령어를 함께 포함하여 정의할 수 있다. (간단히 표현하면 위임권한과 명령어를 함께 묶어놓았다는 뜻이다)
실행 profile에 지정한 명령어는 profile shell이라고 불리우는 특정 쉘에서만 실행된다. 이 쉘은 pfsh, pfcsh, pfksh라는 이름이 붙어있다. 이들은 각각 Bourne shell (sh), C shell (csh), Korn shell (ksh)에 대응하는 shell로서 각 명칭앞에 pf를 붙였다고 생각하면 된다. (profile shell과 일반 shell은 동일한 것이 아님.)
가. 확장된 사용자속성 DB(user_attr DB)
/etc/user_attr DB는 /etc/passwd 파일과 /etc/shadow 파일을 보조해 주는 역할을 한다. 이곳에는 확장된 사용자 속성 (예. 권한 및 실행 profile등)이 들어있다. 또한 사용자에게 역할을 지정해줄 수 있다.
역할(role)이란 위에서 언급하였듯 관리자밖에 할 수 없는 작업 일부를 일반사용자도 수행할 수 있도록 고안된 특별한 형태의 사용자 계정이다.
역할(role)계정으로 로그인을 하면 사용자는 일반사용자의 계정을 가지고는 실행할 수 없었던 작업을 실행할 권한을 갖게된다.
이러한 권한을 갖게하는 role 계정으로 로그인을 하는 방법은 CDE 로그인과 같은 일반적인 login 과정으로 할 수는 없다. 뒤에서 다시 설명하겠지만 role계정으로 로그인을 하려면 su (switch user) 명령어를 이용하여야 한다.
user_attr DB 는 다음과 같이 콜론(:)으로 각 필드를 구분한다.
user:qualifier:res1:res2:attr
각 필드는 다음과 같은 의미를 갖는다.
- user : passwd DB에 명시된 사용자 이름.
- qualifier : 추후 사용을 위한 예비 필드
- res1 : 추후 사용을 위한 예비 필드
- res2 : 추후 사용을 위한 예비 필드
- attr : 사용자가 명령어를 수행할 때 적용할 보안 속성을 명시한 키 값이다. 여러개의 키를 명시할때 각 키는 세미콜론(;)으로 분리하여 표기한다. 사용할 수 있는 키는 아래와 같다.
- auths : auth_attr DB에 명시된 사용권한 중에서 선택한 권한명칭을 콤마( , )로 구분한 목록. 권한명칭은 와일드카드(*)도 사용할 수 있다. 예를 들어 solaris.device.* 라고 표기한 것은 모든 솔라리스 device에 대한 사용권한을 의미한다.
- profiles : prof_attr DB에 명시된 profile중 선택한 profile명칭으로서 서열순으로 표기하고 콤마( , )로 구분한 목록. Profile은 사용자가 실행할 수 있는 명령어와 해당 명령어의 속성을 결정한다. user_attr에 명시된 사용자중 극소수만이 모든 profile을 가질 수 있는 All로 설정해야 한다. (모든 profile을 갖게 되는 All로 설정한다는 것은 속성에 상관없이 모든 명령어를 사용할 수 있다는 뜻이다) profile의 서열 역시 매우 중요하다. 그것은 마치 유닉스의 탐색경로와 같은 원리로 사용된다. 수행될 명령어가 들어있는 목록 첫째 profile은 어떠한 속성이 어떠한 명령어에 적용되는가를 명시한다.
- role : 사용자에게 새로이 부여할 역할이다. 콤마로 구분한 목록형태로 표시한다. 여기서 역할은 user_attr DB에 있는것과 동일해야 하며 이가운데 특정값을 지정하여 결정한다. role 계정에게는 role을 지정할 수 없다. 오직 사용자 계정에게만 지정할 수 있다. (계정은 일반사용자 계정과 role 계정이 있다)
- type : normal이나 role로 지정한다. 만일 일반사용자 계정이면 normal로, role에 대한 계정이라면 role로 지정한다.
여러분의 시스템에 설치된 user_attr DB를 살펴보면 아래와 같이 기본값이 지정되어 있을 것이다. root::::type=normal;auths=solaris.*,solaris.grant;profiles=All sysadmin::::type=role;profiles=...,Device Management, Filesystem Management,All anne::::type=normal;auths=solaris.system.date;roles=sysadmin;profiles=All
위 예를 살펴보면 첫째줄에서는 root에 대하여 모든 권한을 부여한다. 둘째줄은 role 계정이다. sysadmin에 대한 역할을 정의하였다. 다음줄을 일반 사용자 계정이다. 여기서 anne이라는 사용자에게 sysadmin role을 지정하였다.
이렇게 sysadmin 역할을 지정해줌으로써 anne은 Device Management, Filesystem Management와 모든 profile에 대한 profile을 access할 수 있는 막강한 권한을 갖게 된다.
여기까지의 내용을 한번 정리해보자.
- 역할과 이에 대한 권한을 정의한다.
- 정의한 역할을 사용자에게 부여한다.
- 역할을 부여받은 사용자는 이에 대한 권한을 갖게 된다.
나. Authorizations (auth_attr)
사용자 권한으로는 접근할 수 없었던 작업을 수행할 수 있는 새로운 능력을 부여받는것을 권한위임(authorization)이라 표현하도록 첫장에서 약속한바 있다.
이렇게 위임된 모든 권한은 /etc/security/auth_attr 데이터베이스에 저장된다.
사용자가 이렇게 위임받은 권한을 사용코자 할 때 해당 프로그램은 auth_attr 데이터베이스를 검사하여 위임받은 권한이 있는가를 살펴본후 사용가능 여부를 결정한다. 예를 들어 사용자가 다른 사용자의 crontab 파일을 편집하고자 한다면 solaris.jobs.admin 이라는 권한이 auth_attr에 명시되어 있어야 한다.
사용자 혹은 role이 user_attr 데이터베이스에 명시되어 있으면, 사용자나 role에게 각 권한들을 직접 지정할 수 도 있다. 또한, 실행 profile에 위임할 권한을 지정한후 이것을 다시 해당 사용자에게 넘겨줄 수 있다.
auth_attr 데이터베이스의 각 필드는 콜론으로 구분하여 아래와 같은 형식으로 나타낸다.
authname:res1:res2:short_desc:long_desc:attr
각 필드는 다음과 같은 의미를 갖는다.
- authname : 위임받은 권한을 명시함. 단일 문자형 상수로 표현하며 접두사.접미사 형태로 구성한다. 명명법은 바로 아래에 설명해 놓았다.
- res1 : 추후 사용을 위한 예비 필드
- res2 : 추후 사용을 위한 예비 필드
- short_desc : 사용자 인터페이스를 표시하는데 적당한 권한에 대한 간략한 명칭.
- long_desc : 긴 표현. . 이 필드는 사용될 권한과 응용프로그램의 목적, 그리고 그것을 사용하고자 하는 사용자의 형태를 나타내주어야 한다. 응용프로그램의 도움말로 사용하기 적절하게 표현되어야 한다.
- attr : 권한의 속성을 보여주는 옵션 목록으로서 key 워드로 나타낸다. 여러개를 사용할 때에는 세미콜론 (;)으로 구분함.
키워드로서 help를 사용할때 이에 대한 해당 도움말은 html 형태의 도움말로 되어있다. 이 도움말 파일은 이미 /usr/lib/help/auths/locale/C 디렉토리안에 저장되어 있다.
해당되는 도움말 파일 이름만 help=xxxx.html, 이런 형식으로 적어주면 된다.
authname 명명법 : 솔라리스 운영체제를 사용하는 권한은 solaris라는 접두사로 표현한다. 그외 다른 권한은 그 권한을 만들어낸 기관의 인터넷 도메인 이름 순서를 역으로 배열한 접두사를 사용한다. (예 : deskpia.com의 경우에는 com.deskpia)
접미사는 권한을 행사할 수 있는 부분 (예. device) 및 작업 명칭 (예. config, allocate, grant, revoke등) 으로 표현한다.
만일 접미사가 붙지 않고 씌여져 있다면 authname은 권한에 우선하여 GUI 환경에서 해당 응용프로그램을 실행시키던 명칭으로 작동하게 된다. authname solaris.printmgr. 은 이렇게 GUI환경 하에서의 명칭을 사용한 예이다.
authname이 grant라는 단어로 끝났다면, authname은 그 권한을 grant, 즉 양도해준다. 즉, 사용자의 해당 권한(동일한 접두사 및 기능에 관한 권한)을 다른 사용자에게 양도해주는 것이다.
예를 들어, authname solaris.printmgr.grant 라고 표기되었다면 이는 사용자에게 solaris.printmgr.admin 권한과 solaris.printmgr.nobanner 권한을 다른 사용자에게 양도할 수 있는 권한을 부여한 다는 뜻이다.
여기까지 오게되면 이 복잡한 authname을 어떻게 적절하게 구사할 수 있을지 고민스러울 것이다. 그러나 고민할 필요가 없다.
솔라리스 8을 사용하는 여러분의 etc/security 디렉토리 안에는 auth_attr이라는 파일이 들어있다. 이파일의 내용을 보면 솔라리스 운영에 대한 모든 권한 목록을 망라하고 있음을 발견할 것이다. 불필요한 권한 앞에 주석표시(#)를 하면, 여러분이 필요한 권한만 선택하여 사용할 수 있다.
또한 /usr/lib/help/auths/locale/C 디렉토리의 index.html 파일에도 authname으로 사용할 수 있는 솔라리스 운영에 대한 권한 (authorization) 목록 및 그에 대한 설명을 담은 도움말이 있다.
아래는 auth_attr 데이터베이스 예제로서 여러분의 시스템에 기본적으로 지정이 되어 있는 값이다.
solaris.*:::Primary Administrator::help=PriAdmin.html solaris..grant:::Grant All Rights::help=PriAdmin.html .... 중략 .... solaris.device.:::Device Allocation::help=DevAllocHeader.html solaris.device.allocate:::Allocate Device::help=DevAllocate.html solaris.device.conf::::Configure Device Attributes::help=DevConfig.html solaris.device.revoke:::Revoke or Reclamim Device::help=DevRevoke.html .... 중략 .... solaris.sys:::Machine Administration::help=SysHeader.html solaris.system.date:::Set Date and Time::help=SysDate.html solaris.system.shutdown::: Shutdown the System::help=SysShutdown.html
auth_attr과 user_attr의 관계는 다음 예제에서 볼 수 있다.
auth_attr DB solaris.*:::Primary Administrator::help=PriAdmin.html ... solaris.system.date:::Set Date & Time::help=SysDate.html
auth_attr 데이터베이스에 명시된 solaris.system.date 권한은 시스템의 날짜와 시각을 조정할 수 있는 권한이다. 이 권한이 'auths=solaris.system.date' 라는 문구 한줄로서 아래 예제의 user_attr 데이터베이스에 있는 sunny라는 사용자에게 지정되는 것이다.
user_attr DB root::::type=normal;auths=solaris.*,solaris.grant;profiles=All ... sunny::::type=normal;auths=solaris.system.date;roles=sysadmin;profiles=All ....
sunny라는 사용자가 solaris.system.dat 권한 및 sysadmin이라는 역할을 위임받았다.
다. 실행 profile DB (prof_attr)
실행 profile은 권한과 명령어를 특별한 속성과 함께 묶어놓은 메카니즘이다. 여기에서 지정한 실행 profile들은 사용자나 role에게 지정할 수 있다. 특별한 속성이란real 및 effective UID, GID를 지칭한다. 가장 일반적인 속성은 real UID 및 effective UID가 root로 지정된 형태이다. 실행 profile의 정의는 etc/security/prof_attr 데이터베이스에 저장되어 있다.
(실행 파일이 수행되면서 프로세스가 만들어질 때, 프로세스를 생성시킨 사용자의 UID를 real UID라 하고, 생성된 프로세스가 가지는 UID를 effective UID라 한다. 일반적으로는 real UID와 effective UID는 같다. 그리고 프로세스는 effective UID의 권한으로 수행된다)
prof_attr 데이터베이스 역시 콜론으로 각 필드가 구분된다.
profname:res1:res2:desc:attr 각 필드에 대한 설명은 다음과 같다.
키워드로서 help를 사용할때 이에 대한 해당 도움말은 html 형태의 도움말로 되어있다. 이 도움말 파일은 이미 /usr/lib/help/auths/locale/C 디렉토리안에 저장되어 있다. 해당되는 도움말 파일 이름만 help=xxxx.html, 이런 형식으로 적어주면 된다.
아래는 여러분의 시스템에 설정된 prof_attr DB의 예이다. All:::Standard Solaris user:help=All.html Audit Control:::Administer the audit subsystem:auths=solaris.audit.config,solaris.jobs.admin; help=AuditControl.html Audit Review:::View the audit trail:auths=solaris.audit.read;help=AuditReview.html Device Management:::Control Access to Removable Media:auths=solaris.device.*;help=DevMgmt.html Printer Management:::Control Access to Printer:help=PrinterMgmt.html
아래 예제는 prof_attr과 user_attr의 관계를 나타낸 것이다. Profile Attributes Database All:::Standard Solaris user:help=All.html ... Device Management:::Control Access to Removable Media: auths=solaris.device.*;help=DevMgmt.html ..
Device Management라는 실행 프로파일의 권한과 명령어를 정의하였다. User Attributes Database 예제 root:::type=normal;auths=solaris.*,solaris.grant;profiles=All sysadmin:::type=role;profiles=Device Management
sysadmin이라는 role계정을 만들어서 Device Management 권한을 부여하였다. 이후, prof_attr에서 정의한 Device Management profile이 user_attr에서 정의한 sysadmin role에게 지정되었다.
prof_attr과 auth_attr의 관계는 다음 예제에서 볼 수 있다. Profile Attributes Database All:::Standard Solaris user:help=All.html ... Device Management:::Control Access to Removable Media: auths=solaris.device.*;help=DevMgmt.html ...
위에서 보면 Device Management profile은 solaris.device. 라는 문자열 상수로 시작되는 모든 권한을 갖는 것으로 prof_attr에서 정의된다. 이러한 권한들은 아래 auth_attr에서 정의된 것이다. auth_attr Database 예제 solaris.*:::Primary Administrator::help=PriAdmin.html solaris..grant:::Grant All Rights::help=PriAdmin.html .... solaris.device.:::Device Allocation::help=DevAllocHeader.html solaris.device.allocate:::Allocate Device::help=DevAllocate.html solaris.device.config::::Configure Device Attributes::help=DevConfig.html solaris.device.revoke:::Revoke or Reclaim Device::help=DevRevoke.html
라. 실행속성 DB (exec_attr)
실행속성은 profile이 지정된 해당 사용자나 role에 의하여 수행되는 명령어로서 특별한 보안속성을 가진다. 여기서 특별한 보안속성은 UID, EUID, GID, EGID와 같은 속성으로서 명령어가 실행될 때 해당 프로세스에 추가된다.
실행속성이 명시된 내용은 /etc/security/exec_attr 데이터베이스에 저장된다.
exec_attr 데이터베이스 역시 콜론으로 각 필드가 구분된다. name:policy:type:res1:res2:id:attr
각 필드에 대한 설명은 다음과 같다.
- name : profile의 명칭
- policy : 해당 엔트리에 관련된 보안정책, 현재로는 suser (수퍼유저 정책 모델)만이 유효한 값이다.
- type : 속성이 명시된 엔티티 형태. 현재로는 cmd (command)만이 유효한 값이다.
- res1 : 추후 사용을 위한 예비 필드
- res2 : 추후 사용을 위한 예비 필드
- id : 엔티티를 규정한 문자열 상수. 와일드카드 (*)를 사용하여 나타낼 수 있음. 명령어들은 전체 경로 혹은 와일드카드 (*)를 포함하는 경로를 가져야 한다.
- attr : 실행할 엔티티에 적용할 보안 속성을 표현한 옵션 목록으로서 key 워드로 나타낸다. 여러개를 사용할 때에는 세미콜론 (;)으로 구분함. 사용할 수 있는 키워드는 보안정책에 따라 결정된다. 유효한 키워드로는euid, uid, egid, gid등 4개가 있다.
euid 와 uid는 단일 사용자이름이나 숫자로된 사용자 ID를 포함한다. euid를 지정하는 명령어는 지정된 real UID값과 함께 실행된다. 이것은 실행파일에 setgid 값을 설정하는것과 비슷한 과정이다. gid를 지정하는 명령어는 real GID 및 effective GID와 함께 실행된다.
아래는 필자의 exec_attr 데이터베이스에 대한 값중 일부를 나타낸 것이다.
보안관계상 모두 보여드리지 못하지만 여러분의 시스템에서도 찾아볼 수 있다. All:suser:cmd:::*: ... Printer Management:suser:cmd:::/usr/bin/cancel:euid=0 Printer Management:suser:cmd:::/usr/bin/lpset:egid=14 Printer Management:suser:cmd:::/usr/lib/lp/enable:euid=lp .... .... Printer Management:suser:cmd:::/usr/sbin/lpusers:euid=lp
다음장에서는 RBAC에서 지정한 role 계정으로 로그인하는 방법을 직접 실습해보고, 그외 관련 유틸리티들을 알아보도록 하겠다.
마. RBAC 실습 및 관련 유틸리티
이제껏 학습한 RBAC를 직접 실습해보자.
우선 다음과 같이 role 계정을 만들어보자. 이것은 /etc/user_attr파일을 편집하면 된다. (이 파일은 root에게 소유권이 있으며 읽기전용이다. 그러므로 편집을 하려면 파일 속성을 변경해주어야 한다. 편집이 끝난 후에는 다시 원상태로 파일 속성을 돌려놓자) root::::type=normal;auths=solaris.*,solaris.grant;profiles=All sysadmin::::type=role;profiles=...,Device Management, Filesystem Management,All
이렇게 변경한 후, 위에서 만든 sysadmin이라는 role 계정으로 로그인을 해보자.
role 계정으로 로그인할때에는 CDE에서 로그인하는것과는 다르다. 다음과 같이 su 명령어를 사용해야 한다. $ su sysadmin
이렇게 로그인해보면 어떤 메시지가 화면에 나오는가 ? 아마도 sysadmin이라는 사용자가 없다는 메시지가 나올 것이다. 이유는 잘 아실 것이다. 비록 user_attr에 sysadmin이라는 role계정을 만들었다 해도, sysadmin이라는 사용자계정이 존재하지 않기 때문이다. (user_attr은 passwd 및 shadow 파일을 보충해주는 역할이란 것을 이미 설명한 바 있음)
그렇다면 먼저 해야할 일은 ?
sysadmin이라는 새로운 사용자 계정을 만들어준 후 다시 로그인을 해보자. $ su sysadmin Password: Roles can only be assumed by authorized users su: 잘못되었습니다 $
이번에는 로그인이 되는가 싶었는데 다시 에러메시지가 나온다. 왜그럴까 ? 위에서 만든 user_attr에는 sysadmin이라는 role계정만 만들었지, 이 role계정을 사용할 수 있는 사용자를 지정하지 않았기 때문이다. 즉, sysadmin이라는 role계정을 부여받은 사용자만이 sysadmin이라는 role 계정으로 login할 수 있는 것이다.
그럼 user_attr을 이렇게 편집해본다.
root::::type=normal;auths=solaris.*,solaris.grant;profiles=All sysadmin::::type=role;profiles=...,Device Management, Filesystem Management,All anne::::type=normal;auths=solaris.system.date;roles=sysadmin;profiles=All
새로이 추가된 세 번째줄은 sysadmin이라는 role계정을 anne이라는 사용자에게 부여한다는 뜻이다. 여기서 anne이라는 이름은 기존에 이미 등록되어 있는 사용자중 하나를 선택한 것이다. anne대신 자신의 사용자 id를 집어넣어도 된다.
이후 role계정을 부여받은 id로 다시 로그인을 한다. (이때 로그인은 일반 사용자 로그인이다) 그후 위에서 처럼 su를 이용하여 다시 role계정으로 로그인하여보자. $ su sysadmin Password: $
sysadmin이란 계정에 대한 암호를 입력하고 나면 멋지게 role 계정으로 로그인할 수 있을 것이다. 이제 sysadmin에게 부여된 모든 권한을 이 role 계정을 통하여 행사할 수 있다.
솔라리스 8 시스템에는 etc/security 디렉토리에 이미 auth_attr, exec_attr, prof_attr DB가 만들어져 있다. 이들을 가지고 적절히 편집하여 role 및 권한부여를 실습해보면 RBCA의 진가를 느낄 수 있을 것이다.
아래 도구들은 RBAC를 운영하는데 필요한 유틸리티이다.
- auths : 사용자의 위임권한을 표시해줌.
- pfexec : profile 쉘, exec_attr DB안에 명시된 명령어를 속성과 함께 실행시킴.
- policy.conf : 보안정책을 configuring 해준 파일. 부여한 권한을 나열함.
- profiles : 특정 사용자에 대한 profile을 보여줌.
- roles : 사용자에게 부여한 권한을 보여줌.
이상으로 RBAC에 대한 설명을 모두 마쳤다. 쉽지는 않지만 일단 이해하고 나면 매력적인 운영체제가 바로 솔라리스 8이 아닌가 싶다.
[7] 암호/인증 시스템의 개요와 구분
솔라리스 운영체제는 시스템 및 네트웍 보안을 위하여 SEAM (Solaris Enterprise Authentication Mechanism), Diffie-Hellman등의 인증 시스템을 제공한다. 본 단원에서는 이가운데 Diffie-Hellman 인증시스템 에 대하여 알아보도록 한다. (SEAM은 다음단원에서 따로이 설명할 예정이다)
가. 암호 시스템
인증시스템에 들어가기에 앞서서 컴퓨터에서 사용하는 암호 시스템에 대하여 살펴보기로 하자.
암호하면 떠오르는 것이 의례 첩보영화나 군사작전일 것이다. 적에게 노출되더라도 비밀이 보장될 수 있도록 평문(plain text)에 보안을 부여하는 것이 암호의 목적이다. 이것은 오늘날 컴퓨터 시스템 보안에도 그대로 적용되고 있다. 물론 암호화 (encryption)기법이 발달할수록 이것을 불필요한 상대방, 예를 들어 해커의 의해 불법적으로 해독 (복호화,decryption)되는 기법도 발전하는 것이 문제이긴 하지만.
오늘날은 암호화하는 방식에 키(key)를 사용한다. 이 키를 운영 방식에 따라 비밀키 암호 시스템과 공개키 암호 시스템으로 나뉜다.
1) 비밀키 암호 시스템
이 시스템은 하나의 비밀키만으로 암호화/ 복호화(해독)를 동시에 수행한다. 전송측과 수신측이 하나의 키를 이용해 암호화와 복호화를 하게 되므로 키를 철저히 관리는것은 이 시스템의 사활이 달린 사안이기도 하다.
비밀키 암호시스템은 공개키 암호시스템에 비해 알고리즘이 단순하여 속도가 빠르고 회로가 간단하다. 비밀키 방식에는 블록 암호 시스템과 스트림 암호 시스템이 있다.
블록 암호 시스템 : 고정된 크기의 입력 블록을 고정된 크기의 출력 블록으로 변형하는 암호 알고리즘을 가지고 암호화 및 복호화 과정을 수행한다. 뒤에서 설명할 DES도 이 시스템중 하나이다.
스트림 암호: 모든 평문에 동일한 암호화 함수가 적용되는 블록 암호와는 달리 비밀키와 현재의 상태 변수(state variable)에서 도출되는 키의 수열(key stream)이 평문과 결합되어 암호문을 생성하는 방식이다.
2) 공개키 암호 시스템
비밀키 시스템에서는 하나의 키만을 사용하므로 그 키가 노출되면 시스템의 소유자가 바뀔 수 있다.
이러한 문제를 해결하기 위하여 개발된 것이 공개키 (public key) 암호 시스템이다.
1976년 미국 스탠포드 대학의 Diffe와 Hellman이 제안한 암호 시스템으로서 모든 사용자는 모든 사람에게 공개되어 있는 공개키(public key)와 자기만의 개인키 (private key 혹은 secret key로도 쓴다) 를 가지고 있다.
공개키는 문서를 암호화할 때 사용하며, 개인키 즉 비밀키는 개인이 보관을 하면서 암호화된 문서를 해독할 때 사용한다. 비밀키만을 사용하는 것에 비해 키를 관리하는 것이 보다 수월해진 것이다.
특히 이러한 개념은 메시지 내용 또는 발신자가 자신이 발송하였음을 부정하는것을 방지할 수 있는 디지털 서명을 가능케 하여 오늘날 전자상거래의 한 축을 담당하고 있다. (개인키는 발신자만이 가질 수 있으므로)
공개키 암호 시스템은 두 개의 키를 사용하느니 만큼, 하나만을 사용하는 비밀키 암호 시스템에 비해 속도가 느리고 키의 길이도 길다.
3) DES (Data Encryption Standard)
DES (Data Encryption Standard, 데이터 암호화 표준기법) 는 앞서 설명한 비밀키 암호시스템으로서 블록 암호 시스템에 속한다. 이것은 1974년에 미국 통상부의 공식권유에 의하여 IBM이 국가표준국(National Bureau of Standards: 현재의 국가기술표준연구소(NIST))과의 계약에 따라 개발한 시스템이다.
DES는 데이터의 암호화 기법에 56bit key를 사용한다. 두사람의 사용자가 서로만의 비밀문서나 파일을 주고받을 때 둘만의 동일한 DES키를 사용하여 파일내용을 암호화한후 이를 전송할 수 있고, 또한 이를 해독할 수 있다. DES는 전용 DES chip을 사용하거나 소프트웨어적으로도 구현할 수 있다. 또한 하나의 키만을 사용하므로 비교적 빠른 암호화 메카니즘에 속한다.
우리가 사용하고 있는 Unix password 생성도 바로 DES를 이용한 것이다.
그러나 DES도 약점이 있다. 동일한 키를 가진 전문 해커가 파일내용을 가로챌 경우, 동일한 키에 의해 모든 전송내용이 해독될 수 있다. 이러한 이유로 Secure NFS와 같은 보안시스템에서는 사용하는 key를 수시로 변경해준다.
① 인증 및 절차
네트웍상에서 이루어지는 서버와 클라이언트간의 인증절차는 다음과 같다
클라이언트는,
- 자신의 공개키/비밀키 짝을 생성하고,
- 서버를 방문하여 신원증명(credential)을 제시한 후,
- 공개키에 대응하는 비밀키를 자신이 보유하고 있다는 것을 (비밀키의 공개 없이) 증명한다.
위 절차는 간단하지만 아주 중요한 절차이다. 잘 기억해두도록 하자.
② 솔라리스 운영체제에서의 Diffie-Hellman 인증법
솔라리스 8에서 제공하는 디피 헬만 인증법은 클라이언트와 서버 양측이 동일한 비밀 키, 즉 공동의 키를 사용하여 서로를 인증해주는 독특한 방식이다. 양측은 서로만이 알 수 있는 암호화/복호화(해독) 기법을 사용하여 보안성이 보장되는 통신을 하게 된다.
이 인증방식은 현재 시각을 암호화한 공동의 키 (common key)를 사용하여 시스템에 전송하는 방식을 골자로 한다. 암호화된 공동의 키를 수신한 시스템은 이를 해독하여 현재시각과 비교하게 된다. 물론 클라이언트와 서버 양측이 사전에 시각을 맞춰놓는 것이 선결조건이다.
여기에서도 물론 공개키(public key)와 비밀키 (secret key)가 사용되는데 이들은 모두 NIS나 NIS+ 데이타베이스에 저장되어 있다. NIS는 publickey map에 키를 저장을 하고 NIS+는 cred table에 키를 저장한다.
공개키와 비밀키는 시스템 관리자가 생성시켜준다. 이가운데 비밀키는 각 사용자의 패스워드안에 암호화되어 저장되며 사용자만이 자신의 비밀키를 알 수 있다. (시스템관리자가 생성시켜준다 하더라도 사용자가 다시 패스워드를 입력하여 비밀키를 바꾸게 된다)
나. 인증 key의 생성 및 활용
Secure RPC가 수행되는 과정에서 사용자를 인증하는 방식을 예를 들면서 각 키가 어떻게 만들어지고 어떻게 활용되는가를 알아보자.
1) 공개키 및 비밀키 생성
시스템관리자는 /usr/sbin에 있는newkey와 /usr/bin에 있는 nisaddcred 라는 두가지 명령어를 이용하여 공개키 및 비밀키를 만들어준다. 키를 변경할때에는 /usr/bin에 있는 chkey 명령어를 사용한다.
처음 로그인시 keylogin이라는 프로그램이 등장한다. 이 프로그램은 로그인 암호가 secure RPC 암호와 동일할 경우에는 사용되지 않는다. 그러나 서로 다를 경우에는 로그인후에 keylogin 이 자동 실행된다.
keylogin의 역할은 다음과 같다.
우선 사용자에게 secure RPC 암호를 물어본후, 답변을 통해 얻게된 암호로 비밀키를 해독한다. 그다음 keyserver라는 프로그램에게 해독한 비밀키를 건네준다. 키서버는 해독된 비밀키를 받아서 저장한후 사용자가 secure RPC transaction을 시작하는 때를 기다리게 된다.
(만일 로그인 암호가 secure RPC 암호와 같은 경우, 로그인 프로세스가 직접 키서버에게 비밀키를 건네준다. 암호가 달라야 할 경우, 사용자는 언제나 keylogin을 구동시켜야 한다. keylogin은 ~/.login, ~/.cshrc ~/profile과 같은 사용자 환경설정 파일 안에 포함되어 있으므로 사용자가 로그인을 할 때마다 자동적으로 수행된다.)
2) 대화키 (conversation key) 생성
사용자가 secure RPC transaction을 시작하면
- keyserver가 난수를 발생시켜 대화키(conversation key)를 생성한다.
- 커널은 생성된 대화키를 사용하여 사용자의 현재시각을 암호화시킨 time stamp를 생성한다.
- keyserver는 공개키 (public key) 데이터베이스에서 서버의 공개키를 찾아낸다.
- keyserver는 사용자의 비밀키와 서버의 공개키를 사용하여 공동의 키(common key)를 생성한다.
- keyserver는 공동의 키(common key)로 대화키(conversation key)를 암호화한다.
3) 서버와의 첫 번째 접속
클라이언트는 전송할 자료에 현재시각을 암호화된 time stamp와 암호화된 대화키를 함께 넣어 서버로 전송한다. 전송시 credential과 verifier도 포함된다. ( credential과 verifier의 개념은 네트웍 보안 부분을 참조하기 바란다) credential은 다음 3가지 요소를 포함하고 있다.
- 클라이언트의 망(net) 이름.
- 공동의 키로 암호화된 대화키
- 대화키로 암호화된 window
여기서 window란 서버의 시각과 클라이언트의 time stamp 사이의 시간차이로서 클라이언트가 허용할 수 있는 범위를 말한다. 만일 서버와 클라이언트의 시간 차이가 윈도우보다 커질 경우, 서버는 클라이언트의 요청을 거부할 것이다. 그러나 정상적 상황에서 이러한 일은 벌어지지 않는다. 왜냐하면 클라이언트는 RPC 세션을 시작하기 전에 서버와 자신의 시각을 똑같이 맞추는 동기화작업을 우선적으로 하기 때문이다.
클라이언트의 verifier는 다음 사항을 포함하고 있다.
- 암호화된 time stamp
- 암호화된 윈도우 verifier (1씩 감소함)
윈도우 verifier는 누군가가 사용자로 위장한후 암호화된 credential과 verifier 필드에 난수를 발생시킨 데이터를 채워넣는 방식으로 해킹을 시도할 때 방어용으로 사용된다.
수천번의 시도를 한다 할지라도 해커가 만들어낸 난수로 된 윈도우/타임스탬프 짝이 인증시스템을 통과한다는 것은 매우 힘든일이다. 윈도우 verifier 시스템은 정확한 credential을 추측하기 아주 어렵게 되어있기 때문이다.
4) 대화키 해독과정
서버가 클라이언트로부터 전송자료를 받은후
- 로칼 keyserver는 공개키 데이터베이스안에서 클라이언트의 공개키를 찾는다.
- keyserver는 클라이언트의 공개키와 서버의 비밀키를 사용하여 공동키, 즉 클라이언트에 의해 계산된 동일한 공동키를 추론한다. (서버와 클라이언트만이 공동키를 계산해낼 수 있다. 자신이나 상대방의 비밀키를 알아야만 하기 때문이다)
- 커널은 공동키를 이용하여 대화키를 해독한다.
- 커널은 keyserver를 호출하여 해독한 대화키를 이용, 클라이언트의 time stamp를 해독한다.
5) 서버에 정보 저장
서버가 클라이언트의 time stamp를 해독한 다음에는 credential table안에 다음 4가지 정보를 저장한다.
- 클라이언트의 컴퓨터 이름
- 대화키
- 윈도우
- 클라이언트의 time stamp
서버는 추후 사용을 위하여 상기 4가지 사항중 클라이언트의 컴퓨터 이름, 대화키, 윈도우 3가지 사항을 저장해둔다. 서버에 저장된 타임스탬프는 누군가가 동일한 타임스탬프로 접근하는 것을 방어해준다. 즉, 서버는 최종적으로 사용된 것보다 시간적으로 큰값을 가진 타임 스탬프만을 받아들이기 때문에 재사용은 불가능하다.
6) 클라이언트로 되돌려주는 verifier
서버는 클라이언트에게 다음사항이 포함된 verifier를 돌려준다.
- 서버가 credential cache에 저장한 기록인 index ID
- 클라이언트의 time stamp에서 1을 뺀 값 (대화키에 의해 암호화된 값임)
time stamp에서 1을 빼는 이유는 time stamp가 클라이언트의 verifier에 의해서 더 이상 사용되어질 수 없도록 하기 위함 이다.
7) 클라이언트가 서버를 인증하는 과정
클라이언트는 서버로부터 verifier를 받은 후에야 서버를 인증하게 된다. 클라이언트는 오직 서버만이 verifier를 전송해줄 수 있음을 알고 있다. 왜냐하면 서버만이 클라이언트가 보낸 time stamp가 무엇인가를 알고 있기 때문이다.
- 디피 헬만 인증의 실제 구현을 위한 keyserver의 구동 - 수퍼유저 권한을 갖는다. - keyserver 데몬이 작동중인가를 검사한다. # ps -ef | grep keyserv root 100 1 16 Apr 11 7 0:00 /usr/sbin/keyserv root 2215 2211 5 09:57:28 pts/0 0:00 grep keyserv 만일 keyserver가 작동중이지 않으면 이를 실행시킨다. # /usr/sbin/keyserv
다. 디피 헬만 인증을 이용한 NIS+ credential 설정방법
1) NIS+ 클라이언트측의 root를 위한 새로운 키 설정방법
사용자의 네트웍이 NIS+ 환경이라면 아래와 같이 클라이언트 시스템의 설정을 해주면 된다.
- 수퍼유저 권한을 갖는다.
/etc/nsswitch.conf파일을 열어서 다음 사항을 추가한다.
publickey: nisplus
- NIS+ 클라이언트를 초기화한다.
# nisinit -cH 호스트이름
위에서 호스트 이름이란 클라이언트에게 서비스를 제공해주는 NIS+ 서버의 이름이다. 물론 호스트서버 이름은 클라이언트의 테이블에 NIS + 서버로 등록되어 있어야 한다.
- 아래 명령어를 사용하여 cred 테이블에 client를 추가한다.
# nisaddcred local # nisaddcred des
- keylogin 명령어를 사용하여 설정된 내용을 검사한다.
아래 예는 young이라는 호스트를 이용하여 jinhee를 NIS+ 클라이언트로 설정해주는 방법이다. 여기서 네트웍 패스워드를 물어올때에 나오는 경고메시지는 무시해도 된다. keylogin 명령어가 올바로 실행되었다면 jinhee라는 클라이언트는 NIS+ client로 올바르게 설정된 것이다. # nisinit -cH young NIS Server/Client setup utility. This machine is in the rose.deskpia.com directory. Setting up NIS+ client ... All done. # nisaddcred local # nisaddcred des DES principal name : unix.jinhee@rose.deskpia.com Adding new key for unix.jinhee@rose.deskpia.com (jinhee.rose.deskpia.com) Network password: xxx Warning, password differs from login password. Retype password: xxx # keylogin Password: #
2) NIS+ 사용자를 위한 새로운 키 설정
root의 마스터 서버에 아래 명령어를 입력하여 cred table에 새로운 사용자를 추가시킨다.
# nisaddcred -p unix.UID@도메인이름 -P 사용자이름.도메인이름. des
이 경우, 사용자 이름과 도메인 이름은 도트(.)로 끝나야 한다.
클라이언트로서 로그인하여 설정된 것을 확인한 후 keylogin 명령어를 입력한다.
아래 예는 sunhee라는 사용자에게 DES 보안인가를 해주는 과정이다. # nisaddcred -p unix.1234@rose.deskpia.com -P sunhee.deskpia.com. des DES principal name : unix.2346@rose.deskpia.com Adding new key for unix.2346@rose.deskpia.com (sunhee.rose.deskpia.com.) Password: Retype password: # rlogin rootmaster -l sunhee # keylogin Password: #
라. 디피 헬만 인증을 이용한 NIS credential 설정방법
1) NIS 클라이언트측의 root를 위한 새로운 키 설정방법
1. 클라이언트 컴퓨터의 수퍼유저 권한을 갖는다.
2. /etc/nsswitch.conf파일을 열어서 다음 사항을 추가한다.
publickey: nis
3. newkey 명령어을 이용하여 새로운 한쌍의 키를 생성한다. # newkey -h hostname
위에서 호스트 이름은 NIS 서버가 아니다. 클라이언트 computer 이름을 입력해야 한다.
아래 예는 jinhee라는 클라이언트 컴퓨터를 NIS client 로 설정하는 과정이다.
# newkey -h jinhee Adding new key for unix.jinhee@deskpia.com New Password: Retype password: Please wait for the database to get updated... Your new key has been successfully stored away. #
2) 사용자를 위한 새로운 키 생성방법
- 관리자가 서버에서 수퍼유저로 로그인한다.
- 사용자를 위한 새로운 키를 만든다.
- newkey -u 사용자이름
시스템은 패스워드를 물어올 것이다. 패스워드를 입력하고 나면 개인키는 암호화되어 패스워드안에 저장된다.
이제 사용자를 부를 차례다. 사용자로 하여금 컴퓨터 앞에 앉아 직접 로그인을 하게 한다. 그후 chkey -p 명령어를 사용하여 개인키를 본인이 직접 다시 암호화시키도록 한다.
chkey -p Updating nis publickey database. Reencrypting key for unix.12345@deskpia.com Please enter the Secure RPC password for junghee : please entet the login password for junghee: Sending key change request to deskpia...
위 과정은 junghee라는 사용자가 사용자만이 아는 암호로서 개인키를 다시 암호화시키는 과정이다.
마. 디피 헬만 인증을 이용한 파일공유 및 마운트
NFS는 널리 사용되는 네트웍 서비스이지만 항상 보안이 문제되는 시스템이었다. 솔라리스 운영체제에서 제공하는 Diffie-Hellman 인증을 NFS에 적용시키면 보다 강력한 보안체계를 구축할 수 있다. 이에 대한 실제 적용방법을 알아보자.
1) 파일 공유
수퍼유저 권한을 갖는다.
아래와 같이 share명령어에 F 옵션을 붙여 파일을 공유한다. 그런데 일반적인 NFS 사용때와 다른 옵션이 눈에 띌 것이다. 바로 -o sec=dh라는 옵션이다. 이것은 디피헬만 인증을 사용하여 파일을 공유할때 붙이는 옵션이다.
# share -F nfs -o sec=dh /공유파일경로
2) 파일마운트
수퍼유저 권한을 갖는다.
Mount 명령어에 F 옵션을 붙여 파일을 마운트한다. 이때 디피헬만 인증법으로 파일을 마운트하기 위하여 -o sec=dh 옵션을 붙인다.
# mount -F nfs -o sec=dh 서버명:공유자원 mountpoint
추신. 보안에 있어서 암호화 알고리즘과 키의 길이는 매우 중요이다. 그러나 이에 못지않게 중요한 요소가 바로 보안프로토콜이다.
암호화 알고리즘 기술은 이미 상당한 수준으로 연구, 개발되어있기 때문에 시스템이나 네트웍 보안에 사용할 수 있는 것들을 쉽게 접할 수 있다. 그러나 자료가 암호화되었다고 무조건 안전하다고 마음놓을 수는 없다. 상당수준의 알고리즘으로 암호화되었다 하더라도 제 3자에 의한 보안침해의 가능성은 언제든 발생할 수 있다고 생각해야 한다.
이런 점을 보완해주는 것이 바로 보안 프로토콜이다. 예를 들면 WWW보안에는 SSL(Secure Socket layer) SHTTP 등이 있으며 전자우편에는 PEM, S/MIME 등과 같은 보안프로토콜이 있다.
완벽에 가까운 보안체계 구축을 위하여는 암호화 알고리즘뿐 아니라 보안프로토콜 역시 매우 중요한 요소임을 알아두어야 하겠다.
[8] SEAM 과 Kerberos ver.5
가. 개요
시스템 및 네트웍 보안을 위하여 전세계적으로 사용되는 인증시스템중 하나가 Kerberos 인증 프로토콜이다.
Solaris 운영체제 역시 커버로스를 보안 및 인증 프로토콜로 채택하고 있다. 솔라리스 이전버전에서는 커버로스 버전 4을 제공해주었으나 솔라리스 7부터는 SEAM, 즉 썬 엔터프라이즈 인증 시스템이라는 이름으로 커버로스 최신버전인 ver.5를 제공하고 있다.
혹시, 솔라리스 8을 interactive 방식으로 설치하는 도중, 네트웍 설정과정에서 이 컴퓨터가 kerberos client로 참여할 것인지를 물어보는 메뉴를 본적이 있는지 ? 처음 설치하다 이것을 보고 yes를 선택하면 KDC서버의 ip address를 비롯한 갖가지 서버 옵션을 설정하는 화면이 나오게 된다. 커버로스를 모르면 이 부분에서 매우 당황하게 된다.
물론 처음 설치시에는 커버로스 클라이언트로 설정하지 않아도 나중에 설치를 마친후에 커버로스 클라이언트로 자신의 시스템을 설정할 수 있다.
여기서 커버로스 인증시스템이 무엇이며 어떠한 장점이 있는가를 알아보도록 하자.
1) Kerberos의 역사
커버로스는 미국 MIT 에서 Athena 프로젝트의 일부로 설계되었다. 이 프로젝트의 목적은 고속의 교육망에 연결된 서버들간에 우수한 데이터 서비스를 제공하기 위한 것이었다. 커버로스는 여기서 사용자, 즉 클라이언트와 서버간에 인증기능을 제공하기 위해서 개발됐다.
2) Kerberos의 특징
① 제 3의 인증서버
일반적인 인증시스템은 서버가 모든 클라이언트의 사용자를 직접 인증해주는 방식이다. 그러나 커버로스는 클라이언트와 서버, 그리고 클라이언트의 사용자를 인증해주는 제 3의 서버 이렇게 삼각 관계로 구성되어 있다. 그리고 여기서 등장하는 제 3의 서버, 즉 인증서버를 이용해 사용자의 신분확인이 이루어진다.
신뢰할 수 있는 제 3의 컴퓨터가 서비스를 이용하려는 사용자를 인증해준다면 서버는 클라이언트의 사용자가 올바른 사용자인지를 확인할 수 있으며 서로간 비밀통신이 가능해진다. 이러한 시스템은 현재 인터넷상에서 사용자 인증기법으로 널리 사용되고 있다.
② 패스워드를 대신한 티켓전송
매번 웹상에서 패스워드를 입력할 때마다 불안한 적이 있었을 것이다. 혹시나 누군가가 이것을 중간에 가로채지는 않을까 하고. 커버로스는 네트웍에서 패스워드 대신 커버로스 티켓(ticket)을 보내는 커버로스 기법을 제공하므로 이러한 걱정을 덜어주는 것이다. (도대체 티켓속에 무엇이 있길래 패스워드 대신 사용이 가능할까 ? 이에 관한 내용은 뒤에서 자세히 설명한다)
③ 타운영체제 보안시스템과의 호환성
Kerberos는 ver. 5가 현재까지의 최신버전이며 많은 운영체제가 네트웍 보안에서의 산업표준으로 커버로스를 채택하고 있다. (윈도우 2000 운영체제도 Kerberos를 채택하였다.)
어디 운영체제뿐이겠는가. 혹시 솔라리스 8용 오라클 8i DB를 설치하였다면 설치하는 도중, 사용자가 DB 접속에 사용할 인증방식을 선택하는 메뉴를 본적이 있을것이다. 여기서 사용가능한 4가지 인증방식중 kerberos를 선택할 수 도 있다.
SEAM 역시 Kerberos V5를 이용하므로 여러 운영체제로 구성된 네트워크에서도 사용할 수가 있다. 게다가 SEAM은 같은 도메인내에서는 물론 서로 다른 도메인과 연결할 때에도 인증 및 보안서비스가 가능하다.
이미 Kerberos 버전 5를 이용하고 있다면 SEAM은 아주 쉽게 이해할 수 있을 것이다.
SEAM 인증체계하에서 사용자는 한 세션당 한번의 인증절차만을 거치면 된다. 이후에 일어나는 세션의 부수적인 처리과정에서는 인증이 자동으로 이루어진다. 일단 인증을 받았다면 password를 다시 입력해야할 일은 없는 셈이다.
SEAM을 사용하게되면 사용자는 철저한 보안환경속에서 다른 컴퓨터에 로그온하여 명령어 실행, 데이터 교환, 파일 송신을 할 수 있다. 또한, 인증서비스를 통하여 시스템 관리자가 사용자의 서비스와 시스템 사용에 적절한 제한을 할 수 있다.
나. SEAM에서 등장하는 용어
SEAM 및 Kerberos 보안 시스템에서는 새로운 용어들이 많이 등장한다. 이들을 한번 알아보기로 한다.
우선 지난강좌에서 언급한 비밀키와 공개키 방식을 다시 한번 살펴보자.
비밀키 암호시스템에서는 사용자가 100명이라면, 100개의 키를 분배해 놓아야 한다. 이러한 많은 키들을 관리하는 것은 쉽지도 않을뿐 아니라 키의 노출도 쉽게 이루어진다. 이를 해결하기 위해 공개키 암호시스템에서는 각 사용자가 자신의 개인키를 가진다. 보내는 메시지는 받는이의 공개키로 암호화시킨 후 전송을 하고, 받은 메시지는 자신의 개인키로 해독하여 읽으면 된다.
그러나 공개키 알고리즘은 일반적으로 비밀키 알고리즘에 비해 훨씬 느리다. 따라서 실제 사용에 있어서는 공개키와 비밀키를 적절히 혼합하여 사용한다.
보내는이는 자료의 암호화는 비밀키 암호알고리즘을 사용하여 하고, 이 비밀키는 다시 받는이의 공개키로 암호화 하여 암호문과, 암호화된 비밀키를 보낸다. 그러면 수신자는 자신의 개인키를 사용하여 비밀키를 해독하고, 해독된 비밀키를 사용하여 암호문을 다시 해독한다.
그러나 여기서도 어려움이 사라지지 않는다. 공개키 암호 시스템에서는 각 사용자가 다른사용자의 공개키들을 모두 관리해야 되는 것이다. 현실적으로 네트웍에 등록된 모든 사용자에 대한 키를 관리를 한다는 것이 결코 쉽지 않은 일이다. 이런 어려움을 타개하고자 등장한 것이 키 분배센터 (Key Distribution Center, KDC라고 흔히 사용함.)라는 서버이다.
키 분배센터(KDC)는 모든 사용자들의 키를 관리한다. 통신하려는 사용자들이 키를 요청하면 키분배 센터는 키를 암호화 하여 요청한 사용자들에게 나누어 주게 된다. 여기서 키 분배센터가 전체 보안체제에 얼마나 큰 영향을 미치는가를 알 수 있을 것이다.
2) 티켓
티켓이란 사용자가 서버나 서비스에 접속시 사용자 식별 및 인증을 위하여 사용되는 정보 패킷이다. SEAM 시스템은 티켓개념을 중심으로 운영된다. 티켓은 사용자뿐만 아니라 필요할 경우 NFS 와 같은 서비스도 식별해주는 정보의 집합체이다.
티켓에 대한 이해를 쉽게 하기 위하여 운전면허증을 예로 들어보자.
운전면허증에는 사용자의 성명, 주소, 운전할 수 있는 차종, 유효기간 (적성검사를 받아야할 시기)등이 명시되어 있다. 운전면허증은 이 자료를 근거로 운전자의 신원을 증명해주고 어떠한 차종을 운전할 수 있는가를 지정해준다.
티켓에는 서비스의 명칭과 사용자의 명칭, 사용자 호스트의 IP Address, 타임스탬프, 티켓의 유효기간을 명시한 값등이 들어있다. 티켓은 이 자료를 근거로 사용자의 신원을 증명해주고 및 사용자가 어떠한 네트웍 서비스를 사용할 권한이 있는가를 지정해준다.
티켓은 지정된 서버에 대하여 하나의 클라이언트와 하나의 지정된 서비스를 위하여 사용된다. 하나의 티켓으로 두개의 서비스 (예. ftp, telnet) 를 이용할 수 없다는 의미이다.
운전면허증은 유효기간이 있다. 기간이 만료되기전 적성검사를 다시 받아 면허증을 갱신해야 하지만 유효기간까지는 계속 사용할 수 있다. 티켓 역시 일단 만들어지면 유효기간이 만료될때까지 다시 사용할 수 있다.
티켓은 난수형태의 세션키에 의해 생성된다.
3) credential (서비스를 위한 자격)
credential은 위에서 설명한 티켓과 매칭 세션키가 함께 들어있는 정보패킷이다. credential은 개인키 혹은 서비스키에 의해 암호화된다. 암호화되는 방식은 이것이 어떻게 복호화될것인가에 따라 결정된다.
Client/Server 및 Service
클라이언트 : SEAM에서의 클라이언트는 사용자를 의미하는것이 아니다. 사용자가 워크스테이션에서 사용하는 프로그램 (소프트웨어)를 의미한다.
좀더 생각하면 이 의미를 알 수 있다. 비록 사용자가 서버에 접근하기 위하여 인증을 요청하지만 사용자가 서버에게 직접 인증을 해달라고 말하는것은 아닐 것이다. (서버가 사람의 말을 알아듣지 못하므로). 즉, 사용자는 자신의 프로그램을 실행시켜서, 그 실행된 프로그램을 통하여 서버에게 요청을 하게 된다. 이때 실행된 프로그램이 바로 클라이언트이다.
서버 : SEAM 소프트웨어가 작동되는 물리적인 시스템, 즉 컴퓨터.
서비스 : FTP나 NFS와 같은, 서버가 제공하는 특정한 소프트웨어 (기능).
4) 인증기(authenticator)
티켓을 이용할 때, 인증기는 사용자의 신원확인에 이용된다. 인증기 안에는 사용자 이름, 사용자 호스트의 IP Address, 타임스탬프등이 들어있다.
티켓과 다른점이 있다면 티켓은 다시 사용할 수 있지만 인증기는 서비스를 이용코자 요청을 할때 오직 한번밖에 사용될 수 없다는 것이다. 인증기는 클라이언트와 해당 서버에 대한 세션키를 이용하여 암호화된다.
5) Principal
SEAM에서의 클라이언트를 구분하는 방법은 해당 principal로 이루어진다. principal이란 KDC가 티켓을 발급해줄 대상을 식별하는 유일한 단서이며, principal은 사용자도 될 수 있고 서비스도 될 수 있다. principal 명칭은 primary, instance, realm등 3가지로 구성된다.
parkjh/admin@PRIME.DESKPIA.COM 라는 명칭을 살펴보자.
parkjh가 primary이며 이것처럼 사용자 이름을 쓰거나, NFS와 같은 서비스 명을 쓸 수도 있다. (서버 이름도 사용할 수 있다)
admin 은 instance이다. instance는 principal이 사용자일 경우, 옵션으로 지정할 수 있지만 서비스일 경우에는 반드시 지정되어야 한다.
parkjh라는 사용자가 시스템 관리자라면 그는 그의 평상시 사용자 증명을 parkjh/admin으로 할 수 있다. 만일 그가 두 개의 다른 호스트에 계정을 가지고 있다면 그는 다른 instance로 두 개의 principal 명칭을 사용할 수 있다. (예를 들면 parkjh/love.deskpia.com 과 parkjh/feel.deskpia.com) 단, SEAM 은 parkjh 와 parkjh/admin을 두 개의 서로 다른 principal로 다룬다.
서비스 principal에서는 instance로서 hostname을 사용하면 된다. mymachine.knight.deskpia.com 은 그러한 instance의 한 예이다. 그러므로 primary/instance는 nfs/mymachine.knight.deskpia.com 과같이 사용하면 된다.
다음은 principal 명칭의 예들이다.
sunny sunny/admin sunny/admin@FEEL.DESKPIA.COM nfs/host.feel.deskpia.com@FEEL.DESKPIA.COM
FEEL.DESKPIA.COM은 SEAM 영역의 한 예로 든것이다.
6) Realms (영역)
영역이란 하나의 마스터 KDC가 인증서비스를 실시해주는 네트웍상의 시스템 그룹을 지정한 것이다. 즉, SEAM의 인증이 이루어지는 총괄 서비스구역이다. 어떤 영역은 계층적 구조를 이루어 하나가 다른것의 상위에 위치하기도 한다.
Realms (영역) 과 서버
각 영역은 principal DB의 마스터 복사본을 유지, 보관하는 서버를 포함해야 한다. 이것을 마스터 KDC 서버라고 부른다. 또한, 각 realm은 최소한 하나의 slave KDC 서버를 포함해야 하며 이 서버에 principal DB의 제 2 복사본을 저장한다. 마스터 및 슬레이브 KDC 서버 모두 인증을 위한 티켓을 발급한다.
(만일 Slave KDC 서버가 없는 상태에서 마스터 KDC 서버의 DB에 장애가 발생한다면 해당 네트웍에서는 누구도 인증을 받을 수 없는 상황이 발생할 것이다. Slave KDC가 존재하는 이유이다.)
하나의 영역안에 두 개의 부가적인 SEAM 응용프로그램 서버도 위치할 수 있다. SEAM 네트웍 응용 프로그램 서버는 ftp, telnet, rsh와 같은 커버로스 인증을 이용할 수 있는 응용프로그램 사용을 제공한다. 커버로스 인증을 사용하는 NFS 서버도 영역안에 포함될 수 있다.
SEAM의 3가지 키
① 개인키
이것은 각 사용자에게 기본적으로 주어지며 오직 사용자와 키분배쎈터만이 그 암호를 알고 있다. 사용자에게 있어서 사용자 암호가 개인키의 암호가 된다.
② 서비스키
서버와 서비스에게 있어서 개인키가 서비스키로 인식된다. 이 서비스키는 개인키와 동일한 목적으로 사용되지만 개인이 아닌, 서버와 서비스가 이용한다는 차이가 있다.
③ 세션키
이 키는 인증서비스 혹은 티켓 발급 서비스에 의해 생성된다. 이 세션키는 클라이언트와 서버간의 보안작업을 위하여 만들어진다.
SEAM에서의 KDC 구성
위에서 언급하였듯, SEAM에서 각 영역은 최소한 2대의 KDC (마스터 KDC 한 대와 한 대 이상의 슬레이브 KDC) 로 구성된다.
SEAM에서의 KDC는 티켓과 매칭 세션키가 들어있는 credentials을 발급하는 책임을 맡는다. 이 credential은 KDC database안에 저장된 정보를 이용하여 생성된다.
키분배쎈터의 마스터키는 stash 파일속에 암호화되어 있다. 네트웍에서 서버가 KDC를 인증해야만 비로소 KDC가 역할을 할 수 있을 것이다. 이 마스터키는 서버가 리부팅된후 KDC를 자동으로 인증할 때 사용된다. 이 stash 파일안에는 마스터키가 들어있으므로 이 파일 및 백업본은 아주 안전하게 보관되어야 한다.
다. SEAM의 인증과정
SEAM에서는 어떻게 인증절차가 이루어질까 ?
사용자가 원격시스템에 로그온하여 응용프로그램을 사용하려면 자신의 신원을 확인시킬 수 있는 티켓과 매칭 세션키를 제공하여야 한다. 세션키는 사용자와 사용을 하려는 서비스가 지정된 정보를 담고 있다. 티켓과 세션키는 사용자가 처음 로그인할 때 KDC에 의해 생성된다. credential이란 이 티켓과 세션키를 담고 있는 것이다.
다중 네트웍 서비스를 이용하려면 사용자 역시 각 서비스에 필요한 다수의 credential을 가지고 있어야 한다. A라는 서버의 B라는 서비스는 거기에 필요한 특정 credential을 가진 사용자에게만 사용을 허가하기 때문이다.
예를 들어 emerald라는 서버에서 ftp 서비스를 이용하려면 여기에 맞는 credential을 가져야 하며 다른 서버의 ftp 서버스 역시 고유의 credential을 요구한다.
credential이 생성되고 저장되는 과정은 보이지 않게 이루어진다. KDC는 사용자의 요구가 있을 때 credential을 발급해주며 이것은 credential cache에 저장된다.
SEAM에서의 서비스 이용권한 획득
특정 서버의 특정서비스를 이용하기 위해서, 사용자가 얻어야 할 것이 두가지가 있다.
우선 사용자는 '티켓 발급 서비스(Ticket-granting Service)' 자체를 위한 credential을 얻어야 한다. 티켓발급서비스가 credential을 해독하고 난 이후, 서비스는 사용자가 접근하려는 서버의 두 번째 credential을 생성해준다. 서버의 서비스를 이용코자 하는 요청은 여기서 생성된 두번째 credential을 이용하는 것이다.
서버가 성공적으로 두 번째 credential을 해독한 이후에야 비로소 사용자는 해당 서버의 서비스 이용권한을 얻게 된다.
다음을 보면 인증과정이 좀더 쉽게 다가올것이다.
등장인물 client, KDC 인증서비스, KDC 티켓발급 서비스, Server 대본 1) client : KDC 인증서비스님, 인증서비스 티켓좀 주세요. 2) KDC 인증서비스 : 잠깐만요. 사용자가 맞나 확인좀 하고요. 아 맞네요. 티켓 여기 있습니다. 3) client : KDC 티켓발급 서비스님, 서버사용에 필요한 티켓이 필요한데요. 4) KDC 티켓발급 서비스 : 잠시만요. 자 여기 티켓입니다. 5) client : 서버님, 제가 사용해도 될까요 ? 6) Server : 세션키를 주세요. 7) client : 제 세션키 여기 있습니다. 8) Server : 예, 맞네요. 어서 들어오세요.
이 과정을 좀더 자세히 알아보자.
티켓발급 서비스를 위한 credential 얻기
인증과정을 시작하면서, 클라이언트는 특정 사용자의 principal을 보내줄 것을 인증서버에게 요청한다. 이 요청은 특별한 보안정보가 없으므로 암호화되지 않고 전송된다.
인증서비스가 이 요청을 접수하고 나면, 사용자의 principal 이름을 KDC 데이터베이스에서 찾는 과정이 수행된다.
principal이 일치하면 인증서비스는 KDC 데이타베이스에서 해당 principal에 대한 개인키를 획득할 수 있다.
인증서비스는 클라이언트가 이용할 세션키, 티켓 발급 서비스 (세션키 1이라 칭함), 티켓 발급서비스를 위한 티켓 (티켓1이라 칭함) 을 발급한다. 이 티켓을 티켓 발급을 위한 티켓 (ticket-granting-ticket, TGT) 이라고 한다.
세션키와 티켓은 에서 획득한 사용자의 개인키로 암호화된 후 클라이언트에게 되돌아간다.
클라이언트는 이 정보를 이용하여 세션키 1과 티켓 1을 복호화하고 개인키를 이용하여 사용자 principal을 복호화한다. 개인키는 오로지 사용자와 KDC 데이터베이스만이 알고 있다. 클라이언트는 이 정보를 credential cache에 저장한다.
보통 이 과정이 수행되는동안 사용자는 자신의 패스워드를 입력하는 작업만 하면 된다.
사용자가 입력한 패스워드가 KDC 데이터베이스에 저장된 개인키에 의해 생성되어 사용된 것과 동일하다면 클라이언트는 인증서비스가 보내준 정보를 성공리에 복호화할 수 있다.
이제 클라이언트는 티켓 발급 서비스와 사용될 credential을 갖게 된다. 클라이언트는 서버에게 credential을 요청할 준비를 마친것이다.
서버 접속을 위한 credential 요청하기
특정서버 접속 요청시, 클라이언트는 먼저 인증서비스로부터 해당서버의 credential을 얻어야 한다.
클라이언트는 그후 티켓발급서비스에게 서비스 principal 이름, 티켓 1, 세션키 1로 암호화된 인증기를 발급해달라는 요청을 하게된다. 티켓1은 원래 티켓발급서비스의 서비스키를 이용하여 인증서비스가 암호화 작업을 해놓은것이다.
티켓발급서비스의 서비스키는 티켓발급서비스 자신이 잘 알고 있으므로 티켓1은 금방 복호화시킬 수 있다. 이 정보에는 세션키와 티켓 1이 담겨있으므로 티켓 발급서비스는 인증기 역시 복호화시킨다. 이시점에서 사용자의 principal이 티켓발급서비스에 의해 인증된다.
인증이 성공적으로 이루어진 후, 티켓발급서비스는 사용자 principal과 서버 (세션키 2)를 위한 세션키 및 서버 (티켓2)를 위한 티켓을 생성한다. 세션키 2와 티켓2는 세션키 1로 암호화된다. 세션키1은 클라이언트와 티켓발급서비스만이 알고있으므로 네트웍상에서도 비밀이 보장된다.
클라이언트가 이 정보패킷을 접수한후, 이것은 credential cache에 저장된 세션키 1을 이용하여 복호화된다. 클라이언트는 서버에서 사용할 credential을 얻게된 것이다.
클라이언트는 서버의 특정서비스를 이용코자 하는 요청을 할 준비를 마치게 된다.
특정 서비스 사용권한 획득하기
특정서비스 이용을 요청하기 위하여, 클라이언트는 먼저 인증서버로부터 티켓 발급서비스 credential을 얻어야 하며 티켓발급서비스로부터 서버 credential을 얻어야 한다.
클라이언트는 서버에게 티켓2 및 다른 인증을 보내달라고 요청한다. 인증기는 세션키 2에 의해 암호화되어있다.
티켓2는 서비스를 위한 서비스키로 티켓발급서비스에 의해 암호화되어있다. 서비스키는 서비스 principal 이 잘 알고 있으므로 서비스는 티켓2를 복호화하여 세션키 2를 얻을 수 있다. 세션키 2는 인증기 복호화에 사용된다.
인증기가 성공리에 복호화되면 클라이언트는 서비스 이용권한을 갖게 된다.
라. SEAM 구성요소와 파일, 명령어
1) SEAM 구성요소
SEAM 1.0에는 아래와 같은 프로그램이 들어있다.
Solaris 7에는 위의 프로그램이 모두 들어있다. SEAM 클라이언트 기능을 사용하려면 KDC가 운영중인 환경하에서만 가능하다. 티켓을 분배하는 KDC, 즉 제 3의 인증서버 없이 SEAM은 이루어질 수 없으므로...
그러나 Solaris 8에는 SEAM의 클라이언트쪽 소프트웨어만이 제공된다. 고로 상기 프로그램중 KDC를 비롯한 많은 부분이 빠져있다. 솔라리스 8 사용자 입장에서는 섭섭할 수 있다. 왜 KDC를 주지 않을까 ?
지금 이 글을 읽고 계시는 분들중 많은 분들은 자신의 PC 1대에 솔라리스8 인텔버전을 설치하여 사용하고 계실 것이다. 이것만으로는 SEAM에서 요구하는 영역(realm)을 구성할 수 없다. 최소 KDC 2대가 별도로 필요하기 때문이다.
그러나 솔라리스 8이 설치된 PC가 네트웍에 참여하고 있고, 그 네트웍에서 이미 커버로스 5를 운영중이라면 솔라리스 8이 설치된 PC는 SEAM Client 시스템으로 금방 사용할 수 있다. SEAM은 커버로스5의 일원이므로 다른 운영체제의 커버로스 5와도 호환이 된다고 앞장에서 설명한 바 있다.
만일 자신이 몇대의 PC나 워크스테이션을 가지고 있다면, 그리고 네트웍의 일원으로서 DNS에서 자신의 시스템이 도메인명을 받을 수 있다면 직접 SEAM 영역을 구성해볼 수 있다. 이때 KDC 서버는 솔라리스 7 운영체제가 설치된 컴퓨터를 이용하고, 솔라리스 8이 설치된 컴퓨터는 SEAM 인증방식을 사용하는 클라이언트로 사용하면 될 것이다. 이러한 분들을 위하여 KDC를 설정하는 방법을 본단원의 12, 13페이지에 각각 기술해 놓았다.
솔라리스8에 포함된 클라이언트 소프트웨어는 다음과 같다.
Solaris 8 에서 사용할 수 있는 SEAM Client 파일 및 명령어, DAEMON은 다음과 같다. 이들에 대한 자세한 내용은 다음부분에 설명해 놓았다.
SEAM 관련 파일
SEAM 명령어
SEAM Daemon
마. SEAM Client 구성 및 로그인과정
여러분이 솔라리스 8을 사용하고 있다면 , SEAM 서비스가 필요할 경우에는 얼마든지 SEAM client로 시스템을 설정할 수 있다. 이때 필요한 프로그램을 설치하는 과정 및 실제로 SEAM이 설치된 시스템에 로그인 하는 과정을 알아본다.
1) SEAM Client 구성방법
아래는 SEAM client 구성의 한 예이다.
deskpia.com이라는 도메인을 예로 들어본다.
realm name = DESKPIA.COM DNS domain name = deskpia.com master KDC = kdc1.deskpia.com slave KDC = kdc2.deskpia.com client = client.deskpia.com admin principal = sunny/admin user principal = mre
2) SEAM client 설치시 사전 준비사항.
솔라리스가 설치된 여러분의 컴퓨터가 KDC가 작동중인 영역안에 있어야 한다. 또한 DNS 서비스를 통하여 여러분의 컴퓨터 이름 (ip address가 아님) 을 도메인에서 사용할 수 있어야 한다.
자신의 컴퓨터의 superuser 권한을 획득한다. 다음으로 해야할 과정은 그간 #을 붙여놓아 서비스를 막아놓았던 커버로스 관련 서비스의 #을 찾아다니며 제거해주는 일이다.
PAM configuration file (pam.conf)을 연다.
Kerberos PAM module 구동을 위하여 아래 여덟개 줄에 붙어있던 #을 제거한다.
client1 # tail -11 /etc/pam.conf # # Support for Kerberos V5 authentication (uncomment to use Kerberos) # rlogin auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass login auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass dtlogin auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass other auth optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass dtlogin account optional /usr/lib/security/$ISA/pam_krb5.so.1 other account optional /usr/lib/security/$ISA/pam_krb5.so.1 other session optional /usr/lib/security/$ISA/pam_krb5.so.1 other password optional /usr/lib/security/$ISA/pam_krb5.so.1 try_first_pass
NFS 보안서비스 설정파일을 편집기로 연다. (nfssec.conf).
커버로스 서비스를 설명한 라인의 #을 제거한다.
client1 # cat /etc/nfssec.conf . . # # Uncomment the following lines to use Kerberos V5 with NFS # krb5 390003 kerberos_v5 default - # RPCSEC_GSS krb5i 390004 kerberos_v5 default integrity # RPCSEC_GSS default 1 - - - # default is AUTH_SYS
커버로스 구성파일 (krb5.conf)을 편집기로 연다.
영역 (realm) 명칭과 서버의 명칭을 알맞게 변경해준다.
deskpia.com이라는 도메인을 예로 들어본다.
client1 # cat /etc/krb5/krb5.conf [libdefaults] default_realm = DESKPIA.COM [realms] DESKPIA.COM = { kdc = kdc1.deskpia.com kdc = kdc2.deskpia.com admin_server = kdc1.deskpia.com } [domain_realm] .deskpia.com = DESKPIA.COM
NTP나 다른 시각 동기화 메카니즘을 이용하여 마스터 KDC와 자신의 컴퓨터와의 시간을 맞춰준다. (시간맞추기. 간단한 방법이지만 이것은 SEAM인증의 핵심이다. 다른 서버와 서로 시간을 맞추는 방법은 다음장에서 설명한다)
3) SEAM 인증시스템의 로그인절차
사실 사용자입장에서 볼 때, SEAM은 SEAM 세션이 시작되었어도 정말 시작이 되었는지조차 알 수 없을 것이다. SEAM 세션이 시작되면 로그인 후 커버로스 암호를 입력하는 것 이외에는 별반 특별한 것이 없기 때문이다.
kinit 라는 명령어를 수행시키면 사용자가 자신을 인증할 수 있는 티켓을 키분배쎈터 (KDC)에 요청하는 과정도 포함된다. 키분배쎈터(KDC)는 티켓을 발급해주면서 사용자가 다른 컴퓨터에 접속할 수 있는 권한을 부여한다. 즉, 사용자가 티켓을 요청하는 것은 kinit 명령어의 일부분으로 자동 수행되는 셈이다. 오직 인증을 받은 클라이언트만이 특정서버에 대한 티켓을 얻을 수 있으며 그렇지 못한 클라이언트는 knit 명령어를 사용할 수 없다.
다음은 커버로스 환경에서 로그인하는 과정의 한 예이다. 로그인시에는 kinit -l 사용자이름 순으로 명령어를 입력한다.
omega% kinit -l username
kinit 명령어는 사용자에게 티켓 사용기간 (-l 옵션)과 패스워드를 물어오게 된다.
omega% kinit -l sunny SunOS (omega) Kerberos Initialization for "sunny" Kerberos ticket lifetime (minutes): 360 Password: omega%
Kerberos Ticket 목록을 출력하려면 klist 명령어를 사용한다.
omega% klist Ticket file: /tmp/tkt8516 Principal: sunny@feel.Deskpia.COM Issued Expires Principal May 24 20:40:54 May 25:04:40:54 krbtgt.feel.Deskpia.COM@feel.Deskpia.COM
kinit나 klist와같은 커버로스 명령어를 사용하려면 SEAM Client가 시스템에 구성되어 있어야 한다. 그렇지 않으면 etc/krb5.conf 파일이 아직 구성되지 않았다는 에러메시지만을 보게 된다.
바. SEAM principal 설정
아쉽게도 principal을 설정, 운영할 수 있는 도구는 솔라리스 8에 포함된 SEAM Client에서는 제공하지 않는다. 그러나 솔라리스 7에서는 기본적으로 제공이 되므로 이것을 사용할 수 있다.
principal 구성을 위해서는 솔라리스 7에 포함된 SEAM TOOL을 이용하도록 하자.
사용할 수 있는 프로그램은 /usr/krb5/sbin 디렉토리안에 있으며 두가지가 있다. 하나는 GUI 방식의 관리도구로서 gkadmin이라는 명령어를 수행하면 된다. 또하나는 명령어 입력방식으로서 kadmin이라는 파일이다.
principal을 추가, 열람하는 방법은 위에서 언급한 gkadmin을 이용, SEAM TOOL을 이용하는 방법과 명령어를 직접 입력하는 방법이 있다.
SEAM TOOL을 작동시키려면 gkadmin 명령어를 입력하면 된다.
$ /usr/krb5/sbin/gkadmin
화면에 로그인 윈도우가 나타날 것이다. 만일 기본으로 지정된 값을 바꾸고 싶으면 새로운 값을 입력하면 된다. 로그인 윈도우는 자동적으로 기본값이 들어있는 상태로 나타난다. 화면에 나타난 기본 principal 이름은 사용자 환경에서 사용자의 현재 신분을 식별할 수 있는 정보들을 가지고 만들어진 것이다. 또한 기본 영역 및 마스터 KDC 필드는 /etc/krb5/krb5.conf 파일에서 끌어온 것이다.
기본설정값으로 되돌리고 싶으면 Start Over 버튼을 누르면 된다. 지정된 principal 이름의 패스워드를 입력한후 ok 버튼을 누른다. principal list가 나열된 윈도우가 나타날 것이다.
명령어 이용방법
아래 예는 park이라는 새로운 principal을 kadmin 명령어로 생성한 예이다. principal의 정책은 testuser로 설정하였다.
kadmin: add_principal -policy testuser park Enter password for principal "pak@DESKPIA.COM": Re-enter password for principal "pak@DESKPIA.COM": Principal "park@DESKPIA.COM" created. kadmin: quit
아래 예는 kadmin 의 list_principal 명령어를 이용하여 test* 라는 와일드카드와 부합되는 모든 principal의 리스트를 화면에 나타내는 방법이다. kadmin: list_principals test* test1@DESKPIA.COM test2@DESKPIA.COM kadmin: quit
다음은 get_principal 명령어로서 park/admin principal의 속성을 조회하는 예이다.
kadmin: getprinc park/admin Principal: park/admin@DESKPIA.COM Expiration date: Fri Aug 25 17:19:05 PDT 2000 Last password change: [never] Password expiration date: Wed Apr 14 11:53:10 PDT 1999 Maximum ticket life: 1 day 16:00:00 Maximum renewable life: 1 day 16:00:00 Last modified: Thu Jan 14 11:54:09 PST 1999 (admin/admin@DESKPIA.COM) Last successful authentication: [never] Last failed authentication: [never] Failed password attempts: 0 Number of keys: 1 Key: vno 1, DES cbc mode with CRC-32, no salt Attributes: REQUIRES_HW_AUTH Policy: [none] kadmin: quit
change_password 명령어를 이용하여 sunny 라는 principal의 패스워드를 변경하는 방법은 다음과 같다.
kadmin: change_password sunny Enter password for principal "sunny": Re-enter password for principal "sunny": Password for "sunny@DESKPIA.COM" changed. kadmin: quit
delete_principal 명령어를 이용, sunny라는 principal을 삭제하는 예이다.
kadmin: delete_principal sunny Are you sure you want to delete the principal "sunny@DESKPIA.COM"? (yes/no): yes Principal "sunny@DESKPIA.COM" deleted. Make sure that you have removed this principal from all ACLs before reusing. kadmin: quit
NFS service principal을 생성한다.
nfs/client1.deskpia.com 라는 이름의 principal 생성
root/client1.deskpia.com라는 이름의 principal 생성
host/client1.deskpia.com라는 이름의 principal 생성.
root/client1.deskpia.com principal 은 keytab file안에 포함됨.
사. SEAM NFS 서버 설정
NFS 서비스는 UNIX UID를 이용하여 사용자를 식별하지 사용자의 principal을 직접 이용하지는 않는다. principal을 UID로 변환,해석할 때 사용자의 principal을 UNIX UID로 나타내주는 credential table을 생성해야 한다. 이 과정은 SEAM NFS 서버를 설정해주는데 꼭 필요하다.
아래 설정사항을 적용하여 사용해보자.
realm name = DESKPIA.COM DNS domain name = deskpia.com NFS server = mynfs.acme.com admin principle = skn/admin
우선 솔라리스 7에 포함된 KDC와 함께 제공된 SEAM TOOL을 이용하여 NFS 서버의 새로운 principal을 추가한다.
서버의 NFS service principal을 생성한다.
nfs/mynfs.deskpia.com 이라는 이름의 principal 생성
root principal 생성
root/mynfs.deskpia.com이라는 이름의 principal 생성
서버의 NFS 서버스 principal을 서버의 keytab파일 안에 추가.
nfs/mynfs.deskpia.com principal 은 keytab file안에 포함되어 있음.
gsscred 명령어를 이용하여 credential table 생성. (아래에 생성하는 방법을 설명해놓음)
커버로스 보안모드를 사용하여 NFS file system 공유
각 클라이언트에서 사용자와 루트의 principal을 인증
gsscred 테이블의 백엔드 메카니즘 변경방법
NFS server의 수퍼유저권한을 획득한다.
/etc/gss/gsscred.conf을 열어서 메카니즘을 수정한다.
다음 back-end mechanisms 중 하나를 사용할 수 있다.
files, xfn_files, xfn_nis, xfn_nisplus, xfn.
Credential Table 생성방법
gsscred credential table은 NFS 서버가 SEAM principal을 UID로 매핑하는데 사용된다. NFS 클라이언트가 커버로스 인증을 이용하여 NFS 서버로부터 파일 시스템을 마운트하기 위해서는 이 테이블이 반드시 생성되어 있거나 사용할 수 있어야 한다.
서버의 수퍼유저 권한을 획득한다.
이 명령어를 수행할 서버 및 명령을 실행할 사용자의 ID는 gsscred 테이블을 지원해주기 위하여 선택한 백엔드 메카니즘에 따라 달라진다. xfn_nisplus를 제외한 모든 메카니즘은 루트만이 사용할 수 있다.
Back-end Mechanism과 그에 따른 결과 files : NFS server상에서 실행. xfn : 기본 xfn file 세팅값에 근거한 호스트 선택 xfn_files : NFS server상에서 실행. xfn_nis : NIS 마스터상에서 실행. xfn_nisplus : NIS+ 데이터를 변경시킬 수 있는 권한이 있는한 어디서나 실행
만일 /var/fn이 존재하지 않지만 xfn 옵션중 하나를 사용하고자 할 때에는 기본 XFN 데이터베이스를 생성해야 한다.
# fnselect files # fncreate -t org -o org//
gsscred를 이용하여 credential table을 생성하는 방법
이 명령어는 /etc/nsswitch.conf 파일안에 있는 패스워드 엔트리와 함께 모든 소스로부터 정보를 수집한다. 만일 credeintial 테이블에 로칼 패스워드 엔트리를 포함시키고 싶지 않다면 file 엔트리를 임시로 삭제해놓아야 한다.
# gsscred -m kerberos_v5 -a
Credential Table에 단일 엔트리 추가하기
이과정에 앞서서 NFS 서버에 gsscred 테이블이 이미 설치되어 있어야 한다.
NFS server의 수퍼유저 권한을 취득. gsscred 명령어로 테이블에 엔트리 추가 # gsscred -m [mech] -n [name] -u [uid] -a mech : 사용될 보안 메카니즘 name : KDC에서 정의된 사용자의 principal 이름 uid : 패스워드 데이터베이스에 명시된 사용자의 UID -a : principal 이름 매핑에 UID를 추가
단일 엔트리를 크리덴셜 테이블로 변경한 사례
UID 3736으로 매핑된 샌디라는 이름의 사용자를 위하여 엔트리를 추가한 예이다. 명령줄에 포함되어 있지 않을 경우, UID는 패스워드 파일로부터 가져오게 된다.
# gsscred -m kerberos_v5 -n sandy -u 3736 -a
아. 커버로스를 이용한 NFS 보안설정
다중 커버로스 보안모드를 이용한 NFS 보안환경 설정방법
커버로스는 NFS 시스템의 보안환경 설정시 여러가지 보안모드를 동시에 지정할 수도 있고 하나만을 선택하여 사용할 수도 있다. 설정방법은 다음과 같다.
NFS server의 수퍼유저 권한 획득.
서버의 /etc/dfs/dfstab 파일을 열어서 적절한 보안mode를 추가해준다.
# share -F nfs -o sec=mode 공유파일경로 mode : 공유시 사용되는 보안모드. NFS에서 사용되는 share 명령어는 SEAM과 만나면서 더욱 강력한 보안체계을 갖추게 된다. SEAM은 share 명령어에 다음과 같이 3가지 보안모드를 적용하여 쓸 수 있게 해준다.
보안모드가 여러개로 설정되어 있을 때에는 관리자가 특정 보안모드를 선택하지 않는 이상 첫번째로 설정된 모드가 사용된다.
이렇게 설정되면 NFS 공유파일에 접근하기 위하여 모든 클라이언트는 커버로스 인증을 받게 된다.
NFS 서비스가 서버에서 작동중인가를 확인해야 한다.
만일 이것이 사용자가 처음 사용한 공유명령어라면 NFS 대몬은 작동하지 않고 있다는 의미가 된다. 아래 명령어를 이용하여 대몬을 없앤후 다시 restart시키자.
# /etc/init.d/nfs.server stop # /etc/init.d/nfs.server start
단일 커버로스 보안모드로 파일 시스템을 공유한 예
아래는 krb5 가 /export/home 공유파일 사용을 위한 단일 커버로스 보안모드로 선택된 예이다.
# share -F nfs -o sec=krb5 /export/home
다중 커버로스 보안모드로 파일 시스템을 공유한 예
아래 예는 3개의 커버로스 보안모드가 모두 적용된 것이다. 마운트 요청이 들어왔을 때 보안모드가 지정되지 않으면 나열된 것중 첫 번째 보안모드(아래 예에서는 krb5)를 모든 NFS 클라이언트가 사용한다.
# share -F nfs -o sec=krb5:krb5i:krb5p /export/home
자. KDC와 SEAM Client간의 시간 맞추기
솔라리스는 서버와 클라이언트간 시간을 똑같이 설정해놓음으로서 이것을 기본으로 서로를 인증하는 수단을 제공한다고 수차례 언급하였다. 다음은 인증의 가장 중요한 수단인 시각 동기화, 즉 시스템간의 시간을 똑같이 맞추는 방법이다.
KDC와 SEAM 클라이언트간 시간을 똑같이 맞추는데 사용되는 도구로서는 네트웍 타임 프로토콜 (NTP)이 가장 적합하다고 한다. 솔라리스는 2.6 버전부터 델라웨어대학에서 나온 NTP 도메인 소프트웨어를 내장하고 있다.
NTP를 사용하게 되면 사용자는 네트웍상에 있는 시스템들의 정확한 시간조정을 할 수 있다. NTP는 기본적으로 클라이언트/서버 방식이다. 사용자는 하나의 시스템을 마스터 클럭 (NTP 서버)로 지정한후 다른 모든 시스템의 시간을 마스터 클럭의 시간과 동일하게 맞추면 된다. 이 작업은 xntpd 라는 대몬을 통해 이루어진다. 이 대몬은 유닉스 시스템 표준시간을 관리, 조정해주는 역할을 한다.
KDC와 SEAM 클라이언트가 시각을 맞추는 작업은 다음과 같다.
먼저 NTP server를 지정한다. (영역내에서 마스터 KDC를 제외한 아무 서버나 NTP 서버로 지정할 수 있다) 그후 NTP 서버에서 다음 작업을 진행한다.
서버의 수퍼 유저 권한을 갖는다.
/etc/inet directory로 간다.
ntp.server라는 file을 ntp.conf라는 file로 복사한다.
# cp ntp.server ntp.conf
/etc/init.d directory로 간다.
xntpd daemon을 구동시킨다.
# ./xntpd start
NTP Client 시각 설정
네트웍상에서 KDC와 SEAM 클라이언트를 설정한것처럼 NTP서버의 NTP 클라이언트도 다음과 같이 설정하면 된다.
수퍼유저 권한을 갖는다. /etc/inet directory로 간다. ntp.client file을 ntp.conf file로 복사한다. # cp ntp.client ntp.conf /etc/init.d directory로 간다. xntpd daemon을 구동시킨다. ./xntpd start
다른시스템과 일자 및 시간 맞추기
수퍼유저 권한을 갖는다. rdate 명령어를 사용하여 다른 시스템과 일자 및 시간을 동기화시킨다. # rdate 다른시스템 이름 예제 : deskpia라는 시스템과 omega라는 시스템의 시각 동기화 예제 deskpia# date Thu Sep 16 11:08:27 MDT 1999 deskpiah# rdate omega Thu Sep 16 14:06:37 1999 deskpia# date Thu Sep 16 14:06:40 MDT 1999
수동으로 시스템 시각 조절하기
아래예는 시스템의 시간을 조절하는 예이다. 대부분의 유닉스시스템과 동일할 것이다.
수퍼유저 권한을 갖는다. 새로운 일자 및 시각을 입력한다. # date mmddHHMM[cc]yy 순서: 월, 일, 시간, 분, [세기], 연도 예제 ] # date Thu Sep 16 14:00:00 MDT 1999 # date 0916141099 Thu Sep 16 14:10:00 MDT 1999
차. Ticket 관리
1) 티켓 생성법
티켓은 보통 사용자가 로그인할 때 자동으로 만들어지므로 특별히 이를 만들기 위한 작업은 필요치 않다.
그러나 티켓유효기간이 만료되었을 때, 혹은 사용자의 principal이 아닌 다른이의 principal을 사용해야 할 때에는 직접 새로 만들어서 사용해야 한다.
티켓을 만들때에는 다음과 같이 kinit 명령어를 사용한다.
% /usr/bin/kinit
이후 해당 패스워드를 입력해주면 된다.
2) 티켓 만들기 실제사례
sunny라는 사용자가 자신의 시스템에 티켓을 생성하는 예이다. % kinit Password for sunny@ALPHA.DESKPIA.COM: <패스워드 입력>
아래는 sunny라는 사용자가 -l 옵션을 이용하여 3시간동안만 사용할 티켓을 만드는 예이다.
% kinit -l 3h sunny@DESKPIA.COM Password for sunny@DESKPIA.COM:
다음 예는 sunny가 새로운 인증절차 없이 다른 컴퓨터에서도 본인이 사용할 수 있는, 즉 전송가능(forwardable)한 티켓을 -f 옵션을 써서 만드는 과정이다. 이 전송가능한 티켓으로 사용자는 두번째 시스템에 로그인을 할 수도 있고 3번째 시스템에서 ftp를 이용할 수도 있다.
% kinit -f sunny@DESKPIA.COM Password for sunny@DESKPIA.COM:
3) 티켓속성 확인하기
모든 티켓이 동일하지 않다. 어떤 티켓이 전송가능한것이라면 다른 것은 날짜를 연기할 수도 있으며 또 어떤티켓은 두가지 모두의 속성을 가질 수 있다. klist 명령어에 -f 옵션을 사용하면 사용자가 가진 티켓이 어떤 속성을 가지고 있는지를 확인해볼 수 있다.
% /usr/bin/klist -f 아래 기호는 klist 명령어로 티켓을 열람할 때 각 티켓에 부여된 속성을 나타내는 것이다. F : Forwardable f : Forwarded P : Proxiable p : Proxy D : Postdateable d : Postdated R : Renewable I : Initial i : Invalid
티켓이 가진 여러 속성을 표현한 티켓의 종류
soonja라는 사용자가 전송가능하고(F) 날짜를 늦출 수 있지만(d) 아직 유효하지 않은(i) 기본 티켓을 가진예이다.
% /usr/bin/klist -f Ticket cache: /tmp/krb5cc_74287 Default principal: soonja@ALPHA.DESKPIA.COM Valid starting Expires Service principal 12 May 99 16:20:43 12 May 99 18:20:43 nfs/ALPHA.DESKPIA.COM@ALPHA.DESKPIA.COM renew until 13 Mar 99 16:43:11, Flags: Fdi
아래는 정희(junghee)라는 사용자가 다른 호스트에서 그녀의 호스트로 전송된(f) 2장의 티켓을 확인하는 과정이다. 이 티켓들은 (재)전송이 가능한(F) 것들이다.
% klist -f Ticket cache: /tmp/krb5cc_74287 Default principal: junghee@ALPHA.DESKPIA.COM Valid starting Expires Service principal 08 May 99 09:23:50 10 May 99 22:13:31 host/DESKPIA.COM@DESKPIA.COM renew until 11 May 99 17:09:51, Flags: fF Valid starting Expires Service principal 09 May 99 09:19:53 10 May 99 11:43:53 nfs/DESKPIA.COM@DESKPIA.COM renew until 11 May 99 19:35:23, Flags: fF
4) 작업후 확실히 티켓 삭제하기
일반적으로 티켓은 커버로스 명령어 수행이 종료되면서 자동으로 삭제된다. 그러나 이험한 세상에 누구를 믿겠는가 ? 대부분의 사용자들은 커버로스 티켓이 확실히 삭제되었음을 확인하고 싶어한다. 만일 아직 시스템에서 삭제되지 않은 티켓을 누군가가 슬쩍하여 티켓 유효기간이 만료될 때까지 자신의 것인양 사용하고 다닌다면 .... 생각만 해도 아찔하기 때문이다.
확실히 티켓을 삭제할때에는 kdestroy 명령어를 사용하면 된다.
% /usr/bin/kdestroy
작업을 마치면서 티켓을 항상 확실히 삭제하려면 ?
자신의 홈디렉토리 내에 .logout 파일이 있을 것이다. 여기에 kdestory 명령어를 추가시키면 티켓도난 걱정은 끝이다. 시스템 사용을 마치면 자동으로 kdestroy가 수행되므로.
카. 패스워드 관리
SEAM 설치와 함께, 사용자는 두개의 패스워드를 받게 된다. 하나는 솔라리스 일반 패스워드이고 또하나는 커버로스 패스워드이다. 이 둘은 동일하게 설정할 수도 있고 다르게 설정할 수도 있다.
비 커버로스 환경 명령어는, 로그인등에서 인증을 할때, 커버로스와 유닉스 모두 PAM을 통해서 수행을 한다. 만일 다른 패스워드를 사용할 경우, 로그온시 필요한 인증과정은 두개의 패스워드를 모두 요구할 것이다. 그러나 두개의 패스워드가 동일할 경우, 유닉스 로그인시 사용한 첫번째 패스워드가 커버로스에도 그대로 사용된다.
물론 동일한 패스워드는 사용하기에는 편리할 지 모르지만 보안상은 그리 권장할만한 사항이 아니다. 만일 누군가가 사용자의 패스워드를 알게 된다면, 그날부터 사용자의 유닉스 패스워드는 만인의 것이 될 수 있기 때문이다.
그러나, 커버로스를 사용하지 않는것에 비한다면 커버로스의 동일한 암호체계가 훨씬 안전하다고 볼수 있다. 일단 커버로스환경에서의 패스워드는 네트웍을 통해서 전송되는 것이 아니기 때문이다. (대부분의 사이트는 패스워드 설정등에 관한 규정을 정해놓은 자체 보안정책을 가지고 있을 것이다. )
커버로스 패스워드는 커버로스가 사용자의 신원을 확인하는 유일한 수단이다. 만일 해커가 커버로스 패스워드를 알아낸다면 커버로스 보안은 무의미해지게 된다. 해커는 사용자로 위장하여 사용자가 보낸것으로 위장한 e-mail을 보낼 수 있고, 사용자의 파일을 열어보고 편집, 삭제할 수도 있다. 또한 사용자로 위장하여 다른 호스트에 접속할 수도 있지만 누구도 이를 눈치채지 못한다.
사용자의 패스워드는 시스템 관리자에게조차 누설되어서는 안된다. 또한, 사용자의 패스워드는 수시로, 혹은 패스워드가 누설되었다고 판단되었을 경우, 즉시 바꿔주어야 한다.
패스워드 변경시 참조사항
사용자의 패스워드는 컨트롤키와 리턴키를 제외한 어떠한 글자도 포함시킬 수 있다. 좋은 패스워드란 사용자는 쉽게 기억할 수 있지만 다른이는 추측조차 할 수 없는 것이다.
좋지못한 패스워드는 다음과 같다.
좋은 패스워드는 최소 8자의 길이를 가져야 한다. 또한 대문자와 소문자, 숫자와 특수부호등을 포함해야 한다. 좋은 패스워드의 예는 다음과 같다.
주의 : 위에 명시된 패스워드를 절대 그대로 사용하지 말기 바람.
패스워드 바꾸기
커버로스 패스워드를 바꾸는 명령어는 passwd와 kpasswd 두가지가 있다.
passwd는 일반 유닉스 명령어다. SEAM을 설치하고 나면, 솔라리스의 passwd 명령어는 자동적으로 새로운 커버로스 암호를 물어올 것이다.
passwd 명령어가 kpasswd 명령어보다 좋은점은 유닉스와 커버로스 패스워드를 동시에 설정할 수 있다는 점이다. 그러나 passwd 명령어를 이용하여 두개의 패스워드를 동시에 바꾸지는 말자. 유닉스 패스워드만 변경하고 커버로스 패스워드는 그대로 둘 수 있다.
kpasswd 명령어는 passwd 명령어와 매우 유사하다. 차이점이라면 kpasswd는 단지 커버로스 암호만을 바꿀 수 있다는 점이다. 유닉스 패스워드를 바꾸려면 반드시 passwd 명령어를 써야한다.
또하나의 차이점은 kpasswd 명령어는 유닉스 사용자들에게는 유효하지 않은 커버로스 principal의 암호를 변경할 수 있다는 것이다. 예를 들어, david/admin은 커버로스 principal이지만 실제 유닉스 사용자는 아니다. 고로 이것을 변경하려면 passwd가 아닌 kpasswd 명령어가 필요하다.
패스워드를 바꾼후 변경한 패스워드가 적용되기 까지는 시스템 설정상태에 따라 수분에서 수시간이 걸릴 수도 있다. 만일 패스워드를 변경한 후 급히 커버로스 티켓발급이 필요할 때에는 우선 변경한 패스워드를 입력해본후, 적용이 되지 않았다면 변경전 패스워드를 사용하면 된다.
Kerberos V5는 시스템 관리자가 각 사용자의 패스워드를 구성하는 방법을 지정해놓을 수 있다. 예를 들어, 패스워드는 최소한 8자의 길이를 가지며 반드시 2개이상의 숫자가 들어있어야 한다고 지정해 놓으면, 사용자들은 숫자가 들어있지 않은 패스워드를 생성할 수 없다.
아래는 kpasswd를 사용하여 패스워드를 변경하는 예이다.
% kpasswd kpasswd: Changing password for junghee@FEEL.DESKPIA.COM. Old password: kpasswd: junghee@FEEL.DESKPIA.COM's password is controlled by the policy admin which requires a minimum of 8 characters from at least 2 classes (the five classes are lowercase, uppercase, numbers, punctuation, and all other characters). New password: <만일 junghee라는 사용자가 'there'이라고 입력했다면> New password (again): <다시 'there'이라고 입력> kpasswd: New password is too short.
위와 같이 패스워드 범주를 지정해놓으면 그 범주를 벗어난 패스워드는 생성되지 않는다.
아래 예는 kingman라는 사용자가 passwd 명령어를 이용하여 자신의 UNIX 및 커버로스 패스워드를 동시에 바꾼 예이다.
% passwd passwd: Changing password for soonja Enter login (NIS+) password: <기존의 유닉스 패스워드 입력> New password: <새로운 유닉스 패스워드 입력> Re-enter password: <새로운 유닉스 패스워드를 한번 더 입력> Old KRB5 password: <기존의 Kerberos password 입력> New KRB5 password: <새로운 Kerberos password 입력> Re-enter new KRB5 password: <새로운 Kerberos password 재입력 >
위 예에서 나타나듯 커버로스 보안시스템안에서 passwd 명령어는 유닉스 및 커버로스 패스워드를 함께 물어온다. (만일 try_first_pass 항목이 PAM module에 설정되어 있다면 Kerberos password는 자동적으로 UNIX password와 동일하게 설정된다)
타. Master KDC Server 구성
SEAM에서 KDC는 가장 중요한 위치에 있다해도 과언이 아니다. 커버로스의 핵심이 바로 제 3의 인증서버이며 이것이 KDC의 역할이기 때문이다. 이것이 구성된 이후에야 비로소 SEAM 클라이언트 프로그램을 비롯한 SEAM 구성요소가 동작할 수 있다.
솔라리스 8에서는 제공되지 않는 기능이지만 여러대의 서버를 사용하여 SEAM을 구성코자 하는 분들을 위하여 KDC 서버 구성방법을 마지막으로 기술하고자 한다. 이미 언급한 바와 같이 KDC 서버 구성을 위하여는 솔라리스 7이 필요하다.
KDC는 1대의 마스터 서버와 1대이상의 슬레이브 서버로 구성하여야 한다. 마스터와 슬레이브의 차이는 무엇일까 ? 마스터가 할 수 있는 데이터베이스 관리작업을 슬레이브는 할 수 없다는 점이다.
예를 들어, 패스워드를 변경한다거나 새로운 principal을 추가하는 일은 마스터에서만 할 수 있다. 이후 작업이 끝난후에야 변경사항들이 슬레이브로 옮겨진다. 그러면 마스터와 슬레이브는 모두 동일한 DB파일을 가지고 있는 셈이 될 것이다.
credential을 발급하는 일은 마스터와 슬레이브 모두 할 수 있다. 설사 마스터에 변고가 발생하였다 할지라도 슬레이브가 계속 credential을 발급할 수 있으므로 더 이상의 비극을 막을 수 있는 것이다.
Master KDC 구성
KDC 구성에 대한 전반적인 예를 들어보기로 하자. 사용자가 KDC 설치를 위한 아무런 사전구성도 하지 않았다는 가정하에서 시작한다.
아래와 같이 환경설정을 해놓았다고 가정한다.
realm name = DESKPIA.COM DNS domain name = deskpia.com master KDC = kdc1.deskpia.com slave KDC = kdc2.deskpia.com admin principle = sunny/admin online help URL = http://www.solarisschool.com
마스터 KDC 구성을 위한 사전 준비사항
우선 KDC 소프트웨어가 시스템에 설치되어 있어야 한다. (당연한 이야기겠지만). 그리고 DNS가 운영중인 네트웍이어야 한다. (마스터와 슬레이브의 호스트네임을 지정해주어야 하므로) 또한 마스터에 변고가 발생했을 경우, 자동으로 슬레이브가 그 역할을 할 수 있도록 마스터와 슬레이브 KDC 호스트 이름이 swapping되어야 한다. (스와핑 방법은 따로이 설명한다)
마스터 KDC 구성순서는 다음과 같다.
kdc1 # cat /etc/krb5/krb5.conf [libdefaults] default_realm = DESKPIA.COM [realms] DESKPIA.COM = { kdc = kdc1.deskpia.com kdc = kdc2.deskpia.com admin_server = kdc1.deskpia.com } [domain_realm] .deskpia.com = DESKPIA.COM # # if the domain name and realm name are equivalent, # this entry is not needed # [logging] default = FILE:/var/krb5/kdc.log kdc = FILE:/var/krb5/kdc.log [appdefaults] gkadmin = { help_url = 이곳에는 SEAM 도움말을 볼 수 있는 URL을 지정해줌. }
위의 예에서는, default_realm, kdc, admin_server, 그리고 모든 domain_realm 라인의 엔트리를 변경하였다. 만일 영역과 도메인의 명칭이 동일하다면 설치과정중 default_realm 엔트리는 자동으로 생성되지 않는다. 그러나 자세한 설명을 위하여 위의 예에 포함시켜 놓았다. 또한 help_url 경로도 적절한 주소로 변경시켜 준다.
kdc1 # cat /etc/krb5/kdc.conf [kdcdefaults] kdc_ports = 88,750 [realms] DESKPIA.COM= { profile = /etc/krb5/krb5.conf database_name = /var/krb5/principal admin_keytab = /var/krb5/kadm5.keytab acl_file = /var/krb5/kadm5.acl kadmind_port = 749 max_life = 8h 0m 0s max_renewable_life = 7d 0h 0m 0s }
kdb5_util을 이용, KDC 데이터베이스 생성
kdb5_util 명령어는 KDC 데이터베이스를 생성하는데 사용된다. kadmind와 krb5kdc 데몬이 시작되기 전에 KDC 자신을 KDC가 인증하는데 필요한 stash파일이 있다. 이 stash파일 역시 kdb5_util 명령어에 -s 옵션을 붙여서 생성한다.
kdc1 # /usr/krb5/sbin/kdb5_util create -r DESKPIA.COM -s Initializing database '/var/krb5/principal' for realm 'DESKPIA.COM' master key name 'K/M@DESKPIA.COM' You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: <마스터키를 입력해준다.> Re-enter KDC database master key to verify: <한번 더 마스터키를 입력해준다>
Kerberos access control list file (kadm5.acl)을 연다.
/etc/krb5/kadm5.acl 파일안에는 KDC를 관리하는 것이 허용된 모든 principal 명칭이 들어있어야 한다. 첫 번째 엔트리는 다음과 같이 되어있을 것이다.
sunny/admin@DESKPIA.COM *
이 엔트리는 DESKPIA.COM 영역안에 있는 sunny/admin이라는 principal에게 KDC의 principal이나 보안정책을 마음대로 수정할 수 있는 권한을 주는 것이다. 초기 설치과정에서는 모든 admin principal과 일치한다는 * 표시가 포함되어 있을 것이다. 이것은 보안상 위험한 요소이므로 admin principal 리스트를 모두 직접 포함시키는 것이 좋다.
kadmin.local을 시작한다.
다음과정은 SEAM이 사용할 principal을 생성하는 것이다.
kdc1 # /usr/krb5/sbin/kadmin.local kadmin.local:
kadmin.local을 이용하여 데이터베이스에 모든 관리자 principal을 추가한다.
필요한 모든 관리 principal을 추가하도록 하자. KDC 구성을 마치기 위해서는 최소한 하나의 관리자 principal이 추가되어야 한다. 이 예에서는 sunny/admin principal이 추가되었다. 물론 여러분은 sunny대신 다른 이름을 사용해야 한다. (*주: sunny는 선희라는 사용자였음)
kadmin.local: addprinc sunny/admin Enter password for principal sunny/admin@DESKPIA.COM: <암호를 입력> Re-enter password for principal sunny/admin@DESKPIA.COM: <암호 재입력> Principal "sunny/admin@DESKPIA.COM" created. kadmin.local:
kadmin.local을 이용하여 kadmin의 keytab파일 생성
kadmin.local 명령어는 kadmin과 changepw의 principal 엔트리에 대한 keytab 파일을 생성해주는 것이다. 이 principal들은 kadmind 서버스를 위해서 꼭 필요하다.
kadmin.local: ktadd -k /etc/krb5/kadm5.keytab kadmin/kdc1.deskpia.com Entry for principal kadmin/kdc1.deskpia.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab. kadmin.local: ktadd -k /etc/krb5/kadm5.keytab changepw/kdc1.deskpia.com Entry for principal changepw/kdc1.deskpia.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/kadm5.keytab. kadmin.local: Quit kadmin.local
필요한 principal을 모두 추가해준 이후 kadmin.local을 종료한다.
kadmin.local: quit
이후 커버로스 대몬을 작동시키자.
kdc1 # /etc/init.d/kdc start kdc1 # /etc/init.d/kdc.master start
kadmin을 구동시킨다.
여기서, 사용자는 SEAM 관리도구를 이용하여 필요한 principal을 추가해줄 수 있다. 간단하게 설명하기 위하여 커맨드 라인을 사용한 예를 들었다. 이 과정을 수행하기 위해서는 이미 사용자가 만들어놓은 admin principal 명칭중 하나로 log on 해야 한다.
kdc1 # /usr/krb5/sbin/kadmin -p sunny/admin Enter password: kadmin:
kadmin을 이용하여 마스터 KDC 호스트 principal 생성하기.
호스트 principal은 ftp나 telnet 과 같은 커버로스 서비스나 klist, kprop과 같은 커버로스 응용 프로그램이 사용하는 것이다.
kadmin: addprinc -randkey host/kdc1.deskpia.com Principal "host/kdc1.deskpia.com@DESKPIA.COM" created. kadmin:
필요할 경우, kadmin 명령어를 이용하여 마스터 KDC의 root principal을 생성한다. 이 principal은 인증된 NFS-mounting에만 사용하므로 마스터 KDC에서는 필요하지 않다.
kadmin: addprinc root/kdc1.deskpia.com Enter password for principal root/kdc1.deskpia.com@deskpia.COM: Re-enter password for principal root/kdc1.deskpia.com@DESKPIA.COM: Principal "root/kdc1.deskpia.com@DESKPIA.COM" created. kadmin:
마스터 KDC의 호스트 principal을 마스터 KDC의 keytab 파일에 추가해준다. 이렇게 추가를 해주면 추가된 principal은 필요할 경우, 자동적으로 사용된다.
kadmin: ktadd host/kdc1.deskpia.com kadmin: Entry for principal host/kdc1.deskpia.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab kadmin: quit
kadmin을 종료한다.
kadmin: quit
각 KDC의 엔트리를 propagation 구성파일 (kpropd.acl)에 추가한다. 이미 SEAM 소프트웨어를 설치하여 사용중이라면 그냥 확인만 해보아야 한다.
kdc1 # cat /etc/krb5/kpropd.acl host/kdc1.deskpia.com@DESKPIA.COM host/kdc2.deskpia.com@DESKPIA.COM
NTP나 다른 시각 동기화 메카니즘을 이용하여 마스터 KDC의 시각을 맞춘다. 모든 서버의 시각은 krb5.conf 파일의 libdefaults 부분에 명시한 기본 범위내로 설정되어 있어야만 보안인증이 이루어질 수 있다.
여기까지가 마스터 KDC 구성과정이었다. 다음장에서는 슬레이브 KDC 구성과정을 알아보도록 하자.
파. Slave KDC Server 구성
kdc3라는 이름의 새로운 슬레이브 KDC를 구성하는 것으로 예를 들어보자. 슬레이브 KDC 구성에 대한 전반적인 예를 들기 위하여 사용자가 kdc3 서버를 슬레이브로 설정하기 위한 아무런 사전구성도 하지 않았다는 가정하에서 시작한다. 이번 예에서는 아래와 같이 환경설정을 해놓았다고 가정한다.
realm name = DESKPIA.COM DNS domain name = deskpia.com master kdc = kdc1.deskpia.com slave kdc = kdc2.deskpia.com and kdc3.deskpia.com admin principle = sunny/admin online help URL = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956
slave KDC 구성을 위한 사전 준비사항.
슬레이브 KDC의 구성 순서는 다음과 같다.
마스터 KDC의 수퍼유저 권한을 갖는다.
마스터 KDC에서 kadmin을 구동시킨다. 이때에는 마스터 KDC를 구성할 때 생성해 놓은 관리 principal 명칭중 하나로 로그인한다.
kdc1 # /usr/krb5/sbin/kadmin -p sunny/admin Enter password: kadmin:
마스터 KDC에서, kadmin을 이용하여 슬레이브 호스트 principal을 데이터베이스에 추가시킨다. 슬레이브 KDC가 제 기능을 발휘하기 위하여, 슬레이브 KDC는 호스트 principal을 가져야 한다.
kadmin: addprinc -randkey host/kdc3.deskpia.com Principal "host/kdc3@DESKPIA.COM" created. kadmin:
필요시 마스터 KDC에서 kadmin을 이용하여 슬레이브 KDC의 root principal을 생성한다. 이 principal은 슬레이브가 인증된 파일 시스템을 NFS-mounting할때에만 사용하면 된다.
kadmin: addprinc root/kdc3.deskpia.com Enter password for principal root/kdc3.deskpia.com@DESKPIA.COM: <암호 입력> Re-enter password for principal root/kdc3.deskpia.com@DESKPIA.COM: <암호 재입력> Principal "root/kdc3.deskpia.com@DESKPIA.COM" created. kadmin:
kadmin 프로그램을 종료한다.
kadmin: quit
마스터 KDC에서 커버로스 구성파일 (krb5.conf)을 연다. 각 슬레이브의 엔트리를 추가시킨다. 만일 사전 준비과정에서 kdc3를 이미 슬레이브 서버로 지정해놓았다면 그냥 내용만 확인하면 된다.
kdc1 # cat /etc/krb5/krb5.conf [libdefaults] default_realm = DESKPIA.COM [realms] DESKPIA.COM = { kdc = kdc1.deskpia.com kdc = kdc2.deskpia.com kdc = kdc3.deskpia.com admin_server = kdc1.deskpia.com } [domain_realm] .deskpia.com = DESKPIA.COM # # if the domain name and realm name are equivalent, # this entry is not needed # [logging] default = FILE:/var/krb5/kdc.log kdc = FILE:/var/krb5/kdc.log [appdefaults] gkadmin = { help_url = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956
마스터 KDC에서 database propagation configuration file (kpropd.acl)에 각 슬레이브 KDC의 엔트리를 추가해준다. 만일 사전 준비과정에서 kdc3를 이미 슬레이브 서버로 지정해놓았다면 그냥 내용만 확인하면 된다.
kdc1 # cat /etc/krb5/kpropd.acl host/kdc1.deskpia.com@DESKPIA.COM host/kdc2.deskpia.com@DESKPIA.COM host/kdc3.deskpia.com@DESKPIA.COM
모든 슬레이브 KDC에서 마스터 KDC 서버로부터 KDC 관리파일을 복사해온다. 이 과정은 모든 슬레이브 KDC에서 반드시 필요한 것이다. 마스터 KDC 서버는 모든 KDC가 가지고 있어야 하는 최신의 정보를 항상 가지고 있기 때문이다. 만일 사전 준비과정에서 kdc3를 이미 슬레이브 서버로 지정해놓았다면 그냥 내용만 확인하면 된다. ftp나 기타 전송 프로그램을 이용해서 마스터로부터 아래 파일을 몽땅 가져온다.
/etc/krb5/krb5.conf /etc/krb5/kdc.conf /etc/krb5/kpropd.acl
새로 구성한 슬레이브 KDC에서 kadmin을 이용하여 slave의 host principal을 slave의 keytab file에 추가한다. 이때에는 마스터 KDC를 구성할 때 만들어 놓은 관리 principal 명칭중 하나로 로그온 하여 작업한다. 이 엔트리는 kprop나 다른 커버로스 응용프로그램을 사용할 수 있게 해준다.
kdc3 # /usr/krb5/sbin/kadmin -p sunny/admin Enter password: kadmin: ktadd host/kdc3.deskpia.com kadmin: Entry for principal host/kdc3.deskpia.com with kvno 3, encryption type DES-CBC-CRC added to keytab WRFILE:/etc/krb5/krb5.keytab kadmin: quit
마스터 KDC에서 crontab -e 명령어를 실행하여 백업시 자동으로 작동되는 cron job에 슬레이브 KDC 명칭을 추가한다.
각 kprop_script 라인의 끝에 슬레이브 KDC 서버의 이름을 추가한다. 만일 사전 준비과정에서 kdc3를 이미 슬레이브 서버로 지정해놓았다면 그냥 내용만 확인하면 된다.
10 3 * * * /usr/krb5/lib/kprop_script kdc2.deskpia.com kdc3.deskpia.com
백업되는 시간을 변경하려면 앞에 써있는 숫자를 바꾸면 된다. 현재 이 구성파일은 매일 오전 3시 10분에 백업과정이 시작되도록 설정되어 있다.
마스터 KDC에서 kprop_script를 이용하여 데이터베이스를 백업하고 슬레이브로 복사해주자. 만일 백업과정이 이미 끝나서 데이터베이스 백업본이 있다면 다시 할 필요는 없다.
kdc1 # /usr/krb5/lib/kprop_script kdc3.deskpia.com Database propagation to kdc3.deskpia.com: SUCCEEDED
새로 구성한 슬레이브 KDC에서 kdb5_util 명령어를 이용 stash파일을 생성한다.
kdc3 # /usr/krb5/sbin/kdb5_util stash kdb5_util: Cannot find/read stored master key while reading master key kdb5_util: Warning: proceeding without master key Enter KDC database master key: <키를 입력>
새로 구성한 슬레이브 KDC에서 KDC daemon (krb5kdc)을 시작한다.
kdc3 # /etc/init.d/kdc start
새로 만든 슬레이브에서 NTP나 그외 시각설정 프로그램을 사용하여 마스터 KDC와 시각을 맞추도록 한다. 모든 서버의 시각은 krb5.conf 파일의 libdefaults 부분에 명시한 기본 범위내로 설정되어 있어야만 보안인증이 이루어질 수 있다.
이제 모든 과정이 끝났다. 한 대의 마스터 KDC와 한 대의 슬레이브 KDC가 있으면 이제 SEAM 환경에서 여러분의 컴퓨터를 클라이언트로 설정하여 사용할 수 있게 된다.
하. SEAM의 실제적용과 KDC 보안
1) 시스템 보안을 위한 SEAM의 실제 적용
이제껏 복잡한 SEAM 및 커버로스 인증체계를 알아본 이유는 ? 누군가 시스템에 access할 때 솔라리스 운영체제가 무상제공해주는 SEAM을 이용하여 인증절차를 통과하도록 함으로서 시스템 보안을 향상시키기 위함이었다.
그러면, 실제로 사용자들이 ftp, telnet 서비스 사용시 커버로스 인증절차를 반드시 거치게 하는 방법을 알아보자.
/etc/inetd.conf 파일을 열어서 telnet 부분으로 간다.
텔넷 엔트리에 '-a user' 옵션을 추가한다.
telnet stream tcp nowait root /usr/krb5/lib/telnetd telnetd -a user
ftp 부분으로 가서 ftp 엔트리에도 -a 옵션을 추가한다.
ftp stream tcp nowait root /usr/krb5/lib/ftpd ftpd -a
/etc/inetd.conf 파일에 있는 쉘이나 로긴의 엔트리는 모두 주석을 붙이거나 삭제한다.
# shell stream tcp nowait root /usr/sbin/in.rshd in.rshd # login stream tcp nowait root /usr/sbin/in.rlogind in.rlogind
자, 이제부터는 커버로스 인증을 거치지 않은 사용자는 telnet이나 ftp를 절대 사용할 수 없다.
2) KDC server 보안
보디가드가 아무리 남을 잘 지켜준다 해도, 그 보디가드가 공격을 당해서 쓰러진다면... KDC 서버는 보안상 아주 중요한 위치에 있음을 누차 강조한 바 있다. 그 KDC 서버가 공격대상이 되어 누군가가 침입을 했다면....
우선 다른서버도 그러하겠지만 KDC는 일반 사용자들이 접근할 수 없는 안전한 장소에 위치해 있어야 한다. KDC 데이터베이스의 백업본, 그리고 keytab 파일은 KDC 서버의 디스크나 다른 슬레이브 KDC 디스크에 보관한다. (테이프백업본은 특히 소홀하기 쉬운 부분이다. 서버만큼이나 안전하게 보관되어야 한다.)
KDC로 접근하는 방법은 복도위를 걸어서 오는 방법과 네트웍 선을 타고 오는 방법이 있다. 불필요한 사용자가 네트웍 선을 타고 오는 방법을 차단하는 방법은 KDC 서버의 /etc/inetd.conf 에 있는 서비스중 필요없는것을 중단시키면 된다.
그러나 KDC의 임무를 위하여 중단하면 안되는 것들이 있다. time 서비스, krdb5_prop 서비스는 꼭 필요하다. 또한, loopbak tli ( ticlts, ticotsord, and ticots)를 이용하는 서비스 역시 그냥 둘 필요가 있다.
아래는 새로 수정한 KDC의 inetd.conf 파일이다. 필요없는 대부분의 서비스는 삭제하였다.
kdc1 # cat /etc/inetd.conf # #ident "@(#)inetd.conf 1.33 99/08/14 SMI" /* SVr4.0 1.5 */ .... .... #name dgram udp wait root /usr/sbin/in.tnamed in.tnamed #shell stream tcp nowait root /usr/sbin/in.rshd in.rshd ... .... # Time service is used for clock synchronization. # time stream tcp nowait root internal time dgram udp wait root internal .... # 100234/1 tli rpc/ticotsord wait root /usr/lib/gss/gssd gssd 100134/1 tli rpc/ticotsord wait root /usr/krb5/lib/ktkt_warnd kwarnd #telnet stream tcp nowait root /usr/krb5/lib/telnetd telnetd #ftp stream tcp nowait root /usr/krb5/lib/ftpd ftpd #kshell stream tcp nowait root /usr/krb5/lib/rshd rshd -k -c -A krb5_prop stream tcp nowait root /usr/krb5/lib/kpropd kpropd
위와 같이 변경후에는 KDC서버를 꼭 재부팅해주어야만 효력이 발생한다.
[9] ASET (자동 보안강화 시스템 도구)
가. 개요
기나긴 솔라리스 보안의 마지막 강좌부분이다. 이제껏 우리가 다룬 내용의 대부분은 어떻게 하면 허가받지 않은 이들이 파일 및 시스템에 접근하는 것을 막을 수 있을까 하는것이 주된 사항이었다. 이를 더욱 보강해 줄 수 있는 도구로서 솔라리스 8은 ASET이라는 재미있는 시스템 보안강화 유틸리티를 함께 제공해주고 있다. ASET은 시스템 보안을 자동으로 모니터링하고 제어하는 기능을 제공한다. 시스템 관리자는 ASET이 제공하는 관리도구로 보안등급을 조절하여 시스템을 운영할 수 있다. 관리자가 보안등급을 낮음 (low), 중간 (medium), 높음 (high) 중 하나로 지정해주면 ASET은 이를 시스템보안에 그대로 적용시켜준다.
ASET은 7가지 형태의 작업을 수행한다. 각 작업을 통하여 시스템 파일에 대한 보안 점검 및 접근권한 제어가 가능하다. ASET이 높은 등급으로 적용될 수록 시스템 파일에 접근하기는 더욱 어려워지고 보안에 헛점이 될만한 시스템파일들은 모두 체크되며, 감시대상이 된다.
/usr/aset 디렉토리를 살펴보면 이 안에는 ASET 작업에 필요한 마스터파일, 레포트, 그외 다른 ASET 파일들이 들어있다. ASET이 적용하는 보안등급은 마스터파일에 의해 구성된다. 물론 이들 파일을 적절하게 수정하여 해당 싸이트의 보안정책에 따른 ASET 보안레벨을 결정할 수 있다.
ASET은 작업을 하면서 보안상 약점을 찾아내어 리포트로 남겨놓는다. 뿐만 아니라 높은 보안등급을 적용시켜 놓으면 ASET이 직접 모든 시스템 보안상 약점을 수정, 변경해준다. 만일 그래도 잠재적인 보안 위험요소가 남아있게 되면, ASET은 그 문제를 관리자에게 리포트로 보고해준다. 충직한 보안담당 보좌관인 셈이다.
ASET 세션은 /usr/aset 명령어를 사용하여 필요시 직접 실행시킬 수 있다. 또한 crontab파일에 엔트리를 추가해주면 일정한 시간마다 주기적으로 ASET을 실행시킬 수도 있다.
그런데 ASET 작업은 많은 디스크작업을 수반한다. 보안점검을 위한 파일검사 때문이다. 이는 평상시 시스템 작업에 방해가 될 수 있다. 이로 인한 시스템 성능저하가 우려된다면 시스템 사용상태가 최저일 때 ASET을 구동시키도록 스케줄을 잡으면 된다. (하루 혹은 이틀에 한번꼴로 새벽 2시에 실행이 되도록 하면 되지 않을까 ?)
1) 도대체 ASET의 7가지 작업은 무엇일까 ?
ASET이 작업중 발견한 모든 문제들을 자세히 기록한 리포트는 보안관련 문제해결에 큰 도움을 줄 수 있다. 작업이 완료되면 리포트는 해당파일 안에 기록된다. 그러면, ASET이 하는 작업을 각각 구체적으로 살펴보자.
2) 시스템 파일 사용권한 검증
사용자가 원하는 보안레벨은 회사마다 모두 틀릴 수 있다. 이 작업은 시스템 파일의 사용권한을 원하는대로 설정해준다. 솔라리스 운영체제가 인스톨될 때에도 이것이 수행되지만 (낮은 보안등급으로 기본설정될것이다) 인스톨 후에도 이작업을 다시 실행시켜 보안레벨을 수정할 수 있다. 낮은 보안등급에서는 누구나 시스템에 쉽게 접근할 수 있는 개방형 정보공유 환경으로 설정된다. 그러나 높은 보안등급에서의 시스템 파일 접근은 매우 제한된다. 이 작업을 통해서 이루어지는 시스템 파일의 사용권한이나 파라메터 변경내용은 tune.rpt 파일에 리포트로 기록되므로 어떤 파일이 어떻게 변경되었는가를 쉽게 알 수 있다.
3) 시스템 파일 점검작업
시스템파일을 점검하고 마스터파일에 적힌 내용과 비교해보는 작업이다. 마스터파일에는 관리자가 지정한 보안등급하에서 시스템파일에 대해 점검해야할 체크리스트가 들어있다. 마스터파일은 ASET이 이작업을 최초로 실행할때 생성된다. 점검해야 할 파일들이 들어있는 디렉토리 리스트는 각 보안등급에 따라 정해진다. 사용자는 기본 리스트를 그대로 사용할 수도 있고 그것을 변경시킬수 도 있으며, 각 레벨마다 다른 디렉토리를 지정할 수도 있다.
각 파일에 대하여 다음 사항들이 점검된다.
- 소유자 및 그룹 - 사용권한 (permission bits) - 크기 및 checksum - 링크의 개수 - 최종적으로 수정된 시간
여기서 마스터파일과 비교하여 일치하지 않는 점은 cklist.rpt파일에 기록된다. 이 파일은 마스터파일에 기록된 시스템파일 크기, 사용권한, checksum값과 비교한 결과가 포함되어 있다.
4) 사용자/그룹 점검
이 작업은 passwd 및 group 파일에 정의된 사용자계정 및 그룹의 무결성(integrity)과 일관성(consistency)을 점검한다. 여기서는 local 호스트컴퓨터와 NIS 혹은 NIS+의 패스워드파일을 점검한다. NIS+ 패스워드 파일에 문제가 발견되면 이것은 리포트로 남겨지지만 패스워드 파일이 수정, 변경되지는 않는다. 이 작업에서는 다음 위반사항을 점검한다.
- 중복된 이름이나 ID - 정확치 않은 포맷 엔트리 - 패스워드가 지정되지 않은 계정 - 유효하지 않은 로그인 디렉토리 - nobody 계정 - null 값의 그룹 패스워드 - NIS 혹은 NIS+ 서버의 /etc/passwd 파일안의 +기호
위반된 사항은 모두 usrgrp.rpt 파일에 리포트로 남겨진다.
5) 시스템 구성파일 (configuration file) 점검
이 작업에서는 여러 가지 시스템 테이블을 검사한다. 대부분은 /etc 디렉토리안에 있는 것들이며, 다음 파일들이 검사대상이다.
- /etc/default/login - /etc/hosts.equiv - /etc/inetd.conf - /etc/aliases - /var/adm/utmpx - /.rhosts - /etc/vfstab - /etc/dfs/dfstab - /etc/ftpusers
점검후 발견되는 문제점들은 sysconf.rpt file에 기록된다.
6) 환경변수 점검
root 및 일반사용자들의 PATH 및 UMASK 환경변수가 각 사용자의 해당 /.profile, /.login, /.cshrc file안에 어떻게 설정되어 있는가를 점검한다. 점검후 발견되는 문제점들은 env.rpt file에 기록된다.
7) eeprom 점검
eeprom은 솔라리스 인텔 버전사용자에게는 해당사항이 없는 내용이지만 sparc 서버 사용자에게는 중요한 사항이다. 이 작업은 eeprom의 보안관련 parameter가 적절한 보안등급으로 설정되어있는가를 점검한다. 사용자는 이 값을 none, command 혹은 full로 지정할 수 있다. ASET은 이 값을 변경시키지는 않지만 권장하는 결과는 eeprom.rpt 파일에 기록한다.
8) Firewall (방화벽) 설정
방화벽에 대해서는 네트웍 보안부분에서 언급한바 있다. ASET은 여러분의 시스템을 그대로 방화벽 시스템으로 만들어줄 수 있다. 방화벽 시스템이 꼭 필요한 이들에게는 ASET이 그 해결책이 될 수 있는 것이다.
ASET으로 이 방화벽 시스템을 설정하게 되면 정말 높은 보안레벨을 시스템에 적용시킬 수 있다. IP 패킷전송도 막을 수 있다. 그러나 이것을 만들기 전에 고려해야 할 사항이 참으로 많다. 일단 적용되고 나면 기존의 환경과는 전혀 다른 상황이 벌어지기 때문이다.
만일 사용자가 높은 보안등급으로 ASET을 실행시키고는 싶지만 방화벽 구축까지는 필요가 없다면 asetenv 파일을 수정하여 firewall 작업을 삭제할 수 있다. 그러면 firewall 작업을 제외한 다른 작업은 그대로 실행된다.
나. ASET 실행기록 (log) 및 보고서 (Report)
1) ASET 실행 기록 (log)
ASET을 실행시키면 아래와 같이 작업에 대한 log, 즉 실행기록이 화면에 나타난다. 뿐만 아니라 ASET은 수행된 모든 작업내용을 파일에 기록해준다. aset -n 명령어를 사용하면 이 작업내용이 e-mail로 지정된 사용자에게 전송된다.
4 ASET 실행기록(log) 파일의 예 ASET running at security level low Machine=study; Current time = 0325_08:00 aset: Using /usr/aset as working directory Executing task list... firewall env sysconfig usrgrp tune cklist eeprom All tasks executed. Some background tasks may still be running. Run /usr/aset/util/taskstat to check their status: $/usr/aset/util/taskstat aset_dir Where aset_dir is ASET's operating directory, currently=/usr/aset When the tasks complete, the reports can be found in: /usr/aset/reports/latest/*.rpt You can view them by: more /usr/aset/reports/latest/*.rpt
위 기록의 첫 번째에는 ASET이 수행된 시스템과 시각이 나타난다. 그후 시작된 각 작업의 목록이 나온다.
ASET은 각 작업을 백그라운드로 처리할 수 있다. 백그라운드 처리작업이 시작되었다는 것은 실행로그의 목록에 나타나지만 이것이 종료되었는가는 표시되지 않는다. 백그라운드작업의 상태를 점검하려면 taskstat 유틸리티를 사용하면 된다.
2) ASET 리포트
ASET 작업과 함께 생성되는 모든 리포트 파일은 /usr/aset/reports directory 밑에 있는 해당 서브디렉토리에 들어있다. 이 서브디렉토리의 구조 및 사용법은 다음과 같다.
리포트가 생성될 때에 붙여지는 이름은 생성된 시간과 일자를 반영한것이다. 이를 통하여 ASET 실행중 시스템 상태의 변동 기록을 살펴볼 수 있다.
아래는 새로 생성된 두 개의 서브디렉토리의 한 예이다.
0115_02:30 0116_02:30
각 서브디렉토리 이름은 월일_시간:분 (이들 모두 두자리 숫자로 구성)의 형식이다.
lastest 디렉토리는 최신 리포트가 있는 서브디렉토리로 연결되는 심볼릭 링크이다. 고로 ASET이 생성한 최신 리포트를 보려면 /usr/aset/reports/latest directory로 가면 된다. 이곳에는 ASET이 수행한 각 작업중 최근에 실행된것에 대한 리포트 파일이 들어있다.
3) ASET Report File 형식
각 리포트파일은 해당 작업이 종료되면서 생성된후 이름이 붙는다. 아래는 작업이름과 이에 해당하는 리포트의 목록이다.
- 시스템 파일 사용권한 검증 (tune) : tune.rpt - System file 점검 (cklist) : cklist.rpt - 사용자/그룹 점검 (usrgrp) : usrgrp.rpt - 시스템 구성(configuration)파일 점검 (sysconf) : sysconf.rpt - 환경변수 점검 (env) : env.rpt - eeprom 점검 (eeprom) : eeprom.rpt - 방화벽 설정 (firewall) : firewall.rpt
각 리포트파일 안에는 시작 및 끝을 표시하는 배너표시가 잇다. 정전이 된다던가 하는 불의의 사고로 해당 작업이 비정상적으로 중단될 때, 리포트파일의 끝부분에는 작업이 중단된 이유가 표시된다. (물론, 정전이 되서 작업을 중단한다는등 구체적인 이유가 나오지는 않는다)
아래는 usrgrp.rpt 리포트파일의 예이다. *** Begin User and Group Checking *** Checking /etc/passwd ... Warning! Password file, line 12, no passwd :sync::1:1::/:/bin/sync ..end user check; starting group check ... Checking /etc/group... *** End User And group Checking ***
4) ASET Report File 점검
ASET을 재구성(reconfiguration)하거나 처음 실행시킨 후에는, 리포트파일을 세밀히 점검해보아야 한다. 재구성할 때에는 마스터 서브디렉토리의 asetenv 파일이나 마스터파일이 수정되기도 하며, ASET 작업이 실행될 보안레벨이 변경되는 수도 있으므로. 리포트 파일에 기록된 모든 오류사항은 재구성될 때 표시된다. 리포트를 세밀히 점검함으로서 시스템에 발생한 모든 문제점에 대응하고 이를 해결할 수 있다.
다. ASET 관련 파일운영
1) ASET Master File
/usr/aset/masters 디렉토리안에 있는 tune.high, tune.low, tune.med, uid_aliases등의 파일을 ASET 마스터파일이라고 한다. ASET은 이들 마스터파일을 근거로 시스템의 보안등급을 지정한다.
2) Tune File
tune.low, tune.med, tune.high 와 같은 파일은 ASET 보안등급을 지정하는 마스터파일이다. 이들은 각 등급에서의 시스템 파일의 속성을 명시해주고 비교나 참고 목적으로 사용된다.
3) uid_aliases 파일
uid_aliases file은 같은 ID를 공유하는 복수 사용자 계정의 리스트를 가지고 있다. 보통, ASET은 이러한 사용자 계정에 대하여 경고를 해준다. uid_aliases 파일에 있는 exceptions에 목록을 표기해주면 이러한 원칙에서 예외를 허용할 수 있다. 그러나 복수의 사용자계정이 동일한 사용자 ID를 갖는 것은 피해야 하며, 꼭 이를 원할 경우에는 그룹 계정 생성과 같은 다른 방법을 찾아보자.
4) 체크리스트 파일
ASET을 처음 실행시키거나 보안등급을 변경후 실행시킬 때 시스템파일 체크리스트를 이용한 마스터파일이 생성된다. 이작업으로 점검되는 파일은 다음 환경변수로 정의된다.
CKLISTPATH_LOW CKLISTPATH_MED CKLISTPATH_HIGH
5) ASET 환경 File (asetenv)
asetenv라는 환경파일은 ASET 작업에 영향을 주는 변수 목록을 가지고 있다. 사용자가 원하는대로 ASET 작업을 변경할 수 있도록 이 변수들은 수정이 가능하다.
① ASET 구성
ASET은 대부분의 경우 약간의 사용자 관리 및 구성, 혹은 기본값으로 수행시킬 수 있다. 그러나 특정한 ASET에 영향을 미치는 파라메터들을 약간 튜닝해주면 효과를 극대화시킬 수 있다. 기본값을 변경하기 전에 ASET이 어떻게 수행되는가와 이 파라메터들이 시스템의 각 요소들에게 어떤 영향을 미치는가를 알아보자.
ASET은 아래 4가지 구성파일에 의거하여 작업의 특성을 결정한다.
/usr/aset/asetenv /usr/aset/masters/tune.low /usr/aset/masters/tune.med /usr/aset/masters/tune.high
② 환경 (Environment) File (asetenv) 수정
/usr/aset/asetenv file은 크게 두 부분으로 나뉜다.
사용자 설정 파라메터 section 내부 환경변수 section
사용자는 사용자설정 파라메터 섹션을 수정할 수 있다. 그러나 내부 환경변수 섹션의 설정값은 시스템 내부에서 사용되는 것으로서 바꾸면 안된다. 사용자설정 파라메터 섹션의 엔트리는 아래와 같은 경우에 수정하면 된다.
- 실행할 작업을 선택할때 - 체크리스트 작업 디렉토리를 지정할때 - ASET 실행 스케줄을 지정할때 - aliases 파일을 지정할때 - NIS+ 테이블을 확장점검할 때
③ 실행할 작업 선택
대부분의 시스템환경에서 보안시스템은 요구사항이 각각 다르다. 그러므로 해당 시스템에서는 불필요한 작업을 하나 혹은 몇 개정도 삭제해줄 필요가 생길 수 있다.
예를 들어, 모든 시스템이 firewall을 설치할 필요는 없을 것이다. 이럴때 asetenv 파일의 환경변수중 아래 예로 든 TASKS 부분을 수정하여 firewall에 관련된 파라메터를 삭제하면, firewall 없이 ASET을 높은 보안등급에서 실행시킬 수 있다. 여기서는 firewall이라는 환경변수를 삭제하면 된다. 그후 ASET을 수행시키면 firewall은 수행되지 않는다.
TASKS="env sysconfig usrgrp tune cklist eeprom firewall"
④ Checklist 작업 디렉토리 지정 : CHKLISTPATH
사용자 시스템 디렉토리를 선택하여 그 안에 있는 파일의 속성을 점검하는 시스템 파일 점검작업이다. 사용자는 checklist path 환경변수를 이용하여 어떤 디렉토리를 점검할 것인가를 결정할 수 있다.
CKLISTPATH_LOW CKLISTPATH_MED CKLISTPATH_HIGH
CKLISTPATH_LOW 변수는 낮은 보안등급하에서 점검할 디렉토리를 지정하는 변수이다. 마찬가지로 CHKLISTPATH_MED와 CKLISTPATH_HIGH 환경변수는 각각 중간 및 높은 보안등급하에서 점검할 디렉토리를 지정한다.
가장낮은 보안등급이 적용된 디렉토리 리스트는 다음으로 높은 등급으로 적용된 디렉토리의 subset이 된다. 예를 들어 CKLISTPATH_LOW로 적용된 모든 디렉토리는CKLISTPATH_MED안에 모두 포함되며, CKLISTPATH_MED로 적용된것은 CKLISTPATH_HIGH안에 모두 포함된다.
모든 디렉토리에 대해서 광범위한 점검이 이루어지는 것은 아니다. ASET은 오로지 변수에 지정된 디렉토리에 한해서 점검을 실시한다. 물론 해당디렉토리의 서브디렉토리 역시 점검하지 않는다.
사용자는 변수를 바꾸어줌으로서 점검할 디렉토리를 추가하거나 삭제할 수 있다. 주의할 것은 매일 변동이 발생하지 않는 시스템파일에 한해서만 체크리스트를 적용해야한다는 것이다. 사용자의 홈디렉토리와 같이 수시로 변동되는 것은 체크리스트를 적용하지 않는것이 좋다.
⑤ ASET 실행 스케줄: PERIODIC_SCHEDULE
사용자는 interactive하게 ASET을 시작하거나 -p 옵션을 사용하여 지정된 시간에 ASET을 수행시킬 수 있다. 시스템의 요구사항이 적은 시간을 택하여 ASET을 이때마다 주기적으로 실행시킬 수 있다. ASET은 PERIODIC_SCHEDULE에게 자문을 구하여 작업을 얼마나 빈번하게 할지 그리고 언제 작업을 할지를 결정한다.
PERIODIC_SCHEDULE 형식은 crontab 엔트리의 형식을 따른다.
Aliases File 지정 : UID_ALIASES
UID_ALIASES 변수는 사용자 ID를 공유하는 aliases file을 지정한것이다. 기본적으로는 /usr/aset/masters/uid_aliases가 된다.
NIS+ Tables 확장점검: YPCHECK
YPCHECK 환경변수는 ASET이 시스템 구성파일테이블도 점검할 것인가를 결정해준다. YPCHECK은 부울린 변수이다. 사용자는 참값(true)인가 거짓값(false)인가만을 지정할 수 있다. 기본값은 false이며 이렇게 지정되면 NIS+ 테이블 점검은 이루어지지 않는다.
이 변수가 false로 지정되어 있다면 ASET은 로칼 시스템의 passwd 파일을 점검하지만 true로 지정되어 있으면 시스템 도메인의 NIS+ passwd 파일도 점검한다.
ASET이 자동적으로 local 테이블은 복구해주지만 NIS+테이블에 대해서는 잠재적인 문제점을 보고해줄 뿐 내용을 수정하지는 않는다.
aliases 파일을 지정 :UID_ALIASES
사용자 ID를 공유하는 목록인 aliases 파일을 지정하는 변수이다. /usr/aset/masters/uid_aliases 에 기본값이 들어있다.
Tune File 수정
ASET은 3개의 마스터 tune file (tune.low, tune.med, tune.high)을 사용하여 시스템파일의 접근을 쉽게할지 어렵게 할지를 설정한다. 이 마스터파일들은 /usr/aset/masters directory에 있으며 사용자의 환경에 따라 변경할 수 있다. tune.low file은 기본적인 시스템 설정값에 적합한 사용권한을 설정한다. tune.med file은 tune.low에서 지정한것보다 사용권한이 더욱 제한을 받는다.
ASET으로 변경된 시스템 파일 복구
ASET이 처음 실행될때, 모든 시스템 파일의 원본은 그대로 저장해놓는다. /usr/aset 디렉토리에 있는 aset.restore 유틸리티는 이 파일들을 다시 ASET 실행전 상태인 원상태로 복구해준다. 이 유틸리티를 실행시키면 시스템파일에 적용된 변동사항이 모두 없어진다.
다음과 같은 경우 aset.restore를 실행하면 된다.
만일 사용자가 ASET을 앞으로 계속 사용하지 않겠다면, 이미 root의 crontab에 추가되어 있는 aset 명령어를 cron 스케쥴링에서 제거해야 한다. cron을 이용하여 자동실행을 제거하는 것은 다음장에서 설명하겠다.
라. ASET 환경변수(Environmental variable)
ASET에서 사용되는 환경변수 및 기능은 다음과 같다.
- ASETDIR : ASET 작업 디렉토리 - ASETSECLEVEL : 보안등급 - PERIODIC_SCHEDULE : 작업주기 스케줄 - TASKS : 실행할 작업 - UID_ALIASES : Aliases file - YPCHECK : NIS 나 NIS+에 대한 확장 점검 - CKLISTPATH_LOW : 낮은 보안이 적용된 디렉토리 리스트 - CKLISTPATH_MED : 중간 보안등급이 적용된 디렉토리 리스트 - CKLISTPATH_HIGH : 높은 보안등급이 적용된 디렉토리 리스트
ASET에서 사용되는 환경변수 목록은 /usr/aset/asetenv 파일안에 있다.
ASETDIR과 ASETSECLEVEL 변수는 옵션사항이며 aset 명령어를 사용하는 사용자의 shell을 통해서만 설정이 가능하다. 다른 환경변수들은 파일을 편집하여 설정할 수 있다. 각 변수의 세부기능을 알아보자.
1) ASETDIR
ASET의 작업디렉토리를 나타낸다.
C shell 환경에서는 다음과 같이 입력한다. % setenv ASETDIR pathname Bourne shell이나 Korn shell에서는 다음과 같이 입력한다. $ ASETDIR=pathname $ export ASETDIR
위에서 pathname에는 ASET 작업디렉토리의 전체경로명을 적어준다.
2) ASETSECLEVEL
ASET 작업이 실행되는 보안등급을 지정해준다.
C shell에서는 다음과 같이 입력한다. % setenv ASETSECLEVEL level Bourne shell이나 Korn shell에서는 다음과 같이 입력한다. $ ASETSECLEVEL=level export ASETSECLEVEL 위에서 level은 다음중 하나로 지정할 수 있다. low : 낮은 보안등급으로 설정시 med : 중간 보안등급으로 설정시 high : 높은 보안등급으로 설정시
3) PERIODIC_SCHEDULE
이중 인용부호로 둘러싸인 5개 필드의 값으로 구성되어 있으며 각 필드는 공백으로 분리한다.
"minutes hours day-of-month month day-of-week" Periodic_Schedule 변수값 - minutes hours : ASET 시작시간 지정 (분은 0에서 59사이, 시는 0에서 23사이) - day-of-month : ASET이 실행되어야 할 그 달의 일자를 지정 (1에서 31사이) - month : ASET이 실행되어야 할 해당년도의 월을 지정 (1에서 12사이) - day-of-week : ASET이 실행되어야 해당주의 요일을 지정 (0에서 6사이, 0은 일요일임)
4) TASKS
ASET이 실행되는 작업의 목록을 지정하는 변수이다. 기본값은 7개의 모든 작업 목록이 있는 상태이다.
TASKS="env sysconfig usrgrp tune cklist eeprom firewall"
5) UID_ALIASES
aliases file을 지정한다. 형식은 아래와 같다.
UID_ALIASES=pathname 위에서 pathname은 aliases file의 전체경로이다. 기본값은 다음과 같이 지정되어 있다. UID_ALIASES=${ASETDIR}/masters/uid_aliases
6) YPCHECK
YPCHECK 변수는 시스템 테이블을 NIS 혹은 NIS+ 테이블로 확장시킨다. 부울린 변수로서 true 나 false 로 나타낸다. 기본값은 false이다.
YPCHECK=false
7) CKLISTPATH_level
세 개의 경로변수는 체크리스트 작업에 의해 점검될 디렉토리의 목록이다. 아래는 기본으로 지정된 것이며 각 등급에서의 변수의 관계를 보여준다. CKLISTPATH_LOW=${ASETDIR}/tasks:${ASETDIR}/util:${ASETDIR}/masters: /etc CKLISTPATH_MED=${CKLISTPATH_LOW}:/usr/bin:/usr/ucb CKLISTPATH_HIGH=${CKLISTPATH_MED}:/usr/lib:/sbin:/usr/sbin:/usr/ucblib
ASET 파일 예
Tune Files
ASET은 3개의 tune file을 가지고 있다. 엔트리 포맷은 다음과 같다.
- pathname 파일의 전체 경로명 - mode 설정된 사용권한을 나타내는 5자리 숫자 - owner 파일 소유자 - group 파일 소유그룹 - type 파일 형태
8) Aliases File
aliases file은 동일한 사용자 ID를 공유하는 aliases의 목록을 가지고 있다. 각 엔트리는 다음 형식으로 되어있다.
uid=alias1=alias2=alias3=... uid : 공유하는 사용자 ID alias : 사용자 ID를 공유하는 사용자계정 아래예는 sysadm 그리고 root가 공유하는 사용자 ID 0의 목록이다. 0=root=sysadm
마. ASET 실제 운영
1) ASET의 실행 ASET을 Interactive하게 실행하는 방법 superuser 권한을 갖는다. aset 명령어를 이용, ASET을 interactive하게 수행시킨다. # /usr/aset/aset -l level -d pathname level : 보안레벨 (기본값은 low). pathname : ASET의 작업디렉토리 (기본값은 /usr/aset) 모니터화면에 ASET 실행로그가 나타났다면 ASET이 수행되는 것이다. 실행 로그 메시지는 어떤 작업이 현재 수행중인가를 보여준다. 아래예는 기본 작업디렉토리에서 낮은 보안등급으로 실행중인 ASET의 예이다. # /usr/aset/aset -l low ======= ASET Execution Log ======= ASET running at security level low Machine = study; Current time = 0111_09:26 aset: Using /usr/aset as working directory Executing task list ... firewall env sysconf usrgrp tune cklist eeprom All tasks executed. Some background tasks may still be running. Run /usr/aset/util/taskstat to check their status: /usr/aset/util/taskstat [aset_dir] where aset_dir is ASET's operating directory,currently=/usr/aset. When the tasks complete, the reports can be found in: /usr/aset/reports/latest/*.rpt You can view them by: more /usr/aset/reports/latest/*.rpt
2) ASET을 주기적으로 실행시키는 방법
superuser 권한을 갖는다.
주기적으로 ASET을 실행시킬 시간을 관리자가 선택하여 설정한다.
시스템 요구가 최소인 시간대에 ASET을 실행시키면 시스템 성능에 지장을 주지 않는다. /usr/aset/asetenv file 안에 있는 PERIODIC_SCHEDULE 환경변수를 수정해주면 ASET을 주기적으로 실행시킬 시간이 설정된다.
기본적으로는 매일 심야(사용자가 거의 없는 시간)에 실행되도록 설정되어 있다. 만일 자신의 시스템은 지구 반대편의 외국인들이 많이 사용하므로 밤보다는 낮이 더 한가하다면 낮시간으로 PERIODIC_SCHEDULE 변수를 수정해주면 된다.
aset 명령어를 이용하여 crontab 파일에 엔트리를 추가해준다.
# /usr/aset/aset -p
-p : /usr/aset/asetenv file에 있는 PERIODIC_SCHEDULE 환경변수는 crontab 파일을 실행시킨다. 이것이 실행되면서 ASET이 시작되는 것이다. 이 crontab 파일에 엔트리를 추가해준다.
ASET이 실행되는지를 검사하는 crontab 엔트리를 출력한다.
# crontab -l root
3) 주기적으로 수행되는 ASET작업 중단하기
superuser 권한을 갖는다. crontab file을 연다. # crontab -e root ASET entry를 삭제한다. 저장후 편집기를 빠져나간다. ASET엔트리가 삭제되었는가를 확인한다. # crontab -l root
4) 서버에 ASET 리포트 모으기
superuser 권한을 갖는다. 서버에 디렉토리를 설정한다. - /usr/aset directory로 이동한다. sunny# cd /usr/aset - rptdir directory를 생성한다. sunny# mkdir rptdir - rptdir directory로 이동하여 client_rpt directory를 생성한다. sunny# cd rptdir mars# mkdir client_rpt - 리포트를 모으는 것이 필요한 각 클라이언트 컴퓨터에도 위의 내용을 그대로 반복
아래 예는 all_reports라는 디렉토리와 study_rpt, sunny_rpt 서브디렉토리를 생성하는 과정이다.
mercury# cd /usr/aset mercury# mkdir all_reports mercury# cd all_reports mercury# mkdir study_rpt mercury# mkdir sunny_rpt
client_rpt directory들을 /etc/dfs/dfstab 파일에 추가한다.
이 디렉토리들은 read/write 속성만을 가져야 한다.
아래 엔트리들은 dfstab파일 안에 있는것들로서 읽기/쓰기 속성만을 가지고 공유된 것이다.
share -F nfs -o rw=study /usr/aset/all_reports/study_rpt share -F nfs -o rw=sunny /usr/aset/all_reports/sunny_rpt
클라이언트가 사용할 수 있는 자원을 dfstab file안에 만든다.
# shareall
각 클라이언트에서 클라이언트 서브디렉토리를 서버로부터 마운트한다. 마운트 포인트는 /usr/aset/masters/reports이다.
# mount server:/usr/aset/client_rpt /usr/aset/masters/reports
/etc/vfstab file을 수정해주면 부팅때마다 디렉토리가 자동으로 마운트될 것이다.