Zimbra 및 메일 폭탄 보호

메일 폭탄 공격은 가장 오래된 유형의 사이버 공격 중 하나입니다. 핵심은 일반 DoS 공격과 유사하지만 다른 IP 주소의 요청 물결 대신 이메일 물결이 서버로 전송되어 이메일 주소 중 하나에 대량으로 도착하므로 부하가 발생합니다. 그것에 크게 증가합니다. 이러한 공격으로 인해 사서함을 사용할 수 없게 될 수 있으며 때로는 전체 서버에 장애가 발생할 수도 있습니다. 이러한 유형의 사이버 공격은 오랜 역사를 통해 시스템 관리자에게 긍정적인 결과와 부정적인 결과를 가져왔습니다. 긍정적인 요인으로는 메일 폭탄 공격에 대한 지식이 풍부하고 그러한 공격으로부터 자신을 보호할 수 있는 간단한 방법이 있다는 점 등이 있습니다. 부정적인 요인에는 이러한 유형의 공격을 수행하기 위해 공개적으로 사용 가능한 수많은 소프트웨어 솔루션과 공격자가 탐지로부터 자신을 안정적으로 보호할 수 있는 능력이 포함됩니다.

이번 사이버 공격의 중요한 특징은 영리 목적으로 활용하는 것이 거의 불가능하다는 점이다. 글쎄, 공격자는 사서함 중 하나로 이메일을 대량으로 보냈습니다. 글쎄, 그는 그 사람이 이메일을 정상적으로 사용하도록 허용하지 않았습니다. 공격자는 누군가의 회사 이메일을 해킹하여 GAL 전체에 수천 통의 편지를 대량으로 보내기 시작했습니다. 서버가 충돌하거나 속도가 느려져서 사용할 수 없게 된 이유는 무엇이며 그 다음은 무엇입니까? 그러한 사이버 범죄를 실제 돈으로 전환하는 것은 거의 불가능합니다. 따라서 단순히 메일 폭격은 현재 매우 드물게 발생하며 시스템 관리자는 인프라를 설계할 때 그러한 사이버 공격으로부터 보호해야 할 필요성을 기억하지 못할 수도 있습니다.

그러나 이메일 폭격 자체는 상업적인 관점에서 볼 때 상당히 무의미한 활동이지만, 이는 종종 더 복잡하고 다단계인 다른 사이버 공격의 일부입니다. 예를 들어, 메일을 해킹하고 이를 사용하여 일부 공공 서비스의 계정을 탈취할 때 공격자는 확인 편지가 스트림에서 손실되어 눈에 띄지 않도록 의미 없는 문자로 피해자의 메일함을 "폭탄"시키는 경우가 많습니다. 메일 폭탄 공격은 기업에 대한 경제적 압력을 가하는 수단으로도 사용될 수 있습니다. 따라서 고객의 요청을 받는 기업의 공용 사서함을 적극적으로 공격하면 작업이 심각하게 복잡해질 수 있으며 결과적으로 장비 가동 중지 시간, 미완료 주문, 평판 손실 및 이익 손실로 이어질 수 있습니다.

그렇기 때문에 시스템 관리자는 이메일 폭격 가능성을 잊지 말고 항상 이러한 위협으로부터 보호하기 위해 필요한 조치를 취해야 합니다. 이것이 메일 인프라 구축 단계에서 수행될 수 있다는 점과 시스템 관리자의 시간과 노력이 거의 소요되지 않는다는 점을 고려하면 인프라에 메일 폭격으로부터 보호를 제공하지 않을 객관적인 이유가 없습니다. Zimbra Collaboration Suite Open-Source Edition에서 이러한 사이버 공격에 대한 보호가 어떻게 구현되는지 살펴보겠습니다.

Zimbra는 현재 사용할 수 있는 가장 안정적이고 기능적인 오픈 소스 메일 전송 에이전트 중 하나인 Postfix를 기반으로 합니다. 개방성의 주요 장점 중 하나는 기능을 확장하기 위해 다양한 타사 솔루션을 지원한다는 것입니다. 특히 Postfix는 메일 서버 사이버 보안을 보장하는 고급 유틸리티인 cbpolicyd를 완벽하게 지원합니다. 스팸 방지 보호와 화이트리스트, 블랙리스트, 그레이리스트 생성 외에도 cbpolicyd를 사용하면 Zimbra 관리자는 SPF 서명 확인을 구성하고 이메일이나 데이터 수신 및 전송에 대한 제한을 설정할 수 있습니다. 스팸 및 피싱 이메일에 대한 안정적인 보호를 제공하고 이메일 폭격으로부터 서버를 보호할 수 있습니다.

시스템 관리자에게 가장 먼저 요구되는 작업은 인프라 MTA 서버의 Zimbra Collaboration Suite OSE에 사전 설치된 cbpolicyd 모듈을 활성화하는 것입니다. 이는 zmprov ms `zmhostname` +zimbraServiceEnabled cbpolicyd 명령을 사용하여 수행됩니다. 그런 다음 cbpolicyd를 편안하게 관리하려면 웹 인터페이스를 활성화해야 합니다. 이렇게 하려면 웹 포트 번호 7780에서 연결을 허용하고 다음 명령을 사용하여 심볼릭 링크를 생성해야 합니다. ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webui, nano 명령을 사용하여 설정 파일을 편집합니다. /opt/zimbra/data/httpd/htdocs/webui/includes/config.php, 여기서 다음 줄을 작성해야 합니다.

$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$DB_USER="루트";
$DB_TABLE_PREFIX="";

그 후에 남은 것은 zmcontrol restart 및 zmapachectl restart 명령을 사용하여 Zimbra 및 Zimbra Apache 서비스를 다시 시작하는 것입니다. 그 후에는 웹 인터페이스에 액세스할 수 있습니다. example.com:7780/webui/index.php. 주요 차이점은 이 웹 인터페이스의 입구가 아직 어떤 방식으로든 보호되지 않았으며 승인되지 않은 사람이 들어가는 것을 방지하기 위해 웹 인터페이스에 들어갈 때마다 포트 7780의 연결을 닫으면 된다는 것입니다.

cbpolicyd 덕분에 설정할 수 있는 이메일 전송 할당량을 사용하여 내부 네트워크에서 들어오는 이메일의 홍수로부터 자신을 보호할 수 있습니다. 이러한 할당량을 사용하면 한 시간 단위로 하나의 사서함에서 보낼 수 있는 최대 편지 수에 대한 제한을 설정할 수 있습니다. 예를 들어 비즈니스 관리자가 시간당 평균 60~80개의 이메일을 보내는 경우 작은 마진을 고려하여 시간당 100개의 이메일 할당량을 설정할 수 있습니다. 이 할당량에 도달하려면 관리자는 36초마다 하나의 이메일을 보내야 합니다. 한편으로는 이는 완전히 작동하기에 충분하며, 다른 한편으로는 이러한 할당량을 사용하면 관리자 중 한 명의 메일에 액세스할 수 있는 공격자가 메일 폭탄 공격이나 기업에 대한 대규모 스팸 공격을 시작하지 않습니다.

이러한 할당량을 설정하려면 웹 인터페이스에서 새 이메일 전송 제한 정책을 생성하고 해당 정책이 도메인 내에서 전송된 편지와 외부 주소로 전송된 편지 모두에 적용되도록 지정해야 합니다. 이는 다음과 같이 수행됩니다.

그런 다음 편지 보내기와 관련된 제한 사항을 더 자세히 지정할 수 있습니다. 특히 제한 사항이 업데이트되는 시간 간격과 제한을 초과한 사용자가 받게 될 메시지를 설정할 수 있습니다. 그런 다음 편지 전송 제한을 설정할 수 있습니다. 보내는 문자 수와 전송된 정보의 바이트 수로 설정할 수 있습니다. 동시에, 지정된 한도를 초과하여 발송된 편지는 다르게 처리되어야 합니다. 예를 들어, 간단히 즉시 삭제할 수도 있고, 메시지 전송 제한이 업데이트된 후 즉시 전송되도록 저장할 수도 있습니다. 두 번째 옵션은 직원이 이메일을 보낼 때 최적의 제한 값을 결정할 때 사용할 수 있습니다.

