|
Tweet Follow @spamhaus |
|
||
![]() Poor sending practices trigger a tidal wave of informational listings Spamhaus Botnet Threat Update: Q4-2021 SERVICE UPDATE | Spamhaus DNSBL users who query via Cloudflare DNS need to make changes to email set-up Spamhaus Botnet Threat Update: Q3-2021 Spammer Abuse of Free Google Services Spamhaus Botnet Threat Update: Q2-2021 Emotet Email Aftermath Wordpress compromises: What's beyond the URL? Older News Articles: ![]() ![]() |
When things move to the "cloud", sadly, good things don’t always follow. Miscreants of various sorts have long recognized that they too can benefit from the same advantages as regular users: scalability, abstraction and pay-per-use. It was thus no surprise that spamming operations set-up shop on the biggest of all clouds: Amazon Web Services (AWS). Difficulties in detectionThis is not news per se, but these malicious operators quickly found their way into the extensive array of APIs offered by AWS. By building their set-up specifically around the AWS ecosystem, cybercriminals rapidly maneuvered within it. As a result, mitigation was difficult not only for those receiving their spam but also for the AWS abuse team, which, on occasion, had difficulty pinpointing the offending accounts. History repeating itselfWhat’s interesting is that this isn’t the first time we’ve observed this kind of situation; it isn’t a million miles away from the "spambots in end-user systems" which have been around for over 10 years. Spambots have infected end-users' systems for years, taking advantage of network and IP address diversity to get the spam out. Similarly to there being no necessity for the majority of end-user systems to send mail directly, neither does the majority of cloud infrastructure. Tipping point at AWSTop ASNs appearing in Spamhaus CSS Listings![]() Restricting Port 25At the end of January 2020, AWS announced that they would start restricting port 25 access, by default. Why restrict port 25? Well, port 25 is the channel designated for sending email. By restricting this port, operators force email to go through dedicated outbound mail-servers instead of direct-to-mx, thereby greatly limiting the damage that can be done. In AWS's FAQ regarding this change, it explains that it is taking this action "to protect customers and other recipients from spam and email abuse." Does this sound familiar? It should; this is what the majority of internet service providers (ISPs) have done for years to their end-user networks. By deploying this relatively simple countermeasure, massive amounts of abuse are not only mitigated but will simply never occur in the first place. A nod to AWSAS16509 & AS14618 CSS Listings decrease![]() Don’t make resources available to miscreantsThere are valuable lessons to be learned here for the wider internet community; abusers will go wherever they can get the resources. With this in mind, products and architecture should always be designed factoring in abuse i.e., how cybercriminals could work the product/architecture to their advantage. Customers should always be vetted and infrastructure constantly monitored for abuse, and where abuse is reported, speedy remediation should take place. Finally, a thought for us all: the best spam is the spam that is never sent in the first place. |
![]() ![]() ![]() ![]() ![]() ![]() |
![]() Permanent link to this news article: Amazon Web Services - thwarting spam with a decade-old best practice http://www.spamhaus.org/news/article/794/amazon-web-services-thwarting-spam-with-a-decade-old-best-practice ![]() |
![]() Permission to quote from or reproduce Spamhaus News articles is granted automatically providing you state the source as Spamhaus and link to the news record. |
|