Xinetd에서의 Access Control에 대하여

시스템보안

Xinetd에서의 Access Control에 대하여

JustSangRok 2026. 6. 26. 15:50

실습 환경.

● CentOS 7 — xinetd는 최신 배포판에선 거의 사라져서 CentOS 환경을 사용하겠다.

Xinetd가 사라진 이유는 systemd로의 서비스 제어 통합과 하드웨어의 발전에 따른 시스템 자원의 여유 등이 있다.

1. 데몬이란?

데몬(daemon) 은 사용자가 직접 띄우지 않아도 백그라운드에서 돌면서 요청을 처리하는 프로세스다. 웹 서버, 데이터베이스, 메일 서버, SSH 서버 — 다 데몬이다.

이 데몬을 운영하는 방식에는 Standalone과 xinetd, 크게 두 가지가 있다.

구분	Standalone (독립 방식)	xinetd (슈퍼 데몬 방식)
데몬이 띄워져 있는 시점	항상 미리 띄워둠	요청이 올 때 그때 띄움
서비스 응답 속도	빠름	느림
메모리 사용	항상 차지	필요할 때만 차지
적합한 서비스	자주 호출되는 것	가끔 호출되는 것
대표 예시	httpd, sshd, named, sendmail	telnetd, ftpd, pop3d, tftpd

보면 서비스명 뒤에 d가 붙어있는 것을 볼 수 있는데 daemon을 뜻하는 것이라고 알고 있다. sendmail처럼 안붙어있는 것들도 있지만 대부분의 daemon 서비스는 뒤에 d가 붙어있다.

Standalone 방식

[Client] ──── 연결 ────► [httpd]  ← 항상 시간 메모리에 떠있음

서비스 데몬이 미리 띄워져 있으니까 요청 즉시 응답할 수 있다.

대신 메모리는 항상 차지한다.

자주 쓰는 서비스에 유리하다.

xinetd 방식

[Client] ──── 연결 ────► [xinetd]  ← 슈퍼 데몬만 떠있음
                            │
                            │ 요청이 오면 그때 fork
                            ▼
                         [telnetd] ← 이 시점에 실행

평소엔 슈퍼 데몬(xinetd)만 떠있다. 클라이언트 요청이 들어오면 그제서야 해당 서비스 데몬을 실행해서 처리한다.

메모리는 절약되지만 응답이 살짝 늦다.

가끔 쓰는 서비스에 유리하다.

요즘은 xinetd 자체가 거의 사라졌다. 최신 배포판들은 systemd의 socket activation 기능으로 같은 일을 처리한다. xinetd 패키지조차 기본 저장소에 없는 경우가 많다.

설정 파일 위치

방식 설정 파일 위치

Standalone (systemd)	/usr/lib/systemd/system/<서비스>.service (패키지 제공) /etc/systemd/system/<서비스>.service (관리자 정의)
xinetd	/etc/xinetd.conf (글로벌 설정) /etc/xinetd.d/<서비스> (서비스별 설정)

CentOS 7에서 찾아보니 /etc/init.d가 보이던데, 이건 SysV init 시절의 잔재라고 한다. CentOS 7부터는 systemd가 표준이고, systemctl로 관리하는 게 정석이다.

2. xinetd, 실습 Service 설치

CentOS 7은 이미 서비스가 종료되어서 공식 저장소에서 패키지를 받을 수 없다.

그래서 ISO/DVD를 직접 마운트해서 RPM을 가져오는 방식으로 설치한다.

mount /dev/cdrom /mnt
cd /mnt/Packages

여기서 필요한 RPM들을 직접 설치한다.

# 슈퍼 데몬 자체
rpm -i xinetd-2.3.15-13.el7.x86_64.rpm

# 실습용 서비스 — telnet
rpm -i telnet-server-0.17-64.el7.x86_64.rpm    # 서버 데몬
rpm -i telnet-0.17-64.el7.x86_64.rpm           # 클라이언트 도구

# 실습용 서비스 — ftp
rpm -i vsftpd-3.0.2-25.el7.x86_64.rpm          # 서버 데몬
rpm -i ftp-0.17-67.el7.x86_64.rpm              # 클라이언트 도구

xinetd가 깔리면 글로벌 설정 파일을 확인할 수 있다.

cat /etc/xinetd.conf

여기엔 기본 설정만 들어있고, 각 서비스별 설정은 /etc/xinetd.d/ 디렉터리 안에 파일로 분리되어 있다.

3. xinetd telnet 서비스 등록

/etc/xinetd.d/telnet 파일을 만들어서 telnet 서비스를 xinetd 아래로 등록한다.

cd /etc/xinetd.d
vi telnet

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

옵션 하나씩 풀어보자.

옵션	의미
disable	no면 서비스 활성화, yes면 비활성화
flags = REUSE	소켓 재사용 허용 (포트가 TIME_WAIT 상태여도 바로 다시 listen 가능)
socket_type	stream = TCP, dgram = UDP
wait	no = 멀티 스레드 (연결마다 fork), yes = 싱글 스레드 (하나 처리하고 끝날 때까지 대기)
user	서비스를 실행할 사용자 (telnetd는 root로 실행해야 함)
server	실제 실행될 서비스 데몬 경로
log_on_failure	로그인 실패 시 기록할 항목. USERID는 시도한 사용자 이름

wait 옵션

wait = no는 "기다리지 않는다" = 연결이 들어올 때마다 새 프로세스를 fork해서 동시에 여러 연결을 처리한다는 뜻이다. TCP 서비스의 표준.

반대로 wait = yes는 "기다린다" = 하나 띄우고 그게 끝날 때까지 다음 연결을 안 받는다. UDP나 동시 처리가 필요 없는 서비스에서 쓴다.

wait를 안 한다 = 여러 개 동시 처리 로 알아두면 된다.

xinetd 재시작

서비스 파일을 만들었으면 xinetd를 재시작해서 설정을 읽어들이게 해야 한다.

systemctl restart xinetd

xinetd를 재시작하면 등록된 모든 서비스가 같이 재시작된다. 운영 중인 다른 xinetd 서비스가 있다면 잠깐 끊긴다.
이게 xinetd가 가진 단점 중 하나이기도 하다.

4. xinetd로 vsftpd 띄우기

ftp도 같은 방식으로 등록할 수 있는데, vsftpd 자체 설정에서 설정해야 충돌이 안 난다.

vi /etc/vsftpd/vsftpd.conf

여기서 다음 두 줄을 모두 NO로 바꿔준다.

listen=NO
listen_ipv6=NO

이게 왜 필요한가?

listen=YES  → vsftpd가 자체적으로 21번 포트에서 listen
              (standalone 모드)
              
listen=NO   → vsftpd가 listen을 안 함
              (xinetd가 소켓을 받아서 vsftpd에게 넘겨주는 inetd 모드)

xinetd가 21번 포트를 잡고 있는 상태에서 vsftpd도 21번을 잡으려고 하면 충돌난다. 그래서 vsftpd의 자체 listen을 꺼서 xinetd가 받은 연결을 그대로 vsftpd로 넘기는 구조로 만들어야 한다.

그 다음 xinetd 서비스 파일을 만든다.

vi /etc/xinetd.d/ftp

service ftp
{
        disable      = no
        flags        = REUSE
        socket_type  = stream
        wait         = no
        user         = root
        server       = /usr/sbin/vsftpd
        log_on_failure += USERID
}

systemctl restart xinetd

이제 telnet과 ftp가 둘 다 xinetd 아래로 운영된다.

5. xinetd 자체에서 Access Control

xinetd는 PAM과는 별개의 레이어에서 자체적인 접근 제어를 제공한다.

no_access  =        ← IP or Domain Name 차단
only_from  =        ← IP or Domain Name 허용

두 옵션이 충돌하면 일반적으로 deny가 우선하지만, 정확한 규칙은 더 좁은 범위(more specific) 규칙이 우선 이다.

같은 specificity면 deny가 우선.

1) 네트워크 단위 차단

CIDR 표기로 네트워크 대역을 통째로 차단할 수 있다.

no_access = 192.168.10.0/24      # 10.0~10.255 전체 차단
no_access = 192.168.10.0/25      # 10.0~10.127 차단
no_access = 192.168.10.128/25    # 10.128~10.255 차단

이런 식으로 서브넷 마스크를 이용해서 대역 차단을 할 수도 있다.

2) 호스트 단위 차단

특정 호스트만 차단할 수 있다.

no_access = 192.168.10.250

# 여러 개를 공백으로 구분
no_access = 192.168.10.150 192.168.10.50

3) 화이트리스트

only_from을 쓰면 화이트리스트 방식이 된다.

only_from = 192.168.10.250

이렇게 적으면 192.168.10.250만 접속 허용, 그 외 모든 호스트는 차단된다.

4) 두 정책이 충돌시

no_access = 192.168.10.250
only_from = 192.168.10.250

