시스템이야기2011. 8. 30. 13:22


apache


jjun님이 글을 쓰셨으니 간단하게만 몇가지 언급하겠다.

'아파치 웹서버 무력화시킬 심각한 DoS 결함 발견' 기사에는 mod_deflate또는 mod_gzip 모듈과 관련이 있는 것으로 쓰여있지만, 이 모듈과는 무관하게 취약점이 존재한다. 해당 모듈을 주석처리해도 악의적인 Range 헤더 요청에 대해 똑같은 문제가 있으며, 아파치 메일링 리스트에서도 이 모듈을 언급한 것은 잘못된 판단이었다고 한다.

* Bug 51714 - Byte Range Filter might consume huge amounts of memory combined with compressed streams
As discussed on the Apache Dev Mailing list it looks like this issue has nothing to do with mod_deflate or mod_gzip, wrong assumption by me.

웹페이지 size에 따라서, Range 헤더의 문제가 발생할 수도 있고 없을 수도 없다.

1) mod_php5모듈이 없다면 웹페이지 size에 상관없이 문제가 있다.
2) mod_php5모듈과 함께 아파치를 동작중이라면 8000bytes 이하의 웹페이지를 요청할 때만 문제가 발생한다. mod_php5 모듈이 있더라도 php로 인식하지 않는 확장자(예를 들어 .css, js, .txt 등)는 사이즈에 상관없이 문제가 있다.

따라서 index페이지만 체크하고 '우리는 문제가 없네'라고 판단해서는 안된다. php로 된 index가 8000bytes를 넘는다면, 취약점이 없는 것으로 보일 수 있기 때문이다.

Request 헤더에 Range: bytes=0-,1-2,2-3,4-5 같은 형태로 요청했다고 가정하자.

0-은 해당 웹페이지의 시작부터 끝까지를, 1-2는 웹페이지의 2번째~3번째 문자(0부터 시작하니깐 1-2는 2~3번째)를, 나머지도 같은 의미이다. 일반적으로 콤마(,)로 구분해서 여러 필드를 요청하는 경우는 없다라고 생각하면 된다.

[ 아파치 설정에서 Range헤더에 콤마를 제한하는 예 ]
SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range

따라서 위처럼 5개 필드 이상(콤마가 5개 이상)인 경우만 제한해도 좋고, 간단하게 콤마(,)가 포함된 경우를 차단해도 무방할 것으로 보인다.
곧 패치버전이 나올 것이다. 하지만 그 때까지는 L7장비 또는 웹서버에서 Range 헤더 조건 강화하는 방법으로 차단해야 할 것이다.


* 관련글 :
  - Mitigation of Apache Range Header DoS Attack
  - DoS with mod_deflate & range requests

* 내용 추가 (2011.8.31(수) 점심)

이 DoS 취약점을 패치한 2.2.20 버전이 발표되었다.

- Release 정보 : http://www.apache.org/dist/httpd/Announcement2.2.html
- 다운받기 : http://ftp.daum.net/apache/httpd/




Posted by 좋은진호
IT이야기2011. 8. 13. 23:28
'쥐박이' 도메인을 청와대에서 등록했다는 기사를 봤다.(한겨레신문) 그래서 재미삼아 도메인 whois 검색을 해봤다. 쥐박이, 명박이 도메인은 같은날에 등록을 했다. 언론에 노출된 뒤로 등록자 정보가 모두 감춰졌다.

$ whois_list.sh 쥐박이
쥐박이.kr            등록 => 등록일: 2010. 01. 27.
쥐박이.com           등록 =>  Creation Date: 27-jan-2010
쥐박이.org           등록 => Created On:27-Jan-2010 06:06:52 UTC
쥐박이.net           등록 =>  Creation Date: 27-jan-2010

$ whois_list.sh 명박이
명박이.kr            등록 => 등록일: 2010. 01. 27.
명박이.com           등록 =>  Creation Date: 27-jan-2010
명박이.org           등록 => Created On:27-Jan-2010 06:06:47 UTC
명박이.net           등록 =>  Creation Date: 27-jan-2010

$ whois_list.sh 이명박
이명박.kr            등록 => 등록일: 2010. 12. 02.
이명박.com           등록 =>  Creation Date: 15-nov-2000
이명박.org           없음
이명박.net           등록 =>  Creation Date: 11-nov-2005


* 명박이.kr whois 정보

도메인이름                  : 명박이.kr
등록인                      : 후이즈 도메인 관리자   <-- blind 처리
등록인 주소                 : 서울 구로구 구로3동 182-4 대륭포스트타워 3차 1101호
등록인 우편번호             : 152847
책임자                      : 후이즈 도메인 관리자
책임자 전자우편             : admin@whoisblind.com
책임자 전화번호             : 82-2-1588-4259
등록일                      : 2010. 01. 27.
최근 정보 변경일            : 2011. 08. 12.          <-- 언론 노출 후 정보 변경
사용 종료일                 : 2012. 01. 27.
정보공개여부                : Y


