[커널] iptables-tng

2009. 6. 30. 16:40 | Posted by 꿈꾸는코난

 

 iptables-TNG ( The Next Generation of iptables)
 
 An environment that can use from different packet 
 classification algorithm (eg. tuple) to support large rulesets (more than 10,000 rules)
 for high bandwidth networks.
 
 Licence: GNU GPLv2
 Author: hamid jafarian (hm.t.) <hamid.jafarian@gmail.com>
 Author: maryam geranian <m.geranian@gmail.com>


 Contents

1. Introduction
2. New Code
3. Some Features
4. Classifiers
    4-1. linear classifier
    4-2. tuple cassifier
    4-3. url classifier
5. TODO list
6. Opportunitis


1. Introduction:

In This version I tried to create the ability of Interactivity beside the ability of using Multiple And Different Classification Algorithms  for every chain. In this version one chain (e.g. OUTPUT in filter) Can Use from "linear Classifier" (like of current version) and other chain (e.g. FORWARD in filter) can use from "tuple".

Implementation of Classification Algorithms Is like of Matches and Targets but they don’t have any User Space implementation (only one (or more) module).

An Important feature in this version is "Ranking". All of the rules base on their locations
(is defined in the "iptables" command when user add a rule) in the list of the rules of a Chain, get a Rank. Thus hashing the rules doesn't create any problem because the algorithm must test the rule with lowest rank from the rules that may match the packet. Thus the users can sit and think; "the rules are stored sequentially and also processed sequentially (like of current version)".

   
2. New Code:
   
In this version I was used "link list"s in the kernel, instead of continues memory (in the current version) for rule storage and also defined many useful and important structures for "Table", "Chain" and....
This code is different completely and also easy to understand absolutely.

New "iptables" command syntax has been not changed. "iptables-save" and "iptables-restore" are adopted.
You can use and develop "matches" and "targets" like before.
   

3. Some Features:

       1. All Chains can get Policy:
          Against the Current Version, the User Chains Like of Built-in Chains can get olicy.

       2. All Chains can be used as Target:
          you can use from every chain to reference to them as a Rule Target. against the 
          current Version that you should use only from User Chains as Target.

       3. All Chains have reference number:
          this define the number of references to the chain (i.e. number of rules that use it
          as Target). At deletion time, this num ber must be zero (if not and you try to
          delete the chain; you will receive an error message from IPtables).

       4. RETURN can be Rule Target:
          like of Current Version, in the called chains (Child Chains: referenced as a target
          in one of the rules of Parent Chain), cause to return to the caller (Parent Chain)
          and In the built chains, the Chain Policy will be used for the matched packet.

       5. RETURN can be Chain Policy:
          Against the Current Version. In the called chains (Child Chains) this cause to
          return to the caller (Parent Chain) but in the Built-in Chains, this means DROP.

       6. You can change Chain Classifier:
          With -C option in the iptables command. for example: iptables -C INPUT tuple.
          You can do this every time. by this option, base on the number of rules in the
          chains;
          you can select best Classification Algorithm for that chain and force it to use that.

       7. pkt_tables namespace and framework
          using pkt_tables namespace and create a common framework for all of the
          *tables.


4. Classifiers

    To now, we developed three classifiers for iptablestng:"linear", "tuple" and "url".

    4-1: linear classifier
          This is not a new approuch in rule search, like before he search rules
          sequentially from first to last.
          this is implemented for compatibility and also is appropriate for chains with few
          rules.

    4-2: tuple classifeir
          this classifier, classifies packets base on their source/destination addresses. He
          uses src/dst ips in the iptables rules to store them in his hash tables. then when
          packets are recived, he retrive the addresses and search the rules that match
          the packet.
          The key note is that: this classifier is appropriate for rules that have source or
          destination IP.

          change classifier to tuple:     # iptables -C INPUT tuple

    4-3: url classifier
          Filter "http" packets base on their domain name may be one of administrators
          interests.
          To now there are many user space applications that can do it. but doing this idea
          in the kernel in a modular and flexible enviornment is new.
          By IPtables-tng we can implement and use new classifiers for special porposes.
          "url classifier" is an special porpose classifier that may be used to filter "http"
          packets base on "HOST" field value in the "http request" packet.

      4-3-1: Use instructions:
          To fiter domain names, after installation of patches(read INSTALL file for more
          info):
              1- first: change the classifier of your chain to the "url":
                   # iptables -C YOUR_CHAIN_NAME url
              2- second: add rules with domain names: e.g. to filter www.xxx.com
                   # iptables -A YOUR_CHAIN_NAME -m url --url www.xxx.com -j DROP
         
         NOTE:
              1- this classifier doesn't support rule deletion (iptables -D).
                  you can use -F to flush the chain.
              2- he only matches "request" packets. target is triggerd on this packets.
              3- he verfies the rule header (source/des IPs & ...) and also other matches to
                  match the packet.
              4- "url" matched is used to tranfer urls to kernel and he dose nothing with
                  packets.
         
      4-3-2: Implementaion notes:
          he uses combination of Boolm Filter & hash tables.
      
5- TODO list

    In progress work is focused on use of RCU for rule managemnt activities (search,
    add, remove) instead of use of spin locks.
    Also the next step will be use of NetLink for user/kernel communication(God Willing).
    Implementation of new way to send classifier data (like urls for url classifier) instead
    of using matches and also new aprouches to retrive data from packets are our goles.

6. Opportunities :

       1. Upgrade IP6tables:
          We can use from this implementation to upgrade ip6tables. The structures and
          functions that is used in this implementation are general.
   
       2. Implement More Classification Algorithms:
          We can implement other Classification Algorithms for iptables e.g. HiCuts.

'컴맹의 컴퓨터 이야기 > 커널' 카테고리의 다른 글

[루팅] 갤탭 루팅하기  (0) 2012.04.19

마이크로 블로그라 불리는 트위터(twitter)가 전 세계적으로 선풍적인 인기를 얻고 있다. 트위터는  작은 블로그라고 볼 수 있다.

 

