최근 몇년간 침해사고(통칭 사이버테러)가 끊임없이 발생했죠..
아무도 모르는 사건부터, 나라가 뒤흔들릴만한 큰 사고도 간간히 발생하는데요,
오유에 올라오는 글들을 보며 재미도 느끼고 즐거움도 느끼고 많이 배우기도 하지만,
가끔은 옳지 않은 정보가 사실인냥 확산되는게 안타까워 글을 쓰게 되었습니다.
몇가지 사례를 예로 들어 설명 드리겠습니다.
1. 2009년 77 디도스 사건
-네이버 및 29개 사이트 마비
대표적인 서비스 거부 공격이며, 좀비 PC(bot)를 통해 다수의 트래픽을 유발하여,
타겟이 되는 사이트(혹은 서버)의 정상적인 서비스를 중단 시키는 것이 목표입니다.
이때 사용된 공격은 HTTP get Flooding 및 CC 어택이며,
TCP 및 UDP Flagmentation 공격이 동반되었습니다.
서버 및 네트워크 망의 부하를 이용한 공격으로 보안장비의 DID(Defend in Depth) 구성으로
인프라만 갖춰지면, 충분히 사전 방어가 용이합니다.
HTTP get Flooding 과 CC어택은 웹서버 및 WAS가 타겟이며,
특정페이지를 지속적으로 요청(GET)하거나, 특정페이지의 preload cache를 이용한 공격입니다.
대표적인 슬로우 공격이며, 디도스 장비보다는 웹서버 및 WAS 서버의 소스코드 보안을 이용해
방어가 가능하지만, L4급 네트워크 장비에서 로드밸런싱을 통한 부하 분산으로도 어느정도 방어가
가능합니다. 단, 그만큼 인프라가 사전에 구축이 되어야 합니다.
TCP 및 UDP Flagmentation 공격은 가장 기초적인 디도스 유형이며, DDoS 보안장비로
임계치 방어를 하거나, 백본 혹은 라우터에서 ACL로 방어가 가능합니다. 단 손이 많이 갑니다.ㅠㅠ
위의 공격유형은 단순히 서비스 방해를 위한 목적이므로, 정보 유출의 위험은 미미합니다.
2. 2011년 농협 전산망 마비
- 농협전산망
위 공격에서 진화형이며, 사전준비가 많이 필요합니다.
77디도스의 경우 bot만 많이 유포되면 쉽게 할 수 있지만,
농협건의 경우 철저한 사전준비가 필요합니다.
보통 OS나 APP의 취약점이 발견된 후 이를 바탕으로 한 악성코드를 제작 유포하여
원하는 목적지에 설치가 되기 까지 보통 3개월에서 길게 3년까지 준비합니다.
달리 말씀드리면, OS나 APP의 취약점이 보완되는 업데이트가 배포될 경우 다시 변종에 변종에 변종을
지속적으로 업데이트 해줘야 합니다. 웹하드에 자료를 bot이나 악성코드가 첨부된 자료를
올려서 다운받은 PC등을 botnet으로 만드는 툴키드 수준의 해커는 하기 힘든 수준의 공격이었습니다.
공격형태는 사전에 악성코드를 유포하여 감염된 bot pc에 커맨드서버가 bot pc의 키로깅,원격접속등으로 정보를
미리 조사한 후, 공격 목적지가 되는 곳으로 접속하길 기다립니다.
그 후, 원하는 목적지에 접속이 되는 것이 파악되면, 외부에 botnet을 이용하여 목적지에 DDoS 공격을 유발 후,
내부 악성코드는 자동실행 형태의 Script를 실행, 정보 유출 삭제를 시도 하였습니다.
자세한 내용은 위키피디아에 잘 설명이 되어 있더라구요. 아래의 주소를 참고 바랍니다.
http://ko.wikipedia.org/wiki/%EB%86%8D%ED%98%91_%EC%A0%84%EC%82%B0%EB%A7%9D_%EB%A7%88%EB%B9%84_%EC%82%AC%ED%83%9C
위와 같은 공격의 방어방법은.. 없다고 봐야 합니다.
CERT(Computer Emergency Response Team) 담당자가 사고 발생 후 빠른 대응만이 최선책입니다.
왜 못막냐면.. 알려지지 않은 취약점에 대해선 IPS(침입차단장치), TMS(위협관리시스템)등에 시그니쳐나 패턴이
없을 확률이 99.999999% 입니다.
보안관제 인원이 사고 발생후 이상을 발견하고 목적지가 되는, 혹은 피해가 발생할 만한 서버 및 정보에 대해
빠른 망분리 및 차단으로 피해를 최소화 할 수 있는 것이 최선일 뿐이죠. 관제인원은 사고발생 전에는 장비에
입력된 시그니쳐 및 패턴만으로 확인할 수 있는것이 전부입니다.
발견되지 않는 취약점에 대해서는 휴리스틱 탐지 기법(발견되지 않은 이상 패턴에 대한 분석 및 차단)이 있으나,
휴리스틱은 오탐이 너무 많기 때문에, 서비스 가용성에 영향을 주는 경우가 많습니다.
결론은 농협사태는 인재입니다. 사고 발생 자체를 막기는 힘들어도 피해는 최소화 할 수 있으며, 원인으로 지목된
직원의 보안의식 결여입니다.
3. 2013년 320사태
- YTN 등 방송사 및 금융기업
가장 최근이며, 가장 위협적인 형태의 공격입니다.APT(지능적 지속 공격)공격이라고 하는데,
1,2와 다르게 3의 사이버 공격은 내부에서의 서비스 장애를 유도 하였으며, 1,2의 공격을 통해
어느정도 보안시스템의 구조까지(OS나 APP가 아닌 내부 보안장비구성) 파악하여 공격하였습니다.
320사태는 농협사태때 이용된 공격방법과 유사하지만, 한단계 더 진화되어 내부망 1대만 감염되어도
내부망 APC를 이용한 전사 유포가 가능 한점, 최초는 Windows OS만 대상으로 하였으나, 후에는
보안이 강하다고 생각됬던 UNIX계열 서버도 마비된점(YTN)등이 아주 아주 위협적입니다.
또한 별도의 커맨드 서버의 명령을 받아 실행되는게 아닌 악성코드 자체에 입력된 스케쥴에 의해
실행되었다는 분석결과로 봐서, 철저한 망분리 운영이 안된다면, 안전하다고 생각한 내부 인트라넷 망도
충분히 피해를 입을 수 있다는 것을 보여주었습니다.
하지만 이는.. 벌써 2011년에 예측가능한 APT공격의 한 방법이었습니다..
http://ddos.tistory.com/157
제가 이 회사 직원은 아니지만 리오레이 직원분이 어느정도 예측하여 설명을 써 주셨더라구요..
예측이 현실이 된 이 사태가 참으로 슬프지만, 현실은 현실이기에 말씀드리자면..
320 사태도 인재입니다. 예측가능한 사태를 사전에 준비하지 못했기 때문이죠.
2의 농협사태에서 썼듯이 취약점에 대해서 막는 방법은 현재로선 너무 힘들지만,
320 사태는 사전 예측이 되었단 점에서 관리를 못한 APC 서버 운영 보안업체의 책임도 있고,
또한 악성코드 감염이 의심될 수 있는 사이트에 접속한 내부 직원 및 철저한 망 분리 운영을 안한
보안담당자도 책임이 있다고 생각합니다.
이전에 있었던 사이버 테러 사건들을 간략이 요약해 설명 드렸는데,
소잃고 외양간 고치는 것이 아니라, 소 잃기전에 튼튼히 외양간을 지켰으면 하는것과
일부 카더라 언론이 유포하는 기사중에 기술적인 근거없이 유포되는 기사를 보고
사실인줄 오해하시는 오유인이 없었으면 하는 보안엔지니어의 푸념이었습니다..
PS: 위에 일이 있을때마다.. 일하기 너무 힘들었습니다.320 사태후에 국가 비상사태가 어제 등급 하향되어
야간상황근무 풀렸습니다.ㅠ
궁금하신 사항 더 있으시면 덧글로 남겨주심 아는한도내에서 설명 드릴게요..
