Tweet
Criei este artigo com a ajuda de todos os contribuintes com sites e outros artigos para a instalação de um servidor com firewall iptables para compartilhar a internet, proxy Squid, Sarg para monitoração dos acessos e com iptraf para monitoramento dos pacotes da rede.
Por: Rafael da Silva Rosa
Sumário
Neste projeto foi usado um micro para agir na rede como firewall de filtragem de pacotes e proxy. Para filtragem de pacotes recebidos da internet usamos o iptables v1. 4.2, Squid versão 2.5 STABLE14 e sistema operacional Debian Etch GNU/Linux com o kernel 2.6.18-6-k7. Para controle de relatórios de acesso usei o Sarg 2.2.5 e para controle de pacotes usei o Iptraf 3.0.0. Como método de segurança na autenticação de senhas usei o Kerberos v5.
Descrição dos softwares:
Firewall Iptables
Firewall pode ser definido como uma barreira de proteção, que controla o tráfego de dados entre seu computador e a Internet (ou entre a rede onde seu computador está instalado e a Internet). Seu objetivo é permitir somente a transmissão e a recepção de dados autorizados. Existem firewalls baseados na combinação de hardware e software e firewalls baseados somente em software. Este último é o tipo recomendado ao uso doméstico e também é o mais comum.
Explicando de maneira mais precisa, o firewall é um mecanismo que atua como "defesa" de um computador ou de uma rede, controlando o acesso ao sistema por meio de regras e a filtragem de dados. A vantagem do uso de firewalls em redes, é que somente um computador pode atuar como firewall, não sendo necessário instalá-lo em cada máquina conectada.
Como funciona: Há mais de uma forma de funcionamento de um firewall, que varia de acordo com o sistema, aplicação ou do desenvolvedor do programa. No entanto, existem dois tipos básicos de conceitos de firewalls: o que é baseado em filtragem de pacotes e o que é baseado em controle de aplicações. Ambos não devem ser comparados para se saber qual o melhor, uma vez que cada um trabalha para um determinado fim, fazendo que a comparação não seja aplicável. Conheça cada tipo a seguir. No nosso caso usamos o modo FILTRAGEM DE PACOTES.
Filtragem de pacotes: O firewall que trabalha na filtragem de pacotes é muito utilizado em redes pequenas ou de porte médio. Por meio de um conjunto de regras estabelecidas, esse tipo de firewall determina que endereços IPs e dados possam estabelecer comunicação e/ou transmitir/receber dados. Alguns sistemas ou serviços podem ser liberados completamente (por exemplo, o serviço de e-mail da rede), enquanto outros são bloqueados por padrão, por terem riscos elevados (como softwares de mensagens instantâneas, tal como o ICQ). O grande problema desse tipo de firewall, é que as regras aplicadas podem ser muito complexas e causar perda de desempenho da rede ou não ser eficaz o suficiente.
Este tipo se restringe a trabalhar nas camadas TCP/IP, decidindo quais pacotes de dados podem passar e quais não. Tais escolhas são regras baseadas nas informações endereço IP remoto, endereço IP do destinatário, além da porta TCP usada.
Quando devidamente configurado, esse tipo de firewall permite que somente "computadores conhecidos troquem determinadas informações entre si e tenham acesso a determinados recursos". Um firewall assim, também é capaz de analisar informações sobre a conexão e notar alterações suspeitas, além de ter a capacidade de analisar o conteúdo dos pacotes, o que permite um controle ainda maior do que pode ou não ser acessível.
Iptraf
Iptraf é um programa que possui a função de monitorar a rede a qual o seu computador está conectado, através de dados transmitidos sobre os protocolos IP/TCP e UDP/IP, entre outros. O aplicativo tem a capacidade de exibir diversas estatísticas, como número de pacotes e seus respectivos tamanhos, além da velocidade de suas transmissões. O programa funciona em modo texto, em algum terminal de sistema, como o Konsole.
A princípio é possível aplicar IPTRAF em diversas tecnologias de rede físicas distintas, entre elas: Ethernet, FDDI, SLIPP e interfaces de loopback. Além das várias redes, é possível também utilizar o programa para monitorar diversos protocolos distintos.
Squid
O Squid é um servidor proxy que suporta HTTP, HTTPS, FTP e outros. Ele reduz a utilização da conexão e melhora os tempos de resposta fazendo cache de requisições frequentes de páginas web numa rede de computadores. Ele pode também ser usado como um proxy reverso. No cache são armazenados os objetos da Internet (ex. dados de páginas web) disponíveis via protocolo HTTP, FTP e Gopher num sistema mais próximo ao do cliente.
Os navegadores podem então usar o Squid local como um servidor Proxy HTTP, reduzindo o tempo de acesso aos objetos e reduzindo a utilização da conexão. Isto é muito usado por provedores no mundo todo para melhorar a velocidade de navegação para seus clientes e também em LAN que compartilham a mesma conexão à Internet.
Ele pode fornecer anonimato e segurança dado ser um intermediário no acesso aos objetos. No entanto a sua utilização pode gerar preocupações a respeito da privacidade pois o Squid é capaz de armazenar registos sobre os acessos, incluindo URLs acedidas, a data e hora exatas, e quem acedeu. Isto é usado frequentemente nas empresas para controlarem o acesso à Internet dos seus funcionários.
A aplicação cliente (ex.navegador) deverá especificar explicitamente o servidor proxy que quer utilizar (típico para os clientes de provedores), ou poderá utilizar uma proxy sem qualquer configuração extra: caching transparente, em que todos os pedidos HTTP para fora, são interceptados pelo Squid e todas as respostas são armazenadas em cache. Este é uma típica configuração em corporações (todos os clientes na mesma rede local) e introduz as preocupações com privacidade mencionadas acima.
Squid tem algumas funcionalidades que permitem tornar as conexões anônimas, tais como desabilitar ou alterar campos específicos do cabeçalho dos pedidos HTTP do cliente. Se isto é feito e como, é controlado pela pessoa que administra a máquina que corre o Squid. As pessoas que requisitam páginas numa rede que usa Squid de forma transparente podem não saber que esta informação está a ser registada. Em determinados países, os utilizadores devem ser informados sobre a possível monitorização e registo das ligações internet.
Sarg
O Sarg é um interpretador de logs para o Squid, assim como o Webalizer e o Apache. Sempre que executado ele cria um conjunto de páginas, divididas por dia, com uma lista de todas as máquinas que foram acessadas e a partir de cada máquina da rede veio cada acesso. Ele também mostra os usuários, caso o Squid esteja configurado para exigir autenticação.
A partir daí você pode acompanhar as páginas que estão sendo acessadas, mesmo que não exista nenhum filtro de conteúdo e tomar as medidas cabíveis em casos de abuso. Todos sabem que os filtros de conteúdo nunca são completamente eficazes, eles sempre bloqueiam algumas páginas úteis e deixam passar muitas páginas impróprias. Se você tiver algum tempo para ir acompanhando os logs, a inspeção manual é sempre o método mais eficiente.
Kerberos
Kerberos é um protocolo de autenticação de rede que oferece um método extremamente seguro para autenticar clientes e servidores (entidades de segurança) de uma rede. Essas entidades de segurança usam uma autenticação baseada em chaves mestras e permissões criptografadas.
No modelo de protocolo Kerberos, todas as conexões de cliente/servidor começam com a autenticação. Por sua vez, cliente e servidor seguem uma sequência de ações que se destinam a verificar em uma ponta da conexão se a outra ponta é verdadeira. Se a autenticação tiver êxito, a configuração da sessão será concluída e uma sessão cliente/servidor segura será estabelecida.
Entre os principais benefícios da autenticação Kerberos estão:
* Autenticação mútua. O cliente pode validar a identidade da entidade de servidor e o servidor pode validar o cliente. Com essa documentação, as duas entidades são denominadas "cliente" e "servidor" mesmo que seja possível estabelecer conexões seguras de rede entre servidores.
* Permissões de autenticação seguras. São utilizadas somente permissões criptografadas, e as senhas nunca são incluídas na permissão.
* Autenticação integrada. Uma vez que o usuário faça logon, ele não precisa efetuar logon novamente para acessar algum serviço que suporte a autenticação Kerberos, pois a permissão do cliente não expira. Todas as permissões têm um prazo de validade determinado pelas diretivas do Kerberos que geram a permissão.
O Kerberos oferece um mecanismo para autenticação mútua entre entidades antes do estabelecimento de uma conexão de rede segura. Kerberos usa terceiros confiáveis, o KDC (Key Distribution Center), para facilitar a geração e a distribuição segura de permissões de autenticação e chaves de sessões simétricas. O KDC é executado como um serviço em um servidor seguro e mantém um banco de dados para todas as entidades de segurança de seu território. No contexto de Kerberos, um território é o equivalente a um domínio do Windows.
Mas também temos as desvantagens que precisam ser mostradas:
* Migrar senhas de usuário de um banco de dados UNIX padrão, como o /etc/passwd ou o /etc/shadow, para um banco de dados de senhas Kerberos pode ser entediante, pois não há um mecanismo automatizado para executar esta tarefa.
* O Kerberos tem apenas compatibilidade parcial com os Módulos de Autenticação Plugáveis (PAM), sistema usado pela maioria dos servidores Red Hat Enterprise Linux.
* O Kerberos presume que cada usuário é confiável e está usando uma máquina não confiável em uma rede não confiável. Seu objetivo principal é evitar que senhas não criptografadas sejam enviadas pela rede. No entanto, se alguém além do usuário legítimo tiver acesso à máquina que emite tickets usados para autenticação - chamada de centro de distribuição de chave (KDC) - o sistema de autenticação inteiro do Kerberos estará em risco.
* Para que um aplicativo use o Kerberos, sua fonte deve ser alterada para fazer as chamadas apropriadas às bibliotecas do Kerberos. Os aplicativos modificados desta maneira são considerados kerberizados. Para alguns aplicativos, isto pode ser bastante problemático devido ao tamanho ou design do aplicativo. Para outros aplicativos incompatíveis, as alterações devem ser feitas na maneira como o lado servidor e clientes se comunicam. Vale frisar que isto pode requerer uma programação extensiva. Aplicativos de código fechado que não têm suporte ao Kerberos por padrão são geralmente os mais problemáticos.
* O Kerberos é uma solução 'tudo ou nada'. Se ele for utilizado na rede, quaisquer senhas não criptografadas transferidas a um serviço não-kerberizado estão em risco. Portanto, a rede não se beneficia do uso do Kerberos. Para proteger uma rede com o Kerberos, devem-se utilizar versões kerberizadas de todos os aplicativos cliente/servidor que enviam senhas não criptografadas ou não usar nenhum aplicativo do tipo cliente/servidor.
Como tudo funciona
O firewall foi criado com regras para compartilhar a internet, lembrando que temos 2 interfaces de rede, sendo 1 para (rede local) e outra para receber a internet a (Ethernet). Nele, acrescentei as regras para redirecionamento, liberação e bloqueio de portas, liberação da rede local e loopback, bloqueio para rede externa, Nat, mascaramento da rede, redirecionamento da porta 80 para o proxy e o bloqueio do restante. Ainda estou estruturando da o firewall da melhor maneira, mas por enquanto é o necessário.
O Squid funciona como o gerente do acesso a internet, liberando o que for preciso e bloqueando o restante. Nele criei regras para o bloqueio de sites, palavras, streamings, downloads e regras para liberar os mesmos quando for preciso. Sua autenticação é feita no Active Directory via NTLM. Ele autentica pela senha do usuário logado na estação de trabalho.
Como o NTLM funciona
As etapas a seguir apresentar um esboço de autenticação NTLM não interativo. O primeiro passo fornece as credenciais NTLM do utilizador e só ocorre como parte da autenticação interativa (logon) do processo.
Autenticação Interactive apenas - um usuário acessa um computador cliente e fornece um nome de domínio, nome de usuário e senha. hash O cliente calcula a criptografia hash da senha e descarta a senha real.
plaintext - o cliente envia o nome de usuário para o servidor (no texto original).
nonce - o servidor gera um byte aleatório número 16, chamado de desafio ou nonce, e envia para o cliente. O cliente criptografa o desafio com o hash da senha do usuário e retorna o resultado para o servidor. Isso é chamado de a resposta.
O servidor envia os seguintes três itens para o controlador de domínio:
* Nome de usuário
* Desafio enviado para o cliente
* Resposta recebida do cliente
O controlador de domínio usa o nome de usuário para recuperar o hash da senha do usuário do banco de dados Security Account Manager. Ele usa este hash de senha para criptografar o desafio.
O controlador de domínio compara o desafio é criptografado computadorizada (na etapa 6) a resposta calculada pelo cliente (na etapa 4). Se forem idênticos, a autenticação é bem sucedida.
O kerberos funciona como segurança para essa autenticação, pois invés de se usar as senhas e usuários como em outros métodos de autenticação ele usa "Tickets". Vamos entender melhor.
Vejamos como o Kerberos trabalha. Usuários e serviços que utilizem o Kerberos possuem chaves armazenadas no AS. As chaves dos usuários são derivadas de senhas escolhidas por estes, e as chaves dos serviços são geradas aleatoriamente.
Para esta explicação, imaginemos que as mensagens são escritas em papel, e são criptografadas colocando-as em uma caixa-forte, associada a uma chave.
Primeiro o usuário envia uma mensagem ao AS: "Eu, J. Random User gostaria de falar com o servidor Foo".
Quando o AS recebe a mensagem, ele faz duas cópias de uma nova chave registrada. Estas chaves são chamadas de chaves de sessão. Elas serão usadas nas trocas diretas entre serviço e usuário.
Ele coloca uma das chaves de sessão na Caixa 1, junto com um pedaço de papel com o nome "Servidor Foo" escrito. A caixa é trancada com a chave do usuário (o AS conhece todas as chaves de usuário e todas as chaves de serviço).
Por que este papel aqui? Devemos nos lembra que a caixa é na realidade apenas uma mensagem criptografada, e que a chave de sessão é uma sequência randômica de bytes. Se a Caixa 1 somente contivesse a chave de sessão, o usuário não teria como reconhecer se a resposta veio do AS, ou não saberia se a decriptação teve sucesso. Pela adição da mensagem "Servidor Foo", o usuário (mais precisamente a aplicação do usuário) poderia saber se a caixa veio do AS, e se a decriptação obteve sucesso.
Ele coloca a outra chave de sessão em uma Caixa 2, junto com um pedaço de papel com o nome "J. Random User". Esta caixa é fechada com a chave do serviço.
Ele envia ambas as caixas ao usuário. Na versão 4 do Kerberos, a Caixa 2 era colocada (sem necessidade) dentro da caixa 1, mas na versão 5 isto foi corrigido. O usuário destranca a Caixa 1 com sua chave, extraindo assim a chave de sessão e o papel com o nome "Servidor Foo" escrito nele.
O usuário não consegue abrir a Caixa 2 (ela foi trancada com a chave do serviço, que só o AS e o serviço conhecem). Então ele coloca um pedaço de papel com a hora corrente numa Caixa 3, e tranca esta com chave de sessão, e envia ambas ao serviço.
O serviço abre a Caixa 2 com sua própria chave, extraindo a chave de sessão e o papel com "J. Random User" escrito nele. Ele abre a Caixa 3 com a chave de sessão para extrair o pedaço de papel com a hora corrente nele. Estes itens demonstram a identidade do usuário.
O timestamp é colocado na Caixa 3 para prevenir que alguém faça uma cópia da Caixa 2 (devemos nos lembrar que as caixas são na verdade mensagens eletrônicas) e a utilize para se passar pelo usuário mais tarde. Como os relógios da rede nunca são perfeitamente sincronizados, uma pequena margem (em geral 5 minutos) é permitida entre o timestamp e a hora atual. Além disto, o serviço mantém uma lista das autenticações recebidas recentemente para garantir que elas não foram reenviadas.
A chave de serviço é gerada aleatoriamente e armazenada em um arquivo especial chamado de SECRETE KEY FILE. O Kerberos assume que este é seguro, que ninguém pode copiá-lo e se passar pelo serviço.
No Kerberos, a Caixa 2 é chamada de ticket, e a Caixa 3 de authenticator. O authenticator tipicamente contém mais informações do que as listadas acima. Algumas destas informações são adicionadas em decorrência do fato de que as mensagens são eletrônicas (por exemplo, existem checksum). Pode existir também uma chave secreta usada para criptografar as mensagens que serão trocadas entre usuário e serviço após a autenticação, garantindo assim a privacidade.
Instalando o Kerberos
Estou partindo do princípio que na rede a ser implementada essa solução já exista um Active Directory e um servidor DNS instalado. O servidor DNS é de fundamental importância para o trabalho do Kerberos assim como um servidor de NTP. Então instale esse 3 serviços na rede e configure-os da maneira correta. Antes da instalação do cliente kerberos atente para os seguinte itens:
Antes de instalar qualquer coisa, verificar se o sistema operacional usado está atualizado para não haver nenhum problema como por exemplo: instalar o pacote apt-build que contém compiladores entre outros softwares.
Primeiro, edite o arquivo /etc/hosts colocando o nome e o ip do seu Domain Controller:
# vi /etc/hosts
Obs.: Onde está xxx.xxx.xxx.xxx coloque o ip servidor Active Directory.
Depois edite o seu resolv.conf e coloque o nome do servidor DNS:
# vi /etc/resolv.conf
Obs.: Onde está xxx.xxx.xxx.xxx coloque o ip servidor DNS.
Depois atualize o relógio do micro com o servidor Ntp da rede ou com um Ntp Server.
# ntpdate [nome do servidor ntp]
ou
# ntpdate ntp.cais.rnp.br (onde está nome do servidor é o servidor de Ntp da rede)
Para instalar o ntpdate use:
# apt-get install ntpdate
Depois vá até seu servidor DNS e crie um host para seu servidor Proxy com o ip do mesmo.
Agora vamos instalar o cliente Kerberos:
# apt-get install krb5-kdc krb5-config krb5-clients libpam-krb5 krb5-user
Obs.: Se for pedido o nome do domínio, disponibilize.
Depois é necessário alterar o aquivo /etc/krb5.conf:
# vi /etc/krb5.conf
Obs.: Onde está xxx.xxx.xxx.xxx coloque o ip do Domain Controller e onde está ELETROMOTORES.COM.BR troque pelo domínio da rede respeitando maiúsculas e minúsculas.
Depois altere o arquivo /etc/krb5kdc/kdc.conf:
# vi /etc/krb5kdc/kdc.conf
Obs.: Faça o mesmo do que no arquivo anterior troque ELETROMOTORES.COM.BR pelo domínio usado na rede.
Depois altere o arquivo /etc/default/krb5-kdc:
# vi /etc/default/krb5-kdc
bs.: Isso é para desabilitar o Kerberos 4.
Em seguida, vamos iniciar a comunicação entre o Linux e o Domain Controller utilizando Kerberos.
# kinit administrator@ELETROMOTORES.COM.BR
Lembrando que estamos usando o domínio ELETROMOTORES.COM.BR como teste, então troque pelo domínio da sua rede.
Será solicitada a senha do usuário "administrator". Depois deste passo use o comando klist e veja se retorna isto:
# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: administrator@LAB.VIRTUAL
Valid starting Expires Service principal
02/22/07 14:25:47 02/23/07 00:25:47 krbtgt/LAB.VIRTUAL@LAB.VIRTUAL
Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached
Caso não seja este o retorno do comando, reveja os passos acima. Gostaria de salientar que encontrei diversos sites com abordagens da instalação do Kerberos no Linux e seus arquivos .conf, mas a única maneira que consegui realizar os testes foi com os arquivos .conf desta maneira descrita no projeto. Portanto se copiarem como está no projeto e só trocar o que for pedido correrá tudo certo. Para testes execute o comando kinit com outros usuários do domínio.
Em seguida vamos editar o arquivo nsswitch.conf:
# vi /etc/nsswitch.conf
Alterar as linhas:
De:
passwd: compat
group: compat
Para:
Instalando o Winbind
Descrição dos componentes usados:
Samba
O Samba é um "software servidor" para Linux (e outros sistemas baseados em Unix) que permite o gerenciamento e compartilhamento de recursos em redes formadas por computadores com o Windows. Assim, é possível usar o Linux como servidor de arquivos, servidor de impressão, entre outros, como se a rede utilizasse servidores Windows (NT, 2000, XP, Server 2003). Este artigo faz uma abordagem introdutória ao Samba, mostrando suas principais características e um pouco de sua história.
Winbind
O Windbind faz a integração entre o Linux e o Domínio NT e toda a comunicação com o Domínio NT é realizada através do Samba, neste caso apenas o Samba-client é utilizado, ou seja, sem carregar o serviço smb. O winbind é responsável por fazer a autenticação usando o NTLM.
Na verdade dentro do pacote samba contém o winbind se fizéssemos o download do samba via wget precisaríamos apenas compilar para usarmos o winbind, mas eu preferi instalar os dois, ai fica a gosto do freguês. A instalação do SAMBA e do WINBIND é simples e pode ser feita via apt-get. Então, vamos por a mão na massa:
# apt-get install samba winbind
Após rodarmos o comando acima, será aberta uma tela de configuração, onde é solicitado o nome do domínio, o uso de senhas encriptadas, que OBRIGATORIAMENTE tem que ser SIM e também é necessário que o samba crie o arquivo de senhas.
Agora é necessário configurar o samba. Para isso, vamos fazer backup do arquivo original e depois vamos criar o nosso arquivo de configuração.
# mv /etc/samba/smb.conf /etc/samba/smb.original
# vi /etc/samba/smb.conf
O arquivo smb.conf deve conter OBRIGATORIAMENTE as linhas abaixo. Outras configurações podem ser feitas de acordo com a necessidade.
Lembre-se de trocar o domínio na 1º linha mas coloque só o nome do domínio sem .com.br e colocar o nome do micro que será o proxy na 2º linha. Onde está password server coloque o ip do Domain Controller e onde está o Wins Server coloque o ip do servidor Dns que no meu caso é o mesmo do Domain Controller.
Criado o arquivo de configuração, vamos reiniciar os serviços do Samba e do Winbind.
# /etc/init.d/samba stop
# /etc/init.d/winbind stop
# /etc/init.d/samba start
# /etc/init.d/winbind start
Não se esqueça de verificar os logs para saber se tudo iniciou corretamente.
Agora vamos colocar a máquina Linux no domínio Windows.
# net ads join -U administrator -S ELETROMOTORES
Após digitar a senha, que será solicitada, o retorno deve ser semelhante ao retornado abaixo:
Pronto! A máquina que está rodando o LINUX já faz parte do Domínio Microsoft e pode ser vista no Active Directory Users and Computers.
Você também pode usar o seguinte comando:
# net rpc join ELETROMOTORES -S servidor -Uadministrador
Troque onde está ELETROMOTORES pelo seu domínio onde está SERVIDOR pelo nome do Domain Controller e ADMINISTRADOR por um usuário que tenha permissão de administrador ou pelo próprio mesmo.
Verificando se o Winbind está comunicando com o RPC Server:
# wbinfo -t
Retorno esperado: checking the trust secret via RPC calls succeeded
Listando usuários do AD:
# wbinfo -u
Listando os grupos do AD:
# wbinfo -g
Se não for esse o retorno, revise os passos acima.
Instalando o Squid
O Squid deve ser instalado pelo source, pois usaremos algumas opções específicas que não são utilizadas ao usar o apt-get. Recomendo a utilização da versão 2.5, pois quando utilizei a 2.6-STABLE não funcionou de acordo, mas não testei as versões mais novas.
Vamos ao que interessa!
Entrando no diretório de sources:
# cd /usr/src
Efetuando o download do pacote estável:
# wget Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
Descompactando:
# tar zxvf squid-2.5.STABLE14.tar.gz
Acessando o diretório do Squid/Source:
# cd squid-2.5.STABLE14
Compilando com as opções necessárias:
# ./configure --prefix=/usr --exec_prefix=/usr --bindir=/usr/sbin --sbindir=/usr/sbin --libexecdir=/usr/lib/squid --sysconfdir=/etc/squid --localstatedir=/var/spool/squid --datadir=/usr/share/squid --enable-auth="ntlm,basic" --enable-basic-auth-helpers="winbind" --enable-ntlm-auth-helpers="winbind" --enable-external-aclhelpers="winbind_group,wbinfo_group" --enable-delay-pools --enable-removal-policies --enable-underscores --enable-cache-digests --disable-ident-lookups --enable-truncate --enablearp-acl --with-winbind-auth-challenge
Instalando:
# make && make install
Criando o grupo para utilizar o Squid:
# groupadd proxy
Criando o usuário e colocando-o no grupo do Squid:
# useradd proxy -g Proxy
Dando permissão para o diretório do Squid:
# chown -R proxy.proxy /usr/share/squid
# chown -R proxy.proxy /var/spool/squid
Efetuando backup do arquivo de configuração original:
# cd /etc/squid/etc
# mv squid.conf squid.original
Limpando todas as linhas comentadas do squid.original e gerando o squid.conf:
# egrep -v "^#|^$" squid.original > squid.conf
Gerando o diretório de logs e liberando as permissões:
# mkdir /var/log/squid
# chown -R proxy.proxy /var/log/squid
Liberando a permissão no arquivo do Winbind:
# chown root.proxy /var/run/samba/winbindd_privileged
Reiniciando o Winbind:
# /etc/init.d/winbind stop & /etc/init.d/winbind start
Editando o arquivo squid.conf e colocando as linhas abaixo:
# vi /etc/squid/squid.conf
Lembrando que esse squid.conf é um exemplo somente, pode ser modificado conforme diversos sites na internet e conforme o site do próprio Squid.
Criando o cache e iniciando o Squid:
# squid -z
# squid &
Caso dê algum erro no procedimento, revisá-lo, mas geralmente dá-se erro na criação do cache se isso ocorrer de permissão e crie a pasta cache no /var/squid.
# mkdir cache /var/squid
# chown -R proxy.proxy /var/squid/cache
Para utilizar as regras baseadas em grupos do Active Directory, utilize as seguintes linhas no seu squid.conf:
Depois de editar o seu squid.conf, não esqueça de recarregá-lo:
# squid -k reconfigure
Execute o Squid:
# squid
Configure o proxy no IE:
* Proxy: IP do seu servidor de proxy
* Porta 3128
Testes
Monitorando o arquivo de log de acessos do Squid com o comando "tail -f" vemos que o acesso foi liberado utilizando o usuário GK, que é o usuário logado na estação de trabalho.
# tail -f /var/log/squid/access.log
Instalação do Sarg
Instalando e configurando o Sarg:
# apt-get install update
# apt-get install sarg
Após o processo de instalação, o principal arquivo de configuração denominado 'sarg.conf' poderá ser localizado no diretório /etc/squid. Apenas para efeitos de backup, pois é sempre bom se ter o arquivo original em reserva para eventuais problemas que possam surgir.
Crie o seu próprio 'sarg.conf':
# touch sarg.conf
Edite o arquivo utilizando o seu editor de preferência (no meu caso o mcedit) e adicione o conteúdo abaixo ao mesmo:
Algumas TAGs podem ser modificadas sem maiores problemas, pois tratam-se apenas de formatação dos relatórios, outras tratam-se dos caminhos de arquivos importantes ao bom funcionamento do Sarg e o restante diz respeito a forma que o mesmo vai funcionar, por isso, é de alta importância uma revisão com fins de verificar se existe alguma discrepância entre os dados do sarg.conf aqui sugerido e as características de seu servidor.
As TAGs apresentadas abaixo são exatamente as que indicarão ao Sarg que nos relatórios gerados por ele deverá aparecer ao invés do endereço IP, o nome do usuário ou máquina devidamente setado por você.
Logo após o arquivo criado e salvo, procure no mesmo diretório (/etc/squid) um arquivo denominado 'sarg.usertab', se ele não existir, fique calmo (hehehe), crie-o você mesmo. Este arquivo será altamente importante para que nosso trabalho tenha o devido sucesso. É nele que o administrador irá setar os IPs das máquinas e o nome equivalente as mesmas. O conteúdo a ser adicionado no mesmo é exemplificado abaixo, sendo mudado de acordo com sua rede.
Exemplo:
Esta é a forma correta do arquivo, qualquer outra forma não dará o resultado esperado. Na ÚLTIMA LINHA do arquivo 'sarg.usertab' adicione o caractere '#'.
Como visto acima, é o 'sarg.usertab' que possibilita ao Sarg mostrar nomes amigáveis ao invés de endereços IPs, fator muito útil em redes de grande porte e não menos importante em pequenas redes.
Gerando os relatórios
Criaremos agora o script que irá orientar ao Sarg sobre o total de dias que se deseja apresentar nos relatórios. Crie um arquivo dentro do diretório /etc/squid denominado 'sarg.sh':
# touch diario.sh
Dê permissão total:
# chmod 777 sarg.sh
Para gerar os relatórios diariamente, insira o conteúdo abaixo no arquivo recém-criado (/etc/squid/sarg.sh):
Para os relatórios semanalmente crie outro arquivo com o conteúdo:
# touch semanal.sh
Para gerar os relatórios mensalmente outro arquivo:
# touch mensal.sh
Muitos usam o crontab para gerar os relatórios, mas eu os gero executando os executáveis quando eu quero pois minha rede é pequena e não preciso dos relatórios sempre. Mas fica a dica.
Instalação do Iptraf
Esse não tem segredo, mas muito bom para administradores de rede conforme orientação do próprio projeto. Então vamos lá, para instalá-lo:
# apt-get install iptraf
Para usá-lo:
# iptraf
Conclusão
Existem diversos sites com explicações e maneiras de se instalar o Squid com autenticação, mas preferi essa por ser considerada mais segura e de maior facilidade. Espero ter ajudado a muitos que igual a mim montar um servidor como o descrito. Gostaria de agradecer a todos os autores e sites descrevo na bibliografia. Muito obrigado.
Bibliografia
Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
Por: Rafael da Silva Rosa
Sumário
Neste projeto foi usado um micro para agir na rede como firewall de filtragem de pacotes e proxy. Para filtragem de pacotes recebidos da internet usamos o iptables v1. 4.2, Squid versão 2.5 STABLE14 e sistema operacional Debian Etch GNU/Linux com o kernel 2.6.18-6-k7. Para controle de relatórios de acesso usei o Sarg 2.2.5 e para controle de pacotes usei o Iptraf 3.0.0. Como método de segurança na autenticação de senhas usei o Kerberos v5.
Descrição dos softwares:
Firewall Iptables
Firewall pode ser definido como uma barreira de proteção, que controla o tráfego de dados entre seu computador e a Internet (ou entre a rede onde seu computador está instalado e a Internet). Seu objetivo é permitir somente a transmissão e a recepção de dados autorizados. Existem firewalls baseados na combinação de hardware e software e firewalls baseados somente em software. Este último é o tipo recomendado ao uso doméstico e também é o mais comum.
Explicando de maneira mais precisa, o firewall é um mecanismo que atua como "defesa" de um computador ou de uma rede, controlando o acesso ao sistema por meio de regras e a filtragem de dados. A vantagem do uso de firewalls em redes, é que somente um computador pode atuar como firewall, não sendo necessário instalá-lo em cada máquina conectada.
Como funciona: Há mais de uma forma de funcionamento de um firewall, que varia de acordo com o sistema, aplicação ou do desenvolvedor do programa. No entanto, existem dois tipos básicos de conceitos de firewalls: o que é baseado em filtragem de pacotes e o que é baseado em controle de aplicações. Ambos não devem ser comparados para se saber qual o melhor, uma vez que cada um trabalha para um determinado fim, fazendo que a comparação não seja aplicável. Conheça cada tipo a seguir. No nosso caso usamos o modo FILTRAGEM DE PACOTES.
Filtragem de pacotes: O firewall que trabalha na filtragem de pacotes é muito utilizado em redes pequenas ou de porte médio. Por meio de um conjunto de regras estabelecidas, esse tipo de firewall determina que endereços IPs e dados possam estabelecer comunicação e/ou transmitir/receber dados. Alguns sistemas ou serviços podem ser liberados completamente (por exemplo, o serviço de e-mail da rede), enquanto outros são bloqueados por padrão, por terem riscos elevados (como softwares de mensagens instantâneas, tal como o ICQ). O grande problema desse tipo de firewall, é que as regras aplicadas podem ser muito complexas e causar perda de desempenho da rede ou não ser eficaz o suficiente.
Este tipo se restringe a trabalhar nas camadas TCP/IP, decidindo quais pacotes de dados podem passar e quais não. Tais escolhas são regras baseadas nas informações endereço IP remoto, endereço IP do destinatário, além da porta TCP usada.
Quando devidamente configurado, esse tipo de firewall permite que somente "computadores conhecidos troquem determinadas informações entre si e tenham acesso a determinados recursos". Um firewall assim, também é capaz de analisar informações sobre a conexão e notar alterações suspeitas, além de ter a capacidade de analisar o conteúdo dos pacotes, o que permite um controle ainda maior do que pode ou não ser acessível.
Iptraf
Iptraf é um programa que possui a função de monitorar a rede a qual o seu computador está conectado, através de dados transmitidos sobre os protocolos IP/TCP e UDP/IP, entre outros. O aplicativo tem a capacidade de exibir diversas estatísticas, como número de pacotes e seus respectivos tamanhos, além da velocidade de suas transmissões. O programa funciona em modo texto, em algum terminal de sistema, como o Konsole.
A princípio é possível aplicar IPTRAF em diversas tecnologias de rede físicas distintas, entre elas: Ethernet, FDDI, SLIPP e interfaces de loopback. Além das várias redes, é possível também utilizar o programa para monitorar diversos protocolos distintos.
Squid
O Squid é um servidor proxy que suporta HTTP, HTTPS, FTP e outros. Ele reduz a utilização da conexão e melhora os tempos de resposta fazendo cache de requisições frequentes de páginas web numa rede de computadores. Ele pode também ser usado como um proxy reverso. No cache são armazenados os objetos da Internet (ex. dados de páginas web) disponíveis via protocolo HTTP, FTP e Gopher num sistema mais próximo ao do cliente.
Os navegadores podem então usar o Squid local como um servidor Proxy HTTP, reduzindo o tempo de acesso aos objetos e reduzindo a utilização da conexão. Isto é muito usado por provedores no mundo todo para melhorar a velocidade de navegação para seus clientes e também em LAN que compartilham a mesma conexão à Internet.
Ele pode fornecer anonimato e segurança dado ser um intermediário no acesso aos objetos. No entanto a sua utilização pode gerar preocupações a respeito da privacidade pois o Squid é capaz de armazenar registos sobre os acessos, incluindo URLs acedidas, a data e hora exatas, e quem acedeu. Isto é usado frequentemente nas empresas para controlarem o acesso à Internet dos seus funcionários.
A aplicação cliente (ex.navegador) deverá especificar explicitamente o servidor proxy que quer utilizar (típico para os clientes de provedores), ou poderá utilizar uma proxy sem qualquer configuração extra: caching transparente, em que todos os pedidos HTTP para fora, são interceptados pelo Squid e todas as respostas são armazenadas em cache. Este é uma típica configuração em corporações (todos os clientes na mesma rede local) e introduz as preocupações com privacidade mencionadas acima.
Squid tem algumas funcionalidades que permitem tornar as conexões anônimas, tais como desabilitar ou alterar campos específicos do cabeçalho dos pedidos HTTP do cliente. Se isto é feito e como, é controlado pela pessoa que administra a máquina que corre o Squid. As pessoas que requisitam páginas numa rede que usa Squid de forma transparente podem não saber que esta informação está a ser registada. Em determinados países, os utilizadores devem ser informados sobre a possível monitorização e registo das ligações internet.
Sarg
O Sarg é um interpretador de logs para o Squid, assim como o Webalizer e o Apache. Sempre que executado ele cria um conjunto de páginas, divididas por dia, com uma lista de todas as máquinas que foram acessadas e a partir de cada máquina da rede veio cada acesso. Ele também mostra os usuários, caso o Squid esteja configurado para exigir autenticação.
A partir daí você pode acompanhar as páginas que estão sendo acessadas, mesmo que não exista nenhum filtro de conteúdo e tomar as medidas cabíveis em casos de abuso. Todos sabem que os filtros de conteúdo nunca são completamente eficazes, eles sempre bloqueiam algumas páginas úteis e deixam passar muitas páginas impróprias. Se você tiver algum tempo para ir acompanhando os logs, a inspeção manual é sempre o método mais eficiente.
Kerberos
Kerberos é um protocolo de autenticação de rede que oferece um método extremamente seguro para autenticar clientes e servidores (entidades de segurança) de uma rede. Essas entidades de segurança usam uma autenticação baseada em chaves mestras e permissões criptografadas.
No modelo de protocolo Kerberos, todas as conexões de cliente/servidor começam com a autenticação. Por sua vez, cliente e servidor seguem uma sequência de ações que se destinam a verificar em uma ponta da conexão se a outra ponta é verdadeira. Se a autenticação tiver êxito, a configuração da sessão será concluída e uma sessão cliente/servidor segura será estabelecida.
Entre os principais benefícios da autenticação Kerberos estão:
* Autenticação mútua. O cliente pode validar a identidade da entidade de servidor e o servidor pode validar o cliente. Com essa documentação, as duas entidades são denominadas "cliente" e "servidor" mesmo que seja possível estabelecer conexões seguras de rede entre servidores.
* Permissões de autenticação seguras. São utilizadas somente permissões criptografadas, e as senhas nunca são incluídas na permissão.
* Autenticação integrada. Uma vez que o usuário faça logon, ele não precisa efetuar logon novamente para acessar algum serviço que suporte a autenticação Kerberos, pois a permissão do cliente não expira. Todas as permissões têm um prazo de validade determinado pelas diretivas do Kerberos que geram a permissão.
O Kerberos oferece um mecanismo para autenticação mútua entre entidades antes do estabelecimento de uma conexão de rede segura. Kerberos usa terceiros confiáveis, o KDC (Key Distribution Center), para facilitar a geração e a distribuição segura de permissões de autenticação e chaves de sessões simétricas. O KDC é executado como um serviço em um servidor seguro e mantém um banco de dados para todas as entidades de segurança de seu território. No contexto de Kerberos, um território é o equivalente a um domínio do Windows.
Mas também temos as desvantagens que precisam ser mostradas:
* Migrar senhas de usuário de um banco de dados UNIX padrão, como o /etc/passwd ou o /etc/shadow, para um banco de dados de senhas Kerberos pode ser entediante, pois não há um mecanismo automatizado para executar esta tarefa.
* O Kerberos tem apenas compatibilidade parcial com os Módulos de Autenticação Plugáveis (PAM), sistema usado pela maioria dos servidores Red Hat Enterprise Linux.
* O Kerberos presume que cada usuário é confiável e está usando uma máquina não confiável em uma rede não confiável. Seu objetivo principal é evitar que senhas não criptografadas sejam enviadas pela rede. No entanto, se alguém além do usuário legítimo tiver acesso à máquina que emite tickets usados para autenticação - chamada de centro de distribuição de chave (KDC) - o sistema de autenticação inteiro do Kerberos estará em risco.
* Para que um aplicativo use o Kerberos, sua fonte deve ser alterada para fazer as chamadas apropriadas às bibliotecas do Kerberos. Os aplicativos modificados desta maneira são considerados kerberizados. Para alguns aplicativos, isto pode ser bastante problemático devido ao tamanho ou design do aplicativo. Para outros aplicativos incompatíveis, as alterações devem ser feitas na maneira como o lado servidor e clientes se comunicam. Vale frisar que isto pode requerer uma programação extensiva. Aplicativos de código fechado que não têm suporte ao Kerberos por padrão são geralmente os mais problemáticos.
* O Kerberos é uma solução 'tudo ou nada'. Se ele for utilizado na rede, quaisquer senhas não criptografadas transferidas a um serviço não-kerberizado estão em risco. Portanto, a rede não se beneficia do uso do Kerberos. Para proteger uma rede com o Kerberos, devem-se utilizar versões kerberizadas de todos os aplicativos cliente/servidor que enviam senhas não criptografadas ou não usar nenhum aplicativo do tipo cliente/servidor.
Como tudo funciona
O firewall foi criado com regras para compartilhar a internet, lembrando que temos 2 interfaces de rede, sendo 1 para (rede local) e outra para receber a internet a (Ethernet). Nele, acrescentei as regras para redirecionamento, liberação e bloqueio de portas, liberação da rede local e loopback, bloqueio para rede externa, Nat, mascaramento da rede, redirecionamento da porta 80 para o proxy e o bloqueio do restante. Ainda estou estruturando da o firewall da melhor maneira, mas por enquanto é o necessário.
O Squid funciona como o gerente do acesso a internet, liberando o que for preciso e bloqueando o restante. Nele criei regras para o bloqueio de sites, palavras, streamings, downloads e regras para liberar os mesmos quando for preciso. Sua autenticação é feita no Active Directory via NTLM. Ele autentica pela senha do usuário logado na estação de trabalho.
Como o NTLM funciona
As etapas a seguir apresentar um esboço de autenticação NTLM não interativo. O primeiro passo fornece as credenciais NTLM do utilizador e só ocorre como parte da autenticação interativa (logon) do processo.
Autenticação Interactive apenas - um usuário acessa um computador cliente e fornece um nome de domínio, nome de usuário e senha. hash O cliente calcula a criptografia hash da senha e descarta a senha real.
plaintext - o cliente envia o nome de usuário para o servidor (no texto original).
nonce - o servidor gera um byte aleatório número 16, chamado de desafio ou nonce, e envia para o cliente. O cliente criptografa o desafio com o hash da senha do usuário e retorna o resultado para o servidor. Isso é chamado de a resposta.
O servidor envia os seguintes três itens para o controlador de domínio:
* Nome de usuário
* Desafio enviado para o cliente
* Resposta recebida do cliente
O controlador de domínio usa o nome de usuário para recuperar o hash da senha do usuário do banco de dados Security Account Manager. Ele usa este hash de senha para criptografar o desafio.
O controlador de domínio compara o desafio é criptografado computadorizada (na etapa 6) a resposta calculada pelo cliente (na etapa 4). Se forem idênticos, a autenticação é bem sucedida.
O kerberos funciona como segurança para essa autenticação, pois invés de se usar as senhas e usuários como em outros métodos de autenticação ele usa "Tickets". Vamos entender melhor.
Vejamos como o Kerberos trabalha. Usuários e serviços que utilizem o Kerberos possuem chaves armazenadas no AS. As chaves dos usuários são derivadas de senhas escolhidas por estes, e as chaves dos serviços são geradas aleatoriamente.
Para esta explicação, imaginemos que as mensagens são escritas em papel, e são criptografadas colocando-as em uma caixa-forte, associada a uma chave.
Primeiro o usuário envia uma mensagem ao AS: "Eu, J. Random User gostaria de falar com o servidor Foo".
Quando o AS recebe a mensagem, ele faz duas cópias de uma nova chave registrada. Estas chaves são chamadas de chaves de sessão. Elas serão usadas nas trocas diretas entre serviço e usuário.
Ele coloca uma das chaves de sessão na Caixa 1, junto com um pedaço de papel com o nome "Servidor Foo" escrito. A caixa é trancada com a chave do usuário (o AS conhece todas as chaves de usuário e todas as chaves de serviço).
Por que este papel aqui? Devemos nos lembra que a caixa é na realidade apenas uma mensagem criptografada, e que a chave de sessão é uma sequência randômica de bytes. Se a Caixa 1 somente contivesse a chave de sessão, o usuário não teria como reconhecer se a resposta veio do AS, ou não saberia se a decriptação teve sucesso. Pela adição da mensagem "Servidor Foo", o usuário (mais precisamente a aplicação do usuário) poderia saber se a caixa veio do AS, e se a decriptação obteve sucesso.
Ele coloca a outra chave de sessão em uma Caixa 2, junto com um pedaço de papel com o nome "J. Random User". Esta caixa é fechada com a chave do serviço.
Ele envia ambas as caixas ao usuário. Na versão 4 do Kerberos, a Caixa 2 era colocada (sem necessidade) dentro da caixa 1, mas na versão 5 isto foi corrigido. O usuário destranca a Caixa 1 com sua chave, extraindo assim a chave de sessão e o papel com o nome "Servidor Foo" escrito nele.
O usuário não consegue abrir a Caixa 2 (ela foi trancada com a chave do serviço, que só o AS e o serviço conhecem). Então ele coloca um pedaço de papel com a hora corrente numa Caixa 3, e tranca esta com chave de sessão, e envia ambas ao serviço.
O serviço abre a Caixa 2 com sua própria chave, extraindo a chave de sessão e o papel com "J. Random User" escrito nele. Ele abre a Caixa 3 com a chave de sessão para extrair o pedaço de papel com a hora corrente nele. Estes itens demonstram a identidade do usuário.
O timestamp é colocado na Caixa 3 para prevenir que alguém faça uma cópia da Caixa 2 (devemos nos lembrar que as caixas são na verdade mensagens eletrônicas) e a utilize para se passar pelo usuário mais tarde. Como os relógios da rede nunca são perfeitamente sincronizados, uma pequena margem (em geral 5 minutos) é permitida entre o timestamp e a hora atual. Além disto, o serviço mantém uma lista das autenticações recebidas recentemente para garantir que elas não foram reenviadas.
A chave de serviço é gerada aleatoriamente e armazenada em um arquivo especial chamado de SECRETE KEY FILE. O Kerberos assume que este é seguro, que ninguém pode copiá-lo e se passar pelo serviço.
No Kerberos, a Caixa 2 é chamada de ticket, e a Caixa 3 de authenticator. O authenticator tipicamente contém mais informações do que as listadas acima. Algumas destas informações são adicionadas em decorrência do fato de que as mensagens são eletrônicas (por exemplo, existem checksum). Pode existir também uma chave secreta usada para criptografar as mensagens que serão trocadas entre usuário e serviço após a autenticação, garantindo assim a privacidade.
Instalando o Kerberos
Estou partindo do princípio que na rede a ser implementada essa solução já exista um Active Directory e um servidor DNS instalado. O servidor DNS é de fundamental importância para o trabalho do Kerberos assim como um servidor de NTP. Então instale esse 3 serviços na rede e configure-os da maneira correta. Antes da instalação do cliente kerberos atente para os seguinte itens:
Antes de instalar qualquer coisa, verificar se o sistema operacional usado está atualizado para não haver nenhum problema como por exemplo: instalar o pacote apt-build que contém compiladores entre outros softwares.
Primeiro, edite o arquivo /etc/hosts colocando o nome e o ip do seu Domain Controller:
# vi /etc/hosts
xxx.xxx.xxx.xxx nomedomicro@dominio.com.br nome do micro
127.0.0.1 localhost.localdomain localhost prx
127.0.0.1 localhost.localdomain localhost prx
Depois edite o seu resolv.conf e coloque o nome do servidor DNS:
# vi /etc/resolv.conf
nameserver xxx.xxx.xxx.xxx
search nomedodomínio.com.br
search nomedodomínio.com.br
Depois atualize o relógio do micro com o servidor Ntp da rede ou com um Ntp Server.
# ntpdate [nome do servidor ntp]
ou
# ntpdate ntp.cais.rnp.br (onde está nome do servidor é o servidor de Ntp da rede)
Para instalar o ntpdate use:
# apt-get install ntpdate
Depois vá até seu servidor DNS e crie um host para seu servidor Proxy com o ip do mesmo.
Agora vamos instalar o cliente Kerberos:
# apt-get install krb5-kdc krb5-config krb5-clients libpam-krb5 krb5-user
Obs.: Se for pedido o nome do domínio, disponibilize.
Depois é necessário alterar o aquivo /etc/krb5.conf:
# vi /etc/krb5.conf
[libdefaults]
default_realm = ELETROMOTORES.COM.BR
krb4_config = /etc/krb.conf
krb4_realms = /etc/krb.realms
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
v4_instance_resolve = false
v4_name_convert = {
host = {
rcmd = host
ftp = ftp
}
plain = {
something = something-else
}
fcc-mit-ticketflags = true
}
[realms]
ELETROMOTORES.COM.BR = {
kdc = xxx.xxx.xxx.xxx
admin_server = xxx.xxx.xxx.xxx
default_domain = xxx.xxx.xxx.xxx
}
[domain_realm]
.eletromotores.com.br = ELETROMOTORES.COM.BR
eletromotores.com.br = ELETROMOTORES.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
default_realm = ELETROMOTORES.COM.BR
krb4_config = /etc/krb.conf
krb4_realms = /etc/krb.realms
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
v4_instance_resolve = false
v4_name_convert = {
host = {
rcmd = host
ftp = ftp
}
plain = {
something = something-else
}
fcc-mit-ticketflags = true
}
[realms]
ELETROMOTORES.COM.BR = {
kdc = xxx.xxx.xxx.xxx
admin_server = xxx.xxx.xxx.xxx
default_domain = xxx.xxx.xxx.xxx
}
[domain_realm]
.eletromotores.com.br = ELETROMOTORES.COM.BR
eletromotores.com.br = ELETROMOTORES.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
Depois altere o arquivo /etc/krb5kdc/kdc.conf:
# vi /etc/krb5kdc/kdc.conf
[kdcdefaults]
kdc_ports = 88
[realms]
ELETROMOTORES.COM.BR = {
database_name = /var/lib/krb5kdc/principal
admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
acl_file = /etc/krb5kdc/kadm5.acl
key_stash_file = /etc/krb5kdc/stash
kdc_ports = 88
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = des3-hmac-sha1
supported_enctypes = aes256-cts:normal arcfour-hmac:normal des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des
nlyrealm des:afs3
default_principal_flags = +preauth
}
kdc_ports = 88
[realms]
ELETROMOTORES.COM.BR = {
database_name = /var/lib/krb5kdc/principal
admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
acl_file = /etc/krb5kdc/kadm5.acl
key_stash_file = /etc/krb5kdc/stash
kdc_ports = 88
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = des3-hmac-sha1
supported_enctypes = aes256-cts:normal arcfour-hmac:normal des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des
nlyrealm des:afs3default_principal_flags = +preauth
}
Depois altere o arquivo /etc/default/krb5-kdc:
# vi /etc/default/krb5-kdc
KRB4_MODE=disable
RUN_KRB524D=false
RUN_KRB524D=false
Em seguida, vamos iniciar a comunicação entre o Linux e o Domain Controller utilizando Kerberos.
# kinit administrator@ELETROMOTORES.COM.BR
Lembrando que estamos usando o domínio ELETROMOTORES.COM.BR como teste, então troque pelo domínio da sua rede.
Será solicitada a senha do usuário "administrator". Depois deste passo use o comando klist e veja se retorna isto:
# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: administrator@LAB.VIRTUAL
Valid starting Expires Service principal
02/22/07 14:25:47 02/23/07 00:25:47 krbtgt/LAB.VIRTUAL@LAB.VIRTUAL
Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached
Caso não seja este o retorno do comando, reveja os passos acima. Gostaria de salientar que encontrei diversos sites com abordagens da instalação do Kerberos no Linux e seus arquivos .conf, mas a única maneira que consegui realizar os testes foi com os arquivos .conf desta maneira descrita no projeto. Portanto se copiarem como está no projeto e só trocar o que for pedido correrá tudo certo. Para testes execute o comando kinit com outros usuários do domínio.
Em seguida vamos editar o arquivo nsswitch.conf:
# vi /etc/nsswitch.conf
Alterar as linhas:
De:
passwd: compat
group: compat
Para:
passwd: compat winbind
group: compat winbind
group: compat winbind
Descrição dos componentes usados:
Samba
O Samba é um "software servidor" para Linux (e outros sistemas baseados em Unix) que permite o gerenciamento e compartilhamento de recursos em redes formadas por computadores com o Windows. Assim, é possível usar o Linux como servidor de arquivos, servidor de impressão, entre outros, como se a rede utilizasse servidores Windows (NT, 2000, XP, Server 2003). Este artigo faz uma abordagem introdutória ao Samba, mostrando suas principais características e um pouco de sua história.
Winbind
O Windbind faz a integração entre o Linux e o Domínio NT e toda a comunicação com o Domínio NT é realizada através do Samba, neste caso apenas o Samba-client é utilizado, ou seja, sem carregar o serviço smb. O winbind é responsável por fazer a autenticação usando o NTLM.
Na verdade dentro do pacote samba contém o winbind se fizéssemos o download do samba via wget precisaríamos apenas compilar para usarmos o winbind, mas eu preferi instalar os dois, ai fica a gosto do freguês. A instalação do SAMBA e do WINBIND é simples e pode ser feita via apt-get. Então, vamos por a mão na massa:
# apt-get install samba winbind
Após rodarmos o comando acima, será aberta uma tela de configuração, onde é solicitado o nome do domínio, o uso de senhas encriptadas, que OBRIGATORIAMENTE tem que ser SIM e também é necessário que o samba crie o arquivo de senhas.
Agora é necessário configurar o samba. Para isso, vamos fazer backup do arquivo original e depois vamos criar o nosso arquivo de configuração.
# mv /etc/samba/smb.conf /etc/samba/smb.original
# vi /etc/samba/smb.conf
O arquivo smb.conf deve conter OBRIGATORIAMENTE as linhas abaixo. Outras configurações podem ser feitas de acordo com a necessidade.
[global]
workgroup = ELETROMOTORES
netbios name = SRV-PROXY
server string = PROXY SERVER
load printers = no
log file = /var/log/samba/log.%m
max log size = 500
realm = ELETROMOTORES.COM.BR
security = ads
auth methods = winbind
password server = 192.168.52.3
winbind separator = +
encrypt passwords = yes
winbind cache time = 15
winbind enum users = yes
winbind enum groups = yes
winbind use default domain = yes
idmap uid = 10000-20000
idmap gid = 10000-20000
local master = no
os level = 233
domain master = no
preferred master = no
domain logons = no
wins server = 192.168.52.3
dns proxy = no
ldap ssl = no
workgroup = ELETROMOTORES
netbios name = SRV-PROXY
server string = PROXY SERVER
load printers = no
log file = /var/log/samba/log.%m
max log size = 500
realm = ELETROMOTORES.COM.BR
security = ads
auth methods = winbind
password server = 192.168.52.3
winbind separator = +
encrypt passwords = yes
winbind cache time = 15
winbind enum users = yes
winbind enum groups = yes
winbind use default domain = yes
idmap uid = 10000-20000
idmap gid = 10000-20000
local master = no
os level = 233
domain master = no
preferred master = no
domain logons = no
wins server = 192.168.52.3
dns proxy = no
ldap ssl = no
Criado o arquivo de configuração, vamos reiniciar os serviços do Samba e do Winbind.
# /etc/init.d/samba stop
# /etc/init.d/winbind stop
# /etc/init.d/samba start
# /etc/init.d/winbind start
Não se esqueça de verificar os logs para saber se tudo iniciou corretamente.
Agora vamos colocar a máquina Linux no domínio Windows.
# net ads join -U administrator -S ELETROMOTORES
Após digitar a senha, que será solicitada, o retorno deve ser semelhante ao retornado abaixo:
Using short domain name -- ELETROMOTORES
Joined 'PROXY' to realm 'ELETROMOTORES.COM.BR'
Joined 'PROXY' to realm 'ELETROMOTORES.COM.BR'
Você também pode usar o seguinte comando:
# net rpc join ELETROMOTORES -S servidor -Uadministrador
Troque onde está ELETROMOTORES pelo seu domínio onde está SERVIDOR pelo nome do Domain Controller e ADMINISTRADOR por um usuário que tenha permissão de administrador ou pelo próprio mesmo.
Verificando se o Winbind está comunicando com o RPC Server:
# wbinfo -t
Retorno esperado: checking the trust secret via RPC calls succeeded
Listando usuários do AD:
# wbinfo -u
Listando os grupos do AD:
# wbinfo -g
Se não for esse o retorno, revise os passos acima.
Instalando o Squid
O Squid deve ser instalado pelo source, pois usaremos algumas opções específicas que não são utilizadas ao usar o apt-get. Recomendo a utilização da versão 2.5, pois quando utilizei a 2.6-STABLE não funcionou de acordo, mas não testei as versões mais novas.
Vamos ao que interessa!
Entrando no diretório de sources:
# cd /usr/src
Efetuando o download do pacote estável:
# wget Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
Descompactando:
# tar zxvf squid-2.5.STABLE14.tar.gz
Acessando o diretório do Squid/Source:
# cd squid-2.5.STABLE14
Compilando com as opções necessárias:
# ./configure --prefix=/usr --exec_prefix=/usr --bindir=/usr/sbin --sbindir=/usr/sbin --libexecdir=/usr/lib/squid --sysconfdir=/etc/squid --localstatedir=/var/spool/squid --datadir=/usr/share/squid --enable-auth="ntlm,basic" --enable-basic-auth-helpers="winbind" --enable-ntlm-auth-helpers="winbind" --enable-external-aclhelpers="winbind_group,wbinfo_group" --enable-delay-pools --enable-removal-policies --enable-underscores --enable-cache-digests --disable-ident-lookups --enable-truncate --enablearp-acl --with-winbind-auth-challenge
Instalando:
# make && make install
Criando o grupo para utilizar o Squid:
# groupadd proxy
Criando o usuário e colocando-o no grupo do Squid:
# useradd proxy -g Proxy
Dando permissão para o diretório do Squid:
# chown -R proxy.proxy /usr/share/squid
# chown -R proxy.proxy /var/spool/squid
Efetuando backup do arquivo de configuração original:
# cd /etc/squid/etc
# mv squid.conf squid.original
Limpando todas as linhas comentadas do squid.original e gerando o squid.conf:
# egrep -v "^#|^$" squid.original > squid.conf
Gerando o diretório de logs e liberando as permissões:
# mkdir /var/log/squid
# chown -R proxy.proxy /var/log/squid
Liberando a permissão no arquivo do Winbind:
# chown root.proxy /var/run/samba/winbindd_privileged
Reiniciando o Winbind:
# /etc/init.d/winbind stop & /etc/init.d/winbind start
Editando o arquivo squid.conf e colocando as linhas abaixo:
# vi /etc/squid/squid.conf
http_port 3128
cache_effective_user proxy
cache_effective_group proxy
cache_log /var/log/squid/cache.log
cache_access_log /var/log/squid/access.log
cache_store_log /var/log/squid/store.log
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY
auth_param ntlm program /usr/bin/ntlm_auth LAB/DC01 --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm use_ntlm_negotiate off
auth_param ntlm children 10
auth_param ntlm max_challenge_reuses 0
auth_param ntlm max_challenge_lifetime 5 minutes
auth_param basic program /usr/bin/ntlm_auth LAB/DC01 --helper-protocol=squid-2.5-basic
auth_param basic children 5
auth_param basic realm Digite o LOGIN/SENHA
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern . 0 20% 4320
acl all src 192.168.88.0/255.255.255.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443 563
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 563 # https, snews
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
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 CONNECT method CONNECT
acl acesso proxy_auth REQUIRED # Solicitando a autenticação
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow acesso # Liberando usuários autenticados
http_access allow all
http_reply_access allow all
icp_access allow all
coredump_dir /usr/local/squid/var/cache
cache_effective_user proxy
cache_effective_group proxy
cache_log /var/log/squid/cache.log
cache_access_log /var/log/squid/access.log
cache_store_log /var/log/squid/store.log
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY
auth_param ntlm program /usr/bin/ntlm_auth LAB/DC01 --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm use_ntlm_negotiate off
auth_param ntlm children 10
auth_param ntlm max_challenge_reuses 0
auth_param ntlm max_challenge_lifetime 5 minutes
auth_param basic program /usr/bin/ntlm_auth LAB/DC01 --helper-protocol=squid-2.5-basic
auth_param basic children 5
auth_param basic realm Digite o LOGIN/SENHA
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern . 0 20% 4320
acl all src 192.168.88.0/255.255.255.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443 563
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 563 # https, snews
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
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 CONNECT method CONNECT
acl acesso proxy_auth REQUIRED # Solicitando a autenticação
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow acesso # Liberando usuários autenticados
http_access allow all
http_reply_access allow all
icp_access allow all
coredump_dir /usr/local/squid/var/cache
Criando o cache e iniciando o Squid:
# squid -z
# squid &
Caso dê algum erro no procedimento, revisá-lo, mas geralmente dá-se erro na criação do cache se isso ocorrer de permissão e crie a pasta cache no /var/squid.
# mkdir cache /var/squid
# chown -R proxy.proxy /var/squid/cache
Para utilizar as regras baseadas em grupos do Active Directory, utilize as seguintes linhas no seu squid.conf:
external_acl_type nt_group %LOGIN /usr/lib/squid/wbinfo_group.pl
acl AllowedWindowsGroups external nt_group GrupodoAD
http_access allow AllowedWindowsGroups
acl AllowedWindowsGroups external nt_group GrupodoAD
http_access allow AllowedWindowsGroups
# squid -k reconfigure
Execute o Squid:
# squid
Configure o proxy no IE:
* Proxy: IP do seu servidor de proxy
* Porta 3128
Testes
Monitorando o arquivo de log de acessos do Squid com o comando "tail -f" vemos que o acesso foi liberado utilizando o usuário GK, que é o usuário logado na estação de trabalho.
# tail -f /var/log/squid/access.log
Instalação do Sarg
Instalando e configurando o Sarg:
# apt-get install update
# apt-get install sarg
Após o processo de instalação, o principal arquivo de configuração denominado 'sarg.conf' poderá ser localizado no diretório /etc/squid. Apenas para efeitos de backup, pois é sempre bom se ter o arquivo original em reserva para eventuais problemas que possam surgir.
Crie o seu próprio 'sarg.conf':
# touch sarg.conf
Edite o arquivo utilizando o seu editor de preferência (no meu caso o mcedit) e adicione o conteúdo abaixo ao mesmo:
# Script para configuração do Sarg [sarg.conf]
# Desenvolvido por Júnior Jones de Menezes
# TAG: Linguagem
language Portuguese
# TAG: Caminho para o arquivo Access.log
access_log /etc/squid/access.log
# TAG: Gráficos
graphs yes
graph_days_bytes_bar_color green
# TAG: Título do Relatório
title "[Acessos a Internet]"
# TAG: Visual
font_face Arial
header_color #666666
header_bgcolor #EEEEEE
header_font_size 9px
title_font_size 11px
background_color #FFFFFF
text_color #666666
text_bgcolor #FFFFFF
title_color #009999
# TAG: Temporários
temporary_dir /tmp
# TAG: Diretório de Saída (Modifique de acordo com sua necessidade)
output_dir /var/www/squid-reports
# TAG: Top Users
topuser_sort_field BYTES reverse
user_sort_field BYTES reverse
# TAG: URL Excluídas do Relatório
exclude_hosts /etc/squid/sarg.hosts
# TAG: Filtragem de Strings
exclude_string /etc/squid/sarg.strings
# TAG: Filtragem de Usuários
exclude_users /etc/squid/sarg.users
# TAG: Formato de Data
date_format e
# TAG: Limite de Logs [0 = Sem limites]
lastlog 0
# TAG: Mostrar IP
user_ip no
# TAG: Mostrar Usuário
usertab /etc/squid/sarg.usertab
# TAG: Gerando Relatório
remove_temp_files yes
index yes
overwrite_report yes
records_without_userid ignore
use_comma no
topsites_num 100
topsites_sort_order BYTES D
exclude_codes /etc/squid/sarg.exclude_codes
max_elapsed 28800000
report_typie topsites users_sites sites_users date_time denied auth_failures site_user_time_date
long_url no
show_successful_message no
topuser_fields NUM DATE_TIME USERID CONNECT BYTES %BYTES IN-CACHE-OUT USED_TIME MILISEC %TIME TOTAL AVERAGE
topuser_num 0 download_suffix "zip,arj,bzip,gz,ace,doc,iso,adt,bin,cab,com,dot,d rv$,lha,lzh,mdb,mso,ppt,rtf,src,shs,sys,exe,dll,mp 3,avi,mpg,mpeg"
# Desenvolvido por Júnior Jones de Menezes
# TAG: Linguagem
language Portuguese
# TAG: Caminho para o arquivo Access.log
access_log /etc/squid/access.log
# TAG: Gráficos
graphs yes
graph_days_bytes_bar_color green
# TAG: Título do Relatório
title "[Acessos a Internet]"
# TAG: Visual
font_face Arial
header_color #666666
header_bgcolor #EEEEEE
header_font_size 9px
title_font_size 11px
background_color #FFFFFF
text_color #666666
text_bgcolor #FFFFFF
title_color #009999
# TAG: Temporários
temporary_dir /tmp
# TAG: Diretório de Saída (Modifique de acordo com sua necessidade)
output_dir /var/www/squid-reports
# TAG: Top Users
topuser_sort_field BYTES reverse
user_sort_field BYTES reverse
# TAG: URL Excluídas do Relatório
exclude_hosts /etc/squid/sarg.hosts
# TAG: Filtragem de Strings
exclude_string /etc/squid/sarg.strings
# TAG: Filtragem de Usuários
exclude_users /etc/squid/sarg.users
# TAG: Formato de Data
date_format e
# TAG: Limite de Logs [0 = Sem limites]
lastlog 0
# TAG: Mostrar IP
user_ip no
# TAG: Mostrar Usuário
usertab /etc/squid/sarg.usertab
# TAG: Gerando Relatório
remove_temp_files yes
index yes
overwrite_report yes
records_without_userid ignore
use_comma no
topsites_num 100
topsites_sort_order BYTES D
exclude_codes /etc/squid/sarg.exclude_codes
max_elapsed 28800000
report_typie topsites users_sites sites_users date_time denied auth_failures site_user_time_date
long_url no
show_successful_message no
topuser_fields NUM DATE_TIME USERID CONNECT BYTES %BYTES IN-CACHE-OUT USED_TIME MILISEC %TIME TOTAL AVERAGE
topuser_num 0 download_suffix "zip,arj,bzip,gz,ace,doc,iso,adt,bin,cab,com,dot,d rv$,lha,lzh,mdb,mso,ppt,rtf,src,shs,sys,exe,dll,mp 3,avi,mpg,mpeg"
As TAGs apresentadas abaixo são exatamente as que indicarão ao Sarg que nos relatórios gerados por ele deverá aparecer ao invés do endereço IP, o nome do usuário ou máquina devidamente setado por você.
# TAG: Mostrar IP
user_ip no
# TAG: Mostrar Usuário
usertab /etc/squid/sarg.usertab
user_ip no
# TAG: Mostrar Usuário
usertab /etc/squid/sarg.usertab
Exemplo:
192.168.52.2 gabriel
192.168.52.3 daniel
192.168.52.4 rafael
192.168.52.3 daniel
192.168.52.4 rafael
Como visto acima, é o 'sarg.usertab' que possibilita ao Sarg mostrar nomes amigáveis ao invés de endereços IPs, fator muito útil em redes de grande porte e não menos importante em pequenas redes.
Gerando os relatórios
Criaremos agora o script que irá orientar ao Sarg sobre o total de dias que se deseja apresentar nos relatórios. Crie um arquivo dentro do diretório /etc/squid denominado 'sarg.sh':
# touch diario.sh
Dê permissão total:
# chmod 777 sarg.sh
Para gerar os relatórios diariamente, insira o conteúdo abaixo no arquivo recém-criado (/etc/squid/sarg.sh):
#!/bin/bash
INICIO=$(date --date "0 days ago" +%d/%m/%Y)
FIM=$(date --date "0 day ago " +%d/%m/%Y)
sarg -f /etc/squid/sarg.conf -d $INICIO-$FIM -p -x -z
INICIO=$(date --date "0 days ago" +%d/%m/%Y)
FIM=$(date --date "0 day ago " +%d/%m/%Y)
sarg -f /etc/squid/sarg.conf -d $INICIO-$FIM -p -x -z
# touch semanal.sh
#!/bin/bash
INICIO=$(date --date "7 days ago" +%d/%m/%Y)
FIM=$(date --date "0 day ago " +%d/%m/%Y)
sarg -f /etc/squid/sarg.conf -d $INICIO-$FIM -p -x -z
INICIO=$(date --date "7 days ago" +%d/%m/%Y)
FIM=$(date --date "0 day ago " +%d/%m/%Y)
sarg -f /etc/squid/sarg.conf -d $INICIO-$FIM -p -x -z
# touch mensal.sh
#!/bin/bash
INICIO=$(date --date "31 days ago" +%d/%m/%Y)
FIM=$(date --date "0 day ago " +%d/%m/%Y)
sarg -f /etc/squid/sarg.conf -d $INICIO-$FIM -p -x -z
INICIO=$(date --date "31 days ago" +%d/%m/%Y)
FIM=$(date --date "0 day ago " +%d/%m/%Y)
sarg -f /etc/squid/sarg.conf -d $INICIO-$FIM -p -x -z
Instalação do Iptraf
Esse não tem segredo, mas muito bom para administradores de rede conforme orientação do próprio projeto. Então vamos lá, para instalá-lo:
# apt-get install iptraf
Para usá-lo:
# iptraf
Conclusão
Existem diversos sites com explicações e maneiras de se instalar o Squid com autenticação, mas preferi essa por ser considerada mais segura e de maior facilidade. Espero ter ajudado a muitos que igual a mim montar um servidor como o descrito. Gostaria de agradecer a todos os autores e sites descrevo na bibliografia. Muito obrigado.
Bibliografia
Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...
Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...