月別アーカイブ: 2017年8月

DNSSEC ルートゾーン KSK ロールオーバーについて

DNSSECのルートゾーンKSKロールオーバーについて、ロールオーバー前後でDNSの検索に支障が出ないよう、各所から通達が出ている。

ルートゾーンKSKロールオーバーによる影響とその確認方法について (JPRS)
KSKロールオーバーについて (JPNIC)

(2017/10月予定だった切り替えが延期され、現在は 2018/10/11 に予定されています)

1. 管理下の DNS キャッシュは DNSSEC 検証をしているか

DNS キャッシュサーバーを管理している場合は、一応気を付けたほうが良い。管理下の DNS キャッシュサーバーに対して、dig コマンドでDNSSEC 対応済みドメイン (例: jprs.jp) の情報を検索したときに、回答に ad フラグが付いていたら「キャッシュサーバーでDNSSEC署名検証が有効になっている」状態なので、更新後の鍵を設定してやる必要があるかもしれない。

adフラグが付いている例:

$ dig jprs.jp. @mydns.example.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> jprs.jp.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26772
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 9
...

(参考: DNSSECチュートリアル~実践編~)

2. RHEL 7 / CentOS 7 + BIND の場合

named.confにデフォルトで以下の設定が入っていて、DNSSEC署名検証が有効になっている。

options {
...
        dnssec-enable yes;
        dnssec-validation yes;

        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.iscdlv.key";

        managed-keys-directory "/var/named/dynamic";
...
};
...
include "/etc/named.root.key";

対処法1. パッケージアップデート

/etc/named.iscdlv.key と /etc/named.root.key に、ルートゾーンの鍵が入っている。パッケージバージョンがbind-9.9.4-38.4以降であれば、上記2ファイルに新しい鍵が追加されるので、bindのパッケージをアップデートしてしまうのが一番手っ取り早く安心できる方法ではある。

対処法2. 自動更新に任せる

9.9.4-38.3以前のパッケージを使っている場合でも、RFC5011 の自動更新に対応している。named を起動すると更新後の鍵は /var/named/dynamic/managed-keys.bind{,.jnl} として自動保存される。このため、特に何かをする必要はない。

# とはいえ、CVE-2017-3142、CVE-2017-3143への対処が9.9.4-38.5以降で行われているので、パッケージを更新した方が良い。

3. RHEL 7 / CentOS 7 + Unbound の場合

デフォルトの /var/lib/unbound/root.key には古い鍵しか入っていないが、/etc/unbound/unbound.conf に以下の記述があり、自動更新が有効になっている。

server:
...
        auto-trust-anchor-file: "/var/lib/unbound/root.key"
...

unbound のデーモンを起動すると、/var/lib/unbound/root.key に新しい鍵が追加される。

このため、これらの設定を変更していなければ、特に対処の必要はない。

4. 確認、その他

EDNS0を無効化していないこと、経路上でTCP53が通ること、フラグメントパケットが通ることも確認しておく。

大きなサイズの DNS 応答に対応できているかどうかは、DNS-OARCが確認用のレコードを用意してくれているので、以下の dig コマンドで確認できる。

$ dig +bufsize=4096 +short rs.dns-oarc.net txt

非対応のキャッシュサーバだと、以下のような回答が返ってくる。

rst.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net.
"203.0.113.1 DNS reply size limit is at least 490"
"203.0.113.1 lacks EDNS, defaults to 512"
"Tested at 2017-08-31 01:19:47 UTC"

可用性セットを考慮したAzure仮想マシンのリストア

Azure ポータルからの操作では可用性セットの中に仮想マシンをリストアできないので、PowerShellで実行する。

まず、Azure PowerShellの環境を整えておく(参考)。

さらに、リソースグループ/仮想マシン/Recovery Services vault/ストレージアカウントの名前を事前にAzureポータルで調べておく。この例では、以下のようなリソース名になっている。

  • リソースグループ:Test01_RG
  • 仮想ネットワーク名:Test01_VNET
  • Recovery Services vault:Test01-Backup
  • 元の仮想マシン名:web1
  • 復元先仮想マシン名:restoretest1
  • ストレージアカウント名:test01st
  • リージョン:東日本

1. コンテキストをRecovery Services vaultに設定する

Get-AzureRmRecoveryServicesVault -Name "Test01-Backup" | Set-AzureRmRecoveryServicesVaultContext

2. 仮想マシンを選択

FriendlyNameオプションの引数に、復元したい仮想マシンの名前を入れる。

$namedContainer = Get-AzureRmRecoveryServicesBackupContainer -ContainerType "AzureVM" -Status "Registered" -FriendlyName "web1"
$backupItem = Get-AzureRmRecoveryServicesBackupItem -Container $namedContainer -WorkloadType "AzureVM"

3. 対象とする復元ポイントを探す

最近1週間のバックアップオブジェクトを配列rpに入れる。

$startDate = (Get-Date).AddDays(-7)
$endDate = Get-Date
$rp = Get-AzureRmRecoveryServicesBackupRecoveryPoint -Item $backupItem -StartDate $startDate.ToUniversalTime() -EndDate $endDate.ToUniversalTime()
$rp[0]

最終行、$rp[0]の実行で、一番最近の復元ポイントが表示される。これ以外を選びたい場合は$rp[1]などを順次表示して、日付と時刻(UTC)で判断して選ぶ。

