This is puzzling me. If it's from non-announced space, at some point some router should report no route to it. How is the TCP handshake performed to allow a sync to turn into spam?
Chuck
Chuck Church
Network Planning Engineer, CCIE #8776
Harris Information Technology Services
DOD Programs
1210 N. Parker Rd. | Greenville, SC 29609
Office: 864-335-9473 | Cell: 864-266-3978
Unallocated is not the same as unannounced.
Unallocated doesn't mean non-routed. All a spammer needs is a willing/non-filtering provider doing BGP with them, and they can announce any space they like, send out some spam, and then pull the announcement. Next morning, when you see the spam and try to figure out who to send complaints to, you're either going to complain to the wrong people or find that whois is of no help.
Seen it before - but mostly for malware rather than for spam. And
certainly not long enough / persistent enough for a full fledged spam
campaign (4..5 days rather than a day or two at the most when people
start noticing and dropping the bogus announcement)
Yes, unallocated (at least according to ARIN's whois db) but not unannounced - obviously our network can get to the space or else I wouldn't be having a spam problem with them! I'm actually seeing this /20 as advertised through Savvis from AS40430
It seems to me like the best solution might be a semi-hacky solution of asking arin (and other IRR's) if i can copy its DB and creating an internal peer which null routes unallocated blocks (updated nightly?)
Has anyone seen an IRR's DB's not being updated for more than 30 days after allocations? I always assumed that they are quickly updated.
Thanks again,
Leslie
Jon Lewis wrote:
Ah, colo4jax I see. Jacksonville, Florida.
68.234.16.0/20 shows up as unallocated but as these guys own the
previous /20 its probably a stale arin db and a brand new allocation
Prefix AS Path
Aggregation Suggestion
68.234.0.0/20 4777 2497 25973 40430
68.234.16.0/20 4608 1221 4637 3561 40430
69.174.96.0/21 4777 2497 25973 40430
173.205.80.0/20 4777 2497 25973 40430
204.237.184.0/21 4777 2497 25973 40430
204.237.192.0/22 4777 2497 25973 40430
208.153.96.0/22 4777 2497 25973 40430
208.169.228.0/22 4777 2497 25973 40430
Note, ARIN is an RIR, a regional internet registry, which is what I
presume you meant there. Nevertheless, while it might be worth a try
from a research perspective, it may be a bit risky in a production
environment. In addition, someone may announce a more specific so keep
that scenario in mind. The CIDR Report monitors RIR allocation data.
This may be of interest to you:
<http://www.cidr-report.org/bogons/rir-data.html>
You can get access to that allocation data as noted here:
<https://www.arin.net/knowledge/statistics/rir.html>
John
Leslie wrote:
[..]
It seems to me like the best solution might be a semi-hacky solution of
asking arin (and other IRR's) if i can copy its DB and creating an
internal peer which null routes unallocated blocks (updated nightly?)
What you want to take is:
$rirs = array(
"afrinic" =>
"ftp://ftp.ripe.net/pub/stats/afrinic/delegated-afrinic-latest",
"apnic" =>
"ftp://ftp.ripe.net/pub/stats/apnic/delegated-apnic-latest",
"arin" =>
"ftp://ftp.arin.net/pub/stats/arin/delegated-arin-latest",
"lacnic" =>
"ftp://ftp.ripe.net/pub/stats/lacnic/delegated-lacnic-latest",
"ripe" =>
"ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest",
"brnic" =>
"ftp://ftp.registro.br/pub/stats/delegated-ipv6-nicbr-latest",
//// Avoid broken/slow servers:
//// "afrinic" =>
"ftp://ftp.afrinic.net/pub/stats/afrinic/delegated-afrinic-latest",
//// "apnic" =>
"ftp://ftp.apnic.net/apnic/stats/apnic/delegated-apnic-latest",
//// "lacnic" =>
"ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-latest",
);
Yes, generally the latter three are broken, but as they are mirrored to
RIPE anyway, you can just pull them off there.
Then you have all IPv4 and IPv6 delegated blocks. If it is not in there,
it is a bogon. Yes, those are updated only once in a day or so, thus if
some one is going to start using the block before it is published in
those files you will get some false-positives, but then ask the question
why they get a block up so quickly and start spamming you in the first
place.....
Those /stats/ dirs contain other useful things btw.
Greets,
Jeroen
You may want to take a look at what is going on in the SIDR working group if you want something similar to this.
- Jared
It seems to me like the best solution might be a semi-hacky solution of
asking arin (and other IRR's) if i can copy its DB and creating an
internal peer which null routes unallocated blocks (updated nightly?)What you want to take is:
$rirs = array(
"afrinic" =>
"ftp://ftp.ripe.net/pub/stats/afrinic/delegated-afrinic-latest",
"apnic" =>
"ftp://ftp.ripe.net/pub/stats/apnic/delegated-apnic-latest",
"arin" =>
"ftp://ftp.arin.net/pub/stats/arin/delegated-arin-latest",
"lacnic" =>
"ftp://ftp.ripe.net/pub/stats/lacnic/delegated-lacnic-latest",
"ripe" =>
"ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest",
"brnic" =>
"ftp://ftp.registro.br/pub/stats/delegated-ipv6-nicbr-latest",//// Avoid broken/slow servers:
//// "afrinic" =>
"ftp://ftp.afrinic.net/pub/stats/afrinic/delegated-afrinic-latest",
//// "apnic" =>
"ftp://ftp.apnic.net/apnic/stats/apnic/delegated-apnic-latest",
//// "lacnic" =>
"ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-latest",
);
this is brilliant. maybe we should form an org to do this and
distribute via bgp? shall we have a contest for the name of the org?
my bid is cymru
randy
Randy Bush wrote:
It seems to me like the best solution might be a semi-hacky solution of
asking arin (and other IRR's) if i can copy its DB and creating an
internal peer which null routes unallocated blocks (updated nightly?)What you want to take is:
$rirs = array(
"afrinic" =>
"ftp://ftp.ripe.net/pub/stats/afrinic/delegated-afrinic-latest",
[..]
this is brilliant. maybe we should form an org to do this and
distribute via bgp? shall we have a contest for the name of the org?
my bid is cymru
Who have it already indeed for a long long time and have a proven track
record.
I noted the above for the people who want to get their own copy from the
IRRs, like what was asked above. For instance for the few who want to
build their own setups, want to integrate it in their own systems etc.
Greets,
Jeroen
I can't see anything on their site that provides a BGP feed of prefixes allocated by RIRs, which I think is what we're talking about here.
We currently provide A BGP bogon route server feed for the asking,
which are routes of 'well known' aggregate prefixes published by IANA as
well as special and reserved netblocks documented by a IETF that should
not be seen on the public net.
Providing a feed of allocations would be the opposite approach of
course.
I suppose if there is interest and a need we could do this. Shoot
myself or the team (info@cymru.com) a note off list if you have
thoughts on the matter or simply want to provide some feedback into
such a service and how it might best be used. We're always on the look
out for things we can do to help.
John
Just FYI the colo4jax guys got back to me and it is a stale ARIN db entry - I guess they don't update it as quickly as I thought. So this is now just a normal case of spam.
Leslie
Leslie wrote:
John Kristoff wrote:
Leslie wrote:
John Kristoff wrote:
I suppose if there is interest and a need we could do this. Shoot
myself or the team (info@cymru.com) a note off list if you have
thoughts on the matter or simply want to provide some feedback into
such a service and how it might best be used. We're always on the look
out for things we can do to help.My big issue isn't the larger blocks, it's the smaller unallocated
blocks - which anyone with a not-too-strict transit provider could
easily steal and abuse. Getting the allocated space is just another way
of finding the smaller unallocated blocks (with a bit of extra work)
The problem though with BGP is that when you have say a NonAllocatedFeed
containing 10.0.0.0/8 then when somebody else announced 10.1.2.0/24 (or
any other more specific) it will perfectly work. Unless you are able to
pull of some tricks in hardware based routers (software based ones you
can of course modify to do whatever you want but might not be the right
thing to run in some scenarios).
As such, pulling the delegated files and generating prefix filters
yourself, which you most likely have anyway for things like blackholing
prefixes you otherwise also don't want to talk too....
And don't forget to source-filter those prefixes too 
Greets,
Jeroen
//// Avoid broken/slow servers:
//// "afrinic" =>
"ftp://ftp.afrinic.net/pub/stats/afrinic/delegated-afrinic-latest",
//// "apnic" =>
"ftp://ftp.apnic.net/apnic/stats/apnic/delegated-apnic-latest",
//// "lacnic" =>
"ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-latest",
);Yes, generally the latter three are broken, but as they are mirrored to
RIPE anyway, you can just pull them off there.
Having checked with Jeroen, I would like to observe that in the case of APNIC this is almost certainly IPv6 and pMTU problems.
As he observes elsewhere in the email, we all shadow each others data in the FTP trees so you can very probably choose one RIR, and use it as a fetch-point for all of this data.
BTW The last time this cropped up in any public eye facing NANOG type people it was the rfc editor. It can happen to anyone. Geoff wrote it up at:
So, this is not APNIC having "broken" FTP, its the innate problem of IPv6 in the wild.
If you fall back to V4, the fetch works just fine. If tomorrow you have problems fetching the stats from ARIN or RIPE, you might want to look at your path..
-George
Just in case anyone's curious - The prefix still hasn't been updated in ARIN and I am still seeing tons of spam (grrr spammers and grr transit providers who don't filter advertisements of smaller customers)
I made a script which looks at our log files for ips that are unknown, double checks them against live database, and then reports the number of hits to me - that way I can at least take manual action against offenders. On the good side, the only offender I currently see is 40430, but I am still trying to remain vigilent for future spammers
Leslie
Leslie wrote: