とりあえずここに置いただけ。後でググるかChatGPTに聞く。

2022.02
Firefox Monitor プライバシー保護ダッシュボード
about:protections
をURLに入力、データ漏洩に注意を>アカウント登録して通知を受ける
でメアドを入力し、データ侵害を確認する、をやってみた。０件だった。
https://monitor.firefox.com/breaches に侵害を受けたサイトが報告され
https://monitor.firefox.com/ でメアドを登録しておくと漏洩を通知してくれるのかな?
通常は(会員であれば)漏洩サイトから通知があるだろうから登録せんでもいいか。漏洩しても通知しない
とかあるか?

2022.02
必要ないリストを作るか?：
acl (tools for using POSIX Access Control Lists)
https://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E5%88%B6%E5%BE%A1%E3%83%AA%E3%82%B9%E3%83%88
アクセス制御リスト（アクセスせいぎょリスト、Access Control List、ACL）とは、コンピュータセキュリティにおけるアクセス制御を実現するために、あるリソース（受動体）に対して、誰からのどの操作を許可するかを列挙したもの。
(PCを自分しか使わないなら必要ない。Web上のボタンがトリガーであっても押すのは自分。通常はWeb
\サービスは行わない。PCに個人情報は入れない(メールは定期的にspitzに移動))
(押すのは自分であってもデーモンが仲介する場合、デーモンが実行者になるのでそこは注意)

2022.03
今必要ない物は入れない。
危うくセキュリティーの基本を忘れるとこだった。極端な話、Javaを入れていなければ例の件は
問題無しだ。(何の件か忘れた)
普段環境とは分けて、リスク有り環境をコンテナ化して使いたい時だけmountして使うか。

2022.04
netstatでもlsofの代わりができるのか?
https://shirakawa.weblike.jp/blog-page/2025/08/16…

2024.01
たまにSlackware関連でググるとヒットする、こんなヤツ、
Slackware Linux 15.0 / 最新の emacs の脆弱性 (SSA:2022-342-01)
https://jp.tenable.com/plugins/nessus/168542
tenable slackware-15 脆弱性、でググった：
Slackware Linux 15.0kernel-generic 複数の脆弱性 (SSA:2023-359-01)
https://jp.tenable.com/plugins/nessus/187293
Slackware Linux 15.0 / 最新版 mozilla-firefox の複数の脆弱性 (SSA:2023-018-04)
https://jp.tenable.com/plugins/nessus/170152
Slackware Linux 14.2 / 15.0 /現行の libssh の複数の脆弱性 (SSA:2023-353-01)
https://jp.tenable.com/plugins/nessus/187107
\
Slackware Security Advisories
http://www.slackware.com/security/
(上の脆弱性はSlackのHPにもありCurrentで対応されてるんだろう。外部に対してサーバーを立てて
\いるわけでもないし、ブラウザは本家最新を使っているし、気が向いたら入れるか)
(Debianだと自動的に通知してきて、Updateするか聞いてくるシステムだった)

/*************************************************************************************/

2024.03
時々忘れそうになる：
サーバにHTTPSアクセスする時に、認証局や証明書をブラウザはどう使う？
ChatGPT
ブラウザがサーバにHTTPSアクセスする際には、以下の手順で認証局や証明書を使用します。
1.SSL/TLS ハンドシェイク:
ブラウザがサーバにHTTPSでアクセスすると、最初に SSL/TLS ハンドシェイクが行われます。このハンドシェイクには、暗号化スイートやプロトコルのバージョンを選択するためのやり取りが含まれます。
2.サーバの証明書の提供:
サーバは、SSL/TLS ハンドシェイクの中で自身の証明書を提供します。この証明書には、サーバの公開鍵とその証明書の発行者（認証局）の情報が含まれます。
3.証明書の検証:
ブラウザは、サーバが提供した証明書を検証します。この際、以下の点が確認されます。
証明書の有効期限が現在の日時に適しているか
証明書の発行者が信頼できる認証局であるか
証明書に含まれるドメイン名がサーバのドメインと一致するか
証明書が取り消されていないか（CRLやOCSPによるチェック）
4.信頼できる認証局のルート証明書:
ブラウザは、信頼できる認証局のルート証明書を持っています。これは、そのブラウザがデフォルトで信頼する認証局の証明書です。ブラウザは、サーバの証明書の発行者がこのルート証明書を使用して署名されているかどうかを確認します。
5.証明書チェーンの構築:
サーバの証明書が信頼できる認証局によって署名されている場合、ブラウザは証明書チェーンを構築します。これには、サーバ証明書、中間証明書（Intermediate Certificate）、ルート証明書（Root Certificate）が含まれます。
6.暗号化キーの交換:
ブラウザは、証明書の検証が成功した場合、サーバとの間で暗号化キーを交換して通信を暗号化します。これにより、データのプライバシーとセキュリティが保護されます。
このようにして、ブラウザはSSL/TLSハンドシェイクを通じて認証局から提供された証明書を使用して安全なHTTPS通信を確立します。
参考：
https://seesaawiki.jp/lifewithslackzaurus_15_0/d/Apache%a4%ce%c0%df%c4%ea

