KR20020075601A

KR20020075601A - 접근통제기능을 개선한 리눅스 시스템 및 리눅스 시스템의운영방법

Info

Publication number: KR20020075601A
Application number: KR1020010015693A
Authority: KR
Inventors: 배강호; 성재모; 황장희
Original assignee: 주식회사데이콤
Priority date: 2001-03-26
Filing date: 2001-03-26
Publication date: 2002-10-05
Also published as: KR100396308B1

Abstract

본 발명은 접근통제기능을 개선한 리눅스 시스템 및 리눅스 시스템의 운영방법에 관한 것이다.

본 발명에 따른 리눅스 시스템에 있어서, 각 호스트는 각 프로세스(process)별로 시스템 자원(resource)에의 접근규칙을 설정할 수 있도록 하되, 설정된 접근규칙에 따라 시스템 자원에의 접근허용여부를 결정하는 기능을 가진 리눅스 운영체제(Linux OS)를 탑재한다. 이러한 각 호스트는 로그서버와 연동하는데, 로그서버는 각 호스트에서 전송한 로그정보를 저장하고, 자신과 연동하는 관리자 서버에서 로그 정보를 기 규정된 규칙에 따라 검색할 수 있도록 해준다. 또한, 각 호스트와 로그서버는 관리자 서버와 서로 연동하는데, 관리자 서버는 각 호스트에서의 접근규칙을 설정하고, 로그서버에 있는 로그 정보를 검색한다.

본 발명을 사용하면, 접근통제기능이 강화되고 시스템의 목적에 특화된 운영체제를 구성할 수 있다. 즉, 웹서버 전용이나 파일서버 전용 등 각각의 목적에 맞는 보안 환경 설정이 가능하고, 이를 정형화하여 이용하는 것이 가능하다.

Description

접근통제기능을 개선한 리눅스 시스템 및 리눅스 시스템의 운영방법{Linux System and Operating Method of the Linux System having improved access control function}

본 발명은 접근통제기능을 개선한 리눅스 시스템 및 리눅스 시스템의 운영방법에 관한 것으로서, 특히 슈퍼 유저의 권한 분산과 규칙기반 접근통제(MAC: Mandatory Access Control) 개념을 도입하여 해커가 시스템 침입에 성공하더라도 해커가 궁극적으로 하고자 하는 행동을 차단할 수 있는 리눅스 시스템 및 그 운영방법에 관한 것이다.

현재 인터넷의 역할이 단순한 정보 공유의 차원에서 인트라넷, 전자상거래 등으로 확대되어 감에 따라 해킹 및 정보보호에 대한 관심과 중요도는 더욱 가중되고 있다. 해킹의 발생은 프라이버시의 침해, 재산상의 손실, 기업 이미지의 실추, 기밀 정보의 유출, 서비스의 중단 등으로 이어지고 있어 그 피해규모가 빠른 속도로 증가하고 있다. 특히 기업의 경우에 있어, 해킹을 막느냐 막지 못하느냐의 문제는 기업의 생존과 직결된다고 할 수 있을 것이다.

일반적인 유닉스(UNIX) 운영체제는 접근제어 방식으로 신분기반 접근통제 (DAC:Discretionary Access Control) 방식을 사용하고 있다. 또한, TCSEC(Trusted Computer System Evaluation Criteria)에서는 신분기반 접근통제 정책과 동일한 개념을 DAC로 정의하고 있다. 즉, 주체나 또는 그들이 속해 있는 그룹 등의 신분에 근거하여 객체에 대한 접근을 제한 하는 방법을 DAC라고 정의하는 것이다.

이러한 신분기반 접근통제(DAC) 방식에 있어서의 보안상 가장 큰 문제는 슈퍼 유저의 권한이 분산되어 있지 않고 너무 막강하다는 것이다. 즉 슈퍼 유저의 신분이면 시스템의 모든 환경 설정이 가능하고, 모든 프로세스(process)를 죽이는 것도 가능하다는 것이다. 그러므로, 해커가 취약점을 이용하여 슈퍼 유저가 되면 슈퍼 유저가 할 수 있는 모든 일을 할 수 있게 된다.

현재 신분기반 접근통제(DAC) 방식을 이용하고 있는 유닉스 운영체제가 가지고 있는 문제점을 정리하면 다음과 같다.

1. 슈퍼 유저(root)의 권한 남용이 가능하다.

2. 많은 시스템 파일이 쉽게 변경될 수 있다.

3. 커널을 인터셉트하는데 모듈이 쉽게 이용될 수 있다.

4. 커널(kernel)이 대형화 되고 지원 기능이 많아지면서 커널의 모듈화가 이루어 지고 있으며, 모듈이 커널에 삽입된 이후에는 커널의 일부가 되어 작업을 수행한다. 따라서 악의적 코드가 커널에 삽입되면 심각한 문제를 야기시킬 수 있다.

5. 프로세스가 보호되지 않는다.

한편, 신분기반 접근통제(DAC) 방식과 함께 주로 논의되고 있는 접근제어방식으로 MAC(Mandatory Access Control) 방식이 있다. TCSEC에서는 규칙기반 접근통제 정책과 동일한 개념으로 MAC를 정의하고 있다. 즉, 객체에 포함된 정보의 비밀성(레이블로 표현된 허용등급)과 이러한 비밀성의 접근정보에 대하여 주체가 갖는 권한(clearance))에 근거하여 객체에 대한 접근을 제한하는 방식을 MAC라 한다.

본 발명은 상기와 같은 문제점을 해결하기 위하여 고안된 것으로서, 슈퍼 유저의 권한 분산과 규칙기반 접근통제(MAC: Mandatory Access Control) 개념을 도입하여 보안성을 강화한 리눅스 시스템 및 그 운영방법을 제공하는데 그 목적이 있다.

상기와 같은 목적을 달성하기 위하여 본 발명에 따른 리눅스 시스템은,

각 프로세스(process)별로 시스템 자원(resource)에의 접근규칙을 설정할 수 있도록 하되, 상기 프로세스가 특정 자원에 접근하려고 할 때는 상기 접근규칙을 만족시키는지를 판단하여, 상기 접근규칙을 만족시키는 경우에는 상기 자원에의 접근을 허용하지만, 상기 접근규칙을 만족시키지 못하는 경우에는 상기 자원에의 접근을 차단하고 이에 관한 로그(LOG) 정보를 로그서버로 통보하도록 구성된 리눅스 운영체제(LINUX OS:Operating System)를 탑재한 하나 이상의 호스트; 상기 각 호스트와 연동하여 상기 각 호스트에서 전송한 로그정보를 저장하고, 자신과 연동하는 관리자 서버에서 상기 저장된 로그 정보를 기 규정된 규칙에 따라 검색할 수 있도록 해주는 로그서버; 및 상기 각 호스트와 연동하여 상기 접근규칙을 설정하고, 또한 상기 로그서버와 연동하여 상기 로그 정보를 검색하는 관리자 서버를 포함하여 구성되는 것을 특징으로 한다.

상기 접근규칙은 커널(kernel) 자체에 부여되는 캐퍼빌리티 (capability)를 기록하는 캐퍼빌리티 파일, 및 각 프로세스에 부여되는 접근규칙을 기록하는 접근제어목록(ACL:Access Control List) 파일을 통해 관리하도록 구성하여 바람직하게실시할 수 있다.

상기 운영체제는, 상기 접근제어목록 파일의 내용은 부팅(Booting)시에 메모리에 로드하되, 부팅 후 접근제어목록 파일의 내용이 변경되면 이를 상기 메모리에 반영하여 이용하고, 상기 캐퍼빌리티 파일의 내용은 상기 캐퍼빌리티 파일의 내용을 그대로 가지고 있되 상기 커널에 그 내용을 전달할 때와 그 내용이 변경될 때를 구분하는 기능을 수행하는 캐퍼빌리티 중개파일에서 읽어 이용하도록 구성하는 것이 바람직하다.

이러한 운영체제는, 상기 프로세스가 특정 자원에 접근하려고 할 때는 상기 메모리에 로드된 접근제어목록 정보 혹은 상기 캐퍼빌리티 중개파일의 정보를 통해 접근규칙을 만족시키는지를 판단하여, 상기 접근규칙을 만족시키는 경우에는 상기 자원에의 접근을 허용하지만, 상기 접근규칙을 만족시키지 못하는 경우에는 상기 자원에의 접근을 차단하고 이에 관한 로그(LOG) 정보를 로그서버로 통보하는 커널; 상기 관리자 서버와의 인터페이스 수단; 및 상기 인터페이스 수단을 통해 상기 관리자 서버가 상기 접근제어목록 파일 혹은 캐퍼빌리티 파일을 변경시킬 수 있도록 해주는 접근규칙 갱신수단을 포함하도록 구성할 수 있다.

