Proxy Squid - 6

Exercitando as ACLs

Configurações básicas

Como comentado, toda a estrutura do Squid é baseada em listas de acessos.

Criando uma lista de acesso básica para nossos usuários.

Vamos supor que nossa rede interna seja 192.168.5.0/24. Crie a seguinte linha no squid.conf, na seção de ACLs (TAG: acl):

     acl rede_interna src 192.168.5.0/24

E a seguinte linha na seção de acesso (TAG: http_access)

     http_access allow rede_interna

 

Para declarar ACL's, a sintaxe básica é a seguinte:

acl |""

 

Um exemplo prático de ACL:

 

acl palavra_proibida url_regex -i sexo

A ACL acima bloqueia todos os sites que contenham em seu endereço a palavra "sexo".

É simplesmente inútil o uso de ACL's sem o uso da tag http_access. É ela que trava ou libera o que a ACL está estipulando.

Exemplo:

http_access deny proibido

Se nós considerarmos o conjunto ACL + http_access, ficaria:

acl proibido url_regex -i sexo

http_access deny proibido

 

O que o conjunto acima faz é proibir que qualquer site que possua em seu endereço a palavra "sexo" seja exibido para o requisitante. Nem sempre você vai utilizar um http_access para cada ACL que você fizer, às vezes você pode combinar duas ACL's em um único http_access, como é visto em outros casos.

Ordem das ACL's

Esta é uma dúvida que é muito comum.

"Qual a ordem que devo utilizar as minhas ACL's? Porque eu estou colocando tudo certo e não está funcionando!".

A resposta para essa pergunta não é tão simples assim. Eis o que o Squid faz quando vai tratar das ACL's.

  • 1 - O Squid vai ler todas as ACL's e testar se todas as ACL's declaradas possuem uma sintaxe correta e se elas estão sendo referenciadas por algum http_access;
  • 2 - Depois disso, se ele iniciar normalmente (Pode ser que outros fatores impeçam isto), ele irá começar a testar todas as requisições que são feitas para ele e tentar casar as mesmas com as regras que as ACL's estipulam em conjunto com os http_access;
  • 3 - Caso uma URL case com uma ACL, ele ignorará todas as outras ACL's para aquela requisição.

Uma outra maneira mais prática de tentar implementar isso é fazer da seguinte maneira:

  • 1 - Primeiro coloque as ACL's que estipulam uma excessão à alguma regra de bloqueio que virá à seguir;
  • 2 - Depois coloque as suas ACL's que vão bloquear sites e tudo o mais;
  • 3 - Só então você coloca as suas ACL's liberando o acesso.

Restringindo o acesso ao Squid

Se nós quisermos que somente uma rede da nossa empresa acesse o proxy, nós podemos definir faixas de IP's ou redes inteiras para a utilização do proxy. Quando você encontrar a linha http_access allow all, ela vai estar liberando acesso à todos os hosts, Agora crie uma nova ACL do tipo "src", especificando a rede interna:

acl redeinterna src 192.168.0.0/24

Agora autorize a ACL que você acabou de criar por meio de um http_access:

http_access allow redeinterna

Como visto acima, estamos somente permitindo o uso ao proxy pela rede interna. Agora, caso você queira especificar uma range de IP's, faça assim:

acl faixa_adm src 192.168.0.10-192.168.0.50

http_access allow faixa_adm

 

Bloqueando sites indesejados

O tipo de ACL url_regex serve para nós compararmos termos dentro de uma URL para que possamos compará-la e saber se esta palavra está ou não liberada e se os usuários vão ou não, visualizar a página. Nós utilizamos muito isso quando desejamos que sites pornográficos não sejam vistos por usuários dentro de uma empresa.

Vamos ao exemplo:

Adicione a seguinte ACL:

acl palavra url_regex -i sex

Agora bloqueie o acesso com o http_access:

http_access deny palavra

 

