13년차의 서버실

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

[태그:] SSH 보안

  • [보안] 방화벽 설정, 이것만은 꼭! 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입니다. 오늘 서버 한 대라도 체크리스트대로 다시 보시면 분명 놓친 게 하나쯤은 보일 겁니다.

  • [보안] CIS 벤치마크 기반 서버 보안 강화: 실제 적용 사례와 효과

    [보안] CIS 벤치마크 기반 서버 보안 강화: 실제 적용 사례와 효과

    목차

    CIS 벤치마크 기반 서버 보안 강화: 실제 적용 사례와 효과

    서버를 오래 운영하다 보면 한 번쯤은 이런 순간이 옵니다. 서비스는 잘 돌아가는데, 막상 CIS 벤치마크 서버 보안 관점에서 보면 기본 설정이 생각보다 허술한 경우가 있거든요. 저도 홈랩(Home Lab, 개인 실험용 인프라 환경)과 업무 환경에서 Linux(리눅스) 서버를 같이 만지다 보니, “기능은 되는데 보안 감사(Security Audit, 보안 점검)에서 계속 걸리네?” 싶은 날이 있었습니다. 특히 계정 정책, SSH(Secure Shell, 원격 접속), 파일 권한, 로그 설정 같은 항목은 평소엔 문제 없어 보여도 실제 감사 시점에는 바로 드러나더라고요. 그래서 이번 글에서는 제가 직접 정리해서 적용했던 CIS 벤치마크 기반 서버 보안 강화 과정을 사례 중심으로 풀어보겠습니다.

    이 글은 특정 제품 홍보가 아니라, 실제로 많이 부딪히는 Linux 보안 강화 흐름을 기준으로 적었습니다. 보안 감사 대응이 필요하신 분, 서버 설정을 체계적으로 정리하고 싶은 분, 그리고 “어디서부터 손대야 하지?” 막막하신 분께 특히 도움이 될 겁니다.

    CIS 벤치마크 서버 보안 전체 아키텍처 개요 이미지

    기본 서버에서 계정 정책, SSH 설정, 로그 수집, 감사 항목을 단계적으로 강화하는 전체 흐름을 보여주는 이미지입니다.

    CIS 벤치마크 서버 보안, 쉽게 말하면 뭘까요?

    CIS Benchmarks(CIS 벤치마크, Center for Internet Security에서 제공하는 보안 설정 권고안)는 운영체제와 소프트웨어를 보다 안전하게 설정하기 위한 기준 모음입니다. 쉽게 말해, “이 정도는 최소한 맞춰두면 보안 사고 가능성을 꽤 줄일 수 있습니다”라는 체크리스트에 가깝습니다.

    처음엔 저도 이게 뭔가 싶었습니다. 문서를 보면 항목이 많고, 다 적용하면 서비스가 멈플 것 같아 겁부터 나거든요. 근데 실제로 써보니까 핵심은 단순합니다. 모든 항목을 기계적으로 넣는 게 아니라, 서비스 영향도를 보면서 우선순위를 나눠 적용하는 것이더라고요.

    현장에서 특히 많이 보는 점검 항목

    • 계정 및 인증(Authentication, 사용자 신원 확인): 패스워드 정책, 불필요한 계정 정리, sudo 권한 제한
    • SSH 설정: root 직접 로그인 차단, 인증 방식 점검, 접속 가능한 사용자 제한
    • 파일 권한(File Permission, 접근 권한): 중요한 설정 파일의 소유자와 권한 조정
    • 로그와 감사(Auditing, 행위 기록 추적): auth 로그, sudo 로그, 변경 이력 보관
    • 네트워크 최소화: 불필요한 포트와 서비스 비활성화
    구분 적용 전 적용 후
    계정 관리 오래된 계정 방치 불필요 계정 잠금 또는 제거
    SSH 접속 기본값 위주 운영 root 로그인 차단, 접근 사용자 제한
    로그 추적 기본 로그만 확인 감사 기준에 맞춰 로그 보강
    설정 일관성 서버마다 편차 큼 표준 설정 베이스 확보

    여기서 중요한 포인트! CIS 벤치마크 서버 보안은 만능 보안 솔루션이 아닙니다. 다만 서버 설정의 기준선을 맞춰주기 때문에, 보안 감사나 운영 안정성 측면에서 체감 효과가 꽤 큽니다.

    제가 적용할 때 잡았던 기준: 한 번에 다 하지 않기

    실전에서는 보통 신규 서버보다 기존 운영 서버가 더 문제입니다. 이미 서비스가 돌아가고 있으니 설정 하나 잘못 건드리면 장애로 이어질 수 있거든요. 저도 처음엔 의욕이 앞서서 SSH, PAM(Pluggable Authentication Modules, 인증 모듈), sysctl 커널 파라미터까지 한 번에 바꾸려다가 접속 정책 꼬여서 삽질 좀 했습니다 ㅎㅎ

    그래서 이후부터는 아래 순서로 정리했습니다.

    1. 현재 상태 수집
    2. 위험도 높은 항목 우선 적용
    3. 변경 전 백업
    4. 적용 후 즉시 검증
    5. 운영 표준 문서화

    이 순서가 별거 아닌 것 같아도 진짜 중요합니다. 특히 보안 감사 대응에서는 “무엇을 바꿨는지”보다 “왜 이렇게 바꿨고, 어떻게 검증했는지”가 더 중요할 때가 많더라고요.

    실전 구현 1: 현재 서버 설정과 계정 상태 점검

    가장 먼저 한 일은 현황 파악이었습니다. 서버 설정을 바꾸기 전에 지금 어떤 계정이 있고, SSH가 어떻게 열려 있고, 권한이 어떤지 보는 거죠. 아래 명령어는 배포판에 크게 구애받지 않고 기본 점검에 쓸 수 있습니다.

    # 접속 중인 사용자 확인
who

# 최근 로그인 이력 확인
last -a | head

# sudo 권한 그룹 확인
getent group sudo
getent group wheel

# root 원격 로그인 설정 확인
grep -Ei '^PermitRootLogin' /etc/ssh/sshd_config

# 패스워드 정책 관련 기본 설정 확인
grep -E 'PASS_MAX_DAYS|PASS_MIN_DAYS|PASS_WARN_AGE' /etc/login.defs

