Шифрование файлов и папок в Linux. Зачем нужно шифрование. Порядок выполнения работы
У меня имеется свежеустановленный сервер 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
Полезным будет внести некоторые изменения в стандартный механизм сохранения истории команд. Он часто выручает, когда надо вспомнить одну из ранее введенных команд. Стандартные настройки имеют некоторые ограничения, которые неудобны. Вот их список:
- По-умолчанию, сохраняются только последние 1000 команд. Если их будет больше, то более старые будут удаляться и заменяться новыми.
- Не указаны даты выполнения команд, только их список в порядке выполнения.
- Файл со списком команд обновляется после завершения сессии. При параллельных сессиях часть команд может быть утеряна.
- Сохраняются абсолютно все команды, хотя в хранении некоторых нет никакого смысла.
Список последних выполненных команд хранится в домашней директории пользователя в файле .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
Это руководство больше не обновляется
gpg4usb - бесплатная портативная шифровальная программа с открытым кодом. Она использует тот же алгоритм открытых ключей, что и популярные программы GPG и PGP .
Главная функция: шифрование текста (включая электронную почту) и файлов
Операционная система: все версии Windows
Лицензия: бесплатная, с открытым кодом
Используемая здесь версия программы: 0.3.3
Объем архива: 16 Мб
Последняя редакция этого материала: август 2014 г.
- Главу нашего руководства
- Руководство "Цифровая безопасность и приватность" (англ.)
Что вы получите в результате
- Умение шифровать текстовые сообщения и файлы, где бы вы ни находились (например, на работе или в интернет-кафе)
- Умение шифровать сообщения, не будучи в интернете (или когда доступа к сети нет), а затем посылать их с компьютера, у которого есть доступ к интернету.
Приготовления к работе
- Щелкаем по значку gpg4usb ниже и открываем сайт http://www.gpg4usb.org .
- Щелкаем по большой зеленой кнопке в правой части страницы и скачиваем к себе на компьютер архив zip.
- Распаковываем архив.
- После этого можно удалить архив.
Полезная информация перед началом работы
gpg4usb использует шифровальный алгоритм с открытым ключом. Это значит, что с помощью программы человек создает свою уникальную пару ключей. Первый ключ называется "закрытым" (или "секретным"). Владелец защищает этот ключ паролем и хранит в надежном месте. Второй ключ называется "открытым". Его можно открыто передавать своим знакомым. Особенность этой пары ключей - то, что зашифровано одним, можно расшифровать только другим, парным.
Допустим, некто хочет отправить вам зашифрованное письмо. Он использует ваш открытый ключ, шифрует с его помощью текст и отправляет вам по электронной почте. Расшифровать послание можете только вы. Ведь только у вас есть подходящий (парный) закрытый ключ.
Наоборот: если вы хотите ответить шифровкой, используйте открытый ключ адресата. А он применит свой секретный ключ, чтобы прочесть текст письма.
Алгоритм также полезен, если нужно обеспечить целостность письма. В этом нам поможет электронная подпись. Вы используете свой закрытый ключ, чтобы подписать сообщение. После этого всякий может использовать ваш открытый ключ и удостовериться, что письмо действительно подписано вами, и в процессе передачи в текст не вносились никакие изменения.
Всё это можно делать с помощью gpg4usb .
Примечание. Будьте внимательны: исходное (незашифрованное) письмо по-прежнему хранится на вашем компьютере. Если важна секретность, после отправки письма лучше удалить оригинал.
Шифровальные ключи и зашифрованные с помощью gpg4usb сообщения совместимы с другими программами, в частности, GPG и PGP .
Начало работы и создание ключей
Распаковываем архив zip в папку на диске и запускаем приложение start_windows.exe. Открывается главное окно программы.
Перед тем, как что-то зашифровывать (или расшифровывать), нужно выполнить два важных шага: во-первых, создать пару ключей (открытый и секретный), во-вторых, обменяться открытыми ключами с вашими адресатами. О том, как экспортировать открытый ключ из программы, поговорим в следующей части, а сейчас создадим пару ключей.
Внимание: Мы описываем запуск "мастера создания ключей" в общем случае (через меню программы). В случае, если gpg4usb только что установлена на компьютер, мастер создания ключей запустится автоматически.
Выбираем в меню "Ключ" - "Генерировать ключ".
Появляется следующее окно.
Имя - имя владельца ключа. Служит для визуального опознания, кому принадлежит ключ (что-то вроде имени на шкафчике). Лучше использовать латиницу, так как не все программы шифрования сегодня "понимают" кириллицу. Из соображений безопасности вы можете не указывать свое настоящее имя. Однако, следует понимать, что этим вы можете сбить с толку тех, кто с вами обменивается шифрованными сообщениями.
Адрес email - адрес электронной почты. Справедливо все то, о чем написано в предыдущем абзаце.
Комментарий - можно пропустить.
Истекает - дата окончания действия ключа. По достижении этой даты открытый ключ уже нельзя будет использовать для шифрования. Обычно это ограничение служит дополнительной страховкой на случай, если ключевая пара окажется скомпрометирована (злоумышленник, завладевший ключами, по крайней мере, не сможет пользоваться ими вечно). Если вам это не нужно, ставим галочку в поле "без срока годности".
Длина ключа (бит) - чем длиннее ключ, тем надежнее защита и дольше длится шифрование/расшифровка. Значение по умолчанию (2048 бит) вполне достаточно.
Пароль - пароль для защиты секретного ключа. (Загляните в раздел "Как создавать и хранить надежные пароли").
Щелкните по кнопке "ОК".
По окончании появится финальное окошко:
Можете убедиться, что ключ появился в списке.
Значок с двумя ключиками подразумевает, что это не открытый ключ, а пара ключей (открытый и секретный).
Теперь, когда вы успешно создали пару ключей, нужно экспортировать открытый ключ из программы, чтобы другие люди могли шифровать письма для вас. И, наоборот, импортировать их ключи, чтобы вы могли посылать им шифрованные сообщения. О том, как это сделать, поговорим в следующей части.
Экспорт и импорт ключей
Как экспортировать свой открытый ключ
Перед тем, как обмениваться шифрованными сообщениями, нужно обменяться с адресатом открытыми ключами. Чтобы другие люди могли посылать вам шифровки, они должны использовать ваш открытый ключ. Но он хранится "где-то в программе", не так ли? Давайте его экспортируем.
Щелкаем по кнопке Менеджера ключей.
Выбираем ключ (ставим галочку рядом с именем) и щелкаем на панели управления по кнопке "Экспортировать в файл". Сохраняем файл на диск.
Файл будет иметь несколько длинное и корявое название вроде *John Doe [email protected](015A8EAF8C28FA30)_pub* и расширение .asc . Суффикс pub в имени файла указывает, что экспортирован только открытый ключ (public key). Кстати, этот файл имеет обычный текстовый формат: при желании можете заглянуть внутрь с помощью какого-нибудь редактора (например, "Блокнота") и посмотреть, как он выглядит.
Фраза "BEGIN PGP PUBLIC KEY BLOCK" означает "Начало блока открытого ключа PGP". Это стандарт для всех открытых ключей.
Gpg4usb позволяет не только сохранять выбранный ключ на диск, но и копировать его в буфер обмена с помощью соседней кнопки на панели инструментов Менеджера ключей:
Как импортировать чужой открытый ключ
Чтобы посылать шифрованные сообщения другу, вам нужно использовать его открытый ключ. Предположим, друг успел экспортировать свой ключ (как показано выше) и отправить вам файл с ключом. Наша задача - импортировать этот ключ в нашу программу gpg4usb.
Щелкаем по кнопке импорта ключей на панели инструментов. В появившемся списке выбираем первый пункт "Файл".
Находим на диске файл с ключом, выбираем его и убеждаемся, что ключ нашего друга появился в списке.
Как проверить открытый ключ
Иногда можно быть вполне уверенным, что полученный вами открытый ключ действительно принадлежит вашему другу (например, если он передает вам его лично в руки на флэшке). Но часто прямой связи нет. При определенных обстоятельствах злоумышленник может подсунуть вместо ключа друга другой, "фальшивый", иначе говоря - свой собственный. И тогда злоумышленник сможет прочесть шифрованное сообщение, которое вы отправили другу (а вот друг не сможет). Как удостовериться, что ключ настоящий?
- Свяжитесь с другом по какому-нибудь другому каналу связи, например, по Skype.
- Удостоверьтесь, что действительно говорите с нужным человеком (звук его голоса и картинка помогут рассеять сомнения).
- Попросите друга передать вам отпечаток его ключа.
Отпечаток ключа - серия знаков, которой сопровождается каждый ключ. Сам по себе он не секретный, но уникальный. Если отпечаток того ключа, который вы получили (например) по электронной почте, и отпечаток, которым поделился ваш друг в Skype, совпадут, значит, у вас в руках правильный, настоящий ключ.
Чтобы увидеть отпечаток, достаточно щелкнуть правой кнопкой мыши по ключу и выбрать в контекстном меню "Показать свойства ключа".
В появившемся окне можно видеть отпечаток ключа. Соседняя кнопка позволяет скопировать отпечаток в буфер обмена.
Вашему адресату нужно повторить эти шаги. Убедитесь, что отпечатки совпадают. Если нет, попробуйте снова обменяться открытыми ключами (возможно, через другие адреса e-mail или вообще другим способом связи) и еще раз проверьте отпечатки. Если они полностью совпадают, можно быть уверенным, что вы обладаете правильными ключами.
Как шифровать и расшифровывать
Как зашифровать текст
- Копируем текст, который нужно зашифровать, в буфер обмена, а затем вставляем его в окно редактора ("безымянный1.txt").
- Выбираем открытый ключ адресата (ставим галочку) и нажимаем на кнопку "Зашифровать текст" на панели управления.
В окне редактора появляется зашифрованный текст.
Можно зашифровать сообщение сразу нескольким адресатам. Достаточно поставить галочки напротив соответствующих открытых ключей.
Примечание. Короткий текст после шифрования обычно "вырастает в размерах", и это бросается в глаза. Не волнуйтесь, здесь нет прямой пропорции. То есть, большой документ не вырастет во столько же раз, во сколько вырастает короткий текст.
Как расшифровать текст
- Выделяем зашифрованный текст в окне почтовой программы (службы) или редактора (словом, там, где он виден), копируем его в буфер памяти и вставляем в окно редактора gpg4usb.
- Нажимаем на кнопку "Расшифровать текст".
- Программа запрашивает пароль (к секретному ключу, который используется для расшифровки). Вводим пароль и нажимаем "ОК".
Расшифрованный текст появится в окне программы.
Примечание. Важно вставлять в окно gpg4usb шифрованный текст целиком, включая заголовок BEGIN PGP MESSAGE и завершение END PGP MESSAGE.
Шифрование файла столь же простое дело, как шифрование текста.
- Щелкаем по кнопке "Зашифровать или расшифровать файл" на панели инструментов. В контекстном меню выбираем "Зашифровать файл".
Появляется окно с выбором файла.
- Файл ввода - выбираем на диске файл, который собираемся зашифровать.
- Файл вывода - придумываем имя файла, куда будет сохранен результат.
- Выбираем (ставим галочку) ключ адресата, которому предназначается шифрованный файл, и нажимаем на кнопку "ОК".
Можно убедиться, что по указанному пути появился новый зашифрованный файл. Теперь его можно передать адресату, например, по электронной почте.
Для программы не имеет значения, какого типа файлы вы шифруете. Это могут быть документы, электронные таблицы, презентации, словом, что угодно. Не забудьте: для шифрования файла большого размера может понадобиться время.
Примечание. При шифровании выполняется сжатие файла. Нет необходимости отдельно сжимать (архивировать) файлы перед шифрованием.
Примечание. Важно: имя файла не шифруется. Если вы отправляете адресату деликатную информацию, помните об этом. Лучше дать файлу какое-нибудь нейтральное, отвлеченное имя.
Как расшифровать файл
- Щелкаем по кнопке "Зашифровать или расшифровать файл" на панели инструментов. В контекстном меню выбираем "Расшифровать файл".
- Появляется окно, где нужно выбрать на диске файл ввода (зашифрованный) и указать желаемый файл вывода (результат).
- Вводим пароль к нашему секретному ключу.
Всё. Можно убедиться, что расшифрованный файл есть на диске.
Примечание. Если вы работаете в интернет-кафе или вообще не на своем компьютере, возможно, лучше сохранить зашифрованный файл на USB-флэшке, чтобы потом расшифровать его в более безопасной обстановке.
Резервное копирование ключей
Как и любые другие важные данные, шифровальные ключи требуют бережного обращения. (См. главу "Как избежать потери данных"). Так, известно немало случаев, когда люди переустанавливали операционную систему, предварительно скопировав свои данные, но позабыв о ключах. Конечно, можно создать новую пару ключей; но без прежнего секретного ключа вы не сможете прочесть ни одно из отправленных вам ранее зашифрованных писем.
Конечно, gpg4usb - портативная программа и может работать с USB-флэшки. Но и флэшки, бывает, портятся, теряются, или они попадают в чужие руки, которые (умышленно или нет) стирают важные данные. Поэтому лучше иметь резервные копии ключей.
Как экспортировать свой секретный ключ
Программное обеспечение
GnuPG служит для создания цифровых подписей и шифрования данных. Например, вопрос идентификации писем всегда был актуальным. С помощью GnuPG можно «вложить» в письмо электронную подпись.
Предисловие
В последнее время очень остро стоит проблема сохранения конфиденциальности информации. Особенно в глобальной сети Интернет, где риск перехвата секретных данных весьма высок. В этой статье будет представлено описание работы пакета GnuPG (GNU Privacy Guard, GPG) вкупе с несколькими примерами применения.
GnuPG служит для создания цифровых подписей и шифрования данных. Например, вопрос идентификации писем всегда был актуальным. С помощью GnuPG можно «вложить» в письмо электронную подпись. И, таким образом, получатель определит подлинность отправителя и принадлежность ему этого письма. Процесс работы GnuPG весьма прост: за сложнейшими алгоритмами шифрования скрыта простая логика: используется пара ключей, один из которых является приватным (вы его держите у себя), а второй - публичным (он свободно бороздит просторы Сети). Файл второго содержит публичный ключ и подписи ваших респондентов. Получается, что после доставки подписанного письма получатель сравнивает публичные ключи, и таким образом идентифицирует отправителя.
Особенности GnuPG
Основные технические особенности GnuPG таковы:
- полноценная альтернатива PGP;
- не использует патентованные алгоритмы;
- распространяется под лицензией GPL;
- полная реализация OpenPGP (RFC4880);
- расшифровывание и аутентификация сообщений, созданных с помощью PGP 5, 6 и 7;
- поддержка электронной подписи с помощью алгоритмов ElGamal, DSA, RSA и хеш-функций MD5, SHA-1, RIPE-MD-160 и TIGER;
- работа с асимметричным шифрованием ElGamal и RSA (длина ключа от 1024 до 4096 бит);
- поддержка блочных алгоритмов симметричного шифрования AES, 3DES, Blowfish, Twofish, CAST5, а также IDEA с помощью модуля;
- лёгкая реализация новых алгоритмов с помощью дополнительных модулей;
- многоязыковая поддержка (в том числе и русского);
- online-система помощи;
- поддержка просроченных ключей и подписей;
- встроенная поддержка HKP-серверов ключей.
Как уже было отмечено, GnuPG разработан в соответствии со стандартом OpenPGP, а это значит, что подписи и зашифрованные данные, созданные другими программами, совместимыми с OpenPGP, будут работать с GnuPG. Использование различных криптографических алгоритмов, таких как симметричные шифры, шифрование с открытым ключом и смешанные алгоритмы, позволяет надёжно защищать секретные данные и передавать их. Длины ключа в 1024 или 2048 бит достаточно, чтобы не беспокоиться о взломе зашифрованной информации.
GnuPG - исключительно консольная программа, но уже сейчас существует несколько графических оболочек для неё: Seahorse и , - которые упрощают работу с программой посредством интуитивно понятного графического интерфейса.
Работа с GnuPG
Первое взаимодействие с пакетом GnuPG начинается с генерирования ключей:
$ gpg --gen-key
Программа задаст несколько вопросов о длине ключей, имени и адресе электронной почты. Затем нужно будет ввести пароль для защиты ключа. Таким образом будет создана пара ключей, один из которых будет основным. Его стоит использовать для шифрования самых важных данных. Поскольку вероятность взлома есть всегда, основной ключ лучше использовать для подписи в крайних случаях. Также можно создать ещё несколько подключей, которым по усмотрению пользователя могут быть заданы другие алгоритмы шифрования, если не требуется повышенного уровня секретности данных. Такие подключи будут зависеть от основного и могут использоваться для шифрования документов или переписки. Другими словами, для каждого способа связи - свой ключ. У каждого из них есть срок использования (так же, как и у кредитных карт). Хорошим тоном является установка срока использования для подключей 1-2 года. GnuPG ведёт собственную базу, которая находится в файле ~/.gnupg/pubring.gpg. Туда и заносятся открытые (публичные) ключи ваших респондентов.
С помощью команды:
$ gpg --list-keys
можно просмотреть все ключи, находящиеся в базе. Будет выведен список ключей, показывающий их статус (pub - публичный, sub - второстепенный), длину и метод шифрования, дату создания и, главное, уникальный идентификатор (ID), представляющий собой 8-значное 16-ричное число.
Для основного ключа можно (и нужно) создать отзывающий сертификат:
$ gpg --gen-revoke $KEY
где $KEY - ID основного ключа.
Отзывающий сертификат нужен для уничтожения ключа. Это может потребоваться, например, если ключ будет украден или утерян. Даже если ключевая фраза очень надёжна, стоит заранее, еще на этапе создания ключа, подумать о возможности его уничтожения в будущем. После создания сертификата его содержимое будет выведено в stdout. Его нужно сохранить в надёжном месте (желательно на другом носителе или вообще в печатном виде), т.к. любой, завладевший этим сертификатом, может сделать ключ недействительным и удалить его из базы данных сервера открытых ключей (тогда никто не сможет получить ваш ключ). Такие базы данных хранят публичные ключи совершенно свободно. Это сделано для удобства обмена ключами: вам необязательно постоянно передавать ваш публичный ключ лично. Можно воспользоваться несколькими способами: разместить у себя на домашней странице, на портале, в котором есть поле для публичного ключа, либо воспользоваться более централизованной базой - копилкой ключей, из которой достать ваш ключ будет всегда удобно.
Чтобы использовать сертификат, нужно просто импортировать его в базу, как и любой открытый ключ:
$ gpg --import revoke-certificate.asc
а затем отправить на сервер:
$ gpg --send-keys $KEY
где $KEY - ID ключа, который будет отправлен.
Точно так же можно отправлять публичные ключи и хранить их на серверах баз данных. Для этого в первую очередь их нужно экспортировать в общую локальную базу командой:
$ gpg --import $FILE
где $FILE - файл ключа или keyring («связка», несколько ключей в одном файле).
После этого командой --sign-key $KEY (где $KEY - ID ключа респондента) нужно подписать желаемый ключ. При подписывании к нему добавляется ваш публичный ключ для того, чтобы ваши сообщения/письма могли идентифицировать другие. Затем нужно отправить подписанный вами ключ его владельцу:
$ gpg --export $KEY > userkey.gpg
Эта команда извлекает подписанный ключ отдельно для удобства отправки.
Можно сделать то же самое в виде ASCII-текста, который легко разместить в Сети:
$ gpg -a --export $KEY > userkey.asc
где $KEY - ID ключа владельца.
Теперь владелец должен импортировать этот ключ к себе, чтобы ваша подпись находилась у него в базе. Экспорт такого ключа производится точно так же, как и любого другого публичного ключа. Затем владелец отправляет его на сервер баз данных ключей или выкладывает на свой сайт. Теперь его ключ содержит вашу подпись. И идентификация сообщений позволит удостовериться, что они дошли именно от вас.
Иногда может потребоваться хранить ваши ключи (публичные или приватные) на каком-либо носителе (например, на USB flash). Для этого нужно экспортировать ключ, что можно сделать как в бинарном виде:
$ gpg --export $KEY > mykey.gpg
Так и в текстовом (ASCII armor):
$ gpg -a --export $KEY > mykey.asc
В обоих случаях $KEY - это ID вашего ключа. Вместо -a можно также использовать --armor.
В итоге, для работы с документами доступны следующие команды:
- подписать документ (гарантирует, что документ «от вас»), к нему просто добавляется ваша электронная подпись;
- зашифровать документ (производится шифровка выбранным алгоритмом всего документа);
- подписать и зашифровать документ (сочетает в себе эти действия).
Вне зависимости от типа файла (как было показано выше с ключом) можно получить подпись или зашифрованное сообщение как в бинарном, так и в текстовом виде. Например, есть файл библиотеки - он двоичный. Шифруем и подписываем его, а на выходе получаем текстовый файл. После расшифровки файл приходит в своё оригинальное состояние. Это можно использовать для хранения различных файлов в таблицах реляционных баз данных: в таком случае, несмотря на различные типы файлов, после зашифровки все они будут представлять набор символов в виде строк ASCII.
Можно создавать так называемые «прозрачные» подписи (в которых будет незашифрованное содержимое документа + ваша цифровая подпись):
$ gpg --clearsign $DOC
где $DOC - путь к документу. Таким образом, будет создан файл $DOC.asc, в котором само содержание документа открыто и добавлена его цифровая подпись.
А подписи, находящиеся в отдельных файлах в бинарном виде (будет создан файл подписи $DOC.sig), создаются командами:
$ gpg --detach-sign $DOC
В текстовом (ASCII armor) виде (будет создан файл подписи $DOC.asc):
$ gpg -a --detach-sign $DOC
Такие подписи (в последних двух примерах) должны распространяться вместе с подписываемым документом.
Любой ключ также можно отредактировать командой `--edit-key’. Это позволит изменить некоторые параметры ключа: степень достоверности, если это чужой публичный ключ, секретную фразу, если это ваш приватный ключ, и другое.
Что касается степени достоверности, то в GnuPG существует 5 уровней:
- I don’t know or won’t say (я ничего не знаю о владельце этого ключа или не хочу говорить об этом);
- I do NOT trust (я не доверяю этому человеку);
- I trust marginally (я знаю этого человека и доверяю ему, но не уверен, что ключ принадлежит ему);
- I trust fully (я знаю этого человека и лично убедился в том, что ключ принадлежит ему);
- I trust ultimately (я знаю этого человека, у меня есть доступ к его секретному ключу).
GnuPG и Open Source
GnuPG существует практически в каждом дистрибутиве GNU/Linux, является обязательным пакетом в OpenBSD, NetBSD, FreeBSD и других свободных операционных системах. Множество Open Source-приложений поддерживают GnuPG посредством различных модулей. Например, gpgme (библиотека, являющаяся неким посредником между GnuPG и программами) используется следующими приложениями:
- Почтовые клиенты Evolution (входит в состав GNOME) и Sylpheed
.
Бинарные дистрибутивы Linux также зачастую используют пакеты, подписанные GnuPG. Например, в случае с пакетами DEB - это Debian GNU/Linux и Ubuntu, а с RPM - Red Hat, Fedora, Mandriva и многие-многие другие.
Итоги
В этой статье мы познакомились с GnuPG - свободным средством защиты информации. Теперь можно не беспокоиться о том, что ваши секретные данные будут утрачены или обнародованы. Этот принципиально новый подход (со времен создания OpenPGP) к шифрованию с точки зрения обычного пользователя позволяет и по сей день решать сложные задачи, связанные с передачей особо важных данных.
Данная статья представляет собой краткое руководство по использованию GnuPG (он же GPG). В ней вы найдете основные команды, примеры использования, а также инструкции по прикручиванию GPG к почтовым клиентам. Далее предполагается, что вы знакомы с принципом работы GPG и объяснять, например, что такое ассиметричная криптография, открытый и закрытый ключ, цифровая подпись и так далее, не требуется. За несколько десятилетий существования GPG никто особо не преуспел в его взломе, что как бы намекает нам, что это довольно надежное решение как для обмена зашифрованными сообщениями, так и просто шифрования файлов.
Терминология
Существует некоторая путаница в терминологии. Например, далеко не все могут внятно объяснить, чем PGP отличается от GPG. Давайте же во всем разберемся.
- OpenPGP — стандарт шифрования, описанный в RFC 4880 и RFC 6637 . Не следует путать с конкретными реализациями, такими, как PGP и GPG;
- GnuPG или GPG — конкретная открытая (GPLv3) реализация OpenPGP, речь о которой пойдет в настоящей статье;
- PGP — сильно проприетарная реализация OpenPGP от компании PGP Corporation. В 2010-м году компанию купила Symantec , а ее продукты переименовала во что-то типа Symantec Desktop Email Encryption;
Часто, говоря «PGP», люди имеют в виду способ шифрования, описанный в OpenPGP, и соответственно любую из его реализаций.
Основные команды GnuPG
Генерируем ключи:
gpg --gen-key
Хорошей идеей будет выбрать алгоритм RSA и длину ключей 4096 бит.
Важно! Не забудьте пароль от закрытого ключа.
Частая проблема — сообщение вроде такого:
Not enough random bytes available. Please do some other work to give
the OS a chance to collect more entropy! (Need 204 more bytes)
Решается она установкой демона для сбора энтропии:
sudo apt-get install rng-tools
Просмотр списка ключей:
gpg --list-keys
gpg --list-secret-keys
gpg --list-public-keys
Получение fingerprint ключа:
gpg --fingerprint afiskon@ example.ru
Пример вывода:
pub 4096R/8640D6B9 2016-09-27
Fingerprint = DB5E AA39 0745 427D ED31 D189 3197 3F00 8640 D6B9
uid Aleksander Alekseev
sub 4096R/5982B4BF 2016-09-27
Fingerprints используются в основном для проверки того, что с сервера ключей (см далее) был импортирован действительно правильный ключ. Для поиска их не используют.
gpg --armor --output privkey.txt --export-secret-keys 8640D6B9
Импорт открытого ключа:
gpg --import key.txt
Импорт закрытого ключа:
gpg --allow-secret-key-import --import privkey.txt
Если не указать --allow-secret-key-import , импортируется только открытый ключ, и при попытке подписать что-то вы будете получать странные ошибки вроде:
gpg: no default secret key: secret key not available
gpg: msg.txt: sign+encrypt failed: secret key not available
Экспорт открытого ключа на keyserver:
gpg --keyserver pgp.mit.edu --send-keys 8640D6B9
Важно! После того, как вы залили ключ на keyserver, его будет невозможно удалить, только сделать revoke. Убедитесь, что вы сделали надежную резервную копию ключа. Если вы раньше никогда не работали с PGP/GPG, очень советую сначала потренироваться на почтовых адресах в зоне example.ru.
Не имеет большого значения, какой keyserver указать. Например, еще есть keys.gnupg.net, а также другие. Все они время от времени обмениваются друг с другом данными . Не лишено смысла сделать send-keys сразу на несколько серверов, чтобы их быстрее увидели все пользователи PGP/GPG. Синхронизация серверов, по моим наблюдениям, занимает минут 10-15.
Hint: чтобы постоянно не указывать --keyserver , просто допишите в ~/.bashrc:
alias gpg ="gpg --keyserver pgp.mit.edu"
Импорт открытого ключа с keyserver:
gpg --keyserver pgp.mit.edu --search-keys afiskon@ example.ru
В мире PGP/GPG существуют так называемая сеть доверия (web of trust) . В двух словах это означает, что GPG не доверяет ключу, если только он не подписан кем-то, кому вы доверяете. Кроме того, если вы доверяете Пете, а Петя доверяет Коле, то вы автоматически доверяете Коле. В частности, по умолчанию при проверке подписи и прочих действиях GPG будет ругаться так:
Чтобы исправить это, говорим:
gpg --edit-key afiskon@ example.ru
Затем в диалоге говорим trust , жмем 5 («I trust ultimately»), говорим quit . Другие ключи можно подписать командой tsign . Кстати, там же можно сменить пароль от вашего ключа (команда passwd ), изменить дату экспирации ключа в любую сторону (команда expire ), добавить имя/email (команда adduid ), удалить имя/email (команда revuid ), посмотреть алгоритмы шифрования, используемые по умолчанию (showpref ) и делать другие интересные вещи.
Примечание: Что делать, когда ключ заэкспайрился? В этом случае можно изменить дату экспирации на более позднюю и перезалить ключ. Или же создать новый ключ, подписать его старым, и залить новый ключ на keyserver. Делать revoke не требуется.
Вы можете подписать чей угодно ключ и залить подписанный ключ на сервер, подтвердив тем самым, что ключ действительно принадлежит человеку, указанному в описании:
gpg --sign-key
7EFE74E5
На какой-нибудь другой машине можно скачать ключ заново и посмотреть, кем он подписан:
gpg --keyserver
pgp.mit.edu --search-keys
eax@
example.ru
gpg --list-sigs
eax@
example.ru
gpg --check-sigs
eax@
example.ru
Время от времени стоит обновлять ключи, на случай, если у ключей появились новые подписи, или какие-то ключи отозвали:
gpg --keyserver pgp.mit.edu --refresh-keys
Пример шифрования и подписи файла для заданного получателя (ключ -r можно указывать много раз):
gpg --encrypt --sign --armor -r eax@ example.ru msg.txt
Расшифровка файла и проверка подписи осуществляется командой:
Пример подписи и проверки подписи бинарного файла (например, ISO образа диска):
gpg --detach-sign
file.iso
gpg --verify
file.iso.sig
Симметричное шифрование/дешифрование файла (удобно, например, для хранения паролей):
gpg -o
nonsense.gpg --cipher-algo
AES -a
-c
nonsense.txt
gpg -o
nonsense2.txt -d
nonsense.gpg
Симметричное шифрование с сохранением в бинарном формате (удобно для шифрования бэкапов):
tar
-cvzf
- /
home/
eax |
\
gpg --symmetric
--cipher-algo
AES256 --digest-algo
SHA256 \
--compression-algo
Uncompressed >
backup.tgz.gpg
Расшифровка зашифрованного таким образом файла:
gpg --decrypt backup.tgz.gpg | tar -xvzf -
При этом по умолчанию GPG запрашивает пароль через GUI интерфейс, что я лично нахожу не очень-то удобным. Изменить данное поведение можно так:
echo
"pinentry-program /usr/bin/pinentry-tty"
>>
\
~/
.gnupg/
gpg-agent.conf
killall
gpg-agent
Может оказаться, что ваш закрытый ключ скомпрометирован, то есть, его украли и подобрали к нему пароль. Или же вы потеряли его. Или просто не можете вспомнить пароль от ключа. Для таких случаев предусмотрен отзыв ключа. Делается это так. Заранее, сразу после создания ключей, требуется создать сертификат отзыва:
gpg --gen-revoke --armor --output =revocation.crt eax@ example.ru
Используя его, ключ можно отозвать так:
gpg --import
revocation.crt
gpg --keyserver
pgp.mit.edu --send-keys
7EFE74E5
Важно! Сертификат отзыва не шифруется и может быть использован кем угодно. Убедитесь, что храните его в надежном месте (лучше даже в нескольких таких местах) и непременно в зашифрованном виде!
Прикручиваем GnuPG к Claws Mail
В Ubuntu нам понадобятся следующие пакеты:
sudo apt-get install claws-mail-pgpinline claws-mail-pgpmime
В Configuration → Plugins → Load загружаем pgpcore.so, pgpinline.so и pgpmime.so. Далее просто настраиваем плагины через настойки клиента. В настройках аккаунта можно указать, какие ключи использовать, а также сгенерировать новые ключи и отправить их на keyserver. При написании письма в Options станут доступны галочки Encrypt и Sign.
В свойствах аккаунта во вкладке Privacy можно настроить плагины так, чтобы сообщения всегда подписывались, шифровались при ответе на зашифрованные сообщения, и так далее. Использовать советую PGP/MIME, так как PGP/Inline может не слабо раздражать пользователей, не использующих PGP/GPG. То есть, почти всех.
Из косяков плагина я столкнулся только с тем, что в настройках нужно указать полный путь к исполняемому файлу gpg, после этого все заработало.
Прикручиваем GnuPG к Mutt
Заключение
GPG прикручивается еще очень много к чему. Скажем, для Thunderbird есть плагин Enigmail . Существуют мобильные приложения с поддержкой GPG. Например, для iPhone есть oPenGP и iPGMail . Кроме того, существуют плагины и для IM-клиентов, в частности, для Psi. К сожалению, рассмотреть их все в рамках одной статьи не представляется возможным.
В качестве домашнего задания можете добавить меня в свой keyring, подписать мои ключи и отправить мне на email зашифрованное письмо.
А используете ли вы PGP/GPG?