2024.07
暗号化キーを交換というのは秘密鍵と公開鍵の事か？
ChatGPT
はい、その通りです。ブラウザとサーバが通信を暗号化するために暗号化キーを交換するプロセスは、公開鍵暗号方式に基づいています。
4.セッションキーの生成:
ブラウザは、ランダムに生成されたセッションキー（対称鍵）をサーバに送信します。このセッションキーは、サーバの公開鍵を使って暗号化されて送信されるため、サーバだけが自分の秘密鍵を使って復号化できます。
5.セッションの確立:
サーバは、自分の秘密鍵を使ってセッションキーを復号化します。これにより、ブラウザとサーバは共通のセッションキーを共有し、このキーを使って以降の通信を暗号化します。
6.暗号化通信の開始:
これ以降、ブラウザとサーバは、対称鍵暗号を使って通信データを暗号化し、安全にやり取りします。
このプロセスにより、データのプライバシーとセキュリティが保護されます。公開鍵と秘密鍵は、初期のキー交換のために使用され、その後の通信はセッションキーを使って行われます。

その内容は、sshにて最初にログインする時も同じか？
ChatGPT
SSH（Secure Shell）で最初にログインする時も、似たようなプロセスが行われますが、いくつかの違いがあります。以下は、SSHの初回接続時のプロセスの概要です。
1.接続の開始:
クライアント（ユーザーのマシン）は、SSHサーバ（リモートマシン）に接続を開始します。
2.サーバの公開鍵の送信:
サーバは、自身の公開鍵をクライアントに送信します。この公開鍵は、サーバのIDを確認するために使用されます。
3.サーバの公開鍵の検証:
クライアントは、サーバの公開鍵が初めての場合、その公開鍵をユーザーに提示し、信頼するかどうかを尋ねます。ユーザーが信頼すると決定した場合、その公開鍵はクライアントの「known_hosts」ファイルに保存されます。
ls -al ~/.ssh
\-rw-r–r– config (以降にメモ)
\-rw——- known_hosts
\(hostname,ip_address key_type base64_encoded_key)
\drwxr-xr-x mygithkey
4.セッションキーの生成:
クライアントは、ランダムに生成されたセッションキー（対称鍵）を作成し、それをサーバの公開鍵で暗号化してサーバに送信します。これにより、セッションキーは安全にサーバに伝えられます。
5.セッションキーの復号化:
サーバは、自分の秘密鍵を使ってセッションキーを復号化します。これで、クライアントとサーバは共通のセッションキーを共有することになります。
6.ユーザー認証:
クライアントは、パスワード、公開鍵、または他の認証方法を使用してユーザーの認証を行います。このステップは、クライアントとサーバの間の通信が暗号化された後に行われます。
7.暗号化通信の開始:
認証が成功すると、クライアントとサーバは、セッションキーを使って以降の通信を暗号化します。

まとめると、SSHで最初にログインする時も、公開鍵と秘密鍵を使用したキー交換が行われ、その後はセッションキーを使って通信が暗号化されます。ただし、SSHの場合は、サーバの公開鍵を初めて受け取る際にユーザーの確認を求めるステップがあり、これがブラウザのSSL/TLSとは異なる部分です。

