13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[태그:] nftables

  • [Linux] 리눅스 서버 네트워크 연결 장애: IP 설정부터 방화벽까지 디버깅 5단계

    [Linux] 리눅스 서버 네트워크 연결 장애: IP 설정부터 방화벽까지 디버깅 5단계

    목차

    [리눅스] 리눅스 서버 네트워크 연결 장애: IP 설정부터 방화벽까지 디버깅 5단계

    리눅스 네트워크 장애는 평소엔 조용하다가 꼭 바쁠 때 터지더라고요. SSH는 안 붙고, 서비스 Health Check(헬스 체크, 상태 확인)는 빨갛게 뜨고, 팀 메신저에는 왜 서버가 안 되냐는 메시지가 쌓입니다. 저도 홈랩이랑 운영 서버를 만지면서 비슷한 상황을 정말 많이 겪었는데, 처음엔 케이블 문제인가 싶었는데, 실제로는 리눅스 IP 설정 하나가 꼬였던 적도 있었고, 반대로 IP는 멀쩡한데 iptables(아이피테이블스, 리눅스 패킷 필터) 규칙 때문에 통신이 막힌 적도 많았어요.

    그래서 오늘은 제가 실제로 쓰는 기준으로 리눅스 네트워크 장애를 좁혀 가는 5단계 디버깅 흐름을 정리해보겠습니다. 무작정 재부팅부터 하는 게 아니라, 아래에서 위로 차근차근 확인하는 방식이죠. 특히 Ubuntu 계열에서 자주 쓰는 netplan(넷플랜, 네트워크 설정 추상화 도구), systemd-networkd(시스템디 네트워크 관리 데몬), 그리고 방화벽 쪽의 nftables(엔에프테이블스, 최신 패킷 필터 프레임워크)까지 같이 보겠습니다.

    리눅스 네트워크 장애 점검 순서를 보여주는 전체 흐름도

    리눅스 서버에서 링크 상태, IP 설정, 라우팅, DNS, 방화벽 순서로 점검하는 전체 디버깅 흐름을 보여주는 개요 이미지입니다.

    리눅스 네트워크를 층으로 나눠 봐야 하는 이유

    쉽게 말해 네트워크 장애는 한 덩어리가 아니라 여러 층으로 나뉘어 있거든요. 물리 링크가 살아 있는지, 인터페이스가 Up(업, 활성화) 상태인지, IP가 붙었는지, 기본 게이트웨이(Default Gateway, 기본 경로)가 맞는지, 이름 해석 DNS가 되는지, 마지막으로 방화벽이 막고 있지는 않은지요. 여기서 중요한 포인트는 위 증상만 보고 아래 원인을 단정하면 삽질이 길어진다는 점입니다.

    제가 직접 해보니 제일 효율적인 방법은 이렇더라고요. 1단계에서 링크와 인터페이스를 확인하고, 2단계에서 리눅스 IP 설정을 보고, 3단계에서 라우팅과 DNS를 확인한 뒤, 4단계에서 netplan과 systemd-networkd를 보고, 마지막 5단계에서 iptables 또는 nftables를 점검하는 겁니다. 이 순서대로 보면 원인 범위가 빠르게 줄어들어요.

    리눅스 네트워크 장애 디버깅 5단계

    1단계. 링크 상태와 인터페이스 확인 (제일 많이 놓치는 부분)

    제일 먼저 보는 건 케이블, 가상 NIC, 스위치 포트, 인터페이스 상태입니다. 이 단계에서 해결되는 경우가 생각보다 많더라고요. 특히 VM(가상머신)에서는 가상 스위치 설정이, 베어메탈에서는 포트 비활성화가 원인일 때가 꽤 있거든요.

    ip link show
ip -br link
ethtool eth0

    여기서 보는 포인트는 간단해요.

    1. 인터페이스 상태가 UP인지 확인하세요.
    2. LOWER_UP 표시가 있는지 봐야 합니다. 이게 없으면 링크 자체가 안 잡힌 경우가 많거든요.
    3. ethtool로 Speed(속도), Duplex(이중화 모드), Link detected 여부를 봅니다.

    예를 들어 인터페이스가 내려가 있으면 이렇게 올릴 수 있어요.

    sudo ip link set eth0 up

    별거 아닌 것 같지만, 저도 예전에 테스트하다가 인터페이스를 내려놓고 그대로 잊어버려서 한참 헤맨 적이 있습니다. 진짜 허무했어요 ㅎㅎ

    2단계. 리눅스 IP 설정 확인

    다음은 IP 주소, 서브넷 마스크(Subnet Mask, 네트워크 범위 정보), DHCP(디에이치씨피, 자동 IP 할당) 여부를 확인하는 거예요. 여기서 리눅스 IP 설정이 의도와 다르게 잡혀 있으면 외부 통신이 바로 꼬입니다.

    ip addr show
ip -br addr
hostname -I

    출력에서 확인할 것은 아래입니다.

    • 예상한 인터페이스에 IP가 붙었는지
    • 대역이 맞는지 예: 192.168.10.0/24
    • 중복 IP 가능성은 없는지
    • DHCP로 받아야 하는 서버인데 주소가 비어 있지는 않은지

    Ubuntu 서버에서 netplan을 쓴다면 설정 파일은 보통 이렇게 생겨요.

    network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: false
      addresses:
        - 192.168.10.20/24
      routes:
        - to: default
          via: 192.168.10.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8

    설정 반영은 아래처럼 하면 됩니다.

    sudo netplan generate
sudo netplan apply

    처음엔 이게 뭔가 싶었는데, YAML(야믈, 들여쓰기 기반 설정 형식) 들여쓰기 하나만 틀려도 적용이 안 되더라고요. 그래서 저는 반영 전에 꼭 눈으로 한 번 더 봅니다.

    리눅스 IP 설정과 netplan 점검 장면

    netplan YAML 설정과 ip 명령 결과를 나란히 확인하는 실전 점검 장면을 담은 이미지입니다.

    3단계. 라우팅과 DNS 확인

    IP가 붙어 있어도 목적지로 가는 길이 없으면 통신이 안 되거든요. 그래서 라우팅 테이블(Route Table, 경로 정보)과 DNS를 따로 봐야 합니다. 이 구간에서 많이들 헷갈리세요. 핑은 IP로 되는데 도메인은 안 된다면 DNS 쪽일 가능성이 높고, 같은 대역은 되는데 외부가 안 된다면 기본 게이트웨이 문제일 가능성이 커요.

    ip route show
ip route get 8.8.8.8
ping -c 4 192.168.10.1
ping -c 4 8.8.8.8
getent hosts example.com
resolvectl status

    제가 주로 이렇게 해석하더라고요.

    증상 가능성 높은 원인 우선 확인할 것
    게이트웨이 핑 실패 L2 링크, VLAN, 잘못된 IP 케이블, 스위치, 인터페이스 상태
    외부 IP 핑 실패 기본 라우트 누락, 업스트림 차단 ip route, 게이트웨이
    도메인만 실패 DNS 설정 오류 nameserver, resolvectl
    특정 포트만 실패 방화벽 또는 서비스 미기동 ss, iptables, nftables

    여기서 중요한 포인트! DNS 문제를 네트워크 전체 장애로 오해하는 경우가 정말 많아요. 실제로 써보니까 IP 통신과 이름 해석을 분리해서 보는 습관이 장애 시간을 많이 줄여줍니다.

    4단계. netplan, systemd-networkd 로그 확인

    설정 파일이 맞아 보여도 실제 적용 과정에서 실패할 수 있거든요. 특히 cloud-init(클라우드이닛, 초기 인스턴스 설정 도구)와 netplan이 같이 엮인 환경에서는 예상과 다르게 덮어써지는 경우도 있어요.

    networkctl status eth0
systemctl status systemd-networkd
journalctl -u systemd-networkd --no-pager
sudo netplan try

    netplan try는 꽤 유용하더라고요. 원격 서버에서 네트워크 설정 바꿀 때 잘못 적용하면 SSH가 끊길 수 있거든요. 이 명령은 일정 시간 안에 확인하지 않으면 롤백되는 방식이라 조금 더 안전합니다.

    저도 홈랩에서 라우트를 바꾸다가 접속이 끊겨서 콘솔로 다시 들어간 적이 몇 번 있어요. 그 뒤로는 원격 작업에서는 무조건 보수적으로 갑니다. 가능하면 콘솔 접근 경로를 하나 확보하고 작업하시길 권장합니다.

    리눅스 네트워크 장애 원인을 systemd-networkd 로그로 분석하는 모습

    systemd-networkd 상태 출력과 journal 로그를 보며 적용 실패 원인을 찾는 디버깅 장면입니다.

    5단계. iptables, nftables, 서비스 포트 확인

    마지막 단계는 방화벽과 리스닝 포트(Listening Port, 대기 중인 서비스 포트)예요. 여기까지 왔는데도 통신이 안 되면, 사실 방화벽일 때가 꽤 많습니다. 특히 오래된 서버는 iptables를, 최근 배포판은 nftables를 쓰는 경우가 많아서 둘 다 확인해야 헷갈리지 않아요.

    sudo iptables -L -n -v
sudo iptables -S
sudo nft list ruleset
ss -tulpn

    체크 포인트는 이렇습니다.

    • INPUT 체인 기본 정책이 DROP인지
    • SSH, HTTP, HTTPS 등 필요한 포트 허용 규칙이 있는지
    • 서비스가 실제로 해당 포트에서 listen 중인지
    • iptables와 nftables가 혼재되어 정책을 헷갈리게 만들고 있지는 않은지

    예를 들어 SSH 22/tcp가 막혀 있으면 서버는 살아 있어도 접속이 안 돼요. 반대로 방화벽은 열려 있는데 서비스가 안 떠 있으면 역시 안 되죠. 그래서 저는 항상 패킷 필터와 서비스 포트를 같이 봅니다.

    ⚠️ 실제로 자주 겪는 트러블슈팅 포인트

    여기서는 제가 삽질 좀 했던 사례를 중심으로 적어보겠습니다. 혹시 이런 경험 있으신가요? 겉으로는 리눅스 네트워크 장애처럼 보이는데, 실제 원인은 아주 사소한 설정 하나인 경우 말입니다.

    1. YAML 들여쓰기 오류
      netplan은 형식이 엄격해요. 공백 수가 틀리면 적용이 실패하거나 의도와 다르게 해석됩니다.
    2. 인터페이스 이름 혼동
      예전엔 eth0로 익숙했는데, 환경에 따라 ens18, enp1s0처럼 다르게 보여요. 설정 파일과 실제 NIC 이름이 다르면 당연히 안 붙습니다.
    3. 기본 라우트 누락
      같은 대역 통신만 되고 외부가 안 되는 전형적인 증상이죠.
    4. DNS 서버 미설정
      핑은 되는데 apt 업데이트나 도메인 접근이 안 됩니다.
    5. 방화벽 정책 잔존
      이전 작업에서 넣어둔 DROP 규칙이 그대로 남아 있는 경우가 있더라고요.

    이런 문제를 줄이려면 변경 전후 비교가 중요합니다. 저는 보통 현재 상태를 먼저 저장해 둬요.

    ip addr show
ip route show
resolvectl status
sudo iptables -S
sudo nft list ruleset

    그리고 변경 후에는 꼭 다시 비교합니다. 이 습관이 쌓이면 리눅스 네트워크 디버깅 속도가 확실히 빨라집니다.

    검증 방법: 어디까지 확인해야 정말 해결된 걸까요?

    설정만 반영됐다고 끝이 아닙니다. 리눅스 네트워크 장애는 재현이 사라진 것처럼 보여도 실제 서비스 경로가 여전히 막혀 있을 수 있거든요. 그래서 저는 최소한 아래 검증은 꼭 합니다.

    1. 게이트웨이 핑 확인
    2. 외부 IP 핑 확인
    3. 도메인 이름 해석 확인
    4. 필요 포트 접속 확인
    5. 서비스 로그와 클라이언트 관점 확인
    ping -c 2 192.168.10.1
ping -c 2 8.8.8.8
getent hosts example.com
curl -I http://example.com
nc -zv 127.0.0.1 22

    여기까지 다 통과하면 거의 끝입니다. 드디어 됐다! 싶은 순간이 오죠. 다만 운영 환경이라면 여기서 한 번 더, 다른 서버나 사용자 위치에서 역방향 확인도 해보시는 걸 권장합니다. 서버 안에서만 되는 경우가 있거든요.

    리눅스 네트워크 장애 복구 후 검증 화면

    ping, curl, 포트 체크 결과가 정상으로 돌아온 모습을 한눈에 보여주는 검증 이미지입니다.

    정리 표: 단계별 점검 포인트 한 번에 보기

    단계 확인 명령 핵심 질문
    1. 링크 ip link, ethtool 인터페이스와 물리 링크가 살아 있나?
    2. IP ip addr 리눅스 IP 설정이 맞게 붙었나?
    3. 라우팅/DNS ip route, getent, resolvectl 길이 있나? 이름 해석이 되나?
    4. 설정 적용 netplan, networkctl, journalctl 설정이 실제로 반영됐나?
    5. 방화벽/포트 iptables, nft, ss 패킷과 서비스 포트가 열려 있나?

    이 표만 머릿속에 넣어두셔도 현장에서 꽤 도움이 됩니다. 특히 초반에 당황해서 이것저것 동시에 건드리기 시작하면 원인 추적이 더 어려워져요. 순서대로, 하나씩, 확인한 사실만 쌓아가는 게 제일 빠릅니다.

    리눅스 네트워크 장애 5단계 디버깅 요약 인포그래픽

    링크, IP, 라우팅, 설정 적용, 방화벽 점검 순서를 한 장으로 요약한 체크리스트 이미지입니다.

    마무리: 리눅스 네트워크 장애는 감으로 풀기보다 순서로 푸는 게 낫습니다

    오늘 정리한 흐름의 핵심은 단순합니다. 리눅스 네트워크 장애가 생기면 링크, IP, 라우팅, DNS, 설정 적용, 방화벽 순서로 보자는 거예요. 저도 처음엔 여기저기 막 건드렸는데, 실제로 써보니까 장애 대응에서 제일 중요한 건 화려한 명령어보다 점검 순서였습니다.

    특히 netplan과 systemd-networkd를 쓰는 환경에서는 설정 파일과 적용 로그를 같이 봐야 하고, 구형 환경이나 혼재된 환경에서는 iptables와 nftables를 둘 다 체크해야 합니다. 이 부분만 익숙해져도 리눅스 네트워크 디버깅이 훨씬 덜 막막해집니다.

    다음 글에서는 tcpdump(티씨피덤프, 패킷 캡처 도구)로 패킷 흐름을 직접 보면서 원인을 좁히는 방법도 다뤄보겠습니다. 이전 글에서 다뤘던 홈랩 VLAN 구성 글이 있다면 같이 보셔도 흐름 이해에 도움이 됩니다. 현장에서 바로 써먹을 수 있는 기준으로 계속 정리해보겠습니다.

    자주 묻는 질문

    Q1. ping은 되는데 웹 접속만 안 되면 어디부터 봐야 하나요?

    A. 보통은 서비스 포트와 방화벽을 먼저 봅니다. ss -tulpn으로 리스닝 여부를 확인하고, 그다음 iptables 또는 nftables 규칙을 점검해보세요.

    Q2. netplan apply 전에 더 안전한 방법이 있나요?

    A. 원격 서버라면 netplan try를 먼저 권장합니다. 잘못 적용돼도 자동 롤백되는 흐름이라 실수 비용이 줄어듭니다.

    Q3. DNS 문제와 라우팅 문제는 어떻게 구분하나요?

    A. IP로는 되는데 도메인만 안 되면 DNS 문제일 가능성이 커요. 반대로 외부 IP 자체가 안 되면 라우팅이나 게이트웨이를 먼저 보시면 됩니다.

  • [보안] 리눅스 서버 하드닝 전략 재점검 체크리스트

    [보안] 리눅스 서버 하드닝 전략 재점검 체크리스트

    목차

    리눅스 서버 하드닝 전략 재점검 체크리스트

    요즘 보안 메일함 열어보면 심장이 조금 빨리 뛰죠. 특히 리눅스 서버 하드닝 관점에서 보면, 커널과 사용자 공간(User space, 커널 밖에서 도는 일반 프로세스) 취약점 공지가 꽤 자주 올라옵니다. 저도 홈랩이랑 운영 서버를 같이 굴리다 보니, 처음엔 “요즘 왜 이렇게 Linux CVE가 많아졌지?” 싶었거든요. 그런데 실제로 뜯어보니, 단순히 숫자만 늘었다기보다 공개 체계가 더 촘촘해진 부분, 그리고 실제로 빨리 패치해야 하는 취약점이 섞여 있더라고요.

    특히 2024년 2월 13일에 kernel.org가 CVE Numbering Authority(CNA, CVE 번호 발급 권한 기관)로 추가된 뒤부터는 Linux 커널 취약점에 CVE가 더 체계적으로 붙기 시작했습니다. 거기에 CISA가 실제 악용 사례가 있는 Linux kernel 취약점들을 Known Exploited Vulnerabilities(KEV) 목록에 올리면서, “아, 이건 숫자 구경만 할 게 아니구나” 싶었거든요. 리눅스 보안은 결국 패치 속도만의 문제가 아니라, 노출면(Attack Surface, 공격 가능 면적)을 줄이는 운영 습관의 문제이기도 합니다.

    리눅스 서버 하드닝 전체 구조를 보여주는 아키텍처 이미지

    커널, SSH, 방화벽, MAC 정책, 패치 자동화, 검증 흐름까지 한눈에 보여주는 개요 이미지입니다.

    1. 최근 Linux CVE가 많이 보이는 이유부터 정리해보겠습니다

    쉽게 말해, 요즘 보이는 “급증”은 두 가지가 섞여 있습니다. 발견과 공개가 더 적극적이 된 점, 그리고 실제 운영자가 체감할 정도로 대응 압박이 커진 점이 같이 온 겁니다.

    구분 무슨 뜻인가 운영자가 봐야 할 포인트
    CVE 공개 체계 변화 kernel.org가 2024-02-13부터 CNA 역할 수행 이전보다 커널 취약점이 더 잘 드러날 수 있음
    실제 악용 사례 CISA가 Linux kernel CVE를 KEV에 추가 패치 우선순위를 높게 잡아야 함
    자동화된 버그 탐지 fuzzing과 정적/동적 분석이 더 활발 작은 버그도 더 빨리 공론화됨

    여기서 중요한 포인트가 있습니다. CVE 숫자가 늘었다 = 리눅스가 갑자기 위험해졌다로 바로 연결하면 좀 단순합니다. 제가 직접 홈랩 커널 업데이트 흐름을 따라가 보니까, 예전엔 배포판 공지 뒤에 숨어 지나가던 수정이 이제는 CVE로 더 명확하게 드러나는 경우도 꽤 있더라고요. 반대로, KEV에 들어간 건 진짜 우선순위가 다릅니다. 이건 “나중에 점검”이 아니라 즉시 확인 쪽입니다.

    2. 리눅스 서버 하드닝 체크리스트, 우선순위는 이렇게 잡으시면 됩니다

    저는 보통 패치, 접근 통제, 권한 축소, 관측성 순으로 봅니다. 이유는 간단하거든요. 멋진 보안 솔루션보다 먼저, 뚫릴 구멍을 줄이는 게 훨씬 싸고 빠릅니다.

    1. 커널과 패키지 업데이트 기준선 만들기: 지금 어떤 커널을 쓰는지, 보안 업데이트가 몇 건 밀렸는지 숫자로 확인합니다.
    2. SSH 노출면 줄이기: 비밀번호 로그인, root 직접 로그인, 불필요한 포트 노출을 먼저 줄입니다.
    3. 방화벽 기본 정책 정리: 허용 목록(Allowlist, 허용 대상만 열기) 방식으로 바꿉니다.
    4. SELinux/AppArmor 같은 MAC 적용: 뚫려도 옆으로 번지는 걸 막습니다.
    5. systemd sandboxing: 서비스 단위로 권한을 더 잘게 자릅니다.
    6. 감사 로그와 검증 루틴: 적용 후 확인하지 않으면 하드닝이 아니라 기분만 좋아지는 설정이 됩니다.

    3. 실전 구현 1단계: 패치 상태와 커널 노출 범위부터 확인합니다

    처음엔 이게 뭔가 싶었는데, 결국 출발점은 단순합니다. 무엇이 돌아가고 있는지 알아야 CVE 대응도 빠릅니다. 아래 명령은 제가 새 서버 잡으면 거의 습관처럼 먼저 칩니다.

    uname -r
cat /etc/os-release
ss -tulpn
systemctl --failed

    uname -r은 현재 커널 버전, ss -tulpn은 외부에 열려 있는 포트와 프로세스를 같이 보여줍니다. 여기서 예상 밖 포트가 보이면, 그 서버는 이미 서버 보안 강화 대상입니다.

    Debian/Ubuntu 계열이면 보안 업데이트 확인은 이렇게 시작하시면 됩니다.

    sudo apt update
apt list --upgradable
sudo unattended-upgrades --dry-run -d

    RHEL 계열은 보통 이렇게 봅니다.

    sudo dnf check-update
