| TCP/IP群 |
|---|
| アプリケーション層 |
|
| トランスポート層 |
| カテゴリ |
| インターネット層 |
| カテゴリ |
| リンク層 |
| カテゴリ |
SOCKSは、インターネット・プロトコル・スイートにおいて、Transmission Control Protocol（TCP）および User Datagram Protocol（UDP）による通信を代理するプロキシのプロトコルである。主にTCPのために設計されている。認証の機能の規定もあるため、それが実装されていれば認証にもとづき、認可された接続のみ接続を許可するような設定もできる。DARPAモデルの観点からは、3番めの層にあるTCP及びUDPによる通信を代理するものであり、使い方にも依るが通常は4番目のアプリケーション層からは透過ではない。例えばウェブブラウザのようなアプリケーションから利用する場合は、ネットワーク接続に関する設定として明示的にプロキシとして指定が必要である。ポート番号には1080がよく使われている[1][2]。
SOCKSは当初、MIPS Computer Systemsのシステム管理者であるDavid Koblasによって開発された。Koblasは、MIPS Computer Systemsが1992年にSilicon Graphicsによって吸収合併された後に、その年のUsenix Security SymposiumでSOCKSの研究論文を公開した。これによりSOCKSはパブリックに利用できるようになった[3]。SOCKSは、NECのYing-Da Leeによってバージョン4に拡張された。
SOCKS関連のアーキテクチャやクライアントはPermeo Technologiesが所有している[4]。なお、Permeo Technologiesは、NECからスピンオフしたBlue Coat Systems[5]によって吸収合併された[6]。
SOCKS5プロトコルは、もともとはファイアウォールの一部として、他のセキュリティ製品とともに管理を容易にするために作られたセキュリティプロトコルだった[7]。1996年にIETFによって承認された[7]。SOCKS5は、アジア外の技術を販売している企業Aventail Corporationの協力のもとに開発された[8]。
SOCKSは迂回のためのツールとしても使用されることがある。たとえば、政府、職場、学校、特定の国限定のウェブサービスなどで、インターネットのコンテンツへのアクセスフィルタやブロッキングが行われている場合に、それらを回避することができる[9]。
たとえば、Tor onion proxyソフトウェアは、クライアントに対して、SOCKSインターフェイスを提供している[10]。
OpenSSHはSOCKSプロトコルを利用した「動的ポートフォワード」の機能を持っている。SSHサーバ側で許可されていれば、クライアント側からは ssh(1) コマンドにある -D オプションで利用でき、sshコマンドのプロセスがローカルなSOCKSプロキシのようにして見えるようになる。そのプロキシへの接続はSSHサーバ側へポートフォワードされ、最終的な接続先からはSSHサーバからのアクセスとして見える。[11]。
クラッキングされたコンピュータには、ボットネットの制御を隠したりクレジットカード詐欺等といった、マルウェア的な目的のために、SOCKS proxyソフトウェアが設定されることがある[12][13][14][15]。
 |
SOCKSは、ネットワーク・ファイアウォール越えやアクセス制御等を目的として、クライアントサーバ型のプロトコルが、透過的に使用できるよう設計されたプロキシ（proxy）のプロトコル、及びシステム（の一つ）である。"SOCKetS" [16] の略。
いわゆるTCP/IPの4層モデル（インターネット・プロトコル・スイートのDARPAモデル）の観点からは、Internet Protocol（IP）の上の、TCPやUDP（ただしUDPに関しては有用性が限られる）のようなトランスポート層における通信の手続きを中継・代理するメカニズムとなっている。SOCKSサーバ自身とクライアント間の通信はストリーム指向であり、一般にはLAN内からTCPで接続する。
プロトコル上は多段にもできるが、原理の説明には1段階で十分なので、以下はそのような前提とする。またファイアウォールを設けないシステムでもユースケースは考えられるが、以下ではファイアウォールの存在を前提とする。
似たような目的のための他のプロキシ類と同様、SOCKSサーバはその目的から、内外のネットワークの両方が見えるファイアウォール自身、あるいはDMZ内に置く。そうでない場合は、SOCKSサーバのみは外部との通信を可能にする、あるいは、内部からSOCKサーバにだけは通信を可能にする、といったような設定が必要となる。
そして、内側から外部に通信する必要があるノードは、代わりにSOCKSサーバに接続し、SOCKSサーバがプロキシとして代わりに外部と通信する。SOCKSプロキシは、例えば、クライアントが外部サーバにアクセスする資格を制御するなどといった、認証や認可を掛けることもできる。SOCKSはまた正反対にも使用することができる。つまり、ファイアウォールの外側の許可された外部クライアントのみが、物理的にはファイアウォールの内側にある、公開のサービスを提供するサーバのみに接続できるようにする、といった用途のための設定もできる。
標準の SOCKS 4 接続では、以下のような通信が行われる。
SOCKS クライアントからサーバ:
SOCKS サーバからクライアント:
例:
これは、66.102.7.99:80にユーザ「Fred」を接続する SOCKS 4 のリクエストである。そして、サーバは、"OK"の返事をする。
この時点以降、 SOCKS クライアントから SOCKS サーバまで送る全てのデータは66.102.7.99に向けて中継される。そして、 SOCKS サーバから SOCKS クライアントに送る場合も同様である。
コマンドフィールドは、 "connect" で 0x01 、あるいは、 "bind" で 0x02 になることができる。 "bind" は動作中の FTP のようなプロトコルのために入ってくる接続を許可する。
SOCKS 4a は、 SOCKS 4 プロトコルのシンプルな拡張機能であり、宛先ホストのドメイン名を解決できないクライアントがドメイン名を指定することを可能にする。
クライアントは宛先アドレスの最初の3バイトを NULL に、そして最後のバイトを0でない値に設定すべきである(これは、ｘ を非零の値として、 IP アドレス 0.0.0.x に対応する。この値は宛先アドレスとして使用してはならない。したがって、この値は、もしクライアントがドメイン名を解決できるならば、決して設定するべきではない。)。
ユーザ ID を終了する NULL バイトの次に、クライアントは宛先ドメイン名を送らなければならない、そして、それを別の NULL バイトで終了させなければならない。これは "connect" と "bind" の両方のリクエストに使われる。
SOCKS クライアントからサーバ:
SOCKS サーバからクライアント:
4A プロトコルを使用するサーバはリクエストパケット内の宛先アドレスをチェックしなければならない。宛先アドレスが、 x を非零の値としてアドレス 0.0.0.x を表現するならば、サーバはクライアントがパケット内に送付するドメイン名を読み込まなければならない。サーバはドメイン名を解決すべきであり、そしてそれが可能であるならば、宛先ホストへの接続を確立しなくてはならない。
より多くの認証の選択を提供する SOCKS 4 プロトコルの拡張である SOCKS 5 プロトコルは RFC 1928 内で定義されている。最初のハンドシェイクは下記の事項から成り立つ。
サポートされた認証方法は次の通りに番号を割り付けている：
クライアントからの最初の挨拶：
サーバの選択が伝えられる：
次の認証は認証方法によって異なり、 RFC 1929 で記述されている。
クライアントの認証要求：
認証のためのサーバの応答:
クライアントの接続要求：
サーバの応答：
SOCKSによって外部ネットワークに接続する、全てのネットワーク・ソフトウェアの適合を可能にする "socksify" というクライアント用のプログラムがある。
未登録
IPFS未登録
📡 0ピア
N=1
CRITICAL
PQS B66