Alley가 메시지 사본을 보내드립니다. 송금에 관한 편지를 우편으로 받았습니다. 그게 무엇인가요? 해야 할 일
좋은 시간! 오늘은 스마트폰의 모든 메시지를 이메일로 보내는 SMS 백업에 대해 이야기하겠습니다. 이는 단순히 서신을 저장하고 메시지를 추가로 처리하기 위해 필요할 수 있습니다. 예를 들어 메시지에서 필요한 정보(연락처, 이름, 가격 등)를 검색하는 타사 애플리케이션을 사용하여 작업할 수 있습니다. 이메일. Android를 실행하는 스마트폰을 사용하여 이러한 복사 옵션을 살펴보겠습니다.
사서함 만들기
모든 메시지를 이메일로 보내고 저장하려면 먼저 사서함을 등록해야 하며, yandex.ru의 메일이 이에 적합합니다. 기존 메일함을 사용해도 되지만 새로 등록하는 것을 추천드립니다. 첫째, 시간이 지남에 따라 많은 양의 SMS 메시지가 누적되어 일반 편지 작업을 방해할 수 있으며, 둘째, 분석을 위해 사서함을 타사 서비스에 연결하는 경우 로그인 및 비밀번호를 표시하지 마십시오. 그 안에 있는 주요 이메일. .
Android 스마트폰에 SMS 백업 + 애플리케이션을 설치하세요.
모든 SMS 메시지를 사서함으로 보내려면 특별한 SMS 백업 + 애플리케이션을 설치하고 구성해야 합니다. 이 애플리케이션은 play.goole.com 또는 apk-dl.com(Google Play를 사용하지 않는 스마트폰의 대안)에서 다운로드할 수 있습니다. ) 또는.
이 애플리케이션은 Android 3.xx, 4.xx, 5.xx, 6.xx에서 테스트되었습니다. 버전 2.xx에 대한 지원이 선언되었습니다.
SMS 백업 설정 +
- 응용 프로그램을 실행하십시오.
- 응용 프로그램을 실행한 후 열리는 메뉴에서 고급 설정 항목을 선택합니다.
- 다음으로 백업 설정으로 이동합니다.
- SMS 백업 및 이메일 제목 접두사 확인란을 선택하고 MMS 백업, 통화 기록 백업 확인란을 선택 취소합니다(MMS 및 통화 기록은 백업할 수 있지만 필요하지 않습니다).
- 이전 메뉴로 돌아가서 IMAP 서버 설정 섹션으로 이동하세요.
- 인증 메뉴 항목을 선택하고,
매개변수 값을 일반 텍스트로 설정합니다. 
- 서버 주소 메뉴 항목을 선택하고 imap.yandex.ru:993 값을 입력합니다.
- 보안 메뉴 항목을 선택하고 SSL 값을 입력하십시오.
- 로그인(IMAP 계정) 메뉴 항목을 선택하고 로그인을 지정한 다음 비밀번호(IMAP 계정 비밀번호) 메뉴 항목을 선택하고 yandex.ru 메일의 비밀번호를 지정하세요.
- 메인 메뉴에서 자동 백업 확인란을 선택하세요.
- 그런 다음 자동 백업 설정으로 이동하여 정기 일정 메뉴 항목을 선택하고 지정된 사서함 계정으로 SMS가 전송되는 시간 간격(예: 2시간마다)을 설정합니다.
SMS 백업 + 애플리케이션을 사용하면 이메일에 백업 복사본을 만들 수 있을 뿐만 아니라 이메일에서 메시지를 복원할 수도 있습니다. 해당 복구 설정은 고급 설정 -> 설정 복원 섹션에서 찾을 수 있습니다.
이메일로 메시지를 보낸 후에는 모두 SMS라는 폴더에 저장됩니다.
이메일로 전송된 SMS 분석
귀하의 이메일 주소로 SMS 메시지 목록을 받은 후 특수 소프트웨어를 사용하여 포함된 데이터를 분석할 수 있습니다. 예를 들어 현금 영수증 및 차변에 대한 메시지가 포함된 은행의 SMS를 추적할 수 있으며 이를 기반으로 재무 기록을 자동으로 보관할 수 있습니다. 나는 "공동 쇼핑 사이트"에 대해 유사한 솔루션을 구현했습니다. JV 주최자가 수신한 은행의 모든 SMS 메시지가 한곳에 수집되어 분석되고 이를 기반으로 시스템은 어떤 사용자가 배치했는지에 대한 데이터를 제어판에 표시합니다. 주문이 결제되었습니다.
Thunderbird를 사용하여 이메일 주소를 지정하는 것은 어려운 작업이 아니지만, 다른 메일 프로그램과 약간의 차이점을 제외하고 여러 가지 방법으로 수행할 수 있습니다. Microsoft 제품에서 마이그레이션하는 사람들이 알아차린 가장 분명한 변화는 Thunderbird가 각 주소 상자에 하나의 수신자만 배치하여 수신자가 여러 명일 경우 여러 개의 주소 상자를 생성한다는 것입니다. 이는 메일이 수신자에게 표시되는 방식에 어떤 방식으로도 영향을 미치지 않습니다. 이는 Thunderbird 디자인 프로세스 초기에 이루어진 레이아웃 선택의 결과일 뿐입니다.
주소 필드
에게:이 이메일의 기본 수신자
참조:(카본 카피) 이 이메일의 보조 수신자입니다. 수신자는 받는 사람: 및 참조: 필드에 있는 이메일 주소를 볼 수 있습니다.
숨은참조:(숨은 참조) 이 필드의 주소에는 메일이 전송되지만 수신자는 숨은 참조: 필드에 누가 있었는지 알 수 없습니다. 즉, 숨은 참조: 필드에 있는 주소는 이메일을 받지만 받는 사람: 및 참조: 필드에 있는 주소는 알 수 없습니다. BCC: 필드에 누가 있었는지 알 수 없습니다.
받는 사람: 필드에 항목이 없고 숨은 참조 항목만 있는 경우 메일은 모든 숨은 참조 수신자에게 전송되며 해당 메일은 "미공개 수신자" 또는 이와 유사한 문구로 수신자에게 표시됩니다. 수신 이메일 프로그램.
Google 사용자를 위한 특별 참고사항
Google IMAP 메일 계정은 보낸 폴더에서 숨은 참조 목록의 이름을 제거합니다. 결과적으로 발신자는 – 즉 귀하는 누구에게 이메일을 숨겼는지에 대한 기록이 없습니다. 이메일에 숨은참조한 사람에 대한 기록이 필요한 경우 이메일을 보내기 전에 직접 수동으로 기록해야 합니다. 지메일만의 기능입니다.
주소록에서 항목 선택
Thunderbird는 목록에서 연락처를 마우스 오른쪽 버튼으로 클릭하면 쓰기 옵션을 제공합니다.
이는 하나의 메일만 보내려는 경우 유용하지만 메일을 보낼 사람이 여러 명인 경우에는 쓸모가 없습니다. 그러나 주소록에 있는 항목과 같이 목록에서 여러 항목을 선택할 수 있도록 운영 체제에서 지원하는 거의 사용되지 않는 키 조합이 있습니다.
을 누른 상태에서 Ctrl 키명령키를 사용하면 마우스 클릭당 하나씩 여러 항목을 선택할 수 있습니다. 이미 선택된 목록의 항목을 클릭하면 해당 항목이 선택 취소됩니다.
이 외에도 Shift 키를 사용할 수 있는 기능이 있습니다. Shift 키를 누르고 있으면 마우스 클릭 사이에 목록에 있는 모든 항목이 선택됩니다.
Shift와 Shift를 조합하여 사용 Ctrl 키명령동일한 작업에서 적절한 시간에 누른 키를 변경하면 선택한 목록을 미세 조정하면서 시간을 매우 효율적으로 사용할 수 있습니다.
연락처 창에서 항목 선택
쓰기, 전달 또는 회신을 클릭할 때마다 Thunderbird는 작성 창을 엽니다. 작성 창의 기능 중 하나는 주소록의 모든 항목을 볼 수 있는 연락처 사이드바 창이 포함되어 있다는 것입니다. 이 창은 F9 키를 사용하거나 구성 창의 보기 메뉴를 사용하여 켜고 끌 수 있습니다.
두 번 클릭하거나 창 하단에 있는 버튼을 사용하여 이 창에서 항목을 선택할 수 있습니다.
또는 마우스나 Ctrl 및 Shift 키를 사용하여 선택한 항목을 마우스 오른쪽 버튼으로 클릭한 다음 메뉴에서 대상을 선택합니다.
추가 옵션을 선택하면 메일 상단의 수신자 목록에 수신자당 한 줄씩 주소가 추가됩니다.
사이드바에서 단일 연락처 또는 여러 연락처 선택을 주소 지정 상자로 끌어서 놓을 수도 있습니다. 여기에 설명된 다른 방법과 달리 이 방법은 단일 주소 지정 상자에 여러 연락처를 삽입하지만 주소 지정 상자에 Enter를 입력하면 연락처가 수신자당 한 줄 형식으로 구문 분석된다는 점에 유의하세요.
마술사_로만"블라인드 카피"라는 개념으로, 어리석은 짓을 하지 않는 법을 배우는 것놀랍게도 많은 사람들이 한 번에 여러 사람에게 이메일을 보내야 할 때 단순히 "받는 사람" 필드에 주소를 나열합니다. 이 이메일이 동료나 친구에게 전달될 때는 일반적인 현상이지만 그룹에 편지를 보낼 때는 일반적입니다. 클라이언트의 경우 다른 수신자의 주소를 모든 사람에게 표시하여 본질적으로 주소 기반을 공개합니다.
귀하의 고객이 해야 할 일은 이 편지를 경쟁업체에 전달하는 것뿐입니다. 그러면 귀하의 연락처가 즉시 유출됩니다.
이상하지만 어리석은 사람들과는 거리가 먼 많은 사람들이 많은 수신자에게 서로에 대해 알지 못하도록 편지를 보내야 할 경우 이에 대한 "숨은 참조" 필드가 있다는 사실에 놀랐습니다.
예를 들어 mail.ru의 경우 다음과 같습니다.
다시 한 번 간략하게 설명합니다."받는 사람"에 주소가 표시되어 있습니다. 모든 사람은 "숨은 참조"로 표시된 편지를 누구에게 보냈는지 볼 수 있습니다. 모든 사람은 그 편지가 자신만을 위한 것이라고 생각합니다.
그리고 각 수신자는 "받는 사람" 필드에 다음과 같은 편지를 받게 됩니다. 그냥 그 사람 주소야 . 다른 프로그램의 경우 BCC 위치를 찾을 수 없으면 다른 사람에게 보여달라고 요청하세요. 또 다른 작은 점은 "받는 사람" 필드에 하나의 주소를 지정해야 한다는 것입니다. 대부분의 프로그램이나 메일 서버는 이 매개변수 없이는 편지를 보내는 것을 허용하지 않습니다.
따라서 고객 그룹에게 제안, 뉴스를 보낼 때 숨은 참조 사용 관행이 분명하므로 주소 기반을 숨겨야 합니다. 동료에게 편지를 보낼 때 흥미로운 점은 여기에서 상황에 따라 행동하는 것이 좋습니다. 예를 들어 제안(예: 고객 서비스 개선)을 보내라는 요청이 포함된 편지를 보내고 각 동료가 다른 것을 본 경우 사람들은 같은 편지를 받았지만 대부분 응답하지 않을 것입니다. 다른 사람에게 의존할 것이므로 숨겨진 사본을 사용해야 함을 의미합니다. 예를 들어, 이 명령이 수행되면 동료의 상사가 놀라운 일을 하게 될 것이며 귀하의 명령이 수행될 것임을 나타냅니다.
공급업체와는 별도의 문제입니다. 한편, 사본에 모든 수신자를 표시하면 공급업체에게 귀하에게 선택권이 있으며 공급업체는 귀하에게 좋은 가격을 제시해야 한다는 사실을 보여주어야 합니다. 반면에, 귀하의 편지를 받은 관리자는 그 편지가 자신에게만 전송된 것이 아니라는 것을 알고 귀하의 요청을 "차갑게" 처리할 가능성이 높습니다. 개인적으로 제 생각에는 공급업체의 경우 최소한 영업비밀을 보호하기 위해서라도 히든카피를 활용해야 하지만, 공급업체의 관리자와의 좋은 관계를 위해서는 더 가능성이 높다고 생각합니다.
모든 수신자가 다른 수신자를 본 전문가의 실수에 대한 최근 사례를 읽을 수 있습니다. 이 채팅의 모든 사람에게 충격을 주었고 거기에는 정말 존경받는 사람들, 즉 이사가 있었지만 여전히 많은 사람들이 응답으로 스팸을 받았습니다.
글쎄, 언제나 그렇듯이 댓글에서의 토론은 환영합니다.
최근에 나는 주기적으로 이런 메시지를 받고 있는데, 나에게서 그런 메시지가 어떤 곳에 전달되지는 않았지만 편지의 본문에는 링크 등을 포함하여 일종의 이단이 가득합니다. 다 괜찮을 텐데 그런 메시지를 보낸 적도 없고 내용도 처음 봤어요.
스푸핑이란 무엇이며 어떻게 작동합니까?
아래 텍스트는 에서 가져왔습니다.
귀하의 계정에서 메시지를 보낼 때 오류 메시지를 받거나, 스팸 폴더에서 귀하를 발신자로 나열한 메시지를 찾거나, 보내지 않은 메시지에 대한 답장을 받은 경우, 귀하는 스푸핑의 피해자일 수 있습니다. 스푸핑은 메시지의 실제 출처를 숨기기 위해 보내는 메일 반송 주소를 위조하는 것입니다.
우편으로 메시지를 보낼 때 일반적으로 반송 주소는 봉투에 표시됩니다. 이를 통해 수신자는 발신자의 신원을 확인할 수 있으며, 필요한 경우 우편 서비스는 발신자에게 편지를 반송할 수 있습니다. 그러나 발신자가 자신의 주소 대신 다른 사람의 주소를 표시하는 것을 막을 수는 없습니다. 이는 다른 사람이 편지를 보내고 봉투에 귀하의 반송 주소를 사용할 수 있음을 의미합니다. 이메일도 같은 방식으로 작동합니다. 서버가 이메일을 보낼 때 보낸 사람을 지정하지만 보낸 사람 필드가 스푸핑될 수 있습니다. 누군가가 메시지에 귀하의 주소를 잘못 입력한 경우, 배달 문제가 있는 경우 귀하가 메시지를 보내지 않았더라도 메시지가 귀하에게 반송됩니다.
귀하의 주소에서 전송되지 않은 이메일에 대한 응답을 받은 경우에는 두 가지 이유가 있을 수 있습니다.
- 편지는 위조되었으며 귀하의 주소가 보낸 사람의 주소로 기재되어 있었습니다.
- 실제 보낸 사람은 귀하의 반송 주소를 포함하였으므로 모든 답장은 귀하에게 전송됩니다.
이러한 옵션 중 어느 것도 다른 사람이 귀하의 계정에 액세스했음을 의미하지는 않지만 보안이 우려되는 경우 최근 액세스 기록을 확인할 수 있습니다. 받은편지함 페이지에서 아래로 스크롤하여 링크를 클릭하세요. 추가 정보줄 옆에.
후문
그러니 당황하지 마세요. 공격자들이 온갖 종류의 좌익 링크를 사용하여 갈고리 또는 사기꾼을 통해 우리를 다시 한 번 유인하려고 시도하고 있다는 것입니다. 물론 이러한 문자는 링크를 클릭하지 않으면 무시되고 삭제됩니다.
그건 그렇고, 당신은 그것을 결코 잊어서는 안됩니다.
추신: 경고 질문: "추가 정보" 및 "계정의 최근 작업" 주제 - 사서함에만 해당 지메일.
안녕하세요 하브르! 이 노트에서는 가짜 이메일(이메일 스푸핑, 위조 이메일)로부터 보호하는 주제를 다루기로 결정했습니다. 보낸 사람에 대한 정보가 위조된 편지에 대해 이야기하겠습니다. 수신자는 신뢰할 수 있는 사람이 보낸 것으로 추정되는 편지를 보게 되지만 실제로는 해당 편지는 공격자가 보낸 것입니다.
최근 우리는 고객뿐만 아니라 지인으로부터 위조 편지 문제에 대한 이야기를 점점 더 자주 듣고 있습니다. 이 문제는 관련성이 있을 뿐만 아니라 추진력을 얻고 있는 것 같습니다. 다음은 달러 기준으로 0 4개를 잃을 뻔한 친구의 실화입니다. 회사는 고가의 특수 장비 구입과 관련해 외국 회사와 영어로 서신을 주고받았습니다. 처음에는 친구 측에서 뉘앙스가 발생했습니다. 보낸 사람 (구매자 회사)의 계정 세부 정보를 변경해야했습니다. 얼마 후, 새로운 세부 사항에 대해 성공적으로 동의한 후 장비 공급업체에서도 수신자(판매사)의 계정 세부 정보를 변경해야 한다고 통보했습니다. 그러나 수신자의 데이터 변경에 대한 편지는 이미 발신자의 주소를 성공적으로 교체한 공격자가 보낸 것이었습니다. 양측이 통신 언어의 원어민이 아니라는 사실로 인해 악화된 일반적인 혼란을 배경으로 문자 대체를 알아차리는 것이 거의 불가능했습니다. 또한 공격자들은 편지의 스타일, 글꼴, 서명 및 사진을 부지런히 복사했다는 점에 유의해야 합니다. 거래에 대한 정보가 정확히 어떻게 유출되었는지 - 이메일 서신이 손상되었을 가능성이 높습니다. 이 기사에서 논의된 거래가 최종 승인되기 일주일 전에 트로이 목마가 포함된 편지가 *.exe 아카이브에 청구서 형태로 친구의 메일로 도착했습니다. 편지가 도착했을 때 바이러스 백신은 악성 코드를 포착하지 못했고 얼마 동안 컴퓨터에서 "작동"했으며 심지어 도움을 줄 동료 몇 명을 모집했습니다.
며칠 후 바이러스 백신 서명이 업데이트되고 악성 코드와 그 형제가 제거되었지만 그 무렵에는 이미 서신이 삽입되어 있고 보낸 사람이 위조되었으며 돈이 다른 사람의 계좌로 들어간 상태였습니다.
이 예에서는 보내는 사람의 주소가 매우 간단한 방식으로 대체되었습니다. 실제 주소를 공개하지는 않지만 비슷한 예를 들어보겠습니다.
올바른 보낸 사람 주소: [이메일 보호됨]
가짜 보낸 사람 주소: [이메일 보호됨].
공격자의 이메일 계정에는 이름 'best@bestofall'과 성 '.com'이 포함되어 있었습니다. 친구는 모바일 장치에서 서신의 일부를 수행했는데, 그 이메일 클라이언트는 보낸 사람 필드에 보낸 사람의 이름과 성만 표시했습니다. 그리고 모든 모바일 이메일 클라이언트가 이를 수행합니다. 따라서 이 이메일 클라이언트의 수신 편지는 best@bestofall “space”.com에서 온 것으로 표시되었습니다. 원본과 매우 유사합니다. 아래는 공격자가 보낸 편지이고 그 아래에는 Yandex.Mail 인터페이스의 합법적인 편지가 있습니다.
아웃룩에서는 공격자가 보낸 편지도 원본과 상당히 유사해 자세히 살펴보지 않으면 가짜인지조차 눈치채지 못할 수도 있습니다.
공급업체가 전화를 걸어 “마이 마니에서 나오나요?”라고 물었을 때 이 모든 사실이 밝혀졌습니다. 다행히 친구의 경우 원래 서명된 계약서에 대한 세부 정보(수취인 및 보낸 사람)가 이중으로 변경되어 $$$$$가 최종적으로 공격자의 계좌에 입금되지 않고 수취인 은행의 중계 계좌에 정체되었습니다. , 그리고 그들은 반환될 수 있었습니다.
전 세계 기업들은 이메일 공격으로 인해 막대한 손실을 입고 있습니다(). 따라서 2013년 10월부터 2015년 8월까지 전 세계 기업의 기업 이메일 침해로 인한 총 손실액은 미화 12억 달러에 이릅니다. 그리고 가짜 편지를 이용한 공격은 기업 이메일 시스템에 대한 가장 일반적인 공격 유형 중 하나입니다.
공격자가 회사 고위 임원을 대신해 가짜 이메일을 보내는 공격에 특히 주목된다. 편지 본문에서 공격자는 직원이나 회사 직원 그룹에게 즉각적인 응답 또는 긴급한 대응을 요구합니다. 예를 들어, 일부 기밀 정보를 보내 편지에 응답해야 할 수도 있습니다. 이는 데이터 유출로 이어질 수 있습니다. 또는 공격자가 긴급하게 거액의 은행 송금을 요구할 수도 있습니다. 설명된 시나리오에서 직원은 압박감을 느낍니다. 고위 관리자가 즉각적인 조치를 요구합니다. 이 사실은 공격이 성공할 가능성을 높입니다. 또한, 편지의 내용을 가장 효과적으로 구성하고 가짜 편지를 받을 직원의 대상 그룹을 가장 정확하게 식별하기 위해 사회 공학적 방법을 사용한 정찰이 공격에 선행될 수 있습니다. 이 접근 방식은 공격 성공에도 유익한 영향을 미칩니다.
보낸 사람의 주소를 위조하는 메커니즘을 이해하기 위해 SMTP 프로토콜을 통해 전송되는 이메일의 구조를 떠올려 보겠습니다. 이메일은 봉투, 헤더, 메시지 본문으로 구성됩니다. 보낸 사람에 대한 정보는 봉투에 포함되어 있습니다. 이 정보는 SMTP 명령의 메일에 의해 생성되며 MTA(메일 전송 에이전트) 메일 서버를 통과할 때 메시지 전달 프로세스에 직접적인 영향을 미칩니다. 그러나 보낸 사람에 대한 정보는 "From:", "Return-Path:", "Reply-To:"와 같은 일부 메시지 헤더에도 포함되어 있습니다. "보낸 사람:" 제목은 편지 봉투에 적힌 내용과 일치할 필요는 없으며 일종의 "친숙한 이름"(친숙한 이름, 보낸 사람)을 나타낼 수 있습니다. "Return-Path:" 헤더는 봉투에서 보낸 사람을 복사합니다. "Reply-To:" 헤더에는 답장 주소가 포함되어 있습니다. 헤더는 이메일 클라이언트(예: MS Outlook)에 중요하며 해당 필드는 헤더를 기반으로 채워집니다.
가짜 헤더 "From:" 및 "Reply-To:"가 포함된 편지를 보내는 SMTP 명령의 예를 살펴보겠습니다. 텔넷을 사용하여 Exchange 메일 서버에 연결합니다.
Telnet 10.1.2.3 25 220 Exchange Microsoft ESMTP MAIL 서비스 준비 완료, Wed, 26 Oct 2016 10:28:00 +0300 helo 250 Exchange Hello 메일 보낸 사람: [이메일 보호됨] 250 2.1.0 발신자 확인 수신자: [이메일 보호됨] 250 2.1.5 수신자 OK 데이터 354 메일 입력 시작; 다음으로 끝나다
이 예에서는 실제 주소에서 전송하고 있습니다. [이메일 보호됨]편지이지만 "보낸 사람:" 헤더에는 회사 대표의 이름과 주소가 표시되고 "답장" 헤더에는 부주의한 직원이 기밀 정보를 보내는 mail.yandex의 주소가 표시됩니다. 결과적으로 Outlook 이메일 클라이언트의 문자는 다음과 같습니다.
그리고 "답장"을 클릭하면 수신자의 주소가 자동으로 채워집니다.
이전 예에서 볼 수 있듯이 메일 서버가 보호되지 않으면 가짜 이메일을 보내는 것은 그리 어렵지 않습니다. 최악의 경우, 편지에서 보낸 우편물 봉투의 가치도 합법적인 가치로 대체될 수 있습니다. 이메일 본문을 신중하게 구성하고 사회 공학적 결과를 사용하면 최종 사용자가 가짜 이메일을 식별하는 것이 점점 더 어려워집니다. 모바일 기기 사용자의 상황은 더욱 심각하다. 이동성의 개념은 작은 세부 사항이나 불일치에 주의를 기울이지 않고 "이동 중에", 심지어 작은 화면에서도 모든 작업을 신속하게 수행한다고 가정합니다. 그런데 외국 기업과의 거래 예시에서 친구의 거래도 '이동성' 요소와 관련이 있었습니다. 서신의 일부는 모바일 장치에서 이루어졌으며 이메일 클라이언트는 보낸 사람 필드에 보낸 사람의 이름/성만 표시하고 전체 이메일 주소는 숨겼습니다.
스푸핑된 이메일을 처리하는 단일 방법은 없습니다. 이러한 유형의 공격으로부터 보호하려면 통합된 다단계 접근 방식이 필요합니다. 가짜 이메일을 퇴치하는 주요 접근 방식을 강조하겠습니다.
- 보내는 서버의 평판을 기준으로 필터링합니다.
- 송신 서버의 DNS 레코드 확인을 기반으로 필터링합니다.
- 편지 봉투에서 보낸 사람 도메인의 DNS 레코드를 확인하여 필터링합니다.
- SPF 기록 확인을 기반으로 필터링합니다.
- DKIM 기반 필터링.
- DMARC 기반 필터링.
- 세분화된 필터를 수동으로 생성합니다.
방법 4-6은 정확한 보낸 사람 스푸핑, 즉 공격자가 편지 헤더에서 기호까지 스푸핑된 보낸 사람을 나타내는 상황을 방지하는 데 도움이 됩니다.
기사 시작 부분에 있는 외국 회사와의 서신에 대한 예와 같이 편지의 헤더가 실제 보낸 사람과 유사하도록 수정되는 경우 방법 7을 사용해야 합니다. 그러나 동시에 스푸핑된 편지의 헤더는 실제 보낸 사람의 헤더와 여전히 다르기 때문에 방법 4-6을 사용하여 검사를 우회할 수 있습니다.
나열된 방법을 더 자세히 고려해 보겠습니다.
1. 보내는 서버의 평판을 기준으로 필터링합니다.기업 메일 보호 시스템이 고품질의 발신자 평판 데이터베이스를 제공한다면, 우리는 메일의 본문이나 봉투를 들여다보지 않고도 이미 TCP 세션을 설정하는 단계에 있는 모든 종류의 스팸 및 악성 서신 배포자의 상당 부분을 필터링할 수 있습니다. 편지. 이 접근 방식은 시스템 리소스를 크게 절약합니다. 발신자가 포트 25에서 TCP 세션 설정을 시도하자마자 보안 시스템은 발신자의 IP 주소에 대한 평판을 확인하고 결정을 내립니다.
시스코 ESA 예시. 평판 필터링.
Cisco ESA의 예를 사용하여 몇 가지 세부 사항을 설명합니다. 이 솔루션은 Sender Base 평판 데이터베이스를 사용합니다. 평판 필터링은 악성 이메일의 약 80%를 차단하는 데 도움이 됩니다. 또한, 이 솔루션을 구현하고 유지하는 데 수년간의 경험을 바탕으로 Cisco ESA 평판 필터링의 오탐률이 0인 경향이 있다고 말할 수 있습니다.
우리 조직을 요약하면 다음과 같습니다.
발신자의 평판에 따라 Cisco ESA는 편지를 폐기할지 아니면 더 건너뛸지를 결정할 뿐만 아니라 편지 처리를 위한 추가 시나리오도 결정합니다. 다양한 평판 값에 대해 다양한 정책을 적용할 수 있습니다.
2. 발신자의 서버 DNS 레코드 확인을 기반으로 필터링합니다.메일 메시지의 발신자가 DNS에 올바르게 등록되어 있어야 합니다. 발신자에게는 유효한 PTR 레코드와 A 레코드가 있어야 합니다. 보낸 사람은 SMTP HELO 명령에 올바르게 표시되어야 합니다. 대량 스팸 및 악성 코드를 보낼 때 공격자는 보내는 서버의 IP 주소를 지속적으로 변경합니다. 주소는 매일, 심지어 더 자주 변경됩니다. 필요한 레코드를 DNS에 등록하는 것은 어렵고 심지어 불가능합니다. 따라서 많은 스팸 및 악성 메시지 유포자들은 이러한 요구 사항을 무시하고 있으며, 이에 따라 DNS 기준에 따라 필터링이 가능해졌습니다.
시스코 ESA 예시. 발신자의 IP 주소에 대한 DNS 확인입니다.
Cisco ESA를 예로 들어 DNS 검사를 살펴보겠습니다. TCP 세션이 설정되면 보낸 사람에 대해 다음과 같은 DNS 확인이 수행됩니다.
- PTR 레코드가 있는지 확인합니다. PTR 레코드는 고유해야 하며 보낸 사람의 올바른 정식 호스트 이름을 반환해야 합니다.
- 첫 번째 단계에서 찾은 호스트 이름에 대한 A 레코드가 있는지 확인합니다(PTR 레코드 사용).
- 이전 단계의 A 레코드에 대한 정방향 DNS 조회가 보낸 사람의 IP 주소와 일치하는지 확인합니다.
이 확인 단계에서 ESA는 보낸 사람의 적법성을 제어하지 않는다는 사실, 즉 보낸 사람이 지정된 도메인에서 편지를 보낼 권리가 있는지 여부를 확인하지 않는다는 사실에 주목하고 싶습니다. 게다가 이 단계에서는 편지 봉투나 머리글도 보이지 않습니다. IP 주소로만 확인이 가능합니다. 예를 들어, mycompany.ru 도메인의 문자가 DNS에 올바른 A 및 PTR 레코드(예: "smtp.spamer.ru")가 있는 "왼쪽" IP 주소에서 온 경우 검사는 성공하고 문자는 다음과 같습니다. 추가 처리를 위해 건너뛰었습니다. 발신자의 적법성 확인은 다른 방법을 사용하여 수행됩니다(아래 SPF 레코드, DKIM, DMARC 참조).
3. 편지봉투에서 보낸 사람 도메인의 DNS 레코드를 확인하여 필터링합니다.보낸 메일의 정보에도 DNS 확인이 적용됩니다. 예를 들어 Cisco ESA를 사용하면 다음과 같은 경우 서신이 폐기될 수 있습니다.
- 보낸 사람의 도메인 정보가 봉투에 없습니다.
- 도메인 이름이 DNS에서 확인되지 않습니다.
- 도메인 이름이 DNS에 존재하지 않습니다.
4. SPF 기록 확인을 기반으로 필터링합니다. SPF – 보낸 사람 정책 프레임워크 – 전자 메시지의 보낸 사람을 확인하는 시스템입니다. "발신자의 서버 DNS 레코드"를 확인하는 방법 2는 발신자의 IP 주소에 필요한 DNS 레코드(PTR 및 A 레코드)가 존재함을 나타냅니다. 그러나 이러한 확인은 보내는 서버가 지정된 도메인에서 편지를 보낼 수 있는 권한이 있는지 확인하는 데 도움이 되지 않습니다. 메일 서버의 A 레코드에 회사 도메인 이름(예: smtp01.mycompany.ru)이 포함되는 경우가 많다는 점은 주목할 가치가 있습니다. 동일한 서버를 사용하여 메일을 수신하는 경우 동일한 A 레코드가 MX 레코드에도 포함됩니다. mycompany.ru에서 보낸 편지가 smtp01.mycompany.ru 서버에서 전송된 경우 이 편지는 가짜가 아니라고 가정할 수 있습니다. 그렇지 않고 smtp01.anythingelse.ru에서 보낸 편지는 가짜입니다. 그러나 실제로 회사는 메일 서버에서 직접 이메일을 보내는 것이 아니라 일부 추가 MTA 서버(예: 공급자의 서버)를 통해 이메일을 보내는 경우가 많습니다. 이 경우 mycompany.ru 도메인의 편지는 smtp01.provider.com, smtp02.provider.com 등과 같은 서버를 통해 전송됩니다. 발신자 서버의 정식 이름은 mycompany.ru 회사 도메인에 속하지 않습니다. 이 경우 수신자는 보내는 서버가 합법적인지 아닌지 어떻게 알 수 있습니까? 이 문제는 SPF 검사 시스템으로 해결됩니다.
문제는 DNS를 사용하여 다시 해결됩니다. 발신자의 도메인에 대해 특수 형식의 TXT 레코드가 게시됩니다. 이 TXT 레코드에는 서신을 보낼 수 있는 서버, 합법적인 발신자가 아닌 서버의 IP 주소, 서브넷 또는 A 레코드가 나열됩니다. SPF 시스템 덕분에 수신자는 DNS에 접속하여 편지를 보내는 서버를 신뢰할 수 있는지 또는 보내는 서버가 다른 사람을 사칭하려고 하는지 확인할 수 있습니다.
현재 모든 회사가 SPF 레코드를 생성하는 것은 아닙니다.
5. DKIM 기반 필터링. DKIM - DomainKeys Identified Mail - 전자 메시지 인증 기술입니다. mycompany.ru 회사가 공급자 MTA smtp01.mycompany.ru 및 smtp02.provider.com을 통해 외부로 서신을 보내는 SPF 레코드 고려 사례로 돌아가겠습니다. MTA에 대한 SPF 레코드가 있으므로 이러한 서버를 통해 전송된 mycompany.ru의 이메일은 성공적으로 확인됩니다. 그러나 MTA 데이터가 손상되어 공격자가 이러한 서버를 통해 스푸핑된 이메일을 보낼 수도 있다면 어떻게 될까요? 이 경우 발신자를 어떻게 인증하나요? 문자 인증이 구출됩니다.
인증에는 비대칭 암호화 및 해시 기능이 사용됩니다. 개인 키는 보내는 서버에만 알려져 있습니다. 공개 키는 DNS를 사용하여 특수 TXT 레코드에 다시 게시됩니다. 보내는 서버는 해시 함수를 사용하여 메시지 헤더의 지문을 생성하고 개인 키를 사용하여 서명합니다. 서명된 지문은 이메일의 "DKIM-Signature:" 헤더에 삽입됩니다. 이제 공개 키를 사용하여 편지 수신자는 해독된 지문을 얻고 이를 수신된 편지 필드의 지문과 비교할 수 있습니다(해시 함수가 알려져 있음). 지문이 일치하면 전송 중에 서명된 헤더가 변경되지 않았으며 "DKIM-Signature:" 헤더를 생성한 편지의 발신자가 합법적인 것입니다.
6. DMARC 기반 필터링. DMARC - 도메인 기반 메시지 인증, 보고 및 적합성은 SPF 및 DKIM 검사 결과를 어떻게 사용해야 하는지 정확하게 설명하는 기술 사양입니다. DMARC 정책은 TXT 레코드의 DNS를 사용하여 평소와 같이 게시됩니다. DMARC 정책은 SPF 및 DKIM 검사 결과에 따라 수신자 측에서 편지에 대해 정확히 수행해야 할 작업(배달, 폐기, 격리)을 지정합니다. 또한 DMARC는 발신자로부터 수신자에게 피드백을 제공합니다. 발신자는 자신의 도메인이 포함된 모든 이메일에 대한 보고서를 받을 수 있습니다. 정보에는 보내는 서버의 IP 주소, 메시지 수, DMARC 정책에 따른 결과, SPF 및 DKIM 검사 결과가 포함됩니다.
7. "수동으로" 세분화된 필터 만들기.안타깝게도 모든 조직에서 이메일을 보낼 때 SPF, DKIM, DMARC를 사용하는 것은 아닙니다. 또한 SPF, DKIM 및 DMARC 검사를 성공적으로 통과했지만 이메일이 여전히 위조된 것으로 판명되는 경우도 있습니다(사촌 도메인, 무료 이메일 계정). 이러한 경우에는 필터 설정이 도움이 됩니다. 필터링 규칙을 생성하는 다양한 시스템의 기능은 다양합니다. 필터는 다양한 공격 시나리오에 맞게 구성되며 회사의 특정 메일 시스템 구성에 따라 달라집니다. 예를 들어, 일부 회사에서는 동일한 회사의 발신 도메인을 사용하여 외부에서 편지가 올 수 있습니다. 대부분의 경우 이러한 편지는 조직 경계 내에서만 전송되어야 합니다.
우리는 Cisco ESA에 더 초점을 맞추고 있으므로 결론적으로 이 솔루션에 필터를 설정하는 몇 가지 예와 Cisco ESA용 소프트웨어 릴리스 10.0(2016년 6월)에 나타난 흥미로운 기능인 위조 이메일 탐지를 살펴보겠습니다. 이 기능을 사용하면 기사 시작 부분의 예와 같이 부정확한 가짜 발신자를 퇴치할 수 있습니다. 관심이 있으시면 태클에 오신 것을 환영합니다.
시스코 ESA 예시. 필터.
Cisco ESA는 콘텐츠 필터와 메시지 필터라는 두 가지 유형의 필터를 제공합니다. 전자는 GUI를 사용하여 구성되며 유한한(상당히 광범위하긴 하지만) 조건 및 작업 목록을 제공합니다. GUI의 예:
콘텐츠 필터가 필터에 속하는 문자의 조건을 설명하기에 충분하지 않은 경우 메시지 필터를 사용할 수 있습니다. 메시지 필터는 명령줄에서 구성되고, 정규식을 사용하여 조건을 설명하고, 복잡한 조건(예: If (((A 및 B)이고 C가 아님) 또는 D))을 생성할 수 있습니다. 메시지 필터는 콘텐츠 필터보다 먼저 이메일을 처리하고 보다 세부적인 규칙을 생성할 수 있도록 해줍니다.
공격에 대처하기 위한 여러 발신자 스푸핑 시나리오와 해당 Cisco ESA 필터를 살펴보겠습니다.
예시 1.보낸 사람의 조직 도메인이 포함된 편지는 외부에서 오면 안 됩니다. cisco.com에서 가져온 예: 링크. 이 예는 조직이 DNS에 SPF 및 도메인 키를 게시할 준비가 되지 않은 경우에 적합합니다. 이 예에서는 다음 메시지 필터를 사용합니다.
MarkPossicallySpoofedEmail: if ((recv-listener == "InboundMail") AND (subject != "\\(Possously Forged\\)$")) // 외부에서 이메일을 받았지만 아직 헤더에 표시되지 않은 경우, 이메일은 " 위조되었을 수 있습니다"( if (mail-from == "@yourdomain\\.com$") OR (header("From") == "(?i)@yourdomain\\.com") // 보낸 메일의 봉투에 조직의 도메인이 포함되어 있거나 보낸 사람 헤더에 조직의 도메인이 포함되어 있는 경우(strip-header("Subject"); insert-header("Subject", "$Subject (위조 가능)") ; ) ) // "위조" 헤더에 "위조 가능성" 항목을 추가합니다.
다른 옵션을 작업으로 선택할 수 있습니다: 검역소로 보내기, 편지 폐기 등.
예시 2.기사 시작 부분에서 편지 봉투의 우편물이 가짜가 아닌 경우의 예를 살펴 보았습니다. [이메일 보호됨]즉, 공격자가 자신의 올바른 주소를 작성했지만 From 헤더에는 가짜 주소( [이메일 보호됨]). 동시에 공격자가 spoofed.ru 도메인의 DNS에 SPF 및 도메인 키를 설정하는 것을 막을 수 있는 방법은 없습니다. 가짜 이메일은 SPF 및 DKIM 검사를 통과한다는 사실을 알게 되었습니다. 또한 공격자가 무료 메일(무료 메일 계정 - gmail.com, mail.ru 등)을 사용하는 경우 SPF 및 DKIM 검사가 성공적으로 통과됩니다.
메일 보낸 사람과 보낸 사람 헤더의 값이 동일한지 확인하여 이러한 상황을 해결할 수 있습니다. 즉시 예약할 가치가 있습니다. 일반적인 경우 RFC에서는 메일 보낸 사람이 보낸 사람과 동일할 것을 요구하지 않습니다. 따라서 이러한 필터는 일부 발신자에게만 적용해야 합니다.
현재 Cisco ESA(2016년 11월)에는 제한 사항이 있습니다. 필드 값을 서로 비교할 수 없습니다. 즉, 메일이 != 헤더(보낸 사람)인 경우 간단히 쓸 수 없습니다. 문제는 다른 방법으로 해결될 수 있습니다. 스푸핑에 취약한 발신자를 입력할 발신자 이름 사전인 Spoofed_senders를 만듭니다. 필터에서 조건을 설정합니다. 메일 보낸 사람에 사전의 보낸 사람이 포함되어 있지 않고 보낸 사람 헤더에 사전의 보낸 사람이 포함되어 있으면 작업을 수행합니다. 메시지를 격리하거나 삭제할 수 있지만 Cisco에서는 변조된 From 헤더 값을 새 X-Original-From 헤더에 쓰고 From 필드를 모두 제거할 것을 권장합니다. 이 경우 Cisco ESA는 메일 보낸 사람 값에서 보낸 사람 헤더를 자동으로 생성합니다. 이러한 필터의 예:
SpoofedSendersFilter: if (header-dictionary-match("Spoofed_Senders","From", 1)) AND (NOT (mail-from-dictionary-match("Spoofed_Senders", 1))) // 보낸 사람 필드에 이름이 포함된 경우 from the Dictionary , 그리고 mail from 값에는 사전의 이름이 포함되어 있지 않습니다( insert-header("X-Original-From", "$From"); Strip-header("From"); ) // Form the X-Original-From 헤더 및 From 헤더 삭제
예시 3.공격자는 발신자 주소와 유사한 주소, 즉 “사촌 도메인” 및 “사촌 주소”를 사용합니다. 예를 들어 주소 [이메일 보호됨]로 대체됩니다 [이메일 보호됨]. cbc.ru 도메인의 경우 SPF 및 도메인 키가 DNS에 생성되므로 편지는 적절한 SPF 및 DKIM 검사를 성공적으로 통과하고 편지 수신자는 친숙한 발신자를 보게 됩니다. 그러한 대체물에 맞서 싸우는 것이 더 어렵습니다. 이전 예의 Spoofed_senders 사전에 보낸 사람 이름과 도메인 이름의 유사한 변형을 모두 입력해야 하는데 이는 거의 불가능합니다.
이러한 유형의 발신자 스푸핑을 방지하기 위해 Cisco ESA는 AsyncOS 10.0(2016년 6월) 릴리스부터 흥미로운 "위조 이메일 탐지" 기능을 도입했습니다. 먼저, 이전 예에서와 같이 보낸 사람 이름 사전이 생성됩니다(예에서는 FED 사전의 이름이 사용됨). 여기에 스푸핑에 취약한 보낸 사람을 입력합니다. 이 사전은 사서함 이름이 아닌 보낸 사람의 이름으로 구성됩니다. 즉, 대신 Olivia Smith를 작성해야 합니다. [이메일 보호됨]. 위조된 이메일 탐지 시스템은 FED 사전에 있는 이름과 비교하여 보낸 사람 헤더를 확인하고 보낸 사람이 위조된 것으로 간주될 확률(1~100)을 제공합니다.
예를 들어 사전에 "John Simons"가 포함되어 있고 From 헤더에 "John Simons"가 포함되어 있는 경우 [이메일 보호됨], 시스템은 위조 확률 82를 표시합니다. From 헤더에 다음이 포함된 경우 [이메일 보호됨](즉, 이름은 같지만 도메인이 다른 경우) 시스템은 위조 확률을 100으로 부여합니다.
위조 이메일 탐지는 콘텐츠 필터 또는 메시지 필터를 통해 구성됩니다. 다음은 콘텐츠 필터 설정의 스크린샷입니다.
발신자가 위조된 것으로 간주하려면 사전 이름과 임계 확률 값을 지정해야 합니다. 이 조건에서는 사용 가능한 작업(폐기, 격리로 보내기, 편지 제목 수정 등)을 선택할 수 있습니다. 또한 위조 이메일 탐지를 위한 새로운 추가 작업이 있습니다. 즉, From 헤더 값을 from mail from 값으로 바꿉니다. 이 작업은 다음 옵션을 제공하지 않습니다.
결론
불행하게도 이메일에 대한 발신자 스푸핑 공격은 일상적인 현실입니다. 그리고 이런 종류의 성공적인 공격의 결과는 개인은 물론 공격을 받은 조직 전체에도 극도로 재앙이 될 수 있습니다. 상당한 물질적 손실과 기밀 정보 유출이 발생할 수 있습니다. 이 기사가 가짜 이메일을 사용한 공격의 구조와 방어 방법을 이해하는 데 도움이 되기를 바랍니다. 예제에서는 Cisco ESA 솔루션을 사용했지만 기사에 언급된 보호 도구는 다른 기업 이메일 보호 시스템에도 구현할 수 있습니다.