sudo dnf updateinfo list security

    Ubuntu를 쓰신다면 Livepatch(재부팅 없이 일부 커널 보안 수정 적용)도 검토할 만합니다. 다만 Canonical 문서 기준으로 Livepatch만 믿고 장기간 재부팅을 미루면 안 됩니다. 지원되는 커널 ABI 범위와 재부팅 주기가 따로 있거든요. 실제로 써보니까 편하기는 한데, 이것도 결국 정식 커널 교체를 완벽히 대체할 수는 없더라고요.

    4. 실전 구현 2단계: SSH와 네트워크부터 조입니다

    제가 제일 먼저 손대는 부분입니다. CVE가 터졌을 때 제일 아쉬운 서버가 어떤 서버냐 하면, 패치가 늦은 서버보다도 불필요하게 다 열어둔 서버더라고요. 삽질 좀 했습니다 ㅎㅎ

    sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%F)
sudoedit /etc/ssh/sshd_config

    PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
AllowUsers adminops

    적용 전에는 반드시 문법 검사를 하세요.

    sudo sshd -t && sudo systemctl reload sshd

    방화벽은 nftables 기준으로 아주 단순하게 시작하는 편이 좋습니다.

    sudo mkdir -p /etc/nftables
sudoedit /etc/nftables.conf

    #!/usr/sbin/nft -f
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority 0;
    policy drop;
    iif lo accept
    ct state established,related accept
    tcp dport { 22, 80, 443 } accept
    ip protocol icmp accept
    ip6 nexthdr icmpv6 accept
  }

  chain forward {
    type filter hook forward priority 0;
    policy drop;
  }

  chain output {
    type filter hook output priority 0;
    policy accept;
  }
}

    sudo nft -f /etc/nftables.conf
sudo nft list ruleset
sudo systemctl enable --now nftables
    리눅스 서버 하드닝에서 SSH와 방화벽 정책을 설명하는 이미지

    SSH 접근 제한, 허용 포트 최소화, 상태 기반 방화벽 정책을 시각적으로 보여주는 이미지입니다.

    5. 실전 구현 3단계: SELinux, AppArmor, systemd sandboxing으로 한 번 더 막습니다

    Mandatory Access Control(MAC, 강제 접근 통제)은 초반엔 귀찮아 보여도, 사고 났을 때 진짜 값어치를 합니다. Red Hat 문서도 SELinux를 추가 보안 계층으로 설명하고 있고, Ubuntu 문서도 AppArmor를 경로 기반 MAC으로 안내합니다. 쉽게 말해 프로세스가 원래 해야 할 일만 하게 만드는 장치입니다.

    RHEL 계열에서는 SELinux 상태를 먼저 확인하세요.

    getenforce
sestatus
sudo setenforce 1

    Ubuntu 계열에서는 AppArmor 상태를 확인합니다.

    sudo apparmor_status
sudo aa-enforce /etc/apparmor.d/*

    그리고 요즘 제가 자주 같이 보는 게 systemd-analyze security입니다. 서비스별 노출 점수를 빠르게 볼 수 있어서, 감으로 하드닝하는 느낌이 훨씬 줄어들더라고요.

    sudo systemd-analyze security nginx.service

    서비스 오버라이드(override)로 샌드박싱을 추가하는 예시는 아래처럼 시작하시면 됩니다.

    sudo systemctl edit nginx.service

    [Service]
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes
PrivateDevices=yes
RestrictSUIDSGID=yes
LockPersonality=yes
MemoryDenyWriteExecute=yes
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
SystemCallArchitectures=native

    sudo systemctl daemon-reload
sudo systemctl restart nginx
sudo systemd-analyze security nginx.service

    이거 실제로 써보니까 꽤 좋더라고요. 다만 여기서 중요한 건, 서비스별로 필요한 권한이 다르다는 점입니다. DB나 백업 에이전트는 너무 세게 조이면 바로 깨집니다.

    6. 커널 노출면 줄이는 sysctl과 감사 로그도 같이 가야 합니다

    리눅스 서버 하드닝에서 빠지기 쉬운 게 커널 파라미터와 로그입니다. 공격 자체를 막는 것도 중요하지만, 이상 징후를 빨리 보는 것도 중요하거든요.

    sudoedit /etc/sysctl.d/99-hardening.conf

    net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.tcp_syncookies = 1
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
fs.protected_symlinks = 1
fs.protected_hardlinks = 1

    sudo sysctl --system

    감사 로그(audit log)도 최소한은 잡아두는 편이 좋습니다.

    sudo apt install auditd -y || sudo dnf install audit -y
sudo systemctl enable --now auditd

    sudo auditctl -w /etc/ssh/sshd_config -p wa -k ssh_config_change
sudo auditctl -w /etc/sudoers -p wa -k sudoers_change
sudo auditctl -w /usr/bin/sudo -p x -k sudo_exec

    여기서 정말 중요한 포인트예요. 로그는 쌓는 것보다 어떤 이벤트를 보면 위험 신호로 판단할지가 더 중요합니다. SSH 설정 변경, sudo 실행 급증, 예상하지 못한 서비스 재시작 같은 건 바로 알아채야 하거든요.

    리눅스 서버 하드닝에서 SELinux AppArmor 시스템 샌드박싱을 보여주는 이미지

    프로세스 권한 최소화와 서비스 격리를 여러 층으로 적용하는 장면을 표현한 이미지입니다.

    7. ⚠️ 실제로 자주 겪는 문제와 트러블슈팅

    하드닝은 설정 넣는 순간보다, 그 뒤에 안 깨지게 만드는 과정이 더 어렵습니다. 저도 처음엔 자신 있게 적용했다가 웹 서비스가 파일 못 읽어서 502 띄운 적 있습니다.

    • SELinux/AppArmor 적용 후 서비스 장애: 먼저 비활성화하지 말고 로그를 봅니다. SELinux는 /var/log/audit/audit.log, AppArmor는 journalctl -xe나 /var/log/syslog 쪽부터 확인하세요.
    • systemd sandboxing 후 서비스 기동 실패: ProtectSystem=strict, ProtectHome=yes가 자주 원인입니다. 서비스가 실제로 써야 하는 경로를 ReadWritePaths=로 열어줘야 할 수 있습니다.
    • SSH 설정 변경 후 원격 접속 끊김: 운영 중인 세션을 유지한 상태에서 새 세션으로 테스트하고, 가능하면 콘솔 접근 수단을 남겨두세요.
    • 방화벽 적용 후 내부 통신 장애: 모니터링, 백업, 노드 간 헬스체크 포트를 빼먹는 경우가 많습니다. 홈랩에서 Kubernetes 올릴 때 저도 이걸로 반나절 썼습니다.

    그래서 저는 항상 한 번에 다 바꾸지 않고, 서비스 하나씩 묶어서 적용합니다. 보안 체크리스트는 체크만 하면 끝나는 문서가 아니라, 배포 순서를 정리하는 운영 문서여야 하더라고요.

    8. 검증, 결과 확인, 그리고 다음 단계

    설정이 들어갔으면 반드시 검증해야 합니다. 아래 정도는 최소 루틴으로 가져가면 좋습니다.

    1. 커널/패키지 버전 확인: 패치 적용 전후 버전 차이를 기록합니다.
    2. 포트 노출 재검사: ss -tulpn 결과를 저장해 비교합니다.
    3. 서비스 샌드박스 점검: systemd-analyze security로 전후 점수를 비교합니다.
    4. 로그 확인: SELinux/AppArmor 거부 로그, audit 로그, 인증 로그를 같이 봅니다.
    5. 재부팅 리허설: 커널 업데이트 후 서비스가 정상 복구되는지 꼭 확인합니다.
    uname -r
ss -tulpn
sudo systemd-analyze security
sudo journalctl -p warning -b
sudo ausearch -k ssh_config_change

    제가 직접 해보니 가장 효과가 큰 건 화려한 솔루션이 아니라 패치 기준선 + SSH 제한 + 방화벽 기본 거부 + MAC + 서비스 샌드박스 이 5개였습니다. 드디어 됐다! 싶은 순간이 오긴 오는데, 사실 그 뒤가 더 중요합니다. 운영 환경은 계속 바뀌니까요.

    리눅스 서버 하드닝 적용 전후 결과를 보여주는 검증 이미지

    적용 전후 비교 결과를 대시보드 형태로 보여주는 검증 이미지입니다.

    정리: 지금 바로 다시 볼 체크포인트

    • 리눅스 서버 하드닝은 CVE 개수보다 노출면 축소가 핵심입니다.
    • kernel.org CNA 전환과 실제 악용 사례 공개를 보면, 공개량 증가와 실제 위험 신호를 구분해서 봐야 합니다.
    • CVE 대응은 패치만이 아니라 SSH, nftables, SELinux/AppArmor, systemd sandboxing까지 묶어서 봐야 합니다.
    • 검증 없는 하드닝은 절반짜리입니다. 적용 후 로그와 서비스 상태를 꼭 확인하세요.

    다음 글에서는 systemd 서비스별 하드닝 템플릿을 좀 더 깊게 다뤄볼 예정입니다. 이전 글에서 다뤘던 로그 수집 파이프라인이 있으시면 그쪽과 묶어서 보셔도 좋고요.

    패치, 접근 통제, MAC, 샌드박스, 로그 검증을 우선순위별로 정리한 요약 이미지입니다.

    참고한 공개 자료

  • [Linux] iptables에서 nftables로 전환: 레거시 방화벽 마이그레이션 가이드

    [Linux] iptables에서 nftables로 전환: 레거시 방화벽 마이그레이션 가이드

    목차

    [Linux] iptables에서 nftables로 전환: 레거시 방화벽 마이그레이션 가이드

    리눅스 서버를 오래 운영하다 보면 방화벽 규칙이 점점 덕지덕지 붙는 순간이 오더라고요. 저도 홈랩과 실서버를 같이 굴리면서 iptables nftables 전환 작업을 몇 번 했었는데, 처음엔 “굳이 잘 돌아가는 걸 왜 바꿔?” 싶었어요. 근데 규칙이 늘어나고, IPv4와 IPv6를 따로 관리하고, 서비스별 예외가 계속 생기기 시작하면 이야기가 확 달라져요. 그때부터는 레거시 방화벽 구조가 발목을 잡기 시작하거든요. 이번 글에서는 iptables에서 nftables로 전환할 때 어떤 흐름으로 접근하면 덜 고생하는지, 제가 직접 해보며 삽질했던 포인트까지 묶어서 정리해보겠습니다.

    특히 이 글은 새로운 방화벽을 처음 설계하는 분보다는, 이미 운영 중인 규칙을 가진 상태에서 nftables 마이그레이션을 고민하는 분들께 맞춰 썼습니다. “규칙은 많은데 서비스 중단은 싫다”, “iptables-save 출력은 복잡한데 어떻게 옮겨야 할지 모르겠다” 같은 상황이 딱 여기에 해당합니다.

    iptables nftables 전환 아키텍처를 보여주는 리눅스 방화벽 마이그레이션 이미지

    레거시 체인과 테이블이 nftables의 통합 규칙셋으로 재구성되는 흐름을 보여주는 개요 이미지입니다.

    왜 지금 iptables에서 nftables로 전환해야 할까요

    쉽게 말해, nftables는 Linux 커널의 Netfilter(넷필터, 리눅스 패킷 필터링 프레임워크) 위에서 동작하는 더 현대적인 규칙 관리 방식이에요. 예전에는 iptables, ip6tables, arptables, ebtables처럼 도구가 나뉘어 있었는데, nftables 쪽은 이걸 훨씬 일관되게 다룰 수 있게 정리해둔 느낌이 강합니다.

    제가 직접 운영하면서 체감한 장점은 크게 세 가지였어요. 첫째, 규칙 표현이 훨씬 읽기 좋습니다. 둘째, IPv4와 IPv6를 한 구조 안에서 관리하기가 정말 편해요. 셋째, 집합(Set, 셋)과 맵(Map, 매핑) 같은 기능을 활용하면 반복 규칙이 크게 줄어듭니다. 예전엔 포트 하나 열 때마다 규칙을 늘어놓았는데, nftables에서는 묶어서 다루니까 관리가 훨씬 편하더라고요.

    항목 iptables nftables
    규칙 구조 테이블/체인/룰이 분산되어 장황해지기 쉬움 문법이 비교적 일관적이고 집합 활용이 쉬움
    IPv4/IPv6 관리 보통 분리 관리 inet 패밀리로 통합 관리 가능
    변환 도구 기존 자산 많음 iptables-translate 같은 변환 도구 활용 가능
    장기 운영성 레거시 환경과의 호환성은 좋음 새 규칙 설계와 정리에 유리

    여기서 중요한 포인트가 하나 있어요. iptables를 무조건 즉시 버리라는 뜻은 아닙니다. 실제 운영에서는 배포판 기본값, 커널 버전, 시스템 서비스와의 연동 방식까지 같이 봐야 하거든요. 다만 새로 정리할 기회가 있다면 nftables 쪽이 구조적으로 훨씬 낫다는 건 분명해요.

    iptables에서 nftables로 전환 전에 꼭 확인할 체크리스트

    저도 처음엔 규칙부터 바꾸려고 달려들었는데, 나중에 보니 그게 제일 위험한 접근이었어요. 리눅스 방화벽 교체 전에 아래 항목부터 확인하는 게 훨씬 안전합니다.

    1. 현재 규칙 백업
      현재 적용된 IPv4/IPv6 규칙을 반드시 저장합니다.
    2. 원격 접속 경로 확인
      SSH 관리 포트가 어디서 열려 있는지 먼저 확인합니다. 이거 놓치면 진짜 난감해집니다.
    3. 배포판의 기본 방화벽 스택 확인
      일부 환경은 iptables 명령이 내부적으로 nft 백엔드를 쓰기도 해요. 헷갈리기 쉬운 부분이죠.
    4. 자동 시작 서비스 확인
      재부팅 후 `nftables.service` 또는 배포판별 방화벽 서비스가 어떤 규칙을 로드하는지 봐야 합니다.
    5. 롤백 경로 준비
      문제가 생기면 바로 이전 규칙으로 되돌릴 방법을 준비해둡니다.

    예를 들어 현재 규칙 백업은 이렇게 해두면 돼요.

    sudo iptables-save > /root/iptables-backup.rules
sudo ip6tables-save > /root/ip6tables-backup.rules

    그리고 nftables 쪽 현재 상태도 함께 확인해보세요.

    sudo nft list ruleset

    출력이 비어 있더라도 괜찮습니다. 중요한 건 지금 시스템이 무엇을 기준으로 패킷을 처리하는지 감을 잡는 거예요.

    nftables 개념, 쉽게 말해 이렇게 이해하면 됩니다

    저도 처음엔 `table`, `chain`, `hook` 같은 용어가 한꺼번에 나와서 좀 헷갈렸는데요. 쉽게 말해 이렇습니다.

    • Table(테이블): 규칙을 묶는 큰 서랍이에요.
    • Chain(체인): 실제 패킷이 지나가며 검사되는 규칙 목록입니다.
    • Hook(훅): 커널 네트워크 경로의 어느 지점에서 체인을 실행할지 정하는 연결점입니다.
    • Set(셋): IP, 포트 같은 값을 묶어 재사용하는 구조예요.

    iptables에서는 INPUT, OUTPUT, FORWARD 체인 중심으로 익숙해져 있다 보니 nftables 문법이 낯설게 느껴지는데, 구조를 이해하고 나면 오히려 더 명확합니다. 특히 `inet` 패밀리를 쓰면 IPv4와 IPv6 규칙을 함께 다룰 수 있어서, 실무에서 규칙 중복이 많이 줄어들어요.

    레거시 규칙을 그대로 옮기기보다 재설계가 필요한 이유

    이 부분이 꽤 중요합니다. iptables-translate는 분명 유용한 도구입니다. 하지만 “기계적으로 변환된 규칙 = 가장 좋은 nftables 규칙”은 아니더라고요. 번역은 되는데, 구조가 지저분하게 남는 경우가 많아요. 그래서 저는 보통 이렇게 접근합니다. 먼저 변환 도구로 초안을 만들고, 그다음 사람이 읽기 좋은 구조로 다시 정리합니다. 처음엔 귀찮아 보여도 장기적으로 훨씬 이득이에요.

    실전: iptables 규칙을 nftables로 마이그레이션하는 순서

    이제 본격적으로 옮겨보겠습니다. 여기서는 가장 흔한 서버 기준으로 설명할게요. SSH는 열어두고, 이미 확립된 연결은 유지하고, 기본 정책은 보수적으로 가져가는 흐름입니다.

    1. 현재 iptables 규칙 확인

    sudo iptables -S
sudo ip6tables -S

    규칙을 읽어보면서 실제로 필요한 것과 과거 흔적을 구분하는 게 먼저예요. 저 같은 경우 예전에 테스트하다 남긴 포트 허용 규칙이 생각보다 많았습니다. 이런 건 옮기기 전에 정리하는 게 맞아요.

    2. 변환 초안 생성

    단일 규칙 한 줄은 `iptables-translate`로, 전체 저장본은 `iptables-restore-translate`로 보는 식으로 접근하면 편합니다.

    sudo iptables-translate -A INPUT -p tcp --dport 22 -j ACCEPT
    sudo iptables-save | sudo iptables-restore-translate

    출력 결과를 바로 적용하기보다, 먼저 파일로 저장해서 검토하는 쪽을 권장해요.

    sudo sh -c 'iptables-save | iptables-restore-translate > /root/translated.nft'

    여기서 중요한 포인트! 변환 결과를 그대로 믿지 마시고, 불필요하게 중복된 규칙이나 체인 구조를 꼭 점검하세요.

    iptables nftables 전환 과정에서 iptables-translate를 사용하는 터미널 이미지

    기존 iptables 규칙을 읽고 nftables 초안으로 변환하는 과정의 핵심 명령 흐름을 보여주는 이미지입니다.

    3. 사람이 읽기 좋은 nftables 규칙으로 정리

    제가 실제로는 아래처럼 새 파일을 다시 구성하는 편입니다. 예시는 가장 기본적인 서버용 필터 규칙셋입니다.

    table inet filter {
    chain input {
        type filter hook input priority 0;
        policy drop;

        iif lo accept
        ct state established,related accept
        ct state invalid drop

        tcp dport 22 accept
        tcp dport 80 accept
        tcp dport 443 accept

        ip protocol icmp accept
        ip6 nexthdr ipv6-icmp accept
    }

    chain forward {
        type filter hook forward priority 0;
        policy drop;
    }

    chain output {
        type filter hook output priority 0;
        policy accept;
    }
}

    이 규칙은 설명하기도 좋고, 나중에 봐도 의도가 비교적 분명합니다. `ct state established,related accept` 같은 부분은 기존 연결을 유지하는 데 아주 중요해서 빠뜨리면 안 돼요. 저도 초반에 이걸 빼먹고 “왜 응답 패킷이 이상하지?” 하며 한참 들여다봤었습니다.

    4. Set으로 반복 규칙 줄이기

    nftables의 진짜 장점은 이런 반복 제거에서 드러나요.

    table inet filter {
    set allowed_tcp_ports {
        type inet_service
        elements = { 22, 80, 443 }
    }

    chain input {
        type filter hook input priority 0;
        policy drop;

        iif lo accept
        ct state established,related accept
        tcp dport @allowed_tcp_ports accept
    }
}

    포트가 많아질수록 이 방식이 진짜 편하더라고요. 나중에 하나 추가하거나 제거할 때도 눈에 잘 들어옵니다.

    5. 문법 검증 후 적용

    실제 적용 전에는 반드시 문법 검사를 먼저 해요.

    sudo nft -c -f /etc/nftables.conf

    이상 없으면 적용합니다.

    sudo nft -f /etc/nftables.conf

    그리고 자동 시작도 확인해둬요.

    sudo systemctl enable nftables
sudo systemctl restart nftables

    배포판에 따라 서비스 이름이나 기본 설정 경로가 조금 다를 수 있으니, 이 부분은 현재 환경 기준으로 꼭 다시 확인하셔야 해요.

    ⚠️ 트러블슈팅: 제가 실제로 겪었던 문제들

    여기서부터가 실전입니다. 문서만 보면 금방 끝날 것 같지만, 실제로는 작은 차이 때문에 시간이 꽤 들어가요. 저도 삽질 좀 했습니다 ㅎㅎ

    SSH 접속이 갑자기 끊길 뻔한 경우

    가장 흔한 문제입니다. 기본 정책을 `drop`으로 바꿨는데 SSH 허용 규칙 순서가 뒤에 있거나, 아예 빠져 있으면 바로 위험해져요. 그래서 저는 항상 아래 순서를 지킵니다.

    1. 현재 접속 세션을 유지하는 `established,related` 규칙 먼저 추가
    2. SSH 허용 규칙 추가
    3. 그다음 기본 정책 적용

    이 순서를 지키면 사고 확률이 많이 줄어들어요.

    iptables와 nftables가 동시에 있는 것처럼 보이는 경우

    이건 처음 보면 꽤 혼란스러워요. 배포판에 따라 `iptables` 명령이 내부적으로 nft 기반 호환 레이어를 쓰는 경우가 있거든요. 그래서 “분명 nft로 바꿨는데 iptables 명령도 뭔가 보인다?” 같은 상황이 생깁니다. 이럴 땐 감으로 보지 말고, 실제 활성 규칙셋이 무엇인지 `nft list ruleset` 기준으로 확인하는 습관이 필요해요.

    변환은 됐는데 규칙이 너무 지저분한 경우

    이건 거의 반드시 겪어요. `iptables-translate`는 시작점으로는 훌륭하지만, 최종 결과물로 보기엔 장황한 경우가 많습니다. 여기서 시간을 조금 더 써서 `set`, `inet`, 상태 기반 매칭 중심으로 재구성하면 나중에 유지보수가 훨씬 쉬워져요. 제가 직접 써보니 이 단계가 가장 큰 차이를 만들었습니다.

    nftables 마이그레이션 시 set 기반 규칙 구성을 설명하는 리눅스 방화벽 이미지

    반복되는 포트 허용 규칙을 set으로 정리해 유지보수성을 높이는 구성을 시각화한 이미지입니다.

    검증: nftables 마이그레이션 후 무엇을 확인해야 할까요

    규칙 적용이 끝났다고 바로 마무리하면 안 돼요. 실제로 원하는 동작이 나오는지 검증이 꼭 필요합니다.

    기본 검증 명령

    sudo nft list ruleset
sudo ss -tulpn
sudo journalctl -u nftables --no-pager

    첫 번째는 현재 규칙셋 확인, 두 번째는 실제 리슨(Listen, 수신 대기) 포트 확인, 세 번째는 서비스 적용 로그 확인입니다. 저는 여기에 외부 호스트에서 실제 접속 테스트도 꼭 붙입니다. 서버 안에서만 보면 놓치는 게 있거든요.

    체크해야 할 항목

    • SSH, 웹, 모니터링 포트가 의도대로 열려 있는지
    • 허용하지 않은 포트가 막혀 있는지
    • 재부팅 후에도 동일한 규칙이 유지되는지
    • IPv6 트래픽도 의도대로 동작하는지

    특히 재부팅 검증은 꼭 해보세요. 적용은 됐는데 부팅 후 원래 규칙이 다시 올라오거나, 반대로 아무 규칙도 안 올라오는 경우가 있거든요. 저도 예전에 이걸 놓쳐서 “어제 분명 됐는데 왜 오늘 다르지?” 하며 로그를 뒤졌던 적이 있습니다.

    iptables nftables 전환 후 규칙 검증과 포트 확인을 보여주는 운영 점검 이미지

    적용된 규칙셋과 실제 서비스 포트 상태를 함께 확인하는 검증 단계의 결과 이미지입니다.

    iptables와 nftables, 어떤 방식으로 운영 정리하는 게 좋을까요

    운영 기준으로 보면 저는 이렇게 정리해요. 기존 시스템이 매우 안정적으로 돌고 있고 외부 의존성이 강하면, 한 번에 크게 바꾸기보다 단계적으로 옮기는 게 맞습니다. 반대로 규칙이 이미 복잡하고, 중복이 많고, 앞으로도 계속 확장될 예정이라면 nftables로 정리할 가치가 충분해요.

    운영 상황 권장 접근
    단순한 단일 서비스 서버 기본 규칙을 nftables로 재작성 후 빠르게 전환
    규칙이 많은 오래된 서버 iptables 백업 후 변환 초안 생성, 단계적 검증
    IPv4/IPv6 동시 운영 inet 테이블 중심으로 통합 설계
    반복 포트/주소 규칙이 많음 set과 map 활용으로 구조 단순화

    혹시 이런 경험 있으신가요? 규칙은 분명 맞는 것 같은데, 몇 달 뒤 다시 보면 왜 이렇게 짰는지 본인도 기억이 안 나는 경우요. 사실 리눅스 방화벽은 “작동만 하면 된다”가 아니라, 나중에 다시 읽어도 이해되는 구조가 정말 중요합니다. nftables는 바로 그 지점에서 큰 장점이 있어요.

    정리: 리눅스 방화벽 교체는 번역보다 재설계가 핵심입니다

    이번 iptables nftables 전환의 핵심은 단순 치환이 아닙니다. 리눅스 방화벽 교체를 한다고 생각하면, 기존 규칙을 점검하고, 필요한 것만 남기고, nftables 문법과 구조에 맞게 다시 정리하는 과정이 훨씬 중요합니다. `iptables-translate`는 좋은 출발점이지만, 최종 목적지는 결국 사람이 관리하기 좋은 규칙셋이어야 해요.

    제가 직접 해보니 가장 중요한 건 세 가지였습니다. 백업, 순서, 검증입니다. 백업 없이 시작하지 말 것. SSH 같은 필수 허용 규칙을 먼저 둘 것. 적용 후에는 반드시 외부에서 검증할 것. 이 세 가지만 지켜도 큰 사고를 많이 줄일 수 있어요.

    다음 글에서는 `nftables`에서 NAT(Network Address Translation, 네트워크 주소 변환) 규칙과 포트 포워딩을 정리하는 방법도 다뤄볼까 합니다. 홈랩 돌리시는 분들은 그쪽도 꽤 자주 쓰시거든요. 이전 글에서 다룬 리눅스 네트워크 기본 흐름과 함께 보시면 훨씬 이해가 잘 되실 겁니다.

    iptables nftables 전환 핵심 체크리스트를 요약한 인프라 운영 인포그래픽

    전환 이유, 절차, 검증 포인트를 한 번에 복습할 수 있도록 요약한 마무리 인포그래픽입니다.

    자주 묻는 질문

    iptables 규칙을 그대로 자동 변환해서 써도 될까요?

    가능은 하지만 권장하지는 않아요. 초안 생성에는 좋지만, 장기 운영을 생각하면 사람이 읽기 좋은 형태로 정리하는 게 훨씬 낫습니다.

    nftables 마이그레이션 시 가장 위험한 실수는 뭔가요?

    원격 접속 허용 규칙보다 먼저 기본 차단 정책을 적용하는 거예요. SSH 세션이 끊기면 복구가 번거로워집니다.

    IPv6를 안 쓰는 것 같으면 무시해도 될까요?

    환경에 따라 다르지만, 실제로는 IPv6가 살아 있는 경우가 적지 않아요. 인터페이스와 서비스 노출 상태를 먼저 확인해보는 게 안전합니다.

    netfilter를 꼭 깊게 알아야 하나요?

    커널 내부까지 깊게 파고들 필요는 없지만, 패킷이 어느 훅(hook)을 지나고 어느 체인에서 처리되는지 정도는 이해해두면 문제 해결이 훨씬 빨라져요.

  • [보안] 방화벽 설정, 이것만은 꼭! 10가지 필수 점검 항목

    [보안] 방화벽 설정, 이것만은 꼭! 10가지 필수 점검 항목

    목차

    [보안] 방화벽 설정, 이것만은 꼭! 10가지 필수 점검 항목

    서버를 올리고 포트만 열어둔 뒤 불안했던 경험, 아마 한 번쯤 있으실 겁니다. 저도 홈랩에서 테스트 서버를 굴리다가 방화벽 설정을 대충 해두고 넘어갔다가 나중에 로그를 보고 식은땀을 흘린 적이 있거든요. 방화벽 설정은 단순히 포트를 열고 닫는 작업이 아니라, 네트워크 보안의 기본선(baseline, 최소 보안 기준)을 만드는 일입니다. 이번 글에서는 실무와 홈랩에서 반복해서 확인하는 방화벽 보안 체크리스트 중심으로, 꼭 봐야 할 필수 점검 항목 10가지를 정리해보겠습니다.

    특히 이 글은 “방화벽 설정 후 뭘 먼저 확인해야 하지?” 하고 막막하신 분들을 위해 썼습니다. Linux 서버 기준 예시를 넣겠지만, 원칙 자체는 온프레미스(on-premise, 사내 구축 환경), 클라우드, 가상화 환경 모두에 그대로 적용됩니다.

    방화벽 설정이 적용된 홈랩 네트워크 아키텍처 이미지

    방화벽 설정 점검 항목이 DMZ, 내부망, 관리망으로 나뉘어 보이는 전체 개요 이미지입니다.

    1. 왜 방화벽 설정 점검은 항상 사고 전에 해야 할까요

    방화벽(Firewall, 트래픽을 제어하는 보안 장치)은 평소엔 조용합니다. 그래서 더 무섭습니다. 문제가 생기기 전까지는 존재감이 없거든요. 그런데 실제 장애나 침해사고 대응에서는 거의 항상 “이 포트 왜 열려 있었지?”, “관리 포트가 왜 외부에 노출됐지?” 같은 질문이 나옵니다.

    제가 직접 경험해보니 방화벽 설정 검토는 잘한 티는 안 나는데, 한 번 놓치면 문제가 됩니다. 특히 다음 상황에서 실수가 많이 나옵니다.

    • 테스트 서버를 운영 서버처럼 오래 끌고 갔을 때
    • 임시 오픈한 포트를 닫지 않았을 때
    • 소스 IP 제한 없이 관리 포트를 공개했을 때
    • 클라우드 보안 그룹(Security Group, 가상 방화벽)과 OS 방화벽 정책이 따로 놀 때

    여기서 중요한 포인트는 이것입니다: 방화벽은 “설정해뒀다”보다 “지금도 맞는 상태인지 확인하는 것”이 더 중요합니다.

    2. 좋은 방화벽 설정의 기본 원칙

    좋은 방화벽 설정은 결국 한 문장으로 정리됩니다: 필요한 통신만 허용하고, 나머지는 기본 차단(Default Deny, 기본 거부)하는 상태입니다. 이 원칙 하나만 제대로 잡아도 절반은 갑니다.

    방화벽 설정 점검 기준은 세 가지로 보면 편합니다.

    1. 누가 들어오나: 소스 IP, 네트워크 대역
    2. 어디로 들어오나: 목적지 포트, 서비스
    3. 왜 열어두나: 실제 업무 필요성, 운영 근거

    결국 방화벽 설정은 ACL(Access Control List, 접근 제어 목록)을 얼마나 명확하게 관리하느냐의 문제더라고요. “웹 서비스라서 80/443 허용”, “운영자만 SSH 22 접근”, “DB 3306은 앱 서버만 허용” 이런 식으로요.

    3. 방화벽 설정 점검 체크리스트: 필수 10가지 항목

    아래 10가지는 제가 서버 오픈 전에 거의 습관처럼 확인하는 필수 점검 항목입니다. 이 순서로 보면 빠르고, 빠뜨릴 것도 줄어듭니다.

    항목 무엇을 확인하나 핵심 이유
    1 기본 정책(Default Policy) 미정의 트래픽 차단
    2 허용 포트 최소화 공격 표면 축소
    3 관리 포트 접근 제한 SSH, RDP 등 보호
    4 소스 IP 대역 제한 불필요한 외부 접근 차단
    5 인바운드/아웃바운드 구분 양방향 정책 명확화
    6 불필요한 Any 허용 제거 과도한 허용 방지
    7 로그 활성화 추적과 감사 가능
    8 규칙 우선순위 확인 예상과 다른 매칭 방지
    9 예외 정책 문서화 운영 지속성 확보
    10 검증 명령과 정기 점검 설정 드리프트 방지

    보안 체크리스트는 화려할 필요 없습니다. 대신 반복 가능해야 합니다. 그리고 누가 봐도 같은 결론이 나와야 합니다.

    10가지 필수 항목을 짧게 풀어보면

    • 기본 정책은 deny: 허용보다 차단을 기본값으로 둡니다.
    • 포트는 최소한만: 서비스와 무관한 포트는 닫습니다.
    • 관리 포트는 외부 전체 공개 금지: Bastion(배스천, 중계 관리 서버)이나 VPN 뒤로 넣는 게 좋습니다.
    • 소스 제한: 가능하면 특정 사무실 IP나 관리망만 허용합니다.
    • 아웃바운드도 본다: 내부 서버가 외부로 아무 데나 나가는 것도 위험할 수 있습니다.
    • Any-Any 규칙 제거: 편하지만 위험합니다. 저도 급할 때 열었다가 나중에 후회했었습니다.
    • 로그는 꼭 남긴다: 침해 대응의 시작점입니다.
    • 우선순위 확인: 먼저 걸리는 규칙 때문에 뒤 규칙이 무의미해질 수 있습니다.
    • 예외는 기록: 왜 열었는지 안 적어두면 몇 달 뒤 아무도 모릅니다.
    • 정기 검증: 월 1회만 해도 효과가 큽니다.

    4. 실전 구현: Linux 서버의 방화벽 설정 기본

    여기서는 Ubuntu 계열에서 많이 쓰는 UFW(Uncomplicated Firewall, 간단 방화벽 관리 도구) 기준으로 보여드리겠습니다. 환경에 따라 nftables(리눅스 패킷 필터 프레임워크)나 iptables(전통적 패킷 필터)를 쓰실 수도 있는데, 원칙은 같습니다.

    1. 현재 열려 있는 서비스와 포트를 먼저 확인합니다.
    2. 기본 정책을 설정합니다.
    3. 서비스별 허용 규칙을 최소 권한으로 추가합니다.
    4. 로그와 검증을 수행합니다.
    ss -tulpn
sudo ufw status verbose
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw logging on
sudo ufw enable
sudo ufw status numbered

    위 예시는 정말 기본형입니다. 웹 서버라면 80/443만, SSH는 관리 IP에서만 허용하는 식이죠. 실제로 써보니까 처음부터 이렇게 보수적으로 잡는 게 나중에 훨씬 편하더라고요.

    서비스별 방화벽 설정 기준

    서비스 권장 접근 방식 비고
    SSH 특정 관리 IP만 허용 가능하면 VPN 뒤에서 접근
    HTTP/HTTPS 외부 공개 허용 리버스 프록시 뒤 구성 가능
    DB 포트 앱 서버 IP만 허용 인터넷 직접 공개 지양
    모니터링 포트 관리망만 허용 Prometheus 등 내부 수집 권장
    방화벽 설정에서 허용 포트를 구분한 서버 구성 이미지

    웹 포트와 관리 포트가 구분되어 보이는 실전 방화벽 설정 예시 이미지입니다.

    5. 더 실무적으로: 인바운드와 아웃바운드를 함께 점검하세요

    많이 놓치는 부분이 아웃바운드(Outbound, 서버에서 외부로 나가는 트래픽)입니다. 인바운드만 막아두면 끝이라고 생각하기 쉬운데, 실제 운영에서는 그렇지 않거든요. 만약 서버가 침해당했다면 외부 C2(Command and Control, 원격 제어 서버)와 통신을 시도할 수도 있습니다.

    그래서 저는 최소한 아래는 꼭 봅니다.

    • 패키지 저장소, 시간 동기화, 외부 API 등이 꼭 필요한 목적지인지
    • 내부 서버가 임의 포트로 외부에 나가고 있지 않은지
    • 백업, 모니터링, 알림 전송 경로가 정책과 충돌하지 않는지

    예를 들어 DB 서버는 인터넷으로 직접 나갈 이유가 거의 없습니다. 그런 서버는 아웃바운드 정책도 보수적으로 잡는 편이 낫습니다.

    sudo ufw default deny outgoing
sudo ufw allow out 53
sudo ufw allow out 123/udp
sudo ufw allow out 443/tcp
sudo ufw status verbose

    물론 이렇게 하면 처음엔 업데이트나 에이전트 통신이 막혀서 좀 삽질했습니다. ㅎㅎ 그래서 운영 서버에 바로 적용하기보다는, 먼저 필요한 통신 목록부터 뽑아보시는 걸 추천드립니다.

    6. 규칙 우선순위, 로그, 문서화: 운영 품질을 갈라놓는 세 가지

    방화벽 설정이 당장은 맞아 보여도, 시간이 지나면 예외 규칙이 늘어나면서 복잡해집니다. 그때 진짜 차이가 나는 게 규칙 우선순위(rule order), 로그(logging), 문서화(documentation)입니다.

    규칙 우선순위 확인하기

    특히 iptables나 클라우드 ACL에서는 먼저 매칭된 규칙이 적용되는 경우가 많습니다. 그래서 아래처럼 번호나 순서를 보고 정리해야 합니다.

    sudo ufw status numbered

    분명 차단 규칙을 넣었는데 접속이 되는 경험 있으신가요? 나중에 보면 위쪽에 더 넓은 허용 규칙이 먼저 있더라고요. 저도 처음엔 꽤 헷갈렸습니다.

    로그는 최소한 이 정도는 남기세요

    • 거부된 접속 시도
    • 관리 포트 접근 시도
    • 비정상적으로 반복되는 스캔 패턴

    로그가 있어야 Fail2ban 같은 자동 방어 도구를 붙이기도 쉽고, 나중에 보안 체크리스트 점검 결과를 설명하기도 편합니다.

    예외 정책은 꼭 기록하세요

    예를 들어 “협력사 고정 IP에서만 임시 허용, 만료일은 2026-08-03” 같은 걸 남겨야 합니다. 안 그러면 임시가 영구가 됩니다. 이거 진짜 자주 봅니다.

    방화벽 설정 결과를 모니터링하는 네트워크 보안 대시보드 이미지

    차단 로그와 관리 포트 접근 시도가 보이는 결과 검증용 모니터링 이미지입니다.

    7. ⚠️ 실제로 겪었던 문제들: 방화벽 트러블슈팅 포인트

    실무든 홈랩이든 방화벽 설정에서 가장 무서운 건 “서비스를 보호하려다가 내가 못 들어가는 상황”입니다. 저도 원격지 장비에서 SSH를 제 손으로 막아본 적 있습니다. “드디어 됐다!” 하고 나갔는데 다시 접속이 안 되더라고요.

    자주 겪는 문제 1: SSH를 너무 빨리 막음

    해결 방법은 간단합니다: 현재 접속 중인 세션을 유지한 상태에서 새 세션으로 재접속 테스트를 먼저 하세요.

    sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
ssh user@server-ip

    새 세션 접속이 확인되기 전에는 기존 세션을 끊지 않는 게 안전합니다.

    자주 겪는 문제 2: 클라우드 방화벽과 OS 방화벽이 충돌

    AWS Security Group, GCP VPC Firewall, Azure NSG 같은 상위 정책과 OS 내부 정책이 둘 다 있으면, 어디서 막히는지 헷갈립니다. 이런 경우는 아래 순서로 확인하면 됩니다.

    1. 클라우드 보안 그룹에서 허용 여부 확인
    2. OS 방화벽에서 동일 포트 허용 여부 확인
    3. 서비스 데몬이 실제로 Listen(포트 대기) 중인지 확인
    4. 라우팅과 NAT(Network Address Translation, 주소 변환) 경로 확인
    ss -tulpn
sudo ufw status verbose
ip addr
ip route

    자주 겪는 문제 3: IPv4만 보고 끝냄

    이 부분도 은근히 놓칩니다. IPv6이 활성화된 환경이라면 IPv4 규칙만 보고 안심하면 안 됩니다. 방화벽 설정 점검 시 IPv6 정책도 같이 봐야 합니다.

    8. 검증 방법: 설정했으면 반드시 확인하세요

    보안은 추측으로 끝내면 안 됩니다. 설정 후에는 꼭 검증해야 합니다. 저는 보통 서버 내부 확인과 외부 확인을 나눠서 봅니다.

    서버 내부에서 확인

    sudo ufw status verbose
sudo ufw status numbered
ss -tulpn
    • 열려 있어야 하는 포트만 열려 있는지
    • 허용 대상 IP가 의도와 맞는지
    • 기본 정책이 incoming deny인지

    외부에서 확인

    nc -vz server-ip 22
nc -vz server-ip 80
nc -vz server-ip 443

    관리 PC에서는 열려야 하고, 허용되지 않은 위치에서는 막혀야 정상입니다. 이 차이를 직접 확인해보면 훨씬 마음이 놓입니다.

    방화벽 설정 검증 체크리스트

    1. 기본 정책이 차단 중심인지 확인
    2. 불필요한 포트가 남아 있지 않은지 확인
    3. 관리 포트가 특정 IP로 제한됐는지 확인
    4. 로그가 남고 있는지 확인
    5. 예외 정책이 문서화됐는지 확인

    이 정도만 해도 네트워크 보안 수준이 꽤 안정됩니다. 화려한 장비보다 이런 기본기가 훨씬 오래 갑니다.

    방화벽 설정 필수 점검 항목을 요약한 네트워크 보안 이미지

    점검 전후 차이와 필수 점검 항목 10가지를 한눈에 보여주는 요약 이미지입니다.

    9. 정리: 방화벽 설정은 결국 운영 습관입니다

    정리하면 방화벽 설정의 핵심은 세 가지입니다: 기본 차단, 최소 허용, 지속 검증. 사실 특별한 비법은 없습니다. 대신 귀찮아도 반복해야 합니다. 저도 처음엔 규칙 몇 개 넣고 끝내려 했었는데, 시간이 지나 보니 결국 방화벽 보안 체크리스트를 얼마나 성실하게 돌리느냐가 차이를 만들더라고요.

    다음 글에서는 홈랩 기준으로 리버스 프록시(역방향 프록시)와 방화벽을 함께 구성하는 방법도 다뤄볼 예정입니다. 이전 글에서 다뤘던 로그 모니터링 내용과 연결해서 보시면 더 이해가 쉬우실 겁니다.

    자주 묻는 질문

    Q. 방화벽 설정은 서버마다 다르게 해야 하나요?
    네, 서비스 역할이 다르면 달라져야 합니다. 웹 서버, DB 서버, 모니터링 서버는 필요한 포트와 접근 주체가 다르거든요.

    Q. 클라우드 보안 그룹만 있으면 OS 방화벽은 안 써도 되나요?
    환경에 따라 다르지만, 저는 이중으로 두는 편입니다. 방어 계층(다층 방어)이 생기기 때문입니다.

    Q. 제일 먼저 바꿔야 할 한 가지는 뭔가요?
    기본 정책을 정리하고, SSH 같은 관리 포트의 소스 IP 제한부터 거세요. 체감 효과가 가장 큽니다.

    마지막으로 한 줄만 드리면, 방화벽 설정은 한 번 잘해두는 작업이 아니라 계속 점검하는 운영 루�ine입니다. 오늘 서버 한 대라도 체크리스트대로 다시 보시면 분명 놓친 게 하나쯤은 보일 겁니다.

  • [Proxmox] VE 8.2 네트워크 고급 설정: VLAN, 브릿지, nftables 방화벽 완벽 가이드

    목차

    홈랩 네트워크, 이대로 괜찮은가요?

    솔직히 말씀드리면, 저도 처음엔 Proxmox VE를 설치하고 그냥 기본 브릿지 하나에 VM 다 때려넣고 썼거든요. “뭐, 집에서 쓰는 건데 보안이 무슨 상관이야” 싶었죠. 근데 어느 날 홈랩에서 돌리던 개발용 컨테이너 하나가 이상한 트래픽을 뿜는 걸 발견했을 때… 그때부터 제대로 네트워크를 나눠야겠다는 생각이 들었습니다.

    Proxmox 네트워크 설정을 제대로 이해하면 VM/컨테이너별로 네트워크를 격리하고, 불필요한 트래픽을 차단하고, 관리 인터페이스를 보호할 수 있어요. 오늘은 Proxmox VE 8.2 기준으로 VLAN 설정, 브릿지 구성, 그리고 nftables 방화벽까지 한 번에 정리해 드릴게요. 꽤 긴 글이 될 것 같지만, 차근차근 따라오시면 충분히 이해하실 수 있을 겁니다.

    ▲ 오늘 구성할 Proxmox 네트워크 전체 구조입니다. VLAN별로 트래픽을 분리하고 nftables로 방화벽 규칙을 적용하는 흐름을 한눈에 볼 수 있어요.

    Proxmox 네트워크 핵심 개념 먼저 짚고 가기

    설정 들어가기 전에 개념을 잡아두는 게 중요해요. 저도 처음엔 브릿지랑 본드(Bond)랑 VLAN이 뭐가 다른지 헷갈려서 삽질을 꽤 했거든요.

    Linux Bridge(리눅스 브릿지)란?

    쉽게 말해, 소프트웨어로 만든 스위치입니다. Proxmox에서 VM이나 컨테이너를 만들면 각각의 가상 NIC(네트워크 인터페이스 카드)가 이 브릿지에 연결되는 구조예요. 물리 스위치의 포트처럼 동작한다고 보시면 됩니다.

    VLAN(Virtual LAN, 가상 로컬 네트워크)이란?

    하나의 물리 네트워크를 논리적으로 분리하는 기술이에요. 예를 들어 관리용 VM, 개발용 VM, IoT 장비를 같은 물리 스위치에 연결해도 VLAN ID로 완전히 다른 네트워크처럼 동작하게 만들 수 있습니다. Proxmox 8.2에서는 VLAN-aware bridge(VLAN 인식 브릿지) 방식을 권장하고 있어요.

    nftables란?

    기존 iptables를 대체하는 리눅스 방화벽 프레임워크입니다. Proxmox VE 7.x 이후부터 내부적으로 nftables를 사용하고 있고, 8.x에서는 더 완성도 있게 통합됐어요. 문법이 처음엔 낯설지만, 익숙해지면 iptables보다 훨씬 직관적이더라고요.

    구성 요소 역할 비고
    Linux Bridge VM/CT 간 L2 연결 (소프트웨어 스위치) vmbr0, vmbr1 등으로 명명
    VLAN 논리적 네트워크 분리 (태그 기반) 802.1Q 표준, ID 1~4094
    Bond 물리 NIC 이중화 / 대역폭 확장 active-backup, LACP 등
    nftables 호스트 및 VM 트래픽 방화벽 iptables 대체, Proxmox 통합

    Proxmox VLAN 설정: VLAN-aware Bridge 구성하기

    이제 본격적으로 설정을 시작해 볼게요. 제가 실제로 운영 중인 홈랩 구성을 기반으로 설명드리겠습니다.

    시나리오 설명

    • VLAN 10: 관리 네트워크 (Proxmox 관리 인터페이스, 네트워크 장비)
    • VLAN 20: 서버 네트워크 (웹서버, DB 등 서비스 VM)
    • VLAN 30: 개발/테스트 네트워크 (개발 VM, 컨테이너)
    • VLAN 99: IoT/비신뢰 네트워크 (외부 접근 허용 최소화)

    1단계: /etc/network/interfaces 설정

    Proxmox의 네트워크 설정은 /etc/network/interfaces 파일로 관리됩니다. GUI에서도 설정할 수 있지만, 파일을 직접 편집하는 게 더 정확하고 빠르더라고요.

    # 기존 설정 백업 먼저!
cp /etc/network/interfaces /etc/network/interfaces.bak

# 편집
nano /etc/network/interfaces

    아래 내용으로 설정합니다. 물리 NIC 이름은 환경마다 다를 수 있으니 ip link show로 먼저 확인하세요.

    auto lo
iface lo inet loopback

# 물리 NIC (업스트림 스위치와 연결되는 트렁크 포트)
auto enp3s0
iface enp3s0 inet manual

# VLAN-aware Bridge (VLAN 인식 브릿지)
auto vmbr0
iface vmbr0 inet static
    address 192.168.10.100/24      # VLAN 10 (관리망) IP
    gateway 192.168.10.1
    bridge-ports enp3s0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes          # 핵심! VLAN 인식 활성화
    bridge-vids 2-4094             # 허용할 VLAN ID 범위

# VLAN 인터페이스 (호스트가 각 VLAN에 직접 접근할 때 필요)
auto vmbr0.20
iface vmbr0.20 inet static
    address 192.168.20.1/24

auto vmbr0.30
iface vmbr0.30 inet static
    address 192.168.30.1/24

auto vmbr0.99
iface vmbr0.99 inet static
    address 192.168.99.1/24

    ⚠️ 중요! bridge-vlan-aware yes를 설정하면 기존에 VLAN 없이 연결된 VM들이 통신이 끊길 수 있어요. 반드시 각 VM의 네트워크 설정에서 VLAN 태그를 지정해 줘야 합니다.

    2단계: 설정 적용

    # 네트워크 재시작 (원격 접속 중이라면 주의!)
ifreload -a

# 또는 재부팅
reboot

    💡 팁: 원격으로 작업 중이라면 ifreload -a가 더 안전합니다. 그래도 혹시 모르니 콘솔 접근이 가능한 상태에서 작업하는 걸 강력 추천드려요. 저도 한 번 원격이 끊겨서 IDC까지 달려간 적 있거든요.

    3단계: VM에 VLAN 태그 설정

    VM 설정에서 네트워크 장치를 추가할 때 VLAN Tag를 지정합니다.

    # CLI로 VM 네트워크 설정 변경 (VM ID 101, VLAN 20 할당)
qm set 101 --net0 virtio,bridge=vmbr0,tag=20

# 컨테이너(LXC)의 경우
pct set 201 --net0 name=eth0,bridge=vmbr0,tag=30,ip=192.168.30.10/24,gw=192.168.30.1

    ▲ Proxmox GUI에서 VM 네트워크 설정 시 VLAN Tag 항목에 VLAN ID를 입력하면 됩니다. bridge-vlan-aware 설정이 되어 있어야 이 옵션이 동작해요.

    Proxmox 브릿지 고급 설정: 다중 브릿지 구성

    VLAN-aware 브릿지 하나로 대부분 해결되지만, 경우에 따라 브릿지를 여러 개 나누는 게 더 나을 때도 있어요. 예를 들어 완전히 격리된 내부 네트워크(외부 연결 없는 NAT 망)가 필요할 때죠.

    NAT 브릿지 추가 (인터넷 연결 없는 격리망)

    # /etc/network/interfaces에 추가
auto vmbr1
iface vmbr1 inet static
    address 10.10.10.1/24
    bridge-ports none              # 물리 NIC 없음 = 완전 격리
    bridge-stp off
    bridge-fd 0
    post-up echo 1 > /proc/sys/net/ipv4/ip_forward
    post-up iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -o vmbr0 -j MASQUERADE
    post-down iptables -t nat -D POSTROUTING -s '10.10.10.0/24' -o vmbr0 -j MASQUERADE

    이렇게 하면 vmbr1에 연결된 VM들은 인터넷은 되지만(NAT를 통해), 외부에서 직접 접근은 불가능한 구조가 됩니다. 개발/테스트 환경에 딱이에요.

    nftables 방화벽 설정: Proxmox 방화벽 제대로 활용하기

    자, 이제 핵심 중의 핵심입니다. Proxmox 방화벽 설정인데요, 사실 Proxmox에는 GUI 기반의 자체 방화벽 기능이 있고, 이게 내부적으로 nftables를 사용해요. 두 가지 방법을 모두 알아두는 게 좋습니다.

    방법 1: Proxmox 내장 방화벽 (GUI/설정 파일)

    Proxmox 방화벽은 세 가지 레벨로 동작합니다.

    1. Datacenter 레벨: 클러스터 전체에 적용되는 공통 규칙 (/etc/pve/firewall/cluster.fw)
    2. Host 레벨: Proxmox 호스트 자체에 적용 (/etc/pve/nodes/[노드명]/host.fw)
    3. VM/CT 레벨: 개별 가상머신/컨테이너에 적용 (/etc/pve/firewall/[VMID].fw)

    Proxmox 방화벽 활성화

    # 방화벽 설정 파일 위치 확인
ls /etc/pve/firewall/

# 클러스터 방화벽 설정
cat /etc/pve/firewall/cluster.fw

    GUI에서는 Datacenter → Firewall → Options에서 Enable을 체크하면 됩니다. 호스트별로도 같은 방법으로 활성화할 수 있어요.

    방화벽 규칙 파일 직접 편집

    # /etc/pve/firewall/cluster.fw 예시
[OPTIONS]
enable: 1
policy_in: DROP      # 기본 인바운드 정책: 차단
policy_out: ACCEPT   # 기본 아웃바운드 정책: 허용

[RULES]
# Proxmox 웹 GUI 접근 (관리망에서만)
IN ACCEPT -source 192.168.10.0/24 -p tcp --dport 8006 -log warning
# SSH 접근 (관리망에서만)
IN ACCEPT -source 192.168.10.0/24 -p tcp --dport 22 -log warning
# ICMP (ping) 허용
IN ACCEPT -p icmp
# 이미 맺어진 연결 허용
IN ACCEPT -m conntrack --ctstate RELATED,ESTABLISHED

    방법 2: nftables 직접 설정 (고급 사용자용)

    Proxmox 내장 방화벽으로 커버 안 되는 복잡한 규칙이 필요할 때는 nftables를 직접 건드려야 합니다. 근데 여기서 주의할 점! Proxmox가 자체 방화벽을 관리하기 때문에, 직접 nftables 규칙을 추가하면 충돌이 날 수 있어요.

    그래서 권장하는 방법은 custom nftables 설정 파일을 별도로 만드는 겁니다.

    # /etc/nftables.conf 에 커스텀 규칙 추가
nano /etc/nftables.conf
    #!/usr/sbin/nft -f

# 기존 규칙 초기화
flush ruleset

table inet filter {
    # 체인(chain): 패킷 처리 흐름 정의
    chain input {
        type filter hook input priority 0; policy drop;

        # 루프백 인터페이스 허용
        iif lo accept

        # 이미 맺어진 연결 및 관련 트래픽 허용
        ct state established,related accept

        # ICMP 허용 (ping 등)
        ip protocol icmp accept
        ip6 nexthdr icmpv6 accept

        # 관리망(VLAN 10)에서 SSH 허용
        iifname "vmbr0.10" tcp dport 22 accept

        # 관리망에서 Proxmox 웹 GUI 허용
        iifname "vmbr0.10" tcp dport 8006 accept

        # 나머지는 로그 남기고 차단
        log prefix "[nft-drop] " limit rate 5/minute
        drop
    }

    chain forward {
        type filter hook forward priority 0; policy drop;

        # 이미 맺어진 연결 허용
        ct state established,related accept

        # VLAN 20 (서버망) → 인터넷 허용
        iifname "vmbr0.20" oifname "vmbr0" accept

        # VLAN 30 (개발망) → 인터넷 허용
        iifname "vmbr0.30" oifname "vmbr0" accept

        # VLAN 간 통신 차단 (보안 격리)
        # 개발망 → 서버망 차단
        iifname "vmbr0.30" oifname "vmbr0.20" drop

        # IoT망 → 다른 VLAN 차단
        iifname "vmbr0.99" drop
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

# NAT 테이블 (vmbr1 사용 시)
table ip nat {
    chain postrouting {
        type nat hook postrouting priority 100;
        oifname "vmbr0" masquerade
    }
}
    # nftables 서비스 활성화 및 시작
systemctl enable nftables
systemctl start nftables

# 규칙 적용 확인
nft list ruleset

# 특정 테이블만 확인
nft list table inet filter

    ⚠️ 경고: Proxmox 내장 방화벽과 nftables를 동시에 사용하면 규칙이 충돌할 수 있습니다. 둘 중 하나만 선택하거나, Proxmox 방화벽을 비활성화한 후 nftables를 직접 관리하는 방식을 권장합니다. 저는 단순한 환경에서는 Proxmox 내장 방화벽만 쓰고, 복잡한 규칙이 필요할 때는 nftables 직접 설정을 사용하고 있어요.

    ▲ nftables 방화벽 규칙을 적용했을 때 VLAN 간 트래픽 허용/차단 흐름입니다. IoT망(VLAN 99)은 다른 VLAN으로의 접근이 완전히 차단됩니다.

    ⚠️ 트러블슈팅: 실제로 겪은 문제들

    설정하다 보면 분명히 막히는 부분이 생기거든요. 제가 겪은 것들 공유합니다.

    문제 1: VLAN 설정 후 VM 네트워크 먹통

    증상: bridge-vlan-aware 활성화 후 기존 VM들이 네트워크가 안 됨

    원인: VLAN-aware 브릿지에서는 VLAN 태그가 없는 트래픽이 기본적으로 차단됩니다.

    해결: 각 VM 네트워크 설정에 VLAN 태그를 추가하거나, 태그 없이 쓰고 싶다면 bridge-pvid(포트 VLAN ID)를 설정하세요.

    # 특정 브릿지 포트의 PVID 확인
bridge vlan show

# VM 포트에 PVID 설정 (태그 없는 트래픽을 VLAN 20으로)
bridge vlan add dev vmbr0 vid 20 pvid untagged

    문제 2: nftables 규칙 적용 후 Proxmox GUI 접근 불가

    증상: nftables 설정 후 8006 포트로 접근이 안 됨

    원인: input 체인의 기본 정책이 drop인데, 8006 포트 허용 규칙이 잘못된 인터페이스에 적용됨

    해결: 인터페이스 이름을 ip link show로 정확히 확인하고, 임시로 모든 8006 트래픽을 허용한 뒤 규칙을 다듬으세요.

    # 임시로 8006 전체 허용 (디버깅용)
nft add rule inet filter input tcp dport 8006 accept

# 현재 적용된 규칙 확인
nft list chain inet filter input

# 인터페이스 이름 확인
ip link show | grep -E "^[0-9]+:"
bridge vlan show

    문제 3: VM 간 통신이 방화벽 규칙과 무관하게 됨

    증상: forward 체인에서 차단했는데 VM끼리 통신이 됨

    원인: 같은 브릿지 내 VM 간 트래픽은 L2(2계층)에서 바로 처리되어 forward 체인을 거치지 않을 수 있음

    해결: 브릿지에서 nf_call_iptables(또는 nftables)를 활성화해야 합니다.

    # 브릿지 트래픽이 netfilter를 통과하도록 설정
echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo 1 > /proc/sys/net/bridge/bridge-nf-call-ip6tables

# 영구 적용 (/etc/sysctl.conf)
echo "net.bridge.bridge-nf-call-iptables = 1" >> /etc/sysctl.conf
echo "net.bridge.bridge-nf-call-ip6tables = 1" >> /etc/sysctl.conf
sysctl -p

    ✅ 설정 검증: 제대로 됐는지 확인하기

    설정을 다 했으면 검증이 필수입니다. “됐겠지”하고 넘어갔다가 나중에 보안 구멍 발견하면 더 힘들거든요.

    VLAN 설정 검증

    # 브릿지 VLAN 상태 확인
bridge vlan show

# 예상 출력:
# port    vlan ids
# vmbr0    1 PVID Egress Untagged
#          10
#          20
#          30
#          99

# 각 VLAN 인터페이스 IP 확인
ip addr show vmbr0.20
ip addr show vmbr0.30

# VLAN 10 (관리망) VM에서 VLAN 20 (서버망) VM으로 ping 테스트
# 허용된 경로라면 응답이 와야 함
ping -c 4 192.168.20.10

    방화벽 규칙 검증

    # 현재 nftables 규칙 전체 출력
nft list ruleset

# 패킷 카운터 확인 (규칙이 실제로 매칭되는지)
nft list ruleset | grep -A2 "counter"

# 로그 확인 (차단된 패킷)
journalctl -f | grep "nft-drop"

# 특정 포트 접근 테스트
nc -zv 192.168.10.100 8006   # 성공해야 함
nc -zv 192.168.10.100 22     # 성공해야 함
nc -zv 192.168.10.100 80     # 차단되어야 함 (규칙 없으면)

    VLAN 간 격리 검증

    # IoT망 VM(192.168.99.x)에서 서버망 VM(192.168.20.x)으로 ping
# 차단 규칙이 있다면 응답 없어야 함
ping -c 4 192.168.20.10  # 타임아웃이 나야 정상!

# 개발망 VM에서 서버망으로 접근 시도
ping -c 4 192.168.20.10  # 마찬가지로 차단되어야 함

    🎉 모든 테스트가 예상대로 동작한다면 설정 완료입니다! 처음 이 구성을 완성했을 때 진짜 뿌듯했거든요. 네트워크가 깔끔하게 정리되는 느낌이랄까요.

    ▲ 설정 완료 후 각 VLAN 간 통신 허용/차단 검증 결과입니다. 초록색은 허용, 빨간색은 차단을 의미하며 설계한 대로 정확히 동작하는 것을 확인할 수 있습니다.

    자주 묻는 질문 (FAQ)

    Q. Proxmox 방화벽과 nftables를 동시에 써도 되나요?

    권장하지 않습니다. Proxmox 내장 방화벽이 활성화되면 자체적으로 nftables 규칙을 생성하는데, 여기에 커스텀 nftables 설정을 추가하면 규칙 순서와 충돌 문제가 생길 수 있어요. 간단한 환경이라면 Proxmox 내장 방화벽만, 복잡한 규칙이 필요하다면 내장 방화벽을 끄고 nftables를 직접 관리하는 것을 추천합니다.

    Q. VLAN 설정 시 업스트림 스위치도 설정해야 하나요?

    네, 반드시 필요합니다. Proxmox와 연결된 스위치 포트는 Trunk 포트로 설정하고, 사용할 VLAN ID들을 허용해야 합니다. 관리형 스위치(Managed Switch)가 없다면 VLAN 기능을 사용하기 어렵습니다.

    Q. VM이 많아지면 방화벽 규칙 관리가 힘들지 않나요?

    맞아요, 그래서 IP set(IP 집합)과 Security Group(보안 그룹) 기능을 활용하는 게 좋습니다. Proxmox 내장 방화벽에서 IP set으로 그룹을 만들어두면 규칙 관리가 훨씬 수월해집니다.

    마무리: 네트워크 분리, 귀찮아도 꼭 해야 합니다

    처음에 이야기했던 것처럼, 저도 처음엔 “홈랩인데 뭘 그렇게까지” 싶었어요. 근데 막상 제대로 구성해 놓고 나니까, 어떤 VM에 문제가 생겨도 다른 VM이나 호스트에 영향이 없으니까 마음이 편하더라고요. 특히 외부에서 접근 가능한 서비스를 운영할 때는 정말 필수입니다.

    오늘 다룬 내용을 정리하면:

    • ✅ VLAN-aware Bridge로 논리적 네트워크 분리
    • ✅ 다중 브릿지로 완전 격리 NAT 망 구성
    • ✅ Proxmox 내장 방화벽 또는 nftables 직접 설정으로 트래픽 제어
    • ✅ VLAN 간 격리 검증으로 설정 완료 확인

    다음에는 Proxmox 클러스터 구성과 고가용성(HA, High Availability) 설정에 대해 다룰 예정이에요. 네트워크 기반이 잘 잡혀 있어야 클러스터도 안정적으로 운영할 수 있거든요. 궁금한 점이나 다른 경험 있으신 분은 댓글로 공유해 주세요!

    💡 다음 단계 제안: 이 설정을 기반으로 SDN(Software Defined Networking) 기능도 탐구해 보세요. Proxmox 8.x에서 SDN 기능이 많이 발전했는데, VXLAN 오버레이 네트워크 같은 더 고급 구성도 가능합니다. 이전 글에서 다룬 Proxmox 기본 설치 가이드와 함께 보시면 더 도움이 될 거예요.