Help me, please.

Если траффик к нему идет через тебя - закрой ему 3128 порт и все. Или 8080... Короче проксевый порт перекрой и будет тебе счастие.

2Nefer:
сам-то понял что сказал?

2anonymous:
Никак. Только административными мерами. В общем случае ты никак не узнаешь, кто прячется за его прокси. Особливо если этот прокси - анонимизирующий. Ну можно попытаться посмотреть хедеры, которые оставляет этот Usergate - и на их основе фильтровать - но это тоже легко обходится удалением этих хедеров.

Спасибо вам за ответы.
Я так и думал, что не удастся, но вот зотел поспрашивать людей, может кто и сталкивался с таким саботажем :) Кто и как боролся и борется.:)
Спасибо.

1. Я так понимаю клиентские машины под винды? Поставь тогда squid 2.5 и аутентифицируй пользователей по login'у в windows. 2. Другой очевидный вариант - разобраться чем запросы этого прокси отличаются от запросов обычного браузера - и зафильтровать 3. Поставить ограничение пропускной способности - delay_pool - при правильном подборе параметров это может помочь.

2anonymous(2002-09-30 11:03:34.049)

1.Клиенты - Виндовые.
2.Если будут проходить через этого пользователя, то просто произойдёт его аутентификация (ведь фактически это получаются уже ЕГО запросы?). Или я не прав?
3"..разобраться чем запросы этого прокси отличаются от запросов обычного браузера - и зафильтровать.."
Каким образом?
Я знаю уже какой прокси, это UserGate.
4.Ограничить delay_pool-ами можно, но это не снимет проблему, а только увеличит нагрузку на сервер.

За ответы спасибо, если честно, то даже появилась надежда :)

В догонку к п.2
Если этот пользователь может предоставить свою машину как шлюз для других "обездоленных", то ничего не помешает ему сказать свои данные по аутентификации.
Если SQUID у меня пускает по MAC-адресам, то его прокси просто переваливает от своего имени чужие запросы выдавая их за свои.

Спасибо.

2anonymous (*) (2002-09-30 13:30:35.166)

Нет, если использовать аутентификацию NTLM, то аутентифицироваться должен конкрентно IE клиента, кроме того вероятно, что такая аутентификация через UserGate вообще не пройдет. В принципе нет необходимости реально выполнять полную аутентификацию, достаточно будет воспользоваться модулем fakeauth_auth, вряд ли злоумышленники смогут подменить credentials.

Если искать отличия в запросах от UserGate и просто браузеров, то тут обширное поле для деятельности. Можно ловить cами пакеты (с помощью tcpdump) есть шанс что у них другой например TTL. Можно попытаться что-то найти в HTTP-запросе.

Я так понимаю, что эта аутентификация появилась с версии 2.5?
Если можно, то подскажите ссылочку или как это делать.
Может кто это использует у себя?
Расскажите.
Спасибо.

http://www.squid-cache.org/Doc/FAQ/FAQ-23.html http://www.artmagic.ru/labs/sqlandwin.shtml

anonymous (2002-10-02 12:08:17.694)

Спасибо, но это не пойдёт.
У меня одноранговая сетка без NT-сервера для регистрации учётных записей. Никакой самбы нет (пока).
Есть файл-сервер под Windows, но он не производит идентификацию пользователей. В силу ряда причин это положение сохранится ещё какое-то время, следовательно этот способ аутентификации мне не пойдёт.
Спасибо.

Я конечно не уверен, но возможно, что IE отправляет credentials и в том случае, если ты логинился не в домен, а просто на машину, ведь протокол NTLM v1 работает и в одноранговых сетях. В принципе это очень легко проверяется, если перехватить пакеты сниффером. Мне здесь просто не на чем проверить

Абрамофф - я то прекрасно понял. Если весь траффик (даже между пользователей) пустить через роутер то можно отфильтровать траффик на порт прокси у этого пользователя. что здесь такого? Вот только разворачивать этот траффик... Может получиться тяжело и/или дорого. Зато все будет шоколадно.

В общем, я так понял, что это всё-таки гвязано с необъяснимым и неоправданым гемором.
Прийдётся искать другие способы.
Большое спасибо всем, кто хотел помочь и помогал!