2012년 2월 24일 금요일

이길환 정보보호소장의 새로운 이론과 반론

 이길환 정보보호소장님이 장문의 기술적 글을 올리셨습니다. 처음부터 이렇게 하셨으면 얼마나 좋았을까 하는 생각을 해봅니다. 그러면 기술적인 반론을 제시해 드리며 기술적 논의임으로 존칭은 생략함을 양해해 주시기 바랍니다. 검정 글씨가 이길환씨의 주장 입니다. [트윗에 올린 주장 바로가기]






#닥치코패쓰 한글 읽을 줄 알면보세요 ㅡ
 이 부분은 누가 보아도 이길환씨의 기술적 이야기를 반대하면 나꼼수빠로 일반화 시킬 수 있는 논리적 오류입니다. 한나라당을 반대하면 민주당으로 보는 시각과 크게 다르진 않습니다.




특정 페이지만 열리지 않는 것이 DDoS 공격인가?
(1)결론부터 말씀드리면 DDoS 공격이 맞다.
 DDoS 공격은 존재했습니다. 제 의견은 "DDoS공격에 따른 증상이 아니다" 이고 이길환씨의 주장은 "DDoS공격에 의한 증상이 맞다" 입니다.




(2)DDoS 전문가인 제 견해는 정확히 L7 보안장비인 웹방화벽의 자동 필터기능의 약점을 이용한 공격이다.
 기본적 개념에서 L7 Application Gateway Firewall 은 L7 스위치 까지 도달한 정보를 모두 조회하는 방식이며, 웹방화벽은 80,443,20,21 Port 로 들어오는 정보를 조회하여 분석/차단 하는 방식입니다. L7은 OSI Layer-7 를 간단하게 이야기한 것이라 생각 됩니다. 자동 필터기능의 약점 이라는 부분은 Positive Security Model 에 있는 자동학습 기능에 대한 약점을 이야기 하는 것으로 보입니다.



(3)좀비 PC가 선관위 웹페이지에 정상적으로 접속을 하고 투표소 위치에 요청에 대해 반복적으로 수백 수천 건의 정보요청 보내면
(4)웹방화벽에 설정된 반복 쿼리에 대한 필터가 자동으로 만들어지고 WAS와 DB서버의 부하를 줄이기 위해 같은 형식의 쿼리 요청 차단하게 된다.

 이길환씨와 미팅이 있던 날 이길환씨의 주장인 "페이지 디도스는 일반인의 이해를 위해 사용한 용어이고 정확히는 UDT CC"다 라는 의견보다는 진보된 의견으로 보입니다. UDT CC는 UDP based application layer Data Transfer protocol 을 통한 Cache Control 방식의 공격을 의미 하는데 HTTP Request가 아닌 Cache Control 공격이 어떻게 이루어질 수 있는지 상상이 가지 않습니다. 제가 모르는 공격 방식일 수 있음으로 검색을 시도하여 보았으나 검색 결과가 없는 것으로 보아 아직 정식으로 보고된 바는 없습니다.


 웹 방화벽은 웹서버 앞단에서 Network Packet 을 조회하는 Hardware방식과 Web Service Application 으로 부터 Header와 Data Stream을 받아서 조회하는 Software 방식이 있습니다. "공격이 웹페이지에 정상적으로 접속을 했다" 라는 전제가 필요한 것으로 보아 Software 방식의 웹방화벽을 이야기 하는 듯 합니다.

 웹방화벽의 동작은 안전하다 여겨지는 것을 제외한 모든 트래픽을 차단하는 PSM(Positive Security Model) 과 위험하다고 정의되는 트래픽만을 차단하는 NSM(Negative Security Model) 두가지 모델이 있으며 요즘은 두가지 모델을 동시에 적용하는 제품이 주를 이룹니다. 


 앞서 이길환씨가 주장한 자동필터링(자동학습기능)은 PSM의 기능 중 하나입니다. 공격방식과 공격자 IP에 대하여 Reputation Based 방식으로 주변의 웹 방화벽과의 교류를 통한 자동학습을 이야기 하는 것이지 Query를 검증하는 기능이 아닙니다. 


 가장 큰 논리적 오류는 Query란 Web Service Application(Apache, webtoB 등)을 거쳐 Java Servlet Container(WAS포함),ASP,PHP 등의 Framework에 전달된 정확한 Data를 기반으로 Framework 가 DB에 요청하는 요청문이지 Web Service Application 단에있는 웹방화벽이 검증할 부분이 아라는 것 입니다. 또한 SQL Injection은 웹방화벽에서 차단되지만 정상적인 사용자는 Network packet 안에 Injection요소를 가지고 있지 않음으로 공격과 확연히 구별되며 차단될 여지가 전혀 없습니다.


 결론적으로 반복적인 쿼리 요청에 의한 WAS와 DB의 부하를 막기위해 웹방화벽이 쿼리를 차단한다는 이길환씨의 주장은 선후관계 및 인과관계가 뒤바뀐 오류이며 어떠한 기술적, 논리적 근거도 찾을 수 없습니다.



(5)그 결과, 검색 결과 페이지를 요청하는 정보가 WAS에 도달하지 않아 투표소 결과 페이지를 제공하지 못하는 것이다.

 ?!




(6)DDoS는 분산 서비스 거부 공격을 통칭하는 용어이다.현재 미국 NIST에서는 DDoS의 분류를 소모성(Attrition)공격으로 분류한다.*< Attrition*: An attack that employs brute force methods to compromise, degrade, or destroy systems, networks, or services (e.g., a DDoS intended to impair or deny access to a service or application; a brute force attack against an authentication mechanism, such as passwords, captchas, or digital signatures).
(7)DDoS의 공격은 서버 마비 뿐만 아니라, 시스템 가용성에 대한 전반적인 부분을 다루고 있다.
(8)실제 DDoS 방어를 해본 사람이면, 이러한 문제가 쟁점화 되지 않는다. 왜냐하면,
(9)DDoS 공격자 입장에서는 가장 적은 노력으로 가장 큰 효과를 내려고 한다. 그리고 공격 중에 DDoS 방어에 따라 시시각각 공격의 양상을 바꾸어서 소기의 목적을 달성한다.
(10)DDoS 방어자 입장에서는 보안장비간의 설정충돌(이율배반)상태가 계속 발생할 수 밖에 없다. 공격의 양상에 따라서 계속적으로 방어 설정을 바꾸어야만 한다. DDoS 공격의 특징이 그러하다. 정상 사용자와 좀비의 공격을 구별할 방법을 기술적으로는 개별 개체가 과도한가 아닌가를 판단 할 수 밖에 없으며 과도하다는 정도를 주관적으로 판단해야 할 경우가 많이 발생한다.
(11)일반인이 생각할때, DDoS 장비가 있으니 DDoS를 방어하고, 침입차단 장비가 있으니 해킹이 방지되고, 웹방화벽이 있으니 웹은 안전하다고 판단 할 것이나, 이런식으로 말하는 자체가 보안의 기초만 알고 실제 보안 세계를 알지 못하는 사람들의 발상이다.


 위 내용들은 지식자랑 과 몇가지 소소한 오류를 제외하면 보안 전문가로서 충분히 이야기 할 수 있는 내용임으로 굳이 반론을 달지 않겠습니다.








 마지막으로 이길환씨에게 드리고 싶은 말은, 미팅이 있던 날 저는 기술검증을 위해 그자리에 간 것이지 이길환씨의 강의를 듣기위해 간 학생이 아니었다는 점, 그러므로 자세에 대해 기분이 나빴다는 것에 대하여 인간적으로 사과한것 뿐이지 결코 기술적 사과가 아니었다는 점, 그리고 저의 기술적 논지는 확고하며 이길환씨의 정치적 방향성은 기술적 논지에서 제외된다는 점 입니다. 


 방송을 통해 페이지 디도스가 가능하다는 주장을 하고 이러한 비논리적 이야기를 용어의 현란함을 이용하여 비종사자들로 하여금 비판없이 수용하도록 한 부분에 대해서는 책임감을 느끼실 수 있기를 바라며 조금 더 전문가적인 접근을 기대해 봅니다.



댓글 17개:

  1. 한 벤쳐에서 서버관리와 웹 개발을 동시에 하고 있는 개발자입니다.

    이길환씨의 주장이 확실히 이해되지 않는 부분이 있는데요. 제가 지금까지 써왔던 어떤 L7 방화벽도 프레임워크에서 DB서버로 전달하는 패킷에 대해 검증을 실시하지 않습니다. 실제로는 이러한 검증이 이루어지고 있는데 제가 알고 있지 못한 것인지 궁금하네요. 참고로 제가 운영하고 있는 서버에서 L7 방화벽은 인바운드/아웃바운드 포트 관리에만 관여하고, DB서버로의 접근은 당연히 풀어놓았기 때문에 전혀 제한없이 통신을 하고 있습니다.

    한가지 또 의문점은, 설사 이길환씨의 주장대로 L7 방화벽의 쿼리필터라는게 존재하고 DDoS 공격을 통해 쿼리필터가 자동으로 생성되게 하려면 선관위의 웹서비스가 DB캐시, 페이지캐시를 둘다 사용하지 않았다는 가정이 필요하지 않나요? 그런데 저 정도 규모의 웹서버를 구축하면서 둘다를 사용하지 않았다는건 도저히 이해할 수 없는 일이네요. DB캐시든 페이지캐시든 둘중 하나만 동작했더라도 동일 쿼리에 대한 재요청이 이루어지지 않았을 것이고, 그랬다면 쿼리 필터가 생길 일도 없었겠으니 말입니다.

    답글삭제
    답글
    1. 1인개발자의 무한 능력을 공감합니다.
      무한 피로도 동반하지만요... OTL

      삭제
    2. WAS 서버와 DB서버 간의 통신을 막았다는 내용이 없는데.. 본문을 이해하지 못하고 의문을 제기하는 군요. 다시 읽어보세요... 그냥 지나가려다 질문같지 않은 질문라 지적하고 가는 사람

      삭제
    3. +__+??????????????????????????????????????????????????????? 뭐징? ㅎㅎㅎ

      삭제
    4. 익명//

      이길환씨 본문에 L7 웹방화벽의 자동 필터링 기능이 반복되는 쿼리를 제한했다는 내용이 존재합니다. 웹방화벽이 WAS 와 DB 서버 사이의 통신을 중재하지 않는다면(다시 말해 둘 사이 통신에 필터링이 걸리지 않는다면) 성립할 수 없는 주장이 아닌가요? 말씀하시는대로 웹방화벽의 필터가 WAS 윗단에 걸려있어서 '쿼리'가 아니라 '리퀘스트'만을 필터링한다면 내부 DB쿼리가 어떻게 생겨먹은줄 알고 필터링을 하나요? 누가 질문의 요지를 이해하지 못하고 반론을 오해하는지 다시 한번 생각해주셨으면 좋겠군요.

      이길환씨 주장에 있는 '쿼리'라는 단어가 오해를 불러일으키고 있는것 같은데, 비전문가와의 대화도 아니고 기술적인 반론에서 '쿼리'라는 단어를 사용했다면 보다 기술적으로 일반적인 용어 정의로 받아들일 수 밖에 없습니다. 사용자가 정보 요청을 하는 것은 일반적으로 'request'라고 하지 'query'라고 쓰지 않습니다.

      삭제
    5. 익명//

      그리고 한가지 더.
      설사 이길환씨 주장의 쿼리라는 단어가 리퀘스트의 의미를 포괄하는 것이라 하더라도 제가 두번째 단락에서 제기한 부분은 여전히 유효합니다. 페이지 캐시, DB 캐시가 올바르게 구성되어 있었다면 DDoS 로 인해 WAS 가 죽기 직전까지 몰리더라도 DB 서버는 훨씬 가용성 있게 동작했을겁니다.

      그런데 보면 볼수록 이길환씨의 주장이 좀 어이없네요; 애초부터 DDoS 공격이란게 지속적인 리퀘스트로 웹서버의 커넥션풀을 오버플로우 시키는 건데, 커넥션풀도 넘어가기 전에 웹방화벽이 동작해서 중간에 전부를 필터링시킨다면, DDoS 가 한결 쉬워지고 좋겠군요.

      삭제
  2. "웹방화벽에 설정된 반복 쿼리에 대한 필터가 자동으로 만들어지고 WAS와 DB서버의 부하를 줄이기 위해 같은 형식의 쿼리 요청 차단하게 된다".....

    이분... 뭐 보안 전문가? 어떻게 웹방화벽이 쿼리에 대한 필터링을 한다는 거지? 요즘은 클라이언트에서 서버로 쿼리를 날리나? 저기요. 자칭 보안 전문가분? 클라이언트에선 폼값만 날리거든요. 방화벽 지나서 웹서버에 들어간 후에야 서버가 직접 쿼리를 만드는 거에요. 그리고 정해진 폼값을 주고 받기 때문에 즉 모든 요청은 다 동일한 형식입니다.
    결국 주장의 요지는 투표소검색요청을 좀비로 죽어라 날리면 웹방화벽에서 동일한 형태의 모든 투표소검색요청은 필터링해버리니 투표소검색만 않되게 된다.
    많이 발전했네요. 해비 쿼리를 죽어라 날리면 웹서버는 놔두고 DB에 부하를 걸어서 DB만 죽일수 있다고 하는 이론에 비하면 방화벽 장비 내지 소프트의 오동작을 유도할수 있다는 건데...
    그래도 아직 허술해... 보안 전문가가 한다는 소리가 이정도니 툴사용법 한달 배운 중국 공장 해커한테 툭하면 뚤리는 거겠죠.
    보안은 쥐뿔도 모르고 네트워크 장비는 말로만 들어본 웹프로그램으로 밥먹고 사는 사람으로 도대체 이해가 않되는 하드 세계네요. 소프트 세계에선 그렇게 코딩하면 바로 짤리거든요.

    답글삭제
    답글
    1. ㅋㅋ... 폼값에 쿼리가 들어있다고 생각하나 보죠..뭐...

      삭제
    2. POST hidden이라 우길지도 ... ㅎㅎ

      그런데 성토성 글은 여기에 다셔도 이길환씨가 보지는 못할겁니다.

      삭제
    3. 이길환 소장의 새로운 이론 원문을 보니 논리적 기술적으로 틀린점이 없는데... 여기 반론은 단어하나하나를 가지고 이야기 하는 군요. 쿼리라는 사용자가 WAS서버에게 정보를 요청하는 질문 전체를 말하는 것으로 맞는 말인데, 쿼리라는 것이 씨퀄서버에서 쓰는 좁은 의미를 가지고 이야기하는 것은 반론을 위한 반론으로 보입니다. 건설적으로 반론하세요. 이건 뭐 기술가지고 혹세무민하는 작당도 아니고 나원 참.... 그냥 지나가려다 질문 같지 않은 질문이라 지적하고 가는 사람

      삭제
    4. 이길환 소장의 새로운 이론 원문을 보니 논리적 기술적으로 틀린점이 없는데...

      <-- 장문 댓글로 증명 하셔도 됩니다.

      여기 반론은 단어하나하나를 가지고 이야기 하는 군요.

      <-- 그렇게 보이시나요? 자세히 읽어보세요 문맥이 어렵지는 않습니다.

      쿼리라는 사용자가 WAS서버에게 정보를 요청하는 질문 전체를 말하는 것으로 맞는 말인데, 쿼리라는 것이 씨퀄서버에서 쓰는 좁은 의미를 가지고 이야기하는 것은 반론을 위한 반론으로 보입니다.

      <-- 사용자가 WAS 에 정보를 요청해요? 그런것을 쿼리라고 한다구요? 리퀘스트는 그럼 뭔가요?

      건설적으로 반론하세요. 이건 뭐 기술가지고 혹세무민하는 작당도 아니고 나원 참.... 그냥 지나가려다 질문 같지 않은 질문이라 지적하고 가는 사람

      <-- 댓글마다 질문같지도 않은 질문을 같은 어조로 하시는 모습이 꼭 누구를 보는 것 같습니다.

      삭제
    5. query

      (n.) A request for information from a database. There are three general methods for posing queries:
      Choosing parameters from a menu: In this method, the database system presents a list of parameters from which you can choose. This is perhaps the easiest way to pose a query because the menus guide you, but it is also the least flexible.
      Query by example (QBE): In this method, the system presents a blank record and lets you specify the fields and values that define the query.
      Query language: Many database systems require you to make requests for information in the form of a stylized query that must be written in a special query language. This is the most complex method because it forces you to learn a specialized language, but it is also the most powerful.
      (v.) To make a request for information from a database.

      옛다 떡밥! 씨퀄서버에서 쓰는 좁은의미? ㅎㅎㅎㅎㅎ

      삭제
  3. 아..계속지켜보겠습니다..이길환님

    답글삭제
  4. 여기 반론은 단어 하나 하나를 가지고 이야기했다기 보다는 한개 이상의 문장을 가지고 반론했습니다. 단어 하나 하나를 정확히 쓰는 것도 중요합니다. 용어 통일 안되면 토론이 진행될 수가 없어요.

    답글삭제
  5. 이길환이는 . . 정신세계가 다른 나라 사람..

    답글삭제
  6. 논쟁에 있어서 자연과학이 좋은 이유는 식(이론)을 대입해서 풀면 답이 나옵니다. 그 풀이 과정은 사람마다 다 다르겠지만요.
    그런데...인문학은(형이상학적 논쟁)은 누구의 이론과 논리전개가 완벽하냐에 따라 달라지는 것 같습니다.
    (고등학교에서 이과 공부를 하고 인문학을 공부한 한 사람으로서의 경험입니다.)

    컴퓨터는 이론이 아니라고 생각합니다. 입력(Input)에 의한 결과(Output)은 절대로 거짓말을 하지 않는다고 생각합니다. 결과를 속이거나 속일 수 있다면 그것은 제대로 된 시스템이나 입력(Input)이 아니라고 생각합니다.

    시스템 장애가 발생한 후 사후처리 과정에서 원인분석은 항상 다양한 가능성을 열어 놓고 네트워크, 서버, OS, 응용프로그램의 로그 하나하나를 역추적하여 분석하여야만 제대로 된 결과값을 얻을 수 있습니다.

    결과를 정해 놓고 분석하는 것은 억지춘향이 될 확률이 100%라고 생각합니다.
    (다들 경험 많으시리라 생각합니다. 시스템 장애의 80% 이상이 인적장애라는 것은 이미 밝혀진 사실이기도 하고요.)

    좋은 글 잘 읽었습니다. 역시 열려 있는 공간이라 많은 의견들을 다양하게 듣고 생각하는 과정이 참 좋은 것 같습니다. 저도 나름 공개된 자료들을 보면서 많은 가능성을 열어 놓고 분석해 보고 있습니다. 고맙습니다. 잘 읽었습니다.

    답글삭제
  7. 음... 8년차 개발자입니다. 아무리 혁신적인 기술을 생각해봐도 저 사람의 말을 이해하기가 힘드네요...
    '쿼리'라는 단어를 'DML Query'의미로 생각해보고 'Http Request'로 생각해봐도 둘다 DB만 죽이기엔 역부족입니다.
    전자의 경우는 미친 개발입니다. DB에 직접 작용할 Query 구문을 Form에다 집어넣고 request로 쏴서 그걸 웹서버에서 필터링한다면..... 그건 '정보보호연구소'가 '정보유출연구소'로 간판을 바꿔달아야 될 말이죠... 그래서 혹시나 보안을 걱정해 XFlatform 환경으로 클라이언트에 암호화 모듈을 적용시켜서 직접 쿼리구문을 날릴까... 했는데 선관위페이지는 그냥 일반 JAVA-JSP환경인거 같더군요... ActiveX 설치를 하는 것도 아니고, 그래서 후자의 의미도 생각해봤는데 그럴경우 DB가 죽기전에 웹서버가 죽을 맛이겠다는 생각이 먼저듭니다. 그럼 모든걸 양보하고 페이지리로드가 없이 Ajax방식으로 XML문서로 통신을 했을 경우를 생각해봤는데... 그것 역시 Conection Pool과의 싸움이 되기에 WAS가 먼저 죽을 맛이 겠네요... Connection Pool이 아닌 단일 연결이라는 미친 상상은 안하겠습니다.
    더군다나... 개발자가 유지보수 할때마다 그 필터링 장비에 접근해서 손을 봐야 되는 문제도 존재할꺼 같은데 장비도 알고 JAVA개발도 할 줄 아는 아주 고급개발인력이 있어야 겠다는 생각도 들구요. 그나저나 그런 장비가 있습니까? 있다손치더라도 팔리기나 합니까?

    답글삭제