ssh -i abc.key def@ghi.net で接続する場合の説明。
ChatGPT
ssh -i abc.key def@ghi.net というコマンドの中で、abc.key はクライアント側の秘密鍵ファイルです。このコマンドの詳細は次のとおりです：
・ssh: SSHコマンドを使用してリモートサーバに接続するためのプログラム。
・-i abc.key: -i オプションは、SSHクライアントが接続する際に使用する秘密鍵ファイルを指定します。この場合、abc.key が秘密鍵ファイルです。
・def@ghi.net: リモートサーバのユーザー名 (def) とホスト名またはIPアドレス (ghi.net) を指定しています。
このコマンドを実行すると、SSHクライアントは abc.key ファイルを使用して、ghi.net サーバの def ユーザーとして接続を試みます。
公開鍵認証の流れ：
1.秘密鍵と公開鍵のペアの生成:
事前にクライアント側で秘密鍵（abc.key）と公開鍵を生成します。
2.公開鍵の配置:
公開鍵をリモートサーバ（ghi.net）の def ユーザーのホームディレクトリ内の ~/.ssh/authorized_keys ファイルに追加しておきます。
3.接続の開始:
クライアントがコマンド ssh -i abc.key def@ghi.net を実行すると、指定された秘密鍵（abc.key）を使用して認証プロセスが始まります。
4.チャレンジメッセージの送信:
サーバは、クライアントの公開鍵に対応するチャレンジメッセージを生成してクライアントに送信します。
5.署名の生成:
クライアントは、秘密鍵（abc.key）を使ってチャレンジメッセージに署名を行い、その署名をサーバに送信します。
6.署名の検証:
サーバは、クライアントの公開鍵を使って署名を検証し、正しければ認証が成功します。
7.セッションの確立:
認証が成功すると、クライアントとサーバはセッションを確立し、通信が暗号化されます。
このように、abc.key は秘密鍵ファイルであり、クライアントがサーバに安全に接続するために使用されます。

上の方法では、初回以降も abc.key を指定しなければならないか？
ChatGPT
通常、SSHコマンドで秘密鍵ファイルを指定する方法を使う場合、毎回接続のたびに -i abc.key オプションを指定する必要があります。ただし、SSHの設定ファイルを使ってこれを簡略化することができます。以下の手順で、SSHの設定ファイルを使って秘密鍵の指定を自動化する方法を説明します。
SSH設定ファイルの使用
1.設定ファイルの編集:
SSHの設定ファイルは ~/.ssh/config です。もしこのファイルが存在しない場合は、新しく作成します。
2.設定の追加:
設定ファイルに接続先サーバに対する設定を追加します。以下はその例です：
\Host ghi.net
\ User def
\ IdentityFile ~/.ssh/abc.key
この設定を追加することで、ghi.net に接続する際に自動的にユーザー def と秘密鍵 ~/.ssh/abc.key を使用するようになります。
設定ファイルの内容
上記の設定ファイルを使うと、以下のようなコマンドで秘密鍵を指定せずに接続できます：
$ ssh ghi.net
設定の詳細
・Host ghi.net: この設定は ghi.net への接続に適用されます。
・User def: サーバに接続する際のユーザー名を指定します。
・IdentityFile ~/.ssh/abc.key: 使用する秘密鍵ファイルを指定します。
追加のヒント
・設定ファイルを使うことで、複数のサーバへの接続設定を一元管理できます。
・設定ファイル内では、ワイルドカード（*）を使用して複数のホストに対する設定を一度に指定することも可能です。
例えば、全てのホストに対して特定の秘密鍵を使いたい場合は次のように設定できます：
Host *
\ IdentityFile ~/.ssh/abc.key
これにより、全てのSSH接続で ~/.ssh/abc.key を使用するようになります。

github ssh key、でググった(上の設定をgithubで行った)：
https://www.kagoya.jp/howto/it-glossary/develop/github_ssh/
https://qiita.com/shizuma/items/2b2f873a0034839e47ce

