특정 웹 사이트에 대한 HTTPS 액세스를 차단하는 Netfilter의 FILTER 테이블에 대한 몇 가지 규칙이 있습니다.
-A FORWARD -s 10.255.255.0/26 -p tcp -m tcp --dport 443 -m string --string "facebook.com" --algo bm -j DROP
-A FORWARD -s 10.255.255.0/26 -p tcp -m tcp --dport 443 -m string --string "instagram.com" --algo bm -j DROP
-A FORWARD -s 10.255.255.0/26 -p tcp -m tcp --dport 443 -m string --string "snapchat.com" --algo bm -j DROP
-A FORWARD -s 10.255.255.0/26 -p tcp -m tcp --dport 443 -m string --string "tumblr.com" --algo bm -j DROP
-A FORWARD -s 10.255.255.0/26 -p tcp -m tcp --dport 443 -m string --string "twitter.com" --algo bm -j DROP
-A FORWARD -s 10.255.255.0/26 -p tcp -m tcp --dport 443 -m string --string "youtube.com" --algo bm -j DROP
youtube.comGoogle Chrome을 통해 요청할 때 작동하지 않는 마지막 규칙(YouTube)을 제외하고 모든 규칙은 잘 작동합니다. Mozilla Firefox 및 Microsoft Edge와 같은 다른 웹 브라우저를 사용해 보았는데 규칙이 이러한 웹 브라우저에서 완벽하게 작동했습니다.
저는 헤더, 패킷 및 웹 서버에서 오는 정확한 정보에 관한 HTTP/HTTPS 프로토콜 전문가는 아니지만 YouTube 서버가 Google Chrome 사용자의 요청(SYN-ACK)에 응답할 때 에이전트(패킷 첨부 정보)에는 "youtube.com"에 대한 문자열이 포함되어 있지 않으며, 이 경우 Google Chrome(YouTube + Google 제품)의 성능 향상을 위해 다른 수정이 있을 수 있습니다.
bm(Boyer-Moore) 에서 (Knuth-Pratt-Morris)로 알고리즘을 변경해 보았지만 kmp작동하지 않았습니다.
내 질문은 다음과 같습니다
- 당신은 가지고 있습니까?IP 테이블IP를 차단하지 않고 Chrome을 통해 "youtube"에 대한 요청을 차단하는 규칙은 무엇입니까?
답변1
이러한 의견을 보면 netfilter가 해당 작업에 잘못된 도구라는 것을 깨닫는 것 같으므로 여기서는 그 점을 반복하지 않겠습니다.
여기서 무슨 일이 일어나고 있는 걸까요?
Google 크롬은 TLS 서버 이름 표시(SNI) 확장을 사용하지 않으므로 전송하는 패킷 중 암호화되지 않은 대상 호스트의 이름이 포함되어 있지 않고 사용자가 지정한 규칙과 일치하는 패킷이 없으며 라우터는 귀하가 아닌 이상 암호화된 트래픽을 읽을 수 없습니다. 이를 투명 프록시로 설정하고 이를 통해 이루어진 모든 HTTPS 연결에 대해 중간자 공격을 수행합니다.
TLS SNI는 HTTPS 연결을 암호화하는 데 사용되는 일반 TLS 프로토콜의 확장이며 시스템이 연결을 시도하는 호스트를 지정하는 데 사용됩니다. 특히 TLS 핸드셰이크의 이 부분은 암호화되지 않은 상태로 전송됩니다. 연결을 암호화하는 데 사용되는 TLS 인증서의 선택은 클라이언트가 액세스하려는 호스트에 따라 달라지기 때문입니다. 표면적으로는 동일한 IP 주소에서 수백 또는 수천 개의 호스트 이름을 제공할 수 있는 웹 호스팅 사이트를 고려할 때까지 이 모든 것이 무의미하게 들립니다.
HTTP는 실제로 이 목적을 위해 요청 헤더도 지정하지만(적어도 버전 1.1 및 2.0에서는) TLS 핸드셰이크가 완료된 후에 이 헤더가 전송되므로 연결에 사용되는 TLS 인증서를 결정하는 데 사용할 수 없습니다. 이는 호스팅된 모든 사이트가 동일한 도메인에 있고 연결에서 해당 도메인에 대한 와일드카드 인증서를 사용하는 경우에만 사용할 수 있는 옵션입니다.
실용적인 관점에서 볼 때 TLS SNI는 일반적으로 필요하지 않습니다. 왜냐하면 사람들이 정기적으로 방문하는 대부분의 웹사이트(차단하려는 웹사이트 포함)는 개별적으로 호스팅되거나 HTTP 헤더 및 와일드카드 인증서를 사용하기 때문입니다. 실제로 일부 웹사이트는 그렇지 않습니다. 이를 전혀 지원하지 마십시오(클라이언트가 이를 사용하려고 하면 핸드셰이크가 실패할 수 있습니다). 또한 TLS SNI는 사용자가 어떤 서비스에 액세스하려고 하는지 확인하는 것이 쉽지 않기 때문에 사용자가 로컬에서 DNS 정보를 얻는 경우 정보를 유출할 수 있습니다.
따라서 Google Chrome(및 Chromium 및 대부분의 기타 파생 제품)은 먼저 SNI를 사용하지 않고 연결을 시도하며(대부분의 사람들에게 작동함) 그런 다음에만 SNI를 사용하여 실패하게 됩니다. 대부분의 다른 브라우저는 먼저 SNI에 연결한 다음 실패할 경우 SNI 없이 시도하는 보다 자유로운(덜 안전하고 검열하기 쉬운) 접근 방식을 취합니다(대부분의 사람들은 일반적으로 그렇게 하지 않습니다).
문제를 해결하는 가장 좋은 방법은 무엇입니까?
먼저, 하지 않는 것을 고려해보세요. 이러한 정책을 엄격하게 시행하려는 시도는 명시적으로 승인된 서비스만 허용하는 상당히 엄격한 수준에 도달하지 않는 한(명시적으로 허용되지 않는 서비스를 차단하는 것과는 반대로) 비생산적이며 기능적으로 불가능합니다. 왜냐하면 사람들은 여전히 VPN 연결이나 프록시를 사용하여 액세스할 수 있기 때문입니다. (모든 VPN 및 프록시 방법을 차단할 수는 없습니다).
실제로 이를 중지해야 한다고 명시적으로 주장하는 경우 UDP 포트 53에서 일치하도록 규칙을 변경하세요. 이렇게 하면 해당 도메인의 캡슐화되지 않은 DNS 트래픽이 라우터를 통과하는 것을 방지할 수 있습니다(참고:예DNS 트래픽은 암호화되고 난독화될 수 있으며 심층 패킷 검사를 수행하고 다른 많은 것을 차단하지 않고는 쉽게 아무것도 할 수 없습니다. 규칙이 대칭인지 확인하십시오(즉, 아웃바운드 트래픽뿐만 아니라 인바운드 트래픽도 차단함). 이렇게 하면 이러한 종류의 문제에 대한 일부 해결 방법이 제대로 작동하지 못하게 됩니다.