리눅스 네트워킹 및 보안

쑤욱가앗·2025년 10월 14일
CSlinux

Study

목록 보기
12/24

현대의 상호 연결된 디지털 환경에서 리눅스 서버의 안정성과 보안은 단일 기능이 아닌, 정확하게 구성된 여러 서비스 계층 위에 구축되는 포괄적인 상태를 의미한다. 웹 서버부터 클라우드 인프라에 이르기까지 핵심적인 시스템에서 리눅스의 사용이 보편화됨에 따라, 견고한 네트워크 관리 및 보안 구성은 더 이상 선택이 아닌 필수 요건이 되었다.  

기본 설정으로 방치되거나 부적절하게 구성된 서비스, 불필요하게 개방된 포트, 그리고 패치되지 않은 취약점들은 시스템에 심각한 공격 벡터를 제공한다.

가상 환경 네트워크 아키텍처

가상화 환경에서의 네트워크 모드 선택은 단순한 연결성 설정을 넘어, 가상 머신(VM)의 공격 표면을 결정하는 근본적인 보안 아키텍처 설계의 첫 단계이다. 각 모드는 VM의 네트워크 경계를 정의하며, 이에 따라 요구되는 보안 강화 수준이 달라진다.

가상 네트워크 어댑터 모드 분석

VMware, VirtualBox와 같은 가상화 플랫폼은 주로 세 가지의 네트워크 어댑터 모드를 제공하며, 각 모드는 고유한 아키텍처를 가진다.  

  • 브리지 모드(Bridged Mode): 이 모드는 VM의 가상 네트워크 어댑터를 호스트 시스템의 물리적 네트워크 어댑터에 직접 연결한다. 결과적으로 VM은 물리적 네트워크상에서 호스트와 동등한 하나의 독립된 장치처럼 동작한다. VM은 호스트와 동일한 네트워크 대역의 DHCP 서버로부터 IP 주소를 할당받으며, 외부 네트워크와의 양방향 통신이 자유롭게 가능하다.  

  • NAT(Network Address Translation) 모드: 이 모드에서 가상화 소프트웨어는 VM을 위한 가상 라우터 및 DHCP 서버 역할을 수행한다. VM은 이 가상 라우터로부터 사설 IP 주소를 할당받는다. 외부로 나가는 트래픽은 호스트 시스템의 IP 주소를 사용하여 주소 변환(NAT) 과정을 거치게 되며, 외부 네트워크로부터의 비요청 인바운드 연결은 기본적으로 차단된다.  

  • 호스트 전용 모드(Host-only Mode): 이 모드는 호스트 시스템과 그 위에서 실행되는 VM들만으로 구성된 완전히 격리된 가상 네트워크를 생성한다. 이 네트워크에 속한 VM들과 호스트는 서로 통신할 수 있지만, 외부 물리적 네트워크와는 어떠한 연결도 설정되지 않는다.  

네트워크 모드의 선택은 VM의 보안 경계를 설정하는 첫 번째 방어선이다.
브리지 모드는 보안의 책임을 전적으로 VM 자체에 부여하는 반면, NAT 모드는 호스트의 주소 변환 기능을 활용하여 기본적인 인바운드 차단 정책을 구현한다. 호스트 전용 모드는 물리적으로 분리된 네트워크(Air-gapped network)와 유사한 가상 환경을 구축하여 최대 수준의 격리를 보장한다. 이러한 관계를 이해하면, 후속 보안 강화 단계(예: firewalld 설정)가 브리지 모드에서 가장 중요하며, 호스트 전용 모드에서는 외부 위협에 대한 고려가 상대적으로 덜 필요하다는 점을 명확히 알 수 있다.

기능브리지 모드NAT 모드호스트 전용 모드
IP 주소 할당 주체물리적 네트워크 DHCP 서버가상화 소프트웨어 (가상 DHCP)가상화 소프트웨어 (가상 DHCP)
호스트-게스트 통신가능가능 (포트 포워딩 필요)가능
게스트-외부 통신양방향 가능단방향 (Outbound) 가능불가능
게스트-게스트 통신 (동일 호스트)가능가능가능
보안 수준낮음 (외부 노출)중간 (기본 인바운드 차단)높음 (외부와 격리)
주요 사용 사례공개 서버 운영일반 개발/테스트 환경격리된 랩, 보안 테스트