2025.01
ssh-keygen、一度やったくらいじゃ忘れる。あとGUIでFP貼り付けるより、ssh-copy-idの方がよくないか?：
クライアント側で生成した公開鍵をサーバに渡す方法は？
クライアント側で生成した公開鍵をサーバに渡す方法は主に以下の手順で行えます。これにより、公開鍵認証を設定してパスワードなしでサーバに接続できるようになります。
### **1. 公開鍵を生成する**
公開鍵と秘密鍵のペアを生成します。
\- **手順**:
1. コマンドプロンプトやターミナルで以下を実行：
$ ssh-keygen -t rsa -b 4096 -C “your_email@example.com”
\ – `-t rsa`: 鍵のタイプ（RSA）。
\ – `-b 4096`: 鍵の長さ（ビット数）。
\ – `-C “your_email@example.com”`: 鍵のコメント（任意）。
2. プロンプトに従って、鍵ペアを保存するパスを指定（デフォルトは `~/.ssh/id_rsa`）。
3. パスフレーズは任意で設定（設定しない場合はそのままEnter）。
これにより、以下のファイルが生成されます：
\- **秘密鍵**: `~/.ssh/id_rsa`（他人と共有しない）
\- **公開鍵**: `~/.ssh/id_rsa.pub`（サーバに渡す）
\
### **2. 公開鍵をサーバに渡す**
公開鍵をサーバに渡して設定します。
#### **方法1: `ssh-copy-id`を使用**
\- **手順**:
1. 以下のコマンドを実行：
$ ssh-copy-id user@hostname
2. プロンプトに従ってサーバのパスワードを入力。
このコマンドは、クライアントの `~/.ssh/id_rsa.pub` をサーバの `~/.ssh/authorized_keys` に自動的に追加します。
#### **方法2: 手動で公開鍵を渡す**
`ssh-copy-id` を使用できない場合、手動で公開鍵をサーバに渡します。
\- **手順**:
1. 公開鍵ファイルを確認：
$ cat ~/.ssh/id_rsa.pub
ファイル内容が表示されます。
2. サーバにSSHで接続：
$ ssh user@hostname
3. 公開鍵をサーバの `~/.ssh/authorized_keys` に追加：
$ mkdir -p ~/.ssh
$ chmod 700 ~/.ssh
$ echo “公開鍵の内容” >> ~/.ssh/authorized_keys
$ chmod 600 ~/.ssh/authorized_keys
\ – `公開鍵の内容` は、先ほど `cat ~/.ssh/id_rsa.pub` で表示された内容をコピー＆ペースト。
\
### **3. 公開鍵認証を確認**
公開鍵認証が正しく設定されたか確認します。
\- **手順**:
1. クライアント側で以下を実行：
$ ssh user@hostname
2. パスワード入力を求められずにログインできれば成功です。
\
### **4. 必要に応じたサーバ側のSSH設定**
サーバのSSH設定が公開鍵認証を許可していることを確認します。
\- **手順**:
1. サーバのSSH設定ファイルを編集：
$ sudo nano /etc/ssh/sshd_config
2. 以下の設定を確認または変更：
\ PubkeyAuthentication yes
\ PasswordAuthentication yes # 必要に応じて無効化
3. SSHサービスを再起動：
$ sudo systemctl restart ssh
### **トラブルシューティング**
1. **権限の問題**:
\ – サーバ側の `.ssh` ディレクトリや `authorized_keys` の権限が正しく設定されていないと認証が失敗します。
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys
2. **鍵が正しく使われていない**:
\ – 接続時に特定の鍵を指定して試す：
$ ssh -i ~/.ssh/id_rsa user@hostname
これらの手順で、公開鍵をサーバに渡して公開鍵認証を構築できるはずです。

SSH接続を確認 <- よく忘れる
$ ssh -T git@github.com
https://qiita.com/dev-cho/items/b0f5574689d9e28c844c

