You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by jdebert <jd...@garlic.com> on 2014/07/25 02:32:05 UTC
Alternate method to check for rule updates?
Sprint, which I use for net access is hijacking DNS. I cannot trust
that the response received by sa-update is valid. Is there another
method to check for updates?
BTW, 1609892 is being given as the current version. It's been at this
version for at least a few days.
jd
Re: Alternate method to check for rule updates?
Posted by John Hardin <jh...@impsec.org>.
On Thu, 24 Jul 2014, jdebert wrote:
> BTW, 1609892 is being given as the current version. It's been at this
> version for at least a few days.
Masscheck corpora are starved at the moment. It's being analyzed.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
...the good of having the government prohibited from doing harm
far outweighs the harm of having it obstructed from doing good.
-- Mike@mike-istan
-----------------------------------------------------------------------
784 days since the first successful private support mission to ISS (SpaceX)
Re: Alternate method to check for rule updates?
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Fri, 2014-07-25 at 03:30 +0200, me wrote:
> On Thu, 2014-07-24 at 17:32 -0700, jdebert wrote:
> > Sprint, which I use for net access is hijacking DNS.
> > I cannot trust that the response received by sa-update is valid. Is
> > there another method to check for updates?
Let me clarify a little.
> If you really cannot trust *.updates.spamassassin.org DNS responses, you
False results here would in almost any case simply mean failing
sa-update. The odds for false TXT records, that (a) still are a valid
revision number and (b) do not result in either lint check failure or
simply downgrade to a previous working rule set are close to zero.
In other words, no rules update with an alert via cron. Or at worst,
revert to a previous known-to-work state.
> cannot trust *any* DNS response. Including all the DNSxLs SA uses by
> default. And rDNS rules. And your own SMTP's Received header.
False responses in those cases easily can result in both, FPs and FNs.
Lot's of them.
Thus, if you cannot even trust your ISP('s DNS) to get sa-updates right,
worrying about sa-update is the least of your problems.
(Unless, again, your issue actually is not running a local resolver.)
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Alternate method to check for rule updates?
Posted by jdebert <jd...@garlic.com>.
On Fri, 25 Jul 2014 17:13:13 +0100
RW <rw...@googlemail.com> wrote:
> On Thu, 24 Jul 2014 18:56:10 -0700
> jdebert wrote:
>
>
> > >
> > > > I cannot trust that the response received by sa-update is valid.
> > > > Is there another method to check for updates?
> > >
> > > If you really cannot trust *.updates.spamassassin.org DNS
> > > responses, you cannot trust *any* DNS response. Including all the
> > > DNSxLs SA uses by default. And rDNS rules. And your own SMTP's
> > > Received header.
> >
> > Wow. I never thought of that. :\
>
>
> Do you have any reason to think they are modifying TXT records? I'd be
> surprised if they are. Typically the way this kind of thing works is
> that they modify negative A-record results, or the DNS for malicious
> sites.
I've received empty TXT and other resource records where I was
expecting something else. Sometimes the answers are not consistent. Not
really sure what to make of it yet.
They won't even answer for ietf.org and isc.org, and other such
malicious and dangerous sites. (As everyone knows, ietf and isc are
two of the most dangerous entities on the net.) But they do respond for
nsfw, known malware, paedo and porno sites. And there have been a few
other odd things happening here from time to time that likely could be
attributed to dns shenanigans.
>
> I don't, so far, see a reason why this need have a significant impact
> on SpamAssassin. It will probably affect NO_DNS_FOR_FROM. It might
> cause problems with DNSxL per IP limits, but that depends on how it's
> implemented.
>
I can imagine some possibilities. Whether they can get away with it or
not depends on how robust authentication is, how clever their spoofing
may be, and other factors.
Controlling DNS is a less obvious way of controlling information than is
blocking or redirecting http traffic. And it's more difficult to evade.
I am curious about which other service providers use these so-called
"transparent DNS proxies" and just how detectable they are. Someone's
already mentioned Earthlink was probably doing dns proxying.
Right now, also considering a vpn and about finding or building
dns watchdogs.
jd
Re: Alternate method to check for rule updates?
Posted by RW <rw...@googlemail.com>.
On Thu, 24 Jul 2014 18:56:10 -0700
jdebert wrote:
> >
> > > I cannot trust that the response received by sa-update is valid.
> > > Is there another method to check for updates?
> >
> > If you really cannot trust *.updates.spamassassin.org DNS responses,
> > you cannot trust *any* DNS response. Including all the DNSxLs SA
> > uses by default. And rDNS rules. And your own SMTP's Received
> > header.
>
> Wow. I never thought of that. :\
Do you have any reason to think they are modifying TXT records? I'd be
surprised if they are. Typically the way this kind of thing works is
that they modify negative A-record results, or the DNS for malicious
sites.
I don't, so far, see a reason why this need have a significant impact
on SpamAssassin. It will probably affect NO_DNS_FOR_FROM. It might
cause problems with DNSxL per IP limits, but that depends on how it's
implemented.
Re: Alternate method to check for rule updates?
Posted by jdebert <jd...@garlic.com>.
On Fri, 25 Jul 2014 04:31:11 +0200
Karsten Bräckelmann <gu...@rudersport.de> wrote:
>
> Run.
>
> Is that an option?
Not yet. And alternatives will cost at least double, for half of what
I get via sprint.
> Just to be clear -- and absolutely no excuse to tamper with raw
> traffic like this -- are we talking end-user / dial-up?
End user.
>
> Sprint really even messes with DNS TXT records? What for?
Who knows?
> I understand home ISP switching might be difficult. In which case I
> guess Sprint would see exactly one type of traffic by me -- VPN
> traffic using their line into a trustworthy network.
>
They're about to see a whole lot more encrypted traffic.
jd
Re: Alternate method to check for rule updates?
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Thu, 2014-07-24 at 18:56 -0700, jdebert wrote:
> On Fri, 25 Jul 2014 03:30:19 +0200 Karsten Bräckelmann wrote:
> > On Thu, 2014-07-24 at 17:32 -0700, jdebert wrote:
> > > Sprint, which I use for net access is hijacking DNS.
> >
> > What exactly do you mean hijacking? Routing NXDOMAIN to some sort of
> > advertising web-server? Or serious packet-sniffing tampering with
> > *any* DNS query crossing their hardware?
>
> Yes. Also disabling dnssec, not responding to certain queries and
> modifying responses and queries.
Run.
Is that an option?
> They like to call it "transparent DNS proxying". But it's not
> proxying and obviously not transparent.
>
>
> > > I cannot trust that the response received by sa-update is valid. Is
> > > there another method to check for updates?
> >
> > If you really cannot trust *.updates.spamassassin.org DNS responses,
> > you cannot trust *any* DNS response. Including all the DNSxLs SA uses
> > by default. And rDNS rules. And your own SMTP's Received header.
>
> Wow. I never thought of that. :\
>
>
> > And just in case your problem merely is with using your ISPs DNS
> > server, don't. Run your own local, caching DNS resolver
> > (non-forwarding).
> >
> > Unless we're really talking intercepting raw DNS traffic, that should
> > do.
>
> we are.
Got to admit, I wasn't expecting this. What you describe sounds major.
Just to be clear -- and absolutely no excuse to tamper with raw traffic
like this -- are we talking end-user / dial-up?
Sprint really even messes with DNS TXT records? What for?
Well, unless there is no way around that almost malicious tampering, I
guess the solution is to change ISP, regardless whether that's local
line or server housing.
I understand home ISP switching might be difficult. In which case I
guess Sprint would see exactly one type of traffic by me -- VPN traffic
using their line into a trustworthy network.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: Alternate method to check for rule updates?
Posted by John Hardin <jh...@impsec.org>.
On Thu, 24 Jul 2014, jdebert wrote:
> On Fri, 25 Jul 2014 03:30:19 +0200
> Karsten Bräckelmann <gu...@rudersport.de> wrote:
>
>> On Thu, 2014-07-24 at 17:32 -0700, jdebert wrote:
>>> Sprint, which I use for net access is hijacking DNS.
>>
>> What exactly do you mean hijacking? Routing NXDOMAIN to some sort of
>> advertising web-server? Or serious packet-sniffing tampering with
>> *any* DNS query crossing their hardware?
>
> Yes. Also disabling dnssec, not responding to certain queries and
> modifying responses and queries.
>
> They like to call it "transparent DNS proxying". But it's not
> proxying and obviously not transparent.
YGBFKM. Seriously? That kinda shoots the idea they are a Tier-1 ISP in the
head...
Maybe you have to pay extra to have them not fsck up your data.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
The more you believe you can create heaven on earth the more
likely you are to set up guillotines in the public square to
hasten the process. -- James Lileks
-----------------------------------------------------------------------
784 days since the first successful private support mission to ISS (SpaceX)
Re: Alternate method to check for rule updates?
Posted by Dave Warren <da...@hireahit.com>.
On 2014-07-24 18:56, jdebert wrote:
> On Fri, 25 Jul 2014 03:30:19 +0200
> Karsten Bräckelmann <gu...@rudersport.de> wrote:
>
>> On Thu, 2014-07-24 at 17:32 -0700, jdebert wrote:
>>> Sprint, which I use for net access is hijacking DNS.
>> What exactly do you mean hijacking? Routing NXDOMAIN to some sort of
>> advertising web-server? Or serious packet-sniffing tampering with
>> *any* DNS query crossing their hardware?
> Yes. Also disabling dnssec, not responding to certain queries and
> modifying responses and queries.
>
> They like to call it "transparent DNS proxying". But it's not
> proxying and obviously not transparent.
If they're actually tampering with DNS requests made to other DNS
servers, I'd give some serious thought to dropping them completely.
If that's not an option, perhaps a $5 VPS at a network location that's
reasonably near yourself, and then forwarding your own resolver to that
resolver over port other than 53.
--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren
Re: Alternate method to check for rule updates?
Posted by jdebert <jd...@garlic.com>.
On Fri, 25 Jul 2014 03:30:19 +0200
Karsten Bräckelmann <gu...@rudersport.de> wrote:
> On Thu, 2014-07-24 at 17:32 -0700, jdebert wrote:
> > Sprint, which I use for net access is hijacking DNS.
>
> What exactly do you mean hijacking? Routing NXDOMAIN to some sort of
> advertising web-server? Or serious packet-sniffing tampering with
> *any* DNS query crossing their hardware?
Yes. Also disabling dnssec, not responding to certain queries and
modifying responses and queries.
They like to call it "transparent DNS proxying". But it's not
proxying and obviously not transparent.
>
> > I cannot trust that the response received by sa-update is valid. Is
> > there another method to check for updates?
>
> If you really cannot trust *.updates.spamassassin.org DNS responses,
> you cannot trust *any* DNS response. Including all the DNSxLs SA uses
> by default. And rDNS rules. And your own SMTP's Received header.
Wow. I never thought of that. :\
>
> And just in case your problem merely is with using your ISPs DNS
> server, don't. Run your own local, caching DNS resolver
> (non-forwarding).
>
> Unless we're really talking intercepting raw DNS traffic, that should
> do.
>
we are.
jd
Re: Alternate method to check for rule updates?
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Thu, 2014-07-24 at 17:32 -0700, jdebert wrote:
> Sprint, which I use for net access is hijacking DNS.
What exactly do you mean hijacking? Routing NXDOMAIN to some sort of
advertising web-server? Or serious packet-sniffing tampering with *any*
DNS query crossing their hardware?
> I cannot trust that the response received by sa-update is valid. Is
> there another method to check for updates?
If you really cannot trust *.updates.spamassassin.org DNS responses, you
cannot trust *any* DNS response. Including all the DNSxLs SA uses by
default. And rDNS rules. And your own SMTP's Received header.
In that case, I don't see how you can run SA at all, or even a trusted
SMTP MX. (Without VPN'ing out to a trusted DNS...)
And just in case your problem merely is with using your ISPs DNS server,
don't. Run your own local, caching DNS resolver (non-forwarding).
Unless we're really talking intercepting raw DNS traffic, that should
do.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}