Windows Server 2019 で Windows Admin Center のポップアップを無効化する

Windows Server 2019 の起動時 (というか、サーバー マネージャーの起動時) に Windows Admin Center (WAC) のポップアップ [Windows Admin Center でのサーバー管理を試してみる] が出ますが、以下のレジストリで無効化できそうでした。

HKLM\SOFTWARE\Microsoft\ServerManager\DoNotPopWACConsoleAtSMLaunch

  • 0: サーバー マネージャー起動時に WAC のポップアップを表示 (既定)
  • 1: サーバー マネージャー起動時に WAC のポップアップを無効化

そもそもサーバー マネージャー自体を毎回起動させたくない場合は以下も一緒に設定しましょう。

HKLM\SOFTWARE\Microsoft\ServerManager\DoNotOpenServerManagerAtLogon

  • 0: ログイン時にサーバー マネージャーを起動 (既定)
  • 1: ログイン時にサーバー マネージャーを起動しない

 

Procmon で RegSetValue してるのを探すだけだから簡単ですね。

 

コマンドでやりたい場合は以下でいけるかな。

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ServerManager" /v DoNotPopWACConsoleAtSMLaunch /t REG_DWORD /d 1 /f
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ServerManager" /v DoNotOpenServerManagerAtLogon /t REG_DWORD /d 1 /f

 

ちなみに、Windows Admin Center 自体は非常に良いものなので、ぜひ使ってみてくださいな。

指崎さんのスライドがわかりやすいのでオススメです。

 

 

 

 

ログオンの監査の話

クラウドの時代になって、ポチポチするだけで Public IP を持った VM が手軽に作れる時代になりましたが、その一方で Public IP で直接アクセスできるの怖いなぁと思う話を先日きいたので、注意喚起の意味も込めてブログのネタにしてみるなど。

 

以下は至って普通の Windows VM ですが、[Event Viewer] – [Windows Logs] – [Security] から、”Audit Failure” でフィルターすると、AdminXXX とか、UserXXX とか、SUPPORT とか、ありがちなユーザー名で謎の IP からログインが多数試行されてたりします。

 

Details の中身をよく見てみると、どういうユーザー名で (TargetUserName)、どういうアクセス方法で (LogonType)、どこから (IpAddress) アクセスがあったかがわかります。詳しくは以下のドキュメントとか見てもらえればと思いますが、RDP の場合には LogonType は 10 とかで記録されて、その他ネットワーク越しのアクセスだと 3 とかが多いかな。

で、アクセス元の IP を適当に調べてみると、上記の例ではロシアからのアクセスで、既に複数の Abuse (迷惑行為の報告) が上がってるみたいですね。

まあ、Failure なのでログオンされてはいないはずですが、調べてみると結構な数のログインが試行されているので、初めて見たときは結構な衝撃を受けると思います。脆弱なユーザー名・パスワードを使ってると、デプロイして数時間や数日で乗っ取られて攻撃元にされたり、その結果として自分自身が加害者側として報告される可能性もあるので、Firewall で特定の IP 以外からはブロックするとか、VPN 越しに Private IP でしか接続できなくするとか、オンプレ・クラウド問わず気を付けましょう。

あと、逆に攻撃された場合は当該 IP の管理者へも報告するといいと思います。(Microsoft 所有の IP の場合は以下から報告できます)

クラウドだと Azure も AWS も Public IP Range は公開されてますし、それに限らず我が家のコンテナ データセンターで使ってるグローバル IP アドレスなんかも普通にログイン試行されてる形跡があったりします。

手軽に検証環境とか作っちゃいがちですけど、IaaS の場合は OS やミドルウェアの管理はユーザーの責任範囲になるので、ユーザーとパスワードの管理をはじめ、セキュリティ対策には十分に気を付けましょうね、というお話でした。

Win 10 で共有フォルダーにアクセスできなかった件

新しい NAS を買ったので、さっそく階層化ボリュームを構成してつなごうと思ったら、久々にこのエラーに遭遇したので対処策をメモっておきます。

組織のセキュリティ ポリシーによって非認証のゲスト アクセスがブロックされているため、この共有フォルダーにアクセスできません。これらのポリシーは、ネットワーク上の安全でないデバイスや悪意のあるデバイスから PC を保護するのに役立ちます。

Webで調べると、AllowInsecureGuestAuth のレジストリを書き換えれば繋がるとか雑な対処策がたくさん書かれていますが、これはセキュリティ上よろしくない。

 

というのも、この現象が出るのは Windows10 の Fall Creators Update (1709) でセキュリティ上の理由によって明示的に無効化された経緯があるから。

なので、匿名認証にならないように (PC\LocalUser -> NAS\NASUser とかアクセスした際に勝手に匿名認証にならないように) ちゃんと NAS と PC のユーザー管理をしましょうというお話。

  • PC と NAS に同じユーザー・パスワードのアカウントを作る
  • PC と NAS でユーザー・パスワードが違う場合は、[資格情報マネージャー] – [Windows 資格情報]に認証情報を登録する

 

SMB 周りはバージョンによって暗号化の有無とかも違うし、SMB1 は wannacry の件もあったし、古いものはさっさと駆逐しましょう。マジで。

Azure と VPN 接続して BGP で経路交換する際のタイマーの話

Azure と VPN でつないで、BGP で動的に経路交換するときの KeepaliveTimer / HoldTimer の話です。

結論から言うと、Azure の VPN Gateway 側は 60 / 180 sec になっていて、オンプレ側の機器で短く設定すれば調整可能という話。

 

どこのご家庭にもある FortiGate で確認してみます。

まずはタイマーの値が未設定の場合から。

config router bgp
    set as 65521
    set network-import-check disable
    config neighbor
        edit "10.0.255.4"
            set ebgp-enforce-multihop enable
            set next-hop-self enable
            set soft-reconfiguration enable
            set remote-as 65516
            set update-source "BGPloopback"
        next
    end
    config network
        edit 1
            set prefix 172.16.0.0 255.255.0.0
        next
    end
end

 

Neighbor の状態を見てみると、KeepaliveTimer が 60 秒、HoldTimer が 180 秒になっていることがわかります。

FG100E # get router info bgp neighbors
BGP neighbor is 10.0.255.4, remote AS 65516, local AS 65521, external link
  BGP version 4, remote router ID 10.0.255.4
  BGP state = Established, up for 00:00:10
  Last read 00:00:08, hold time is 180, keepalive interval is 60 seconds //実際に採用された値
  Configured hold time is 180, keepalive interval is 60 seconds //設定値 (未設定なので FortiGate の規定値)
  Neighbor capabilities:
    Route refresh: advertised and received (new)
    Address family IPv4 Unicast: advertised and received
    Address family IPv6 Unicast: advertised and received
  Received 41770 messages, 0 notifications, 0 in queue
  Sent 41829 messages, 16 notifications, 0 in queue
  Route refresh request: received 0, sent 0
  Minimum time between advertisement runs is 30 seconds
  Update source is BGPloopback

 

これに対して、FortiGate 側のコンフィグで明示的に 10 / 30 sec などの短い値を設定してみます。

config router bgp
    set as 65521
    set network-import-check disable
    config neighbor
        edit "10.0.255.4"
            set ebgp-enforce-multihop enable
            set next-hop-self enable
            set soft-reconfiguration enable
            set remote-as 65516
            set keep-alive-timer 10
            set holdtime-timer 30
            set update-source "BGPloopback"
        next
    end
    config network
        edit 1
            set prefix 172.16.0.0 255.255.0.0
        next
    end
end

 

で、Neighborを一度クリアして張りなおさせると、ちゃんと 10 / 30 sec になってますね。

FG100E # execute router clear bgp all

FG100E # get router info bgp neighbors
BGP neighbor is 10.0.255.4, remote AS 65516, local AS 65521, external link
  BGP version 4, remote router ID 10.0.255.4
  BGP state = Established, up for 00:00:16
  Last read 00:00:07, hold time is 30, keepalive interval is 10 seconds //実際に採用された値
  Configured hold time is 30, keepalive interval is 10 seconds //設定値 
  Neighbor capabilities:
    Route refresh: advertised and received (new)
    Address family IPv4 Unicast: advertised and received
    Address family IPv6 Unicast: advertised and received
  Received 41786 messages, 0 notifications, 0 in queue
  Sent 41845 messages, 17 notifications, 0 in queue
  Route refresh request: received 0, sent 0
  Minimum time between advertisement runs is 30 seconds
  Update source is BGPloopback

 

逆に、長めの時間を入れてみます。

config router bgp
    set as 65521
    set network-import-check disable
    config neighbor
        edit "10.0.255.4"
            set ebgp-enforce-multihop enable
            set next-hop-self enable
            set soft-reconfiguration enable
            set remote-as 65516
            set keep-alive-timer 120
            set holdtime-timer 360
            set update-source "BGPloopback"
        next
    end
    config network
        edit 1
            set prefix 172.16.0.0 255.255.0.0
        next
    end
end

 

この場合は 60 / 180 sec になったことが確認できます。

FG100E # execute router clear bgp all

