Доступ в интернет в сложных административных условиях

в 9:39, , рубрики: linux, доступ в интернет, ит-инфраструктура, Песочница, Серверное администрирование, удалённый доступ, метки: , ,

Приветствую уважаемые,

Хотелось бы поделиться неким решением, которое все еще является в нашей компании экспериментальным, но малыми силами доводится до ума. Речь идет о коллективном доступе в Интернет, в условиях, когда интернет лучше пользователям не давать (в виду разных причин — организационных, технических, административных).

До сего момента в мы внедряли достаточно распространенную схему доступа. А именно:

  • Выделенный прокси-сервер (squid, без вариантов), который собственно и связывал, в общих словах, сеть внутреннюю с интернетом.
  • SAMS2 — решения для создания шаблонов и политик доступа в интернет.
  • Контроллер домена (samba+ldap)

Интегрируя эти три компонента получали неплохое сочетание удобства и надежности. Более того, этот способ многим будет подходить и до сих пор, но для нас реалии диктуют другие правила. Пока есть интернет на рабочем месте, есть вероятность утечки информации (способов уйма, хотите поспорить — welcome to comments..).

И было решено оставить доступ в интернет, но убрать его с рабочих машин o_O. В своей работе мы активно используем Linux (обычно это CentOS 4-5-6) и удаленный доступ. Это совершенно разные технологии, для каждой своя сфера применения и мы активно пользуемся каждым решением исходя из поставленной задачи.

  • ssh с его туннелями позволяет делать практически все, что угодно. Если не требуется большего;
  • RDP;
  • HP Remote Graphic Software (HP RGS) иногда надо и такое;
  • FreeNX

Вот с помощью последней и решили творить чудеса. Благо клиенты(OpenNX, NoMachineNX, Remmina) есть для разных платформ. Мы должны получить систему отвечающую следующим требованиям

  • Легко разворачиваемой, хорошей производительности;
  • Изолированную от основной сети (на программного-логическом уровне);
  • Доступ в интернет куда угодно — www, mail, ftp, im. Для экономии трафика, локальный кеширующий прокси. Хранение своих файлов в определенных лимитах.

Чтобы не зависеть от железа и легко наращивать мощности, создали виртуальную машину в vmware фабрике (сейчас еще непонятно, какие именно мощности нам нужны, быть может в будущем перенесем на реальное железо). Для основы используем дистрибутив CentOS6 x86_64 с оконным менеджером XFCE4.8 — это даст нам неплохую экономию производительности (в отличии от KDE и прочих тяжелоатлетов). Кстати, для XFCE не найден был keyboard layout для русскоязычных пользователей. Пришлось пересобирать оный с alt linux и оформить в виде rpm для CentOS. После установки ОС, были поставлены максимальное количество знакомых пользователям программ, как то Opera, Firefox, Google Chrome, а также Pidgin, LibreOffice, Acrobat Reader и прочее, прочее, прочее…

Вход по ssh запретили всем, кроме группы доменных админов. Фаерволом (iptables) закрыли все возможные локальные сервисы оставляя лишь доступ к dns, cups. Все остальное внутрь сети нещадно попадает под -j Reject.

Локально был поставлен squid (в /etc/profile.d/ были положены скрипты в зависимости от шела выставляющие переменные *_proxy), который будет исключительно для кеша. Домашние папки пользователей вынесли на отдельный раздел, включили журналируемое квотирование на нем.

Для freenx сервера разрешили 1 соединение per user. Отключили clipboard в обе стороны.

В результате у нас получается, система сама в себе. Доступ в нее только с помощью nx-клиента, вход только по ключу, с доменной аутентификацией. Никакой связи с локальными машинами нет. Что-либо передать на удаленную nx машину практически невозможно, а следовательно в интернет лишние данные не попадут.

Активных одновременных пользователей десятка полтора (работа не дает бОльшему количеству народу зайти). Параметры виртуальной машины на текущий момент — 2 ядра, 8Гб RAM, hdd и прочее не столь важно. По необходимости можно добавлять, в том и прелесть виртуалки.

Выяснились некоторые моменты относительно производительности. Отдельные пользователи могут открыть Оперу с множеством вкладок и тем самым откусить много памяти. Были предприняты попытки лимитировать ресурсы средствами limits.conf, но ничего толкового не вышло и пошли эксперименты с cgroups. Ограничили этим механизмом использование памяти только для браузеров, лимитирование работает, но пользователям не нравиться :). Ищем компромиссы.

Особые конфиги не прикладываю т.к. все из достаточно простых компонентов. NX поставить мануалов много, iptables настроить тоже ничего сложного :) но если есть вопросы — пишите.

Для облегчения запуска пользователям, сам NX клиент (бинарники), положены на сетевую шару, а ярлык на батник с запуском заранее подготовленной настроенной NX сессии, положен на рабочий стол пользователям. Работает без установки на конкретные машины на ура.

Автор: Anton_Shevtsov

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js