Eu gostaria de negar o archive.isacesso ao meu site. (Não quero que este site armazene em cache o meu sem o meu consentimento).
Você sabe se é possível?
Eu gostaria de negar o archive.isacesso ao meu site. (Não quero que este site armazene em cache o meu sem o meu consentimento).
Você sabe se é possível?
Respostas:
OK. Este é um novo (pelo menos para mim) e bastante interessante até agora. Eu não vou entrar no mato sobre isso.
Quando escrevi isso, estava trabalhando com pouco ou nenhum sono. Perdi algumas coisas que a @unor indicou gentilmente e, portanto, devo moderar minha resposta e dar crédito onde o crédito é devido. Obrigado @unor!
O Archive.is está registrado em Denis Petrov, que está usando uma conta de host do Google no endereço IP 104.196.7.222 [AS15169 GOOGLE - Google Inc.] de acordo com as Ferramentas de Domínio, embora eu o possua em 46.17.100.191 [AS57043 HOSTKEY-AS HOSTKEY BV]. É provável que a empresa anfitriã tenha mudado recentemente.
O Archive.today também pertence a Denis Petrov e é semelhante ao Archive.is, se não for idêntico. Para os fins desta resposta, irei abordar Archive.is e você pode assumir que se aplica a Archive.today. Hoje existe Archive.tho em outro endereço IP 78.108.190.21 [AS62160 GM-AS Yes Networks Unlimited Ltd]. Por favor, entenda que Denis Petrov possui 70 domínios. Sem se aprofundar, é possível que haja mais sites com os quais se preocupar. Fornecerei código de bloqueio para todos os três endereços IP.
Archive.is é direcionado ao usuário. Supõe-se que você esteja arquivando sua própria página. Além desse cenário, o Archive.is pode ser considerado como um site de spam do raspador de conteúdo.
Archive.is está caminhando em uma linha perigosa. Ele está usando o conteúdo de outros sites por meio de raspagem de página única. Por fim, o potencial de pesquisa do conteúdo original é pelo menos diluído e potencialmente usurpado por completo. Pior ainda, o site original não é citado como o criador do conteúdo. Archive.is usa uma tag canônica, mas é para seu próprio site / página.
Exemplo: <link rel="canonical" href="http://archive.is/Eo267"/>
Isso combinado com a falta de controle sobre quem está enviando um site e se eles têm direito ao site, a falta de informações claras sobre retirada e o mecanismo de contato um tanto confuso e potencialmente fraco, o Archive.is tem o potencial de ser real problema.
Você pode encontrar mais informações sobre o endereço IP aqui: https://www.robtex.com/#!dns=archive.is
Usando o firewall da Cisco.
access-list block-78-108-190-21-32 deny ip 78.108.190.21 0.0.0.0 any
permit ip any any
** Nota: Você pode substituir o [nome da ACL fornecido] pelo nome da ACL de sua escolha.
Usando o Nginx.
Edite nginx.conf e insira include blockips.conf; se não existir. Edite o arquivo blockips.conf e adicione o seguinte:
deny 78.108.190.21/32;
Usando o Linux IPTables Firewall. ** Nota: Use com cuidado.
/sbin/iptables -A INPUT -s 78.108.190.21/32 -j DROP
Usando o servidor Web Microsoft IIS
<rule name="abort ip address block 78.108.190.21/32" stopProcessing="true">
<match url=".*" />
<conditions>
<add input="{REMOTE_ADDR}" pattern="^78\.108\.190\.21$" />
</conditions>
<action type="AbortRequest" />
</rule>
Usando o Apache .htaccess.
RewriteCond %{REMOTE_ADDR} ^78\.108\.190\.21$ [NC]
RewriteRule .* - [F,L]
Usando o firewall da Cisco.
access-list block-46-17-100-191-32 deny ip 46.17.100.191 0.0.0.0 any
permit ip any any
** Nota: Você pode substituir o [nome da ACL fornecido] pelo nome da ACL de sua escolha.
Usando o Nginx.
Edite nginx.conf e insira include blockips.conf; se não existir. Edite o arquivo blockips.conf e adicione o seguinte:
deny 46.17.100.191/32;
Usando o Linux IPTables Firewall. ** Nota: Use com cuidado.
/sbin/iptables -A INPUT -s 46.17.100.191/32 -j DROP
Usando o servidor Web Microsoft IIS
<rule name="abort ip address block 46.17.100.191/32" stopProcessing="true">
<match url=".*" />
<conditions>
<add input="{REMOTE_ADDR}" pattern="^46\.17\.100\.191$" />
</conditions>
<action type="AbortRequest" />
</rule>
Usando o Apache .htaccess.
RewriteCond %{REMOTE_ADDR} ^46\.17\.100\.191$ [NC]
RewriteRule .* - [F,L]
Usando o firewall da Cisco.
access-list block-104-196-7-222-32 deny ip 104.196.7.222 0.0.0.0 any
permit ip any any
** Nota: Você pode substituir o [nome da ACL fornecido] pelo nome da ACL de sua escolha.
Usando o Nginx.
Edite nginx.conf e insira include blockips.conf; se não existir. Edite o arquivo blockips.conf e adicione o seguinte:
deny 104.196.7.222/32;
Usando o Linux IPTables Firewall. ** Nota: Use com cuidado.
/sbin/iptables -A INPUT -s 104.196.7.222/32 -j DROP
Usando o servidor Web Microsoft IIS
<rule name="abort ip address block 104.196.7.222/32" stopProcessing="true">
<match url=".*" />
<conditions>
<add input="{REMOTE_ADDR}" pattern="^104\.196\.7\.222$" />
</conditions>
<action type="AbortRequest" />
</rule>
Usando o Apache .htaccess.
RewriteCond %{REMOTE_ADDR} ^104\.196\.7\.222$ [NC]
RewriteRule .* - [F,L]
Pode ser necessário bloquear mais de um endereço IP de qualquer conjunto de códigos. Isso não está claro.
archive.org loses copyright lawsuitnão parecia apresentar artigos relevantes sobre decisões.
robots.txtO Archive.is não usa um bot que rastreia páginas de forma autônoma (por exemplo, seguindo os hiperlinks), portanto robots.txtnão se aplica, porque é sempre um usuário que dá o comando para arquivar uma determinada página.
Pelo mesmo motivo, serviços como o Feedfetcher do Google ( por que o Feedfetcher não está obedecendo ao meu arquivo robots.txt? ) E o Validator ( detalhes ) do W3C não obedecem robots.txt.
Consulte a FAQ do archive.is: Por que o archive.is não obedece ao robots.txt?
meta- robots/X-Robots-TagNão tenho certeza se archive.is deve (idealmente) honrar noindexou noarchivevalor em meta- robots/ X-Robots-Tag, ou se essas tecnologias também se aplicam apenas a bots autônomos. Mas como o archive.is não o documenta, eles não parecem suportá-lo atualmente.
(FWIW, cada página arquivada parece ter um <meta name="robots" content="index,noarchive"/>.)
User-Agentarchive.is não documenta que um determinado item User-Agenté usado (eles provavelmente não se identificam, para obter as páginas como se fossem vistas por um navegador comum), então você não pode usá-lo para bloquear o acesso deles no nível do servidor .
Portanto, como nem robots.txtnem meta- robots/ X-Robots-Tagfuncionam aqui, e você não pode bloqueá-los através deles User-Agent, você teria que bloquear acessos de IPs archive.is. Consulte a resposta do closetnoc sobre bloqueio de IP , mas observe que isso pode bloquear mais do que o pretendido e você nunca pode pegar todos os IPs (e / ou manter-se atualizado).
Cada versão arquivada é vinculada a um formulário no qual você pode denunciar um possível abuso (anexar /abuse), por exemplo, com os motivos "Problema de SEO" ou "Direitos autorais". Mas não sei se ou como eles lidam com esses casos.
Para bloquear as práticas repugnantes de roubo de archive.is (ignorando o robots.txt, substituindo o link canônico, o agente do usuário falso, sem maneira de executar uma remoção em todo o site), desejo adicionar o seguinte às soluções acima.
Para encontrar seus endereços IP, envie um URL para eles que esteja sob seu controle, para que você possa monitorar os logs do servidor da Web para ver quem acessou esse URL. O URL nem precisa existir, desde que o servidor da Web receba a solicitação. (Portanto, é melhor usar uma página / URL vazia inexistente.) Por exemplo, use uma URL como: http://example.com/fuck-you-archive.is
Em seguida, verifique seus logs para ver quem acessou o URL. Você pode usar o grep para verificá-lo:
grep "fuck-you-archive.is" web-server-log.txt
Depois de ter o endereço IP, você pode bloqueá-lo usando as soluções das outras respostas. E repita o processo novamente para encontrar outros endereços IP que eles usam. Você precisa especificar um URL diferente, para fazê-los executar uma solicitação HTTP novamente, por exemplo, basta alterar http://example.com/fuck-you-archive.is para http://example.com/fuck-you- archive.is?2 etc.
Caso você não queira expor seu site de maneira alguma ao tentar encontrar seus endereços IP, convém usar este útil site de solicitação de HTTP: https://requestb.in As etapas a serem executadas são: criar um RequestBin> envie o "BinURL" para Archive.is com "? SomeRandomNumber" anexado ao BinURL> use o "? inspecionar" do RequestBin para monitorar a solicitação de entrada do Archive.is e ver o endereço IP no "Cf-Connecting-Ip "Cabeçalho HTTP. (Certifique-se de não enviar o URL "? Inspecionar" para Archive.is.) Em seguida, repita para encontrar outros endereços IP alterando "? SomeRandomNumber" para outro número.
Observe que, com as tabelas IP, você pode bloquear o uso
/sbin/iptables -A INPUT -s 78.108.190.21 -j DROP
mas geralmente a cadeia 'INPUT' é definida como uma política 'DROP' com aceitação do tráfego HTTP. Nesse caso, pode ser necessário usar uma operação de pré-adição (inserção) em vez da operação de adição, caso contrário, ela não será bloqueada:
/sbin/iptables -I INPUT -s 78.108.190.21 -j DROP
No entanto, eles têm muitos endereços IP, portanto, pode ser mais fácil bloquear intervalos IP completos. Você pode fazer isso convenientemente com o IPTables (sem a necessidade de especificar sub-máscaras) usando:
iptables -I INPUT -m iprange --src-range 46.166.139.110-46.166.139.180 -j DROP
Esse intervalo (46.166.139.110-46.166.139.180) pertence em grande parte a eles, porque eu vi vários endereços entre 46.166.139.110 e 46.166.139.173.
No momento, eles estão usando o NFOrce como host da web. Consulte https://www.nforce.com/abuse para saber como fazer uma reclamação sobre o Archive.is. Mencione: 1) o URL da sua página da Web que o archive.is roubou, 2) mencione o URL em archive.is que contém o conteúdo roubado e 3) mencione os endereços IP que eles usaram.
Você também pode reclamar na Cloudflare, sua CDN, que armazena em cache as páginas e imagens roubadas por motivos de desempenho. https://www.cloudflare.com/abuse/
Como podemos ver, o archive.is está usando o anycasting de DNS.
Se você usa servidores de nomes diferentes (por exemplo, de https://www.lifewire.com/free-and-public-dns-servers-2626062 ), atualmente (10/09/2018) obtém endereços IP diferentes para "archive.is" ( dig @NAMESERVER archive.is A)
104.27.170.40
104.27.171.40
154.59.112.68
185.219.42.148
46.105.75.102
46.17.42.43
46.182.19.43
46.45.185.30
80.211.3.180
81.7.17.119
91.121.82.32
91.219.236.183
94.16.117.236
Usei abuse-contacts.abusix.org ( https://www.abusix.com/contactdb ) para obter os contatos de abuso desses endereços IP:
abuse@as42926.net
abuse@cloudflare.com
abuse@cogentco.com
abuse@isppro.de
abuse@nbiserv.de
abuse@netcup.de
abuse@ovh.net
abuse@serverastra.com
abuse@staff.aruba.it
abuseto@adminvps.ru
noc@baxet.ru
Como o Cloudflare relatou, o archive.is está abusando de seus "serviços" usando um registro A do DNS que não tem funcionalidade!
Considere também entrar em contato com os registradores em www.isnic.is, registro de domínio da Islândia. isnic no ponto isnic é
A Islândia tem lei de direitos autorais e o Registro a reconhece. O registro existe desde o final dos anos 80 e não está sob a ICANN.