One place for hosting & domains

      Journald

      Como centralizar logs com o Journald no Ubuntu 20.04


      O autor selecionou o Free and Open Source Fund para receber uma doação como parte do programa Write for DOnations.

      Introdução

      Os logs de sistema são um componente extremamente importante no gerenciamento de sistemas Linux. Eles fornecem uma visão valiosa sobre como os sistemas estão funcionando e também como eles estão sendo usados, porque, além de erros, eles registram informações operacionais como eventos de segurança. A configuração padrão para sistemas Linux é para armazenar seus logs localmente no mesmo sistema onde eles ocorreram. Isso funciona para sistemas standalone, mas rapidamente torna-se um problema à medida que o número de sistemas aumenta. A solução para gerenciar todos esses logs é criar um servidor de logs centralizado onde cada host Linux envia seus logs, em tempo real, para um servidor de gerenciamento de logs dedicado.

      Uma solução de log centralizada oferece vários benefícios em comparação com o armazenamento de logs em cada host:

      • Reduz a quantidade de espaço em disco necessária em cada host para armazenar arquivos de log.
      • Os logs podem ser retidos por mais tempo, pois o servidor de log dedicado pode ser configurado com mais capacidade de armazenamento.
      • Análise de log avançada pode ser realizada, o que requer logs a partir de vários sistemas e também mais recursos de computação do que podem estar disponíveis nos hosts.
      • Os administradores de sistemas podem acessar os logs para todos os seus sistemas nos quais eles talvez não consigam efetuar login diretamente por questões de segurança.

      Neste guia, você irá configurar um componente do conjunto de ferramentas systemd para retransmitir mensagens de log de sistemas cliente a um servidor de coleta de log centralizado. Você irá configurar o servidor e o cliente para usar certificados TLS para criptografar as mensagens de log à medida que elas são transmitidas por redes inseguras, como a internet e também para autenticar um ao outro.

      Pré-requisitos

      Antes de iniciar este guia, será necessário o seguinte:

      • Dois servidores Ubuntu 20.04.
      • Um usuário não-root com privilégios sudo em ambos os servidores. Siga o guia Initial Server Setup with Ubuntu 20.04 para instruções sobre como fazer isso. Você também deve configurar o firewall UFW em ambos os servidores, conforme explicado no guia.
      • Dois nomes de host que apontam para seus servidores. Um nome de host para o sistema client que gera os logs e outro para o server de coleta de log. Saiba como apontar nomes de host para os Droplets da DigitalOcean consultando a documentação de Domínios e DNS.

      Este guia irá usar os seguintes dois nomes de host de exemplo:

      • client.your_domain: O sistema cliente que gera os logs.
      • server.your_domain: O servidor de coleta de log.

      Faça login tanto no cliente quanto no servidor em terminais separados via SSH como o usuário sudo não-root para iniciar este tutorial.

      Nota: ao longo do tutorial, os blocos de comando são rotulados com o nome do servidor (client ou server) em que o comando deve ser executado.

      Passo 1 — Instalando o systemd-journal-remote

      Neste passo, você irá instalar o pacote systemd-journal-remote no client e no server. Este pacote contém os componentes que o client e o server usam para transmitir as mensagens de log.

      Primeiro, tanto no client quanto no server, execute uma atualização de sistema para garantir que o banco de dados de pacotes e o sistema estejam atualizados:

      Client and Server

      • sudo apt update
      • sudo apt upgrade

      Em seguida, instale o pacote systemd-journal-remote:

      Client and Server

      • sudo apt install systemd-journal-remote

      No server, habilite e inicie os dois componentes systemd que ele precisa para receber mensagens de log com o seguinte comando:

      Server

      • sudo systemctl enable --now systemd-journal-remote.socket
      • sudo systemctl enable systemd-journal-remote.service

      A opção --now no primeiro comando inicia os serviços imediatamente. Você não o usou no segundo comando, porque este serviço não irá iniciar até que ele tenha certificados TLS, que você irá criar no próximo passo.

      No client, habilite o componente que o systemd usa para enviar as mensagens de log para o servidor:

      Client

      • sudo systemctl enable systemd-journal-upload.service

      Em seguida, no servidor, abra as portas 19532 e 80 no firewall UFW. Isso permitirá ao servidor receber as mensagens de log do cliente. A porta 80 é a porta que o certbot irá usar para gerar o certificado TLS. Os seguintes comandos irão abrir essas portas:

      Server

      • sudo ufw allow in 19532/tcp
      • sudo ufw allow in 80/tcp

      No cliente, você só precisa abrir a porta 80 com este comando:

      Client

      Agora, você instalou os componentes necessários e concluiu a configuração básica do sistema no cliente e no servidor. Antes de configurar esses componentes para começar a retransmitir mensagens de log, você registrará os certificados TLS Let’s Encrypt para o client e o server usando o utilitário certbot.

      Passo 2 — Instalando o Certbot e registrando certificados

      O Let’s Encrypt é uma Autoridade de Certificação que emite certificados TLS gratuitos. Esses certificados permitem que os computadores criptografem os dados que eles enviam entre eles e também verificam a identidade um do outro. Esses certificados são o que lhe permite proteger sua navegação na Internet com HTTPS. Os mesmos certificados podem ser usados por qualquer outra aplicação que queira o mesmo nível de segurança. O processo de registro do certificado é o mesmo, independentemente para o que você o utilize.

      Neste passo, você irá instalar o utilitário certbot e usá-lo para registrar os certificados. Ele também irá cuidar automaticamente de renovar os certificados quando eles expirarem. O processo de registro aqui é o mesmo no client e no server. Você só precisa alterar o nome do host para corresponder ao host onde você está executando o comando de registo.

      Primeiro, habilite o repositório universe do Ubuntu, pois o utilitário certbot reside no repositório universe. Se você já tiver o repositório universe habilitado, executar esses comandos não fará nada com seu sistema e é seguro executar:

      Client and Server

      • sudo apt install software-properties-common
      • sudo add-apt-repository universe
      • sudo apt update

      Em seguida, instale o certbot em ambos os hosts:

      Client and Server

      Agora que você instalou o certbot, execute o seguinte comando para registrar os certificados no client e no server:

      Client and Server

      • sudo certbot certonly --standalone --agree-tos --email sammy@your_domain -d your_domain

      As opções neste comando significam o seguinte:

      • certonly: registrar o certificado e não fazer nenhuma outra alteração no sistema.
      • --standalone: usar o servidor Web embutido do certbot para verificar a solicitação de certificado.
      • --agree-tos: concordar automaticamente com os Termos de Serviço do Let’s Encrypt.
      • --email your-email: este é o endereço de e-mail que o Let’s Encrypt irá usar para notificar você sobre a expiração do certificado e outras informações importantes.
      • -d your_domain: o nome de host para o qual o certificado será registrado. Isso deve corresponder ao sistema em que você o executa.

      Ao executar este comando, você será perguntado se você deseja compartilhar o endereço de e-mail com o Let’s Encrypt para que eles possam enviar a você notícias e outras informações sobre seu trabalho. Fazer isso é opcional, se você não compartilhar seu endereço de e-mail o registro de certificado ainda irá completar normalmente.

      Quando o processo de registro de certificado for concluído, ele irá colocar o certificado e os arquivos de chave em /etc/letsencrypt/live/your_domain/ onde your_domain é o nome de host para o qual você registrou o certificado.

      Por fim, você precisa baixar uma cópia do CA do Let’s Encrypt e certificados intermediários e colocá-los no mesmo arquivo. O journald irá usar este arquivo para verificar a autenticidade dos certificados no client e no server quando eles se comunicam um com o outro.

      O comando a seguir irá baixar os dois certificados do site do Let’s Encrypt e colocá-los em um único arquivo chamado letsencrypt-combined-certs.pem no diretório home do seu usuário.

      Execute este comando no client e no server para baixar os certificados e criar o arquivo combinado:

      Client and Server

      • curl -s https://letsencrypt.org/certs/{isrgrootx1.pem.txt,letsencryptauthorityx3.pem.txt} > ~/letsencrypt-combined-certs.pem

      Em seguida, mova este arquivo para o diretório do Let’s Encrypt que contém os certificados e chaves:

      Client and Server

      • sudo cp ~/letsencrypt-combined-certs.pem /etc/letsencrypt/live/your_domain/

      Agora, você registrou os certificados e as chaves. No próximo passo, você irá configurar o server de coleta de logs para iniciar a escuta e armazenar mensagens de log do client.

      Passo 3 — Configurando o servidor

      Neste passo, você irá configurar o server para usar o certificado e os arquivos de chave que você gerou no último passo para que ele possa começar a aceitar mensagens de log do client.

      O systemd-journal-remote é o componente que faz a escuta para as mensagens de log. Abra seu arquivo de configuração em /etc/systemd/journal-remote.conf com um editor de texto para iniciar a configuração dele no server:

      • sudo nano /etc/systemd/journal-remote.conf

      Em seguida, descomente todas as linhas sob a seção [Remote] e defina os caminhos para apontar para os arquivos TLS que você acabou de criar:

      /etc/systemd/journal-remote.conf

      [Remote]
      Seal=false
      SplitMode=host
      ServerKeyFile=/etc/letsencrypt/live/server.your_domain/privkey.pem
      ServerCertificateFile=/etc/letsencrypt/live/server.your_domain/fullchain.pem
      TrustedCertificateFile=/etc/letsencrypt/live/server.your_domain/letsencrypt-combined-certs.pem
      

      Aqui estão as opções que você usou aqui:

      • Seal=false: assine os dados de log no journal. Habilite isso se você precisar de segurança máxima; caso contrário, você pode deixá-lo como falso.
      • SplitMode=host: os logs dos clientes remotos serão divididos por host em /var/log/journal/remote. Se você preferir que todos os logs sejam adicionados a um único arquivo defina isso como SplitMode=false.
      • ServerKeyFile: o arquivo de chave privada do servidor.
      • ServerCertificateFile: o arquivo de certificado do servidor.
      • TrustedCertificateFile: o arquivo que contém os certificados Let’s Encrypt CA.

      Agora, você precisa alterar as permissões nos diretórios do Let’s Encrypt que contêm os certificados e a chave para que o systemd-journal-remote possa lê-los e usá-los.

      Primeiro, altere as permissões para que o certificado e a chave privada sejam legíveis:

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}
      • sudo chmod 0640 /etc/letsencrypt/live/server.your_domain/privkey.pem

      Em seguida, mude a propriedade do grupo da chave privada para o grupo systemd-journal-remote:

      • sudo chgrp systemd-journal-remote /etc/letsencrypt/live/server.your_domain/privkey.pem

      Agora, você pode iniciar o systemd-journal-remote:

      • sudo systemctl start systemd-journal-remote.service

      Seu server de coleta de log agora está em execução e pronto para começar a aceitar mensagens de log de um client. No próximo passo, você irá configurar o client para retransmitir os logs para seu server de coleta.

      Passo 4 — Configurando o cliente

      Neste passo, você irá configurar o componente que retransmite as mensagens de log para o servidor de coleta de log. Este componente é chamado systemd-journal-upload.

      A configuração padrão para o systemd-journal-upload é que ele usa um usuário temporário que só existe enquanto o processo está em execução. Isso torna mais complicada a permissão para o systemd-journal-upload ler os certificados TLS e as chaves. Para resolver isso, você irá criar um novo usuário de sistema com o mesmo nome que o usuário temporário que será usado em seu lugar.

      Primeiro, crie o novo usuário chamado systemd-journal-upload no client com o seguinte comando adduser:

      • sudo adduser --system --home /run/systemd --no-create-home --disabled-login --group systemd-journal-upload

      Essas opções para o comando são:

      • --system: cria o novo usuário como um usuário do sistema. Isso dá ao usuário um número UID (User Identifier) abaixo de 1000. UID’s acima de 1000 são geralmente dados a contas de usuário que um humano irá usar para fazer login.
      • --home /run/systemd: define /run/systemd como o diretório home para este usuário.
      • --no-create-home: não cria o conjunto de diretório home, uma vez que ele já existe.
      • --disabled-login: o usuário não pode fazer login no servidor via SSH, por exemplo.
      • --group: cria um grupo com o mesmo nome que o usuário.

      Em seguida, defina as permissões e a propriedade dos arquivos de certificado Let’s Encrypt:

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}
      • sudo chmod 0640 /etc/letsencrypt/live/client.your_domain/privkey.pem
      • sudo chgrp systemd-journal-upload /etc/letsencrypt/live/client.your_domain/privkey.pem

      Agora, edite a configuração para o systemd-journal-upload, que está em /etc/systemd/journal-upload.conf. Abra este arquivo com um editor de texto:

      • sudo nano /etc/systemd/journal-upload.conf

      Edite este arquivo para que ele fique como o seguinte:

      /etc/systemd/journal-upload.conf

      [Upload]
      URL=https://server.your_domain:19532
      ServerKeyFile=/etc/letsencrypt/live/client.your_domain/privkey.pem
      ServerCertificateFile=/etc/letsencrypt/live/client.your_domain/fullchain.pem
      TrustedCertificateFile=/etc/letsencrypt/live/client.your_domain/letsencrypt-combined-certs.pem
      

      Por fim, reinicie o serviço systemd-journal-upload para que ele use a nova configuração:

      • sudo systemctl restart systemd-journal-upload.service

      Seu client agora está configurado e funcionando e está enviando suas mensagens de log para o servidor de coleta de log. No próximo passo, você irá verificar se os logs estão sendo enviados e gravados corretamente.

      Passo 5 — Testando o cliente e o servidor

      Neste passo, você irá testar se o client está retransmitindo mensagens de log para o server e se o server está armazenando-as corretamente.

      O servidor de coleta de log armazena os logs dos clientes em um diretório em /var/log/journal/remote/. Quando você reiniciou o client no final do último passo, ele começou a enviar mensagens de log, dessa forma há agora um arquivo de log em /var/log/journal/remote/. O arquivo será nomeado após o nome do host usado para o certificado TLS.

      Use o comando ls para verificar se o arquivo de log do client está presente no server:

      Server

      • sudo ls -la /var/log/journal/remote/

      Isso irá imprimir o conteúdo do diretório mostrando o arquivo de log:

      Output

      total 16620 drwxr-xr-x 2 systemd-journal-remote systemd-journal-remote 4096 Jun 30 16:17 . drwxr-sr-x+ 4 root systemd-journal 4096 Jun 30 15:55 .. -rw-r----- 1 systemd-journal-remote systemd-journal-remote 8388608 Jul 1 10:46 'remote-CN=client.your_domain'

      Em seguida, escreva uma mensagem de log no client para verificar se o server está recebendo as mensagens do client como você espera. Você irá usar o utilitário logger para criar uma mensagem de log personalizada no client. Se tudo estiver funcionando, o systemd-journal-upload irá retransmitir esta mensagem ao server.

      No client execute o seguinte comando logger:

      Client

      • sudo logger -p syslog.debug "### TEST MESSAGE from client.your_domain ###"

      O -p syslog.debug neste comando define a facilidade e a severidade da mensagem. Definir isso para syslog.debug irá tornar claro que ela é uma mensagem de teste. Este comando irá gravar a mensagem ### TEST MESSAGE from client.your_domain ### no journal do cliente, que o systemd-journal-upload então retransmite para o server.

      Em seguida, leia o arquivo de journal do client no server para verificar se as mensagens de log estão chegando do client. Este arquivo é um arquivo de log binário, portanto você não será capaz de lê-lo com ferramentas como o less. Em vez disso, leia o arquivo usando o journalctl com a opção --file= que lhe permite especificar um arquivo de journal personalizado:

      Server

      • sudo journalctl --file=/var/log/journal/remote/remote-CN=client.your_domain.journal

      A mensagem de log irá aparecer da seguinte forma:

      Test log message

      . . . Jun 29 13:10:09 client root[3576]: ### TEST MESSAGE from client.your_domain ###

      Seu servidor de centralização de log agora está coletando logs com sucesso a partir do seu sistema cliente.

      Conclusão

      Neste artigo, você configurou um servidor central de coleta de logs e configurou um cliente para retransmitir uma cópia dos logs de sistema ao servidor. Você pode configurar quantos clientes você precisar retransmitir mensagens ao servidor de coleta de log usando os passos de configuração do cliente que você usou aqui.



      Source link

      Централизация журналов с помощью Journald в Ubuntu 20.04


      Автор выбрал фонд Free and Open Source Fund для получения пожертвования в рамках программы Write for DOnations.

      Введение

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

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

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

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

      Предварительные требования

      Для прохождения этого обучающего руководства вам потребуется следующее:

      • Два сервера Ubuntu 20.04.
      • Пользователь без прав root с привилегиями sudo на обоих серверах. Указания можно найти в руководстве «Начальная настройка сервера Ubuntu 20.04». Также вам следует настроить брандмауэр UFW на обоих серверах, как объясняется в этом руководстве.
      • Два хоста, указывающие на ваши серверы. Одно имя хоста для клиентской системы, которая генерирует журналы, и другое — для сервера сбора журналов. Узнайте, как назначать имена хостов для дроплетов DigitalOcean, ознакомившись с документацией по доменам и DNS.

      В этом руководстве мы будем использовать два типовых имени хоста:

      • client.your_domain: клиентская система, генерирующая журналы.
      • server.your_domain: сервер хранения журналов.

      Для начала этого обучающего модуля выполните вход на клиент и на сервер в отдельных терминалах через SSH как пользователь без прав root с привилегиями sudo.

      Примечание. В этом обучающем модуле блоки команд помечаются именем сервера (client или server), где должна запускаться команда.

      Шаг 1 — Установка systemd-journal-remote

      На этом шаге мы установим пакет systemd-journal-remote на серверах client и server. Этот пакет содержит компоненты, которые client и server используют для пересылки сообщений журнала.

      Вначале проведите обновление системы на серверах client и server, чтобы гарантировать использование актуальных версий системы и базы данных пакетов:

      Client and Server

      • sudo apt update
      • sudo apt upgrade

      Затем установите пакет systemd-journal-remote:

      Client and Server

      • sudo apt install systemd-journal-remote

      На сервере server активируйте и запустите два компонента systemd, необходимых для получения журнала, с помощью следующей команды:

      Server

      • sudo systemctl enable --now systemd-journal-remote.socket
      • sudo systemctl enable systemd-journal-remote.service

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

      Активируйте на сервере client компонент, используемый systemd для отправки сообщений журнала на сервер:

      Client

      • sudo systemctl enable systemd-journal-upload.service

      Откройте на сервере порты 19532 и 80 в брандмауэре UFW. Это позволит серверу получать сообщения журнала от клиента. Порт 80 используется certbot для генерирования сертификата TLS. Эти порты открываются с помощью следующих команд:

      Server

      • sudo ufw allow in 19532/tcp
      • sudo ufw allow in 80/tcp

      На клиенте нужно открыть только порт 80 с помощью следующей команды:

      Client

      Мы установили требуемые компоненты и настроили базовую конфигурацию системы на клиенте и сервере. Прежде чем настраивать эти компоненты для пересылки сообщений журнала, необходимо зарегистрировать сертификаты TLS от Let’s Encrypt для серверов client и server с помощью утилиты certbot.

      Шаг 2 — Установка Certbot и регистрация сертификатов

      Let’s Encrypt — это центр сертификации, выпускающий бесплатные сертификаты TLS. Эти сертификаты позволяют компьютерам шифровать данные, которыми они обмениваются, и выполнять взаимную аутентификацию. Эти сертификаты позволяют защитить компьютер с помощью протокола HTTPS в браузере. Эти же сертификаты могут использоваться любым другим приложением, для которого требуется такой же уровень безопасности. Процесс регистрации сертификата будет одинаковым вне зависимости от его предназначения.

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

      Вначале активируйте репозиторий Ubuntu universe, поскольку утилита certbot находится в репозитории universe. Если у вас уже активирован репозиторий universe, при запуске этих команд ничего не произойдет, так что вы можете безопасно запустить их:

      Client and Server

      • sudo apt install software-properties-common
      • sudo add-apt-repository universe
      • sudo apt update

      Затем установите certbot на обоих хостах:

      Client and Server

      После установки certbot запустите следующую команду для регистрации сертификатов на клиенте и на сервере:

      Client and Server

      • sudo certbot certonly --standalone --agree-tos --email sammy@your_domain -d your_domain

      Опции этой команды имеют следующее значение:

      • certonly: зарегистрировать сертификат и не вносить в систему никаких других изменений.
      • --standalone: использовать встроенный веб-сервер certbot для проверки запроса сертификата.
      • --agree-tos: автоматически принять условия обслуживания Let’s Encrypt.
      • --email your_email: этот адрес электронной почты Let’s Encrypt будет использовать для уведомлений об истечении срока действия сертификатов и отправки другой важной информации.
      • -d your_domain: имя хоста, для которого будет регистрироваться сертификат. Это значение должно соответствовать имени хоста системы, где вы запускаете команду.

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

      После завершения процесса регистрации файлы ключа и сам сертификат будут размещены в каталоге /etc/letsencrypt/live/your_domain/, где your_domain — имя хоста, для которого вы зарегистрировали сертификат.

      В заключение вам нужно будет загрузить копию ЦС Let’s Encrypt и промежуточные сертификаты и поместить их в этот же файл. journald будет использовать этот файл для проверки подлинности сертификатов клиента и сервера при их взаимодействии друг с другом.

      Следующая команда загрузит два сертификата с сайта Let’s Encrypt и поместит их в один файл letsencrypt-combined-certs.pem в домашнем каталоге пользователя.

      Запустите эту команду на клиенте и на сервере для загрузки сертификатов и создания объединенного файла:

      Client and Server

      • curl -s https://letsencrypt.org/certs/{isrgrootx1.pem.txt,letsencryptauthorityx3.pem.txt} > ~/letsencrypt-combined-certs.pem

      Затем переместите этот файл в каталог Let’s Encrypt, содержащий ключи и сертификаты:

      Client and Server

      • sudo cp ~/letsencrypt-combined-certs.pem /etc/letsencrypt/live/your_domain/

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

      Шаг 3 — Настройка сервера

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

      Компонент systemd-journal-remote отслеживает сообщения журнала. Откройте его файл конфигурации /etc/systemd/journal-remote.conf в текстовом редакторе, чтобы начать его настройку на сервере:

      • sudo nano /etc/systemd/journal-remote.conf

      Затем разкомментируйте все строки в разделе [Remote] и установите пути к только что созданным файлам TLS:

      /etc/systemd/journal-remote.conf

      [Remote]
      Seal=false
      SplitMode=host
      ServerKeyFile=/etc/letsencrypt/live/server.your_domain/privkey.pem
      ServerCertificateFile=/etc/letsencrypt/live/server.your_domain/fullchain.pem
      TrustedCertificateFile=/etc/letsencrypt/live/server.your_domain/letsencrypt-combined-certs.pem
      

      Здесь мы используем следующие опции:

      • Seal=false: Подписывать данные в журнале. Активируйте эту опцию, если вам требуется максимальный уровень безопасности, а в ином случае оставьте значение false.
      • SplitMode=host: журналы удаленных клиентов разделяются по хостам в каталоге /var/log/journal/remote. Если вы предпочитаете добавлять все журналы в один файл, установите значение SplitMode=false.
      • ServerKeyFile: файл закрытого ключа сервера.
      • ServerCertificateFile: файл сертификата сервера.
      • TrustedCertificateFile: файл, содержащий сертификаты ЦС Let’s Encrypt.

      Теперь необходимо изменить разрешения для содержащих сертификаты и ключ каталогов Let’s Encrypt, чтобы команда systemd-journal-remote могла считывать и использовать их.

      Вначале измените разрешения так, чтобы сертификат и закрытый ключ были доступны для чтения:

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}
      • sudo chmod 0640 /etc/letsencrypt/live/server.your_domain/privkey.pem

      Затем измените группового владельца закрытого ключа на группу systemd-journal-remote:

      • sudo chgrp systemd-journal-remote /etc/letsencrypt/live/server.your_domain/privkey.pem

      Теперь вы можете запустить systemd-journal-remote:

      • sudo systemctl start systemd-journal-remote.service

      Сервер хранения журналов запущен и готов начать принимать сообщения журнала от клиента. На следующем шаге мы настроим клиент для пересылки журналов на сервер хранения журналов.

      Шаг 4 — Настройка клиента

      На этом шаге мы настроим компонент, пересылающий сообщения журнала на сервер хранения журналов. Этот компонент называется systemd-journal-upload.

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

      Вначале создайте нового пользователя systemd-journal-upload на клиенте с помощью следующей команды adduser:

      • sudo adduser --system --home /run/systemd --no-create-home --disabled-login --group systemd-journal-upload

      Опции этой команды:

      • --system: создать нового пользователя как системного. При этом пользователю присваивается числовой идентификатор UID ниже 1000. Идентификаторы UID выше 1000 обычно присваиваются учетным записям, которые используют пользователи-люди.
      • --home /run/systemd: задать /run/systemd как домашний каталог пользователя.
      • --no-create-home: не создавать набор домашних каталогов, поскольку он уже существует.
      • --disabled-login: этот пользователь не может входить на сервер, например, через SSH.
      • --group: создать группу с тем же именем, что и у пользователя.

      Затем необходимо задать разрешения и владельца файлов сертификатов Let’s Encrypt:

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}
      • sudo chmod 0640 /etc/letsencrypt/live/client.your_domain/privkey.pem
      • sudo chgrp systemd-journal-upload /etc/letsencrypt/live/client.your_domain/privkey.pem

      Теперь отредактируйте конфигурацию systemd-journal-upload в файле /etc/systemd/journal-upload.conf. Откройте этот файл в текстовом редакторе:

      • sudo nano /etc/systemd/journal-upload.conf

      Отредактируйте файл следующим образом:

      /etc/systemd/journal-upload.conf

      [Upload]
      URL=https://server.your_domain:19532
      ServerKeyFile=/etc/letsencrypt/live/client.your_domain/privkey.pem
      ServerCertificateFile=/etc/letsencrypt/live/client.your_domain/fullchain.pem
      TrustedCertificateFile=/etc/letsencrypt/live/client.your_domain/letsencrypt-combined-certs.pem
      

      Перезапустите службу systemd-journal-upload, чтобы она использовала новую конфигурацию:

      • sudo systemctl restart systemd-journal-upload.service

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

      Шаг 5 — Тестирование клиента и сервера

      На этом шаге мы проверим пересылку клиентом сообщений журнала на сервер и правильность их сохранения на сервере.

      Сервер хранения журналов сохраняет журналы клиентов в каталоге /var/log/journal/remote/. Когда мы перезапустили клиент в конце последнего шага, он начал отправлять сообщения журнала, и поэтому теперь в каталоге /var/log/journal/remote/ содержится файл журнала. Имя файла будет соответствовать имени хоста, использованному для сертификата TLS.

      Используйте команду ls, чтобы проверить наличие файла журнала клиента на сервере:

      Server

      • sudo ls -la /var/log/journal/remote/

      Эта команда выводит содержимое каталога, показывая файл журнала:

      Output

      total 16620 drwxr-xr-x 2 systemd-journal-remote systemd-journal-remote 4096 Jun 30 16:17 . drwxr-sr-x+ 4 root systemd-journal 4096 Jun 30 15:55 .. -rw-r----- 1 systemd-journal-remote systemd-journal-remote 8388608 Jul 1 10:46 'remote-CN=client.your_domain'

      Затем запишите сообщение журнала на клиенте, чтобы проверить получение сервером сообщений от клиента ожидаемым образом. Мы используем утилиту logger для создания сообщения журнала на клиенте. Если все работает нормально, systemd-journal-upload перешлет это сообщение на сервер.

      Запустите на клиенте следующую команду logger:

      Client

      • sudo logger -p syslog.debug "### TEST MESSAGE from client.your_domain ###"

      Опция -p syslog.debug в этой команде указывает принадлежность и серьезность сообщения. Мы установим значение syslog.debug, чтобы показать, что это тестовое сообщение. Эта команда записывает сообщение ### TEST MESSAGE from client.your_domain ### в журнал клиента, а systemd-journal-upload пересылает его на сервер.

      Откройте файл журнала клиента на сервере и проверьте поступление сообщений журнала от клиента. Это двоичный файл журнала, поэтому вы не сможете открыть его с помощью таких инструментов, как less. Вместо этого откройте файл с помощью команды journalctl с опцией --file=, позволяющей указать определенный файл журнала:

      Server

      • sudo journalctl --file=/var/log/journal/remote/remote-CN=client.your_domain.journal

      Сообщение журнала будет выглядеть следующим образом:

      Test log message

      . . . Jun 29 13:10:09 client root[3576]: ### TEST MESSAGE from client.your_domain ###

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

      Заключение

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



      Source link

      Cómo centralizar los registros con Journald en Debian 10


      El autor seleccionó Free and Open Source Fund para recibir una donación como parte del programa Write for DOnations.

      Introducción

      Los registros de sistemas son un componente extremadamente importante para administrar sistemas Linux. Proporcionan una visión valiosa sobre cómo funcionan los sistemas, así como sobre cómo se utilizan porque, además de errores, registran información operativa como eventos de seguridad. La configuración estándar para sistemas Linux es almacenar sus registros localmente en el mismo sistema donde se produjeron. Esto funciona para sistemas independientes, pero rápidamente se convierte en un problema, ya que aumenta el número de sistemas. La solución para administrar todos estos registros es crear un servidor de registro centralizado donde cada host Linux envíe sus registros en tiempo real a un servidor de administración de registros específico.

      Una solución de registro centralizada ofrece varias ventajas en comparación con el almacenamiento de registros en cada host:

      • Reduce la cantidad de espacio de disco necesaria en cada host para almacenar archivos de registro.
      • Los registros pueden mantenerse más tiempo, ya que el servidor de registro específico puede configurarse con más capacidad de almacenamiento.
      • Pueden realizarse análisis de registro avanzados que requieren registros de varios sistemas y también más recursos informáticos de los que pueden estar disponible en los hosts.
      • Los administradores de sistemas pueden acceder a los registros para todos sus sistemas a los que quizás no acceden directamente por razones de seguridad.

      En esta guía, configurará un componente de la serie de herramientas systemd para transmitir mensajes de registro desde los sistemas de cliente a un servidor de recopilación de registros centralizado. Configurará el servidor y el cliente para que utilicen certificados TLS para cifrar los mensajes de registro, ya que se transmiten a través de redes inseguras como Internet y también para autenticarse.

      Requisitos previos

      Para completar esta guía, necesitará lo siguiente:

      • Dos servidores Debian 10.
      • Un usuario no root con privilegios sudo en ambos servidores. Siga la guía de configuración inicial de servidor con Debian 10 para obtener instrucciones sobre cómo hacerlo. También debería configurar el firewall UFW en ambos servidores como se explica en la guía.
      • Dos nombres de host que apuntan a sus servidores. Un nombre de host para el sistema cliente que genera los registros y otro para el servidor de compilación de registros. Descubra cómo apuntar nombres de host a DigitalOcean Droplets consultando la documentación sobre dominios y DNS.

      Esta guía utilizará los dos nombres de host siguientes:

      • client.your_domain: el sistema de cliente que genera los registros.
      • server.your_domain: el servidor de compilación de registro.

      Inicie sesión tanto en el cliente como en el servidor en terminales independientes a través de SSH como en el usuario sudo no root para empezar este tutorial.

      Nota: a lo largo de la tutorial, se etiquetan los bloques de comandos con el nombre de servidor (cliente o servidor) en el que debería ejecutarse el comando.

      Paso 1: Instalar systemd-journal-remote

      En este paso, instalará el paquete systemd-journal-remote en el cliente y en el servidor. Este paquete contiene los componentes que utilizan el cliente y el servidor para transmitir los mensajes de registro.

      Primero, tanto en el cliente como en el servidor, ejecute una actualización de sistema para garantizar que la base de datos de paquetes y el sistema estén actualizados:

      Client and Server

      • sudo apt update
      • sudo apt upgrade

      A continuación, instale el paquete systemd-journal-remote:

      Client and Server

      • sudo apt install systemd-journal-remote

      En el servidor, habilite e inicie los dos componentes systemd que necesita para recibir mensajes de registro con el siguiente comando:

      Server

      • sudo systemctl enable --now systemd-journal-remote.socket
      • sudo systemctl enable systemd-journal-remote.service

      La opción --now en el primer comando inicia los servicios de inmediato. No lo utilizó en el segundo comando, ya que este servicio no se iniciará hasta que tenga certificados TLS, lo que creará en el siguiente paso.

      En el cliente, habilite el componente que systemd utiliza para enviar los mensajes de registro al servidor:

      Client

      • sudo systemctl enable systemd-journal-upload.service

      A continuación, en el servidor, abra los puertos 19532 y 80 en el firewall UFW. Esto permitirá al servidor recibir los mensajes de registro del cliente. El puerto 80 es el puerto que certbot utilizará para generar el certificado TLS. Los siguientes comandos abrirán estos puertos:

      Server

      • sudo ufw allow in 19532/tcp
      • sudo ufw allow in 80/tcp

      En el cliente, solo deberá abrir el puerto 80 con este comando:

      Client

      Ahora ha instalado los componentes necesarios y ha completado la configuración del sistema base en el cliente y en el servidor. Antes de que pueda configurar estos componentes para que empiecen a retransmitir los mensajes de registro, registrará los certificados TLS Let’s Encrypt para el cliente y el servidor usando la utilidad certbot.

      Paso 2: Instalar certificados de registro y Certbot

      Let’s Encrypt es una Autoridad de certificados que emite certificados TLS gratuitos. Estos certificados permiten a los ordenadores cifrar los datos que envían entre ellos y también verificar la identidad de cada uno. Estos certificados le permiten proteger su navegación en Internet con HTTPS. Cualquier otra aplicación que quiera el mismo nivel de seguridad, puede usar los mismos certificados. El proceso de registro del certificado es el mismo sin importar para lo que los use.

      En este paso, instalará la utilidad certbot y la usará para registrar los certificados. También automáticamente se ocupará de renovar los certificados cuando expiren. El proceso de registro aquí es el mismo en el cliente y en el servidor. Solo deberá cambiar el nombre de host para que coincida con el host donde está ejecutando el comando de registro.

      Primero, instale certbot y la utilidad curl en ambos hosts:

      Client and Server

      • sudo apt install certbot curl

      Ahora que ha instalado certbot, ejecute el siguiente comando para registrar los certificados en el cliente y en el servidor:

      Client and Server

      • sudo certbot certonly --standalone --agree-tos --email sammy@your_domain -d your_domain

      Las opciones de este comando significan lo siguiente:

      • certonly: registra el certificado y no se realizan otros cambios en el sistema.
      • --standalone: se utilizar el servidor web integrado de certbot para verificar la solicitud de certificado.
      • --agree-tos: se aceptan de forma automática los Términos de uso de Let’s Encrypt.
      • --email your-email: esta es la dirección de correo electrónico que Let’s Encrypt usará para notificarle sobre la expiración del certificado y otra información importante.
      • -d your_domain: el nombre de host para el que se registrará el certificado. Esto debe coincidir con el sistema donde lo ejecuta.

      Cuando ejecute este comando, se le preguntará si quiere compartir la dirección de correo electrónico con Let’s Encrypt para que puedan enviarle por correo electrónico noticias y otra información sobre su trabajo. Hacerlo es opcional; si no comparte su dirección de correo electrónico, el registro de certificados se completará de forma normal.

      Cuando se complete el proceso de registro de certificado, colocará el certificado y los archivos de clave en /etc/letsencrypt/live/your_domain/ donde your_domain es el nombre de host para el que registró el certificado.

      Por último, deberá descargar una copia de los certificados CA Let’s Encrypt y de nivel intermedio y ponerlos en el mismo archivo. journald usará este archivo para verificar la autenticidad de los certificados en el cliente y en el servidor cuando se comuniquen unos con otros.

      El siguiente comando descargará los dos certificados desde el sitio web Let’s Encrypt y los pondrá en un solo archivo llamado letsencrypt-combined-certs.pem en el directorio de inicio de su usuario.

      Ejecute este comando en el cliente y en el servidor para descargar los certificados y crear un archivo combinado:

      Client and Server

      • curl -s https://letsencrypt.org/certs/{isrgrootx1.pem.txt,letsencryptauthorityx3.pem.txt} > ~/letsencrypt-combined-certs.pem

      A continuación, mueva este archivo al directorio Let’s Encrypt que contiene los certificados y las claves:

      Client and Server

      • sudo cp ~/letsencrypt-combined-certs.pem /etc/letsencrypt/live/your_domain/

      Ahora ha registrado los certificados y las claves. En el siguiente paso, configurará el servidor de compilación de registro para que empiece a escuchar y almacenar los mensajes de registro del cliente.

      Paso 3: Configuración del servidor

      En este paso, configurará el servidor para que utilice el certificado y los archivos de clave que generó en el último paso, de forma que pueda comenzar a aceptar los mensajes de registro del cliente.

      systemd-journal-remote es el componente que escucha los mensajes de registro. Abra su archivo de configuración en /etc/systemd/journal-remote.conf con un editor de texto para empezar a configurarlo en el servidor:

      • sudo nano /etc/systemd/journal-remote.conf

      A continuación, elimine todas las líneas de la sección [remoto] y establezca las rutas para que apunten a los archivos TLS que acaba de crear:

      /etc/systemd/journal-remote.conf

      [Remote]
      Seal=false
      SplitMode=host
      ServerKeyFile=/etc/letsencrypt/live/server.your_domain/privkey.pem
      ServerCertificateFile=/etc/letsencrypt/live/server.your_domain/fullchain.pem
      TrustedCertificateFile=/etc/letsencrypt/live/server.your_domain/letsencrypt-combined-certs.pem
      

      Aquí están las opciones que ha utilizado:

      • Seal=false: firma los datos de registro en el diario. Habilítelo si necesita una máxima seguridad; de lo contrario, puede dejarlo como false.
      • SplitMode=host: los registros de los clientes remotos se dividen host en /var/log/journal/remote. Si prefiere que se añadan todos los registros a un solo archivo configúrelo a SplitMode=false.
      • ServerKeyFile: el archivo de clave privada del servidor.
      • ServerCertificateFile: el archivo de certificado del servidor.
      • TrustedCertificateFile: el archivo que contiene los certificados Let’s Encrypt CA.

      Ahora, deberá cambiar los permisos en los directorios Let’s Encrypt que contienen los certificados y la clave para que systemd-journal-remote los pueda leer y usar.

      Primero, cambie los permisos para que el certificado y la clave privada se puedan leer:

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}
      • sudo chmod 0640 /etc/letsencrypt/live/server.your_domain/privkey.pem

      A continuación, cambie la propiedad de grupo de la clave privada al grupo systemd-journal-remote:

      • sudo chgrp systemd-journal-remote /etc/letsencrypt/live/server.your_domain/privkey.pem

      Ahora puede iniciar systemd-journal-remote:

      • sudo systemctl start systemd-journal-remote.service

      Ahora se está ejecutando su servidor de compilación de registro y está listo para comenzar a aceptar mensajes de registro de un cliente. En el siguiente paso, configurará el cliente para que envíe los registros a su servidor de compilación.

      Paso 4: Configurar el cliente

      En este paso, configurará el componente que transmite los mensajes de registro al servidor de compilación de registro. Este componente se llama systemd-journal-upload.

      La configuración predeterminada para systemd-journal-upload es la que utiliza un usuario temporal que solo existe mientras se está ejecutando. Esto permite que systemd-journal-upload lea los certificados TLS y las claves más complicadas. Para resolverlo, creará un nuevo usuario de sistema con el mismo nombre que el usuario temporal que se utilizará en su lugar.

      Primero, cree el nuevo usuario llamado systemd-journal-upload en el cliente con el siguiente comando adduser:

      • sudo adduser --system --home /run/systemd --no-create-home --disabled-login --group systemd-journal-upload

      Estas opciones al comando son:

      • --system: crea el nuevo usuario como un usuario de sistema. Esto le da al usuario un número UID (Identificador de usuario) inferior a 1000. Normalmente, los UID superiores a 1000 se dan a las cuentas de usuario con las que un humano iniciará sesión.
      • --home /run/systemd: establece /run/systemd como el directorio de inicio de este usuario.
      • --no-create-home: no crea el conjunto de directorio de inicio, puesto que ya existe.
      • --disabled-login: el usuario no puede iniciar sesión en el servidor a través de SSH, por ejemplo.
      • --group: crea un grupo con el mismo nombre que el usuario.

      A continuación, establezca los permisos y la propiedad de los archivos de certificado Let’s Encrypt:

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}
      • sudo chmod 0640 /etc/letsencrypt/live/client.your_domain/privkey.pem
      • sudo chgrp systemd-journal-upload /etc/letsencrypt/live/client.your_domain/privkey.pem

      Ahora, edite la configuración para systemd-journal-upload, que está en /etc/systemd/journal-upload.conf. Abra este archivo con un editor de texto:

      • sudo nano /etc/systemd/journal-upload.conf

      Edite este archivo de forma que tenga el siguiente aspecto:

      /etc/systemd/journal-upload.conf

      [Upload]
      URL=https://server.your_domain:19532
      ServerKeyFile=/etc/letsencrypt/live/client.your_domain/privkey.pem
      ServerCertificateFile=/etc/letsencrypt/live/client.your_domain/fullchain.pem
      TrustedCertificateFile=/etc/letsencrypt/live/client.your_domain/letsencrypt-combined-certs.pem
      

      Por último, reinicie el servicio systemd-journal-upload para que utilice la nueva configuración:

      • sudo systemctl restart systemd-journal-upload.service

      Ahora su cliente está configurado y ejecutado, y envía sus mensajes de registro al servidor de compilación de registro. En el siguiente paso, comprobará que los registros se están enviando de forma correcta.

      Paso 5: Probar el cliente y el servidor

      En este paso, probará que el cliente está enviando mensajes de registro al servidor y que el servidor los almacena correctamente.

      El servidor de compilación de registro almacena los registros de los clientes en un directorio en /var/log/journal/remote/. Cuando reinició el cliente e al final del último paso, comenzó a enviar mensajes de registro, de forma que ahora hay un archivo de registro en /var/log/journal/remote/. El archivo se llamará como el nombre de host que utilizó para el certificado TLS.

      Utilice el comando ls para comprobar que el archivo de registro del cliente está presente en el servidor:

      Server

      • sudo ls -la /var/log/journal/remote/

      Esto imprimirá el contenido del directorio que muestra el archivo de registro:

      Output

      total 16620 drwxr-xr-x 2 systemd-journal-remote systemd-journal-remote 4096 Jun 30 16:17 . drwxr-sr-x+ 4 root systemd-journal 4096 Jun 30 15:55 .. -rw-r----- 1 systemd-journal-remote systemd-journal-remote 8388608 Jul 1 10:46 'remote-CN=client.your_domain'

      A continuación, escriba un mensaje de registro en el cliente para comprobar que el servidor está recibiendo los mensajes del cliente como se espera. Usará la utilidad logger para crear un mensaje de registro personalizado en el cliente. Si todo está funcionando, systemd-journal-upload transmitirá este mensaje al servidor.

      En el cliente ejecute el siguiente comando logger:

      Client

      • sudo logger -p syslog.debug "### TEST MESSAGE from client.your_domain ###"

      El -p syslog.debug en este comando establece la instalación y la gravedad del mensaje. Configurar esto a syslog.debug aclarará que es un mensaje de prueba. Este comando grabará el mensaje ### TEST MESSAGE from client.your_domain ### al diario del cliente, que systemd-journal-upload transmitirá al servidor.

      A continuación, lea el archivo de diario del cliente en el servidor para comprobar que los mensajes de registro están llegando desde el cliente. Este archivo es un archivo de registro binario de forma que no podrá leerlo con herramientas como less. En su lugar, lea el archivo usando journalctl con la opción --file= que le permite especificar un archivo de diario personalizado:

      Server

      • sudo journalctl --file=/var/log/journal/remote/remote-CN=client.your_domain.journal

      El mensaje de registro aparecerá como se muestra:

      Test log message

      . . . Jun 29 13:10:09 client root[3576]: ### TEST MESSAGE from client.your_domain ###

      Ahora su servidor de centralización de registro está recopilando correctamente los registros de su sistema de cliente.

      Conclusión

      En este artículo, configuró un servidor de compilación central de registro y configuró un cliente para que transmitiera una copia de sus registros de sistema al servidor. Puede configurar tantos clientes como necesite para transmitir los mensajes al servidor de compilación de registro usando los pasos de configuración del cliente que utilizó aquí.



      Source link