web-dev-qa-db-ja.com

Dockerコンテナーのネットワークアクセスの制限

私はSFTPのみ Docker コンテナを作成中です。コンテナは、独自のchrooted環境でファイルをアップロードおよび管理する目的でのみ複数の人が使用します。

紙の上では、これはかなり安全です。bashログインのすべての形式を無効にし、その中で他のプロセスを実行しません。ただし、もう少しだけ強化したいと思います。

このコンテナがSFTPサーバーであるという目的を除いて、内部からインターネットにアクセスできないようにしたいと思います。

明確にするために：外部からのコンテナーへのアクセスを防ぐ方法を知っています。受信iptablesルールを設定でき、docker runコマンドでSFTPポートのみを公開できます。

しかし、私は次のコマンドを（例として）実行したときに、コンテナをinside実行すると失敗します。

curl google.com

私の意図は、ハッキングされたコンテナがもたらすダメージの量を減らすことです（スパムメールの送信などには使用できません）。

sshsecuritysftpdocker
14
Daniel S

攻撃を防ぐために、Dockerインスタンス内にいくつかの上りルールを配置することは依然として理にかなっていますが、Dockerイメージが接続する上流のルーターからの送信（インターネット）アクセスを制限する必要があります。これは、インスタンス内のファイアウォールルールで送信アクセスをブロックしようとすると、インスタンスが侵害された場合、それらのルールが攻撃者によって削除される可能性があるためです。インスタンスのルーターを介して下りをブロックすることで、侵害が発生した場合でも送信アクセスをブロックします。攻撃者はルーターも侵害する必要があります。

わかりましたので、フィルタリングがコンテナのホストを対象としたものであると説明するコメントを受け取った後、達成しようとしていることが少し明確になりました。その場合、ホストで、次のようなルールを追加します。

iptables -A FORWARD -s lo.cal.sub.net -d con.tai.ner.ip -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -d lo.cal.sub.net -j ACCEPT
iptables -A FORWARD -s ! lo.cal.sub.net -d con.tai.ner.ip -p tcp --dport sftp -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -d ! lo.cal.sub.net -p tcp --sport sftp -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -m state --state related,established -j ACCEPT
iptables -A FORWARD -s con.tai.ner.ip -j DROP

最初の2つのルールは、ホストとコンテナ間のアクセスに関するものです。 3つ目のルールは、（おおまかに）SFTPに向かうホストのサブネットではないものは問題ないことを示しています。 4番目は基本的に3番目のツインであるアウトバウンドルールです。 5番目のルールはキャッチオールです（使用されている他の関連ポートがある場合）。これは必要ではありませんが、おそらく削除できます。最後のルールは、ホストサブネット以外へのアクセスを防止する魔法です。アクセスは最初のいくつかのルールで与えられるため、前述のルールがいずれも適用されない限りトリガーされません。その場合、「必要なものは気にしない、承認されたものと一致しませんでした。だからここからそこに行くことはできない」外部からの受信トラフィックは、3番目と4番目のルールによって満たされます。

4
Avery Payne

これは実際にはDocker固有の問題ではありません。これを解決する方法はいくつかあります。

  1. ステートフルiptablesルールを使用して、受信および関連/確立されたトラフィックの接続を許可し、それ以外のすべてをブロックします。

  2. シェルを実行できない ProFTPD などのsftpのみのサービスを使用します。

一般に、ユーザーがシェルを取得することを許可せず、コンテナー内からプログラムを実行することも許可しない場合、それについて心配する必要はありません。

1
Randall Smith

これは簡単なブレインストーミングであり、まだテストしていません。実稼働に移す前に、ラボで確認する必要があります。

非SSH（SFTP）およびWebポートでの送信トラフィックを防ぐために、IPTABLESまたは別のLayer4ファイアウォールを介してポリシーを適用し、宛先が指定されている場合を除いて、0.0.0.0/0を宛先とするdockerコンテナーが使用するセグメントから送信されるトラフィックをDROPまたはREJECTすることができます。ポートはTCP22です。

ウェブへの未承認の場所の問題を解決するために、インターフェイスdocker0でリッスンし、使用しているSquidやBluecoatなどのフィルタリング/キャッシングプロキシのインスタンスを設定することをお勧めします。インターネットに出るためのホストのデフォルトルート。そこから、多くの基準に基づいてポリシーを適用できるだけでなく、静的コンテンツをキャッシュすることでネットワーク使用率を節約できます。ホストマシンでNAT（LinuxでIPTABLESとマスカレードがこれを提供していると思います）を使用して、プロキシの使用を透過的に強制することができます（これについては I HTTPのみをプロキシしたいが、HTTPSトラフィックの処理方法がわからない ）これは、企業のポリシーに準拠している最初の場所からWebにアクセスする理由があることを意味します。

（SFTPのベースとなっている）SSHの性質上、コンテナがユーザーから提供されたキーペアのみを使用するというポリシーを実装しない限り、ファイル移動のトラフィックを禁止することはできません。これはあなたにとって良いことです。なぜなら、顧客の1人が違法なものを転送した場合、「転送されたファイルを表示または制御できなかった」という防御が得られるためです（たとえば、IP侵害、またはサービスを使用して分類ラベルが付いた情報を引き出したり、CPで取引したりする場合）、顧客がしたことで法廷に連れて行かれた場合（電話会社の通信事業者のステータスに類似していると考えてください）。これは、頻繁に再転送され、変更されていないファイルをキャッシュできないため、また顧客との契約に書き込むポリシーは、技術的な手段によって本質的に強制できないため、あなたにとっては悪いことです。

0
DTK