1996년도에 쓴 글이다. 사실 이 문서가 유명해 진 것은 국내 최초의 보안웹진 LOGIN (미소테크) 에 연재되고, 또 major.kaist.ac.kr/~sakai/Security_Docs , mgt.kaist.ac.kr/~sakai/Security_Docs 에 업로드하기도 하고, 여러 잡지에서도 인용해 간 후부터인데, 사람들이 부지런히도 ^^;;; 저작권 표기 따위 없이 퍼나르고 계시다.
이 문서들은 버전이 두개다. LOGIN 에 올렸던 글이고 이 때는 제목을 'General Secure Administration' 이라는 title 로 연재 했다가, major.kaist.ac.kr/~sakai/Security_Docs 처럼 내 홈페이지에서 연재할 때에는 'Practically Useful UNIX Security Administration' 이란 제목으로 연재하였다.
Practically Useful UNIX Security Administration 시리즈가 minor update 이긴 하지만 좀 더 내용이 가다듬어졌다.
10년이 넘은 자료인데 아직 굴러다니는게 사실 좀 부끄럽다. 언제 새로 쫙 리뉴얼이라도 해서 뿌려야 하려나.
어떤 분께서 잘 Local copy 로 올려두고 계시기에 링크를 걸어둡니다. 다 퍼오긴 귀찮고;;;
Login 에 연재했던 General Security Administration 시리즈
http://kmh.yeungnam-c.ac.kr/Hacking/admin1.htm
http://kmh.yeungnam-c.ac.kr/Hacking/admin2.htm
http://kmh.yeungnam-c.ac.kr/Hacking/admin3.htm
http://kmh.yeungnam-c.ac.kr/Hacking/admin4.htm
http://kmh.yeungnam-c.ac.kr/Hacking/admin5.htm
원래는 System Performance Tuning 이 연재될 예정이었으나, 미소테크에 재직하던 KUS 93학번 선배님들이 미소테크를 떠나는 상황으로 인해 나의 미소테크 LOGIN 웹진에의 연재는 1997년도까지 해서 여기에서 끝나게 되었다. 아쉽다. 이때 좀 더 많은 글을 쓰고 싶었는데.
"* General Security Administration VI 부 (다음 호)
o 다음호에는 System Performance Turning 에 대해 다루어 보도록 하겠다."
만이 공허하다. ^^;;;
Practically Useful UNIX Security Administration 시리즈
http://jkkang.net/security/hkkim/part1.html
http://jkkang.net/security/hkkim/part2.html
http://jkkang.net/security/hkkim/part3.html
http://jkkang.net/security/hkkim/part4.html
http://jkkang.net/security/hkkim/part5.html
이때 html 뿐 아니라 MS-WORD 포맷으로도 문서를 뿌렸었다. ;-) 모두 고이 소중히 보관중.
인터넷에 떠도는 모든 종류의 보안 글들이 1994~1999 사이에 만들어 졌다면 한번쯤 꼼꼼히 살펴보시라. 글의 예제에 sakai, miso.co.kr, baikdu, chiak, sparcs, kus, cenda, nya, mtdog, 143.248.x.x 등이 들어 있다면 김휘강(HK) 의 original 문서라 보시면 됩니다. ;-)
I. General System Administration
1. System Administration
--------------------------------------------------------------------------------
System Administration 이란 무엇인가?
한마디로 줄여 이야기 하면 root 가 되어 system 을 관리하는 것을 말한다.
root 의 권한을 갖게 되었다는 것에는 많은 책임이 뒤따르게 된다.
시스템의 사활을 좌지우지 할 수 있을 뿐만 아니라, 사용자들의 account 도 임의로 삭제 할 수 있는 권한을 부여받았다는 뜻이기 때문이다.
또 root 의 권한을 갖게 되면 타 사용자들의 메일이나, 홈디렉토리에 있는 어떠한 화일이라도 열람할 수 있게 되는데 이에 따라 윤리적인 문제도 많이 파생되고 있다.
실제로 천주교의 입김이 강한 나라라든가, 프라이버시 보호가 잘 보장된 나라에서는 시스템 관리자가 될때 부득이한 목적 외에는 사용자들의 화일들을 touch 하지 않는다는 것과 사용자들의 프로세스를 임의로 kill 하지 않고 , 사용자들의 메일을 절대 보지 않는 다는 것을 선서해야 한다.
또한 사용자들도 시스템을 사용하게 될때 시스템에 피해를 주는 행위를 하지 않는다는 것과 , 시스템의 긴급 상황일 때에는 관리자가 자신의 화일들이나 메일들을 살펴 볼 수 있다는 것도 서명을 하게 되있다.
현재 국내에서는 이렇게 까지 엄격하지는 않지만 나름대로의 규칙을 정해 서로의 범위를 많이 침해하지 않도록 하고 있다.
또 항상 인지해 두어야 할 점은, 시스템 관리자는 봉사자의 입장이지 독재자가 아니라는 점이다. 항상 근면하게 시스템을 관리하며 사용자의 요구에 귀기울이는 자세가 필요하다.
예전에는 많은 명령어들을 알아야 했고, 작업에 잔손질이 많이 가는 일들도 많았지만 요즘은 Menu based Interface 를 갖춘 관리툴들이 많이 나오고 있어 관리에 상당히 편리해 졌다.
그러면, 이제 Administrator 가 관리하는 일에는 어떠한 것들이 있는가 살펴보자.
o 새로운 사용자의 account 를 추가한다.
o 사용이 중지된 사용자의 account 를 삭제한다.
o 새로운 하드웨어의 추가, 보수 , 유지한다.
o 시스템 데이터들의 백업 및 restoring 작업을 담당한다.
o 사용자들의 질문에 답해주며, 시스템 사용에 필요한 지식을 교육한다.
o 시스템을 항시 모니터링하면서 문제를 해결한다.
o 시스템의 부하를 많이 주는 프로세스가 있으면 양해를 구하고 프로세스를 죽인다.>
o 시스템의 보안상에 문제가 없도록 버그를 끊임없이 팻치해 나간다.
o 사용자에게 필요한 S/W 들을 지속적으로 인스톨하고, 업그레이드 시켜나간다.
o 시스템 panic 이나 crash 시에 수리하고, 원인을 분석하여 고친다.
위에서 열거한 일들 말고도 많은 일들이 있을 것이다.
이번 호에서는 이러한 많은 일들중에서 System Security 에 관련된 사항들을 중점적으로 다루어 보도록 하겠다.
II.General Security Administration
현재 UNIX 계열의 system에는 다양한 version 의 많은 종류의 OS 가 존재하고 있는데, 각각의 OS 마다의 많은 버그를 일일히 파악하기도 어려운 일이고, 모든 OS 를 전부 cover 한다는 것은 실제적으로 많은 어려움이 뒤따른다.
이번 달에는 system 관리를 어떻게 하면 보다 secure 하게 할 수 있는지에 대해 공통적으로 알아야 할 부분을 다루어 보겠다.
공통적으로 파악해야 하는 부분 외에도 여러 OS 마다 같은 명령어가 다른 이름으로 존재하는 경우는 짚고 넘어가겠다.
1. General Security
우선 해커(hacker) 들이 어떠한 방법으로 system에 침입하는 지를 파악한다면 이에 따라 system의 보안을 보다 효율적으로 관리할 수 있게 된다.
해킹에는 다음의 세가지 단계가 있다.
(여기에서 해킹이라 함은 intruding 을 의미하고, 해커는 원래의 뜻이 아닌 intruder 를 속칭하여 쓰기로 한다.)
1.1 Intruding & Defensing
* Intruding 의 세가지 단계
첫번째 단계로 remote host 에서 target host 의 쉘 액세스를 얻으려고 시도하는 과정이다. 최근의 많은 심각한 버그로 인하여 침입하고자 하는 host 의 shell access 를 할 수 없다 하더라도 root 권한을 얻어 낼 수 있기도 하지만 일반적으로 local host 로 침입한 후 OS 의 버그를 이용하여 root 의 권한을 얻는 것이 보통이다.
그럴 수 밖에 없는 이유로서 우선 remote 에서 직접 root 권한으로 명령을 실행시키도록 조작하는 것은 상당수준에 이른 해커들만이 구사할 수 있을 뿐 아니라 remote 에서 동작하는 버그 수는 local host 에서 OS 의 버그수에 비해 상당히 적기 때문이다.
또한 remote 에서 조작을 하여 root 권한을 얻는다 하더라도 어짜피 증거 (system의 log 화일들)를 지우기 위해 침입을 해야만 하기 때문에 결과적으로 해커는 system 안으로 침입을 강행하게 된다.
두번째 단계로 local host 침입 후 root privilege 를 얻으려 시도하는 과정이다. 이것은 우선 remote 에서 local host 로 잡입한 후에 OS 의 버그를 이용한다든지, 관리자 미숙으로 인해 system이 misconfigure 된 점을 이용한다든지 하여 system의 root 권한을 얻는 과정을 말한다.
세번째 단계로 증거 입멸 후 재침입을 위한 백도어 설치하는 과정이다.
system 로그 디렉토리(보통 /var ) 에 자신의 해킹과정과 관련된 로그화일들을 변조하거나 삭제하여 자신의 증거를 입멸한후, 재침입의 용이성을 위해 백도어를 설치하게 된다.
보통 백도어는 /bin/login , /bin/rlogin , /bin/passwd 등과 같은 setuid root program 들에 설치해 놓는 것이 보통이다.
자 , 그렇다면 이와 같은 해커의 침입에 대비하여 관리자들은 어떠한 방법으로 system을 방어해야 하겠는가?
* Defensing 의 세가지 단계
첫번째 단계는 "Network Security 를 통한 침입 방지" 이다.
해커가 remote 에서부터 아예 침입할 수가 없다면, 즉 자신의 host가 Network 관련된 버그가 아무것도 없다면, 자신이 관리하는 host 에 OS 버그가 많이 존재한다 하더라도 해커는 침입을 할 수 없을 것이다.
이처럼 자신의 host 를 network 상에 구동 시켜 놓았을 때 아무런 문제점이 없도록 하여 (system 무결성- system Integrity) 자신의 host가 vulnerable 하지 않도록 하는 것이 Network Security 이다.
두번째 단계는 "Host Security 를 통한 root 권한 노출 방지"이다.
해커가 remote 에서 자신의 host로 침입을 하는데 성공하여 shell access 권한을 얻게 되었다고 했다고 하더라도 자신의 host 내부에 아무런 security 상의 문제점이 없다고 한다면 해커는 해킹에 실패를 하게 된다.
이런 식으로 자신의 호스트 내부의 misconfiguring 된 사항들을 정상적으로 고쳐 놓는 것, 또한 자신의 system에서 사용중인 OS 의 버그를 팻치하는 Administration 과정을 Host Security 라고 한다.
세번째 단계는 "Administration 을 통한 침입자 추적, 백도어 제거" 이다.
현재 자신의 host 가 해킹을 당했는지 이상한 기미가 보이는 경우 적절히 대처하여, 해커가 설치해 놓고 나간 백도어를 찾아내어 없애야 하고, 시스템에 심각한 피해를 입혔다면 이를 추적할 수도 있어야 한다.
아직 많은 대학의 경우 시스템 관리자를 전문 관리자가 아닌 미숙한 학생들에게 맡기는 경우가 대부분이므로 자신의 시스템이 해킹을 당했는지조차 모르는 경우가 많고, 보안에 아예 무관심한 경우도 많이 있어서 문제가 되고 있다.
이제, 보안의 인증의 가장 기본이라 할 수 있는 password 관리에 대해 알아보기로 하자.
2. General Security (password Security)
2.0 /etc/passwd 화일의 구조
UNIX 시스템은 각 사용자들의 password 및 기타 정보를 /etc/passwd 에 보관하고있다. vi 나 cat 을 이용하여 이 file 을 살펴보자.
단, 보는 방법이 어떤 시스템을 쓰느냐에 따라 다르다. 위는 일반적인 경우이고 * NIS 시스템을 이용하는 경우: cat /etc/passwd 나 ypcat passwd 를 한다.
* NetInfo 시스템을 이용하는 경우: nidump passwd / 를 한다.)
/etc/passwd 화일은 6 개의 colon 으로 구분되어져 7 개의 필드로 구성이 되어 있다.
;username:password:UID:GID:User's Information:home directory:login shell
예:
sakai:JpCRcHUZgpvGs:501:100:Sakai Kim:/home/sakai:/bin/tcsh
1번째 field: User Name (login name)은 sakai 이다.
2번째 field: Password 가 encrypt 된 부분으로 요즘의 대부분의 OS 에서는 기본적으로 C2 Level 이므로 password 의 encrypt 된 내용을 따로 다른 화일에 저장한다.
(이 화일은 OS 에 따라 다르다.SunOS 4.x 에서는 /etc/security/passwd.adjunct 로 저장이 되고, Solaris 2.x 에서는 /etc/shadow 에 저장이 된다.)
아마 여러분들이 사용하는 대부분의 OS 에서는 다음과 같이 되어 있을 것이다.
sakai:x:501:100:Sakai Kim:/home/sakai:/bin/tcsh
또는
sakai:##sakai:501:100:Sakai Kim:/home/sakai:/bin/tcsh
그리고 참고로 TCSEC(Trusted Computer System Evaluation Criteria)에 대해 말해볼까 한다.
이는 시스템 보안의 표준 등급을 나누어 둔 것인데 D Level 부터 A Level 까지 등급을 나누고 있다.
레벨들 사이의 관계는 D -> A 로 갈수록 , 또 같은 레벨에서는 숫자가 클수록 보안성이 좋음을 의미한다.
[참고: TCSEC ]
o Division D: Minimal Protection
보안이 전혀 고려되어 있지 않는 시스템 즉, PC 처럼 외부에 완전히 공개되어 있는 경우.
예: MS/DOS, Macintosh, Atari Amiga
o Division C: Discretionary Protection
C1 Level : Discretionary Security Protection
사용자 간에 서로 침범할 수 없게 되어 있다.
rwx 의 permission 조정과 owner, group, other 등을 이용하여 자신의 정보를 보호 할 수 있다.
데이터는 모두 사용자 단위로 접근의 허가를 줄수 있어서 어떤 사용자는 특정한 정보에 대하여 사용할 수 있는 귄한이 있다. 그리 강력한 보안은 아니고 다른 사용자가 다른 사람의 화일을 마음대로 할 수 없다는 정도이다.
보통의 UNIX 시스템의 대부분이 이에 속한다.
C2 Level : Controlled Access Protection
C1 level보다는 조금 더 엄격해진 정도에 불과하지만 C2 level에 이르러 비로소 보안상 헛점을 대폭 줄였다고 할 수 있다.
C1 의 기준을 충족시키며, 사용자 각각의 행동을 검사할 수 있는 audit, log 기능등이 더 추가되었으며, 특징적으로 passwd 의 두번째 필드를 다른 화일에 저장하여 관리자 외에는 볼수 없도록 해두었다.
요즘의 대부분의 UNIX 시스템과 VMS(DEC) 나 AOS/VS(Data General), VM/SP,NOS 등이 이에 속한다.
o Division B: Mandatory Protection
B1 Level : Labeled Security Protection
C2 level의 기준을 충족시킨다. 각각 데이타에 보안 level을 설정하여, 낮은 보안 level을 지닌 사용자는 고 level의 정보에 접근이 금지되도록 되어있다.
기밀 등급별로 Mandatory Access Control 을 할 수 있도록 했다.
System V/MLS 등이 이에 속한다.
B2 Level : Structured Protection
B1 의 기준을 충족시키며 각 레벨의 특권 사용자는 자신의 작업에 대한 최소한의 권한만을 부여받도록 해 두었다.
보안 정책을 시스템 내에 일정하게 유지하고 있어야 한다.데이터를 access 하는데 필요되는 접근방법으로 체게화된 보호시스템이 구축되어야 한다.
예: Multics, Trusted XENIX
B3 Level : Security Domain
B2 의 기준을 충족시키며 추가적으로 H/W 자원을 포함한 보안관리자 기능 및 위험시 스스로 탐색을 하며, 최악의 경우 스스로 시스템을 정지시키는 기능까지 포함되어 있다.
운영체제 내부에 보안과 관련된 code와 관련이 없는 것은 모두 제거되어야 한다. 또한 모듈을 작게 하여 분석을 쉽게 해야한다.
즉 보안 분석과 테스트가 이루어 질수 있어야 한다.
o Division A: Verified Protection
A1 Level : Verified Design
수학적으로 secure 하다는 것이 증명된 시스템으로서 현존하지 않는다.
3번째 field: User ID Number 가 기록되는 필드이다.
4번째 field: Group ID Number 가 기록되는 필드이다.
5번째 field: GECOS 필드라고도 하는데, 사용자의 Real-Name 이나, 전화번호 등의 User Information 이 저장되는 필드이다.
6번째 field: User 의 home directory 위치를 절대경로로 기록하는 필드이다.
7번째 field: User 가 사용하는 shell 의 위치를 절대경로로 표시한 필드이다.
요즘의 OS 들은 보통 C2 Level 이지만 아직도 아래와 같이 encrypted 된 password 가 /etc/passwd 에 노출이 되어 있는 C1 시스템의 경우에는 C2 레벨로 업그레이드 할 것을 강력히 권한다.
sakai:JpCRcHUZgpvGs:501:100:Sakai Kim:/home/sakai:/bin/tcsh
이렇게 encrypt 된 password 필드를 Crack 등의 프로그램에 입력하면 간단하고 단순한 password인 경우 password가 무엇인지를 알아 낼 수 있게 된다.
시스템 내부에 침입한 해커가 이런 식으로 다른 사용자의 password를 알아낸뒤 다른 사용자의 account 를 도용할 수 있게 되므로 C2 레벨을 유지하는 것이 요구된다.
C2 레벨로 업그레이드를 해주는 tool 로 C2conv 가 있다.
single 사용자 상태에서 이 프로그램을 실행시키면 C2 Level 로 업그레이드 시켜 준다. 그리고 C2 convert 시 문제가 생기면 C2unconv 를 이용하여 다시 복귀시킬 수 도 있다.
C2conv 이외에도 Linux 용의 shadow 패키지 같은 것도 C2 레벨로 업그레이드 시켜주는 툴의 좋은 예가 될 것이다.
2.1 password가 노출되지 않도록 한다.
해커가 remote 상에서 침입하기 위해서는 targethost 의 username 과 password 가 필요할 것이다. 그래서 해커는 이를 어떻게든 알아내려 애를 쓰는데, 단순히 guessing 을 이용하는 저수준 방법도 있을 수 있겠지만, 대부분의 해커는 이를 얻기 위해 Sniffing 을 시도한다.
다음은 sakai.kaist.ac.kr 란 호스트에서 sniffing 을 하는 예이다.
sakai# ./sniffit
Log started at => Mon Apr 8 20:29:04 [pid 10937]
-- TCP/IP LOG -- TM: Mon Apr 8 20:29:44 --
PATH: sakai.miso.co.kr(1270) => cenda.miso.co.kr(telnet)
STAT: Mon Apr 8 20:29:48, 30 pkts, 77 bytes [TH_FIN]
DATA: (255)(253)^C(255)(251)^X(255)(251)^_(255)(251)
(255)(251)!(255)(251)"(255)
(253)^E(255)(251)#(255)(251)$(255)(250)^X
: IRIS-ANSI-NET(255)(240)(255)(253)^A(255)(252)^Aaragorn
: evenstar
: cls
: du -s -k *
: elm arwen
--
위의 예를 보면 알겠지만 sakai.miso.co.kr 에서 cenda.miso.co.kr 로 aragorn 이란 사용자가 evenstar 라는 password를 사용한다는 것을 알아 낼 수 있다.
기본적으로 TCP 관련 패킷들은 encrypt 되지 않으므로 root password가 노출이 된다면 정말 큰일이라고 할 수 있다.
이를 막기 위해서 관리자는 사용자들에게 password가 노출되지 않도록 주의해 줄 것을 주지시켜야 한다.
예를 들어, 사용자들로 하여금 ssh(Secure Shell) 등을 이용하여, 암호화된 패킷을 주고받도록 하며, 최근의 로그인 정보를 통해 이상한 징후가 있는지 늘 살펴보는 등의 방법으로 이런 위험은 어느 정도 줄일 수 있게 된다.
특히 최근 관리의 편의를 위해 sudo 를 이용하여 root privilege 를 일반 사용자들이나 staff 그룹, wheel 그룹들과 공유하는 경우가 많다.
예:
% id
uid=103(sakai) gid=101(wheel)
% sudo /sbin/shutdown -y NOW
Password:
(여기에서 root password를 입력치 않고 sakai 란 사용자의 password를 입력한다.)
하지만 원칙적으로 이는 위험한 일임을 알아야 한다.
그룹에 등록된 사용자들의 password 만 누출이 되어도, root 의 password 가 누출되는 것과 마찬가지의 파급효과가 일어나기 때문이다.
반드시 sudo 를 써야만 하는 경우라면 /etc/sudoers 등의 화일들이 root 만 read 퍼미션을 갖도록 조정해 주는 것이 좋다.
su 명령어를 이용하여 주는 것이 sudo 보다는 더 안전하다.
예:
% su root -c "/sbin/shutdown -y NOW"
Password:
참고로 SCO UNIX 에서는 sudo 와 비슷한 명령어로 asroot (루트인양...) 라는 명령어가 있다. (/tcb/bin/asroot)
잡담이지만 SCO UNIX 는 국내에서 그다지 많은 점유율을 보이는 OS 는 아니지만, 시스템 관리 관련 툴의 GUI 가 타 OS 에 비해 상당히 뛰어나서 고정팬들의 지속적인 사랑을 받고 있다.
이런 것들과 마찬가지로 요즘은 각 OS 마다 GUI 가 뛰어난 Integrated System Administration tool 들을 제공하고 있는 추세이다.
(Solaris 의 admintool, HP-UX 의 sam , AIX 의 SMIT, VSM , Digital UNIX 의 setup,
IRIX 의 Cadmin series , SCO UNIX 의 sysadmsh , scoadmin 등등)
2.2 Password Aging
위에서 예로 들은 가상적인 문서에도 적혀 있지만 아무리 사용자들에게 password를 주기적으로 바꾸어 달라고 주지를 시켜도, 게으르고 *무지한* 사용자들은 계속 추측하기 쉬운 password를 사용하며, 또한 password를 바꾸지 않게 마련이다.
이런 것을 강제적으로 시키기 위해 Password Aging (password 갱신) 를 수행할 필요가 있다.
* passwd aging
password aging 기능은 System V 에서 처음으로 구현이 된 기능으로, 일정한 시간이 흐른 후에는 password 를 로긴시에 자동으로 바꾸도록 해주는 것을 말한다.
password aging 을 지정해 주기 위해 shadow facility 에서는 /etc/shadow 화일에 직접 기록해 주거나, /bin/passwd 명령을 이용하거나, Administration tool 을 이용하여야 한다.
/etc/shadow 화일을 사용하는 OS 들에는 Solaris 2.x , IRIX 등이 있다.
HP-UX 의 경우 9.x 에서는 손으로 기록해 주어야 하지만 10.x 인 경우 아주 강력한 Administration tool 인 SAM 을 통하여 간단하게 지정을 해 줄수 있고, Solaris 의 경우 /etc/shadow 를 직접 에디팅하거나 admintool 을 이용하여 지정해 주면 된다.
물론 공통적으로 /bin/passwd 를 사용하면 지정을 할 수 있다.
먼저 /etc/shadow 화일의 각 필드를 살펴보자.
ID:encrypted password:lastchange:minday:maxday:warnday:inactiveday:expiredate
1번째 field: User Name 이 기록되는 필드이다.
2번째 field: 사용자가 입력한 password 가 password화 되어 저장되는 필드이다.
3번째 field: password 를 마지막으로 바꾼 날짜가 기록이 되는 필드이다.
4번째 field: 한번 password 를 바꾸었을 때 바뀐 password를 적용시켜야 하는 최소일수를 말한다.
즉 한번 password를 바꾸면 이 일수 동안은 password를 다시 바꿀 수 없게 된다.
5번째 field: 사용자가 한번 password 를 바꾸었을 때 바뀐 password를 사용할 수 있는 최대한의 일수를 기록하는 필드이다.
6번째 field: password 를 바꾸도록 warning 메시지를 보내는 일수를 기록한 필드이다.(즉 password 유효 만기가 다 차기 지정된 날수 전부터 메시지를 보내어 password를 바꾸기를 권고한다.)
7번째 field: password 가 expire 된지 며칠후에 access 를 disable 시킬 것인 지를 기록하는 필드이다.
8번째 field: 이 account 가 사용중지되는 날짜를 기록하는 필드
이제 실제로 /bin/passwd 를 이용하여 aging 을 시키는 것을 살펴보자.
(Administration tool 을 사용하는 경우는 각 필드에 숫자만 기록하면 되므로 생략하겠다.)
o 관련된 /bin/passwd 의 옵션 (System V 계열의 /bin/passwd 경우임)
-n : minimum day
-x : maximum day
-f : 다음로긴시에 무조건 password를 사용자가 바꾸도록 한다.
-s : password aging status 를 보여준다.
-a : 모든 사용자의 password aging status 를 보여준다.
-l : 사용자가 로긴하지 못하도록 password를 lock 해놓는다.
-u : lock 을 걸어놓은 사용자의 password를 unlock 시킨다.
-d : 사용자의 password 를 삭제한다.
예:
# passwd -n 1 -x 158 sakai
(password를 바꾸고 바꾼 password를 158 일동안 사용할 수 있다.)
# passwd -x 3 -n 30 username
# passwd -w 3 username
(password 를 최소 3일에서 최대 30 일 까지 사용할수 있고, password 를 바꾸도록 만 3일전부터 경고를 보내게 된다.)
BSD 계열 UNIX 를 사용하는 경우에는 위에 열거한 옵션들과 매우 다르다.
그 이유는 초창기 BSD 계열 UNIX 에서는 shadow facility 를 고려하지 않았기 때문이다.
또 관련된 명령어로, AIX 의 경우 pwdadm (password Administration 의 약자) 이 있다.
AIX 4.1 의 경우 /etc/security/user 화일을 데이터베이스로 사용하고, AIX 3.2.5 의 경우 /etc/security/login.cfg 등의 화일에 관련된 내용을 저장한다.
2.3 좋은 password를 사용하자.
좋은 password란 타인이 알아내기 힘든 password를 말한다.
요즘의 OS 에서 제공되는 /bin/passwd 는 password 를 바꿀 때에 좋은 password 를 선택하도록 엄격히 관리하고 있다.
즉, 특수문자가 반드시 포함되어야 하고, 소대문자를 섞어 써야 하는 것등을 규칙 으로 정해 추측이 어렵도록 관리를 해준다.
그렇다면 반대로 나쁜 password 에는 다음과 같은 것들이 있다.
[BAD PASSWORD] ID 와 같은 password
사용하는 시스템의 이름
컴퓨터의 호스트의 이름
영어사전에 나오는 단어 (boss , world .... )
전화번호
생일
키보드위의 같은 선상에 있는 글쇠들의 연속.(qwert,asdf .....)
동일한 글자의 연속 (11111, eeeee .... )
나쁜 password를 사용하는 경우 crack 과 같은 password guessing 프로그램을 이용하여 password 를 알아낼 수 있게 되고, 이를 악용할 여지도 생기게 마련이다.
이를 막기 위해 관리자는 좋은 password를 사용할 것을 사용자들에게 주지시키고, 주기적으로 password를 점검하여 쉬운 password를 사용하는 사용자들에게 password 를 바꿀 것을 권고해줘야 한다.
예전에는 관리자가 일일히 password 를 guessing 해내어 쉬운 password 를 사용하는 사용자를 찾기 위해 crack ,cops 같은 툴을 따로 설치해야 했지만, 요즘의 OS 에는 기본적으로 password checking tool 이 포함되어져 나오고 있다.
o AIX 의 경우
/etc/security/user 에 dictionlist가 저장되어 있는데 , pwdchecks 명령을 사용하여 사용자의 password 를 체크한다.
o SCO 의 경우
goodpw facility 를 이용한다.
/usr/bin/goodpw 를 이용하기 위해 /etc/default/passwd 화일안에 다음과 같은 사항을 지정해 둔다.
GOODPW = YES
DESCRIBE = /usr/lib/goodpw/describe
SUMMARY = /usr/lib/goodpw/summary
ONETRY = YES
CHECKDIR = /usr/lib/goodpw/checks
o 그 외의 경우
자기가 관리하는 OS 에 이러한 facility 가 지원되지 않는다면 passwd+ 나 npasswd를 사용하면 될 것이다.
passwd+ 는 /bin/passwd 의 약점을 보완한 것으로 자체의 decrypt 알고리즘이 있어서 간단한 password 를 사용하고 있는 사용자들에게 자동으로 메일을 보내어 주의를 주기도 하고 password aging (특정기간이 지나면 바꾸도록 메일을 보내어 체크해 준다.) 기능이 있어서 사용자들의 비밀번호의 관리에 도움을 준다.
npasswd 는 텍사스 Austin 대학의 Clyde Hoover 에 의해 개발된 프로그램이다.
이것도 passwd+ 과 유사한 기능을 가지고 있다.
이를 정리해 보면,
둁 최소한의 password 의 길이를 조정할 수 있다.
둁 사용자로 하여금 대소문자, 숫자. 마침점등을 강요할 수 있다.
둁 단순한 password 를 체크해 낼 수 있다.
둁 호스트 이름과 호스트 정보를 체크해 낼 수 있다.
둁 로그인 이름과 성명등을 체크할 수 있다.
둁 시스템 사전을 비롯하여 여러 사전의 단어를 이용하여 체크를 해 볼 수 있다.
이 툴들은 각 ftp 서버에서 쉽게 구할 수 있다.
npasswd
ftp://ftp.cc.utexas.edu/pub/npasswd/
passwd+
ftp://ftp.dartmouth.edu/pub/security/
또는 Crack 이나 COPS 를 이용해 보는 것도 좋은 방법이 될 것이다.
Crack 이나 Cops 는 다음의 ftp 서버에서 쉽게 구할 수 있다.
COPS
ftp://info.cert.org/pub/tools/cops/
C Program 버전도 있고 Shell script, Perl script 버전이 모두 존재한다.
Crack version 5.0 & Crack lib
http://www.users.dircon.co.uk/~crypto/
ftp://info.cert.org/pub/tools/crack/
ftp://info.cert.org/pub/tools/cracklib/
최근에 나온 Crack 5.0 은 예전의 4.x 버전에 비해 password 추측하는 성능이 향상되었으며 gecos 필드의 체크를 보다 강력하게 해준다.
참고로 Crack 과 Cops 에 대해 살펴보겠다.
나중에 Security 관련 stuff 들에 대해 정리할 때 더욱 자세히 다루게 될 것이다. [Crack & Cops Briefing]
Cops 가 검사하는 부분
o 화일, 디렉토리 , device 의 퍼미션을 검사
o 쉽게 추측할 수 있는 password 를 검사한다.
o /etc/rc와 /crontab 에 의해 실행되는 프로그램 검색
o Set user id 화일들과 화일들의 퍼미션 조사
o 중요한 화일들의 CRC 조사
o 유저들의 홈디렉토리와 .profile , .cshrc , .login과 .rhost 화일 체크의 퍼미션 조사
( 주어진 사용자를 체크하는 expert 시스템 기능)
o anonymous ftp setup 조사
o CERT 에서 발견한 버그와 보안의 헛점에 관련된 화일을 알려준다.
o NFS mount 와 /etc/host.eqiv 를 조사
o /dev/kmem과 다른 디바이스 화일의 읽기/쓰기를 체크
Crack
% Crack
Crack 4.1f RELEASE, The Password Cracker (c) Alec D.E. Muffett, 1992
Invoked as: Crack
Usage: Crack [options] [bindir] passwdfile [...]
Or: Crack -network [options] passwdfile [...]
Options:-
-v - to produce verbose output
-nnicevalue - to run niced to 'nicevalue'
-rpointfile - to recover a crashed-out job
-Rpointfile - to recover (with verify) a crashed-out job
-f - to run in foreground (output to stdout)
-m - to mail the user a warning message if cracked
# Crack /etc/shadow
위의 명령을 돌리면 , Crack 이 프로세스로 되어 수행되게 되며 얼마후 out.$HOSTNAME$$ 라는 이름의 화일로 저장이 되게 된다.
출력 화일에서 얻을 수 있는 결과
join: Guessed yddd (/bin/csh in passwd) [harmony] Lr95Q
join: Guessed skan (/bin/csh in passwd) [JinSeok] Psyjvi0Oa
join: Guessed gni (/bin/csh in passwd) [genius.] ZkUag
위의 예에서 보듯이, 쉽게 추측할 수 없을 것 같은 password도 알아내는 결과를 볼 수 있다.
단순히 영어로 된 단어만이 아니라 한글 단어를 2 벌식 영어단어로 옮긴 사전을 이용하여 crack database 를 구축한 경우도 있어, 단순히 한글을 영어로 옮겨서 치는 경우도 좋은 password라고만은 볼 수 없다.
2.4 /etc/passwd 화일 관리
Null password 의 문제점
우선 /etc/passwd 화일을 통하여 , NULL password인 사용자들을 체크해보는 것이 중요하다. password 를 사용하지 않는 경우 침입을 당하기 쉬워서 문제를 발생시킬 수 있기 때문이다.
일일히 확인하는 방법도 있지만 다음과 같은 awk 명령을 이용하면 쉽다.
% awk -F: 'length($2)<1 {print $1}' < /etc/passwd
sync
haltsys
leegh
다음은 몇달동안이나 로그인을 안하여 문제가 될 소지가 있는 사용자들을 조사해서 연락하여, 계정을 적정기간에 지우는 것이다.
우선 사용을 하지 않는 사용자를 찾아내는 명령을 다음과 같이 shell script 로 찾아낸다.
% cat > find_idler.sh
#!/bin/sh
# 이번달에 로그인 안한 사람 찾아내기
#
THIS_MONTH='date |awk '{print $2}''
last |grep $THIS_MONTH |awk '{print $1}' |sort -u > /tmp/users1$$
cat /etc/passwd |awk -F : '{print $1}' |sort -u > /tmp/users2$$
comm -13 /tmp/users[12]$$
/bin/rm -f /tmp/users[12]$$
^D
% sh find_idler.sh
audit
backup
bin
calab
또한, 위에서 말한 외에, 시스템 관리자가 주의해야 할 것은 다음과 같다.
o 사용하지 않는 계정은 반드시 지운다. 또한 사용하는 계정이라고 하더라도, 사용자 이름 필드에, 만기일을 기입하여, 주기적(1달에 1회정도)으로 이를 check하는 Shell Script를 수행하는 것이 좋다.
o 손님 계정(대체로 로그인 이름은 guest, anonymous, public, general, sonnim의 형태가 된다)은 사용이 끝나면 즉시 지운다.
o password가 지정되지 않은 사용자나 uid(user id)가 0인 사용자를 찾아서 가급적이면 지우던가, 알려주도록 한다.
uid가 0인 계정을 알아내려면 다음과 같이 한다.
% awk -F: '$3 == 0' /etc/passwd
o 잘 알려진 계정인, vendor, service, sysdiag, wheel 등과 같은 계정은 필요성 여부를 잘 판단해서, 불필요한 것은 지우고, 남길 것은 남기지만, 위에서 말했듯이, 절대로 uid를 0으로 해서는 안된다.
위의 사항들에 대해 좀 더 깊이 들어가 보기로 하자.
======================================================================
***** NULL password 를 사용하는 계정이 야기하는 보안문제 I *****
======================================================================
"sync" 라는 계정은 보통 SunOs 에서 Null password 로 두어 아무 사용자나 로긴만 하면 sync 가 되도록 되어 있다.
하지만 이를 악용하여 다음과 같은 해킹이 일어나는 것이 가능하다.
% cat > exit.c << _EOF_
exit()
{
execl("/bin/sh","sh",0);
}
_EOF_
% cc -c -assert pure-text exit.c
% ld -o libbug.so exit.o
% setenv LD_PRELOAD `pwd`/libbug.so
% /bin/login -p
login: sync
SunOS 4.1.1 ...
^C
$ LD_PRELOAD=
$ id
uid=daemon(1) gid=daemon(1)
$ ^D
%
위와 같이 아무리 보안에 신경을 썼다 해도 우선 Null password 인 상태라면 외부의 사용자가 뚫고 들어올 발판을 마련해 주는 것과 다를 바가 없다.
위의 스크립트는 sync 로 들어가면 원래는 초기 shell 이 없이 sync 명령어를 호출하게 되어있지만 그 대신 shell 을 띄우도록 조작을 해 놓은 것이다.
해커는 우선 저런 방식으로 뚫고 들어갔다면 다음에 들어가기 편함을 위해 chsh 이나 passwd -s 로 초기 shell 을 바꾸어 놓을 것이다.
======================================================================
***** NULL password 를 사용하는 계정이 야기하는 보안문제 II *****
======================================================================
$ grep '^[^:]::' /etc/passwd
root::NQI1235sdq3.:0:0:Super User:/:/bin/csh
demo::7:17:Demo User:/home/demo:/bin/sh
::0:0:::
$ su ""
#
위와 같이 NIS 의 셋업을 잘못하여 "::0:0:::" 과 같은 줄이 들어있는 경우 위와 같이 침입을 당할 수 있게 된다. 또한, root 권한을 갖는 uid 가 0 인 사용자의 경우, Null Password 라면 그대로 어떠한 사용자라도 login 을 하여 root 권한을 획득하게 되므로 반드시 Null Password 인 사용자를 두어서 는 안되겠다.
부득이 passwd ID 또는 UID=0 인 ID를 이용하는 서비스에서는, shell access 를 제한 하는 것이 좋다.
--------------------------------------------------------------------------------
예:
anonymous FTP 의 경우 initial shell을 /bin/false 로 할당한다
/usr/lib/rsh (restricted shell) 을 이용하여 File System 을 제한되게 Access 하도록 한다.
--------------------------------------------------------------------------------
일일히 password 화일을 check 하기가 쉬운 일은 아니다.
특히 사용자의 수가 엄청나게 많은 경우는 OS 에서 제공해주는 프로그램을 이용하는 것이 좋다.
o 대부분의 System V 계열 UNIX, SunOS , Linux 의 경우
/sbin/pwdck 을 사용한다.
성능이 뛰어난 프로그램이다.
이와 마찬가지로 group 화일을 체크해 주는 화일도 있다.
/sbin/grpck 이다.
o AIX 의 경우
pwck 를 사용한다.
예전의 /etc/passwd 화일과 현재 화일과의 비교
o 사용자가 상당히 많은 경우 password 화일에 새로운 사용자가 불법적으로 해커에 의해 추가되었다든지, 변조가 되었다든지를 한번에 눈치채기가 어려워 진다. 그러므로 주기적으로 /etc/passwd 화일을 백업하는 것이 중요하다. 단, 시스템 내부에 백업화일을 두지 말고 반드시 하드카피나 백업테잎, 플로피 디스크 등을 이용하여 offline 상태에서 보관하도록 한다.
예:
# mcopy /etc/passwd a:
로 백업을 한 후, 나중에
# mcopy a:/passwd /tmp/old_passwd
# diff /etc/passwd /tmp/old_passwd
2.5 Password Security Administration (Further Study)
지금까지 아주 기본적인 패스워드 보안을 위해 해야 할 일들을 정리해 보았다.
이제 좀더 깊이 있게 다루어 보자.
o Trusted System
Trust 란 말그대로 "신뢰" 이다. 이 개념은 버클리 계열 유닉스의 r-(remote) 명령어들을 구현하면서 생긴 것이다. (rsh, rlogin, rcp, rdist...)
이를 적용하여 A 란 호스트가 B 란 호스트를 trust 하고 있으면, 즉 B 가 A 의 trusted 호스트이면 B 호스트의 사용자가 A 호스트에 로긴하지 않고도 화일을 엑세스 할 수 있으며, 또한 패스워드 인증 절차 없이 로긴할 수도 있게 된다.
어떻게 보면 상당히 편리하지만 , 이것이 악용되어 현재 많은 보안 문제들을 낳고 있다.
여기에서 인증절차에 요구되는 화일이 $HOME/.rhosts 화일이다.
이 화일은 rlogin 으로 들어올때에 아무런 패스워드 인증절차가 없이도 로그인을 허가해 줄 수 있도록 한다.
-------------------------------------------------------------------------
예:
% hostname
arirang
% cat .rhosts
ssrirang.miso.co.kr sakai
serva.miso.co.kr seoro
이제 ssrirang.miso.co.kr 에서 arirang.miso.co.kr 의 sakai 란 유저로 rlogin 하는
예이다.
$ rlogin arirang.miso.co.kr -l sakai
Last login: Fri Mar 3 01:53:29 from baram.miso.co.kr
....
You have mail
$
비단 .rhosts 에 + + 가 적혀 있어서 모든 호스트의 모든 사용자로부터의 rlogin 시에 패스워드 인증을 하지 않겠다는 .rhosts 화일이 아닐지라도, 외부로부터의 인증되지 않는 로긴을 허가하게 되면 문제가 발생할 수 있으므로 아예 /etc/services 나 /etc/inetd.conf 에서 r-command 들을 disable 시키는 것이 좋다.
.rhosts 는 개인사용자 단위에서의 패스워드 인증 생략을 위한 화일이지만 아예 시스템 자체에서 특정 호스트에서 들어오는 커넥션에서는 패스워드 인증을 하지 않겠다는 것을 지정할 수 있는데 여기에 사용되는 화일은 /etc/hosts.equiv 이다.
=============================================================================
예:
# cat /etc/hosts.equiv
gold.acs.com
silver.acs.com
adam.kaist.ac.kr
-@netgroup1
+@netgroup2
위의 화일이 의미하는 바는 gold.acs.com , silver.acs.com , adam.kaist.ac.kr 에서 들어오는 모든 유저에 대해서는 패스워드를 묻지 않고 들어오는 것을 허용하며, netgroup1 에 속한 모든 호스트에 대해서는 불가, netgroup2 에 속한 호스트들에 대해서는 허용을 표시한 것이다.
=============================================================================
이들 화일들은 차라리 사용을 하지 않는 것이 유리하며, 다음과 같은 명령을 이용하면 쉽게 지울 수 있다.
# cd /
# find . -name ".rhosts" -o -name ".netrc" -print -depth -exec rm -f {} /;
# rm /etc/hosts.equiv
다음은 자신의 호스트에 있는 .rhosts 화일들과 이를 소유하고 있는 아이디를 검색하는 스크립트 이다.
#!/bin/sh
# Search for .rhosts files in home directories
PATH=/bin:/usr/bin:/usr/ucb:
export PATH
case $# in
1)
if test -f $1/.rhosts; then
echo "There is a .rhosts file in $1"
fi
;;
0)
(ypcat passwd; cat /etc/passwd) 2> /dev/null | /
awk -F: 'length($6)>0 {print command, $6}' command=$0 - | /
sort -u | sh
;;
*)
echo "usage: $0 [home directory]"
;;
esac
다음은 자신의 호스트에 있는 .rhosts 를 모두 지울 때 사용하는 스크립트이다.
#!/bin/sh
# Search for .rhosts files in home directories
# And delete them.
PATH=/bin:/usr/bin:/usr/ucb:
export PATH
case $# in
1)
if test -f $1/.rhosts; then
echo "The .rhosts file in $1 has been deleted"
rm -f $1/.rhosts
fi
;;
0)
(ypcat passwd; cat /etc/passwd) 2> /dev/null | /
awk -F: 'length($6)>0 {print command, $6}' command=$0 - | /
sort -u | sh
;;
*)
echo "usage: $0 [home directory]"
;;
esac
이와 같이 hosts.equiv 나 .rhosts 들을 삭제했다고 해도 이러한 화일을 악용하는 해킹유형에서는 .rhosts 화일이나 hosts.equiv 화일이 존재하는 경우 append 시키고 없는 경우에는 create 시키기 때문에 아예 /etc/hosts.equiv , ~root/.rhosts 를 /dev/null 로 링크시키는 것이 좋은 해결책이라 할수 있다.
이 외에도 좀더 강도 높게 시스템을 관리하려면 ssh 이나 S/Key 을 사용하는 것이 좋다.
ssh(Secure Shell: http://www.cs.hut.fi/ssh)
예:
% ssh arirang.miso.co.kr -l sakai
Connection to arirang.miso.co.kr was refused.
Using rsh. WARNING: Connection will not be encrypted.
하지만 ssh 을 이용하는 경우 시스템에 부하가 많이 걸리고 사용자들이 불편해 할 수도 있다.
언제나 그렇지만 엄격하게 시스템을 관리하는 것은 항상 사용자들의 편의와 trade off 하는 것임을 알고 적정한 수준에서 조정하는 것이 좋을 것이다.
이제 어느정도 패스워드 관리하는데 필요한 지식이 쌓였으리라 생각이 된다.
하지만 passwd 는 시스템 관리의 첫단계인 사용자 account 추가, 삭제에 필요한 가장 기본적인 내용일 뿐이다.
이제 다음 호에서는 process 를 관리하는 법 및 시스템의 로그들을 관리하는 것을 security 와 관련을 맺어 설명을 할까 한다.
다음호 예고
General Secure Administration 2 부
o Process 관리, 감시법
o 시스템의 로그관리 및 분석법. 관련 명령어 및 툴 소개
======================================================================
(footnote)
# 는 root shell 프롬프트를 뜻한다.
$ 은 일반 사용자의 borne shell 계열 쉘 프롬프트를 뜻한다.
% 는 일반 사용자의 C shell 계열 쉘 프롬프트를 뜻한다.
======================================================================
References
1. Essential System Administration, O'Reilly & Associates, Inc.
2. KUS Bulletin ; NULL Password 에 관한 문제점 - 이석찬
3. [General Security Technique - Practically Useful], 김휘강
제 4 회 WWW-KR Conference
댓글 없음:
댓글 쓰기