Câu trả lời:
Được chứ. Đây là một cái mới (ít nhất là với tôi) và khá thú vị cho đến nay. Tôi sẽ không nhận được cỏ dại về điều này.
Khi tôi viết bài này, tôi đang làm việc rất ít hoặc không ngủ. Tôi đã bỏ lỡ một vài điều mà @unor đã vui lòng chỉ ra và vì vậy tôi phải tiết chế câu trả lời của mình và cung cấp tín dụng khi tín dụng đáo hạn. Cảm ơn bạn @unor!
Archive.is được đăng ký với Denis Petrov, người đang sử dụng tài khoản Google webhost trên địa chỉ IP 104.196.7.222 [AS15169 GOOGLE - Google Inc.] theo Domain Tools mặc dù tôi có nó trên 46.17.100.191 [AS57043 HOSTKEY-AS HOSTKEY BV]. Có khả năng công ty chủ quản gần đây đã thay đổi.
Archive.today cũng thuộc sở hữu của Denis Petrov và tương tự như Archive.is nếu không giống hệt. Với mục đích của câu trả lời này, tôi sẽ giải quyết Archive.is và bạn có thể giả sử rằng nó áp dụng cho Archive.today. Archive.today không tồn tại trên một địa chỉ IP khác 78.108.190.21 [AS62160 GM-AS Yes Networks Unlimited Ltd]. Xin hãy hiểu rằng Denis Petrov sở hữu 70 tên miền. Nếu không đào sâu hơn, có thể có nhiều trang web cần quan tâm hơn. Tôi sẽ cung cấp mã chặn cho cả ba địa chỉ IP.
Archive.is là hướng dẫn sử dụng. Giả định rằng bạn đang lưu trữ trang của riêng bạn. Khác với kịch bản này, Archive.is có thể được coi là một trang web spam nội dung.
Archive.is đang đi một đường nguy hiểm. Nó đang sử dụng nội dung trang web khác thông qua việc quét trang đơn. Cuối cùng, tiềm năng tìm kiếm của nội dung ban đầu ít nhất bị pha loãng và có khả năng chiếm đoạt hoàn toàn. Tệ hơn nữa, trang web gốc không được trích dẫn là người khởi tạo nội dung. Archive.is sử dụng thẻ chính tắc, nhưng đó là trang web / trang riêng của nó.
Thí dụ: <link rel="canonical" href="http://archive.is/Eo267"/>
Điều này cùng với việc thiếu kiểm soát ai đang gửi trang web và liệu họ có quyền truy cập trang web hay không, thiếu thông tin gỡ xuống rõ ràng và cơ chế liên hệ hơi mờ và có khả năng yếu, Archive.is có tiềm năng thực sự rắc rối.
Bạn có thể tìm hiểu thêm thông tin địa chỉ IP tại đây: https://www.robtex.com/#!dns=archive.is
Sử dụng Tường lửa của Cisco.
access-list block-78-108-190-21-32 deny ip 78.108.190.21 0.0.0.0 any
permit ip any any
** Lưu ý: Bạn có thể thay thế [tên acl được cung cấp] bằng tên ACL bạn chọn.
Sử dụng Nginx.
Chỉnh sửa nginx.conf và chèn bao gồm blockips.conf; nếu nó không tồn tại Chỉnh sửa blockips.conf và thêm vào như sau:
deny 78.108.190.21/32;
Sử dụng tường lửa IPTables Linux. ** Lưu ý: Sử dụng thận trọng.
/sbin/iptables -A INPUT -s 78.108.190.21/32 -j DROP
Sử dụng máy chủ 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>
Sử dụng Apache .htaccess.
RewriteCond %{REMOTE_ADDR} ^78\.108\.190\.21$ [NC]
RewriteRule .* - [F,L]
Sử dụng Tường lửa của Cisco.
access-list block-46-17-100-191-32 deny ip 46.17.100.191 0.0.0.0 any
permit ip any any
** Lưu ý: Bạn có thể thay thế [tên acl được cung cấp] bằng tên ACL bạn chọn.
Sử dụng Nginx.
Chỉnh sửa nginx.conf và chèn bao gồm blockips.conf; nếu nó không tồn tại Chỉnh sửa blockips.conf và thêm vào như sau:
deny 46.17.100.191/32;
Sử dụng tường lửa IPTables Linux. ** Lưu ý: Sử dụng thận trọng.
/sbin/iptables -A INPUT -s 46.17.100.191/32 -j DROP
Sử dụng máy chủ 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>
Sử dụng Apache .htaccess.
RewriteCond %{REMOTE_ADDR} ^46\.17\.100\.191$ [NC]
RewriteRule .* - [F,L]
Sử dụng Tường lửa của Cisco.
access-list block-104-196-7-222-32 deny ip 104.196.7.222 0.0.0.0 any
permit ip any any
** Lưu ý: Bạn có thể thay thế [tên acl được cung cấp] bằng tên ACL bạn chọn.
Sử dụng Nginx.
Chỉnh sửa nginx.conf và chèn bao gồm blockips.conf; nếu nó không tồn tại Chỉnh sửa blockips.conf và thêm vào như sau:
deny 104.196.7.222/32;
Sử dụng tường lửa IPTables Linux. ** Lưu ý: Sử dụng thận trọng.
/sbin/iptables -A INPUT -s 104.196.7.222/32 -j DROP
Sử dụng máy chủ 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>
Sử dụng Apache .htaccess.
RewriteCond %{REMOTE_ADDR} ^104\.196\.7\.222$ [NC]
RewriteRule .* - [F,L]
Bạn có thể cần chặn nhiều hơn một địa chỉ IP từ bất kỳ bộ mã nào. Điều đó không rõ ràng.
archive.org loses copyright lawsuitdường như không đưa ra các bài viết liên quan về các phán quyết.
robots.txtArchive.is không sử dụng bot tự động thu thập dữ liệu các trang (ví dụ: bằng cách theo các siêu liên kết), vì vậy robots.txtkhông áp dụng, vì đó luôn là người dùng đưa ra lệnh để lưu trữ một trang nhất định.
Vì lý do tương tự, các dịch vụ như Feedfetcher của Google ( Tại sao Feedfetcher không tuân theo tệp robot.txt của tôi? ) Và Trình xác thực ( chi tiết ) của W3C không tuân theo robots.txt.
Xem kho lưu trữ. Câu hỏi thường gặp: Tại sao archive.is không tuân theo robot.txt?
meta- robots/X-Robots-TagTôi không chắc là archive.is (lý tưởng) nên tôn trọng noindexhoặc noarchivegiá trị trong meta- robots/ X-Robots-Taghoặc nếu các công nghệ này cũng chỉ áp dụng cho các bot tự trị. Nhưng như archive.is không tài liệu này, họ dường như không hỗ trợ nó hiện tại.
(FWIW, mỗi trang lưu trữ dường như có được một <meta name="robots" content="index,noarchive"/>.)
User-Agentarchive.is không tài liệu rằng một số nhất định User-Agentđược sử dụng (có thể họ không nhận dạng chính họ, để có được các trang như thể được xem bởi một trình duyệt thông thường), vì vậy bạn không thể sử dụng nó để chặn truy cập của họ ở cấp độ máy chủ .
Vì vậy, khi không phải robots.txtvà cũng không meta- robots/ X-Robots-Taglàm việc ở đây, và bạn không thể chặn chúng thông qua họ User-Agent, bạn sẽ phải chặn truy cập từ archive.is IP. Xem câu trả lời của Closnoc về việc chặn IP , nhưng lưu ý rằng điều này có thể chặn nhiều hơn dự định và bạn có thể không bao giờ bắt được tất cả IP của họ (và / hoặc cập nhật).
Mỗi phiên bản lưu trữ liên kết đến một biểu mẫu nơi bạn có thể báo cáo lạm dụng có thể xảy ra (chắp thêm /abuse), ví dụ: với lý do "Vấn đề SEO" hoặc "Bản quyền". Nhưng tôi không biết nếu họ xử lý những trường hợp này.
Để chặn các hành vi ăn cắp kinh tởm của archive.is (bỏ qua robot.txt, ghi đè liên kết chính tắc, tác nhân người dùng giả mạo, không có cách nào để thực hiện xóa toàn bộ trang web), tôi muốn thêm các giải pháp sau vào các giải pháp ở trên.
Để tìm địa chỉ IP của họ, hãy gửi url cho họ dưới sự kiểm soát của bạn để bạn có thể theo dõi nhật ký máy chủ web của mình để xem ai đã truy cập url đó. Url thậm chí không tồn tại, miễn là máy chủ web nhận được yêu cầu. (Vì vậy, tốt hơn là sử dụng một trang / url trống không tồn tại.) Ví dụ: sử dụng một url như: http://example.com/fuck-you-archive.is
Sau đó kiểm tra nhật ký của bạn để xem ai đã truy cập url. Bạn có thể sử dụng grep để kiểm tra nó:
grep "fuck-you-archive.is" web-server-log.txt
Khi bạn có địa chỉ IP, bạn có thể chặn nó bằng các giải pháp từ các câu trả lời khác. Và sau đó lặp lại quy trình một lần nữa để tìm địa chỉ IP khác mà họ sử dụng. Bạn cần chỉ định một url khác, để khiến họ thực hiện lại yêu cầu HTTP, ví dụ, chỉ cần thay đổi http://example.com/fuck-you-archive.is thành http://example.com/fuck-you- archive.is?2, v.v.
Trong trường hợp bạn hoàn toàn không muốn tiết lộ trang web của mình khi cố gắng tìm địa chỉ IP của họ, bạn có thể muốn sử dụng trang web yêu cầu HTTP tiện dụng này: https://requestb.in Các bước để thực hiện là: tạo RequestBin> gửi "BinURL" cho Archive.is với "? someRandomNumber" được gắn vào BinURL> sử dụng "? Kiểm tra" của RequestBin để theo dõi yêu cầu đến từ Archive.is và xem địa chỉ IP của họ trong "Cf-Connection-Ip "Tiêu đề HTTP. (Đảm bảo rằng bạn không gửi url "? Kiểm tra" cho Archive.is.) Lặp lại để tìm địa chỉ IP khác bằng cách thay đổi "? Một sốRandomNumber" sang một số khác.
Lưu ý rằng với các bảng IP, bạn có thể chặn bằng cách sử dụng
/sbin/iptables -A INPUT -s 78.108.190.21 -j DROP
nhưng thường thì chuỗi 'INPUT' được đặt thành chính sách 'DROP' với sự chấp nhận lưu lượng HTTP. Trong trường hợp đó, bạn có thể cần phải sử dụng thao tác trả trước (chèn) thay vì thao tác nối thêm, nếu không nó hoàn toàn không bị chặn:
/sbin/iptables -I INPUT -s 78.108.190.21 -j DROP
Tuy nhiên, họ có rất nhiều địa chỉ IP, do đó có thể dễ dàng hơn để chặn các dải IP hoàn chỉnh. Bạn có thể thực hiện việc này một cách thuận tiện với IPTables (không cần chỉ định mạng con) bằng cách sử dụng:
iptables -I INPUT -m iprange --src-range 46.166.139.110-46.166.139.180 -j DROP
Phạm vi này (46.166.139.110-46.166.139.180) dành cho một phần lớn thuộc sở hữu của họ, vì tôi đã thấy nhiều địa chỉ trong khoảng từ 46.166.139.110 đến 46.166.139.173.
Họ hiện đang sử dụng NFOrce làm máy chủ web. Xem https://www.nforce.com/abuse để biết cách khiếu nại về Archive.is. Đề cập: 1) url trang web của bạn mà archive.is đã bị đánh cắp, 2) đề cập đến url tại archive.is có chứa nội dung bị đánh cắp và 3) đề cập đến các địa chỉ IP mà họ đã sử dụng.
Ngoài ra, bạn có thể muốn khiếu nại tại Cloudflare, CDN của họ, lưu trữ các trang và hình ảnh bị đánh cắp của họ vì lý do hiệu suất. https://www.cloudflare.com/abuse/
Như chúng ta có thể thấy, archive.is đang sử dụng DNS anycasting.
Nếu bạn sử dụng các máy chủ tên khác nhau (ví dụ: từ https://www.lifewire.com/free-and-public-dns-servers-2626062 ), bạn hiện tại (2018-09-10) nhận các địa chỉ IP khác nhau cho "archive.is" ( đào @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
Tôi đã sử dụng lạm dụng-contacts.abusix.org ( https://www.abusix.com/contactdb ) để nhận các liên hệ lạm dụng cho các địa chỉ IP này:
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
Như Cloudflare đã báo cáo, archive.is đang lạm dụng "dịch vụ" của họ bằng cách sử dụng bản ghi DNS A không có chức năng!
Đồng thời xem xét Liên hệ với các nhà đăng ký tại www.isnic.is, Cơ quan đăng ký tên miền của Iceland. isnic tại dấu chấm isnic là
Iceland có luật bản quyền và Cơ quan đăng ký công nhận nó. Cơ quan đăng ký đã tồn tại từ cuối những năm 1980 và không thuộc ICANN.