일반적인 Email Security Appliance 오류 트러블슈팅

소개

이 문서에서는 Cisco ESA(Email Security Appliance)의 일반적인 컨피그레이션 오류에 대해 설명합니다.

환경

• 제품:Cisco ESA(Email Security Appliance)
• 소프트웨어:AsyncOS for ESA(버전은 구축에 따라 다름)
• 범위: 필요에 따라 이 지침을 인바운드 및 아웃바운드 메일 정책에 적용합니다. 변경하기 전에 각 섹션을 검토하십시오.

사전 요구 사항

• ESA에 대한 관리 액세스(GUI 또는 CLI)
• 검증을 위해 메일 로그 및 메시지 추적 검토 기능
• SBRS 기반 발신자 그룹을 사용하는 경우 Reputation Services SenderBase Reputation Score SBRS 활성화
• HAT(Host Access Table)가 메일 정책 평가 전에 연결 호스트를 분류하며, 이는 나중에 제어가 적용되는 방식에 영향을 미칩니다

일반 확인

• Monitor(모니터) > Overview and message tracking(개요 및 메시지 추적)을 사용하여 예상된 발신자 그룹 분류, 정책 일치, 변경 후 전달 결과를 확인합니다. 성공은 변경 후 예상되는 발신자 그룹, 정책 및 배달 결과가 나타남을 의미합니다.
• 평판 또는 필터링 설정을 강화한 후 7-144일 동안 격리 및 오탐을 모니터링하고 필요에 따라 알려진 비즈니스 파트너를 조정합니다.

ESA의 일반적인 컨피그레이션 오류)

이 검사를 사용하여 Email Security Appliance ESA의 일반적인 컨피그레이션 오류를 식별하고 수정합니다. 각 하위 섹션에서는 일관된 문제, 원인, 해결 방법 및 확인 패턴을 사용하므로 문제를 신속하게 진단하고 수정할 수 있습니다.

HAT(호스트 액세스 테이블)

증상

• 지나치게 허용적인 평판 기반 발신자 그룹으로 인해 스팸이 수락됩니다.
• 합법적인 메일은 지나치게 엄격한 연결 제어로 인해 제한되거나 차단됩니다.

원인

• 발신자 그룹이 부적절한 SBRS(SenderBase Reputation Score) 범위 또는 DNS(Domain Name System) 확인 설정으로 구성됩니다.

해결

1. 허용 목록에 양의 SBRS 값(예: +5 또는 +7)을 추가하지 마십시오. SBRS 기반 허용 목록의 경우 9.0~10.0의 점수만 사용하고 메시지 추적으로 검증합니다.
2. 필요한 경우에만 알 수 없는 발신자 목록 및 DNS 확인 기능을 구성합니다. 필요하지 않은 경우 UNKNOWNLIST, Envelope SenderDNS Verification, Connecting HostDNS Verification을 비활성화합니다.

3. 정책별 설정의 일관성을 방지하려면 전역 기본값을 구성합니다. mail Policies(메일 정책) > Mail Flow Policies(메일 플로우 정책) > Default Policy Parameters(기본 정책 매개변수)를 선택하고 메시지 크기 및 기타 기본 매개변수를 설정합니다.
4. 대부분의 발신자에 대해 적절한 기본 최대 연결 값(예: 3)을 설정하고 이를 새 메일 플로우 정책의 기본값으로 적용합니다. 필요에 따라 알려진 대량 발신자를 조정합니다.
5. 위험 허용 범위를 기반으로 차단 목록 SBRS 범위를 구성합니다. 대부분의 구축에서 SBRS를 -10.0에서 -2.0으로 차단하면 오탐률이 낮을 수 있습니다. 메시지 추적을 통해 검증하고 비즈니스 파트너를 조정합니다.

정책

증상/영향

• 기본 메일 정책이 아닌 메일 정책이 전역 기본값을 재정의하므로 예기치 않게 메일이 검사되거나 격리됩니다.
• 아웃바운드 메일은 불필요한 Anti-Spam/Outbreak Filter 작업을 트리거하여 처리 시간 및 오탐을 증가시킵니다.
• 감염된 첨부 파일은 제거되고 메시지 본문에는 제거된 내용만 포함되므로 메시지는 비어 있습니다.

원인

• 기본값이 아닌 정책은 특정 요구 사항 없이 기본 안티스팸, 안티바이러스, 콘텐츠 필터 또는 Outbreak Filter 설정을 복제하거나 재정의합니다.
• 아웃바운드 정책은 인바운드 중심 검사 기능을 적용합니다.

해결

1. 적용되는 수신자에 대한 이름 메일 정책(예: Inbound_Executives) 및 수행하는 작업에 대한 이름 콘텐츠 필터(예: Q_basic_attachments 및 Dspooferss)
2. 기본 정책이 아닌 정책의 경우, 문서화된 예외가 필요하지 않은 경우 Use Default Settings for Anti-Spam, Anti-Virus, Content Filters, and Outbreak Filters를 선택합니다.
3. Drop infected attachments(감염된 첨부 파일 삭제)의 확인란 선택을 취소하면 제거된 내용이 비어 있을 수 있는 메시지가 전달되지 않습니다.
4. 아웃바운드 Anti-Virus 작업의 경우 수신자 대신 발신자에게 알립니다.
5. 명시적인 아웃바운드 사용 사례가 없는 한 아웃바운드 메일 정책에서 Outbreak Filter 및 안티스팸을 비활성화합니다.