핵심 네트워크 서비스 관리

안정적인 서버 운영을 위해서는 네트워크 통신의 근간을 이루는 라우팅과 DNS 해석 메커니즘에 대한 깊이 있는 이해가 필수적이다. 최신 리눅스 배포판은 iproute2 패키지를 통해 이러한 핵심 서비스를 정교하게 제어할 수 있는 강력한 도구를 제공한다.

ip 명령어를 활용한 고급 라우팅 제어

iproute2 패키지에 포함된 ip 명령어는 ifconfig, route 등 기존의 레거시 네트워크 도구를 대체하는 현대적인 표준 유틸리티이다. ip 명령어는 네트워크 인터페이스, IP 주소, 라우팅 테이블 등 네트워크 스택의 거의 모든 측면을 관리할 수 있다.  

라우팅 테이블 분석

시스템의 라우팅 테이블은 ip route show 또는 단축 명령어인 ip r을 통해 확인할 수 있다. 라우팅 테이블은 커널이 네트워크 패킷을 어떤 경로로 전달할지 결정하는 규칙의 집합이다. 각 라우팅 항목은 다음과 같은 주요 필드로 구성된다.  

필드명설명예시 값
Destination목적지 네트워크 주소. default는 모든 주소를 의미한다.192.168.1.0/24
Gateway패킷을 전달할 다음 홉 라우터의 IP 주소. 0.0.0.0 또는 *는 게이트웨이가 없음을 의미한다.192.168.1.1
Genmask목적지 네트워크의 서브넷 마스크. ip 명령어 출력에서는 CIDR 표기법으로 통합된다.255.255.255.0
Flags경로의 속성을 나타내는 플래그. U (Up), G (Gateway), H (Host) 등이 있다.UG
Metric경로의 우선순위를 결정하는 비용 값. 값이 낮을수록 우선순위가 높다.100
Iface패킷을 내보낼 네트워크 인터페이스의 이름.eth0

라우팅 경로 조작

ip route 명령어를 사용하여 정적 라우팅 경로를 추가하거나 삭제할 수 있다.  

  • 특정 호스트로의 경로 추가:
    ip route add 192.168.100.10 via 192.168.1.1 dev eth0

  • 특정 서브넷으로의 경로 추가:
    ip route add 172.16.0.0/16 via 192.168.1.1

  • 기본 게이트웨이 설정:
    ip route add default via 192.168.1.1

  • 경로 삭제:
    ip route del 172.16.0.0/16

라우팅 테이블에서 metric 값은 동일한 목적지에 대해 여러 경로가 존재할 때 우선순위를 결정하는 중요한 역할을 한다. 가장 구체적인 경로(가장 긴 프리픽스 길이)가 먼저 선택되지만, 만약 두 개 이상의 경로가 동일한 구체성을 가질 경우(예: 두 개의 기본 게이트웨이), 커널은 metric 값이 더 낮은 경로를 우선적으로 사용한다. 이 원리를 활용하면, 시스템 관리자는 주 통신 회선에 연결된 인터페이스의 기본 경로에 낮은 metric 값을, 백업 회선에는 높은 metric 값을 설정하여 간단한 형태의 회선 이중화 및 자동 장애 조치(Failover)를 구현할 수 있다. 이는 라우팅 테이블의 기본 필드를 활용한 효과적인 트래픽 제어 기법이다.  

DNS 이름 해석 과정 및 설정 분석

도메인 이름을 IP 주소로 변환하는 DNS 이름 해석은 모든 네트워크 통신의 시작점이다. 현대 리눅스 시스템에서의 이 과정은 여러 구성 요소가 연계되어 동작하는 다단계 프로세스이다.

