Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Malware detection via (something like) Google Safe Browsing #478

Open
vorburger opened this issue Aug 27, 2023 · 3 comments
Open

Malware detection via (something like) Google Safe Browsing #478

vorburger opened this issue Aug 27, 2023 · 3 comments

Comments

@vorburger
Copy link
Contributor

vorburger commented Aug 27, 2023

In #477 I have noticed that apparently some ISPs (mine) block (some URLs related to) Saturn, now.

I (vaguely) remember that there was a blocklist of bad CIDs somewhere, but apparently it's not enough for overzealous ISP.

Does this project have any plans to add more filtering to weed out CIDs hosting e.g. phishing content?

It occured to me that (something like) Google Safe Browsing https://developers.google.com/safe-browsing/ (which has a publicly availabe API) could be potentially be of interest to integrate.

Just a thought and for discussion.

@willscott
Copy link
Contributor

there is no user-generated content served from 'orchestrator.strn.pl'. It is only used for L1 registration / communications. As such, something like safe browsing would not help with an overzealous ISP blocking of the form you have encountered.

@vorburger
Copy link
Contributor Author

@willscott right... I see. Let's forget what specifically got me thinking about and triggered me to create this issue initially.

More generally, would Saturn benefit from some form of more "dynamic" CID blocking for malware detecting than only the current denylist.conf?

If there is interest, I'm not sure how one would go about this... completely dynamic may slow down retrieval? But you could image doing some offline batch analysis to regularly update a block list?

Perhaps this issue could serve for discussion of this more general underlying idea.

@willscott
Copy link
Contributor

There are already a couple factors that help mitigate the abuse potential of an L1 node.

As an initial dynamic mitigation, L1s do not serve content from the combined/community-maintained https://badbits.dwebops.pub/

In addition, L1s do not serve content directly. This should both limit the risk of getting flagged for serving e.g. malware or phishing content, but is also done for client protection - getting content from an L1 requires content software that verifies that the data received matches the CID that was requested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants