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.
I am using NGINX for rProxy. So blocked the path to the cid. Closed the takedown complaint.
But it will be easier for gateway operators if IPFS includes cid blocking option at application level inside ipfs itself.
Also, maintaining public ledger of malicious cids can be helpful too.
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.
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.
What I’m stalking about is if you constructed some other path /ipfs/Qmblahblahblah/my/other/path that resolved to the malicious CID.
Just pointing out that it would be trivial to work around and you’d end up playing wack-a-mole.
Now that I think about it it would be trivial to change the CID (of the malicious content, yes I know CIDs are immutable) by say adding trivial white space or padding.
Seems to be an inherent problem of running something wide open on the internet and not really specific to IPFS.
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 abuse@ipfs.io 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:
Main takeaway: public gateways can be blocked. Rule of thumb is to host them on separate, dedicated domains to minimize impact to your main website (example: switching non-gateway websites from .io to .tech TLD).
If you want to run a dedicated gateway under your own brand, and only for your own content-addressed data, make sure it only hosts safelisted CIDs (or response types).
Consider denylists (described below) or running with Gateway.NoFetch.
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.