Com este exemplo, todos os sites que possuam a palavra "sex" em seu endereço não serão visualizados pelos usuários. O parâmetro "-i" serve para que o Squid não distingua entre maiúsculas ou  minúsculas.

Porém neste momento você deve estar pensando que não é prático definir uma ACL para cada palavra que você deseje bloquear. E realmente não é. Por isso, vamos declarar listas inteiras de palavras negadas.

Eis o exemplo:

Vamos criar o arquivo texto que nos vai servir como lista de palavras bloqueadas e será dado a ela permissões de leitura:

# touch /etc/squid/lists/blocked.txt (criando uma lista com o nome  blocked)

# chmod 755 /etc/squid/lists/blocked.txt (atribuindo permissões à ela)

Nele insira todas as palavras proibidas. Lembre-se que você deve adicionar uma palavra por linha.

Após isto, nós criamos a ACL da seguinte maneira:

acl blocked url_regex -i "/etc/squid/lists/blocked.txt"

E bloqueamos o acesso com o http_access:

http_access deny blocked

 

Feito isto, todos os sites que contém em seu endereço palavras como "sex", "sexo", "sexologia" vão ser bloqueados, porém como no último exemplo, nem todos os sites que contém a palavra "sex" é um site pornográfico . Mas como distinguir os sites que podem ser liberados dos que não podem? Simples, vamos criar uma outra lista para as excessões como "sexologia".

Vamos seguir o mesmo procedimento.

Criando uma lista também para as palavras não bloqueadas:

# touch /etc/squid/lists/unblocked.txt

# chmod 755 /etc/squid/lists/unblocked.txt

 

Nesta lista nós também vamos colocar todos os sites que são excessões à regra, como "www.sexologia.org". Também um site por linha. Se você preferir colocar as palavras somente, tudo bem também. Depois você vai ter que juntar as duas ACL's em um único http_access, desta maneira:

http_access deny blocked !unblocked

 

Note a utilização do sinal de !, significando uma inversão no sentido da regra, este sinal é extremamente útil no seu dia-a-dia.

Utilizando IPs e redes

 

Isso é o básico das ACLs. Limitar por IP e/ou rede. Exemplos para simplificar:

  acl ip_do_diretor src 192.168.0.5
  acl ips_da_diretoria src 192.168.0.5 192.168.0.6 192.168.0.7
  acl rede_do_rh src 192.168.0.7/24
  acl rede_do_cpd src 192.168.0.6/255.255.255.0

 

Usando ACLs externas

O recurso de ACL externa é muito útil para um tratamento melhorado de algum recurso que não é compreendido por ACLs normais.

Uma ACL externa pode ser escrita em qualquer linguagem. Ela deve sempre retornar OK para o stdout caso a condição seja satisfeita, ou ERR também para o stdout caso ela não seja satisfeita.

Vou mostrar aqui um exemplo onde a diretoria deve acessar qualquer coisa, mas os usuarios normais sao submetidos a certas restrições. Levo em consideração que o usuário já está autenticado.

  external_acl_type checa_diretoria %LOGIN /etc/squid/modulos/diretoria.sh
  acl diretoria external checa_diretoria


Arquivo /etc/squid/modulos/diretoria.sh (deve ser executável)

        #!/bin/bash
       while read linha
       do
               if [ `grep -i $linha /etc/squid/users/diretoria` ]
              then
                              echo OK
               else
                              echo ERR
               fi
       done

Esse script verifica se o usuário autenticado pertence à diretoria. Para que um usuário seja reconhecido como diretoria, seu username deve estar dentro do arquivo /etc/squid/users/diretoria.

Trabalhando com domínios

Esse tipo de ACL tem que ser utilizada com cuidado. Tentar bloquear o acesso a chat em portais com essa opção também pode acarretar em acesso negado a sites de notícias ou de interesse geral. Todos os sub-domínios e hosts abaixo do domínio principal são afetados pela ACL.

  acl GEOCITIES dstdomain geocities.com

 

Expressão regular na URL

Aqui podemos fazer milhares de coisas, desde que conheçamos muito bem expressões regulares. Para saber mais sobre elas, procure o livro "Expressões Regulares - Guia de Consulta Rápida" ou pesquise na internet.

     acl jogos url_regex jogos

 

 

Restringindo por horários

Para  fazer isto usarei a ACL do tipo time.

Exemplo:

acl horariopermitido time MTWHF 08:00-18:00

http_access deny !horariopermitido

 

O sinal de exclamação aparece, invertendo o sentido da regra. Interpretando a regra fica assim: negar o uso do proxy em todos os horários, COM EXCESSÃO do horário especificado na ACL horariopermitido.

O "MTWHF" na frente da ACL. Ela especifica os dias da semana conforme esta tabela:

  • S - Sunday (Domingo)
  • M - Monday (Segunda)
  • T - Tuesday (Terça)
  • W - Wednesday (Quarta)
  • H - Thursday (Quinta)
  • F - Friday (Sexta)
  • A - Saturday (Sábado)

Liberando e bloqueando um acesso específico

O chefe proibe as coisas para os usuários, mas ele quer ter o controle completo. Para contornar a situação, faça o seguinte:

Caso você utilize proxy convencional, sem autenticação:

acl chefe src 192.168.1.23

E permitir a lista de palavras negadas para ele, assim:

http_access allow blocked chefe

Caso você utilize proxy autenticado:

acl chefe proxy_auth nome_do_chefe

E permitir a lista de palavra negadas para ele, assim:

http_access allow blocked chefe

Uma outra maneira de se fazer ambos os bloqueios é definir o IP/login do seu chefe em uma ACL e na hora em que for declarar o http_access, definir acima das ACL's de bloqueio, assim:

http_access allow chefe

http_access deny blocked !unblocked

 

Acessando somente sites específicos 

Ao invés de especificar os sites negados, você vai especificar o site que ele vai poder acessar. Este exemplo também pode ser adaptado para outros sites, não somente para o site de bancos e caso sejam muitos sites, você pode especificá-los em uma lista também.

Caso você utilize proxy convencional, sem autenticação, faça assim:

Primeiramente, especifique os sites que eles irão poder acessar:

acl bancos url_regex -i "/etc/squid/lists/bancos"

Adicione os endereços dos bancos na lista e especifique também o IP do computador do usuário:

acl financeiro src 192.168.0.8

Então junte os dois em um único http_access, desta maneira:

http_access deny !bancos financeiro

Interpretando a regra, fica: Vamos bloquear todos os sites, COM EXCESSÃO DOS SITES ESPECIFICADOS NA LISTA DE BANCOS para o IP 192.168.0.8.

Caso você utilize proxy autenticado, o pensamento é praticamente o mesmo, mas como é sempre bom praticar, vamos explicar todo o procedimento novamente:

Primeiramente, especifique o login do usuário por meio de uma ACL:

acl financeiro proxy_auth nome_do_usuario

Depois especifique os endereços dos sites que você quer que o usuário  tenha acesso, desta maneira:

acl bancos url_regex -i "/etc/squid/lists/bancos"

 

Insira os endereços que você deseja que o usuário acesse na lista e não se esqueça de dar as permissões de leitura para o arquivo.

Depois, junte as duas ACL's com um único http_access:

http_access deny !bancos financeiro

 

Bloqueando MSN

 O MSN a partir da versão 6.x (in)felizmente passou a fazer conexões utilizando tunneling por http, ou seja, ele se conecta pela porta 80. Sendo assim, é muito difícil fazer o bloqueio do MSN se não utilizados softwares como o layer-7 ou o Squid, que tratam as requisições vindas pela porta 80. O layer-7 é um software muito interessante também, trabalhando na camada de aplicação da tabela OSI. O bloqueio do Squid é simples de ser feito, bastando adicionar o termo "gateway.dll" na sua lista de palavras negadas.

