노 병 규 (nono@kisa.or.kr)
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
접근통제의 기본적인 특성 및 이러한 특성에 따른 접근통제 방법의 분류와 호스트 수준에서 강력한 접근통제 정책을 수행할 수 있는 TCP_Wrapper의 설치 및 운영에 대하여 알아보자. 이 글은 모든 사람이 읽을 수 있도록 가능한 쉽게 쓸려고 노력하였다. 단순히 TCP_Wrapper 설치 및 운용에 그치지 않고 TCP_Wrapper가 운용되기 위한 기술적/환경적 내용에 대해서도 기술하였다.
1. 시작하며 시스템 관리자의 책임은 모든 사용자 통제, 서비스의 할당, 시스템이 허용하는 가용자원의 배분 등이 있다. 이러한 행위는 시스템에 관한 모든 것을 책임지는 관리자라고 하는 특별한 지위에 의해서만 이루어진다. 많은 컴퓨터들이 인터넷에 접속됨에 따라 관리자의 역할이 더욱 늘어나게 되었는데 인터넷에 접속시켜 인터넷의 풍부한 자원을 손쉽게 사용할 수 있게 하는 것뿐만 아니라 인터넷을 통한 불법적인 접근의 차단도 그중 하나이다. 외국의 자료를 보면 약 38,000건의 침입시도에 대하여 약 60%가 차단에 실패하였으며 침입에 성공한 24,800건중 약 90% 이상을 인식하지 못했다. 또한 인식된 1,000여건중 단 25%정도만이 대응조치를 취했을 뿐 75%가 대응조차 하지 못했다(그림 1). 즉, 결과적으로 38,000건의 침입시도중 1%가 못미치는 260건에서만 시스템 관리자가 올바른 대응을 취했다. 시스템 관리자(리눅서는 대체적으로 모두 시스템 관리자이다)는 항상 네트워크를 통해 시스템이 침해를 당할 경우에 대비하여 항상 이의 탐지, 대응조치 등을 사전에 고려하여야 하며 이를 위한 조치 중의 하나가 바로 TCP_Wrapper이다. (그림 1) 침해에 대한 대응
2. 접근통제란? 권한을 가지지 않은 자가 권한이 부여되지 않은 자료에 불법적인 접근을 시도할 때 이를 차단하는 행위를 접근통제(Access Control)라 한다. 우리가 사용하고 있는 리눅스 시스템도 소유자, 그룹 또는 그 외의 경우 등으로 분류하여 파일 또는 디렉토리의 읽기/쓰기/실행에 대한 권한을 부여하며, 사용자의 식별정보를 이용하여 접근통제를 수행하는 경우를 특별히 임의적 접근통제(Discretionary Access Control)라 한다. 그럼 다른 접근통제 방법도 있는가? 그렇다. 우리는 비밀번호를 변경할 때 passwd를 이용한다. 그런데 passwd의 권한은 누구에게 있는가? 당연히 root인 관리자이다. 그런데 관리자에게 권한이 부여된 passwd를 어떻게 일반 사용자가 사용 가능한가? 그것은 root가 일반 사용자에게 패스워드 권한을 일부 양도했기 때문에 가능하다(이를 setuid/setgid라 부른다). 이러한 경우와 같이 패스워드를 바꾸는 행위 또는 그 역할에만 권한을 허용한 경우를 역할기반 접근통제(Role Based Access Control)라 한다. - 다른 접근통제 방법도 있으나 이것을 설명하는 것이 목적이 아니므로 여기에서 그친다. 그럼 파일 등에 대한 접근통제 방법과 같이 네트워크에 대해서도 이를 확장할 수 있을까? 그렇다. 다행히 네트워크에도 사용자를 식별할 수 있는 인터넷 주소(xxx.xxx.xxx.xxx)가 있으며 이 주소를 이용하여 불법적인 접근을 통제할 수 있다. (네트워크 주소 아이디에 근거하여 접근통제를 수행하므로 엄밀히 얘기하면 임의적 접근통제이다.) 우리가 이미 알고 있는 ipfwadm, ipchains, TIS FWTK(TIS Firewall Toolkit) 등도 이러한 접근통제를 수행하기 위한 도구이다. 그럼 TCP_Wrapper가 ipfwadm, ipchains, TIS FWTK 등과는 어떻게 틀린가? 이들 중 하나면 충분한가? 아니면 모두다 필요한가? 이러한 궁금증을 다음절에서 세부적으로 설명해보고자 한다. ※ 접근통제 기능을 수행하는 도구 또는 시스템을 방화벽(일명 Firewall)이라 한다. 국내에서 정보보호기술 전문용어 표준이 제정(TTA.KO-12.0002)되었으며 방화벽(일명 Firewall)의 국내 공식 용어는 침입차단 시스템 또는 방화벽이다. (1) 프로토콜 계층에 따른 접근통제 분류 다양한 네트워크 프로토콜이 있으나 이를 대표적으로 표현한 ISO 프로토콜 스택을 대상으로 살펴보도록 하자. ISO 프로토콜 스택 중 네트워크의 라우팅 정보가 표현되는 Network 계층 및 사용자에 대한 정보를 표현하는 Application 계층이 접근통제를 수행 할 수 있는 부분으로 분류될 수 있다. 대체적으로 Network 계층에서 수행되는 접근통제를 패킷 필터링 또는 접근통제 라우터라 하고 Application 계층에서 수행되는 접근통제를 프록시 서비스 또는 응용 게이트웨이라 한다. (그림 2) (그림 2) 프로토콜 스택과 접근 통제 TCP_Wrapper, ipfwadm, ipchains 및 TIS FWTK은 수행되는 프로토콜 계층에 따라 좰표 1좱과 같이 분류 가능하다. 〈표 1〉 프로토콜 계층에 따른 접근통제
(2) 운영 위치에 따른 접근통제 분류 ipfwadm과 ipchains는 유사한 기능임을 안다.
그럼 이들과 TCP_Wrapper와의 차이점은 없는가? 이를 분류하기
위하여 두가지 접근통제 유형을 살펴보자. (그림 3) 호스트 기반 접근통제 두번째는 (그림 4)와 같이 네트워크간의 중계기능을 가지는 경우이다. 이런 경우 각 요소는 다음과 같이 구성된다. - 내/외부 서비스를 중계하는 게이트웨이 (그림 4) 네트워크 기반 접근통제 ipfwadm, ipchains, TIS FWTK는 두 네트워크를 중계할 수 있는 능력이 있다. 또 이들은 호스트 뿐 아니라 네트워크 단위로도 접근통제를 수행할 수 있다. 그럼 모두 ipfwadm이나 ipchains를 사용하는게 더 좋지 않을까? 반드시 그런건 아니다. ipfwadm이나 ipchains를 수행하기 위해서는 반드시 커널 컴파일을 재 수행하여야 한다. 네트워크를 중계 할 수 있는 능력을 필요로 하지 않고 네트워크에 연결된 서비스 호스트로만 사용될 경우에는 ipfwadm, ipchains을 사용하기 위하여 커널을 다시 컴파일하여 커널을 무겁게 만들 필요는 없을 것이다. 어떤 호스트가 두 네트워크 사이에서 네트워크를
통제할 필요가 없이 하나의 단일 호스트로 사용될 경우(대부분의
리눅스 시스템이 이렇게 운영되지 않을까?) TCP_Wrapper는 최소한의
환경 설정 변경만으로 사용할 수 있다. 또한 TCP_Wrapper는
리눅스 외에도 거의 모든 유닉스에서 사용할 수 있다. (리눅스는
기본적으로 설치되어 있다)
〈표 2〉 운영 위치에 따른 접근통제
3. TCP Wrapper (1) 제작 배경 TCP_Wrapper는 네트워크 취약성 검출 도구인 SATAN 패키지를 만든 Wietse Venema가 만든 도구이다. 이것을 만든 동기는 학교내의 컴퓨터 로그 자료에 지속적인 불법 침입 시도 - 비밀번호 오류 따위 - 가 발견되었다. 만일 이러한 시도에서 우연히 비밀번호가 맞았다면 그 다음부터 흔적 없이 시스템에 접근가능 할 것이다. 그러나 Wietse Venema는 이러한 흔적을 발견하자마자 침입을 시도한 IP 주소에 대하여 시스템에 접근하지 못하도록 하는 방법을 생각하였다. 처음에 그는 현존하는 서버 프로그램을 교체하여 서비스별로 이러한 기능을 수행하는 것을 목표로 하였는데 다음의 문제로 인하여 벽에 부닥치게 되었다. - 네트워크 서비스 소스에 대한 라이센스 따라서 그는 이러한 문제를 해결하고 일반적으로 수행될 수 있는 범용의 방법을 생각해 내게 되었고 이를 위하여 TCP_Wrapper 트릭을 생각해 내었다. (2) 인터넷 서비스 일단 TCP_Wrapper 트릭을 설명하기에 앞서 어떻게 인터넷 서비스가 이루어지는가 살펴봐야 한다. 인터넷 서비스가 이루어지기 위해서는 다음 두 가지 방법이 있다. 1) 프로그램으로 수행(대체적으로 시스템
부팅시 rc 파일에서 수행) 2) 시스템 부트시에 기동되는 inetd 데몬에 의하여 수행대부분의 네트워크 서비스와 관련된 정보가 포트에 도달하기 전까지 서버가 수행될 필요가 없으므로 효율적이다. 즉 임의의 포트가 활성화될 경우 그에 해당되는 필요한 서비스만을 수행 시켜준다. 그럼 임의의 포트에 대하여 어떤 서비스가 필요한지 inetd는 어떻게 판단하는가? 이러한 기능을 하는 것이 바로 /etc/inetd.conf(이하 inetd.conf)이며 이것이 바로 TCP_Wrapper 트릭을 가능하게 해주는 요점이다. (inetd를 통하지 않고 수행한 서비스는 TCP_Wrapper가 적용되지 않는다.) (3) inetd와 inetd.conf 자! 이제 TCP_Wrapper 트릭을 위해 점점 중요한
내용이 나온다. 일단 inetd에 대하여 알아보자. (그림 5)와 같이
외부에서 telnet 서비스를 요청할 경우 inetd는 이 서비스가 어떤
프로토콜(TCP/UDP 등)을 사용하는지, 이 서비스가 실행될 경우 소유
권한은 누구로 할 것인지, 실행하여야 할 서비스 화일의 위치는
어디든지 등을 확인할 수 있어야 한다. inetd는 이러한 정보를 세
개의 중요한 파일 - /etc/protocols, /etc/services와 inetd.conf
-을 참조하여 필요한 정보를 획득한 후 외부로부터의 telnet 접속요구를
허용한다. 여기서 TCP Wrapper와 직접적으로 관련이 있는 inetd.conf
파일에 대해서 좀더 자세히 살펴보자. (그림 5) inetd의 동작 흐름 inetd.conf는 총 7개의 필드로 구성되어 있다.
〈표 3〉 inetd.conf 필드의 구성 7개의 필드 중 “서버 프로그램”과 “매개변수”를
주목하면서 telnet의 경우에 대하여 inetd.conf를 보자. 외부에서 telnet을 요청할 경우 inetd는 서버프로그램 /usr/sbin/in.telnetd를 수행시키고 서버프로그램에 매개변수 in.telnetd를 넘겨준다. in.telnetd가 이미 수행중인데 왜 매개변수가 필요한가? in.telnetd도 하나의 데몬이기 때문이다. 즉, in.telnetd도 여럿의 요청에 대해 응답을 하여야 하므로 부프로세스(in.telnetd)에서 자식 프로세스(in.telnetd)로 수행시켜야 할 프로세스의 이름이 자기 자신이란 뜻이다. 자. 이제 여러분의 리눅스 박스로 가서 inetd.conf를 살펴볼 차례이다. 과연 그런가? 아니다. 위의 내용과 조금 틀리다. ·telnet stream tcp nowait root 그렇다. 틀리는 것이 당연하다. 왜냐하면 리눅스는 이미 TCP Wrapper가 설치되어 있기 때문이다. 이제 드디어 TCP Wrapper 트릭을 얘기할 차례이다. (4) TCP Wrapper 트릭 TCP Wrapper가 설치되어 있는 호스트의 inetd.conf를 다시 한번 써보자. ·telnet stream tcp nowait root 이를 이용하여 (2)절에서 설명한대로 한번 따라 해보자. inetd는 외부로부터 telnet 요청이 올 경우 inetd.conf를 참조하여 /usr/sbin/in.telnetd를 첫 번째 매개변수로 하여 /etc/sbin/tcpd를 수행한다. tcpd는 부여된 일을 수행한 후 매개변수로 입력된 in.telnetd를 수행시킬 수 있다. 여기서 tcpd가 바로 TCP Wrapper 프로세스이다 !!! 어떤가? 현재 TCP Wrapper가 수행되고 있는 것을 누가 아는가? inetd가 유일하게 알 수 있지만 inetd는 inetd.conf에 있는 정보를 그대로 수행했을 뿐이다. 단순히 환경 파일의 일부만 변경하므로써 우리가 원하는 다른 일을 투명하게 수행시켰다. 이것이 바로 inetd.conf를 이용한 트릭이다. 그럼 tcpd에게 부여된 일은 무엇인가? tcpd는 접근허용 파일 /etc/hosts.allow(이하 hosts.allow)와 접근거부 파일/etc/hosts.deny(이하 hosts.deny)를 참조하여 호스트에 대한 접근 여부를 판단한다. 즉, 이러한 서비스에 접근하는 과정에서 발생하는 모든 사항에 대하여 상세한 접속 로그를 남기고, 특별한 네트워크 서비스에 대하여 패턴에 기초한 접근통제를 수행하고, 원격 사용자 이름에 대하여 lookup을 하고, IP 스푸핑을 방지하고, 관리자가 정의한 임의의 명령을 수행하고, 접속에 필요한 서비스를 활성화시킨다. 즉, inetd와 서버 사이에 끼어 들어 매우 중요한 판단을 수행하게 된다. (그림 6) TCP_Wrapper는 투명하게 동작하므로 클라이언트와
서버는 이러한 사실이 일어났는지 전혀 알지 못한다. (그림 6) TCP Wrapper의 동작흐름 이제 프로토콜에 따른 접근통제 분류와 운영
위치에 따른 접근통제 분류가 이해되는가?
4. TCP Wrapper 설치 및 운용 4.1 무엇이 필요한가? 이제 무엇이 필요한지 질문할 때가 되었다. 우선 TCP Wrapper 소스를 구하자. 다음 사이트에서 구할 수 있다. ·ftp://ftp.porcupine.org/pub/security/TCP ----------------------------------------------------- 1) 날짜와 파일 크기
2) 기타 백도어 버전에서 변경된 소스 내용 등 자세한 사항은 다음 사이트를 참고하라. ·http://mail.mc2.nu/~secure/msg01574.html ----------------------------------------------------- 다음은 자신의 호스트가 무엇인지 확인한다. 컴파일 가능한 시스템 및 운영체제의 일부를 다음에 리스팅하였다. (리눅스는 기본적으로 설치되어 있으므로 바로 운영할 수 있다) ·aix / AIX 4.1 , dunix / Digital Unix 3.2, hpux10 / HP-UX 10.20, irix / Irix 5.3, solaris / Solaris 2.5, … 시스템을 알았으면 바이너리 설치 위치를 다음과 같이 결정한다. ·aix : /usr/sbin ※ 이러한 바이너리 설치 위치에 대해선 필자도 맞는지 틀리는지는 확인할 수 없다. 다만 대체적으로 맞을 것이란 생각은 든다. 또한 틀리면 어떤가? inetd.conf와 적절히 조합해서 사용하면 아무런 문제가 없다. 잘 모르겠으면 inetd.conf 중 telnet 데몬이나 ftp 데몬은 있는 위치를 지정하면 된다. 말 그대로 트릭이다 !!! 4.2 컴파일과 설치 이제 가져온 프로그램을 적절한 위치에 풀어놓은 후 위에서 결정된 경로를 Makefile에 적용시키자. 1) tar xvzf TCP Wrapper.7.6.tar.gz 다 되었나? 너무 쉽다. 이제 inetd.conf를 바꾸자. 리눅스에 기본적으로 설정되어 있는 내용은 다음과 같다. ·ftp stream tcp nowait root /usr/sbin/tcpd
in.ftpd -l -a inetd.conf에서 통제가 필요한 부분에서 주석문(#)을 떼거나 3.3절과 같이 서버 프로그램 위치에 tcpd를 입력하여 적절히 적용한다. 4.3 TCP Wrapper 운용 ·서비스 데몬 리스트[들] : 클라이언트 리스트[들]
서비스 데몬 리스트는 외부로부터 접근을 통제하고자
하는 서비스로써 <표 3>에 설명된 inetd.conf 마지막 필드에
기술된 매개변수 이름을 그대로 사용하여야 하고, 클라이언트 리스트는
네트워크 서비스를 사용하게 또는 사용하지 못하게 할 호스트 주소나
호스트 이름이다. 또 쉘명령은 서비스 데몬 리스트와 클라이언트
리스트가 주어진 조건이 충족되었을 경우 관리자가 임의로
수행할 수 있는 명령이다.
<표 4> 규칙설정 예약어 및 패턴 매치
규칙 TCP Wrapper의 기본 목적이 접근통제이므로 “명백히 허용된 서비스 외에는 어떠한 것도 금지”하는 보안정책을 기본 보안정책으로 수립한다. (이것은 매우 적절한 정책이다. 만일 “명백히 거부한 것 외의 어떠한 것도 접근 허용”을 기본 보안정책으로 수립할 경우 발생되는 문제점에 대해서는 각자 생각해 보라) 이를 위하여 다음과 같이 hosts.deny 파일의 접근 규칙을 설정한다. ·ALL : ALL hosts.allow 파일을 다음과 같이 구성 해보자. ·ALL : localhost, goodguy.good.net 이렇게 규칙이 설정될 경우 수행되는 접근통제
결과는 관리자가 수행시킬 수 있는 쉘 명령 필드는 관리자가
정의한 임의의 명령을 수행시킬 수 있으며 다음과 같이 두 가지
방법으로 수행 가능하다.
<표 5> 쉘 명령 필드에 사용되는 대치
확장자 의심되는 호스트(badguy.bad.net)가 시스템에 접근을 시도할 경우 이의 접속을 거부하고 관리자에게 관련 정보를 전송하기 위하여 hosts.deny에 다음과 같이 구성해 보자. ·ALL : badguy.bad.net : twist ( finger -l
@%h | 만일 badguy.bad.net 사용자가 임의의 서비스를
요청할 경우 badguy.bad.net 사용자에 대한 reverse finger 내용이
관리자 메일로 전송된다. (대치 확장자는 각자 생각해 보라) 쉘
명령 필드를 잘 이용하면 관리자가 적절한 프로그램을 작성하여
지속적인 불법 접근을 시도하는 사용자를 괴롭힐 수도 있다. 4.4 로그 TCP Wrapper가 기록하는 로그 내용은 운영체제별로 다음 장소에 기록된다. ·aix : /var/admin/messages 4.5 시험 우선 TCP Wrapper의 환경이 잘 구성되었는지
확인하기 위하여 tcpdchk와 tcpdmatch를 이용해본다. tcpdchk는
TCP Wrapper에 필요한 hosts.allow, hosts.deny 및 inetd.conf 파일을
비교하여 규칙에 맞지 않는 부적절한 서비스, 적합하지 않은 호스트
이름/주소 및 부적절한 패턴구문 등에 대한 오류를 리포팅하며,
tcpdmatch는 임의의 사용자 또는 호스트가 임의의 서비스 접속에
대한 요구를 TCP Wrapper가 어떻게 처리할지 그 결과를 보여준다. ·ifconfig eth0:1 200.200.200.2 netmask 255.255.255.0 호스트 주소 200.200.200.2에서 접근하는 것은 모든 서비스를 받을 수 있도록 할 경우 hosts.allow와 hosts.deny를 다음과 같이 구성하고 telnet이 수행되는지 확인해 보자. ·hosts.allow -> ALL : localhost, 200.200.200.2 200.200.200.2에서 접근하는 것은 어떠한 서비스도 받을 수 없도록 하고 만일 200.200.200.2에서 접근 시도가 있을 경우 관리자에게 메일을 전송하도록 하도록 할 경우 hosts.allow와 hosts.deny를 다음과 같이 구성하고 telnet이 수행되는 않는지 확인해 보자. ·hosts.allow -> ALL : localhost telnet 접속이 실패하고 관리자에게 200.200.200.2
호스트에 대한 reverse finger 결과를 내용으로 하여 메일이 왔으면
성공이다. (메일의 제목은 in.telnetd-200.200.200.2가 될 것이다)
만일에 메일이 오지 않거나 접속 결과가 규칙과 일치하지 않을 경우
로그 내용을 보고 오류를 찾아 다시 한번 시도해 보자. ·man hosts.allow
5. 마치며 이제 TCP Wrapper를 이용하여 자신의 호스트에 대하여 접근통제를 수행할 수 있게 되었다. 이제 모든 것이다 되었는가? 모든 것이 안전한가? 건물에 경비만 배치하면 모든 것이 완료되었다고 판단해도 좋은가? 아니다. 만일 믿고 접근 권한을 부여한 사람이 부당한 행위를 할 경우 어떻게 대처할 것인가? 당연히 내부 중요 자료에 대한 별도의 대책이 필요하다. TCP Wrapper만으로는 안심할 수 없다. 이를 위하여 추후 또 다른 보안 대책 도구에 대하여 얘기해 볼까 한다. 네트도둑이 남긴 조그마한 흔적조차도 끝까지 추적하기 위하여... ■저자 소개(노병규) ■저자 소개(조대일) |