SSH-Bastion. Замковые ворота вашей инфраструктуры — KAZARIN OnLine

Требуемые пакеты

Мы устанавливаем минимально необходимый набор пакетов: рабочий стол Gnome (или другой оконный менеджер по выбору), базовый сервер и Samba. Нам потребуются:

  1. пакет krb5-workstation (версия не ниже 1.9), содержащий необходимые клиентские приложения для аутентификации на основе Kerberos;
  2. пакет oddjobmkhomedir (версия не ниже 0.30-5), предназначенный для автоматического создания каталогов пользователя при первом входе в систему;
  3. сам пакет Samba (версия не ниже 3.5-10), содержащий основные программы и пакет samba-winbind, отвечающий за соединение нашего сервера с контроллером домена.

Настройка сетевого адаптера

Теперь этот IP-адрес (192.168.7.10) необходимо присвоить сетевому адаптеру вновь установленного сервера CentOS Linux. Воспользуемся пунктом меню System на рабочем столе и выберем пункт Network Connections (рис. 2).

Рис. 2. Настройка сетевого соединения.

В появившемся окне настроек зададим нужный IP-адрес. В результате мы должны получить следующее — см. рис. 3.

Рис. 3. Настройка сетевого соединения. Задание IP-адреса.

Наш сервер настроен с использованием менеджера соединений (Network Manager). Поэтому нужно обязательно отметить несколько опций:

Настройка времени

Как уже говорилось в предыдущих статьях, корректная настройка времени очень важна для работы Active Directory. Настроить время можно с использованием штатных средств системы (см. рис. 5).

Рис. 5. Настройка времени.

Но для того, чтобы полностью избежать проблем с рассинхронизацией часов, следует настроить службу времени (демон ntpd) на синхронизацию времени с контроллером домена (см. рис. 6).

Рис. 6. Настройка службы времени.

Для этого нужно отредактировать файл /etc/ntp.conf, указав в качестве сервера времени контроллер домена. Не забудьте настроить запуск демона ntpd с помощью команды chkconfig ntpd on и перезапустить его командой /etc/init.d/ntpd restart.

Проверка настроек

Произведя указанные настройки, следует проверить их корректность. Нужно протестировать соединение с контроллером домена, настройку времени, правильность прямого и обратного разрешения имен (см. рис. 7).

Рис. 7. Проверка настроек.

Настройка авторизации в домене

Теперь настала пора настроить членство нашего сервера в домене Windows. В отличие от предыдущих примеров, не будем отдельно настраивать LDAP и Kerberos. Постараемся настроить все сразу, используя утилиту командной строки authconfig, поставляемую в составе дистрибутива CentOS.

Authconfig позволяет настроить сразу все требуемые службы. При этом настраивать можно не только авторизацию в домене Windows 2008, но и использование LDAP, NIS и других способов аутентификации.

Более подробную информацию об утилите authconfig можно получить из встроенного руководства (man authconfig, онлайн-версия), либо из встроенного руководства, набрав в командной строке authconfig -help.

Достаточно будет сказать, что authconfig имеет около 50 опций настройки — представляете его возможности и, одновременно, сложности в настройке? Проще воспользоваться графическим интерфейсом к authconfig — утилитой system-config-authentication (рис. 8).

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

Рис. 8. Вызов system-config-authentication.

Fail2ban

Статей по базовой настройке множество, что взять за основу, я уже успешно описывал в своей предыдущей статье. Поэтому немного процитирую сам себя:

Одной из дополнительных мер защиты, которую я настоятельно рекомендую применять в любом случае, является установка и настройка службы fail2ban. Это очень хороший инструмент борьбы с различными брутфорсерами и сканировщиками в автоматическом режиме без вашего участия. Инструмент парсит логи различных служб ( поддерживется очень большое число популярных — начиная от ssh и заканчивая различными ftp сервисами) на предмет нездоровой активности, вычисляет источник и банит его по ip адресу, добавляя в специально созданное правило firewall. Для общего развития советую так же ознакомиться вот с такой статьей на хабре.  

По умолчанию, fail2ban готов защищать ваш ssh сервер ( только в нашем случае нужно будет в настройках сменить порт с стандартного под псевдонимом ssh на тот который Вы указали в настройках sshd) 

Небольшое дополнение для этой статьи — он должен быть настроен игнорировать подключения с 127.0.0.1 и с внутренней сети. В остальном банить должен быстро и надолго:

Как разбанивать пострадавших, так же описано в предыдущей статье.

Мониторинг

Если вы еще не выбрали себе систему мониторинга, я настоятельно рекомендую начать с Zabbix. В случае сложных и серьезных проектов его первенство спорно — возможно лучше взять Prometheus или TICK/TIG стэк. Но в целом я ставлю под сомнение ситуацию, когда Вы решили ставить бастион сервер а системы мониторинга у вас нет.

Что нам нужно будет мониторить:

  • Целостность файлов с паролями, например /etc/shadow. Это zabbix делает по умолчанию.
  • Целостность файлов с ssh ключами сервера и конфигурационными файлами  sshd и sssd. Сделать это можно аналогично как это сделано для /etc/shadow.
  • Статистику fail2ban и статистику ssh по подключениям. Я для себя реализовал мониторинг ssh через логи, для f2b это можно сделать схожим образом.

Вот так выглядят элементы данных:

SSH-Bastion. Замковые ворота вашей инфраструктуры — KAZARIN OnLine

Настройки firewall

Использовать по умолчанию будем  UFW, так как настройка должна быт примитивно проста. Входящий и исходящий трафик для этого сервера строго ограничивается. 

Разрешенный входящий трафик:

Разрешенный исходящий трафик:

Подключение через бастион

Как же нам теперь работать с внутренними сервисами, спросите Вы. А очень просто — я нарисую лишь варианты для ssh, однако один из них ( с пробросом порта), подойдет и для RDP и для VNC и для HTTP.

Сессия внутри сессии

Самый простой вариант — называется заходим на бастион сервер а потом заходим на нужный сервер. То есть сессия внутри сесии.

Как видно из лога выше, вначале произошла авторизация на бастион сервере, потом я  залогинился на вики сервер. Вся авторизация прошла с данными моей учетной записи AD.

Проброс портов

Не буду тут копипастить — просто приведу ссылки на готовые статьи как этим пользоваться:

Jump через сервер

Основная статья вот она: https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_Jump_Hosts#Jump_Hosts_—_Passing_Through_a_Gateway_or_Two

Заключение

На этом все. Я постарался описать минимальный и при этом достаточно функциональный вариант ssh-бастион сервера для Вас, коллеги. надеюсь будет полезно!

П.С. Подписывайтесь на мой Telegram канал

А как же sso при доступе к ресурсам на linux пк?


Можно и так! PBIS заполняет /etc/krb5.keytab и поддерживает его актуальным. Поэтому серверное ПО с поддержкой GSSAPI может быть сконфигурировано для SSO.

Например, для доступа к серверу по ssh, в конфигурационный файл /etc/ssh/sshd_config (путь в вашей системе может отличаться)

GSSAPIAuthentication yes

И при подключении указать доменное имя компьютера (присутствующее в его SPN — иначе билет kerberos не сможет быть выписан)

UsePAM yes

(PBIS предоставляет модуль для PAM в том числе)Также логично будет добавить директиву «AllowGroups» и указать через пробел доменные группы, пользователям которых вы намерены дать доступ к ssh серверу.

На клиентском Linux ПК в конфигурацию клиента ssh достаточно включить:

GSSAPIAuthentication yes

Естественно на клиентском Linux компьютере должен быть настроен kerberos. Простейший способ выполнить это условие — так же ввести клиентский компьютер в домен и работать от имени доменного пользователя.

Аутентификация samba в домене windows

Мы продолжаем серию статей про взаимодействие Linux и Windows.Теперь мы рассмотрим задачу введения в домен Windows 2008R2 сервера с операционной системой CentOS Linux (версия 6.3). Как и в последних статьях, будем пользоваться штатными средствами, поставляемыми в составе дистрибутива операционной системы.

Но, в отличие от наших предыдущих статей, мы расширим задачу. Требуется организовать не только файловое хранилище на сервере под управлением CentOS Linux, но и обеспечить доступ доменных пользователей к командной и графической оболочке.

База данных

Тут все довольно просто. Скорее всего Вы используете MySQL или ее вариации (MariaDB или Percona Server). 

Первым делом убедитесь, что Ваш движок СУБД не открыт всему миру, а слушает только локальный порт:

Далее — ваш сайт должен иметь отдельную базу, и отдельного пользователя внутри СУБД, которому разрешено пользоваться только этой базой и более ничем:

Ну и в конце — есть такой замечательный скрипт от самих разработчиков MySQL, как mysql_secure_installation, который позволит Вам быстро и просто подкрутить настройки безопасности СУБД, без страха сломать Вашу базу.

Ввод centos 7 в домен active directory и авторизация по ssh доменных пользователей

Мне понадобилось настроить авторизацию доменный учетных записей Active Directory по ssh на linux сервер. В моем случае это будет система CentOS 7. Данная возможность будет очень удобна для организаций с внедренной доменной структурой Windows. С помощью групп доступа в AD вы сможете централизованно управлять доступом к linux серверам.

