TCP-Wrapper

System/Linux 2011. 10. 31. 17:42



TCP-Wrapper

공재순 / CERTCC-KR kong@certcc.or.kr

1. 소개

TCP-Wrapper는 네트워크 서비스에 관련한 트래픽을 제어하고 모니터링 할 수 있는 UNIX 기반의 방화벽 툴이다. 임의의 호스트가 서비스를 요청해 오면 실제 데몬을 구동하기 전에 접속을 허용한 시스템인지 여부를 확인하여 호스트명 및 서비스명을 로그에 남긴다음, 허가된 시스템은 서비스를 제공하고 허가되지 않은 경우에는 접속을 차단해 준다.

기존의 설정파일이나 소스코드에 별다른 수정이 필요치 않고, 정상적인 사용자들에게는 불편을 주지 않으면서도 허가되지 않은 접근의 제한 및 탐지가 가능하기 때문에 많은 서버 관리자들이 이 툴을 사용하고 있다.

2. inetd와 TCP-Wrapper

[그림1]에서 보는 바와 같이 UNIX 기반에서 서버프로그램인 데몬들은 standalone 모드나 inetd 모드로 구동된다.standalone 모드는 시스템 부팅과 동시에 바로 실행되어 프로세스가 항상 떠 있어야 하는 데몬들로 자체제어 메커니즘을 가지고 있다. 그에 비해, inetd모드에서는 client의 요청이 있을때만 inetd데몬에 의해서 해당 서비스데몬을 구동시키는데, inetd데몬이 client로부터 들어오는 요청에 대해 /etc/inetd.conf 파일의 구성설정과 /etc/services 파일의 정의된 포트를 이용하여 서비스를 구분하고 해당 서비스의 서버데몬을 구동시켜준다.

TCP-Wrapper 프로그램은 허락되지 않은 접속으로부터 inetd 모드로 구동되는 데몬들을 보호하는 역할을 한다고 볼 수 있다. [표1]은 inetd 모드에서 실행되는 대표적인 프로그램들의 client-server모델이다.

[표1] Examples of TCP/IP Client-Server Program

Client Server Application
telnet telnetd Remote login
ftp ftpd File transfer
finger fingerd Show users
... ... .....

위와 같은 각종 네트워크 서비스의 실제 서버들을 보호하기 위해서 단순하지만 강력한 메커니즘을 제공하는데 그것은 ined데몬이 client로부터 요청되어진 서버프로그램을 대신해 TCP-Wrapper를 구동시키는 트릭이다.

네트워크 서비스 요청이 들어오면, client host의 address,이름, 요청한 서비스 등 수행에 필요한 몇가지 정보를 확인하여 이를 syslog 파일에 저장한 다음 실제데몬을 구동시켜주거나 접근을 차단하게 되는데, 정상적인 사용자들은 실제 Telnet 서버가 구동될때와의 차이를 느끼지 못한다.

<service_name>
<sock_type>
<protocol>
<wait/nowait>
<user>
<server_program>
<server_program_arguments>
[사용하지않는경우]
ftp
stream
tcp
nowait
root
/usr/sbin/in.ftpd
in.ftpd
telnet
stream
tcp
nowait
root
/usr/sbin/in.telnetd
in.telnetd
[사용하는경우]
ftp
stream
tcp
nowait
root
/usr/sbin/tcpd
in.ftpd -l -a
telnet
stream
tcp
nowait
root
/usr/sbin/tcpd
in.telnetd

3. 설치

LINUX 시스템의 경우 Linux 6.x 버전에는 대게 TCP_Wrapper가 설치되어 있기 때문에 설치 과정 없이 /etc/hosts.deny 와 /etc/hosts.allow 파일에 접근 리스트를 설정 해 주고 inetd 데몬을 재구동 시켜주면 된다. " 4.설정 " 으로 넘어가면 된다.

설치여부나 설치된 버전을 확인하고자 경우에는 다음 명령을 이용한다.

rpm -qa | grep wrappers

[Redhat7.0 부터는 TCP_Wrapper와 유사하나 보다 강화된 Xinet가 기본적으로 설치된다.]

UNIX 시스템의 경우에는 TCP-Wrappers 프로그램을 구해서 설치해 주어야 한다. 다음과 같은 설치 과정을 거친 다음

[ ① 프로그램파일 다운로드 -> ② 압축해제 -> ③ 시스템타입 확인 및 Makefile수정 -> ④ 컴파일 -> ⑤ 실행파일 및 맨페이지 이동 -> ⑥ inetd.conf 파일 수정 -> ⑦ hosts.deny, hosts.allow 파일 생성 ]

Linux에서와 동일하게 /etc/hosts.deny 와 /etc/hosts.allow 제어파일에 접근 리스트를 설정하고 inetd데몬을 재구동 시키는 작 업을 수행해 주면 된다.

① 프로그램 파일 다운로드

■ TCP_Wrappers는 잘 알려진 툴인 만큼 여러 보안 사이트로부터 다운로드 받을 수 있다.

<대표적인 사이트>

CERTCC-KR http://www.certcc.or.kr/kisul/kisul8.htm
Porcupine.org ftp://ftp.porcupine.org/pub/security/tcp_wrappers_7.6.tar.gz.

어떤 사이트에서 프로그램파일을 구하든 관계없으나 트로잔 버전의 TCP-Wrapper가 아닌지 확인해 볼 필요가 있다.

[자세한 사항은 advisories/CA-1999-01에서 확인.]

* Correct version:

tcp_wrappers_7.6.tar.gz
MD5 = e6fa25f71226d090f34de3f6b122fb5a
size = 99438
tcp_wrappers_7.6.tar
MD5 = 5da85a422a30045a62da165404575d8e
size = 360448

* Trojan Horse version:

tcp_wrappers_7.6.tar.gz
MD5 = af7f76fb9960a95a1341c1777b48f1df
size = 99186

② 압축 해제

다운로드받은 프로그램의 확장자를 확인해서 경우에 맞는 tar 옵션을 준다. 압축이 풀리면

tcp_wrappers_7.6 라는 디렉토리가 새로 생성되고 [그림3]과 같이 파일들 존재할 것이다.

# tar -zxvf tcp_wrappers_7.6.tar.gz 또는 # tar -xvf tcp_wrappers_7.6.tar

③ sys-type 확인 및 Makefile 수정

시스템에 TCP-Wrappers 프로그램을 컴파일 할때, system type을 지정해주어야 하는데 다음 명령을 이용하여 확인한다.

#uname -a

SunOS sparc5 5.6 Generic_105181-05 sun4m sparc SUNW,SPARCstation-5

각 system type마다 서버데몬들이 존재하는 디렉토리 위치가 차이가 있기 때문에 Makefile의 REAL_DAEMON_DIR를 시스템

스타일에 맞게 설정을 해주어야한다. 압축을 해제하면 Makefile은 readonly 모드이므로 쓰기 가능한 모드로 수정한 다음 해당 sys-type에 맞는 REAL_DAEMON_DIR을 지정해 준다.

ftp stream tcp nowait root /usr/sbin/in.ftpd in.ftpd
telnet stream tcp nowait root /usr/sbin/in.telnetd in.telnetd
shell stream tcp nowait root /usr/sbin/in.rshd in.rshd
......

sunos5 타입인 본 시스템은 inetd.conf 파일을 확인해 보면 위와 같이 각종 서비스 데몬들이 /usr/sbin 밑에 존재하기 때 문에 REAL_DAEMON_DIR가 /usr/sbin 이 되므로 앞부분의 # 만 지워주면 된다.

그밖에 sys-type은 [그림5]를 참고하라.

④ 컴파일

압축을 해제했던 tcp_wrappers_7.6 디렉토리에서 컴파일을 수행하는데 make 명령을 이용해 다음과 같이 Makefile에서

정의한 REAL_DAEMON 위치와 sys-type을 설정해주면 된다.

# make REAL_DAEMON_DIR=/usr/sbin sys-type

본 시스템의 경우에는 susnos5를 sys-type으로 지정했는데 다음과 같이 컴파일 되는 과정이 화면에 보여진다.

#make REAL_DAEMON_DIR=/usr/sbin sunos5
cc -O -DFACILITY=LOG_MAIL -DHOSTS_ACCESS -DPARANOID -DNETGROUP -DGETPEERNAME_BUG
-DBROKEN_FGETS -DLIBC_CALLS_STRTOK -DSOLARIS_24_GETHOSTBYNAME_BUG
-DDAEMON_UMASK=022 -DREAL_DAEMON_DIR=\"/usr/etc\" -DSEVERITY=LOG_INFO
.........
.........

정상적으로 컴파일을 마쳤을 경우에 다음과 같은 5개의 실행파일이 생성된다.

-rwxr-xr-x 1 root other 10572 3월 24일 23:55 safe_finger* <--finger체크유틸리티
-rwxr-xr-x 1 root other 29888 3월 24일 23:55 tcpd* <--TCP_Wrapper데몬
-rwxr-xr-x 1 root other 29852 3월 24일 23:55 tcpdchk* <--TCP_Wrapper구성 체크
-rwxr-xr-x 1 root other 37808 3월 24일 23:55 tcpdmatch* <-- " 액세스콘트롤 체크
-rwxr-xr-x 1 root other 25176 3월 24일 23:55 try-from* <-- 유저체크유틸리티

⑤ 실행파일 및 맨페이지 파일 이동

새로 생성된 실행파일 5개를 Makefile에서 Real_Daemon_Dir로 지정해 주었던 실제 디렉토리 위치로 이동시킨다.

# cp safe_finger tcpd tcpdchk tcpdmatch try-from /usr/sbin

[ § 다른 곳에다 설치를 원할 경우에는 다음과 같은 별도의 과정을 거쳐야 한다. ]

# mkdir /other/place
# mv /usr/sbin/in.telnetd /other/place
# cp tcpd /usr/sbin/in.telnetd

온라인 설명파일들은 해당 맨페이지 디렉토리에 카피시킨다.

# cp hosts_access.3 /usr/man/man3
# cp hosts_access.5 hosts_options.5 /usr/man/man5
# cp tcpd.8 tcpdchk.8 tcpdmatch.8 /usr/man/man8

⑥ /etc/inetd.conf 파일 수정

외부의 연결로부터 보호할 네트워크 서비스들을 선택하여 tcpd가 보호하도록 inetd.conf 파일을 수정해 주어야한다.

보호하고자 하는 서비스의 서버프로그램 위치에 다음과 같이 tcpd 데몬이 설치된 위치를 지정해 주면 되는데 telnet을 예 로 들면 다음과 같다. [inetd.conf 파일은 주로 /etc 디렉토리 또는 /etc/inet 디렉토리에 존재한다.]

예) telnet 서비스를 보호하고자 하면 원래 파일을 수정된 파일처럼 지정해 주면 된다.

telnet stream tcp nowait root /usr/sbin/in.telnetd in.telnetd <-- 원래 파일
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd <-- 수정된 파일

[ § TCP_Wrapper 접근제어 가능 서비스 : SYSTAT, FINGER, FTP, TELNET, RLOGIN, RSH, TALK, EXEC, TFTP 등 ]

⑦ /etc/hosts.deny , /etc/hosts.allow 파일 생성

