Este artigo tem como principal objetivo orientar a implantação de um servidor para oferecer os serviços de proxy transparente, armazenamento/compartilhamento de arquivos e controle de acesso, além de servir a novos usuários do GNU/Linux como referência preliminar para estudo. O S.O. escolhido para implantação será a última versão estável do Debian 8, em virtude desta escolha os seguintes pacotes farão parte desta instalação:

• Squid 3
• ISC DHCP Server
• CUPS
• Samba
• BIND 9
• Sarg
• NFS
• NTP
• Apache 2

Para a implantação do servidor utilizaremos como checklist as seguintes etapas:

1. Configuração das interfaces de rede.
2. Atualização do S.O. e instalação dos pacotes.
3. Configuração do servidor DHCP.
4. Definição de firewall e redirecionamento.
5. Configuração do Squid e possibilidade de compilação para escuta da porta 443 (HTTPS).
6. Ajustes no Sarg para gerar relatórios de acesso.

CONFIGURAÇÃO DAS INTERFACES DE REDE

As configurações das interfaces de rede em sistemas baseados em Debian são possíveis através do arquivo interfaces localizado na pasta/etc/network. Antes da edição deste arquivo serão necessárias as seguintes informações:

• Qual a interface recebe o sinal da internet e qual a interface que será responsável por receber as requisições da rede local. Preferencialmente opte pela interface eth0 para receber o link com a internet e demais interfaces para prover a rede local.
• Endereço IP do modem.
• Definição da classe de IP para a rede local.

Todos os procedimentos devem ser realizados com a conta do superusuário e através da edição de arquivos de configuração via terminal. Neste roteiro as informações recolhidas foram as seguinte:

• Interface eth0 – link com a internet
• Interface eth1 – link com a rede local
• Endereço IP do modem – 192.168.0.1
• Classe de IP da rede interna – 172.16.0.0

Inicialmente é necessário a edição do arquivo interfaces. Abaixo temos um exemplo das configurações mediante as informações recolhidas, ambas as interfaces foram setadas com endereço IP estático. Pare o serviço de rede e efetue a configuração necessária:

# systemctl stop networking
# nano /etc/network/interfaces

Encerre a edição do arquivo e inicie os serviços de rede:

# systemctl start networking

Verifique com o comando ifconfig as configurações das interfaces:

# ifconfig

eth0  Link encap:Ethernet  Endereço de HW 08:00:27:0c:c3:73
          inet end.: 192.168.0.2  Bcast:192.168.0.255  Masc:255.255.255.0
          endereço inet6: fe80::a00:27ff:fe0c:c373/64 Escopo:Link
          UP BROADCASTRUNNING MULTICAST  MTU:1500  Métrica:1
          RX packets:606 errors:0 dropped:0 overruns:0 frame:0
          TX packets:380 errors:0 dropped:0 overruns:0 carrier:0
          colisões:0 txqueuelen:1000
          RX bytes:582316 (568.6 KiB)  TX bytes:33198 (32.4 KiB)

eth1  Link encap:Ethernet  Endereço de HW 08:00:27:77:c1:45
          inet end.: 172.16.0.1  Bcast:172.16.255.255  Masc:255.255.0.0
          endereço inet6: fe80::a00:27ff:fe77:c145/64 Escopo:Link
          UP BROADCASTRUNNING MULTICAST  MTU:1500  Métrica:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          colisões:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:648 (648.0 B)

lo       Link encap:Loopback Local
          inet end.: 127.0.0.1  Masc:255.0.0.0
          endereço inet6: ::1/128 Escopo:Máquina
          UP LOOPBACKRUNNING  MTU:65536  Métrica:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          colisões:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Verifique através do comando ping se há conectividade:

