タグ付けされた質問 「security」

セキュリティは製品ではなく、プロセスです。


17
データを回復不能にするために、ハードドライブに穴を開けるだけで十分ですか?
会社には多くのPCがありますが、多数のハードドライブを消去したい人はいません。また、物を破壊したい見習いツールメーカーもたくさんいます。したがって、数か月ごとに、見習いはドリルスルー用に2つの重いハードドライブバスケットを受け取ります。 私の同僚の何人かは、これは絶対にやり過ぎだと信じています。ただし、ドライブをドリルする前にドライブを拭かないと、一部のデータが回復可能になると考えています。 この質問によると、DBANでワイプすると、データは完全に回復不能になります。 DBANは問題ありません。ここに汚い小さな秘密があります-ドライブのすべてのバイトを上書きするプログラムはすべて永久にすべてを消去します。異なる書き込みパターンなどで複数のパスを実行する必要はありません。 穴を開けるのはどうですか?


8
Heartbleed:OpenSSLのバージョンを確実かつ移植可能にチェックする方法は?
私はGNU / Linuxおよび他のシステムでOpenSSLのバージョンをチェックする信頼性の高いポータブルな方法を探していたので、ユーザーはHeartbleedバグのためにSSLをアップグレードする必要があるかどうかを簡単に見つけることができます。 簡単だと思いましたが、すぐに最新のOpenSSL 1.0.1gを使用してUbuntu 12.04 LTSで問題に遭遇しました。 opensslバージョン-a 私はフルバージョンを見ることを期待していましたが、代わりにこれを手に入れました: OpenSSL 1.0.1 2012年3月14日 構築日:火6月4日07:26:06 UTC 2013 プラットフォーム:[...] 不愉快なことに、バージョンレターが表示されません。そこにfもgもありません。「1.0.1」だけです。リストされた日付は、(非)脆弱性バージョンの検出にも役立ちません。 1.0.1(af)と1.0.1gの違いは重要です。 質問: バージョンを確認するための信頼できる方法は何ですか? そもそもバージョンレターが表示されないのはなぜですか?Ubuntu 12.04 LTS以外ではテストできませんでした。 他の人もこの動作を報告しています。いくつかの例: https://twitter.com/orblivion/status/453323034955223040 https://twitter.com/axiomsofchoice/status/453309436816535554 いくつかの(ディストリビューション固有の)提案の展開: UbuntuおよびDebian:apt-cache policy opensslおよびapt-cache policy libssl1.0.0。バージョン番号をパッケージと比較してください:http : //www.ubuntu.com/usn/usn-2165-1/ Fedora 20:yum info openssl(Twitterの@znmebに感謝)およびyum info openssl-libs 古いバージョンのOpenSSLがまだ存在するかどうかの確認: 完全に信頼できるわけではありませんが、試してみてくださいlsof -n | grep ssl | grep DEL。Heartbleed:OpenSSLのバージョンを確実かつ移植可能にチェックする方法をご覧ください。なぜこれがうまくいかないかについて。 UbuntuおよびDebianでOpenSSLパッケージを更新するだけでは十分ではないことがわかりました。また、libssl1.0.0パッケージを更新し、-then-がopenssl …

11
HTTP w00tw00t攻撃への対処
私はApacheを備えたサーバーを持っていますが、最近mod_security2をインストールしました。 私のApacheバージョンはApache v2.2.3であり、mod_security2.cを使用しています これはエラーログからのエントリでした: [Wed Mar 24 02:35:41 2010] [error] [client 88.191.109.38] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:) [Wed Mar 24 02:47:31 2010] [error] [client 202.75.211.90] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:) [Wed Mar 24 02:47:49 2010] [error] [client 95.228.153.177] …



5
IT担当者から会社を保護するにはどうすればよいですか?[閉まっている]
私はオフィスのコンピューターとネットワークの管理を手伝うためにITの人を雇います。私たちは小さなお店なので、ITを行うのは彼だけです。 もちろん、私は注意深くインタビューし、参考文献をチェックし、バックグラウンドチェックを実行します。しかし、あなたは物事がどのように機能するかを決して知らない。 雇っている人が悪であることが判明した場合、どうすれば会社の露出を制限できますか 彼を組織内で最も強力な人物にすることを避けるにはどうすればよいですか?

