Solproxy

en proxyserver for alle

Nå kan du skaffe deg din egen proxyserver gratis og er ikke lenger avhengig av andre. Med Solproxy ser ikke din ISP hvem du besøker på nettet, og de du besøker ser ikke din IP-adresse. Solproxy virker, og her skal jeg forklare hvordan. Jeg skynder meg å tilføye at den også tjener et annet godt formål: speiler viktige sider på nettet slik at de ikke bare forsvinner.

Desverre kan vi ikke tilby proxytjeneste gjennom solkorset.org. Det skulle snart belaste serveren for mye. Men du kan skaffe deg gratis shared webhosting (webhotell) hvor du kan installere Solproxy. Siden har du en proxyserver som bare du kan bruke og som derfor ikke blir overbelastet. Søk på nettet etter gratis webhosting og du finner massevis. Det er ikke mye du trenger; 100 Mb minne er nok. Du trenger dog CGI slik at du kan kjøre bash-skripts under Linux.

Solproxy består av tre deler. Først har vi utvidelsen i nettleseren som omdirigerer alle forespørsler til proxy-hosten der oppe. Så har vi .htaccess -skriptet (mod_rewrite) som omdirigerer forespørselen til et bash-skript hvis filen det spørres etter ikke finnes i cachen. Til slutt tar bash-skriptet wget.sh seg av nedlastingen av alle filer fra målstedet til cachen på proxystedet.

I pakken solproxy.zip har vi samlet alle filene du trenger (SHA256-hash: 0a58d869a27d5860e629fa63af783163aed386038e218323a22cb831b08427e3). Utvidelsen er testet i Firefox; muligens må den endres bitte litt for å kjøre i andre. Den består som vanlig av to filer: manifest.json og background.js . Legg dem i en mappe for seg og installer den i nettleseren som debug-utvidelse. Vi forklarte hvordan man gjør det i Firefox i Google baner vei for jødisk verdensherredømme. Googleblocker har vi forresten oppdatert, men når Solproxy-utvidelsen kjører gjør den samme nytten.

Kjernefunksjonen i background.js heter redirect, men den omdirigerer noen URLer til proxystedet, blokkerer andre. Du kan se hvilke som blir hva ved å åpne browser-konsollet: klikk på menyikonet i Firefox og velg nettsideutvikling og Browser Console. Det kan du også lese mer om i Google-skriftet. På filterlinja skal du skrive Cancel for å se URLene som blokkeres og Redirect for å se dem som sendes opp til proxystedet. URLer som allerede går til proxystedet gjøres det intet med. Tre kriterier for å blokkere: At det er noe skummelt med hosten, at filen ikke ser ut til å være et html-dokument, og at URLen som helhet vekker mistanke om spionvare. Først i skriptet står alt som du kan skru på. proxysite er satt lik https://www.solkorset.org/cache/ og den du endre. nh er forbudne filendelser, fb forbudne hoster, og sw forbudne brokker av URLen.

Du ser at solkorset forekommer både i fb og sw. Grunnen til at det er i fb er at solkorsets sider ikke skal lastes gjennom proxyen ved solkorset! Men oftest skyldes solkorsets opptreden her at filer på målstedet feilaktig har fått solkorset.org som host. Slike gale URLer fører ingen steder. Grunnen til at det er i sw er at spionvare ofte angir proxystedets host i sin query for å spore. Bort med alt dette. Men når du har fått ditt eget proxysted må solkorset endres til din host.

Du kan skru på disse innstillingene som du lyster. Legge til nye forbudne brokker når du ser at du får omdirigert og lastet ned uønskede filer, eller ta bort noen når noe du vil ha blokkeres. Men jeg må forklare hvorfor f.eks. jpg er en forbuden filendelse. Skal man ikke laste ned bilder? Jo. Grunnen er at bilder som naturlig hører til en webside allerede er lastet ned til cachen på proxystedet og har fått en cache-adresse. Hvis ikke nettleseren ser den cache-adressen er det noe galt; bildet synes å være websiden uvedkommende. Mer om dette når jeg forklarer skriptet wget.sh nedenfor.

Hvordan virker proxyen? La oss gå gjennom et eksempel. La oss si du skriver inn URLen https://www.eksempel.com/dette-er-en-artikkel på adresselinja i nettleseren. Den sendes til utvidelsen som omdirigerer den til https://www.solkorset.org/cache/www.eksempel.com/dette-er-en-artikkel . Når denne URLen når solkorset sendes den til .htaccess -skriptet for mulig omskriving. Dette skriptet skal legges i public_html -mappen. Hvis det er første gang du besøker eksempel-URLen, og det må det være, så finnes ikke denne filen i cachen. Det er hva man tester på med RewriteCond %{REQUEST_FILENAME} !-f . Hvis den ikke er der omskrives URLen til et kall til skriptet wget.sh. Det gjøres med regelen RewriteRule cache/(.*)$ cgi-bin/wget.sh?fil=$1&%{QUERY_STRING} .

wget.sh må selvfølgelig legges i cgi-bin mappen for at dette skal virke. Pass på så du laster det opp i ascii-modus og setter det eksekverbart. Vi kommer nå inn i wget.sh -skriptet og det første som gjøres er å fange URLen som ble sendt opp. Den har to deler: Det som jeg i regelen ovenfor kaller fil og en query_string. $QUERY_STRING i wget.sh er fil=$1&%{QUERY_STRING} fra regelen. Jeg fanger de to delene i henholdsvis fil og query.

Det neste som gjøres er å sjekke om dette gikk bra og om kalleren har tillatelse til å bruke proxy-tjenesten. Det sjekkes på kallers IP-adresse og på om fil er fanget. Her du redigere IP-adressen fra 1.2.3.4 til din egen IP-adresse. Du finner din, dvs. din routers, IP-adresse ved å klikke her. Hver gang du slår av routeren får den en ny IP-adresse av din ISP neste gang du slår den på igjen, så la den stå på! Ellers må du stadig vekk inn og redigere IP-adressen i wget.sh . Men hvis ikke du frykter at andre skal misbruke din proxy kan du fjerne sjekken på $REMOTE_ADDR .

URLen man skal ha tak i kan nå lett rekonstrueres. $fil_ er hva filen kommer til å hete lokalt i cachen på proxystedet. At det henges på @$query hvis URLen hadde query skyldes at wget-programmet omskriver ?$query til @$query før det lagrer filen lokalt. Det neste som gjøres med $fil_ fremtvinges også av wget-måten å omskrive på. Så beregnes host, ref og domain som trengs i kallet til wget. Hvis $REQUEST_METHOD er POST må inndataene leses og prepareres for å gis til wget sammen med $CONTENT_TYPE .

Vi går til cache-mappen (som du må opprette under public_html) og nå er alt klart for å kalle vidunderet, Linux/GNU -programmet wget. Hvis ikke $fil_ eksisterer skal dokumentet med alt innhold lastes ned og legges i cache-mappen, bortsett fra det du måtte ha fra før.

wget-programmet har mange options. quiet er for at det ikke skal skrive ut noe (for det er jo unyttig); timestamping gjør at bare filer lastes ned som er nyere enn dem du måtte ha i cachen; restrict-file-names=windows gir ordre om at filnavn skal omskrives for å unngå tegn som er ulovlige i Windows-filnavn; no-iri betyr vanlige URLer, nei til internasjonale URLer; adjust-extension gjør at det legges til passende filendelser for å vise typen; load-cookies og save-cookies velger filen som cookies skal oppbevares på; keep-session-cookies tar vare på session cookies slik at man ikke blir auto-utlogget av nettsider med innlogging, f.eks. debattfora; no-check-certificate dropper sjekken av TLS-certifikatet fordi det sinker og kan føre til trøbbel; span-hosts tillater nedlasting fra andre hosts enn den man tar utgangspunkt i (den i $url); men domains=$domain sørger for at kun hosts som matcher $domain tillates; convert-links innebærer at alle lenker i dokumentet til filer som er lastet ned omskrives slik at de går til filene i cachen; page-requisites gir beskjed om å laste ned alle filer som trengs for å vise nettsiden i en nettleser, men ingen andre.

