Показаны сообщения с ярлыком Ubuntu. Показать все сообщения
Показаны сообщения с ярлыком Ubuntu. Показать все сообщения

суббота, 7 апреля 2018 г.

Разрешение экрана в Ubuntu

CRT-мониторАвтоматическая настройка разрешения экрана не всегда работает так, как ожидается. При установке дистрибутива X-сервер выбирает самое большое значение разрешения экрана и частоты развёртки из возможных. Это верно для ЖК-мониторов, но не всегда верно для ЭЛТ, так как на 17" мониторе максимальной величиной является 1600x1200, а удобной для просмотра — 1024x768. Если для сеанса Gnome можно выбрать конкретное разрешение, то для экрана входа в систему и загрузки системы графических утилит сразу не предоставлено. Эта проблема легко решается. 
Начнём с экрана загрузки системы. Нам нужно отредактировать один файл. Открываем его через суперпользователя, вводя в терминале:

sudo gedit /etc/usplash.conf

В нём находится что-то подобное:

# Usplash configuration file
xres=1600
yres=1200

Изменяем значения на нужные и сохраняем файл. Всё! При следующей загрузке разрешение уже будет нужным.
Теперь переходим к разрешению окна входа. Как мы говорили выше, оно максимальное из возможных. Значит нужно сделать максимально возможным используемое вами разрешение.
Открываем ещё один файл, предварительно сделав его копию:

sudo cp /etc/X11/xorg.conf /etc/X11/xorg.conf.bak; sudo gedit /etc/X11/xorg.conf

Находим в нём подобные строчки:
SubSection "Display"
Modes "1280x1024" "1024x768" "800x600" "640x480"
EndSubSection


Удаляем ненужные разрешения во всех подобных строчках, чтобы остались только используемые. Сохраняем. Теперь можно перезапустить X-сервер, нажатием Ctrl+Alt+Bkspace.
Так же в системе присутствует псевдографическая утилита для более тонкой настройки X-сервера и более опытных пользователей. Её можно вызвать командой:

sudo dpkg-reconfigure -plow xserver-xorg

Будьте осторожны при её использовании, иначе, при неправильном конфигурировании Вы рискуете ничего не увидеть =)
Подведя итог, можно сказать, что в операционной системе Убунту всё направлено, в первую очередь, на автоматическую настройку. Это хорошо, так как экономит время и силы. С другой стороны, Linux-основа дистрибутива даёт возможность более точной ручной настройки.

воскресенье, 12 ноября 2017 г.

Установка Ubuntu Linux на SSD

Многие слышали, что на рынке появились твердотельные жёсткие диски без движущихся частей, SSD диски. Они пока относительно дорогие и объем не велик, но операционная система на них просто летает, а тяжёлые приложения стартуют в разы быстрее, чем с обычных HDD. Чем достигается такое волшебство?
У SSD нет головок, которые необходимо позиционировать над затребованными данными и поэтому скорость чтения случайных секторов происходит намного быстрее. А как показывает практика, именно работа с мелкими файлами, расположенных в разных местах диска - это обычный портрет работы операционной системы.
Лучшее решение на сегодняшний день - это покупка SSD для операционной системы и хранение личных и медиа файлов на обычных HDD.
Вот и я решился купить себе SSD диск для Ubuntu. Много прочёл про этот новый вид дисков - твердотельные накопители. Хотел модель Intel X25-V, но денег как всегда мало, пришлось приобрести модель OCZ "Onyx" OCZSSD2-1ONX32G с контроллером Indilinx Amigos, про который много отрицательного не пишут.
Ниже описаны этапы, которые помогут правильно подготовить SSD для работы с Ubuntu Linux. Если вы проигнорируете этапы, то получите работающую систему, но не оптимальную, с меньшей скоростью чтения-записи и, возможно, подвергните свой SSD диск опасности раннего выхода из строя.

Прочтите все о вашем SSD на официальном сайте

Не пренебрегайте данным советом, например я вычитал на официальном сайте моего OCZ "Onyx" OCZSSD2-1ONX32G, что обновлять прошивку нужно, установив в BIOS, режим IDE для SATA дисков, а не родной AHCI режим. Мало ли чего важного вы вычитаете?

Обновите прошивку

Внутри жёстких дисков, SSD не исключение, есть микроконтроллер, который управляется микропрограммой. Её можно обновлять и это называется "прошивкой" (firmware). Прочтите что и как рекомендует производитель вашего SSD диска для обновления прошивки. Обычно обновление прошивки устраняет ошибки и добавляет новые функции. Очень важно чтобы SSD диск поддерживал TRIM и, если для этого нужно обновить прошивку, обновляйте!
Узнать текущую версию прошивки можно командой sudo hdparm -i /dev/ваш_диск | grep -i Fw

Выравнивание разделов на SSD

Суть проблемы в том, что если начало разделов в секторах не кратно размеру кластера файловой системы, то резко падает производительность при чтении/записи с диска, а в случае с SSD диском ещё и увеличивается износ диска. То есть когда разделы не выравнены, то кластер файловой системы занимает несколько секторов и тем самым увеличивается количество операций чтения/записи. Подробнее об этой проблеме выравнивания разделов лучше прочесть в Интернете. Главное запомнить простое правило: создаёте раздел - его стартовый сектор должен делиться на 8 без остатка.

