Blog SegInfo – Segurança da Informação – Tecnologia – Notícias, Artigos e Novidades

O artigo a seguir (Utilizando o Nmap Scripting Engine (NSE) – Funcionalidade do Nmap que permite executar scripts do usuário) está publicado no Blog Clavis e foi desenvolvido por Henrique Soares e Rafael Soares.

Utilizando o Nmap Scripting Engine (NSE) – Funcionalidade do Nmap que permite executar scripts do usuário

Introdução

Este artigo faz parte de uma série de artigos redigidos sobre a ferramenta livre e de código aberto Nmap (reduzido de “Network Mapper”). No primeiro artigo “Mapeamento de Redes com Nmap”[1], foram discutidas as funcionalidades mais comuns da ferramenta, abrangendo suas principais técnicas de descoberta de hosts, de varredura de portas, de detecção de versões de serviços e de identificação de sistema operacional. Neste artigo, o foco é no Nmap Scripting Engine (NSE), uma funcionalidade poderosa e flexível do Nmap, que permite a execução de scripts a fim de automatizar tarefas variadas.

O NSE é distribuído com o Nmap, junto com um conjunto de scripts maior a cada nova versão, e pode ser obtido através do site oficial [2]. Informações adicionais às apresentadas neste artigo podem  ser encontradas na documentação oficial do Nmap [3] e do NSE [4], no Portal NSEDoc de Referência do NSE [5] ou no livro de autoria do próprio Fyodor dedicado à ferramenta [6], que inclusive tem uma versão traduzida em português (pt-BR) [7]. Parte deste livro está disponível gratuitamente na Internet para leitura e consulta [8]. Vale mencionar que o capítulo do livro referente ao NSE faz parte do conteúdo disponibilizado.

Nos exemplos de alvo apresentados neste artigo, são utilizados apenas faixas de endereços IP privados definidos na RFC 1918 [9], a saber 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16, e o endereço scanme.nmap.org, que é um host preparado pelos próprios desenvolvedores da ferramenta para receber este tipo de varredura. Os leitores são encorajados a não executar varreduras sobre qualquer ativo que não seja de sua propriedade ou que se tenha autorização formal para isso.

Cursos Relacionados:

Sobre o Nmap Scripting Engine

Como descrito anteriormente, o NSE é uma funcionalidade do Nmap poderosa, versátil e flexível, que permite a seus usuários desenvolver e compartilhar scripts simples e integrá-los às varreduras tradicionais do Nmap, a fim de automatizar tarefas variadas. Os usuários podem somente utilizar os scripts disponibilizados junto com o Nmap, modificar scripts existentes ou ainda desenvolver seus próprios scripts personalizados que atendam suas necessidades.

O NSE foi desenvolvido inicialmente com o objetivo de melhorar a descoberta de rede, incluir métodos mais sofisticados de detecção de versões e permitir a identificação de vulnerabilidades. Em sua versão atual, além destas funções, o NSE é capaz de detectar backdoors, explorar vulnerabilidades, realizar ataques de dicionário e de negação de serviço, detectar malwares remotamente, entre outros. Por se tratar de uma ferramenta tão versátil, é possível que surjam ainda scripts aplicáveis em novas situações não previstas pelos desenvolvedores e mantenedores do Nmap.

Os scripts executados pelo NSE são escritos na linguagem de script Lua [10]. A linguagem Lua foi Criada em 1993 no Laboratório de Tecnologia em Computação Gráfica da Pontifícia Universidade Católica do Rio de Janeiro (TecGraf/PUC-Rio) [11] e continua em desenvolvimento ativo ainda hoje. Lua é uma linguagem extensível, segura e portável, muito usada e já bastante depurada, além disto é considerada uma linguagem fácil de aprender (principalmente se já se conhece outras linguagens de script como perl, python ou outras linguagens como C/C++, Java, etc) e pequena para embutir (segundo a documentação da linguagem, uma distribuição completa, com código fonte, manual e binários para algumas plataformas cabem confortavelmente em um disquete). Atualmente, Lua é bastante usada no desenvolvimento de jogo, figurando em títulos como “World of Warcraft” e “Crysis”, e, mais recentemente, em ferramentas de segurança, como o Nmap, naturalmente, o Wireshark e o Snort 3.0.

O manual de referência oficial da linguagem Lua são os livros “Programming in Lua”, no momento da redação deste artigo, na segunda edição [12], e “Lua 5.1 Reference Manual” [13]. A primeira edição do livro “Programming in Lua” está disponível gratuitamente na Internet [14], bem como a edição atual do “Lua 5.1 Reference Manual” [15], que inclusive tem uma versão em português [16].

É importante frisar que não é necessário nenhum conhecimento de programação para executar os scripts prontos, distribuídos com o Nmap. Entretanto, caso se deseje desenvolver ou modificar scripts, além das bibliotecas padrão do Lua, o Nmap fornece diversas outras prontas para tratar requisições de diversos protocolos, módulos para ataques de dicionário e manipulação de wordlists, suporte para tratar transações SSL, entre muitas outras facilidades. Estas facilidades auxiliam os desenvolvedores, de forma que, mesmo que este se considere um programador mediano, seja possível desenvolver scripts para o NSE.

Outro adendo importante é que os scripts executados pelo NSE não são isolados em sandboxes de nenhuma espécie. Então evite utilizar scripts cuja procedência não pode ser atestada. Ainda assim, caso se queira executar scripts desenvolvidos pela comunidade, sem a auditoria da equipe do Nmap, audite-o você mesmo, pois este script pode, potencialmente, executar código arbitrário em seu sistema operacional.

Em 2010, o próprio Fyodor, juntamente com o desenvolvedor de scripts David Fifield, apresentaram palestras no DEFCON 18 e no BlackHat 10 sobre o NSE. Os vídeos destas palestras se encontram disponíveis na página oficial do Nmap [17]. Estas palestras tiveram como título “Mastering the Nmap Scripting Engine” e mostraram uma introdução ao uso do NSE e ao desenvolvimento de scripts e também estudos de caso onde ao NSE foi utilizado.

“Quickstart”

A forma mais simplista de executar uma varredura utilizando o Nmap e o NSE é executar a ferramenta somente com o parâmetros referente ao NSE, a saber “-sC”, sobre o alvo especificado. Esta varredura utiliza as opções padrão tanto para a descoberta de hosts quanto para a varredura de portas.

• nmap -sC scanme.nmap.org

Esta varredura verifica se o alvo está ativo na rede utilizando o método de descoberta padrão, faz a varredura de portas utilizando o método de varredura padrão e executa os scripts classificados na categoria padrão. O resultado esperado de uma varredura como esta é:

1. Verificação de atividade do alvo na rede;
2. Listagem de portas abertas, fechadas e filtradas associadas ao nome do serviço que tradicionalmente utiliza cada porta, caso o alvo esteja ativo; e
3. Saídas dos scripts que tiveram suas condições de execução satisfeitas e, por isto, foram executados pelo NSE.

Isto quer dizer que se um determinado serviço estiver sendo provido em uma porta diferente da que tradicionalmente é utilizada, o nmap fornecerá uma resposta incorreta sobre o serviço. Isto quer dizer que, por exemplo, se um servidor ssh, que tradicionalmente utiliza a porta 22, for configurado para prover o serviço na porta 80, tradicionalmente utilizada por servidores http, nesta varredura o nmap detectará um servidor http e não um ssh, como esperado. Para resolver este problema, é necessário incluir na varredura a detecção de versões de serviços.

Na seção, “Classificação dos Scripts” é discutido do que consiste a categoria padrão e quais são as categorias de scripts e como eles são classificados nas mesmas. As questões referentes ao método de descoberta de hosts, de varredura de portas e de detecção de versões de serviços foram tratadas no primeiro artigo da série, “Mapeamento de Redes com Nmap” [1].

Classificação dos Scripts

Os scripts disponibilizados pelo NSE são classificados quanto às categorias e ao tipo. As categorias dizem respeito à natureza da funcionalidade desempenhada e os tipos, à fase da varredura em que devem ser executados, isto é, as categorias classificam os scripts pelo que eles fazem e os tipo, pelo momento em que o mesmo são executados durante uma varredura. Vale frisar que um scripts pode ser classificado em mais de uma categoria e mais de um tipo, inclusive operando de maneira distinta nos diferentes momentos de execução. A listagem abaixo descreve cada categoria especificada no Portal NSEDoc de Referência do NSE [5].

• auth: relacionados a mecanismos de autenticação e credenciais de acesso;
• broadcast: fazem descoberta de hosts não listados como alvos através do envio de pacotes broadcast;
• brute: visam descobrir credenciais de acesso através de ataques de dicionário;
• default: é a categoria padrão, em que os scripts devem fornecer respostas rápidas, concisas e confiáveis, além de serem pouco intrusivos, de fornecerem informações úteis para a maior parte dos usuários e de não estressarem o alvo a ponto de ser detectado por seus administradores como um ataque;
• discovery: visam descobrir ativamente mais informações sobre o alvo;
• dos: tentam causar indisponibilidade do alvo, ao provocar erros no lado do servidor;
• exploit: exploram uma dada vulnerabilidade conhecida;
• external: fazem consultas legítimas a recursos de terceiros, não listados como alvos;
• fuzzer: enviam pacotes contendo aleatórios ou inesperados pela aplicação servidor visando descobrir bugs e vulnerabilidades;
• intrusive: representam considerável risco de provocar erros no lado do servidor, utilizar uma quantidade significativa de recursos ou estressar o alvo a ponto de ser detectado por seus administradores como um ataque;
• malware: detectam remotamente se o alvo está infectado com um dado malware;
• safe: representam pouco risco e não devem causar erros no lado do servidor, utilizar muitos recursos ou explorar brechas de segurança;
• version: extendem a funcionalidade de detecção de versão do Nmap; e
• vuln: verificam se há uma dada vulnerabilidade conhecida no alvo.

O NSE somente seleciona um script para execução sobre o alvo da varredura, caso certas condições pré-determinadas sejam atendidas. Estas condições são especificadas por regras que estão vinculadas ao tipo de script. A listagem abaixo descreve cada uma destas regras que definem os tipos de script, conforme especificado na documentação oficial do Nmap Scripting Engine [5].

• prerule: são executados apenas uma vez, antes de todas as fases de varredura do Nmap, quando ainda não há informações a respeito dos alvos, e realizam tarefas que não dependem da especificação de alvos, como o envio de pacotes broadcast, por exemplo;
• hostrule: são executados durante as fases de varredura do Nmap e são invocados apenas uma vez para cada um dos alvos especificados que forem detectados como ativos;
• portrule: são executados durante as fases de varredura do Nmap e são invocados uma vez para cada instância detectada de um dado serviço encontrado em alvos detectados como ativos; e
• postrule: são executados apenas uma vez, depois de todas as fases de varredura do Nmap e da execução de todos os outros scripts do NSE e são usados, principalmente, para formatar a saída do Nmap segundo uma regra pré-definida.

O que define se o script será executado é o tipo da regra e o conteúdo da regra em si. A regra é definida pelo desenvolvedor do script e pode estipular casos em que o script não deve ser executado, como a ausência da definição de determinados parâmetros, nível de privilégios do usuário que executou a varredura, até o resultado de outros scripts.

Dependências de Scripts

O NSE oferece também um esquema de dependências de scripts que é utilizando para estabelecer a ordem em que os scripts serão executados. Este esquema é útil em situações em que um script pode se beneficiar em utilizar a saída de um outro script. Entretanto, apesar do que o nome sugere, caso a dependência de um script não seja executada, este script poderá ser executado mesmo assim.

Um exemplo claro do funcionamento deste esquema são os scripts da categoria “brute”. Muitos scripts têm como dependência scripts da categoria brute, pois, se alguma credencial for obtida por um scripts desta categoria, esta credencial certamente será útil para outros scripts. Assim, ao relacioná-lo como dependência, fica garantido que o script de dependência será executado antes e a sua saída será repassada, melhorando ainda mais os resultados obtidos na execução do segundo script.

Sintaxe de Uso do Nmap Scripting Engine

Existem diversas maneiras distintas de executar o NSE. Duas delas, “-sC” e “-A”, executam somente os scripts da categoria padrão, que agora sabemos que se chama “default”. A opção “-A” representa a varredura agressiva do Nmap e equivale às opções “-sC -sV -O –traceroute”. Neste caso, o NSE também executa a categoria de scripts padrão e o Nmap ativa também a detecção de versões de serviços e a identificação de sistema operacional, que foram tratadas no primeiro artigo da série, “Mapeamento de Redes com Nmap” [1], e também a opção que traça a rota de transmissão dos pacotes.

Além destas, o NSE também pode ser executado a partir da opção “–script”, sendo esta a opção que pode ser configurada para executar scripts de outras categorias além da padrão. Esta opção é usada obedecendo a seguinte sintaxe:

• –script script|categoria|diretório|expressão|all[,script|categoria|diretório|expressão]

Se a opção “–script” for usada com a categoria “default”, o NSE se comporta da mesma maneira que com as opções “-sC” e “-A”. Assim, os comandos abaixo são equivalentes e o NSE executa somente os scripts da categoria padrão:

• nmap -A scanme.nmap.org
• nmap -sC -sV -O –traceroute scanme.nmap.org
• nmap –script “default” -sV -O –traceroute scanme.nmap.org

A opção “–script” pode ser usada com nomes de scripts completos, nomes de categorias, nomes de diretórios, expressões ou a string “all”. O NSE busca por scripts identificados pela extensão “.nse”, que atendam as condições passadas no subdiretório “scripts” dos seguintes diretórios: o parâmetro da opção “–datadir”, o conteúdo das variáveis “$NMAPDIR” e “NMAPDATADIR”, aquele que contém o binário do nmap, aquele que contém o binário do nmap seguido de “../share/nmap”, “~/.nmap” e o atual.

Quando o NSE é executado com nomes de scripts completos, seguido ou não da extensão “.nse”, o NSE busca por script com o nome de arquivo passado e o executa se suas condições execução forem safisteitas. Seguem abaixo exemplos de varreduras que chamam um único script:

• nmap –script “http-methods” scanme.nmap.org
• nmap –script “dhcp-discovery,dns-zone-transfer,whois” scanme.nmap.org

Quando o NSE é executado com nomes de categorias, o NSE busca todos os scripts pertencentes àquela categoria e os executa se suas condições execução forem safisteitas. Seguem abaixo exemplos de varreduras que chamam categorias:

• nmap –script “default” scanme.nmap.org
• nmap –script “auth,discovery,safe” 10.0.0.0/24

Quando o NSE é executado com nomes de diretórios, o NSE busca todos os scripts armazenados no diretório referido e os executa se suas condições execução forem safisteitas. Seguem abaixo exemplos de varreduras que chamam scripts armazenados em um diretório:

• nmap –script “./custom_scripts” 172.16.0.0/28
• nmap –script “/tmp/scripts,/usr/share/nmap/scripts” 10.0.0.0/24

Quando o NSE é executado com a string “all”, o NSE executa todos os scripts que encontrar se suas condições execução forem safisteitas. Segue abaixo um exemplo de varredura que chama todos os scripts:

• nmap –script “all” 10.0.0.1

Quando o NSE é executado com uma expressão, o NSE busca todos os scripts referenciados pela expressão e os executa se suas condições execução forem safisteitas. Expressões podem conter caracteres coringas (“wildcards”) no estilo de scripts bash, parênteses que definem escopos e os operadores lógicos “and”, “or” e “not”.

• nmap –script “http-* and ssh-* and not intrusive” scanme.nmap.org
• nmap –script “intrusive and (brute or dos or exploit) and not (default or safe)” 178.16.0.1

Passando Parâmetros para Scripts

É possível passar argumentos para os scripts executados com o NSE através da opção “–script-args”. Os argumentos são passados em uma lista separada por vírgulas no formato “chave=valor”. A listagem de argumentos aceitos por cada script pode ser acessada diretamente na documentação de cada script no Portal NSEDoc de Referência do NSE [5].

Os argumentos pode afetar a apenas um ou todos os scripts executados. Quando um argumento deve afetar apenas um script, este deve ser passado usando a sintaxe “nome_script.chave=valor” ou, para passar mais de um argumento “nome_script={ chave1=valor1,chave2=valor2}”. Quando o argumento deve afetar todos os scripts executados, basta passar “chave=valor” que todos os scripts que aceitam o argumento “chave” o utilizarão. Seguem abaixo exemplos de varredura utilizando o NSE com passagem de parâmetros:

• nmap –script ‘brute’ –script-args ‘user=”foo”,pass=”bar”‘ 10.0.0.0/24
• nmap –script ‘safe’ –script-args ‘domain=”alvo.com”, smtp.domain= “alvomail.com”‘ 192.168.0.1
• nmap –script ‘brute’ –script-args ‘smtp-brute={userdb=user2.txt,passdb=pass2.txt}, userdb=user1.txt,passdb=pass1.txt’ 172.16.0.1

Também é possível passar parâmetros em um arquivo texto através da opção “–script-args-file”. Para utilizar esta opção, os parâmetros devem ser escritos da mesma forma que seriam na modalidade passada na linha de comando e estar separados por vírgulas ou quebras de linha.

Conclusão

O Nmap Scripting Engine é uma funcionalidade do Nmap que inclui à varredura tradicional do Nmap diversas funcionalidades que permitem interrogar hosts na rede de maneira mais flexível e versátil. Este artigo discutiu as funcionalidades principais oferecidas pelo NSE, no entanto ainda há muitas outras funcionalidades do Nmap que não foram, se quer, mencionadas, como: opções de controle de desempenho, opções de evasão de firewalls/IDS/IPS, opções de spoofing, e muitas outras. O leitor é encorajado a buscar mais informações na documentação oficial do Nmap [3] e do NSE [4,5], no livro oficial [6,7,8] e outras fontes, como os webinars “NMAP – Software Livre para Exploração de Rede e Auditorias de Segurança”[18] e “Teste de Invasão com o Nmap Scripting Engine”[19], da Clavis.

Vale mencionar que, apesar de não haver legislação especifica que tipifique como crime o ato de executar varreduras de qualquer tipo em redes de qualquer espécie, o objetivo deste artigo não é incentivar os leitores a fazer varreduras aleatórias em redes que não são de sua propriedade ou que não se tenha autorização para fazê-lo, mas informar quanto a que tipo de informação relevante pode ser extraída destas varreduras e como estas podem ajudar em auditorias teste de invasão, depuração de firewalls ou administração de servidores, etc.

Referências

[1] Mapeamento de Redes com Nmap – Ferramenta de código aberto com diversas funcionalidades, http://www.blog.clavis.com.br/materia-sobre-mapeamento-de-redes-com-nmap-na-revista-seguranca-digital/

[2] Nmap – Free Security Scanner For Network Exploration & Security Audits, http://nmap.org/

[3] Nmap Official Documentation, http://nmap.org/docs.html

[4] Nmap Scripting Engine (NSE) Documentation, http://nmap.org/book/man-nse.html

[5] NSEDoc Reference Portal, http://nmap.org/nsedoc/

[6] Nmap Network Scanning. Gordon “Fyodor” Lyon, Insecure.com LCC Publishings. ISBN: 978-0979958717

[7] Exame de Redes com NMAP. Gordon “Fyodor” Lyon, Editora Ciência Moderna. ISBN: 978-8573938654

[8] Nmap Network Scanning, Gordon “Fyodor” Lyon, http://nmap.org/book/toc.html

[9] RFC 1918 – Address Allocation for Private Internets: http://tools.ietf.org/html/rfc1918

[10] The Programming Language Lua, http://www.lua.org/

[11] Laboratório de Tecnologia em Computação Gráfica – Pontifícia Universidade Católica do Rio de Janeiro, http://www.tecgraf.puc-rio.br/

[12] Programming in Lua, Second Edition. Roberto Ierusalimschy. Lua.org Publishing. ISBN: 978-8590379829

[13] Lua 5.1 Reference Manual. Roberto Ierusalimschy, Luiz Henrique de Figueiredo e Waldemar Celes, Lua.org Publishing. ISBN: 978-8590379836

[14] Programming in Lua, First Edition. Roberto Ierusalimschy, http://www.lua.org/pil/

[15] Lua 5.1 Reference Manual. Roberto Ierusalimschy, Luiz Henrique de Figueiredo e Waldemar Celes, http://www.lua.org/manual/5.1/

[16] Manual de Referência de Lua 5.1. Roberto Ierusalimschy, Luiz Henrique de Figueiredo e Waldemar Celes, http://www.lua.org/manual/5.1/pt/

[17] Mastering the Nmap Scripting Engine. Gordon “Fyodor” Lyon e David Fifield, DEFCON 18 e BlackHat 10, http://nmap.org/presentations/BHDC10/

[18] Webinar #4 – NMAP – Software Livre para Exploração de Rede e Auditorias de Segurança, http://www.blog.clavis.com.br/webinar-4-software-livre-para-exploracao-de-rede-e-auditorias-de-seguranca/

[19] Webinar #14 – Teste de Invasão com o Nmap Scripting Engine, http://www.blog.clavis.com.br/webinar-14-teste-de-invasao-com-o-nmap-scripting-engine/

Cursos Relacionados:

Auditorias do tipo Teste de Invasão (pentests, do inglês Penetration Tests) têm sido cada vez mais demandadas por empresas que buscam atender a normas internacionais e  proteger sua infraestrutura e aplicações web. No artigo Case de Sucesso Clavis e Artigo sobre a Importância das Auditorias Teste de Invasão é apresentado um caso de sucesso na utilização desse tipo de auditoria, explicando o seu funcionamento, suas vantagens e características. Já o artigo Auditoria Teste de Invasão(Pentest) – Planejamento, Preparação e Execução descreve as etapas de um pentest e as diversas metodologias para este tipo de auditoria.

O Webinar #5, “Auditorias Teste de Invasão para Proteção de Redes Corporativas”, da Academia Clavis Segurança da Informação, apresenta o funcionamento prático de um teste de invasão, expondo algumas ferramentas utilizadas:

Uma importante etapa do pentest é a obtenção de informações: nela efetua-se o mapeamento da rede ser analisada. Há um artigo da Clavis sobre mapeamento utilizando a ferramenta de código aberto Nmap. O Webinar #14 – “Teste de Invasão com o Nmap Scripting Engine” também apresenta detalhes sobre o uso do Nmap e seu Scripting Engine (NSE). O NSE é um engine do Nmap que possui como funcionalidades: detecção de vulnerabilidades, varredura de aplicações web, execução ataques de força bruta, busca proxies abertos, entre outras. Assista-o a seguir:

Muitos administradores de redes sem fio utilizam o protocolo WEP acreditando que o uso de criptografia garante algum nível de segurança. A sexta palestra da Clavis  ( Webinar #6 – Teste de Invasão a Redes Sem Fio – Protocolo WEP ) apresenta as vulnerabilidades deste protocolo e as opções seguras a serem escolhidas.

• Artigos
• Webinars

Bons estudos! =)

E que tal aproveitar para conhecer a Formação de 100 horas – Auditor em Teste de Invasão (pentest) da Academia Clavis Segurança da Informação?

Depois de mais de 5 meses foi lançada a nova versão do Nmap (6.25)! \o/

O lançamento traz consigo 85 novos scripts para o NSE, sigla para Nmap Script Engine . Recentemente a Academia Clavis Segurança da Informação apresentou o Webinar #14 – “Teste de Invasão com o Nmap Scripting Engine”. Tal webinar apresenta justamente o NSE e sua relação com o Nmap e com suas varreduras tradicionais no contexto de Auditorias Teste de Invasão.

Além do webinar o Blog Clavis apresentou hoje um artigo sobre as funcionalidades do NSE, artigo com com o título “Utilizando o Nmap Scripting Engine (NSE) – Funcionalidade do Nmap que permite executar scripts do usuário“.

Assim como os novos scripts para o NSE, a atualização apresenta melhorias em sua performance como um suporte ao traceroute para IPv6, melhoras no Windows 8, dentre outras.

Como o Nmap é uma ferramenta com muitas funcionalidades o Blog Clavis publicou um artigo que discute suas funcionalidades principais incluindo: técnicas de descoberta de hosts, de varredura de portas, de detecção de versão de serviços e de identificação remota de sistemas operacionais (OS fingerprinting). O texto foi publicado também na Revista Segurança Digital e pode ser lido através do artigo com o tema “Mapeamento de Redes com nmap – ferramenta de código aberto com diversas funcionalidades“.

Outro webinar apresentado pela Academia Clavis é o Webinar #4 – NMAP – Software Livre para Exploração de Rede e Auditorias de Segurança, que aborda o funcionamento do Nmap. Assista-o a seguir:

Mais informações sobre a atualização da ferramenta no link.

Confira o artigo dos colunistas do SegInfo Rafael Ferreira (@rafaelsferreira), Bruno Salgado (@salgado_bruno) e dos analistas da Clavis Henrique Soares (@hrssoares) e Jarcy Azevedo (@jarcyjr) que saiu na última edição da Revista Segurança Digital:

Introdução

O nmap (reduzido de “Network Mapper”) é uma ferramenta livre, de código aberto, utilizada para ma­peamento de redes e inclui diversas funcionalidades como: varredura de portas, detecção de versão de ser­viços, identificação remota de sistemas operacionais (OS fingerprinting), etc. Esta ferramenta foi criada por Gordon “Fyodor” Lyon, que ainda hoje participa ativamente do desenvolvimento da mesma. O nmap é uma ferramenta versátil que é muito utilizada, entre outros, em auditorias teste de invasão, teste em firewalls e testes de conformidade.

O nmap, em geral, opera nas camadas de rede e transporte. Entretanto, também é capaz de manipular dados da camada de enlace (endereças MAC e requi­sições ARP, por exemplo) e de interpretar dados da camada de aplicação para inferir informações interes­santes a respeito de seu alvo (versões de serviços e sistemas operacionais, por exemplo).

A versão mais nova do nmap por ser obtida atra­vés do site oficial. Informações adicionais às apresentadas neste artigo podem ser encontradas na documentação oficial ou no livro de autoria do próprio Fyodor dedicado à ferramenta (Nmap Network Scanning, Gordon “Fyodor” Lyon, Insecure.com LCC Publishings. ISBN: 978­0979958717), que inclu­sive tem uma versão traduzida em português brasileiro (Exame de Redes com NMAP, Gordon “Fyodor” Lyon, Editora Ciência Moderna. ISBN: 978­8573938654). Parte deste livro está disponível gratuitamente na Internet para leitura e consulta.

Nos exemplos de alvo apresentados neste artigo, são utilizados apenas faixas de endereços IP privados definidos na RFC 1918, a saber 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16, e o endereço scanme.nmap.org, que é um host preparado pelos próprios desenvolvedores da ferramenta para receber este tipo de varredura. Os leitores são encorajados a não executar varreduras sobre qualquer ativo que não seja de sua propriedade ou que se tenha autorização formal para isso.

Cursos Relacionados:

Especificação de Alvos

Antes de iniciar uma varredura, seja esta muito simples ou extremamente complexa, é preciso dizer ao nmap quais são os alvos desta varredura. O nmap define como alvos válidos endereços IP, faixas de endereços IP ou nomes de domínio dispostos em lista e separados por caracteres de espaçamento (espaço, tab, nova linha, etc). Estes alvos podem ser passados como parâmetro na linha de comando ou em um ar­quivo (pela opção -iL arquivo_alvos.txt).

Assim, quando o alvo é um endereço IP único, es­te deve ser especificado como quatro números intei­ros positivos, entre 0 e 255, separados por pontos. São exemplos de endereços IP únicos: 172.28.1.101 192.168.0.1. Quando o alvo é uma faixa de endere­ços IP, este deve ser especificado com duas sintaxes distintas. A primeira delas consiste do par endereço da rede e sua máscara de sub­rede. São exemplos de pares endereço da rede e máscara de sub­rede: 10.20.0.0/16 172.16.1.32/27. A outra sintaxe aceita consiste de um endereço IP com listas de números se­parados por vírgulas ou intervalos especificados com hífen. São exemplos de endereço IP com listas de nú­meros ou intervalos: 10.0.0.0­-255 172.16.1,3,5,0-­127 (equivalente a 172.16.1.0-­127 172.16.3.0­-127 172.16.5.0-127). Finalmente, quando o alvo é um no­me de domínio, este deve ser especificado por sequências de caracteres quaisquer separadas por vír­gulas. São exemplos de nomes de domínio: scanme.nmap.org e www.seginfo.com.br.

“Quickstart”

A forma mais simplista de executar a varredura utilizando o nmap é executar a ferramenta sem parâ­metros sobre o alvo especificado. Esta varredura con­siste de todas as opções padrão tanto de descoberta quanto de varredura.

nmap scanme.nmap.org

Esta varredura verifica se o alvo está ativos na re­de utilizando o método de descoberta e faz a varredu­ra utilizando o método de varredura padrão. O resultado esperado de uma varredura como esta é:

1. Verificação de atividade do alvo na rede; e
2. Listagem de portas abertas, fechadas e filtradas associadas ao nome do serviço que tradicionalmente utiliza cada porta, caso o alvo esteja ativo.

Isto quer dizer que se um determinado serviço es­tiver sendo provido em uma porta diferente da que tradicionalmente é utilizada, o nmap fornecerá uma resposta incorreta sobre o serviço. Isto quer dizer que, por exemplo, se um servidor ssh, que tradicionalmente utiliza a porta 22, for configurado para pro­ver o serviço na porta 80, tradicionalmente utilizada por servidores http, nesta varredura o nmap detectará um servidor http e não um ssh, como esperado.

Nas próximas seções, “Descoberta de hosts” e “Técnicas de Varredura de portas” respectivamente, é discutido do que consistem estes método de desco­berta e de varredura padrão.

Descoberta de Hosts

Frequentemente, o primeiro passo de uma auditoria de segurança ou projeto de mapeamento de rede é reduzir uma grande faixa de endereços IP a uma lista de endereços de interesse. Este interesse pode variar dependendo do propósito da varredura. Em uma au­ditoria teste de invasão caixa preta, o auditor se inte­ressa por qualquer host que esteja ativo na rede, enquanto em um auditoria em aplicações web, o au­ditor se interessa somente nos hosts que provejam serviços web. Assim, para cada propósito distinto há uma forma diferente realizar a descoberta de hosts.

O nmap fornece diversas opções a fim de perso­ nalizar a descoberta de hosts para que esta se adeque aos propósitos da varredura. Estas opções serão dis­cutidas a seguir.

Primeiramente, pode ser interessante não fazer a descoberta de hosts. Isto ocorre quando a varredura compreende um único endereço alvo, ou quando já se sabe que os alvos estão ativos na rede. Para estes ca­sos, podem ser utilizadas as opções “List scan” (­-sL) ou “No Ping” (­-PN) como exemplificadas nos exemplos abaixo:

nmap -sL 10.0.0.0/24
nmap -PN 10.0.0.0/24

