投稿者: manualmaton Page 54 of 238

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アドレス固定サービスを利用しているのであれば、アクセス許可を固定する(ポジティブリスト形式)が確実です。

ボードゲーム『バラージ』コンポーネント一部差し替え。

先日、ようやく崩すことができたボードゲーム『バラージ』。

既に専用オーガナイザーとホイールとアップグレードを行っていますが、そこに更に改善を行いました。

水トークン差し替え

電力の源となる水。

  • ダムに溶け込んでしまう
  • 少々小さくて取り回ししづらい

と実際に遊んで分かったので、この、キューブビーズに差し替えます。

色的にも調和しますし、経常的に転がり落ちることもありません。

コイン差し替え

各種クレジットは大きさと数字が違うのみ。「1クレジット差」が大きな差になる本ゲームにおいて、この視認性の悪さは無視できません。

これに関しては汎用のボードゲーム用コインに差し替えます。

それぞれ色が異なるので使う時も受け取るときも便利。

収納

こうして用意した水トークンと木製コインをオーガナイザー内のスペースに差し替えます。

それぞれ、サイズ感を損なうことなく差し替えられました。

箱と鏡。-百均グッズの撮影用小物(その46)-

状況に応じたパーツを増やしました。

ミニチュア宝箱

まずは宝箱。きちんと蓋も開き

なので、ボードゲーム『宝石の煌めき』のアップグレードトークンを入れて

こう撮影。RPGなどにも使える素材となりました。

スタンドミラー

そしてこちらスタンドミラー。

1/12とサイズ感も完璧です。

配置にさえ気をつければ余計な写り込みはありません。そして、背中も両方移せるという利点が生まれます。

この手の単体でも仕事をする小物があって役立ちました。

蓮と傘。-百均グッズの撮影用小物(その45)-

ちょっとした閃きがありました。

セリアで見つけたロータスリーフ。(雨つき)

池に浮かんでいる蓮の葉の造花(?)です。これを手に取ったときのサイズ感がピッタリでした。

早速購入し、

figmaライザに持たせたらジャストフィット。

以前作っていた紫陽花の木枠とも相性抜群です。

フィルターかけても楽しいです。

『ライザのアトリエ3』鍵利用による属性値変化。

こちらの記事の補足になります。

はじめに

『ライザのアトリエ3』で、ストーリー/戦闘/調合/探索と全てに関わってくる秘密の鍵。

今回は調合時の違いです。

通常通りに作った場合の古の賢者の石

パーティークエストの条件にもなっている調合アイテム《古の賢者の石》。

全ての効果/特性を発現させた場合の属性値は10。

特性のみ発現させない場合でも8の属性値を持っています。

効果「属性値増加」を付与した場合

ここに、レシピの起点(精霊の小瓶)からシンセサイズ効果「属性値増加」を加えます。

秘密の鍵はレシピ変化ごとに追加できるので……

  1. 精霊の小瓶
  2. クリスタルエレメント
  3. 賢者の石

と、それぞれに付与。この途上で超特性「超濃度」を付与していくと

属性値「22」まで膨れ上がります。

最後の《古の賢者の石》のみ属性追加を付与しているので、こちらでも使うと更に属性値は上がるでしょう。

「ここまで上げてどうする」レベルではありますが、レシピ変化にはこういう側面があります。

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

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

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

素材感とグラデーション。

今回新たにお迎えしたフィギュアのジャンルはこたら。

Wave ホノルル「二人のお祭り」

2017~2020年、2022年11月~2023年1月に遊んでいた『アズールレーン』のKAN-SENホノルルの換装衣装。

最初の印象は「1/7にしては箱が大きい」でした。その理由は開封後に明らかに。

最初の撮影

後から組み付けるタイプの髪が箱の容積を占有。

流れるような造形も、グラデーションのかかった質感も惚れ惚れです。

また、上半身の浴衣は透過するように、下半身のストッキングは透過+反射感が視線を釘付けにします。

差し替え用の表情差分もありました。

これらの表情も含め、撮影のしがいがある像が増えました。

Page 54 of 238

Powered by WordPress & Theme by Anders Norén