상기 커널의 기능은 소스코드(source code) 레벨에서 구현하도록 구성하여 더욱 바람직하게 실시할 수 있다.

상기 인터페이스 수단은 커맨드 라인 인터페이스(CLI:Command Line Interface)와 웹 그래픽 사용자 인터페이스(Web GUI:Graphic User Interface) 중 하나 이상을 포함하도록 구성하여 바람직하게 실시할 수 있다.

상기 접근제어목록 파일은 각 프로세스 명칭, 상기 각 프로세스가 접근하려는 객체(Object), 및 상기 객체에 대한 접근유형(Access Type)에 관한 정보로서 그 카테고리를 구성하는 것이 바람직하다.

이 때, 상기 객체는 파일/디렉토리 혹은 캐퍼빌리티이고, 상기 접근유형은 상기 파일/디렉토리에 대해서는 읽기 및 쓰기 금지(DENY), 수정금지(READ), 추가만 가능(APPEND), 및 쓰기가능(WRITE) 중 하나 이고, 상기 캐퍼빌리티에 대해서는 상속(INHERIT)과 불상속(NO_INHERIT) 중 하나 이도록 구성하여 바람직하게 실시할 수 있다.

상기 운영체제는, 상기 커널로부터 상기 접근규칙을 만족시키지 못한 로그정보를 받고, 이 로그정보를 이메일(e-mail)을 통해 상기 관리자 서버로 전송해주는 경보전송수단을 추가로 구비하도록 구성하여 더욱 바람직하게 실시할 수 있다.

한편, 상기 운영체제는 프로세스 자체의 보안 기능을 추가로 구비하도록 구성하는 것이 바람직하다. 즉, 특정 프로세스의 캐퍼빌리티가 중단금지(un-killable)를 나타내는 캐퍼빌리티인 경우에는 해당 프로세스를 중단시키려는 시도를 무시하는 기능; 특정 프로세스의 캐퍼빌리티가 감추기를 나타내는 캐퍼빌리티인 경우에는 프로세스 목록의 디스플레이 기능 수행 중 해당 프로세스를 나타내지 않는 기능; 및 특정 프로세스의 캐퍼빌리티가 모듈삽입제한을 의미하는 캐퍼빌리티인 경우에는 커널에의 모듈 삽입 시도가 있을 때 이를 무시하는 기능 중 하나 이상의 기능을 포함하도록 구성할 수 있다.

또한, 상기 운영체제는 상기 호스트에서 송수신되는 데이터 패킷을 검사하여 통과가 허용된 패킷일 경우에만 통과시키는 기능을 수행하는 네트워크 보안처리수단을 추가로 포함하도록 구성하여 바람직하게 실시할 수 있다.

상기 네트워크 보안처리수단은, 상기 관리자 서버로부터 커맨드 라인 인터페이스(CLI) 혹은 웹 그래픽 사용자 인터페이스(Web GUI)를 통해 상기 데이터 패킷의 통과에 관한 규칙을 설정받되, 이 규칙은 별도의 파일에 기록하여 관리하도록 구성하는 것이 바람직하다.

상기 운영체제는, 기 규정된 시간동안 해당 호스트에서 이루어지는 열려있지 않은 포트로의 접속시도가 기 규정된 회수를 넘는 경우에는 그 리스트를 작성하여 상기 로그서버로 전송하는 기능을 추가로 포함하도록 구성하여 더욱 바람직하게 실시할 수 있다.

상기 로그서버는 상기 관리용 서버와 웹 그래픽 사용자 인터페이스(Web GUI)를 통해 연동하도록 구성하되, 자신이 저장하고 있는 로그정보를 검색하는데 있어서, AND, NOT, OR 중 하나 이상의 검색옵션을 이용하여 검색할 수 있도록 해주는 기능을 포함하도록 구성하여 바람직하게 실시할 수 있다.

본 발명에 따라 리눅스 시스템의 접근통제기능을 강화하기 위한 운영방법은, 각 프로세스별 접근규칙을 설정할 수 있도록 하는 제1 절차; 시스템 자원(resource)에 접근하려는 프로세스(process)가 있는지를 조사하는 제2 절차;상기 조사 결과, 상기 자원에 접근하려는 프로세스가 있는 경우에는 상기 접근규칙을 참조하여 상기 프로세스에게 상기 자원에의 접근이 허용되었는지를 판단하는 제3 절차; 상기 제3 절차에서의 판단 결과, 접근이 허용되어 있으면 상기 프로세스가 해당 자원에 접근할 수 있도록 허용하는 제4 절차; 및 상기 제3 절차에서의 판단 결과, 접근이 허용되어 있지 않은 경우에는 상기 프로세스의 동작을 중단시키고 이에 관한 로그정보를 기록하는 제5 절차를 포함하여 구성되는 것을 특징으로 한다. 이러한 절차는 각 호스트에 탑재되는 리눅스 운영체제에서 수행하는 것이다.

상기 제1 절차에서 설정하는 접근규칙은, 커널(kernel) 자체에 부여되는 캐퍼빌리티(capability)를 기록하는 캐퍼빌리티 파일, 및 각 프로세스에 부여되는 접근규칙을 기록하는 접근제어목록(ACL:Access Control List) 파일에 설정하도록 구성하는 것이 바람직하다.

상기 접근규칙은 타 컴퓨터 시스템(관리자 서버)으로부터 설정받도록 구성하되, 상기 관리자 서버와의 인터페이스는 커맨드 라인 인터페이스(CLI) 혹은 웹 스래픽 사용자 인터페이스(Web GUI)를 통해 이루어지도록 구성하여 바람직하게 실시할 수 있다.

이때 상기 제3 절차는, 상기 제2 절차에서 시스템 자원에 접근하고자 하는 프로세스가 커널 자체의 프로세스인지 혹은 개별적인 프로세스인지를 판단하는 단계; 상기 판단 결과 커널 자체의 프로세스인 경우에는 상기 캐퍼빌리티 중개파일에 기록된 접근규칙을 만족시키는지를 판단하는 단계; 및 상기 판단 결과 개별적인 프로세스인 경우에는 상기 메모리에 로드된 접근제어목록 정보에 규정된 접근규칙을 만족시키는지를 판단하는 단계를 포함하도록 구성하여 바람직하게 실시할 수 있다.

위에서 설명한 바와 같이, 상기 접근제어목록 파일은 각 프로세스 명칭, 상기 각 프로세스가 접근하려는 객체(Object), 및 상기 객체에 대한 접근유형(Access Type) 정보를 포함하도록 구성하는 것이 바람직하다.

여기서, 상기 객체는 파일/디렉토리 혹은 캐퍼빌리티이고, 상기 접근유형은 상기 파일/디렉토리에 대해서는 읽기 및 쓰기 금지(DENY), 수정금지(READ), 추가만 가능(APPEND), 및 쓰기가능(WRITE) 중 하나 이고, 상기 캐퍼빌리티에 대해서는 상속(INHERIT)과 불상속(NO_INHERIT) 중 하나 이도록 구성할 수 있다.

상기 제5 절차는, 상기 접근규칙을 만족시키지 못한 로그정보를 이메일(e-mail)을 통해 관리자 서버로 전송해주는 절차를 추가로 구비하도록 구성하여 보다 바람직하게 실시할 수 있다.

한편, 상기 리눅스 시스템의 운영방법은 네트워크 보안절차를 추가로 포함하도록 하여 더욱 바람직하게 실시할 수 있다.

이러한, 상기 네트워크 보안 절차는 데이터 패킷의 통과 규칙을 설정하는 단계; 송수신되는 데이터 패킷이 있는지를 조사하는 단계; 상기 조사 결과, 송수신되는 데이터 패킷이 있는 경우에는 상기 설정된 규칙을 참조하여 통과시킬 것인지를 판단하는 단계; 및 상기 판단 결과, 통과가 허용된 경우에는 해당 데이터 패킷을그 방향으로 통과시키되, 그렇지 않은 경우에는 드롭(drop) 시키는 단계를 포함하도록 구성하여 바람직하게 실시할 수 있다.

또한, 상기 네트워크 보안절차는 열려있지 않은 포트로의 접속시도가 있는지를 조사하는 단계; 상기 조사 결과 접속시도가 있는 경우에는 이 접속시도가 기 규정된 시간동안 기 규정된 회수를 넘는지를 판단하는 단계; 및 상기 판단 결과, 그 회수를 넘는 경우에는 규정된 로그서버로 이를 통보하는 단계를 추가로 포함하도록 구성하여 더욱 바람직하게 실시할 수 있다.

도 1은 본 발명에 따른 리눅스 시스템의 일 실시예에 관한 구성도,

도 2는 본 발명에 따른 리눅스 운영체제의 동작에 관한 일 실시예의 흐름도,

도 3은 로그서버의 동작에 관한 일 실시예의 흐름도,

도 4는 관리자 서버의 동작에 관한 일 실시예의 흐름도,

도 5는 본 발명에 따른 리눅스 시스템의 바람직한 상세 구성도,

도 6은 캐퍼빌리티의 예,

도 7은 접근제어목록(ACL) 파일의 카테고리에 관한 구성예,

도 8은 접근제어목록(ACL) 파일의 구성예,

도 9는 접근규칙 반영 과정에 관한 일 실시예의 흐름도,

도 10은 프로세스 보안기능에 관한 제1 실시예의 흐름도,

도 11은 프로세스 보안기능에 관한 제2 실시예의 흐름도,

도 12는 프로세스 보안기능에 관한 제3 실시예의 흐름도,

도 13은 네트워크 보안기능에 관한 제1 실시예의 흐름도,

도 14는 네트워크 보안기능에 관한 제2 실시예의 흐름도,

도 15는 로그서버의 구성에 관한 일 실시예,

도 16은 로그서버의 GUI 구성에 관한 실시예를 도시한 것이다.

* 도면의 주요 부호에 관한 설명

10-1 내지 10-3: 호스트11: 리눅스 운영체제

12: 커널12-1: 프로세스

12-2: 접근규칙 검사수단12-3: 접근제어목록(메모리)

12-4: 접근제어목록 파일12-5: 캐퍼빌리티 중계화일

12-6: 캐퍼빌리티 파일12-7: 로그 처리수단

13: 접근규칙 갱신수단14-1: CLI 처리수단

14-2: Web GUI 수단15: 네트워크 보안처리수단

16: 경보전송수단20: 로그서버

21: Web GUI 수단22-1: 수신 IP 리스트 파일

22-2: 초기화 수단22-3: 로그수신수단

22-4: 로그필터수단22-5: 로그저장수단

22-6: 로그 테이블30: 관리자 서버

이하, 첨부된 도면을 참조하여 본 발명을 상세히 설명하기로 한다.

도 1은 본 발명에 따른 리눅스 시스템의 일 실시예에 관한 구성도로서, 하나 이상의 호스트(10-1 내지 10-3), 각 호스트(10-1 내지 10-3)와 연동하는 로그서버(20)와 관리자 서버(30)로 이루어지는데, 관리자 서버(30)와 로그서버(20)도 서로 연동한다. 각 호스트(10-1 내지 10-3)에는 본 발명에 따른 리눅스(LINUX) 운영체제(OS:Operating System)가 탑재된다. 이하에서의 "리눅스 운영체제"라 함은 본 발명에 따른 기능을 수행하도록 설계된 운영체제를 의미하는 것으로 사용한다.

도 2를 참조하여 리눅스 운영체제의 기능을 구체적으로 설명하기로 한다.

먼저, 리눅스 운영체제는 시스템 자원(resource)에 접근할 수 있는 접근규칙을 설정할 수 있도록 한다(S210). 그리고, 어느 프로세스(process)가 특정 시스템자원에 접근하려고 하는지를 조사하고 있다가 자원에 접근하려고 시도하는 프로세스가 있는 경우에는(S211), 설정된 접근규칙을 검색하여 해당 자원에의 접근이 허용되어 있는지를 판단한다(S212). 이 판단결과, 접근이 허용되어 있는 경우에는 자원에의 접근을 허용하고(S214) 프로세스가 계속 수행되도록 처리한다(S215). 그러나, 접근이 허용되어 있지 않은 경우에는 자원에의 접근을 차단하고 프로세스를 중단한 후(S216), 이에 관한 로그(LOG) 정보를 로그서버(20)로 전송한다(S217).

도 3을 참조하여 로그서버(20)의 기능을 설명하자면, 로그서버(20)는 각 호스트(10-1 내지 10-3)로부터의 로그정보 수신을 대기하다가 로그정보를 수신하면 이를 데이터베이스에 저장한다(S310,S311). 또한, 로그서버(20)는 관리자 서버(30)로부터의 로그정보 검색요청이 있으면(s312), 데이터베이스를 검색하여(S313) 관리자 서버(30)에게 제공한다(S314).

한편, 관리자 서버(30)는 각 호스트(10-1 내지 10-3)에서 사용할 접근규칙을 설정하는 역할과 로그서버(20)를 통해 각 호스트(10-1 내지 10-3)에서 발생한 비정상적 접근정보를 검색하는 역할을 수행한다.

도 4를 참조하자면, 관리자 서버(30)는 각 호스트(10-1 내지 10-3)의 접근규칙을 변경하고자 하는 경우에는(S410), 해당 호스트(예:10-1)에 접속하여(S411) 접근규칙을 변경하게 되며(S413), 변경된 내용은 호스트(10-1)에 저장된다(S413). 또한, 관리자 서버(30)는 로그정보의 검색이 필요한 경우에는(S420), 로그서버(20)에접속하여(S421) 필요한 로그정보를 검색해줄 것을 요청하며(S422), 로그서버(20)는 요청된 로그정보를 검색하여(S423) 관리자 서버(30)로 전송해준다(S424).

도 5는 본 발명에 따른 리눅스 시스템의 바람직한 실시예에 관한 상세 구성도로서, 이를 참조하여 본 발명을 더욱 상세히 설명하기로 한다.

각 호스트(10-1 내지 10-3)에 탑재되는 리눅스 운영체제(11)는 커널(12), 접근규칙 갱신수단(13), 관리자 서버와의 인터페이스 수단(14-1,14-2), 네트워크 보안처리수단(15), 경보전송수단(16) 등을 포함하고 있다.

여기서, 커널(12)은 리눅스 시스템의 기본 기능 이외에도, 프로세스(12-1)가 특정 자원에 접근하려고 할 때는 메모리에 로드된 접근제어목록(ACL:Access Control List) 정보(12-3) 혹은 캐퍼빌리티 중계파일(12-5)의 캐퍼빌리티 정보를 통해 접근규칙을 만족시키는지 판단한다. 그리고, 접근규칙을 만족시키는 경우에는 자원에의 접근을 허용하지만, 접근규칙을 만족시키지 못하는 경우에는 자원에의 접근을 차단하고 이에 관한 로그(LOG) 정보를 로그서버(20)로 통보하는 기능을 수행하는 유닉스 운영체제의 핵심부분이다. 이러한 판단은 접근규칙 검사수단(12-2)에서 이루어진다.

또한, 접근규칙 검사수단(12-2)은 접근규칙을 만족시키지 않는 비정상 접근시도에 관한 정보를 로그처리수단(12-7)으로 보내 로그서버(20)로 전송하도록 한다. 이 때, 더욱 신속하게 호스트의 상태의 파악하기 위하여, 커널(12)의 로그처리수단(12-7)은 경보전송수단(16)으 비정상 접근정보를 보내주어 경보전송수단(16)이이메일(e-mail)을 통해 관리자 서버(30)로 이를 알리도록 한다. 전자메일의 발송과 관련한 정보는 경보관련정보 파일(16-1)에 기록하도록 한다.

경보관련정보 파일(16-1)의 구성예를 다음의 표 1에 나타내었다.

MAIL_SWITCH=1# MAIL_REPLAY=hex IP:portMAIL_RELAY=210.73.88.149:25# MAIL_SOURCE=source machine :MAIL_SOURCE=pandora.domain_name.com

즉, MAIL_SWITCH 값이 1로 설정되면, 보안 경고 발생시 그 내용이 설정 내용에 따른 주소로 이메일에 의해 발송된다. 위의 예에서 메일을 전달할 서버의 주소와 포트 번호는 각각 210.73.88.149와 25이다. 그리고 MAIL_SORUECE는 호스트 확인에 이용되는 정보를 명시하는 것이다.

이 때, 위에서 설명한 커널(12)의 기능은 소스코드(source code) 레벨에서 구현하도록 구성하는 것이 바람직하다.