2025.03
WinPCから、ssh abcserver としてサーバーへアクセスするとpasswdを聞かれるので入力するとloginできる。.ssh/config にはabcserverの情報はない。/etc/hostsには、abcserverのIPアドレスが書いてある。この場合、入力したパスワードがsshのデフォルトの暗号化が行われているとう事か？
(->DeepSeek)
SSH接続時のパスワード入力と暗号化について、以下の点を説明します。
### 1. パスワード転送の暗号化
\- **Yes**、入力したパスワードはSSHのデフォルトの暗号化で保護されて送信されます。
\- SSH接続は最初のハンドシェイク時（接続開始時）に**自動的に暗号化チャネルを確立**します。
\- パスワード認証が行われるのは、この暗号化されたチャネル上です。
### 2. 具体的な仕組み
1. 接続時、クライアントとサーバーは**Diffie-Hellman鍵交換**を行い、安全な暗号化チャネルを確立
2. その後、パスワードは（デフォルトでは）`aes256-ctr`などの暗号化方式で保護されて送信
3. 実際の暗号化方式は`ssh -v abcserver`で確認可能（`debug1: kex: algorithm:`の行に記載）
### 3. 観察された状況の分析
\- `.ssh/config`に設定がない → デフォルトのSSH動作（ポート22、パスワード認証）が使われた
\- `/etc/hosts`に記載 → DNSではなくhostsファイルで名前解決された
\- パスワード認証になった → おそらくサーバー側で`PasswordAuthentication yes`が設定されている
### 4. より安全な方法（推奨）
パスワード認証よりも安全な**公開鍵認証**を設定できます：
# クライアントで鍵生成（既に持っている場合は不要）
$ ssh-keygen -t ed25519
# 公開鍵をサーバーにコピー
$ ssh-copy-id abcserver
### 5. 暗号化の確認方法
実際の接続で使われた暗号化を確認するには：
$ ssh -v abcserver 2>&1 | grep -i “encryption”
# または
$ ssh -Q cipher
要約すると、**パスワードはSSHの標準暗号化（通常AES256）で保護されて送信されます**が、公開鍵認証への移行がセキュリティベストプラクティスです。

ssh-copy-id で 公開鍵を指定してabcserverへ送るコマンドは？
(->DeepSeek)
`ssh-copy-id` で **特定の公開鍵ファイルを指定** して `abcserver` に送信するコマンドは次のとおりです：
$ ssh-copy-id -i ~/.ssh/あなたの公開鍵.pub user@abcserver
### 各オプションの説明
\- `-i ~/.ssh/あなたの公開鍵.pub`
\ デフォルトの`id_rsa.pub`ではなく、**特定の公開鍵ファイルを指定**します。
\ （例: `id_ed25519.pub` など）
\- `user@abcserver`
\ 接続先サーバーのユーザー名とホスト名を指定します。
\ （例: `taro@abcserver` など）
### 補足：よく使われるパターン
#### 1. デフォルトの鍵（`id_rsa.pub`など）を使う場合
$ ssh-copy-id user@abcserver
#### 2. 非標準ポートで接続する場合
$ ssh-copy-id -i ~/.ssh/鍵ファイル.pub -p 2222 user@abcserver
#### 3. リモートサーバーでカスタムSSHディレクトリを使っている場合
$ ssh-copy-id -i ~/.ssh/鍵ファイル.pub -o “PubkeyAuthentication=yes” user@abcserver
### 注意点
1. **初回接続時**はサーバーのフィンガープリント確認が表示されます。
\ `Are you sure you want to continue connecting (yes/no/[fingerprint])?` → `yes` と入力します。
2. **パスワード認証が無効化されているサーバー**では、事前に別の方法で公開鍵を設置する必要があります。
3. コマンド実行後、`ssh user@abcserver` で**パスワードなしログイン**できることを確認してください。
4. サーバー側で `~/.ssh/authorized_keys` に正しく鍵が追加されているか確認するには：
$ ssh user@abcserver “cat ~/.ssh/authorized_keys”
これで、指定した公開鍵を使って安全に接続できるようになります！

/*************************************************************************************/

