Tag Archives: spf

Amazon SES Now Supports DMARC Validation and Reporting for Incoming Email

Post Syndicated from Nic Webb original https://aws.amazon.com/blogs/ses/amazon-ses-now-supports-dmarc-validation-and-reporting-for-incoming-email/

Amazon SES now adds DMARC verdicts to incoming emails, and publishes aggregate DMARC reports to domain owners. These two new features will help combat email spoofing and phishing, making the email ecosystem a safer and more secure place.

What is DMARC?

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. The DMARC standard was designed to prevent malicious actors from sending messages that appear to be from legitimate senders. Domain owners can tell email receivers how to handle unauthenticated messages that appear to be from their domains. The DMARC standard also specifies certain reports that email senders and receivers send to each other. The cooperative nature of this reporting process helps improve the email authentication infrastructure.

How does Amazon SES Implement DMARC?

When you receive an email message through Amazon SES, the headers of that message will include a DMARC policy verdict alongside the DKIM and SPF verdicts (both of which are already present). This additional information helps you verify the authenticity of all email messages you receive.

Messages you receive through Amazon SES will contain one of the following DMARC verdicts:

  • PASS – The message passed DMARC authentication.
  • FAIL – The message failed DMARC authentication.
  • GRAY – The sending domain does not have a DMARC policy.
  • PROCESSING_FAILED – An issue occurred that prevented Amazon SES from providing a DMARC verdict.

If the DMARC verdict is FAIL, Amazon SES will also provide information about the sending domain’s DMARC settings. In this situation, you will see one of the following verdicts:

  • NONE – The owner of the sending domain requests that no specific action be taken on messages that fail DMARC authentication.
  • QUARANTINE – The owner of the sending domain requests that messages that fail DMARC authentication be treated by receivers as suspicious.
  • REJECT – The owner of the sending domain requests that messages that fail DMARC authentication be rejected.

In addition to publishing the DMARC verdict on each incoming message, Amazon SES now sends DMARC aggregate reports to domain owners. These reports help domain owners identify systemic authentication failures, and avoid potential domain spoofing attacks.

Note: Domain owners only receive aggregate information about emails that do not pass DMARC authentication. These reports, known as RUA reports, only include information about the IP addresses that send unauthenticated emails to you. These reports do not include information about legitimate email senders.

How do I configure DMARC?

As is the case with SPF and DKIM, domain owners must publish their DMARC policies as DNS records for their domains. For more information about setting up DMARC, see Complying with DMARC Using Amazon SES in the Amazon SES Developer Guide.

DMARC reporting is now available in the following AWS Regions: US West (Oregon), US East (N. Virginia), and EU (Ireland). You can find more information about the dmarcVerdict and dmarcPolicy objects in the Amazon SES Developer Guide. The Developer Guide also includes a sample Lambda function that you can use to bounce incoming emails that fail DMARC authentication.

The Linux Foundation picks up FRRouting

Post Syndicated from corbet original https://lwn.net/Articles/718859/rss

The Linux Foundation has announced
that the FRRouting project has come under the LF umbrella.
FRRouting (FRR) is an IP routing protocol suite for Unix and Linux
platforms which includes protocol daemons for BGP, IS-IS, LDP, OSPF, PIM,
and RIP, and the community is working to make this the best routing
protocol stack available. FRR is rooted in the Quagga project and includes
the fundamentals that made Quagga so popular as well as a ton of recent
enhancements that greatly improve on that foundation.
” It is a fork
of Quagga that originally went
under the name “Cumulus private Quagga”.

Some notes on today’s DNS DDoS

Post Syndicated from Robert Graham original http://blog.erratasec.com/2016/10/some-notes-on-todays-dns-ddos.html

Some notes on today’s DNS outages due to DDoS.

We lack details. As a techy, I want to know the composition of the traffic. Is it blindly overflowing incoming links with junk traffic? Or is it cleverly sending valid DNS requests, overloading the ability of servers to respond, and overflowing outgoing link (as responses are five times or more as big as requests). Such techy details and more make a big difference. Was Dyn the only target? Why were non-Dyn customers effected?

Nothing to do with the IANA handover. So this post blames Obama for handing control of DNS to the Russians, or some such. It’s silly, and not a shred of truth to it. For the record, I’m (or was) a Republican and opposed handing over the IANA. But the handover was a symbolic transition of a minor clerical function to a body that isn’t anything like the U.N. The handover has nothing to do with either Obama or today’s DDoS. There’s no reason to blame this on Obama, other than the general reason that he’s to blame for everything bad that happened in the last 8 years.

