На каком ПО раздавать, мониторить и управлять доступом интернет?
Стоит сервер Microsoft Windows Server 2012 r2 с ролью Active Directory, нужно всех пользователей в сети подключить к интернету, управлять доступом к определенным ресурсам и чтобы был NAT, желательно со встроенным прокси сервером. Есть WinGate, Kerio, Lan2Net, Trafic Inspector? но они платные, есть ли что нибудь такое подешевле или Freeware.
А может можно встроенными средствами Microsoft Windows Server 2012 r2, если да то как
я так думаю что Hyper-V решит проблему, AD установить на физическом железе, а раздавать с виртуальной в качестве ОС думаю установить Linux. Ну или наоборот, надо почитать как лучше, в данное время планирую, сам сервер придет через 2 недели и надо основательно подговиться
Подключать всех пользователей корпоративной сети через NAT к сети интернет это ИМХО очень плохая идея, УИБ в нашей организации за такое к стенке бы поставил. Думаю тут нужно пересмотреть сам подход и уже после решать какие инструменты лучше использовать. В подавляющем большинстве случае достаточно обычного прокси сервера.
Александр Воробьев: если под правилами считать только белый или черный список то из бесплатных знаю handycache, пользуюсь уже года 2. Есть поддержка пользователей.
Артем: NAT это в некотором смысле "прямое" подключение к сети и при определенной сноровке двухстороннее подключение, что крайне негативно сказывается на безопастности всего, что есть в сети. Подключение же "снаружи" при использовании прокси сервера практически исключено.
Виталий Пухов: А как же тогда подключать веб сервера к сети? тоже через прокси?
Безопасность нужна там где она нужна, и ее можно настроить независимо от типа подключений.
В некоторых организациях на всех компьютерах просто стоят белые адреса, и никаких нат и прокси.
В некоторых используют нат (чаще всего)
Изредка используют прокси. Я например его использую очень редко.
Поэтому правильное решение - это маршрутизация.
Решение с вынужденными костылями - NAT.
И самое ужасное что можно придумать это прокси, это уж крайний случай.
Артем: в общем то согласен, если на компьютерах в сети нет клиенских данных а только фотки с котятами то проблемы особой нет, в таком случае не вижу причин вообще что либо ограничивать, обычно ограничения создают чтобы предотвратить утечку данных или бесконтрольный доступ к сомнительным ресурсам, тут все решается на уровне прокси легко. для подключение ресурсов локальный сети к внешней (чтобы был доступ к ним извне) обычно создают DMZ (ru.wikipedia.org/wiki/DMZ_(%D0%BA%D0%BE%D0%BC%D0%BF%D1%8C%D1%8E%D1%82%D0%B5%D1%80%D0%BD%D1%8B%D0%B5_%D1%81%D0%B5%D1%82%D0%B8)) в которой уже крутится сервер, тем самым внутренняя сеть остается изолированной от внешней сети, в самом тупом и дешевом варианте для этого достаточно в веб сервер воткнуть вторую сетевую карту и ее подключать к интернету.
Виталий Пухов: Да почему же фотки с котятами?
Нормальные рабочие сети, с довольно конфиденциальной информацией.
Просто при чем тут нат или прокси?
Вот смотрите - в первую очередь делается подключение желательно чтобы у всех были белые адреса, если не получается, то нат, если совсем все печально прокси.
Это мы сделали подключение, о безопасности вообще речи не идет.
А вот когда подключение к интернету есть, надо обеспечить безопасность.
Она обеспечивается как правило на шлюзе. Режется нежелательный трафик, блокируются порты и прочее.
А какой тип подключения - роутинг, прокси, или впн большой роли не играет, и на безопасность никак не влияет.
Артем: не соглашусь, скажем если есть только маршрутизация и я как умный вася "разрешу только вебстранички смотреть" то есть открою 80 порт, что делает умный недоброжелатель, открывает по ssh тунель на свой сервер по 80 порту (ssh без разницы на каком порту крутиться) и сливает к себе всю клиенскую информацию. Что обстоит с прокси, на стороне прокси можно настроить все(зависит от сервера конечно), например фильтрация по содержимому, проксе не даст "передать" контент в внешний сервер (см mcaffe web gateway к примеру). Второй момент, через прокси нельзя иницировать подключение с внешней сети, а значит любые попытки проникнуть извне невозможны впринципе, пройти за NAT вполне можно, если очень постараться. И третий момент, я понимаю что потеря клиентских данных не всеми организациями воспринимается как чтото страшное, но это до первого же конфликта с потерей доверия клиентов, поэтому безопастность должна быть на первом месте, удобность на последнем. "Вот смотрите - в первую очередь делается подключение желательно чтобы у всех были белые адреса, если не получается, то нат, если совсем все печально прокси." - этот подход может быть для домашнего компьютера, но не для организации.
Такие моменты-
А как работать пользователям с SSH тогда? Или у вас юзеры не используют SSH?
Как прокси отследит сливаемый контент, если он предварительно зашифрован?
За NAT проникнуть так же невозможно извне как и за прокси.
По поводу безопасности данных - данные бывают очень разные, и защищать их надо по разному.
В некоторых случаях - проходная с металлодетектором, вход на территорию только после переодевания в рабочую одежду, полный запрет на внос личных вещей на территорию предприятия, просмотр документов только на компьютере абсолютно изолированном от сети.
Все это под наблюдением сотрудников СБ.
Во многих организациях так все и организованно.
Но скажите - оно всем надо, вот так жестко?
А использование прокси это полумеры, даже школьник стырит информацию которая защищена прокси.
Вообще передачу информации наружу, невозможно блокировать никакими программными ухищрениями.
Максимум чего можно добиться, так это сделать слив информации менее удобным для злоумышленника.
Все работающие решения по блокировке утечек информации не имеют ничего общего с IT, все делается исключительно административными методами.
Артем: у нас пользователи для работы по ssh из внешней сети используют отдельный терминальный сервер, данные на который скопировать нельзя, доступы ограничиваются на уровне vlan.
Если инициатор "утечки данных" находится во внутренней сети отследить и заблокировать данные за Nat будет невозможно, прокси же может сканировать данные по сигнатуре и шифрование тут ничем не поможет, если сигнатура архива к примеру, то передать данные не выйдет.
По поводу данных согласен, они разные бывают, но лучше сделать правильно, чем потом "школьники" будут воровать информацию. Так хоть от дурака защита будет.
Защита от дурака дело хорошее, но только когда оно не мешает пользователям работать.
Поэтому тут рецепт прост - нужно решать в каждом конкретном случае, без шаблонов.
Т.е не стоит советовать что прокси лучше чем нат, не изучив требования по безопасности, и условия работы конкретной организации.
Иначе можно вместо повышения безопасности, ее снижения.
Яркий пример-
Что безопаснее разрешить пользователю создать пароль вида "барсик", или обязать делать пароль вида "St*4^de'ArudwZ", чтобы и регистр и спецсимволы, и длина не менее 12символов?
Казалось бы длинный пароль намного безопаснее.
Но на практике пользователи с паролем "барсик" спокойно набирают его каждый раз по памяти, а у каждого пользователя с паролем "St*4^de'ArudwZ" висит стикер на мониторе, с этим самым паролем.
Ну чтобы не забыть.
В итоге короткий и небезопасный пароль зачастую оказывается намного безопаснее правильного.
Ты создаешь пользователю неудобство, он его обходит самым естественным способом.
Я вот в данный момент бодаюсь с одной конторой, как раз по поводу прокси.
Был заказ поставить ПО с определенным функционалом - я озвучил что для корректной работы нужен компьютер с определенными характеристиками и доступ в интернет.
Приехал, выдали комп, поставил - интернета нет. Сказали завтра админы подключат.
Ну фиг с ними, воткнул флешку с йотой, протестировал - все работает отлично.
Теперь звонят - нифига не работает, так оно и правильно, мой софт не умеет работать через прокси, а доступ у них только через прокси.
Артем: про пароль соглашусь, находил анализ согласно которому пароль в виде пары тройки нормальных "человеческих" слов в виде пароля намного безопасней сочетаний закорючек. Про инстраграм не соглашусь, так можно слить десяток страничек, и то не факт, что сотрудника фотающего свой монитор не уволят раньше, утащить таким образом базу ПД клиентов в 10 Гб не получится, а с NAT легко. Но в целом согласен, нужно смотреть в контексте задачи, на счет прокси не соглашусь, особых проблем научить свой софт работать с прокси нет. Делал поддержку разных проксей и особых заморочек нет (для C# конечно, думаю на том же C++ это тот еще геморой).
