태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

secureos (7)



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

    비밀댓글입니다


해커들이 해킹을 통해 침투하고자 하는 컴퓨터는 딱~ 두종류로 요약된다. 개인의 비밀스런 정보가 저장되어 있는 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 신고

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


Windows, Linux, Unix 등 서버엔 많은 관리자나 엔지니어들이 접속하여 관리를 수행한다. 여기서 "접속"이라 함은  일반적인 웹서비스나 일반 업무 프로그램을 통한 접속이 아니라  telnet, ssh, terminal service 등 서버의 관리를 위해 운영체제에서 기본적으로 제공하는 접속 환경을 말한다.

SSH 혹은 telnet을 통해 Unix/Linux 서버에 접속하면 아래와 같은 화면이 표시된다.

이때부터 서버의 관리는 그 옛날 DOS시절보다 더 복잡한 명령어를 실행하거나 설정함으로써 이루어진다. 서버의 보안관리상의  문제는 여기서 부터 발생한다. 

1. 누가(사람) 언제 어디서 접속하였는가 ?

2. 어떤 계정으로 접속하였는가 ?

3. 어떤 명령을 실행하였는가?

4. 명령 실행 후 어떤 결과가 화면에 표시되었는가?

5. 어느 파일을 수정하였는가 ?

6. 명령 실행 혹은 파일 수정 후 어떤 에러가 발생하였는가?

위의 6가지에 대한 감사(Audit)를 수행하기 위해서는 운영체제의 기본 기능만으로 구현할 수는 없다. Unix와 Linux 그리고 Windows는 훌륭한(?) 운영체제지만 보안을 특별히 고려한 운영체제라고 보기는 어렵다. 서버의 보안을 강화하기 위해 특별한 기능을 기대하지는 않는 것이 좋다.

그렇다면 위의 6가지 감사 이슈를 충족하기 위해서는 어떤 방법을 취할 수 있을까? 역시 가장 확실한 방법은 서버보안SW를 적용하는 것이 가장 확실하다 하겠다.

SecureOS는 다음의 두가지 사용자 및 관리자의 행위추적 기능을 제공한다.

1. 커널수준에서 수행되는 "사용자 추적"

2. 응용수준의 입출력디바이스에 대한 모니터링을 수행하는 "TTY 모니터링"

몇몇 서버보안 제품들과 서버 감사로그 수집솔루션에서는 TTY모니터링 기능만을 제공하지만 레드캐슬은 커널수준의 사용자 추적과 TTY 모니터링을 모두 제공하고 있기 때문에 보다 상세하고 강력한 감사기능을 지원하고 있다.

1. 커널수준의 사용자 추적

말 그대로 커맨드라인에서 입력된 명령행이 exec() 시스템콜에 의해 커널에 전달된 시점에서 로그인한 사용자 세션을 식별하여 세션별로 수집/저장하는 행위추적 기능이다. exec() 시스템콜을 가로채어 감사로그를 저장하기 때문에 커맨드라인에서 직접 입력한 명령어 뿐만 아니라 실행된 명령어 혹은 스크립트가 내부적으로 실행하는 exec() 시스템콜도 가로채어 감사로그를 기록할 수 있다.

이는 화면에는 보이지 않고 백그라운드로 실행되는 명령어도 감사로그 기록이 가능하다는 의미다. 때문에 보다 정확하고 상세한 감사로그를 남길 수 있다. 예를 들어 외부 엔지니어가 작업상의 편의를 위해 미리 스크립트를 만들어 가져온 뒤 서버에 업로드하고 한꺼번에 실행하는 경우 커널수준의 사용자 추적에서는 그 스크립트 안에서 실행되는 명령어까지도 빠뜨리지 않고 감사기록을 남길 수 있다는 것을 의미한다.

또한 TTY 모니터링과는 다르게 보안SW가 구동중이면 우회하거나 무력화할 수 없으며 화면의 입출력을 가로채는 동작이 없기 대문에 여러 명령행의 "붙여넣기" 혹은 DBA들이 자주 사용하게 되는 길다란 ~ SQL문의 "붙여넣기" 시에도 영향을 주지 않는다.

커널기반 사용자 추적 조회 화면 (Windows / Linux / Unix 공통)

이 커널기반의 사용자 행위 추적 기능은 타 서버보안SW 혹은 감사로그 수집 솔루션에서 지원하지 못하고 있는 기술이다.

2. TTY기반의 사용자 추적

TTY란 Telnet, SSH, rlogin 접속 시 운영체제가 사용자 세션에게 부여하는 가상의 터미널디바이스 이름이다. TTY는 옛날 타자기(TeleTYpewriter)의 입출력을 컴퓨터 상에 접목시키기 위해 만들어진 것으로서 사용자가 접속할 때 1개씩 부여되고 키보드의 입력과 화면의 출력이 사용자가 접속할 때 부여된 터미널디바이스(즉 TTY)를 통해 이루어진다.

대부분의 서버보안 제품 및 TTY모니터링을 지원하는 로그통합관리 제품들은 동일한 방식 즉 TTY를 모니터링하는 기법을 사용하여 사용자 추적을 수행한다. 이 기술은 커널 수준이 아닌 응용프로그램 수준에서 동작하며 운영체제의 기본적인 설정 중 일부를 변경해주어야만 동작한다. 즉 어떤 파일을 변경하면 되는지를 알면 root 권한을 얻었을 때 해당 설정을 수정하며 감사기록이 남지 않도록 할 수 있다는 이야기다.

그럼에도 불구하고 TTY 모니터링 기법은 중요한 장점을 갖고 있는데 그것은 바로 명령 수행의 결과로 출력되는 내용까지도 감사기록으로 남길 수 있으며 온전한 입력과 출력을 모두 로깅하기 때문에 "동영상" 처럼 재생시켜 볼 수 있다는 장점이 있다.

Windows 서버에 대한 사용자 행위 추적(GUI수준)

 Unix / Linux 서버에 대한 TTY 수준의 행위추적 (GUI수준)

개인정보보호법이 발효된 이후 시스템에 대한 보안 점검 시 "관리자의 행위에 대한 감사로그"를 남기고 있느냐가 무척 중요한 이슈로 떠오르고 있다. 이에 대해 완벽하게 대응하기 위해서는 TTY수준(GUI수준)에서의 행위 감사와 TTY수준의 행위 감사가 무력화 되었을 경우를 대비한 커널수준의 사용자 추적 두가지가 모두 필요하다.




또한 번의 보안사고가 전산업계를 뒤흔들고 있다. 하지만 이전의 보안사고들과는 달리 외부(인터넷을 통해)에서 침입하여 현대캐피탈 고객 42만명의 개인정보는 물론 일부 금융정보까지 빼내어간 완벽(?)한 해킹사고라는 점에서 충격의 여파는 상당히 크고 오래 지속될 것으로 보인다. 비록 1금융권이 아닌 대출전문 캐피탈 업체이긴 하지만 업계 1위의 업체인데다가 "현대그룹" 이라는 간판으로 인해 1금융권도 보안에 취약한 것이 아니냐는 우려마저 나오고 있다.

= 대캐피탈 해킹사건의 전말. (이데일리 기사 발췌)=

◇ 해킹 피해 `42만명+α`..신용정보도 새나가

현대캐피탈 고객정보보호를 담당하는 황유노 부사장은 10일 서울 여의도 본사에서 열린 기자회견에서 "해킹 당한 고객 정보가 더 있을 수 있다고 판단하고 있다"고 말했다.
42만명과 프라임론 피해고객이 중복되기 때문에 현재까지 피해고객 총수는 파악하기 어려운 상태다.

현재까지 유출된 고객정보는 기본 정보 이외에 금융 정보가 포함돼 금융사고 피해가 우려되는 상황. 이름, 주소, 전화번호, 이메일, 주민등록번호, 신용등급, 신용대출 `프라임론` 패스카드의 번호와 비밀번호 등이 해킹당했다.

황 부사장은 "프라임론 패스카드 정보는 현대캐피탈과 거래 외에 활용할 수 없다"며 "신용등급 자체도 금전적 손해를 끼칠 가능성이 낮다"고 설명했다.

현대캐피탈은 2차 피해를 막기 위해 고객에게 "전화로 개인정보, 홈페이지 ID, 패스워드 등을 요구할 때 각별히 주의하라"며 "11일부터 프라임론 패스카드를 재발급받고, 홈페이지 비밀번호도 바꿀 필요가 있다"고 당부했다.

또 자동응답시스템(ARS) 거래를 막고, 거래 계좌를 변경하는 고객에게 고객 휴대폰으로 다시 전화해 본인 확인 절차를 강화했다.


◇ 2개월간 해킹 당한지도 몰라..정태영 사장 "수치스러워"

현대캐피탈이 해킹 사실을 두달간 인지하지 못했다는 점에서 문제의 심각성이 크다는 지적이다. 현대캐피탈 고객정보가 해킹당한 것은 지난 2월부터 조금씩 이루어진 것으로 현대캐피탈은 지난 7일 오전 9시 해커의 협박 이메일이 있을 때까지 모르고 있었다. 현대캐피탈 보안시스템에 큰 구멍이 뚫렸던 셈이다.

