Crimes Cibernéticos A Visão da ICANN. Vanda Scartezini SSAC Security & Stability Advisory Committee

Transcrição

1 Crimes Cibernéticos A Visão da ICANN Vanda Scartezini SSAC Security & Stability Advisory Committee

2 ICANN SSAC gestor dos Nomes e Endereços da Internet SSAC grupo internacional de 35 membros analisa e faz recomendações à ICANN sobre a Segurança e Estabilidade da Internet. SSAC tem um representante no Board of Directors da ICANN SSAC membros selecionados com foco na maior diversidade de conhecimento técnico possível relacionado à Internet. SSAC tem membros relacionados ao Law Enforcement Authorities LEA. SSAC publica seus estudos sob a sigla SAC nº

3 Foco da ICANN É responsável pela Estabilidade e Segurança da rede mundial ICANN tem foco no DNS. Vem aumentando sua colaboração com a LEA Law Enforcement Authorities A segurança está vinculada em última instância ao DNS. Toda ação de proteção ao DNS é um reforço contra o crime cibernético.

4 O que se está trabalhando na ICANN com a LEA? Reuniões de negociação com equipes de Law Enforcement (Praga / Toronto/ prox: Pequim) WHOIS Protocolo e demais questões Internationalized Registration Data Carrier Grade NAT (Network Address Translation)

5 Entendendo o Whois ( SAC 051) WHOIS tem 3 distintos componentes: 1. Domain Name Registration Data (DNRD) são as informações que os Registrantes provêm e os ISPs/ Registrars coletam. Algumas informações são disponíveis ao público. Todas as informações disponíveis à investigação autorizadas. Registrars acreditados à ICANN especificado em contrato (RAA). cctlds (Country Code Top Level Domains) operadores ou seus governos definem.

6 Entendendo o Whois ( SAC 051) 2. Domain Name Registration Data Access Protocol (DNRD AP) é o elemento padrão de troca de comunicação que torna o acesso aos dados possível. Ex: WHOIS protocolos (RFC 3912) e HTTP (RFC atualizações) são usados para acesso público ao DNRD. 3. Domain Name Registration Data Directory Service (DNRD DS) serviços oferecidos pelos Registries e Registrars para provê acesso ao DNRD. Por contrato o Diretório de Serviços deve ser via porta 43 e pela internet. Para os cctlds eles ou os governos definem que serviços eles devem prestar.

7 Que dados são estes do DNRD? Nome do domínio a ser registrado Nomes dos servidores primários e secundários para o novo domínio registrado A identidade do registrar (pode ser provido pela própria website) A data do registro inicial do nome de domínio registrado A data da expiração deste domínio registrado O Nome e endereço postal do dono deste domínio registrado Nome, endereço postal, e mail, telefone e fax do contato técnico Nome, endereço postal, e mail, telefone e fax do contato administrativo do domínio registrado

8 Survey on Whois porque é importante? Vai ajudar a estimar o grau de concordância entre os vários requisitos entre os operadores de nomes genéricos na Internet. Oferece um voz à comunidade em assuntos técnicos sobre o futuro do sistema WHOIS. O relatório e a análise serão uteis ao IETF nos esforços de criação de um novo protocolo. A pesquisa é um inventário técnico e não define regras nem politicas que devam ser implantadas.

9 IRD (Internationalized Registration Data)/ IDNs Foi feito um estudo de viabilidade e adequabilidade sobre a introdução e publicação de especificações para lidar com o registro de dados em outros alfabetos.

10 Porque este estudo é importante? É um importante passo na evolução dos serviços de Whois. Não existem standards/padrões para a submissão e publicação de dados em outros alfabetos nos serviços de Whois. Correntemente as implementações de Whois existentes não permitem, de forma consistente, tratar os dados em outros alfabetos e pode gerar problemas para o usuário e questões de interoperabilidade.

11 O que se pretende resolver? É relevante criar este registro de dados realmente internacionalizado (com os diferentes alfabetos)? Quais são os dados que de fato são viáveis de serem internacionalizados? O sistema existente do Whois é capaz de tratar e publicar estes dados sem gerar outros problemas? (é urgente criar um protocolo alternativo para acesso ao DNRD)

12 Registro para internacionalização Nome do Domínio (ambos) Nome do Registrar ( deve vir em ASCII) O Status do registro do Domínio (diversas alternativas) Informações sobre o Servidores (ASCII ou ambos) Nomes (ex. dono, contatos admin. e técnico); Endereço Postal (ex. dono, contatos admin. e técnico); Fone/fax (ex. dono, contatos admin. e técnico); (usar ITU R E.123 ( ) Datas (ex. de criação do domínio, expiração, atualização); (ISO /ASN 1 ex ) E mails (ex. dono, contatos admin. e técnico); (IETF novo padrão)

13 IRD (Internationalized Registration Data)/ IDNs O que está em discussão com as autoridades LE? Como o registro adequado de dados dos registros em outros alfabetos vão afetar o Law enforcement e a habilidade dos pesquisadores de identificar e capturar o criminoso na Internet. Deverá ter um requisito de tradução ou mudança de alfabeto para os dados registrados? Como a comunidade policial (law enforcement) pode efetivamente participar do processo de desenvolvimento de políticas neste item?

14 Verificação e Validação dos registros As propostas sobre a mesa: Validação Pré & Pós Registro Validar a consistência de todos dados com os campos do documento e os padrões antes da resolução do registro; Verificação requerendo retorno afirmativo, com ferramenta baseada em autenticação que gere um código único que deve retornar como especificado pelo Registrar ( manual ou cancela); Verificação do telefone código único com retorno; (manual ou cancela) Qualquer mudança deve ser verificada e validada em 15 dias corridos. Validar novamente todos os dados após 12 meses.

15 Quais os pontos de discussão com LEA? 1. Pré XPós LEA os abusos podem ser efetivos mesmo que o domínio possa ser mantido apenas pro alguns dias Mercado a)hoje resolução imediata do registro dos registrantes. Atrasar a resolução muda drasticamente o mercado. b) Justifica atrasar o registro de milhões para impedir potenciais criminosos?

16 Questões que devem ser respondidas O processo de registro deve ser modificado para permitir que a validação do WHOIS se dê antes da resolução do registro do novo domínio? Esta pré verificação resolve as preocupações das LEA? Que tamanho tempo & custo tem estas mudanças? Quais os impactos e os custos para os registrantes? A maioria dos registrantes querem apenas um endereço de e mail. Isso muda alguma coisa?

17 Quais os pontos de discussão com LEA? 2. Validação do FONE LEA ambos e mail e fone devem ser validados Mercado verificar uma das três alternativas: E mail com código único Telefone, chamando o número (custo + criminosos burlam fácil a validação de código) Via postal

18 Questões que devem ser respondidas O Registrante (além do técnico e admin) deve ter um fone de contato? Como isso vai impactar o Registrante e como vai ajudar a LEA? Não exigirá contratação de terceiros para checar telefones e aumentar o risco? Que gols as autoridades de LE pretendem alcançar com esta validação de telefone? ( pré pagos celulares...)

19 Quais os pontos de discussão com LEA? 3. Re verificação Anual LEA só os avisos do lembre se de atualizar o Whois é muito falho. Mercado continuar com os lembre se ou verificar quando alterado pelo Registrante. (custos)

20 Questões que devem ser respondidas Que trabalho adicional terá o Registrante (ex : donos de muitos nomes)? O cancelamento por não responder a tempo não é um castigo desproporcional? Quais os impactos técnicos e financeiros para os Registrars? Que gols as autoridades de LE pretendem alcançar com esta re validação?

21 Network CARRIER GRADE NAT ( ) Address Translation O problema: NATs são práticas estabelecidas no mercado Preservam os endereços (exaustão do IPv4) Segurança: CGN move as NATs do consumidor para o provedor Remove a capacidade de identificar o usuário final. Muitos usuários por trás de um mesmo endereço A NAT traduz as redes internas para a rede externa, preservando o endereço, mas quebra o end to end da Internet.

22 CGN NATs Proposta de Solução LEA Aceleração do IPv6 Atribuições do CGN Fonte e destino no endereço de IP ( os ISPs devem prover identificador no log in) Fonte e destino porta : os provedores de conteúdo precisam fazer log in numa porta fonte e os provedores de aplicações precisam garantir ter uma porta fonte padrão. Ter uma autenticação do tempo (time stamp) em segundos com tempo em UTC.

23 CGN Nats pedido ao SSAC Descrever o problema em profundidade; Oferecer uma solução inédita para a indústria; Encorajar a indústria a adotar a solução; Promover a adoção de IPv6?

24 Obrigada