カテゴリー: PC Page 25 of 51

同一サーバ内でRedmineのドメインを変更するときの設定。(apacheバーチャルファイル編集)

ちょっとした事情で、既に稼働しているRedmineのドメインを変更しました。以下、作業メモです。

環境

  • Ubuntu 20.04
  • Apache 2.4系
  • Redmine 4.2系

前提

  • apacheのバーチャルサイトでRedmineを設定していること。
  • 新しく割り当てるドメインが、稼働サーバと同じであること。
  • 新しいドメインの適切な証明書を取得し、所定の箇所に格納していること。

ここでは、aaa.hoge.comをbbb.hoge.comに変える手順を行います。

さっくりとした手順

  1. バーチャルサイトの設定ファイルをコピーします。(aaa→bbb)
  2. 新たなドメインの設定ファイルを編集します。
  3. 以前の設定ファイルを無効化します。
  4. 新たな設定ファイルを有効化します。
  5. apacheの再起動を行います。
  6. Redmineの設定変更を行います。

手順

設定ファイルコピー

cd /etc/apache2/sites-available && pwd
# 自分の環境に合わせます。

sudo cp -pi aaa.hoge.com.conf bbb.hoge.com.conf
# 設定ファイルは自身の環境に合わせます。

ファイル編集

以下の差分の通り修正します。信仰・教義に沿ったエディタで編集してください。

 <VirtualHost _default_:80>
-servername aaa.hoge.com
+servername bbb.hoge.com

 <VirtualHost _default_:443>
-    servername aaa.hoge.com
+    servername bbb.hoge.com

-SSLCertificateFile /etc/certs/aaa.hoge.com.crt
-SSLCertificateKeyFile /etc/private/aaa.hoge.com.key
+SSLCertificateFile /etc/certs/bbb.hoge.com.crt
+SSLCertificateKeyFile /etc/private/bbb.hoge.com.key
# 証明書と秘密鍵の適切な格納場所を指定します。
# ホスト名のみ変更し、ワイルドカード証明書を利用するのであれば証明書の部分は修正する必要はありません。

変更前設定ファイルの無効化

sudo a2dissite aaa.hoge.com.conf
# サービス再起動を求められますが、最後にまとめて行います。

変更後設定ファイルの有効化

sudo a2ensite bbb.hoge.com.conf

サービス再起動

  • 設定ファイル構文チェック
sudo apache2ctl configtest
# Syntax OKを確認します。
  • サービス再起動
sudo systemctl restart apache2.service

変更後の設定変更

  1. ブラウザで、変更後のドメインにアクセスします。
  2. 管理者権限でログインします。
    • ドメイン以外の設定は変えていないので、ログインは行えます。
    • ビルトインの2段階認証を利用している場合変更前のワンタイムパスワードを利用してください。
  3. 設定→管理に移動します。
  4. 概要タブのホスト名とパスを変更後のものに合わせます。

Ubuntu20.04のOpenSSLを1.1.1から3.1.1にアップデート。

概要

2023/09/11にサポート終了を迎えるOpenSSL1.1.1。

2023年6月現在の最新安定版である3.1.1にアップデートを行います。

https://www.openssl.org/blog/blog/2023/06/15/1.1.1-EOL-Reminder/

環境

  • OS:Ubuntu 20.04
openssl version -a
OpenSSL 1.1.1f  31 Mar 2020
built on: Wed May 24 17:14:51 2023 UTC
platform: debian-amd64
options:  bn(64,64) rc4(16x,int) des(int) blowfish(ptr) 
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-mSG92N/openssl-1.1.1f=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_TLS_SECURITY_LEVEL=2 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAESNI_ASM -DVPAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
OPENSSLDIR: "/usr/lib/ssl"
ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-1.1"
Seeding source: os-specific

参考とした手順

https://nextgentips.com/2022/03/23/how-to-install-openssl-3-on-ubuntu-20-04/