Ввод в домен.

Перед вводом в домен следует убедиться, что контроллеры домена доступы и доменные имена корректно разворачиваются в ip. (Иначе следует настроить resolv.conf)


Для ввода в домен предназначены две команды: /opt/pbis/bin/domainjoin-cli и /opt/pbis/bin/domainjoin-gui. Одна из них работает в командной строке, вторая использует libgtk для отображения графического интерфеса.

Веб сервер

Так как статья нацелена именно на вопросы security а не на вопросы просто настройки веб сервера, я буду краток. на Вашем сервере с вероятностью 99% будет либо nginx, либо apache. При условии что оба они обновлены (стоят последние пакеты со всеми патчами), сами по себе они безопасны. Вопрос сводится только к настройкам:

Похожее:  Кто там? Или правильная PHP авторизация на сайте

Веб сервер должен быть запущен от имени отдельного пользователя! Не root, не ваша учетка! Отдельный юзер, в настройках которого, в качестве командной оболочки стоит nologin. То есть, если веб сервер будет взломан и через него зальют некий shell скрипт, злоумышенник не сможет его запустить на Вашей машинке и не получит доступа к управлению:

Как видно на скриншоте,  рабочий процесс Nginx работает из под пользователя www-data, для которого оболочкой стоит nologin.

Каталог, в котором лежат файлы Вашего сайта, должен принадлежать пользователю Вашего веб сервера и быть ограниченным в правах для других пользователей. Больше ни на какие каталоги в вашей системе пользователь веб сервера прав иметь не должен. Вот пример:

Конфигурация веб сервера для Вашего сайта должна содержать инструкцию, которая разрешает обращение к «админке» только с определенных адресов. Вот пример для nginx:

Вход по ssh ключу для локальных администраторов windows

В OpenSSH используются особые настройки доступа по ключам для пользователей с правами локального администратора Windows.

Генерация ssh ключей на клиенте windows

На клиентском, компьютере, с которого вы будет подключаетесь к удалённому серверу Windows с OpenSSH, вам нужно сгенерировать пару ключей (открытый и закрытый). Закрытый ключ хранится на клиенте (не отдавайте его никому!), а открытый ключ нужно скопировать в файл authorized_keys на SSH сервере. Чтобы сгенерировать SSH ключи на клиенте Windows, вы должны установить клиент OpenSSH.

В Windows 10/11 и Windows Server 2022/2022 клиент OpenSSH устанавливается как отдельный встроенный компонент с помощью PowerShell:

Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

Запустите обычную (непривилегированную сессию PowerShell) и сгенерируйте пару ED25519 ключей:

ssh-keygen -t ed25519

По умолчанию утилита ssh-keygen генерирует ключи RSA 2048. В настоящий момент вместо RSA ключей рекомендуется использовать именно ED25519.

Утилита попросит вас указать пароль для защиты закрытого ключа. Если вы укажете пароль, то каждый раз при использовании этого ключа для SSH авторизации, вы должны будете вводить этот пароль. Я не стал указывать пароль для ключа (не рекомендуется).

До фортификации

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

Вот так примерно выглядит ситуация — каждый сервер торчит портом доступа во внешнюю сеть и вынужден отбиваться сам по себе от атак и не легитимных подключений. Вам нужно следить, чтобы все они были обновлены, проверять на них логи, мониторить нездоровую активность.

Хочется остановить все это и спрятать их всех за прочную стену. Но как тогда обеспечить доступ? Нам нужны ворота, нам нужна башня, защищающая эти ворота и строгий привратник. Все это зовется просто — Бастион Сервер. Так же его порой называют Access gateway.

Добавление rhel (centos) 5 сервера в домен active directory

SSH-Bastion. Замковые ворота вашей инфраструктуры — KAZARIN OnLine

Если ввод в домен рабочей станции или сервера Windows довольно тривиальная задача, то присоединение к домену Linux системы оказалось не на много сложнее 🙂 Прогресс не стоит на месте, Red Hat приложила (да и Microsoft тоже) немело усилий для безпроблемного сосуществования и взаимодействия различных операционных систем. В качестве примера возьмем сервер с RHEL 5.

6 на борту с именем server01  и заведем его в Active Directory домен ACME.LOCAL Для начала проверяем что в имени машины присутствует имя домена

[root@server01 ~ ] vim /etc/sysconfig/network

HOSTNAME=server01.acme.local если нет – правим файл и, затем, выполняем команду

[root@server01 ~ ] hostname server01.acme.local

Указываем короткое и полное имя этого сервера

[root@server01 ~ ] vim /etc/hosts

127.0.0.1       server01 server01.acme.local localhost localhost.localdomain Важный момент: прописываем IP нашего контроллера домена как DNS сервер

