Прокси-серверы прикладного уровня и уровня соединений

Прокси-серверы могут выполнять свою посредническую миссию на разных уровнях.

ПРИМЕР-АНАЛОГИЯ

Рассмотрим пример, иллюстрирующий идею посредничества разного уровня. Для покупки акций инвестор (в нашем случае аналог клиентской части приложения) может прибегнуть к посредническим услугам брокера или трейдера. Брокер, точно следуя указаниям инвестора, покупает для него определенное количество акций определенного типа по определенной цене. Трейдер — это посредник более высокого уровня, которому инвестор поручает самостоятельно принимать решения о необходимых покупках, учитывая различные факторы, например состояние рынка.

Различают прокси-серверы прикладного уровня и уровня соединений.

Прокси-сервер прикладного уровня, как это следует из его названия, умеет «вклиниваться» в процедуру взаимодействия клиента и сервера по одному из прикладных протоколов, например тому же HTTP, HTTPS, SMTP/POP, FTP или telnet. Чтобы выступать в роли посредника на прикладном уровне, прокси-сервер должен «понимать» смысл команд, «знать» форматы и последовательность сообщений, которыми обмениваются клиент и сервер соответствующей службы. Это дает возможность прокси-серверу проводить анализ содержимого сообщений, делать заключения о подозрительном характере того или иного сеанса.

Прокси-сервер уровня соединений выполняет свою посредническую миссию на транспортном уровне, контролируя TCP-соединение. Очевидно, что работая на более низком уровне, прокси-сервер обладает гораздо меньшим «интеллектом» и имеет меньше возможностей для выявления и предупреждения атак. Однако он обладает одним очень важным преимуществом перед прокси-сервером прикладного уровня — универсальностью, то есть он может быть использован любыми приложениями, работающими по протоколу TCP (а в некоторых случаях и UDP).

Примером прокси-сервера данного типа является разработанный достаточно давно, но все еще широко применяемый сервер SOCKS (от SOCKetS).

В простейшей версии протокола SOCKS V4[81] клиент обменивается с прокси-сервером SOCKS двумя сообщениями: запросом клиента SOCKS-серверу и ответом SOCKS-сервера клиенту.

□ Запрос клиента SOCKS-серверу:

· поле 1 — номер версии SOCKS, 1 байт (для этой версии — 4);

· поле 2 — код команды, 1 байт (для установки соединения TCP/IP код равен 1);

· поле 3 — номер порта, 2 байта (TCP-порт запрашиваемого пользователем ресурсного сервера, например, для 21 для FTP);

· поле 4 — IP-адрес, 4 байта (IP-адрес ресурсного сервера);

· поле 5 — идентификатор пользователя (строка переменной длины, завершаемая байтом null).

SOCKS-сервер анализирует все полученные данные и на основании сконфигурированных для него правил определяет, предоставить или нет данному пользователю доступ к данному серверу. Результат SOCKS-сервер сообщает клиенту в виде ответа.

□ Ответ SOCKS-сервера клиенту:

· поле 1 — байт null;

· поле 2 — код ответа, 1 байт (применяются коды для следующих вариантов ответа: запрос разрешен, запрос отклонен или ошибочен, запрос не удался из-за проблем с идентификацией пользователя);

· несколько байтов, игнорируемых клиентом.

Если прокси-сервер сообщил в ответе, что запрос разрешен, то SOCKS-сервер начинает работать промежуточным звеном между клиентом и сервером (например, FTP), контролируя поток квитанций, которыми они обмениваются.