이름 해석 과정

  1. 애플리케이션이 gethostbyname()과 같은 라이브러리 함수를 호출하여 이름 해석을 요청한다.

  2. GNU C 라이브러리(glibc)는 /etc/nsswitch.conf 파일을 참조하여 이름 해석 서비스의 순서를 결정한다. 이 파일의 hosts: 라인에 정의된 순서(예: files resolve dns)에 따라 다음 단계가 진행된다.  

  3. files: 시스템은 가장 먼저 로컬의 /etc/hosts 파일을 확인하여 정적으로 정의된 매핑 정보가 있는지 검사한다.  

  4. resolve: nss-resolve 모듈이 활성화된 경우, 질의는 systemd-resolved 서비스로 전달된다. 이 서비스는 로컬 DNS 캐싱, DNSSEC 검증 등 고급 기능을 제공한다.  

  5. dns: systemd-resolved를 사용하지 않거나 해당 서비스에서 이름을 찾지 못한 경우, 시스템은 /etc/resolv.conf 파일에 지정된 DNS 서버로 직접 질의를 보낸다.  

/etc/resolv.conf의 역할 변화

과거 리눅스 시스템에서 /etc/resolv.conf 파일은 시스템이 사용할 DNS 서버의 IP 주소를 직접 명시하는 정적인 설정 파일이었다. 그러나 systemd-resolved가 도입된 최신 배포판에서는 이 파일의 역할이 크게 변경되었다. 현재 이 파일은 실제 DNS 서버 주소 대신, systemd-resolved가 로컬에서 운영하는 DNS 스텁 리졸버(stub resolver)의 주소인 127.0.0.53을 가리키는 심볼릭 링크인 경우가 많다. 실제 외부 DNS 서버 정보는 NetworkManager나 systemd-networkd와 같은 네트워크 관리 데몬이 DHCP를 통해 동적으로 수신하여 systemd-resolved 서비스 내부에서 관리한다.  

이러한 구조적 변화를 이해하지 못하고 구식 시스템처럼 /etc/resolv.conf 파일을 직접 수정하는 것은 흔한 관리 실수이다. 수동으로 변경된 내용은 네트워크 서비스가 재시작되거나 시스템이 재부팅될 때 네트워크 관리 데몬에 의해 자동으로 덮어쓰여지기 때문에, 변경 사항이 예고 없이 사라지는 문제를 야기한다. 따라서 영구적인 DNS 서버 설정을 위해서는 반드시 nmcli(NetworkManager), netplan(Ubuntu) 등 해당 배포판에서 사용하는 공식 네트워크 관리 도구를 통해 구성해야 한다. 이는 예측 가능하고 안정적인 시스템 운영을 위한 핵심적인 관리 원칙이다.  

OpenSSH 고급 활용 및 보안 강화

OpenSSH는 원격 시스템 관리를 위한 필수 도구이며, 단순한 원격 셸 기능을 넘어 강력한 보안 및 네트워크 제어 기능을 제공한다. 키 기반 인증과 터널링은 OpenSSH의 핵심 고급 기능이다.

키 기반 인증의 암호학적 원리 및 설정

SSH 키 기반 인증은 패스워드 인증 방식보다 월등히 높은 보안 수준을 제공하며, 비대칭 암호화(공개키 암호화) 원리에 기반한다.  

암호학적 원리: 챌린지-응답 메커니즘

인증 과정은 다음과 같은 챌린지-응답(Challenge-Response) 메커니즘을 통해 이루어진다.  

  1. 클라이언트는 서버에 접속을 시도하며, 인증에 사용할 공개키를 지정한다.

  2. 서버는 클라이언트 사용자의 홈 디렉터리에 있는 ~/.ssh/authorized_keys 파일에서 해당 공개키를 찾는다.

  3. 서버는 임의의 데이터로 구성된 '챌린지' 메시지를 생성한 후, 클라이언트의 공개키로 이를 암호화하여 클라이언트에게 전송한다.

  4. 오직 해당 공개키와 쌍을 이루는 개인키를 소유한 클라이언트만이 이 챌린지 메시지를 성공적으로 복호화할 수 있다.

  5. 클라이언트는 복호화된 챌린지와 현재 세션 ID 등을 조합하여 응답 값을 계산하고, 이를 서버로 다시 전송한다.

  6. 서버는 클라이언트가 올바른 응답을 보냈는지 확인하여, 개인키 소유를 증명한 클라이언트의 접속을 허용한다. 이 과정에서 개인키 자체는 절대로 네트워크를 통해 전송되지 않는다.

설정 절차

  1. 키 쌍 생성: 클라이언트 시스템에서 ssh-keygen 명령어를 사용하여 키 쌍을 생성한다. 보안 강화를 위해 RSA 4096비트 또는 Ed25519 알고리즘 사용이 권장된다.   

    ssh-keygen -t rsa -b 4096

  2. 공개키 서버 복사: ssh-copy-id 유틸리티를 사용하여 생성된 공개키를 원격 서버의 authorized_keys 파일에 안전하게 추가한다. 이 명령어는 필요한 디렉터리와 파일 생성 및 권한 설정을 자동으로 처리한다. 

    ssh-copy-id user@remote_host

  3. 권한 확인 및 설정: SSH 서버는 보안상의 이유로 홈 디렉터리, ~/.ssh 디렉터리, authorized_keys 파일의 권한이 과도하게 개방되어 있으면 키 기반 인증을 거부한다. 따라서 권한을 다음과 같이 정확하게 설정해야 한다.

    chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

  4. 서버 보안 강화: 서버의 /etc/ssh/sshd_config 파일을 수정하여 패스워드 기반 로그인을 비활성화하고 루트 계정의 직접적인 로그인을 금지한다. 이는 무차별 대입 공격(Brute-force attack)을 원천적으로 차단하는 매우 중요한 보안 조치이다.   

    PasswordAuthentication no
PermitRootLogin no

  5. SSH 서비스 재시작: 설정 변경 사항을 적용하기 위해 SSH 데몬을 재시작한다.

    sudo systemctl restart sshd

SSH 터널링을 이용한 네트워크 트래픽 제어

SSH 터널링(포트 포워딩)은 특정 TCP 포트의 네트워크 트래픽을 암호화된 SSH 연결 내부에 캡슐화하여 안전하게 전송하는 기술이다. 이를 통해 방화벽을 우회하거나 안전하지 않은 프로토콜을 보호할 수 있다.  

로컬 포트 포워딩 (-L)

로컬 포트 포워딩은 원격지에서만 접근 가능한 서비스를 로컬 시스템의 특정 포트에서 접근할 수 있도록 만들어준다. 연결은 클라이언트 측에서 시작된다.  

  • 구문: ssh -L [LOCAL_IP:]LOCAL_PORT:DESTINATION_HOST:DESTINATION_PORT user@SSH_SERVER

  • 활용 시나리오: 관리자가 자신의 로컬 PC에서 내부망에 위치한 데이터베이스 서버(db.internal, 포트 3306)에 접근해야 하는 상황을 가정한다. 데이터베이스 서버는 외부에서 직접 접근이 불가능하며, 오직 중간 경유 서버(Bastion Host, bastion.example.com)를 통해서만 접근할 수 있다.

    • 명령어: 관리자는 자신의 PC에서 다음 명령어를 실행한다.

      ssh -L 3306:db.internal:3306 user@bastion.example.com

      이후 로컬 PC의 데이터베이스 클라이언트에서 localhost:3306으로 접속하면, 모든 트래픽은 bastion.example.com을 통해 암호화되어 db.internal:3306으로 안전하게 전달된다.  

원격 포트 포워딩 (-R)