# 중요 파일 권한 확인
ls -l /etc/passwd /etc/shadow /etc/group /etc/ssh/sshd_config

    제가 직접 해보니 여기서 이미 문제점이 꽤 보였습니다. 예전 작업용 계정이 남아 있거나, SSH 설정 파일에 주석만 있고 실설정은 애매한 경우도 있었고요. 이런 상태에서 바로 강화 설정부터 넣으면, 나중에 왜 접속이 막혔는지 추적이 어려워집니다.

    CIS 벤치마크 서버 보안 점검을 위한 리눅스 터미널 이미지

    계정 상태, SSH 설정, 파일 권한을 터미널에서 점검하는 실전 분위기의 이미지입니다.

    실전 구현 2: SSH와 계정 정책부터 우선 강화

    초기 단계에서는 영향도가 크지만 효과도 분명한 항목부터 만졌습니다. 제 경험상 SSH와 계정 정책만 정리해도 보안 감사 결과가 꽤 달라지더라고요.

    1. root 직접 로그인 차단

    sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo vi /etc/ssh/sshd_config
    PermitRootLogin no
PasswordAuthentication yes
X11Forwarding no
MaxAuthTries 4
ClientAliveInterval 300
ClientAliveCountMax 0
    sudo sshd -t
sudo systemctl reload sshd

    여기서 중요한 건 reload 전에 반드시 문법 검증입니다. 저도 예전에 오타 하나로 SSH 데몬이 reload 실패해서 콘솔로 붙었던 적이 있습니다. 원격 서버면 정말 식은땀 납니다.

    2. 접속 허용 사용자 제한

    # /etc/ssh/sshd_config 예시
AllowUsers adminuser deployuser

    운영 서버는 접속 대상이 많을수록 관리가 어렵습니다. 그래서 관리 계정은 분리하고, 실제 접속이 필요한 사용자만 명시하는 편이 훨씬 낫더라고요.

    3. 패스워드 정책 정리

    sudo vi /etc/login.defs
    PASS_MAX_DAYS   90
PASS_MIN_DAYS   1
PASS_WARN_AGE   7

    환경에 따라 MFA(Multi-Factor Authentication, 다중 인증)나 키 기반 인증 위주로 운영하는 경우도 있겠지만, 기본 정책이 비어 있으면 보안 감사에서 자주 지적됩니다. 그래서 사용 여부와 별개로 기준은 잡아두는 편이 좋더라고요.

    실전 구현 3: 파일 권한과 감사 로그 보강

    그다음은 Linux 보안에서 기본 중의 기본인 파일 권한과 로그입니다. 평소엔 잘 눈에 안 띄는데, 사고 나면 가장 먼저 후회하는 부분이기도 하죠.

    중요 파일 권한 조정

    sudo chown root:root /etc/ssh/sshd_config
sudo chmod 600 /etc/ssh/sshd_config
sudo chown root:root /etc/shadow
sudo chmod 000 /etc/shadow
sudo chmod 644 /etc/passwd /etc/group

    배포판 기본값과 다를 수 있으니 적용 전 확인은 필수입니다. 특히 자동화 도구나 이미지 템플릿이 이미 정책을 넣어둔 경우가 있어서, 무작정 덮어쓰면 오히려 표준에서 벗어날 수 있습니다.

    sudo 로그 남기기

    sudo visudo
    Defaults logfile="/var/log/sudo.log"

    이 설정은 나중에 보안 감사뿐 아니라 내부 추적에도 꽤 유용했습니다. 누가 언제 어떤 권한 명령을 쳤는지 보는 것만으로도 원인 파악 속도가 많이 달라지거든요.

    불필요 서비스 점검

    systemctl list-unit-files --type=service --state=enabled
ss -tulpen

    여기서 안 쓰는 서비스가 떠 있으면 정리합니다. 예를 들어 테스트용으로 잠깐 열어둔 데몬이 계속 살아 있는 경우가 꽤 있습니다. 보안은 거창한 장비보다도 이런 기본 서버 설정 정리에서 차이가 납니다.

    CIS 벤치마크 서버 보안을 위한 SSH 설정과 감사 로그 구성 이미지

    SSH 접근 제어와 sudo 로그 기록 흐름을 한눈에 보여주는 구성 다이어그램 이미지입니다.

    ⚠️ 실제로 겪었던 문제와 트러블슈팅

    이 부분이 제일 중요할 수도 있습니다. 문서만 보면 다 간단해 보이는데, 실제 적용하면 꼭 한두 군데서 걸립니다.

    문제 1. SSH 설정 반영 후 접속 실패

    원인은 대부분 두 가지였습니다. 하나는 AllowUsers에 현재 운영 계정을 빼먹은 경우, 다른 하나는 sshd_config 오타였습니다.

    • 해결 방법 1: 설정 변경 전 현재 세션은 유지한 상태에서 새 세션으로 접속 테스트
    • 해결 방법 2: sshd -t로 문법 검증 후 reload
    • 해결 방법 3: 가능하면 콘솔 접속 경로 확보 후 작업

    문제 2. 보안 감사는 통과했는데 운영팀이 불편해함

    이것도 많이 겪습니다. 정책은 강화됐는데 현업이 쓰기 불편하면 결국 예외 요청이 쌓이거든요. 그래서 저는 서버 역할별로 기준을 나눴습니다. 배치 서버, 운영 웹 서버, 점프 서버(Jump Server, 중간 접속용 서버)를 같은 기준으로 묶지 않았습니다.

    서버 유형 강화 우선 항목 주의점
    운영 웹 서버 SSH 제한, 로그 강화, 불필요 서비스 제거 배포 계정 접근 경로 확인
    점프 서버 계정 감사, sudo 로그, 접속 기록 보관 관리자 편의성과 통제 균형
    배치 서버 계정 만료 정책, 스크립트 권한 점검 자동 실행 계정 영향 확인

    문제 3. 자동화 스크립트가 갑자기 실패

    패스워드 정책이나 파일 권한을 강화하고 나면 기존 스크립트가 가정하고 있던 조건이 깨질 수 있습니다. 저도 키 파일 권한을 조정한 뒤 일부 배포 스크립트가 실패한 적이 있었는데, 원인을 찾고 보니 권한 검사가 더 엄격해졌더라고요. 드디어 됐다 싶다가 다시 되돌아가서 확인하는 과정, 다들 한 번쯤 있으시죠.

    검증과 결과: 무엇이 달라졌나

    설정 적용 후에는 꼭 검증을 했습니다. 그냥 파일만 바뀌었다고 끝내면 안 됩니다. 실제 접속, 권한, 로그, 서비스 상태를 같이 봐야 하거든요.

    # SSH 설정 최종 확인
sshd -T | egrep 'permitrootlogin|maxauthtries|clientaliveinterval|clientalivecountmax'