새의 지저귐이라는 듯의 이 소셜 네트워킹 서비스는 누군가를 따라다니며 정보를 얻고자하는 심리에 근거에 탄생됐다. 누군가의 트위터를 구독하면 그 대상이 업데이트 하는 140바이트 내외 메시지를 문자메시지나 메신저, 이메일 등 다양한 환경에서 받아볼 수 있다. 특히 우리나라에서는 피겨 퀸인 김연아 선수가 트위터를 이용한다 해서 널리 알려지기도 했다. 


샌프란시스코의 한 벤처기업에서 탄생한 이 서비스는, 관심 있는 누군가를 쫓아다니며 더 많은 정보를 알고 싶어 하는 심리와 나에게 관심 있어 하는 다수에게 나를 알리고 싶어하는 심리를 바탕으로 하고 있다. 따라서 많은 유명인들이 트위터를 이용하고 있으며 일반인들도 트위터를 통해 널리 알려지기도 한다. 현재 트위터를 모방한 많은 소셜 네트워킹 서비스가 나타나고 있으며 이런 서비스는 앞으로도 계속 증가할 것으로 예상된다.


문제는 이 서비스가 인기를 얻어갈수록 이를 노리는 많은 보안 위협이 나타나고 있다는 것. 특히 유명인을 노린 보안 위협이 크게 증가하고 있어 문제가 되고 있다. 유명인의 트위터는 많은 이용자들에게 파급효과를 가지고 있어 이를 악용할 경우 큰 사회적인 문제를 낳을 수 있다는 것이다. 가령 얼마 전엔 오바마 대통령의 트위터나 브리트니 스피어스의 트위터도 계정이 해킹당해 큰 사회적 이슈를 낳은 적 있다. (생각해보자. 유명인들의 트위터를 통해 변조된 메시지가 전달된다면... 상상만해도 심각해보인다.)


초기에 트위터를 노린 해킹은 단순 유추형 해킹이었다. 특정인의 계정에 패스워드를 임의로 대입하는 기초적인 해킹이라고 볼 수 있다. 하지만 최근들어 트위터의 프로파일(누군가의 트위터를 구독한 사용자 목록)을 노린 웜이나 이를 통해 변조된 메시지를 전달하는 웜이 기승을 부리고 있다.


이런 웜은 보내지는 메시지를 통해 전파되는 특성도 가지고 있어 그 위협은 점차 커져가고 있다. 특히 트위터가 이동통신이나 여러 통신수단을 이용하고 있기 때문에 향후 스마트폰과 같은 모바일 기기까지 위협이 번질 수 있다는 경고는 많은 보안전문가들 사이에서 늘어가고 있다.


따라서 트위터와 같은 다중 네트워크 소셜네트워킹 서비스를 이용할 경우 각별한 보안 관리가 요구된다. 일단 패스워드 관리가 가장 중요하다. 패스워드가 노출 될 경우 큰 문제가 나타날 수 있기 때문에 패스워드는 수시로 바꿔야 하며 유추가 불가능한 패스워드의 이용이 필수다. 아울러 트위터를 이용하는 환경이 보안 취약점에 노출되지 않았는지도 체크해 봐야한다. 따라서 안티바이러스를 이용한 바이러스 검사나 스파이웨어 검사에도 많은 노력을 기울여야 할 것으로 보인다.

[오병민 기자(boan4@boannews.com)]


http://www.boannews.com/media/view.asp?idx=16767&kind=1

10억 규모 사업, “조달청에 공고 내고 7월 경 사업계약을 맺을 것”


방송통신위원회 주도하에 인터넷망에 DDoS 대응시스템 도입이 확산되고 있는 가운데 행정안전부는 DDoS공격에 우선적으로 대응이 필요한 행안부를 포함한 3개 기관 13개 영역 인터넷 구간에 10억여원 규모로 DDoS 대응시스템을 구축하는 내용을 담은 로드맵을 마련했다.

 

 

행안부는 지난 4월 21일 국가정보원, 지식경제부, 방송통신위원회와 합동으로 정보해킹 및 개인정보 유출 실태와 2009년 역점 추진과제를 국무회의에 보고한 바 있다. 이날 행안부가 발표한 정보보호와 관련한 8개 역점 과제 중에는 최근 급속히 증가하고 있는 DDoS공격에 대한 국가적 대응체계를 구축하기 위해 DDoS 대응시스템을 구축할 것이라는 내용이 담겨 있었다. 그리고 그러한 준비기간을 거쳐 행안부는 이번에 ‘DDoS 대응체계 구축사업’을 벌인다.


최근 전자정부서비스 오류 및 사이버 공격으로 인한 침해사고 발생 등 정부·공공기관에 대한 지속적인 DDoS 공격이 지속적으로 발생하고 있으며, 공격 규모두 수 기가에서 수십 기가로 지속적으로 증가하고 있어 대응체계가 아직 갖추어지지 않아 DDoS공격에 취약했던 것이 사실이다. 이에 따라, 대국민 서비스에 심각한 영향을 미치는 비정상적인 대량의 통신 트래픽을 감지하고, 경보를 발생시키는 시스템을 구축하려는 것이다.


3개 기관 13개 영역에 DDoS 대응체계 구축

이번 ‘DDoS 대응체계 구축사업’은 시·도 및 시군구와 연계된 4대 접점 구역에 DDoS 전용장비를 설치하고 교육과학기술부와 보건복지부의 대민서비스를 위한 인터넷 접점 중 각각 5개, 4개 영역에 설치된다.


여기서 4대 접점구간 별 DDoS 대응지역은 ▲중앙청사-경북도청 및 외부기관 중앙부처 ▲별관청사-서울·인천시청 및 강원·경기·충북도청 ▲과천청사-부산·대구·울산시청 및 경남도청 ▲대전청사-대전·광주시청 및 전북·전남·제주·충남도청이다.


