Is there anyone from ASPEWS on this list?

Mailman List Mirror (Read Only)
1

Hi,

ASPEWS is listing 216.83.32.0/20 as being associated with the whole
Atrivo incident of 2008. My memory does not recall 216.83.32.0/20 being
involved, nor the provider that belongs to.

So it'd be cool if I could you know, talk to someone who has involvement
with that, because frankly, I do not see why it is listed as having any
involvement with Atrivo. Also, the fact that Atrivo is *dead* and this
stuff is still listed means that anyone who gets those blocks from ARIN
next are basically screwed. Which kind of sucks.

William

2

Also, the fact that Atrivo is *dead* and this
stuff is still listed means that anyone who gets
those blocks from ARIN next are basically screwed

Why would you say Atrivo is dead?

root@localhost --- {~} nslookup www.googleadservices.com 85.255.114.83
Server: 85.255.114.83
Address: 85.255.114.83#53

Name: www.googleadservices.com
Address: 67.210.14.113

root@localhost --- {~}
root@localhost --- {~} nslookup www.googleadservices.com 8.8.4.4
Server: 8.8.4.4
Address: 8.8.4.4#53

Non-authoritative answer:
www.googleadservices.com canonical name = adservices.google.com.
adservices.google.com canonical name = adservices.l.google.com.
Name: adservices.l.google.com
Address: 74.125.19.96

Regards,

Alex Lanstein
FireEye, Inc.

3

That is Cernal, and it is hosted in Russia now.

Cernal and Atrivo are two different entities, Atrivo used to host
Cernal, but now they have different hosting arrangements.

Can people get a clue and understand this very critical difference?

Thanks.

William

4

ASPEWS is listing 216.83.32.0/20 as being associated with the whole
Atrivo incident of 2008. My memory does not recall 216.83.32.0/20 being
involved, nor the provider that belongs to.

Since nobody but the occasional highly vocal GWL uses ASPEWS, it's
hard to see why one would care, but if you want to find ASPEWS, crank
up your favorite usenet program, post a question to nanae, and watch
the vitriol roll in. There might be a comment from ASPEWS in there.

R's,
John

5

William Pitcock wrote:

Cernal and Atrivo are two different entities, Atrivo used to host
Cernal, but now they have different hosting arrangements.

I now understand the original point you were trying to make about Atrivo. I disagree with your premise that it is actually a different entity than Cernel, but am not trying to debate that on this list for various reasons.

Acting under my (incorrect or correct) assumption that they are in fact the same entity, I made my post to show that "the boys were back".

That is, for a decent amount of time, parts of 85.255.112.0/20 were not being advertised, and hence the dns hijacking pointing selected http traffic to 67.210.0.0/20 wasn't happening.

My point was that it (fairly) recently started being advertised again, and it was the same old song and dance wrt dns/http hijacking/fraud.

Regards,

Alex Lanstein
FireEye, Inc.

6

William Pitcock wrote:
>>>Cernal and Atrivo are two different entities, Atrivo used to host
>>>Cernal, but now they have different hosting arrangements.

I now understand the original point you were trying to make about Atrivo. I disagree with your premise that it is actually a different entity than Cernel, but am not trying to debate that on this list for various reasons.

Then why did you make the post?

Acting under my (incorrect or correct) assumption that they are in fact the same entity, I made my post to show that "the boys were back".

They are separate entities, and Cernal hosts with other providers, and
did so while Atrivo existed as well.

Infact, read below for some poignant analysis on this fact.

That is, for a decent amount of time, parts of 85.255.112.0/20 were not being advertised, and hence the dns hijacking pointing selected http traffic to 67.210.0.0/20 wasn't happening.

My point was that it (fairly) recently started being advertised again, and it was the same old song and dance wrt dns/http hijacking/fraud.

That doesn't surprise me, but I see it coming from Amazon EC2. Infact,
traceroutes end at 67.210.14.1, which is a router servicing the EC2
cloud. 85.255.112.0/20 appears to be announced by Bandcon /
Internet-Path in the NYC area. I believe that Amazon EC2's NYC cloud
uses these providers, but not 100% sure on that one.

Regardless, Amazon EC2 is not Atrivo, at all, period, and if you believe
that it is, you're bloody crazy.

William

7

