Admin charlaMX friendica (via ActivityPub)

Friendica Web Security Guides: GAB Hacked

GAB Hacked: Now Hackers Only Hack Free Speech Platforms
!Friendica Admins
Do you have any Guide to increase the security of your site in Friendica?
Now the platforms trying to escape BigTech's siege are being "hacked" 😒, it is obvious that the pirates are paid trolls who exploit security holes. Gab is know as a "Conservative" website, for people banned from other platforms like instagram, facebook and twitter.

I think that we as alternative platforms should have a strong security fence, especially because of how open the fediverse platforms are.

So far, apart from some like Wikileaks groups, I have not seen any group of hackers aiming to improve people's lives or fight against surveillence, but rather to enrich themselves and exploit the money and lifes of others, not a single one.

I appreciate any guidance to increase the security of the website.

Thanks and regards...
Jasnah Kholin friendica (via ActivityPub)
Just today I was talking to a security researcher (who has submitted 1 vulnerability to Friendica team) about ways to increase security in Fediverse software. Here's his advice:

1. Document a straightforward process for reporting vulnerabilities - must be easy to find for each project. On first glance, I can't find it in Friendica repo or Wiki. Is it somewhere there? Ideally it should be in the README of the main code repository and/or documentation repo. See diaspora good example
2. Add security.txt file to official project's website
3. Make a security.txt file part of Friendica deployments: with Friendica team data by default, but mentioned in deployment docs for admins optionally to tweak / add their own contacts for server (rather than software) vulnerabilities. **Alternatively**, add separate line in <domain/friendica> path specifically for security vulnerabilities (ATM there's only "Bug reports and issues")
4. (Optional) Decide on the desired timeline for critical reports - this information may be stated in the docs/security, or/and in security.txt file.

Will someone from Friendica team be interested to discuss these options and make them real? I'm sorry to say I don't have a GitHub account to submit this as an issue.
Jasnah Kholin friendica (via ActivityPub)
Forgot link for (2) - security.txt
Admin charlaMX friendica (via ActivityPub)
I think is a good idea, I will set mine, but instead of open contact I guess I can use twitter account, if gets spammed then is twitter not my network/email 😅

Thanks Jasnah!
Hypolite Petovan friendica (via ActivityPub)
Of course! We've never been shy about security issues, if only because Friendica doesn't have a wide adoption (yet?). We do address them in a timely manner when they are reported currently only publicly on the project's GitHub page and made special hotfix stable releases for concerning vulnerabilities.

As a result, the security.txt file would be pretty straightforward.
PrivacyMatters 🔒 friendica (via ActivityPub)
Thank you, @Hypolite Petovan ! Proud to be part of the #Friendica family!
Admin charlaMX friendica (via ActivityPub)
I would help but I don't know much about security, I am a developer but the old school, and this is my first approach to social networks and website implementations.
Still, I am reading about security in my case for websites implemented by using Plesk and virtual private servers, if I got something I will share for sure🙂👍
Admin charlaMX friendica (via ActivityPub)
💡In case any of you can take the time to check about this, it explains is the way gab.com was hacked, I understand it was a security hole by sql injection and as I know, Gab was implemented by using a Mastodon fork. So my concern is that Friendica could also have this kind of holes, even that I understand Friendica code is different and is PHP, Gab/Mastodon is in Ruby code. If any you know more about it I'll appreciate your comments: 👍

jeroen 🇧🇪 pleroma (via ActivityPub)
From the Federation statistics on my server, one could say that there is some room for improvement for some servers...
@Admin charlaMX General guidelines do exist on the Internet, e.g. have a decent firewall on your server, don't do root, how to harden SSH servers (also important), don't let to much listen on or on any public address (only as needed), use strong keys and certificates for encrypted connections (SSL/TLS), regularly update your software and so on.,
Andy H3 friendica (via ActivityPub)
Five servers still on 2.x. Wow! What's going on there?
@Andy H3 I wonder the same, why they don't want to upgrade? Well, one day they might be disconnected from the rest as the server-to-server communication protocol might become incompatible.
Andy H3 friendica (via ActivityPub)
Must be ghost servers... unless they are used for internal communication.

I'm sure there's nothing going in there. Who sends out DFRN messages?
Andy H3 friendica (via ActivityPub)
why they don't want to upgrade?
Imagine the procedure, if you want to keep the DB. I already picture the support question for a DB schema issue as you move up from 2.05 to 2.07... 😂
This entry was edited (8 months ago)
@Andy H3 It would be nice if Friendica can have some feature to cleanup old (gone servers, closed instances, ...) entries from database, including their posts and comments (if not otherwise possible). Or am I just not finding it?
Andy H3 friendica (via ActivityPub)
@roland Cleaning up the stats? Nope that doesn't exist. But you can block any node.

Your DB should automatically purge expired messages. You can set the expiry frame in the admin panel.
@Andy H3 I still see a lot records in gcontact from old quitterse/no/nu and gnusocialde/ch instances. E.g. SELECT * FROM `contact` WHERE `notify` LIKE '%quitter.se%' turns up a lot records here and I guess many posts/comments are attached to these expired accounts. Can I do a DELETE FROM on them safely?
Andy H3 friendica (via ActivityPub)
Not sure if that's a good way. I think theses are just known users in the fedi.

It's assumed that they may reappear. Don't think it will be cleaned up.

Generally I would not manually alter the DB unless there's a fault.
Andy H3 friendica (via ActivityPub)
I guess many posts/comments are attached to these expired accounts.

Don't think it's the case that messages are still there. Unless of course you set the server not to expire them.

I think it's only user addresses, avatars, and some metadata.

I guess you're saying that the service doesn't even exist anymore.
@Andy H3 Yes, #quitter.se and such other old #GNUSocial instances are gone. It would be good to clean their (also gone) contacts up.
Andy H3 friendica (via ActivityPub)
I'd say we are looking for a console command that would take care of this.

Would you like to open an issue for a request. I think you got a valid point.
@Andy H3 Really not that much in item table, for only #quitter.se I found 12 records:

SELECT COUNT(`item`.`id`) AS `cnt`
FROM `item`
INNER JOIN `contact`
ON `item`.`contact-id`=`contact`.`id`
WHERE `contact`.`notify` LIKE '%quitter.se%'

All expired nodes together I could find so far: 20 ...
SELECT COUNT(`item`.`id`) AS `cnt`
FROM `item`
INNER JOIN `contact`
ON `item`.`contact-id`=`contact`.`id`
WHERE `contact`.`notify` LIKE '%gnusocial.de%'
OR `contact`.`notify` LIKE '%gnusocial.ch%'
OR `contact`.`notify` LIKE '%quitter.se%'
OR `contact`.`notify` LIKE '%quitter.no%'
OR `contact`.`notify` LIKE '%fragdev%'
Andy H3 friendica (via ActivityPub)
Well you're preserving history. You're the custodian of these long bygone usernames. :-)
This entry was edited (8 months ago)
I personally do not believe in non-public vulnerability disclosures. We do not have a fake public image of security to artificially maintain nor an adoption large enough that a public disclosure could do any significant harm. The cost of adding support for non-public disclosure, on the other hand, would be real.