さっくりとした手順

  1. システム全体のバックアップ
  2. 必要なライブラリをインストールします。
  3. githubレポジトリから最新安定版のソースコードをダウンロードします。
  4. ソースからインストールしていきます。
  5. 設定を行います。(コンフィグを反映させ、パスを通します)
  6. バージョンアップを確認します。

実施した手順

全体のバックアップを取得します。

  • Webアクセスの根幹となるプログラムであること
  • 重要なデータが格納されている

ことから、AWS Lightsailのスナップショットを利用して全体のバックアップを取りました。

必要なライブラリのインストール

sudo aptitude install build-essential checkinstall zlib1g-dev
# 筆者はaptitudeを用いています。必要に応じてaptを使ってください。

ソースコードの取得

sudo su -
# 以下、管理者権限で実施します

cd /hoge
# 任意のディレクトリを指定します

git clone https://github.com/openssl/openssl -b openssl-3.1.1
# 2023/06/20時点での最新安定版を指定します

cd openssl

ソースからインストール

./config --prefix=/usr/local/ssl --openssldir=/usr/local/ssl shared zlib

make
# makeは時間がかかります。状況を時折確認しながら待ちましょう。

make test

make install

インストール後の設定

  • 設定ファイル追記
cat <<- __EOF__ | tee -a /etc/ld.so.conf.d/openssl-3.1.1.conf
/usr/local/ssl/lib64
__EOF__
  • 設定反映
ldconfig -v
  • 既存プログラムの退避
mv /usr/bin/c_rehash /path/to/backup/c_rehash.$(date +%Y%m%d)

mv /usr/bin/openssl /path/to/backup/openssl.$(date +%Y%m%d)
# 任意の退避ディレクトリを指定します
  • パスを通す
cat <<- __EOF__ | tee -a /etc/environment
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/local/ssl/bin"
__EOF__
  • 通したパスを反映
source /etc/environment

echo $PATH
# PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/local/ssl/bin"
# と表示されることを確認します

バージョンアップ後の確認

openssl version -a
OpenSSL 3.1.1 30 May 2023 (Library: OpenSSL 3.1.1 30 May 2023)
built on: Tue Jun 20 01:47:24 2023 UTC
platform: linux-x86_64
options:  bn(64,64)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DZLIB -DNDEBUG
OPENSSLDIR: "/usr/local/ssl"
ENGINESDIR: "/usr/local/ssl/lib64/engines-3"
MODULESDIR: "/usr/local/ssl/lib64/ossl-modules"
Seeding source: os-specific
CPUINFO: OPENSSL_ia32cap=0x7ffaf3ffffebffff:0x27ab

これで、Ubuntu20.04でもOpenSSL3.1.1を利用することが可能になりました。

必要に応じて

  • システムの再起動を行います。
  • 既存サービスが正常に動くことを確認します。

作業日

2023/06/22

nginxでリバースプロキシ化しているgrowiサイトにセキュリティヘッダーを付与。

はじめに

現在、growiのリバースプロキシとしてnginxを利用しています。

そこで、先だってご紹介したapache利用のサイトと同じようにセキュリティヘッダーを付与しました。

環境

  • Ubuntu 20.04
  • Growi v6.1.4
  • nginx 1.24.0

前提

  • サーバへの適切な証明書は準備済みです。
  • 既にGrowiが稼働しているものとします。(hoge.example.com)

コンフィグファイル

以下、教義・信仰に沿ったエディタで編集します。自分の環境に合わせてください。

  • ファイル名:/etc/nginx/sites-available/growi
upstream hoge {
       server 192.168.1.101:3000;
       #growiが稼働しているアドレス
}

server {
## http設定(常時SSL化を行います)
        listen 80 http2;
        server_name hoge.example.com;
        server_tokens off;
        return  301 https://$host$request_uri;
        access_log /var/log/nginx/hoge.example.com/access.log;
        error_log /var/log/nginx/hoge.example.com/error.log warn;
}

