http://threatpost.com/en_us/blogs/attackers-buying-own-data-centers-botnets-spam-122109
It this something new ? The article seems to mix various issues together.
And this would seem highly inefficient to me compared to traditional
botnets (renting your own rack for a botnet doesn't really make sense 
Comments ?
Sounds like a snowshoe setup to me.
Tony.
With the added refinement of spammer / botmaster controlled LIRs ..
after spammer / botmaster controlled registrars.
I did wonder sometimes how some snowshoe spammers could keep acquiring
a series of /20 to /15 sized CIDRs over the past year or two.
I don't see how going to jump.ro, getting a bunch of IP assignments, and then setting those IPs up on a server or few servers in the US = "attackers buying own data centers".
I am curious how both jump.ro and the other RIPE region LIRs involved in assigning the space and the US based networks that have been involved routing it justify assigning/routing "Assigned PA" space to "customers" who only use that space in their US operations (which in the cases I've seen have primarily been high volume email deployment).
According to http://www.ripe.net/ripe/docs/ipv4-policies.html
ASSIGNED PA: This address space has been assigned to an End User for use
with services provided by the issuing LIR. It cannot be kept when
terminating services provided by the LIR.
Should US based networks be willing to route RIPE "ASSIGNED PA" space customers provide?
this is an interesting question, which when I worked for an ISP I
always wondered about. In fact, when we'd see solely based US
customers asking for this sort of thing it often meant shortly there
after we'd see complaints of TOS/AUP violations. There doesn't seem to
be a hard/fast rule about this though (the 'is it right to permit this
activity'), but there sure is quite a bit of it going on, eh?
-Chris
Christopher Morrow wrote:
Should US based networks be willing to route RIPE "ASSIGNED PA" space
customers provide?
Are any of your customers multinationals?
this is an interesting question, which when I worked for an ISP I
always wondered about. In fact, when we'd see solely based US
customers asking for this sort of thing it often meant shortly there
after we'd see complaints of TOS/AUP violations. There doesn't seem to
be a hard/fast rule about this though (the 'is it right to permit this
activity'), but there sure is quite a bit of it going on, eh?
Last two companies I have worked with, through a combination of organic
growth, aquistion and partnership have a rather complex mix of PA,
Legacy, RIR assignments in 4 regions, LIR assignments, and so forth. it
would be fairly normal in the course of service delivery to customers to
advertise prefixes obtained in one region in one or more other regions.
One of these entities has a global IP backbone, the other glues it
altogether with vpns, appart from scale they're not really that different.
They may be. I don't agree that it's relevant. You can disagree with the RIPE wording or with RIPE policies, or maybe I'm misinterpreting
ASSIGNED PA: This address space has been assigned to an End User for use
with services provided by the issuing LIR. It cannot be kept when
terminating services provided by the LIR.
My interpretation of the above is ASSIGNED PA is the equivalent of my assigning IP space to a customer who either buys transit (connectivity) from us or colo's or buys server hosting from us where they will use that IP space. We don't simply lease out IP space for "customers" to use as they please on other networks. We do have customers who are multihomed to whom we've assigned IP space, and they announce those IPs via BGP to us and other transit providers.
What I've seen recently with jump.ro and other RIPE region LIRs looks like the LIRs are effectively selling/renting (whatever you want to call it) "ASSIGNED PA" IP space to spammers who announce it using single homed ASNs in the US.
As an End User in the RIPE region, if you need/want PI space, are you not able to get that directly from RIPE?
The previously mentioned page is confusing to me in its coverage of that question.
The RIPE NCC no longer allocates PI address space. Consequently, many
LIRs do not have PI allocations from which to make PI assignments. If an LIR
has an End User that requires PI address space they are able to support
them by sending these requests to the RIPE NCC on behalf of the End User.
This support includes helping End Users prepare a properly documented
request. The RIPE NCC will make PI assignments when justified.
RIPE no longer allocates PI space. If an LIR has an End User that requires PI space and the LIR doesn't have any PI left to give out, they can help that End User apply to RIPE.
This implies RIPE still does "assign" PI space to end users...and if you need PI IP space and are eligible to deal with RIPE, you should be getting it from them.
So, if you're not multihomed with jump.ro as one of your providers, is it appropriate for them to sell you ASSIGNED PA space which you'll use elsewhere? I don't think so.
Should US based networks be willing to route RIPE "ASSIGNED PA" space
customers provide?
I would argue not and the bofh in me would be inclined to announce more
specifics if I saw someone announcing my PA space from another ASN. But
I'm more into the ixp sort of thing these days rather than isps.
My interpretation of the above is ASSIGNED PA is the equivalent of my
assigning IP space to a customer who either buys transit (connectivity)
from us or colo's or buys server hosting from us where they will use
that IP space.
ASSIGNED PA space is intended to be announced by the provider which
operates the LIR only (i.e. the space is associated with the provider).
It's not intended for multihoming, and if you want multihoming space, you
need PI address space.
As an End User in the RIPE region, if you need/want PI space, are you
not able to get that directly from RIPE?
You can get it directly from the RIPE NCC, but it's more usual to get it
via your provider's LIR, the important word being "via". The LIR just
passes on your request form.
The RIPE NCC is very specific about the language used here. In the context
of all RIPE docs and policies, "allocate" means to bulk-delegate resources
to a LIR. "assign" is the process of delegating the address space to the
end-user, whether that end-user is a customer or the provider itself.
So, when the RIPE NCC says:
The RIPE NCC no longer allocates PI address space.
... what they mean is that they no longer delegate bulk blocks of PI
address space to LIRs so that the LIR can then assign the address space to
end-users.
Instead, what happens these days is:
[...]The RIPE NCC will make PI assignments when justified.
i.e. if you want a PI block, you fill out a form, send it to your LIR, who
sends it to the RIPE NCC. The NCC will then register the address space to
the end-user.
So, if you're not multihomed with jump.ro as one of your providers, is
it appropriate for them to sell you ASSIGNED PA space which you'll use
elsewhere? I don't think so.
it is completely inappropriate at many levels - imo.
Nick
[...]
They may be. I don't agree that it's relevant. You can disagree with the
RIPE wording or with RIPE policies, or maybe I'm misinterpretingASSIGNED PA: This address space has been assigned to an End User for use
with services provided by the issuing LIR. It cannot be kept when
terminating services provided by the LIR.My interpretation of the above is ASSIGNED PA is the equivalent of my
assigning IP space to a customer who either buys transit (connectivity)
from us or colo's or buys server hosting from us where they will use that
IP space. We don't simply lease out IP space for "customers" to use as
they please on other networks.
I am sure that your interpretation was the original intent of the policy
text. However, the wording could also be read in a way that allows an LIR to
just provide registry services, without providing any connectivity services.
Regards,
Leo
What would you do if a shell company (the european equivalent of a LLC
with a UPS store address) came to you with a large sized PA netblock
from out of region, and asked you to route it for them?
I might as well reply to this here. The folks from threatpost had me talk at length about the various issues with doing cybercrime enforcement and how things have changed, and they picked that section for their post.
My key point I wanted to hammer home was that most of the modern botnets (and/or malware that has phone home capability) have a much more stable infrastructure, as more and more of the hosting pieces are controlled by the bad guys.
In the old days you'd see C&C servers running from popped boxes, but now you're seeing the criminals renting their own servers from xyz datacenter, or worse, buying their own racks/cages and going to an LIR or RIR to get direct IP allocations. They then rent out those allocations to other shell companies (or possibly to other criminals) and handle the abuse notifications on the frontend. Since these data centers have many transit options, nullrouting an ip block at a single ISP hasn't been very effective. And of course, getting an RIR to revoke IP space only happens if you don't pay the bills. A year after allocation the blocks are pretty much burned anyways, so that's not a real barrier. There doesn't even seem to be any policies against intentional fraudulent SWIPing of IP space, or at least, not one that's enforced. The Knujon guys have had some success in the domain space, maybe this could happen in the ip world as well?
The only technical statement in there that I think was misinterpreted was the "owning your own ip space makes you an isp" which I clearly didn't mean. It's a quote so I must have said it but it must I think I had some qualifiers in there in that I was talking about the abuse desks at an ISP. If they are the ISP they claim it was a downstream customer and that they've fixed the issue, when really it's their own stuff that they shuffle around.
Regards,
Alex Lanstein
So, if you're not multihomed with jump.ro as one of your providers, is
'multihomed' here could mean: "we have an IPSEC vpn, we need to use
globally unique ip space, we may have exit points (and have space
routed by other providers from this block), but we'll anchor things
here in your datacenter in elbonia, ok?"
it appropriate for them to sell you ASSIGNED PA space which you'll use
elsewhere? I don't think so.
'sell you ASSIGNED PA' or 'Assign to you as a customer ASSIGNED PA' ?
(cause 'selling ip space' is still officially verboten, eh?)
it is completely inappropriate at many levels - imo.
agreed, it's at least a management headache, and aside from very
obvious large multi-nationals (joel's examples) every time I've seen
it done it was by 'bad actors'... In fact I think I had a conversation
with an install engineer that went something like:
"You really thought ip space assigned to a ukranian company in the
ukraine was 'ok' for you to route to a customer in tampa, fla??"
-chris
Not that I need to do so, but I might as well -- I know Alex pretty well,
as both a trusted colleague & friend, and he is spot on in his assessment
here. If anything, he was mild in his criticizes -- this type of criminal
"diversification" has been the standard bat-and-switch method of operation
for several years now.
The criminals -- especially the professional Eastern Europeans -- have
become quite adept in their campaigns of registering domains, obtaining IP
address space, hosting facilities, etc., and are quite successful in their
criminal endeavors.
Folks should not be so obtuse about these activities. It's almost blatantly
in-your-face, so to speak. These guys have no fear of retribution.
$.02,
- - ferg
no real arguement, but... 'please provide some set of workable solutions'
The ARIN meetings (at least) are open, please come and help guide
policies. I'm sure RIPE also wouldn't mind a discussion, if there
could be some positive policy outcome.
-Chris
Folks should not be so obtuse about these activities. It's almost
blatantly in-your-face, so to speak. These guys have no fear of
retribution.no real arguement, but... 'please provide some set of workable solutions'
First question: Solution(s) for which problem(s)?
The ARIN meetings (at least) are open, please come and help guide
policies. I'm sure RIPE also wouldn't mind a discussion, if there
could be some positive policy outcome.
Frankly, there simply is not enough hours in the day for what I already do,
and trying to add "policy foo" to my laundry list of stuff just isn't going
to happen.
Many of us have already tried to engage ICANN on domain registration issues
(primarily bad registrars and policy cruft), as well as RIRs, etc., to no
avail.
I've simply given up on trying to make a dent in policy issues because
profit trumps everything else, plus -- as I said -- I just have no spare
cycles.
I have taken a different set of tactics to go after criminal activities...
policy stuff doesn't work.
- - ferg
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Folks should not be so obtuse about these activities. It's almost
blatantly in-your-face, so to speak. These guys have no fear of
retribution.no real arguement, but... 'please provide some set of workable solutions'
First question: Solution(s) for which problem(s)?
ideally the 'bad folks get ip space' (which was part of the initial
thrust of the thread)
Many of us have already tried to engage ICANN on domain registration issues
(primarily bad registrars and policy cruft), as well as RIRs, etc., to no
avail.
some headway was made, some more may still come. It's certainly not
'fast' though
I've simply given up on trying to make a dent in policy issues because
profit trumps everything else, plus -- as I said -- I just have no spare
cycles.
If the, for the ip space issue, main problem can't be solved without
policy this seems like abdication, no?
I have taken a different set of tactics to go after criminal activities...
policy stuff doesn't work.
also good... except that the only real fix for some of this is policy
things, I fear.
IP-address issues can't get solved without policy changes, which
happen today via community consensus. Domain-name issues have to get
hammered out from the top down (with some policy that allows
registries to impose change on registrars. This DNS issues may also
get resolved with action coming from ICANN (hope springs eternal).
-Chris
Well, I have to say I'm somewhat pessimistic that ICANN really cares about
what security issues evolve from their "policy" failures. If history is any
lesson, it should teach us that ICANN cares more about expanding the TLD
space to the point where it can be abused infinitely.
Having said that, ICANN is not IANA, and the last time I checked, IANA had
some measure of influence in the policies that the RIRs operated within...
or is that the role of yet another level of obfuscation (policy authority)?
I think you see my point...
It's just unworkable as things stand, and rife with abuse -- the policy
loopholes allow these commercial entities to reap the benefits of huge
profits, while allowing criminals to also share in the same benefits.
$.02,
- - ferg
The set of workable solutions at this point looks something like "null
routes, firewall rules, blacklist entries" -- in order to deny traffic
to and from such locales.
I agree just about entirely with Ferg: the policy angle is a dead end.
The organizations involved are either clueless or entirely focused on
other goals (e.g., profit) at the expense of sound policy.
---Rsk
Rich Kulawiec wrote:
no real arguement, but... 'please provide some set of workable
solutions'The set of workable solutions at this point looks something like
"null routes, firewall rules, blacklist entries" -- in order to deny
traffic to and from such locales.I agree just about entirely with Ferg: the policy angle is a dead
end. The organizations involved are either clueless or entirely
focused on other goals (e.g., profit) at the expense of sound policy.
Gosh, there's no way I can create this public good, because someone
somewhere will use it in the commission of a crime notwithstanding all
the benefits it confers.
I'll just throw down props to Paul Samuelson since he's no longer with
us and leave it at that.
Rather than expecting anti-spam researchers to lobby at ARIN & RIPE meetings, perhaps ARIN & RIPE representatives could visit anti-spam meetings such as MAAWG to ask how they can help?
I'd be happy to make some introductions.