Kangtian Anti-Blackwall을 어떻게 사용하나요? 다른 바이러스 백신 소프트웨어와 다릅니다!

"해커가 나를 이용할까요?" 이렇게 생각하는 것이 맞습니다. 해커는 계란 틈 사이로 기어다니는 파리와 같아서 시스템 취약점에서 나오는 희미한 빛을 보면 조치를 취할 준비가 되어 있습니다. ! 좋습니다. 그렇다면 네트워크를 어떻게 보호합니까? 컴퓨터 전문가는 네트워크 방화벽 설치를 제안할 수 있습니다. 그러면 첫 번째 질문이 떠오릅니다. 방화벽이란 무엇입니까?

방화벽이란 무엇입니까?

방화벽은 일종의 필터 플러그입니다(현재 이해하신 내용이 틀린 것은 아닙니다). 원하는 항목이 이 플러그를 통과하도록 하면 다른 모든 항목은 필터링됩니다. 네트워크 세계에서 방화벽에 의해 필터링되는 것은 통신 데이터를 전달하는 통신 패킷입니다.

세계의 모든 방화벽은 예 또는 아니요라는 두 단어 이상을 말합니다. 수락 또는 거부를 말하세요. 가장 간단한 방화벽은 이더넷 브리지입니다. 그러나 이 원시적인 방화벽이 많이 유용할 것이라고 생각하는 사람은 거의 없었습니다. 대부분의 방화벽은 다양한 기술과 표준을 사용합니다. 이러한 방화벽은 다양한 형태로 제공됩니다. 일부는 시스템에 이미 장착된 TCP/IP 프로토콜 스택을 대체하고 일부는 기존 프로토콜 스택에 자체 소프트웨어 모듈을 구축합니다. 특정 유형의 네트워크 연결(예: SMTP 또는 HTTP 프로토콜 등)에 대해서만 보호를 제공하는 애플리케이션 기반 방화벽도 있습니다. 실제로 보안 라우터로 분류되어야 하는 일부 하드웨어 기반 방화벽 제품도 있습니다. 위의 제품들은 모두 동일한 방식으로 작동하기 때문에 방화벽이라고 부를 수 있습니다. 즉, 방화벽에 들어오고 나가는 데이터 패킷을 분석하고 이를 통과시키거나 버릴지 결정합니다.

모든 방화벽에는 IP 주소 필터링 기능이 있습니다. 이 작업은 IP 패킷 헤더를 검사하고 IP 소스 및 대상 주소를 기반으로 통과/삭제 결정을 내립니다. 아래 그림을 보십시오. 두 네트워크 세그먼트 사이에 방화벽이 있습니다. 방화벽의 한쪽 끝에는 UNIX 컴퓨터가 있고, 네트워크 세그먼트의 다른 쪽에는 PC 클라이언트가 있습니다.

PC 클라이언트가 UNIX 컴퓨터에 대한 텔넷 요청을 시작하면 PC의 텔넷 클라이언트 프로그램은 TCP 패킷을 생성하고 전송을 위해 이를 로컬 프로토콜 스택에 전달합니다. 다음으로 프로토콜 스택은 TCP 패킷을 IP 패킷에 "채운 다음" PC의 TCP/IP 스택에 정의된 경로를 통해 UNIX 컴퓨터로 보냅니다. 이 예에서 IP 패킷은 UNIX 컴퓨터에 도달하기 전에 PC와 UNIX 컴퓨터 사이의 방화벽을 통과해야 합니다.

이제 우리는 UNIX 컴퓨터로 전송된 모든 데이터 패킷을 거부하도록 방화벽을 "명령"(전문 용어로 구성)합니다. 이 작업을 완료한 후에도 더 나은 "마음"을 가진 방화벽은 여전히 ​​클라이언트 프로그램입니다. 통보됩니다! 대상으로 전송된 IP 데이터는 전달될 수 없으므로 UNIX 컴퓨터와 동일한 네트워크 세그먼트에 있는 사용자만 UNIX 컴퓨터에 액세스할 수 있습니다.