2024.01
個人情報 収集 売買ビジネス、でググった：
個人情報は売買されることもある？ダークウェブや対策について解説
https://www.lrm.jp/security_magazine/trade_pii/
ダークウェブとは、Google chromeといった通常のブラウザではアクセスすることができないサイトのことを指しています。
Googleで検索してクリックすると閲覧できるサイトたちは「サーフェスウェブ」
IDやパスワードが必要であり、特定の人物でないと閲覧できない場所を「ディープウェブ」
そして更に深層にあり、指定のソフトやツールの設定をしないとアクセスできない「ダークウェブ」
(要するに会員制のVPNサーバってことか)
グーグルが集めている個人情報の中身と、それをユーザーが管理する方法
https://wired.jp/2021/05/30/google-app-gmail-chrome-data/
Googleビジネスプロフィールを放置する5つのリスクと機会損失の怖さ
https://www.gyro-n.com/seo/hack/gbp_risk_management/

2024.07
ダークウェブレポート、Have I Been Pwned (HIBP)
https://support.google.com/googleone/answer/13632847
https://www.itmedia.co.jp/news/articles/2407/04/news158.html

/*************************************************************************************/

2026.01
一般家庭で光固定でインターネットにつながる場合は、ルーターを使用してファイアーウォールを作っているのか？
結論から言うと **はい**、
**一般家庭で光回線（固定回線）を使ってインターネットに接続している場合、ほぼ確実に「ルーターが簡易的なファイアウォールの役割」を果たしています。**
もう少し正確に説明します。

## 家庭用ネットワークの典型構成
[インターネット]
      │
[ONU / 光回線終端装置]
      │
[家庭用ルーター]  ←★ここが重要
      │
[PC / スマホ / 家電]

この **家庭用ルーター** が、実質的な防御壁（ファイアウォール）になっています。

## ルーターが行っている主な防御機能
### ① NAT（Network Address Translation）
* 家庭内は **プライベートIP**
* 外部とは **1つのグローバルIP** で通信
👉
**外部から勝手に家庭内のPCへ接続できない**
（これが最大の防御）

### ② ステートフル・パケット・インスペクション（SPI）
* 「内側から開始した通信だけ通す」
* 「外部から突然来た通信は遮断」
👉
これは **ファイアウォールの基本機能そのもの**

### ③ ポートフィルタリング
* 不要なポートは閉じている
* 明示的に設定しない限り、サーバーは公開されない

## 「ファイアウォールを作っているのか？」への正確な答え
| 観点                       | 答え              |
| -------------------------- | ----------------- |
| 専用FW装置を置いているか   | ❌ 普通は置かない |
| ルーターがFW機能を持つか   | ✅ ほぼ全て持つ   |
| 意識せずにFWを使っているか | ✅ その通り       |

👉
**一般家庭では「ルーター ＝ NAT + 簡易ファイアウォール」**

## 例外・注意点
### ● ルーターを使っていない場合
* PCをONUに直接つないだ場合
→ **無防備（危険）**
### ● IPv6（IPoE）の場合
* IPv6はNATがない
* しかし
* デフォルトで **受信遮断**
* ルーター側に **IPv6ファイアウォール** がある
👉 IPv6でも「実質的にFWあり」

## 企業向けとの違い
| 家庭           | 企業           |
| -------------- | -------------- |
| ルーター内蔵FW | 専用FW装置     |
| 設定ほぼ不要   | ポリシー厳密   |
| 防御は最低限   | IDS/IPS, WAF等 |

## まとめ（短く）
* ✅ 一般家庭でも **ファイアウォールは存在する**
* ✅ 正体は **家庭用ルーターのNAT＋SPI機能**
* ❌ 専用機器を置いているわけではない
* ⚠ ルーターなし直結は危険

/***************************************/

Webサーバを立てた場合は、Webサーバへ通じるポートやIPアドレスを通す様にルーターを設定するのか？

はい、その理解で **正しいです**。
**Webサーバを自宅や拠点内に立てる場合は、ルーター側で「通す通信だけ」を明示的に設定します。**
ただし、少しだけ整理して説明します。

## 基本原則（最重要）
**通常は「全部遮断」→「必要なものだけ通す」**
家庭用ルーターも企業FWも、この考え方は同じです。

## IPv4（家庭で最も一般的なケース）

### ① ポートフォワーディング（NAT設定）
ルーターで次を設定します。
* **外部ポート**：80（HTTP）、443（HTTPS）
* **内部IP**：WebサーバのプライベートIP（例：192.168.1.10）
* **内部ポート**：80 / 443
```
Internet
   ↓ 80/443
[Router]
   ↓ (転送)
[192.168.1.10 : Web Server]
```

👉
**これを設定した瞬間、そのポートだけが外部に公開されます。**

### ② IPアドレス制限（可能なら推奨）
管理画面やテスト用途なら：
* 接続元IPを限定（自宅・会社のみ）
* ルーター側 or Webサーバ側で制御
“`
許可: 203.xxx.xxx.xxx
拒否: その他すべて
“`

## IPv6の場合（考え方が少し違う）
### ● NATがない
* Webサーバは **グローバルIPv6** を直接持つ

### ● 代わりに「IPv6ファイアウォール」
* デフォルト：外部 → 内部は **遮断**
* Webサーバ用に
* TCP 80 / 443 を許可
* 宛先IPv6を限定
👉
**IPv6では「ポートフォワード」ではなく「FW許可ルール」**

## ルーターとサーバ、どこで防御する？
**答え：両方**

### ルーター側
* 通すポートを最小限に
* SSH（22）は原則閉じる
* 管理画面はWAN側無効

### Webサーバ側（OS）
* `iptables / nftables / firewalld`
* Apache/Nginx の設定
* 不要サービス停止

## 最小構成の安全な例（IPv4）
| 項目     | 設定               |
| -------- | ------------------ |
| 公開     | TCP 443 のみ       |
| 80番     | 443へリダイレクト  |
| SSH      | 閉じる or IP制限   |
| 管理画面 | VPN経由のみ        |

## よくある誤解
❌「Webサーバ側でFWを設定すればルーターは不要」
⭕ **入口（ルーター）で落とす方が圧倒的に安全**

## まとめ
* ✅ Webサーバ公開時は **ルーターで明示的に許可**
* ✅ IPv4 → ポートフォワーディング
* ✅ IPv6 → FWルールで許可
* ✅ 通すのは **必要最小限のポート・IP**
* 🔒 ルーター＋サーバの二重防御が基本
もし
* 家庭用ルーター機種別の設定例
* Apache / Nginx / Node.js の公開構成
* IPv6だけでWeb公開する場合の注意点
などを知りたければ、そこも具体例で説明できます。

/*************************************************************************************/
アプリに関するプライバシー： (2026.02)
あなたの会話、見られてるかも？Geminiの「学習」を止める方法【オプトアウト】
https://www.youtube.com/watch?v=lk-vFoRHcg0
https://www.youtube.com/watch?v=esnj40cOtXQ
【YouTube】今すぐオフにすべきプライバシー設定８選！
https://www.youtube.com/watch?v=hptjd4HzMco

/*************************************************************************************/

 

参考URL：
テナブル、脆弱性リスク管理ソリューションの日本語版を提供
https://cloud.watch.impress.co.jp/docs/news/1406486.html
\
OpenSSL、GnuPG、GnuTLS
https://seesaawiki.jp/lifewithslackzaurus_15_0/d/OpenSSL%a1%a2GnuPG%a1%a2GnuTLS
使わない不足libの穴埋め
https://seesaawiki.jp/lifewithslackzaurus_15_0/d/%bb%c8%a4%ef%a4%ca%a4%a4%c9%d4%c2%adlib%a4%ce%b7%ea%cb%e4%a4%e1
普段使いのPC-Linuxにウイルス対策ソフトは必要？ – 基本は不要
https://seesaawiki.jp/lifewithslackzaurus_15_0/d/%c9%e1%c3%ca%bb%c8%a4%a4%a4%cePC%2dLinux%a4%cb%a5%a6%a5%a4%a5%eb%a5%b9%c2%d0%ba%f6%a5%bd%a5%d5%a5%c8%a4%cf%c9%ac%cd%d7%a1%a9%20%2d%20%b4%f0%cb%dc%a4%cf%c9%d4%cd%d7