ITインフラエンジニアのおつむの整理

ITインフラエンジニア(現ニート)の頭の整理場所。ほぼ日記になる予定。

漫画村の判例を読んでみて

漫画村の首謀者の一人が出所したとかで、ツイッターで色々更新されているのでフォローして成り行きをたまに見ているのですが、漫画村判例をちゃんと読んだことないなと思い読んでみました。(以下漫画村判例らしいです)

https://www.courts.go.jp/app/hanrei_jp/detail4?id=90489

ざっくりと興味あるところを読んでいるだけなので、あいまいなところもありますが、争点としては以下のような感じっぽいです。

  1. コンテンツ(漫画)自体は漫画村自体に記録されたものを公開されていたか
  2. リバースプロキシは著作権法(2条1項9号の5イ)の送信可能化に当たるのか
  3. 漫画村の広告収入は犯罪収益などになるのか

意外だったのは、1については首謀者自身であったり某ひろ〇き氏などもリバースプロキシで他のサイトの情報を表示しているだけでコンテンツは保持していないと聞いてました。しかし判例ではコンテンツのアップロードもしていたっぽい共謀者の供述がされてます。
とはいえあんなサイトを作るくらいだから実は漫画村にコンテンツアップロードしてました、で捕まるのは何かしっくりこないですよね。それくらい対策をしてそうな気がします。控訴もしてないですし。

色々思うこともありますが深く踏み込む気もないので、この辺にします。
自分が知っている話題について裁判の判例読むの面白いですね。いつかのコインハイブの件もそうでした。
気になる裁判などあったら今後も判例を読んでみようと思います。

今後はほぼ日記となるでしょう

ここ2週間くらいElastic Stackに良くも悪くもドはまりしてしまい、何か記事を書いている場合じゃないってくらい没頭してました。 そのせいでニート期間中にQiitaやnote、はてなブログを色々更新しようかなと思っていたのですが、なかなか更新できず。
ドはまりしていた内容などは、個人で使用しているMattermostにメモはしてあるのですが、それを改めて整理してアウトプットするのは面倒だなぁ、躓いた内容をメモしながらパブリックにアウトプットできるのないかなー、と思っていたところZennにスクラップの機能を今日見つけました。

zenn.dev

このスクラップの機能、上記紹介サイトにも記載してある通り取り組んでいることや解決方法がまだわかってないことの試行錯誤中のログを残す感じで記載できます。当初このブログで自分が書きたいと思っていたのは、色々試行錯誤した内容やその時のどう考えて行動したかなどを書きたいなと思っていたのですが、それをまとめ直そうとすると時間がかかってしまうため筆不精となってました。

ということで、これは自分がパブリックにアウトプットできる機会が増えるかも!と思い早速今日試してみました。

zenn.dev

スクラップの内容は、Zennでは投稿する記事をGitHub管理できる機能があるのでそれについて試行錯誤した内容です。ちゃんとGitHub連携できました。ただ拡張子を付与し忘れただけで1-2時間無駄にしたことだけが悔やまれます。

スクラップの使用感は気軽に更新できるので使い心地はよく感じました。
そして自分の悪い癖として、色々に詰まったときにほど更新が雑になる(1-2時間無駄にしたとき)のを改めた感じます。。。もう検討がつかない状況になったとき、思いつくことをあらかた試そうとして証跡を残すのをめんどくさがってしまうんですよね。。。
たぶん思いつくことを色々試している時って、脳内麻薬が出ている気がする。でも躓いているときはちゃんと何がいけないのか冷静になって振り返りが必要なんだろうな。
そういった時ほど理性を働かせて、いったん休憩して糖分を摂取するなどをしないとですね。

と、Zennのスクラップの機能が良かったので、今後は色々試行錯誤することはZennに投稿するようになると思います。
ただそうすると、このブログって当初は色々検証したことなどを投稿するつもりだったため、ただの日記になりそうです。
使い分けとしては以下の感じかなと思ってます。

  • Qiita:コードや設定ファイル等を投稿する用途
  • note:IT専門じゃない人でも活用できそうなノウハウ等
  • Zenn(記事/本):ITインフラ関連でまとまった内容を投稿する場合(GitHub連携で更新)
  • Zenn(スクラップ):普段の試行錯誤の内容投稿先
  • はてなブログ:日記(脳内整理?)
  • Twitter:試行錯誤中の叫び先

それでは今日はこの辺で。

clasp login --no-localhostができない

背景

Gmailの自動整理としてGAS(Google Apps Script)を使用しているのですが、せっかく最近Gitを覚えたしGitで管理できるようにしたいと思ってました。 調べてみるとclaspという環境を使用すると、CLIからGASを管理できるようになるとのこと。 ではDockerで環境構築して管理してきますか!と意気込んてたのですが、一番最初のloginの段階でうまくいかない状態です。

Dockerfile

FROM node:slim
RUN npm i @google/clasp -g
CMD ["/bin/bash"]

以下を参考にさせてもらってます。 gasを管理するclaspのdocker環境を作成する - Qiita

build/run/clasp login実行

実行したのが以下です。

# docker build . -t clasp:latest
Sending build context to Docker daemon  4.096kB
Step 1/3 : FROM node:slim
 ---> 72150548d9e3
Step 2/3 : RUN npm i @google/clasp -g
 ---> Running in 7474b17f5cfb

added 264 packages, and audited 265 packages in 20s

80 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
npm notice
npm notice New major version of npm available! 8.19.3 -> 9.1.1
npm notice Changelog: <https://github.com/npm/cli/releases/tag/v9.1.1>
npm notice Run `npm install -g npm@9.1.1` to update!
npm notice
Removing intermediate container 7474b17f5cfb
 ---> 4670be7b9b25
Step 3/3 : CMD ["/bin/bash"]
 ---> Running in cd1277eb5550
Removing intermediate container cd1277eb5550
 ---> 0c90541ed382
Successfully built 0c90541ed382
Successfully tagged clasp:latest
# docker run -it clasp
root@7bad27bd043e:/# clasp login --no-localhost
Logging in globally…
🔑 Authorize clasp by visiting this url:
https://accounts.google.com/o/oauth2/v2/auth?access_type=offline&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fscript.deployments%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fscript.projects%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fscript.webapp.deploy%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fdrive.metadata.readonly%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fdrive.file%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fservice.management%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Flogging.read%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcloud-platform&response_type=code&client_id=1072944905499-vm2v2i5dvn0a0d2o4ca36i1vge8cvbn0.apps.googleusercontent.com&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob

Enter the code from that page here: 

ここまできたらあとは表示されたURLにアクセスして許可したら表示されるコードを入力すればよいはずなのですが、アクセスしたURLでは以下のような画面が。

claspLogin後の画面

はて。Google Apps Script APIもちゃんと事前にONにしてます。 また上記ログで表示されているnpm install -g npm@9.1.1もあとでDockerfileに追記して実行してみても同じ結果です。

試しに--no-localhostのオプションを外して実行してみると何やら成功しそうな画面が表示されます。 ただしこれはclaspを実行した環境でGUIが使用できる場合のコマンドのため、そのまま許可しようとしてもhttp://localhost:<port>/?code=xxxxxxxxxxxxxxxのURLに飛ばされるため失敗します。

claspLogin(成功)

エラー内容確認

このまま試行錯誤しても解決しなさそうなので、諦めてエラー内容などを詳細に確認してみます。 まずはエラーの詳細を読んでみます。

エラーの詳細

oobなんちゃらがブロックされていると。関連するデベロッパードキュメントとやらもざっと読んでみます。 影響を受けているかどうかの確認アプリが OOB フローを使用しているかどうかを判断する方法アプリケーション コードを調べる

