In message <A.1P0wT9-0004Fy-9J at smtp-ext-layer.spamhaus.org>,
Richard Cox <richard.cox at btuser.net> wrote:
>Ronald F Guilmette <rfg at tristatelogic.com> wrote:
>> (Separate question: Is there any way to obtain archived dumps of the
>> RIPE whois data base, e.g. from April of this year, so that I might be
>> able to check and see if the original whois for the AS & IP block also
>> said "Belize", as I suspect it did?)
>>Have you been introduced to the RIPE Resource Explainer yet?
>See: http://albatross.ripe.net/cgi-bin/rex.pl
No, I didn't know about that. Thanks for the tip!
>It does not show the original WHOIS data (sadly) but it can be helpful.
Well, really, it was the older whois info (if any) for the AS and the IP
block that I wanted to look at the most. Just a history of who has been
routing a specific chunk of IP space is somewhat less interesting, from
my perspective.
>We can be reasonably sure that the resource holder for 195.80.148.0/22
>is not in Belize because the phone numbers in the WHOIS record are in
>an invalid format for Belize. (See: http://wtng.info/wtng-501-bz.html)
>If they really were in Belize, they would know the local phone number
>format and so even if they wanted to submit fake phone numbers, they
>would probably get them in the correct format. Incidentally, we see
>that CIDR currently routing to Starnet, Moldova. No surprise there.
Is Starnet known to be... ah... dodgy?
>But the BGP PATH downstream of Starnet (AS31252) is most unusual:
>"31252 12968 40975 41665 30968 50877" which tells us that packets
>are (allegedly) passing through routers announcing these networks:
>>AS31252 STARNET MOLDOVA
>AS12968 CROWLEY DATA POLAND
>AS40975 CHML WEB SERVICES ROMANIA
>AS41665 HOSTING.UA UKRAINE
>AS30968 INFOBOX.RU RUSSIA
>AS50877 INSTANTEXCHANGER "BELIZE"
>>But what may well be an ICMP filter at Starnet prevents traceroutes.
>>I think what we are seeing here is an ASN simulator, similar in concept
>to the traceroute simulators that have been used by the Russian Business
>Network. It is probably being used as part of a non-physical routing
>technology, such as BGP-VPN. If you go to route-views.routeviews.org,
>log in, and issue "sh ip bgp regex 12968" (without the quotes, natch!)
>Routeviews will show you all routes that have been contributed to
>Routeviews which allegedly pass through AS12968.
Thanks much for all this additional info Richard. I really didn't know
any of this. I knew some other stuff that made that block look especially
suspicious, but not any of the info that you just shared.
I certainly hadn't made any sort of connection to RBN, however...
It does certainly seem to me that _somebody_ may have taken serious umbrage
to my recent attempts to call attention to various ASes and IP blocks that
looked to me to be more than a little bit suspicious. Just a few short
hours after I posted here about AS50877 and the 195.80.148.0/22 block,
starting at around 06:16AM and continuing until around 06:51AM, local
time (PDT, -0700) my firewall got lit up, continuously, like a veritable
Christmas tree, with blocked TCP packets coming in to a wide variety of
apparently random ports, from on the order of around 7 million different
source IP addresses. (Yea, I know, spoofed.) Thankfully, I was asleep
at the time, and thus was saved from a lot of needless worry and/or panic.
No material damage seems to have been done, but I'm certainly glad that
the last time I did an install, I allowed plenty of extra gigabytes for
my /var/log partition, as I eneded up with some really obese log files.
>...
>Now it is entirely possible for some Routeviews data to be misleading
>(not through any fault of Routeviews, but anyone who understands BGP
>will know what I'm referring to) and it's also possible for the above
>to happen for legitimate reasons, so other checks were needed to make
>certain that my results are meaningful: those checks have been done
>and they passed: I'm not going to post details for obvious reasons.
By "passed" I'm assuming that you mean that you've confirmed that
195.80.148.0/22 is rather on the dodgy side, yes?
>> Why would anyone bother to hijack an IP block or an ASN if RIPE
>> will just issue you either of those things, willy nilly, no matter
>> where you live?
>>The only advantages of hijacking a block in the RIPE service region
>are (a) that you would then avoid having to pay for it, and (b) that
>your conscience would be less likely to be troubled by the fact that
>some LIR had taken your money for submitting (probably) exaggerated
>information about your hardware etc to the RIPE NCC on your behalf.
So bringing this all back around to the issue of available WHOIS information,
is there anything in the WHOIS for either AS50877 or 195.80.148.0/22 that
a mere mortal such as myself could look at to determine which LIR had
requested this specific IP block?
Does Moldova have its own LIR? Is that the one that requested this block?
Please tell me that _somebody_ is responsible here.
Regards,
rfg