또 다른 상황에서는 열악한 PC의 문제를 찾아내도록 방화벽에 명령할 수 있으며, 그러면 방화벽은 다른 사람의 데이터 패킷을 통과시키지 못하게 됩니다. 이것이 방화벽의 가장 기본적인 기능입니다. IP 주소를 기반으로 전달 결정을 내리는 것입니다. 그러나 큰 문제의 경우에는 이 작은 트릭이 작동하지 않습니다. 해커가 IP 주소 스푸핑 기술을 사용할 수 있기 때문에 합법적인 주소로 위장한 컴퓨터는 이 주소를 신뢰하는 방화벽을 통과할 수 있습니다. 그러나 주소를 기반으로 한 전달 의사결정 메커니즘은 여전히 ​​가장 기본적이고 필요합니다. 또 다른 주의할 점은 필터링 테이블을 생성하기 위해 DNS 호스트 이름을 사용해서는 안 된다는 것입니다. DNS 스푸핑은 IP 주소 스푸핑보다 훨씬 쉽습니다.

서버 TCP/UDP 포트 필터링

데이터 필터링을 위해 주소에만 의존하는 것은 실제 애플리케이션에서 실현 가능하지 않습니다. 또 다른 이유는 대상 호스트에서 여러 통신 서비스가 실행되는 경우가 많기 때문입니다. 예를 들어, 우리는 사용자가 텔넷을 사용하여 시스템에 연결하는 것을 원하지 않지만 이것이 동시에 SMTP/POP 메일 서버 사용을 금지해야 한다는 의미는 아닙니다. 따라서 주소 외에도 서버의 TCP/UDP 포트도 필터링해야 합니다.

예를 들어 기본 텔넷 서비스 연결 포트 번호는 23입니다. PC 클라이언트가 UNIX 컴퓨터에 대한 텔넷 연결을 설정하는 것을 허용하지 않는 경우(현재는 이를 서버로 취급함) UNIX 서버로 향하는 데이터 패킷을 확인하고 필터링하도록 방화벽에 명령하기만 하면 됩니다. 대상 포트 번호가 23인 패킷이 전부입니다. 이런 식으로 IP 주소와 대상 서버의 TCP/UDP 포트를 필터링 표준으로 결합하여 상당히 안정적인 방화벽을 구현할 수는 없을까요? 아니요, 그렇게 간단하지 않습니다.

클라이언트에는 TCP/UDP 포트도 있습니다.

TCP/IP는 종단 간 프로토콜이며 각 네트워크 노드에는 고유한 주소가 있습니다. 네트워크 노드의 애플리케이션 계층에서도 마찬가지입니다. 애플리케이션 계층의 각 애플리케이션과 서비스에는 포트 번호인 해당 "주소"가 있습니다. 주소와 포트를 사용할 수 있는 경우에만 클라이언트와 서버의 다양한 응용 프로그램 간의 효과적인 통신이 설정될 수 있습니다. 예를 들어 텔넷 서버는 포트 23에서 인바운드 연결을 수신합니다.

동시에 텔넷 클라이언트에도 포트 번호가 있습니다. 그렇지 않으면 클라이언트의 IP 스택이 특정 데이터 패킷이 속한 애플리케이션을 어떻게 알 수 있습니까?

역사적인 이유로 인해 거의 모든 TCP/IP 클라이언트 프로그램은 1023보다 큰 무작위로 할당된 포트 번호를 사용합니다. UNIX 컴퓨터의 루트 사용자만 1024 미만의 포트에 액세스할 수 있으며 이러한 포트는 서버의 서비스용으로 예약되어 있습니다. 따라서 포트 번호가 1023보다 큰 모든 패킷이 네트워크에 진입하도록 허용하지 않으면 다양한 네트워크 연결이 제대로 작동하지 않습니다.