관리자 서버와의 인터페이스 수단은 호스트(10-1)의 리눅스 운영체제(11)와 관리자 서버(30)와의 인터페이스를 위한 구성요소로서, 커맨드 라인 인터페이스 (CLI)와 웹 그래픽 사용자 인터페이스(Web GUI)로 이루어지도록 하는 것이 바람직하다. 이 때 커맨드 라인 인터페이스는 CLI 처리수단(14-1)에서 제공하고, 웹 그래픽 사용자 인터페이스는 Web GUI 처리수단(14-2)에서 제공한다.

여기서, 커맨드 라인 인터페이스(CLI)는 관리자가 원하는 접근제어 규칙을 설정하고 확인하는 작업을 터미널에서 할 수 있도록 하는 기능을 의미한다. 또한, Web GUI를 위해서 호스트(10-1)와 로그서버(20)는 웹 서버(Web Server), 사용자가 입력한 접근규칙의 설정 내용이나 로그서버 검색 내용을 처리하기 위한 CGI(Common Gateway Interface) 프로그램들을 가지고 있다. 이러한 인터페이스 수단(14-1,14-2)을 통해 관리자 서버(30)는 각 호스트(10-1 내지 10-3)에서의 접근규칙을 설정할 수 있게 되며, 접근규칙은 접근규칙 갱신수단(13)을 통해 커널(12)에 전달된다.

한편, 본 발명의 가장 중요한 핵심은 각 프로세스의 자원접근 허용 여부를 결정하는 접근규칙인데, 이 접근규칙에 대하여 상세히 설명하기로 한다.

접근규칙은 커널(kernel:12) 자체에 부여될 접근규칙과 개별적인 프로세스에 부여될 접근규칙으로 나눌 수 있다. 커널 자체에 부여되는 접근규칙은 캐퍼빌리티 (capability)로서 표시하여 캐퍼빌리티 파일(12-6)에 기록하며, 개별적인 프로세스에 부여되는 접근규칙은 접근제어목록(ACL:Access Control List) 파일(12-4)을 통해 관리하도록 하는 것이 바람직하다.

여기서, 캐퍼빌리티란 "POSIX draft 1003.1e"에서 출발하였으며, 기본적으로는 슈퍼 유저의 권한을 나누기 위한 것이다. 리눅스 운영체제에서 이용할 수 있는 캐퍼빌리티의 예를 도 6에 도시하였다. 이하에서 설명하는 바와 같이, 이러한 캐퍼빌리티는 커널 전반에 적용되는 접근규칙으로서 사용되고, 또한 개별 프로세스에 대한 접근규칙에서의 객체로서도 사용된다.

캐퍼빌리티 파일에의 캐퍼빌리티 등록으로서, 커널 전반에 걸쳐 슈퍼 유저에 부여되는 권한을 제한할 수 있다.

예를 들어, 캐퍼빌리티 파일에서 CAP_SYS_ADMIN 캐퍼빌리티를 제거하면 슈퍼 유저도 CAP_SYS_ADMIN 캐퍼빌리티를 사용할 수 없다. 즉, 슈퍼 유저도 시스템의 도메인 이름이나 호스트 이름을 바꿀 수 없게 되는 것이다. 다른 예로서 CAP_NET_BIND_SERVICE 캐퍼빌리티가 제거되면, 슈퍼 유저도 1024이하의 포트를 사용하는 네트워크 데몬을 구동시킬 수 없게 된다.

커널 전반에 걸쳐 부여되는 접근규칙 이외에 각 프로세스별로 접근규칙이 설정될 수 있는데, 위에서 설명한 바와 같이 개별적인 프로세스의 접근규칙은 접근제어목록(ACL) 화일(12-4)에 저장되어 관리된다.

도 7은 접근제어목록(ACL) 파일의 카테고리에 관한 구성예로서, 접근제어목록 파일(12-4)은 각 프로세스 명칭(subject), 각 프로세스가 접근하려는 객체(Object), 및 객체에 대한 접근유형(Access Type)에 관한 정보를 포함하도록 구성하는 것이 바람직하다.

여기서, 객체는 파일/디렉토리(File/Dir.) 혹은 캐퍼빌리티(Capability)이다. 또한, 다음의 표 2에 보인 바와 같이 접근유형은 파일/디렉토리에 대해서는 읽기 및 쓰기 금지(DENY), 수정금지(READ), 추가만 가능(APPEND), 및 쓰기가능(WRITE) 중 하나 일 수 있으며, 캐퍼빌리티에 대해서는 상속(INHERIT)과 불상속(NO_INHERIT) 중 하나일 수 있다.

객체종류	Acess Type	내용
file/directory	DENY	읽기 및 수정금지
	READ	수정금지
	APPEND	추가만 가능, 이전내용의 삭제나 수정금지
	WRITE	쓰기도 가능
capability	INHERIT	주체 프로세스가 실행시키는 프로세스에도 이 capability가 부여됨
capability	NO_INHERIT	주체 프로세스가 실행시키는 프로세스에는 이 capability가 부여되지 않음.

표 2의 내용을 구체적으로 설명하기로 한다.

DENY : 객체가 파일 또는 디렉토리인 경우 적용되는 접근유형으로서 누구도 객체를 읽거나 수정할 수 없도록 설정한다. 중요한 시스템 파일 등에 적용가능하며, CLI 처리수단(14-1)을 이용한 설정 예는 다음과 같다. 여기서 #pandoradm은 CLI 처리수단(14-1)의 구동 명령을 의미하는 것으로 가정한다.

#pandoradm -A -o /etc/shadow -j DENY

CLI 처리수단(14-1)은 다음의 표 3에 도시한 예와 같은 옵션을 설정할 수 있도록 하여 바람직하게 실시할 수 있다.

-A : 접근제어 규칙이 추가됨을 알림-s : 주체(subject)가 이어짐을 알림-o : 객체(object)가 이어짐을 알림-j : 접근유형(Access Type)이 이어짐을 알림

READ : 객체가 파일 또는 디렉토리인 경우 적용되는 접근유형으로서 누구도 객체를 수정할 수 없도록 설정한다. 중요한 시스템 실행파일이 트로이 목마 등으로 수정되는 것을 방지하는 것 등에 이용될 수 있다. CLI 처리수단(14-1)을 이용한 설정 예는 다음과 같다.

#pandoradm -A -o /sbin/ -j READ

WRITE : 객체가 파일 또는 디렉토리인 경우 적용되는 접근유형으로서 객체에 대한 수정이 가능하도록 설정한다. 접근제어목록(ACL)에 특별히 접근규칙이 명시되지 않은 객체에 대한 접근은 기존의 신분기반 접근통제(DAC) 방식의 접근제어를 따르도록 한다. 따라서, DENY, READ, APPEND가 미리 설정되어 있지 않은 객체에 대하여 WRITE 접근 형태를 허용할 필요는 없는 것이다. WRITE는 특정 주체, 즉 프로세스에게 DENY, READ, APPNED로 설정되어 있는 객체에 대하여 WRITE가 가능하도록 설정하기 위한 것이다. 이는 주로 특정 어플리케이션 프로세스가 실행을 위하여 접근하는 객체에 대해서 이용한다. CLI 처리수단(14-1)을 이용한 설정 예는 다음과 같다.

#pandoradm -A -o /var/log/wtmp -j DENY

APPEND : 객체가 파일 또는 디렉토리인 경우 적용되는 접근유형으로서 누구도 객체에 대한 추가만 가능하도록 설정한다. 빈번히 쓰기가 이루어지지만, 내용을 보존하여야 하는 경우에 이용 가능할 것이다. 주로 로그 파일이 중요한 적용 예라 할 수 있을 것이다. CLI 처리수단(14-1)을 이용한 설정 예는 다음과 같다.

#pandoradm -A -o /var/log/messages -j APPEND

상속/불상속(INHERIT/NO_INHERIT) : 객체가 캐퍼빌리티(capability)일 때 사용 가능한 접근유형(Access Type)으로서, 주체에 부여된 캐퍼빌리티가 주체가 실행시키는 프로그램에도 상속되어 부여되느냐의 여부를 설정한다. 프로세스가 실행을 위해서 다른 프로세스를 실행하고, 실행된 프로세스에도 그 캐퍼빌리티가 필요한 경우에는 INHERIT으로 설정하고 그렇지 않은 경우에는 NO_INHERIT로 설정한다. 안전성을 고려하면, 캐퍼빌리티의 상속이 필요 없는 경우에는 NO_INHERIT로 설정하는 것이 바람직하다.

접근제어목록(ACL) 파일의 구성예를 도 8에 도시하였다.

여기서, 각 프로세스별로 부여되는 캐퍼빌리티의 의미를 보다 구체적으로 설명하기로 한다.

프로세스가 구동되기 위해서는 특정 캐퍼빌리티가 요구되는 경우가 많이 있다. 예를 들어 웹서버를 구동시키기 위해서는 80번 TCP 포트를 이용하여야 하므로, CAP_NET_BIND_SERVICE 캐퍼빌리티가 필요하다.

그런데 기존에는 슈퍼 유저가 CAP_NET_BIND_SERVICE 캐퍼빌리티를 가지고 있으므로, 슈퍼 유저만이 웹서버를 80번 포트로 구동시킬 수 있었다. 그러나, CAP_NET_BIND_SERVICE 캐퍼빌리티는 웹서버가 이용하는 80번 포트에 한정되는 것이 아니라 1024이하의 모든 포트의 바인딩을 가능하게 하는 캐퍼빌리티이다. 그러므로 슈퍼 유저 계정을 해킹한 해커가 다른 위험한 데몬 프로그램을 구동시킬 수도 있는 것이다.

이에 대한 해결책으로 http 데몬 프로세스에 개별적으로 CAP_NET_BIND_SERVICE 캐퍼빌리티를 부여한다면, 해커가 슈퍼 유저의 권한을 획득하더라도 CAP_NET_BIND_SERVICE 캐퍼빌리티를 이용해서 할 수 있는 것이 웹서버 구동으로 제한되어 진다. 즉, 프로세스별로 그 프로세스의 구동에 꼭 필요한 캐퍼빌리티만을 부여함으로써, 해킹시 해커가 할 수 있는 권한을 최소한으로 한정시켜 버릴 수 있다.

도 9는 접근규칙 반영 과정에 관한 일 실시예의 흐름도로서, 이를 참조하여 리눅스 운영체제(11)가 설정된 접근규칙을 어떻게 반영하는가를 보다 구체적으로 설명하기로 한다.

리눅스 운영체제(11)는 해당 호스트(10-1)가 부팅(BOOTING)될 때(S510), 접근제어목록 파일(12-4)의 내용을 메모리(12-3)에 로드하여 이용한다(S511). 또한, 관리자 서버(30)를 통해 개별 프로세스에 대한 접근규칙이 변경되면 그 변경내용은 접근제어목록 파일(12-4)에 저장되고(S512), 메모리 영역(12-3)에 있는 접근제어목록 정보에 반영된다(S513).

만일, 관리자 서버(30)를 통한 커널 자체의 캐퍼빌리티 변경이 이루어지면 캐퍼빌리티 파일(12-6)이 변경되며(S514), 이 파일의 변경 사항은 캐퍼빌리티 파일(12-6)의 내용을 그대로 가지고 있되 커널(12)에 그 내용을 전달할 때와 그 내용이 변경될 때를 구분하는 기능을 수행하는 캐퍼빌리티 중개파일 (예:/proc/sys/pandora /locks)에 반영한다(S515).

즉, 외부에서의 개별적인 프로세스에 대한 접근규칙의 변경과 커널 자체의 캐퍼빌리티 변경은 각각 접근제어목록 파일(12-4)과 캐퍼빌리티 파일(12-6)에서 이루어지지만, 리눅스 커널(12)에의 반영은 각각 메모리 영역(12-3)과 캐퍼빌리티 중계파일(12-5)을 통해 이루어지는 것이다.

또한, 커널(12)은 부팅이 종료된 후 새로이 생성된 프로세스에는 기 규정된 기본 캐퍼빌리티를 일단 할당한다. 물론, 기본적으로 할당된 캐퍼빌리티는 관리자 서버(30)에 의하여 변경될 수 있다.

프로세스 생성시 부여되는 기본적인 캐퍼빌리티(capability)라 함은 원래 일반적인 유닉스 운영체제의 신분기반 접근통제(DAC)에 기반을 둔 접근제어가 제공하는 캐퍼빌리티와 본 발명에 따른 유닉스 운영체제에서 기본적으로 허용시켜준 캐퍼빌리티중 공통되는 것들을 의미한다.

예로서, CAP_NET_BIND_SERVICE 캐퍼빌리티는 1024이하의 TCP/UDP 포트를 열어 서비스가 가능하게 하는 캐퍼빌리티이다. 이 캐퍼빌리티는 일반적인 유닉스에서는 슈퍼 유저만이 사용할 수 있는 것이다. 만약 리눅스 운영체제가 이 캐퍼빌리티를 기본적으로 제한하였다면, 슈퍼 유저도 1024 이하의 포트에 대한 바인딩을 할 수 없게 되는 것이다. 그러나 리눅스 운영체제에서 이 캐퍼빌리티에 대한 기본 설정값을 허용하였다고 하여도, 일반 사용자가 1024이하의 포트에 대한 바인딩을 할 수 없는 것이다. 접근제어목록(ACL) 정보에는 프로세스의 파일이나 캐퍼빌리티에 대한 허용 여부가 정의되어 있어 이를 통한 접근제어가 가능하기 때문이다.

한편, 본 발명에 따른 리눅스 운영체제는 프로세스 자체의 보안 기능을 제공하도록 하여 더욱 바람직하게 실시할 수 있는데, 그 바람직한 실시예로서 Un-Killable 프로세스 만들기, 프로세스 숨기기, 커널 모듈 삽입 제한이라는 세가지 기능을 제공한다.

먼저, Un-Killable 프로세스 만들기 기능은 중요한 프로세스의 실행을 중지시킬 수 없게 설정하는 것이다. 해커가 슈퍼 유저의 권한을 획득하더라도 중요 프로세스를 중단시키지 못하도록 하여 서비스의 중단 등과 같은 사태가 일어나지 못하도록 하는 것이다.

도 10을 참조하여 Un-Killable 프로세스 만들기 기능을 구체적으로 설명하자면, 커널(12)은 특정 프로세스에 대한 kill 시도가 있으면(S611), 이 프로세스의 캐퍼빌리티를 검사하여(S612), kill이 가능하게 설정되어 있는 경우에만(S613) 해당 프로세스를 kill 시킨다(S614). 그렇지 않은 경우에는 kill 시도를 차단한다.

프로세스 숨기기 기능은 특정 프로세스의 동작 여부가 ps 명령어를 실행시켜도 나타나지 않도록 하는 것이다. 이는 침입탐지시스템 등 특정 프로세스의 운영 여부를 숨기기 위해서도 이용되며, 프로세스 아이디(ID)를 알지 못하게 하여 해커가 프로세스를 kill 하는 것을 방지할 목적으로도 사용 가능하다.

도 11을 참조하여 프로세스 숨기기 기능을 구체적으로 설명하자면, 커널(12)은 특정 프로세스에 대한 ps 요구가 있으면(S621), 이 프로세스의 캐퍼빌리티를 확인하여(S622), 감추기로 설정되어 있지 않은 경우에만(S623), 해당 프로세스를 디스플레이한다(S624). 그렇지 않은 경우에는 디스플레이하지 않는다.

그리고 다양하고 복잡해진 커널 기능의 효과적인 동작을 위하여 커널의 모듈화가 많이 이용되고 있는데, 이 모듈 속에 악성 코드가 숨어 있을 가능성이 있다. 커널 모듈 삽입 제한이란 함부로 모듈을 커널 속에 삽입할 수 없도록 하는 기능을 말한다.

도 12를 참조하여 커널 모듈 삽입 제한 기능을 구체적으로 설명하자면, 커널(12)은 특정 모듈의 커널 삽입 시도가 있으면(S631), 이 프로세스의 캐퍼빌리티를 확인하여(S632), 모듈 삽입이 가능하게 되어 있는 경우에만(S633) 해당 프로세스를 커널에 삽입할 수 있게 한다(S634). 그렇지 않은 경우에는 모듈 삽입 시도를 차단한다.

또한, 리눅스 운영체제는 네트워크 보안기능을 제공하여 더욱 바람직하게 실시할 수 있다. 도 5에 도시한 실시예에서 보면 이 기능은 네트워크 보안 처리수단(15)에서 수행하는데, 보안기능을 위한 설정은 인터페이스 수단(14-1,14-2)을 통해 설정된다. 네트워크 보안 처리수단(15)은 네트워크 보안기능으로서의 바람직한 실시예로서 방화벽(Firewall) 기능과 포트 스캐닝(Port Scanning) 기능을 제공한다.

