효과적인 메일 서버 방어 구축 방법

이메일 통신 보안을 위한 다단계 접근 방식

메일 서버 관련 보안을 이야기할 때, 사람들은 일반적으로 메시지 적용 보안 조치, 특히 안티바이러스 및 안티스팸 보호로 문제를 제한하는 경향이 있습니다. 그러나 이는 서버 보안을 위한 더 복잡한 과정의 한 단계에 불과합니다. 이 기사는 특정 메일 서버를 선택할 때와 그에 따라 구성하고 사용할 때 매우 중요한 모든 보안 계층을 식별하고 설명하는 것을 목표로 합니다.

1. 메일 서버 연결 보안

새로 설치된 메일 서버를 사용할 때, 관리자는 먼저 안전한 연결을 사용하고 있는지 확인해야 합니다. 연결을 보호하는 두 가지 주요 방법은 암호화와 방화벽과 유사한 규칙입니다.

인터넷이 데이터 전송의 선호 매체가 됨에 따라 인코딩 방법이 지속적으로 개발되었습니다. 가장 일반적으로 사용되는 암호화 방법은 SSL (Secure Sockets Layer)와 TLS (Transport Layer Security)입니다. 그러나 암호화를 잘못 사용하면 보안 위반이 발생하는 경우가 많습니다. 가장 일반적인 예는 보안 및 비보안 정보를 모두 포함하는 웹 페이지 또는 일반 로그인 페이지를 통해 로그인한 후에만 보안이 적용되는 통신입니다.

방화벽과 유사한 규칙은 서버 수준에서 시행되어 기존 방화벽을 백업하거나 방화벽이 없는 경우 대체하는 것이 좋습니다. 이들은 설정된 연결과 호스팅된 트래픽 모두에 제한을 부과할 수 있습니다. 우리는 DOS (서비스 거부)와 같은 공격을 방지하기 위해 전 세계적으로 (모든 프로토콜 및 리스너에 적용) 및 각 리스너에 대해 특정적으로 허용/거부 규칙을 만드는 것을 권장합니다.

2. 메일 서버 프로토콜 보안

이메일 전송의 첫 번째 단계를 보안한 후, 다음으로 취해야 할 조치는 프로토콜을 보호하는 것입니다.

권장 단계는 각 인터페이스에 대해 다중 리스너를 사용하고 이를 특정 허용 및 거부 규칙과 연관시키는 것입니다. 또한 연결 및 인증 오류의 수를 제한하고, 최대 명령 수를 설정하거나 세션에 대한 시간 초과를 설정하는 것도 서버를 추가적인 DOS 공격으로부터 보호하는 데 도움이 될 수 있습니다.

프로토콜 보안을 더욱 강화하기 위해, 발신자 또는 수신자 주소를 기반으로 한 클라이언트 제어 규칙을 권장합니다. 또한 이메일 메시지의 수와 크기에 대한 특정 제한을 두는 것도 좋습니다.

인증은 프로토콜 수준에서도 매우 중요합니다. 여러 가지 인증 방법을 구현함으로써 (단순한 방법: 평문, 로그인, CRAM-MD5 또는 복잡한 방법: GSSAPI, Kerberos) 메일 서버는 통신 보안을 강화하고 공격 및 무단 접근에 더 잘 대비할 수 있습니다.

효율적인 프로토콜 수준 솔루션으로는 메일 서버가 RFC 준수를 보장하고 이메일 루핑을 방지하는 것이 있습니다 (매우 간단한 방법은 이메일당 최대 “수신” 헤더 수를 설정하는 것입니다).

3. 이메일 제어 매개변수 보안

다양한 안티스팸 및 안티바이러스 애플리케이션을 사용하는 것 외에도 이메일 제어 기반 보안과 관련하여 염두에 두어야 할 추가 조치가 있습니다. 매우 유용한 옵션 중 하나는 그레이 리스트를 사용하는 것입니다. 그레이 리스트는 기본적으로 이메일을 일시적으로 거부한 후 이메일을 재전송하도록 요청하는 것입니다. 서버는 발신자 IP와 수신자를 목록에 저장하고 임시 오류를 반환합니다. 모든 유효한 서버는 그런 다음 이메일을 재전송하며, 스팸 스크립트는 그렇지 않습니다. 그러나 많은 서버가 현재 임시 오류와 영구 오류를 구별할 수 없다는 점에 유의해야 합니다.

호스트 제어는 이메일 서버가 유효한 이메일만 추가로 처리하도록 보장하는 또 다른 간단한 방법입니다. 잘 알려진 두 가지 방법은 SPF (Sender Policy Framework)와 DNS 기반 블랙홀 목록입니다. SPF 레코드는 DNS 서버 내의 도메인에서 공개적으로 게시된 세부정보입니다. 일반적으로 이들은 도메인의 실제 주소를 가리키고 확인합니다. SPF 검사를 사용하면 스팸 및 백스캐터 이메일을 성공적으로 방지할 수 있습니다.

