github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-22 14:34:54 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Bruteforce login security #1733

New Issue
Closed
opened 2025-11-02 04:11:36 -06:00 by GiteaMirror · 11 comments
GiteaMirror commented 2025-11-02 04:11:36 -06:00
Owner
Copy Link

Originally created by @xy2z on GitHub (Apr 26, 2018).

  • Gitea version (or commit ref): 1.4.0
  • Git version: Not relevant
  • Operating system: Ubuntu 16.04
  • Database (use [ ]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • Not relevant
  • Log gist:

Description

By default, it is possible to bruteforce login on Gitea...
From reading other topics, it seems fail2ban is the preferred way to protect from these attacks.

IMO This is an important message to tell to new users in the "Installation" docs, including a tutorial on how to set it up (eg. using Docker) - both for gitea login and git login bruteforce attacks.

Originally created by @xy2z on GitHub (Apr 26, 2018). - Gitea version (or commit ref): 1.4.0 - Git version: Not relevant - Operating system: Ubuntu 16.04 - Database (use `[ ]`): - [ ] PostgreSQL - [ ] MySQL - [ ] MSSQL - [X] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [X] Not relevant - Log gist: ## Description By default, it is possible to bruteforce login on Gitea... From reading other topics, it seems fail2ban is the preferred way to protect from these attacks. IMO This is an important message to tell to new users in the "Installation" docs, including a tutorial on how to set it up (eg. using Docker) - both for gitea login and git login bruteforce attacks.
GiteaMirror added the topic/security label 2025-11-02 04:11:36 -06:00
GiteaMirror commented 2025-11-02 04:11:37 -06:00
Author
Owner
Copy Link

@TangentFoxy commented on GitHub (Apr 26, 2018):

Since you mention it... how would you set it up? I've looked up usage before, but struggled with understanding.

@TangentFoxy commented on GitHub (Apr 26, 2018): Since you mention it... how would you set it up? I've looked up usage before, but struggled with understanding.
GiteaMirror commented 2025-11-02 04:11:37 -06:00
Author
Owner
Copy Link

@xy2z commented on GitHub (Apr 26, 2018):

You prove my point :) we need a tutorial.
And sorry, I don't know

@xy2z commented on GitHub (Apr 26, 2018): You prove my point :) we need a tutorial. And sorry, I don't know
GiteaMirror commented 2025-11-02 04:11:37 -06:00
Author
Owner
Copy Link

@4oo4 commented on GitHub (Apr 27, 2018):

This works for me. But remember that fail2ban is powerful and can cause lots of issues if you do it incorrectly, so make sure to test this before relying on it so you don't lock yourself out.

Gitea returns an HTTP 200 for bad logins in the web logs, but if you have logging options on in app.ini, then you should be able to go off of log/gitea.log, which gives you something like this on a bad authentication:

2018/04/26 18:15:54 [I] Failed authentication attempt for user from xxx.xxx.xxx.xxx

So we set our filter in /etc/fail2ban/filter.d/gitea.conf:

# gitea.conf
[Definition]
failregex =  .*Failed authentication attempt for .* from <HOST>
ignoreregex =

And configure it in /etc/fail2ban/jail.d/jail.local.

[gitea]
enabled = true
port = http,https
filter = gitea
logpath = /home/git/gitea/log/gitea.log
maxretry = 10
findtime = 3600
bantime = 900
action = iptables-allports

Make sure and read up on fail2ban and configure it to your needs, this bans someone for 15 minutes (from all ports) when they fail authentication 10 times in an hour.

I also have other filters looking at the web access logs for HTTP error codes, but I'm guessing this is more effective. Since I run a reverse proxy to gitea with nginx, I also had to add this to my nginx config so that the IPs all didn't show up as 127.0.0.1

proxy_set_header X-Real-IP $remote_addr;

I would be surprised if there wasn't some kind of rate limiting built in to the app itself to help mitigate, if not it should definitely be looked at.