# ping -c 3 www.vivaolinux.com.br
PING www.vivaolinux.com.br (162.144.34.3) 56(84) bytes of data.
64 bytes from 162-144-34-3.unifiedlayer.com (162.144.34.3): icmp_seq=1 ttl=52 time=185 ms
64 bytes from 162-144-34-3.unifiedlayer.com (162.144.34.3): icmp_seq=2 ttl=52 time=186 ms
64 bytes from 162-144-34-3.unifiedlayer.com (162.144.34.3): icmp_seq=3 ttl=52 time=187 ms

— www.vivaolinux.com.br ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 185.369/186.339/187.087/0.800 ms

Atualize o conteúdo do arquivo /etc/hosts de forma que a interface loopback (127.0.0.1) aponte para o hostname:

# cat /etc/hosts

Atualize o Debian e instale os pacotes necessários:

# apt-get update && apt-get upgrade -y

Instale os pacotes:

# apt-get install -y squid3 samba sarg cups isc-dhcp-server ntp bind9 apache2 debmirror

CONFIGURAÇÕES DO SERVIDOR DHCP

O servidor DHCP será o responsável por distribuir IPs na rede local, para editar as configurações iniciais localize o arquivo dhcpd.conf na pasta /etc/dhcp e tenha em mãos as informações relativas ao servidor DNS primário e secundário, para este exemplo foi usado o servidor do opendns.com:

# nano /etc/dhcp/dhcpd.conf

Status do funcionamento do ISC DHCP Server:

# systemctl status isc-dhcp-server
● isc-dhcp-server.service – LSB: DHCP server
Loaded: loaded (/etc/init.d/isc-dhcp-server)
Active: active (running) since Qua 2015-07-08 23:28:36 BRT; 2s ago
Process: 9399 ExecStart=/etc/init.d/isc-dhcp-server start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/isc-dhcp-server.service
└─9407 /usr/sbin/dhcpd -q -cf /etc/dhcp/dhcpd.conf -pf /var/run/dhcpd.pid

Jul 08 23:28:33 onix dhcpd[9406]: Wrote 0 leases to leases file.
Jul 08 23:28:34 onix dhcpd[9407]: Server starting service.
Jul 08 23:28:36 onix isc-dhcp-server[9399]: Starting ISC DHCP server: dhcpd.

Em caráter opcional é possível realizar a atualização do arquivo /etc/resolv.conf de forma que é possível apontar quais servidores DNS serão consultados primeiramente. A cada nova conexão o arquivo resolv.conf é atualizado, a forma mais apropriada para a atualização deste arquivo e através do dhclient.conf na pasta /etc/dhcp. Localize no arquivo as linhas:

#supersede domain-name “fugue.com home.vix.com”;
#prepend domain-name-servers 127.0.0.1;

Modifique-as retirando o # e adicione as informações necessárias, neste exemplo será usado OpenDNS.

Encerre a edição do arquivo e reinicie o serviço.

DEFINIÇÃO DE FIREWALL E REDIRECIONAMENTO

A definição do firewall será realizado pelo iptables através de um script. O conteúdo deste script deve ser definido de acordo com as necessidades e normas de segurança da rede. Neste exemplo será utilizado um firewall básico para redirecionar todas as requisições para a porta 3128:

# touch /etc/init.d/rc.firewall

#!/bin/bash
### BEGIN INIT INFO
# Provides: Script Firewall
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop:
# Short-Decription: Script Firewall based on Iptables
### END INIT INFO

# Clean modules
iptables -F
iptables -t nat -F
iptables -t mangle -F

# Proxy
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 3128

# Masquerading IP
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# Forward
echo 1 > /proc/sys/net/ipv4/ip_forward

Atribua o valor de executável para o arquivo e adicione o script à inicialização do sistema:

# chmod +x rc.firewall
# update-rc.d rc.firewall defaults

Verifique as tabelas do iptables:

# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
REDIRECT   tcp  —  anywhere             anywhere             tcp dpt:http redir ports 3128

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  —  anywhere             anywhere

