Previous     Next      Top   Detailed TOC  

유닉스 보안: 1/2 부

• 개요
• 유닉스 보안 속성 가이드
• 일반
• 문서
• 보증      "C2" for SunOS
• 주요 위험 / 문제
• 책임추적성
• 신원확인 / 인가
• 도입
• 유닉스 계정: 일반적 지침
• NIS
• NIS +
• 패스워드 대안
• DES 암호화 스크립트
• DNS (Domain Name Service)
• 감사 증적
• 시스템 변경사항 감시
• 감사:  Sun Shield / BSM
• 로그파일
• Syslog
• Process Accounting:   Solaris Accounting
• 2부: 접근통제,안전한 데이타 교환, 책임추적성, 체크리스트 및 도구들

개요

유닉스는 안전한 운영체제로 설계되지 않았다. 유연하고, "개방적"이고, 이식성 있고 단순하게 구상 설계되었다. 이제 28년이 지난 지금, 유닉스는 주요 서버 운영체제중 하나이고 앞으로도 그럴 것으로 보인다. 그러나 유닉스는 골치아픈 보안 문제들을 일으키고 있다. 대부분의 벤더들이 몇년간 보안을 개선해왔고, 그 결과 현재 시스템들은 이전보다 나아졌지만, 벤더들은 아직도 유닉스 소스코드를 청소하는 데 충분한 노력을 하지 않고 있거나 또는 할 수가 없다 (호환성 때문에). 유닉스 시스템의 주요 판매 초점은 기술적 혁신이며 보안은 경시되고 있다.. 유닉스 시스템을 안전하게 운영하려면 시스템 관리자의 엄청난 노하우가 필요하다. [덧붙이자면 VMS나 NT도 마찬가지다]

유닉스는 많은 변형을 가지고 있다, 예를들면: Next, SGI, AIX, HP-UX, AUX, SunOS, Solaris, SCO, Ultrix, Digital UNIX (OSF/1) 그리고 Unixware. UNIX 상표는 이제 X/Open Ltd 에서 가지고 있다. 유닉스에는 두 가지 주요 줄기가 있다: BSD (버클리 대학에서 개발) 와 SYSV (AT&T의 System 5, 그 후 USL, Novell 그리고 지금은 SCO).

SVR4 와 OSF 은 BSD 와 SYSV 모두를 기반으로 하며 SVR4가 현재 사실상의 표준이다. 대부분의 상용시스템들은 SVR4 에 기반하거나 SVR4로부터 특정 구성요소들을 가져왔다. DEC, IBM 및 HP 시스템들은 OSF 특징들을 많이 가지고 있다.

BSD: SunOS (Solaris 1.x), BSDI, Ultrix, OSF/1, NeXTstep, HP-UX, OpenBSD, NetBSD, FreeBSD.
SVR4: Solaris 2.x, HP-UX, Unixware 및 (얼마간) IRIX5, HP-UX 10
OSF: Digital Unix
이상한 것: AIX (SVR3+BSD+OSF+IBM). AIX 는 BSD, System V release 3 와 중대한 비표준 변경을 섞어놓은 것이다. AIX 에 있는 서브시스템 중 BSD나 SVR4 에서와 같은 방법으로 관리되는 것은 거의 없다. 관리하기는 아주 재미있다.

이 절에서는 SunOS (Solaris 1.x) 와 Solaris 2.x 를 주로 다룬다. AIX, Digital UNIX, IRIX 및 HP-UX 도 조금씩 추가해 나갈 것이다. 그러나, 이들 시스템 중 대부분은 SunOS 나 Solaris와 비슷하므로, Sun 외의 유닉스 관리자에게도 이 장은 도움이 될 것이다.

• 아직까지 다음 사양에 따라 시스템을 안전하게 할 수 있는 단일 도구는 없다.
  • 민감한 Solaris 서버와 배스천 호스트를 강화 (harden) 하기 위해 Yassp 을 추천한다.
  • Titan 은 다중 사용자 서버를 강화하는데 유용한 또다른 도구이다.
  • 유용한 상용 감시/강화 도구로 Raxco 의 ESM 제품이 있다.
  • Tripwire 는 방화벽 배스천과 같은 비다중사용자 호스트에서 인가되지 않은 변경을 탐지하는 데 뛰어난 작은 도구이다.
  • 시스템이 얼마나 잘 강화되었는지 검사하기 위한 TAMU 타이거 스크립트 또는 나의 감사 스크립트.
  • 네트웍 서비스와 네트웍 취약점 스캔을 위한 Nmap 과 아마 Nessus도.
  • 로그, 로그인 시간, 위험한 파일, 네트웍 인터페이스 및 빈 패스워드를 감시하기 위한 약간의 직접 만든 스크립트들 (e.g. 예제 스크립트들은 부록 D 에).
• Solaris 1.x(SunOS) 보다는 Solaris 2.x 를 사용한다, 더 안전하고 관리하기도 더 쉽다. Solaris 1을 써야 한다면, 4.1.3 보다는 4.1.4를 설치한다, 보안 패치가 통합되어 있다.
• Trusted UNIX 시스템 (e.g. TCSEC "B" 승인받은) 은 여기서 아직 논의하지 않는다. 상용 유닉스와는 꽤 다른 경향이 있다. 어쩌면 나중에 언젠가?
• OpenBSD 를 한 번 보도록 한다, 특히 훌륭한 유닉스 전문기술을 가지고 있다면.. 이것은 보안을 주 목표로 하는 유일한 유닉스이다.

유닉스 보안을 위한 속성 가이드

• 사용자: 사용자와 직원들이 반드시 좋은 패스워드를 사용하도록 확인한다. 디폴트 패스워드를 사용하지 못하게 하거나 변경한다.
• 부록 C 에 열거된 방법들을 통해 검사한다.
• Solaris/SunOS: Yassp 을 설치하고/하거나 부록 D의 명령들을 이용하여 시스템, 특히 방화벽과 중요한 시스템들에서 불필요한 서비스들을 벗겨낸다.
• /var/mail 을 마운트 하는 모든 클라이언트와 비 메일서버들에서 sendmail 을 내려놓는다. 메일서버에는 최신의 sendmai/postfix/qmaill 을 설치한다.
• 최신 패치를 새로운 설치본으로 설치한다. 가능하면, 패치 설치를 자동화하여 (Sun에서는 Jumpstart를 통해) 모든 시스템들상에서 패치 버전을 쉽게 동기화할 수 있게 한다.
• NFS 파일시스템을 각각 Export 및 import 한다.  Secure NFS 를 사용한다.
• NIS 보다는 NIS+ 를 사용한다.
• TFTPD 가 필요하면, 올바르게 설정한다 (-s 옵션), 아니면 사용하지 않는다.
• syslog 서버에 공간이 많이 있으면 중요 서버들에 대해 inetd 로깅을 활성화 한다 (Solaris 2.x 에서 inetd 명령줄에 -t 옵션 추가).
• 이상한 행위에 대해 로그를 감시한다( 매주,  매일). 자동으로 알람을 발생시킨다.
• 서버들에 대해 보안 검사기(e.g. Tripwire, COPS, ESM, ASET, SecureMax...)를 주기적으로 실행한다 ( 6개월마다,  매월). Tripwire 는 하루에도 여러번 실행할 수 있다.
• 스캐너 (ISS/Satan/nmap) 를 사용하여 네트웍을 주기적으로 스캔한다 ( 6개월마다, 매월): 내부에서 그리고 방화벽을 담당하고 있다면 외부에서도. 시스템/네트웍 관리자의 허가 없이는 절대 스캐너를 사용하지 않는다.
• rlogin, rsh, rcp & telnet 대신 ssh 를 사용한다.
• X11에는 xhost 보다 xauth를 사용한다. 절대 "xhosts +" 는 사용하지 않는다. Ssh를 사용한다면, xauth 는 자동이고 X11 통신은 암호화된다.
• 필요하지 않으면 inetd 데몬은 내려놓는다 (방화벽에서: 아마 ftp 말고는 모두 없애고 login 에는 ssh 를 사용한다).
• 방화벽 장에 있는 내용에 따라 유닉스 프락시와 방화벽을 구성한다.
• FIRST 보안 경고 메일 리스트에 가입한다. 부록 C 참조.
• etherfind 와 snoop 같은 스니퍼는 사용 불가능하게 하거나 삭제한다.

일반

문서

보증 (Assurance)

보증을 위해서는 ITSEC 이나 TCSEC 등급에 인증된 OS 버전을 선택한다. See the "운영체제 개론" 장을 참고한다. 대부분의 유닉스 버전은 C2로 사용할 수 있다.

SunOS4 용 "C2"

이 패키지는 solaris1 시스템이 C2 레벨 보안을 따를 수 있게 해준다. 실제 경험상으로는 관리하기 어렵고, 많은 패치를 필요로 하고, 복잡하며, 거대한 로그를 제공하며 심지어 이 로그들에 대한 패스워드를 clear text 로 쓴다. 이 패키지를 쓰느니 Solaris 2로 업그레이들 할 것을 권한다.

주요 위험 / 문제

• 패스워드가 없거나, 취약한 패스워드 또는 디폴트 패스워드를 가지는 시스템과 사용자 계정 (e.g. IRIX 및 벤더 설치 시스템).
• 도청:
• (암호화된) 패스워드에의 접근: NIS를 사용하거나 shadow 패스워드 파일을 가지고 있지않은 유닉스 시스템들 (BSD, SunOS, OSF/1, Ultrix, HP-UX V9...) 은 사전 (dictionary) 공격에 노출되어 있다 [11].
• Clear text 패스워드에의 접근: 많은 유닉스 서비스들이 패스워드를 clear text 로 전달한다 (e.g. ftp, telnet). 네트웍 스니퍼는 공격자 Toolkit의 기본 부품이다. 많은 유닉스 시스템들은 출시될 때 네트웍 스니퍼를 포함하고 있다.
• 버그가 많은 소프트웨어:
• Sendmail 프로그램은 아직도 새로운 구멍과 위험을 만들어내고 있다.
• 벤더들은 종종 현재 소프트웨어의 문제점들을 고치기 보다도 새로운 것에 집중한다.
• 버그가 많은 프로토콜: 유닉스에서 사용되는 주요 통신 프로토콜인 TCp/IP 는 이용당하기 쉬운 여러가지 보안 취약점을 가지고 있다.
• 잘못된 설정: NFS 와 TFTP 는 종종 잘못 설정되어 시스템들을 완전히 개방해 놓는데, 대개는 관리자의 지식부족 때문이다.
• 복잡성:
• 대부분의 유닉스 종류에서 작동하는 표준 보안도구가 거의 없다. 어떤 도구도 모든 측면을 다루지 못한다.
• 유닉스 시스템 관리는 복잡하고 따라서 실수하기 다.
• 많은 제조업체들이 보호주의적이며, 자체적인 브랜드의 유닉스를 다른 종류들과 아주 다르게 개발한다 (e.g. AIX). POSIX 인터페이스 지원은 이 문제를 어느정도 경감시킨다.
• 어떤 유닉스 종류의 소스코드(e.g. BSD) 는 해커들이 구할 수 있다. 이것은 이 시스템들에 대한 공격 가능성을 높이지만, 또한 이들의 보안 알고리듬을 철저히 검증할 수 있게도 한다.
• 암호:
• 미국의 수출 정책은 유닉스에 고급 암호화 메카니즘을 포함시키려는 노력을 수년간 마비시켰다. 이제는 개방되었으므로 (200년 9월) 새로운 기회가 있다. 예를 들어 OpenBSD 2.9 는 디폴트 설치시 강력한 암호 도구를 많이 포함한다.
• 메일 클라이언트에서 보안 이메일 시스템(e.g. PGP) 이 표준으로 포함되거나 지원되지 않는다.

책임추적성

신원확인 / 인가

도입

표준 유닉스는 user ids (UID) 를 통해 사용자들을 식별하는데, 이것을 사용자의 로그인 이름에 부여되는 번호이다. 사용자는 패스워드를 사용하여 인증된다.

• login, xdm, telnet, ftp, SSH 명령들은 사용자에게 사용자이름 (username)과 패스워드를 물어봄으로써 인증을 한다.
• SSH 는 또한 RSA 키를 사용하여 사용자를 인증할 수도 있다.
• NIS (대부분의 벤더들이 지원하는) 는 위의 원칙을 토대로 하지만, 사용자들의 식별과 인증을 한 그룹 (도메인이라고 불리는) 의 시스템들에 대해 수행한다.
• NIS+는, NIS를 완전히 새로 개조한 것으로, Secure RPC ("보안 메커니즘" 장 참고)를 기반으로 하는데, 이는 사용자가 사용하는 시스템도 인증을 하고 사용자를 net name 으로 식별하며, 이 net name은 도메인에서 유일하다. 강력한 (그러나 무적은 아닌) 암호화 기법이 사용된다 (512 비트 키를 쓰는 Diffie-Hellman 공개키 암호화).
• "r" 명령들은 (rlogin, rsh, rcp) 사용자들의 UID와 출발 시스템의 이름을 근거로 사용자를 인증한다. 대상 시스템의 .rhosts 나 host.equiv 가 적절하게 구성되어 있으면 패스워드 없이 접근이 허가된다.

사용자가 자신의 워크스테이션에 root 접근만 할 수 있으면, 유닉스 시스템 네트웍 상에서는 표준 유닉스 인증 기법들 (telnet, ftp, "r"commands, NIS) 을 속이기가 쉽다.

유닉스 계정: 일반적 지침

다음 지침들 중 대부분은 COPS, TAMU Tiger, ESM 그리고 SecureMax 같은 유틸리티에 의해 테스트 된 것들이다:

• 정의되어 있는 패스워드 정책을 구현한다 (e.g. "정책" 장에 있는 것처럼). (aging/choosing/changing) 정책은 다음과 같은 proactive 메카니즘으로 적용할 수 있다:

Solaris 2: /etc/default/passwd, /etc/shadow, 명령어 nispasswd, passwd, admintool
Solaris 1: passwd, yppasswd
HP-UX:  Trusted 모드에서,/tcb/files/auth/ 참조..
AIX:       /etc/security/login.cfg
다른 PD 유틸리티, proactive: npasswd, passwd+. reactive: COPS, 빈 패스워드나 안좋은 패스워드를 검사하는 스크립트 (crack 으로).

• 접근이 거의 필요하지 않은 사용자들에게는 제한 쉘 [restricted shell] (/usr/lib/rsh) 사용을 고려한다.
• 사용자들은 시스템에 로그인할 때 표시되는 "last login" 시간을 확인하도록 훈련되어야 한다.
• UID가 0인 계정이 있는지 시스템을 주기적으로 검사한다.
  awk -F: '{if ($3=="0") print $1}' /etc/passwd
• 패스워드가 없는 계정이 있는지 시스템을 검사한다, Solaris에서 "logins -p" 를 사용하거나:
  awk -F: '{if ($2=="") print $1}' /etc/passwd
• 추측하기 쉬운 패스워드들을 주기적으로 검사한다 (e.g. "crack" 을 통해).
• 각 사용자에 대해 .login, .logout, .cshrc, .profile, .xinitrc 파일들이 올바르게 구성되어 있어야 한다. 이들은 root나 소유주만이 쓰기 가능해야 한다. 가능하면 새로운 사용자들을 생성할 때 템플릿을 이용한다 (Solaris 2: /etc/skel 사용).
• Solaris 1: wheel 그룹을 이용하여 root 로 su 할 수 있는 사용자를 제한한다 (TBD: HP & AIX 에서 가능?).
• root의 디폴트 경로(path)나 관리자 계정의 경로에 "." (즉 현재 디렉토리)를 넣지 않는다.
• umask (파일 생성 사용허가 마스크) 는 가능한한 제한적으로 설정한다, 특히 관리자 계정에 대해. e.g. 민감한 계정에 대해 077 (그룹이나 모든사용자 접근 없음) 그리고 일반 사용자에 대해 027 (그룹 읽기, 모든사용자 접근 없음).

다음은 위에 언급한 도구들이 꼭 검사하지는 않는다:

• 새로운 계정은 패스워드 없이 생성되지 않아야 한다.
• su 를 사용할 때, 절대경로를 사용한다 - 디폴트 경로에 의존하지 않는다, 즉 /bin/su 로 쓴다.
• 사용자 데이타베이스는 주기적으로 인사 기록과 대조하여 검사해야 한다.
• 사용자들에게 로그인시 last login 메시지를 확인할 것을 일깨워준다.
• 시스템 계정들은 (e.g. uucp, bin, adm, lp, listen, noaccess, audit, sys, ftp, nobody, daemon, news, sync) 패스워드 필드에 "*" (Solaris 1) 또는 in /etc/shadow 에서 "NP"를 (Solaris 2) 가져야 하며 쉘은 /bin/false 로 설정되어야 한다 (uucp 만 빼고).
• Solaris 1: shadow 패스워드 파일을 설치한다 (e.g. Sun C2 소프트웨어나 John F.Haugh 의 login,passwd 에 대한 공개 대체 라이브러리를 통해. 이 유틸리티를 구하려면, Tarchie를 사용하여 shadow 를 검색한다). 둘다 저자가 테스트해보진 않았다.
• HP-UX : shadow 패스워드를 사용한다.
• 어떤 리눅스 버전들과 AIX 에는 로그인 프로그램에 인증을 사용하지 않도록 하는 "-f" 옵션이 있어서, 어떤 사용자든 /bin/login -f root 명령어로 root 가 될 수 있게 해준다. 이것이 작동된다면, 새로운 버전으로 업그레이드 하도록 한다.

NIS

