수년 전 발생했던 농협 전산망 해킹사고와 320사태 그리고 신용카드 3사의 엄청난 개인정보 유출사고에서 가장 핵심적인 취약성은 바로 “서버내부의 명령어에 대한 실행 통제 불가”와 “서버에 Telnet, SSH 접속 시 2차 인증 부재”다.
사실 서버가 해킹당하는 경우 위의 두가지 이슈가 가장 핵심적인 보안 취약성임에도 최근까지는 대부분 네트워크 수준에서 침투를 막지 못했다는 결과로 귀결시켜 조직 내부의 서버에 대한 보안이슈가 발생하는 것을 피해갔던 것이 사실이다.
하지만 2013년 금융감독원의 금융감독규정이 개정되면서 서버에 대한 접속 시 2차 인증 의무화와 서버 내에서의 위법행동 발생 시 즉각적인 조치가 가능한 수단 강구라는 항목이 추가되었다.
[금융감독원 금융감독규정 제14조 9항과 10항]
이에 따라 금융기관들의 움직임이 바빠지고 있는 듯 하다. 지금까지는 시스템관리자들의 고유 권한으로써 장애발생 가능성을 이유로 신성불가침???의 영역처럼 여겨져 명령어의 사용에 대해 제약을 두지 않았으나 대형 보안사고의 주요 취약성으로 “서버내에 접속한 사용자/개발자/관리자/엔지니어에 대한 명령어 실행 통제 미흡”이 언급되기 시작하였고 결국 금융감독지침에 구체적으로 명령어 사용에 대한 통제 항목이 포함되었다.
서버내의 명령어 실행 통제를 위한 세가지 기술 동향
서버 내에서의 명령어 실행…더 나아가 서버 내의 중요 파일에 대한 읽기/수정/삭제 등을 통제하기 위한 다양한 기법의 솔루션이 이미 존재하고 있다. 그리고 이러한 명령어 실행을 통제할 수 있는 솔루션 들은 크게 3가지 정도의 제품군으로 분류될 수 있다.
1. 게이트웨이 방식의 서버접근제어(SAC) 기법
이 방식은 서버에 접근하는 모든 사용자가 프락시형태의 게이트웨이 장비를 통해 Telnet/SSH 접속을 하게 되고 게이트웨이 장비에서 서버로 전달되는 명령어를 분석하여 통제하는 방식이다.
하지만 이 방식은 우회접속이나 서버와 서버간의 직접 접속 등을 통제하지 못하기 때문에 사실 거론의 대상이 되어서는 안되는 방식이다. 흔히 서버에 별도의 통제 SW를 설치하지 않아도 되고 장비하나만 도입하면 되기 때문에 수년전까지 선호되던 방식이나 최근 여러 감독기관의 보안감사에서 우회접속과 콘솔을 통한 직접접속에 대한 통제가 불가능한 사실이 알려지면서 명령어 통제기술로는 부적합하다는 것이 일반적인 평가다.
많은 SAC 솔루션 개발사에서 다양한 방법을 통해 이러한 단점을 극복하려 노력하고 있으나 워낙 해결하기 어려운 기술적문제가 많아 단시간내에 제대로 된 명령어 통제 기능을 수행할 것으로 기대하긴 어렵다.
2. TTY 복제 및 쉘(Shell : ksh, csh 등) 교체 방식의 명령어 통제 기술
게이트웨이 방식과는 달리 서버에 직접 응용수준에서 동작하는 보안SW를 설치하는 에이전트 방식의 명령어 통제 기법이다. 사용자가 Telnet, SSH를 접속하면 TTY라 부르는 터미널 디바이스를 할당받는데 보안SW가 하나의 TTY를 더 할당받아 TTY와 Shell 사이에 끼워 넣어 화면에 입출력되는 명령어를 가로채어 통제하는 방식이다.
또 하나의 방식은 /etc/passwd에 사용자마다 지정되는 shell을 보안SW 개발사에서 만든 shell로 변경하는 방식이다.
이 두가지 응용수준에서 동작하는 명령어 통제 방식의 공통점은 Shell로 전달되는 키보드를 통해 입력된 명령어를 가로채 검사한다는 점이다. 이 방식은 게이트웨이 방식보다는 장점이 많고 통제할 수 있는 영역이 넓기는 하지만 응용수준에서 동작하기 때문에 역시나 우회하거나 통제하지 못하는 명령어 실행이 많을 수 밖에 없다.
예를들어 알리아스가 설정된 명령어의 실행이나 쉘스크립트 혹은 다른 명령어 내에서 위험한 명령어를 실행하는 행위를 통제할 수는 없다. 간혹 쉘스크립트를 파싱하여 분석하여 통제한다고 하나 스크립트를 2중, 3중으로 작성하거나 스크립트가 아닌 실행파일로 만들어 그 실행파일 안에서 명령어를 실행할 경우 쉽게 통제가 뚫리는 취약성을 갖고 있을 수 밖에 없다.
또한 명령어는 사용자 쉘에서만 실행되는 것이 아니다. 앞에서 언급된 대형 보안사고에서와 같이 사용자가 직접 실행하지 않고 백신업데이트 서버나 시스템관리소프트웨어 등 다양한 소프트웨어가 실행하여 발생된 사고도 많다.
때문에 게이트웨이 방식보다는 우월하나 여전히 제대로 된 명령어 통제를 수행할 수 없는 것이 사실이다.
3. 운영체제 커널 수준에서의 명령어 통제 기술
서버내에서 명령어의 실행이나 파일에 대한 수정은 최종적으로 운영체제 커널의 시스템콜을 호출하게 된다. 운영체제의 커널에 동적으로 로드될 수 있는 커널모듈을 만들어 아래 그림처럼 시스템콜 테이블과 실제 시스템콜 루틴 사이에 끼워넣어 모든 파일에 대한 실행/수정/삭제/생성 등을 검사하는 방식이다.
SecureOS의 Security Kernel (RedCastle)
이 기술은 이미 1990년대 후반부터 세계적으로 사용되기 시작하여 국내에서는 2000년 초반대에 안정적인 동작을 보장하는 솔루션이 출시되기에 이르렀다.
이 커널수준에서의 사용자 추적과 명령어 실행통제 및 파일에 대한 수정/삭제의 통제는 보안소프트웨어가 커널에 로드되는 점 이외에는 단점보다는 장점이 더 많은 것이 사실이다. 우회접속에 대한 우려와 알리아스, 심볼릭링크, 콘솔접속에 의한 명령어 실행은 물론 다중 레벨 스크립트와 서비스대몬 및 명령어 내에서 실행하는 명령어에 대한 추적과 통제도 완벽하게 수행된다.
마무리
이렇듯 서버 내에서의 명령어 통제에 대한 문제를 해결하기 위한 솔루션은 이미 시장에 넘쳐난다. 다만 어떤 솔루션을 선택하느냐의 문제다. 서버에 커널 수준에서 동작하는 소프트웨어를 설치하기 부담스럽다면 쉽게 우회할 수 있는 취약성이 있더라도 느슨한 통제를 수행하는 솔루션을 선택하면 되고 명령어 통제라는 이름에 걸맞는 제대로 된 명령어 통제를 구현하고 싶다면 커널 수준에서 동작하는 명령어 통제 솔루션을 선택하면 된다.
관련포스트 : https://blogger.pe.kr/401