It’s not a practice attack. A Bruce Schneier post created the idea of hacking doing “practice” DDoS. That’s not how things work. Using a botnot for DDoS always degrades it, as owners of machines find the infections and remove them. The people getting the most practice are the defenders, who learn more from the incident than the attackers do.

It’s not practice for Nov. 8. I tweeted a possible connection to the election because I thought it’d be self-evidently a troll, but a lot of good, intelligent, well-meaning people took it seriously. A functioning Internet is not involved in counting the votes anywhere, so it’s hard to see how any Internet attack can “rig” the election. DDoSing news sources like CNN might be fun — a blackout of news might make some people go crazy and riot in the streets. Imagine if Twitter went down while people were voting. With this said, we may see DDoS anyway — lots of kids control large botnets, so it may happen on election day because they can, not because it changes anything.

Dyn stupidly uses BIND. According to “version.bind” queries, Dyn (the big DNS provider that is a major target) uses BIND. This is the most popular DNS server software, but it’s wrong. It 10x to 100x slower than alternatives, meaning that they need 100x more server hardware in order to deal with DDoS attacks. BIND is also 10x more complex — it strives to be the reference implementation that contains all DNS features, rather than a simple bit of software that just handles this one case. BIND should never be used for Internet-facing DNS, packages like KnotDNS and NSD should be used instead.

Fixing IoT. The persistent rumor is that an IoT botnet is being used. So everything is calling for regulations to secure IoT devices. This is extraordinarily bad. First of all, most of the devices are made in China and shipped to countries not in the United States, so there’s little effect our regulations can have. Except they would essentially kill the Kickstarter community coming up with innovative IoT devices. Only very large corporations can afford the regulatory burden involved. Moreover, it’s unclear what “security” means. There no real bug/vulnerability being exploited here other than default passwords — something even the US government has at times refused to recognize as a security “vulnerability”.

Fixing IoT #2. People have come up with many ways default passwords might be solved, such as having a sticker on the device with a randomly generated password. Getting the firmware to match a printed sticker during manufacturing is a hard, costly problem. I mean, they do it all the time for other reasons, but it starts to become a burden for cheaper device. But in any event, the correct solution is connecting via Bluetooth. That seems to be the most popular solution these days from Wimo to Echo. Most of the popular WiFi chips come with Bluetooth, so it’s really no burden for make devices this way.

It’s not IoT. The Mirai botnet primarily infected DVRs connected to security cameras. In other words, it didn’t infect baby monitors or other IoT devices insider your home, which are protected by your home firewall anyway. Instead, Mirai infected things that were outside in the world that needed their own IP address.

DNS failures cause email failures. When DNS goes down, legitimate email gets reclassified as spam, and dropped by spam filters

It’s all about that TTL. You don’t contact a company’s DNS server directly. Instead, you contact your ISPs “cache”. How long something stays in that cache is determined by what’s known as the TTL or “time to live”. Long TTLs mean that if a company wants to move servers around, they’ll have to wait until for until caches have finally aged out old data. Short TTLs mean changes propagate quickly. Any company that had 24 hours as their TTL was mostly unaffected by the attack. Twitter has a TTL of 205 seconds, meaning it only takes 4 minutes of DDoS against the DNS server to take Twitter offline. One strategy, which apparently Cisco OpenDNS uses, is to retain old records in its cache if it can’t find new ones, regardless of the TTL. Using their servers, instead of your ISPs, can fix DNS DDoS for you:

Why not use anycast?

The attack took down only east-coast operations, attacking only part of Dyn’s infrastructure located there. Other DNS providers, such as Google’s famed 8.8.8.8 resolver, do not have a single location. They instead us anycasting, routing packets to one of many local servers, in many locations, rather than a single server in one location. In other words, if you are in Australia and use Google’s 8.8.8.8 resolver, you’ll be sending requests to a server located in Australia, and not in Google’s headquarters.

The problem with anycasting is it technically only works for UDP. That’s because each packet finds its own way through the Internet. Two packets sent back-to-back to 8.8.8.8 may, in fact, hit different servers. This makes it impossible to establish a TCP connection, which requires all packets be sent to the same server. Indeed, when I test it here at home, I get back different responses to the same DNS query done back-to-back to 8.8.8.8, hinting that my request is being handled by different servers.

Historically, DNS has used only UDP, so that hasn’t been a problem. It still isn’t a problem for “root servers”, which server only simple responses. However, it’s becoming a problem for normal DNS servers, which give complex answers that can require multiple packets to hold a response. This is true for DNSSEC and things like DKIM (email authentication). That TCP might sometimes fail therefore means things like email authentication sometimes fail. That it will probably work 99 times out of 100 means that 1% of the time it fails — which is unacceptable.

There are ways around this. An anycast system could handle UDP directly and pass all TCP to a centralized server somewhere, for example. This allows UDP at max efficiency while still correctly with the uncommon TCP. The point is, though, that for Dyn to make anycast work requires careful thinking and engineering. It’s not a simple answer.

SPF (SpeedPhish Framework) – E-mail Phishing Toolkit

Post Syndicated from Darknet original http://feedproxy.google.com/~r/darknethackers/~3/fHMgD_pVPbs/

SPF (SpeedPhish Framework) is a an e-mail phishing toolkit written in Python designed to allow for quick recon and deployment of simple social engineering phishing exercises. There are also other popular Phishing tools are frameworks such as: – Phishing Frenzy – E-mail Phishing Framework – Gophish – Open-Source Phishing Framework – sptoolkit…

Read the full post at darknet.org.uk

Amazon SES Now Supports Custom MAIL FROM Domains

Post Syndicated from Cristian Smochina original https://aws.amazon.com/blogs/ses/amazon-ses-now-supports-custom-mail-from-domains/

The Amazon SES team is pleased to announce that, to increase your email authentication options, you can now use your own MAIL FROM domain when you send emails with SES.

First, a quick refresher on the different “source” addresses associated with an email: an email has a “From” address and a MAIL FROM address. The “From” address is the address that you pass to SES in the header of your email. This is the address that recipients see when they view your email in their inbox (RFC 5322). The MAIL FROM address (a.k.a. “envelope MAIL FROM”), on the other hand, is the address that the sending mail server (SES) transmits to the receiving mail server to indicate the source of the mail (RFC 5321). The MAIL FROM address is used by the receiving mail server to return bounce messages and other error notifications, and is only viewable by recipients if they inspect the email’s headers in the raw message source. By default, SES uses its own MAIL FROM domain (amazonses.com or a subdomain of that) when it sends your emails.

Why use my own MAIL FROM domain?

You might choose to use your own MAIL FROM domain to give you more flexibility in complying with Domain-based Message Authentication, Reporting and Conformance (DMARC). DMARC is an email authentication protocol that relies on two other authentication protocols (Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM)) to enable receiving mail servers to validate that an incoming email is authorized by the owner of the sending domain and has not been modified during transit.

An email can comply with DMARC in two ways: by satisfying the DKIM requirements and/or by satisfying the SPF requirements. You can use either method, but some senders prefer to use both DKIM and SPF for maximum deliverability. As established by DMARC, the requirements for each validation are as follows:

  • DKIM. The requirements to pass DKIM validation for DMARC are: 1) the message must have a valid DKIM signature, and 2) the domain in the DKIM signature must align with the domain in the “From” address in the header of the email. You can easily achieve DKIM validation with SES, which provides a tool (EasyDKIM) to DKIM-sign your messages automatically.
  • SPF. The requirements to pass SPF validation for DMARC are: 1) The domain in the MAIL FROM address of the email must authorize the sending mail server to send for it via a DNS record, and 2) the domain in the email’s “From” address must match the MAIL FROM domain. When SES uses its default MAIL FROM domain, the first SPF requirement is satisfied (because the MAIL FROM domain is amazonses.com, and the mail server is SES), but the second requirement is not satisfied. This is where the benefit of using your own MAIL FROM domain comes in – it enables you to meet that second SPF requirement.

Can I use any domain as my MAIL FROM domain?

The MAIL FROM domain you use with SES must be a subdomain of the verified identity you want to use it with. For example, a MAIL FROM domain of bounce.example.com would be a legitimate MAIL FROM domain for verified domain example.com or verified email address [email protected]. An additional requirement is that the MAIL FROM domain you use with SES must not be a domain that you use in a “From” address if the MAIL FROM domain is the destination of email feedback forwarding.

How do I set it up?

You configure an identity to use a specific MAIL FROM domain within the Identity Management part of the SES console, or by using the SES API. You also must publish MX and SPF records to your domain’s DNS server. When SES successfully detects the MX record, emails you send from the identity will use the specified MAIL FROM domain. For a full description of the set-up procedure, see the developer guide.

Will my sending process change?

No. After you configure a verified identity to use a specified MAIL FROM domain and SES successfully detects the required MX record, you simply continue to send emails in the usual way.

We hope you find this feature useful! If you have any questions or comments, let us know in the SES Forum or here in the comment section of the blog.