Tutoriel Linux

Proxmox의 VM 또는 CT용 방화벽 규칙

DébutantPublié par Julien Macé le 2 min de lecture

귀하의 웹 VM은 여전히 응답하지만, 너무 넓은 규칙이 불필요한 서비스를 열거나 SSH를 차단할 수 있는 시점에 도달하게 됩니다.

Proxmox 방화벽은 이미 활성화되어 있으며, 질문은 구체적으로: VM, 노드 또는 게스트 OS 수준에서 작성해야 하는가입니다?

VM 또는 컨테이너의 경우, 게스트와 실제 흐름에서 시작해야 합니다.

net0의 옵션을 살펴보고, IN 규칙을 구성하며, OUT의 운명을 결정한 후 재사용 가능한 규칙만 패키징합니다. Proxmox 검제와 애플리케이션 테스트는 호스트 방화벽에서 분리되어 있습니다.

Proxmox VM에 적용된 방화벽 규칙으로 인바운드 및 아웃바운드 흐름
VM/CT Proxmox 규칙은 게스트의 실제 흐름에서 시작해야 하며, 재사용 가능한 경우에만 패키징해야 합니다.

첫 번째 규칙을 작성하기 전에 대상을 정의하십시오

VMID, 가상 인터페이스, 게스트의 주소 및 실제로 노출된 서비스를 식별하십시오. HTTP 및 HTTPS를 제공하는 Debian VM은 방화벽에서 사용할 수 있는 관리 컨테이너와 동일하지 않습니다.

  • 실제 VMID와 net0 인터페이스를 기록합니다;
  • 인바운드 포트 및 허용된 소스를 나열합니다;
  • 호스트에 대한 콘솔 또는 관리자 액세스를 유지합니다;
  • 데이터센터/노드 방화벽이 이미 처리된 커버리지를 확인합니다.

영역은 서로 교체할 수 없습니다. 데이터센터는 재사용 가능한 블록에 특히 유용하고, 노드는 호스트와 관련되며, VM/CT는 게스트의 흐름을 필터링합니다.

Debian의 방화벽은 별도의 레이어로 남아 있습니다. Proxmox VE 공식 문서는 이 분리와 IN, OUT 및 FORWARD 방향에 대해 설명합니다.

노드 방화벽이 아직 활성화되지 않았거나 Web UI 또는 SSH를 잃을까 우려된다면, VM 규칙 전에 멈추고 접근을 잃지 않고 Proxmox 방화벽을 안전하게 활성화하는 방법를 참조하십시오.

호스트 잠금은 이 범위를 벗어납니다.

VM 및 인터페이스 옵션 읽기

첫 번째 규칙을 작성하기 전에 Proxmox 노드에서 구성을 검토하십시오. <VMID>를 귀하의 VM 숫자 ID로 대체하세요:

qm config <VMID> --current

다음으로, VM 구성에서 enable, policy_in, policy_out, log_level_in, log_level_out 및 ipfilter를 확인하십시오.

각 인터페이스는 자체 방화벽 지시기를 가지고 있습니다. net0 플래그가 비활성화된 경우 VM의 일반 옵션만으로는 충분하지 않습니다.

