LINUXFIREWALL
리눅스에서의 방화벽 시스템 [마지막 회]

    이수준 외 BIT NETWORK 67 기
    VIRUSWALL & SSL APPLICATION 팀

     

 

    지난 호에서는 FWTK의 설치와 구성, 운영법 등에 대해 알아보았다.
    이번에는 마지막으로 본 프로젝트에서 FWTK의 성능 개선을 위하여 수정/추가한 부분을 언급하고 이 글을 마칠까 한다.

 

연구 목표

    FWTK 라는 방화벽 도구를 기반으로 하여 새로운 기능을 추가하여 보다 안전하고 뛰어 난 방화벽 시스템을 구성하고자 본 프로젝트에서 구현하고자 목표로 삼았던 내용을 소개하면 다음과 같다. (이하 기능 추가에 따른 새로운 방화벽 도구를 Viruswall이라 칭한다.)

     

    - GUI 환경의 방화벽 관리 도구

    TIS FWTK는 방화벽에서 내부 네트워크로의 접근 차단과 허용에 관한 모든 규칙을 Netperm-Table이라는 하나의 파일에 텍스트 형식으로 저장한다. 내부 네트워크에 대한 접근 제어 규칙을 쉽게 추가, 삭제, 수정할 경우 Netperm-Table을 일일이 수작업으로 수정하여야 한다. Netperm-Table을 Windows 95 환경에서 방화벽에 접속하여 쉽게 수정할 수 있는 도구를 작성하고 하였다.

     

    - FWTK 의 인증 서버와 PostgreSQL 의 연동

    FWTK에서는 외부의 호스트에서 방화벽 내부로 접근하고자 할 때 사용자의 인증의 과정을 거친 후에 접근을 허용하게 되는데, 이때 사용자에 대한 정보를 임의의 파일에 저장하게 되어있다. 본 프로젝트에서는 인증 서버를 수정하여 PostgreSQL과 연동하여 사용자에 관한 자료를 데이터베이스화하여서 FWTK의 authsrv라는 사용자 관리 프로그램을 사용하지 않더라도 데이터베이스를 수정하는 것만으로 사용자를 추가 삭제하도록 하였다.

     

    - 일회용 패스워드를 이용한 사용자 인증

    UNIX 상에서 사용하는 사용자 패스워드는 항상 동일하다. 만약 사용자가 원격으로 Telnet 서비스를 사용할 때 사용자의 ID 와 Password을 입력하는 순간에 그 내용을 도청(Sniffing)을 하고 있는 사용자가 있다면 사용자의 ID와 Password가 유출이 되어 보안상에 문제가 된다. 이러한 보안상의 문제를 해결하기 위한 한가지 방법으로 매번 접속을 할 때마다 다른 일회용 패스워드를 사용하는 것이다. 본 프로젝트에서는 일회용 패스워드 기법 중 하나인 S/key를 사용하였다.

     

    - FTP-GW 에서의 바이러스 검색기능 첨가

    FWTK의 FTP-Gateway 프로그램을 수정하여 바이러스가 감염된 파일을 전송 받을 경우 파일 전송 후 바이러스 감염 사실을 통보하여 사용자로 하여금 바이러스를 치료 후 사용하거나 삭제를 할 수 있도록 하였다.

     

    - FWTK에 SSL-gw 작성 추가

    HTTP상에서 자료를 암호화하여 안전하고 신뢰성 있는 통신을 제공하는 SSL (Secure Socket Layer)을 이용한 WWW서비스가 있다. 만약 방화벽이 설치된 네트워크에서 방화벽 내부의 호스트가 방화벽의 프락시를 거쳐서 WWW를 사용할 경우 일반적으로는 SSL 을 사용한 서비스를 이용 할 수 없게 되는데, 본 프로젝트에서는 방화벽 내부의 호스트도 SSL을 이용한 WWW 서비스를 사용할 수 있도록 SSL-Gateway를 작성하여 방화벽에 추가하였다.

     

    - SSL을 이용한 Telnet 프로그램 작성

    SSL(Secure Socket layer)은 HTTP뿐만 아니라 Telnet, Ftp등 다른 응용 프로그램에도 적용할 수 있다. 많이 사용하는 응용 프로그램 중에 하나인 Telnet 프로그램을 SSL을 이용하여 새롭게 작성하여 Sniffing공격에 안전하고 신뢰성 있는 Telnet 서비스를 제공하도록 하였다.

     

시스템 구성도.

    Viruswall 시스템은 패킷 필터링 방화벽과 어플리케이션 프락시 방화벽을 혼합한 형식의 방화벽 시스템으로 외부(Internet) 베스천(Bastion) 호스트 사이에 리눅스 머신을 사용하여 패킷 필터링이 가능한 라우터를 구성하여 외부의 호스트가 방화벽 내부의 IP로 위장하여 접근하지 못 하도록 막아주는 기능을 하고, 베스천 호스트에 TIS FWTK (Fire Wall Tool Kit)을 기반으로 하는 어플리케이션 프락시 방화벽을 설치하였다. 내부 자원을 보호하기 위하여 명백히 허용되지 않는 서비스 이외에는 금지하도록 정책을 세웠으며, 허용되는 서비스는 우리가 가장 많이 사용하는 Telnet, FTP, WWW 이다. 내부의 호스트가 외부의 Telnet 또는 FTP Gateway에 접속을 한다. 이때 사용자 인증을 요구하게 된다. 사용자 ID와 패스워드를 입력하여 사용자 확인을 마친 후에 원하는 서비스에 재접속하는 방식으로 서비스를 사용할 수 있다. 본 프로젝트에서는 FTP서비스를 통하여 파일을 전송 받게 될 경우 파일 전송 후 전송된 파일이 바이러스에 감염된 파일인지를 검사하여 이를 통보하여 주도록 수정하였다. 외부의 호스트가 내부의 호스트에 Telnet이나 FTP를 이용하려고 하는 경우에도 마찬가지로 베스천호스트에 먼저 접속을 한 후 다시 원하는 호스트로 재접속하여야 한다.

     

    <그림 2-1> 시스템 구성도

    내부의 사용자가 WWW 서비스를 이용하게 될 경우에는 Telnet의 경우와는 약간 다른 방식을 취하게 되는데, Nescape의 환경 설정 부분에서 Proxy를 설정하는 부분이 있는데 그 곳에 베스천 호스트의 IP Address와 port 번호(80)를 설정하고 사용하면 된다. 그리고 만약 SSL을 사용하여 안전하고 신뢰성 있는 WWW 서비스를 제공하는 곳에 접속을 하고자 한다면, Security 부분에 베스천 호스트 IP와 Port 443 을 지정하면 된다. 본 프로젝트에서 작성한 SSL-Gateway 프로그램이 443번 Port를 사용하여 프락시 기능을 한다. 전체 방화벽 시스템을 관리하기 편하게 하기 위하여 Windows 환경에서 운용되는 관리 도구를 작성하여 방화벽 시스템의 설정 작업을 편하게 할 수 있도록 하였으며, Telnet을 이용하여 베스천 호스트에서 작업을 할 경우 작업 내용의 보호를 위하여 SSL을 지원하는 Telnet 서버와 클라이언트를 작성하였다.

     

TIS와 Viruswall의 인증 시스템 비교.

    TIS-toolkit에서는 인증자의 정보, 프로토콜 타입, 패스워드 등을 DBM 라이브러리를 이용하여 Netperm-TABLE에서 정의한 임의의 이름을 가진 3개의 FILE에 저장한다. 하지만 Viruswall에서는 인증 서버와 DB 서버를 따로 분리시켜 인증에 필요한 모든 정보를PostgreSQL DB를 사용해 관리하게 하고 인증 요구 시 자료를 전송하게 하였다. 인증 서버

      

    <그림 3-1> Viruswall 인증 시스템>

    와 DB 서버를 따로 분리시켜 놓음으로써 새로운 사용자를 추가하기 위하여 베스천 호스트에 접근하지 않아도 되고, DB자료를 수정하기만 하면 되기 때문에 사용자의 추가, 삭제를 쉽게 할 수 있게 된다. 또 모든 자료를 DB 화하였기 때문에 추후 그 활용도를 높일 수 있으며, DB를 관리하기 편하게 하기 위해 web상에서 CGI를 사용해 접근할 수 있도록 하였다.

     

    S/key

    S/key는 원격지의 컴퓨터에 접근하는 사용자를 위한 접근 제어 시스템으로 일회용 패스워드(one time password) 인증 시스템이다. 전세계적인 네트워크의 증가에 따라 합법한 사용자의 접근을 허용하는 것만으로도 시스템의 안전을 위협 받을 수 있다. 이에 따라 네트워크와 컴퓨터를 보호하기 위한 방법들이 생겨나게 되었다. 만약 사용자가 회사 네트워크로 모뎀이나 인터넷을 통해 접근하여 인증을 받을 때, 원격지 컴퓨터가 취약하지 않더라도 네트워크 자체의 보안이 매우 나빠 원격지의 컴퓨터가 위험해 지게 될 수 있다. 이런 네트워크를 통한 인증시에 네트워크의 취약점을 보안할 수 있는 방법의 하나로서 S/key라는 인증 시스템이 있다. 네트워크를 통해 가는 데이터들은 암호화되어 통신되지 않는 이상, 네트워크를 통해 가는 데이터들은 모두에게 공개되어 있다. 이때 username 과 passwd 가 네트워크를 통해 지나갈 때 hacker가 이 네트워크를 지켜보고 있다면 이 시스템의 인증은 무용지물이 되게 된다. 이후로는 hacker도 이 시스템을 합법한 사용자처럼 사용할 수 있게 된다.

    사용자 이증 시스템(예 UNIX passwd)은, 많은 네트워크 보안에서 첫번째의 방어막이다. S/key 는 Bellcore사에서 개발한 일회용 사용자 인증 시스템으로서 네트워크의 감시 공격(evesdropping attack)으로부터 사용자와 시스템을 보호하여 줄 수 있다.

     

    FTP-Gateway에서의 바이러스 검색

    대부분 인터넷 사용자들은 FTP 서비스를 통하여 파일을 전송할 수 있게 된다. 인터넷의 자료들은 개방적이기는 하지만 그만큼 위험 부담도 크다. 많은 사용자들이 즐기는 게임이라든지 기타 멀티미디어 자료 등에는, 컴퓨터 바이러스 등의 위협적인 요소가 도사릴지도 모른다는 부담감은 누구나 가지고 있다. 이러한 위험 요소들을 파일 전송시 등에 경고해 주는 시스템을 가질 수는 없을까? 우리가 구축한 방화벽시스템은 단지 외부로부터의 네트워크를 통한 직접적인 공격들에는 비교적 훌륭한 기능을 제공하지만, 컴퓨터 바이러스처럼 간접적인 공격들에는 별 다른 보호막이 없는 실정이다. 하지만 FTP등의 파일 전송 서비스에 바이러스 등을 검색할 수 있는 시스템을 구축할 수 있다면 완벽하지는 않더라도 어느 정도 간접적

     

    <그림 3-2> S/key 인증 시스템

    인 위협에 적응할 수 있을 것이다. 우리가 구축한 방화벽 시스템에 바이러스 검색 시스템을  추가할 수 있는 방법에 대해 생각해 보자. 일단 방화벽 시스템이 구축되면, 모든 네트워크 트래픽이 설치된 방화벽 시스템을 통과하게 된다. FTP proxy인 FTP-GW는 방화벽 호스트를 통과하는 사설 네트워크 또는 공용 네트워크로의 FTP 트래픽을 허용하는데, 방화벽으로 표준 FTP포트를 경유하는 FTP접근이 감지되면 proxy의 수행이 시작된다. 이점에 착안하여 방화벽 호스트의 FTP proxy가 방화벽 호스트를 통과하는 FTP 트래픽을 검사, 전송 파일에 바이러스의 감염 여부를 판단할 수 있게 시스템을 구축할 수 있으리라는 예측을 할 수 있다.
    이 시스템을 좀 더 구체화 시켜보자.

     

    T FTP-GW를 통한 바이러스 검색 시스템.

    ① 내부 사용자가 외부 인터넷으로부터의 파일 전송을 위해 방화벽 호스트에 접속.
    ② 간단한 인증 절차를 거친 후 원래 접속하고자 하는 외부 호스트로 접속.
    ③ 사용자는 필요한 파일을 전송 받는다.
    ④ 파일 전송시 FTP-GW는 내부 사용자의 호스트로 파일을 전송함과 동시에
        방화벽 호스트(혹은 임의의 호스트)에 동일의 파일을 임의의 이름으로 저장.
    ⑤ 파일 전송이 끝나기 직전 해당 파일의 바이러스 감염 여부 조사.
    ⑥ 바이러스 감염시 경고문을 사용자에게 알려준다.
    ⑦ 파일 전송을 마친다. 임시 저장 파일은 삭제한다.
    ⑧ 사용자 요구시 외부 호스트 접속 종료.
    ⑨ 사용자 요구시 방화벽 호스트 접속 종료.

     

    <그림 4-1> FTP-GW에서의 바이러스 검사

     

    <그림 4-2> Linux에서 FTP로 파일을 전송한 예

    FTP-GW를 통과하는 FTP 트래픽을 가로채 그것을 임의의 파일로 저장한 후 그 파일이 바이러스에 감염이 되었는가 검사한다. 사용자에게로 전송되는 파일과 동일한 내용이 저장된다면 바이러스 검색은 그리 어렵지 않다. 쉽게 생각해본다면 방화벽 호스트, 혹은 임시 파일이 저장된 호스트에서 돌아가는 일반적인 바이러스 검색 프로그램을 이용하여 그 감염 여부 메시지를 넘겨받는 방법도 있고 또 직접 그 바이러스 검색 루틴을 자체적으로 구현할 수도 있다. 본 프로젝트에서 구현한 바이러스 검색 방법은, 일반적인 바이러스 검색 프로그램을 통한 검색은 별 의미가 없다고 판단되어(물론 상업적으로나 안정성으로는 이것이 더 유리할 수 있다. ) 바이러스 검색 루틴을 직접 구현하였다. 우리의 방화벽 호스트는 Linux(UNIX) 머신이기 때문에 바이러스 검색 루틴은 기간 DOS용으로 구현된 루틴들을 모두 Linux(UNIX)에서 돌아갈 수 있도록 수정하고, 데이터를 보완하였다.

    FTP-GW에서의 바이러스 검색을 위해서는 단지 바이러스 검색을 위한 루틴뿐만 아니라 기존의 TIS Firewall Toolkit의 FTP-GW source의 수정도 불가피하다. 바이러스 검색이 추가된 FTP-GW 가 실행되기 위해서는 Netperm-table에 FTP-GW 옵션으로 -virus를 추가해 주어야 한다. 그러면 이제부터는 표준 FTP로의 파일 전송시 전송되는 파일의 바이러스 감염 여부를 확인할 수 있다. 다음 그림은 FTP전송시 바이러스 감염 여부를 확인한 예이다. 본 프로젝트의 방화벽 시스템 내 FTP-GW에서 FTP트래픽을 가로채어 전송되는 파일의 바이러스 감염 여부를 확인하는 시스템을 구현해 보았다. 바이러스 검색 루틴은 DOS상에서 돌아가는 루틴을 Linux(UNIX)에서 작동되도록 수정하였다. 한가지 아쉬운 점은 이 바이러스 검색 시스템은 압축 파일 내의 내용물에 대한 바이러스 검색을 고려하지 않았다는 것이다. 이것은 실지로 바이러스 검색 루틴의 자체제작보다는 기존의 바이러스 검색 프로그램을 이용하는 것이 성능 면에서는 뛰어나다고 생각한다. 그렇다고 할지라도 직접 구현해볼 생각이라면 다음과 같은 작업이 더 추가되어야 할 것이다.

     

    압축된 파일에 대한 바이러스 검색 전략

    ① 임시로 저장된 파일의 압축된 형식을 조사한다.
    ② 임시 디렉토리에 압축 파일을 푼다.
    ③ 풀려진 파일에 대한 바이러스 검사.
    ④ 바이러스가 검출되었을 때 메시지 전송.
    ⑤ 풀려진 파일들과 임시 파일을 지운다.

 

