Relatórios de Acesso do ISA Server com o SARG

Boa tarde!

Atualização 02/01/2012: A solução funciona perfeitamente com o TMG 2010.

Bom, estou colocando esse post mais para eu mesmo não mais esquecer... Já havia implementado essa solução tempos atrás mas não documentei. Hoje fiquei puto da cara pois tive que refazer alguns testes até ficar tudo ok, ou seja, perdi tempo.

Em fim. Meu objetivo aqui é mostrar como posso gerar logs de acesso à WEB pelo proxy do ISA Server 2004/2006 (Outras versões não testei).

Por que?

Simplesmente porque o ISA Server é muito pobre na questão de relatórios. Nativamente conseguimos apenas gerar um Report com os 10 usuários que mais acessaram determinados protocolos e tal. Claro! Ele permite que guardamos os logs em banco de dados (adivinha qual? SQLServer) e isso possibilitaria fazermos uma ferramenta que consulte esse banco e nos monte um relatório descente. Porém isso demanda tempo e trabalho.

Como muito admins não têm tempo sobrando para isso, a Microsoft tem uma série de partners que disponibilizam uma ferramentinha prontinha para isso. Viu como é esse meio do Software Proprietário? E os preços dessas ferramentinhas não é nada amigável.

Em fim. Como já estudei TUDO relacionado ao ISA Server na época que me certifiquei na versão 2006, lembrei-me que ele tem uma forma de gerar logs em padrão aberto (W3C). Perfeito!! Se ele consegue gerar logs assim eu consigo manipulá-lo.

E depois?

Bom, a menos que eu esteja completamente maluco, jamais cairia nesse golpe comercial comprando uma ferramenta que faz algo tão simples: Gerar relatórios de acesso Web. Falando desse assunto, ninguém melhor que o SARG (Squid Analyst Report Generator). Há quem diga que o MySAR é melhor, mas o testei e só achei uma vantagem em relação ao SARG, que salvar os dados em Banco de Dados. Tirando isso o SARG tem muito mais recurso, é bem mais flexível e maduro. Contudo respeito outras opiniões.

Bom como o próprio nome já diz, o SARG foi feito para ler logs do squid (normalmente o access,log).

Raciocínio!

- Tenho um ótimo gerador de logs, que simplesmente lê o access.log e faz um relatório bem bonitinho.

- Tenho acesso ao access.log, logo sei de tudo que o SARG precisa ou não.

- Tenho acesso ao arquivo W3C do ISA Server, logo posso comparar com o access.log e deixá-los mais parecidos possível.

- Vou ajustando, testando, ajustando, testando até funcionar.

O grande segredo!

Bom, o grande segredo dessa mágina está na forma de gerar o Log do ISA Server. O arquivo w3c nativo tráz uma porrada de informação que acho que somente o ISA sabe para que servem. O segredo é ajustarmos para ele gerar logs somente com a informação necessária ao SARG.

Mas como?

Serei bem breve, pois quem deseja fazer essa loucura pressuponho que já saiba mexer no ISA Server.

Acesse a sessão "Monitoring", depois clique em "Configure Web Proxy Logging" no Painel de Tarefas.

Na janelinha que abrirá escolha "File" e "W3C extended log file format". Em "Options" defina a pasta dos logs, rotações, etc.

Depois dessa maracutaia vá para a aba "Fields" e desmarque uma porrada de opções.

Tem que ficar apenas as seguintes:

- Client IP;

- Client Username;

- Log Date;

- Log Time;

- Destination Host Name;

- Destination IP;

- Processing Time;

- Bytes Received;

- Bytes Sent;

- Protocol;

- HTTP Method;

- URL;

- HTTP Status Code.

Feito isso dê um ok em tudo que for janela do Windows, aplique as configurações do ISA Server e já pode testar os logs com o SARG.

FAQ:

P: Como passar o arquivo de log do ISA Server para o servidor Linux?

R: Ótima pergunta. Primeiro o lugar do SARG é no Linux. Tem versão Windows tenho minhas dúvidas. Seria como rodar um Internet Explorer no Linux! hehehe Para transferir o arquivo de um jeito.

P: Meu ISA é em português. Quais os nomes dos campos?

R: Você é completamente maluco!!!

P: É só isso?

R: Dessa forma vai funcionar, mas se você for uma pessoa criteriosa vai ver que da para fazer MUITAS melhorias nos relatórios simplesmente com uma configuração bem feita do sarg.conf.

Agora nunca mais vou esquecer!!! hehehehe

Referência sobre campos dos Arquivos de Log do Squid:
http://wiki.squid-cache.org/SquidFaq/SquidLogs

Abraço!

Roteamento Avançado em Linux

Olá!

Essa é uma técnica bem simples porém muito útil quando temos dois links de Internet. Felizmente o Linux, como de costume, permite mexermos em qualquer funcionalidade dele.

