Blog ID Tecnologia da Informação

Instalação do debian 8 em fake RAID ("BIOS RAID")

2017-04-03T15:32:00.001-03:00

INTRODUÇÃO

Recentemente precisei realizar a instalação do Debian 8 (Jessie) em um arranjo RAID 1 configurado com fake RAID. Como encontrei pouco material para resolver os problemas que enfrentei, descrevo nesse tutorial (que considero mais como um informativo) o que precisei fazer para que tudo funcionasse de acordo com o esperado.

MAS ANTES: O QUE É FAKE RAID ("BIOS RAID")

Existe basicamente 3 formas de se criar arranjos RAID:

Via hardware dedicado: nesses casos todas as operações de acesso aos discos são realizadas via hardware dedicado para esse objetivo. É a forma recomendada devido ao desempenho e confiabilidade. Funciona independente do sistema operacional, pois para ele irá aparecer apenas um disco independente de como o RAID foi configurado.

Via software: nesses casos todas as configurações do RAID são realizadas no sistema operacional, ficando esse responsável também pelas operações. Como não necessita de um hardware específico para criação do RAID é muito vantajoso em questão valores.

Via fake RAID ("Bios RAID"): é a forma de RAID utilizada pela maioria das controladoras utilizadas em placas-mães planejadas para desktop. No fake RAID é realizada a configuração do RAID via software da controladora, no entanto, é necessário ainda um driver que roda pelo sistema operacional e é nesse ponto que chegamos ao objetivo desse tutorial.

INICIANDO A INSTALAÇÃO.

Após o RAID configurado no software da BIOS, na tela de inicial de boot do CD de instalação do debian, será necessário carregar o grub com a seguinte opção dmraid=true.

No menu de inicialização, selecione a opção de instalação desejada (não aperte Enter ainda), pressione Tab para editar a linha de inicialização do kernel e adicione "dmraid = true" sem aspas para o final da linha. Pressione Enter. Conforme figura abaixo:

Figura 1

Caso a opção não seja digita o disco não irá ser detectado e você provavelmente irá se dar conta disso na fase de particionamento do disco.

Aqui cabe uma observação importante: Se você criar apenas uma partição no disco provavelmente não terá mais nenhum problema desde que no final da instalação seja selecione o arranjo RAID para instalação do gerenciador de boot grub como na figura abaixo:

Figura 2

No meu caso como eu precisava de 3 partições distintas no disco, foi quando meus problemas começaram. Após o primeiro boot, verifiquei que a primeira partição criada no disco / montava sem problemas, mas a /var e /home, que estavam configurados em outras 2 partições separadas, não eram montados. Me retornando um erro semelhante ao da figura 3 abaixo:

Figura 3

COMO CORRIGIR ("O PULO DO GATO"):

Se o seu boot parou na mesma tela da figura 3, siga a dica abaixo, no entanto, se após o boot a tela é semelhante a da figura 4, siga a dica no final do tutorial (COMO REINSTALAR O GRUB), antes de prosseguir.

Figura 4

Utilizando o próprio console de recuperação, edite o fstab, alterando as linhas referente as partições que não montaram para dm-X, onde x é o número correspondente a partição que você quer montar. Abaixo uma possível configuração de como o fstab estará e como deve ficar:

Antes da modificação:

/dev/mapper/isw_dbigideeae_Volume1p1 /         ext4    errors=remount-ro 0       1
/dev/mapper/isw_dbigideeae_Volume1p2 /home          ext4    defaults          0       2
/dev/mapper/isw_dbigideeae_Volume1p3 /var              ext4    defaults                    0       2

Após a modificação:

/dev/mapper/isw_dbigideeae_Volume1p1 /      ext4    errors=remount-ro 0       1
/dev/dm-2 /home        ext4    defaults          0       2
/dev/dm-3 /var                ext4    defaults                    0       2

COMO REINSTALAR O GRUB

Se a instalação do grub não ocorreu com sucesso e você recebeu uma tela como a da figura 4 após o boot, siga os seguintes passos:

1 - Inicialize novamente usando a mídia de instalação Debian. No menu de inicialização, vá para Opções avançadas e mova o cursor para "Rescue system" (não aperte Enter ainda), pressione Tab para editar a linha de inicialização do kernel e adicione "dmraid = true" sem aspas para o final da linha. Pressione Enter.

2 - Você será apresentado com telas semelhantes às telas de instalação. Responda as questões das telas até você ser convidado a escolher um sistema de arquivos raiz para montar e usar.

Escolha o primeiro /dev/dm-? (? É um número). Você receberá um prompt de comando.

3 - Digite bash no prompt, para edição de linha de comando mais fácil e histórico de comandos.

4 - Digite grub-install /dev/mapper/ e pressione tab e tab novamente, você obterá os nomes das partições raid. Complete o grub-install /dev/mapper/ com o nome de todo o seu disco falso.

Por exemplo, grub-install /dev/mapper/isw-jggdha7s-SYS (Observe que não há número no final do nome). Você pode ter algo como /dev/mapper /isw-jggdha7s-SYS e /dev/mapper/isw-jggdha7s-SYS1 , ou /dev/mapper/isw-jggdha7s-Volume e /dev/mapper/isw-jggdha7s-Volume1.

Escolha uma que não tenha o número da partição e pressione enter.

O grub deve instalado sem retornar erros.

REFERÊNCIAS:

DEBIAN Installer/Sata Raid. Disponível em: <https://wiki.debian.org/DebianInstaller/SataRaid> Acesso em 03 abr. 2017.

FAKE Raid - Definição de Fake RAID. Disponível em: <http://www.hardware.com.br/termos/fake-raid> Acesso em 03 abr. 2017.

TUTORIAL - ZIMBRA 8 NO UBUNTU SERVER 14.04

2016-06-06T17:16:00.000-03:00

TUTORIAL 2 - INSTALAÇÃO E CONFIGURAÇÃO DO SERVIÇO DE E-MAIL ZIMBRA

Essa é a segunda parte de uma série de quatro tutoriais que possui como objetivo demonstrar a instalação do mais recente servidor de e-mails Zimbra, a configuração de um backup e como bônus a instalação de um chat integrado com o serviço de e-mail.

1 INTRODUÇÃO

Nesse segundo tutorial iremos instalar e configurar o Zimbra, o qual no final, estará pronto para ser utilizado. É necessário que você tenha completado com sucesso o primeiro tutorial para continuar.

2 INSTALAÇÃO

2.1 OBTENDO O ZIMBRA

Para nossa instalação utilizaremos o pacote de instalação do Zimbra para o Ubuntu 14.04.

Baixe o pacote do link 64bit x86 disponível em:
https://www.zimbra.com/downloads/os-downloads.html

Você pode baixar também em uma pasta (aconselho baixar na pasta /root) do sistema operacional com o comando:

#cd /root
#wget https://files.zimbra.com/downloads/8.6.0_GA/zcs-8.6.0_GA_1153.UBUNTU14_64.20141215151116.tgz

Descompactar os arquivos de instalação

#tar -zxvf zcs-8.6.0_GA_1153.UBUNTU14_64.20141215151116.tgz

2.2 EXECUTANDO A INSTALAÇÃO

Com todos os requisitos atendidos a instalação do Zimbra é relativamente simples.

Entre na pasta onde a instalação foi descompactada e execute a instalação:

#cd zcs-8.6.0_GA_1153.UBUNTU14_64.20141215151116

#./install.sh

A instalação irá realizar algumas perguntas de configuração, basta responder de acordo com a sequência abaixo:

Do you agree with the terms of the software license agreement? Y

Install zimbra-ldap [Y] y
Install zimbra-logger [Y] y
Install zimbra-mta [Y] y
Install zimbra-dnscache [Y] n
Install zimbra-snmp [Y] y
Install zimbra-store [Y] y
Install zimbra-apache [Y] y
Install zimbra-spell [Y] y
Install zimbra-memcached [Y] y
Install zimbra-proxy [Y] n

Note que não foram selecionado para instalação o zimbra-dnscache, o qual não deve ser instalado em sistemas que já tem bind ou outro serviço de dns instalado e o zimbra-proxy que pode ser utilizado no caso de existir mais de um servidor Zimbra.

The system will be modified. Continue? Y

Aguarde...

Change domain name? [Yes]

Create domain: [ns1.teste.com.br] teste.com.br

O Zimbra já esta quase pronto, necessita agora serem aplicadas as configurações. A única configuração que faremos pela linha de comando é a mudança da senha do usuário admin. Após a instalação inicial aparecerá o Menu Principal de configuração do zimbra.

No menu principal tecle 6 [Enter], tecle 4 [Enter] e entre com a senha do usuário admin [ENTER]. Volte ao menu teclando r [Enter] e aplique a configuração teclando a [Enter].

Save configuration data to a file? [Yes]
Save config in file [/opt/zimbra/config.9481]
The system will be modified - continued? [Yes]

Aguarde o final da configuração. O Zimbra já está em funcionamento.

Notify Zimbra of your instalation? [YES] NO
Configuration complete - press return to exit

Você pode acessar o console de gerenciamento, com ele que será realizada todas as configurações necessárias para administração do servidor.

https://192.168.0.1:7071/zimbraAdmin/

Figura 1 - Imagem do console de administração Zimbra 8.

Também pode ter acesso a interface do usuário.

https://192.168.0.1/

2.3 COMANDOS BÁSICOS E DICAS

Alguns comandos que podem ajudar o administrador a resolver pequenos problemas do servidor Zimbra.

*Para mudar senha do administrador
#su - zimbra
#zmprov sp <admin email address> <new password>

*Para parar e iniciar o zimbra:
#su - zimbra
#zmcontrol stop
#zmcontrol start

*Para ver o status dos serviços do zimbra:
#su - zimbra
#zmcontrol status

Uma dica é o fato de o Zimbra vir configurado para acesso apenas via https, que na minha opinião deve ser mantido por questão de segurança, mas também pode ativado o acesso via http.

Como usuário zimbra:
#su - zimbra

Ativa suporte ao acesso http e https
#/opt/zimbra/bin/zmtlsctl mixed
#zmcontrol restart

Ativa suporte apenas ao https
#/opt/zimbra/bin/zmtlsctl https
#zmcontrol restart

Ativa suporte apenas ao http
#/opt/zimbra/bin/zmtlsctl http
#zmcontrol restart

3 CONCLUSÃO

Neste ponto temos o servidor Zimbra completamente funcional. No próximo tutorial veremos como configurar um backup das contas de e-mail utilizando uma ferramenta gratuita.

REFERÊNCIAS

TUTORIAL, Zimbra 8 no debian 6 squeeze. Disponível em: <http://itnproducoes.blogspot.com.br/2013/04/tutorial-zimbra-8-no-debian-6-squeeze_22.html>

TUTORIAL - ZIMBRA 8 NO UBUNTU SERVER 14.04

2016-06-06T14:11:00.003-03:00

PALAVRA DO AUTOR

Três anos se passaram desde que escrevi a série de 4 tutoriais explicando na época os detalhes de como instalar o Zimbra em um sistema Debian.

Devido ao grande sucesso, venho atualizar os tutoriais anteriores, com novas informações, no entanto, agora instalando o Zimbra no Ubuntu 14.04, sistema operacional que possui versão homologada pelo fabricante o qual irá facilitar muito a configuração.

TUTORIAL 1 - PRÉ-REQUISITOS E CONFIGURAÇÃO DO SERVIÇO DE DNS

Esse é a primeira parte de uma série de quatro tutoriais que possui como objetivo demonstrar a instalação do mais recente servidor de e-mail Zimbra, a configuração de um backup, e como bônus, a instalação de um chat integrado com o serviço de e-mail.

1 INTRODUÇÃO

Zimbra Collaboration Server é um servidor de e-mail Opensource, que integra diversos recursos como por exemplo: agenda, organizador de tarefas e porta arquivos. Através de extensões uma infinidade de outras funcionalidades podem ser implantadas.
Funciona com clientes de e-mails com Thunderbird, Outlook, Evolution, além de possuir um cliente próprio o Zimbra Desktop.
Possui como concorrentes soluções como o Exchange da Microsoft e o GroupWise da Novel.

Nesse primeiro tutorial iremos preparar o sistema operacional para receber o Zimbra e realizar a configuração do serviço de DNS.

2 REQUISITOS DO SERVIDOR DE E-MAIL

2.1 HARDWARE

Para uma instalação de um servidor de teste é recomendado:

Processador Intel ou AMD, 32 ou 64 bits com clock de 1.5 GHz;
Memória de 4 GB;
Espaço livre em disco de 5 GB para instalação e logs;
Espaço livre em disco para armazenamento das mensagens.

Para uma instalação de um servidor para produção, é recomendado:

Processador mínimo Intel ou AMD com clock 2.0 GHZ e de 64 bits;
Memória de 8 GB;
Espaço livre em disco de 10GB para instalação e logs;
Espaço livre em disco para armazenamento das mensagens.

2.2 DOMÍNIO E IP

Um servidor DNS é pré-requisito para a instalação do Zimbra, ele pode estar no mesmo servidor ou em servidor(es) separados. Para nosso tutorial o servidor que irá hospedar o Zimbra é o mesmo que hospeda o servidor de DNS. O servidor de DNS é o responsável por resolver o nome do domínio em um ip.

Todo o domínio precisa ser registrado para poder ser acessível via internet. No Brasil o responsável pelo registro é o Registro.br. Após o registro, é preciso configurar no ambiente do registro.br o endereço do servidor DNS que irá responder pelo seu domínio. Para tanto seu servidor deve possuir um número de ip válido na internet. Na verdade o registro.br exige pelo menos dois servidores DNS que respondam pelo seu domínio. Tal procedimento é adotado para garantir a redundância de forma que se um servidor ficar indisponível, o secundário pode responder em seu lugar. Nem sempre é possível dispor de 2 servidores em um ambiente de testes, dessa forma é possível configurar um único servidor DNS para trabalhar como primário e secundário ao mesmo tempo. Com tal atitude você perde a redundância, mas para um ambiente de teste e estudo é perfeitamente válido.

Atualização: É possível instalar o Zimbra sem configurar um servidor DNS e utilizar o registro.br para adicionar as entradas DNS necessárias. Apesar de funcionar, a configuração das entradas no registro.br são limitadas, e encontraremos problemas ao tentar implementarmos algumas entradas. Uma dificuldade que enfrentei por exemplo, foi não conseguir adicionar uma entrada DKIM devido ao uso restrito do entre aspas.

Observação: Estarei escrevendo futuramente um tutorial explicando com detalhes do que se trata o DKIM e como utilizá-lo com Zimbra.

2.3 INSTALANDO E CONFIGURANDO O SERVIDOR DNS

Para o nosso tutorial o servidor irá responder pelo domínio teste.com.br e terá como ip o 192.168.0.1 e o 192.168.0.2. Como você pode observar são ips de LAN, que não são válidos para a internet, no entanto, para uma configuração real basta alterá-los.

a) Execute a instalação do seguinte pacote:

#apt-get install bind9

b) Editar arquivo /etc/hosts e adicionar as seguintes linhas:

192.168.0.1 ns1.teste.com.br ns1
192.168.0.2 ns2.teste.com.br ns2

O ns1 e ns2 são os nomes de nossos dois servidores DNS que pertencem ao domínio teste.com.br

c) Mudar o nome da máquina para ns1:

#hostname ns1
#echo ns1 > /etc/hostname

d) Editar o arquivo /etc/resolvconf/resolv.conf.d/head e deixar com a estrutura abaixo:

domain teste.com.br
search teste.com.br
nameserver 192.168.0.1
nameserver 192.168.0.2

e) Configurar as interfaces de rede editando o arquivo /etc/network/interfaces da seguinte forma:

auto lo eth0 eth0:1
iface lo inet loopback

iface eth0 inet static
address 192.168.0.1
netmask 255.255.255.0
gateway 192.168.0.254

iface eth0:1 inet static
address 192.168.0.2
netmask 255.255.255.0

Note que o ip 192.168.0.254 diz respeito ao dispositivo responsável por disponibilizar a internet para o servidor. Este dispositivo pode ser um modem adsl, por exemplo.

f) Reiniciar a interface de rede.

# ifdown eth0 && ifup eth0 && ifup eth0:1

2.3.1 Configurar o serviço de DNS

a) Adicionar no arquivo /etc/bind/named.conf.local as seguintes linhas:
Dica: Procure digitar e não copiar essa configuração, o Bind é sensível a formatações inseridas por alguns editores ao copiar e colar.

zone "teste.com.br"{
type master;
file "/etc/bind/db.teste.com";
allow-transfer { 192.168.0.2; };
};

b) Criar o arquivo /etc/bind/db.teste.com com o conteúdo abaixo:

$TTL    604800
@    IN    SOA    ns1.teste.com.br. irineu.teste.com.br. (
2016060615    ; Serial
604800        ; Refresh
86400         ; Retry
2419200       ; Expire
604800 )      ; Negative Cache TTL

@    IN    NS    ns1.teste.com.br.
@    IN    A    192.168.0.1

@    IN    NS    ns2.teste.com.br.

@    IN    MX    10    ns1.teste.com.br.
@    IN    A    192.168.0.1
ns1        A      192.168.0.1
webmail    CNAME ns1
pop    CNAME ns1
smtp CNAME ns1
imap CNAME ns1
ns2        A      192.168.0.2

c) Testes sua configuração do DNS:

#named-checkzone teste.com.br /etc/bind/db.teste.com

Resultado esperado do comando:
zone teste.com.br/IN: loaded serial 3734755897
OK

#/etc/init.d/bind9 restart

#nslookup ns1

Resultado esperado do comando:
Server: 192.168.0.1
Address: 192.168.0.1#53

Name: ns1.teste.com.br
Address: 192.168.0.1

#nslookup ns2
Server: 192.168.0.1
Address: 192.168.0.1#53

Name: ns2.teste.com.br
Address: 192.168.0.2

2.3.2 DNS Reverso

Apenas com a configuração do servidor de DNS que executamos até agora já é possível fazer a instalação do Zimbra. No entanto, para uso em produção é necessário ainda no mínimo a configuração do DNS Reverso. O DNS Reverso é uma das formas que um servidor utiliza para saber se a mensagem enviada do endereço de IP de seu servidor de e-mail responde ao domínio encontrado no cabeçalho. Vejamos com o exemplo de configuração.

a) Adicionar no arquivo /etc/bind/named.conf.local as seguintes linhas:

zone "0.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.teste.com-rev";
};

b) Criar o arquivo /etc/bind/db.teste.com-rev

$TTL    604800
@    IN    SOA    ns1.teste.com.br. irineu.teste.com.br. (2016060615    ; Serial
604800        ; Refresh
86400        ; Retry
2419200        ; Expire
604800 )    ; Negative Cache TTL

@    IN    NS    ns1.teste.com.br.
1    IN    PTR   ns1.teste.com.br.
@    IN    NS    ns2.teste.com.br.
2    IN    PTR   ns2.teste.com.br.

h) Testes sua configuração do DNS Reverso:

#named-checkzone 0.168.192.in-addr.arpa /etc/bind/db.teste.com-rev

Resultado esperado:
zone 0.168.192.in-addr.arpa/IN: loaded serial 2016060615
OK

#/etc/init.d/bind9 restart

#dig teste.com.br

Resultado esperado:

;; QUESTION SECTION:
;teste.com.br.            IN    A

;; ANSWER SECTION:
teste.com.br.        604800    IN    A    192.168.0.1

;; AUTHORITY SECTION:
teste.com.br.        604800    IN    NS    ns1.teste.com.br.
teste.com.br.        604800    IN    NS    ns2.teste.com.br.

;; ADDITIONAL SECTION:
ns1.teste.com.br.    604800    IN    A    192.168.0.1
ns2.teste.com.br.    604800    IN    A    192.168.0.2

#dig -x 192.168.0.1

