수안이의 컴퓨터 연구실
여러 가지 설정으로 공격으로부터 시스템을 안전하게 지키는 방법
난이도 : 초급
Mario Eberlein, IT 아키텍트, IBM Global Services
Rene Auberger, 소프트웨어 IT 아키텍트, IBM Software Group
Wolfram Andreas Richter, IT Architect, IBM Software Group
2005년 4 월 14 일
공격에 대한 저항력이 강한 리눅스 시스템을 만드는 기술을 배워보자. 부트 프로세스와 로컬 파일시스템 보안, 서비스와 데몬 잠금, 할당량과 한계 적용, Mandatory Access Control 실행, 새로운 소프트웨어로 보안을 업데이트 할 때 발생할 수 있는 보안 취약성 인식 등을 다룬다. Part 1에서는 보안 개념과 잠재적 위험을 Part 2에서는 보안 설치를 계획할 때 고려해야 할 사항들을 설명한다.
이 시리즈를 통해서, 리눅스를 실행하는 시스템의 계획 수립, 디자인, 설치, 설정, 관리 방법을 설명한다. 보안 개념, 설치 문제, 잠재적 위협과 남용 등에 대한 이론적인 설명 외에도 리눅스 시스템의 보안과 하드닝 등 실용적인 방법도 제시한다. 최소한의 설치, 리눅스 설치 하드닝, 권한/인증, 로컬 및 네트워크 보안, 공격과 방어 방법, 데이터 보안, 바이러스, 악성 프로그램 등을 논할 것이다.
Part 1은 보안 개념과 잠재적 위협에 대한 문제로 시작한다. Part 2에서는 보안 설치를 계획할 때 고려해야 할 사항들을 설명한다. 상세한 액션 플랜도 포함된다.
이번 시간에는 리눅스 하드닝 단계를 설명하겠다.
하드닝(hardening)에 대하여
성공적인 하드닝을 위해서는 다음과 같이 해야 한다:
공격을 피하기 위해서 시스템이 네트워크로 연결되기 전에 하드닝을 수행한다.
최소 권한 모델(least-privilege model)설정:시스템은 해당 기능에 필요한 정도로만 액세스를 허용해야 한다. 마찬가지로, 사용자들은 최소한의 접근 권한만 가져야 한다..
사전 플래닝과 준비를 완료하고 최소한의 설치(Part 2 참조)를 마친 후에는 여러 가지 설정 단계들을 고려해야 한다. 다음 단계는 리눅스 하드닝에 일반적으로 참조된다:
부트(boot) 프로세스 보안
서비스와 데몬 보안
로컬 파일시스템 보안
할당량과 한계 적용
Mandatory Access Control 실행
보안 패치 업데이트 및 추가
부트(boot) 프로세스 보안
부트 로더(LILO 또는 Grub)를 설정하여 부팅 시 어떤 사용자의 개입도 허용되지 않도록 한다. 다시 말해서, 사용자가 부트 프롬프트에서 커널 매개변수를 패스하지 못하도록 한다. (원격 데이터센터 같은 곳에서) 원격 재부팅을 수행하는 것이 아닌 이상 패스워드를 넣도록 설정한다. 이는 머신에 물리적으로 접근하는 사람들에게 주는 사전 경고이다. 루트 쉘을 얻기 위해 single 또는 init=/bin/sh를 이용하는 부팅을 방지한다. (하드 드라이브를 제거하거나 다른 시스템에 하드 드라이브를 마운트 하는 등의) 추가적인 시도를 하면, 파일 시스템을 암호화 하지 않은 한 쉽게 피할 수 있다.
LILO의 경우 매개변수 prompt를 설정 파일(일반적으로 /etc에 있음)에 있는 password로 대체시켜라. Grub의 경우, 관련 매개변수는 Grub 설정 파일(/boot/grub/grub/conf)에 있는 hiddenmenu, default 0, password이다.
실행 레벨 설정에는 sp:S:respawn:/sbin/sulogin을 /etc/inittab에 추가하여 단일 사용자 모드로 전환할 때 루트 패스워드가 필요하다.
사용자가 Ctrl-Alt-Del을 사용하여 재부팅을 하지 못하도록 한다: ctrlaltdel주석을 달아 /etc/inittab에 ctrlaltdel 엔트리가 실행되지 못하도록 한다. #ca::ctrlaltdel:/sbin/shutdown -t5 -rf now 처럼 해시(#) 표시를 추가하여 키 조합을 이용한 재부팅을 방지할 수 있다.
서비스와 데몬 보안
서비스의 보안 설정의 첫 단계는 필요하지 않는 모든 서비스들을 실행불가 상태로 만드는 것이다. 제공되지 않는 서비스들은 침입자들이 악용할 수 없기 때문에 위험을 줄일 수 있다.
모든 실행 가능한 서비스들을 감추려면 여러 위치를 검사하면 된다. 불안정한 서비스들의 기능을 억제하고 보다 안전한 옵션으로 대체한다. 예를 들어, telnet은 암호화 되지 않기 때문에 암호화된 ssh 서비스를 사용한다. (Part 2 참조)
서비스 보안을 위해서는 다음 요소들을 고려해야 한다:
/etc/inittab
/etc/init.d의 부트 스크립트
inetd/xinetd 데몬
TCP 래퍼
방화벽
/etc/inittab
부트 프로세스 동안 init 프로세스는 /etc/inittab 파일에 있는 엔트리들을 읽는다. 라인 당 한 개씩 있는 각 엔트리는 특정 상황에서 어떤 프로그램이 실행될 것인지를 정의한다. 그와 같은 프로그램은 서비스 그 자체 이거나 서비스를 시작 및 종료하는데 사용된다.
init 프로세스는 하나의 문자로 구별된 여러 상태들(소위 말해 실행 레벨(run level), 을 구별한다. 실행 레벨이 나타나거나 (전원 오류 같은) 특정 이벤트가 발생하면 엔트리들은 평가되고 해당 명령어들이 실행된다.
/etc/inittab에 있는 엔트리 포맷은 이 엔트리용 레이블이고, 엔트리가 처리되는 실행 레벨,그 다음에는 액션 키워드, 명령행 매개변수를 포함하여 실행될 명령어 순으로 된다. 이 모든 필드는 콜론으로 구별되며 전형적인 엔트리는 다음과 같다:
my_service:35:once:/usr/local/bin/my_service someparameter
(inittab의 맨 페이지(man-page)에서 액션 키워드의 리스트를 참조하라.)
이 예제에서, 이 엔트리의 레이블은 my_service이다. 실행 레벨3 또는 5가 되면 매개변수 someparameter를 가진 /usr/local/bin/my_service 프로그램이 실행된다. 일단 프로그램이 종료되면 다시 시작되지 않는다. (액션 키워드 “once”)
안전한 리눅스 시스템을 위해 /etc/inittab의 모든 엔트리 기능을 이해해야 하며, 엔트리를 삭제하거나 라인 앞에 해시 사인을 사용하여 주석을 달아 원치 않는 서비스 기능을 없앤다.
모든 리눅스 시스템에 공통적인 두 가지 유형의 엔트리가 있다. 하나는 /sbin/getty 라고 하는 프로그램을 시작하는데 사용된다. 이것은 리눅스 가상 콘솔이나 시리얼 라인상에서 로그인을 허용하는데 사용된다. 또 다른 유형은 매개 변수로서 현재 실행 레벨을 갖고 있는 /etc/rc.d 디렉토리의 rc 라는 스크립트를 시작한다. 이 스크립트는 서비스의 시작과 종료를 제어한다. (다음에 설명하겠다.)
/etc/init.d의 부트 스크립트
/etc/init.d에 있는 부트 스크립트는 시스템 서비스를 시작 및 정지하는데 사용된다. 각 실행 레벨의 경우 실행 레벨 변경 시 호출될 부트 스크립트로의 소프트 링크가 포함되어 있는 /etc/rcN.d 디렉토리가 있다. (“N”은 실행 레벨을 나타낸다.)
링크 이름이 “S”로 시작한다면 이 스크립트는 상응하는 서비스를 시작하기 위해 실행 레벨을 입력할 때 실행된다; “K”로 시작하면 서비스 중지를 위해 실행 레벨을 종료할 때 스크립트가 실행된다.
대부분, 부트 스크립트의 이름을 보면 어떤 서비스가 제어되는지 알 수 있다. 서비스가 특정 실행 레벨에서 시작되지 않도록 하려면 실행 레벨 하위 디렉토리에서 상응하는 부트 스크립트 까지의 링크를 삭제하고 아무것도 수행하지 않는 더미 스크립트로 /etc/init.d에 있는 원래 부트 스크립트로 대체한다.
inetd/xinetd 데몬
클라이언트가 요청하면 서비스들은 호출될 수 있다. 이 요청들은 수퍼 데몬인 inetd 또는 xinetd로 간다. 수퍼 데몬은 어떤 서비스를 시작할 것인지를 결정하고 요청을 상응하는 데몬에 보낸다. 일반적으로 telnet, ftp, rlogin 같은 서비스들은 inetd 또는 xinetd를 사용하여 시작된다.
inetd 데몬은 에서 설정된다. 여기에는 수퍼 데몬에서 제공하는 각 서비스에 대한 엔트리가 포함된다. FTP 서버를 설정하는 엔트리는 ftp stream tcp nowait root /usr/bin/ftpd in.ftpd -el과 같다. 그리고 마찬가지로 해시 사인을 사용하여 주석을 달아 기능을 못하도록 한다.
보안을 위해 xinetd를 사용하라. inetd와 달리 xinetd는 rpc 기반 서비스들을 시작할 수 있고 액세스 제어도 제공한다. xinetd는 인커밍 커넥션의 비율, 특정 호스트로 부터의 인커밍 커넥션의 수, 한 서비스를 위한 총 커넥션의 수 등을 제한할 수 있다.
xinetd는 각 하위 데몬에 대한 개별 설정 파일에 의해 설정된다. 이 파일들은 /etc/xinetd.d/에 위치해 있다. 위 FTP 서버용 설정 파일 예제는 /etc/xinetd.d/ftp 일 것이고 다음과 같다:
Listing 1. 설정 파일, /etc/xinetd.d/ftp
service ftp
{
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/bin/ftpd
server_args = -el
disable = yes
}
서비스 기능을 없애려면 disable 매개변수를 이전 예제에서 yes로 설정한다.
보다 세련된 액세스 제어를 위해 xinetd는 다음 세 개의 매개변수들을 지원한다:
only_from
no_access
access_time
ftp 데몬 기능을 완전히 억제하지 않고 액세스만 제한하려면 다음과 같이 /etc/xinetd.d/ftp config 파일을 변경하면 된다:
Listing 2. 액세스를 제한하도록 변경된 /etc/xinetd.d/ftp 설정 파일
service ftp
{
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/bin/ftpd
server_args = -el
disable = no
only-from = 192.168.200.3 192.168.200.7 192.168.200.9
only-from += 192.168.200.10 192.168.200.12 172.16.0.0
no_access = 172.16.{1,2,3,10}
access_times = 07:00-21:00
}
only-from과 no_access는 숫자로 된 IP 주소(맨 오른쪽에 있는 0은 와일드카드로 간주됨), IP 주소/넷마스크 범위, 호스트 네임, /etc/networks의 네트워크 이름을 허용한다. only-from과 no_access의 조합이 사용되면 xinetd는 각 호스트 연결과 가장 근접한 매치를 찾는다.
이전 코드 예제의 경우, IP 주소 172.16.x.x를 가진 호스트는 172.16.1.x, 172.16.2.x, 172.16.3.x, 172.16.10.x에 있는 주소를 가진 호스트를 제외하고는 연결될 수 있음을 의미한다. no_access에서 처럼 인자 표시를 사용하면 네 개의 모든 조수의 컴포넌트를 지정할 필요가 없다. 인자로 된 부분은 주소의 가장 오른쪽 엘리먼트가 되어야 한다. (xinetd와 설정은 참고자료 참조)
TCP 래퍼
xinetd 대신 inted를 사용하기로 결정했다면 TCP 래퍼를 사용하여 특정 네트워크를 수락/거절하고, 요청을 기록할 수 있다. TCP 래퍼는 권한 부여와 로깅을 위해 /etc/hosts.allow와 /etc/hosts.deny를 평가하고 이것에 직접 응답하지 않고 클라이언트 요청을 래핑한다. 일단 성공적인 권한 부여가 되면 요청은 원리 요청된 서비스로 포워딩 된다.
TCP 래퍼를 사용하면 inetd를 사용할 때 보다 더 나은 점이 있다:
요청 클라이언트는 TCP 래퍼를 인식하지 못한다. 따라서 운이 좋은 사람들은 어떤 차이도 느끼지 못하고 운이 나쁜 사람들은 왜 요청이 실패했는지에 대한 아무런 정보도 받지 못한다.
TCP 래퍼는 래핑된 서비스와 상관없이 작동하면서 애플리케이션들이 설정 파일들을 공유하게 하여 관리 작업을 용이하게 한다.
TCP 래퍼 설정 파일 관련 문서는 Red Hat Linux Reference Guide를 참조하라. (참고자료)
world-writable 파일 찾는 방법
world-writable 파일을 찾으려면 다음 명령어를 사용한다:
find / -perm -002 \( -type f -o -type d \) -ls
풀이:
/는 검색의 출발선이다.
-perm은 허가 여부를 검사한다.
002는 (8진법 표기) "other"용 쓰기 비트 설정이다.
002 모드 앞에 있는 -는 모든 허가 비트가 설정됨을 의미한다. (zero 비트는 무시된다).
-type f 또는 -type d는 정식 파일 또는 디렉토리를 찾는다
-ls는 -ls 포맷에서 찾은 파일들을 나열한다.
방화벽
실행되지 않는 서비스나, 인터넷 같은 특정 네트워크로 접근 될 수 없는 서비스들과의 원치 않는 통신을 막으려면 방화벽 설치가 권장된다. 방화벽은 신용 레벨에 기반하여 네트워크들 간 통신을 제어하고, 최소 권한 원리를 적용하여 규칙 기반 보안 정책을 사용하는 특정 서비스들로의 액세스를 허용 또는 거부한다.
방화벽 설치와 설정은 매우 복잡한 주제이기 때문에 이 글에서는 다루지 않겠다.
로컬 파일시스템 보안
로컬 파일시스템의 보안은 파일과 디렉토리의 소유권과 접근 권한을 다루는 문제이다. 파일시스템을 보안화 하려면 파일과 디렉토리의 보호 비트(protection bit)가 최소 접근만 허용하도록 설정되어야 한다.
world-writable 파일과 시스템 디렉토리 그리고 setuid 또는 setgid명렁어와 관련된 부적절한 허가는 특별한 주의가 필요하다. 이 명령어를 실행하는 사용자가 실제로 갖고 있는 것 보다 더 높은 사용자 권한으로 실행된다. 오직 루트만 접근 할 수 있는 파일에 접근해야 할 수도 있다. (/bin/passwd가 /etc/passwd에 접근해야 하는 것 처럼). 각 명령어들은 setuid/setgid 비트 세트가 반드시 필요하다. 그런 경우가 아니면 사용하지 말라
파티션 상의 모든 파일들이 setuid/setgid비트를 필요로 하지 않을 때, /etc/fstab의 nosuid 옵션은 상응하는 파일 시스템상의 각 파일들을 위해 이를 정지시킨다. 다음 예제의 경우 (/dev/hdc1):
#device mountpoint filesystemtype options dump fsckorder
/dev/hda1 / ext2 defaults 1 1
...
/dev/hdc1 /mnt/cdrom iso9660 nosuid,user 1 2
더욱이, 민감한 데이터의 경우 그 데이터를 암호화하고 패스워드로 보호해야 함은 더 말할 나위 없다. GnuPG는 이 용도에 맞는 패키지이다.
할당량과 한계 적용
Linux PAM (Pluggable Authentication Modules)은 어느 정도 유용한 제한 기능이 있다. /etc/security/limits.conf 파일에서 설정될 수 있다. 이 제한은 싱글 세션에 적용된다는 것을 염두해야 한다. maxlogins옵션으로 전체적인 제한을 관리할 수 있다. limits.conf 내의 엔트리들은 다음의 구조를 갖는다: username|@groupname type resource limit
그룹 이름 앞에는 반드시 @이 선행되어야 한다. 사용자 이름과 구별하기 위해서이다. 유형은 soft 또는 hard가 되어야 한다. soft-limit은 초과될 수 있고 일반적으로 경고 표시인 반면, hard-limit은 초과될 수 없다. resource는 이들 키워드들 중 하나이다:
core - 핵심 파일의 사이즈 제한(KB).
data - 최대 데이터 사이즈(KB).
fsize - 최대 파일 사이즈 (KB).
memlock - 최대 고정 메모리 주소 공간 (KB).
nofile - 최대 개방 파일의 수.
rss - 레지던트 세트의 최대 사이즈 (KB).
stack - 최대 스택 사이즈 (KB).
cpu - 최대 CPU 시간 (분).
nproc - 최대 프로세스 수.
as - 주소 공간 한계.
maxlogins - 사용자에게 허용된 최대 로그인 수.
다음 코드 예제에서, 모든 사용자들은 세션 당 10 MB로 제한되고 총 4개의 동시 로그인이 허용된다. 세 번째 줄은 모든 사람들에게 core 덤프를 불가능하게 한다. 네 번째 줄은 사용자 bin에 대한 모든 제한을 제거한다. ftp는 10 개의 동시 세션을 가질 수 있다. (이는 익명의 ftp어카운트에 특히 유용하다); managers그룹의 멤버들은 40 프로세스로 제한된다. developers는 64 MB의 memlock으로 제한되며 wwwusers의 모든 멤버들은 50 MB 보다 큰 파일을 만들 수 없다.
Listing 3. 할당과 한계 설정
* hard rss 10000
* hard maxlogins 4
* hard core 0
bin -
ftp hard maxlogins 10
@managers hard nproc 40
@developers hard memlock 64000
@wwwusers hard fsize 50000
할당 예제
모든 파티션 사용자들을 위한 할당은 쓰기가 허용되어야 한다. 시스템이 인간 사용자 대신 애플리케이션에 대한 사용자 ID를 갖는 것도 고려해야 한다. 그러한 ID들은 사람들이 접근할 수 없는 디렉토리에 쓰기 접근을 갖고 있다.
/sbin/quotacheck -avug를 cronjobs에 추가하여 할당 파일과 커널에서 현재 사용하고 있는 테이블을 자동으로 업데이트 하도록 한다.
이 한계를 활성화하기 위해 다음 라인을 /etc/pam.d/login의 밑에 추가해야 한다: session required /lib/security/pam_limits.so.
할당은 inode의 수와 사용자 및 그룹의 소비 공간을 제한한다. 할당은 마운트 포인트 별로 정의되어 사용자가 여러 파티션에 쓰기 권한을 가지면 이들 각자에 대한 할당을 정의해야 한다.
할당은 하드 드라이브의 모든 사용 공간을 채우는 DoS 어택의 위험을 최소화하는 관리자들의 방식이다. (다른 프로세스들이 임시 파일을 만들지 못하게 하여 실패하게끔 한다). 사용하고 있는 배포판에 따라 내장된 할당 툴을 설치할 수 있고 직접 다운로드, 컴파일, 설치할 수 있다. (참고자료)
할당은 커널에서 실행되어야 한다. 오늘날 대부분의 배포판들은 할당 지원이 된다. 자신의 배포판에서 할당을 실행할 수 없다면 참고자료를 참조하라.
파일시스템용 할당을 실행하려면 /etc/fstab의 상응하는 라인에 옵션을 추가해야 한다. usrquota와 grpquota를 사용하여 사용자 할당과 그룹 할당을 실행한다. (Listing 4):
Listing 4. 사용자 할당과 그룹 할당 실행하기
/dev/hda1 / ext3 defaults 1 1
/dev/hda2 /home ext3 defaults,usrquota 1 1
/dev/hda3 /tmp ext3 defaults,usrquota,grpquota 1 1
/dev/hda4 /shared ext3 defaults,grpquota 1 1
/dev/hdc1 /mnt/cdrom iso9660 nosuid,user 1 2
그런 다음, 상응하는 파일시스템들을 다시 마운트하여 mount -a -o remount로 새롭게 추가된 옵션을 활성화한다; 그런 다음 quotacheck -cugvm명령어를 사용하여 바이너리 할당 파일을 만든다. 여기에는 머신이 읽을 수 있는 포맷에 할당 설정이 포함된다.
할당 설정은 edquota툴을 사용하여 수행된다. 사용자 alice용 제한을 설정하려면, edquota -u alice로 이것을 호출한다. 환경변수 EDITOR(디폴트는 vi)로 정의된 에디터는 비슷한 콘텐트로 연다:
Quotas for user alice:
/dev/hda2: blocks in use: 3567, limits (soft = 5500, hard = 6500)
inodes in use: 412, limits (soft = 1000, hard = 1500)
"in use" 값은 정보를 목적으로 있는 것이기 때문에 변경될 수 없다. soft와 hard 한계가 변경할 수 있는 유일한 값이다. 에디터를 저장하고 종료한 후에 edquota는 편집했던 임시 파일을 읽고 그 값을 바이너리 할당 파일로 변환하여 변경사항을 적용한다. 그룹 할당을 편집은 -u 대신 -g옵션을 사용해야 한다는 것을 제외하고는 작동은 같다.
soft 한계는 초과될 수 있는 경고 레벨인 반면 hard 한계는 엄격하게 실행된다. soft 한계는 grace period이다. (가끔 soft time 한계라고 불린다); 이는 사용자에게 허용된 시간 길이가 시스템에 의해 실행될 때 까지 soft 한계를 초과할 수 있다.);
grace period를 edquota -t로 설정할 수 있다. 사용할 수 있는 단위는 초, 분, 시간, 일, 주, 달 등이다. 할당을 관리하는 기타 유용한 툴들로는 repquota (파일시스템용 할당 요약), quotaon, quotaoff (할당을 on/off로 변환)등이 있다.
Mandatory Access Control 실행
Mandatory Access Control 또는 MAC으로 SELinux를 구현하여 추가적인 보안 문제를 해결할 수 있다. MAC을 사용하면 OS의 허가가 사용자/그룹 ID에 의해 제어된다. 또한 MAC을 사용하여 각 개별 프로세스는 리눅스 커널에서 실행되고 프로세스가 수행하는 것을 제어한다.
MAC으로 올바르게 설정된 시스템에서 강탈 또는 해킹당헌 서비스는 시스템으로 넘어올 수 없다. 서비스 프로세스가 실행되는 곳의 사용자 또는 그룹 ID (최악의 시나리오: root)가 /etc/passwd 같은 중요한 시스템 파일의 파일 허가와 맞더라도 이 정책은 접근을 허용하지 않는다.
SELinux의 효과는 모든 사람들이 로그인 할 수 있는 인터넷 상의 테스트 시스템에서 잘 보여준다; 제어 방식은 모든 악의적인 작업을 막는다. 심지어 root로서 로그인 할 수 있는 사용자라도 막는다.
GnuPG 키 추가하기
배포판 벤더의 GnuPG 키는 이미 기본 설정의 일부가 되어있어야 한다: $ rpm -import명령어를 사용하여 삼자 벤더의 키를 추가할 수 있다.
커넥션 인증이 입증된 HTTPS를 통해 벤더의 웹 사이트에서 다운로드를 받는 안전한 방식으로 keyfile을 받아야 한다.
SELinux에는 몇 가지 문제가 있다. 우선 배포판에서 MAC을 실행할 수 없다면 설정은 매우 힘들다. 커널의 패치와 재컴파일이 필요하고 특정 시스템 관리 툴을 대체해야 한다. (이 모든 것이 배포판 벤더의 지원 정책을 위반하는 것이다). 둘째, 적당한 정책을 정의하는 것은 매우 복잡한 일이다. 선택한 애플리케이션에 사용할 수 있는 정책 정의가 없다면 MAC 환경에서 실행하기 위해 많은 어려움을 겪어야 한다. 광범위한 패키지들이 지원되는 데스크탑 워크스테이션에서 특히 그렇다.
보안 패치 업데이트 및 추가
시스템을 가능한 한 안전하게 유지하려면 소프트웨어에 대한 새로운 픽스와 패치에 대한 정보를 지속적으로 받아야 한다. 이 정보에는 여러 소스들이 있지만, 일반적으로 소프트웨어 벤더와 리눅스 배포자들은 적시에 이 정보를 제공해야 한다. 또한 CERT (Computer Emergency Response Team)의 서비스를 사용할 수 있다. (거의 무료이다). 또한 최신 보고, 취약성 등에 대한 정보를 담고 있는 메일링 리스트들을 관리한다.
새로운 업데이트를 적용하려면 자신의 시스템과 보안 요구사항에 적용될 수 있는지를 확인해야 한다. 업데이트 설치는 그 자체가 보안 문제의 원인이 될 수 있다. 또한 각 업데이트로 인해 취약점이 생기거나 업데이트가 실패하면 시스템은 사용불가 상태로 될 것이다.
큰 규모의 시스템에 업데이트를 적용해야 할 때, 모두를 동시에 업데이트 할 수 없을 때가 종종 있다. 이로 인해 시스템 상호 비호환 문제가 생긴다.
여러분도 알다시피 시스템 업데이트에는 많은 위험이 잠재되어 있다. 다음은 이러한 위험들을 줄이기 위한 권고 사항들이다:
처음 설치 후에 곧바로 시스템을 네트워크에 연결하지 말라. 개별 머신에서 모든 관련 업데이트를 다운로드하여 이들을 직접 전송하여 시스템의 현재 상태를 확인하라.
사용하고 있는 시스템을 항상 백업하라.
비즈니스에 중요한 모든 시스템들의 경우, 하드웨어와 소프트웨어 모두, 실제 제품 환경과 동일한 고립된 테스트 환경을 갖고 있어야 한다. 테스트 환경에서 먼저 업데이트를 하여 제품 환경에는 차질이 없도록 하라.
이상적으로는 시스템을 구성하고 있는 모든 프로그램의 업데이트 전후에 해당 기능과 퍼포먼스를 비교하기 위한 회귀 테스트 수트를 갖고 있어야 한다. 최소한, 제품 시스템을 변경하기 전에 테스트 환경에서 영향을 주지 않는 기능과 서비스인지를 확인하는 반복적인 품질 검사를 해야 한다.
직접 업데이트를 적용하는 것은 작은 네트워크에는 알맞지만 규모가 클 경우 제어가 불가능하다. 이로 인해 업데이트가 설치되지 않을 때도 있다. 상용 또는 오픈 소스 시스템 관리 또는 소프트웨어 배포 툴을 이용하여 업데이트를 쉽게 전개하라.
백업을 자주 하라고 언급한적이 있다. 다시 한번 강조하겠다.
업데이트 적용 계획을 수립하라. 다음은 고려 사항이다:
시스템의 업데이트 순서
비즈니스에 중요한 시스템 결정
시스템의 의존 방식r
기밀 데이터를 포함하는 시스템 확인
무결성 체크 툴을 사용할 때, 알려진 보안 상태에서 취해진 시스템의 기본 특징을 업데이트 하여 예기치 않은 변경을 확인할 수 있도록 하라.
픽스를 적용하기 전에, 암호화 체크섬 툴을 사용하여 (웹 사이트나 ftp 서버에서 다운로드 할 때) 소프트웨어의 무결성과 인증을 확인하라. 리눅스에서는 일반적으로 MD5 또는 SHA-1 체크섬을 사용한다. RPM 패키지를 사용하여 소프트웨어가 제공된다면 벤더는 GnuPG 서명을 제공해야 한다. $ rpm -v --checksig.rpm 명령어를 실행하여 체크 할 수 있다. 성공적인 응답은 ".rpm: md5 gpg OK"이고, 실패한 응답은 ".rpm: md5 GPG NOT OK"이다.
MD5 또는 SHA-1 체크섬을 확인하려면, $ md5sum.rpm 또는 $ sha1sum .rpm을 사용한다. 한 개 이상의 파일을 위한 체크섬을 포함하고 있는 파일을 다운로드 했다면 (대부분의 경우 md5sum.asc 또는 .md5) $ md5sum -c md5sum.asc를 사용할 수 있다.
그 무엇보다도, 백업하라.
보안 플랜 수행하기
Part 2에서 논의한 것 처럼, 설치된 시스템과 문서화된 보안 계획을 맞춰보라. 어떤 프로세스가 시스템상에서 실제로 실행되는지를 파악하고 불필요한 프로세스를 제거한다. 이 같은 작업을 정기적으로 수행하여 정상적이지 않은 액티비티를 검사한다; 알려지지 않은 프로세스는 원치 않은 프로세스를 제공할 수도 있고 시스템을 위험에 노출시키게 된다.
이 섹션에서는 불필요한 (잠재적인 위험이 있는) 프로세스를 찾아 기능을 정지시키는 방법과 시스템의 정기적인 감사를 준비하는 방법을 설명한다.
불필요한 프로세스의 파악 및 기능 정지
이상적으로는, 시스템 상에서 실행중인 모든 프로세스를 알아야 한다. 모든 프로세스 리스트를 파악하려면 ps -ef (POSIX style) 또는 ps ax (BSD style)를 실행한다. 이름이 대괄호([])로 둘러 쌓인 프로세스는 도움말 기능(캐시를 디스크에 플러시하는 등..)을 수행하는 커널 레벨의 프로세스이다; 모든 다른 프로세스들은 userland 프로세스이다. 새롭게 설치된 (최소) 시스템상에서 조차도 많은 프로세스들이 실행되고 있다는 것을 알게 될 것이다. 여기에 익숙해지고 이를 문서에 추가하라.
네트워크 모니터링 툴
다음은 네트워크 모니터링 툴들이다:
Nmap (Network Mapper)는 무료 오픈 소스 유틸리티로서 네트워크 탐색 또는 보안 감사에 사용된다. 이것을 사용하여 설정을 끝마친 후에 시스템을 검사한다.
IPTraf는 리눅스용 콘솔 기반의 네트워크 통계 유틸리티이다. TCP 커넥션 패킷과 바이트 카운트, 인터페이스 통계, 액티비티 인디케이터, TCP/UDP 트래픽 브레이크다운, LAN 스테이션 패킷, 바이트 카운트 같은 다양한 그림을 모은다.
Multi Router Traffic Grapher는 네트워크 링크 상의 트래픽 부하를 감시하는 툴이다. MRTG는 이 트래픽의 그래픽 이미지를 포함한 HTML을 생성한다. MRTG index page참조.
이제, 네트워크 연결을 여는 프로세스를 살펴보자; 이 프로세스는 잠재적인 공격 위험이 크다. 모든 TCP 또는 UDP 연결 리스트를 알려면 netstat -atu (name resolution으로 읽기 쉬움) 또는 netstat -atun (name resolution이 없으며 빠르다) 명령어를 실행한다. 이 리스트 안에서 LISTEN 상태를 가진 TCP 연결과 모든 UDP 연결에 주의를 기울여라. 이들은 인커밍 연결을 수락하는 서버들이다.
서버가 127.0.0.1/localhost를 리스닝하면 시스템 자체에 의해 접근될 수 있다. (loopback 인터페이스). 따라서 외부에서 접근 가능한 인터페이스나, 어떤 네트워크 인터페이스를 통해서든 접근할 수 있는 0.0.0.0 (= * name-resolution 켜진 상태)을 리스닝 하는 것보다 노출이 훨씬 덜 된다.
netstat -atun을 사용했다면 포트 넘버를 변환해야 한다. /etc/services 에서 검색할 수 있다. 추가 매개변수인 -p를 사용하여 상응하는 프로세스를 디스플레이 한다. (Listing 5)
이 예제에서 포트매퍼(portmapper)와 그래픽 유저 인터페이스(X)는 특정 서버에는 필요하지 않다는 결론이 나왔다. 포트매퍼는 NFS 같은 다양한 RPC 기반 서비스에 표준 엔드포인트를 제공한다. 시스템은 NFS 공유를 제공하지 않는다. X 윈도우 디스플레이는 시스템이 워크스테이션으로서 사용될 때 유용하지만 서버로 사용될 때는 제한이 많다.
이 프로세스들이 (/etc/inittab, boot scripts 등을 통해) 어떻게 시작되었는지를 확인하고 앞에서 설명한 대로 기능을 정지한다. 이 작업은 프로그램이 다른 프로그램에 의해 시작되었다면 매우 힘들다; X 서버는 거의 대부분 xdm, kdm, 또는 gdm 같은 디스플레이 매니저로 시작되고 inittab 또는 부트 스크립트 디렉토리에는 보이지 않는다.
netstat으로 열거된 연결은 넷 상의 모든 컴퓨터에서 사용될 필요가 없다: 리눅스의 빌트인 기능에 근거한 방화벽은 패킷이 개방 커넥션에 연결되기 전에 액세스를 조정한다.
감사 준비
일단 기본적인 시스템이 설치되고 안전하게 설정되면 시스템을 안전하게 지키는 것이 궁극적인 목표이다. 시스템에 원치 않은 변경을 확인하려면 시스템의 핑거프린트를 기록하는 감사 툴을 사용한다.
http://www-128.ibm.com/developerworks/k ··· clnx3%2F
난이도 : 초급
Mario Eberlein, IT 아키텍트, IBM Global Services
Rene Auberger, 소프트웨어 IT 아키텍트, IBM Software Group
Wolfram Andreas Richter, IT Architect, IBM Software Group
2005년 4 월 14 일
공격에 대한 저항력이 강한 리눅스 시스템을 만드는 기술을 배워보자. 부트 프로세스와 로컬 파일시스템 보안, 서비스와 데몬 잠금, 할당량과 한계 적용, Mandatory Access Control 실행, 새로운 소프트웨어로 보안을 업데이트 할 때 발생할 수 있는 보안 취약성 인식 등을 다룬다. Part 1에서는 보안 개념과 잠재적 위험을 Part 2에서는 보안 설치를 계획할 때 고려해야 할 사항들을 설명한다.
이 시리즈를 통해서, 리눅스를 실행하는 시스템의 계획 수립, 디자인, 설치, 설정, 관리 방법을 설명한다. 보안 개념, 설치 문제, 잠재적 위협과 남용 등에 대한 이론적인 설명 외에도 리눅스 시스템의 보안과 하드닝 등 실용적인 방법도 제시한다. 최소한의 설치, 리눅스 설치 하드닝, 권한/인증, 로컬 및 네트워크 보안, 공격과 방어 방법, 데이터 보안, 바이러스, 악성 프로그램 등을 논할 것이다.
Part 1은 보안 개념과 잠재적 위협에 대한 문제로 시작한다. Part 2에서는 보안 설치를 계획할 때 고려해야 할 사항들을 설명한다. 상세한 액션 플랜도 포함된다.
이번 시간에는 리눅스 하드닝 단계를 설명하겠다.
하드닝(hardening)에 대하여
성공적인 하드닝을 위해서는 다음과 같이 해야 한다:
공격을 피하기 위해서 시스템이 네트워크로 연결되기 전에 하드닝을 수행한다.
최소 권한 모델(least-privilege model)설정:시스템은 해당 기능에 필요한 정도로만 액세스를 허용해야 한다. 마찬가지로, 사용자들은 최소한의 접근 권한만 가져야 한다..
사전 플래닝과 준비를 완료하고 최소한의 설치(Part 2 참조)를 마친 후에는 여러 가지 설정 단계들을 고려해야 한다. 다음 단계는 리눅스 하드닝에 일반적으로 참조된다:
부트(boot) 프로세스 보안
서비스와 데몬 보안
로컬 파일시스템 보안
할당량과 한계 적용
Mandatory Access Control 실행
보안 패치 업데이트 및 추가
부트(boot) 프로세스 보안
부트 로더(LILO 또는 Grub)를 설정하여 부팅 시 어떤 사용자의 개입도 허용되지 않도록 한다. 다시 말해서, 사용자가 부트 프롬프트에서 커널 매개변수를 패스하지 못하도록 한다. (원격 데이터센터 같은 곳에서) 원격 재부팅을 수행하는 것이 아닌 이상 패스워드를 넣도록 설정한다. 이는 머신에 물리적으로 접근하는 사람들에게 주는 사전 경고이다. 루트 쉘을 얻기 위해 single 또는 init=/bin/sh를 이용하는 부팅을 방지한다. (하드 드라이브를 제거하거나 다른 시스템에 하드 드라이브를 마운트 하는 등의) 추가적인 시도를 하면, 파일 시스템을 암호화 하지 않은 한 쉽게 피할 수 있다.
LILO의 경우 매개변수 prompt를 설정 파일(일반적으로 /etc에 있음)에 있는 password로 대체시켜라. Grub의 경우, 관련 매개변수는 Grub 설정 파일(/boot/grub/grub/conf)에 있는 hiddenmenu, default 0, password이다.
실행 레벨 설정에는 sp:S:respawn:/sbin/sulogin을 /etc/inittab에 추가하여 단일 사용자 모드로 전환할 때 루트 패스워드가 필요하다.
사용자가 Ctrl-Alt-Del을 사용하여 재부팅을 하지 못하도록 한다: ctrlaltdel주석을 달아 /etc/inittab에 ctrlaltdel 엔트리가 실행되지 못하도록 한다. #ca::ctrlaltdel:/sbin/shutdown -t5 -rf now 처럼 해시(#) 표시를 추가하여 키 조합을 이용한 재부팅을 방지할 수 있다.
서비스와 데몬 보안
서비스의 보안 설정의 첫 단계는 필요하지 않는 모든 서비스들을 실행불가 상태로 만드는 것이다. 제공되지 않는 서비스들은 침입자들이 악용할 수 없기 때문에 위험을 줄일 수 있다.
모든 실행 가능한 서비스들을 감추려면 여러 위치를 검사하면 된다. 불안정한 서비스들의 기능을 억제하고 보다 안전한 옵션으로 대체한다. 예를 들어, telnet은 암호화 되지 않기 때문에 암호화된 ssh 서비스를 사용한다. (Part 2 참조)
서비스 보안을 위해서는 다음 요소들을 고려해야 한다:
/etc/inittab
/etc/init.d의 부트 스크립트
inetd/xinetd 데몬
TCP 래퍼
방화벽
/etc/inittab
부트 프로세스 동안 init 프로세스는 /etc/inittab 파일에 있는 엔트리들을 읽는다. 라인 당 한 개씩 있는 각 엔트리는 특정 상황에서 어떤 프로그램이 실행될 것인지를 정의한다. 그와 같은 프로그램은 서비스 그 자체 이거나 서비스를 시작 및 종료하는데 사용된다.
init 프로세스는 하나의 문자로 구별된 여러 상태들(소위 말해 실행 레벨(run level), 을 구별한다. 실행 레벨이 나타나거나 (전원 오류 같은) 특정 이벤트가 발생하면 엔트리들은 평가되고 해당 명령어들이 실행된다.
/etc/inittab에 있는 엔트리 포맷은 이 엔트리용 레이블이고, 엔트리가 처리되는 실행 레벨,그 다음에는 액션 키워드, 명령행 매개변수를 포함하여 실행될 명령어 순으로 된다. 이 모든 필드는 콜론으로 구별되며 전형적인 엔트리는 다음과 같다:
my_service:35:once:/usr/local/bin/my_service someparameter
(inittab의 맨 페이지(man-page)에서 액션 키워드의 리스트를 참조하라.)
이 예제에서, 이 엔트리의 레이블은 my_service이다. 실행 레벨3 또는 5가 되면 매개변수 someparameter를 가진 /usr/local/bin/my_service 프로그램이 실행된다. 일단 프로그램이 종료되면 다시 시작되지 않는다. (액션 키워드 “once”)
안전한 리눅스 시스템을 위해 /etc/inittab의 모든 엔트리 기능을 이해해야 하며, 엔트리를 삭제하거나 라인 앞에 해시 사인을 사용하여 주석을 달아 원치 않는 서비스 기능을 없앤다.
모든 리눅스 시스템에 공통적인 두 가지 유형의 엔트리가 있다. 하나는 /sbin/getty 라고 하는 프로그램을 시작하는데 사용된다. 이것은 리눅스 가상 콘솔이나 시리얼 라인상에서 로그인을 허용하는데 사용된다. 또 다른 유형은 매개 변수로서 현재 실행 레벨을 갖고 있는 /etc/rc.d 디렉토리의 rc 라는 스크립트를 시작한다. 이 스크립트는 서비스의 시작과 종료를 제어한다. (다음에 설명하겠다.)
/etc/init.d의 부트 스크립트
/etc/init.d에 있는 부트 스크립트는 시스템 서비스를 시작 및 정지하는데 사용된다. 각 실행 레벨의 경우 실행 레벨 변경 시 호출될 부트 스크립트로의 소프트 링크가 포함되어 있는 /etc/rcN.d 디렉토리가 있다. (“N”은 실행 레벨을 나타낸다.)
링크 이름이 “S”로 시작한다면 이 스크립트는 상응하는 서비스를 시작하기 위해 실행 레벨을 입력할 때 실행된다; “K”로 시작하면 서비스 중지를 위해 실행 레벨을 종료할 때 스크립트가 실행된다.
대부분, 부트 스크립트의 이름을 보면 어떤 서비스가 제어되는지 알 수 있다. 서비스가 특정 실행 레벨에서 시작되지 않도록 하려면 실행 레벨 하위 디렉토리에서 상응하는 부트 스크립트 까지의 링크를 삭제하고 아무것도 수행하지 않는 더미 스크립트로 /etc/init.d에 있는 원래 부트 스크립트로 대체한다.
inetd/xinetd 데몬
클라이언트가 요청하면 서비스들은 호출될 수 있다. 이 요청들은 수퍼 데몬인 inetd 또는 xinetd로 간다. 수퍼 데몬은 어떤 서비스를 시작할 것인지를 결정하고 요청을 상응하는 데몬에 보낸다. 일반적으로 telnet, ftp, rlogin 같은 서비스들은 inetd 또는 xinetd를 사용하여 시작된다.
inetd 데몬은 에서 설정된다. 여기에는 수퍼 데몬에서 제공하는 각 서비스에 대한 엔트리가 포함된다. FTP 서버를 설정하는 엔트리는 ftp stream tcp nowait root /usr/bin/ftpd in.ftpd -el과 같다. 그리고 마찬가지로 해시 사인을 사용하여 주석을 달아 기능을 못하도록 한다.
보안을 위해 xinetd를 사용하라. inetd와 달리 xinetd는 rpc 기반 서비스들을 시작할 수 있고 액세스 제어도 제공한다. xinetd는 인커밍 커넥션의 비율, 특정 호스트로 부터의 인커밍 커넥션의 수, 한 서비스를 위한 총 커넥션의 수 등을 제한할 수 있다.
xinetd는 각 하위 데몬에 대한 개별 설정 파일에 의해 설정된다. 이 파일들은 /etc/xinetd.d/에 위치해 있다. 위 FTP 서버용 설정 파일 예제는 /etc/xinetd.d/ftp 일 것이고 다음과 같다:
Listing 1. 설정 파일, /etc/xinetd.d/ftp
service ftp
{
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/bin/ftpd
server_args = -el
disable = yes
}
서비스 기능을 없애려면 disable 매개변수를 이전 예제에서 yes로 설정한다.
보다 세련된 액세스 제어를 위해 xinetd는 다음 세 개의 매개변수들을 지원한다:
only_from
no_access
access_time
ftp 데몬 기능을 완전히 억제하지 않고 액세스만 제한하려면 다음과 같이 /etc/xinetd.d/ftp config 파일을 변경하면 된다:
Listing 2. 액세스를 제한하도록 변경된 /etc/xinetd.d/ftp 설정 파일
service ftp
{
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/bin/ftpd
server_args = -el
disable = no
only-from = 192.168.200.3 192.168.200.7 192.168.200.9
only-from += 192.168.200.10 192.168.200.12 172.16.0.0
no_access = 172.16.{1,2,3,10}
access_times = 07:00-21:00
}
only-from과 no_access는 숫자로 된 IP 주소(맨 오른쪽에 있는 0은 와일드카드로 간주됨), IP 주소/넷마스크 범위, 호스트 네임, /etc/networks의 네트워크 이름을 허용한다. only-from과 no_access의 조합이 사용되면 xinetd는 각 호스트 연결과 가장 근접한 매치를 찾는다.
이전 코드 예제의 경우, IP 주소 172.16.x.x를 가진 호스트는 172.16.1.x, 172.16.2.x, 172.16.3.x, 172.16.10.x에 있는 주소를 가진 호스트를 제외하고는 연결될 수 있음을 의미한다. no_access에서 처럼 인자 표시를 사용하면 네 개의 모든 조수의 컴포넌트를 지정할 필요가 없다. 인자로 된 부분은 주소의 가장 오른쪽 엘리먼트가 되어야 한다. (xinetd와 설정은 참고자료 참조)
TCP 래퍼
xinetd 대신 inted를 사용하기로 결정했다면 TCP 래퍼를 사용하여 특정 네트워크를 수락/거절하고, 요청을 기록할 수 있다. TCP 래퍼는 권한 부여와 로깅을 위해 /etc/hosts.allow와 /etc/hosts.deny를 평가하고 이것에 직접 응답하지 않고 클라이언트 요청을 래핑한다. 일단 성공적인 권한 부여가 되면 요청은 원리 요청된 서비스로 포워딩 된다.
TCP 래퍼를 사용하면 inetd를 사용할 때 보다 더 나은 점이 있다:
요청 클라이언트는 TCP 래퍼를 인식하지 못한다. 따라서 운이 좋은 사람들은 어떤 차이도 느끼지 못하고 운이 나쁜 사람들은 왜 요청이 실패했는지에 대한 아무런 정보도 받지 못한다.
TCP 래퍼는 래핑된 서비스와 상관없이 작동하면서 애플리케이션들이 설정 파일들을 공유하게 하여 관리 작업을 용이하게 한다.
TCP 래퍼 설정 파일 관련 문서는 Red Hat Linux Reference Guide를 참조하라. (참고자료)
world-writable 파일 찾는 방법
world-writable 파일을 찾으려면 다음 명령어를 사용한다:
find / -perm -002 \( -type f -o -type d \) -ls
풀이:
/는 검색의 출발선이다.
-perm은 허가 여부를 검사한다.
002는 (8진법 표기) "other"용 쓰기 비트 설정이다.
002 모드 앞에 있는 -는 모든 허가 비트가 설정됨을 의미한다. (zero 비트는 무시된다).
-type f 또는 -type d는 정식 파일 또는 디렉토리를 찾는다
-ls는 -ls 포맷에서 찾은 파일들을 나열한다.
방화벽
실행되지 않는 서비스나, 인터넷 같은 특정 네트워크로 접근 될 수 없는 서비스들과의 원치 않는 통신을 막으려면 방화벽 설치가 권장된다. 방화벽은 신용 레벨에 기반하여 네트워크들 간 통신을 제어하고, 최소 권한 원리를 적용하여 규칙 기반 보안 정책을 사용하는 특정 서비스들로의 액세스를 허용 또는 거부한다.
방화벽 설치와 설정은 매우 복잡한 주제이기 때문에 이 글에서는 다루지 않겠다.
로컬 파일시스템 보안
로컬 파일시스템의 보안은 파일과 디렉토리의 소유권과 접근 권한을 다루는 문제이다. 파일시스템을 보안화 하려면 파일과 디렉토리의 보호 비트(protection bit)가 최소 접근만 허용하도록 설정되어야 한다.
world-writable 파일과 시스템 디렉토리 그리고 setuid 또는 setgid명렁어와 관련된 부적절한 허가는 특별한 주의가 필요하다. 이 명령어를 실행하는 사용자가 실제로 갖고 있는 것 보다 더 높은 사용자 권한으로 실행된다. 오직 루트만 접근 할 수 있는 파일에 접근해야 할 수도 있다. (/bin/passwd가 /etc/passwd에 접근해야 하는 것 처럼). 각 명령어들은 setuid/setgid 비트 세트가 반드시 필요하다. 그런 경우가 아니면 사용하지 말라
파티션 상의 모든 파일들이 setuid/setgid비트를 필요로 하지 않을 때, /etc/fstab의 nosuid 옵션은 상응하는 파일 시스템상의 각 파일들을 위해 이를 정지시킨다. 다음 예제의 경우 (/dev/hdc1):
#device mountpoint filesystemtype options dump fsckorder
/dev/hda1 / ext2 defaults 1 1
...
/dev/hdc1 /mnt/cdrom iso9660 nosuid,user 1 2
더욱이, 민감한 데이터의 경우 그 데이터를 암호화하고 패스워드로 보호해야 함은 더 말할 나위 없다. GnuPG는 이 용도에 맞는 패키지이다.
할당량과 한계 적용
Linux PAM (Pluggable Authentication Modules)은 어느 정도 유용한 제한 기능이 있다. /etc/security/limits.conf 파일에서 설정될 수 있다. 이 제한은 싱글 세션에 적용된다는 것을 염두해야 한다. maxlogins옵션으로 전체적인 제한을 관리할 수 있다. limits.conf 내의 엔트리들은 다음의 구조를 갖는다: username|@groupname type resource limit
그룹 이름 앞에는 반드시 @이 선행되어야 한다. 사용자 이름과 구별하기 위해서이다. 유형은 soft 또는 hard가 되어야 한다. soft-limit은 초과될 수 있고 일반적으로 경고 표시인 반면, hard-limit은 초과될 수 없다. resource는 이들 키워드들 중 하나이다:
core - 핵심 파일의 사이즈 제한(KB).
data - 최대 데이터 사이즈(KB).
fsize - 최대 파일 사이즈 (KB).
memlock - 최대 고정 메모리 주소 공간 (KB).
nofile - 최대 개방 파일의 수.
rss - 레지던트 세트의 최대 사이즈 (KB).
stack - 최대 스택 사이즈 (KB).
cpu - 최대 CPU 시간 (분).
nproc - 최대 프로세스 수.
as - 주소 공간 한계.
maxlogins - 사용자에게 허용된 최대 로그인 수.
다음 코드 예제에서, 모든 사용자들은 세션 당 10 MB로 제한되고 총 4개의 동시 로그인이 허용된다. 세 번째 줄은 모든 사람들에게 core 덤프를 불가능하게 한다. 네 번째 줄은 사용자 bin에 대한 모든 제한을 제거한다. ftp는 10 개의 동시 세션을 가질 수 있다. (이는 익명의 ftp어카운트에 특히 유용하다); managers그룹의 멤버들은 40 프로세스로 제한된다. developers는 64 MB의 memlock으로 제한되며 wwwusers의 모든 멤버들은 50 MB 보다 큰 파일을 만들 수 없다.
Listing 3. 할당과 한계 설정
* hard rss 10000
* hard maxlogins 4
* hard core 0
bin -
ftp hard maxlogins 10
@managers hard nproc 40
@developers hard memlock 64000
@wwwusers hard fsize 50000
할당 예제
모든 파티션 사용자들을 위한 할당은 쓰기가 허용되어야 한다. 시스템이 인간 사용자 대신 애플리케이션에 대한 사용자 ID를 갖는 것도 고려해야 한다. 그러한 ID들은 사람들이 접근할 수 없는 디렉토리에 쓰기 접근을 갖고 있다.
/sbin/quotacheck -avug를 cronjobs에 추가하여 할당 파일과 커널에서 현재 사용하고 있는 테이블을 자동으로 업데이트 하도록 한다.
이 한계를 활성화하기 위해 다음 라인을 /etc/pam.d/login의 밑에 추가해야 한다: session required /lib/security/pam_limits.so.
할당은 inode의 수와 사용자 및 그룹의 소비 공간을 제한한다. 할당은 마운트 포인트 별로 정의되어 사용자가 여러 파티션에 쓰기 권한을 가지면 이들 각자에 대한 할당을 정의해야 한다.
할당은 하드 드라이브의 모든 사용 공간을 채우는 DoS 어택의 위험을 최소화하는 관리자들의 방식이다. (다른 프로세스들이 임시 파일을 만들지 못하게 하여 실패하게끔 한다). 사용하고 있는 배포판에 따라 내장된 할당 툴을 설치할 수 있고 직접 다운로드, 컴파일, 설치할 수 있다. (참고자료)
할당은 커널에서 실행되어야 한다. 오늘날 대부분의 배포판들은 할당 지원이 된다. 자신의 배포판에서 할당을 실행할 수 없다면 참고자료를 참조하라.
파일시스템용 할당을 실행하려면 /etc/fstab의 상응하는 라인에 옵션을 추가해야 한다. usrquota와 grpquota를 사용하여 사용자 할당과 그룹 할당을 실행한다. (Listing 4):
Listing 4. 사용자 할당과 그룹 할당 실행하기
/dev/hda1 / ext3 defaults 1 1
/dev/hda2 /home ext3 defaults,usrquota 1 1
/dev/hda3 /tmp ext3 defaults,usrquota,grpquota 1 1
/dev/hda4 /shared ext3 defaults,grpquota 1 1
/dev/hdc1 /mnt/cdrom iso9660 nosuid,user 1 2
그런 다음, 상응하는 파일시스템들을 다시 마운트하여 mount -a -o remount로 새롭게 추가된 옵션을 활성화한다; 그런 다음 quotacheck -cugvm명령어를 사용하여 바이너리 할당 파일을 만든다. 여기에는 머신이 읽을 수 있는 포맷에 할당 설정이 포함된다.
할당 설정은 edquota툴을 사용하여 수행된다. 사용자 alice용 제한을 설정하려면, edquota -u alice로 이것을 호출한다. 환경변수 EDITOR(디폴트는 vi)로 정의된 에디터는 비슷한 콘텐트로 연다:
Quotas for user alice:
/dev/hda2: blocks in use: 3567, limits (soft = 5500, hard = 6500)
inodes in use: 412, limits (soft = 1000, hard = 1500)
"in use" 값은 정보를 목적으로 있는 것이기 때문에 변경될 수 없다. soft와 hard 한계가 변경할 수 있는 유일한 값이다. 에디터를 저장하고 종료한 후에 edquota는 편집했던 임시 파일을 읽고 그 값을 바이너리 할당 파일로 변환하여 변경사항을 적용한다. 그룹 할당을 편집은 -u 대신 -g옵션을 사용해야 한다는 것을 제외하고는 작동은 같다.
soft 한계는 초과될 수 있는 경고 레벨인 반면 hard 한계는 엄격하게 실행된다. soft 한계는 grace period이다. (가끔 soft time 한계라고 불린다); 이는 사용자에게 허용된 시간 길이가 시스템에 의해 실행될 때 까지 soft 한계를 초과할 수 있다.);
grace period를 edquota -t로 설정할 수 있다. 사용할 수 있는 단위는 초, 분, 시간, 일, 주, 달 등이다. 할당을 관리하는 기타 유용한 툴들로는 repquota (파일시스템용 할당 요약), quotaon, quotaoff (할당을 on/off로 변환)등이 있다.
Mandatory Access Control 실행
Mandatory Access Control 또는 MAC으로 SELinux를 구현하여 추가적인 보안 문제를 해결할 수 있다. MAC을 사용하면 OS의 허가가 사용자/그룹 ID에 의해 제어된다. 또한 MAC을 사용하여 각 개별 프로세스는 리눅스 커널에서 실행되고 프로세스가 수행하는 것을 제어한다.
MAC으로 올바르게 설정된 시스템에서 강탈 또는 해킹당헌 서비스는 시스템으로 넘어올 수 없다. 서비스 프로세스가 실행되는 곳의 사용자 또는 그룹 ID (최악의 시나리오: root)가 /etc/passwd 같은 중요한 시스템 파일의 파일 허가와 맞더라도 이 정책은 접근을 허용하지 않는다.
SELinux의 효과는 모든 사람들이 로그인 할 수 있는 인터넷 상의 테스트 시스템에서 잘 보여준다; 제어 방식은 모든 악의적인 작업을 막는다. 심지어 root로서 로그인 할 수 있는 사용자라도 막는다.
GnuPG 키 추가하기
배포판 벤더의 GnuPG 키는 이미 기본 설정의 일부가 되어있어야 한다: $ rpm -import
커넥션 인증이 입증된 HTTPS를 통해 벤더의 웹 사이트에서 다운로드를 받는 안전한 방식으로 keyfile을 받아야 한다.
SELinux에는 몇 가지 문제가 있다. 우선 배포판에서 MAC을 실행할 수 없다면 설정은 매우 힘들다. 커널의 패치와 재컴파일이 필요하고 특정 시스템 관리 툴을 대체해야 한다. (이 모든 것이 배포판 벤더의 지원 정책을 위반하는 것이다). 둘째, 적당한 정책을 정의하는 것은 매우 복잡한 일이다. 선택한 애플리케이션에 사용할 수 있는 정책 정의가 없다면 MAC 환경에서 실행하기 위해 많은 어려움을 겪어야 한다. 광범위한 패키지들이 지원되는 데스크탑 워크스테이션에서 특히 그렇다.
보안 패치 업데이트 및 추가
시스템을 가능한 한 안전하게 유지하려면 소프트웨어에 대한 새로운 픽스와 패치에 대한 정보를 지속적으로 받아야 한다. 이 정보에는 여러 소스들이 있지만, 일반적으로 소프트웨어 벤더와 리눅스 배포자들은 적시에 이 정보를 제공해야 한다. 또한 CERT (Computer Emergency Response Team)의 서비스를 사용할 수 있다. (거의 무료이다). 또한 최신 보고, 취약성 등에 대한 정보를 담고 있는 메일링 리스트들을 관리한다.
새로운 업데이트를 적용하려면 자신의 시스템과 보안 요구사항에 적용될 수 있는지를 확인해야 한다. 업데이트 설치는 그 자체가 보안 문제의 원인이 될 수 있다. 또한 각 업데이트로 인해 취약점이 생기거나 업데이트가 실패하면 시스템은 사용불가 상태로 될 것이다.
큰 규모의 시스템에 업데이트를 적용해야 할 때, 모두를 동시에 업데이트 할 수 없을 때가 종종 있다. 이로 인해 시스템 상호 비호환 문제가 생긴다.
여러분도 알다시피 시스템 업데이트에는 많은 위험이 잠재되어 있다. 다음은 이러한 위험들을 줄이기 위한 권고 사항들이다:
처음 설치 후에 곧바로 시스템을 네트워크에 연결하지 말라. 개별 머신에서 모든 관련 업데이트를 다운로드하여 이들을 직접 전송하여 시스템의 현재 상태를 확인하라.
사용하고 있는 시스템을 항상 백업하라.
비즈니스에 중요한 모든 시스템들의 경우, 하드웨어와 소프트웨어 모두, 실제 제품 환경과 동일한 고립된 테스트 환경을 갖고 있어야 한다. 테스트 환경에서 먼저 업데이트를 하여 제품 환경에는 차질이 없도록 하라.
이상적으로는 시스템을 구성하고 있는 모든 프로그램의 업데이트 전후에 해당 기능과 퍼포먼스를 비교하기 위한 회귀 테스트 수트를 갖고 있어야 한다. 최소한, 제품 시스템을 변경하기 전에 테스트 환경에서 영향을 주지 않는 기능과 서비스인지를 확인하는 반복적인 품질 검사를 해야 한다.
직접 업데이트를 적용하는 것은 작은 네트워크에는 알맞지만 규모가 클 경우 제어가 불가능하다. 이로 인해 업데이트가 설치되지 않을 때도 있다. 상용 또는 오픈 소스 시스템 관리 또는 소프트웨어 배포 툴을 이용하여 업데이트를 쉽게 전개하라.
백업을 자주 하라고 언급한적이 있다. 다시 한번 강조하겠다.
업데이트 적용 계획을 수립하라. 다음은 고려 사항이다:
시스템의 업데이트 순서
비즈니스에 중요한 시스템 결정
시스템의 의존 방식r
기밀 데이터를 포함하는 시스템 확인
무결성 체크 툴을 사용할 때, 알려진 보안 상태에서 취해진 시스템의 기본 특징을 업데이트 하여 예기치 않은 변경을 확인할 수 있도록 하라.
픽스를 적용하기 전에, 암호화 체크섬 툴을 사용하여 (웹 사이트나 ftp 서버에서 다운로드 할 때) 소프트웨어의 무결성과 인증을 확인하라. 리눅스에서는 일반적으로 MD5 또는 SHA-1 체크섬을 사용한다. RPM 패키지를 사용하여 소프트웨어가 제공된다면 벤더는 GnuPG 서명을 제공해야 한다. $ rpm -v --checksig
MD5 또는 SHA-1 체크섬을 확인하려면, $ md5sum
그 무엇보다도, 백업하라.
보안 플랜 수행하기
Part 2에서 논의한 것 처럼, 설치된 시스템과 문서화된 보안 계획을 맞춰보라. 어떤 프로세스가 시스템상에서 실제로 실행되는지를 파악하고 불필요한 프로세스를 제거한다. 이 같은 작업을 정기적으로 수행하여 정상적이지 않은 액티비티를 검사한다; 알려지지 않은 프로세스는 원치 않은 프로세스를 제공할 수도 있고 시스템을 위험에 노출시키게 된다.
이 섹션에서는 불필요한 (잠재적인 위험이 있는) 프로세스를 찾아 기능을 정지시키는 방법과 시스템의 정기적인 감사를 준비하는 방법을 설명한다.
불필요한 프로세스의 파악 및 기능 정지
이상적으로는, 시스템 상에서 실행중인 모든 프로세스를 알아야 한다. 모든 프로세스 리스트를 파악하려면 ps -ef (POSIX style) 또는 ps ax (BSD style)를 실행한다. 이름이 대괄호([])로 둘러 쌓인 프로세스는 도움말 기능(캐시를 디스크에 플러시하는 등..)을 수행하는 커널 레벨의 프로세스이다; 모든 다른 프로세스들은 userland 프로세스이다. 새롭게 설치된 (최소) 시스템상에서 조차도 많은 프로세스들이 실행되고 있다는 것을 알게 될 것이다. 여기에 익숙해지고 이를 문서에 추가하라.
네트워크 모니터링 툴
다음은 네트워크 모니터링 툴들이다:
Nmap (Network Mapper)는 무료 오픈 소스 유틸리티로서 네트워크 탐색 또는 보안 감사에 사용된다. 이것을 사용하여 설정을 끝마친 후에 시스템을 검사한다.
IPTraf는 리눅스용 콘솔 기반의 네트워크 통계 유틸리티이다. TCP 커넥션 패킷과 바이트 카운트, 인터페이스 통계, 액티비티 인디케이터, TCP/UDP 트래픽 브레이크다운, LAN 스테이션 패킷, 바이트 카운트 같은 다양한 그림을 모은다.
Multi Router Traffic Grapher는 네트워크 링크 상의 트래픽 부하를 감시하는 툴이다. MRTG는 이 트래픽의 그래픽 이미지를 포함한 HTML을 생성한다. MRTG index page참조.
이제, 네트워크 연결을 여는 프로세스를 살펴보자; 이 프로세스는 잠재적인 공격 위험이 크다. 모든 TCP 또는 UDP 연결 리스트를 알려면 netstat -atu (name resolution으로 읽기 쉬움) 또는 netstat -atun (name resolution이 없으며 빠르다) 명령어를 실행한다. 이 리스트 안에서 LISTEN 상태를 가진 TCP 연결과 모든 UDP 연결에 주의를 기울여라. 이들은 인커밍 연결을 수락하는 서버들이다.
서버가 127.0.0.1/localhost를 리스닝하면 시스템 자체에 의해 접근될 수 있다. (loopback 인터페이스). 따라서 외부에서 접근 가능한 인터페이스나, 어떤 네트워크 인터페이스를 통해서든 접근할 수 있는 0.0.0.0 (= * name-resolution 켜진 상태)을 리스닝 하는 것보다 노출이 훨씬 덜 된다.
netstat -atun을 사용했다면 포트 넘버를 변환해야 한다. /etc/services 에서 검색할 수 있다. 추가 매개변수인 -p를 사용하여 상응하는 프로세스를 디스플레이 한다. (Listing 5)
이 예제에서 포트매퍼(portmapper)와 그래픽 유저 인터페이스(X)는 특정 서버에는 필요하지 않다는 결론이 나왔다. 포트매퍼는 NFS 같은 다양한 RPC 기반 서비스에 표준 엔드포인트를 제공한다. 시스템은 NFS 공유를 제공하지 않는다. X 윈도우 디스플레이는 시스템이 워크스테이션으로서 사용될 때 유용하지만 서버로 사용될 때는 제한이 많다.
이 프로세스들이 (/etc/inittab, boot scripts 등을 통해) 어떻게 시작되었는지를 확인하고 앞에서 설명한 대로 기능을 정지한다. 이 작업은 프로그램이 다른 프로그램에 의해 시작되었다면 매우 힘들다; X 서버는 거의 대부분 xdm, kdm, 또는 gdm 같은 디스플레이 매니저로 시작되고 inittab 또는 부트 스크립트 디렉토리에는 보이지 않는다.
netstat으로 열거된 연결은 넷 상의 모든 컴퓨터에서 사용될 필요가 없다: 리눅스의 빌트인 기능에 근거한 방화벽은 패킷이 개방 커넥션에 연결되기 전에 액세스를 조정한다.
감사 준비
일단 기본적인 시스템이 설치되고 안전하게 설정되면 시스템을 안전하게 지키는 것이 궁극적인 목표이다. 시스템에 원치 않은 변경을 확인하려면 시스템의 핑거프린트를 기록하는 감사 툴을 사용한다.
http://www-128.ibm.com/developerworks/k ··· clnx3%2F
"System" 카테고리의 다른 글
- 시스템 관리자를 위한 기초 명령어 활용법 (0)2007/06/22
- 프로세스정보 얻어오기 (0)2007/05/14
- 여러 가지 설정으로 공격으로부터 시스템을 안전하... (0)2007/05/10
- 데이터 문제에 대한 차세대 NFS 계열 파일 시스템... (0)2007/05/10
- inotify를 이용한 리눅스 파일 시스템 감시 (0)2007/05/10
Leave your greetings.