I work for IPinfo, and we do not believe in the general-purpose "IP Reputation Scoring."
IP scoring is such a difficult product to do reliably. When someone says we provide IP scoring, you have to ask them based on what and what is your methodology. Now, IP reputation scoring can be good if both the vendor and the customer know what they are looking for very specifically.
For example, there are abusive IP databases. Now, some abusive IP databases run global honeypots, and they can say these IP addresses tried to exploit the CVE patterns. Sounds good, so when you buy their product, you can say the scoring they are providing can help with blocking IP addresses that run automated CVE exploits that match this pattern. Those services act as beacons, rather than a flat, generic, and everlasting database of bad IP addresses.
Now, do you take that score and try to use it as a baseline for protecting your login portal or credit card fraud? Of course not! You have to go to specialized vendors who provide specialized scoring.
We do not do IP reputation because we provide IP metadata that we can verify, and we can discuss methodologies publicly. If you ask us to do IP reputation scoring, we can easily do that, as we run a global honeypot ourselves as well. But that will involve us providing explanations and education to folks that the score you see fits a very specific pattern of attack that is not generic.
For example, we sell residential proxy detection data, and the database contains 100 million IP addresses. Are all 100 million IP addresses bad? Of course not. But this is not our call to make; our customers have to see the metadata we provide as well, such as percent days seen, last seen, etc. Now, if an IP address is flagged for being 100 percent seen and the last seen date is fairly new, it fits a certain threat model which can be categorized as concerning.
Is that the same IPinfo that does IP reputation and shares inaccurate info about real ISPs and keeps spamming NANOG about how they actually don't do either?
Your CTO or CEO was saying they always trust geofeed and an ISP with wrong info just needs to update their geofeed, then he said you actually never trust geofeeds, but don't worry just update the geofeed and it'll be trusted, then when pointed out the correct information was already in the geofeed but not on IPinfo, he said IPinfo uses data from the geofeed so it's correct... Something like that, it made no sense but it made it clear you guys don't know what your product does.
I work for IPinfo. I recommend users use ipinfo.io/my as we do connect to residential IPs and verify.
Now, how to prevent this. If you are on a NATed connection, it is nearly impossible to prevent this from happening because you cannot control what apps people install who share the same IP address with you. If you have control over your network, then I suggest you install a DNS monitoring service. You can periodically monitor the DNS requests to find unusual patterns.
I work for IPinfo. Traffic data alone is not going to be a good indicator, to be honest. Last time I checked, we recognized 100 million resproxy IP addresses, and resproxy services charge by bandwidth. No single organization can or will want to run continuous operations from a single IP address, as it will get flagged by a non-IP-based bot detection check, and churning IPs generally indicate a standard web scraping operation.
I recommend folks just check our website: https://ipinfo.io/my and if they have questions, ask me, I will try to get to the bottom of this.
What we do is connect to residential proxy IP address and verify them before putting them in our database.
But DNS and traffic monitoring is a good practice. If you see gigabytes of traffic without explanation, you have more serious concerns than resproxy.
If your IP address is part of a residential proxy network, it will be flagged.
Also, I recommend seeing the device count data we have for you. If you are on a NATed IP, you have virtually no control to remove the residential proxy SDK from your system. Let me know if you have any questions, as I work for IPinfo.
We do not run any kind of detection systems when you visit the page. What we do is reference our resproxy detection database, which has a schema like this:
We collect the residential proxy data continuously from independent systems; when you visit the page, we take your IP address and look it up in our database. Note the percent_day_seen field, which is frequency metadata. You can also complement it with our device count data to understand if you are on a NATed IP.
If you are on a static IP address and a single user, we flag your IP address as a residential proxy. I think you should install some DNS monitoring service and start uninstalling unnecessary apps from internet-connected devices.
I pinged the web team, they will work on something to make this more legible. (Edit: they have started work on this; if you have any other feedback, please let me know) — Abdullah | DevRel, IPinfo
We could have done something similar here as well. It is really challenging to balance the stats and explainers. So, the approach we sometimes take with high-impact topics is to provide companion blogs and dashboards for users to explore the data themselves.
I work for IPinfo. We really would appreciate more constructive feedback on how to present data driven stories that is approachable to everyone.
> I stopped reading after the first graphic.
Now, let's see what we had before the first graphic.
1st Paragraph: Explains what BGP is.
2nd Paragraph: Tells a story about the Pakistani ASN accidental BGP hijack. A story which is known in the network engineering community, but not by most people.
3rd Paragraph: Introduces RPKI.
4th Paragraph: Summary states that builds the foundation of the article.
Then the first graphic shows the RPKI validation. That is all.
How would you structure the blog post about RPKI adoption, which is a data-driven technical story? I am not absolutely trying to be demeaning, but would you rather start from what BGP, RPKI, and those things are?
Then we have a series of community post around them:
IP scoring is such a difficult product to do reliably. When someone says we provide IP scoring, you have to ask them based on what and what is your methodology. Now, IP reputation scoring can be good if both the vendor and the customer know what they are looking for very specifically.
For example, there are abusive IP databases. Now, some abusive IP databases run global honeypots, and they can say these IP addresses tried to exploit the CVE patterns. Sounds good, so when you buy their product, you can say the scoring they are providing can help with blocking IP addresses that run automated CVE exploits that match this pattern. Those services act as beacons, rather than a flat, generic, and everlasting database of bad IP addresses.
Now, do you take that score and try to use it as a baseline for protecting your login portal or credit card fraud? Of course not! You have to go to specialized vendors who provide specialized scoring.
We do not do IP reputation because we provide IP metadata that we can verify, and we can discuss methodologies publicly. If you ask us to do IP reputation scoring, we can easily do that, as we run a global honeypot ourselves as well. But that will involve us providing explanations and education to folks that the score you see fits a very specific pattern of attack that is not generic.
For example, we sell residential proxy detection data, and the database contains 100 million IP addresses. Are all 100 million IP addresses bad? Of course not. But this is not our call to make; our customers have to see the metadata we provide as well, such as percent days seen, last seen, etc. Now, if an IP address is flagged for being 100 percent seen and the last seen date is fairly new, it fits a certain threat model which can be categorized as concerning.
reply