Resultado esperado:

;; QUESTION SECTION:
;1.0.168.192.in-addr.arpa.   IN   PTR

;; ANSWER SECTION:
1.0.168.192.in-addr.arpa. 604800 IN   PTR   ns1.teste.com.br.

;; AUTHORITY SECTION:
0.168.192.in-addr.arpa.   604800   IN   NS   ns1.teste.com.br.

;; ADDITIONAL SECTION:
ns1.teste.com.br.   604800   IN   A   192.168.0.1

2.4 DEPÊNDENCIAS

O zimbra exige a instalação de alguns pacotes que podem ser instalados com o comando abaixo:

#apt-get install sysstat sqlite3 libperl5.18 libgmp10 libaio1 pax

3 CONCLUSÃO

Neste ponto chegamos ao ambiente do sistema operacional pronto para receber o serviço de e-mail Zimbra. A instalação e configuração é parte do tutorial 2.

REFERÊNCIAS

TUTORIAL, Zimbra 8 no Debian 6 Squeeze. Disponível em: <http://itnproducoes.blogspot.com.br/2013/04/tutorial-zimbra-8-no-debian-6-squeeze.html>

REFORÇANDO A SEGURANÇA DAS CONEXÕES HTTPS NO APACHE

2016-03-01T15:59:00.002-03:00

1 - INTRODUÇÃO

Encontrei diversos tutoriais ensinando como ativar o protocolo https no apache utilizando chaves autoassinadas. No entanto, a maioria deles não leva em consideração os cuidados a serem tomados em relação a segurança.

Ativar o protocolo https ajuda, mas não ter o mínimo de atenção com o apache e não utilizar chaves criptograficas realmente seguras, pode causar a falsa sensação de segurança.

2 - SSL, TLS e RC4

SSL - Secure Socket Layer - protocolo de criptografia amplamente utilizado para conexões seguras https. No entanto devido as diversas falhas de segurança encontradas, mesmo nas últimas versões, empresas como Google e Mozilla estão desativando o suporte em seus navegadores ao SSL 2 e 3 em favor do TLS (Transport Layer Security).

Apesar de as novas versões de navegadores desabilitarem o suporte ao SSL, é dever de quem fornece os serviços fazer sua parte no lado do servidor.

TLS - Transport Layer Security é um protocolo semelhante ao SSL mas está imune as falhas encontradas no SSL.

RC4 - É um dos algoritmos utilizados em sistemas de criptografia como o SSL e o WEP (redes sem fio). Não é considerado um algoritmo seguro.

3 - CONFIGURAÇÕES A SEREM ALTERADAS/ADICIONADAS NO APACHE.

O suporte ao SSL e ao RC4 vem ativados por padrão no apache. Desative o suporte ao SSL 2 e SSL 3, e a algoritmos de criptografias ultrapassados acrecentando as linhas abaixo no arquivo de configuração apache.conf (derivados debian) ou httpd.conf (derivados RedHat).

SSLProtocol ALL -SSLv2 -SSLv3 #Desativa o suporte ao SSLv2 e SSLv3

SSLHonorCipherOrder on #Ao escolher o tipo de criptografia, normalmente a configuração do cliente é utilizada. Se essa opção está ativa (on), a configuração do servidor será utilizada.

SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA EECDH EDH+aRSA !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4"

4 - SHA-1 e SHA-2

Os algoritmos de hash SHA são utilizados utilizados por Autoridades Certificadoras para assinar digitalmente os certificados emitidos. O SHA-1 é o mais utilizado, no entanto, diversas pesquisas apontam que ataques bem sucedidos ao SHA-1 tornam-se cada vez mais prováveis a medida que a capacidade de processamento dos computadores aumenta. Sendo assim, pretende-se estinguir-se o uso de certificados gerados em SHA-1 até janeiro de 2017.

Para quem utiliza um certificado em seu servidor gerado em SHA-1, terá que necessariamente substituí-lo por um gerado em SHA-2 mesmo que este ainda esteja dentro da validade. O google, por exemplo, anunciou recentemente que pretende adicionar alertas de segurança em seu navegador para sites que utilizem certificados SHA-1 em conexões seguras.

A família de algoritmos SHA-2 inclui seis funções de valores hash que são conhecidos como: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256

5 - GERANDO UM CERTIFICADO AUTO ASSINADO SHA-2

Você pode gerar seu próprio certificado com SHA-2 auto assinado e adicioná-lo no apache. Gere o certificado com os comandos abaixo:

#Gera o repositório de chaves

openssl genrsa -out server.key 2048

#Gera o novo certificado autoassinado utilizando o repositório de chaves (Após o comando entre com as informaçõesde país, estado, cidade, etc). Obs: Diminua o parametro -days para diminuir o tempo de validade do certificado.

openssl req -x509 -nodes -days 3650 -new -sha256 -keyout server.key -out certificado.crt

#Exibe informações do certificado.

openssl x509 -in certificate.crt -text -noout

UPGRADE ZIMBRA 8.0.X (UBUNTU 12.04) PARA ZIMBRA 8.5 + (UBUNTU 14.04)

2016-02-22T13:04:00.001-03:00

1 INTRODUÇÃO

Recetemente necessitei fazer o upgrade de um servidor de email que rodava o Ubuntu 12.04 com a versão 8.05 do Zimbra, para o Ubuntu 14.04. Como era minha intenção também atualizar o Zimbra para a última versão (8.5) precisei seguir alguns passos para obter sucesso.

Aviso desde o princípio que essa postagem não é um tutorial, mas apenas uma dica de como atualizar o Zimbra da versão 8.0.x para o Zimbra 8.5+ atualizando também o sistema operacional 12.04. Sendo assim, é necessário ter conhecimento de como realizar a instalação do Zimbra.

2 PASSO 1: ATUALIZAÇÃO NO SERVIDOR UBUNTU 12.04

Como a intenção é também atualizar o Zimbra, você irá necessitar primeiro atualizá-lo no servidor Ubuntu 12.04. Aconselho antes, que seja executado um backup completo da pasta de instalação do zimbra (com os serviços do zimbra parado), é a sua garantia se algo der errado durante o upgrade.

3 - PASSO 2: INSTALAR O ZIMBRA 8.5+ NO UBUNTU 14.04

Tenho como uma boa prática executar antes uma nova instalação do Zimbra no servidor novo, o qual irá receber o zimbra que será transferido do servidor antigo.

Se o serviço DNS a ser utilizado irá ficar no mesmo servidor Zimbra, é importante configurá-lo antes de qualquer procedimento. Esse serviço DNS deve responder as solicitações de todos os domínios configurados no servidor Zimbra que será transferido. Além disso, não se pode esquecer de configurar o próprio servidor para que o mesmo realize as consultas no local, o que pode ser feito editando-se o resolv.conf, apagando seu conteúdo e adicionando a linha nameserver 127.0.0.1.

Após a configuração do DNS, execute a instalaçao do Zimbra 8.5 normalmente no novo servidor. Provavelmente você irá necessitar resolver outros problemas durante a instalação, até que a mesma seja executada sem erros. Um erro comum é a falta de algum pacote, no entanto, a instalação avisa logo no início quais dependências são necessárias e que não foram encontradas para que seja executada a correção.

Com a instalação do Zimbra 8.5 no Ubuntu 14.04 executada com sucesso vamos para o passo 3.

4 - PASSO 3: EXECUÇÃO DO UPGRADE

Pare os serviços do zimbra no servidor antigo (Ubuntu 12.04) e também no novo servidor (Ubuntu 14.04).

No servidor Ubuntu 14.04 apague a pasta de instalação do zimbra e copie a pasta do zimbra do servidor Ubuntu 12.04 para o Ubuntu 14.04. Uma opção é utilizar o rsync ou o sftp. É importante executar a cópia mantendo as permissões do arquivos.

Execute a instalação do Zimbra no servidor Ubuntu 14.04 com o comando ./install.sh --skip-upgrade-check. Adicionar --skip-upgrade-check irá desativar um série de checagens que a instalação executa antes do upgrade. Se for executado apenas o ./install.sh você irá receber o famoso erro de perl, algo como "Perl API version v5.14.0 of Socket does not match v5.18.0 at /usr/share/perl/5.18/XSLoader.pm". Uma outra dica é não realizar a checagem de base de dados quando a instalação solicitar.

Após finalizada a instalação, verifique se todos os serviços do zimbra estão em execução e se as respectivas caixas de email possuem o conteúdo do Zimbra do servidor antigo.

Unisul TechDay 2013

2013-10-21T21:36:00.001-02:00

Atenção profissionais de TI, no dia 09 de Novembro na Universidade do Sul de Santa Catarina - Unisul em Tubarão acontece o TechDay 2013.

O evento que possui como objetivo reunir profissionais de TI, além de entusiastas, para compartilhar experiências e conhecimentos dos mais variados ramos da tecnologia da informação.

Abaixo o roteiro do mini-curso que estarei ministrando:

Servidor de email corporativo com Zimbra.

Maiores informações em:

http://unisultechday.wordpress.com/evento/

Abraços!!

2013-09-10T21:01:00.000-03:00

TUTORIAL - ZIMBRA 8 NO DEBIAN 6 SQUEEZE

TUTORIAL 4 - IMPLEMENTANDO UM SERVIÇO DE CHAT INTEGRADO COM O ZIMBRA (ZEXTRAS SUITE)

Esse é a última parte de uma série de quatro tutoriais que possui como objetivo demonstrar a instalação do mais recente servidor de e-mails Zimbra, a configuração de um backup e como bônus a instalação de um chat integrado com o serviço de e-mail.

1 INTRODUÇÃO

Nesse último tutorial iremos instalar e configurar o ZeXtras Suite, uma extensão para o Zimbra que adiciona diversos recursos ao servidor. Como, por exemplo, backup e sincronia de arquivos para dispositivos móveis. Para a utilização desses é necessário o pagamento de uma licença. A boa notícia é que o recurso de Mensagem Instantânea (Chat) que vamos implementar é gratuito.

2 INSTALAÇÃO

2.1 BACKEND

A instalação do ZeXtras Suite é bastante simples. Siga os passos abaixo:

#cd /root/

# wget http://www.zextras.com/download/zextras_suite-latest.tgz

# tar -zxvf zextras_suite-latest.tgz

# cd zextras_suite-latest

Obs: O comando abaixo irá parar o servidor Zimbra, dessa forma o procedimento deve ser executado quando o mesmo não estiver em uso.

#./install core

Responda sim para todas as perguntas [Y], e aguarde o final da instalação.

#./install zimlet

Responda sim para todas as perguntas [Y], e aguarde o final da instalação.

2.3 FRONTEND

Com o pacote ZeXtras Suite instalado precisamos agora instalar o cliente do Chat. Essa instalação pode ser feita via interface do console de administração do zimbra.

a) Obter o zextras_chat_zimlet que pode ser salvo em qualquer terminal que tenha acesso a interface web de administração do Zimbra. Você pode encontrar o pacote necessário em:

http://gallery.zimbra.com/type/zimlet/zxchat-free-instant-messaging-zimbra-8

ou baixar diretamente no link abaixo:

http://gallery.zimbra.com/download/949/1192

b) Descompacte o arquivo tar, para ter acesso ao arquivo com_zextras_chat.zip

c) Logar na interface de administração do zimbra e clique em Configurar --> Zimlets.

d) Na engrenagem no canto superior direito (do lado de Ajuda) clique em Distribuir.

e) Selecione o arquivo com_zextras_chat.zip, clique em distribuir e concluir.

O Chat já irá aparecer para qualquer usuário que logar no Zimbra. Se o usuário preferir pode desativar o chat em Preferências --> Zimlet.

3 CONCLUSÃO

Espero que, com essa sequência de tutoriais, o objetivo de desmistificar e mostrar de uma maneira prática e rápida a instalação e configuração de um servidor de e-mail completo com o Zimbra tenha sido atingido. Não deixe de comentar com sugestões, críticas e dúvidas. É a sua participação que motiva o compartilhamento de conhecimento.

REFERÊNCIAS

ZETRAS SUITE. Disponível em: <http://www.zextras.com/pt/>

2013-09-10T20:49:00.000-03:00

TUTORIAL - ZIMBRA 8 NO DEBIAN 6 SQUEEZE

TUTORIAL 3 - CONFIGURAÇÃO DO BACKUP DO ZIMBRA (ZMBKPOSE)

Esse é a terceira parte de uma série de quatro tutoriais que possui como objetivo demonstrar a instalação do mais recente servidor de e-mails Zimbra, a configuração de um backup e como bônus a instalação de um chat integrado com o serviço de e-mail.

1 INTRODUÇÃO

Nesse terceiro tutorial iremos instalar e configurar o Zmbkpose, um script capaz de realizar o backup das contas de e-mails e arquivos dos usuários Zimbra. É importante saber, que o Zmbkpose não é capaz de fazer backup de Agenda, Contatos e Tarefas. Para continuar é necessário que você tenha completado com sucesso o tutorial número dois.

2 INSTALAÇÃO

2.1 PRÉ-REQUISITOS

a) Para o funcinamento do Zmbkpose é necessário instalar os pacotes obtidos com o comando abaixo:

#apt-get install ldap-utils curl

b) É necessário também criar o diretório de configuração com o comando:

#mkdir /etc/zmbkpose

2.2 CONFIGURAÇÃO

c) Criar o arquivo /etc/zmbkpose/zmbkpose.conf com a configuração inicial obtida no site:

http://www.kyapanel.com/wiki/doku.php?id=zimbra:zmbkpose

d) Modifique as seguintes linhas do script de acordo com o exemplo abaixo:

BACKUPUSER=zimbra
WORKDIR=/opt/zimbra/backup
ADMINUSER=admin@teste.com.br
ADMINPASS=(senha definida na instalação para o admin)
LDAPMASTERSERVER=ldap://teste.com.br:389
LDAPZIMBRADN=uid=zimbra,cn=admins,cn=zimbra
LDAPZIMBRAPASS= (obtido com o comando zmlocalconfig -s zimbra_ldap_password com o usuário zimbra).
LOGFILE=/var/log/zimbra_backup.log

e)Criar o arquivo /usr/local/bin/zmbkpose com o código do script obtido no site:

http://www.kyapanel.com/wiki/doku.php?id=zimbra:zmbkpose

f) Definir o script como executável.

#chmod + /usr/local/bin/zmbkpose

g) Execute um backup de todas as contas.

#su - zimbra
#zmbkpose -f

h) Você pode restaurar o backup de uma conta com o comando:

#su - zimbra
#cd /opt/zimbra/backup
#zmbkpose -r irineu@teste.com.br full-20130412141920

onde

full-20130412141920 = nome do arquivo de backup.

Você encontra a lista de backup no arquivo sessions.txt

#cat /opt/zimbra/backup/sessions.txt

2.3 COMANDOS BÁSICOS E DICAS

Para conhecer a sintaxe de utilização, digite simplesmente “zmbkpose” logado com o usuário zimbra. Você também pode agendar no crontab o comando de backup para ser executado automaticamente. Também é possível utilizar um backup incremental.

3 CONCLUSÃO

Até o momento o zmbkpose me parece a melhor solução livre para backup do Zimbra. Existem ferramentas comerciais que oferecem diversos outros recursos. Uma delas faz parte do pacote que instalaremos para disponibilizar um Webchat aos usuários do nosso servidor Zimbra. No próximo tutorial iremos personalizar o Zimbra integrando um recurso de chat.

REFERÊNCIAS

BACKUP NO ZIMBRA. Disponível em: <http://www.kyapanel.com/wiki/doku.php?id=zimbra:zmbkpose>

FILHO, Rubens Afonso. Zmbkpose. Disponível em: <http://markintux.net/tag/zmbkpose/>

TUTORIAL - ZIMBRA 8 NO DEBIAN 6 SQUEEZE

2013-04-22T18:54:00.000-03:00

TUTORIAL 2 - INSTALAÇÃO E CONFIGURAÇÃO DO SERVIÇO DE E-MAIL ZIMBRA

Essa é a segunda parte de uma série de quatro tutoriais que possui como objetivo demonstrar a instalação do mais recente servidor de e-mails Zimbra, a configuração de um backup e como bônus a instalação de um chat integrado com o serviço de e-mail.

1 INTRODUÇÃO

Nesse segundo tutorial iremos instalar e configurar o Zimbra, o qual no final, estará pronto para ser utilizado. É necessário que você tenha completado com sucesso o primeiro tutorial para continuar.

2 INSTALAÇÃO

2.1 OBTENDO O ZIMBRA

O servidor de e-mail Zimbra é desenvolvido para diversas plataformas Linux, no entanto oficialmente não é homologada para o sistema operacional Debian. Apenas para constar, nunca tive problemas com o Zimbra sendo executado sobre o sistema Debian.
Para nossa instalação utilizaremos o pacote de instalação do Zimbra para o Ubuntu 10.04 LTS, que é o irmão mais próximo homologado pelo empresa que desenvolve o Zimbra.

Baixe o pacote do link 64bit x86 disponível em:
https://www.zimbra.com/downloads/os-downloads.html

Você pode baixar também em uma pasta (aconselho baixar na pasta /root) do sistema operacional com o comando:

#cd /root
#wget http://files2.zimbra.com/downloads/8.0.3_GA/zcs-8.0.3_GA_5664.UBUNTU10_64.20130305090205.tgz

Descompactar os arquivos de instalação

#tar -zxvf zcs-8.0.3_GA_5664.UBUNTU10_64.20130305090205.tgz

2.2 EXECUTANDO A INSTALAÇÃO

Com todos os requisitos atendidos a instalação do Zimbra é relativamente simples.

Entre na pasta onde a instalação foi descompactada e execute a instalação:

#cd zcs-8.0.3_GA_5664.UBUNTU10_64.20130305090205

#./install.sh --platform-override

A instalação irá realizar algumas perguntas de configuração, basta responder de acordo com a sequência abaixo:

Do you agree with the terms of the software license agreement? Y
Do you agree with the terms of the software license agreement? Y

Install zimbra-ldap Y
Install zimbra-logger Y
Install zimbra-mta Y
Install zimbra-snmp Y
Install zimbra-store Y
Install zimbra-apache Y
Install zimbra-spell Y
Install zimbra-memcached Y
Install zibra-proxy N

Install anyway? Y
The system will be modified. Continue? Y

Aguarde ....

Change domain name? [Yes]

Create domain: [ns1.teste.com.br] teste.com.br

O Zimbra já esta instalado. A única configuração que faremos pela linha de comando é a mudança da senha do usuário admin. Após a instalação aparecerá o Menu Principal de configuração do zimbra.

No menu principal tecle 3 [Enter], tecle 4 [Enter] e entre com a senha do usuário admin [ENTER]. Volte ao menu teclando r [Enter] e aplique a configuração teclando a [Enter].

Save configuration data to a file? [Yes]
Save config in file [/opt/zimbra/config.9481]
The system will be modified - continued? [Yes]

Aguarde o final da configuração. O Zimbra já está em funcionamento.

Notify Zimbra of your instalation? [YES] NO

Você pode acessar o console de gerenciamento, com ele que será realizada todas as configurações necessárias para administração do servidor.

https://192.168.0.1:7071/zimbraAdmin/

Figura 1 - Imagem do console de administração Zimbra 8.

Também pode ter acesso a interface do usuário.

https://192.168.0.1/

2.2.1 Bug da inicialização automática

Existe um bug na inicialização do Zimbra durante o boot do sistema. A solução para esse problema é relativamente simples.

a) Edite o arquivo /etc/init.d/zimbra e adicione a linha em negrito no entre as duas linhas como abaixo:

# Default-Start: 3 5
# Default-Stop: 0 1 6
# Description: Zimbra mail service

b) Adicione o script na inicialização:

#update-rc.d zimbra defaults

c) Reinicie o servidor para testar.

2.3 COMANDOS BÁSICOS E DICAS