이에 행안부 관계자는 “중앙행정기관 대민서비스에 대한 보안관제를 지원하는 ‘교육 관제시설’과 ‘보건·의료 관제시설’에 우선 시범적용된다”며 “시·도 및 시군구와 연계된 4대 접점 구역에 DDoS 대응체계를 구축해 행안부의 통합보안관제센터 및 지역정보개발원의 보안관제센터와 정보공유를 통해 DDoS공격을 사전에 차단할 것”이라고 밝혔다.


또한 그는 “구축된 시스템의 서비스거부 대응 효과 검증을 위한 모의 훈련을 실시하고 기관별 시범적용을 통한 장비운용 DDoS 대응 임계치를 설정하는 한편 시험 구축 결과를 바탕으로 서비스거부 대응지침 및 매뉴얼 개발 등의 DDoS 대응시스템 시험적용 및 확산 방안 마련할 계획”이라고 말했다.


사업자, 정부납품 위한 보안요구사항 충족 등 갖춰야

이번 사업의 제한요청 내용을 살펴보면, 구축되는 시스템은 정부납품을 위한 보안요구사항을 충족해야 하며, 기관의 특성에 적합한 대역폭을 충분히 처리할 수 있는 시스템을 구축해야 한다. 또한 백본 통신장애는 업무 영향도가 높기 때문에 비상시를 대비해 목적시스템의 설치 위치에 따라 ‘백본 통신경로 선상에 설치하는 방식’과 ‘백본 통신경로 외에 설치하는 방식’ 중 택해 구성해야 한다.


그 외 ▲통신 트래픽 분석 기능은 하드웨어·펌웨어 기반으로 처리 ▲기존 네트워크 장비 및 보안시스템 구성에 영향 주지 않고, 호환되는 시스템 구축 ▲생성 대용량 로그의 효율적 관리 방안 제시·구축 ▲향후 인터넷 회선 대역폭 증가 시 안정적으로 비정상 트래픽을 처리할 수 있도록 모듈 추가 및 업그레이드 등 목적시스템 확장 방안 제시 ▲설치기관의 정책에 따라, 기존 시스템과 연계가 가능해야 하는 등의 내용을 담고 있다.


이에 행안부 관계자는 “DDoS 대응체계 구축 경험을 보유한 한국정보보호진흥원을 통해 시스템을 구축하게 되는 본 사업은 대상기관과의 유기적 협력을 통한 맞춤형 DDoS 대응체계를 구축하게 될 것”이라고 추진전략을 밝히고 “해당기관의 기존 네트워크 변경 없이 목적시스템을 설치해 통신 안정성을 확보하고 향후 사용자의 급증 등 환경변화에 대처가 용이하고, 유지보수성이 높은 범용적인 목적시스템을 설치해 경제성 및 효율성을 확보할 것”이라고 덧붙였다.


또한 그는 “이번 사업은 빠르면 금일 저녁이나 내일 중으로 조달청에 공고를 내고, 7월 경 사업계약을 맺고 본격적인 구축사업을 시작하게 될 예정”이라며 사업진행 시기를 밝히고 “이번 사업은 시스템 구축 3개월과 2개월의 안정화 기간을 거쳐 완료될 예정”이라고 말했다.


한편 행안부가 중앙행정기관의 DDoS 대응을 위해 정부통합전산센터에서의 체계적 운영 방안을 마련하는 한편 보건복지분야 및 과학기술분야에 시범적용을 통한 유효성 검증을 위해 진행되는 이번 사업은 사업규모가 그렇게 크지는 않지만 공공의 DDoS 대응체계 구축의 첫 시도라는 점에서 이후 확대 구축이 예상됨에 따라 DDoS업계의 분주한 움직임이 있을 것으로 예상된다.

[김정완 기자(boan3@boannews.com)]


의사소통의 중요성은 다들 잘 아시리라 생각됩니다.

힘이나 상하관계에 의한 일방적인 커뮤니케이션이 아니라 상호 *소통*이 중요하다는 것을…

물론 *소통*을 다른 개념으로 사용하고 있는 듯한 사람이 있긴 하죠.

뇌 용량이 지극히 부족한 누구처럼…


주어진 일을 할 때 100% 판단 가능한 근거를 가지고 일을 시작하는 것은 거의 불가능에 가깝습니다. 아무리 많은 시간이 주어지더라도 어떤 것에 대해 100% 이해하고 시작하는 것이 쉬울까요?

따라서 일을 하면서 한정된 판단 근거를 가지고 판단해야 하는 과정이 반복됩니다. 그리고 그때마다 올바른 판단이 이루어진다면 주어진 일은 목적지를 향해 한발씩 더 다가가는 형태가 될 겁니다.

이때 올바른 판단을 위해 여러 가지 방법을 사용합니다. 예를 들어 다른 사람의 의견을 많이 듣고 판단한다거나 다양한 시스템(도구)을 활용하여 제대로 된 판단 근거를 유도하는데 사용하는 것입니다.

 

하지만 아무리 많은 좋은 데이터가 있더라도 결정은 사람이 하는 것입니다.

100% 올바른 데이터는 없기에… 또한 잘못된 데이터가 있기에…

 

그걸 잘 가려내어 올바른 판단을 할 수 있는 능력이 중요할 것입니다.


어떤 일을 할 때 각자 고유한 방식이 있습니다.

여기서 말하는 고유한 방식이란 게 사람마다 조금씩 다른 뭔가를 얘기하는 것이 아니라 좀 근본적인 두가지 측면을 말합니다.

 

A 스타일은 어떠한 문제가 주어졌을 때 그 문제를 분석하고 어떻게 해결해나갈지 방향을 생각하고, 또 그 내용을 정리하고 정리된 내용을 분석하고 그런 과정을 반복적으로 수행합니다. 근데 이 스타일이 너무 강해지면 문제의 본질을 망각해버리는 상황이 발생하게 됩니다. 예를 들어 주어진 문제를 풀어보니 코끼리를 그려야 한다면 처음에는 전체적으로 필요한 것을 파악하고 고민하고 그러다가 어느순간 코끼리는 사라지고 코만 계속 그리고 지우고 하는 과정이 되는거죠. 시간이 많이 흐른 다음에 “내가 뭘하고 있지” 느끼게 될 때가 있는데 이미 많이 늦어진거죠.

B 스타일은 어떠한 문제가 주어졌을 때 일단 구체화 과정까지 가보는 겁니다. 개발을 예로 든다면 어떤 문제가 있으면 일단 코드부터 수정을 해보는 거죠. 해보다가 안되면 다른 방법을 찾고 또 해보고 이러한 과정이 반복되는 것입니다. 근데 이 스타일이 너무 강해지면 시도해보지 않아도 빤한 일을 시도하는 경우가 생기고 빠뜨려지는 부분이 항상 생긴다는 겁니다. 예를 들어 동물원을 그려야 된다면 일단 대충 생각해서 호랑이, 사자, 곰 등을 그립니다. 다 그려놓고 다른 사람이 보니 동물원 건물 자체가 없습니다. 고민을 하게 되죠. 다 지우고 동물원 건물부터 다시 그려야 하나 아님 일단 그린 동물 사이사이에 동물원 건물을 그려 넣을까…

 

둘 다 극단적인 예입니다. 대부분의 사람들이 A 스타일과 B 스타일을 다 가지고 있습니다. 다만 어느 스타일 측면을 가지고 있냐에 따라 일하는 방식이 조금씩 다를 뿐이죠. 둘이 적절히 잘 조화를 이루게 되면 가장 좋겠지만 말만큼 쉬운 건 아니죠.

하여튼 어떤 일을 해야 할 때 세부적으로 내용을 잘 정리하고, 정리된 내용을 바탕으로 각각을 해결해 내갈 방안을 잘 고민하고 생각하는 게 중요합니다.

적어도 자신이 뭘 해야 하며 어떻게 해야 하는지는 계속적으로 고민해 나가는 것이 꼭 필요합니다.

그렇지 않으면….


예전에 프로젝트를 진행할 때 팀원 중에 이런 사람이 있었습니다.

개발계획서를 작성하고 프로젝트에 대한 일정을 생각해서 달라고 하니 아직 개발(여기서는 코딩을 말함)도 시작 못했는데 일정을 어떻게 알 수 있냐고 했습니다. 그럼 언제 개발이 완료될지 알 수 있냐고 했더니 개발이 끝나봐야 알 수 있다고 하더군요(OTL).

 

물론 무슨 일을 시작할 때 문제점이 무엇인지, 어떻게 문제점을 해결해 나갈지, 진행하면서 무슨 새로운 일이 생길지 알 수 없는 상태에서 일정을 도출해 내기란 불가능에 가까울지 모릅니다.

하지만 어떠한 조직에서 일을 할 때 일에 대한 예측 없이 진행한다는 것은 앞으로의 계획을 전혀 만들 수 없다는 것과 같습니다(언제 끝날지 모르는데 앞으로 계획을 세우는게 가능할까요?)

특히 개발이라는 무형의 괴물(?)을 봤을 때 언제 어떤 식으로 돌변해서 자신을 덮칠지 모르기 때문에 일정을 예측하기는 더욱 어려운 것 같습니다.

다만 일정을 예측할 때 지난 경험을 바탕으로 다양한 시나리오(앞으로 발생 가능한 일, 문제점 등등)를 감안하여 최대한  (?) 만드는 것이 중요할 것입니다.

 

근데 혹시 student syndrome이라고 아시나요?

해야 할 일을 미루고 있다가 결국 마지막 순간이 되어서야 실행하는 습관을 말합니다.

방학숙제를 쌓아두고 개학 전날 시작한다거나, 기말고사 준비를 시험기간 직전에 몰아서 한다거나 하는 식의 학생들의 버릇을 빈댄 거죠.

사실 회사 업무도 비슷한 경향이 있는 것 같습니다. 데드라인이 있으면 논리적으로는 그 전 언제 까지 어떻게 하는 등의 일정 수립을 합니다. 그러나 이상하게도 심리적으로는 데드라인이 가까이 오기 전까지는 시작을 하지 않는 경향이 있답니다. 항상 날짜가 많이 남아있어 보이죠. 그래서 막판까지 가다가 지금 시작하지 않으면 데드라인을 맞추기 어려울 것 같은 시점에서 드디어 발등에 불이 떨어지는 것을 느끼고 시작하게 되는 것이죠. 근데 그 깨닫는 시점이 늦을 수록 결과는 엉망이 되는 것입니다.


대부분의 회사에서 개발에 관련된 사항을 프로젝트화 해서 진행하고 있습니다.

“프로젝트”란 주어진 요구사항을 주어진 자원을 이용하여 주어진 기간동안 수행하는 것을 말합니다.

일상적인 업무와 프로젝트의 차이점이 바로 주어진 기간 동안 한시적으로 운영된다는 것이죠.

 

사실 조그만 조직에서는 프로젝트화 하는 것이 필요 없을 지도 모릅니다.

개발에 참여하는 인원이 소규모이고, 따라서 하는 일이 빤히 보이는 상황이기 때문에 프로젝트화한다는 것이 별로 의미가 없어 보일 수도 있죠.

하지만 항상 이 정도의 규모로만 개발이 진행된다고 볼 수 없기 때문에 프로젝트 기반으로 업무를 수행하고 체계화해 나가는 분위기를 익히고 경험하는 것은 매우 중요하다고 할 수 있습니다.

 

규모나 참여 인원에 따라 프로젝트 관리 방법도 상당히 많이 다르겠지요.

그래도 기본적으로 해야 할 일을 명확히 정의하고, 그 일을 누가, 어떻게, 언제까지 할 것인지를 미리 결정하고 진행하는 것은 기본이라고 볼 수 있습니다.

그리고 중간 중간 진행 상황에 대해 검토하고, 그 결과에 따라 다음 진행 방향에 대해 보완해 나가는 것이 필요하죠.

