Search Results for '분류 전체보기'

125 POSTS

  1. 2008.11.06 BIND 최신버전으로 업그레이드
  2. 2008.11.06 find 유용한 사용법
  3. 2008.11.06 iptables
  4. 2008.11.06 named.conf - option최적화
  5. 2008.11.06 DNS 서버 구성하기
  6. 2008.11.06 Ethernet과 Switch 모든것 1
  7. 2008.11.06 기가비트 이더넷의 이해

BIND 최신버전으로 업그레이드

Posted 2008. 11. 6. 17:39

BIND 최신버전으로 업그레이드

 

1. 최신 소스 다운로드 받기 [bind 9.5.0]

 

먼저 보안에 노출된 버젼은 받지 마시기 바랍니다.

현재 보안상 문제가 없는 bind-9.5.0rc1 로 예를 들어보겠습니다.

  

[root@localhost tmp]# ftp ftp.isc.org

Name (ftp.isc.org:root): ftp

 

패스워드는 그냥 아무거나 적으시면 됩니다.

 

ftp> cd isc

ftp> cd bind9

ftp> cd 9.5.0rc1

ftp> bi

200 Switching to Binary mode.

 

ftp> get bind-9.5.0rc1.tar.gz

 

[root@localhost tmp]#tar zxvf bind-9.5.0rc1.tar.gz

 

  

2. 백업 받아 놓기 

 

[root@localhost tmp]# cp /etc/named.conf named.conf-20080519

[root@localhost tmp]# /usr/sbin/named -v

BIND 9.2.1

[root@localhost tmp]# cp /usr/sbin/named /usr/sbin/named-921

 

 

3. 컴파일하기 

 

[root@localhost tmp]# cd bind-9.5.0rc1

[root@localhost bind-9.5.0rc1]# vi  bin/named/include/named/globals.h

 

EXTERN const char *             ns_g_defaultpidfile     INIT(NS_LOCALSTATEDIR

                                                             "/run/named.pid");

EXTERN const char *             lwresd_g_defaultpidfile INIT(NS_LOCALSTATEDIR

                                                            "/run/lwresd.pid");

이부분을 

  

EXTERN const char *             ns_g_defaultpidfile     INIT(NS_LOCALSTATEDIR

                                                             "/named.pid");

EXTERN const char *             lwresd_g_defaultpidfile INIT(NS_LOCALSTATEDIR

                                                            "/lwresd.pid");

 

로 수정

 

[root@localhost bind-9.5.0rc1]# ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var/run/named --enable-threads

  

컴파일후 바로 데몬을 확인하시길 바랍니다.

가끔 데몬이 죽는경우가 생기기 때문입니다.

 

[root@localhost bind-9.5.0rc1]# ps -ef | grep named
named    13608     1  0 May19 ?        00:00:00 /usr/sbin/named -u named
root     24320 23450  0 18:15 pts/1    00:00:00 grep named


[root@localhost bind-9.5.0rc1]# service named restart  혹은

[root@localhost bind-9.5.0rc1]# /usr/sbin/named restart

 

[root@localhost bind-9.5.0rc1]# /usr/sbin/named -v
BIND 9.5.0rc1

 

[root@localhost bind-9.5.0rc1]# rndc reload
server reload successful

 

이렇게 하시면 업그레이드는 끝이 납니다.


find 유용한 사용법

Posted 2008. 11. 6. 16:52

유용한 find 사용 방법  


출처 : http://linuxer.mireene.com/bbs/zboard.php?id=tips&page=2&sn1=&divpage=1&sn=off&ss=on&sc=on&select_arrange=headnum&desc=asc&no=40


* / 는 최상위 디렉터리를 뜻함. 만약 찾고자 하는 디렉터리가 있다면 그걸로 대체

- 파일 이름에 foobar 가 들어간 파일 찾기
   find / -name "foobar" -print

- 특정 사용자(foobar) 소유의 파일을 찾기
   find / -user foobar -print | more

- 최근 하루동안에 변경된 파일을 찾기
   find / -ctime -1 -a -type f | xargs ls -l | more

- 오래된 파일(30일 이상 수정되지 않은 파일) 찾기
   find / -mtime +30 -print | more

- 최근 30일안에 접근하지 않은 파일과 디렉터리를 별도의 파일로 만들기
   find / ! ( -atime -30 -a ( -type d -o -type f ) ) | xargs ls -l > not_access.txt

- 하위 디렉터리로 내려가지 않고 현재 디렉터리에서만 검색하기
   find . -prune ...

- 퍼미션이 777 인 파일 찾기
   find / -perm 777 -print | xargs ls -l | more

- others 에게 쓰기(write) 권한이 있는 파일을 찾기
   find / -perm -2 -print | xargs ls -l | more

- others 에게 쓰기(write) 권한이 있는 파일을 찾아 쓰기 권한을 없애기
   find / -perm -2 -print | xargs chmod o-w
      또는
   find / -perm -2 -exec chmod o-w {} ; -print | xargs ls -l | more

- 사용자이름과 그룹이름이 없는 파일 찾기
   find / ( -nouser -o -nogroup ) -print | more

- 빈 파일(크기가 0 인 파일) 찾기
   find / -empty -print | more
      또는
   find / -size 0 -print | more

- 파일 크기가 100M 이상인 파일을 찾기
   find / -size +102400k -print | xargs ls -hl

- 디렉터리만 찾기?
   find . -type d ...

- root 권한으로 실행되는 파일 찾기
   find / ( -user root -a -perm +4000 ) -print | xargs ls -l | more

- 다른 파일시스템은 검색하지 않기
   find / -xdev ...

- 파일 이름에 공백이 들어간 파일 찾기
   find / -name "* *" -print

- 숨겨진(hidden) 파일을 찾기
   find / -name ".*" -print | more

- *.bak 파일을 찾아 지우기
   find / -name "*.bak" -exec rm -rf {} \;

- *.bak 파일을 찾아 특정 디렉터리로 옮기기
   mv `find . -name "*.bak"` /home/bak/

- 여러개의 파일에서 특정 문자열을 바꾸기
   find / -name "*.txt" -exec perl -pi -e 's/찾을문자열/바꿀문자열/g' {} \;




출처 : http://blog.empas.com/rootmankr/19974627

--------------------------------------------------------
1. find 명령과 관련된 기본적인 옵션 사항들
--------------------------------------------------------
(1) -name pattern    
      화일의 이름이 pattern과 일치하면 참, pattern은 셸 메타문자 *,[] ?를 포함할 수 있다.


(2) -perm oct          
      화일의 허가 플래그의 8진수 표현이 oct와 일치하면 참


(3) -type ch            
      화일의 유형이 ch(b=block, c=char등)이면 참


(4) -user userId
      화일의 소유자가 userId이면 참
  

(5) -group groupId    
      화일의 그룹이 groupId이면 참


(6) -atime count      
      화일이 count 날 수 이내에 접근되었으면 참

  
(7) -mtime count      
      화일의 내용이 count 날 수 이내에 수정되었으면 참


(8) -ctime count      
      화일의 내용이 count 날 수 이내에 수정되었고,  화일의 속성이 바뀌었으면 참

  
(9) -exec cmd        
      수행중인 command의 종료 코드가 0이면 참. 명령은 ; 에 의해서 끝내야한다.
      만일 {}를 명령의 인수로 지정하면, 현재 화일의 이름으로 치환


(10) -print                
      현재 화일명을 프린트하고 참값을 반환


(11) -ls                    
       현재 화일의 속성을 보여주고 참값을 반환


(12) -cpio device      
       현재 화일을 cpio 형식으로 device에 쓰고 참값을 반환


(13) -!expression      
       expression의 논리 부정을 반환


(14) exp1 [-a] expr2  
      단축형 and: 만일 expr1이 거짓이면 거짓을 돌려주고, expr2는 수행하지 않고, 만일 expr1이 참이면 expr2의 값을 반환


(15) expr1 -o expr2    
      단축형 or: 만일 expr1이 참이면 참을 반환. 만일 expr1ㅣ 거짓이면 expr2의 값을 반환


--------------------------------------------------------
2. find 동작 예시
--------------------------------------------------------
(1) [root@root /root]# find / -name "*.c" -print
     : 최상위 디렉토리로 부터 모든 C 소스를 출력


(2) [root@root /root]# find / -mtime 5 -ls
     : 최상위 디렉토리에서 5일동안 수정된 화일들을 표시


(3) [root@root /root]# find / -name "*.bak" -exec rm -f {} ; 2>/dev/null
     : 최상위 디렉토리로부터 bak로 끝나는 화일들을 삭제처리함


(4) [root@root /root]# find / (-name "*.c" -o -name "*.bak" ) -print
     : 최상위 디렉토리에서 *.c 나 *bak 화일로 끝나는 모든 화일들의 이름을 출력


(5) [root@root /root]# find / -name "*.o" -o -name "*.tmp"
     : 파일 이름이 *.o 또는 *.tmp 와 일치하는 파일들에 대해서 참으로 평가


(6) [root@root /root]# find / -type f -atime +30 -print
     : 30일 이상 읽혀지지 않은 모든 파일들을 출력한다


(7) [root@root /root]# find / -atime +5 ( -name "*.o" -o -name "*.tmp" )
     : access 시간이 5일 이상이고 이름이 .o 나 .tmp 로 끝난다.


(8) [root@root /root]# find / ! -atime +5 ( -name "*.o" -o -name "*.tmp" )
     : 4번과의 반대로 의 결과를 얻는다. 








Find 용법 Sysadmin 
2007/03/12 19:49


http://blog.naver.com/dreamworkers/70015231124

출처 : 유닉스 파워툴


* / 는 최상위 디렉터리를 뜻함. 만약 찾고자 하는 디렉터리가 있다면 그걸로 대체

- 파일 이름에 foobar 가 들어간 파일 찾기
find / -name "foobar" -print

- 특정 사용자(foobar) 소유의 파일을 찾기
find / -user foobar -print | more

- 최근 하루동안에 변경된 파일을 찾기
find / -ctime -1 -a -type f | xargs ls -l | more

- 오래된 파일(30일 이상 수정되지 않은 파일) 찾기
find / -mtime +30 -print | more

- 최근 30일안에 접근하지 않은 파일과 디렉터리를 별도의 파일로 만들기
find / ! ( -atime -30 -a ( -type d -o -type f ) ) | xargs ls -l > not_access.txt

- 하위 디렉터리로 내려가지 않고 현재 디렉터리에서만 검색하기
find . -prune ...

- 퍼미션이 777 인 파일 찾기
find / -perm 777 -print | xargs ls -l | more

- others 에게 쓰기(write) 권한이 있는 파일을 찾기
find / -perm -2 -print | xargs ls -l | more

- others 에게 쓰기(write) 권한이 있는 파일을 찾아 쓰기 권한을 없애기
find / -perm -2 -print | xargs chmod o-w
또는
find / -perm -2 -exec chmod o-w {} ; -print | xargs ls -l | more

- 사용자이름과 그룹이름이 없는 파일 찾기
find / ( -nouser -o -nogroup ) -print | more

- 빈 파일(크기가 0 인 파일) 찾기
find / -empty -print | more
또는
find / -size 0 -print | more

- 파일 크기가 100M 이상인 파일을 찾기
find / -size +102400k -print | xargs ls -hl

- 디렉터리만 찾기?
find . -type d ...

- root 권한으로 실행되는 파일 찾기
find / ( -user root -a -perm +4000 ) -print | xargs ls -l | more

- 다른 파일시스템은 검색하지 않기
find / -xdev ...

- 파일 이름에 공백이 들어간 파일 찾기
find / -name "* *" -print

- 숨겨진(hidden) 파일을 찾기
find / -name ".*" -print | more

- *.bak 파일을 찾아 지우기
find / -name "*.bak" -exec rm -rf {} \;

- *.bak 파일을 찾아 특정 디렉터리로 옮기기
mv `find . -name "*.bak"` /home/bak/

- 여러개의 파일에서 특정 문자열을 바꾸기
find / -name "*.txt" -exec perl -pi -e 's/찾을문자열/바꿀문자열/g' {} \;

find에 대한 참고문

find는 유닉스 및 리눅스 환경에서 중요한 유틸리티 중 하나이다. find는
파일의 이름부터 시작해서 수정 시간에 이르기까지 주어진 파라미터들과
일치하는 파일들을 찾아준다.

여기에서는 find에 대해 일부분만 다룬다. 조금더 알고싶은 유저는 한빛미디어
"유닉스 파워툴"을 참조하시기 바란다.

find의 기본문법

find path operators

path는 경로이다. 이 부분에 대해선 다음부분에서 약간 더 자세하게
설명할 것이다.
operators 는 연산자이다. 쉽게 풀이하자면 옵션인 셈이다. 여기에 들어갈
수 있는 것은 지금부터 소개할 것이다.

-name filename

