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

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

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

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

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

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 % 이상 향상되었습니다.

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

방화벽은 추가 보호입니다. 서버 스택이 보호하는 세 가지 특정 시나리오는 네트워크 스택 공격 (예 : 서버 OS가 포트 수준에 도달하지 않는 특수하게 조작 된 패킷에 취약 함), "전화 홈"에 연결하는 성공적인 침입 (또는 스팸 전송 등)입니다. ) 또는 서버 포트를 성공적으로 열거 나 감지하기 어려운 포트를 열기 전에 포트 노킹 순서를 확인하십시오. 물론, 마지막 2 개는 침입을 방지하기보다는 침입의 피해를 완화시키는 것과 관련이 있지만 이것이 그것이 쓸모 없다는 것을 의미하지는 않습니다. 보안은 전적으로 또는 전혀없는 제안이 아니라는 점을 기억하십시오. 하나는 계층화 된 접근 방식, 벨트 및 멜빵을 사용하여 사용자의 요구에 충분한 수준의 보안을 달성합니다.

나는 어떤 보안 전문가도 아니지만 방화벽이있는 것처럼 들립니다. 방화벽의 핵심 기능 중 일부를 가져 와서 정책 및 절차의 일부로 만든 것처럼 보입니다. 아니요, 방화벽과 동일한 작업을 수행하려는 경우 방화벽이 필요하지 않습니다. 나 자신에 관해서는, 나는 보안을 유지하는 데 최선을 다하지만 방화벽을 어깨 너머로 바라보고 있지만 어느 시점에서 방화벽이하는 모든 일을 할 수 있으면 방화벽이 무의미 해지기 시작합니다.

소규모 설정에는 방화벽이 필요하지 않습니다. 하나 또는 두 개의 서버가있는 경우 소프트웨어 방화벽을 유지 관리 할 수 ​​있습니다. 그러나 우리는 전용 방화벽 없이는 실행되지 않으며이 철학을 유지해야하는 몇 가지 이유가 있습니다.

역할 분리

서버는 응용 프로그램을위한 것입니다. 방화벽은 패킷 검사, 필터링 및 정책을위한 것입니다. 웹 서버는 웹 페이지를 제공하는 것에 대해 걱정해야합니다. 두 역할을 하나의 장치에 두는 것은 회계사에게 경비원에게 요청하는 것과 같습니다.

소프트웨어는 움직이는 목표입니다

호스트의 소프트웨어는 항상 변경됩니다. 응용 프로그램은 자체 방화벽 예외를 만들 수 있습니다. OS가 업데이트 및 패치되었습니다. 서버는 트래픽이 많은 "관리자"영역이며 방화벽 정책 / 보안 정책은 종종 응용 프로그램 구성보다 보안에 더 중요합니다. Windows 환경에서 누군가가 일부 그룹 정책 수준에서 실수를하고 데스크톱 PC에서 Windows 방화벽을 끄고 서버에 적용된다는 것을 인식하지 못한다고 가정합니다. 당신은 클릭의 문제에 크게 열려 있습니다.

방화벽 펌웨어 업데이트는 일반적으로 1 년에 한두 번 나오지만 OS 및 서비스 업데이트는 지속적인 스트림입니다.

재사용 가능한 서비스 / 정책 / 규칙, 관리 효율성

"웹 서버"라는 서비스 / 정책을 한 번 설정하고 (예 : TCP 80 및 TCP 443) 방화벽 수준에서 "웹 서버 그룹"에 적용하면 훨씬 효율적입니다 (몇 가지 구성 변경). 10 박스에 방화벽 서비스를 설치하고 2 포트 x 10 회 개방하는 것보다 인적 오류가 발생하기 쉽습니다. 해당 정책을 변경해야하는 경우 1 변경 대 10입니다.

공격 중이나 타협 후에도 방화벽을 관리 할 수 ​​있습니다

호스트 기반 방화벽 + 응용 프로그램 서버가 공격을 받고 CPU가 차트에서 벗어났다고 가정합니다. 무슨 일이 일어나고 있는지 파악하기 시작하면 공격자가 침입하여 그것을 보는 것보다 부하가 적은 자비에 있습니다.

실제 경험-한 번 방화벽 규칙을 엉망으로 만들었습니다 (포트를 특정 규칙 대신 임의의 포트로 남겨두고 서버는 취약한 서비스를 가졌습니다). 공격자는 실제로 원격 데스크톱 세션을 라이브 박스에했습니다. 세션을 시작할 때마다 공격자가 세션을 종료 / 연결 해제합니다. 독립 방화벽 장치에서 해당 공격을 차단할 수 없다면 훨씬 나빠질 수 있습니다.

독립적 인 모니터링

전용 방화벽 장치의 로깅은 일반적으로 호스트 기반 소프트웨어 방화벽보다 훨씬 우수합니다. 정확한 사진을 얻기 위해 외부 SNMP / NetFlow 모니터링 소프트웨어가 필요하지 않을 정도로 충분합니다.

IPv4 보존

하나는 웹용이고 다른 하나는 메일 용인 경우 두 개의 IP 주소를 가질 이유가 없습니다. 서비스를 별도의 상자에 보관하고 그렇게하도록 설계된 장치를 통해 포트를 적절하게 라우팅하십시오.

Blockquote 글쎄, 당신 말이 맞아요, 나는 거기에 어떤 단점도 넣지 않았습니다. 단점 : 네트워크 복잡성 증가, 단일 장애 지점, 대역폭 병목 현상이 발생하는 단일 네트워크 인터페이스. 마찬가지로 하나의 방화벽에서 발생하는 관리 실수로 인해 전체 네트워크가 중단 될 수 있습니다. 그리고 신들은 당신이 서버 룸으로 20 분 동안 여행하는 동안 자신을 잠그지 말 것을 금지했습니다.

첫째, 네트워크를 통해 최대 하나의 라우팅 된 홉을 추가하는 것은 복잡하지 않습니다. 둘째, 단일 장애 지점으로 구현 된 방화벽 솔루션이 전혀 쓸모가 없습니다. 중요한 서버 나 서비스를 클러스터링하고 본드 된 NIC를 사용하는 것처럼 고 가용성 방화벽을 구현합니다. 그렇게하지 않거나 인식하고 인식하지 못하는 것은 눈에 띄지 않습니다. 단일 인터페이스가 있다고 말하면 자동으로 병목 현상이 발생하지 않습니다. 이 어설 션은 네트워크를 통과하는 트래픽을 처리 할 수있는 크기의 방화벽을 올바르게 계획하고 배포하는 방법을 모른다는 것을 보여줍니다. 정책상의 실수가 전체 네트워크에 해를 끼칠 수 있다고 말하는 것은 맞지만 모든 서버에서 개별 정책을 유지 관리하는 것이 단일 장소보다 훨씬 오류가 발생한다고 주장합니다.

보안 패치를 따르고 보안 가이드를 따르십시오. 그것은 기이 한 논쟁이다. 일반적으로 보안 패치는 취약점이 발견 될 때까지 사용할 수 없습니다. 즉, 공개적으로 주소를 지정할 수있는 서버를 실행하는 동안에는 패치 될 때까지 취약합니다. 다른 사람들이 지적했듯이 IPS 시스템은 이러한 취약점으로 인한 타협을 방지 할 수 있습니다.

시스템이 최대한 안전하다고 생각한다면 좋은 확신입니다. 그러나 네트워크에서 전문 보안 감사를 수행하는 것이 좋습니다. 눈을 뜨고있을 수도 있습니다.

일반적으로 보안은 이미 언급했듯이 양파입니다. 방화벽이 존재하는 데는 이유가 있으며 다른 바보가 바보 같은 바보가 아닙니다.

이 페이지에서 'fail2ban'을 검색해도 아무런 결과가 나오지 않으므로이 답변이 제공됩니다. 따라서 다른 콘텐츠를 두 배로 늘리면 나와 함께하십시오. 실례합니다. 조금만 주면 다른 사람들에게 도움이 될 수 있으므로 분명한 경험을 제공합니다. :)

네트워킹 고려 사항, 로컬 및 외부

이것은 Linux에 국한된 것이며 호스트 기반 방화벽에 중점을 두는데, 이는 일반적으로 유스 케이스입니다. 외부 방화벽은 적절한 네트워크 구조와 함께 사용되며 일반적으로 다른 보안 고려 사항도 있습니다. 여기에 무엇이 내포되어 있는지 아는 경우이 게시물이 필요하지 않을 수 있습니다. 아니면, 읽지 말고 계속 읽으십시오.

방화벽을 외부 및 로컬로 실행하면 직관적이지 않고 이중 작업으로 보일 수 있습니다. 그러나 이것은 또한 다른 모든 호스트의 보안을 손상시키지 않으면 서 외부 규칙의 규칙을 바꿀 가능성을 제공합니다. 디버깅 이유나 누군가가 방금 잤기 때문에 필요할 수 있습니다. '어댑티브 글로벌 방화벽'섹션에 또 다른 유스 케이스가 있으며 글로벌 및 로컬 방화벽도 필요합니다.

비용과 가용성 및 항상 같은 이야기 :

방화벽은 적절한 보안 시스템의 한 측면 일뿐입니다. '비용'으로 방화벽을 설치하지 않고 SPOF를 도입하거나 헛소리가 들리면 내 프랑스어를 용서하십시오. 클러스터를 설정하기 만하면됩니다. 하지만 소방서에 정전이 발생하면 어떻게 될까요? 그런 다음 두 개 이상의 소방 실에 걸쳐 클러스터를 설정하십시오.

그러나 두 외부 사업자가 모두 사업을하지 않아서 전체 데이터 센터에 접근 할 수 없다면 (굴착기가 광섬유를 죽였습니다)? 그런 다음 클러스터를 여러 데이터 센터로 확장하십시오.

그건 비싸? 클러스터가 너무 복잡합니까? 편집증은 지불해야합니다

SPOF에 대해서만 징징하지만 더 많은 돈을 지불하거나 더 복잡한 설정을 만들고 싶지 않은 것은 회사 또는 고객 측의 이중 표준 또는 작은 지갑의 명확한 사례입니다.

이 패턴은 어떤 서비스가 현재의 문제인지에 관계없이 이러한 모든 토론에 적용됩니다. VPN 게이트웨이이든 상관없이 Cisco ASA는 방화벽, MySQL 또는 PostgreSQL 데이터베이스, 가상 시스템 또는 서버 하드웨어, 스토리지 백엔드, 스위치 / 라우터 등에 사용되었습니다.

이제 아이디어를 얻어야합니다.

왜 방화벽을 방해합니까?

이론적으로 당신의 추론은 건전합니다. (실행중인 서비스 만 이용할 수 있습니다.)

그러나 이것은 진실의 절반에 불과합니다. 방화벽, 특히 상태 저장 방화벽은 훨씬 더 많은 일을 할 수 있습니다. 상태 비 저장 방화벽은 이미 언급 한 다른 성능 문제가 발생하는 경우에만 중요합니다.

손쉬운 중앙 집중식 개별 액세스 제어

기본적으로 동일한 보안 기능을 구현하는 TCP 래퍼에 대해 언급했습니다. 논쟁을 위해 누군가가 tcpd마우스 사용을 모르고 좋아 한다고 가정 해 봅시다 . fwbuilder마음에 올 수 있습니다.

관리 네트워크에서 전체 액세스 권한을 갖는 것은 활성화해야하는 것으로 호스트 기반 방화벽의 첫 번째 사용 사례입니다.

데이터베이스가 다른 곳에서 실행되고 어떤 이유로 든 두 머신 / 모든 머신을 공유 (프라이빗) 서브넷 내에 둘 수없는 다중 서버 설정은 어떻습니까? 방화벽을 사용하면 다른 서버의 단일 IP 주소에 대해서만 포트 3306에서 MySQL 액세스를 허용 할 수 있습니다.

그리고 그것은 UDP에도 완벽하게 작동합니다. 또는 어떤 프로토콜이든. 방화벽은 매우 유연합니다. ;)

포트 스캔 완화

또한 방화벽을 사용하면 커널 및 해당 네트워킹 스택을 통해 시간 범위 당 연결 양을 모니터링 할 수 있고 방화벽이 그에 따라 작동 할 수 있으므로 일반적인 포트 캔을 감지하고 완화 할 수 있습니다.

또한 유효하지 않거나 모호한 패킷은 애플리케이션에 도달하기 전에 처리 될 수 있습니다.

아웃 바운드 트래픽 제한

아웃 바운드 트래픽 필터링은 일반적으로 엉덩이에 고통입니다. 그러나 계약에 따라 필수 일 수 있습니다.

