숭늉이

1. Lock and Key ACL(Dynamic ACL)

Lock and Key ACL은 인증된 곳으로부터 오는 트래픽을 허용하기 위해 동적으로 ACL 항목을 추가하여 트래픽 필터링을 가능하게 하는 보안 기능이다.

- 기존 ACL은 관리자가 항목을 변경하지 않는 한 바뀌지 않지만, Lock and Key ACL은 사용자가 라우터에 인증한 다음에만 활성화되는 동적 ACL 항목을 추가한다. 인증 과정이 끝난 뒤, 동적 ACL 항목은 미리 설정된 시간이 지나거나 동적 항목의 최대 수명이 다 할 경우 삭제된다. 이 동적 ACL 항목이 삭제되면 라우터 인터페이스 설정은 원래대로 동작을 실시한다.

- 라우터에 인증을 하기 위해서 Telnet 패켓을 전송한다. 그 다음 라우터는 관리자가 설정한 인증 데이터베이스를 기반으로 인증을 수행한다. 이 인증 과정은 로컬 라우터에 저장되어 있는 사용자 이름/패스워드를 이용할 수 있고, 또는 인증 서버(TACACS+, RADIUS)를 이용할 수도 있다.

- 사용자가 인증에 성공되면 Telnet 세션은 닫히고 동적 ACL 항목이 추가된다. 이 동적 ACL 항목은 만료시간이 지나면 삭제되며, 그전에 관리자에 의해 삭제도 가능하다.

- 사용자가 DHCP 및 Dialer-Up 환경을 통해 인터넷에 연결되어 있다면 고정 IP 대신 유동 IP를 사용하게 된다. 이때, 사용자는 매번 다른 IP 주소를 가지고 네트워크 자원에 접근을 실시하게 된다. 이때, Lock and Key ACL를 사용하면 공격자로부터 보안 수준을 높일 수 있다.

- Lock and Key ACL은 두 개의 추가 필드를 제외하고는 Extended ACL과 동일하다.

2. Lock and Key ACL Example

R11은 Lock and Key ACL를 구성하여 Telnet을 통해 Local 인증이 성공된 사용자만 FTP에 접근을 허용하길 원한다.

1) Telnet으로 접속 하는 모든 사용자는 Telnet 접속 이후 연결이 끊어진다.

R11(config)# username cisco password cisco

R11(config)# access-list 113 dynamic FTP_USER timeout 60 permit tcp any host 172.16.1.113 eq ftp

R11(config)# access-list 113 permit tcp any host 11.11.11.11 eq telnet

R11(config)# interface serial 0/0

R11(config-if)# ip access-group 113 in

R11(config-if)# line vty 0 4

R11(config-line)# login local

R11(config-line)# autocommand access-enable host timeout 10

2) Telnet으로 접속 하는 Lock and Key ACL 사용자만 Telnet 접속 이후 연결이 끊어진다.

R11(config)# username cisco password cisco

R11(config)# username cisco autocommand access-enable host timeout 10(10분 동안 트래픽이 없으면 dynamic ACL 해제)

R11(config)# access-list 113 dynamic FTP_USER timeout 60 permit tcp any host 172.16.1.113 eq ftp(60 분후 dynamic ACL 해제)

R11(config)# access-list 113 permit tcp any host 11.11.11.11 eq telnet

R11(config)# interface serial 0/0

R11(config-if)# ip access-group 113 in

R11(config-if)# line vty 0 4

R11(config-line)# login local

3. Verifying Lock and Key ACL

- Lock and Key ACL를 구성한 R11은 사용자 로그인이 없을 경우에는 평범한 ACL로 동작을 실시한다.

- 만약, 사용자로부터 Telnet 접속 및 로컬 인증을 실시 하게 되면, 사용자에 대한 소스 트래픽을 동적으로 ACL 항목에 추가하여 동작을 실시한다.

- 위의 정보 확인을 통해 Lock and Key ACL의 동작 원리를 확인할 수 있다.

- 앞에 설정 중에 ‘R11(config)# username cisco autocommand access-enable host timeout 10’는 ‘cisco’라는 사용자에 대해서만 Lock and Key ACL에 적용되어 Telnet 연결을 종료시키고, 나머지 사용자들에 대해서는 Telnet 종료를 시키지 않는 구문이다. 그 이유는 FTP Server 접근을 위한 Lock and Key ACL 사용자 이외에도 관리목적상 R11으로 Telnet 접근을 실시하는 관리자를 위해서 위의 구문은 필요하다.

- 또한 ‘host’ 키워드를 사용하지 않으면 모든 트래픽들을 허용하는 동적 항목이 생성되기 때문에, ‘host’ 키워드를 빼먹어서는 안된다.

4. Reflexive ACL

Reflexive ACL은 Standard ACL과 Extended ACL에서 제한되었던 일부 기능을 가능하게 하였고, Extended ACL과 마찬가지로 상위 계층 세션 정보에 근거하여 IP 패켓을 필터링한다, 또한, 허용된 세션에 속하는 IP 트래픽에 대한 동적 연결 정보를 유지하여 세션 필터링도 할 수 있다.

- Reflexive ACL를 사용하면 내부 네트워크로부터 시작된 세션에 속하는 IP 트래픽을 허용하고, 외부 네트워크로부터 시작된 세션에 속하는 IP 트래픽을 거부할 수 있다. 설정은 Extended Named ACL으로만 설정이 가능하다.

- IP 상위 계층 세션이 내부 네트워크로부터 시작되어 외부 네트워크로 전송되는 경우, 새로운 임시 항목이 ACL 항목에 생성되어 외부 네트워크로부터 되돌아오는 트래픽을 허용한다. 되돌아오는 트래픽 중에 세션에 속하는 트래픽만 허용하고 나머지 다른 트래픽들은 거부된다.

- 이렇게 동작 하는 이유는 내부에서 외부 네트워크로 TCP 패켓이 나갈 때 임시 ACL 항목이 Reflexive ACL 항목 내에 생성되기 때문에 외부로 나가는 트래픽에 대응하여 내부로 들어오는 트래픽만 허용한다.

- Reflexive ACL은 기존의 ACL처럼 아무런 명시를 하지 않는 한 ‘deny any’ 처리는 실시 하지 않는다. 그 이유는 Reflexive ACL은 다른 ACL에 포함되어 동작하기 때문에, 일단 Reflexive ACL를 처리하고 나면, 라우터는 Extended ACL의 나머지 부분을 계속 처리를 한다.

- Extended Named ACL 구성 시 ‘reflect’ Command와 ‘evaluate’ Command가 사용된다.

5. Reflexive ACL Example

R1에서 Reflexive ACL를 구성하여, 내부 사용자 192.168.1.0/24가 외부로 나갔다가 되돌아오는 Telnet 트래픽을 허용하며, 외부에서 직접적으로 R1 내부 네트워크로 접근하는 Telnet 트래픽은 허용하지 않길 원한다. (Ping Test는 가능하게 하여라)

R1(config)# ip access-list extended OUTBOUND

R1(config-ext-nacl)# permit icmp any any

R1(config-ext-nacl)# permit tcp any any reflect RFX_USER

R1(config-ext-nacl)#

R1(config-ext-nacl)# exit

R1(config)# ip access-list extended INBOUND

R1(config-ext-nacl)# permit icmp any any

R1(config-ext-nacl)# evaluate RFX_USER

R1(config-ext-nacl)# exit

R1(config)# interface serial 0/0

R1(config-if)# ip access-group OUTBOUND out

R1(config-if)# ip access-group INBOUND in

Reflexive ACL은 Telnet과 같은 단일 채널의 어플리케이션만 다룰 수다는 단점을 가지고 있다. 이러한 어플리케이션은 세션이 지속되는 동안 동일한 정적 포트 하나만을 사용한다. 즉, 세션 중간에 포트가 변경되는 어플리케이션을 지원하지 못한다. 한 예로 하나의 통제 채널과 다른 하나의 데이터 채널을 사용하는(다중 채널 어플리케이션) FTP를 들수 있다. 만약, Reflexive ACL과 FTP를 사용한다면 FTP는 수동 모드인 Passive Mode로 동작을 실시해야 한다.

1. CBAC(Context-based Access Control)

Reflexive ACL은 오직 단일 채널 어플리케이션만 제어할 수 있다. 이러한 문제점 때문에 기업 네트워크에서 많은 제

한을 가지고 올 수 있다. 이 문제를 해결하기 위해서 나온 것이 바로 CBAC이라는 기능이다.

- CBAC은 외부로 나가는 세션을 검사하여 그 트래픽에 대한 응답 트래픽을 위한 임시 항목을 생성한다. 마치 Reflexive ACL과 비슷하게 생각되지만, CBAC은 Reflexive ACL보다 다양한 어플리케이션 계층 정보를 검사하고 안전하게 정의하는 점에서 차이가 있다.

- CBAC은 연결을 제대로 처리하려면 각 연결의 상태를 끊임없이 모니터링을 실시 하기 때문에 Stateful 상태 감시 검사법이라고 한다. 즉, 어떠한 트래픽을 정의하여 이 트래픽이 특정 인터페이스를 통해 네트워크 외부로 나가는 경우 CBAC은 그 트래픽에 대한 응답 트래픽이 내부 네트워크로 들어갈 수 있도록 임시 항목을 생성한다는 것이다. 이때 임시 항목은 Reflexive ACL과 마찬가지로 응답 트래픽을 허용하며, 초기 트래픽과같은 세션에 속하는 추가 데이터 채널이 라우터를 통해 내부 네트워크로 들어올 수 있도록 한다.

- CBAC은 네트워크와 전송 계층은 물론 어플리케이션 계층 프로토콜까지 검사하여 TCP/UDP의 세션 정보를 검사한다. 일부 프로토콜은 제어 채널을 통해 교환한 정보를 이용하여 추가적인 채널을 연다. 그렇기 때문에 IP와 전송 계층정보만 가지고 이런 프로토콜을 필터링할 수 없었지만, CBAC은 가능하다. 즉, CBAC은 외부로 나가는 세션 정보를 검사하여 응답 트래픽이 되돌아 오기 위한 임시 ACL 항목을 생성하며, 7계층 어플리케이션까지의 정보에 기반한 결정을 내릴 수 있다.

- CBAC을 사용할 경우 패켓은 인터페이스에 들어갈 때나 나올 때 검사되며 세션 정보는 패켓 상태 정보 테이블에 저장된다. 이 정보는 IP 주소와 4계층 포트 번호를 포함한다. 또한, CBAC은 라우터가 어떤 ACL이 응답 트래픽을 거부해야 할 지 자동으로 결정한 다음 임 ACL 항목을 ACL의 맨 첫 줄에 추가한다. 그리고 어플리케이션 계층 정보를 검사하여 응답 트래픽의 허용/거부 여부를 결정한다.

- Reflexive ACL에서는 FTP에 대해서 처리할 때에는 Passive Mode로 동작할 수 밖에 없는 제한이 있었지만, CBAC에서는 일반 FTP Mode에서도 트래픽에 대한 접근 제어가 가능하다. 즉, 외부로 나가는 세션을 모니터링 한 뒤에 서버에서 클라이언트로 맺는 연결을 허용하기 위한 임시 ACL 항목을 생성하여 동작하게 된다.

- CBAC은 출발지/목적지 주소가 라우터의 주소로 설정된 패켓은 검사하지 않는다. 그리고 CBAC은 오로지 TCP/UDP 패켓만 검사하기 때문에 라우터 자체가 주고 받은 패켓은 CBAC으로 제어할 수 없다.

- CBAC은 IPSec 트래픽을 검사할 수 없다. 만약, IPSec 트래픽을 검사해야 한다면 라우터를 IPSec 터널 종단으로 구성해야 한다.

- UDP/ICMP 트래픽은 비 상태 감시 프로토콜이기 때문에 CBAC은 이들 프로토콜의 세션에 대한 상태 정보를 추적할 수 없다. UDP 응답 패켓은 일정 시간 후에 만료되는 임시 ACL 항목으로 제어가 가능하지만, ICMP는 반드시 확장 ACL 명령어로 허용/거부되어야 한다. 즉, CBAC은 ICMP 제어 기능을 제공하지 않는다.

2. CBAC Process

2개의 인터페이스 중에 Ethernet 0 인터페이스 쪽은 네트워크가 우리가 보호하고자 하는 내부 네트워크에 연결되어 있고, Serial 0 인터페이스 쪽은 외부 네트워크에 연결되어 있으며, 이때 ‘Outbound Traffic’은 내부 네트워크에서 외부 네트워크로 나가는 트래픽이고, ‘Inbound Traffic’은 외부 네트워크에서 내부 네트워크로 흘러 들어오는 트래픽이라고 가정하여, CBAC 처리과정에 대해서 알아보도록 하자.

- 외부로 나가는 패켓이 라우터에 도착하면 라우터는 아웃바운드 ACL을 이용해 그 패켓을 검사한다. 만약, ACL에 그 트래픽을 허용하면, 이제 CBAC은 그 트래픽을 검사할 수 있다. 그렇지 않다면 패켓은 드랍될 것이고 CBAC은 패켓을 검사하지 않을 것이다.

- CBAC 검사 과정 동안, 출발지/목적지 IP 주소와 포트 번호를 포함한 정보가 기록된다. 이 정보는 새 연결을 위해 생성된 상태 테이블 항목에 기록된다. 이 상태 정보에 기반한 임시 ACL 항목이 생성된다. 이 ACL 항목은 인바운드 트래픽을 필터링 하도록 설정되어 있는 Extended ACL의 맨 앞에 위치하게 된다.

- 이 임시 ACL 항목은 앞에서 검사한 아웃바운드 패켓과 같은 연결에 속한 인바운드 패켓을 허용하도록 되어있다. 이제 아웃바운드 패켓이 인터페이스 밖으로 빠져나간다.

- 응답 패켓이 돌아오면 인바운드 ACL의 검사를 받게 되는데 CBAC이 생성한 임시 ACL 항목이 있기 때문에 접근이 허용된다. 여기서 CBAC은 필요할 경우 상태 테이블과 인바운드 ACL 목록을 수정한다. 그 이후로, 전송되는 모든 인바운드 아웃바운드 트래픽은 이 ACL 항목과 비교된다. 그리고 상태 테이블 접근 목록은 필요할 경우에 계속 수정된다. 연결이 끝나면 상태 테이블 항목과 임시 ACL 항목이 삭제가 된다.

