시스템이야기2012. 5. 8. 18:25

SSD 스토리지의 필요성은 느끼는데, 아직은 보편화하기에는 가격이 부담스럽다. 하지만 점점 기대된다.
초고성능과 적당한 수준의 용량이 필요하다면 'PCIe'기반의 메모리 스토리지(대표적인게 스티브워즈니악이 CSO로 있는 Fusion-io)가 최적의 조건일 것이고,
고성능과 고용량이 필요하다면 'SSD스토리지'가 최적의 선택일 것 같다.

SSD Impact 2012 세미나[ SSD Impact 2012 세미나 ]


5월 4일 금요일에 있었던 'SSD Impact 2012' 세미나에 참석했다. 여러 개의 부스가 마련되어 있는데, 그중에서 SSD기반의 scale-out NAS 제품을 개발 판매하는 블랙아이옵스(BlackIOPS)를 찾았다.

SSD Impact 2012 세미나장의 블랙아이옵스 부스[ 블랙아이옵스 부스 ]


블랙아이옵스( http://blackiops.com/ )는 올해 처음 들어봤고, 스토리지는 이 날 처음봤다. 이제 막 국내에 런칭되었기 때문에.
블랙아이옵스의 엔지니어(총판 글로벌텔레콤 엔지니어)에게 몇가지 궁금한 사항을 물어보고 간단히 정리했다.

< 기본 >

  • 어플라이언스 장비로 별도의 NFS서버나 CIFS서버 없이 네트웍 스위치나 SAN스위치에 연결해서 사용한다.
  • NFS, CIFS등 지원
  • 리눅스 기반의 다큐OS(DarqOS) 사용. 쉘을 직접 한번 볼 수 있었으면 좋겠다. ^^
  • 24bay 모델은 최초 node 2개부터 초기 구성 가능, 48bay 모델(DM800, DM900모델)은 node 1개만으로 초기 구성 가능
  • HDD + SSD Hybrid 형태는 지원하지 않는다.
    SSD 전용 스토리지. OS는 SSD에 최적화되어 있다.
    앞으로 SSD스토리지 시대가 될 것으로 보고 SSD 전용 스토리지를 출시.
  • SSD는 MLC(Multi Level Cell)방식, SATA3 인터페이스(6Gb/s)
  • 단일볼륨으로 1PB이상 구성 가능
  • 데이터중복제거, 암호화, 압축 지원(DM500, DM600, DM800, DM900모델중 DM600과 DM900이 지원)

블랙아이옵스[ 블랙아이옵스 스토리지. 위 2개는 24bay 모델, 맨아래 1개는 48bay 모델 ]

< 운영 >

  • GUI환경 (세미나장에서는 GUI를 볼 수 없었다.)
  • I/O 모니터링 : GUI에서 실시간 모니터링 가능. 인터페이스별로도 실시간 모니터링 가능
  • SNMP 지원


< 인터페이스 구성 >

  • FC와 이더넷 인터페이스를 '동시'에 사용할 수 있다. 단, 각 인터페이스별로 다른 볼륨을 보게 된다. 동일 볼륨을 보는 것을 권하지 않음.
  • 이더넷 1G 2port를 기본으로, FC 등의 인터페이스 확장해서 사용
  • 8Gb FC포트 X 4개. FC포트 추가 가능(슬롯에 꽂아서 추가하는 방식)

24bay모델은 1개 여분 슬롯 제공, 48bay모델은 2개 여분.
지원 인터페이스는 10G, FC, iSCSI, infiniBand, FCoE

블랙아이옵스[ 블랙아이옵스 스토리지 후면부. 위는 24Bay, 아래는 48Bay 모델 ]

일반 서버처럼 생겨서, 외관은 다소 실망스러웠다. 인터페이스는 슬롯에 꽂아서 추가한다.

블랙아이옵스 8G FC x 4포트[ 8G FC x 4포트 ]


< RAID 및 disk 구성 >

일반 스토리지의 RAID개념과는 다른 구성이다.

1) 1개 node가 하나의 물리적 볼륨
2) 2개 node일 경우 node끼리 미러링 개념
3) 3개 node일 때, 1개 node의 disk 장애시 다른 1개 node로 미러링되어 문제없음. 1개 node에 disk 여러개가 장애나도 서비스 문제없음
4) 3개 node일 때, 2개 node에 1개씩 disk가 장애시 데이터 손실 발생 가능
5) Hot spare disk별도로 필요없음

일반적인 스토리지는 RAID로 볼륨을 만들지만, 블랙아이옵스는 별도의 Hot spare와 RAID없이 구성하여 1개 노드가 1개의 디스크처럼 동작한다. 따라서 3개 노드를 구성한다면 각 1개 노드가 디스크 1개처럼 작동하므로, 디스크 3개를 묶은 RAID5개념으로 이해하면 쉬울 것이다.



Posted by 좋은진호
시스템이야기2012. 1. 11. 18:37
Hash table 충돌을 이용한 DoS 공격(일명 HashDoS)을 해결한 PHP 5.3.9버전이 나왔습니다.
  • php 5.3.8 포함하여 이전 버전 사용중 : 필히 업그레이드 할 것
  • php 5.3.9 RC 또는 5.4.0 RC4~RC5 사용중 : 임시 업그레이드하셨던 분은 필요하면 정식 버전을 적용해도 되겠네요.

php


참고로 php.ini의 max_input_vars default값은 1000입니다.

http://www.php.net/index.php#id2012-01-11-1

The PHP development team would like to announce the immediate availability of PHP 5.3.9. This release focuses on improving the stability of the PHP 5.3.x branch with over 90 bug fixes, some of which are security related.

Security Enhancements and Fixes in PHP 5.3.9:

* Added max_input_vars directive to prevent attacks based on hash collisions. (CVE-2011-4885)
* Fixed bug #60150 (Integer overflow during the parsing of invalid exif header). (CVE-2011-4566)


※ 2012.2.2에 php 5.3.10버전이 나왔습니다. HashDoS를 패치한 5.3.9버전에 원격에서 코드를 실행할 수 있는 취약점이 있습니다. 자세한 것은 'php 5.3.10으로 업그레이드하세요."를 읽어보세요.

* HashDoS 관련 글

- 2012/01/04 - [시스템이야기] - php에서 hash table DoS(HashDoS) 공격 방어
- 2012/01/02 - [시스템이야기] - 웹서버 hash table DoS(HashDoS) 공격 (중요. PHP, ASP 등 해당)


Posted by 좋은진호
시스템이야기2012. 1. 4. 09:36
HashDoS 공격에 대해서는 '웹서버 hash table DoS(HashDoS) 공격 (중요. PHP, ASP 등 해당)'  을 읽어보기 바란다.

웹서버에서는 Request POST, GET 변수를 hash 구조로 관리한다. 그런데 POST 요청 파라미터수가 상당히 많을 경우(GET 요청은 길이 제한이 있으므로 문제가 되지 않음)에 hash 충돌이 많이 발생하게 되어 CPU load가 상당히 올라가게 된다. 이런 문제는 PHP5, Asp.Net, Java, V8 자바스크립트 엔진 등에서 발생한다.

취약점을 해결하거나 공격을 약화시키는 방법이다.

1. php 5.4.0 RC버전과 앞으로 나올 PHP 5.3.9 버전 (취약점 해결)

max_input_vars 설정으로 파라미터 개수를 제한한다.

2. 기존 php버전에서 (완벽한 해결이 아닌 공격을 약화시키는 방법)

php.ini 설정값 (default)
max_input_time = 60     ; Maximum amount of time each script may spend parsing request data
post_max_size = 8M

max_input_time은 요청 데이터를 파싱하는데 걸리는 최대 시간이다.
max_input_time으로 파싱 시간 제한, post_max_size으로 POST 사이즈를 제한함으로써 파라미터수를 어느정도(?) 제한하는 효과를 갖는다. 완벽한 해결이 아닌 공격을 약화시키는 방법이다.