SSL Telnet

    본래 인터넷은 보안을 염두에 두고 만들어지지 않았다. 그렇기 때문에 인터넷을 사용하다 보면 공개되어서는 안될 정보가 유출되거나 사생활까지도 침해당하는 경우가 생기게 되었다. 그래서 안전하고 신뢰성 있는 통신을 제공할 수 있는 방법들이 많이 제안되었다. SSL은 그러한 목적을 위해 제안된 프로토콜이다. 우리는 이것을 이용하여 인터넷 프로토콜 중 가장 많이 쓰이는 프로토콜의 하나인 Telnet에 보안 기능을 가미하고자 하였다.

     

    <표 5-1> SSL 버전

    SSL은 TCP/IP와 같은 연결 지향 네트워크 계층 프로토콜(connection-oriented network layer protocol)과 HTTP, FTP, Telnet과 같은 응용 프로토콜 계층(application protocol layer) 사이에 위치하는 프로토콜 계층으로 응용 프로그램에서 전달되는 내용을 암호화하여 이를 전송하는 프로토콜이다. SSL은 기존의 소켓 계층을 완전 대체하는 것은 아니고 기존의 소켓이 열어져 있는 상태에서 사용하는 프로토콜이기 때문에 SSL과 일반 Socket을 병행하여 사용하는 것이 가능하다. Telnet을 예로 든다면, SSL을 지원하는 Telnet 서버를 작성하여 운영하는 호스트가 있다고 할 때, SSL을 이용한 접속과 그렇지 않은 접속 모두가 가능하도록 작성을 할 수 있다는 이야기다. 또한 SSL 은 클라이언트(Client)와 서버(Server) 사이에 전자 서명을 통하여 상호 인증(mutual authentication)을 제공한다. 클라이언트와 서버 서로가 서로의 인증서를 요청하고 받아서 확인하여서 서로가 신뢰할 만한가를 평가하게 된다.

    <표 5-1>는 SSL Protocol의 버전들을 보여주고 있다. SSL 3.0에서의 특징이라면 인증서 체인을 지원한다는 것이다. 이것은 한 서버가 서버의 인증서를 발행한 곳의 인증서와 함께 브라우저(browser)에 보내는 것을 허용한다는 뜻이다.

    이것은 가능함으로써 서버의 인증서가 공인된 공증 사무소에서 발행된 것인지 서버 스스로가 만들어 낸 인증서 인지를 알아 낼 수 있게 된다. SSL 3.0은 IETF(Internet Engineering Task Force)에서 현재 연구 개발 중에 있는 TLS(Transaction Layer Security) 프로토콜 표준의 기초가 되었다.

    SSL을 사용하는데 있어서 우선 결정하여야 할 것은 기존의 프로토콜이나 응용 프로그램과의 투명성을 제공할 것인가 하는 것이다. 기존의 프로토콜 위에 SSL을 사용할 것인지를 결정하는 프로토콜을 확장하여 사용한다면 동적으로 SSL을 이용할 수 있다. 그렇지 않다면 SSL을 이용하는 응용 프로그램간에만 통신을 제공할 수 있다. Telnet의 경우 RFC1409에 나와있는 인증 모델(Authentication models)을 이용하여 동적으로 SSL을 이용하도록 할 수 있다.

     

    1) 클라이언트 프로그램의 구조

    ① SSL 구조체를 생성한다.
        Con = (SSL *) SSL_new();
    ② 일반 소켓을 열어 서버에 연결한다.
        socket(), bind(), connect();
    ③ 소켓의 파일 디스크립터(file descriptor)를 SSL에서 사용하도록 설정한다.
        SSL_set_fd(con,  s);
    ④ SSL을 사용하도록 연결을 한다.
        SSL_connect(con);
    ⑤ read() / writer 를 대신 하여 SSL_read ./SSL_write 를 사용한다.
        SSL_write(con,  "bye\n",4);

     

     

    2) 서버 프로그램의 구조

    ① SSL 구조체를 생성한다.
        con  =  (SSL *) SSL_new();
    ② 일반 소켓을 열어 연결을 기다린다.
        socket(), bind(), listen(), accept();
    ③ 소켓의 파일 디스크립터(file descriptor)를 SSL에서 사용하도록 설정한다.
        SSL_set_fd(con, s);
    ④ 비밀키 파일을 설정한다.
        SSL_use_RSAPrivateKey(con, "Server.cert");
    ⑤ 인증서 파일을 설정한다.
        SSL_use_certificate(con, "Server.cert");
    ⑥ SSL 연결을 수용한다.
        SSL_accept(con);
    ⑦ read() / write를 대신 하여 SSL_read  ./SSL_write를 사용한다.
        SSL_write(con, "bye\n",4);

 

    기존의 Telnet을 사용했을 때는 스니핑(네트워크를 지나다니는 Packet을 분석하여 정보를 빼내는 해킹 수법) 공격에 무력하다. 그러나 SSL을 이용한 Telnet을 통해 통신했을 경우에는 Packet이 유출되더라도 암호화된 데이터이기 때문에 해석이 불가능하므로 안전한 통신을 할 수 있다. 본 프로젝트에서는 공개된 간단한 Telnet 소스에 공개된 SSL Library인 SSLeay를 이용하여 SSL 루틴을 추가 구현하였다. SSL Telnet을 사용할 경우에는 -ssl 옵션을 사용한다.

 

