Um pequeno problema que aparece quando configuramos um proxy de encaminhamento, como sugerido no artigo "Proxy Squid no Ubuntu com autenticação NTLM no Windows 2008 e regras baseadas em Grupos do AD" é a configuração manual do proxy em cada computador e/ou browser cliente.

Para automatizar este processo foi criado o WPAD (Web Proxy Auto-Discovery Protocol). O WPAD se utiliza de um conceito bem simples e a maioria dos browsers já vem pré-configurada para utilizá-lo.

Seu funcionamento se resume em, no momento em que o browser é inicializado, buscar por um script padrão wpad.dat que contém as configurações do proxy de sua rede. A forma de obter este script se dá de duas maneiras: através de configurações no DHCP e através de DNS.

A princípio somente o Internet Explorer implementa a descoberta de proxy a partir do DHCP, os demais browsers se utilizam do DNS.

Uma vez que o computador obtém configurações de rede a partir de um servidor de DHCP, o DHCP pode informar o caminho de um servidor web que contenha o arquivo de configuração do proxy. O browser por sua vez realiza o download deste arquivo e o utiliza para configurar o proxy automaticamente.

Se a configuração a partir de DHCP não estiver disponível, ou o browser não suportar este modo, o DNS é consultado pelo endereço wpad seguido do dominio padrão configurado no computador cliente. Se o DNS possuir uma entrada do tipo A para o nome de domínio wpad, então o browser tenta acessar a URL http://wpad/wpad.dat. Se conseguir, o arquivo é baixado e as configurações presentes no mesmo são utilizadas.

Neste tutorial irei mostrar como configurar seus servidores de DHCP e DNS para responder pelas opções de WPAD. Também irei falar um pouco sobre a criação do arquivo wpad.dat.

Este artigo faz parte da série Proxy Squid no Ubuntu com autenticação NTLM no Windows 2008 e regras baseadas em Grupos do AD.

Pré-Requisitos

• Serviços DNS e DHCP instalados e configurados em sua rede. Este tutorial trata dos passos para ajustar o DHCP e o DNS de um servidor Windows 2008, porém é simples fazer as devidas adptações para outros sistemas operacionais.
• Servidor Web pré-configurado e em funcionamento para armazenar o arquivo wpad.dat. Pode ser Apache, IIS ou qualquer outro de sua preferência. Este tutorial vai descrever os passos para permitir o uso do wpad.dat em um servidor IIS 7 rodando sob Windows 2008. Não é necessário um servidor web dedicado para esta atividade, Você pode usar qualquer servidor web em funcionamento na sua rede.
• Proxy de encaminhamento instalado e configurado em sua rede. Se quiser saber como instalar e configurar um proxy squid com autenticação no Active Directory leia o tutorial: Squid 3 (Ubuntu 10.04 LTS) autenticando no Active Directory (Windows 2008).
• Credenciais com privilégios suficientes para administrar os serviços DHCP, DNS e Web de sua rede.

Tutorial

1. Criação do arquivo wpad.dat

O arquivo wpad.dat é um java script que contém no mínimo a função: FindProxyForURL(url, host).

Toda vez que uma nova URL for solicitada pelo usuário, esta função será automaticamente executada pelo browser, passando como parâmetros a URL e o domínio solicitados.  Por exemplo, se a URL solicitada for http://www.google.com.br/s=teste, o campo url será preenchido com http://www.google.com.br/s=teste e o campo domínio com www.google.com.br.

Esta execução é local no próprio browser, sendo o arquivo wpad.dat obtido uma única vez na inicialização do browser.

A função FindProxyForURL possui dois retornos possíveis: DIRECT ou PROXY. Se o retorno for DIRECT, o browser não utilizará proxy para aquela requisição, sendo o acesso feito diretamente pela rede. Se a string PROXY for retornada a função deve retornar também o endereço e a porta do proxy a ser utilizada para tratar a requisição.

Exemplo de script wpad.dat:

function FindProxyForURL(url, host){
   var host_ip;

   host_ip= dnsResolve(host);
   if (isInNet(host_ip, "127.0.0.1", "255.255.255.255"))
      return "DIRECT";
   if (isInNet(host_ip, "192.168.0.0", "255.255.255.0"))
      return "DIRECT";
   if (isInNet(myIpAddress(), "192.168.0.0", "255.255.255.0"))
      return "PROXY 192.168.0.2:3128";
   else
      return "DIRECT";
}

• dnsResolve(host): Converte o nome de domíno host em endereço IP
• isInNet(ip, address, mask): Verifica se o ip encontra-se na sub-sede formada pelo endereço de rede address com a máscara mask.
• shExpMatch(url, string): Verifica se a string está contida na url.
• myIpAddress(): Retorna o endereço IP da máquina local.

Você pode ainda retornar endereços de proxy distintos, de acordo com suas necessidades. Pode ter por exemplo dois proxys em sua rede e utilizar este script para fazer um balanceamento de carga baseado no IP de origem do acesso.

Coloque o arquivo wpad.dat na raiz de algum servidor web de sua rede, de forma que os clientes consigam acessá-lo através da URL: http://ip-do-servidor/wpad.dat.

2. Configuração do IIS

Se você utiliza IIS, coloque o arquivo wpad.dat na raiz de seu servidor, por padrão é a pasta C:\inetpub\wwwroot. Se você apontar um browser para a URL http://ip-do-servidor/wpad.dat provavelmente verá uma mensagem de erro dizendo que o arquivo não foi encontrado no servidor. Isto ocorre pois a extensão .dat não é aceita como um tipo MIME padrão do IIS. Precisamos configurar um novo tipo MIME .dat para que o IIS entregue o arquivo para os clientes.

Para fazer isso, acesse o Gerenciador de Servidores (Iniciar --> Ferramentas Administrativas --> Gerenciador de Servidores) e expanda Funções --> Servidor Web (IIS) --> Gerenciador do Serviços de Informações da Internet (IIS). Em Conexões clique no nome de seu servidor Web e na janela da direita (Página Inicial do Servidor) clique duas vezes em Tipos de MIME. No canto direito (janela ações) clique em Adicionar...

Na janela Adicionar Tipo de MIME preencha:

• Extensão de nome de arquivo: .dat
• Tipo MIME: application/x-javascript-config

3. Configuração do DNS

Para que o WPAD funcione em sua rede é necessário criar uma entrada do tipo A (Host) ou CNAME (Alias) em seu servidor de DNS.

Crie uma entrada do tipo A na zona de pesquisa direta de seu domínio com nome WPAD e com endereço IP do servidor Web que hospeda o arquivo wpad.dat, de forma que o browser acesse a URL http://wpad/wpad.dat e obtenha o arquivo wpad.dat. Você pode usar uma entrada CNAME e apontar para o FQDN do servidor que hospeda o wpad.dat.

Teste acessando a URL http://wpad/wpad.dat de um browser qualquer.

4. Configuração do DHCP

No servidor de DHCP é necessário configurar uma entrada com a opção 252 e valor http://wpad/wpad.dat. Porém, para poder adicionar uma entrada 252 é necessário configurar uma opção pré-definida com este valor.

Para fazer isso clique com o botão direito do mouse em IPv4, clique em Configurar opções pré-definidas e em seguida no botão Adicionar.

Configure a nova opção com os seguintes valores:

• Nome: WPAD
• Tipo de dados: Cadeia de Caracteres
• Código: 252
• Descrição: Web Proxy Auto-Discovery Protocol

5. Configuração do Browser

Provavelmente seu browser já está configurado para obter as configurações automáticas, mas para ter certeza, vá até a janela de configuração de proxy. Para cada browser é um pouco diferente o caminho, mas a configuração é a mesma.

No Chrome vá até Ferramentas --> Opções --> Configurações Avançadas --> Alterar Configurações de Proxy... --> Conexões --> Configurações da LAN.

Marque a opção Detectar automaticamente as configurações e deixe todas as demais opões em branco, conforme a figura abaixo

No Firefox acesse o menu principal do Firefox --> Opções --> Rede --> Configurar conexão...  Marque a opção Autodetectar as configurações de proxy para esta rede.

Observações e Dicas

Para computadores membros de um domínio Active Directory você pode configurar uma GPO (Group Police Object) para configurar o proxy de forma automática para o Internet Explorer. Basta ativar a opção Configurações do Usuário --> Diretivas --> Configurações do Windows --> Manutenção do Internet Explorer -->Conexão/Configuração Automática do Navegador --> Detectar configurações automaticamente.

