Ubuntuセキュリティアルファベット
Brian Kennedyによる「 サーバーでの最初の5分間 」は、ほとんどの攻撃からサーバーを迅速に保護するための優れた入門書です。 完全なガイドを補完するために、このマニュアルにはいくつかの修正があります。 また、若いエンジニアのためにいくつかのことを詳しく説明したいと思います。
毎朝、ログウォッチのメール通知を確認し、数百(場合によっては数千)のアクセス試行の失敗を徹底的に観察します。 (多くはかなり平凡です-1234のパスワードで何度も何度も
root
としてログインしようとしています)。 ここで紹介する一般的な方法論は、Debian / Ubuntuサーバーに適しています。 通常、Dockerコンテナのホストとしてのみ機能しますが、原則は同じです。
大規模な環境では、 AnsibleやShipyardなどのツールで完全自動インストールを使用することをお勧めしますが、単一のサーバーを上げるか、Ansibleのタスクを選択することもあります。このような状況では、指示が意図されています。
注:このヘルプは基本的なアルファベットとして作成されています。 必要に応じて拡張および補足する必要があります。
まずは
まだルートパスワードさえ持っていません。 ランダムで複雑なものを選択したいと思います。 最大複雑度設定でパスワードマネージャージェネレーターを使用します。 パスワードマネージャーはパスワードを保存して暗号化し、長いマスターパスワードでのみアクセスできるようにします。 ここでは、冗長なセキュリティ対策がいくつか提供されています(長くて複雑なランダムパスワード+暗号化と別の長いパスワードによるパスワード保護)。 パスワードマネージャーまたは他のツールを使用していますか。何らかの暗号化を使用してパスワードを安全に保ちます。 このrootパスワードは、sudoパスワードを紛失した場合にのみ必要です。
# passwd
*注:ルートパスワードに関する興味深い議論は、 HNとRedditで始まりました。 読む価値があります。
ここで、リポジトリを更新し、最新のパッチを適用する必要があります。 次は、セキュリティ更新プログラムのインストールの自動化に関する別のセクションになります。
apt-get update
apt-get upgrade
ユーザーを追加
ルートとしてサーバーにアクセスしないでください。 Brian Kennedyがインストールしたユーザーを作成するときも同じルールに従いますが、独自のルールを使用することもできます。 私たちの小さなチームでは、1人のユーザーを認証に使用することに問題はありませんでしたが、大規模なチームでは、特権レベルが異なるエリートのみがsudo特権を取得する別のユーザーを作成する方が適切です。
useradd deploy
mkdir /home/deploy
mkdir /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
deployユーザーの優先シェルをインストールします。bashを使用します。
usermod -s /bin/bash deploy
要確認:
chmod 700
は、アカウント所有者がプログラムの読み取り、書き込み、実行の権限を持っていることを意味します。 まだrootですが、
chown
にこのフォルダーで
chown
展開ユーザーと展開グループに対して再帰的に実行します。 このユーザーのみが.sshフォルダーを操作できるようにする必要があります。
SSHキー認証
サーバーへの入力にパスワードを使用しないようにします。 ブライアンの指示が出た後、これについて多くの論争がありましたが、私もその立場に同意する傾向があります。 このテーマに関するいくつかのコメントを次に示します。
- SSHキーは、より多くの情報を含んでいる必要があるため、パスワードよりも優れています。
- パスワードはブルートフォースにすることができます。 公開鍵で推測することは本質的に不可能であるため、完全に安全と見なすことができます。
- コンピューターの盗難はどうですか? はい、秘密鍵はありますが、ssh-keyの呼び出しは簡単で、authorized_keysから公開鍵を削除するだけです。 また、安全で長いパスフレーズで秘密鍵を保護する必要があります。 次の段落を参照してください。
- これはすべて、キーを保護する安全で長いパスワードフレーズの条件でのみ機能します。 繰り返しますが、これは非常に重要です。
それで、過去にパスワード認証を残しましょう。 id_rsa.pubの内容をコピーします 1ローカルマシンからauthorized_keysファイル内のサーバーへ。
vim /home/deploy/.ssh/authorized_keys
Linuxのセキュリティ原則( 最小特権の原則)に従って 、適切な特権を設定します。
chmod 400 /home/deploy/.ssh/authorized_keys
chown deploy:deploy /home/deploy -R
chmod 400
は、所有者のみがファイルを読み取れるように許可を設定します。 別の
chown
は、ユーザーにホームディレクトリの所有者を(再帰的に)展開させ、グループに展開させます。 このディレクトリの所有者に読み取り、書き込み、および実行のアクセス許可を設定するときに、これについて前に言及しました。
この後、ユーザーのdeployとsudoを正しくテストして、ルート認証を無効にし、sshキーのみを使用して認証を設定します。
展開ユーザーのテストとsudoのインストール
デプロイユーザーの認証がどのように発生するかを確認すると同時に、万が一のためにルートに対してssh接続を開いたままにします。 すべてが正常に機能する場合、オープンルート接続を使用してデプロイ用のパスワードを設定します。 パスワード認証を無効にしているため、sudoを適用するときにこのパスワードが使用されます。 再びパスワードマネージャーを実行して、複雑でランダムなパスワードを生成し、暗号化された形式で保存し、同僚に通知します(暗号化されたファイルとパスワードの同期)。
passwd deploy
sudoのインストールは簡単です。 sudoファイルを開きます。
visudo
以下に示すように、rootユーザーとしてグループ
%sudo
を追加します。 他のすべてのユーザーとグループが、
#
記号が付いたコメントで無効になっていることを確認します(ユーザーにはプレフィックスがなく、グループは
%
始まります)。 ほとんどの新規インストールでは、念のために何もありません。
root ALL=(ALL) ALL
%sudo ALL=(ALL:ALL) ALL
次に、
deploy
ユーザーを
sudo
グループに追加します。
usermod -a -G sudo deploy
これにより、先ほど作成したパスワードを入力した後、デプロイユーザーがsudoにアクセスできるようになります。
修正メモ:Redditのユーザーackackacksynに、ユーザーをsudoリストに直接追加しないように正しく注意してくれたことに感謝します 。
sshキーログインをアクティブにする
このマシンのssh設定は次の場所に保存されます。
vim /etc/ssh/sshd_config
そこに数行を追加する必要があります。 私には、彼らは自分自身でかなり明確であるように思えます。 これは、接続に使用するIPアドレスです。 当社では、OpenVPNと暗号化認証を備えたVPN構成を使用しているため、サーバーに接続するには、認証してVPNに接続する必要もあります。
PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy@(your-VPN-or-static-IP)
sshサービスを再起動して、これらのルールをすべてアクティブにします。 おそらく再接続する必要があります(これはdeployユーザーを介して行います!)。
service ssh restart
ファイアウォールのインストール
通常、2つのキャンプがあります。 IPtablesを直接使用するものもあれば、設定プロセスを簡素化するためにIPtablesの上のレイヤーである
ufw
と呼ばれる便利なインターフェースを使用するものもあります。 セキュリティの観点からは、通常、よりシンプルなオプションが望ましいです。 DigitalOceanのufwは本当に優れており、基本的なことを支援します。
ufw
Ubuntuにデフォルトでインストールされ、Debianでは
apt-get install ufw
実行するだけです。
デフォルトでは、
ufw
はすべての着信接続を拒否し、すべての発信接続を許可する必要がありますが、起動しません(そうでない場合、どのように接続しますか?)。 通常通りと見なされる接続を通過して、明示的に許可します。
まず、IPv6をサポートしていることを確認してください。 構成ファイルを開きます。
vim /etc/default/ufw
IPv6を
yes
設定し
yes
。
IPV6=yes
開く予定の残りのポートについては、コマンドラインから
ufw
ツールを使用できます。これは非常に便利です。
sudo ufw allow from {your-ip} to any port 22
sudo ufw allow 80
sudo ufw allow 443
sudo ufw disable
sudo ufw enable
1つは冗長な手段で、IPアドレスからの接続のみがSSH(標準SSHポート)を介して接続できるようにします 2 。 2番目と3番目のチームは、httpおよびhttpsトラフィックを開きます。
注:最初のルールを設定する場合(および実行する必要がある場合)、接続する静的IPアドレスまたはセキュアVPNがあることを確認してください。 動的IPアドレスを使用すると、将来サーバーにアクセスできなくなります。
自動セキュリティ更新
私はそれらが好きです。 完全ではありませんが、リリース後にパッチをスキップするよりも優れています。
apt-get install unattended-upgrades
vim /etc/apt/apt.conf.d/10periodic
このファイルを次のように更新します。
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::AutocleanInterval "7";
APT::Periodic::Unattended-Upgrade "1";
私は通常、定期的な更新を無効にし、セキュリティの更新のみを残す方が良いというブライアンに同意します。 アイデアは、依存関係のあるパッケージの更新のためにアプリケーションが突然動作を停止するとあまり良くないが、セキュリティの更新はアプリケーションレベルで依存関係の問題を作成することはほとんどないということです。
vim /etc/apt/apt.conf.d/50unattended-upgrades
次のようにファイルを編集します。
Unattended-Upgrade::Allowed-Origins {
"Ubuntu lucid-security";
//"Ubuntu lucid-updates";
};
すべて準備完了です。
Fail2ban
fail2banは、疑わしいアクティビティが検出されるとすぐにプロアクティブにブロックする優れたパッケージです。 彼らのウィキによると、fail2banはログファイル(
/var/log/apache/error_log
)をスキャンし、疑わしい兆候を示すIPアドレスを禁止しています-間違ったパスワードの入力、エクスプロイトの検索などが多すぎる... Fail2Banがインストールされた直後さまざまなサービス(apache、courier、sshなど)のフィルター。
apt-get install fail2ban
二要素認証
セキュリティ標準に準拠したシステムを設計する場合、2要素認証が必要です。 理論的には、他のすべての保護手段に加えて2要素認証をアクティブにした場合、サーバーへのアクセスを得るために(アプリケーションの脆弱性を開くことにより)、攻撃者は次のことも必要になります。
- 証明書とVPNアクセスキーへのアクセス。
- コンピューターにアクセスして秘密鍵を取得します。
- 秘密鍵のパスフレーズにアクセスします。
- 二要素認証のために電話にアクセスします。
これらは、克服しなければならない多くの障壁(4つ)です。 sudoを介してルートアクセスを取得した場合でも、AES暗号化(5番目のバリア)で保護されている展開パスワードを見つける必要があります。
パッケージをインストールします。
apt-get install libpam-google-authenticator
インストールするには、コマンドを実行し、指示に従ってください:
su deploy
google-authenticator
二要素認証は非常に簡単にインストールでき、セキュリティの追加レイヤーが追加されます。
ログウォッチ
このツールは、事後の喜びと監視に適しています。 ログウォッチはログを追跡し、設定に従って、毎日、美しく構造化された要約をメールで送信します。 これは非常に面白いデータであり、サーバーへのアクセス試行が毎日何回発生するかに驚くでしょう。 セキュリティを確保することがいかに重要かを同僚に示すためだけにインストールしました。
DigitalOceanにはLogwatch のインストールと設定に関する優れた説明がありますが、 10分の期限に間に合わせたい場合は、インストールしてcronタスクを実行し、毎日起動して電子メールを送信します。
apt-get install logwatch
cronジョブを追加します。
vim /etc/cron.daily/00logwatch
cronファイルに次の行を追加します。
/usr/sbin/logwatch --output mail --mailto you@example.com --detail high
すべて準備完了
よくここに。 上記のすべてを完了した後、主な懸念事項および障害点はアプリケーションとサービスになります。 これは完全に異なる領域です。
私たちは、ベストプラクティスとプロセスを可能な限り形式化して説明しようとします 。詳しく知りたい場合は、 リポジトリを調べてください。 すべてがパブリックドメインにあり、私たちはそれを補充し続けます。
1 `.pub`が指定されていることを確認してください。 とても簡単に思えますが、私が尋ねたとき、秘密鍵( `id_rsa`を拡張子なしで)を送ってきた彼らのキャリアの間に、私は2人の仲間に会いました(両方とも*私たちの会社で働いていません-彼らはすぐにここで働いていません)公開鍵を送信します。 記事に戻る
2 SSH接続に標準ポートと非標準ポートのどちらを割り当てるかについての意見は異なります。 こことここの両側の議論を見てください。 記事に戻る