Skip to content

linux

Primeiros passos com Docker

thumbnail2253

Olá!

Estou começando a dar os primeiros passos com o Docker e quero compartilhar os links que já estudei até aqui e que servem de bússola para quem quer começar a usá-lo também. Esta página será atualizada à medida que eu encontrar mais documentos relevantes.

O que é Docker? Por que usá-lo? Instalando o Docker:

Docker versus VmWare:

Documentos sobre Docker:

Slides:

Comunidade/Fórum Docker:

Livros:

Meus repositórios Docker:

Orquestração com Docker:

Cluster Ativo/Passivo com PostgreSQL 9.3, Red Hat 6, pcs, Pacemaker, Corosync e DRBD

Introdução

Para a execução deste tutorial foram criadas duas máquinas virtuais com as configurações abaixo.
  • Processador: 1 vCPU com clock acima de 2.0 GHz.
  • Memória: 1 GB.
  • HD1: 50 GB (com duas partições: / de 42 GB e swap de 8 GB).
  • HD2: 20 GB (mas este não foi configurado durante a instalação do S.O).
  • 2 placas de rede.
  • S.O: Red Hat 6.8 64 bits com idioma em Inglês-US (UTF-8).

Cada VM possui duas placas de rede, mas apenas uma das placas de rede de cada VM foi configurada com IP fixo (também pode ser usado IPs distribuídos pelo serviço DHCP, desde que os IPs sejam associados ao MAC de uma placa de rede de cada VM).

As VMs são identificadas da seguinte forma:
  • db1.domain.com.br: 10.0.0.1/24 na interface eth0
  • db2.domain.com.br: 10.0.0.2/24 na interface eth0

Estas informações foram adicionadas no arquivo /etc/hosts de cada máquina. Veja o ambiente do cluster na figura abaixo.

cluster_db2

 

 

Após a instalação do S.O, é necessário que ele esteja registrado para poder acessar os repositórios oficiais da Red Hat. Veja nesta página como registrar o sistema: https://access.redhat.com/documentation/en-US/Red_Hat_Network_Satellite/5.3/html/Reference_Guide/ch-register.html

Também foi configurado a autenticação via par de chaves RSA para o usuário root de cada máquina acessar a outra via SSH sem senha. Aqui está o tutorial: https://goo.gl/NdLkD4

Instalação dos pacotes

Aviso: Os passos abaixo devem ser executados nas duas máquinas.

1- Crie o arquivo /etc/yum.repos.d/centos.repo e adicione o seguinte conteúdo.

[centos-6-base]
name=CentOS-$releasever
Base mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os
baseurl=http://mirror.globo.com/centos/6.8/os/x86_64/
enabled=1

2- Execute os comandos abaixo para adicionar repositórios extras e autenticá-los.
rpm -Uvh http://www.elrepo.org/elrepo-release-6-6.el6.elrepo.noarch.rpm
rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
rpm --import http://mirror.globo.com/centos/6.8/os/x86_64/RPM-GPG-KEY-CentOS-6
rpm -ivh https://download.postgresql.org/pub/repos/yum/9.3/redhat/rhel-6-x86_64/pgdg-redhat93-9.3-2.noarch.rpm

3- Execute o comando abaixo para instalar os pacotes que usaremos ao longo do tutorial.

yum -y install pacemaker cman pcs ccs resource-agents ntsysv kmod-drbd84 drbd84-utils postgresql93-contrib postgresql93 postgresql93-server

Cada nó terá os seguintes componentes de software, a fim de trabalhar como membro do o cluster HA (High-availability).

Pacemaker => É um gestor de recursos do cluster, que executa scripts no momento em que os nós do cluster são inicializados ou desligados ou quando os recursos relacionados falham. Além disso, pode ser configurado para verificar periodicamente o estado de cada nó do cluster. Em outras palavras, o pacemaker será encarregado de dar a partida e parada dos serviços (como um servidor web ou de banco de dados, para citar um exemplo clássico) e irá implementar a lógica para garantir que todos os serviços necessários estão rodando em apenas um local, ao mesmo tempo a fim de evitar a corrupção de dados.

Corosync: Trata-se de um serviço de mensagens que irá fornecer um canal de comunicação entre os nós do cluster. Ele é essencial e funciona como um marca-passo que checa a disponibilidade de cada nó.

PCS: É uma ferramenta de configuração do corosync e pacemaker que permite a visualização, edição e criação de clusters. Ele é opcional, mas é bom instalá-lo para ajudar na configuração do Cluster.

Desabilitando o Selinux e Iptables

Como este tutorial tem objetivo apenas de criar um ambiente de teste, desabilite o SELinux e o Iptables para não interferir na comunicação dos nodes do cluster e na configuração dos serviços.

