OSが「これはUnixシステムです！」に対する難読化の防御策である理由は何ですか。広く実装されていませんか？
タイトルで参照されている ジュラシックパークシーン は、技術に詳しい人にとっては滑稽に聞こえることで有名です。しかし、それはまた、私がWebセキュリティ、特にIoTデバイスに明らかに巨大な穴であると思われるものを示しています-攻撃者がサーバーまたはカメラまたはベビーモニターがLinuxを実行していることを発見するとすぐに、彼らは即座にそれがどのように機能するかについてのボリュームを知っています。彼らはSudoのようなコマンドがジューシーな大きなターゲットであることを知っており、シェルアクセスがlsやcatのような便利なツールの塊をもたらすことを知っています。
では、なぜOSが難読化されないのですか？Webヘッダーでバージョンを非表示にするだけではありません。 JavaScriptの縮小化または難読化と同様に、私はOS自体のバイナリーとファイルパスの名前を変更することについて話しています。 OSがSudoとlsの代わりにha7TrUOとRRI6e29コマンドを持っている場合、攻撃のクラス全体が実質的に役に立たないのではないでしょうか？どういうわけかリモートrootアクセスを得たハッカーを想像してみてください-彼らがコマンドを知らない場合、彼らはどうするでしょうか？
コンパイラーにとって、実装はかなり簡単です。 「この関数の名前を変更し、すべての呼び出しを行う」という最も単純なケースを取り上げます。 OSコンパイラとアプリケーションコンパイラに同じランダム化された名前を付けると、お互いに対話することができます。しかし、アプリケーションのセキュリティが低く、bashインジェクションに対して脆弱である場合でも、このような攻撃は無益です。
明らかに、この手法はすべてのシナリオで使用できるわけではありません。人間のシステム管理者が管理するサーバーのようなシナリオは別として、自動化によって管理されるデバイスまたはサーバーは、この防御策の主要な候補であるように思えます。
質問はもう少し具体的である必要があると思います：
- 説明されているOSの難読化は広く使用されていますか？
- 広く使用されていない場合、使用上の実用的または技術的な障壁は何ですか？
あなたのアイデアをバラバラにする前に、それは本当に面白いアイデアであり、考えるのはとても楽しかったと言いましょう。
既成概念にとらわれず、引き続き興味深い質問をしてください！
さて、これをやりましょう！
少し前に戻り、そもそもなぜベビーモニターがLinuxを実行しているのかを考えてみましょう。オペレーティングシステムがなく、アプリケーションがベアマイクロコントローラーコードで記述されている場合（Arduinoコードを考える）次に、攻撃者が使用するSudoまたはlsまたはシェルさえもないでしょうか？
私はここの専門家ではありませんが、私たちは業界として、開発者の便宜のためにLinuxを実行するのに十分な大きさのLinuxを配置することに引き付けられたことを期待しています。
- 開発時間の短縮：コンパニオンAndroidおよびiOSアプリを使用して、WiFiおよびBluetooth対応のWeb管理クラウド同期自己パッチウィズポッパーを構築する場合、Linuxにはすべてのライブラリ、ユーティリティ、およびあなたがそれを行う必要があるドライバー。
- テスト性の向上：デバイスがSSHポートを備えたbashまたはbusyboxを実行している場合、接続し、製品テスト段階で何が問題になっていたかを把握するのは非常に簡単です。
難読化のアイデアを機能させるには、Sudoやlsなどのコマンドラインユーティリティの名前だけでなく LinuxカーネルAPIごと も難読化する必要があります攻撃者がカーネルを直接呼び出す独自のコンパイル済みバイナリをドロップするのを防ぐため。だからあなたの考えをもう一度見てみましょう：
コンパイラーにとって、実装はかなり簡単です。 「この関数の名前を変更し、すべての呼び出しを行う」という最も単純なケースを取り上げます。 OSコンパイラとアプリケーションコンパイラに同じランダム化された名前を付けると、お互いに対話することができます。
このランダム化されたコンパイルを自分で行う必要があります。そうでなければ、誰かがグーグルでマッピングを調べることができます。
そのため、難読化されたカーネルAPIのマッピングを知っているのが自分だけになるように、「難読化コンパイラ」を使用してソースからカーネルを構築する必要があります。（ソースからLinuxカーネルを構築したことはありますか？確かにdocker pull Alpineよりも面倒です。これは、開発カルチャーが進んでいるように見える方向です）。
しかし、オペレーティングシステムは単なるカーネルではありません。そのミニPCデバイスに付属しているBroadcom BCM2837 wifiチップのドライバーが必要ですか？ Broadcomがソースコードを提供する場合は、コンパイラーを使用して、オフバス化されたカーネルに対してそのドライバーをビルドする必要があります。 GNU wifiおよびネットワークソフトウェアスタック全体をビルドする必要があります。OSが機能する前に、ソースを見つけてビルドパイプラインを追加するために、他にいくつ必要がありますか？
ああ、これらのいずれかのアップストリームレポジトリがパッチを発行した場合、あなたはそれを再構築する責任があります（カーネルバイナリと一致するコンパイラの難読化マッピングファイルを保存したと仮定）およびそれをデバイスにプッシュするのは、設計上、デバイスがベンダーによって作成されたパッチバイナリを使用できないためです。
ああ、ハッカーを阻止するために、これはありません"これはWhizpopper 1.4.7のバイナリファイルです"、ああ、そうする必要があります出荷したカーネルからper deviceまでのすべての一意に難読化されたバージョンを構築します。
だからあなたの質問に：
- 説明されているOSの難読化は広く使用されていますか？
- 広く使用されていない場合、使用上の実用的または技術的な障壁は何ですか？
答えは、ソースから文字通りすべてを見つけてビルドする必要がある場合、あなたが説明しているものは既存のソフトウェアコンポーネントを使用する目的をほとんど完全に無効にするということです。実際には、オペレーティングシステムを完全に廃止し、1960年のふりをして、アプリケーションをCPUマイクロコードに直接書き込む方が、労力は少ないかもしれません。
ほとんどの開発者よりもセキュリティが好きですが、f * thatが好きです。
マイクの答えは、開発の観点からこれが悪い考えである理由について私が提供しなければならないすべてを基本的に述べています（そして、Ghedipunkのコメントが言うように、使用できないセキュリティ機能はセキュリティを提供しません）。代わりに、なぜセキュリティの観点からなのかについてお話します。
答えは実際には驚くほど簡単です。それは時間の浪費であり、厳密により良いオプションがあります。すべての愚かなIoTの危険（「IoT」の「s」はSecureを意味することを忘れないでください）は、あなたが提案するようなアプローチでは地獄がうまくいかないため、そのような機能を実装することを気にしません。
- システムコールを制限するには、アイデア全体が機能しないだけです。攻撃者は、いくつかのレジスタを設定してオペコードとブームを呼び出すだけで、カーネル内で任意のシステムコールを実行します。それの象徴的な名前が何であるかを誰が気にしますか？確かに、syscallテーブルを改ざんしてこれを複雑にすることもできます（すべてを再コンパイルする必要がなく、カスタムカーネルのデバッグをまったく地獄の形にする必要がない場合）、使用しているOSを難読化するようなものです。とにかく、候補者が非常に少ないのに、なぜわざわざ？攻撃者がシステム上の既存のコードをリバースエンジニアリングしたくない場合でも、使用可能な呼び出しインデックスの検索スペースが組み込みシステムでこれまでに見たものよりも広い場合を除いて、ブルートフォースが可能になるはずです。
- 完全にアクセスできないようにできるのに、なぜコマンド名を難読化するのですか？
chrootはShellビルトインでは機能しませんShellを実行している場合ですが、それ以外の場合は問題なく機能しますが、カスタムビルドの単一目的はなぜでしょうかapp-in-a-boxはシェルを実行していますか？つまり、開発用ユニットにはテスト目的で1つインストールされますが、怠惰であったり、再び必要になると思われるため、小売イメージから削除されない可能性があります。しかし、攻撃者は、アプリが実行されているコンテキストからそれを実行することはできません。単純なchroot（またはより複雑なサンドボックス/刑務所/コンテナー）を使用すると、プログラムは、ジョブに必要なファイル以外のファイルを実行（またはアクセス）できなくなります。 - カーネルAPIへのアクセスを削除できるのに、なぜそれらを難読化するのですか？プロセス（またはその子孫...作成を許可されている場合）が実行できるものを制限できるサンドボックスシステムは多数あります。 https://stackoverflow.com/questions/2146059/limited-syscall-access-for-a-linux-application を参照してください
攻撃者がlsとcatを奪うことを目的としている場合は、難読化のより良い代替手段があります。それらのユーティリティをインストールしないでください。
これが広く実装アプローチであるとは言いませんが、少なくとも実装です。たとえば、ほとんど何も含まれていないDockerイメージのコレクション distroless を考えてみます。それらのいくつか（goのようなもの）は文字通りnothingを持っています。このようなコンテナーで実行されているシステムに対する攻撃は、実行するシェルがないため、シェルアクセスを取得できません。
そのようなコンテナー内のアプリケーションを攻撃してシェルアクセスを取得する唯一の方法は、コンテナーランタイムを回避することです。これは、それを正確に防ぐように設計されています。
Dockerイメージの例を示しましたが、同じ概念をオペレーティングシステム全般に適用できます。たとえば、lsおよびcatは、Debianのcoreutilsパッケージの一部です。 apt-get remove coreutilsそして、攻撃者がlsまたはcatを攻撃の一部として使用できないことを確信してください。もちろん、これはそれらを使用することもできないことを意味し、おそらく他にもcoreutilsに依存するものの多くを削除する必要がありますが、組み込みデバイスまたは1つのことだけを実行するサーバーの場合大丈夫かもしれません。
一般的な原則は、「攻撃面」を減らすことです。ターゲットが持つ「もの」が多いほど、攻撃が容易になります。開いているネットワークポート、コード行、インストールされているバイナリなどが考えられます。セキュリティを強化することが目的である場合は、不要な「もの」をすべて削除することから始めます。
難読化はセキュリティではなく、OSの難読化は基本的にナンセンスだからです。
一般的なOSは非常に多く、知識に基づいた推測を行う方法は非常に多くあります。 IISまたはMSSQL Serverを実行していることを検出した場合、その下で実行されているOSを推測できます。
どういうわけか、私の基盤となるOSについて何も知らないスタックを実行し、それに関するヒントをすべてマスクしても（フィンガープリントは重要です）、それでも私は多くを獲得していません。
セキュリティの点では、私がLinuxを実行していること、または私がDebian 8を実行していることを知っていても、あなたが取り組むことも、私が心配することもあまりありません。私が適切に強化されてパッチを適用していれば、あなたはあなたが望むものを何でも知ることができます。昨日ソフトウェアミュージアムに適用されたパッチレベルにいる場合、一連の攻撃はすべてを試してみるだけで私をひっくり返し、私のOSを難読化すると、いくつかの役に立たないエクスプロイトを試さざるを得なくなります。自動化された攻撃では、数秒間すべてが遅くなります。
難読化は機能しません。人々はあなたをスキャンしたり、指紋を取ったり、悪用のライブラリ全体を投げたりして、何が機能するかを確認できます。
実際の強化に費やした可能性のある時間を無駄にすると、実際にはセキュリティが損なわれます。
適切な硬化が機能します。上で言った「あなたはあなたが何でも知りたい」。私はスピーチをしたセキュリティ会議で自分のIPアドレスとrootパスワードを投稿しました。リモートrootログインと一連のサービスを有効にしたSSH。厳しく強化されたSELinuxマシン。私のスピーチを中断することに成功した人はいませんが、私のポリシーがまだ完全ではなかったときに、ある人がテキストファイルをルートディレクトリにドロップすることに成功しました。
補遺：あなたの出発点は映画でした。難読化は優れた映画デバイスです。そのような啓示は、ヒーロー（または悪役）が何らかの情報を見つけて進歩していることを視聴者に伝えるためです。それでも、コードが必要な場合でも、金庫がどこにあるかを見つけるのに相当するコンピューターです。それが実際に正しいかどうか、それが聴衆に適切な感情的なメッセージを伝えるかどうかは関係ありません。
非常に広範囲に及ぶ例として、独自のOSを備えたIntel Management Engineは、ファームウェア更新メカニズムが存在する場合にそのようなことを行いますが、ファームウェアは非常に特定の形式である必要があり、その詳細は機密情報です。未知のパラメータを伴うハフマンエンコーディングが含まれているようです。提案（基本的にファームウェアの対称暗号化）と同様に、MEはファームウェアの準備時に特定の変更を必要とし、実行時に標準メカニズムからの一致する偏差があります。
あなたが説明しているものは「あいまいさによるセキュリティ」と呼ばれ、広く知られているセキュリティアンチパターンです。これは新しい考え方ではなく、古くて悪い考え方であり、セキュリティ哲学に初心者ではない人々が、陥らないように教育されなければならないということです。
安全な家を設計していて、あいまいさは有望な戦略であると考えているとします。すべての家は、廊下や部屋、ドアノブ付きのドア、ライトスイッチなどで構築されています。これらは一般的に知られているため、侵入者がこれらの一般的に知られている構造要素によって家を簡単に移動できるため、これは安全ではないと考えるかもしれません。あなたは一から建築の原則を再設計しようとするかもしれません、ドアノブをrubiks立方体と取り替えて、侵入者を混乱させるために半分の高さの天井を作るなど。侵入者は、いったん中に入ると、彼の目で周りを見回し、彼の脳を使ってそれを理解することができるためです。ハッカーは本質的にパズル中毒です。
あなたの家を保護するための解決策は、非標準的な構造にすることではありません、それはより良いロック、安全な窓、適切なセキュリティシステムなどを持つことです。あなたは金を秘密の通路に隠したくないのです。そして、コステロはそのろうそく足に寄りかかって誤ってそれを開きます。良い秘密の組み合わせと改ざんアラームを備えた金庫に金を入れてください。コンピューターの同等機能は、公開鍵暗号、制限されたユーザーアクセスの役割、監視システムによる制限付きの認証済みアクセスを持ち、公開された表面積の減少、侵入の脅威ベクトルの緩和などを行っています。
コンピュータシステムをわかりにくくするための取り組みは、システムをサポートから遠ざけるだけであり、securityパッチを入手することを難しくし、安全な方法で使用することを難しくします。
編集：時々、いくつか セキュリティ 実際のセキュリティに加えて使用される場合、あいまいさは許容されます。一般的な例は、30000のような高いポートでSSHを実行することです。 SSHは暗号化されており、アクセスは認証された認証の背後にあります。これが本当のセキュリティです。しかし、それを高いポートに配置すると、誰かがクイックスキャンを実行している場合でも、最初から目立たなくなります。 OSを難読化しようとするなど、これより複雑なものは運用上の悪夢になり、実際のセキュリティ対策（パッチの最新状態など）がより困難になります。
考える使いやすさ
- 新しいシステム管理者に
ha7TrUOinsetead ofSudo、RRI6e29の代わりにlsなど...はい、必要な翻訳のリストがあります！ ローカルネットワークの閲覧も不可能であるべきです：全体的なビューを維持するために紙のリストを維持する必要があります！
すべての重要なコマンドの名前を変更すると、システムをアップグレードするためにこれを実行する必要があります！
そして Nick2253コメントアウト として、組み込みシステムを構築しようとする場合、最終製品を公開する前に難読化を行い、最終製品をテストする必要があります。
- home madeスクリプトを作成して、難読化のためにすべてをバインドする必要があります。
- 何かがうまくいかない場合、デバッグはトリッキーになります。
- デバッグを行うには、home made解読スクリプトを作成する必要があります。
- カスタムフィードバック（ログファイルを使用）も難読化解除する必要があります。
そうすることで、新しい潜在的なバグを含む重要な作業の層を追加します。
セキュリティの改善がほとんどない場合は、さらに参照してください
Obcurityは自分に害を及ぼす可能性があります。
思う低いレベル
ファイルの名前を変更しようとしても、アプリケーションとosレベルで機能しますが、これはすべて、標準ライブラリを使用します。攻撃者がバイナリ実行可能ファイルを送信すると、直接呼び出されますすべての標準ライブラリを難読化することもできます！ （ファイルシステム、ネットワークプロトコルを含む...）
変更されていないカーネルを使用している間、それらはstandard変数と名前空間を使用します。したがって、カーネルの難読化バージョンを作成する必要があります...
...次に、すべてを結合します！
まあ、すべてが難読化されている場合でも、アプリケーションはインターネットに対応する必要があります。難読化によって、これに関する概念上のバグを防ぐことはできません。
Obcurityすべてのレベルでない場合、セキュリティは向上しません。
完全なあいまいさインターネットに対応するために標準プロトコルを使用する必要があるため、実際には不可能です。
ライセンスを考える
distributeGNU/Linux を計画している場合は、 GNU GENERAL PUBLIC LICENSE GPLv で説明されているようにソースコードを共有する必要があります。 /または GNU LESSER GENERAL PUBLIC LICENSE LGPLv （使用するアプリケーションとライブラリに応じて）。これは、すべての分散製品とともに難読化メソッドの公開を暗示します。
2つの質問に厳密に答えます。
私は専門家ですが、非常に小さな焦点です。多くの異なる中小企業インフラストラクチャに取り組んでいる私は、数年前にいくつかの選択をしました。進化と歴史は私の選択を裏付けるように見えますが、それは私の個人的な価値観にすぎません。
説明されているOSの難読化は広く使用されていますか？
したがって、難読化が広く使用されているかどうかは本当にわかりませんが、securityは使用していませんobscurityによって、しないように推奨します。
広く使用されていない場合、使用上の実用的または技術的な障壁は何ですか？
バリアなし！ただそれは逆効果です。時間コストはすぐに巨大になり、セキュリティの向上は魅力です。
もちろん、最低限必要なことは次のとおりです。
- 不要な場合は
sshサーバーを起動しないでください Sudoをインストールせず、正しい権限、groupsおよび一貫した構造を使用してください。- グローバルインフラストラクチャを最新の状態に保つ!!!
小さなサンプルwhen light come over obscurity
sshの保護：双方向。Sshポートを22から34567に移動
- 軽くて素早くできますが
攻撃者がそれらを発見した場合、エンドユーザーがそれらを発見するまで、このポートに対してスムーズなブルートフォースを長時間かける可能性があります。
ファイアウォールをインストールする
- より強く、より多くの知識が必要ですが、.
最新の状態でより安全です。
OSにSudoとlsの代わりにha7TrUOとRRI6e29コマンドがある場合、攻撃のクラス全体が実質的に役に立たないのではないでしょうか？どういうわけかリモートrootアクセスを得たハッカーを想像してみてください-彼らがコマンドを知らない場合、彼らはどうするでしょうか？
より良い代替策は、最初からこれらのコマンドをインストールしないことです。 Linuxカーネルを実行するためにシェルが実際に必要シェルだとは思わないが、これは起動プロセスがsysV-initまたはsystemd以外のものであることを意味する。
ただし、他の人が指摘したように、これはセキュリティと開発の容易さの間のトレードオフです。残念ながら、多くのデバイスメーカーは、前者よりも後者を重視しています。
コンパイラーにとって、実装はかなり簡単です。 「この関数の名前を変更し、すべての呼び出しを行う」という最も単純なケースを取り上げます。 OSコンパイラとアプリケーションコンパイラに同じランダム化された名前を付けると、お互いに対話することができます。しかし、アプリケーションのセキュリティが低く、bashインジェクションに対して脆弱である場合でも、このような攻撃は無益です。
compiler's のヘルプが必要かどうかはわかりません。 linker ¹を変更してすべてのシンボル名にランダム化を適用することで、これをほぼ達成できると思います。おそらく、製造元だけが知っているソルトを使用してハッシュ関数を適用するだけで十分でしょう。これを行うためにソースコードが必要かどうかはわかりません。つまり、すでにコンパイルされたコードにマングリングを適用できると思います think 。
（¹これはうそだと思います。シンボル名を置き換えるためにオブジェクトコードを変更する必要があるかもしれませんが、これはアセンブラレベルに似ています。つまり、a）すべてを行っているわけではありません hard コンパイルC/C++/etcのビット。コードおよびb）C/C++ /その他のソースコードは必要ありません。 OTOHデバイスコードがPythonのようなものである場合、この種のことを実行できるかどうかはわかりません）。
ただし、プロセスをリバースエンジニアリングする可能性はまだあります。さらに、目的を達成するソルトを提供しない限り、GPL²（特にGPLv3）に違反する可能性があります。
実際、「GPLのため」がこれが表示されない主な理由です。各デバイスを異なるにすることは別として、実際に役立つ方法で実装するのは難しいでしょう。 OTOH、つまり、攻撃者は「 any Linux x.y.zを実行しているデバイス」の脆弱性を悪用することはできず、特定のデバイスのみをターゲットにできることを意味します。
（²簡単にするために、全体を通して「GPL」のみを使用しますが、これは一般的に [〜＃〜] l [〜＃〜] GPLに対応したものにも適用されることに注意してください。）
とはいえ、ソースを「変更」したため、GPLではソルトを公開する必要がないことに注意してください。シンボル名のランダム化がコンパイル時に発生する場合は、ソースを /変更していません。ソルトを公開する必要がある理由は、GPLがユーザーにGPL化されたライブラリの自分のバージョンを置き換えることを要求するためです。ソルトを知らない限り、ユーザーはこれを行うことができません。 。 （前述のように、GPLv2でこれを解除できる可能性がありますが、技術的な効果は、GPLv3が対処するために特別に書かれた「署名されたソフトウェアのみを実行する」と同様です。）
結局、ここには some の利点があるかもしれませんが、 particular システムを特により安全にすることはできません（それはよく知られています） 「あいまいさによるセキュリティ」は、一般にセキュリティではありません）。あなたができるが達成することは、単一のベクトルを介して多くのシステムをターゲットにすることを難しくしています。
公正な開示：私はこれだけを構築する会社のCTOです。必要なすべてのバイアスを解除します。
ISシステムカーネルアップ、デバイスドライバー、パッケージ、スタック全体のPERホストを1日に複数回完全に構築することは確かに可能であり、それは非常に効果的です。それがまさに私たちが行っていることです。 、そして私たちがお客様のお手伝いをします。私たちだけではありません-少なくともGoogleがすべてのマシンでこれを行っていると推測できます（リファレンスは近日公開予定です）。
今、マシンごとにゼロから再構築する機能があったら、何を変更できるでしょうか？
Kernel Self Protection Projectは、これをカーネル構造のランダムな順序変更によって既に許可しています： https://lwn.net/Articles/722293/ 。この記事は、Linus Torvaldsがセキュリティシアターと呼んでいる有名な交換についても指摘していますが、プロジェクトの作成者（Googleで働いています）は、「そうですね、FacebookとGoogleはカーネルビルドを公開していません。
これは、少なくともGoogleがこれを実行し、それを有用であると見なしているという推論に信頼をもたらします。クローズドセットでより多くの種類のスクランブルを実行できますか？最も基本的なレベルで、WindowsウイルスがLinuxまたはMacで実行されないのはなぜですか？フォーマットが違うからです。それはすべてx86の下にありますが、同じではありません。 2つのLinuxが同じように異なる場合はどうでしょうか。 WindowsとLinuxは、「難読化」されているわけではありません。これは、WindowsとLinuxのようにLinuxを異なるものにするための多くの方法がないためです。しかし、それは不可能ではありませんし、それほど難しいことでもありません。 KSPPのアプローチを採用し、それをsyscallsに適用してから、それらのsyscallsに対してすべてを再コンパイルします。それは壊れるのが非常に難しいでしょう-少なくともフライバイではありません。
しかし、あなたの質問はシンボルの名前変更（実行可能ファイル、ライブラリなどの名前）に関するものでした。これには2つの側面があります：（a）それは便利ですか？ （b）確実に実行できますか？
私たちはPHPコードインジェクションを一度にすべて解決する方法を探していました。何があっても HackerNewsはあなたに信じさせるでしょう 、PHPコードインジェクションは、インターネットメッセージボード以外では解決された問題ではありません。実際の開発者PHP開発者、管理者、およびユーザーは、継続的なコードインジェクションにさらされています。
そこで、ポリスクリプティング（許容的にMITライセンスのオープンソース）を試すことにしました： https://github.com/polyverse/polyscripted-php
私たちはこれを公に共有してフィードバックを求め、2つのWebサイト polyscripted.com と nonpolyscripted.com を実行します。これらのWebサイトは、ユーザーの名前に基づいて期待どおりに動作します。また、ペンテスターを雇ってそれを破ろうとしました。
そして、実行可能ファイル、共有ライブラリ、および（たとえば、Dockerコンテナー内の）閉じたセットでのエクスポートされたシンボルの名前変更の実験を始めたところです。個人的にはこれはそれほど価値があるとは思いませんが、少しだけ増えるのでしょうか？私はそう思う。したがって、それはコストに帰着します。さらに少ないコストでほとんど価値を得ることができないなら、なぜそれをしないのですか？それがまさに私たち全員がASLRを持っている理由です-それはスライスされたパン以来の最大の防御ではありませんが、すでに再配置可能なコードがあり、それを並べ替えるつもりなら、なぜそれを限界までプッシュしてランダム化しないのですか？
簡単に言うと、あなたが説明しているアプローチは、Moving Target Defenseの分野の多くの学者や、Googleのような少数の企業とともに、多くの人々（Google、Facebook、Linuxカーネルなどを含む）によって試みられています。 ASLRのようにそれをささいに消費できるようにしようとしています。
私はこれをハッカーの観点からどのように見るかを教えてくれます。
間違いなく、すべてのユーティリティの名前を変更する場合、私にとっては非常に困難で快適ではなくなりますが、何ができるでしょうか？
システム上のシェルにすでにアクセスできる場合は、busybox（1つのバイナリのすべての基本ユーティリティ）または基本的な操作に必要なバイナリのフルセットをアップロードするだけです。
特権をさらにエスカレートするには、suid-rootバイナリを探す必要があるかもしれませんが、それらの数はわずかです（Sudo、mountなど）。ハッカーはそのようなファイルをアップロードできません（彼がすでにrootでない限り）。私のシンプルな小さなLinuxシステムには、24のsuidバイナリしかありません。それぞれを手動で試すのはとても簡単です。
しかしとにかく、私は同意します、これはこの箱をハッキングすることを難しくします。このシステムを使用（ハック）するのは面倒ですが、可能です。そして、ハッカーは時間、日、月のシステムで動作します...しかし、管理者/ユーザーは何年もシステムで動作する可能性があり、ha7TrUOとRRI6e29の名前を思い出せません。たぶん誰もシステムをハッキングしようとはしませんが、管理者は毎日苦しみます。
しかし...セキュリティを高くしすぎてもユーザー/管理者にとって不快な場合-実際にはセキュリティを低くしていることがよくあります。 20文字以上の複雑なパスワードを適用する場合のように、ほとんどの場合、パスワードはモニターの付箋に書き込まれます。システムをそのように難読化する場合、優れたユーザーがそれに取り組むのは非常に困難になります。そして、彼らは彼らの生活を楽にするためにいくつかのことをしなければならないでしょう。たとえば、busyboxバイナリをアップロードできます。一時的。そして、彼らはそれを忘れるか、それを故意にそこに残します（彼らは少し後にそれを使用する予定だからです）。
Ssh接続は暗号化されているため、実際に発生します。いくつかのコアバイナリの名前を変更しても、これ以上のことはできません。また、それは多くの混乱を引き起こします。これらのユーティリティに依存するすべてのスクリプトは使用できなくなるか、または何らかの方法でプロキシ「deobfuscator」が必要になるため、最終的には攻撃ベクトルになります。しかし、私は、rootログインを許可せず、代わりにSudoを使用するように強制するいくつかのサーバーを実際に目にしました。 sudoersのユーザー名はいくらか秘密のままです。どれほど安全かはわかりませんが、専門家ではありません。
なぜすべてのドアに10個の鍵穴がないのに、そのうちの1つだけが実際にキーまたはロックピックに機能していないのですか？回答：ほとんどの場合、邪魔は泥棒の時間の10秒余分に価値がありません。
数百万の一意単独で作成ソースコードのオペレーティングシステムがあった場合、不明瞭になることがよくあります。実際問題として、私たちには一般的に使用されている約4つの固有のコードベースがあります-イベントタイミングによる自身に関するすべてのリーク情報、および特定のCPU機能をアクティブ化またはアクセスするためにチップメーカーが所定のマシンビットコードシーケンスを提供するいくつかの低レベルOS関数については、おそらく、まったく同じコードを含む短いシーケンスがあります。