Linux 시스템에는 파일이 존재 할 것이나 Unix시스템에는 두 파일을 만들어주어야 한다.

#echo /etc/hosts.deny
#echo /etc/hosts.allow

4. 접근제어 리스트 설정

① 접근 제어 리스트 : TCP_Wrapper는 다음 두 파일에 의해 접근이 제어된다.

/etc/hosts.deny --> 접근 제어할 리스트
/etc/hosts.allow --> 접근 허용할 리스트
(not in either : 접근 허용)

② 접근 제어 형식 : 접근 제어 리스트 파일에 아래와 같은 형식으로 데몬, 사용자 등의 리스트를 등록한다.

daemon_list : client_list : option : option .... : shell_command

■ daemon_list : 하나 이상의 데몬 프로세스 이름

■ client_list : 하나 또는 그 이상의 호스트 이름, 호스트 어드레스, 패턴/와일드카드

■ shell_command : 규칙이 매칭될 때 수행되는 shell 명령으로 주로 허가되지 않은 접속 요청이 있을 경우 접속을 요청한 클라이언트의 단말기에 에러 메시지를 출력하거나 특정인에게 메일을 발송하는 형태로 주로 사용함.

[ 아래 [표2]와 [표3]을 참고하면 다양한 접근제어 규칙을 적용 할 수 있다. ]

[표2] 접근제어 기술 형식

기술 형식 기술예
IP Address 에의한 기술 172.16.2.146
Network address와 Netmask에 의한 기술 172.16.2.146/255.255.255.0
Networkgroup에 의한 기술 @local-network
호스트 명에 의한 기술 kisa.or.kr
와일드 카드를 이용한 기술 LOCAL /etc/hosts 에 등록된 모든 호스트에 대해 적용
ALL 모든 호스트에 대해 적용
사용자명과 호스트명에 의한 기술 kong@certcc.or.kr

[표3] host_options 와일드카드 & 연산자 & 쉘 커맨드특수문자

와일드카드 지원 기능
와일드카드 ALL 모든 호스트나 모든 서비스에 대해 허가 또는 제한 설정시 사용
ex)hosts.deny 파일에 ALL:ALL 이면 모든 호스들은 어떠한 서비스에도 접근 할 수 없다.
KNOWN hosts.allow나 hosts.deny 설정에서 알 수 없는 IP의 경우
LOCAL local 호스트
PARANOID IP 주소와 일치하지 않는 호스트
UNKNOWN hosts.allow나 hosts.deny 설정에서 알 수 없는 IP의 경우
연산자 EXCEPT 데몬,클라이언트 둘다 사용할 수 있고 특정한 예외를 두고자 할때 사용
쉘 커맨드 특수문자 %a(%A) client (server) 호스트 어드레스
%c Client 정보 : user@host, user@address, 호스트명 또는 주소
%d 데몬 프로세스 이름 (argv[0] value)
%p 데몬 프로세스 id
%u 클라이언트 사용자 이름 또는 unknown
%h(H) 유용하지 않은 client (server) 호스트명 또는 어드레스