Nesse caso, faremos uma alteração relacionada à tabelas de roteamento podendo direcionar tráfegos bem específicos para o link que quisermos.

A situação mais comum para usarmos essa técnica é a de uma empresa com dois Links de Internet sendo um deles o principal, ou seja,  por onde saem todos os serviços e por onde estão publicados endereços externos, etc e um outro usado apenas como redundância para acesso a Internet.

Já que o link principal normalmente é o mais usado, nosso link secundário acaba sendo subutilizado. Por experiência, posso garantir que o trafego Web (tcp/80 - http e tcp/443 - https) é um dos maiores consumidores de link. Isso é lógico, cada vez mais dependemos da Internet.

Então, nesse post fareia seguinte configuração: Tudo que for serviço sai pelo Link Principal e tudo que for tráfego Web sai pelo Link Secundário. Isso vai garantir que os dois links sejam utilizados de forma equilibrada. Lembrando que isso não é regra!! Podem ter situação que outros tráfegos possam predominar, portanto faça uma análise da sua rede antes de seguir esse post.

Mãos-a-obra

Nosso objetivo é fazer essa façanha simplesmente manipulando tabelas de roteamento do nosso Firewall.

Para isso a primeira dependência que temos é o pacote iproute2. Normalmente ele já vem instalado na maioria das distros. Senão estiver instalado? Da um jeito de instalar ué!!

Bom, começaremos editando o arquivo /etc/iproute2/rt_tables.

Esse arquivo já vem com 3 tabelas de roteamento por default como no exemplo abaixo:

$ cat /etc/iproute2/rt_tables
255     local
254     main
253     default

OBS: Quanto maior o número, maior a prioridade da tabela no sistema.

Local: Essa é uma tabela padrão criada pelo Kernel que serve para gerenciar todos os endereços locais da máquina. Ela possui todos os endereços cadastrados na interface do firewall. Não tem necessidade de mexermos nela a não ser que você seja um maníaco testador.

Comando bacana:

$ ip route show table local

Main: Essa e principal tabela do sistema. É nela que criamos rotas, adicionamos nosso default gateway, etc. Todos os comando de roteamento, por padrão, apontam para ela.

Comandos bacanas:

$ ip route show table main

$ route -n

Default: Como quase tudo que é desenvolvido, principalmente na área de redes, os desenvolvedores sempre criar algo que poderá ser utilizado no futuro caso haja a necessidade de algo que não foi previsto enquanto ele digitava o código desse treco, ou seja, essa tabela de roteamento vem vazia e não serve para nada a não ser que mandemos ela fazer algo.

Legal vamos deixar esse default bem quietinha no lugar dela e vamos criar uma nova tabela. Edite o arquivo rt_tables e adicione uma nova tabela.

Ex:

$ cat /etc/iproute2/rt_tables
255     local
254     main
253     default

100     link_sec

Por quê o número 100?

Porque acho um número fácil de digitar, decorar e também misterioso para os leigos... heheheh Na verdade você pode usar qualquer número entre 1 e 255. Mas recomendo fortemente usar algum menor que os números das tabelas default. Caso duvide pode fazer um teste. É bem divertido.

Com essa alteração criamos uma tabela nova e zerada. Nenhum tráfego vai passar por ela, pois na pior das hipóteses ele vai casar com o default gateway da tabela main. É bem isso que queremos. Continue funcionando perfeitamente e especificaremos minuciosamente o que vamos mandar para a nova tabela.

Mas antes disso, vamos criar uma rota ou gateway nessa nova tabela.

$ ip route add default via "gateway" table link_sec

Para conferir:

$ ip route show table link_sec

Beleza! Agora tudo que cair nessa tabela vai para o link secundário.

Selecionando o Tráfego

Podemos fazer isso diretamente com parâmetros do ip rule, mas eles são um pouco limitados e como sou um adorador do iptables, usarei a extensão MARK dele para fazer isso.

Como quero que todo o tráfego WEB saia pelo Link Secundário, criarei a seguinte linha do iptables:

# iptables -t mangle -A PREROUTING -j MARK --set-mark 1 -p tcp -m multiport --dports 80,443 -i "interface interna" -d ! "rede interna ou dmz"

Essa linha colocará uma marca/garimbo em cada pacote que contiver 80 ou 443 na porta de destino e não for direcionado para o servidor local. Resumindo, marcará tudo que for navegação para fora da empresa.

Pronto, temos a tabela de roteamento criada, uma rota default dela para meu link secundário e todos os pacotes marcados.

Só falta jogarmos esses pacotes para a nova tabela e automaticamente eles sairão pelo link secundário.

Direcionando o Tráfego

Como já temos os pacotes marcados pelo iptables, vamos criar uma rule para eles.

# ip rule add fwmark 1 table link_sec

