트래픽 로그에서 app-id가 어떻게 표시되나요? 보안 정책이 작동하지 않으면 psiphon3으로 태그되지 않는다고 안전하게 가정할 수 있습니다.
암호화된 트래픽은 방화벽으로 검사할 수 없습니다. 복호화가 활성화되지 않은 경우, 방화벽은 세그먼트 헤더(포트 등) 또는 TLS SNI 필드를 기반으로 트래픽을 추정하는 경우가 많으며… 이는 "SSL"과 같은 일반화된 태그로 이어집니다. 트래픽이 복호화되면, 방화벽은 스트림으로 트래픽을 검토하고, 페이로드 패턴이 일치하는 경우 동적으로 app-id를 조정합니다.
트래픽이 제대로 태그되지 않는다면, 암호화되었을 가능성이 높으며 복호화 방법이 없다는 의미입니다.
다른 사람들이 말했듯이… SSL 복호화를 활성화하면(처리되는 트래픽 양과 사용되는 암호 스위트에 따라) 최대 처리량의 30-40%를 손실할 수 있습니다. 이 방법을 선택한다면, 보안 정책과 유사하게 매칭 객체 또는 IP를 사용하는 소규모 그룹을 통해 미리 테스트하는 것이 좋습니다.
또한 인바운드(웹에서 내부 서브넷으로)인지 아니면 아웃바운드 트래픽인지 고려해야 합니다. 인바운드라면 현재 보안 정책을 더 좁게 조정할 수 있는지 검토하세요. 아웃바운드도 마찬가지로 실제 사용 필요에 따라 정책을 강화하는 논리적 장치 그룹을 생성할 수 있습니다. 많은 사람들이 이 reddit에서 기본 내부 및 내부 존 정책에 의존하는 경우를 봤으며, 이는(트래픽이 정책을 트리거하지 않는 한) 웹 트래픽이 허용되어 기록되지 않거나(존 할당에 따라 다름) 문제가 생길 수 있습니다.
이 질문에 답하기는 어려우며, 귀하의 환경을 더 잘 이해하는 것이 필요합니다. 정당한 연결이 Ike/IPsec/etc.를 통해 내부 사용자 트래픽과 같은 존에 있나요? 그렇지 않다면, 내부 사용자 존에 대한 암호 해독 정책 규칙을 만들고, 귀하가 나열한 Ike/IPsec/기타 트래픽을 차단하는 것이 좋습니다. 하지만 주의해야 할 점도 있습니다. 우선, 복호화는 많은 리소스를 소모할 수 있으니 신중히 적용하세요. 두 번째로, SSL로 표시되던 애플리케이션이 바뀌거나 차단되지 않기 시작할 수 있습니다.
불행히도, 복호화 없이는 Palo는 그 트래픽을 쉽게 파악하여 차단할 다른 방법이 없습니다. 필요에 따라 보안 정책에 따라 알려진 손상 없는 트래픽/IP를 허용하는 규칙을 사용할 수 있습니다. 아래는 Palo Alto의 참고 자료입니다: