Zentyal Forum, Linux Small Business Server
International => Russian => Topic started by: Rekfuby on May 20, 2014, 11:38:59 pm
-
Требуется добавить в исключения прозрачного прокси локальный пул адресов (сегмент сети), тк прозрачный прокси игнорирует правила ограничение межсегментного трафика, есть у кого нить идеи как это можно сделать?
-
А разве "HTTP прокси"-"Исключения Прозрачного Прокси" - не об этом? Сам не пользуюсь, но звучит соответствующе...
-
"А разве "HTTP прокси"-"Исключения Прозрачного Прокси" - не об этом? Сам не пользуюсь, но звучит соответствующе..."
Он умеет работать только с доменными именами. но никак не с ip адресами...
-
Ну, как костыль - создать в DNS домен и обращаться к "внутренним" ресурсам по доменному имени - типа webka1.internal.lan
-
Мне нужно ограничить доступ всяких умников до веб интерфейсов сетевого оборудования, чтобы при этом у меня и моего сменщика оставался доступ и введение доменных имён в этом никак не поможет!
-
Мне нужно ограничить доступ всяких умников до веб интерфейсов сетевого оборудования,
Что у Вас за оборудование, где на входе нет запроса логина и пароля?)
Ну, а если все плохо, то можно в фаерволе заблочить доступ с адресов умельцев к боевым айпишникам по портам 80 и 443
-
Запрос на логин и пароль есть, вот только они умудряются вешать оборудование запросами и забивают логи на оборудовании занимаясь брутфорстом.
Фаервол не помогает в связи с тем что его правила игнорируются прокси сервером и запросы идут от его имени (читайте моё первое сообщение в теме).
-
Запрос на логин и пароль есть, вот только они умудряются вешать оборудование запросами и забивают логи на оборудовании занимаясь брутфорстом.
Школа или институт?
Организация - докладная начальнику и вычет премии с последующим увольнением за повторные трюки.
они умудряются вешать оборудование запросами
fail2ban - но никогда не было задачи внутри вылавливать и банить))
введение доменных имён в этом никак не поможет!
Почему же... Вы их добавите в список исключения прокси.
-
Колледж, поставили задачу обеспечивать бесперебойную работу гостевой беспроводной сети, а это несколько сотен просто прохожих в день, ловить и банить не то что не эффективно, а просто бессмысленно...
По доменным именам никто кроме меня и обращаться к этому оборудованию и не будет, а мне ещё запоминать 200 с лишним доменных имён не будет в удовольствие.
-
Колледж, поставили задачу обеспечивать бесперебойную работу гостевой беспроводной сети, а это несколько сотен просто прохожих в день, ловить и банить не то что не эффективно, а просто бессмысленно...
Хорошая статья про Вашу задачу:
http://www.lanmart.ru/blogs/mikrotik-hotspot
-
Бюджета на новые железки нет, а уже 12 точек доступа куплены и распиханы, некоторые даже замурованы в стены, персонал, студенты и гости уже распределены в разные вланы, так что данное решение мне точно не подходит!
-
По доменным именам никто кроме меня и обращаться к этому оборудованию и не будет, а мне ещё запоминать 200 с лишним доменных имён не будет в удовольствие.
Тут, имелось ввиду:
webka1.internal.lan - 10.0.0.2
webka1.internal.lan - подсунуть в прокси, по идее, не должен будет пускать как по доменному имени, так и по ip.
А Вам и не надо запоминать доменные имена, если помните ip )
студенты и гости уже распределены в разные вланы
Не совсем понял, чем не подходит решение на основе создания гостевого vlan?
-
При указании доменного имени прокси сервер блокирует запросы только к данному доменному имени, но никак не к IP адресам.
Гостевой влан создан и давным давно фаерволом (маршрутизатором) отделён от основной сети!
-
В моем понимании...когда у Вас подключаются к бесплатному wifi, юзера должны видеть только страницу авторизации.... какие либо попытки ввести 10.0.0.2 должны отправлять на страницу авторизации.
К сожалению, практикой помочь не могу, не стояло никогда задачи про Captive Portal
+ я бы в Вашей ситуации все равно настроил fail2ban и банил бы по маку нарушителей...
-
Передо мной такой задачи и не стоит, клиент подключается, его сама точка доступа и просит ознакомиться с правилами пользования, после чего выпускает в сеть, на данном этапе всё работает и всё прекрастно, но весь трафик идёт на прокси сервер который даёт возможность сделать шейпинг, блокировку ресурсов по списку и не хило экономит трафик, а особо умные додумываются при помощи данного прокси сервера ломиться к локальному оборудованию!
-
Окей.
Ещё один костыль - сделать гостям отдельный прокси-сервер (хоть на виртуалке), не имеющий доступа к локальной сети.
Хотя сквид, на сколько я помню, умел банить и по IP. Если найду старые конфиги, выложу синтаксис ACL (ибо за ненадобностью всё забыл).
Вот что нашёл на вскидку:
Если имя домена для IP-адреса было сохранено Сквидом в ``FQDN cache,'' то Squid может сравнивать домен назначения с контролем доступа. Однако, если домен недоступен немедленно, Squid разрешит запрос и сделает преобразование IP-адреса, которое будет доступно для будущих запросов.
http://squid.h12.ru/FAQ/FAQ-10.html#ss10.4
Так что идея с DNS-именами внутренних хостов вполне может сработать.
Ещё там же стоит обратить внимание на http://squid.h12.ru/FAQ/FAQ-10.html#ss10.11 - задача зеркальная, но логика подходящая. Правда, это уже не из вэбки Z настраивать придётся, а лезть в конфигурационные макрошаблоны Z...