漫画村の判例を読んでみて
漫画村の首謀者の一人が出所したとかで、ツイッターで色々更新されているのでフォローして成り行きをたまに見ているのですが、漫画村の判例をちゃんと読んだことないなと思い読んでみました。(以下漫画村の判例らしいです)
https://www.courts.go.jp/app/hanrei_jp/detail4?id=90489
ざっくりと興味あるところを読んでいるだけなので、あいまいなところもありますが、争点としては以下のような感じっぽいです。
意外だったのは、1については首謀者自身であったり某ひろ〇き氏などもリバースプロキシで他のサイトの情報を表示しているだけでコンテンツは保持していないと聞いてました。しかし判例ではコンテンツのアップロードもしていたっぽい共謀者の供述がされてます。
とはいえあんなサイトを作るくらいだから実は漫画村にコンテンツアップロードしてました、で捕まるのは何かしっくりこないですよね。それくらい対策をしてそうな気がします。控訴もしてないですし。
色々思うこともありますが深く踏み込む気もないので、この辺にします。
自分が知っている話題について裁判の判例読むの面白いですね。いつかのコインハイブの件もそうでした。
気になる裁判などあったら今後も判例を読んでみようと思います。
今後はほぼ日記となるでしょう
ここ2週間くらいElastic Stackに良くも悪くもドはまりしてしまい、何か記事を書いている場合じゃないってくらい没頭してました。 そのせいでニート期間中にQiitaやnote、はてなブログを色々更新しようかなと思っていたのですが、なかなか更新できず。
ドはまりしていた内容などは、個人で使用しているMattermostにメモはしてあるのですが、それを改めて整理してアウトプットするのは面倒だなぁ、躓いた内容をメモしながらパブリックにアウトプットできるのないかなー、と思っていたところZennにスクラップの機能を今日見つけました。
このスクラップの機能、上記紹介サイトにも記載してある通り取り組んでいることや解決方法がまだわかってないことの試行錯誤中のログを残す感じで記載できます。当初このブログで自分が書きたいと思っていたのは、色々試行錯誤した内容やその時のどう考えて行動したかなどを書きたいなと思っていたのですが、それをまとめ直そうとすると時間がかかってしまうため筆不精となってました。
ということで、これは自分がパブリックにアウトプットできる機会が増えるかも!と思い早速今日試してみました。
スクラップの内容は、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では以下のような画面が。
はて。Google Apps Script APIもちゃんと事前にONにしてます。
また上記ログで表示されているnpm install -g npm@9.1.1
もあとでDockerfileに追記して実行してみても同じ結果です。
試しに--no-localhost
のオプションを外して実行してみると何やら成功しそうな画面が表示されます。
ただしこれはclaspを実行した環境でGUIが使用できる場合のコマンドのため、そのまま許可しようとしてもhttp://localhost:<port>/?code=xxxxxxxxxxxxxxx
のURLに飛ばされるため失敗します。
エラー内容確認
このまま試行錯誤しても解決しなさそうなので、諦めてエラー内容などを詳細に確認してみます。 まずはエラーの詳細を読んでみます。
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を使用したインスタンスへの接続方法を色々試していました。
あと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管理方法
背景
サーバの設定ファイルを変更したことの履歴とかを残したいけどどうすればいいだろうとずっと考えていて、以下の記事を見かけたしまねしてみるか~と思ってました。
が、記事最後に記載されてありましたが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インストール
- Windowsターミナル起動
- WSLインストール
powershell wsl --list --online #インストール可能なディストリビューション確認 wsl --install #ディストリビューション指定なしでUbuntuをインストール
- インストール完了後再起動
- WindowsターミナルからUbuntuを選択してWSL起動
- 初期ユーザ/パスワード設定(sudo可能なユーザ)
- 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
らしいです。
イメージをプルして
$ 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に分類される脆弱性について修正リリースが今日~明日で出るらしいですね。
対象はバージョン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 <載せていいのか調べるの面倒だったので割愛>