月: 2024年10月 Page 1 of 4

サーバSSH接続時に「REMOTE HOST IDENTIFICATION HAS CHANGED」のエラーメッセージが出たときの対処。

再インストールしたLinuxサーバに対して、Linuxクライアントから公開鍵認証でSSH接続を行ったところ以下のメッセージが出ました。

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:********************************
Please contact your system administrator.
Add correct host key in /home/hoge/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/hoge/.ssh/known_hosts:2
Host key for hoge.example.com has changed and you have requested strict checking.
Host key verification failed.

それに備えて秘密鍵を新しいものに差し替えていましたが、サーバが再インストール前の公開鍵情報を覚えていたという形です。

「SSHホスト鍵が変わってるよ!」と怒られたときの対処

上記そのものズバリの解決策がありましたので、これに沿って対応していきます。

エラーが起きたLinuxクライアントで

ssh-keygen -R hoge.example.com

を実行するだけ。(ホスト名は自分の環境に合わせます)

# Host hoge.example.com found: line 1
# Host hoge.example.com found: line 2
/home/hoge/.ssh/known_hosts updated.
Original contents retained as /home/hoge/.ssh/known_hosts.old

のメッセージが出てきたら対処完了です。

改めて、新たな秘密鍵を用いて

ssh -i /path/to/private/key/hoge.exammple.com.key hoge@hoge.example.com

等としてssh接続を行い、

This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes

と、無事に接続ができました。

2024年10月のボドゲ・統率者記録。

平日休みにボードゲームを行いました。

カヴェルナ 洞窟対決

ソロではわりとやっていましたが、対人は初。アクションの取り合いでままならない状況がありましたが、素点の高い部屋を建てられた分、8点差で勝利。

資源管理とアクションの読み合いが楽しいいいゲームです。

統率者

《根花のヘイゼル》より《リスの大将軍、サワギバ》の報が組みやすいコンボがあると気づき、こちらに差し替え。

残り5点まで追い詰められた状態で無限宝物&無限死亡誘発が決まりなんとか勝てました。

このサワギバデッキは動きも好きなので、もう少し詰めていきます。

撮影台、新調。

5年ぐらい前に買っておいて3年前に故障。その後、長らく使っていなかったアイテムを新調しました。

こちらの撮影台。

折りたたみ式で、

展開、セットアップすると天井のライトと反射板で覆われた撮影ボックスになります。

早速、撮影してみました。

  • 構図決めが楽になった
  • より強い光で、1/6でも捉えやすくなった

が利点ですが、上から光が降り注ぐ関係上、顔に影が着くのが問題。ここをすこし直していくのが課題です。

Ubuntu24.04に導入したnginxをバーチャルホスト化。

概要

Ubuntu24.04にリポジトリを利用して追加したnginxは、apacheのようにバーチャルサイトが最初から備わっていませんでした。

そこで、その設定を施します。

バーチャルサイトの設定ファイル格納ディレクトリの作成

sudo mkdir -p /etc/nginx/sites-available
sudo mkdir -p /etc/nginx/sites-enabled
ls -ld /etc/nginx/sites*

sites-availablesites-enabledディレクトリがあることを確認します。

バーチャルサイト有効化

  • ファイルバックアップ
sudo cp -pi /etc/nginx/nginx.conf /path/to/backup/directory/nginx.conf.$(date +%Y%m%d)

任意のバックアップディレクトリを指定します。

  • ファイルバックアップ確認
diff -u /path/to/backup/directory/nginx.conf.$(date +%Y%m%d) /etc/nginx/nginx.conf

差分がなければバックアップは成功です。

  • ファイル書き換え
sudo sed -i '/http {/a \    include /etc/nginx/sites-enabled/*;' /etc/nginx/nginx.conf
  • ファイル書き換え確認
diff -u /path/to/backup/directory/nginx.conf.$(date +%Y%m%d) /etc/nginx/nginx.conf

以下の差分を確認します。