# sudo 로그 확인
sudo tail -n 20 /var/log/sudo.log

# 열려 있는 포트 점검
ss -tulpen

# 최근 인증 로그 확인
sudo tail -n 50 /var/log/auth.log

    검증 단계에서 제가 체감한 효과는 크게 네 가지였습니다.

    1. 보안 감사 대응 속도 향상: 항목별 근거를 바로 제시하기 쉬워졌습니다.
    2. 설정 표준화: 서버마다 제각각이던 서버 설정이 어느 정도 정리됐습니다.
    3. 추적성 확보: sudo와 인증 로그가 정리되니 사고 분석이 편해졌습니다.
    4. 운영 리스크 감소: root 직접 로그인 같은 명백한 위험 요소를 줄였습니다.

    물론 한 번 적용했다고 끝은 아닙니다. 하지만 CIS 벤치마크 서버 보안 기준으로 최소선만 맞춰도, 평소 불안하게 남아 있던 부분이 꽤 정리됩니다. 특히 보안 감사 준비할 때 체감 차이가 큽니다.

    CIS 벤치마크 서버 보안 적용 후 보안 감사 검증 대시보드 이미지

    적용 전후 점검 항목과 로그 확인 결과를 시각적으로 보여주는 대시보드 형태의 이미지입니다.

    정리: 제가 배운 점과 다음 단계

    이번 적용에서 다시 느낀 건, 보안은 대단한 도구보다도 기본을 얼마나 꾸준히 맞추느냐가 훨씬 중요하다는 점이었습니다. Linux 보안 강화는 막연히 어렵게 느껴지지만, 실제로는 계정 정책, SSH, 권한, 로그처럼 반복해서 나오는 핵심 축이 있습니다. 저도 처음엔 항목이 많아서 겁먹었는데, 하나씩 잘라서 적용하니 생각보다 정리가 되더라고요.

    혹시 지금 운영 중인 서버가 있고, 보안 감사 일정이 다가오고 있다면 이렇게 시작해보세요.

    1. 현재 계정과 SSH 설정부터 점검합니다.
    2. root 로그인 차단과 접근 사용자 제한을 우선 적용합니다.
    3. 중요 파일 권한과 로그 기록을 보강합니다.
    4. 변경 직후 검증 명령으로 바로 확인합니다.
    5. 서버 역할별 예외 정책을 문서화합니다.

    이 흐름만 잡혀도 서버 설정 품질이 눈에 띄게 좋아집니다. 다음 글에서는 Ansible(앤서블, 자동화 도구) 같은 구성 관리 방식으로 이 작업을 반복 가능하게 만드는 방법도 다뤄볼 예정입니다. 이전 글에서 다뤘던 로그 관리나 계정 표준화 주제와도 연결해서 보시면 더 이해가 쉬우실 거예요.

    CIS 벤치마크 서버 보안 적용 전후 비교 요약 이미지

    적용 전후 차이, 핵심 점검 항목, 다음 단계 체크리스트를 요약한 인포그래픽 이미지입니다.

    자주 묻는 질문

    Q1. CIS 벤치마크 항목을 모두 적용해야 하나요?

    아닙니다. 서비스 특성과 운영 환경에 따라 예외가 생길 수 있습니다. 중요한 건 근거 없이 빼는 게 아니라, 왜 제외했는지 설명 가능해야 한다는 점입니다.

    Q2. 기존 운영 서버에도 바로 적용해도 될까요?

    가능은 하지만, 반드시 백업과 검증 경로를 확보한 뒤 단계적으로 적용하는 걸 권장합니다. 특히 원격 접속 정책은 새 세션으로 꼭 테스트해보세요.

    Q3. 보안 감사 대응에 실제 도움이 되나요?

    네, 꽤 도움이 됩니다. 적어도 계정 정책, 접근 통제, 로그 추적성 같은 기본 항목에서 설명이 훨씬 쉬워집니다. 저도 실제로 써보니까 이 부분이 가장 체감되더라고요.

  • [보안] Fail2ban 오탐 줄이기: 로그 분석과 정규식 최적화 전략

    [보안] Fail2ban 오탐 줄이기: 로그 분석과 정규식 최적화 전략

    목차

    [보안] Fail2ban 오탐 줄이기: 로그 분석과 정규식 최적화 전략

    Fail2ban 오탐 때문에 정상 사용자가 차단되는 상황, 한 번쯤 겪어보셨을 겁니다. 저도 홈랩이랑 외부에 노출된 몇몇 서비스에서 비슷한 Fail2ban 오탐 문제를 꽤 겪었습니다. 처음엔 “차단이 잘 되면 좋은 거 아닌가?” 싶었는데, 실제 운영에서는 이야기가 좀 다르더라고요. 특히 SSH, Nginx, 메일 서비스처럼 로그 형식이 조금만 달라져도 Fail2ban 정규식이 과하게 반응해서 멀쩡한 요청까지 공격으로 오인하는 경우가 생깁니다. 이번 글에서는 제가 실제로 정리해 둔 방식대로, 로그 분석부터 정규식(regex, 정규 표현식) 튜닝까지 단계별로 풀어보겠습니다.

    핵심은 단순합니다. 차단 수치를 무작정 올리거나 <code>maxretry만 만지는 게 아니라, 먼저 로그를 읽고 패턴을 이해한 다음, 그에 맞는 필터를 만드는 겁니다. 이 흐름만 잡히면 침입 방지 시스템을 좀 더 안정적으로 운영할 수 있습니다.

    Fail2ban 오탐 분석과 로그 처리 흐름을 보여주는 아키텍처 이미지

    Fail2ban 오탐을 줄이기 위해 로그 수집, 패턴 분석, 정규식 튜닝, 차단 검증까지 이어지는 전체 흐름을 한눈에 보여주는 이미지입니다.

    왜 Fail2ban 오탐이 생길까요?

    쉽게 말해 Fail2ban은 로그를 보고 판단합니다. 네트워크 패킷 자체를 해석하는 게 아니라, 서비스가 남긴 텍스트 로그를 기준으로 차단하거든요. 그래서 서비스 설정이 바뀌거나 프록시(Proxy, 중계 서버)가 앞단에 추가되면, 기존 필터가 예상하지 못한 문자열이 로그에 섞이게 됩니다.

    예를 들어 이런 경우가 대표적입니다.

    • 리버스 프록시(Reverse Proxy, 역방향 프록시) 뒤에 있어서 실제 클라이언트 IP 대신 프록시 IP가 보이는 경우
    • 애플리케이션 로그 포맷이 커스텀되어 기본 필터와 맞지 않는 경우
    • 에러 로그와 경고 로그가 비슷한 문장 구조를 가져서 실패 이벤트로 잘못 매칭되는 경우
    • 한글 메시지 또는 추가 모듈 로그가 섞여 정규식이 과하게 넓게 잡히는 경우

    저도 예전에 Nginx 뒤에 붙은 인증 서비스에서 Fail2ban 오탐이 계속 나서 삽질 좀 했습니다. 원인은 단순했어요. 기존 필터가 authentication failure 같은 문자열만 보고 잡고 있었는데, 실제로는 봇 공격이 아니라 브라우저 재시도 요청 일부까지 걸리고 있었거든요.

    Fail2ban 동작 원리와 정규식 최적화 포인트

    Fail2ban은 크게 세 가지를 봅니다. 필터(filter), 저널 또는 로그 소스(log source), 그리고 차단 정책(jail)입니다. 여기서 Fail2ban 오탐을 줄이는 핵심은 필터입니다.

    구성 요소 역할 오탐과의 관계
    Filter 로그에서 실패 패턴 추출 정규식이 넓으면 정상 로그도 공격으로 인식
    Jail 재시도 횟수, 차단 시간, 대상 서비스 설정 필터가 잘못되면 정책이 정상 사용자에게 적용
    Action iptables, nftables 등으로 차단 수행 실수한 필터가 실제 차단으로 이어짐

    여기서 중요한 포인트! 정규식은 많이 잡는 게 좋은 게 아닙니다. 정확하게 잡는 게 중요합니다.

    제가 보통 보는 기준은 이렇습니다.

    1. 실패 이벤트를 명확히 나타내는 고정 문자열이 있는가
    2. IP 주소 위치가 일정한가
    3. 정상 요청과 실패 요청을 구분하는 문장이 분리되는가
    4. 시간대별, 서비스별 로그 변형이 있는가

    이 네 가지만 점검해도 Fail2ban 오탐 확률이 꽤 줄어듭니다.

    로그 분석 먼저: Fail2ban 오탐 줄이기의 출발점

    정규식을 바로 고치기 전에 반드시 로그를 먼저 봐야 합니다. 이걸 건너뛰면 거의 감으로 튜닝하게 되는데, 그러면 나중에 더 크게 꼬입니다. 실제로 써보니까 로그 20줄 제대로 보는 게 설정 20번 바꾸는 것보다 훨씬 빠르더라고요.

    1. 최근 차단 이벤트 확인

    sudo fail2ban-client status