[ § 접근제어 파일(hosts.deny , hosts.allow) 기술시 # 문자는 주석을 의미하고, 역슬래쉬 (\) 문자는 한줄에 계속 이어 쓴다는 의미로 긴 리스트를 다음 줄에 이어서 나열할 경우 사용하고 한 줄이 끝나는 마지막에 입력한다. 각 대상 리스트를 나열할때는 한칸의 공백 이나 콤마(,)로 구분한다. ]

5. inetd 재구동

접근제한 파일의 설정을 완료하면 새로운 설정이 적용되도록 현재 구동되고 있는 /etc/inetd 데몬의 process id를 확인하고 다 음의 명령을 이용해 inetd를 재구동 시켜준다.

kill -HUP process-id

■사례 inetd의 프로세스 id 확인

[root@cyber118 /etc]# ps -ef | grep inetd
root 572 1 0 Mar21 ? 00:00:00 inetd
[root@cyber118 /etc]# kill -HUP 572

6. 접속제어 로그

TCP_Wrappers 프로그램은 logging 정보를 syslog데몬으로 전달하고, 일반적으로 syslog.conf 에 의해 파일이나 콘솔에 쓰여지거나 @loghost 로 전달한다. tcpd가 접속제어한 서비스명,호스트명,어드레스등의 정보를 /var/log(adm)/syslog에 저장한다. Linux시스템의 경우에는 /var/log/messages 파일에 저장된다. 일반적인 접속제어 로그내용은 다음과 같은 형태로 남는다.

date time hostname service[process id]: connect from hostname
date time hostname service[process id]: refused connection from hostname

허가되지 않은 호스트가 접속을 요청 해 올 경우 해당 콘솔로 다음과 같은 메시지를 보낸다.

■ telnet 접속을 요청 한 경우

[cert:root]:/> telnet 172.16.4.150
Trying 172.16.4.150...
Connected to 172.16.4.150.
Escape character is '^]'.
Connection closed by foreign host.

■ ftp 접속을 요청 한 경우

[cert:root]:/> ftp 172.16.4.150
Connected to 172.16.4.150.
421 Service not available, remote server has closed connection

7. 접근제어 적용 사례

우선적으로 /etc/hosts.deny 파일에서 모든 호스트에 대한 접근을 막아놓고, 접근을 허가할 호스트는 /etc/hosts.allow 파일에서 설정하는 것이 일반적이다.

■ 사례1

/etc/hosts.deny
ALL : ALL EXCEPT .or.kr --> 모든 서비스에 대해 or.kr 도메인을 제외한 다른 시스템들은 접근차단
/etc/hosts.allow
ALL : LOCAL --> 모든 서비스에 대해 local 호스트들의 접근 허용

■ 사례2 텔넷서비스는 172.16.2.146 호스트만, ftp서비스는 172.16.2.159 호스트만 허용하였다. 그밖에 모든 호스트 들은 모든 네트워크 서비스로부터 제한하여 테스트가 용이하도록 설정하였는데, 허가되지 않은 호스트로부터 서비스 요 청이 들어오면 요청한 서비스명, 호스트 어드레스등의 정보를 kong@certcc.or.kr 로 메일을 발송하도록 설정한 예이다.

[cert:root]:/etc> vi hosts.allow
ALL:172.16.2.146
in.ftpd : 172.16.2.159
[cert:root]:/etc> vi hosts.deny
ALL:ALL:/usr/sbin/safe_finger -l @%h | /usr/ucb/mail -s "Reject %d from %h to cert"kong@certcc.or.kr&

[그림6] 사례2 에서 접근제어한 172.16.2.134 호스트의 텔넷 접속시도에 의해 통보된 메일

■ 사례2 의 경우에 남은 /var/log/syslog의 로그 메시지

......
......

Mar 29 00:50:42 ids in.telnetd[2352]: refused connect from 172.16.4.134

Mar 29 00:50:42 ids sendmail[2357]: AAA02357: from=root, size=515, class=0, pri=30515, nrcpts=1, msgid=<200103281550.AAA02357@ids.certcc.or.kr>, relay=root@localhost

Mar 29 00:51:12 ids sendmail[2359]: AAA02357: to=kong@certcc.or.kr, ctladdr=root (0/1), delay=00:00:30, xdelay=00:00:30, mailer=esmtp, relay=certcc.or.kr. [211.252.150.1], stat=Sent (AAA21903 Message accepted for delivery)

8. 설치확인

접근제어 파일설정 후에 직접 테스트를 해서 접속이 되는지 여부를 확인하고 syslog나 messages 의 로그를 확인하는 방법으로 확인 할 수도 있으나 TCP_Wrapper 가 지원하는 구성설정 확인 명령들을 이용하면 간편하다.

① tcpdchk 이용

접근제어 파일의 잘못된 문법이나 잘못된 경로명, 호스트명이나 어드레스등 설정된 규칙에 대한 구성오류 발견해 낼 수 있다.

② tcpdmatch 이용

접근제어 파일에 기술된 규칙을 실제로 적용하였을 때 발생하는 상황을 보여주기 때문에 tcpdmatch를 이용하면 한번에 확인 할 수 있다. 설정이 제대로 되었다면 접근제어한 호스트에서 접속을 시도할 때 deny 되는지, 허용한 호스트는 allow하는 지 여부를 확인해 본다.

■ usage: tcpdmatch [-d] [-i inet_conf] daemon[@host] [user@]host

- d : use allow/deny files in current directory
- i : location of inetd.conf file

 사례 비정상적인 ip 어드레스 111.111.111.111 로 telnet 접속을 시도하면 /etc/hosts.deny파일의 설정과 비교하여 접속 을 차단하고 접속을 시도한 호스트정보와 요청한 서비스를 지정된 메일로 발송하는 것을 확인할 수 있다.

[ids:root]:/usr/sbin> tcpdmatch in.telnetd 111.111.111.111
client: address 111.111.111.111
server: process in.telnetd
matched: /etc/hosts.deny line 1
command: /usr/sbin/safe_finger -l @111.111.111.111 | /usr/ucb/mail -s "Reject in.telnetd from 111.111.111.111 to cert" kong@certcc.or.kr&
access: denied

9. 참고자료

TCP_Wrappers_7.6 README file
http://www.cert.org/security-improvement/implementations
http://security.kaist.ac.kr/tips/tcpwrapper/TCP_Wrapper.htm
http://www.cert.org/advisories/CA-1999-01.html
리눅스 네트워크 레퍼런스 바이블, 베스트북, 2000.9

 

자료제공 : CERTCC-KR : 한국정보보호진흥원

'System > Linux' 카테고리의 다른 글

A typical north/southbridge layout  (0) 2011.11.02
일반 유저의 .rhosts 파일 생성 금지법  (0) 2011.11.01
/etc/profile 예시  (0) 2011.10.05
lsof , fuser, pgrep 명령어  (0) 2011.09.30
top 명령어  (0) 2011.09.27
Posted by linuxism
,
NAS가 이길까, SAN이 이길까"

불과 2, 3년 전만해도 수 많은 국내외 IT관련 월간지나 정보지 등의 특집 기사 제목이나 칼럼의 소제목으로 자주 등장했던 말이다. 서기 2003년의 스토리지 업계에서 이 말처럼 시대에 뒤떨어지고 진부한 말도 없을 것이다. NAS(Network Attached Storage)와 SAN(Storage Area Network)은 모두 한가지 큰 목적을 가지고 시장에 등장했다. 흩어져 있는 디스크를 한곳에서 집중 관리하고 서버는 그 중앙 스토리지가 나누어주는 디스크 공간을 '네트워크'를 통하여 할당 받고 사용하자는 아이디 어이다. 이러한 것을 '네트워크 스토리지(Networked Storage)'라고 부른다. NAS는 이더넷(Ethernet)을, SAN은 파이버 채널(Fiber Channel)을 중간 매개체인 '네트워크'로 선택해서 발전 해 왔다. 어느쪽이 더 좋은 성능을 내고 더 안정적인가를 논한다는 것은 이제 더 이상 무의미해진 일에 불과할 정도로 양 쪽 모두 눈부신 발전을 거듭 해 온 것이다.

"NAS가 맞을까, SAN이 맞을까"

바로 이것이 최근에 네트워크 스토리지를 도입하고 구성하려는 IT 담당자들이 가장 고민하는 부분일 것이다. 대형 서버의 부속품쯤으로 여겨졌던 디스크가 이제는 기업 전산실이나 대외 인터넷 서비스의 핵심 요소로 자리잡은 이 때에 그 디스크의 총체적 집합체인 스토리지 아키텍쳐를 이분법적으로 NAS 아니면 SAN으로 단일화한다는 것은 정말로 심사숙고해야 할 문제이다.

수 많은 기업들이 이미 네트워크 스토리지를 도입하여 성공적으로 운영하고 있고 수 많은 매체에서 네트워크 스토리지에 대하여 과거 수년 동안 심도 있게 다루어 왔음에도 불구하고 의외로 많은 사람 들이 NAS와 SAN의 차이점을 명확히 알지 못하고 있는 듯 하다. 혹자에게는 지겨운 이야기가 되겠으나 그래도 한번 짚고 넘어가 보자.










표 1. NAS와 SAN의 비교

NAS는 데이터 공유가 되고 SAN은 데이터 공유가 안된다는 이야기는 파일 시스템을 디스크가 관리하는가 서버가 관리하는가의 차이에서 비롯된다. 데이터의 전송 단위가 파일이냐 블록이냐 하는 것은 뭐가 되고 안되고의 문제가 아닌 애플리케이션의 특성에 따라 어느쪽이 유리한가의 문제이다. 대표적인 예가 데이터베이스의 경우인데 전통적으로 데이터베이스는 블록 단위의 액세스에 유리하도록 제작되어 있다. 대부분 대용량의 미션 크리티컬한 업무에 사용되는 데이터베이스의 스토리지로 SAN이 선택되는 이유도 이 때문이다.

물론 요즘에는 오라클을 위시한 대표적인 데이터베이스가 NAS에서 잘 돌아가도록 재설 되고 있고 하이엔드급의 NAS에서 데이터베이스를 운영하는데 아무런 문제가 없는 시대가 되었다.

표 1을 가만히 보면 NAS와 SAN은 완전히 다른 구조를 가지고 있음을 알 수 있다. 하지만 이것은 전적으로 스토리지를 만드는 사람과 구성하는 사람의 입장에서 본 관점일 수 있다. 정작 데이터를 저장하고 저장된 데이터를 유용하게 사용하려는 사람의 입장에서 보면 프로토콜이나 전송단위 따위는 알려고 하면 골치 아프고 별로 알아야 할 필요도 없는 것이 사실이다.

"NAS도 필요하고 SAN도 필요하다"

문제는 이것이다. 둘 다 필요하다는 것. 'NAS에 데이터를 저장하는 것에 대해서는 데이터의 정합성을 보장할 수 없다'고 하는 몇몇 데이터베이스 애플리케이션의 경우에는 선택의 여지가 없이 SAN을 사용해야 한다. 수십에서 수백, 수천대의 서버가 동일한 데이터를 공유해야 하는 경우에는 역시 선택의 여지가 없이 NAS를 사용해야 한다.

대표적인 두 가지 예를 들었지만, 오늘날 기업의 90%가 SAN과 NAS의 필요성을 모두 가지고 있다는 보고서가 나오는걸 보면 기업의 전산 환경이 날로 다양해지고 복잡한 요구가 계속된다는 것을 미루어 짐작할 수 있으리라 생각된다. 사실 답은 간단하다. 둘 다 도입하면 된다. SAN이 필요한 업무의 서버는 SAN을 이용한 스토리지 통합을 추진하면 되고 NAS가 필요한 업무의 서버는 NAS를 이용한 스토리지 통합을 추진하면 두 가지 요건을 모두 충족시킬 수 있게 된다.

하지만 이렇게 하기엔 몇 가지 쉽지 않은 문제가 따른다. 우선 투자 비용이 과다하다는 점이다. 전혀 다른 두 제품을 구매해야 한다는 이유에서다. 네트워크 스토리지의 특성상 스토리지만 구매한다고 모든 것이 해결되지는 않는다. 더군다나 SAN의 경우는 파이버 채널이라는 기존에 사용하던 이더넷 환경과 전혀 다른 종류의 네트워크를 구성해야 하기 때문에 그에 따른 파이버 채널 스위치라던가 서버의 HBA(Host Bus Adapter)등이 추가로 요구된다.

그 다음으로 관리적인 리스크 문제를 생각 해 볼 수 있다. SAN을 도입한다는 것은 뭔가 상당히 전문적인 스토리지를 도입한다는 느낌이 든다. 흔히 인터넷을 사용하면서 친숙하게 오랫동안 사용해온 네트워크와는 전혀 다른 네트워크를 구성한다는 것, 사무실 여기저기에 굴러다니는 이더넷 스위치를 그대로 두고 그보다 몇 배 비싼 파이버 채널 스위치를 또 구입해야 한다는 것, 결정적으로 이러한 모든 것들이 대단히 낯설고 아주 하찮은 문제라도 생기면 전문 인력에게 전적으로 의존해야 한다는 석연찮음 등이 그 느낌의 일부분일 것이다. 결론적으로 이미 회사에서 열심히 일하고 있는 네트워크 관리자가 관리할 수 없는 네트워크가 새로 생긴다는 것이다.

"SAN과 NAS를 결합하면?"

이러한 요구 사항을 만족시키는 동시에 위에서 제기한 문제를 해결하기 위한 스토리지 업계의 노력은 다양한 방법으로 표출되어 왔다.

그 중 하나는 'NAS 게이트웨이(Gateway)'라는 것이다. EMC의 Celerra나 HDS의 gFiler가 그 대표적인 예라고 볼 수 있다. 이것은 SAN을 중심으로 하여 SAN 스토리지를 NAS의 컨트롤러 역할을 하는 장비와 연결하여 SAN의 디스크 공간의 일부를 NAS 컨트롤러에 할당 하여 사용할 수 있게 해 주는 솔루션이다. 주된 타겟은 이미 SAN을 도입하여 사용하는 기업이 NAS의 요구가 있을 때, 새로 NAS 스토리지를 도입 할 것이 아니라 NAS 게이트웨이라는 NAS 컨트롤러만 도입하도록 하여 디스크 자체에 대한 중복 투자를 방지하자는 것이다. 사실상 이러한 제품을 통하여 SAN업계의 선두주자인 EMC가 NAS 시장으로 진입을 시작하였으며, HDS는 NAS업계의 선두주자인 네트워크 어플라이언스(이하 넷앱)와 손을 잡고 자사의 SAN제품에 NAS 게이트웨이를 공급하고 있다. 강력한 방법이긴 하나 역시 하드웨어가 들어가는 만큼 투자 비용이 만만치 않다.

또 한가지 방법은 NAS 스토리지에서 SAN을 지원하는 것이다. 네트워크 어플라이언스가 대표적이면서 또한 유일한 경우인데, 자사의 NAS 스토리지에서 이더넷 포트 뿐만 아니라 파이버채널 스위치나 서버의 HBA와 바로 연결할 수 있는 파이버 채널 인터페이스를 지원하여 디스크의 일부를 SAN호스트에게 할당하여 사용할 수 있도록 하는 방법이다. 유니파이드 스토리지(Unified Storage), 혹은 FAS(Fabric Attached Storage)라는 개념이 출발하게 된 직접적인 계기가 된 경우라고 볼 수 있다. 물론 NAS 게이트웨이와 SAN 디스크를 하나의 제품이라고 본다면 그 또한 FAS라고 보는 견해도 있다. 어찌 되었건 궁극적으로 하나의 스토리지 박스만으로 NAS와 SAN을 모두 사용하자는 것이 이러한 제품의 의도라고 볼 수 있다.

"그런데...여전히 너무 비싸다."

위의 두 가지 방법은 업계 최고의 기술을 응집하여 최대의 성능을 내면서 '단일 박스 내에서의 NAS와 SAN의 지원'이라는 명제를 외형적으로 해결한 것은 사실이지만 문제는 여전히 투자비용이 많다는 것이다. 전자의 경우는 디스크 몇 개(?)의 가격을 절약한 정도이고 후자는 훨씬 근본적인 접근 방법이긴 하지만 여전히 파이버채널 네트워크가 필요하다는 숙제가 남아 있다.

그래서 눈을 돌린 것이 네트워크 프로토콜에 대한 접근법이다. 즉, 친숙하고 상대적으로 가격이 훨씬 저렴한데다가 라우팅이 가능하여 거리제한이 전혀 없는(참고로 파이버채널은 라우팅이 불가능하고, 따라서 직접적으로는 50Km라는 거리 제한이 있다) IP 네트워크를 이용하여 NAS와 SAN을 모두 사용하고자 하는 필요조건을 만족시키기 위한 다양한 시도가 행해진 것이다. 그래서 등장한 것이 바로 'iSCSI(Internet Small Computer System Interface)'라는 프로토콜이다.


"iSCSI? iSCSI!"

앞의 두 방법이 스토리지 장비 자체를 중심으로 한 접근법 내지는 해결책이었다면 iSCSI는 네트워크 프로토콜을 중심으로 한 해결책이라고 볼 수 있다. iSCSI는 넷앱과 인텔이 프로토콜의 프로토타입을 만들어 IETF(Internet Engineering Task Force)에 상정, 지난 2월에 HTTP, FTP등과 같은 인터넷 표준 프로토콜로 인정 받은 이후로 TCP/IP상에서 블록단위의 데이터를 전송할 수 있도록 하는 최적의 솔루션으로 각광 받고 있다. "TCP/IP상에서 블록단위의 데이터를 전송한다"라는 말은 어떻게 사용하라는 말인지 사실 크게 와 닿지 않는 것이 사실이다. 다음과 같은 상황을 한번 생각 해 보자.

A라는 회사의 정보시스템 부서장인 나부장은 지난달까지 회사의 핵심 시스템들에 대한 대대적인 스토리지 통합 작업을 완료하고 그 성능이나 관리의 효율성에 대단히 만족하고 있다. 회사 내부의 ERP 및 외부 서비스 관련 대형 DB서버 4대는 SAN 스토리지를 도입하여 통합시켰고, 인터넷 서비스용의 중형 서버 80여대는 NAS 스토리지를 도입하여 역시 각 서비스 특성 별로 공간할당을 하여 완벽하게 로드 밸런싱 환경을 구현 해 놓았다. 그런데 문제는 2주전부터 다른 곳에서 발생하기 시작했다. SAN으로 통합한 것 이외에도 회사 여기저기에 흩어져 있는 20여대의 Windows 및 Linux를 사용하는 DB서버의 디스크 공간이 거의 80%에 이르고 있다는 보고가 올라 오기 시작 한 것이다. 물론 SAN을 도입 할 당시에 이 서버들을 고려하지 않은 것은 아니지만 그 서버에도 두개씩 HBA를 탑재하고 SAN 스위치까지 도입한다고 계산하니 도저히 예산 범위 내에서 해결 할 수 있는 문제가 아니었다. 사실 크리티컬한 업무가 아니라고 과소평가한 부분도 없지 않았다. 하지만 어제 발생한 제2부서의 Exchange서버가 노화되어 문제가 생겼을 때 공교롭게도 디스크 장애로 인하여 시스템을 완전히 새로 구성하였는데 꼬박 8시간 30분이 걸렸다. 결국 그 시간 동안 아무도 사내 이메일을 사용할 수 없었다. 이런 작은 서버들 까지도 모두 그 값비싼 파이버 채널로 연결하여야 한다는 말인가…

고민중에 문득 "NAS서버에 DB를 돌려도 아무런 문제가 없다"는 말이 생각났다. "그래! 2대의 Exchange서버와 18대의 DB서버를 NAS로 통합하는 거야!" 스스로의 번뜩이는 아이디어에 감탄한 나부장이 좋아했던 것도 잠시. Exchange 서버와 SQL 서버는 NAS에서 운영하는 것에 대한 데이터 정합성을 보장할 수 없다는 자료를 부하 직원이 보고해 왔다.

고민은 줄었다. 첫째, 그냥 하던 대로 디스크를 추가하면 된다. 하지만 언제까지 이렇게 할 것인가. 왜 값비싼 SAN을 도입하고 NAS를 도입하였는데. 둘째, 20대의 서버에 HBA를 꼽고, 모자라는 파이버 채널 포트 수를 충당하기 위하여 SAN스위치를 도입하여 기존의 SAN에 통합하는 것이다. 견적을 받아 보니 엄청나다. 애초에 예산을 잡아놓지 않았기 때문에 당장 집행할 수 있는 일도 아니다. 방법이 없을까?

이와 같은 상황에서 가장 적합한 솔루션이 바로 iSCSI를 이용한 SAN을 구성하는 방법이다. 다행히 나부장이 도입한 NAS장비는 완벽하게 iSCSI를 지원하고 있다. 그것도 프로토콜 라이센스를 무료로 사용할 수 있다니! 기존의 SAN 스토리지 및 파이버 채널 네트워크는 전혀 생각하지 않아도 된다. 20대의 서버에서 사용하지 않던 여분의 이더넷 포트와 전산실 구석에서 잠자고 있는 L2스위치 한대만 있으면 NAS 스토리지를 이용하여 간단하게 SAN을 구축할 수 있게 된 것이다. Exchange도 완벽하게 동작하고 MS SQL서버도 완벽하게 동작한다. iSCSI를 사용하는 서버에서 바라본 NAS의 볼륨은 로컬 하드디스크와 완전히 동일하게 보인다. 허…이거 완전히 SAN이네…

"iSCSI는 어떻게 작동하길래…"

도대체 iSCSI라는 것이 어떻게 작동하길래 돈 한푼 안들이고 SAN 환경을 구축할 수 있다고 하는 것일까. 이더넷 네트워크상에서의 데이터는 IP 패킷 형태로 흘러다닌다. 마찬가지로 SCSI 케이블을 통해서는 SCSI 패킷의 형태로 흘러 다니게 된다. 당연히 이더넷 네트워크로 SCSI 패킷을 보내려고 하면 전송되지 않고 반대의 경우도 마찬가지이다.





그림 1. SCSI패킷





그림 2. iSCSI 패킷

위의 그림 1은 전형적인 SCSI 패킷을 단순하게 그린 것이다. 여기에 그림 2에서와 같이 IP 헤더만 덧붙이면 그대로 IP 패킷이 되는데 이 형태로 전송하게 되면 이더넷 네트워크의 입장에서는 이것을 단지 IP 패킷이라고 생각하고 전송하게 되는 원리이다. 따라서 스토리지나 서버에서는 SCSI 패킷에 IP 헤더를 붙였다 떼었다하는 작업이 수반되게 되는데 이것이 iSCSI의 전부라 해도 과언이 아니다. 단순히 몇 바이트의 IP 헤더만 데이터에서 탈부착시키는 과정이 더해지는 것 뿐, 어떠한 데이터의 변환이나 암호화 등의 연산은 일어나지 않으므로 많은 시스템 오버헤드도 필요치 않게 된다.

iSCSI를 이용한 스토리지 통합을 구현하기 위해서는 크게 세가지 구성 요소가 필요하다.

1. iSCSI Target (=스토리지)
iSCSI가 완벽하게 지원되는 스토리지가 있어야 함은 물론이다. 즉 디스크통합의 최종 주체가 되는 스토리지에서 iSCSI 프로토콜을 지원해야 한다. 이럴 경우 해당 스토리지를 'iSCSI Target'이라고 부른다. 아직까지는 전 제품 모델에서 iSCSI를 완벽하게 지원하는 스토리지는 넷앱의 파일러 제품군밖에는 없다. 넷앱의 파일러 제품을 가지고 있다면 iSCSI 프로토콜 라이센스를 무료로 추가할 수 있다.

2. iSCSI 네트워크 (=일반 TCP/IP 네트워크)
iSCSI 전용 네트워크가 있는 것은 아니다. 기존의 일반 TCP/IP의 이더넷 환경이라면 더 이상 필요한 것은 없다. iSCSI는 표준 TCP/IP상에서 작동하도록 설계되어 있기 때문이다.

3. iSCSI Initiator (=서버)
iSCSI는 기본적으로 서버의 이더넷 랜 카드를 통하여 작동한다. 단, 여타의 드라이버들처럼 iSCSI 패킷을 이해할 수 있도록 iSCSI 드라이버가 있어야 하고 이러한 iSCSI 드라이버는 각 OS벤더에서 무료로 제공하고 있다. 이와 같이 기존의 랜카드에 iSCSI 드라이버만 설치해서 사용하는 경우를 소프트웨어 이니시에이터라고 하며, iSCSI와 관련된 연산은 서버의 CPU가 하게 된다. 반대로 iSCSI와 관련된 연산을 하는 전용 카드를 iSCSI HBA라고 하는데 이러한 전용 카드를 사용하는 경우를 하드웨어 이니시에이터라고 한다. 넷앱 파일러를 이미 사용하고 있으면서 소프트웨어 방식을 선택하였다면 정말로 돈 한 푼 안들이고 SAN을 구축하는 것이 가능해진다는 이야기가 된다.

iSCSI는 2003년 2월에 표준으로 채택된 신기술이지만 대부분의 스토리지, 서버 벤더들은 iSCSI에 대한 적극적인 지원을 표명하고 있으며 지금도 끊임없이 제품 개발에 박차를 가하고 있다. 하지만 아직은 그리 오래 되지 않은 표준 프로토콜이기 때문에 스토리지에 있어서는 넷앱의 전 모델, 서버측은 Windows 2000 이상, Linux 계열 그리고 노벨 NetWare만 정식 지원되고 있다. 올 연말에서 내년 초,중반까지 IBM의 AIX, HP의 HP-UX, Sun Microsystems의 Solaris운영체제도 지원 될 전망이다. 아래 그림 3은 넷앱의 스토리지를 이용하여 iSCSI를 통한 스토리지 통합을 구현한 다이어그램을 보여준다.


그림 3. iSCSI를 이용한 스토리지 통합 다이어그램

iSCSI가 가져다 주는 이점은 비단 저렴한 가격의 SAN을 구축할 수 있다는 점 뿐만이 아니다. 전체 스토리지 시장의 60% 이상을 차지하고 있는 중소형 서버의 DAS(Direct Attached Storage)를 네트워크 스토리지로 통합하는 가장 손쉽고 리스크가 적은 솔루션으로 급속히 자리잡아 가고 있는 iSCSI는 SAN이 가져다 주는 이점을 대부분 그대로 제공해 준다.

다만 아직까지 계속 발전 단계에 있는 프로토콜이고 지속적으로 지원 플랫폼을 넓혀가고 있는 새로운 솔루션이기 때문에 보유하고 있는 서버 기종에 따라 좀 더 기다려야 하는 경우가 있을 수 있다. 회사의 주요 업무를 관장하는 대형 서버는 SAN과 NAS를 도입하여 모두 통합하였다. 이제 각 부서에, 전산실 여기저기에 흩어져서 각자 나름대로 중요한 업무를 담당하고 있는 중소형 서버들을 손볼 차례다. 무얼 망설이는가. 무얼 망설이는가. iSCSI에 그 해답이 있다. 

출처 : 넷엡(
 http://www-kr.netapp.com/tech_library/kr_iscsi_1.html#7)
          http://hostindex.tistory.com/entry/%EA%B8%B0%EC%97%85-%EC%8A%A4%ED%86%A0%EB%A6%AC%EC%A7%80%EC%9D%98-%EC%97%B4%EC%87%A0-iSCSI-SAN

'System > Storage' 카테고리의 다른 글

DLT와 LTO  (1) 2012.01.03
LTO란 무엇인가?  (0) 2012.01.03
Posted by linuxism
,

MySQL DB 백업/복구

DB/MySQL 2011. 10. 19. 15:00


백업 명령

mysqldump -u root -p DB명 > 파일명.sql
암호입력 (Enter)
1DB 와 2DB를 백업
mysqldump -u root -p --databases 1 2 > 파일명.sql
모든 데이터베이스 백업
mysqldump -u root -p --all-databases > 파일명.sql

덤프시 LOCK TABLES 에러메시지 발생할경우 테이블에 lock이 걸려있어 덤프가 안된다
그럴경우 --lock-tables=0  옵션 추가



복구 명령

mysql -u root -p DB명 < 파일명.sql
암호입력 (Enter)
모든데이터베이스 복구
mysql -u root -p < 파일명.sql

특정테이블만 백업 및 복구
백업
mysqldump -u root -p db명 테이블명 > 백업파일명.sql

복구
mysql -u root -p db명 < 백업파일명.sql

복구시 한글이 깨지는 경우가 종종 있다. 그럴때는 아래와 같이 --default-character-set 옵션을 사용해 복구한다
mysql -u user -p --default-character-set=euckr DB명 < 파일명.sql

source명령어로 복구방법

1. 우선 mysql에 접속합니다. (root로)

2. source (dump떠 놓은 파일 경로와 파일 이름)후 enter
- ex : source /home/backup/db.sql
* 끝에 ;를 붙이지 않습니다.

* 전체 db가 아니라 특정 사용자와 특정 db라면 해당 계정 접속후 해당 use 해당db (enter)
source /home/backup/user.db



출처 - http://anews.smartflex.org/631






/usr/local/mysql/bin 디렉토리로 이동하여 명령을 실행한다.

[ 백업 ] : mysqldump -u 사용자아이디 -p 백업받을DB > 백업파일명
./mysqldump -u root -p intranet > /home/eight256/intranet.sql
./mysqldump -u root -p realweb > /home/eight256/realweb.sql

[ 복구 ] : mysql -u 사용자아이디 -p 복구할DB < 백업파일명
./mysql -u root -p intranet < /home/eight256/intranet.sql
./mysql -u root -p realweb < /home/eight256/realweb.sql





'DB > MySQL' 카테고리의 다른 글

MySQL 시스템 데이터베이스 및 테이블 구조 이해하기  (0) 2012.01.19
mysqld_safe  (0) 2012.01.18
MySQL에서 Create Procedure 설명  (0) 2010.12.21
MySQL에서 Create Procedure  (0) 2010.12.21
리눅스에서 my.cnf 설정  (0) 2010.12.21
Posted by linuxism
,