Instruções para desabilitar o SELinux:https://goo.gl/4McGVw
Instruções para parar o Iptables:http://goo.gl/uE3PP9

Configurando os dois nós do cluster para sincronizar a configuração

OBS.: Durante a execução dos comandos, deve ser utilizado o usuário root ou outro que possa executado o comando sudo.

Em cada máquina virtual foram executados os comandos abaixo, para iniciar o serviço pcsd e definir uma senha para o usuário hacluster, que será usado futuramente para sincronizar a configuração do cluster nas duas VMs. A senha do usuário hacluster deve ser a mesma em cada máquina.
service pcsd start
passwd hacluster

Adicionando os nós do cluster


Na VM db1, foram executados os comandos abaixo para adicionar os nós do cluster.
pcs cluster auth db1 db2
pcs cluster setup --name cluster-db db1 db2
pcs cluster start --all

OBS.: Durante a execução dos comandos será solicitado o login e senha do usuário hacluster

Os comandos abaixo configuram algumas das propriedades principais do cluster.

pcs property set stonith-enabled=false
pcs property set no-quorum-policy=ignore
pcs resource defaults migration-threshold=1
Em máquinas virtuais não dá para usar o STONITH (Shoot    The    Other    Node    In The    Head), que um dispositivo responsável por  evitar que dois nós ou membros de um cluster atuem como nó primário em um cluster do tipo HA. Isso ajuda a evitar a corrupção de dados. Este dispositivo “chuta” o nó slave para ser o prímario, quando há uma falha no nó master atual. Por isso no primeiro comando acima, ele foi desabilitado. O Fence é um processo de isolamento, ou a separação, de um nó do cluster ao usar os recursos ou iniciar serviços. Ele ajuda a evitar que um nó com defeito execute os recursos de cluster. Em alguns casos, se um nó do cluster parar de responder, o mesmo deve ser colocado como offline antes de outro nó assumir a execução dos recursos. O fence também é um mecanismo do STONITH.

 

O segundo comando acima evita que os recursos sejam iniciados em mais nós do que o desejado. É usado quando você tem um cluster com vários pares de nós (veja http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Clusters_from_Scratch/_perform_a_failover.html). Neste tutorial, a política de quorum foi desabilitada.

 

Já o terceiro comando acima, indica quantas falhas o cluster irá esperar que aconteça em um nó para mover os recursos para o próximo nó online.

 

Os comandos abaixo devem ser executados nas duas VMs para verificar o status do corosync e demais serviços do cluster.
corosync-cfgtool -s 
corosync-cpgtool
pcs status
Inicie os serviços dos cluster das duas máquinas.
service pcsd start
service corosync start
service cman start
service pacemaker start

Configure os serviços para serem inicializados no boot do S.O das duas máquinas

chkconfig pcsd on
chkconfig cman on
chkconfig pacemaker on
chkconfig corosync on

Visualizando a configuração do cluster

Quando quiser visualizar a configuração do cluster, use o comando abaixo.

pcs config

Comando para remoção da configuração do cluster

Se precisa remover a configuração do cluster, use os comandos abaixo nas duas VMs.

pcs cluster stop --force
pcs cluster destroy

Adicionando o IP do cluster como um recurso

Na VM db1 foi executado o comando abaixo para configurar o IP do cluster.

pcs resource create ClusterIP ocf:heartbeat:IPaddr2 ip=192.168.0.1 cidr_netmask=24 nic=eth1 op monitor interval=10s
Com o comando acima será atribuído o IP 192.168.0.1/24 na interface de rede eth1 (das duas máquinas) e o recurso ClusterIP será monitorado a cada 10s.
Este IP será automaticamente configurado apenas em uma das máquinas por vez. Por padrão, apenas a máquina MASTER conterá o IP definido acima na segunda placa de rede (identificada no Red Hat 6 como eth1). Se o db1 ficar indisponível, este IP será configurado na máquina db2. Quando o master voltar ao normal, o IP continuará no db2 e só será migrado para o db1 em caso de problema no db2.
 

Execute o comando abaixo para visualizar a configuração.

ifconfig

Testando a migração do IP do cluster para a máquina db2. Na máquina db1 execute:

pcs cluster stop db1 --force

Na máquina db2, execute o comando abaixo para visualizar a configuração.

ifconfig

Na máquina db1, inicie o cluster.

pcs cluster start db1

Novamente execute o comando abaixo para visualizar a configuração.

ifconfig

Adicionando uma rota de saída do cluster como um recurso

Na VM db1 foi executado o comando abaixo para configurar a rota do cluster. É por essa rota que o cluster irá se comunicar com os hosts das demais redes.

pcs resource create DefRoute ocf:heartbeat:Route destination=default device=eth1 gateway=192.168.0.1 op monitor interval=10s