4. 復元ポイントを選択して、ディスクを復元する

$rp[0]の復元ポイントの仮想ディスクを戻す。

$restorejob = Restore-AzureRmRecoveryServicesBackupItem -RecoveryPoint $rp[0] -StorageAccountName "test01st" -StorageAccountResourceGroupName "Test01_RG"
Wait-AzureRmRecoveryServicesBackupJob -Job $restorejob -Timeout 43200

1行目で復元ジョブを実行できるが、ジョブ完了前にプロンプトに戻ってしまうので、2行目のWait-AzureRmRecoveryServicesBackupJobを実行して完了を待つ。

5. 復元ジョブの情報を元にJSONファイルを作成する

$destination_pathには、JSONファイルのフルパスを記述する。コマンドを実行するユーザで書き込めるフォルダを指定すること。

$restorejob = Get-AzureRmRecoveryServicesBackupJob -Job $restorejob
$details = Get-AzureRmRecoveryServicesBackupJobDetails -Job $restorejob
$properties = $details.properties
$storageAccountName = $properties["Target Storage Account Name"]
$containerName = $properties["Config Blob Container Name"]
$blobName = $properties["Config Blob Name"]
Set-AzureRmCurrentStorageAccount -Name $storageAccountName -ResourceGroupName "Test01_RG"
$destination_path = "C:\Users\test\Desktop\vmconfig.json"
Get-AzureStorageBlobContent -Container $containerName -Blob $blobName -Destination $destination_path

6. 復元する仮想マシンの設定をJSONファイルから読み込む

VMNameオプションで復元先仮想マシンの名前を指定する。元の仮想マシンと同じにすることはできない。

$obj = ((Get-Content -Path $destination_path -Raw -Encoding Unicode)).TrimEnd([char]0x00) | ConvertFrom-Json
$availabilitySet = Get-AzureRmAvailabilitySet -ResourceGroupName "Test01_RG" -Name "test_availability_set"
$vm = New-AzureRmVMConfig -VMSize $obj.'properties.hardwareProfile'.vmSize -VMName "restoretest1" -AvailabilitySetId $availabilitySet.Id

7. ディスクの設定を追加する

下記の例ではOSディスクがrt1-osdiskという名前に、データディスクがrt1-datadisk1, rt1-datadisk2,…という名前になる。

Set-AzureRmVMOSDisk -VM $vm -Name "rt1-osdisk" -VhdUri $obj.'properties.storageProfile'.osDisk.vhd.Uri -CreateOption "Attach"
$vm.storageProfile.OsDisk.OsType = $obj.'properties.storageProfile'.OsDisk.OsType
foreach($dd in $obj.'properties.storageProfile'.DataDisks)
{
  $dataDiskName = "rt1-datadisk" + $dd.lun
  $vm = Add-AzureRmVMDataDisk -VM $vm -Name $dataDiskName -VhdUri $dd.vhd.Uri -Lun $dd.lun -CreateOption "Attach"
}

8. NICの設定を追加する

$nicName = "rt1-nic"
$pip = New-AzureRmPublicIpAddress -Name $nicName -ResourceGroupName "Test01_RG" -Location "japaneast" -AllocationMethod Dynamic
$vnet = Get-AzureRmVirtualNetwork -Name "Test01_VNET" -ResourceGroupName "Test01_RG"
$nic = New-AzureRmNetworkInterface -Name $nicName -ResourceGroupName "Test01_RG" -Location "japaneast" -SubnetId $vnet.Subnets[0].Id -PublicIpAddressId $pip.Id
$vm = Add-AzureRmVMNetworkInterface -VM $vm -Id $nic.Id

9. 仮想マシン復元を実行する

New-AzureRmVM -ResourceGroupName "Test01_RG" -Location "japaneast" -VM $vm

10. 後処理

あとはポータルで実施する。
・復元した仮想マシンのNICに、ネットワークセキュリティグループを追加
・復元した仮想マシンのNICに、元々のパブリックIPアドレスを付け替える
・復元した仮想マシンを、ロードバランサーのバックエンドプールに追加する

参考URL:
Azureでスナップショットの取得について(Azure Backup サービス)
AzureRM.RecoveryServices.Backup コマンドレットを使って仮想マシンをバックアップする
AzureBackupから可用性セットへリストアするPowerShellスクリプト

Azure PowerShellの準備

環境:Windows10 Pro 1703 64bitで確認。

まずローカルWindowsで管理者権限のPowerShellウインドウを開き、AzureRMモジュールをインストールする。

PS C:\WINDOWS\system32> Install-Module AzureRM

信頼されていないリポジトリ
信頼されていないリポジトリからモジュールをインストールしようとしています。このリポジトリを
信頼する場合は、Set-PSRepository コマンドレットを実行して、リポジトリの InstallationPolicy 
の値を変更してください。'PSGallery' からモジュールをインストールしますか?
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)  [?] ヘルプ (既定値は "N"): y
(Enterを押す)

あとは自動的にモジュールがインストールされる。

次に管理者権限PowerShellを閉じ、一般権限のPowerShellを開く。

Microsoftアカウントでログインする。

PS C:\Users\username> Login-AzureRmAccount

ポップアップウインドウが表示されるので、そこにユーザ名とパスワードを入力する。

これで準備完了なので、以下やりたいことを実行する。

参考URL:
Azure PowerShell のインストールおよび構成
Azure PowerShell と Resource Manager でリソースを管理する