기존의 inetd 데몬은 잘 알려져 있다. 이것의 기능을 대체할 여러 방법들이 있지만, 가장 유연하고 쉬운 방법은 xinetd일 것이다. Xinetd는 inetd가 할 수 있는 모든 것을 수행한다. 그 이상도 할 수 있다. TCP 래핑(wrapping), 모듈러 설정, 커넥션 리다이렉션(connection redirection), 인커밍 커넥션에 대한 로드 제한 등은 기능의 일부일 뿐이다. 시스템 관리자가 xinetd를 선택할 충분한 이유가 된다.

이 글은 초보자에서 중급의 시스템 관리자를 대상으로 한다. inetd에 익숙하지 않을 것이라는 것을 감안하고 설명 및 예제를 선별했다. 이 글에서 xinetd의 간단한 사용 예제를 보게 될 것이다. 설치에서 보안 정책의 구현까지, xinetd의 간단한 사용 예제를 살펴보도록 하자.

시스템 요구사항

시스템이 최신(2000년 이후) 유닉스 계열 (리눅스, 솔라리스, BSD)의 시스템이면 이상적이다. 예제는 이전 버전의 펄과 유닉스에도 작동하고 기타 다른 OS에도 문제없이 작동하지만 문제가 생길 수도 있다. 문제에 대한 해결책을 염두해야 한다. 이 글의 특정 예제들은 레드햇 리눅스용이다. 하지만 다른 시스템에서도 문제없이 작동한다.

위로

inetd

유닉스 시스템 관리자에게 있어, inetd는 cp/rm/mv 명령어 만큼 기본적인 것이다. 이것은 항상 존재하고 있으면서 인커밍 커넥션을 핸들 할 준비를 하고 있다. 하지만 이것이 무엇이며 무슨 일을 하는가?

대답은 TCP/IP로 시작한다. 여러분이 호스트에 연결할 때 사실상 TCP/IP에 연결하는 것이다(일반적으로, 소켓); 여러분과 호스트 사이의 전화와 같은 것이라고 생각하면 된다. TCP/IP 연결은 호스팅을 시작하고 호스트를 받아들임으로서 독자적으로 정의되지만 다른 식별자가 있다. 만일 우리 모두 서버에 연결되어 있다면 웹서버, 텔넷, SSH, FTP, 기타 커넥션 등을 어떻게 구별할 수 있겠는가? 소켓은 연결을 수행하는 데 사용되는 포트에 의해서 정의된다. 예를 들어, port 21은 인커밍 FTP, 22는 SSH, 23는 TELNET..이런 식이다.

일단 연결이 이루어지면 누군가는 다른 끝에서 전화기를 든다. 이것은 오퍼레이터 라인(operator line) 또는 다이렉트 라인(direct line)이 될 수 있다. 다이렉트 라인은 서버에 직접적으로 연결되었다는 것을 의미한다. 반면 오퍼레이터 라인은 inetd가 개입된 접근방식이다. 오퍼레이터는 다량의 인커밍 다이렉트 라인 (호스트상의 포트)을 핸들링한다.

UDP는 또 다른 연결 방식이다. TCP 처럼 이것은 기본적으로 다른 누군가와의 대화라고 할 수 있다. 하지만 신뢰성은 보장하지 않는다. 전화 아날로그를 지속하기 위해서 UDP는 컨베이어 벨트에 메시지를 보내고 수신자는 컨베이어 벨트의 다른 끝에 서있는 것과 같다. 여러분은 컨베이어 상에서 더 많은 메시지를 보낼 수 있지만 수신자는 몇 가지를 놓칠 수도 있다. 메시지가 많거나 메시지를 읽는데 많은 시간이 걸릴 수 있기 때문이다.

inetd를 사용하면 몇 가지 점검이 수행된 후에 특정 서버로 다시 갈 수 있다. inetd.conf는 유일한 설정파일로서 모든 인커밍 연결을 관리한다. 시스템에 서비스를 추가하고 삭제 및 변경, 리뷰 할 때 훨씬 쉬워진다. 예를 들어 ftp는 솔라리스 시스템에 TCP 래퍼와 함께 다음과 같이 정의되어 있다:

ftp     stream  tcp     nowait  root    /usr/sbin/tcpd          in.ftpd

이것은 FTP 연결을 만드는데 필요한 변수들이다. 우리는 스트림 지향(stream-oriented) 모드에서 TCP/IP (tcp)를 사용하고 있다. 한번에 하나 이상의 FTP 연결을 허용하며, root로서 실행되며, FTP를 호출한다.

Xinetd는 inetd 디자인을 가져다가 이것을 모듈화 한다. 각 서비스는 고유의 설정 파일을 가질 수 있다. Xinetd는 TCP 래퍼와 같은 기능을 추가한다. 이로서 설정은 더욱 쉬워진다.

Xinetd는 중앙 설정 (오퍼레이터) 접근방식을 가지고 있다. 모든 설정파일들을 한곳에 (주로, /etc/xinetd.conf 와 /etc/xinetd.d/*) 저장한다. 그래서 시스템 관리는 더욱 쉬워진다. 이것을 xinetd.d 디렉토리에 복사해서 모듈러 설정은 서비스를 여러 머신에 분배할 수 있다는 것을 의미한다. 심지어 별도의 추가 디렉토리를 지정할 수 있다.

마지막으로, xinetd FAQ (참고자료)에는 RPC 프로그램이 xinetd로 잘 작동하지 않는다는 것을 말하고 있다. RPC를 위해 inetd를 사용하고 그외 다른 것을 위해 xinetd를 사용하는 것은 문제없다. 이것은 두 명의 오퍼레이터를 고용하는 것과 같다. 왜냐하면 한명은 스페인어를 말하고 다른 한명은 그외 모든 언어를 다루는 식으로 말이다.

위로

xinetd

xinetd는 무엇인가? 이것은 단순한 프로그램이다. 그게 전부다. 인커밍 네트워크 커넥션을 핸들링하는데 있어서 마법같은 것은 존재하지 않는다. 펄, 파이썬, 자바에서 수행할 수도 있다. Xinetd는 C로 작성되었고 이것의 선배인 inetd 만큼 빠르다.

Xinetd는 작업이 진행중이다. (참고자료). 아직도 진행중이기 때문에, xinetd의 보안 허점들은 빠르게 보완된다. inetd가 더이상 패치되지 않는 것과는 다르다. 물론, xinetd에는 소스 코드가 있어 어느부분에 취약성이 있는지 볼 수 있다.

xinetd를 이용하여 어떻게 서비스를 정의할까? /etc/xinetd.conf에 지정된 일반적인 매개변수 이외에도 특정 구성을 지정하는 서비스 파일을 만든다. /etc/xinetd.conf:

defaults
{
        instances               = 60
        log_type                = SYSLOG authpriv
        log_on_success          = HOST PID
        log_on_failure          = HOST
        cps                     = 25 30
}

service telnet
{
        flags           = REUSE
        socket_type     = stream        
        wait            = no
        user            = root
        server          = /usr/sbin/in.telnetd
        log_on_failure  += USERID
        disable         = yes
}

includedir /etc/xinetd.d

/etc/xinetd.d에 있는 모든 서비스 파일은 디폴트를 상속받고 고유의 매개변수를 지정한다. 텔넷 서비스는 하위 디렉토리 대신 상위 레벨에 정의되어있다. 이러한 모듈 속성은 복잡한 설정을 가능하게 한다.

xinetd가 설정파일을 다시 읽기 위해 재시작 할 필요가 없다. 이것을 간단히 USR2 시그널로 보낸다.

다음과 같이 매개변수를 정리했다. 몇몇 매개변수 (rpc_version, rpc_number)는 제외되었다.

일반적인 매개변수들

id

이 서비스를 위한 독자적인 이름. 서비스 이름은 괄호 앞에 이미 지정된다. 하지만 ID는 이론적으로 같은 서비스를 위해 여러 프로토콜을 갖는 것이 가능하다. 일반 사용자에게는 사용이 제한되어있다. 예를들어, NFS 서비스는 UDP 또는 TCP 전송 프로토콜을 통해 실행될 수 있다. 타임 서비스는 xinetd에 있다.

type

실제로 "specialtype"으로 불린다. 특별한 서비스에만 적용되기 때문이다. RPC 서비스를 위해 "RPC"의 조합이 될 수 있다; 서비스용 "INTERNAL"은 xinetd에 내장되어 있다; "UNLISTED"(RPC 서비스용 /etc/services 또는 /etc/rpc)는 시스템 리스트에서 찾을 수 없는 비표준 서비스를 위한 것이다.

flags

모든 기타 플래그들은 이에 해당한다. 이 리스트는 길고 매우 기술적이다; 흥미로운 플래그로는 REUSE (소켓 재사용), NAMEINARGS/NOLIBWRAP (TCP 래퍼를 수동으로 호출하거나 모든 래퍼를 피하고 싶을 경우), NODELAY/KEEPALIVE (TCP 소켓 튜닝), DISABLE (상위 레벨의 "disable" 파라미터 오버라이드), SENSOR (서비스 거부 네트워크 공격 감시)등 이다.

disable

서비스가 불가능하게 되기를 원하지 않는한 항상 "no" 로 설정해야 한다. 레드햇 리눅스 chkconfig 프로그램은 "disable" 매개변수를 키거나 끈다; 레드햇의 경우 chkconfig를 사용하여 특정 서비스를 사용 불가 또는 가능으로 만드는 것이 수동으로 하는 것보다 쉽다. chkconfig는 /etc/xinetd.d/SERVICE에서 서비스 파일을 찾을 것이다. Listing 2 예제에서, chkconfig은 요청될 때 텔넷을 키거나 끄지 않을 것이다. 이것은 보는이의 관점에 따라 버그일 수도 있고 또 하나의 기능이 될 수도 있다.

socket_type

UDP 서비스를 사용하지 않는한 이것을 "stream"으로 설정해야 한다. "raw"와 "seqpacket" 도 있지만 일반적이지 않다.

protocol

연결에 사용되는 프로토콜이다. 보통 "tcp" 또는 "udp"이다. 이론상으로는/etc/protocols에서 무엇이든 사용할 수 있다.

wait

"no"로 설정되었다면, xinetd은 모든 커넥션에 그 서비스를 위해 새로운 핸들러를 시작시킬 것이다. "yes"로 설정되어 있다면, xinetd는 핸들러가 연속적인 커넥션을 처리한다고 볼 수 있다. 대부분의 경우, "no"이다.

server, server_args

핸들러용 프로그램 이름과 매개변수.

port

서비스의 포트. 포트는 /etc/services 파일에 의해 서비스로 매핑되기 때문에 일반적으로 불필요하다.

redirect

xinetd가 서비스로의 모든 트래픽을 또 다른 호스트에 보낼 수 있도록 한다. 따라서 방화벽이 설치된 호스트는 중앙의 xinetd 포워더를 통해 안전한 트래픽만 허용할 수 있다. 하지만 외부 네트워크로의 연결은 없다.

banner, banner_success, banner_fail

성공한 커넥션인지 실패한 커넥션인지를 프린트하는 파일 텍스트의 커스텀 블럭.

enabled

"disabled" 매개변수와 DISABLE 플래그를 global 레벨에 포함한다.

include, includedir

xinetd에게 파일 또는 디렉토리를 포함하도록 명령한다.

환경 매개변수

user, group, umask, groups

대부분 불안정한 서비스용이다.

nice

이 서비스가 시스템에 있어 얼마나 중요한지를 결정하는 유닉스 우선순위 레벨. 시스템에 맞춰 튜닝할 수 있다; "nice" man page 참조.

env

서비스 핸들러용 환경 변수.

passenv

xinetd로 부터 서비스 핸들러로 전달되어야 하는 환경변수.

리소스 관리 매개변수

instances

즉시 시작할 수 있는 핸들러의 수. 서비스 거부 공격을 방지하도록 튜닝 될 수 있다. 디폴트(제한없음) 작동을 원한다면 "UNLIMITED"로 설정.

max_load

시스템이 과도하게 부하가 되면 커넥션 수락을 중단할 것. 로드의 수는 시스템에 따라 다르다.

rlimit_as, rlmist_cpu, rlimit_data, rlimit_rss, rlimit_stack

매개변수는 서비스 핸들러를 위해 리소스 제한 (메모리, CPU, 특정 메모리 구역)을 정한다.

보안 관련 매개변수

only_from, no_access

TCP 래퍼 보완. 우리에게 연결되는 호스트를 막는 방법. 기본적으로 모든이에게 액세스가 허용된다.

access_times

서비스가 가능한 시간. 예를 들어 "6:00-23:00"는 오전 6시 부터 오후 11시 까지 서비스가 가능하다는 것을 의미한다.

log_type, log_on_success, log_on_failure

다양한 로그 옵션들. 특히 USERID 플래그는 문제가 많을 수 있다. 가능하다면 USERID를 피하는 것이 좋다.

bind

서비스가 인터페이스 스팩이 되도록 한다. 보안의 이점이 있다. 예를들어, 네트워크 내부의 FTP 서비스는 FTP이다. 반면 외부의 FTP 커넥션은 침입자 경보를 만들어낸다. "id" 매개변수가 유용하게 쓰인다.

per_source

소스 IP에서 서비스의 최대 인스턴스 지정. 단일 소스의 서비스 거부 어택 또는 많은 커넥션을 만드는 버그가 많은 프로그램 핸들러에 유용하다.

cps

허용된 초당 최대 커넥션과 서비스가 다시 가능할 때 까지 걸린 시간(초). "30 45"는 "초당 30개의 인커밍 커넥션과 제한이 초과할 경우 45 초의 기다림"을 의미한다.

deny_time

SENSOR 플래그를 시작한 사람에 의한 서비스 거부 시간.

위로

TCP 래퍼 대체

기존의 TCP 래퍼 패키지는 매우 유용한 툴이다. 중앙화 된 파일인 /etc/hosts.allow와 /etc/hosts.deny를 통해서 서비스 마다 호스트에서 허용될 수도 거부당할 수도 있다. 안타깝게도 TCP 래퍼 라이브러리는 시스템 로드, 리소스 제한, 다중 어택 등에 대해서 잘 알지 못한다. Xinetd는 TCP 래퍼 기능을 (libwrap 라이브러리를 통해) 모아서, xinetd로 유연하게 전환할 수 있도록 하고 전과 동일한 설정 파일을 계속하여 사용한다.

마이그레이션은 쉽다. 기존의 hosts.deny와 hosts.allow 파일을 유지하면, xinetd는 그들을 따라온다. 하지만 TCP 래퍼를 발전시킨 커넥션 제어용 많은 옵션을 가지고 있다는 것을 명심해야 한다. 예를 들어, 초당 커넥션을 제한하거나 부하가 높을 때 커넥션을 제한하는 것은 서버 관리에 있어서 불필요한 도움이 될 수 있다.

반드시 libwrap 옵션으로 xinetd를 컴파일해야 한다. 그렇지 않으면 이것은 TCP 래퍼에 대해 알지 못한다 . xinetd가 레드햇 리눅스 상에서 RPM으로 부터 오면, 머신을 시작하기 전에 TCP wrapper 파일이 적절히 작동하는지 반드시 테스트를 해야한다.

위로

failover

xinetd가 사용에는 여러 방식이 있지만 리다이렉트 매개변수 (redirect parameter)는 특히 흥미롭다. 우리 모두가 알고있는 Failover는 실행시키기가 까다롭고 하드웨어 failover는 비싸다. 이 글에 설명된 접근방식은 싸고 효율적이다. 간단한 소프트웨어를 사용한다.

우선, "액티브" 머신을 선택한다. 이것을 set_active.pl 스크립트를 통해 수행할 것이라고 가정해 보자. 스크립트는 머신 이름을 취하는데 이것은 새로운 failover를 설정하기 위해 사용할 것이다. 또한 서비스 이름도 취하는 데 이것은 편집하기 위해서 알맞은 /etc/xinetd.d/SERVICE 파일을 우리에게 제공할 것이다. 다른 파일을 편집하거나 다른 매개변수를 취하기 위해 스크립트를 자유롭게 커스터마이징 할 수 있다.

매우 간단하다. 이제는 수동으로 또는 cron job을 통해서 또는 다른 프로그램에 의해서 이 스크립트를 호출하는 절차에 대해 결정하기만 하면 된다. 이 부분은 아키텍쳐가 결정해야 할 것이다. USR2 신호를 xinetd로 보내는 것을 잊지말라. 또는 원한다면 재시작 할 수 있다는 것도 기억하라. 신호를 자동화하는 것은 레드햇 리눅스의 경우 "pkill -USR2 xinetd"으로 수행될 수 있다. 그리고 xinetd를 재시작하는 것은 리눅스 또는 기타 유닉스 시스템에서는 "/etc/rc.d/init.d/xinetd restart" 이다.

이러한 종류의 failover는 데이터베이스 측에서 많은 추가 작업없이는 데이터베이스 연결을 위해서는 작동하지 않을 것이다. rsync, ssh, ftp, telnet과 같이 failover 머신이 서로서로 의존하지 않는 프로토콜에도 이것을 사용하는 것이 좋다.

위로

결론

분명, xinetd가 제공하는 많은 기능들이 있고 사용할 가치가 충분하다. xinetd의 유용성은 여기에 그치지 않는다: 버그는 보고되는 즉시 픽스되고, 소스 코드는 자유롭게 사용할 수 있으며, 기존의 inetd 설정 마이그레이션도 쉽다.

xinetd를 사용해보는 것이 어떤가? xinetd 소프트웨어는 솔라리스와 리눅스 서버에서 대중적으로 사용된다. 그래서 특정 플랫폼은 풀리지 않는 문제들을 가지고 있을 지도 모른다.

참고자료

• developerWorks worldwide 사이트에서 이 기사에 관한 영어원문.
  
  
• snetd tutorial : MacSecurity.org.
  
  
• developerWorks "Cultured Perl" 시리즈:
  • 프로그래머의 Linux 지향 설정
  • Perl로 애플리케이션 구성하기
  • Perl을 이용하여 유닉스 시스템 관리 자동화하기
  • Debugging Perl with ease
  • Cultured Perl: "JAPH"
  • Perl의 유전자 알고리즘
  • One-liners 개론
  • C와 Java 프로그래머를 위한 Perl
  • Perl로 Excel 파일 읽기/쓰기
  • Review of Programming Perl, Third Edition
  • Save it with Perl
  
  
  
• Linux resources: developerWorks.
  
  
• Open source resources: developerWorks.
  
  

필자소개

아티클 순위

의견

위로

목차

• 시스템 요구사항
• inetd
• xinetd
• TCP 래퍼 대체
• failover
• 결론
• 참고자료
• 필자소개
• 의견