提交 ac6180bc 编写于 作者: D Dmitriy Zaporozhets

Merge branch 'rack_attack' of /home/git/repositories/gitlab/gitlabhq

......@@ -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.
= 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
# 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"
......
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).
\ No newline at end of file
# 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
```
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册