기존에 쌓아둔 웹로그를 분석해서
  1. 스크립트의 실행 시간이 얼마나 걸리는지 (max_input_time 설정위해. 웹로그 시간은 정확히는 전송시간 + max_input_time + max_execution_time과 관련)
  2. POST 요청의 사이즈를 분석한다. (post_max_size 설정위해)
수치를 적절히 파악한 후 서비스에 지장없는 정도로 조절한다.
(예 : max_input_time = 10, post_max_size = 100K)
단, 파일이 업로드되는 서비스는 POST사이즈가 크므로 post_max_size는 적용하기 어렵고, max_input_time만 설정해볼 수 있다.

3. 수호신(suhosin) php 보안 모듈 사용 (취약점 해결)

suhosin.post.max_value_length = 1000000
suhosin.post.max_vars = 500
suhosin.request.max_vars = 500

수호신 모듈을 사용하면 위 설정만으로도 문제가 해결된다. 최대 파라미터 개수를 500개로 제한한 경우이다. default는 1000이다. 다음과 같이 차단되었음을 확인할 수 있다.

suhosin[95705]: ALERT - configured POST variable limit exceeded - dropped variable '..생략..' (attacker 'xxx.xxx.xxx.xxx', file '/..생략../index.html')

4. apache와 nginx에서 POST사이즈 제한 (100K로 제한하는 예)

POST사이즈 제한을 php설정 외에 웹서버 자체 설정도 적용하고 싶다면 다음과 같이 한다. 위 2번에서 설명한대로 기존 웹로그를 분석해서 적절한 POST사이즈를 파악해서 적용한다.

1) apache
   LimitRequestBody 100000

2) nginx (defaul는 1MB)
   client_max_body_size 100k;


※ 다음은 php.ini의 max_input_time 설정을 착각하는 분들이 있어 정리했다. (1.4(수) 19시)

위에서 말한대로, php.ini 설정 중 max_input_time은 HTTP '요청 데이터(POST, GET)를 파싱하는데 걸리는 시간'이다. 'input' 이라는 단어가 들어가기 때문에, 전송되는 시간으로 착각하는 경우가 있다. 하지만 모든데이터를 다 받은 순간부터 실행 시작하기까지의 시간이다. 아래에서 3번에 해당하는 구간이다.

1) POST 요청 -> 2) POST 데이터 전송 -> 3) 전송후 파싱 -> 4) 실행

정상적인 요청이라면 파싱하는데 걸리는 시간은 짧다. 그래서 이 수치를 줄임으로써 어느정도의 효과가 있다.


Posted by 좋은진호
시스템이야기2012. 1. 2. 19:20
먼저 공격 동영상 한편을 보자.

Denial of Service using Hash tables collisions in PHP


hash table collisions버그를 이용해서 PHP로 DoS공격을 하는 예이다. 동영상에서는 약 190초 동안이나 CPU load가 15%정도 올라갔다. H/W사양이나 요청하는 POST값은 다양하니 수치의 의미보다는 load 상승의 심각성을 중요포인트로 생각해야 한다. 이런 비정상 요청 몇개만으로 서비스는 제대로 이뤄지지 않을 수 있다. '단 몇개만'으로.

웹서버에서는 Request POST, GET 변수를 hash 구조로 관리한다. 그런데 POST 요청 파라미터수가 상당히 많을 경우(GET 요청은 길이 제한이 있으므로 문제가 되지 않음)에 hash 충돌이 많이 발생하게 되어 CPU load가 상당히 올라가게 된다. 이런 문제는 PHP5, Asp.Net, Java, V8 자바스크립트 엔진 등에서 발생한다.

PHP의 경우 5.4.0 RC버전과 앞으로 나올 PHP 5.3.9 버전에서 max_input_vars 설정으로 파라미터 개수를 제한할 수 있다.

현재 @hashDoS 트위터( http://twitter.com/hashDoS )에서 이번 취약점에 대한 논의가 있으니 참고하기 바란다.

* php에서 hash table DoS(HashDoS) 공격 방어 (정리해서 올렸습니다. 1.4(수) 오전)
* hashDoS 취약점 관련 글


Posted by 좋은진호
시스템이야기2011. 8. 31. 17:15
지난주 '아파치 웹서버를 한방에 다운시키는 Range요청 취약점'이 발표되었다.

apache 웹서버


국내에서는 이 DoS 취약점에 대해 너무나 조용하지만, 한방에 서버를 다운시킬 수 있는 심각한 문제이다. 아파치 웹서버(Apache)에 정상적이지 않은 형태로 Range 헤더를 요청하면, 웹서버의 load는 단 몇초만에 급상승하여 서버는 응답을 처리할 수가 없다.

아파치 1.3, 2.0, 2.2버전대 모두 DoS 취약점이 존재한다. 오늘 DoS 취약점을 패치한 2.2.20 버전을 발표했다.

SECURITY: CVE-2011-3192 (cve.mitre.org) core: Fix handling of byte-range requests to use less memory, to avoid denial of service. If the sum of all ranges in a request is larger than the original file, ignore the ranges and send the complete file. PR 51714.

예전 1.3.x버전 운영중인 분들은 더 이상 지원하지 않는 버전대를 버리고 2.2.x대로 갈아타시기 권장한다. 2.0.x버전대는 조만간 발표될 것이다.
2.2.20 테스트 결과, 해당 취약점이 패치된 것을 확인했다.


Posted by 좋은진호
시스템이야기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 좋은진호
시스템이야기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 좋은진호
시스템이야기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 좋은진호
시스템이야기2010. 11. 11. 22:04
커피닉스(coffeenix.net)의 '범냉이'님이 dig과 nslookup툴을 사용하여, resolv.conf에서 지정한 DNS 서버가 죽었을 경우 timeout시간은 어떻게 되는지 테스트를 하셨다. 테스트한 글은 '커피닉스'에 'DNS 질의 TimeOut의 진실은..'  에 정리되어 있다.

lookup

※ 이미지 출처 : 구글 'domain lookup' 이미지 검색


resolv.conf에 지정한 DNS서버 중 한대가 응답이 없을 때, DNS 요청의 timeout은 5초일까? 1초일까?
왜 이런 궁금증을 갖게됐을까? /usr/include/resolv.h에는 RES_TIMEOUT은  5초로 설정되어 있다. 하지만 dig이나 nslookup으로 테스트한 결과는 1초였기 때문이다.

1) Primary 정상, Secondary 정상
2) Primary 비정상, Secondary 정상
3) Primary 정상
4) Primary 비정상

위 4가지 상황에 대한 테스트 결과는 범냉이님의 글을 읽어보면 결과를 확인할 수 있다.
이후, 추가적인 실험은 제가 넘겨받아 하게 됐다. 자세한 글은 '커피닉스'의 'DNS 질의 TimeOut의 진실은.. (2번째)' 에 쓰여있고, 여기에는 간단하게 요약해서 적었다.

1. dig, nslookup에서는 왜 timeout이 1초인가?

결론적으로는 bind 소스내의 dig과 nslookup툴은 resolv.h의 설정값을 사용하지 않는다. dig소스의 dig.h에 timeout이 1초(#define SERVER_TIMEOUT 1)로 정의되어 있기 때문이다.

2. 만약 resolv.conf에 지정한 모든 서버가 응답이 없다면 dig, nslookup의 timeout 결과는?

정리하면 다음과 같다.
1) resolv.conf에 나열된 서버간 요청 대기는 1초(SERVER_TIMEOUT)
2) 나열된 모든 서버 요청 후 retry시 대기는 5초(UDP_TIMEOUT)
3) retry 횟수는 3번이다.

resolv.conf에 지정한 서버 대수에 따라서,

1) 1대일 때 응답없다면 : 5초 + 5초 + 5초 = 총 15초 소요.
2) 2대일 때 모두 응답이 없다면 : 1초+5초  +  1초+5초  +  1초+5초 = 총 18초 소요
3) 3대일 때 모두 응답이 없다면 : 1초+1초+5초  +  1초+1초+5초   +  1초+1초+5초 = 총 21초 소요

3. gethostbyname() 함수, ping 프로그램 테스트 결과는?

gethostbyname()함수를 사용하는 C프로그램이라면 지금까지 설명한 resolv.h와 resolv.conf을 따르게 된다. 대표적인 것이 ping일 것이다.

resolv.conf에 지정한 DNS서버에서 ICMP응답을 받을 수 있느냐 없느냐에 따라서 대기시간(timeout시간)은 달라지게 된다.

ICMP Port Unreachable

ICMP Port Unreachable (UDP Port 53)


1) ICMP응답이 온다면, timeout없이 바로 다음 서버로 요청을 한다.
2) ICMP응답이 없다면, timeout동안(5초) 대기하다가 다음 서버로 요청을 한다.

4. 효과적인 resolv.conf 설정

만약 resolv.conf에 지정한 첫번째 네임서버(또는 네임서버 VIP) 자체가 죽는다면 ICMP 응답을 못받을 것이다. 따라서 응답시간을 줄이고자 한다면 resolv.conf에서 timeout시간을 줄여주는게 더 나은 대비책이 될 것이다.

options timeout:1 attempts:2 또는
options timeout:1 attempts:1

하지만 resolv.conf 설정을 사용하지 않는 프로그램도 있다. 모든게, resolv.conf 설정대로 될 것이라는 믿음은 절대 금물.

Posted by 좋은진호
시스템이야기2010. 5. 31. 19:14
MySQL의 SELECT LOAD_FILE() 함수, LOAD DATA는 서버내에 있는 파일을 읽어들이는 명령이다. MySQL 데몬이 파일을 읽을 권한이 있다면, 서버내의 경로와 상관없이 어떠한 파일이라도 읽을 수 있다. 만약 웹페이지가 SQL Injection 공격의 취약점이 있다고 할 때 다음과 같은 형식으로 쉽게 웹에서 서버 내의 파일을 확인할 수 있는 위험성이 존재한다.

select ...생략... from ...생략...  UNION SELECT LOAD_FILE("/etc/passwd");

이 함수가 편리성, 활용성 측면에서는 좋을 수 있지만, 보안에는 취약한 통로를 제공하는 셈이다.

2009월 말, 루마니아의 Unu 해커는 세계 주요 사이트와 국내 보안 업체 사이트를 SQL Injection공격으로 해킹을 했다. 그리고, MySQL의 load_file() 함수로 서버의 /etc/ 파일까지 캡쳐하여 블로그에 공개한 적이 있다.

mysql


MySQL 5.1.17부터는 LOAD_FILE() 함수, LOAD DATA, SELECT ... OUTFILE을 특정 디렉토리내의 파일만 허용하도록 설정할 수 있다. --secure-file-priv 옵션은 동적으로는 설정값을 변경할 수가 없다. my.conf 의 '[mysqld]' 섹션에 다음과 같은 설정을 한다. (경로는 운영 환경에 맞게 할 것)

[mysqld]

secure-file-priv=/var/tmp

위처럼 설정하고 MySQL 데몬을 실행하면 load_file()을 사용할 수 있는 경로가 /var/tmp으로 제한이 된다.

자세한 글은 커피닉스의 'MySQL에서 보안위해 load_file() 경로 제한하기' ( 2010.5 )를 읽어보기 바란다.


* 관련글

- 2009/11/30 - [IT이야기] - nProtect 웹사이트, SQL Injection공격 당해
- 2008/12/11 - [시스템이야기] - MySQL 인젝션 공격 방어하는 GreenSQL
- 12.22~23 커피닉스 이야기 (Intel사이트 SQL Injection등) (2009.12.24)
- 대량 SQL Injection 공격 주의 (2009.12.11)


Posted by 좋은진호