ネットワークセキュリティ - セキュリティ

最終更新日: 2026-07-25

TOP(About this memo)) > 一覧(セキュリティ) > ネットワークセキュリティ

SSL/HTTPS

フリーWi-Fiでの接続とSSL

• 基本的にSSLで通信していれば内容は暗号化されている。ただし接続先のドメインは（DNS解決やTLSのSNIなどを通じて）外部から見えてしまう。
• メールクライアントの場合、例えばGmailに接続すると以下のような構成になっている。
  • 送信用メールサーバー: smtp.gmail.com（SMTPS）
  • 受信用メールサーバー: pop.gmail.com（POP3S）/ imap.gmail.com（IMAPS）
• 基本的に設定時にSSL/TLSは有効化されているはず。ただしメールサーバーによっては暗号化されていない通信が残っている可能性もゼロではない。
• 多層防御の観点からは、信用できないフリーWi-Fiは使わない方が無難。FTPではなくSFTPやFTPSを使うこと。

HTTPSでのURL・クエリの扱い

• HTTPS通信では、URLのパス部分やクエリパラメータも含めて暗号化される。ただしURLのドメイン部分は（DNS解決やSNIの都合上）平文でやり取りされる。

GETパラメータに秘密情報を載せてよいか

• 載せない方がベター。
• GETパラメータも通信自体はHTTPSで暗号化されるが、アクセスログには平文で記録される。ログが漏えいすると、そこから秘密情報が流出するリスクがある。
• ブラウザのアドレスバーに常に秘密情報が表示された状態になるため、画面を目視されたり、URLを誤って共有されたりするリスクもある。

Slack・Teamsなどの通信

• SlackやTeamsのようなSaaSとの通信は、当然TLS（SSL）で暗号化されていると考えてよい。大手のSaaSであれば通信のセキュリティはサービス側でしっかり担保されているはず。

踏み台サーバー

• (参考) https://blog.serverworks.co.jp/tech/2019/08/21/thinkbastion/
• メリット
  • 主要なサーバーへのアクセス経路を踏み台サーバーのみに限定できる。
  • 使わないときは踏み台サーバーを停止できる。
• (IMO) 主要サーバーのSSHアクセスを許可IPアドレスで絞るだけでも一定の効果はあるが、許可IPは運用しているうちに増えがちなので、必要なときだけ立ち上げる踏み台サーバーを併用するとセキュリティレベルが上がる。
• 不要なときに踏み台サーバーのSSHポートを閉じる運用も考えられるが、都度の起動・停止が必要になり運用負荷は上がる。

OpenSSL

• 大きな脆弱性がいくつか報告されているため、CVE情報が出ていないか都度確認するとよい。
• 以下は執筆時点より前に実施した調査の記録であり、記載しているバージョンやCVEは調査当時のもの。実際に対応する際は必ず最新のCVE情報を確認すること。

Amazon Linux（調査当時）

• Amazon Linuxにはopensslとopenssl11（1.1.x系）のパッケージがあり、openssl11は利用可能だがデフォルトではインストールされていなかった。
  • yum info openssl11、yum info openssl で確認可能。
• アップデート: yum update openssl（openssl11を使っている場合はyum update openssl11）
• バージョン確認
  • CentOS系はopenssl versionだと詳細なパッチバージョンまでは分からない（1.0.2k-fips程度の表示に留まる）。
  • rpm -qa | egrep ^openssl- でパッケージバージョンを確認できる。

  openssl-libs-1.0.2k-24.amzn2.0.4.x86_64
  openssl-1.0.2k-24.amzn2.0.4.x86_64
  

  • このバージョンで検索すると該当のアップデート情報が見つかり、調査時点ではきちんと更新が適用されていることを確認できた。
    • https://alas.aws.amazon.com/AL2/ALAS-2022-1831.html

コンテナ内のnginx（調査当時）

• docker-compose exec nginx openssl version で確認したところ、OpenSSL 1.1.1系がビルドに使われており、1.1.1系の脆弱性情報が出ていたため最新パッチバージョンへの更新が望ましい状態だった。
• nginxの公式イメージはOpenSSLをソースからビルドし直す必要がある場合があり、Dockerfileでのビルドや、nginxイメージを使わずベースイメージ上でnginxを動かす構成などが選択肢になる。
  • (参考) https://zenn.dev/noraworld/articles/build-openssl-from-source-and-use-it-in-nginx

AWSのマネージドサービスの活用

• (IMO) 上記のようなミドルウェアの脆弱性管理コストを考えると、なるべくAWSのマネージドサービスに寄せて構築する方が運用コストは下がりやすい。
• 例えば「バックエンド + フロントの静的ファイル配信 + スケジュール処理」といった構成であれば、それぞれAWSのマネージドサービスを使うことでインフラの管理コストを下げられる。

IPスプーフィング

• グローバルIPアドレスの偽装。
• TCP/IP通信では、送信データはインターネット層（OSI参照モデルのネットワーク層に相当）でパケット単位に分割され、各パケットのヘッダに送信先IPアドレスが記載される。ルータやサーバなどのホストはこの送信先IPアドレスを見て転送先を判断し、送信元IPアドレスは返信先として利用する。
• この仕組みがインターネット全体に適用されている以上、送信元IPアドレスの偽装自体は避けられない。
• 攻撃者はアクセス経路を特定しづらくするため、送信元IPアドレスを攻撃対象自身に偽装し、多数の踏み台を経由して攻撃することもある。
  • (参考) https://gigazine.net/news/20180309-ip-spoofing-ddos/
• ただし、グローバルIPアドレスを偽装すると、その仕組み上、送信元と送信先の間で正常な通信ができなくなる。そのため、IPスプーフィングはDDoSのような「応答を必要としない」目的では使われるが、情報窃取のように応答（レスポンス）を受け取る必要がある目的には使えない。
  • この場合は、IPスプーフィングではなく海外のサーバーなどを経由させて追跡コストを上げる手口が使われる。技術的・原理的には追跡は可能。

X-Forwarded-Forヘッダ

• X-Forwarded-For（XFF）ヘッダーは、HTTPプロキシやロードバランサを経由してWebサーバーに接続したクライアントの送信元IPアドレスを特定するための事実上の標準ヘッダー。
• ロードバランサーを経由すると、サーバー側から見たリクエスト元IPアドレスはロードバランサーのIPアドレスになってしまうため、実際のクライアントIPを特定する際はこのヘッダーを参照する。

This site is open source. Improve this page.