Countering Spam and Phishing– Cisco Security Tools
Social engineering through email, text messages, and private messages is the most common information technology attack.
Spam is any unwanted mail, including advertising, newsletters you did not ask for, and scams sent to thousands (or even millions) of users.
A phish is a targeted attack against an individual user, using information about the user to craft an email the user is more likely to respond to or act on.
Attackers often want you to
• Open an attachment that installs malware.
• Visit a website that installs malware.
• Give them account numbers (or other private information).
• Give someone access to your computer.
Each of these can have disastrous consequences for you and your organization. Learning how to guard against phishing attacks is a critical engineering skill and an important life skill.
This section explains how you can defend yourself against phishing attacks.
Each of these approaches is something you can also show family members, friends, and users to help them.
System-Level Defenses
Many elements of the email ecosystem work to block spam and phishing emails before they even arrive in your inbox. Figure 20-9 illustrates the many checks involved in sending and receiving email in a system supporting Domain-based Message Authentication, Reporting, and Conformance (DMARC ).
Figure 20-9 Security in the Email Ecosystem
Figure 20-9 begins with a user composing a mail in a client, usually an application running on a mobile device, host, or web page on a server running in the cloud. This client sends the mail to the sending server using Simple Mail Transfer Protocol. This server may also be called a mail transfer agent.
Simple Mail Transfer Protocol (SMTP ) is designed to transfer mail between two servers. The Internet Engineering Task Force (IETF) has extended SMTP to carry text, images, HTML, encrypted mail, etc., through Multipurpose Internet Mail Extensions (MIME).
A mail transfer agent (MTA) transfers email using SMTP.
Sending servers will almost always require the sender to log in to email. Forcing senders to log in prevents attackers from using a random email server to send a phishing email and makes most emails traceable to their originator. While requiring senders to log in to an email server blocked large amounts of spam, attackers have adapted their techniques by building and managing email servers and abusing free email systems.
The sending server creates a DomainKeys Identified Mail (DKIM ) header and attaches it to the mail. This DKIM header signs the sender’s email address, the receiver’s email address, the body of the message, the message’s subject, and other fields. This signature is encrypted using the sender’s private key.
The sending server looks up the receiver’s domain name, the part after the @ symbol in the email address, to discover the receiving server’s IP address. The sending server opens a connection to this IP address and uses SMTP to send the mail to the receiving server.
Most receiving servers will perform several initial checks before processing the mail, including
• Checking local IP blocklists for this sender.
• Checking the reputation of the sender’s domain name.
• Rate limiting mail from this sender.
• Searching for the sender’s IP address using a reverse DNS inaddr.arpa lookup; verifying the sender’s IP address is in the same domain as the sender’s address.
Once these basic checks are completed, the receiving server retrieves the sender’s public key using DNS. The receiving server calculates a signature, encrypts it using the sender’s public key, and compares this newly calculated encrypted signature with the signature included by the sender.
If these signatures do not match, the mail has been modified and should be discarded.
Another policy called the Sender Policy Framework (SPF) uses DNS. The SPF contains a list of valid email addresses in a domain. The mail should be discarded if the sender’s mail address is not in this list.
The receiving server then retrieves the sending domain’s policies, called the DMARC, and checks the email against these policies.
If the email passes these tests, the receiving server stores the mail for a client to retrieve later. The mail might also be marked as spam by the receiving server, in which case it will be quarantined. Users can normally release quarantined mail through a web interface.
Receiving mail servers will process local filters at this point.
These filters may include blocked senders, sorting mail into folders, etc. Most receiving servers will also process mail through a spam filter.
A spam filter searches mail for keywords, key phrases, attachments, suspicious links, suspicious Hypertext Markup Language (HTML), etc. Based on this search, a spam filter sets a spam score for each mail. If the spam score is high enough, the mail will be marked as spam and sorted into a special folder.
The next time the receiver’s mail client connects to the receiving server, it will retrieve any new mail. Mail clients use two protocols to retrieve email:
• Post Office Protocol v3 (POP3) physically copies mail from the server to the client. Mail retrieved by POP no longer exists on the server.
• Internet Message Access Protocol (IMAP) synchronizes the server’s folders with the client’s. Mail accessed through IMAP remains on the server so multiple clients can access and manage it.
Internet mail is a complex system with many security mechanisms built into every stage of transmitting mail from a sender to a receiver.