태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

DDoS (6)


서버보안의 일을 하다 보면 주로 서버에 로그온 하는 자연인(부서/직급/이름으로 식별가능한 실제 사람과 서버에 접속할 때 입력하는 계정(ID) 그리고 로그온한 세션에서 실행한 명령어(Command)와 해당 명령어(Command)가 접근한 파일 그리고 파일에 접근할 때의 권한(읽기/생성/수정/삭제/실행) 관계를 다루는 일을 하게 된다.


때문에 주로 서버관리자, 개발자, 응용프로그램 운영자 및 외부 인력의 서버 내에서의 작업을 어떻게 통제하고 작업 및 행위에 대한 감사기록을 어떻게 남길 것인가에 대한 컨설팅을 하게 된다. 그리고 그러한 서버에 대한 접근통제와 파일 및 명령어에 대한 접근/실행의 통제 그리고 감사 증적자료의 확보는 대부분 개인정보보호법이나 정보통신망 이용촉진 및 개인정보보호에 관한 법률, 그리고 금융기관의 경우 금융감독원의 규정에 대한 컴플라이언스 기준으로 이루어진다.


사실 이런 관리적 보안에 대한 업무는 운영체제와 데이터베이스 그리고 몇몇 시스템 소프트웨어에 대한 지식과 전체적인 시스템을 어떻게 구축하고 개발하고 운영하는지에 대한 노하우만 있다면 이를 바탕으로 위험관리 절차에 따라 정책을 수립하고 서버보안SW를 통해 구현하면 된다. 

이 일을 하기 위해서는 깊은 지식보다는 넓은 지식이 필요하고 프로젝트 및 시스템 운영에 투입된 엔지니어, 관리자, 운영자, 개발자, 오퍼레이터와의 커뮤니케이션 능력이 더 중요하다고 할 수 있다. 그리고 다양한 분야의 기술자 들을 아우르기 위한 충분한 경험은 더욱 중요한게 사실이다.


하지만 DOS 및 DDOS 그리고 웹해킹 및 APT 공격에 의한 서버에 대한 공격의 방어는 조금 이야기가 달라진다. 물리적인 네트워크 구성과 OSI 7 Layer 중 2,3,4,5 계층(TCP/IP)에 대한 심도 있는 이해와 운영체제 측면에서의 프로그래밍에 대한 지식 그리고 애플리케이션서버에 대한 지식이 필요하다. 그 중에서도 DOS 및 DDOS 공격의 급격한 트렌드의 변화는 특정 애플리케이션의 프로토콜에 대한 정확한 이해가 필요하다.


예전의 DOS와 DDOS 공격은 주로 TCP/IP 프로토콜의 취약성을 공격하는 형태가 주를 이루었다. ICMP 프로토콜의 취약성을 공격하는 SMURF 공격, Ping of Death 공격이 그랬고 UDP의 취약성을 공격하는 Tear Drop 공격 그리고 TCP의 3-way handshake 취약성을 파고드는 Syn Flooding도 TCP/IP의 취약성을 공격하는 대표적인 사례였다. 그 외에도 무수히 많은 TCP/IP 취약성 공격이 있으나 현재는 대부분 네트워크 장비의 설정을 변경하는 것으로도 충분히 방어가 가능하게 되었다.


그래서 해커들은 더 이상 TCP/IP 프로토콜에서만 취약성을 찾고 있지는 않다. TCP/IP에서 벗어나 보다 더 상위레이어(L7)에서 취약성을 찾기 시작했고 가장 대표적인 애플리케이션 레이어의 프로토콜인 HTTP 프로토콜의 취약성을 공격하기 시작했다.



대표적인 HTTP의 취약성을 악용하는 DOS/DDOS 공격은 다음과 같은 것들이 있다.


● HTTP Get Flooding

● Slow HTTP Post Attack

● Slow HTTP Header Attack

● Slow HTTP Read Attack


이러한 공격들은 주로 HTTP 프로토콜을 통해 클라이언트의 Request 와 그 Request를 처리하는 웹서버 사이의 통신 세션의 수에 제약이 있다는 점을 이용해 해당 세션의 처리를 지연시킴으로써 웹서버가 더 이상 클라이언트의 Request를 받아들이지 못하도록 하는 공격을 수행하는 것이다.


이 공격에 대한 자세한 원리와 분석방법 그리고 대응 방안을 명시한 KISA(한국인터넷진흥원)의 자료(2012년)를 첨부한다. 그 양이 꽤 많고 심도있게 이해해야하기 때문에 포스트에 모든 것을 쓰기는 좀.... 어렵다. 두고 두고 꾸준히 읽어봐야할 자료인 듯 하다.


KISA_DDoS공격대응 가이드.pdf




결론부터 말하자면 "끊임없이 다시 발생한다" 이다.

엊그제 발생한 대대적인 DDOS 공격... 아니나 다를까 또 백신타령이다. 역시나 좀비PC가 된 불특정 다수의 죄없는 일반인들이 해커 대접(?)을 받고 있다. 그나마 이번엔 좀비PC를 양산(?)한 중간 감염 사이트가 운좋게 밝혀졌다.

인터넷 다운로드 사이트인 쉐어박스와 수퍼다운이 해킹되어 이 두 사이트에 접근한 사용자들의 PC에 공격도구를 감염시켰다고 한다.


이전의 국가적인 DDOS 공격이 있었을 때도 분명 이렇게 매개체가 되는 웹사이트가 무척 많았을 것이다. 이번 공격에도 어쩌면 더 많은 웹사이트가 해킹되어 더 많은 PC를 좀비PC로 만들었을 지도 모른다. 다만 밝혀진 웹사이트가 2곳일 뿐일지도 모른다.

이제는 더이상은 많은 피해자(좀비PC의주인들)를에게 주의의 의무만을 지우지 않았으면 한다.

공공의 서비스를 위해 그리고 돈을 벌기 위해 운용중인 수 많은 보안에 취약한 웹서버에 소스위변조 차단을 위해 서버보안 S/W 혹은 위변조 모니터링 솔루션, 홈페이지 위변조 차단 솔루션 등의 설치를 의무화할 필요가 있다고 본다. 대부분의 기업과 공공기관의 PC에 백신설치는 의무화되다시피 했다. 또한 방화벽과 IPS도 거의 의무적으로 도입되다시피 했다. 그럼에도 불구하고 이러한 네트워크 기반의 보안솔루션으로는 홈페이지의 위변조를 차단하지는 못한다. 이제는 서버 내부에서 홈페이지의 보안을 더욱 강화할 필요가 있다.

홈페이지 위변조를 통해 발생하는 해킹의 피해는 이번 DDOS 공격 사건에서 보듯 심각한 수준이다. 더 이상 지체할 수 없는 상황이라는 것을 하루빨리 인지하면 좋겠다.

DDOS공격을 수행하는 좀비PC는 그냥 생기는 것이 아니다. 좀비PC가 왜 생기는지... 어떤 경로로 정상적인 PC가 좀비PC로 변신(?)하는지을 이해해야 한다.


위의 그림의 (1)과 같이 "보안에 취약한 웹사이트"의 홈페이지 소스를 위/변조하여 악성코드를 직접 심어놓거나 타 사이트에 올려져 있는 악성코드를 다운로드 받는 코드를 삽입한다.

그리고 (2)와 같이 보안에 취약한 PC가 해당 웹사이트에 접근하면 악성코드가 PC에 설치되어 좀비PC가 된다.

일단 좀비PC가 되면 (3)과 같이 공격자(해커)의 명령에 따라 (4)와 같이 DDOS 공격을 수행하게 된다.
하지만 해커가 자신의 IP를 직접 노출해가면서 (3) 처럼 직접 공격하는 경우는 드물다. 해커와 좀비PC사이에는 또하나의 명령서버(Command Server)가 존재하는 경우가 대부분이다. (이 그림에서는 생략되어 있다.)

그렇다면 가장 효과적으로 DDOS 공격을 방어하는 방법은 무엇일까..??
지금까지는 (4)번의 DDOS 공격을 막는데 주력하고 있다. 그래서 DDOS 공격이 시작되면 대한민국 국민에게 사용하는 PC에 백신을 설치하라고 방송을 통해서까지 호소하고있다. 과연 이것이 효과적인 대응인지를 곰곰히 생각해볼 필요가 있다.

일단 (1)의 공격이 성공하면 그 이후에는 DDOS공격이 발생하는 것은 시간문제다. 그리고 어느 PC가 좀비PC인지 식별하는 것도 사실상 불가능하다. 국민전체를 믿고 기다리는 것밖에는 할일이 없는 것이다. 너무도 소극적인 대응이 아닌가 ?

가장 효과적인 방법은 바로 (1)을 차단하는 것이다. 웹사이트를 개발하고 운영하는 이들은 누구인가? 바로 영리목적의 기업이거나 공공기관이다. 웹사이트의 보안을 강화하고 해킹을 차단할 능력이 충분히 있다. 다만 비용과 신속한 개발과 빠른 서비스 시작에 목매어 보안을 등한시하고 있을 뿐이다.

(1)의 공격을 막기위해 보안을 강화해야만 효과적으로 DDOS 공격을 차단할 수 있다.


오늘 갑자기 이상한 메일들이 주루룩~~오기 시작했다. 내 이메일 주소를 여기저기서 잘도 수집했다.

불특정 다수에게 이메일을 보내 백도어나 루트킷..혹은 DDOS 공격을 수행하는 좀비PC로 만드는 툴을 감염시키는 경우는 무척이나 흔하다. 물론 PC에 설치되는 백신이나 대형 포털에서 사용하는 메일월 같은 솔루션으로 감염을 방지할 수 있으나 신종 공격기법은 신속하게 대처하기 힘들다.

공격패턴을 감지하는 기법을 사용하는 네트워크 기반 솔루션들의 한계이고 백신처럼 특정 파일명이나 문자열 패턴을 감지하는 솔루션의 한계이기도 하다.

그렇다면 방법은??

PC의 경우 사용자들의 주의가 가장 중요하다.

오늘 내게 온 메일이 가장 대표적인 예이다.



이따금씩 트위터에서 메일이 오긴 한다. 하지만 이렇게 요상하게 오는 적은 없었다.
메일 본문은 봐도 크게 문제가 발생할 가능성은 없다. 아웃룩도 요즘엔 웬만한 보안 취약성은 패치가 되기 때문이다. 하지만 서비스팩이나 아웃룩 보안 패치가 최신까지 되어 있지 않다면 주의해야한다.

메일 본문을 보면...

음...로고나 다른 것들은 정말 트위터에서 보낸 것처럼 되어 있다. 심지어 Hi~~ 라는 인사 폰트도 트위터에서 오는 메일과 같은 것으로 썻다.
하지만 파란색 링크에 마우스를 살~포~시 올려놓자... 이런...실제 연결된 URL이 트위터사이트가 아니라 전혀 엉뚱한 openexe.~~~로 나온다.

이런 메일은 십중팔구 PC의 정보를 유출시키는 공격도구이거나 시스템관리자 권한을 빼앗을 수 있는 해킹 툴... 혹은 DDOS 공격도구... 또는 원격모니터링 도구일 가능성이 높다.

사실 이러한 공격은 "사회공학적 기법"을 응용하는 공격으로 기술적으로 차단하는 것이 거의 불가능하다. 사용자들이 주의를 기울이는 것 밖에는 확실한 대처방법이 없다.

PC를 사용하는 사람들이 이메일을 보면서 주의해야할 부분이다.




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

 



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

 

서버보안 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이 설치되고 최소한의 보안 정책이 적용되어 있었기 때문이다.