'''xined FAQ 번역''' ---- 원문 : http://www.xinetd.org/faq.html ---- [[TableOfContents]] ---- === xinet란? === xinetd는 inetd를 대체하는 인터넷 서비스 데몬입니다. === 나는 시스템 관리자가 아닙니다. inetd 대체에 신경 쓸 필요 없지요? === xinetd는 단순히 inetd를 대체하는 것만이 아닙니다. xinetd에서는 설정 파일 내의 서비스가 꼭 /etc/services에 있어야 하는 게 아니기에, 어떤 사용자든 xinetd를 이용해 특권(역주: 1024 이하의) 포트를 필요로 하지 않는 서버를 실행할 수 있습니다. === inetd와 호환 됩니까? === 아니오. 이것의 설정 파일은 inetd와는 다른 형식을 가집니다. 그리고 시그널을 다르게 인식합니다. 그러나 신호에 대한 행동의 할당을 바꿀 수 있고, inetd.conf를 xinetd.conf로 변환하는 프로그램이 포함되어 있습니다. === 왜 이것을 사용해야 합니까? === 왜냐하면 이것은 (제 소견으로는) inetd 보다 더 좋기 때문입니다. 여기 그 이유가 있습니다. * 다음 사항들을 바탕으로 모든 서비스에 대해 접근 제어가 가능합니다. a. 원격 호스트의 주소 a. 접근 시간 a. 원격 호스트의 이름 a. 원격 호스트의 도메인 네임 * 접근 제어는 다중 스레드와 단일 스레드에 관계없이, TCP 및 UDP 프로토콜 모두에서 모든 서비스에 대해 동작합니다. 모든 TCP 연결뿐 아니라 모든 UDP 패킷들을 검사할 수 있습니다. * 확실한 재설정을 제공합니다. a. 더 이상 설정 파일에 없는 서비스에 대한 서버들을 죽입니다. a. 더 이상 접근 제어 규칙을 만족하지 않는 서버들을 죽입니다. * 다음 방법으로 접근거부 공격을 막을 수 있습니다. a. 각 서비스에 대한 서버 개수에 제한을 두기 (프로세스 테이블 오버플로우를 피합니다) a. 프로세스가 fork할 수 있는 횟수에 제한을 두기 a. 생성하는 로그 파일의 크기에 제한을 두기 a. 하나의 호스트가 만들 수 있는 연결의 개수에 제한을 두기 a. 들어오는 연결의 속도에 제한을 두기 a. 부하가 지정한 제한을 넘어갈 경우 서비스를 중지하기 * 광범위한 로그 남기기 능력: a. 동작시킨 모든 서버에 대해 다음을 로그로 남길 수 있습니다. i) 서버 시작 시간[[BR]] ii) 원격 호스트 주소[[BR]] iii) 원격 사용자(다른 끝단에서 RFC-931/RFC-1413 서버를 실행하는 경우)[[BR]] iv) 서버가 얼마동안 실행되고 있는지[[BR]] (i, ii, iii에서는 실패한 시도까지도 남길 수 있습니다.) a. 어떤 서비스에 대해 접근 제어가 실패하면, 시도가 이뤄진 접근에 대한 정보를 남길 수 있습니다. (예를 들면 rsh서비스의 경우 사용자 이름과 명령을 남길 수 있습니다.) * 서버 전달 인자의 제한이 없습니다. * 당신의 호스트 장치에서 특정 서비스를 특정 IP에 지정할 수 있습니다. === 이 프로그램에 대해 누구에게 감사/비난 해야 하나요? === [mailto:panos@cs.colorado.edu]가 이 프로그램의 원래 저자이지만, 현재 제([mailto:bbraun@synaok.net])가 버그 리포트를 받고 있습니다. === xinetd의 2.2.1 버전은 무엇이 좋아졌나요? === xinetd의 원래 최신 버전은 2.1.1과 2.1.8까지 올릴 수 있는 패치들입니다. Nick Hilliard가 Panos의 발표되지 않은 xinetd 2.2.0을 기반으로 해서 xinetd 2.2.1은 만들었습니다. xinetd에 포함된 저작권 문서에서는 xinetd의 공식판(이 경우 2.1.8)이 지켜야 할 버전 규칙을 명시하였는데, 덧붙인 네 번째 버전 번호는 변경 수준(modification level)을 나타냅니다. 이것은 제가 채택한 버전 규칙입니다. 여기에 있는 xinetd 2.1.8.X는 xinetd 2.2.0이나 그 상위 버전을 기반으로 하지 않습니다. 이것은 2.1.8의 코드 기반을 가지고 작성한 것입니다. 다만 xinetd-2.2.1에서 도입한 몇 가지 기능들을 재구현 하기는 했습니다. === 어디서 최신이자 최고의 버전을 찾을 수 있나요? === xinetd 소스는 [http://www.synack.net/xinetd]에서 얻을 수 있습니다. === xinetd를 가지고 qmail이 동작하도록 한 사람 없나요? === 있습니다, 여기 기본 정보가 있습니다. {{{ service smtp { flags = REUSE NAMEINARGS socket_type = stream protocol = tcp wait = no user = qmaild server = /usr/sbin/tcpd server_args = /var/qmail/bin/tcp-env -R /var/qmail/bin/qmail-smtpd } }}} Antony Abby씨가 제공해 주셨습니다. 이 방법으로 `/etc/hosts.allow`에서 환경 변수와 이것저것들을 설정할 수 있습니다. xinetd를 libwrap 지원을 포함해서 컴파일 할 수 있기는 하지만, 이는 tcpd의 기능을 완벽하게 대신할 수 있다는 뜻은 아닙니다. xinetd는 `host_access(5)` 맨페이지에서 설명하는 접근 제어를 수행하는 `host_access()`를 호출합니다. 이것은 tcpd가 제공하는 기능들 중 일부입니다. === xinetd가 동작한다고 알려진 플랫폼은 무엇입니까? === 저는 솔라리스 2.6(sparc와 x86), 리눅스, !BSDi, 그리고 IRIX 5.3과 6.2에서 실행해 봤습니다. 원본 패키지는 !SunOS 4와 Ultrix에서 동작했습니다. === 서비스에 대해 chroot 환경은 어떻게 설정하나요? === 여기 간단한 설정 파일이 있습니다. {{{ service telnet_chroot { log_on_sucess = HOST PID DURATION USERID log_on_failure = HOST RECORD USERID no_access = 152.30.11.93 socket_type = stream protocol = tcp port = 8000 wait = no user = root server = /usr/sbin/chroot server_args = /var/public/servers /usr/libexec/telnetd } }}} lburns@sasquatch.com이 제공해 주셨습니다. === itox는 어떻게 사용하나요? === itox는 표준 입력으로 올바른 inetd.conf를 읽어서 표준 출력으로 xinetd.conf를 기록합니다. 일반적으로 다음 명령을 사용합니다. {{{ itox < /etc/inetd.conf > /etc/xinetd.conf }}} inetd.conf에서 각 데몬들에 대해 명시적인 경로가 없다면 ''-daemon_dir'' 옵션을 사용해야 합니다. 모든 데몬들이 /usr/sbin에 있다고 하면, 다음 명령을 사용하면 됩니다. {{{ itox -daemon_dir=/usr/sbin < /etc/inetd.conf > /etc/xinetd.conf }}} itox는 좀 오래 되었고 한동안 갱신하지를 않았습니다. xconv.pl은 펄 스크립트로, 최근의 inetd.conf 파일을 변환하는 데 있어 좀 더 낫습니다. 사용법은 itox와 비슷합니다. === xinetd는 libwrap (tcpwrappers)를 지원합니까? === 예. `configure` 스크립트 옵션으로 `--with-libwrap` 을 전달하여 xinetd가 libwrap을 지원하도록 컴파일 할 수 있습니다. libwrap 지원을 포함해서 xinetd를 컴파일 하면 모든 서비스들이 `/etc/hosts.allow` 및 `/etc/hosts.deny` 방식의 접근 제어를 사용할 수 있습니다. 또한 전통적인 inetd 방식으로 tcpd를 사용하도록 xinetd를 구성해 줄 수도 있습니다. 이는 NAMEINARGS 플래그 사용을 필요로 하며, 실제 데몬의 이름는 server_args로 전달해 주어야 합니다. 여기 tcpd로 텔넷을 사용하는 예제가 있습니다. {{{ service telnet { flags = REUSE NAMEINARGS protocol = tcp socket_type = stream wait = no user = telnetd server = /usr/sbin/tcpd server_args = /usr/sbin/in.telnetd } }}} === xinetd는 IPv6를 지원합니까? === 예. `configure` 스크립트에 `--with-inet6` 옵션을 추가하여 xinetd가 IPv6를 지원하도록 컴파일 할 수 있습니다. IPv6에서도 접근 제어가 동작합니다. 접근 제어에서 ipv4로 사상된 주소를 사용할 수도 있고, 보통의 점으로 분리된 ipv4 주소를 사용할 수도 있으며, xinetd가 이것들을 ipv6 주소로 사상해 줄 것입니다. === IPv6 서비스가 시작이 안 됩니다! 어떻게 하죠? === IPv6 지원을 포함해서 컴파일 하게 되면 모든 소켓들이 IPv6 소켓입니다. 당신의 커널이 IPv6 소켓이 뭔지 이해하지 못한다면 소켓을 생성하려는 모든 시도가 실패할 것이고, 어떤 서비스도 시작이 안 될 것입니다. 커널이 IPv6를 지원하는 경우에만 xinetd를 IPv6 지원으로 컴파일 하십시오. === setgroups(0, NULL) 오류는 무엇입니까? === 기본적으로 xinetd는 서버 프로세스들에 대한 그룹 권한을 허용하지 않으며, 이는 자식 프로세스의 그룹을 빈값(nothing)으로 설정하는 방식으로 이뤄집니다. 어떤 BSD는 이와 관련해 문제가 있습니다. 이 오류를 피하려면 당신의 서비스에 `groups = yes`라는 지시자를 넣으면 됩니다. 이는 서버 프로세스가 동작중인 사용자와 동등하게 모든 그룹 권한을 서버 프로세스가 가질 수 있도록 해줍니다. === 왜 리눅스에서 teletd가 정상적으로 실행되지 않습니까? === 몇몇 리눅스 배포판들에서는 권한 없는 사용자로 텔넷 데몬을 시작합니다. 대신 그 사용자는 새로운 tty를 열고 utmp를 수정할 수 있는 그룹에 소속되어 있습니다. 기본적으로 xinetd는 서버 프로세서에 그룹 권한을 허용하지 않으며, 따라서 telnetd가 올바르게 시작하지 못할 수 있습니다. 서버 프로세스가 올바른 그룹을 갖추도록 하려면 텔넷 서비스에 `groups = yes` 지시자를 사용하면 됩니다. 이는 xinetd에게 사용자가 포함된 모든 그룹을 갖추고 서버 프로세스를 시작해도 괜찮다는 것을 알려줍니다. === xinet를 이용해서 서비스를 SSL로 감싸려면 어떻게 해야 되나요? === 서비스를 SSL로 감싸려면 [http://web.archive.org/web/20040608061630/www.stunnel.org/ stunnel] 프로그램을 사용하세요. 이건 inetd를 통해 실제로 사용할 수 있습니다. === cvs 서버를 xinetd에 어떻게 설정합니까? === 어떤 사용가 다음 제안을 썼습니다. {{{ cvpserver stream tcp nowait root /usr/bin/cvs cvs --allow-root=/home/pauljohn/cvsroot --allow-root=/home/pauljohn/cvsmisc pserver }}} xinetd 하에서도 같은 작업을 해주려면 /etc/xinetd.d에 cvspserver라는 설정 파일을 저장하세요. (마지막 줄은 당신의 저장소들의 이름을 말해줍니다.) {{{ service cvspserver { socket_type = stream protocol = tcp wait = no user = root passenv = server = /usr/bin/cvs server_args = --allow-root=/home/pauljohn/cvsroot --allow-root=/home/pauljohn/cvsmisc pserver -f } }}} 기타 cvs 설정 내용들은 모두 같습니다. 이건 제가 아는 한 동작하는 것 같습니다. === 관련 자료 === * http://www.xinetd.org/ ---- [CategorySoftware]