O “List scan” diz ao nmap que a varredura con­siste apenas em listar os alvos passados como parâ­metro, embora o nmap ainda faça uma consulta DNS (reversa, no caso de alvos especificados como ende­reços IP) sobre os alvos. Portanto no caso do “List scan” nenhuma varredura ativa é realizada sobre os alvos especificados. No caso do “No Ping”, o nmap pula a faze de descoberta completamente. Versões mais antigas do nmap apontarão a opção “P0” para o “No Ping”, mas esta opção é considerada obsoleta, apesar de ainda funcionar nas versões atuais do nmap, e, a título de curiosidade, esta opção foi modi­ficada por ser frequentemente confundida com o “IP Protocol Ping” (­-PO). No exemplo dado acima, o nmap ainda faria a varredura utilizando o método de varredura padrão sobre os alvos especificados. A única situação em que o nmap não se comportaria desta forma acontece quando os alvos especificados estão na mesma rede que o host que faz a varredura. Neste caso, o nmap faria um “ARP Ping”, ignorando a opção do “No Ping”.

Uma vez que se queira fazer uma descoberta de hosts, esta deve ser ativada com a opção “-sP”. Quando esta opção esta ativada, o nmap não realiza varreduras, mas apenas realiza a descoberta de hosts, se não houverem outras opções comandando que a varredura seja feita. Neste caso, o nmap utiliza o mé­todo de descoberta de hosts padrão, que é o “ARP Ping” (-PR) para alvos localizados na rede interna e o “ICMP Echo Ping” (-PE) para os demais.

O “ARP Ping” (-PR) é sempre o método de desco­berta de hosts escolhido pelo nmap quando o alvo en­contra­-se na mesma rede que o host de onde a ferramenta é executada. Mesmo que outro método de descoberta de host seja explicitamente especificado o nmap irá realizar o “ARP Ping” sobre endereços da rede interna. Para forçar o nmap a utilizar outro mé­todo de descoberta de hosts sobre endereços na rede interna é necessário utilizar a opção adicional “­--send-ip”. Outro adendo importante é que esta opção não funciona nos sistemas da família Microsoft Win­dows, pois os mesmo não oferecem suporte a sockets brutos (não vinculados a protocolos). Assim, consi­derando que a faixa de endereços IP 192.168.1.0/16 seja a rede interna, os comandos abaixo são equiva­lentes:

nmap -sP 192.168.1.0/16
nmap -sP -PR 192.168.1.0/16

O “ICMP Echo Ping” (-PE) é o método de desco­berta padrão para endereços que não estão localiza­dos na mesma rede que o host de onde a ferramenta é executada. Este método faz parte da família de méto­dos “ICMP Ping”, que ainda inclui os métodos “ICMP Timestamp Ping” (-PP) e “ICMP Address Mask Ping” (-­PM). Todos estes métodos funcionam de maneira semelhante, pois detectam a atividade em um host pelo envio de pacotes ICMP de diferentes ti­pos. Assim como os comandos abaixo também são equivalentes para a rede externa:

nmap -sP scanme.nmap.org
nmap -sP -PE scanme.nmap.org

Outros métodos de descoberta de hosts interessan­te são o “TCP SYN Ping” (-PS lista_de_portas) e o “UDP Ping” (-PU lista_de_portas). Estes métodos são úteis, pois alguns hosts podem não respondem re­quisições ICMP, seja por restrições no firewall ou do próprio sistema operacional. Assim, estes métodos de descoberta enviam pacotes TCP ou UDP a uma porta que pode estar aberta ou fechada. Se a porta estiver aberta, o host certamente irá responder, denunciando a atividade do host. No entanto, se a porta estiver filtrada, nenhuma resposta será enviada (bloqueada pe­lo mesmo firewall que impediu descoberta via ICMP). Assim, a desvantagem destes métodos, além de serem mais lentos que o “ARP Ping” e o “ICMP Ping”, está na escolha das portas utilizadas, pois se todas as portas escolhidas estiverem filtradas, não será possível detectá­-lo, ainda que o host esteja ativo. São exemplos de descobertas de host por “TCP SYN Ping” e “UDP Ping”:

nmap -sP -PS22,80,443 scanme.nmap.org
nmap -sP -PU53,631 scanme.nmap.org

Varredura de Portas

Esta seção trata da principal funcionalidade do nmap, a varredura de portas. Mesmo quando estava em suas primeiras versões, o nmap sempre foi capaz de fazer a varredura de portas de forma rápida e efi­ciente. O nmap fornece diversos métodos para reali­zar varreduras de portas e a escolha de qual método utilizar depende do objetivo que se pretende atingir. Varreduras de portas podem ter por objetivo detectar serviços providos por um host alvo, verificar se um firewall está filtrando requisições de forma adequada ou ainda confirmar se a pilha TCP foi implementada conforme especificado na RFC 793. É importante frisar que embora hajam diversos métodos de varre­dura de portas disponíveis, só é possível utilizar um por vez. Outro adendo importante é que a maioria dos métodos de varredura de portas exige altos privi­légios de usuário. Isto é necessário, pois algums pa­cotes são veiculados por sockets brutos (não vinculados a protocolos) que exigem este tipo de pri­vilégios.

Outra parte importante na varredura de portas é a listagem de portas (-p). A listagem de portas a serem consideradas separadas por vírgulas e, assim como as faixas de endereços IP, é possível especificar faixas de portas utilizando um hífen. As podem ser associa­das a um protocolo manualmente ou automaticamen­te pelo nmap dependendo do contexto da varredura. Quando os protocolos são especificados manualmen­te, a listagem de portas é sempre precedida por uma letra que identifica o protocolo utilizado (‘T’ para TCP e ‘U’ para UDP) e quando são especificados au­tomaticamente, basta informar a listagem de portas. Também é possível se utilizar todas as portas através da opção “-p­” ou limitar por uma determinada quan­tidade de porta mais utilizadas através da opção “--top-ports qtd_portas” e se esta quantidade for 100 é possível utilizar o “Fast Scan” (-F), que é equivalente a “--top-ports 100”. Assim, são exemplos de listagem de portas: -p22­25,80,443; -pT:22,80,U:53,631.

A varredura de portas sempre é feita para cada execução do nmap, exceto para o caso do “Ping Scan” (-sP), quando é necessário escolher um método de varredura de portas para que esta seja executada. Quando nenhum método de varredura de portas é ex­plicitamente especificado, o nmap executa o “TCP SYN Scan”, caso tenha sido executado por um usuá­rio com privilégio de criar sockets brutos (não vincu­lados a protocolos), e o “TCP Connect Scan”, caso contrário.

O “TCP SYN Scan” (-sS) é considerado pelos de­senvolvedores da ferramenta como o método de var­redura de portas mais popular. Esta varredura consiste em enviar pacotes TCP com a flag SYN ati­vada para as portas alvo. Esta flag é ativada para se iniciar uma nova conexão TCP entre os hosts, no en­tanto o nmap não completa o processo de abertura da conexão (“Three­Way Handshake”, explicado na se­ção 3.4 da RFC 793) e por isto é considerado um método bem furtivo e difícil de se detectar. Nesta varredura, uma porta é considerada aberta se a res­posta recebida for um pacote com as flags SYN e ACK ativadas. Se a resposta for um pacote com a flag RST ativada a porta é classificada como fechada e se nenhuma resposta for recebida, a porta é classifi­cada como filtrada. Assim, considerando que a faixa de endereços IP 192.168.1.0/16 seja a rede interna, os comandos abaixo são equivalentes (considerando que um usuário privilegiado esta executando as varredu­ras):

nmap 192.168.1.0/16
nmap -sP -sS 192.168.1.0/16
nmap -sP -PR -sS 192.168.1.0/16

De forma semelhante, os comandos abaixo também são equivalentes para a rede externa:

nmap scanme.nmap.org
nmap -sP -sS scanme.nmap.org
nmap -sP -PE -sS scanme.nmap.org

O “TCP Connect Scan” (-sT) funciona de forma muito semelhante ao “TCP SYN Scan”. Esta varredura consiste em tentar criar conexões entre os hosts na porta alvo. Isto é feito através da execução completa do Aperto de Mão em Três Vias (“Three-Way Handshake”, explicado na seção 3.4 da RFC 793) executado pela chamada de sistema “connect()”. Este método de varredura de portas é mais lento e menos furtivo que o “TCP SYN Scan”, pois a conexão é, de fato, estabelecida, no entanto, por usar a chamada de sistema, esta varredura pode ser executar por um usuário sem privilégios. Nesta varredura, uma porta é considerada aberta se a conexão for estabelecida com sucesso. Se a conexão for rejeitada a porta é classificada como fechada e se o tempo limite para estabelecer a conexão expirar, a porta é classificada como filtrada. Assim, considerando que a faixa de endereços IP 192.168.1.0/16 seja a rede interna, os comandos abaixo são equivalentes (considerando que um usuário sem privilégios esta executando as varre­duras):

nmap 192.168.1.0/16
nmap -sP -sT 192.168.1.0/16
nmap -sP -PR -sT 192.168.1.0/16

De forma semelhante, os comandos abaixo também são equivalentes para a rede externa:

nmap scanme.nmap.org
nmap -sP -sT scanme.nmap.org
nmap -sP -PE -sT scanme.nmap.org

Outros métodos de varredura de portas sobre o protocolo TCP interessante são o “TCP ACK Scan” (-sA), “TCP NULL Scan” (-sN), o “TCP FIN Scan” (-sF) e o “TCP Xmas Scan” (-sX). Estes métodos são úteis, pois permitem explorar falhas de configuração de um firewall stateless ou roteador que filtre pacotes, que estejam dificultando uma varredura direta. Estas varreduras enviam pacotes TCP com a flag ACK ativada para o “TCP ACK Scan”, com nenhuma flag ativada para “TCP NULL Scan”, com a flag FIN ativada para o “TCP FIN Scan” e, finalmente, as flags FIN, PSH e URG ativadas para o “TCP Xmas Scan”. Estas varreduras, em geral, são executadas para agregar informação a outras varreduras já executadas, visto que nem sempre oferecem resultados confiáveis. Isto acontece, pois nem todos os sistemas operacionais implementam sua pilha TCP em conformidade com a RFC 793 e respondem de maneiras inesperadas a requisições como as utilizadas para este tipo de varredura. Outro adendo importante é que as soluções mais modernas de IDS/IPS são capazes de detectar e bloquear este tipo de varredura, tornando-as ineficazes. São exemplos deste tipo de varredura:

nmap -PN -sN -p- 172.17.16.1
nmap -sX -p21­25,53,80,443 192.168.1.0/24
nmap -sP -PP -sA --­top-ports 512 scanme.nmap.org

Existem também métodos de varredura de portas sobre outros protocolos além do TCP. A varredura sobre o protocolo UDP é chamada “UDP Scan” (-sU). Esta é a única varredura que pode ser executada simultaneamente com outras. Diferentemente das outras varreduras, um pacote UDP vazio é enviado para a porta alvo. Uma porta é considerada aberta se um pacote UDP de qualquer espécie for recebido. Se um pacote “ICMP Port Unreachable” (ICMP tipo 3, código 3) for recebido, se um pacote “ICMP Destination Unreachable” (ICMP tipo 3, qualquer código) de qualquer código diferente de 3 for recebido, a porta é classificada como filtrada e se nenhuma resposta for recebida, a porta é classificada como aberta ou filtrada. Maiores informações sobre os protocolos UDP e ICMP e seus tipos e códigos podem ser encontradas nas RFC 768, 792 e Registro de Parâmetros do ICMP disponibilizado pela IANA, respectivamente. São exemplos deste tipo de varredura:

nmap -sP -sU -­F scanme.nmap.org

Há também a varredura sobre o protocolo SCTP, chamada “SCTP INIT Scan” (-sY). O SCTP é um protocolo que combina características tanto do TCP quanto do UDP e introduz novas funcionalidades como multi­homing e multi­streaming. Maiores informações sobre o SCTP podem ser encontradas nas RFC 3286 e 4960. Quanto a varredura SCTP, ela é muito similar à “TCP SYN Scan”, pois nunca completa a associação SCTP e é relativamente furtiva e pouco intrusiva. São exemplos deste tipo de varredura:

nmap -PN -sY -p- 172.17.16.1

Detecção de Serviço, Versão e Sistema Operacional

As vulnerabilidades publicadas em entidades especializadas, em geral, são eficazes somente sobre determinadas versões de uma dada aplicação. Assim, é interessante obter uma leitura mais específica sobre um serviço detectado do que somente a porta em que este está sendo executado, uma vez que estes serviços podem ser executados em, virtualmente, qualquer porta. Sendo assim, o nmap fornece uma opção para aferir o serviço e a versão do software provendo este serviço através da opção “-sV”. Esta opção tenta obter, através do envio de pacotes construídos com este propósito, descobrir qual serviço está sendo provido de fato e sua versão aproximada. Vale ressaltar que se o nmap for compilado com suporte a OpenSSL, a ferramenta tentará aferir serviço provido e sua versão aproximada mesmo com a camada extra de criptografia. Maiores informações sobre a detecção da versão de serviços e aplicações podem ser encontradas no capítulo 7 do livro do próprio autor da ferramenta, disponibilizado gratuitamente.

nmap -sP -sS -sV --top-ports 256 scanme.nmap.org

Assim como são publicadas vulnerabilidades para serviços providos em uma rede, o mesmo é acontece com sistemas operacionais, portanto também é importante detectar qual sistema é executado por uma alvo na rede. O nmap também fornece uma opção para aferir o sistema operacional e sua versão aproximada através da opção “-O”. Esta operação também é conhecida como “OS Fingerprinting”. Esta opção tenta obter, através do envio de pacotes construídos com este propósito, descobrir qual sistema operacional está sendo executado e sua versão aproximada. Maiores informações sobre a detecção remota do sistema operacional podem ser encontradas no capítulo 8 do livro do próprio autor da ferramenta, disponibilizado gratuitamente.

nmap -sP -sS -sV -O -p- scanme.nmap.org

Conclusão

O nmap é uma ferramenta que oferece uma gama de opções úteis e é de grande valia para obtenção de informação para diversas atividades, como auditorias de segurança em geral, mapeamento de redes inteiras, teste em firewalls, etc. Este artigo discutiu apenas as funcionalidades principais, no entanto ainda há muitas outras que não foram sequer mencionadas, como: o Nmap Scripting Engine (NSE), opções de controle de desempenho, opções de evasão de firewalls/IDS/IPS, opções de spoofing, e muitas outras. O leitor é encorajado a buscar mais informações na documentação oficial, no livro oficial e outras fontes, como o Webinar #4 da Clavis sobre “NMAP – Software Livre para Exploração de Rede e Auditorias de Segurança”.

Vale mencionar que, apesar de não haver legislação especifica que tipifique como crime o ato de executar varreduras de qualquer tipo em redes de qualquer espécie, o objetivo deste artigo não é incentivar os leitores a fazer varreduras aleatórias em redes que não são de sua propriedade ou que não se tenha autorização para fazê­lo, mas informar quanto a que tipo de informação relevante pode ser extraída destas varreduras e como estas podem ajudar em auditorias teste de invasão, depuração de firewalls ou administração de servidores, etc.

Artigo por Bruno Salgado, publicado anteriormente no Blog da Clavis e na newsletter da Cobre Bem.

Há diversos procedimentos de auditoria que têm por objetivo aferir a segurança de uma rede, sistema ou aplicação. Cada um deles tem suas características, objetivos, vantagens e desvantagens próprias. Com base nestes fatores, o auditor deve avaliar as necessidades do seu cliente a fim de definir qual auditoria de segurança é mais adequada para atendê-las, e oferecerá melhores resultados.A auditoria Teste de Invasão é uma das auditorias de segurança que podem ser realizadas sobre ativos do cliente. O principal diferencial deste tipo de auditoria é que a avaliação de segurança é realizada através de simulações de ataques reais aos ativos do cliente. Isto quer dizer que a auditoria Teste de Invasão vai além da simples identificação de potenciais vulnerabilidades. Ao contrário da simples indentificação de vulnerabilidades, há verificação da representação de risco real destas, e apreciação do impacto associado à exploração destas vulnerabilidades sobre a segurança da informação e o próprio negócio do cliente.

A auditoria Teste de Invasão é uma das auditorias de segurança que podem ser realizadas sobre ativos do cliente. O principal diferencial deste tipo de auditoria é que a avaliação de segurança é realizada através de simulações de ataques reais aos ativos do cliente. Isto quer dizer que a auditoria Teste de Invasão vai além da simples identificação de potenciais vulnerabilidades, incluindo a avaliação do risco real que estas vulnerabilidades representam para o cliente e a apreciação do impacto associado à exploração das mesmas sobre a segurança da informação e o próprio negócio do cliente.

Motivação para se realizar uma auditoria Teste de Invasão

O benefício gerado pela contratação de uma auditoria Teste de Invasão é difícil de definir para uma equipe gerencial (Return of Investment – ROI), pois qualquer auditoria é, por natureza, um procedimento preventivo, que visa mitigar pró-ativamente um problema que ainda não surgiu. Uma forma de mensurar o benefício que uma auditoria Teste de Invasão traria a uma organização é comparar o custo da auditoria ao prejuízo estimado de um ataque bem sucedido, incluindo prejuízos associados a indisponibilidade de sites comerciais, ações judiciais por quebra de sigilo de informações de terceiros e até desconfiança dos clientes em manter sua relação comercial com a organização.

Além disto, a auditoria Teste de Invasão oferece uma visão ampla sobre a segurança da organização, permitindo homologar a segurança da mesma como um todo. Isto é, ainda que se implemente um mecanismo de segurança complexo para uma aplicação crítica, é possível que haja vulnerabilidades em outras aplicações ou até outros ativos que permitam contornar este mecanismo e comprometer a segurança da informação e dos próprios usuários. De nada adianta, por exemplo, um modelo complexo de segurança em camadas, firewalls duplos, redundância e IDSs distribuídos, se um usuário utiliza por exemplo a senha “12345″.

Finalmente, auditorias Teste de Invasão periódicas cada vez mais tem aparecido como requisito para conformidade com normas internacionais. No Brasil, este requisito já é exigido pelos padrões de segurança PCI-DSS e a família ABNT 27000.

Cursos Relacionados:

Características das auditorias Teste de Invasão

Uma auditoria Teste de Invasão deve ser conduzida de forma totalmente transparente, ou seja, o escopo da auditoria deve ser cuidadosamente definido e todas as simulações de ataque modeladas devem ser apresentadas previamente ao cliente para aprovação. Em seguida, todo o processo deve ser minuciosamente documentado para que o cliente possa, de maneira simples, identificar quais atividades ofensivas são oriundas da auditoria. Além disto, é importante que o auditor seja capaz de estimar os impactos (inclusive efeitos colaterais) de cada vetor a ser explorado, pois o cliente pode querer limitar os testes temendo algum tipo de impacto no seu negócio.

Outros aspectos importantes que devem ser definidos antes da execução da auditoria são: a posição do auditor em relação aos ativos contemplados, o nível de conhecimento do auditor e da equipe de gerência técnica dos ativos sobre a auditoria. Estes aspectos são importantes, pois influenciam diretamente na forma como o teste é realizado e quais técnicas podem ser utilizadas.

Primeiramente, a posição do auditor em relação aos ativos contemplados diz respeito à localização da origem das simulações de ataque, isto é, a auditoria será realizada dentro da rede interna ou a partir da Internet. A definição deste aspecto permite avaliar a segurança dos ativos frente a ameaças públicas vindas de opositores externos (auditoria externa) ou de ex-funcionários insafisfeitos que se aproveitam do acesso interno que ainda possuem (auditoria interna).

Em seguida, o nível de conhecimento do auditor sobre os ativos diz respeito à quantidade de informação que é fornecida sobre os ativos. A definição deste aspecto permite avaliar a segurança dos ativos frente a ataques realizados por opositores que só conhecem informações públicas sobre os ativos (auditoria caixa preta) ou de ex-funcionários ou ex-desenvolvedores que tem amplo conhecimento sobre a forma como a aplicação funciona (auditoria caixa branca).

Finalmente, o nível de conhecimento da equipe de gerência técnica destes ativos sobre a auditoria diz respeito ao quanto esta equipe sabe sobre a auditoria. A divulgação da realização da auditoria (auditoria anunciada), por um lado, pode evitar que mudanças inadvertidas nos ativos contemplados sejam feitas durante a auditoria, alterando do resultado de algumas simulações de ataque, mas, por outro lado, pode ser encarada pela equipe técnica como uma verificação da qualidade do seu trabalho, que pode propositalmente fazer modificações temporárias que forneçam resultados enganosos para a auditoria. Já a não divulgação da realização da auditoria (auditoria não-anunciada) permite que o cliente avalie a capacidade da equipe técnica em detectar e reagir as simulações de ataque, no entanto pode dificultar a divulgação de informações sobre os ativos para auditorias caixa branca.

