Comments 67
Ну это не та площадка, чтобы размещать how-to по установке squid. А самое главное нет ответа на вопрос где брать списки для блокировки или для белого-листа. Ну и конечно в реалиях РФ важна бумажка которой для наколенного решения не будет и в случае чего прикрыться будет нечем.
1. Список я нашел в интернете по простому запросу «список разрешенных сайтов для школ» (самые основные) + дополнил его своими сайтами + дал задачу учителям приносить мне адреса сайтов, которые им нужны. => список является дополняемым. При желании, его можно оформить, распечатать, подписать директором и будет бумажка. Также я указал, что могу скинуть свой список ввиду того, что он слишком большой. В статью его добавлять нецелесообразно, а файлы, кроме картинок, я так понял, добавлять нельзя.
2. Реалии РФ таковы, что требовать у нас любят, а как дело доходит до финансирования — денег нет, но вы держитесь. Отсюда наколенные решения.
2. Реалии РФ таковы, что требовать у нас любят, а как дело доходит до финансирования — денег нет, но вы держитесь. Отсюда наколенные решения.
В недавней статье про наколенное решение на малинке гражданин divanus писал, что с финансированием в школах все хорошо: https://habr.com/ru/post/472200/#comment_20805868
Вы можете опровергнуть его тезис конкретными фактами?
Ростелеком предоставляет комплексное решение контентной фильтрации. У нас в центре образования (а это 5 школ и 3 детсада) подключена их система. Отсутсвтует в принципе проблема с фильтрацией. Скорее даже приходится к примеру для работы с Яндекс.Облако (школьный портал) в начале VPN организовать, а уже потом только РТ добавил в белые списки фильтрации.
Например, в Москве всё очень жирно. Но не без дебилизма — могут купить дорогое крутое оборудование, а установить его как попало.
Как мне рассказывали, в московских школах штатно предусмотрен интернет через единый ЦОД. И на уровне школ вопрос фильтрации контента не решается — этим занимаются централизованно.
А вот в регионах может быть что угодно.
Как мне рассказывали, в московских школах штатно предусмотрен интернет через единый ЦОД. И на уровне школ вопрос фильтрации контента не решается — этим занимаются централизованно.
А вот в регионах может быть что угодно.
Хотите фиаско? Спустя пару месяцев после того, как я сделал вышеописанную фильтрацию, мне сообщили, что в следующем году школу будут переключать на другого провайдера с фильтрацией интернета централизовано по региону без возможности отказа.
Почему фиаско? Если вам эта система нужна только чтобы прикрыть ... для соответствия 436-ФЗ — надо радоваться, что заниматься этим будет кто-то другой, с соответствующими лицензиями.
я потратил кучу времени и сил, чтобы разобраться и сделать то, что сейчас работает, а мне сообщают, что можно было бы этого и не делать. С другой стороны, все-таки хороший опыт, который мне еще пригодиться на другой работе.
И еще момент — если централизовано фильтрация будет недостаточная (проверка сможет выйти хотя бы на один нехороший сайт) то выговор угадайте кому будет? Мне, а не провайдеру. В РФ так.
Что касается техники — она есть и ее полно. На нее денег не жалеют — верно. В разумных пределах, конечно. А вот что касается ПО для примера: несколько учителей у меня в школе покупали лицензии на офис 365 за свой счет, так как денег не дали. Применительно к фильтрации — если использовать платное решение, то это не единовременные затраты, а по подписке раз в месяц\год, следовательно, не каждой школе дадут добро на это.
Насколько я понял из разговоров тех к кому приходила проверка, то приходит человек и вбивает в яндексе что то типа «как сделать бомбу» и давай по ссылкам ходить.
Если я введу белый список, то мне только и придётся, что его пополнять и смысл интернета в школе с таким списком будет около нуля. А черный список я естественно вести не в состоянии.
Если рассуждать здраво, то тут безвыходная ситуация.
Если я введу белый список, то мне только и придётся, что его пополнять и смысл интернета в школе с таким списком будет около нуля. А черный список я естественно вести не в состоянии.
Если рассуждать здраво, то тут безвыходная ситуация.
Приходит проверка из прокуратуры, вбивает в Яндекс-картинки "белая азбука" и вы влетаете на штраф.
выход в такой ситуации есть и я указал его в статье — делаем фильтрацию по рабочему времени минус 1 час. Детям полный интернет не нужен, а вот для учителей, если что-то надо будет найти — пусть либо ищут дома, либо ждут определенного времени. + проверка если и придет, то утром или ближе к середине дня.
А, собственно, почему? На сайте очень много хороших пошаговых инструкций на самые разные темы.
>У некоторых сайтов множество поддоменов, субдоменов и т.д.
Вот это самый адский пункт. Я конструировалвелосипеды белые списки.
Для работы нам понадобится всего лишь разрешить сайт sitename.ru, а на деле это оборачивается головняком с определением да что же он не работает то, и что ж тебе, болезному ещё надо то?. Не всегда это можно определить анализом статической части, у нас же вебдваноль как никак, фрейморки, скрипты и динамическая разметка рулят. В общем, неблагодарная это работа. Плагин uMatrix в какой то мере облегчает(ит) её, он сразу показывает в итоговой таблице возможные запросы посторонних доменов со страницы.
Вот это самый адский пункт. Я конструировал
Для работы нам понадобится всего лишь разрешить сайт sitename.ru, а на деле это оборачивается головняком с определением да что же он не работает то, и что ж тебе, болезному ещё надо то?. Не всегда это можно определить анализом статической части, у нас же вебдваноль как никак, фрейморки, скрипты и динамическая разметка рулят. В общем, неблагодарная это работа. Плагин uMatrix в какой то мере облегчает(ит) её, он сразу показывает в итоговой таблице возможные запросы посторонних доменов со страницы.
Это скорее how-to в стиле копировать-вставить в терминал. Если бы все параметры были объяснены подробнее, было бы круто. А так есть куда более подробные статьи на хабре по сходной теме. Например, вот.
К тому же Webmin является плохим выбором, т.к. любит ломать конфиги, пишет их абсолютно нечитаемым для человека способом и вообще работает не очень стабильно. И хоть вы предлагаете его использовать только в качестве мониторинга, другой человек, увидев богатство настроек Webmin, вполне может начать им редактировать что-то, а потом быть неприятно удивлен. Лучше уж поставить CentOS с Cockpit (есть и под deb-based дистрибутивы, но их я не пробовал), если так хочется вебморды.
Так же решил посмотреть подробнее правила, у вас ошибка:
К тому же Webmin является плохим выбором, т.к. любит ломать конфиги, пишет их абсолютно нечитаемым для человека способом и вообще работает не очень стабильно. И хоть вы предлагаете его использовать только в качестве мониторинга, другой человек, увидев богатство настроек Webmin, вполне может начать им редактировать что-то, а потом быть неприятно удивлен. Лучше уж поставить CentOS с Cockpit (есть и под deb-based дистрибутивы, но их я не пробовал), если так хочется вебморды.
Так же решил посмотреть подробнее правила, у вас ошибка:
http_access allow localnet CONNECT
http_access deny !Safe_ports - применится на всех. Применилось бы и на CONNECT, если бы не первое правило
http_access deny CONNECT !SSL_ports - уже не применится, т.к. первое allow правило разрешило все для CONNECT
*правила применятся, конечно, но т.к. целевая acl группа у нас localnet, то для нее эти правила действовать не будут
1. how-to в стиле копипаста, верно. Читайте «Введение» в котором указано, для кого статья. Зачем учителям информатики подробное описание действий? Краткого вполне достаточно.
2. Про Webmin, да спорная штука. Однако, очень удобно, когда необходимо срочно что-то поправить в конфигах, а ты находишься далеко от терминала (другой конец школы, например).
3. По правилам — с тем, что есть, все работает. Если убрать мое правило (остальные же по умолчанию), то HTTPS выдает ошибку сертификата. Почему? Не знать… Подозреваю, что это связано с маршрутизацией на проксю через микротик, так как на аналогичном сервере, но с настроенным DHCP (dnsmasq) и являющимся проксей и роутером одновременно, со стандартным конфигом без моего правила все работает нормально.
2. Про Webmin, да спорная штука. Однако, очень удобно, когда необходимо срочно что-то поправить в конфигах, а ты находишься далеко от терминала (другой конец школы, например).
3. По правилам — с тем, что есть, все работает. Если убрать мое правило (остальные же по умолчанию), то HTTPS выдает ошибку сертификата. Почему? Не знать… Подозреваю, что это связано с маршрутизацией на проксю через микротик, так как на аналогичном сервере, но с настроенным DHCP (dnsmasq) и являющимся проксей и роутером одновременно, со стандартным конфигом без моего правила все работает нормально.
1. Мне кажется, лучше хоть немного понимать что ты делаешь. Впрочем, я никого не виню, т.к. сам далеко не образец (посмотрите мою публикацию), это скорее посыл к тому, что на хабре было бы хорошо публиковать более расширенные гайды, т.к. остального полно на других ресурсах.
2. Ну, тут не поспоришь. А можно пример такой ситуации?
3. Действительно странно, смотрю на свой конфиг и у меня CONNECT фигурирует только в запрете портов, правда в моем случае прокси прописывается в системных настройках черех wpad и, соответственно, я обхожусь без ssl bump. Вообще, сквид бывает очень капризный, конечно. У меня есть подозрение, что
Если будет возможность, попробуйте.
2. Ну, тут не поспоришь. А можно пример такой ситуации?
3. Действительно странно, смотрю на свой конфиг и у меня CONNECT фигурирует только в запрете портов, правда в моем случае прокси прописывается в системных настройках черех wpad и, соответственно, я обхожусь без ssl bump. Вообще, сквид бывает очень капризный, конечно. У меня есть подозрение, что
http_access deny CONNECT !SSL_ports как-то мешает localhost, может еще где-то правила перекрывают. Поэтому предлагаю следующий конфиг, чтобы вынести все, что относится к самому серверу, за остальные правила и не давать им пересекаться:http_access allow localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access deny blacklist
http_access allow whitelist
http_access deny all worktime
http_access allow allЕсли будет возможность, попробуйте.
2. Например, у меня сервер для кабинетов информатики, о котором я писал с DHCP, стоит в одном из кабинетов, который находится достаточно далеко от моего кабинета. Были у него некоторые проблемы с доступом к одному сайту. я подключился через Webmin с одного из компов в кабинете и перенастроил, сразу все проверив. В противном случае мне пришлось бы бегать из кабинета в кабинет.
3. Завтра проверю. Кстати, если использовать редирект в микротике с помощью правил nat, то сквид блокирует все на свете, не принимая во внимание белый список. в логах на белый список вместо TCP_DENIED пишет TCP_MISS и выдает страницу запрета (http). Такое ощущение, что соединение зацикливается и блокируется. хотя правило на исключение зацикливания тоже присутствовало. странности невообразимые))
3. Завтра проверю. Кстати, если использовать редирект в микротике с помощью правил nat, то сквид блокирует все на свете, не принимая во внимание белый список. в логах на белый список вместо TCP_DENIED пишет TCP_MISS и выдает страницу запрета (http). Такое ощущение, что соединение зацикливается и блокируется. хотя правило на исключение зацикливания тоже присутствовало. странности невообразимые))
2. Я тут вспомнил, что у Cockpit есть так же доступ в консоль (у Webmin тоже есть, если не ошибаюсь). Так что можно через вебморду в консоль ходить) Жаль нормальную веб панель сквиду так и не придумали
3. А что за правило на исключение зацикливания? Можно увидеть?
3. А что за правило на исключение зацикливания? Можно увидеть?
2. Я так и делал. Только консоль там (в webmin) кривая. Файл открывается в новом окне. Сохраняется не по комбинации клавиш, а жмяканьем мыши на дискетку. После закрытия, приходится заново открывать консоль. Подлагивает еще к тому же. Но для срочной правки конфигов пойдет.
3. add chain=dstnat dst-port=80 protocol=tcp src-address=(squid). Такое же для 443 порта.
3. add chain=dstnat dst-port=80 protocol=tcp src-address=(squid). Такое же для 443 порта.
3. Там, кстати, не выходила с страница с предупреждением о незащищенном соединении с ошибкой NET::ERR_CERT_COMMON_NAME_INVALID?
Была и такая. Еще была ошибка подобная тоже по сертификату. Отличаются они тем, что одна не пускает вообще на сайт, а вторая дает выбор — там есть кнопка «Все равно перейти на сайт». Нажимаю на нее и он выдает страницу запрета Squid на другом языке. Странно, потому что все эти сайты должны открываться по https и не должны подменяться страницей запрета.
Проверил конфиг. http заработал как надо. https — ошибка сертификата ERR_CERT_AUTHORITY_INVALID.
Блин, как-то странно… По сути он пытается подменять сертификат, хотя конфиг это не делает… Видимо, с ssl_bump надо как-то по-другому работать с http_access. А если так?
http_access allow localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow CONNECT
http_access deny blacklist
http_access allow whitelist
http_access deny all worktime
http_access allow allОчень странно, но конфиг сработал. Странно, потому что deny выше allow и, по идее, должно отрабатывать правило deny, а allow уже игнорироваться.
У сквида в правилах условия соединяются логическим «И»
http_access deny CONNECT !SSL_ports — запретить, если клиент соединяется методом connect И порт соединения не в списке SSL_ports
Поэтому все, что не попадает под deny, разрешается следующим правилом.
А ошибка сертификата похоже из-за того, что http_access нельзя в прозрачном режиме применить к https, сквид этого просто не может, и браузер интерпретирует дальнейшие попытки переправлений от сквида, как mitm. Поэтому вывод этого трафика из дальнейшей обработки правилом http_access allow CONNECT сработал, и он ушел на обработку в ssl_bump. Впрочем, в непрозрачном режиме такой проблемы нет. Так что если настроите wpad, можете смело отказываться от ssl_bump за ненадобностью.
Кстати, могу посоветовать использовать в ACL правилах dstdomain вместо url_regex. Регулярки нужны, если блочится конкретная ссылка (а в https без mitm этого не получится), а не весь сайт. Обработка регулярок в целом всегда медленней и по нагрузке тяжелее. Ну и в ssl правилах тоже перейти на ssl::server_name без regex. Да и записывать сайты проще, нет лишнего мусора, например: .google.com. Но это, конечно, если вы не блочите прямые ссылки по http, хотя сейчас сайтов без шифрования почти нет.
http_access deny CONNECT !SSL_ports — запретить, если клиент соединяется методом connect И порт соединения не в списке SSL_ports
Поэтому все, что не попадает под deny, разрешается следующим правилом.
А ошибка сертификата похоже из-за того, что http_access нельзя в прозрачном режиме применить к https, сквид этого просто не может, и браузер интерпретирует дальнейшие попытки переправлений от сквида, как mitm. Поэтому вывод этого трафика из дальнейшей обработки правилом http_access allow CONNECT сработал, и он ушел на обработку в ssl_bump. Впрочем, в непрозрачном режиме такой проблемы нет. Так что если настроите wpad, можете смело отказываться от ssl_bump за ненадобностью.
Кстати, могу посоветовать использовать в ACL правилах dstdomain вместо url_regex. Регулярки нужны, если блочится конкретная ссылка (а в https без mitm этого не получится), а не весь сайт. Обработка регулярок в целом всегда медленней и по нагрузке тяжелее. Ну и в ssl правилах тоже перейти на ssl::server_name без regex. Да и записывать сайты проще, нет лишнего мусора, например: .google.com. Но это, конечно, если вы не блочите прямые ссылки по http, хотя сейчас сайтов без шифрования почти нет.
Очень понятно объяснили работу Squid. Благодарю.
Про dstdomian подумаю, потестирую, но пока так, как есть.
Подскажите, пожалуйста, как записать регулярку для Squid, чтобы заблокировать (или открыть), к примеру, example.com/route/index.php (или любую другую отдельную страницу на сайте)
Про dstdomian подумаю, потестирую, но пока так, как есть.
Подскажите, пожалуйста, как записать регулярку для Squid, чтобы заблокировать (или открыть), к примеру, example.com/route/index.php (или любую другую отдельную страницу на сайте)
Я бы написал как-то так:
Вот тут можно проверить выражения
Но, как я говорил выше, без подмены сертификата это будет работать только на http
(\w+\.)*example\.com\/route\/index\.phpВот тут можно проверить выражения
Но, как я говорил выше, без подмены сертификата это будет работать только на http
Сочувствую нынешним школьникам.
Все это можно было сделать на Mikrotik с его прозрачным прокси и контентной фильтрацией
1. Микротик и его прозрачный прокси не работают с HTTPS.
2. Даже если делать фильтрацию фаерволом, используя домены в address list, то не откроются сайты типа Ютуба и Вк. Точнее они откроются, но на Ютубе не будет ни одного видео, а в вк — картинок. Почему? Посмотрите, где хранит свои видео Ютуб и картинки — вк.
3. Поверьте, я пробовал.
2. Даже если делать фильтрацию фаерволом, используя домены в address list, то не откроются сайты типа Ютуба и Вк. Точнее они откроются, но на Ютубе не будет ни одного видео, а в вк — картинок. Почему? Посмотрите, где хранит свои видео Ютуб и картинки — вк.
3. Поверьте, я пробовал.
UFO just landed and posted this here
1) WPAD избавляет от головняка с поддержкой SSL в Squid.
2) В nano сохранять файл вызывая закрытие? Чта? У вас ctrl или o вырваны из клавиатуры?
3) Зачем привязывать комп к ip адресу, если можно в настройках клиента по маку выставить нужный addresslist?
2) В nano сохранять файл вызывая закрытие? Чта? У вас ctrl или o вырваны из клавиатуры?
3) Зачем привязывать комп к ip адресу, если можно в настройках клиента по маку выставить нужный addresslist?
1. WPAD геморнее ставить. Но не спорю — с ним было бы меньше проблем. Я не стал заморачиваться.
2. Зачем совершать 2 действия, когда можно совершить одно? Если нажать ctrl+o мы сохраним файл а потом опять ctrl+x чтобы закрыть. Или один раз ctrl+x и сразу сохранить, раз все равно закрывать файл. Экономия времени.
3. Какого клиента, простите? В микротике в адресс-лист не добавить мак.
2. Зачем совершать 2 действия, когда можно совершить одно? Если нажать ctrl+o мы сохраним файл а потом опять ctrl+x чтобы закрыть. Или один раз ctrl+x и сразу сохранить, раз все равно закрывать файл. Экономия времени.
3. Какого клиента, простите? В микротике в адресс-лист не добавить мак.
1) Поднять lighttpd сервер со статичными данными и в микротике прописать опцию DHCP… по мне, так геморройнее организовывать прозрачный перехват https трафика… к тому же позволяет избавиться от squid (имея флешку. флешку в микротик)
2) «Чтобы сохранять файл в nano, необходимо нажать Ctrl+X и следом Y.»
Ещё раз. Вы утверждаете, что сохранить файл можно лишь закрыв его. Не надо так.
3) /ip dhcp-server lease add address-list=«admins» mac-address=«aa:aa:aa:aa:aa:aa» address=pool1…
Пункт 3.4.б просто дополнить: сразу же указать address-list. и тогда надобность в привязке адреса отпадает
Сразу извинюсь: читал пост по диагонали. Сам в прошлом году на коленке ради прикола поднял следующую щщтуку:
В микротик подключил флешку и настроил родной прокси. На ту же флешку закинул образ openwrt/ С помощью MetaRouter на OpenWRT поднял lighttpd. На ём настроил WPAD. На микротиковском DHCP принудительно подсовываю WPAD и всё. Все лезут принудительно и «прозрачно» через прокси.
Если мне не изменяет память, я там ещё Hotspot прикручивал, но это не точно. Точно, что связка mikrotik proxy + WPAD гарантированно работа(ло)ет
2) «Чтобы сохранять файл в nano, необходимо нажать Ctrl+X и следом Y.»
Ещё раз. Вы утверждаете, что сохранить файл можно лишь закрыв его. Не надо так.
3) /ip dhcp-server lease add address-list=«admins» mac-address=«aa:aa:aa:aa:aa:aa» address=pool1…
Пункт 3.4.б просто дополнить: сразу же указать address-list. и тогда надобность в привязке адреса отпадает
Сразу извинюсь: читал пост по диагонали. Сам в прошлом году на коленке ради прикола поднял следующую щщтуку:
В микротик подключил флешку и настроил родной прокси. На ту же флешку закинул образ openwrt/ С помощью MetaRouter на OpenWRT поднял lighttpd. На ём настроил WPAD. На микротиковском DHCP принудительно подсовываю WPAD и всё. Все лезут принудительно и «прозрачно» через прокси.
Если мне не изменяет память, я там ещё Hotspot прикручивал, но это не точно. Точно, что связка mikrotik proxy + WPAD гарантированно работа(ло)ет
1. Идея с флешкой интересна, но, считаю, что будет нестабильна, когда на такую систему будет обращаться большое количество клиентов. А выдержит ли сам микротик? Ведь, как я понял, вы использовали ресурсы самого роутера. В любом случае, отдельный сервер надежней и стабильней.
2. Пожалуй, вы правы. Статью поправил.
3. Действительно, так получается более разумно. Но есть пара моментов: а) статья все-таки для учителей информатики. про IP они в курсе, а вот про MAC-адреса… может и в курсе, но для них «многабуков» сложнее. б) я делаю привязку всех своих IP-адресов, потому что мониторю сеть через Dude по IP, а аренда часто заканчивается, так как компы бывают выключены неделями (особенно летом), поэтому и написал, как делал сам.
2. Пожалуй, вы правы. Статью поправил.
3. Действительно, так получается более разумно. Но есть пара моментов: а) статья все-таки для учителей информатики. про IP они в курсе, а вот про MAC-адреса… может и в курсе, но для них «многабуков» сложнее. б) я делаю привязку всех своих IP-адресов, потому что мониторю сеть через Dude по IP, а аренда часто заканчивается, так как компы бывают выключены неделями (особенно летом), поэтому и написал, как делал сам.
3. а) привязка по ip происходит как раз исходя из mac адреса. Всё, чем отличается мой метод от предложенного вами, это
— Не добавлять вручную хост к адрес личту со статическим ip
— В DHCP Lease в поле адреса указать пул, а в поле address-list нужный лист.
б) Плохая практика привязываться к ip. Советую переходить на Hostname.
— Не добавлять вручную хост к адрес личту со статическим ip
— В DHCP Lease в поле адреса указать пул, а в поле address-list нужный лист.
б) Плохая практика привязываться к ip. Советую переходить на Hostname.
Также пункты 3.в и 3.г
По-моему, поля перепутаны: в General разрешаем (у вас Mangle), а в Mangle маркируем (у вас general)
По-моему, поля перепутаны: в General разрешаем (у вас Mangle), а в Mangle маркируем (у вас general)
Нет, все верно. В Ip-Firewall есть вкладка Mangle куда мы добавляем маркировку пакетов (на скриншоте она). В окне добавления нового правила есть вкладки general. action и тд. В пункте г) подразумевается, что мы уже находимся в IP-Firewall-Mangle
У вас разрешающие правила во вкладке Mangle, а маркировка в General…
Вот, я отсюда брал информацию. docs.diladele.com/tutorials/mikrotik_transparent_squid/mangling.html. Там более подробно со скриншотами. (в списке источников указано, если что)
Mangle это вкладка в самом IP-Firewall, а general первая вкладка в окне добавления нового правила для mangle Сама маркировка на вкладке action=mark routing и далее.
Правила в пункте В) разрешают принятие трафика от прокси.
Mangle это вкладка в самом IP-Firewall, а general первая вкладка в окне добавления нового правила для mangle Сама маркировка на вкладке action=mark routing и далее.
Правила в пункте В) разрешают принятие трафика от прокси.
и 6.4 — WPAD
Поясню в чём проблема. Вы заворачиваете необходимый трафик (порты 80 и 443) на прокси сервер через таблицу маршрутизации. То есть пакет идёт так:
Клиент — Шлюз (микротик) — Прокси
А должен
Клиент — Прокси.
Добиться это можно двумя способами:
1) Заворачивать необходимый трафик не с помощью таблицы маршрутизации, а перенаправляя трафик (redirect в NAT). Не уверен на все 100%, что будет верно отрабатывать ip клиента, но, по логике вещей, должно. Это называется прозрачный прокси сервер. При этом SSL могут не работать, так как сертификат принадлежит вашему прокси, а не сайту. Теоретическая атака MiM. Для клиента это может быть заметно.
2) Использовать явно прокси сервер. Опять два варианта:
а) На каждом клиенте явно прописать прокси сервер.
б) Использовать WPAD. Информации достаточно много. В двух словах: WPAD — это автоматические настройки прокси серверов для клиентов. Теоретическая атака MiM.
При «явном» использовании прокси сервера у клиента не возникает проблем с «подменным» сертификатом, так как это нормальная работа прокси сервера. А значит, что клиент даже не будет догадываться, что работает через прокси!
Поясню в чём проблема. Вы заворачиваете необходимый трафик (порты 80 и 443) на прокси сервер через таблицу маршрутизации. То есть пакет идёт так:
Клиент — Шлюз (микротик) — Прокси
А должен
Клиент — Прокси.
Добиться это можно двумя способами:
1) Заворачивать необходимый трафик не с помощью таблицы маршрутизации, а перенаправляя трафик (redirect в NAT). Не уверен на все 100%, что будет верно отрабатывать ip клиента, но, по логике вещей, должно. Это называется прозрачный прокси сервер. При этом SSL могут не работать, так как сертификат принадлежит вашему прокси, а не сайту. Теоретическая атака MiM. Для клиента это может быть заметно.
2) Использовать явно прокси сервер. Опять два варианта:
а) На каждом клиенте явно прописать прокси сервер.
б) Использовать WPAD. Информации достаточно много. В двух словах: WPAD — это автоматические настройки прокси серверов для клиентов. Теоретическая атака MiM.
При «явном» использовании прокси сервера у клиента не возникает проблем с «подменным» сертификатом, так как это нормальная работа прокси сервера. А значит, что клиент даже не будет догадываться, что работает через прокси!
Спасибо за разъяснение! Я в принципе догадывался, что оно так.
NAT я ковырял. Нашел правила для него, по логике, должны были работать. Проверил и в итоге блокировка всех сайтов даже из белого списка и http и https.
Правила таковы.
add chain=dstnat dst-port=80 protocol=tcp src-address=(squid)
add action=dst-nat chain=dstnat dst-port=80 protocol=tcp src-address=(наша_сеть) to-addresses=(squid) to-ports=3128
add action=src-nat chain=srcnat dst-address=(squid) dst-port=3128 protocol=tcp to-addresses=(mikrotik)
Такие же для 443 порта.
В логах на белый список реакция TCP_MISS и блок страница. IP почему то микротика (шлюза).
Пробовал выносить сервер в отдельную подсеть, добавив ее к интерфейсу локалки, и использовать одно правило.
add action=dst-nat chain=dstnat dst-port=80 protocol=tcp src-address=(наша_сеть) to-addresses=(squid_подсеть) to-ports=3128
Для 443 соответственное.
Так http отрабатывал нормально, а https, как вы и сказали, дает ошибку сертификата.
Буду ковырять WPAD. Как закончу, либо дополню статью, либо добавлю еще одну. Но пока рабочий вариант таков. Еще раз спасибо за помощь :)
NAT я ковырял. Нашел правила для него, по логике, должны были работать. Проверил и в итоге блокировка всех сайтов даже из белого списка и http и https.
Правила таковы.
add chain=dstnat dst-port=80 protocol=tcp src-address=(squid)
add action=dst-nat chain=dstnat dst-port=80 protocol=tcp src-address=(наша_сеть) to-addresses=(squid) to-ports=3128
add action=src-nat chain=srcnat dst-address=(squid) dst-port=3128 protocol=tcp to-addresses=(mikrotik)
Такие же для 443 порта.
В логах на белый список реакция TCP_MISS и блок страница. IP почему то микротика (шлюза).
Пробовал выносить сервер в отдельную подсеть, добавив ее к интерфейсу локалки, и использовать одно правило.
add action=dst-nat chain=dstnat dst-port=80 protocol=tcp src-address=(наша_сеть) to-addresses=(squid_подсеть) to-ports=3128
Для 443 соответственное.
Так http отрабатывал нормально, а https, как вы и сказали, дает ошибку сертификата.
Буду ковырять WPAD. Как закончу, либо дополню статью, либо добавлю еще одну. Но пока рабочий вариант таков. Еще раз спасибо за помощь :)
Если у Вас в прозрачном режиме домены с белого списка ругаются на сертификат, то посмотрите лог сквида cache.log, там скорее всего присутствуют записи
Если это так, то это фитча (не баг) сквида, в плане безопасности и вот тут есть лекарство для этого, но придётся пересобирать пакет. Этот патч работает в том числе и на 4.8 версии.
SECURITY ALERT: Host header forgery detected on ... (local IP does not match any domain IP)Если это так, то это фитча (не баг) сквида, в плане безопасности и вот тут есть лекарство для этого, но придётся пересобирать пакет. Этот патч работает в том числе и на 4.8 версии.
Сейчас не ругаются. Ругаются, только если перенаправление nat-ом делать.
А Вам и не нужно nat-ить пакеты на http/https портах, их нужно перенаправлять (если микрот в такое умеет, проверить нет и не скоро появится возможность) на сквид. Но сразу тогда исключить на микроте пакеты с сквида, иначе получится цикл, между микротом и сквидом.
Выше в моем комменте правила на перенаправление пакетов с помощью nat на проксю. И правило на исключение цикла присутствует. Это без маршрутизации. С маршрутизацией вариант в статье.
Других вариантов перенаправления пакетов я не встречал.
Микротик построен на базе линуксового фаервола, следовательно, должен уметь все, что умеет линукс.
В любом случае, я попробовал ваше предложение по замене шлюза у DHCP сервера на микроте, и в логах появились нормальные IP. Создал и проверил списки — все работает. Ни ошибок сертификата, никаких глюков. Только придется побегать по клиентам, сменить сеть с общественной обратно на рабочую)) Также, я смогу отказаться от второго сервера для кабинетов информатики, и сделать их списком.
Благодарю)
Других вариантов перенаправления пакетов я не встречал.
Микротик построен на базе линуксового фаервола, следовательно, должен уметь все, что умеет линукс.
В любом случае, я попробовал ваше предложение по замене шлюза у DHCP сервера на микроте, и в логах появились нормальные IP. Создал и проверил списки — все работает. Ни ошибок сертификата, никаких глюков. Только придется побегать по клиентам, сменить сеть с общественной обратно на рабочую)) Также, я смогу отказаться от второго сервера для кабинетов информатики, и сделать их списком.
Благодарю)
не за что благодарить, сам при помощи хабра познавал эту науку.
как совет глянуть логику в конфиге, а именно тут
я бы убрал бы 3-ю строку, а 4-ю переделал бы так
т. к. белый список нам разрешён всегда, то и запрещать его не нужно и строка говорит блокировать всё в рабочее время кроме белого списка.
и последняя строка говорит, что устанавливать все соединения, что не вошли в предыдущие правила.
если в рабочее время вообще всё запрещено, тогда и разрешающее правило для белого списка не нужно.
как совет глянуть логику в конфиге, а именно тут
ssl_bump peek step1
ssl_bump terminate blacklist_ssl
ssl_bump splice whitelist_ssl
ssl_bump terminate all worktime
ssl_bump splice allя бы убрал бы 3-ю строку, а 4-ю переделал бы так
ssl_bump terminate all worktime !whitelist_sslт. к. белый список нам разрешён всегда, то и запрещать его не нужно и строка говорит блокировать всё в рабочее время кроме белого списка.
и последняя строка говорит, что устанавливать все соединения, что не вошли в предыдущие правила.
если в рабочее время вообще всё запрещено, тогда и разрешающее правило для белого списка не нужно.
для использования сквида не нужно подменять сертификат и явно указывать настройки прокси у клиента, достаточно собрать сквид с поддержкой ssl, что автор и сделал, указать сквиду порт прозрачного проксирование и обычными средствами firewall зарулить трафик на нужные порты, что так же автор сделал. Возможны какие-то отличия настройки микротов от ipfw могут быть. У меня на боевом рабочем сервере все пакеты с локального интефейса по портам 80, 8080, 443 заруливаются на локалхост и оттуда уже на сквид.
ну или на крайний случай, в самом микроте в DHCP сервере указать скивд в качестве шлюза.
тогда решится и ещё одна проблема автора, что в локах сквида только ip микротика.
ну или на крайний случай, в самом микроте в DHCP сервере указать скивд в качестве шлюза.
тогда решится и ещё одна проблема автора, что в локах сквида только ip микротика.
При «явном» использовании прокси сервера у клиента не возникает проблем с «подменным» сертификатом, так как это нормальная работа прокси сервера. А значит, что клиент даже не будет догадываться, что работает через прокси!
Неверно, проблема с сертификатом никуда не денется. Проблема уйдет только потому, что сквид сможет блочить сайты по http_access правилам, т.к. клиент будет явно передавать запрашиваемый домен прокси серверу и сквиду не придется выдирать его из https трафика. Соответственно, ssl_bump будет в принципе не нужен.
1. Зачем собирать старый сквид, когда уже доступен 4.8, исправно работающий?
2. Надеюсь Вы не столкнулись с проблемой, когда браузер на домены в белом списке ругается на недействительные сертификаты. Пример с тем же mail.ru Сам сайт открывается, а вот вложения, авторизация, выход выдают «ERR_SSL_PROTOKOL_ERROR». Это болезнь сквида с версий, когда появилась директива ssl-bump. Решением которой будет патч указанный в этой статье.
3. По конфигу сквида, не вижу, где Вы разрешили себе ходить во всюду, а остальным ходить нельзя. Можно добавить пару ACL типо admin, teachers, students, servers в которых указаны соответствующие ip или сразу диапазоны ip (например 192.168.1.12-192.168.1.58). И соответственно прописать запреты/разрешения в http_access и в ssl_bump кому по какому списку ходить (например: ssl_bump terminate students !admin blacklist_ssl)
4. строка «ssl_bump splice whitelist_ssl» абсолютно не нужна, т. к. основным правило идёт разрешить всё, что не запрещено, а именно «ssl_bump splice all»
PS. На работе использую сквида 4.8 собранного на freebsd 11.2 (основной GW), Debian 9 (тестовый GW) и у пары знакомых на Debian 9 в качестве детского firewall.
2. Надеюсь Вы не столкнулись с проблемой, когда браузер на домены в белом списке ругается на недействительные сертификаты. Пример с тем же mail.ru Сам сайт открывается, а вот вложения, авторизация, выход выдают «ERR_SSL_PROTOKOL_ERROR». Это болезнь сквида с версий, когда появилась директива ssl-bump. Решением которой будет патч указанный в этой статье.
3. По конфигу сквида, не вижу, где Вы разрешили себе ходить во всюду, а остальным ходить нельзя. Можно добавить пару ACL типо admin, teachers, students, servers в которых указаны соответствующие ip или сразу диапазоны ip (например 192.168.1.12-192.168.1.58). И соответственно прописать запреты/разрешения в http_access и в ssl_bump кому по какому списку ходить (например: ssl_bump terminate students !admin blacklist_ssl)
4. строка «ssl_bump splice whitelist_ssl» абсолютно не нужна, т. к. основным правило идёт разрешить всё, что не запрещено, а именно «ssl_bump splice all»
PS. На работе использую сквида 4.8 собранного на freebsd 11.2 (основной GW), Debian 9 (тестовый GW) и у пары знакомых на Debian 9 в качестве детского firewall.
Можно обойтись и без прокси.
Шаги:
1) /ip firewall nat add chain=srcnat out-interface-list=WANs src-address-list=teachers action=masquerade disabled=no
2) /ip firewall nat add chain=srcnat out-interface-list=WANs dst-address-list=whitelist action=masquerade disabled=no
3) /ip firewall address-list add list=whitelist address=<разрешённое доменное имя> disabled=no
4) /ip dhcp-server lease add mac-address=<учительский mac> address=<пул адресов> address-lists=teachers disabled=no
Смысл сказанного:
1) Маскарадим только учителей. То есть те компы, которые указаны в листе teachers могут ходить тудыть-сюдыть как умеют и могут. Прошу заметить, что я маскаражу по interface-list. Я привых все интерфейсы я загоняю в бриджи, а бриджи раскидываю по листам. удобно и красиво. Особенно при мультиване.
2) Маскарадим всех остальных только на те адреса, которые разрешены (а списке whitelist). Остальное просто не пройдёт.
3) В address list добавляем разрешённые сайты
4) Заносим учительские компы в список учителей
В винбоксе это делается проще. клац-клац и маскарад…
Шаги:
1) /ip firewall nat add chain=srcnat out-interface-list=WANs src-address-list=teachers action=masquerade disabled=no
2) /ip firewall nat add chain=srcnat out-interface-list=WANs dst-address-list=whitelist action=masquerade disabled=no
3) /ip firewall address-list add list=whitelist address=<разрешённое доменное имя> disabled=no
4) /ip dhcp-server lease add mac-address=<учительский mac> address=<пул адресов> address-lists=teachers disabled=no
Смысл сказанного:
1) Маскарадим только учителей. То есть те компы, которые указаны в листе teachers могут ходить тудыть-сюдыть как умеют и могут. Прошу заметить, что я маскаражу по interface-list. Я привых все интерфейсы я загоняю в бриджи, а бриджи раскидываю по листам. удобно и красиво. Особенно при мультиване.
2) Маскарадим всех остальных только на те адреса, которые разрешены (а списке whitelist). Остальное просто не пройдёт.
3) В address list добавляем разрешённые сайты
4) Заносим учительские компы в список учителей
В винбоксе это делается проще. клац-клац и маскарад…
У меня смысл в том, что фильтровать надо ВСЕ компы, включая учительские, т.к. прокуратура может зайти в любой кабинет и проверить там комп (да, это до безумия глупо, т.к. компы там учительские, но спорить с прокуратурой — себе дороже).
Далее по предложенному вами — я так понял, вы имеете ввиду адрес лист по доменному имени (микротики с 6.3, вроде, версии прошивки могут сами искать ip по домену в листе). Я это уже пробовал (очень мне не хотелось делать сервер....). Проблема в том, что учителям нужен ютуб, а он хранит фрагменты видео на сайте googlevideo.com. Сами фрагменты имеют свой уникальный адрес в формате абракадабра.googlevideo.com. Исходя из этого, даже если добавить googlevideo.com по имени в адрес лист, он найдет ip этого домена, но все, что находится перед этим доменом, он будет блокировать. Я так понял, у всех фрагментов видео свои ip адреса. На практике это вылазит в разблокировку ютуба, как сайта, но все видео будут блокироваться (в консоле разработчика в хроме идут бесконенчые дропы с адресов типа абракадабра.googlevideo.com). Та же история и с картинками в ВК.
Только я использовал для этого фаервол а не nat с маскарадом (правило в фаерволе с action=tcp reject или drop для всех сайтов, кроме address list)
К тому же у этого способа был и еще один минус — высокая нагрузка на роутер. Были моменты, когда он не сразу находил IP в address list, подвисал и начинал выпендриваться (список то большой — около 1500 адресов). Помогала перезагрузка роутера, но это же не дело…
Далее по предложенному вами — я так понял, вы имеете ввиду адрес лист по доменному имени (микротики с 6.3, вроде, версии прошивки могут сами искать ip по домену в листе). Я это уже пробовал (очень мне не хотелось делать сервер....). Проблема в том, что учителям нужен ютуб, а он хранит фрагменты видео на сайте googlevideo.com. Сами фрагменты имеют свой уникальный адрес в формате абракадабра.googlevideo.com. Исходя из этого, даже если добавить googlevideo.com по имени в адрес лист, он найдет ip этого домена, но все, что находится перед этим доменом, он будет блокировать. Я так понял, у всех фрагментов видео свои ip адреса. На практике это вылазит в разблокировку ютуба, как сайта, но все видео будут блокироваться (в консоле разработчика в хроме идут бесконенчые дропы с адресов типа абракадабра.googlevideo.com). Та же история и с картинками в ВК.
Только я использовал для этого фаервол а не nat с маскарадом (правило в фаерволе с action=tcp reject или drop для всех сайтов, кроме address list)
К тому же у этого способа был и еще один минус — высокая нагрузка на роутер. Были моменты, когда он не сразу находил IP в address list, подвисал и начинал выпендриваться (список то большой — около 1500 адресов). Помогала перезагрузка роутера, но это же не дело…
Был найден неиспользуемый стационарный компьютер с двух-ядерным Intel-ом, 1 Гб ОЗУ и жестким на 80 Gb.
Мой Вам совет — pfsense\opnsense. Есть всё — и squid и vpn неск-ких типов и IDPS и много-много всего.
Вот, напр., настройка OpenVPN + OSPF — forum.netgate.com/topic/147028/два-провайдера-и-openvpn-клиент/92
Пользуйте forum.netgate.com/topic/120102/proxmox-ceph-zfs-pfsense-и-все-все-все
Sign up to leave a comment.
Контентная фильтрация в школе на основе Ubuntu 18.04 и прозрачного Squid, с интеграцией в сеть на MikroTik и не только