REJIK

Здравствуйте.
Необходимо запретить пользователям заходить на адреса
http://mail.yandex.ru
и https://mail.yandex.ru
с исключением для избранных
есть такое правило

<MAILSOCNET>
ban_dir /usr/local/rejik/banlists/mailsocnet
url http://127.0.0.1/ban/mailsocnet.html
allow_id f:/usr/local/rejik/mailsocnet.allow_id

в /usr/local/rejik/banlists/mailsocnet прописано:
mail.yandex.ru

И в такой конфигурации исключения для https не работают, страница просто не грузится (без подмены на локальный url)
лог режика:
2011-12-20 15:23:24 MAILSOCNET: 132.147.160.122 - mail.yandex.ru:443 (urls rule: mail.yandex.ru)

лог тоже имеет странный вид т.к тут не указан пользователь, хотя сквид настроен на ldap аутентиф. и нормальный лог имеет такой вид:
2011-12-20 13:49:10 MAILSOCNET: 132.147.160.122 s.ivanov http://mail.yandex.ru/ (urls rule: mail.yandex.ru)

куда можно покопать?

Браузер считает, что он работает по шифрованному соединению, редиректор подменяет ему урл на не шифрованный.

Вы пытаетесь загрузить по https страницу замены по 80-му порту.

Можно поднять для таких сайтов страницы замены на сервере с https и прописать соответствующий урл замены для сайтов с https.
Можно сказать браузеру, что урл поменялся: поищите "302:" на форуме.

в моем случае страницу подмены как раз загружать не надо (https страницу пытается открыть пользователь из списка исключений)

Ага, сразу недопонял.

В логе сквида, в этом случае, логин пользователя виден?

нет,пользователя не видно. вот такой лог в сквиде:
1324430431.212 0 132.147.160.122 TCP_MISS/404 0 CONNECT mail.yandex.ru:443 - DIRECT/- -

По этому логин и не попадает в режик.
Добейтесь появления логина в логе сквида и проблема будет решена.

mzv писал(а):нет,пользователя не видно. вот такой лог в сквиде:
1324430431.212 0 132.147.160.122 TCP_MISS/404 0 CONNECT mail.yandex.ru:443 - DIRECT/- -

Действительно, проблема была в правиле сквида:
http_access allow connect ssl_ports
в котором было разрешено коннект на ssl порты без аутентиф.
спасибо за помощь!

У меня тоже не блокируются https сайты

Сквид как прозрачный прокси, т.е. все запросы идут на него. Аутентификации нет. В конфиге сквида -

# Deny requests to unknown ports
http_access deny !Safe_ports
# Deny CONNECT to other than SSL ports
http_access deny CONNECT !SSL_ports

Политикой компании запрещено использовать личную почту в "производственных" целях. Нужно блокировать доступ некоторым особо непонятливым работникам к личной почте на gmail, хотя бы на время, чтобы отучить от использования ее в офисе.

В конфиге режика создал специальный раздел, который действует только для этих IP
<LOCALBAN>
ban_dir /usr/local/rejik3/banlists/localban
url http://xxx.hostline.ru/webmail
work_ip 172.18.4.11
work_ip 172.18.4.1

в localban/url :
accounts.google.com
https://mail.google.com


Тем не менее https открываются. Что посмотреть/подправить нужно в конфигах?

Кстати, еще один момент - переадресация проходит на
url http://xxx.hostline.ru/webmail и не проходит на url https://xxx.hostline.ru/webmail (ошибка не найден путь)

Найдите в аксеслоге сквида попытки доступа на эти https сайты.

Если прокси для https не указан в броузере явно, то нет их там. Т.е. скорее всего iptables https на сквид не заворачивает (т.к. все равно транзитом идет).

Если указан, тогда
1340971102.573 2 172.18.4.1 TCP_MISS/404 0 CONNECT mail.google.com:443 - DIRECT/- -

Что еще проверить?