Conclusão

Com as constantes e aceleradas mudanças na área de TI, novas ferramentas, sistemas e protocolos surgem a cada dia, tornando tantas outras obsoletas. O mesmo vale para técnicas de ataque e ferramentas associadas. Para ser um bom profissional de segurança é preciso, mais do que dominar suas ferramentas de trabalho, entender conceitos e técnicas por trás de cada ferramenta. Só assim você será capaz de modelar seus ataques, dimensionar seu trabalho e aplicar com confiança o que sabe, através do ferramental mais atual e técnicas mais adequadas àquele problema.

Links Interessantes:

• Webinar #5 – Auditorias Teste de Invasão para Proteção de Redes Corporativas
• Artigo Mapeamento de Redes com nmap – ferramenta de código aberto com diversas funcionalidades
• Série de Webinars – Auditoria de Segurança em Aplicações WEB

Artigo por Filipe Villar.

Quando se fala em tratamento de riscos, uma das possibilidades é a de terceirização, isto é fazer um seguro (o exemplo mais clássico da terceirização de riscos) sobre determinado processo ou ativo cujo risco seja maior do que o nível aceitável, porém com controles compensatórios mais caros do que a contratação do tal seguro.

Um dos processos mais críticos para as empresas é a gestão da segurança da informação. Muitas vezes nascida e mantida dentro da área de TI em virtude dos executivos entenderem que Segurança da Informação é o mesmo que Segurança de TI, esse processo é carregado de responsabilidades que podem envolver desde a gestão dos controles de segurança até questões envolvendo perícias e análise de artefatos e desdobramentos legais. Normalmente a gestão de segurança da informação é considerada pela literatura como sendo uma área cujo reporte deveria ser feito diretamente à presidência da companhia ou a uma diretoria específica e que, por isso, estaria numa situação de topo de pirâmide na organização.

Recentemente acompanhei uma discussão sobre a possibilidade de se terceirizar essa área, fazendo-se o uso de consultoria em substituição de uma equipe interna e formada exclusiva ou predominantemente por profissionais internos. O tema levantado era bem direto: deveria ou não ser possível a terceirização da gestão de segurança da informação?

Como consultor já tive experiências sendo terceirizado com essa finalidade, bem como já tive a oportunidade também de trabalhar em uma empresa cuja área de segurança da informação era total e exclusivamente interna à empresa. E a conclusão à que chego para essa situação é: “depende”. Ambas as possibilidades são válidas (e amplamente praticadas), mas cada caso continuará sendo um caso. Mas para evitar o impasse de opinião desse artigo, vamos tentar abordar os prós e contras de cada possibilidade.

Terceirizado

Assim como no início desse artigo, deve-se manter em mente que a terceirização de qualquer atividade envolve a aceitação dos riscos das coisas não irem exatamente como o esperado ou planejado. Em se tratando da área de gestão de segurança da informação, e de todos os detalhes estratégicos envolvidos, a terceirização pode ser considerada em alguns casos como, por exemplo:

• start up da área: A empresa pode não ter estrutura de pessoal para fazer o início das atividades ou mesmo alguma outra deficiência como falta de conhecimento e cultura interna, mas por outro lado por uma questão regultória ou de direcionamento de mercado a empresa deve apresentar em um curto espaço de tempo atividades de SI. E não são raras as empresas que têm essas prerrogativas. A questão é que depois de um tempo agindo, o provisório acaba assumido (muitas vezes) a característica de “provinitivo” (provisório que se tornou definitivo). É necessário um direcionamento estratégico que permita a alta cúpula questionar sobre a internalização ou não.
• carência de mão de obra: É o que acontece nos casos em que a empresa precisa de uma equipe mais estruturada, mas não busca (ou não consegue buscar) mão de obra especializada no mercado para contratação. Para esse cenário o mais comum é ter um gestor da empresa ao qual a equipe terceirizada se reporte e de quem venham as instruções, determinações, diretrizes e tudo mais relacionado ao direcionamento da área. Especificamente nesse caso, o gestor assume uma posição de altíssimo risco visto que ele é o responsável por todas as atividades da equipe de gestão de segurança, mas os resultados são dependentes diretamente do quão capacitada e comprometida essa equipe estará com a organização. E considerando que a gestão de segurança da informação é uma atividade estratégica, o conhecimento do negócio por parte dos integrantes da área é de extrema importância e representa a tênue diferença entre o sucesso e o fracasso desa equipe. E como se não bastasse, o risco do gestor é potencializado justamente pelo fato de ser inviável a rotação da equipe visto que a curva de aprendizado sobre o negócio e os processos internos tem um crescimento muitas vezes suave.
• Política da terceirização: pode parecer estranho e um tanto que arriscado de mais, mas há empresas que optam pela terceirização ao máximo que puder. E ok se isso fizer parte da estratégia escolhida pela gestão, mas quando é essa a escolha, espera-se que hajam controles que cuidem com certo apreço dos contratos, SLAs, questões trabalhistas e todos os outros possíveis desdobramentos. A empresa que opta pela terceirização como base de sua gestão tem na verdade outro fator que os onera subjetivamente que é a questão da retenção do conhecimento e criação/manutenção de uma cultura própria. Mas por outro lado, os benefícios de não ter os custos trabalhistas e de impostos pela quantidade de funcionários, a possibilidade de ser capaz de trocar de equipe através da simples troca de fornecedor e o benefício de poder ter em sua operação o know-how de outras empresas do mesmo setor agregando valor em seu cotidiano podem acabar por assumirem um peso grande na balança das decisões.

Internalizando

Ao contrário do que se tem nos cenários de terceirização, manter a área de Segurança da Informação internalizada, composta exclusivamente popr funcionários tem a vantagem que todos conhecerão vivenciarão os valores da empresa. Por mais que se leve um tempo até que a equipe esteja enganjada, inevitavelmente será uma área com o DNA da empresa. Isso obviamente tem seu lado positivo, visto que não haverá espaço para o ranço de outras empresas e ainda, por serem funcionários assim como todos os outros profissionais de outras áreas, a integração entre a equipe de segurança da informação e as demais equipes (RH, financeiro e comunicação, por exemplo) tende a ser melhor e mais natural. Afinal, os profissionais estariam juntos em eventos de integração, festas de final de ano, torneios de futebol, o choppinho de sexta e tudo mais que pessoas que compartilham o mesmo empregador costumam fazer. Além disso, atividades mais duradouras como planos de comunicação e conscientização, revisões de análises de risco e PCNs, auditorias internas e tudo mais que leve tempo e ocorra em ciclos seriam melhor aproveitados visto que o histórico e o conhecimento se manteria dentro das paredes da empresa.

Mas nem tudo pode ser tão positivo assim. Normalmente, e note que eu disse normalmente, equipes formadas por funcionários da empresa concorrem com outras áreas em pontos comuns à toda a empresa. É o caso de orçamento, calendários, hierarquias, ordem de seja lá o que for… Isso acaba dificultando que haja disponibilidade de recursos para manter essa equipe atualizada e circulante nos meios. Não que seja impossível, mas como é da natureza de todo bom funcionário (salvo raras exceções), ele acredita que todo investimento em sua melhoria como profissional deve ser provida, facilitada ou mesmo bancada pelo seu empregador. Normal em nossa sociedade de origem patriarcal, mas ainda assim não é difícil ver alguns que entendem que esses esforços beneficiam muito mais o próprio profissional em si do que a empresa.

Acrescente-se a isso, o fato de que não é comum o intercâmbio de funcionários entre empresas. Ao menos nunca ouvi falar de tal coisa acontecer por aqui. Você conseguiria imaginar um funcionário da Apple indo fazer um intercâmbio com um empregado da Microsoft? Soa tão estranho quanto improvável. Não que fosse esperado tal intercâmbio, mas em se tratando de consultorias externas, já torna-se mais possível encontrar consultores que tenham trabalhado em projetos mesmo semelhantes em empresas clientes que fossem concorentes entre si. Sob os olhos da consultoria, isso é bem normal e praticado visto que podem haver processos e objetivos semelhantes entre as concorrentes, o que reduz o tempo de aprendizado e de atendimento.

Por isso é que normalmente (e, de novo, atenção ao “normalmente”) equipes formadas exclusivamente por funcionários podem apresentar alguma defasagem de experiência. Não que isso seja tão prejudicial assim, mas ao menos os riscos de descontinuidade e de vazamento de informações acabam sendo reduzidos.

Então, qual é a melhor escolha: terceirizar ou não os riscos e/ou alguma área? Encerro deixando essa pergunta propositalmente sem uma resposa definitiva porque, como dito anteriormente, cada caso será um caso. Se a duvida persistir, pode me escrever que tento ajudar.

Você conhece as vantagens de se migrar o e-mail corporativo para a nuvem? E os cuidados necessários à estratégia de migração? Antes de se adotar o correio eletrônico na nuvem, é preciso levar em conta os custos ocultos, as questões legais, as contratuais e seguir diversas recomendações, inclusive as de segurança. Os principais riscos relativos à adoção do correio eletrônico na nuvem devem ser atentamente analisados.

Artigo por Paulo Sergio Pagliusi, Ph. D..

Uma das principais razões para se pensar em e-mail na nuvem é a significativa economia de escala obtida com esse modelo computacional. A maioria das corporações não tem mais que centenas ou milhares de usuários, enquanto um provedor de nuvem pode fornecer esses serviços para dezenas de milhões de usuários, a custos bem menores – podendo chegar, no limite, a zero. Além disso, devido a restrições orçamentárias, o e-mail interno às organizações não disponibiliza grande capacidade de armazenamento. É comum um e-mail interno ser restrito a 500 MB por usuário, enquanto um e-mail na nuvem oferta 30 GB. O custo por GB na nuvem é bem menor pela economia de escala ofertada e, logo, o provedor pode oferecer, com custo mínimo, maior capacidade de armazenamento.

Entretanto, definir uma estratégia de migração para e-mail na nuvem exige cuidados. Um deles é levar em conta os custos ocultos. Embora o e-mail na nuvem tenha um preço por usuário bem menor, há certos custos que não aparecem imediatamente. Por exemplo, custo do maior uso de redes e banda larga, e da migração do ambiente interno para a nuvem. Também será necessário manter um staff mínimo de suporte, para apoio ao usuário final e para a gestão da interface com o provedor da nuvem.