소프트웨어 공학에서 얘기하는 것처럼 시스템적이고 체계적이고 이론적인 부분이 현실에 적용되기는 상당히 어렵습니다. 다만 근본적인 개념을 이해하고 그 개념을 속해있는 조직의 현실에 맞게 접목하는 것이 가장 중요하다고 볼 수 있습니다.

 

앞으로 당분간은 일을 진행할 때 각자가 사전에 많은 생각을 하도록 유도하고, 기술적인 부분 검토나 아이디어 도출에 좀 더 많은 시간을 할애할 수 있도록 할 계획입니다.

모든 프로젝트가 그렇다고 할 순 없지만, 대부분 사전에 많은 고려를 하게 되면 나중에 완전히 엉뚱한 방향으로 일이 잘못 나아가는 것을 최소한으로 방지할 수 있습니다.

그리고 코딩 들어가기 전에 머리 속으로 체계화시킬수 있는 능력도 좀더 키우는 것이 필요할 것이라고 생각됩니다. 누가 대신해 줄 순 없지만 그렇게 하도록 유도할 순 있겠죠….


아버네트웍스 보안연구 매니저

DDoS 공격, 한국만의 위협 아니다
DNS 기술 이용하는 컨피커C, 정리 끝났다

반가운 얼굴을 만났다. 지난해 ISEC 2008 강연을 위해 한국을 처음 방문했던 정보보안 연구의 권위자 호세 나자리오(Jose Nazario) 박사가 지난달 개최된 “2009 Hacking Defence & Conference”의 기조연설을 위해 두 번째로 한국을 방문했다. 본지는 현 봇넷 조망에 대해 발표한 호세 나자리오 박사를 만나 봇넷과 DDoS 공격에서부터 컨피커에 이르기까지 최근의 보안 위협에 대해 포괄적으로 살펴봤다. 한편 컨피커 워킹 그룹(Conficker Working Group)의 일원으로 활동하고 있는 그는 본지와의 인터뷰에 앞서 KISA 연구원들과 컨피커에 관한 미팅을 갖기도 했다.

해외 기사를 검색하다보면 몇 번이고 그 이름을 보게 되는 아버네트웍스(Arbor Networks)의 보안연구 매니저 호세 나자리오 박사는 특히 DDoS 공격, 봇넷, 웜, 소스코드분석 툴, 데이터 마이닝 등에 관한 연구로 전 세계 인터넷 트렌드 연구에 상당한 영향을 끼치고 있다. 또한 블랙햇(Blackhat)을 비롯해 CanSecWest, PacSec, NANOG 등 전 세계 수많은 컨퍼런스의 강연자로 초청받고 있는 그는 국내에서 개최된 이번 해킹대회에서 DDoS 봇넷, 스파이웨어 봇넷, 그리고 컨피커에 관한 기조연설을 했다.


이번 해킹 대회에서 발표한 기조연설 “The botnet landscape”에 대해 간단히 말해 달라.

2009년 중반에 접어들고 있는 현재의 봇넷 조망에 관해 발표했다. 특히 현재 확인되고 있는 봇넷의 종류와 변화, 그리고 그에 대해 우리가 어떻게 지속적으로 대응할 필요가 있는지에 관한 전반적인 내용을 설명하고자 했다. 몇 년 전만 해도 대부분의 봇넷은 IRC와 일부 코드베이스들을 기반으로 했다. 그러나 현재 HTTP를 이용하는 봇넷이 나타나고 있으며 더욱 더 많은 봇넷들이 자체 프로토콜을 이용하고 있다. 또한 봇넷이 단지 DDoS나 소프트웨어 설치에 이용되고 있을 뿐만 아니라 종종 스팸이나 정보 탈취의 목적으로 이용되고 있음이 확인되고 있다.


최근 세계적인 DDoS 공격 트렌드나 특징이 있다면?

과거와의 가장 큰 변화는 무엇인가? 작년 혹은 재작년부터 보다 교묘한 공격자들이 ISP 업체들과 운영업체들의 핵심 장비를 공격해 사용자들과 주요 e-상거래 업체들에 대한 서비스 불능을 유발하고 있다. 그들은 또한 주요 호스팅 업체들과 클라우드 공급업체들을 공격하고 있어 수많은 사용자들에게 영향을 끼치게 된다.

공격자 메소드(attacker method) 또한 변화하고 있다. 상당수 공격이 피해자의 광대역을 차지하도록 고안된 브루트 포스 플러드(brute force flood)를 여전히 이용하고 있다. 그러나 또한 공격자들은 애플리케이션 리소스를 소모하는 애플리케이션 메소드로 피해자의 서버를 공격하고 있는 것으로 확인됐다. 이것은 백엔드 데이터베이스 서버 등 전체 서비스 인프라스트럭처에 영향을 끼칠 수도 있다. 이러한 공격은 특별히 빠른 속도가 필요한 것도 아니며 특히 정상 클라이언트와 구별하기가 어려운 점이 특징이다.


이에 대응하기 위해서는 무엇이 필요한가?

성공적인 DDoS 완화를 위해서는 최소 두 가지가 필요하다. 우선 특정한 트래픽을 차단하기 위한 정확하고 통찰력 있는 애플리케이션 레이어 필터링이 필요하다. 둘째 ISP를 통한 고속 필터링 업스트림으로 트래픽이 고객의 네트워크를 다 차지하기 전에 그 트래픽을 차단하는 것이다. 이와 같은 방법은 공격을 막을 뿐만 아니라 고객들에 대한 서비스 손실을 최소화할 수 있게 해준다.


국내에서는 한국이 유난히 DDoS 공격에 노출되어있다는 의견도 있는데, 이에 대해 어떻게 생각하는가?