Два варианта:
1. Если запрос идет мимо сквида, то к режику он так же не попадет и не заблокируется.
2. Если запрос идет через сквид, и он должен блокироваться по правилам режика, но этого не происходит, то нужно проверять правила и конфиг режика.
Например, не надо писать в urls "https://mail.google.com", пишите проще "mail.google.com".
Смотрите error лог режика, нет ли ругани на чтение urls файлов и нужных правил из них.
Возьмете из строки accesslog сквида логин и ip клиента, делающего запрос - попадают ли они под work_* и allow_* правила?

с iptables буду разбираться - тонкость в том, что нужно заворачивать 443 порт только из броузера, иначе webdav перестает работать. Пока не знаю, как это можно сделать.

в error логе режика ругани нет.
попадают под правила.
https из urls убрал, но изменений не заметил

в логе режика
LOCALBAN: 172.18.4.1 - http://mail.google.com/ (urls rule: mail.google.com)
если в адресной строке http - переадресация идет

LOCALBAN: 172.18.4.1 - mail.google.com:443 (urls rule: mail.google.com)
если в адресной строке https - получаю ошибку в броузере.

Броузер вместо переадресации выдает:
Кстати, если в конфиге режика пишу
url https://xxx.hostline.ru/webmail
получаю:

Leo2 писал(а): в логе режика
LOCALBAN: 172.18.4.1 - http://mail.google.com/ (urls rule: mail.google.com)
если в адресной строке http - переадресация идет

LOCALBAN: 172.18.4.1 - mail.google.com:443 (urls rule: mail.google.com)
если в адресной строке https - получаю ошибку в броузере.

На сколько я понимаю, если в redirector.log у Вас такая запись появилась (пометил зеленым) то режик нормально отработал перенаправление, а ошибка в браузере должна появиться потому что Ваш браузер предполагает что должно начаться зашифрованное соединение между вашим и удаленным компьютерами а squid должен выполнить роль тунеля между машинами однако так как режик перенаправил Ваш запрос то получается что соединение не состоялось. Попробуем разобраться почему squid не установил соединение, смотрим access.log и видим что в логе https сайт записан как mail.google.com:443 а не https://mail.google.com/ вот и выяснилось что squid не понимает протокол https а просто создает тунель а значит запись в конфиге url https://xxx.hostline.ru/webmail или url http://xxx.hostline.ru/webmail не сработают для https протокола.
Но не отчаивайтесь, в функционале режика есть кое что что может Вам помочь - попробуйте в конфиге режика вместо url http://xxx.hostline.ru/webmail указать url 302:http://xxx.hostline.ru/webmail, Это должно подменить урл в браузере а значит вы должны получить в адресной стоке браузера вместо https://mail.google.com/ ---> http://xxx.hostline.ru/webmail

Сегодня дорвался до своего сервака и проверил все это на практике, в общем: c https сайтами перенаправление все таки наверное будет невозможно, браузер все равно не примет код ошибки 302 так как хочет зашифрованный коннект и ничего другого принимать не желает, но ведь и заблокированный сайт не открывается а это само по себе радует.
PS. приставку 302: в данном случае наверное лучше использовать дабы избежать ошибок на перенаправленном сайте (без 302: в адресной строке браузера будет не перенаправленный сайт а тот который пытались запросить, возможно будут проблемы с некоторыми скриптами или изображениями).

Выяснил, что запросы https не доходят до squid, т.к. iptables прозрачно перенаправляет запросы только по портам 80 и 8080. Все остальное уходит напрямую. Поэтому неудивительно, что режик и свид на SSL не действуют.

Я пробовал завернуть на squid порт 443, но тогда у меня перестает работать webdav (он тоже secured через порт 443)
Что можно сделать в моем случае?

Leo2 писал(а): Я пробовал завернуть на squid порт 443, но тогда у меня перестает работать webdav (он тоже secured через порт 443)
Что можно сделать в моем случае?

Почитать про проблемы и решения прозрачного проксирования https трафика.
ИМХО: проще прописать прокси сервер на клиенте.