server {
## https設定
        listen 443 ssl http2;
        server_name hoge.example.com;
        server_tokens off;
        ssl_session_timeout 1d;
        ssl_session_cache shared:SSL:50m;
        ssl_session_tickets off;
        ssl_dhparam /etc/nginx/dhparam;
        ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
        ssl_prefer_server_ciphers off;

        #SecurityHeader
        add_header Strict-Transport-Security 'max-age=63072000';
        add_header X-Content-Type-Options "nosniff";
        add_header X-Frame-Options "SAMEORIGIN";
        add_header X-XSS-Protection "1; mode=block";

        ssl_certificate /etc/certs/hoge.example.com.crt;
        ssl_certificate_key /etc/private/hoge.example.com.key;

        ssl_stapling on;
        ssl_stapling_verify on;

        access_log /var/log/nginx/hoge.example.com/ssl_access.log;
        error_log /var/log/nginx/hoge.example.com/ssl_error.log warn;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_max_temp_file_size 10240m;
        client_max_body_size 10240m;
        proxy_redirect off;

       set $proxy_target  'hoge';

       location / {
          proxy_pass http://$proxy_target;
       }

       location /socket.io/ {
          proxy_http_version 1.1;
          proxy_set_header Upgrade $http_upgrade;
          proxy_set_header Connection "Upgrade";
          proxy_cache_bypass $http_upgrade;

        #SecurityHeader
        add_header Strict-Transport-Security 'max-age=63072000';
        add_header X-Content-Type-Options "nosniff";
        add_header X-Frame-Options "SAMEORIGIN";
        add_header X-XSS-Protection "1; mode=block";

          proxy_pass http://$proxy_target/socket.io/;
       }
}
  • 差分内容
+        #SecurityHeader
         add_header Strict-Transport-Security 'max-age=63072000';
+        add_header X-Content-Type-Options "nosniff";
+        add_header X-Frame-Options "SAMEORIGIN";
+        add_header X-XSS-Protection "1; mode=block";

           proxy_cache_bypass $http_upgrade;
+
+        #SecurityHeader
+        add_header Strict-Transport-Security 'max-age=63072000';
+        add_header X-Content-Type-Options "nosniff";
+        add_header X-Frame-Options "SAMEORIGIN";
+        add_header X-XSS-Protection "1; mode=block";
+
           proxy_pass http://$proxy_target/socket.io/;

コンフィグファイル反映

sudo nginx -t
# nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
# nginx: configuration file /etc/nginx/nginx.conf test is successful
# と出れば正常です

sudo systemctl restart nginx

セキュリティヘッダー付与確認

curlを用いて、開発者ツールよりも手っ取り早くヘッダ付与を確認します。

curl -I 上記、設定を行ったURL
strict-transport-security: max-age=63072000
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block

のように表示されればOKです。

Apacheで動かしているWebサイトにセキュリティヘッダーを付与。

概要

AWS Lightsailを用いて外部公開しているWebサイトのセキュリティを高めるため、セキュリティヘッダを更に付与しました。

環境

  • Ubuntu 20.04
  • Apache 2.4系
  • Headerモジュール導入済み

また、/etc/apache2/sites-availavle配下にバーチャルサイトファイルで管理しています。

さっくりとした手順

  1. 現行のバーチャルサイトのコンフィグのバックアップを取得します。
  2. コンフィグにセキュリティヘッダを付与します。
  3. Webサービスの再起動を行います。

実施した手順

バックアップ

cd /etc/apache2/sites-available &&pwd
# 自環境のバーチャルサイトの格納場所に移動します

sudo cp -pi hoge.conf /path/to/directory/hoge.conf.$(date +%Y%m%d)
# バックアップ元とバックアップ先は自分の環境に合わせます。

diff -u hoge.conf /path/to/directory/hoge.conf.$(date +%Y%m%d)
# 差分がないことでバックアップが取れていることを確認します。

セキュリティヘッダ追記

教義・進行に沿ったエディタを用いて、以下の差分になるようにセキュリティヘッダをコンフィグに付与します。

+    Header set X-Content-Type-Options "nosniff"
+    Header always append X-Frame-Options "SAMEORIGIN"
+    Header set X-XSS-Protection "1; mode=block"

以下はChantGPTによる解説です。

X-Content-Type-Options: "nosniff"