통계

방화벽이 제공 할 수있는 또 다른 것은 통계입니다. ( watch -n1 -d iptables -vnxL INPUT패킷이 통과하고 있는지 확인하기 위해 맨 위에 특수 IP 주소에 대한 규칙을 추가했다고 생각하십시오.)

일이 잘되거나 효과가 없으면 평범한 일광에서 볼 수 있습니다. 연결 문제를 해결하고 다른 사람에게 전화를 걸지 않고 다른 사람에게 패킷을 얻지 못하도록 할 때 매우 유용합니다 tcpdump. 네트워킹은 재미 있고, 대부분의 사람들은 이제 자신이하는 일을 알고 있으며 종종 단순한 라우팅 오류 일뿐입니다. 지옥조차도 내가하는 일을 항상 알지는 못합니다. 문자 그대로 수십 개의 복잡한 시스템 및 어플라이언스를 다루었지만 지금은 종종 터널링을 사용하기도했습니다.

IDS / IPS

Layer7 방화벽은 올바르게 참석하지 않고 정기적으로 업데이트되는 경우 일반적으로 뱀 오일 (IPS / IDS)입니다. 또한 라이센스 비용이 많이 들기 때문에 돈으로 구입할 수있는 모든 것을 얻을 필요가 없다면 라이센스를 하나 더 확보 할 것입니다.

Masqerading

쉽게 래퍼로 시도하십시오. :디

로컬 포트 ​​포워딩

가장 무도회를 참조하십시오.

동적 IP 주소로 비밀번호 액세스 채널 보안

고객에게 동적 IP 주소가 있고 VPN 설정이 배포되지 않은 경우는 어떻습니까? 아니면 방화벽에 대한 다른 동적 접근 방법은 무엇입니까? 이것은 이미 질문에 암시되어 있으며 불행히도 유스 케이스가 올 것입니다. 안타깝게도 방화벽을 찾을 수 없습니다. 부품.

비밀번호를 통한 루트 계정 액세스를 비활성화해야합니다. 액세스가 특정 IP 주소로 제한 되더라도.

또한 ssh 키가 손실되거나 배포에 실패한 경우 암호 로그인을 사용하여 다른 Blanko 계정을 준비하는 것이 실제로 잘못되면 사용자에게 매우 유용합니다 (사용자는 컴퓨터에 대한 관리 액세스 권한이 있고 '일어남')? Linux에서 단일 사용자 모드를 사용하거나 로컬 액세스 init=/bin/bash를 grub위해 via 를 사용하는 것이 정말 나쁘고 어떤 이유로 든 라이브 디스크를 사용할 수 없기 때문에 네트워크 액세스와 동일한 아이디어입니다 . 웃지 마세요. 가상화 제품이 금지되어 있습니다. 기능이 존재하더라도 기능이없는 오래된 소프트웨어 버전을 실행하면 어떻게됩니까?

어쨌든 ssh 데몬을 22가 아닌 일부 포트에서 실행하더라도 포트 노킹과 같은 것을 구현하지 않은 경우 (다른 포트조차 열어 포트 포트를 완화하여 너무 비실용적 인 서라운드) 포트 스캔은 사용자를 감지합니다. 결국 서비스.

일반적으로 효율성을 위해 동일한 포트 및 서비스를 사용하여 동일한 구성으로 모든 서버를 설정합니다. 모든 머신에서 ssh를 다른 포트로 설정할 수는 없습니다. 또한 이미 '공개'정보로 간주 될 때마다 모든 시스템에서이 정보를 변경할 수는 없습니다. 이미 스캔 한 후에 있기 때문입니다. nmap합법적인지 아닌지에 대한 질문은 해킹 된 Wi-Fi 연결을 사용할 때 문제가되지 않습니다.

이 계정의 이름이 '루트'가 아니면 사람들이 '백도어'의 사용자 계정 이름을 추측하지 못할 수 있습니다. 그러나 그들은 회사에서 다른 서버를 얻거나 웹 공간을 사면 알 수 있습니다 /etc/passwd.

순전히 이론적 인 설명을 위해, 그들은 해킹 가능한 웹 사이트를 사용하여 서버에 액세스하고 일반적으로 귀하의 장소에서 물건이 어떻게 움직이는 지 찾아 볼 수 있습니다. 해킹 검색 도구는 연중 무휴 24 시간 실행되지 않을 수 있으며 (일반적으로 파일 시스템 검사의 디스크 성능상의 이유로 밤에 실행됩니까?) 바이러스 검사기는 새로운 제로 데이 가 하루를 밝게 보는 순간 업데이트되지 않으므로 이러한 상황을 한 번에 감지 할 수 없으며 다른 보호 조치가 없으면 어떤 일이 발생했는지조차 모를 수도 있습니다. 현실로 돌아 가기 위해 누군가가 제로 데이 익스플로잇에 액세스 할 수 있다면, 서버가 비싸기 때문에 서버를 대상으로하지 않을 가능성이 큽니다. 이것은 '필요한'이 발생하면 시스템에 항상 방법이 있음을 설명하기위한 것입니다.

그러나 다시 주제에 대해, 추가 암호 계정을 사용하지 말고 귀찮게하지 않습니까? 읽어주세요.

공격자가이 추가 계정의 이름과 포트를 가져 오더라도 8 자리 암호 만 사용하더라도 fail2ban+ iptables조합은 짧게 중지합니다. 또한 다른 서비스에도 fail2ban을 구현하여 모니터링 범위를 넓힐 수 있습니다!

필요한 경우 자체 서비스의 경우 : 기본적으로 파일에 대한 모든 서비스 로깅 실패는 파일 제공, 일치하는 정규식 및 허용되는 실패 수를 통해 fail2ban 지원을받을 수 있으며 방화벽은 모든 IP 주소를 행복하게 금지합니다. 들었다.

8 자리 비밀번호를 사용하라고 말하지 않습니다! 그러나 5 번의 잘못된 암호 시도로 24 시간 동안 금지 된 경우 보안이 철저한 경우에도 봇넷이없는 경우 얼마나 오래 시도해야하는지 추측 할 수 있습니다. 또한 고객이 아닌 고객이 사용하는 비밀번호에 놀라게 될 것입니다 ssh. Plesk 를 통해 사람들의 메일 암호를 살펴보면 알고 싶지 않은 모든 것을 알 수 있지만 물론 여기서 암시하지 않는 것은 무엇입니까? :)

적응 형 글로벌 방화벽

fail2ban의 라인을 따라 무언가를 사용하는 단 하나의 응용 프로그램 iptables -I <chain_name> 1 -s <IP> -j DROP이지만 Bash 마법을 사용하여 이러한 물건을 쉽게 만들 수 있습니다.

이와 같은 것을 확장하려면 추가 서버의 네트워크 서버에서 모든 fail2ban IP 주소를 집계하여 모든 목록을 관리하고 핵심 방화벽으로 전달하여 네트워크 에지에 이미있는 모든 트래픽을 차단합니다.

이러한 기능은 판매 할 수 없으며 (물론 가능하지만 취하기 쉬운 시스템 일뿐 아니라) 인프라에 직조되어야합니다.

그 동안, 당신은 또한 자신 또는 외부에 의해 집계 된 다른 소스의 블랙리스트 IP 주소 또는 목록을 사용할 수 있습니다.

실제 세계에서 사람들은 귀중품을 금고에 넣어서 확보합니다. 그러나 침입 할 수없는 금고는 없습니다. 금고 또는 보안 컨테이너는 출입을 강제하는 데 걸리는 시간에 따라 등급이 매겨집니다. 금고의 목적은 공격자가 탐지되고 활동적인 조치를 취한 다음 공격을 중지 할 수있을 정도로 오래 지연시키는 것입니다.

마찬가지로 적절한 보안 가정은 노출 된 시스템이 결국 손상 될 수 있다는 것입니다. 방화벽과 배스 천 호스트는 서버 (귀중한 데이터가있는)가 손상되는 것을 방지하기 위해 설정되지는 않지만 공격자가 먼저 서버를 손상시키고 귀중품이 손실되기 전에 공격을 탐지 (및 저지)하도록합니다.

방화벽이나 은행 금고는 내부자 위협으로부터 보호하지 않습니다. 이것이 은행 회계사들이 2 주 연속으로 떠나야하는 이유 중 하나이며 서버가 요새 호스트에 의해 보호 되더라도 내부 보안에 대한 철저한 예방 조치를 취해야합니다.