Well, I just want to reach SORBS to clear up some confusion regarding
what ranges of mine are dynamic (e.g. none of them, but they seem to
think otherwise). Unfortunately, e-mail to SORBS bounces due to
ethr.net being listed in ASPEWS as being "part of Atrivo".

I think it is kind of fail that RBL people do not have e-mail based
contact addresses. Snoozenet is unpleasant to deal with.

William

8

So write to her from a gmail account. APEWS is pretty kooky, and I'm kind of surprised if SORBS is using it.

9

William Pitcock wrote:

10

More like "pay our ransom or FOAD". Why I never use them....

11

John R. Levine wrote:

So write to her from a gmail account. APEWS is pretty kooky, and I'm kind of surprised if SORBS is using it.

We use ASPEWS not APEWS (there is a vast cookiness difference).

Shells

12

Seth Mattinen wrote:

You should still be able to submit a ticket to SORBS, no? I was always under the impression that it was "open a ticket and wait or you are moved to the back of the line" with SORBS.

That is correct on all counts. The ticket engine is web based and has an interface to email, so anyone listed on ASPEWS (or any other DNSbl we use) can still report issues with ASPEWS (for our continual evaluation on whether to use it) as well as log support tickets and issues about SORBS listings.

The initial reply from the support ticket will give you an email and password that will allow you to login to the support interface.

Regards,

Michelle

13

John Levine wrote:

ASPEWS is listing 216.83.32.0/20 as being associated with the whole
Atrivo incident of 2008. My memory does not recall 216.83.32.0/20 being
involved, nor the provider that belongs to.
     

Since nobody but the occasional highly vocal GWL uses ASPEWS,
   
Guess I'm a highly vocal GWL then .. :wink: (what ever GWL means)

Shells

14

Michelle Sullivan wrote:

Seth Mattinen wrote:

You should still be able to submit a ticket to SORBS, no? I was always under the impression that it was "open a ticket and wait or you are moved to the back of the line" with SORBS.

That is correct on all counts.

Oh and to re-iterate a point made so many times in so many forums and so often ignored. Posting to any of my email personal addresses will not help your case at all.. ever.. in any way... and in fact posting to some of the old and disused ones will likely cause a spamtrap listing. SORBS Support is done through the SORBS support system (which is what it is there fore funnily enough!) Posting on mailing lists, or emailing to me, other SORBS staff, or GFI will result in various responses from completely ignoring you to sending you a PDF that tells you that you can only gain support through the SORBS support system - NO EXCEPTIONS. The only thing my email address is valid for is if the SORBS Support system is down for telling me such (and I have plenty of systems monitoring all components of it so an email is pretty pointless in most cases.) Robot rejection and refusal to delist is not a failure in the support system... Read the response and act upon the contents if you want a review.

Sorry if that sounds harsh, but when you had seen even a couple of the idiotic messages I get, you'll understand why. Logging a ticket is simple if a little ownerous (it takes 7 clicks to get a ticket logged, 3 if you use the contact form!)

Michelle

PS: Here is an example or 5 of tickets logged in the support system (unedited except for the last) and all in the queue that specifically states "do not send listing or delisting requests here"...

15

Name: www.googleadservices.com
Address: 67.210.14.113

That is Cernal, and it is hosted in Russia now.

not unless 'russia' moved a whole lot closer to 'ashburn,va' in the
last little while (or wormhole network technology is available)

4 0.xe-4-2-0.BR1.IAD8.ALTER.NET (152.63.32.161) 8 ms
0.xe-7-3-0.BR1.IAD8.ALTER.NET (152.63.32.158) 6 ms
0.xe-4-2-0.BR1.IAD8.ALTER.NET (152.63.32.161) 10 ms
5 194.25.211.17 (194.25.211.17) 7 ms 8 ms 7 ms
6 217.239.40.38 (217.239.40.38) 13 ms 12 ms 24 ms
7 217.6.49.126 (217.6.49.126) 12 ms 15 ms 12 ms
8 67-210-14-113-rev.ineting.net (67.210.14.113) 15 ms 14 ms 15 ms

(note upstream here is DT)

Cernal and Atrivo are two different entities, Atrivo used to host
Cernal, but now they have different hosting arrangements.