현대캐피탈은 지난 7일부터 서울지방경찰청 사이버범죄수사대에 해킹수사를 의뢰해 범인 검거를 위해 총력을 기울이고 있지만 현재까지 정확한 피해 규모와 범인의 소재를 파악하지 못한 상태다. 금융감독원은 오는 11일 정보기술(IT) 전문가로 대책반을 구성해 현대캐피탈 특별검사에 나서기로 했다.

정태영 현대캐피탈 사장은 이날 "개인적으로 죄송스럽고 수치스럽다"며 "현재까지 직접적이고 금전적 피해는 없고 고객 피해를 파악하는데 모든 역량을 집중하고 있다"고 사과했다. 또 "지금은 사태 전모를 확실히 아는 것이 중요하다고 생각한다"며 "책임질 일이 있으면 책임지겠다"고 강조했다.

캐피탈업계에선 1위업체인 현대캐피탈이 해킹당했다는 사실이 알려지자 긴장하는 분위기다. 한 캐피탈사 관계자는 "현대캐피탈이 당할 정도면 다른 캐피탈사도 안전할 수 없다"고 우려를 표명했다.

현대캐피탈 신용정보도 유출..`최악의 해킹사고`(종합)

2011/04/10 19:26:47 이데일리


=========================================================================================

최근 주로 발생되는 DDOS 공격은 단순히 공객 대상이 되는 업체의 일부 서버가 서비스를 수행하지 못하도록 비정상적인 과도한 트래픽을 유발시키는 해킹기업이다. 따라서 개인정보 혹은 기타 공공 및 기업의 기밀에 해당되는 정보 유출은 없다.

또한 과거 발생했던 GS칼텍스 등에서 발생했던 대량의 고객정보 유출은 외부에서의 해킹이 아닌 내부자가 연관되어 발생된 "내부 보안 사고"의 성격이 강했다.

하지만 과거 옥션의 개인정보 유출과 이번 현대캐피탈 고객정보 및 금융정보 해킹사건은 내부자가 아닌 외부자가 인터넷을 통해 내부 시스템에 침입한 완벽한(?) 해킹으로 인해 발생한 보안사고이기 때문에 그 심각성은 다른 보안사고와는 차원이 다른 수준이다.


현대캐피탈의 내부통제 수준

몇차례 현대캐피탈의 IT 부서에 방문하여 업무협의와 PT, Demo 등을 진행한 경험이 있다. 공교롭게도 현대캐피탈에서 해킹이 발생했다고 공개한 날짜와 비슷한 시기였다. 결국 담당자가 선호하는 외산 SecureOS를 도입하는 것으로 결정이 되었다는 안타까운(?) 소식을 접하긴 했지만 그 과정에서 경험한  현대캐피탈의 내부통제 시스템은 듣던대로 비교적 잘 갖추어져 있고 적용도 잘되어 있는 듯 했다. 또한 필요한 네트워크 보안 시스템 즉, 방화벽, IPS 등도 운영중이었다.


문제는 서버 및 애플리케이션 보안

이번 해킹사고는 완벽할 것이라고 믿는 네트워크 보안시스템의 한계를 잘 드러낸 사건이다. 방화벽, IPS 그리고 클라이언트와 서버간의 통신 암호화로 대변되는 네트워크 보안이 결코 시스템을 해킹으로부터 완벽하게 보호해줄 수 없다는 일반적인 상식(?)을 증명해준 해킹사건이다.

과거 해커들은 시스템의 취약점을 데이터의 이동 통로인 네트워크서 찾는 경향이 있었지만 최근에는서 서버에서 데이터를 관리하는 애플리케이션에서 찾는 경향이 두드러지게 나타나고 있다. 특히 이번 해킹사건에서 보듯 인터넷에 공개되어 있는 웹서버는 해커들의 주요 공격대상이 되고 있다.

해커들은 집요하게 웹서버를 공격하려 취약성을 찾는다. 이 취약성의 대부분은 웹서버에서 구동되는 서버사이드스크립트인 JSP(Java Server Page) 및 서블릿이 갖고 있게 된다. 결국 웹 응용프로그램 개발자의 보안 수준에 따라 취약성이 많은 시스템을 개발하느냐 아니면 취약성이 거의 없는 시스템을 개발하느냐가 결정되어 진다.