sudo fail2ban-client status sshd

    이 명령으로 활성화된 jail과 현재 차단된 IP를 먼저 확인합니다. 어떤 jail이 유독 많이 반응하는지부터 보는 거죠.

    2. 원본 로그에서 실패 패턴 확인

    sudo tail -n 200 /var/log/auth.log
sudo journalctl -u ssh --since "1 hour ago"
sudo grep -i "fail\|invalid\|error" /var/log/auth.log | tail -n 50

    시스템마다 로그 경로는 다를 수 있습니다. Debian/Ubuntu 계열은 auth.log, systemd 환경은 journalctl 기반으로 보는 경우가 많습니다.

    3. 정상 로그와 실패 로그를 같이 비교

    이 단계가 진짜 중요합니다. Fail2ban 오탐은 보통 실패 로그만 보면 안 보입니다. 정상 사용자 접속, 키 교환, 세션 종료 같은 문장까지 같이 봐야 차이가 보이거든요.

    sudo grep -E "Failed password|Accepted password|Invalid user|Connection closed" /var/log/auth.log | tail -n 100

    제가 자주 하는 방식은 실패 케이스와 정상 케이스를 각각 10~20줄씩 복사해서 옆에 두고 비교하는 겁니다. 어떤 단어가 실패에서만 나오는지 찾는 거죠.

    Fail2ban 오탐을 줄이기 위한 정상 로그와 실패 로그 비교 이미지

    정상 로그인 로그와 실패 로그인 로그를 나란히 비교하면서 정규식에 포함해야 할 문자열과 제외해야 할 문자열을 구분하는 과정을 표현한 이미지입니다.

    실전 구현: Fail2ban 필터와 정규식 다듬기

    이제 본격적으로 Fail2ban 정규식을 손보겠습니다. 여기서는 SSH 계열 로그를 예시로 들지만, 원리는 Nginx나 메일 서비스에도 그대로 적용됩니다.

    1. 기존 필터 확인

    sudo ls /etc/fail2ban/filter.d/
sudo sed -n '1,200p' /etc/fail2ban/filter.d/sshd.conf

    기존 필터를 무작정 덮어쓰는 건 추천하지 않습니다. 기본 파일은 참고만 하고, 별도 커스텀 필터를 만드는 편이 유지보수에 좋습니다.

    2. 커스텀 필터 작성

    # /etc/fail2ban/filter.d/sshd-local.conf
[Definition]
failregex = ^%(__prefix_line)sFailed password for (?:invalid user )?.* from <HOST> port \d+ ssh2$
            ^%(__prefix_line)sInvalid user .* from <HOST>$
ignoreregex = ^%(__prefix_line)sConnection closed by authenticating user .*$
              ^%(__prefix_line)sAccepted publickey for .*$

    여기서 의도는 명확합니다.

    • failregex는 실패로 확정할 수 있는 로그만 좁게 잡습니다
    • ignoreregex는 헷갈릴 수 있는 정상 또는 무해한 로그를 제외합니다
    • <HOST>는 Fail2ban이 IP를 추출할 때 사용하는 플레이스홀더입니다

    처음엔 이게 뭔가 싶었는데, 실제로는 ignoreregex를 잘 쓰는 순간 Fail2ban 오탐이 확 줄더라고요. 많은 분들이 failregex만 만지는데, 사실 둘을 같이 봐야 합니다.

    3. jail 설정 분리

    # /etc/fail2ban/jail.local