원래 게시물에서 방화벽을 통해 "외부"패킷을 서버로 직접 전달하고 있음을 나타냅니다. 이 경우, 방화벽은 그다지 많이 작동하지 않습니다. 외부에서 내부로 직접 논리적으로 연결되지 않는 두 개의 방화벽과 하나의 요새 호스트로 더 나은 경계 방어가 이루어집니다. 모든 연결은 DMZ 요새 호스트에서 종료됩니다. 모든 패킷은 전달하기 전에 적절하게 검사 (및 구문 분석 가능)합니다.

취약점을 예측하기가 어렵습니다. 인프라가 악용 될 방법을 예측하는 것은 사실상 불가능합니다. 침입자가 취약점을 악용하려는 방화벽을 "막아냅니다". 이는 취약점이 무엇인지 알기 전에 중요한 부분입니다. 또한 방화벽의 영향을 미리 쉽게 이해할 수 있으므로 피할 수있는 문제보다 더 심각한 방화벽의 문제를 일으킬 가능성이 거의 없습니다.

이것이 "방화벽 설치로 해고 된 사람이없는 이유"입니다. 이들의 구현은 위험이 매우 낮으며 악용을 방지하거나 완화 할 가능성이 높습니다. 또한 대부분의 불쾌한 취약점은 자동화에 의해 악용 될 수 있으므로 "비정상적인"항목은 봇을 손상 시키거나 최소한 더 쉬운 대상을 위해 사용자를 건너 뛰게합니다.

사이드 노트; 방화벽은 인터넷 전용이 아닙니다. 회계 부서 ldap 서버에 ssh / 무엇이든 필요하지 않으므로 서버에 제공하지 마십시오. 내부 서비스를 구획화하면 무언가가 성벽을 위반하는 경우 정리 작업에 큰 차이를 만들 수 있습니다.

Ernie는 서버를 강화하고 공격 및 취약성을 완화하기 위해 많은 노력을 기울이고 있지만 방화벽에 대한 귀하의 입장에는 동의하지 않습니다.

코어에 도달하기 전에 통과해야하는 계층이 있다는 점에서 보안을 양파처럼 취급합니다. 개인적으로 네트워크 경계에 어떤 형태의 하드웨어 방화벽이 없어야한다고 생각합니다.

나는 "내가 사용했던"각도에서 이것에오고 있다는 것을 인정할 것이지만, 매월마다 마이크로 소프트로부터 몇 달 동안 패치 패치를 얻을 수 있다는 것을 알고있다. . 나는 당신이 생각하고 싶은 거의 모든 OS와 응용 프로그램에 대해서도 마찬가지라고 생각합니다.

방화벽이이 문제를 해결하거나 버그 / 취약성에 영향을받지 않는 방화벽을 제안하지는 않습니다. 분명히 "하드웨어"방화벽은 하드웨어 스택에서 실행되는 소프트웨어 일뿐입니다.

즉, 웹에서 액세스 할 수있는 포트 443 만 필요한 서버가있는 경우 경계 주니퍼는 웹에서 포트 443 만 액세스 할 수 있다는 것을 알고 훨씬 안전합니다. 뿐만 아니라 Palo Alto는 들어오는 트래픽이 암호 해독, 검사, 기록 및 IPS / IDS 검색을 보장합니다. 서버를 안전하게 최신 상태로 유지할 필요가 없습니다. 그러나 제로 데이 익스플로잇과 오래된 인적 오류를 완화 할 수 있다는 이점이없는 이유는 무엇입니까?

우선, 포트 포워딩에 대한 당신의 이야기에 따르면, NAT와 방화벽을 접목시키고 있다고 생각합니다. 요즘 NAT는 사실상 방화벽의 역할을하는 경우가 많지만, 이것이 설계된 목적이 아닙니다. NAT는 라우팅 도구입니다. 방화벽은 액세스를 규제하기위한 것입니다. 이러한 개념을 명확하게 유지하는 것이 명확하게 생각하는 것이 중요합니다.

물론 서버를 NAT 상자 뒤에두고 NAT를 구성하여 해당 서버로 아무것도 전달하지 않는 것은 서버를 인터넷에 직접 배치하는 것보다 안전하지 않다는 것은 사실입니다. 나는 아무도 이것에 대해 논쟁하지 않을 것이라고 생각합니다.

