ポート22アウトバウンドをブロックする理由

私はプログラマーであり、ネットワークがポート22での発信接続をブロックするいくつかのクライアントで働いてきました。せいぜい、プログラマーに会社に3Gインターネットの料金を請求することを強制します。最悪の場合、彼らは仕事を効率的に行えないことを意味します。

これがもたらす困難を考えると、経験豊富なシステム管理者は、負け負けアクションのように思われるものに望ましい利点を説明できますか？

SSHポートフォワーディングの特定のリスクを詳細に説明した人はいないようです。

ファイアウォールの内側にいて、パブリックインターネット上のマシンへのアウトバウンドSSHアクセスがある場合、そのパブリックシステムにSSHで接続し、そのプロセスでトンネルを作成して、パブリックインターネット上の人々がネットワーク内のシステムに完全にsshできるようにしますファイアウォールをバイパスします。

fredがデスクトップであり、barneyが会社の重要なサーバーであり、wilmaが（fredで）実行されている場合：

ssh -R *：9000：barney：22 wilma

ログインすると、攻撃者はwilmaのポート9000にsshし、barneyのSSHデーモンと通信できます。

ファイアウォールは、データが発信方向で最初に確立された接続を介して渡されるため、着信接続として認識しません。

迷惑ですが、完全に正当なネットワークセキュリティポリシーです。

彼らがポートのミッシュマッシュをブロックし、いくつかのものを通過させ、ランダムに他のものをブロックしている場合（ポール・トムブリンのSSHをブロックしてTelnetを許可した人々の悲しい物語が大好きです）ネットワークの境界をセキュリティで保護するか、少なくとも外部からのセキュリティポリシーが考え抜かれているようです。あなたはそのような状況を理解することはできませんので、痛みを抱えて一日を続けていく人々のために継続料金を請求してください。

そのポート経由のトラフィックを許可するための特定のビジネスケースがない限り、すべてのポートをブロックしている場合、その時点で慎重に管理されているので、彼らは仕事で有能であるため、それを行っています。

安全なアプリケーションを作成しようとしているとき、他のプロセスが情報を好きなように読み書きできるようにしますか、または人々が呼び出すことを期待し、注意深くサニタイズする慎重に文書化されたAPIがいくつかありますか？

リスク管理-インターネットに出入りするネットワークとの間のトラフィックがリスクであると感じた場合、ルートの数と方法の数の両方の観点から、トラフィックがインターネットに到達する方法の量を最小限に抑えることを検討します。次に、これらの選択された「祝福された」ゲートウェイとポートを監視およびフィルタリングして、それらを通過するトラフィックが予想どおりであることを確認します。

これは「デフォルトの拒否」ファイアウォールポリシーであり、通常は良いアイデアと見なされますが、いくつか注意点があります。つまり、ブロックを解除する特定の理由がない限り、すべてがブロックされ、その理由の利点がリスクを上回ります。

編集：私は明確にする必要があります、私は1つのプロトコルが許可され、別のプロトコルがブロックされるリスクについて話しているだけでなく、制御されていないネットワークでネットワークに出入りする情報のビジネスに対する潜在的なリスクについて話している仕方。

次に、警告と、場合によっては解放する計画について説明します。

あなたが何かからブロックされているとき、それはあなたが迷惑になることがあります。多くの場合、ファイアウォールの担当者は、「ここにリスクがあり、今は何が利益なのか」ではなく、「いいえ」と言って仕事をしていると考えています。

クライアントのネットワークセキュリティを管理している人と話をする場合、彼らはあなたのために何かを設定することができます。アクセスが必要な特定のシステムを特定できる場合、および/または特定のIPアドレスからのみ接続することを保証する場合、それらの特定の条件のSSH接続のファイアウォール例外を作成する方がはるかに便利ですインターネット全体への接続を開くだけです。または、ファイアウォールを通過するために使用できるVPN機能を持っている場合があります。

ニューヨークのロチェスターにある特定の大企業は、かつて多くの映画を制作していたため、そこで働いていたときに発信sshをブロックしていましたが、telnetを許可していました！私がそれについて尋ねると、彼らはsshがセキュリティホールだと言った。

言い換えれば、企業は時々愚かな決定を下し、それから自分の過ちを認めるのではなく、セキュリティに関する卑劣な言い訳をする。

会社が外部ログインを許可していない場合、インバウンドSSH通信のブロックを理解できます。しかし、これは私がアウトバウンドSSHブロックを聞いたのは初めてです。

注意すべき重要なことは、このようなファイアウォールはおそらくカジュアルなSSHユーザーのみを制限するということです。誰かが本当に外部（企業ネットワークの外部にアクセスする重要なサーバー/マシンへ）にSSHをしたい場合、22以外のポート（ポート80など）でSSHサーバーを簡単に実行できます。ブロックは簡単にバイパスされます。

HTTP（ポート80またはHTTPSポート443）を介して企業を終了し、プロキシを提供して外部のポート22に接続できるようにするパブリックドメインツールもいくつかあります。

編集：OK、ちょっと待ってください、なぜこれがポリシーになるのか考えがあります。

時々、SSHトンネルを使用して、IMやBittorrentなどのプロトコルの基本的な送信ファイアウォールをバイパスします（たとえば）。この// might //はそのようなポリシーをトリガーしました。ただし、これらのトンネルツールのほとんどは22以外のポートで動作できると感じています。

このようなアウトバウンドトンネルをブロックできる唯一の方法は、SSH通信をその場で検出し、これらのTCP接続を（動的に）ブロックすることです。

これはおそらく規制/コンプライアンスの問題です。雇用主は、すべての通信を読み取り/アーカイブできるようにしたいと考えています。これは、銀行などの業界では非常に頻繁に要件になります。

私の意見では、アウトバウンドポート22をブロックする主な理由は2つあります。

まず、人々が言及したように、SSHポート転送はプロキシとして使用したり、他のポートやサービスを迂回して、そのようなトラフィックが許可されていないことを示すITポリシーを回避できます。

第二に、多くのマルウェア/ボットネットはポート22を使用します。これは、多くの場合「セキュア」であると見なされ、許可されているためです。その後、そのポートからプロセスを起動できます。また、感染したコンピューターはSSHブルートフォース攻撃も起動する可能性があります。

多くの場合、必要な場合を除き、すべての発信接続をブロックし、発信接続にポート22を使用できるように要求する人がいなくなるまで（80、433など）をブロックします。この場合、ソリューションはIS / ITに連絡し、例外を追加する必要がある理由を伝えるだけで、ステーションが特定のホストまたは一般に発信SSH接続を確立できるようにすることができます。

場合によっては、他の制御を回避するために（リンクを介したポート転送を介して）プロキシをセットアップする方法としてSSHを使用するために、この機能を使用することが懸念されます。これは、法的な理由（インサイダー取引の監視、企業データや個人データの転送の検出/ブロックなど）のためにすべての通信を監視/記録する必要がある一部の規制産業（銀行など）や、は、内部漏えいが偶然またはその他の理由で企業秘密を漏らしてしまうことに対する大きな恐怖です。これらの場合、3Gリンク（またはHTTPを介してSSHをトンネリングするなどの他の手法）を使用して制限を回避することは、契約違反であり、したがって解任犯罪（または、おそらく最悪の場合、法的犯罪）になる可能性がありますあなたがそれを試みる前にあなたの行動に同意してもらう

別の理由は、企業のマシンにインストールするのが面倒な場合に、発信フットプリントを削減することです（会社のファイアウォール内のホストおよび一般にアクセス可能な内部サービス）。ポート22でSSH接続が不可能な場合、伝播ルートの1つがブロックされるため、ブルートフォースSSHログインを使用しようとする多くの単純なハッキングが行われます。この場合、ファイアウォールを制御する人々に正当な理由があれば、マシンがSSH接続を確立できるように、例外の追加を再度要求できるようになります。

クライアントは、おそらく保持したい重要なデータを所有しています。アウトバウンドSSHは、ネットワーク全体に対してオープンにするのは本当に悪いことです。プロキシをバイパスし、機密データを漏洩し、一般的に不快なことは非常に簡単です。

IMO、ネットワーク/インターネット境界を通過するものはすべて理解され、制御可能である必要があります。開発者のグループがsshを介してホスティングプロバイダーのサーバーにアクセスする必要がある場合は問題ありませんが、文書化する必要もあります。一般に、私が働いた場所では、ネットワークの外部の場所への専用のサイト間VPN接続を確立し（本質的に内部ネットワークを拡張します）、インターネット経由のSSHなどのクライアントプロトコルを回避します。

SSHはVPNとして使用できるためです。暗号化されているため、ネットワーク管理者は文字通りネットワークから何が出るのかわかりません（顧客データベースのダンプなど）。毎月のコラム「秘密のトンネル」でこのことを取り上げました。一部の3Gインターネットのコストは、暗号化されたプロトコルがネットワークからデータを送信することを心配するよりもはるかに少ないです。さらに、発信ポート22をデフォルトでブロックし、トラフィックを検査すると、非標準ポートでSSHを簡単に見つけることができ、セキュリティポリシーに違反している人を見つけることができます。

SSHの機能を悪用して、SSHを介してSOCKSプロキシをインストールすることで、サイトの制限を回避する人がいることを知っています。

または、いくつかの単純なポート転送（ssh -L ....）でさえ、サイトの制限のために実際にポートがブロックされている場合、

• ローカル管理者と
• あなたのプロジェクトマネージャー

彼らをテーブルに連れて行き、これがブロックされている理由について詳しく説明させてください。もちろん、内部製品を開発するために外部SSHポートへのアクセスが必要な正当な理由が必要です（内部存在：snakeoil.invalid会社で働いているときにboxA.example.comへのアクセスが必要な理由）

しかし、発信SSHをブロックしている会社はまだ見ていません。

明らかな答えはすべて述べられています。これは暗号化されたプロトコルで、トンネルの作成（これは企業のWebフィルターを通過するのに最適な方法です）だけでなく、不正な通信チャネル（リバースプロキシ）による脅威を回避するために使用できます。

確かに、最新のネットワークではtelnetを破壊する必要があります。しかし、sshを禁止しながら、ネットワークからのtelnetの許可を確認できます。Telnetはsshよりも能力が低く、スニファーを介してストリームを常にリアルタイムで監視できます。コアネットワークにtelnetデバイスがなく、一部のユーザーがtelnetを使用したい場合、どうすればいいですか。私はそれを見ることができ、それが脅威ではないことを確認します。

もちろん、これはすべて、デフォルトのポリシーではすべての出力をブロックし、特定のプロトコルのみを許可するという考え方に依存しています。あなたがエッジをヒットする前にそれらをプロキシしている場合のボーナスポイント。

管理者はSSHに対して何かを持っているため、ポート22を特にブロックすることはありません。さらに、開く必要があるとわかっているポートのみを開く場合もあります。管理者がSSHを開く必要があると言われていない場合、管理者はサーバー上の未使用のサービスを無効にするのと同じ原理で、SSHをブロックします。

明らかに、アウトバウンドTCP / 22ブロックは、ネットワーク管理者が特定の SSHトラフィックをブロックするために真剣かつ真剣な努力を払わない限り、簡単に回避できます。さらに、資産管理者は、3Gモデムと2番目のNICの疑わしいIPアドレスをキャッチするのに十分な資産インベントリを実行するのに十分な能力を備えている必要があります。弊社の地域にはClearWireサービスがあるため、ネットワークセキュリティに関するエンドランオプションとしてWiMaxもあります。

私たちは、主に情報漏えいに関心のある機関ではありません。しかし、そうであれば、厳格なネットワークセキュリティポリシーと厳格な資産ポリシー、および監査を組み合わせる必要があります。私の知る限りでは、ある種の外部ネットワーク接続でインベントリを行う資産のネットワークジャックをオフにする既製のセキュリティパッケージは存在しないと思います。それは来るかもしれません。

このようなパッケージがない場合、資産インベントリプロセスは、3GやWiMaxなどのエンドランネットワーク接続をキャッチするための最良の方法の1つです。

そして最後に、TCP / 22のブラインドブロックは、作業ネットワークのAUPに違反しようとするエンドユーザーの最も少ないワイリーのみをブロックします。

22人がHTTPトラフィックを22経由で転送していることを発見したときに、22がブロックされているのを確認しました。

大規模な組織のほとんどはすべてをブロックし、プロキシサーバー経由のHTTP / HTTPSアクセスのみを許可します。

特定のニーズがない限り、デスクトップやサーバーからの直接外部接続を許可している企業を聞いて、私は非常に驚いています。

ポート80でのリモートsshdの実行を妨げるものはありません。sshとsshdの両方に、ポートを設定するための-pオプションがあります。

もちろん、管理者が賢明であれば、ポート22のトラフィックだけでなく、sshのトラフィックも監視する必要があります。テクノロジーの問題ではなく、ポリシーの問題があるようです。

しかし、他の人が指摘したように、暗号化されたプロトコルは、さまざまなコンプライアンスの問題を心配しなければならない人々に胸焼けを引き起こす可能性があります。