Pull to refresh

Comments 22

Годная статья, спасибо. Добавил обе части в закладки.
Но вы себе придумали немало головной боли, настояв на transparent режиме. Зачем он нужен? Прокси архитектурно правильнее размещать «сбоку», а не «в разрыв». В разрыв полезно разве что в маленьких организациях, где прокси+шлюз+всё_остальное на одном сервере.

Ну и не смог удержаться:
«чем отличается проверка хоста на принадлежность к спаму от проверки на принадлежность к malware? ничем !»
Как минимум тем, что malware-хост может и не распространять СПАМ, правило работает только в одну сторону. Соответственно в эти rbl такой хост не попадет.
речь примерно вот об этих списках.

xbl.spamhaus.org Illegal 3rd party exploits, including proxies, worms and trojan exploits
zombie.dnsbl.sorbs.net — List of networks hijacked from their original owners. Some already used for spamming.
http.dnsbl.sorbs.net — List of Open HTTP Proxy Servers.
rbl.efnetrbl.org -Hosts are added by our bots as users connect with hacked boxes and open proxies.

Проверка по этим спискам может дать положительный результат если вы бродите по сети в поисках кряков или в поисках прона. Залив последние списки блокировки малвари случайно обнаружил несколько хостов которые уже резолвились в ранее виденные малваревые IP, но не детектились коммерческим фильтром.
ок, понятно. Я думал в этих rbl только хосты, которые спамят.
похоже на черную дыру и джет, вылетающий из неё.
Но это изображение художника, а не фото:
Если денег недостаточно или их совсем нет, то впринципе все правильно, хотя конечно головной боли не избежать.
А так уж ли надо дифференцировать доступ по пользователю/компу? Взять и завернуть ВСЕХ через прокси (прозрачный или не очень — благо на это тоже есть функция автоконфигурации) без разбора и фильтровать всех по одинаковым правилам. Если босс будет сильно вопить что ему как и всем доступ вконтакт с рабочнго места закрыли, можно для таких отдельный прокси поднять с ручным прописыванием на клиенте и обычной аутентификацией с хранением пароля в конфиге прокси-сервера, их же немного таких наверняка.
Вы, похоже, никогда не работали системным/сетевым администратором в действительно крупных компаниях (где несколько тысяч сотрудников). То, что вы говорите, — это наколеночные решения для мелких компаний. А топик, как видно даже из названия, по проблемам администрирования в больших компаниях.

В крупных компаниях помимо общих правил для всех появляется отдел разработчиков, для которых нужны специфические правила доступа (в частности права для обмена бинарными exe/dll-файлами), потом отдел дизайнеров со своими заморочками и особенностями доступа, потом отдел по связям с общественностью, которые уверены, что им выход в инет ограничивать никак нельзя, ну и конечно куча боссов разного уровня со своими ассистентами и секретаршами — и их тоже раздражают некоторые ограничения.

В итоге получается, что в компании достаточно разношёрстная «цветовая дифференциация штанов», а у некоторых ещё и по несколько компьютеров, поэтому и на прокси приходится делать разные правила доступа в инет для разных категорий сотрудников.
а еще в крупных компаниях есть такая вещь как синдром светофора. Когда что-то вдруг останавливается на полминуты, то тебе обязательно позвонят человек 20 сразу и спросят «а у нас с интернетом всё хорошо ?»
Хотя ты уже видишь проблему и скорее всего уже на неё отреагировал и скорее всего уже починил.
Ну если в крупной компании все процессы грамотно налажены, то все юзеры звонят не администратору напрямую, а в хелпдеск. Поэтому в случае проблем админ получит только звонок от оператора хелпдеска, который скажет о массовых звонках, уточнит в чём проблема, спросит, что отвечать юзерам и каковы ожидаемые сроки устранения проблемы, а потом все остальные сотни звонков по той же проблеме будет отфутболивать уже сам хелпдеск.
А самого админа по этой проблеме кроме оператора хелпдеска может потревожить разве что ещё непосредственный начальник.
Да, я работал только в средних компаниях — до 100 компьютеров и до 5 филиалов по стране и почти всегда был в своей деревне царём. Всех под одну гребёнку и не-ёт. Хотите эффективную IT-систему (с максимизацией надёжности и минимизацией издержек) — извольте терпеть некоторые ограничения, налагаемые принципом KISS, ведь чем сложнее сисема — тем ниже надёжность и выше TCO, а многих усложнений можно избежать, отказываясь от тех возможностей, необходимость которых для эффективного функционирования бизнеса никто не может уверенно обосновать.
система разрабатывалась изначально как helper для блокировки разной малвари. Перед ней стоял коммерческий фильтр, но коммерческие фильтра не всегда успевают обновляться :( увы. Ну и потом оно обросло тем функционалом который описан в обоих статьях. А если система умеет то что может понадобиться, то почему её не использовать на полную катушку?
обычная аутентификация тут тоже вполне может работать. никто не запрещает в конфиге сквида указать вместо $SRC слово $LOGIN, и авторизовывать по логину. Просто в нашей конторе с этим проблемно. Во первых грузится AD, во вторых иногда возникали никому непонятные лаги на ровном месте(речь о сквиде 2.x на котором начинала строиться система)
От себя добавлю, что можно (но вопрос правильно ли !) ДНС от MS вынести полностью в ISC Bind, для 2008R правда надо поставить будет патч.
в этом решении админ борется большей частью сам с собой чем с malware.

в больших компаниях: McAfee Web Gateway (Webwasher), IronPort S-Serie, BlueCoat etc. В этих продуктах вышеназванных восьми проблем просто нет.

с чем можно поздравить автора — что он обеспечил себя работой на годá и теперь на него все моляться включая начальство. Можно приходить теперь на работу в свитере и небритым — все равно не выгонят, потому что в перл скриптах кроме него (и L.D.Stein'a) никто не разберется.

UFO just landed and posted this here
>>все равно не выгонят, потому что в перл скриптах кроме него (и L.D.Stein'a) никто не разберется
Зря Вы так, последующий админ(если умный) рано или поздно раскопает все скрипты (или свои напишет, но с комментариями) — а вот предыдущего может и «пропеарить» на местном форуме, или ответить на телефонный звонок будущего работодателя того нерадивого админа.

А вообще у DNS_сервисов, будь то опенднс или редиректор есть принципиальный недостаток: они не обеспечивают блокировки веб-трафика в случае, если урл содержит IP-адрес (http://81.81.81.81/virus.js) — а такие есть, и их будет все больше…
Тема статистики и отчетов не раскрыта. Что используйте? Всем ли довольны?
Статку дёргаем тогда, когда видим что за сутки улетели к 40 гигам трафика. Обычный ежесуточный трафик около 30 гигов. Два канала на балансировке через pf — (10Mbit+100Mbit ) Unlim. Используем sarg. никто другой с файлами размером свыше 300 мег работать не умеет корректно. Попытки загона данных в базу были чреваты. увы.
рекомендую попробовать lightsquid для логов… работает существенно быстрее сарга
Sign up to leave a comment.

Articles