3. CBAC Example

인터넷으로 나가는 모든 아웃바운드 IP 트래픽을 허용한다. 만약 누군가가 내부 네트워크에서 VPN 연결을 하는 것을 막고 싶다면 TCP, UDP, ICMP를 제외한 모든 IP 트래픽을 거부하면 된다.

R1(config)# ip inspect name TEST_CBAC tcp

R1(config)# ip inspect name TEST_CBAC udp

R1(config)# ip inspect name TEST_CBAC ftp

R1(config)# ip inspect name TEST_CBAC http

R1(config)# ip inspect name TEST_CBAC realaudio

R1(config)# ip access-list extended OUTBOUND

R1(config-ext-nacl)# permit ip 192.168.1.0 0.0.0.255 any

R1(config-ext-nacl)# exit

R1(config)# ip access-list extended INBOUND

R1(config-ext-nacl)# permit icmp any 192.168.1.0 0.0.0.255 echo-reply

R1(config-ext-nacl)# permit icmp any 192.168.1.0 0.0.0.255 traceroute

R1(config-ext-nacl)# permit icmp any 192.168.1.0 0.0.0.255 time-exceeded

R1(config-ext-nacl)# permit icmp any 192.168.1.0 0.0.0.255 unreachable

R1(config)# interface ethernet 0/0

R1(config-if)# ip inspect TEST_CBAC in

R1(config-if)# ip access-group OUTBOUND in

R1(config)# interface serial 0/0

R1(config-if)# ip access-group INBOUND in

앞에 설정에 대한 내용을 알아보도록 하자.

- CBAC은 인터넷으로 나가는 모든 트래픽에 대한 응답 패켓이 내부 네트워크로 되돌아 올 수 있도록 한다.앞의 CBAC 설정에는 구체적으로 FTP, HTTP, Real-audio 트래픽을 검사하라는 설정을 하였다. 그 이유는 내부 네트워크 사용자가 이들 프로토콜을 이용하는 어플리케이션을 사용하고 있기 때문이다.

- 그리고 설정 마지막 부분에는 ICMP 트래픽에 대해서 라우터로 되돌아 오는 것을 허용하였다. 이렇게 한 이유는 네트워크 문제가 발생됐을 때 그 원인을 파악하기 위해서 관리목적상으로 설정하였다. 내부 네트워크 사용자는 인터넷에 있는 다른 사용자가 내부 호스트에 Ping 테스트를 원하지는 않지만, 내부 네트워크 사용자가 인터넷에 보낸 Ping과 Traceroute에 대한 응답은 받아 들이길 원하기 때문에 설정이 필요하다.

- 또한, ICMP 트래픽을 허용하면 Ping에 대한 응답 패켓 이외에도 패켓의 TTL이 만료된 때가 언제인지, 그리고 인터넷의 어딘가에서 라우팅 또는 접근 문제가 있어서 접근이 불가 되었다는 정보도 얻을 수 있다.

- ‘show ip inspect config’, ‘show ip inspect interfaces’ Command를 이용하여 CBAC 관련 정보 확인이 가능하다.

4. PAM(Port to Application Mapping)

PAM(Port to Application Mapping)은 CBAC의 단점인 오직 표준 포트에서 동작하는 서비스만을 제어할 수 있는 문제를 해결하였다.

- 한 예로, HTTP 포트(80번)가 아닌 포트에서 동작하는 웹-서버로 가는 트래픽은 CBAC으로 검사하거나 보호하는 것이 불가능하다. 그러나 PAM을 사용하여 네트워크 서비스 및 어플리케이션이 사용하는 TCP/UDP 포트를 커스터마이징을 할 수 있다.

- PAM이 동작하는 첫 과정은 어플리케이션과 기본 포트를 연결하여 PAM 테이블을 생성한다. 이 테이블 안에는 CBAC이 지원하는 모든 서비스가 동일하게 포함되어 있다. 바로 이 부분이 CBAC과 PAM이 연결되는 부분이다.

- 즉, CBAC은 PAM에 있는 정보를 이용하여 비 표준 포트에서 동작하는 서비스를 지원할 수 있다. 만약, 비 표준 포트에서 어플리케이션을 운영하고 있다면, PAM과 CBAC을 함께 사용하여 그러한 어플리케이션이 사용하는 포트를 구분할 수 있다. 그렇기 때문에, CBAC은 PAM이 없다면 표준 포트와 그 어플리케이션만을 지원할 수 밖에 없을 것이다.

- 비 표준 포트를 사용하는 네트워크 서비스나 어플리케이션이 있다면 수동으로 PAM 테이블에 포트를 설정해야 한다. 그리고 특정 어플리케이션이 사용하는 포트 범위도 입력할 수 있다. 이렇게 하려면 포트 범위에 속한 각 포트를 PAM 테이블에 개별 항목으로 추가해야 한다.

- 라우터 설정을 저장하면 모든 수동으로 입력한 항목은 기본 매핑 정보와 함께 저장되며, 만약 비 표준 포트를 사용하는 어플리케이션을 갖고 있다면, 그 포트를 PAM 테이블에 수동으로 설정해야 한다.

다음은 PAM 설정에 대해서 알아보도록 하자.

- Router(config)# ip port-map [Application_Name] port [Port-Number]

- Router(config)# ip port-map [Application_Name] port [Port-Number] [ACL List]

PAM 구성에 대한 예제를 알아보도록 하자.

- Telnet 기본 포트 23번을 8000번으로 맵핑을 실시하여라.

- Router(config)# ip port-map telnet port 8000

- 호스트 192.168.1.1인 Telnet 기본 포트 23번을 8000번으로 맵핑을 실시하여라.

- Router(config)# access-list 13 permit host 192.168.1.1

- Router(config)# ip port-map telnet port 8000 list 13

1. Rad Hat 계열 Linux에 설치

Rad Hat이 설치된 컴퓨터에 ftp server를 설치하기 위한 절차를 기술함

# yum -y install proftpd : ftp daemon을 설치

2. Ubuntu Linux에 설치

Ubuntu가 설치된 컴퓨터에 ftp server를 설치하기 위한 절차를 기술함

# sudo apt-get install proftpd : ftp daemon을 설치

[참고]

● 명령어 앞의 sudo는 root 권한으로 실행하겠다는 의미임

● Ubuntu에서는 root 계정을 별도로 사용하지 않고 # sudo -s 하면 일정시간동안 root 권한으로 실행할 수 있음

● apt-get은 Internet을 통해 package 설치를 할 때 사용하는 명령임

configuration file은 /etc/proftpd/proftpd.conf이며 실행 file은 /etc/init.d/proftpd임

3. 환경설정

Fedora에서의 설정

# vi /usr/local/proftpd/etc/proftpd.conf 

웹서비스와 같이 실행 되도록 설정, FTP 서버의 성능과 안정성이 필요하다면 standalone으로 그냥 둠

Ubuntu에서의 설정

# sudo vim /etc/proftpd/proftpd.conf

[참고]

vim은 UNIX 계열에서 사용하는 editor vi의 improved program이며 vim 대신에 vi 또는 gedit 등을 사용하여도 무방함

##############

# Global 섹션   

##############

ServerName                  "ProFTPD Default Installation-WOW"

# 서버의 이름을 정해서 적어준다.

ServerType                   inetd

# inetd와 standalone 모드 중에서 선택

DefaultServer                 on

# 주 IP address 또는 <VirtualHost> 설정 블록에서 지정되어진 address 중의 하나가 아

# 닌 IP address로 들어오는 connection이 있을 때 기본으로 사용되어질 서버 설정 조절

Port                         21

# Proftpd가 사용할 기본 포트를 지정

# ADSL이나 케이블 같은 유동 IP 환경에서는 ISP 업체에서 21번 23번 25번 80번 포트 등

# 을 필터링 하기 때문에 ftp 기본 포트를 변경해야 외부에서 접속 가능

Umask                       022

# umask를 설정해주는 지시자

# 새로 생성되는 파일이나 디렉토리의 기본 permission을 결정

# umask 022는 644의 permission을 가진 파일과 755의 permission 가진 디렉토리 생성

MaxInstances                 30

# proftpd가 standalone 모드로 작동할 때 최대로 생성할 수 있는 자식 프로세스 정의

# DoS 공격에 대한 보호 목적이므로 적당한 값을 설정해서 사용

User                         nobody

# proftpd가 실행 될 때 User 지시자로 정의된 사용자명으로 실행

# 보안상 절대 root로 실행되게 해서는 안 됨

Group                       nobody

# User 지시자와 마찬가지이고 proftpd가 실행 될 때 Group 지시자로 정의된 Group 명

# 으로 실행

UseReverseDNS              off

# 접속자의 IP 주소를 Reverse Mapping을 하지 않겠다는 설정

# Reserver Mapping이란 IP 주소를 도메인으로 변경하는 것

IdentLookups                off

# 일반적으로, 클라이언트가 proftpd로 연결했을 때, ident protocol(RFC1413)은 remote

# username의 확인을 시도되기 위해 사용

# IdentLookups 지시자를 통해 조절

AuthPAMAuthoritative        on

# PAM이 인증에 있어서 최종 단계의 권한을 가지게 함

# 즉 PAM 인증이 실패할 경우 클라이언트와의 연결을 거부함

RootLogin                   off

# ftp로의 root 로그인을 허락 또는 거부하기 위한 지시자

<Directory /*>

          AllowOverwrite                on

# 모든 디렉토리 내의 파일에 대해 같은 이름의 파일을 전송할 때 overwrite를 허락 또는

# 거부하기 위한 지시자

</Directory>

#  아래부터는 anonymous접속에 대한 설정

##################

anonymous섹션

##################

<Anonymous ~ftp>

# anonymous 설정을 시작

# anonymous 설정은 </Anonymous>까지 임

          User                  ftp

          Group                 ftp

# anonymous접속의 경우 proftpd가 실행 할 때 사용자명 "ftp" 그룹명 "ftp"로 실행

          UserAlias              anonymous      ftp

# anonymous로 ftp에 접속한 사용자들에 대해 접속자명을 ftp로 alias해 줌

# 즉 anonymous로 접속한 사용자들은 사용자명 "ftp"의 권한을 가지게 됨

          MaxClients            10   "Sorry, maxium users %m -- try again later"

# 동시 접속자수를 정의하는 지시자

# 정의한 수를 초과할 때 " " 안의 문자열을 사용자에게 출력

          MaxClientsPerHost      2   "Sorry, Allow only one client for host"

# 하나의 호스트 당 최대 접속수를 정의하는 지시자

# 정의한 수를 초과 했을 때 " " 안의  문자열을 사용자에게 출력

          DisplayLogin           welcome.msg

# ftp로그인 때 보여 지는 메시지 파일 이름을 정의

          DisplayFirstChdir        .message

# 각 서브 디렉토리로 이동할 경우 보여줄 메시지 파일을 정의

          RequireValidShell       off

# /etc/shells에 없는 shell binary로그인 여부를 결정

# 특별한 이유가 없다면 off로 설정

          HideUser              root

# HideUser로 설정된 유저 소유의 파일은 보이지 않음

# Anonymous's Uploads Directory

# 업로드 디렉토리 이름을 변경하고 싶으면 아래의 uploads를 적당한 이름으로 변경

<Directory uploads/*>

        AllowOverwrite            on

# overwrite를 허용

        AllowRetrieveRestart        on

        AllowStoreRestart           on

       <Limit DELE RMD>

               DenyAll

# 디렉토리 삭제(RMD) 권한을 주지 않음

       </Limit>

       <Limit READ STOR MKD>

# 파일 읽기(READ), 업로드(STOR), 디렉토리 생성(MKD)에 대한 제어

# 읽기(READ)권한은 다운로드를 의미

# 와우 리눅스 7.0에는 MKD가 MDK로 잘못 설정되어 있음

       AllowAll

# 읽기(READ), 업로드(STOR), 디렉토리 생성(MKD)에 대해 모두 허락

# 하지만 특정 권한에 DENY 설정을 하지 않는 이상 AllowAll 설정을 하지 않아도 Dney # 설정된 권한을 제외한 나머지 권한을 가짐

       </Limit>

</Directory>

# Anonymous's Public Directory

<Directory pub/*>

      <Limit READ>

      AllowAll

# 읽기(READ)권한을 허락

      </Limit>

      <Limit  STOR  DELE  RMD   MKD>

      DenyAll

# 업로드(STOR), 파일 삭제(DELE), 디렉토리 삭제(RMD), 디렉토리 생성(MKD)을 허락

     </Limit>

</Directory>

</Anonymous>

● Order를 이용한 권한 제어

위에서 다루었던 proftpd.conf는 단순히 AllowAll 과 DenyAll만을 사용해 권한 제어를 했는데 Order 명령을 이용해서 접근제어와 권한 제어를 할 수 있음

특정 호스트만 로그인을 허용할 때

<Limit LOGIN>

Order       allow,deny

Allow       from 203.241.205.,.rootman.co.kr

Deny        from all

</Limit>

Order 명령에서 Allow 와 Deny는 공백 문자가 아닌 쉼표(,)로 구분함

Allow 와 Deny의 대상을 입력할 때도 대상들의 구분은 공백이 아닌 쉼표(,)로 구분함

위의 설정은 203.241.205의 네트워크 주소를 가지거나 rootman.co.kr을 포함해 하위 호스트들만 접근이 가능하고 그 이외의 호스트에 대해서는 Login을 받아들이지 않음

예)

203.241.205.97          ---> 로그인 가능(203.241.205의 네트워크 주소를 가진다)

203.241.202.16          ---> 로그인 불가(203.241.205의 네트워크 주소를 가지지 않는다)

linux.rootman.co.kr       ---> 접속 가능(rootman.co.kr의 하위 호스트이다)

microsoft.com          ---> 접속 불가(rootman.co.kr의 하위 호스트가 아니다)

order명령은 LOGIN외에 READ, MKD, DELE, RMD, STOR등에도 적용할 수 있습니다.

● ftp 루트( / ) 디렉토리 지정

DefaultRoot                  ~

사용자가 fpt로 접속해서 자신의 홈 디렉토리 외에 다른 곳에는 접근하지 못하게 함

~(물결표시)는 사용자의 홈 디렉토리를 가리킵니다. 즉 자신의 홈 디렉토리가 루트(/) 디렉토리가 됨

이 지시자를 설정 하지 않으면 기본적으로 DefaultRoot는 /로 설정되어 있기 때문에 사용자는 최상위 경로(/) 까지 접근 할 수 있음

예)

DefaultRoot           ~aaa,bbb,ccc

--> aaa, bbb, ccc 그룹에 속하는 ftp 접속 시 자신의 홈 디렉토리가 루트(/) 디렉토리가 됨

DefaultRoot           ~ !aaa

--> aaa 그룹에 속하는 사용자들을 제외한 나머지 접속자들은 자신의 홈 디렉토리가 루트 (/) 디렉토리가 됨

● 심볼릭 링크 파일 보여주기

ShowSymlinks            On  또는 Off

디렉토리에서 심볼릭 링크가 된 파일을 보여 주느냐, 보여 주지 않느냐에 대한 설정임

이 설정이 안 되어 있을 때에는 기본적으로 계정 사용자 접속의 경우에는 심볼릭 링크파일이 보이고 anonymous사용자 접속의 경우는 심볼릭 링크 파일을 보여주지 않음

전체 사용자에게 On 또는 Off를 설정하고 싶다면 Global 섹션에 포함 시키면 됨

● 숨김 파일 보여주기

LsDefaultOption   "-a"

이 설정을 함으로써 점( . ) 으로 시작하는 파일 또는 디렉토리명을 보여 줌. 즉 숨김 파일에 대한 설정임. 하지만 요즘 사용하는 ftp클라이언트에서도 이 기능을 제공함

● welcome.msg 파일에 사용할 수 있는 유용한 것들

호스트명 : %L

남은 용량 : %f

현재 접속자 수 : %N

최대 접속자 수 : %M

리모트 호스트 : %R

사용자명 : %U

관리자 메일 : %E

# vi /etc/xinetd.d/proftpd

### pro-ftpd ###

service ftp

{

disable = no

flags        = REUSE

protocol     = tcp

socket_type    = stream

instances     = 50

wait        = no

user        = root

server       = /usr/local/sbin/in.proftpd

log_on_success = HOST PID

log_on_failure  = HOST RECORD

}

(참고 : http://www.webtoedu.com/gachon_proftp2.php)

4. 실행

Ubuntu에서의 실행

# sudo /etc/init.d/xinetd restart (Ubuntu)

# service xinetd restart 또는 /etc/rc.d/init.d/xinetd restart (Rad Hat)

Fedora에서의 실행

# /etc/init.d/proftpd start

# /usr/local/proftpd/sbin/proftpd (compile을 통해 설치한 경우)

# ps -ef | grep proftpd (process 동작 확인)

nobody 23152 1 0 16:59 ? 00:00:00 [proftpd]

# netstat -an | grep LISTEN | grep 21 (21번 포트 확인)

tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN

1. Rad Hat 계열 Linux에 설치

Red Hat 계열의 Linux에서 telnet server 설치를 위해 우선 설치 여부를 확인한다.

# rpm -qa | grep telnet

telnet-server-xxx package (server)가 설치되어 있어야 함 (telnet-xxx는 telnet client임)

telnet server package가 없을 경우 다음 명령어를 수행함

# yum install telnet-server

또는http://ftp.sayclub.co.kr/pub/fedora/releases/10/Everything/i386/os/Packages/telnet-server-0.17-42.fc9.i386.rpm을 download 받은 후 다음 명령어를 수행함

# rpm -Uvh telnet-server-0.17-42.fc9.i386.rpm

2. Rad Hat에서의 환경설정

# vim /etc/xinetd.d/telnet

[참고]

vim은 UNIX 계열에서 사용하는 editor vi의 improved program이며 vim 대신에 vi 또는 gedit 등을 사용하여도 무방함

telnet 파일에 아래의 내용을 추가

service telnet

{

disable = no

flags = REUSE

socket_type = stream

wait = no

user = root

server = /usr/sbin/in.telnetd

log_on_failure += USERID

}

3. Rad Hat에서의 실행

xinetd service를 시작하기 위해 다음 명령을 입력한다.

[참고]

Red Hat Linux 6.2까지는 network connection을 처리하기 위하여 inetd를 사용하였으나 7.0부터는 inetd를 사용하지 않고 Xinetd를 사용한다.

전통적인 inetd는 port로 연결요청이 들어오면 이를 tcpd에게 보내고, tcpd는 host.allow와 host.deny에 포함되어 있는 rule에 따라 그 요청을 허락할 것인지의 여부를 결정한다. 요청이 허락되면 tcpd는 요청에 적합한 서버프로그램을 실행시킨다. 이러한 mechanism을 tcp-wrapper라고 하는데 Xinetd는 tcp_wrapper와 비슷한 접근 통제 방법을 제공한다.

# service xinetd start 또는 # /etc/rc.d/init.d/xinetd restart

xinetd service가 실행되고 있는지를 확인하기 위해 다음 명령을 입력한다.

# ps -ef | grep xinetd

root 3853 1 0 14:25 ? 00:00:00 xinetd -stayalive -pidfile /var/run/xinetd.pid

4. Ubuntu Linux에 설치

Ubuntu가 설치된 컴퓨터에 Telnet server를 설치하기 위한 절차를 기술함

# sudo apt-get install telnetd : telnet daemon을 설치

# sudo apt-get install xinetd : xinet daemon을 설치

[참고]

 명령어 앞의 sudo는 root 권한으로 실행하겠다는 의미임

 Ubuntu에서는 root 계정을 별도로 사용하지 않고 # sudo -s 하면 일정시간동안 root 권한으로 실행할 수 있음

 apt-get은 Internet을 통해 package 설치를 할 때 사용하는 명령임

5. Ubuntu에서의 환경설정

# sudo vim /etc/xinetd.conf

[참고]

vim은 UNIX 계열에서 사용하는 editor vi의 improved program이며 vim 대신에 vi 또는 gedit 등을 사용하여도 무방함

xinetd.conf 파일에 아래의 내용을 추가

service telnet

{

disable = no

flags = REUSE

socket_type = stream

wait = no

user = root

server = /usr/sbin/in.telnetd

log_on_failure += USERID

}

6. Ubuntu에서의 실행

# sudo /etc/init.d/xinetd restart

xinetd가 실행 중인지를 다음 명령으로 확인한다.

# ps -ax | grep xinetd

root 3853 1 0 14:25 ? 00:00:00 xinetd -stayalive -pidfile /var/run/xinetd.pid

7. 기타 사항

telnet 연결이 안 될 경우에는 setup - firewall (활성화 유무 확인) - telnet(활성화 유무 확인) iptables 여부 yes

telnet 접속 시 환영 메시지나 공지사항 등을 /etc/issue.net 파일을 사용하여 화면에 표시할 수 있다.

# vi /etc/issue.net

Welcome to the telnet server

현재의 tty는 %t 입니다.

시스템 노드 명은 %h 입니다.

NIS 도메인명은 %D 입니다.

현재 시간과 날짜는 %d 입니다.

운영체제 이름은 %s 입니다.

하드웨어의 유형은 %m 입니다.

운영체제 릴리즈는 %r 입니다.

운영체제 버전은 %v 입니다.

%t 현재의 tty 출력

%h 시스템 노드 명 출력

%D NIS 도메인명 출력

%d 현재 시간과 날짜 출력

%s 운영체제 이름 출력

%m 하드웨어 유형 출력

%r 운영체제 릴리즈 출력

%v 운영체제 버전 출력

7. 그 외 명령어

at  : 프로그램을 지금이 아닌 나중에 실행하도록 예약한다.

문법

at -q [-m][-f 파일명] 큐(queue) 시간

at -r 작업번호

at -l

옵션

-q 큐 : 대소문자 알파벳으로 큐를 지정한다. 순서적으로 빠른 알파벳이 지정된 큐 일수록 CPU 시간 점유 우선권이 낮다.

-r 작업번호 : 큐에서 작업 번호가 지시하는 작업을 지운다. 슈퍼유저가 아니라면 자신의 작업만을 지울 수 있다.

-l : 현재 계획된 작업들의 목록을 보여준다. 슈퍼 유저라면 모든 작업들의 계획목록을 보여준다.

-m : 작업이 완결되면 사용자에게 메일을 보낸다.

-f 파일명 : 표준 입력이 아닌 지시된 파일에서 작업을 읽어온다.

설명

명령은 기본적으로 표준 입력 장치를 통해서 받으며, ^D로 입력을 종료한다. redirection을 사용하여 다른 파일의 내용을 사용할 수 있다.

/etc/at.allow 파일이 있다면 이 파일에 명단이 있는 사용자만이 at 명령을 사용할 수  있다. /etc/at.allow 파일이 없다면 /etc/at.deny 파일을 찾는다. 이 파일에 목록이 있는 사용자는 at 명령을 사용할 수 없다. 두 파일 모두 찾지 못한다면 오로지 슈퍼 유저만이 at 명령을 사용할 수 있다. 그리고 /etc/at.deny 파일이 비어 있다면 모든 사용자가 at 명령을 사용할 수 있다.

시간을 지정할 때 상당히 다양한 방법을 사용할 수 있다. hhmm 혹은 hh:mm 형태도 가능하며, noon, midnight이나 오후 4시를 의미하는 teatime이라고도 할 수 있다. 오전 오후를 쉽게 구분하려면 am pm 문자를 추가해도 된다. 이미 지나간 시간이라면 다음 날 그 시간에 수행될 것이다. 정확한 날짜를 지정하려면 mmddyy 혹은 mm/dd/yy 아니면 dd.mm.yy 형태 중 선택하라.

현재부터 얼마의 시간이 경과한 후에 수행할지를 지정하려면 + 기호를 사용하라. 이 + 기호 뒤에 숫자를 명시하고, 다시 뒤에 그 숫자의 단위가 무엇인지 지정하면 된다.

사용 예

at 8am work : work에 수록된 작업 사항들을 오전 8시에 수행하도록 한다.

at noon work : 정오에 work에 수록된 작업을 수행한다.

at -f work 14:40 tomorrow : 내일 오후2시 40분에 work 파일에 수록된 작업을 수행한다.

1. Linux 컴퓨터에 router package 설치

Ubuntu가 설치된 컴퓨터에 router package를 설치하기 위해 터미널 창에서 다음 절차들을 수행한다.

1) 다음 파일의 내용을 변경하고 재부팅한다.

/etc/sysctl.conf 파일 내용 중 # net.ipv4.ip_forward = 1 내용에서 ‘#’ 부분을 제거, 저장 후 재부팅 (1은 yes, 0은 no를 의미하므로 #을 제거하면 IP forwarding을 수행하겠다는 의미임)

2) router package인 quagga를 설치한다.

# sudo apt-get install quagga

/etc/quagga directory 내에 zebra.conf와 ripd.conf 파일을 생성하여 아래와 같은 내용으로 만든다.

-- zebra.conf 파일 내용 --

  hostname Router

  password zebra    (암호는 임의로 정해도 무관함)

  enable password zebra  (암호는 임의로 정해도 무관함)

-- ripd.conf  파일 내용 --

  hostname ripd (암호는 임의로 정해도 무관함)

  password zebra (암호는 임의로 정해도 무관함)

3) deamons 파일의 내용을 변경한다.

zebra 부분과 ripd 부분을 yes로 수정

4) /etc/services 파일의 내용을 확인한다.

port 번호 2601 ~ 부분에 현재 zebra, ripd 등의 port가 별도로 분배되어 있음

2. quagga 및 rip의 실행

quagga를 실행/재실행/중지하는 명령은 다음과 같다.

# sudo /etc/init.d/quagga start | restart | stop 또는

# service zebra start

rip daemon을 실행하는 명령은 다음과 같다. (Fedora의 경우)

# service ripd start

3. quagga로의 접속 및 운용

quagga를 실행한 후 zebra로 telnet 접속을 시도한다.

# sudo telnet localhost 2601 또는

# telnet localhost zebra

Router> enable

Router# configure terminal

Router(config)# interface eth0     

Router(config-if)# ip address 192.168.1.1/24

Router(config-if)# exit

Router(config)# interface eth1     

Router(config-if)# ip address 192.168.3.1/24

Router(config-if)# end

Router# write memory

Configuration saved to /etc/quagga/zebra.conf

Router# show running-config

....

Router# quit

/etc/quagga/zebra.conf 파일 내용이 위에 설정한 내용과 유사한지를 확인한다.

192.168.1.1/24과 192.168.3.1/24은 실제 eth0 및 eth1의 IP 주소이므로 네트워크 장치에 가서 이에 맞도록 IP 주소를 변경하는 것이 필요하다.

4. rip daemon으로의 접속 및 운용

RIP daemon (ripd)로 telnet 접속을 시도한다.

# sudo telnet localhost 2602 또는

# telnet localhost ripd

ripd> enable

ripd# configure terminal

ripd(config)# router rip

ripd(config-router)# network 192.168.1.0/24

ripd(config-router)# network 192.168.3.0/24

ripd(config-router)# end

Router# write memory

Configuration saved to /etc/quagga/ripd.conf

Router# show running-config

....

Router# quit

/etc/quagga/ripd.conf 파일 내용이 위에 설정한 내용과 유사한지를 확인한다.

5. static route 설정

static route를 설정한 후 show ip route로 설정 상황을 확인한다. (C는 directly connected, S는 static route를 의미함)

Router> enable

Router# configure terminal

Router(config)#  ip route 192.168.1.100 255.255.255.0 eth0

Router(config)# ip route 192.168.3.100 255.255.255.0 eth1

Router(config)# end

Router# show ip route

C   192.168. ....

....

S   192.168. ....

....

Router# write memory

Configuration saved to /etc/quagga/zebra.conf

Router# show running-config

....

Router# quit

[참고사항] static route 설정 명령어

Router(config)# ip route network [mask] {address | interface} [distance] [permanent]

network : destination network

mask : destination network의 subnet mask

address : destination network에 도달하기 위한 next-hop address

interface : destination network에 도달하기 위한 next-hop router의 local interface

distance : route의 AD (Administrative Distance) value

permanent : 정의된 static route가 table에서 삭제되지 않도록 함

AD (Administrative Distance) value 변경 명령어

Router(config)# router rip

Router(config-router)# distance [1-255 distance]

router A에서 static route를 설정한 예는 다음과 같다.

Router(config)# ip route 150.150.0.0   255.255.0.0   203.210.100.1

150.150.0.0과 255.255.0.0은 destination network 주소 및 subnet mask

203.210.100.1은 1 hop을 건너뛴 IP address (즉, router B의 serial interface에 대한 IP address를 의미)

명령어 맨 뒤에 distance (라우팅 value, 작을수록 high)를 입력 가능 (default는 1)

[참고사항] rip 관련 timer 주기 설정 명령어

Router(config)# router rip

Router(config-router)# timers basic 5 30 30 40 1

숫자 순서대로 update, invalid, holddown, flush, sleep timer임

sleep timer는 최소 1ms임

default timer value는 다음과 같다.

(참고 : http://cafe.naver.com/hotsauce.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=96)

(참고 : http://blog.naver.com/loveleed?Redirect=Log&logNo=80099326253)

­ hello time (정기 알림 간격) 30초

­ invalid time (경로 만료 시간) 180초

­ holddown time은 invalid timer 종료 후 180초

­ flush time (경로 제거 시간)은 240초

­ sleep time (route poisoning 수신 시 긴급 update 시간)은 0초

1. at : 프로그램을 지금이 아닌 나중에 실행하도록 예약한다.

문법

at -q [-m][-f 파일명] 큐(queue) 시간

at -r 작업번호

at -l

옵션

-q 큐 : 대소문자 알파벳으로 큐를 지정한다. 순서적으로 빠른 알파벳이 지정된 큐 일수록 CPU 시간 점유 우선권이 낮다.

-r 작업번호 : 큐에서 작업 번호가 지시하는 작업을 지운다. 슈퍼유저가 아니라면 자신의 작업만을 지울 수 있다.

-l : 현재 계획된 작업들의 목록을 보여준다. 슈퍼 유저라면 모든 작업들의 계획목록을 보여준다.

-m : 작업이 완결되면 사용자에게 메일을 보낸다.

-f 파일명 : 표준 입력이 아닌 지시된 파일에서 작업을 읽어온다.

설명

명령은 기본적으로 표준 입력 장치를 통해서 받으며, ^D로 입력을 종료한다. redirection을 사용하여 다른 파일의 내용을 사용할 수 있다.

/etc/at.allow 파일이 있다면 이 파일에 명단이 있는 사용자만이 at 명령을 사용할 수 있다. /etc/at.allow 파일이 없다면 /etc/at.deny 파일을 찾는다. 이 파일에 목록이 있는 사용자는 at 명령을 사용할 수 없다. 두 파일 모두 찾지 못한다면 오로지 슈퍼 유저만이 at 명령을 사용할 수 있다. 그리고 /etc/at.deny 파일이 비어 있다면 모든 사용자가 at 명령을 사용할 수 있다.

시간을 지정할 때 상당히 다양한 방법을 사용할 수 있다. hhmm 혹은 hh:mm 형태도 가능하며, noon, midnight이나 오후 4시를 의미하는 teatime이라고도 할 수 있다. 오전 오후를 쉽게 구분하려면 am pm 문자를 추가해도 된다. 이미 지나간 시간이라면 다음 날 그 시간에 수행될 것이다. 정확한 날짜를 지정하려면 mmddyy 혹은 mm/dd/yy 아니면 dd.mm.yy 형태 중 선택하라.

현재부터 얼마의 시간이 경과한 후에 수행할지를 지정하려면 + 기호를 사용하라. 이 + 기호 뒤에 숫자를 명시하고, 다시 뒤에 그 숫자의 단위가 무엇인지 지정하면 된다.

사용 예

at 8am work : work에 수록된 작업 사항들을 오전 8시에 수행하도록 한다.

at noon work : 정오에 work에 수록된 작업을 수행한다.

at -f work 14:40 tomorrow : 내일 오후2시 40분에 work 파일에 수록된 작업을 수행한다.

2. banner : 인수로 주어진 문자열을 큰 글씨로 만들어서 출력한다.

문법

banner [ -w [숫자] ] 문자열 

옵션

-w : 옵션 지정만 하면 80 칼럼으로 폭을 바꾼다. 지정하지 않으면 132 칼럼으로 내정되어 있다. -w 옵션 뒤에 숫자를 지정하면 원하는 폭으로 조정할 수 있다.

설명

출력은 표준 출력으로 내정되어 있다. 글자는 열 배 정도 확대된다. 글자는 * (asterisk)를 조합하여 만든다.

사용 예

banner "hello world"

banner linux | lqr : default 프린터에 확대한 글자를 출력한다.

3. bash : 리눅스의 Bourne shell이다. sh를 사용하면 sh가 bash를 호출하여 실행한다. bash를 직접 사용하지 말고 sh를 사용한다.

문법

sh [ 옵션 ][ 파일 ]

설명

sh의 설명을 참조

4. biff : 전자우편의 수신을 즉시 알려주는 동작을 가능하게 할 것인지 그렇지 않은 지의 여부를 보여주거나 결정한다.

문법

biff [ y 혹은 n]

설명

UNIX shell은 사용 중이라도 주기적으로 전자우편의 수신 여부를 점검한다. 만일 사용자가 전자우편이 도착하는 즉시 알고자 한다면 biff를 사용하여 그것을 지시할 수 있다. 또는 언제라도 그 기능을 해제할 수도 있다. biff는 인수 없이 사용되면 현재 어떤 상태로 되어 있는지 보여준다. 기능 설정과 해제 여부는 y 혹은 n 인수를 주어서 결정한다.

사용 예

$ biff

is n : 전자우편 수신 즉시 통고 기능은 설정되어 있지 않음

$ biff y : 기능설정

$ biff

is y

5. cal : 서기 원년부터 9999년까지의 달력을 볼 수 있다.

문법

cal [-jy] [ [ 달 ] 연도 ]

옵션

-j : 1월 1일부터 날짜수를 계산하는 julian 날짜를 표시한다.

-y : 올해의 달력을 표시한다.

설명

인수를 하나만 준다면 그 숫자는 연도를 의미하는 것으로 간주된다. 두 개의 숫자를 준다면 앞의 것은 월, 그 다음은 연도를 의미하는 것이 된다. 우리의 습관과는 다른 방법을 사용한다. 아무 인수도 주어지지 않으면 이번 달의 달력을 표시한다. 연도를 표기할 때는 서기를 완전히 표기해야 한다. 예를 들어 97은 1997년이 아니라 서기 97년의 달력을 출력할 것이다.

사용 예

$ cal 1997

$ cal 4 1997

6. cat : cat은 catenate(사슬로 잇다. 연결하다)에서 이름이 유래한다. 이것은 파일의 내용을 화면에 출력하는 데 사용되기도 하며 파일을 다른 곳에 순차적인 스트림으로 보내기 위해 사용된다.

문법

cat [ -benstuvETA ] [ 파일명(들) ]

옵션

-b : 공백 외의 글자가 있는 모든 행의 개수를 센다.

-e : 제어 문자를 ^ 형태로 출력하면서, 각 행의 끝에 $를 추가한다. -vE와 같다.

-n : 각 행을 출력하면서 행 번호를 함께 첨부한다.

-s : 중복되고 겹치는 빈 행은 하나의 빈 행으로 처리한다.

-r : 행 바꿈 문자를 제외한 제어 문자를 ^ 형태로 출력한다. -vT와 같다.

-u : 유닉스 호환성을 위해 추가된 옵션으로서 무시된다.

-v : tab과 행 바꿈 문자를 제외한 제어 문자를 ^ 형태로 출력한다.

-E : 각 행마다 끝에 $ 문자를 출력한다.

-T : 시로서 탭(tab) 문자를 출력한다.

-A : -vET 옵션을 사용한 것과 같은 효과를 가진다.

설명

유닉스 시스템은 기본적으로 텍스트 자료들을 처리하는 것을 매우 중요시 여겼다. 많은 초기 설정 작업들이 텍스트 문서로 이루어지고, 텍스트 문서를 처리하는 수많은 명령들이 있다. cat 명령은 그러한 것들 중 기본적인 것이다. cat 명령은 읽어 들이는 파일 이름을 지정하지 않으면, 기본 내정 값으로 표준 입력 장치를 선정한다.

$ cat

이렇게 하면 키보드로부터 입력을 받고, ^d로 입력이 끝나면 다시 표준 출력 장치인 화면으로 출력한다.

사용 예

$ cat document.1 : document.1 파일을 화면으로 출력한다.

$ cat content report.first myreport : content와 report.first 두 개의 문서가 연결된 myreport라는 파일을 생성하게 된다.

7. cd : 현재 작업하는 directory를 변경한다.

문법

cd [ directory ]

설명

directory 이름과 cd 명령 사이에 반드시 공백이 있어야 한다. directory 이름을 주지 않고 수행하면 사용자의 홈 directory로 이동한다. 자신이 이동하고자 하는 directory는 자신에게 실행 권한(execution permission)이 있어야 한다.

사용 예

$ cd /home

$ pwd

/home

8. chgrp : 파일의 그룹 소유권을 바꾼다.

문법

chgrp [ -cfvR ] 그룹 파일들

옵션

-c : 실제로 소유자가 바뀐 파일에 대해서 자세히 기술한다.

-f : 파일의 그룹 소유권을 바꿀 수 없더라도 에러 메시지를 출력하지 않는다.

-v : 소유권의 바뀜에 대해서 자세히 기술한다.

-R : directory와 그 내용 파일들의 소유권을 재귀적으로 모두 바꾼다.

설명

파일의 소유자나 슈퍼 유저만이 파일의 그룹 소유권을 바꿀 수 있다. chgrp 명령 뒤에 원하는 옵션을 사용한 후 목적하는 그룹의 이름을 명시하고 대상 파일의 이름을 명시한다.

사용 예

$ chgrp DoublePlus /usr/project/* : /usr/project의 모든 파일들의 소유권을 DoublePlus 그룹으로 바꾼다.

9. chmod : 파일의 모드를 바꾼다. 파일의 모드는 권한(permission) 을 제어한다.

문법

chmod [ -cfvR ] 모드 파일명(들)

chmod [ -cfvR ] 레벨 동작 권한 파일이름(들)

옵션

-c : 실제로 파일의 권한이 바뀐 파일만 자세히 기술한다.

-f : 파일의 권한이 바뀔 수 없어도 에러 메시지를 출력하지 않는다.

-v : 변경된 권한에 대해서 자세히 기술한다.

-R : directory와 파일들의 권한을 재귀적으로 모두 바꾼다.

설명

위에서 보인 문법에서 첫 번째 보인 형식에 사용되는 모드는 파일의 권한을 8진수로 표현한 값이 된다. 파일의 권한은 세 가지가 있기 때문에 각 특성을 하나의 비트로 표현하면 0부터 7까지의 수로 표현할 수 있다. 이것은 8진법 표현이 매우 적당하다.

두 번째 형식은 어떤 사용자 레벨을 바꿀 것인가 어떻게 바꿀 것인가를 개별적으로 정하는 방법이다. 숫자를 사용하지 않고 ls 등을 사용할 때 실제로 볼 수 있는 기호 문자를 사용한다는 것과 특정 권한을 줄 것인가 뺄 것인가 지정할 수 있다는 장점이 있다. 특정한 경우 두 번째 형식이 편리하겠지만 고유한 값의 권한을 지정하는 데에는 첫 번째 형식이 훨씬 편리할 것이다. 8진법을 다루는 것은 조금만 알면 너무나 쉽기 때문이다.

사용 예

$ chmod 666 broadboard : 파일을 모두가 읽고 쓸 수 있도록 한다.

$ chmod 746 broad : 파일 권한을 -rwxr--rw-로 변경한다.

$ chmod o+x,g-w broadboard : 파일 소유자는 실행권한을 추가하고, 그룹은 쓰기 권한을 금지한다.

$ chmod u=r broad : 다른 사용자의 권한을 읽기로 제한한다. 사용자의 다른 권한은 사라져 버린다.

10. chown : 파일의 소유권을 다른 사람에게로 변경시킨다.

문법

chown [ -cfvR ] 사용자 파일명(들)

옵션

-c : 실제로 파일의 소유권이 바뀐 파일만 자세히 기술한다.

-f : 파일의 소유권이 바뀔 수 없어도 에러 메시지를 출력하지 않는다.

-v : 변경된 소유권에 대해서 자세히 기술한다.

-R : directory와 파일들의 소유권을 재귀적으로 모두 바꾼다.

설명

파일의 소유권을 다른 사람에게로 바꾸는 것은 슈퍼 유저만이 할 수 있다.

사용 예

$ chown blade /user/sisap/* : /usr/sisap directory의 모든 파일을 blade의 것으로 바꾼다.

11. cmp : file들의 내용을 비교한다.

문법

cmp [-ls][파일명][파일명2][오프셋1][오프셋2]

옵션

-l : 일치하지 않는 모든 바이트 값과 그 오프셋을 알 수 있다.

-s : 비교만을 수행할 뿐 아무런 메시지도 출력하지 않는다.

설명

option없이 두 파일 이름만을 지정하면 cmp는 두 개의 파일 처음부터 순서대로 비교를 시작한다. 만일 끝까지 차이점을 발견하지 못하면 cmp는 조용히 끝난다.

만일 중간에 다른 점을 발견한다면 더 이상의 작업은 중단하고 차이를 발견한 지점을 알려주고는 종료한다. 또한 계속해서 일치해 나가다가 두 파일 중 어느 하나가 끝나는 경우가 있을 수 있다. 다시 말해, 한 파일이 다른 파일의 앞부분에 해당하는 경우이다. 이때는 어느 쪽 파일의 end of file 표시를 만나게 되었는지를 알려주고 종료한다.

$ cmp document1 document2

document1 document2 differ: char 128, line 13

오프셋을 지정하면 파일의 어느 부분부터 비교할 것인지를 정할 수 있다. -s 옵션이 왜 필요한 지를 이해하지 못할 테지만, cmp 명령이 보이지 않게 리턴 값을 들려준다는 점을 알면 이해할 수 있을 것이다. cmp는 비교 후 두 파일이 일치한다고 판단하면 0을 리턴하며, 그렇지 않으면 1을 return한다. shell 스크립트 상에서 비교 결과만을 원하고 화면에 메시지가 출력되는 것을 원치 않을 때에는 이러한 옵션을 사용할 수 있을 것이다. C 언어를 아는 사람이라면 금방 이해할 수 있었으리라 생각된다.

사용 예

$ cmp mail.1 mail.2 13 14

12. compress : 파일을 압축하거나 압축을 푼다.

문법

compress [ -cCdfv ] 파일명

옵션

-c : 옵션을 사용하면 압축 결과가 표준 출력으로 나가며 파일은 변함없다.

-C : 파일을 블록으로 분화하는 것을 금지한다. 이것은 compress의 구식 버전이 파일을 읽을 수 있도록 하기 위함이다.

-f : 수행 결과 파일과 같은 이름의 파일이 있다면 물어보지 않고 덮어쓴다. 또한 파일의 크기가 줄어들지 않더라도 파일 이름에 .Z를 추가한다.

-v : 파일이 압축되면 압축 효율을 퍼센트로 보여준다.

설명

압축된 파일은 이름에 접미사 .Z가 추가된다. 압축 알고리즘에 의해 크기가 줄어드는 경우만 압축을 수행한다. -d 옵션은 역으로 압축을 풀지만 uncompress를 사용하면 옵션을 주지 않고 압축을 풀 수 있다. 압축을 푸는 경우 파일 이름 뒤에 접미사 .Z를 생략할 수도 있다.

사용 예

$ compress -v roman

$ compress -d noman.Z

$ compress -d roman

13. cp : 파일을 현재의 위치나 다른 directory로 복사(copy)한다.

문법

cp [ -abdfilPprsuvxR ] 파일명1 파일명2

cp [ -abdfilPprsuvxR ] 파일명(들) 디렉토리

옵션

-a : 가능한 한 원 파일의 구조와 속성을 그대로 복사한다.

-b : 복사할 때 덮어쓰게 되는 파일은 백업을 만든다.

-d : symbolic 링크는 symbolic 링크로 복사한다. 그리고 원본 파일과의 하드 링크 관계를 유지한다.

-f : 복사 위치에 존재하는 파일을 제거하고 복사한다.

-i : 복사 시 같은 이름의 파일이 존재한다면 덮어쓸 것인가 확인한다.

-I : 하드 링크를 만든다.

-P : 원본 파일의 소유자, 그룹, 권한, 시간 기록을 그대로 복사한다.

-r : 파일과 하위 directory에 포함된 파일 모두를 재귀적으로 복사한다.

-s : directory가 아닌 파일의 symbolic 링크를 만든다. 소스 파일의 이름은 전체 경로 이름으로 한다. 목적지 파일 이름은 전체 경로를 주지 않아도 현재 directory로 간주되므로 상관없다.

-u : 파일의 정보를 갱신한다.

-x : 다른 파일 시스템인 하위 directory는 무시한다.

-R : directory를 재귀적(recursive)으로 복사한다.

설명

만일 파일명2가 이미 존재하는 파일의 이름이라면 기존에 있던 파일은 사라지고 새로운 복사본 파일로 바뀐다. 이것이 원하지 않는 결과라면 -i 옵션을 주어서 확인 작업을 거칠 수 있다. -i 옵션은 파일명2가 이미 존재하는 이름이라면 그대로 복사할 것인지 아닌지를 선택할 수 있게 물어온다.

사용 예

$ cp -i blade.Z temp.Z

$ cp -r * /somewhere : 당연히 -r 옵션은 파일명2가 directory 이름일 때만 사용이 가능하다.

1. 패킷필터링이란? (역할과 목적)

패킷 필터링이란 지나가는 패킷의 Header를 살펴보고 그 전체 패킷의 운명을 결정하는 소프트웨어의 일부이다. 이것은 패킷을 ‘DROP(즉, 마치 전혀 전달되지도 않았던 것처럼 패킷을 거부)’하던가, ‘ACCEPT(즉, 패킷이 지나가도록 내버려둠)’를 하던가 또는 다른 더욱 복잡한 무엇을 할 것인가를 결정하는 것이다. 주요 사용 목적은 패킷의 제어와 보안이다. 패킷을 제어함으로써 자신이 원하는 것만을 외부 네트워크에 공개할 수 있고 또 자신이 허용하는 것만을 내부 네트워크 사용자에게 전해줄 수 있다. 이렇게 함으로써 허가되지 않은 정보가 외부로 누출되는 것을 막을 수 있으며, 외부에서 내부로 크래킹을 시도하는 것을 막을 수 있게 된다.

2. 사용하기 위해서 준비해야 할 것들

패킷 필터링을 하기 위해서 준배해야 할 것은 리눅스 커널(2.4.x)와 iptables이다. 다음의 사이트에서 소스를 얻을 수 있다.

리눅스 커널(linux kernel) ftp://ftp.kernel.org, ftp://ftp.kr.kerenl.org

iptables : http://www.netfilter.org, http://netfilter.samba.org

일단 소스를 확보하면 해야할 일은 2가지이다. 하나는 바로 커널 컴파일, 다른하나는 iptables 설치이다. 커널 컴파일과 관련된 사항은 Kernel Compile Guide를 참고하여 주기를 바란다. iptables의 설치와 관련된 상세한 설명은 소스 파일과 함께 제공되는 INSTALL 문서를 참고하길 바란다. 간략하게 요약하자면 다음과 같은 명령를 실행시킴으로써 iptables를 설치할 수 있다.

[root@ulug iptables-1.2.5]# make pending-patches

[root@ulug iptables-1.2.5]# make

[root@ulug iptables-1.2.5]# make install

'KERNEL_DIR'은 현재의 커널 소스가 있는 위치를 가리키는 것으로 일반적으로 커널은 '/usr/src/linux'란 디렉토리에 존재한다. Makefile에 default값으로 '/usr/src/linux'란 값이 주어져 있기 때문에 별도로 KERNEL_DIR을 설정해 줄 필요가 없다.

‘make pending-patches'는 커널에 미쳐 적용되어 있지 않은 최신 패치를 적용하는 것으로 커널별로 적용되는 범위가 다르며, 이미 패치된 커널일 경우에는 ’Already applied'라고 표시된다. 설치할 iptables보다 최근에 나온 커널이 아니라면 패치를 하는 것이 좋으며, 권장사항이다. ‘y'는 적용, ’t'는 적용이 정상적으로 되었는지를 테스트, ‘f'는 강제로 적용, ’q'는 종료를 뜻한다. ‘make'와 ’make install'은 소스를 컴파일하고 binary로 실행가능하게 생성된 파일을 해당 디렉토리에 설치한다. 기본 디렉토리는 /usr/local이며, Makefile을 수정하거나 make시 'BINDIR', 'LIBDIR', 'MANDIR'과 같이 환경변수를 설정해줌으로써 변경가능하다. 최근 Windows 서버를 공격하는 Nimda와 같은 악성 바이러스들이 극성이며, 이러한 바이러스는 Windows 서버에게만 피해를 입히는 것이 아니라 Linux 서버에도 불필요한 LOG 파일을 남김으로써 피해(?)를 주고 있다. 이러한 피해의 해결책으로 자주 거론되는 것이 바로 iptables의 확장 기능들 중에 하나인 string match filtering으로 이것은 일반적인 설치와 달리 별도의 패치를 적용시켜 주어야 한다. 시험적인 기능들을 패치하는 방법은 아래와 같으며, 'pending-patches'와 마찬가지로 적용시켜주면 된다. 이때 자신에게 필요한 패치만을 적용하는 것이 좋으며, 모두를 적용하는 것은 Netfilter측에서도 권하지 않고 있다.

[root@ulug iptables-1.2.5]# make patch-o-matic

3. 패킷필터링의 원리(구조)

iptables의 패킷 필터링의 원리는 이전 버전의 ipchains와는 약간 다른 구조를 가지고 있다. 모든 체인들이 소문자에서 대문자로 변경되었고, INPUT 체인의 경우 그 위치가 모든 체인들이 앞에서 존재하던 구조에서 routing이후로 구조를 변경하였다. 따라서 ipchains를 사용하던 사용자는 정책을 세울때 이러한 점을 고려해서 작성해야 할 것이다. NAT와 관련된 사항은 관련문서(리눅스 2.4 NAT HOWTO)를 참조하기 바라며, 여기서는 패킷 필터링에 대해서만 언급한다.iptables는 INPUT, OUTPUT, FORWARD라는 3개의 내장 체인을 가지고 있으며, 이 체인이라는 것은 규칙의 점검표이다. 각 규칙은 ‘패킷의 헤더를 비교하여 이렇게 되어있으면 이곳에서 무엇을 하라’라는 형태로 되어 있다. 각 규칙에 대해서 패킷을 비교하고 그에 해당하지 않는 패킷은 체인의 기본 정책을 따르게 된다. (일반적인 기본 체인의 정책은 ACCEPT이다.)

iptables에서 패킷이 순회하는 과정은 다음과 같다.

1. 패킷의 checksum을 점검한다.

2. 목적지가 자신이라면 ‘INPUT' 체인으로 이동하게 되고, 이 패킷을 기다리고 있는 프로세스에게 전달된다.

3. 만약 목적지가 자신의 것이 아니라면 2가지 행동을 하게 된다. FORWARD가 허용이 된다면 FORWARD 체인으로 이동하게 되고, 허용되어 있지 않다면 DROP을 하게 된다. 그리고 허용된 패킷의 경우 FORWARD 정책에 따라 그 운명이 결정된다.

4. 내부 프로세서에 의해서 바깥으로 나가는 패킷들은 OUTPUT 체인에 보내지며 규칙과 일치해야만 외부로 나갈 수 있다.

4. 일반적인 사용법

ㄱ. COMMANDS

-A(--append) : 지정된 체인의 끝에 하나 또는 그 이상의 규칙을 첨가

-D(--delete) : 규칙 내용과 일치하는 특정 체인에서 하나 또는 그 이상의 규칙을 삭제

-R(--replace) : 선택된 체인에서 규칙을 교체

-I(--insert) : 지정된 체인의 시작에 하나 또는 그 이상의 정책을 삽입

-L(--list) : 선택된 체인에서 모든 정책의 목록을 출력

-F(--flush) : 지정한 체인 내의 규칙들을 삭제

-Z(--zero) : 모든 체인의 byte와 packet 카운터를 0으로 초기화

-N(--new-chain) : 새로운 사용자 정의 체인을 만든다.

-X(--delete-chain) : 지정한 사용자 정의 체인을 삭제한다.

-P(--policy) : 지정된 체인의 정책을 세운다.

-E(--rename-chain) : 체인의 이름을 변경한다.

-h : 도움말을 출력 (아주 유용하다)

ㄴ. Rule specification parameters

-p [!]proto(col) protocol : 점검할 패킷 또는 정책에 대한 프로토콜 정의

ex) tcp, udp, icmp, all

-s(--source) [!] address[/mask] : 근원지 정의

-d(--destination) [!] address[/mask] : 목적지 정의

-j(--jump) target : 지정된 target으로 이동

-i(--in-interface) [!] name[+] : 패킷을 받는 인터페이스(eth0, ppp0)의 이름('+'는 와일드 카드)

-o(--out-interface) [!] name[+] : 패킷이 나가는 인터페이스의 이름 [!] -f(--fragment) : 두 번째 이후의 패킷에 대한 규칙을 설정

-c(--set-counters) PKTS BYTES : 규칙의 패킷과 byte를 초기화

ㄷ. OTHER OPTIONS

-v(--verbose) : 상세 정보를 출력

-n(--numeric) : 호스트 이름이나 포트 이름 대신 숫자로 출력

-x(--exact) : 패킷과 바이트 카운터의 값을 단위(K,M,G)로 보여주지 않고 전체 숫자로 출력

--line-numbers : 규칙을 출력시 각 정책의 시작 부분에 라인 넘버를 추가

--modeprobe=<command> : 체인에 규칙을 삽입할 때, 필요한 모듈을 올릴 수 있음

ㄹ. MATCH 확장

a. TCP : ‘--protocol tcp‘로 지정되면 적용된다.

--sport(--source-port) [!] [port[:port]] : 패킷이 들어 오는 tcp 포트 또는 포트 범위를 설정

--dport(--destination-port) [!] [port[:port]] : 패킷이 나가는 tcp 포트 또는 포트 범위를 설정

--tcp-flags [!] mask comp : mask에서 지정한 TCP flag가 있을 때 comp와 대응시킨다.

※참고 : 유효한 TCP flag : SYN,ASK,FIN,RST,URG,PSH,ALL,NONE

[!] --syn : --tcp-flags SYN,RST,ACK SYN의 약어

--tcp-option [!] number : TCP 옵션과 일치할 경우 패킷을 검사한다.

b. UDP

: '--protocol udp'로 지정되면 적용된다.

--sport(--source-port) [!] [port[:port]] : 근원지의 포트 또는 포트 범위를 지정

--dport(--destination-port) [!] [port[:port]] : 목적지의 포트 또는 포트 범위를 지정

c. ICMP

: ‘--protocol icmp'로 지정되면 적용된다.

--icmp-type [!] typename : 지정된 ICMP 형태를 허용한다.

d. mac

: 근원지 MAC 주소를 검사하며, PREROUTING, FORWARD 또는 INPUT체인에서만 유효하다.

--mac-source [!] address : 콜론(:)으로 구분된 16진수의 이더넷 주소를 지정

e. limit

: 적용 검사의 속도를 제한하는데 사용되며, 이 확장을 사용하는 규칙은 limit에 적용된 숫자만큼만 검사하게 된다.

--limit rate : 초당 평균 최대 적용 검사수(rate)를 지정하며, 시간 단위를 지정할 수 있다. (/second,/minute,/hour,/day, default : 3/hour)

--limit-burst number : 일치하는 패킷의 최대 수 (default는 5)

f. multiport

: 근원지와 목적지의 포트를 무더기로 설정할 수 있다. 최대 15개의 포트까지 설정 가능하며, tcp, udp 연결시에만 사용 가능하다.

--source-port [port[,port]] : 근원지 포트들을 설정

--destination-port [port[,port]] : 목적지 포트들을 설정

--port [port[,port]] : 근원지와 목적지 포트가 동일하게 설정하거나 한가지만 설정

g. owner

: 지역 프로세스에 의해서 발생한 패킷의 생성자(유저)의 다양한 특징들을 적용

--uid-owner userid : 지정된 사용자에 의해서 발생한 프로세스에서 생성된 패킷인지를 검사

--gid-owner groupid : 지정된 그룹에 의해서 발생한 프로세스에 의해서 생성된 패킷인지를 검사

--pid-owner processid : 지정한 프로세스에 의해서 발생한 프로세스에 의해서 생성된 패킷인지를 검사

--sid-owner sessionid : 지정한 세션 그룹에 의해서 발생한 프로세스에 의해서 생성된 패킷인지를 검사

h. state

: ‘ip_conntrack' 모듈의 접속 추적 분석(connection-tracking analysis)을 해석한다.

--state state : 설정 가능한 state 값은 NEW(새로운 접속을 만드는 패킷), ESTABLISHED(접속과 관련되어 있는 패킷),RELATED(FTP 송신과 ICMP와 같이 이미 성립한 접속과 연관되어 새로운 접속을 시작하는 패킷)가 존재한다.

ㅁ. TARGET 확장

a. LOG : 일치하는 패킷의 커널 로그를 제공

--log-level level : 레벨 숫자나 이름을 적음 (자세한 사항은 syslog(5)의 man 페이지를 참고)

--log-prefix prefix : 로그 시작 부분에 prefix의 내용을 첨가하게 된다. 29자까지 가능하다.

--log-tcp-sequence : TCP sequence 넘버를 로그에 기록한다. 만약 사용자들이 로그를 읽을 수 있을 경우 보안의 위협을 받게 된다.

--log-tcp-options : TCP 패킷 헤더의 option들을 로그에 남긴다.

--log-ip-options : IP 패킷 헤더의 option들을 로그에 남긴다.

b. REJECT : ‘DROP'과 동일한 작용을 하며, 상대편 호스트에 'port unreachable'이란 에러 메시지를 ICMP로 보내게 된다.

--reject-with type : 응답 패킷에 대한 변경을 할 수 있다. icmp-netunreachable, icmp-port-unreachable, icmp-

proto-unreachable, icmp-net-prpohibited 또는 icmp-host-prohibited, echo-reply, tcp-reset과 같은 값을 설정할 수 있다.

1. 패킷(Packet)

패킷이란 원래 우체국에서 취급하는 소포(packet)를 말하며, 화물을 적당한 크기로 분할해서 행선지 표시 꼬리표를 붙인 형태이다. 데이터 통신망에서 말하는 패킷이란, 데이터와 호 제어 신호가 포함된 2 진수, 즉 비트의 그룹을 말하는데, 특히 패킷교환 방식에서 데이터를 전송할 때에는 패킷이라는 기본 전송 단위로 데이터를 분해하여 전송한 후, 다시 원래의 데이터로 재조립하여 처리한다.

2. 네트워크의 구조(OSI 7 Layer)

현재의 네트워크 구조는 1970년대 말 IOS(International Oraganization for Standardization)에 의하여 OSI(Open System Interconnection) Layer로 만들어졌다. OSI Layer는 7개의 Layer로 구성되어 있으며, 정의 목적은 장비를 제조하는 업체와는 상관없이 네트워크 장비끼리 서로 표준적인 연결이 가능하도록하기 위한 틀을 제공하기 위한 것이다. 이렇게 범용적으로 받아들여질 수 있는 표준을 설정함으로써 개방형 시스템 환경에서 어떤 장비끼리라도 상호 정보리가 가능하도록 되었다.

각 Layer가 하는 역할

1. Physical: 인접 장치간의 비트 단위의 전기적 전송

2. Data Link : 인접장치간의 프레임 단위의 전송

3. Network : 하나 또는 2개 이상의 망을 통한 데이터 전송(네트워크 엑세스 계층, 망 연동 계층)

4. Transport : 종점 시스템(End -to-end)간의 데이터 전송 

5. Session : 응용 프로토콜간의 대화 제어

6.  Presentation: 두 사용자 시스템간의 데이터 표현 차이 해소

7.  Application : 파일, 메일 전송 등의 사용자 서비스 제공

ㄱ. Application Layer

: 사용자와 컴퓨터가 통신을 하는 곳으로, 통신하고자 하는 상대를 식별하고 그 상대와의 통신을 확보하는 역할을 한다. 또한 통신을 위한 충분한 자원을 보유하고 있는지를 판단한다.

<ex> FTP, E-mail, etc.

ㄴ. Presentation Layer

: 어플리케이션 계층으로 데이터를 제공하며, 코딩 및 변환 기능을 제공한다. 전송에 앞서서 데이터를 표준 포맷으로 교환함으로써 정확히 데이터를 전송하는 기술이다.

<ex> JPEG, MIDI, MPEG, etc.

ㄷ. Session Layer

: 데이터의 절단(tearing down)을 담당하며, 노드 사이의 다이얼 로그 제어를 제공한다. 이것은 통신을 하기 위한 세가지의 다른 방식(simplex,half-duplex 및 full-duplex)을 제공함으로써 시스템 사이의 통신을 조정한다. 일반적으로 서로 다른 어플리케이션의 데이터가 섞이지 않도록 한다.

<ex> NFS, SQL, RPC, etc.

ㅁ. Transport Layer

: 상위 레이어 어플리케이션에서 데이터를 분리하고 조합하여 다시 하나의 데이터스트림(datastream)으로 마무리 한다. 이러한 서비스는 인터네트워킹에서 end to end 간의 데이터 전송을 제공, 송신지의 호스트와 수신지 호스트 사이에 논리적 연결을 수행한다.

<ex> TCP, UDP

ㅂ. Network Layer

: 인터네트워크 내에서 라우팅과 네트워크 어드레싱을 담당한다. 라우터 혹은 다른 Layer-3 장비들은 네트워크 레이어에서 규정되어 있다. 기능으로는 경로설정(path determination), 스위칭(switching), 호 설정(callsetup)이다.

<ex> IP, ICMP

ㅅ. Data Link Layer

: 메시지가 적절한 수신 장비로 전달되는 것을 보증하며, 네트워크 레이어로부터의 메시지를 비트로 변환하여, 물리 레이어가 전송할 수 있도록 한다. 또한 메시지를 데이터 프레임의 포맷으로 만들고, 수신지와 발신지 하드웨어 어드레스를 포함하는 헤더를 추가한다.

o. Physical Layer

: 전송 비트와 수신 비트의 2부분으로 구분되며, 비트들은 수치값을 가진 모스 부호로서 0 또는 1로 표시된다. 물리적 레이어는 실제 통신 미디어의 다양한 형식과 직접 통신한다. 매체가 다르면 비트값 표현 방법이 다르므로 각 타입의 매체 각각에 사용해야 할 적절한 비트 패턴, 데이터를 매체의 신호로 부호화하는 방법, 여러 가지 물리적 매체의 접속 인터페이스의 품질 등을 정하는 전기적, 기계적, 절차적, 기능적 프로토콜을 규정한다.

3. TCP(Transmission Control Protocol)

TCP는 OSI 7계층 중에서 Transport 계층에 속하는 것으로서, point-to-point, connection-oriented, flow controll과 같은 역할을 수행한다. 아래의 그림은 TCP의 구조체이며, 일반적으로 10byte의 헤더를 가지고 있다. (필요에 따라서 별도의 옵션을 추가할 수 있다.) RFC(Requests for comments) 793, 1122, 1323, 2018, 2581에 정의되어 있다.

ㄱ. 발신지 포트(source port) : 데이터를 전송하는 호스트의 포트 번호

ㄴ. 수신지 포트(destination port) : 수신지 호스트 상에서 요청된 어플리케이션의 포트 번호

ㄷ. 시퀀스 번호(sequence number) : 데이터를 순서대로 다시 조립하거나, 누락 혹은 손상된 데이터를 재전송하는 순서배열 과정을 위한 번호

ㄹ. 확인 응답 번호(acknowledgement number) : 다음에 올 TCP 옥텍(octet)을 정의한다.

ㅁ. 헤더 길이(Header length) : 헤더의 길이를 나타내며, 이는 헤더의 32비트 워드의 수를 정의

ㅂ. 예비 필드(Not Used) : 항상 ‘0’으로 설정된다.

ㅅ. 코드 비트(Code bits) : 세션을 설정하고 종료하는 등의 제어 기능을 수행

※ URG : 긴급 포인터

ACK : 승인

PSH : 푸쉬 기능

RST : 접속의 리셋

SYN : 동기화 일련번호

FIN : 송신자로부터 더 이상의 데이터 없음

ㅇ. 수신자 윈도우(Receiver Window) : 송신자가 수용하는 윈도우의 크기(otet)

ㅈ. 체크섬(Checksum) : CRC로서, TCP는 하위 레이어를 신뢰하지 않고 모든것을 점검한다.

ㅊ. 긴급 포인터(Urgent pointer) : 긴급 데이터가 있다면 그 곳의 위치를 포인팅한다.

ㅋ. 데이터(Data) : 상위 레이어에서 전달되는 데이터

TCP를 통해서 데이터를 전송하기 위해서는 Handshake라는 연결 설정 과정을 거쳐야 하며, 이를 설정하는 과정은 다음과 같다. 우선 클라이언트측에서 접속을 요구하는 SYN 패킷을 임의의 sequence 넘버를 random하게 생성하여 서버측에게 보내게 된다. 서버는 서비스 데몬(Daemon)과 같은 어플리케이션이 대기(Listne)하고 있다가 클라이언트에서 보내온 SYN 패킷의 sequence 넘버에 1을 더한 ACK와 서버측에서 random하게 생성한 sequence 넘버의 SYN을 가지고 있는 패킷을 클라이언트에게 전송하게 된다. 마지막으로 클라이언트는 서버측에서 보내온 sequence 넘버에 1을 더한 ACK를 송신하게 되고 Connection이 설정된다. 데이터 전송간에는 ACK만을 서로 교환하게 되며, 접속을 종료시에는 클라이언트측에서 먼저 종료를 나타내는 FIN 패킷을 전송하게 되고 이를 받은 서버측은 ACK를 전송한다. 그리고 접속을 closing 하고 FIN을 클라이언트에게 전송한다. 클라이언트는 FIN을 수신후 ACK를 전송하게 되며 time 카운터를 시작한다.(서버측으로 전송한 ACK가 분실할 것을 대비하여 일정시간동안 기다린다. 만약 ACK가 분실된다면 서버는 다시 FIN을 발송하게 되며, 타이머 시간동안 기다리던 클라이언트는 다시 한번 ACK를 전송하게 된다.) 서버는 ACK를 받게 되면 접속은 완전히 종료(close)하게 된다. 아래의 그림은 클라이언트 측에서의 TCP상태 천이와 서버측에서의 상태 천이를 각각 표현한 것이다. 이러한 상태 천이는 'netstat -at'와 같은 명령으로 확인 가능하며, 일반적으로 LISTEN,ESTABLISHED, TIME_WAIT만을 볼 수 있다.

4. UDP(User Datagram Protocol)

UDP는 규모를줄인 경제적 모델으로서 TCP의 모든 기능을 제공하지는 않지만 신뢰성을 요하지 않는 정보 전송 작업에 많이 활용된다. 비연결형이기 때문에 지연이 적고, TCP와 같은 handshake 과정이 없기 때문에 간단하고 패킷 구조가 간단하다. DNS, SNMP와 같은 프로토콜이 UDP를 활용하고 있다. RFC 768에 정의되어 있다.

ㄱ. 발신지 포트(source port) : 데이터를 전송하는 호스트의 포트 넘버

ㄴ. 수신지 포트(destination port) : 수신지 호스트상에서 요청된 어플리케이션의 포트 번호

ㄷ. 세그먼트의 길이(length of segment) : UDP 데이터와 UDP 헤더의 길이

ㄹ. 체크섬(Checksum) : CRC로서 UDP 데이터 필드와 UDP 헤더의 체크섬

ㅁ. 데이터(Data) : 상위 레이어의 데이터

5. IP(Internet Porotocol)

Network Layer에 존재하는 프로토콜로서 TCP와 함께 현재의 인터넷 구조에서 가장 많은 활용도를 가지고 있다. 패킷의 구조는 아래와 같으며, 상위 레이어 (Transport Layer)의 데이터를 데이터그램으로 분해하여 수신측으로 전송한다. 데이터그램을 수신하는 각 라우터는 패킷의 IP 어드레스를 근간으로 라우팅을 결정한다. 관련 RFC는 791이며, 차세대 표준인 IPv6에 대해서 알고 싶다면 RFC 2373, RFC 2460을 참고하길 바란다.

ㄱ. 버전(Version) : IP의 버전 번호(현재는 IPv4이다.)

ㄴ. 헤더 길이(Header Length) : 헤더의 길이

ㄷ. 우선 순위(Type of service) : 데이터그램을 어떻게 처리해야 하는지를 결정하며, 처음 3비트는 우선 순위를 나타내는 비트이다.

ㄹ. 전체 길이(Total Length) : 헤더와 데이터를 포함한 패킷의 길이

ㅁ. 식별 번호(Identification) : 유일한 IP-packet 값

ㅂ. 플래그(Flags) : Fragmentation 발생 여부를 지정

ㅅ. 플래그 옵셋(Frag offset) : 패킷이 커서 한 프레임에 들어가지 못할 경우 Fragmentation 및 재결합에 대한 정보를 가지고 있다.

ㅇ. TTL(Time to Live) : 최초 패킷 생성시 설정되며, 설정된 시간 동안만 패킷이 살아 있다. 패킷이 인터넷을 무한정 떠도는 것을 방지한다.

ㅈ. 프로토콜(Protocol) : 상위 레이어 프로토콜의 포트 번호 (TCP : 6, UDP : 17)

ㅊ. 체크섬(Internet Checksum) : 헤더의 CRC

ㅋ. 발신지 IP 주소(Source IP address) : 발신지의 32비트 IP 주소

ㅍ. 수신지 IP 주소(Destination IP address) : 패킷을 보내려고 하는 수신자의 32비트 IP 주소

IP 주소는 32비트로의 정보로 구성되며, Dot(.)을 구분자로 이용해서 Octet으로구분된 4부분으로 나뉘어 진다. 이중 일부(high order bits)는 Network를 나타내고 다른 부분(low order bits)는 호스트(host)를 나타내며, 다음과 같이 4개의Class로 구분된다.현재의 IP 주소 구조는 낭비가 심하기 때문에 Subnet이란 구조를 통해서 하부 Network을 분류한다. Subnet이란 하나의 큰 네트워크를 작은 네트워크로 분리하는 데 사용하는 것을 말하며, local network에서만 적용된다. 모든 IP 주소는 Network과 Host를 구분하는 Mask를 가지고 있다.IP 주소를 분류하는 방법으로 CIDR(Classess InterDomain Routing)를 이용할수 있다. a.b.c.d/x와 같은 표현 방식으로 주소를 표현되며 x는 bit의 수를 나타낸다.

6. ICMP(Internet Control Message Protocol)

인터넷 제어 메시지 프로토콜로서 네트워크 레이어에서 작동하며 다른 많은 서비스를 제공하기 위해 IP를 사용한다. IP와 같은 Layer에 있으면서 데이터를 전송하기 위해서 IP에 포함되어 전송된다. 일반적으로 Error Reporting이나 ping에 사용된다.(관련 RFC 792) ICMP message는 type, code와 함께 에러를 발생시킨 IP 데이터그램(datagram)한 첫 8 bytes를 포함하고 있다.

7. Fragmentation

하나의 패킷이 너무 커서 하나의 Entity로서 전송되어질 수 없을때, 네트워크를 통해 보내어질 수 있는 두 개 이상의 더 작은 패킷조각으로 분리되어 진다. 이때 각 패킷 각각의 조각을 Fragment라고 하며 시스템 및 네트워크 장비에서 이러한 패킷을 조각내는 작업을 Fragmentation이라고 한다.

1. RIP의 개요

RIP은 IP Network에서 사용되었던 초기 버전의 Routing Protocol이였으며, IGP Routing Protocol 중에서 가장 덜 복잡한 알고리즘으로 동작한다.

RIP은 기본적으로 다음과 같은 특징을 제공한다.

• 이웃한 Router들과 Neighbor 관계를 설정하지 않는다. RIP은 Routing Process가 enable되는 해당 Interface상에 자신과 동일한 Routing Protocol을 수행하는 Router가 있는지를 확인 하지 않는다. 때문에 RIP이 Enable되어진 interface상에서 무조건 RIP Update 정보를 송/ 수신 한다.

• 30초마다 RIP이 Enable되어 있는 interface에서 Routing Update Traffic 전달 RIP은 Topology의 변화를 감지하기 위해 주기적으로 Routing 정보를 교환한다.

• Broadcast(v1), Multicast(v2), Unicast(v2)를 이용한 경로 정보 교환 RIPv1은 오직 Broadcast를 이용한 Update Traffic을 교환하며, RIPv2는 Broadcast,Unicast, Multicast 방식 모두를 사용자의 선택에 의해 지원된다.

• Topology 정보를 관리 하지 않는다. Topology 정보를 별도로 관리 하지 않기 때문에 이웃한 Router가 알려준 경로 정보를 무조건 신뢰한다.

• Hop Count를 Metric으로 사용하여 최적 경로 선택

• 기본 4개, 최대 6개의 Equal Cost Path 지원 IP Protocol이 지원하는 Load Balancing 경로의 최대값이 6이다. 따라서 Router는 특정 목적지에 도달 가능한 경로가 여러 개고, 이중 같은 Metric을 가진 경로들이 아무리 많다 해도 기본적으로는 4개, 사용자에 의해 최대 6개까지의 경로만을 Routing Table에 등록 할 수 있다.

• RIP v1(Classfull)과 RIP v2(Classless)가 있다.

2. RIP의 경로 학습

RIP은 특정 시간 주기(보통 30초)를 가지고 자신의 Routing Table에 등록된 최적의 경로 정보들을 RIP Enable되어진 Interface상에서 송/수신 한다.RIP의 경로 학습 동작의 특징은 아래와 같다.

• Router 자신과 경로 정보를 교환해야 하는 대상 Router의 존재를 인식하지 않는다.

• 특정 time interval을 두고 이웃한 Router와 주기적인 Routing Update 정보 교환

• RIPv1은 Broadcast만을 사용하고, RIP v2는 Unicast, Broadcast, Multicast 방식을 모두 사용 할 수 있다.

• Network이 커질수록 주기적으로 교환하는 경로 정보의 양이 증가 한다. 따라서 대규모의 Network에서는 Routing Update Traffic 교환으로 인해 Bandwidth에 부담을 줄 수 있다.

3. RIP 설정하기

RIP을 구성 하는 작업 단계는 다음과 같다.

1.router#config t

2.router(config)# router rip

3.router(config-router)#network x.x.x.x

4.router(config-router)# 기타 관련 Option들

4. RIP 설정하기

예) router rip

network 10.0.0.0

Router rip

=> RIP Routing Process를 enable 한다.IPv4 RIP Process는 Local Router에서 하나만이 수행될 수 있다.

Network 10.0.0.0

=> RIP Process가 enable되어질 Interface의 Network정보이다.RIP의 Network Command는 오직 Major Network 단위로만 선언된다.Network Command는 RIP Process가 동작해야 특정한 Interface를 선언 하는 것이지 RIP이 전파해야 하는 Network의 Prefix 형태를 정의하는 것은 아니다.

5. RIP의 구성 검증

‘show ip protocols’command는 Router에서 정의된 Roting Process들의 설정 상태를 확인 하기 위해 자주 사용되는 Command이다. 이 command를 이용하면 주로 다음과 같은 정보들을 확인 할 수 있다.

• Timer 값

• Routing Filter 적용 상태

• Version및 인증 옵션 정보

• Summary 동작 상태

• Routing Protocol이 Enable된 Network

• Next-hop 정보

• Distance 값

6. RIP Version의 Default 설정

RIP의 Default Version 설정 상태를 보여 주고 있다. Router에서 RIP을 설정하는 경우, 특별히 Version에 대한 Option을 설정하지 않았다면 위 그림과 같은 결과를 확인 할 수 있을 것이다. RIP은 기본적으로 RIP이 Enable되어진 Interface상에서 RIP Version1 Broadcast을 이용한 Update 정보를 송신하며, 수신은 Version1과 2 모두가 가능하게 되어 있다. 만약 상대방 Router-A가 Version2 Only로 설정되어 있고, Router-B는 이러한 사실을 모른다 하더라도 Routing 정보를 수신 하는 데는 큰 무리가 없는 것처럼 보일 것이다. 하지만 Router-A는 오직 Version2 만을 지원하기 때문에 Router-B가 전달 하는 경로 정보들을 Routing Table에서 표현하지 않을 것이다. 이런 상황처럼 상대방 Router의 RIP Version 정보를 모르는 경우라면 ‘debugip rip’ command를 실행하고 ‘clear ip route *’ command를 실행하여 상대방 Router가 전달하는 RIP Update 정보들에서 Version정보를 확인 할 수 있다.

7. RIP의 Unicast Update

Unicast Update는 RIP 경로 정보를 Unicast 방식으로 교환하기 위해 사용되며 Version2에서만 사용이 기능하다. 이를 위해서는 RIP 설정 시에 ‘neighbor’라는 option을 사용하며, neighbor command 다음에 설정되는 IP Address는 사전에 Routing Table에서 도달 가능한 경로로 등록 되어 있어야 한다. 만약 위 그림의 Router-A와 Router-B가 Serial(172.16.11.x/24) 구간에 직접 연결되어 있는 경우라면, 다음과 같이 추가적인 option을 설정해야 한다.

예) router rip

version 2

network 172.16.0.0

neighbor 172.16.11.2

passive-interface serial0

RIP Version2는 기본적으로 Multicast를 이용한 Update Traffic을 교환한다. 비록 Unicast Update를 위한 Neighbor Command가 선언되어 있더라도 172.16.0.0이라는 Major Network을 공유하는 Serial 구간에서도 Multicast를 이용한 Update Traffic이 여전이 발생된다. 따라서 ‘Passive-interface serial0’command를 설정하여 Serial 구간에서 전송하는 Multicast Traffic을억제하고, 오직 Unicast Update Traffic을 교환하게 한다. 참고로 ‘passive-interface’ command를 특정 interface에 적용하면, 해당 interface에서 broadcast와 multicast 전송을 허용하지 않고, 오직 수신만 가능하게 된다.

8. RIP의 Route Summary

첫 번째 예제를 보면 비연속적인 Major Network으로 연결된 구조에서는 Auto-Summary기능에 의해 정확한 경로 정보가 제공되지 않을 수 있음을 보여 주고 있다. 만약 Router-B가 목적지가 172.16.1.1로 향하는 packet들을 받았다면 일부 Traffic들은 엉뚱한 방향으로 전송되게 될 것이다.

예) ping 172.16.1.1

!.!.!. 또는 !U!U!

RIP은 Version 설정에 상관 없이 기본적으로 Auto Summary를 지원한다. 즉 Classful Routing 동작을 수행한다는 것이다. RIP Version 1은 오직 Classful Routing만을 제공하므로 Auto Summary기능을 조정 할 순 없지만, RIP Version 2에서 다음과 같은 설정으로 Auto-Summary 기능을 해지 할 수 있다.

예) router rip

no auto-summary

9. RIP Authentication (Plain Text)

RIP에서 인증된 Routing Update 정보를 교환하기 위한 설정이다. RIP Routing Update Traffic들은 Public Network에서 쉽게 노출되고, 해석하기 쉬운 형태이므로 , 별도의 인증 기법을 사용하여 Update 정보들을 보호 할 수 있다. 인증 설정 방법은 다음과 같다.

1.인증에 사용될 Key Chain을 설정하고 이름을 부여한다. Key Chain에는 필요에 따라 다수의 key를 정의 할 수 있다.

Key chain ccie

key 1

key-string 1234 암호화에 사용될 Key String을 정의 한다.

2.RIP을 실행하는 Interface에서 RIP 인증 option을 구성한다.

interface serial0

ip addr 192.168.1.1 255.255.255.0

ip rip authentication key-chain ccie => key chain을 선언한다.

10. Offset-list

Offset-list는 Distance Vector계열의 IGP Protocol에서 Metric의 조정을 위해 사용하는 Option이다. 위 그림의 예제 Topology를 보면 일반적인 상황에서의 Router-A는 150.100.1.0/24와 150.100.2.0/24 경로를 위한 최적의 경로로 Router-B를 통하는 64Kbps 경로를 선택 할 것이다. 왜냐하면 RIP은 bandwidth보다는 Hop이 적은 경로가 우선이기 때문이다. 만약 Router-A가 150.100.1.0을 위한 최적의 경로로 T1 link가 연결된 구간을 선택하고 싶어 한다면 어떻게 할 것인가? 이러한 요구를 해결하기 위해 Router-B는 Router-A가 150.100.1.0/24를 위한 최적의 경로를 T1 Link가 연결된 방향으로 선택 할 수 있도록 Router-B에서는 Router-A에게 전달하는 150.100.1.0 경로의 hop Count값을 ‘3’으로 변환하여 전달하고 있다.

11. RIP의 Split Horizon

RIP의 Split-Horizon의 설정은 Network Type에 따라 다른 설정을 가지고 있다. 따라서 위 그림에서 표현된 예제를 숙지하는 것이 좋을 것이다. Split Horizon은 일반적으로 Broadcast Network에서 Routing Update Traffic을 줄이기 위해 사용된다는 특징을 기억할 것이다. 따라서 다른 Device들과 매체를 공유하는 형식의 BMA Network Type에서는 Split-Horizon을 기본적으로 Enable하고, point-to-point와 같은 전용선 환경에서는 Routing Loop을 방지하기 위해서도 Split-Horizon을 enable한다. 하지만 NBMA와 같은 환경에서는 하나의 물리 interface에 다수의 논리적인 가상 회선이 연결되는 특징이 있으므로 가상회선의 연결 상황에 따라 Split-Horizon의 활성화 여부를 고려

해야 하는 경우도 있다.

Serial Interface에서 Split Horizon 설정 특징 (RIP, IGRP의 경우)

- Frame relay not enabled – split horizon(O)

- Frame relay enabled, no subinterface – split horizon(X)

- Frame relay enabled, subinterface – split horizon(O)

- EIGRP는 기본적으로 NBMA에서 Split horizon이 enable되어 있다.

Secondary IP Address가 설정되어 있고 split horizon이 설정된 경우 모든 Secondary Address들이 Routing 정보에 나타나지 않을 것이다. 이런 경우 split horizon을 Disable 한다. (IGRP, EIGRP의 경우) RIP과 EIGRP는 Split-Horizon의 설정 command가 다르게 되어 있으며, 특히 EIGRP 같은 경우에는 Split-Horizon의 설정 여부를 ‘show ip interface’ command로만 확신 할 수 없으므로, 반드시 ‘show running-config’ command를 실행하여 확인해야 한다.

12. Passive Interface

Router의 특정 interface를 대상으로 Passive-interface를 선언하면, 해당 interface상에서 broadcast와 Multicast 전송 기능을 disable하고, 오직 수신되는 broadcast와 multicast만을 허용하겠다는 의미이다.따라서 Broadcast나 Multicast를 이용하여 Routing Update 정보를 교환하는 RIP과 IGRP와 같은 Routing Protocol을 설정 할 때, 특정 interface에 passive-interface를 적용했다면, 해당 Interface에서는 Routing Update 정보를 보내지 않고, 오직 수신만 하겠다는 의미로 해석 할수 있는 것이다. 하지만 EIGRP나 OSPF와 같은 Routing Protocol 설정 시 passive-interface를 사용했다면 어떻게 될 것인가? OSPF나 EIGRP는 Routing Update 정보를 교환하기 전에 Hello packet을 multicast로 교환하여 neighbor 관계를 우선 설정한다. 때문에 OSPF나 EIGRP가 enable되어진 특정 interface에 passive-interface가 설정되었다면, multicast방식의 hello packet은 전송되지 않을 것이며, neighbor관계도 설정되지 않으므로 결론적으로는 passive-interface가 설정된 구간에서는 아무런 Update정보도 교환되지 않는다. Passive-interface는 다음과 같은 형태로 설정 될 수 있다.

1.특정 interface를 대상으로 설정하는 경우;

Router rip

network 10.0.0.0

passive-interface ethernet0

2.기본적으로 모든 Interface에 passive-interface 설정을 구성 후 특정interface만 해제 하는 경우

Router rip

network 10.0.0.0

passive-interface default

no passive-interface ethernet1

1. Queuing Mechanism

큐는 마치 버스를 타기 위해 줄을 서는 모습과 비슷하다. 줄을 서면 보통 맨 앞에 있는 사람부터 차례대로 버스에 탑승을 한다. 이런 원리가 바로 큐의 가장 기본적인 FIFO(First-in First-Out) 큐잉이다.

- 네트워크에서 큐잉은 어떤 네트워크 장비가 서비스할 수 있는 것 이상을 패켓이 도착하거나, 동시에 동일한 목적지로 향하는 패켓들이 존재할 때 발생된다. 즉, 한꺼번에 처리할 수 없는 패켓들을 잠시 동안 버퍼에 저장해 놨다가 나중에 서비스를 하는 것이 큐잉이다. 이때 사용되는 버퍼의 종류는 소프트웨어 큐와 하드웨어 큐 2가지로 구분된다.

- 라우터로 들어오는 트래픽은 라우팅 프로세서에 의해 라우팅 경로가 결정되며, 결정된 출력 인터페이스를 통해 서비스가 된다. 이때 라우터의 인터페이스에서 연속 지연 시간 동안 패켓을 저장해야 하는 상황이 생기며, 이를 처리하기 위해 각 인터페이스마다 일정량의 하드웨어 큐를 사용한다. 이때, 인터페이스에 할당되는 하드웨어 큐는 보통 ‘TX Queue’와 ‘TX Ring’이라고 말한다. 이 하드웨어 큐의 크기는 라우터의 성능에 따라서 다르다.

하드웨어 큐인 ‘TX Queue’는 다음과 같은 특징을 가지고 있다.

- FIFO 스케줄링만 지원하며 변경이 안되며, 인터페이스별로 1개만 사용 가능하다.

- 다른 큐잉 스케쥴링을 사용하면 IOS는 ‘TX Queue’의 길이를 자동으로 축소한다.

- 관리자가 임의의 설정을 통해 ‘TX Queue’의 길이를 조절할 수 있다.

- ‘Best-Effort’ 서비스만 하는 단점을 가지고 있으며, 차후 이 문제를 소프트웨어 큐로 해결이 가능하다.

2. FIFO Queuing

FIFO 큐잉은 단일 FIFO 큐를 사용하는 것을 말한다. 가장 기본적인 큐잉의 구조로 TX Queue 앞에 있는 하드웨어 큐라고 생각하면 된다. 일반적으로 FIFO 큐잉은 하나의 큐만 제공되기 때문에 하나의 큐에에 모든 클래스의 트래픽을 저장한다.

- FIFO 큐잉에 사용되는 스케줄링 방식은 ‘머리가 먼저 들어온 사람부터 먼저 내보낸다.’라고 표현할 수 있다. 즉, 패켓의 클래스나 우선순위에 상관 없이 먼저 입력된 패켓을 먼저 서비스를 한다. ‘Best-Effort’ 서비스 모델만을 갖고 있는 전통적인 인터넷에서 사용되는 큐잉과 스케줄링 구조에 포함된다.

- 트래픽의 구분이 존재 하지 않기 때문에, FIFO 큐잉을 사용하는 장비에서는 분류, 마킹 작업을 할 필요가 없다.

- 구현이 간단하며 FIFO 큐의 동작이 예측이 가능하다. 즉, 패켓들의 순서가 유지되며, 패켓의 최대 지연은 큐의 최대 크기에 의해 결정된다. FIFO 큐잉의 단점으로는 클래스의 구분이 없기 때문에 차별화된 서비스를 제공하는 것이 불가능하다.

- 또한, Tail-Drop이 발생하기 때문에 버스트 트래픽 서비스에 부적합 하며, 혼잡이 발생하는 경우 TCP보다 UDP 트래픽에 유리하다.(TCP 재전송 문제)

- 즉, TCP와 UDP 트래픽이 존재하는 경우 혼잡이 발생하면, TCP Sender는 흐름 제어 알고리즘에 의해 전송 속도를 줄이게 되지만, UDP Sender는 계속해서 트래픽을 보내게 되며 TCP의 흐름 제어에 의해 발생한 대역폭을 차지하게 된다. 결국 TCP 트래픽의 서비스는 힘들게 된다.

3. Priority Queuing

Priority Queuing(우선순위 큐잉)은 FIFO 큐잉의 단점인 클래스의 구분 없이 차등화된 서비스 실시하는 문제를 해결하였다. 우선선위 큐는 기존의 FIFO 큐잉이 단일 FIFO 큐를 사용하는 것에 비해 ‘High’, ‘Medium’, ‘Normal’, ‘Low’라는 4가지 FIFO 큐를 사용한다. 4개의 FIFO 큐를 사용하므로, 각각의 큐가 서로 다른 트래픽 클래스에 매핑된다.

- ‘High’, ‘Medium’, ‘Normal’, ‘Low’ 4 가지 Class가 존재한다.

- 우선순위 큐잉을 사용하는 경우 스케줄링의 방식은 오로지 ‘High’ class가 최우선적으로 서비스가 실시된다.

- 즉, 낮은 우선순위 큐에 저장돼 있는 패켓들은 높은 우선순위 큐에 저장돼 있는 패켓들이 모두 서비스 된 이후에 서비스가 실시된다.

- 만약, 낮은 우선순위 큐에 저장돼 있는 패켓이 서비스 되는 도중이라도 높은 우선순위 큐에 패켓이 입력되면, 낮은 우선순위 큐는 서비스를 잠시 멈추고, 높은 우선순위 큐에 새로 도착한 패켓을 먼저 서비스를 실시한다.

- 우선순위 큐잉 방식의 장점은 간단한 방법으로 차등화된 서비스를 제공할 수 있다. 그렇기 때문에, 실시간 어플리케이션 지원이 가능하다. 그러나 높은 우선순위 큐에 패켓이 계속해서 입력될 때에는, 낮은 우선순위 큐에 저장된 패켓이 서비스가 되지 못하는 현상이 발생된다. 이런 현상을 아사 현상이라고 한다.

- 또한, 동일한 우선순위의 패켓들만 많이 들어오는 경우에는 FIFO 큐처럼 동작이 되는 문제점도 발생될 수 있다.

4. Priority Queuing : ‘Priority-list’ Command

Priority Queuing 설정 방법은 다음과 같다.

- 프로토콜, 인터페이스, ACL 별로 ‘Priority-list’ 설정 (list-number 1 ~ 16)

- Default Queue 설정  우선순위 큐잉에 포함되지 않는 트래픽에 대해서 처리를 해야한다.

- 각각의 Queue 크기를 지정  ‘High’, ‘Medium’, ‘Normal’, ‘Low’ 은 기본적으로 20, 40, 60, 80 이다.

- 해당 인터페이스에 우선순위 큐잉 적용

Ex) Priority Queuing 설정

Router(config)# priority-list 1 protocol ip high tcp 23

Router(config)# priority-list 1 protocol appletalk medium

Router(config)# priority-list 1 protocol ipx medium

Router(config)# priority-list 1 protocol list 113 normal

Router(config)# priority-list 1 protocol ip normal

Router(config)# priority-list 1 default low

Router(config)# priority-list 1 queue-limit 20 40 60 80 ->default값 변경하지 않는 것을 권장:Queue Size

Router(config)# interface serial 0/0

Router(config-if)# priority-group 1

Router(config-if)# end

Router# show interface serial 0/0

Router# show queueing priority

5. Custom Queuing

Custom Queuing 또는 Fair Queuing은 Priority Queuing에서 낮은 우선순위 클래스의 패켓들이 우선순위가 높은 트래픽 때문에 발생되는 아사 현상을 해결하였다.

- Custom Queuing은 최대 16개의 FIFO 큐를 사용한다. 관리자가 각 큐에 대해서 클래스를 구분하여 각각의 클래스마다 각각의 큐를 지정해 사용이 가능하다. Priority Queuing에서 클래스를 4개로 나누어서 분리하는 것보다 더 세분화하여 분리하여 골고루 큐를 할당할 수 있는 장점을 가지고 있다.

- 이렇게 세분화된 트래픽은 각각의 해당 큐로 보내져 ‘Round Robin’ 스케줄러에 의해 하드웨어 큐인 ‘TX Queue’로 서비스 된다. 즉, 모든 큐의 패켓이 공평하게 서비스가 실시된다.

- Priority Queuing에서는 높은 우선순위 큐가 패켓을 갖고 있는 한, 낮은 우선순위 큐에 있는 패켓들은 아사 현상이 발생된다. 그러나 Custom Queuing은 모든 큐가 동일한 우선순위를 갖기 때문에 아사 현상을 발생시키지는 않지만, 트래픽의 특성을 고려하지 않고 서비스 차원에서의 공정성만 따지기 때문에 스케쥴링 부분에서 차별화된 서비스를 제공하기 힘들다.

- 이렇기 때문에 관리자의 잘못된 설정으로 인해 대역폭의 비효율적인 할당 및 지연시간 증가라는 문제가 발생된다.

6. Custom Queuing : ‘Queue-list’ Command

Custom Queuing 설정 방법은 다음과 같다.

- 프로토콜, 인터페이스, ACL 별로 ‘Queue-list’ 설정 (list 1~16 , queue 1~16)

- Default Queue 설정  우선순위 큐잉에 포함되지 않는 트래픽에 대해서 처리

- 각각의 Queue가 Bandwidth의 몇 퍼센트를 사용할 것인지를 설정

- 해당 인터페이스에 우선순위 큐잉 적용

Ex) Custom Queuing 설정

router(config)#queue-list <list-#> protocol <protocol-name> <queue-#>

Router(config)# queue-list 1 protocol ip 1 tcp 23

Router(config)# queue-list 1 protocol ip 2

Router(config)# queue-list 1 protocol ipx 3

Router(config)# queue-list 1 default 4

Router(config)# queue-list queue 3 byte-count 3000  (기본 Byte-Count 1500). IPX를 2배이상 대역폭을 할당 설정

Router(config)# interface serial 0/0

Router(config-if)# custom-queue-list 1

위의 예제는 telnet bandwidth 20%, IP bandwidth 20%, IPX bandwidth 40%, 나머지 트래픽 bandwidth 20% 일 때 Custom Queuing 설정이다. 이때, 각각의 차지하는 비율이 ‘20 : 20 : 40 : 20 = 100’ 이기 때문에, ‘1:1:2:1 = 5’가 된다. 즉, IPX는 다른 Bandwidth 보다 2배이기 때문에 기본 Byte-Count 1500에 2배인 3000을 설정을 한 것이다.

7. WFQ(Weight Fair Queuing)

WFQ는 Priority Queuing과 Custom Queuing을 결합 형태를 갖고 있는 큐잉이다. 즉, WFQ 큐잉은 Priority Queuing의 단점인 우선순위가 낮은 클래스의 패켓들이 우선순위가 높은 트래픽에 의해 아사 현상 문제를 해결하고, Custom Queuing 큐잉의 단점인 차별화된 서비스 불가라는 문제를 해결하였다.

- WFQ는 ‘꼬리가 먼저 들어온 사람부터 먼저 내보낸다.’라고 표현할 수 있다.

- WFQ는 최대 4096개의 큐를 사용한다. 상당히 많은 큐를 제공하기 때문에 클래스를 플로우 단위로 나누어서 사용된다. 각각의 큐는 IP Precedence를 기준으로 가중치를 받게 된다.

- 즉, IP Precedence의 값과 반비례로 동작한다. 실제 패켓의 크기와 수식으로 계산을 하여 나온 가상 패켓의 크기를 기준으로 서비스되도록 스케줄링을 실시한다. 이와 같은 수식을 적용하는 이유는 우선순위가 높거나 크기가 작은 패켓들에 대해서 우선적으로 서비스를 하기 위해서이다.

- 한 예제로, FTP와 Telnet을 들 수 있다. 동시에 FTP와 Telnet 트래픽이 출력될 때 WFQ 큐잉은 Telnet 트래픽부터 서비스를 실시한다.

8. WFQ Queuing : ‘fair-queue’ Command

WFQ Queuing 설정 방법은 다음과 같다.

- 기본적으로 Cisco 라우터 Serial 인터페이스는 WFQ로 동작을 실시한다.

- 해당 인터페이스에서 ‘fair-queue’ Command를 사용한다.

- <1-4096> Conversation Discard Queues : 패켓을 Discard하기 위한 임계치

- <16-4096> Number Dynamic Conversation Queues : 최대 4096개의 플로우 기반 큐를 제공

- <0-1000> Number Reservable Conversation Queues : 예약할 수 있는 최대 큐

9. CBWFQ(Class-Base Weight Fair Queuing)

CBWFQ(Class-Base Weight Fair Queuing)이란 WFQ와 Custom Queuing을 결합한 형태를 갖춘 큐잉 방법이다.

- CBWFQ는 Custom Queuing의 장점인 각각의 큐마다 최저 대역폭을 바이트 단위로 할당하는 기능을 발전시켜서 전체 대역폭의 %로도 최저 대역폭을 보장할 수 있게 한다.

- 그러나, 기존의 WFQ가 플로우 기반으로 구현돼 큐가 많이 필요했던 것에 비해서 CBWFQ는 클래스를 기준으로 큐를 구분하기 때문에 64개로도 설정이 가능하다.

- 드롭 정책에도 WFQ는 ‘Tail-Drop’만 사용하지 못한 것에 비해 CBWFQ는 ‘Tail-Drop’과 같이 ‘WRED’를 사용하여 ‘Global Synchronization’ 문제를 해결한다.

- CBWFQ 설정은 MQC 방식의 3 단계를 과정을 갖는다.

10. CBWFQ Queuing : Example

CBWFQ 설정은 MQC 방식을 이용하여 다음 같이 진행된다.

- ‘class-map’ 구문을 가지고 클래스를 정의

- ‘policy-map’ 구문을 가지고 정책을 실시

- ‘policy-map’ 정책에서 ‘bandwidth’ Command 사용

- ‘policy-map’ 정책에서 ‘fair-queue’ Command를 이용하여 나머지 트래픽은 WFQ 적용 실시

- 해당 인터페이스에 ‘service-policy’ Command를 이용하여 적용 실시

- 정보 확인 : ‘show class-map’, ‘show policy-map’, ‘show policy-map interface s 0/0/