[root@server01 ~ ] vim /etc/resolv.conf

nameserver 192.168.1.1 Далее необходимо синхронизаровать системное время между сервером и контроллером домена. Правим конфигурационный файл службы точного времени:

[root@server01 ~ ] vim /etc/ntp.conf

добавляя строку:

server dc.acme.local

 здесь – dc.acme.local – это имя контроллера домена для ACME.LOCAL. Время должно быть синхронизировано для корректной работы службы Kerberos

Настраиваем службу времени на запуск при старте системы 
[root@server01 ~ ] chkconfig ntpd on 
и запускаем ее:
[root@server01 ~ ] service ntpd start
Ставим клиент Samba 3.3

[root@server01 ~ ] yum install samba3x samba3x-common samba3x-client

Можно использовать Samba 3.0 который идет в поставке RHEL версии 5.4 и ранее, но для домена на основе Windows Server 2008 R2 рекомендуется использовать samba-3.3. В моем случае это позволило побороть сообщения в журнале /var/log/messagesА теперь самая магия.

Запускаем нижеследующую команду одной строкой либо с обратными слешами:

[root@server01 ~ ] authconfig –update –kickstart<p>–enablewinbind –enablewinbindauth –smbsecurity=ads –smbworkgroup=ACME –smbrealm=ACME.LOCAL –smbservers=DC.ACME.

Дополнительные материалы по centos

Настройки системыНастройка программных комплексовНастройка отдельных программРазное
Рекомендую полезные материалы по CentOS:
Установка CentOS 7 в конфигурации minimal или netinstall с загрузочной флешки или по сети на диск или raid раздел.Базовая настройка CentOS 7 для работы с любым функционалом. Приведены практические советы по улучшению безопасности и удобства администрирования.Как установить точное время на сервере CentOS, настроить часовой пояс, синхронизировать время с помощью ntpdate и ntpd и другое.Подробное описание настройки сети в CentOS 7 – задать ip адрес, dhcp, отключить ipv6, dns, hostname, статические маршруты и др.
 Подробное описание настройки прокси сервера на базе CentOS 7 со связкой squid AD sams2, реализован запрет доступа по url и группам пользователей.Описание установки и настройки asterisk – популярной современной sip атс. Описан расширенный функционал, покрывающий большинство потребностей стандартного офиса в современной телефонии.Установка и настройка высокопроизводительного web сервера на базе nginx и php fpm. В качестве кэша используется APC.
 Настройка DNS сервера BIND (Named) в CentOS 7. Рассмотрены наиболее популярные конфигурации, в том числе подробное логирование.Установка Unison в CentOS 7 для двухсторонней синхронизации файлов.Настройка сервера для централизованного сбора логов с удаленных устройств и серверов с помощью программы syslog-ng.

Как присоединить серверы centos 7 / rhel 7 к домену active directory

В большинстве сред домен Active Directory является центральным центром информации для пользователя, а это значит, что для систем Linux необходимо каким-то образом получить доступ к этой пользовательской информации для запросов на аутентификацию.

В этой статье мы покажем вам, как присоединить  системы CentOS 7 / RHEL 7 в домен Active Directory.

Прежде чем присоединиться к домену AD, нам необходимо убедиться, что мы установили службы времени (NTP) и DNS.

При наличии этих инфраструктурных служб нам понадобятся следующие пакеты, установленные на сервере CentOS / RHEL:

  • realmd: управляет регистрацией и членством в доменах Active Directory
  • samba:  служба samba
  • samba-common: общие инструменты для серверов и клиентов
  • oddjob: Это служба D-bus, которая запускает odds задания для клиентов
  • oddjob-mkhomedir: используется odds службами задания для создания домашних каталогов для учетных записей AD, если это необходимо
  • sssd:  демон System Security Services
  • adcli: : Это инструменты для присоединения и управления доменами AD

— Используйте следующую команду для установки необходимых пакетов:

# sudo yum install oddjob realmd samba samba-common oddjob-mkhomedir sssd adcli

— Чтобы обнаружить идентификатор домена, мы будем использовать команду обнаружения области, которая вернет полную конфигурацию домена и список пакетов, которые должны быть установлены для системы, которая будет зарегистрирована в домене.

# realm discover yallalabs.local YALLALABS.LOCAL type: kerberos realm-name: YALLALABS.LOCAL domain-name: YALLALABS.LOCAL configured: no server-software: active-directory client-software: sssd required-package: oddjob required-package: oddjob-mkhomedir required-package: sssd required-package: adcli required-package: samba-common-tools yallalabs.local type: kerberos realm-name: YALLALABS.LOCAL domain-name: yallalabs.local configured: no