Se seu servidor de DNS é Windows 2008, você poderá ter problemas com a resolução do nome wpad. Por padrão o serviço de DNS do Windows 2008 bloqueia as resolução de nomes wpad e isatapi.

Para remover a entrada wpad da lista global de bloqueio faço o seguinte:

• Clique em Iniciar, digite regedit.exe e pressione ENTER.
• Na árvore de console, abra Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters.
• No painel de conteúdo, clique duas vezes no valor GlobalQueryBlockList.
• Na caixa de diálogo Editar Cadeia de Caracteres Múltipla, remova o nome WPAD da lista e clique em OK.
• Inicie um prompt de comando como administrador.
• Na janela de prompt de comando, execute os seguintes comandos:

net stop dns
net start dns

dnscmd /config /enableglobalqueryblocklist 0

-

Referências

- Auto Configuring Proxy Settings
- Findproxyforurl.com - A Proxy Auto-Configuration Resource
- Remover o ISATAP da lista global de consultas não autorizadas do DNS
- Habilitar ou desabilitar a lista global de consultas não autorizadas

Descoberta automática de Proxy – WPAD (Web Proxy Auto-Discovery) é uma publicação do Blog do Nerd.

Compartilhar / Favoritos

Este artigo faz parte do tutorial Proxy Squid no Ubuntu com autenticação NTLM no Windows 2008 e regras baseadas em Grupos do AD. A idéia é aproveitar as credenciais dos usuários do AD, que já fizeram a autenticação no Windows e permitir que eles se autentiquem no Squid sem precisar digitar nenhuma senha.

Além disso os usuários serão incluidos em grupos do AD e as regras do Squid será configuradas para dar privilégios de acesso para estes grupos.

A sugestão aqui é a criação de 3 grupos de acesso: Internet_Acesso_Completo, Internet_Acesso_Padrao e Internet_Acesso_Bloqueado. Dessa forma o Squid gerencia os privilégios de cada grupo e fornece o acesso de acordo com o grupo que o usuário pertença.

Também serão criadas um conjunto de arquivos que irão conter palavras e sites permitidos e proibidos, além de computadores liberados e proibidos de navegar utilizando o proxy.

Por fim irei mostrar um pequeno script que utilizo para poder mostrar os logs do Squid de forma mais funcional e fácil de visualizar.

Pré-Requisitos

• Servidor Linux autenticando no AD - Você pode aprender como fazer isso aqui.
• Privilégios de administrador (root) no Linux instalado.
• Domínio Active Directory (AD) baseado em Windows 2000, 2003 ou 2008 já instalado e operando.
• Credenciais com privilégios para criação de grupos no AD.

Tutorial

1. Instalação do Squid 3

Instale o Squid 3 executando o comando abaixo:

sudo apt-get install squid3

Substitua o conteúdo do arquivo /etc/squid3/squid.conf pelo mostrado abaixo. Atenção para as linhas destacadas. Elas devem ser alteradas para refletir a realidade de seu ambiente.

# /etc/squid3/squid.conf
####################################################

# Portas (padrão 3128)
http_port 3128

#Habilitar debug
#debug_options 28,3

#Configurações de Cache
# tipo de cache (aufs), pasta raiz, tamanho em MB, diretorios pais, diretorios em cada diretorio
cache_dir aufs /var/spool/squid3 8196 16 256
# Tamanho da cache para obejtos
cache_mem 2 GB
# Tamanho máximo dos objetos que serão salvos em disco
maximum_object_size 131070 KB
# Tamanho minimo dos objetos que serão salvos em disco
minimum_object_size 0 KB
# Número de entradas na tabela de cache de conversão de IP para FQDN
ipcache_size 16384
# Percentagem de cache baixa - padrão 90
ipcache_low 90
# Percentagem de cache baixa - padrão 95
ipcache_high 95
# manter memória alocada e não usada, para não precisar realocar quando for usar
memory_pools on
# Número de entradas na tabela de cache de DNS
fqdncache_size 16384
# tamanho máximo dos objetos guardados na cache
maximum_object_size_in_memory 8 MB
# Gerar resumo de cache - Útil somente quando existem squids parceiros deste squid
digest_generation off

# Configurações gerais
# Como tratar o X-Forwared-For no cabeçalho HTTP
forwarded_for off
#logar parametros das URL's
strip_query_terms on
# Força IE 5.5 ou anteior a buscar novas páginas do servido em caso de refresh
ie_refresh on
#Detecta respostas quebradas de conexões persistnes e assuma que o reply foi enviado apos 10 segundos
detect_broken_pconn on
#Tenta executar até 2 requisições em paralelo - Pode quebrar autenticação NTLM/Kerberos
pipeline_prefetch off
# Continua baixando requisições abortadas
quick_abort_min -1 KB
# continua baixando requsições abortadas até o limite de 16KB
quick_abort_max 16 KB
# Quanto tempo manter cache de DNS
positive_dns_ttl 5 minute
# Fechar conexões TCP imediatamente
half_closed_clients off
# timeout de leitura de dados
read_timeout 240 second
# timeout de conexões persistentes
pconn_timeout 240 second
# Email do administrador
cache_mgr adminsquid@dominio.com.br
# Host visível
visible_hostname proxy-squid.dominio.com.br
# Linguagem dos erros
error_directory /usr/share/squid3/errors/pt-br
# Evita que sejam feitos coredumps.
coredump_dir /var/spool/squid3
# Numero de arquivos de log rotacionados a guardar.
logfile_rotate 120
# Tempo para agaurdar o fechamento de conexçoes durante encerramento do squid
shutdown_lifetime 1 second
# palavras que será tratadas diretamente por esse squid, ou seja, não serão repassadas para vizinhos
hierarchy_stoplist cgi-bin ?
# Dominio padrão de busca
#append_domain .dominio.com.br

# Padrão de refresh de cache para alguns sites
# refresh_pattern [-i] regex min percent max [options]
# -i : regular expressiona case-insensitive
# regex: Expressão regular a buscar
# min: tempo (em minutos) que um objeto será considerado novo
# percent: % da idade do objeto que é considerado novo
# max: limite máximo que os objetos sem tempo de expirar explicito serão considerados novos
refresh_pattern -i http.*\.gov.br/.*        720 100%  7200 reload-into-ims
refresh_pattern -i http.*\.globo.com/.*     720 100%  7200 reload-into-ims
refresh_pattern -i http.*\.terra.com.br/.*  720 100%  7200 reload-into-ims
refresh_pattern -i http.*\.google.*/.*      720 100% 10080 reload-into-ims
refresh_pattern -i http.*\.msn.*/.*         720 100% 10080 reload-into-ims
refresh_pattern -i http.*\.uol.com.*/.*     720 100% 10080 reload-into-ims
refresh_pattern -i http.*\.bol.com.*/.*     720 100% 10080 reload-into-ims
refresh_pattern -i http.*\.lyricsplugin.com.*/.*     720 100% 10080 reload-into-ims
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern . 0 20% 4320

# Logs
#logformat combined %>a %ui %un [%tl] "%rm %ru HTTP/%rv" %Hs %# Log de acesso
access_log /var/log/squid3/access.log
# Log de cache
cache_log  /var/log/squid3/cache.log
# pasta para arquivo de dump
coredump_dir /var/spool/squid3

# comportamente para espaço em branco nas URLs
uri_whitespace allow

# Servidores de DNS a serem utilizados - Se não for especificado, o valor de /etc/resol.conf será utilizado
#dns_nameservers 192.168.0.1

# Autenticação no Windows 2008
auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 30
auth_param ntlm keep_alive on

auth_param basic program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic
auth_param basic children 5
auth_param basic realm Proxy Squid - Digite suas credenciais
auth_param basic credentialsttl 5 hours

# ACLs
# acls de origem
# rede loopback
acl localhost src 127.0.0.1/32
# Rede local
acl rede_local src 192.168.0.0/24

# acls de destino
#acl allDest dst 0.0.0.0/0.0.0.0
#acl to_localhost dst 127.0.0.0/8

# portas seguras
acl SSL_ports port 443
acl SSL_ports port 8180
acl SSL_ports port 8443

