One place for hosting & domains

      January 2020

      Como Sincronizar e Compartilhar Seus Arquivos com o Seafile no Debian 10


      Introdução

      O Seafile é uma plataforma de compartilhamento e sincronização de arquivos open-source e auto-hospedada. Os usuários podem armazenar e, opcionalmente, criptografar dados em seus próprios servidores, tendo o espaço de armazenamento como única limitação. Com o Seafile, você pode compartilhar arquivos e pastas usando links de sincronização multi-plataformas e protegidos por senha para arquivos com datas de validade. O recurso de versionamento de arquivo significa que os usuários podem restaurar arquivos ou pastas excluídos e modificados.

      Neste tutorial, você instalará e configurará o Seafile em um servidor Debian 10. Você usará o MariaDB (a variante padrão do MySQL no Debian 10) para armazenar dados para os diferentes componentes do Seafile e o Apache como servidor proxy para lidar com o tráfego web. Após concluir este tutorial, você poderá usar a interface web para acessar o Seafile a partir de clientes móveis ou desktops, permitindo sincronizar e compartilhar seus arquivos com outros usuários ou grupos no servidor ou com o público.

      Pré-requisitos

      Antes de começar este guia, você precisará do seguinte:

      Passo 1 — Criando Bancos de Dados para os Componentes do Seafile

      O Seafile requer três componentes para funcionar corretamente:

      • Seahub: O front-end web do Seafile, escrito em Python usando o framework web Django. A partir do Seahub, você pode acessar, gerenciar e compartilhar seus arquivos usando um navegador web.
      • Seafile server: O daemon do serviço de dados que gerencia o upload, o download e a sincronização de arquivos raw. Você não interage diretamente com o servidor, mas usa um programa cliente ou a interface web Seahub.
      • Ccnet server: O daemon de serviço RPC para permitir a comunicação interna entre os diferentes componentes do Seafile. Por exemplo, quando você usa o Seahub, ele pode acessar dados do servidor Seafile usando o serviço RPC Ccnet.

      Cada um desses componentes armazena seus dados separadamente em seu próprio banco de dados. Neste passo, você criará os três bancos de dados MariaDB e um usuário antes de prosseguir com a configuração do servidor.

      Primeiro, efetue login no servidor usando SSH com seu nome de usuário e endereço IP:

      ssh sammy@ip_do_seu_servidor
      

      Conecte-se ao servidor de banco de dados MariaDB como administrador (root):

      No prompt do MariaDB, use o seguinte comando SQL para criar o usuário do banco de dados:

      • CREATE USER 'sammy'@'localhost' IDENTIFIED BY 'senha';

      Em seguida, você criará os seguintes bancos de dados para armazenar os dados dos três componentes do Seafile:

      • ccnet-db para o servidor Ccnet.
      • seahub-db para o frontend web Seahub.
      • seafile-db para o servidor Seafile.

      No prompt do MariaDB, crie seus bancos de dados:

      • CREATE DATABASE 'ccnet-db' CHARACTER SET = 'utf8';
      • CREATE DATABASE 'seafile-db' CHARACTER SET = 'utf8';
      • CREATE DATABASE 'seahub-db' CHARACTER SET = 'utf8';

      Em seguida, conceda todos os privilégios ao seu usuário de banco de dados para acessar e fazer alterações nesses bancos de dados:

      • GRANT ALL PRIVILEGES ON 'ccnet-db'.* to 'sammy'@localhost;
      • GRANT ALL PRIVILEGES ON 'seafile-db'.* to 'sammy'@localhost;
      • GRANT ALL PRIVILEGES ON 'seahub-db'.* to 'sammy'@localhost;

      Saia do prompt do MariaDB digitando exit:

      Agora que você criou um usuário e os bancos de dados necessários para armazenar os dados de cada um dos componentes do Seafile, você instalará as dependências para baixar o pacote do servidor Seafile.

      Passo 2 — Instalando Dependências e Baixando o Seafile

      Algumas partes do Seafile são escritas em Python e, portanto, requerem módulos e programas adicionais em Python para funcionar. Neste passo, você instalará essas dependências necessárias antes de baixar e extrair o pacote do servidor Seafile.

      Para instalar as dependências usando o apt, execute o seguinte comando:

      • sudo apt install python-setuptools python-pip python-urllib3 python-requests python-mysqldb ffmpeg

      As dependências python-setuptools e python-pip supervisionam a instalação e o gerenciamento de pacotes Python. Os pacotes python-urllib3 e python-orders fazem solicitações aos websites. Finalmente, o python-mysqldb é uma biblioteca para usar o MariaDB no Python e o ffmpeg lida com arquivos multimídia.

      O Seafile requer o Pillow, uma biblioteca python para processamento de imagens, e o moviepy para lidar com as miniaturas dos arquivos de filmes. Estes módulos não estão disponíveis no repositório de pacotes Debian, então instale-os com o pip:

      • sudo pip install Pillow moviepy

      Agora que você instalou as dependências necessárias, pode fazer o download do pacote do servidor Seafile.

      O Seafile cria diretórios adicionais durante a instalação. Para mantê-los todos organizados, crie um novo diretório e mude para ele:

      Você pode baixar a versão mais recente (7.0.4 no momento em que este artigo foi escrito) do servidor Seafile a partir do website do projeto executando este comando:

      • wget https://download.seadrive.org/seafile-server_7.0.4_x86-64.tar.gz

      O Seafile distribui o download como um arquivo tar compactado, o que significa que você precisará extraí-lo antes de continuar. Extraia o arquivo usando tar:

      • tar -zxvf seafile-server_7.0.4_x86-64.tar.gz

      Agora mude para o diretório extraído:

      Nesta fase, você baixou e extraiu o pacote do servidor Seafile e também instalou as dependências necessárias. Agora você está pronto para configurar o servidor Seafile.

      Passo 3 — Configurando o Servidor Seafile

      O Seafile precisa de algumas informações sobre sua configuração antes de iniciar os serviços pela primeira vez. Isso inclui detalhes como o nome do domínio, a configuração do banco de dados e o caminho em que os dados serão armazenados. Para iniciar a série de solicitações de perguntas para fornecer essas informações, você pode executar o script setup_seafile_mysql.sh, incluído no arquivo que você extraiu na etapa anterior.

      Execute o script usando o bash:

      • bash setup-seafile-mysql.sh

      Pressione ENTER para continuar quando solicitado.

      O script agora fará uma série de perguntas. Onde quer que os padrões sejam mencionados, pressionar a tecla ENTER utilizará esse valor.

      Este tutorial usa Seafile como o nome do servidor, mas você pode alterá-lo se desejar:

      Question 1
      
      What is the name of the server?
      It will be displayed on the client. 3 - 15 letters or digits
      [ server name ] Seafile
      

      Para Question 2, digite o nome de domínio para esta instância do Seafile.

      Question 2
      
      What is the ip or domain of the server?.
      For example: www.mycompany.com, 192.168.1.101
      [ This server's ip or domain ] seu_domínio
      

      Pressione ENTER para aceitar o valor padrão para a Question 3. Se você configurou o armazenamento externo, por exemplo, usando NFS ou armazenamento em bloco, precisará especificar o caminho para esse local aqui.

      Question 3
      
      Where do you want to put your seafile data?
      Please use a volume with enough free space
      [ default "/home/sammy/seafile/seafile-data" ]
      

      Para Question 4 pressione ENTER para aceitar o número da porta padrão.

      Question 4
      
      Which port do you want to use for the seafile fileserver?
      [ default "8082" ]
      

      O próximo prompt permite confirmar a configuração do banco de dados. Você pode criar novos bancos de dados ou usar bancos de dados existentes para configuração. Para este tutorial, você criou os bancos de dados necessários no Passo 1, então selecione a opção 2 aqui.

      -------------------------------------------------------
      Please choose a way to initialize seafile databases:
      -------------------------------------------------------
      
      [1] Create new ccnet/seafile/seahub databases
      [2] Use existing ccnet/seafile/seahub databases
      
      [ 1 or 2 ] 2
      

      As perguntas 6 a 9 estão relacionadas ao servidor de banco de dados MariaDB. Você precisa fornecer o nome de usuário e a senha do usuário MySQL que você criou no Passo 1, mas você pode pressionar ENTER para aceitar os valores padrão para host e port.

      
      What is the host of mysql server?
      
      [ default "localhost" ]
      
      What is the port of mysql server?
      
      [ default "3306" ]
      
      Which mysql user to use for seafile?
      
      [ mysql user for seafile ] sammy
      
      What is the password for mysql user "seafile"?
      
      [ password for seafile ] senha
      

      Após fornecer a senha, o script solicitará os nomes dos bancos de dados do Seafile. Use ccnet-db, seafile-db, e seahub-db para este tutorial. O script verificará se há uma conexão bem-sucedida aos bancos de dados antes de continuar exibindo um resumo da configuração inicial.

      Enter the existing database name for ccnet:
      [ ccnet database ] ccnet-db
      
      verifying user "sammy" access to database ccnet-db ...  done
      
      Enter the existing database name for seafile:
      [ seafile database ] seafile-db
      
      verifying user "sammy" access to database seafile-db ...  done
      
      Enter the existing database name for seahub:
      [ seahub database ] seahub-db
      
      verifying user "sammy For this tutorial you have" access to database seahub-db ...  done
      
      ---------------------------------
      This is your configuration
      ---------------------------------
      
          server name:            Seafile
          server ip/domain:       seu_domínio
      
          seafile data dir:       /home/sammy/seafile/seafile-data
          fileserver port:        8082
      
          database:               use existing
          ccnet database:         ccnet-db
          seafile database:       seafile-db
          seahub database:        seahub-db
          database user:          sammy
      
      --------------------------------
      Press ENTER to continue, or Ctrl-C to abort
      ---------------------------------
      

      Pressione ENTER para confirmar.

      Output

      Generating ccnet configuration ... done Successly create configuration dir /home/sammy/seafile/ccnet. Generating seafile configuration ... done Generating seahub configuration ... ---------------------------------------- Now creating seahub database tables ... ---------------------------------------- creating seafile-server-latest symbolic link ... done ----------------------------------------------------------------- Your seafile server configuration has been finished successfully. ----------------------------------------------------------------- run seafile server: ./seafile.sh { start | stop | restart } run seahub server: ./seahub.sh { start <port> | stop | restart <port> } ----------------------------------------------------------------- If you are behind a firewall, remember to allow input/output of these tcp ports: ----------------------------------------------------------------- port of seafile fileserver: 8082 port of seahub: 8000 When problems occur, Refer to https://github.com/haiwen/seafile/wiki for information.

      Você estará executando o Seafile atrás do Apache, o que você já permitiu através do firewall do servidor. Portanto, você não precisa se preocupar em abrir as portas 8082 e 8000 e pode ignorar essa parte da saída.

      Você concluiu a configuração inicial do servidor. No próximo passo, você configurará o servidor web Apache antes de iniciar os serviços do Seafile.

      Passo 4 — Configurando o Servidor Web Apache

      Nesta etapa, você configurará o servidor web Apache para encaminhar todas as solicitações ao Seafile. O uso do Apache dessa maneira permite que você use uma URL sem um número de porta, habilite conexões HTTPS com o Seafile e utilize a funcionalidade de armazenamento em cache fornecida pelo Apache para obter melhor desempenho.

      Para começar a encaminhar solicitações, você precisará habilitar o módulo proxy_http na configuração do Apache. Este módulo fornece recursos para fazer proxy de solicitações HTTP e HTTPS. O seguinte comando ativará o módulo:

      Nota: Os módulos Apache rewrite e ssl também são necessários para esta configuração. Você já ativou esses módulos como parte da configuração do Let’s Encrypt no segundo tutorial do Apache listado na seção de pré-requisitos.

      Em seguida, atualize a configuração do virtual host do seu_domínio para encaminhar solicitações ao servidor de arquivos Seafile e à interface web Seahub.

      Abra o arquivo de configuração em um editor de texto:

      • sudo nano /etc/apache2/sites-enabled/seu_domínio-le-ssl.conf

      As linhas de ServerAdmin até SSLCertificateKeyFile fazem parte da configuração inicial do Apache e do Let’s Encrypt que você definiu nos tutoriais de pré-requisito. Adicione o conteúdo destacado, iniciando em Alias e terminando com a diretiva ProxyPassReverse:

      /etc/apache2/sites-enabled/your_domain-le-ssl.conf

      
      <IfModule mod_ssl.c>
      <VirtualHost *:443>
          ServerAdmin admin@seu_domínio_de_email
          ServerName seu_domínio
          ServerAlias www.seu_domínio
          DocumentRoot /var/www/seu_domínio/html
          ErrorLog ${APACHE_LOG_DIR}/seu_domínio-error.log
          CustomLog ${APACHE_LOG_DIR}/seu_domínio-access.log combined
      
          Include /etc/letsencrypt/options-ssl-apache.conf
          SSLCertificateFile /etc/letsencrypt/live/seu_domínio/fullchain.pem
          SSLCertificateKeyFile /etc/letsencrypt/live/seu_domínio/privkey.pem
      
          Alias /media  /home/sammy/seafile/seafile-server-latest/seahub/media
          <Location /media>
              Require all granted
          </Location>
      
          # seafile fileserver
          ProxyPass /seafhttp http://127.0.0.1:8082
          ProxyPassReverse /seafhttp http://127.0.0.1:8082
          RewriteEngine On
          RewriteRule ^/seafhttp - [QSA,L]
      
          # seahub web interface
          SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
          ProxyPass / http://127.0.0.1:8000/
          ProxyPassReverse / http://127.0.0.1:8000/
      </VirtualHost>
      </IfModule>
      

      A diretiva Alias mapeia o caminho da URL seu_domínio/media para um caminho local no sistema de arquivos que o Seafile utiliza. A diretiva seguinte, Location, habilita o acesso ao conteúdo deste diretório. As diretivas ProxyPass e ProxyPassReverse fazem o Apache agir como um proxy reverso para este host, encaminhando solicitações para / e /seafhttp para a interface web e para o servidor de arquivos Seafile em execução nas portas do host local 8000 e 8082 respectivamente. A diretiva RewriteRule passa todas as solicitações para /seafhttp inalteradas e interrompe o processamento de novas regras ([QSA,L]).

      Salve e saia do arquivo.

      Teste se há algum erro de sintaxe na configuração do virtual host:

      • sudo apache2ctl configtest

      Se ele informar Syntax OK, então não há problemas com sua configuração. Reinicie o Apache para que as alterações entrem em vigor:

      • sudo systemctl restart apache2

      Agora você configurou o Apache para atuar como um proxy reverso para o servidor de arquivos Seafile e o Seahub. Em seguida, você atualizará as URLs na configuração do Seafile antes de iniciar os serviços.

      Passo 5 — Atualizando a Configuração do Seafile e Iniciando os Serviços

      Agora que você está usando o Apache para fazer proxy de todas as solicitações para o Seafile, será necessário atualizar as URLs nos arquivos de configuração do Seafile no diretório conf usando um editor de texto antes de iniciar o serviço Seafile.

      Abra ccnet.conf em um editor de texto:

      • nano /home/sammy/seafile/conf/ccnet.conf

      Perto do topo do arquivo, dentro do bloco [General], está a diretiva SERVICE_URL. Ela parecerá assim:

      Update /home/sammy/seafile/conf/ccnet.conf

      . . .
      SERVICE_URL=http://www.example.com:8000
      . . .
      

      Modifique essa configuração para apontar para o seu domínio. Verifique se a URL fornecida usa o protocolo HTTPS e se não inclui nenhum número de porta:

      Update /home/sammy/seafile/conf/ccnet.conf

      . . .
      SERVICE_URL = https://seu_domínio
      . . .
      

      Salve e saia do arquivo depois de adicionar o conteúdo.

      Agora abra seahub_settings.py em um editor de texto:

      • nano /home/sammy/seafile/conf/seahub_settings.py

      Adicione uma configuração FILE_SERVER_ROOT no arquivo para especificar o caminho onde o servidor de arquivos está atendendo a uploads e downloads de arquivos:

      Update /home/sammy/seafile/conf/seahub_settings.py

      # -*- coding: utf-8 -*-
      SECRET_KEY = "..."
      FILE_SERVER_ROOT = 'https://seu_domínio/seafhttp'
      # ...
      

      Salve e saia do arquivo seahub_settings.py.

      Agora você pode iniciar o serviço Seafile e a interface Seahub:

      • cd /home/sammy/seafile/seafile-server-7.0.4
      • ./seafile.sh start
      • ./seahub.sh start

      Como esta é a primeira vez que você inicia o serviço Seahub, ele solicita que você crie uma conta de administrador. Digite um endereço de email válido e uma senha para este usuário administrador:

      Output

      What is the email for the admin account? [ admin email ] admin@seu_domínio_de_email What is the password for the admin account? [ admin password ] senha Enter the password again: [ admin password again ] senha ---------------------------------------- Successfully created seafile admin ---------------------------------------- Seahub is started Done.

      Abra https://seu_domínio em um navegador web e faça login usando seu endereço de e-mail e a senha de administrador do Seafile.

      Login screen of the Seafile web interface

      Uma vez logado com sucesso, você pode acessar a interface de administração ou criar novos usuários.

      Agora que você verificou que a interface web está funcionando corretamente, você pode ativar esses serviços para iniciar automaticamente na inicialização do sistema no próximo passo.

      Passo 6 — Habilitando o Servidor Seafile para Iniciar na Inicialização do Sistema

      Para permitir que o servidor de arquivos e a interface web iniciem automaticamente na inicialização, você pode criar seus respectivos arquivos de serviço systemd e ativá-los.

      Crie um arquivo de serviço systemd para o servidor de arquivos Seafile:

      • sudo nano /etc/systemd/system/seafile.service

      Adicione o seguinte conteúdo ao arquivo:

      Create /etc/systemd/system/seafile.service

      [Unit]
      Description=Seafile
      After=network.target mysql.service
      
      [Service]
      Type=forking
      ExecStart=/home/sammy/seafile/seafile-server-latest/seafile.sh start
      ExecStop=/home/sammy/seafile/seafile-server-latest/seafile.sh stop
      User=sammy
      Group=sammy
      
      [Install]
      WantedBy=multi-user.target
      

      Aqui, as linhas ExecStart e ExecStop indicam os comandos que são executados para iniciar e parar o serviço Seafile. O serviço será executado com sammy como User e Group. A linha After especifica que o serviço Seafile será iniciado após o início da rede e do serviço MariaDB.

      Salve o seafile.service e saia.

      Crie um arquivo de serviço systemd para a interface web do Seahub:

      • sudo nano /etc/systemd/system/seahub.service

      Isso é semelhante ao serviço Seafile. A única diferença é que a interface web é iniciada após o serviço Seafile. Adicione o seguinte conteúdo a este arquivo:

      Create /etc/systemd/system/seahub.service

      [Unit]
      Description=Seafile hub
      After=network.target seafile.service
      
      [Service]
      Type=forking
      ExecStart=/home/sammy/seafile/seafile-server-latest/seahub.sh start
      ExecStop=/home/sammy/seafile/seafile-server-latest/seahub.sh stop
      User=sammy
      Group=sammy
      
      [Install]
      WantedBy=multi-user.target
      

      Salve o seahub.service e saia.

      Você pode aprender mais sobre arquivos de unidade do systemd no tutorial Understanding Systemd Units and Unit Files.

      Por fim, para permitir que os serviços Seafile e Seahub sejam iniciados automaticamente na inicialização, execute os seguintes comandos:

      • sudo systemctl enable seafile.service
      • sudo systemctl enable seahub.service

      Quando o servidor é reiniciado, o Seafile irá iniciar automaticamente.

      Neste ponto, você concluiu a configuração do servidor e agora pode testar cada um dos serviços.

      Passo 7 — Testando as Funcionalidades de Sincronização e Compartilhamento de Arquivos

      Neste passo, você testará a funcionalidade de sincronização e compartilhamento de arquivos do servidor que você configurou e garantirá que elas estejam funcionando corretamente. Para fazer isso, você precisará instalar o programa cliente do Seafile em um computador separado e/ou em um dispositivo móvel.

      Visite a página de download no site da Seafile e siga as instruções para instalar a versão mais recente do programa cliente no seu computador. Os clientes do Seafile estão disponíveis para as várias distribuições do Linux (Ubuntu, Debian, Fedora, Centos/RHEL, Arch Linux), MacOS e Windows. Clientes móveis estão disponíveis para dispositivos Android e iPhone/iPad nas respectivas lojas de aplicativos.

      Depois de instalar o cliente Seafile, você pode testar a funcionalidade de sincronização e compartilhamento de arquivos.

      Abra o programa cliente do Seafile no seu computador ou dispositivo. Aceite o local padrão para a pasta Seafile e clique em Next.

      Na próxima janela, digite o endereço do servidor, nome de usuário e senha e clique em Login.

      Na página inicial, clique com o botão direito do mouse em My Library e clique em Sync this library. Aceite o valor padrão para o local no seu computador ou dispositivo.

      Seafile client — Sync the default library

      Adicione um arquivo, por exemplo, um documento ou uma foto, na pasta My Library. Depois de algum tempo, o arquivo será carregado no servidor. A captura de tela a seguir mostra o arquivo photo.jpg copiado para a pasta My Library.

      Add a file to the default library from the computer

      Agora, efetue login na interface web em https://seu_domínio e verifique se seu arquivo está presente no servidor.

      My Library page to verify file sync

      Clique em Share ao lado do arquivo para gerar um link de download para esse arquivo que você pode compartilhar.

      Você verificou que a sincronização de arquivos está funcionando corretamente e que você pode usar o Seafile para sincronizar e compartilhar arquivos e pastas de vários dispositivos.

      Conclusão

      Neste tutorial, você configurou uma instância privada de um servidor Seafile. Agora você pode começar a usar o servidor para sincronizar arquivos, adicionar usuários e grupos e compartilhar arquivos entre eles ou com o público sem depender de um serviço externo.

      Quando uma nova versão do servidor estiver disponível, consulte a seção upgrade do manual para verificar os passos para executar uma atualização.



      Source link

      Como Testar Seu Deployment Ansible com InSpec e Kitchen


      O autor escolheu a Diversity in Tech Fund para receber uma doação como parte do programa Write for DOnations.

      Introdução

      O InSpec é um framework open-source de auditoria e teste automatizado usado para descrever e testar preocupações, recomendações ou requisitos regulatórios. Ele foi projetado para ser inteligível e independente de plataforma. Os desenvolvedores podem trabalhar com o InSpec localmente ou usando SSH, WinRM ou Docker para executar testes, portanto, é desnecessário instalar quaisquer pacotes na infraestrutura que está sendo testada.

      Embora com o InSpec você possa executar testes diretamente em seus servidores, existe um potencial de erro humano que poderia causar problemas em sua infraestrutura. Para evitar esse cenário, os desenvolvedores podem usar o Kitchen para criar uma máquina virtual e instalar um sistema operacional de sua escolha nas máquinas em que os testes estão sendo executados. O Kitchen é um executor de testes, ou ferramenta de automação de teste, que permite testar o código de infraestrutura em uma ou mais plataformas isoladas. Ele também suporta muitos frameworks de teste e é flexível com uma arquitetura de plug-in de driver para várias plataformas, como Vagrant, AWS, DigitalOcean, Docker, LXC containers, etc.

      Neste tutorial, você escreverá testes para seus playbooks Ansible em execução em um Droplet Ubuntu 18.04 da DigitalOcean. Você usará o Kitchen como executor de teste e o InSpec para escrever os testes. No final deste tutorial, você poderá testar o deploy do seu playbook Ansible.

      Pré-requisitos

      Antes de começar com este guia, você precisará de uma conta na DigitalOcean além do seguinte:

      Passo 1 — Configurando e Inicializando o Kitchen

      Você instalou o ChefDK como parte dos pré-requisitos que vem empacotados com o kitchen. Neste passo, você configurará o Kitchen para se comunicar com a DigitalOcean.

      Antes de inicializar o Kitchen, você criará e se moverá para um diretório de projeto. Neste tutorial, o chamaremos de ansible_testing_dir.

      Execute o seguinte comando para criar o diretório:

      • mkdir ~/ansible_testing_dir

      E então passe para ele:

      Usando o gem instale o pacote kitchen-digitalocean em sua máquina local. Isso permite que você diga ao kitchen para usar o driver da DigitalOcean ao executar testes:

      • gem install kitchen-digitalocean

      No diretório do projeto, você executará o comando kitchen init especificando ansible_playbook como o provisionador e digitalocean como o driver ao inicializar o Kitchen:

      • kitchen init --provisioner=ansible_playbook --driver=digitalocean

      Você verá a seguinte saída:

      Output

      create kitchen.yml create chefignore create test/integration/default

      Isso criou o seguinte no diretório do projeto:

      • test/integration/default é o diretório no qual você salvará seus arquivos de teste.

      • chefignore é o arquivo que você usaria para garantir que certos arquivos não sejam carregados para o Chef Infra Server, mas você não o usará neste tutorial.

      • kitchen.yml é o arquivo que descreve sua configuração de teste: o que você deseja testar e as plataformas de destino.

      Agora, você precisa exportar suas credenciais da DigitalOcean como variáveis de ambiente para ter acesso para criar Droplets a partir da sua CLI. Primeiro, inicie com seu token de acesso da DigitalOcean executando o seguinte comando:

      • export DIGITALOCEAN_ACCESS_TOKEN="SEU_TOKEN_DE_ACESSO_DIGITALOCEAN"

      Você também precisa obter seu número de ID da chave SSH; note que SEU_ID_DE_CHAVE_SSH_DIGITALOCEAN deve ser o ID numérico da sua chave SSH, não o nome simbólico. Usando a API da DigitalOcean, você pode obter o ID numérico de suas chaves com o seguinte comando:

      • curl -X GET https://api.digitalocean.com/v2/account/keys -H "Authorization: Bearer $DIGITALOCEAN_ACCESS_TOKEN"

      Após este comando, você verá uma lista de suas chaves SSH e metadados relacionados. Leia a saída para encontrar a chave correta e identificar o número de ID nela:

      Output

      ... {"id":seu-ID-numérico,"fingerprint":"fingerprint","public_key":"ssh-rsa sua-chave-ssh","name":"nome-da-sua-chave-ssh" ...

      Nota: Se você deseja tornar sua saída mais legível para obter seus IDs numéricos, você pode encontrar e baixar o jq com base no seu sistema operacional na página de download do jq. Agora, você pode executar o comando anterior fazendo um pipe para o jq da seguinte maneira:

      • curl -X GET https://api.digitalocean.com/v2/account/keys -H "Authorization: Bearer $DIGITALOCEAN_ACCESS_TOKEN" | jq

      Você verá as informações da chave SSH formatadas de forma semelhante a:

      Output

      { "ssh_keys": [ { "id": ID_DA_SUA_CHAVE_SSH, "fingerprint": "2f:d0:16:6b", "public_key": "ssh-rsa AAAAB3NzaC1yc2 [email protected]", "name": "sannikay" } ], }

      Depois de identificar seus IDs numéricos de SSH, exporte-os com o seguinte comando:

      • export DIGITALOCEAN_SSH_KEY_IDS="SEU_ID_DE_CHAVE_SSH_DIGITALOCEAN"

      Você inicializou o kitchen e configurou as variáveis de ambiente para suas credenciais da DigitalOcean. Agora você vai criar e executar testes em seus Droplets diretamente da linha de comando.

      Passo 2 — Criando o Playbook Ansible

      Neste passo, você criará um playbook e roles (funções) que configurará o Nginx e o Node.js no Droplet criado pelo kitchen no próximo passo. Seus testes serão executados no playbook para garantir que as condições especificadas no playbook sejam atendidas.

      Para começar, crie um diretório roles para as roles ou funções Nginx e Node.js:

      • mkdir -p roles/{nginx,nodejs}/tasks

      Isso criará uma estrutura de diretórios da seguinte maneira:

      roles
      ├── nginx
      │   └── tasks
      └── nodejs
          └── tasks
      

      Agora, crie um arquivo main.yml no diretório roles/nginx/tasks usando o seu editor preferido:

      • nano roles/nginx/tasks/main.yml

      Neste arquivo, crie uma tarefa ou task que configura e inicia o Nginx adicionando o seguinte conteúdo:

      roles/nginx/tasks/main.yml

      ---
      - name: Update cache repositories and install Nginx
        apt:
          name: nginx
          update_cache: yes
      
      - name: Change nginx directory permission
        file:
          path: /etc/nginx/nginx.conf
          mode: 0750
      
      - name: start nginx
        service:
          name: nginx
          state: started
      

      Depois de adicionar o conteúdo, salve e saia do arquivo.

      Em roles/nginx/tasks/main.yml você define uma tarefa que atualizará o repositório de cache do seu Droplet, o que equivale a executar o comando apt update manualmente em um servidor. Essa tarefa também altera as permissões do arquivo de configuração do Nginx e inicia o serviço Nginx.

      Você também criará um arquivo main.yml em roles/nodejs/tasks para definir uma tarefa que configure o Node.js.

      • nano roles/nodejs/tasks/main.yml

      Adicione as seguintes tarefas a este arquivo:

      roles/nodejs/tasks/main.yml

      ---
      - name: Update caches repository
        apt:
          update_cache: yes
      
      - name: Add gpg key for NodeJS LTS
        apt_key:
          url: "https://deb.nodesource.com/gpgkey/nodesource.gpg.key"
          state: present
      
      - name: Add the NodeJS LTS repo
        apt_repository:
          repo: "deb https://deb.nodesource.com/node_{{ NODEJS_VERSION }}.x {{ ansible_distribution_release }} main"
          state: present
          update_cache: yes
      
      - name: Install Node.js
        apt:
          name: nodejs
          state: present
      
      

      Salve e saia do arquivo quando terminar.

      Em roles/nodejs/tasks/main.yml, você primeiro define uma tarefa que atualizará o repositório de cache do seu Droplet. Em seguida, na próxima tarefa, você adiciona a chave GPG para o Node.js, que serve como um meio de verificar a autenticidade do repositório apt do Node.js. As duas tarefas finais adicionam o repositório apt do Node.js e o instalam.

      Agora você definirá suas configurações do Ansible, como variáveis, a ordem em que você deseja que suas roles sejam executadas e configurações de privilégios de superusuário. Para fazer isso, você criará um arquivo chamado playbook.yml, que serve como um entry point para o Kitchen. Quando você executa seus testes, o Kitchen inicia no seu arquivo playbook.yml e procura as roles a serem executadas, que são seus arquivos roles/nginx/tasks/main.yml e roles/nodejs/tasks/main.yml.

      Execute o seguinte comando para criar o playbook.yml:

      Adicione o seguinte conteúdo ao arquivo:

      ansible_testing_dir/playbook.yml

      ---
       - hosts: all
         become: true
         remote_user: ubuntu
         vars:
          NODEJS_VERSION: 8
      

      Salve e saia do arquivo.

      Você criou as roles do playbook do Ansible com as quais executará seus testes para garantir que as condições especificadas no playbook sejam atendidas.

      Passo 3 — Escrevendo Seus Testes InSpec

      Neste passo, você escreverá testes para verificar se o Node.js está instalado no seu Droplet. Antes de escrever seu teste, vejamos o formato de um exemplo de teste InSpec. Como em muitos frameworks de teste, o código InSpec se assemelha a uma linguagem natural. O InSpec possui dois componentes principais, o assunto a ser examinado e o estado esperado desse assunto:

      block A

      describe '<entity>' do
        it { <expectation> }
      end
      

      Em block A, as palavras-chave do e end definem um bloco ou block. A palavra-chave describe é comumente conhecida como conjuntos ou suites de testes, que contêm casos de teste. A palavra-chave it é usada para definir os casos de teste.

      <entity> é o assunto que você deseja examinar, por exemplo, um nome de pacote, serviço, arquivo ou porta de rede. O <expectation> especifica o resultado desejado ou o estado esperado, por exemplo, o Nginx deve ser instalado ou deve ter uma versão específica. Você pode verificar a documentação da InSpec DSL para aprender mais sobre a linguagem InSpec.

      Outro exemplo de bloco de teste InSpec:

      block B

      control 'Pode ser qualquer coisa única' do  
        impact 0.7                         
        title 'Um título inteligível'     
        desc  'Uma descrição opcional'
        describe '<entity>' do             
          it { <expectation> }
        end
      end
      

      A diferença entre o bloco A e o bloco B é o bloco control. O bloco control é usado como um meio de controle regulatório, recomendação ou requisito. O bloco control tem um nome; geralmente um ID único, metadados como desc, title, impact e, finalmente, agrupam blocos describe relacionados para implementar as verificações.

      desc, title, e impact definem metadados que descrevem completamente a importância do controle, seu objetivo, com uma descrição sucinta e completa. impact define um valor numérico que varia de 0.0 a 1.0 onde 0.0 a <0.01 é classificado como sem impacto, 0.01 a <0.4 é classificado como baixo impacto, 0.4 a <0.7 é classificado como médio impacto, 0,7 a <0,9 é classificado como alto impacto, 0,9 a 1,0 é classificado como controle crítico.

      Agora, vamos implementar um teste. Usando a sintaxe do bloco A, você usará o recurso package do InSpec para testar se o Node.js está instalado no sistema. Você irá criar um arquivo chamado sample.rb em seu diretório test/integration/default para seus testes.

      Crie o sample.rb:

      • nano test/integration/default/sample.rb

      Adicione o seguinte ao seu arquivo:

      test/integration/default/sample.rb

      describe package('nodejs') do
        it { should be_installed }
      end
      

      Aqui seu teste está usando o recurso package para verificar se o node.js está instalado.

      Salve e saia do arquivo quando terminar.

      Para executar este teste, você precisa editar kitchen.yml para especificar o playbook que você criou anteriormente e para adicionar às suas configurações.

      Abra seu arquivo kitchen.yml:

      • nano ansible_testing_dir/kitchen.yml

      Substitua o conteúdo de kitchen.yml com o seguinte:

      ansible_testing_dir/kitchen.yml

      ---
      driver:
        name: digitalocean
      
      provisioner:
        name: ansible_playbook
        hosts: test-kitchen
        playbook: ./playbook.yml
      
      verifier:
        name: inspec
      
      platforms:
        - name: ubuntu-18
          driver_config:
            ssh_key: CAMINHO_PARA_SUA_CHAVE_PRIVADA_SSH
            tags:
              - inspec-testing
            region: fra1
            size: 1gb
            private_networking: false
          verifier:
            inspec_tests:
              - test/integration/default
      suites:
        - name: default
      
      

      As opções de platform incluem o seguinte:

      • name: A imagem que você está usando.
      • driver_config: A configuração do seu Droplet da DigitalOcean. Você está especificando as seguintes opções para driver_config:

        • ssh_key: Caminho para SUA_CHAVE_SSH_PRIVADA. Sua SUA_CHAVE_SSH_PRIVADA está localizada no diretório que você especificou ao criar sua chave ssh.
        • tags: As tags associadas ao seu Droplet.
        • region: A region ou região onde você deseja que seu Droplet seja hospedado.
        • size: A memória que você deseja que seu Droplet tenha.
      • verifier: Isso define que o projeto contém testes InSpec.

        • A parte do inspec_tests especifica que os testes existem no diretório test/integration/default do projeto.

      Observe que name e region usam abreviações. Você pode verificar na documentação do test-kitchen as abreviações que você pode usar.

      Depois de adicionar sua configuração, salve e saia do arquivo.

      Execute o comando kitchen test para executar o teste. Isso verificará se o Node.js está instalado — ele falhará propositalmente, porque você atualmente não possui a role Node.js no seu arquivo playbook.yml:

      Você verá uma saída semelhante à seguinte:

      Output: failing test results

      -----> Starting Kitchen (v1.24.0) -----> Cleaning up any prior instances of <default-ubuntu-18> -----> Destroying <default-ubuntu-18>... DigitalOcean instance <145268853> destroyed. Finished destroying <default-ubuntu-18> (0m2.63s). -----> Testing <default-ubuntu-18> -----> Creating <default-ubuntu-18>... DigitalOcean instance <145273424> created. Waiting for SSH service on 138.68.97.146:22, retrying in 3 seconds [SSH] Established (ssh ready) Finished creating <default-ubuntu-18> (0m51.74s). -----> Converging <default-ubuntu-18>... $$$$$$ Running legacy converge for 'Digitalocean' Driver -----> Installing Chef Omnibus to install busser to run tests PLAY [all] ********************************************************************* TASK [Gathering Facts] ********************************************************* ok: [localhost] PLAY RECAP ********************************************************************* localhost : ok=1 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 Downloading files from <default-ubuntu-18> Finished converging <default-ubuntu-18> (0m55.05s). -----> Setting up <default-ubuntu-18>... $$$$$$ Running legacy setup for 'Digitalocean' Driver Finished setting up <default-ubuntu-18> (0m0.00s). -----> Verifying <default-ubuntu-18>... Loaded tests from {:path=>". ansible_testing_dir.test.integration.default"} Profile: tests from {:path=>"ansible_testing_dir/test/integration/default"} (tests from {:path=>"ansible_testing_dir.test.integration.default"}) Version: (not specified) Target: ssh://[email protected]:22 System Package nodejs × should be installed expected that System Package nodejs is installed Test Summary: 0 successful, 1 failure, 0 skipped >>>>>> ------Exception------- >>>>>> Class: Kitchen::ActionFailed >>>>>> Message: 1 actions failed. >>>>>> Verify failed on instance <default-ubuntu-18>. Please see .kitchen/logs/default-ubuntu-18.log for more details >>>>>> ---------------------- >>>>>> Please see .kitchen/logs/kitchen.log for more details >>>>>> Also try running `kitchen diagnose --all` for configuration 4.54s user 1.77s system 5% cpu 2:02.33 total

      A saída informa que seu teste está falhando porque você não possui o Node.js instalado no Droplet que você provisionou com o kitchen. Você corrigirá seu teste adicionando a role nodejs ao seu arquivo playbook.yml e executará o teste novamente.

      Edite o arquivo playbook.yml para incluir a role nodejs:

      Adicione as seguintes linhas destacadas ao seu arquivo:

      ansible_testing_dir/playbook.yml

      ---
       - hosts: all
         become: true
         remote_user: ubuntu
         vars:
          NODEJS_VERSION: 8
      
         roles:
          - nodejs
      

      Salve e feche o arquivo.

      Agora, você executará novamente o teste usando o comando kitchen test:

      Você verá a seguinte saída:

      Output

      ...... Target: ssh://[email protected]:22 System Package nodejs ✔ should be installed Test Summary: 1 successful, 0 failures, 0 skipped Finished verifying <default-ubuntu-18> (0m4.89s). -----> Destroying <default-ubuntu-18>... DigitalOcean instance <145512952> destroyed. Finished destroying <default-ubuntu-18> (0m2.23s). Finished testing <default-ubuntu-18> (2m49.78s). -----> Kitchen is finished. (2m55.14s) 4.86s user 1.77s system 3% cpu 2:56.58 total

      Seu teste agora passa porque você tem o Node.js instalado usando a role nodejs.

      Aqui está um resumo do que o Kitchen está fazendo em Test Action:

      • Destrói o Droplet se ele existir
      • Cria o Droplet
      • Converge o Droplet
      • Verifica o Droplet com o InSpec
      • Destrói o Droplet

      O Kitchen interromperá a execução em seu Droplet se encontrar algum problema. Isso significa que, se o seu playbook do Ansible falhar, o InSpec não será executado e o seu Droplet não será destruído. Isso permite que você inspecione o estado da instância e corrija quaisquer problemas. O comportamento da ação final de destruição pode ser substituído, se desejado. Verifique a ajuda da CLI para a flag --destroy executando o comando kitchen help test.

      Você escreveu seus primeiros testes e os executou no seu playbook com uma instância falhando antes de corrigir o problema. Em seguida, você estenderá seu arquivo de teste.

      Passo 4 — Adicionando Casos de Teste

      Neste passo, você adicionará mais casos de teste ao seu arquivo de teste para verificar se os módulos do Nginx estão instalados no seu Droplet e se o arquivo de configuração tem as permissões corretas.

      Edite seu arquivo sample.rb para adicionar mais casos de teste:

      • nano test/integration/default/sample.rb

      Adicione os seguintes casos de teste ao final do arquivo:

      test/integration/default/sample.rb

      . . .
      control 'nginx-modules' do
        impact 1.0
        title 'NGINX modules'
        desc 'The required NGINX modules should be installed.'
        describe nginx do
          its('modules') { should include 'http_ssl' }
          its('modules') { should include 'stream_ssl' }
          its('modules') { should include 'mail_ssl' }
        end
      end
      
      control 'nginx-conf' do
        impact 1.0
        title 'NGINX configuration'
        desc 'The NGINX config file should owned by root, be writable only by owner, and not writeable or and readable by others.'
        describe file('/etc/nginx/nginx.conf') do
          it { should be_owned_by 'root' }
          it { should be_grouped_into 'root' }
          it { should_not be_readable.by('others') }
          it { should_not be_writable.by('others') }
          it { should_not be_executable.by('others') }
        end
      end
      

      Esses casos de teste verificam se os módulos nginx-modules no seu Droplet incluem http_ssl, stream_ssl e mail_ssl. Você também está verificando as permissões do arquivo /etc/nginx/nginx.conf.

      Você está usando as palavras-chave it e its para definir seu teste. A palavra-chave its é usada apenas para acessar propriedades de resources. Por exemplo, modules é uma propriedade de nginx.

      Salve e saia do arquivo depois de adicionar os casos de teste.

      Agora execute o comando kitchen test para testar novamente:

      Você verá a seguinte saída:

      Output

      ... Target: ssh://[email protected]:22 ↺ nginx-modules: NGINX modules ↺ The `nginx` binary not found in the path provided. × nginx-conf: NGINX configuration (2 failed) × File /etc/nginx/nginx.conf should be owned by "root" expected `File /etc/nginx/nginx.conf.owned_by?("root")` to return true, got false × File /etc/nginx/nginx.conf should be grouped into "root" expected `File /etc/nginx/nginx.conf.grouped_into?("root")` to return true, got false ✔ File /etc/nginx/nginx.conf should not be readable by others ✔ File /etc/nginx/nginx.conf should not be writable by others ✔ File /etc/nginx/nginx.conf should not be executable by others System Package nodejs ✔ should be installed Profile Summary: 0 successful controls, 1 control failure, 1 control skipped Test Summary: 4 successful, 2 failures, 1 skipped

      Você verá que alguns dos testes estão falhando. Você irá corrigi-los adicionando a role nginx ao seu arquivo playbook e executando novamente o teste. No teste que falhou, você está verificando módulos nginx e permissões de arquivo que não estão presentes atualmente no seu servidor.

      Abra seu arquivo playbook.yml:

      • nano ansible_testing_dir/playbook.yml

      Adicione a seguinte linha destacada às suas roles:

      ansible_testing_dir/playbook.yml

      ---
      - hosts: all
        become: true
        remote_user: ubuntu
        vars:
        NODEJS_VERSION: 8
      
        roles:
        - nodejs
        - nginx
      

      Salve e feche o arquivo quando terminar.

      Em seguida, execute seus testes novamente:

      Você verá a seguinte saída:

      Output

      ... Target: ssh://[email protected]:22 ✔ nginx-modules: NGINX version ✔ Nginx Environment modules should include "http_ssl" ✔ Nginx Environment modules should include "stream_ssl" ✔ Nginx Environment modules should include "mail_ssl" ✔ nginx-conf: NGINX configuration ✔ File /etc/nginx/nginx.conf should be owned by "root" ✔ File /etc/nginx/nginx.conf should be grouped into "root" ✔ File /etc/nginx/nginx.conf should not be readable by others ✔ File /etc/nginx/nginx.conf should not be writable by others ✔ File /etc/nginx/nginx.conf should not be executable by others System Package nodejs ✔ should be installed Profile Summary: 2 successful controls, 0 control failures, 0 controls skipped Test Summary: 9 successful, 0 failures, 0 skipped

      Depois de adicionar a role nginx ao playbook, todos os seus testes agora passam. A saída mostra que os módulos http_ssl, stream_ssl e mail_ssl estão instalados em seu Droplet e as permissões corretas estão definidas para o arquivo de configuração.

      Quando terminar, ou não precisar mais do seu Droplet, você poderá destruí-lo executando o comando kitchen destroy para excluí-lo após executar seus testes:

      Após este comando, você verá uma saída semelhante a:

      Output

      -----> Starting Kitchen (v1.24.0) -----> Destroying <default-ubuntu-18>... Finished destroying <default-ubuntu-18> (0m0.00s). -----> Kitchen is finished. (0m5.07s) 3.79s user 1.50s system 82% cpu 6.432 total

      Você escreveu testes para o seu playbook, executou os testes e corrigiu os testes com falha para garantir que todos os testes sejam aprovados. Agora você está pronto para criar um ambiente virtual, escrever testes para o seu Playbook Ansible e executar seu teste no ambiente virtual usando o Kitchen.

      Conclusão

      Agora você tem uma base flexível para testar seu deployment Ansible, que lhe permite testar seus playbooks antes de executar em um servidor ativo. Você também pode empacotar seu teste em um perfil. Você pode usar perfis para compartilhar seu teste através do Github ou do Chef Supermarket e executá-lo facilmente em um servidor ativo.

      Para detalhes mais abrangentes sobre o InSpec e o Kitchen, consulte a documentação oficial do InSpec e a documentação oficial do Kitchen.



      Source link

      How To Install and Use Radamsa to Fuzz Test Programs and Network Services on Ubuntu 18.04


      The author selected the Electronic Frontier Foundation Inc to receive a donation as part of the Write for DOnations program.

      Introduction

      Security threats are continually becoming more sophisticated, so developers and systems administrators need to take a proactive approach in defending and testing the security of their applications.

      A common method for testing the security of client applications or network services is fuzzing, which involves repeatedly sending invalid or malformed data to the application and analyzing its response. This is useful to help test how resilient and robust the application is to unexpected input, which may include corrupted data or actual attacks.

      Radamsa is an open-source fuzzing tool that can generate test cases based on user-specified input data. Radamsa is fully scriptable, and so far has been successful in finding vulnerabilities in real-world applications, such as Gzip.

      In this tutorial, you will install and use Radamsa to fuzz test command-line and network-based applications using your own test cases.

      Warning: Radamsa is a penetration testing tool which may allow you to identify vulnerabilities or weaknesses in certain systems or applications. You must not use vulnerabilities found with Radamsa for any form of reckless behavior, harm, or malicious exploitation. Vulnerabilities should be ethically reported to the maintainer of the affected application, and not disclosed publicly without explicit permission.

      Prerequisites

      Before you begin this guide you’ll need the following:

      • One Ubuntu 18.04 server set up by following the Initial Server Setup with Ubuntu 18.04, including a sudo non-root user and enabled firewall to block non-essential ports.
      • A command-line or network-based application that you wish to test, for example Gzip, Tcpdump, Bind, Apache, jq, or any other application of your choice. As an example for the purposes of this tutorial, we’ll use jq.

      Warning: Radamsa can cause applications or systems to run unstably or crash, so only run Radamsa in an environment where you are prepared for this, such as a dedicated server. Please also ensure that you have explicit written permission from the owner of a system before conducting fuzz testing against it.

      Once you have these ready, log in to your server as your non-root user to begin.

      Step 1 — Installing Radamsa

      Firstly, you will download and compile Radamsa in order to begin using it on your system. The Radamsa source code is available in the official repository on GitLab.

      Begin by updating the local package index to reflect any new upstream changes:

      Then, install the gcc, git, make, and wget packages needed to compile the source code into an executable binary:

      • sudo apt install gcc git make wget

      After confirming the installation, apt will download and install the specified packages and all of their required dependencies.

      Next, you’ll download a copy of the source code for Radamsa by cloning it from the repository hosted on GitLab:

      • git clone https://gitlab.com/akihe/radamsa.git

      This will create a directory called radamsa, containing the source code for the application. Move into the directory to begin compiling the code:

      Next, you can start the compilation process using make:

      Finally, you can install the compiled Radamsa binary to your $PATH:

      Once this is complete, you can check the installed version to make sure that everything is working:

      Your output will look similar to the following:

      Output

      Radamsa 0.6

      If you see a radamsa: command not found error, double-check that all required dependencies were installed and that there were no errors during compilation.

      Now that you’ve installed Radamsa, you can begin to generate some sample test cases to understand how Radamsa works and what it can be used for.

      Step 2 — Generating Fuzzing Test Cases

      Now that Radamsa has been installed, you can use it to generate some fuzzing test cases.

      A test case is a piece of data that will be used as input to the program that you are testing. For example, if you are fuzz testing an archiving program such as Gzip, a test case may be a file archive that you are attempting to decompress.

      Note: Radamsa will manipulate input data in a wide variety of unexpected ways, including extreme repetition, bit flips, control character injection, and so on. This may cause your terminal session to break or become unstable, so be aware of this before proceeding.

      Firstly, pass a simple piece of text to Radamsa to see what happens:

      • echo "Hello, world!" | radamsa

      This will manipulate (or fuzz) the inputted data and output a test case, for example:

      Output

      Hello,, world!

      In this case, Radamsa added an extra comma between Hello and world. This may not seem like a significant change, but in some applications this may cause the data to be interpreted incorrectly.

      Let’s try again by running the same command. You’ll see different output:

      Output

      Hello, '''''''wor'd!

      This time, multiple single quotes (') were inserted into the string, including one that overwrote the l in world. This particular test case is more likely to result in problems for an application, as single/double quotes are often used to separate different pieces of data in a list.

      Let’s try one more time:

      Output

      Hello, $+$PATHu0000`xcalc`world!

      In this case, Radamsa inserted a shell injection string, which will be useful to test for command injection vulnerabilities in the application that you are testing.

      You’ve used Radamsa to fuzz an input string and produce a series of test cases. Next, you will use Radamsa to fuzz a command-line application.

      Step 3 — Fuzzing a Command-line Application

      In this step, you’ll use Radamsa to fuzz a command-line application and report on any crashes that occur.

      The exact technique for fuzzing each program varies massively, and different methods will be most effective for different programs. However, in this tutorial we will use the example of jq, which is a command-line program for processing JSON data.

      You may use any other similar program as long as it follows the general principle of taking some form of structured or unstructured data, doing something with it, and then outputting a result. For instance this example would also work with Gzip, Grep, bc, tr, and so on.

      If you don’t already have jq installed, you can install it using apt:

      jq will now be installed.

      To begin fuzzing, create a sample JSON file that you’ll use as the input to Radamsa:

      Then, add the following sample JSON data to the file:

      test.json

      {
        "test": "test",
        "array": [
          "item1: foo",
          "item2: bar"
        ]
      }
      

      You can parse this file using jq if you wish to check that the JSON syntax is valid:

      If the JSON is valid, jq will output the file. Otherwise, it will display an error, which you can use to correct the syntax where required.

      Next, fuzz the test JSON file using Radamsa and then pass it to jq. This will cause jq to read the fuzzed/manipulated test case, rather than the original valid JSON data:

      If Radamsa fuzzes the JSON data in a way that it is still syntactically valid, jq will output the data, but with whatever changes Radamsa made to it.

      Alternatively, if Radamsa causes the JSON data to become invalid, jq will display a relevant error. For example:

      Output

      parse error: Expected separator between values at line 5, column 16

      The alternate outcome would be that jq is unable to correctly handle the fuzzed data, causing it to crash or misbehave. This is what you’re really looking for with fuzzing, as this may be indicative of a security vulnerability such as a buffer overflow or command injection.

      In order to more efficiently test for vulnerabilities like this, a Bash script can be used to automate the fuzzing process, including generating test cases, passing them to the target program and capturing any relevant output.

      Create a file named jq-fuzz.sh:

      The exact script content will vary depending on the type of program that you’re fuzzing and the input data, but in the case of jq and other similar programs, the following script suffices.

      Copy the script into your jq-fuzz.sh file:

      jq-fuzz.sh

      #!/bin/bash
      while true; do
        radamsa test.json > input.txt
        jq . input.txt > /dev/null 2>&1
        if [ $? -gt 127 ]; then
          cp input.txt crash-`date +s%.%N`.txt
          echo "Crash found!"
        fi
      done
      

      This script contains a while to make the contents loop repeatedly. Each time the script loops, Radamsa will generate a test case based on test.json and save it to input.txt.

      The input.txt test case will then be run through jq, with all standard and error output redirected to /dev/null to avoid filling up the terminal screen.

      Finally, the exit value of jq is checked. If the exit value is greater than 127, this is indicative of a fatal termination (a crash), then the input data is saved for review at a later date in a file named crash- followed by the current date in Unix seconds and nanoseconds.

      Mark the script as executable and set it running in order to begin automatically fuzz testing jq:

      • chmod +x jq-fuzz.sh
      • ./jq-fuzz.sh

      You can issue CTRL+C at any time to terminate the script. You can then check whether any crashes have been found by using ls to display a directory listing containing any crash files that have been created.

      You may wish to improve your JSON input data since using a more complex input file is likely to improve the quality of your fuzzing results. Avoid using a large file or one that contains a lot of repeated data—an ideal input file is one that is small in size, yet still contains as many ‘complex’ elements as possible. For example, a good input file will contain samples of data stored in all formats, including strings, integers, booleans, lists, and objects, as well as nested data where possible.

      You’ve used Radamsa to fuzz a command-line application. Next, you’ll use Radamsa to fuzz requests to network services.

      Step 4 — Fuzzing Requests to Network Services

      Radamsa can also be used to fuzz network services, either acting as a network client or server. In this step, you’ll use Radamsa to fuzz a network service, with Radamsa acting as the client.

      The purpose of fuzzing network services is to test how resilient a particular network service is to clients sending it malformed and/or malicious data. Many network services such as web servers or DNS servers are usually exposed to the internet, meaning that they are a common target for attackers. A network service that is not sufficiently resistant to receiving malformed data may crash, or even worse fail in an open state, allowing attackers to read sensitive data such as encryption keys or user data.

      The specific technique for fuzzing network services varies enormously depending on the network service in question, however in this example we will use Radamsa to fuzz a basic web server serving static HTML content.

      Firstly, you need to set up the web server to use for testing. You can do this using the built-in development server that comes with the php-cli package. You’ll also need curl in order to test your web server.

      If you don’t have php-cli and/or curl installed, you can install them using apt:

      • sudo apt install php-cli curl

      Next, create a directory to store your web server files in and move into it:

      Then, create a HTML file containing some sample text:

      Add the following to the file:

      index.html

      <h1>Hello, world!</h1>
      

      You can now run your PHP web server. You’ll need to be able to view the web server log while still using another terminal session, so open another terminal session and SSH to your server for this:

      • cd ~/www
      • php -S localhost:8080

      This will output something similar to the following:

      Output

      PHP 7.2.24-0ubuntu0.18.04.1 Development Server started at Wed Jan 1 16:06:41 2020 Listening on http://localhost:8080 Document root is /home/user/www Press Ctrl-C to quit.

      You can now switch back to your original terminal session and test that the web server is working using curl:

      This will output the sample index.html file that you created earlier:

      Output

      <h1>Hello, world!</h1>

      Your web server only needs to be accessible locally, so you should not open any ports on your firewall for it.

      Now that you’ve set up your test web server, you can begin to fuzz test it using Radamsa.

      First, you’ll need to create a sample HTTP request to use as the input data for Radamsa. Create a new file to store this in:

      Then, copy the following sample HTTP request into the file:

      http-request.txt

      GET / HTTP/1.1
      Host: localhost:8080
      User-Agent: test
      Accept: */*
      

      Next, you can use Radamsa to submit this HTTP request to your local web server. In order to do this, you’ll need to use Radamsa as a TCP client, which can be done by specifying an IP address and port to connect to:

      • radamsa -o 127.0.0.1:8080 http-request.txt

      Note: Be aware that using Radamsa as a TCP client will potentially cause malformed/malicious data to be transmitted over the network. This may break things, so be very careful to only access networks that you are authorized to test, or preferably, stick to using the localhost (127.0.0.1) address.

      Finally, if you view the outputted logs for your local web server, you’ll see that it has received the requests, but most likely not processed them as they were invalid/malformed.

      The outputted logs will be visible in your second terminal window:

      Output

      [Wed Jan 1 16:26:49 2020] 127.0.0.1:49334 Invalid request (Unexpected EOF) [Wed Jan 1 16:28:04 2020] 127.0.0.1:49336 Invalid request (Malformed HTTP request) [Wed Jan 1 16:28:05 2020] 127.0.0.1:49338 Invalid request (Malformed HTTP request) [Wed Jan 1 16:28:07 2020] 127.0.0.1:49340 Invalid request (Unexpected EOF) [Wed Jan 1 16:28:08 2020] 127.0.0.1:49342 Invalid request (Malformed HTTP request)

      For optimal results and to ensure that crashes are recorded, you may wish to write an automation script similar to the one used in Step 3. You should also consider using a more complex input file, which may contain additions such as extra HTTP headers.

      You’ve fuzzed a network service using Radamsa acting as a TCP client. Next, you will fuzz a network client with Radamsa acting as a server.

      Step 5 — Fuzzing Network Client Applications

      In this step, you will use Radamsa to fuzz test a network client application. This is achieved by intercepting responses from a network service and fuzzing them before they are received by the client.

      The purpose of this kind of fuzzing is to test how resilient network client applications are to receiving malformed or malicious data from network services. For example, testing a web browser (client) receiving malformed HTML from a web server (network service), or testing a DNS client receiving malformed DNS responses from a DNS server.

      As was the case with fuzzing command-line applications or network services, the exact technique for fuzzing each network client application varies considerably, however in this example you will use whois, which is a simple TCP-based send/receive application.

      The whois application is used to make requests to WHOIS servers and receive WHOIS records as responses. WHOIS operates over TCP port 43 in clear text, making it a good candidate for network-based fuzz testing.

      If you don’t already have whois available, you can install it using apt:

      First, you’ll need to acquire a sample whois response to use as your input data. You can do this by making a whois request and saving the output to a file. You can use any domain you wish here as you’re testing the whois program locally using sample data:

      • whois example.com > whois.txt

      Next, you’ll need to set up Radamsa as a server that serves fuzzed versions of this whois response. You’ll need to be able to continue using your terminal once Radamsa is running in server mode, so it is recommended to open another terminal session and SSH connection to your server for this:

      • radamsa -o :4343 whois.txt -n inf

      Radamsa will now be running in TCP server mode, and will serve a fuzzed version of whois.txt each time a connection is made to the server, no matter what request data is received.

      You can now proceed to testing the whois client application. You’ll need to make a normal whois request for any domain of your choice (it doesn’t have to be the same one that the sample data is for), but with whois pointed to your local Radamsa server:

      • whois -h localhost:4343 example.com

      The response will be your sample data, but fuzzed by Radamsa. You can continue to make requests to the local server as long as Radamsa is running, and it will serve a different fuzzed response each time.

      As with fuzzing network services, to improve the efficiency of this network client fuzz testing and ensure that any crashes are captured, you may wish to write an automation script similar to the one used in Step 3.

      In this final step, you used Radamsa to conduct fuzz testing of a network client application.

      Conclusion

      In this article you set up Radamsa and used it to fuzz a command-line application, a network service, and a network client. You now have the foundational knowledge required to fuzz test your own applications, hopefully with the result of improving their robustness and resistance to attack.

      If you wish to explore Radamsa further, you may wish to review the Radamsa README file in detail, as it contains further technical information and examples of how the tool can be used:

      You may also wish to check out some other fuzzing tools such as American Fuzzy Lop (AFL), which is an advanced fuzzing tool designed for testing binary applications at extremely high speed and accuracy:



      Source link