Adicionando um grupo de recursos

Para evitar que os recursos ClusterIP e DefRoute sejam iniciados em máquinas diferentes do cluster, podemos criar um grupo de recursos e incluí-los de forma que os dois sejam iniciados na mesma máquina. Para fazer isto, use os comandos abaixo:

pcs resource group add ClusterGrupoRecursos ClusterIP DefRoute
pcs resource manage ClusterIP DefRoute

Listando, atualizando e removendo um recurso

Se precisar listar os recursos ativos do cluster, use o comando abaixo.

pcs resource show
Se precisar atualizar um recurso. Use a opção update do comando pcs resource. Exemplo, o comando abaixo altera o IP do cluster.
 
pcs resource update ClusterIP ocf:heartbeat:IPaddr2 ip=192.168.0.75 cidr_netmask=24 nic=eth1 op monitor interval=10s

Se precisar remover um recurso do cluster, use o comando abaixo.

pcs resource delete NOMERECURSO
pcs resource cleanup NOMERECURSO

Se precisar ver a inicialização de um recurso no modo debug (depuração), use o comando abaixo:

pcs resource debug-start NOMERECURSO --full

Fonte: http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html-single/Pacemaker_Explained/#ap-lsb

Se precisar consultar a lista de agentes do heartbeat, pacemaker ou LSB para configurar um recurso do cluster, use os comandos abaixo.

pcs resource agents ocf:heartbeat
pcs resource agents ocf:pacemaker
pcs resource agents lsb:

Configurando o DRBD nas duas máquinas

Os pacotes do DRBD já foram instalados no início do tutorial.

As duas VMs já possuem um segundo disco de 20 GB e que não foi usado durante a instalação. Esses discos serão usados pelo serviço DRBD para sincronizar os dados. O DRBD atuará como um cluster Ativo > Passivo. Os dados serão gravados apenas na máquina ativa do cluster. Na máquina passiva os dados serão sincronizados e o disco ficará apenas no modo leitura. O disco a ser usado pelo DRBD será montado no sistema como /database com o sistema de arquivos ext4 e será usado pelo PostgreSQL para armazenar os arquivos dos bancos de dados.

Em cada máquina, crie o arquivo /etc/drbd.d/disk_database.res com o conteúdo abaixo para configurar um recurso no DRBD que usará o disco disponível identificado no S.O como /dev/sdb1.

resource disk_database {
 protocol C;
 meta-disk internal;
 device /dev/drbd1;
 syncer {
   verify-alg sha1;
 }
 net {
   allow-two-primaries;
 }
 on db1 {
   disk   /dev/sdb;
   address  10.0.0.1:7789;
 }
 on db2 {
   disk   /dev/sdb;
   address  10.0.0.2:7789;
 }
}

O disco /dev/drdb1, configurado acima, é o disco DRBD que abstraí o uso do disco /dev/sdb1 de cada máquina.

Em cada máquina, ative o uso do recurso com os comandos abaixo.

drbdadm create-md disk_database
modprobe drbd
drbdadm up disk_database

Na máquina db1, force-a para ser o nó primário do DRBD.

drbdadm primary --force disk_database
Visualize a sincronização dos discos com o comandos abaixo.
 
 cat /proc/drbd
 A sincronização demorará alguns minutos.

Quando terminar a sincronização dos discos, execute o comando abaixo na máquina db1 para formatá-lo com o sistema de arquivos ext4.

mkfs.ext4 /dev/drbd1
Na máquina db1, teste o uso do disco /dev/drbd1.
 
mkdir /database
mount /dev/drbd1 /database
ls /database
mkdir /database/teste
touch /database/teste/a.txt

Configurando o DRBD para ser gerenciado pelo cluster

Na máquina db1, execute os comandos abaixo para configurar o recurso DRBD disk_database (configurado no arquivo /etc/drbd.d/disk_database.res) para ser gerenciado pelo Cluster.

pcs cluster cib drbd_cfg
pcs -f drbd_cfg resource create DBData ocf:linbit:drbd \
 drbd_resource=disk_database op monitor interval=60s
pcs -f drbd_cfg resource master DBDataClone DBData \
 master-max=1 master-node-max=1 clone-max=2 clone-node-max=1 notify=true

Execute o comando abaixo para visualizar a configuração do recurso.

pcs -f drbd_cfg resource show

Execute o comando abaixo para salvar e habilitar a configuração do recurso.

pcs cluster cib-push drbd_cfg

Execute o comando abaixo para visualizar a configuração do cluster

pcs status

Habilite nas duas máquinas, o carregamento do módulo drbd no boot do S.O.

echo drbd > /etc/modprobe.d/drbd.conf

Configurando o Postgresql

