Autores | |
---|---|
Nome: Jordi Palet Martinez Email: jordi.palet@theipv6company.com Organização: The IPv6 Company |
Nome: Jordi Palet Martinez Email: jordi.palet@theipv6company.com Organização: The IPv6 Company |
Resumo | |
A proposta permite garantir e validar os contatos de abuso do WHOIS (abuse-c e abuse-mailbox) das organizações e poder a ssim informar os casos de abuso e resolvê-los. Esta proposta visa resolver o problema e garantir a existência de um contato abuse-c correto e o processo para seu uso. |
A proposta permite garantir e validar os contatos de abuso do WHOIS (abuse-c e abuse-mailbox) das organizações e poder a ssim informar os casos de abuso e resolvê-los. Esta proposta visa resolver o problema e garantir a existência de um contato abuse-c correto e o processo para seu uso. |
Justificativa(Descrever o problema que deseja solucionar) | |
A política atual (ASN) não é clara em relação à obrigação de registrar um contato de abuse (abuse-c) nem ao formato espe cífico, e se pode ser aplicada a outros casos de registros no WHOIS. Como resultado, pode haver receptores de recursos de LACNIC que não têm esse contato registrado para seus recursos, ou a inda há casos de LIRs/ISPs, usuários finais ou outros, que usam uma caixa de correio inexistente ou que não está ativame nte monitorada. A falta de validação dos contatos tornou o relato de casos de abuso ineficaz, gerando problemas de segurança e custos pa ra as vítimas. Para tentar resolver este problema, é feita uma simples verificação periódica do contato de abuso, evitando assim custos desnecessários para terceiros. A proposta garante que o custo de processar os abusos recaia sobre o receptor do recurso quem, direta ou indiretamente ( seu cliente e de quem ele possivelmente recebe compensação pelo serviço), é responsável pelo abuso, em vez de recair sob re a vítima. Leve em conta que isso evita o possível agravamento, tempo e despesas legais para ambas as partes se forem para essa instância. Para isso, o atributo abuse-c, que até agora era apenas referenciado para o objeto "aut-num", torna-se obrigatório nos o bjetos "inetnum" (tanto para o IPv4 quanto para o IPv6), e qualquer um que venha surgir no futuro. Este atributo é um co ntato de abuso, que irá conter no mínimo o atributo "abuse-mailbox". |
A política atual (ASN) não é clara em relação à obrigação de registrar um contato de abuse (abuse-c) nem ao formato espe cífico, e se pode ser aplicada a outros casos de registros no WHOIS. Como resultado, pode haver receptores de recursos de LACNIC que não têm esse contato registrado para seus recursos, ou a inda há casos de LIRs/ISPs, usuários finais ou outros, que usam uma caixa de correio inexistente ou que não está ativame nte monitorada. A falta de validação dos contatos tornou o relato de casos de abuso ineficaz, gerando problemas de segurança e custos pa ra as vítimas. Para tentar resolver este problema, é feita uma simples verificação periódica do contato de abuso, evitando assim custos desnecessários para terceiros. A proposta garante que o custo de processar os abusos recaia sobre o receptor do recurso quem, direta ou indiretamente ( seu cliente e de quem ele possivelmente recebe compensação pelo serviço), é responsável pelo abuso, em vez de recair sob re a vítima. Leve em conta que isso evita o possível agravamento, tempo e despesas legais para ambas as partes se forem para essa instância. Para isso, o atributo abuse-c, que até agora era apenas referenciado para o objeto "aut-num", torna-se obrigatório nos o bjetos "inetnum" (tanto para o IPv4 quanto para o IPv6), e qualquer um que venha surgir no futuro. Este atributo é um co ntato de abuso, que irá conter no mínimo o atributo "abuse-mailbox". |
Texto atual | |
Texto atual: Não existe Texto novo: 12. Registro e validação de "abuse-c" e "abuse-mailbox" 12.1. Descrição do "abuse-c" e "abuse-mailbox" Todos os recursos que usem os sistemas de registro de LACNIC devem incluir obrigatoriamente, nas entradas do WHOIS corre spondentes, o atributo de contato abuse-c (contato de abuso) como mínimo com um e-mail abuse-mailbox válido, monitorado e devidamente atendido, que permita o envio de relatórios manuais ou automáticos de comportamentos abusivos, segurança e semelhantes. O atributo abuse-mailbox deve estar disponível sem restrições via WHOIS, APIs e futuras tecnologias. Levando em conta a natureza hierárquica dos objetos, os herdados de aqueles alocados diretamente por LACNIC (por exemplo , subdesignações), estar cobertos pelos objetos de nível superior e seu próprio atributo "abuse-c” é optativo. Seguindo práticas usuais, outros atributos "e-mail" podem ser incluídos para outros fins. 12.2. Características do "abuse-mailbox" Os e-mails enviados para "abuse-mailbox" devem exigir intervenção manual em algum momento, por parte do destinatário, e não podem ser filtrados, pois isso poderia impedir, em alguns casos, a recepção de um relatório de abuso. Por exemplo, u m relatório de spam, ao incluir a própria mensagem de spam ou URLs ou conteúdos geralmente classificados como spam. A caixa de correio "abuse-mailbox" poderá enviar inicialmente uma resposta automática, por exemplo, designando um número de bilhete, aplicando procedimentos de classificação, solicitando mais informações, etc. No entanto, não poderá requere r o uso de um formulário, pois isso implicaria que cada entidade que precisar denunciar abusos, geralmente de forma auto matizada, seja forçada a desenvolver uma interface específica para cada receptor de recursos a quem tem que informar um abuso. Isso seria inviável, uma vez que faria recair o custo do processado dos abusos em quem envia a reclamação, vítima do abuso, em vez de ser pago por aquele que, direta ou indiretamente, provoca o abuso. O razoável é que quem denuncia o abuso, faça isso no primeiro relatório, enviando informações suficientes (log, cópia de spam ou cabeçalhos completos, o equivalente em cada tipo de abuso). Da mesma forma, é razoável que o e-mail inicial de auto-resposta indique que, se essas informações não tiverem sido enviadas, não será atendido, dando assim a oportunidade de repetir o envio com a evidência pertinente. Isso permite relatórios automatizados, por exemplo, mediante fail2ban, S pamCop ou outros, com um custo mínimo para ambas as partes. Normalmente, espera-se que, se um número de bilhete tiver si do designado, ele será mantido em todas as comunicações (tipicamente como parte do assunto). 12.3. Objetivos da validação do "abuse-c"/"abuse-mailbox" O procedimento, que deverá ser desenvolvido por LACNIC, deve atender aos seguintes objetivos: 1) Garantir sua funcionalidade e permitir os "helpdesk" que lidam com os relatórios de abuso, a verificação de que a v alidação realmente provem de LACNIC e não de terceiras fontes (envolvendo riscos de segurança, evitando, por exemplo, um a única URL "direta" para a validação). 2) Impedir um processo exclusivamente automatizado. 3) Confirmar que quem valida: • garante conhecer o procedimento e as políticas de LACNIC • monitora regularmente o “abuse-mailbox” • toma medidas a esse respeito • responde ao relatório de abuso. 4) Prazo de validação “inicial” de 15 dias. 5) Se não for validado corretamente, “escalado” com o restante dos contatos disponíveis, em um prazo “adicional” de 1 5 dias. Os prazos de validação poderão ser modificados a critério de LACNIC, informando a comunidade dos motivos. (na forma de recomendação, propõe-se um procedimento detalhado em "informações adicionais" desta proposta de política). 12.4. Validação do "abuse-c"/"abuse-mailbox" LACNIC validará o cumprimento da política periodicamente, pelo menos duas vezes por ano, e quando os atributos "abuse-c" forem criados ou modificados. A frequência de validação poderá ser modificada a critério de LACNIC, informando a comunidade dos motivos. 12.5. Dos incumprimentos O incumprimento por parte de qualquer organização ocorre se não foi validado no prazo "inicial" ou "adicional". Isso imp licará o bloqueio de MiLACNIC e medidas equivalentes nos sistemas dos NIRs, para todos os recursos associados a essa org anização. Excluem-se as questões exclusivamente contratuais e relacionadas a pagamentos, bem como a atualização dos cont atos abuse-c/abuse-mailbox, de modo que possam ser revalidados automaticamente para permitir o desbloqueio de MiLACNIC. Qualquer acesso a MiLACNIC (ou sistemas equivalentes dos NIRs) durante o referido bloqueio, mostrará uma mensagem de avi so, incluindo o texto desta política, e para permitir continuar será necessário que essa mensagem seja "lida" até o fina l, e confirmada por meio de um check-box ou semelhante. Mecanismos equivalentes adaptados ao progresso da tecnologia pod erão ser usados. Se o incumprimento for mantido, LACNIC atuará de acordo com suas políticas e procedimentos pertinentes. 12.6. Mecanismo de escalado para LACNIC Comportamentos fraudulentos (por exemplo, "abuse-mailbox” que respondem apenas a e-mails de LACNIC, a um assunto específ ico ou corpo da mensagem) ou o incumprimento dos demais aspectos desta política (incorreta ou não atenção aos casos de a buso), poderão ser denunciados a LACNIC, para sua revalidação segundo 12.4. |
Texto atual: Não existe Texto novo: 12. Registro e validação de "abuse-c" e "abuse-mailbox" 12.1. Descrição do "abuse-c" e "abuse-mailbox" Todos os recursos que usem os sistemas de registro de LACNIC devem incluir obrigatoriamente, nas entradas do WHOIS corre spondentes, o atributo de contato abuse-c (contato de abuso) como mínimo com um e-mail abuse-mailbox válido, monitorado e devidamente atendido, que permita o envio de relatórios manuais ou automáticos de comportamentos abusivos, segurança e semelhantes. O atributo abuse-mailbox deve estar disponível sem restrições via WHOIS, APIs e futuras tecnologias. Levando em conta a natureza hierárquica dos objetos, os herdados de aqueles alocados diretamente por LACNIC (por exemplo , subdesignações), são cobertos pelos objetos de nível superior e seu próprio atributo "abuse-c” é optativo. Seguindo práticas usuais, outros atributos "e-mail" podem ser incluídos para outros fins. 12.2. Acerca do "abuse-mailbox" O “abuse-mailbox” possui as seguintes características: • Requer intervenção do destinatário. • Não deve exigir o uso de um formulário para denunciar um abuso. • Deve garantir que as denúncias de abuso, logs, cabeçalhos, exemplos etc., relacionadas ao caso de abuso, sejam rece bidas. 12.3. Objetivos da validação do "abuse-c"/"abuse-mailbox" O procedimento, que deverá ser desenvolvido pelo LACNIC, deve atender aos seguintes objetivos: 1) Processo simples que garanta sua funcionalidade e o cumprimento de sua finalidade. 2) Confirmar que quem valida: • garante conhecer o procedimento e as políticas de LACNIC • monitora regularmente o “abuse-mailbox” • toma medidas a esse respeito • responde ao relatório de abuso. 3) Prazo de validação “inicial” de 15 dias. 4) Se não for validado corretamente, escalado, por qualquer meio possível, com o restante dos contatos disponíveis, em u m prazo “adicional” de 15 dias. 12.4. Validação do "abuse-c"/"abuse-mailbox" LACNIC validará o cumprimento da política periodicamente, pelo menos duas vezes por ano, e quando os atributos "abuse-c" forem criados ou modificados. O incumprimento por parte de qualquer organização ocorre se não foi validado no prazo "inicial" ou "adicional". 12.5. Mecanismo de escalado para LACNIC Comportamentos fraudulentos (por exemplo, "abuse-mailbox” que respondem apenas a e-mails de LACNIC, a um assunto específ ico ou corpo da mensagem) ou o incumprimento dos demais aspectos desta política (incorreta ou não atenção aos casos de a buso), poderão ser denunciados a LACNIC, para sua revalidação segundo 12.4. |
Texto novo | |
Texto atual: Não existe Texto novo: 12. Registro e validação de "abuse-c" e "abuse-mailbox" 12.1. Descrição do "abuse-c" e "abuse-mailbox" Todos os recursos que usem os sistemas de registro de LACNIC devem incluir obrigatoriamente, nas entradas do WHOIS corre spondentes, o atributo de contato abuse-c (contato de abuso) como mínimo com um e-mail abuse-mailbox válido, monitorado e devidamente atendido, que permita o envio de relatórios manuais ou automáticos de comportamentos abusivos, segurança e semelhantes. O atributo abuse-mailbox deve estar disponível sem restrições via WHOIS, APIs e futuras tecnologias. Levando em conta a natureza hierárquica dos objetos, os herdados de aqueles alocados diretamente por LACNIC (por exemplo , subdesignações), estar cobertos pelos objetos de nível superior e seu próprio atributo "abuse-c” é optativo. Seguindo práticas usuais, outros atributos "e-mail" podem ser incluídos para outros fins. 12.2. Características do "abuse-mailbox" Os e-mails enviados para "abuse-mailbox" devem exigir intervenção manual em algum momento, por parte do destinatário, e não podem ser filtrados, pois isso poderia impedir, em alguns casos, a recepção de um relatório de abuso. Por exemplo, u m relatório de spam, ao incluir a própria mensagem de spam ou URLs ou conteúdos geralmente classificados como spam. A caixa de correio "abuse-mailbox" poderá enviar inicialmente uma resposta automática, por exemplo, designando um número de bilhete, aplicando procedimentos de classificação, solicitando mais informações, etc. No entanto, não poderá requere r o uso de um formulário, pois isso implicaria que cada entidade que precisar denunciar abusos, geralmente de forma auto matizada, seja forçada a desenvolver uma interface específica para cada receptor de recursos a quem tem que informar um abuso. Isso seria inviável, uma vez que faria recair o custo do processado dos abusos em quem envia a reclamação, vítima do abuso, em vez de ser pago por aquele que, direta ou indiretamente, provoca o abuso. O razoável é que quem denuncia o abuso, faça isso no primeiro relatório, enviando informações suficientes (log, cópia de spam ou cabeçalhos completos, o equivalente em cada tipo de abuso). Da mesma forma, é razoável que o e-mail inicial de auto-resposta indique que, se essas informações não tiverem sido enviadas, não será atendido, dando assim a oportunidade de repetir o envio com a evidência pertinente. Isso permite relatórios automatizados, por exemplo, mediante fail2ban, S pamCop ou outros, com um custo mínimo para ambas as partes. Normalmente, espera-se que, se um número de bilhete tiver si do designado, ele será mantido em todas as comunicações (tipicamente como parte do assunto). 12.3. Objetivos da validação do "abuse-c"/"abuse-mailbox" O procedimento, que deverá ser desenvolvido por LACNIC, deve atender aos seguintes objetivos: 1) Garantir sua funcionalidade e permitir os "helpdesk" que lidam com os relatórios de abuso, a verificação de que a v alidação realmente provem de LACNIC e não de terceiras fontes (envolvendo riscos de segurança, evitando, por exemplo, um a única URL "direta" para a validação). 2) Impedir um processo exclusivamente automatizado. 3) Confirmar que quem valida: • garante conhecer o procedimento e as políticas de LACNIC • monitora regularmente o “abuse-mailbox” • toma medidas a esse respeito • responde ao relatório de abuso. 4) Prazo de validação “inicial” de 15 dias. 5) Se não for validado corretamente, “escalado” com o restante dos contatos disponíveis, em um prazo “adicional” de 1 5 dias. Os prazos de validação poderão ser modificados a critério de LACNIC, informando a comunidade dos motivos. (na forma de recomendação, propõe-se um procedimento detalhado em "informações adicionais" desta proposta de política). 12.4. Validação do "abuse-c"/"abuse-mailbox" LACNIC validará o cumprimento da política periodicamente, pelo menos duas vezes por ano, e quando os atributos "abuse-c" forem criados ou modificados. A frequência de validação poderá ser modificada a critério de LACNIC, informando a comunidade dos motivos. 12.5. Dos incumprimentos O incumprimento por parte de qualquer organização ocorre se não foi validado no prazo "inicial" ou "adicional". Isso imp licará o bloqueio de MiLACNIC e medidas equivalentes nos sistemas dos NIRs, para todos os recursos associados a essa org anização. Excluem-se as questões exclusivamente contratuais e relacionadas a pagamentos, bem como a atualização dos cont atos abuse-c/abuse-mailbox, de modo que possam ser revalidados automaticamente para permitir o desbloqueio de MiLACNIC. Qualquer acesso a MiLACNIC (ou sistemas equivalentes dos NIRs) durante o referido bloqueio, mostrará uma mensagem de avi so, incluindo o texto desta política, e para permitir continuar será necessário que essa mensagem seja "lida" até o fina l, e confirmada por meio de um check-box ou semelhante. Mecanismos equivalentes adaptados ao progresso da tecnologia pod erão ser usados. Se o incumprimento for mantido, LACNIC atuará de acordo com suas políticas e procedimentos pertinentes. 12.6. Mecanismo de escalado para LACNIC Comportamentos fraudulentos (por exemplo, "abuse-mailbox” que respondem apenas a e-mails de LACNIC, a um assunto específ ico ou corpo da mensagem) ou o incumprimento dos demais aspectos desta política (incorreta ou não atenção aos casos de a buso), poderão ser denunciados a LACNIC, para sua revalidação segundo 12.4. |
Texto atual: Não existe Texto novo: 12. Registro e validação de "abuse-c" e "abuse-mailbox" 12.1. Descrição do "abuse-c" e "abuse-mailbox" Todos os recursos que usem os sistemas de registro de LACNIC devem incluir obrigatoriamente, nas entradas do WHOIS corre spondentes, o atributo de contato abuse-c (contato de abuso) como mínimo com um e-mail abuse-mailbox válido, monitorado e devidamente atendido, que permita o envio de relatórios manuais ou automáticos de comportamentos abusivos, segurança e semelhantes. O atributo abuse-mailbox deve estar disponível sem restrições via WHOIS, APIs e futuras tecnologias. Levando em conta a natureza hierárquica dos objetos, os herdados de aqueles alocados diretamente por LACNIC (por exemplo , subdesignações), são cobertos pelos objetos de nível superior e seu próprio atributo "abuse-c” é optativo. Seguindo práticas usuais, outros atributos "e-mail" podem ser incluídos para outros fins. 12.2. Acerca do "abuse-mailbox" O “abuse-mailbox” possui as seguintes características: • Requer intervenção do destinatário. • Não deve exigir o uso de um formulário para denunciar um abuso. • Deve garantir que as denúncias de abuso, logs, cabeçalhos, exemplos etc., relacionadas ao caso de abuso, sejam rece bidas. 12.3. Objetivos da validação do "abuse-c"/"abuse-mailbox" O procedimento, que deverá ser desenvolvido pelo LACNIC, deve atender aos seguintes objetivos: 1) Processo simples que garanta sua funcionalidade e o cumprimento de sua finalidade. 2) Confirmar que quem valida: • garante conhecer o procedimento e as políticas de LACNIC • monitora regularmente o “abuse-mailbox” • toma medidas a esse respeito • responde ao relatório de abuso. 3) Prazo de validação “inicial” de 15 dias. 4) Se não for validado corretamente, escalado, por qualquer meio possível, com o restante dos contatos disponíveis, em u m prazo “adicional” de 15 dias. 12.4. Validação do "abuse-c"/"abuse-mailbox" LACNIC validará o cumprimento da política periodicamente, pelo menos duas vezes por ano, e quando os atributos "abuse-c" forem criados ou modificados. O incumprimento por parte de qualquer organização ocorre se não foi validado no prazo "inicial" ou "adicional". 12.5. Mecanismo de escalado para LACNIC Comportamentos fraudulentos (por exemplo, "abuse-mailbox” que respondem apenas a e-mails de LACNIC, a um assunto específ ico ou corpo da mensagem) ou o incumprimento dos demais aspectos desta política (incorreta ou não atenção aos casos de a buso), poderão ser denunciados a LACNIC, para sua revalidação segundo 12.4. |
Informações adicionais | |
Nota (não deve ser incluído no manual de políticas): A seção atual “12. Apêndices "passa a ser" A. Apêndices ", no final do manual de políticas, e todas as referências a ela são renumeradas em todo o manual de políticas. Dessa forma, as novas seções do manual não requererão renumerações futur as, segundo o manual for "crescendo". O texto desta proposta torna-se, portanto, a seção 12, ou a considerada apropriada pelo pessoal no momento de sua implementação, uma vez que o consenso tenha sido alcançado. O texto a seguir é um exemplo de procedimento de validação, considerando as práticas usuais nos "helpdesk" (mesas de aju da), que, por exemplo, impedem clicar em um link html de um e-mail, para evitar casos de phishing ou outros. Mesmo quand o este texto não faz parte do texto da política, recomenda-se sua consideração estrita, uma vez que é o resultado de dis cussões relacionadas a políticas de abuse-c na comunidade global. 1) A validação começa de forma automatizada, por parte de LACNIC, com o envio de DOIS e-mails consecutivos para o "ab use-mailbox”. 2) Esses e-mails terão exclusivamente formato texto (e, portanto, ocultar URLs que correspondam a ataques como "phish ing" etc.). 3) A critério de LACNIC, de forma generalizada ou em casos específicos (por exemplo, para a confirmação em casos de e scalado de acordo com o ponto 12.6), LACNIC, poderá usar outros domínios além do lacnic.*, e inclusive modificar o assun to e corpo da mensagem, para realizar ditas validações de forma mais eficaz. 4) O primeiro dos e-mails vai conter a URL onde a validação deve ser realizada, que será "validacion.lacnic.net", e p oderá conter informações sobre o procedimento, extrato desta política, etc. 5) O segundo dos e-mails vai conter um código alfanumérico único de validação. 6) O receptor que atende o "abuse-mailbox", deverá acessar à URL e inserir no formulário o código recebido no segundo e-mail. 7) Esta URL deverá estar projetada de forma de impedir um processo automatizado (por exemplo, "captcha") e conterá um texto que confirme que o receptor da validação conhece o procedimento, a política e que monitora regularmente o "abuse- mailbox" e que são tomadas medidas adequadas para resolver os abusos relatados e responder a eles, com um "checkbox" que deverá ser necessariamente aceito. 8) O código alfanumérico apenas será válido por um máximo de 15 dias. 9) Se o código não for inserido nesse prazo, o sistema marcará o "abuse-c" como "provisoriamente inválido" e alertará a equipe de LACNIC para que possa ser iniciado o acompanhamento personalizado com o receptor do recurso. 10) No caso de não obter uma resposta com a confirmação da correção da situação, em um prazo adicional de 15 dias, o "abuse-c" será marcado de forma permanente como "inválido". 11) O processo de validação será repetido automaticamente (pontos 1 a 7 acima) e, neste caso, o "abuse-c" será marcad o como "válido" se for satisfatório, caso contrário, seria um caso de descumprimento da política. 12) LACNIC terá mecanismos (formulário, e-mail e outros no futuro) para facilitar o escalamento nos casos em que se q ueira denunciar uma violação desta política. Isso permitirá a revalidação (12.4) e a intervenção de LACNIC na aplicação das políticas, procedimentos e requisitos contratuais em vigor. |
Nota (não deve ser incluído no manual de políticas): A seção atual “12. Apêndices "passa a ser" A. Apêndices ", no final do manual de políticas, e todas as referências a ela são renumeradas em todo o manual de políticas. Dessa forma, as nov as seções do manual não requererão renumerações futuras, segundo o manual for "crescendo". O texto desta proposta torna- se, portanto, a seção 12, ou a considerada apropriada pelo pessoal no momento de sua implementação, uma vez que o consen so tenha sido alcançado. Os prazos de validação "inicial" e "escalado" podem ser modificados por LACNIC, se for considerado apropriado, desde que a comunidade seja informada sobre os motivos dessa mudança. Por exemplo, na fase inicial da implementação, esses períod os poderiam ser estendidos e ajustados progressivamente à medida que uma porcentagem maior de contatos seja verificada. Igualmente, a frequência da validação periódica pode ser modificada por LACNIC, se considerar necessário, informando tam bém à comunidade acerca dos motivos. Por exemplo, no primeiro ano, uma única validação poderia ser realizada para facili tar o cumprimento da política, e o número de validações aumentar progressivamente, talvez até trimestralmente, a fim de melhorar a qualidade dos contatos. O texto a seguir é um exemplo de procedimento de validação, considerando as práticas usuais nos "helpdesk" (mesas de aju da), que, por exemplo, impedem clicar em um link html de um e-mail, para evitar casos de phishing ou outros. Mesmo quand o este texto não faz parte do texto da política, recomenda-se sua consideração estrita, uma vez que é o resultado de dis cussões relacionadas a políticas de abuse-c na comunidade global. (Veja versão anterior, o formulário limita o número de caracteres). |
Referências | |
- |
- |