[Security/Gitea] How to Secure Your Public Gitea Server Without Complex Configuration

Last time when I restarted my Gitea server was when I upgraded it to 2.20.11. It has been six months. Although I almost pushed code everyday, I didn’t notice that my Gitea server was already attacked by hackers for a couple of months.

I found out that the hackers created few users and repositories on my Gitea server everyday. I was lucky that I found out this issue before it was too late.

Check the above sceenshot, those user accounts are even activated!

Since I’m the only user of this Gitea server, I don’t want to introduce any complex configuration to secure it. I just want to keep it simple and secure.

1. Update Gitea Server Configurations

Here is how I secure my Gitea server:

1. Disable user registration

I don’t want to provide an effortless way for others register to my Gitea server. I only want to use it for myself.

This can be done by setting DISABLE_REGISTRATION to true in the app.ini file.

...
[service]
DISABLE_REGISTRATION = true

With this setting, the “Register” button will be hidden from the login page. I thought this is pretty enough to secure my Gitea server. But it’s not. The hackers can still create users and repositories by sending API requests to the Gitea server.

If you have CAPTCHA service or STMP server, you can enable CAPTCHA or REGISTER_EMAIL_CONFIRM to protect your Gitea server from unauthorized access. If you don’t have them, it can be a little bit complex to set up.

As I mentioned before, I don’t want to introduce any complex configuration to secure my Gitea server. I just want to keep it simple and secure.

2. Blocklist email domains

You might think of setting up a firewall to whiltelist my IP, but I don’t want to do that. I want to access my Gitea server from anywhere.

However, this gives me an idea. I can set up email domain blocklist to prevent unauthorized access to my Gitea server. This is simple and secure.

So I navigated to the Site Administration/Identity & Access/User Emails page, found that gmail.com is the most used email domain by the hackers. I added it to the blocklist. This can be done by setting EMAIL_DOMAIN_BLOCKLIST to gmail.com in the app.ini file.

...
[service]
EMAIL_DOMAIN_BLOCKLIST = gmail.com

If you want to block multiple email domains, you can separate them by commas.

...
[service]
EMAIL_DOMAIN_BLOCKLIST = gmail.com, yahoo.com

I thought it’s enough to secure my Gitea server this time. It reduced a lot of malicious signups, it doesn’t fix the issue completely though. The hackers still used some other email domains, such as skankville.com. It will be too time-consuming to add all the email domains to the blocklist.

3. Allowlist email domains

The killing solution is to set email domain allowlist configuration. This can be done by setting EMAIL_DOMAIN_ALLOWLIST to mydomain.com in the app.ini file.

...
[service]
EMAIL_DOMAIN_ALLOWLIST = mydomain.com

Since your Gitea server is public, you must own the domain. This is secure enough to prevent malicious signups to your Gitea server. Don’t worry about if your current users are using other email domains. They can still access your Gitea server. This configuration only affects new users.

After I applied the above changes, I didn’t see any new users and repositories created by hackers. My Gitea server is secure now.

2. Clean Up Malicious Users and Repositories

We only finish the half of the work. We need to clean up the malicious users and repositories created by hackers.

1. Delete malicious email addresses

To be honest, there is no easy way to delete users in Gitea. There is no bulk delete feature in Gitea. You have to delete them one by one from the page.

Again, this makes things complex. So we can delete them directly from the database.
❗ Please backup your database before you do this.

DELETE FROM email_address WHERE email not in ('youraccount@domain.com', 'youraccount2@domain.com');

The data in the email_address table is used to store the email addresses of the users. It corresponds to Site Administration/Identity & Access/User Emails page in the Gitea web interface.

2. Delete malicious users

❗ Please backup your database before you do this.

-- list all users and record the id of the user/organiation you want to keep.
SELECT id, name, email FROM public.user order by id; 
-- delete the malicious users except the ones you want to keep
DELETE FROM public.user WHERE id not in (1, 2, 3); 
-- or delete all users except the ones you want to keep
DELETE FROM public.user WHERE id > 3;

The data in the public.user table is used to store the users and organizations. It corresponds to Site Administration/Identity & Access/User Accounts page in the Gitea web interface.

3. Delete malicious repositories

❗ Please backup your database before you do this.

-- have a general view of the repositories. The owner_id is the id of the user or organization.
SELECT owner_id, owner_name, name FROM repository; 
-- delete the malicious repositories except the ones you want to keep
DELETE FROM repository WHERE owner_id not in (1, 2, 3); 
-- or delete all repositories except the ones you want to keep
DELETE FROM repository WHERE owner_id > 3;

The data in the repository table is used to store the repositories. It corresponds to Site Administration/Code Assets/Repositories page in the Gitea web interface.

Now we can say our Gitea server is secure and clean. My current Gitea version is 1.22.2. The above pages might be different from yours. But I’m sure you can find the corresponding pages in your Gitea web interface.