私は最近、比較的小規模な会社で新しい職に就き、私たちの会社ではLinux / UNIX側（そしてwindows server / ADなどですが、それは重要ではありません）で主導的立場をとりました絶対にすべてのICT関連）。彼はまだ私たちと一緒にいて、私と同じようなことをしていますが、今や彼はおそらくネットワーク側にもっと集中することを許されています。少なくとも経験に関しては、私の上司。私はLinux / UNIX / Windows /（一般的なシステムとアプリケーション）の側（そして彼が離れている間はいつでもネットワーク）に対して最大の責任を持ちます。
何年も前に入社する前、彼は私たちの会社のためにDebianメールサーバー（そして他のいくつかの内部/ DMZノード）をセットアップしましたが、時間の制約のために（私たちの上司のせいで、私が同僚に公平になるために、彼がこれらのサーバーをセットアップするのに非常に良い仕事をしたと思う時に彼が利用可能な時間と知識を与えました）何年も経ち、結局私はこれらのノードのリードを引き継いで、私が今責任を継承したシステムで予備的な侵入テストをすることにしました。私はbash ShellShockをリモートで悪用し、2、3の既知の問題の概念実証のエクスプロイトをほんのわずかの時間内に、実際には数十分で証明することができました。
これらのサーバーの中で最も重要なものは私たちのメインのメールサーバーで、他のほとんどのものはDebian Linuxの非常に古い（私が思うところバージョン3）であり、もはやサポートもアクティブリポジトリもありません。ほとんどの意図と目的のために安全であると考えられるが、FreeBSD上で並行して実行されている二次システムは、完全に置き換えることができなかった）。
私の質問はDebianはしばらくの間これらのシステム用のパッチをリリースしたり置き換えたりしていないため、ここ数カ月/年の間に大きなセキュリティホールが見つかったbashやopensslなどのパッケージをソースから構築する必要があります。その間の一時的な修正を行わないには、まったく時間がかかりすぎます。最適な場所は次のとおりです。
- 過去数年間にどのパッケージが重大なセキュリティホールを持っていたかを見つけてください。
- それらを構築するためのソースコードを入手してください。
- 依存関係の問題を回避するためにそれらをどのように構築するか（問題となっているノードにコンパイラがないため、おそらく組み込みの依存関係で静的に他のシステムからクロスコンパイルする必要があります）、
- それが予想通りに動作すること、そして少なくともほとんどの侵入者以外に開放されていないことを確認するためにその後すべてを適切にテストする方法（私は自分自身でテストすることができる
私はほとんど私自身がGentooとFreeBSDのユーザなので、Debianの知識を正確に把握していませんでしたが、プログラミング経験が豊富な経験豊富なLinux / UNIXユーザですが、絶対にしないでください。私たちのメインのメールサーバーといくつかの私たちの内部使用サーバーを潜在的に煉瓦する前に何かを見落としてはいけません。