SSL-Gateway

    여기에서 구현하고자 하는 것은 SSL 서비스를 방화벽 호스트를 통하여 제공하고자 하는 것이다. 그런데 SSL은 client와 server간에 3 way-in-the-middle-attack을 방지하는 구조를 가지므로 실지로 application level firewall에서는 프락시 할 수 없다. SSL은 프락시 서비스를 middleman으로 간주하므로 우리가 실지 구현해야 할 것은 SSL tunneling이다.
    SSL Tunneling은 기본 HTTP를 통한 SSL 연결이 시도될 때 handshake가 발생하고 byte-forwarding tunnel을 통한 secure connection이 성립한다. Proxy는 client-proxy request header로 연결이 성립되고 session은 암호화된다. 다음은 proxy server를 통한 세가지 SSL Tunneling mechanism이다.

     

    ① Client는 "user agent" 메시지를 보낸다.
        Ex) "Mozila/3.0/Macintosh"
    ② Proxy는 외부 인터넷 접속을 위한 인증 요구를 client로 전송한다.
    ③ Connection의 확립, client는 요구하는 URL을 firewall로 전송.

 

    1) Apache-SSL

    SSL-Gateway 동작 시험을 위해 우리는 Apache-SSL WWW server를 설치하였다. Apache-SSL WWW server는 영국의 Ben Laurie가 Apache server와 SSLeay library를 기반으로 만든 SSL server로서, Apache server의 socket 부분 등을 Ssleay API로 바꾸고 SSL에 필요한 configuration 등을 인식하기 위해 apache_ssl module을 추가한 것이다.

    실제로 통신을 하기 위해서는 서버가 사용할 열쇠 쌍을 생성하고 그 열쇠의 증명서를 만들어야 한다. 증명서는 서버 자신이 증명하는 자체 증명서(dummy certificate)와 공증 사무소에서 발행하는 일반 증명서의 두 가지가 있다. 우리는 자체 증명서를 사용하였다. Apache SSL을 만든 directory에서 make certificate를 실행하면 SSLconf/conf/httpsd.pem이라는 파일이 생긴다. 이것은 다음 명령과 같은 의미이다.

      req -new -x509 -out ../SSLconf/conf/httpsd.pem -keyout \ ../
          >>SSLconf/conf/httpsd.pem

    공증 사무소에서 증명 받기 위해서는 먼저 공증 사무소에 보낼 신청서를 만들어야 한다.

      req -newkey 512 -new>new-req.pem

    위와 같은 명령을 실행하면 X.500 형식으로 서버의 정보(이것을 고유 이름 - Distinguished Name : DN - 이라 한다. )를 입력하라는 요구가 나타난다. 여기서 국가(Country :C)는 ISO 3166 Country code를 따르는 두 글자 표현으로써, 한국의 경우 KR 이어야 한다. 또한 CN(Common Name)은 서버의 호스트 명으로 하여야 한다. X.500형식에 관한 자세한 사항은 X.500형식에 관한 자세한 사항은 X.520[X520]을 참조하기 바란다.

    열쇠 쌍을 생성하면, new-req.pem과 privkey.pem의 두 파일이 생성된다. Privkey.pem은 비밀 열쇠로서 서버 관리자가 보관하고, new-req.pem을 공증 사무소에 보낸다. 공증 사무소에서 증명서를 보내주면, privkey.pem은 비밀 열쇠로서 서버 관리자가 보관하고, new-req.pem을 공증 사무소에 보낸다. 공증 사무소에서 증명서를 보내주면, privkey.pem과 받은 증명서를 합쳐서 SSLconf/conf/httpsd.pem 혹은 httpd.conf에서 SSLCertificateFile directive로 지정한 파일 이름으로 저장한다.

    흔히 알려져 있는 증명서의 종류에는 다음과 같이 3가지가 존재한다.

    서버 증명서 (Site certificate)

    이 서버가 이 이름을 가지고 있고, 이런 공개 열쇠를 가지고 있다는 것을 증명한다. 공증 사무소의 서명으로 증명되는 것이 보통이다. SSL을 사용한 접속이 이루어지려면 최소한 서버 증명서는 있어야 한다. browser에 서버 증명서를 설치하면 해당 서버와의 연결을 신용한다.

    CA 증명서 (CA certificate)

    공증 사무소 (CA: Certification Authority) 자신을 증명한다. 공증 사무소들끼리 증명해 주었을 경우 다른 공증 사무소의 서명으로 증명되며, 그렇지 않은 경우 자기 자신의 서명에 의해 증명된다. browser에 CA 증명서를 설치하면 해당 공증 사무소가 증명하는 모든 증명서를 신용한다. (단, 모든 증명서 중에는 다른 CA 증명서도 포함된다는 점에 유의하라.)

    사용자 증명서 (User certificate)

    클라이언트를 사용하는 사람이 누구이고 그 사람의 공개 열쇠가 이렇다는 것을 증명한다. 공증 사무소의 서명으로 증명된다. 서버가 요구될 때만 서버에게 전달되며, password 혹은 pass phrase로 암호화되어 저장된다. browser에 사용자 증명서를 설치하면 서버가 강력한 사용자 확인을 요구할 수 있으며, 서버와 클라이언트간 쌍방 암호화 통신을 할 수 있다.
    <그림 6-1>은 SSL-GW를 통한 SSL host로의 접속 화면이다.

    <그림 6-1> SSL-GW를 통한 SSL host로의 접속

 