블랙리스트는 공개(무료) 또는 비공식적일 수 있으며 일반적으로 오픈 릴레이 서버, 오픈 프록시 및 스팸 필터링이 없는 ISP의 IP 주소를 포함합니다. 귀하의 서버는 이러한 목록을 요청하고 목록에 포함된 IP 주소에서 시작된 연결을 수락하지 않도록 설정되어야 합니다. 귀하의 서버 중 하나가 잘못 나열된 경우, 목록에서 제거되기 위해 온라인 양식을 작성하거나 목록 관리자에게 연락해야 하며, 더 심각한 상황에서는 IP를 변경해야 할 수도 있습니다.

더 복잡한 인증 방법은 DKIM (Domain Keys Identified Mail Signature)입니다. Yahoo에서 구현하고 Google, Cisco, Sendmail, PGP에서 지원하는 DKIM은 표준 인증 방법이 될 가능성이 큽니다. 이메일 헤더에는 암호화된 서명이 포함되어 있으며, 이는 다시 암호화되어 발신 도메인에서 DNS 서버에 게시된 암호화된 키를 가리킵니다. 이메일을 처리하는 서버는 이 키를 사용하여 이메일 본문을 디코딩합니다. 디코딩이 성공하면 이메일이 유효합니다.

릴레이 규칙은 때때로 보안 서버와 비보안 서버를 구분하는 차이를 만들 수 있습니다. 우리의 첫 번째 권장 사항은 오픈 릴레이를 절대 수락하지 않는 것입니다. 이는 쉽게 블랙리스트에 올라갈 수 있습니다. 따라서 발신자 주소/수신자 주소를 기반으로 하거나 인증된 사용자만을 위한 릴레이 규칙을 구현해야 합니다. 메일 서버를 선택할 때는 다음 기능이 있는지 확인해야 합니다: 릴레이 규칙 생성 허용, 도메인 인증 구성 가능, 발신 인터페이스 사용자 정의 가능, SSL/TSL 및 다양한 인증 방법 및 확장 지원.

4. 안전한 구성 및 관리

구성 및 관리는 일반적으로 보안 계층으로 간주되지 않습니다. 그러나 서버가 제공하는 구성 가능성 기능과 사용자가 실제로 수행한 구성은 MTA 보안에 중요한 역할을 합니다. 첫째, 관리자는 솔루션, 모든 기능 및 결함(있는 경우)에 익숙해져야 합니다. 서버 실행 파일은 메모리 누수 없이 프로그래밍을 지원하고 (유닉스 시스템에서만) 루트 권한을 드롭하며, 공개 파일에 대한 요청을 제외한 모든 접근 요청을 차단해야 합니다.

구성 파일에 대한 접근은 관리자에게만 부여되어야 합니다. 또한, 이 파일은 항상 매우 구체적이고 이해하기 쉽고 수정하기 쉬워야 하며, 모든 기본값은 안전해야 합니다. 예를 들어, 오픈 릴레이를 허용하는 기본값은 주요 보안 결함을 나타냅니다.

대체 관리 모듈 (웹 인터페이스, 명령줄 인터페이스)은 서버 구성을 수정하는 데 제공되어야 합니다. 이러한 모듈에 대한 모든 연결은 SSL을 통해 이루어져야 합니다. 이러한 모듈에 안전하게 접근하기 위해, 우리는 독점 HTTP 서버와 HTML 기반 스크립팅 언어를 갖춘 메일 서버를 사용하는 것을 권장합니다.

우리의 가장 완전한 보안 권장 사항은 “스마트 호스팅” 시스템을 구현하는 것입니다. 이러한 시스템은 서로 다른 머신에 설치된 여러 메일 서버로 구성되어 있으며, 각 서버는 특정 작업을 수행합니다. 최고의 연결 및 프로토콜 보안을 제공하는 서버는 방화벽 보호에 집중해야 합니다. 두 번째 서버는 이메일 제어 매개변수(안티스팸 및 안티바이러스 애플리케이션 포함)를 실행해야 합니다. 세 번째 서버는 주로 도메인 관리에 집중해야 합니다. 그러나 스마트 호스팅은 시스템 내에서 사용할 수 있는 하드웨어 및 소프트웨어 리소스보다 더 많은 리소스를 요구할 수 있습니다.

스마트 호스팅

결론

가장 중요한 점은 완벽한 보안은 없다는 것입니다. 따라서 최적의 보호가 완벽함을 대체해야 합니다. 각 보안 계층에서 가능한 결함과 위반이 존재합니다. 해결책은 가능한 최상의 구성을 선택하고 이를 네트워크의 요구와 토폴로지에 맞게 조정하는 것입니다.

추가 정보, 의견 및 질문이 있으시면 언제든지 AXIGEN 사이트를 방문하시거나 지원 팀에 연락해 주시기 바랍니다 ([email protected]).