web-dev-qa-db-ja.com

Debianサーバーを保護するためにどのような手順を踏んでいますか?

インターネットに直接接続されているDebianサーバーをインストールしています。もちろん、できる限り安全にしたいと思っています。私はあなたたちにあなたのアイデアを追加して、それを安全にするためにあなたがそれをどのように使用するかを追加して欲しいです。

この質問の一部で、ファイアウォールとして何を使用していますか?ただ iptables 手動で設定するか、何らかのソフトウェアを使用して支援しますか?最良の方法は何ですか?すべてをブロックし、必要なものだけを許可しますか?このトピックの初心者向けの良いチュートリアルはありますか?

SSHポートを変更しますか?ブルートフォース攻撃を防ぐために Fail2Ban のようなソフトウェアを使用していますか?

66
Thomaschaaf

義務的:

  • エキスパートモードでのシステムのインストール、必要なパッケージのみ
  • iptablesの入力にデフォルトのポリシーが設定された手書きのファイアウォール:ドロップ、SSH、HTTPまたは他のサーバーが実行しているものへのアクセスを許可
  • Fail2Ban SSHの場合[場合によってはFTP/HTTP /その他-コンテキストによって異なります]
  • rootログインを無効にし、通常のユーザーとSudoを強制的に使用する
  • カスタムカーネル[ただ古い習慣]
  • スケジュールされたシステムのアップグレード

さらに、妄想のレベルに応じて:

  • いくつかの許可された宛先/ポートを除く出力のポリシーをドロップ
  • integritファイルシステムウェアの一部が変更されていないかどうかをチェックします(チェックサムがマシンの外部に保持されている場合)。例 Tripwire
  • 少なくとも外部からのシステムのnmapによる定期スキャン
  • 未知のパターンの自動ログチェック[ほとんどの場合、ハードウェアの誤動作やいくつかの小さなクラッシュを検出するため]
  • chkrootkit の実行予定
  • /etc/passwdの不変属性なので、新しいユーザーの追加は少し難しい
  • / tmpはnoexecでマウントされています
  • ポートノッカーまたはSSHポートを開く他の非標準的な方法[例えばWebサーバーの「シークレット」Webページにアクセスすると、ページを表示したIPアドレスから一定期間、SSH接続を受信できます。接続すると、-m state --satete ESTABLISHEDは単一のSSHセッションを使用している限りパケットフローを許可します]

私が自分でやらないことには意味があります。

  • grsecurity カーネル用
  • リモートSyslogにより、システムが危険にさらされたときにログを上書きできません
  • sSHログインに関する警告
  • 設定 rkhunter し、時々実行するように設定します
50
pQd

マシンのファイアウォールに関する注意事項...

  • ブラックリストではなく、ホワイトリストを使用します。つまり、すべてをブロックし、必要なものだけを許可し、それ以外はすべて拒否します。
  • ファイアウォールを作成するタスクを実行しようとするGUI/ncursesまたはその他のソフトウェアを使用しないでください。そうすれば、ソフトウェアがあなたに代わって仮定を立てることができます-そのリスクを取る必要はありませんし、そうすべきではありません。自分で設定してください。不明な場合は無効にしてください。必要な場合はすぐにわかります。それがすでに稼働中のシステムであり、(誤ってブロックすることによって)トラフィックを中断できない場合は、tcpdump(ファイルにダンプ)を実行してサンプルを取得します-後で調べて、有効なものと無効なものを見つけます。
  • 私は個人的には非標準ポートでサービスを実行することに意味がありません。ツールは最近、たとえば何かがポート22で実行されているので、それがsshでなければならず、それ以外の場合はそうではないことを前提としています。例amap、およびnmap 's -Aオプション。そうは言っても、サービスを変更して、のぞき見から身を隠すことができます。たとえば、次のようにすると、実行しているOpenSSHの正確なバージョンを攻撃者に知らせることができます。次に、その正確なバージョンのエクスプロイトを探すことができます。そのようなものを隠すと、あなたはそれらをより難しくするでしょう。
 [root @ ud-olis-1 uhtbin]#telnet localhost 22 
 Trying 127.0.0.1 ... 
 connected to localhost.localdomain(127.0.0.1)
エスケープ文字は '^]'です。
 SSH-2.0-OpenSSH_3.9p1 
  • すべての公共サービスを最新の状態に保ち、最新のセキュリティパッチを適用します。
  • ゲートウェイサーバー自体にDATAを保存しないでください。少なくとも、サーバーがこのマシンに侵入したときに時間を稼ぐことができます。サービスが1つか2つ失われますが、データは失われます。

結論としては、100%安全なものを作成することに成功することは決してありません-それは不可能です-したがって、目的はできるだけ安全にすることです-システムを破壊するのにあまりにも多くの努力が必要な場合、それは十分であり、ほとんどのスクリプトキディは次のシステムに移ります。

  • iptablesは、どのLinuxシステムでも使用できる方法ですが、自分で設定してください。

オープンスタンダードに基づいていない「セキュリティソフトウェア」を決して使用しないでください。これらのソフトウェアは、正しく記述されていないことが運命づけられており、ハッキングされます(「if」ではなく「いつ」という問題ではありません)。オープンソースとオープンプロトコルは公の監視を受け、成熟した信頼できる製品になることに集中しています。クローズドソースソフトウェアは、作成者の製品の信頼性に大きく依存していますthey考えてみてください。つまり、少数の目と地球に満ちた目です。