프로젝트를 마치며...

    본 프로젝트는 네트워크를 통하여 바이러스의 감염되는 것을 막고자 기존 방화벽에 바이러스 검색기능을 추가하고자 하였다. 하지만 바이러스에 대한 자료나 바이러스의 검색에 관한 자료들을 수집하는데 어려움을 겪었고, 그나마 구해진 자료가 오래된 바이러스에 대한 검색기능은 구현을 할 수가 없었고, 관리 도구에 사용자 접속 통계와 같은 모니터링 기능을 추가하고자 하였으나 시간의 부족으로 구현하지는 못한 것이 아쉬움으로 남는다.

    S/key 일회용 패스워드 인증 시스템을 구축하고 사용하며 보안에 대한 많은 관심을 가지게 되어 SSL을 이용하여 보안상 안전하고 신뢰성 있는 통신을 제공하는 Telnet프로그램을 작성하게 되었다. 그러나 Telnet 프로토콜에 대한 이해의 부족과 SSL라이브러리 사용법에 대한 자료가 부족하여 많은 어려움을 겪었다.

    SSL을 사용한 WWW 서비스를 사용할 수 있도록 SSL-GW를 작성하였고, 이를 이용하여 안전한 Web 서비스를 통하여 사용자 인증에 관한 DB를 접근 관리하게 하였다. DB 접근을 위한 CGI를 C와 <본문>PHP/FI를 이용하여 작성하였다. PHP/FI라는 새로운 기술을 활용하고 그 가능성을 시험 해 볼 수 있어서 좋았다. 앞으로 많은 발전과 활용이 기대되는 기술이다.

    3개월 동안 개선할 사항들이 남아있긴 하지만 목표로 삼았던 모든 기능을 구현하게 되어 기쁘다. 개선할 사항들은 독자들의 실력에 맡긴다. 그리고 약속한 대로 본 프로젝트에 관계된 자료와 소스들을 천리안, 나우누리, 하이텔 리눅스 동호회에 올린다. 많이 참고 하길 바란다.




▲ top

home으로...