セキュリティのためのコンピューター名の命名規則
私はセキュリティ監査を行っており、ホストの役割と実行中のサービスを、コンピューター名（nslookupを使用）だけで簡単に識別できることがわかりました。
わかりにくいコンピュータ名を使用し、攻撃者がネットワーク上のマシンの役割を特定することが困難になるように、これを報告したいと思います。信頼できる組織のセキュリティ命名規則にリンクすることで、この提案にある程度の重みを付けたいと思います。いくつか検索したところ、見つかりませんでした。既存のものはありますか？
予測可能なホスト名を使用してネットワーク上のマシンの役割を攻撃者が特定するという1つのリスクしか特定していません。
予測可能で説明的なホスト名を使用しないことで、オペレーターのエラーが増加するという競合するリスクを逃したと思います。
これは私がそれらの矛盾する測定を評価する方法です：
予測できないホスト名を使用する
メリット
攻撃者は、ネットワークのレイアウトを決定するために（かなり）より多くの労力を費やし、侵入の試みで最も収益性の高いターゲットを特定する必要があります。
リスク
オペレーターエラー。ユーザーと管理者は、システムとその正しい役割を識別するのが難しい場合があります。混乱を招くテストシステムと本番システム。
- 確率：高
- 影響：高
理由：ほとんどの人間は、「ランダムな」データが関係するひどい記憶を持っています->高い確率。
また、通常、信頼できるユーザーや管理者が重大なミスを犯すことを防ぐための障壁はほとんどありません->重大な影響。
予測可能なホスト名を使用する
メリット
オペレーターのエラー率の低下、管理と自動化の容易さ。
リスク
攻撃者はまた、ネットワークのレイアウトを決定し、侵入の試みで最も収益性の高いターゲットを特定するのが簡単になります。
- 確率：中
- 影響：低
根拠：すべての命名規則がブラックハットの攻撃者にとって直感的であるとは限りません->中確率。
また、ホスト名を使用してネットワークレイアウトを予測することは単なるショートカットですが、攻撃者が他の方法で学習できない情報は提供しません。また、ホスト名で公開されているサーバーの役割を知っていても、自動的にサーバーの脆弱性が高まるわけではありません（多かれ少なかれ価値があります）。 ->影響が少ない。
あなたの結論を裏付けるすぐに利用できる情報がないという事実は、あなたにその妥当性についていくつかの考えを与えるはずです。
重要なのは、攻撃者が既に参加している場合は、とにかく追加のフットプリントを行う必要があるということです。ホスト名はdatabase.xyz.intranetの可能性がありますが、nmapが1521（Oracle）、1433（SQLサーバー）、または5432（Postgress）を提供する場合、考えられる脆弱性に関するいくつかの情報が提供されます。そのwww.companyname.comはおそらくバックエンドデータベースサーバーではありませんが、それは最小限です。
一方、開発者は本当にlinux20195681.intranetでSQLクエリを実行できますか？オンプレミスクラウドの2番目のデータベースを起動するのは何ですか？意味のある名前を付けると、彼らの生活も簡素化されます。そしてもちろん、午前2時に呼び出されるスタンバイの方が簡単です。
また、実サーバーがロードバランサーの背後に隠れている場合もあります。 VIPは、通常、機能名とその背後のホストにシーケンス番号を取得します。
小さな組織の場合は、ホストにテーマ名を付けることを検討することもできます（たとえば、私の自宅のPiはpi、rho、sigma、phiなどと呼ばれます）。それでも、私はsigmaが私の家であることを覚えるのに苦労しています自動化、DNSサーバーなどのpsiなどです。そうです、Zeusを運用データベース、Jupiterをテスト、Odinを開発のテーマにするかもしれませんが、ある時点で、あらゆる形式の多神教がサーバーの数に制限を課します。
ですから、機能的な名前を付けた方がいいです。
一方で、特定のものや魅力的なものにしないでください。ホストを呼び出すprivatekeybackup.intranetは、もう少し注意を引くでしょう。
ホスト名（rfc8117）をランダム化するいくつかのアイデアがありましたが、それはクライアントにとってより問題のようです。
あなたが提唱しているのは、「あいまいなセキュリティ」と呼ばれています。理論的にはあいまいなことは、事態を悪化させずに追加の保護を提供しますが、通常、実際には事態を悪化させます。それは、（1）エラーを引き起こすシステムに複雑さを追加し、（2）どの情報が秘密で何が秘密ではないかについての理解を薄めます、そして（3）自明ではない維持費がかかるかもしれません。
（1）の例は、機密性が高いという事実が名前からは明らかではなかったために、機密性の高いサーバーに低セキュリティ設定を適用する管理者です。
（2）の例は、IT部門から秘密と思われるサーバー名の開示を求められるユーザーです。その後、ITのふりをして攻撃者からパスワードを開示するように依頼された場合、驚かれることも疑わされることもありません。
（3）の例は、あいまいなサーバー名を維持するために、ネットワークが侵害されたと疑うたびにITを変更する必要があるという事実です。