Google OAuth 認証エンドポイントを呼び出すアプリケーション コードのセクションを確認し、redirect_uri パラメータに次のいずれかの値があるかどうかを確認します。
・redirect_uri=urn:ietf:wg:oauth:2.0:oob
・redirect_uri=urn:ietf:wg:oauth:2.0:oob:auto
・redirect_uri=oob

アクセス先のURLの末尾がredirect_uri=urn:ietf:wg:oauth:2.0:oobになってますね。これか。。。 問題っぽいのはわかったのですが、ではどうすればいいのかと、サンプルリクエストを見てみると

https://accounts.google.com/o/oauth2/v2/auth?
response_type=code&
scope=<SCOPES>&
state=<STATE>&
redirect_uri=urn:ietf:wg:oauth:2.0:oob&
client_id=<CLIENT_ID>

clasp触ったばかりだから全然わからーん、とめげつつURLにScopeとClientIDは記載されてますね。おそらくScopeが許可するサービス、ClientIDはClaspを示すものなんだと思います。あとStateはなんなんじゃ。

と色々調べてたら、この事象についてGithubでissuesになってるっぽい。なので改善されるまで保留かな、ってなってます。てか今記載しながら思ったけど、サンプルクエリだし、State無し版でURLにアクセスすればいいのか??

clasp login --no-localhost No Longer Working · Issue #948 · google/clasp · GitHub

※20221116追記 ↑アクセスするURLを編集すればどうこうできるものではなかったですね、、、

AWS CLIのDockerコンテナでSSM StartSessionを使ったポートフォワードができなかった話

背景

昨日AWS CLIのDockerコンテナを使用して、SSMを使用したインスタンスへの接続方法を色々試していました。

qiita.com

あとscpとかもできるようになったらうれしいなーと思い少し検証を進めてたのですが、ちょっと厳しそうだったのであきらめた話です。

やりたかったこと

  • AWS CLIのコンテナでssmを使用したポートフォワードのセッションを張る
  • コンテナ外から、コンテナ経由でインスタンスにscpする(いわゆるリモートフォワード?)

試したこと

上記で乗せた記事の環境です。(多少パスが違いますが) そこで以下コマンドを実行し、sshのポートフォワードのセッションが張られたコンテナが起動している状態です。

$ docker run --rm -p 6022:6022 -it -v /opt/docker/awscli/.aws:/root/.aws awscli ssm start-session --target "i-xxxxxxxxxxxxxxxxxxxxx" --document-name AWS-StartPortForwardingSession --parameters '{"portNumber":["22"],"localPortNumber":["6022"]}'

Starting session with SessionId: readonly-xxxxxxxxxxxxxxxxxxx
Port 6022 opened for sessionId readonly-xxxxxxxxxxxxxxxxxxx.
Waiting for connections...

Connection accepted for session [readonly-xxxxxxxxxxxxxxxxxxx]
$ docker ps
CONTAINER ID   IMAGE     COMMAND                  CREATED          STATUS          PORTS                                       NAMES
5cd67455349b   awscli    "/usr/local/bin/aws …"   12 minutes ago   Up 12 minutes   0.0.0.0:6022->6022/tcp, :::6022->6022/tcp   objective_kepler

ここでリモートフォワードが設定されていたら、コンテナ外(コンテナホスト)から対象のコンテナに対してsshすればインスタンスに接続できるのかなーと思ってましたが、だめでした。

$ docker ps
CONTAINER ID   IMAGE     COMMAND                  CREATED          STATUS          PORTS                                       NAMES
5cd67455349b   awscli    "/usr/local/bin/aws …"   17 minutes ago   Up 17 minutes   0.0.0.0:6022->6022/tcp, :::6022->6022/tcp   objective_kepler
$ ssh -i <key> ec2-user@172.17.0.2 -p 6022
ssh: connect to host 172.17.0.2 port 6022: Connection refused

コンテナにアクセスして、net-toolsをインストールしてポートを確認してみると、ローカルに対してしかListenしてないようです。それではできないのもしょうがないですね。 ちなみにコンテナにsshをインストールして、localのポートを指定したらちゃんと接続できました。

bash-4.2# netstat -ant
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 127.0.0.1:6022          0.0.0.0:*               LISTEN
tcp       32      0 172.17.0.2:52612        52.119.219.52:443       CLOSE_WAIT
tcp        0      0 172.17.0.2:58144        52.119.220.97:443       ESTABLISHED
tcp        0      0 172.17.0.2:37508        18.65.125.52:443        TIME_WAIT

なので、もしSSMのStartSesionを使用してscpをどうしてもしたいのであればコンテナ作成時にコピーしたいファイル(orディレクトリ)をバインドマウントして、コンテナからscpする手順になるのかなーと思ってます。ただscpとかはなんとなくできたらラッキーくらいで検証していたので、いったん後回しにします。 同じ考えをした人の参考程度になれば幸いです。

gitを使用したサーバのconfig管理方法

背景

サーバの設定ファイルを変更したことの履歴とかを残したいけどどうすればいいだろうとずっと考えていて、以下の記事を見かけたしまねしてみるか~と思ってました。

qiita.com

が、記事最後に記載されてありましたがgitで管理する方法がよさそうだなと思い、今日から試しに実行してみました。ちょうど最近gitを勉強したのでちょうどいいです。

Gitでの管理方針

設定変更したファイルがあるディレクトリでgit initを使用して、設定ファイルのバージョン管理をします。 今までは元ファイルのバックアップをサフィックスに日付を付与してコピーしてから設定ファイルを編集していました。それを今後はGitで管理します。 例として、環境変数を付与するために.bashrcを編集する際の手順を以下に記載します。

  • 今まで
$ cp -p .bashrc .bashrc.yyyymmdd
$ vi .bashrc #更新
  • これから(初回)
$ git init
$ git add .bashrc
$ git commit -m "<commit message>"
  • これから(更新する際)
$ vi .bashrc
$ git add -u
$ git commit -m "<commit message>"

手順の長さとしては今までのほうがシンプルですが、ただどんどんバックアップが増えてしまい邪魔だと感じたり、またどの設定ファイルをいじったのか忘れがちでした。

それをgitで管理するようになると、git管理しているディレクトリでは.gitディレクトリが作成されるので.gitディレクトリを検索すればよいではないか!となり、これが個人的に一番うれしいです。

検索はfindコマンドで、以下エイリアスを設定しました。

alias gitfind='sudo find ~ /opt -name .git | sed s/.git//'
$ gitfind
/home/horonium/
/opt/docker/awscliv2/

一般ユーザに設定した例のためsudoを付与、また検索するディレクトリはルートディレクトリをしているするとsudoを付与していても権限不足で余計なエラーが出るので、よく設定変更するディレクトリを指定(/opt, /etc, ~)、あと.gitは表示されなくてもいいかと思いsedで置換。

これでgit管理しているディレクトリが表示されるため、表示されたディレクトリでgitのstatusやls-filesを実行すればどの設定ファイルを修正したかわかります。この辺もう少し工夫すれば、gitで管理しているファイル一覧とかも出せそうですね。いったん今回は様子見ですが。

WSLでAWS CLIのDockerイメージを使用できるようにするまで

はじめに

最近Surface Go 3を買ったのですが、なるべくソフトをインストールすることなく使用したいと考えていました。そんな中ふと思いつきでAWS CLIを使用したいと思い、また最近Dockerを勉強していたこともありWSLでdockerを使用することで今後CLIやプログラミングをdockerで環境用意すればよくね?と思い付きで試して思ったより時間がかかったので書き残します。 (すぐ終わるだろうと高を括っていたのでログをとっておらず、Qiitaとかに乗せるにはひどいのでブログ側に書いておきます)

環境

