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
Citação:
| xxx.xxx.xxx.xxx nomedomicro@dominio.com.br nome do micro 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
Citação:
| nameserver xxx.xxx.xxx.xxx 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
Citação:
| [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 |
Depois altere o arquivo /etc/krb5kdc/kdc.conf:
# vi /etc/krb5kdc/kdc.conf
Citação:
| [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:afs3default_principal_flags = +preauth } |
Depois altere o arquivo /etc/default/krb5-kdc:
# vi /etc/default/krb5-kdc
Citação:
| KRB4_MODE=disable 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:
Citação:
| passwd: 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.
Citação:
| [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 |
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:
Citação:
| Using short domain name -- ELETROMOTORES 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 http://www.squid-cache.org/Versions/...TABLE14.tar.gz
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
Citação:
| 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 |
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:
Citação:
| external_acl_type nt_group %LOGIN /usr/lib/squid/wbinfo_group.pl 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:
Citação:
| # 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" |
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ê.
Citação:
| # TAG: Mostrar IP user_ip no # TAG: Mostrar Usuário usertab /etc/squid/sarg.usertab |
Exemplo:
Citação:
| 192.168.52.2 gabriel 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):
Citação:
| #!/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 |
# touch semanal.sh
Citação:
| #!/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 |
# touch mensal.sh
Citação:
| #!/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 |
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.
0 comentários:
Postar um comentário