@4oo4 commented on GitHub (Apr 27, 2018): This works for me. **But remember that fail2ban is powerful and can cause lots of issues if you do it incorrectly, so make sure to test this before relying on it so you don't lock yourself out.** Gitea returns an `HTTP 200` for bad logins in the web logs, but if you have logging options on in `app.ini`, then you should be able to go off of `log/gitea.log`, which gives you something like this on a bad authentication: `2018/04/26 18:15:54 [I] Failed authentication attempt for user from xxx.xxx.xxx.xxx` So we set our filter in `/etc/fail2ban/filter.d/gitea.conf`: ``` # gitea.conf [Definition] failregex = .*Failed authentication attempt for .* from <HOST> ignoreregex = ``` And configure it in `/etc/fail2ban/jail.d/jail.local`. ``` [gitea] enabled = true port = http,https filter = gitea logpath = /home/git/gitea/log/gitea.log maxretry = 10 findtime = 3600 bantime = 900 action = iptables-allports ``` Make sure and [read up](https://www.linode.com/docs/security/using-fail2ban-for-security/) on [fail2ban](https://www.fail2ban.org/wiki/index.php/MANUAL_0_8#Jail_Options) and configure it to your needs, this bans someone for 15 minutes (from all ports) when they fail authentication 10 times in an hour. I also have other filters looking at the web access logs for HTTP error codes, but I'm guessing this is more effective. Since I run a reverse proxy to gitea with nginx, I also had to add this to my nginx config so that the IPs all didn't show up as `127.0.0.1` `proxy_set_header X-Real-IP $remote_addr;` I would be surprised if there wasn't some kind of rate limiting built in to the app itself to help mitigate, if not it should definitely be looked at.
GiteaMirror commented 2025-11-02 04:11:38 -06:00
Author
Owner
Copy Link

@xy2z commented on GitHub (Apr 27, 2018):

@4oo4

I would be surprised if there wasn't some kind of rate limiting built in to the app itself to help mitigate, if not it should definitely be looked at.

I don't think there is. I just tried a simple bruteforce attack on my own git, and I could get ~1000 in 10 minutes, not sure if it's my server or gitea that's slowing it down a bit. Anyway, that's 144.000 attempts a day...

And thanks for the guide, I'll try it out.

@xy2z commented on GitHub (Apr 27, 2018): @4oo4 > I would be surprised if there wasn't some kind of rate limiting built in to the app itself to help mitigate, if not it should definitely be looked at. I don't think there is. I just tried a simple bruteforce attack on my own git, and I could get ~1000 in 10 minutes, not sure if it's my server or gitea that's slowing it down a bit. Anyway, that's 144.000 attempts a day... And thanks for the guide, I'll try it out.
GiteaMirror commented 2025-11-02 04:11:38 -06:00
Author
Owner
Copy Link

@xy2z commented on GitHub (Jul 14, 2018):

This doesn't work on my Gitea via Docker - I would be banned from all ports, but still have access to my docker websites, really weird...

So I found this blog post http://www.the-lazy-dev.com/en/install-fail2ban-with-docker/

Create a new fail2ban action file in /etc/fail2ban/action.d/iptables-docker.conf:

[Definition]
actionstart = iptables -N f2b-docker
              iptables -A f2b-docker -j RETURN
              iptables -I FORWARD -p tcp -m multiport --dports 80 -j f2b-docker

actionstop = iptables -D FORWARD -p tcp -m multiport --dports 80 -j f2b-docker
             iptables -F f2b-docker
             iptables -X f2b-docker

actioncheck = iptables -n -L FORWARD | grep -q 'f2b-docker[ \t]'

actionban = iptables -I f2b-docker 1 -s <ip> -j DROP

actionunban = iptables -D f2b-docker -s <ip> -j DROP

Change the action in jail.local gitea section to:
action = iptables-docker

Restart fail2ban.

Can someone confirm this works on their docker setup, so the docs can be updated.

@xy2z commented on GitHub (Jul 14, 2018): This doesn't work on my Gitea via Docker - I would be banned from all ports, but still have access to my docker websites, really weird... So I found this blog post http://www.the-lazy-dev.com/en/install-fail2ban-with-docker/ Create a new fail2ban action file in `/etc/fail2ban/action.d/iptables-docker.conf`: ``` [Definition] actionstart = iptables -N f2b-docker iptables -A f2b-docker -j RETURN iptables -I FORWARD -p tcp -m multiport --dports 80 -j f2b-docker actionstop = iptables -D FORWARD -p tcp -m multiport --dports 80 -j f2b-docker iptables -F f2b-docker iptables -X f2b-docker actioncheck = iptables -n -L FORWARD | grep -q 'f2b-docker[ \t]' actionban = iptables -I f2b-docker 1 -s <ip> -j DROP actionunban = iptables -D f2b-docker -s <ip> -j DROP ``` Change the `action` in `jail.local` gitea section to: `action = iptables-docker` Restart fail2ban. Can someone confirm this works on their docker setup, so the docs can be updated.
GiteaMirror commented 2025-11-02 04:11:38 -06:00
Author
Owner
Copy Link

@ghost commented on GitHub (Jul 14, 2018):

If a site is seeing a brute force attack why be reactionary and not proactive? A proof of work upon login could go a long way.

@ghost commented on GitHub (Jul 14, 2018): If a site is seeing a brute force attack why be reactionary and not proactive? A proof of work upon login could go a long way.
GiteaMirror commented 2025-11-02 04:11:38 -06:00
Author
Owner
Copy Link

@Mebus commented on GitHub (Mar 28, 2019):

How can I set this up within my Docker container? Could this be integrated into the default Docker Image?

@Mebus commented on GitHub (Mar 28, 2019): How can I set this up within my Docker container? Could this be integrated into the default Docker Image?
GiteaMirror commented 2025-11-02 04:11:38 -06:00
Author
Owner
Copy Link

@xy2z commented on GitHub (Mar 28, 2019):

@Mebus See https://docs.gitea.io/en-us/fail2ban-setup/

Note: If you have Gitea running on a port other than 80/443, eg. '3000', then you need to change the fail2ban config - this was my initial issue.

But I agree there should be an integrated solution in Gitea.

@xy2z commented on GitHub (Mar 28, 2019): @Mebus See https://docs.gitea.io/en-us/fail2ban-setup/ Note: If you have Gitea running on a port other than 80/443, eg. '3000', then you need to change the fail2ban config - this was my initial issue. But I agree there should be an integrated solution in Gitea.
GiteaMirror commented 2025-11-02 04:11:39 -06:00
Author
Owner
Copy Link

@porunov commented on GitHub (Aug 1, 2019):

Any idea how to add bruteforce login security for git clone <myrepo>? Failed logins for git clone are shown without ip addresses. Am I missing something?

2019/08/01 21:44:53 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `lower_name`, `name`, `full_name`, `email`, `keep_email_private`, `passwd`, `must_change_password`, `login_type`, `login_source`, `login_name`, `type`, `location`, `website`, `rands`, `salt`, `language`, `description`, `created_unix`, `updated_unix`, `last_login_unix`, `last_repo_visibility`, `max_repo_creation`, `is_active`, `is_admin`, `allow_git_hook`, `allow_import_local`, `allow_create_organization`, `prohibit_login`, `avatar`, `avatar_email`, `use_custom_avatar`, `num_followers`, `num_following`, `num_stars`, `num_repos`, `num_teams`, `num_members`, `visibility`, `diff_view_style`, `theme` FROM `user` WHERE `lower_name`=? LIMIT 1 []interface {}{"sdfwe"}
2019/08/01 21:44:53 ...xorm/session_find.go:199:noCacheFind() [I] [SQL] SELECT `id`, `type`, `name`, `is_actived`, `is_sync_enabled`, `cfg`, `created_unix`, `updated_unix` FROM `login_source` WHERE (is_actived = ?) []interface {}{true}
2019/08/01 21:44:53 ...s/context/context.go:202:HandleText() [E] invalid credentials
@porunov commented on GitHub (Aug 1, 2019): Any idea how to add bruteforce login security for `git clone <myrepo>`? Failed logins for `git clone` are shown without ip addresses. Am I missing something? ``` 2019/08/01 21:44:53 .../xorm/session_get.go:99:nocacheGet() [I] [SQL] SELECT `id`, `lower_name`, `name`, `full_name`, `email`, `keep_email_private`, `passwd`, `must_change_password`, `login_type`, `login_source`, `login_name`, `type`, `location`, `website`, `rands`, `salt`, `language`, `description`, `created_unix`, `updated_unix`, `last_login_unix`, `last_repo_visibility`, `max_repo_creation`, `is_active`, `is_admin`, `allow_git_hook`, `allow_import_local`, `allow_create_organization`, `prohibit_login`, `avatar`, `avatar_email`, `use_custom_avatar`, `num_followers`, `num_following`, `num_stars`, `num_repos`, `num_teams`, `num_members`, `visibility`, `diff_view_style`, `theme` FROM `user` WHERE `lower_name`=? LIMIT 1 []interface {}{"sdfwe"} 2019/08/01 21:44:53 ...xorm/session_find.go:199:noCacheFind() [I] [SQL] SELECT `id`, `type`, `name`, `is_actived`, `is_sync_enabled`, `cfg`, `created_unix`, `updated_unix` FROM `login_source` WHERE (is_actived = ?) []interface {}{true} 2019/08/01 21:44:53 ...s/context/context.go:202:HandleText() [E] invalid credentials ```
GiteaMirror commented 2025-11-02 04:11:39 -06:00
Author
Owner
Copy Link

@GAS85 commented on GitHub (Jul 18, 2022):

Since I run a reverse proxy to gitea with nginx, I also had to add this to my nginx config so that the IPs all didn't show up as 127.0.0.1

proxy_set_header X-Real-IP $remote_addr;

This seems very old issue. Could be please documentation updated? E.g. Add how to set this header in all Reverse Proxies examples here https://docs.gitea.io/en-us/reverse-proxies/.
I came here to check Apache2 solution for the header.

@GAS85 commented on GitHub (Jul 18, 2022): > Since I run a reverse proxy to gitea with nginx, I also had to add this to my nginx config so that the IPs all didn't show up as 127.0.0.1 > > proxy_set_header X-Real-IP $remote_addr; This seems very old issue. Could be please documentation updated? E.g. Add how to set this header in all Reverse Proxies examples here https://docs.gitea.io/en-us/reverse-proxies/. I came here to check Apache2 solution for the header.
GiteaMirror commented 2025-11-02 04:11:39 -06:00
Author
Owner
Copy Link

@delvh commented on GitHub (Apr 29, 2023):

By default, it is possible to bruteforce login on Gitea...
From reading other topics, it seems fail2ban is the preferred way to protect from these attacks.

Yes.

IMO This is an important message to tell to new users in the "Installation" docs, including a tutorial on how to set it up (eg. using Docker) - both for gitea login and git login bruteforce attacks.

Exists already as you linked the article yourself: https://docs.gitea.com/administration/fail2ban-setup

But I agree there should be an integrated solution in Gitea.

I disagree. I don't see how Gitea can do this better than a service that is specialized for these kinds of things.
Every approach to implement it in Gitea will only bloat Gitea substantially.

So, as everything mentioned in this issue has been implemented, I think we can close this one.

@delvh commented on GitHub (Apr 29, 2023): > By default, it is possible to bruteforce login on Gitea... From reading other topics, it seems fail2ban is the preferred way to protect from these attacks. Yes. > IMO This is an important message to tell to new users in the "Installation" docs, including a tutorial on how to set it up (eg. using Docker) - both for gitea login and git login bruteforce attacks. Exists already as you linked the article yourself: https://docs.gitea.com/administration/fail2ban-setup > But I agree there should be an integrated solution in Gitea. I disagree. I don't see how Gitea can do this better than a service that is specialized for these kinds of things. Every approach to implement it in Gitea will only bloat Gitea substantially. So, as everything mentioned in this issue has been implemented, I think we can close this one.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label topic/security
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#1733
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?