방화벽은 네트워크에 두 개의 아이콘으로 나타나는 경우가 많습니다. 하나의 아이콘은 마치 벽과도 같이 매우 시각적입니다. 다른 아이콘은 방화벽의 필터링 메커니즘에서 시각화되었으며 아이콘에는 다이오드 아이콘이 있습니다. 우리는 다이오드가 단방향 전도성을 가지고 있다는 것을 알고 있으며, 이는 방화벽이 단방향 전도성을 가지고 있음을 생생하게 보여줍니다. 이는 방화벽 필터링 메커니즘과 다소 모순되는 것처럼 보이지만 방화벽의 초기 설계 아이디어를 완전히 구현하고 현재 방화벽 필터링 메커니즘을 상당 부분 구현합니다. 방화벽의 원래 설계 아이디어는 내부 네트워크는 항상 신뢰하고 외부 네트워크는 절대 신뢰하지 않는 것이었기 때문에 원래 방화벽은 외부에서 들어오는 통신만 필터링하고 내부 네트워크 사용자가 보내는 통신을 제한하지 않았습니다. 물론, 방화벽의 필터링 메커니즘이 변경되어 외부 네트워크의 통신 연결뿐만 아니라 내부 네트워크 사용자의 일부 연결 요청 및 데이터 패킷도 필터링해야 합니다. 그러나 방화벽은 여전히 이를 준수하는 통신만 전달합니다. 보안 정책은 "일방향 통신"이라고도 할 수 있습니다.
방화벽의 원래 의미는 고대에 목조 주택을 건축하여 화재의 발생과 확산을 방지하기 위해 집 주위에 단단한 돌을 쌓아서 장벽으로 삼았다는 뜻입니다. 보호 구조를 '방화벽'이라고 불렀습니다. 사실 방화벽과 함께 작동하는 것이 '문'이다. 문이 없다면 각 방에 있는 사람들은 어떻게 소통할 수 있으며, 이 방에 있는 사람들은 어떻게 들어갈 수 있습니까? 불이 났을 때, 이 사람들은 어떻게 현장을 탈출할까요? 이 문은 우리가 여기서 말하는 방화벽의 '보안 정책'과 동일하므로 여기서 말하는 방화벽은 실제로 단단한 벽이 아니라 작은 구멍이 몇 개 있는 벽입니다. 이러한 작은 구멍은 통신을 가능하게 하는 데 사용되며, 이러한 작은 구멍에는 필터링 메커니즘이 설치되는데, 이것이 위에서 소개한 "단방향 연결"입니다.
우리가 일반적으로 네트워크 방화벽이라고 부르는 것은 고대에 실제로 화재 예방에 사용되었던 방화벽을 비유적으로 표현한 것입니다. 로컬 네트워크와 외부 네트워크를 격리하는 방어 시스템을 말합니다. 화재 예방은 기업의 내부 근거리 통신망(LAN) 네트워크를 인터넷이나 기타 외부 네트워크로부터 격리하고 상호 네트워크 액세스를 제한하여 내부 네트워크를 보호할 수 있습니다. 방화벽의 하드웨어 아키텍처는 일반적인 CPU 아키텍처, ASIC 아키텍처 및 네트워크 프로세서 아키텍처를 경험했으며 각각의 특징은 다음과 같습니다.
일반 CPU 아키텍처
가장 일반적인 일반 CPU 아키텍처입니다. Intel X86 아키텍처 기반의 방화벽입니다. 100메가비트 방화벽 중 Intel의 하드웨어는 2Gbps의 처리량을 훨씬 더 높지만 실제 애플리케이션, 특히 작은 패킷의 경우 공칭 성능과는 거리가 멀습니다. 범용 CPU의 처리 능력도 매우 제한적입니다.
국내 보안장비는 주로 X86 기반의 일반 CPU 아키텍처를 사용하고 있다.
ASIC 아키텍처
ASIC(ApplicationSpecific Integrated Circuit) 기술은 몇 년 전부터 외국의 고급 네트워크 장비에 널리 사용되었습니다. 하드웨어 포워딩 모드, 다중 버스 기술, 데이터 플레인과 제어 플레인 분리를 채택함으로써 ASIC 아키텍처 방화벽은 대역폭 용량 및 성능 부족 문제를 해결하고 안정성도 잘 보장됩니다.
ASIC 기술의 성능 이점은 주로 네트워크 계층 포워딩에 반영되지만, 강력한 컴퓨팅 성능이 필요한 응용 프로그램 계층 데이터 처리에는 이점이 없으며, 응용 프로그램이 자주 변경되는 상황에서도 이점이 없습니다. 보안 문제로 인해 유연성이 어렵고 확장성도 요구 사항을 충족하기 어렵습니다.
이 기술은 기술적, 재정적 한계가 높기 때문에 국내외 유명 제조업체에서 주로 사용하고 있습니다. 주요 대표 해외 제조업체는 Netscreen이며, 국내 주요 대표 제조업체는 Tianrongxin 및 Netroy Shenzhou입니다.
네트워크 프로세서 아키텍처
네트워크 프로세서에서 사용하는 마이크로코드를 작성하는 기술적인 어려움으로 인해 제품의 최적 성능을 구현하기 어렵습니다. 네트워크 프로세서 아키텍처는 구현하기가 어렵습니다.
국산 CPU 기반 방화벽
국내 범용 프로세서의 발전과 함께 China Core 기반 방화벽도 점차 개발되고 있으며, 주요 아키텍처는 국내 Loongson 2F+FPGA 프로토콜입니다. 프로세서. 정부, 군사 등 국가 안보에 민감한 산업에 주로 사용됩니다. 대표적인 제조업체로는 중국과학원 컴퓨팅 기술 연구소, Bohua Technology 및 기타 회사가 있습니다. 방화벽 구성에는 이중 홈 모드, 스크린 호스트 모드, 스크린 서브넷 모드 등 세 가지가 있습니다.
듀얼 홈 방식이 가장 간단합니다. Dual-homedGateway는 두 네트워크 사이에 배치됩니다. 이 Dual-omedGateway는 bastionhost라고도 합니다. 이 구조는 비용이 저렴하지만 단일 실패 지점이 있다는 문제를 안고 있습니다. 이 구조는 네트워크 보안의 자체 방어 능력을 높이지 않으며, 일단 침해되면 전체 네트워크가 노출되는 "해커" 공격의 첫 번째 대상이 되는 경우가 많습니다.
Screened-host 모드의 Screeningrouter는 Bastionhost의 보안을 보호하기 위한 장벽을 설정합니다. 들어오는 모든 정보를 먼저 Bastionhost로 보내고 Bastionhost의 데이터만 나가는 데이터로 받아들입니다. 이 구조는 Screeningrouter 및 Bastionhost에 의존합니다. 하나가 실패하면 전체 네트워크가 노출됩니다.
Screened-subnet에는 두 개의 Screeningrouter와 두 개의 Bastionhost가 포함되어 있습니다. 공용망과 사설망 사이에는 '정전지대'(DMZ, Demilitarized Zone)라 불리는 격리망이 형성되고, Bastionhost는 '휴전지대'에 배치된다. 이 구조는 보안성이 좋은데, 보안 유닛 2개가 파괴되어야만 네트워크가 노출되지만 비용도 매우 비싸다. 1세대 방화벽
1세대 방화벽 기술은 패킷 필터(Packet Filter) 기술을 사용해 라우터와 거의 동시에 등장했다.
2세대 방화벽
1세대 방화벽 기술은 주로 라우터에 구현되었으며, 이후 이 보안 기능은 분리되어 보안 필터링 기능을 구현하는 데 사용되었습니다. 1989년 벨 연구소의 데이브 프레소토(Dave Presotto)와 하워드 트리키(Howard Trickey)는 2세대 방화벽, 즉 회로 계층 방화벽을 출시했고, 3세대 방화벽의 예비 구조인 애플리케이션 계층 방화벽(프록시 방화벽)도 제안했다.
3세대 방화벽
프록시 방화벽의 등장으로 라우터와는 독립적이었던 보안 소프트웨어가 급속도로 발전하면서 보안 소프트웨어 자체를 호스팅하는 운영체제에 대한 보안 수요가 촉발됐다. . 즉, 방화벽 자체의 보안 문제에 대한 보안 요구 사항입니다.
4세대 방화벽
1992년 USC 정보과학대학원의 밥 브래든(Bob Braden)은 동적 패킷 필터(Dynamic Packet Filter) 기술을 바탕으로 4세대 방화벽을 개발했는데, 이는 이후 소위 Stateful 검사 기술로 발전했습니다. 1994년에 이스라엘 회사인 CheckPoint는 이 기술을 사용하여 최초의 상용 제품을 개발했습니다.
5세대 방화벽
1998년 NAI는 적응형 프록시(Adaptive Proxy) 기술을 출시하고 이를 자사 제품인 NT용 Gauntlet Firewall에 구현하여 프록시를 제공했습니다. 새로운 의미로 5세대 방화벽이라고 할 수 있습니다.
통합 보안 게이트웨이 UTM
UTM 통합 위협 관리는 방화벽을 기반으로 개발된 장치로 방화벽, IPS, 안티 바이러스, 안티 스팸 등의 포괄적인 기능을 갖추고 있습니다. 여러 기능을 동시에 켜면 UTM의 처리 성능이 크게 떨어지기 때문에 고성능이 요구되지 않는 중저가 분야에 주로 사용된다. 중저가 분야에서는 UTM 자체가 추가 기능이 없는 방화벽이고, 추가 기능을 통해 사용자에게 더 많은 애플리케이션 선택권을 제공하기 때문에 UTM이 방화벽을 대체할 것으로 등장했습니다. 통신, 금융 및 기타 산업과 같은 고급 애플리케이션 분야에서는 전용 고성능 방화벽과 IPS가 여전히 주류입니다.
방화벽은 일종의 필터 플러그입니다(당신의 이해가 틀린 것은 아닙니다). 당신이 좋아하는 것들은 이 플러그를 통과하게 하면 다른 모든 것들은 걸러질 것입니다. 네트워크 세계에서 방화벽에 의해 필터링되는 것은 통신 데이터를 전달하는 통신 패킷입니다.
세계의 모든 방화벽은 예 또는 아니요라는 두 단어 이상을 말합니다. 간단히 수락 또는 거부를 말하세요. 가장 간단한 방화벽은 이더넷 브리지입니다. 그러나 이 원시적인 방화벽이 많이 유용할 것이라고 생각하는 사람은 거의 없었습니다. 대부분의 방화벽은 다양한 기술과 표준을 사용합니다. 이러한 방화벽은 다양한 형태로 제공됩니다. 일부는 시스템에 이미 장착된 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 호스트 이름을 사용해서는 안 된다는 것입니다. IP 주소 스푸핑보다 DNS를 위조하는 것이 훨씬 쉽습니다.
서버 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, 메일 서버 및 기타 기능을 제공합니다. 프록시 서버는 단순히 패킷을 전달하는 대신 패킷을 다시 작성합니다. 이는 네트워크 내부의 호스트가 네트워크의 가장자리에 서 있는 것처럼 보이지만 실제로는 모두 프록시 뒤에 숨어 있으며, 그들이 보여주는 것은 프록시의 가면일 뿐입니다. 방화벽은 보안 정책을 구현합니다. 방화벽은 일부 보안 정책을 시행합니다. 방화벽을 설치하기 전에 보안 정책을 만들지 않았다면 이제 하나를 만들어야 합니다. 기록할 필요는 없지만 여전히 보안 정책의 역할을 할 수 있습니다. 보안 정책이 무엇인지 명확하게 밝히지 않은 경우 방화벽을 설치하는 것이 사이트를 보호하는 최선의 방법이지만 이를 항상 유지하는 것은 쉽지 않습니다. 좋은 방화벽을 가지려면 모든 사람이 작성하고 승인하는 좋은 보안 정책이 필요합니다. 방화벽은 단일 장치가 아닌 경우가 많습니다. 특히 간단한 경우를 제외하면 방화벽은 단일 장치인 경우가 거의 없으며 장치 그룹입니다. 상업용 "일체형" 방화벽 응용 프로그램을 구입하더라도 해당 응용 프로그램과 함께 실행되도록 다른 시스템(예: 웹 서버)을 구성해야 합니다.
이러한 다른 시스템은 방화벽의 일부로 간주되며, 여기에는 이러한 시스템이 구성 및 관리되는 방법, 신뢰하는 대상, 신뢰할 수 있는 것으로 간주되는 대상 등이 포함됩니다. 단순히 "방화벽"이라는 장치를 선택하고 그것이 모든 보안 책임을 맡을 것이라고 기대할 수는 없습니다.
2. 방화벽은 쉽게 구할 수 있는 제품이 아닙니다.
방화벽을 선택하는 것은 휴가를 갈 곳을 선택하는 것보다 집을 구입하는 것과 같습니다. 방화벽은 집과 매우 유사하며 매일 유지해야 하며 1~2주 이상 사용해야 합니다. 모두 유지 관리가 필요합니다. 그렇지 않으면 붕괴될 것입니다. 방화벽을 구축하려면 요구 사항을 충족하는 솔루션을 신중하게 선택 및 구성한 다음 시간이 지남에 따라 유지 관리해야 합니다. 내려야 할 결정이 많이 있으며, 한 사이트에 대한 올바른 솔루션이 다른 사이트에서는 잘못된 솔루션일 수 있는 경우가 많습니다.
3. 방화벽이 모든 문제를 해결하지는 않습니다.
방화벽 자체가 보안을 제공할 것이라고 기대하지 마십시오. 방화벽은 외부에서 내부를 직접 공격하려는 공격 유형 중 하나로부터 사용자를 보호합니다. 그러나 LAN 내부의 공격으로부터 보호하지 않으며, 탐지할 수 있는 모든 공격으로부터 사용자를 보호하지도 않습니다.
4. 기본 정책 사용
일반적으로 접근 방식은 필요하고 안전하다고 생각되는 서비스를 제외한 모든 서비스를 거부하는 것입니다. 하지만 매일 새로운 취약점이 나타나고 있으며, 안전하지 않은 서비스를 종료한다는 것은 끊임없는 전쟁을 의미합니다.
5. 가볍게 타협하지 말고 조건으로 타협하세요.
사람들은 안전하지 않은 일을 하는 것을 좋아합니다. 모든 요청을 허용하면 네트워크가 매우 안전하지 않게 됩니다. 모든 요청을 거부하면 네트워크도 안전하지 않으며 안전하지 않은 내용이 어디에 숨어 있는지 알 수 없습니다. 당신과 함께 일할 수 없는 자들은 당신을 대적할 것입니다. 사용자의 요구 사항을 충족할 수 있는 방법을 찾아야 하지만 이러한 방법에는 어느 정도의 위험이 따르게 됩니다.
6. 계층화된 접근 방식을 사용하고
한 위치에 단일 장치를 두십시오. 여러 보안 계층을 사용하여 단일 실수로 인해 관심 있는 문제가 손상되는 것을 방지하세요.
7. 필요한 것만 설치
방화벽 시스템은 일반 컴퓨터처럼 제조업체에서 제공하는 배포판을 모두 설치할 수 없습니다. 방화벽의 일부인 머신은 최소한으로 설치해야 합니다. 안전하다고 생각하더라도 필요하지 않으면 설치하지 마세요.
8. 사용 가능한 모든 소스를 사용하십시오.
단일 소스의 정보를 기반으로 방화벽을 구축하지 마십시오. 특히 해당 소스가 공급업체에서 제공되지 않은 경우에는 더욱 그렇습니다. 예를 들어, 공급업체 정보, 우리가 작성한 서적, 메일링 목록, 웹사이트 등 다양한 리소스를 사용할 수 있습니다.
9. 확신할 수 있는 것만 신뢰하세요.
어떤 연결이 거부되어야 하는지 결정하려면 GUI 매뉴얼과 대화 상자 또는 공급업체의 주장을 신뢰하지 마세요. 모두 거절했습니다. 허용되어야 하는 연결이 허용되는지 확인하십시오.
10. 결정을 끊임없이 재평가하세요
당신이 구입한 집이 오늘 당신에게 적합하지 않을 수도 있습니다. 마찬가지로, 1년 전에 설치한 방화벽은 더 이상 현재 상황에 가장 적합한 솔루션이 아닙니다. 방화벽에 관한 결정을 항상 평가하고 합리적인 솔루션이 있는지 확인해야 합니다. 새 집으로 이사하는 것처럼 방화벽을 변경하려면 상당한 노력과 신중한 계획이 필요합니다.
11. 실패에 대해 정신적으로 준비하십시오.
최악의 상황에 대해 정신적으로 준비하십시오. 방화벽은 전능하지 않으며 일부 새로운 바이러스 및 트로이 목마를 반영하지 않을 수 있으므로 자주 업데이트해야 합니다. 기계가 작동을 멈출 수도 있고, 좋은 동기를 가진 사용자가 나쁜 일을 할 수도 있으며, 악의적인 동기를 가진 사용자가 나쁜 일을 하여 성공할 수도 있습니다. 하지만 이런 일이 발생하더라도 완전한 재앙은 아니라는 점을 이해해야 합니다. 바이러스는 급속도로 발전하고 종류가 다양하기 때문에 방화벽으로는 모두 차단할 수 없으므로 정신적으로 최악의 상황에 대비해야 합니다. 다음은 예방 계획을 세우고 자신의 안전 보호를 강화하세요.
Online Armor Free 4.0.0.35 무료 버전
Malware Defender 2.6.0-국내 방화벽
Kaspersky Internet Security 2010 9.0.0.736
Privatefirewall 7.0.20.36- 무료 버전
Outpost Firewall Free 2009 6.5.1.2725.381.0687-무료 버전
ZoneAlarm Extreme Security 9.1.008.000
Norton Internet Security 2010 17.5.0.127
p> p>
Jetico 개인 방화벽 2.1.0.7.2412
BitDefender Internet Security 2010 13.0.19.347
Trend Micro Internet Security Pro 2010 17.50.1647.0000
< p> avast! Internet Security 5.0.418.0McAfee Internet Security 2010 11.0.378
Panda Internet Security 2010 15.01.00 1. Windows 방화벽을 끄는 방법 a: " 시작" 메뉴, "실행" 및 제어 명령을 입력하여 제어판을 엽니다. b: 제어판에서 "방화벽" 아이콘을 찾아 두 번 클릭하여 엽니다. c: "닫기(권장하지 않음)"를 선택하고 확인합니다. 방화벽을 닫으려면
2. Windows 방화벽을 켜는 방법: Windows 방화벽을 켜려면 방화벽 끄기의 세 번째 단계를 "사용(권장)"으로 변경하면 됩니다.