방화벽 기능은 호스트(10-1)에서 송수신되는 데이터 패킷을 검사하여 통과가 허용된 패킷일 경우에만 통과시키는 기능이다.

이를 통해 허용되지 않은 곳으로부터의 네트워크 서비스 요청을 차단하여 해커의 침입을 미연에 차단하는 기능을 수행한다. 즉, 보호 대상 네트워크와 인터넷의 연결 길목에서 왕래하는 패킷의 헤더 정보를 이용하여 패킷의 통과 여부를 결정하는 시스템이라 할 수 있다. 여기서 패킷의 헤더 정보를 활용한다는 것은 패킷 헤더에서 다음의 정보를 추출하여 패킷의 통과여부를 결정한다는 것이다.

- 패킷의 출발지 주소(source address)

- 패킷의 출발지 포트(source port)

- 패킷의 도착지 주소(destination address)

- 패킷의 도착지 포트(destination port)

도 13을 참조하여 방화벽 기능의 바람직한 실시예를 구체적으로 설명하자면, 네트워크 보안처리수단(15)은 송수신될 데이터 패킷이 있는 경우에는(S711), 먼저 해당 데이터 패킷이 정상적인 데이터 패킷인지를 검사한다(S712). 이 검사에는 체크섬(Checksum) 검사와 정상성 테스트(Sanity)가 있다.

단계 S712에서의 검사결과 정상적인 데이터 패킷이 아닌 경우에는(S713), 이를 무시하되(S717) 정상적인 데이터 패킷인 경우에는 기 규정된 통과규칙을 만족하는지를 판단한다(S714). 그리고, 통과규칙을 만족하는 경우(S715), 데이터 패킷을 그 다음 경로로 통과시키되 (S716), 그렇지 않은 경우에는 이에 관한 로그정보를 기록한다(S718).

단계 S714에서의 통과규칙은 데이터 패킷 헤더의 내용에 따른 처리규정을 의미하며, 인터페이스 수단(14-1, 14-2)을 통해 관리자 서버(30)에서 설정한다. 예를 들어 기본적인 정책을 모든 패킷을 차단한다 로 설정하고, telnet 서비스만 허용하고자 한다면, 방화벽 접근제어 규칙에 패킷의 도착지 포트가 23인 패킷만 통과시키도록 설정하면 되는 것이다. 그리고 CAP_NET_ADMIN 캐퍼빌리티를 슈퍼 유저 권한에서 제거시킨다면, 해커가 슈퍼 유저 권한을 해킹하더라도 이 방화벽 접근제어 규칙을 수정할 수 없게 된다.

또한, 캐퍼빌리티(capability)를 이용해서 네트워크 보안을 향상시킬 수 있다. 즉 다음의 캐퍼빌리티를 제거하거나, 꼭 필요한 프로세스에만 부여함으로써 네트워크 보안을 강화할 수 있다.

CAP_NET_ADMIN: 이는 방화벽의 관리, 라우팅 테이블의 수정, NIC(Network Interface Card)의 promiscuous 모드 설정 등을 가능하게 하는 캐퍼빌리티이다. 따라서 이 캐퍼빌리티를 제거한다면, 해커가 방화벽 접근 제어 규칙을 변경하거나 라우팅 테이블의 임의 수정, 그리고 스니퍼(sniffer) 프로그램을 구동시키는 것을 방지할 수 있다.

CAP_NET_BIND_SERVER: 이는 TCP/UDP 소켓에 1024이하의 포트 바인딩을 가능하게 하는 캐퍼빌리티이다. 이 캐퍼빌리티를 제거한다면, 해커가 포트번호 1024이하의 서비스를 악의의 목적으로 구동시키는 것을 방지할 수 있다.

이러한 방화벽 기능의 주요 목적은 본 발명에 따른 리눅스 운영체제가 장착된 호스트로 오는 패킷을 통제하는데 있다.

포트 스캐닝 기능은 기 규정된 시간동안 해당 호스트에서 이루어지는 열려있지 않은 포트로의 접속시도가 기 규정된 회수를 넘는 경우에는 그 리스트를 작성하여 로그서버(20)로 통보하는 기능을 의미한다. 즉, 해킹을 위한 수단으로 많이 이용되고 있는 포트 스캐닝 도구가 유닉스 시스템에 적용되면, 이 사실을 탐지하여 통보하는 기능이다.

포트 스캐닝(Port Scanning)을 하는 것은 주로 짧은 시간에 많은 수의 포트에 대하여 연결시도를 행함으로써 이루어진다. 이에 착안하여 유닉스 운영체제는 짧은 시간동안에 특정 호스트에서 이루어지는 열려있지 않은 포트로의 접속시도에 대한 값을 바탕으로 탐지하게 된다. 단지 리스트만을 유지하도록 하면 성능 저하의 문제를 차단할 수 있다. 그리고, DoS(Denial of Service)에 대한 대응책으로 유지되는 리스트의 값을 제한하고, 이에 대한 보완책으로 일정 시간(예:3초)에 한번씩 리스트를 삭제하도록 구성하는 것이 바람직하다.

도 14를 참조하여 포트 스캐닝 기능을 구체적으로 설명하자면, 먼저 관리자 서버(30)는 인터페이스 수단(14-1,14-2)을 통해 검사 시간과 접근시도회수를 설정한다(S721). 이 정보는 네트워크 보안관련 정보를 저장하는 파일에 기록되어 참조된다. 네트워크 보안 처리수단(15)은 접근이 허용되지 않은 포트로의 접속시도가 있는지를 조사하고 있다가(S722), 이러한 접속시도가 있는 경우에는 규정된 시간동안 규정된 회수의 접근시도가 이루어지는지 경우에는(S723), 리스트를 만들고 이를 로그서버(20)로 통보한다(S724).

이제, 로그서버(20)에 대하여 보다 구체적으로 설명하기로 한다.

먼저, 로그서버는 각 호스트(10-1 내지 10-3)로부터 오는 로그를 데이터베이스에 저장하는 역할을 한다. 그리고 데이터가 디스크의 용량을 초과하지 않도록 적절한 분배작업이 이루어지며, 데이터의 백업이 용이하도록 데이터베이스를 관리한다. 이 때, DBMS를 활용하는 것이 바람직하다.

도 15를 참조하여 보다 상세하게 설명하자면, 로그서버의 초기화 수단(22-2)은 설정 파일(22-1)에서 수신 IP 주소 리스트와 Drop 로그 패턴 리스트를 읽어 들인 후, 일정 포트(예: UDP 514 포트)를 열고 각 호스트(10-1 내지 10-3)로부터 전송되는 로그 메시지의 수신을 대기한다.

로그수신수단(22-3)은 로그 메시지가 수신되면 로그 메시지를 보낸 호스트의 IP 주소가 수신 허용 IP 주소 리스트에 있는지를 조사한다. 그리고, 수신 허용 IP 주소 리스트에 있는 경우에는 이를 받아들여서 로그필터수단(22-4)으로 로그 메시지를 전송한다. 그러나, 수신 허용 IP 주소 리스트에 없는 경우는 해당 메시지를 드롭(drop) 한다.

로그필터수단(22-4)은 로그수신수단(22-3)으로부터 받은 로그 메시지에 Drop 로그 패턴 리스트의 항목이 존재하는지를 조사하여, Drop 로그 패턴 리스트의 항목이 존재하는 경우에는 메시지를 드롭(drop) 하고, 존재하지 않는 경우에는 로그저장수단(22-5)으로 로그 메시지를 전송한다.

로그저장수단(22-5)은 로그 메시지를 DBMS의 로그 테이블(22-6)에 저장한다. 이 때, 로그 메시지의 저장은 설정 파일에서 정해진 최대 행(Row)의 개수만큼 저장되고 그 이상 로그가 들어오면 처음부터 다시 저장하게 된다. 예로서, 총 6 개의 로그 테이블로 구성할 수 있으며, 일정 주기(예: 1개월)마다 로그 테이블(22-6)을 변경하는 것이 바람직하다. 이 과정에서 이용되는 DBMS 테이블로는 로그 테이블과 시스템 테이블이 있다. 로그 테이블은 로그 메시지를 저장하기 위한 것이고, 시스템 테이블은 로그 저장과 관계된 전역변수를 저장하기 위해 사용할 수 있다.

또한, 로그서버(20)는 관리자가 원하는 조건에 따라 로그를 검색할 수 있는 검색기능을 제공한다. 보다 바람직하게는 로그가 발생한 시스템이나 발생일자 등에 대하여 AND, OR 와 NOT 조건을 부가하여 검색하는 기능을 제공하도록 한다.

