EXE 하나로 시작하는 Windows 방화벽 규칙 관리: 조회부터 안전한 배포까지

방화벽 규칙을 실행 파일 중심으로 관리하기

Windows 방화벽 규칙은 인바운드와 아웃바운드가 나뉘고, 같은 프로그램에 여러 규칙이 연결될 수 있습니다. 이름만 보고 대상 규칙을 찾으면 비슷한 이름의 다른 규칙과 혼동하기 쉽고, 한쪽 방향의 규칙만 등록된 상태도 놓치기 쉽습니다.

현재 구현은 이 문제를 실행 파일 경로를 기준으로 규칙을 조회하고 필요한 상태로 보정하는 방식으로 해결합니다. 사용자가 EXE 파일을 선택하면 연결된 규칙을 찾아 인바운드와 아웃바운드 상태를 각각 보여주고, 기존 규칙은 수정하며 누락된 방향은 새로 생성합니다.

핵심은 규칙 이름이 아니라 실제 프로그램 경로를 기준으로 관리 범위를 결정하는 것입니다.

기존에 불편했던 점

관리 콘솔에서 특정 프로그램과 연결된 규칙을 직접 찾아야 했습니다.
인바운드와 아웃바운드 중 어느 방향이 빠졌는지 한눈에 확인하기 어려웠습니다.
TCP, UDP, 단일 포트, 포트 범위에 따라 입력 조건을 사용자가 직접 판단해야 했습니다.
기존 규칙 수정과 누락 규칙 생성을 각각 수행해야 했습니다.
배포 과정에서는 Windows x64용 런타임 자산이 준비되지 않은 상태로 단일 파일 게시가 진행될 가능성이 있었습니다.

화면과 방화벽 처리 로직의 역할 분리

이 프로젝트는 별도 서버나 웹 백엔드를 사용하는 구조가 아니라 하나의 .NET 8 WPF 데스크톱 앱입니다. 내부에서는 역할을 세 부분으로 구분합니다.

화면 계층: EXE 선택, 규칙 설정 입력, 상태 카드와 규칙 목록 표시, 사용자 확인 메시지를 담당합니다.
모델 계층: 프로토콜과 포트 방식, 조회 결과, 적용 옵션, 생성·수정 개수처럼 화면과 서비스가 주고받는 데이터를 표현합니다.
서비스 계층: Windows 방화벽 COM 인터페이스를 이용해 규칙을 조회·수정·생성·삭제합니다.

화면은 사용자의 선택을 구조화된 옵션으로 만들고, 서비스는 그 옵션을 다시 검증한 뒤 운영체제 방화벽에 반영합니다. 완료 후에는 규칙을 다시 조회해 화면에 최종 상태를 표시합니다.

핵심 동작 흐름

실행 파일 선택: 실제로 존재하는 EXE인지 확인하고 전체 경로로 정규화합니다.
연결 규칙 검색: 기존 방화벽 규칙에 저장된 환경 변수를 확장하고 경로를 정규화한 뒤, 선택한 경로와 정확히 일치하는 규칙만 수집합니다.
상태 요약: 인바운드와 아웃바운드 규칙 수를 나눠 표시하고, 양쪽 모두 없음·한쪽만 있음·양쪽 모두 있음 상태에 맞춰 다음 작업을 안내합니다.
입력 검증: 전체 프로토콜, TCP, UDP 중 하나를 선택하고 전체 포트, 단일 포트, 포트 범위를 지정합니다. 단일 포트나 범위에는 TCP 또는 UDP가 필요합니다.
규칙 보정: 해당 방향에 기존 규칙이 있으면 현재 입력값으로 수정하고, 없다면 새 허용 규칙을 생성합니다.
결과 재조회: 적용 직후 방화벽 상태를 다시 읽어 실제 생성·수정 결과와 현재 규칙 목록을 갱신합니다.

포트는 1부터 65535까지만 허용하며, 범위의 시작 값이 끝 값보다 크면 적용을 중단합니다. 전체 프로토콜을 선택하면 포트도 전체 범위로 처리합니다.

사용 방법

Windows에서 관리자 권한으로 앱을 실행합니다.
EXE 선택 버튼으로 방화벽 규칙을 관리할 프로그램을 고릅니다.
전체 상태와 인바운드·아웃바운드 카드, 현재 규칙 목록을 확인합니다.
규칙 이름과 프로토콜을 선택합니다.
전체 포트, 단일 포트 또는 포트 범위를 지정합니다.
규칙 등록 / 수정을 눌러 양쪽 방향의 규칙을 보정합니다.
하단 상태 메시지에서 수정된 규칙 수와 새로 등록된 규칙 수를 확인합니다.

선택한 EXE와 연결된 규칙을 모두 제거하려면 규칙 삭제 기능을 사용할 수 있습니다. 삭제 전에는 경고와 확인 절차가 표시되며, 완료 후 목록을 즉시 다시 조회합니다.

안정성과 보안을 위해 고려한 부분

관리 범위 제한

규칙 이름의 부분 일치가 아니라 정규화한 실행 파일 경로의 정확한 일치를 사용합니다. 파일이 없거나 확장자가 EXE가 아니면 작업을 거부합니다.

중복 실행 방지

조회나 적용이 진행되는 동안 버튼과 입력 필드를 비활성화하고, 작업 잠금을 사용해 여러 방화벽 변경이 동시에 실행되지 않도록 합니다. 예외가 발생해도 잠금과 화면 상태는 해제되며 오류 내용이 상태 영역에 표시됩니다.

삭제 전 확인

삭제는 선택한 실행 파일과 연결된 규칙 전체에 영향을 주므로 사용자 확인 없이는 실행되지 않습니다. 또한 삭제할 규칙이 확인된 경우에만 삭제 버튼이 활성화됩니다.

COM 자원 정리

Windows 방화벽 정책과 규칙 객체는 사용 후 명시적으로 해제합니다. 반복 조회나 적용 과정에서 운영체제 자원이 불필요하게 남지 않도록 한 처리입니다.

권한과 적용 범위 고지

방화벽 정책을 변경하려면 관리자 권한이 필요하므로 실행 매니페스트에서 권한 상승을 요청합니다. 새 허용 규칙은 도메인·개인·공용 프로필과 모든 인터페이스에 적용됩니다.

주의할 점도 분명합니다. 적용 기능은 선택한 EXE에 연결된 기존 규칙도 현재 입력한 이름, 프로토콜, 포트 조건으로 수정합니다. 중요한 환경에서는 적용 전에 대상 경로와 조건을 다시 확인하고 기존 방화벽 정책을 백업하는 편이 안전합니다.

최근 Git 변경: 배포 실패 가능성 줄이기

최근 앱 관련 변경은 사용자 기능을 새로 바꾸기보다 공개 빌드와 배포 기반을 안정화하는 작업에 집중됐습니다.

기본 브랜치와 변경 요청에서 .NET 8 Release 빌드를 검증합니다.
버전 태그가 등록되면 Windows x64용 self-contained 단일 실행 파일을 생성합니다.
실행 파일과 ZIP 패키지, SHA-256 체크섬을 함께 배포합니다.
디버그 심볼은 배포 결과에서 제외합니다.

초기 배포 구성에는 솔루션을 일반 복원한 뒤, Windows x64 런타임을 지정한 게시 명령을 --no-restore로 실행하는 불일치가 있었습니다. 이 경우 게시 단계에 필요한 런타임별 자산이 준비되지 않을 수 있습니다.

이를 해결하기 위해 게시 대상 프로젝트를 직접 복원하고, 복원 단계에도 Windows x64 런타임을 명시했습니다.

dotnet restore <앱 프로젝트> --runtime win-x64
dotnet publish <앱 프로젝트> --runtime win-x64 --no-restore

복원과 게시가 같은 프로젝트 및 런타임 조건을 사용하게 되면서, WPF 네이티브 라이브러리를 포함한 단일 실행 파일 생성 흐름이 일관되게 맞춰졌습니다. Git 기록상 같은 순서의 로컬 게시도 확인됐으며, 이 수정은 앱의 방화벽 동작이나 사용자 조작 방식에는 영향을 주지 않습니다.

최종적으로 개선된 점

사용자는 복잡한 관리 콘솔을 오가며 규칙을 하나씩 찾는 대신, 실행 파일 하나를 선택해 현재 상태와 다음 작업을 확인할 수 있게 됐습니다. 기존 규칙 수정과 누락 방향 생성을 한 번에 처리하고, 적용 직후 실제 상태를 다시 보여주기 때문에 결과도 비교적 명확합니다.

개발 측면에서는 Release 빌드 검증부터 단일 실행 파일, 압축본, 체크섬 생성까지 배포 과정이 자동화됐습니다. 특히 런타임 복원 조건을 게시 조건과 일치시켜 배포 단계의 구성을 바로잡았습니다.

다만 조사 범위에서는 별도의 자동화 테스트 프로젝트가 확인되지 않았습니다. 현재 CI가 보장하는 범위는 Release 빌드와 패키징이며, 실제 방화벽 변경 동작은 관리자 권한을 갖춘 Windows 환경에서 확인해야 합니다. 조사 시점의 작업 트리에는 미커밋 변경사항이 없었습니다.