이렇게 같은 IP를 양쪽 모두에 적으면 차단이 우선된다. xinetd는 충돌 시 안전한 쪽(deny)을 택한다.

좀 더 복잡한 케이스도 있다.

only_from = 192.168.10.0/24      # 10.x 대역 전체 허용
no_access = 192.168.10.250       # 10.250 한 명만 차단

이건 더 좁은(more specific) 규칙이 우선되니까, 192.168.10.0/24 안의 호스트는 모두 허용되지만 192.168.10.250만 차단된다.

6. 동시 접속 / 속도 제한

xinetd는 자원 제한도 자체적으로 걸 수 있다.

cps         = 50 10      # 초당 50개 요청 초과 시 10초간 서비스 중지
instances   = 50         # 최대 동시 실행 가능 서비스 수
per_source  = 10         # 한 IP에서 동시에 열 수 있는 연결 수

옵션별 의미.

● cps = 50 10 — Connections Per Second. 초당 50개의 connection까지 허용하고, 그 이상으로 들어오면 10초간 서비스 중지. DoS 방어 역할

● instances = 50 — 동시에 떠있을 수 있는 서비스 데몬의 최대 수. 51번째 요청이 오면 거부됨

● per_source = 10 — 같은 IP 주소에서의 동시 연결 상한. 한 사용자/봇이 자원을 독점하는 걸 막음

이런 자원 옵션들은 대부분 DOS 공격의 방어 기제들이다.

7. 시간 기반 통제

서비스를 특정 시간대에만 허용할 수 있다.

vi /etc/xinetd.d/telnet

access_times = 15:38-15:39

이러면 telnet 서비스가 15시 38분부터 15시 39분 59초까지만 접속을 받는다. 그 외 시간엔 차단된다.

여러 구간을 공백으로 이어 적을 수도 있다.

access_times = 09:00-12:00 13:00-18:00

오전 9시~정오, 오후 1시~6시만 허용. 점심시간(12:00-13:00)에는 차단되는 구조다. 업무 시간 외 접근을 막는 패턴으로 유용하다.

같은 분을 시작-끝으로 잡으면 항상 차단된다.

access_times = 21:18-21:18    # 0분 동안만 허용

access_times는 분 단위가 최소 정밀도다. 시작 시각과 끝 시각이 같으면 허용 시간이 0분이라 그 분의 1초도 통과 못 한다. 나는 이렇게 하면 1분 허용되는 줄 알았는데 무한통제였다. 이 방법으로는 1분만 허용은 불가능하다.

8. xinetd의 동작 흐름

마지막으로 xinetd가 어떻게 이 모든 통제를 가능하게 하는지 흐름을 정리한다.

Standalone 방식의 흐름

서비스 데몬이 직접 listen하고 요청도 직접 처리한다. 통제도 서비스 데몬 자체의 설정에서 한다.

xinetd 방식의 흐름

핵심은 xinetd가 먼저 받아서 검사한 뒤, 통과한 연결만 실제 서비스 데몬에게 넘기는 구조다. 그래서 xinetd 단에서 거는 통제는 서비스 데몬에 도달하기도 전에 차단할 수 있다. 더 빠르고 자원 소모도 적다.

같은 시스템에 두 개의 접근통제 레이어가 동시에 동작하는 셈이다.

[Client] → [xinetd 통제] → [서비스 데몬] → [PAM / 서비스 자체 통제]
              ↑                                      ↑
        IP, 시간, 자원 단위                   사용자, 그룹, 비밀번호 단위

이런 식으로 시스템 자체에 도달하기까지 여러 겹의 방어막이 있다.

'시스템보안' 카테고리의 다른 글

Metasploit을 사용한 Scan, Brute Force Attack에 대하여 (0)	2026.07.02
티렉터리, 파일에서의 권한 관리에 대하여 (0)	2026.06.29
FTP에서의 Access Control에 대하여 (0)	2026.06.25
시스템 내부에서의 Ping 차단에 대하여 (0)	2026.06.25
ftp, telnet, ssh에서의 사용자 Access Control에 대하여 (0)	2026.06.23

현재글Xinetd에서의 Access Control에 대하여

평범한 정보보안 이야기

보안전문가 되기

Ai, It, nmap, 정보보안, 파티션 분할, 리버싱, 리눅스, claude, 네트워크 보안, ADsP, 해킹, 자격증, wireshark, 보안, Mythos,

Today :
Yesterday :

평범한 정보보안 이야기