아파치 웹서버에는 UseCanonicalName 이라는 옵션이 있다. 이 옵션은 CGI나 php등에 SERVER_NAME과 SERVER_PORT변수값을 넘길 때, 어떤값을 넘길 것인지 결정한다. On으로 설정되어 있을 경우는 아파치의 ServerName으로 지정한 값이 넘겨지고, Off로 설정되어 있을 경우는 클라이언트가 요청한 호스트명과 포트명이 넘겨진다.

이런 경우를 가정해보자. www.coffeenix.net 로 서비스되는 서버가 5대라고 하고, 각 5대의 서버는 w101~w105.coffeenix.net 이름을 갖고 있다.


위처럼 설정되어 있을 때 On과 Off의 차이를 확인홰보자. 유저가 브라우저에서 w101.coff...를 요청했을 때이다.

다음은 On으로 설정한 경우이며, ServerName에 설정된 호스트명이 출력된다.
Off으로 설정한 경우이며, 브라우저에서 요청한 호스트명이 출력된다.

UseCanonicalName 옵션은 아피치 1.3에선 기본값이 On으로, 2.x대(2.0, 2.2)는 Off로 되어 있다. 기본값의 차이가 있으니 반드시 ServerName에서 지정한 호스트명이 나와야할 경우 주의가 필요하다. 다음은 아파치 웹서버의 httpd.conf 일부다.

[ 아파치 1.3.x의 httpd.conf ]

[ 아파치 2.2.x의 httpd-default.conf ]

.html이나 .js 등의 파일들을 전송할 때 압축해서 보낸다면, 웹페이지 접속시에 약간의 전송속도 향상을 가져올 수 있을 것이다. 요즘 워낙 회선속도가 좋아 그 영향이 미비할 수도 있지만. 주요 포털들과 랭킹 상위 사이트 몇개를 대상으로 gzip 압축 전송을 지원하는지를 체크해봤다. 메인페이지를 기준으로 확인해봤으며, 메인페이지 접속시에 함께 요청되는 페이지도 체크에 포함했다.

gzip 압축 전송 지원여부 체크는 초기에는 직접 Request 헤더에 'Accept-Encoding: gzip, deflate'를 포함해서 만들어 보내고, Response 헤더에 'Content-Encoding: gzip'가 포함되어 있는지를 파악했다. 그러나 정확도가 떨어진데다가 한 페이지에 .css, .js등 여러 request가 있는 경우까지 체크하기 위해서 Fiddler툴을 이용해서 결과를 정리했다.


gzip을 지원하는 사이트들이다.

1. 다음( www.daum.net )
   .html 파일의 gzip 압축 전송을 지원했으며, top-sc.daum.net 의 .js 파일과 top-sc.daum-img.net 의 .xml 파일도 지원한다.

2. 네이버( www.naver.com )
   20bytes의 작은 사이즈도 gzip 압축했으며, .js, .css 파일은 사이즈에 무관하게 압축을 하지 않았다.
   auto.naver.com의 .html 파일, .js 파일, .css 파일의 gzip 압축 전송 지원

3. 네이트( www.nate.com )
   .html 파일, .js 파일, .ico 파일의 gzip 압축 전송을 지원한다. 특이하게 .ico까지 한다. 아니, 일반적인 이미지파일을 제외하고는 확장자에 무관하게 gzip을 지원하는 것일 수도 있다. 300bytes대의 사이즈도 gzip 압축을 했다. 메인페이지의 최소사이즈 파일이 300bytes였으며, 이보다 작은 사이즈의 파일이 있었으면 압축을 지원했을 수 있다. 적용범위를 폭넓게 생각하면, 파일확장자와 사이즈에 무관하게 압축할 가능성이 있다.
   .css파일은 존재하지 않아 gzip 압축 전송 여부 확인할 수 없었다.
   
4. 야후! 코리아( kr.yahoo.com )
   .html 파일의 gzip 압축을 지원한다. .js와 .css는 img.yahoo.co.kr 이미지 웹서버에 존재하는데 .js, .css 파일의 압축을 지원한다.
   adz.kr.yahoo.com 요청 중에 .js 파일의 압축을 지원한다.

5. 싸이월드( www.cyworld.com )
   .asp(.html), .js 파일의 gzip 압축을 지원한다. 31bytes의 작은 사이즈도 압축했으므로, 사이즈 상관없이 압축한다는 의미일 것이다.
   .css는 압축 지원을 하지 않았다.

6. 구글( www.google.co.kr )
   .html, .js, .css 파일의 gzip 압축 전송을 지원한다.

