The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"принцип DNSBL против  open proxy"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Настройка Squid и других прокси серверов (Public)
Изначальное сообщение [Проследить за развитием треда]

"принцип DNSBL против  open proxy"  
Сообщение от shizzzgara (ok) on 18-Апр-06, 22:56 
  Здравствуйте!
DNSBL довольно широко используется при работе с почтой. Возникает естественный вопрос - существует ли похожий механизм для Squid для автоматического определения нежелательных open(и не очень open) proxy?
Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

 Оглавление

Сообщения по теме [Сортировка по времени, UBB]


1. "принцип DNSBL против  open proxy"  
Сообщение от Андрей Слободяник on 19-Апр-06, 11:56 
>  Здравствуйте!
> DNSBL довольно широко используется при работе с почтой. Возникает естественный вопрос
>- существует ли похожий механизм для Squid для автоматического определения нежелательных
>open(и не очень open) proxy?

Не совсем понятно, что требуется.
Сформулируй вопрос по-другому.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

2. "принцип DNSBL против  open proxy"  
Сообщение от shizzzgara (ok) on 20-Апр-06, 23:13 
  Может быть я с хронического недосыпания совсем глупость придумала...
Скажем, существуют всякие оперативные блэк-листы для почтовиков, когда почтовик при helo проверяет ip отправителя на вшивость и в случае положительного ответа режектит письмо или вносит свою пометку(как в моем случае). Существуют ли подобные сервисы для Squid? Клиент посылает запрос содержащий destination адрес. Редиректор проверяет этот адрес на наличие его на блэк-лист - сервере и в случае положительного ответа выполняет заданное действие - блокировку или редирект и т.д. Понятно, что так могут отсеиваться или проходить дополнительную проверку не только   открытые прокси, но и прочие "ненужности".
  Чушь?  
>
>Не совсем понятно, что требуется.
>Сформулируй вопрос по-другому.


Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

3. "принцип DNSBL против  open proxy"  
Сообщение от Sloboda (ok) on 21-Апр-06, 11:30 
>  Может быть я с хронического недосыпания совсем глупость придумала...
Девушка? Ого, по стопам ginger?

> Скажем, существуют всякие оперативные блэк-листы для почтовиков, когда почтовик при helo
Я в курсе принципов DNSBL для почты.

>сервисы для Squid? Клиент посылает запрос содержащий destination адрес. Редиректор проверяет этот адрес на наличие его на блэк-лист - сервере и в
>случае положительного ответа выполняет заданное действие - блокировку или редирект и
>т.д.
Да, есть, конечно, такие механизмы, тут - на опен-нете - многократно описанные.
acl-мя сквида можно реализовывать очень гибкую политику.
А редиректорами - rejik, squidguard - резать баннеры, порно и т.д.

> Понятно, что так могут отсеиваться или проходить дополнительную проверку не
>только   открытые прокси, но и прочие "ненужности".
А вот открытое прокси - это из другой оперы. В отличие от почтовика, прокси не нужно открывать на весь инет. Правда, есть либо специально либо ошибочно настроенные открытые прокси.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

4. "принцип DNSBL против  open proxy"  
Сообщение от shizzzgara (ok) on 24-Апр-06, 13:22 
>Да, есть, конечно, такие механизмы, тут - на опен-нете - многократно описанные.
>
>acl-мя сквида можно реализовывать очень гибкую политику.
>А редиректорами - rejik, squidguard - резать баннеры, порно и т.д.
Я как раз сейчас использую rejik. Его идея понятна, проблем не создает, делает то, что от него ожидается.

>А вот открытое прокси - это из другой оперы. В отличие от
>почтовика, прокси не нужно открывать на весь инет. Правда, есть либо
>специально либо ошибочно настроенные открытые прокси.
Вот про них и речь. У нас есть большой отдел web-программистов. Они очень любят использовать именно "специально либо ошибочно настроенные открытые прокси". Политика ограничений доступа в Интернет у нас не жесткая. Я не очень понимаю страсть  пользоваться открытыми прокси. Стесняются наверное :)  А если серьезно, то ребята не научились предохраняться и тащут в сеть троянов и прочую гадость. Утомляет это.


Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

5. "принцип DNSBL против  open proxy"  
Сообщение от Sloboda (ok) on 24-Апр-06, 15:20 
>>А вот открытое прокси - это из другой оперы. В отличие от
> Вот про них и речь. У нас есть большой отдел web-программистов.
>Они очень любят использовать именно "специально либо ошибочно настроенные открытые прокси".
>Политика ограничений доступа в Интернет у нас не жесткая. Я не
>очень понимаю страсть  пользоваться открытыми прокси. Стесняются наверное :)

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