우리가 가장 일반적으로 사용하는 옵션이다. filename에는 와일드 카드(별표)
가 들어갈 수 있지만 쉘이 변환하지 않도록 인용부호 쿼트(")로 둘러싼다

-perm mode

주어진 액세스 모드를 가진 파일을 찾는다. 액세스 모드는 8진수 값을 갖는다.
뒤에서 다시 설명한다

-type c

지정된 타입에 관해서 파일을 찾는다. c는 한글자로 된 코드이다. 예를 들면,
f는 일반 파일, b는 블록 특수 파일, l은 심볼릭파일을 나타낸다. 뒤에서 다시
설명한다.

-user name

이 옵션은 name에 해당하는 사용자 파일을 찾는다. name에는 사용자 id뿐만 아니라
사용자의 UID도 들어갈 수 있다.

-group name

이 옵션은 name에 해당하는 그룹의 파일을 찾는다. name에는 그룹명 뿐만 아니라
GID가 들어갈 수도 있다.

-size n

해당되는 사이즈의 파일을 찾는다. n은 블록길이의 파일을 찾는다. 한 블록은 512와 같다.
+n 이란 표시가 들어가면 n 블록보다 더 긴 파일을 찾는다라는 뜻이다. 파일이 클때
유용하다. nc라는 표현은 n 문자 길이의 파일들을 찾는다는 의미이다. ++nc는 무엇을
뜻할까? 뒤에서 다시 다룬다

-inum n

inode 번호가 n인 파일을 찾는다. 그다지 자주 사용되는 옵션은 아니여서 자세한
설명은 요약한다.

-atime n

n일 전에 액세스한 파일들을 찾는다. +n은 n일 이전에 액세스한(즉 n일 동안 액세스
하지 않은)파일들을 찾는다는 의미이다. 그러면 -n은 무엇을 의미할까? (즉, n일 동안
액세스한) 파일들을 찾는다" 의미이다. 뒤에서 다시 언급한다

-mtime n

파일의 내용이 수정된 시간을 검사한다는 것을 제외하고는 atime과 유사하다.

-ctime n

inode의 마지막으로 변경된 시간을 확인한다는 것을 제외하고는 atime과 유사하다.
"변경되다"라는 것은 파일이 수정되거나 그 특성 중의 하나가 변경되었다는 것(예를
들면, 그 소유자)을 의미한다.

-newer file

주어진 file보다 더 최근에 수정된 파일을 찾는다.

그런데 여기까기 find의 옵션을 살펴 보았는데 때때로 여러분은 조건을 만족하는
파일을 찾기 원할 것이다. 이럴때 쓰는 연산자가 있다. 다음이 그 연산자이다.

operator1 -a operator2

and 연산에 해당한다. -a는 생략이 가능하다. 두개의 검색 패턴이 같이 쓰여지면
find는 2개 모두와 일치하는 파일들을 원하는 것으로 가정한다.

operator1 -o operator2

or 연산에 해당한다. 둘 중 하나가 속하는 파일을 찾는다.

! operator

not 연산에 해당한다. operator에 해당하지 않는 파일들을 찾는다.

\(expression\)

논리 우선순위를 의미한다. 복잡한 표현식에서 위와 같이 지정해 주면 이 부분을
나머지 부분보다 빨리 계산한다. 여기서 (를 \( 로 표현했는데. 쉘이 해석할 수
있기 때문이다. php를 사용해 보신분이라면 무슨 얘기인지 대충 감 잡으셨을 것이다.

이번 부분은 find가 파일들을 찾았을때의 행위를 지정하는 그룹의 연산자들이다.

-print

파일의 이름을 표준출력으로 출력한다. 뒤에서 조금 더 다룬다..

-exec command

찾은 파일들을 command로 처리한다. command에서 찾은 파일의 경로명을 포함
시키려면 중괄호를 사용한다 {} command는 명령을 실행시키고 난 뒤에는 반드시
백슬래시와 세미콜론을 사용한다. (\;)

-ok command

기본적으로 -exec 옵션과 같다. 그러나 해당 command를 실행하기 전에 명령을
실행할지에 대해 물어본다. 일반적으로 find를 테스트하는 데 많이 쓰인다고 한다.

위 옵션은 가장 일반적인 옵션들이지만 때때로 막강한 시스템 관리자들은 추가 또는
삭제하여 사용하기도 하니 여러분의 시스템에서 man find를 하게 되면 더 많은 옵션을
볼 수 있을 것이다.

1. 깊은 디렉토리 파고 들어가기

find의 가장 분명한 용도는 오래되고 큰 자료를 찾는 것이다. 또는 사용되지 않는
파일들의 위치를 찾아내는 능력이다. 그러나 근본적으로 가장 중요한 find의 특징은
서브 디렉토리로 내려가는 것이다.

보통 쉘은 인자 목록을 명령어에 제공해 준다. 그것은 UNIX 프로그램들에게 디렉토리명이
아닌 파일명들이 주어지는 이유이다. 단지 몇몇 프로그램들만이 디렉토리 이름을 받아서
서브디렉토리의 이름을 받아서 검색해서 내려갈 수 있다. find, tar, du, 그리고 diff 같은
프로그램이 그렇게 한다. chmod, chgrp, ls, rm 그리고 cp의 몇몇 버전들도 -r이나 -R
옵션이 주어질 때는 그럴 수 있다.

일반적으로는 대부분의 명령어들은 디렉토리 구조를 완전이 이해하지 못하며 쉘이 와일드
카드를 디렉토리 명으로 확장해 주는데 의존한다. 그러므로 어떤 디렉토리 그룹에서 .o로
끝나는 모든 파일들을 삭제하려면 다음과 같이 입력할 수 있다

find *.o */*.o */*/*.o

이렇게 하는 것은 입력하기 귀찮을 뿐 아니라 검색하는 모든 파일들을 찾을 수 없을지도
모른다. 쉘은 어떤 맹점이 있다. 점으로 시작하는 이름을 가진 디렉토리 내의 파일들은
찾을 수 없을 것이다. 그리고 */*/*/*.o 로 찾아지는 파일들이 있다면 삭제되지 않을 것이다.

또 다른 문제점은 위와 같이 입력하게 되면 Arguments too long이라는 에러 메시지를 내 뱉는다.
이것은 여러분이 입력한 와일드 카드를 쉘이 너무 많은 인자들로 확장했음을 의미한다.

find는 이런 문제점에 대한 해결책이다.

find의 가장 간단한 예는 다음이다

find . -print

find의 첫번째 인자는 디렉토리 또는 파일들의 경로이다. 위의 예제는 해당 디렉토리의
모든 파일들을 찾아준다. 경로명 뒤의 인자들은 항상 - 부호 (하이픈또는 대시라고 부른다)가
붙게 된다. 이것에 유의하기 바란다. 그리고 이 인자는 find가 무엇을 찾았을 때 어떤 행동을
취하는 가에 대해 명시한다. 그리고 다른 말로 이것은 검색 연산자들이다. 이경우엔 파일명이
출력된다. 특정 경로 이외에 C쉘에서는 틸드(~)도 사용할 수 있다. 예를 들어본다

find ~ ~barnett /usr/local -print

그리고 만약 따분하다면 다음과 같이 명령을 내릴 수도 있다

find / -print

위의 예제는 디스크에 있는 모든 파일들을 검색한다. 이 예제는 자신이 쓰는 워크스테이션에선
상관 없겠지만 여러 사람이 쓰는 웍 스테이션이나 서버에서는 범죄 행위일 정도로 디스크를
공회전 하게 낭비한다. 왠만해선 참아주기 바란다. 그러나 정말 필요하다고 생각될 시엔
/* 를 사용해 주기 바란다.

find는 결과를 표준 출력(stdin)으로 뿌리게 되니 발견한 파일의 목록을 다른 명령어로 보낼 수 있다.
이 기능을 사용한 한가지 방법은 치환이다. 다음 예제를 보자.

ls -ld 'find . -print'

find의 명령어의 실행 결과 출력이 역 인용부호 전체를 대신한다. ls는 find의 결과를 볼뿐 find
가 사용되었다는 것을 모른다. 또 다른 명령어는 xargs를 사용하는 방법이 있으나
여기에서 더 다루지 않겠다. 관심있는 유저는 한빛미디어 "유닉스 파워툴"을 보기 바란다.

2. -print 를 잊지 말자..

가끔 나는 find에 -print를 붙이는 것을 잊는다. 이것을 붙이지 않으면 검색결과가 출력되지 않는다.
(물론 GNU 버전에서는 그렇지 않으나 GNU 버전이 아닌 find에서는 꼭 붙여주어야 한다. 일부 버전에서는
-ls도 사용한다)
이것은 오래된 시스템 관리자도 가끔 잊고 초보 사용자들이 가장 잘 실수하는 내용 중 하나이니 조심하자
그리고 일부 버전은 -print를 추가해 주기도 하지만 기대해선 안된다.

3. 특정한 이름을 가진 파일 찾기

find 명령을 내릴때 메타 문자를 사용할 수 있는데 정규 표현식(grep과 같진 않다)를 사용할때 -name
연산자의 인자로 사용해서 그것들이 변경되지 않고 find로 넘겨지게 하려면 인용 부호로 감싸야 한다.
여기서 인용부호로는 어떤것을 사용해도 관계 없다.

find . -name \*.o -print
find . -name '*.o' -print
find . -name "[a-zA-Z]*.o" -print

파일 경로의 디렉토리들은 -name 연산자와 일치하지 않고 경로의 마지막에 있는 이름만이 일치한다.
예를 들어, 위의 명령어들은 ./subdir/afile이란 경로명과 일치하진 않지만 ./subdir/prog.o와는 일치한다.

경로의 중간에 있는 디렉토리과 일치하는 방법이 있다.

alias ff "find . -name '*\!{*}*' -ls"

파일이나 디렉토리의 이름을 넘겨주면 이 앨리어스는 그 인자를 포함하는 모든 파일이나 디렉토리
이름의 목록을 출력할 것이다.

4. 오래된 파일 찾기

7일된 파일을 찾고 싶으면 -mtime 연산자를 사용하면 된다

find . -mtime 7 -print

또 다른 방법은 시간의 범위를 지정하는 것이 있다.

find . -mtime +6 -mtime -8 -print

mtime은 파일의 최종 수정 시간이다. 사용되지 않은 파일을 찾아보려면 -atime 인자로 액세스 시간을 확인
하면 된다. 30일 이상 읽혀지지 않은 파일을 찾으려면 다음과 같이 하면 된다.

find . -type f -atime +30 -print

find 명령어가 디렉토리의 시간을 수정하기 실제로 액세스 되지 않은 디렉토리를 찾기란 어렵다. 각 파일과
관련된 연관된 또 하나의 시간이 있는데. ctime이라 불리는 inode 변경 시간이다. 그러나 여기에선 더 이상
자세하게 다루지 않는다.

5. find 검색의 최고봉이 되어보기

find는 확실히 까다롭다. 그러나 그 능력을 자유롭게 다루면 그 까다로움에 감사하게 될 것이다.(아직 필자는
그런 능력을 가지고 있지 않다)

find의 명령어들은 명령행의 복잡도와 상관없이 실제로는 위와 같은 것의 변형들일 뿐이다. 많은 다른 이름을
명시할 수 있고 오래된 파일들을 찾을 수 있다. 그 복잡함에 관계없이 실제로는 시작점이 어디이고 어떤
파라메터를 주고, 그리고 찾아낸 파일들을 어떻게 처리할 것인지 대해 명시하는 것 뿐이다.

더 복잡한 방법으로 find를 사용하는 것의 핵심은, 검색 파라미터는 실제로는 find가 평가하는 "논리 표현식(logical
expression)이라는 것을 깨닫는 것이다.(실제 find를 사용하는 대 부분의 유저는 논리 표현식을 사용하지 않는다)

즉. find는
한번에 하나씩 모든 파일들을 본다(솔직히 이것은 사실이다. 그러나 우리눈에 보일정도로 느리진 않다)
명령행 연산자가 제공한 표현식을 평가하기 위해 indoe에 들어있는 정보를 사용한다.(앞서 inode는 많이 사용하지
않는다는 얘기를 들어 생략했다)
표현식의 값이 참이면 지정된 행동을 한다.(예를 들면 파일의 이름을 출력하기 위해)

예를 들어 다음 표현식은 참이다
find / -name "*.c"

이런식으로 생각하게 되면 논리 연산자도 쉽다. 다음 표현식은 2개의 확장자에 해당되는 파일을 찾는다

-name "*.o" -o -name "*.tmp" -print

위 예제는 *.o와 *.tmp로 끝나는 파일들을 찾는다. 그럼 위의 확장자를 가진 파일을 찾는다면 다음의 표현식을
넣어 액세스 시간이 맞는지 검색한다

-atime +5 \( -name "*.o" -o -name "*.tmp" \)

find 안에 괄호를 넣으면 해당 부분을 먼저 계산한다. 앞에서 잠깐 설명했지만 괄호 앞에 \ 를 넣은건
서브 쉘 연산자로 의식하지 말라고 넣은 것이다.

그러나 위의 예제를 다음과 같이 바꾸면 참이 아니다.

atime +5 -name "*.o" -o -name "*.tmp"

위의 예제는 이름이 *.tmp로 끝난다. 이면 참이라는 틀린 식이 된다. 이 잘못된 표현식은 .tmp로 끝나는
모든 파일들에 대해 그 파일이 언제 액세스 되었간 간에 참이 될 것이다. 즉 -atime이 적용되지 않는다.
그러나 위의 표현식은 틀린 식이 아니다. 그러나 우리가 원하는 일을 하지 않을 뿐이다.

위의 예제를 조금 더 응용해서 현재 디렉토리에 있는 파일들을 찾으려면 다음과 같이 내리면 된다.

find . -atime +5 \( -name "*.o" -o -name "*.tmp" \) -print

그러나 반대로 위의 파일들만 찾지 않는다면 ! 연산자를 사용하면 된다..

find . ! -atime +5 \( -name "*.o" -o -name "*.tmp" \) -print

그러나 위의 표현식은 -atime 연산자에 대해서만 적용한다. 모든 연산자에 사용하려면 -atime 연산자에도
괄호를 아래와 같이 사용하면 된다.

find . ! \( -atime +5 \( -name "*.o" -o -name "*.tmp" \) \)-print

-print도 표현식이다. 이것은 항상 참으로 평가된다. 이외에 -ok, -exec 도 항상 참으로 평가된다.
이 표현식들이 좋게 사용될 때가 있긴 하다. 뒤에서 다시 다룬다.

그리고 여러분들이 find를 사용할 때 실수 하는 것 중 하나는 공백을 넣지 않는 것이다. 모든 연산자에는
공백이 필요함을 기억하기 바란다.

find가 찾는 시간들

일반적으로 -atime 부류의 연산자들에 대해서는 아쉽게도 문서화가 되어 있지 않다. 이 시간들은 일반적으로
일 단위이다.

부호없는 숫자. 예를 들어 3은 정확하게 3일 전에 끝난 24시간을 의미한다.(달리 말하면 96시간과 72시간 전 사이)

마이너스 부호를 가진 숫자는 그 시간 이후의 기간을 가리킨다. 예를 들어, -3은 지금과 3일 전 사이의 모든 시간이다.
(달리 말하면 0시간 전과 72시간 전 사이)

플러스 부호가 붙은 숫자는 그 시간 전의 24시간 기간을 가리킨다. 예를 들면 +3은 3일 이상 된 시간이다. (달리 말하면
96시간 이상)

정확한 파일 비교

"이 부분에 대해서는 언급을 생략한다. 위에서 언급한 책을 보면 자세하게 잘 나와있으니 참고하기 바란다."

찾은 파일 실행하기

find에서 찾은 파일을 실행할 수 있는데 여기서 -exec 연산자는 끝 부분에 항상 \;를 넣는다. 그러나 find가 다르게
취급하는 인자가 있는데 이 인자는 바로 중괄호이다. {} 이 두문자들은 find가 발견하는 파일의 이름을 갖는 변수이다.
예제를 보면 더 확실할 것이다. 다음 예제는 간단한 경우로써 -print 연산자를 흉내내는 echo 연산자가 있다.

find . -exec echo {} \;

c쉘은 {} 문자를 사용하지만 {}를 바꾸진 않으므로 이 문자를 인용부호로 덮어쌓일 필요는 없다. 그러나 \;에서 \는
''로 대체가 가능하다. 세미 콜론은 항상 ';'로 C쉘에서는 하는 걸로 익히자..

그리고 find안에 또 다른 find의 호출이 가능하다

여기에선 또 다른 호출에 대해서는 생략한다

-exec 커스터 테스트하기

-exec 연산자를 이용해서 커스템 테스트를 할 수 있는데 앞서 잠시 얘기했지만 되도록 -exec 연산자를 피하는게 좋다
사용해야 한다면 -ok 를 사용하는 방법과 확실히 그걸 실행해야 하는지 확인해 본다. 그리고 -exec 연산자는 꼭 find
명령의 뒤쪽에 놔두도록 한다.

HandTip

여기엔 기재하지 않았지만 \ 를 줄 바꿈 연산자로 사용할 수 있다. SQL에서도 사용가능하니 유용할 것이다. 다량의
명령어를 내릴때 상당히 유용한 기능이다.

find의 진정한 역할?

find의 진짜 역활은 파일의 위치를 찾는 것이 아니라 표현식을 평가하는 것이다. 그렇다. find는 확실히 파일의 위치를
찾아준다. 그러나 그것은 부수적인 것이다. 이점을 이해하는 것이 find를 이용하는 데에 있어 이해가 빠르고 find를
훨씬 더 자유롭게 유용하게 만드는 개념적인 발전이 될 수도 있다.

-type 연산자의 유형들

b - 블록 특수 파일("장치 파일")
c - 문자 특수 파일("장치 파일")
d - 디렉토리
f - 일반파일
l - 심볼릭 파일
p - 이름 파이프 파일
s - 소켓 파일

// 이 아래부분에서 더 이상 설명를 다루지 않습니다.

find . -size 1234c -print

- 보다 더 작은 , + 보다 더 큰

find . -name \*.o -perm 664 -print

find . -type d -perm 777 -print

----w---- 패턴은 -20과 같다.

퍼미션 8진 값
rwxrwxrwx 777
rwxrwxr-x 775
rw-rw-rw- 666
rw-rw-r-- 664
rw-rw---- 660

find . -perm -100 -print

실행가능한 --x------ 파일을 찾는다.

-perm 인자가 마이너스 부호를 가지게 되면 setuid 설정 비트를 포함한 모든 퍼미션 비트들이 검사된다.


iptables

Posted 2008. 11. 6. 16:52

1.
 전체 체인조절
 -N : 새로운 체인만들기
 -X : 비어있는 체인 제거하기
 -P : 미리만들어진 체인의 정책 바꾸기
 -F : 체인의 규칙 지우기
 -L : 체인의 규칙 나열하기
 -Z : 체인내 규칙들의 패킷과 바이트의 카운트를 0으로 만들기

 내부 체인조절
 -A : 새로운 규칙을 추가하기
 -I : 체인의 특정지점에 규칙삽입하기
 -R : 체인의 특정지점의 규칙교환하기
 -D : 체인의 특정지점의 규칙삭제하기

 INPUT  : 자신의 서버에 접속할때  설정
 FORWARD  : 자신의 서버가 경유지로 이용될때
 OUTPUT  : 자신의 서버에서 외부로 빠져나깔때 설정

 DROP  : 해당 패킷을 제거함
 ACCEPT  : 해당 패킷을 받아들임
 REJECT  : 해당 패킷을 돌려보냄

2. 설정파일을 파일로 남기기

 iptables-save > mytables
 로 파일을 만든 후 수정 및 추가 삭제를 한다.
 메모리에 저장되므로 재부팅시 설정이 유지되지 않는다.
 그래서 파일로 만들어 부팅시 자동실행되게 한다.

 iptables의 정책 변경

 iptables -F INPUT     : input 설정을 먼저 제거한다.
 iptables-restore < mytables  : 변경된 mytables의 내용을 읽어들임
 iptables -L [-n]

 cp mytables > /etc/sysconfig/iptables : 시작프로그램으로 작동시

3. 문법 예제
 - 설정순서가 중요하다. 먼저 ACCEPT한후 DROP해 주어야 한다.
 - 자주 사용되는 정책들은 앞에 설정해 두자(네임서버, 분절, 상태적용, ...)
 
  : !  : 일치하지 않는(상태적용 제외)  
  ex) -p ! tcp : tcp 프로토콜을 제외한 나머지 프로토콜

 ex) iptables -A INPUT -s 211.111.111.0/24 -p tcp -m tcp --syn -j DROP
  : -A : 정책 추가
  : INPUT  : 자신의 서버로 접속하는 부분에 대한 설정을 표시
  : -s  : start 출발지를 나타냄
    즉 현재 서버로 접속하는 클라이언트들에 대한 설정임
    211.111.111.0/24 : 211.111.111.0 - 255번까지
    211.111.111.0/255.255.255.0 : 위와 동일
    0/0  : 모든 주소를 나타냄(이렇게 설정하지 않음)
  : -p tcp : 정책을 가하는 프로토콜을 나타냄
  : -m tcp : tcp의 확장으로 이해하자(??)
  : --syn : tcp 인증과정(SYN,RST,ACK,SYN)을 모두 나타냄(??)
  : -j DROP : 정책을 나타냄

 ex) iptables -A INPUT -i lo -j ACCEPT
  : -i : 입력인터페이스
    -o : 출력인터페이스
  : INPUT이므로 당연히 입력인터페이스로 결정된다.
  * lo : loopback interface

 ex) iptables -A INPUT -f -j DROP
  : -f : 분절지정으로 DROP으로 설정(??)

 ex) in과 out을 함께 적어주면 좋음(??)
  : -A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
  : -A OUTPUT -p tcp -m tcp --sport 25 -j ACCEPT

 ex) 상태적용 (!을 쓰지 못함)
  : -m state --state [NEW, ESTABLISHED, RELATED, INVALID]
  : INVALID 가 정책의 가장위에 있게 함
  : ESTABLISHED, RELATED가 그 다음
  : NEW가 가장 마지막
  : 위에서
  : -A INPUT -f -j DROP
  : -A INPUT -m state --state INVALID -j DROP
  * ESTABLISHED, RELATED, NEW는 정책과 함께 사용하자 당연한 이야기
  * 먼저 ESTABLISHED, RELATED설정후 똑같이 NEW를 설정한다.
  * 그리고 당근 DROP이 따라 와야 한다.

 ex 초짜 설정) 
  # Generated by iptables-save v1.2.6a on Fri Dec 27 16:11:48 2002
  *filter
  :INPUT ACCEPT [22188:2403099]
  :FORWARD ACCEPT [0:0]
  :OUTPUT ACCEPT [14235:609757]
  # 그대로 두자 iptables-save > mytables시 자동으로 생성되는 부분

  -A INPUT -f -j DROP
  # 분절은 모두 drop
  -A INPUT -i lo -j ACCEPT
  # 입력인터페이스 모두 허용

  #-A INPUT -d 218.238.43.6 -p tcp -m tcp --dport 80 -j ACCEPT
  # INPUT -d(목적지)이므로 접속의 목적지는 바로 자신의 IP가 된다.(OUTPUT이면 반돼가
  # 된다. 주의 하자) 그러므로 자신의 IP를 적어주고, tcp 프로토콜에 대해서 설정한다.
  # dport는 목적지 포트로 자신의 컴퓨터 80번포트에 해당한다.
  # 즉 웹서비스만 접속가능하다는 뜻(80번 포트)
  -A INPUT -p tcp -m tcp --dport 80 -m mac --mac-source 00:E0:29:96:FF:63 -j ACCEPT
  # 이 부분은 해당 랜카드의 MAC ADDRESS에서만 접속가능하게 설정하는 부분
  -A INPUT -d 218.238.43.6 -p tcp -m tcp --syn -j DROP
  # 위에서 ACCEPT한 후에 이곳에서 DROP설정
  # --syn 설정하자 : 나가는 tcp는 허용 접속하는 tcp는 거부

  ############### UDP #########################################
  -A INPUT -s 210.117.65.100 -d 218.238.43.6 -p udp -m udp --sport 53 -j ACCEPT
  # 210.117.65.100(외부 네임서버)에서 자신의 컴퓨터(218.238.43.6)로 UDP포트를 이용하여
  # 210.117.65.100의 53(네임서버)포트를 이용하여 접속할 때 접속허용
  # 외부 네임서버 이용시 설정

  #-A INPUT -d 218.238.43.6 -p udp -m udp --dprot 53 -j ACCEPT
  # 자신의 네임서버를 운영할 때  

  -A INPUT -d 218.238.43.6 -p udp -m udp -j DROP
  # 자신의 컴퓨터로 UDP 포트를 이용한 접속을 모두 거부
  # 항상 ACCEPT후 DROP하자.

  ############### ICMP #########################################
  -A INPUT -d 218.238.43.6 -p icmp --icmp-type 8 -j REJECT
  # 자신의 컴퓨터로 icmp 프로토콜을 이용하여 접속할 때
  # icmp type 8번 포트만 거부(ping 공격거부임)

  COMMIT
  # Completed on Fri Dec 27 16:11:48 2002

 ex 딴놈꺼 함 보기)
  FTP 데몬및 클라이언트 설정하기

 FTP SERVER
  FTP 데몬을 위해서는 21번 포트로 들어 오는 접속 시도 연결,
  그와 연관이 있는 20번 포트로의 연결, windows의 IE 에서 더블 클릭들을 했을
  경우에 대한 passive(1024-65535 포트로의 연결)모드에 대한 연결을 허락

  iptables -A INPUT -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
  iptables -A INPUT -p tcp --dport 20 -m state --state ESTABLISHED -j ACCEPT
  iptables -A INPUT -p tcp --sport 1024:65535 --dport 1024:65535 -m state \
   --state ESTABLISHED,RELATED -j ACCEPT

  21번 포트로의 새로운 연결과 연결 확립을 허가
  20번역시 허가
  나머지 1024-65535 번으로의 연결 확립및 연관된 패킷에 대한 연결을 허가하는
  RELATED를 위해서 패킷을 추적하는 것으로 예상된다.

  추가로 다음 명령을 집어 넣으면 더 빠른 접속을 하게 되는데,
  왜 그런지는 지금 이해가 가지 않는다.
  내가 아는 FTP 세션 연결과는 상관이 없는 부분이지만,
  서버측에서 다음과 같은 패킷을 보내고 나서 응답이 없으면
  연결을 맺는 기이한 현상을 보이고 있다.서버측 모습을 보면

  [root@redhat root]# netstat -an
  Active Internet connections (servers and established)
  Proto Recv-Q Send-Q Local Address           Foreign Address         State
  tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN
  tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
  tcp        0      0 192.168.0.8:21          192.168.0.3:2649        ESTABLISHED
  tcp        0     20 192.168.0.8:22          192.168.0.3:2625        ESTABLISHED
  tcp        0      1 192.168.0.8:1137        192.168.0.3:113         SYN_SENT

  마지막 라인을 주목해서 보기 바란다. 192.168.0.8 은 서버측 주소이고,
  192.168.0.3은 클라이언트 쪽 주소이다. 즉 클라이언트 족에서 원하는 데이타를
  IE에서 더블 클릭하면 위와 같은 상황이 발생하게 된다는 말이다.
  따라서 다음을 집어 넣으면 빠른 접속을 하게 되는데, 알수 없는 현상이다.
  이부분에 대한 생각을 좀 해봐야 할 것이다. 정확한 이해를 하는대로 수정하겠다.

  iptables -A INPUT -p tcp --sport 113 -m state --state ESTABLISHED -j ACCEPT

 FTP 클라이언트
  tcp는 양방향이기 때문에 클라이언트측에서 나가는게 허락이 된다고 해도,
  들어 오는게 막혀 있으면 접근이 불가능하다.
  따라서 상대방의 21,20,1024-65535 에서 들어 오는 연결을 허락해야 한다.
  서버측과 상대적으로 생각하면 된다.

  iptables -A INPUT -p tcp --sport 21 -m state --state ESTABLISHED  -j ACCEPT

  상대방의 21번 포트에서 내컴으로의 존재하는 접속에 대한 패킷을 받아 들이는 룰이다.

  iptables -A INPUT -p tcp --sport 20 -m state --state ESTABLISHED,RELATED -j ACCEPT

  위의 라인은 서버(상대방)측의 20번 포트에서 내 컴퓨터로 존재하는 접속에 대한
  패킷과 또 그존재 하는 접속과의 연관이 있는 패킷을 허용한다.

  iptables -A INPUT -p tcp --sport 1024:65535 --dport 1024:65535 -m state \
   --state ESTABLISHED -j  ACCEPT

  위의 라인은 상대방컴(서버)의 1024:65535 에서 내 컴(클라이언트)으로의 존재하는
  접속에 대한 패킷을 허용 한다.
  위와 같이 허가를 해주면, active, passive 모드 둘 다 접근이 가능하다.

 ex 초짜에서 함더 생각한후 설정)
  # Generated by iptables-save v1.2.6a on Tue Dec 31 13:15:17 2002
  *filter
  :INPUT ACCEPT [8762:10005592]
  :FORWARD ACCEPT [0:0]
  :OUTPUT ACCEPT [7815:454302]
  :RH-Lokkit-0-50-INPUT - [0:0]
  #####################  상위에 오는 정책들  ###########################
  # fragmentation drop
  -A INPUT -d 218.238.43.20 -f -j DROP
  # INVALID packet Drop
  -A INPUT -d 218.238.43.20 -m state --state INVALID -j DROP
  # 네임서버가 상위정책에 오는 것은 생각해 보면 당연한 것 같다.
  # 외부네임서버(210.117.65.100) 이용할 때
  -A INPUT -s 210.117.65.100 -d 218.238.43.20 -p udp -m udp --sport 53 -j ACCEPT
  # 자신이 네임서버역확을 할때
  -A INPUT -d 218.238.43.20 -p udp -m udp --sport 53 -j ACCEPT
  # 나머지 udp 포트는 Drop
  #-A INPUT -d 218.238.43.20 -p udp -m udp -j DROP
  # Loopback 은 모두 허용(??)
  -A INPUT -i lo -j ACCEPT
  # 서비스 포트가 아니라 랜덤하게 생성되는 외부 응용프로그램의 접속포트이다.
  # 그러므로 ACCEPT 해주는 것이 편하다.
  -A INPUT -p tcp --sport 1025:65535 --dport 1025:65535 -m state --state ESTABLISHED,RELATED -j ACCEPT
  #################### ESTABLISHED, RELATED, NEW #######################
  # ESTABLISHED, RELATED 설정후 나머지(TCP, UDP) 모두 DROP 시키고
  # 똑같이 NEW 설정후 나머지(TCP, UDP) 모두 DROP하는 순서로 한다.
  # 응답속도가 빠르게 요구되는 것은 상위에 위치시킨다.
  ############### ESTABLISHED, RELATED #################################
  # 아파치
  -A INPUT -d 218.238.43.20 -p tcp -m tcp --dport 80 -m state --state ESTABLISHED,RELATED -j ACCEPT
  # 20-21:FTP, 22:SSH
  -A INPUT -d 218.238.43.20 -p tcp -m tcp --dport 20:22 -m state --state ESTABLISHED,RELATED -j ACCEPT
  # 25:smtp
  -A INPUT -d 218.238.43.20 -p tcp -m tcp --dport 25 -m state --state ESTABLISHED,RELATED -j ACCEPT
  # 137-139:samba
  -A INPUT -d 218.238.43.20 -p tcp -m tcp --dport 139 -m state --state ESTABLISHED,RELATED -j ACCEPT
  -A INPUT -d 218.238.43.20 -p udp -m udp --sport 137:138 -m state --state ESTABLISHED,RELATED -j ACCEPT
  ############### NEW #################################
  -A INPUT -d 218.238.43.20 -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT
  -A INPUT -d 218.238.43.20 -p tcp -m tcp --dport 20:22 -m state --state NEW -j ACCEPT
  -A INPUT -d 218.238.43.20 -p tcp -m tcp --dport 25 -m state --state NEW -j ACCEPT
  -A INPUT -d 218.238.43.20 -p tcp -m tcp --dport 139 -m state --state NEW -j ACCEPT
  -A INPUT -d 218.238.43.20 -p udp -m udp --sport 137:138 -m state --state NEW -j ACCEPT
  ############### 나머지 전부 DROP #################################
  -A INPUT -d 218.238.43.20 -p tcp -m tcp --syn -j DROP
  # 아래와 같은 설정이다 (--syn)
  #-A INPUT -d 218.238.43.20 -p tcp -m tcp --sport 1:65535 -j DROP
  -A INPUT -d 218.238.43.20 -p udp -m udp -j DROP
  #-A INPUT -d 218.238.43.20 -p udp -m udp --sport 1:65535 -j DROP
  ############### ICMP #########################################
  # icmp type 8 : echo = ping 공격 거부 설정
  -A INPUT -d 218.238.43.20 -p icmp --icmp-type 8 -j DROP
  ############### ETC# #########################################
  # MAC ADDRESS의 랜카드만 접속 허용
  # 주의하자 상위 정책에서 tcp를 막았으므로 아래 설정은 상위에 설정되어야
  # 효력을 발휘할 것으로 생각된다.
  # 특정유저 허용, 로그기록등 다양한 설정이 가능하다. 계속 연구하자.
  #-A INPUT -p tcp -m tcp --dport 80 -m mac --mac-source 00:E0:29:96:FF:63 -j ACCEPT
  COMMIT
  # Completed on Tue Dec 31 13:15:17 2002

===============================================================================
IPTABLES HOWTO 문서
===============================================================================
IP address, network address, netmask, routing, DNS 가 무었인지 알고 있다고
가정합니다. 그렇지 않다면 '네트워크 개념 하우투' 를 읽기를 권유합니다.

이 하우투는 상냥한 소개(이게 여러분을 열받게 하고 지금은 흐리멍텅하고 그러나
무방비인)와 가공되지않은 완전 노출(which would leave all but the hardiest
souls confused, paranoid and seeking heavy weaponry)사이를 넘 나들 것이다.

여러분의 네트워크는 안전하지 않다. 빠르고, 편안하면서 그 사용이 좋은 쪽으로만
하도록하고 악한 시도를 허락하지 않도록 하려는 것은 복잡한 영 화관에서 자유로운
대화는 허락하면서 "불이야"하고 외치는 것은 불허하는 것처럼 거의 해결불능의
문제와 같다. 이것에대한 해답은 이 하우투에서 구할 수 없을 것이다.

여러분이 할 수있는 것은 그 절충점을 결정하는 일이다. 나는 이러한 목적 으로
사용할 수 있는 몇몇 도구와 경계하여야할 약점에 대하여 여러분이 좋은 목적으로
사용하고 악의있는 목적으로 사용하지 않기를 바라며, 알려 주려고 한다. 또다른
어려운 문제이다.


3. 그렇다면, 패킷 필터란 무었일까?

패킷필터는 지나가는 패킷의 해더를 살펴보고 그 전체 패킷의 운명을 결정하는
소프트웨어의 일부이다. 이것은 패킷을 'DROP'(즉, 마치 전혀 전달되지도 못 했던것
처럼 패킷을 거부) 하던가, 'ACCEPT'(즉, 패킷이 지나가도록 내버려 둠) 하던가
또는 다른 더욱 복잡한 무엇을 할 것인가를 결정할 것이다.

리눅스에서 패킷 필터링은 커널 내부에 구성되고(커널의 모듈로서 또는 그 내부에
포함 되는 형태이다), 우리가 패킷으로 해야할 몇몇 복잡한 것이 있다. 그러나, 그
패킷의 헤더를 관찰하고 그 패킷의 운명을 결정하는 기본 원칙은 여전히 적용 된다.



3.1 왜 우리는 패킷을 필터할려고 하나 ?


제어, 보안, 관찰가능성


제어:

여러분이 내부 네트워크에서 다른 네트워크로 리눅스 박스를 이용하여 접속을
하고자 할때(소위, 인터넷) 여러분은 어떤형태의 전송은 가능하게 하고 다른것은
불가능하게 할 기회를 가진다. 예를 들어, 패킷 헤더에는 목적지의 주소를 포함하고
있고 이것으로 패킷이 바깥 네트워그의 다른곳 으로 가지 않도록 한다. 다른 예로,
나는 Dilbert archives를 호출하기 위하여 넷스케잎을 이용한다. 그곳의
웹페이지에는 doubleclick.net으로 부터의 광고가 있고 넷스케잎은 그 광고를
받기위하여 나의 시간을 소비한 다. doubleclick.net의 주소로 가거나 또는
그곳에서 오는 어떠한 패킷도 허락하지 않도록 패킷필터에게 이야기 해 놓음으로 이
문제를 해결할 수 있다. (이렇게 하는 더 좋은 방법도 있다 : Junkbuster를 보세요)


보안:

여러분의 멋지고, 잘 정돈된 네트워크와 인터넷의 혼돈사이에 리눅스 박스 만이
있다면, 여러분의 네트워크로 들어오려는 것을 억제할 수 있다는 것은 근사한
일이다. 예를들어, 여러분은 여러분의 네트워크로부터 나가는 모든 것을 허용하고
싶지만, 반면에 밖으로부터 들어오는, "죽음의 핑"같은, 악의 있는 것에 대하여는
것정이 될 것이다. 다른 예로, 아무리 여러분 리눅스 박스의 모든 계정사용자가
암호를 가지고 있다고 하더도 바깥으로부터의 텔넷시도는 바라지 않을 것이다.
대부분의 사람들처럼 인터넷에서 구경꾼 이 되고 싶고 제공자는 되고싶지 않을
것이다. 간단히 말해서, 접속중에 모든 들어오려는 패킷을 패킷 필터를 이용하거
거부할려고 할 것이다.


관찰가능성:

가끔 잘못 설정된 지역네트워크는 패킷을 바깥세상으로 토해놓는다. 패킷 필터에게
어떠한 이상한 일이라도 일어나면 여러분에게 알려 주도록 말해 두는 것은 근사한
일이다. 여러분은 이런 일에대하여 무엇인가를 할 수도 있고 그냥 '이상한
일이네'하고 넘길 수도 있다.


3.2 리눅스에서 패킷 필터는 어떻게 하나 ?


1.1 시리즈 부터 리눅스 커널은 패킷 필터링을 포함하기 시작했다. 제 1세대는
BSD의 ipfw를 기본으로 하였고 1994년 후반기에 Alan Cox에 의해서 포트 되었다.
이것은 리눅스 2.0에서 Jos Vos와 다른이들에 의해서 개선되었고 커널의 필터링
규칙을 제어하는 사용자 툴로는 'ipfwadm'이 사용되었다. 1998년 중반에 리눅스
2.2를 위하여 나는 Michael Neuling의 도움으로 커널에 대하여 열심히 일하였고
사용자 툴료는 'ipchains'를 내놓았다. 마지막으로, 제 4세대 툴이 'iptables'이고
리눅스 2.4를 위하여 1999년 중반에 커널을 제 작성 하였다. 이 하우투 문서가
촛점을 맞추고 있는 것이 이 iptables 에 대한 내용이다.


netfilter를 가지고있는 커널이 필요하다. netfilter는 다른 것들(iptables 모듈
같은)이 붙을수 있는 리눅스 커널의 일반적인 기본 구조이다. 이것은 2.3.15 이상
의 리눅스 커널에 들어있고 커널 설정에서 CONFIG_NETFILTER 에 'Y'로 대답하고 컴
파일한 것이어야 한다.


iptables라는 툴은 커널에게 어떤 패킷을 필터할 것인지를 알려준다. 여러분이 프
로그래머나 변태가 아니라면, 이것이 패킷 필터링을 제어하는 수단이다.


iptables


iptables 는 커널의 패킷 필터링 테이블에 필터링 규칙을 삽입하거나 삭제하는 도구
이다. 이것은 여러분이 무었을 설정했든지, 재부팅시에는 소실된다는 것을
의미한다. 다음번 리눅스가 다시 부팅되었을때 설정 내용들이 재설치 되기를
바란다면 규칙들을 영속시키기를 보아라


iptables는 ipfwadm과 ipchains를 대치한다. 손실없이 iptables 의 사용을 피하고
싶 다면 ipchains와 ipfwadm 사용하기를 보아라.


규칙들을 영속시키기


여러분의 파이어월 설정은 커널에 저장되므로 재부팅시에 손실된다. iptables-save
와 iptables-restore을 구현하는 것은 나의 TODO 리스트에 있다. 이것들이 나오게
되면 정말 좋을 것이다. 약속한다.


그동안은 여러분의 규칙을 설정하는 명령들을 초기화 스크립트에 기록해야 한다. 명
령들중 하나가 실패하였을때를 대비하여 뭔가 이성적인것을 해두어야 한다. (보통
'exec /sbin/sulogin'을 사용한다.)


4. 당신은 누구며 왜 나의 커널을 가지고 놀려고 하나 ?


나는 Rusty이다. 리눅스 IP 파이어월 유지하는 사람이고 적절한 시기에 적절한
장소에 있게된 그냥 워킹코더일 뿐이다. 나는 ipchains를 맹글었다. (실제적인
작업을 한 사람을 볼려면 "How Do I Packet Filter Under Linux?"라는 문서를
보라), 그리고 이번에 패킷 필터링을 구할 수 있을 정도의 많은 것을 배웠다.


WatchGuard는 정말 훌륭한 파이어월 회사이며, 정말 멋진 플럭인 파이어박스를
판매하며 아무것도 하지 않아도 나에게 월급을 준다. 덕분에 나는 이 작품을
만드는데 나의 모든 시간을 소모할 수 있었고, 이전의 작업도 그러하다. 나는
6개월이면 끝마치리라 짐작했지만 12개월이 걸렸다. 그러나 내가 바르게 했다는
생각이 든다. 수많은 수정과 하드디스크 박살과, 한번의 랩탑분실과 몇번의
파일시스템 박살과 한번의 모니터 박살의 결과물이 여기있다.


내가 여기에 있는 동안, 사람들의 잘못된 개념을 고쳐주고 싶다. 나는 커널대왕 이
아니다. 나도 내가 커널대왕이 아닌것을 안다. 왜냐하면 이런 커널에 대한 작 업중
진짜 커널대왕들(David S. Miller, Alexey Kuznetsov, Andi Kleen, Alan Cox 같은)
몇명과 접촉해 봤기 때문이다. 그러나 그들은 심오한 마술을 하느라 너무나 바빴고,
내가 안전한 물 가장자리에서 허우적 거리도록 내버려 두었다.


5. Rusty's 의 패킷 필터링에 대한 총알 가이드


대부분의 사람들은 단 하나의 PPP 접속만 사용하고 어떤 누구도 이것을 통해서
들어오는 것을 원하지 않는다.


## connection-tracking modules을 삽입한다. (not needed if built into kernel).
# insmod ip_conntrack
# insmod ip_conntrack_ftp

## 내부로부터 오는 것을 제외한 다른 새로운 접속을 막기위하여 새로운 체인을
## 만든다.
# iptables -N block
# iptables -A block -m state --state ESTABLISHED,RELATED -j ACCEPT
# iptables -A block -m state --state NEW -i ! ppp0 -j ACCEPT
# iptables -A block -j DROP

## 입력과 포워드 체인으로부터 그 체인으로 가도록 한다.
# iptables -A INPUT -j block
# iptables -A FORWARD -j block


6. 패킷이 필터를 어떻게 지나는가 ?


커널은 '필터' 테이블에 세개의 규칙을 가지고 시작한다. 이것을 파이어월 체인
또는 그냥 체인이라고 한다. 그 세개의 체인은 INPUT, OUTPUT, FORWARD 이다.


이것은 2.0 이나 2.2 커널과는 아주 다르게 움직인다.


이 체인은 아래그림처럼 생겼다.

                      _____
                     /     \
   -->[ 라우팅 ]--->|포워딩 |------->
      [ 판  정 ]     \_____/        ^
           |                        |
           v                       ____
          ___                     /    \
         /   \                   | 출력 |
        |입력 |                   \____/
         \___/                      ^
           |                        |
            ----> Local Process ----


위 그림에서 세개의 원은 위에서 언급한 세개의 체인을 나타낸다. 패킷이 이
그림에서 동그라미로 나타낸곳에 이르면 그 체인은 그 패킷의 운명을 결정하
기위하여 시험한다. 체인이 그 패킷을 DROP 하라고 하면 패킷은 그곳에서 삭
제된다. 그러나 그 체인이 ACCEPT 하고 하면 이 이 그림의 다음 부분으로 계 속
전달된다.


체인은 규칙의 점검표이다. 각 규칙은 '패킷의 헤더가 이렇게 되어있으면 이 곳에서
무엇을 하라'는 형태로 되어 있다. 규칙이 그 패킷에 맞지 않으면 다 음 규칙을
참고한다. 마지막으로 더이상 고려할 규칙이 없으면 커널은 무엇 을 할 것인가를
결정하기 위하여 그 체인의 정책을 확인한다. 보안을 생각하 는 시스템에서 이러한
정책은 보통 커널에게 그 패킷을 DROP 하도록 한다.


패킷이 커널에 도탁하면 그 패킷의 목적지를 확인한다. 이것은 '라우팅' 이라고
한다.
이것의 목적지가 이곳이면, 패킷은 위 그림에서 아래쪽 방향으로 전달 되어 입력
체인에 도달한다. 이것이 이 체인을 통과하면 패킷을 기다리 고있던 어떤
프로세서도 그것을 받게 된다.
그렇지 않으면, 커널이 포워딩 불능으로 되어있던가, 패킷을 어떻게 포 워딩해야
하는가를 알지 못하면, 그 패킷은 DROP 된다. 포워딩이 가능하 게 되어있고 다른
곳이 목적지이면 패킷은 그림의 오른쪽 방향으로 전달 되어 포워딩 체인으로 간다.
이 체인이 ACCEPT 하게 되면 이것은 포워딩 할 네트워크로 보내진다.
마지막으로, 이곳에서 돌아가던 프로그램은 네트워크 패킷을 전송할 수 있 게 된다.
이 패킷은 즉시 출력 체인에 보내진다. 이 체인이 ACCEPT 하게 되면 이 패킷은 그
목적지가 어디든지 보내진다.


7. iptables 사용하기


iptables는 상당히 자세한 메뉴얼 페이지(man iptables)를 가지고 있다. ipchains
에 익숙하다면 <@@ref>Appendix-Aipchains와 iptables의 다른점을 보아라. 이 둘은
매우 비슷하다.


iptables로 할수 있는 일에는 몇가지 다른것이 있다. 첫번째 작동은 전체 체인을
조절한다. 처음 시작은 세개의 미리 만들어진 체인으로 시작하는 데 이것은 제거될
수 없다.


새로운 체인 만들기 (-N).
 비어있는 체인을 제거하기 (-X).
 미리 만들어진 체인의 정책을 바꾸기 (-P)
 어떤 체인의 규칙들을 나열하기 (-L)
 체인으로부터 규칙들을 지우기 (-F)
 체인내의 모든 규칙들의 패킷과 바이트의 카운드를 0 으로 만들기 (-Z)

체인 내부의 규칙을 조작하는 몇가지 방법이 있다.


체인에 새로운 규칙을 추가하기 (-A)
 체인의 어떤 지점에 규칙을 삽입하기 (-I)
 체인의 어떤 지점의 규칙을 교환하기 (-R)
 체인의 어떤 지점의 규칙을 제거하기 (-D)
 체인에서 일치하는 첫번째 규칙을 제거하기 (-D)


7.1 컴퓨터가 부팅될때 여러분이 보게 되는 것


iptables는 모듈로 되어있을 것이다. 이것은 iptable_filter.o 이다. 이것은
처음으로 iptables를 실행할때 자동으로 로드될 것이다. 이것느 커널에 영구히
포함될 수도 있다.


iptables 명령이 실행되기 전에는 기본적으로 만들어져있는 체인(입력, 포워딩,
출력)에는 아무른 규칙도 없다. (주의 : 어떤 배포판에는 초기화 스크깁트에
iptables를 실행하는 것이 들어있을 수 있다.) 입력과 출력 체인의 정책은
ACCEPT이고 포워딩 체인의 정책은 DROP이다. (iptable_filter 모듈에 'forward=1'
옵션을 선택하여 이것을 고칠 수 있다.)


7.2 하나의 규칙으로 작동하기


이것은 패킷 필터링의 약방의 감초이다. 일반적으로 추가와 제거 명령을 사용할
것이다. 다른것은 이런 개념의 단순한 확장이다.


각 규칙은 패킷이 일치되어야할 상태를 설정하고, 일치되었을때 무었을 할 것인가
('target')를 나타낸다. 예를들어, 여러분은 127.0.0.1로부터의 모든 ICMP 패킷을
DROP하려고 할 것이다. 그렇다면, 이경우 일치되어야할 상태는 'ICMP이면서 그 출처
가 127.0.0.1' 이다. 이 경우 'target' 은 DROP 이다.


127.0.0.1 은 'loopback' 인터페이서 이고 실제적인 네트워크 접속이 전혀 없더라도
이것은 가지고 있을 것이다. 이러한 패킷은 'ping' 프로그램을 이용하여 생성할 수
있다. (이것은 단순히 ICMP type 8 (반응요구)을 보내고 모든 협조적인 호스트는
친절하게 ICMP type 0 (반응요구에 대한 응답)을 대답한다. 이것은 테스트하는데
유용 하다.


 
# ping -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.2 ms

--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.2/0.2 ms
# iptables -A INPUT -s 127.0.0.1 -p icmp -j DROP
# ping -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes

--- 127.0.0.1 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
#


여기서 첫번째 ping 이 성공한 결과를 볼 수 있다. ('-c 1'은 하나의 패킷만
보내도록 ping에게 말하는 것이다.)


그리고, '입력' 체인에 127.0.0.1에서 오는 패킷('-s 127.0.0.1')으로 ICMP
프로토콜인것 ('-p icmp')은 DROP ('-j DROP')하라는 규칙을 추가(-A)하였다.


그리고는 다시 ping으로 규칙을 테스트하였다. ping이 오지않은 응답을 기다 리지
못하고 응답받기를 포기하기까지 약간의 시간이 걸릴것이다.


규칙을 제거하는데는 두가지 방법이 있다. 첫째, 입력체인에는 단 하나의 규칙 만이
있다는 것을 앎으로, 몇번을 지워라는 방식으로 할 수 있다.

               # iptables -D INPUT 1
               #

 입력 체인으로부터 1번 규칙을 제거한다.


두번째 방법은 -A 명령을 이용한 이전의 명령에서 -A를 -D로 다꿔주면 된다. 이것은
복잡한 규칙을 가지고 있고 각 규칙이 몇번째 규칙인지를 외우고 다니기를 싫어
한다면, 아주 유용한 방법이다.

               # iptables -D INPUT -s 127.0.0.1 -p icmp -j DROP
               #

 -D 명령은 -A 명령과 똑 같은 문법이다. (-I 나 -R 도 마찬가지이다.) 만약,
여러개의 똑 같은 규칙들이 같은 체인에 있다면, 첫번째 것만 제거 될 것이다.


7.3 필터링 지정


앞에서 프로토콜을 지정하기위하여 '-p'를 이용하였고, 출처를 지정하기 위하여
'-s'를 이용하였다. 그 외에도 패킷의 특징을 지정하는데 사용되 는 다른 옵션들이
있다. 아래는 이것들에 대한 완벽한 개요이다.


출처와 목적지 지정


출처('-s', '--source', '--src')와 목적지('-d', '--destination', '--dst') IP
주소를 지정하는데 4가지 방법이 있다. 가장 보편적인 방법은 'www.linuxhq.com',
'localhost' 처럼 이름을 이용하는 것이다. 두번째 방법은 '127.0.0.1' 처럼 IP
주소를 이용하는 것이다.


세번째와 네번째 방법은 IP 주소의 그룹을 지정하는 것으로 '199.95.207.0/24' 또는
'199.95.207.0/255.255.255.0' 같은 형태이다. 이 둘은 모두 199.95.207.0 부터
199.95.207.255 사이의 모든 IP 주소를 지정한다. '/' 다음의 숫자는 IP 주소의
어떤 부분이 의미있는가를 나타낸다. '/32' 나 '/255.255.255.255' 가
기본값이다.(IP 주소의 모든부분이 일치해야 한다.) 모든 IP 주소를 지정하는데
'/0' 가 사용된다.

               # iptables -A INPUT -s 0/0 -j DROP
               #


이것은 '-s' 옵션을 이용하지 않은것과 같은 효과를 나타내므로 잘 사용되지
않는다.


'역'의 경우 지정


많은 지시자들('-s'나 '-d' 같은)은 일치하지 않는 주소를 나타내기 위하여
'!'('not'을 의미한다)로 시작하는 설정을 할 수 있다. 예로, '-s ! localhost' 는
localhost로부터오는 패킷이 아닌경우를 나타낸다.


프로토콜 지정


 프로토콜은 '-p' 지시자로 지정할 수 있다. 프로토콜을 숫자가 될수 있고 (IP의
프로토콜 번호를 알고 있다면) 'TCP', 'UDP', 'ICMP' 같은 이름이 될 수도 있다.
그리고 'tcp'는 'TCP'와 같은 역할을 한다.


프로토콜 이름 지정에도 '!'을 이용할 수 있다. '-p ! TCP'


인터페이서 지정


'-i'('--in-interface')와 '-o'('--out-interface')가 인터페이서를 저정 하는데
사용된다. 인터페이서는 패킷이 들어오고 나가는 물리적인 도구이다. ifconfig
명령을 사용하여 현재 활성화 되어있는 인터페이서를 알아볼수 있다.


입력 체인을 지나는 패킷은 출력 인터페이서를 가지고 있지 않으므로 '-o' 설정에
일치하는 패킷이 없을 것이고 출력 체인을 지나는 패킷은 입력 인터 페이서를
가지고 있지 않으므로 '-i' 설정에 일치하는 패킷이 없을 것이다.


포워딩 체인을 지나는 패킷만이 입력과 출력 인터페이서를 모두 가질것이다.


현재 존재하지 않는 인터페이서를 지정하는 것도 아무런 문제없이 될 수 있 다.
이것은 인터페이서가 활성화 되기 전까지는 규칙에 일치하는 패킷이 있을수 없을
것이다. 이것은 dial-up PPP를 사용하는 경우 특히 유용하다.


특별한 경우로, 인터페이서 이름이 '+'로 끝날수 있는데 이것은 그 이름으로
시작하는 모든 인터페이서를 모두 지정한다(그것이 현재 존재하든 존재하지 않든).
예를들어, 모든 PPP 인터페이서와 일치하는 규칙을 지정하려면 -i ppp+와같이 하면
된다.


인터페이서 이름앞에 '!'도 이용할 수 있다.


분절 (Fragments) 지정


가끔 패킷은 한번에 다 전달되기에는 너무 큰 경우가 있다. 이런경우 패킷은 여러
분절로 나뉘어지고 다중패킷의 형태로 전달된다. 목적지에서 이 분절들 은 재
구성되어 전체 패킷이 된다.


분절에서 문제점은 내부 패킷의 부분으로 IP 헤더 다음의 위치에서 프로토콜 헤더를
찾는데, 이것은 첫번째 분절에만 있기 때문에 찾을수가 없다.


만약 여러분이 접속추적이나 NAT를 한다면 모든 분절은 필터링 코드에 도달하 기
전에 뭉쳐지므로 분절에 대한 걱정은 할 필요가 없다.


그렇지 않다면, 분절들이 필터링 규칙에서 어떻게 처리되는가를 이해하는 것 은
중요하다. 우리가 가지고있지 않은 정보를 요구하는 필터링 규칙에 부합될 수가
없다. 이것은 첫번째 패킷은 다른 패킷과 같이 처리되고 두번째 이후의 분절은
전달될 수 없음을 의미한다. 그러므로 -p TCP --sport www ('www' 를 출신 포트로
지정하는 경우)와 같은 규칙에 맞는 분절은 있을 수 없다( 첫번째 분절을
제외하고). 그 반대의 규칙인 -p TCP --sport ! www도 분 절들을 처리할 수 없다.


그러나, 두번째 이상의 분절에 대하여 규칙을 지정하기위하여 '-f'
('--fragment')라는 지시자를 사용할 수 있다. 두번째 이상의 분절에는 적용
되지않는 규칙을 지정하기 위하여 '-f' 앞에 '!' 를 붙이는 것도 가능하다.


일반적으로 , 첫번째 분절에 필터링이 적용되어 DROP 되면 목적지 에서 다른
분절들의 재합성이 되지 않으므로, 두번째 이상의 분절이 그냥 지나가도록하는 것도
안전한 것으로 간주 된다. 그러나 단순히 분절들을 전달하는 것만으로 호스트를
크래쉬가 생기는 버그가 알려져 있다. 여러분이 결정할 일이다.


네트워크 헤더에 대한 주의 : 잘못 구성된 패킷들은 이러한 시험을 할때 DROP
되었다. (TCP, UDP, ICMP 패킷중 길이가 너무 짧아 파이어월 코드가 포트나 ICMP
코드와 형태를 읽을 수 없는 경우). 왜냐하면 TCP 분절은 8번째 위치부터 시작되기
때문이다.


예로, 다음과 같은 규칙은 192.168.1.1 로 향하는 분절을 DROP 시킨다.


# iptables -A OUTPUT -f -d 192.168.1.1 -j DROP
#


iptables 의 확장 : 새로운 대상(Matches)


iptables는 확장 가능하다. 즉 새로운 형태를 제공하기 위하여 iptables와 커널
모두가 확장 가능하다는 의미이다.


이중 일부는 표준적이고 다른 것은 이색적이다. 다른사람에 의해서도 확장 은
만들어질 수도 있으며 독립적으로 배포될 수 있다.


정상적으로 커널 확장은 커널 모듈 하부 디렉토리에 존재한다.
(/lib/modules/2.3.15/net). 이것은 요구에 의하여 적재된다. 그러므로 직 접 이들
모듈을 적재할 필요는 없다.


iptables의 확장들은 공유라이버러리 형태로 보통 /usr/local/lib/iptables 에
위치한다. 배포판은 이것을 /lib/iptables나 /usr/lib/iptables에 넣으 려 할
것이다.


확장은 두가지 형태이다. : 새로운 타겟(target), 새로운 적용(match) 아래에
새로운 타겟에 대하여 이야기 할 것이다. 어떤 프로토콜은 자동으로 새로운
테스트를 제공하는데 현재로는 TCP, UDP, ICMP 에 대해서 아래에 보여 줄 것이다.


이것을 위해서 '-p' 옵션 뒤에 지정하는데 그러면 확장을 적제할 것이다. 명백히
할려면 '-m' 옵션으로 확장을 적재하고 확장 옵션을 사용가능하게 할 수 있다.


확장에 대한 도움을 얻으려면, 적제하는 옵션('-p', '-j', '-m')을 '-h'나 '--help'
다음에 지정하면 된다.


TCP 확장


TCP 확장은 '--protocol tcp' 가 지정되고 다른 적용이 지정되지 않으면 자동으로
적제된다. 이것은 다음과 같은 옵션을 제공한다.


--tcp-flags

'!' 옵션을 사용한다면 이것 뒤에 두개의 단어를 사용한다. 첫번째 것은 검사하고자
하는 지시자 리스트의 마스크이다. 두번째 단어는 지시자에게 어떤것이 설정 될
것인지를 말해준다. 예를들어,


# iptables -A INPUT --protocol tcp --tcp-flags ALL SYN,ACK -j DENY


이것은 모든것이 검사되어야 함을 말한다.('ALL'은 `SYN,ACK,FIN,RST,URG,PSH' 와
같다.) 그러나 SYN 과 ACK 만 설정된다. 'NONE'는 지시자가 없음 을 말한다.


--syn

'!' 옵션이 선행될 수 있다. 이것은 '--tcp-flags SYN,RST,ACK,SYN'의 약어이다.


--source-port

'!' 옵션이 선행될 수 있다. 이후에 하나의 TCP 포트나 포트의 범위를 지정한다.
/etc/services 에 기록된 것과 같은 포트 이름이 사용될 수 도 있고 숫자로 나타낼
수도 있다. 범위는 두개르 포트 이름을 '-' 으 로 연결해서 사용하거나 (커거나
같은경우를 위해서) 하나의 포트 뒤에 '-'를 사용하거나 (작거나 같은 경우를
위해서) 하나의 포트 앞에 '-' 를 덧붙일 수 있다.


--sport

이것은 '--source-port'와 동의어이다.


--destination-port

--dport

는 위의 내용과 같으나 목적 지를 지정한다.


--tcp-option

'!' 나 숫자가 옵션에 선행될 수 있는데 숫자가 앞에 올경우 그 숫자 와 TCP 옵션이
같은 경우의 패킷을 검사한다. TCP 옵션을 검사하려 할 때 완전한 TCP 헤더를
갖지않는 것은 자동으로 DROP 된다.


TCP 지시자에대한 설명


가끔 한쪽 방향에서의 TCP 접속만 허랑하고 다른 방향에서의 접속을 불허하 는 것이
유용하다. 예로, 여러분은 외부 WWW 서버로의 접속은 허락하며 그 서버로 부터의
접속은 불허하기를 원할 것이다.


단순하게 그 서버로부터 오는 TCP 패킷을 막으면 된다고 생각할 것이다. 그러 나,
불행히도 작동하기 위해서 TCP 접속은 양방향의 패킷을 요구한다.


해법은 접속을 요구하는 패킷만 막는 것이다. 이러한 패킷을 SYN 패킷이라한다.
(물론, 기술적으로 SYN 지시자 셋을 갖는 패킷이 있다. 그리고 FIN 과 ACK 지시
자는 지워진다. 그러나 간단히 그것을 SYN 패킷이라고 한다.) 이러한 패킷만
불가능으로 만듬으로서 외부로 부터의 접속 시도를 막을 수 있다.


이러한 것을 위해서 '--syn' 지시자가 사용된다. : 이것은 프로토콜을 TCP 로
지정했을 때만 효과가 있다. 예를 들면, 192.168.1.1 로부터의 TCP 접속을 지
정하기 위하여 다음과 같이 하면 된다.

-p TCP -s 192.168.1.1 --syn


 접속을 시작한 것 외의 모든 패킷을 지정하기 위하여 '!' 옵션이 선행될 수 있다.


UDP 확장


이 확장은 '--protocol udp'가 지정되고 적용이 저정되지 않으면 자동으로
적재된다. 이것은 '--source-port', '--sport', '--destination-port', '-dport'를
지원하고 내용은 TCP 설명에서 자세히 나왔다.


ICMP 확장


이 확장은 '--protocol icmp'가 지정되고 그 적용이 지정되지 않으면 자동으로
적재된다. 이것은 단 하나의 새로운 옵션만 지원한다.:


--icmp-type

'!' 옵션이 선행될 수 있다. 이후에 ICMP 타입의 이름('host-unreachable') 이나
숫자형태 ('3'), 또는 숫자형태와 코드('/'로 분리 예. '3/3') 의 형 태가
사용된다. 사용할 수 있는 ICMP 형태의 이름의 리스트는 '-p icmp --help' 하면
나타난다.


그외의 적용 확장


Netfilter 패키지의 다른 확장은 시험적인 확장이다. 이것은 (설치 되어있다면)
'-m' 옵션으로 활성화 된다.


mac

이 모듈은 '-m mac' 또는 '--match mac' 이라고 함으로 지정할 수 있다. 이것은
들어오는 패킷의 이더넷 주소를 검사한다. 그러므로 입력 체인에 서만 유용하다.
이것은 하나의 옵션만 제공한다.


--mac-source

'!' 옵션이 선행 될 수 있다. 이후에 콜론으로 분리된 16진수 숫자의 이더넷 주소가
온다. 예 '--mac-source 00:60:08:91:CC:B7'


limit

이 모듈은 '-m limit' 또는 '--match limit'이라고 함으로 지정할 수 있 다. 이것은
로그 메세지를 억제할때 처럼 적용검사의 속도를 제한하는데 사용한다. 1초에
주어진 숫자만큼의 적용만 검사한다. (기본값은 한 시간 에 3번, 최고 5번이다.)
이것은 두개의 옵션을 제공한다.


--limit

숫자가 따라온다 : 초당 평균 최대 적용 검사 수를 지정한다. 숫자뒤 에 시간단위를
지어할 수 도 있다. ('/second', '/minute', '/hour', '/day'형태이다. 예로,
'5/second' 또는 '5/s'가 가능하다)


--limit-burst

숫자가 따라온다. 위의 제한이 적용되기전의 최대 Burst(?) 를 제한 한다.


이 적용은 종종 로그의 속도를 제한하기위하여 LOG 타겟과 함께 사용된 다. 이것을
이해하기위하여 아래에 기본 제한설정을 하는 로그 패킷제한 을 보자.


# iptables -A FORWARD -m limit -j LOG


이 규칙에 도달될때까지 패킷은 로그될 것이다. 사실 Burst의 기본값은 5 이므로
처므ㅇ 5개의 패킷은 로그될것이다. 그 이후 얼마나 많은 패킷이 도달하든 간에
하나의 패킷이 로그되기전에 20분이 걸릴 것이다. 그리고 20분 동안 패킷 적용이
없으면 Burst 하나가 다시 생길 것이다. 패킷없이 100분 이 지나면 Burst는 완전이
원상 복구 될것이다. 처음 시작할때로 돌아가는 것 이다.


재복구 시간을 59시간 이상으로는 설정하지 못한다. 그러므로 평균속도를 하 루에
1개로 설정하였다면 Burst 속도는 3 이하가 되어야 한다.


owner

이 모듈은 지역에서 생성된 패킷의 생성자의 여러 특징을 적용하려고 한다. 이것은
출력 체인에만 사용되며 어떤 패킷들(ICMP ping 응답같은)은 소유자 가 없으므로
적용되지 않는다.


--uid-owner userid

유효한 사용자 id (숫자)의 프로세서가 생성한 패킷에 적용한다.

--uid-owner groupid

유효한 그룹 id (숫자)의 프로세서가 생성한 패킷에 적용한다.

--pid-owner processid

주어진 프로세서 id 의 프로세서가 생성한 패킷에 적용한다.

--sid-owner processid

세션 그룹내의 프로세서가 생성한 패킷에 적용한다.


unclean

이 시험적인 모듈은 정확히 '-m unclean' 또는 '--match unclean'으로 지정해
주어야 한다. 이것은 무작위의 여러 건전성 검사를 한다. 이것은 제대로 검사되지
않았고 안전성 도구로도 사용되지 못한다.(아마도 이것 은 무제를 더욱 힘들게 하고
버그 그 자체일 것이다.) 이것은 옵션이 없다.


상태 적용


가장 유용한 적용 기준은 'ip_conntrack' 모듈의 접속 추적 분석을 해석하는
'state' 확장이다. 이것을 강력히 추천한다.


'-m state'를 지정함으로 '--state' 옵션을 사용할 수 있는데 이후에 콤마로
분리되는 적용할 상태들의 리스트가 온다.('!' 지시자는 사용되어지지 않는 다.) 이
상태들은 ;


NEW

새로운 접속을 만드는 패킷


ESTABLISHED

존재하는 접속에 속하는 패킷 (즉, 응답 패킷을 가졌던 것)


RELATED

기존의 접속의 부분은 아니지만 연관성을 가진 패킷으로 . ICMP 에러 나 (FTP
모듈이 삽입 되어있으면) ftp 데이터 접속을 형성하는 패킷.


INVALID

어떤 이유로 확인할 수 없는 패킷: 알려진 접속과 부합하지 않는 ICMP 에러와 'out
of memory' 등을 포함한다. 보통 이런 패킷은 DROP 된다.


7.4 타겟 지정


이제 패킷에서 어떤 검사를 할 수 있는지를 알았다. 이제 우리의 검사에 일치 하는
패킷을 어떻게 할 것인지를 말하는 것을 알아야 한다. 이것을 규칙 타겟 이라고
한다.


두개의 이미 만들어진 단순한 타겟이 있다. : DROP 과 ACCEPT. 이미 이것에
대해서는 이야기를 한 적이 있다. 적용이 되는 패킷과 그것의 타겟이 위의 두 개중
하나라면 더이상의 참고할 규칙은 없다. : 패킷의 운명은 결정 되는 것 이다.


이미 만들어진 두개의 타겟외에 두가지 형태의 타겟이 있다.: 확장과 사용자 지정의
체인들 이다.


사용자 지정의 체인들


ipchains로 부터 상속되는 iptables의 강력한 기능중의 하나는 능력되는 사용 자가
기존의 세개의 체인(입력, 출력, 포워드)외에 새로운 체인을 생성할 수 있다는
것이다. 모임의 결과 사용자 지정의 체인은 그것을 구분하기 위하여 소문 자로
나타낸다. (아래 전체 체인에 대한 작용 부분에서 어떻게 사용자 지정의 새로운
체인을 만드는지 기술할 것이다.)


타겟이 사용자 지정의 체인인 규칙에 패킷이 맞으면 패킷은 사용자 지정의 체인을
따라 움직이게 된다. 그 체인이 패킷의 운명을 결정하지 못하면 그리고 그 체인에
따른 이송이 끝나면, 패킷은 현제 체인의 다음 규칙으로 돌아온다.


그림을 보자. 두개의 체인이 있고 그것이 입력과 테스트라는 사용자 지정의 체인이
라고 가정하자.


          `INPUT'                         `test'
         ----------------------------    ----------------------------
         | Rule1: -p ICMP -j DROP   |    | Rule1: -s 192.168.1.1    |
         |--------------------------|    |--------------------------|
         | Rule2: -p TCP -j test    |    | Rule2: -d 192.168.1.1    |
         |--------------------------|    ----------------------------
         | Rule3: -p UDP -j DROP    |
         ----------------------------


192.168.1.1 로부터 와서 1.2.3.4 로 향하는 TCP 패킷이 있다고 가정한다. 이것은
입력 체인으로 들어온다. Rule1 을 검사한다. 맞지 않음. Rule2 맞음. 그것의 타겟
은 테스트, 고로 다음 검사할 규칙은 테스트의 시작이다. 테스트의 Rule1 이 맞다.
그러나 이것이 타겟을 지정하지 않는다. 그러므로 다음 규칙이 검사된다. Rule 2.
맞지 않다. 그 체인의 끝에 도달했다. 다시 입력 체인으로 돌아가서 Rule3 을 검사
한다. 그것도 맞지 않다.


여기서 패킷의 이동경로를 그림으로 나타냈다.

                                v    __________________________
         `INPUT'                |   /    `test'                v
        ------------------------|--/    -----------------------|----
        | Rule1                 | /|    | Rule1                |   |
        |-----------------------|/-|    |----------------------|---|
        | Rule2                 /  |    | Rule2                |   |
        |--------------------------|    -----------------------v----
        | Rule3                 /--+___________________________/
        ------------------------|---
                                v


사용자 지정의 체인에서 대를 사용자 지정의 체인으로 갈수 있다. (그러나 루프 를
돌수는 없다. 루프를 발견하게 되면 패킷은 DROP 된다.)


iptables로의 확장 : 새로운 타겟


타겟의 다른 형태는 확장이다. 타겟 확장은 커널 모듈로 구성된다. 그리고 iptables
에 대한 선택적 확장은 새로운 명령행의 옵션을 제공한다. 기본적으로 넷필터
배포에 포함된 몇몇의 확장은 다음과 같다.


LOG

일치하는 패킷의 커널 로그를 제공한다. 이것은 부가의 옵션을 제공한다.

--log-level

레벨 숫자나 이름이 따라온다. 유효한 이름은 (상황에 따라 다르다) 'debug'
'info', 'notice', 'warning', 'err', 'crit', 'alert', 'emerg' 이고 이것 은 각각
숫자 7 에서 0 에 대응한다. 이런 레벨에 대한 설명은 syslog.conf 의 man 페이지를
보라.


--log-prefix

14자 까지의 문장이 따라온다. 이 메세지는 로그 메세지의 시작부분으로 보내져서
확인에 사용될 수 있다.


이 모듈은 'limit' 타겟 다음에 사용하면 가장 효과적이다. 그래서 로그가 넘
지나지 않도록 할 수 있다.


REJECT

이 모듈은 'DROP'과 같은 효과를 나타낸다. 다만, 'port unreachable' 이라는 에러
메세지를 ICMP 로 보낸다. 주의할 것은 ICMP 에러 메세지는 다음의 경우 보내 지지
않는다 ( RFC 1122 를 보라) :


검사된 패킷이 ICMP 에러메세지이거나나 알수 없는 ICMP 형태인 경우
검사된 패킷이 헤더가 없는 분절인 경우
너무 많은 ICMP 에러 메세지를 그 목적지로 보낸 경우.

REJECT 는 '--reject-with'라는 옵션을 가지는데 이것은 사용할 응답 패킷을
변경한다. 자세한 것은 메뉴얼 페이지를 보라.


특별한 미리 만들어진 타겟


두개의 미리 만들어진 타겟이 있다 : RETURN, QUEUE


RETURN은 한 체인의 끝으로 보내지는 것과 같은 효과가 있다. : 미리 만들어진 체
인의 경우 그 체인의 정책은 실행이다. 사용자 정의 체인의 경우 이 체인으로 점프
하는 규칙의 바로 다음인 이전 체인으로 이동한다.


QUEUE은 특별한 타겟으로, 사용자공간의 작업을 위해 패킷을 대기하도록 한다. 패킷
을 위해서 대기하고있는 것이 없다면(즉, 이 패킷을 다룰 프로그램이 아직 씌어져
있지 않다면) 패킷은 DROP 될 것이다.


7.5 전체 체인에 대한 작용.


iptables의 유용한 기능주 하나는 여러 관계가 있는 규칙을 하나의 체인속으로
그룹화 하는 것이다. 체인의 이름은 어떤 것을 사용할 수도 있으나 미리 만들어 진
체인과의 혼동을 막기 위하여 소문자를 사용하기를 권한다. 체인의 이름은 16 자
까지 가능하다.


새오룬 체인 생성


새로운 체인을 만들어 보자. 나는 매우 상상력이 좋은 사람이므로 이것을 테스트
라고 부르기로 하겠다. '-N' 또는 '--new-chain' 옵션을 사용한다.


# iptables -N test
#


단순하다. 이제 이 체인에 상세한 규칙을 적용할 수 있다.


체인 제거


체인을 제거하는 것도 단순하ㄷ. '-X' 나 '--delete-chain' 을 사용한다.


# iptables -X test
#


체인을 제거 하는데는 몇가지 제한이 있다. 이것은 비어있어야 한다. (아래의 체인
비우기를 보라) 그리고 그것은 다른 어떤 규칙의 타겟도 아니어야 한다. 미리
만들어진 세개의 체인은 제거할 수 없다.


체인의 이름을 지정하지 않으면 모든 사용자 정의의 체인은 제거된다.


체인 비우기


하나의 체인의 모든 규칙을 비우는 간단한 방법이 있으니, '-F' ('--flush')
명령이다.


        # iptables -F forward
        #


체인을 지정하지 않으면 모든 체인의 규칙이 지워진다.


체인 규칙 나열하기


한 체인의 모든 규칙은 '-L' 명령으로 나열할 수 있다.


각 사용자 정의의 체인을 나열했던 'refcnt' 는 그 체인을 그들의 타겟으로하 는
규칙들의 번호이다. 체인이 제거되기 위해서는 이것이 '0' 으로 되어야 한다.
(그리고 그 체인은 비어야 한다)


체인의 이름이 생략되면 비어있는 것을 포함한 모든 체인이 나열된다.


'-L' 명령에 따르는 옵션은 세개가 있다. '-n' (numeric) 옵션은 iptables가
여러분이 DNS 요구를 필터링 아웃한 경우나 DNS가 적절이 설정되어 있지 않다면
오랜 시간이 걸리는, IP 주소를 찾는 것을 예방하는 아주 유용한 옵션이다. 이것 은
TCP와 UDP 포트가 이름이 아닌 숫자로 출력되도록 하기도 한다.


'-v' 옵션은 규칙의 자세한 정보(패킷과 바이트 카운터, TOS 비교, 인터페이서와
같은)를 나타낸다.


패킷과 바이트 카운트는 'K'(1000), 'M'(1,000,000), 'G'(1,000,000,000) 와 같은
접미어와 함께 나타난다. '-x' (확장 수) 지시자를 사용하면 얼마나 큰 숫자든 전
체 숫자가 나타난다.


카운트 리셋트 ('0'으로 만들기)


이것은 카운트를 리셋하는데 유용하다. 이것은 '-Z' ('--zero') 옵션으로 가능하다.


이것의 문제점은 리셋하기 직전의 카운트 값을 알필요가 있을 때가 가끔 있다는 것
이다. 이러한 경우의 예로, 어떤 패킷이 '-L' 과 '-Z' 명령 사이에 지나갈 수 있다.
이런이유로 카운트를 읽는 것과 동시에 리셋하기위해서 '-L' 과 '-Z' 명령을 같이
사용할 수 있다.


정책 설정


우리가 이전 체인을 패킷이 어떻게 지나가는가를 의논할 때, 미리 만들어진 체인의
끝에 패킷이 다다렀을때 무슨 일이 일어날 것인가를 설명하였다. 이 경우 체인의
정책이 그 패킷의 운명을 결정한다. 미리 만들어진 체인(입력, 출력, 포워드)만이
정책을 가지는데, 이것은 사용자 정의의 체인의 끝에 다다른 패킷의 이동은 이전
체인에서 요약되어지기 때문이다.


정책은 ACCEPT 또는 DROP 이 될수 있다.


ipchains와 ipfwadm을 사용하기


배포되는 넷필터에는 ipchains.o 와 ipfwadm.o 라는 모듈이 있다. 이것을 여러 분의
커널에 포함시키면 이전과 똑 같이 ipchains 나 ipfwadm을 사용할 수 있 다. ( 주의
: 이들은 iptables.o, ip_conntrack.o, ip_nat.o와 호환성이 없다)


이것은 아직 한동안은 지원될 것이다. 이들을 완전히 대치하는 안정판이 나오 는데
까지는 2 * [대치할 것이라는 발표 - 첫번째 안정판] 이라는 공식이 적 용된다고
생각한다.


즉, ipfwadm의 경위 이것의 지원이 종료될 때는 :


2 * [October 1997 (2.1.102 release) - March 1995 (ipfwadm 1.0)]
        + January 1999 (2.2.0 release)
    = November 2003.


그리고 ipchains의 경우 이것의 지원이 종료될 때는 :


2 * [August 1999 (2.3.15 release) - October 1997 (2.2.0 release)]
        + January 2000 (2.3.0 release?)
    = September 2003.


그러므로, 2004년 까지는 걱정할 필요가 없을 것이다.


8. iptables와 ipchains의 차이점


첫째로, 미리 만들어진 체인의 이름들이 소문자에서 대문자로 바뀌었는데 이것은
입력과 출력 체인은 이게 지역 넷으로 향하는 그리고 지역에서 생성된 패킷만을
적용하기 때문이다. 이것은 모든 들어오는것과 나가는 패킷을 다룬다.
'-i' 지시자는 들어오는 인터페이스만 의미하고 입력 과 포워드 체인 에서만
작동한다. 포워드 나 출력 체인에 사용되었던 '-i' 는 '-o'로 바꿔야 한다.
이제 TCP 와 UDP 포트는 --source-port 또는 --spotr (또는 --destination-port /
--dport) 옵션과 함께 사용되어져야 할 필요가 있고 '-p tcp' 또는 '-p udp' 옵션과
함께 사용되어져야 한다. 그러면 이것은 TCP 또는 UDP 확장을 각각 적재 할 것이다.
(ipt_tcp 와 ipt_udp 모듈을 수동으로 적제 하기위해서 포함 시킬 수도 있다.)
TCP -y 지시자는 --syn으로 바뀌었고 `-p tcp'다음에 와야 한다.
DENY target 는 DROP 으로 바뀌었다.
Zeroing single chains while listing them works.
만들어진 체인을 '0'으로하면 정책 카운터도 지워진다.
체인을 나열하는 것은 카운트의 스넵샷을 제공한다.
REJECT 와 LOG 는 확장된 target이다. 즉, 이것들은 독립된 커널 모듈이다는
의미이다.
체인 이름은 16자 까지 가능하다.
MASQ 와 REDIRECT 는 더이상 target 이 아니다. iptables은 패킷을 변화 시키지
않는다. 이것을 위해서 NAT라는 하부구조가 있다. 이것은 ipnatctl 하우두를
읽어보아라.
그 외의 것들은 잊어먹었다.
===============================================================================


named.conf - option최적화

Posted 2008. 11. 6. 16:51

출처 : http://cafe.naver.com/dnspro/269



7.1 설정 최적화 검사

http://www.serverchk.com/

http://www.dnsreport.com/에서 검사

 

# named-checkconf /etc/named.conf

named.conf설정내용 사전오류검사 명령어임. 오류가 없을시 아무것도 나오지 않는다.

 

7.2Options 튜닝하기

 

Bind8이 보안상 취약하여 Bind8에서 사용하는 옵션이 대부분입니다.

Bind9버전에서는 일부분은 보안취약점이 개선되어 기본으로 적용되어 있어 오류로 표시되는 옵션이 있으므로,

messages파일보고 불필요하면 제거하도록 한다. (진한 부분은 공통으로 설정이 필요한부분이다.)

 

# vi/etc/ Named.conf

 

options {

directory "/var/named";

named 데몬이 인식하는 기본 디렉토리를 지정함. 해당디렉토리에 zone File존재

// pid-file "/var/named/named.pid";// named pid 파일을 남길 위치

// statistics-file "/var/named/named.stats";// 통계정보를 남길 위치

memstatistics-file "/var/named/named.memstats"; // 메모리 통계정보 파일을 위치

dump-file "/var/adm/named.dump"; // 네임서버의 메모리 상태 정보 파일 위치

 

version Unknown !!;

#dig @203.231.124.14 txt chaos version.bind 로 원격에서 Bind버전 확인시후, 보안취약점을 이용해 공격할수 있음으로 보안상 사용 Bind버전을 안보이게함.

 

edns-udp-size 512 ;

EDNS등사용시 512k가 넘어 Pix-Firewall등에서 Drop되는 부분을 해결하는 부분

dns-udp사이즈를 512가 넘지 않도록 제한 설정하는것임.

DNS udp패킷사이즈가 512가 넘으면 tcp패킷으로 넘어감.

 

check-names master ignore ;// 필수 권장설정

check-names slave ignore ;// 권장설정

자신이 master인경우 존파일 이름 검사를 무시한다.

기본값 Fail. RFC에 어긋나는 설정(언더바(_))이 있는 zone파일의 경우는 해당 도메인이 정상적으로 동작하지 않게 되므로, 반드시 ignore로 설정을 변경해야한다.

예전 4.9.4이전, 9.1.0이내의 Bind에서는 이름검사가 구현되지 않았다.

에러 형식:

May 11 08:55:46 ns1 named[28399]: owner name "chungju_s.s.co.kr" IN (primary) is invalid - rejecting
May 11 08:55:46 ns1 named[28399]: s.co.kr:200: owner name error

 

다음은 버전8의 기본값

check-names master fail; // 언더바가 들어가더라도 현재는 정상 응답한다

check-names slave warn; // 언더바가 들어가더라도 현재는 경고만 보내주고 응답한다

Check-names response ignore;// 언더바가 들어가더라도 현재는 정상 응답한다

오류에 대해 무시하고 질의에 대한 응답을 하도록 한다.

 

 

Check-names response ignore;

디폴트가 ignore이므로 설정을 하지 않아도 된다.

이름을 질의해왔을경우 응답이 RFC규약을 따르지 않는 응답이라도 무시하고 응답한다.

Check-names response fail; 이라면, 응답이 RFC규약에 어긋나면 응답거부하기 때문에 해당 네임서버에 언더바(_)가 들어간 사이트를 질의한경우 접속이 안된다.

> drop_b.yejin.pe.krcom

Server:ns.yejin.pe.krcom

Address:203.231.124.14

*** ns.yejin.pe.krcom can't find drop_b.yejin.pe.krcom: Query refused

 

notify no;

Bind 8,9 DNS notify yes가 기본임.

Zone transfer request 도스공격방지를 위한 보안설정임.

존 업데이트에 대한 notify 메시지를 사용하지 않음.

notify메시지 => Master서버가 영역정보가 바뀌었을때 Slave서버에게 알리는 메시지

단점: Slave가 업데이트하는데 TTL시간까지 기다려야함.

 

Allow-notify { 203.231.124.15; };

192.168.0.1 notify메시지를 보낼수 있도록 허용함.

주 마스터네임서버가 아닌 다른네임서버로부터 오는 NOTIFY메시지를 수신허용.

 

multiple-cnames yes;

Cname을 여러개 사용가능하도록 설정함.

 

maintain-ixfr-base yes;

주 마스터네임서버는 시리얼 번호가 증가할때마다 슬레이브에 Notify를 알려준다.

슬레이브서버는 알림을 받을때마다, 마스터네임서버의 영역시리얼 번호를 확인해 상황에 따라 전체 영역전송한다. 동적 업데이트가 매우 빈번하게 발생하는 큰 영역을 운영하는경우는 문제가 되어 증진적 영역전송(IXFR) 이라는 개념이 나왔다.

Bind 8.2.3 , Bind 9 이상에서 동작하며, 변경된 정보만 영역전송를 진행한다.

동적업데이트를 이용해 영역데이터를 수정할 때만 문제없이 잘 동작한다.

 

transfer-format many-answers;

전형적인 영역전송은 각 dns 메시지에 하나의 리소스 레코드를 담고 있는데 이것은 공간 낭비이다. 이러한 문제를 해결 하기 위해 설정한다.

단점은 영역전송이 실제로 새로운 형식을 이용해 시간이 더 오래 걸릴수 있다.

대역폭이나 CPU사용량의 관점에서는 효율적이나 시간이 더 오래걸려 완료된다.

슬레이브의 대부분이 BIND8이나 9 또는 MS DNS서버를 운영하고 있다면 권장설정임.

 

serial-queries 100 ;

slave의 빠른 업데이트를 위해 soa 쿼리를 100까지 설정한다.

 

listen-on { 203.231.124/24; };

네임서버가 어떤 네트워크 인터페이스를 청취하면서 질의를 기다리 것인지를 명시

 

 };

 

 

7.3 Bind버전확인하기

# dig txt chaos version.bind.

# dig @200.1.1.1 txt chaos version.bind.

 

7.4 질의제한:

7.4.1 해당 DNS서버의 named.conf 에 질의를 허용할 IP블록을 등록한다.

# more/etc/named.conf

options {

directory "/var/named";

allow-query { 203.231.124.14; 200.1.1.1/24; };//자체네임서버는 들어가야함.

};

 

7.5 개별도메인에 Notify허용법

named.conf option부분에notify no; 라고 한경우 Master가 Slave에 정보변경시 바로 notify를 하지 않고, SOA레코더값이 지정되어 있는시간에 전송요청을 한다.

만약  option부분에는 no로 되어 있으나 특정도메인은 notify목록에 추가하려면zone구문에서 also-notify라는 서버구문을 이용한다.

 

zone "congress.go.kr" {

allow-update { none; };

allow-transfer { 127.0.0.1; 10.201.27.3; 10.201.14.45; };

allow-query { any; };

notify yes;

also-notify { 10.201.27.3; };//자신의 슬레이브에 변경을 알려주도록 설정.

allow-transfer { none; };

};

 

7.6IXFR – BIND 8.2.3이상, 다음은 BIND8에서의 IXFR설정법입니다.

동적 업데이트만 이용해 영역데이터를 수정할때만 문제없이 동작

options {

maintain-ixfr-base yes;

max-ixfr-log-size 1M;

};

server 200.1.1.110 {

support-ixfr yes;

};

 

 

7.7 포워더 설정.

options {

forwarders { 168.126.63.1; 203.255.112.34; };

};

도메인 질의에 대한 포워딩

1) 캐시 데이터베이스에 있다면 이 정보를 대답한다.

2) 캐시에 없으면, 네임서버는 질의를 포워더에 보내고 대답을 기다린다.

3) 응답이 오지 않으면, 정상적인 동작을 다시 개시해 원격서버에 접속하게 된다.

 

options {

forwarders { 168.126.63.1; };

forward only;

};

도메인 질의에 대한 포워딩

1) 캐시 데이터베이스에 있다면 이 정보를 대답한다.

2) 캐시에 없으면, 네임서버는 질의를 포워더에 보내고 대답을 기다린다.

3) 응답이 오지 않으면, 응답을 하지 못한다.

 

7.8 영역포워드 – (BIND 8.2부터, BIND 9.1.0부터)

7.8.1  귀하의 Cache DNs에서 yejin.pe.kr사이트만 정상적으로 레졸루션 되지 않을시 우선조치

       해당 사이트 질의시 다른 네임서버에게 포워드하여 해당 네임서버가 응답하도록함.

zone " yejin.pe.kr " IN {
type forward ;
forwarders { 168.126.63.1; };
};

 

7.8.2 Yahoo.com등 특정사이트가 접속이 안될때 -Name:www.yahoo.akadns.net

네임서버에서 yahoo의 네임서버인 akaff 찾을땐 특정 IP로 포워드 한다.

Forward하는법.

Zone "akadns.net" IN {
        type forward ;        forwarders { 65.203.234.27; 193.45.1.103; 63.209.170.136; 80.67.67.182; 63.241.73.214; 206.132.100.108; };
};

 

7.8.3 설정 파일 전체에 영향을 미치는 options구문속의 forwarder설정을 무력화시키기.

 

로컬에 있는 도메인을 forwarder인 외부에 질의하게 되는 부분을 해결.

options {

type forward ;forwarders { 203.255.112.34; 203.255.117.34; };

};

 

zone " yejin.pe.kr " IN {
type forward ;
forwarders { };
};

 

 

7.9 비재귀적 네임서버 (네임서버 전용인 경우 설정함)

options {

recursion no;

No: 자신이 호스팅하고 있는 도메인에 대한 DNS응답만 처리한다.
no
로 하면 일반 질의에 대한 응답을 하지 않음. 설정에 주의해야한다.

         네입서버 전용으로사용하는경우 설정됨. Cache DNS로는 사용못함.

        OPEN DNS취약점 해결됨. 주의점:  resolve.conf에 외부 DNS를 지정해야함. 예;168.126.63.1

   

Yes : 일반적인 도메인서버로 사용하는것이다..

 

options {

fetch-glue no ;

질의에 대한 응답값으로 NS레코드는 있지만, 해당 네임서버의 A레코드가 없을경우 이IP를 다시 찾기위해 질의를 한다. 이경우 Cache poisoning될수 있는 여지가 있어 no로 설정하여 질의를 하지 않게 한다 Bind8만 설정 필요, 9는 기본적으로 no로 동작함.

 

 

7.10 엉터리 네임서버 이용금지. - blackhole설정

이 목록에 있는 네임 서버에는 질의를 보내지도 않고 이들이 보내는 질의에도 응답하지 않는다.

목록에 있는 네임서버에는 질의를 보내지도 않고, 보내는 질의에도 응답하지 않는다

blackhole {

210.116.96.112/32;

};

또는

blackhole {

bogon;

};

acl "bogon" {

0.0.0.0/8;

10.0.0.0/8;

192.168.0.0/16;

};

bogon 네트워크 : IANA에 의해 테스트, 멀티케스트, 또는 실험목적을 위해 예약된 아이피

네트워크에 실제로 존재하지 않는 bogon ACL 대역에서 오는 querydrop 시킴

 

 

7.11네임서버별 영역전송 개수 제한

transfers-per-ns 4;

네임서버가 하나의 원격네임서버로부터 얼마나 많은 영역을 요청 받는지 제한한다.

주로 bind8에서 사용, 사용하지 않아도됨.

 

7.12 영역 전송 시간 제한

max-transfer-time-in 180;

최대 영역전송(zone transfer)시간을 디폴트(120)에서 180분으로 설정 아주 큰 Zone File을 가지고 올때 발생될수 있는 문제를 예방한다.

시간을 줄이면, named-xfer 프로세스가 불필요한 자원을 점유하는 것을 막을수도 있다.

주로 bind8에서 사용, 사용하지 않아도됨.

 

7.13 청소주기

cleaning-interval 120;

캐시속의 오래된 항목을 주기마다 능동적으로 뒤지면서 오래된 레코드를 삭제한다.

디폴트 60분, CPU많이 사용하면 120분으로 늘려준다.이 주기를 0으로 설정하면 캐쉬청소를 하지 않는다.

실행된 로그내용:

12-May-2005 13:44:29.123 maintenance: info: Cleaned cache of 123874 RRsets
//
named 데몬에서 잡고 있는 메모리가 이 설정에 의해 줄거나 하지는 않으며 이미 잡혀 있는 메모리 자체에 있는 데이타를 날리고 제 사용하는 방식을 택하고 있는 것으로 보입니다.

 

7.14 인터페이스주기

interface-interval 0;

네트워크 인터페이스가 up/down 상태인지 체크하는시간.

불필요한 오버해드를 없애기위해 인터페이스체크 주기를 0으로 설정해 새로운인터페이스를 훓어보지 않게 할수 있다.

 

 

 

7.15 통계주기

statistics-interval120;

통계주기 네임서버 통계정보를 남길 시간을 120분으로 정함 (기본값 60)

값을 0으로 설정하면 주기적인 통계덤프를 하지 않는다. 성능향상과는 무관한 옵션.

 

7.16 부정적 TTL시간

max-ncache-ttl 3600;

부정적 캐싱 ttl 시간을 3600(1시간)으로 정함. 기본값은 10800(3시간)

 

 

7.17 질의제한:

1) 해당 DNS서버의 named.conf 에 질의를 허용할 IP블록을 등록한다.

외부에서 사용못하도록함.

# more/etc/named.conf

options {

directory "/var/named";

allow-query {203.231.124.14; 200.1.1.1/24; };//자체네임서버는 들어가야함.

 

or

options {

allow-query {

trusted;

};

 

acl "trusted" {

210.103.175.0/24;

127.0.0.1;

//any;

};일반적으로 any를 사용. 설정된 IP블록이외에서는 해당서버를 이용해 쿼리를 할수없음.

 

7.18리졸빙 네임서버를 더욱 안전하게 운영

options {

           use-id-pool yes ;

안전한 서버운영을 위해 네임서버가 질의와 응답에 붙이는 메시지 id를 랜덤한 순서로

}; 

 

7.19 Zone Transfer 제어 - 인가 받지 않은 영역 전송금지

options {

allow-transfer {         xfer;    // Zone tranfers limited to members of the"xfer" ACL.
};

};

 

acl "xfer" {

200.1.1.34;

200.1.2.0/24;// 사용하는 네임서버 IP는 모두 등록해야한다.

    // none;// Allow no transfers일 경우.

};

용도: 서버로부터 영역을 zone transfer할수 있는 사용자들은 영역의 모든 호스트를 보게됨으로서 보안상 설정을 함.(BIND8을 기준으로 작성됨.)

특정 IP블록에서만 Zone Transfer를 할수 있도록함.

Zone transfer는 일반적으로 slave에서 Masterzone을 가져가므로 slaveip-address나 블록을 넣어준다.

 

설정법

#파일위치:/etc/named.conf,// 환경 설정파일은 options 안에 정의

options {

directory "/var/named";/* zone 화일들의 위치 */

       allow-transfer { 127.0.0.1;200.1.1.0/24;200.1.2.0/24;};/* 허용ip */

};

Slave서버의 zone구문은zone-transfer가 일어나지 않으므로 다음과 같이 설정한다.

 

options {

directory"/var/named";/* zone 화일들의 위치 */

allow-transfer{ none;};/* zone transfer를 허용하지 않는다 */

};

- 이상 끝 -


'OS 운영체제 및 보안 > Linux' 카테고리의 다른 글

서버설치후 해야할 일  (0) 2008.11.06
chattr 와 lsattr 파일 권한  (0) 2008.11.06
BIND 최신버전으로 업그레이드  (0) 2008.11.06
find 유용한 사용법  (0) 2008.11.06
iptables  (0) 2008.11.06
DNS 서버 구성하기  (0) 2008.11.06
Vi 편집기 사용법  (0) 2008.10.24
Vi 편집기 사용법  (0) 2008.10.24
crontab 간단 정리  (0) 2008.10.24
Named 최신버전으로 업그레이드  (0) 2008.10.24

DNS 서버 구성하기

Posted 2008. 11. 6. 16:50


1. IP 주소와 도메인
  인터넷에 연결된 수많은 서버와 클라이언트 컴퓨터는 각자 고유한 IP주소를 가지고 있는데 이 IP는
 오직 자기만의 주소이다. 주민등록번호가 다르듯이 IP주소도 똑같은 경우가 없다. IP는 숫자로 된
 배열로 되어있는데(IP에 대해서는 네트워크 책 참조), 많은 수의 갯수를 외우기는 상당히 어렵다.
 따라서, 알기 쉽게 등장한 것이 도메인 네임이다.


2. DNS서버에 대하여
 우리는 흔히 특정한 사이트에 접속하기 위해 도메인이름을 입력한다. 그러나 실제적으로 인터넷은
IP주소기반이기 때문에 해당사이트의 IP주소를 알아야 한다. 이 때 우리가 이용하는 것이 네임서버
이다. 네임서버는 특정한 클라이언트로부터 특정한 도메인에 대한 요청이 왔을 경우 Root 네임서버와
다른 네임서버로 부터 정보를 얻어 요청한 도메인에 대한 IP주소를 알려주는 역할을 한다. 또한 각각
의 도메인네임서버들은 2차도메인도 부여하고, 다른 서버로부터 오는 도메인에 대한 요청도 응답한다.


3. DNS서버의 종류와 역할
 (1) 설명: DNS서버는 크게 Primary서버, Secondary서버, Caching Only서버로 나뉜다. 자신의
          도메인을 가지기 위해서는 가장 기본이 되는 것이 Primary서버이고, Secondary서버 및
          Caching Only서버는 보조 및 백업 서버 혹은 속도를 빠르게 하기 위해서 필요한 서버이다.
          일반적으로 Secondary서버는 Primary 서버가 다운되었을 경우를 대비해 백업할 경우에
          사용하고,  Caching Only서버는 기간망간의 캐싱을 위해서 사용한다.
 (2) 종류와 역할
   1) Primary Name Server: 도메인 네임서버 사용시에 꼭 구축해야 하고, 보통 Master DNS라고
                          부른다.
   2) Secondary Name Server: 주 도메인서버인 Master DNS의 백업을 담당하고 Slave DNS라고
                            부른다. 반드시 구축할 필요는 없다.
   3) Caching Only Server: 서버에 기록된 정보가 요청이 올 경우에 응답해주는 서버이다. 즉 한번
                          요청한 정보를 서버에 기록해 두었다가 다시 동일한 요청이 왔을 때 직접
                          조회하지 않고 바로 응답하도록 해주는 서버이다.


4. 네임서버 구축의 개요
 (1) 개요: 네임 서버를 운영하기 위해서는 서버에서 도메인 네임 서비스를 수행하는 프로그램을 설
          치해야 한다. Red Hat은 BIND(Berkeley Internet Name Domain)이라는 DNS서버용
          소프트웨어(데몬)을 제공한다. 또한 이 네임서버의 데몬이름은 named이다.
 (2) RedHat Linux와 rpm 패키지
   RedHat Linux는 3개의 rpm패키지로 제공한다. DNS 서버관련 패키지는 bind 및 bind-utils이고,
  기본 환경설정파일 관련 패키지는 caching-nameserver로 제공이 된다.
 (3) bind관련 파일 및 디렉토리
   1) 주환경설정파일
     /etc/named.conf
      => named데몬이 작동할 때 처음으로 참조하는 파일로 환경설정과 밀접한 관련이 있다.
        이 파일에서는 도메인별 zone파일을 지정하는 역할을 주로 한다.
   2) 시스템 부팅시 자동 실행 스크립트 파일
     /etc/rc.d/init.d/named
      => named데몬을 실행시킴에 있어 최적화시킨 파일이다. 네임서버를 작동시키고 중단시킬 때
        사용한다. 보통 stop, start, restart, reload 등의 인자값을 사용하는데, DNS에서는
        restart하면 caching정보가 사라지므로, 보통 reload를 많이 사용한다.
   3) /var/named 디렉토리: 루트 도메인 서버에 대한 정보가 담긴 zone파일인 named.ca와
                          localhost에 대한 zone파일인 localhost.zone, reverse zone파일인
                          named.local 파일 등 도메인 설정을 위한 zone파일이 위치하는
                          디렉토리이다.
   4) localhost와 루트 네임서버 정보 데이터베이스파일
    ㄱ. /var/named/named.ca       : 루트(.) 네임서버에 대한 정보가 있는 데이터베이스 파일이다.
    ㄴ. /var/named/localhost.zone : 리눅스 시스템에 부여되는 호스트이름인 localhost에 대한
                                   zone파일로 일종의 sample파일이라고 보면 된다.
    ㄷ. /var/named/named.local    : localhost의 Reverse zone파일이다. Reverse zone파일 구성을
                                   위한 sample파일이라고 볼 수 있다.
 (4) DNS 설정하기
   1) 설명: DNS설정에서 핵심은 named.conf파일과 존파일이다. 이 두 가지의 파일을 설정하면 된다.
           존파일의 이름은 관리자가 임의로 부여하여 사용할 수 있다. named.conf 파일이
           DNS설정의 뼈대이고, 실제 서버의 내용은 존파일에 기록한다.
   2) 역할
    ㄱ. /etc/named.conf: 서버에서 사용하는 도메인별로 존파일을 지정한다. 리버스존파일의 선언도
                        해준다.
    ㄴ. zone파일: named.conf파일에서 지정한 경로에 파일을 정해진 포맷으로 만든다. 이 존파일의
                 역할은 2차도메인 부여 등 사용하는 도메인에 대해 주 설정을 담당한다.


5. /etc/named.conf파일
 (1) 파일의 구성과 특징
   1) 파일의 구성은 크게 주석문과 구문으로 구성되어 있다.
   2) 기본구문은 DNS서버 구동시 꼭 필요하므로 지우지 않도록 한다.
   3) 주석은 실제 내용의 설정과 관계없이 설명 등을 붙힐 때 사용한다. 주석은 C나 C++에서 사용하
     는 스타일과 같다.
      예) // => 한줄정도의 주석을 달 경우, 또는 '#'도 사용가능하다.
          /*  */  => 여러라인의 주석을 달 경우 사용한다.
   4) 각 설정은 세미콜론(;)으로 한다.
 (2) 기본설정
    // generated by named-bootconf.pl
    options {
            directory "/var/named";
            /*
             * If there is a firewall between you and nameservers you want
             * to talk to, you might need to uncomment the query-source
             * directive below.  Previous versions of BIND always asked
             * questions using port 53, but BIND 8.1 uses an unprivileged
             * port by default.
             */
            // query-source address * port 53;
    };

    //
    // a caching only nameserver config
    //
    controls {
        inet 127.0.0.1 allow { localhost; } keys { rndckey; };
    };
    zone "." IN {
            type hint;
            file "named.ca";
    };

    zone "localhost" IN {
            type master;
            file "localhost.zone";
            allow-update { none; };
    };

    zone "0.0.127.in-addr.arpa" IN {
            type master;
            file "named.local";
            allow-update { none; };
    };
    include "/etc/rndc.key";
 (3) Options
   1) 설명: 네임서버가 동작함에 있어 필요한 여러가지 설정을 하는 영역이다. 네임서버에 쓰이는
           존파일의 위치를 적는 directory 항목은 꼭 적어야 한다.
   2) 항목
    ㄱ. directory "/var/named";
         => 네임서버에서 데이터베이스 역할을 하는 존(zone)파일의 위치를 설정한다. 보통 기본값
           으로 /var/named 디렉토리가 지정된다.
    ㄴ. dump-file "/var/tmp/named_dump.db";
         => named는 정보가 갱신될 때 dump파일로 저장하는데 그 덤프파일이 생성될 위치와 파일명
           을 지정한다.
    ㄷ. statistics-file "/var/tmp/named.stats";
         => 네임서버의 통계를 낼 경우에 사용하는 옵션으로 메모리 통계 파일을 생성할 위치와
           파일명을 지정한다.
    ㄹ. forward (only|first);
         => 보통 forwarders 옵션과 함께 사용되며, only나 first 두 값 중 하나를 갖는다. only는
           자신에게 들어온 도메인 질의를 지정한 다른 서버로 넘기도록 하는 것으로 다른 서버가
           그에 대한 응답이 없을 경우 그 자신도 그 질의에 대해 응답하지 않을 경우에 설정한다.
           first는 타 서버에서 응답이 없을 때 자신이 응답하도록 할 때 설정한다.
    ㅂ. forwarders { 네임서버주소1; 네임서버주소2;....};
         => 도메인에 대한 질의를 다른 서버로 넘길 때 사용하는 옵션으로 복수 형태로
           지정가능하고 구분은 세미콜론(;)으로 한다.
    ㅅ. allow-query { 192.168.0/24; };
         => 네임서버에 질의할 수 있는 호스트를 지정한다. 위와 같이 지정하면 192.168.0.0 네트
           워크주소를 가진 호스트만이 질의할 수 있다.
    ㅇ. allow-transfer { 192.168.0/24; };
         => zone 파일의 내용을 복사할 대상에 제한을 걸 때 지정한다. 이 항목을 명기하지 않았을
          경우 기본적으로는 제한이 없다.
   3) 참고: ACL
    ㄱ. 설명: ACL이란 Access Control List의 약자로 여러 호스트를 하나의 명칭으로 지정하여
             사용하는 방법이다. allow-query나 allow-transfer 사용시 ACL을 이용하여 리스트를
             만든 후 사용가능하다.
    ㄴ. 사용예
        acl  "accesslist" { 192.168.0/24; 192.168.1.20; };
    ㄷ. 주의점: acl의 선언은 options {  }; 이전에 해야 한다.
   4) 사용예
     acl "member" { 210.96.52.100; 203.247.40/24; 211.58.96.100; };
     options {
             directory "/var/named";
             allow-transfer { 203.247.50/24; 203.247.51.30; };
             dump-file "/var/named/named_dump.db";
             statistics-file "/var/named/named.stat";
             forward only;
             forwarders { 203.247.32.31; };
             allow-query { 203.247.50/24; 203.247.51.33; member; };
     };
 (4) zone 구문
   1) 설명: 실제적으로 도메인을 관리하는 데이터베이스파일인 zone파일을 지정한다. 이 zone구문
           은 크게 master, slave, hint(캐쉬서버)의 세가지 타입이 있다. 위의 예에서 보면
           zone "."이라는 항목이 있다. "."는 가장 상위도메인을 나타낸다. (참고로 말하면 원칙적
           으로 도메인을 칠때는 맨뒤에 "."을 붙여야 한다. 예를 들면 다음과 같이 "www.linux.co.
           kr."해야 한다. 그러나, 보통은 생략해서 사용해도 된다.) 도메인을 찾을 때는 가장 상위
           도메인서버에서 차례대로 트리구조형태로 찾는다. 또한 참조하는 파일인 named.ca는 일종
           의 캐시파일로서 인터닉(Internic)에서 배포하는 파일이므로 그 부분은 수정해서는 안된
           다. Reverse zone파일도 설정할 수 있다. Reverse zone 파일이란 IP를 도메인으로 변경하
           기 위해서 필요한 존파일이다. 몰론 설정안해도 무방하다. 또한 zone "0.0.127.in-addr.
           arpa"는 로컬호스트에서의 Reverse 파일에 관한 부분으로 이 부분 역시 설정그대로 둔다.
   2) 기본설정형식
     zone "도메인이름" {
       type (master | slave | hint);
       file "존파일이름";
       allow-update { none; };
     };
   3) 항목설명
    ㄱ. 도메인이름
      a. 설명: 일반적으로 해당 도메인이름을 적는다. 그 외에 "."은 캐시서버를 의미하고,
              리버스존파일의 선언은 "0.0.127.in-addr.arpa" 형태로 한다.
      b. 설정예
        1. zone "linux.co.kr"
        2. zone "50.247.203.in-addr.arpa"
    ㄴ. type
      a. 설명: type은 1차 네임서버와 2차 네임서버의 종류를 구분할 때 사용한다. 값에는master,
             slave, hint가 오는 데 이것은 DNS서버의 종류중에서 primary, slave, cache only
             서버를 뜻한다.
      b. 설정예
        1. type master;
            => Primary Name Server를 뜻한다.
        2. type slave;
           masters { primary_Name_Server_IP주소; };
    ㄷ. file
      a. 설명: 사용하고자할 존파일의 이름을 적는다. 보통 "도메인명.zone"으로 설정하고 리버스
              존파일인 경우에는 "도메인명.rev"로 설정한다.
      b. 설정예
        1. file "mybestone.zone";
        2. file "mybestone.rev";
    ㄹ. allow-update
      a. 설명: bind 9버전부터 등장한 항목으로 이 지시자는 아래의 Key설정영역과 함께 작동한다.
              역할은 Primary Name Server의 zone정보가 Slave Name Server에 업데이트될 때 사용
              한다. 이 지시자는 Primary Name Server와 Slave Name Server간에 인증을 위한 공유가
              설정되어 있어야 하고, 만약 공유키를 지정하지 않고, IP주소로 Slave Name Server를
              지정하고자 한다면 Slave Name Server의 IP주소를 적으면 된다. 물론 Slave Name Ser
              ver를 운영하지 않는다면 필요없는 항목이다.
      b. 설정예
        1. allow-update { key 공유키; };
        2. allow-update { 192.168.0.100; };
   4) 설정예:  도메인이 linux.co.kr이고, IP주소가 192.168.0.2인 경우
    ㄱ. zone파일지정(linux.zone)
       zone "linux.co.kr" {
              type master;
              file "linux.zone";
       };
    ㄴ. 리버스 zone파일지정
       zone "0.168.192.in-addr.arpa" {
             type master;
             file "linux.rev";
       };
 (5) Key 설정 영역
   1) 설명: Bind 9 버전에 새롭게 추가된 보안 설정 영역으로 다른 서버에 존 설정관련 데이터들이
           전달될 때 서버 인증에 필요한 공유키를 설정하는 영역이다. 키 이름은 임의로 설정할 수
           있으나, 공유키 생성시에 지정한 키 이름과 같이 생성해야 한다. 역시 원격서버로 zone파
           일을 백업하지 않는다면 필요하지 않다.
   2) 기본구조
     key 키이름 {
           algorithm       알고리즘방식지정;
           secret          공유키값;
     };
      => bind 9에서는 HMAC-MD5알고리즘을 사용하고 공유키값은 dnssec-keygen이라는 것에 의해
        생성된다.
   3) 키생성
    ㄱ. 설명: Bind 9 에서는 RSA, DSA, HMAC-MD5 알고리즘중에서 HMAC-MD5만 지원한다. -a옵션으로
            알고리즘을 지정하고 -b 옵션으로 암호길이를 지정하면 된다. 최고 512bit로 지정할 수
            있다. -n HOST 뒤에 두 네임서버간의 공유키이름을 지정한다.
    ㄴ. 사용법
       dnssec-keygen -a hmac-md5 -b 128 -n HOST 키이름
    ㄷ. 사용예
       [root@www root]# dnssec-keygen -a hmac-md5 -b 128 -n HOST posein
       Kposein.+157+57372
       [root@www root]# ls K*
       Kposein.+157+57372.key  Kposein.+157+57372.private
        => 두 개의 키가 생성되는 데 두 키 가운데 하나를 선택하여 에디트하면 다음의 내용을 볼
          수 있다.
       [root@www root]# cat Kposein.+157+57372.key
       posein. IN KEY 512 3 157 6BPkem9J9/JOtfnWQ6Eahw==
        => 위의 내용을 편집해서 만들면 된다.
           key "posein" {
                 algorithm           "hmac-md";
                 secret              "6BPkem9J9/JOtfnWQ6Eahw==";
           };
 (6) controls 설정 영역
   1) 설명: 이 영역은 rndc 유틸리티에 의해서 네임서버에 명령을 전달하여 네임서버를 구동시킬 때
           사용되는 제어 채널을 설정하는 부분이다.
   2) 기본구조
     controls {
        inet 127.0.0.1 allow { localhost; } keys { rndckey; };
     };
   3) 사용법
     inet 아이피주소 포트 allow { 허가주소; } keys { 키이름; };
   4) 사용예
    ㄱ. inet 127.0.0.1 allow { localhost; } keys { rndckey; };
      => 아이피주소 다음에 포트를 지정하지 않을 경우 기본값인 953으로 지정된다. allow 다음에
        설정한 localhost에서만 가능하고 키이름은 rndckey를 가진 경우에만 가능하다.
    ㄴ. inet * allow { any; } keys { key_list; };
      => *는 포트를 사용하지 않음을 나타내고, key_list라는 키를 가진 모든 호스트에서 가능하다.
 (7) include "/etc/rndc.key" 설정 영역
    rndc라는 유틸리티의 접속을 위한 키설정부분이다. 이 내용은 /etc/rndc.key의 내용을 그대로
   가져와 control 영역의 키로 사용한다는 뜻이다.


6. 존(zone)파일
 (1) 개요: 존파일은 /etc/named.conf의 정의하에 /var/named에 위치한다. /etc/named.conf에 정의된
          zone파일인 'named.ca', 'localhost.zone', 'named.local'는 BIND설치시 기본적으로
          제공해 주는 파일로, DNS 서버의 주 역할인 Resolving을 할 수 있도록 해주고(named.ca),
          개별 도메인 설정을 위한 샘플 파일같은 역할을 해준다.(localhost.zone, named.local)
          도메인을 설정하기 위해서는 zone 파일을 사용자가 지정해줘야 하는데, 임의로 생성하면
          된다. 예를 들면 linux.zone과 linux.rev 형태로 지정할 수 있는데, linux.zone파일은
          기본적인 도메인을 위해 필요한 것이고, linux.rev파일은 IP를 도메인으로 바꿔주는 역할
          (보통 Reverse라고 표현)을 하는 존파일이다. 물론 이 리버스 파일은 설정 안해도
          상관없다.
 (2) 존파일의 역할: 사용하는 메인 도메인뿐만아니라, 2차 도메인을 관리하는 역할을 한다. 예를
                   들면 linux.co.kr이라는 도메인을 사용할 경우 2차도메인으로 game.linux.co.kr,
                   edu.linux.co.kr등을 사용할 수 있는데, 이러한 2차도메인의 지정을 담당하는
                   파일이다.
 (3) 존파일의 구성
   1) 구성: 존파일은 도메인에 대한 실제적인 DNS정보를 담는 파일이다. 이 파일은 크게 SOA record
           와 실제내용으로 나뉜다.
   2) 기본구조
     $TTL    86400
     @ IN SOA nameserver contact-email-address (
     serial_number  ; Serial
     refresh_number ; Refresh
     retry_number   ; Retry
     expire_number  ; Expire
     minium_number  ; Minimum
     )
     [도메인] [ttl] [class] [type] [rdata]
   3) 항목설명
    ㄱ. $TTL: Time To Live의 약자로 bind 9 버전에서부터는 첫줄에 무조건 적도록 되어있다. TTL
             은 다른 서버에서 자신의 정보를 가져갔을 경우 그 쪽 서버의 캐시에 해당 정보가 얼
             마나 머물지를 결정한다. 값은 0~2147483647까지 가능하며, 단위는 초단위로 보통
             86400(1일)을 설정한다.
    ㄴ. SOA record : SOA(Start of Authority) 레코드는 zone의 시작을 가리키는 데 사용한다. 설정
                    시에 주석이 필요하면 세미콜론(;)을 입력하고 뒤에 문자열을 적는다.
      a. 맨 앞의 '@'는 현재 도메인을 나타낸다. 처음은 이것으로 시작한다.
      b. nameserver는 네임서버의 호스트명과 도메인명을 기록한다.그리고 마지막은 꼭 루트도메인
        을 뜻하는 '.'을 찍는다. 그러나 호스트명만을 입력할 때는 '.'을 생략할 수 있다.
         예) 도메인이 'linux.co.kr'인 경우 다음의 두 경우는 같다.
            ns                     IN           A          203.xxx.xxx.xxx
            ns.linux.co.kr.        IN           A          203.xxx.xxx.xxx
      c. contact-email-address는 관리자의 e-mail주소를 적는다. 일반적인 표기법은 'root@domain.
        com'이라고 표기하지만, 여기서는 'root.domain.com.'이라고 표기한다. 이 부분도 뒤에 꼭 
        '.'를 붙인다.
      d. serial_number : 일련번호로서 만약 도메인 데이터베이스가 갱신되어지면 숫자가 더 크도록
                        수정한다. 일반적으로 'YYYYMMDDNN'의 형식을 사용한다.'YYYYMMDD'는 해당
                        년월일을 적고, 'NN'은 수정한 횟수를 적어주면 된다.
      e. refresh_number : 2차 네임서버가 자신의 정보를 업데이트하기 위해서 1차네임서버에 얼마
                         나 자주 체크할 것인가를 설정하는 항목이다.
      f. retry_number : 만약 2차 네임서버가 1차 네임서버에 접속을 실패했을 경우 재시도할 시간
                       을 설정한다.
      g. expire_number : 2차 네임서버가 자신의 zone데이터를 사용할 수 있는 유효기간을 정한다.
      h. minimum_number : 데이터의 저장한도를 나타낸다. 시간들의 단위는 초단위이다.
        (참고) 2차 네임서버를 운영하지 않는다면 serial_number등의 항목은 무의미하다. 또한
              최근에 값설정시에 초단위값 대신에 W(weeks), D(Days), H(Hours), M(Minutes) 붙여
              사용해도 된다.
    ㄷ. [도메인] [ttl] [class] [type] [rdata]
      - 도메인: 도메인이름, 호스트명, 공백, @, * 등이 올 수 있다. @는 현재 도메인을 가리키고,
               *는 모든 도메인을 뜻한다. 호스트명만 기입하면 "호스트명.도메인이름"로 인식한다.
               공백은 바로 위 자원을 이어서 사용하고, 전체 도메인으로 지정시에는 반드시 도메인
               이름 맨 뒤에 꼭 맨 뒤에 '.'을 붙여야 한다.
      - ttl : 해당 레코드에 대한 TTL을 설정한다. 생략해도 무방하다.
      - class: 레코드에 대한 클래스를 지정하는 부분으로 일반적으로 Internet 클래스인 IN을 사용
             한다.
      - type: 레코드 타입을 지정한다.(A, MX 등)
      - rdata: 실제정보를 입력한다.
    ㄹ. type
      a. NS : Name Server를 지정한다.
        1. 사용법
          IN NS name_server_hostname
        2. 사용예
          IN NS ns.linux.co.kr.
      b. A : Address, 즉 특정호스트명에 대한 IP주소를 입력한다. 실제의 도메인 데이터베이스를
            구축하는 항목이다.
        1. 사용법
          hostname IN A IP_address
        2. 사용예
          www.linux.co.kr.      IN       A        211.36.134.226
      c. PTR : Domain Name Pointer, 이것은 위와 반대로 IP주소를 도메인으로 변환할 때 사용되는
              타입으로 reverse zone에서만 사용한다.
        1. 사용법
          IP_address           IN       PTR      hostname
        2. 사용예
          252     IN      PTR     mybestone.com.
        3. 참고: 이것은 꼭 안써주어도 상관은 없지만, 어떤 인터넷 서비스는 특정 호스트를 인증할
                때 IP역추적을 통해서 도메인이 등록이 되어 있는지를 인증하는 경우가 있다. 이때
                에는 이 항목을 사용하여야 한다.
      d. CNAME : Canonical Name 레코드이다. 일종의 Alias(별칭)을 의미한다.
        1. 사용법
          Alias  IN CNAME Canonical-hostname
        2. 사용예
          www                     IN A            192.168.3.224

          www1                    IN CNAME www
          www2                    IN CNAME www
      e. MX : Mail Exchanger의 약어로 일종의 Fowarding개념으로, 특정 도메인(호스트)에 대해서
             메일을 다른 메일서버로 보내게 된다.
       1. 사용법
         (도메인명 또는 호스트)      IN       MX       preference value     (메일서버)
          => 여기서 preference value는 '0'또는 양의 정수값이다. 여러개의 값이 존재할 경우에는
            낮을수록 우선권이 높다.
       2. 사용예 : linux.co.kr이라는 도메인으로 메일을 받을 경우
            IN    MX    10    linux.co.kr.
       3. 응용예 : 두개의 메일서버를 구축했을 경우
         IN     MX    10       mail
         IN     MX    20       mail2
         => 위의 예제는 이메일이 도착할 경우에는 먼저 mail서버로 먼저 보내고, 응답이 없을경우
           에는 mail2서버로 이메일을 보낸다. mail서버를 하나만 구축했을 경우에는 큰 의미가
           없다.
      f. HINFO: Host INFOrmation의 약자로 호스트정보를 제공할 때 쓴다.
       1. 사용법
         www    IN    HINFO     CPU정보    운영체제정보
       2. 사용예
         www    IN    HINFO     "i686"    "RedHat 9"
   4) 설정예: 여기서는 /etc/named.conf파일에서 존파일을 linux.zone으로 지정하고 Reverse 존파일
             을 linux.rev로 지정했다고 가정하자.
      예) 도메인이 linux.co.kr이고 IP가 192.168.0.2인 경우 다음과 같이 설정한다.
         1.linux.zone
          $TTL    86400
          @       IN      SOA     ns.linux.co.kr. root.linux.co.kr.  (
                                      2001022200 ; Serial
                                      28800      ; Refresh
                                      14400      ; Retry
                                      3600000    ; Expire
                                      86400 )    ; Minimum
               IN      NS      ns.linux.co.kr.
        linux.co.kr.           IN    A    192.168.0.2
                               IN    MX    10    linux.co.kr.
        www.linux.co.kr.       IN    A    192.168.0.2
       (주의) 이 파일을 설정시에는 도메인 네임뒤에 루트를 뜻하는 '.'을 꼭 찍어야 한다. 또한
            이 파일에서 도메인 네임을 설정한 것만 접속이 된다.
       (참고) 여기에서 @는 origin을 뜻하는 특수 문자이다. 즉 메인도메인인 'linux.co.kr'를 의
             미한다. 또한 linux.co.kr이라는 도메인으로 메일을 받는다.
         2. linux.rev
           @       IN      SOA     ns.linux.co.kr. root.linux.co.kr.  (
                                      2001022301 ; Serial
                                      28800      ; Refresh
                                      14400      ; Retry
                                      3600000    ; Expire
                                      86400 )    ; Minimum
                      IN      NS      ns.linux.co.kr.
          2               IN      PTR     ns.linux.co.kr.
          => 윗부분의 설정은 linux.zone의 설정과 같고, 아랫부분의 설정만 해주면 된다. 값은
            전체IP중에서 맨 숫자만 적어주면 된다. 왜냐하면 /etc/named.conf에서 linux.rev설정에
            서 일부를 지정했기 때문이다.

7. DNS관련 유틸리티
 (1) rndc
   1) 설명: rndc는 네임서버 데몬을 관리하는 프로그램이다.
   2) 관련파일
    ㄱ. /etc/rndc.conf: rndc의 주 환경설정 파일이다.
    ㄴ. rndc-confgen: rndc의 주환경설정파일인 /etc/rndc.conf를 생성하는 명령이다.
   3) /etc/rndc.conf 기본설정예
     options {
        default-server  localhost;
        default-key     "rndckey";
     };

     server localhost {
             key     "rndckey";
     };

     include "/etc/rndc.key";
   4) /etc/rndc.conf의 항목
    ㄱ. options {};
       => default-server, default-key, default-port를 지정한다. 각각 서버, 키이름, 포트를 지정
         한다.
    ㄴ. server 서버주소 {};
       => 서버의 주소를 지정한 후 { }; 안에 사용할 식별키이름을 지정한다.
    ㄷ. key "키이름" {};
       => named.conf 파일과 같이 설정하거나 위의 항목처럼 include해도 된다.
         예) key "rndckey" {
                     algorithm       hmac-md5;
                     secret "2gNzw5u5z4ypwigLARTOgcA9cBQ94l4whKyjOBa5Rm4iu8P7XVt5LT8wht6x";
             };
   5) rndc-confgen
    ㄱ. 설명: /etc/rndc.conf 파일을 생성해주는 명령이다.
    ㄴ. 사용법
       rndc-confgen [option]
    ㄷ. option
       -a : /etc/rndc.key 키파일을 생성한다.
    ㄹ. 생성예
       [root@www root]# rndc-confgen -a
        => /etc/rndc.key 파일을 생성한다.
       [root@www root]# chmod 640 /etc/rndc.key
        => 퍼미션 변경
       [root@www root]# chown named.named /etc/rndc.key
        => 소유권 변경
       [root@www root]# rndc-confgen > /etc/rndc.conf
        => 리다이렉션기호를 사용하여 /etc/rndc.conf 파일로 저장할 수 있다.
   6) rndc 사용하기
    ㄱ. 조건: 네임서버 데몬이 작동하고 있어야 하며, /etc/named.conf 파일에 controls구문이 설정
             되어 있어야 한다.
    ㄴ. 사용예
       [root@www root]# rndc reload
        => named 데몬의 설정을 다시 로딩한다.
 (2) redhat-config-bind: 레드햇 8.0부터 제공하는 GUI기반 BIND 설정도구이다.

 (3) named-checkconf
   1) 설명: 네임서버의 주 환경 설정 파일인 /etc/named.conf의 문법적 오류를 찾아주는 명령이다.
   2) 사용법
     named-checkconf [filename]
      => 기본적으로 /etc/named.conf 파일의 오류를 검사하고, 다른 경로의 named.conf파일을
        검사하려면 파일의 경로를 적어주면 된다.
   3) 사용예
    ㄱ. [root@linux224 named]# named-checkconf
          => /etc/named.conf 파일의 문법적 오류를 찾는다.
    ㄴ. [root@linux224 root]# named-checkconf ~/named.conf
        /root/named.conf:12: unknown option 'acl
          => ~/named.conf의 문법적 오류를 찾는다.

 (4) named-checkzone
   1) 설명: zone파일의 문법적 오류를 찾아주는 명령이다.
   2) 사용법
     named-checkzone 도메인명 zone파일경로
   3) 사용예
     [root@linux224 root]# named-checkzone linux.com /var/named/linux.zone
     /var/named/linux.zone:1: no TTL specified; using SOA MINTTL instead
     zone linux.com/IN: loaded serial 2005070802
     OK

8. DNS서버 구성예
 (1) 단일서버
   1) 설명: 부여받은 IP주소가 192.168.1.125이고 신청한 도메인이 linux.co.kr이고, 하나의 시스템
           에 DNS, WEB, Mail서버 운영하는 경우
   2) 설정하기
    ㄱ. /etc/named.conf 파일의 설정: 이 파일에는 기본적으로 zone파일의 위치하는 디렉토리와
                                    2개의 존파일이 선언되어 있는 데, 기본설정은 건드리지 말고
                                    내용만 추가해야 한다.
      (예)
       [root@www root]# vi /etc/named.conf
       // generated by named-bootconf.pl

       options {
               directory "/var/named";
               /*
                * If there is a firewall between you and nameservers you want
                * to talk to, you might need to uncomment the query-source
                * directive below.  Previous versions of BIND always asked
                * questions using port 53, but BIND 8.1 uses an unprivileged
                * port by default.
                */
               // query-source address * port 53;
       };

       //
       // a caching only nameserver config
       //
       controls {
               inet 127.0.0.1 allow { localhost; } keys { rndckey; };
       };
       zone "." IN {
               type hint;
               file "named.ca";
       };

       zone "localhost" IN {
               type master;
               file "localhost.zone";
               allow-update { none; };
       };

       zone "0.0.127.in-addr.arpa" IN {
               type master;
               file "named.local";
               allow-update { none; };
       };
       zone "linux.co.kr" {         // 사용하고자 하는 도메인을 선언
               type master;         // 기본 primary로 사용시에는 master로 선언한다.
               file "linux.zone";   // 사용하고자하는 zone파일의 이름을 선언한다. 물론 이름은
       };                            임의로 선언. 여기서는 linux.zone이라고 함.

       zone "1.168.192.in-addr.arpa" {   // 부여받은 IP중 마지막 자리를 뺀 나머지를 역으로
               type master;                선언한다. nslookup등을 이용하여 IP주소로 도메인이름
               file "linux.rev";           을 조회할 때 사용. 타입은 master이고, zone파일의
       };                                  이름은 임의로 지정할 수 있으며, 여기서는 linux.rev
                                           라 함.

       include "/etc/rndc.key";
    ㄴ. zone파일의 생성: /etc/named.conf파일에서 zone파일들이 위치하는 디렉토리가 /var/named
                        라고 정의되어 있으므로 이 디렉토리에 생성한다. 아울러, 이 디렉토리에
                        localhost의 zone파일인 localhost.zone파일이 존재하므로 이 파일을
                        위에서 설정한 zone파일인 linux.zone으로 변경한뒤에 편집하고 리버스
                        존파일인 linux.rev는 linux.zone파일을 복사하여 설정하면 된다.
       (예)
      1. linux.zone파일의 설정
       [root@www named]# vi linux.zone
       $TTL    86400
       @       IN      SOA     ns.linux.co.kr. root.linux.co.kr.  ( // 네임서버와 관리자 메일
                                        2001071500 ; Serial           설정시 도메인명 뒤에
                                        28800      ; Refresh          반드시 '.'를 표기
                                        14400      ; Retry
                                        3600000    ; Expire         // 예전에는 초단위의 값을
                                        86400 )    ; Minimum          사용했으나 현재는 H(시),
                              IN   NS       ns.linux.co.kr.           D(일)등의 단위도 사용
       linux.co.kr.           IN   A        192.168.1.125
                              IN   MX 10    linux.co.kr.        // 메일서버의 우선순위를 지정
       www.linux.co.kr.       IN   A        192.168.1.125

         (참고) 2차 도메인 전부를 설정하는 경우
               *.linux.co.kr.         IN   A       192.168.1.125
           => (생략법)
               *                      IN   A       192.168.1.125

      2. linux.rev 파일의 설정
       [root@www named]# vi linux.rev
       $TTL    86400
       @       IN      SOA     ns.linux.co.kr. root.linux.co.kr.  (
                                        2001020201 ; Serial
                                        28800      ; Refresh
                                        14400      ; Retry
                                        3600000    ; Expire
                                        86400 )    ; Minimum
                       IN NS      ns.linux.co.kr.
       125             IN PTR     ns.linux.co.kr.    // 125는 부여받은 IP의 맨 마지막을 표기한
       125             IN PTR     linux.co.kr.         것이며. PTR은 리버스존에서 정의해주는
       125             IN PTR     www.linux.co.kr.     것으로 IP주소로 도메인을 변환할 때 사용
                                                       한다.
   3) 테스트하기
    ㄱ. named 데몬을 작동시킨다.
       [root@www named]# /etc/rc.d/init.d/named start
         => named 시작시 [OK]메시지가 나타나도 /etc/named.conf파일의 설정이 잘못되면 데몬이
           작동되지 않으므로 데몬작동유무를 확인해야 한다.
    ㄴ. /etc/reslov.conf파일에 본인의 IP주소를 네임서버로 등록한다.
       예) [root@www named]# vi /etc/resolv.conf
           nameserver 192.168.1.125
    ㄷ. nslookup 명령등으로 테스트한다.
       예) [root@www named]# nslookup linux.co.kr
           Note:  nslookup is deprecated and may be removed from future releases.
           Consider using the `dig' or `host' programs instead.  Run nslookup with
           the `-sil[ent]' option to prevent this message from appearing.
           Server:         192.168.1.125
           Address:        192.168.1.125#53

           Name:   linux.co.kr
           Address: 192.168.1.125
 (2) 단일서버2
   1) 설명: 위의 단일서버에 linux.com이라는 도메인 추가하기
   2) 설정하기
    ㄱ. /etc/named.conf 파일의 설정: 도메인이 추가된 경우에는 반드시 이 파일에 등록하고
                                    linux.com의 존파일을 선언해야 한다. 단순히 도메인만 추가
                                    하여 사용하는 경우에는 linux.com의 2차도메인인
                                    www.linux.com 등을 사용하기 위하여 새로운 존파일을
                                    생성해야 한다.
       (예)
      1. linux.zone파일의 설정
       [root@www named]# vi linux.com.zone
       $TTL    86400
       @       IN      SOA     ns.linux.com. root.linux.com.  ( // 네임서버와 관리자 메일
                                        2001071500 ; Serial       설정시 도메인명 뒤에
                                        28800      ; Refresh      반드시 '.'를 표기
                                        14400      ; Retry
                                        3600000    ; Expire         // 예전에는 초단위의 값을
                                        86400 )    ; Minimum          사용했으나 현재는 H(시),
                              IN   NS       ns.linux.com.             D(일)등의 단위도 사용
       linux.com.             IN   A        192.168.1.125
                              IN   MX 10    linux.com.        // 메일서버의 우선순위를 지정
       www.linux.com.         IN   A        192.168.1.125
      2. linux.rev 파일의 설정
       [root@www named]# vi linux.rev
       $TTL    86400
       @       IN      SOA     ns.linux.co.kr. root.linux.co.kr.  (
                                        2001020201 ; Serial
                                        28800      ; Refresh
                                        14400      ; Retry
                                        3600000    ; Expire
                                        86400 )    ; Minimum
                       IN NS      ns.linux.co.kr.
       125             IN PTR     ns.linux.co.kr.
       125             IN PTR     linux.co.kr.
       125             IN PTR     www.linux.co.kr.
       125             IN PTR     linux.com.            // 추가
       125             IN PTR     www.linux.com.        // 추가
    ㄷ. apache의 설정: 웹서비스를 하는 경우 아파치의 환경파일인 httpd.conf에서도 설정해줘야
                      한다.
        예) [root@www apache]# vi httpd.conf
            ---- 생략 -----
            NameVirtualHost 192.168.1.125              // 이 부분에 사용하는 IP를 적는다.
            ---- 생략 -----
            <VirtualHost 192.168.1.125>
                ServerAdmin admin@linux.com
                DocumentRoot /usr/local/apache/htdocs
                ServerName www.linux.com
                ServerAlias linux.com www.linux.com
                ErrorLog logs/linux.com-error-log
                CustomLog logs/linux.com-access_log common
            </VirtualHost>
              => 위의 ServerAlias 설정은 브라우저상에서 linux.com과 www.linux.com를 입력했을
                경우에 웹페이지가 열리도록 설정. 만약 2차도메인이 전부 이 동일한 웹페이지가
                열리도록 하려면 *.linux.com이라고 설정한다.
   3) 테스트하기
     [root@www named]# nslookup
     Note:  nslookup is deprecated and may be removed from future releases.
     Consider using the `dig' or `host' programs instead.  Run nslookup with
     the `-sil[ent]' option to prevent this message from appearing.
     > www.linux.co.kr                           // www.linux.co.kr 조회
     Server:         192.168.1.125
     Address:        192.168.1.125#53

     Name:   www.linux.co.kr
     Address: 192.168.1.125
     > www.linux.com                            // www.linux.com 조회
     Server:         192.168.1.125
     Address:        192.168.1.125#53

     Name:   www.linux.com
     Address: 192.168.1.125
     > 192.168.1.125                           // IP로 조회
     Server:         192.168.1.125
     Address:        192.168.1.125#53

     125.1.168.192.in-addr.arpa     name = linux.co.kr.
     125.1.168.192.in-addr.arpa     name = linux.com.
     125.1.168.192.in-addr.arpa     name = ns.linux.co.kr.
     125.1.168.192.in-addr.arpa     name = www.linux.co.kr.
     125.1.168.192.in-addr.arpa     name = www.linux.com.

 (3) 다중 웹서버
   1) 설명: 웹서버 2대를 따로 운영할 경우 직접 www이라는 동일한 이름으로 지정가능하다.
   2) 사용예
     [root@linux224 named]# vi linux.zone
     @                        IN SOA ns.linux.com. posein.linux.com. (
                                             2005070501      ; serial (d. adams)
                                             3H              ; refresh
                                             15M             ; retry
                                             1W              ; expiry
                                             1D )            ; minimum

                              IN NS          ns.linux.com.
                              IN A           203.247.50.224
                              IN MX 10       203.247.50.224
     www                   0  IN A           203.247.50.227
     www                   0  IN A           203.247.50.228
       => TTL을 0으로 설정하면 caching을 하지 말도록 하는 설정이다.

 (4) 2차도메인서버운영
   1) 개요: mybestone.com이라는 도메인으로 서버가 한 대 운영중이고 linux.mybestone.com이라는
           서브도메인(2차도메인)을 부여하여 이 서버가 독자적인 IP를 가지고 있고, 웹서버 및
           메일서버도 독자적으로 운영하려고 한다. 또한 이 서버의 서브도메인(3차도메인)도
           가능하게 설정하도록 한다.
   2) 조건
    ㄱ. mybestone.com (주 도메인)
         IP 주소         : 192.168.0.3
         zone 파일       : mybestone.zone
         Reverse zone파일: mybestone.rev
    ㄴ. linux.mybestone.com (서브 도메인)
         IP 주소         : 192.168.0.4
   3) 설정
    ㄱ. 주 네임서버(ns.mybestone.com)의 설정
      a. /var/named 디렉토리에 존재하는 mybestone.zone파일의 설정 추가
             linux            IN      NS      ns.linux
             ns.linux         IN      A       192.168.0.4
          => 첫번째줄의 설정을 풀어쓰면 다음과 같다.
              linux.mybestone.com.         IN       NS      ns.linux.mybestone.com.
            즉 linux.mybestone.com이라는 도메인의 네임서버를 ns.linux.mybestone.com이라는
            것으로 정한다는 뜻이다.
            두번째줄의 설정을 풀어쓰면 다음과 같다.
             ns.linux.mybestone.com.      IN       A      192.168.0.4
           즉, ns.linux.mybestone.com의 IP주소는 192.168.0.4라는 뜻이 된다.
       (참고) 단순히 2차 도메인 사용만 지정하려면
                linux             IN      A      192.168.0.4
              라고 한줄만 지정해도 된다.
       b. /var/named 디렉토리에 존재하는 mybestone.rev파일의 설정 추가
            linux            IN      NS      ns.linux.mybestone.com.
            4                IN      NS      ns.linux.mybestone.com.
    ㄴ. 서브 네임서버(ns.linux.mybestone.com)의 설정
      a. /etc/named.conf파일의 설정
          zone "linux.mybestone.com" {        // 위임받은 2차도메인 설정
                  type master;
                  file "linux.mybestone.zone";
          };

           zone "linux.0.168.192.in-addr.arpa" { // 위임받은 2차도메인의 역존 설정법
                   type master;
                   file "linux.mybestone.rev";
                 };
      b. linux.mybestone.zone파일의 설정
          @       IN      SOA     ns.linux.mybestone.com. root.linux.mybestone.com.  (
                                           2001071500 ; Serial
                                           28800      ; Refresh
                                           14400      ; Retry
                                           3600000    ; Expire
                                           86400 )    ; Minimum
                                         IN NS      ns.linux.mybestone.com.
          linux.mybestone.com.           IN A       192.168.0.4
                                         IN MX 10   linux.mybestone.com.
          www.linux.mybestone.com.       IN A       192.168.0.4
      c. linux.mybestone.rev 파일의 설정
          @       IN      SOA     ns.linux.mybestone.com. root.linux.mybestone.com.  (
                                           2001020201 ; Serial
                                           28800      ; Refresh
                                           14400      ; Retry
                                           3600000    ; Expire
                                           86400 )    ; Minimum
                       IN      NS      ns.linux.mybestone.com.
         4             IN      PTR     linux.mybestone.com.
         4             IN      PTR     ns.linux.mybestone.com.
         4             IN      PTR     www.linux.mybestone.com.
   ㄷ. httpd.conf파일에 설정한다.
        <VirtualHost 192.168.0.4>
            ServerAdmin root@linux.mybestone.com
            ServerName www.linux.mybesone.com
            DocumentRoot /usr/local/apache/html
            ErrorLog logs/linux.mybestone.com-error_log
            CustomLog logs/linux.mybestone.com-access_log common
        </VirtualHost>
 (5) Slave DNS 구성하기
   1) 설명: Slave DNS는 Master DNS의 zone파일을 백업하는 역할을 하는 서버이다. Master DNS의
           IP주소를 192.168.1.125, 도메인 네임을 linux.co.kr이라고 가정하고, Slave DNS는
           192.168.1.126이라고 가정한다.
   2) 설정하기
    ㄱ. Master DNS(192.168.1.125)의 /etc/named.conf 파일에 허가할 Slave DNS의 설정
       [root@master root]# vi /etc/named.conf
       options {
               directory "/var/named";
               allow-transfer { 192.168.0/24; 192.168.1.126; };  // 허가할 Slave DNS IP주소
       };
       ----- 이하 생략 ------
    ㄴ. Slave DNS(192.168.126) 설정
      a. /etc/named.conf 파일의 설정: 다음의 항을 추가한다.
        [root@slave root]# vi /etc/named.conf
        ---- 생략 ----
        zone "linux.co.kr" IN {
                type slave;
                file "linux.zone";
                masters { 192.168.1.125; };
        };

        zone "1.168.192.in-addr.arpa" IN {
                type slave;
                masters { 192.168.1.125; };
                file "linux.rev";
        };
       b. zone파일을 복사할 /var/named의 허가권 조정: 복사를 해오는 named가 기본적으로
                                                     /var/named에 쓰기권한이 없다. 따라서,
                                                     허가권을 조정해야 한다.
         [root@www root]# ls -ld /var/named
         drwxr-x---    2 named    named        4096  8월 16 21:48 /var/named/
         [root@www root]# chmod g+w /var/named
         drwxrwx---    2 named    named        4096  8월 16 21:48 /var/named/
     ㄷ. slave DNS에서 named 데몬을 재가동하면 Master DNS의 존파일인 linux.zone, linux.rev
        파일을 복사해온다.


'OS 운영체제 및 보안 > Linux' 카테고리의 다른 글

chattr 와 lsattr 파일 권한  (0) 2008.11.06
BIND 최신버전으로 업그레이드  (0) 2008.11.06
find 유용한 사용법  (0) 2008.11.06
iptables  (0) 2008.11.06
named.conf - option최적화  (0) 2008.11.06
Vi 편집기 사용법  (0) 2008.10.24
Vi 편집기 사용법  (0) 2008.10.24
crontab 간단 정리  (0) 2008.10.24
Named 최신버전으로 업그레이드  (0) 2008.10.24
DNS 기본 보안 설정  (0) 2008.10.24

Ethernet과 Switch 모든것

Posted 2008. 11. 6. 16:47

출처 : http://blog.naver.com/exity5?Redirect=Log&logNo=90000405610    exity5님 블로그



 1장. Ethernet과 Switch

네트워크를 구성하는 여러요소중에서 일반사용자 및 관리자들에게 가장 밀접한 연관을 갖는 것은 LAN(Local Area Network)으로 작게는 10여대의 pc가 연결된 작은 사무실을 위한 네트웍에서 크게는 1000개의 노드가 연결되는 캠퍼스 네트웍 까지 비교적 가까운 거리의 장비들을 연결하는 네트워크 입니다. LAN은 Token Ring, FDDI, ATM 등의 기술을 이용해서도 구축될 수 있으나 현재 우리나라의 경우 전체 LAN의 90%이상이 Ethernet을 기반으로 한 Switched Network으로 구성되어 있으므로 Ethernet 및 Switched Network의 몇가지 기본적인 부분에 대해 간략하게 알아보려 합니다.

1. Ethernet

2. Switch


1 계층 장비인 repeater와 shared-hub의 문제점을 해결하기 위해 개발된 것이 2계층에 속하는 장비인 Bridge와 Switch입니다. 두장비의 기능과 작동원리는 동일하며 차이는 물리적인 연결 port의 숫자이므로 switch를 멀티포트브리지라고 생각하시면 됩니다. 물론 Bridge에 비해 Swtich가 다양한 기능과 높은 성능을 제공하며 내부구조또한 복잡합니다.
(일반 스위치를 보통 L2 혹은 2계층 스위치라고 합니다. OSI7 Layer중 2계층에 속하는 MAC address정보를 콘트롤 할 수 있다는 의미입니다. Network Layer의 IP address에 기반한 Routing정보를 다루는 L3 switch(multilayer switch)나, tansport layer의 tcp, udp port정보를 이용해 load balancing, caching등에 이용되는 L4 switch, Application Layer에 해당하는 정보를 읽어 codered, nimda등의 악성 코드를 네트워크 자체에서 소멸시키는 L7 Switch등이 등장하면서 편한 구분을 위해 사용됩니다.)

Hub와 Switch의 구조를 살펴보면 그림 7.에서와 같이 개념적으로 하나의 Backbone으로 연결된 Hub에 비해 Switch는 다중 Backbone 의 Matrix구조를 가집니다.


...................................[그림 7] Hub와 Switch의 구조적 차이점




스위치의 종류
▶ 더미 스위치 - 기능상 분류로서 인텔리젼트 허브정도의 기능(기본적인 관리기능과 문제가 발생한 port를 폐쇄시키는 Partition Isolization 기능)을 보유한 단순한 스위치
▶ 인텔리젼트 스위치 - 기능상 분류로서 대부분의 일반 스위칭에 해당함. 스위치내에 자체 중앙처리장치 및 버퍼를 보유하고 클라이언트 P.C 또는 상위 계층의 장비들의데이터 목적지를 일시 분석, 전송하는 기능을 보유한 스위치
▶ 스텍커블 스위치 - 구조상 분류로서 여러대의 스위치를 적층할 때 스위치의 Backbone-Bus를 상호 연결할 수 있도록 별도의 트렁크 포트를 구비한 스위치
▶ 이더넷 스위치 - 속도의 구분으로 10Mbps 인터페이스 포트를 구비한 스위치
▶ 패스트 이더넷 스위치 - 속도의 구분으로 100Mbps 인터페이스 포트를 구비한 스위치로 대부분10/100Mbps 겸용임
▶ 기가비트 이더넷 스위치 - 속도의 구분으로 1000Mbps 인터페이스 포트를 구비한 스위치로 대부분의 인터페이스는 광케이블(멀티모드 혹은 싱글모드) 임

Hub와 Swtich의 차이점
: 스위치에서는 동시에 송신과 수신 두 pc만이 통신이 가능한 허브와 달리 1번 포트에 연결된 pc가 2번 포트에 연결된 pc와 통신하는 동안 5번 포트의 pc가 6번 포트의 pc와 통신하는 것이 가능합니다. 즉, 허브에 연결된 모든 노드가 하나의 collision domain이 되는 것에 비해 스위치는 포트 각각이 별개의 collision domain을 구성하게 됩니다. 즉, 24port Switch라면 24개의 collision domain을 구성하게 되는 거죠.
: 허브에서 전체 대역폭을 연결된 장비들이 나누어 사용하는 것에 비해 100BaseTX로 구성된 스위치라면 각각의 port들이 각각 100Mbps로 통신할 수 있읍니다. 이걸 dedicated port라고 합니다.

앞에서 보신것처럼 스위치는 collision domain을 나누어 주어서 포트에 연결된 각 노드가 충분한 대역폭을 사용하며 unicast frame경우 정확히 해당하는 노드에만 전달함으로써 다른 노드들이 불필요하게 대역폭과 시스템 자원을 사용하지 않도록 해줍니다. 물론 broadcast의 경우에는 변함없이 연결된 모든 노드에 전송을 하고 broadcast를 막는 것은 Layer3 의 장비인 router의 기능입니다.(이렇게 스위치를 이용해 여러 개의 collision domain으로 나누는 것을 segmenting이라고 하며 나눠진 domain을 각각 하나의 segment라고 합니다. 당연히 라우터는 broadcast domain을 segmeting합니다.)

그림 8.은 switch를 이용해 구성한 네트워크의 간단한 예와 OSI7 계층에 따른 네트웍장비의 구분입니다. 전체 LAN이 8개의 collision domain과 하나의 broadcast domain으로 나누어져 있읍니다.


.......................................[그림 8] Switched LAN의 구성예

MAC address정보를 이용해 네트웍을 효과적으로 구성하는 스위치의 작동원리를 자세히 알아보죠. 그림 9.에서 보시면 MAC address Table이 Swtich내부의 메모리안에 만들어집니다. 가령 host A가 스위치에 연결된후 어딘가로 프레임을 전송하게 되면 스위치는 프레임안의 source address을 읽어서 port E0 에 host A가 연결되어있다는 것을 인식하고 테이블에 추가하며 다른 호스트들도 같은 방법으로 추가하여 MAC address Table을 완성합니다(Learning). 물론 port E1에서는 허브를 통해 연결된 host A 와 B 모두의 MAC address가 등록됩니다. Host B에서 E로 통신을 시도할 경우 프레임은 허브에서 복제되어 host C와 Switch로 전달됩니다. Host C는 자신의 MAC 주소와 맞지 않으므로 이것을 폐기하죠. Port E1을 통해 프레임을 받은 스위치는 Table의 MAC 주소와 비교한 후 일치하는 주소가 등록된 port E3로만 프레임을 전송합니다(Forwarding). Port E0 와 E2에는 다른 MAC address가 등록되어 있으므로 프레임을 전송하지 않읍니다(Filtering). 만약 host D가 Broadcast방식으로 프레임을 전송한다면 스위치는 filtering을 수행하지 않고 모든 port를 통해 broadcast 프레임을 forwarding하여 모든 host가 이 프레임을 받을 수 있읍니다(Flooding).

........
.........................................[그림 9] Switch의 작동원리

다시한번 정리하자면 Switch의 작동은 다음 다섯 단계로 나누어 질 수 있읍니다.
Learning - 각 port에 연결된 host의 MAC address를 등록합니다.
Forwarding - MAC address Table과 비교하여 일치하는 port로만 프레임을 전송합니다.
Filtering - 그외의 port에 대해서는 프레임을 전송하지 않읍니다.
Flooding - broadcast 프레임의 경우 모든 port로 전송합니다.

이상으로 CSMA/CD를 포함한 Ethernet과 Switch에 대해서 기본적인 사항 몇가지를 살펴보았읍니다. 다음번에는 LAN Switching의 좀 더 세부적인 사항들과 효과적인 Switched Network을 구성하기 위한 Spaning Tree Protocol(STP), Trunking(Cisco Cayalyst Switch의 경우 Channelizing), VLAN 등에 대해 알아보겠읍니다.

마지막으로 Switch성능과 관련된 몇가지 용어가 의미하는 바를 살펴보죠.

Non-Blocking/Non-Blocking
보통 L2 스위치의 성능을 이야기 할 때 사용되는 용어입니다. 스위치의 모든 port들은 switch-backbone을 통해 연결되어 있는데 만약 이 백플레인의 용량이 충분하지 않다면 port를 통해 수신된 프레임들은 즉각 처리되어 목적지로 전송되지 않고 차례가 올때 까지 buffer안에 대기하고 있어야 합니다. 즉, 스위치에서 네트워크의 지연현상이 발생하는 경우를 Blocking이라고 하고, 충분한 backplane 용량을 지녀 지연현상이 없는 경우를 Non-Blocking 이라고 합니다. 예를 들어 100Mbps 48port를 가진 스위치의 경우 4.8Gbps의 Backplane용량이 있어야 Non-Blocking Switch라 할 수 있으며, full-duplex방식을 사용할 경우에는 그 두배인 9.6Gbps(48 ? 100Mbps ? 2)의 백플레인 용량을 갖추어야 합니다.

Wired/Non-Wired
Blocking/Non-Blocking과 비슷하게 스위치의 성능을 나타내는 용량이나 주로 L3, 즉 IP라우팅 기능을 같춘 스위치에서 사용되며 패킷전송속도에 따라 구분됩니다. 패킷전송속도의 bps가 아닌 pps(Packet Per Second), 즉 스위치의 초당 packet처리 능력을 나타냅니다. 10Mbps의 경우 14880pps를 갖추어야 wired, 즉 연결된 링크의 물리적 대역폭을 통해서 전달되는 모든 패킷을 지연없이 통과시킬 수 있읍니다. Fastethernet의 경우는 10배, GigabitEthernet의 경우는 100배의 용량이 필요합니다. 24port Fastethernet과 2port GigabitEthernet 을 갖춘 스위치의 경우 모든 port들이 full-duplex를 사용한다면 8.8Gbps의 backplane capacity와 대략 13.2Mpps(1.5Mpps ? 2 ? 2 + 0.15Mpps ? 24 ? 2)의 패킷처리성능을 지니고 있어야 Non-Blocking wired switch라 할 수 있읍니다.




2장. Switching Network

1. Switching



지 난 기사에서 말씀드린 것처럼 Ethernet은 기반 기술인 CSMA/CD의 특성상 매체공유방식, 즉 대역폭의 공유 방식을 따르고 있어 서버나 PC같은 네트웍 상의 노드들의 성능향상과 멀티미디어등의 대용량 트래픽의 증가에 따른 LAN의 혼잡도가 증가하면서 여러가지 약점을 드러냈고 이것을 보완하기 위한 장비가 Switch(Switching Hub)입니다.
LAN Switch는 network을 분할(Segmenting)하여 하나의 공유매체(Collision Domain, segment)에 접속되는 장치의 수를 효율적으로 줄여 개개인의 사용자에게 더 많은 대역폭을 할당(Dedicated)하는 장비로 Bridge와 마찬가지로 MAC address정보를 이용하는 OSI 7 Layer 중 2nd Layer인 Datalink Layer에 해당하는 장비입니다. 대부분의 Ethernet LAN Switch가 MAC address table을 작성하고 이를 이용하는 기법인 Transparent Bridging-첫번째 기사의 <그림 9. Switch의 작동원리> 참조-은 Learning, Flooding, Filtering, Fowarding 의 네부분으로 이루어져 있읍니다. 여기에 Dynamic한 MAC address lookup Table의 업데이트를 위해서 Aging기능이 추가됩니다.
스위치로 들어온 Ethernet 프레임의 조각인 Packet들을 일단 임시저장공간의 RAM 상의 Buffer에 저장되고 프레임의 Header부분에 들어있는 목적지 MAC address와 lookup table상의 address와 비교한 후 적합한 port로 전송하는 Fowarding을 Packet-Switching이라고도 부르는데 여기에는 Store and Forward, Cut-Through, Fragment-Free 의 세가지 방법이 있읍니다.

Store and Forward : 전체 Packets을 버퍼에 저장하여 CRC(Cyclic Redundancy Check) error나 다른 문제점이 없는 것을 확인한 후 문제가 있으면 그 패킷을 폐기하고-이 경우 UDP packet이라면 정보는 그냥 소실되고, TCP라면 3-handshake acknowlegment에 의해 노드에서 재전송이 일어납니다.-, 문제가 없을 때만 목적지 노드로 패킷을 전송합니다. 연결이 안정적이라는 장점에 비해 버퍼에 패킷을 저장하고 문제를 확인하는 동안 시간지연이 생기는 단점이 있읍니다.

Cut-Through : 스위치에 패킷이 들어오자마자 첫 6Bytes를 읽어서 MAC Address를 확인한 후 곧장 목적지 노드로 패킷을 전송하는 방법으로 패킷의 나머지 부분이 스위치로 들어오는 중간에도 전송이 일어나게 됩니다. 그만큼 시간지연이 없어 빠른 네트웍이 가능하지만 대신에 패킷의 문제여부에 대한 확인이 없는 만큼 연결의 안정성이 떨어지게 됩니다.

Fragment-Free : Cut-Through처럼 작동하면서도, 패킷을 목적지 노드로 전송하기전에 일단 처음의 64Bytes만큼은 저장하여 에러여부를 확인한 후 전송합니다. 왜냐하면 대부분의 에러나 패킷의 품질에 영향을 미치는 Collision등의 문제점이 Ethernet의 header(packet 자체에 대한 정보를 갖고있는)인 첫 64Bytes에서 발생하기 때문으로 시간지연을 줄이면서 안정성을 높이려는 시도입니다.

현재 대부분의 스위치들은 특정 error수준에 도달 할 때까지는 Cut-Through방식을 그 다음에는 Store and Forward방식을 사용하는 혼합형입니다.
LAN스위치의 물리적인 구성면에서는 Shared-memory, 격자구조의 Matrix방식의 순으로 발전해 왔으며 근래에는 개별 port마다 메모리 버퍼를 두고 Internal transmission path(Common Bus)를 공유하고 Application Specific Integrated Circuit(ASIC)으로 Bus 접근을 관리하는 Bus-Architecture가 도입되었읍니다.




2. Spanning Tree Protocol(STP)






LAN의 크기가 증대되어 더 많은 사용자 및 노드를 수용하기 위해서는 스택킹을 사용하거나 스위치들을 서로 연결하여 네트웍을 확장 시킵니다. 물론 현재는 스위치의 역할에 따라 Backbone, workgroup 등으로 구분하여 연결하는 계층구조적인 디자인을 이용합니다.
다수 노드들의 집합체인 네트웍의 특성상 발전단계의 초기부터 제기된 핵심적인 이슈중 하나인 ‘어떻게 Single point of failure가 네트웍의 다른 부분에 영향을 미치지 않도록 하느냐?’는 Switched LAN에서도 여전히 동일하게 적용됩니다.

..........................
............................................[그림1]Single link Switched LAN

위의 그림에서 B switch에 문제가 발생할 경우 전체네트웍에 영향을 미치게 되는 것을 방지하기 위해서는 그림 2.와 같이 Redundancy구현의 가장 기본적인 형태인 이중화를 도입하여 Single point of failure를 효과적으로 제거할 수 있읍니다만, 연결경로의 이중화로 인해 다른 문제가 발생하게 됩니다.

..........................
..........................................[그림3]Broadcast Storm

그림 2.에서 스위치들은 두개의 다른 연결경로를 지닌 일종의 loop형태로 연결되어있읍니다. 스위치의 동작과정중 Learning과정을 생각해 보죠. 그림 3.에서 노드 B가 노드 A와 통신을 하려 할 경우 스위치 A는 아직 노드 A를 위한 lookup table이 없으므로 모든 포트를 통해 패킷을 flooding시킵니다. 그 패킷은 Segment A 또는 B를 통해 다른 두 스위치 B, C에 전달되어 다시 Segment B로 flooding됩니다. 따라서 두 스위치는 서로 플러딩된 패킷을 주고 받은 후 아직 노드 A에 대해 알지 못하므로 다시 한 번 패킷을 즉시 flooding시킵니다. 그러면 스위치 A는 두 경로 모두로 부터 그 패킷을 받은 후 또 다시 Flooding을 합니다. 즉 패킷이 루프를 따라 계속해서 돌게 되는 상황이 발생하고, 특히나 이 패킷이 Broadcast일 경우에는 모든 스위치가 계속 재전송을 수행하게 되어 잠재적으로 어느순간 Broadcast Storm이라 불리는 재난적인 네트웍 혼잡이 발생, 네트웍 전체가 작동불능상황에 빠질 수 있읍니다.

..........................
.................................................[그림3]Broadcast Storm

네트웍의 안정성을 높이기 위한 loop구성을 유지하면서도 재난적인 부대효과인 Broadcast Storm을 방지하기위해 개발된 프로토콜이 STP(Spanning Tree Protocol:IEEE802.1d)입니다. Spanning Tree의 핵심요소은 Spanning Tree Algorithm으로, 스위치가 어떤 노드와의 통신을 위한 하나이상의 경로를 감지했을 때, 최적경로 하나를 결정한 후 다른 경로를 blocking하여 looping의 가능성을 막으면서도 우선경로에 문제가 발생했을 때 blocking되어 있던 경로를 통해 지속적으로 통신을 연결할 수 있게 해줍니다. 즉, STP를 통해 Switched Ethernet LAN은 가용성과 안정성을 동시에 확보할 수 있게 되었읍니다. 최적경로의 선택은 STP가 설정된 스위치들이 지속적으로 BPDU(Bridge Protocol Data Unit)의 교환을 통해 STP Cost Value를 계산함으로써 이루어지며 디폴트 값들은 다음과 같읍니다.

Bandwidth .......STP Cost Value
4 Mbps.....................250
10 Mbps...................100
16 Mbps...................62
45 Mbps...................39
100 Mbps.................19
155 Mbps.................14
622 Mbps..................6
1 Gbps.....................4
10 Gbps....................2

해당하는 경로의 cost value를 합산한 후 제일 값이 적은 경로가 최적 경로로 선택됩니다. 물론 네트웍의 특별한 구성에 따라서는 각 경로에 기본 값 이외의 임의의 cost value를 설정하여 관리자가 원하는 형태로 최적경로와 대기경로를 설정할 수 도 있읍니다.



3. Trunking(EtherChannel)






STP의 도입으로 Switched LAN은 Broadcast Storm등의 문제없이 looping connection을 통해 자체복원적인 구성이 가능하게 되었읍니다만, 안정성과 가용성외에 네트웍에 요구되는 다른 하나의 문제점, 즉 점점 다양해지는 네트워크상의 Application이 도입되고 네트웍상의 노드들의 성능이 대폭적으로 개선되면서 제기되는 보다빨리 많은 데이터의 전송에 대한 성능상의 요구압력에 대처하기위해 나온 방법이 Trunking(EtherChannel in Cisco product)기술입니다.
최초에 Trunking은 Switch, Router, Server 사이에서 카테고리5 UTP cable을 사용하는 full-duflex 802.3 FastEthernet에 대하여 fault-tolerant한 고속링크를 목적으로 개발되었으나 다른 네트웍기술의 발달에 발 맞추어 현재는 singlemode 및 multimode 광 연결과 GigabitEthernet에도 적용할 수 있읍니다.


...................................
.............................[그림4]Basic Topology of Trunking or Fast-EtherChannel

그림 4.에서 보듯이 trunking의 구현을 위해서는 스위치사이에, 주로 Wrokgroup Switch(wiring closet)와 Backbone(data center) switch, 이중 혹은 다중 링크를 연결한 후 연결에 사용된 각 스위치의 port들을 하나의 trunking interface로 묶어주면 됩니다. 위의 예에서는 두개의 링크를 각각 trunking하여 하나의 물리적 port처럼 사용되게 함으로써 Tx, Rx 각 100Mbps씩 200Mbps인 Fastethernet의 대역폭을 400Mbps로 확장한 구성입니다. Spanning Tree Protocol을 적용한 LAN과 비교하자면 위 그림에서 STP가 적용되었을 경우 single point failure시 네트웍의 가용성은 확보되지만 대역폭은 FastEthernet의 100Mbps의 한계를 그대로 지니며, link failure 발생시 Blocking되었던 link가 되살아나기까지 스위치사에에 BPDU의 교환 및 경로설정을 위해 소요되는 시간만큼(대략 50초 가량이나 fastlink및 backbonelink등의 설정을 통해 단축가능)네트웍이 단절되는 것을 감수 해야합니다. 즉 그 사이에 host protocol time이 만료되며 session이 종료됨으로서 일반 사용자들은 세션을 다시 설정해야만 합니다.
그에비해 trunking 적용시에는 최대 4개의 물리적 포트를 묶어 800Mbps(GigabitEthernet의 경우 8Gbps)까지 대역폭의 확장이 가능하며 트래픽은 port들 사이에서 load-balancing이 됩니다. 단, 이경우에는 MAC address기반의 load balancing으로 정확히 50:50으로 구현되지는 않읍니다. 따라서 하나의 link failure 발생시에도 트래픽을 다른 링크를 통해 1초 이내에 재전송함으로 사용자 서비스는 전혀 영향을 받지 않고 지속되는 것이 큰 장점입니다. Trunking은 STP 및 VLAN, HSRP등의 다른 네트웍기술과 완벽히 호환되기 때문데 기존의 네트웍 서비스에 영향을 미치지 않고 적용이 가능합니다.
Trunking으로 묶일 port들은 연속적인 port들이어야 합니다. 1, 2번 port및 5, 6, 7, 8번 port들은 trunking이 가능하지만 1, 4번 port를 트렁킹으로 묶을 수는 없읍니다. 또한 제조사에 따른 port 관리용 ASIC칩의 구성에 따라 조금씩 차이가 있을 수도 있읍니다.


................................[그림5]Network Design based on Fast Etherchannel

그림 5.는 Switch, Router, Server사이에 다양한 형태로 적용된 trunking(EtherChannel)을 나타내며 Router사이의 이중연결은 trunking이 아닌 시리얼 구간의 load-balancing기법을 나타냅니다. Wiring closet의 스위치는 전형적인 L2 switch이고 data center영역의 정사각형의 기호는 Multi Layer Switch를 나타냅니다.



4. MultiLayer Switch(MLS) and Vritual LAN(VLAN)






지난 번 기사에서 OSI reference model에 따라 분류할 때 Switch는 datalink layer(layer2), router는 network layer(layer3)에 속하는 장비라고 말씀드렸읍니다. MLS라는 것은 일반적인 스위치에 layer3의 정보를(예를 들자면 ip address)를 제어할 수 있는 라우터의 기능(Routing, Routing Protocol을 이용한 경로선택, HSRP, Access List 등)을 추가한 장비로 Router에 비해 빠른 전송속도가 특징입니다. Router가 패킷전송을 위한 경로결정을 대부분 cpu에 의존했다면 MLS는 최적화된 ‘Switching’ hardware, 특히 customized chips에 기반하여 구성되었기 때문데 라우팅을 포함한 모든 패킷 포워딩을 layer2 switch만큼이나 빠르게 처리할 수 있게 되었읍니다. 최근의 MLS들은 다양한 종류의 WAN interface를 수용하게 되면서 접속모듈의 다양성이나 port 밀도 등에서 장점을 지니게 되었으며 이에 따라 라우터들도 스위치의 특성을 받아들이게 되어 현재는 라우터와 스위치사이의 차이점은 점차 사라지고 있읍니다. 이러한 MLS의 발전은 Virtual LAN(VLAN) 기술의 개념도입 및 발전과 밀접한 관련을 맺어왔읍니다.
VLAN은 네트웍의 크기와 복잡성의 증가에 대한 대응수단의 하나로, 하나의 broadcast domain에 groupinge된 노드들의 집합입니다. switch의 도입이 collision domain을 물리적으로 segmenting 하여 네트웍의 성능을 증가시켰듯이 VLAN은 broadcast domain을 논리적으로 segmenting하여 라우터처럼 broadcast packet을 걸러냄으로써 대규모 네트웍에서의 지나친 broadcast에 의한 대역폭의 잠식을 방지하고 네트웍을 세분화할 수 있는 유연성을 제공합니다. 즉 VLAN이 설정된 switch는 라우터와 같이 여러 broadcast domain을 지니게 됩니다. 단, VLAN과 VLAN사이의 통신을 위해서는 여전히 라우터 혹은 MultiLayer Switch가 필요합니다.
다음 페이지의 그림 6.을 보면 빌딩전체의 네트웍은 업무영역에 따라 세개의 VLAN으로 나누어져 있고 따라서 세개의 logical한 broadcast domain이 존재합니다. 서로 다른 층의 스위치에 물려있더라도 같은 sales VLAN에 속한 노드들은 기존의 switched lan에서 처럼 서로간에 아무런 지장없이 통신을 할 수 있지만, 같은 3층 switch에 연결되어 있더라도 sales VLAN에 속한 노드와 HR VLAN에 속한 pc는 switch 연결이 없는 것 처럼 서로간에 아무런 연결을 할 수 없으며, 그림 7에서 보듯이 Router혹은 routing을 수행할 MultiLayer Switch(기존 switched LAN과의 비교시 routing에 따른 네트웍의 전송성능 저하를 막기위해서는 MLS가 유리합니다.)를 통해서만 각 VLAN사이에 연결이 가능합니다. 즉 완벽하게 전체 빌딩의 네트웍을 관리자 혹은 회사의 경여방침에 따라 분리해 낼 수 있으며, 실제 VLAN의 구축은 port 기반, ip address 기반, 특정 protocol기반 등 다양한 방법으로 조직구조에 맞춰 customizing이 가능합니다.

.......................
............................................[그림6]Typical VLAN Topology

.........
.................................................[그림7]VLAN사이의 통신

그림 6.과 그림 7.에서처럼 여러대의 스위치가 여러 개의 VLAN에 대한 정보를 동일하게 갖고 정확히 패킷을 전송하기위해서 스위치들 사이의 혹은 스위치와 라우터사이의 VLAN설정이 동일해야 하며 Cisco 장비의 경우 VLAN Trunking Protocol(VTP)을 적용할 경우 모든 VLAN정보를 스위치들에 일일이 설정하지 않고 하나의 VTP Server Switch에만 설정해주면 다른 switch들의 VLAN정보들은 자동적으로 업데이트 및 동기화가 됩니다. 그래서 혼선을 피하기위해 Cisco의 경우 port agregateion을 Trunking이라 하지않고 EtherChannel이라 부릅니다. VLAN정보가 동일하게 설정되었다면 스위치 사이에 오가는 패킷들이 어느 VLAN에 속하는지 구분하기위해 꼬리표를 달아(Tagging) 전송하게 되는데, 이 때 사용되는 protocol이 802.1q(open standard), ISL(Cisco only)입니다. 그림 6.에서 보자면 2층의 sales VLAN의 노드가 2층 스위치로 패킷을 보내면 스위치는 그 패킷에 자신이 가진 VLAN정보에 따라 sale VLAN의 꼬리표를 붙인 후 backbone스위치로 보냅니다. Backbone switch에서는 꼬리표의 정보를 읽은 후 같은 VLAN으로 가는 패킷이면 해당하는 스위치로 전송하고 다른 VLAN으로 가는 패킷이면 라우터나 MLS로 전송합니다.
마지막으로 VLAN의 도입에 따른 장점을 정리해보면 다음과 같읍니다.

Security : 민감한 데이터를 저장한 특정 시스템의 경우 네트웍상에 Router가 없다면 특정 VLAN 외부의 사용자는 절대 해당 VLAN에의 접근이 차단될 정도의 극단적인 보안수준이 가능하며, MLS 혹은 Router가 있어 접근이 가능한 경우에도 승인되지 않은 사용자의 접근 가능성을 감소시킬 수 있읍니다.

Performance : 특정 사용자 그룹이 고대역의 네트웍킹을 필요로 하는 경우에도 VLAN설정을 통한 유연한 대역폭 관리가 가능해져 필요한 부분의 네트웍 성능을 높일 수 있읍니다.

Broadcast/Traffic flow Control : VLAN이 Broadcast나 Multicast traffic을 통과시키지 않음으로 인해 전체 네트웍에 뿌려지는 Broadcast packet의 양을 감소시키고, 필요한 경우 관리자에게 Access list등을 통한 다양한 네트웍 접근제어를 가능하게 합니다.

Management : 특별한 프로젝트나 어플리케이션에 따라서, 혹은 기업내부의 조직개편이나 인사이동이 있는 경우에도 추가적인 케이블링 작업의 필요없이 Switch에서의 논리적인 설정 변경을 통해서 네트웍을 재설정할 수 있읍니다.

다음 기사에서는 Switched LAN의 총아로 떠오른 GigabitEthernet에 대해 살펴보고 소개된 기술에 기반한 기본적인 Switched LAN디자인 및 간단한 LAN troubleshooting에 대해서 알아보겠읍니다.




3장. GigabitEthernet(GE)과 LAN Design

1. GigabitEthernet



모 든 기술의 발달사가 그렇듯이 지금 까지 살펴본 여러 네트워크상의 신기술의 도입도 좀 더 고속/광역의 안정적인 네트워크 인프라에 대한 요구에의 대응으로 발달해 왔고 이번에 소개드리는 Gigabit Ethernet또한 100Mbps의 전송속도를 갖는 FastEthernet과 collison domain을 분리시키는 스위칭 기술의 도입에도 불구하고 급속도로 증가하는 네트워크 대역폭의 고갈에의 대처방안으로 시작되었읍니다. Gigabit Ethernet 이전에는 622Mbps의 대역폭을 갖는 ATM이 차세대 LAN기술의 선두자리를 차지하고 있었으나(또다른 LAN 형태인 FDDI(Fiber Distributed Data Interface)는 FastEthernet에 의해 벌써 대체 되었죠.) ATM을 Ethernet/FastEthernet 으로 구성된 기존의 LAN과 연결하기 위해서는 LANE등을 통한 Protocol간의 복잡한 변환과 심할 경우 Application의 변경도 요구되었기 때문에 ATM은 기존의 LAN과는 별다른 네트워크로 다루어져왔고, 도입을 위해서는 여러가지 조건을 따져봐야하는 어려움이 있었읍니다.

이러한 상황에서 FastEthernet의 10배 ATM과 비교해서도 2배 가까운(시뮬레이션 환경에서 1500bytes packet사이즈시 853.20Mbps 의 througput)대역폭을 제공하며 기존의 802.3 Ethernet표준(Fiber Cable을 이용하는 802.3z, category5 UTP cable을 이용하는 802.3ab)과 CSMA/CD 기술을 이어받아 LAN운영자나 사용자가 별도의 재학습없이 운영이 가능하고 Ethernet에서 운영되던 기존의 application의 수정없는 사용을 보장하는 GigabitEthernet이 상대적으로 저렴한 가격에 제공되면서 빠르게 ATM을 대체하는 차세대 LAN의 주역으로 등장하게 되었읍니다.

GigabitEthernet의 표준화는 Fiber Channel의 8B/10B코딩(부호화) 기술을 이용하는 1000Base-X(802.3z)와 category5 UTP cable을 이용하기위한 1000Base-T(802.3ab)로 나누어 진행되었으며 802.3z에는 현재 다음과 같은 3가지 규격이 존재합니다.

...a. Multi Mode 광케이블과 단파장의 트랜시버를 이용하는 1000Base-SX
...b. Multi Mode 광케이블 또는 Single Mode 광케이블과 장파장의 트랜시버를 이용하는 1000Base-LX
...c. Impedance가 150?인 Shield Balanced 케이블을 이용하는 1000Base-CX



[그림1]Gigabit Ethernet 표준사항


이중 최대 전송거리가 25m로 제한된 1000Base-CX기술은 가격의 저렴성이라는 장점이 있으나 실용성의 문제로 국내에서는 거의 이용되지 않고 있으며 실제로 가장 많이 적용되는 기술들을 중심으로 자세히 살펴보려고 합니다. 1000Base-SX와 1000Base-LX 표준은 모두 100Base-FX에서와 같은 SC-type Connector로 연결되는 광섬유 케이블을 이용하며 사용되는 Laser의 파장에 따라 구분됩니다.




[그림2]SC-type 광케이블 커넥터

1000Base-SX는 다중모드 파이버(MMF:Multi-Mode Fiber)상에서 단파장(Short-Wavelength:780nm) 레이저를 사용하며 최대전송거리가 광 케이블의 직경(diameter)따라 62.5마이크로미터 직경의 광케이블에서는 220m, 50마이크로미터 직경의 광케이블에서는 약 500m가 됩니다. 1000Base-LX는 장파장(Long-Wabelength:1300nm)레이저를 다중모드 파이버 혹은 단일모드 파이버(SMF:Single-Mode Fiber)상에서 사용하며, 62.5마이크로미터 직경의 MMF에서는 약 500m, 50마이크로미터 직경의 SMF를 사용할 경우에는 3Km이상의 최대전송거리가 가능합니다. 따라서 1000Base-SX의 경우 지리적으로 한정된 규모를 갖는 빌딩내의 LAN이나 서버-스위치 사이의 연결을 위해서, 1000Base-LX의 경우에는 빌딩과 빌딩사이의 광역 LAN(Campus Network)을 연결하는데 쓰입니다. 최근에는 저렴한 Gigabit Ethernet기술을 보다 지리적으로 보다 확장된 네트워크에 적용하기위한 Metro Ethernet에 대한 관심이 높아지면서 9마이크로미터 직경의 SMF를 이용하여 5-10Km까지 전송거리를 연장시킨 1000Base-LH기술이 발표되었읍니다. 초기 GigabitEthernet Switch들이 1000Base-SX 혹은 LX의 고정된 인터페이스를 가졌던 것에 비해 근래에는 GBIC(Gigabit Interface Converter )가 도입되어 스위치의 Gigabit port별로 SX-GBIC, LX-GBIC, LH-GBIC 을 각각 구성하는 것이 허용되어 네트워크 구성의 유연성이 대폭 증가되었읍니다.



[그림3] 1000Base-SX/LX/LH, 1000Base-T GBIC
기 존의 FastEthernet에서 사용되어 이미 널리 보급되 있는 category 5 UTP cable을 사용할 수 있는 1000Base-T, 802.3ab 표준은 추가적인 케이블의 포설이 필요없이 GigabitEthernet으로의 LAN 업그레이드가 가능하다는 점에서 대단히 매력적인 기술입니다.

3. GigabitEthernet 으로의 Migration
현재 사용중인 Ethernet/FasttEthernet LAN의 GigabitEthernet으로의 Migration을 할 때에는 도입시 실제 사용가능한 대역폭, 기존 혹은 도입예정의 타 제품들과의 상호 호환성, 구체적인 용도와 GigabitEthernet이 가진 단점들에 대해서도 한 번 쯤 고려해 볼 필요가 있읍니다. Ethernet Frame의 최대전송단위(MTU: Mximum Transmission Unit)인 1500bytes에서는 820Mbps의 전송속도를 보이지만 모든 프레임이 최소크기인 64bytes(ethernet header와 trailer길이의 합)인 경우에는 120Mbps, 평균 프레임 크기인 200-500bytes에서는 300-400Mbps정도의 성능을 보인다는 것을 고려할 때 대역폭 활용의 비효율성 문제가 대두될 수 있으며, 앞으로 네트워크 대역폭의 대부분을 차지하게 될 멀티미디어 트래픽의 경우 ATM같은 정교한 parameter에 의한 QoS(Quality of Service)의 보장을 위해서는 802.1q protocol에 따른 Vlan packet header에 따른 priority, 802.1p에 의한 priority queuing 및 multicast grouping 등을 염두에 두어볼 필요성이 제기될 수 있읍니다. 물론 앞에서 언급한 GigabitEthernet의 장점(고속/광대역, 저렴한 가격, 기존 네트워크에의 손쉬운 이식)들은 위의 단점들에도 불구하고 차세대 LAN의 주역으로서 GigabitEthernet의 확고히 하기에 충분합니다.
GigabitEthernet으로의 Migration이 결정되었다면 대략적으로 네가지 형태의 Migration을 고려할 수 있읍니다.



[그림4]Upgrading Switch-to-Switch Link



[그림5]Upgrading Switched FastEthernet Backbone



[그림6]Upgrading Switch-to-Server Link



[그림7]Upgrading High-Performance Workgroups

4. Switched LAN Design
네트워크의 디자인을 위해서는 앞서 다루어진 Switch에 의한 collision domain의 분리와 Router에 의한 broadcast domain의 분리, 이중link에서의 loop방지를 위한 STP나 큰 대역폭을 위한 Trunking기술, VLAN 과 GigabitEthernet등의 모든 기술이 고려되며 각 사이트의 기존사용환경이나 사용중인 application, 사용자의 요구사항에 따라 적용되게된다. 따라서 100개의 사이트를 위해서는 100개의 서로다른 네트워크 디자인이 있을 수 있으나 일반적으로 다음과 같은 항목에 대한 고려가 필요합니다.

1) 사용자의 네트워크 환경 분석 및 결정
운영할 애플리케이션 특성 검토 : 사용자의 서비스 요구 사항에 대한 분석, 신뢰성과 가용성에 대한 분석,과부하나 악조건에서의 운용 여부, 갑작스런 네트워크 단절, 패켓의 재 전송이 급격히 증가하는 경우에 대한 대처
네트워크 트래픽 분석 : 전송 데이터의 특성 - 실시간 처리 또는 일괄 처리, 패켓 크기
병목 현상 발생 여부 : 특정 서버나 스위치 세그먼트당 통계 분석 : 전체 네트워크의 트래픽에 적용
물리적 환경 분석 : 거리, 건물수, 장비의 설치 위치등 스위칭 포트를 이용하여 보다 쉬운 방법으로 세그먼트 설정이 가능
확장성 분석 : 시스템의 환경, 애플리케이션으 변화에 대한 유연성, 새로운 노드의 추가에 따른 트래픽의 변화, 기술 추세와 환경에 대한 전망, 사후 투자 비용에 대한 고려, 기존의 네트워크가 보유한 문제점 분석
새로운 네트워크의 장.단점 비교 분석 : 도입 네트워크의 타당성, 향후 기술 전개 방향, 기존과의 호환성 및 마이그레이션 여부 확인
예산과 platform 고려하여 네트워크 환경 결정 : FDDI, ATM, 고속 Ethernet 등 : Backbone 과 하부 네트워크를 설정
시스템의 관리 : 규모와 사용 환경에 따라 범위를 설정, 네트워크 모니터링, MS 에 의한 관리 Application 환경에 맞는 관리 디자인을 고려

이러한 고려 사항들은 실제로는 지나치고 넘어가는 경우가 많으나, 네트워크의 특성에 따라 어떤 부분은 철저한 분석이 필요하게 된다.


2) 기술적 문제 검토
2) 특정 벤더에 속하지 않는 컨설팅 선택
2) 향후 적용될 기술 접목 가능성과 상호 연동성
2) 디자인 후 개선 사항
2) 프로토콜의 선택
2) Application, topology 의 적용

2) Network의 Design작업이 끝난 후에는 파일럿 시스템의 운용 및 BMT를 거쳐 검증과 문제점에 대한 분석 및 보완작업을 거쳐 실제 설치와 추후 운영 및 유지보수의 결정까지가 기업네트워크의 디자인에 있어서 반드시 고려되어야 할 사항입니다.

그림 8.은 계층구조적인 네트워크 디자인의 개념을 보여주는 것으로서, 각기 다른 기능을 제공하는 세 계층-Core, Distribution and Access-으로 구성됩니다.



[그림8]계층 구조적인 네트워크 디자인 모델

Access 계층은 일반 user들에 대한 접속기능을 제공하고, Distribution 계층은 inter-Vlan routing이나 broadcast domain의 관리 및 각종 보안기능의 적용을 통해 controlled connectivity를 제공하며 Core 계층은 high-speed Switching기능을 제공하게 됩니다. 이러한 계층구조개념에 따라 대략적으로 구성가능한 몇 가지 디자인을 살펴보면 그림 9., 그림 10., 그림 11. 등이 가능합니다.



[그림9]Building LAN Desing 과 축약(Collapsed)된 백본 모델





[그림10]Layer 2 Switched Backbone Model ? Single Vlan


[그림11]Layer 3 Switched Backbone Model ? Multiple Vlan
위의 세 네트워크 디자인은 Campus 규모의 네트워크을 위해 고안된 것으로 사용자 규모에 따라 기능과 크기의 축소 및 확장이 고려되어야 합니다.

네트워크에 문제는 LAN의 경우 90%정도가 물리적 특히나 케이블과 관련된 문제 혹은 대역폭의 포화상태로 인한 서비스 응답시간의 지연일 가능성이 높읍니다. 이를 확인하기 위해서는 전문적인 네트워크 분석기 혹은 프로토콜 분석기를 이용해야만 정확한 진단이 가능합니다. 라우터나 스위치에서 각 포트의 물리적 상태와 트래픽 및 에러의 통계상태를 통해서도 확인이 가능하나 수많은 포트를 일일이 수동으로 확인해야 하는 어려움이 따릅니다. 최근에는 web-base의 GUI를 장착한 간단하고 해석이 편리한 NMS들이 많이 도입되면서 네트워크 관리자의 장애관리 및 성능관리 업무에 편리성이 높아지고 있습니다.


'Network' 카테고리의 다른 글

T1 과 E1 이란?  (1) 2011.07.19
기가비트 이더넷의 이해  (0) 2008.11.06
TCP/UDP Port List  (0) 2008.09.29
Port List #2  (0) 2008.09.29
Port List #1  (0) 2008.09.29

기가비트 이더넷의 이해

Posted 2008. 11. 6. 16:46


출처 : http://kmh.yeungnam-c.ac.kr/encycl/terms/termsG/gigabite2.htm

 

기가비트 이더넷(Gigabit Ethernet)의 이해

 


I. 서 론

최근에 와서 정보 처리의 많은 부분이 데스크탑 컴퓨터에 의해 이루어지고 있다. 이러한 데스크탑 컴퓨터들은 대부분 근거리 통신망(LAN: Local Area Network)으로 연결되어 있으며, 이들은 10Mbps의 이더넷(Ethernet)으로 연결된 경우가 많다. 또한 이러한 데스크탑 컴퓨터에서 처리하는 응용 서비스는 점점 복잡해 지고 LAN에 연결되는 개수도 많아져서 네트워크의 트래픽이 매우 빠른 속도로 증가하였다. 따라서 고속 네트워크의 필요성이 점차 증대되고 있다.
요즈음 사용 가능한 고속 LAN 기술 중에서 고속 이더넷(Fast Ethernet)이 가장 많이 사용되고 있다. 이것은 기존의 이더넷을 유연하게 100Mbps로 향상시킬 수 있기 때문이다. 최근에는 이러한 이더넷 기술을 발전시킨 초고속 네트워크 기술의 하나로 기가비트 이더넷이 등장하였다. 기가비트 이더넷은 고속 이더넷의 경우처럼 유연하게 초고속 네트워크를 구성할 수 있게 해 준다는 점에서 흥미롭다.
현재 네트워크 기술의 사용 현황을 보면, 1997년에 이더넷이 약 77%를 차지하고, 기타 ATM, FDDI/CDDI 및 토큰링 등이 13%를 차지할 것으로 IDC는 보고하고 있으며, 이러한 추세는 1999년 까지 계속될 것으로 예상하고 있다. 이처럼 이더넷은 네트워크 분야에서 매우 독보적인 위치를 고수하고 있다. 이처럼 많은 이더넷 사용자들 중에서 고속 네트워크로 성능 향상을 원하는 경우 여러가지 고속 네트워크 기술 중 어떤 기술을 선택해야 하는지와 비용은 얼마나 지불해야 하는가의 문제는 매우 현실적이며 심각한 상황이다.
따라서 본 고에서는 현재 비교적 저렴한 가격에 유연하게 고속 네트워크로 성능을 향상시킬 수 있어서 큰 관심을 끌고 있는 기기비트 이더넷에 대해 기술적인 측면과 표준화 현황에 대해 간략하게 살펴보고자 한다. 또한 기존의 고속 네트워크 기술인 ATM과의 장단점에 대해 비교해 보고자 한다.

II. 표준화 현황

표준화 문제는 통신이 단독적으로 동작하는 것이 아니라 상대와 서로 일정한 규약을 가지고 정보를 교환한다는 것이다. 이 규약이 다르면 서로 통신할 수 없으므로, 통신에서는 이 규약을 정하는 표준화 작업이 매우 중요하다. 따라서 기가비트 이더넷의 표준화 현황에 대해 먼저 살펴보자.
1996년 3월에 IEEE 802.3 위원회는 802.3z 기가비트 이더넷 표준화 프로젝트를 승인했다. 곧이어 1996년 5월에 11개 회사(3Com Corp., Bay Networks Inc., Cisco System Inc., Compaq Computer Corp., Grantie Systems Inc., Intel Corp., LSI Logic, Packet Engines Inc, Sun Microsystems Computer Company, UB Networks, VLSI Technology)가 참여하여 기가비트 이더넷 연합(alliance)을 결성하였다. 현재는 여기에 95개의 회사가 참여하고 있다. 이 연합은 개방적이고 호환성 있는 기가비트 네트워크를 제안한다는 취지 하에서, 현존하는 이더넷 및 고속 이더넷의 기술을 확장하고, 표준에 포함되는 기술적 제안들을 개발하고, 상호 운용성을 위한 테스트 절차 및 과정을 확립하는 것이 그 목적이다.

기 가비트 이더넷의 표준안 중 802.3z는 1998년 7월에 승인/출판되었으며, 802.3ab는 1999년 상반기에 완료될 것으로 보인다. 참고로 (그림 1)은 IEEE 802.3의 표준화 그룹별 진행 상황을 나타내었으며, (그림 2)는 항목별 진행 상황을 나타내었다.

III. 기가비트 이더넷의 특성

1. 기가비트 이더넷의 구성

(그림 3)은 기가비트 이더넷의 기능별 구성 요소를 나타내었다. 기가비트 이더넷은 물리계층의 매체로는 광섬유(fibre-optic cable) 및 구리선(copper cable) 두 가지를 지원하며, 또한 각 매체의 인코더/디코더 부분과 MAC(Media Access Control), GMII(Gigabit Media Independent Interface)로 구성되어 있다. GMII는 MAC과 물리 계층의 중간에서 인터페이스로 Full-duplex/Half-duplex를 모두 지원하게 해주는 것으로 고속 이터넷의 MII(Media Independent Interface)를 확장한 것이다.


2. 물리계층(Physical Layer)

기가비트 이더넷의 물리계층은 기존 이더넷에서 사용하던 기술과 ANSI X3T11 Fibre Channel 규격을 혼용해서 사용하고 있다. 기가비트 이더넷은 최종적으로는 4가지의 매체(media)를 지원하게 될 것이며, 802.3z(1000Base-X)와 802.3ab(1000Base-T)에서 규정될 것이다.
1000Base-X 표준의 Fibre Channel의 물리계층을 근간으로 하고 있다. Fibre Channel은 워크스테이션, 슈퍼컴퓨터, 저장 장치, 기타 주변 기기 등의 연결에 사용하는 기술로 4개의 계층 구조를 가지고 있다. 이중 하위 2개의 계층인 FC-0(Interface and media)와 FC-1(Encode/Decode)를 기가비트 이더넷에서 사용하고 있다. 이것은 아마도 이미 인증된 기술을 사용하므로서 표준화에 걸리는 시간을 절약하려는 의도로 보인다.
1000Base-T 표준은 장거리 비차폐 구리선(long haul copper UTP)을 사용하는 것으로 25~100m의 4가닥 Category 5 UTP를 사용하는 것을 목표로 하고 있다. 현재 표준안을 제정 중에 있으며 1999년 상반기에 완성될 것으로 보인다.


<표 1>은 기가비트 이더넷의 종류별 매체를 나타내었으며, <표 2>는 케이블의 종류와 거리를 나타내었다.


3. MAC 계층

기가비트 이더넷의 MAC 계층은 이더넷의 CSMA/CD 프로토콜을 사용한다. 이더넷의 최소 프레임(frame) 크기는 64 바이트이다. 이것은 어떤 국(station)에서 프레임의 첫 비트가 케이블의 끝에 도달하기 전에 한 프레임을 완전히 전송해 버리는 것을 막기 위해서 이다. 따라서 충돌(collision)을 감지(detection)하는 최소한의 시간을 "슬롯 시간(slot time)"이라 하고, 이 시간 동안 전송할 수 있는 바이트 수를 "슬롯 크기(slot size)"라 한다. 이더넷의 경우, 슬롯 크기는 64 바이트이며 이것이 최소 프레임의 크기가 된다.
이더넷에서 케이블의 최대 길이는 2.5Km(최대 4개의 리피터(repeater)를 사용한 경우) 이다. 만일 속도가 증가하게 되면 송신에서는 프레임을 빨리 보내게 되고 그 결과 같은 크기의 프레임과 같은 길이의 케이블을 사용한다면, 어떤 국에서는 프레임 전송이 너무 빨라 케이블 끝에서 충돌을 감지하기 전에 프레임 전송이 끝나 버릴 수 있다. 따라서 이러한 문제를 해결하기 위해서는 케이블 길이를 최대로 유지하고 슬롯 시간을 증가 시키거나, 슬롯 시간을 유지하고 최대 케이블 길이를 감소시켜야 한다. 고속 이더넷의 경우, 최대 케이블 길이를 100m로 감소시키고 최소 프레임 크기와 슬롯 시간을 그대로 두었다.
기가비트 이더넷은 이더넷의 최소와 최대 프레임 크기를 유지하였다. 따라서 기가비트 이더넷은 고속 이더넷보다 10배 빠르므로 슬롯 크기를 유지하려면 최대 케이블 길이를 10m로 감소시켜야 하는 데 이것은 별로 바람직한 방법이 아니다. 그러므로 기가비트 이더넷에서는 슬롯 크기를 512 바이트 보다 크게 하였다. 그러나 이더넷과의 호환성을 유지하기 위해서는 최소 프레임 크기가 증가하지 않아야 하므로 "carrier event"를 확장 시켰다. 만일 프레임이 512 바이트보다 작으면 확장 심볼(extension symbol)로 채워 넣는다. 이것은 특수한 심볼로 유료 하중(payload)에서는 발생하지 않는다. 이러한 과정을 캐리어 확장(carrier extension)이라 한다.
기가비트 이더넷에서 캐리어 확장은 적정한 케이블 길이를 가지면서 802.3의 최소 및 최대 프레임 크기를 유지하여, 현재 사용하고 있는 802.3 네트워크와 상호 운용성(inter-operable)을 유지하기 위한 방법이다.


(그림 4)는 캐리어 확장을 사용한 이더넷 프레임의 형식을 나타내었다.



캐 리어 확장은 이더넷과의 상호 운용성을 유지하는 매우 간단한 해결책이기는 하지만 대역폭을 낭비하게 된다. 작은 프레임을 보내려 할 때에도 최고 488바이트까지 채워 넣어야 한다. 이것은 결국 성능의 저하를 초래한다. 많은 수의 작은 프레임을 사용하게 되면 극한적인 경우 고속 이더넷의 수준으로 성능이 저하하게 된다. 이것을 방지하기 위하여 "프레임 연속(Frame Burst)"을 사용한다. 프레임 연속은 "캐리어 확장의 확장"으로, 어떤 국이 여러 개의 프레임을 보낼 때 첫 프레임이 캐리어 확장이 필요할 때 사용하게 된다. 다음 프레임들은 연속해서 최소 IPG(Inter Packet Gap)에서 연속 타이머(Burst timer)가 종료될 때 까지 전송한다. (그림 5)는 프레임 연속의 동작을 나타내었다.

4. GMII(Gigabit Media Independent Interface)


GMII는 물리 계층과 MAC 계층 사이에 존재하는 것으로 어떤 물리 계층에서도 MAC 계층을 사용할 수 있게 해 준다. 이것은 고속 이더넷에서 사용하고 있는 MII(Media Independent Interface)를 확장한 것으로 10, 100, 1000Mbps의 데이터 처리 속도를 지원한다. 또한 GMII는 독립된 8 비트의 데이터 송×수신 경로를 가지고 있어서 full-duplex와 half-duplex를 공히 지원할 수 있다.
GMII는 캐리어의 존재를 표시하는 것과 충돌이 없다는 것을 표시하는 2개의 상태를 가리키는 신호를 제공한다. 조정 서브레이어(Reconciliation Sublayer)는 이러한 신호들이 MAC 서브레이어에게 물리 신호(PLS: Physical Signaling)의 인자(primitive)로 이해하도록 한다. GMII는 같은 MAC 콘트롤러를 사용하면서도 다양한 형태의 매체를 사용할 수 있게 해준다.


GMII는 다음과 같이 3개의 서브레이어로 구성되어 있다.
○ PCS(Physical Coding Sublayer)
○ PMA(Physical Medium Attachment)
○ PMD(Physical Medium Dependent)


(그림 6)에 기가비트 이더넷의 프로토콜 구조를 나타내었다.


IV. 기가비트 이더넷의 적용

현재 사용하고 있는 이더넷에서 기가비트 이더넷으로 전환하기 위한 방법으로 대략 3가지 시나리오를 생각할 수 있다.
먼저 가장 간단한 방법으로 (그림 7)과 같이 사용하고 있는 스위치와 스위치 간의 링크를 기가비트 이더넷으로 대체하는 것이다.

또 다른 시나리오는 네트워크가 서버로 집중되어 있는 경우, (그림 8)과 같이 스위치와 서버 간의 링크를 기가비트 이더넷으로 대체하면 된다.
만일 백본으로 10/100Mbps 스위치를 사용하고 있다면, (그림 9)와 같이 백본 스위치를 100/1,000Mbps 스위치로 대체하면 된다.

 

V. ATM과 기가비트 이더넷

ATM(Asynchronous Transfer Mode)이 소개되었을 때 155Mbps의 대역폭을 가지므로 고속 이더넷보다 대략 1.5배 정도 빨랐으며, 새로운 응용 서비스, 특히 멀티미디어 서비스의 경우 매우 이상적으로 생각되었다. 한편, ATM 측에서는 LANE(LAN emulation)과 IOPA(IP over ATM) 등으로 이더넷 이뮬레이션을 추진하였다. 반면에 Ethernet/IP 측에서는 RSVP (Resource Revervayion Protocol)과 RTSP(Real-time Streaming Transport Protocol) 등으로 ATM의 기능들을 제공하려고 하였다. 그러나 두 기술은 그들 고유의 기능들과 각각의 장점들이 있다는 것은 분명한 사실이다.
ATM의 경우, LAN, WAN, 백본 등에 사용될 수 있어서 유연하고 확장성이 좋은 장점이 있다. 이더넷은 오랫동안 LAN에서 독보적으로 사용되어 왔다. 기가비트 이더넷이 이제 막 시장에 진출하려고 하므로서 양측의 경쟁은 피할 수 없어 보인다. 현재 대부분의 워크스테이션과 PC 들은 고속 네트워크에 접속되어 있지 않다. 따라서 대규모 네트워크에서 스위치와 서버들 간의 네트워크와 백본에서 이들의 경쟁이 매우 치열할 것으로 생각된다.
ATM은 기가비트 이더넷에 비해 다음과 같이 몇가지 이점이 있다. 먼저 ATM은 현재 기가비트의 속도를 지원하지는 못하지만 향후 빠른 속도를 지원하기 위한 버전에 대한 계획이 확립되어 있고, 이미 많이 사용되고 있다는 점에서 유리하다. 또한 ATM은 QoS(Quality of Service)에 강점이 있고, CBR(Constant Bit Rate)이 있어 다양한 응용 서비스를 지원할 수 있다.
하지만 기가비트 이더넷에도 유리한 점이 있다. 기가비트 이더넷의 강점은 그것이 바로 이더넷이라는 것이다. 현재 사용하고 있는 이더넷에서 기가비트 이더넷으로의 전환이 ATM의 경우 보다 매우 쉽다는 것이다. 또한 속도면에서도 현재 ATM이 622Mbps를 지원하는 데 비해 기가비트 이더넷은 ATM에 비해 거의 2배 정도 빠른 속도를 지원하고 있다.
현재로서는 어느 한쪽이 다른 한쪽을 완전히 물리치고 승리할 것인지는 판단하기 어렵다. 이것은 사용자들이 각각의 장점들 중에서 어떤 것을 선택할 것 인지가 관건이 될 것이다.

VI. 결 론

본 고는 기가비트 이더넷의 기술적인 특성 및 표준화 등에 대해 간략히 살펴 보았으며 ATM과의 장단점에 대해서도 살펴 보았다. 기가비트 이더넷은 제 3 세대의 이더넷 기술로 1,000Mbps의 속도를 제공한다. 또한 기존의 이더넷과 호환성을 유지해 줌으로 현재의 네트워크를 유연하게 고속 네트워크로 향상 시킬 수 있게 해 준다. 이제 막 탄생한 기가비트 이더넷이 기존의 고속 네트워크 기술인 ATM 및 FDDI와 어떻게 경쟁하여 자기 자리를 잡을지는 좀더 지켜봐야 할 것이다.


기기비트 이더넷의 표준화 경향



'Network' 카테고리의 다른 글

T1 과 E1 이란?  (1) 2011.07.19
Ethernet과 Switch 모든것  (1) 2008.11.06
TCP/UDP Port List  (0) 2008.09.29
Port List #2  (0) 2008.09.29
Port List #1  (0) 2008.09.29
« PREV : 1 : ··· : 5 : 6 : 7 : 8 : 9 : 10 : 11 : ··· : 18 : NEXT »