이것은 방화벽에 문제가 됩니다. 모든 인바운드 포트가 차단되면 모든 클라이언트가 네트워크 리소스를 사용할 수 없게 됩니다. 외부 연결 요청에 대한 응답으로 서버에서 보내는 인바운드(방화벽 진입을 의미) 패킷은 방화벽의 인바운드 필터링을 통과할 수 없기 때문입니다. 반면에 1023보다 높은 포트를 모두 여는 것이 가능합니까? 설마. X 클라이언트, RPC 기반 NFS 서비스 및 수많은 비 UNIX IP 제품(NetWare/IP)과 같은 많은 서비스가 1023보다 큰 포트를 사용하기 때문입니다. 그렇다면 1023 포트 규격을 만족하는 모든 데이터 패킷이 네트워크에 진입하도록 허용한다면, 네트워크는 여전히 안전하다고 할 수 있을까요? 이러한 클라이언트 프로그램조차도 충분히 안전하다고 감히 말할 수 없습니다.

양방향 필터링

자, 생각을 바꿔보겠습니다. 우리는 방화벽에 다음 명령을 내립니다. 알려진 서비스의 데이터 패킷이 들어올 수 있고 다른 모든 데이터 패킷은 방화벽에서 차단됩니다. 예를 들어, 사용자가 웹 서버에 액세스하기를 원하는 경우 소스 포트 번호가 80인 패킷만 네트워크에 진입하도록 허용합니다.

그러나 새로운 문제가 발생합니다. 첫째, 액세스하려는 서버에 실행 중인 포트가 어떤 포트 번호인지 어떻게 알 수 있습니까? HTTP와 같은 서버는 임의로 구성할 수 있고, 사용하는 포트도 임의로 구성할 수 있습니다. 이렇게 방화벽을 설정하면 표준 포트 번호를 사용하지 않는 웹사이트에는 접속할 수 없습니다! 반대로, 포트 번호 80을 사용하여 네트워크로 들어오는 데이터 패킷이 반드시 웹 서버에서 나온다고 보장할 수는 없습니다. 일부 해커는 이를 이용하여 자신만의 침입 도구를 만들고 로컬 시스템의 포트 80에서 실행되도록 합니다.

ACK 비트를 확인하세요

우리는 소스 주소나 소스 포트를 신뢰하지 않습니다. 해커들과 춤을 추어야 하는 이 미친 세상에서 우리가 신뢰할 만한 가치가 있는 것은 또 무엇입니까? ? 다행스럽게도 아직 절망적인 수준까지는 이르지 않았습니다. 아직 대책이 남아있지만 이 방법은 TCP 프로토콜에서만 사용할 수 있습니다.

TCP는 신뢰할 수 있는 통신 프로토콜입니다. "신뢰할 수 있다"는 단어는 프로토콜에 오류 수정 메커니즘을 포함한 몇 가지 특별한 속성이 있음을 의미합니다. 신뢰성을 달성하기 위해 각 TCP 연결은 먼저 "핸드셰이크" 프로세스를 거쳐 연결 매개변수를 교환해야 합니다. 또한 전송된 각 패킷은 후속 패킷을 전송하기 전에 승인을 받아야 합니다. 그러나 모든 TCP 패킷에 응답하기 위해 특별한 ACK 패킷을 사용할 필요는 없습니다. 실제로 이 기능은 TCP 패킷 헤더에 특별한 비트를 설정하기만 하면 완료됩니다. 따라서 응답 패킷이 생성될 때마다 ACK 비트를 설정해야 합니다. 연결 세션의 첫 번째 패킷은 확인에 사용되지 않으므로 ACK 비트가 설정되어 있지 않습니다. 후속 세션에서 교환되는 TCP 패킷에는 ACK 비트가 설정됩니다.