Alguns comandos que podem ajudar o administrador a resolver pequenos problemas do servidor Zimbra.

*Para mudar senha do administrador
#su - zimbra
#zmprov sp <admin email address> <new password>

*Para parar e iniciar o zimbra:
#su - zimbra
#zmcontrol stop
#zmcontrol start

*Para ver o status dos serviços do zimbra:
#su - zimbra
#zmcontrol status

Uma dica é o fato de o Zimbra 8 vir configurado para acesso apenas via https. Você pode ativar também o acesso via http.

Como usuário zimbra:
#su - zimbra

Ativa suporte ao acesso http e https
#/opt/zimbra/bin/zmtlsctl mixed
#zmcontrol restart

Ativa suporte apenas ao https
#/opt/zimbra/bin/zmtlsctl https
#zmcontrol restart

Ativa suporte apenas ao http
#/opt/zimbra/bin/zmtlsctl http
#zmcontrol restart

Uma outra dica é ativar o recurso de porta arquivos que vem desativado como padrão.Para ativá-lo logando como administrador no console clique em:

Configurar --> Classe de serviço.

Na página da direita duplo clique em default.

Recursos --> Ativar a opção Porta-arquivos.

Clica em salvar no canto superior direito.

3 CONCLUSÃO

Neste ponto temos o servidor Zimbra completamente funcional. No próximo tutorial veremos como configurar um backup das contas de email utilizando uma ferramenta gratuita.

REFERÊNCIAS

ZIMBRA, OpenSource Edition + Bind9 (DNS). Disponível em: <http://ensinalinux.blogspot.com.br/2012/04/zimbra-opensource-edition-bind9-dns.html>

TUTORIAL - ZIMBRA 8 NO DEBIAN 6 SQUEEZE

2013-04-17T21:40:00.000-03:00

TUTORIAL 1 - PRÉ-REQUISITOS E CONFIGURAÇÃO DO SERVIÇO DE DNS

Esse é a primeira parte de uma série de quatro tutoriais que possui como objetivo demonstrar a instalação do mais recente servidor de e-mails Zimbra, a configuração de um backup, e como bônus, a instalação de um chat integrado com o serviço de e-mail.

1 INTRODUÇÃO

Nesse primeiro tutorial iremos prepar o ambiente do sistema operacional e realizar a configuração do serviço de DNS, indispensáveis para a instalação e funcionamento do Zimbra.

2 REQUISITOS DO SERVIDOR DE E-MAIL

2.1 HARDWARE

Para uma instalação de um servidor de teste é recomendado:

Processador Intel ou AMD, 32 ou 64 bits com clock de 1.5 GHz;
Memória de 1GB;
Espaço livre em disco de 5GB para instalação e logs;
Espaço livre em disco para armazenamento das mensagens.

Para uma instalação de um servidor para produção, o mínimo recomendado é:

Processador mínimo Intel ou AMD com clock 2.0 GHZ de 32 bits (recomendado processador de 64 bits);
Memória ram de 2GB;
Espaço livre em disco de 10GB para instalação e logs;
Espaço livre em disco para armazenamento das mensagens.

2.2 DOMÍNIO E IP

Um servidor DNS é pré-requisito para a instalação do Zimbra, ele pode estar no mesmo servidor ou em servidor(es) separados. Para nosso tutorial o servidor que irá hospedar o Zimbra é o mesmo que hospeda o servidor de DNS. O servidor de DNS é o responsável por resolver o nome do domínio em um ip.
Todo o domínio precisa ser registrado para poder ser acessível via internet. No Brasil o responsável pelo registro é o Registro.br. Após o registro, é preciso configurar no ambiente do registro.br o endereço do servidor DNS que irá responder pelo seu domínio. Para tanto seu servidor deve possuir um número de ip válido na internet. Na verdade o registro.br exige pelo menos dois servidores DNS que respondam pelo seu domínio. Tal procedimento é adotado para garantir a redundância de forma que se um servidor ficar indisponível, o secundário pode responder em seu lugar. Nem sempre é possível dispor de 2 servidores em um ambiente de testes, dessa forma é possível configurar um único servidor DNS para trabalhar como primário e secundário ao mesmo tempo. Com tal atitude você perde a redundância, mas para um ambiente de teste e estudo é perfeitamente válido.

2.3 INSTALANDO E CONFIGURANDO O SERVIDOR DNS

Para o nosso tutorial o servidor irá responder pelo dominio teste.com.br e terá como ip o 192.168.0.1 e o 192.168.0.2. Como você pode observar são ips de rede locais, que não são válidos para a internet, no entanto, para uma configuração real basta alterá-los.

a) Execute a instalação do seguinte pacote:

#apt-get install bind9

b) Editar arquivo /etc/hosts e adicionar as seguintes linhas:

192.168.0.1 teste.com.br ns1
192.168.0.2 teste.com.br ns2

O ns1 e ns2 são os nomes de nossos dois servidores DNS que pertencem ao domínio teste.com.br

c) Mudar o nome da máquina para ns1:

#hostname ns1
#echo ns1 > /etc/hostname

d) Editar o arquivo /etc/resolv.conf e deixar com a estrutura abaixo:

domain teste.com.br
search teste.com.br
nameserver 192.168.0.1
nameserver 192.168.0.2

e) Configurar as interfaces de rede editando o arquivo /etc/network/interfaces da seguinte forma:

auto lo eth0 eth0:1
iface lo inet loopback

iface eth0 inet static
address 192.168.0.1
netmask 255.255.255.0
gateway 192.168.0.254

iface eth0:1 inet static
address 192.168.0.2
netmask 255.255.255.0

Note que o ip 192.168.0.254 diz respeito ao dispositivo responsável por disponibilizar a internet para o servidor. Este dispositivo pode ser um modem adsl, por exemplo.

f) Reiniciar a interface de rede.

#/etc/init.d/networking restart

2.3.1 Configurar o serviço de DNS

a) Adicionar no arquivo /etc/bind/named.conf.local as seguintes linhas:
Dica: Procure digitar e não copiar essa configuração, o Bind é sensível a formatações inseridas por alguns editores ao copiar e colar.

zone "teste.com.br"{
type master;
file "/etc/bind/db.teste.com";
allow-transfer { 192.168.0.2; };
};

b) Criar o arquivo /etc/bind/db.teste.com com o conteúdo abaixo:

$TTL    604800
@    IN    SOA    ns1.teste.com.br. irineu.teste.com.br. (
201303251513 ; Serial
604800        ; Refresh
86400         ; Retry
2419200       ; Expire
604800 )      ; Negative Cache TTL

@    IN    NS    ns1.teste.com.br.
@    IN    A    192.168.0.1

@    IN    NS    ns2.teste.com.br.

@    IN    MX    10    ns1.teste.com.br.
@    IN    A    192.168.0.1

www        A    192.168.0.2

webmail    A    192.168.0.1
mail       A    192.168.0.1
ns1        A    192.168.0.1
ns2        A    192.168.0.2

c) Testes sua configuração do DNS:

#named-checkzone teste.com.br /etc/bind/db.teste.com

Resultado esperado do comando:
zone teste.com.br/IN: loaded serial 3734755897
OK

#/etc/init.d/bind9 restart

#nslookup ns1

Resultado esperado do comando:
Server: 192.168.0.1
Address: 192.168.0.1#53

Name: ns1.teste.com.br
Address: 192.168.0.1

#nslookup ns2
Server: 192.168.0.1
Address: 192.168.0.1#53

Name: ns2.teste.com.br
Address: 192.168.0.2

2.3.2 DNS Reverso

Apenas com a configuração do servidor de DNS que executamos até agora já é possível fazer a instalação do Zimbra. No entanto, para uso em produção é necessário ainda a configuração do DNS Reverso. O DNS Reverso é uma das formas que um servidor utiliza para saber se a mensagem enviada do endereço de ip de seu servidor de e-mail responde ao domínio encontrado no cabeçalho. Vejamos com o exemplo de configuração.

a) Adicionar no arquivo /etc/bind/named.conf.local as seguintes linhas:

zone "0.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.teste.com-rev";
};

b) Criar o arquivo /etc/bind/db.teste.com-rev

$TTL    604800
@    IN    SOA    ns1.teste.com.br. irineu.teste.com.br. (
201303261613    ; Serial
604800        ; Refresh
86400        ; Retry
2419200        ; Expire
604800 )    ; Negative Cache TTL

@    IN    NS    ns1.teste.com.br.
1    IN    PTR   ns1.teste.com.br.
@    IN    NS    ns2.teste.com.br.
2    IN    PTR   ns2.teste.com.br.

h) Testes sua configuração do DNS Reverso:

#named-checkzone 0.168.192.in-addr.arpa /etc/bind/db.teste.com-rev

Resultado esperado:
zone 0.168.192.in-addr.arpa/IN: loaded serial 3734765997
OK

#/etc/init.d/bind9 restart

#dig teste.com.br

Resultado esperado:

;; QUESTION SECTION:
;teste.com.br.            IN    A

;; ANSWER SECTION:
teste.com.br.        604800    IN    A    192.168.0.1

;; AUTHORITY SECTION:
teste.com.br.        604800    IN    NS    ns1.teste.com.br.
teste.com.br.        604800    IN    NS    ns2.teste.com.br.

;; ADDITIONAL SECTION:
ns1.teste.com.br.    604800    IN    A    192.168.0.1
ns2.teste.com.br.    604800    IN    A    192.168.0.2

#dig -x 192.168.0.1

Resultado esperado:

;; QUESTION SECTION:
;1.0.168.192.in-addr.arpa.    IN    PTR

;; ANSWER SECTION:
1.0.168.192.in-addr.arpa. 604800 IN    PTR    ns1.teste.com.br.

;; AUTHORITY SECTION:
0.168.192.in-addr.arpa.    604800    IN    NS    ns1.teste.com.br.
0.168.192.in-addr.arpa.    604800    IN    NS    ns2.teste.com.br.

;; ADDITIONAL SECTION:
ns1.teste.com.br.    604800    IN    A    192.168.0.1
ns2.teste.com.br.    604800    IN    A    192.168.0.2

2.4 DEPÊNDENCIAS

O zimbra exige a instalação de alguns pacotes que podem ser instalados com o comando abaixo:

#apt-get install sysstat sqlite3 sudo nscd libperl5.10

E necessário também remover o pacote exim4 que é um serviço de e-mail nativo do Debian.

#apt-get purge exim4-daemon-light exim4 exim4-daemon-heavy

3 CONCLUSÃO

Neste ponto chegamos ao ambiente do sistema operacional pronto para receber o serviço de e-mail Zimbra. A instalação e configuração é parte do tutorial 2.

REFERÊNCIAS

ZIMBRA, OpenSource Edition + Bind9 (DNS). Disponível em: <http://ensinalinux.blogspot.com.br/2012/04/zimbra-opensource-edition-bind9-dns.html>

CRIANDO TÚNEIS SEGUROS COM O OPEN VPN (Matriz – Filial1 – Filial2)

2012-01-22T09:34:00.001-02:00

INTRODUÇÃO

Em minhas pesquisas pelas internet encontrei dezenas de artigos abordando a configuração do Open VPN, mais não encontrei nenhum que explicasse de maneira prática o uso em cenários onde se faz necessário a interligação de três ou mais redes distintas de tal forma que se um dos servidores cair às outras redes continue comunicando-se normalmente. Fato o qual me motivou a escrever esse artigo.

Para melhor entendermos o problema imaginamos a situação da figura que servirá como base desse tutorial:

Temos a matriz, filial1 e filial2. Em uma situação em que o servidor da matriz (que está rodando uma instância do Open VPN apenas no modo servidor, servindo os clientes filial1 e filial2) venha a sair do ar, os servidores da filial1 e filial2 precisam continuar se comunicando. O mesmo terá que acontecer se o servidor da filial1 ou filial2 caírem, a comunicação com servidor da matriz permanece para o servidor ainda no ar.

Solução

1º - Uma solução simples para esse problema foi abordado em outro artigo utilizando o VTUN. Link abaixo:

http://itnproducoes.blogspot.com/2011/07/criando-tuneis-com-o-vtun.html

2º - No entanto, particularmente, tenho utilizado na maioria dos casos a solução proposta nesse artigo com o Open VPN, devido a pontos fortes que essa ferramenta oferece. Veja alguns dos principais abaixo:

* Possui atualizações constantes.

* Multiplataforma (Roda também em Windows).

* Segurança aprimorada utilizando certificados x509.

* Relativamente fácil de conseguir material na internet abordando o uso do Open VPN, além de possuir uma ampla documentação sobre seus recursos com exemplos de configuração. Veja o HOWTO no site do desenvolvedor.

Voltando ao assunto, para esse tutorial a solução proposta consiste em:

Matriz – Irá rodar uma instância do Open VPN como servidor para Filial1 e Filial2.

Filial1 – Irá rodar uma instância do Open VPN como cliente da Matriz e uma instância como servidor da Filial2.

Filial2 – Irá rodar uma instância do Open VPN como cliente da Matriz e uma instância como cliente da Filial1.

Nesse artigo exemplificarei como configurar a interligação de três redes distintas geograficamente separadas através de um túnel seguro criptografado de 2048 bits e autenticação utilizando certificados x509.

Recursos utilizados para esse tutorial:

* Três Servidores Linux rodando Debian 6.0.3 (Squeeze).

* Cada um com duas placas de redes, uma para comunicação com a rede local e outra para internet.

* Endereços das placas de redes locais:
192.168.2.1/24 --> Matriz
192.168.3.1/24 --> Filial1
192.168.4.1/24 --> Filial2

Cenário

Redes separadas geograficamente:
192.168.2.0/24 --> Matriz
192.168.3.0/24 --> Filial1
192.168.4.0/24 --> Filial2

*Obs: É necessário que as redes utilizem configurações de ips distintas, caso o contrário teremos posteriormente conflitos no roteamento e a comunicação não ocorrerá.

CONFIGURAÇÃO

Para instalar o Open VPN nos servidores.

# apt-get install openvpn

CONFIGURAÇÃO DA MATRIZ

Em nosso tutorial a máquina da matriz irá atuar apenas como servidor do Open VPN, dessa forma precisaremos além de da configuração propriamente dita, gerar as chaves de autenticação de seus clientes (Filial1 e Filial2).

a) Crie o arquivo /etc/openvpn/servidor.conf:

# mcedit /etc/openvpn/servidor.conf

Conteúdo do arquivo /etc/openvpn/servidor.conf:

proto udp
dev tun
server 10.0.0.0 255.255.255.0

#####Rota para os clientes####
client-config-dir ccd

#Filial1
route 192.168.3.0 255.255.255.0
#Filial2
route 192.168.4.0 255.255.255.0

##########################################################

max-clients 10
tls-server

#Compressao de dados
comp-lzo

#Tempo de ping 10s tempo de reinicio 120s
keepalive 10 120

#Mantem tunel e chaves carregadas em caso de quedas
persist-key
persist-tun

#Mantem o tunel levantando mesmo em conexoes ip dinamico
float
#########################################
dh /etc/openvpn/keys/dh2048.pem
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/servidor.crt
key /etc/openvpn/keys/servidor.key
tls-auth /etc/openvpn/keys/chave.key 0

b) Crie a pasta /etc/openvpn/keys e /etc/openvpn/ccd

# mkdir /etc/openvpn/keys
# mkdir /etc/openvpn/ccd

c) Crie os arquivos /etc/openvpn/ccd/filial1 e /etc/openvpn/ccd/filial2

# mcedit /etc/openvpn/ccd/filial1

Conteúdo arquivo /etc/openvpn/ccd/filial1 :

iroute 192.168.3.0 255.255.255.0

# mcedit /etc/openvpn/ccd/filial2

Conteúdo arquivo /etc/openvpn/ccd/filial2 :

iroute 192.168.4.0 255.255.255.0

É importante salientar que a não criação desses dois arquivos é causa comum de erros no roteamento encontrado em diversas configurações, que apesar de possibilitarem a comunicação entre os servidores, não conseguem encaminhar os pacotes corretamente para a interface de rede local em questão.

Esses dois arquivos são vitais para o funcionamento das rotas criadas pelas linhas
#Filial1
route 192.168.3.0 255.255.255.0
#Filial2
route 192.168.4.0 255.255.255.0
do arquivo de configuração servidor.conf criado anteriormente. Isso porque as linhas do servidor.conf apenas criam as entradas de roteamento no kernel que serão encaminhadas para a interface tun0 do servidor Open VPN. No momento em que a conexão é estabelecida o servidor Open VPN saberá para qual rede encaminhar o pacote, utilizando justamente os arquivos /etc/openvpn/ccd/filial1 e /etc/openvpn/ccd/filial2 que possuem a rota do cliente recém-conectado.

d) Criar as chaves de segurança e autenticação:

* Copiar os scripts de criação das chaves fornecidos pela instalação do Open VPN para o diretório /etc/openvpn:

# cp -a /usr/share/doc/openvpn/examples/easy-rsa/ /etc/openvpn

* Configurar o arquivo vars para geração das chaves:

Edite o arquivo /etc/openvpn/easy-rsa/2.0/vars e modifique as seguintes linhas de acordo com seus dados (KEY_SIZE corresponde ao tamanho da chave 2048 bits):

# mcedit /etc/openvpn/easy-rsa/2.0/vars

Linhas a serem modificadas:

export KEY_SIZE=2048
export KEY_COUNTRY= “BR”
export KEY_PROVINCE = “SC”
export KEY_CITY = “Laguna”
export KEY_ORG = “ITN Ltda”
export KEY_EMAIL= “itnp@msn.com”

* Preparar ambiente para criação das chaves para o servidor, filial1 e filial2:

# cd /etc/openvpn/easy-rsa/2.0
# source vars
# ./clean-all

#./build-ca
(Apenas confirme os dados com ENTER nessa etapa).

Entre na pasta /etc/openvpn/easy-rsa/2.0/keys e confirme a existência dos arquivos ca.crt, ca.key, index.txt e serial.

* Criar as chaves propriamente ditas:

# cd /etc/openvpn/easy-rsa/2.0/

./build-key-server servidor
(Mais uma vez confirme com ENTER os dados e responda do Y as duas perguntas finais Sign the certificate? Y e 1 out of 1 certificate requests certified, commit? Y)

Resultado esperado:
Write out database with 1 new entries
Data Base Updated

./buid.dh dh2048.pem
(Esse comando pode demorar alguns segundos).

# openvpn --genkey --secret chave.key
# mv chave.key /etc/openvpn/keys
(Criar essa chave adiciona uma camada extra de segurança a sua VPN recomendado pelo próprio HOWTO)

./build-key filial1
(Mais uma vez confirme com ENTER os dados e responda do Y as duas perguntas finais Sign the certificate? Y e 1 out of 1 certificate requests certified, commit? Y)

Resultado esperado:
Write out database with 1 new entries
Data Base Updated

./build-key filial2
(Mais uma vez confirme com ENTER os dados e responda do Y as duas perguntas finais Sign the certificate? Y e 1 out of 1 certificate requests certified, commit? Y)

Resultado esperado:
Write out database with 1 new entries
Data Base Updated

e) Confirmar a criação das chaves, copiar para seus diretórios de destino e iniciar o servidor OpenVPN:

* Entre na pasta /etc/openvpn/easy-rsa/2.0/keys e copie os arquivos ca.crt, servidor.crt, servidor.key, dh2048.pem, para a pasta /etc/openvpn/keys.

# cd /etc/openvpn/easy-rsa/2.0/keys
# cp –a servidor.key servidor.crt dh2048.pem ca.crt /etc/openvpn/keys

* Reinicie o serviço do Open VPN, confirme a criação da interface tun0 e das rotas para as redes da filial1 e filial2:

# /etc/init.d/openvpn restart
#ifconfig tun0

