왜 방화벽 서버를 사용해야합니까? 나 자신과 내가 일하는 회사

참고 : 나는 이것을 화염 전쟁으로 만드는 데 관심이 없다! 나는 많은 사람들이 방화벽 솔루션에 많은 노력을 기울 였고 또한 그들의 필요성을 믿도록 교리를 받았기 때문에이 주제에 대한 신념을 아주 잘 알고 있음을 이해합니다.

그러나 보안 전문가 인 사람들의 답변을 찾고 있습니다. 나는 이것이 중요한 질문이라고 생각하며, 그 대답은 나 자신과 내가 일하는 회사 이상으로 이익을 얻을 것이다. 방화벽없이 전혀 타협하지 않고 몇 년 동안 서버 네트워크를 운영해 왔습니다. 우리 가진 보안 타협 은 방화벽으로 막을 수 없었습니다.

“서버”라고 할 때 항상 “비밀 내부 청구 데이터베이스”가 아니라 “공개적으로 제공되는 서비스”를 의미하기 때문에 여기서 너무 오래 일한 것 같습니다. 따라서, 우리가 어떤 규칙 것이 어떤 방화벽에있는 전체 인터넷 액세스를 허용해야합니다. 또한 공용 액세스 서버는 모두 사무실과 별개의 전용 데이터 센터에 있습니다.

다른 사람 이 비슷한 질문을했고 내 대답은 음수로 투표되었습니다. 이로 인해 투표에 참여한 사람들이 실제로 내 대답을 이해하지 못했거나 현재하고있는 일을 수행 할만큼 충분한 보안을 이해하지 못한다고 믿게되었습니다.

이것은 서버 보안에 대한 나의 접근 방식입니다.

  1. 서버를 인터넷에 연결 하기 전에 운영 체제의 보안 지침을 따르십시오 .

  2. TCP 래퍼를 사용하여 SSH (및 기타 관리 서비스)에 대한 액세스를 적은 수의 IP 주소로 제한하십시오.

  3. Munin 으로이 서버의 상태를 모니터하십시오 . 그리고 기본 구성에서 Munin-node 고유의 심각한 보안 문제를 수정하십시오.

  4. 새 서버를 Nmap하십시오 (또한 서버를 인터넷에 연결하기 전에). 이 서버를 방화벽으로 사용하려면 들어오는 연결로 제한되는 정확한 포트 집합이어야합니다.

  5. 서버 룸에 서버를 설치하고 공용 IP 주소를 제공하십시오.

  6. 운영 체제의 보안 업데이트 기능을 사용하여 시스템을 안전하게 유지하십시오.

저의 철학 (및 문제의 기초)은 강력한 호스트 기반 보안이 방화벽의 필요성을 제거한다는 것입니다. 전반적인 보안 철학에 따르면 방화벽이 있어도 강력한 호스트 기반 보안이 여전히 필요합니다 ( 보안 지침 참조 ). 그 이유는 퍼블릭 서비스를 서버로 전달하는 방화벽이 침입자가 방화벽을 전혀 사용하지 않는 것만 큼 가능하기 때문입니다. 취약한 서비스 자체이며 전체 인터넷에 해당 서비스를 제공하는 것이 운영의 요구 사항이므로 액세스를 제한하는 것이 중요하지 않습니다.

이 경우 입니다 전체 인터넷에 액세스 할 필요가없는 서버에서 사용 가능한 포트는, 그 소프트웨어는 1 단계에서 종료 될 필요하고, 공격자가 성공적으로 취약한 소프트웨어를 통해 서버에 침입해야 4 단계에 의해 확인되었다 포트 자체를 열면 공격자는 임의 포트에서 아웃 바운드 연결을 통해 방화벽을 쉽게 물리 칠 수 있습니다. 보안의 요점은 성공적인 공격 후에 자신을 방어하는 것이 아니라 이미 불가능한 것으로 입증 된 것이므로 공격자를 우선적으로 차단하는 것입니다.