このヘッダーは、ブラウザがレスポンスのContent-Typeヘッダーと実際のコンテンツの種類が一致しない場合に、ブラウザが自動的にコンテンツのタイプを推測するのを防止します。これにより、悪意のあるコンテンツが実行されるリスクを低減することができます。

X-Frame-Options: "DENY" または "SAMEORIGIN"

このヘッダーは、クリックジャッキング攻撃を防止するために使用されます。"DENY" を指定すると、ページがフレーム内で表示されることが完全に禁止されます。"SAMEORIGIN" を指定すると、同じオリジン(ドメインとプロトコルが一致)のフレーム内でのみページが表示されます。

X-XSS-Protection: "1; mode=block"

このヘッダーは、クロスサイトスクリプティング(XSS)攻撃からの保護を目的としています。ブラウザによって検出されたXSS攻撃が検出された場合、ブラウザはページをブロックするように指示されます。

コンフィグの整合性確認と再起動

  • コンフィグ確認
sudo apache2ctl configtest
#Syntax OKを確認します
  • サービス再起動
sudo systemctl restart apache2.service

systemctl status apache2.service
#Active(running)を確認します

ヘッダ付与確認

  1. Google Chromeを開き、対象のウェブサイトにアクセスします。
  2. ウェブサイトを表示した状態で、右クリックしてコンテキストメニューを表示し、「検証」を選択します。
  3. 開発者ツールが表示されたら、上部のメニューバーの中から「Network」(ネットワーク)タブを選択します。
  4. ページをリロードするか、ウェブサイト上で任意のアクションを実行してネットワークタブにリクエストが表示されるようにします。
  5. ネットワークタブで、対象のリクエストを選択します。
  6. 右側のパネルで、"Headers"(ヘッダー)セクションを展開します。
  7. ヘッダーセクションには、レスポンスヘッダーが表示されるので、以下を確認してください。
  • X-Content-Type-Options
  • X-Frame-Options
  • X-XSS-Protection

ヘッダーが正しく設定されていれば、それぞれのヘッダーの値が表示されます。

Fail2banによる防御効果確認。

侵入防御システム、Fail2banを本格的に導入してから半年余り。その効果のフィードバックです。

導入環境

  • Ubuntu 20.04
  • Fail2ban 0.11.1
  • AWS Lightsailで運用しており、鍵交換認証を行っています。
  • Lightsailで開けているポートは22(SSH),80(http),443(https)の3つです。

設定ファイル

  • /etc/fail2ban/jail.local
[ufw]
enabled=true
filter=ufw.aggressive
action=iptables-allports
logpath=/var/log/ufw.log
maxretry=1
bantime=-1
ignoreip = 127.0.0.0/8 ::1
# 他、自環境のアクセス元

[sshd]
enabled=true
filter=sshd
mode=normal
port=22
protocol=tcp
logpath=/var/log/auth.log
maxretry=3
bantime=-1
ignoreip = 127.0.0.0/8 ::1
# 他、自環境のアクセス元

bantimeは「-1」。つまり、一度でもリストに入るような不審な兆候があれば、永久に追放します。

半年の経過

この設定で、どのぐらいのIPアドレスを弾いたのか、確認してみました。

  • 確認コマンド(ufw)
sudo fail2ban-client status ufw
  • 確認結果(ufw)
Status for the jail: ufw
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     0
|  `- File list:        /var/log/ufw.log
`- Actions
   |- Currently banned: 187
   |- Total banned:     187
   `- Banned IP list: (後略)
  • 確認コマンド(sshd)
sudo fail2ban-client status sshd
  • 確認結果(sshd)
Status for the jail: sshd
|- Filter
|  |- Currently failed: 0
|  |- Total failed:     29
|  `- File list:        /var/log/auth.log
`- Actions
   |- Currently banned: 5125
   |- Total banned:     5125
   `- Banned IP list: (後略)

驚くべきはSSHのリスト数。半年で5000件を超えているので、単純計算で一月に833件超。BANされたリストをランダムに選んでabusedIP (https://www.abuseipdb.com/)で検索をかけると、いずれも

Confidence of Abuse is 100%

と表示されるものがほとんどです。

  • 鍵交換認証だろうとお構いなしに攻撃を仕掛けるアクセス元の多さ
  • これらを(ほぼ自動的に)弾いてくれるシステムのありがたさ

を改めて思い知りました。また、IPアドレス固定サービスを利用しているのであれば、アクセス許可を固定する(ポジティブリスト形式)が確実です。

Nextcloud、メンテナンスモードの解除方法。

はじめに

プライベートのオンラインストレージをWebベースで構築できるNextcloud。

ブラウザ上からもアップデートなどを行えるのは大きな利点ですが:メンテナンス中にWebブラウザが落ちてしまった場合に

このようなメンテナンスモードが出ます。(ブラウザ上で処理ができなかったことが原因です)

サーバ自体を

sudo reboot

と再起動を行ってもその状態であることが多いです。

「処理が終わるまでブラウザを落とさず待つ」が正常な手順ですが、それを怠った場合のリカバリについてです。

動作環境

  • Ubuntu 20.04
  • Nextcloud
  • Apache 2.4
  • PHP8.1

さっくりとした手順

  1. Nextcloudサーバにアクセスします。
  2. 設定ファイルを書き換えます。
  3. Apacheサービスを再起動します。
  4. メンテナンスモードの解除を確認します。

Nextcloudサーバへのアクセス

cd /home/www-data/nextcloud/config && pwd
# 自分のディレクトリを指定します

コンフィグファイルのバックアップ

sudo cp -pi config.php /path/to/backup/directory/config.php.$(date +%Y%m%d)

ファイルの内容書き換え

sudo -u www-data sed -i "s/'maintenance' => true/'maintenance' => false/" config.php
# メンテナンスモードを無効化します。

apache2サービス再起動

sudo systemctl restart apache2.service

再起動後の確認

メンテナンスモードが解除されました。「アップデートを開始」をクリックします。(今度はブラウザを閉じないようにしましょう)

その後、NextcloudのWeb画面が出てきたので問題なくアップデートされました。

サイトのSSL強化。(HSTSプリロード)

概要

サイトのセキュリティを高めるため、HSTSプリロードを設定したときのメモとなります。

環境

  • OS: Ubuntu 20.04
  • Apache 2.4系
  • Let's Encryptで取得した証明書を利用

前提条件

  1. インターネット上に公開されたサイトであること。(非ローカル環境)
  2. 公開するWebサイトドメイン全てに適切な証明書が設定されていること。
  3. Webサーバの設定で、httpアクセス全てをhttpsに変換する設定になっていること。
  4. 必要なモジュール(header、SSL等)がインストールされていること。

ここでは、hoge.example.com というサイトに対してHSTSプリロードを設定します。

注意点

  • サブドメイン全てに対して適用されます。(hoge.example.comの場合はwww.example.comはもちろん、example.comも対象となることを注意してください)
  • https化されていないサイトに対してもhttps接続を強制します。つまり、他にhttps化されていないシステムに対してもです。
  • プリロードリストに登録された場合、解除はとても難しくなります。相応の運用が試されることに注意してください。

さっくりとした手順

  1. HSTSを有効にします。
  2. httpdサービスを再起動します。
  3. HSTSサイトにドメインを登録します。

実施手順

apacheのバーチャルサイトファイルを修正します。

  • 修正後のファイル

※ドメインやDocumentRoot等は書き換えてください。また、サブドメインごとに複数のサイトがある場合、その全てを修正します。

<VirtualHost _default_:80>
servername hoge.example.com
 RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>
<VirtualHost _default_:443>
    servername hoge.example.com
    ErrorLog /var/log/apache/error.log
    CustomLog /var/log/apache/access.log combined

DocumentRoot /var/www/html/hoge

    <Directory /var/www/html/hoge>
        Options -MultiViews
        AllowOverride All
        Require all granted
    </Directory>

  SSLEngine on
    Protocols h2 http/1.1
    Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

SSLCertificateFile /etc/certs/hoge.example.com.crt
SSLCertificateKeyFile /etc/private/hoge.example.com.key

</VirtualHost>

SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2
SSLCipherSuite          ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder     off
SSLSessionTickets       off
  • 主な差分
-    Header always set Strict-Transport-Security "max-age=63072000"
+    Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

-SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
+SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2
  • HSTSのプリロードを有効化しています。
  • ついでに弱いSSL(TLSv1.2)を無効化します。

apacheサービスを再起動します。

sudo apache2ctl configtest
# Syntax OKを確認します
sudo systemctl restart apache2.service

systemctl satus apache2.service
# active(running)を確認します。

HSTSプリロードサイトへの登録

  1. https://hstspreload.org/ にアクセスします。
  2. 上記で設定したドメイン名を入力して登録を進めていきます。(サブドメインは含みません)
  3. エラーがなければStatus: laplacemine.com is pending submission to the preload list.と表示されます。
  4. 2~3週間ほど待って正式に登録されるのを待ちます。

設定確認

  1. https://www.ssllabs.com/ssltest にアクセスします。
  2. HSTSを設定したサイトのドメイン名を入力して診断します。
  3. Strict Transport Security (HSTS) が「YEえs」となっていれば成功です。

タイムタグ、ライフログ。

Twitterの話題が元で:

英国に滞在していたときの記憶が蘇りました。なので、AWSにて管理しているPiwigoの写真を更新です。

ロンドン

https://hideout.reisalin.com/index.php?/category/7

こちらはテムズ川のクルーズに絞ったもの。

当時は晴れた日ばかりを選んで撮影したはずですが、こうしてみるとくすんだ空の色です。

コーンウォール

https://hideout.reisalin.com/index.php?/category/1

願わくば、6~7月にもう一度行きたい場所。自分にとって初めて目にする大西洋にも感動しました。

カンタベリー

https://hideout.reisalin.com/index.php?/category/12

ここも暮らしていた場所なので、感慨深いです。

改めて:写真というのは自分の思い出をタグ付けするものであり、明確な記録(ログ)であると思いました。

Mod_Securityが検知したIPアドレスの自動遮断スクリプト・修正。

以下のスクリプトを修正しました。

このスクリプトの主な動き

  1. Mod_Securityが検知したエラーログからIPアドレスのみを抜き出す。
  2. 重複を排除した上でsuscpicious_ip.YYYYMMDD形式で保存。
  3. 全てのsuscpicious_ip.YYYYMMDDを統合する。
  4. ここからnegativelist.txtを作成する。
  5. negativelist.txtの中に疑陽性(自身のアクセス元)のIPを排除する。
  6. Webサービスを再起動する。

そうして、「一度でもMod_Securityが疑わしいと検知すれば、次回以降のアクセスを許さない」という、言わば“ONE OUTS”システムを採用しています。

この可読性を高めました。

スクリプトが動く前提

  • ApacheとMod_Securityを運用している。
  • 以下のように、「negativelist.txt」に記録されたIP全てをブロックするようにしている。

apacheバーチャルサイト設定の抜粋

# Mod Security
SecRuleEngine On
## ModSecurity有効化
SecRequestBodyInMemoryLimit 524288000
SecRequestBodyLimit 524288000
## ファイルのアップロードをできるようにします。
    # ネガティブリスト
    SecRule REMOTE_ADDR "@pmFromFile negativelist.txt" "phase:1,id:2,deny,msg:'Negativelisted IP address'"

修正したスクリプト

※ 教義・信仰に沿ったエディタで記載します。

  • negativelist.sh
#!/bin/bash
# このシェルスクリプトは、変数で定義したエラーログからIPアドレスを抽出し、
# suspicious_ipディレクトリに保存し、その後、特定のIPアドレスを削除して
# /etc/apache2/sites-available/negativelist.txtに書き込むものです。

# 読み込むログのディレクトリとファイル名を変数指定
log_dir="/var/lib/redmine/log"
log_file="error.log"

# 除外するIPアドレスをファイルで指定
exclude_ips_file="/path/to/exclude_ips.txt"

# IPアドレスを抽出して重複を排除し、ファイルに保存
cd "$log_dir"
awk 'match($0,/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/) { print substr($0, RSTART, RLENGTH) }' "$log_file" | sort | uniq > "$log_dir/suspicious_ip/suspicious_ip.$(date +%Y%m%d)"
chown www-data:www-data "$log_dir/suspicious_ip/suspicious_ip.$(date +%Y%m%d)"

# 過去のIPアドレスを読み込んで重複を排除し、ファイルに保存
cat "$log_dir/suspicious_ip/suspicious_ip."2* | sort | uniq > "$log_dir/suspicious_ip_all.txt"
chown www-data:www-data "$log_dir/suspicious_ip_all.txt"

# 新たにリストに書き起こす
cat "$log_dir/suspicious_ip_all.txt" > /etc/apache2/sites-available/negativelist.txt

# 除外するIPアドレスをファイルから削除
while IFS= read -r exclude_ip; do
  sed -i "/$exclude_ip/d" /etc/apache2/sites-available/negativelist.txt
done < "$exclude_ips_file"

# Apacheを再起動
systemctl restart apache2.service
  • 除外するIPアドレスリスト

※ 教義・信仰に沿ったエディタで作成します。

  • exclude_ips.txt 記載例
192.168.0.1
172.28.0.1
# 一行ずつ記載

記載後の設定

  • スクリプトの所有者変更
sudo chown root:root negativelist.sh
  • スクリプトの実行権付与
sudo chmod 744 negativelist.sh
  • cron登録
sudo crontab -e -u root
  • cron内容
0 6 * * * /home/manualmaton/bin/negativelist.sh

これによって、スクリプトを変数化。他のサーバへの転用を行いやすくしました。

Let’s Encryptの証明書をRSA方式で更新。

以前ご案内した、Let's Encryptのデフォルト暗号化形式がデフォルトでECDSA方式に変更されたという話。

ただ、サーバの環境によっては、この暗号化形式をサポートしていない事があります。(ワイルドカード証明書を様々なサーバに適用するケースでありがちです)
本来ならばサーバそのもののバージョンアップを図るべきでしょうが、運用によってはままならず。

そんなときにLet's Encryptの暗号化を従来のRSA方式に変える方法をメモしておきます。

前提

  • Let's EncryptでSSLを利用している。
  • 適用するサーバがECDSA方式の暗号化形式に対応していない。

作業手順

Let's Encrypt(Certbot)サーバで実施します。

ここでは、

  • hoge.example.com ドメインのワイルドカード証明書を取得し
  • 有効期限前にhoge@example.com宛にメールを送付する

として手順を示します。

証明書更新

sudo certbot certonly --manual -d\
*.hoge.example.com\
 -m hoge@example.com\
 --agree-tos --manual-public-ip-logging-ok\
 --key-type rsa --preferred-challenges dns-01
# ディレクトリやメールアドレスは自身の環境に合わせます。
# --key-type rsa を明示します

この後、DNSでTXTレコードを設定するよう求められるので、それに従いDNSの所有権を確認します。

確認されたら証明書は更新されます。

証明書と鍵の整合性確認

openssl x509 -pubkey -in /etc/letsencrypt/live/hoge.example.com/cert.pem -noout | openssl md5
(stdin)= ハッシュ値
# SSL証明書ファイル

openssl pkey -pubout -in /etc/letsencrypt/live/hoge.example.com/pprivkey.pem | openssl md5
(stdin)= ハッシュ値
# 秘密鍵ファイル

## Let's Encryptで指定されたディレクトリや証明書・秘密鍵を指定してください
## 2つのハッシュ値が合っていれば証明書と秘密鍵の整合性は取れています

証明書の鍵方式確認

openssl rsa -text -noout -in /etc/letsencrypt/live/hoge.example.com/pprivkey.pem
# 正常に表示されればRSA方式で暗号化されています

後は、指定したディレクトリの証明書や秘密鍵を適切に他サーバに適用します。

Page 25 of 51

Powered by WordPress & Theme by Anders Norén