[anti-abuse-wg] AS28753 - Leaseweb Deutschland GmbH -- Facilitating legacy squatting?

Excellent questions, friends.
All the best in this time of covid and holidays!
George
Canada
________________________________
From: anti-abuse-wg <anti-abuse-wg-bounces at ripe.net> on behalf of PP <phishphucker at storey.ovh>
Sent: Sunday, December 20, 2020 4:47:21 PM
To: anti-abuse-wg at ripe.net <anti-abuse-wg at ripe.net>
Subject: Re: [anti-abuse-wg] AS28753 - Leaseweb Deutschland GmbH -- Facilitating legacy squatting?

Does anyone else find it crazy that without Mr Guilmette, this would all
go un-noticed?

Why does RIPE not employ its own researchers doing what he is doing?

and more importantly, how much of this crap is occurring that even he
himself has not yet noticed?



On 21/12/2020 11:16 am, Ronald F. Guilmette wrote:
> In the period from 2020-12-04 until 2020-12-10 someone representing
> AS28753 - Leaseweb Deutschland GmbH, or someone purporting to represent
> that ASN/company created a set of thirteen (13) new route: entries in
> the security-free RADB data base:
>
> https://pastebin.com/raw/qs9yywFe
>
> It appears somewhat more than coincidental that many of these new RADB
> route entries refer to either(a) legacy IPv4 address blocks in the ARIN
> region or else (b) unassigned (bogon) IPv4 address space in the ARIN
> region.
>
> A listing of the relevant IPv4 cidrs along with the top-level allocation
> holders for each CIDR is given in the following table:
>
> https://pastebin.com/raw/rnqMXHW0
>
> Although there is some ambiguity regarding the status of the non-US/non-ARIN
> blocks listed in the above table, my inspection of the relevant WHOIS
> records for the US/ARIN blocks indicates to me that these are all either
> (a) abandoned IPv4 legacy blocks or else (b) unassigned ARIN bogons.  This
> strongly suggests that all of the IPv4 address blocks named in all of the
> relevant RADB rote entries may be, and likely are being squatted on at the
> present time.
>
> Please note however that AS28753 - Leaseweb Deutschland GmbH - is not
> itself doing any of the squatting.  Rather, the squatting is being
> undertaken by the various ASNs mention in the following active routing
> summary:
>
> 62.182.160.0/21    AS39325   RU  Viptelecom LLC
> 79.173.104.0/21    AS13259   RU  Delta Telesystems Ltd.
> 85.28.48.0/20      AS13259   RU  Delta Telesystems Ltd.
> 85.89.104.0/21     AS13259   RU  Delta Telesystems Ltd.
> 89.187.8.0/21      AS41762   UA  PE Logvinov Vladimir Vladimirovich
> 91.229.148.0/22    AS56968   KZ  TemirLan Net Ltd
> 128.0.80.0/20      AS34498   RU  Jilcomservice
> 199.61.32.0/19     AS9009    GB  M247 Ltd
> 204.229.64.0/19    AS10650   US  Extreme Internet
> 205.134.96.0/19    AS10650   US  Extreme Internet
> 205.148.96.0/19    AS397373  US  H4Y Technologies LLC
> 209.151.96.0/19    AS9009    GB  M247 Ltd
> 216.93.0.0/19      AS9009    GB  M247 Ltd
>
> Note that AS10650 (Extreme Internet) is itself a legacy abandoned ARIN
> ASN.  It is likely also squatted.  It's one and only current upstream,
> according to bgp.he.net, is AS13259 - Delta Telesystems Ltd. (Russia).
>
> In fact, all of the following ASNs from the above table also have AS13259,
> Delta Telesystems Ltd. (Russia) as their one and only upstream at the
> present time:
>
> AS39325 - Viptelecom LLC
> AS41762 - PE Logvinov Vladimir Vladimirovich
> AS56968 - TemirLan Net Ltd
> AS34498 - Jilcomservice
> AS1065  - Extreme Internet
>
> On this basis it would appear that the root of the problem in this case
> lies at AS13259, Delta Telesystems Ltd. (Russia).
>
> As a mitigation for these squats, I recommend dropping/blocking all of
> the IPv4 CIDRs listed above.  Additionally, since AS13259 appears to
> be highly untrustworth at the present time. I would advise blocking
> all traffic to/from these blocks also:
>
> https://bgp.he.net/AS13259#_prefixes
>
> 79.173.104.0/21
> 82.147.68.0/24
> 82.147.70.0/24
> 82.147.71.0/24
> 82.147.75.0/24
> 85.28.48.0/20
> 85.89.104.0/21
> 91.206.16.0/23
> 193.107.92.0/22
> 2001:678:68c::/48
>
>
> Regards,
> rfg
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/anti-abuse-wg/attachments/20201221/35af1632/attachment.html>