— Чтобы присоединиться к домену AD, добавьте компьютер в папку по умолчанию в домене AD, используя следующую команду:

Мониторинг

Если вы еще не выбрали себе систему мониторинга, я настоятельно рекомендую начать с Zabbix. В случае сложных и серьезных проектов его первенство спорно — возможно лучше взять Prometheus или TICK/TIG стэк. Но в целом я ставлю под сомнение ситуацию, когда Вы решили ставить бастион сервер а системы мониторинга у вас нет.

Что нам нужно будет мониторить:

  • Целостность файлов с паролями, например /etc/shadow. Это zabbix делает по умолчанию.
  • Целостность файлов с ssh ключами сервера и конфигурационными файлами  sshd и sssd. Сделать это можно аналогично как это сделано для /etc/shadow.
  • Статистику fail2ban и статистику ssh по подключениям. Я для себя реализовал мониторинг ssh через логи, для f2b это можно сделать схожим образом.

Вот так выглядят элементы данных:

Настройка openssh в windows для авторизации по ключам

SSH сервер (в этом примере это удаленный компьютер с Windows 11 и настроенной службой OpenSSH).

Настройки firewall

Использовать по умолчанию будем  UFW, так как настройка должна быт примитивно проста. Входящий и исходящий трафик для этого сервера строго ограничивается. 

Разрешенный входящий трафик:

Разрешенный исходящий трафик:

Настройки ос

Нус, с чего нам стоить начать?

Пункт первый — ставьте обновления! Черт возьми- первым делом после установки сервера — ставьте обновления! И в дальнейшем старайтесь про ни не забывать. Обновления в первую очередь закрывают баги и дыры в безопасности.

Похожее:  Armelle Евгения Ликаревич

Шаг Второй — заведи учетную запись отличную от root. В 99% случаев аренды vps/vds Вам отдают виртуальную машину с единственной учетной записью — root. Это нормально. не нормально — оставлять ее просто так. Заведите отдельную учетку, с правами на sudo или без — уже Вам решать.

Кстати «о птичках» — если работать на сервере Вы будете не один, используя sudoers файлы, можно отлично «нарезать» привелегированный доступ другим сотрудникам, не выдавая им при этом возможность завладеть root привелегиями. Вот пример  часто используемого мною файла sudoers, чтобы предоставить например веб-разработчикам на «продакшен» сервере довольно широкие права для исследования проблемы, но при этом без полного доступа к системе:

Если не очень понятно что это и зачем — милости просим читать про sudo утилиту и sudoers файлы

Шаг четвертый — настройте правильно SSH. Тут существует 3 простые и максимально действенные настройки:

  • Отключите вход по учетной записью root (саму запись можно не выключать, просто в настройках sshd скажите «PermitRootLogin no» )
  • Сгенерируйте для себя ssh ключ, установите его на сервер под Вашей учетной записью, проверьте доступ по ключу и наконец отключите вход по паролю («PasswordAuthentication no»)
  • «Скройте» стандартный ssh порт от всего Интернет. Самый простой способ для этого — переключите ssh на не стандартный порт ( т.е отличный от 22). Зачем это нужно — в сети огромное число ботов и авто сканирующих программ, которые просто рыщут по доступным ip адресам и найдя открытый 22 ssh порт, начинаю его брутфорсить. Посмотрите записи вашего лога аутентификаци и в реальном времени — «tail -f /var/log/auth.log», спустя  час после запуска вашего сервера, а потом повторите эту процедуру после смены порта и перезапуска ssh — сразу поймете о чем я)
  • Другие способы — это спрятать ssh за vpn, разрешить подключение к ssh только с определенных ip адресов  с помощью firewall (например с вашего домашнего/рабочего адреса, если у Вас там статический IP)

Шаг пятый — раз уж мы заговорили про SSH, стоит вспомнить про тот факт, что не только Вы используете ключи при работе с сервером, но и он при работе с Вами. При установке OpenSSH сервера, происходит автоматическая генерация ключей для него, тем самым гарантируется их уникальность ( а значит и безопасность) для каждой новой инсталляции.

Однако, нередко хостеры грешат тем, что при заказе Вами у них виртуалки, они не устанавливают ее «с нуля» а просто клонируют ее Вам из шаблона, сохраняя всю «начинку» ( и сгенерированные 1 раз ключи, и устаревшие пакеты без обновлений). Я уже писал про один такой хостинг.

Как резюме — да, это плохо, да, про это надо помнить. Что в такой ситуации делать? Просто взять и перегенерировать эти ключи вручную с последующим перезапуском сервера. Вот пример из моего Ansible Playbook для настройки нового сервера, где  я безапелляционно делаю:

