pslaboが試したことの記録

はてなダイヤリーからはてなブログに引っ越してきました

この日記は現在実行中の減量記録を含む個人的なメモとして始めましたが、最近はコンピュータやガジェット、ハック、セキュリティネタのほうがメインになっております。

はてなダイヤリー時代はカテゴリ分けが適当だったのですが、これはそのうち直します。


OpenWRT のイメージに ds-lite を組み込んだカスタムイメージを作る

OpenWRT をインストールしてからパッケージを後付けで追加するのは微妙に面倒だなあ、と思っていたのですが、実は OpenWRT のサイトでカスタムイメージをビルドできるページがあることに気づきました。

まず、特定のデバイス向けのファームウェアを検索してダウンロードページを開きます。 firmware-selector.openwrt.org

開いたページからデフォルトのイメージをダウンロードできるのですが、ページ内をよく見ると「インストールされるパッケージのカスタマイズ」という表示があります。ここに自分が必要なパッケージ名を追記して「ビルドをリクエスト」すると、カスタムイメージがビルドできました。

ds-lite を含む追加パッケージを指定してビルドしてみる

"ds-lite luci-i18n-base-ja" を追記してビルドをリクエストすると、一応ビルドできました。そして、ビルドしたイメージを実機に展開してみたのですが、Web UI が開かない。

どうやら、パッケージカスタマイズのデフォルトのリストには、luci がパッケージリストに含まれていないようなのです。

インストール後の構成に luci を追加する。

OpenWRT に ssh 接続した状態などで、以下のコマンドを実行します。

opkg update
opkg install luci

これを実行すると luci がインストールされ、Web UI が再び利用できるようになりました。ということは、最低限、以下の内容をパッケージのカスタマイズで指定すれば良いのかな。 "ds-lite luci luci-i18n-base-ja"

あまり厳密に検証していないので、上記以外にもデフォルトイメージにあり、しかしカスタムイメージにないパッケージがあるかもしれませんが、とりあえず備忘録として残して起きます。

ESET 製品(個人向け)の macOS Monterey 12 対応予定日は 2021/11/1

ESET 製品の macOS Big Sur 11 対応版(日本語版)提供は OS リリースから半年後の 2021 年 3 月までずれ込んだので macOS Monterey 12 についても若干不安があったのですが、今回は予想よりも速く対応が行われているようです。

日本語版については V6.11.2.0 で対応が行われ、2021/11/01 が対応予定日ということです。

eset-support.canon-its.jp

なお、日本語以外の言語向けには 2021/10/07 に 6.11.1 がリリースされていたそうです。

forum.eset.com

従って、ESET.COM にアクセスすると、日本語版以外のバージョンはすでに入手可能になっています。

www.eset.com

シェルスクリプトで時刻の秒が 0 秒になるまで待つ処理を書く

ローカル環境で 1 分ごとに特定の処理を実施する必要が生じたのでシェルスクリプトを書こうと思ったのですが、次のように安易に sleep 60 を行うと 1 分ごとの実行にはなりません。

#!/bin/bash

while : ; do
    (何かの処理)

    sleep 60
done

例えば、何かの処理、の部分に常に 5 秒かかるとしたら sleep は 60 秒ではなく 55 秒にすべきです。しかし処理にかかる時間がさまざまな外部要因に依存して変動する場合にはこれではダメですね。

こういう場合はスクリプト自身でループや sleep を行わずに単一実行だけ行うようにして、cron で毎分の実行にするのが基本かもしれませんが、1 分ごとに新規にスクリプトが実行されるのはイマイチのように考えました。

そこで sleep の待ち時間を動的に変えるように実装することにしました。どうせなら、計測時のタイムスタンプの秒が 00 になるようにしたかったので、処理の実施後に現在の秒を取得し、そこから sleep の時間を算出するようにしてみました。

#!/bin/bash

while : ; do
    sleepwait=$(( 60 - $( date +"%S" ) ))
    echo "sleepwait ${sleepwait}"
    sleep "${sleepwait}"

    (何かの処理)
done

この実装では初回の実行時から処理実施時の秒は 00 になります。また初回の実行は即時の実行ではなく、スクリプト実行開始から 1 分以内に行われます。すぐに実行を開始する必要があり、初回実行時のタイムスタンプで秒が 00 にならなくてもよく、かつ 1 回目と 2 回目の処理が 1 分間隔ではなくてもよいなら次のようにしても良いでしょう。

#!/bin/bash

while : ; do
    (何かの処理)

    sleepwait=$(( 60 - $( date +"%S" ) ))
    echo "sleepwait ${sleepwait}"
    sleep "${sleepwait}"
done

なお、いずれの方法でもミリ秒単位の誤差は生じますが実用上の問題はないので、そこはあまり気にしないことにします。macOSLinux の両方で動作することを確認済み。

OpenWrt 21.02 がリリースされています

2021/09/04 付けで最初のバージョン 21.02.0 がリリース

openwrt.org

19.07 から 21.02 へのアップグレードは sysupgrade パッケージでサポートされるそうです。ただし 19.07 からのアップグレードを行うと LuCi に HTTP でアクセスすると HTTPS にリダイレクトされるようになるそうです(21.02 新規インストールでは自動リダイレクトされない)。HTTPS リダイレクトされるとブラウザで証明書の検証エラーが表示されることに注意が必要です。

リリースノートには次のハイライトが紹介されています。

  • WPA3 support included by default
  • TLS and HTTPS support included by default
  • Initial DSA support
  • Increased minimum hardware requirements: 8 MB flash, 64 MB RAM
  • New network configuration syntax and board.json change
  • New hardware targets
  • Dropped hardware targets
  • ASLR activated
  • Kernel with container support
  • SELinux support
  • Core components update

WPA3 が標準サポートになったのはとてもありがたいです。WPA3 は 19.07 でも追加インストール可能できましたが、OpenWrt のマイナーアップデート作業(例えば 19.07.1 → 19.07.2 へのアップデート)では、自分が追加インストールしたパッケージは消えてしまうので、インストールしなおす必要がありました。

特に 19.07.5 や 19.07.6 のようにリリースが短期間で行われた場合には、マイナーアップデートを行うモチベーションが下がる(パッケージの追加と設定をやり直す必要がある)ので、こういう機能が標準で組み込まれるのはとてもありがたいです。モチベーションを下げないために ImageBuilder を用いてカスタムイメージを作り、自分が必要なパッケージが最初から含まれた状態にすることもできますが、そこまでするのもどうかという感じもあります。

紛失防止タグ TrackR のサービスが 2021/08/15 で終了したみたいだ

紛失防止タグというと、MAMORINO, Tile, TrackR などが以前から存在しつつも、一部のユーザー層を除くとあまり利用が進んでいない中で Apple の AirTag が登場し、どうなるかなと思っておりましたが、TrackR はどうやら 2021/08/15 にサービスを停止したようです。サイトにアクセスしてみると、英文でサービス終了に関する案内が出ていました。

www.thetrackr.com

We regret to inform you that TrackR will no longer be supported on Apple or Android devices after August 15, 2021. We want to thank you for your trust and support throughout the years. We hope TrackR was the perfect resolution for finding your lost items.

ざっくり日本語訳すると次の通りでしょうか。

この度、TrackRは2021年8月15日以降、AppleおよびAndroid端末でのサポートを終了させていただくことになりました。 長年にわたるお客様の信頼とご支援に感謝いたします。TrackRがお客様の紛失物を見つけるための完璧な解決策であったことを願っております。

この手のデバイスクラウド経由で紛失デバイスを探すには多くのユーザーが当該アプリをインストールしている必要があるため、AirTag のように iOS ベースで利用できるデバイスが圧倒的に有利すぎるから、なかなか辛いものがありますね。何かのプラットフォームの上で展開するサービスは、そのプラットフォーム自身がその機能を包括してしまうと、どう考えても負け戦になってしまう。

個人的にも TrackR のデバイスを複数所有しているので、サービス停止は残念ではあります。

AWS の海外リージョンに HTTP proxy を建てる (SSH ポートフォワーディング 利用)

ウェブサイトによっては接続元 IP アドレスの国情報に基づいてコンテンツの出し分けを行っている場合があります。そのようなサイトに日本からアクセスする方法として VPN サービスを利用するという方法が知られているようですが、率直なところ、信頼してよいかどうかわからない回線にデータを流すのはリスクが高すぎると感じます。

このため、AWS の海外リージョンで HTTP proxy を建ててみることにしました。

接続方法

HTTP proxy を建てる場合の接続方法には、次の 3 種類が挙げられると思います。

  1. HTTP proxy に対して HTTP 接続する
  2. HTTP proxy に対して VPN トンネルで接続する
  3. HTTP proxy に対して SSH ポートフォワーディングで接続する

1.は HTTP 通信は平文のままで送受信されます。HTTPS 通信エンドツーエンドで暗号化されたままで扱われるので、プロキシを経由しない通信と同等の安全性です。ただしプロキシサーバーのポートがインターネット側に開いているのは第三者による悪用のリスクがあるので、できれば接続元 IP アドレス制限はかけるべきだし、IP アドレス制限を行わない場合は HTTP 認証をつけるべきです。

  1. は、VPN を導入する時点で構築しなければならない要素が増えており、しかも VPN トンネルを張れるなら HTTP proxy を使う必要性が減るので一旦除外します。

  2. は Proxy サーバのポートをインターネット向けに開く必要がないので第三者に利用されてしまうリスクが大幅に減ります。ただしスマートフォンタブレットからは利用できないという制限を伴います。

このように提供形態によって制約がありますが、今回は SSH ポートフォワーディングを用いることにします。

Squid のインストールと設定

EC2 インスタンスまたは Lightsail でインスタンスを作ります。費用的には Lightsail のほうがコストがかからないのではないでしょうか。

インスタンスには次のように接続します。これは SSH 接続元 機材の 3128/TCP に対するリクエストを、SSH 接続先の localhost:3128 に転送する設定を含んでいます。

ssh -L 3128:localhost:3128 ec2-user@IPアドレス

インスタンスには squid と nc (netcat) をインストールします。netcat は Proxy サーバが Web サイトにアクセスする際に用いるリクエストヘッダを簡易的に検証する際に使用します。

sudo yum install squid nc

squid の設定ファイルには、少なくとも次の設定を入れます。

# ログをリアルタイム出力させる(処理数の多いサーバーでは非推奨)
buffered_logs off

# X-Forwarded-For を付けない(接続先 Web サーバに対して HTTP Proxy 経由のアクセスの痕跡を見せない)
forwarded_for delete

# Via ヘッダを付けない(接続先 Web サーバに対して HTTP Proxy 経由のアクセスの痕跡を見せない)
request_header_access Via deny all

設定完了したら squid を起動します。

sudo systemctl start squid.service

squid のステータスは次のように取得できます。

sudo systemctl status squid.service

● squid.service - Squid caching proxy
   Loaded: loaded (/usr/lib/systemd/system/squid.service; disabled; vendor preset: disabled)
   Active: active (running) since 日 2021-09-05 07:24:38 UTC; 54s ago
  Process: 4834 ExecStart=/usr/sbin/squid $SQUID_OPTS -f $SQUID_CONF (code=exited, status=0/SUCCESS)
  Process: 4829 ExecStartPre=/usr/libexec/squid/cache_swap.sh (code=exited, status=0/SUCCESS)
 Main PID: 4837 (squid)
   CGroup: /system.slice/squid.service
           ├─4837 /usr/sbin/squid -f /etc/squid/squid.conf
           ├─4839 (squid-1) -f /etc/squid/squid.conf
           └─4840 (logfile-daemon) /var/log/squid/access.log

 9月 05 07:24:38 ip-172-26-7-17.us-west-2.compute.internal systemd[1]: Starting Squid caching proxy...
 9月 05 07:24:38 ip-172-26-7-17.us-west-2.compute.internal systemd[1]: Started Squid caching proxy.
 9月 05 07:24:38 ip-172-26-7-17.us-west-2.compute.internal squid[4837]: Squid Parent: will start 1 kids
 9月 05 07:24:38 ip-172-26-7-17.us-west-2.compute.internal squid[4837]: Squid Parent: (squid-1) process 4839 started
$

■動作確認

インスタンス側で netcat を次のように実行します。

sudo nc -l 80

この状態でブラウザから http://インスタンスIPアドレス/ にアクセスしてみます。そうすると次のリクエストヘッダがブラウザから送出されていることがわかります。

$ sudo nc -l 80
GET / HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Firefox/91.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Upgrade-Insecure-Requests: 1
Host: インスタンスのIPアドレス
Cache-Control: max-age=259200
Connection: keep-alive

squid.conf では X-Forwarded-For や Via を削除するように設定しているので HTTP プロキシを経由しているような通信には見えづらいと思います。Cache-Control を消す、消さないということについてはさまざまな判断があると思いますが、今回の設定ではこの削除までは行っていません。

OpenWrt 19.07.8 リリース (2021/08/07)

OpenWrt 19.07.8 がリリースされています。前回のリリース 19.07.8 から半年ほど空いていますね。

openwrt.org

主要な Security fixes は 4 点。そのうち 1 点は FragAttacks への対処ですね。Wi-Fi の規格や実装に関する脆弱性であり、ほぼすべての機器が影響を受けるので、これは潰しておきたい。 https://www.security-next.com/126150

残りの 3 件は管理 UI の LuCI に関するクロスサイトスプリクティング脆弱性対応のようです。

Fix FragAttacks (fragmentation and aggregation attacks) vulnerabilities in cfg80211, mac80211, ath10k and ath10k-ct

We are not sure if some closed source firmware files are still affected by these problems.

Security Advisory 2021-08-01-1 - XSS via missing input validation of host names displayed (CVE-2021-32019)

https://openwrt.org/advisory/2021-08-01-1

Security Advisory 2021-08-01-2 - Stored XSS in hostname UCI variable (CVE-2021-33425)

https://openwrt.org/advisory/2021-08-01-2

Security Advisory 2021-08-01-3 - luci-app-ddns: Multiple authenticated RCEs (CVE-2021-28961)

https://openwrt.org/advisory/2021-08-01-3

Various security fixes in packages

https://openwrt.org/releases/19.07/changelog-19.07.8#security_fixes