열린 항구 외에 다른 보안 고려 사항이 있다고 제안되었지만, 그것은 단지 자신의 믿음을 변호하는 것처럼 들립니다. 포트가 해당 운영 체제 / TCP 스택으로 직접 전달된다는 사실에 기초하여 방화벽이 존재하는지 여부에 관계없이 모든 운영 체제 / TCP 스택 취약성은 동일하게 취약해야합니다. 마찬가지로, 라우터에서 방화벽을 사용하는 것과는 반대로 서버 자체에서 방화벽을 실행하면 (또는 두 곳에서 모두 더 나빠짐) 불필요한 복잡한 계층이 추가되는 것으로 보입니다. 나는 “보안은 층으로 나온다”는 철학을 이해하지만, X 개의 합판 층을 서로 쌓아 올린 다음 지붕을 뚫고 구멍을 뚫는 것과 같은 점이 있습니다. 합판의 다른 층은 그 구멍을 통한 누출을 막지 않을 것입니다.

솔직히 말해서, 방화벽이 서버에 사용되는 것을 보는 유일한 방법은 스팸에 대한 RBL과 같은 알려진 공격자의 모든 서버에 대한 모든 연결을 막는 동적 규칙이있는 경우입니다 (우연히 메일 서버가하는 일임) . 불행히도, 그렇게하는 방화벽을 찾을 수 없습니다. 다음으로 가장 좋은 방법은 IDS 서버이지만 공격자는 실제 서버를 먼저 공격하지 않으며 공격자는 공격 하기 전에 전체 네트워크를 조사하려고합니다 . 게다가, 이들은 많은 수의 오탐 (false positive)을 생성하는 것으로 알려져있다.



답변

방화벽의 장점 :

  1. 아웃 바운드 트래픽을 필터링 할 수 있습니다.
  2. IPS (계층 7 방화벽)는 알려진 응용 프로그램 취약점으로부터 보호 할 수 있습니다.
  3. TCP 랩퍼를 사용하여 각 개별 시스템의 해당 포트에서 서비스를 수신하거나 액세스를 거부하지 않고 특정 IP 주소 범위 및 / 또는 포트를 중앙에서 차단할 수 있습니다 .
  4. 방화벽은 보안을 덜 인식하는 사용자 / 관리자에게 두 번째 방어선을 제공 할 수 있으므로 처리해야 할 경우 도움이됩니다. 그것들이 없으면 호스트가 안전하다는 것을 절대적으로 확신해야하며, 이는 모든 관리자의 충분한 보안 이해가 필요합니다.
  5. 방화벽 로그는 중앙 로그를 제공하고 수직 스캔을 감지하는 데 도움이됩니다. 방화벽 로그는 일부 사용자 / 클라이언트가 모든 서버의 동일한 포트에 주기적으로 연결하려고하는지 여부를 결정하는 데 도움이 될 수 있습니다. 방화벽없이이 작업을 수행하려면 중앙 집중식보기를 얻기 위해 다양한 서버 / 호스트의 로그를 결합해야합니다.
  6. 방화벽에는 안티 스팸 / 바이러스 백신 모듈도 함께 제공되어 보호 기능도 강화합니다.
  7. OS 독립적 보안. 호스트 OS를 기반으로 호스트를 보호하려면 다른 기술 / 방법이 필요합니다. 예를 들어, TCP 랩퍼는 Windows 시스템에서 사용하지 못할 수 있습니다.

무엇보다도 방화벽이없고 시스템이 손상된 경우 어떻게 감지합니까? 로컬 시스템에서 일부 명령 ‘ps’, ‘netstat’등을 실행하려고하면 바이너리를 교체 할 수 있으므로 신뢰할 수 없습니다. 원격 시스템의 ‘nmap’은 공격자가 루트킷이 선택한 시간에 선택한 소스 IP 주소의 연결 만 수락하도록 보장 할 수 있으므로 보호되지 않습니다.

하드웨어 방화벽은 호스트 OS / 파일과 비교하여 방화벽 OS / 파일을 변경하기가 매우 어려운 시나리오에서 도움이됩니다.

