서버 전용 방화벽에서 깊은 패킷 검사가 필요합니까? [닫은

Question

방화벽 뒤에 서버가 있습니다. 웹 응용 프로그램 (Apache Tomcat 아래에서 Java 서블릿)을 실행하고 포트 443 (HTTPS)에만 응답합니다. 제공된 페이지에는 스크립팅 코드가 없습니다. 양식은 HTTP 게시물을 사용하여 양식을 수신하고 데이터를 처리 한 다음 HTTP 결과 페이지를 출력합니다.

현재 기기 방화벽을 사용하고 있지만 '하드웨어-플레이크'입니다. 나는 더 '산업 강도'솔루션으로 업그레이드하려고했지만 공급 업체는 "Deep Packet Inspection"소프트웨어에 대한 구독을 구매해야한다고 주장합니다. 그는 웹 서버조차도 이런 종류의 보호가 필요하다고 주장합니다.

나는 확신하지는 않지만 확실한 보안 배경이 없습니다. 방화벽은 "세계"와 내 서버 사이에 앉아 "포트 전달"을 사용하여 포트 443 및 22 (유지 보수 용) 만 서버에 도달 할 수 있도록합니다.

그래서 -이 깊은 패킷 검사가 정말로 필요합니까?

Answer 1

관심있는 유일한 프로토콜 (SSH 및 HTTPS)은 "Connect에서 암호화 협상"이라는 점을 감안할 때, 그 시점 이후 표준 방화벽이 검사 할 수있는 것은 거의 없습니다. SSL/SSH 세션이 설정되면 방화벽에는 암호화 된 패킷 만 볼 수 있습니다. 이 맥락에서 제품이 검사하는 내용을 공급 업체에게 물어보십시오.

또는 장치가 프록시처럼 작용할 수 있습니다. 실제 서버로 릴레이하기 전에 연결의 서버 측 엔드 포인트 역할을 할 수 있습니다.이 경우 제품이 더 깊은 일을 할 수 있습니다. 방화벽이 실제로 "포트 전달"인 경우에는 그렇지 않습니다. 다시 말하지만, 공급 업체는 장치 작동 방식을 설명 할 수 있어야합니다.

또한 검사 시스템이 보호하기 위해 어떤 취약점/위험이 있는지 물어볼 수도 있습니다. 예를 들어 : SQL 주입을 찾습니까? 특정 플랫폼을 대상으로합니까? (예를 들어 웹 서버가 SPARC CPU에서 실행되는 경우 X86 ShellCode에 대한 URL을 검사하는 점은 거의 없습니다).

Answer 2

네트워크 보안 전문가로서 이것은 나에게 과잉처럼 들립니다.

Martin Carpenter의 답변은 목표에 100%입니다. 보안을 고려할 때마다 이해해야합니다

• 당신이 확보하는 것,
• 당신이 그것을 확보하는 것 에 맞서,
• 공격의 가능성 및
• 공격이 성공하면 위험.

2 개의 포트에서만 암호화되고 인증 된 통신 만 허용하는 응용 프로그램의 경우 몇 가지 취약점 만 볼 수 있습니다.

• 방화벽이 해당 공격을 차단하지 않는 한, 서비스 거부 (DOS)는 항상 위협입니다.
• 다른 포트에서 다른 응용 프로그램을 듣고있을 수 있지만 간단한 포트 스캔 프로그램으로 감지 할 수 있습니다.
• 제한하고 싶을 수도 있습니다 배 밖으로 사용자 또는 불량 애플리케이션을 방지하기위한 커뮤니케이션 시작 무단 서버와의 통신.

또한 공급 업체에게 "깊은 패킷 검사"가 자신에게 무엇을 의미하는지, 특정 상황에 필요한 이유를 묻는 것이 좋은 생각에 동의합니다. 구체적이고 지식이 풍부한 답변을받지 않는 한 평신도의 용어, 저것 당신에게 의미가 있습니다, 나는 다른 곳으로 갈 것입니다. 유행어없이 간단히 설명 할 수없는 네트워크 보안에 대해서는 아무것도 없습니다.

Answer 3

여러 전선에 대한 업데이트 ...

첫째 - 이제 OTS 하드웨어 제품의 플라크 성 중 일부는 저전력 CPU와 불충분 한 버퍼 메모리의 조합이라고 믿을만한 이유가 있습니다. 몇 주 동안 로깅과 몇 차례의 충돌로 충돌 전에 로그에 항목이 없지만 로그 컨트롤에 따라 모든 것을 기록하고 있습니다. 다른 방화벽 공급 업체와 대화하면서, 버퍼가 많이 사용하는 동안 비우는 것보다 더 빨리 충전되고 있음을 나타냅니다. 이것은 결과에 해당합니다 - 가장 많이 사용되는 IP는 가장 자주 충돌하는 IP입니다.

그래서 확인했고 방화벽에는 깊은 패킷 검사 물건이 켜졌습니다. 나는 상황이 개선되는지 확인하기 위해 그것을 끕니다.

내 네트워크 시나리오에서 방화벽의 주요 목적은 "게이트 골키퍼"입니다. 즉, 방화벽이 HTTP, HTTPS 및 일부 SSH를 제외한 모든 트래픽이 WAN 포트를 넘어서는 것을 방지하기를 원합니다. 방화벽 내부에는 사용자가 없으므로 내부에서 생성 된 트래픽은 내 응용 프로그램에서 나오며 허용 될 수 있습니다.

한 공급 업체와의 추가 대화에 따르면 더 이상 깊은 패킷 검사가 필요하지 않다는 것이 밝혀졌습니다. 다른 동료는 단지 해당 장치에서 나를 "상향"하려고했습니다. 나는 또한 그들의 하드웨어가 많은 돈을 쓰지 않고 내가 원하는 모든 것을 실제로 할 수는 없다는 것을 알았습니다.

나는 이제 OpenBSD와 PF 방화벽의 사용을 심각하게 탐색하여 비용 효율적인 방식으로 내가 reauire를 수행합니다.