Я хотел бы отказать в archive.isдоступе к моему веб-сайту. (Я не хочу, чтобы этот сайт кэшировал мой без моего согласия).
Вы знаете, возможно ли это?
Я хотел бы отказать в archive.isдоступе к моему веб-сайту. (Я не хочу, чтобы этот сайт кэшировал мой без моего согласия).
Вы знаете, возможно ли это?
Ответы:
Ладно. Это новый (по крайней мере для меня) и довольно интересный до сих пор. Я не буду лезть в сорняки на этом.
Когда я писал это, я работал практически без сна. Я пропустил несколько вещей, на которые @unor любезно указал, и поэтому я должен умерить свой ответ и отдать должное, когда это необходимо. Спасибо @unor!
Archive.is зарегистрирован Денисом Петровым, который использует учетную запись веб-хостинга Google на IP-адресе 104.196.7.222 [AS15169 GOOGLE - Google Inc.] в соответствии с инструментами домена, хотя он у меня есть на 46.17.100.191 [AS57043 HOSTKEY-AS HOSTKEY BV]. Вполне вероятно, что принимающая компания недавно изменилась.
Archive.today также принадлежит Денису Петрову и похож на Archive.is, если не идентичен. Для целей этого ответа я обращусь к Archive.is, и вы можете предположить, что он применим к Archive.today. Archive.today существует на другом IP-адресе 78.108.190.21 [AS62160 GM-AS Да Networks Unlimited Ltd]. Пожалуйста, поймите, что Денис Петров владеет 70 доменами. Не копая глубже, вполне возможно, что есть еще сайты, о которых нужно беспокоиться. Я предоставлю код блокировки для всех трех IP-адресов.
Archive.is ориентирован на пользователя. Предполагается, что вы архивируете свою собственную страницу. Помимо этого сценария, Archive.is можно рассматривать как сайт спама для удаления содержимого.
Archive.is идет по опасной линии. Он использует контент других сайтов через одностраничную очистку. В конечном счете, поисковый потенциал оригинального контента, по крайней мере, ослаблен и потенциально узурпирован. Что еще хуже, оригинальный сайт не упоминается в качестве источника контента. Archive.is использует канонический тег, но он относится к своему сайту / странице.
Пример: <link rel="canonical" href="http://archive.is/Eo267"/>
В сочетании с отсутствием контроля над тем, кто отправляет сайт и имеют ли они право на сайт, отсутствием четкой информации о разборке и несколько нечетким и потенциально слабым механизмом контактов, Archive.is имеет потенциал для реального беда.
Вы можете узнать больше информации об IP-адресе здесь: https://www.robtex.com/#!dns=archive.is
Использование Cisco Firewall.
access-list block-78-108-190-21-32 deny ip 78.108.190.21 0.0.0.0 any
permit ip any any
** Примечание. Вы можете заменить [предоставленное имя acl] на имя ACL по вашему выбору.
Используя Nginx.
Отредактируйте nginx.conf и вставьте include blockips.conf; если его не существует Отредактируйте blockips.conf и добавьте следующее:
deny 78.108.190.21/32;
Использование Linux IPTables Firewall. ** Примечание: используйте с осторожностью.
/sbin/iptables -A INPUT -s 78.108.190.21/32 -j DROP
Использование веб-сервера 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>
Использование Apache .htaccess.
RewriteCond %{REMOTE_ADDR} ^78\.108\.190\.21$ [NC]
RewriteRule .* - [F,L]
Использование Cisco Firewall.
access-list block-46-17-100-191-32 deny ip 46.17.100.191 0.0.0.0 any
permit ip any any
** Примечание. Вы можете заменить [предоставленное имя acl] на имя ACL по вашему выбору.
Используя Nginx.
Отредактируйте nginx.conf и вставьте include blockips.conf; если его не существует Отредактируйте blockips.conf и добавьте следующее:
deny 46.17.100.191/32;
Использование Linux IPTables Firewall. ** Примечание: используйте с осторожностью.
/sbin/iptables -A INPUT -s 46.17.100.191/32 -j DROP
Использование веб-сервера 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>
Использование Apache .htaccess.
RewriteCond %{REMOTE_ADDR} ^46\.17\.100\.191$ [NC]
RewriteRule .* - [F,L]
Использование Cisco Firewall.
access-list block-104-196-7-222-32 deny ip 104.196.7.222 0.0.0.0 any
permit ip any any
** Примечание. Вы можете заменить [предоставленное имя acl] на имя ACL по вашему выбору.
Используя Nginx.
Отредактируйте nginx.conf и вставьте include blockips.conf; если его не существует Отредактируйте blockips.conf и добавьте следующее:
deny 104.196.7.222/32;
Использование Linux IPTables Firewall. ** Примечание: используйте с осторожностью.
/sbin/iptables -A INPUT -s 104.196.7.222/32 -j DROP
Использование веб-сервера 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>
Использование Apache .htaccess.
RewriteCond %{REMOTE_ADDR} ^104\.196\.7\.222$ [NC]
RewriteRule .* - [F,L]
Вам может потребоваться заблокировать более одного IP-адреса из любого набора кода. Это не ясно.
archive.org loses copyright lawsuitПохоже, Google не опубликовал соответствующие статьи о решениях.
robots.txtArchive.is не использует бота, который сканирует страницы автономно (например, по гиперссылкам), поэтому robots.txtне применяется, потому что это всегда пользователь, который дает команду для архивирования определенной страницы.
По той же причине такие службы, как Feedfetcher от Google ( почему Feedfetcher не подчиняется моему файлу robots.txt? ) И Validator от W3C ( подробности ) не подчиняются robots.txt.
См. Archive.is FAQ: Почему archive.is не подчиняется robots.txt?
meta- robots/X-Robots-TagЯ не уверен, должен ли archive.is (в идеале) учитывать значение noindexили noarchiveв meta- robots/ X-Robots-Tagили эти технологии также применимы только к автономным ботам. Но так как archive.is не документирует это, они, похоже, не поддерживают его в настоящее время.
(FWIW, каждая заархивированная страница, кажется, получает <meta name="robots" content="index,noarchive"/>.)
User-Agentarchive.is не документирует, что определенное User-Agentиспользуется (они, вероятно, не идентифицируют себя, чтобы получить страницы, как если бы они просматривались обычным браузером), поэтому вы не можете использовать его, чтобы заблокировать их доступ на уровне сервера ,
Так как ни, robots.txtни meta- robots/ X-Robots-Tagздесь работают, и вы не можете заблокировать их через их User-Agent, вам придется блокировать доступы с IP-адресов archive.is. Посмотрите ответ closetnoc о блокировке IP-адресов , но обратите внимание, что это может блокировать больше, чем предполагалось, и вы можете никогда не перехватить все их IP-адреса (и / или не обновлять их).
Каждая заархивированная версия ссылается на форму, где вы можете сообщить о возможных злоупотреблениях (добавить /abuse), например, по причинам «SEO Issue» или «Copyright». Но я не знаю, как они справляются с этими случаями.
Чтобы заблокировать отвратительные методы кражи файла archive.is (игнорирование robots.txt, переопределение канонической ссылки, поддельный пользовательский агент, отсутствие способа удаления всего сайта), я хочу добавить следующее к вышеупомянутым решениям.
Чтобы найти их ip-адреса, отправьте им URL-адрес, который находится под вашим контролем, чтобы вы могли отслеживать журналы веб-сервера, чтобы узнать, кто обращался к нему по этому URL-адресу. URL даже не должен существовать, пока веб-сервер получает запрос. (Так что лучше использовать несуществующую пустую страницу / URL.) Например, используйте URL-адрес, например: http://example.com/fuck-you-archive.is
Затем проверьте свои журналы, чтобы увидеть, кто получил доступ к URL. Вы можете использовать grep, чтобы проверить это:
grep "fuck-you-archive.is" web-server-log.txt
Получив IP-адрес, вы можете заблокировать его, используя решения из других ответов. А затем повторите процедуру еще раз, чтобы найти другие IP-адреса, которые они используют. Вам нужно указать другой URL-адрес, чтобы они снова выполняли HTTP-запрос, например, просто измените http://example.com/fuck-you-archive.is на http://example.com/fuck-you- archive.is?2 и т. д.
Если вы вообще не хотите показывать свой веб-сайт при попытке найти их IP-адреса, вы можете использовать этот удобный веб-сайт HTTP-запроса: https://requestb.in Шаги, которые необходимо выполнить: создать RequestBin> отправить «BinURL» в Archive.is с «? SomeRandomNumber», добавленным к BinURL> использовать «? inspect» RequestBin для отслеживания входящего запроса из Archive.is и увидеть их IP-адрес в «Cf-Connecting-Ip» "Заголовок HTTP. (Убедитесь, что вы не отправляете «? Inspect» url в Archive.is.) Повторите, чтобы найти другие IP-адреса, изменив «? SomeRandomNumber» на другой номер.
Обратите внимание, что с IP-таблицами вы можете заблокировать с помощью
/sbin/iptables -A INPUT -s 78.108.190.21 -j DROP
но часто для цепочки INPUT устанавливается политика DROP с принятием HTTP-трафика. В этом случае вам может потребоваться использовать операцию добавления (вставки) вместо операции добавления, в противном случае она вообще не блокируется:
/sbin/iptables -I INPUT -s 78.108.190.21 -j DROP
Однако у них много IP-адресов, поэтому может быть проще заблокировать полные IP-диапазоны. Это удобно сделать с помощью IPTables (без указания масок подсетей), используя:
iptables -I INPUT -m iprange --src-range 46.166.139.110-46.166.139.180 -j DROP
Этот диапазон (46.166.139.110-46.166.139.180) по большей части принадлежит им, потому что я видел несколько адресов между 46.166.139.110 и 46.166.139.173.
В настоящее время они используют NFOrce в качестве веб-хостинга. См. Https://www.nforce.com/abuse, чтобы узнать, как подать жалобу на Archive.is. Упомяните: 1) URL-адрес вашей веб-страницы, который украл archive.is, 2) упомяните URL-адрес на archive.is, который содержит украденный контент, и 3) укажите IP-адреса, которые они использовали.
Также вы можете подать жалобу в Cloudflare, их CDN, который кэширует их украденные страницы и изображения по соображениям производительности. https://www.cloudflare.com/abuse/
Как мы видим, archive.is использует DNS anycasting.
Если вы используете разные серверы имен (например, с https://www.lifewire.com/free-and-public-dns-servers-2626062 ), вы в настоящее время (2018-09-10) получаете разные IP-адреса для «archive.is» ( копаем @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
Я использовал abuse-contacts.abusix.org ( https://www.abusix.com/contactdb ), чтобы получить контакты для злоупотреблений по следующим 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
Как сообщает Cloudflare, archive.is злоупотребляет своими «услугами», используя А-запись DNS, которая не имеет никакой функциональности!
Также рассмотрите возможность обращения к регистраторам по адресу www.isnic.is, Исландский реестр доменов. isnic на isnic точка является
В Исландии действует закон об авторском праве, и Секретариат признает его. Реестр существует с конца 1980-х годов и не находится под управлением ICANN.