I'll add the security.txt file, the corresponding module (.well-known/security.txt on any Friendica node) and a succinct Security Policy page on the Friendi.ca website this week.
Admin charlaMX friendica (via ActivityPub)
Many thanks, I didn't know about it, I am reading it🤯
Nanook friendica (via ActivityPub)
There are things you can do to help secure your website. Avoid hosts that have control panels, there isn't a one of them that doesn't have serious root exploits, same for phpmysqladmin.

On your host, block everything except the ports actually needed to provide the service, i.e., https port 443, https port 80, ssh port 22, etc.

Bind mysql or mariadb to localhost only so it can't be accessed remotely.

Install fail2ban for every service so that you can stop brute force password guessing.

Install suPHP or equivalent on your web server so that each PHP application runs with it's own UID, this also eliminates the need for any application to have publicly writable files or directories. It prevents a whole in one application from being able to be used to modify another. Give each PHP application their own unique UID that suPHP will use to execute it. Make sure all your accounts have strong password.

Consider using one of the kernel security enhancements such as selinux or apparmor.

Consider using different virtual machines to insulate services from each other. Often a given service by itself is okay another service can be used to exploit something in the first.

I suggest installing rkhunter and running it daily. This searches for unauthorized changes to binaries and installation of root kits and other abnormal things that may indicate a site compromise.

Make backups frequently and at least occasional backups offline so that if you get hit with ransomeware, you've got some means to recover.

If you do not manually apply updates daily, consider installation of automatic updates for AT LEAST any security related updates.

Keep your Linux kernel up to date; exploits are found and fixed frequently, you don't want to be sitting open with zero day exploits.
Nanook friendica (via ActivityPub)
@Adam@Admin charlaMX Please don't turn the fediverse into another fucking Facebook.