Category Archive Linux

Автор:human

Скрипт удаления писем из очереди postfix по получателю

Скрипт удаления писем из очереди postfix по получателю

Автор:human

Установка node js 6 на debian 8 jessie

Установка node js 6 на debina 8 jessie из репы

Установка из исходников — например 6.2.1 (сборка)

# смотрим версии

Делаем симлинки

Делаем симлинки
Просмотрим версию

Автор:human

Docker compose — установка и настройка

Шаг 1-й установка docker

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

Шаг 2-й установка docker-compose

После установки необходимых пакетов мы установим сам docker комопозер

 

Шаг 3-й запуск docker контейнеров через docker-compose

The public Docker registry, Docker Hub, includes a simple Hello World image. Now that we have Docker Compose installed, let’s test it with this really simple example.

First, create a directory for our YAML file:

mkdir hello-world
Then change into the directory:

cd hello-world
Now create the YAML file using your favorite text editor (we will use nano):

nano docker-compose.yml
Put the following contents into the file, save the file, and exit the text editor:

docker-compose.yml
my-test:
image: hello-world
The first line will be used as part of the container name. The second line specifies which image to use to create the container. The image will be downloaded from the official Docker Hub repository.

While still in the ~/hello-world directory, execute the following command to create the container:

docker-compose up
The output should start with the following:

Output of docker-compose up
Creating helloworld_my-test_1…
Attaching to helloworld_my-test_1
my-test_1 |
my-test_1 | Hello from Docker.
my-test_1 | This message shows that your installation appears to be working correctly.
my-test_1 |
The output then explains what Docker is doing:

The Docker client contacted the Docker daemon.
The Docker daemon pulled the «hello-world» image from the Docker Hub.
The Docker daemon created a new container from that image which runs the executable that produces the output you are currently reading.
The Docker daemon streamed that output to the Docker client, which sent it to your terminal.
If the process doesn’t exit on its own, press CTRL-C.

This simple test does not show one of the main benefits of Docker Compose — being able to bring a group of Docker containers up and down all at the same time. The How To Install WordPress and PhpMyAdmin with Docker Compose on Ubuntu 14.04 articles show how to use Docker Compose to run three containers as one application group.

 
Step 4 — Learning Docker Compose Commands

Let’s go over the commands the docker-compose tool supports.

The docker-compose command works on a per-directory basis. You can have multiple groups of Docker containers running on one machine — just make one directory for each container and one docker-compose.yml file for each container inside its directory.

So far we’ve been running docker-compose up on our own and using CTRL-C to shut it down. This allows debug messages to be displayed in the terminal window. This isn’t ideal though, when running in production you’ll want to have docker-compose act more like a service. One simple way to do this is to just add the -d option when you up your session:

docker-compose up -d
docker-compose will now fork to the background.

To show your group of Docker containers (both stopped and currently running), use the following command:

docker-compose ps
For example, the following shows that the helloworld_my-test_1 container is stopped:

Output of docker-compose ps
Name Command State Ports
————————————————
helloworld_my-test_1 /hello Exit 0
A running container will show the Up state:

Output of docker-compose ps
Name Command State Ports
—————————————————————
nginx_nginx_1 nginx -g daemon off; Up 443/tcp, 80/tcp
To stop all running Docker containers for an application group, issue the following command in the same directory as the docker-compose.yml file used to start the Docker group:

docker-compose stop
Note: docker-compose kill is also available if you need to shut things down more forcefully.

In some cases, Docker containers will store their old information in an internal volume. If you want to start from scratch you can use the rm command to fully delete all the containers that make up your container group:

docker-compose rm
If you try any of these commands from a directory other than the directory that contains a Docker container and .yml file, it will complain and not show you your containers:

Output from wrong directory
Can’t find a suitable configuration file in this directory or any parent. Are you in the right directory?

Supported filenames: docker-compose.yml, docker-compose.yaml, fig.yml, fig.yaml
 
Step 5 — Accessing the Docker Container Filesystem (Optional)

If you need to work on the command prompt inside a container, you can use the docker exec command.

The Hello World! example exits after it is run, so we need to start a container that will keep running so we can then use docker exec to access the filesystem for the container. Let’s take a look at the Nginx image from Docker Hub.

Create a new directory for it and change into it:

mkdir ~/nginx && cd $_
Create a docker-compose.yml file in our new directory:

nano docker-compose.yml
and paste in the following:

~/nginx/docker-compose.yml
nginx:
image: nginx
Save the file and exit. We just need to start the Nginx container as a background process with the following command:

docker-compose up -d
The Nginx image will be downloaded and then the container will be started in the background.

Now we need the CONTAINER ID for the container. List of all the containers that are running:

docker ps
You will see something similar to the following:

Output of docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e90e12f70418 nginx «nginx -g ‘daemon off» 6 minutes ago Up 5 minutes 80/tcp, 443/tcp nginx_nginx_1
Note: Only running containers are listed with the docker ps command.

If we wanted to make a change to the filesystem inside this container, we’d take its ID (in this examplee90e12f70418) and use docker exec to start a shell inside the container:

docker exec -it e90e12f70418 /bin/bash
The -t option opens up a terminal, and the -i option makes it interactive. The /bin/bash options opens a bash shell to the running container. Be sure to use the ID for your container.

You will see a bash prompt for the container similar to:

root@e90e12f70418:/#
From here, you can work from the command prompt. Keep in mind, however, that unless you are in a directory that is saved as part of a data volume, your changes will disappear as soon as the container is restarted. Another caveat is that most Docker images are created with very minimal Linux installs, so some of the command line utilities and tools you are used to may not be present.

Автор:human

Авторизация с помощью клиентских SSL сертификатов.

Авторизация с помощью клиентских SSL сертификатов.

Протокол безопасной передачи данных SSL (Secure Sockets Layer) помимо
обеспечения безопасной передачи данных позволяет также реализовать
авторизацию клиентов на сервере с помощью клиентских SSL сертификатов.
Данная статья является практическим руководством по реализации данного
вида авторизации. В статье не рассматриваются теоретические основы
криптографии или передачи данных по протоколу SSL. Подразумеваемся,
что читатель хотя бы поверхностно знаком с понятиями, используемыми в
этой статье, такими как сертификат, секретный ключ, подпись
сертификата и т.д.

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

Наиболее наглядным примером использования авторизации посредством
клиентских сертификатов является система платежей WebMoney Transfer, а
точнее реализация WM Keeper Light. Данная схема авторизации признана
наиболее надежной и, в том или ином виде, широко используется в сфере
предоставления банковских услуг.

Практическая реализация рассматривается на основе популярной связки
веб-сервера Apache (https://httpd.apache.org/) и модуля mod_ssl (https://www.modssl.org/),
основанного на использовании библиотеки openssl (https://www.openssl.org/).
Предполагается, что соответствующее программное обеспечение у вас уже
установлено.

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

1. Создать собственный доверенный сертификат (Certificate Authority),
для того чтобы с помощью него подписывать и проверять клиентские
сертификаты.
2. Создать клиентские сертификаты, подписанные доверенным
сертификатом, для последующей передачи их клиентам.
3. Сконфигурировать веб-сервер для запроса и проверки клиентских
сертификатов.

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

Создание собственного самоподписанного доверенного сертификата.

Собственный доверенный сертификат (Certificate Authority — далее CA)
необходим для подписи клиентских сертификатов и для их проверки при
авторизации клиента веб-сервером. С помощью приведенной ниже команды
создается закрытый ключ и самоподписанный сертификат.

Описание аргументов:

Запрос на создание нового сертификата.

Создание запроса на сертификат (Certificate Signing Request —
далее CSR).

Автоматически будет создан новый закрытый RSA ключ длиной 1024
бита. Длину ключа можете настроить по своему усмотрению.

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

Данные сертификата, пары параметр=значение, перечисляются через
‘/’. Символы в значении параметра могут быть «подсечены» с
помощью обратного слэша «\», например «O=My\ Inc». Также можно
взять значение аргумента в кавычки, например, -subj
«/xx/xx/xx».
Описание параметров:
С — Двухсимвольный код страны (Country). Необязательный
параметр.
ST — Название региона/области/края/республики/… (State
Name). Необязательный параметр.
L — Название города/поселка/… (Locality Name).
Необязательный параметр.
O — Название организации (Organization Name).
Необязательный параметр.
OU — Название отдела (Organization Unit). Необязательный
параметр.
CN — Имя сертификата, при создании серверных сертификатов
используется доменное имя сайта, для клиентских
сертификатов может быть использовано что угодно (Common
Name). Обязательный параметр. Максимальная длина 64
символа.
emailAddress — почтовый адрес (E-mail address).
Необязательный параметр. Максимальная длина 40 символов.

Необязательные параметры могут быть пропущены, например,
/C=RU/CN=blabla/emailAddress=user@domain.ru.

В результате выполнения команды появятся два файла ca.key и ca.crt.

Просмотреть данные закрытого ключа и сертификата вы можете с помощью
команд:

Создание клиентских сертификатов

Подготовка конфигурации и файлов для подписи сертификатов.

Создайте конфигурационный файл с именем ca.config следующего
содержания.

Создайте структуру каталогов и файлов, соответсвующую описанной в
конфигурационном файле

Примечание: В файле db/serial записывается текущий серийный номер
подписываемого сертификата в шестнадцатиричном формате. В файл
db/index.txt сохраняются данные о подписываемых сертификатах.

Создание клиентского закрытого ключа и запроса на сертификат (CSR).

Для создания подписанного клиентского сертификата предварительно
необходимо создать запрос на сертификат, для его последующей подписи.
Аргументы команды полностью аналогичны аргументам использовавшимся при
создании самоподписанного доверенного сертификата (см. $1), но
отсутсвует параметр -x509.

В результате выполнения команды появятся два файла client01.key и
client01.csr. Просмотреть данные закрытого ключа и запроса на
сертификат (CSR) вы можете с помощью команд:

Подпись запроса на сертификат (CSR) с помощью доверенного сертификата (CA).

При подписи запроса используются параметры заданные в файле ca.config

Описание аргументов:

Подпись запроса с помощью CA.

Использовать конфигурационный файл ca.config.

CSR находится в файле client01.csr

Сохранить сертификат в файл client01.crt

Не спрашивать подтверждения подписи.

В результате выполнения команды появится файл клиентского сертификата
client01.crt. Просмотреть данные сертификата вы можете с помощью
команды:

Подготовка данных для передачи клиенту.

Для передачи полученных в результате предыдущих операций файлов
клиенту, обычно используется файл в формате PKCS#12. В этот файл
упаковывается и защищается паролем вся информация необходимая клиенту
для инсталяции сертификата в броузер.

Описание аргументов:

Работа с файлами формата PKCS#12.

Экспортирование данных в файл.

Файл клиентского сертификата.

Файл закрытого ключа.

Файл доверенного сертификата.

Сохранить данные в файл client01.p12.

Установить пароль q1w2e3 на файл (пароль может быть любым, в
том числе и пустым)

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

Для создания новых клиентских сертификатов повторите операции с $2.2.
по $2.4.

Настройка веб-сервера.

Для реализации процесса авторизации по клиентским сертификатам
необходимо сконфигурировать веб-сервер для решения следующих задач:
1. Запрет доступа к защищаемой области по протоколу HTTP.
2. Запрос и проверка клиентских сертификатов.

Запрет доступа к защищаемой области по протоколу HTTP.

Найдите в конфигурационном файле веб-сервера httpd.conf секцию
, соответсвующую вашему сайту и добавьте в неё
следующие директивы

Описание директив:

Абсолютный путь до директории защищаемой области.

Запрещает доступ клиенту, если при соединении не используется
протокол HTTPS (HTTP через SSL).

Запрос и проверка клиентских сертификатов.

Найдите в конфигурационном файле веб-сервера httpd.conf секцию ,
соответсвующую вашему сайту и добавьте в неё следующие директивы:

Описание директив:

Абсолютный путь до доверенного сертификата (см. $1.). Также в
качестве значения директивы SSLCACertificateFile может быть
указан файл, содержащий несколько доверенных сертификатов
(формируется путем обычной конкатенации файлов сертификатов),
тогда все они будут считаться доверенными сертификатами.

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

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

Альтернативные способы настройки веб-сервера.

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

Пример 1.

Допустим файл указанный в директиве SSLCACertificateFile содержит
несколько доверенных сертификатов (см. описание директивы
SSLCACertificateFile). Требуется разрешить доступ до защищенной
области только владельцам сертификатов, подписанных только одним из
поставщиков.

Описание директив:

Требует чтобы организацией поставщика клиентского сертификата
являлась «First CA Inc.». Аналогичным способом можно проверять
любые другие параметры клиентского сертификата или его
поставщика. Более подробную информацию о директиве SSLRequire и
именах переменных смотрите в документации по mod_ssl.

Пример 2.

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

Содержимое файла /path/to/passwd/file

Описание директив:

Имитирует простую авторизацию веб-сервером. Имя пользователя и
пароль не запрашиваются, но сверяются данные клиентского
сертификата с данными в файле /path/to/passwd/file. Строка
идентифицирующая клиента может быть получена из клиентского
сертификата с помощью команды:

Или взята из базы данных db/index.txt, формируемой при подписи
CSR (см. $2.). В качестве пароля всегда используется строка
«xxj31ZMTZzkVA», являющаяся результатом шифрования строки
«password» с помощью алгоритма DES.

Отзыв сертификатов.

Результат проверки веб-сервером клиентского сертификата будет успешным
на весь срок действия сертификата. Возникает вопрос, что делать в
случае если вы хотите отказать какому-либо клиенту в доступе по его
клиентскому сертификату. Для решения этой проблемы создается список
отзыва сертификатов (Certificate Revocation List — CRL). В списке
отзыва перечисляются отозванные вами клиентские сертификаты. В
соответсвии с этим списком веб-сервер будет отклонять запросы если
сертифкат клиента отозван.

Создание списка отзыва (CRL).

При создании списка отзыва используется тот же конфигурационный файл и
таже структура файлов, что и при подписи сертификатов (см. $2.1.),
поэтому при выполнении следующей команды вы должны находиться в том же
каталоге.

Описание аргументов:

При создании CRL также используется этот аргумент.

Создание списка отзыва сертификатов.

Использовать конфигурационный файл ca.config.

Сохранить созданный список отзыва в файл ca.crl

В результате будет создан список отзыва, основанный на базе данных
подписанных сертификатах db/index.txt. Так как на данный момент ни
один из сертификатов в базе данных не помечен как отозванный, то
созданный список будет пустым. Просмотреть данные списка отзыва вы
можете с помощью следующей команды.

Одной из важных черт списка отзыва является его срок действия,
указываемый в конфигурационном файле ca.config с помощью директивы
default_crl_days. Также альтернативно может быть использована
директива default_crl_hours, если вы планируете часто обновлять ваш
CRL. Список отзыва должен обновляться не позже истечения срока
действия. Для переодического вызова приведенной выше команды можно
использовать cron.

Отзыв сертификата.

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

Описание аргументов:

Настройка веб-сервера

После создания списка отзыва сертификатов необходимо дать возможность
веб-серверу использовать его. Для этого добавьте приведенную ниже
директиву в конфигурационный файл веб-сервера.

Описание директив:

Не забывайте перезапускать веб-сервер после каждого изменения его
конфигурации.

Заключение.

Вышеизложенный материал можно дополнять и углублять, цель статьи —
минимальное руководство по реализации авторизации по клиентским
сертификатам на практике. Любой читатель, имеющий доступ к
использовавшемуся программному обеспечению, с помощью этой статьи
может за короткое время настроить свой веб-сервер для решения этой
задачи. Каждый из изложенных пунктов можно расширить и написать по
нему отдельную статью, заинтересовавшиеся читатели могут получить
дополнительные сведения в документации по Apache, mod_ssl и openssl. В
заключение хочется дать несколько советов по программной реализации
вышеописанных процессов.

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

# … код, реализующий подпись сертификата …

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

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

Описание директив:

Включает установку в переменные окружения текста сертификатов
использовавшихся при передаче данных.

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

Альтернативой переменной REMOTE_USER могут служить следующие
переменные: SSL_CLIENT_M_SERIAL — серийный номер клиентского
сертификата, SSL_CLIENT_S_DN_CN — имя сертификата (Common Name) или
SSL_CLIENT_S_DN — данные сертификата (Subject Name, см. описание
аргумента -subj в $1). Если вы хотите использовать переменную
SSL_CLIENT_S_DN_CN для идентификации пользователя, то вы должны
обеспечить уникальность Common Name для разных сертификатов при
создании запросов на клиентский сертификат (см. $2.2.). Уникальность
SSL_CLIENT_M_SERIAL и SSL_CLIENT_S_DN гарантируется автоматически при
подписи сертификатов.

Несколько мелких замечаний от Александр Елисеенко:

1) ключ -sabj при генерации сертификатов явно лишний, все именные
данные и так будут запрошены (в интерактиве). Для упрощения жизни
можно отредактировать файл openssl.cnf, секция [
req_distinguished_name ]. Тогда останется только жать ENTER.

2) специально создавать файл ca.config нет смысла, дешевле
воспользоваться готовым openssl.cnf

3) подробное освещение вопроса генерации сертификатов — дело нужное,
но не лишним было бы отметить, что в составе дистрибутива openssl есть
готовый скрипт CA (CA.sh или GA.pl), с помощью которого ключи
генерятся без всяких проблем

Ну и по вопросу организации проверки клиентских сертификатов на
сервере — не все так просто,как написано в статье.

Корневой (или доверенный) сертификат может быть не один. Каталог, где
они размещены, указывается директивой SSLCACertificatePath. Для
каждого доверенного сертификата должен быть указан md5 hash. Все
доверенные сертификаты могут быть сгруппированы в один файл (вместе с
md5 хэшем, а не путем обычной конкатенации файлов сертификатов), путь
к нему в этом случае указывается директивой SSLCACertificateFile. Если
используются довереннные сертификаты, подписанные другими CA, то
директивой SSLVerifyDepth устанавливается глубина проверки цепочки
сертификатов.

Источник — https://www.opennet.ru/base/sec/ssl_cert.txt.html