• 가능하면 NIS보다는 NIS+를 사용한다, NIS 서버로부터 패스워드 파일을 얻기는 매우 쉽다. NIS는 또 서버에서 패스워드 shadowing 을 무력화한다 (사용할 수 있다 하더라도).
• 가장 최근의 NIS 패치를 설치한다 ( "변경/릴리즈 관리" 절 참조).
• /var/yp/securenets 을 사용하여 도메인 스푸핑을 방지한다. 이것은 특별한 버전의 ypserv를 필요로 한다 (Solaris 1에서는 패치 100482 가 필요). ypx 도구도 참조한다.
• /etc/passwd 에서 "+" 나 "+@" 로 시작하는 모든 항목의 패스워드 필드가 "*" 로 되어 있는지 확인단다. 이 항목들은 NIS 사용자나 사용자들의 netgroup 들이 시스템에 접근할 수 있게 해준다. "+" 만 있는 줄은 모든 NIS 사용자들이 시스템에 접근할 수 있게 한다. 비슷하게 -name 또는 -@ 으로 된 항목들은 특정 사용자나 사용자들의 그룹에 대해 접근을 거부한다.
• "+" 와 "-" 항목은 /etc/group 에 사용되어 NIS 그룹 인식을 허용/거부할 수도 있다
• "+" 와 "-" 항목은 또 /etc/hosts.equiv 에 쓰일 수도 있는데, "+" 는 NIS 그룹들의 모든 멤버가 신뢰되는 것을 의미하고, "+@group1" 또는 -"@group1" 은 group1의 모든 멤버들이 신뢰된다는/신뢰되지 않는다는 것을 의미한다.
• rpc.ypupdated 가 keyserv 와 함께 사용될 때 중대한 보안 결함이 존재한다[12]. 할 수 있는 유일한 방법은 ('95 .11.28) rpc.ypupdated 를 사용하지 않는것이다!
• 덜 안전한 네트웍에 대해 패킷 필터를 가지고 있는 네트웍에서만 NIS 를 사용한다.
• NIS 슬레이브 마스터는 패스워드 정보에 NIS를 사용하면 안된다.
• Solaris 2 클라이언트: 브로드캐스트보다는 서버 목록을 사용하여 연결을 맺는다 (bind). ypinit -c 참조.
• Solaris 1 클라이언트: /etc/passwd 에 NIS 서버 이름을 지정한다, 즉 +::-:0  대신 +server[13]

NIS +

• Solaris 2.x: 가장 최신의 NIS+ 점보 패치를 설치한다.
• 레벨 2 보안을 사용한다.
• NIS 호환 모드는 피한다.
• 고 가용성: 복제 (replica) 서버를 설치하고, NIS+ 마스터 서버들에서 /var/nis 를 최소한 매일 백업한다. Cron 작업으로 간단한 tar 파일을 생성할 수도 있다. (e.g. tar cf - /var/nis | compress > /opt/backup/nis.tar.Z).
• 테이블 소유권/사용허가를 주기적으로 검사한다 (e.g. nisls -l TABLE_NAME or niscat -o TABLE_NAME 를 사용하여).
• nisls -l
  org_dir.gdv023.vptt.ch.:
  T ----rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 16:59:50 1995 passwd
  T ----rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 16:59:51 1995 group
  T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 16:59:52 1995 auto_master
  T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 16:59:52 1995 auto_home
  T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 16:59:53 1995 bootparams
  T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 16:59:54 1995 cred
  T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 16:59:55 1995 ethers
  T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 16:59:56 1995 hosts
  T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 16:59:56 1995 mail_aliases
  T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 16:59:57 1995 sendmailvars
  T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 16:59:58 1995 netmasks
  T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 16:59:59 1995 netgroup
  T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 17:00:00 1995 networks
  T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 17:00:00 1995 protocols
  T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 17:00:01 1995 rpc
  T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 17:00:02 1995 services
  T r---rmcdrmcdr--- gdv023.gdv023.vptt.ch. Thu Feb 23 17:00:03 1995 timezone

  Notes:

  1. 위의 사용허가 열(column)은 (왼쪽에서 오른쪽으로) nobody (인증되지 않은 사용자), owner, group, world (인증된 모든 사용자) 사용허가이다.
  2. 인증되지 않은 사용자들은 passwd 와 group 만 빼고 모두 읽을 수 있다. 이 두 테이블을 보호하는 것이 매우 중요하다.
  3. TBD: 패스워드 & 그룹 테이블에 대해 모든 사용자들의 읽기 접근이 정말 필요한가?
  4. auto_direct 테이블은 (직접 자동마운트 매핑을 위한) Solaris2.x 에서는 디폴트로 존재하지 않는다. 수작업으로 생성해야 한다 (nistbladm 을 써서).
  5. 위의 모든 테이블들은 그룹이 쓰기 가능하다. 다음은 각 테이블에 어떤 그룹이 할당되어 있는지를 보여준다:
     nisls -lg
     org_dir.gdv023.vptt.ch.:
     T ----rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 16:59:50 1995 passwd
     T ----rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 16:59:51 1995 group
     T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 16:59:52 1995 auto_master
     T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 16:59:52 1995 auto_home
     T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 16:59:53 1995 bootparams
     T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 16:59:54 1995 cred
     T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 16:59:55 1995 ethers
     T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 16:59:56 1995 hosts
     T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 16:59:56 1995 mail_aliases
     T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 16:59:57 1995 sendmailvars
     T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 16:59:58 1995 netmasks
     T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 16:59:59 1995 netgroup
     T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 17:00:00 1995 networks
     T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 17:00:00 1995 protocols
     T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 17:00:01 1995 rpc
     T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 17:00:02 1995 services
     T r---rmcdrmcdr--- admin.gdv023.vptt.ch. Thu Feb 23 17:00:03 1995 timezone
• admin 그룹에는 멤버를 신중히 할당한다. 이 그룹의 멤버들은 대부분의 NIS+ 테이블들을 변경할 수 있다. nisgrpadm -l admin. 을 써서 그룹 멤버들을 확인한다.
• 각 테이블은 열마다 같은 사용허가가 부여될 수 있게 허용한다. 예를 들어 패스워드 테이블의 열에 부여된 사용허가들을 검사하려면,
• niscat -o passwd.org_dir | egrep "Name|Access"
• 어떤 Solaris 2.5 NIS+ 설치에서의 사용허가는 안전하지 않다 (CERT Advisory CA-96.10 참조).
• 일반적으로 NIS+ 에서는, 모든 사용자들이 NIS+ 도메인 내의 모든 시스템들에 로그인할 수 있다. 이것은 항상 바람직한 것은 아니다, 예를 들어 일반 사용자는 DNS 서버에 로그온할 수 없어야 한다. 이것은 /etc/nsswitch.conf 에서 passwd 항목을 다음과 같이 설정하여 달성할 수 있다:

passwd: compat
passwd_compat: nisplus
group: compat
group _compat: nisplus

그러면 로그인이 허용될 각 사용자는 /etc/passwd와 /etc/shadow 에 다음과 같은 형태의 항목을 가지고 있어야 한다:

+fred:x:::::: /etc/passwd
+fred::::::: /etc/shadow

패스워드 대체

Passwd+, npasswd, Obvious 는 사용자의 패스워드 선택을 강화하는 공개도메인 유틸리티들이다. Passwd+ 와 npasswd 는 저작사 1994년 평가해 보았지만, 그때는 NIS+를 지원하지 않았었다. Npasswd 는 특히 확장과 확인이 쉬워보였다.

좋은 패스워드의 사용을 보장하기 위해 위 프로그램들 중 하나를 사용할 것을 고려한다.

DES 암호화된 스크립트

등급 시스템들에서는 그 스크립트를 소유주만이 읽을 수 있다고 하더라도, clear text 스크립트에 root 나 관리자 패스워드가 있어서는 안된다. 그러나 이런 스크립트들은 (예를들면) 데이타베이스 관리에 종종 필요하다. 한 가지 해법은 전체 스크립트를 암호화하고, 스크립트를 이동중에 (on-the-fly) 복호화 하는 변조된 쉘을 사용하여 암호화 되는 동안에 복호화한다.

• 이런 목적을 위한 유틸리티로 des, despasswd, descsh, deswrap 및 desscript 가 있다.

DNS:  Domain Name Service

대부분의 유닉스 변형들은 DNS 클라이언트(resolver 라는)와 DNS 서버를 모두 가지고 있다. 벤더 버전들은 오래돼서 문제가 있는 경향이 있다. (e.g. 캐쉬 오염 문제, 대량의 데이타를 리턴하는 도메인, 보안 등등..).

• ftp.isc.org/isc/bind/ 또는 www.isc.org/view.cgi?/products/BIND/index.phtml에서 가장 최신의 BIND (Berkeley Internet Name Server) 를 구해 사용하도록 한다. BIND 는 보다 많은 기능을 가지고 있고 (유닉스 벤더 버전보다), 디버그하기도 쉬우며 (dig로) 보안 문제가 발견됐을 때 업데이트도 빠르다.
• Hardening the BIND DNS Server (www.boran.com/security/sp/bind_hardening.html) 도 참조한다.
• 장애처리:
  • nslookup & dig 을 써서 서버 결과를 확인한다.
  • Solaris:
    • DNS 클라이언트쪽에 문제가 있을 경우 /etc/nsswitch.conf 와 /etc/resolv.conf 를 확인한다. Nslookup 을 "-d2" 옵션으로 시작하여 디버깅 정보를 얻는다.
    • Nscd 데몬을 kill 로 중단시켜 본다.
    • Sun의 옛날 /etc/named.boot 에서는 탭을 쓰지 말고 공백을 쓴다 (bind 는 named.conf 를 쓴다).
    • www.ebsinc.com/solaris/dns.html 을 참조한다.
  • Named 를 디버그 옵션 "-d" 로 시작하고 콘솔과 로그를 본다.
  • 일반적으로 로그는 syslog "daemon" 부분에서 볼 수 있다.
  • 네임 서버로부터 통계를 얻으려면, 다음과 같이 한다
         kill -ABRT `cat /etc/named.pid`
    이것은 통계정보를 /usr/tmp/named.stats 파일에 쓴다. ( 'DNS and BIND' 책 142-149 페이지 참조, from O'Reilly & Assoc. ).
  • 필자는 BIND가 죽는 문제가 있었다, monitor_processes.pl 같은 cron 스크립트를 돌려서 살아 있는지 확인한다.
  • Named 에 HUP 신호를 보내서, 설정 파일 변경 후 다시 읽게 한다.
        kill -HUP `cat /etc/named.pid`
• 감사/ 테스팅:
  • 활동중인 도메인을 테스트하는 훌륭한 도구로 www.uniplus.ch/direct/testtool/dnstest.html 이 있다
  • 샘플 도메인 swisscom.ch 에 대해 Swiss WHOIS 항목 확인하기:
    www.switch.ch/cgi-bin/info/whois?Query=sun.ch&Server=whois.nic.ch

도메인 등록 메모:

• The .CH 도메인은 웹을 통해 생성 및 변경한다, www.nic.ch/cgi-bin/preprocessor/register 참조. ~2주정도 걸린다.
• .com 도메인은 다르다:
  • 연락 "코드명[handles]"을 등록해야 한다, e.g. SB10345 는 Sean Boran을 가리킨다든지. 코드명을 변경하려면, 여기를 참조: http://rs.internic.net/cgi-bin/itts/handle 이들은 템플릿을 다운받고, 작성해서 이메일로 보내어 변경할 수 있다 (필자의 선호). 참조: http://rs.internic.net/help/templates.html
  • 일차 및 이차 DNS 서버의 호스트이름/IP 가 등록되어야하며 정확해야 한다. 이들은 템플릿을 다운받고, 작성해서 이메일로 보내어 변경할 수 있다. 참조: rs.internic.net/help/templates.html
  • 마지막으로 도메인 수정과 사용자/호스트 코드명(핸들) 변경은 여기서 할 수 있다: rs.internic.net/cgi-bin/domain 이들은 템플릿을 다운받고, 작성해서 이메일로 보내어 변경할 수 있다. 참조: http://rs.internic.net/help/templates.html

  .COM 변경은 일단 요령만 알게되면 사실 아주 빠르고 쉽다. 변경은 재개 24 또는 48시간 이내에 완료된다.

감사 증적

시스템 변경사항 감시

파일시스템 사용허가와 체크섬이 무엇이어야 하는지 알아야 한다, 이 사용허가들을 설정하고, 스냅샷을 취해 읽기 전용으로 만든다. 주기적으로 스냅샷을 다시 만들어 원본과 비교하여 변경되었는지 확인한다. 시스템은 자동적으로 사용허가를 재설정 해야한다.

• Tripwire는 공개도메인 유틸리티로 많은 플랫폼에서 돌아간다. 파일 변경을 탐지하는 몇개의 안전한 해싱 알고리듬을 가지고 있다.
• 예를 들어, tripwire 를 사용하여 시스템에서 스냅샷을 취한 후, 스냅샷이 제대로 된 것 같은지 검사한다. 그런다음 스냅샷을 읽기전용 매체에 복사한다 (또는 다른 시스템에 복사하여 NFS를 통해 읽기 전용으로 마운트). 그다음에 주기적으로 tripwire 를 돌려 (e.g. 매주 또는 매일), 스냅샷을 생성하여 읽기전용 마스터와 비교한다.
• 또는, SSH 와 .shosts 를 구성, 사용하여 원격 명령어가 대상 시스템에서 안전하게 실행되도록 한다. 대상이 검사되어야 할 때마다, tripwire 파일들과 스냅샷 데이타베이스를 대상 시스템에 복사 하고, tripwire를 돌리고, 결과를 업로드하고 대상시스템에서는 tripwire의 모든 흔적을 없앤다. 이것은 공격자로 하여금 대상호스트가 감시되고 있다는 것을 알기 힘들게 한다.
• Solaris 2 에는 ASET 유틸리티가 있어서, 시스템 변경사항이나 취약한 구성을 조사할 수 있게 해준다. 하지만 저자는 tripwire 를 선호한다.
• rdist 유틸리티는 시스템들간에 파일을 배포하고 동기화 하는 데 사용될 수 있다. 이것은 파일이 변경되었는지 보고하기도 하고 올바른 값으로 다시 되돌리기도 하여, 보안 관점에서 볼 때 흥미롭다. 물론 rdist 는 안전하게 사용되려면 신중하게 구성해야 한다 (e.g. 공개 도메인 6.2 나 이후 버전으로, rsh가 아닌 SSH로 사용).
• Securemax (from OpenVision), ESM (from Raxco) 같은 다른 상용 유틸리티들도 그 가치를 입증했다. 둘다 GUI 를 가지고 있어, 처음 사용을 쉽게 한다.

감사

감사는 보안 관련 이벤트들을 감시하고, 이 이벤트들을 감사 증적에 기록하고 이러한 감사 이벤트들을 보고 및 분석하는 것이다. 감사는 사용자의 action 들을 시스템 오용에 대한 탐지 관점에서 감시할 수 있게 해주어야 한다. 감사 도구들은 시스템 로깅 도구들 (시스템 에러를 표시하고 시스템 관리 문제 해결을 돕는) 과는 다르다.

Sun Shield / BSM

Sun 은 SunOS (Sunshield) 와 Solaris (Sunshield BSM) 에 대해 모두 "C2" 레벨 감사 시스템을 제공한다. Solaris 2 에 번들로 들어있다. Solaris 2.4 BSM 을 여기서 논의한다. BSM은 지정된 사용자들의 행위(action)를 기록하고 감사파일에 쓸 수 있게 해준다. 그러나, 감사가 시스템 호출 레벨에서 이루어지므로, 사용자의 단순한 행위에 의해서도 거대한 로그가 발생될 수 있다. 성능도 영향을 받는다. 표준 분석도구인 praudit 와 auditreduce 는 높은 수준의 감사증적을 제공하지 않는다. 어플리케이션들도 감사증적에 쓸 수 있다.

참고문서: "SunSHIELD Basic Security Module Guide" (표준 Solaris 2.x 문서). Man 페이지: audit(1m), audit_startup(1m), audit_warn(1m), auditconfig(1m), auditreduce(1m), bsmconv(1m).

• 아주 최소한의 사용자 행위만을 감사한다.
• 로그를 해석할 수 있는 시스템 전문가가 없으면 감사를 건드리지 않도록 한다!
• 감사를 활성화 하는 경우, 실시간으로 감사증적을 분석하는 스크립트를 작성하여 필요할 때 경고를 발생시킨다.
• 감사증적의 분석은 syslog 나 다른 시스템을 분석하는 기존 프로세스를 참작해야 한다.
• 파일 이름에 따라 파일 접근을 감사하는 방법은 없다. 가령 /etc/passwd 에 대한 모든 쓰기 시도 같은 것은 간단하게 감사될 수 없다. 상위레벨에서 사용자 행위를 추적하는 것도 불가능하다.
• 감사증적은 반드시 충분한 공간이 있는 파티션에 저장되도록 하고, 여러 시스템의 감사증적을 secure NFS 와 auditreduce 중앙집중화 할 것을 고려해 본다.

Solaris C2/BSM 보안 메모 (www.boran.com/security/sp/Solaris_bsm.html) 도 참조한다.

로그 파일

주기적으로 로그를 검사하는 시스템 관리자는 시스템이 어떻게 기능하는지에 대해 많이 배우게 되고, 보다 적은 중단시간을 보장할 수 있으며, 동시에 보안 침해 발생시 이를 감지할 수 있다, 특히 경고(alerts)를 사용할 경우. 로그를 감시하는 일을 따분한 작업으로 여겨서는 안되며, 시스템의 내부를 이해하는 좋은 기회로 생각해야 한다!

유닉스 시스템에는, 다양한 로깅 정보들이 있으며, 대부분은 /var 파티션에 보관된다. 이 로그들은 감시되어야 한다.

• Syslog: 는 대부분의 유닉스 시스템에서 널리 사용되는 중앙화된 로깅 서비스이다 (다음 절을 참조). Syslog 는 설정에 따라 로그 데이타를 /var/adm/messages 나 /var/adm/syslog 또는 /var/log 저장한다.
• Process accounting (/var/adm/acct, pacct*): 대부분의 유닉스 시스템들이 accounting을 제공하지만, 대부분 디폴트로 비활성화되어 있다. Accounting 은 성능을 어느정도 저하시킨다. 아래의 accounting 절을 참조한다.
• 감사증적: 위의 감사 절을 참조한다.
• utmp 와 utmpx: 누가 로그인했는지에 대한 로그는 utmp 에 보관되며, 보통 /var/adm, /etc 또는 /usr/adm 에 있다. SunOS는 utmpx 가 없다.
• wtmp 와 wtmpx: 로그인, 로그아웃, 재부팅 로그는 이 파일에 보관된다. 이들은 시스템 accounting 에도 사용된다 (Solaris 에서). 이들은 accounting 이 활성화되면 자동적으로 다듬어지며(trimmed), 그렇지 않으면 연말직전에 다듬어지도록 하는 cron 항목이 생성되어야 한다 (디스크 공간이 충분하다면). wtrim.pl 유틸리티가 이 작업에는 완벽하다. wtmp 를 검사하는데에는 보통 last 명령어가 사용되지만, finger, users, whodo, w 와 who 명령어들도 이 파일에 접근하여 정보를 얻는다. SunOS에는 wtmpx 가 없다.
  => 숙련된 공격자들은 utmp 나 tmp에서 자기의 흔적을 지울 수 있는 스크립트를 가지고 있을 수 있으므로, 여기에 너무 의존하지 말도록 한다.
• /var/adm/lastlog 이진(binary)파일은 사용자가 마지막으로 로그인한 게 언젠지에 대한 로그를 가지고 있으며 사용자가 로그인할 때 표시된다.
• 공개 도메인 유틸리티인 wu-ftp 는 디폴트로 /var/adm/xferlog 에 로그를 남긴다.
• Solaris 에서 서비스에 특정적인 로그:
• /etc/default/su 에서 SULOG 가 정의되어 있으면 su 명령어의 모든 사용자들의 로그가 /var/adm/sulog 에 보관될 수 있다, 하지만 모든 su 시도는 Syslog 에도 기록되기 때문에 (/etc/default/su 에서 SYSLOG=yes인 경우) 이것은 거의 필요가 없다.
• /etc/default/su 에서 CONSOL 옵션이 설정되어 있으면 su 를 사용하려는 모든 시도가 콘솔에 기록된다. 권장.
• 실패한 로그인 시도에 대한 로그는 /var/adm/loginlog 파일이 존재하고 root에 속하며 root만 쓸 수 있을 때 이 파일에 보관된다. 권장.
• PPP 가 설치되어 있을 때 PPP activity 는 /var/adm/log/asppp.log 에 로그된다.
• /etc/default/cron에서 CRONLOG=Yes 일 때 모든 cron activity 는 /var/cron/log 에 로그된다. 그러나 syslog를 통한 cron 로깅도 가능하고, 여러 시스템들에 대한 로그를 중앙화 할 수 있으므로 더 낫다.
• 볼륨 매니저 volume manager (플로피 & CD-ROM 드라이브에 대한 접근을 관리) 는 /var/adm/vold.log 에 activity를 로그한다. 문제 진단에 유용하다.
• /var/adm/aculog: 모뎀 activity 의 기록 (uucp 와 tip), 별로 쓸모있진 않다.
• uucp 는 /var/uucp/.log 에 로그한다.
• /var/adm/sa/*: sar 성능감시.
• 프린터 로그는/var/lp/logs/{lpNet,lpsched,requests} 에 보관된다. 이 파일들은 문제 진단에 유용하다.
• NIS+ 는 트랜잭션 로그를 /var/nis/trans.log 에 기록한다.
• 진단 도구 sundiag 은 로그를 /var/adm/sundiaglog/sundiag.err 에 한다.
• BSM 감사 로그는 /etc/security/audit 에 저장된다.
• Accounting 파일들은 /var/adm/acct 에 보관된다.
• 어플리케이션: 많은 어플리케이션들이 Syslog 를 쓰지 않고, 자체적으로 로그를 생성한다.
• Firewall-1 은 /var/opt/SUNWfw/log/fw.log로 로그한다.
• Sun NetManager 로그는 /var/opt/snm/event.log 이다.
• TIS firewall proxies, SSH 및 tcp wrappers 는 syslog 에 로그한다 (보통 데몬 부분에).

일반적인 권고사항:

• 로그는 root 나 /etc 또는 /usr 가 아니라 /var 에 저장한다. /var 를 위해 (큰) 별도의 파티션을 생성하여, 꽉 차더라도 중대한 문제를 발생시키지 않도록 한다. Solaris 2 환경에서 /var 는 소프트링크 (softlink) 될 수 없다는 것에 유의한다.
• 로그는 주기적으로 가지치기 (쓸데없는 것 버리기) 하고 보관 (archive) 되어야 한다. 많은 시스템들이 자동으로 일부 로그를 가지치기 하고 삭제하긴 하지만, 일관성 있는 방법으로 모든 로그에 대해하는 경우는 거의 없다. 예를 들어, 매주 일요일 로그파일들은 이동되고, 압축되어 백업된다. 7주 후 암축된 로그는 디스크에서 삭제된다. 이런 목적을 위한 단순하지만 강력한 공개 도메인 유틸리티가 rotate_log 이다. rotate_log 를 위한 cron 항목의 예제는 부록 D 에서 찾을 수 있다.
• 비일상적인 시간의 로그인에 대해 로그인 로그를 모니터한다 (last 명령어 이용). (가령 밤중에 - logins_today.plin 부록 D 참조).
• 부록 D 에서, syslog 파일들인 alertlog, authlog 및 daemonlog 에 대해 이상한 항목들을 감시하는 스크립트 monitor_auth.pl 이 제공된다.

Syslog

Syslog 는 중앙화된 로깅 유틸리티도 대부분의 유닉스 시스템에서 널리 사용되며 8개의 우선순위와 18개 facilities를 제공한다. Syslog의 주 사용자는 kernel, news, uucp, sendmail 그리고 login 서비스들이다.logger 유틸리티를 사용하여 스크립트로 syslog 에 메시지를 보내거나 syslog를 테스트 할 수 있다. Syslog 데몬은 syslogd라고 한다.

AIX: AIX 에서 syslogd 가 지원되긴 하지만, 어떤 시스템 유틸리티도 여기에다 보고를 하지 않기 때문에 무용지물이다!

보안 버그 (1996년 1월): 8lgm 보안 메일링 리스트에서 syslog 에서 문자열 처리와 관련한 심각한 문제를 발견하였다. 이들은 1995년 6월에 발견되었다. 이 문제는 현재 sendmail에서 이용되고 있다. Sun과 마찬가지로 HP는 패치를 발표하였다, HP 패치 서버로부터 (패치에 대한 절 "변경/릴리즈 관리" 참조) 보안 공시 HPSBUX9602-029 를 구하도록 한다. (Solaris 2.5 에서는 이 fix가 통합되어 있다).

대부분의 유닉스 시스템에서 Syslog는 몇가지 흥미로운 가능성을 제공한다:

• 사용자 로그인이 없는 별도의 (보다 안전한) 시스템에 서버 로그들을 집중시킨다.
• 모든 서버들의 콘솔 메시지가 관리자 콘솔에 표시될 수 있다.
• 에러메시지는 파일에 쓸 수 있고, 이메일로 보낼 수 있고, 콘솔에 쓰거나 모든 단말에 뿌려질 수도 있다.
• 에러 메시지에 우선순위를 할당한다.
• /etc/syslog.conf 를 구성하여 서비스별로 메시지를 분리시킨다. syslogd 클라이언트와 로그 콘솔 모두에서 사용될 수 있는 (SunOS & Solaris 에서) syslog.conf 의 예제가 Appendix D에서 제공된다. 이 예제에서, authlog 라는 인가 메시지를 위한 별도의 로그가 생성된다. 이 로그에서의 변경사항은 매일 점검해야 한다 (부록 D 에서 예제 스크립트 monitor_auth.pl을 참조).
• 디버깅은 재미있을 수 있다, 위에 언급한 구성 파일에서 헤더를 한번 보라.
• Syslog 서버에 공간이 많으면 inetd 로깅을 활성화한다 (Solaris 2 에서 /etc/init.d/inetsvc에 있는 inetd 명령줄에 -t 옵션을 추가). rpc.cmsd (달력 관리자) 같은 말썽꾸러기 데몬들이 잘못 동작하면 로깅 볼륨이 거대해질 수 있다!

조심!

• Syslog 는 UDP를 사용하므로, 배달이 보장되지 않는다, 따라서 등급 시스템에서 중요도(우선순위)가 높은 메시지들은 로컬 사본의 보관을 고려한다.
• 누구나 syslog 서버에 항목들(entiries)을 보낼 수 있으므로, 잘못된 항목에 주의한다!

Process Accounting

Accounting 소프트웨어는 사용자들이 시스템 사용량에 대해 얼마를 내야 하는지를 작업하는데 쓸 수 있는 도구모음이다. 보안 관점에서 볼 때 이것은 누가 시스템을 사용하고 있으며 어떤 명령어들이 사용되고 있는지를 보고하기 때문에 흥미롭다.

Solaris Accounting

명령어들은 /usr/lib/acct 에 있고, 보고서들은 /var/adm/acct/fiscal/fiscrptMM (숫자) 및 /var/adm/acct/sum/rprtMMDD (사용자 요약 보고서) 에 있다.

• "일간" 보다는 "주간" 보고서 생성을 권고한다. 이것은 필요한 디스크 공간을 증가시키지만, 어떤 사람이 실제로 보고서를 읽을 가능성도 훨씬 더 높인다!
• 설치:

ln /etc/init.d/acct /etc/rc2.d/S22acct
ln /etc/init.d/acct /etc/rc0.d/K22acct
sh /etc/rc2.d/S22acct start

crontab -e adm
# Check /var/adm/pacct size:
0 * * * * /usr/lib/acct/ckpacct
# Create weekly report:
0 2 * * 0 /usr/lib/acct/runacct 2> /var/adm/acct/nite/fd2log
# Create monthly accounting summary:
0 7 1 * * /usr/lib/acct/monacct

crontab -e root
0 22 * * 4 /usr/lib/acct/dodisk

vi /etc/acct/holidays [set your local holidays]

두가지 주요 보고서가 만들어지는데, 명령어 사용을 보여주는 일간 보고서와 사용자당 시스템 사용량을 보여주는 월간 보고서이다. 다음은 전형적인 일일 명령어 요약에서 추출한 것이다:

TOTAL COMMAND SUMMARY
COMD. NUM. TOTAL TOTAL TOTAL MEAN MEAN HOG CHARS BLOCKS
NAME CMDS K-MIN CPU-MIN REAL-MIN SIZE-K CPU-MIN FACTOR TRNSFD READ
sh 1082 85.98 0.57 183.20 149.67 0.00 0.00 218296 14
lpstat 886 84.49 0.53 3.08 159.36 0.00 0.17 749192 1
uname 682 39.38 0.38 0.43 103.64 0.00 0.89 3964 4
hostname 194 14.49 0.15 0.30 96.82 0.00 0.49 98552 1
sed 209 14.01 0.17 0.38 84.82 0.00 0.43 407197 0
ssh 71 12.26 0.54 41.66 22.85 0.01 0.01 2539679 87
csh 99 12.10 0.48 1.51 25.15 0.00 0.32 744715 94
sendmail 46 10.30 0.15 0.65 67.25 0.00 0.24 10724864 297

TOTALS 4300 364.04 14.61 12068.92 24.91 0.00 0.00 1626266848 21308

월간 보고서는 이렇게 생겼다:

2 date changes
28 system boot
2 run-level 6
2 run-level 3
1 runacct
1 acctcon

LOGIN CPU KCORE CONNECT DISK # OF # OF # DISK FEE
UID NAME PRIME NPRIME PRIME NPRIME PRIME NPRIME BLOCKS PROCS SESS SAMPLES
MINS
0 root 0 9 16 205 9 133 0 2453 79 0 0
4 adm 0 0 1 0 0 0 0 13 0 0 0
71 lp 0 0 0 1 0 0 0 24 0 0 0
200 ftp 0 0 0 0 3094 5040 0 0 6 0 0
315 boran 2 3 165 15 10298 25740 0 1810 24 0 0
TOTAL 2 12 182 221 13401 30913 0 4300 109 0 0

어떤 사용자들이 어떤 명령어를 사용하고 있는지에 대한 주기적인 보고를 한다면 멋질 것이다. 이것은 표준 보고서에서는 할 수 없지만 lastcomm 명령어는 마지막 accounting 갱신 이후 (e.g. 매주 또는 매일) 어떤 특정사용자가 어떤 명령어들을 마지막으로 실행했는지를 보여준다. 관리자는 Lastcomm 을 사용하여 사용자의 행위를 감시할 수 있지만, 공격자도 역시 이를 사용하여 관리자의 행위들을 감시할 수 있다 (어떤 사용자든지 lastcomm을 실행할 수 있으므로). 따라서:

• Accounting 파일들은 root 만 사용할 수 있게 하여, 공격자 (아직 root가 아닌) 가 이를 사용하여 root를 감시할 수 없게 만든다:
  chmod og-rwx /var/adm/pacct*
• 관리자들에게만 accounting 보고서와 파일 접근을 허용한다:
  chmod -R o-rwx /var/adm/acct
• 명령어는 사용자, 프로세스 이름, 또는 단말에 따라 검사할 수 있다. e.g.:
  lastcomm billyjoe
  lastcomm netscape
  lastcomm pts/27

[11] 시스템들간에 패스워드가 동기화 된다면, 가장 취약한 시스템이 보안 수준을 결정짓는다.
[12] "Avalon Security Research" 에서 이 결함들의 상세내용과 이를 이용할 수 있는 스크립트들을 ("slammer") 인터넷에 공개했다 ('95 년 11월).
[13] 자동으로 /etc/.rootkey 를 발생시키기 위한 유틸리티가 저자에게 있다.
[14] 이를 위해서는 스크립트가 필요하다, 표준 유틸리티는 없다.
[15] "Avalon Security Research" 에서 이 결함들의 상세내용과 이를 이용할 수 있는 스크립트들을 ("slammer") 인터넷에 공개했다 ('95 년 11월).
[16] 예제 명령어들은 Solaris 2.4 용이다.

            Previous   Next   Top   Detailed TOC  IT Security Cookbook, 04 December, 2000