Thank you all for this input, I really appreciate all this information <3 Institutionally, it seems to make the most sense to block all AI harvesters, even if they are accessing content: if for-profit AI companies would like to improve their models, they really shouldn't be doing so at the expense of publicly funded infrastructure.
Please continue to drop your information and thoughts on this in the thread, and have a lovely weekend! On Thursday, April 24, 2025 at 8:06:30 PM UTC-4 Rich Kulawiec wrote: > On Wed, Apr 23, 2025 at 10:29:16AM -0700, Carolyn Sullivan wrote: > > We've been getting a ton of traffic from IP addresses with Alibaba Cloud > > out of Hong Kong and Singapore that's been overwhelming our servers. > [...] > > 1. Unless you have an operational need to do otherwise, I recommend > dropping all incoming TCP traffic from Alibaba's clouds to (a) web > services and (b) password-protected services. (a) includes ports 80, > 443, and anything else you're running; (b) includes 22 (ssh), 993 (imaps), > 995 (pops), and anything else that requires authentication. > > 2. I recommend this because I've been watching received traffic from > them for many years, and -- so far -- it's been constant attacks and abuse, > the latter including some very badly behaving web crawlers. > > 3. To clarify (1), I mean "in your perimeter firewalls". There's no > reason to let this traffic get anywhere near a server. And I use > the word "drop" because I mean "just drop the incoming TCP SYN, don't > even bother sending a NACK". It's not worth wasting even the small > amount of CPU/bandwidth it would take to send back those NACK responses > (which will be ignored anyway); just silently discard whatever arrives, > if your firewall allows that. (If you're using BSD's pf, then > "set block-policy drop" in concert with the "block" directive > accomplishes this.) > > 4. It's your call on whether to expand this policy beyond the ports > associated with web and password-protected services, and/or whether to > expand it to UDP. If you're observing port scans and/or DNS abuse/attacks > and/or attacks against other services, that might be wise. > > 5. Here's my working list of their network allocations. *This may be > incomplete or overinclusive or otherwise wrong* but I hope it'll > be useful as a starting point: > > 8.208.0.0/12 ASEPL-SG/AlibabaCloudSingaporePrivateLimited > 47.52.0.0/16 AL-3/Alibaba > 47.56.0.0/15 AL-3/ALICLOUD-HK > 47.74.0.0/15 AL-3/Alibaba > 47.76.0.0/14 AL-3/Alibaba > 47.80.0.0/13 AL-3/Alibaba > 47.88.0.0/14 AL-3/Alibaba > 47.235.0.0/16 AL-3/Alibaba > 47.236.0.0/14 AL-3/Alibaba > 47.240.0.0/14 AL-3/Alibaba > 47.244.0.0/15 AL-3/Alibaba > 47.246.0.0/16 AL-3/Alibaba > 47.250.0.0/15 AL-3/Alibaba > 47.252.0.0/15 AL-3/Alibaba > 47.254.0.0/16 AL-3/Alibaba > 147.139.0.0/16 AL-3/Alibaba > 163.181.0.0/16 AL-3/AlibabaCloudLLC > 198.11.128.0/18 ALIBABA-US-CDN > > 6. There are various collaborative efforts underway to deal with very > badly behaved web crawlers, because unfortunately it's a rapidly > proliferating problem. If you're interested in this, please drop > me a note off-list. > > ---rsk > -- All messages to this mailing list should adhere to the Code of Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/dspace-tech/2aa4d8e1-2ac2-47cc-9989-1392a80f425an%40googlegroups.com.