예를 들어 PC가 원격 웹 서버에 연결을 시작할 때 ACK 비트가 설정되지 않은 상태로 연결 요청 패킷을 생성합니다. 서버가 요청에 응답하면 서버는 ACK 비트가 설정된 패킷과 패킷에 표시된 클라이언트로부터 수신된 바이트 수를 포함하여 패킷을 다시 보냅니다. 그런 다음 클라이언트는 자체 응답 패킷으로 패킷에 응답합니다. 이 패킷에도 ACK 비트가 설정되어 있으며 서버에서 수신한 바이트 수를 표시합니다. ACK 비트를 모니터링함으로써 네트워크로 들어오는 데이터를 응답 패킷의 범위로 제한할 수 있습니다. 결과적으로 원격 시스템은 TCP 연결을 전혀 시작할 수 없지만 수신된 데이터 패킷에 응답할 수 있습니다.

이 메커니즘은 아직 완벽하지 않습니다. 간단한 예를 들자면 내부 웹 서버가 있다고 가정하면 외부 요청이 네트워크에 들어갈 수 있도록 포트 80을 열어야 합니다. 또한 UDP 패킷의 경우 UDP 패킷에는 ACK 비트가 전혀 없기 때문에 ACK 비트를 모니터링할 방법이 없습니다. FTP와 같은 일부 TCP 애플리케이션의 경우 서버 프로그램 자체에서 연결을 시작해야 합니다.

FTP로 인한 어려움

일반 인터넷 서비스는 모든 통신에 한 쌍의 포트 번호만 사용하는 반면, FTP 프로그램은 연결 중에 두 쌍의 포트 번호를 사용합니다. 포트 번호의 첫 번째 쌍은 FTP의 "명령 채널"에 사용되어 로그인 및 명령 실행을 위한 통신 링크를 제공하고, 다른 포트 번호 쌍은 FTP의 "데이터 채널"에 사용되어 클라이언트와 클라이언트 간의 파일 전송을 제공합니다. 섬기는 사람.

일반적인 FTP 세션에서 클라이언트는 먼저 서버의 포트 21(명령 채널)에 TCP 연결 요청을 보낸 후 LOGIN, DIR 등 다양한 명령을 실행합니다. 사용자가 서버에 데이터 전송을 요청하면 FTP 서버는 포트 20(데이터 채널)을 사용하여 클라이언트의 데이터 포트에 대한 연결을 시작합니다.

문제는 서버가 클라이언트에 데이터를 전송하기 위해 연결을 시작하면 ACK 비트가 설정되지 않은 상태로 데이터 패킷을 보내고 방화벽은 이전 규칙에 따라 데이터 패킷을 거부한다는 것입니다. 더 이상 가능하지 않습니다. 일반적으로 고급 방화벽, 즉 충분히 똑똑한 방화벽만이 클라이언트가 서버에 전달한 포트를 확인한 다음 해당 포트에 대한 인바운드 연결을 허용할 수 있습니다.

UDP 포트 필터링

자, 이제 UDP 문제를 해결하는 방법을 알아보겠습니다. 방금 언급한 것처럼 UDP 패킷에는 ACK 비트가 없으므로 ACK 비트 필터링을 수행할 수 없습니다. UDP는 전송되고 무시되는 "신뢰할 수 없는" 통신입니다. 이러한 유형의 서비스는 일반적으로 방송, 라우팅 및 멀티미디어와 같은 브로드캐스트 통신 작업에 사용됩니다. NFS, DNS, WINS, NetBIOS-over-TCP/IP 및 NetWare/IP는 모두 UDP를 사용합니다.

가장 간단한 해결책은 인바운드 UDP 연결 설정을 허용하지 않는 것 같습니다. 방화벽은 내부 인터페이스의 UDP 패킷만 전달하고 외부 인터페이스의 UDP 패킷은 전달하지 않도록 설정되어 있습니다. 이제 문제는 예를 들어 DNS 이름 확인 요청이 UDP를 사용하므로 DNS 서비스를 제공하는 경우 최소한 일부 내부 요청이 방화벽을 통과하도록 허용해야 한다는 것입니다. UDP를 사용하는 IRC와 같은 클라이언트 프로그램도 있습니다. 사용자가 이를 사용하도록 하려면 UDP 패킷이 네트워크에 들어가도록 해야 합니다. 우리가 할 수 있는 일은 로컬에서 신뢰할 수 있는 사이트로의 연결을 제한하는 것입니다. 그런데 신뢰성이란 무엇을 의미하는가? 해커가 주소 스푸핑을 사용하면 이전 방식으로 돌아가지 않을까요?