Bloqueando extensões e downloads de determinados

É incrível o número de pessoas que nos dias atuais se infectam com vírus contidos em arquivos de extensões conhecidas por conter programas maliciosos, como o .bat e o .pif. Você pode bloquear extensões que os seus usuários baixam no computador por meio de HTTP ou de FTP e de quaisquer outros protocolos que o Squid suporte, fazendo os seguintes passos:

Primeiramente, você deve criar uma lista e seta as permissões corretas:

# touch /etc/squid/lists/extensoes

# chmod 755 /etc/squid/lists/extensoes

Feito isto, você deve escrever as extensões que você quer bloquear da seguinte maneira no arquivo:

\.mp3$

\.wav$

\.pif$

\.bat$

Atenção: O "\" é um eliminador de metacaracteres e serve para cancelar a função do ".". Já o "$" serve para que seja analizado até o final de string.

Agora nós vamos adicionar a ACL no Squid que vai bloquear as extensões efetivamente, juntamente com o seu http_access:

acl extensoes urlpath_regex -i "/etc/squid/lists/extensoes"

http_access deny extensoes

Note que ao invés do url_regex, foi utilizado o urlpath_regex.

Linha 2850        visible_hostname squid.nomedodominio.com.br

Linha 3495        error_directory /usr/local/squid/share/errors/portuguese

 

  • Comando para gerar um cache no squid

·         Comando para iniciar o squid

 

 

MAC Address

Para utilizar essa opção, o Squid deve ser compilado com os parâmetros "--enable-arp-acl", como feito em nossa instalação via source.

     acl administrador arp XX:XX:XX:XX:XX:XX

Onde: XX:XX:XX:XX:XX:XX é o MAC Address da placa de rede do administrador.

 

Limitando o número de conexões por usuário

Se quiser limitar o número de sessões que cada usuário abre de uma única vez, podemos utilizar o recursos de máximo de conexões.

  acl CONEXOES maxconn 10
  http_access deny CONEXOES rede_interna

 

Impedindo ou Limitando o tamanho de uploads

Diversas empresas tem a necessidade de impedir que seus usuários dêem upload de arquivos para webmails, discos virtuais ou algum outro tipo de repositório na internet. O grande problema é que o método utilizado para fazer estes uploads é o POST, também utilizado para preenchimento de formulários, pesquisas, logins e senhas, etc. Isso impede o bloqueio total do método. Como fazer?

A opção mais lógica seria limitar o tamanho de um POST para um número suficientemente grande para permitir seu funcionamento normal e suficientemente pequeno para impedir o upload de arquivos. Para isso será usado a tag request_body_max_size.

No entanto essa tag tem uma falha, por não ser compatível com ACLs, ela limitará todos os usuários no que for determinado, situação normalmente incômoda.

Um script que nos permite criar ACLs baseadas nesse parâmetro. Vamos chamá-lo de /etc/squid/modulos/size.sh

  #!/bin/sh
  while read line; do
    set -- $line
    length="$1"
    limit="$2"
    if [ "$length" -le "$2" ]; then
      echo OK
     else
      echo ERR
     fi
  done


Depois basta criar uma ACL assim:

 external_acl_type request_body %{Content-Length} /etc/squid/modulos/size.sh
 acl request_max_10KB request_body 10240

Com isso limitamos o tamanho do upload para 10KB, o que deve ser suficiente para preenchimento de um formulário, mas pouco para um upload.

 


Proxy Transparente

O uso de proxy transparente libera você do trabalho de configurar os browsers individualmente para trabalhar. Se você tem uma centena, ou um milhar, de usuários em sua rede, muitas vezes é uma dor de cabeça configurar cada browser para usar proxies -- ou para convencer os usuários para editar as preferências do browser e escrever aqueles símbolos que eles não entendem.

Ao usar um proxy transparente, você intercepta as solicitações de páginas da web e redireciona as mesmas através do proxy. Bonito e simples – aparentemente.

Porque não usar um proxy transparente

O uso de proxy transparente (também conhecido como sequestro de TCP -- "TCP hijacking") é parecido com o "Network Address Translation" (NAT) em alguns aspectos: deve ser evitado a todo custo, e somente usar se não houver, positivamente, nenhum outro jeito.

O proxy transparente não funciona bem com certos browsers web. Com a maioria dos browsers ele funciona bem, mas mesmo se um quarto de seus usuários está usando browsers mal comportados, você pode esperar que os custos de helpdesk excedam qualquer benefício que você pode ganhar com o proxy transparente. Infelizmente, estes browsers são largamente utilizados.

Estes browsers se comportam de forma diferente se sabem que há um proxy. Todos os outros browsers seguem o padrão, e a única alteração que eles fazem com um proxy é direcionar as solicitações para uma máquina e porta diferentes. Browsers que não se comportam bem deixam alguns cabeçalhos HTTP fora das solicitações, e só acrescentam os mesmos se sabem que há um proxy. Sem aqueles cabeçalhos, comandos de usuários como "reload" não funcionam se houver um proxy entre o usuário e a origem.

O proxy transparente também introduz uma camada de complexidade, que pode complicar transações que de outra forma seriam simples. Por exemplo, aplicações baseadas em web que pedem um servidor ativo não podem fazer o teste do servidor fazendo uma conexão -- eles serão conectados ao proxy em vez do servidor.

Teoria de um proxy transparente

Como funciona o proxy transparente?

Um firewall ou outro redirecionador captura as conexões TCP direcionadas a portas específicas em hosts remotos (normalmente a porta 80), e direciona as mesmas para o servidor proxy local. O servidor proxy usa os cabeçalhos HTTP para determinar para onde ele deve fazer a conexão, e faz a conexão.

Administradores de sistema são geralmente pedidos para fazerem proxy transparente de FTP e SSL, mas estes protocolos não podem passar por proxy transparente. O FTP é um protocolo mais complexo que o HTTP, e dá menos dicas sobre a origem da solicitação. O SSL é criptografado e não contém dados úteis sobre o destino. Tentativas de decodificar o SSL são exatamente o que o SSL é feito para evitar: decodificar o SSL para proxy transparente, isto é indistinguível de um "verdadeiro" ataque man-in-the-middle.

Para executar um proxy transparente, precisamos de um servidor entre o cliente e o destino. Este servidor deve ter as facilidades necessárias para combinar e redirecionar o tráfego, como o netfilter e o iptables. Qualquer sistema de firewall capaz de Network Address Translation e redireção de tráfego pode ser usado.

Você precisará configurar uma regra para capturar o tráfego destinado à porta 80 em hosts externos, e redirecionar este tráfego para a porta de um servidor proxy na máquina que está fazendo a interceptação.

Pode-se ter proxies que não estão na máquina que faz a interceptação, mas estes são mais complicados. Primeiro, o endereço de origem da solicitação não está mais disponível ao proxy, ele é perdido no processo de redireção. Você pode resolver este problema usando NAT (Network Address Translation) de destino, mas você terá que rotear o tráfego do proxy de volta para o servidor que faz a tradução. Se você tentar fazer o proxy passar a resposta HTTP de volta diretamente, o cliente ficará confuso e (corretamente) irá recusar comunicar com o proxy. O proxy não é a máquina que o cliente pensa estar falando com -- o cliente pensa que está fazendo a solicitação para o servidor de destino. O proxy precisa rotear de volta através do interceptador, de forma que os endereços possam ser convertidos novamente, e deixar o cliente acreditando que está falando diretamente com o servidor web.

O protocolo HTTP/1.1 tornou a vida mais fácil para os proxies transparentes, tornando obrigatório o cabeçalho de host. Este cabeçalho contém o nome da máquina (conforme informado na URL) e permite web hosting virtual baseado em nomes, permitindo que o servidor web use o cabeçalho do host para determinar com qual página deve responder.

