gitlabとgitoliteをパスワードとキーから保護する

ごく最近、gitlabのパスワードとsshのキーの選択に対する攻撃が、gitリポジトリを備えた私のサーバーで始まりました。 攻撃者の意図は明らかです-gitに保存されている独自のアプリケーションのソースコードを取得するため。



私はsshキーを選択しようとする試みをよく理解していません、なぜなら RSAキーを取得するのは問題があります（これには数十年かかります）が、ログが「乱雑」にならないように、まだいくつかの制限を設けました。



パスワードの推測からgitoliteとgitlab（nginxに対応）を保護する方法を気にする人-catへようこそ。

SSH保護。

Linux上のsshdだけでは接続数を制限できないことを多くの人が知っています。 これは問題ではありませんでした。ファイアウォールレベルに制限しました。



CentOSの標準iptablesディストリビューションには、hashlimitモジュールがあります。 それを使用します。 iptablesについて次のルールを作成しました。

iptables -N ssh_input iptables -A ssh_input \ -m hashlimit \ --hashlimit 5/m \ --hashlimit-burst 5 \ --hashlimit-mode srcip,dstport \ --hashlimit-name ssh \ --hashlimit-htable-expire 3600000 \ -j ACCEPT iptables -A ssh_input -p tcp -j REJECT --reject-with tcp-reset iptables -A INPUT -m state -m tcp -p tcp --dport 22 --state NEW -j ssh_input
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私たちは何をしましたか？ 最初にssh_inputチェーンを追加しました。 次に、接続数を1分あたり5に制限するルールを追加します（--hashlimit 5 / m --hashlimit-burst 5）。 その中で、接続をグループ化する価値のあるパラメーターを示します（--hashlimit-mode srcip、dstport）。 アクセスを拒否するルールを追加した後（-j REJECT）。 そして、接続が新規でポート22に到達する必要があるという条件で、入力にチェーンを追加します。



これらのルールはどのように機能しますか？ ポート22の新しい接続フラグを持つすべてのパケットは、処理のためにssh_inputチェーンに送信されます。 そこでは、特定のIPからのそのような接続の数が1分あたり5を超えないという条件の下で、パケットが渡されます（-j ACCEPT）。 条件が満たされない場合は、次のルール-j REJECTに進みます。



現在、攻撃者はsshキーを数年（数十年、数百年？）取得できます。 そして、ログの「混乱」は少なくなります。

Gitlabの保護

また、攻撃者はgitlab Webインターフェイスのパスワードを取得しようとします。 フロントエンドとして、Nginxを使用します。 彼はかなり古いバージョン0.8.55を使用しており、今すぐ更新するのは時間と欲望ではありません。



まず、基本認証を追加し、1分あたりの接続数を制限します（そのため、このパスワードを取得するのはそれほど簡単ではありません）。 私たちの場合の制限の問題は、Webページを読み込むと、静的サーバーの呼び出しが約15回増えることです。 これにより、1秒間に15を超える接続が許可されます。 それは私たちを修正しません。 各IPに1秒あたり15の接続があるため、攻撃者はパスワードを取得でき、次の「耳を傾ける」ことができます。



基本認証のユーザー名とパスワードはすべてのユーザーに共通であり 、Webアプリケーション自体からのパスワードの選択に対する障害としてのみ機能します。 その場合、次のチェックを実行できます。

 if ($http_authorization != "Basic secretdsddsaadsdsasad=="){ return 403; break; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

/以外のすべてのURL。 オン/基本的な認証を行い、1 ipに対して1分あたり5回の試行を制限します。

 limit_req_zone $binary_remote_addr zone=one:10m rate=5r/m; ... server { .... location = / { auth_basic "Top secret"; auth_basic_user_file /etc/nginx/conf.d/ssl/.htpasswd; limit_req zone=one burst=5 nodelay; ..... } .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、基本パスワードがまだ取得または盗まれていることを想像してみましょう。 アプリケーションのログインフォームも保護します。

 limit_req_zone $binary_remote_addr zone=two:10m rate=5r/m; ... server { ... location = /users/sign_in { if ($http_authorization != "Basic secretdsddsaadsdsasad=="){ //       basic  return 403; break; } limit_req zone=two burst=5 nodelay; .... } .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして最後に、他の住所の主要な場所：

 server { ... location / { if ($http_authorization != "Basic secretdsddsaadsdsasad=="){ //       basic  return 403; break; } ... } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、ルート以外のURLで基本認証なしで要求すると、403が返されます。基本認証はルートでのみ可能であり、1分あたり5要求に制限されています。 基本承認を選択した場合でも、Webアプリケーションの承認フォームは1分あたり5リクエストに制限されています。 異なるゾーンで、異なる場所で異なるパスワードを入力する際のエラーが蓄積せず、実際のユーザーが「サービスを利用できない」ことを防ぐために、基本アプリケーションとWebアプリケーションの入力の制限を強調しました。