85.255.114.0/24 today routes:
5 0.xe-9-0-0.BR1.IAD8.ALTER.NET (152.63.41.49) 8 ms 6 ms
0.xe-10-0-0.BR1.IAD8.ALTER.NET (152.63.41.149) 8 ms
6 dcp-brdr-02.inet.qwest.net (63.146.26.105) 9 ms 9 ms 10 ms
7 dcx-core-01.inet.qwest.net (205.171.251.33) 10 ms 14 ms 10 ms
8 cer-core-01.inet.qwest.net (67.14.8.202) 30 ms
cer-core-02.inet.qwest.net (67.14.8.22) 28 ms
cer-core-01.inet.qwest.net (67.14.8.202) 29 ms
9 chx-edge-02.inet.qwest.net (205.171.139.61) 172 ms 32 ms
chx-edge-02.inet.qwest.net (205.171.139.57) 30 ms
10 63.146.238.218 (63.146.238.218) 29 ms 29 ms 30 ms

(note QWest is the upstream)

Right, two different ASN's originating prefixes, they seem to have
different 'locations' (or connections to networks in two different
tier-1 cities (chicago based on naming vs nyc-area based upon rtt)

The two entities seem to have a very tightly linked business though,
and have for quite some time.

Can people get a clue and understand this very critical difference?

sure, the difference being the act of changing names on top level
entities every period of time ('names will be changed to protect the
innocent') and providers as the providers notice sales folk did 'bad'
things..

It doesn't help to say things like: "Thats hosted in russia" when
clearly it is not... it also doesn't help to try and separate the 2
clearly inseparable entities.

-chris

16

Hi,

Michelle Sullivan wrote:
> Seth Mattinen wrote:
>>
>> You should still be able to submit a ticket to SORBS, no? I was
>> always under the impression that it was "open a ticket and wait or
>> you are moved to the back of the line" with SORBS.
>
> That is correct on all counts.
Oh and to re-iterate a point made so many times in so many forums and so
often ignored. Posting to any of my email personal addresses will not
help your case at all.. ever.. in any way... and in fact posting to some
of the old and disused ones will likely cause a spamtrap listing. SORBS
Support is done through the SORBS support system (which is what it is
there fore funnily enough!) Posting on mailing lists, or emailing to
me, other SORBS staff, or GFI will result in various responses from
completely ignoring you to sending you a PDF that tells you that you can
only gain support through the SORBS support system - NO EXCEPTIONS. The
only thing my email address is valid for is if the SORBS Support system
is down for telling me such (and I have plenty of systems monitoring all
components of it so an email is pretty pointless in most cases.) Robot
rejection and refusal to delist is not a failure in the support
system... Read the response and act upon the contents if you want a review.

Sorry if that sounds harsh, but when you had seen even a couple of the
idiotic messages I get, you'll understand why. Logging a ticket is
simple if a little ownerous (it takes 7 clicks to get a ticket logged, 3
if you use the contact form!)

Perhaps people wouldn't have to email you if the robot actually did what
it said it was going to do. Your website promises that the robot will
get things delisted out of the DUHL zone in "3 to 5 hours".

It has been more than "3 to 5 hours", and it is costing me money.
Considering that you shouldn't have listed the space to begin with, I
think it would be fantastic if you updated the website to reflect the
reality of the situation.

While I am sorry to hear that most of the people you deal with are
morons, it does not change the facts that SORBS listed IP address space
for no valid reason, other than the first version of the RDNS not
having .static. in it.

Perhaps if this sort of thing didn't keep happening, on a regular basis,
we would never hear about SORBS, MAPS, or any other RBLs on NANOG in a
bad light.

Personally, I like SORBS. I would like to continue to be able to use
SORBS on my mail servers. The fact that my addresses are listed as
being dynamic in SORBS when they are not, and it hasn't been fixed in
the timeframe that the website promises it would be fixed in, is making
me re-evaluate whether or not I should use SORBS and recommend it to
people looking for good DNSBLs to use on their mailservers.

NO I DO NOT ACCEPT DELISTING REQUESTS OUT OF THE SUPPORT SYSTEM!

Then you should make your delisting process more streamlined. You
already have a robot for most things, make it do the next step and just
delist the IP ranges it is given.

William

17

William wrote:

Hi,

Perhaps people wouldn't have to email you if the robot actually did what
it said it was going to do. Your website promises that the robot will
get things delisted out of the DUHL zone in "3 to 5 hours".
   
Please feel free to show me *any* SORBS webpage that says this because the robot cannot delist you, it just approves you for delisting.

It has been more than "3 to 5 hours", and it is costing me money.
Considering that you shouldn't have listed the space to begin with, I
think it would be fantastic if you updated the website to reflect the
reality of the situation.
   
Then tell me where it says 3-5 hours and I'll correct the text.

While I am sorry to hear that most of the people you deal with are
morons, it does not change the facts that SORBS listed IP address space
for no valid reason, other than the first version of the RDNS not
having .static. in it.
   
The robot doesn't list or delist so the entry was added at some point because of either spam, or it's an old entry that has not had any requests to update. The robot will reject certain patterns of DNS, you can always reply to the ticket as the whois contact to get delisted outside of what the robot says (as it says in the robot reply) thought it should be noted that I don't care who contacts me, if the rDNS is clearly dynamic (eg: <some>.<ip>.dyn.<domain>.<tld>) you're not going to get delisted at all.

Perhaps if this sort of thing didn't keep happening, on a regular basis,
we would never hear about SORBS, MAPS, or any other RBLs on NANOG in a
bad light.

Personally, I like SORBS. I would like to continue to be able to use
SORBS on my mail servers. The fact that my addresses are listed as
being dynamic in SORBS when they are not, and it hasn't been fixed in
the timeframe that the website promises it would be fixed in, is making
me re-evaluate whether or not I should use SORBS and recommend it to
people looking for good DNSBLs to use on their mailservers.

> NO I DO NOT ACCEPT DELISTING REQUESTS OUT OF THE SUPPORT SYSTEM!

Then you should make your delisting process more streamlined. You
already have a robot for most things, make it do the next step and just
delist the IP ranges it is given.
   
The process has been more and more streamlined as time has progressed. The support system will ask questions and will allow you to either delist or request delisting very easily. If you are an ISP you can (at the moment) use the mail/contact form to submit a request to the manual queue immediately... and anyone can send requests by email to the support system bypassing the whole "we'll gather the information via a web form" script, but the robot will reply, and if you do not meet the acceptance criteria by the robot you need to read the message and act upon it (eg: it will usually tell you to reply to the ticket after correcting something). In your case I have reviewed the address space and I see the robot will approve it for delisting, no questions (or should do) however it will have replied with something like the following:

18

Michelle Sullivan(matthew@sorbs.net)@Mon, Dec 14, 2009 at 11:32:48AM +0100:

William wrote:

Hi,

Perhaps people wouldn't have to email you if the robot actually did what
it said it was going to do. Your website promises that the robot will
get things delisted out of the DUHL zone in "3 to 5 hours".

Please feel free to show me *any* SORBS webpage that says this because
the robot cannot delist you, it just approves you for delisting.

It has been more than "3 to 5 hours", and it is costing me money.
Considering that you shouldn't have listed the space to begin with, I
think it would be fantastic if you updated the website to reflect the
reality of the situation.

Then tell me where it says 3-5 hours and I'll correct the text.

On http://www.au.sorbs.net/cgi-bin/support , I read:
"This will route any created ticket to the robot handler which will
process and delist the netblock (upto /24) within a few hours"

That says the robot will delist (not schedule to delist) "within a few
hours".

19

<snip>

I'm a robot writing you on behalf of the SORBS' admins. The reason
you're getting this automated response, is our desire to provide you
with consistent and fast responses. I'm prepared to correctly analyze
most of the cases appearing in the DUHL queue.

<snip>

This last sentence seems to be my point of contention here. I am trying
to get a /18 removed from the DUHL and every time the robot tells me
some arbitrary ranges I did not mention explicitly are being tested
and/or not eligible for delisting. Since the ranges not eligible are
configured the same as those that are, I can't figure this out.
Replying to the robot resulted in no response for a month, so I ended up
submitting a ticket via the ISP contact form directly, with all the
information requested, but the first time, someone just pushed my
request back to the robot and it refused ranges again.

I understand you get a lot of traffic to your ticket system, but I have
to wonder whether a system which is so complex and large that it is near
impossible to support and keep maintained accurately is actually still
useful. I assume you love (to some degree) helping kill spammers, but
maybe you need to solicit (screened) volunteers to expand your staffing?

20

And then you take several days if not several weeks to delist them.

You have spent a considerably longer time replying to people on NANOG
discussing your policies on NANOG, when you could just delist the IPs in
question already.

Like I said before, I am sorry that you deal with a lot of morons, but
maybe like others have said, you need to add more staff to your project.

William