[sshd-local]
enabled = true
filter = sshd-local
port = ssh
logpath = /var/log/auth.log
maxretry = 5
findtime = 10m
bantime = 30m

    maxretry, findtime, bantime은 정책값입니다. Fail2ban 오탐이 자주 난다고 무조건 maxretry를 크게 올리면 실제 공격 대응이 느슨해질 수 있습니다. 그래서 저는 먼저 필터를 좁히고, 그 다음 정책을 조정하는 순서를 지킵니다.

    4. 정규식 테스트

    sudo fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd-local.conf

    이 명령은 거의 필수입니다. 실제 로그 파일에 대해 내가 만든 정규식이 몇 줄을 매칭하는지 보여주거든요. 여기서 정상 로그가 잡히면 배포 전에 바로 알 수 있습니다. 드디어 됐다! 싶은 순간도 보통 여기서 옵니다.

    Fail2ban 정규식 테스트와 로그 분석 검증 화면 이미지

    fail2ban-regex 명령으로 필터가 어떤 로그를 매칭하는지 검증하고, 예상치 못한 정상 로그가 걸리는 부분을 찾아내는 과정을 시각화한 이미지입니다.

    ⚠️ 제가 실제로 겪었던 Fail2ban 오탐 패턴과 해결법

    운영하다 보면 생각보다 단순한 이유로 오탐이 납니다. 아래는 제가 자주 본 패턴입니다.

    프록시 뒤에서 IP가 꼬이는 경우

    Nginx 같은 리버스 프록시 뒤에 인증 서비스가 있으면, 애플리케이션 로그에 원본 IP 대신 프록시 IP가 찍히는 경우가 있습니다. 그러면 한 사용자의 실패가 아니라 프록시 전체가 문제처럼 보일 수 있죠. 이럴 땐 애플리케이션 로그 포맷에서 실제 클라이언트 IP가 어디에 기록되는지 먼저 확인해야 합니다.

    로그 문장이 비슷해서 정상 이벤트가 같이 잡히는 경우

    예를 들어 Connection closed 같은 문장은 실패 직후에도 보이고 정상 종료에도 보일 수 있습니다. 이런 문장을 넓게 잡아버리면 Fail2ban 오탐이 생깁니다. 그래서 저는 실패 판단용 문자열은 가급적 Failed, Invalid user처럼 의미가 분명한 것만 씁니다.

    한 줄 정규식으로 모든 걸 해결하려는 경우

    이거 정말 많이 봅니다. 정규식을 너무 똑똑하게 만들려고 하면 나중에 본인도 못 읽게 됩니다. 차라리 여러 줄의 failregex로 케이스를 나누는 게 유지보수에 훨씬 좋습니다.

    테스트 없이 서비스 재시작하는 경우

    저도 초반에 이 실수 했었습니다. 필터 바꾸고 바로 재시작했는데, 다음 날 정상 사용자 한 명이 접속이 안 된다고 연락이 오더라고요. 그 뒤로는 무조건 fail2ban-regex 테스트부터 합니다.

    검증 절차: 설정 후 무엇을 확인해야 할까

    설정을 넣었다고 끝이 아닙니다. Fail2ban 오탐은 운영 중에 드러나는 경우가 많아서, 적용 후 검증 루틴이 필요합니다.

    1. 필터 문법 테스트
    2. 실제 로그에 대한 매칭 수 확인
    3. 서비스 재시작 또는 설정 리로드
    4. 최근 1시간 로그에서 정상 이벤트가 차단 대상에 포함되는지 확인
    5. 차단된 IP 목록과 대응 로그를 대조
    sudo fail2ban-client reload