+    include /etc/nginx/sites-enabled/*;

サンプルのhtmlファイルを作る

ファイル格納ディレクトリは自分の環境に合わせます。

sudo -u www-data tee /home/www-data/index.html > /dev/null <<EOL
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Welcome to example.com</title>
</head>
<body>
<h1>Welcome to example.com!</h1>
<p>This is a sample page served by Nginx.</p>
</body>
</html>
EOL

サンプルのバーチャルサイトを作成する

ファイル名やserver_nameは自分の環境に合わせます。

  • 設定ファイル作成
sudo tee /etc/nginx/sites-available/sample.conf > /dev/null <<EOL
server {
listen 80;
server_name example.com www.example.com;

root /home/www-data;
index index.html index.htm;

location / {
try_files \$uri \$uri/ =404;
}

# セキュリティ設定
# サーバー情報を隠す
server_tokens off;

# MIMEタイプの設定
include /etc/nginx/mime.types;
default_type application/octet-stream;

# XSS対策
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options SAMEORIGIN;
add_header X-XSS-Protection "1; mode=block";

# ファイルのアップロードサイズ制限
client_max_body_size 1M;

# ログの設定
access_log /var/log/nginx/example.com.access.log;
error_log /var/log/nginx/example.com.error.log;
}
EOL

設定ファイル有効化

  • シンボリックリンク作成
sudo ln -s /etc/nginx/sites-available/sample.conf /etc/nginx/sites-enabled/
  • 構文確認
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.service

設定したURLでアクセスできることを確認します。

これで、バーチャルサイトが設定されました。

Ubuntu 24.04にnginxを導入する。

概要

好みはapacheではありますが、セットアップしたばかりのUbuntuサーバの性能を鑑みてnginxを入れていきます。

さっくりとした手順

  1. インストールに必要なパッケージを入れます。
  2. nginxのリポジトリーを追加します。
  3. インストールを行います。
  4. 基本的な設定を行います。

必要なパッケージの導入とリポジトリー追加

  • 必要なパッケージの導入
sudo aptitude install curl gnupg2 ca-certificates lsb-release
  • リポジトリ追加
echo "deb http://nginx.org/packages/ubuntu/ $(lsb_release -cs) nginx" | sudo tee /etc/apt/sources.list.d/nginx.list
curl -fsSL https://nginx.org/keys/nginx_signing.key | sudo apt-key add -

nginxインストール

  • パッケージのアップデート
sudo aptitude update
  • nginxインストール
sudo aptitude install nginx
  • インストール確認
nginx -v

nginx version: nginx/1.26.2を確認します。(2024/10/25現在)

  • サービス起動
sudo systemctl start nginx.service
  • サービス起動確認
systemtl status nginx.service

active(running)を確認します。

初期設定(オプション)

ここからは筆者の好みの問題です。

オプション:nginxの実行をwww-dataに変更する

  • ファイルバックアップ
sudo cp -pi /etc/nginx/nginx.conf /path/to/backup/directory/nginx.conf.$(date +%Y%m%d)

任意のバックアップディレクトリを指定します。

  • ファイルバックアップ確認
diff -u /path/to/backup/directory/nginx.conf.$(date +%Y%m%d) /etc/nginx/nginx.conf

差分がなければバックアップは成功です。

  • ファイル書き換え
sudo sed -i 's/user  nginx;/user  www-data;/g' /etc/nginx/nginx.conf
  • ファイル書き換え確認
diff -u /path/to/backup/directory/nginx.conf.$(date +%Y%m%d) /etc/nginx/nginx.conf

以下の差分を確認します。

-user  nginx;
+user  www-data;
  • サービス再起動
sudo systemctl restart nginx.service
  • サービス再起動確認
systemctl status nginx.service

active(running)`を確認します。

オプション:Web格納ディレクトリを作成する

  • web格納ディレクトリを作成
sudo mkdir -p /home/www-data
sudo chown -R www-data:www-data /home/www-data
sudo chmod -R 755 /home/www-data

オプション:passwdファイルの書き換え

※システム全体のアカウントを制御する重要なファイルです。取り扱いは慎重に行ってください。※

  • バックアップ作成
sudo cp -pi /etc/passwd /path/to/backup/directory/passwd.$(date +%Y%m%d)

任意のバックアップディレクトリを指定します。

  • バックアップ作成確認
diff -u /path/to/backup/directory/passwd.$(date +%Y%m%d) /etc/passwd

エラーがなければバックアップは成功です。

  • ファイル書き換え
sudo sed -i 's|/var/www|/home/www-data|' /etc/passwd
  • 書き換え確認
diff -u /path/to/backup/directory/passwd.$(date +%Y%m%d) /etc/passwd

以下の差分を確認します。

-www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
+www-data:x:33:33:www-data:/home/www-data:/usr/sbin/nologin

差分がこの2つだけであることを確認できたら設定完了です。

備考

この手順ではnginxのバーチャルサイトまではサポートしていないので、後述します。

WordPressの設定変更:Confファイルによるセキュリティ設定

apacheのバーチャルファイルにセキュリティ設定を追加します。

バーチャルサイトの設定ファイルバックアップ

  • バックアップ
sudo cp -pi /etc/apache2/sites-avaiable/wordpress.conf /path/to/backup/directory/wordpress.conf.$(date +%Y%m%d)

ファイル及びバックアップディレクトリは自分の環境に合わせます。

  • diffによる差分確認
diff -u /path/to/backup/directory/wordpress.conf.$(date +%Y%m%d) /etc/apache2/sites-avaiable/wordpress.conf

エラーがなければバックアップは成功です。

バーチャルサイトの設定ファイル編集

DocumentRootの項目に、以下のように編集します。/home/www-data/wordpressの部分は自分の環境に合わせます。

ここでは、サーバのリソースを食い潰し、robots.txtを無視するクローラーを止めることにしています。

また、こういったクローラーであることを隠し、ユーザーエージェントを偽装するIPもレンジでブロックしています。

    DocumentRoot /home/www-data/wordpress
    <Directory /home/www-data/wordpress>
        Options -Indexes
        Options FollowSymLinks
        AllowOverride All
        ## スパムクローラーを拒否
        SetEnvIfNoCase User-Agent "facebookexternalhit/1.1" spam_crawler
        SetEnvIfNoCase User-Agent "SemrushBot/7~bl" spam_crawler
        SetEnvIfNoCase User-Agent "AhrefsBot" spam_crawler
        SetEnvIfNoCase User-Agent "MJ12bot" spam_crawler
        SetEnvIfNoCase User-Agent "DotBot" spam_crawler
        SetEnvIfNoCase User-Agent "Baiduspider" spam_crawler
        SetEnvIfNoCase User-Agent "YandexBot" spam_crawler
        SetEnvIfNoCase User-Agent "Sogou web spider" spam_crawler
        SetEnvIfNoCase User-Agent "Exabot" spam_crawler
        SetEnvIfNoCase User-Agent "MegaIndex.ru" spam_crawler
        SetEnvIfNoCase User-Agent "SeznamBot" spam_crawler
        SetEnvIfNoCase User-Agent "BLEXBot" spam_crawler
        SetEnvIfNoCase User-Agent "Bytespider" spam_crawler
        SetEnvIfNoCase User-Agent "DataForSeoBot" spam_crawler
        SetEnvIfNoCase User-Agent "serpstatbot" spam_crawler
        SetEnvIfNoCase User-Agent "SeekportBot" spam_crawler
        SetEnvIfNoCase User-Agent "index.community crawler" spam_crawler
        SetEnvIfNoCase User-Agent "PetalBot" spam_crawler
     <RequireAll>
      Require all granted
      ##スパムクローラーを拒否
      Require not env spam_crawler
        #偽装エージェントを拒否
        Require not ip 190.92.0.0/16
        Require not ip 159.138.0.0/16
        Require not ip 166.108.0.0/16
        Require not ip 124.243.0.0/16
        Require not ip 114.119.0.0/16
        Require not ip 119.8.0.0/16
        Require not ip 110.238.0.0/16
        Require not ip 217.113.194.0/24
        Require not ip 34.123.0.0/16
     </RequireAll>
    ## 設定ファイルのアクセス拒否
     <Files wp-config.php>
      Require all denied
     </Files>
     <Files xmlrpc.php>
      Require all denied
     </Files>
     ## キャッシュを有効
     ExpiresActive On
     ExpiresByType image/jpg "access plus 1 year"
     ExpiresByType image/jpeg "access plus 1 year"
     ExpiresByType image/gif "access plus 1 year"
     ExpiresByType image/png "access plus 1 year"
     ExpiresByType text/css "access plus 1 month"
     ExpiresByType application/pdf "access plus 1 month"
     ExpiresByType text/x-javascript "access plus 1 month"
     ExpiresByType application/x-shockwave-flash "access plus 1 month"
     ExpiresByType image/x-icon "access plus 1 year"
     ExpiresDefault "access plus 2 days"
    </Directory>
     <Files xmlrpc.php>
      Require all denied
     </Files>

は運用に合わせて無効化の可否を決めてください。

  1. モバイルアプリからのリモート投稿ができなくなります。
  2. ピンバックとトラックバックを受け付けることができなくなります。
  3. Jetpackの一部機能が動作しなくなります。
  4. その他、リモート投稿や自動投稿のプラグインが影響を受けます。

編集後、

diff -u /path/to/backup/directory/wordpress.conf.$(date +%Y%m%d) /etc/apache2/sites-avaiable/wordpress.conf

として、上記の差分が出ることを確認します。

設定反映

  • 設定有効
sudo a2ensite wordpress.conf

→ 一時的に無効にしている場合

  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • Apache2再起動
sudo systemctl restart apache2.service

その後、Wordpressが正常に閲覧できることを確認します。

確認後、追加のセキュリティ設定を行わないのであれば、

sudo a2dissite wordpress.conf
sudo systemctl restart apache2.service

として、無用な攻撃を防ぎます。

Ubuntu 24.04にWordPressをインストール。

概要

CMSの代名詞、Wordpressをきちんとした手順で書いていなかったのでこの機会にメモを残します。

手順が比較的簡単なだけに狙われやすいのも納得。

なので、ここではインストールだけではなく、セキュリティ対策を含めて実施します。

環境

  • Ubuntu 24.04
  • Apache 2.4
  • MySQL
  • PHP 8.3

前提

  • Apacheの初期設定は完了しています。
  • mod_securityが稼働しています。
  • 適切に名前解決できることが条件です。(DNS設定済み)
  • 証明書は適切なものを準備済みです。

さっくりとした手順

  1. WordPress用のデータベースを作成します。
  2. WordPressのプログラムを配置します。
  3. WordPressをWebサービスで動かす設定を行います。
  4. WordPressをブラウザでインストールします。
  5. インストール後、一度、設定を解除します。

※Wordpressは非常に狙われやすいWebアプリです。そのため、安定稼働するまでは設定をするたびにWebサービスから切り離します。

DB作成

  • MySQLログイン
mysql -u root -p
  • DB作成
CREATE DATABASE wordpress CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

DB名(mt)は自分の環境に合わせます。

  • ユーザー作成
CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'your_password';

ユーザー(wpuser)やパスワードは自分の環境に合わせます。適正なパスワードを設定してください。

  • 権限委譲
GRANT ALL PRIVILEGES ON wordpress.* TO 'wpuser'@'localhost';
  • 設定反映、MySQLログアウト
FLUSH PRIVILEGES;
exit

作成したDB確認

  • MovableTypeのユーザーでログイン
mysql -u wpuser -p
  • DB確認
SHOW DATABASES;

WordPressのDBがあることを確認します。

  • DB切り替え
use wordpress;
  • DBの文字コード確認
SHOW VARIABLES LIKE 'character_set_database';

Valueutf8mb4であることを確認

  • DBの照合順序確認
SHOW VARIABLES LIKE 'collation_database';

Valueutf8mb4_binであることを確認

exit

WordPress取得

  • 作業ディレクトリに移動
cd /hoge && pwd

任意のディレクトリを指定します。

  • wget
wget https://wordpress.org/latest.tar.gz
  • ファイルの解凍
tar -xzvf latest.tar.gz
  • ファイルの所有権変更
sudo chown -R www-data:www-data wordpress
  • www-dataディレクトリに移動
sudo mv wordpress /home/www-data/wordpress

自分の環境に合わせます。

WordPressWebサイト設定編集

ログ格納用のディレクトリ作成

  • ログ格納ディレクトリ作成
sudo mkdir -p /var/log/wordpress
  • ログ格納ディレクトリの所有者変更
sudo chown www-data:www-data /var/log/wordpress

WordPressのバーチャルサイト作成

  • /etc/apache2/site-available配下に、wordpress.confを管理者権限で作成し、以下のように編集していきます。
<VirtualHost *:80>
    # ドメイン名を指定します
    servername hoge.example.com
    # HTTPアクセスを強制的にHTTPSにリダイレクトします
    RewriteEngine On
        RewriteCond %{HTTPS} off
        RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>
<VirtualHost *:443>
    # ドメイン名を指定します
    ServerName hoge.example.com
    CustomLog /var/log/wordpress/wp_access.log combined
    ErrorLog /var/log/wordpress/wp_error.log


    # WordPressを配置したディレクトリを指定します。
    DocumentRoot /home/www-data/wordpress
    <Directory /home/www-data/wordpress>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

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

    Header always set Strict-Transport-Security "max-age=63072000"
    Header set X-Content-Type-Options "nosniff"
    Header always append X-Frame-Options "SAMEORIGIN"
    Header set X-XSS-Protection "1; mode=block"


#SSL設定
  SSLEngine on
    Protocols h2 http/1.1
    SSLCertificateFile /path/to/ssl/certificate.crt
    SSLCertificateKeyFile /path/to/ssl/private.key
   # 証明書と秘密鍵のパスを指定します

    # Mod_Security設定
    SecRuleEngine DetectionOnly
    # Webでインストールを行うため、最初は検知モードに設定します。
    ## ファイルのアップロードをできるようにします。
    SecRequestBodyInMemoryLimit 524288000
    SecRequestBodyLimit 524288000

    ## テスト用の検知パラメーター
    SecRule ARGS:modsecparam "@contains test" "id:4321,deny,status:403,msg:'ModSecurity test rule has triggered'"


</VirtualHost>

# これらのセクションはSSL暗号化強度を高めるための記述です
# </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:EC6-GCM-SHA384
SSLHonorCipherOrder     off
SSLSessionTickets       off

SSLUseStapling On
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"

設定ファイル有効化

  • コンフィグ読み込み
sudo a2ensite wordpress.conf
  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • Webサービス再起動
sudo systemctl restart apache2.service
  • Webサービス再起動確認
systemctl status apache2.service

ブラウザから確認

ブラウザで設定したURLにログインします。

インストール画面が出てきます。言語を選びContinueをクリックします。

ボタンをクリックします。

設定したDB名、ユーザー、パスワードを入力します。

DBと接続されると、以下が表示されます。インストール実行をクリックします。

サイト名などを入れていきます。

ここまで出たらOKです。

インストール後の処理(一時停止)

圧倒的なシェアを誇るWordpressは攻撃者が真っ先に狙うサービスです。
そのため、安定稼働するまでは確認後に一度停止して、物理的なアクセスを防ぎます。

  • バーチャルサイトの設定ファイル無効化
sudo a2dissite wordpress.conf
  • 構文確認
sudo apache2ctl configtest

Syntax OKを確認します。

  • Webサービス再起動
sudo systemctl restart apache2.service
  • Webサービス再起動確認
systemctl status apache2.service

無効化後、上記の設定ファイルで指定したURLにアクセスできないことを確認します。

Redmine、ヘッダーに別サイトへのリンクを追加。(redmine_view_customize)

ヘッダーに別のサイトのリンクがほしいときは割とあるので、そのメモです。

動作環境

  • Redmine 4.2 /5.0/5.1
  • view_customize_pluginがインストール済み

コード

「新しい表示のカスタマイズ」で

  • パスのパターン:空白
  • プロジェクトのパターン:空白
  • 挿入位置:ヘッダー
  • 種別:JavaScript

で、以下のように入力。

$(document).ready(function(){
  // メニューの準備
  const menus = `
<li><a href="https://manualmaton.com" rel="noopener noreferrer">WordPress(manualmaton.com)</a></li>
<li><a href="http://barrel.reisalin.com" target="_blank" rel="noopener noreferrer">BookStack(Barrel Gazer)</a></li>
`;
  // 追加する
  $('#top-menu>ul').append(menus);
});

こうすることで、Redmineのヘッダーに

このようにリンクが追加されます。

思わぬ作業影響。

WebARENAにて新たなWebサービスを立ち上げようと思ったものの大失敗。

ちょっとハマってしまったので切り戻し。

しかし、同一サーバで稼働させているNextcloud上で、この謎の状況が起きました。

ロケールを en_US.UTF-8/fr_FR.UTF-8/es_ES.UTF-8/de_DE.UTF-8/ru_RU.UTF-8/pt_BR.UTF-8/it_IT.UTF-8/ja_JP.UTF-8/zh_CN.UTF-8 に設定できませんでした
これらのロケールのうちいずれかをシステムにインストールし、Webサーバーを再起動してください。

localectl 

を実行しても

System Locale: LANG=ja_JP.UTF-8
               LANGUAGE=ja_JP:ja
    VC Keymap: (unset)          
   X11 Layout: us
    X11 Model: pc105

と、正常な状況です。

何が起きたか?

新たに

  • perl
  • CGI

などを動かそうとパッケージをうにゃうにゃしていたときにこれが起きてしまったようです。

復旧

「転ばぬ先の杖」が功を奏しました。作業前にとっておいたスナップショットにより、作業前の状況に切り戻し。さながら「逆転時計(タイムターナー)」を起動させた気分です。

  • DB
  • データ

はバックアップを取ることで復旧できますが、新たなパッケージを動かしたときのようにシステム深奥まで影響を及ぼすような作業は全体のバックアップを取ることを学んで助かったという心境です。

ログ調査時にIPやステータスコードを抜き出すコマンド。

Apacheのアクセスログを調査するとき何かと使うのでメモです。

アクセスログからIPのみを抽出してカウント

 awk 'match($0,/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/) { print substr($0, RSTART, RLENGTH) }' "/var/log/apache/access.log" | sort -u 

表示例

3 xxx.xxx.xxx.xxx
2 yyy.yyy.yyy.yyy
1 zzz.zzz.zzz.zzz

と、煩雑なその他のログを探すことなく件数とIPをカウントします。

更にステータスコードも表示

awk 'match($0, /[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/) { ip = substr($0, RSTART, RLENGTH) } match($0, /" [0-9]{3} /) { status = substr($0, RSTART+2, 3); print ip, status }' /var/log/apache/access.log | sort | uniq -c | sort -nr

表示例

5 xxx.xxx.xxx.xxx 200
3 yyy.yyy.yyy.yyy 404
2 zzz.zzz.zzz.zzz 500

ステータスコードが入るので、アクセス制御の有無やそれを突破してきたIPも調べられます。

Page 1 of 4

Powered by WordPress & Theme by Anders Norén