>А если серьезно, то ребята не научились предохраняться и тащут в
Ты по совместительству и виндовая админша? Во-первых, проводить разъяснительную работу, во-вторых, грамотно настроить винду, но, увы, это не мой профиль.

>сеть троянов и прочую гадость. Утомляет это.

Теперь по сути вопроса. Мягкий вариант - закрыть фаерволом проксёвые порты: 80, 3128, 8080, 8800 и т.д. Жесткий вариант - учитывая, что открытые прокси могут жить на любых портах, закрыть весь проходящий трафик, оставить только доступ к локальному прокси.

P.S. Админ Ж... Где ж такие чудеса-то встречаются?

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

6. "принцип DNSBL против  open proxy"  
Сообщение от shizzzgara (ok) on 24-Апр-06, 18:44 
>Ты по совместительству и виндовая админша? Во-первых, проводить разъяснительную работу, во-вторых, грамотно
>настроить винду, но, увы, это не мой профиль.
Я не занимаюсь поддержкой пользователей и работой с Win. У меня FreeBSD на серверах и ... MacOS X на маке дома и на работе :-P Парни которые как раз занимаются пользователями Win постоянно жалуются.
>
>>сеть троянов и прочую гадость. Утомляет это.
>

>Теперь по сути вопроса. Мягкий вариант - закрыть фаерволом проксёвые порты: 80,
>3128, 8080, 8800 и т.д. Жесткий вариант - учитывая, что открытые
>прокси могут жить на любых портах, закрыть весь проходящий трафик, оставить
>только доступ к локальному прокси.
Ясно. Придется бить рублем. Нельзя нам все закрывать. А мягкий вариант бесполезен.

>P.S. Админ Ж... Где ж такие чудеса-то встречаются?
  Надеюсь, что там не то слово о котором сразу бы подумал Ржевский?  :)
  

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

7. "принцип DNSBL против  open proxy"  
Сообщение от Sloboda (ok) on 26-Апр-06, 12:20 
>>Ты по совместительству и виндовая админша? Во-первых, проводить разъяснительную работу, во-вторых, грамотно
>>настроить винду, но, увы, это не мой профиль.
> Я не занимаюсь поддержкой пользователей и работой с Win. У меня
>FreeBSD на серверах и ... MacOS X на маке дома и
>на работе :-P
Удивляюсь всё больше. Зачем это всё нужно девочке/девушке/женщине/бабушке?

>Парни которые как раз занимаются пользователями Win постоянно жалуются.
Работал в фирме с грамотным виндовым админом. Ни сбоев, ни вирусов - но мне до него далеко.

> Ясно. Придется бить рублем. Нельзя нам все закрывать. А мягкий вариант
>бесполезен.
Ещё есть один вариант, правда, я по описанию толком не понял - оно или не оно? iptables + tproxy (из patch-o-matic), а вот под БСД не знаю.

>>P.S. Админ Ж... Где ж такие чудеса-то встречаются?
>  Надеюсь, что там не то слово о котором сразу бы
>подумал Ржевский?  :)
Тысяча извинений за невольно допущенную двусмысленность. icq: 84065753

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

8. "принцип DNSBL против  open proxy"  
Сообщение от shizzzgara (ok) on 27-Апр-06, 12:54 
>> Я не занимаюсь поддержкой пользователей и работой с Win. У меня
>>FreeBSD на серверах и ... MacOS X на маке дома и
>>на работе :-P
>Удивляюсь всё больше. Зачем это всё нужно девочке/девушке/женщине/бабушке?
Тяжелая мужская работа? ;)

>Ещё есть один вариант, правда, я по описанию толком не понял -
>оно или не оно? iptables + tproxy (из patch-o-matic), а вот
>под БСД не знаю.
Закрыла в squid connect - был неправильный порядок правил. Притихли:) Наверное это и есть решение.

>>>P.S. Админ Ж... Где ж такие чудеса-то встречаются?
>>  Надеюсь, что там не то слово о котором сразу бы
>>подумал Ржевский?  :)
>Тысяча извинений за невольно допущенную двусмысленность.
Принимаются:)
>icq: 84065753
у меня муж - волшебник. Но все равно спасибо:)


Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