#route | grep tun0
Resultado esperado desse comando:
…
192.168.4.0 10.0.0.2 255.255.255.0 UG 0 0 0 tun0
192.168.3.0 10.0.0.2 255.255.255.0 UG 0 0 0 tun0
…

f) Configurar o firewall para aceitar conexões na porta 1194, adicionando a seguinte linha: (1194 é a porta padrão do servidor Open VPN):

iptables -A INPUT –p udp --dport 1194 –j ACCEPT

CONFIGURAÇÃO DA FILIAL1

Com o servidor da matriz já configurado para aceitar conexões dos clientes filial1 e filial2, vamos ao maior desafio de nosso tutorial que é a configuração do servidor da filial1 para funcionar como servidor para filial2 e cliente da matriz ao mesmo tempo.

1 - Configurar o cliente:

a) Crie a pasta /etc/openvpn/keysCliente

# mkdir /etc/openvpn/keysCliente

b) Crie o arquivo /etc/openvpn/clienteMatriz.conf

# mcedit /etc/openvpn/clienteMatriz.conf

Conteúdo do arquivo /etc/openvpn/clienteMatriz.conf:

remote “IP DA MATRIZ”
proto udp
client
route 192.168.2.0 255.255.255.0
dev tun
tls-client

##CONFIGURAÇÕES DE OTIMIZACAO##

#Tempo de ping 10s tempo de reinicio 120s
keepalive 10 120

#Compressao dos dados
comp-lzo

#Mantem tunel e chaves carregadas em quedas
persist-key
persist-tun

##########################################
dh /etc/openvpcn/keysCliente/dh2048.pem
ca /etc/openvpn/keysCliente/ca.crt
cert /etc/openvpn/keysCliente/filial1.crt
key /etc/openvpn/keysCliente/filial1.key
tls-auth /etc/openvpn/keysCliente/chave.key 1

c) Copiar as chaves necessárias correspondentes a filial1 do servidor da matriz:

Para esse fim você pode utilizar uma conexão sftp a partir da filial1 ou até mesmo copiar em um pendrive os arquivos dh2048.pem, ca.crt, filial1.crt filial1.key e chave.key da pasta /etc/openvpn/easy-rsa/2.0/keys e /etc/openvpn/keys do servidor da matriz para a pasta /etc/openvpn/keysCliente do servidor da filial1.

Exemplo utilizando sftp:

# cd /etc/openvpn/keysCliente
# sftp root@“IP DA MATRIZ”
# “senha do root da matriz”
# get /etc/openvpn/easy-rsa/2.0/keys/filial1.crt
# get /etc/openvpn/easy-rsa/2.0/keys/filial1.key
# get /etc/openvpn/easy-rsa/2.0/keys/ca.crt
# get /etc/openvpn/easy-rsa/2.0/keys/dh2048.pem
# get /etc/openvpn/keys/chave.key

d) Reinicie o serviço do Open VPN, confirme a criação da interface tun0 e das rotas para a rede da matriz:

# /etc/init.d/openvpn restart
#ifconfig tun0

#route | grep tun0
Resultado esperado desse comando:
…
192.168.2.0 10.0.0.5 255.255.255.0 UG 0 0 0 tun0
…

e) Teste a comunicação entre filial1 e Matriz através do envio de Pings:

#ping 192.168.2.1
(Enviado do servidor da filial1)

#ping 192.168.3.1
(Enviado do servidor da matriz)

Obs: Até o momento apesar de matriz e filial1 conseguirem resposta do echo da interface destinada à rede local (192.168.2.1 e 192.168.3.1) não será possível o ping para terminais da rede interna precisando ainda a configuração final no firewall que faremos na parte final do tutorial quando matriz, filial1 e filial2 estiverem se comunicando mutuamente.

2 - Configurar o servidor:

Para configurar o Open VPN como servidor do cliente da filial2 realizaremos praticamente os mesmos passos da configuração do servidor Open VPN da matriz com pequenas mudanças.

a) Crie o arquivo /etc/openvpn/servidorFilial1.conf

# mcedit /etc/openvpn/servidorFilial1.conf

Conteúdo do arquivo /etc/openvpn/servidorFilial1.conf:

proto udp
dev tun
port 1195
server 10.10.10.0 255.255.255.0

#####Rota para os clientes####
client-config-dir ccd

#Filial2
route 192.168.4.0 255.255.255.0

##########################################################

max-clients 10
tls-server

#Compressao de dados
comp-lzo

#Tempo de ping 10s tempo de reinicio 120s
keepalive 10 120

#Mantem tunel e chaves carregadas em caso de quedas
persist-key
persist-tun

#Mantem o tunel levantando mesmo em conexoes ip dinamico
float

#########################################
dh /etc/openvpn/keysServidor/dh2048.pem
ca /etc/openvpn/keysServidor/ca.crt
cert /etc/openvpn/keysServidor/servidorFilial1.crt
key /etc/openvpn/keysServidor/servidorFilial1.key
tls-auth /etc/openvpn/keysServidor/chave.key 0

b) Crie as pastas /etc/openvpn/keysServidor e /etc/openvpn/ccd

# mkdir /etc/openvpn/keysServidor
# mkdir /etc/openvpn/ccd

c) Crie o arquivo /etc/openvpn/ccd/filial2

Conteúdo arquivo /etc/openvpn/ccd/filial2 :

iroute 192.168.4.0 255.255.255.0

d) Criar as chaves de segurança e autenticação:

* Copiar os scripts de criação das chaves fornecidos pela instalação do Open VPN para o diretório /etc/openvpn:

# cp -a /usr/share/doc/openvpn/examples/easy-rsa/ /etc/openvpn

* Configurar o arquivo vars para geração das chaves:

Edite o arquivo /etc/openvpn/easy-rsa/2.0/vars e modifique as seguintes linhas de acordo com seus dados (KEY_SIZE corresponde ao tamanho da chave 2048 bits):

# mcedit /etc/openvpn/easy-rsa/2.0/vars

Linhas a serem modificadas:

export KEY_SIZE=2048
export KEY_COUNTRY= “BR”
export KEY_PROVINCE = “SC”
export KEY_CITY = “Laguna”
export KEY_ORG = “ITN Ltda”
export KEY_EMAIL= “itnp@msn.com”

* Preparar ambiente para criação das chaves para o servidorFilial1 e filial2:

# cd /etc/openvpn/easy-rsa/2.0
# source vars
# ./clean-all

#./build-ca
(Apenas confirme os dados com ENTER nessa etapa).

Entre na pasta /etc/openvpn/easy-rsa/2.0/keys e confirme a existência dos arquivos ca.crt, ca.key, index.txt e serial.

* Criar as chaves propriamente ditas:

# cd /etc/openvpn/easy-rsa/2.0/

./build-key-server servidorFilial1
(Mais uma vez confirme com ENTER os dados e responda do Y as duas perguntas finais Sign the certificate? Y e 1 out of 1 certificate requests certified, commit? Y)

Resultado esperado:
Write out database with 1 new entries
Data Base Updated

./buid.dh dh2048.pem
(Esse comando pode demorar alguns segundos).

# openvpn --genkey --secret chave.key
# mv chave.key /etc/openvpn/keysServidor
(Criar essa chave adiciona uma camada extra de segurança a sua VPN recomendado pelo próprio HOWTO)

./build-key filial2
(Mais uma vez confirme com ENTER os dados e responda do Y as duas perguntas finais Sign the certificate? Y e 1 out of 1 certificate requests certified, commit? Y)

Resultado esperado:
Write out database with 1 new entries
Data Base Updated

e) Confirmar a criação das chaves, copiar para seus diretórios de destino e iniciar o servidor OpenVPN:

* Entre na pasta /etc/openvpn/easy-rsa/2.0/keys e copie os arquivos ca.crt, servidorFilial1.crt, servidorFilial1.key e dh2048.pem, para a pasta /etc/openvpn/keys.

# cd /etc/openvpn/easy-rsa/2.0/keys
# cp –a servidor.key servidor.crt dh2048.pem ca.crt /etc/openvpn/keysServidor

f) Reinicie o serviço do Open VPN, confirme a criação da interface tun1 e das rotas para a rede da filial2:

# /etc/init.d/openvpn restart
# ifconfig tun0

#route | grep tun0
Resultado esperado desse comando:
…
192.168.4.0 10.10.10.2 255.255.255.0 UG 0 0 0 tun0
…

3 - Configurar o firewall para aceitar conexões na porta 1195, adicionando a seguinte linha:

iptables -A INPUT –p udp --dport 1195 –j ACCEPT

Observações importantes:

1º Antes da criação da configuração para o servidor do Open VPN na filial1, a interface tun0 era a do cliente da matriz.

2º Note que agora possuímos duas interfaces tun0 e tun1 no servidor da filial1, uma utilizada para o cliente da matriz (tun1) e outra para o servidor da filial2 (tun0).

3º Precisamos alterar a porta de escuta do servidor do Open VPN da filial1 para 1195, isso porque a porta padrão 1194 já estava sendo utilizada pelo cliente que se conecta na matriz.

CONFIGURAÇÃO DA FILIAL2

Continuando nosso tutorial, temos ainda a configuração do filial2 que atuará apenas como cliente tanto da matriz como da filial1.

1 – Configurar o cliente da Matriz:

a) Crie as pastas /etc/openvpn/keysMatriz

# mkdir /etc/openvpn/keysMatriz

b) Crie o arquivo /etc/openvpn/clienteMatriz.conf:

# mcedit /etc/openvpn/clienteMatriz.conf

Conteúdo do arquivo /etc/openvpn/clienteMatriz.conf:

remote “IP DA MATRIZ”
proto udp
client
route 192.168.2.0 255.255.255.0
dev tun
tls-client

##CONFIGURAÇÕES DE OTIMIZACAO##

#Tempo de ping 10s tempo de reinicio 120s
keepalive 10 120

#Compressao dos dados
comp-lzo

#Mantem tunel e chaves carregadas em quedas
persist-key
persist-tun

##########################################
dh /etc/openvpcn/keysMatriz/dh2048.pem
ca /etc/openvpn/keysMatriz/ca.crt
cert /etc/openvpn/keysMatriz/filial2.crt
key /etc/openvpn/keysMatriz/filial2.key
tls-auth /etc/openvpn/keysMatriz/chave.key 1

c) Copiar as chaves necessárias correspondentes a filial2 do servidor da matriz: dh2048.pem, ca.crt, filial2.crt , filial2.key e chave.key da pasta /etc/openvpn/easy-rsa/2.0/keys e /etc/openvpn/keys para a pasta /etc/openvpn/keysMatriz do servidor da filial2.

Exemplo utilizando sftp:

# cd /etc/openvpn/keysMatriz
# sftp root@“IP DA MATRIZ”
# “senha do root da matriz”
# get /etc/openvpn/easy-rsa/2.0/keys/filial2.crt
# get /etc/openvpn/easy-rsa/2.0/keys/filial2.key
# get /etc/openvpn/easy-rsa/2.0/keys/ca.crt
# get /etc/openvpn/easy-rsa/2.0/keys/dh2048.pem
# get /etc/openvpn/keys/chave.key

d) Reinicie o serviço do Open VPN, confirme a criação da interface tun0 e das rotas para a rede da matriz:

# /etc/init.d/openvpn restart
#ifconfig tun0

#route | grep tun0
Resultado esperado desse comando:
…
192.168.2.0 10.0.0.9 255.255.255.0 UG 0 0 0 tun0
…

e) Teste a comunicação entre filial2 e Matriz através do envio de Pings:

#ping 192.168.2.1
(Enviado do servidor da filial2)

#ping 192.168.4.1
(Enviado do servidor da matriz)

2 – Configurar o cliente da Filial1:

a) Crie as pastas /etc/openvpn/keysFilial1

# mkdir /etc/openvpn/keysFilial1

b) Crie o arquivo /etc/openvpn/clienteFilial1.conf:

# mcedit /etc/openvpn/clienteFilial1.conf

Conteúdo do arquivo /etc/openvpn/clienteFilial1.conf:

remote “IP DA FILIAL1”
proto udp
port 1195
client
route 192.168.3.0 255.255.255.0
dev tun
tls-client

##CONFIGURAÇÕES DE OTIMIZACAO##

#Tempo de ping 10s tempo de reinicio 120s
keepalive 10 120

#Compressao dos dados
comp-lzo

#Mantem tunel e chaves carregadas em quedas
persist-key
persist-tun

##########################################
dh /etc/openvpcn/keysFilial1/dh2048.pem
ca /etc/openvpn/keysFilial1/ca.crt
cert /etc/openvpn/keysFilial1/filial2.crt
key /etc/openvpn/keysFilial1/filial2.key
tls-auth /etc/openvpn/keysFilial2/chave.key 1

c) Copiar as chaves necessárias correspondentes a filial2 do servidor da filial1: dh2048.pem, ca.crt, filial2.crt , filial2.key e chave.key da pasta /etc/openvpn/easy-rsa/2.0/keys e /etc/openvpn/keys para a pasta /etc/openvpn/keysMatriz do servidor da filial2.

Exemplo utilizando sftp:

# cd /etc/openvpn/keysFilial1
# sftp root@“IP DA FILIAL1”
# “senha do root da filial1”
# get /etc/openvpn/easy-rsa/2.0/keys/filial2.crt
# get /etc/openvpn/easy-rsa/2.0/keys/filial2.key
# get /etc/openvpn/easy-rsa/2.0/keys/ca.crt
# get /etc/openvpn/easy-rsa/2.0/keys/dh2048.pem
# get /etc/openvpn/keysServidor/chave.key

d) Reinicie o serviço do Open VPN, confirme a criação de mais uma interface tun1 e das rotas para a rede da filial1:

# /etc/init.d/openvpn restart
#ifconfig tun0
#ifconfig tun1

#route | grep tun
Resultado esperado desse comando:
…
192.168.3.0 10.10.10.5 255.255.255.0 UG 0 0 0 tun0
192.168.2.0 10.0.0.9 255.255.255.0 UG 0 0 0 tun1
…

e) Teste a comunicação entre filial2 e Matriz através do envio de Pings:

#ping 192.168.2.1
(Enviado do servidor da filial2)

#ping 192.168.4.1
(Enviado do servidor da matriz)

f) Teste a comunicação entre filial2 e Filial1 através do envio de Pings:

#ping 192.168.3.1
(Enviado do servidor da filial2)

#ping 192.168.4.1
(Enviado do servidor da filial1)

ROTEAMENTO PARA REDE LOCAL

Apesar de todos os três servidores estarem comunicando-se através da VPN, se o objetivo é expandir o encaminhamento de pacotes para os terminais ligados nas redes e permitir a comunicação entre eles, como comentando anteriormente, é necessário à configuração dos servidores para permitir o repasse de pacotes das interfaces dos túneis a interface de rede local. Para tanto ativamos o repasse com o seguinte comando:

Na matriz:
# echo 1 > /proc/sys/net/ipv4/ip_forward

Na Filial1:
# echo 1 > /proc/sys/net/ipv4/ip_forward

Na Filial2:
# echo 1 > /proc/sys/net/ipv4/ip_forward

Após completar esse passo as redes estarão se comunicando sem problemas, sendo que tarefas como compartilhamento de impressoras e arquivos já podem ser realizadas entre os micros das redes geograficamente separadas tranquilamente.

CONCLUSÃO

Utilizando a configuração desse tutorial a VPN estará roteando o tráfego. Isso elimina a transmissão de broadcast e protocolos da camada 2. A desvantagem é que como as redes estão em endereçamentos diferentes, alguns recursos da rede como instalação automática de impressoras do Cups ou de um servidor DHCP unificado para três redes não irão funcionar. Para esses casos podemos utilizar o pacote bridge-utils, e criar uma configuração tal em que todas as três redes estejam conectadas como se estivessem em uma mesma rede local. No entanto, isso irá aumentar drasticamente o tráfego tornando-se muitas vezes inviável. Na grande maioria dos casos a solução proposta nesse aqui é mais que suficiente, sendo que podemos limitar ainda mais o uso do túnel bloqueando tudo e liberando apenas as portas e protocolos necessários aos serviços que irão utilizar de fato a VPN.

REFERÊNCIAS

Morimoto, Carlos Eduardo. Servidores Linux – guia prático. Porto Alegre: Sul Editores,2009.

HOWTO Open VPN. Disponível em: Acesso em: 21 jan. 2012.

Unisul TechDay 2011

2011-11-11T13:08:00.000-02:00

Finalmente um evento sem igual em nossa região onde tem como objetivo reunir profissionais dos mais diferentes ramos da área de tecnologia da informação.
Com muito orgulho estarei participando dessa iniciativa protagonizada pelo especialista Rafael Meyer e por toda a equipe de tecnologia da Unisul de Tubarão.
O evento acontecerá durante o dia 26 de novembro (sábado).
Entre as diversas palestras, mini-palestras e mini-cursos do evento estarei ministrando a palestra de Técnicas de recuperação de arquivos e o mini-curso de Introdução ao Firewall em Linux (Iptables).

Abaixo os links para os arquivos da palestra e mini-curso:

Técnicas de recuperação de arquivos

Introdução ao Firewall em Linux (Iptables).

Maiores informações no site:
http://unisultechday.wordpress.com/organizacao/

Abraços!!

FTP Seguro com Proftpd + SSL tutorial rápido e prático (Parte2)

2011-08-13T16:18:00.001-03:00

INTRODUÇÃO

Na parte 1 desse tutorial realizamos a configuração básica do proftpd e nos familiarizamos com alguns conceitos que nos fez entender melhor o seu funcionamento.
Nessa parte do tutorial iremos implementar o FTPs, ou seja a transferência segura dos arquivos via FTP utilizando certificados.
Esse tutorial é uma continuação dessa forma é necessário termos finalizado com êxito a parte anterior.

Link da parte 1

O QUE FOI UTILIZADO

Além do que foi utilizado na parte 1 desse tutorial aqui iremos precisar do pacote Openssl que será utilizado para gerar os certificados

INSTALAÇÃO E CONFIGURAÇÃO

Instale o pacote openssl:

#apt-get install openssl

Crie uma pasta em /etc/proftpd/certs e navegue até ela:

#mkdir /etc/proftpd/certs

#cd /etc/proftpd/certs

Utilize os comandos abaixo para gerar a chave primária, o pedido de assinatura, e o certificado:

Obs: Esse comando irá pedir uma senha que deverá ser digitada para possibilitar a geração da chave privada.
#openssl genrsa -des3 -out server.key 1024

Obs: Esse comando irá pedir a mesma senha digitada na geração da chave privada.
#openssl rsa -in server.key -out server.key.insecure

Obs: Esse comando irá pedir uma série de informações que podem ser preenchidas ou simplesmente aceitarmos as opções default utilizando enter.
#openssl req -new -key server.key.insecure -outform PEM -out server.csr

Obs: Esse comando irá pedir a mesma senha digitada na geração da chave privada.
#openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

Explicando:

server.key 1024 É a chave privada com criptografia de 1024 bits.

server.key.insecure É a mesma chave privada sem password, isso se faz necessário pelo simples fato de que se utilizarmos uma chave com password será necessário digitar a senha cada vez que o proftpd for inicializado.

server.csr É pedido de assinatura da certificação

server.crt É o certificado auto-assinado.

-days 365 É o tempo o qual o certificado será válido (365 dias = 1 ano), aumente se necessário.

Com os certificados gerados localize as linhas abaixo em nosso arquivo de configuração do /etc/proftpd/proftpd.conf e retire os comentários para ativarmos o suporte ao FTPs:

LoadModule mod_sftp_pam.c
LoadModule mod_sftp.c

< IfModule mod_tls.c > TLSEngine on
TLSRequired on
TLSVerifyClient off
TLSProtocol SSLv23
TLSLog /var/log/proftpd_tls.log
TLSRSACertificateFile /etc/proftpd/certs/server.crt
TLSRSACertificateKeyfile /etc/proftpd/certs/server.key.insecure
TLSRenegotiate required off < /IfModule >

Reinicie o servidor profptd:

#/etc/init.d/proftpd restart

CONFIGURAÇÃO DOS CLIENTES.

A transferência segura já está ativa, sendo assim você só conseguirá acessar o FTP com um cliente compatível e configurados corretamente.

Para clientes Linux via linha de comando você pode utilizar o ftp-ssl:

#apt-get install ftp-ssl

$ftp-ssl 

E para linux e Windows graficamente o Filezilla que possui cliente para diversas plataformas, downloads no link abaixo:

http://filezilla-project.org/download.php?type=client

Para o filezilla:

-Abra o gerenciador de sites;
- Clique em novo site;
- Host “ip do servidor”;
- Protocolo escolha “FTP protocolo de transferência de arquivos”;
- Encriptação “Requer FTP sobre TLS Explícito”;
- Tipo de logon “normal”;
- Usuário “suporte, itn2”;
- Senha “correspondente ao usuário”;

Veja a imagem abaixo:

Obs: O login anônimo com ssl ativo não irá funcionar.

CONCLUSÃO

A implementação de FTP com transferência aqui mostrada foi bastante simples mas ao mesmo tempo oferece uma segurança considerável levando em consideração que estamos utilizando chaves criptografadas em 1024 bits.
Espero que para aqueles que não possuíam familiaridade com ftps sobre a plataforma Linux consigam com esse tutorial utilizar o proftpd sem maiores problemas.

Abraço a todos.

Irineu Teza Nunes.

REFERÊNCIAS

MORIMOTO, Carlos. Instalando um servidor ftp. Disponível em: < http://www.hardware.co m.br/livros/servidores-linux/instalando-servidor-ftp.html > Acesso em: 08 de ago. 2011.

RIBEIRO, Pinguim. Proftpd + tls/ssl. Disponível em: Acesso em: 07 ago. 2011.

RIBEIRO, Pinguim. Certificados ssl auto-assinados. Disponível em: < http://pinguimribeiro.wikidot.com/ssl-cert-self > Acesso em: 07 ago. 2011.

LIST, of raw command. Disponível em: < http://www.nsftools.com/tips/RawFTP.htm > Acesso em 08 ago. 2011.

FILE, transference protocol. Disponível em: < http://en.wikipedia.org/wiki/File_Transfer_Protocol > Acesso em: 08 ago. 2011.

FTP Seguro com Proftpd + SSL tutorial rápido e prático (Parte1)

2011-08-12T16:27:00.000-03:00

INTRODUÇÃO

O ftp é um dos serviços mais antigos e utilizados na internet para troca de arquivos entre servidores e clientes. Devido ao fato de ter sido projetado inicialmente apenas como uma maneira fácil de disponibilizar os arquivos online, não utilizava a transferência segura criada mais tarde com o nome de FTPS (não confundir com SFTP que utiliza o protocolo ssh). O FTPS nada mais é que um FTP que utiliza a transferência de arquivos entre o cliente e servidor de forma criptografada dificultando e impedindo a coleta de dados como senha e nome de usuários com programas sniffers. Apesar de o FTP sem transferência segura ser muito utilizado, as vezes torna-se necessário a implantação do FTPs em empresas que precisam de sigilos entre as informações e dados trocados via ftp.

Neste tutorial estaremos abordando uma forma simples de utilizar o servidor Proftpd tanto como um ftp normal ou implementando a transferência segura através de chaves SSL.

O QUE FOI UTILIZADO

Para esse tutorial foram utilizados o Ubuntu Server 11.04 rodando o servidor Proftpd e para os clientes o Filezilla e o Ftp-ssh (este ultimo é um cliente ftp seguro por linha de comando para Linux). Apesar de ter sido utilizado o Ubuntu Server nesse tutorial, o servidor Proftpd pode ser utilizado praticamente em qualquer distribuição Linux, sendo que na maioria das vezes ele já vem pré instalado na distribuição.

INSTALANDO E CONFIGURANDO O SERVIDOR PROFTPD

Para instalar o Proftpd como root execute o comando:

#apt-get install proftpd

Nas perguntas feitas pelo configurador mantenha as respostas padrões.

Renomei o arquivo /etc/proftpd/proftpd.conf para /etc/proftpd/proftpd.conf.backup

#mv /etc/proftpd/proftpd.conf /etc/proftpd/proftpd.conf.backup

Cria um novo arquivo proftpd.conf:

#mcedit /etc/proftpd/proftpd.conf

Digite o seguinte conteúdo no arquivo criado:

#Carrega módulos adicionais do proftpd
LoadModule mod_ctrls_admin.c
LoadModule mod_tls.c
LoadModule mod_radius.c
LoadModule mod_quotatab.c
LoadModule mod_quotatab_file.c
LoadModule mod_quotatab_radius.c
LoadModule mod_wrap.c
LoadModule mod_rewrite.c
LoadModule mod_load.c
LoadModule mod_ban.c
LoadModule mod_wrap2.c
LoadModule mod_wrap2_file.c
LoadModule mod_dynmasq.c
LoadModule mod_vroot.c
LoadModule mod_exec.c
LoadModule mod_shaper.c
LoadModule mod_ratio.c
LoadModule mod_site_misc.c
#LoadModule mod_sftp.c
#LoadModule mod_sftp_pam.c
LoadModule mod_facl.c
LoadModule mod_unique_id.c
LoadModule mod_ifsession.c

#Configuracao principal do servidor
ServerType standalone
DefaultServer on
Umask 022
ServerName "ITN SERVER FTP"
ServerIdent on "Bem vindo ao ITN Server FTP"
ServerAdmin itn@localhost
IdentLookups off
UseReverseDNS off
Port 21
PassivePorts 60000 62000
DefaultRoot ~
TimesGMT off
MaxInstances 30
MaxLoginAttempts 3
TimeoutLogin 300
TimeoutNoTransfer 120
TimeoutIdle 120
DisplayLogin welcome.msg
DisplayChdir .message
User nobody
Group nobody
DirFakeUser off nobody
DirFakeGroup off nobody
DefaultTransferMode binary
AllowForeignAddress off
AllowRetrieveRestart on
AllowStoreRestart on
DeleteAbortedStores off
TransferRate RETR 220
TransferRate STOR 250
TransferRate STOU 250
TransferRate APPE 250
SystemLog /var/log/secure
RequireValidShell off

#Para utilizacao de certificados SSL/TLS
#<IfModule mod_tls.c>
#TLSEngine on
#TLSRequired on
#TLSVerifyClient off
#TLSProtocol SSLv23
#TLSLog /var/log/proftpd_tls.log
#TLSRSACertificateFile /etc/proftpd/certs/server.crt
#TLSRSACertificateKeyfile /etc/proftpd/certs/server.key.insecure
#TLSRenegotiate required off
#</IfModule>

<IfModule mod_ratio.c>
Ratios off
SaveRatios off
RatioFile "/restricted/proftpd_ratios"
RatioTempFile "/restricted/proftpd_ratios_temp"
CwdRatioMsg "Please upload first!"
FileRatioErrMsg "FileRatio limit exceeded, upload something first..."
ByteRatioErrMsg "ByteRatio limit exceeded, upload something first..."
LeechRatioMsg "Your ratio is unlimited."
</IfModule>

#Apenas se o usuario for acessar seu home via ftp
<Limit LOGIN>
#AllowUser usuarioComHome1
#AllowUser usuarioComHome2
#AllowUser usuarioComHome3
DenyALL
</Limit>

<Anonymous /ftp/anonimo>
User anonymous
Group ftp
AnonRequirePassword off
MaxClients 10 "The server is full, hosting %m users"
DisplayLogin welcome.msg
DisplayChdir .msg
UserRatio anonymous 0 0 0 0
<Limit LOGIN>
Allow from All
Deny from all
</Limit>
AllowOverwrite off
<Limit LIST NLST RETR PWD XPWD SIZE STAT CWD XCWD CDUP XCUP>
AllowAll
</Limit>
<Limit STOR STOU APPE RNFR RNTO DELE MKD XMKD SITE_MKDIR RMD XRMD SITE_RMDIR SITE SITE_CHMOD SITE_CHGRP MTDM>
DenyAll
</Limit>
</Anonymous>

<Anonymous /ftp/suporte>
User suporte
Group ftp
AnonRequirePassword on
MaxClients 10 "The server is full, hosting %m users"
DisplayLogin welcome.msg
DisplayChdir .msg
UserRatio suporte 0 0 0 0
<Limit LOGIN>
Allow from All
Deny from all
</Limit>
AllowOverwrite off
<Limit LIST NLST RETR PWD XPWD SIZE STAT CWD XCWD CDUP XCUP>
AllowAll
</Limit>
<Limit STOR STOU APPE RNFR RNTO DELE MKD XMKD SITE_MKDIR RMD XRMD SITE_RMDIR SITE SITE_CHMOD SITE_CHGRP MTDM>
DenyAll
</Limit>
</Anonymous>

<Anonymous /ftp>
User itn2
Group ftp
AnonRequirePassword on
MaxClients 10 "The server is full, hosting %m users"
DisplayLogin welcome.msg
DisplayChdir .msg
UserRatio itn 0 0 0 0
<Limit LOGIN>
Allow from All
Deny from all
</Limit>
AllowOverwrite on
<Limit LIST NLST STOR STOU APPE RETR RNFR RNTO DELE MKD XMKD SITE_MKDIR RMD XRMD SITE_RMDIR SITE SITE_CHMOD SITE_CHGRP MTDM PWD XPWD SIZE STAT CWD XCWD CDUP XCUP>
AllowAll
</Limit>
<Limit NOTHING>
DenyAll
</Limit>
</Anonymous>

Calma a configuração não é tão complicada quanto possa parecer de início :D.

Vejamos as linhas principais:

ServerType standalone

Modo como o servidor irá se comportar (standalone ou inetd). Segundo Morimoto (2010) O standalone é mais seguro e mais rápido, enquanto o inetd faz com que ele fique ativo apenas quando acessado, economizando cerca de 400 KB de memória RAM (que fazem pouca diferença hoje em dia).

MaxInstances 30
Diz respeito ao número de conexões simultâneas que serão aceitas pelo servidor.

ServerName "ITN SERVER FTP"
Nome do servidor FTP que será apresentado aos clientes ao se conectarem.

ServerAdmin itn@localhost
Email do administrador do sistema.

Port 21
Porta que será utilizada para escuta das conexões (padrão do FTP é 21).

PassivePorts 60000 62000
Configuração das portas utilizadas pelo ftp passivo (devem estar abertas no firewall).

DefaultRoot ~
Opção importante de segurança que restringe os usuários ao acesso ao seu próprio home.

ServerIdent on "Bem vindo ao ITN Server FTP"
Configuração da mensagem que será mostrada aos clientes ao se conectarem.

User nobody
Group nobody

Com essas duas linhas definimos que as instâncias do servidor Proftpd serão executar com privilégios restritos impedindo um comprometimento do sistema caso seja detectada uma falha grave.

#LoadModule mod_sftp_pam.c
#LoadModule mod_sftp.c
Carrega módulos necessários para ativar o SFTP.

#Para utilizacao de certificados SSL/TLS
#< IfModule mod_tls.c >
#TLSEngine on
#TLSRequired on
#TLSVerifyClient off
#TLSProtocol SSLv23
#TLSLog /var/log/proftpd_tls.log
#TLSRSACertificateFile /etc/proftpd/certs/server.crt
#TLSRSACertificateKeyfile /etc/proftpd/certs/server.key.insecure
#TLSRenegotiate required off
#< /IfModule >

Essas linhas serão utilizadas quando configuramos o FTP para transferência segura. Para um FTP normal mantenha essas linhas comentadas.

#Apenas se o usuario for acessar seu home via ftp
< Limit LOGIN >
#AllowUser usuarioComHome1
#AllowUser usuarioComHome2
#AllowUser usuarioComHome3
DenyALL
< /Limit >
Caso você queira que um usuário possa acessar sua pasta home via FTP inclua aqui AllowUser “nomeDoUsuario” nesta tag.

Na tag:

< Anonymous /ftp/anonimo >

Definimos as pastas efetivamente compartilhadas pelo ftp e dentro delas quem tem permissão de acessar ou não as pastas bem como o que pode ser feito ou não dentro da pasta. No exemplo de configuração a pasta /ftp/anonimo pode ser acessado por login anônimos (mas apenas para downloads). Isso é definido pelas linhas:
User anonymous
Group ftp
AnonRequirePassword off

A principal diferença da tag:
< Anonymous /ftp/anonimo >

Para as tags:
< Anonymous /ftp/suporte >
< Anonymous /ftp >
é que nessas duas últimas é necessário que o usuário entre com a senha para autenticação no servidor. Isso é definido pela opção:
AnonRequirePassword on

Com a linha abaixo definimos os comandos que o usuário anônimo pode executar. Entre eles o download de arquivos:
< Limit LIST NLST RETR PWD XPWD SIZE STAT CWD XCWD CDUP XCUP >
AllowAll
< /Limit >

Já com a linha abaixo definimos os comandos que o usuário anônimo pode não pode executar. Entre apagar arquivos, criar pastas, e executar uploads:
< Limit STOR STOU APPE RNFR RNTO DELE MKD XMKD SITE_MKDIR RMD XRMD SITE_RMDIR SITE SITE_CHMOD SITE_CHGRP MTDM >
DenyAll
< /Limit >

Veja ao final desse artigo uma lista de alguns dos comandos FTP utilizados nesse artigo.

De maneira resumida com esse exemplo de arquivo de configuração, o usuário anonymous pode apenas executar download da pasta /ftp/anonimo. O usuário suporte pode executar download da pasta /ftp/suporte. Já o usuário itn2 tem permissão completa (upload, downloads, renomear ou remover arquivos, etc), seria como um administrador do ftp, que pode acessar a raiz /ftp e fazer as modificações necessárias.

CRIANDO AS PASTAS, GRUPO E USUÁRIOS PARA O USO DO FTP.

Precisamos criar o grupo ftp e os usuários que fazem parte desse grupo para que acessem o FTP. No entanto esses usuários não devem ter permissão para logarem no servidor como usuários comuns. Para tanto execute seguintes comandos:

Cria o grupo ftp
# addgroup ftp

Cria os usuários sem pasta home e com shell desativado:

# adduser itn2 --shell /bin/false --no-create-home
# adduser suporte --shell /bin/false --no-create-home
# adduser anonymous --shell /bin/false –no-create-home

Adiciona os usuário ao grupo ftp

# adduser itn2 ftp
# adduser suporte ftp
# adduser anonymous ftp

Agora vamos criar as pastas raiz do ftp, do usuário anonymous e do suporte definidos nas tags correspondentes no arquivo de configuração:

# mkdir /ftp
# mkdir /ftp/anonimo
# mkdir /ftp/suporte

Vamos ajustar a permissão das pastas:

Define o grupo ftp como dono do diretório /ftp e todos seus subdiretórios (opção -R)

# chown -R ftp.ftp /ftp

Define permissão total para o grupo ftp do diretório /ftp e todos seus subdiretórios (opção -R)

# chmod 575 -R /ftp

Basta agora liberamos as portas 21 bem como as portas 60000 ao 62000 no firewall. Se você utiliza o Iptables adicione as seguintes linhas no seu script:

iptables –A INPUT –p tcp --dport 21 –j ACCEPT
iptables –A INPUT –p tcp --dport 60000:62000 –j ACCEPT

Reinicie o servidor proftpd:
#/etc/init.d/proftpd restart

Caso você receba um erro de grupo nobody não encontrado, ao iniciar o servidor proftpd crie o grupo nobody com o comando abaixo e torne a reiniciar o proftpd:
# addgroup nobody
#/etc/init.d/proftpd restart

COMANDOS FTP PADRONIZADOS

Os comandos abaixo dizem respeito a comandos FTP padronizados pela RFC 959, os quais irão aparecer nas tags do nosso arquivo de configuração. Você pode achar estanho a ausência na lista de comandos como get por exemplo, isso irá acontecer porque o get é considerado um comando de usuário utilizado pelas aplicações ftp que indicam a requisição do download de um arquivo do servidor, no entanto o comando get é representado dentro da padronização pelo retr.
Vejamos abaixo alguns comandos que podem ser adicionados nas tags afim de permitir ou negar que determinado usuário execute determinada ação:

list Permite que o usuário liste os arquivos dos diretórios.

nlst Lista o nome dos diretórios.

retr Executa o download de um arquivo.

pwd Mostra o diretório atual.

size Permite o retorno do tamanho de um arquivo em decimal.

stat Retorna informações sobre o servidor.

cwd Permite definir o diretório inicial no ato da conexão.

cdup Marca o diretório acessado como diretório raiz para os demais.

stor, stou Permitem iniciar o upload de arquivos.

appe Utilizado para acrescentar informações ao final de um arquivo.

rnfr, rnto Utilizados para renomear arquivos.

dele Utilizado para exclusão de arquivos.

mkd Utilizado para criar diretórios.

CONCLUSÃO

Com a parte 1 desse tutorial nosso servidor FTP já está no ar e pronto para ser utilizado, podendo ser acessado normalmente por qualquer cliente FTP (mesmo que não possua suporte a conexão segura SSL como o Firezilla ou o Ftp-ssl, isto porque iremos implementar a transferência segura SSL na parte 2.

Não percam a continuação…

Link Parte 2

REFERÊNCIAS

FILE, transference protocol. Disponível em: < http://en.wikipedia.org/wiki/File_Transfer_Protocol > Acesso em: 08 ago. 2011.

MORIMOTO, Carlos. Instalando um servidor ftp. Disponível em: < http://www.hardware.co m.br/livros/servidores-linux/instalando-servidor-ftp.html > Acesso em: 08 de ago. 2011.

RIBEIRO, Pinguim. Proftpd + tls/ssl. Disponível em:< http://pinguimribeiro.wikidot.com/proftpd-tls-ssl > Acesso em: 07 ago. 2011.

RIBEIRO, Pinguim. Certificados ssl auto-assinados. Disponível em: < http://pinguimribeiro.wikidot.com/ssl-cert-self > Acesso em: 07 ago. 2011.

LIST, of raw command. Disponível em: < http://www.nsftools.com/tips/RawFTP.htm > Acesso em 08 ago. 2011.

Port knocking + Iptables fechando portas abertas a internet

2011-07-30T11:02:00.000-03:00

Introdução.

Você já se preocupou com a quantidade de portas abertas no firewall da sua empresa, a porta 22 precisa para o acesso SSH, a 3389 para o terminal Server, a 5900 para o VNC?

Claro que a gente não se preocupa isso é bobagem, afinal nós profissionais de TI sempre temos pouca coisa para fazer e estamos constantemente trocando senhas de todos os serviços, atualizando o sistema, monitorando logs, e usamos tunelamento*. Além disso, não usamos portas padrões para o ssh, ele está rodando na porta “60500” e nenhum Hacker* irá descobrir isso :D. Bom brincadeiras a parte afinal em qualquer chat de Stripts* a palavra nmap* rola solta.

Sabemos no entanto que é praticamente impossível não possuir nenhuma porta aberta para o uso externo. Afinal temos servidores pop (porta 110), smtp (porta 25), e o próprio servidor web (porta 80) que devem estar “bem abertas” para o acesso. No entanto podemos minimizar o problema abrindo outras portas apenas quando realmente for necessário.

A idéia de um Port knocking é exatamente essa. As portas de serviços como o do Ssh ficam fechadas para acesso externo até segunda ordem a não ser que você solicite a abertura.

*Tunelamento resumidamente seria a conexão entre duas máquinas utilizando-se de uma porta qualquer onde podem trafegar informações de qualquer serviço mesmo que utilizem outra porta. Um bom exemplo de protocolo que suporta tunelamento é o Security Shell (ssh).

*Hacker diz respeito ao usuário que estuda um sistema ou hardware de computador, procurar entender seu mecanismo e como ele funciona a fim de aperfeiçoá-lo. Ao contrário do que divulga a mídia onde o Hacker é o usuário que invade sistemas e os danifica, ela está se referindo na verdade ao Cracker. Um Hacker pode invadi um sistema a fim de apontar falhas a serem corrigidas no entanto jamais causará prejuízos ou roubo de informações sigilosas.

*Scripts antigamente denominado de Lamer é o usuário que apesar de não compreender exatamente como um sistema ou mecanismo funciona utiliza-se de ferramentas criadas por outros. Esses causam prejuízos, danificam sistemas com o único intuito de ganhar fama ou dinheiro.

*Nmap software utilizado para escaneamento de redes a procura de informações diversas de um host.

Knockd

O knockd é um servidor port knoking que utiliza a lógica de combinações de portas, ou seja, caso uma tentativa de conexão externa respeite uma lógica de portas previamente definidas, a porta realmente requerida será aberta.

Um serviço knockd fica ativo em seu servidor monitorando todas as tentativas de conexões externas, caso a ordem das tentativas de conexões em portas distintas respeitem a ordem definida no seu arquivo de configuração uma regra é ativada e adicionada ao firewall.

Imaginamos que precisamos acesso a porta 3389, tentaremos inicialmente a conexão no servidor pelas portas 5000, 6000 e 7000 respectivamente (também fechadas), o serviço knockd estará monitorando essa tentativa e disparando a regra correspondente liberando acesso a porta 3389 no firewall.

Da mesma forma que a porta é aberta após finalizarmos a conexão uma outra regra é definida para fechar a porta.

O que foi utilizado

Para esse tutorial foram utilizados os sistemas Ubuntu server 11.04 configurado como firewall que possui duas placas de redes uma para acesso da internet e outro para a rede local, uma máquina cliente da rede local com Windows 2008 R2, ip 192.168.1.18, rodando o Terminal Server na porta 3389 (“Windows com W viu :)”) e uma maquina externa a rede Windows Seven que irá acessar o TS da internet.

Nosso objetivo será manter a porta 3389 fechada para acesso externo no firewall e abri-la apenas (não para toda a internet) ao cliente externo que entrou com a seqüência de portas definidas no arquivo de configuração do knocking.

Instalação e configuração do servidor

Para instalar o knockd como root digite:

#apt-get install knockd

Edite o arquivo de configuração:

# mcedit /etc/knockd.conf

Apague o conteúdo padrão do arquivo e preencha com o seguinte conteúdo:

#--INICIO--#

[options]

UseSyslog

[OPENTS2003]

sequence = 7000,8000,9000

seq_timeout = 5

command = /sbin/iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 3389 -j DNAT -s %IP% --to 192.168.1.18

tcpflags = syn

[CLOSETS2003]

sequence = 9000,8000,7000

seq_timeout = 5

command = sbin/iptables -t nat -D PREROUTING -p tcp -i eth0 --dport 3389 -j DNAT -s %IP% --to 192.168.1.18

tcpflags = syn

#--FIM--#

As linhas mais importantes desse arquivo são:

sequence = 7000,8000,9000
é onde definimos a seqüência de portas tcp que devem respeitada para a adição da regra da linha command = /sbin/iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 3389 -j DNAT -s %IP% --to 192.168.1.18 no firewall.

sequence = 9000,8000,7000 é onde definimos a seqüência de portas tcp que devem respeitada para a remoção da regra da linha command = /sbin/iptables -t nat -D PREROUTING -p tcp -i eth0 --dport 3389 -j DNAT -s %IP% --to 192.168.1.18 do firewall.

Execute o knockd com o seguinte comando:

knockd –i eth0 –d –c /etc/knockd.conf

Obs: Neste tutorial considere eth0 a placa do firewall ligada à internet.

Dicas:

*Você pode adicionar no final do arquivo /etc/rc.local o comando knockd –i eth0 –d –c /etc/knockd.conf afim de o serviço do knocking iniciar junto com o servidor.

*Podem ser adicionadas novas regras OPEN e CLOSE no arquivo de configuração do knocking.

Configuração o cliente knockd no Windows

Com o servidor em pleno funcionamento vamos baixar o cliente knockd para Windows e criar um pequeno script para executá-lo e disparar a solicitação de abertura da porta 3389 ao servidor além de abrir o cliente do Terminal Server para acesso.

Baixe o cliente knock para Windows no link abaixo:

http://www.zeroflux.org/proj/knock/files/knock-win32.zip

Cria uma pasta no c:\ com o nome de knockcli

Descompacte o arquivo baixado, entre na pasta Release e copie o executável knock.exe para a pasta c:\knockcli

Abra o bloco de notas e digite o seguinte conteúdo:

c:
cd\
cd knockcli
knock “ipdoservidor” 7000:tcp 8000:tcp 9000:tcp
cls
echo "Mantenha essa janela aberta"
%windir%\system32\mstsc.exe
knock “ipdoservidor” 9000:tcp 8000:tcp 7000:tcp

Salve com o arquivo com o nome de iniciaTS.cmd

Configuração o cliente knockd em uma máquina Linux (Ubuntu).

Para instalar cliente do knockd no Linux o comando é o mesmo do servidor, como root:

#apt-get install knockd

Podemos agora criar um pequeno script que irá executar o cliente knocking, abrir o cliente TS (Rdesktop) e ao término da sessão do TS fechar a porta novamente.

Em um terminal crie o arquivo exemplo.sh no diretório de sua preferência (não precisa ser como root):

$ mcedit /home/itn/exemplo.sh

Adicione o seguinte conteúdo ao arquivo:

#!/bin/bash
knock “ipdoservidor” 7000:tcp 8000:tcp 9000:tcp
rdesktop “ipdoservidor”
knock “ipdoservidor” 9000:tcp 8000:tcp 7000:tcp

As linhas

knock “ipdoservidor” 7000:tcp 8000:tcp 9000:tcp é a seqüência de solicitação de conexão de portas definidas no servidor para abrir a porta 3389.

knock “ipdoservidor” 9000:tcp 8000:tcp 7000:tcp é a seqüência de solicitação de conexão de portas definidas no servidor para fechamento da porta 3389.

Marque o arquivo como executável:

$ chmod +x /home/itn/exemplo.sh

Execute o arquivo (clicando sobre ou via terminal).

$ /home/itn/exemplo.sh

Conclusão

Esse tutorial foi uma pequena demonstração do uso prático de um Port knocking, sendo que o limite para o seu uso é a imaginação. Concluímos também que com esse pequeno guia podemos dormir mais tranqüilos sabendo que a “temida” porta 3389 está fechada dando um pouco mais de dor de cabeça ao Scripts, Hacker ou curiosos de plantão .

Referências

KNOCKD, a port-knocking server. Disponível em: Acesso em: 29 jul. 2011.

Cfengine tutorial prático de instalação cliente – servidor.

2011-07-29T12:57:00.000-03:00

Introdução

Cfengine é um software utilizado para automatizar tarefas como instalação de programas e configurações de serviços em máquinas clientes de forma centralizada e controlada agilizando e otimizando o trabalho do profissional de TI.

O objetivo deste tutorial é demonstrar de maneira prática a instalação e configuração básica de um servidor Cfengine e de seus clientes, utilizando comunicação segura através de chaves criptografadas.

Para esse tutorial foi utilizado como servidor o Ubuntu server 11.04 e como cliente o Ubuntu desktop 10.10, no entanto o Cfengine pode ser configurado em diversos sistemas operacionais até mesmo no Windows (para utilizá-lo no Windows será preciso a instalação prévia do Cygwin).

Principais componentes do Cfengine:

Cabe aqui uma pequena definição dos componentes principais do Cfengine:

cf-promises – É um verificador e compilador para os arquivos de promises. É usado principalmente para checar as configurações desses arquivos.

cf-agent - Verifica as mudanças no diretório de atualizações do servidor a faz a sincronia no cliente.

cf-serverd – É o componente responsável por receber as requisições dos clientes e executar as políticas de um cliente. Segundo CFENGINE não é possível o envio operações de (push).

cf-execd – É o agendador de tarefas do Cfengine. Ele também coleta e executa saídas do cf-agent. Além de poder ser configurado para enviar emails ao administrador se necessário.

cf-runagent - É um programa auxiliar pode se comunicar com o cf-serverd e solicitar que ele execute o cf-agent.

cf-report - Gera relatórios em uma variedade de formatos para exportação ou
integração com outros sistemas.

Instalação e configuração no servidor

Como administrador execute o comando:

#apt-get install cfengine3

Crie na raiz uma pasta com o nome de cfengine e dentro desta uma pasta inputs.

# mkdir /cfengine
# mkdir /cfengine/inputs

Para configuração do servidor precisaremos criar quatro arquivos.

Arquivo 1: Dentro da pasta /cfengine crie o arquivo cf-serverd.cf com o seguinte conteúdo:

#--Inicio--#

body server control {

trustkeysfrom => { "192.168.1.18", "192.168.1.17" };

allowconnects => { "192.168.1.18", "192.168.1.17" };

maxconnections => "10";

logallconnections => "true";

}

bundle server access_rules {

access: "/cfengine/"

admit => { "192\.168\..*" };

}

#--Fim--#

As linhas

trustkeysfrom => { "192.168.1.18", "192.168.1.17" };
allowconnects => { "192.168.1.18", "192.168.1.17" };

é o lugar onde serão adicionados os ips das máquinas clientes que irão ter acesso ao servidor.

As linhas

access:

"/cfengine/"

admit => { "192\.168\..*" };

representam a pasta que os clientes terão acesso ao servidor, e a faixa de ips dos clientes com acesso autorizado.

Arquivo 2: Dentro da pasta /cfengine crie o arquivo update.cf com o seguinte conteúdo:

#--Inicio--#

body copy_from remote(server, path) {

servers => { "${server}" };

encrypt => "true";

trustkey => "true";

source => "${path}";

compare => "digest";

preserve => "true";

verify => "true";

purge => "true";

}

body depth_search recurse {

depth => "inf";

}

bundle agent update {

vars:

any::

"cfserverd" string =>"192.168.1.1";

"policyfiles" string =>"/cfengine";

"server_inputs" string =>"${policyfiles}/inputs";

"client_inputs" string =>"${sys.workdir}/inputs";

files:

any::

"${client_inputs}"

copy_from => remote("${cfserverd}","${server_inputs}"),

depth_search => recurse;

}

#--Fim--#

Na linha

"cfserverd" string =>"192.168.1.1";

é onde adicionamos o ip do servidor.

Na linha

"policyfiles" string =>"/cfengine";

Adicionamos a política de acesso a pasta cfengine (a mesma definida nas linhas access:

"/cfengine/" do arquivo cf-serverd.cf

Arquivo 3: Dentro da pasta /cfengine crie o arquivo promises.cf com o seguinte conteúdo:

#--Inicio--#

body common control {

bundlesequence => {

"update" };

inputs => { "update.cf","cf-serverd.cf" };

}

bundle agent hello {

commands:

any::

"/bin/date";

reports:

linux::

"Ola Mundo.";

}

#--Fim--#

Arquivo 4: Dentro da pasta /cfengine crie o arquivo failsafe.cf com o seguinte conteúdo:

#--Inicio--#

body common control{

bundlesequence => { "update" };

inputs => { "update.cf" };

}

#--Fim--#

Obs: Quando utilizarmos posteriormente o cf-agent ele sempre irá ler o arquivo promises.cf durante sua execução. Sendo assim todos os comandos a serem executados devem estar neste arquivo ou referenciado nele. Sendo assim o arquivo failsafe.cf não é realmente obrigatório, mas no entanto caso exista algum problema no arquivo promises.cf o cf-agent irá ler o arquivo failsafe.cf, que por sua vez chama o arquivo update.cf e busca atualizações ou correções no servidor.

Com os quatro arquivo prontos precisamos copiá-los para a pasta /etc/cfengine3 e move-los para /cfengine/inputs:

# cp promises.cf failsafe.cf update.cf cf-serverd.cf /etc/cfengine3
# mv promises.cf failsafe.cf update.cf cf-serverd.cf inputs

Agora geramos as chaves no servidor:

#cf-key

Afim de o servidor ler as configurações execute o comando:

#cf-serverd --verbose --no-fork

Quando a mensagem:

No new promises found
Waiting at incoming select...

finalize o processo CTRL+C.

Agora com o servidor configurado ele já pode ser iniciado:

#cf-serverd

Obs: A porta default do Cfengine é a 5308 sendo necessário ela estar liberada no servidor afim de permitir as conexões dos clientes.

Configuração do cliente:

Para configurar os clientes iniciamos com a instalação do pacote:

# apt-get install cfengine3

Geramos as chaves com o comando:

# cf-key

Precisamos agora copiar manualmente os arquivos failsafe.cf e update.cf criados anteriormente no servidor para a pasta /etc/cfengine3 do cliente.

Como root entre na pasta /etc/cfengine3 e execute o comando abaixo:

# cd /etc/cfengine3
#cf-agent –K --verbose –bootstrap

Se tudo estiver certo na pasta /var/lib/cfengine3/ppkeys do cliente irá aparacer a chave root-192.168.1.1.pub e no servidor root-192.168.1.18.pub (ou root-“ip que você configurou para o cliente”.pub).

Execute agora o comando:

# cf-agent

Com esse comando os arquivos da pasta /var/lib/cfengine3/inputs do cliente serão sempre sincronizados com conteúdo da pasta /cfengine/inputs no servidor.

Configurando cliente para atualizar automaticamente.

Claro que na prática o cf-agent não é executado manualmente no cliente afim de executarmos sincronização com o servidor, para isso utilizamos um outro componente do Cfengine o cf-execd que irá ficar ativo no cliente e de tempos em tempos executando o cf-agent a procura de atualizações.

Obs: Muitos utilizam para esse fim o próprio cron, no entanto não é recomendável uma vez que o cf-execd trás diversos recursos incorporados como o criação de logs para cada execução, além disso o cf-execd foi criado exclusivamente para tarefa de agendamento do Cfengine.

Crie o arquivo cf-execd.cf na pasta /etc/cfengine3

#--Inicio--#

body executor control {

splaytime => "1";

mailto => "root@192.168.1.1";

smtpserver => "192.168.1.1";

mailmaxlines => "1000";

schedule => { "Min00_05", "Min30_35" };

executorfacility => "LOG_DAEMON";

}

bundle agent executor {

processes:

any::

"cf-execd"

restart_class => "start_cfexecd";

commands:

start_cfexecd::

"/usr/local/sbin/cf-execd";

}

#--Fim--#

Execute o comando:

# cf-execd

Como teste final você pode criar algum arquivo no diretório /cfengine/inputs no servidor, aguardar o tempo programado no arquivo cf-execd.cf para atualização e verificar se o diretório /var/lib/cfengine3/inputs do cliente foi sincronizado.

Conclusão

Devido à falta de material em português que mostrassem de maneira prática e direta a configuração do Cfengine resolvi escrever esse tutorial. O objetivo não era ensinar a utilização prática, mas como configurar a comunicação entre o servidor e os clientes.

Agora com o servidor e os clientes comunicando-se, será preciso estudar sínteses de comandos e criação de configurações para o arquivo “promises.cf” afim de realmente automatizar as tarefas poder aplicar o Cfegine de maneira produtiva.

Referências

CFENGINE. Disponível em: <http:// www. cfengine. org> Acesso em: 28 jul. 2011.

CFENGINE 3, concept guide. Mark Burges.

Criando túneis com o VTUN

2011-07-26T00:06:00.000-03:00

Introdução

Nesse tutorial estarei abordando de forma prática a interligação de três redes distintas com utilizando o VTUN.

Cenário:
Redes separadas geograficamente:
192.168.1.0/24
192.168.2.0/24
192.168.4.0/24

*Obs: É necessário que as redes utilizem configurações de ips distintas, caso o contrário teremos posteriormente conflitos no roteamento e a comunicação não acontecerá.

Para esse tutorial:
Foram utilizados três servidores rodando uma versão do Ubuntu Server 11.04, com duas placas de redes uma para rede local e outra para a internet. No entanto esse tutorial pode ser adaptado para qualquer versão de Debian ou derivados.

Explicando:

O desenho abaixo representa uma topologia de VPN em estrela, dessa forma se qualquer um dos servidores ficarem fora do ar por algum motivo os outros continuará comunicando-se entre si normalmente.

Rede Matriz -> 192.168.1.0/24
Rede Filial1 -> 192.168.4.0/24
Rede Filial2 -> 192.168.2.0/24

Túnel 1 -> Liga a Matriz a Filial 1 (10.0.0.1 <>10.0.0.3)
Túnel 2 -> Liga a Filial 1 a Filial 2 (10.0.0.4 <>10.0.0.5)
Túnel 3 -> Liga a Filial 2 a Matriz (10.0.0.6 <> 10.0.0.2)

Configuração

Para instalar o vtun

# apt-get install vtun

Teremos três arquivos de configuração distintos. A Matriz apenas irá rodar o vtun em modo servidor, ou seja irá aceitar as conexões da Filial1 e Filial2.

Vejamos o arquivo de configuração da Matriz:

#Configuracao Matriz

#Configuracao Matriz (10.0.0.1 / 10.0.0.2)

default {
type tun;
proto tcp;
compress lzo:9;
keepalive yes;
encrypt yes;
}

#Tunel entre Filial1 e Matriz (10.0.0.3 <--->10.0.0.1)
Filial1Matriz {
passwd tux;

up{
ifconfig "%% 10.0.0.1 pointopoint 10.0.0.3";
route "add -net 192.168.4.0/24 gw 10.0.0.3";
};
down{
ifconfig "%% down";
route "del -net 192.168.4.0/24 gw 10.0.0.3";
};

}

#Tunel entre Filial2 e Matriz (10.0.0.6 <--->10.0.0.2)
Filial2Matriz {
passwd tux;

up{
ifconfig "%% 10.0.0.2 pointopoint 10.0.0.6";
route "add -net 192.168.2.0/24 gw 10.0.0.6";
};
down{
ifconfig "%% down";
route "del -net 192.168.2.0/24 gw 10.0.0.6";
};

}

Nesse arquivo você pode ver a configuração do servidor que irá esperar por duas conexões da Filial1 e da Filial2.

As Linhas passwd tux; podem e devem ser alteradas utilizando-se senhas diferentes entre os túneis do servidor com a Filial1 e Filial2.

As linhas route "del -net 192.168.4.0/24 gw 10.0.0.3"; para a Filial1 e route "add -net 192.168.2.0/24 gw 10.0.0.6"; para a Filial2 devem ser alteradas de acordo com a configuração de ip da sua rede.

Com o arquivo pronto você irá precisar executar apenas mais dois passos, liberar a porta 5000 utilizada como padrão (essa porta pode ser alterada) pelo vtun no firewall e executar o servidor vtun propriamente dito.

Exemplo:
# iptables –I INPUT –p tcp --dport 5000 –j ACCEPT

ou ainda:

# iptables –I INPUT –p tcp –s IPDAFILIAL1 --dport 5000 –j ACCEPT
# iptables –I INPUT –p tcp –s IPDAFILIAL2 --dport 5000 –j ACCEPT

Nesse caso apenas se o ips da internet da FILIAL1 e FILIAL2 forem fixos, isso trará mais segurança uma vez que você está liberando conexões na porta 5000 apenas para os ips da Filial1 e Filial2 impedindo tentativas de conexões oriundas de outros locais.

Para executar o servidor vtun:
# vtund -s

Vejamos o arquivo de configuração da Filial1:

###Configuracao cliente de 2 servidores#######

#Cliente para Matriz (10.0.0.3 <-->10.0.0.1)
Filial1Matriz{
passwd tux;
compress lzo:9;
keepalive yes;
encrypt yes;

up{
ifconfig "%% 10.0.0.3 pointopoint 10.0.0.1";
route "add -net 192.168.1.0/24 gw 10.0.0.1";
};
down{
ifconfig "%% down";
route "del -net 192.168.1.0/24 gw 10.0.0.1";
};
}

#Cliente para Filial2 (10.0.0.4 <-->10.0.0.5)
Filial1Filial2 {
passwd tux;
compress lzo:9;
keepalive yes;
encrypt yes;

up{
ifconfig "%% 10.0.0.4 pointopoint 10.0.0.5";
route "add -net 192.168.2.0/24 gw 10.0.0.5";
};
down{
ifconfig "%% down";
route "del -net 192.168.2.0/24 gw 10.0.0.5";
};
}

Caso você tenha alterado a linha passwd tux; referente à Filial1 no arquivo da Matriz, ela deve ser alterada aqui também.

Para iniciar o cliente da Matriz com a Filial1 execute:

# vtund Filial1Matriz “IPDAMATRIZ”

Obs: Respeite maiúsculas e minúsculas aqui caso o contrário o vtun irá retornar um erro.

Como já temos a Matriz e a Filial1 em funcionamento podemos testar esse túnel:

Testes a partir da Matriz:
ping 10.0.0.2
ping (para qualquer outro ip de alguma máquina interna a rede da Filial1)
route (que deve retornar entre as linhas e colunas):
Destino Roteador iface
192.168.4.0 10.0.0.3 tun0

Testes a partir da Filial1:
ping 10.0.0.1
ping (para qualquer ip de alguma máquina interna a rede da Matriz)
route (que deve retornar entre as linhas e colunas):
Destino Roteador iface
192.168.4.0 10.0.0.1 tun0

Para finalizarmos precisamos fechar o círculo fazendo a ligação da Filial2 com a Matriz e Filial1.

Vejamos o arquivo de Configuração da Filial2:

###Configuracao de um Servidor e cliente ao mesmo tempo####

#Configuracao Filial2 (10.0.0.5)

default {
type tun;
proto tcp;
compress lzo:9;
keepalive yes;
encrypt yes;
}

#Tunel entre Filial1 e Filial2 (10.0.0.4 <----> 10.0.0.5)
Filial1Filial2 {
passwd tux;
up{
ifconfig "%% 10.0.0.5 pointopoint 10.0.0.4";
route "add -net 192.168.4.0/24 gw 10.0.0.4";
};
down{
ifconfig "%% down";
route "del -net 192.168.4.0/24 gw 10.0.0.4";
};
}

###Configuracao Cliente da Filial2######

#Tunel entre Matriz e Filial2 (10.0.0.2 <-----> 10.0.0.6)

Filial2Matriz {
passwd tux;

up{
ifconfig "%% 10.0.0.6 pointopoint 10.0.0.2";
route "add -net 192.168.1.0/24 gw 10.0.0.2";
};

down{
ifconfig "%% down";
route "del -net 192.168.1.0/24 gw 10.0.0.2";
};
}

Se você analisar esse arquivo ele é uma mixagem do arquivo da Matriz com o arquivo da Filial1 o que irá mudar é apenas que ao executarmos o VTUN termos uma instância para o servidor que irá ficar aguardando a conexão da Filial1 e do cliente para a conexão com a Matriz.

Com o arquivo pronto assim como a matriz você irá precisar liberar a porta 5000 para o VTUN no firewall.

Exemplo:
# iptables –I INPUT –p tcp --dport 5000 –j ACCEPT

ou ainda:

# iptables –I INPUT –p tcp –s IPDAMATRIZ --dport 5000 –j ACCEPT

Para finalizarmos executamos o na Filial2 os comandos:

# vtund –s
# vtund Filial2Matriz “IPDAMATRIZ”

E ainda para fecharmos a comunicação da Filial1 com a Filial2 executamos na Filial1:

# vtund Filial1Filial2 “IPDAFILIAL2”

Testes que podem ser executados:

Testes a partir da Matriz:
ping 10.0.0.2
ping 10.0.0.6
ping (para qualquer outro ip de alguma máquina interna a rede da Filial1)
ping (para qualquer outro ip de alguma máquina interna a rede da Filial2)
route (que deve retornar entre as linhas e colunas):
Destino Roteador iface
192.168.4.0 10.0.0.3 tun0
192.168.2.0 10.0.0.6 tun1

Testes a partir da Filial1:
ping 10.0.0.1
ping 10.0.0.5
ping (para qualquer ip de alguma máquina interna a rede da Matriz)
ping (para qualquer ip de alguma máquina interna a rede da Filial2)
route (que deve retornar entre as linhas e colunas):
Destino Roteador iface
192.168.1.0 10.0.0.1 tun0
192.168.2.0 10.0.0.5 tun1

Testes a partir da Filial2:
ping 10.0.0.2
ping 10.0.0.4
ping (para qualquer ip de alguma máquina interna a rede da Matriz)
ping (para qualquer ip de alguma máquina interna a rede da Filial2)
route (que deve retornar entre as linhas e colunas):
Destino Roteador iface
192.168.1.0 10.0.0.2 tun0
192.168.4.0 10.0.0.4 tun1

Conclusão

Esse artigo foi um apanhado de conhecimentos colhidos na internet. Devido a diversas informações desencontradas e incompletas sobre o VTUN resolvi escrever e contribuir com a comunidade.
Alguns podem dizer que já existem soluções mais modernas no mercado para criação de túneis como o OpenVPN, no entanto o VTUN ainda é bastante usado, sendo que conhecimento nunca é demais.
Espero que tenham gostado.
Estou aberto a críticas e sugestões.
Abraços.

REFERÊNCIAS:

VIRTUAL tunnel. Disponível em: Acesso em: 25 jul. 2011.

COMO, configurar um túnel com Vtun. Disponível em: Acesso em: 26 jul. 2011.

Firewall rápido para o Ubuntu Desktop

2011-07-07T18:32:00.000-03:00

Introdução

Sabemos que o Ubuntu por padrão não vem com um firewall ativado. Segundo Morimoto (2009), esse fato se deve a política da própria Canonical em afirmar que a configuração padrão dos serviços no Ubuntu são suficientemente seguras não necessitando de um firewall ativo. No entanto como escrito "serviços padrões", nada impede que o usuário instale novos softwares como servidores ssh ou vnc, sem ao mesmo saber ao certo o que está fazendo, abrindo "portões" no sistema. Sendo assim como o ditado que diz que o "seguro morreu de velho" não custa nada criarmos um pequeno script de firewall carregado durante a inicialização do sistema adicionando uma camada extra de segurança.

Começando do começo

Abra um terminal e cria um arquivo com o nome de firewall em /etc/init.d, seguindo os comandos abaixo:

sudo gedit /etc/init.d/firewall

Copie e cole o seguinte conteúdo ao arquivo:

#!/bin/bash

# Script modificado por Irineu T. Nunes

firewall_start(){

# Abre para a interface de loopback.
iptables -A INPUT -i lo -j ACCEPT

##################################################
#PROTECOES
##################################################

# Ignora pings
echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all

# Protecao contra IP spoofing
echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter

# Protege contra synflood
echo "1" > /proc/sys/net/ipv4/tcp_syncookies

# Protecao contra ICMP Broadcasting
echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

# Protecao contra ICMP Timestamp
iptables -I INPUT -p icmp --icmp-type timestamp-request -j DROP

# Bloqueia traceroute
iptables -A INPUT -p udp --dport 33435:33525 -j DROP

# Protecoes diversas contra portscanners, ping of death, ataques DoS, etc
iptables -A INPUT -m state --state INVALID -j DROP

#####################################################

##########################
#Coracao do firewall
##########################

#Bloqueia qualquer regra que nao tenha sido liberada acima.
iptables -A INPUT -p tcp --syn -j DROP
iptables -A INPUT -p udp --dport 1:32000 -j DROP

#Bloqueia protocolo ipv6

#TCP
ip6tables -A INPUT -p tcp --syn -j DROP
ip6tables -A OUTPUT -p tcp --syn -j DROP

#UDP
ip6tables -A INPUT -p udp --dport 1:32000 -j DROP
ip6tables -A OUTPUT -p udp --dport 1:32000 -j DROP

#ICMPv6
ip6tables -A INPUT -p icmp -j DROP
ip6tables -A OUTPUT -p icmp -j DROP
###########################################################

echo "O Firewall esta sendo carregado..."
sleep 1
echo "Firewall Carregado"
sleep 1
}

firewall_stop(){
iptables -F
iptables -t nat -F
iptables -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
echo 0 > /proc/sys/net/ipv4/ip_forward
echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_all
}

case "$1" in
"start")
firewall_start
;;
"stop")
firewall_stop
echo "O ITN-firewall esta sendo desativado"
sleep 2
echo "ok."
;;
"restart")
echo "O ITN-firewall esta sendo reiniciado"
sleep 1
echo "ok."
firewall_stop; firewall_start
;;
*)
iptables -L -n
esac