한국뿐만 아니라 거의 모든 국가들이 DDoS 공격의 위험에 처해있다. DDoS 공격자들의 구미를 당기는 것은 e-가버먼트(e-government), ISP 인프라스트럭처, e-상거래 사이트, 호스팅(포르노나 게임, 또는 도박 사이트를 호스팅하는) 업체, 사람들의 참여도가 높은 유명 포럼 등 외에도 상당히 많다. 이와 관련해 한국의 수많은 온라인 서비스와 엄청난 온라인 이용자들이 한국을 DDoS 공격에 취약하게 만든다고 할 수 있다. 공격자들은 자신들이 사용자 경험에 영향을 끼칠 수 있다는 것을 알고 있으며 공격을 통해 피해자들로부터 금품을 갈취할 수 있다는 것도 알고 있기 때문에 이러한 공격이 많이 발생하고 있다. 아울러 한국에 가해지고 있는 대부분의 공격이 중국 봇넷으로부터 발생한 것이라는 한국의 주장은 사실이라고 볼 수 있다. 전 세계 트래픽을 모니터링하고 있는 우리(아버네트웍스)가 중국 봇넷과 한국 트래픽을 모니터링 한 결과에 따르면 수많은 중국 봇넷이 한국 사이트를 공격하고 있는 것으로 확인되고 있다.

그러나 한국만이 유독 DDoS 공격의 타겟이 되고 있는 것은 아니다. 미국에서도 은행 등을 대상으로 하는 DDoS 공격이 발생하고 있으며 이미 금품을 요구하는 DDoS 공격도 있었다. 그러나 현재 미국에는 인터넷 금융 거래(Financial Transaction)에 관한 엄격한 제재(strict rules)가 있어 대부분의 관련 사이트들은 버퍼 오버플로우를 완전히 제거한(clean) 상태다.

페이팔(Paypal) 등은 매우 구미가 당기는 타겟이기 때문에 금품을 요구하는 공격을 받기도 했지만 이제는 그에 대한 대책을 충분히 세워놓고 있다. DDoS 공격으로 서비스 제공을 하지 못하게 되는 것은 그들 자신의 사업에 심각한 문제가 될 수 있기 때문이다.


DDoS 공격에 대한 대응과 관련해 한국의 기업들 또는 보안 담당자들에게 조언해준다면?

공격 받을 것을 우려하고 있다면 ISP 업체의 DDoS 공격 방어 대책에 대해 확인하는 것이 가장 중요하다. 즉, 그들이 DDoS 공격 방어 서비스를 제공하고 있는지, 대응 시간은 얼마나 걸리는지, 또 공격이 가해지는 동안 당신의 온라인 비즈니스가 안전하게 지켜질 수 있는지 등을 확인해야만 한다.


최근에는 맥 운영체제를 노리는 맬웨어가 맥 봇넷을 구축했다는 보도도 있었는데?

HTTP와 기타 자체 프로토콜을 이용한 봇넷의 변화가 나타나고 있다고 언급한 바와 같이 봇넷은 스팸 소프트웨어 설치뿐만 아니라 정보 탈취 소프트웨어 등과 같은 공격에 이용되고 있다. 봇넷은 그야말로 공격자들을 위한 서비스 툴이 되었다. 그러나 맥(Mac) OS X 봇넷은 대부분 개념증명(PoC : proof of concept) 정도의 수준이며 일반 PC 봇넷에 비해서는 아주 극히 일부 이용자들만이 맥 봇넷으로 이용되고 있음을 확인했다. 특히 맥 OS X 봇넷 소프트웨어는 사용자에 의해 설치되어야만하기 때문에 루트 패스워드를 입력해야만 한다. 이 때문에 대개 사용자가 인식하지 못 한 상태에서 설치되는 PC 봇넷에 비해 맥 봇넷이 생성되기는 훨씬 어렵다.


컨피커워킹그룹에서 활동하고 있는 것으로 아는데 단체의 목적, 그리고 성과에 대해 말해 달라.

개체수 뿐만 아니라 언론의 관심이라는 측면에서 볼 때 컨피커는 최근 몇 년간 있었던 웜 중에 가장 심각한 웜이다. 나는 4~5개월 동안 매일 반나절을 컨피커와 관련된 일로 보내고 있다. 나를 포함한 컨피커 워킹 그룹(Conficker Working Group)의 멤버들은 이 봇넷을 조사하고 감염된 네트워크를 정화하기 위해 매우 분주하게 보내고 있다.

컨피커 워킹 그룹은 컨피커에 대응하기 위해 MS를 비롯해 시만텍, F-시큐어, 아버네트웍스 등 IT 및 보안 기업들과 쉐도우서버 파운데이션(Shadowserver Foundation), 그리고 개인 연구자들이 모인 단체다. 처음에는 장난삼아 컨피커 카발(Conficker Cabal, 컨피커 결사대)라고 이름 붙이기도 했지만, 이제는 컨피커 워킹 그룹이라고 부른다. 컨피커 워킹 그룹은 컨피커 웜이 P2P를 이용해 통신하는 방법 등에 관해 연구하고 있고 이러한 호스트를 식별하기 위한 센서를 배포해왔으며 보고서를 작성하고 있다. 특히 우리는 현재 사용자 PC의 컨피커 웜 제거라는 더 큰 과제와 대면하고 있으며, 상당히 어려운 일임에도 불구하고 전 세계 대부분의 컨피커 웜 감염자들과 컨택하기 위해 노력하고 있다. 그러나 DNS를 이용하는 컨피커C는 현재 깨끗이 정리됐다고 자신할 수 있다. 특히 컨피커C가 이용한 도메인에는 .kr이 상당히 많았기 때문에 우리는 한국의 이용자들에게 닿기 위해 최선의 노력을 기울이고 있다. 한편, 컨피커 배후세력과 관련해 우리는 일부 의심되는 배후는 추측하고 있으나 아직 정확하게는 알지 못 한다.


앞서 언급한 내용 외에 올해 가장 큰 보안 위협 또는 이슈가 될 것이 있다면?

