mirror of
https://github.com/wahyd4/gitlabhq.git
synced 2026-08-23 19:46:12 +10:00
Merge branch 'rack_attack' of /home/git/repositories/gitlab/gitlabhq
This commit is contained in:
@@ -20,6 +20,7 @@ Vagrantfile
|
||||
config/gitlab.yml
|
||||
config/database.yml
|
||||
config/initializers/omniauth.rb
|
||||
config/initializers/rack_attack.rb
|
||||
config/unicorn.rb
|
||||
config/resque.yml
|
||||
config/aws.yml
|
||||
|
||||
@@ -120,6 +120,9 @@ gem "underscore-rails", "~> 1.4.4"
|
||||
# Sanitize user input
|
||||
gem "sanitize"
|
||||
|
||||
# Protect against bruteforcing
|
||||
gem "rack-attack"
|
||||
|
||||
group :assets do
|
||||
gem "sass-rails"
|
||||
gem "coffee-rails"
|
||||
|
||||
@@ -334,6 +334,8 @@ GEM
|
||||
rack (1.4.5)
|
||||
rack-accept (0.4.5)
|
||||
rack (>= 0.4)
|
||||
rack-attack (2.2.1)
|
||||
rack
|
||||
rack-cache (1.2)
|
||||
rack (>= 0.4)
|
||||
rack-mini-profiler (0.1.31)
|
||||
@@ -608,6 +610,7 @@ DEPENDENCIES
|
||||
poltergeist (~> 1.4.1)
|
||||
pry
|
||||
quiet_assets (~> 1.0.1)
|
||||
rack-attack
|
||||
rack-mini-profiler
|
||||
rails (= 3.2.13)
|
||||
rails-dev-tweaks
|
||||
|
||||
@@ -30,5 +30,8 @@
|
||||
%li
|
||||
%strong= link_to "Public Access", help_public_access_path
|
||||
|
||||
%li
|
||||
%strong= link_to "Security", help_security_path
|
||||
|
||||
.span9.pull-right
|
||||
= yield
|
||||
|
||||
@@ -79,3 +79,7 @@
|
||||
%li
|
||||
%strong= link_to "Public Access", help_public_access_path
|
||||
%p Learn how you can allow public access to a project.
|
||||
|
||||
%li
|
||||
%strong= link_to "Security", help_security_path
|
||||
%p Learn what you can do to secure your GitLab instance.
|
||||
|
||||
@@ -0,0 +1,15 @@
|
||||
= render layout: 'help/layout' do
|
||||
%h3.page-title Security
|
||||
|
||||
%p.slead
|
||||
If your GitLab instance is visible from the internet chances are it will be 'tested' by bots sooner or later.
|
||||
%br
|
||||
%br
|
||||
%br
|
||||
.file-holder
|
||||
.file-title
|
||||
%i.icon-file
|
||||
Dealing with bruteforcing
|
||||
.file-content.wiki
|
||||
= preserve do
|
||||
= markdown File.read(Rails.root.join("doc", "security", "rack_attack.md"))
|
||||
@@ -77,5 +77,8 @@ module Gitlab
|
||||
# 3) In your unicorn.rb: ENV['RAILS_RELATIVE_URL_ROOT'] = "/gitlab"
|
||||
#
|
||||
# config.relative_url_root = "/gitlab"
|
||||
|
||||
# Uncomment to enable rack attack middleware
|
||||
# config.middleware.use Rack::Attack
|
||||
end
|
||||
end
|
||||
|
||||
@@ -0,0 +1,16 @@
|
||||
# To enable rack-attack for your GitLab instance do the following:
|
||||
# 1. In config/application.rb find and uncomment the following line:
|
||||
# config.middleware.use Rack::Attack
|
||||
# 2. Rename this file to rack_attack.rb
|
||||
# 3. Review the paths_to_be_protected and add any other path you need protecting
|
||||
# 4. Restart GitLab instance
|
||||
#
|
||||
|
||||
paths_to_be_protected = [
|
||||
"#{Rails.application.config.relative_url_root}/users/password",
|
||||
"#{Rails.application.config.relative_url_root}/users/sign_in",
|
||||
"#{Rails.application.config.relative_url_root}/users"
|
||||
]
|
||||
Rack::Attack.throttle('protected paths', limit: 6, period: 60.seconds) do |req|
|
||||
req.ip if paths_to_be_protected.include?(req.path) && req.post?
|
||||
end
|
||||
@@ -39,6 +39,7 @@ Gitlab::Application.routes.draw do
|
||||
get 'help/web_hooks' => 'help#web_hooks'
|
||||
get 'help/workflow' => 'help#workflow'
|
||||
get 'help/shortcuts'
|
||||
get 'help/security'
|
||||
|
||||
#
|
||||
# Global snippets
|
||||
|
||||
@@ -195,6 +195,13 @@ You can change `6-1-stable` to `master` if you want the *bleeding edge* version,
|
||||
# Ex. change amount of workers to 3 for 2GB RAM server
|
||||
sudo -u git -H editor config/unicorn.rb
|
||||
|
||||
# Copy the example Rack attack config
|
||||
sudo -u git -H cp config/initializers/rack_attack.rb.example config/initializers/rack_attack.rb
|
||||
|
||||
# Enable rack attack middleware
|
||||
# Find and uncomment the line 'config.middleware.use Rack::Attack'
|
||||
sudo -u git -H editor config/application.rb
|
||||
|
||||
# Configure Git global settings for git user, useful when editing via web
|
||||
# Edit user.email according to what is set in gitlab.yml
|
||||
sudo -u git -H git config --global user.name "GitLab"
|
||||
|
||||
@@ -0,0 +1,19 @@
|
||||
To prevent abusive clients doing damage GitLab uses rack-attack gem.
|
||||
If you installed or upgraded GitLab by following the official guides this should be enabled by default.
|
||||
If you are missing `config/initializers/rack_attack.rb` the following steps need to be taken in order to enable protection for your GitLab instance:
|
||||
|
||||
1. In config/application.rb find and uncomment the following line:
|
||||
config.middleware.use Rack::Attack
|
||||
2. Rename config/initializers/rack_attack.rb.example to config/initializers/rack_attack.rb
|
||||
3. Review the paths_to_be_protected and add any other path you need protecting
|
||||
4. Restart GitLab instance
|
||||
|
||||
By default, user sign-in, user sign-up(if enabled) and user password reset is limited to 6 requests per minute.
|
||||
After trying for 6 times, client will have to wait for the next minute to be able to try again.
|
||||
These settings can be found in `config/initializers/rack_attack.rb`
|
||||
|
||||
If you want more restrictive/relaxed throttle rule change the `limit` or `period` values. For example, more relaxed throttle rule will be if you set limit: 3 and period: 1.second(this will allow 3 requests per second). You can also add other paths to the protected list by adding to `paths_to_be_protected` variable. If you change any of these settings do not forget to restart your GitLab instance.
|
||||
|
||||
In case you find throttling is not enough to protect you against abusive clients, rack-attack gem offers IP whitelisting, blacklisting, Fail2ban style filter and tracking.
|
||||
|
||||
For more information on how to use these options check out [rack-attack README](https://github.com/kickstarter/rack-attack/blob/master/README.md).
|
||||
@@ -0,0 +1,100 @@
|
||||
# From 6.1 to 6.2
|
||||
|
||||
# You should update to 6.1 before installing 6.2 so all the necessary conversions are run.
|
||||
|
||||
### 0. Backup
|
||||
|
||||
It's useful to make a backup just in case things go south:
|
||||
(With MySQL, this may require granting "LOCK TABLES" privileges to the GitLab user on the database version)
|
||||
|
||||
```bash
|
||||
cd /home/git/gitlab
|
||||
sudo -u git -H RAILS_ENV=production bundle exec rake gitlab:backup:create
|
||||
```
|
||||
|
||||
### 1. Stop server
|
||||
|
||||
sudo service gitlab stop
|
||||
|
||||
### 2. Get latest code
|
||||
|
||||
```bash
|
||||
cd /home/git/gitlab
|
||||
sudo -u git -H git fetch
|
||||
sudo -u git -H git checkout 6-2-stable
|
||||
```
|
||||
|
||||
### 3. Update gitlab-shell
|
||||
|
||||
```bash
|
||||
cd /home/git/gitlab-shell
|
||||
sudo -u git -H git fetch
|
||||
sudo -u git -H git checkout v1.7.1
|
||||
```
|
||||
|
||||
### 4. Install libs, migrations, etc.
|
||||
|
||||
```bash
|
||||
cd /home/git/gitlab
|
||||
|
||||
# MySQL
|
||||
sudo -u git -H bundle install --without development test postgres --deployment
|
||||
|
||||
#PostgreSQL
|
||||
sudo -u git -H bundle install --without development test mysql --deployment
|
||||
|
||||
|
||||
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
|
||||
sudo -u git -H bundle exec rake migrate_iids RAILS_ENV=production
|
||||
sudo -u git -H bundle exec rake assets:clean RAILS_ENV=production
|
||||
sudo -u git -H bundle exec rake assets:precompile RAILS_ENV=production
|
||||
sudo -u git -H bundle exec rake cache:clear RAILS_ENV=production
|
||||
```
|
||||
|
||||
### 5. Update config files
|
||||
|
||||
* Make `/home/git/gitlab/config/gitlab.yml` same as https://github.com/gitlabhq/gitlabhq/blob/6-2-stable/config/gitlab.yml.example but with your settings.
|
||||
* Make `/home/git/gitlab/config/unicorn.rb` same as https://github.com/gitlabhq/gitlabhq/blob/6-2-stable/config/unicorn.rb.example but with your settings.
|
||||
* Copy rack attack middleware config
|
||||
```bash
|
||||
sudo -u git -H cp config/initializers/rack_attack.rb.example config/initializers/rack_attack.rb
|
||||
```
|
||||
* Uncomment `config.middleware.use Rack::Attack` in `/home/git/gitlab/config/application.rb`
|
||||
|
||||
### 6. Update Init script
|
||||
|
||||
```bash
|
||||
sudo rm /etc/init.d/gitlab
|
||||
sudo curl --output /etc/init.d/gitlab https://raw.github.com/gitlabhq/gitlabhq/6-2-stable/lib/support/init.d/gitlab
|
||||
sudo chmod +x /etc/init.d/gitlab
|
||||
```
|
||||
|
||||
### 7. Start application
|
||||
|
||||
sudo service gitlab start
|
||||
sudo service nginx restart
|
||||
|
||||
### 8. Check application status
|
||||
|
||||
Check if GitLab and its environment are configured correctly:
|
||||
|
||||
sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production
|
||||
|
||||
To make sure you didn't miss anything run a more thorough check with:
|
||||
|
||||
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production
|
||||
|
||||
If all items are green, then congratulations upgrade complete!
|
||||
|
||||
## Things went south? Revert to previous version (6.1)
|
||||
|
||||
### 1. Revert the code to the previous version
|
||||
Follow the [`upgrade guide from 6.0 to 6.1`](6.0-to-6.1.md), except for the database migration
|
||||
(The backup is already migrated to the previous version)
|
||||
|
||||
### 2. Restore from the backup:
|
||||
|
||||
```bash
|
||||
cd /home/git/gitlab
|
||||
sudo -u git -H RAILS_ENV=production bundle exec rake gitlab:backup:restore
|
||||
```
|
||||
Reference in New Issue
Block a user