# Demais serviços
acl Safe_ports port 80 # http
acl Safe_ports port 81 # http
acl Safe_ports port 20-21 # ftp
acl Safe_ports port 70 # gopher
acl Safe_ports port 443 563 # https, snews
acl Safe_ports port 210 # wais
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl Safe_ports port 901 # SWAT
acl Safe_ports port 8080 # http
acl Safe_ports port 8081 # http
acl Safe_ports port 8082 # http
acl Safe_ports port 8088 # http
acl Safe_ports port 8180 # http
acl Safe_ports port 3456 # receita federal - irpf
acl Safe_ports port 3001 # diario oficial

# acls default squid
acl purge method PURGE
acl CONNECT method CONNECT
acl POST method POST

# acl para obter grupos do AD
external_acl_type grupo_AD ttl=60 %LOGIN /usr/lib/squid3/wbinfo_group.pl

# Grupos do AD
acl acesso_completo  external grupo_AD Internet_Acesso_Completo
acl acesso_padrao    external grupo_AD Internet_Acesso_Padrao
acl acesso_bloqueado external grupo_AD Internet_Acesso_Bloqueado

# acls de segurança proteção do cache
acl manager proto cache_object

# acl controlar sites (sites-proibidos)
acl sites_proibidos dstdomain -i "/etc/squid3/acls/sites_proibidos"
acl sites_liberados dstdomain -i "/etc/squid3/acls/sites_liberados"

# acl controlar palavras de sexo, baixo calão, etc
acl palavras_proibidas url_regex -i "/etc/squid3/acls/palavras_proibidas"
acl palavras_liberadas url_regex -i "/etc/squid3/acls/palavras_liberadas"

acl maquinas_proibidas src "/etc/squid3/acls/maquinas_proibidas"
acl maquinas_liberadas src "/etc/squid3/acls/maquinas_liberadas"

# acl controlar horário de expediente
#acl horario_allow url_regex -i "/etc/squid3/horario_allow"
#acl fora_expediente time MTWHFA 20:01-23:59
#acl fora_expediente2 time MTWHFA 00:00-05:59

# Mensagem de erros personalizados para alguimas ACLs
deny_info ARQ_SITES_PROIBIDOS sites_proibidos
deny_info ARQ_SITES_PROIBIDOS sites_liberados
deny_info ARQ_SITES_PROIBIDOS palavras_proibidas
deny_info ARQ_SITES_PROIBIDOS palavras_liberadas
deny_info ARQ_MAQUINAS_PROIBIDAS maquinas_proibidas
deny_info ARQ_MAQUINAS_PROIBIDAS maquinas_liberadas
deny_info ARQ_ACESSO_BLOQUEADO acesso_bloqueado
deny_info ARQ_PORTAS_PROIBIDAS Safe_ports
deny_info ARQ_PORTAS_PROIBIDAS SSL_ports

# HTTP ACCESS
# regras das acls de origem - libera os administradores
#http_access allow admins

# libera método POST sem autenticação. Para evitar problemas
http_access allow POST

http_access allow rede_local acesso_completo
http_access deny acesso_bloqueado

# regras das acls de portas - bloqueia todas as portas não listadas
http_access deny !Safe_ports
# bloqueia conexões das portas seguras não listadas
http_access deny CONNECT !SSL_ports

# regras das acls de controle (bloqueio e políticas de rede)
http_access allow manager localhost
http_access deny manager

# controle de acesso de sites proibidos
http_access deny sites_proibidos !sites_liberados

# controle de acesso da acl de palavras de sexo, baixo calão, etc
# bloqueia todas as palavras da lista de proibidas com exceção das
# palavras liberadas
http_access deny palavras_proibidas !palavras_liberadas

http_access deny maquinas_proibidas !maquinas_liberadas
http_access allow rede_local maquinas_liberadas

# controle de horário de expediente
# bloqueia utilização fora do expediente
#http_access deny !horario_allow fora_expediente
#http_access deny !horario_allow fora_expediente2

http_access allow purge localhost

http_access allow rede_local acesso_padrao

http_access deny purge
# HTTP REPLY ACCESS
http_reply_access allow all
http_access deny all

# ICP ACCESS
icp_access deny all

# MISS ACCESS
miss_access allow rede_local
miss_access deny all

# MODO DE FTP PASSIVO
#ftp_passive on

# Negar cache de cgi-bin
acl QUERY urlpath_regex cgi-bin \?
cache deny QUERY

# negar cache de POST
acl POSTS method POST
cache deny POSTS

O arquivo acima é apenas uma sugestão. Você pode fazer as alterações que julgar necessárias. A parte importante é a que controla a autenticação NTLM no dominio:

# Autenticação no Windows 2008
auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 30
auth_param ntlm keep_alive on

auth_param basic program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic
auth_param basic children 5
auth_param basic realm Proxy Squid - Digite suas credenciais
auth_param basic credentialsttl 5 hours

Outra parte importante é a que configura a obtenção dos grupos do AD e a aplicação das regras associadas:

# acl para obter grupos do AD
external_acl_type grupo_AD ttl=60 %LOGIN /usr/lib/squid3/wbinfo_group.pl

# Grupos do AD
acl acesso_completo  external grupo_AD Internet_Acesso_Completo
acl acesso_padrao    external grupo_AD Internet_Acesso_Padrao
acl acesso_bloqueado external grupo_AD Internet_Acesso_Bloqueado

http_access allow rede_local acesso_completo
http_access deny acesso_bloqueado
#... conjunto de regras de bloqueio padrão
http_access allow rede_local acesso_padrao

O campo ttl=60, na diretiva external_acl_type acima, controla por quanto tempo (em segundos) o grupo é válido para o acesso. Você pode diminuir ou aumentar este valor de acordo com suas preferências, para que as alterações de grupos dos usuários sejam aplicadas para os acessos ao Squid. Em outras palavras: com o ttl de 60, se por exemplo um usuário que possui acesso padrão for incluído no grupo Internet_Acesso_Completo, levará 1 minuto para que esta alteração seja efetivada pelo Squid.

Você pode comentar as regras que não se aplicarem a sua realidade ou não satisfizerem suas necessidades.
Cada diretiva possui uma breve descrição sobre sua função no próprio arquivo acima, mas em caso de dúvidas, consulte a ajuda do Squid: http://www.squid-cache.org/Doc/config/

2. Criação dos grupos no Active Directory (AD)

Você precisa criar os três grupos sugeridos no começo do tutorial em seu AD:

• Internet_Acesso_Completo
• Internet_Acesso_Padrao
• Internet_Acesso_Bloqueado

3. Criação de arquivos de controle

Crie a pasta /etc/squid3/acls e dentro dela os arquivos de controle de acesso a sites, palavras e computadores de origem.

sudo mkdir /etc/squid3/acls
sudo touch /etc/squid3/acls/sites_proibidos
sudo touch /etc/squid3/acls/sites_liberados
sudo touch /etc/squid3/acls/palavras_proibidas
sudo touch /etc/squid3/acls/palavras_liberadas
sudo touch /etc/squid3/acls/maquinas_proibidas
sudo touch /etc/squid3/acls/maquinas_liberadas

Inclua nos arquivos recém criadas as entradas que deseja permitir ou proibir, uma em cada linha.

Os arquivos de controle de sites devem conter o domínio completo do que se deseja permitir/proibir, por exemplo www.playboy.com.br.

Os arquivos de controle de palavras irão controlar o acesso para URLs que contenham em algum lugar as palavras listadas nos respectivos arquivos.

Os arquivos maquinas_proibidas e maquinas_liberadas, devem conter o endereço IP de computadores que devem ter seu acesso proibido ou liberado completamente, independente do usuário conectado no mesmo.

4. Arquivos de erros personalizados

As regras deny_info controlam arquivos de erro personalizado para cada regra acl que seja negada pelo Squid.

Crie os arquivos ARQ_SITES_PROIBIDOS, ARQ_MAQUINAS_PROIBIDAS, ARQ_ACESSO_BLOQUEADO e ARQ_PORTAS_PROIBIDAS na pasta /usr/share/squid3/errors/pt-br.

Estes arquivos são em formato HTML e devem conter as mensagens a serem reportadas para o usuário em caso de bloqueio no acesso.

Você pode utilizar alguns caracteres especiais para serem convertidas em informações antes de mostrar para o usuário. Para saber os caracteres permitidos consulte: http://www.squid-cache.org/Doc/config/deny_info/

Se quiser usar meus arquivos personalizados, descomprima o arquivo erros_squid.zip na pasta /usr/share/squid3/errors/pt-br.

Um exemplo de acesso negado contido nestes arquivos seria semelhante ao seguinte:

5. Como controlar o acesso a redes sociais para um grupo específico do AD

acl acesso_redes_sociais external grupo_AD Internet_Acesso_Redes_Sociais
acl redes_sociais dstdomain -i "/etc/squid3/acls/redes_sociais"

Você pode usar url_regex ao invés de dstdomain, assim você não precisa digitar o nome exato de cada domínio de rede social, bastando escrever o domínio parcialmente em /etc/squid3/acls/redes_sociais.

Um exemplo do arquivo /etc/squid3/acls/redes_sociais seria:

twitter.com
orkut.com
facebook.com
plus.google.com

Ainda no arquivo /etc/squid3/squid.conf, antes da linha abaixo:

http_access allow rede_local acesso_padrao

incluia as seguintes linhas:

http_access allow redes_sociais acesso_redes_sociais
http_access deny redes_sociais

Visualização dos logs de acesso do Squid

Escrevi um pequeno script para permitir a visualização dos logs do Squid de uma forma mais simples e fácil de entender.

Você precisa ter o gawk instalado para ele funcionar corretamente. Instale-o com o comando abaixo:

sudo apt-get install gawk

Crie um arquivo squid3_log.sh com o conteúdo abaixo:

#!/bin/bash
tail -f /var/log/squid3/access.log | awk '{print strftime("\033[1;31m%F %H:%M:%S\033[0m",$1) " " $3 " \033[1;35m" $8 "\033[0m " $4 " \033[1;32m" $6 "\033[0m \033[1;33m" $7 "\033[0m"}'

Dê permissão de execução:

chmod +x squid3_log.sh

Execute o script para verificar os acessos em tempo real:

./squid3_log.sh

Você pode melhorar o script acima incluindo filtros, usando o grep, para por exemplo encontrar os acessos de usuários específicos e/ou data e hora de acesso determinados.

A saída do script acima será algo semelhante a imagem abaixo:

Observações e Dicas

Reinicie seu computador e teste todos os acessos com usuários de grupos diferentes antes de colocar o sistema em produção.