Para os proxies transparentes, ele dá ao proxy o nome de host. Tendo recebido uma conexão à porta 80 que foi interceptada, o servidor proxy precisa entender que não está recebendo uma URI (Uniform Resource Identifier) absoluta completamente qualificada, mas uma URI relativa. Normalmente, um servidor proxy recebe http://host/path, mas se o cliente pensa que está falando diretamente com o servidor, e não um proxy, ele só pede por /path.

O servidor proxy usa o cabeçalho HOST para recuperar a URI completamente qualificada, e então checa seu cache e faz o serviço de proxy usual.

O Squid pode ser utilizado para proxy transparente por que ele também foi projetado para ser um proxy reverso (também conhecido como acelerador HTTP, ou "HTTP accelerator"), e pode ler estes cabeçalhos de solicitação abreviados. No modo acelerador, ele fica em frente ao servidor web verdadeiro e recebe solicitações como se fosse o servidor web, portanto foi projetado com a habilidade de reconstruir URIs relativas. Para usar o Squid como proxy transparente, este comportamento de acelerador web será habilitado.

Quando usar o Squid como acelerador HTTP, configure o nome de host e a porta que você quer que o proxy acelere. Isto previne que o Squid seja usado como um HTTP relay arbitrário. Quando estiver usando o Squid no modo acelerador como um proxy transparente, configure o host name para virtual e a porta para qualquer porta para a qual queremos fazer proxy transparente.

Para iniciarmos a configuração do Squid como proxy transparente, insira ou descomente as seguintes linhas no arquivo /etc/squid/squid.conf:

No arquivo squid.conf, configure estas opções:

httpd_accel_host virtual

httpd_accel_port 80

(Ou qualquer porta que você queira fazer proxy)

httpd_accel_with_proxy on

httpd_accel_uses_host_header on

Atenção: Observe que você não pode fazer proxy transparente de mais de uma porta por vez. O cabeçalho HTTP não contém informação de porta, de forma que o Squid não pode saber para que porta a solicitação foi feita uma vez que a solicitação tenha sido interceptada.

Configurando um proxy transparente

Interceptação de tráfego

Intercepte e/ou redirecione o tráfego para a porta escolhida. Ter o proxy na mesma máquina que faz a interceptação é preferível. O código exemplo usa o iptables como mecanismo de redireção, e a porta 8080 como a porta http_port do proxy.

Como root, execute o comando:
#  iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

ou

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

Neste exemplo acima utilizamos a interface de rede eth0 como se fosse a interface ligada na rede local. Você deve adaptar o exemplo à sua rede. O exemplo também assume que o iptables e o servidor proxy estão sendo executados na mesma máquina. Caso os serviços estejam em máquinas separadas, a linha de comando para o iptables é ligeiramente diferente:

# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-dest IP:3128

ou

# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to IP:8080

 

IP - Deve ser substituído pelo endereço IP da máquina onde o servidor Squid esta sento executado.

Para que esta regra esteja ativa logo após a inicialização do sistema operacional, execute em seguida os comandos:


# iptables --save > /etc/sysconfig/iptables

# chkconfig iptables on

Ao reiniciar o Squid ("service squid restart" ou "/etc/init.d/squid restart") os clientes já poderão navegar normalmente em necessidade de especificar no browser qual servidor proxy deve ser utilizado.

