アカウント名:
パスワード:
PPT資料でも
Only as secure as the security of the signature database.
で、ここからが本題。 CDとかに署名DBを置くのであれば、セキュリティFixとかでバイナリが入れ替わる度に焼き直ししなきゃいけないんですよね? だったら最初からバイナリはCD上に置いて、CDからしかバイナリは実行できないようにした方が早いんじゃないかと・・・ CDだと最初の一度目の実行には多少時間かかるかもしれませんが、それはDB参照する時も一緒だし、2度目からは(RAMさえ潤沢にあれば)ディスクキャッシュが効きます。 何らかのバグでディスクキャッシ
CDとかに署名DBを置くのであれば、セキュリティFixとかでバイナリが入れ替わる度に焼き直ししなきゃいけないんですよね? だったら最初からバイナリはCD上に置いて、CDからしかバイナリは実行できないようにした方が早いんじゃないかと・・・
至極ごもっとも,と思ってPDF資料を読み直してみたらちゃんと書いてありました.
>至極ごもっとも,と思ってPDF資料を読み直してみたらちゃんと書いてありました.
「面白そうだ」と思って作ってみたけど、色々穴があったので無理矢理こじつけた「利用価値」という感じがします。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
起動前binaryチェックサム作成とチェックサム確認用デ (スコア:2, 参考になる)
署名、と言う話だけど、コマンド自身のチェックサム結果を内部に埋め込むか、
システム側に上記のコマンドのチェックサム結果のデータベースを持っていて、
それを起動直前にチェックして、結果が合致すればコマンドが起動できる、って
ものみたいですね。
#コマンド単体だと、トロイの木馬が正直にチェックサムつけてたら
#置き
---- redbrick
Re:起動前binaryチェックサム作成とチェックサム確認 (スコア:2, 参考になる)
PPT資料でも
と言ってますし,その辺はちゃんと分かってるみたいです.Re:起動前binaryチェックサム作成とチェックサム確認 (スコア:1, 興味深い)
で、ここからが本題。
CDとかに署名DBを置くのであれば、セキュリティFixとかでバイナリが入れ替わる度に焼き直ししなきゃいけないんですよね?
だったら最初からバイナリはCD上に置いて、CDからしかバイナリは実行できないようにした方が早いんじゃないかと・・・
CDだと最初の一度目の実行には多少時間かかるかもしれませんが、それはDB参照する時も一緒だし、2度目からは(RAMさえ潤沢にあれば)ディスクキャッシュが効きます。
何らかのバグでディスクキャッシ
Re:起動前binaryチェックサム作成とチェックサム確認 (スコア:1)
至極ごもっとも,と思ってPDF資料を読み直してみたらちゃんと書いてありました.
Re:起動前binaryチェックサム作成とチェックサム確認 (スコア:1, 興味深い)
>至極ごもっとも,と思ってPDF資料を読み直してみたらちゃんと書いてありました.
- 攻撃に成功してもrootkitも置かずバイナリも改竄しなければ,そもそも攻撃を受けたかどうかが管理者には分からない
- Honeypotだけセキュリティを上げても無意味だし、他のシステムより先にHoneypotへ攻撃してくれると期待する理由がわからん
という気がします。Honeypotは、クラッカーの生態を観察する:-)とか、クラッカーの身元を特定して逮捕、告発するためには有用ですが、そのためには少しでも長く留まっていてくれた方が良い。
しかし、こういう仕組みを入れてしまうと、速攻で「おいししくない」と思われて逃げられてしまうので意味が無い。
「面白そうだ」と思って作ってみたけど、色々穴があったので無理矢理こじつけた「利用価値」という感じがします。