それが役に立てば幸い:)

18
Xerxes
  • rootログインを無効にする
  • パスワードによるログインを無効にする(公開鍵によるログインのみを許可)
  • sSHポートを変更する
  • denyhosts(または類似の)を使用する

  • 独自のiptblesスクリプトを記述します(許可するものを正確に制御し、他のすべてを削除できます)

  • sSL/TLSで保護された通信の使用を強制し、有効で、有効期限が切れておらず、署名された証明書があることを確認します

  • すべての外部サービスに対して厳密な証明書検証をオンにします(たとえば、別のマシン上のLDAPサーバーでユーザーを認証する場合)
12
x-way
9
KPWINC

一般的な出発点として、私は Center for Internet Security のベンチマーク/ガイドに従います。これは、セキュリティのベストプラクティスを包括的にまとめたものです。 Debianベンチマークがしばらく更新されたようではありませんが、手順の一般的な概要は次のとおりです。

  • 最新のOSパッチ/パッケージを適用する
  • システム/カーネル/プロセスのアカウンティングを有効にします。
  • MACを有効にします(SELinuxやAppArmorなど)。
  • ホストベースのファイアウォール(iptables)を有効にします。
  • 確認APT sources.list(キーは正しく、ソースは信頼されています)。
  • ネットワークサービスを最小化し、不要なものをすべて無効にし、ファイアウォールを無効にします。
  • TCPWrappersを使用して、システムアクセスをさらに制限します。
  • 暗号化されたネットワークプロトコルのみを使用し、暗号化されていないサービス(telnet、ftpなど)を無効にします。
  • SSHへのリモートアクセスのみを構成します。
  • ユーザーのログインパスワードを無効にし、キーベースの認証を要求します。
  • ファイルシステム共有(NFS、SMB)を無効にします。
  • リモート/集中型システムログを有効にします(定期的にログを確認します!)。
  • BIOS /ファームウェアレベルのパスワードを設定します。
  • ブートローダーのパスワードを設定します。
  • システムバックアップを構成し、障害復旧計画を立て、バックアップが有効であり、担当者が障害復旧手順を知っていることをテストします。

CISecurityベンチマークのシステムに実装する特定のコマンドや構成ファイルなど、これらのさまざまな設定に関する多くのリソースがあります。

6
jtimberman

マシンをインターネットに直接接続しないことをお勧めします。マシンとインターネットの間に何らかのファイアウォールを設置します。これにより、サーバーに負荷をかけずにセキュリティとネットワークの監視を行うことができます。個人的には、ネットワークと機能のセグメンテーションによりネットワークのトラブルシューティングが単純化されることが多いと思いますが、場合によっては複雑さが増すため、分析がさらに困難になります。

最も安全であるが管理が最も面倒なファイアウォールポリシーは、すべてを拒否し、許可する必要があるトラフィックのみを明示的に許可することです。ネットワークの変更が必要になると、ファイアウォールポリシーを頻繁に更新する必要があるため、これは厄介です。

また、サーバーで何らかの種類のインターフェースファイアウォールを使用することをお勧めします-多層防御が重要です。管理関連のサービスに非標準のポートを使用しても問題はありません。 fail2banは問題ありません。 Serverfaultのセキュリティアプリケーションに関するより具体的な質問を追求して、より多くのアイデアを見つけてください。

セキュリティは、2人のハイカーとクマについての冗談のようなものです。完璧なセキュリティを達成することは決してできませんが、他の人よりも難しいターゲットになることは役立ちます。

5
pcapademic

Securing Debian Manual を指摘する人もいます。これは、軍事的要件以外のすべてに完全に適しています。

多くの人々は、途方もなく妄想的であることがクールであるか、プロであるか何かであると思います。それはではなく、他の管理者にとっては迷惑であり、完全にはrepressiveですユーザー。本当のセキュリティ違反はシステムが十分に更新されていないか、内部ソースから発生したものである可能性が高いため、パラノイアな管理者にとって便利だと感じるのは、偽の忙しい仕事ですが、実際には役に立ちません。

そうは言っても、ローカルネットワーク上の何もインターネットからの何よりも信頼しないことが私の信条の1つだと私は考えています。したがって、ローカルネットワークでも認証を要求するようにすべてを構成します。 IPsecを使用して、コンピューターのすべての間のすべてのトラフィックを暗号化および認証します。

現在、すべてのサーバーでフルディスク暗号化に変換しています。

使用しているサービスのみをインストールします。ファイアウォールはありません。私は認証を要求する必要があるサービスを構成するか、それらを(プログラム自体の構成またはTCPラッパーによって)特定のIPに制限します。 iptablesを使用してブロックする必要があるのは、memcachedだけでした。これは、構成ファイルがなく、TCPラッパーを使用していなかったためです。

私は自分のアカウントに適切なランダムに生成されたパスワードを使用し、SSHサーバー(および他のすべてのサービス)を信頼して、パスワードを知らない人に知られないようにしています。 fail2banは、ログファイルIMOのスペースが限られている場合にのみ使用できます。 (それらを信頼できるようにするには、十分なパスワードが必要です。)

4
Teddy

Www.debian.org/doc/manuals/securing-debian-howto/でこの素敵なハウツーを体験してください

私は個人的にsshポートを変更し、fail2ban + denyhostsを使用しています。そして、不要なものはすべてブロックします。ブロックするほど、心配する必要が少なくなります。

3
Vihang D