Dicas

  • Você pode perder o endereço origem da solicitação se o proxy também não é o interceptador de tráfego. Você pode corrigir isto utilizando NAT de destino em vez de redireção de pacotes, e certificando-se que o proxy faça roteamento de todos os pacotes de volta para o computador que faz a interceptação, incluindo o tráfego para os clientes (ou alternativamente faça que o proxy seja a máquina que faz a interceptação).
  • Alguns browsers não conseguem fazer refresh de conteúdo através de um proxy transparente. O cliente não consegue enviar cabeçalhos de cache coerentes, assumindo que está falando com um servidor web, e assumindo que não há proxy ou agente de cache (incluindo aceleradores web) no meio. Usuários destes browsers terão problemas e serão problemas para o IT helpdesk. Não tem correção conhecida para este problema, além de não usar estes browsers com qualquer tipo de proxy ou agente de cache.
  • É mais barato em termos de ciclos de CPU e memória ter os browsers configurados explicitamente para usar um proxy, do que redirecionar o tráfego. É mais barato em termos de ciclos de CPU e memória bloquear a porta 80 ao invés de redirecionar o tráfego. O bloqueio tem menos overhead que a redireção, e pode forçar as pessoas a utilizar um proxy.
  • Não esqueça de verificar os arquivos de log do Squid quando não estiver conseguindo resolver algum problema. O Diretório padrão de armazenamento dos arquivos de log é: /var/log/squid/. Os principais arquivos são cache.log, access.log e o squid.out, que armazenam respectivamente, informações sobre o cache do servidor proxy, os acessos feitos através do proxy e mensagens de erro emitidas pelo deamon do Squid.

Aqueles que preferem uma interface gráfica para configuração de servidores podem optar pelo Webmin, um gerenciador de sistema com interface web que contém um módulo para gerenciamento do Squid. O download do Webmin pode ser feito através do site http://www.webmin.com

Adonel  Bezerra

Pós-graduado em Teoria em Educação a Distância e Docência do Ensino Superior;

MBA Executivo em Coaching;

Coordenador de cursos de pós-graduação.

Experiência em Gestão de Negócios, envolvendo-se com as áreas administrativa, financeira, comercial, produção e logística;

Experiência de mais de 20 anos como professor conferencista na área de segurança da informação;

Sólida experiência na gestão de negócios e tecnologia da informação;

Sólida experiência no meio acadêmico; 

Consultor de Segurança da informação com mais de vinte anos de experiência;

Treinamentos e palestras ministrados para milhares de profissionais em todo o Brasil;

Livro publicado pela Editora Ciência Moderna e diversos artigos publicados.

 

ALGUMAS PARTICIPAÇÕES COMO CONFERENCISTA OU PALESTRANTE

Centro Universitário do Maranhão – UniCeuma/2009 – Apresentação “O MERCADO DE CONSULTORIA EM SEGURANÇA DE INFORMAÇÃO. 

Universidade de Fortaleza|UNIFOR – Apresentação “TÉCNICAS HACKERS PARA TESTES DE INVASÃO”.

Faculdades Integradas do Ceará – FIC/2010 – Apresentação “ SEGURANÇA DA INFORMAÇÃO”.

Escola de Gestão Pública do Estado do Ceará – /2012 – Apresentação “ SEGURANÇA DA INFORMAÇÃO COM SOFTWARE LIVRE”.

Faculdade La Salle – 2013 – Apresentação “ESPIONAGEM INTERNACIONAL”.

Estácio|FIC/2013 – Apresentação “ ANÁLISE DE VULNERABILIDADES COMO FATOR PRIMORDIAL NAS ORGANIZAÇÕES”.

Estácio|FIC/2015 – Apresentação “PROVA DE CONCEITO”.

Devry Brasil|FANOR Salvador/BA, Fortaleza/CE, Belém/PA, Caruaru/PE, Recife/PE, Teresina/PI    - Apresentação “ VULNERABILIDADES DE SISTEMAS COMPUTACIONAIS”.

 

PROJETO PESSOAL – 1998 – Até o momento

- Fundador e Mantenedor de um dos maiores portais de Segurança de sistema do Brasil, o portal Clube do Hacker; www.clubedohacker.com.br

Fundador e mantenedor da Academia Linux www.academialinux.com.br

Fundador da BUCOIN – www.bucoin.com.br