Valgene av restrict-file-names=windows og adjust-extension forklarer hvorfor jeg omskriver $fil_ tidligere i skriptet og på den måten. Grunnen til at jeg har span-hosts og domains=$domain er at www.eksempel.com ikke tillater bilder.eksempel.com, altså ikke andre hosts ved samme domene. For å tillate det må man velge dette. convert-links og page-requisites forklarer hvorfor jeg kan blokkere alle forespørsler i utvidelsen i nettleseren som ber om filer som ikke er html: Hvis f.eks. et jpg-bilde hører til den aktuelle nettsiden (html) så har wget allerede lastet det ned og gitt det en ny URL i html-dokumentet som går til cachen. Så hvis jpg-URLen som ankommer utvidelsen ikke peker på cachen skal bildet ikke lastes ned, det skal blokkeres.

Det siste som gjøres i wget.sh etter kallet til wget-programmet er nøkkelen til hvordan proxyen virker. Http status-headeren 301 Moved Permanently skrives ut og siden headeren Location: $url_ . Dette instruerer nettleseren å mappe den etterspurte URLen til $url_ . I eksemplet ovenfor sendte nettleseren opp URLen https://www.solkorset.org/cache/www.eksempel.com/dette-er-en-artikkel (etter omskriving i utvidelsen). wget.sh sender beskjed tilbake om at filen har flyttet permanent til den nye adressen $url_ som er https://www.solkorset.org/cache/www.eksempel.com/dette-er-en-artikkel.html . Neste gang du klikker på en lenke til https://www.eksempel.com/dette-er-en-artikkel sendes denne URLen til utvidelsen som før og ut kommer https://www.solkorset.org/cache/www.eksempel.com/dette-er-en-artikkel som før. Men nå sender ikke nettleseren denne opp mer, den oppdager at dette er en URL som har flyttet for godt og finner frem den nye adressen: https://www.solkorset.org/cache/www.eksempel.com/dette-er-en-artikkel.html . Denne sendes opp til solkorset. I mod_rewrite -skriptet konstateres det at filen eskisterer og da omskrives ikke URLen, den sendes videre til filsystemet som returnerer filens innhold. wget.sh kalles altså kun ved cache-bom. Så lenge filene ligger i cachen lastes de ned like kjapt som vanlige filer ved solkorset.

Alt dette er veldig fikst i teorien men fungerer ikke alltid like bra i praksis. Du får prøve deg frem og skru på innstillingene som best du kan. Du vil merke at det går saktere med denne proxy-løsningen enn ved direkte anrop, så bruken innskrenker seg til nettsteder hvor det er viktig å være anonym. Moderne nettlesere som Firefox åpner mange forbindelser til målstedet samtidig (opp til 40 eller noe sånt), eller bruker http/2; wget åpner bare en eneste forbindelse og bruker bare http/1.1 . Mye av forklaringen på hvorfor det går sakte ligger nok her. Man burde bruke wget2, men den er ofte ikke installert på billige webservere. Forøvrig er det ikke alle målsteder som lar seg lure av wget men nekter det å laste ned. Det merker du på at nettleseren klager over at proxystedet ikke videreformidler riktig. Du vil også se i cachen at intet er lastet ned. Jeg forutsetter ikke at du har siste utgave av wget; en temmelig gammel utgave er nok. Hos gratis-hoster kan man ikke regne med å få det siste og beste.

Det er ikke bare anonymitet proxyen tjener, den tar også vare på viktige nettsider som ellers fort kan bli borte under sensurens barberblad. Hvor ofte har det ikke hendt at hvite nasjonalistiske sider er gått ned fordi verten har kastet dem ut? Ved å speile sørger du for at sidene alltid er tilgjengelige. Hvis de forsvinner for godt har du bevart dem og kan gi dem liv etter døden. Proxy-brukerne blir sammen et gedigent internet-arkiv. Lag gjerne en hjemmeside på proxystedet med lenker til forsidene i cachen. Og lenker til andre proxysteder.

Jeg har laget flere nyttige programmer for å behandle cachen. Hvert består av to deler: et bash-skript der oppe for Linux og et batch-skript her nede for Windows. Det første heter cachelist og består av cachelist.sh og cachelist.bat . cachelist.sh skal som alle Linux-skripts lastes opp til cgi-bin -mappen i ascii -modus og settes eksekverbart (chmod 755 cachelist.sh). Men før du laster det opp må du redigere det: abrakadabra må endres til passordet du skal bruke. Det samme gjelder de andre bash-skriptene. cachelist.bat bruker det medfølgende programmet http.exe for å kjøre cachelist.sh, men du kan alternativt bruke https.exe . Før du kjører det må du redigere og kjøre miljo.bat som stiller visse miljøvariabler. %cachehost% er som du forstår hosten til proxystedet ditt, %passord% er passordet til cache-skriptene (abrakadabra før du endret det), de tre siste er ftp-host, ftp-bruker og ftp-passord som du har fra webhosten din.

For å liste øverste nivå i cachen skriver du: cachelist . . Viktig å få med seg dot til slutt her. Som mapper vil du få se alle nettstedene du har lastet ned fra, f.eks. www.eksempel.com . Når du har lastet opp de andre bash-skriptene kan du kjøre cacheclear www.eksempel.com som sletter denne mappen med alt innhold. Endelig kan du kjøre cachesize for å se hvor mye plass cachen tar på disken der oppe. Som gratis-passager har du meget begrenset kvote så du må holde et øye med dette. Du får også se hvor mye plass de ulike nettstedene tar så du selektivt kan slette noen.

Noen av dokumentene i cachen vil du vel laste ned til din egen maskin? Når du har bestemt deg for hva du vil spare på og hva du ikke bryr deg om skal du slette det siste og synkronisere det første. Å synke er nesten det samme som å laste ned, bare at man ikke gjør det dersom filene finnes her nede fra før og ikke er gamle. sync.bat er skriptet for å synke. Første rad i skriptet er call cachelist.bat . lR > cache.lst og lister hele cachen som legges på filen cache.lst . For å se hvor mye plass ulike filtyper tar kan du gi kommandoen type cache.lst | mend | filstat . Ut i fra dette kan du beslutte hvilke filtyper du skal laste ned. La oss si du nøyer deg med html og css, da lager du batch-skriptet for å synke slik: type cache.lst | mend | filetypes html css | cachesync > cs.bat . cs.bat oppretter mappestrukturen her nede, lager foreløpige utgaver av alle filene som ikke finnes med bare 2 bytes i hver, og produserer ftp-skriptet som skal laste ned alle filene som mangler eller er større der oppe. Ja, det synkes ikke på fildato men på filstørrelse.

Med cs.bat > cs.ftp får du gjort dette og får ut ftp-skriptet i cs.ftp . Til slutt kjører du ftp-skriptet med ftps -s:cs.ftp . Her er ftps.exe en ftp-klient som medfølger (MOVEit Freely 5.5.0.0). Du kan også laste ned kryptert, se raden i sync.bat som er kommentert bort. Du kan gjøre alt dette på en gang ved å kjøre sync html css . Desverre har ftps.exe en lei tendens til å henge seg opp når det laster ned mange filer. Det du gjør da er å avbryte med ctrl C og siden produsere ftp-skriptet på ny med cs.bat > cs.ftp . Da lastes ingen filer ned to ganger. Kjør ftps -s:cs.ftp på ny. Gjenta dette inntil du har fått ned alle filene. Har du en annen ftp-klient kan du prøve den i steden for ftps.exe, men MS ftp.exe virker ikke.

Det tror jeg var alt. Håper dette blir til nytte for folket i kampen mot regimet. Er noe galt er det bare å melde fra. Entusiastene kan videreutvikle og forbedre dette selv.

Erlend