WSLインストール

  1. Windowsターミナル起動
  2. WSLインストール powershell wsl --list --online #インストール可能なディストリビューション確認 wsl --install #ディストリビューション指定なしでUbuntuをインストール
  3. インストール完了後再起動
  4. WindowsターミナルからUbuntuを選択してWSL起動 image.png
  5. 初期ユーザ/パスワード設定(sudo可能なユーザ)
  6. WindowsターミナルからwslコマンドでWSLが起動するようになる(初期ユーザ作成前にwslを入力しても起動しなかったです)

バージョンは以下でした

$ cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.1 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.1 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

Dockerインストール・サービス起動

インストール

ここが少し引っかかったポイントです。DockerのインストールはRed Hat系では何度も試していたのですが、UbuntuなどのDebian系は初めてだったので少し勝手が違い戸惑いました。

最初は以下のサイトを参考にリポジトリ追加とGPG公開鍵追加(Red Hat系では実施したことがなかった記憶)を実施して、apt updateを実行しました。 https://sid-fm.com/support/vm/guide/install-docker-ubuntu.html

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
$ sudo add-apt-repository \
    "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
    $(lsb_release -cs) \
    stable"
 #ここで/etc/apt/sources.list.d/archive_uri-https_download_docker_com_linux_ubuntu-jammy.listができます
$ apt update

するとupdateのところでエラー、また試しにdockerのインストールを試しても失敗。 同件事象を調べたらいくつか引っかかり、どうやらapt-keyが非推奨(廃止予定)とのことで。 以下先人の情報を参考にさせてもらいました。 https://text.baldanders.info/remark/2022/05/apt-key-is-deprecated/

まずは公開鍵を配置。

$ cd /etc/apt/keyrings
$ sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o docker-key.asc

その後/etc/apt/sources.list.d/archive_uri-https_download_docker_com_linux_ubuntu-jammy.listの中身を手動で修正。(signedの部分を追記)

deb [arch=amd64 signed-by=/etc/apt/keyrings/docker-key.asc] https://download.docker.com/linux/ubuntu jammy stable

上記実施後apt updateが成功するようになったため、以下コマンドでDocker関連パッケージをインストール。

sudo apt install docker-ce docker-ce-cli containerd.io

サービス起動

インストールできたため、いざサービスを起動して実行しようとしたらなぜかsystemctlが実施不可。

$ systemctl status docker
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down

エラーに表示されている通りでしたが、どうやらsystemdがPID1で起動していないためsystemctlコマンドが使用できないっぽいです。 ではPID1は何になっているのかいうと、initになっているようです。そのためinit.dからサービスを起動を試したら無事Dockerサービスが起動し、dockerコマンドが実行できるようになりました。

$ /etc/init.d/docker start

DockerでAWS CLIの実行

無事Dockerが使用できるようになりましたので、あとはコンテナイメージを持ってくればどうにかなりますね。 公式のイメージはamazon/aws-cliらしいです。

docs.aws.amazon.com

イメージをプルして

$ sudo docker pull amazon/aws-cli

公式のコマンドを参考に実行してみれば

$ sudo docker run --rm -it amazon/aws-cli --version
aws-cli/2.8.8 Python/3.9.11 Linux/5.15.68.1-microsoft-standard-WSL2 docker/x86_64.amzn.2 prompt/off

実行できましたね!あとはAWS CLI実行用にアクセスキーを発行、リージョン情報やアクセスキーの設定です。

AWS CLI実行用クレデンシャル設定

使用するリージョン、アクセスキーを~/.awsを用意してそこに格納します。 アクセスキーが必要なので、AMCで事前にCLI実行用のIAMユーザを作成します(アクセスキーが漏れても怖いのでいったん権限はreadonlyだけにしておきます)

$ mkdir ~/.aws
$ cat <<EOF > ~/.aws/config
> [default]
> output = json
> region = ap-northeast-1
> EOF
$ cat <<EOF > ~/.aws/credentials 
> [default]
> aws_access_key_id = xxxxxxxxxx
> aws_secret_access_key = xxxxxxxxxx
> EOF

