pslaboが試したことの記録

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

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

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


OpenWrt で IPv6 IPoE 接続した場合にインターネット側からの IPv6 インバウンド通信が LAN 側に流れないことを検証する

OpenWRT

フレッツひかりに接続したルーターで IPv6 IPoE を有効にするとルーターの LAN 側クライアントにも パブリック IPv6 アドレスが割り当てられるため、その IPv6 アドレスに対して外部からのインバウンド通信が通りそうな感じがして、なんだか気持ち悪い感じがしますね。そこでインターネット側からの IPv6 インバウンド通信がルーターの LAN 側のノードまで到達するかどうかを検証しておきます。

なお、ここで紹介する手順を試すには、クラウドサービスのインスタンスまたは VPS サーバに対して ssh でログインし、必要なパッケージをインストールできる程度の知識が必要です。

注意事項

この検証は、あくまで私の環境での結果を示しているだけであり、すべての OpenWrt 構成で IPv6 インバウンド通信が LAN 側に到達しないことを保証するものではありません。この内容を盲信するのではなく、ご自身の環境についてはご自身で検証してください。

使用するもの

クライアント側が IPv6 で通信できていることを確認する

http://www.kame.net/ にアクセスして亀が泳いでいたら IPv6 でアクセスしています。

EC2インスタンスを用意する（その他のクラウドサービスや VPS でも IPv6 が利用可能であればよい）

EC2 の場合は t2.micro とかでインスタンスを立てて、IPv6 のアウトバウンド通信が通ることを確認しておきます。また、インバウンド通信を 8080/TCP について許可しておきます。接続元IPアドレスはローカル環境のアウトバウンド IPv6 アドレスに制限しておくのがベターですが、一時的な使い捨てのインスタンスですし、当該ポートでサービスが常時稼働するわけでもないので、0.0.0.0/0 や ::/0 に対する許可でも実質的な問題は起きないと考えられます。

ローカル環境からのアウトバウンド IPv6 アドレスは https://test-ipv6.com/ にアクセスすれば確認できます。ifconfig コマンドなどで確認しても良いのですが、不慣れな方にとっては、何をどのように見れば良いかの判断が難しいので、外部サービスに接続して確認するほうがお手軽です。

インスタンスを立てたら、次のコマンドにより、IPv6 でのアウトバウンド通信が通ることを確認しておきます。

ping6 www.google.com

また nc コマンドを sudo yum install nc でインストールし、www.google.com に対して次のように実行してみます。

$ nc -v -6 www.google.com 80
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 2404:6800:4004:810::2004:80.
HEAD / HTTP/1.0
Host: www.google.com

HTTP/1.0 200 OK
Content-Type: text/html; charset=ISO-8859-1
P3P: CP="This is not a P3P policy! See g.co/p3phelp for more info."
Date: ..........
Server: gws
X-XSS-Protection: 0
X-Frame-Options: SAMEORIGIN
Expires: ..........
Cache-Control: private
..........

HEAD, Host を送出して応答が帰ってくるなら特に問題なく通信できているので、Ctrl + c で nc を止めます。念の為、ホスト名ではなく IPv6 アドレス指定でも確認します。

$ nc -v -6 2404:6800:4004:810::2004 80
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 2404:6800:4004:810::2004:80.
HEAD / HTTP/1.0
Host: www.google.com

HTTP/1.0 200 OK
Content-Type: text/html; charset=ISO-8859-1
P3P: CP="This is not a P3P policy! See g.co/p3phelp for more info."
Date: ..........
Server: gws
X-XSS-Protection: 0
X-Frame-Options: SAMEORIGIN
Expires: ..........
Cache-Control: private

これで EC2 インスタンス側からの IPv6 アウトバウンド通信が通ることが確認できました。これが通らない場合は VPC で IPv6 が無効になっている可能性があります。AWS アカウントを以前から保有している場合はデフォルトの VPC にて IPv6 設定が有効化されていない可能性があります。

とはいえ、既存の VPC 設定を安易に変更できないでしょうから、この検証を行うために一時的に使用する VPC を作成し、検証が終わったら VPC を削除するのがよいと思います。

OpenWrt の LAN 側からEC2インスタンスに向けて通信する

EC2 インスタンス側で nc コマンドを以下のように実行し、8080/TCP で待ち受け状態にしておきます。

$ nc -v -6 -l 8080

次にクライアント側から EC2 インスタンスの IPv6 アドレスに向けて nc コマンドで接続します。接続先の IPv6 アドレスは EC2 コンソールなどで確認できます。

$ nc -6 EC2インスタンスのパブリックIPv6アドレス 8080

このように実行すると、EC2 インスタンス側の nc コマンドには次のようにメッセージが出力されるはずです。

