По сути дела через туннель можно обойти все ограничения сквида.Юзер качает прогу вот отсюда - http://www.htthost.com/httport_3_quick_overview.htm и все, вбивает левый хттп прокси и весь трафик между ними ходит по SSL.
Есть методы для предотвращения такого беспредела? :-\
>По сути дела через туннель можно обойти все ограничения сквида.
>
>Юзер качает прогу вот отсюда - http://www.htthost.com/httport_3_quick_overview.htm и все, вбивает левый хттп
>прокси и весь трафик между ними ходит по SSL.
>
>Есть методы для предотвращения такого беспредела? :-\а кто его так просто выпустит по SSL во внешний мир?
>а кто его так просто выпустит по SSL во внешний мир?Какая разница - можно и не по SSL.
Подробнее:
Туннелирование TCP через веб-прокси представляет собой способ использования HTTP-метода CONNECT для организации туннеля между клиентом (по одну сторону прокси-сервера) и неким демоном (сервером), обеспечивающим сервис по протоколу TCP — например IRC, SMTP, POP3, HTTP и др. Суть метода тривиальна: когда прокси-сервер получает запрос вида CONNECT host:port HTTP/1.x, он открывает на указанные в запросе хост:порт исходящее соединение, и после установления соединения начинает отдавать на сокет со стороны клиента данные в нетронутом виде, то бишь все содержимое поля "данные" TCP-сегмента. Организовывается туннель. Теперь и клиент, позабыв про HTTP-запросы, кидает в новообразовавшийся туннель сырым TCP-материалом. Ну и так далее.
количество хостов, которые могут быть второй стороной туннеля весьма ограничено и достаточно быстро вычисляются те, которые пытаются использовать юзеры...кроме того особо избранным можно запретить метод CONNECT...
сейчас прочитал вышеуказанную статью и понял, что все далко не так просто... в идеале надо проверять содержимое пакетов...
а еще, для профилактики - сократить request_body_size (название параметра точно не помню)
>сейчас прочитал вышеуказанную статью и понял, что все далко не так просто...В том то и дело... А что дает method connect? Это вроде бы разрешение сквиду соединяться с удаленными серваками по определенным портам. ИМХО первым делом стоит убрать диапазон портов 1025-65535.
>в идеале надо проверять содержимое пакетов...
Сквидом?
>а еще, для профилактики - сократить request_body_size (название параметра точно не помню)
В смысли размер отправляемого PUT/POST запроса? Как это может помочь, кроме того, в таком случае у юзеров начнутся проблемы с отправкой почты через вэб.
ИМХО основной трафик тут будет входящий, интересно, сможет ли reply_body_max_size корректно определить размер ответа, вроде бы он получает его из HTTP заголовка Content-Length?
>>в идеале надо проверять содержимое пакетов...
>
>Сквидом?
нет, конечно...
например, в iptables что-то было на эту тему...
а еще где-то я видел специализированные проги для этого...
это надо заниматься и искать...>>а еще, для профилактики - сократить request_body_size (название параметра точно не помню)
>
>В смысли размер отправляемого PUT/POST запроса? Как это может помочь, кроме того,
>в таком случае у юзеров начнутся проблемы с отправкой почты через
>вэб.
например, у нас всем желающим делается корпоративный ящик, а внешние почтовики закрыты, чтобы вирусов не понатащили...>ИМХО основной трафик тут будет входящий, интересно, сможет ли reply_body_max_size корректно определить
>размер ответа, вроде бы он получает его из HTTP заголовка Content-Length?
а вот reply_body_max_size зажимать бесполезно, так это в первую очередь помешает обычному легальному серфингу, в частности, перестанет работать графика...
>>Сквидом?
>нет, конечно...это уже сложнее... %)
>например, у нас всем желающим делается корпоративный ящик, а внешние почтовики закрыты,
>чтобы вирусов не понатащили...поделитесь опытом, как закрыть внешние почтовики? :) это как перебанить все порносайты...
>а вот reply_body_max_size зажимать бесполезно, так это в первую очередь помешает обычному
>легальному серфингу, в частности, перестанет работать графика...Не скажите, очень действенный способ для экономии трафика на желающих покачать полноразмерные обои для рабочего стола. Лимита в 50-100КБ вполне достаточно для нормального серфа.
Вопрос тут в другом - откуда сквид берет размер объекта.
>>например, у нас всем желающим делается корпоративный ящик, а внешние почтовики закрыты,
>>чтобы вирусов не понатащили...
>
>поделитесь опытом, как закрыть внешние почтовики? :) это как перебанить все порносайты...
я имел ввиду smtp и pop3 закрыты...
с web-почтой бороться особо не приходится, у нас почти никто ей не пользуется, так как корпоративная удобнее и быстрее
кстати, закрыть основные внешние почтовики не вижу проблемы... их всего десятка два-три широкоизвестных...>>а вот reply_body_max_size зажимать бесполезно, так это в первую очередь помешает обычному
>>легальному серфингу, в частности, перестанет работать графика...
>
>Не скажите, очень действенный способ для экономии трафика на желающих покачать полноразмерные
>обои для рабочего стола. Лимита в 50-100КБ вполне достаточно для нормального
>серфа.
только это не поможет в борьбе с туннелями...кстати, неплохой эффект может дать и такая вещь, как урезание ежеденевной квоты на http до размеров 3 Мбайт.
мы у себя сразу ввели такую квоту, первые две недели пользователи жаловались, потом перестали... даже уменьшить сейчас можно :)
а туннели имеют низкий кпд, т.е. много тратится на http и внутреннюю обвязку данных, соответственно, через туннели они еще меньше скачать могут...
>>поделитесь опытом, как закрыть внешние почтовики? :) это как перебанить все порносайты...
>я имел ввиду smtp и pop3 закрыты...у нас проще, в инет ходят только через сквид...
>кстати, неплохой эффект может дать и такая вещь, как урезание ежеденевной квоты
>на http до размеров 3 Мбайт.опять же, стандартными средствами сквида этого не сделать... :(
>>>поделитесь опытом, как закрыть внешние почтовики? :) это как перебанить все порносайты...
>>я имел ввиду smtp и pop3 закрыты...
>
>у нас проще, в инет ходят только через сквид...
а почта через web? но это же неэкономично с точки зрения трафика...>>кстати, неплохой эффект может дать и такая вещь, как урезание ежеденевной квоты
>>на http до размеров 3 Мбайт.
>
>опять же, стандартными средствами сквида этого не сделать... :(
ну почти стандартными... три маленьких скрипта на перле...в принципе, если задаться целью, то двумя сквидами и одним (приблизительно) скриптом можно полность закрыть подобные тоннели, если хоть что-то знать об их внутреннем устройстве... а таких широкодоступных туннелирующих программ единицы...
>в принципе, если задаться целью, то двумя сквидами и одним (приблизительно) скриптом
>можно полность закрыть подобные тоннели, если хоть что-то знать об их
>внутреннем устройстве... а таких широкодоступных туннелирующих программ единицы...ну хотя бы в общем, теоретически - как это реализовать?
коннект на все порты кроме 443 запрещен.
>>в принципе, если задаться целью, то двумя сквидами и одним (приблизительно) скриптом
>>можно полность закрыть подобные тоннели, если хоть что-то знать об их
>>внутреннем устройстве... а таких широкодоступных туннелирующих программ единицы...
>
>ну хотя бы в общем, теоретически - как это реализовать?
где-то в прошлом месяце на этом форуме обсуждалась проблема как прикрутить антивирус к сквиду. там я предложил следующую комбинацию (пусть извращенную, но работать должно):
1) родительский сквид кэширует все по максимуму, cache_mem поднять до небес, maximum_object_size и maximum_object_size_in_memory тоже круто поднять и сделать равными reply_body_max_size.
maximum_object_size_in_memory поднимать необязательно, но желательно, чтобы избежать падения производительности на больших файлах.
еще есть смысл поиграться с параметрами quick_abort.
редиректор редиректит то, что не зависит от имени пользователя.
2) дочерний сквид не кэширует ничего, все берет только (!) от родительского сквида.
соответственно, параметры памяти поднимать не стоит... наверное...
редиректор редиректит то, что зависит от имени пользователя.
думаю, весь редирект можно перетащить сюда целиком, чтобы не ломать устоявшуюся схему...
НО! редиректор подключается не прямо в сквид, а через самописный скрипт-редиректор, который от себя скармливает урл староиу редиректору, а потом сам скачивает с родительского сквида нужный объект, проверяет его содержимое, и на основании этого решает, что отдать сквиду в ответ - исходный урл или послать на сраничку с ругательством.>коннект на все порты кроме 443 запрещен.
это не панацея, как выяснилось...
через GET мона тож туннелировать...
Сам лазил на забаненные айпишники через HTTPort, так как админы заблочили пару важных сайтов.А вообще могу поделиться представлениями по этому поводу:
Можно оставить метод CONNECT ток на 443 порт, или запретить его для определённой группы user'ов. А если это не положено делать, то просто баняться все публичные проксики на 443 порту, а их уж и не так много: во всём нете штук 5-6 (поверьте, сам искал, конечно, юзер может и сам свой проксик сдлелать, но вряд ли он этим будет заниматься. А пользовать методом GET - это изврат. 300 байт в секунду - это несерьёзно, никто этим пользоваться не будет....даже мне надоело :)
>В том то и дело... А что дает method connect? Это вроде
>бы разрешение сквиду соединяться с удаленными серваками по определенным портам. ИМХО
>первым делом стоит убрать диапазон портов 1025-65535.
>
Если я не ошибаюсь, метод коннект дает сквиду вкладывать в http-трафик любые данные, в том числе методы GET, POST а так же работать с FTP. Поппробуй оставить только метод GET