30代後半で転職したSEのブログ

転職の経験談、IT技術情報など紹介していきます。

TLS1.0/1.1の無効化

TLS1.0/1.1にはPOODLE攻撃により暗号化した通信が盗聴される可能性があるという脆弱性があるらしく、
こちらを無効化した方がよいようです。
Windows Server でIISを利用している環境では、デフォルトでTLS1.0/1.1が有効となっており、
クライアントのBrowser側がTLS1.0にしか対応していない場合はTLS1.0で通信することになります。

無効化にする手順はこちらに記載がありました。
https://blogs.technet.microsoft.com/jpazureid/2018/01/10/adfs-tls12/
レジストリキーを追加する必要があります。

キー:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.0\Server
名前:Enabled
タイプ: REG_DWORD
値:0

名前:DisabledByDefault
タイプ: REG_DWORD
値:1

キー:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.1\Server
名前:Enabled
タイプ: REG_DWORD
値:0

名前:DisabledByDefault
タイプ: REG_DWORD
値:1

暗号化技術や証明書の仕組みなど、なかなか理解できないことばかりですが、
下記のサイトにTLS設定のガイドラインがありました。
https://www.ipa.go.jp/security/vuln/index.htmlhttps://www.ipa.go.jp/security/vuln/ssl_crypt_config.html

リモートデスクトップ プロキシ越え その2

windows2020.hatenablog.com
以前、紹介したリモートデスクトップのプロキシ越えでは、
mstscがプロキシを経由せず、自端末からクラウドグローバルIPと直接通信しようとして、
エラーとなっていました。

今回、ようやくmstscがプロキシを経由する設定が見つかりました。

それは以下の環境変数

  • http_proxy="xxx.domain.local:8080"
  • https_proxy="xxx.domain.local:8080"

こちらを設定すると、mstscがプロキシを経由して、
無事プロキシを超えてhttpsプロトコル
リモートデスクトップ接続ができました。

Kindleでダウンロードに失敗する

AmazonKindleで漫画をよく読むのですが、以前に買った漫画がダウンロードできないという事象が起きました。
なぜか、11巻だけ失敗する。

色々調べていくと、どうも複数の端末からダウンロードしており、そのダウンロード数制限に引っかかっていたようです。

対処方法はAmazonのサイトにログインして
アカウント&リスト
→アカウントサービス
 →コンテンツと端末の管理
  →端末
古い端末を選択して登録の解除
で解消しました。

携帯を買い替えて使っていくと、登録されている端末数が増えていつの間にか制限に引っかかるようです。

AWS解約

去年のちょうど今頃、AWSの検証用にアカウントを作成しましたが、最近はめっきりAzureを使うようになったので、解約をしてみました。

アカウントの解約 - AWS 請求情報とコスト管理

上記のURLを参考にして、5分で解約できました。

最近、株式口座などどんどん解約しているのですが、どれも紙の書類を郵送したり、なかには3往復ぐらい書類のやりとりをしないと解約できなかったり、またまた、解約用のWebページが見つからず、電話でないと解約できなかったりとすることが多かったのですが、AWSは調査時間あわせても10分で解約できました。

f:id:windows2020:20180524000839p:plain

家に帰るとかゆくなる

最近、仕事が終わり、帰ろうとすると、事務室を出て、エレベーターに入ったあたりから全身かゆくなります。
家に着いた時がピークで、寝ると翌日にはおさまっています。

Google先生に聞いてみると、リラックスした瞬間に疲れやストレスがたまっていると、かゆみが出てくることがあるらしいです。
疲れがたまっているのかもしれませんが、最近は朝4時か5時ぐらいには目が覚めてしまい、長時間寝れていないのが原因かもと考えています。

ペットボトルのキャップ

私が子供のころはペットボトルで販売されている飲料は少なく、ほとんどが缶ジュースでした。
よく、コーラを振って、名札の安全ピンで蓋のところに穴をあけ、噴射させて遊んでました。

ペットボトルが普及しだしたのは1996年ごろらしいです。
500ml以下の飲料にもペットボトルを使えるようになって、普及したようです。
確かこのころは桃の天然水など流行っていた気がします。

ペットボトルが普及してから約20年経つわけですが、ペットボトルのキャップは
20年前と変わらず、そろそろ進化してもいいのではないかと最近思います。
キャップをしっかり閉めることで、こぼれないようにできているのですが、
あけるときには少し時間がかかるので、開けやすくこぼれにくいキャップが開発されると嬉しいです。

希望としては冷蔵庫をあけて、ドリンクをコップに入れて、冷蔵庫を閉めるまでが10秒以内になると
いいなと思います。

リモートデスクトップのプロキシ越え

Azureなどのクラウド環境にWindowsOSを立ち上げると、インターネット経由でリモートデスクトップ接続することになります。会社のネットワークからインターネットにアクセスする場合はプロキシサーバーやファイアウォールを経由する構成になっていることが多く、通常httpやhttps以外のプロトコルはブロックされていると思います。そのため、会社のネットワークからAzure上のWindowsリモートデスクトップでアクセスすることはなかなか難しいです。

結局はプロキシ越えはできなかったのですが、惜しいところまで行けましたので、まとめておこうと思います。

こんな構成だったら成功したはず

RDP over httpsなどでググると解説いただいているページを見かけるかと思います。今回試した方法はRemote Desktop Gateway(以下RD Gateway)を踏み台にして、目的となるサーバにアクセスする方法です。
ネットワーク構成が以下のようなものであれば、アクセスは成功したかと思います。

自分の端末 > ファイアウォール > RD Gateway > ターゲットのサーバ

自分の端末からRD Gateway経由でリモートデスクトップ接続をすると、ファイアウォールhttps(443)のポートで通過するようになります。自分の端末から直接、ターゲットのサーバにリモデでアクセスしようとすると通常はrdp(3389)のポートでアクセスしようとするため、ファイアウォールでブロックされることになります。

こんな構成でもいけるはず

AzureであればAzure Load Balancerを使って以下のような構成もできるはずです。

自分の端末 > ファイアウォール > Azure Load Balancer > ターゲットのサーバ

NAT機能を利用して、Azure Load Balancerがhttps(443)で受け付けて、rdp(3389)に変換するという方式にします。
この構成であれば、RD Gatewayを設定するよりも短時間に設定できます。mstsc上でターゲットのサーバのIPアドレスを指定する際に、IPアドレス:443 と指定すればいけるはずです。

今回NGだった原因

それは、mstscがプロキシ経由で通信してくれなかったからです。
今回試した構成は以下のようなものでした。

自分の端末 > プロキシ > ファイアウォール > RD Gateway > ターゲットのサーバ

mstscがRD Gateway経由でターゲットのサーバにアクセスするように設定はできるのですが、アクセスしようとするとプロキシを経由せずにRD Gatewayにアクセスしようとしてファイアウォールでブロックされてしまいました。
Windows 8の事例ですが、IEのプロキシ設定がmstscのプロキシ設定に反映されるという記事をみかけてやってみたのですが、どうやってもプロキシを経由してくれませんでした。

mstscでプロキシを明示的に設定できると嬉しいのですが。。。