또한 취약성이 발견되어 해커가 해당 취약성을 공격하였을 때 해커가 얻게되는 최초의 서버 접근권한을 운영체제 차원에서 제대로 통제하느냐에 따라 해킹의 성공여부가 판가름 난다. 만약 운영체제 차원에서 적절한 통제를 수행하지 못한다면 해커는 해당 시스템을 장악할 수 있는 발판을 마련하게되고 그때부터 시스템은 해커의 공격에 무방비 상태로 노출되는 것이다. (네트워크 보안 시스템으로는 통제하기 어려움)

해커가 취약성에 대한 공격으로 서버 접근 권한을 얻게 되면 그때부터 원격지에서 서버에 존재하는 수많은 파일을 뒤져 자기가 원하는 추가적인 정보를 얻을 수도 있다. 이때부터 주요 정보의 유출은 시간문제가 된다. 운이 좋다면 root의 패스워드 혹은 다른 서버에 관리자 권한으로 접근할 수 있는 계정정보가 하드코딩된 스크립트를 얻을 수도 있을 것이다.

현대캐피탈의 해킹은 지금까지 설명한 과정을 거쳐 이루어졌을 것으로 보인다. 이러한 과정은 전형적인 웹서버 해킹의 과정일 뿐이다.


또다른 문제... 서버 감사시스템의 부재

많은 금융사에서 고객의 계좌정보를 메인프레임에서 Unix 서버로 다운사이징하여 운영하고 있다. 그리고 계좌정보의 일부가 서비스의 성능을 높이기 위해 기간계 서버에서 각기 다른 Unix 및 Windows 서비스 시스템으로 (예를 들면 이번 해킹사고가 발생한 프라임론 시스템) 분산되어 저장된다.

하지만 Unix 나 Windows 모두 보안에 취약한 운영체제다. 외부로 부터 침입한 해커든, 내부자이든, 아니면 기술지원을 나온 외부의 엔지니어든 서버에 접근하여 무엇을 하는지 통제하고 감사기록을 남길 수 있는 솔루션을 운영체제 자체적으로 제공해주지 않는다.

사실 이번 해킹의 경우도 정확하게 어떤 정보가 유출되었는지 확실치 않다. 또한 해커가 어떤 백도어를 숨겨두었는지 찾아낼 방법도 없다. 아니면 해킹당했다는 프라임론 시스템외에 같은 네트워크내에 있는 다른 어떤 서버가 또 해킹을 당했는지 확인할 완벽한 방법이 없다. 확인할 수 있는 것은 외부의 어떤 IP에서 접근했는지와 다른 서버로 Telnet, FTP, rlogin 같은 단순한 방법으로 로그온을 시도했는지와 그 로그인의 성공여부 정도 뿐이다.

해커가 서버에서 어떤 파일을 열어보았는지, 어떤 명령어를 수행했는지, 어떤 파일을 만들었는지와 같은 구체적인 활동정보는 어디에도 기록되어 있지 않을 것이다. 보안사고 및 침해행위를 감사할 수 있는 기능을 제공하는 솔루션은 현재로서는 SecureOS를 이용하여 감사정책을 적용하는 것이 최선의 방법이나 현대캐피탈에는 아직 적용되어 있지 않은 듯 하다.


= 서버 보안의 강화가 필요한 시점

많은 공공기관과 금융기관 그리고 일반 기업체에서 SecureOS 를 도입하고도 제대로 활용하지 못하는 경우가 많다. 네트워크 보안과는 달리 서버 운영체제, 네트워크, 시스템소프트웨어, 웹응용프로그램에 대한 지식을 비롯한 다양한 경험과 지식을 필요로 하는 것이 바로 SecureOS 제품이다.

하지만 국내의 엔지니어에 대한 정서(?)상 그렇게 다양하고 풍부한 경험과 지식을 갖춘 엔지니어를 찾기는 어렵다. 기술자를 경시하는 풍조가 IT 업계에도 만연되어 있어 엔지니어가 오랫동안 다양한 분야에서 경험과 지식을 쌓기란  무척 어렵기 때문이다. 그리고 그러한 이유에서 제대로 서버보안S/W(SecureOS)를 운영할만한 엔지니어를 찾기란 쉽지 않다.

하지만 주요 데이터가 보관되고 서비스되는 서버의 보안을 서버 내부가 아닌 서버 외부의 네트워크 보안 시스템에게 맞기는 것은 사람이 오리털 파카를 입고 있으면서 그 속에는 홀라당~~ 벗고 있는 것과 크게 다를 바가 없다.

서버와 애플리케이션 보안의 강화....
그것만이 보안이 취약한 Unix/Linux/Windows 서버의 해킹을 막을 수 있는 유일한 해결책이다.


지금 (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 공격이 난무하는 어느날... ===