Меню
ГлавнаяПоломки

Шифрование файлов и папок в Linux. Порядок выполнения работы. Термины GPG шифрования

Защита своих данных от чужих глаз — в некоторых случаях может быть вопросом жизни и смерти, а полагаться в этом вопросе на других означает доверять им свои данные. Защитить от любопытных носов свою переписку своими же силами поможет GPG шифрование .

  • GPG шифрование
  • История PGP / GPG шифрования
  • Термины GPG шифрования
  • Установка GPG шифрования
  • Шифрование сообщений и файлов
  • Подписи в GPG шифровании
  • Функция Web of Trust
  • Зачем нужно шифрование

GPG шифрование

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

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

История PGP / GPG шифрования

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

В 1991 появился общедоступный инструмент асимметричного шифрования для личного использования - PGP, задавший стандарт, однако он был платным и являлся зарегистрированной товарной маркой.

В 1999 был создан GPG - свободный, бесплатный, открытый и полностью совместимый со стандартом аналог PGP. Именно GPG стал самым популярным и зрелым инструментом асимметричного шифрования.

Термины GPG шифрования

Прежде чем приступить к использованию GPG, нужно понять несколько главных особенностей этого инструмента. Первая и основная особенность - это понятие «ключи». Каждый пользователь создает себе свой личный ключ. Ключ пользователя состоит из двух частей

  • Публичный ключ (из публичной части)
  • Секретный ключ (из секретной части)

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


GPG4USB

Вторая особенность - ключи, основанные на разных алгоритмах совместимы между собой. Неважно, использует ли пользователь RSA или ELGamal, для шифрования не нужно забивать голову такими деталями. Это достигается за счет работы по упомянутому выше стандарту и через некоторые криптографические приемы. Это одно из главных преимуществ GPG. Достаточно знать нужные команды, и программа сделает все сама. В библиотеку входит большое количество асимметричных алгоритмов, симметричным шифров и односторонних хэш-функций. Разнообразие также является преимуществом, потому что позволяет создать одновременно и общие рекомендованные конфигурации, подходящие для большинства, и возможность тонкой настройки для более опытных пользователей.

Как установить GPG шифрование

Для начала работы нужно установить сам GPG. Пользователи Linux могут поставить его из любого пакетного менеджера, поискав там « », или собрать вручную. Пользователи Windows могут воспользоваться сильно устаревшим клиентом , который имеет несколько неприятных багов и больше функций, или портативным и более свежим клиентом , который имеет меньше функций, но намного проще и стабильнее. Кстати, мы уже писали о том как с помощью клиента GPG4USB .


Независимо от операционной системы и клиента, после установки нужно будет создать свой ключ, введя в терминале или кликнув в клиенте соответствующую команду. Программа попросит определиться с алгоритмом шифрования. Обычно их два - это RSA и ELGamal (на самом деле три, если на Linux Вы отважились поставить экспериментальную ветку «modern» с криптографией на эллиптических кривых). Конкретных рекомендаций по алгоритмам нет, они разные и каждый выбирает себе схему по нраву.

Затем необходимо определиться с размером ключа в битах. Здесь тоже нет короткого и однозначного ответа. У слишком длинных ключей есть и недостатки. Одно можно сказать с уверенностью: при выборе RSA и ELGamal не используйте ключи меньше 2048 бит, они крайне не безопасны. Далее программа попросит заполнить несколько форм: E-mail, Имя и комментарий. E-mail и Имя - это публичная информация, которую сможет увидеть каждый, с кем вы будете переписываться.

В качестве почты можно указать другие виды связи, например ID какого-либо сервиса или мессенджера ( , Jabber, и т. д.), разделив знаком «@» сам идентификатор/адрес и название сервиса. Чаще всего содержание именно этого поля используется для идентификации владельца ключа.

Имя выбирать по своему усмотрению. Например, часто используемый ник или вообще «Anonymous».

Поле комментария заполнять не обязательно. Можно ввести дополнительный. адрес или свою должность. Комментарий будет виден другим пользователям.

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

Сгенерировав свой GPG-ключ, можно начать его распространять. Для этого надо ввести команду отображения публичной части. Исторически сложилось так, что программа изначально применялась для шифрования почты и подписи публичных сообщений в почтовых рассылках, поэтому ключи отображаются по принципу формата РЕМ (англ. «Privacy­Enhanced Mail»). Формат представляет собой единый стандартный блок ключа, начинающийся заголовком — BEGIN PGP PUBLIC KEY BLOCK­­­ —, за ним следует достаточно длинное тело самого ключа, кодированное цифрами и латинским алфавитом, и завершающий заголовок — ­­­­END PGP PUBLIC KEY BLOCK­­­­ —. Весь блок с заголовками представляет собой ключ GPG, его и нужно распространять целиком. Помимо ручного распространения ключей, возможно использовать специализированные сервера. Пользователь загружает свой публичный ключ на сервер, и при необходимости любой может запросить его. Во многих программах в качестве сервера по умолчанию часто указывают сервер MIT.

Каждый GPG-ключ уникален. Запоминать и сравнивать такие большие блоки ключей вручную невозможно, поэтому для этого существуют отпечатки ключей. Каждый отпечаток ключа тоже уникален, формируется из публичной части, предоставляя короткую уникальную строку для идентификации. В строке отпечатка содержится 40 символов с разделением на 4 символа пробелами. Важно знать, что последние 8 или 16 символов являются еще и ID ключа. При использовании команд из терминала надо будет указывать ID для работы. Отпечатки удобны для быстрого сравнения двух ключей, или короткого указателя нужного ключа при нехватке места.

Шифрование сообщений и файлов

Шифрованные с помощью GPG сообщения состоят из похожих на публичный ключ блоков, только с заголовком ­­­­— BEGIN PGP MESSAGE —­­­­, а длина кодированной символами части зависит от длины сообщения. Подобные сообщения могут быть прочитаны только обладателем ключа, которому адресовано сообщение. Также можно зашифровать свое послание для нескольких ключей, что очень удобно при общении небольшой группы людей. Шифровать можно и файлы, тогда результат шифрования будет записан в файл, а не кодирован текстовыми символами.

Подписи в GPG

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

Подписи тоже можно применять на файлах. Особенно часто эта функция применяется разработчиками ПО, связанного с безопасностью. Делается это для того, чтобы предотвратить подмену файлов злоумышленниками, которые могут встроить в программы вредоносный код. Подписываются обычно архивы или сборки, сама подпись сохраняется в отдельный файл с расширением.asc или.sig. Ключ публикуется в нескольких местах и/или загружается на сервер, где его очень трудно подменить. Сам процесс проверки называется «верификация подписи».

Функция Web of Trust

Еще одна функция GPG, которую стоит упомянуть - это Web of Trust. Она используется для подтверждения принадлежности публичного ключа конкретному человеку. Для этого знакомые друг с другом пользователи GPG обмениваются ключами при личной встрече.

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

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

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

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

Зачем нужно шифрование

Зачем вообще нужно все это шифрование, если человек ничего не скрывает и не нарушает? Это один из самых часто задаваемых вопросов. На него есть несколько ответов. За последние годы возможность тотальной слежки за сетевой деятельностью миллионов пользователей стала уже вопросом не технической сложности, а ресурсов. Обладатели таких ресурсов - все спецслужбы мира и десятки крупных корпораций, с помощью таких программ как PRISM и X­Keyscore могут собирать и хранить годами все письма электронной почты, SMS-сообщения и историю звонков.

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

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

Оценка GPG шифрования

Наша оценка

GPG шифрование - это отличный инструмент для шифрования электронной почты и цифровых материалов.

Оценка пользователей: 4.41 (27 оценок)

Если вы хотите использовать те же самые открытые и закрытые ключи, которые есть на другом компьютере, просто скопируйте их с другого компьютера на новый. Если вы уже создавали какие-либо ключи, примите решение, будете ли вы их переписывать на новый компьютер, поскольку это может быть правильным решением. Я использовал одни и те же ключи в течение многих лет, просто копируя их с машины на машину и этого было достаточно. Ниже показано как с помощью команды scp скопировать ключи со старой машины, имеющей имя eliot .

$ mkdir ~/.gnupg

