TL; DR - я планирую использовать брандмауэр уровня приложения для пересылки только запросов HTML-содержимого на прозрачный прокси. Таким образом, первоначальный запрос GET для google.com (например), который возвращает файл HTML, будет перенаправлен на Squid (прозрачный прокси), но все последующие запросы на статические ресурсы (CSS, JS, файлы изображений и т. Д.) Не будут через прокси.
Можете ли вы представить, как это может повлиять на сеанс пользователя?
Некоторый фон:
У нас есть роутер, но мы хотим выполнять фильтрацию контента с помощью прозрачного прокси-сервера + ICAP-сервера, размещенного на AWS. Первоначально мы планировали перенаправить весь трафик порта 80 на прозрачный прокси, но беспокоились о дополнительных 50–100 мсек, которые мы понесем для каждого запроса, поскольку он маршрутизируется через наш экземпляр EC2, и, что более важно, приведет к неприемлемым затратам на пропускную способность. Недавно мы обнаружили, что межсетевой экран маршрутизатора может фильтровать с помощью глубокой проверки пакетов (например, сопоставление исходящих запросов с заголовком «Accept text / html. *»).
На первый взгляд это кажется гораздо более управляемым решением, но мой опыт работы в сети ограничен, и я хотел выявить любые "подводные камни" и / или примеры того, что это, очевидно, ужасная идея, прежде чем зайти слишком далеко по этому пути.
По моему опыту, прозрачное HTTP-проксирование обычно практически не влияет на пользовательские сеансы.
Однако ваша стратегия и то, чего вы на самом деле собираетесь достичь, кажутся мне неясными. Я думаю, что реальность того, как работает HTTP, станет для вас проблемой. Возможно, вы сможете подробнее рассказать о том, чего вы действительно пытаетесь достичь с точки зрения конечного результата. Я не говорю, что это «ужасная идея», но совершенно неясно, что вы надеетесь получить.
С точки зрения протокола HTTP у вашей стратегии есть серьезная проблема. Ваш брандмауэр уровня 7 по определению не может знать тип MIME запрашиваемого ресурса до тех пор, пока запрос не будет сделан. Вы можете выполнить сопоставление имени файла (увидеть его, если он оканчивается на «.html» и т. Д.), Но любой URL может возвращать произвольный тип MIME. это .b0rk файл является text/html, но правило соответствия в вашем брандмауэре на .html или .htm не "знал" этого. Запрос должен быть отправлен удаленному серверу, и удаленный сервер должен ответить до того, как станет известен тип MIME.
Почему вы считаете, что другие типы файлов (CSS, Javascript, изображения и т. Д.) Являются «статическими»? Они определенно не должны быть такими. Объект, на который ссылается любой URL, может быть «динамическим».
Если вас беспокоит стоимость полосы пропускания, почему бы просто не разместить прозрачный прокси локально? Локальный прокси-сервер не будет подвергаться задержке в десятую долю секунды для запросов, попадающих на прокси, и у вас не будет потенциальных затрат на пропускную способность, связанных с отправкой всех ваших данных из стороннего центра обработки данных. Вы также заметите некоторое улучшение использования локальной пропускной способности, когда прокси-сервер кэширует объекты, и вы можете позволить ему кэшировать все (что это cna).
Я запустил образовательную сеть на 1000 мест через экземпляр Squid-cache, работающий на оборудовании, которое сегодня могло бы показаться жалким. Если вы не говорите об очень, очень большой сети, очень скромная машина могла бы справиться с нагрузкой за вас. Если вас беспокоит единственная точка отказа, вы можете использовать Протокол связи веб-кеша (WCCP), если ваше пограничное устройство поддерживает это, для переключения между парой кешей.
Если вы собираетесь делать это для сканирования HTML на предмет «вредоносного» кода, то, думаю, вы смотрите на него наоборот. Меня больше беспокоит вредоносный код в Javascript и application/octet-stream объекты, чем о text/html объекты. В любом случае я сомневаюсь в том, чтобы сканировать, потому что все может быть достаточно запутано, чтобы ускользнуть от сканирования (см. Проблема с остановкой). Если вы не собираетесь использовать перехват SSL, вы также пропустите все, что доставляется по HTTPS. Сканирование жестяная банка ловите известные эксплойты, и я действительно считаю это действительной частью архитектуры ИТ-безопасности, но нулевой день почти всегда проходит мимо.