원격 포트 포워딩은 로컬 시스템에서 실행 중인 서비스를 원격 서버의 특정 포트를 통해 외부에서 접근할 수 있도록 노출시킨다. 리스닝 소켓이 원격 서버에 생성된다는 점에서 로컬 포트 포워딩과 반대 개념이다.  

  • 구문: ssh -R REMOTE_PORT:DESTINATION_HOST:DESTINATION_PORT user@SSH_SERVER

  • 활용 시나리오: 개발자가 방화벽으로 보호된 자신의 노트북에서 개발 중인 웹 애플리케이션(포트 8000)을 외부에 있는 동료에게 시연하고자 한다. 개발자는 공개적으로 접근 가능한 서버(public.example.com)에 SSH 접속 권한을 가지고 있다.

    • 명령어: 개발자는 자신의 노트북에서 다음 명령어를 실행한다.

      ssh -R 8080:localhost:8000 user@public.example.com

      이제 동료는 웹 브라우저에서 http://public.example.com:8080 으로 접속할 수 있으며, 이 트래픽은 SSH 터널을 통해 개발자의 노트북에 실행 중인 애플리케이션으로 전달된다. 이 기능을 외부 IP에서도 사용하려면 원격 서버의 /etc/ssh/sshd_config 파일에 GatewayPorts yes 옵션이 설정되어 있어야 한다.  

SSH 터널링은 단순한 원격 셸 접속 도구를 넘어, 필요에 따라 임시 보안 네트워크를 구성하고, 방화벽 정책을 안전하게 우회하며, 암호화 기능이 없는 레거시 프로토콜(예: VNC, FTP, 구형 데이터베이스 프로토콜)의 통신을 보호하는 다목적 네트워크 보안 도구로 활용될 수 있다.

예를 들어, 방화벽에서 VNC 포트(5901)를 직접 개방하는 대신 ssh -L 5901:localhost:5901 user@remote-host 명령을 사용하면, 로컬 VNC 클라이언트로 localhost:5901에 접속하는 것만으로 전체 VNC 세션을 암호화할 수 있다. 이는 별도의 VPN 설정 없이도 특정 서비스의 통신을 효과적으로 보호하는 유연한 방법을 제공한다.

시스템 시간 동기화 및 방화벽 정책

정확한 시간 정보와 견고한 방화벽 정책은 리눅스 서버 보안의 양대 축을 이룬다. 시간 동기화는 모든 시스템 활동 기록의 신뢰성을 보장하며, 방화벽은 외부로부터의 악의적인 접근을 차단하는 첫 번째 방어선 역할을 한다.

chrony를 이용한 정밀 시간 동기화

시스템 시간의 정확성은 보안 인증서의 유효성 검증, 로그 분석 시 이벤트 발생 순서 파악, 분산 시스템 간의 데이터 정합성 유지 등 시스템 전반에 걸쳐 매우 중요하다. RHEL 8 버전부터 기본 시간 동기화 도구로 채택된 chrony는 기존 NTP 데몬에 비해 더 빠르고 정확한 동기화 성능을 제공한다.  

설정 및 관리

  • 패키지 설치: chrony가 설치되어 있지 않은 경우, 각 배포판의 패키지 관리자를 이용해 설치한다.   

    # RHEL/CentOS 계열
sudo yum install chrony
# Debian/Ubuntu 계열
sudo apt install chrony

  • 서버 지정: /etc/chrony.conf 파일을 수정하여 동기화할 상위 NTP 서버를 지정한다. pool 지시어는 여러 서버 주소를 한 번에 지정하는 효율적인 방법이며, iburst 옵션은 초기 동기화 속도를 높여준다.   

    pool pool.ntp.org iburst

  • 서비스 관리: systemd를 통해 chronyd 서비스를 시작하고, 시스템 부팅 시 자동으로 실행되도록 활성화한다.   

    sudo systemctl start chronyd
sudo systemctl enable chronyd

상태 확인 및 진단

  • 전체 상태 확인: timedatectl status 명령어로 시스템의 시간, 시간대, NTP 동기화 활성화 및 성공 여부를 한눈에 파악할 수 있다.  

  • 동기화 상세 정보: chronyc tracking 명령어는 현재 동기화 기준이 되는 참조 서버, 스트라텀(Stratum) 수준, 시스템 시간의 오차 등 핵심 동기화 정보를 보여준다.  

  • 소스 상태 분석: chronyc sources -v 명령어는 chronyd가 연결을 시도하고 있는 모든 시간 소스의 상세한 상태를 출력한다. 이 출력은 시간 동기화 문제를 진단하는 데 매우 유용하다.  

firewalld를 이용한 동적 및 정교한 접근 제어

firewalld는 기존의 iptables 스크립트 방식보다 직관적이고 유연한 방화벽 관리 인터페이스를 제공하는 동적 방화벽 관리 데몬이다. 핵심적인 특징은 'Zone(영역)'이라는 개념을 통해 네트워크 인터페이스나 소스 IP 주소의 신뢰 수준에 따라 각기 다른 보안 정책을 적용하는 것이다.  

Zone 기반 관리

firewalld는 미리 정의된 여러 Zone을 제공하며, 각 Zone은 기본적인 허용/차단 정책을 내포하고 있다.  

  • public: 신뢰할 수 없는 공용 네트워크에 사용되는 기본 Zone으로, 선택된 연결만 허용한다.

  • internal: 내부 네트워크용으로, public Zone보다 상대적으로 더 많은 서비스를 신뢰한다.

  • dmz: 외부로 서비스를 제공해야 하지만 내부 네트워크와는 격리되어야 하는 서버(예: 웹 서버)를 위한 DMZ(Demilitarized Zone)용이다.

  • trusted: 해당 Zone에 속한 모든 트래픽을 허용한다. 매우 신뢰하는 환경에서만 제한적으로 사용해야 한다.

  • block / drop: 들어오는 모든 연결을 각각 거부(REJECT)하거나 무시(DROP)한다.

주요 관리 명령어

  • 활성 Zone 확인: firewall-cmd --get-active-zones

  • 기본 Zone 설정: firewall-cmd --set-default-zone=work

  • 인터페이스 Zone 할당: firewall-cmd --zone=internal --change-interface=eth1 --permanent  

  • 서비스 허용: firewall-cmd --zone=public --add-service=http --permanent  

런타임(Runtime)과 영구(Permanent) 설정

firewall-cmd로 적용된 변경 사항은 기본적으로 현재 실행 중인 런타임 환경에만 적용되며, 시스템 재부팅 시 사라진다. 변경 사항을 영구적으로 저장하려면 반드시 --permanent 옵션을 함께 사용해야 한다. 영구 설정이 적용된 후에는 firewall-cmd --reload 명령어를 실행하여 현재 실행 중인 방화벽에 새로운 규칙을 불러와야 한다.  

Rich Rule을 이용한 세부 정책 수립

Rich Rule은 단순한 서비스나 포트 허용을 넘어, 출발지/목적지 IP, 프로토콜, 로깅, 행위(accept/reject/drop) 등을 조합하여 매우 정교하고 조건부적인 규칙을 생성할 수 있는 강력한 기능이다. Rich Rule의 문법은 직관적이어서 복잡한 iptables 규칙을 직접 작성하는 것보다 오류 발생 가능성이 낮고 가독성이 높다.  

  • 특정 IP로부터의 SSH 접근 허용:

    firewall-cmd --zone=public --add-rich-rule='rule   family="ipv4" source address="203.0.113.5" service name="ssh"   accept' --permanent
  • 특정 서브넷의 Samba 접근을 거부하고 로그 남기기:
    firewall-cmd --zone=internal --add-rich-rule='rule  family="ipv4" source address="192.168.1.0/24" service  name="samba" log prefix="SAMBA_REJECT: " level="info" reject'  --permanent
  • 분당 5회로 새로운 SSH 연결 시도 제한 (Rate-limiting):
    firewall-cmd --zone=public --add-rich-rule='rule service  name="ssh" accept limit value="5/m"' --permanent

이처럼 Rich Rule은 복잡한 네트워크 보안 요구사항을 인간이 읽기 쉬운 형태로 표현할 수 있게 해주는 추상화 계층을 제공한다. 이는 방화벽 정책의 유지보수성을 향상시키고, 정교한 보안 정책을 보다 쉽게 구현할 수 있도록 돕는다.

profile
쑤욱가앗
Incident Response
이전 포스트

리눅스 시스템 동작 원리

다음 포스트

리눅스 시스템 유지보수

0개의 댓글