Getting fraudulent entries removed
Hi, We've run into an issue where an unknown malicious party appears to have hijacked some of our IP space. They created entries in the RIPE database that they are using to actually get this space announced. What's even worse is their carrier is trying to say these announcements are legitimate because they have IRR entries (which is a whole other issue) What is the process like for actually getting this fraudulent entry removed? I've been in contact with RIPE NCC Support, and they have been super unhelpful (ref case #14523) The fraudulent entry is: https://apps.db.ripe.net/search/lookup.html?source=ripe&key=198.13.32.0/19AS... route: 198.13.32.0/19 descr: 2nd route origin: AS39967 mnt-by: ADMASTER-MNT created: 2017-10-13T00:20:08Z last-modified: 2017-10-13T00:20:08Z source: RIPE I should also note that this ASN suspiciously appears to be announcing other people's space as well, but I can only confirm that this particular entry does not belong. I would suspect that their other IRR entries are fake as well. You can verify my request by reaching out to any of the POCs associated with this network: https://whois.arin.net/rest/net/NET-198-13-32-0-1 Thanks, Brian Rak
Dear Brian, It appears that RIPE NCC is lacking a clear and expedient procedure to remedy unauthorised route object creation. I'd be happy to volunteer to work with the RIPE NCC to develop a procedure that aligns with industry standards on how to verify abuse reports like these and resolve them in a timely manner. (Of course this doesn't help you right now.) The topic of ARIN space in the RIPE database has been discussed extensively. A long thread on this topic started here https://www.ripe.net/ripe/mail/archives/db-wg/2017-October/005622.html, sadly, some people even indicated they don't see an issue with how things are right now https://www.ripe.net/ripe/mail/archives/db-wg/2017-October/005627.html Fortunately this was a minority view, and the RIPE NCC is now tasked to more clearly mark non-authoritative route objects as can be read here: https://www.ripe.net/ripe/mail/archives/routing-wg/2017-October/003456.html One thing I recommend you do is to set the "OriginAS" through the ARIN webinterface, this will show the world what the origin AS ought to be: https://www.arin.net/resources/originas.html. You could reference this field in your communication with RIPE NCC to demonstrate that the RIPE IRR version of the route object does not align with your intentions. Another thing you can do is file complaints with the upstreams of AS205869 (some of them visible here https://bgp.he.net/AS205869) Telia seems to be their main provider. Kind regards, Job On Thu, Nov 09, 2017 at 11:22:33AM -0500, Brian Rak via db-wg wrote:
Hi,
We've run into an issue where an unknown malicious party appears to have hijacked some of our IP space. They created entries in the RIPE database that they are using to actually get this space announced. What's even worse is their carrier is trying to say these announcements are legitimate because they have IRR entries (which is a whole other issue)
What is the process like for actually getting this fraudulent entry removed? I've been in contact with RIPE NCC Support, and they have been super unhelpful (ref case #14523)
The fraudulent entry is:
https://apps.db.ripe.net/search/lookup.html?source=ripe&key=198.13.32.0/19AS...
route: 198.13.32.0/19 descr: 2nd route origin: AS39967 mnt-by: ADMASTER-MNT created: 2017-10-13T00:20:08Z last-modified: 2017-10-13T00:20:08Z source: RIPE
I should also note that this ASN suspiciously appears to be announcing other people's space as well, but I can only confirm that this particular entry does not belong. I would suspect that their other IRR entries are fake as well.
You can verify my request by reaching out to any of the POCs associated with this network: https://whois.arin.net/rest/net/NET-198-13-32-0-1
Thanks, Brian Rak
On 11/9/2017 11:52 AM, Job Snijders wrote:
Dear Brian,
It appears that RIPE NCC is lacking a clear and expedient procedure to remedy unauthorised route object creation. I'd be happy to volunteer to work with the RIPE NCC to develop a procedure that aligns with industry standards on how to verify abuse reports like these and resolve them in a timely manner. (Of course this doesn't help you right now.)
The topic of ARIN space in the RIPE database has been discussed extensively. A long thread on this topic started here https://www.ripe.net/ripe/mail/archives/db-wg/2017-October/005622.html, sadly, some people even indicated they don't see an issue with how things are right now https://www.ripe.net/ripe/mail/archives/db-wg/2017-October/005627.html Fortunately this was a minority view, and the RIPE NCC is now tasked to more clearly mark non-authoritative route objects as can be read here: https://www.ripe.net/ripe/mail/archives/routing-wg/2017-October/003456.html
One thing I recommend you do is to set the "OriginAS" through the ARIN webinterface, this will show the world what the origin AS ought to be: https://www.arin.net/resources/originas.html. You could reference this field in your communication with RIPE NCC to demonstrate that the RIPE IRR version of the route object does not align with your intentions.
Another thing you can do is file complaints with the upstreams of AS205869 (some of them visible here https://bgp.he.net/AS205869) Telia seems to be their main provider. Thanks!
We'll look into setting OriginAS on these. We've been in contact with Telia. Telia is trying to use the presence of the RIPE IRR entry to try and justify not taking any actions. Their exact statement about this was: "According to the records on RADb, the prefix 198.13.32.0/19 is owned by both AS20473 and AS39967." I couldn't really facepalm hard enough after I got that email.
Kind regards,
Job
On Thu, Nov 09, 2017 at 11:22:33AM -0500, Brian Rak via db-wg wrote:
Hi,
We've run into an issue where an unknown malicious party appears to have hijacked some of our IP space. They created entries in the RIPE database that they are using to actually get this space announced. What's even worse is their carrier is trying to say these announcements are legitimate because they have IRR entries (which is a whole other issue)
What is the process like for actually getting this fraudulent entry removed? I've been in contact with RIPE NCC Support, and they have been super unhelpful (ref case #14523)
The fraudulent entry is:
https://apps.db.ripe.net/search/lookup.html?source=ripe&key=198.13.32.0/19AS...
route: 198.13.32.0/19 descr: 2nd route origin: AS39967 mnt-by: ADMASTER-MNT created: 2017-10-13T00:20:08Z last-modified: 2017-10-13T00:20:08Z source: RIPE
I should also note that this ASN suspiciously appears to be announcing other people's space as well, but I can only confirm that this particular entry does not belong. I would suspect that their other IRR entries are fake as well.
You can verify my request by reaching out to any of the POCs associated with this network: https://whois.arin.net/rest/net/NET-198-13-32-0-1
Thanks, Brian Rak
Hi guys Perhaps after the RIPE NCC implements the agreed actions on foreign ROUTE objects, it would be a good idea to do a (one time?) cleanup/review of all foreign ROUTE objects in the RIPE IRR. Find the contact details in the appropriate RIR Database for all non RIPE address space covered by these ROUTE objects. Send them a notification with a link to click if they approve of the ROUTE object. If no response is received within a defined time period, delete the ROUTE object. cheersdenisco-chair DB WG From: Job Snijders via db-wg <db-wg@ripe.net> To: Brian Rak <brak@choopa.com> Cc: db-wg@ripe.net Sent: Thursday, 9 November 2017, 17:53 Subject: Re: [db-wg] Getting fraudulent entries removed Dear Brian, It appears that RIPE NCC is lacking a clear and expedient procedure to remedy unauthorised route object creation. I'd be happy to volunteer to work with the RIPE NCC to develop a procedure that aligns with industry standards on how to verify abuse reports like these and resolve them in a timely manner. (Of course this doesn't help you right now.) The topic of ARIN space in the RIPE database has been discussed extensively. A long thread on this topic started here https://www.ripe.net/ripe/mail/archives/db-wg/2017-October/005622.html, sadly, some people even indicated they don't see an issue with how things are right now https://www.ripe.net/ripe/mail/archives/db-wg/2017-October/005627.html Fortunately this was a minority view, and the RIPE NCC is now tasked to more clearly mark non-authoritative route objects as can be read here: https://www.ripe.net/ripe/mail/archives/routing-wg/2017-October/003456.html One thing I recommend you do is to set the "OriginAS" through the ARIN webinterface, this will show the world what the origin AS ought to be: https://www.arin.net/resources/originas.html. You could reference this field in your communication with RIPE NCC to demonstrate that the RIPE IRR version of the route object does not align with your intentions. Another thing you can do is file complaints with the upstreams of AS205869 (some of them visible here https://bgp.he.net/AS205869) Telia seems to be their main provider. Kind regards, Job On Thu, Nov 09, 2017 at 11:22:33AM -0500, Brian Rak via db-wg wrote:
Hi,
We've run into an issue where an unknown malicious party appears to have hijacked some of our IP space. They created entries in the RIPE database that they are using to actually get this space announced. What's even worse is their carrier is trying to say these announcements are legitimate because they have IRR entries (which is a whole other issue)
What is the process like for actually getting this fraudulent entry removed? I've been in contact with RIPE NCC Support, and they have been super unhelpful (ref case #14523)
The fraudulent entry is:
https://apps.db.ripe.net/search/lookup.html?source=ripe&key=198.13.32.0/19AS...
route: 198.13.32.0/19 descr: 2nd route origin: AS39967 mnt-by: ADMASTER-MNT created: 2017-10-13T00:20:08Z last-modified: 2017-10-13T00:20:08Z source: RIPE
I should also note that this ASN suspiciously appears to be announcing other people's space as well, but I can only confirm that this particular entry does not belong. I would suspect that their other IRR entries are fake as well.
You can verify my request by reaching out to any of the POCs associated with this network: https://whois.arin.net/rest/net/NET-198-13-32-0-1
Thanks, Brian Rak
Hi, I don’t think a one-off will cut it. This is, and has to be, a continuous process. A “did you know this happened in RIPE IRR”-notification would be good when non-auth objects are created. Maybe RPKI ghostbuster and Whois context info can be used to find the appropriate block owners. Kind regards, Job On Thu, 9 Nov 2017 at 19:44, denis walker <ripedenis@yahoo.co.uk> wrote:
Hi guys
Perhaps after the RIPE NCC implements the agreed actions on foreign ROUTE objects, it would be a good idea to do a (one time?) cleanup/review of all foreign ROUTE objects in the RIPE IRR. Find the contact details in the appropriate RIR Database for all non RIPE address space covered by these ROUTE objects. Send them a notification with a link to click if they approve of the ROUTE object. If no response is received within a defined time period, delete the ROUTE object.
cheers denis co-chair DB WG
------------------------------ *From:* Job Snijders via db-wg <db-wg@ripe.net> *To:* Brian Rak <brak@choopa.com> *Cc:* db-wg@ripe.net *Sent:* Thursday, 9 November 2017, 17:53
*Subject:* Re: [db-wg] Getting fraudulent entries removed
Dear Brian,
It appears that RIPE NCC is lacking a clear and expedient procedure to remedy unauthorised route object creation. I'd be happy to volunteer to work with the RIPE NCC to develop a procedure that aligns with industry standards on how to verify abuse reports like these and resolve them in a timely manner. (Of course this doesn't help you right now.)
The topic of ARIN space in the RIPE database has been discussed extensively. A long thread on this topic started here https://www.ripe.net/ripe/mail/archives/db-wg/2017-October/005622.html, sadly, some people even indicated they don't see an issue with how things are right now https://www.ripe.net/ripe/mail/archives/db-wg/2017-October/005627.html Fortunately this was a minority view, and the RIPE NCC is now tasked to more clearly mark non-authoritative route objects as can be read here: https://www.ripe.net/ripe/mail/archives/routing-wg/2017-October/003456.html
One thing I recommend you do is to set the "OriginAS" through the ARIN webinterface, this will show the world what the origin AS ought to be: https://www.arin.net/resources/originas.html. You could reference this field in your communication with RIPE NCC to demonstrate that the RIPE IRR version of the route object does not align with your intentions.
Another thing you can do is file complaints with the upstreams of AS205869 (some of them visible here https://bgp.he.net/AS205869) Telia seems to be their main provider.
Kind regards,
Job
On Thu, Nov 09, 2017 at 11:22:33AM -0500, Brian Rak via db-wg wrote:
Hi,
We've run into an issue where an unknown malicious party appears to have hijacked some of our IP space. They created entries in the RIPE database that they are using to actually get this space announced. What's even worse is their carrier is trying to say these announcements are legitimate because they have IRR entries (which is a whole other issue)
What is the process like for actually getting this fraudulent entry removed? I've been in contact with RIPE NCC Support, and they have been super unhelpful (ref case #14523)
The fraudulent entry is:
https://apps.db.ripe.net/search/lookup.html?source=ripe&key=198.13.32.0/19AS...
route: 198.13.32.0/19 descr: 2nd route origin: AS39967 mnt-by: ADMASTER-MNT created: 2017-10-13T00:20:08Z last-modified: 2017-10-13T00:20:08Z source: RIPE
I should also note that this ASN suspiciously appears to be announcing
other
people's space as well, but I can only confirm that this particular entry does not belong. I would suspect that their other IRR entries are fake as well.
You can verify my request by reaching out to any of the POCs associated with this network: https://whois.arin.net/rest/net/NET-198-13-32-0-1
Thanks, Brian Rak
denis walker via db-wg wrote:
Perhaps after the RIPE NCC implements the agreed actions on foreign ROUTE objects, it would be a good idea to do a (one time?) cleanup/review of all foreign ROUTE objects in the RIPE IRR. Find the contact details in the appropriate RIR Database for all non RIPE address space covered by these ROUTE objects. Send them a notification with a link to click if they approve of the ROUTE object. If no response is received within a defined time period, delete the ROUTE object.
a cleanup would be a good idea, but this is probably too aggressive an approach. I'd prefer to see multiple contact attempts with the objects eventually modified to make a note that they are flagged for deletion, before they are actually deleted. Some categories of entries can probably be deleted immediately, e.g. route(6) objects which are associated with ASNs which are unregistered or from the private ranges. There are a couple of special case ASNs, e.g. AS112. Nick
We're back to this again... more of our space is being hijacked using a RIPE IRR entry: route: 108.160.128.0/20 descr: 2nd route origin: AS19529 mnt-by: ADMASTER-MNT created: 2017-11-15T17:41:46Z last-modified: 2017-11-15T17:41:46Z source: RIPE Same ASN. Can RIPE purge all the IRR entries created by this maintainer? They don't appear to be legitimate. On 11/9/2017 2:13 PM, Nick Hilliard via db-wg wrote:
denis walker via db-wg wrote:
Perhaps after the RIPE NCC implements the agreed actions on foreign ROUTE objects, it would be a good idea to do a (one time?) cleanup/review of all foreign ROUTE objects in the RIPE IRR. Find the contact details in the appropriate RIR Database for all non RIPE address space covered by these ROUTE objects. Send them a notification with a link to click if they approve of the ROUTE object. If no response is received within a defined time period, delete the ROUTE object. a cleanup would be a good idea, but this is probably too aggressive an approach. I'd prefer to see multiple contact attempts with the objects eventually modified to make a note that they are flagged for deletion, before they are actually deleted.
Some categories of entries can probably be deleted immediately, e.g. route(6) objects which are associated with ASNs which are unregistered or from the private ranges.
There are a couple of special case ASNs, e.g. AS112.
Nick
We're back to this again... more of our space is being hijacked using a RIPE IRR entry:
route: 108.160.128.0/20 descr: 2nd route origin: AS19529 mnt-by: ADMASTER-MNT created: 2017-11-15T17:41:46Z last-modified: 2017-11-15T17:41:46Z source: RIPE
Same ASN.
Can RIPE purge all the IRR entries created by this maintainer? They don't appear to be legitimate.
and we are supposed to use the high quality ripe irr as authoritative data for routing validation?
Randy Bush via db-wg wrote:
and we are supposed to use the high quality ripe irr as authoritative data for routing validation?
the current plan is to re-mark all out-of-region route / route6 / autnum objects with source: RIPE-NONAUTH and to disable creation of these objects in future. Unless something has been missed, this should be an improvement over the current situation? Nick
and we are supposed to use the high quality ripe irr as authoritative data for routing validation?
the current plan is to re-mark all out-of-region route / route6 / autnum objects with source: RIPE-NONAUTH and to disable creation of these objects in future. Unless something has been missed, this should be an improvement over the current situation?
peval() does not look at source:. and thanks, don't tell a whole lot of folk to change software. and you know that the point of my snark is that there are more authoritative data available. randy
Randy Bush wrote:
peval() does not look at source:. and thanks, don't tell a whole lot of folk to change software.
it does if you tell it to: % peval -s RIPE AS-BLAH Generally it's sensible practice to filter on source: attributes, as there is a good deal
and you know that the point of my snark is that there are more authoritative data available.
RPKI has a different set of characteristics which doesn't fully overlap with irrdb-managed filter lists. There's a place for both in this world. Nick
Generally it's sensible practice to filter on source: attributes, as there is a good deal
... of unfinished emails on the internet. Also, of junk stored in a bunch of irrdbs, some of which have ended up as unmaintained toxic dumping grounds for route objects. Nick
On 4/5/2018 2:27 PM, Nick Hilliard via db-wg wrote:
Randy Bush via db-wg wrote:
and we are supposed to use the high quality ripe irr as authoritative data for routing validation? the current plan is to re-mark all out-of-region route / route6 / autnum objects with source: RIPE-NONAUTH and to disable creation of these objects in future. Unless something has been missed, this should be an improvement over the current situation?
Nick
Is there going to be a cleanup process for existing entries? For example: https://apps.db.ripe.net/db-web-ui/#/query?bflag&inverse=mnt-by&searchtext=A... route: 104.143.112.0/20 Not currently advertised, belongs to a managed services provider in the US: https://whois.arin.net/rest/net/NET-104-143-112-0-1/pft?s=104.143.112.0 route: 141.193.96.0/19 Not currently advertised. ARIN claims this belongs to RIPE: https://whois.arin.net/rest/net/NET-141-0-0-0-0 RIPE claims this belongs to... someone else? https://apps.db.ripe.net/db-web-ui/#/query?searchtext=141.193.96.0 route: 192.73.128.0/18 Currently advertised by 30237 ARIN says this belongs to the US Air Force https://whois.arin.net/rest/net/NET-192-73-82-0-1 It largely looks like all of these route objects created by ADMASTER-MNT are (or have been) used for hijacking mostly unused ARIN space.
Den 2017-11-09 kl. 17:22, skrev Brian Rak via db-wg:
Hi,
We've run into an issue where an unknown malicious party appears to have hijacked some of our IP space. They created entries in the RIPE database that they are using to actually get this space announced. What's even worse is their carrier is trying to say these announcements are legitimate because they have IRR entries (which is a whole other issue)
What is the process like for actually getting this fraudulent entry removed? I've been in contact with RIPE NCC Support, and they have been super unhelpful (ref case #14523)
The fraudulent entry is:
https://apps.db.ripe.net/search/lookup.html?source=ripe&key=198.13.32.0/19AS...
route: 198.13.32.0/19 descr: 2nd route origin: AS39967 mnt-by: ADMASTER-MNT created: 2017-10-13T00:20:08Z last-modified: 2017-10-13T00:20:08Z source: RIPE
I should also note that this ASN suspiciously appears to be announcing other people's space as well, but I can only confirm that this particular entry does not belong. I would suspect that their other IRR entries are fake as well.
You can verify my request by reaching out to any of the POCs associated with this network: https://whois.arin.net/rest/net/NET-198-13-32-0-1
Thanks, Brian Rak
It seems that at least 4 ASes has announced this prefix (both /19 and /20) this year. https://stat.ripe.net/widget/routing-history#w.resource=198.13.32.0%2F19 -- Bengt Gördén Resilans AB
participants (6)
-
Bengt Gördén -
Brian Rak -
denis walker -
Job Snijders -
Nick Hilliard -
Randy Bush