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.
Google chrome is now giving phishing warning on my apex domain used for gateway.
- 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.
In recent development, the threat became widespread now. Check the article here
@Jorropo @Discordian @lidel @system Need serious attention. The IPFS is loosing reputation.
I also found a phishing link :-/
I am taking steps to close ipfs.io for all 12000 users that we have.
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 that one path to the CID. There can be any number of paths.
The phishing mail with the phishing link points to:
So if the firewall blocks all access to ipfs.io, then the link should be harmless … is that not correct?
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
This will be better approach blocking any ipfs resource.
Yes. Thats why I am asking him to block path to that 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
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:
Tips for Gateway Operators
Gateways and gatekeepers: How Google’s mistakes can still affect web3 a case study by nft.storage team running their own public gateway.
- 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
- 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
Loved to hear this. Fingers crossed.
How to use it? I can block cid from reverse proxy. But don’t know about badbit.
My understanding is that you need to calculate
sha256(CIDv1Base32(cid)) and then check if value is on https://badbits.dwebops.pub/denylist.json.
You could integrate this into your middleware app, or nginx itself, with something like lua-nginx-module.
(note this is a band-aid until a turnkey solution described in IPFS filtering to allow node operators to decide on content they are willing to serve · Issue #8492 · ipfs/kubo · GitHub is implemented)