인터넷 접속 제어

인터넷을 이용하는 프로그램의 핵심에 웹 브라우져가 있다고 가정하고 만드는 보안 장비들이 있습니다. 그들의 주 타겟은 사용자의 인터넷 접속을 제한하는 것인데, 모든 웹 트래픽을 사용자 인증을 거치도록 리다이렉션 시킨다음 인증되고 나면, 해당 브라우저에 cookie나 혹은 auth header등을 설정하게 만들거나 해당  IP를 등록하여 이후의 인터넷 접속을 허용하는 방식으로 구현이 됩니다.

문제 발생

아, 그런데 여기에서 웹브라우저가 아닌 것들과 문제가 발생합니다. 저희 회사의 제품에서도 80번 포트를 이용한 HTTP로 업데이트를 하고 있습니다만, 이것은 사용자의 인터렉션을 기대하기 어렵습니다. 라이브러리만 HTTP를 이용하는 수준으로 개발되기 때문입니다. HTTP 프로토콜을 사용하는 어플리케이션 개발자들은 대개
  • IE Component를 이용하거나
  • HTTP+SSL library 를 이용하거나
  • tcp로 직접 HTTP를 구현하거나
하는 방법을 사용하게 됩니다. 그러나 네트워크 보안제품을 만드는 사람은 어떻게든 불편을 감수하고서라도 관리자에 의해 통제 가능하도록 만듭니다.

보안 제품 개발

이런 보안 제품은 최대한 정상적인 흐름을 건드리지 않고 그 흐름을 제어 하게 됩니다. network fire wall, personal fire wall, qos, switching hub, transparent proxy, load balancer, nat, ips 등등... 일개 어플리케이션 개발자들이 굳이 알지 않아도 그들은 다 회피시켜주는 것을 원칙으로 합니다. 다만, 인터넷 접속 제어만은 인증을 요구하여 최초 한번만 용서를 구하도록 개발되고, 이런 보안 프로그램과 일반 어플리케이션이 충돌하게 되면, 어플리케이션이 접속하는 서버들은 고정되어 있으므로, 그 서버 리스트를 제작자에게 요청하여 예외 항목에 등록하게 됩니다.

예외 관리 및 관리 회피 개발간의 갈등

여기에서 갈등이 생깁니다. 네트워크 관리자는 어플리케이션마다 예외를 추가하는 부담스러운 관리를 해야합니다. 필수 어플리케이션이 아닌 상황에서야 VIP(임원진) 들이 요청하는 것외에는 예외을 둘 수 없는 상황이 생깁니다.

그런데 그런 네트웍 안에 있는 어플리케이션 사용자들은 왜 이 제품이 정상적으로 동작하지 않는지 알 수 있는 방법이 없습니다. 제품 개발사에 문의를 하는 것 밖엔 없지만, 연락을 잘 하지 않습니다.

그렇다고, 어플리케이션 개발자들도 상상하지 않았던 보안제품이 설치된 환경에서 동작할 때의 이상현상이란 직접 보지 않고는 알 수가 없기 때문에 어떤 식으로 대처해야 할지 모릅니다. 대개, 보안 제품과 충돌할 때, 허용리스트를 네트워크 관리자에게 전달해주면 모든게 끝날수 있지만, 그렇게 모든 문제가 생기는 네트워크마다 가이드 해줄 수 있는 것도 아닙니다. 게다가 서버가 증설되거나 변경이 되면 다시 모든 네트워크 관리자에게 전달해주어야합니다.

결국... 개발자가...

이런 갈등은 소비자/생산자, 관리자/개발자 간의 알력이 포함될 수 밖에 없습니다. 여기서 문제는, 보안 제품쪽 개발자가 수 많은 어플리케이션의 요구사항에 맞춰 지능화 시키기란 어렵다는 것입니다. 어플리케이션 개발자가 늘 지는 구도로 갈 수 밖에 없고, 처음 몇번은 회피 목록을 관리자에게 전달하여 우회시키는 것을 해답으로 제시하겠지만, 다시 이런 일로 고객지원을 하지 않게 하려면, 어플리케이션에서 사용하는 HTTP를 마치 인터넷 익스플로러를 사용할 때 나올 법한 오류 메시지로 진화시켜야합니다.

이런 개발자들을 우리는 칭찬해 주어야합니다.


신고
HTTP: Hyper Text Transfer Protocol
SMTP: Simple Mail Transfer Protocol
POP3: Post Office Protocol ver 3
NNTP: Network News Transfer Protocol
FTP: File Transfer Protocol

HTTP는 다른 프로토콜보다 상당히 젊다. 만들어진 시기를 RFC 등록일로 조사해보니 다음과 같다.

FTP: RFC 765 - 1980
SMTP: RFC 821 - 1982
POP: RFC 918 - 1984
NNTP: RFC 977 - 1986
HTTP: RFC 1945 - 1996

HTTP의 경우 RFC 1945에서도 기술된 바와 같이 1990년부터 만들어져 사용되어 왔다고 기록되어 있다. 다른 프로토콜도 그정도는 아닐지라도 사용은 먼저되어오다가 RFC 트랙을 밟았으리라 생각되는데, 굳이 연도를 들먹이는 이유는 다름아닌 근대화된 프로토콜의 차이점이 무엇일까를 생각해보고자 한다.

이들은 모두 telnet 명령으로 쉽게 흉내를 낼 수 있는 간단한 줄단위 프로토콜이다. 이 말은 telnet을 네트워크 프로그램의 디버거라고 불러도 좋을 정도로 직관적인 프로토콜들인데, 이들은 다음에서 가장 큰 차이가 난다.

HTTP는 client가 먼저 전송하고 server가 응답을 준다.
FTP,SMTP,POP3,NNTP는 서버가 먼저 자신의 존재를 전송한다.

이 간단한 차이는 다음과 같은 이점이 있다.

1. 포트 스캐너에 의해 정체가 쉽게 드러나지 않는다.

이 얼마나 10년이 지나도록 유지되어왔던 관행을 깬 것인가. 맏형 FTP부터 NNTP들은 접속하자 마자 어서옵쇼하면서 정체를 드러낸다. 정말 보안이 필요없는 정직한 세상에서 태어난 존재들이기 때문에 그렇게 설계되지 않았을까?

2. 서버의 프로토콜 버전을 올리기가 쉽다.

SMTP, POP3, NNTP 등은 서버부터 버전을 말해야하므로, Client와 협상해야하는 과정이 필요하다. SMTP의 경우 EHLO, POP3의 경우 APOP 과 같은 여러가지 확장기능이 있다. 그런데, HTTP의 경우 client 가 어떤 버전인지를 먼저 말해오므로, 그것에 따라 맞춰 반응해주면 되기 때문에, 불필요한 협상과정을 최소화 하여 속도록 높힐 수 있게 된다.

3. 네트웍의 트래픽을 최소화 할 수 있다.

서버란 모름지기 요청에 대한 응답을 주는 것이다. 그말은 가장 최소한의 데이터 교환은 접속후 한 번의 요청과 한 번의 응답으로 구성되는 2 개의 패킷이 필요한 것인데, 서버부터 뭔가가 내려가야한다면 그 과정은 적어도 3 개의 패킷이 필요하게된다. 안된다. 바쁜 세상 줄일 수 있을 때까지 줄여야지.

4. 클라이언트가 눈치 채지 못하게 프락시를 구성하기 쉽다.

자명하지 않은가. 클라이언트가 어딘가로 가는 것을 가로채서 자신이 요청사항을 받고서 적절한 처리를 하고 종료하는 것이 가능해진다. HTTP의 경우 캐시도 가능해진다. 그러나 다른 서비스들도 가로챌 수는 있으나 반드시 그 서버에 접속해서 server hello를 받아서 전달하기 전까지는 눈치 채지 못하게 구성하기란 쉽지 않다.
논리가 쫌 약한가? 하지만 이 기능은 로드밸런서를 생각할 때 자주 고민되는 문제가 될 수 있다. 서버는 하나로 보이게 하나 요청에 의해 분배되는 구조! 클라이언트가 먼저 보내는 것만이 일을 쉽게 할 수 있다.

막내가 제일 똘똘한만큼 거기에는 위와 같은 얘깃거리가 담겨있다.
신고

+ Recent posts