7. Live Search( www.live.com )
   .html 파일의 gzip 압축 전송을 지원한다.

8. MSN Korea( kr.msn.com )
   .html 파일의 gzip 압축 전송을 지원한다.
   stckr.msn.com의 .css 파일, stjkr.msn.com 의 .js 파일의 gzip 압축을 지원하며,
   특이하게도 ads1.msn.com의 js 파일과 stj.msn.com의 .js 파일은 deflate 압축을 지원한다. 아마도 'Footprint 4.2/FPMCP' 캐싱 서버 때문일 것 같다.

위 사이트를 확장자별로 지원 여부를 표시했다.


다음은 지원하지 않는 사이트이다.

엠파스( www.empas.com ), 파란닷컴( www.paran.com ), 드림위즈( www.dreamwiz.com )

MaxMind의 GeoIP 데이터와 GeoIP apache 모듈을 사용하여, 아파치의 웹로그에 국가코드를 남겨보자.

1. GeoIP C API 설치한다.
2. 그리고, Apache mod_geoip2 모듈을 설치한다. (apache 2.x 기준임)

apache 모듈이 설치된 상태에서 phpinfo() 를 살펴보면, Apache Environment 부분에서 GEOIP_CONTINENT_CODE, GEOIP_COUNTRY_CODE, GEOIP_COUNTRY_NAME환경 변수를 볼 수 있다.
이중에서 GEOIP_COUNTRY_CODE 변수값을 로그에 남기면 된다.



위에서 %{변수명}i 형식은 Header중 해당 변수값을 말한다. %{변수명}e 는 환경변수를 의미한다.

%{Host}i : 요청한 호스트명을 로그에 남긴다. 이를테면 하나의 서버에 2개 이상의 도메인을 갖고 있을 때 유용하다.  www.foobar.com, www.foobar.net, foobar.com 등의 도메인이 있을 때 어떤 도메인으로 요청했는지를 남길 수 있게 된다.
%{GEOIP_COUNTRY_CODE}e : GEOIP_COUNTRY_CODE 환경변수, 즉 국가코드를 남긴다.

로그는 다음과 같이 남는다.


자세한 것은 커피닉스의 'GeoIP 활용(아파치 웹로그에 국가코드 남기기 외)' 에 정리해뒀다.

FreeBSD 7.0의 사용기 몇가지를 적어보겠다.

1. make buildworld 시간 : 1시간 2분 (FreeBSD 6.x대와 별반 차이 없음)

2. 차세대 전송 프로토콜인 SCTP를 사용하기 위해서는 커널에서 INET, INET6 모두 define되어 있어야 한다. INET6을 define하지 않고 커널 컴파일을 하면 에러가 발생한다. ( /usr/src/sys/conf/NOTES )

'INET, INET6가 모두 정의되어 있어야 한다. V6를 enable할 필요는 없다. 그러나 SCTP가 dual stack으로 되어 있어서 지금까지 우리는 V6과 V4를 별도로 분리하지(teased apart) 않았다. (dual-stacked라 분리할 필요가 없었다는 의미) 왜냐하면 SCTP 커넥션(association)은 V6과 V4주소가 동시에 펼쳐지기(span) 때문이다.'

SCTP 에서는 커넥션을 association라고 부르므로, 위의 문장중 'association'은 커넥션으로 이해하면 된다.

3.  TCP 디버깅 로그가 이전 보다 자세하다.

1) 6.x 버전
2) 7 버전
    그리고, Connection attempt 외에 또다른 로그.

4. ZFS 파일시스템

/boot/loader.conf 에 다음과 같이 설정하고 리부팅하면, XFS와 ZFS 파일시스템을 사용할 수 있다.

kldstat로 동적링크된 커널모듈(.ko) 목록을 확인해보자.

ZFS 사용을 위한 준비는 완료됐다. zfs, zpool 등의 명령으로 ZFS 파일시스템을 만들고 확인해본다.

ZFS와 UFS간의 성능테스트와 그 이외의 응용프로그램 등의 성능은 추후 테스트를 해볼 것이다.
덧붙여서 FreeBSD 7 리뷰글과 Live CD로 설치하는 화면을 'Review of FreeBSD 7'에서 볼 수 있다.

※ 시스템 환경 : Dell 1950, CPU 5310 X 2개, 2G 메모리, SAS, No RAID

http://www.freebsd.org/releases/7.0R/announce.html
http://www.freebsd.org/releases/7.0R/relnotes.html

• 가장 눈에 띄는 것은 릴리즈 페이지에도 나와 있듯이 드라마틱할 정도로 놀라운 성능향상이다.