$ nc -v -6 -l 8080
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Listening on :::8080
Ncat: Connection from クライアントのIPv6アドレス.
Ncat: Connection from クライアントのIPv6アドレス:クライアント側TCPポート番号.

この状態でクライアント側で任意の文字列を入力して enter を押すと、EC2 インスタンス側に送信されることが確認できます。また逆の操作も行えます。通信が通ることが確認できたら、Ctrl + C を押して nc コマンドを終了します。

クライアントに向けて同じ操作を行う。

こんどは OpenWrt の LAN 側へのインバウンドIPv6通信を検証しますので、手元の PC で次のように nc を 8080/TCP で待ち受けさせておきます。

$ nc -v -6 -l 8080

そして AWS の EC2 インスタンスから次のように実行してみると、nc コマンドはタイムアウトしてしまいました。

$ nc -v -6 クライアントのIPv6アドレス 8080
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connection timed out.

さらに、念のために OpenWrt から nc コマンドで LAN 側のクライアントに IPv6 で接続してみます。OpenWrt の nc コマンドでは IPv6 アドレスを [] で囲む必要があることに注意してください。実行したら任意の文字を入力してみると、LAN 側クライアントで実行中の nc コマンド側で文字が表示されることが確認できるはずです。

nc "[クライアントのIPv6アドレス]" 8080

これにより、つぎのことが検証できました。インターネット側からの IPv6 インバウンド通信が OpenWrt の LAN 側に届くことは無いようです。

  • OpenWrt の LAN 側クライアントからインターネット向けの IPv6 アウトバウンド通信 = 通る
  • インターネット側から OpenWrt の LAN 側への IPv6 インバウンド通信 = 通らない
  • OpenWrt 自身と OpenWrt の LAN 側クライアントとの IPv6 通信 =　通る

このようにテストすることにより、OpenWrt の LAN 側機器に対して外部から IPv6 でアクセスできないことが確認できました。

参考：その他の検証方法

ポートが開いているかどうかの確認ならば、nmap を使っても良いかもしれません。PC を 2 台用意し、片方は OpenWrt の LAN 側に収容、もう一台は IPv6 接続が可能な SIM とスマートフォンでのテザリングによるモバイルインターネット接続を行います。モバイルインターネット接続側の PC から nmap によりフレッツひかり + OpenWrt IPv6 IPoE 側にポートスキャンを行えば、ポートが開いているか、閉じているかを検証できると思います。

macOS でシェルスクリプトの実行完了時にターミナルを前面に表示する

macOS

シェルスクリプトの実行中に、特定のタイミングでターミナルを前面に表示させて、その実行状況を確認する必要が生じました。この処理は実行中のスクリプト側でコントロールしたかったので、方法を調べてみたところ、osascript で次のように操作すればよいことがわかりました。

osascript -e 'tell application "Terminal" to activate'

なお、ウィンドウを前面に持ってくる必要はないけれど、特定のタイミングになったら通知を受けたい、という場合は "display notification" を利用すればシステム通知にメッセージを送ることができます。

osascript -e 'display notification "通知したいメッセージ内容"'

追加オプションで title, subtitle を設定したり、通知音を指定したりできますので、単に状況を知りたい場合はこの方法も使えると思います。

AWS の IP アドレスを対話的な操作で抽出するスクリプト

Amazon Web Service

AWS ではサービスが使用する IP アドレスが公開されていて、特定のサービスとの通信だけを通したい場合に、この情報を用いてフィルタリングする設定を作る際に利用できます。

docs.aws.amazon.com

そしてこのページでは抽出方法も示されていますが、なんとなく、ノリと勢いだけで対話的なUIで抽出できるスクリプトを書いてみました。

なお、実行の際は peco と jq が必要です。 対話的な操作に peco を使用しており、JSON データの操作には jq を用いています。

また出力結果には curl + jq で同じ結果を取得する際のコマンド実行例も含めています。後日に同じ条件で最新の情報を取得したい場合には、対話的な操作を行わなくても容易に抽出が行えるようにしています。

#!/bin/bash

interactive_helper=peco
aws_ip_address_url="https://ip-ranges.amazonaws.com/ip-ranges.json"
ip_ranges=$( curl -s "${aws_ip_address_url}" )

service=$(
    echo ${ip_ranges} | jq ".prefixes[].service" -r | sort | uniq | ${interactive_helper}
)

region=$(
    (
        echo "ALL"
        echo ${ip_ranges} | jq ".prefixes[] | select (.service == \"${service}\") | .region" -r | sort | uniq
    ) | ${interactive_helper}
)

if [ "${region}" == "ALL" ]; then
    condition=".service == \"${service}\""
else
    condition=".service == \"${service}\" and .region == \"${region}\""
fi

echo "# service=${service}"
echo "# region=${region}"
echo "#"
echo "# curl -s ${aws_ip_address_url} | jq '.prefixes[] | select( ${condition} ) | .ip_prefix' -r | sort -n"
echo "# curl -s ${aws_ip_address_url} | jq '.ipv6_prefixes[] | select( ${condition} ) | .ipv6_prefix' -r | sort -n"
echo ${ip_ranges} | jq ".prefixes[] | select( ${condition} ) | .ip_prefix" -r | sort -n
echo ${ip_ranges} | jq ".ipv6_prefixes[] | select( ${condition} ) | .ipv6_prefix" -r | sort -n

例えば、S3 が使用する IP アドレスを大阪リージョンの分だけ出力させてみると次のようになります。

$ get_aws_iprange.sh 

# service=S3
# region=ap-northeast-3
#
# curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | jq '.prefixes[] | select( .service == "S3" and .region == "ap-northeast-3" ) | .ip_prefix' -r | sort -n
# curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | jq '.ipv6_prefixes[] | select( .service == "S3" and .region == "ap-northeast-3" ) | .ipv6_prefix' -r | sort -n
3.5.240.0/22
52.95.157.0/24
52.95.158.0/23
52.95.181.0/24
52.95.182.0/23
2406:daa0:6000::/40
2406:daf0:6000::/40
2406:daf8:6000::/40
2406:daf9:6000::/40
2406:dafa:6000::/40

ASIX のチップセットを用いた USB-LAN アダプタを macOS Big Sur で利用する方法を調べたら危険すぎるのでとてもおすすめできない件について

手持ちの USB-LAN アダプタのうち、ASIX AX88179 が用いられている製品は、macOS Big Sur に正式対応しておらず、Beta のドライバが提供されている状況です。

しかし、このドライバを利用する方法はあまりにも危険すぎると感じるので、普段使いの Mac に導入することはリスクが高すぎると感じます。

ドライバ自体はここから入手可能なので、リスクを理解して試したい方は自己責任でどうぞ。 https://www.asix.com.tw/en/support/download

このドライバの問題点は、システム整合性保護（System Integrity Protection: SIP）を無効化したままで利用しなければならない点にあります。

SIP を無効化する操作は、reFind のようなブートローダーのインストールでも必要な操作の一つですが、reFind の場合はインストールが完了したら SIP を再度有効化しても問題なく動作します。

しかし ASIX のドライバは SIP を無効化した状態で利用しつづける必要があります。SIP が有効の状態では、ストレージ上のシステムファイルを root 権限でも書き換えられないので、さまざまな脅威に対して効果的と考えられます。しかし SIP を無効化した状態で利用しつづけなければならないということは、そういうリスクを抱えた状態で利用しなければならないことを意味します。

このことを理解して利用する分には自己責任の範囲ですが、利用に伴うリスクを説明せずに安易に利用方法を記事化して案内するのは危険過ぎます。

AWS で EC2 の開始、停止、再起動を行うポリシーを書く

Amazon Web Service

AWS で既存の EC2 インスタンスの一覧取得や、それらの開始、停止、終了、再起動を行うポリシーを作成してみるテスト。

RunInstances を含めていないので、新規にインスタンスを作ることはできない。また、TerminateInstances も含まないので、既存のインスタンスに対する誤操作によってインスタンスを失うこともない。

このポリシーを IAM ユーザーにアタッチすれば、そのユーザーは AWS コンソールまたは AWS CLI 経由で EC2 インスタンスを操作できる。ただし、ステータスチェックやアラームの状態、EIP に関する許可を行っていないため、これらを参照することはできない。

あらかじめインスタンスID がわかっていて、なおかつ AWS CLI だけで操作する場合は DescribeInstances の許可をする必要はない。ただしEC2 コンソールは一覧表示してから操作する形式であるから、DescribeInstances を許可しない場合は EC2 コンソールから操作できない。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ec2:DescribeInstances",
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:StartInstances",
                "ec2:StopInstances",
                "ec2:RebootInstances"
            ],
            "Resource": "arn:aws:ec2:*:<AWS Acccount ID>:instance/*"
        }
    ]
}

EC2 コンソールで、ステータスチェックやアラームの状態、EIP の割り当ての有無くらいは確認させたい場合は、ec2:DescribeInstanceStatus, ec2:DescribeAddresses, cloudwatch:DescribeAlarms も許可する。cloudwatch:GetMetricData を追加すれば、EC2 コンソールの「モニタリング」よりメトリクスを閲覧できる。単にインスタンスの操作だけを行いたい IAM ユーザーに割り当てる Policy は、だいたいこんな感じだろう。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstances",
                "ec2:DescribeInstanceStatus",
                "ec2:DescribeAddresses"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:StartInstances",
                "ec2:StopInstances",
                "ec2:RebootInstances"
            ],
            "Resource": "arn:aws:ec2:*:<AWS Acccount ID>:instance/*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "cloudwatch:DescribeAlarms",
                "cloudwatch:GetMetricData"
            ],
            "Resource": "*"
        }
    ]
}

ec2:DescribeSecurityGroups や ec2:DescribeVolumes も許可すれば、EC2 コンソールでセキュリティグループの設定内容を確認したり、EBS ボリュームのボリュームサイズを確認できるけれど、単なる Operator にはそこまでの許可をしなくても良さげ。Describe... は Resource "*" のような広い参照範囲になるようだから、Operator に必要な参照権限を割り当てる必要はないだろう。

ESET Cyber Security macOS Big Sur 対応版の日本語版は2021年3月23日から提供開始の模様

macOS

英語版その他からは3週間ほど遅れてのリリースとなりますが、やっとリリースされるみたいです。詳細は以下のリンク先の通り。

eset-support.canon-its.jp

この日まで待てる方は、あと数日待ちましょう。待てないかたは、自己責任で英語版を入れているか、または他のセキュリティソフトに切り替えてしまっているはず。

私も自己責任で英語版を入れているけれど、英語版についてリリースが遅れたことは、まあ仕方がない部分はあるだろうと思います。今回の macOS Big Sur は以前の macOS 10.x で利用できた kext の廃止に伴う対応が必要になったようだから、やむを得ない部分はあるだろうなあ、と考えています。ただし kext の廃止はずいぶん前からアナウンスされていたはずなので、そういう意味では ESET の新しい macOS へのキャッチアップはちょっと遅い。

OpenWrt 19.07 では IPv6 IPoE + IPv4 DS-Lite の設定が Luci からの Web UI だけで設定できるようになっている

OpenWRT

先月にリリースされていた OpenWrt 19.07.7 をインストールするにあたり、久々にゼロから Luci の Web UI だけで基本的な環境構築を実施してみたのですが、IPoE IPv6 + DS-Lite IPv4 の環境を構築する作業は Web UI だけで行えることに気づきました。OpenWrt に ssh 接続して設定ファイルを調整するような作業は一切不要でした。

以下は Raspberry Pi 3 での環境構築手順のサマリです。これは openwrt-19.07.7-brcm2708-bcm2710-rpi-3-ext4-factory.img.gz を microSDHC に焼いた直後の初期状態からの手順です。スクリーンショット入りの手順はそのうちまとめるかも。

IPoE IPv6 接続を有効にする

一旦、LAN 側から設定を投入しつつ、WiFi を有効化して LAN 側の IP アドレス変更を実施したのち、LAN を DHCP, DHCPv6 のクライアントにするところまでの手順です。

これを実施することで IPoE IPv6 接続が有効化されます。プロバイダ側のサービスメニューが IPv6 が利用できるプランの場合は、ここまでの設定を行うと IPv6 でのインターネット接続が可能となります。

  1. PC を RasPi3 の LAN と直結し、192.168.1.1 にブラウザでアクセス
  2. WiFi を有効化する
  3. PC を LAN と WiFi で RasPi3 に接続する
  4. Interface に wan を追加する。Name = wan, Protocol = Static address, Interface = eth0 に設定する。IPv4 address = 192.168.1.1 に設定する
  5. Interface = LAN の IP アドレスを 192.168.1.1 以外のアドレスに変更する (ここでは 192.168.4.1 に設定）
  6. PC の WiFi 側の DHCP リースを更新し、ブラウザの別タブで 192.168.4.1 にアクセスする
  7. Interface = lan の Physical Settings から eth0 を除外する
  8. Interface = wan を DHCP Client に変更する
  9. Interface = wan6 を追加し、DHCPv6 client に設定する
  10. ここで一旦 OpenWrt を reboot し、RasPi3 の LAN をひかり電話の ONU に差し替える
  11. reboot 後に ping6 www.google.com を試したり、www.google.com にブラウザでアクセスできることを確認する。

IPv4 DS-Lite 接続を有効にする

IPv6 接続だけでは既存の多くのインターネット側サイトに接続できないため、DS-Lite パッケージをインストールして IPv4 DS-Lite による接続を有効化します。これにより IPv6 + IPv4 のすべてのサイトへのアクセスが行えるようになります。

  1. ds-lite を追加インストールし、RasPi3 を再起動する
  2. Interface = transix を追加し、 Protocol = Dual-Stack Lite にする
  3. DS-Lite AFTR address = gw.transix.jp 、Firewall Settings = wan に設定する
  4. クライアント PC から ping 8.8.8.8 へのアクセスが通ることを確認する。また、この状態で ping6 www.google.com へのアクセスが通ることを確認する
  5. ブラウザで https://test-ipv6.com/index.html.ja_JP にアクセスし、IPv4 と IPv6 の両方が通ることを確認する
  6. IPv4 だけの接続が行えるサイトにブラウザでアクセスして問題がないことを確かめる。