O PostgreSQL já foi instalado no início do tutorial. Configure-o para usar o disco /dev/drbd1 montado na máquina db1 no diretório /database.
mkdir -p /database/pgsql
chown -R postgres:postgres /database/
chmod -R 0700 /database/
sudo -u postgres /usr/pgsql-9.3/bin/initdb -D /database/pgsql
Edite o script de inicialização do PostgreSQL, localizado em /etc/init.d/postgresql-9.3. No script mude apenas as variáveis citadas para conter os valores abaixo. Antes de editar o script, faça um backup do mesmo.
 
PGPORT=5433
PGDATA=/database/pgsql/
PGLOG=/database/pgsql/pgstartup.log
PGUPLOG=/database/pgsql/pgupgrade.log
Salve as alterações e copie-o para a máquina db2.
scp /etc/init.d/postgresql-9.3 root@db2:/etc/init.d/postgresql-9.3

Configurando recurso Postgresql no cluster

Na máquina db1, execute o comando abaixo para criar o recurso Postgresql que irá inicializar o serviço na máquina ativa do cluster, usando o script /etc/init.d/postgresql-9.3 (representado no comando abaixo por lsb:postgresql-9.3). É importante lembrar que ele não deve ser inicializado junto com o boot do sistema operacional. Apenas o cluster deve inicializá-lo.

pcs resource create Postgresql lsb:postgresql-9.3

Configurando a ordem de inicialização dos recursos no cluster

Configure o cluster para só inicializar o Postgresql depois de configurar o IP, a rota e montar o disco /dev/drbd1 em /database (usando o sistema de arquivos ext4) na máquina ativa. Execute os comandos abaixo apenas na máquina db1, pois a configuração será replicada para o db2.

pcs cluster cib fs_cfg
pcs -f fs_cfg resource create DBFS Filesystem \
 device="/dev/drbd1" directory="/database" fstype="ext4"
pcs -f fs_cfg constraint colocation add DBFS with DBDataClone INFINITY with-rsc-role=Master
pcs -f fs_cfg constraint order promote DBDataClone then start DBFS
pcs -f fs_cfg constraint colocation add ClusterIP with DefRoute INFINITY
pcs -f fs_cfg constraint order ClusterIP then DefRoute
pcs -f fs_cfg constraint colocation add DefRoute with DBFS INFINITY
pcs -f fs_cfg constraint order DefRoute then DBFS
pcs -f fs_cfg constraint colocation add Postgresql with DBFS INFINITY
pcs -f fs_cfg constraint order DBFS then Postgresql

Execute os comandos abaixo para revisar a configuração.

pcs -f fs_cfg constraint
pcs -f fs_cfg resource show

Execute o comando abaixo para salvar e habilitar a configuração do recurso.

pcs cluster cib-push fs_cfg

Execute o comando abaixo para visualizar a configuração do cluster

pcs status
 
Pronto! Agora é só realizar testes de funcionamento com o cluster.
 
OBS.: Para verificar o funcionamento do PostgreSQL, use o comando abaixo.
 
/etc/init.d/postgresql-9.3 status

Comandos úteis à gerência de configuração do cluster

Comandos para visualizar a configuração do cluster CIB (Cluster Information Base):
pcs cluster cib --config
pcs cluster cib
Comando para backup da configuração do cluster:
pcs config backup cluster_config_$(date +%Y-%m-%d)

Restaurando a configuração do cluster a partir do backup:1) Você precisa parar o serviço de cluster no nó, restaurar a configuração e iniciá-lo depois:

