Visita ao site do apache, leitura de documentação, busca no google…

“Ok, já posso por a mão na massa.”

Ledo engano. O apache2 não autenticava o usuário nem a pau. O log do openldap mostava a consulta sendo feita, o repositório estava com as permissões corretas para www-data.

“Tá bom, vou ler a documentação novamente.”

Após algumas horas de pesquisas na internet, consegui fazer a integração. Vejamos todos os passos.

Ambiente

• Servidor Subversion e apache2;
• Servidor OpenLDAP;
• Svn com vários repositórios, permissões de arquivos via OpenLDAP;
• Controle via grupos.

Configuração do repositório

O usuário www-data precisa ter acesso aos arquivos do repositório. Então supondo que sua base seja /var/svn/repo01, precisamos garantir as permissões com o comando:

cd /var/snv/repo01
chown -R www-data:grupo1
find repo01/ -type f -print -exec chmod 660 {} \;
find repo01/ -type d -print -exec chmod 2770 {} \;


Assim, apenas o www-data e os usuários do grupo terão acesso aos arquivos. Além disso, estamos setando o bit SGID nos diretórios, para que os arquivos criados também sejam do grupo.

Configuração do apache2

No apache 2.2.x, o módulo utilizado para autenticação via ldap é o mod_authnz_ldap. Iremos precisar do módulo dav_svn (pacote libapache2-svn). Habilite-os com o a2enmod.

Crie o arquivo do site em /var/apache2/sites-available/repo01. O conteúdo deve ser mais ou menos assim:

<VirtualHost *:80>
ServerAdmin administrador@seudominio.com.br
ServerName svn.seudominio.com.br
DocumentRoot /var/www/
ErrorLog /var/log/apache2/repo01/error.log
LogLevel notice
CustomLog /var/log/apache2/repo01/access.log combined
<Location /svn/repo01>
#habilita o repositorio
DAV svn
# caminho para o repositorio
SVNPath /var/svn/repo01
# tipo de autenticacao
AuthType Basic
# identificação do repositorio
AuthName "Repositorio SVN"
# provedor de autenticacao
AuthBasicProvider ldap
# Está on porque se a autenticação via ldap falhar, não deve pesquisar outras bases
AuthzLDAPAuthoritative on
# URL da base LDAP. O ?uid especifica atributo pesquisar (uid)
AuthLDAPURL "ldap://ldap.seudominio.com.br/ou=Usuarios,dc=seudominio,dc=com,dc=br?uid"
# Informa que atributo usar para verificar se o usuario faz parte do grupo ou não
AuthLDAPGroupAttribute memberUid
# especifica que a busca deve ser feita por usuario, e nao pelo DN
AuthLDAPGroupAttributeIsDN off
#usuario que irá fazer a consulta no ldap
AuthLDAPBindDN "cn=subversion,dc=seudominio,dc=com,dc=br"
#senha do usuario acima
AuthLDAPBindPassword "senha"
# grupos que terão acesso ao repositorio
Require ldap-group cn=repo01,ou=Grupos,dc=seudominio,dc=com,dc=br
</Location>
</VirtualHost>

Habilite o site com o a2ensite, recarregue o apache2 e pronto, seu apache2 está acessando o repositório svn e autenticando via openldap.

Agradecimentos ao faw, que me ajudou a debugar o problema e a encontrar a solução.

Um exemplo seria alguém enviar um email interno (após ter se autenticado corretamente), se passando pelo chefe (crianças, não tentem fazer isso em casa sem a supervisão de um adulto).

vejamos:

…
235 2.0.0 Authentication successful
mail from:<chefe@seudominio.com>
250 2.1.0 Ok
rcpt to:<vitima@seudominio.com>
data
Assunto: vc foi promovido
A partir do mês que vem você receberá o dobro do salário! Parabéns!
.
250 2.0.0 Ok: queued as 2C702C192C8
quit

E então o servidor aceitou a mensagem, e seu amigo ficou feliz por alguns minutos, antes de ser avisado que era uma brincadeira.