마찬가지로 모든 트래픽을 허용하도록 구성된 방화벽은 방화벽이 아닙니다.

그러나 "모든 트래픽 허용"이 실제로 원하는 정책입니까? 누구든지 러시아 IP 주소에서 귀하의 서버로 ssh해야합니까? 새로운 실험용 네트워크 데몬의 구성에 관심을 가지고 있지만 전 세계에 실제로 액세스해야합니까?

방화벽의 장점은 방화벽이 열려 있어야하는 서비스 만 열어두고이 정책을 구현하기위한 단일 제어 지점을 유지할 수 있다는 것입니다.

상태 저장 패킷 검사 방화벽은 공용 서버 앞에 속하지 않습니다. 모든 연결을 수락하므로 상태 추적이 쓸모가 없습니다. 기존 방화벽은 DDoS 공격에 대한 큰 책임이며 일반적으로 링크 대역폭 또는 서버 리소스가 완전히 소비되기 전에 DDoS 공격에서 가장 먼저 실패하는 것입니다.

라우터의 상태 비 저장 패킷 필터는 퍼블릭 서버 앞에서 의미가 있지만 라우터의 하드웨어 ACL과 같은 모든 수신 및 송신 트래픽의 회선 속도를 처리 할 수있는 경우에만 가능합니다.

구글, 페이스 북, 심지어 마이크로 소프트조차도 전통적인 "방화벽"을 퍼블릭 서버 앞에 두지 않습니다. "둘 이상의 서버"규모로 공개 웹 서비스를 실행 한 사람은이 사실을 알고 있어야합니다.

Cisco ASA와 같은 기존 방화벽에서 발견되는 다른 기능 또는 호스트 자체에서 가장 잘 구현되는 기능으로 효과적으로 확장 할 수 있습니다. 로깅, IDS 등은 방화벽의 모든 소프트웨어 기능이므로 공개적으로 액세스 할 수있는 서버 앞에 놓으면 병목 현상이 발생하고 DDoS 대상이됩니다.

모든 서버에 공개 주소가 필요한 이유는 무엇입니까?

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

정기적으로 실행되는 14 개 정도의 서버 중 2 개만 공개적으로 액세스 가능한 인터페이스를 가지고 있습니다.

추가 편집 : 내가 관리하고있는 다른 네트워크에서는 방화벽을 관리 할 수있는 액세스 권한이 없었지만 마음대로 서비스를 켜고 끌 수있는 기능이있었습니다. 물론 실수로 SMTP (불필요한 서비스)가 켜졌다가 몇 번이고, 스팸 덤프가되어 프로세스에서 블랙리스트에 올라 오는 것을 막는 유일한 방법은 방화벽이었습니다.

또한 서버 사이를 통과하는 모든 트래픽이 완전히 암호화됩니까?

안전 벨트, 에어백 및 대머리 타이어없이 자동차를 100 마일로 운전할 수는 있지만 왜 그럴까요?

방화벽은 시스템 사용자가 관리자가 알지 못하거나 다른 컴퓨터로 포트를 전달하는 네트워크 액세스 가능 서비스를 열지 못하게 할 수 있습니다. 방화벽은 hashlimit 모듈을 사용하여 원격 IP를 기반으로 악용자를 평가할 수 있습니다.

방화벽은 정책을 준수하는 또 다른 안전망입니다. 물론, 예상치 못한 서비스를 실행하지 마십시오.

예를 들어 소프트웨어 업데이트를 적시에 적용 할 것을 권장하지만 모든 컴퓨터에서 방화벽을 권장합니다. 운전할 때와 같습니다. 물론 장애물과 다른 차량을 피하려고 노력하지만 예기치 않은 상황이 발생할 경우를 대비하여 안전 벨트를 착용하고 에어백을 착용하십시오.

다른 사람 이 방화벽을 사용하고 있기 때문에 방화벽의 혜택을 얼마나 누릴 수 있는지 모를 수도 있습니다. 문자 그대로 모든 사람, 홈 DSL 사용자까지 방화벽이 설치되어있는 날에는 포트 스니핑이 실현 가능한 공격 경로로 제외되었습니다. 괜찮은 해커는 그런 것들을 확인하는 데 시간을 낭비하지 않을 것입니다.