- 공유 링크 만들기
- X
- 이메일
- 기타 앱
이 글의 목적은 Windows Defender 방화벽(고급 보안)에서 규칙이 중복되거나 충돌하여 특정 포트가 예기치 않게 차단되는 상황을 원인별로 진단하고, GUI와 PowerShell로 “실제로 차단을 일으키는 규칙”을 찾아 안전하게 해제·정리하는 실무 절차를 제공하는 것이다.
1. 증상과 핵심 원리 이해
1-1. 대표 증상
서비스는 정상 실행 중인데 외부에서 포트 연결이 실패하거나, 같은 포트에 대해 “허용 규칙을 만들었는데도” 계속 차단되는 현상이 발생하다.
예를 들어 3389(RDP), 1433(MSSQL), 445(SMB), 80/443(웹), 5432(PostgreSQL) 같은 포트에서 흔히 나타나다.
1-2. 가장 흔한 원인: “허용”과 “차단” 규칙의 충돌
Windows Defender 방화벽은 전통적인 순차 룰(위에서 아래로 평가) 방식이 아니라, 조건이 일치하는 룰들을 종합하여 적용하다.
이때 명시적 “차단(Block)” 규칙은 충돌하는 “허용(Allow)” 규칙보다 우선하여 적용되는 것이 일반 원칙이다.
또한 규칙이 구체적일수록(특정 IP, 특정 프로그램, 특정 인터페이스, 특정 서비스 등) 더 강하게 적용될 수 있어, 겉으로는 같은 “포트 허용”처럼 보여도 실제 적용 결과가 달라질 수 있다.
주의 : “허용 규칙을 추가했는데도 열리지 않는다”는 상황의 상당수는, 같은 포트·같은 방향(인바운드)·같은 프로파일에서 “차단 규칙이 이미 존재”하거나, GPO/MDM 정책 규칙이 로컬 규칙을 덮어쓰는 구조에서 발생하다. 무작정 새 허용 규칙을 추가하면 중복만 늘어나고 문제는 지속되다.
2. 먼저 확인해야 하는 필수 체크리스트
2-1. 네트워크 프로파일 확인
동일한 규칙이라도 Domain/Private/Public 프로파일 중 어디에 적용되는지에 따라 결과가 달라지다.
현재 연결 프로파일을 확인하고, 규칙이 같은 프로파일에 적용되는지부터 맞춰야 하다.
PowerShell(관리자)에서 실행하다.
Get-NetConnectionProfile2-2. 인바운드/아웃바운드 방향 확인
서버 포트를 열려는 목적이면 대부분 “인바운드(Inbound)” 규칙이 핵심이다.
클라이언트에서 외부로 나가는 통신이 막히는 문제라면 “아웃바운드(Outbound)”에서 차단 규칙이 있는지 봐야 하다.
2-3. 기본 정책(Default) 확인
기본적으로 인바운드는 “허용 규칙이 없으면 차단” 성격이 강하다.
기본 정책 자체가 강화되어 있거나, 로컬 방화벽 정책이 조직 정책으로 강제되는 경우도 흔하다.
다만 기본 정책을 완화하는 방식은 보안 리스크가 크므로, 원칙적으로 “필요 포트만 정확히 허용”하는 방향이 안전하다.
3. GUI로 “실제 차단 규칙” 찾아 해제하는 절차
3-1. 고급 보안 콘솔 열기
실행 창에서 wf.msc를 실행하여 “Windows Defender 방화벽(고급 보안)” 콘솔을 열다.
Win + R wf.msc3-2. 모니터링에서 “유효 정책(Effective Rules)” 먼저 확인
좌측 하단의 “모니터링(Monitoring)”은 로컬 규칙 목록보다 실제 적용 결과를 파악하는 데 유리하다.
특히 도메인 환경에서는 GPO 규칙이 로컬 규칙과 함께 보이거나 우선 적용될 수 있으므로, 모니터링 영역에서 우선 확인하는 습관이 중요하다.
3-3. 인바운드 규칙에서 포트 기반으로 후보 좁히기
좌측 “인바운드 규칙(Inbound Rules)”에서 다음을 확인하다.
- 같은 포트가 여러 규칙에 중복 지정되어 있는지 확인하다.
- 작업(Action)이 “연결 차단”인 규칙이 존재하는지 확인하다.
- 프로파일(Profile)이 현재 네트워크 프로파일과 일치하는지 확인하다.
- 사용(Enabled)이 켜져 있는지 확인하다.
- 범위(Scope)에 원격 IP가 제한되어 있는지 확인하다.
- 프로그램(Program) 또는 서비스(Service)에 묶여 특정 실행 파일에만 허용되는 구조인지 확인하다.
3-4. 규칙 속성에서 충돌 포인트를 분해 점검
문제가 의심되는 규칙을 더블 클릭하여 아래 항목을 점검하다.
| 점검 항목 | 확인 위치 | 실무 판단 |
|---|---|---|
| 차단/허용 | 일반(General) > 작업(Action) | 차단 규칙이 있으면 허용 규칙이 있어도 막힐 가능성이 높다. |
| 프로파일 | 고급(Advanced) > 프로파일 | Public에만 허용이면 Private/Domain에서는 열리지 않다. |
| 포트/프로토콜 | 프로토콜 및 포트 | TCP/UDP 혼동, 로컬 포트/원격 포트 혼동을 자주 하다. |
| 범위(원격 IP) | 범위(Scope) | 원격 IP 제한이 있으면 해당 IP 외는 차단되다. |
| 프로그램/서비스 | 프로그램(Program), 서비스(Services) | 특정 exe에만 적용되면 다른 프로세스는 허용되지 않다. |
| 인터페이스/에지 트래버설 | 고급(Advanced), 에지 트래버설 | VPN/가상 NIC/터널 환경에서 의도치 않게 적용 범위가 달라지다. |
3-5. 발견된 “차단 규칙”을 안전하게 무력화하는 방법
차단 규칙을 바로 삭제하기 전에 아래 중 하나로 처리하는 것이 안전하다.
- 우선 “사용 안 함(Disable)”으로 변경하여 영향도를 확인하다.
- 규칙 이름을 남기고 비활성화하여 추후 감사나 원복을 가능하게 하다.
- 정책(GPO/MDM) 규칙이면 로컬에서 수정이 불가할 수 있으므로, 정책 소유자 측에서 수정해야 하다.
주의 : 규칙이 “그룹 정책”에서 내려온 것이라면 로컬에서 삭제·변경이 유지되지 않거나, 재부팅/정책 갱신 시 다시 생성되다. 이런 경우 로컬에서 증상만 임시 해제하지 말고, GPO 편집 또는 정책 예외 설계를 통해 근본 수정해야 하다.
4. PowerShell로 중복·충돌 규칙을 정확히 찾아내는 방법
4-1. 포트를 기준으로 관련 규칙 전부 뽑기
GUI 검색은 포트 조건을 한 번에 필터링하기가 번거롭다. 아래 PowerShell은 특정 로컬 포트와 연관된 규칙을 규칙명/동작/프로파일과 함께 빠르게 보여주다.
PowerShell(관리자)에서 실행하다. 아래 예시는 TCP 445 포트 기준이다. $Port = 445 $Proto = "TCP" Get-NetFirewallPortFilter | Where-Object { $_.Protocol -eq $Proto -and $_.LocalPort -eq $Port } | ForEach-Object { $pf = $_ Get-NetFirewallRule -AssociatedNetFirewallPortFilter $pf } | Select-Object DisplayName, Enabled, Direction, Action, Profile, PolicyStoreSource, PolicyStoreSourceType | Sort-Object Action, DisplayName출력에서 Action이 Block인 규칙이 하나라도 활성(Enabled=True)이고 조건이 충돌하면 포트는 막힐 수 있다.
또한 PolicyStoreSource/PolicyStoreSourceType에서 규칙 출처가 로컬인지, 그룹 정책인지, MDM인지 구분이 가능하다.
4-2. “중복 규칙” 패턴 탐지
동일 포트·동일 방향·동일 프로토콜을 여러 개의 규칙이 반복 생성하는 환경이 흔하다. 아래는 특정 포트에 대해 규칙 DisplayName을 묶어서 개수를 보는 방식이다.
PowerShell(관리자)에서 실행하다. $Port = 3389 $Proto = "TCP" $rules = Get-NetFirewallPortFilter | Where-Object { $_.Protocol -eq $Proto -and $_.LocalPort -eq $Port } | ForEach-Object { Get-NetFirewallRule -AssociatedNetFirewallPortFilter $_ } $rules | Group-Object DisplayName | Sort-Object Count -Descending | Select-Object Count, NameCount가 과도하게 큰 항목은 배포 스크립트가 중복 생성했을 가능성이 높다.
4-3. 의심 규칙을 비활성화하거나 제거하기
정확히 “차단을 유발하는 규칙”이 특정되었을 때만 조치하다.
PowerShell(관리자)에서 실행하다. 아래는 표시 이름(DisplayName)으로 비활성화하는 예시이다. $RuleName = "Block TCP 445 (Legacy)" Disable-NetFirewallRule -DisplayName $RuleNamePowerShell(관리자)에서 실행하다. 아래는 표시 이름(DisplayName)으로 삭제하는 예시이다. 삭제는 복구가 번거로우므로 비활성화를 먼저 권장하다. $RuleName = "Block TCP 445 (Legacy)" Remove-NetFirewallRule -DisplayName $RuleName주의 : DisplayName이 동일한 규칙이 여러 개면 한 번에 같이 비활성화되거나 삭제될 수 있다. 먼저 Get-NetFirewallRule로 Name(고유 식별자)까지 확인한 뒤, 필요한 대상만 처리하는 절차가 안전하다.
5. “허용 규칙이 있는데도 차단되는” 자주 발생하는 시나리오
5-1. 차단 규칙이 더 구체적 조건으로 걸려 있는 경우
허용 규칙은 “모든 IP, 모든 프로그램, 모든 인터페이스”로 넓게 만들어졌는데, 차단 규칙이 “특정 원격 IP 대역” 또는 “특정 프로그램” 또는 “특정 프로파일(Public)”로 더 정확히 매칭되는 경우가 있다.
이때 특정 접속 경로에서만 막히는 현상이 나타나다.
5-2. 규칙이 적용되는 프로파일이 서로 다른 경우
허용 규칙이 Private에만 체크되어 있고, 현재 연결이 Public이면 허용 규칙은 적용되지 않다.
반대로 차단 규칙이 Public에만 있어도, 현재 프로파일이 Public이면 차단이 발생하다.
5-3. 프로그램 기반 규칙의 함정
같은 포트라도 실제로 리스닝하는 프로세스가 다르면 프로그램 조건이 맞지 않아 허용되지 않다.
예를 들어 테스트 도구로 임시 리스너를 띄웠는데, 허용 규칙은 서버 데몬 exe에만 묶여 있으면 포트는 계속 막히다.
5-4. GPO/MDM 정책 규칙과 로컬 규칙의 충돌
조직 보안정책이 강한 환경에서는 로컬에서 만든 허용 규칙이 있어도 정책 규칙의 차단이 우선되는 구조가 발생하다.
이 경우 현장에서는 “규칙이 존재하는데 왜 안 열리나”로 보이지만, 사실상 정책 소유자 쪽에서 예외 승인이 필요하다.
6. 재발 방지를 위한 표준 정리 방식
6-1. 규칙 네이밍과 그룹화 기준을 정하다
규칙 이름에 시스템/서비스/포트/방향/프로파일/승인일자 정보를 포함하면 중복을 크게 줄일 수 있다.
또한 DisplayGroup을 통일하면 향후 일괄 점검과 회수가 쉬워지다.
6-2. “허용 규칙을 추가”하기 전에 “차단 규칙 검색”을 표준 절차로 만들다
운영 표준은 다음 순서가 안전하다.
- 대상 포트 기준으로 Block 규칙 존재 여부를 먼저 찾다.
- 프로파일/범위/프로그램 조건 충돌을 확인하다.
- 필요 시 차단 규칙을 비활성화하여 증상 변화를 확인하다.
- 근본 원인(정책/배포 스크립트)을 수정하여 중복 생성이 재발하지 않게 하다.
6-3. 변경 기록을 남기다
방화벽 규칙은 장애 원인이 되기도 하지만 보안 통제 수단이기도 하다.
따라서 삭제보다는 비활성화를 우선하고, 변경 사유·승인·영향 범위를 기록으로 남기는 방식이 감사를 통과하기 유리하다.
7. 현장에서 바로 쓰는 “포트 차단 규칙 찾기” 최소 명령 세트
아래는 문제 포트가 생겼을 때, 원인 규칙을 빠르게 특정하기 위한 최소 명령이다.
1) 현재 네트워크 프로파일을 확인하다. Get-NetConnectionProfile 2) 특정 포트(TCP 1433)에 연결된 모든 규칙을 나열하다. $Port = 1433 Get-NetFirewallPortFilter | Where-Object { $_.Protocol -eq "TCP" -and $_.LocalPort -eq $Port } | ForEach-Object { Get-NetFirewallRule -AssociatedNetFirewallPortFilter $_ } | Select-Object DisplayName, Enabled, Direction, Action, Profile, PolicyStoreSource | Sort-Object Action, DisplayName 3) 차단(Action=Block) 중 활성(Enabled=True)만 필터링하다. $Port = 1433 Get-NetFirewallPortFilter | Where-Object { $_.Protocol -eq "TCP" -and $_.LocalPort -eq $Port } | ForEach-Object { Get-NetFirewallRule -AssociatedNetFirewallPortFilter $_ } | Where-Object { $_.Enabled -eq "True" -and $_.Action -eq "Block" } | Select-Object DisplayName, Profile, PolicyStoreSource주의 : 위 명령으로 “차단 규칙이 존재한다”는 사실이 확인되면, 허용 규칙을 더 만드는 방식은 대부분 문제를 악화시키다. 차단 규칙의 출처(로컬/정책)와 조건(프로파일/범위/프로그램)을 먼저 정리해야 하다.
FAQ
규칙 목록에서 허용 규칙이 위에 있는데도 왜 차단되나?
Windows Defender 방화벽은 단순히 목록의 위/아래 순서로 적용되지 않다. 조건이 충돌하는 경우 명시적 차단이 우선되는 구조가 흔하며, 더 구체적인 조건의 규칙이 실질적으로 적용될 수 있다.
규칙을 삭제했는데 다시 생기다. 원인이 무엇인가?
그룹 정책(GPO) 또는 MDM(Intune 등)에서 방화벽 규칙이 내려오는 환경이면 로컬에서 삭제해도 정책 갱신 시 재생성되다. PolicyStoreSourceType을 확인하여 정책 소유자 측에서 예외 또는 규칙 수정이 필요하다.
특정 IP에서만 접속이 안 되다. 포트는 같은데 왜 그런가?
범위(Scope)에 원격 IP 제한이 걸려 있거나, 차단 규칙이 특정 원격 IP 대역을 대상으로 더 구체적으로 설정되어 있을 수 있다. 규칙 속성의 범위 항목과, PowerShell로 차단 규칙을 필터링하여 확인하는 것이 정확하다.
같은 포트인데 TCP는 되고 UDP는 안 되다. 무엇을 봐야 하나?
프로토콜이 다르면 별개의 규칙으로 취급되다. 허용 규칙이 TCP만 열어두고 UDP는 차단된 경우가 흔하다. “프로토콜 및 포트”에서 TCP/UDP를 정확히 분리해 점검해야 하다.
가장 안전한 해결 방식은 무엇인가?
차단 규칙을 무조건 삭제하지 말고, 먼저 비활성화로 영향도를 확인한 뒤, 중복 생성의 근본 원인(배포 스크립트, GPO, 보안 기준 템플릿)을 수정하여 재발을 막는 방식이 안전하다.