편지 보내기에 대한 제한 외에도 cbpolicyd를 사용하면 편지 수신에 대한 제한을 설정할 수 있습니다. 언뜻보기에 이러한 제한은 메일 폭탄으로부터 보호하기 위한 훌륭한 솔루션이지만 실제로 큰 제한을 설정하면 특정 조건에서 중요한 편지가 도착하지 못할 수 있다는 사실이 내포되어 있습니다. 그렇기 때문에 수신 메일에 대한 제한을 활성화하지 않는 것이 좋습니다. 그러나 여전히 위험을 감수하기로 결정한 경우 수신 메시지 제한 설정에 특별한 주의를 기울여야 합니다. 예를 들어, 신뢰할 수 있는 상대방으로부터 수신되는 이메일 수를 제한하여 해당 상대방의 메일 서버가 손상되더라도 귀하의 비즈니스에 스팸 공격이 시작되지 않도록 할 수 있습니다.

메일 폭격 중에 들어오는 메시지의 유입을 방지하기 위해 시스템 관리자는 단순히 들어오는 메일을 제한하는 것보다 더 영리한 조치를 취해야 합니다. 이 솔루션은 그레이리스트를 사용하는 것일 수 있습니다. 작동 원리는 신뢰할 수 없는 발신자로부터 메시지를 처음 전달하려고 시도할 때 서버 연결이 갑자기 중단되어 편지 전달이 실패하는 것입니다. 그러나 일정 기간 신뢰할 수 없는 서버가 동일한 편지를 다시 보내려고 시도하면 서버는 연결을 끊지 않고 배달에 성공합니다.

이러한 모든 작업의 ​​요점은 대량 이메일을 자동으로 보내는 프로그램은 일반적으로 보낸 메시지의 전달 성공을 확인하지 않고 두 번째로 보내려고 시도하지 않는 반면, 사람은 자신의 편지가 다음으로 전송되었는지 확실히 확인한다는 것입니다. 주소인지 아닌지.

cbpolicyd 웹 인터페이스에서 그레이리스팅을 활성화할 수도 있습니다. 모든 것이 작동하려면 서버의 사용자에게 수신되는 모든 편지를 포함하는 정책을 생성한 다음 이 정책에 따라 그레이리스팅 규칙을 생성해야 합니다. 여기서 cbpolicyd가 대기하는 간격을 구성할 수 있습니다. 모르는 사람의 발신자로부터 반복 응답을 받으려면. 보통 4~5분 입니다. 동시에, 다른 보낸 사람이 보낸 편지를 전달하려는 모든 성공 및 실패 시도를 고려하고 해당 번호에 따라 보낸 사람을 화이트 목록 또는 블랙 목록에 자동으로 추가하도록 결정되도록 그레이 목록을 구성할 수 있습니다.

그레이리스트의 사용은 최대한의 책임을 가지고 이루어져야 한다는 사실에 주목해 주시기 바랍니다. 기업에 정말 중요한 이메일이 손실될 가능성을 제거하기 위해 이 기술을 화이트리스트와 블랙리스트의 지속적인 유지 관리와 함께 사용한다면 가장 좋을 것입니다.

또한 SPF, DMARC 및 DKIM 검사를 추가하면 이메일 폭격으로부터 보호하는 데 도움이 될 수 있습니다. 우편 폭탄 공격을 통해 도착하는 편지는 이러한 검사를 통과하지 못하는 경우가 많습니다. 이를 수행하는 방법이 논의되었습니다. 이전 기사 중 하나에서.

따라서 이메일 폭격과 같은 위협으로부터 자신을 보호하는 것은 매우 간단하며 기업을 위한 Zimbra 인프라 구축 단계에서도 이를 수행할 수 있습니다. 그러나 그러한 보호 기능 사용에 따른 위험이 귀하가 받는 혜택을 초과하지 않도록 지속적으로 확인하는 것이 중요합니다.

출처 : habr.com