쥐박이, 명박이 도메인은 청와대에서 등록을 했다. 그런데, '이명박' 도메인은 이명박.kr, .com, .net이 모두 다른 소유자가 갖고 있었다.
왜 이명박.kr 은 청와대(국민 세금이 들어가는 것이니 개인적으로 원치는 않지만)에서 등록하지 않았을까? 이명박.com과 .net은 오래전에 등록되어 있으니 그런가보구나 넘어갈 수 있는데, 이명박.kr은 누군가에 의해 작년 12월에 등록되어 있다. 쥐박이, 명박이는 작년 1월에 등록했다. 그러면 작년 1월에 이명박.kr과 이명박.org도 같이 등록했을 수도 있지 않았을까.

한글 도메인은 이쯤하고, 다른 것을 검색해보고 싶었다. 그순간, 방통위로 부터 접속차단당한 트위터 2MB18nomA가 떠올랐다. whois 검색을 해볼까?

$ whois_list.sh 2mb18noma
2mb18noma.co.kr      없음
2mb18noma.or.kr      없음
2mb18noma.re.kr      없음
2mb18noma.pe.kr      없음
2mb18noma.go.kr      없음
2mb18noma.kr         없음
2mb18noma.com        등록 =>  Creation Date: 15-jul-2011
2mb18noma.org        등록 => Created On:15-Jul-2011 07:53:15 UTC
2mb18noma.net        등록 =>  Creation Date: 15-jul-2011


어? 등록되어 있다. 3개가 7월에. 현재 2mb18noma.com, 2mb18noma.net은 도메인 파킹되어 있다. 
2mb18noma.org은 진보넷에서 사용중인 것으로 보인다. 사이트를 가보니 '2MB18nomA 접속차단에 반대한다. 방송통신심의위원회 통신심의 문제 감시 블로그'라고 쓰여있다. 와~ 좋은 목적의 블로그다. ^^ 3개 도메인 모두 소유자는 'Domains by Proxy'으로 표시되어 있는데, 같은 날짜에 등록한 것을 보면 '진보넷'에서 등록했을 듯 싶다. 

* 2mb18noma whois 정보 

Registrant:
   Domains by Proxy, Inc.
   DomainsByProxy.com
   15111 N. Hayden Rd., Ste 160, PMB 353
   Scottsdale, Arizona 85260
   United States


※ whois 검색은 '커피닉스에 올려둔 스크립트'를 사용했다.
 
Posted by 좋은진호
IT이야기2011. 4. 20. 21:02
오리건주 프린빌(Prineville, Oregon)에는 약 30만 square feet크기(9만5천평)의 페이스북(Facebook) 데이터센터가 있다. 현재 절반인 15만 square feet가 운영중이며, 올 하반기에 나머지 절반이 완성될 것이다. 이 데이터센터와 페이스북 서버가 4월초에 Open Compute Project( http://opencompute.org/ )를 통해 공개가 되었다.

[ 페이스북 데이터센터 내부. 출처 : Open Compute Project ]


[ 페이스북 서버 샤시. 출처 : Open Compute Project ]


[ 페이스북 서버 조립. 출처 : Open Compute Project의 동영상 중에서 ]


페이스북 서버에 간략하게 요약하면.
  • 1U보다 더 큰 1.5U 크기의 서버. 그래서 보다 큰 방열판과 팬을 사용하여 온도 효율성이 높아졌다.
  • 샤시는 심플하다. 페이스북은 '무허영심(vanity free)'이라고 표현했다. 멋진 말이다. 군살을 쏙 뺀 반드시 필요한것만 들어있는 구조다.
  • AMD보드 : AMD 옵테론 6100시리즈, 24 DIMM 메모리 슬롯
  • 인텔 보드 : 인텔 제온 5500 또는 5600, 18 DIMM 메모리 슬롯
  • 자체 제작한 서버는 구매한 서버보다 38%정도 높은 효율. 24% 저렴
  • 파워서플라이 : 94.5%의 고효율. 2009년 당시 구글서버가 85~90%였다.
  • 전원은 2개가 연결되는데, 하나는 277V AC 주전원(일반적인 208V보다 높은 것은 효율을 위해). 다른 하나는 48V DC 백업전원(48V DC는 캐비넷형태의 UPS에 연결됨). 구글서버는 12V DC전원만 사용한다.
페이스북 데이터센터와 서버에 대해서는 4월 초에 나온 글이 인터넷에 많을 것이니, 추가된 내용들만 적어보겠다.


1. 페이스북 데이터센터의 태양광 시설

페이스북은 이 데이터센터에 태양광발전시설을 구축하여 100KW의 전기를 생산한다. 1년을 기준으로 204,000KWh의 전기를 생산할 것으로 기대하고 있다. 1년 20만KWh라면, 하루 5.6시간을 생산했을 때를 가정한 것 같다.
365일 X 5.6h X 100KW = 약 20만KWh

태양광발전으로 생산되는 에너지는 전체 에너지 사용량에 비하면 비중이 상당히 낮다. 그린피스에서도 에너지 사용면에서 좋지 않은 데이터센터로 지적했다.

[ 페이스북 데이터센터의 태양광 발전시설. 출처 : Swinny.net (URL은 아래 '사진' 출처에) ]


하지만 데이터센터의 에너지 효율은 상당히 높다. 데이터센터의 에너지효율은 PUE수치로 나타내는데, 이 수치가 1에 가까울수록 높은 효율을 나타낸다. 구글은 2009년에 평균 PUE가 1.22라는 놀라운 수치를 보였으며, 구글의 데이터센터 중에는 1.1x인 곳도 있다. PUE가 1.2만 되어도 예술의 경지에 이르렀다고 하는데, 페이스북의 새 데이터센터는 놀랍게도 PUE가 1.07이다. 즉, 거의 전력 손실없이 운영되고 있다는 뜻이다.

 
2. 데이터센터 추가 동영상과 사진

금요일에 저널리스트와 프린빌(Prineville) 지역 공무원을 대상으로 페이스북 데이터센터 투어가 있었나보다. Data Center Knowledge의 'Video: Inside Facebook’s Server Room' (2011.4.18) 글에 약 8분짜리 데이터센터 투어 동영상을 볼 수 있다.

[ 페이스북 데이터센터와 Jay Park. 출처 : 위 Data Center Knowledge 동영상 캡쳐 ]

[ 서버 전원부. 하나는 277V AC전원. 하나는 48V DC전원. 출처 : 위 Data Center Knowledge 동영상 캡쳐 ]

[ 페이스북 서버랙. 출처 : 위 Data Center Knowledge 동영상 캡쳐 ]


투어를 시켜준 사람이 'Director of Datacenter Engineering'(데이터센터 엔지니어링 부서 이사 정도?) 'Jay Park'이란 분이다. 전기분야 엔지니어이신데, 미국 교포일까? 이름도 그렇기도 하고, 동영상이나 사진을 보면 우리 나라 사람 같아 보인다.

Rackspace에서 근무하시는 분이 데이터센터를 방문하여 올린 사진도 있다
* Photo tour of Facebook’s new datacenter (Scobleizer 블로그, 2011.4.16)

[ 페이스북 데이터센터 로비의 모니터화면. 출처 : 위 Scobleizer 블로그 ]


로비 모니터에 데이터센터 상태를 모니터링할 수 있는 화면이 있다고 한다. 내부 온도는 18~27도(화씨 66~82도), 습도는 24~41% 정도다. 습도는 적정수준인데, 온도는 높은 구역도 있다. 외부 공기를 끌어다가 냉각을 해서 조금 높은 것일 수도 있겠다. 그리고, 오른쪽 상단에 표시된 현재 PUE는 1.08(?)으로 환상적이다. ^^

페이스북의 다른 데이터센터 사진을 보고 싶다면 타임지(TIME)에서 공개한 사진이 있다. 타임지는 2010년 올해의 인물로 페이스북의 '마크 주커버그(Mark Zuckerberg)'를 선정(2010년 12월중순)했다. 그래서, 타임지는 페이스북의 또다른 데이터센터인 캘리포니아주 산타클라라(Santa Clara, California)의 데이터센터 사진을 일부 제공했었다.
* A Glimpse Inside a Facebook Server Farm - Photo Essays (TIME, 9장의 사진)



* 데이터센터 관련글

- 2009/10/07 - [IT이야기] MS의 시카고 데이터센터 사진 공개
- 2009/04/03 - [IT이야기] 구글 데이터 센터 내부 공개, 그 안을 들여다보자
- 2009/04/10 - [IT이야기] 구글, 구글 서버와 데이터센터 발표자료를 풀 동영상으로 공개
- 구글 데이터센터의 놀라운 전력 효율 (2009.10.27, 커피닉스)
- 애플 신규 데이터센터 (2009.7.16, 커피닉스)
- 애플 신규 데이터센터 (2009.8.14, 커피닉스)
- 터키 이스탄불의 Vodafone 데이터센터, 폭우로 물에 잠겨 (2009.9.16, 커피닉스)

* 서버대수 관련글

- 2010/06/30 - [IT이야기] 페이스북(Facebook)의 서버 대수는 6만대 이상? (서버대수와 데이터센터)
- 2009/06/01 - [IT이야기] 해외 주요 업체의 서버 대수는?
- Facebook 사용자 4억명 돌파, 그리고 서버수 (2010.2.12, 커피닉스)

* 사진

- Solar-powered Facebook Data Center (2011.4.16, 페이스북 태양광 발전시설)
- Inside Facebook’s Not-So-Secret New Data Center (2011.4.7, 페이스북 데이터센터 사진 9장)

Posted by 좋은진호
시스템이야기2011. 4. 8. 13:06
Splunk(스플렁크) 솔루션은 '이런 솔루션이다'라고 하나의 명칭으로 정의하기가 쉽지않다. 그만큼 다양한 기능을 갖고 있고, 활용분야도 넓기 때문이다. 데이터(로그 등) 수집 & 실시간 검색부터 데이터 분석, 모니터링 등에 활용할 수 있는 솔루션으로 생각하면 될 것 같다.

splunk


Splunk는 어떤 기능을 가졌는가?
  • 로그 등 다양한 형태의 데이터를 수집할 수 있다. 데이터 포맷은 따지지 않는다. syslog, 네트웍 장비에서 보내주는 데이터, mail 로그, 오픈소스 IDS인 snort 로그, 웹로그, Nagios, squid, bind, Netflow,  Windows의 이벤트 로그 등 다양하다. 또한 포맷에 상관없이 운영자가 필요시 원하는 데이터를 수집할 수 있다. w, uptime, free등의 명령의 결과를 수집할 수도 있다는 얘기다.
  • 수집된 데이터를 검색할 수 있다.

splunk search

[ Splunk의 검색창 ]


  • 다양한 검색어를 지원한다. (정말 많다. ^^ : Search Reference Manual )
  • 검색된 결과를 그래프 또는 도표로 볼 수 있다. (보고서 기능)
  • 그래프, 도표들을 모아서 한페이지에서 모니터링을 할 수 있다. (대시보드)
  • 제공되는 다양한 apps를 설치할 수 있다. Splunk를 하나의 플랫폼으로 생각하면 된다. iOS,안드로이드가 하나의 플랫폼이고, 거기에 apps를 설치하는 것처럼.
  • 검색어를 지정해두고, 실시간 데이터에서 이 것을 찾게되면 alert되도록 설정을 할 수 있다. (error 로그가 검색되면 alert되도록 하면 좋다.)
  • 실시간으로 로그를 볼 수 있다. (쉘에서 tail -f 한 것처럼)
  • 시간지정이 가능하다. (최근 몇분에서 몇시간, 전체, 또는 특정일부터 특정일까지 등 다양하다.)
  • 한글화가 되어 있다.
2달동안 무료로 사용할 수 있는 버전을 Splunk 사이트( http://www.splunk.com/ )에서 받을 수 있다. 1일 500MB 데이터로 제한되어 있다. 설치와 Splunk 실행은 설명할 필요도 없이 간단하다.

Splunk 개략적 이용 과정은 이렇다.

데이터 수집 → 검색 유용한 필드 추출 보고서 작성 대시보드 생성

1. 어떠한 데이터를 수집할 것인지를 설정한다. (데이터 추가하기)
2. 수집된 데이터를 검색해본다.

이단계까지는 누구나 쉽게 할 수 있다. 여기까지만 이용하면 데이터 수집과 검색 용도로만 사용하게 되는 것이다. 이제부터 중요하다.

3. 의미있는 보고서(그래프나 도표)를 만들기 위해서는 수집된 데이터의 포맷을 파악해야 한다.
   이를 테면 네트웍 로그중에서 어떤 source IP를 많이 차단했는지, 어떤 프로토콜(TCP, UDP, ICMP 등) 비율이 많은지를 알고 싶다고 하자.
   로그 중에 Source IP가 있는 위치와 프로토콜이 있는 필드를 알아야 한다.
4. 로그 포맷을 파악하고, 정규식을 사용하여 필드 패턴을 추출한다. 추출한 패턴을 저장한다.
   정규식을 몰라도 필드 추출을 할 수 있도록 똑똑하게 만들어놨다. 그렇지만 정규식을 알면, 보다 정확하고 유연하게 적용이 가능하다. 
5. 이제 어떤 데이터를 통계화하여 볼 것인지 조건문(검색어)을 만들면 된다. 예를 들면 다음 처럼.

   host="network" denied | top ACL_denied_icmp limit=20 또는
   host="network" denied | top 20 ACL_denied_icmp

   로그 중에 denied 단어를 검색하고, 검색 결과에서 ACL_denied_icmp필드를 기준으로 상위 20개를 보여달라는 뜻이다.

splunk search

[ 검색어를 입력하여 통계화할 때(윗부분), 왼쪽 필드를 클릭했을 때(아래부분) ]

   위의 조건문을 모르더라도 통계화하는 방법을 제공한다. 얼마나 좋은가? 검색창 왼쪽 하단에 '선택된 필드'항목을 클릭하면 TOP 10조건을 보여준다.

6. 검색 결과를 보고서로 만든다. ('보고서 보기')
   이 때 보고서는 다양한 형태의 그래프 모양과 도표 등으로 표시를 할 수 있다.
7. 여러 검색 조건을 저장해두고 이를 모아서 대쉬보드를 만든다.

splunk dashboard

[ 트래픽 차단 대시보드의 일부분 (네트웍 장비(방화벽 등)에서 받은 데이터를 활용) ]



splunk dashboard

[ ID별 ssh login 대시보드 일부분 (syslog를 통해 받은 로그를 활용) ]


어느 정도 사용하다보면, 본인이 직접 apps를 만들 수 있을 것이다. 그리고 필드명, 검색어명, 대쉬보드명 등의 네이밍 요령도 생길 것이다.
XML를 사용하여 더 세세하게 설정할 수도 있을 것이다.

운영하면서 느낀 몇가지를 적는다.

  • 데이터가 많으면 속도가 느려졌다. '빠르다'라는 말만 강조하던 Splunk이지만, '빠르지만 느려지기도 하다'로 이해하면 될 것 같다.
  • 검색 대상시간은 전체보다는 1일, 7일, 4시간 등 특정 시간으로 제한하는게 효과적이다.
  • 웹로그를 수집하지는 말자. 한두대의 서버의 로그만 샘플링으로 수집한다고 하더라도 엄청난 양이 된다.  Splunk가 다른 일을 할 수 있도록 힘을 빼지 않는게 좋을 것이다. 웹로그 분석은 전용 서비스나 솔루션을 이용하는게 낫다.
  • SNMP로 데이터를 가져오는 부분이 보이지 않는다. (모르는 건가 없는건가)
  • 쉘에서도 검색할 수 있다.
  (예) ./splunk search '검색어' -auth (처음 한번은 인증과정이 필요해서 -auth사용)
  이를 활용하면 특정 조건(error 또는 지정한 임계치)이 발생하면 스크립트를 호출할 수 있다.
  또는 주기적으로 특정 검색 결과를 .txt(csv)로 저장할 수도 있다.

  #!/bin/bash
  CURR=`date +'%Y_%m%d_%H'`

  cd $SPLUNK_HOME/bin
  ./splunk search "denied udp | top ACL_denied_udp limit=10 | outputcsv denied_UDP_${CURR}" -auth

  $SPLUNK_HOME/var/run/splunk/ 경로에 denied_UDP_YYYY_MM_DD_HH.csv로 저장된다.

2개 업체('유섹'과 보안업체 출신이 세운 업체)에서 매달 무료 교육을 실시한다고 들었다. 들어보질 않아서 어떤 것을 교육하는지는 모르지만, 관심있으신 분은 신청해보시는 것도...

몇주간 사용중인데, Splunk는 굉장한 물건인 건 확실히다. Splunk를 포크레인으로 만들것이나 삽으로, 또는 숟가락 정도로 만들 것이냐는 엔지니어의 능력에 달렸다.

Posted by 좋은진호
IT이야기2011. 3. 24. 21:20

그 때는 검색봇 이름이 'pirs'과 'pirst'였다. 그런데, 3일전에 'first'로 비슷하게 이름이 바뀌어서 접속을 했다. 기존에 User-Agent명으로 차단을 시켜두었다. 하지만, 이를 비켜간 'first'는 마구 긁어가기 시작했다. 몇 시간뒤에 차단 조치를 취하고(개인정보를 취급하지 않는 사이트임), 얼마동안 페이지를 긁어가는지 확인했다. 48시간 가까이 긁어갔다. 포털, 구글의 봇보다 무섭다.

  • 사이트 운영자들은 봇이름으로 차단하는 경우가 많다. 그런데, 이름을 바꾸면 문제가 있지 않겠는가? 예를 들어 구글이나 네이버, 다음의 봇 이름이 바뀐다고 생각해봐라.
  • 여전히 robots.txt는 읽지 않았다. KISA의 공지와는 다르게 검색 규칙을 따르지 않는 것이다.
  • 과거에 긁어간 적이 있는 사이트는 페이지 목록이 DB화되어 있는 건가? 차단을 해도 여전히 여러 페이지를 읽어갔다.
  • referer는 http://www.pirst.kr:6600/RS/PIRST_FAQ.jsp 로 남았다.
  • IP대역은 61.111.15.110~61.111.15.119까지 총 10개이다. 이전의 IP 대역과 비슷하고, 검색 서버의 대수는 동일했다. KISA 모니터링 시스템에 대해서는 'KISA의 '개인정보 모니터링 시스템'에서 확인할 수 있다.

[ referer에 남겨진 http://www.pirst.kr:6600/RS/PIRST_FAQ.jsp 페이지의 공지 내용 ]


사이트 운영자에게 대상 사이트임을 먼저 알리는게 우선이지, 먼저 긁어가고 불편하면 메일로 문의를 하라는 것은 순서가 바뀌것 아닌가? 요즘 개인정보노출에 대한 문제가 많다. 그래서 KISA의 취지를 이해하고, 취지도 좋다고 본다. 하지만, 좋지 않은 인상을 남기는 안타까운 순간이다.
Posted by 좋은진호
시스템이야기2011. 3. 17. 18:57

rsync


rsync는 크게 2가지 용도를 생각해볼 수 있다.

1) 파일 백업 (퍼미션 유지 필요. 백업본으로 복구할 경우 퍼미션도 중요하다.)
2) 파일 배포 (반드시 퍼미션을 유지하지 안해도 될 상황이 있다.)

rsync를 이용해서 다수의 서버를 동기화한다고 하자. 그리고, 대상 서버는 웹서버들이다. (즉, '파일 배포' 용도) 이 웹페이지 파일은 웹에서 읽을 수 있는 권한만 갖으면 된다. 쓰기 권한을 갖을 필요가 없다. (업로드가 이뤄지는 디렉토리는 쓰기 권한이 필요하겠지만)

rsync는 원본 파일(또는 디렉토리) 퍼미션과 상관없이, 싱크할 때 특정한 퍼미션으로 고정시키는 옵션이 있다. 디렉토리는 555(dr-xr-xr-x) 또는 515(dr-x--xr-x)으로, 파일은 444(-r--r--r--)로 고정해볼 수 있을 것이다. 서비스 서버(대상 서버)의 파일은 보안에 조금 더 안전하게 존재하게 된다.

(예)
-------------    ---------------
 원본 서버          대상 서버
192.168.1.123    192.168.1.110~120
-------------    ---------------
drwxr-xr-x    ->   dr-xr-xr-x
drwxrwxr-x    ->   dr-xr-xr-x
-rw-r--r--    ->   -r--r--r--
-rw-rw-rw-    ->   -r--r--r--
-------------    ---------------

대상 서버의 rsyncd.conf 예이다.

# server : 192.168.1.110
#
uid             = root
gid             = root
user chroot     = yes
max connections    = 10
hosts allow    = 192.168.1.123

[coffeenix]
path        = /home/coffeenix/public_html
read only    = no
incoming chmod  = Du=rx,Dgo=rx,Fugo=r

'incoming chmod =' 파라미터는 들어오는 파일을 특정 퍼미션으로 고정한다.
파라미터의 값은 각각 다음과 같은 의미를 갖는다.

- D : 디렉토리
- F : 파일
- ugo : 각각 user(u), group(g), other(o)에 해당한다.


[ 기본적인 파일 보호 장치인 chmod (열쇠찾아서 그리는데 쉽지 않았다. ^^) ]


위의 Du=rx,Dgo=rx,Fugo=r 는 Dugo=rx,Fugo=r처럼 통합해서 표시해도 좋다.
Du=rx는 디렉토리 소유자는 r-x(읽기, 쓰기)로 설정한다는 의미이다.
Fugo=r은 누구나(user, group, other) 파일을 읽을 수 있도록(r--)로 설정한다.
위 설정대로하면 디렉토리는 r-xr-xr-x 가 되고, 파일은 r--r--r--가 된다.

# rsync -avz --delete public_html/ 192.168.1.110::coffeenix/

보다 자세한 글은 커피닉스에 써뒀으니 살펴보시길.

Posted by 좋은진호
IT이야기2011. 2. 1. 09:01
이집트 민주화시위로 인해 이집트 정부는 인터넷을 차단했다.


집권세력들이 자기 잘 못은 생각하지 않고, 국민의 입을 막겠다? 표현의 자유를 없애겠다? 온라인상으로 표현할 공간이 없을수록, 국민들에게 남은 선택은 한가지 밖에 없다. 더 격렬하게 시위하여 자신들의 의사를 표현하는 것 뿐이다.
집권세력은 더욱 힘을 잃고 있다. 내부적으로는 국민들의 격렬한 저항을 받아야 한다. 외부적으로는 다른 국가들의 압박을 받아야 한다. 전세계 네티즌으로부터는 비난을 받을 것이다. 샌드위치로 눌리는 집권세력들. 그들이 보기엔 사방이 적이다. 그러나 생각해보면 잘못을 뉘우칠 수 있는 희망의 손길이다.

그건 그렇고, 실제 인터넷이 차단되었는지 .eg 도메인으로 접속시도를 해봤다. 아~ 접속이 되지 않았다. ㅠ.ㅠ

1. 구글에서 site:gov.eg 를 검색해서 적당한 도메인을 고른다.
2. 그 후 dig으로 lookup해보면 도메인을 찾지 못한다. 물론 사이트 접속도 안된다.

$ dig nosi.gov.eg

; <<>> DiG 9.7.1-P2 <<>> nosi.gov.eg
;; global options: +cmd
;; connection timed out; no servers could be reached

$ dig nosi.gov.eg +trace

; <<>> DiG 9.7.1-P2 <<>> nosi.gov.eg +trace
;; global options: +cmd
.            349239    IN    NS    c.root-servers.net.
.            349239    IN    NS    a.root-servers.net.
.            349239    IN    NS    i.root-servers.net.
.            349239    IN    NS    d.root-servers.net.
.            349239    IN    NS    f.root-servers.net.
.            349239    IN    NS    h.root-servers.net.
.            349239    IN    NS    j.root-servers.net.
.            349239    IN    NS    g.root-servers.net.
.            349239    IN    NS    b.root-servers.net.
.            349239    IN    NS    k.root-servers.net.
.            349239    IN    NS    e.root-servers.net.
.            349239    IN    NS    m.root-servers.net.
.            349239    IN    NS    l.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 137 ms

eg.            172800    IN    NS    ns5.univie.ac.at.
eg.            172800    IN    NS    frcu.eun.eg.
eg.            172800    IN    NS    rip.psg.com.
;; Received 183 bytes from 192.228.79.201#53(b.root-servers.net) in 215 ms

nosi.gov.eg.        86400    IN    NS    NS2.STARNET.COM.eg.
nosi.gov.eg.        86400    IN    NS    NS1.RAYATELECOM.COM.
;; Received 92 bytes from 147.28.0.39#53(rip.psg.com) in 224 ms

;; connection timed out; no servers could be reached

$ dig eeaa.gov.eg +trace

; <<>> DiG 9.7.1-P2 <<>> eeaa.gov.eg +trace
;; global options: +cmd
.            349523    IN    NS    j.root-servers.net.
.            349523    IN    NS    l.root-servers.net.
.            349523    IN    NS    k.root-servers.net.
.            349523    IN    NS    i.root-servers.net.
.            349523    IN    NS    d.root-servers.net.
.            349523    IN    NS    a.root-servers.net.
.            349523    IN    NS    f.root-servers.net.
.            349523    IN    NS    e.root-servers.net.
.            349523    IN    NS    b.root-servers.net.
.            349523    IN    NS    m.root-servers.net.
.            349523    IN    NS    h.root-servers.net.
.            349523    IN    NS    c.root-servers.net.
.            349523    IN    NS    g.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 129 ms

eg.            172800    IN    NS    frcu.eun.eg.
eg.            172800    IN    NS    ns5.univie.ac.at.
eg.            172800    IN    NS    rip.psg.com.
;; Received 183 bytes from 128.8.10.90#53(d.root-servers.net) in 272 ms

gov.eg.            86400    IN    NS    NS.IDSC.gov.eg.
gov.eg.            86400    IN    NS    FRCU.EUN.eg.
gov.eg.            86400    IN    NS    RIP.PSG.COM.
;; Received 131 bytes from 193.171.255.77#53(ns5.univie.ac.at) in 319 ms

eeaa.gov.eg.        86400    IN    NS    NS1.TEDATA.NET.
eeaa.gov.eg.        86400    IN    NS    NS2.TEDATA.NET.
;; Received 75 bytes from 147.28.0.39#53(RIP.PSG.COM) in 214 ms

;; connection timed out; no servers could be reached


Posted by 좋은진호
IT이야기2011. 1. 20. 22:48
DDoS공격은 꾸준했지만, 최근 12월과 1월에 DDoS 공격량이 증가하고, 공격도 심해졌다는 얘기를 한다.

최근 몇몇 업체가 DDos공격을 받았다. 이들 업체도 DDoS 공격 피해자인데, 고객들에게 그것도 못 막냐~라는 얘기를 듣게 되고, 고객에게 미안한 마음까지 생긴다. 하지만 이들 업체가 노력하지 않아서 못 막는게 아니다. 차단위한 인프라 구축에도 한계가 있다. 만약 50G, 아니 100G가 들어온다면 일반적인 국내 환경에서 이 트래픽을 감당할 인프라를 갖춘 곳이 얼마나 되겠는가.

1. 폭우가 쏟아져 상류댐에서 대량의 물을 방류하게 되면 하류에서는 대비를 하더라도 피해를 입을 수밖에 없다.

이런 경우 해결할 방법은 상류댐(IDC나 연동망 등)에서 물길을 막아주는 것 밖에 없다.(이를 IP null routing이라고 한다. 공격받는 IP로 들어오는 트래픽을 상단에서 버리는 것이다.) 그러나 이 댐은 특이해서 물을 한방울도 흘러보내지 않거나 대량의 물을 그대로 방류하거나 둘중 하나만 선택할 수 있다. 어쩔 수 없이 물을 한방울도 흘러보내지 않는 것을 선택하게 된다. 대량의 물은 막았지만 식수난을 겪게 된다. (IP null routing을 하게 되면 공격 트래픽은 막아지지만 해당 IP로는 서비스를 할 수 없다. 인프라는 보호했지만 서비스는 못하는 현실)

DDoS

[ 이미지 출처 : 구글 이미지 검색 -> make.to ]


※ DDoS공격 유형은 여러가지가 있는데, 위는 UDP유형으로 대역폭을 초과하는 공격을 예로 든 것이다.
※ DDoS공격은 유형에 따라 차단할 수 있다. 그리고, 인프라를 초과하더라도 상단과의 협조와 내부 DDos방어장비를 이용해 단계별 처리로 피해를 줄일 수 있다. 먼저 DDoS방어장비 구축과 인프라 개선은 해야하는 것은 당연하다.


2. 최근 공격량이 증가했다는 것은 좀비 PC가 늘었다는 이야기가 된다. '선' 좀비 PC 구축 -> '후' DDoS공격의 형태이기 때문이다.

'하우리의 맞춤전용백신 목록'에서도 Trojan/DDoSAgent 전용백신이 작년 11월부터 증가했다. 좀비 PC도 늘어 났다는 것이다.
인터넷침해대응센터(KRCERT)의 보안공지( http://www.krcert.or.kr/ )를 보면 12월말부터 국내 주요 오픈소스 게시판의 취약점이 줄줄이 발표되었다. (당시 대량의 서버에 설치된 제로보드를 자동 패치하느라 고생한 커피닉스 분이 생각난다. ^^) 이들 3개 게시판이면 국내 공개 게시판의 대부분을 커버한다고 보면 된다.
취약점을 이용해 악성코드만 심으면, 공장에서 찍어내듯 좀비 PC를 만들 수 있는 대량 양산 체제를 구축한 것이다. 밤낮이 필요없는 24시간 양산 체제. 게시판 사용하는 사이트는 널려있으니, 악의적인 사람 입장에서는 원감절감(노력절감) 체제. 우리 나라 좀비 PC들은 네트웍도 빵빵하고, 성능은 날아다닌다. 그만큼 막강한 공격력을 자랑(?)하게 된다.

[ 인터넷침해대응센터(KRCERT)의 보안공지 ]


* 국내 공개 웹 게시판(제로보드) 취약점 주의 (2010/12/21)

  o 국내 PHP 기반의 공개 웹 게시판 제로보드에서 XSS, CSRF 및 RFI 취약점이 발견됨[1, 2]
  o 해당 취약점을 이용한 홈페이지 변조 및 원격 실행 위협이 발생함에 따라, 취약한 버전 사용자의 주의 및 조속한 패치가 요구됨

* 국내 공개 웹 게시판(테크노트) 취약점 주의 (2011/01/06)

  o 국내 PHP기반의 공개 웹 게시판인 테크노트에서 SQL인젝션 취약점이 발견됨 [1]
  o 취약한 버전을 사용하고 있을 경우, 홈페이지 해킹에 의한 내부정보(개인정보 등)유출 등의 피해를 입을 수 있으므로 웹 관리자의 적극적인 조치 필요

* 국내 공개 웹 게시판(그누보드) 취약점 주의 (2011/01/07)

  o 국내 PHP기반의 공개 웹 게시판인 그누보드에서 XSS, CSRF 취약점이 발견됨[1]
  o 취약한 버전을 사용하고 있을 경우, 홈페이지 해킹에 의한 관리자 계정 탈취 및 악성코드 유포지로 악용되는 등의 피해를 입을 수 있으므로 웹 관리자의 적극적인 조치 필요

게시판 취약점 이용한 악성코드 심기, 유명사이트 해킹으로 악성코드 심기, 웹브라우저의 zeroday취약점 등으로 좀비 PC 양산체제 구축은 꾸준할 것이다. DDoS공격 증가와 좀비 PC 양산체제 여건 마련은 무관하지 않다.

PC점검 철저히 하시라. 그리고 IE에만 의존하지 말고, 파이어폭스나 크롬 등도 이용하시라.
내가 이용자이면서 그들에게 공격자일 수도 있다. 누구를 욕할 처지가 아닐 수 있다.
Posted by 좋은진호
IT이야기2010. 12. 16. 21:31
아마존(Amazon)은 고객이 필요한 만큼의 자원만 할당 받아 서버를 이용할 수 있는 아마존 웹서비스(Amazon Web Services, AWS)중 EC2(Amazon Elastic Compute Cloud) 서비스를 제공한다. 클라우드 컴퓨팅 시스템을 이야기할 때 절대 빠질 수 없는 대표적 클라우드 서비스이다.

amazon AWS

아마존 EC2가 무엇인지 들어본적이 없다면, 뷔페를 생각하면 이해가 쉬울 것 같다. 먹을 만큼만 먹고, 필요하면 쉽게 더 덜어먹을 수 있는 뷔페. EC2는 필요한 만큼 서버 자원을 할당받고, 더 필요시 비용을 지불하면 쉽게 자원을 더 할당받아 늘릴 수 있다. 위키리크스(WikiLeaks)도 아마존에서 쫓겨나기 전까지는 EC2 서비스를 이용했었다.

이 서비스를 위해 구성된 아마존의 EC2 Cluster가 세계 슈퍼컴 TOP 500중에서 231위를 차지(2010년 11월 발표기준)했다.

[ 세계 슈퍼컴 TOP 500 중 Amazon EC2 Cluster 순위(2010년 11월) ]


  • 시스템명 : Amazon EC2 Cluster Compute Instances - Amazon EC2 Cluster
  • 환경 : Xeon X5570 2.95 Ghz, 10G Ethernet
  • 프로세서 : 7040 cores
  • 성능 : 41.82 teraflops

이 클러스터는 총 880대로 구성되었다. 위에 표시된 Xeon X5570 CPU는 네할렘(Nehalem) 쿼드코어(Quad Core) CPU이다. 그래서, 위에 표시된 총 코어수는 다음과 같이 계산이 된다.

4 cores(Xeon X5570) X 서버당 CPU 2개 X 880대 = 7040 cores

Amazon EC2 Cluster가 2010년 6월 순위에는 포함되어 있지 않지만, 성능을 그 때 기준과 비교하면 슈퍼컴 TOP 500 중 146위정도였다.

[ 2010년 6월 세계 슈퍼컴 TOP 500 ]


우리가 사용하는 일반 웹서비스가 슈퍼컴 500위 안에 들다니? 클라우드 컴퓨팅 시대에는 누구나 슈퍼컴의 일부를 할당받아 쓰는 시대가 되었다.

Posted by 좋은진호
IT이야기2010. 12. 7. 18:34
구글 캘린더에서는 정상적으로 보인다. 하지만 캘린더 공유용 웹페이지에서는 비정상적으로 날짜가 당겨서 보인다. 지난주부터 문제가 생긴 것 같다. OS와 브라우저별로 확인한 결과, 리눅스 파이어폭스에서만 날짜가 당겨져 보였다.

  • Windows IE8, 파이어폭스, 크롬, 사파리에서 정상 표시
  • 리눅스 오페라에서 정상 표시
  • 리눅스 파이어폭스(3.6.x)에서 비정상 표시

[ 정상적으로 보이는 구글 캘린더 ]



[ 웹공유 페이지에서 날짜가 당겨져서 보이는 구글 캘린더 ]


IT일정 공유하는 커피닉스'캔커피'( http://can.coffeenix.net/ )에서 살펴본 것이다. EMC Effect Day는 12월 9일, Wine 1.2.2 Released는 12월 3일로 표시되어야 맞다. 하지만 모두 이틀씩 당겨서 보인다.

Posted by 좋은진호