방화벽의 단점 :

  1. 사람들은 방화벽이 보안을 관리하고 시스템을 정기적으로 업데이트하지 않고 원치 않는 서비스를 중지하지 않을 것이라고 생각합니다.
  2. 가격은 ~입니다. 때때로 연간 라이센스 비용을 지불해야합니다. 특히 방화벽에 안티 바이러스 및 안티 스팸 모듈이있는 경우.
  3. 추가 단일 실패 지점. 모든 트래픽이 방화벽을 통과하고 방화벽이 실패하면 네트워크가 중지됩니다. 중복 방화벽을 가질 수는 있지만 이전의 원가 절감이 더욱 증폭됩니다.
  4. 상태 저장 추적은 들어오는 모든 연결을 허용하는 공용 시스템에는 가치가 없습니다.
  5. 상태 저장 방화벽은 DDoS 공격 중에 대규모 병목 현상이 발생하며 상태를 유지하고 들어오는 모든 연결을 검사하기 때문에 가장 먼저 실패하는 경우가 많습니다.
  6. 방화벽은 암호화 된 트래픽 내부를 볼 수 없습니다. 모든 트래픽 엔드-투-엔드로 암호화 되어야 하므로 대부분의 방화벽은 퍼블릭 서버 앞에 거의 가치가 없습니다. 일부 차세대 방화벽에는 TLS를 종료하고 트래픽 내부를 볼 수있는 개인 키가 제공 될 수 있지만 DDoS에 대한 방화벽의 민감도는 더욱 높아지고 TLS의 엔드 투 엔드 보안 모델이 손상됩니다.
  7. 운영 체제 및 응용 프로그램은 방화벽보다 훨씬 빠르게 취약성에 대해 패치됩니다. 방화벽 공급 업체는 종종 패치없이 몇 년 동안 알려진 문제를 겪고 있으며 방화벽 클러스터를 패치하려면 일반적으로 많은 서비스와 아웃 바운드 연결을위한 가동 중지 시간이 필요합니다.
  8. 방화벽은 완벽하지 않으며 많은 사람들이 악명 높은 버그입니다. 방화벽은 특정 형태의 운영 체제에서 실행되는 소프트웨어 일 뿐이며 (보통 느린) CPU 외에 추가 ASIC 또는 FPGA가있을 수 있습니다. 방화벽에는 버그가 있지만이를 해결하기위한 도구가 거의없는 것 같습니다. 따라서 방화벽은 응용 프로그램 스택에 복잡성과 진단하기 어려운 추가 오류 소스를 추가합니다.

답변

TCP Wrappers는 호스트 기반 방화벽 구현이라고 할 수 있습니다. 네트워크 트래픽을 필터링하고 있습니다.

침입자가 임의의 포트에서 아웃 바운드 연결을하는 경우 방화벽은 발신 트래픽도 제어 할 수있는 수단을 제공합니다. 올바르게 구성된 방화벽은 시스템과 관련된 위험에 적합한 방식으로 수신 및 송신을 관리합니다.

방화벽이 TCP 취약점을 완화하지 않는 방법에 대해서는 방화벽 작동 방식에 익숙하지 않습니다. Cisco에는 특정 운영 체제 문제를 일으킬 수있는 방식으로 구성된 패킷을 식별하는 다운로드 가능한 규칙이 많이 있습니다. Snort를 가져 와서 올바른 규칙 세트로 실행을 시작하면 이러한 종류의 경고가 표시됩니다. 물론 Linux iptables는 악성 패킷을 필터링 할 수 있습니다.

기본적으로 방화벽은 사전 방역입니다. 사전 예방 적 행동에서 멀어 질수록 문제를 예방하기보다는 문제에 대응하는 상황에 처할 가능성이 높습니다. 전용 방화벽과 마찬가지로 경계에 보호 기능을 집중하면 사방에 규칙을 복제하는 것이 아니라 중앙에 질식 지점이 있으므로 관리하기가 더 쉽습니다.

