새 UFW 규칙, 오래된 연결: 확립된 상태가 이긴다

거부 규칙을 추가했는데 열린 다운로드가 계속되는 것은 UFW 버그가 아닙니다. 추가한 규칙은 이미 그 흐름을 허용한 규칙 뒤에 있고, 이전에 확립된 연결은 계속 그 규칙들과 일치합니다. 이를 고치려면 올바른 위치에 넣고 이전 규칙이 무엇을 약속하는지 이해해야 합니다. 그 변경의 좁은 버전은 다음과 같습니다.

규칙의 존재가 아니라 순서가 결정한다

UFW는 netfilter 규칙을 단계적으로 기록하는 프런트 엔드입니다. 사용자 규칙보다 먼저 실행되는 프레임워크 구역, 그다음 사용자 규칙 자체, 그 뒤에 실행되는 구역 순서입니다. 기본 사전 규칙은 확립되었거나 관련된 연결의 트래픽을 허용하고, 그 규칙들은 일반 allow나 deny로 추가한 무엇보다 먼저 평가됩니다. UFW 명령 참조서는 삽입 구문과 이 변경이 의존하는 번호가 매겨진 상태 보기를 문서화합니다.

그 순서가 의외성을 설명합니다. 새 규칙은 실제로 존재하고 올바른 테이블에 있지만, 패킷이 만나는 첫 결정은 아닙니다. 이미 확립된 것으로 추적되는 연결은 거기에 도달하지 않습니다.

이 작업에는 route 규칙을 사용하십시오. 패킷은 게이트웨이 자체의 서비스로 주소 지정되는 것이 아니라 게이트웨이를 통해 전달되기 때문입니다. 입력 규칙은 잘못된 트래픽을 걸러 아무것도 하지 않는 것처럼 보일 것입니다.

넓은 허용 위에 삽입한다

적용하기 전에 삽입 내용을 미리 보고 규칙이 목록의 다른 곳에 이미 없는지 확인하십시오. 동일한 정책을 복제하면 나중 철회가 모호해지고, 잘못된 사본을 지운 사람은 몇 주 동안 알아차리지 못합니다.

sudo ufw --dry-run route insert 1 deny in on tun0 proto tcp from 10.88.0.55/32 to 192.0.2.88/32

미리보기에서 예상한 위치에 정확히 규칙 하나가 보이면 dry-run 플래그 없이 같은 명령을 적용하십시오. 위치 1은 그것을 더 넓은 사용자 허용 위에 두며, 앞서 검토한 프레임워크 규칙 위가 아닙니다. 인터페이스 이름이 이 게이트웨이의 터널 장치와 일치하는지 확인하십시오. 더 이상 존재하지 않는 인터페이스에 묶인 규칙은 목록에 남아 올바르게 보이지만 아무것도 일치하지 않습니다. 적용하기 전에 장치 참조 이름을 바꾸고, 테스트가 실패한 뒤에 하지 마십시오.

그 규칙에는 대상 포트가 없으므로 HTTPS뿐 아니라 해당 주소의 모든 TCP 포트를 거부합니다. 의도가 단일 서비스라면 포트를 지정하십시오. 정책보다 넓은 규칙은 첫 독자를 기다리는 미래의 사고입니다.

출처를 단일 주소로 제한하는 것은 그 주소가 의도한 신원에 묶여 있을 때만 하십시오. 동적 할당을 쓰는 VPN 풀은 내일 같은 주소를 다른 클라이언트에 줄 수 있고, 거부는 사람이 아니라 주소를 따라갑니다.

확립된 흐름은 새 규칙을 견딘다

기존 세션이 계속되는 이유는 연결 추적입니다. 흐름이 확립된 것으로 기록되면 사전 규칙이 당신의 거부를 보기 전에 그 패킷을 허용하고, 전송은 아무것도 바뀌지 않은 것처럼 끝납니다. 따라서 열린 연결을 재사용하는 브라우저로 시험하는 것은 새 정책에 대해 아무것도 알려주지 않습니다. 거부는 배포 몇 분 뒤에는 쓸모없어 보이고, 다음에 접속하는 사용자에게는 완전히 효과적일 수 있습니다.

요구 사항에 실시간 트래픽 차단이 포함된다면 이 사용자 규칙 변경으로는 제공할 수 없습니다. 추적된 상태를 철회하는 것은 자체 영향 범위를 가진 별도 작업이며, 규칙을 추가한 사람이 아니라 방화벽 소유자에게 속합니다. 한 세션을 사라지게 하려고 게이트웨이의 모든 연결을 비우는 것은 두 번째 사고를 만드는 종류의 수정입니다.

경계도 기억하십시오. 이 규칙은 ICMP, UDP, IPv6에 대해 아무 말도 하지 않으므로 성공한 ping은 거부가 실패했다는 증거가 아닙니다. IPv4 주소 하나도 웹사이트가 아닙니다. 이름은 여러 주소로 해석될 수 있고, 이름을 지정한 하나만 포함됩니다.

새 흐름으로 시험한다

번호가 매겨진 사용자 규칙과 유효한 원시 보기를 읽은 다음 선택한 클라이언트에서 새 연결을 여십시오:

sudo ufw status numbered
sudo ufw show raw
# from 10.88.0.55, a new TCP connection to 192.0.2.88 should fail

원시 보기가 중요한 이유는 status가 손으로 작성한 프레임워크 규칙을 생략하므로 순서가 커널이 적용하는 것과 다르게 보일 수 있기 때문입니다. 규칙이 잘못된 위치에 있다고 결론 내리기 전에 둘을 비교하십시오.

그다음 규칙이 넓지 않고 좁다는 것을 증명하는 두 통제를 확인하십시오. 같은 클라이언트에서 허용된 대상은 여전히 작동하고, 두 번째 클라이언트는 정책이 허용하면 거부된 대상에 여전히 도달합니다. 두 시험을 모두 깨뜨리는 거부는 정책 변경이지 표적 조치가 아닙니다.

시험이 끝나면 추가한 규칙만 정확히 다시 적어 제거하십시오. 정책이 영구적이라면 클라이언트 신원, 대상 소유자, 검토 날짜와 함께 방화벽 소유자에게 넘기십시오. 재할당된 터널 주소가 낡은 거부를 남기지 않도록 하기 위해서입니다.