pcs cluster stop node --force
pcs config restore --local  cluster_config_$(date +%Y-%m-%d).tar.bz2
pcs cluster start node
Estes comandos restauram a configuração apenas no nó atual.
Para restaurar a configuração em todos os nós, use os comados abaixo.
pcs cluster stop node --force
pcs config restore cluster_config_$(date +%Y-%m-%d).tar.bz2
pcs cluster start node
Obtendo o relatório do cluster para análise de incidentes:
pcs cluster report [--from "YYYY-M-D  H:M:S"  [--to  "YYYY-M-D"  H:M:S"]]"  dest
Você também pode voltar a configuração do cluster para um determinado ponto. Para ver os pontos de configuração execute o comando:
pcs config checkpoint
Para visualizar a configuração de determinado ponto, use o comando abaixo:
pcs config  checkpoint view    <checkpoint_number>
Para voltar a usar a configuração de determinado ponto, use o comando:
pcs  config  checkpoint    restore    <checkpoint_number>
Para saber mais detalhes das sintaxes dos comandos e aprender mais sobre o assunto, recomendo a leitura das fontes e livros indicados no tutorial.

Fontes:

Sites:

http://blog.clusterlabs.org/blog/2010/pacemaker-heartbeat-corosync-wtf/

http://www.unixmen.com/configure-drbd-centos-6-5/

http://clusterlabs.org/quickstart-redhat-6.html

http://elrepo.org/tiki/tiki-index.php

http://drbd.linbit.com/en/doc/users-guide-84

http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/pdf/Clusters_from_Scratch/Pacemaker-1.1-Clusters_from_Scratch-en-US.pdf

CRMSH vs PCS: https://github.com/ClusterLabs/pacemaker/blob/master/doc/pcs-crmsh-quick-ref.md

http://www.picoloto.com.br/tag/mkfs-ext4

https://www.vivaolinux.com.br/artigo/Cluster-de-alta-disponibilidade-para-servidores-web-com-Debian-71-Corosync-Pacemaker-DRBD?pagina=1

http://asilva.eti.br/instalar-cluster-high-availbility-no-centos-7-com-pacemaker/

http://clusterlabs.org/quickstart-redhat.html

http://clusterlabs.org/wiki/Install

http://keithtenzer.com/2015/06/22/pacemaker-the-open-source-high-availability-cluster/

http://bigthinkingapplied.com/creating-a-linux-cluster-in-red-hatcentos-7/

https://bigthinkingapplied.com/tag/cluster/

http://www.tokiwinter.com/building-a-highly-available-apache-cluster-on-centos-7/

http://www.cloudera.com/documentation/enterprise/5-4-x/topics/admin_cm_ha_failover.html

http://jensd.be/156/linux/building-a-high-available-failover-cluster-with-pacemaker-corosync-pcs

Documentação Oficial sobre cluster no Red Hat 7:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/High_Availability_Add-On_Overview/index.html

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/High_Availability_Add-On_Administration/index.html

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Load_Balancer_Administration/index.html

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/High_Availability_Add-On_Reference/index.html

Documentação geral do Red Hat 7:

https://access.redhat.com/documentation/en/red-hat-enterprise-linux/7/

Instalando o NFS no Ubuntu 12.04

 

O NFS (Network File System) é um sistema de arquivos distribuídos desenvolvido inicialmente pela Sun Microsystems, Inc., a fim de compartilhar arquivos e diretórios entre computadores conectados em rede, formando assim um diretório virtual. Nesta página [1], você encontra mais informações sobre o funcionamento desse serviço de rede.

Este tutorial ensina a instalar e configurar o NFS  no Ubuntu 12.04.

No servidor

Instale o serviço com o seguinte comando:

sudo apt-get install nfs-kernel-server

Crie um diretório para armazenar os arquivos a serem compartilhados com os hosts clientes. Exemplo: /compartilhado.

sudo mkdir /compartilhado

Edite o arquivo /etc/exports para especificar as permissões do compartilhamento. Adicione seguinte linha:

/compartilhado *(rw,sync,no_subtree_check,no_root_squash)

Assim, o diretório será compartilhado com permissões de leitura e escrita e qualquer arquivo que for adicionado no diretório será rapidamente disponibilizado aos usuários do host cliente. Saiba mais sobre as permissões acessando esta página [2]

Edite o arquivo /etc/hosts.denny e adicione as seguintes linhas para negar o acesso remoto ao NFS a todos os hosts:

portmap: ALL
lockd: ALL
mountd: ALL
rquotad: ALL

Agora libere o acesso remoto ao NFS para hosts específicos.

Se você quer compartilhar o diretório “/compartilhado” com todos os hosts pertencentes a faixa de rede 192.168.0.0/24 (na qual também está o servidor NFS), edite o arquivo /etc/hosts.allow e informe as linhas abaixo. Se você quer compartilhar apenas com um ou dois computadores da rede, substitua 192.168.0.0/24 pelos endereços IP separando-os por vírgula. Ex.: portmap: 192.168.0.2, 192.168.0.3.

portmap: 192.168.0.0/24
lockd: 192.168.0.0/24
rquotad 192.168.0.0/24
mountd: 192.168.0.0/24
statd: 192.168.0.0/24

Execute o comando abaixo para ativar o serviço e habilitar as configurações.

sudo /etc/init.d/nfs-kernel-server restart

No cliente

Instale o cliente NFS.

sudo apt-get install nfs-common

Monte o diretório compartilhado pelo servidor NFS no host cliente.

Crie o diretório que receberá os arquivos compartilhados pelo servidor.

sudo mkdir /media/compartilhado

Edite o arquivo /etc/fstab e adicione a seguinte linha ao final. Isso fará com que a montagem do diretório remoto seja executada automaticamente quando o computador for ligado.

IP-Servidor:/compartilhado /media/compartilhado nfs rw 0 0

Na linha acima, substitua “IP-Servidor” pelo IP do servidor NFS. Exemplo: 192.168.0.1.

Agora monte manualmente o diretório remoto no host cliente.

sudo mount IP-Servidor:/compartilhado /media/compartilhado

Pronto! Agora é só testar. Adicione alguns arquivos no diretório “/compartilhado” do servidor e verá estes mesmos arquivos no diretório “/media/compartilhado” do host cliente.

Abraço e até a próxima.

Fontes:

[1] http://www.qfoi.com.br/index.php/artigos/51-instalando-nfs-no-ubuntu

[2] http://www.vivaolinux.com.br/artigo/Configurando-um-servidor-NFS-em-4-passos?pagina=1

Lançada a 21° edição da Revista Espírito Livre

Para fechar 2010 com chave de ouro, a Revista Espírito Livre traz na capa o tema Segurança da Informação, um assunto pelo qual me interesso muito.

Nesta edição você encontrará uma entrevista internacional com Andrew Lewman, criador do Projeto TOR, que tem como objetivo proteger usuários contra a análise de tráfego, possibilitando uma navegação anônima na Internet; duas entrevistas nacionais, uma com Aderbal Botelho, profissional da área de segurança e perícia forense e outra com Rafael S. Ferreira, que também trabalha com análise forense e ferramentas que facilitam análise de dados e recuperação de informação. Nesta edição, Albino Biasutti e Guilherme Chaves falam sobre segurança para leigos e Edgard Costa fala sobre segurança de documentos.

E não é só isso, tem muita novidade e vários artigos que falam sobre diversos assuntos e que você poderá encontrar nesta edição. Baixe a sua gratuitamente aqui.

Boa leitura e feliz ano novo. 🙂

Aumente a segurança do SSH com o SPA

Vou logo avisando que este é um post longo, mas vale à pena você dedicar alguns minutos para lê-lo e aprender como deixar o acesso ao SSH menos vulnerável a ataques usando o SPA.

SPA (Single Packet Autorization) é uma técnica baseada em Port Knocking que ajuda a aumentar a segurança do SSH.

Como funciona o SPA?

Antes de responder a esta pergunta, é preciso explicar como funciona o Port Knocking.

Port Knocking, segundo o site www.portknocking.org, é uma forma de comunicação entre dois hosts, em que o host cliente envia uma informação, que pode ser criptografada, é dividida e enviada em uma sequência de pacotes a uma porta que está fechada (protegida) num host destinatário. Embora a porta do host destinatário possa estar fechada ou protegida por um firewall, por exemplo, há um daemon que fica escutando os pacotes que chegam. Neste caso, se a sequência de pacotes enviada pelo host cliente estiver correta, a porta será aberta temporariamente e exclusivamente para ele. Vide figura 1.

Port KnockingFigura 1: Funcionamento do Port Knocking.

Uma analogia muito utilizada ao Port Knocking é: uma pessoa que bate na porta fechada de uma casa, usando uma sequência de batidas que é reconhecida pela pessoa que está escutando do lado de dentro atrás da porta. É daí que vem o nome Port Knocking (bater na porta). 🙂

Mas alguns especialistas em segurança da informação perceberam que o Port Knocking tem as seguintes falhas:

  • Se a sequência de pacotes chegar errada no host destino (devido a diferentes rotas que cada um pode tomar), nenhuma porta será aberta e não será possível acessar o serviço.
  • Os pacotes podem ser capturados por um invasor que está observando o tráfego da rede e tentar um ataque no host destino, se disfarçando por um cliente válido.
  • Port Knocking usa os campos de cabeçalho dos protocolos TCP e UDP para enviar “a senha” de acesso e não utiliza criptografia.

É para suprir estas falhas que o SPA foi criado. Ele usa criptografia e só precisa enviar apenas um pacote ao host destino para obter o acesso. E um dos softwares que implementa o SPA é o fwknop, criado por Michael Rash.

Meu amigo Leandro Almeida apresentou uma palestra sobre este tema no III ENSOL e os slides podem ser vistos a seguir. Eles são bem explicativos e objetivos. Qualquer dúvida poste um comentário para debatermos sobre o assunto.

Espero que tenha entendido toda esta teoria (se não entendeu, fale sua dúvida), porque agora vou ensinar a instalar  e configurar o fwknop no Ubuntu 10.04 LTS (neste tutorial estou assumindo que o SSH está instalado e escutando na porta 22).

OBS.: Nos testes que eu fiz, utilizei duas máquinas virtuais. Uma será o servidor SSH que contém o Ubuntu Server 10.04 com o IP 192.168.0.254 (onde está instalado o iptables e o OpenSSH-Server) e a outra é uma máquina com o IP 192.168.0.1 com o Ubuntu Desktop 10.0.4 que contém o cliente ssh.

Para instalar o fwknop no servidor, usei o seguinte comando.

# apt-get install fwknop-server

Durante a instalação, informei uma senha a ser usada pelo fwknop. Depois disso, eu executei o seguinte comando.

# iptables -A INPUT -d 192.168.0.254 -p tcp –dport 22 -j REJECT

Onde:

  • 192.168.0.254 é o IP do servidor que contém o OpenSSH-Server instalado.

O comando acima diz ao Iptables para negar qualquer tentativa externa de conexão ao SSH na porta 22. Ou seja, a porta 22 está fechada.

Depois disso, eu configurei o arquivo /etc/fwknop/access.conf as seguintes opções.

SOURCE: ANY; # Qualquer host pode tentar conectar
OPEN_PORTS: tcp/22; # Porta usada pelo SSH
KEY: testeteste; # Senha criada para o fwknop, ela deve ser divulgada com cuidado apenas com os usuários que terão acesso ao SSH.
FW_ACCESS_TIMEOUT: 30; # Tempo em segundos para abrir a sessão SSH após a autorização

O comando abaixo foi executado para carregar as configurações e iniciar o daemon do fwknop-server.

# /etc/init.d/fwknop-server restart

Ao executar o comando iptables –L foi possível ver que a chain FWKNOP_INPUT foi criada. É nela que podemos ver quais as conexões temporárias que serão autorizadas pelo fwknop.

No host client, que acessará o SSH, foi instalado o pacote fwknop-client com o seguinte comando.

# apt-get install fwknop-client

Agora, para eu acessar o ssh do servidor 192.168.0.254, é preciso digitar o comando abaixo.

# fwknop -A “tcp/22” -a 192.168.0.1 -D 192.168.0.254

Onde:

  • “tcp/22” => porta TCP do SSH.
  • 192.168.0.1 => IP do host cliente que vai acessar o SSH.
  • 192.168.0.254 => IP do servidor SSH.

O comando acima envia um pacote com a senha do fwknop requisitando uma autorização no host destinatário para acessar o SSH.Lembre-se que o Iptables continua rejeitando as conexões na porta 22. Mas se o daemon perceber que o pacote enviado pelo cliente é válido ele vai abrir uma excessão e permitirá que por 30 segundos (tempo configurado no arquivo /etc/fwknop/access.conf) apenas aquele host cliente possa abrir uma conexão na porta 22. Depois que a sessão SSH for encerrada, ele fecha a porta novamente.

Continuando, só depois que for executado o comando acima, é possível abrir uma sessão SSH com o comando abaixo.

# ssh aecio@192.168.0.254

Como digitar o comando de autorização do fwknop-client cada vez que for abrir uma sessão SSH é uma “mão-de-obra”, criei o script client_ssh.sh que simplemente pergunta o IP do servidor SSH e a porta em que o serviço está sendo executado e depois eu posso abrir uma sessão SSH.

Você pode baixar o script e usar também. Depois de baixá-lo use o comando abaixo para dar permissão de execução ao script.

# chmod +x cliente_ssh.sh

Todas as vezes que o usuário for conectar ao servidor SSH, ele deve executar o script acima para receber uma autorização do fwknop-server. Depois de executado o script cliente_ssh.sh, tem 30 segundos para iniciar a sessão SSH (tempo configurado no arquivo /etc/fwknop/access.conf) ou enviar um arquivo usando SCP. Caso contrário, o script deve ser executado novamente.

Para receber a autorizaçao do fwknop-server, a senha configurada no arquivo /etc/fwknop/access.conf tem que ser compartilhada com quem as pessoas que têm permissão para acessar o SSH.

Para finalizar, veja o vídeo feito por Leandro Almeida que demonstra o funcionamento do fwknop.

Finish! Então, o que achou?

Lançada a 15° edição da Revista Espírito Livre

E o tema principal desta edição é o CMS (Content Management Systems ou Sistemas de Gerenciamento de Conteúdo).

Abaixo reproduzo as palavras do editor da revista, João Fernando Costa Júnior, sobre este tema.

“Esse é um assunto que divide opiniões por diversos motivos. Talvez o mais evidente talvez seja que muitos desenvolvedores que gostam de construir seus projetos “na unha” consideram que o uso de um sistema de gerenciamento de conteúdo previamente construído é desnecessário ou que seu uso trás “efeitos colaterais”. Um destes efeitos seria a dependência da ferramenta com o passar do tempo, ou ainda o ato de se prender apenas ao templates (modelos de layout) já existentes. Não considerando apenas a questão do visual, os CMS exercem uma importante tarefa em praticamente qualquer sistema que dependa de atualizações constantes e dinamicidade. E quando o CMS tem seu código aberto, a experência de adaptá-lo a nossa necessidade se torna ainda mais gratificante.

Existem dezenas de CMS sendo utilizados por toda a Web, muitos deles mundialmente famosos e outros nem tanto. A edição deste mês conversou com diversos desenvolvedores, responsáveis por várias destas soluções. Além das entrevistas, casos de sucesso e outros relatos de uso de gerenciadores de conteúdo ilustram esse cenário dinâmico, onde os CMS se encontram.”

Tivemos como entrevistados, Tristan Renaud, vice-presidente do Jahia Software Group, responsável pelo CMS Jahia; Mark Evans, líder do projeto glFusion e batemos um papo com Dan Fuhry e Neal Gompa, criadores do EnanoCMS. Também recebemos contribuições de Rafael Silva, criador do site Drupal Brasil, que em sua matéria traz motivos bastante convincentes quanto ao uso do Drupal, inclusive apresentando casos bem sucedidos de uso deste famoso CMS. Yuri Almeida aponta para uma vertente bem interessante em sua contribuição, falando dos CMS e a produção colaborativa de conteúdo. Rafael Leal traz um questionamento pertinente no título de sua matéria: Usar CMS desvaloriza o meu trabalho? Tivemos ainda outras contribuições sobre o assunto de capa que merecem toda a nossa atenção.”

Mas a edição deste mês não aborda só este assunto, tem muita coisa boa que vale a pena você dedicar alguns minutos do seu dia para ler, refletir e aprender. Baixe gratuitamente a sua edição em http://ur1.ca/0ep80

Lançada a 14° edição da Revista Espírito Livre

Revista_EspiritoLivre_014_capa

Há poucas horas foi lançada a 14° edição da Revista Espírito Livre que traz como tema central as redes P2P e a polêmica do compartilhamento de conteúdos versus direitos autoriais que gira em torno delas.

Nesta edição eu colaborei revisando alguns artigos e um deles me chamou muito a atenção: “P2P: ferramenta de compartilhamento ou de pirataria?“, escrito por Walter Capanema. Neste artigo, Walter quebra um mito que algumas pessoas pensam sobre o fato de que a tecnologia tem sido algumas vezes usada para o mal, neste caso, sobre o fato de as redes P2P terem sido usadas na pirataria de conteúdos.

Mas a revista tem outros artigos muito interessantes que você não pode deixar de conferir. Baixe a sua aqui.

Por fim quero reproduzir um trecho do editorial escrito pelo editor João Fernando Costa Júnior:

“- A cada mês chegam mais e mais comentários nos incentivando a continuar, nos dando um feedback positivo em relação as matérias veiculadas nas edições, pedindo que por favor, diminuamos o número de páginas pois não está dando tempo de acompanhar tanta coisa. Considero este pedido em especial um elogio pois não é nada fácil manter uma publicação mensal, e se ela apresenta o leitor uma quantidade tão grande e rica de material que o mesmo não dá conta de acompanhar, sinal que estamos no caminho certo. Recomendamos porém que estes que não dão conta de ler tudo, que tenham calma, pois a edição não precisa ser devorada em um mês, recorra a ela sempre que necessário. Tivemos algumas baixas em nosso time, mas também ganhamos vários novos colaboradores. Nossa equipe vai se renovando e se fortalecendo a cada dia, prova de nosso amadurecimento e empenho diário em entregar aos leitores uma publicação de qualidade e gratuita.”

Consumo de memória pelo Ubuntu

Coff! coff! Fiquei tanto tempo sem publicar algo no blog, que ele ficou cheio de poeira rsrsrs

Vamos ao que importa. Estou usando o Ubuntu 9.04 e 9.10 e percebi que ele usa muita memória RAM para fazer cache dos programas que estão em execução.

Este recurso é importante, pois permite que eles sejam abertos mais rápido da segunda vez que o usuário pedir. Por outro lado, isso consome muita memória RAM e dependendo da necessidade isso não é legal.
Pesquisei sobre o assunto e descobri que, a partir do kernel 2.6.16, foi adicionado um recurso que permite limpar a cache de memória sem reiniciar o sistema operacional. Basta executar um dos comandos abaixo.

# sysctl -w vm.drop_caches=3

ou

# echo 3 > /proc/sys/vm/drop_caches

Testei e funciona mesmo. Esta é a saída do comando free -m antes de limpar a cache.

Esta é a saída do comando free -m depois de limpar a cache.

Se você usa outra distro GNU/Linux, teste a dica e poste um comentário dizendo se funcionou ou não.

Segue os links de referência:

http://www.vivaolinux.com.br/topico/Ubuntu-e-Kubuntu/Uso-de-memoria-no-Kubuntu-8.04.

http://www.vivaolinux.com.br/dica/Limpando-a-memoria-cache-no-Linux

http://www.linuxinsight.com/proc_sys_vm_drop_caches.html

http://codare.net/2006/12/04/limpar-caches-de-disco-e-de-filesystem-no-linux/