FG100E # get router info bgp neighbors
BGP neighbor is 10.0.255.4, remote AS 65516, local AS 65521, external link
  BGP version 4, remote router ID 10.0.255.4
  BGP state = Established, up for 00:00:00
  Last read 00:00:00, hold time is 180, keepalive interval is 60 seconds //実際に採用された値
  Configured hold time is 360, keepalive interval is 120 seconds //設定値 
  Neighbor capabilities:
    Route refresh: advertised and received (new)
    Address family IPv4 Unicast: advertised and received
    Address family IPv6 Unicast: advertised and received
  Received 41809 messages, 0 notifications, 0 in queue
  Sent 41866 messages, 18 notifications, 0 in queue
  Route refresh request: received 0, sent 0
  Minimum time between advertisement runs is 30 seconds
  Update source is BGPloopback

 

ということで、Azure VPN Gateway とオンプレ側の VPN デバイスの短い方になるみたいですね。

(機種によっては相性というか、Interoperability の闇に飲まれることもあると思うので、ちゃんと検証しましょう)

Azure で DHCP の挙動を見てみる

Azure VM のお作法として、IP アドレスは DHCP 取得が必須 & OS 内で NIC の設定変更は原則 NG というのがありますが、DHCP の挙動ってあんまり情報ないので調べてみました。

というのも、route print したときに見慣れない経路があるんですよね。

168.63.129.16 は言わずと知れた Azure 基盤の仮想 IP、169.254.169.254 は Instance Metadata / Scheduled Events なんですが、個別に経路が入ってるのって不思議ですよね。

あと、前々から ipconfig /renew できない件も疑問だったので、とりあえずパケットを取ってみることに。

168.63.129.16 に対して DHCP Request をユニキャストで出してます。
応答ないので再送してますね。

その一方で、ipconfig /release してから ipconfig /renew すると挙動が違います。
# 複数行まとめてコマンドを流さないとネットワークが切れて死ぬので気を付けましょう。

こちらもパケットを取ってみると、一回 release してるので、255.255.255.255 にブロードキャストしてますね。

ちゃんと応答も帰ってきてますが、中身を細かく見てみると RelayAgentIP に 168.63.129.16 が。
そして、ClasslessStaticRoute に168.63.129.16 と 169.254.169.254 入ってます。こいつが正体か。

ということで、パケットを見たら謎が解けてスッキリしました。

 

せっかくなので Windows Server の DHCP のオプションも見てみたところ、ちゃんとあるんですね。知らんかった。

ということで、分からないことはパケットを見るのが一番だなぁと思ったのでした。

Azure のリソース定義を JSON で取得したい

Resource Explorer で取れるような JSON のリソース定義を Azure PowerShell で取ったことがなかったのを思い出したのでやってみた。
https://resources.azure.com/

Get-AzureRmResource して ConvertTo-Json するだけなので、やってみたら一瞬だった。

一応、Depth だけ忘れずにつけましょう。(Max: 100)

$Resource = Get-AzureRmResource -ResourceId "/subscriptions/49dde45f-5712-44b2-b0ab-296bde83af6b/resourceGroups/shuda0721/providers/Microsoft.Network/publicIPAddresses/shuda0721" -ExpandProperties
$Resource | ConvertTo-Json -Depth 100
{
    "ResourceId":  "/subscriptions/49dde45f-5712-44b2-b0ab-296bde83af6b/resourceGroups/shuda0721/providers/Microsoft.Network/publicIPAddresses/shuda0721",
    "Id":  "/subscriptions/49dde45f-5712-44b2-b0ab-296bde83af6b/resourceGroups/shuda0721/providers/Microsoft.Network/publicIPAddresses/shuda0721",
    "Identity":  null,
    "Kind":  null,
    "Location":  "japaneast",
    "ManagedBy":  null,
    "Name":  "shuda0721",
    "ParentResource":  null,
    "Plan":  null,
    "Properties":  {
                       "provisioningState":  "Succeeded",
                       "resourceGuid":  "6b900826-15aa-4c8b-a5a2-69707cd285b6",
                       "publicIPAddressVersion":  "IPv4",
                       "publicIPAllocationMethod":  "Dynamic",
                       "idleTimeoutInMinutes":  4
                   },
    "ResourceGroupName":  "shuda0721",
    "ResourceType":  "Microsoft.Network/publicIPAddresses",
    "Sku":  null,
    "Tags":  null,
    "Type":  "Microsoft.Network/publicIPAddresses"
}

null のパラメーターが一部混ざってたり、並び順が違ったりするのが若干気になるけど、まあリソース定義をバックアップしておきたいだけだし、十分使えるかな。

 

P.S.
JSON を CSV でくれという人が世の中に入るらしいですね…。