7
OpenVPN対IPsec-長所と短所、何を使うべきか?
興味深いことに、「OpenVPN vs IPsec」を検索したとき、良い検索結果が見つかりませんでした。だからここに私の質問があります: 信頼できないネットワーク上にプライベートLANをセットアップする必要があります。そして私が知る限り、両方のアプローチは有効であるようです。しかし、どちらが優れているかはわかりません。 両方のアプローチの長所と短所、そして何を使用するかについてのあなたの提案や経験をリストできるなら、私はとても感謝しています。 更新(コメント/質問に関して): 私の具体的なケースでは、目標は(静的IPを持つ)任意の数のサーバーを互いに透過的に接続することです。しかし、「動的なIPを使用した」「ロードウォリアー」などの動的クライアントのごく一部も接続できる必要があります。ただし、主な目標は、信頼されていないネットワーク上で「透過的で安全なネットワーク」を実行することです。私はかなり初心者なので、「1:1ポイントツーポイント接続」を正しく解釈する方法がわかりません。
76 security  openvpn  vlan  ipsec 


3
/ sbin / nologinと/ bin / falseの違いは何ですか?
シェルをに設定して、ユーザーアカウントを無効にすることを推奨することをよく耳にし/bin/falseます。しかし、既存のLinuxシステムでは、多数の既存のアカウント(すべてサービスアカウント)が/sbin/nologin代わりにシェルを持っていることがわかります。 /sbin/nologinアカウントが無効になっているというメッセージをユーザーに出力して終了するマニュアルページから確認できます。おそらく/bin/false何も印刷しません。 また、それ/sbin/nologinはにリストされていますが/etc/shells、そうで/bin/falseはありません。 manページには、FTPがリストされていないシェルを持つユーザーのアクセスを無効にし、/etc/shells他のプログラムが同じことを行う可能性があることを示しています。それは、誰かが/sbin/nologinシェルとして持っているアカウントでFTPで接続できるということですか? ここの違いは何ですか?ユーザーアカウントを無効にするには、これらのうちどれを使用する必要がありますか?リストに/etc/shellsは他にどんな効果がありますか?
69 linux  security  login 

11
デフォルトのポート番号を変更すると、実際にセキュリティが向上しますか?
私は、プライベートアプリケーション(イントラネット、プライベートデータベース、部外者が使用しないものなど)には異なるポート番号を使用する必要があるというアドバイスを見てきました。 セキュリティを改善できると完全に確信しているわけではありません。 ポートスキャナーが存在する アプリケーションが脆弱である場合、ポート番号に関係なくそのまま残ります。 私は何かを見逃したか、自分の質問に答えましたか?

11
SSHパスワード認証がセキュリティリスクになるのはなぜですか?
OpenSSH構成のほとんどのガイドでは、キーベースの認証を優先してパスワード認証を無効にすることを推奨しています。しかし、私の意見では、パスワード認証には重要な利点があります。つまり、キーなしで絶対にどこからでも接続できるということです。常に強力なパスワードを使用する場合、これはセキュリティ上のリスクにはなりません。またはそれをすべきですか?

13
Linux:ルートのない生産的なシステム管理者(知的財産の保護)?
完全なrootアクセス権を付与せずに、ベテランのLinux syadminを生産的にする方法はありますか? この質問は、知的財産(IP)を保護するという観点から来ています。IPは、完全にコードおよび/または構成ファイル(つまり、簡単にコピーできる小さなデジタルファイル)です。私たちの秘密のソースは、私たちの小さなサイズが示唆するよりも私たちをより成功させました。同様に、私たちは、 IPを盗もうとした数人の元悪徳従業員(システム管理者ではない)から、一度は噛まれ、二度恥ずかしがります。トップマネジメントの立場は、基本的に「私たちは人々を信頼しますが、自己利益のために、絶対に仕事をするために必要な以上のアクセスを誰かに与えるリスクは許せません。 で、開発者の側、それは人々が生産することができるように、ワークフローやアクセスレベルを分割するだけで、彼らは見るために必要なもののみを表示することは比較的簡単です。最上の人々(実際の会社の所有者)だけが、すべての材料を組み合わせて特別なソースを作成する能力を持っています。 しかし、Linux管理者側でこのIPの機密性を維持する良い方法を思い付くことができませんでした。コードと機密テキストファイルにGPGを広範囲に使用しています...しかし、管理者が(たとえば)ユーザーにsu 'し、tmuxまたはGNU Screenセッションをホッピングして、彼らが何をしているのかを見ないようにするにはどうすればよいですか? (また、機密情報と接触する可能性のあるすべての場所でインターネットアクセスが無効になっています。しかし、完璧なものはなく、賢いシステム管理者やネットワーク管理者側のミスに穴が開いている可能性があります。もちろん他にも数多くの対策が講じられていますが、それらはこの質問の範囲を超えています。) 私が思い付くことができる最高のは、基本的にパーソナライズされたアカウントを使用しているにsudoに記載されているものと同様に、ルートとして動作する複数のLinuxシステム管理者。具体的には、会社の所有者以外には、実際には直接ルートアクセス権はありません。他の管理者は、パーソナライズされたアカウントを持ち、root にsudoする機能を持ちます。さらに、リモートロギングが開始され、ログは会社の所有者のみがアクセスできるサーバーに送信されます。ロギングがオフになると、何らかのアラートが発生します。 賢いシステム管理者は、おそらくこのスキームにいくつかの穴を見つけることができます。そして、それはさておき、それはまだ積極的ではなく反応的です。私たちのIPの問題は、競合他社が非常に迅速にIPを利用し、非常に短い順序で多くの損害を引き起こす可能性があることです。 そのため、管理者ができることを制限するメカニズムの方が良いでしょう。しかし、これは微妙なバランスであることを認識しています(特に、今すぐ解決する必要がある生産上の問題のトラブルシューティングと修正の観点から)。 非常に機密性の高いデータを持つ他の組織がこの問題をどのように管理しているのでしょうか?たとえば、軍のシステム管理者:機密情報を見ることなく、サーバーとデータをどのように管理しますか? 編集:最初の投稿で、私は表面化し始めている「雇用慣行」コメントに先手を打って対処するつもりでした。1つは、これは技術的な質問であると想定されており、雇用慣行はIMOが社会的な質問に向かっている傾向があります。しかし、2つ、私はこれを言います:私たちは人々を雇うために合理的であるすべてをしていると信じています:複数のインタビュー会社の人々; バックグラウンドおよび参照チェック。すべての従業員は、IPに関する詳細を記載したハンドブックを読んで理解したと言っているものを含め、多数の法的文書に署名しています。今、この質問/サイトの範囲外ですが、誰かが悪い俳優の100%を除外する「完璧な」雇用慣行を提案できるなら、私はすべて耳です。事実は次のとおりです。(1)完璧な採用プロセスがあるとは思わない。(2)人々は変わる-今日の天使は明日の悪魔になるかもしれない。(3)試行されたコード盗難は、この業界ではやや日常的なことのようです。
66 linux  security  root 

8
Debianサーバーを保護するためにどのような手順を取りますか?[閉まっている]
インターネットに直接接続されているDebianサーバーをインストールしています。可能な限り安全にしたいのは明らかです。あなたとあなたのアイデアを追加して、それを保護するためのアイデアとあなたがそれのために使用するプログラムをお願いします。 この質問の一部で、ファイアウォールとして何を使用していますか?手動で設定されたiptablesだけか、何らかのソフトウェアを使用して支援しますか?最善の方法は何ですか?すべてをブロックし、必要なものだけを許可しますか?このトピックの初心者向けの良いチュートリアルはありますか? SSHポートを変更しますか?ブルートフォース攻撃を防ぐためにFail2Banなどのソフトウェアを使用していますか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.