Corrigindo o relay

Essa dica se destina a quem usa uma solução de correio com postfix, sasl, mysql, etc. Vou assumir que você já tem a solução instalada e que entende os conceitos que irei utilizar. Caso você não esteja familiarizado, um tutorial legal de como instalar e integrar a solução pode ser lido no vivaolinux.

Primeiramente devemos fechar o relay interno. Apenas usuários autenticados e o próprio servidor de correio devem enviar emails.

Para isso, no arquivo main.cf, acrescente a seguinte linha:
mynetworks_style = host

Assegure-se de que a variável mynetworks não exista, ou então esteja comentada.

Como você é uma pessoa cuidadosa e está utilizando autenticação via SASL (você está né?), o seu campo smtpd_recipient_restrictions deve ser parecido com:
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, etc

Verificando o campo MAIL FROM

Esse foi o que deu mais trabalho. Caso um remetente do seu domínio seja fornecido – quer exista ou não – por padrão o postfix tenta enviar a mensagem para o destinatário. A partir do postfix 2.1, existe o controle reject_sender_login_mismatch, que irá fazer a verificação do usuário autenticado via SASL, e ver se o mesmo bate com os autorizados para ele.

A autorização é feita via tabelas, utilizando o controle smtpd_sender_login_maps, que no meu caso utiliza o mysql, mas vc pode usar hash, ldap, etc.

Seria algo parecido com:

smtpd_sender_login_maps = mysql:/etc/postfix/access.cf

E então no campo smtpd_sender_restrictions, vc acrescenta a verificação:
smtpd_sender_restrictions = reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_unauthenticated_sender_login_mismatch,
reject_sender_login_mismatch

o arquivo access.cf:

user=postfix-user
password=senha
dbname=postfix
table=mailbox
select_field=username
where_field=username
hosts=localhost

Voilá! Agora o usuário só envia email se estiver autenticado,
e somente se o MAIL FROM corresponder com o usuário logado!

Anote essa data no seu calendário.  Ultima sexta-feira do mês de Julho. Nunca se esqueça deste dia, sobre pena de ter sua conta bloqueada, seu acesso limitado, seus emails misteriosamente apagados. Por que?

Bem,  porque neste dia celebra-se o “System Administrator Appreciation Day. Se até o saci pererê tem o seu dia, por que não nós, que aturamos centenas, milhares e as vezes milhões de usuários reclamões?

Seja um BOFH, seja um administrador bonzinho,  os sys admin são figuras essenciais para o funcionamento do Universo,

e muitas vezes são negligenciados, não valorizados.

Mas nem de lamentações vivemos. Uma profissão desafiante, com novidades a cada dia, com uma dinâmica única. E por que não dizer divertida?

Para todos os meus amigos sys admins, um feliz dia!

Instalação

#aptitude install pflogsumm

Configuração

Como iremos gerar relatórios diários e não desejamos que os dados sejam repetidos, precisamos configurar o logrotate. Edite o arquivo /etc/logrotate.conf, acrescentando as seguintes linhas:

/var/log/mail.log {
missingok
daily
rotate 7
create
compress
start 0
}

Agora precisamos criar um script em shell para executar o pflogsumm. Segue um exemplo:

#!/bin/sh
# retirado de http://www.howtoforge.com/mailgraph_pflogsumm_debian_etch
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
gunzip /var/log/mail.log.0.gz

pflogsumm /var/log/mail.log.0 | formail -c -I”Estatisticas de Email” -I”From: pflogsumm@correio” -I”To: postmaster@meudominio.com.br” -I”Received: from correio.meudominio.com.br ([192.168.0.100])” | sendmail postmaster@meudominio.com.br

gzip /var/log/mail.log.0
exit 0

Salve-o em /usr/local/sbin/plogsumm.sh, tornando executável (chmod 755)
Por último, adicionaremos o script acima ao crontab, para rodar diariamente. Execute o comando crontab -e, adicionando as seguintes linhas no arquivo:

0 7 * * * /usr/local/sbin/pflogsumm.sh &> /dev/null

Com este conjunto de ferramentas, mencionado nessa série de artigos, você será capaz de saber tudo o que acontece com o seu servidor de email, no tocante ao tráfego de mensagens.

Instalação

#aptitude install mailgraph rrdtool
O aptitude irá cuidar das dependências necessárias.

Configuração

O debconf irá fazer as seguintes perguntas:
- O mailgraph deverá ser inicializado no boot? (responda sim)
- Arquivo de log usado pelo mailgraph (responda /var/log/mail.log)
- Contar e-mails que foram recebidos como e-mails que foram enviados? (se você usa algum filtro de conteúdo, como amavis, responda não)

Precisamos agora configurar o apache2. O arquivo cgi do mailgraph fica em /usr/lib/cgi-bin/mailgraph.cgi. Abaixo temos um exemplo de configuração, que deve ser acrescentada no arquivo /etc/apache2/sites-enabled/default:

ScriptAlias /mailgraph/ “/usr/lib/cgi-bin/”
[Directory "/usr/lib/cgi-bin/"]
Options MultiViews FollowSymLinks
AllowOverride AuthConfig
Order deny,allow
Allow from all
Allow from 172.17.20.204/255.255.0.0
Deny from all
[/Directory]Após realizar as devidas configurações, basta forçar o apache a reler o arquivo:
#/etc/init.d/apache2 reload

De acordo com o exemplo, acesse o mailgraph em http://servidor/mailgraph/ . Abaixo um exemplo dos gráficos gerados.

Veja também:
Monitorando o servidor de email: isoqlog

O primeiro deles é o isoqlog. Trata-se de um analizador de logs escrito em C, capaz de “entender” vários MTA’s, entre eles postfix e exim. Através de uma interface web, poderemos ter um sumário do que está trafegando por nosso servidor.

Instalação

aptitude install isoqlog

O debconf irá perguntar pelo:
- MTA utilizado;
- Diretório web a ser utilizado:
- Nome da máquina local (FQDN);
- Idioma (português está disponível);
- Domínio a ser analisado.

Configuração

O isoqlog possui dois arquivos de configuração, que ficam em /etc/isoqlog.
O arquivo isoqlog.domains lista os domínios a serem analisados, um por linha.
O arquivo isoqlog.conf é o arquivo de configuração principal, e deve se parecer com o exemplo abaixo:

#isoqlog 2.0 Configuration file

logtype = “postfix”
logstore = “/var/log/mail.log”
domainsfile = “/etc/isoqlog/isoqlog.domains”
outputdir = “/var/www/isoqlog”
htmldir = “/usr/share/isoqlog/htmltemp”
langfile = “/usr/share/isoqlog/lang/portuguese”
hostname = “servidor.meudominio.com..br”

maxsender = 100
maxreceiver = 100
maxtotal = 100

maxbyte = 10

Apache

Configure o servidor web segundo seus critérios de segurança, de modo que você possa acessar a pasta informada em outputdir.

Cron

Adicione a linha abaixo em sua crontab, de modo que o comando seja executado de hora em hora.
59 * * * * isoqlog 1>/dev/null 2>/dev/null

Execute o comando isoqlog. Ele irá gerar as páginas com os dados do servidor. Para acessar, informe o endereço no seu navegador: Um exemplo pode ser visto no site do desenvolvedor. Apesar de não ter uma interface muito agradável, é uma boa ferramenta de gerenciamento.

No próximo artigo iremos aprender a utilizar o mailgraph. Aguarde!

É uma ferramenta fácil de configurar, que ajuda bastante. Possui suporte a chaves ssh, assim basta criar uma e enviar aos seus servidores que o acesso a eles será bem mais prático.

Vejamos como instalar o SSHMenu. Primeiramente, adicione o repositório abaixo no seu arquivo sources.list:
deb http://www.mclean.net.nz/debian stable contrib

