+1, I for one have personally seen leakage from one of their servers,
albeit over a year ago.. No matter what your opinion of how UCE has a
fee for expedited removal, (it's their choice on how to monitize) there
is usually a reason someone gets listed.. compromises happen to the
best.. but you would think a security company would pay more attention
to the why/how they got listed, instead of calling out the RBL.
There is never one side to these issues..
While we don't personally use any honey pots on our RBL's, so I don't
like generalizations like in that article, if more networks paid
attention to what is leaving their networks, they would not get listed
in the first place.
https://www.m3aawg.org/sites/default/files/m3aawg-blocklist-help-bp-2018-02.pdf
Someone else pointed this out, but it used to be that their was more
communication from both sides of the fence, maybe M3AAWG can try
addressing this again, in a COVID friendly way..
On 2021-02-14 8:00 a.m., Chris via mailop wrote:
On 2021-02-14 01:42, André Peters via mailop wrote:
Hi,
Have you guys already read this?
https://blog.sucuri.net/2021/02/uceprotect-when-rbls-go-bad.html
I have seen the discussion and found it fits. Will you remove UCL from
your servers?
I did a bit of research and there's a couple of things that don't
*quite* sit right. Take this as you will:
While UCEProtect has been the recipient of fairly deserved aprobation on
a number of accounts, including that their documentation sucks, and
reasonably well-founded discussions about the policy surrounding their
listings (eg: using L2 or L3 for blocking, or the paid removal
nonsense), there's a couple things to consider:
1) The listings are UCEPROTECTL2. It's policy is to list netblocks
which contain a certain threshold of IPs emitting abuse. The listing
per-se doesn't assert that anything is coming from that IP specifically,
and blocking on that basis may have FPs. While the documentation is
lousy, it does make that clear. It's up to the DNSBL user to determine
if that's what they want. Hopefully they'll have read that part (like I
said the documentation sucks), and deliberately chose that.
[L3 is essentially full ASNs based on metrics alone, rather than
research into the actual behaviour of the owner.]
2) Securi.net used mxtoolbox. It has problems of its own of
synthesizing it's own queries, and jumping to conclusions and misleading
you. For example, if you do a domain lookup, you can end up with
assertions you're listed in IP-only DNSBLs which have nothing to do with
you.
I personally prefer to use this for straight and
uncomplicated/non-misleading results:
http://multirbl.valli.org/lookup/192.124.249.6.html
Which lists some 9 listings for the IP. Now of course most of the
DNSBLs listing it are trivial, not used much, or largely ignored (like
RFC Ignorant), there are at least two that do seem indicate that they
HAVE seen email traffic from that specific IP. So something seems to be
awry with their assertion it can't make outbound connections.
- If I had a nickel for everyone who insisted that their IP can't send
email, when I have spam sample in my hand proving otherwise, I'd have
retired long ago, or at least be a few dozen cases of beer richer.
Even tho it's Securi.net, I'd prefer to see them at least expending the
effort to see if anything *is* emitting from that IP rather than just
asserting it. It wouldn't the first time that network hardware got
infected, or a network operator got outsmarted.
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada
This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