sudo fail2ban-client status sshd-local
sudo fail2ban-client get sshd-local banip

    가능하면 테스트 계정으로 정상 로그인과 실패 로그인을 각각 발생시켜 보는 것도 좋습니다. 홈랩 환경에서는 이런 검증을 해보기 좋아서, 저도 새 필터 만들면 꼭 직접 재현해 봅니다.

    검증 체크리스트

    • 정상 로그인 이벤트가 failregex에 잡히지 않는가
    • 실패 이벤트는 빠짐없이 잡히는가
    • 차단된 IP가 실제 공격 주체와 일치하는가
    • 로그 포맷 변경 시 필터가 깨질 가능성은 없는가

    결과 정리: Fail2ban 오탐 줄이기 전후 비교

    점검 항목 오탐 줄이기 전 오탐 줄인 후
    필터 범위 에러 비슷한 문자열을 넓게 포함 실패로 확정 가능한 문장만 포함
    정상 사용자 영향 재시도나 세션 종료 로그까지 차단 가능 정상 이벤트는 ignoreregex로 제외
    운영 안정성 차단 이유 추적이 어려움 왜 차단됐는지 로그와 정규식이 명확함
    유지보수 한 줄짜리 복잡한 정규식에 의존 케이스별로 읽기 쉬운 필터 분리

    결국 중요한 건 “많이 막는 것”보다 “정확히 막는 것”입니다. 서버 보안은 강하게만 간다고 좋은 게 아니더라고요. 특히 운영 환경에서는 정상 사용자의 경험도 같이 지켜야 하니까요.

    Fail2ban 오탐 감소 후 차단 결과를 검증하는 대시보드 이미지

    Fail2ban 오탐이 줄어든 뒤 차단 로그와 정상 접속 로그가 명확하게 구분되고, 관리자 입장에서 추적이 쉬워진 상태를 보여주는 결과 이미지입니다.

    자주 묻는 질문: Fail2ban 오탐 대응 FAQ

    Q1. maxretry만 올리면 해결되지 않나요?

    일시적으로는 덜 민감해질 수 있습니다. 근데 근본 해결은 아닙니다. 정규식이 잘못되면 정상 로그를 계속 실패로 판단하니까요.

    Q2. ignoreregex는 꼭 써야 하나요?

    반드시 필요한 건 아니지만, 실제 운영에서는 꽤 유용합니다. 특히 비슷한 형식의 정상 로그가 많은 서비스에서는 Fail2ban 오탐 방지에 효과가 큽니다.

    Q3. 로그 분석은 어느 정도까지 해야 하나요?

    최소한 정상 이벤트와 실패 이벤트를 각각 여러 줄씩 비교해 보시는 걸 권합니다. 한두 줄 보고 만들면 예외 케이스를 놓치기 쉽습니다.

    Q4. 기본 필터를 수정해도 되나요?

    가능은 하지만 권장하지 않습니다. 배포판 업데이트나 패키지 변경 시 추적이 어려워질 수 있어서, 별도 로컬 필터 파일로 분리하는 편이 낫습니다.

    마무리: 로그를 읽는 습관이 Fail2ban 운영을 살립니다

    이번 글에서는 Fail2ban 오탐을 줄이기 위해 로그를 어떻게 읽고, Fail2ban 정규식을 어떤 기준으로 다듬어야 하는지 정리해봤습니다. 저도 처음엔 단순히 차단 시간이랑 재시도 횟수만 조정했었는데, 결국 답은 로그 안에 있더라고요. 실제로 해보니까 정규식을 똑똑하게 짜는 것보다, 서비스 로그가 어떤 의미를 가지는지 먼저 이해하는 게 훨씬 중요했습니다.

    혹시 지금도 정상 사용자가 자꾸 차단돼서 골치 아프시다면, 오늘 바로 fail2ban-regex부터 돌려보세요. 거기서 의외로 실마리가 바로 나옵니다. 다음 글에서는 Nginx 액세스 로그 기준으로 봇 요청과 인증 실패를 분리해서 침입 방지 시스템 정책을 나누는 방법도 다뤄볼 예정입니다. 이전 글에서 방화벽 정책과 로그 로테이션(log rotation, 로그 순환) 정리해두셨다면 같이 보시면 흐름이 더 잘 잡히실 겁니다.

    로그 분석, 정규식 최소화, ignoreregex 활용, 테스트 검증이라는 네 가지 핵심 원칙을 한 장으로 정리한 요약 이미지입니다.

  • [Proxmox] Proxmox VE 보안 강화 체크리스트 10가지: 안전한 가상화 환경 구축

    [Proxmox] Proxmox VE 보안 강화 체크리스트 10가지: 안전한 가상화 환경 구축

    안녕하세요! 13년차 인프라 엔지니어, 13년차의 서버실 운영자입니다. 오늘은 제가 홈랩(Homelab)에서 Proxmox VE를 운영하면서 겪었던 일들과 함께, 여러분의 소중한 가상화 환경을 더욱 안전하게 보호할 수 있는 Proxmox 보안 강화 체크리스트 10가지를 공유해볼까 합니다. 사실 처음엔 저도 ‘내 개인 서버인데 뭐 그렇게까지 해야 하나?’ 싶었거든요. 근데 한번 호되게 당하고 나서는 생각이 싹 바뀌었습니다. 인터넷에 연결된 모든 시스템은 잠재적인 공격 대상이 될 수 있다는 걸 뼈저리게 느꼈죠. 이 글을 통해 여러분은 저처럼 삽질하지 마시고, 처음부터 튼튼한 Proxmox VE 환경을 구축하시길 바랍니다. 이 체크리스트만 따라 해도 웬만한 위협에서는 훨씬 안전해질 거예요! 자, 그럼 시작해볼까요? 🎉

    Proxmox VE의 구성 요소와 각 영역에 적용될 보안 조치들을 시각적으로 보여주는 다이어그램입니다.

    1. 강력한 관리자 비밀번호와 SSH 키 인증 ✅

    보안의 가장 기본은 뭐니 뭐니 해도 비밀번호거든요. Proxmox VE 설치 시 설정하는 root 계정 비밀번호는 물론, 추가로 생성하는 모든 사용자 계정 비밀번호는 길고 복잡하게 만들어야 합니다. 숫자, 특수문자, 대소문자를 섞어서 최소 12자리 이상이죠. 저는 보통 16자리 이상으로 만듭니다.

    그리고 SSH(Secure Shell) 접속 시에는 비밀번호 인증 대신 SSH 키 인증(SSH Key Authentication)을 사용하는 게 훨씬 안전해요. 비밀번호는 무작위 대입 공격(Brute-force attack)에 취약하거든요. 제가 직접 해보니 키 인증 한 번 설정해두면 훨씬 편하고 안전하더라고요. 처음엔 좀 번거롭지만, 한 번 해두면 두고두고 안심입니다.

    # 1. SSH 키 생성 (클라이언트 PC에서 실행)
ssh-keygen -t rsa -b 4096 -C "[email protected]"

# 2. Proxmox VE 서버로 공개 키 복사
ssh-copy-id -i ~/.ssh/id_rsa.pub root@your_proxmox_ip

# 3. 비밀번호 없이 SSH 접속 확인
ssh root@your_proxmox_ip

    이렇게 하면 다음부터는 비밀번호 입력 없이 SSH에 접속할 수 있습니다. 💡 팁: ssh-agent를 활용하면 키 비밀번호(passphrase)도 한 번만 입력해도 되더라고요.

    2. Proxmox VE 웹 UI 2단계 인증 (2FA) 🛡️

    Proxmox VE의 웹 관리 UI는 모든 설정의 핵심이거든요. 이곳이 뚫리면 모든 게 끝장입니다. 그래서 2단계 인증(Two-Factor Authentication, 2FA)은 선택이 아닌 필수죠. 구글 OTP(Google Authenticator) 같은 TOTP(Time-based One-Time Password) 앱을 연동해서 로그인할 때마다 일회용 코드를 입력하게 하는 거예요.

    제가 직접 설정해보니 생각보다 간단하더라고요. Proxmox VE 웹 UI에 로그인해서 [Datacenter] > [Permissions] > [Users]로 가서 여러분의 사용자 계정을 선택한 다음, [TFA] 탭에서 [Add] > [TOTP Factor]를 선택하면 됩니다. 그러면 QR 코드가 나오는데, 이걸 OTP 앱으로 스캔하면 끝! 로그인할 때 아이디/비밀번호 입력 후 OTP 코드를 한 번 더 입력하게 됩니다.

    Proxmox VE 웹 UI 2단계 인증 (TOTP) 설정 화면

    Proxmox VE 웹 인터페이스에서 TOTP(Time-based One-Time Password) 2단계 인증을 활성화하는 과정을 보여주는 스크린샷입니다.

    3. SSH 기본 설정 강화 🔒

    앞서 SSH 키 인증을 설정했다면, 이제 sshd 설정을 강화할 차례예요. 기본 설정을 그대로 두면 보안에 취약할 수 있거든요. 특히 root 계정으로 바로 로그인하는 것을 막고, 비밀번호 인증도 비활성화하는 것이 좋습니다. 저는 이 설정을 안 했다가 한동안 SSH 무작위 대입 공격 시도 로그를 보면서 식겁했던 경험이 있습니다. ㅎㅎ

    # Proxmox VE 서버에서 실행

# 1. SSH 설정 파일 백업 (중요!)
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

# 2. 설정 파일 수정
nano /etc/ssh/sshd_config

# 다음 라인들을 찾아서 수정하거나 추가합니다.
# PermitRootLogin no             # root 계정 직접 로그인 금지
# PasswordAuthentication no      # 비밀번호 인증 비활성화 (키 인증 필수)
# Port 2222                      # SSH 기본 포트 22번 대신 다른 포트 사용 (예: 2222)

# 3. SSH 서비스 재시작
systemctl restart sshd

    ⚠️ 주의사항: PermitRootLogin no와 PasswordAuthentication no를 설정하기 전에, 반드시 일반 사용자 계정을 만들고 SSH 키 인증으로 로그인 가능한지 확인해야 합니다. 안 그러면 서버에 접속하지 못하는 불상사가 발생할 수 있거든요! 저도 한 번 실수로 root 계정으로만 접속 가능한 상태에서 이 설정을 했다가 콘솔에 매달려야 했던 적이 있습니다… 😅

    4. Proxmox VE 내장 방화벽 활용 🔥

    Proxmox VE는 자체적으로 방화벽(Firewall) 기능을 제공하는데, 정말 강력해요. 호스트 레벨과 VM(Virtual Machine)/컨테이너(Container) 레벨 모두에서 네트워크 보안(Network Security)을 구현할 수 있거든요. Ingress(인그레스, 외부에서 내부로 들어오는 트래픽)와 Egress(이그레스, 내부에서 외부로 나가는 트래픽) 규칙을 세밀하게 제어할 수 있습니다.

    제가 홈랩에서 가장 먼저 하는 일 중 하나가 바로 이 방화벽 설정입니다. 불필요한 포트는 모두 막아두고, 필요한 포트(예: Proxmox 웹 UI 8006, SSH 변경 포트)만 열어두는 거죠. VM마다 다른 보안 정책을 적용할 수 있어서 정말 유용하더라고요.

    # Proxmox VE 호스트 레벨 방화벽 활성화
pve-firewall start
pve-firewall enable

# 방화벽 규칙 설정은 Web UI를 권장합니다:
# [Datacenter] > [Firewall] 또는 [Node] > [Firewall]
# [VM/Container] > [Firewall]

    이건 Proxmox VE의 꽃 같은 기능이라고 생각합니다. 네트워크 세그멘테이션과 함께 사용하면 시너지가 정말 엄청나거든요!

    5. 네트워크 세그멘테이션 🌐

    네트워크 세그멘테이션(Network Segmentation)은 물리적 또는 가상적으로 네트워크를 여러 개의 작은 구역으로 나누는 것을 의미해요. 예를 들어, Proxmox VE 관리용 네트워크, VM 서비스용 네트워크, 스토리지용 네트워크 등을 분리하는 거죠. 이렇게 하면 한 구역이 뚫려도 다른 구역으로의 확산을 막을 수 있습니다.

    저는 보통 물리적 네트워크 인터페이스 카드(NIC)를 여러 개 사용하거나, VLAN(Virtual Local Area Network)을 활용해서 네트워크를 나눕니다. 관리 네트워크는 외부 인터넷과 직접 연결되지 않도록 하고, VM 서비스 네트워크만 필요한 포트만 열어두죠. 처음엔 귀찮아서 한데 뭉쳐놨었는데, 나중에 문제가 생겼을 때 트러블슈팅도 훨씬 어렵고, 보안적으로도 너무 취약하더라고요. 그래서 지금은 무조건 나누는 걸 원칙으로 합니다.

    Proxmox VE에서는 vmbr0, vmbr1 등 리눅스 브릿지(Linux Bridge)를 활용해서 가상 네트워크를 구성해요. 물리 NIC와 연결하거나, VLAN 태그를 지정할 수 있죠.

    6. Proxmox VE 시스템 최신 유지 🔄

    소프트웨어는 항상 최신 상태로 유지하는 게 중요합니다. Proxmox VE도 마찬가지거든요. 개발팀은 지속적으로 보안 취약점을 패치하고 새로운 기능을 추가하니까요. 오래된 버전은 알려진 취약점에 노출될 위험이 크거든요.

    저는 정기적으로 업데이트를 확인하고 적용하는 루틴을 가지고 있습니다. 한 달에 한 번 정도는 꼭 확인해서 업데이트를 진행하죠. 물론 업데이트 전에 백업은 필수예요! 업데이트하다가 예기치 않은 문제가 생길 수도 있거든요. 이 부분은 제가 나중에 백업 관련 글로 자세히 다룰 예정입니다.

    # Proxmox VE 업데이트
apt update
apt dist-upgrade

# 재부팅이 필요한 경우 (커널 업데이트 등)
reboot

    apt dist-upgrade는 새로운 커널이나 주요 패키지 업데이트를 포함하므로, 항상 변경 내용을 확인하고 신중하게 진행해야 합니다. 특히 프로덕션 환경이라면 더더욱 그렇고요!

    7. 백업 및 복구 전략 보안 💾

    아무리 보안을 잘해도 사고는 언제든 일어날 수 있어요. 랜섬웨어 공격, 하드웨어 고장, 실수로 인한 데이터 손실 등 다양한 위협으로부터 데이터를 보호하기 위해 백업은 필수입니다. 그리고 이 백업 데이터 자체도 안전하게 관리해야 합니다.

    저는 Proxmox Backup Server (PBS)를 활용해서 백업을 하더라고요. PBS는 효율적인 증분 백업(Incremental Backup)과 중복 제거(Deduplication)는 물론, 백업 암호화(Backup Encryption) 기능까지 제공해서 데이터를 안전하게 보관할 수 있게 해줍니다. 백업 데이터를 외부(Off-site) 스토리지에 보관하는 것도 중요해요. 물리적으로 다른 위치에 두는 거죠.

    그리고 백업이 잘 되는지 주기적으로 복구 테스트를 해보는 것도 정말 중요합니다. 백업만 있고 복구가 안 되면 아무 소용 없잖아요? 제가 예전에 백업은 잘 했는데, 복구 테스트를 안 했다가 막상 필요할 때 복구가 안 돼서 식은땀 흘렸던 적이 있어요… 😅

    Proxmox VE 보안 강화 체크리스트 10가지 요약 인포그래픽

    Proxmox VE 보안 강화의 핵심 10가지 항목을 요약하고 시각적으로 강조한 인포그래픽입니다.

    8. 사용자 및 권한 관리 (RBAC) 👥

    Proxmox VE는 역할 기반 접근 제어(Role-Based Access Control, RBAC)를 지원해요. 관리자 계정 하나로 모든 걸 다 하는 것보다는, 필요한 최소한의 권한만 부여하는 최소 권한 원칙(Principle of Least Privilege)을 지키는 게 중요합니다. 예를 들어, VM만 관리하는 사용자에게는 스토리지나 네트워크 설정 권한을 주지 않는 거죠.

    Proxmox VE 웹 UI에서 [Datacenter] > [Permissions]로 들어가면 사용자(Users), 그룹(Groups), 역할(Roles)을 정의할 수 있습니다. 처음엔 좀 복잡하게 느껴질 수도 있지만, 익숙해지면 훨씬 체계적으로 관리할 수 있더라고요.

    저도 처음엔 그냥 root 계정 하나로 모든 걸 했다가, 실수로 중요한 설정을 건드릴 뻔한 적이 여러 번 있습니다. 그때마다 ‘아, 이러면 안 되겠구나’ 싶어서 권한을 쪼개기 시작했죠. 특히 여러 사람이 함께 Proxmox VE를 관리하는 환경이라면 이 기능은 정말 필수예요.

    9. 불필요한 서비스 비활성화 🛑

    운영체제에는 기본적으로 다양한 서비스(Daemon)들이 설치되어 있어요. 이 중에는 Proxmox VE 운영에 반드시 필요하지 않거나, 사용하지 않는 서비스들도 있을 수 있습니다. 불필요한 서비스를 비활성화하면 공격 표면(Attack Surface)을 줄이고 시스템 자원을 절약할 수 있거든요.

    예를 들어, Proxmox VE를 설치하면 apt-cacher-ng 서비스가 자동으로 설치되는 경우가 있는데, 만약 여러 대의 Proxmox 서버를 운영하는 환경이 아니라면 굳이 필요 없을 수 있습니다. 이런 서비스들을 확인하고 비활성화하는 것이 좋아요.

    # 현재 실행 중인 서비스 목록 확인