O contrato com o provedor deve ser analisado com cautela. Alguns itens merecem atenção redobrada, como o custo para retenção longa de backup (archiving) e para o cancelamento do contrato (e migração para outra nuvem). Há também as questões legais. Suas caixas postais podem ficar armazenadas em um centro de dados localizado em outro país? Nesse caso, sob qual jurisdição as questões legais serão resolvidas? E caso haja uma investigação forense, como os dados poderão ser disponibilizados?

Quando uma informação é armazenada em nuvem, em última instância será armazenada em um servidor e em um dispositivo de armazenamento residente em algum local físico, que pode ser em outro país, sujeito a legislação distinta. Além disso, por razões técnicas, essa informação poderá migrar de um servidor para outro, estando ambos em países diferentes. Nada impede que a lei de um desses países permita o acesso às informações armazenadas, mesmo sem o consentimento do proprietário.

Por exemplo, em diversos países a legislação antiterrorista ou de combate à pedofilia permite o acesso a informações pessoais, sem aviso prévio, em caso de evidências legais de atos criminosos. A questão é que o conceito de computação em nuvem é recente. A legislação em vigor mal entendeu a Internet e está distante de entender a nuvem. Ainda está no paradigma da época em que os PCs viviam isolados e, no máximo, havia troca de disquetes. Apreender um desktop para investigação forense em e-mail cujo conteúdo está em nuvem é totalmente irrelevante. E como obter as informações de discos rígidos virtuais, espalhados por diversos provedores de nuvem? Outros cuidados envolvem a segurança e integração com aplicações que interajam com o serviço de e-mail.

Diante do exposto, Cezar Taurion estabelece que, antes da migração do e-mail do ambiente interno para a nuvem, devem ser observadas as seguintes recomendações [1]:

• Criar um projeto específico para a migração do e-mail para a nuvem.
• Determinar claramente os objetivos do projeto em pauta (reduzir custos?).
• Identificar os custos internos por usuário de e-mail e compará-los com os dos provedores de e-mail em nuvem.
• Analisar diferenças de funcionalidade existentes entre os recursos oferecidos pelo e-mail interno e os oferecidos pelo provedor de nuvem (como nível de disponibilidade, política de backup, consumo da largura de banda por usuário [2]).
• Engajar o setor jurídico no processo de migração, de modo a selecionar o provedor de e-mail na nuvem mais adequado e estudar atentamente o contrato.

Passemos à análise dos riscos. Recentemente, diversas organizações adotaram soluções gratuitas de e-mail baseado em nuvem, como o Google Gmail™, Yahoo Mail™ e Hotmail™. Embora para a maioria dos casos tais soluções possam ser excelentes, podem não ser tão adequadas para organizações que necessitam trocar e-mails com conteúdo sensível como, por exemplo, as de defesa. Nestes casos, a segurança provida pelos provedores de e-mail em nuvem é considerada aquém do ideal, devido ao fato de que a maioria dos e-mails é enviada em texto aberto. Assim, para proteger seus e-mails, o remetente precisará criptografá-los, seja fazendo uso de uma infraestrutura de chaves públicas, seja coordenando com o receptor uma forma da informação ser decifrada após o recebimento.

Segundo um estudo publicado pelo portal About.com Defense [3], os principais riscos relativos ao correio eletrônico na nuvem podem ser assim resumidos:

1. E-mails e anexos armazenados em qualquer lugar do mundo. Um dos problemas do correio eletrônico em nuvem é que não se sabe em que lugar do mundo os e-mails e anexos são armazenados. Eles poderiam ser facilmente armazenados em países envolvendo distintas legislações. Como exemplo, leia o conteúdo exposto na norma: NIST SP-800-144 – Guidelines on Security and Privacy in Public Cloud Computing [4].
2. Provedores de correio eletrônico em nuvem, geralmente, reivindicam licença do conteúdo ofertado, inclusive e-mails. Leia bem os termos e condições, para ter certeza que você não desista de direitos que você não pode abrir mão. Por exemplo, os termos e condições estabelecidos pelo Google Gmail™ incluem, na seção 11.1, esta declaração:
   

   By submitting, posting or displaying the content you give Google a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive license to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute any Content which you submit, post or display on or through, the Services.

   Na Seção 11.2, também está escrito:

   You agree that this license includes a right for Google to make such Content available to other companies, organizations or individuals with whom Google has relationships for the provision of syndicated services, and to use such Content in connection with the provision of those services.

   Certifique-se de que estas são condições com as quais você pode concordar, antes de utilizar e-mails baseados em nuvem.

3. E-mail com relatórios sensíveis de segurança e informações não classificadas, mas restritas, não deve transitar na nuvem. Deve-se atentar para não expor indevidamente informações classificadas, que venham a transitar, desprotegidas, no e-mail em nuvem.
4. Legislação vigente sobre segurança da informação pode restringir o uso do e-mail na nuvem. Se a sua corporação está sujeita a regulamentações, tais como HIPAA ou Sarbanes-Oxley, então é importante que qualquer solução de nuvem que você use para enviar e-mail tenha uma equipe com capacidade e especialização para manter seu negócio em conformidade. Se o provedor é incapaz de fornecer esta garantia, então se deve procurar outro provedor de serviços.
5. Um software em nuvem é considerado aceitável se o provedor ofertar ao cliente garantias e controles de segurança, mas a maioria dos provedores de e-mail em nuvem não as oferece. O consumidor precisa ter certeza de que o provedor de e-mail em nuvem suporta suas necessidades e fornece garantias e mecanismos de controle de segurança, de acordo com a dinâmica exigida pelo ambiente em nuvem. Assim, de acordo com Marcon Jr et al, todo provedor de nuvem deve [5]:

• Controlar o acesso de usuários aos serviços fornecidos pela nuvem – de acordo com as políticas definidas pelo consumidor
• Honrar os acordos de nível de serviço (SLA – Service Level Agreement) ou contratos de QoS (Quality of Service) estabelecidos com o consumidor
• Controlar o acesso aos dados dos usuários
• Controlar o acesso à área do sistema, no nível de usuário e administrativo (com acesso privilegiado)
• Manter as informações do perfil do usuário e as políticas de controle de acesso atualizadas
• Permitir a coleta de informações do perfil do usuário e das políticas de controle de acesso implantadas no provedor de nuvem
• Fornecer meios de notificação para alterações em contas de usuários (criação, remoção, concessões de acesso), visando coibir configuração de contas falsas ou modificação de direitos de acesso no provedor sem que o consumidor saiba
• Fornecer trilhas de auditoria para o ambiente de cada consumidor – identificando atividades de gerenciamento e acesso, assim como a utilização de qualquer recurso para o qual sejam estabelecidas cotas de uso.

Em contraste ao exposto, os termos e condições estabelecidos pelo provedor de e-mail em nuvem Google Gmail™ incluem, na seção 14.2, a seguinte declaração, indicando que o risco do uso dos serviços é do consumidor, e que o serviço é fornecido “como está” e “quando disponível”:

YOU EXPRESSLY UNDERSTAND AND AGREE THAT YOUR USE OF THE SERVICES IS AT YOUR SOLE RISK AND THAT THE SERVICES ARE PROVIDED “AS IS” AND “AS AVAILABLE.

Finalmente, as vantagens de se migrar o e-mail corporativo para a nuvem são notáveis. Mas a estratégia de migração demanda cuidados prévios. Antes de se adotar o correio eletrônico na nuvem, é preciso levar em conta os custos ocultos, as questões legais, as contratuais e seguir diversas recomendações, inclusive as de segurança. Os principais riscos relativos à adoção do correio eletrônico na nuvem, expostos neste artigo, devem ser analisados com a devida atenção. A Cloud Security Alliance Brazil publicou, em Jun2010, o Guia de Segurança para Áreas Críticas Focado em Computação em Nuvem [6], com as seguintes recomendações, todas aplicáveis ao provedor de e-mail em nuvem:

1. É preciso examinar e avaliar a cadeia de suprimentos do provedor da nuvem (relacionamentos com prestadores de serviço). Isso também significa verificar o gerenciamento de serviços terceirizados feito pelo próprio provedor da nuvem.
2. A avaliação do provedor do serviço em nuvem deve concentrar-se nas políticas de recuperação de desastres e continuidade de negócio, e em seus processos. Deve incluir, também, a revisão das avaliações do provedor destinadas a cumprir exigências de políticas e procedimentos, e a avaliação das métricas usadas pelo provedor, para disponibilizar informações sobre o desempenho e a efetividade dos controles.
3. O plano de recuperação de desastres e continuidade de negócios do consumidor do serviço em nuvem deve incluir cenários de perda dos serviços prestados pelo provedor e da perda, deste último, de suas capacidades dependentes de terceiros.
4. A regulamentação da governança de segurança da informação, a gestão de riscos, as estruturas e os processos do provedor da nuvem devem ser amplamente avaliados.
5. É preciso solicitar documentação de como as instalações e os serviços do provedor da nuvem são avaliados, quanto aos riscos e ao controle de vulnerabilidades.
6. Deve-se solicitar ao provedor da nuvem uma definição do que ele considera fator de sucesso em segurança da informação e serviços críticos, indicadores-chave de desempenho, e como esses pontos são mensurados.

• [1] Taurion, Cezar. E-mail em nuvem: quando e como? Portal iMasters, Set2010, acesso em Jan2012. Disponível em: http://imasters.com.br/artigo/18170/cloud/e-mail_em_nuvem_quando_e_como/
• [2] Segundo Christopher Voce, analista da Forrester, para cada grupo de 100 utilizadores ativos no Outlook instalado localmente são consumidos 37 KB/s de largura de banda. Já o mesmo grupo de 100 utilizadores, ligados ao serviço de e-mail Outlook na plataforma de e-mail em nuvem, requer mais do que o dobro: 85KB/s. Matéria: Seis dicas para a migração do e-mail para a cloud. Portal ComputerWorld, Abr2011, acesso em Jan2012. Disponível em: http://www.computerworld.com.pt/2011/04/01/seis-dicas-para-a-migracao-do-e-mail-para-a-cloud/
• [3] Bame, Michael. Dangers of Cloud Based Email. Portal About.com Defense, Jan2012, acessado em 12Jan2012. Disponível em: http://defense.about.com/od/BusinessOps/a/Dangers-Of-Cloud-Based-Email.htm
• [4] NIST SP-800-144 – Guidelines on Security and Privacy in Public Cloud Computing. National Institute of Standards and Technology, Jan2011, acesso em Jan2012. Disponível em: http://csrc.nist.gov/publications/drafts/800-144/Draft-SP-800-144_cloud-computing.pdf
• [5] Marcon Jr, Arlindo; Laureano, Marcos; Santin, Altair; Maziero, Carlos. Minicurso Capítulo 2: Aspectos de segurança e privacidade em ambientes de Computação em Nuvem. X Simpósio Brasileiro em Segurança da Informação e de Sistemas Computacionais, 2011. Em: http://professor.ufabc.edu.br/~joao.kleinschmidt/aulas/seg2011/nuvem.pdf
• [6] https://cloudsecurityalliance.org/guidance/CSAGuidance-pt-BR.pdf

