길리랩blog

TCP Wrapper로 서비스별 네트워크 접근 제어하기

TCP Wrapper의 hosts.allow·hosts.deny 설정 방식과 libwrap.so, inetd·xinetd 연동을 통해 서비스별 네트워크 접근을 제어하는 방법을 정리한다.

2026-08-14 · 최초 발행 2025-08-10

서비스 접속 전에 적용되는 호스트 기반 제어

TCP Wrapper는 UNIX/Linux 시스템에서 사용하는 호스트 기반 네트워크 접근 제어 시스템이다. 애플리케이션 계층에서 동작하며, 특정 네트워크 서비스에 접속하려는 클라이언트를 호스트 이름, IP 주소, 네트워크 주소 기준으로 허용하거나 거부한다.

접근 제어는 libwrap.so 라이브러리를 통해 구현되며, 운영 규칙은 /etc/hosts.allow와 /etc/hosts.deny에 둔다. 서비스별로 서로 다른 규칙을 둘 수 있어 SSH나 FTP처럼 관리 범위를 나눠야 하는 환경에서 사용할 수 있다.

allow 규칙부터 평가하는 흐름

접속 요청이 들어오면 TCP Wrapper는 허용 규칙을 먼저 찾고, 일치하지 않을 때 거부 규칙을 확인한다. 두 파일 모두에서 일치하는 항목이 없으면 접속은 허용된다.

⤢✕일치불일치일치불일치클라이언트 접속 요청inetd/xinetdTCP Wrapper 호출hosts.allow 확인접속 허용hosts.deny 확인접속 거부접속 허용요청된 서비스 실행

이 순서는 정책 설계의 기준이 된다. 허용할 대상을 먼저 명시한 뒤 나머지를 거부하는 방식과, 대부분을 허용하고 일부만 차단하는 방식은 이 평가 순서를 바탕으로 구성한다.

라이브러리와 설정 파일이 맡는 역할

libwrap.so를 사용하는 서비스 확인

libwrap.so는 TCP Wrapper의 접근 제어 기능을 제공하는 핵심 라이브러리다. 서비스가 이 라이브러리를 사용해야 호스트 기반 제어를 적용할 수 있다.

다음 명령으로 SSH 서비스의 지원 여부를 확인할 수 있다.

ldd /usr/sbin/sshd | grep libwrap

출력에 libwrap.so가 보이면 해당 서비스는 TCP Wrapper를 지원한다.

hosts.allow에 두는 허용 대상

/etc/hosts.allow은 접속을 허용할 서비스와 호스트를 정의한다. 이 파일의 규칙과 일치한 요청은 즉시 허용된다.

# 모든 호스트에서 SSH 접속 허용
sshd: ALL
# 특정 IP 대역에서만 FTP 접속 허용
ftpd: 192.168.1.0/24
# 특정 호스트와 도메인에서 텔넷 접속 허용
telnetd: server1.example.com, .example.org

hosts.deny에서 차단하는 요청

/etc/hosts.deny는 hosts.allow에서 허용되지 않은 요청을 대상으로 거부 규칙을 적용하는 파일이다.

# 모든 서비스에 대해 모든 호스트 접속 거부
ALL: ALL
# 특정 IP에서의 모든 서비스 접속 거부
ALL: 10.0.0.5
# 특정 도메인에서의 FTP 접속 거부
ftpd: .malicious-domain.com

inetd와 xinetd의 연동

inetd는 여러 네트워크 서비스 요청을 관리하는 전통적인 UNIX 인터넷 서비스 데몬이다. 설정 파일은 /etc/inetd.conf이며, 요청이 들어오면 해당 서비스 프로그램을 실행한다. 이 과정에서 TCP Wrapper를 호출해 접근 제어를 수행한다.

xinetd는 inetd를 확장한 서비스 데몬이다. /etc/xinetd.conf와 /etc/xinetd.d/ 디렉토리에서 설정하며, 접근 제어·로깅·서비스별 설정 기능을 제공한다. 자체 접근 제어와 TCP Wrapper 연동을 함께 사용할 수 있다.

다음은 /etc/xinetd.d/telnet 설정 예시다.

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

규칙에 서비스와 클라이언트를 적는 방식

설정 파일은 서비스명과 클라이언트 목록을 기본 단위로 사용한다.

서비스명: 클라이언트_리스트 [: 옵션]

서비스명에는 sshd, ftpd, ALL 등을 쓸 수 있다. 클라이언트 목록은 허용하거나 거부할 대상을 지정하며, 옵션에는 로깅이나 명령 실행 같은 추가 동작을 둘 수 있다.