Ограничение доступа ssh по группам и пользователям домена

На текущий момент подключиться к серверу может любой пользователь домена. Исправим это и разрешим подключаться только пользователям из группы gr_linux_adm. Для этого правим конфиг /etc/sssd/sssd.conf, добавляя туда новые параметры.

Ограничение доступа к sudo по доменным группам

Ограничение доступа к ssh по группам и пользователям настроили, теперь надо разрешить доменным учетным записям получать права суперпользователя в системе. Сейчас у них нет такой возможности.

Подготовка сервера

Если у вас еще нет готового сервера, то можете воспользоваться моими материалами на эту тему — установка и настройка centos 7. Так же рекомендую настроить iptables для корректной работы сервера с доменом windows. Далее я не буду каcаться этого вопроса, мы просто отключим фаерволл, потому что его настройка не тема этой статьи.

Выключаем firewalld:

# systemctl stop firewalld && systemctl disable firewalld

Перед дальнейшей настройкой, убедитесь, что с вашего сервера centos вы без проблем пингуете и резолвите контроллер домена по полному имени. Если есть какие-то проблемы, исправьте это либо указанием нужного dns сервера, либо правкой файла hosts.

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

Устанавливаем утилиту для синхронизации времени chrony:

# yum install chrony

Добавляем в конфиг /etc/chrony.conf адрес контроллера домена. И делаем его единственным сервером для синхронизации, остальные удаляем.

server xs-winsrv.xs.local iburst

Сохраняем конфиг, запускаем chrony и добавляем в автозагрузку.

# systemctl start chronyd && systemctl enable chronyd

Проверим, что с синхронизацией.

# cat /var/log/messages | grep chronyd Jul 12 17:58:38 xs-centos7-test chronyd[10620]: chronyd version 2.1.1 starting ( CMDMON NTP REFCLOCK RTC PRIVDROP DEBUG ASYNCDNS IPV6 SECHASH) Jul 12 17:58:38 xs-centos7-test chronyd[10620]: Frequency 0.

000 /- 1000000.000 ppm read from /var/lib/chrony/drift Jul 12 17:02:54 xs-centos7-test chronyd[10620]: Selected source 10.1.3.4 Jul 12 17:02:54 xs-centos7-test chronyd[10620]: System clock wrong by -3348.457170 seconds, adjustment started Jul 12 17:02:54 xs-centos7-test chronyd[10620]: System clock was stepped by -3348.457170 seconds

Все в порядке. Синхронизировали время с контроллером домена. По логу видно, что время на сервере убежало вперед на 56 минут, но мы это исправили.

Подключение centos 7 к домену

Устанавливаем софт, который нам понадобится, для корректного ввода centos в домен windows.

# yum install realmd sssd oddjob oddjob-mkhomedir adcli samba-common samba-common-tools

Вводим Centos 7 в домен:

После перезагрузки.

После перезагрузки и id, и getent выдадут вам пользователей и группы домена (национальные символы обрабатываются корректно. Пробелы заменяются на символ “^”).

В доменной DNS зоне появится запись с именем вашего ПК.

Не спешите входить от имени доменного пользователя. Сначала имеет смысл (но вовсе не обязательно) настроить PBIS.

/opt/pbis/bin/config --list


Одно из отличий Enterprise версии — возможность управлять этими настройками через GPO.

Стоит обратить внимание на HomeDirPrefix, HomeDirTemplate.

Я также сразу задал «RequireMembershipOf» — только пользователи, члены групп или SID из этого списка могут авторизоваться на компьютеры.


Описание каждого параметра можно получить, например так:

/opt/pbis/bin/config --detail RequireMembershipOf

Значение параметра устанавливается например так:

/opt/pbis/bin/config RequireMembershipOf "Администраторы^Linux"

Обратите внимание — PBIS не использует атрибуты SFU либо иные другие атрибуты Acrive Directory для получения loginShell пользователя, а также его uid и gid.loginShell для доменных пользователей задаётся в настройках PBIS, причём установка различных loginShell различным пользователям — возможна только в Enterprise версии.uid формируется как хэш SID пользователя.gid — как хэш SID primaryGroup пользователя.Таким образом на двух ПК пользователь получит всегда одинаковые uid и gid.

Похожее:  Киевстар Личный кабинет – вход, регистрация, функции

Теперь можно входить в систему от имени доменного пользователя. После входа доменного пользователя обратите внимание на вывод klist — PBIS получит для пользователя необходимые билеты kerberos. После этого можно безпроблемно обращаться к ресурсам на windows ПК (Главное, чтобы используемое ПО поддерживало GSSAPI). Например: теперь я без дополнительных запросов паролей (и пароль мой нигде не сохранён!) открываю любые smb ресурсы домена в Dolphin.