Faça um aptitude update para atualizar a base, e em seguida, digite aptitude install sshmenu-gnome

Ele irá instalar algumas dependências, como bibliotecas ruby.

Depois basta acrescentá-lo em seu painel (clique com o botão direito no painel, selecione adicionar ao painel e em seguida SSH Menu Applet) , adicionar seus servidores e pronto! Você terá poupado vários cliques do seu dia-a-dia, bem como tempo.
Com o SSHMenu você pode criar submenus para executar tarefas específicas no servidor. No meu caso, eu criei um submenu para o meu servidor firewall que já abre direto shell rodando um tail do arquivo de log de conexões.

Caso você tenha uma dica de uso interessante para o SSHMenu, ou conheca uma outra ferramenta interessante, deixe o seu comentário.

Sucesso total. Na verdade, fiquei impressionado. Apesar dos problemas técnicos que levaram ao atraso da palestra em 20 minutos, a sala estava completamente lotada. Inclusive os corredores laterais, com as pessoas sentando no chão. Alguns amigos inclusive me reclamaram depois dizendo que não conseguiram ver a palestra porque o segurança não deixou, devido a quantidade de gente na sala. Que bom que o tema despertou tanta atenção.
Ela também foi transmitida pela internet via TV Software Livre, e pelo que algumas pessoas me disseram, nessa hora o streaming estava funcionando e elas conseguiram ver.

A gravação deverá estar pronta e liberada pela organização em alguns meses. Quando eu a tiver, liberarei aqui também.
Falando um pouco da palestra, minha intenção foi traçar um paralelo entre as orientações feita por Sun Tzu no livro A arte da guerra e as atividades de um Administrador de Sistemas. Segue a descrição que costumo dar, ao submeter a palestra ou ser convidado para algum evento:

Ao escrever no Sec IV A.C A Arte da Guerra, Sun Tzu visava instruir sobre como o Estado poderia prosperar através da guerra. Nos dias de hoje, as citações de Sun Tzu deixaram de atuar apenas na esfera militar, passando a atuar também em uma guerra diferente, mas igualmente perigosa: a guerra na internet.

Esta palestra tem por objetivo – através da filosofia contida na Arte da Guerra – descrever como Administradores de Sistemas podem vencer suas batalhas diárias na internet construindo ambientes seguros utilizando Software Livre.

Enquanto não sai o vídeo, estou disponibilizando os slides da palestra. Para baixá-los, basta clicar no link abaixo. A licença de utilização é a Gnu FDL, sem seções invariantes.

A arte da guerra para Administradores de Sistemas

Se você a assistiu alguma vez, deixe seu comentário! Ele poderá ser aproveitado na próxima vez que eu der esta palestra, ou mesmo em outra apresentação.

Nosso primeiro artigo irá tratar de um dos serviços mais usados pelos sysadmins em seu dia-a-dia: O serviço SSH. Geralmente presente em todas as instalações de sistemas operacionais livres, o serviço ssh é responsável por permitir acesso remoto e criptografado a servidores geograficamente distribuídos.

Muitos administradores, contudo, acham que por se tratar de um serviço que utiliza criptografia tanto na autenticação do usuário quanto em todo o trafégo não seja necessário realizar nenhuma configuração adicional. Ledo engano. Desde ataques de força bruta em senha a coisas mais sofisticadas como “homem no meio”. Vejamos algumas medidas simples – mas eficientes – de prevenção.

Iremos implementar as seguintes funcionalidades:

• proibir o login como super-usuário;
• Utilizar apenas a versão 2(mais segura) do protocolo SSH;
• Alterar a porta padrão (22) para uma outra qualquer;
• Aplicar restrições de login: tempo de inatividade, utilização de PAM, etc;
• Liberar acesso apenas para usuários específicos. Assim, você pode se certificar que apenas os administradores conseguirão logar no servidor;
• Verificação de DNS;
• Permitir login apenas de certos hosts de origem;
• Bloquear as demais conexões;

Fase 1: configuração do daemon ssh