클라이언트는 다음과 같은 형식으로 표현한다.

  • ALL: 모든 호스트
  • LOCAL: 도메인 이름이 있는 로컬 호스트(FQDN에 점이 없는 호스트)
  • PARANOID: 호스트 이름과 주소가 일치하지 않는 호스트
  • IP 주소: 192.168.1.10
  • 네트워크 주소: 192.168.1.0/24
  • 호스트 이름: server1.example.com
  • 도메인 이름: .example.com
  • 패턴 매칭: 192.168.1.
  • A except B: A에서 B를 제외하며, 예시는 ALL except 192.168.1.5

허용 중심 정책과 차단 중심 정책

화이트리스트 정책은 기본적으로 모든 접근을 거부하고, 명시한 호스트에만 접속을 열어 둔다.

# /etc/hosts.deny
ALL: ALL

# /etc/hosts.allow
sshd: 192.168.1.0/24, .trusted-domain.com
ftpd: 10.0.0.5

블랙리스트 정책은 대부분의 접근을 허용한 상태에서 지정한 호스트만 거부한다.

# /etc/hosts.allow
ALL: ALL

# /etc/hosts.deny
sshd: .malicious-domain.com, 10.0.0.10
ftpd: 192.168.1.100

보안 관점에서는 허용 대상을 명시하는 화이트리스트 정책이 더 안전하며 권장된다.

관리 서비스별 규칙 예시

SSH 접속을 특정 IP 대역과 로컬 호스트로 제한하려면 다음처럼 설정할 수 있다.

# /etc/hosts.allow
sshd: 192.168.1.0/24 10.0.0.0/24 localhost

# /etc/hosts.deny
sshd: ALL

데이터베이스 서버에서는 접근 가능한 클라이언트를 서비스별로 좁힐 수 있다.

# /etc/hosts.allow
mysqld: 192.168.1.5 192.168.1.6 localhost
postgresql: 192.168.1.0/24 localhost

# /etc/hosts.deny
mysqld, postgresql: ALL

여러 서비스를 함께 운영할 때는 관리 도구, 웹 트래픽, FTP처럼 서로 다른 접근 범위를 한 정책에 둘 수 있다.

# /etc/hosts.allow
# 내부 네트워크에서만 웹 서버 관리 도구 접근 허용
webadmin: 192.168.0.0/16
# 모든 웹 트래픽 허용
httpd: ALL
# 관리자 워크스테이션에서만 FTP 접근 허용
ftpd: 192.168.1.10, 192.168.1.11

# /etc/hosts.deny
# 기본적으로 모든 서비스 접근 거부
ALL: ALL

적용 범위와 운영상 한계

TCP Wrapper는 설정 파일만 바꿔 도입할 수 있고, 별도 소프트웨어 없이 서비스별 세분화된 정책과 접근 시도 로깅을 구성할 수 있다. 설정 파일 변경 뒤 서비스 재시작이 필요 없다는 점도 운영상 장점이다.

반면 TCP Wrapper를 지원하는 서비스만 제어할 수 있으며, 패킷 내용을 기준으로 필터링하지는 못한다. 연결마다 설정 파일을 확인하므로 성능 오버헤드가 있고, 완전한 네트워크 보안 솔루션이나 방화벽의 대체 수단으로는 부족하다. 최신 시스템에서는 다른 보안 메커니즘으로 대체되는 추세다.

레거시 환경에서 함께 고려할 보안 계층

최신 Linux 배포판은 systemd 같은 시스템으로 전환하면서 TCP Wrapper의 비중이 줄어들었다. 레거시 시스템과의 호환성을 위해 여전히 지원되지만, 운영 환경에서는 다음 대체 기술과의 역할 구분이 필요하다.

  • 방화벽(firewalld, ufw, iptables): 더 강력한 패킷 필터링
  • SELinux/AppArmor: 애플리케이션 수준의 접근 제어
  • systemd 소켓 활성화: inetd/xinetd를 대체하는 서비스 관리
  • 애플리케이션 내장 보안: 애플리케이션이 자체적으로 제공하는 접근 제어

TCP Wrapper는 단독으로 완전한 보안을 제공하지는 않지만, 방화벽과 SELinux 같은 다른 보안 메커니즘을 조합하는 심층 방어 전략에서 간단한 호스트 기반 제어 계층으로 사용할 수 있다. 특히 레거시 시스템이나 특정 서비스에 대한 간단한 접근 제어가 필요한 환경에서는 여전히 활용할 수 있다.

TCP Wrapper네트워크 보안접근 제어LinuxUNIX