I just got phishing attack report on my public gateway. The concern cid is bafkreicimxxtvbx7l5isvw6vwn5mmkb6tjvspml72dd4vla67x3wbzvlhi
How can I block particular cids to comply with takedown reports?
Is there any centralized crowd maintained list of verified cids to autoblock them ipfs-wide?
What is ipfs doing to reduce such phishing attacks from ipfs network?
The attack reporter might have submitted the web url to various antivirus programs. Because of this, some of them are now reporting my whole domain name (apex too) as spyware/phishing website and blocking the access to it. This is degrading the seo reputation.
Whatever reverse proxy you use is how you’d block specific CIDs I believe. So you’d block the path to the CID.
I don’t believe so, but I love that idea.
There’s nothing that can be done. Like HTTP can’t stop someone from creating a website with illegal content, IPFS can’t stop people from sharing illegal content. This is one of the big struggles of hosting a public unlimited gateway. Same as hosting an HTTP proxy or a Tor exit node.
Yeah that has happened to our gateways too … an extremely frustrating situation. I think you can apply to be removed from the phishing list, but I’m not sure on the details.
Are you blocking the domain ipfs.io? If that so, that will not be useful. Because, other gateways can still be serving the same phishing page. Rather, block the cid path. That will block complete access to that resource from any possible gateway.
That would only block access to that particular path coming from the ipfs.io gateway. I’m not clear what direction you’re suggesting blocking that url.
It will sort of work. If the phishing attack is using that specific hardcoded url at ipfs.io than its no different than blocking any other malicious url. The phishing site is still accessible over any other public gateway. They can also retrieve it directly by CID over IPFS or construct any number of different urls that point to the same CID.
The point was just that it blocks access to that particular url but the CID and the malicious content is still accessible.
Yes, but temporarily. The attacker may use another public gateway for the link. e.g. the same resource can be fetched by using cloudflare’s gateway instead of ipfs.io’'s gateway as follows. Dell - Mail
So, just blocking ipfs.io domain will not be the full proof plan. Rather, that will unable to you and your team to make the use of ipfs.io gateway for good purpose.
I would suggest blocking path only for that ipfs resource. Block following path /ipfs/QmQLL5CwvUfkJTodMFie4QYhQC8n4cvg7ChJLR2KThz8xX
This will be better approach blocking any ipfs resource.
Depends on the firewall configuration. Try blocking following */ipfs/Qmblahblahblah/*
Thats the real pain. We can’t make it full proof for lifetime. But we can try blocking every possible cid.
But just blocking gateway url can not be the solution. That will not be good for IPFS ecosystem.
Thanks for bringing these articles to our attention @Galactus. While it’s inevitable that some bad actors will seek to use IPFS, we immediately block malicious content on our gateways — email email@example.com to report phishing. There is a system in place for processing this, at least for the one maintained by Protocol Labs.
To give more context, deciding which CIDs to co-host is a multi-faceted problem.
Here are some pointers at ongoing work in IPFS Community:
OR (a quick alternative): If your gateway is used only for hosting image/video/audio assets, simply block text/html responses.It will make your gateway useless to phishing campaigns, but can still be used for asset retrieval (including trustless responses)
Allow / Deny lists
Protocol Labs’ gateway team maintains https://badbits.dwebops.pub, a list of hashed CID that have been flagged for various reasons (copyright violation, malware, etc). Feel free to reuse it until community-driven solutions exist (below).
We want to support this out-of-the-box in Kubo and other IPFS implementations. Feedback on the proposed spec will be appreciated.
Long term, we imagine various groups like content-addressed alliance Content Addressed Alliance WG - discuss.ipfs.tech to maintain shared deny lists (similar to adblock lists we see today), allowing community to self-organize and defend against bad actors etc.
After facing deactivation and reactivation of my domain name for IPFS gateway, the original registry NameCheap has given me the clearance that my domain is now clear from current abuse complaints. Also, I am proactively blocking the abuse material from the gateway time to time, as soon as I detect any.
In a shocking event, yesterday, the authority for abuse handling for domain names, GoDaddy has disabled my domain name citing abuse activities from the domain.
Now, what in my hand is, again have same followup with GoDaddy which I have already gone through with NameCheap and beg them to re-activate the domain name.