クレデンシャル情報をマウントしてAWS CLI実行

そして最後に上記で用意したフォルダを、dockerコマンド実行時にマウントして実行するようにすれば

$ sudo docker run --rm -it -v ~/.aws:/root/.aws amazon/aws-cli iam list-account-aliases
{
    "AccountAliases": [
        "xxxxxxxxxxxxxx"
    ]
}

実行できるようになりました!とりあえず実行できてよかった。コマンドが長いので、エイリアス設定とかするのがよさそうですね。 一つ気がかりなのは、毎回コンテナを作成しているのでaws cliを実行する際にtabでコマンドの補完がされないんですよね。使用したいときにコンテナをbashとかで起動しっぱなしにしてコンテナにアクセスして使用する方法が個人的にはあっている気がします。それはまたいずれということで。

dockerコマンドでsudoめんどい

毎回sudoしていたので、sudo不要で実行できるようにします。dockerのグループが作成されているようなので、そこに現在の自分のユーザを追加します。

$ groups horonium
horonium : horonium adm dialout cdrom floppy sudo audio dip video plugdev netdev
$ sudo usermod -aG docker horonium
$ groups horonium
horonium : horonium adm dialout cdrom floppy sudo audio dip video plugdev netdev docker

その後dockerを再起動したのですが、それだけではだめのようでしたのでいったんwsl --shutdownでWSLを再起動。

$ sudo /etc/init.d/docker restart
 * Stopping Docker: docker                                                                                                    [ OK ]
 * Starting Docker: docker                                                                                                    [ OK ]
horonium@TABLET-19B4QHAB:~/.aws$ docker ps
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/json": dial unix /var/run/docker.sock: connect: permission denied

無事sudo無しでも実行できるように。

$ docker images
REPOSITORY       TAG       IMAGE ID       CREATED        SIZE
amazon/aws-cli   latest    c50e434a6ee3   40 hours ago   367MB

PCスリープして数時間後apt updateでエラーが

なにやらエラーが出るようになりました。

$ sudo apt update
Hit:1 https://download.docker.com/linux/ubuntu jammy InRelease
Hit:2 http://archive.ubuntu.com/ubuntu jammy InRelease
Get:3 http://security.ubuntu.com/ubuntu jammy-security InRelease [110 kB]
Get:4 http://archive.ubuntu.com/ubuntu jammy-updates InRelease [114 kB]
Get:5 http://archive.ubuntu.com/ubuntu jammy-backports InRelease [99.8 kB]
Reading package lists... Done
E: Release file for http://security.ubuntu.com/ubuntu/dists/jammy-security/InRelease is not valid yet (invalid for another 1h 14min 20s). Updates for this repository will not be applied.
E: Release file for http://archive.ubuntu.com/ubuntu/dists/jammy-updates/InRelease is not valid yet (invalid for another 1h 14min 39s). Updates for this repository will not be applied.
E: Release file for http://archive.ubuntu.com/ubuntu/dists/jammy-backports/InRelease is not valid yet (invalid for another 1h 15min 12s). Updates for this repository will not be applied.

以下先人がいらっしゃいまして、どうやらWSLのマシンをスリープするとWSLの時間がずれてしまうことが影響とのこと。自分も2時間くらいずれてました。 https://ginpen.com/2021/06/05/apt-update-release-file-is-not-valid-yet/

参考先にあったようにwsl --shutdownで改めてWSLを起動しなおしたら正常になりました。WSLはちゃんとシャットダウンする癖をつけたほうが良いかもしれませんね。

OpenSSLの脆弱性情報が出るらしいですね

前の職場で色々と悩みが多かったのでとりあえず辞めました。無職です。 最近は自分が個人で作成した環境やプログラミングをちゃんと整理しようとgitを勉強してます。

そんな無職のなか、OpenSSLのでcriticalに分類される脆弱性について修正リリースが今日~明日で出るらしいですね。

news.mynavi.jp

対象はバージョン3以降を使用しているもの全てらしい。あとOpenSSHもたしかOpenSSLを使用している記憶があったのでそっちも怪しいですね。
とりあえず個人で使用しているAmazon Linuxで使用しているサーバで以下確認してみました。

# openssl version
OpenSSL 1.0.2k-fips  26 Jan 2017

# yum info openssl
Loaded plugins: extras_suggestions, langpacks, priorities, update-motd
230 packages excluded due to repository priority protections
Installed Packages
Name        : openssl
Arch        : x86_64
Epoch       : 1
Version     : 1.0.2k
Release     : 24.amzn2.0.4
Size        : 830 k
Repo        : installed
From repo   : amzn2-core
Summary     : Utilities from the general purpose cryptography library with TLS implementation
URL         : http://www.openssl.org/
License     : OpenSSL
Description : The OpenSSL toolkit provides support for secure communications between
            : machines. OpenSSL includes a certificate management tool and shared
            : libraries which provide various cryptographic algorithms and
            : protocols.

# yum deplist openssh | grep ssl
   provider: openssl-libs.x86_64 1:1.0.2k-24.amzn2.0.4
   provider: openssl-libs.x86_64 1:1.0.2k-24.amzn2.0.4
   provider: openssl-libs.x86_64 1:1.0.2k-24.amzn2.0.4
   provider: openssl-libs.x86_64 1:1.0.2k-24.amzn2.0.4

調べたサーバは月1でyum updateを実行しているのですが、それでもバージョンは1系なんですね。リポジトリは特に弄ってません。なのでOpenSSLの公式から3系をダウンロードしてインストールしている人やリポジトリを弄っている人が影響してるのかなーと個人的に推測してます。
あとsshでもやはり依存関係があり、OpenSSLを使用しているようですね。なので会社勤めしている人は証明書作成とかしてないしOpenSSL使ってないっしょ!とかではなくちゃんと確認しましょうね。

と色々調べているうちに、OpenSSLを調べているうちに2014年にも「Heartbleed」というCriticalの脆弱性が出ていたことを初めて知りました。自分が社会人として働き始めたのが2017年なので、全然前ですね。 Heartbeatを調べてみると、SSL/TLSセッションを維持するためのKeepAliveを実現するために、ハートビート機能があるらしいです。初めて知りました。
Heartbleedはそこで不正なリクエストをした際に、サーバ上のメモリから意図しない情報が返されてしまったようです。

今回はどんな感じなのかまだわからないですが、働いていたら各ベンダーに連絡したりと色々面倒だったろうなとほっとしてます。バージョン3以降なので影響が少なそうというのはありますが、log4jの時くらいに心配はした方が良いのかもと思ってます。対応する方は頑張ってください。

追記

Twitterで調べてみたら、RHEL9やUbuntu22.04が3系を使用しているらしい。 ほんと最近建てたばかりのRHEL9がローカルにあるの思い出したので調べてみたら確かに3系だった、、、公開してないしいいやと思い確認さぼってた。

# openssl version
OpenSSL 3.0.1 14 Dec 2021 (Library: OpenSSL 3.0.1 14 Dec 2021)

さらに追記

よくよく考えたら自分が公開しているサーバはdockerコンテナのnginxをリバースプロキシとして使用しているので、そこも確認しないとでした。そのため確認したところそちらも問題なさそうでした。
意外だったのが、OpenSSLをインストールして使用しているのかと思ってましたがopenssl versionコマンドでは確認できず、nginxコマンドで確認できました。nginxはdockerイメージを使用させてもらっていたので知らなかったのですが、nginxをインストール時にOpenSSLを指定してビルドする感じなんですかね。

# nginx -V
nginx version: nginx/1.17.4
built by gcc 8.3.0 (Debian 8.3.0-6)
built with OpenSSL 1.1.1c  28 May 2019
TLS SNI support enabled
<載せていいのか調べるの面倒だったので割愛>

hackers-high.com