일부 최신 라우터는 아웃바운드 UDP 패킷을 "기억"하여 이 문제를 해결할 수 있습니다. 인바운드 UDP 패킷이 가장 최근 아웃바운드 UDP 패킷의 대상 주소 및 포트 번호와 일치하면 이를 허용합니다. 일치하는 UDP 패킷을 메모리에서 찾을 수 없으면 거부해야 합니다! 하지만 패킷을 생성한 외부 호스트가 내부 클라이언트가 통신하려는 서버인지 어떻게 확신할 수 있습니까? 해커가 DNS 서버 주소를 허위로 주장하는 경우 이론적으로는 DNS에 연결된 UDP 포트에서 공격을 시작할 수 있습니다. 이 문제는 DNS 쿼리와 피드백 패킷이 네트워크에 진입하도록 허용하는 한 반드시 존재합니다. 해결책은 프록시 서버를 사용하는 것입니다.

소위 프록시 서버는 이름에서 알 수 있듯이 네트워크를 대표하고 외부 세계와 상호 작용하는 서버입니다. 프록시 서버는 네트워크 내부 또는 외부로부터의 직접 연결을 허용하지 않습니다. 자체적으로 공개 및 비공개 DNS, 메일 서버 및 기타 기능을 제공합니다. 프록시 서버는 단순히 패킷을 전달하는 대신 패킷을 다시 작성합니다. 이는 네트워크 내부의 호스트가 네트워크의 가장자리에 서 있는 것처럼 보이지만 실제로는 모두 프록시 뒤에 숨어 있으며, 그들이 보여주는 것은 프록시의 가면일 뿐입니다.

요약

IP 주소가 가짜일 수 있습니다. 이는 IP 프로토콜의 소스 경로 메커니즘으로 인해 라우터가 데이터 패킷에 대해 일반 경로를 사용하지 않도록 지시합니다. . 이지만 패킷 헤더의 경로에 따라 데이터 패킷을 전송합니다. 그런 다음 해커는 시스템의 IP 주소를 사용하여 반환된 패킷을 얻을 수 있습니다. 일부 고급 방화벽에서는 사용자가 소스 라우팅을 비활성화할 수 있습니다. 일반적으로 우리 네트워크는 경로를 통해 ISP에 연결한 다음 인터넷에 들어갑니다. 이때 소스 라우팅을 비활성화하면 패킷이 강제로 일반 경로를 따라 반환됩니다.

또한 패킷을 거부할 때 방화벽이 수행하는 다른 작업을 이해해야 합니다. 예를 들어, 방화벽은 연결 시작 시스템에 "호스트에 연결할 수 없음" ICMP 메시지를 다시 보냅니까? 아니면 방화벽이 실제로 다른 작업을 수행하지 않습니까? 이러한 문제는 보안 위험을 초래할 수 있습니다. ICMP "호스트에 연결할 수 없음" 메시지는 해커에게 "방화벽이 특정 포트를 특별히 차단합니다."라고 알려줍니다. 해커는 이 메시지에서 즉시 무엇인가 냄새를 맡을 수 있습니다. ICMP "Host Unreachable"이 통신 중에 발생하는 오류인 경우 정직한 시스템은 실제로 아무것도 보내지 않을 수 있습니다. 응답이 없으면 통신을 시작하는 시스템은 애플리케이션이나 프로토콜 스택의 시간이 초과될 때까지 계속 연결을 시도하게 됩니다. 결과적으로 최종 사용자는 오류 메시지만 받게 됩니다. 물론 이 방법을 사용하면 해커가 특정 포트가 닫혀 있는지, 사용 중이 아닌지 확인할 수 없습니다.