Устр-во Загр Начало Конец Блоки Id Система
/dev/sdh1 2048 514047 256000 83 Linux
/dev/sdh2 514048 55810047 27648000 83 Linux
Начальные сектора 2048 и 514048 кратны 8! Я использовал fdisk и в нём создал разделы /boot, / и swap. Из статьи на Хабре выяснил, что работа со swap в современных операционных системах идёт примерно ~40:1 чтение:запись. Поэтому размещение swap на SSD это отличная идея. Чуть позже мы заставим Ubuntu Linux меньше использовать swap, а больше быструю ОЗУ.
Некоторое место на вашем SSD зарезервировано и недоступно вам, это место будет использовано для замены износившихся во время записи-перезаписи ячеек. Во время разметки диска, я оставил не размеченой область ~3,5 Гб, чтобы контроллеру диска было чем заменять, в далёком будущем, вышедшие из строя ячейки. Вам так же рекомендую не жадничать и при разметке оставить чуток не размеченной области.

Установка на SSD Ubuntu

Во время установки я указал, что первый раздел на SSD это /boot и файловая система ext3. Просто я решил помочь grub'у и не огребать не нужных проблем. В /boot хранятся ядра системы и размера 250 мб должно хватить на много установленных параллельно ядер.
Второй раздел на SSD стал корнем / в BTRFS. У этой продвинутой файловой системы, есть замечательный параметр -o ssd. Указав его, мы сообщаем, что жёсткий диск вида SSD и улучшаем работу с ним. Указать параметр можно позже, отредактировав /etc/fstab

# мой корень
UUID=6f1fedb8-2dc7-4d19-a1f4-2eac082f879e / btrfs defaults,noatime,barrier=0,nodatacow,discard,commit=600,ssd 0 0

Раздел /home был и его не форматируя через установщик, я задействовал как и раньше. Все файловые системы, кроме /boot, указаны в BTRFS.

Оптимизация Ubuntu для SSD

Если у вас есть UPS, он же ИБП, то можно применить советы из Ускорение Ubuntu.
Параметр discard.
Включает полезную команду TRIM и настоятельно рекомендуется к применению к различным файловым системам. discard нужно указать в /etc/fstab. Разработчики многих дистрибутивов linux обсуждали иногда возникающую проблему с discard, которая приводит к падению производительности. Альтернативным путём является вызов fstrim из cron. Пробуйте и выбирайте своё!
Параметр ssd для btrfs.
Указывайте для файловых систем btrfs в /etc/fstab.
Параметр commit=600.
Замечательный параметр commit равный 600 можно применять ко многим файловым системам и commit указывает на сброс грязных файловых буферов каждые 10 минут (600). Настоятельно рекомендуется иметь ИБП. commit=600 нужно указать в /etc/fstab.
barrier=0
Код файловой системы обязан перед созданием записи фиксации [журнала] быть абсолютно уверенным, что вся информация о транзакции помещена в журнал. Просто делать запись в правильном порядке недостаточно; современные диски имеют кэш большого объёма и меняют порядок записи для оптимизации производительности. Поэтому файловая система обязана явно сообщить диску о необходимости записать все журнальные данные на носитель перед созданием записи фиксации; если сначала будет создана запись фиксации, журнал может быть повреждён. Блокирующая система ввода-вывода ядра предоставляет такую возможность благодаря использованию механизма «шлагбаумов» (barriers); проще говоря, «шлагбаум» запрещает запись любых блоков, посланных после него, до того момента, как всё, что было прислано перед «шлагбаумом», будет перенесено на носитель. При использовании «шлагбаумов» файловая система может гарантировать, что всё, что находится на диске, целостно в любой момент времени. Отключая шлагбаум barrier=0, мы ускоряем операции записи на разделы.
barrier=0 нужно указать в /etc/fstab.
Для btrfs указывайте nobarrier.
LVM.
Если вы используете технологию LVM, то нужно указать в /etc/lvm/lvm.conf параметр issue_discards = 1.
Preload.
Демон, кешируюший обращения к файлам и ускоряющий IO вывод. В SSD диске нет вращающихся блинов и считывающих головок, то желательно в /etc/preload.conf изменить параметр и привести его к виду sortstrategy = 0. Этим самым вы прикажете не производить сортировку очереди запросов, так как для SSD это не имеет смысла. Перезапустите preload - sudo /etc/init.d/preload restart
Увеличим сброс грязных буферов vm.dirty_writeback_centisecs = 15000 в /etc/sysctl.conf.
У демонов журналирования rsyslogd или syslogd перед всеми путями к журналам поставим знак минус и заставим не делать sync после добавления одной строки в журнал. Демон ведения журналов syslog (а также идущий ему на смену - rsyslog) пишет журналы в каталоге /var/log/ и добавив одну строку делает операцию sync, которая сводит на нет кэш диска и более долгий сброс буферов. Можно изменить поведение демона и указать не делать sync после каждого добавления. Найдите файл конфигураций демона, обычно это /etc/syslog.conf или /etc/rsyslog.d/ и все пути вида /var/log/что-то-там/ измените, дописав знак минус ("-") перед путями.
В файл /etc/sysctl.conf в конец файла вставьте строку vm.swappiness = 10 и тем самым заставьте Ubuntu Linux больше занимать ОЗУ, чем swap. Как это достигается подробно расписано в Ускорении Ubuntu.
По умолчанию в Ubuntu Linux в качестве файлового планировщика используется CFQ, он старается минимизировать перемещения головок, но у SSD нет движущихся частей и CFQ не нужен. Нужно в файле /etc/default/grub добавить elevator=noop и получить строку, типа GRUB_CMDLINE_LINUX_DEFAULT="quiet splash elevator=noop". Не забудьте sudo update-grub
Теперь перезагрузка вашего ПК и получите оптимизированную под плюсы и скрывающая минусы SSD систему Ubuntu Linux. Порадуйте себя скоростью SSD sudo hdparm -t /dev/ваш_диск_ssd

