ごく最近、営業日の真っat中に、クライアントからサイトがXSS / SQL攻撃を受けているという不穏な情報を受け取りましたが、その一部は成功しました。 数時間以内に行動を起こし、基本的な保護を設定することが急務でした。 開発者は、コードの欠陥をすばやく見つけて取り除くことができませんでした。
ある程度の検討の後、選択は、技術的にはnginxモジュールであるnaxsiと呼ばれるnginxのWebアプリケーションのファイアウォールに落ちました。 Naxsiは原則に従って機能します。許可されていないものはすべて禁止されています。 各HTTP要求（GET | PUT | POST）は、naxsi_core.rulesファイルにデフォルトで設定されている禁止ルールテンプレートに準拠しているかどうかがチェックされます。 これらの単純なルールは、悪意のあるリクエストのすべての可能なバリアントの99％をカバーします。 たとえば、デフォルトでは、文字「<」を含むURI内のすべての要求は拒否されます。 アプリケーションでこのようなシンボルの使用が通常の操作に必要な場合は、対応する例外をホワイトリストに手動で登録する必要があります。
このアプローチは、次のような高レベルの保護を提供します。 naxsiには、「未知のタイプの攻撃」というものはありません。フィルタリングで既知の脆弱性のシグネチャを使用する他のセキュリティシステムの場合と同様です。 しかし、コインには裏返しがあります。許可ルールがうまく機能していない場合、naxsiは法的要求の一部もブロックします。 最終結果に対する責任は、モジュールの開発者がシステム管理者に完全に委ねられます。 これらの考えに基づいて、モジュールのインストールを開始しました。
クライアントのサイトではCentOS 6が実行されています。残念ながら、CentOS 6でnaxsiモジュールがオンになっている既製のnginxパッケージはなかったため、自分でコンパイルする必要がありました。
当社には、ソースのインストールを禁止するポリシーがあります。そのため、同僚が問題を解決するために、必要に応じてリポジトリから取得できるrpmパッケージを作成しました。
パッケージからのインストール：
rpm -Uvh http://rpms.southbridge.ru/southbridge-rhel6-stable.rpm yum install -y nginx-naxsi
自動実行にnginxを追加します：
chkconfig nginx on
標準のnaxsi 拒否ルールを使用してファイルを作成します。
wget -O /etc/nginx/naxsi_core.rules https://raw.githubusercontent.com/nbs-system/naxsi/master/naxsi_config/naxsi_core.rules
httpコンテキストのnginx構成に標準の禁止ルールを含めます。
/etc/nginx/nginx.conf
http { ... include /etc/nginx/naxsi_core.rules; ... }
naxsi構成ファイルを作成します。
touch /etc/nginx/my_naxsi.rules cat << EOF >/etc/nginx/naxsi.rules LearningMode; # . SecRulesEnabled; #SecRulesDisabled; DeniedUrl "/RequestDenied"; include "/etc/nginx/my_naxsi.rules"; ## check rules CheckRule "$SQL >= 8" BLOCK; CheckRule "$RFI >= 8" BLOCK; CheckRule "$TRAVERSAL >= 4" BLOCK; CheckRule "$EVADE >= 4" BLOCK; CheckRule "$XSS >= 8" BLOCK; EOF
目的の仮想ホストのnaxsiを有効にします。
server { ... set $naxsi_extensive_log 1; # ... location / { ... include /etc/nginx/naxsi.rules; ... } ... location /RequestDenied { return 500; # "" 500 } ... }
nginxを再起動します。
service nginx restart
これから、naxsiはトレーニングモードになります。 要求はブロックされませんが、指定されたnginx仮想ホストのエラーログにアクティブに記録されます。トレーニングモードでサイトの将来の操作を妨げないように、サイトに正当なトラフィックを提供して、できるだけ多くの異なる要求が通常に行われるようにする必要があります仕事。
トレーニング後、基本的な禁止ルールのホワイトリストの生成に進みます。 これは、nx_util.pyユーティリティを使用して手動または自動で実行できます。
wget -O /tmp/naxsi.zip https://github.com/nbs-system/naxsi/archive/0.53-2.zip unzip /tmp/naxsi.zip rm -f /tmp/naxsi.zip sed -i 's/\/usr\/local\/etc/\/tmp\/naxsi-0.53-2\/nx_util/' /tmp/naxsi-0.53-2/nx_util/nx_util.py python /tmp/naxsi-0.53-2/nx_util/nx_util.py -l <///errorlog-> -o
このユーティリティは、NAXSIからのエントリについてエラーログファイルを解析し、生成された例外のリストを操作の頻度でソートしてstdoutに出力します。 この場合、リストの下からのルールはデフォルトでコメント化できます。
データ生成された例外、それらの完全性および正確性が主な要因です-Naxsiフィルタリングがどの程度効果的に適用されるか。 自動生成されたルールは、必要に応じて分析および編集する必要があります。 公式ドキュメントを調べることで、ルールの構文を理解できます。
結果のホワイトリストルールを/etc/nginx/my_naxsi.rulesファイルにコピーします。
naxsi戦闘モードをオンにします。
sed -i 's/LearningMode/#LearningMode/' /etc/nginx/naxsi.rules
nginxを再起動します。
nginx -t service nginx reload
基本的なセットアップが完了しました！
モジュールが戦闘モードになっている間に、一部の法的要求がまだ考慮されずにブロックされている場合は、/ etc / nginx / my_naxsi.rulesファイルのホワイトリストに追加する必要があります。 これを行うには、nx_util.pyを再実行するか、エラーログのNAXSIエントリを分析し、自分で例外を書き込む方法を学習します。
要求がブロックされているかどうかを確認できます。
cat <///errorlog-> | grep NAXSI
そのため、わずか数時間で、XSS / SQL攻撃に対するサイトの基本的な保護が編成されました。 そして、開発者は急いで、コードの欠陥を解消し続けました。
それだけです ご清聴ありがとうございました！
Last_Lameによる投稿
私たちは、個人的な通信またはメールでの質問に喜んでお答えしますask@centos-admin.ru