그러나 반드시 유일한 해결책은 아닙니다. 좋은 보안 솔루션은 일반적으로 경계에 방화벽이 있고 장치에 TCP 래퍼가 있으며 내부 라우터의 규칙도있는 다중 계층입니다. 일반적으로 인터넷에서 네트워크를 보호하고 서로 노드를 보호해야합니다. 이 다층 접근 방식은 여러 장의 합판을 통해 구멍을 뚫는 것과 같지 않습니다. 이는 한 쌍의 문을 세우는 것과 비슷하기 때문에 침입자가 하나의 자물쇠 대신 두 개의 자물쇠를 끊을 수 있습니다. 이것을 물리적 보안의 맨 트랩 (man trap)이라고하며 대부분의 모든 건물에는 이유가 있습니다. 🙂


답변

( ” 방화벽없는 수명 “을 읽을 수도 있습니다 )

이제 : 더 이상 패치가 게시되지 않는 레거시 시스템이 있습니까? N- 머신에 패치를 적용 할 수없는 동시에 패치를 네트워크의 더 적은 노드 (방화벽)에 적용 할 수 있습니까?

방화벽의 존재 또는 필요성에 대해서는 논란의 여지가 없습니다. 실제로 중요한 것은 보안 정책을 구현해야한다는 것입니다. 그렇게하려면 도구를 구현할 도구를 사용하고 관리, 확장 및 발전시키는 데 도움이됩니다. 방화벽이 필요한 경우에는 괜찮습니다. 그들이 필요하지 않으면 괜찮습니다. 실제로 중요한 것은 작동하고 검증 가능한 보안 정책 구현입니다.


답변

대부분의 설명은 방화벽에 대한 요구를 반박하는 것처럼 보이지만 방화벽을 설정하는 데 적은 시간이 아닌 다른 방화벽을 사용해야한다는 단점은 보이지 않습니다.

단어의 엄격한 의미에서 “필수”는 거의 없습니다. 보안은 가능한 모든 봉쇄를 설정하는 것입니다. 서버에 침입하는 데 필요한 작업이 많을수록 성공적인 공격 가능성이 줄어 듭니다. 다른 곳보다 기계에 침입하는 것이 더 많은 작업을 원합니다. 방화벽을 추가하면 더 많은 작업이 이루어집니다.

보안의 중복성이 핵심 용도라고 생각합니다. 방화벽의 또 다른 장점은 거부 된 요청에 응답하지 않고 모든 포트에 연결하려는 시도를 간단히 중단 할 수 있다는 점입니다. 이렇게하면 공격자가 nmapping을 조금 더 불편하게 만들 수 있습니다.

귀하의 질문에 대한 실질적인 메모에서 가장 중요한 것은 SSH, ICMP 및 기타 내부 서비스를 로컬 서브넷에 고정하고 들어오는 연결을 제한하여 DOS 공격을 완화하는 데 도움이된다는 것입니다.

“보안의 요점은 공격이 성공한 후에 자신을 방어하는 것이 아니라 이미 불가능한 것으로 입증 된 것입니다. 이는 공격자를 우선적으로 차단하는 것입니다.”

동의하지 않습니다. 손해를 제한하는 것도 중요 할 수 있습니다. (이 이상적인 이유에서 암호를 해시하거나 웹 응용 프로그램과 다른 서버에 데이터베이스 소프트웨어를 집어 넣는 이유는 무엇입니까?) 이전에 “모든 달걀을 한 바구니에 집어 넣지 마십시오”라는 말이 여기에 해당한다고 생각합니다.


답변

Should I firewall my server?좋은 질문. 합법적으로 열려있는 소수의 포트를 제외한 모든 포트에 대한 연결 시도를 이미 거부하는 네트워크 스택 위에 방화벽을 두드리는 데는 거의 도움이되지 않는 것 같습니다. 악의적으로 제작 된 패킷이 호스트를 방해 / 악용 할 수있는 취약점이 OS 에있는 경우 동일한 호스트에서 실행중인 방화벽 이 악용을 막을 수 있습니까? 음, 어쩌면

이것이 모든 호스트에서 방화벽을 실행하는 가장 강력한 이유 일 수 있습니다. 방화벽 은 네트워크 스택 취약점을 악용하지 못할 수 있습니다 . 충분한 이유가 있습니까? 잘 모르겠지만 “방화벽 설치로 해고 된 사람은 아무도 없습니다”라고 말할 수 있다고 생각합니다.

서버에서 방화벽을 실행하는 또 다른 이유는이 두 가지 상관 관계가 강한 관심사를 분리하기위한 것입니다.

  1. 어디에서 어떤 포트로 연결을 수락합니까?
  2. 어떤 서비스가 연결을 실행하고 있고 듣고 있습니까?

방화벽이 없으면 (tcpwrapper 등의 구성과 함께) 실행중인 서비스 세트가 서버가 열려있는 포트 세트와 연결을 승인 할 포트 세트를 완전히 결정합니다. 호스트 기반 방화벽은 관리자에게 새로운 서비스를보다 널리 사용 가능하게하기 전에 제어 된 방식으로 설치 및 테스트 할 수있는 유연성을 제공합니다. 이러한 유연성이 필요하지 않은 경우 서버에 방화벽을 설치할 이유가 적습니다.

마지막으로 보안 점검 목록에 언급하지 않은 항목 중 하나가 항상 추가되며 AIDE 또는 samhain 과 같은 호스트 기반 침입 탐지 시스템 (HIDS) 입니다. 좋은 HIDS는 침입자가 시스템을 원치 않게 변경하고 탐지되지 않는 것을 매우 어렵게 만듭니다. 모든 서버에서 일종의 HIDS를 실행해야한다고 생각합니다.


답변

방화벽은 도구입니다. 그것은 그 자체로 안전하지는 않지만 안전한 네트워크에서 계층으로 기여할 수 있습니다. 그렇다고해서 꼭 필요한 것은 아니며, 왜 그렇게 생각하는지, 방화벽의 강점과 약점을 이해하지 못하는 사람은 맹목적으로 “방화벽을 얻어야한다”고 말하는 사람들에 대해 걱정하고 있습니다.

우리가 필요하지 않다고 말할 수있는 많은 도구가 있습니다 … 안티 바이러스없이 Windows 컴퓨터를 실행할 수 있습니까? 그렇습니다.하지만 보험이있는 것은 좋은 보험입니다.

방화벽에 대해서도 똑같이 말하고 싶습니다. 방화벽에 대해 말할 수있는 것은 좋은 수준의 보험입니다. 패치, 기계 잠금, 사용하지 않는 서비스 비활성화, 로깅 등을 대신 할 수는 없지만 유용한 보충 자료가 될 수 있습니다.

또한 신중하게 계획된 서버 그룹 앞에 방화벽을 배치할지 또는 워크 스테이션과 서버가 혼합 된 일반적인 LAN 앞에 방화벽을 배치하는지에 따라 방정식이 약간 변경되는 것이 좋습니다. 일부는 IT 팀의 최선의 노력과 희망에도 불구하고 꽤 털이 많은 것들을 운영하고있을 수 있습니다.

고려해야 할 또 다른 사항은 분명히 강화 된 대상을 만드는 이점입니다. 밝은 조명, 무거운 자물쇠 및 건물의 명백한 경보 상자 등 눈에 보이는 보안; 또는 사업 범위의 IP 주소에 명백한 방화벽이 있으면 일반 침입자를 막을 수 있습니다. 이것은 당신이 원하는 정보를 알고 있고 그것을 얻기로 결심 한 결정된 침입자를 막을 수는 없지만, 캐주얼 침입자를 막는 것은 여전히 ​​가치가 있습니다. 특히 프로브가 억제력을 넘어서서 침입하는 침입자를 특히 진지하게 받아 들여야한다는 것을 알고 있다면 .


답변

모든 좋은 질문. 그러나-나는 성능이 테이블에 가져 오지 않은 것에 매우 놀랐습니다.

CPU 측면에서 많이 사용되는 웹 프런트 엔드의 경우 로컬 방화벽은 성능, 기간을 실제로 저하시킵니다. 로드 테스트를 시도해보십시오. 나는이 톤을 보았다. 방화벽을 끄면 성능 (초당 요청)이 70 % 이상 향상되었습니다.

이 절충을 고려해야합니다.