Советы SSD

1) Меньше пишешь на SSD, лучше.
2) Постоянная запись множества мелких файлов - самое большое зло для SSD. Запись на SSD производится блоками (вплоть до 128 Кб) и маленькие файлы вынуждают стирать блоки большего размера.
3) Располагать раздел подкачки на SSD можно и нужно. Работа с подкачкой характеризуются большим количеством чтения по сравнению с записью (40 к 1), и относительно большими объемами записи, так что пользы от гораздо более быстрого доступа к данным больше, чем вреда.
4) Если команда iotop часто показывает запись процесса в раздел, находящийся на SSD, сделай так, чтобы процесс туда писал реже или вообще не писал. Не бойся редкой записи - бойся постоянной, периодической записи. Смотри п.п 1.
5) Забудь про дефрагментацию, её больше для тебя не существует. Если увидел слово онлайн дефрагментация или дефрагментация на-лету, найди и выключи это.
6) В Ubuntu Linux кроме системного индексатора updatedb, остальные индексаторы хранят файлы-базы-данных в домашнем каталоге. Подумайте о необходимости этих индексаторов-поисковиков, если не нужны - отключайте/удаляйте.
Отличный видеоматериал, правда на английском языке, но всё понятно из самого видео и открытых окон как оптимизировать Linux для SSD.

суббота, 24 июня 2017 г.

Как установить бесплатный SSL-сертификат для своего сайта

Let’s Encrypt — это центр сертификации (англ. certification authority, CA), предоставляющий лёгкий способ получения и установки TLS/SSL-сертификатов, обеспечивающих возможность использования протокола HTTPS на веб-сервере. Работа с Let’s Encrypt упрощена наличием клиента Certbot, который автоматизирует большую часть работы. Тем не менее, бесплатный SSL-сертификат можно установить на веб-сервер вручную, независимо от его конфигурации.
Полный перечень программного обеспечения, в котором работа с сертификатами уже автоматизирована, вы можете найти на официальном сайте Certbot. Стоит отметить, что полная или частичная автоматизация возможна с помощью не только Certbot, но и другого программного обеспечения. Списки поддерживаемых операционных систем и браузеров, а также клиентов и библиотек постоянно обновляются.
В этом руководстве мы расскажем, как при помощи Certbot получить бесплатный SSL-сертификат и использовать его в Nginx на Ubuntu 16.04. Мы также покажем, как настроить автоматическое обновление SSL-сертификата во избежание истечения его срока действия. Если у вас запущен другой веб-сервер, следуйте его документации, чтобы узнать, как использовать сертификат для вашей конфигурации.
Let's Encrypt

Шаг 0. Подготовка

Перед тем, как приступить к работе, вам нужно убедиться в нескольких вещах.
У вас должен быть установлен сервер на Ubuntu 16.04, и создан пользователь (не root), для которого настроены sudo привилегии. Узнать, как это сделать, вы можете, следуя руководству по первичной настройке сервера на Ubuntu 16.04.
Вы должны быть владельцем доменного имени, для которого планируется использовать сертификат, или иметь доступ к его настройке. Если у вас нет зарегистрированного доменного имени, вы можете сделать это, используя один из регистраторов (например, Namecheap или GoDaddy).
После регистрации домена убедитесь, что создана запись A, которая связывает ваш домен и публичный IP-адрес вашего сервера. Это необходимо, потому что Let’s Encrypt проверяет, что вы являетесь владельцем домена, на который выдаётся сертификат. Например, если вы хотите получить сертификат для example.com, такое доменное имя должно указывать на ваш сервер, чтобы проверка прошла. Мы будем использовать доменные имена example.com и www.example.com, поэтому необходимы DNS-записи для обоих доменов.
Если все требования выполнены, приступаем к установке Certbot — клиента Let’s Encrypt.

Шаг 1. Устанавливаем Certbot

Первым шагом на пути к получению SSL-сертификата является установка клиента Certbot на ваш сервер. Разработчики Certbot поддерживают собственный репозиторий с актуальной версией программного обеспечения. Поскольку Certbot находится в стадии активной разработки, для установки свежей версии стоит использовать именно этот репозиторий.
Для начала добавьте репозиторий:
sudo add-apt-repository ppa:certbot/certbot
Нажмите ENTER для подтверждения. После этого необходимо обновить пакеты:
sudo apt-get update
По завершении установите Certbot, используя команду apt-get:
sudo apt-get install certbot
Теперь Certbot готов к использованию.

