기존의 백도어는 애플리케이션 모드인 유저 모드에서 작동을 하였기 때문에 tripwire나 MD5와 같은 시스템파일무결성 검사로 백도어의 유무를 확인할 수 가 있었다. 그러나 커널 모듈을 이용한 백도어는 기존의 애플리케이션 모드에서 작동하는 시스템 파일 무결성 검사로는 백도어의 유무를 확인할 수 없다. 이런 LKM 커널 백도어를 방지하기 위해 여러 가지 프로그램들이 제시가 되었지만 시스템 콜 테이블 변경 유무만을 검사하므로 방지에 한계가 있다. 본 논문에서는 이러한 LKM 커널 백도어에 대한 공격의 위험성을 인식하여 기존의 무결성 검사만으로 커널 백도어 침입을 차단할 수 없었던 커다란 한계성에 대한 대안을 제시하고자 한다.
기존의 백도어는 애플리케이션 모드인 유저 모드에서 작동을 하였기 때문에 tripwire나 MD5와 같은 시스템파일 무결성 검사로 백도어의 유무를 확인할 수 가 있었다. 그러나 커널 모듈을 이용한 백도어는 기존의 애플리케이션 모드에서 작동하는 시스템 파일 무결성 검사로는 백도어의 유무를 확인할 수 없다. 이런 LKM 커널 백도어를 방지하기 위해 여러 가지 프로그램들이 제시가 되었지만 시스템 콜 테이블 변경 유무만을 검사하므로 방지에 한계가 있다. 본 논문에서는 이러한 LKM 커널 백도어에 대한 공격의 위험성을 인식하여 기존의 무결성 검사만으로 커널 백도어 침입을 차단할 수 없었던 커다란 한계성에 대한 대안을 제시하고자 한다.
As the existing backdoor worked at user mode, which is application mode, it was possible to check the existence of backdoor by the integrity check of system file. However, for the backdoor using kernel module, it is impossible to check its existence by the integrity check of system file. Even variou...
As the existing backdoor worked at user mode, which is application mode, it was possible to check the existence of backdoor by the integrity check of system file. However, for the backdoor using kernel module, it is impossible to check its existence by the integrity check of system file. Even various programs were presented to protect this LKM Kernel backdoor, there is limitation in protection as they examine the changes on the system Call Table. This study, recognizing the danger of invasion through such LKM Kernel backdoor, will provide alternative for the limitation which the existing integrity check couldn't prevent intrusion through Kernel backdoor.
As the existing backdoor worked at user mode, which is application mode, it was possible to check the existence of backdoor by the integrity check of system file. However, for the backdoor using kernel module, it is impossible to check its existence by the integrity check of system file. Even various programs were presented to protect this LKM Kernel backdoor, there is limitation in protection as they examine the changes on the system Call Table. This study, recognizing the danger of invasion through such LKM Kernel backdoor, will provide alternative for the limitation which the existing integrity check couldn't prevent intrusion through Kernel backdoor.
* AI 자동 식별 결과로 적합하지 않은 문장이 있을 수 있으니, 이용에 유의하시기 바랍니다.
문제 정의
이곳에 올라와 있는 모듈들의 이름을 보고 경험 있는 관리자라면 예상외의 모듈이 올라와 있음을 알게 될 것이고 그것은 곧 제거되고 말 것이다. 따라서 백도어를 만드는 모듈들을 숨길 필요성이 있는데 간단하게 그 방법을 알아보고자 한다.
따라서 본 논문에서는 커널 LKM 백도어 차단과 탐지에 대하여 연구한다. 커널 LKM 백도어에 관련된 연구를 통하여 차단과 탐지에 관한 기법을 찾고 커널 변경을 통한 시스템의 큰 피해를 막을 수 있다.
이런 LKM 커널 백도어를 방지하기 위해 여러 가지 프로그램들이 제시가 되었지만 시스템 콜 테이블 변경 유무만을 검사하므로 방지에 한계가 있다. 본 논문에서는 이러한 LKM 커널 백도어에 대한 공격의 위험성을 인식하여 기존의 무결성 검사만으로 커널 백도어 침입을 차단할 수 없었던 커다란 한계성에 대한 대안을 제시하고 있다. 그러나 커널의 변경을 통한 침입 차단은 수정의 어려움과 사용의 제약이 따르기 때문에 향후 다양한 방법의 백도어 차단 연구가 필요하다.
제안 방법
지금까지는 시스템 콜 테이블에 들어 있는 시스템 콜을 가로채서 백도어가 심어져 있는 시스템 콜로 대체해 온 것들이다. 이를 위해서 백도어가 심어져 있는 적재 가능한 커널 모듈을 만들어 루트 권한으로 커널을 적재하고 시스템 콜을 대체하였다. 커널 모듈을 관리하는 명령어 중에 lsmod명령이 있다.
성능/효과
커널 구조 중에는 하드웨어 제어 루틴이 있는데, 컴퓨터간의 통신 및 하드웨어의 인터럽트를 처리한다.[2] 결국 리눅스 시스템은 시스템 콜을 통해서 작동한다는 것을 알 수 있다. 시스템 콜을 사용해서 파일의 내용을 읽고, 쓰며, 프로세스를 제어한다.
후속연구
본 논문에서는 이러한 LKM 커널 백도어에 대한 공격의 위험성을 인식하여 기존의 무결성 검사만으로 커널 백도어 침입을 차단할 수 없었던 커다란 한계성에 대한 대안을 제시하고 있다. 그러나 커널의 변경을 통한 침입 차단은 수정의 어려움과 사용의 제약이 따르기 때문에 향후 다양한 방법의 백도어 차단 연구가 필요하다.
만약 이러한 상황이 된다면, 그 서버관리자로선 무척 난감할 일이 아닐 수가 없을 것이다. 따라서 이후에 설명할 몇 가지 예시들은 커널의 모듈기능을 제거하지 않은 상태에서 어떻게 하면 커널 백도어가 설치되지 않도록 막을 수 있을 것인가 하고 백도어가 설치되어 있다면 어떻게 이를 발견할 수 있을 것인가 하는 부분에 대한 것이 될 것이다.
질의응답
핵심어
질문
논문에서 추출한 답변
리눅스 커널이란 무엇인가?
리눅스 커널이란 운영체제의 핵심을 이루는 요소로서 컴퓨터 내의 자원을 사용자 프로그램이 사용할 수 있도록 관리하는 프로그램이며 그 기능은 프로세스 관리, 파일 시스템, 메모리 관리 및 네트워크 등이 있다. 대부분의 사용자는 C 라이브러리를 이용하여 시스템 콜을 사용한다.
시스템 콜은 무엇에 해당하는가?
시스템 콜이란 커널 영역과 사용자 영역을 중재해 주는 인터페이스에 해당하는 것이다. 다중 사용자나 혹은 단일사용자에 의한 실수로부터 커널 영역을 보호하기 위해 커널은 구별된 메모리공간을 사용한다.
LKM기반의 백도어를 막는 가장 기본적인 방법의 단점은 무엇인가?
LKM기반의 백도어를 막는 가장 기본적인 방법은 컴파일의 모듈 로딩기능을 삭제한 완전한 모놀리틱 커널로 컴파일하는 것이다. 그러나 이것은 단순하고 확실한 방법이기는 하나 나중에 디바이스를 추가하는 등의 필요에 의해 커널이 확장되어야 할 순간이 온다면, 전체 커널을 다시 컴파일해야 하고 시스템은 재부팅시켜야 하는 맹점이 따른다. 실제로 서버들은 어지간한 일이 아니고선 재부팅을 할 수 없는 상태인 경우가 많다.
참고문헌 (6)
Maurice J. Bach, "UNIX 운영체제의 설계", pp 47-50, 대익사, 1992.
※ AI-Helper는 부적절한 답변을 할 수 있습니다.