O Squid é o principal responsável pelo serviço de webproxy com a possibilidade de proxy autenticado ou transparente, entre outras funcionalidades temos a possibilidade de cache, controle de banda, definição de acesso por horário e controle de acesso. Neste roteiro será abordado a criação de um proxy transparente, além da possibilidade da compilação para permitir que o Squid realize a escuta do protocolo HTTPS (porta 443) e a criação e cache de certificados dinâmicos.

Para a implantação do proxy transparente há um exemplo de configurações mínimas, o arquivo alvo da edição está localizado na pasta/etc/squid3 com o nome squid.conf:

# nano /etc/squid3/squid.conf

Reinicie o serviço do Squid:

# systemctl restart squid3

Verifique o status do serviços.

# systemctl status -l squid3
● squid3.service – LSB: Squid HTTP Proxy version 3.x
Loaded: loaded (/etc/init.d/squid3)
Active: active (running) since Seg 2015-07-13 23:44:12 BRT; 4s ago
Process: 1531 ExecStop=/etc/init.d/squid3 stop (code=exited, status=0/SUCCESS)
Process: 1554 ExecStart=/etc/init.d/squid3 start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/squid3.service
├─1590 /usr/sbin/squid3 -YC -f /etc/squid3/squid.conf
├─1592 (squid-1) -YC -f /etc/squid3/squid.conf
├─1593 (unlinkd)
└─1594 (pinger)

Jul 13 23:44:12 onix squid3[1554]: 2015/07/13 23:44:12 kid1| Making directories in /var/spool/squid3/06
Jul 13 23:44:12 onix squid3[1554]: 2015/07/13 23:44:12 kid1| Making directories in /var/spool/squid3/07
Jul 13 23:44:12 onix squid3[1554]: 2015/07/13 23:44:12 kid1| Making directories in /var/spool/squid3/08
Jul 13 23:44:12 onix squid3[1554]: 2015/07/13 23:44:12 kid1| Making directories in /var/spool/squid3/09
Jul 13 23:44:12 onix squid3[1554]: 2015/07/13 23:44:12 kid1| Making directories in /var/spool/squid3/0A
Jul 13 23:44:12 onix squid3[1554]: 2015/07/13 23:44:12 kid1| Making directories in /var/spool/squid3/0B
Jul 13 23:44:12 onix squid3[1554]: 2015/07/13 23:44:12 kid1| Making directories in /var/spool/squid3/0C
Jul 13 23:44:12 onix squid3[1554]: 2015/07/13 23:44:12 kid1| Making directories in /var/spool/squid3/0D
Jul 13 23:44:12 onix squid3[1554]: 2015/07/13 23:44:12 kid1| Making directories in /var/spool/squid3/0E
Jul 13 23:44:12 onix squid3[1554]: 2015/07/13 23:44:12 kid1| Making directories in /var/spool/squid3/0F

Com este arquivo base nenhum acesso será negado e a partir dele podemos definir as diretivas através das ACLs.

ACCESS CONTROL LIST

Com a configuração do Squid funcional é possível definir acessos e seus controles através das ACLs (Access Control List). Antes de tratar das ACLs é necessário o entendimento de algumas regras:

1. Por definição quando a requisição é realizada o Squid analisa o conteúdo do squid.conf do topo para o fim, procurando uma diretiva que se encaixe com o padrão da requisição até o final do arquivo.

2. É interessante definir como última diretiva uma regra para bloquear todas as requisições de acesso no caso do pacote não combinar com nenhuma diretiva anterior. Uma analogia que pode ser realiza é a de que o Squid possui políticas de acesso similares a um firewall.

3. Evite regras desnecessárias ou redundantes.

A sintaxe básica para definição da ACL é:

acl [nome_da_ACL] [Classe da ACL]

Para cada ACL criada é necessário definir se acesso será permitido, allow, ou negado, deny.

Classes de acesso:

• SRC – classe baseada na origem da requisição, ou seja, baseia-se no endereço IP do cliente.
• DST – classe baseada no destino da requisição, ou seja, baseia-se no endereço IP do servidor requisitado.
• SRCDOMAIN – classe de acesso que baseia-se no domínio DNS do cliente.
• DSTDOMAIN – classe de acesso que baseia-se no domínio DNS do servidor de destino da requisição.
• TIME – classe de acesso que define o acesso por dia da semana e horário da requisição.
• URL_REGEX – classe onde é possível utilizar expressões regulares para liberação ou bloqueio das requisições.
• PROXY_AUTH – classe que utiliza o login do usuário para definir a liberação ou bloqueio da requisição.

Uma das grandes desvantagens com o proxy transparente é a escuta do protocolo HTTPS, em proxys autenticados o bloqueio/acesso à páginas acontece de acordo com as diretivas ligadas ao login do usuário, bloqueando ou permitindo acesso em sua requisição. A partir deste ponto será apresentada uma solução para a escuta do protocolo 443 redirecionado à porta 3127 do Squid.

Para compilação serão utilizados os binários da instalação corrente do Squid 3. A partir daqui utilizaremos a versão 3.5:

# wget http://www.squid-cache.org/Versions/v3/3.5/squid-3.5.6.tar.gz

Descompacte o arquivo:

# tar xvfz squid-3.5.6.tar.gz

Acesse a pasta recém criada /usr/src/squid-3.5.6, resolva das dependências e instale os pacotes adicionais:

# apt-get build-dep squid3 && apt-get install libssl-dev build-essential

Execute o ./configure com as seguintes opções:

# ./configure –prefix=/usr –includedir=${prefix}/include –mandir=${prefix}/share/man –infodir=${prefix}/share/info –sysconfdir=/etc –localstatedir=/var –libexecdir=${prefix}/lib/squid3 –srcdir=. –datadir=/usr/share/squid3 –sysconfdir=/etc/squid3 –mandir=/usr/share/man –enable-icap-client –enable-ssl –enable-ssl-crtd –enable-follow-x-forwarded-for –enable-linux-netfilter –with-openssl –with-swapdir=/var/spool/squid3 –with-logdir=/var/log/squid3 –with-pidfile=/var/run/squid3.pid –with-filedescriptors=65536 –with-large-files –with-default-user=proxy

Aguarde o final do processo, interrompa a execução do Squid e execute:

# systemctl stop squid3
# make all && make install

Atualize as configurações no arquivo squid.conf adicionando as seguintes linhas:

Realize as cópias dos binários:

# mv /usr/sbin/squid3 /usr/sbin/squid3_old && mv /usr/sbin/squid /usr/sbin/squid3

Utilize o OpenSSL para gerar os certificados que devem ser importados para os clientes. A criação do certificado deve apontar para o caminho descrito no squid.conf:

# mkdir ssl_cert
# cd ssl_cert/
# openssl req -new -newkey rsa:1024 -days 365 -nodes -x509 -keyout onix.pem -out onix.pem

Crie o arquivo que será importado para os clientes:

# openssl x509 -in onix.pem -outform DER -out onix.der

Atualize as diretivas do firewall:

#!/bin/bash
### BEGIN INIT INFO
# Provides: Script Firewall
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop:
# Short-Decription: Script Firewall based on Iptables
### END INIT INFO

# Clean modules
iptables -Fd /etc
iptables -t nat -F
iptables -t mangle -F

# Proxy
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 3128
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 443 -j REDIRECT --to-port 3127

# Masquerading IP
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# Forward
echo 1 > /proc/sys/net/ipv4/ip_forward

Utilize o ssl_crtd para criar o diretório onde serão arquivados o cache de certificados dinâmicos:

# /lib/squid3/ssl_crtd -c -s /var/lib/ssl_db -M 4MB

Mude o grupo e o usuário do diretório para que o Squid possa realizar o cache:

# chown -R proxy:proxy /var/lib/ssl_db

Reinicie o Squid:

# systemctl status -l squid3
● squid3.service – LSB: Squid HTTP Proxy version 3.x
Loaded: loaded (/etc/init.d/squid3)
Active: active (running) since Seg 2015-07-20 15:39:45 BRT; 3s ago
Process: 9493 ExecStop=/etc/init.d/squid3 stop (code=exited, status=0/SUCCESS)
Process: 9552 ExecStart=/etc/init.d/squid3 start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/squid3.service
├─1452 /usr/sbin/squid3 -YC -f /etc/squid3/squid.conf
├─1454 (squid-1) -YC -f /etc/squid3/squid.conf
├─1456 (logfile-daemon) /var/log/squid3/access.log
└─1469 (pinger)

Jul 20 15:39:45 onix squid3[9552]: Starting Squid HTTP Proxy 3.x: squid3Creating Squid HTTP Proxy 3.x cache structure … (warning).
Jul 20 15:39:45 onix squid3[9552]: 2015/07/20 15:39:45| Squid is already running! Process ID 1454
Jul 20 15:39:45 onix squid3[9552]: .

Importe o certificado onix.der para o cliente e verifique o acesso à páginas HTTPS através do log em /var/log/squid3/access.log:

# tail /var/log/squid3/access.log
1437524554.277    180 172.16.222.41 TCP_MISS/200 642 GET https://www.google.com.br/url? – ORIGINAL_DST/74.125.196.94 text/html
1437524554.277    180 172.16.222.41 TCP_MISS/200 642 GET https://www.google.com.br/url? – ORIGINAL_DST/74.125.196.94 text/html
1437524560.693    731 172.16.222.41 TAG_NONE/200 0 CONNECT 157.56.172.28:443 – ORIGINAL_DST/157.56.172.28 –
1437524560.693    731 172.16.222.41 TAG_NONE/200 0 CONNECT 157.56.172.28:443 – ORIGINAL_DST/157.56.172.28 –
1437524570.129   9412 172.16.222.41 TCP_MISS/302 1999 GET https://www.live.com/ – ORIGINAL_DST/157.56.172.28 text/html
1437524570.129   9412 172.16.222.41 TCP_MISS/302 1999 GET https://www.live.com/ – ORIGINAL_DST/157.56.172.28 text/html
1437524580.790    911 172.16.222.41 TAG_NONE/200 0 CONNECT 131.253.61.66:443 – ORIGINAL_DST/131.253.61.66 –
1437524580.790    911 172.16.222.41 TAG_NONE/200 0 CONNECT 131.253.61.66:443 – ORIGINAL_DST/131.253.61.66 –
1437524590.058   9250 172.16.222.41 TCP_MISS/200 9920 GET https://login.live.com/login.srf? – ORIGINAL_DST/131.253.61.66 text/html
1437524590.058   9250 172.16.222.41 TCP_MISS/200 9920 GET https://login.live.com/login.srf? – ORIGINAL_DST/131.253.61.66 text/html

Após a compilação aplique as configurações necessárias ao squid.conf.

Para que o Sarg gere os relatórios corretamente, basta localizar as linhas access_log e output_dir e atualizá-las conforme exemplo:

Execute o comando:

# sarg

O acesso ao relatório do Sarg pode ser acessado através do endereço:

• http://IP-do-servidor/squid-reports

CONCLUSÃO

Na segunda parte deste artigo os seguintes tópicos serão apresentados:

• Configuração do Samba (compartilhamento Windows) e NFS (compartilhamento Linux).
• Criação de scripts para atualização remota de estações GNU/Linux e desligamento agendado.
• Criação de repositório local para atualização das estações GNU/Linux.
• Verificação do funcionamento dos serviços a partir dos Logs.
• Configurações adicionais dos clientes.

Referências:

• Penetration Testing
• squid : Optimising Web Delivery