Шаг 2. Получаем SSL-сертификат

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

Использование плагина Webroot

Алгоритм работы Webroot включает в себя создание специального файла в директории /.well-known. Она размещается в корневом каталоге веб-сервера (document root) и может быть открыта сервисом Let’s Encrypt для проверки. В зависимости от ваших настроек, вам может понадобиться явно разрешить доступ к папке /.well-known.
Если вы ещё не установили Nginx, сделайте это, следуя руководству по установке Nginx на Ubuntu 16.04.
Чтобы убедиться в том, что папка доступна сервису Let’s Encrypt, внесем небольшие изменения в конфигурацию Nginx. По умолчанию файл конфигурации находится в папке /etc/nginx/sites-available/default. Мы будем использовать редактор Nano для внесения изменений:
sudo nano /etc/nginx/sites-available/default
Внутри блока server добавьте такой блок location:
# Добавить в SSL-блок server

location ~ /.well-known {
    allow all;
}
Вам также стоит посмотреть, где расположен корневой каталог веб-сервера (document root), так как этот путь необходим при работе с Webroot. Если вы используете стандартный файл конфигурации, она будет расположена в /var/www/html.
Сохраните и закройте файл.
Проверьте вашу конфигурацию на синтаксические ошибки:
sudo nginx -t
Если ошибок нет, перезапустите Nginx, используя эту команду:
sudo systemctl restart nginx
Теперь, когда мы знаем webroot-path, можно выполнить запрос на получение SSL-сертификата. При помощи ключа -d указываются доменные имена. Если вы хотите использовать единый сертификат для нескольких доменных имен (например, example.com и www.example.com), не забудьте добавить их все. Также убедитесь, что вы заменили значения webroot-path и доменные имена на соответствующие вашим:
sudo certbot certonly –webroot –webroot-path=/var/www/html -d example.com -d www.example.com
Если это первый запуск Certbot, вам будет предложено ввести адрес электронной почты и подтвердить согласие с правилами использования сервиса. После этого вы увидите сообщение об успешном завершении и путь, куда были сохранены ваши сертификаты:
# Пример сообщения

IMPORTANT NOTES:

— Congratulations! Your certificate and chain have been saved at
  /etc/letsencrypt/live/example.com/fullchain.pem. Your cert will expire
  on 2017-07-26. To obtain a new or tweaked version of this certificate
  in the future, simply run certbot again. To non-interactively renew *all*
  of your certificates, run "certbot renew"

— If you lose your account credentials, you can recover through e-mails
  sent to sammy@example.com.

— Your account credentials have been saved in your Certbot configuration
  directory at /etc/letsencrypt. You should make a secure backup of
  this folder now. This configuration directory will also contain
  certificates and private keys obtained by Certbot so making regular
  backups of this folder is ideal.

— If you like Certbot, please consider supporting our work by:
  Donating to ISRG / Let’s Encrypt: https://letsencrypt.org/donate
  Donating to EFF: https://eff.org/donate-le
Обратите внимание, что путь к сертификату и дата истечения срока его использования указаны в начале сообщения.
Примечание 1. Если в процессе вы получите ошибку вроде Failed to connect to host for DVSNI challenge, значит, вам нужно настроить файрвол вашего сервера, разрешив TCP-трафик на портах 80и 443.
Примечание 2. Если для вашего домена используется маршрутизация через такой DNS-сервис, как CloudFlare, вам придется временно отключить её до тех пор, пока сертификат не будет получен.

Файлы сертификата

После получения сертификата у вас должны появиться следующие файлы в PEM-кодировке:
  • cert.pem — сертификат вашего доменного имени;
  • chain.pem — цепочка сертификатов Let’s Encrypt;
  • fullchain.pem — объединённые cert.pem и chain.pem;
  • privkey.pem — приватный (секретный) ключ вашего сертификата.
Важно запомнить расположение этих файлов, так как они будут использоваться в конфигурации вашего сервера. Сами файлы расположены в папке /etc/letsencrypt/archive. Однако Certbot создает симлинкина наиболее актуальные файлы сертификата в папке /etc/letsencrypt/live/ваше_доменное_имя/. Так как символьные ссылки указывают на наиболее актуальные файлы сертификата, именно этот путь лучше использовать при обращении к ним.
Вы можете проверить существование файлов, используя такую команду (подставьте ваше доменное имя):
sudo ls -l /etc/letsencrypt/live/ваше_доменное_имя/
Результатом выполнения команды должны быть указанные выше файлы сертификата. Теперь вы можете настроить ваш сервер так, чтобы fullchain.pem использовался в качестве файла сертификата, а privkey.pem в качестве ключа сертификата.

Генерация ключа по алгоритму Диффи-Хеллмана

Для повышения безопасности вам необходимо сгенерировать ключ по алгоритму Диффи-Хеллмана. Для генерации ключа длиной 2048 бит используйте такую команду:
sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048
Процесс может занять несколько минут.

Шаг 3. Настраиваем TLS/SSL на веб-сервере