Prontinho, seu link tráfego já estará direcionado para o Link Secundário.

Observações:

- Verifique se as regras de Postrouting ficaram de acordo, senão não vai conseguir navegar em função do mascaramento incorreto.

- Instale um agente/gerenciador SNMP para monitorar as interfaces. Fica bacana. O Zenoss já serve.

- Não tente mexer nas outras tabelas com o comando ip. Isso pode causar um caos mundial em servidores de produção.

Abraço!

Cisco Port Security

Buenas!

Mais uma breve postagem sobre segurança de portas em Switches.

Para fazermos um switch funcionar, basicamente precisamos comprá-lo, ligá-lo na energia e plugarmos os hosts em suas portas. Simples e fácil. Isso é uma opção dos fabricantes em tornar o dispositivo o mais fácil possível, porém todos os fabricantes recomendam fortemente configurações avançadas de segurança. 

Uma delas é o Port Security que trata-se de uma tecnologia para limitar e controlar a quantidade de dispositivos ligados em uma porta. Imagine a situação na qual você tem uma sala isolada em sua empresa com apenas uma porta LAN liberada para a única estação de trabalho que se encontra nessa salinha. Essa estação controla algumas câmeras IP e precisa estar sempre conectada mesmo que quase ninguém vá até a sala. Hehehe, que exemplo... : ).

Bom, mas onde eu quero chegar é que qualquer pessoa pode entrar nessa sala, plugar um HUB nesse ponto de rede, ligar a estação no HUB e mais um notebook. Pronto! Teremos uma máquina estranha conectada em nossa rede sem o nosso conhecimento e que pode estar transmitindo vírus, fazendo varreduras ou mesmo DoS na nossa LAN. Esse é um exemplo de risco com switches mal configurados.

Com Port Security podemos especificar que essa porta aceitará tráfego de apenas um  (ou mais) MAC Address e caso um segundo MAC tente trafegar por essa porta, caracterizando a situação acima, o Swicth tome algumas ações automaticamente:

protect: Simplesmente descartará qualquer pacote vindo desse MAC não autorizado.

restrict: Fará a mesma coisa que o protect além de também enviar TRAPs SNMP informando o que está ocorrendo.

shutdown: Essa é a mais drástica. Dará um shutdown administrativo na porta, o que significa que ela só voltará a funcionar se o administrador conectar no switch e mandar a porta funcionar novamente.

Particularmente acho a opção restrict mais vantajosa, pois sempre que houver uma violação o "atacante" não conseguira acesso à LAN e ainda poderei ver as informações do que está ocorrendo através do SNMP. Uma dica é utilizar uma ferramenta de monitoramento como o Zenoss para ajudar nessa tarefa.

Caso eu escolha shutdown, por exemplo, posso estar dando chance para o DoS e se um larápio souber disso ele vai se divertir nas suas custas.

Mas como ele fará o controle do MAC?

Podemos optar entre duas formas sendo a primeira manual e a segunda automática.

Mas como, câmbio?

Quando habilitamos Port Security em uma porta, temos que definir a quantidade de MACs que a porta aceitará. Por padrão ela aceitará apenas 1 MAC. Independente do número x de MACs que for configurado, poderemos especificar manualmente esses endereços ou ligar a opção sticky que irá liberar os primeiros x MAC a chegarem na interface. Fique calmo que colocarei os comandos depois. : )

Eu particularmente acho a opção do Sticky muito mais vantajosa pela menor esforço no gerenciamento, mas para estruturas realmente pequenas isso pode ser interessante olhando pelo lado da segurança.

Como configurar?

Exemplo bem breve e prático de como configurar:

! Acessa um range de portas para configurar tudo de uma só vez.

# interface range FastEthernet 0/1 - 24

! Tem que ser interface de acesso. Não pode ser trunk, por exemplo.

(config-if) # switchport mode access

! Habilita Port security.

(config-if) # switchport port-security 

! Define que a porta aceitará apenas 2 MACs.

(config-if) # switchport port-security maximum 2

! Se um terceiro MAC tantar acesso será descartado e traps SNMP serão enviadas.

(config-if) # switchport port-security violation restrict

! Os dois primeiros MAC que passarem pela porta serão cadastrados automaticamente.

! No lugar do sticky também pode ser digitado o MAC caso queira especificá-lo xxxx.xxxx.xxxx

(config-if) # switchport port-security mac-address sticky

Pronto!

Dicas de Segurança:

- Deixe todas as portas configuradas como portas de acesso para evitar que alguém se conecte em uma porta trunk e acesse todas as VLANs.

- Coloque portas que não são usadas em VLANs que não existem.

- Dê um shutdown administrativos em todas as portas que não estão em uso.

- Mantenha um capacitor sempre carregado para dar choque em quem tente atazanar sua LAN.

Em breve falarei sobre o 802.1x.

Abraço!