On 8/1/23 13:57, Brian Conry wrote:
Hello again,
I'm replying to my own message because I don't want to single out
anyone who has already replied. There was value in each of your
responses.
This is going to be a long email, and for that you have my apologies,
but I can't think of any way to make it shorter without it sounding
like "dude, just trust me, I know what I'm doing", and I don't want to
be that guy.
Thank you for the time and thought that went into the replies. I
sincerely appreciate your concern for the effectiveness of our spam
filtering.
One thing is clear to me from those response is that I did a poor job
explaining the situation, and for that you also have my apologies.
This is my attempt to correct that error.
First, any configuration change I would make would be scoped to _only_
the one (1) recipient address in question - nothing will be changed
about what SA does for any other address that we handle.
Second, this recipient address is for a queue in an RTIR [1]
installation for one of our hosted customers. The purpose of this
queue is to receive reports of suspicious activity from elsewhere, and
the queue is worked by trained security professionals. This address
is already configured to receive all messages no matter what the spam
score is. It is their job to look at them and assess whether or not
it represents an incident, and if so what response is needed.
Third, to expand on something I alluded to briefly, the emails in
question are generated by a security appliance on our customer's
network, in accordance with their security policy and posture. The
warnings we're getting when our mail server performs these DNS queries
are coming from _our_ network infrastructure, which is AWS.
As I understand things, I have several options.
Option 1) Do nothing with any configuration.
We will continue to get notification from AWS of this suspicious
activity, often several times in one day, that we then have to go and
correlate with mail logs to confirm that the suspicious DNS queries
were, in fact, related to the spam filtering of an email, and that the
email in question was for this queue that is specifically for
receiving that sort of content.
The danger with this is that we will become lax in our checking of the
mail logs and that this will essentially devolve into a variant on
option 2, but with more work.
Option 2) Tell our network monitoring (AWS) to ignore these findings
for our mail servers.
This seems fairly reasonable, as we know that our mail servers will
make these queries semi-regularly as they are running the spam
filtering on the messages for this recipient.
The downside is that it will also turn off all notification to us if
similar content were to be received at another address, potentially
one that isn't handled by trained security professionals, or even if
(heaven forbid) our mail servers were to be compromised by bitcoin
mining malware. That last one shouldn't be possible due to other
controls, but there's no denying that there is some added risk in
auto-ignoring these warnings.
Option 3) Skip all spam checking for this recipient.
It is, after all, associated with an incident response queue, expected
to receive email messages with body content that contains names of, or
even links directly to, known malware domains, and is staffed by
security professionals.
And yet, this all-or-nothing approach feels like it's sacrificing some
possible good, which leads to my questions regarding a hypothetical
Option 4.
Option 4) Targeted disabling of specific checks for this _one_
recipient that preserves as much value as possible for the remaining
checks.
I think there are several variants here, and this is where I know that
I don't have the expertise necessary to make the optimal decision.
From what I can tell from the reports, the only queries that are
triggering the security alert for our mail servers are the ones made
for records in the (known malware) domain or one of its subdomains.
In the debug logs that I inspected there were three queries:
1) malwaredomain.com/A
2) subdomain.malwaredomain.com/A
3) malwaredomain.com/NS
As best as I can tell, the results of these queries were all used for
additional DNSRBL queries, but if AWS is noticing that part of the
context they aren't letting on.
Variant A) disable all DNSRBL checks. :(
Variant B) disable only those RBLs that ask for the information that
triggers these queries. This is an improvement, but it also skips
those same checks on everything in the message headers.
Variant C) disable some/most/all checks for names found only in the
message body. This would provide full checking of all names found in
the headers and skip only that content in which we expect to find
trouble.
I believe I can do variants A) and B), so worst case would be choosing
B, but I'm willing to put in some additional work to implement variant
C) if that is possible.
If you've made it this far, I congratulate you on your endurance and
thank you for your time.
Thanks,
Brian
[1] https://github.com/bestpractical/rtir#readme
It appears on brief inspection that the core of your problem is AWS
complaining about suspicious activity from your DNS queries relating to
spam.
If this is so, you have the option to run your own DNS, and/or delegate
your DNS forwarding to a service that is more helpful to your operations
than AWS.
In relation to some anti-spam sites used to check sender IPs, the advice
is to not use any well-known DNS forwarder such as google 8.8.8.8.
Running your own DNS server seems to be more acceptable to the anti-spam
sites.
.
--
Jeremy