Abra com o seu editor preferido o arquivo de configuração do serviço ssh. No Debian, ele se encontra em /etc/ssh/sshd_config.
Adicione ou altere as seguintes linhas:

#proibir login como root
PermitRootLogin no

#Usar apenas o protocolo versão 2.
Protocol 2

#alterar a porta padrão para 444
Port 444

#restringir o endereco de escuta
ListenAddress #(endereço ip a ser utilizado para requisições ssh)

# restrições de login
LoginGraceTime 1m
PasswordAuthentication no
UsePAM yes
AllowUsers (usuario_ssh1) (usuario_ssh2)

PrintMotd no
UseDNS yes

Fase 2: Liberar apenas hosts de origem específicos

No arquivo /etc/hosts.allow, devemos liberar apenas os hosts que deverão ter acesso ao serviço ssh. Acrescente a seguinte linha, substituindo os valores para o endereço ip e a máscara do host a ser liberado:

sshd: ip/mascara

No arquivo /etc/hosts.deny, iremos bloquear as demais conexões. Acrescente a seguinte linha:

sshd: ALL

Fase 3: Alterando a porta padrão

Para que o tcp wapper reconheça a nova porta do ssh (no caso, alteramos para 444), devemos editar o arquivo /etc/services
e alterar a seguinte linha:

ssh 444/tcp

Fase 4: Aplicando as alterações

Para que as alterações tenham efeito, é necessário reiniciar o daemon ssh, com o comando:
/etc/init.d/ssh restart

Pronto! Seu servidor SSH agora está bem mais seguro. Caso você conheça alguma outra funcionalidade que possamos implementar, deixe seu comentário!

Na próxima semana teremos um artigo sobre os principais pontos a serem observados durante a instalação de um servidor. Fique ligado!

Foi assim que precisei passar a utilizar o Vmware Workstation no meu dia-a-dia (o Xen não suporta alguns s.o’s que necessito).

Este Artigo demonstra como instalá-lo no Debian Etch, inclusive em arquiteturas 64 bits.

Configuração do sistema

• Versão: Debian testing (Etch);
• Kernel 2.6.18-3
• gcc 4.1.2

Pacotes necessários

• kernel-package;
• linux-headers
• linux-kbuild
• linux-source
• gcc
• make
• build-essentials

Arquitetura AMD64

Se você está utilizando o Debian AMD64, o port do debian para a arquitetura 64 bits da amd, irá necessitar desses pacotes adicionais:

• ia32-libs;
• libpam0g;
• libdb2:

Instalação

Após ter instalado os pacotes do kernel, você tem duas opções. Gerar o seu próprio kernel ou usar a imagem já instalada. Optei pela segunda opção.
Neste caso, você precisará preparar o ambiente para que possa ser gerado o modulo do vmware. Então execute as operações abaixo.
Copie o arquivo config do kernel instalado para a pasta de fontes:
#cd /usr/src ; tar -jxvf linux-source-2.6.18.tar.bz2
#ln -s /usr/src/linux-source-2.6.18 /usr/src/linux
#cp /boot/config-2.6.18-3-amd64 /usr/src/linux
#make cloneconfig
#make modules_prepare

Baixe o pacote do vmware do site oficial, e descompacte-o em alguma pasta, por exemplo, /usr/local/src.

Entre no diretório vmware-distrib e sete o arquivo vmware-install.pl para executável, para utilizá-lo logo em seguida. O script de instalação nos fará algumas perguntas. Podemos escolher a opção default para todas elas.

Ao final, ele chamará o script de configuração (vmware-config.pl), o qual irá tentar subir um modulo pré-compilado do kernel. Provavelmente ele irá falhar, e então perguntar se você deseja que ele compile um módulo para você. É aí que entra nossa lista de dependências anterior. Informe sim para essa pergunta. O módulo será gerado com sucesso.

Após isso, o script de configuração fará algumas perguntas, principalmente sobre rede, nat, classes ip, etc. Escolha de acordo com as suas necessidades, e boa virtualização!