페이스북이나 트위터와 같은 소셜 네트워킹 사이트들은 유럽과 북미 지역에서 가장 큰 위협이 되고 있다. 트위터 사이트 자체를 공격하거나 그 이용자들에 대한 직접적인 공격이라기보다는 그러한 사이트를 통한 스팸, 악성코드, 그리고 피싱 공격 등이 문제가 된다. 즉, 스팸이 이메일을 이용했던 것과 마찬가지로 이제는 소셜 네트워킹을 이용하고 있다. 스패머들과 악성코드가 이러한 사이트를 이용해 전파를 시도하고 있는 만큼 한국에도 이 같은 문제가 곧 발생할 것이라고 생각한다. 특히 사용자들은 이러한 네트워크 내에서 자신들을 보호하는 방법을 아직 모르고 있는 반면, 공격자들은 이들 사이트가 사용자들을 공격하기 위한 새로운 땅(fresh ground)이라는 것을 잘 알고 있다는 것이 문제다.
 
한편 기업의 경우, 경기 침체 속에서 보다 적은 인력과 장비 예산으로 기업의 데이터와 인프라스트럭처를 보호하는 것이 가장 큰 어려움이 될 것으로 생각된다. 모든 이들이 ‘더 적게’들여 ‘더 많이’ 얻기 위해 애쓰고 있다. 우리 모두는 우리의 네트워크를 안전하게 유지하기 위해, 또 지금 해야만 하는 일을 하기 위해 잘 훈련받고 의견을 교환하도록 해야만 한다고 생각한다. 이것은 특히 그 어느 때보다 지금과 같이 힘든 시기에 더욱 중요한 일이다.

글 : 김동빈 기자(foreign@boannews.com)

[월간 정보보호21c 통권 제106호 (info@boannews.com)]
당신의 조직은 개발자를 올바르게 관리하고 있는가?

류한석(IT 컬럼니스트)   2007/10/09
 
한국의 많은 소프트웨어 업체들이 개발자를 제대로 관리하지 못하고(또는 안하고) 있다. 소프트웨어 개발은 정신에 의한 작업이다. 누가 하는 가에 따라서, 어떤 동기부여를 하는 가에 따라서, 어떤 환경에서 하는 가에 따라서, 어떻게 관리하는 가에 따라서 엄청나게 다른 결과를 만들어낸다.

하지만 관리라는 이름 하에 개발자에게 모욕적인 대우를 하는 경우도 많다. 작업에 지장이 있을 정도의 저사양 개발장비를 제공하고, 좁아터진 공간에, 계속 울리는 전화벨과 시끄러운 대화 소리, 휴식공간이라고는 전혀 없는 조직도 많다. 직원들의 일거수일투족을 감시하고, 심지어는 복장 검사를 하는 경우도 있다.

또한 프로젝트 데드라인을 맞추기 위해 새벽에야 겨우 집에 들어갔음에도 불구하고, 출근시간에 몇 분 늦었다고 해서 지각을 체크하고 전체 직원이 모인 회의에서 실명을 거론하는 회사도 있다. 그런 회사일수록 야근수당이 없고 교통비도 지급하지 않으며 사소한 비용을 아낀다. 한마디로 작은 비용을 절약함으로써, 신뢰 상실이라는 큰 비용을 지불하는 것이다.

그런 회사에서 만들어지는 소프트웨어는 품질이 나쁘다. 불행한 개발자들은 품질이 나쁜 소프트웨어를 만들어 낸다. 어쩌면 잠을 못 자고 피로에 지친 개발자들이 내쉬는 서글픈 한숨이 소프트웨어의 영혼에 스며들어 가는 것은 아닐까? 저주받은 소프트웨어. 마치 호러영화의 한 장면처럼 느껴진다.

회사는 직원들을 사랑하지 않으면서, 직원들에게 애사심을 강요하는 회사를 보고 있자면 실소가 나온다. 물론 회사로서는 직원들에게 사랑을 보여줄 수 없는 가장 큰 이유가, 열악한 비즈니스 환경으로 인한 비용적 압박 때문이라고 얘기할 것이다. 백분 양보하여 그것을 인정한다고 할 지라도, 그렇다면 도대체 왜 부적절한 관리자에게 관리를 맡기고 있는 것일까?

나쁜 관리자가 프로젝트를 망치고 있다!
업계를 보면 관리자의 자격이 전혀 없는 사람이 관리를 맡고 있는 경우가 무척 많다. 나쁜 관리의 비용은 엄청나다. 단지 팀 구성원들의 작업에 지장을 주는 정도가 아니라, 조직의 목표 달성에 해악을 미치며 결국 상당한 대가를 치르게 만들고 프로젝트를 완전히 망치는 경우가 빈번하다.

필자는 단지 관리자를 잘못 배정했기 때문에 수백억 원의 손해를 본 어느 대기업의 프로젝트를 경험한 적이 있다. 팀원들은 모두 유능했고 각자의 마음 속에 일을 잘하고자 하는 열정이 있었지만, 관리자의 무능과 변덕과 학대로 인해 팀원들은 모두 좀비가 되어갔다. 일부는 떠났고 일부는 일을 하지 않았고 일부는 하는 척을 했다. 결국 수년간 프로젝트를 진행했으나 결과는 나오지 않았고 프로젝트는 취소됐다. 몇 가지 추가적인 원인이 없었던 것은 아니지만, 가장 주요한 요인은 ‘나쁜 관리자의 존재’ 그 자체였다.

나쁜 관리자는 팀원들이 무엇을 하고 있는지 알지 못하며(또는 관심이 없으며), 팀원들의 능력을 제대로 파악하지 못한 채로, 원칙 없이 업무를 지시하며, 부적절한 인력을 배치하고, 팀원들과 제대로 대화를 나누지 않으며, 펫프로젝트(pet project, 고위층 또는 자신의 개인적인 관심으로 만들어낸 프로젝트)로 인해 업무 우선순위를 마구 바꾸고, 결과가 나와도 잘했는지 못했는지 제대로 판단하지 못한 채 자신의 기호에 따라 결과를 재단한다. 한마디로 그들은 조직의 목표와 팀원의 성장에는 아무런 관심이 없으며 단지 자신의 안위만 생각하는 사람들이다.

그러한 나쁜 관리자의 존재가 지극히 예외적인 경우라고 생각하는가? 만일 그렇다면 당신은 조직 생활의 경험이 많지 않든가, 아니면 억세게 운이 좋은 경우일 것이다. 그런 나쁜 관리자로 인하여 젊은 시절의 소중한 경험을 빼앗기는 팀원들이 몹시 많다.
나쁜 관리자의 해악은 단지 프로젝트의 실패로 나타나는 것뿐만 아니라, 사람들의 인생에서 그 시기에 필히 겪어야 할 소중한 경험까지 앗아가 버리는 것에 있다. 좋은 관리를 받아보지 못한 사람은 좋은 관리를 할 수가 없다.

좋은 관리자가 되기 위한 지침
그렇다면 좋은 관리란 어떻게 관리하는 것인가? 하단과 같이 몇 가지 지침을 제시할 수 있을 것이다.

첫째, 바라는 결과를 명확히 알려주어야 한다. 어떤 관리자들은 자신이 무엇을 원하는지 자기 스스로도 정확히 모르는 채 작업을 지시하고, 팀원의 작업 결과를 그날그날의 기분에 따라 자신의 기호대로 판단하곤 한다. 그런 관리자는 관리자로서의 자격이 없다.

둘째, 위임을 적절하게 수행해야 한다. 어떤 사람의 그릇은 위임할 수 있는 양의 크기로 정해진다. 즉 어떤 사람이 이루어낼 수 있는 최대 성과치는 그가 팀원들에게 권한을 위임할 수 있는 능력에 의해서 결정된다는 뜻이다. 할 일이 너무나 많지만 일할 시간이 없고 혼자서 모든 일을 처리하려고 하는 관리자는 탈진증후군(burnout syndrome)에 빠지게 된다. 그리고 탈진증후군에 빠진 관리자는 결국 팀을 궤멸시킨다.

셋째, 방법보다는 결과에 초점을 맞추어야 한다. 이 말에 오해가 없기를 바란다. 오로지 결과만 중요시하라는 뜻이 아니라, 결과가 올바르다면 방법은 팀원에게 맡겨두라는 뜻이다. 개발자 출신의 관리자는 자신이 선호하지 않은 방법으로 구현을 했다는 이유로 팀원을 질책하거나 업무를 회수하는 잘못을 저지르는 경우가 많다. 그런 관리자는 좋은 결과도 팀원들의 신뢰도 얻지 못할 것이다. 결과가 옳다면 그 방법은 팀원에게 맡겨두는 포용력을 가져야 한다.

넷째, 피드백을 주고, 코칭을 하고, 경력 개발을 지원해야 한다. 피드백이란 해당 직원의 업무 결과에 대해 어떻게 생각하는지 그 내용을 전달하는 것이다.
코칭은 일종의 도움을 주는 것으로서 선택 가능한 사항들 속에서 실행 계획을 만들도록 도와주는 것이다. 그리고 팀원이 새로운 지식과 경험을 쌓음으로써 성장할 수 있도록 경력 개발을 지원해야 한다. 팀원의 경력 개발에 전혀 신경을 쓰지 않은 관리자들이 너무 많다. 그것은 팀원을 일회용품으로 취급하고 있음을 스스로 증명하는 것과 같다. 경력 개발에 도움을 받은 팀원은 관심을 갖고 도와준 관리자를 언제까지나 기억할 것이다.

다섯째, 좋은 관리자는 자기 자신을 관리하는 사람이다. 좋은 관리자는 감정의 폭발에 반응하기보다는 사건에 대응한다. 불필요한 감정을 발산하여 팀원에게 공포심을 조장해서는 안 된다. 만일 감정이 폭발했거나 또는 잘못된 지시를 했다고 판단될 시에는 즉각 솔직하게 인정하고 사과를 해야 한다. 실수를 인정하는 관리자는 인간적으로 보인다.

좋은 관리 방법을 배우기는 힘들다. 왜냐하면 그것은 눈에 잘 보이지 않기 때문이다. 하지만 우리는 그것을 배우고 실천해야 한다.
그것이야말로 업계에 만연된 악순환의 고리를 끊어버리는 유일한 방법이기 때문이다. 우리가 겪은 불행한 경험을 다시금 후배들에게 전달해서는 안 된다.

비록 기술 중심의 소프트웨어 업체라고 할 지라도, 기술 관리란 기술이 아니라 사람을 다루는 것임을 잊지 말아야 한다. 회사가 가능한 범위 내에서 최상의 업무 환경을 제공하고, 개발자 개개인을 세심히 배려하는 피드백, 코칭, 경력 개발을 지원하는 관리자가 있는 조직이라면 개발자는 결코 불행하지 않을 것이며 더 나아가 어려운 일도 기꺼이 극복해 낼 것이다.

하지만 지금 이 순간에도 많은 기업들이 사소한 비용 절감과 무의미한 규칙 준수를 위해 직원들의 신뢰를 잃고 있으며, 나쁜 관리자를 배정함으로써 프로젝트와 팀원의 인생을 망치고 있다. 나쁜 관리자는 개인, 회사, 사회 모두에 악영향을 미치는 존재이다.

반면에 좋은 관리자는 탁월한 결과를 만들어내고 팀원들을 성장시키고 사회 전반에 좋은 인재를 공급한다. 그런 훌륭한 관리자가 어디 흔하냐고 항변하는 기업의 목소리가 들린다. 하지만 기업들이여, 그런 변명보다는 좋은 관리자를 채용하려는 노력, 그리고 양성하려는 노력, 그리고 그가 ‘진짜 관리’를 제대로 수행하였는지 평가하려는 노력을 무엇보다 먼저 기울여야 하지 않을까?
이전 1 2 3 4 5 6 다음