$ scp eliot:~/.gnupg/* ~/.gnupg

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

$ gpg --import /home/ username /Desktop/pubring.gpg

Вы увидите список ключей, которые были импортированы, и итоговое сообщение, указывающее на успешное завершение. Не забудьте удалить файл pubring.gpg с рабочего стола, так как он вам больше не нужен.

Если ключи вам непосредственно не доступны, но вы знаете, что пользователи, чьи ключи вы хотите импортировать, загрузили их на сервер, вы всегда можете импортировать их оттуда. Например, предположим, вы хотите импортировать мой ключ. Во-первых, вам нужно найти идентификатор моего ключа. С помощью веб-браузера, перейдите по ссылке http://pgp.mit.edu на сервер открытых ключей MIT PGP Public Key Server и найдите там Скотта Граннемана (Scott Granneman ). Вы получите три результата, но обратите внимание на один, датированный от 08/08/2004, который выглядит следующим образом:

Type bits /keyID Date User ID

pub 1024D/6503F88C 2004/08/08 Scott Granneman

Scott Granneman (www.granneman.com)

Обратите внимание на идентификатор ключа, который имеет значение 6503F88C . С его помощью вы можете импортировать конкретный ключ с помощью следующей команды:

$ gpg --keyserver pgp.mit.edu --recv-keys 6503F88C

gpg: requesting key 6503F88C from hkp server pgp.mit.edu

gpg: key 6503F88C: public key "Scott Granneman " imported

gpg: Total number processed: 1

gpg: imported: 1

Практическая работа № 26 Шифрование средствами Windows ХР

1 Цель работы

Приобретение навыков работы с шифрованием средствами Windows ХР

2 Порядок выполнения работы

2. Выполнить на VM шифрование средствами Windows ХР

3. Оформите отчет, который должен содержать:

    титульный лист (см. приложение);

    постановку задачи;

Описание пошагового исполнения;

    отчет о полученном результате

3. Задания к работе.

Шифрование

Особенностью Windows 2000 является возможность шифровать файлы, храня­щиеся на жестком диске. Система кодирования файлов обеспечивает более высо­кий уровень защиты файлов от несанкционированного доступа, однако, прежде чем приступить к использованию этой системы, вы должны обладать понимани­ем принципов ее работы, в противном случае у вас могут возникнуть проблемы. Чтобы включить систему шифрования файлов, необходимо открыть страницу свойств файла или каталога, щелкнуть на кнопке Advanced (Другие) и устано­вить флажок Encrypt contents to secure data (Шифровать содержимое для защиты данных) (рис. 5.2.5).

Windows 2000 также поддерживает атрибут, позволяющий управлять службой индексирования.

Если для какого-либо каталога вы установили флажок Encrypt contents (Шифро­вать содержимое), значит, система будет шифровать все файлы, содержащиеся в этом каталоге. Для шифрования содержимого файла используется алгоритм за­крытого (секретного) ключа. В отличие от алгоритмов открытого ключа, алго­ритм закрытого ключа работает значительно быстрее, что делает его щшемле-мым для шифрования больших объемов информации. Однако при этом/алгоритм закрытого ключа подразумевает использование одного и того же ключа как для кодирования, так и для декодирования данных.^Этот единый ключ создается ав­томатически и должен храниться в секрете. Возникает вопрос: каким образом следует обеспечить надежные хранение и передачу этого ключа? В системах, ис­пользующих открытый ключ, проблема решается очень просто: для кодирования данных используется один ключ, а для декодирования - другой. Кодирующий ключ можно сделать доступным для всех, в то время как декодирующий ключ следует держать в секрете.

Разработчики NTFS решили проблему следующим образом: для кодирования со­держимого файла используется алгоритм закрытого ключа, а для хранения само­го секретного ключа используется алгоритм открытого ключа. Такую схему часто называют английским термином lockbox (шкатулка с замком). Секретный ключ кодируется с использованием открытого ключа пользователя. Чтобы декодиро­вать его, требуется знание закрытого ключа пользователя. Таким образом, файл большого размера кодируется с использованием эффективного быстрого алго­ритма секретного ключа, а для защиты самого секретного ключа (который обла­дает небольшим размером) используется более сложный и менее быстрый алго­ритм открытого ключа.

Для обмена открытыми ключами Windows 2000 использует сертификаты Х509. Спецификация Х509 предназначена для формирования и передачи через сеть ут­верждений вида: «Этот открытый ключ принадлежит этому субъекту и может ис­пользоваться для этих целей». Сертификат можно получить, обратившись в спе­циальный сертифицирующий орган (Certification Authority), который, выдавая сертификат, подписывает его при помощи цифровой подписи. Субъект, получив­ший сертификат, может быть уверенным в том, что этот сертификат действи­тельно содержит ключ, который можно использовать для шифрования той или иной информации, адресованной тому или иному пользователю (например, элек­тронного письма, адресованного пользователю John Doe). Эта уверенность бази­руется на том факте, что сертификат получен от сертифицирующего органа.

Чтобы просмотреть сертификаты, установленные для пользователей, необходи­мо загрузить оснастку Certificates (Сертификаты) консоли управления Microsoft.

Кодирующая файловая система EFS (Encrypting File System) работает незаметно для пользователей. Она получает сертификат Х509, авторизированный для EFS. Если пользователь не имеет сертификата, система EFS создает его.

Сертификат восстановления файлов

Подключившись к системе в качестве администратора и открыв консоль Certificates (Сертификаты), вы увидите, что этой учетной записи соответствует индивидуаль­ный сертификат, предназначенный для восстановления файлов. Копия этого сер­тификата также сохраняется в локальной политике безопасности. Открытый ключ из этого сертификата используется системой EFS для создания дополнительной шкатулки с замком (зашифрованной копии секретного ключа).

При помощи консоли Certificates (Сертификаты) вы можете экспортировать этот сертификат и закрытый ключ в файл (другими словами, создать резервную копию сертификата). После этого как сертификат, так и закрытый ключ можно удалить. Это означает, что если злоумышленник каким-либо образом сможет подключиться ||:1: к системе в качестве агента восстановления, он все равно не сможет расшифровать £:; какие-либо зашифрованные файлы, так как среди сертификатов будет отсутство­вать необходимый для расшифровки сертификат. Чтобы расшифровать какие-ли­бо файлы, необходимо вновь установить в системе необходимый сертификат. Если: вы намерены использовать описанную процедуру в целях повышения безопасно­сти (что особенно уместно в отношении контроллеров доменов), вы должны поза­ботиться о надежном сохранении экспортированных сертификатов.

Практическая работа № 27. Наиболее важные ключи реестра Windows, нуждающиеся в защите. Защита ульев SAM и SECURITY

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

В операционной системе Linux есть замечательный инструмент с открытым исходным кодом для шифрования файлов - GNU Privacy Guard или просто GPG, который может быть использован для шифрования любого файла из командной строки или в графическом режиме. О нем и пойдет речь в сегодняшней статье.

Перед тем как перейти к использованию утилиты, давайте рассмотрим ее синтаксис:

$ gpg опции файл параметры

Опции указывает что необходимо сделать с файлом, как это сделать и какие возможности использовать. Давайте рассмотрим самые основные опции, которые мы будем использовать в этой статье:

  • -h - вывести справку по утилите;
  • -s, --sign - создать цифровую подпись, эта опция используется вместе с другими опциями для шифрования;
  • --clearsign - подписать незашифрованный текст;
  • -e, --encrypt - зашифровать данные, с помощью ключа;
  • -с, --symmetric - зашифровать данные, с помощью пароля;
  • -d, --decrypt - расшифровать данные, зашифрованные с помощью ключа или пароля;
  • --verify - проверить подпись;
  • -k, --list-keys - вывести доступные ключи;
  • --list-sigs - вывести доступные подписи;
  • --fingerprint - вывести все ключи вместе с их отпечатками;
  • --delete-key - удалить ключ;
  • --delete-secret-key - удалить секретный ключ;
  • --export - экспортировать все ключи;
  • --export-secret-keys - экспортировать все секретные ключи;
  • --import - импортировать ключи;
  • --send-keys - отправить ключи на сервер, должен быть указан сервер ключей;
  • --recv-keys - получить ключи от сервера ключей;
  • --keyserver - указать сервер ключей;
  • --fetch-keys - скачать ключи;
  • --gen-key - создать ключ;
  • --sign-key - подписать ключ;
  • --passwd - изменить пароль для ключа.

А теперь рассмотрим по порядку, что нам нужно для того, чтобы выполнять шифрование файлов Linux.

Шифрование файлов с помощью пароля

Симметричный шифр - самый простой и в то же время надежный способ шифрования файлов linux. Расшифровать файл сможет любой у кого есть пароль. Для использования просто запустите терминал и выполните команду gpg с параметром -c:

gpg -c имя файла

Утилита создаст файл с расширением gpg. Для расшифровки используйте:

gpg имя_файла.gpg

Шифрование с использованием ключей

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

Сначала необходимо настроить gpg, создать пару ключей, для этого наберите:

Программа задаст ряд вопросов для настройки ключа:

Выберите требуемый тип ключа.

Выберите нужный размер для ключа, обычно 2048 будет достаточно.

Выберите строк действия для ключа.

Проверьте все ли правильно.

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

Введите ваш email адрес.

Описание ключа, если нужно.

Финальная проверка, затем нажмите O для завершения.

Процесс генерации может занять некоторое время. Когда все будет готово в каталоге ~./gnupg появятся два файла. В файле pubring.gpg публичный ключ, а в secring.gpg приватный.

Также вы можете посмотреть список доступных ключей:

Если вы собираетесь шифровать файлы на другом компьютере необходимо экспортировать публичный ключ, для этого есть опция -а:

gpg -a -o gpgkey.asc --export имя_ключа

Затем передаем файл на целевое устройство и импортируем ключ:

gpg --import gpgkey.asc

После импорта ключа уровень доверия к нему по умолчанию будет неизвестным поэтому при каждом шифровании gpg будет спрашивать действительно ли вы доверяете этому ключу. Чтобы этого избежать нужно указать уровень доверия. Для этого воспользуйтесь редактором ключей:

gpg --edit-key Username

Для выбора уровня доверия введите команду trust:

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

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

gpg -e -r ид_пользователя имя_файла

Ид пользователя нужно указывать тот что вы использовали при создании ключа. Для расшифровки используйте:

gpg -d имя_файла.gpg

Для каталогов действия аналогичны только сначала нужно создать архив с помощью tar:

tar -cf - каталог | gpg -e -r ид_пользователя

А для расшифровки:

gpg -d каталог.gpg | tar -xvf

Подписи и шифрование

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

Вы можете подписать файл с помощью опции --sign:

gpg --sign имя_файла

Если вы не хотите изменить исходный файл, то можно создать подпись в отдельном файле:

gpg -b имя_файла

У меня имеется свежеустановленный сервер CentOS 7 на VDS с виртуализацией KVM. Я расскажу о том, как сделать базовую настройку сервера для использования его в любом качестве на ваше усмотрение. Это может быть web сервер, vpn сервер, сервер мониторинга. Я расскажу о начальных настройках системы CentOS, которые повышают безопасность и удобство работы с сервером. Отмечу, что в 7-й версии системы произошли некоторые изменения по сравнению с предыдущими версиями.

Введение

Еще раз обращаю внимание, что данные настройки я делаю на виртуальном сервере. Если у вас железный сервер, то рекомендуется выполнить еще некоторые настройки, о которых я здесь не упоминаю. К ним относится, к примеру, настройка и проверка отказоустойчивости при выходе одного из дисков. Отключение регулярной проверки массива mdadm и др.

Начальная настройка CentOS 7

Итак, у нас имеется: # uname -a Linux zeroxzed.ru 3.10.0-123.20.1.el7.x86_64 #1 SMP Thu Jan 29 18:05:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Первым делом обновим базовую систему:

# yum update

Для удобства администрирования, я всегда устанавливаю Midnight Commander, или просто mc:

# yum install mc

И сразу же для него включаю подсветку синтаксиса всех файлов, которые не обозначены явно в файле /usr/share/mc/syntax/Syntax синтаксисом для sh и bash скриптов. Этот универсальный синтаксис нормально подходит для конфигурационных файлов, с которыми чаще всего приходится работать на сервере. Перезаписываем файл unknown.syntax . Именно этот шаблон будет применяться к.conf и.cf файлам, так как к ним явно не привязано никакого синтаксиса.

# cp /usr/share/mc/syntax/sh.syntax /usr/share/mc/syntax/unknown.syntax

# ifconfig

И увидите ответ:

Bash: ifconfig: command not found

По крайней мере я, когда впервые это увидел, прилично удивился. Подумал, что ошибся в написании команды, перепроверил все несколько раз, но без результата. Оказалось, что надо отдельно установить пакет для выполнения ifconfig и прочих сетевых утилит.

Вместо ifconfig в CentOS 7 теперь утилита ip . Я не понимаю, зачем пилить отдельные программы для управления сетевыми настройками, если ifconfig и так отлично справляется с задачей. К тому же мне всегда нравилось, что в различных дистрибутивах линукс все примерно одинаковое. С помощью ifconfig можно настроить сеть не только в linux, но и в freebsd. Это удобно. А когда в каждом дистрибутиве свой инструмент это неудобно. Так что предлагаю установить привычный ifconfig.

Сделаем это:

# yum install net-tools

Теперь, чтобы у нас работали команды nslookup или, к примеру, host необходимо установить пакет bind-utils. Если этого не сделать, то на команду:

# nslookup

Будет вывод:

Bash: nslookup: command not found

Так что устанавливаем bind-utils:

# yum install bind-utils

Отключаем SELinux. Его использование и настройка отдельный разговор. Сейчас я не буду этим заниматься. Так что отключаем:

# mcedit /etc/sysconfig/selinux

меняем значение
SELINUX=disabled
Чтобы изменения вступили в силу, перезагружаемся:

# reboot

Можно без перезагрузки применить отключение SElinux:

# setenforce 0

Указываем сетевые параметры

Теперь произведем настройку сети в CentOS. Для этого открываем файл /etc/sysconfig/network-scripts/ifcfg-eth0

# mcedit /etc/sysconfig/network-scripts/ifcfg-eth0

В поле IPADDR вводим свой адрес, в NETMASK маску сети, в GATEWAY шлюз, DNS1 адрес днс сервера. Сохраняем файл и перезапускаем сеть для применения настроек:

# /etc/init.d/network restart

Настраиваем firewall

Сейчас мы быстро и просто настроим firewall. В CentOS 7 в качестве фаервола выступает iptables. По-умолчанию он запущен. Чтобы посмотреть текущие правила, нужно ввести команду:

# iptables -L -v -n

Сразу хочу предупредить, что не имея доступа к консоли сервера, настраивать firewall плохая идея. Даже если вы очень хорошо понимаете что делаете и проделывали подобное много раз, все равно есть шанс остаться без доступа к серверу. Так что первым делом перед настройкой iptables проверяем доступ к консоли через KVM или физически.

В 7-й версии CentOS для управления iptables разработан новый инструмент под названием firewalld и все управление производится через него. Я не понял зачем это сделали, и не могу сказать, удобнее с ним стало или нет. По мне, так удобнее использовать одни и те же наработки по iptables. Мигрируя от сервера к серверу и от дистрибутива к дистрибутиву, я просто редактирую скрипт настроек фаервола.

Но CentOS зачем-то придумали firewalld, в Ubuntu стоит ufw, но суть одна и та же - это утилиты для конфигурирования iptables, который один и тот же во всех дистрибутивах. Я привык управлять iptables через самописный скрипт, который переношу от сервера к серверу и редактирую под конкретные потребности. Этим скриптом я и поделюсь. Так что для начала остановим и отключим firewalld:

# systemctl stop firewalld # systemctl disable firewalld rm "/etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service" rm "/etc/systemd/system/basic.target.wants/firewalld.service"

Установим утилиты для iptables:

# yum -y install iptables-services

Включим автозапуск iptables:

# systemctl enable iptables

Теперь создадим файл /etc/iptables_rules.sh следующего содержания:

#!/bin/bash # # Объявление переменных export IPT="iptables" # Интерфейс который смотрит в интернет export WAN=eth0 export WAN_IP=149.154.71.205 # Очистка всех цепочек iptables $IPT -F $IPT -F -t nat $IPT -F -t mangle $IPT -X $IPT -t nat -X $IPT -t mangle -X # Установим политики по умолчанию для трафика, не соответствующего ни одному из правил $IPT -P INPUT DROP $IPT -P OUTPUT DROP $IPT -P FORWARD DROP # разрешаем локальный траффик для loopback $IPT -A INPUT -i lo -j ACCEPT $IPT -A OUTPUT -o lo -j ACCEPT # Разрешаем исходящие соединения самого сервера $IPT -A OUTPUT -o $WAN -j ACCEPT # Состояние ESTABLISHED говорит о том, что это не первый пакет в соединении. # Пропускать все уже инициированные соединения, а также дочерние от них $IPT -A INPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT # Пропускать новые, а так же уже инициированные и их дочерние соединения $IPT -A OUTPUT -p all -m state --state ESTABLISHED,RELATED -j ACCEPT # Разрешить форвардинг для уже инициированных и их дочерних соединений $IPT -A FORWARD -p all -m state --state ESTABLISHED,RELATED -j ACCEPT # Включаем фрагментацию пакетов. Необходимо из за разных значений MTU $IPT -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu # Отбрасывать все пакеты, которые не могут быть идентифицированы # и поэтому не могут иметь определенного статуса. $IPT -A INPUT -m state --state INVALID -j DROP $IPT -A FORWARD -m state --state INVALID -j DROP # Приводит к связыванию системных ресурсов, так что реальный # обмен данными становится не возможным, обрубаем $IPT -A INPUT -p tcp ! --syn -m state --state NEW -j DROP $IPT -A OUTPUT -p tcp ! --syn -m state --state NEW -j DROP # Рзрешаем пинги $IPT -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT $IPT -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT $IPT -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT $IPT -A INPUT -p icmp --icmp-type echo-request -j ACCEPT # Открываем порт для ssh $IPT -A INPUT -i $WAN -p tcp --dport 22 -j ACCEPT # Открываем порт для DNS #$IPT -A INPUT -i $WAN -p udp --dport 53 -j ACCEPT # Открываем порт для NTP #$IPT -A INPUT -i $WAN -p udp --dport 123 -j ACCEPT # Логирование # Все что не разрешено, но ломится отправим в цепочку undef $IPT -N undef_in $IPT -N undef_out $IPT -N undef_fw $IPT -A INPUT -j undef_in $IPT -A OUTPUT -j undef_out $IPT -A FORWARD -j undef_fw # Логируем все из undef $IPT -A undef_in -j LOG --log-level info --log-prefix "-- IN -- DROP " $IPT -A undef_in -j DROP $IPT -A undef_out -j LOG --log-level info --log-prefix "-- OUT -- DROP " $IPT -A undef_out -j DROP $IPT -A undef_fw -j LOG --log-level info --log-prefix "-- FW -- DROP " $IPT -A undef_fw -j DROP # Записываем правила /sbin/iptables-save > /etc/sysconfig/iptables

В принципе, добавить нечего, в файле даны все комментарии. В таком виде, логи всего заблокированного будут писаться в файл /var/log/messages и записей там будет очень много. Так что в обычной работе эти строки нужно закомментировать, и использовать только во время отладки. Более подробное описание правил и примеры настроек firewall в случае, когда ваш сервер является шлюзом локальной сети, приведено по ссылке в начале раздела.

Делаем файл c правилами исполняемым и запускаем:

# chmod 0740 /etc/iptables_rules.sh # /etc/iptables_rules.sh

Проверяем, применились ли правила:

# iptables -L -v -n

При каждом запуске файла с правилами iptables, все изменения записываются в файл /etc/sysconfig/iptables и применяются при загрузке системы.

Настройка SSH в CentOS 7

Дальше внесем некоторые изменения в работу ssh для увеличения безопасности. По-умолчанию, сервис работает на 22 порту и если все оставить как есть, то мы получим огромное количество попыток авторизоваться. Боты сканят непрерывно интернет и подбирают пароли к ssh. Чтобы обезопасить себя от сканов простых ботов, изменим порт, на котором работает ssh. Можно выбрать любой пятизначный номер, это не принципиально. От автоматического сканирования это защитит. Повесим демон ssh на 25333 порт. Для этого редактируем файл /etc/ssh/sshd_config

# mcedit /etc/ssh/sshd_config

Раскомментируем строку Port 22 и заменим значение 22 на 25333.
Так же я обычно разрешаю подключаться по ssh пользователю root. Мне так удобнее. Проблем с этим у меня никогда не возникало. Если вы считаете, что это не безопасно, не трогайте эту настройку. Чтобы разрешить пользователю root подключаться по ssh, раскомментируйте строку PermitRootLogin yes.

Сохраняем файл. Теперь обязательно изменяем настройки iptables, добавляем в разрешенные подключения вместо 22 порта 25333. Если этого не сделать, то после перезапуска sshd мы потеряем удаленный доступ к серверу. Итак, открываем /etc/iptables_rules.sh и меняем в строке

$IPT -A INPUT -i $WAN -p tcp --dport 22 -j ACCEPT

22 на 25333 и исполняем файл. Наше текущее соединение не оборвется, так как оно уже установлено, но заново подключиться по ssh к 22 порту уже н получится.

Перезапускаем sshd:

# systemctl restart sshd

Проверяем какой порт слушает sshd:

# netstat -tulpn | grep sshd tcp 0 0 0.0.0.0:25333 0.0.0.0:* LISTEN 1799/sshd tcp6 0 0:::25333:::* LISTEN 1799/sshd

Если вывод такой же как у меня, то все в порядке, теперь к ssh можно подключаться по 25333 порту.

Добавим еще одну небольшую настройку. Иногда, когда возникают проблемы с dns сервером, логин по ssh подвисает на 30-60 секунд. Вы просто ждете после ввода логина, когда появится возможность ввести пароль. Чтобы избежать этого замедления, укажем ssh не использовать dns в своей работе. Для этого в конфиге раскомментируем строку с параметром UseDNS и отключим его. По-умолчанию он включен.

UseDNS no

Для применения изменений нужно перезапустить ssh службу, как мы уже делали ранее.

Настраиваем время

Узнать, какое время на сервере можно с помощью команды date:

Чтобы сменить часовой пояс, необходимо выбрать подходящий файл часовой зоны в /usr/share/zoneinfo. В случае, если у вас часовой пояс Москвы, выполните следующее:

# mv /etc/localtime /etc/localtime.bak # ln -s /usr/share/zoneinfo/Europe/Moscow /etc/localtime

Либо можете воспользоваться специальной утилитой, которая входит в комплект CentOS 7. Делает она ровно то же самое:

# timedatectl set-timezone Europe/Moscow

В CentOS 7 есть утилита для синхронизации времени chrony . В стандартной установке она должна быть установлена в системе, в минимальной ее нет. Если у вас она не стоит, то устанавливайте вручную:

# yum install chrony

Запускаем chrony и добавляем в автозагрузку:

# systemctl start chronyd # systemctl enable chronyd

Проверяем, нормально ли запустился:

# systemctl status chronyd ● chronyd.service - NTP client/server Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2016-08-05 00:33:09 MSK; 52min left Main PID: 667 (chronyd) CGroup: /system.slice/chronyd.service └─667 /usr/sbin/chronyd Aug 05 00:33:09 centos.local systemd: Starting NTP client/server... Aug 05 00:33:09 centos.local chronyd: chronyd version 2.1.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +DEBUG +ASYNCDNS +IPV6 +SECHASH) Aug 05 00:33:09 centos.local chronyd: Generated key 1 Aug 05 00:33:09 centos.local systemd: Started NTP client/server. Aug 05 00:33:26 centos.local chronyd: Selected source 85.21.78.91 Aug 05 00:33:26 centos.local chronyd: System clock wrong by -3595.761368 seconds, adjustment started Aug 04 23:33:30 centos.local chronyd: System clock was stepped by -3595.761368 seconds

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

Для синхронизации времени вы можете воспользоваться более привычно программой, которая присутствует практически во всех unix дистрибутивах - ntp . Устанавливаем утилиту синхронизации времени ntp в CentOS:

# yum install ntp

Разово синхронизируем время:

# /usr/sbin/ntpdate pool.ntp.org

Если ntpdate не работает, посмотрите материал, может это ваш случай. Запустим демон синхронизации и запишем его запуск в автозагрузку:

# systemctl start ntpd # systemctl enable ntpd ln -s "/usr/lib/systemd/system/ntpd.service" "/etc/systemd/system/multi-user.target.wants/ntpd.service"

Теперь наши часы будут автоматически синхронизироваться с сервером времени.

Не используйте одновременно оба демона синхронизации времени - chrony и ntp. Выберите какой-нибудь один. Лично я не вижу в них разницы, сам чаще всего ставлю привычный ntp.

Добавление репозиториев

Для инсталляции различного софта необходимо подключить репозитории в CentOS. Наиболее популярные это EPEL и rpmforge, поэтому добавим их. Сначала ставим EPEL. С ним все просто, он добавляется из стандартного репозитория:

# yum install epel-release

Устанавливаем rpmforge:

# rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt # yum install http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el7.rf.x86_64.rpm

# yum install http://repository.it4i.cz/mirrors/repoforge/redhat/el7/en/x86_64/rpmforge/RPMS/rpmforge-release-0.5.3-1.el7.rf.x86_64.rpm

Настройка хранения истории в bash_history

Полезным будет внести некоторые изменения в стандартный механизм сохранения истории команд. Он часто выручает, когда надо вспомнить одну из ранее введенных команд. Стандартные настройки имеют некоторые ограничения, которые неудобны. Вот их список:

  1. По-умолчанию, сохраняются только последние 1000 команд. Если их будет больше, то более старые будут удаляться и заменяться новыми.
  2. Не указаны даты выполнения команд, только их список в порядке выполнения.
  3. Файл со списком команд обновляется после завершения сессии. При параллельных сессиях часть команд может быть утеряна.
  4. Сохраняются абсолютно все команды, хотя в хранении некоторых нет никакого смысла.

Список последних выполненных команд хранится в домашней директории пользователя в файле .bash_history (в начале точка). Его можно открыть любым редактором и посмотреть. Для более удобного вывода списка, можно в консоли ввести команду:

# history

и увидеть пронумерованный список. Быстро найти конкретную команду, можно с помощью фильтрации только нужных строк, например вот так:

# history | grep yum

Так мы увидим все варианты запуска команды yum, которые хранятся в истории. Исправим перечисленные недостатки стандартных настроек хранения истории команд в CentOS 7. Для этого нужно отредактировать файл .bashrc , который находится в том же каталоге, что и файл с историей. Добавляем в него следующие строки:

Export HISTSIZE=10000 export HISTTIMEFORMAT="%h %d %H:%M:%S " PROMPT_COMMAND="history -a" export HISTIGNORE="ls:ll:history:w:htop"

Первый параметр увеличивает размер файла до 10000 строк. Можно сделать и больше, хотя обычно хватает такого размера. Второй параметр указывает, что необходимо сохранять дату и время выполнения команды. Третья строка вынуждает сразу же после выполнения команды сохранять ее в историю. В последней строке мы создаем список исключений для тех команд, запись которых в историю не требуется. Я привел пример самого простого списка. Можете дополнить его на свое усмотрение.

Для применения изменений необходимо разлогиниться и подключиться заново или выполнить команду:

# source ~/.bashrc

Автоматическое обновление системы

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

Для автоматической проверки обновлений нам поможет утилита yum-cron . Ставится она традиционно через yum из стандартного репозитория.

# yum install yum-cron

После установки создается автоматическое задание на выполнение утилиты в /etc/cron.daily и /etc/cron.hourly . По-умолчанию, утилита скачивает найденные обновления, но не применяет их. Вместо этого, администратору на локальный почтовый ящик root отправляется уведомление об обновлениях. Дальше вы уже в ручном режиме заходите и решаете, устанавливать обновления или нет в удобное для вас время. Мне такой режим работы видится наиболее удобным, поэтому я не меняю эти настройки.

Конфигурационные файлы yum-cron находятся по адресу /etc/yum/yum-cron.conf и yum-cron-hourly.conf . Они неплохо прокомментированы, так что в подробных разъяснениях не нуждаются. Обращаю внимание на раздел , где можно указать параметры отправки сообщений. По-умолчанию стоит отправка почты через локальный хост. Можно тут изменить параметры и отправлять сообщения через сторонний почтовый сервер. Но вместо этого лично я предпочитаю глобально для всего сервера настроить пересылку локальной почты root на внешний почтовый ящик через авторизацию на другом smtp сервере.

Отключаем флуд сообщений в /var/log/messages

В дефолтной установке системы CentOS 7, весь ваш системный лог /var/log/messages через некоторое время работы сервера будет забит следующими записями.

Oct 16 14:01:01 xs-files systemd: Created slice user-0.slice. Oct 16 14:01:01 xs-files systemd: Starting user-0.slice. Oct 16 14:01:01 xs-files systemd: Started Session 14440 of user root. Oct 16 14:01:01 xs-files systemd: Starting Session 14440 of user root. Oct 16 14:01:01 xs-files systemd: Removed slice user-0.slice. Oct 16 14:01:01 xs-files systemd: Stopping user-0.slice. Oct 16 15:01:01 xs-files systemd: Created slice user-0.slice. Oct 16 15:01:01 xs-files systemd: Starting user-0.slice. Oct 16 15:01:01 xs-files systemd: Started Session 14441 of user root. Oct 16 15:01:01 xs-files systemd: Starting Session 14441 of user root. Oct 16 15:01:01 xs-files systemd: Started Session 14442 of user root. Oct 16 15:01:01 xs-files systemd: Starting Session 14442 of user root. Oct 16 15:01:01 xs-files systemd: Removed slice user-0.slice. Oct 16 15:01:01 xs-files systemd: Stopping user-0.slice. Oct 16 16:01:01 xs-files systemd: Created slice user-0.slice. Oct 16 16:01:01 xs-files systemd: Starting user-0.slice. Oct 16 16:01:01 xs-files systemd: Started Session 14443 of user root. Oct 16 16:01:01 xs-files systemd: Starting Session 14443 of user root. Oct 16 16:01:01 xs-files systemd: Removed slice user-0.slice.

Никакой практической пользы они не несут, поэтому отключим их. Для этого создадим отдельное правило для rsyslog, где перечислим все шаблоны сообщений, которые будем вырезать. Разместим это правило в отдельном файле /etc/rsyslog.d/ignore-systemd-session-slice.conf .

# cd /etc/rsyslog.d && mcedit ignore-systemd-session-slice.conf if $programname == "systemd" and ($msg contains "Starting Session" or $msg contains "Started Session" or $msg contains "Created slice" or $msg contains "Starting user-" or $msg contains "Starting User Slice of" or $msg contains "Removed session" or $msg contains "Removed slice User Slice of" or $msg contains "Stopping User Slice of") then stop

Сохраняем файл и перезапускаем rsyslog для применения настроек.

# systemctl restart rsyslog

Необходимо понимать, что в данном случае мы отключаем флуд в лог файл только на локальном сервере. Если вы храните логи на удаленном syslog сервере, то данное правило нужно будет настраивать именно на нем.

Установка iftop, atop, htop, lsof на CentOS 7

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

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

# yum install iftop

И два интересных диспетчера задач, я чаще всего пользуюсь htop, но иногда пригодится и atop. Ставим оба, сами посмотрите, разберетесь, что вам больше нравится, подходит:

# yum -y install htop # yum -y install atop

Вот как выглядит htop:

Для вывода информации о том, какие файлы используются теми или иными процессами, советую поставить утилиту lsof . Она скорее всего рано или поздно пригодится, когда будете диагностировать работу сервера.

# yum install wget bzip2 traceroute gdisk

На этом у меня все. Базовая настройка CentOS 7 закончена, можно приступать к установке и настройке основного функционала.

Настройка системной почты

В завершение настройки сервера CentOS 7 сделаем так, что бы почта, адресованная локальному root, отправлялась через внешний почтовый сервер на выбранный почтовый ящик. Если этого не сделать, то она будет локально складываться в файл /var/spool/mail/root . А там может быть важная и полезная информация. Настроим ее отправку в ящик системного администратора.

Здесь кратко только команды и быстрая настройка. Ставим необходимые пакеты:

# yum install mailx cyrus-sasl cyrus-sasl-lib cyrus-sasl-plain

Рисуем примерно такой конфиг для postfix.

Cat /etc/postfix/main.cf ## DEFAULT CONFIG BEGIN ###################### queue_directory = /var/spool/postfix command_directory = /usr/sbin daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix mail_owner = postfix inet_interfaces = localhost inet_protocols = all unknown_local_recipient_reject_code = 550 alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 sendmail_path = /usr/sbin/sendmail.postfix newaliases_path = /usr/bin/newaliases.postfix mailq_path = /usr/bin/mailq.postfix setgid_group = postdrop html_directory = no manpage_directory = /usr/share/man sample_directory = /usr/share/doc/postfix-2.10.1/samples readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES ## DEFAULT CONFIG END ###################### # Имя сервера, которое выводит команда hostname myhostname = centos7-test.xs.local # Здесь по логике нужно оставлять только домен, но в данном случае лучше оставить полное имя сервера, чтобы в поле отправитель # фигурировало полное имя сервера, так удобнее разбирать служебные сообщения mydomain = centos7-test.xs.local mydestination = $myhostname myorigin = $mydomain # Адрес сервера, через который будем отправлять почту relayhost = mailsrv.mymail.ru:25 smtp_use_tls = yes smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = noanonymous smtp_tls_security_level = may

Создаем файл с информацией об имени пользователя и пароле для авторизации.

# mcedit /etc/postfix/sasl_passwd mailsrv.mymail.ru:25 [email protected]:password

Создаем db файл.

# postmap /etc/postfix/sasl_passwd

Теперь можно перезапустить postfix и проверить работу.

# systemctl restart postfix

К стандартному алиасу для root в /etc/aliases , добавьте внешний адрес, куда будет дублироваться почта, адресованная root. Для этого редактируем указанный файл, изменяя последнюю строку.

#root: marc

Root: root,[email protected]

Обновляем базу сертификатов:

# newaliases

Отправим письмо через консоль локальному руту:

# df -h | mail -s "Disk usage" root

Письмо должно уйти на внешний ящик. На этом настройка локальной почты закончена. Теперь все письма, адресованные локальному root, например, отчеты от cron, будут дублироваться на внешний почтовый ящик, причем с отправкой через нормальный почтовый сервер. Так что письма будут нормально доставляться, не попадая в спам (хотя не обязательно, есть еще эвристические фильтры).

Заключение

Мы выполнили некоторые начальные шаги по настройке сервера CentOS 7, которые я обычно делаю при подготовке сервера. Я не претендую на абсолютную истину, возможно что-то упускаю или делаю не совсем верно. Буду рад разумным и осмысленным комментариям и замечаниям с предложениями.

Полезно после базовой настройки сразу же подключить сервер к системе мониторинга. Либо настроить ее, если у вас еще нет.

Видео по настройке CentOS 7