ポート22アウトバウンドをブロックする理由
私はプログラマーであり、ネットワークがポート22での発信接続をブロックするいくつかのクライアントのために働いています。プログラマーがsshにポート22を使用する必要があることを考えると、これは逆効果的な手順のようです。せいぜい、それはプログラマーに会社に3Gインターネットの代金を請求することを強制します。最悪の場合、彼らは彼らの仕事を効果的に行うことができないことを意味します。
これがもたらす困難を考えると、経験豊富なシステム管理者は、負け負けのアクションのように見えるものに望ましい利益を説明できますか？
SSHポートフォワーディングに関する特定のリスクを詳細に説明した人はいないようです。
ファイアウォールの内側にいて、公衆インターネット上のマシンへのアウトバウンドSSHアクセスがある場合、その公衆システムにSSHで接続し、その過程でトンネルを作成して、公衆インターネット上の人々がネットワーク内のシステムに完全にsshできるようにします。ファイアウォールをバイパスします。
Fredがあなたのデスクトップであり、barneyがあなたの会社の重要なサーバーであり、wilmaが（fredで）公開されている場合：
ssh -R *：9000：barney：22ウィルマ
ログインすると、攻撃者はsshでwilmaのポート9000にアクセスし、barneyのSSHデーモンと通信できます。
データが送信方向で最初に確立された接続を通過しているため、ファイアウォールはそれを受信接続として認識しません。
面倒ですが、完全に正当なネットワークセキュリティポリシーです。
彼らがポートの寄せ集めをブロックしていて、いくつかのものを通過させ、他のものをランダムにブロックしている場合（私は、SSHをブロックしてTelnetを許可した人々のポールトンブリンの悲しい物語が好きです）、彼らは、その方法について非常に奇妙なEdgeケースを持っている彼らのネットワーク境界を保護することに取り掛かるか、彼らのセキュリティポリシーは、少なくとも外部からは、どうやらよく考えられていないようです。あなたはそのような状況を理解することができないので、痛みを抱えてあなたの一日を続けている人のために彼らに継続料金を請求してください。
彼らがすべてのポートをブロックしている場合そのポートを通過するトラフィックを許可する特定のビジネスケースがない限り、その時点で慎重に管理されます彼らは彼らの仕事に有能であるため、それを行っています。
安全なアプリケーションを作成しようとしているときに、他のプロセスが簡単に情報を読み書きできるようにしますか、または、人々が呼び出すと予想され、注意深くサニタイズする、注意深く文書化されたAPIをいくつか持っていますか？
リスク管理-ネットワークに出入りするインターネットへのトラフィックがリスクであると思われる場合は、ルートの数と方法の数の両方に関して、トラフィックがインターネットに到達する方法の量を最小限に抑えることを検討します。次に、これらの選択された「祝福された」ゲートウェイとポートを監視およびフィルタリングして、それらを通過するトラフィックが期待どおりであることを確認します。
これは「デフォルトの拒否」ファイアウォールポリシーであり、通常は良いアイデアと見なされますが、いくつか注意点があります。それが意味することは、ブロックを解除する特定の理由がない限りすべてがブロックされ、その理由の利点がリスクを上回ることです。
編集：明確にする必要があります。あるプロトコルが許可され、別のプロトコルがブロックされるリスクについて話しているのではなく、制御されていない状態でネットワークに出入りする情報のビジネスへの潜在的なリスクについて話している仕方。
次に、警告と、場合によっては解放するための計画について説明します。
あなたが何かからブロックされているとき、それはあなたがいくつかのクライアントであなた自身にいる自分の位置であるので、迷惑になるかもしれません。多くの場合、ファイアウォールの担当者は、「リスクはありますが、今は利点は何か、何ができるかを見てみましょう」ではなく、「いいえ」と言うのが自分の仕事だと思っています。
クライアントのネットワークセキュリティを管理している人に話しかけると、クライアントが何かを設定するのに適している場合があります。アクセスする必要がある特定のシステムを特定できる場合、および/または特定のIPアドレスからのみ接続することを保証できる場合、それらのシステムよりも特定の条件のSSH接続に対してファイアウォール例外を作成する方がはるかに便利です。インターネット全体への接続を開くだけです。または、ファイアウォールを通過するために使用できるVPN機能を備えている場合もあります。
多くの映画を作っていたニューヨークのロチェスターにある特定の会社が、私がそこで働いたときに発信sshをブロックしましたが、許可しましたtelnet！私がそれについて尋ねたとき、彼らはsshはセキュリティホールだと言った。
言い換えれば、企業は時々愚かな決定を下し、間違いを認めるのではなく、セキュリティについての口実な言い訳をします。
会社が外部ログインを許可していない場合は、インバウンドSSH通信のブロックを理解できます。しかし、これがアウトバウンドSSHブロックについて聞いたのはこれが初めてです。
注意すべき重要なことは、そのようなファイアウォールはおそらくカジュアルなSSHユーザーだけを制限するということです。外部（通常、企業ネットワークの外部で重要なアクセス権を持つサーバー/マシン）にSSHで接続したい場合、22以外のポート（ポート80など）でSSHサーバーを簡単に実行できます。ブロックは簡単にバイパスされます。
また、HTTP（ポート80またはHTTPSポート443）を介して企業を終了し、外部のポート22に接続するためのプロキシを提供するいくつかのパブリックドメインツールもあります。
編集：わかりました、ちょっと待ってください、これがなぜポリシーになるのか、私には考えがあります。
時には、人々はSSHトンネルを使用して、IMやBittorrentなどのプロトコルの基本的な送信ファイアウォールをバイパスします（たとえば）。これにより/////そのようなポリシーがトリガーされた可能性があります。ただし、これらのトンネルツールのほとんどは22以外のポートでも機能すると思います。
このような送信トンネルをブロックできる唯一の方法は、オンザフライでSSH通信を検出し、（動的に）これらのTCP=接続をブロックすることです。
私の意見では、送信ポート22をブロックする主な理由は2つあります。
まず、人々が述べたように、SSHポートフォワーディングをプロキシとして使用したり、他のポートやサービスを迂回して、そのようなトラフィックは許可されないというITポリシーを回避できます。
次に、多くのマルウェア/ボットネットはポート22を使用します。これは、ポート22が「安全」であると見なされ、許可されていることが多いためです。その後、そのポートからプロセスを起動できます。感染したコンピューターは、SSHブルートフォース攻撃も実行する可能性があります。
これはおそらく規制/コンプライアンスの問題です。あなたの雇用主は、すべてのコミュニケーションを読み取り/アーカイブできることを望んでいます。これは、銀行などの業界では非常に頻繁に必要となります。
クライアントはおそらく、保持したい重要なデータを所有しています。アウトバウンドSSHは、ネットワーク全体に対してオープンにしておくのは本当に悪いことです。プロキシをバイパスし、機密データを漏らし、そして一般的に不愉快になることはかなり簡単です。
IMO、ネットワーク/インターネット境界を通過するものはすべて理解し、制御できる必要があります。開発者のグループがsshを介してホスティングプロバイダーのサーバーにアクセスする必要がある場合は問題ありませんが、ドキュメント化する必要もあります。一般的に、私が働いた場所では、ネットワーク外の場所への専用のサイト間VPN接続を確立し（基本的には内部ネットワークを拡張）、インターネット経由のSSHなどのクライアントプロトコルを回避します。
多くの場合、必要でない限りすべての発信接続をブロックするケースであり、試行するまでは、誰もがポート22を発信接続に使用できるように要求していませんでした（80、433など）。これが事実である場合、ソリューションはIS/ITに連絡し、なぜ例外を追加する必要があるのかをステーションに伝えて、ステーションが特定のホストまたは一般に発信SSH接続を確立できるようにするのと同じくらい簡単です。
他の制御を回避するために（リンクを介したポート転送を介して）プロキシーをセットアップする方法としてSSHを使用する機能を人々が使用することが懸念される場合があります。これは、法的な理由（インサイダー取引の非推奨、企業データまたは個人データの転送の検出/ブロックなど）またはそのような企業のためにすべての通信を監視/記録する必要がある一部の規制産業（銀行など）では非常に重要な要素になる可能性があります。内部漏洩により、偶然または別の方法で営業秘密が漏洩することを恐れています。このような場合、3Gリンク（またはHTTP経由でSSHをトンネルするなどの他の手法）を使用して制限を回避することは、契約違反となる可能性があるため、略奪行為（またはおそらくは法的違反行為）になるので注意してください。あなたがそれを試みる前にあなたの行動に同意してもらいます。
もう1つの理由は、会社が稼働しているマシンに自分自身をインストールするのに不都合なことがあった場合に（会社のファイアウォール内のホストから一般に世界中にアクセスできる内部サービスに）送信フットプリントを減らすことです。ポート22でSSH接続ができない場合、伝搬ルートの1つがブロックされるため、ブルートフォースSSHログインを使用しようとするより単純なハックの多くが発生します。この場合、ファイアウォールを制御している人々にこれらの接続を正当化できる場合は、マシンにSSH接続を確立できるように、例外を追加するように要求することもできます。
SSHはVPNとして使用できるからです。暗号化されているため、ネットワーク管理者はネットワークから何が残されているのか文字通りわかりません（顧客データベースのダンプなど）。私は毎月のコラム "Secret Tunnels" でこのことを取り上げました。一部の3Gインターネットのコストは、暗号化されたプロトコルがネットワークからデータをチャネリングすることを心配する必要よりもはるかに少ないです。さらに、デフォルトで発信ポート22をブロックしてトラフィックを検査すると、非標準ポートでSSHを簡単に見つけることができるため、セキュリティポリシーに違反している人を見つけることができます。
明白な答えはすべて述べられています。これは暗号化されたプロトコルであり、トンネルの作成（これは企業のWebフィルターを通過するための優れた方法です）と、無許可の通信チャネル（リバースプロキシ）による脅威を回避するために使用できます。
確かに、現代のネットワークではtelnetを破壊する必要があります。しかし、sshを禁止しながら、ネットワークからtelnetを許可することを確認できます。 Telnetはsshよりも能力が低く、スニファーを介してストリームを常にリアルタイムで監視できます。コアネットワークにTelnetデバイスがなく、一部のユーザーがTelnetを使用したい場合、どうすればよいですか。私はそれを見て、それが脅威ではないことを確認できます。
もちろん、これはすべて、デフォルトのポリシーがすべての出力をブロックし、特定のプロトコルのみを許可するという考えに依存しています。エッジにヒットする前にそれらをプロキシしている場合、ボーナスポイント。
SSHの機能を悪用して、SSH経由でSOCKSプロキシをインストールし、サイトの制限をいくつか回避している人が何人かいます。
または、いくつかの単純なポート転送（ssh -L ....）、サイトの制限のためにポートが実際にブロックされている場合、次のようにします。
- ローカル管理者および
- あなたのプロジェクトマネージャー
彼らをテーブルに連れて行き、これがブロックされた理由について詳しく説明させます。もちろん、内部製品を開発するために外部SSHポートにアクセスする必要がある正当な理由が必要です（内部存在：snakeoil.invalidという会社で働いているときにboxA.example.comにアクセスする必要があるのはなぜですか）。
しかし、私はまだ発信SSHをブロックしている会社を見たことはありません:)
明らかに、ネットワーク管理者がSSHトラフィックをブロックするために真剣に真剣な努力を払っていない限り、発信TCP/22ブロックは簡単に回避できます特定。さらに、資産管理者は、3Gモデムと2番目のNICの疑わしいIPアドレスをキャッチするのに十分な資産インベントリを実行するのに十分な勢いである必要があります。私たちの地域にはClearWireサービスがあるので、ネットワークセキュリティに関するエンドランオプションとしてWiMaxさえあります。
私たちは情報漏えいを主に懸念する機関ではありません。しかし、もしそうだとすれば、厳格なネットワークセキュリティポリシーと厳格な資産ポリシー、および監査を組み合わせる必要があります。私の知る限りでは、なんらかの外部ネットワーク接続でインベントリを作成するアセットのネットワークジャックをオフにする既成のセキュリティパッケージは存在しないと思います。それは来るかもしれない。
このようなパッケージがない場合、アセットインベントリプロセスは、3GやWiMaxなどのエンドランネットワーク接続を検出するための最良の方法の1つです。
そして最後に、TCP/22のブラインドブロッキングは、エンドユーザーが仕事用ネットワークのAUPに違反することを意図している、最もワイリーでないブロックのみをブロックします。
人々が22を介してhttpトラフィックを誘導していることを発見したときに、22がブロックされているのを見てきました。
ほとんどの大規模な組織はすべてをブロックし、プロキシサーバー経由のHTTP/HTTPSアクセスのみを許可します。
特定の必要がない限り、デスクトップまたはサーバーからの直接外部接続を許可している企業があると聞いて、私は非常に驚きます。
リモートsshdをポート80で実行することを妨げるものは何もありません。sshとsshdの両方に、ポートを設定する-pオプションがあります。
もちろん、管理者が賢い場合は、ポート22トラフィックだけでなく、sshトラフィックも監視する必要があります。つまり、技術的な問題ではなく、ポリシーの問題があるようです。
他の人が指摘したように、暗号化されたプロトコルは、さまざまなコンプライアンス問題を心配しなければならない人々に胸焼けを引き起こす可能性があります。
管理者はSSHに対して何かをしているので、特にポート22をブロックするケースではなく、開く必要があるとわかっているポートのみを開くケースです。 SSHを開く必要があると管理者に通知されていない場合、管理者は、サーバーで未使用のサービスを無効にする場合と同じ原則により、SSHをブロックします。