Artigo de Filipe Villar.

As redes sociais são uma forma de nos expressarmos em um mundo completamente virtual, mas não somos tão virtuais que nos possamos desconhecer reais. E diversos são os exemplos de uso das redes sociais como forma de unir massas reais em movimentos políticos, sociais, culturais, e tantos outros.

Mas as redes sociais têm sim alguns riscos que podem expor não só o internauta, mas também pessoas associadas a ele (exemplo: filhos, esposa, parentes próximos ou amigos) e o seu ambiente de trabalho.

Inicialmente vamos considerar uma abordagem às questões tecnológicas. Considere, por exemplo, o Twitter. Não é exatamente uma rede social, mas sim um sistema de micro blog. Todavia podemos considerá-lo justamente por ter algumas características de sociabilidade digital, uma vez que escolhemos seguidores e seguidos; e essas escolhas muitas vezes denotam nossas opções por assuntos mais diversos. Contudo não se tem certeza de quem está do outro lado e quem está twittando o que lemos e reencaminhamos. E principalmente pela questão tecnológica (e de conceito minimalista), o uso dos encurtadores de endereço modificam os links de forma a não ser possível num primeiro momento identificar o que está atrelado a eles.

Então, considerando apenas a questão tecnológica pura e simplesmente, as redes sociais também podem apresentar um vetor de ataque principalmente através de malwares.

Considerando as questões comportamentais, volto a ressaltar o exemplo das pessoas que gostam de dizer os seus passos para o mundo. A vida moderna e a tecnologia que nos cerca invariavelmente nos afastam dos convívios sociais tradicionais e isso cria uma dependência absurda por aceitação mútua sem precedentes. A carência humana está à flor da pele. A necessidade de ser considerado um “cidadão do mundo” é tão grande que nos relacionamos com inúmeras pessoas apenas virtualmente, o que, em uma realidade mais conservadora, não seria possível pela simples limitação de tempo para tal convívio.

E é assim, carentes digitais, que nos expomos. Fotos, vídeos, grupos de interesse e tantos outros artifícios que são apresentados como cool stuff que nos enveredam por caminhos de total exposição e, consequentemente, promovem um aumento absurdo dos riscos.

Para se ter uma materialização disso, basta fazer um paralelo muito simplista. Imagine que você está andando na rua (num grande centro urbano, por exemplo) e repentinamente se aproxima de uma outra pessoa totalmente desconhecida. Apenas para considerar ainda o cenário fictício desse exemplo, imagine que a receptividade seja positiva e que você comece uma grande e nova amizade de infância… Ora, é claro que você confia totalmente no seu amigo de infância, certo? Então você começa a expor suas questões pessoais para essa pessoa. Nada muito significativo, mas sua fotos, as fotos de seus filhos/parentes, suas viagens, sua casa de veraneio, e mais o que você pensa do seu chefe, ou aquela saída com a amiga da sua prima, enfim… E, por outro lado, o seu novo “amigo de infância” até faz a mesma coisa contigo… Mas que relação mais insólita é essa que pode ser levada à tanta transparência assim? Parece estranho, fazer isso no mundo real (no grande centro urbano). Então por que temos essas mesmas atitudes no mundo virtual? Não vivemos em uma fazenda nem tampouco numa second life.

Cobra-se muito para que os provedores mantenham o sigilo das informações dos internautas. Tanto que a conversa chega ao Planalto Central com peso de regulação (leia-se: passível de multas, portanto $). Porém e quanto à exposição das nossas informações por nós mesmos? Quem regula?

Por Gisele Truzzi

O S.O.P.A. (Stop Online Piracy Act), em tradução livre, “Lei de Combate à Pirataria”, foi um projeto de lei de autoria do Poder Legislativo dos Estados Unidos, que visava combater a violação de direitos autorais (“pirataria”) praticada via internet. Segundo os partidários do S.O.P.A., seu intuito seria proteger o mercado de propriedade intelectual e gerar receitas e empregos. Consequentemente, havia um grande “lobby” da indústria de entretenimento norte-americana para que esta lei fosse aprovada.

Na prática, o S.O.P.A. permitiria que o Departamento de Justiça norte-americano e os grandes detentores de direitos autorais obrigassem, judicialmente, que sites potencialmente violadores da propriedade intelectual fossem bloqueados. Além disso, o projeto de lei permitiria também que o governo norte-americano solicitasse que tais sites permanecessem ocultos nos resultados dos principais buscadores da internet, através da inserção de filtros de pesquisa.

A expectativa de aprovação de tal lei causou fortes protestos internacionais, tendo em vista que as conseqüências do S.O.P.A. refletiriam no mundo todo, equivalendo-se a medidas arbitrárias tomadas contra determinados sites, além de prática de censura através de filtros nos mecanismos de busca da internet.

A discussão trazida pelo S.O.P.A. aumentou com o fechamento do site MEGAUPLOAD, acusado de violar os direitos autorais, servindo como meio de compartilhamento de conteúdo “pirata”.

O S.O.P.A. foi tão criticado e visto como um mecanismo arbitrário de poder, violação da neutralidade da rede e censura, devido aos seguintes motivos:

a) Bloquearia total e irrestritamente sites que potencialmente violassem a propriedade intelectual. Tal atitude seria uma forma de censura e atentaria contra a liberdade de expressão na internet, suspendendo-se totalmente um domínio, ao invés de bloquear somente determinado conteúdo. Isso inviabilizaria completamente o site e afetaria todos os seus usuários, inclusive aqueles que armazenassem ou compartilhassem conteúdo lícito. No Brasil, ocorreu fato semelhante com o site Youtube, devido ao processo judicial movido pela apresentadora e modelo Daniela Cicarelli, que foi filmada em cenas íntimas com o namorado em uma praia e surpreendeu-se com o vídeo disponibilizado na internet. A decisão judicial, favorável à modelo, equivocou-se tecnicamente ao suspender totalmente os serviços do Youtube no Brasil, quando na realidade, deveria identificar e bloquear somente os usuários responsáveis pela divulgação do vídeo.

b) Não determinava a notificação prévia ao responsável pelo site, solicitando-lhe medidas quanto ao material potencialmente ilegal disponibilizado por um usuário. Tal atitude responsabilizaria o site pelo ilícito praticado por um indivíduo, e não permitiria ao detentor do serviço sequer a possibilidade de identificação do usuário e exclusão do material, condenando-o sumariamente pela prática delituosa de terceiro. Esta medida é contrária aos princípios democráticos de Direito, inviabilizando qualquer possibilidade de defesa ou de solução extrajudicial do conflito, e atribuiria objetivamente ao site a culpa de seu usuário. Para que os sites de compartilhamento de conteúdo evitassem sua punição, deveriam então adotar medidas de verificação de conteúdo, o que seria tecnicamente impossível, devido à quantidade de material hospedado, além de ilegal, pois permitiria a censura prévia aos materiais submetidos. Os domínios de compartilhamento de conteúdo teriam portanto, a capacidade de analisar, julgar e condenar os materiais a ele submetidos.

Certamente, se tal lei vigorasse, os reflexos seriam sentidos pelo mundo todo, com a inacessibilidade de diversos sites, inclusive inviabilizando a distribuição de material legal. Felizmente, o S.O.P.A. foi suspenso temporariamente, enquanto a discussão sobre o tema ainda continua.

No Brasil, vivenciamos situação semelhante quando a antiga redação do Projeto de Lei no 84/99, sobre Crimes Eletrônicos, ainda prevalecia, determinando que os provedores de serviço de internet identificassem e remetessem às autoridades qualquer ato de seus usuários que julgassem como “suspeito”. O artigo polêmico deste projeto de lei foi suprimido, a redação foi aprimorada e o conteúdo foi reduzido ao que se considera essencial na punição dos crimes eletrônicos, resultando no PL no 587/2011.

A situação exposta pelo S.O.P.A. demonstrou que a pirataria não é endêmica no Brasil, onde a chamada “Lei de Gérson” inoculada na mentalidade da maioria da população, faz com que o cidadão acredite ser correto comprar uma grande quantidade de filmes e CDs pirateados a preços irrisórios, ao invés de alugar alguns DVDs na locadora do bairro ou assinar um serviço legalizado de streaming online por um preço módico.

É notório que a nossa legislação brasileira relacionada aos direitos autorais encontra-se ultrapassada, o que de certa forma inviabiliza a produção cultural na sociedade digital atual, onde utilizamos inúmeras formas de compartilhamento de conteúdo. Porém, acabar com os direitos autorais ou bloquear sites por completo, sem qualquer notificação extrajudicial prévia, é um retrocesso, uma forma de impor uma Ditadura Online.

A internet não é uma terra sem lei. Porém, deve manter sua característica de dinamismo e neutralidade, possuindo um regramento mínimo. Afinal, já dispomos de todo o nosso ordenamento jurídico brasileiro para coibirmos violações aos direitos autorais e demais infrações legais.

Por Gisele Truzzi

O projeto pretende coletar e registrar as seguintes informações: quantidade de redes identificadas, se protegidas ou não, tipos de autenticação e criptografias utilizadas em cada uma delas. Essas informações serão utilizadas para gerar estatísticas sobre o uso de protocolos seguros e boas práticas de segurança. Nenhuma informação a mais é detectada, e não há intrusão nas redes, garantindo assim a privacidade de todas as redes e empresas atingidas pela pesquisa. Em breve o projeto acredita inclusive divulgar novas parcerias.

No último War Driving Day foi feito um mapeamento das redes sem fio da cidade de Macaé (RJ) no dia 23 de agosto de 2011, e para isso foram utilizadas algumas antenas e equipamentos específicos, necessários para a realização do projeto.

Veja abaixo uma lista com todos os equipamentos utilizados para a realização do projeto:

Em breve faremos um novo post com mais informações sobre o projeto.