다음을 확인합니다.

• 메시지 추적을 사용하여 의도한 메일 정책이 일치하며 기본 검사 설정이 필요한 경우 상속되는지 확인합니다.
• 제어된 아웃바운드 테스트 메시지를 전송하고 Anti-Spam/Outbreak Filter가 예외로 구성되지 않는 한 적용되지 않는지 확인합니다.

수신 릴레이

증상

• 내부 메일 서버는 외부 발신자로 처리되어 예기치 않은 조절, 필터링 또는 평판 기반 작업을 유발할 수 있습니다.

원인

• 내부 메일 서버 IP 주소 또는 네트워크가 수신 릴레이로 구성되지 않았거나 수신 릴레이 기능이 비활성화되었습니다.
• 내부 릴레이 호스트는 전용 HAT 발신자 그룹에 분류되지 않으므로 의도하지 않은 연결 제한 또는 DHAP(Directory Harvest Attack Prevention) 동작이 발생할 수 있습니다.

해결

1. GUI에서 Mail Policies(메일 정책) > Incoming Relay(수신 릴레이)를 선택하고 내부 메일 서버 IP 주소 또는 네트워크를 추가합니다.
2. 수신 릴레이 기능이 활성화되어 있는지 확인합니다(테이블에 엔트리를 추가만 할 수 없음).
3. 보고용으로 이전 목록의 allow(허용) 목록에 나열된 내부 릴레이에 대한 전용 HAT(Host Access Table) 발신자 그룹을 생성합니다. 필요한 경우 안티스팸 및 안티바이러스 검사를 활성화한 상태로 유지하면서 속도 제한을 구성하지 않고 필요한 경우 DHAP(Directory Harvest Attack Prevention)를 구성하지 않습니다.DHAP는 SMTP(Simple Mail Transfer Protocol) 대화 중에 잘못된 수신자 열거 시도를 제한합니다.
4. 릴레이되지 않은 트래픽에 대한 평판을 기반으로 메일을 삭제하는 경우 필요한 경우 릴레이된 메일에 동등한 처리를 적용하는 메시지 필터를 추가합니다. 예:

Drop_Low_Reputation_Relayed_Mail:
if reputation <= -2.0
{ drop(); }

다음을 확인합니다.

• Monitor(모니터) > Overview(개요)에서 내부 서버가 더 이상 신뢰할 수 없는 외부 발신자로 표시되지 않는지 확인합니다.
• 메시지 추적/메일 로그에서 예상 발신자 그룹(예: 내부 릴레이 발신자 그룹)이 적용되는지 확인합니다.

DNS

증상

• DNS 확인자 선택 또는 분할: DNS 컨피그레이션으로 인해 전달 실패, 느린 SMTP 트랜잭션 또는 실패한 reputationDNS 기반 검사가 발생합니다.

환경

• 공용 DNS 확인, 내부 전용 DNS 확인 또는 내부 도메인 및 서비스에 대한 split-horizonDNS가 필요한 구축에 적용됩니다.

증상

• 메시지 추적은 MX, AAA, PTRR 또는 평판 관련 쿼리에 대한 DNSlookup 실패/시간 제한을 표시합니다.
• 반복된 DNS 재시도 때문에 메일 배달이 지연됩니다.

원인

• ESA는 필수 공개 레코드, 필수 내부 레코드 또는 둘 모두를 확인할 수 없는 리졸버를 사용하도록 구성되어 있습니다.
• 소스 네트워크를 기준으로 동일한 도메인에 대해 서로 다른 응답을 반환하는 Split-horizonDNS가 필요하지만 내부 도메인 또는 서비스에 대해서는 구현되지 않습니다.

해결

ESA에서 레코드를 확인하는 위치에 따라 DNS(Domain Name System) 확인을 구성합니다. 공용 인터넷, 내부 전용 도메인 또는 둘 다

1. ESA에서 기본적으로 공용 DNS 레코드를 필요로 하고 정책에서 허용하는 경우 공용 재귀 리졸버를 사용합니다.

2. ESA에서 내부 전용 영역, 내부 메일 교환 MXX(레코드), LDS(Lightweight Directory Access Protocol) 레코드 또는 기타 개인 서비스를 확인해야 하는 경우 internalDNS 또는 split-horizon DNS를 사용합니다.

3. 퍼블릭 DNS는 어플라이언스가 주로 인터넷 메일 레코드를 해결하고 내부 전용 영역 또는 정책 제한이 적용되지 않는 경우에 적합합니다.

필요한 경우 InternalDNS 또는 splitDNS 사용

• 내부 전용 도메인
• 내부 MXX 레코드
• Split-horizonDNS(소스 네트워크를 기준으로 동일한 도메인에 대해 서로 다른 응답)
• 규정 준수 또는 보안 정책에는 내부 재귀 리졸버가 필요합니다.
• 라우팅에 필요한 PrivateDNS 영역
• LDAP(Lightweight Directory Access Protocol)에 필요한 PrivateDNS 영역
• ESA에서 사용하는 내부 서비스에 필요한 PrivateDNS 영역

다음을 확인합니다.

• ESA에서 필요한 공용 및 내부 호스트 이름(해당되는 경우)을 확인할 수 있으며, 메일 전달 및 평판DNS 기반 검사가 메시지 추적에 성공했는지 확인합니다.

메시지 및 콘텐츠 필터

가장 일반적인 오류는 필터가 필요하지 않을 때 일치하는 조건을 추가하는 것입니다.

• 빈 조건: 지정된 메일 정책의 모든 메시지에 대해 필터를 실행해야 하는 경우 조건을 비워 둡니다.
• 평가 동작: asyncOS 메시지 필터에서는 빈 조건이 true로 평가되므로 필터가 해당 조건에 도달하는 모든 메시지에서 실행됩니다.
• 범위: 필터를 적절한 수신 또는 발신 메일 정책에 연결하여 범위를 제어합니다.
• 주문: 메시지 필터는 메시지 특성 및 작업을 순서대로 평가합니다. 콘텐츠 필터는 일반적으로 필터를 호출하는 메일 정책에 따라 범위가 지정됩니다.

예:

• 메시지 필터에서 rcpt-to 조건을 사용하는 것은 일반적으로 목표가 특정 사용자 또는 그룹을 대상으로 하는 경우 필요하지 않습니다. 수신자 기반 수신 메일 정책을 선호하며, 요구 사항이 수신자 또는 수신자 그룹에 완전히 매핑되는 경우 해당 정책에 콘텐츠 필터를 적용합니다. 정책 일치로 요구 사항을 표현할 수 없는 예외에 대해 rcpt-to 조건을 예약합니다.
• 첨부 파일을 삭제하기 전에 해당 첨부 파일이 있는지 테스트하는 것은 일반적으로 특정 첨부 파일 유형을 차단하려는 경우 중복됩니다. 대상 첨부 파일 유형을 직접 삭제하도록 필터를 구성합니다. 첨부 파일의 존재 여부에 따라 다른 작업이 필요한 경우에만 첨부 파일 존재 테스트를 사용하십시오.
• 메시지가 나머지 필터를 우회해야 하는 경우에만 deliver()를 사용합니다. deliver() 작업은 추가 필터 처리를 중지하고 메시지를 전달합니다. 나머지 필터를 건너뛰지 않고 메일을 전달하려면 명시적 deliver() 작업(암시적 전달 적용)을 구성하지 마십시오.

오픈 릴레이 방지

증상/영향

• 서드파티 릴레이 테스트는 어플라이언스가 형식이 잘못되었거나 위험한 수신자 주소를 수락한다고 보고합니다.
• Publicblocklists는 SMTP 주소 구문 분석을 통해 열린 릴레이의 유효성을 검사하는 데 일반적으로 사용되는 패턴을 사용할 수 있기 때문에 전송 IP를 나열합니다.

원인

• SMTP 주소 구문 분석 및 문자 처리에서는 도메인 이름 대신 주소에 직접 작성된 IP 주소인 잘못된 주소 형식(예: double @sign) 또는 주소 리터럴을 허용합니다.

해결

일부 서비스는 MTA(Message Transfer Agent)가 오픈 릴레이 조건을 나타낼 수 있는 잘못된 형식의 주소를 허용하는지 테스트합니다. ESA가 SMTP 대화 중에 이러한 주소를 거부하도록 엄격한 구문 분석 및 거부 동작을 구성합니다.

• 보고용 ALLOWLIST 앞에 릴레이 테스트 소스용 전용 HAT 발신자 그룹을 추가합니다. 필요한 경우 Anti-Spam(안티스팸) 및 Anti-Virus(안티바이러스)를 활성화한 상태로 유지하면서, 속도 제한 및 DHAP(Directory Harvest Attack Prevention)를 구성하지 않습니다.
• 주소에서 이중 @ 기호를 방지하기 위해 Strict Address Parsing(Loose)을 활성화합니다.
• 잘못된 형식의 주소를 허용하지 않도록 잘못된 문자를 거부(제거하지 않음)
• 주소 리터럴을 거부(허용 안 함)하고 다음 문자를 입력합니다. *%!\\/?

다음을 확인합니다.

• 외부 릴레이 테스트를 실행하고 ESA가 SMTP 대화 중에 잘못된 형식의 수신자 주소를 거부하는지 확인합니다.
• 메시지 추적을 사용하여 릴레이 테스트 발신자 그룹이 일치하는지, 그리고 의도한 검사 설정으로 메일이 처리되는지 확인합니다.

관련 정보

• 기술 지원 및 문서 받기
• AsyncOSS forESA 사용 설명서 검토
• ESA(Email Security Appliance) 설치 및 컨피그레이션 가이드(HAT, 메일 정책, 메시지 필터)

개정 이력

개정	게시 날짜	의견
3.0	01-Sep-2026	재인증.
1.0	13-Oct-2014	최초 릴리스