systemctl list-units --type=service --state=running

# 특정 서비스 비활성화 (예시: apt-cacher-ng)
systemctl stop apt-cacher-ng
systemctl disable apt-cacher-ng

    ⚠️ 경고: 어떤 서비스가 시스템에 필요한지 확실히 모른다면 섣불리 비활성화하지 마세요. 잘못하면 시스템이 부팅되지 않거나 정상적으로 작동하지 않을 수 있거든요. Proxmox 관련 핵심 서비스는 절대 건드리면 안 됩니다!

    10. 정기적인 보안 감사 및 모니터링 🔍

    마지막으로, 모든 보안 설정이 잘 작동하는지 정기적으로 확인하고 모니터링하는 게 정말 중요합니다. 시스템 로그를 확인하고, 이상 징후는 없는지 살펴보는 거죠. fail2ban 같은 도구를 사용하면 SSH 무작위 대입 공격 시도를 자동으로 차단하는 데 큰 도움이 됩니다.

    저는 journalctl 명령어를 자주 사용해서 로그를 살펴봐요. 특히 SSH 접속 시도 로그나 방화벽 차단 로그 같은 것들이죠. 처음엔 그냥 지나쳤는데, 자세히 보니 수상한 IP에서 계속 접속 시도가 있더라고요. 그때부터 fail2ban을 설치해서 사용하기 시작했습니다. 이거 진짜 편하더라고요!

    # 최근 로그 확인
journalctl -f

# fail2ban 설치 및 설정
apt install fail2ban
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
nano /etc/fail2ban/jail.local
# [sshd] 섹션에서 enabled = true 로 변경하거나 원하는 설정 적용
systemctl enable fail2ban
systemctl start fail2ban

    ⚠️ 삽질 경험과 해결 과정

    솔직히 이 모든 과정을 한 번에 완벽하게 해내기란 쉽지 않습니다. 저도 여러 번 삽질 좀 했거든요. 특히 SSH 설정을 강화하다가 제 발등을 찍었던 적이 많아요. PermitRootLogin no와 PasswordAuthentication no를 설정하고 sshd를 재시작했는데, 그만 SSH 키 인증이 제대로 안 되어 있어서 서버에 접속하지 못했던 거죠. 다행히 Proxmox VE는 콘솔 접속(Keyboard & Monitor)이 가능해서 직접 가서 복구했습니다만… 원격으로만 관리하는 서버였다면 정말 큰일 날 뻔했어요.

    이런 경험을 통해 배운 건, ‘변경 전에 항상 백업하고, 변경 후에는 반드시 검증하라’는 거예요. 특히 원격 접속 설정은 더더욱 신중해야 합니다. 콘솔 접속이 불가능한 환경이라면 ‘Rollback Plan(롤백 계획)’을 미리 세워두는 것이 좋아요.

    🎉 안전한 Proxmox 환경, 직접 확인해보니

    위에 언급된 체크리스트를 하나씩 적용하고 나면, 여러분의 Proxmox VE 환경은 훨씬 견고해질 겁니다. SSH 포트가 바뀌고, 키 인증으로만 접속되며, 웹 UI는 2단계 인증을 거쳐야만 들어갈 수 있게 되죠. 방화벽 덕분에 불필요한 트래픽은 차단되고, 시스템은 항상 최신 상태를 유지하게 됩니다. 이런 변화들을 직접 체감하면 정말 뿌듯하더라고요!

    각 설정이 제대로 적용되었는지 확인하는 것도 중요합니다. 예를 들어, SSH 포트 변경은 netstat -tuln | grep <새로운 포트> 명령어로 확인할 수 있고, 방화벽 규칙은 Proxmox VE 웹 UI의 [Datacenter] > [Firewall] 섹션에서 확인할 수 있어요.

    보안 강화 설정이 완료된 Proxmox VE 환경 대시보드

    Proxmox VE의 보안 설정이 강화된 후의 상태를 보여주는 대시보드 또는 주요 보안 설정 활성화 여부를 시각적으로 나타낸 이미지입니다.

    💡 마무리하며: 13년차 서버실의 다음 이야기

    오늘은 Proxmox VE 보안 강화 체크리스트 10가지를 통해 안전한 가상화 환경을 구축하는 방법을 알아봤습니다. 기본적인 비밀번호부터 시작해서 SSH 보안, 2FA Proxmox, Proxmox 방화벽 설정, 네트워크 세그멘테이션까지, 이 모든 과정이 처음엔 어렵게 느껴질 수 있지만, 하나씩 따라 하다 보면 어느새 튼튼한 서버실을 만들고 있는 자신을 발견할 수 있을 거예요. 이 경험들이 여러분의 인프라 엔지니어링 여정에 큰 도움이 되기를 바랍니다. 다음번에는 Proxmox VE의 백업 전략에 대해 좀 더 깊이 있는 이야기를 나눠볼까 합니다. 그때까지 여러분의 서버실이 안전하길 바랍니다! 궁금한 점이 있다면 언제든지 댓글로 남겨주세요. 저도 함께 고민해드릴게요! 😊