[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT
log_level_in: nolog
log_level_out: nolog
ipfilter: 1

이 블록은 제한적인 인바운드와 여전히 허용된 아웃바운드를 보여줍니다. 그대로 복사할 파일이 아닙니다: 귀하의 VM에 맞게 값을 조정한 다음 생성된 구성을 확인합니다.

ipfilter는 주로 인터페이스에서 주소 스푸핑을 제한하는 데 사용되며, HTTP 또는 SSH의 허용 목록을 생성하는 데 사용되지 않습니다.

실제로 필요한 인바운드 흐름 허용하기

입장에서 시작하십시오. 웹 VM의 경우, SSH는 일반적으로 중개 서버나 관리 네트워크에서 발생합니다.

포트 80 및 443은 리버스 프록시 또는 아키텍처에 설정된 공개 소스에서 발생합니다. 따라서 허용 규칙은 프로토콜, 포트, 소스 및 인터페이스를 알고 있어야 합니다.

[RULES]
IN ACCEPT -p tcp -dport 22 -source +admins -i net0
IN ACCEPT -p tcp -dport 80 -source +reverse_proxy -i net0
IN ACCEPT -p tcp -dport 443 -source +reverse_proxy -i net0

이 예제에서 +admins와 +reverse_proxy는 별도로 정의된 IPSet입니다.

문서용 주소 192.0.2.0/24는 예제나 문서에서 네트워크를 설명하기에 적합하지만, 귀하의 실제 네트워크를 나타내지 않습니다. 튜토리얼에서 찾은 주소를 복사하지 않고 확인된 소스로 교체하십시오.

명세된 허가는 DROP 또는 REJECT 정책 전에 배치하십시오. 너무 일찍 추가된 전체 거부는 유용한 규칙을 가리는 역할을 합니다.

간단한 오해가 SSH 차단으로 이어질 수 있습니다. 구성을 경량화하기 전에 검토하고 호스트 콘솔을 사용 가능하게 유지하십시오.

엄격하게 만들기 전에 OUT 정책 결정하기

허용된 출력은 DNS, NTP, 업데이트, APT 리포지토리, 모니터링 또는 외부 API가 다른 레이어에서 필터링되는 한 작동합니다.

제한적인 출력은 정확한 목록을 요구합니다: 첫 번째 차단된 DNS 패킷이 VM 또는 브리지가 다운된 것으로 누군가를 믿게 할 수 있습니다.

VM의 흐름방향예DROP 하에 있을 위험
관리 SSHIN+admins에서 22/tcp로소스가 목록에 없으면 접근이 거부됩니다.
HTTP/HTTPSIN+reverse_proxy에서 80/443으로웹 서비스에 접근할 수 없습니다.
DNS 해상도OUTUDP/TCP 53에서 해결기로APT와 이름 호출이 실패합니다.
시스템 시간OUTUDP 123에서 NTP 소스로다른 메커니즘이 그렇지 않으면 시간을 유지할 수 없습니다.
리포지토리 및 APIOUTTCP 80/443에서 예정된 목적지로업데이트와 모니터링이 중단될 수 있습니다.

인벤토리 중에 policy_out: ACCEPT로 두는 것이 좋으며, 문서화된 출력이 하나씩 추가되는 것으로 DROP으로 변경합니다.

이 선택은 빌드하는 동안 서비스의 가용성을 보호합니다. 환경이 실제로 허용 목록을 요구하는 경우, 이는 아웃바운드 정책을 대체하지 않습니다.

[OPTIONS]
policy_out: DROP

[RULES]
OUT ACCEPT -p udp -dport 53 -dest dns_interne
OUT ACCEPT -p tcp -dport 53 -dest dns_interne
OUT ACCEPT -p udp -dport 123 -dest ntp_interne
OUT ACCEPT -p tcp -dport 80 -dest depots
OUT ACCEPT -p tcp -dport 443 -dest depots

이름 dns_interne, ntp_interne 및 depots는 귀하의 실제 주소 또는 그룹을 가리켜야 합니다. 여러 포트 및 별칭 문법은 적용 전에 설치된 Proxmox 버전을 기준으로 검토해야 합니다.

중복되는 규칙을 Security Group으로 패키징하기

여러 VM 또는 컨테이너가 동일한 기능을 공유할 때 Security Group이 유용해집니다.

Proxmox는 클러스터 수준에서 정의하고 각 게스트의 구성에서 그를 호출합니다 [RULES] 섹션에서. 그룹은 규칙에 포함되지 않은 이상 어떤 VM에도 적용되지 않습니다.

# /etc/pve/firewall/cluster.fw
[group webserver]
IN ACCEPT -p tcp -dport 80
IN ACCEPT -p tcp -dport 443

# /etc/pve/firewall/<VMID>.fw
[RULES]
GROUP webserver

그룹에는 실제로 일반적인 규칙만 포함하십시오. VM에 대한 개별 예외는 /etc/pve/firewall/<VMID>.fw에 남아있어야 합니다. 이 분리는 모든 게스트를 변경하지 않고 관리 및 오류 하나를 수정할 수 있도록 합니다.

IPSet 및 별칭으로 소스 명명하기

IPSet은 주소나 네트워크를 집합합니다; 별칭은 주소나 네트워크에 읽기 쉬운 이름을 부여합니다.

규칙은 소스 또는 대상으로 이를 사용할 수 있습니다. 이렇게 하면 +admins 또는 dns_interne를 재검토할 수 있으며, 각 반복에서 IP를 해석할 필요가 없습니다.

# /etc/pve/firewall/cluster.fw
[ALIASES]
dns_interne 192.0.2.53

[IPSET admins]
192.0.2.10

[IPSET reverse_proxy]
192.0.2.20
192.0.2.21

주소 192.0.2.10, 192.0.2.20 및 192.0.2.21는 문서의 플레이스홀더입니다. IPSet은 + 접두사를 사용하여 참조합니다. 예를 들어 -source +admins로 사용됩니다.

이 접두사가 없으면 Proxmox는 이름을 주소나 별칭으로 인식하게 되어 규칙이 의도와 일치하지 않습니다.

ipfilter-net0를 애플리케이션 허용 목록과 혼동하지 마십시오.

이 인터페이스에 연결된 IPSet은 원본 주소 스푸핑을 방지하는 데 도움이 됩니다. 여기서 누가 귀하의 애플리케이션 포트 443을 열 수 있는지를 결정하지 않습니다.

정책을 강화하기 전에 규칙의 순서 읽기

그룹 규칙 또는 로컬 규칙은 예상 위치에서 읽히는 경우에만 효과가 있습니다. 일반 거부보다 정확한 일치를 더 먼저 배치하고 각 변경 후 구성을 다시 검토하십시오.

읽힌 순서예너무 아래에 배치할 위험
1. 특정 소스 및 포트+admins에서 22/tcp로 SSH중개 서버가 정책에 의해 차단됩니다.
2. 재사용 가능한 그룹GROUP webserver이 VM에서 웹 포트가 닫힙니다.
3. 문서화된 출력DNS, NTP, 리포지토리서비스가 시작되지만 종속 구성 요소를 잃을 수 있습니다.
4. 기본 정책DROP 또는 REJECT잊혀진 모든 흐름이 여기로 떨어집니다.

공식 문서에서는 IN/OUT 구문, --source, --dest, --dport 및 --iface 옵션과 Security Group 삽입을 설명합니다.

해당 버전에 맞는 형식을 사용한 다음 그룹이 활성화된지 확인하기 위해 컴파일된 구성을 확인하십시오.

테스트 중에 대상 로깅 활성화하기

Proxmox 로깅은 필터링된 트래픽에 대해 기본적으로 비활성화되어 있습니다. log_level_in 및 log_level_out 옵션은 VM/CT의 표준 로그를 활성화합니다. 이는 Firewall → Log에서 확인할 수 있습니다.

로그에 추가된 수준은 패킷을 식별하는 데 사용됩니다: 자동으로 기록된 패킷 수를 증가시키지 않습니다.

[OPTIONS]
log_level_in: info
log_level_out: nolog

[RULES]
IN ACCEPT -p tcp -dport 22 -source +admins -i net0 -log info

관심 있는 흐름의 테스트 중에만 레벨을 활성화하고, 볼륨이 떠지면 nolog로 되돌리십시오.

영구적인 전역 로깅은 진짜 거부 사항을 읽는 것을 어렵게 하고 운영 소음을 증가시킵니다.

주의: 빈 로깅은 서비스가 작동함을 증명하지 않습니다. 여전히 규칙, 애플리케이션의 응답 및 실제 소스의 네트워크 경로를 확인해야 합니다.

구성, 테스트 및 롤백 계획

노드에서 방화벽 상태를 읽는 것으로 시작하십시오:

pve-firewall status
pve-firewall compile

pve-firewall status는 규칙을 다시 읽고 컴파일합니다: 구문 경고는 네트워크 테스트 전에 수정해야 할 문제입니다.

pve-firewall compile는 생성된 구성을 확인하는 데 사용됩니다.

pve-firewall 공식 문서는 pve-firewall simulate도 설명하며, 소스, 목적지, 포트 및 프로토콜을 시뮬레이션하는 데 도움이 될 수 있지만, 커널 라우팅이나 애플리케이션 작동을 증명하지는 않습니다.

최종 검사는 허용된 소스에서 출발한 후, 위험 없이 사용할 수 있는 거부 소스로 진행해야 합니다:

  • 예상 관리 IP에서 SSH, ssh -v를 사용하여;
  • 리버스 프록시를 통한 HTTP 또는 HTTPS, curl -I https://<IP_VM>를 사용하여;
  • VM에서 DNS, NTP 및 APT를 사용하여 policy_out이 제한적일 경우;
  • 테스트 창에서 Proxmox 로그 읽기 후 nolog로 되돌리기.

이 명령을 이미 수행한 테스트로 제시하지 마십시오: 이는 검증 프로토콜을 형성합니다.

예상되는 결과는 응답하는 허용된 연결, 실패하는 금지된 흐름 및 검토된 규칙과 일치하는 흔적입니다.

규칙이 VM을 차단하면 해당 규칙을 제거하거나 이 VM/CT의 방화벽을 임시로 비활성화하십시오.

DNS, NTP 또는 업데이트가 손상되면 policy_out: ACCEPT로 되돌리십시오.

pve-firewall stop를 일반적인 롤백으로 사용하지 마십시오: 이 명령은 호스트에서 Proxmox 규칙을 제거하고 서버를 보호 없이 남길 수 있습니다.

경계 보이기 유지하기

IP 주소가 없는 VM, отсутствующий 브리지 또는 잘못된 VLAN은 방화벽 규칙으로 수정할 수 없습니다.

규칙이 올바른 것처럼 보이지만 게스트에 IP가 없는 경우 Proxmox VM의 네트워크 진단으로 넘어가십시오. 브리지에서 게스트까지: VM의 네트워크 복구.

호스트 측 문제에 대해서는 서버 접근을 잃지 않고 Proxmox 브리지 생성 가이드가 적절한 레이어를 다룹니다.

백엔드 nftables proxmox-firewall는 PVE 9.2.11 문서에서 기술 미리보기로 표시됩니다.

위의 예는 기본적으로 저장된 백엔드 pve-firewall에 집중되어 있습니다. 귀하의 환경이 IPv6를 사용하는 경우, 단일 IPv4 테스트만으로 결론 내리지 말고 NDP 및 IPv6 주소도 확인하십시오.