로그서버(20)는 관리자의 로그 검색을 용이하게 하기 위하여 관리자 서버(30)와의 사이에서 Web GUI 수단(21)을 통해 웹 기반의 그래픽 사용자 인터페이스(GUI)를 제공한다. 이를 위해서 로그서버(20)는 HTML 생성 및 데이터베이스 검색을 위한 CGI 프로그램을 이용한다. 여기서, CGI 프로그램은 관리자가 입력한 검색조건을 기반으로 로그를 찾아주는 작업을 하며, 검색결과가 HTML 파일로 생성되면 로그서버(20)는 이 내용을 웹서버를 통해 관리자에게 제공하게 되는 것이다.

로그서버를 위한 GUI 구성의 실시예를 도 16을 참조하여 설명하자면, GUI 메뉴(23-1)는 크게 전체로그를 보기 위한 것과 로그검색을 위한 것으로 나눌 수 있다. 관리자가 전체로그의 검색을 선택하면, 로그 전체 리스트 창(23-2)이 나타나 전체 리스트를 볼 수 있다. 이 때, 검색의 용이성을 위하여 이전 리스트와 이후 리스트를 이동하는 버튼을 구비한다.

또한, 관리자가 조건별 로그검색을 선택하면 로그검색옵션 창(23-3)이 나타나 검색옵션(예: AND, OR, Not)과 검색문을 입력할 수 있도록 한다. 그리고, 검색수행을 지시하면 조건에 맞는 로그기록을 검색하여 제공한다.

이상에서 설명한 바와 같이, 본 발명을 올바르게 사용하는 방법은 캐퍼빌리티(capability)와 접근제어목록(ACL:Access Control List)을 얼마나 잘 활용하느냐에 달려 있다. 즉, 본 발명에 따른 유닉스 시스템 내에서 운영되는 어플리케이션 프로그램은 모두 캐퍼빌리티(capability)와 접근제어목록(ACL)이 설정되어 운영되므로, 잘못된 설정은 어플리케이션 프로그램의 동작에 치명적인 오류를 줄 수 있다. 그리고 시스템 파일에 대한 잘못된 접근제어목록(ACL) 설정 등은 운영체제 자체의 동작에 치명적인 오류를 가져올 수 있다.

이러한 오류가 발생할 수 있다고 해서 캐퍼빌리티와 접근제어목록(ACL)을 모두 허용한다면, 이는 안전한 운영체제 이용의 의미가 없어지게 된다. 따라서 관리자는 지속적인 관심을 가지고 다음의 사항을 준수하는 것이 바람직하다.

- 커널 전반에 적용되는 캐퍼빌리티를 최소화한다.

- 시스템 환경 설정 파일과 로그 파일에 대한 접근 제어 규칙을 설정한다.

- 커널 모듈의 추가가 불가능하도록 커널을 실링하고, CAP_SYS_ MODULE 캐퍼빌리티를 꼭 필요한 프로세스에만 부여한다.

- 중요 프로세스에 Un-Killable 기능과 프로세스 숨기기 기능을 설정한다.

- 이용하고자 하는 프로세스의 구동시 요구되는 캐퍼빌리티를 찾아내어 해당 프로세스만 부여한다.

- 이용하고자 하는 프로세스가 접근하는 파일에 대하여 이 프로세스만 접근할 수 있도록 접근 제어 규칙을 설정한다.

- 불필요한 서비스에 대한 방화벽(Firewall) 기능을 설정한다.

- 침입이 의심되는 사항에 대해 즉각적인 전자 우편 통보가 가능 하도록 설정한다.

- 로그 내용을 수시로 확인한다.

특히, 각각의 시스템 목적에 맞는 유닉스 시스템의 환경 설정 내용과 이의 정형화 과정에서 획득한 노하우를 이용하면, 보다 안전한 시스템의 운영과 편리한 이용이 가능해질 수 있다.

Claims

각 프로세스(process)별로 시스템 자원(resource)에의 접근규칙을 설정할 수 있도록 하되, 상기 프로세스가 특정 자원에 접근하려고 할 때는 상기 접근규칙을 만족시키는지를 판단하여, 상기 접근규칙을 만족시키는 경우에는 상기 자원에의 접근을 허용하지만, 상기 접근규칙을 만족시키지 못하는 경우에는 상기 자원에의 접근을 차단하고 이에 관한 로그(LOG) 정보를 로그서버로 통보하도록 구성된 리눅스 운영체제(LINUX OS:Operating System)를 탑재한 하나 이상의 호스트;

상기 각 호스트와 연동하여 상기 각 호스트에서 전송한 로그정보를 저장하고, 자신과 연동하는 관리자 서버에서 상기 저장된 로그 정보를 기 규정된 규칙에 따라 검색할 수 있도록 해주는 로그서버; 및

상기 각 호스트와 연동하여 상기 접근규칙을 설정하고, 또한 상기 로그서버와 연동하여 상기 로그 정보를 검색하는 관리자 서버를 포함하여 구성되는 것을 특징으로 하는 리눅스 시스템.
제 1 항에 있어서,

상기 접근규칙은 커널(kernel) 자체에 부여되는 캐퍼빌리티(capability)를 기록하는 캐퍼빌리티 파일, 및 각 프로세스에 부여되는 접근규칙을 기록하는 접근제어목록(ACL:Access Control List) 파일을 통해 관리하도록 구성되는 것을 특징으로 하는 리눅스 시스템.
제 2 항에 있어서 상기 운영체제는,

상기 접근제어목록 파일의 내용은 부팅(Booting) 시에 메모리에 로드하되, 부팅 후 접근제어목록 파일의 내용이 변경되면 이를 상기 메모리에 반영하여 이용하고,

상기 캐퍼빌리티 파일의 내용은 상기 캐퍼빌리티 파일의 내용을 그대로 가지고 있되 상기 커널에 그 내용을 전달할 때와 그 내용이 변경될 때를 구분하는 기능을 수행하는 캐퍼빌리티 중개파일에서 읽어 이용하도록 구성되는 것을 특징으로 하는 리눅스 시스템.
제 3 항에 있어서 상기 운영체제는,

상기 프로세스가 특정 자원에 접근하려고 할 때는 상기 메모리에 로드된 접근제어목록 정보 혹은 상기 캐퍼빌리티 중개파일의 정보를 통해 접근규칙을 만족시키는지를 판단하여, 상기 접근규칙을 만족시키는 경우에는 상기 자원에의 접근을 허용하지만, 상기 접근규칙을 만족시키지 못하는 경우에는 상기 자원에의 접근을 차단하고 이에 관한 로그(LOG) 정보를 로그서버로 통보하는 커널;

상기 관리자 서버와의 인터페이스 수단; 및

상기 인터페이스 수단을 통해 상기 관리자 서버가 상기 접근제어목록 파일 혹은 캐퍼빌리티 파일을 변경시킬 수 있도록 해주는 접근규칙 갱신수단을 포함하여 구성되는 것을 특징으로 하는 리눅스 시스템.
제 4 항에 있어서 상기 커널은,

새로이 생성된 프로세스에는 기 규정된 기본 캐퍼빌리티를 일단 할당하도록 구성되는 것을 특징으로 하는 리눅스 시스템.
제 4 항에 있어서,

상기 커널의 기능은 상기 커널의 소스코드(source code) 레벨에서 구현하도록 구성되는 것을 특징으로 하는 리눅스 시스템.
제 4 항에 있어서,

상기 인터페이스 수단은 커맨드 라인 인터페이스(CLI:Command Line Interface)와 웹 그래픽 사용자 인터페이스(Web GUI:Graphic User Interface) 중 하나 이상을 포함하도록 구성되는 것을 특징으로 하는 리눅스 시스템.
제 2 항에 있어서 상기 접근제어목록 파일은,

각 프로세스 명칭;

상기 각 프로세스가 접근하려는 객체(Object); 및

상기 객체에 대한 접근유형(Access Type)에 관한 정보를 포함하도록 구성되는 것을 특징으로 하는 리눅스 시스템.
제 8 항에 있어서,

상기 객체는 파일/디렉토리 혹은 캐퍼빌리티이고,

상기 접근유형은 상기 파일/디렉토리에 대해서는 읽기 및 쓰기 금지(DENY), 수정금지(READ), 추가만 가능(APPEND), 및 쓰기가능(WRITE) 중 하나 이고, 상기 캐퍼빌리티에 대해서는 상속(INHERIT)과 불상속(NO_INHERIT) 중 하나 이도록 구성되는 것을 특징으로 하는 리눅스 시스템.
제 4 항에 있어서 상기 운영체제는,

상기 커널로부터 상기 접근규칙을 만족시키지 못한 로그정보를 받고, 이 로그정보를 이메일(e-mail)을 통해 상기 관리자 서버로 전송해주는 경보전송수단을 추가로 구비하여 구성되는 것을 특징으로 하는 리눅스 시스템.
제 2 항에 있어서 상기 운영체제는,

특정 프로세스의 캐퍼빌리티가 중단금지(un-killable)를 나타내는 캐퍼빌리티인 경우에는 해당 프로세스를 중단시키려는 시도를 무시하는 기능;

특정 프로세스의 캐퍼빌리티가 감추기를 나타내는 캐퍼빌리티인 경우에는 프로세스 목록의 디스플레이 기능 수행 중 해당 프로세스를 나타내지 않는 기능; 및

특정 프로세스의 캐퍼빌리티가 모듈삽입제한을 의미하는 캐퍼빌리티인 경우에는 커널에의 모듈 삽입 시도가 있을 때 이를 무시하는 기능 중 하나 이상의 기능을 포함하도록 구성되는 것을 특징으로 하는 리눅스 시스템.
제 1 항에 있어서 상기 운영체제는,

상기 호스트에서 송수신되는 데이터 패킷을 검사하여 통과가 허용된 패킷일 경우에만 통과시키는 기능을 수행하는 네트워크 보안처리수단을 추가로 포함하여 구성되는 것을 특징으로 하는 리눅스 시스템.
제 12 항에 있어서 상기 네트워크 보안처리수단은,

상기 관리자 서버로부터 커맨드 라인 인터페이스(CLI) 혹은 웹 그래픽 사용자 인터페이스(Web GUI)를 통해 상기 데이터 패킷의 통과에 관한 규칙을 설정받되, 이 규칙은 별도의 파일에 기록하여 관리하도록 구성되는 것을 특징으로 하는 리눅스 시스템.
제 1 항에 있어서 상기 운영체제는,

기 규정된 시간동안 해당 호스트에서 이루어지는 열려있지 않은 포트로의 접속시도가 기 규정된 회수를 넘는 경우에는 그 리스트를 작성하여 상기 로그서버로 전송하는 기능을 추가로 포함하여 구성되는 것을 특징으로 하는 리눅스 시스템.
제 1 항에 있어서,

상기 로그서버는 상기 관리용 서버와 웹 그래픽 사용자 인터페이스(Web GUI)를 통해 연동하도록 구성되는 것을 특징으로 하는 리눅스 시스템.
제 15 항에 있어서 상기 로그서버는,

자신이 저장하고 있는 로그정보를 검색하는데 있어서, AND, NOT, OR 중 하나 이상의 검색옵션을 이용하여 검색할 수 있도록 해주는 기능을 포함하여 구성되는 것을 특징으로 하는 리눅스 시스템.
리눅스 시스템을 운영하는 방법에 있어서,

각 프로세스별 접근규칙을 설정할 수 있도록 하는 제1 절차;

시스템 자원(resource)에 접근하려는 프로세스(process)가 있는지를 조사하는 제2 절차;

상기 조사 결과, 상기 자원에 접근하려는 프로세스가 있는 경우에는 상기 접근규칙을 참조하여 상기 프로세스에게 상기 자원에의 접근이 허용되었는지를 판단하는 제3 절차;

상기 제3 절차에서의 판단 결과, 접근이 허용되어 있으면 상기 프로세스가 해당 자원에 접근할 수 있도록 허용하는 제4 절차; 및

상기 제3 절차에서의 판단 결과, 접근이 허용되어 있지 않은 경우에는 상기 프로세스의 동작을 중단시키고 이에 관한 로그정보를 기록하는 제5 절차를 포함하여 구성되는 것을 특징으로 하는 리눅스 시스템의 운영방법.
제 17 항에 있어서,

상기 제1 절차에서 설정하는 접근규칙은, 커널(kernel) 자체에 부여되는 캐퍼빌리티(capability)를 기록하는 캐퍼빌리티 파일, 및 각 프로세스에 부여되는 접근규칙을 기록하는 접근제어목록(ACL:Access Control List) 파일에 설정하도록 구성하는 것을 특징으로 하는 리눅스 시스템의 운영방법.
제 18 항에 있어서, 상기 접근규칙은 타 컴퓨터 시스템(관리자 서버)으로부터 설정받도록 구성되는 것을 특징으로 하는 리눅스 시스템의 운영방법.
제 19 항에 있어서, 상기 관리자 서버와의 인터페이스는 커맨드 라인 인터페이스(CLI) 혹은 웹 스래픽 사용자 인터페이스(Web GUI)를 통해 이루어지도록 구성되는 것을 특징으로 하는 리눅스 시스템의 운영방법.
제 18 항에 있어서 상기 제3 절차는,

상기 제2 절차에서 시스템 자원에 접근하고자 하는 프로세스가 커널 자체의 프로세스인지 혹은 개별적인 프로세스인지를 판단하는 단계;

상기 판단 결과, 커널 자체의 프로세스인 경우에는 상기 캐퍼빌리티 중개파일에 기록된 접근규칙을 만족시키는지를 판단하는 단계; 및

상기 판단 결과, 개별적인 프로세스인 경우에는 상기 메모리에 로드된 접근제어목록 정보에 규정된 접근규칙을 만족시키는지를 판단하는 단계를 포함하여 구성되는 것을 특징으로 하는 리눅스 시스템의 운영방법.
제 18 항에 있어서 상기 접근제어목록 파일은,

각 프로세스 명칭;

상기 각 프로세스가 접근하려는 객체(Object); 및

상기 객체에 대한 접근유형(Access Type) 정보를 포함하도록 구성되는 것을 특징으로 하는 리눅스 시스템의 운영방법.
제 22 항에 있어서,

상기 객체는 파일/디렉토리 혹은 캐퍼빌리티이고,

상기 접근유형은 상기 파일/디렉토리에 대해서는 읽기 및 쓰기 금지(DENY), 수정금지(READ), 추가만 가능(APPEND), 및 쓰기가능(WRITE) 중 하나 이고, 상기 캐퍼빌리티에 대해서는 상속(INHERIT)과 불상속(NO_INHERIT) 중 하나 이도록 구성되는 것을 특징으로 하는 리눅스 시스템.
제 17 항에 있어서 상기 제5 절차는,

상기 접근규칙을 만족시키지 못한 로그정보를 이메일(e-mail)을 통해 관리자 서버로 전송해주는 절차를 추가로 구비하여 구성되는 것을 특징으로 하는 리눅스 시스템의 운영방법.
제 17 항에 있어서, 상기 유닉스 시스템의 운영방법은 네트워크 보안절차를추가로 포함하되, 상기 네트워크 보안 절차는

데이터 패킷의 통과 규칙을 설정하는 단계;

송수신되는 데이터 패킷이 있는지를 조사하는 단계;

상기 조사 결과, 송수신되는 데이터 패킷이 있는 경우에는 상기 설정된 규칙을 참조하여 통과시킬 것인지를 판단하는 단계; 및

상기 판단 결과, 통과가 허용된 경우에는 해당 데이터 패킷을 그 방향으로 통과시키되, 그렇지 않은 경우에는 드롭(drop) 시키는 단계를 포함하여 구성되는 것을 특징으로 하는 리눅스 시스템.
제 25 항에 있어서, 상기 데이터 패킷의 통과 규칙은 관리자 서버를 통해 설정되도록 하되, 상기 관리자 서버와의 인터페이스는 커맨드 라인 인터페이스(CLI) 혹은 웹 그래픽 사용자 인터페이스(Web GUI)를 통해 이루어지도록 구성되는 것을 특징으로 하는 리눅스 시스템의 운영방법.
제 25 항에 있어서 상기 네트워크 보안절차는,

열려있지 않은 포트로의 접속시도가 있는지를 조사하는 단계;

상기 조사 결과 접속시도가 있는 경우에는 이 접속시도가 기 규정된 시간동안 기 규정된 회수를 넘는지를 판단하는 단계; 및

상기 판단 결과, 그 회수를 넘는 경우에는 규정된 로그서버로 이를 통보하는 단계를 추가로 포함하여 구성되는 것을 특징으로 하는 리눅스 시스템의 운영방법.