Предисловие

Итак, представим ситуацию — у вас большая инфраструктура и есть ряд серверов, доступ к управлению которыми вы должны предоставлять извне. Скажем — несколько Дата Центров, облачных площадок и любых других приватных сетей, внутри которых есть работающие сервера, к которым должны подключаться Ваши админы, разработчики, тестировщики.

Другая ситуация — Вы один администратор в компании с несколькими площадками  (офис, несколько серверов в ЦОДе, удаленная производственная площадка)

Предисловие…

Приветствую Вас, друзья! Эта статья представляет собой очередной флешбэк из админского прошлого. буквально сегодня мне написал хороший товарищ, программист, с вопросом — как ему лучше для своего «домашнего» проекта настроить сервер. Цитата дословно (без ссылки на автора просто):

Нужен  совет. Есть VDS, торчит в интернете(сайте). Какие вещи я должен на нем сконфигурировать с точки зрения секьюрности? Кроме того чтобы настроить ssh на нестандартном порту с аутентификацией по ключу и запретить ssh для рута? Может надо как-то правильно расставить права на папки, может включить какие-то дополнительные механизмы, что-то в этом духе? А может и не надо больше ничего. Мне не надо упарываться по самые бубенцы, просто хочу немного обезопасить себя.

Вопрос как оказалось очень даже актуальный. Да, если вы регулярно администрирует Linux и веб сервера, казалось бы, «что тут сложного» и «как это программист не знает». А вот очень просто. Ну не работает человек с этим постоянно. Имеет право не знать.

Первое, о чем мы с Вами условимся — это не будет стандартный шаблонный How-to гайд с тонной команд без комментариев, мол вот это и это сделай и будет тебе счастье. Таким, простите за мой французский, низкопробным шлаком, Интернет переполнен. Я буду говорить о том что нужно сделать, как и почему, давая ссылки на документацию или авторитетные источники и уже в последнюю очередь — может буду приводить команды.

Второе о чем мы с Вами условимся — если будут примеры, они будут привязаны к Ubuntu как к ОС Вашего сервера. Сейчас любой Облачный провайдер или хостинговая компания позволяет Вам развернуть свой виртуальный сервер на базе этого Linux дистрибутива. Она ( Ubuntu) дружественна к пользователям, есть поддержка всего программного обеспечения какое только существует под Linux и т.д.

Третье и самое главное — это НЕ исчерпывающее руководство. Это просто список тех МИНИМАЛЬНЫХ мер «гигиены» которые Вы должны предпринять или убедиться что они предприняты по умолчанию, чтобы Ваш сервер хорошо себя чувствовал и радовал Вас стабильным аптаймом

Поехали!

Проброс портов

Не буду тут копипастить — просто приведу ссылки на готовые статьи как этим пользоваться:

Проектируем нашу защиту

Сейчас я хочу показать, как такое решение можно создать самому, используя opensource инструменты на базе Linux и не прибегая к платным проприетарным решениям.

Суть решения заключается в том, что мы закрываем прямой доступ к любым хостам внутри нашей DMZ напрямую из вне и оставляем доступ только к этому серверу, уже с которого Вы можете получить доступ к внутренним инфраструктурным единицам.

Мы ставим 1 сервер, открываем наружу ( через корпоративный фаервол, или он сам может защитить себя своим фаерволом) 1 сервер, только ему даем доступ внутрь нашей DMZ. Что нам это дает:

  • Active directory base аутентификация. SSH как сервис, нативно используем PAM для аутентфикации и авторизации пользователей. Соедините его через sssd и realmd с Active Directory — получите нативную аутентификацию через доменные учетные записи, получите разграничение по группам, возможность включать и выключать в AD пользователю возможность подключаться к нему ( а значит и через него) извне.
  • Привычный в настройке и эксплуатации сервис. SSH — хорошо известный всем Linux ( да и не только Linux) администраторам сервис, привычный в настройке, с стойким шифрованием, способный пробрасывать порты и соединения, передавать файлы и многое другое!
  • Легко доступные и настраиваемые средства защиты. Помимо встроенных в саму реализацию средств обеспечения безопасности ( минимальные привилегии, ограничение числа подключений, доступ по ключам, стойкое шифрование) существуют так же дополнительные меры которые крайне легко настроить — например тот же Fail2ban.
  • Простота настройки доступа для нового сервера. Если раньше, чтобы обеспечить доступ извне к новому серверу, вам нужно было накрутить на нем методы безопасности, настроить правила фаервола для предоставления доступа извне, сейчас достаточно просто подключить интерфейс нового сервера в DMZ.