Em resumo esse arquivo bloqueia todas as conexões entrantes (permitindo apenas conexões originadas pela própria máquina), adiciona algumas proteções básicas contra escaneamentos e bloqueia completamente o protocolo IPv6 (Apesar de na maioria dos casos o protocolo IPv6 ainda não ser utilizado, ele já esta ativo por padrão em diversas distribuições e equipamentos de redes, muitas vezes a preocupação limita-se em bloquear o protocolo IPv4 esquecendo-se completamente da existência do IPv6).

Na linha iptables -A INPUT -p udp --dport 1:32000 -j DROP foram bloqueadas todas as conexões de entrada das portas 1 a 32000 do protocolo UDP. No entanto essa é uma medida bastante extrema. Caso você comece a notar problemas de conexões em softwares que utilizam o protocolo UDP (Torrents, por exemplo), ou mesmo situações de erros de navegação em sites, uma medida seria um bloqueio mais cauteloso das portas conhecidas:

iptables -A INPUT -p udp --dport 1:1023 -j DROP

Finalizando

Salve o arquivo e execute os seguintes comando no terminal:

chmod +x /etc/init.d/firewall

update-rc.d firewall defaults

/etc/init.d/firewall start

O primeiro comando da as permissões de execução para seu script firewall.
O segundo adiociona seu script a inicialização do sistema.
O terceiro inicia seu firewall para já ficar ativo :D.

Conclusão

Agora você pode dormir mais tranquilo, seu sistema já está com o firewall ativo em em plena atividade, podendo ainda ser implementadas novas regras como a liberação de algumas portas para acesso externo se autorizado por você, mas isso já é outra história. :D

Referências

MORIMOTO, Carlos Eduardo. Linux guia prático. Porto Alegre: Sul Editores, 2009.

Port Scan Attack Detector (Psad) com Iptables.

2011-07-07T11:31:00.000-03:00

Introdução

O administrador de redes dentro de uma empresa vem tornando-se cada vez mais importante e exigido quando falamos no quesito segurança. A necessidade que as empresas possuem de terem acesso as seus dados a qualquer hora e lugar onde o meio geralmente utilizado é a internet é que tornam a questão ainda mais importante e que faz com que os profissionais em redes percam noites sem dormir.

A internet é um meio público onde as informações trafegam livremente e que podem ser interceptadas por qualquer usuário mal intencionado utilizando-se das ferramentas certas.

Notícias sobre invasões de empresas que tiveram seus dados expostos e informações sigilosas roubadas são a cada dia mais frequentes. Diferente de algum tempo atrás onde um usuário (Cracker*) disposto a invadir um sistema necessitava de algumas horas e adquirir um conhecimento sólido de camadas de redes, protocolos e configurações para chegar à porta de um sistema e comprometê-lo, atualmente a facilidade da internet em se obter informações, ferramentas e explicações detalhadas sobre qualquer forma de invasão de um sistema fazem com que usuários (Script *) de fim de semana sem muito esforço consigam descobrir técnicas para varrer sua rede, detectar vulnerabilidades e utilizar o tutorial do “blog do fulano” para comprometer seu sistema causando transtornos e prejuízos inestimáveis.

Com o intuito de prevenir seu sistema de varreduras de usuários mal intencionados a procura vulnerabilidades surgiu entre outras a ferramenta OpenSource PSAD, que estarei abordando aqui a qual pode detectar, alertar e ainda bloquear tentativas de escaneamentos externos a sua rede.

*Hacker diz respeito ao usuário que estuda um sistema ou hardware de computador, procurar entender seu mecanismo e como ele funciona a fim de aperfeiçoa-lo. Ao contrário do que divulga a mídia onde o Hacker é o usuário que invade sistemas e os danifica, ela está se referindo na verdade ao Cracker. Um Hacker pode invadi um sistema a fim de apontar falhas a serem corrigidas no entanto jamais causará prejuízos ou roubo de informações sigilosas.

*Script antigamente denominado de Lamer é o usuário que apesar de não compreender exatamente como um sistema ou mecanismo funciona utiliza-se de ferramentas criadas por outros. Esses causam prejuízos, danificam sistemas com o único intuito de ganhar fama ou dinheiro.

Entendendo o funcionamento

O software Psad trabalha analisando os logs do Iptables em busca de tentativas de varreduras ao seu ip gerando alertas e bloqueando-as.

Abaixo temos uma figura que representa o funcionamento do PSAD:

Adaptado de Cipherdyne 2011.

Instalação e configuração:

Estaremos utilizando para configuração do Psad o sistema Ubuntu 10.10, no entanto ele pode ser instalado em qualquer distribuição bastando para isto executar pequenas alterações.

Para instalar

#apt-get install psad

O arquivo de configuração do Psad fica por padrão em /etc/psad/psad.conf possui muitas opções que podem ser testadas e adequadas as suas necessidades. Abaixo temos algumas que considerei mais importantes:

EMAIL_ADDRESSES itn@localhost;

EMAIL_ADDRESSES: configure aqui o endereço de e-mail para qual irá o aviso de detecção de varreduras. Nesse exemplo os avisos irão para o usuário “itn” da própria máquina local. Caso você possua um servidor de e-mails instalado basta modificar itn@localhost pelo seu e-mail e alterar a opção HOME_NET NOT_USED que evita que você continue a receber e-mails na caixa de entrada do seu usuário “itn”.

Dica: Se você estiver utilizando um servidor Linux, por exemplo, sem o X instalado você pode instalar o cliente de e-mails para o terminal mutt (#apt-get install mutt) e utilizar o comando mutt –z para ler os e-mails recebidos do Psad.

DANGER_LEVEL1 5; ### Number of packets.

DANGER_LEVEL2 15;

DANGER_LEVEL3 150;

DANGER_LEVEL4 1500;

DANGER_LEVEL5 10000;

DANGER LEVEL: É dividido em 5 níveis que representam a quantidade de pacotes enviado de terminado Ip dentro de um período de tempo. Por exemplo o valor 150 do nível 3 diz para o Psad que quando a quantidade de pacotes atingirem esse limite ele deve considerar como uma tentativa de varredura externa.

CHECK_INTERVAL 5;

CHEK_INTERVAL: representa o tempo em segundos em que os logs do iptables serão verificados em busca de varreduras.

Dica: Tenha bastante cuidado em configurar o DANGER_LEVEL uma vez que configurar para o Psad bloquear ou reportar tentativas de varreduras em LEVEL baixos como 1 e 2 podem causar problemas de conexões dos clientes reais uma vez que pacotes de dados são trocados constantemente entre clientes e servidores. Aconselho

IGNORE_PORTS tcp/3389, udp/53, tcp/22;

#IGNORE_PORTS NONE;

IGNORE_PORTS: uma das opções chaves para um bom funcionamento do Psad uma vez que você pode configura-lo para ignorar o tráfego de pacotes em determinadas portas. Imaginamos que você possui um servidor onde a porta 3389 possui um tráfego de pacotes relativamente alto. Esse simples fato poderia vir a causar falsos positivos ao Psad que poderia entender essa troca de pacotes intensa como uma tentativa de varredura ou invasão a sua rede. No entanto se você não precisa disponibilizar nenhuma porta aberta para acesso externo você pode utilizar tranquilamente a opção: IGNORE_PORTS NONE;

Você pode estar se perguntando. É para liberar as principais portas que utilizo do monitoramento do Psad, então qual o objetivo de utiliza-lo para monitorar minha rede? Resposta: As varreduras a redes são realizadas com software que enviam uma quantidade enorme de pacotes em diversas portas e em um curto espaço de tempo. Então o fato de você liberar algumas portas do monitoramento do Psad não irá impedi-lo de executar seu serviço, além de lhe dar uma proteção adicional contra falsos positivos.

IGNORE_INTERFACES eth1;

IGNORE_INTERFACES: opção bastante interessante para quem utiliza uma máquina que possui mais de uma interface de rede onde apenas delas está diretamente ligada a internet. Assim você pode configurar de quais placas os Psad irá monitorar o tráfego.

MIN_DANGER_LEVEL 4;

EMAIL_ALERT_DANGER_LEVEL 5;

MIN_DANGER_LEVEL, EMAIL_ALERT_DANGER_LEVEL: essas duas opções estão diretamente ligadas à opção DANGER LEVEL, a opção MIN_DANGER_LEVEL representa o nível mínimo que deve ser atingido para um arquivo de e-mail ser gerado e EMAIL_ALERT_DANGER_LEVEL é quando esse arquivo será efetivamente enviado.

ENABLE_AUTO_IDS Y;

AUTO_IDS_DANGER_LEVEL 4;

IPTABLES_BLOCK_METHOD Y;

AUTO_BLOCK_TIMEOUT 3600;

ENABLE_AUTO_IDS, AUTO_IDS_DANGER_LEVEL, IPTABLES_B LOCK_METHOD: opções chaves do Psad e que são um dos principais objetivos desse artigo. Com essas opções definidas como Y (ativadas), o nível determinado (4 no exemplo) o Psad irá bloquear todo o acesso do Ip que está executando a varredura em sua rede pelo tempo determinado em segundos (3600 segundos no exemplo.

Configurando o log do Iptables.

Precisamos configurar o Iptables para escrever em um log o movimento dos pacotes que estão passando pelo firewall. Para isso adicionamos os seguintes comandos no script do firewall:

iptables -A INPUT -j LOG

iptables -A FORWARD -j LOG

Edite o arquivo /etc/rsyslog.conf e adicione a seguinte linha ao final:

kern.info | /var/lib/psad/psadfifo

Liberando Ips do monitoramento do Psad.

Um outro arquivo de configuração interessante do Psad é o /etc/psad/auto_dl nele você pode definir quais Ips estão liberados do monitoramento do Psad bem como níveis para diferentes para ips específicos. Essa opção se torna muito útil no caso de você querer evitar bloqueios errôneos de Ips que fazem parte de um grupo confiável que acessa seu servidor.

Exemplo:

200.139.34.1 5;

200.139.34.2 3 tcp;

200.139.34.3 3 tcp/1-1024;

200.193.34.4 0;

No primeiro exemplo dizemos que o ip 200.139.34.1 deve ser tratado com o nível máximo (5) de atenção. No segundo exemplo o ip 200.193.34.2 é tratado com o nível 3 no entanto apenas para tráfego utilizando o protocolo tcp. Já o ip 200.193.34.3 apenas para o tráfego tcp entre as portas 1 e 1024. No último exemplo o ip 200.193.34.4 será excluído do monitoramento do Psad sendo isso representado pelo nível 0.

Conclusões

O Psad é um ferramenta de muito poderosa que pode evitar grandes dores de cabeça inibindo ataque diversos a sua rede e evitando que seu sistema seja comprometido. No entanto o Psad não elimina de maneira alguma a necessidade de um boa configuração de firewall, ele apenas adiciona mais uma camada de proteção e monitoramento ao sistema. Monitore continuamente as mensagens do Psad e implemente sempre atualizações e novas proteções ao seu firewall.

Espero que aproveitem o artigo. Sugestões pelo e-mail itnp@msn.com.

REFERÊNCIAS:

PSAD (Linux) detectar e bloquear ataques port scan em tempo real. Disponível em: < http://segurancalinux.com/artigo/PSAD-%28Linux%29-detectar-e-bloquear-ataques-port-scan-em-tempo-real > Acesso em: 05 jun. 2011.

PSAD: Intrusion Detection and Log Analysis with iptables. Disponivel em: < http://cipherdyne.org/psad/ > Acesso em: 05 jun. 2011.

2011-03-30T21:37:00.000-03:00

MONITORANDO O TRÁFEGO DO MSN NA REDE COM MSN-PROXY

Apresento aqui a instalação e configuração do msn-proxy um software desenvolvido por uma equipe brasileira que possibilita o controle de todo o tráfego do MSN em uma rede. Possui opções como bloqueio por contato, monitoramento de mensagens, bloqueio de usuários entre outras funcionalidades.

Para esse tutorial foi utilizado o Ubuntu 10.10 e o Msn-proxy 0.7, no entanto com algumas pequenas modificações ele pode ser aplicado em qualquer distribuição derivada do Debian. Uma observação a fazer é que nos testes é que com o Mns-proxy 0.7 (ultima versão até a data desse tutorial) o Windows Live Messenger 2011 não conseguiu conectar-se na rede. No entanto funcionou perfeitamente com os clientes Windows Live Messenger 2009, Emesene e Amsn 0.98.

Preparando o ambiente

Alguns servidores e bibliotecas são pré requisitos para a configuração do msn-proxy. Partindo da idéia que servidores como o Apache e o Mysql ainda não estão instalados, precisaremos fazer a instalação dos pacotes necessários executando os comandos abaixo:

$ sudo su

# apt-get install php5 libapache2-mod-php5 php5-gd php5-imagick php5-mysql

# apt-get install apache2

# apt-get install mysql-server phpmyadmin

Obs: Nesse tutorial utilizaremos a senha do servidor Mysql como sendo “root”, mas nada impede que você utilize uma outra senha.

Dica: Quando questionado sobre qual servidor Web utilizar para o Phpmyadmin selecione o apache2.

Quando questionado sobre a criação da base da dados para o phpmyadmin responda “Sim” e na caixa de configuração do phpmyadmin insira a mesma senha configurada no mysql (que em nosso exemplo é “root”), utilizar a mesma senha ajudar a evitar esquecimentos posteriores.

# apt-get install make gcc g++ libevent-dev
# apt-get install -f libmysqlclient15-dev

Edite o arquivo /etc/php5/apache2/php.ini e altere seu conteúdo para:

safe_mode = On
safe_mode_gid = On
register_globals = On
display_errors = On

Baixando e instalando o msn-proxy:

Faça o download do msn-proxy em:

http://sourceforge.net/projects/msn-proxy/

Descompacte o arquivo baixado:

$ tar zxvf msn-proxy-0.7
$ cd msn-proxy

Comente as linhas do FreeBSD e altere as do Linux no arquivo Makefile do msn-proxy para:

MYSQLINC=/usr/lib/mysql
MYSQLLIB=/var/lib/mysql/mysql

Execute a instalação:

$ make
$ sudo su
# make install

Configurando o ambiente do mysql para o msn-proxy:

Com o msn-proxy já instalado algumas alterações de arquivos, assim como a criação da base do msn-proxy no mysql será necessária.

Prepare a acesso ao msn-proxy:

# mkdir /var/www/msn-proxy
# cp -R php /var/www/msn-proxy/

Altere as linhas do arquivo /var/www/msn-proxy/php/mysql.inc.php para:

$host = "localhost";
$user = "root";
$pass = "root";
$db = "msn-proxy";
$port = 3306;

Altere o arquivo /usr/local/etc/msn-proxy/mysql/conf para:

Crie um banco com o nome de msn-proxy no mysql:

# mysql -p

(e digite a senha do administrador do banco de dados: "root");

mysql> CREATE DATABASE `msn-proxy`;
mysql> quit

Execute o seguinte comando afim de fazer um pequeno teste:

/usr/local/bin/msn-proxy

Se tudo estiver certo o comando anterior irá reportar a seguinte mensagem:
fail to read mysql config (check defaults table)

Mude as permissões do arquivo /usr/local/etc/msn-proxy/mysql/conf

# chmod 600 /usr/local/etc/msn-proxy/mysql/conf

Dica: Você pode editar o arquivo /usr/local/etc/msn-proxy/msn-proxy.conf que além de outras opções permite especificar o máximo de usuários que serão controlados na rede:

-> max_clients=10 #Essa linha indica a quantidade de usuários monitorados.

Precisamos agora cadastrar no banco o ip da placa que está distribuindo a internet com para rede local. Considerando que no exemplo esse ip seja 192.168.1.1, executamos seguintes comandos:

# mysql -p

(e digite a senha do administrador do banco de dados: "root");

mysql> use msn-proxy;
mysql> INSERT INTO `defaults` ( `internal_host` , `connect` , `save_msg` , `save_contacts` , `commands` , `warnemail` , `warndn` , `warnmsg` , `msgfont` , `msgcolor` ) VALUES ('192.168.0.1', 'YES', 'YES', 'YES', '0', 'itnp@msn.com', 'Irineu Teza Nunes', 'Para sua segurança esta mensagem esta sendo monitorada.', 'Arial', 'black');

Você pode verificar se os dados foram gravados com o seguinte comando:

mysql> SELECT * FROM `defaults`;

Se a resposta do comando for como está (tudo ok):

+---------------+---------+----------+---------------+----------+--------------+--------------------------+----------------------------------------------------------+---------+----------+

+---------------+---------+----------+---------------+----------+--------------+--------------------------+----------------------------------------------------------+---------+----------+

| 192.168.1.1 | YES | YES | YES | 0 | itnp@msn.com | Irineu Teza Nunes | Para sua segurança esta mensagem esta sendo monitorada. | Arial | black |

+---------------+---------+----------+---------------+----------+--------------+--------------------------+----------------------------------------------------------+---------+----------+

1 row in set (0.00 sec)

Saia do banco de dados:

mysql> quit

Direcionando tráfeco do msn

Utilizando o iptables direcione todo o tráfico da porta 1863 para o proxy-msn inserido a seguinte linha em seu firewall:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 1863 -j REDIRECT --to-port 1863 #Onde eth0 é sua interface de rede local.

Para iniciar o proxy execute o seguinte comando:

# /usr/local/bin/msn-proxy &

Ou:

# /usr/local/bin/msn-proxy -d &

Dica: Com a opção -d irá ser possível visualizar os logs de saída.

Você também pode criar um pequeno script e configurá-lo para iniciar automaticamente o MSN-proxy criando o seguinte arquivo /etc/init.d/msn-proxy.sh e adicionando o seguinte conteúdo:

#!/bin/bash
/usr/local/bin/msn-proxy &
echo "MSN-Proxy Inicializado"

De as permissões e configure-o para iniciar automaticamente:

# cd /etc/init.d/
# chmod 755 msn-proxy.sh
# update-rc.d msn-proxy.sh defaults

Após iniciar o msn-proxy caso você pode acessar sua interface digitando o seguinte endereço em seu navegador:

http://localhost/msn-proxy/php/index.php

A interface é bastante intuitiva e organizada, apresentando diversas opções e todas as configurações necessárias para o monitoramento.

Finalizando esse tutorial deixo aqui meus parabéns a todos os desenvolvedores do MSN-proxy. Realmente foi feito um trabalho primoroso e bem executado. Além disso o desenvolvimento continua, onde novos recursos são adicionados e outros melhorados.

Irineu Teza Nunes.

REFERÊNCIA:

Rudimar. MSN-Proxy no Debian Etch. E-mail: rudimar@remontti.com.br. Disponível em: http://www.vivaolinux.com.br/artigo/MSNProxy-no-Debian-Etch-1

2011-03-28T11:28:00.000-03:00

COMPARTILHANDO SCANNERS NO UBUNTU 10.10

Da mesma forma que conseguimos compartilhar uma impressora na rede, com o linux abre-se ainda mais as possibilidades e é possível também o compartilhamento de scanners com alguns passos simples.Aqui estarei descrevendo como compartilhar uma impressora em um servidor linux e acessar via clientes Windows. Foi utilizando em neste exemplo o Ubuntu 10.10 Server, no entanto esse tutorial deve funcionar sem problemas em qualquer distribuição debian.

Configurando o Servidor

No caso do Ubuntu é necessário que os pacotes xinetd e sane-utils estejam instalados. Podemos fazer isto executando o apt-get como root.

# apt-get install xinetd sane-utils

Após a instalação dos pacotes execute o comando:

scanimage -L

Esse comando irá listar todos os scanner instalados no sistema.

Para ativar o compartilhamento é efetuado a configuração de alguns arquivos.

Edite o arquivo /etc/services e adicione a seguinte linha:

sane-port 6566/tcp

Edite o arquivo /etc/xinetd.conf coloque a seguinte linha:

sane-port stream tcp nowait saned.saned /usr/sbin/saned saned

Em seguida, precisamos configurar o xinetd para usar o saned. Isto é feito criando o arquivo /etc/xinetd.d/sane-port com o seguinte conteúdo:

service sane-port {
socket_type = stream
server = /usr/sbin/saned
protocol = tcp
user = saned
group = saned
wait = no
disable = no
}

Com o compartilhamento já configurado precisamos definir quem tem a permissão de acessar o scanner na rede. Precisamos para isso descomentar uma das linhas do arquivo /etc/sane.d/saned.conf e adicionarmos duas novas linhas:
Descomente essa linha:
scan-client.somedomain.firm

Adicione duas novas linhas:
192.168.0.0/24
127.0.0.0/8

O endereço de rede 192.168.0.0/24 permite que todos os computadores com IP entre 192.168.0.1 a 192.168.0.254 acessem o scanner. E o 127.0.0.0/8 representa o endereço loopback (endereço para acesso local do scanner). Claro que se sua rede estiver configurada com um endereço diferente o primeira linha deve ser alterada (ex 192.168.1.0/24).

Agora precisamos apenas adicionar o “usuário saned” ao grupo root e lp para tanto altere as linhas do arquivo /etc/group para:

root:x:0:saned
lp:x:7:saned
saned:x:16:root

Obs.: Tenha bastante cuidado em alterar esse arquivo pois ele é vital para o funcionamento do sistema.

Agora basta reiniciar o xinetd e o scanner estará compartilhado:

/etc/init.d/xinetd restart

Agora vamos mostrar como configurar os clientes Linux e Windows

Configurando os Clientes

Aqui é a parte mais fácil do serviço. Baixe o link abaixo o software SanetTwain:

http://sanetwain.ozuzo.net/downloads/sanetwain130.zip

Descompacte o arquivos em um diretório qualquer e execute o arquivo Scanimage.exe.

Inicialmente teremos a seguinte tela de configuração:

Nome do servidor: O ip do servidor onde o scanner foi compartilhado. No meu exemplo 192.168.0.1

Porta: A porta onde o servidor saned foi compartilhado o padrão é 6566

Nome do usuário: O nome do usuário que tem permissões de scannear via rede. No exemplo saned.

Está pronto. Basta executar um scanner para fins de teste.

Espero que tenham gostado.

Irineu Teza Nunes.

REFERÊNCIA:

RIBEIRO, Marcos Roberto. Compartilhamento de scanner no linux. Disponível em: http://ultramarcosribeiro.blogspot.com/2008/10/compartilhamento-de-scanner-no-linux.html

Chat em Java Eeboo

2010-10-20T15:03:00.000-02:00

Chat em Java Eeboo

Projeto de final de semestre executado em parceria dos colegas Henrique Martins, André Cândido e Valdenir , desenvolvimento de um chat utilizando apenas a linguagem Java. Na versão atual já é possível a criação de chats privados e envio de textos coloridos.

O código tem muito a ser aperfeiçoado afinal era apenas para ser um trabalho para mostrar a utilização de sockets em Java. Projeto iniciado por um grupo de alunos do 4º semestre de Sistemas de Informação sem qualquer experiência em programação. No entanto novas idéias surgiram e gostaríamos de convidar a todos que tenham interesse em criar novos recursos, contribuir com idéias, alteração, aperfeiçoamento do código, ou simplesmente testar, a participarem.

Pontos fracos do chat:

* A comunicação é baseada toda em String, é preciso adaptá-lo para utilizar pedidos e respostas em bytes, além de criptografia de dados.

* Lentidão de respostas, devido à forma como são enviadas as mensagens. As mensagens são enviadas em filas um usuário por vez, e não é enviada ao outro usuário enquanto o anterior não receber.

Algumas idéias de recursos a serem adicionados:

* Envio de arquivo.
* DCC Chat (Chat privado direto entre usuários).
* Envio de emotions.
* Conversa com áudio e webcams.
* Adição de imagens personalizadas dos usuários conectados.

Você pode baixar o cliente e o servidor compilado em:

Cliente
http://www.4shared.com/file/LcFY2UgN/Chat_22-10.html

Obs: Salve o audio1.mp3 no c:\ (para sistemas Windows) da sua máquina.

Servidor

http://www.4shared.com/file/eRXfmNRS/Servidor_22-10.html

Você pode baixar o código fonte pronto para ser alterado pelo Eclipse em:

http://www.4shared.com/file/P1kSFjvr/Codigo_Eclipse.html

Observações:

*Você irá precisar ter o Visual Editor configurado dentro do Eclipse;
*Descompacte os arquivos e direcione o Eclipse para pasta onde os arquivos foram descompactados.

Postem aqui links com novas versões, códigos, idéias, detecção de bugs, etc.

Abraços!

Irineu Teza Nunes.

BLOQUEANDO O ULTRASURF E O WEBMESSENGER DO HOTMAIL COM PROXY TRANSPARENTE (ATUALIZADO PARA O ULTRA SURF 10.05)

2010-09-12T10:42:00.000-03:00

O UltraSurf é um pequeno utilitário capaz de burlar um proxy e permitir acesso a sites bloqueados, e que tem sido cada vez mais utilizado em bibliotecas, faculdades e escolas.
O UltraSurf utiliza-se de diversos servidores para conexão feitas pela porta SSL 443. Como é de se supor bastaria bloquear a porta 443 que o UltraSurf não mais se conectaria. Ai é que está o problema e a grande façanha do UltraSurf, essa porta 443 é utilizada para as conexões seguras como a de bancos, do Messenger e do próprio Orkut. Bloqueando essa porta você irá bloquear todo o acesso a esses sites.

PARA INICIO:

O tutorial abaixo foi aplicado a seguinte situação:

*Usuários podem ter acesso ao Messenger e sites de bancos e seguradoras todo o resto do tráfico pela porta 443 deve ser bloqueada incluindo nessa situação o UltraSurf. Alguns usuários tem acesso sem restrições a tudo.

A forma mais eficiente para bloquear o UltraSurf é o bloqueio de todo tráfico da porta 443 e liberação dessa porta apenas para URLs pré-determinadas. Isto porque o UltraSurf está constantemente atualizando sua lista de Ips para conexão e bloquear todos eles torna-se mais dispendioso do que bloquear tudo e liberar apenas o necessário.

Passo 1:

Adicione a seguinte regra ao seu firewall (Obs: Adicione essa regra antes de qualquer outra).

##############################
# BLOQUEIO DE PORTAS SSL 443
##############################

#Libera acesso aos bloqueados a urls especificas
#Bloqueia toda a requisição a porta 443
iptables -I FORWARD -p tcp --dport 443 -j DROP

#Bloqueia a nova porta utilizada pelo UltraSurf 10.05

iptables -I FORWARD -p tcp --dport 25101 -j DROP

#Define o local onde está o arquivo com a lista de URLs liberados para a porta 443
for URL in `grep -v "^#" /etc/squid/liberados_443`; do
#Libera o acesso a toda a rede para a lista de URLs definidas
iptables -I FORWARD -p tcp --dport 443 -d $URL -j ACCEPT
done

#Libera acesso total ao ssl 443
#PC-01
#Permite o acesso a porta 443 pelo ip em questão sem qualquer restrição
#adicione os endereços ips que você não pretende restringir o acesso ao UltraSurf.
iptables -I FORWARD -s 192.168.0.2 -p tcp --dport 443 -j ACCEPT

Obs: Regra adaptada do post de Jorge Informática disponível em:
http://www.brazilfw.com.br/forum/viewtopic.php?f=2&t=68610&start=0

Passo 2:

Crie um arquivo liberados_443 e adicione todos os ips das URLs em que o acesso à porta 443 será permitido. No meu caso o arquivo encontra-se dentro de “/etc/squid”, no entanto ele pode ser colocado em qualquer lugar para isso basta modificar a linha:

for URL in `grep -v "^#" /etc/squid/liberados_443`; do

com a nova localização do arquivo.

Exemplo abaixo de um arquivo liberados_443

#################################################
#ORKUT
64.233.160.0/19
64.233.163.0/24
209.85.128.0/17
74.125.0.0/16
72.14.192.0/18

#MSN
69.192.24.0/24

#Novo Hotmail 11-09-2011
65.54.186.0/24
65.54.204.0/24
65.54.165.0/24
216.246.75.0/24

#MSN Embutido no Hotmail 11-09-2011
173.222.141.0/24

#CENTRAL DE UPDATE WINDOWS
65.55.13.0/24

#########BANCOS################
#BANCO DO BRASIL
170.66.2.0/24
170.66.1.0/24

#CAIXA ECONOMICA
200.201.169.0/24
200.201.173.0/24

#ITAU
200.196.152.0/24

#BRADESCO
200.155.86.0/24

#BRADESCO FINANCIAMENTOS
200.155.80.0/24
####################################################

Como descobrir o ip a ser liberado para adicionar a lista?

Baixe um programa monitor de rede, no exemplo utilizei o networx.

Link do networx:
http://www.softperfect.com/download/

Utilize o recurso Netstat para monitorar o tráfico:

Acesse o site que você pretende liberar, e verifique o ip que está sendo acessado pela porta 443.
No exemplo temos o ip 170.66.1.60 que corresponde ao ip do Banco do Brasil. Ao adicionar no arquivo adicione da seguinte maneira 170.66.1.0/24 isso irá liberar toda a faixa de ip de 170.66.1.1 a 170.66.1.254 o que se torna interessante uma vez que geralmente os domínios utilizam mais de um ip de terminada faixa para acessos a serviços.
Observe que esses ips podem mudar com o tempo precisando ser atualizada a lista.

BLOQUEIO DO WEBMESSENGER DO HOTMAIL.

Veja que no arquivo de exemplo liberados_443 temos a seguinte faixa de ip:

#MSN Embutido no Hotmail 11-09-2011
173.222.141.0/24

Esse é justamente a faixa de ip utilizada pelo WebMessenger do Hotmail para acesso. No meu exemplo estou liberando o acesso a esse serviço, caso queria bloqueá-lo basta comentar essa linha.

CONCLUSÃO

Seguindo o exemplo desse tutorial não iremos nos preocupar mais com o UltraSurf ou qualquer outro software semelhante (pelo menos enquanto utilizarem a porta 443). O grande dificuldade realmente está no fato de ter que adicionar os ips de todas as URLs a serem liberadas que dependendo da quantidade de sites exigirá um trabalho bastante dispendioso. Por outro lado depois disso você só irá precisar fazer pequenas atualizações de ips que venham a mudar ou adicionar novos ips a serem liberados no arquivo liberados_443.
Como nem tudo é maravilha dependendo a quantidade de ips adicionados a lista o firewall irá demorar um pouco mais para aplicar todas as regras e a acesso a os sites liberados irá ficar ligeiramente mais lento. “É uma questão de preço benefício” :D.

Espero que tenham gostado desse meu primeiro post. Comentem:

Abraços.

Irineu Teza Nunes.