Теперь, когда у вас есть SSL-сертификат, необходимо настроить веб-сервер Nginx так, чтобы он начал его использовать.
Внесем некоторые изменения в нашу конфигурацию:
  1. Создадим сниппет конфигурации, содержащий расположение нашего SSL-ключа и файлов сертификата.
  2. Создадим сниппет конфигурации, содержащий настройки устойчивого SSL, которые можно будет использовать в будущем для любого сертификата.
  3. Обновим блоки server в конфигурации Nginx, которые будут управлять SSL-запросами и использовать оба вышеуказанных сниппета.
Такой подход к настройке Nginx позволяет сохранить блоки server чистыми и сделать конфигурацию доступной для повторного использования.

Создаем сниппет конфигурации для SSL-ключа и сертификата

Сперва создадим сниппет конфигурации Nginx в папке /etc/nginx/snippets.
Для правильного распознавания назначения файла назовем его ssl-, затем укажем доменное имя и в конце поставим .conf:
sudo nano /etc/nginx/snippets/ssl-example.com.conf
В этом файле необходимо установить соответствие директивы ssl_certificate файлу сертификата и ssl_certificate_key — соответствующему ключу. В нашем случае это будет выглядеть так:
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
Когда добавите эти строки, сохраните и закройте файл.

Создаем сниппет конфигурации с устойчивыми настройками шифрования

Следующим шагом мы создадим другой сниппет, определяющий некоторые настройки SSL. Это позволит Nginx подключить устойчивый «набор шифров» SSL (англ. cipher suite) и некоторые дополнительные функции, которые помогут обеспечить безопасность нашего сервера.
Прим. перев. Cipher Suite — это совокупность алгоритмов, используемых в конкретной TLS/SSL-сессии:
  • алгоритм выработки сессионных ключей шифрования;
  • алгоритм, используемый для аутентификации сервера;
  • непосредственно сам симметричный алгоритм шифрования трафика;
  • и алгоритм контроля целостности (MAC, message authentication code).
Установленные нами параметры могут быть использованы повторно для конфигураций Nginx в будущем, поэтому дадим файлу стандартное название:
sudo nano /etc/nginx/snippets/ssl-params.conf
Для настройки безопасной связки Nginx-SSL мы будем использовать рекомендации сайта Cipherli.st. Он создан для предоставления быстрого доступа к готовым настройкам шифрования популярного программного обеспечения. Дополнительная информация доступна в руководстве по настройке SSL для Nginx.
Примечание. Предлагаемые стандартные настройки на сайте Cipherli.st обеспечивают устойчивую безопасность, но иногда это приводит к ухудшению совместимости. Если вам необходимо поддерживать более старые версии клиентов, используйте альтернативный список настроек, доступный при нажатии на значок «Yes, give me a ciphersuite that works with legacy/old software.» Составить такой список можно и вручную.
Для наших целей можно скопировать предлагаемые настройки целиком. Нам потребуется внести лишь некоторые изменения.
Сперва добавим DNS-резолвер. Используем для нашего руководства тот, что предлагает Google. Затем установим в качестве параметра ssl_dhparam указатель на файл ключа Диффи-Хеллмана, который мы сгенерировали ранее.
И, наконец, почитайте о протоколе HTTP Strict Transport Security, или HSTS. Он обеспечивает повышенную безопасность, но его некорректное использование может привести к серьезным последствиям. В этом руководстве мы отключим заголовочный файл по умолчанию, но вы можете не делать этого, если уверены, что понимаете последствия:
# Источники: https://cipherli.st/
# и https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
ssl_ecdh_curve secp384r1;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
# отключаем заголовочный файл HSTS
# add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;

ssl_dhparam /etc/ssl/certs/dhparam.pem;
После внесения изменений сохраните и закройте файл.

Настраиваем конфигурацию Nginx для SSL

Теперь, когда мы подготовили сниппеты, можно обновить нашу конфигурацию Nginx и подключить SSL.
В данном руководстве мы полагаем, что вы используете стандартный файл с блоками server, расположенный в папке /etc/nginx/sites-available. Если вы используете другой файл с блоками server, замените название в представленных ниже командах.
Перед тем, как двигаться дальше, давайте сделаем резервную копию нашего текущего файла с блоками server:
sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/default.bak
Теперь откройте файл с блоками server для внесения изменений:
sudo nano /etc/nginx/sites-available/default
Внутри ваш блок server, вероятно, начинается так:
server {
 listen 80 default_server;
 listen [::]:80 default_server;

# Конфигурация SSL

# listen 443 ssl default_server;
# listen [::]:443 ssl default_server;

. . .
Изменим текущую конфигурацию так, чтобы незашифрованные HTTP-запросы автоматически перенаправлялись на шифрованный HTTPS. Такой способ обеспечивает лучшую безопасность. Если вы хотите разрешить и HTTP-, и HTTPS-трафик, используйте альтернативную конфигурацию, представленную в следующем разделе.
Разделим конфигурацию на два отдельных блока. После первых двух директив listen добавим директиву server_name, указывающую на доменное имя вашего сервера. Затем установим перенаправление на созданный нами второй блок server. После этого закроем текущий блок:
server {
 listen 80 default_server;
 listen [::]:80 default_server;
 server_name example.com www.example.com;
 return 301 https://$server_name$request_uri;
}

# Конфигурация SSL

# listen 443 ssl default_server;
# listen [::]:443 ssl default_server;

. . .
Следующим шагом необходимо открыть новый блок server сразу за текущим, чтобы оставшаяся часть конфигурации попала в него. Мы можем раскомментировать обе директивы listen, использующие порт 443. К этим строкам можно добавить http2, чтобы включить HTTP/2 внутри блока. После этого нам останется подключить оба настроенных нами сниппета в файл:
Примечание. У вас может быть только одна директива listen, которая подключает модификатор default_server для каждой комбинации версии IP и порта. Если для выбранных портов у вас включены другие блоки server, для которых настроен default_server, вам придется удалить модификатор у одного из блоков.
server { 
 listen 80 default_server;
 listen [::]:80 default_server;
 server_name example.com www.example.com;
 return 301 https://$server_name$request_uri;
}

server {

# Конфигурация SSL

listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
include snippets/ssl-example.com.conf;
include snippets/ssl-params.conf;

. . .
После внесения изменений сохраните и закройте файл.

Альтернативная конфигурация: разрешаем HTTP- и HTTPS-трафик

Если вы хотите или вынуждены разрешить и шифрованный, и нешифрованный контент, вам придётся настроить Nginx немного иначе. Так делать не стоит, но в некоторых ситуациях это может быть необходимо. По сути, мы склеим разделенные блоки server в один и уберём перенаправление:
server {
 listen 80 default_server;
 listen [::]:80 default_server;
 listen 443 ssl http2 default_server;
 listen [::]:443 ssl http2 default_server;

 server_name example.com www.example.com;
 include snippets/ssl-example.com.conf;
 include snippets/ssl-params.conf;

. . .
После внесения изменений сохраните и закройте файл.

Шаг 4. Настраиваем файрвол

Если у вас включен файрвол ufw, вам необходимо обновить настройки и разрешить SSL-трафик. К счастью, Nginx регистрирует несколько профилей с ufw после установки.
Вы можете посмотреть текущие настройки, введя:
sudo ufw status
Вероятно, результат будет выглядеть следующим образом, означая, что на сервере разрешён только HTTP-трафик:
Status: active

To              Action            From
–              ——            —-
OpenSSH         ALLOW             Anywhere
Nginx HTTP      ALLOW             Anywhere
OpenSSH (v6)    ALLOW             Anywhere(v6)
Nginx HTTP(v6)  ALLOW             Anywhere (v6)
Чтобы разрешить HTTPS-трафик, можно включить профиль «Nginx Full» и удалить лишний профиль «Nginx HTTP»:
sudo ufw allow ’Nginx Full’
sudo ufw delete allow ’Nginx HTTP’
Теперь состояние файрвола должно выглядеть так:
sudo ufw status
Status: active

To              Action            From
–              ——            —-
OpenSSH         ALLOW             Anywhere
Nginx Full      ALLOW             Anywhere
OpenSSH (v6)    ALLOW             Anywhere (v6)
Nginx Full (v6) ALLOW             Anywhere (v6)

Шаг 5. Подключаем изменения в Nginx

Теперь, когда мы внесли изменения в конфигурацию и обновили правила файрвола, нужно перезапустить Nginx, чтобы изменения вступили в силу.
Первым делом стоит проверить и убедиться, что синтаксические ошибки в наших файлах отсутствуют. Это можно сделать, введя:
sudo nginx -t
В случае успеха ваш результат должен выглядеть следующим образом:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Если ваш результат совпадает с тем, что вы видите выше, значит, ваш файл конфигурации не содержит синтаксических ошибок. Для активации изменений безопасно перезапустим Nginx:
sudo systemctl restart nginx
Теперь TLS/SSL-сертификат от Let’s Encrypt на месте и файрвол разрешает трафик на портах 80 и 443. На этом этапе протестируйте работоспособность TLS/SSL-сертификата, зайдя на ваш домен в браузере по HTTPS.
Вы можете использовать инструмент Qualys SSL Labs Report, чтобы посмотреть оценку конфигурации вашего сервера:
# Наберите в браузере:
https://www.ssllabs.com/ssltest/analyze.html?d=example.com
Такая настройка SSL должна показать рейтинг A+.

Шаг 6. Настраиваем автоматическое обновление

Сертификаты от Let’s Encrypt действуют только в течение 90 дней. Это побуждает пользователей к автоматизации процесса обновления. Нам понадобится создать регулярно запускающуюся команду для проверки и автоматического обновления сертификатов, срок которых истекает.
Для запуска проверки ежедневных обновлений мы будем использовать Cron — стандартный системный сервис для запуска повторяющихся задач. Задачи Cron указываются в файле под названием crontab:
sudo crontab -e
Вставьте следующую строчку в конец файла, затем сохраните и закройте его:
. . . 
15 3 * * * /usr/bin/certbot renew –quiet –renew-hook "/bin/systemctl reload nginx"
Часть строчки 15 3 * * * означает «запускай следующую команду в 3:15 ночи ежедневно». Вы можете выбрать любое время.
Команда renew для Certbot проверит все сертификаты, установленные в системе, и обновит каждый, срок использования которого истекает менее, чем через 30 дней. Ключ –quiet говорит Certbot’у ничего не выводить и не ждать ввода от пользователя. –renew-hook "/bin/systemctl reload nginx" перезагрузит Nginx, чтобы он использовал новые файлы сертификата, но только в случае, если произошло обновление.
Cron будет запускать эту команду каждый день. Все установленные сертификаты будут автоматически обновлены и подгружены, когда останется меньше 30 дней до истечения срока их действия.

Заключение

В данном руководстве мы установили клиент сервиса Let’s Encrypt — Certbot, загрузили SSL-сертификаты для наших доменов, настроили Nginx, чтобы он использовал эти сертификаты, и настроили автоматическое обновление. Если у вас остались вопросы по использованию Certbot, его документация вам поможет.

вторник, 4 апреля 2017 г.

Настройка OpenVPN в Ubuntu

Настоящая частная виртуальная сеть или Virtual Private Network (VPN)  - это зашифрованное соединенный туннель между двумя сетями, который соединяет две доверенные точки. Это не веб-протокол HTTPS, который считает доверенными всех клиентов. К VPN могут подключиться только те клиенты, которые имеют специальные ключи доступа.
Понятие VPN в наши дни стало очень растянутым, после появления частных виртуальных сетей, которые доверяют всем и распространения HTTPS. Многие из сетей VPN представляют из себя коммерческие решения с минимальным количеством настроек для обеспечения удаленного доступа сотрудников. Но не все доверяют этим решениям. Частная виртуальная сеть соединяет две сети в одну, например, сеть офиса и домашнюю сеть работника. Сервер VPN необходим для того чтобы сервер и клиент могли пройти аутентификацию друг с другом.
Настройка аутентификации сервера и клиента требует много работы, и поэтому коммерческие решения с минимумом настроек проигрывают в этом плане. Но на самом деле не так уж трудно установить сервер OpenVPN. Вам понадобится два узла в разных сетях чтобы организовать тестовое окружение, например, можно использовать несколько виртуальных машин или реальные серверы. Как вы уже поняли, в этой статье будет рассмотрена настройка OpenVPN в Ubuntu для создания полноценной частной виртуальной сети.

Установка OpenVPN

На обоих машинах должен быть установлен OpenVPN, это довольно популярная программа, поэтому вы можете установить ее из официальных репозиториев. Также нам понадобится Easy-RSA для работы с секретными ключами. Для установки программ в Ubuntu используйте такую команду:
$ sudo apt install openvpn easy-rsa
Оба пакеты должны быть установлены как на сервере, так и на клиенте. Они понадобятся для настройки программы. Первый этап статьи установка и настройка openvpn завершен.

Настройка центра сертификации

Первое что нужно сделать, это создать правильную инфраструктуру для открытых ключей на сервере. Сервером мы считаем ту машину, к которой будут подключаться пользователи. Собственный центр сертификации дает несколько преимуществ, у вас будет собственный орган сертификации, который упростит распространение ключей и управление ими. Например, вы можете отозвать сертификаты клиента на сервере. Также теперь не нужно хранить все клиентские сертификаты, центру сертификации будет достаточно знать, что сертификат подписан CA. Кроме сложной системы ключей, вы можете использовать статические ключи, если нужно предоставить доступ только нескольким пользователям.
Обратите внимание, что все секретные ключи должны находится в надежном месте. В OpenVPN открытый ключ называется сертификатом и имеет расширение .crt, а закрытый ключ так и называется ключом, его расширение - .key.
Сначала создайте папку для хранения сертификатов Easy-RSA. Фактически, конфигурация OpenVPN выполняется вручную, так что папку можно разместить где угодно:
$ sudo mkdir /etc/openvpn/easy-rsa
Затем скопируем в эту папку все необходимые скрипты easy-rsa:
$ sudo cp -R /usr/share/easy-rsa /etc/openvpn/
Далее нам нужно создать центр сертификации в этой папке. Для этого перейдите в нее и выполните такие команды:
$ cd /etc/openvpn/easy-rsa/
$ sudo -i
# source ./vars
# ./clear-all
# ./build-ca

Первой командной мы переключаемся в консоль от имени суперпользователя, второй загружаем переменные окружения из файла ./vars. Команда ./clear-all создает папку keys если ее нет и очищает ее содержимое. И последняя команда инициализирует наш центр сертификации. Теперь в папке .keys появились все необходимые ключи:

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


Дальше нужно повторить процедуру копирования скриптов управления RSA, как мы это делали на сервере:
$ sudo cp -R /usr/share/easy-rsa /etc/openvpn/

Теперь нам нужно скопировать сертификат, файл с расширением .crt в папку /etc/openvpn на всех клиентах. Например, скачаем этот файл для нашего клиента с помощью scp:
$ sudo scp пользователь@хост:/etc/openvpn/easy-rsa/keys/ca.crt /etc/openvpn/easy-rsa/keys
Только теперь можно создать свой секретный ключ на основе сертификата CA:
$ cd /etc/openvpn/easy-rsa/
$ sudo -i
# source ./vars
# build-req Sergiy
Обратите внимание, что ca.crt должен лежать в папке с ключами, иначе ничего не сработает. Теперь утилита создаст ключ, на основе которого, вы сможете подключиться к OpenVPN серверу, но вам еще осталось подписать его на сервере. Отправьте полученный .csr файл на сервер с помощью того же самого scp:
$ scp /etc/openvpn/easy-rsa/keys/Sergiy.csr пользователь@хост:~/
Затем уже на сервере в папке /etc/openvpn/easy-rsa нужно выполнить команду подписи сертификата:
# ./sign-req ~/Sergiy
Подпись сертификата нужно подтвердить. Затем программа сообщит что он был подписан и добавлен в базу данных. В папке с сертификатом csr появится файл .crt, который нужно вернуть назад на клиентскую машину:
$ sudo scp пльзователь@хост:/home/Sergiy.crt /etc/openvpn/easy-rsa/keys
Только после этого сервер и клиент имеют все необходимые ключи для подключения и установки связи. Осталось еще несколько настроек. Если вы планируете использовать шифрование TLS, то необходимо создать на сервере набор данных Диффи-Хафмана, для этого используйте команду:
$ ./build-dh
Дальше будет рассмотрена настройка OpenVPN для сервера и клиента, осталось совсем немного до получения рабочей конфигурации.

Настройка OpenVPN

Теперь настройка сервера OpenVPN. По умолчанию, в папке конфигурационных файлов OpenVPN ничего нет. Их нужно создать самостоятельно в зависимости от того, что планируется настраивать, сервер или клиент. Нужный файл конфигурации OpenVPN можно найти по адресу /usr/share/doc/openvpn/examples/sample-config-files/. Сначала создадим конфигурационный файл для сервера:
$ zcat /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz | sudo tee /etc/openvpn/server.conf
Здесь вам нужно настроить несколько параметров:
port и proto - порт и протокол, по которым будет работать программа;
port 1194
proto udp
Все созданные ключи нужно прописать в конфигурационном файле. Наши ключи хранятся по адресу /etc/openvpn/easy-rsa/keys:
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/ca.crt
key /etc/openvpn/easy-rsa/keys/ca.key
dh /etc/openvpn/easy-rsa/keys/dh.pem
Настраиваем диапазон адресов для виртуальной сети, наш сервер будет доступен по первому из них - 10.8.0.1:
server 10.8.0.0 255.255.255.0
После завершения настройки сохраните изменения в файле, вы можете либо вставить всю эту конфигурацию себе или отредактировать файл с примером. Готовые рабочие настройки сервера:
port 1194
proto udp
comp-lzo
dev tun
ca /etc/openvpn/easy-rsa/2.0/keys/ca.crt
cert /etc/openvpn/easy-rsa/2.0/keys/ca.crt
dh /etc/openvpn/easy-rsa/2.0/keys/dh2048.pem
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
Настройка сервера OpenVPN завершена. Дальше необходимо запустить OpenVPN сервер. Это можно сделать прямо из командной строки, просто укажите адрес конфигурационного файла:
$ openvpn /etc/openvpn/server.conf
Дальше нам нужно настроить компьютер клиента. Вы можете аналогично скопировать конфигурационный файл из директории с примерами, только на этот раз его не нужно распаковывать:
$ sudo cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf  /etc/openvpn/client.conf
Вы можете создать несколько конфигурационных файлов клиента для подключения к разным серверам. Откройте конфигурационный файл и измените в нем такие параметры:
remote - это ваш адрес сервера OpenVPN, адрес и порт должны совпадать с настроенными на сервере, например:
remote 194.67.215.125 1194

ca - ключ, который вы получили от центра сертификации, мы расположили его в папке /etc/openvpn/.
cert и key - это открытый и секретный ключи клиента, с помощью них вы и будете подключаться к серверу. Как вы помните, мы сохранили их в папке /etc/openvpn/easy-rsa/keys/.
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/Sergiy.crt
key /etc/openvpn/easy-rsa/keys/Sergiy.key
Остальные настройки можно оставить как есть. Вот файл настройки целиком, который вы можете скопировать:
client
dev tun
proto udp
remote 194.67.215.125 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/Sergiy.crt
key /etc/openvpn/easy-rsa/keys/Sergiy.key
tls-auth ta.key 1
comp-lzo
verb 3
Сохраните настройки, теперь клиент готов к подключению. Обратите внимание, что конфигурационные файлы должны максимально совпадать, отсутствие определенных опций в одном из файлов может привести к ошибкам. Это не значит, что файлы будут идентичны, но основные параметры openvpn должны быть одинаковыми. Вам осталось запустить OpenVPN на этой машине используя этот конфигурационный файл:
$ openvpn /etc/openvpn/client.conf
Готово, теперь все работает, если вы выполните ifconfig, то увидите что был добавлен интерфейс tun0:
$ ifconfig

Также вы можете попробовать выполнить ping адреса 10.8.0.1, именно этот адрес мы настроили для нашего сервера OpenVPN, пакеты ping будут нормально отправляться. Если пакеты не идут, или еще что-то не работает, обратите внимание на вывод обоих программ, возможно, возникли какие-либо ошибки или предупреждения, также убедитесь, что брандмауэр сервера разрешает доступ извне по udp для порта 1194. Еще можно запустить сервер или клиент, настроив в конфиге уровень подробности на максимум verb 9. Очень часто это помогает понять почему что-то не работает.

Выводы

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