Можно произносить еще много интересных и красивых слов, но я думаю смысл понятен.

Сессия внутри сессии

Самый простой вариант — называется заходим на бастион сервер а потом заходим на нужный сервер. То есть сессия внутри сесии.

Сканирование

Время от времени не плохо было бы проверить Ваш сервер — а не забыли ли Вы чего, а не поселилось ли там что? Для этого нам помогут различные сканеры:

Создание домена active directory в centos

Samba версии 4 позволяет создавать домены Active Directory с функциональностью, близкой к доменам на Windows. Уровень схемы соответствует Windows 2008 R2.

Из ограничений следует отметить отсутствие на данный момент поддержки Distributed File System (DFS) и невозможность установить ряд приложений, модифицирующих схему, напр., M$ Exchange.

Нужны дополнительные действия для репликации SYSVOL при 2-х или более КД.

Рассмотрим установку каталога Active Directory на 2-х контроллерах домена под управлением Samba 4, работающей на CentOS 7. Следует отметить, что в базовых репозиториях и EPEL пакет Samba не содержит необходимых для нас функций, поэтому потребуется ее сборка.

Ранее доступный на sernet’е (Enterprise Samba) бинарный RPM в свободном доступе доступен лишь в старой версии – по 4.2, новее – только по подписке.  Мы же поставим текущую на момент написания статьи версию 4.5.3.

Отключать брандмауэр и SELinux, как рекомендуют во многих источниках, не нужно!

Перед началом желательно прочесть документацию

Setting up Samba as an Active Directory Domain Controller

Joining a Samba DC to an Existing Active Directory

Official Samba FAQ

AltLinux ActiveDirectory/DC

ArchLinux Samba 4 Active Directory domain controller

И после установки дополнительные материалы

Samba AD DC Port Usage

Rsync based SysVol replication workaround

Managing the Samba AD DC Service

Итак, приступим. 🙂

Строим

Так, наша задача:

  • Централизованная аутентификация
  • SSH харденинг
  • Fail2ban
  • Мониторинг
  • Настройки внутреннего Firewall

Уведомления

Возможно Вам захочется получать каждое утро сводку новостей от сервера- что случилось, что изменилось и тд. Когда у вас таких серверов десятки это конечно перебор, но когда он один любимый, почему бы нет. В этом Вам поможет LogWatch — утилита парсит логи сервисов, за которыми вы ей приказали следить, и шлет вам на почту отчет регулярно в указанное время  в виде симпатичного простого отчета:

Хотя по большому счету конечно хранение и анализ логов лучше доверить чему-то по серьезней, типа rsyslog LogAnalyzer или ELK.

Но мы помним что вопрос идет про 1 сервер!

Усиление ssh

Так как это протокол у нас будет выступать основным каналом связи, не можем пройти мимо него.

Некоторый список best practices:

Установка.

Есть две версии продукта: Enterprise и Open. Мне для реализации моих задач хватило Open версии, поэтому всё написанное далее будет касаться её.

Получить Open версию можно на

, но ссылку Вам предоставят в обмен на Ваше имя, название компании и e-mail.


Существуют 32-х и 64-х пакеты в форматах rpm и deb. (А также пакеты для OS X, AIX, FreeBSD, SOlaris, HP-UX)

Финиш

По завершении всех процедур настройки можно вернуть имя хоста в исходное состояние, «привычное» для Debain.

# hostname KOM-SRV01

После завершения настройки перезагружаем Linux-сервере, чтобы убедиться в успешном автоматическом запуске SSSD и последующей корректной работы аутентификации/авторизации на базе доменных учётных записей.


Дополнительные источники информации:


Проверено на следующих конфигурациях:


SSH-Bastion. Замковые ворота вашей инфраструктуры — KAZARIN OnLine Автор первичной редакции:
Алексей Максимов
Время публикации: 13.09.2022 16:43

Заключение

На этом все. Друзья — спешу повторить, что эта статья НЕ является исчерпывающим руководством. Это БАЗА, которую нужно знать и применять. Существует огромное множество руководств по настройкам и харденингу, как более подробных, так и узкоспециализированных, затрагивающих вопросы, которых мы в рамках данной статьи не касались — например тюнинг ядра Linux для повышения сетевой безопасности.

Всем спасибо, до новых встреч! Всем высокого аптайма!

Заключение

Данная работа выполнена на базе Информационно-вычислительного центра МЭИ.Мы будем рады вашим замечаниям и предложениям. У нас есть возможности собрать тестовую сеть и отладить на ней различные варианты и конфигурации систем для обеспечения их взаимодействия.

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (Пока оценок нет)
Загрузка...

Добавить комментарий

Ваш адрес email не будет опубликован.

Adblock
detector