• 실험적이긴 하지만 ZFS 지원. XFS 읽기 기능 가능

• 저널링(journaling) 지원 (gjournal 툴을 통해서 저널링 설정) (FreeBSD 6.3에도 포함하려고 했으나 다음버전에서 지원될 듯)
  

• 차세대 TCP라 불리는 SCTP(Stream Control Transmission Protocol) 프로토콜 지원

          SCTP는 TCP, UDP처럼 전송프로토콜로, 이 둘의 프로토콜이 제공하지 않는 멀티스트리밍과 멀티 호밍(multi homing)을 지원한다. 또한 HTTP 프로토콜에서 전송시 SCTP를 이용한다면 속도를 향상시킬 수 있다.  참고로 SCTP는 Linux kernel 2.6.x에서도 지원하며, 관련툴인 lksctp를 sourceforge에서 받을 수 있다.
          TCP, UDP, SCTP가 전송프로토콜로 같이 공존하다가 미래에 SCTP이 보편화되는 시점이 다가올 것으로 보인다.  이 때 UDP를 대체할 정도로 보편성을 갖게 된다면, 개인적인 생각으론 UDP flooding을 통한 공격은 해결될 시점이 다가올 수도 있다.

• OpenBSD/NetBSD에서 가져온 네트웍 링크 aggregation과 failover를 위한 인터페이스인 lagg 지원 (FreeBSD 6.3에도 포함됨)

나머지 자세한 내용이나 포함된 프로그램의 버전 정보등에 대해서는 릴리즈 정보를 살펴보기 바란다.

* Down 1 : ftp://ftp.kaist.ac.kr/FreeBSD/ISO-IMAGES-i386/7.0/ (ftp.kr.freebsd.org는 글 쓰는 현재 미러링이 안되어 있음)
* Down 2 : ftp://ftp.jp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/7.0/

리눅스 커널 2.6.17부터 2.26.24.1 까지의 vmsplice() 콜의 버그로 로컬에서 root 권한을 획득할 수 있다. KLDP에도 나와있듯이, milw0rm에는 2개의 local root exploit 코드가 공개되어 있다. 테스트결과 너무 쉽게 root 권한이 획득되었다.


개인사용자나 외부 접근이 제한된 시스템은 그나마 다행인데, 커널 2.6.x을 사용하는 호스팅업체나 공동 사용 서버는 빨리 대처해야할 것이다. 커널 패치를 적용하여 리부팅을 해야할 것이나 재부팅할 수 없는 서버도 있을 것이다. 이 땐 임시 메모리 패치와 hkpco님의 방어 커널 모듈을 이용하면 된다.

* 관련글


------------------------------------------------------------------
[ 내용 추가 ]

*2.13(수) 현재 RHEL5, Cent5 패치 커널 나옴
http://lists.centos.org/pipermail/centos-announce/2008-February/014684.html
https://rhn.redhat.com/errata/RHSA-2008-0129.html

라드웨어에서 준비한 '2008 Radware DDoS 보안 세미나'에 갔다왔다. 평점을 주면 5점만점에 3점 정도. 사례중심의 발표를 기대했지만, 보편적인 내용으로 흘러갔다. 저와 함께 참석했던 커피닉스( http://coffeenix.net/ )의 나머지 다섯분도 같은 의견이다.

생각난김에 DDoS 공격 유형따라 막을 수 있는지 여부를 정리했다.

국내 DDoS공격이 곳곳에서 터지기 시작한 2007년 초반에만 하더라도, DDoS공격을 막을 수 있느냐, 없느냐의 논의가 몇몇 커뮤니티에서 있었다. 그러나 요즘은 막을 수 없는 공격이 주를 이룬다는 것을 잘 알고 있다.

결론적으로는 회선 대역폭을 공격량보다 많이 확보( 보유한 회선 > 공격량 )해야 공격의 주를 이루는 UDP, ICMP flooding 공격을 버텨낼 수 있는 최소한의 조건을 만족한다. 이 때 네트웍장비의 CPU load 가 낮아야만, 사용자는 불편함없이 서비스를 이용하게 될 것이다. 10G, 20G 이상의 공격량이 많을 경우엔, 다른 고객사에게 피해를 주거나 연동망 장애를 가져올 수 있다. 이럴 경우 IDC나 ISP에서 먼저 차단할 것이다. 즉, 서비스 업체의 인프라만으로는 서비스의 완벽보장은 이뤄내기 힘들다.

UDP, ICMP이외에 공격 유형에 따라, 시스템(네트웍, 서버, 보안장비) 인프라가 되면 막을 수 있는 유형도 있다. Radware 세미나에서 제시한 공격유형 6가지 정도를 갖고 살펴보도록 하겠다.


1. HTTP Flood

  웹페이지를 과다하게 호출하여 서버의 load가 높아지거나 처리가능한 커넥션수를 초과하게 만드는 공격이다.
  '웹페이지 과다 호출 방식의 DDoS공격 사례' (글 좋은진호, 2008.1.23)를 참고하기 바란다.
  IPS, L4스위치의 성능, 웹서버의 설정을 통해서 막아 낼 수 있다.

  1) IPS없고, L4스위치도 없다면.
      몇대 안되는 웹서버를 로드밸런싱하고 있는데, 다량의 공격(세션이 몇만이상)이라면 서버 load가 높아져 서비스가 불가능할 것이다.
  2) IPS없고, 성능 좋은 L4스위치. 그리고 몇 십대의 웹서버를 L4에 물려 서비스 한다면.
      이 때는 '웹페이지 과다 호출 방식의 DDoS공격 사례'에 써진 것처럼 막아 낼 수 있는 방법을 찾을 수 있다.
      그러나 몇 십대에 분산되어 서버가 다 받아드리더라도, 세션이 몇만~몇십만의 공격일 때 L4의 처리한계로 서비스가 느려질 수 있다.
  3) IPS있다면, 웹서버의 설정까지 조합해서 가능

2. SYN Flood, TCP Flag Flood, Half-Open Flood

  방화벽, L4스위치(SYN proxy기능을 갖는 L4. 그러나 SYN proxy기능을 이용하려면 DSR구성 방식은 불가능함), IPS등으로 막아낼 수 있다.

3. UDP Flood, ICMP Flood

  초기에 얘기했던 것처럼 공격량보다 많은 회선을 확보하지 못하면 어떠한 장비를 도입하더라도 막아낼 수 없다.  본인의 백본보다 상위단의 백본을 관리하는 곳(IDC, 호스팅 등)에 요청하여 dest. IP를 차단해달라고 요청해야할 것이다.

  작년 초에는 방화벽, ISP의 장비 업체의 실력있는 엔지니어들도 '우리 장비는 막을 수 있을 것 같다.'라고 얘기하는 경우도 있었다. UDP는 포트가 오픈되어 있지 않더라도 백본까지는 UDP 트래픽이 들어온다는 것(백본에서 UDP를 막았을 때)을 알면서도 저렇게 생각하고 있는 경우가 있었다. 요즘은 국내의 DDoS공격이 주위 사람에게만 뒤져봐도 흔하게 일어나는 안타까운 현실 때문에, 업체에서도 저런 얘기를 하는 경우는 줄었을 것이다.

  참고로 UDP는 주로 80포트와 53(DNS) 포트로 공격하지만 이외에 1024이하의 임의로 포트로 공격하는 경우도 있다.

DDoS 대응 장비로 거론되는 것은 다음 3가지 정도일 것이다.

1. 시스코의 Guard & Detector
   - 대규모 사이트에서 위의 2~3번 유형 대처할 때 적합
   - 초기 훈련을 통해 평상시의 트래픽을 인지하는 방식이라서 1번의 유형을 대처할 수도 있다.
      확인해본 적이 없어서 ^^
   - 1G 장비
   - 어플라이언스 제품과 Catalyst 6500시리지의 모듈형이 있다.
2. 라드웨어의 DefensePro(DP)
   - 대규모 사이트에서 1~3번 유형 대처할 때 적합
   - DP6000의 경우 10G모듈이며, 5~6G정도 공격은 커버 가능
3. 기가핀네트웍스의 Slimline, Flowline
   - 소규모 사이트에서 2번 유형을 대처할 때 적합
   - 약간 두꺼운 책 한 권 크기 정도이며, 가격이 저렴하다.
   - 1G UDP모듈만 제공(역시 소규모 사이트를 위한 제품임을 알 수 있음)했으나
     최근에 Flowline 500-F를 통해 광모듈 지원 장비도 나왔다.

시스코장비나 라드웨어 장비가 3번 유형을 막아준다고 표시해뒀는데, 유해한 UDP를 필터로 걸러내고 하위로 보내준다는 의미이지 보유한 회선을 넘는 공격을 막아낸다는 의미는 아니다.

※ 위의 모든 내용은 공격유형의 이름만 세미나에서 뽑아왔을 뿐이지 세미나 내용과는 전혀 무관하다.

세미나 내용중 흥미있는 슬라이드 2장만 올린다.