Vorrei negare archive.isdi avere accesso al mio sito web. (Non voglio che questo sito Web memorizzi nella cache il mio senza il mio consenso).
Sai se è possibile?
Vorrei negare archive.isdi avere accesso al mio sito web. (Non voglio che questo sito Web memorizzi nella cache il mio senza il mio consenso).
Sai se è possibile?
Risposte:
Va bene. Questo è nuovo (almeno per me) e finora abbastanza interessante. Non entrerò nelle erbacce su questo.
Quando ho scritto questo, stavo lavorando a dormire poco o niente. Ho perso alcune cose che @unor ha gentilmente sottolineato e quindi devo temperare la mia risposta e dare credito quando il credito è dovuto. Grazie @unor!
Archive.is è registrato su Denis Petrov che sta utilizzando un account webhost di Google all'indirizzo IP 104.196.7.222 [AS15169 GOOGLE - Google Inc.] secondo Domain Tools anche se ce l'ho il 46.17.100.191 [AS57043 HOSTKEY-AS HOSTKEY BV]. È probabile che la società ospitante sia cambiata di recente.
Archive.today è anche di proprietà di Denis Petrov ed è simile a Archive.is se non identico. Ai fini di questa risposta, mi rivolgerò a Archive.is e puoi presumere che si applichi a Archive.today. Archive.today esiste su un altro indirizzo IP 78.108.190.21 [AS62160 GM-AS Sì Networks Unlimited Ltd]. Per favore, comprendi che Denis Petrov possiede 70 domini. Senza scavare più a fondo, è possibile che ci siano più siti di cui preoccuparsi. Fornirò il codice di blocco per tutti e tre gli indirizzi IP.
Archive.is è diretto dall'utente. Si presume che tu stia archiviando la tua pagina. Oltre a questo scenario, Archive.is può essere considerato come un sito di spam con raschietto contenuto.
Archive.is sta camminando su una linea pericolosa. Sta utilizzando il contenuto di altri siti tramite lo scraping di singole pagine. In definitiva, il potenziale di ricerca del contenuto originale è almeno diluito e potenzialmente completamente usurpato. Peggio ancora, il sito originale non è citato come il creatore del contenuto. Archive.is utilizza un tag canonico, ma è sul proprio sito / pagina.
Esempio: <link rel="canonical" href="http://archive.is/Eo267"/>
Questo, insieme alla mancanza di controlli su chi sta inviando un sito e se hanno il diritto al sito, la mancanza di chiare informazioni di rimozione e il meccanismo di contatto un po 'confuso e potenzialmente debole, Archive.is ha il potenziale per guaio.
Puoi trovare ulteriori informazioni sull'indirizzo IP qui: https://www.robtex.com/#!dns=archive.is
Utilizzo di 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
** Nota: è possibile sostituire il [nome acl fornito] con il nome ACL desiderato.
Usando Nginx.
Modifica nginx.conf e inserisci include blockips.conf; se non esiste. Modifica blockips.conf e aggiungi quanto segue:
deny 78.108.190.21/32;
Utilizzo di Linux IPTables Firewall. ** Nota: utilizzare con cautela.
/sbin/iptables -A INPUT -s 78.108.190.21/32 -j DROP
Utilizzo del server 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>
Utilizzando Apache .htaccess.
RewriteCond %{REMOTE_ADDR} ^78\.108\.190\.21$ [NC]
RewriteRule .* - [F,L]
Utilizzo di 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
** Nota: è possibile sostituire il [nome acl fornito] con il nome ACL desiderato.
Usando Nginx.
Modifica nginx.conf e inserisci include blockips.conf; se non esiste. Modifica blockips.conf e aggiungi quanto segue:
deny 46.17.100.191/32;
Utilizzo di Linux IPTables Firewall. ** Nota: utilizzare con cautela.
/sbin/iptables -A INPUT -s 46.17.100.191/32 -j DROP
Utilizzo del server 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>
Utilizzando Apache .htaccess.
RewriteCond %{REMOTE_ADDR} ^46\.17\.100\.191$ [NC]
RewriteRule .* - [F,L]
Utilizzo di 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
** Nota: è possibile sostituire il [nome acl fornito] con il nome ACL desiderato.
Usando Nginx.
Modifica nginx.conf e inserisci include blockips.conf; se non esiste. Modifica blockips.conf e aggiungi quanto segue:
deny 104.196.7.222/32;
Utilizzo di Linux IPTables Firewall. ** Nota: utilizzare con cautela.
/sbin/iptables -A INPUT -s 104.196.7.222/32 -j DROP
Utilizzo del server 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>
Utilizzando Apache .htaccess.
RewriteCond %{REMOTE_ADDR} ^104\.196\.7\.222$ [NC]
RewriteRule .* - [F,L]
Potrebbe essere necessario bloccare più di un indirizzo IP da qualsiasi set di codice. Questo non è chiaro
archive.org loses copyright lawsuitnon sembra aver pubblicato articoli pertinenti sulle sentenze.
robots.txtArchive.is non utilizza un bot che esegue autonomamente la scansione delle pagine (ad esempio, seguendo i collegamenti ipertestuali), quindi robots.txtnon si applica, poiché è sempre un utente a dare il comando di archiviare una determinata pagina.
Per lo stesso motivo, servizi come Feedfetcher di Google ( Perché Feedfetcher non obbedisce al mio file robots.txt? ) E Validator ( dettagli ) del W3C non obbediscono robots.txt.
Vedi le FAQ di archive.is: perché archive.is non obbedisce a robots.txt?
meta- robots/X-Robots-TagNon sono sicuro che archive.is dovrebbe (idealmente) onorare il valore noindexo noarchivein meta- robots/ X-Robots-Tag, o se queste tecnologie si applicano anche solo ai robot autonomi. Ma poiché archive.is non lo documenta, al momento non sembrano supportarlo.
(FWIW, ogni pagina archiviata sembra ottenere un <meta name="robots" content="index,noarchive"/>.)
User-Agentarchive.is non documenta che un determinato User-Agentviene utilizzato (probabilmente non si identificano, per ottenere le pagine come se fossero visualizzate da un normale browser), quindi non è possibile utilizzarlo per bloccare il loro accesso a livello di server .
Quindi, poiché né robots.txtné meta- robots/ X-Robots-Tagqui funzionano, e non è possibile bloccarli tramite il loro User-Agent, è necessario bloccare gli accessi dagli IP di archive.is. Vedi la risposta di closetnoc sul blocco IP , ma nota che questo potrebbe bloccare più del previsto e potresti non catturare mai tutti i loro IP (e / o tenerti aggiornato).
Ogni versione archiviata si collega a un modulo in cui è possibile segnalare possibili abusi (append /abuse), ad esempio, con i motivi "SEO Issue" o "Copyright". Ma non so se o come gestiscono questi casi.
Per bloccare le disgustose pratiche di furto di archive.is (ignorando robots.txt, collegamento prioritario canonico, agente utente falso, nessun modo di eseguire una rimozione su tutto il sito), voglio aggiungere quanto segue alle soluzioni sopra.
Per trovare i loro indirizzi IP, invia loro un URL che è sotto il tuo controllo in modo da poter monitorare i log del tuo server web per vedere chi ha avuto accesso a quell'URL. L'URL non deve nemmeno esistere, purché il server Web riceva la richiesta. (Quindi è meglio usare una pagina vuota / url inesistente.) Ad esempio, usare un url come: http://example.com/fuck-you-archive.is
Quindi controlla i tuoi registri per vedere chi ha avuto accesso all'URL. Puoi usare grep per controllarlo:
grep "fuck-you-archive.is" web-server-log.txt
Una volta che hai l'indirizzo IP, puoi bloccarlo usando le soluzioni delle altre risposte. E quindi ripetere nuovamente il processo per trovare altri indirizzi IP che utilizzano. Devi specificare un URL diverso, per fare in modo che eseguano nuovamente una richiesta HTTP, ad esempio, cambia semplicemente http://example.com/fuck-you-archive.is in http://example.com/fuck-you- archive.is?2 ecc.
Nel caso in cui non desideri esporre affatto il tuo sito Web quando cerchi di trovare i loro indirizzi IP, puoi utilizzare questo pratico sito Web di richiesta HTTP: https://requestb.in I passaggi da eseguire sono: creare un RequestBin> inviare "BinURL" a Archive.is con "? SomeRandomNumber" aggiunto a BinURL> utilizzare "? inspect" di RequestBin per monitorare la richiesta in arrivo da Archive.is e vedere il loro indirizzo IP in "Cf-Connecting-Ip "Intestazione HTTP. (Assicurati di non inviare l'URL "? Inspect" a Archive.is.) Ripeti per trovare altri indirizzi IP cambiando "? SomeRandomNumber" con un altro numero.
Si noti che con le tabelle IP è possibile bloccare utilizzando
/sbin/iptables -A INPUT -s 78.108.190.21 -j DROP
ma spesso la catena "INPUT" è impostata su una politica "DROP" con l'accettazione del traffico HTTP. In tal caso, potrebbe essere necessario utilizzare un'operazione di inserimento (inserimento) invece di un'operazione di aggiunta, altrimenti non è affatto bloccata:
/sbin/iptables -I INPUT -s 78.108.190.21 -j DROP
Tuttavia, hanno molti indirizzi IP, quindi potrebbe essere più semplice bloccare intervalli IP completi. Puoi farlo comodamente con IPTables (senza la necessità di specificare maschere di sottorete) usando:
iptables -I INPUT -m iprange --src-range 46.166.139.110-46.166.139.180 -j DROP
Questo intervallo (46.166.139.110-46.166.139.180) è per gran parte posseduto da loro, perché ho visto più indirizzi tra 46.166.139.110 e 46.166.139.173.
Attualmente stanno utilizzando NFOrce come host web. Vedi https://www.nforce.com/abuse su come presentare un reclamo su Archive.is. Menzione: 1) l'URL della tua pagina web che archive.is ha rubato, 2) menziona l'URL at archive.is che contiene il contenuto rubato e 3) menziona gli indirizzi IP che hanno usato.
Potresti anche lamentarti di Cloudflare, il loro CDN, che memorizza le pagine e le immagini rubate per motivi di prestazioni. https://www.cloudflare.com/abuse/
Come possiamo vedere, archive.is sta usando DNS anycasting.
Se si utilizzano server dei nomi diversi (ad esempio da https://www.lifewire.com/free-and-public-dns-servers-2626062 ) attualmente (2018-09-10) si ottengono indirizzi IP diversi per "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
Ho usato abuse-contacts.abusix.org ( https://www.abusix.com/contactdb ) per ottenere i contatti di abuso per questi indirizzi 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
Come riportato da Cloudflare, archive.is sta abusando dei loro "servizi" utilizzando un record A DNS che non ha funzionalità!
Considera anche di contattare i registrar su www.isnic.is, il registro dei domini islandese. isnic at isnic dot is
L'Islanda ha la legge sul copyright e il Registro lo riconosce. Il registro esiste dalla fine degli anni '80 e non è soggetto all'ICANN.