Em caso de problemas com as regras, descomente (remova o #) a linha debug no começo do /etc/squid3/squid.conf e verifique os logs no /var/log/squid3/cache.log.

O Squid é bastante poderoso e integrado ao AD torna-se uma ferramenta incrível e bastante simples de administrar.

Estude principalmente as ACLs e a aplicação das mesmas com a diretiva http_access. Você vai se surpreender com tudo que é capaz de fazer.

Abraços e em caso de dúvidas é só escrever nos comentários.

-

Referências

- Squid autenticando no Windows utilizando grupos do AD
- Integrating Squid and Samba3 with NTLM authentication
- Integrando autenticação do Squid ao Active Directory

Squid 3 (Ubuntu 10.04 LTS) autenticando no Active Directory (Windows 2008) é uma publicação do Blog do Nerd.

Compartilhar / Favoritos

Este tutorial descreve o caminho das pedras para incluir uma estação/servidor Linux Ubuntu em um domínio Active Directory Windows (2000, 2003 ou 2008).
A solução utiliza Samba e Winbind e mostra os passos para que usuários possam se logar na estação Linux usando suas credenciais do Active Directory (AD). É sugerida ainda a criação de um grupo no AD para incluir usuários com privilégios de administrador de estações Linux podendo usar o sudo para executar comandos como root.

Este post faz parte do tutorial Proxy Squid no Ubuntu com autenticação NTLM no Windows 2008 e regras baseadas em Grupos do AD.

Pré-Requisitos

• Estação/Servidor com Linux Ubuntu 10.04 LTS ou superior instalado.
• Servidor de DNS configurado (/etc/resolv.conf) e apontando para um servidor de DNS do domínio Active Directory
• Privilégios de administrador (root) no Linux instalado.
• Domínio Active Directory baseado em Windows 2000, 2003 ou 2008 já instalado e operando.
• Credenciais com privilégios suficientes para inclusão de computador no domínio AD pré-existente.
• Opcional: credenciais com privilégios para criação de grupos no AD

Tutorial

Recomendo atualizar seu Ubuntu, antes de começar, utilizando os comandos abaixo:

sudo apt-get update
sudo apt-get dist-upgrade

Reinicie o computador para que o novo kernel seja atualizado (se necessário).

sudo reboot

Instale os pacotes libkrb5-3, krb5-config, samba, winbind e ntp utilizando o comando abaixo:

sudo apt-get install libkrb5-3 krb5-config samba winbind ntp

Pare os serviços samba e winbind:

sudo service smbd stop
sudo service winbind stop

Limpe a pasta de cache do samba:

sudo rm -rf /var/lib/samba/*

Configure o Kerberos alterando o conteúdo do arquivo /etc/krb5.conf pelo apresentado abaixo.

Lembre-se de substituir DOMINIO.COM.BR e dominio.com.br pelo nome FQDN de seu domínio Active Directory nas linhas em destaque. Troque também servidor pelo nome DNS de um servidor controlador de domínio de sua floresta.

[libdefaults]
	default_realm = DOMINIO.COM.BR
        ticket_lifetime = 24000
        dns_lookup_realm = false
        dns_lookup_kdc = false

[realms]
	DOMINIO.COM.BR = {
		kdc = servidor.dominio.com.br:88
		admin_server = servidor.dominio.com.br:749
		default_domain = dominio.com.br
	}

[domain_realm]
	.dominio.com.br = DOMINIO.COM.BR
	dominio.com.br = DOMINIO.COM.BR

[login]
	krb4_convert = true
	krb4_get_tickets = false

[logging]
        kdc = FILE:/var/log/krb5kdc.log
        admin_server = FILE:/var/log/kadmin.log
        default = FILE:/var/log/krb5lib.log

Edite o arquivo /etc/ntp.conf e substitua a linha server informando o nome de seu domínio. Você pode apontar para um servidor NTP de sua rede ou outro qualquer de preferência.

server dominio.com.br

Reinicie o serviço ntp e verifique se a data e hora estão corretos:

sudo service ntp restart
date

Configure o Samba/Winbind, editando o arquivo /etc/samba/smb.conf e substituindo seu conteúdo conforme abaixo.

Lembre-se de substituir HOSTNAME pelo nome de seu servidor linux e alterar DOMINIO, DOMINIO.COM.BR e dominio.com.br para o FQDN de seu domínio nas linhas em destaque. Troque também servidor pelo nome DNS de um servidor controlador de domínio de sua floresta..

[global]
	realm = DOMINIO.COM.BR
	workgroup = DOMINIO
	netbios name = HOSTNAME
	server string = %h server
	security = ads
	allow trusted domains = no
	idmap config DOMINIO: default = yes
	idmap config DOMINIO: backend = rid
	idmap config DOMINIO: readonly = yes
	idmap config DOMINIO: range= 1000000-10000000
	idmap alloc config: range = 1000000-10000000

	idmap uid = 1000000-10000000
	idmap gid = 1000000-10000000

	template shell = /bin/bash
	template homedir = /home/%U
	winbind use default domain = yes
	winbind enum users = yes
	winbind enum groups = yes
	winbind nested groups = yes

	load printers = no
	domain master = no
	preferred master = no
	domain logons = no
	wins support = no
	wins proxy = no
	dns proxy = no
	password server = servidor.dominio.com.br

#Compartilhamento Home
[homes]
	comment = Compartilhamento Home
	browseable = no
	writable = yes
	read only = no
	create mask = 0664
	directory mask = 0775

Substitua o conteúdo do arquivo /etc/nsswitch.conf pelo abaixo, para configurar o Linux para considerar o winbind para senhas e grupos.

passwd:         compat winbind
group:          compat winbind
shadow:         compat

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Para que estas configurações (nsswitch) tenham efeito, execute o comando ldconfig:

sudo ldconfig

Ajuste o nome do host no arquivo /etc/hosts conforme abaixo, alterando nome-do-host e dominio.com de acordo com o hostname de seu Linux e o FQDN de seu domínio:

127.0.0.1	localhost
127.0.0.1	nome-do-host.dominio.com	nome-do-host

Se o computador estiver utilizando DHCP, ajuste o nome do host para que seja registrado automaticamente no DNS, incluindo as linhas abaixo no arquivo /etc/dhcp3/dhclient.conf. Lembre-se de alterar nome-do-host e dominio.com de acordo com o hostname de seu Linux e o FQDN de seu domínio.

send host-name "nome-do-host.dominio.com";
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, host-name,
netbios-name-servers, netbios-scope, interface-mtu;

Adicione o Linux no dominio executando o comando abaixo. Substitua usuário pela sigla de um usuário com privilégios para adicionar computadores no domínio.

sudo net ads join -U usuario

Sua senha será solicitada. O resultado da execução será algo semelhante ao abaixo:

Enter usuarios's password:
Using short domain name -- DOMINIO
Joined 'HOSTNAME' to realm 'dominio.com.br'
DNS update failed!

Não se preocupe com a mensagen DNS update failed!. Ela aparecerá se o seu dominio não estiver configurado para aceitar atualizações de DNS não autenticadas. Simplesmente ignore esta mensagem.

Inicie os serviços samba e winbind:

sudo service smbd start
sudo service winbind start

Verifique se a resolução de nomes esta funcionando corretamente. Caso não esteja reveja os passos realizados acima.

wbinfo –u
wbinfo –g
wbinfo –i usuario

Se tudo está funcionando corretamente, configure a autenticação do Linux, alterando os arquivos abaixo. Provavelmente o conteúdo já estará correto. Apenas certifique-se de que está tudo OK e altere o que estiver diferente.
Alternativamente você pode fazer estas configurações de forma automática executando o comando abaixo:

sudo pam-auth-update

Conteúdo do arquivo /etc/pam.d/common-account:

account [success=2 new_authtok_reqd=done default=ignore]        pam_unix.so
account [success=1 new_authtok_reqd=done default=ignore]        pam_winbind.so
account requisite                       pam_deny.so
account required                        pam_permit.so

Conteúdo do arquivo /etc/pam.d/common-auth:

auth    [success=2 default=ignore]      pam_unix.so nullok_secure
auth    [success=1 default=ignore]      pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass
auth    requisite                       pam_deny.so
auth    required 

Conteúdo do arquivo /etc/pam.d/common-session. Será necessário incluir a linha destacada, conforme abaixo. Esta alteração irá criar a pasta home do usuário automaticamente no primeiro logon.

session [default=1]                     pam_permit.so
session requisite                       pam_deny.so
session required                        pam_permit.so
session required                        pam_unix.so
session required                        pam_mkhomedir.so skel=/etc/skel/ umask=0022
session optional                        pam_winbind.so

Se você quiser restringir o acesso via SSH para um grupo de usuários, crie um grupo global no AD e inclua os usuários permitidos a acessar o servidor Linux neste grupo, por exemplo administradores_linux. Altere o arquivo /etc/ssh/sshd_config e inclua no final do mesmo a seguinte linha:

AllowGroups admin administradores_linux

O grupo admin é opcional e permite o logon dos usuários locais que estão no grupo admin. Por padrão o primeiro usuário criado no Ubuntu no momento da instalação terá este privilégio.

Como boa prática de segurança, evite que o root faça logon via ssh, atlerando a linha abaixo no arquivo /etc/ssh/sshd_config:

PermitRootLogin no

Se desejar você pode incluir a linha abaixo no arquivo /etc/sudoers para permitir que os usuários membros do grupo administradores_linux possam executar comandos com privilégios de root.

%administradores_linux ALL=(ALL) ALL

Espero que o artigo tenha sido útil. Em caso de problemas é só postar nos comentários.

-

Referências

- Ubuntu 8.04 autenticando no AD do Windows Server 2003
- Integrating Squid and Samba3 with NTLM authentication
- Integrando autenticação do Squid ao Active Directory

Autenticação Ubuntu 10.04 LTS no Active Directory (Windows 2008) é uma publicação do Blog do Nerd.

Compartilhar / Favoritos

Olá galera,

Estou de volta para tratar de um assunto extremamente comum: o uso do proxy Squid integrado com um domínio Active Directory (AD) baseado em Windows 2008.

Precisei montar um proxy desses recentemente e pesquisando na Internet me deparei com muitos tutoriais baseados em versões antigas do Squid e do Windows, e também soluções pouco elegantes, necessitando compilar módulos de terceiros para conseguir a utilização de grupos do AD em regras do Squid e muitas soluções necessitando a digitação de usuário e senha. Esta solução utiliza os módulos padrões do Squid 3 e é baseada em Ubuntu 10.04 LTS. É claro que com alguns ajustes a mesma solução pode ser adotada em outros sabores de Linux. A autenticação é transparente para o usuário e gerenciada pelo próprio Windows através de NTLM (NT LAN Manager), ou seja, não é necessário digitar usuário e senha para se autenticar. Uma vez que o computador esteja em um domínio e o usuário se autenticou neste domínio, as mesmas credenciais serão utilizadas. É possível assim, criar regras baseadas em usuários ou grupos de usuários, permitindo acesso a alguns sites ou portas para um grupo e negando para outros.

Para facilitar o entendimento e a implementação, dividi o assunto em 3 tutoriais:

• Autenticação Ubuntu 10.04 LTS no Active Directory (Windows 2008)
• Squid 3 (Ubuntu 10.04 LTS) autenticando no Active Directory (Windows 2008)
• Descoberta automática de Proxy - WPAD (Web Proxy Auto-Discovery)

Observações

Espero que este seja um bom guia para resolver este problema tão comum nas empresas hoje em dia.

Aproveito para dizer que apesar de não ter tempo para atualizar o site regularmente, continuo respondendo os comentários nos posts.

Abraços.

Proxy Squid no Ubuntu com autenticação NTLM no Windows 2008, regras baseadas em Grupos do AD e configuração automática é uma publicação do Blog do Nerd.

Compartilhar / Favoritos

Olá pessoal. Só gostaria de avisar que o blog não parou, apenas entrou em estado de dormência. Estou com muito trabalho e viajando muito ultimamente, o que torna inviável a inclusão de novos tutoriais.

Se tiverem qualquer dúvida com relação aos tópicos atuais é só postar nos comentários que eu respondo o mais rápido possível.
Espero que no começo do ano [2011] possa voltar com força total.
Um forte abraços a todos.
Nerd.

Pausa… é uma publicação do Blog do Nerd.

Compartilhar / Favoritos

As cotas são um recurso importante para evitar o uso excessivo e descontrolado de espaço em disco em um servidor de arquivos.

Antes do Windows 2003 R2 a única alternativa para configurar cotas em servidores Windows era através da cota por partição. Neste tipo de configuração, entradas de cotas eram criadas para cada usuário e valiam para a partição inteira.

Isso acabava trazendo problemas pois para ter, por exemplo, uma pasta pessoal com um valor de cota e outra pasta compartilhada por um grupo de trabalho, também com controle de cota, era necessário separar as pastas em discos ou partições diferentes, pois caso não o fizesse a cota definida para o usuário é que seria válida.

A partir do Windows Server 2003 R2 a configuração de cotas pode ser feita por pastas, ou seja, posso por exemplo, configurar a pasta pessoal de um usuário com um limite de espaço e a pasta compartilhada por seu grupo de trabalho com outro limite. Em outras palavras: o controle de espaço em disco pode ser feito por pastas ao invés de por usuário.

Neste artigo irei mostrar como configurar o controle de cotas por pastas no Windows 2003 R2. O mesmo procedimento é válido para o Windows 2008.

Se estiver interessado em como criar pastas pessoais para cada usuário de seu domínio, leia o artigo: Active Directory: Configurando pasta pessoal dos usuários.

Pré-Requisitos

Para este tutorial iremos precisar:

• Usuário com permissão de acesso e configuração do servidor de arquivos.
• Gerenciador de Recursos de Servidor de Arquivos (File Server Resource Manager) instalado. Abaixo você encontrará os passos para a instalação.

Resumo

São esses os passos que iremos seguir:

1. Instalação do Gerenciador de Recursos de Servidor de Arquivos (File Server Resource Manager).
2. Configuração das cotas.

Tutorial

Vamos por a mão na massa.

1. Instalação do Gerenciador de Recursos de Servidor de Arquivos (File Server Resource Manager)

Vá em Iniciar (Start), Painel de Controle (Control Panel), Adicionar ou Remover Programas (Add or Remove Programs). Clique em Adicionar/Remover Componentes do Windows (Add/Remove Windows Components).

O Assistente de componentes do Windows (Windows Components Wizard) será aberto:

Selecione Ferramentas de gerenciamento e monitoramento (Management and Monitoring Tools) e clique no botão Detalhes (Details).

Marque o Gerenciador de Recursos de Servidor de Arquivos (File Server Resource Manager) para instalação e clique no botão OK e em Avançar.

O Gerenciador de Recursos de Servidor de Arquivos será instalado. Provavelmente serão solicitados os discos de instalação do Windows.

2. Configuração das cotas

Abra o Gerenciador de Recursos de Servidor de Arquivos executando fsrm.msc ou indo em Iniciar, Ferramentas administrativas.

Em Gerenciamento de Cota (Quota Management), clique com o botão direito em Cotas (Quotas) e escolha Criar cota... (Create Quota...). Pode demorar um pouco para esta opção ficar disponível.

Escolha a pasta a qual será aplicada a cota clicando no botão Procurar... (Browse...) e em seguida escolha um modelo de cota (quota template) ou marque Definir propriedades personalizadas da cota (Define custom quota properties) e clique em Propriedades Personalizadas... (Custom Properties...)

ATENÇÃO: Se a opção Criar cota no caminho (Create quota on path) for escolhida, a cota será aplicada para toda a pasta e seu conteúdo, independente das subpastas criadas e dos usuários que as criaram.

Para criar uma entrada de cota para cada nova subpasta criada dentro da pasta escolhida, selecione a opção Aplicar modelo e criar cotas em subpastas novas e existentes automaticamente (Auto apply template and create quotas on existing and new subfolders). Esta opção é ideal para criar cotas em pastas individuais para cada novo usuário. Talvez seja necessário criar um modelo de cota antes de escolher esta opção.

Defina um Rótulo (Label) e em Limite de Espaço (Space Limit) defina o limite de espaço que cada usuário poderá utilizar na pasta selecionada.

Escolha se deseja Cota fixa (Hard quota) onde os usuários não podem gravar mais do que a cota permitida, ou a Cota flexível (Soft quota) que é utilizada apenas para avisar os usuários que a cota foi excedida.

Em Limites de notificação (Notification thresholds) é possível definir alarmes de notificação a serem registrados no log de eventos do Windows ou ainda por e-mail para os usuários e administradores do servidor de arquivos. Se quiser configurar estes alarmes, clique no botão Adicionar... (Add...) e configure o alarme:

Clique em OK e em seguida em Criar (Create). Uma mensagem solicitando se deseja salvar um modelo de cota baseado nos parâmetros atuais será mostrada. Escolha a opção que mais lhe agrada e clique em OK.

Para que seja possível enviar e-mails para o administrador e os usuários, é necessário configurar um servidor de SMTP. Para fazer isso, clique com o botão direito em Gerenciador de Recursos de Servidor de Arquivos (File Server Resource Manager) e escolha Configurar Opções (Configure Options...)

Na janela de opções especifique o servidor de SMTP e os endereços padrões de email de remetente e administradores.

Observações

Você pode ainda definir uma cota padrão para novas pastas e cotas diferenciadas para usuários específicos, conforme ilustra a figura abaixo. Aproveite o recurso de templates para facilitar a criação de novas cotas.

Espero que o artigo tenha sido útil. Qualquer dúvida, sugestão ou relato de erros é só postar nos comentários.

.

Referências

Managing Volume and Folder Quotas.

Configurando cotas em pastas do Windows Server 2003 R2 e 2008 é uma publicação do Blog do Nerd.

Compartilhar / Favoritos

Essa semana me deparei com o Internal Error 2753. regutils.dll ao tentar atualizar o Java em alguns computadores.

Segundo a Microsoft, esse erro significa que um arquivo não está marcado para instalação??? Não tenho a mínima idéia do que isso quer dizer...

O fato é que não é possível instalar o Java de jeito algum. Tentei remover a versão antiga pelo Painel de Controle e até foi possível remover, porém, ao tentar instalar a nova versão, o erro persistia.

Pesquisando na Internet encontrei diversos posts com reclamações sobre isso. Inclusive alguns scripts maliciosos que deveriam servir para remover entradas do registro mas que acabam danificando a máquina.

Este pequeno tutorial apresenta a solução que encontrei para conseguir remover a instalação atual do Java e instalar a última versão.

Pré-Requisitos

Você vai precisar:

• Windows Installer Cleanup Utility - Baixe aqui. Ele parece ser uma ferramenta da Microsoft que deveria vir em alguma versão do Office.

Tutorial

Instale e execute o Windows Installer Cleanup Utility. Escolha o software que deseja remover, no caso o Java, e clique no botão Remove.

Após a remoção, exclua a pasta C:\Arquivos de Programas\Java, se ela existir, e reinicie o computador.

Agora você deve conseguir reinstalar o Java normalmente.

Se o problema ainda persistir, outro software que também pode ajudar é o JavaRa. Ele é um software pequeno e simples que não precisa ser instalado. Após a execução do mesmo, selecione o idioma de sua preferência e clique no botão Remove Older Versions.

Reinicie seu computador e tente instalar o Java novamente.

Espero que o artigo tenha sido útil. Qualquer dúvida, sugestão ou relato de erros é só postar nos comentários.

Como reinstalar o Java com Internal Error 2753 – regutils.dll é uma publicação do Blog do Nerd.

Compartilhar / Favoritos

Criei um conjunto de scripts para facilitar a realização de backup de arquivos de servidores Linux. A idéia é a de agendar o backup no agendador de tarefas do Linux (cron) para ser executado periodicamente. O backup é  feito localmente em uma pasta predefinida e uma cópia é enviada para um servidor de backup Linux, através de uma conexão SSH com relação de confiança. O script mantém o backup local dos últimos dias, semanas ou meses, de acordo com sua configuração.

Nos servidores que administro sempre configuro um backup mensal ou semanal de toda a pasta /etc, que é onde é mantida as principais configurações do servidor. Além disso, se o servidor executa algum serviço web, também configuro o backup periódico da pasta /var/www (ou a equivalente para a sua instalação/disribuição). Para as demais pastas executo o backup conforme o serviço em execução. Não costumo realizar o backup da instalação completa do Linux pois, acredito que em caso de necessidade de se restaurar o servidor como um todo, o ideal é a reinstalação da distribuição Linux em sua versão mais recente.

Este tutorial apresenta os scripts para backup de arquivos e também como configurá-los em seu servidor Linux. Ele faz parte da série de tutoriais sobre Backup de servidores Linux.

Pré-Requisitos

• Configuração de relação de confiança SSH entre o servidor que será copiado e o servidor que receberá os backups. Leia meu artigo sobre como configurar a relação de confiança SSH entre servidores Linux.
• Usuário com privilégios suficientes de leitura nas pastas a serem copiadas para o servidor de backups. Muitas vezes esse usuário é o root.

Tutorial

Costumo salvar meus scripts em /usr/local/scripts/. Provavelmente será necessário criar a pasta scripts (mkdir /usr/local/scripts).

Salve o script abaixo com o nome backup_pastas.sh na pasta /usr/local/scripts:

###################################################################
# backup_pastas.sh
#
# Desenvolvido por: Nerd
# Data: 27-set-2010
# Objetivo: Realiza backup de uma pasta informada
# Funcionamento:
#			- Comprime a pasta e salva em pasta local
#			- Faz copia via scp para máquina remota
# Parâmetros:
#			<Pasta a ser realizado backup> <Label do backup> <Label de tempo> \
#			<Pasta para o backup local> <Pasta para o backup remoto> \
#			<Usuario remoto> <Host remoto>
#
# (c) Blog do Nerd 2010
###################################################################
#!/bin/bash

local_data=$1
label1=$2
label2=$3
backup_folder=$4
remote_folder=$5
remote_user=$6
remote_host=$7

if [ ! ${remote_host} ]; then
	echo "Uso: "
	echo "$0 <Pasta a ser realizado backup> <Label do backup> <Label de tempo> <Pasta para o backup local> <Pasta para o backup remoto> <Usuario remoto> <Host remoto> "
	exit 1
fi
backup_file="${backup_folder}/${hostname}_${label1}_backup_${label2}"

date=$(date)
echo "-----------------------------------------------------------------------"
echo "${date}: ${backup_file} - ${hostname} - Inicio do Backup!"

tar -czf ${backup_file}.tar.gz ${local_data}

scp ${backup_file}.tar.gz ${remote_user}@${remote_host}:${remote_folder}

date=$(date +%Y-%m-%d)

cp ${backup_file}.tar.gz ${backup_file}_${date}.tar.gz

date=$(date)
echo "${date}: ${backup_file} - ${hostname} - Backup realizado!"
echo "-----------------------------------------------------------------------"

exit 0

Este script recebe vários parâmetros e faz o seguinte:

• Comprime a pasta informada e salva o conteúdo comprimido em uma pasta de backup local
• Copia o arquivo comprimido para uma máquina remota utilizando scp. É estritamente necessário a utilização de relação de confiança entre a máquina local e a máquina remota que receberá o backup.
• Copia o arquivo local incluindo a data atual no nome. Isto é feito para manter backups periódicos (diários, semanais, mensais) na máquina local.

É interessante manter uma cópia local dos backups dos últimos dias ou semanas, pois em caso de ocorrer a corrupção de informações, estes arquivos poderão ser utilizados. Se algo grave acontecer, sendo necessário a restauração completa de um backup, a utilização do backup mais recente é a melhor alternativa. Com o script a cópia mais recente estará armazenado na máquina remota.

Para chamar este script e definir as pastas que serão copiadas, bem como definir os backups que serão mantidos localmente, vamos utilizar outro script.

Salve o script abaixo na pasta /usr/local/scripts com o nome backup_diario.sh:

###################################################################
# backup_diario.sh
#
# Desenvolvido por: Nerd
# Data: 27-set-2010
# Objetivo: Realiza backup diario de arquivos do sistema (Mysql, SVN, arquivos)
# Funcionamento: - Realiza backup de pastas localmente e remotamente
# Parametros:    [Rótulo do backup] - opcional
#
# (c) Blog do Nerd 2010
###################################################################
#!/bin/bash

label=$1
if [ ! ${label} ]; then
	label="diario"
fi
random_log="/tmp/$RANDOM"

# Altere as variáveis abaixo para sua realidade
pasta_backup_local="/backup"
pasta_backup_remoto="/backup/${hostname}"
usuario_backup="backup"
servidor_backup="servbackup"
arquivo_log="/var/log/backup.log"
email="backup@dominio.com.br"
# Altere as variáveis acima para sua realidade

# Ajuste as chamadas abaixo para sua realidade
/bin/sh /usr/local/scripts/backup_dados.sh /etc etc ${label} ${pasta_backup_local} ${pasta_backup_remoto} ${usuario_backup} ${servidor_backup} > ${random_log} 2>&1
/bin/sh /usr/local/scripts/backup_dados.sh /var/www www ${label} ${pasta_backup_local} ${pasta_backup_remoto} ${usuario_backup} ${servidor_backup} > ${random_log} 2>&1
# Ajuste as chamadas acima para sua realidade

# Mantém backup diario dos últimos 7 dias.
find {pasta_backup_local} -name "*diario*" -type f -atime +6 -exec rm "{}" \;>> ${random_log} 2>&1

# Mantém backup semanal dos últimos 90 dias.
find {pasta_backup_local} -name "*semanal*" -type f -atime +90 -exec rm "{}" \; >> ${random_log} 2>&1

cat ${random_log} >> ${arquivo_log}

/bin/mail -s "[Backup Diário] $hostname" ${email} < ${random_log}

rm -f ${random_log}

exit 0

Altere o valor das variáveis abaixo, de forma a refletir sua realidade:

• pasta_backup_local - Pasta local que receberá uma cópia do backup
• pasta_backup_remoto - Pasta no servidor remoto, que receberá o backup
• usuario_backup - Usuário no servidor remoto que receberá o backup. É estritamente necessário a existencia de relação de confiança SSH entre o usuário local e o usuário configurado nesta variável
• servidor_backup - Nome DNS ou IP do servidor remoto que receberá o backup
• arquivo_log - Arquivo local que receberá o log do backup
• email - Endereço de e-mail que receberá uma cópia do log de execução do backup local

No script acima existem duas chamadas para o script de backup (/usr/local/scripts/backup_dados.sh). A primeira é para executar o backup da pasta /etc e adicionar o rótulo etc no nome do arquivo de backup. A segunda linha executa o backup da pasta /var/www e adiciona o rótulo www no nome do arquivo de backup.

Altere ou inclua mais pastas as quais deseja realizar backups.

Agende o script /usr/local/scripts/backup_diario.sh no agendador de tarefas da máquina local. Para isso, execute cron -e e inclua uma linha semelhante a seguinte:

15 3 * * * /bin/sh /usr/local/scripts/backup_diario.sh

A sintaxe das entradas no cron é a seguinte:

[minuto] [hora] [dia do mês] [mês] [dia da semana, domingo=0] [programa a ser executado]

Sendo que o caracter * simboliza qualquer valor. Desta forma a entrada no cron que criamos indica que será executado o backup diário todos os dias as 03:15 da manhã.

O script backup_local.sh irá manter na pasta de backup local uma cópia dos backups diários realizados nos últimos 7 dias e uma cópia dos backus semanais realizados nos últimos 90 dias.

Para agendar a execução de backups semanais, utilize o parametro semanal na chamado do script backup_local.sh. Um entrada cron semelhante a esta deverá ser utilizada:

40 3 * * 6 /bin/sh /usr/local/scripts/backup_diario.sh semanal

Com esta entrada no cron, será realizado um backup semanal todo sábado (6) às 03:40 da manhã. Ajuste a chamada conforme sua necessidade.

Espero que o artigo tenha sido útil. Qualquer dúvida, sugestão ou relato de erros é só postar nos comentários.

Realizando backup de arquivos em servidores Linux é uma publicação do Blog do Nerd.

Compartilhar / Favoritos

Quando se realiza backup de um servidor linux para outro através de scripts via SSH, é extremamente importante a utilização de relação de confiança entre os servidores. A relação de confiança permite que um usuário de um servidor linux se conecte via ssh em outro servidor linux sem precisar digitar senha alguma.

Isto pode soar estranho num primeiro momento, mas é algo extremamente importante e seguro quando implementado corretamente.

É muito melhor ter a relação de confiança via SSH do que configurar senhas em texto puro em scripts de automatização de backup e outras atividades. Aliás, não é só para backup que a relação de confiança pode ser utilizada. Já configurei este tipo de confiança para melhorar a segurança de conexões inseguras como MySQL e permitir uma conexão permanente de um servidor a outro na Internet. Também já utilizei este tipo de relação para acesso remoto a servidores, porém neste caso adicionando uma senha extra no certificado de autenticação da relação de confiança.

Este pequeno tutorial descreve os passos para estabelecer relação de confiança entre servidores Linux Ubuntu, porém pode ser aplicado para outras distribuições também, inclusive para outros sistemas operacionais. Ele faz parte da série de tutoriais sobre Backup de servidores Linux.

Pré-Requisitos

Você vai precisar de dois servidores Linux Ubuntu com o serviço de SSH instalado e habilitado e também do utilitário ssh-keygen, que normalmente já vem instalado junto com o SSH. Se você não tiver o SSH instalado execute:

$ sudo apt-get install ssh

Além disso você vai precisar das credencias de acesso de duas contas de usuário, uma em cada servidor onde será configurada a relação de confiança.

Tutorial

Iremos utilizar dois servidores: Servidor1 e Servidor2 e dois usuários: usuário1 e usuário2, onde usuário1 é uma conta de usuário do Servidor1 e usuário2 uma conta de usuário do Servidor2.

A idéia é configurar uma relação de confiança de modo que o usuário1 consiga, a partir de uma sessão no Servidor1, acessar o Servidor2 utilizando as credenciais do usuário2, sem digitar nenhuma senha. Em outras palavras, o usuário2 do Servidor2 confia no usuário1 do Servidor1, e por isso não pede senha.

Isto é feito baseado em criptografia assimétrica, onde o usuário1 possui duas chaves: uma pública e uma privada. O conceito é simples: tudo o que for criptografado com a chave pública só pode ser descriptografado com a chave privada e vice-versa (o que for criptografado com a chave privada só pode ser descriptografado com a chave pública).

A chave pública do usuário1 é colocada em um lugar específico da conta do usuário2, de forma que o serviço de SSH do Servidor2 consiga verificar a autenticidade do usuário1 através da criptografia e descriptografia de mensagens utilizando o par de chaves pública e privada do usuário1.

O que vamos fazer é:

1. Gerar o par de chaves (pública/privada) do usuário1
2. Copiar a chave pública do usuário1 para o Servidor2

ATENÇÂO: Jamais configure relação de confiança onde o usuário2 possua privilégios administrativos ou pior ainda se ele for o root do Servidor2. Se alguém conseguir comprometer o Servidor1, poderá facilmente acessar o Servidor2 através da relação de confiança. É claro que o atacante precisa saber que esta relação existe, mas isso não é muito difícil de se descobrir pesquisando em logs de execução, agendamento de scripts e outros arquivos. Também não recomendo que o usuário2 tenha privilégios para executar comandos como root (sudo). Apesar de ainda ser necessário digitar a senha do usuário2 para permitir a execução de comandos como root, um outro tipo de falha com o sudo poderia comprometer o servidor.

A figura abaixo ilustra as relações de confiança que podem e as que não devem ser feitas:

1. Gerar o par de chaves (pública/privada) do usuário1

Abra uma janela do shell ou se conecte via SSH ou console no Servidor1 com as credenciais do usuário1 e digite o seguinte comando:

$ ssh-keygen -t rsa

O ssh-keygen irá solicitar um caminho para armazenar a chave privada. Pressione enter para deixar o padrão. Irá solicitar também uma senha (passphrase) para proteger o par de chaves. Deixe em branco simplesmente pressionando enter. É importante que a passphase seja em branco pois senão teriamos que digitá-la toda vez que nos conectarmos ao Servidor2, e é justamente o que não queremos. Seu par de chaves será gerado e a saída (para o Ubuntu 10.04)  será a seguinte:

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/usuário1/.ssh/id_rsa):
Created directory '/home/usuário1/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/usuário1/.ssh/id_rsa.
Your public key has been saved in /home/usuário1/.ssh/id_rsa.pub.
The key fingerprint is:
ef:55:a6:8c:dc:21:02:78:e4:d5:b0:45:42:a9:ae:c4 usuário1@Servidor1
The key's randomart image is:
+--[ RSA 2048]----+
|    ... oo       |
|   ..+ . ..      |
|   .o = o        |
|  .  o +         |
|..      S . . o  |
| A.      + = =   |
|..        + =    |
|.        . .     |
|          .      |
+-----------------+

Dois arquivos são gerados:

1. /home/usuário1/.ssh/id_rsa: Contém a chave privada e deve ser mantido em segredo.
2. /home/usuário1/.ssh/id_rsa.pub: Contém a chave pública e deverá ser exportado para onde precisarmos da relação de confiança.

2. Copiar a chave pública do usuário1 para o Servidor2

No Servidor2 crie a pasta /home/usuário2/.ssh, caso ela ainda não exista, e configure permissão 700. Para fazer isso, digite, no Servidor2:

$ mkdir /home/usuário2/.ssh
$ chmod 700 /home/usuário2/.ssh

Copie o conteúdo do arquivo id_rsa.pub do usuário1 para o arquivo /home/usuário2/.ssh/authorized_keys. Você pode fazer isso digitando, no Servidor1, o seguinte comando:

$ cat /home/usuário1/.ssh/id_rsa.pub | ssh usuário2@Servidor2 'cat - >> ~/.ssh/authorized_keys'

Agora é só logar no Servidor2 a partir do Servidor1, sem precisar de senha:

$ ssh usuário2@Servidor2

A primeira vez que se conectar no Servidor2 uma mensagem informando que a autenticidade do host não pode ser estabelecida será mostrada. Você terá que responder yes para prosseguir. Isso irá guardar uma cópia da chave pública do Servidor2 no arquivo /home/usuário1/.ssh/know_hosts do Servidor1. Uma vez armazenada esta chave a pergunta de autenticidade nunca mais será solicitada, a não ser que o servidor ou seu hostname sejam alterados.

Para copiar um arquivo do Servidor1 para o Servidor2 você pode utilizar o scp:

$ scp arquivo_de_origem usuário2@Servidor2:caminho_de_destino

Por exemplo, para copiar o arquivo /etc/issue do Servidor1 para a pasta /tmp do Servidor2 digite:

$ scp /etc/issue usuário2@Servidor2:/tmp

Observações

Em caso de falhas de autenticação, verifique o final do arquivo /var/log/auth.log no Servidor2:

$ tail /var/log/auth.log

As falhas mais comuns estão relacionadas à permissão e propriedade das pastas. A pasta home do usuário tem que pertencer a ele mesmo e não pode ter permissão de escrita para grupos e outros. A pasta .ssh não pode ter permissão alguma para grupos e outros.

Você pode criar relações de confiança de vários servidores para um único, bastando para isso adicionar mais chaves públicas no arquivo authorized_keys utilizando o mesmo comando mostrado no passo 2.

Espero que o artigo tenha sido útil. Qualquer dúvida, sugestão ou relato de erros é só postar nos comentários.

Estabelecendo relação de confiança SSH entre servidores Linux é uma publicação do Blog do Nerd.

Compartilhar / Favoritos

Minha última publicação foi justamente sobre como fazer o e-DOC funcionar após a instalação da Atualização de Segurança KB980436 no Windows XP. Uma das soluções era desabilitar o uso do TLS 1.0 no Internet Explorer e a aplicação voltava a funcionar.

Como efeito colateral percebi que desabilitando esse mesmo recurso no Internet Explorer do Windows 7, a aplicação e-DOC consegue fazer o logon com sucesso, porém, no momento de envio de documentos, a parte Java da aplicação gera uma exceção por não conseguir gravar e nem acessar o arquivo C:\Windows\MSKeyStoreJNI.dll.

Descobri que instalando esta DLL manualmente e desabilitando o TLS 1.0, o e-DOC funciona corretamente no Windows 7.

Este pequeno tutorial descreve os passos para automatizar a instalação desta DLL para computadores com Windows 7 e que são membros de um domínio Microsoft Active Directory.

Pré-Requisitos

Para este tutorial você vai precisar:

• Computador com Windows 7 instalado.
• Arquivo MSKeyStoreJNI.dll, que pode ser obtido aqui.

Tutorial

Para fazer o e-DOC funcionar em um único computador, desabilite o TLS 1.0 no Internet Explorer e copie o arquivo MSKeyStoreJNI.dll na pasta C:\Windows.

Para saber como desabilitar o TLS 1.0 leia o artigo Sistema e-DOC da Justiça do Trabalho não funciona após atualizar o Windows.

Para instalar esta DLL em todos os computadores de um domínio Microsoft Active Directory, copie o arquivo MSKeyStoreJNI.dll para uma pasta compartilhada de sua rede, por exemplo a pasta NETLOGON. Salve o script abaixo em um arquivo com nome MSKeyStoreJNI.cmd:

@if not exist %windir%\MSKeyStoreJNI.dll copy \\domínio\netlogon\MSKeyStoreJNI.dll %windir%

Altere o valor \\domínio\netlogon\ para o caminho de rede em que salvou o arquivo MSKeyStoreJNI.dll.

Crie uma nova GPO e coloque o arquivo salvo como script de logon de computador.

Se quiser utilizar uma GPO para desativar o TLS 1.0 para todos os computadores de seu domínio, verifique o artigo anterior.

Prontinho, agora é só se conectar no e-DOC e enviar seus pareceres.

Observações

Isto não seria necessário se a aplicação Java do e-DOC solicitasse adequadamente privilégios administrativos para escrever um arquivo na pasta C:\Windows ou ainda que independesse dessa DLL para funcionar.

Neste link você pode ler um artigo interessante sobre como desenvolver aplicações Java que respeitem o recurso de User Access Control do Windows 7 e solicitar elevação de privilégios para tarefas administrativas.

Espero que o artigo tenha sido útil. Qualquer dúvida, sugestão ou relato de erros é só postar nos comentários.

Usando o e-DOC com o Windows 7 é uma publicação do Blog do Nerd.

Compartilhar / Favoritos