9. "принцип DNSBL против  open proxy"  
Сообщение от Sloboda (ok) on 27-Апр-06, 13:39 
> Закрыла в squid connect - был неправильный порядок правил. Притихли:) Наверное
>это и есть решение.

Что-то я потерял нить. Connect обычно нужен на ssl-ные порты, иначе через него можно и на 25-ый порт обращаться.

Твои программеры чужие открытые прокси юзают? Мы вроде этот вопрос обсуждали, причём здесь настройки локального прокси, если это просто проходящий трафик.

Или через твою прокси по connect-у к всякой фигне цепляются?

Или у тебя прокси фаерволом не прикрыто да ещё connect был разрешен? 8-[  ]

Вспомнилось из лички. Начало карьеры, 2000-ый год, инет ещё дайлапный и дорогой. Я работаю у провайдера. Приходит знакомая с подругой за рефератом. Подруга мне:
- И что ты здесь делаешь?
- Провайдер, саппорт.
- А какая у вас тут ОСь стоит?
Я в полной уверенности, что и она и слыхом не слыхала, гордо:
- Linux.
- А какой?
- Red Hat 6.2
- Мда, а я дома Mandrake ставила, мне он больше понравился.
У меня глаза по 5 копеек, челюсть на полу, потом у знакомой спрашиваю:
- Это кто такая?
Знакомая небрежно:
- Расслабся, во-первых она замужем, у неё муж компьютерщик, она этот линукс только из-за его плеча и видела...

Зато нескольками годами позже читал Ginger-овскую статью про Exim + DbMail 8-[ ]

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

10. "принцип DNSBL против  open proxy"  
Сообщение от shizzzgara (ok) on 27-Апр-06, 16:50 
>> Закрыла в squid connect - был неправильный порядок правил. Притихли:) Наверное
>>это и есть решение.
>
>Что-то я потерял нить. Connect обычно нужен на ssl-ные порты, иначе через

Нить у нас потеряна с самого начала и не без моей помощи. :) Изначально интересовала применимость принципа DNSBL для фильтрации всякого дурных ресурсов вообще и open proxy в частности. Сейчас эта частность интересует мало, а первая часть вопроса остается открытой. То есть это не крик "мама, помогите!", а просто вопрос - делают ли так:)


>Или через твою прокси по connect-у к всякой фигне цепляются?

Уже не цепляются

>
>Зато нескольками годами позже читал Ginger-овскую статью про Exim + DbMail 8-[
>
Читала для общего развития. Ничего сказать не могу, т.к. на Exim пока смотрю с точки зрения экспериментальной. Поставила на одну машинку, но к настройкам пока не притрагивалась. Я привыкла к Postfix. :)  


Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

11. "принцип DNSBL против  open proxy"  
Сообщение от forfreeuse email(??) on 28-Апр-06, 08:42 
>  Здравствуйте!
> DNSBL довольно широко используется при работе с почтой. Возникает естественный вопрос
>- существует ли похожий механизм для Squid для автоматического определения нежелательных
>open(и не очень open) proxy?

Есть несколько сдерживающих моментов для использования принципов DNSBL в редиректорах:

1. Медленно. На каждый запрос клиента необходимо выполнять DNS резолв, что вводит дополнительную задержку. Такая задержка не существенна при хождении почты, и существенна при загрузке страницы сайта, а если ещё учесть, что на одной страницы N элементов и каждый придется так же проверять..

2. Не универсально. Так как позволяет работать только с доменными именами. Как например проверить site.ru/banner на наличие в DNS?

PS: Думал сделать такую систему для редиректоров, но по приведенным выше причинам отказался.


Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

12. "принцип DNSBL против  open proxy"  
Сообщение от shizzzgara (ok) on 29-Апр-06, 13:44 
>Есть несколько сдерживающих моментов для использования принципов DNSBL в редиректорах:
>
>1. Медленно. На каждый запрос клиента необходимо выполнять DNS резолв, что вводит
>дополнительную задержку. Такая задержка не существенна при хождении почты, и существенна
>при загрузке страницы сайта, а если ещё учесть, что на одной
>страницы N элементов и каждый придется так же проверять..
>
>2. Не универсально. Так как позволяет работать только с доменными именами. Как
>например проверить site.ru/banner на наличие в DNS?
>
>PS: Думал сделать такую систему для редиректоров, но по приведенным выше причинам
>отказался.

Резонно. Жаль, конечно, но получается, на самом деле, мартышкин труд.
Спасибо.


Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру