florence-social / mastodon-fork

Florence's fork of Mastodon
GNU Affero General Public License v3.0
138 stars 15 forks source link

Set firewall to IP-block Gab's instance #129

Closed 1011X closed 5 years ago

1011X commented 5 years ago

This pull request should set up the Docker image so that it doesn't accept any packets either to or from gab.com or develop.gab.com. This (partly) fixes #120.

Important note: I say "should" because this has not been tested on the image itself yet. Local tests work, but the behavior on the image has yet to be verified. Also, this pull request should remain open until the IP of the official instance is announced so it can be included if needed.

jhaye commented 5 years ago

Nice work, looking good! One thing that might be useful, is running the iptables commands in separate blocks for each domain with a comment on top, which block corresponds to which domain. This will make editing the list much easier later on.

1011X commented 5 years ago

Thanks! Alright, I will do that in the morning.

jhaye commented 5 years ago

Seems like their instance is online on gab.com now.

Her are the IPs for said domain:

www.gab.com has address 104.16.122.96
www.gab.com has address 104.16.121.96
www.gab.com has IPv6 address 2606:4700::6810:7a60
www.gab.com has IPv6 address 2606:4700::6810:7960

Appear to be the same addresses.

meltheadorable commented 5 years ago

We don't know if those are the IPs that will be used for content fetches, if they have their workers running on a separate VPS the IPs they actually use may not even be associated with the domain -- if the domain is pointing at a load balancer same deal -- I get what you're trying to do here, I just want to be clear that this may or may not do anything at all, if their deployment is even a little tiny bit sophisticated this won't stop their traffic coming through and people should know they may not be protected in that situation.

jhaye commented 5 years ago

I understand, but like was said before: this is the best we can do in the immediate future.

meltheadorable commented 5 years ago

I was looking at their code, and there's evidence they are behind cloudflare, so this will not work.

mal0ki commented 5 years ago

We don't know if those are the IPs that will be used for content fetches, if they have their workers running on a separate VPS the IPs they actually use may not even be associated with the domain -- if the domain is pointing at a load balancer same deal -- I get what you're trying to do here, I just want to be clear that this may or may not do anything at all, if their deployment is even a little tiny bit sophisticated this won't stop their traffic coming through and people should know they may not be protected in that situation.

Is there ANY way to figure out what kind of set up they run, regarding this stuff, without going into their social circles?

I think this is incredibly important to keep in mind, when moving on to this part:

I understand, but like was said before: this is the best we can do in the immediate future.

While it may feel defeatist, it's also realist, I would not want to give people a false sense of security. Because that will backfire MORE than not having this in place. I feel like we need to properly discuss it on Sunday.

Laurelai commented 5 years ago

I have relavent information regarding this someone please private message me on mastodon

1011X commented 5 years ago

After learning a bit more about what we are dealing with, I've decided this change is not viable for what it's meant to do.

Although this may block one of Cloudflare's IP addresses for serving Gab, they're not the only ones, and they vary by location. Also, those IPs only pertain to their front-end, not the address(es) they use for federating they're information.

If we do find an IP address that connects directly to Gab and is (mostly) unchanging, I'll consider adding it to the firewall in a new PR.

igalic commented 5 years ago

aah i didn't realise this was cloudflare

that could also block a lot of other things, at least in IPv4