Mer diskplass og økt pris for webhotell
Skrevet av: Jon Eivind Malde

27. juni sjokkerte cPanel hele webhotellbransjen da de mangedoblet prisen for programvaren med øyeblikkelig virkning uten noen form for kommunikasjon med sine partnere. cPanel er kontrollpanelet vi benytter for våre webhotell og er grunnmur for tjenesten vi leverer.

Økt pris for cPanel

Over natten er våre priser blitt ca. 7 ganger dyrere. Bransjen har vært i opprør siden endringen og cPanel har fått mye kjeft fra sinte partnere i alle kanaler. Et raskt søk på nettet vil vise mange «fargerike» tilbakemeldinger.

Vi har selv gitt beskjed til cPanel om det vi mener er useriøs forretningspraksis. Dessverre lytter ikke cPanel til sine partnere og vi blir tvunget til å enten akseptere endringen eller å finne alternative løsninger for å kunne fortsette å levere stabile og gode tjenester til våre kunder.

Våre tanker

cPanel lover at prisendringen skal resultere i enda bedre produkt for deg, men en så radikal prisendring er tung å svelge når produktet i utgangspunktet ikke var lavt priset. Vi har vurdert andre løsninger, men det finnes per dags dato dessverre ikke løsninger som er gode eller stabile nok sammenlignet med cPanel. Vi kan også utvikle egen løsning, men det vil ta mye tid, noe vi ikke har ettersom endringen er umiddelbar.

Vi tror du som kunde først og fremst er opptatt av stabil og sikker drift. Med det som utgangspunkt har vi i første omgang ikke annet valg enn å fortsatt tilby webhotell med cPanel. Vi ønsker imidlertid å tilby det som er best for våre kunder til enhver tid til mest mulig konkurransedyktige priser. Du kan med andre ord være sikker på at vi ikke vil stoppe å vurdere alternativer. Vår lojalitet til cPanel er radert og cPanel må levere på sine løfter for at vi ikke skal foreta endringer.

Økt pris og økt diskplass

På grunn av økningen har vi sett oss nødt til å øke prisen for følgende webhotell:

WebhotellGammel prisNy pris
Pro Medium49,-59,-
Pro Premium99,-119,-

Prisen vil tre i kraft fra 15.09 for alle kunder. Du har med andre ord muligheten til å bestille nye webhotell eller oppgradere før denne datoen til gammel pris.

Samtidig som vi øker prisen ønsker vi også å forbedre tilbudet så vi øker samtidig diskplass:

WebhotellFør
Pro Medium15GB30GB
Pro Premium30GB100GB

Alle kunder har allerede fått nye grenser for diskplass på sine webhotell.

Oppsummering

Denne endringen var ikke planlagt, men vi håper på forståelse for hvorfor vi måtte foreta endringen. Samtidig håper vi økt diskplass vil være et lite plaster på såret når vi først gjør endringen.

cPanel versjon 80
Skrevet av: Simon A. Skaar

Ett-klikks tvungen HTTPS-videresending av nettsiden og bedre støtte for Node.js er blant de nye hovedfunksjonene i versjon 80 av cPanel.

Vi kjører cPanel 80 på samtlige webhotell og du skal allerede kunne benytte de nye funksjonene som er kommet.

Aktivering av tvungen HTTPS så lenge du har gyldig sertifikat (dette har du gjerne allerede). Du finner knappen for dette under «Domains» inne i cPanel. Per dags dato gjelder det kun for hoveddomenet men det er andre enkle måter å tvinge andre domener over.

Innenfor sikkerhet har cPanel gjort integrasjonen med Imunify360 enda bedre, vi har allerede benyttet deres tjeneste siden starten av 2017.

Imunify360 er en registrert merkevare fra CloudLinux

SpamBox vil nå være automatisk aktivert på alle nye webhotell da det har en positiv virkning.
Autosvar sitt brukergrensesnitt er oppdatert med begrensning til kun fraværsmelding per epostbruker.

Les gjerne mer om cPanel 80 i deres lanseringslogg.

Har du fått e-post om skadelig kode på ditt webhotell?
Skrevet av: Jon Eivind Malde

Illustrasjon av hacket nettside

Vi har begynt å ta i bruk et nytt system for å raskere og bedre håndtere, samt varsle våre kunder om skadelig kode på deres webhotell. Systemet tas gradvis i bruk på flere av våre servere og vil innen kort tid dekke alle servere med webhotell. Når alle servere er dekket vil alle kunder bli varslet via e-post innen få minutter av at skadelig kode blir funnet.

Hvorfor gjør vi dette?

Dersom det er skadelig kode hos en av våre kunder kan det utgjøre en risiko for andre brukere på serverne, samt andre brukere på nettet. Hackere kan via slik kode for eksempel:

  • Hente ut alle data du har lagret i webhotellet/nettsiden, eller legge inn hull for å kontinuerlig ha tilgang til dine data.
  • Sende spam og phising e-poster (som vil medføre svartelisting av serverens IP adresser og medfører at alle kunder på serveren får problemer med å sende e-post).
  • Angripe andre maskiner på nettet for å forsøke å spre virus og skadevare eller delta i DDoS angrep.
  • Kjøre kode som overbelaster serveren slik at det går ut over andre kunder på serveren.

Dersom vårt system finner filer med skadelig kode vil vi utføre følgende steg hvor neste steg kun utføres dersom forrige steg ikke var vellykket:

  1. Sjekke backup for uinfisert fil og automatisk gjenopprette filen fra backup.
  2. Rense filen for skadelig kode.
  3. Legge filen i karantene.
  4. Slette filen.

Vi prøver med andre ord å hjelpe deg som kunde med å fjerne koden på den måten som er minst skadelig for deg, men går mer drastisk til verks dersom dette ikke går. Noe vi må ettersom skaden kan være stor dersom vi ikke gjør det på denne måten.

Hva er dette systemet?

Systemet vi benytter kalles Imunify360 og leveres av CloudLinux (som leverer OSet til våre webhotell servere). Vi har benyttet Imunify360 siden CloudLinux lanserte systemet i starten av 2017 og har siden den gang samarbeidet om hvordan det skal fungere. Det er likevel først nå vi mener systemet er modent nok til å bli tatt i bruk på denne måten og at vi har integrert det opp mot våre egne systemer.

Imunify360 logo

Imunify360 gjør mye mer enn å bare finne skadelig kode i filer. Blant annet:

  • Stopper angrep via web applikasjonsbrannmur mot nettsiden din.
  • Stopper bruteforce angrep (forsøk på å finne ut passord) via tjenester som SSH, IMAP mm.
  • Patcher programvare på serveren som har kjente sårbarheter som for eksempel kernel (uten behov for omstart).
  • Stopper skadelige prosesser som samtidig også finner rotårsak via logger.
  • Finner domener som er svartelistet.

Imunify360 er med andre ord en viktig del av sikkerheten på våre servere, og vil bare bli viktigere ettersom systemet utvikles videre.

Hvor kan jeg se hva som blir funnet?

Du har full tilgang til filene og logg via kontrollpanelet (cPanel) som vist i guiden Malware skanner i Imunify360. Her kan du også gjenopprette filer fra karantene, samt hviteliste filer som blir ansett som skadelige uten at de burde (falsk positiv).

I e-postene som sendes når vi tar i bruk systemet kan det hende at noen filer er håndtert for svært lenge siden. Vi kunne latt være å rapportere disse, men gjør det likevel for ordens skyld i tilfelle det skulle være viktig informasjon. I gamle tilfeller er det ikke sikkert du finner filen nevnt i loggene da Imunify360 ikke logget disse på samme måte i starten som de nå gjøres.

Hva bør jeg gjøre dersom noe blir funnet på mitt webhotell?

Du bør sjekke om nettstedet ditt fungerer som det skal. Er filene gjenopprettet eller renset så skal det ikke være nødvendig å gjøre noe med filene. Er de satt i karantene eller slettet bør du finne ut om disse tilhører løsningen du benytter og sjekke om de inneholder kode som ikke burde være der. Er du i tvil kan du spørre leverandør av løsningen eller oss.

Foruten å gjennomgå filene bør du følge tipsene i guiden Hvordan sikre ditt nettsted mor angrep fra hackere.

Spørsmål eller kommentarer? I så fall hører vi gjerne fra deg 🙂

Gratis SSL sertifikat med AutoSSL
Skrevet av: Jon Eivind Malde

I 2016 inngikk vi samarbeid med Symantec (som nå er Digicert) om å levere gratis SSL sertifikat til våre kunder. AutoSSL, som er cPanels løsning for gratis SSL sertifikat, var også akkurat lansert på det tidspunktet. Vi valgte imidlertid å samarbeide med Symantec fordi vi mente at deres løsning ville være best for våre kunder.

Bakgrunn

De to løsningene var forskjellige ved at Symantecs løsning skulle legge til rette for at du skulle begynne med et gratis SSL og deretter kunne bygge videre på dette ved å legge til mer ettersom du fikk behov for mer. Kort fortalt at sertifikatet vokser med deg og tilpasses deg. AutoSSL manglet dette, men dekket til gjengjeld alle domener på webhotellet. AutoSSL hadde imidlertid en del utfordringer som trakk ned og var ikke godt integrert i cPanel på den tiden.

Hvorfor gratis SSL sertifikat via AutoSSL

Dessverre har ikke Symantec levd opp til visjonen som vi falt for. Lite har skjedd siden vi inngikk samarbeidet, samtidig som AutoSSL har blitt stadig bedre integrert i cPanel. Vi måtte derfor bare erkjenne – jo før jo bedre – at vi valgte feil for våre kunder. Vi har nå avsluttet samarbeidet med Symantec om gratis SSL sertifikat og vi har allerede tatt i bruk AutoSSL for samtlige webhotell. De siste restene av gratis SSL via Symantec fjernes fra våre nettsider i løpet av kort tid.

Fordelene for deg med AutoSSL

For deg som kunde vil fordelene med den nye løsningen være at:

  • Alle (sub)domener på webhotell er dekket i motsetning til kun ett domene
  • Sertifikatene utstedes/fornyes automatisk i stedet for at du må manuelt utstede/fornye dem
  • Domeneparkeringer vil også få gratis SSL sertifikat, noe som er spesielt nyttig for dem som benytter 1-sideløsningen av nettsidebyggeren
  • Videresendinger vil også få gratis SSL sertifikat
  • Glemmer du å fornye ett sertifikat så vil AutoSSL erstatte det med et gratis SSL sertifikat (slik at du unngår feilmeldinger for dine besøkende)
  • Du får gratis SSL på mail.dittdomene.net (hvor dittdomene.net er domenet ditt) og kan dermed sette opp e-postklienten med SSL med denne adressen i stedet for cpanelX.proisp.no (hvor X er nummeret på serveren)
  • Andre nyttige adresser som webmail.dittdomene.net og cpanel.dittdomene.net kan benyttes med https da disse automatisk også får gratis SSL

Ulemper?

Du kan kanskje spørre deg om det er noen ulemper? Ja, vi får ikke vist deg like tydelig hva et betalt SSL sertifikat kan hjelpe deg med utover å kun sikre kommunikasjonen. Du får heller ikke skreddersydd din egen SSL løsning slik vi hadde visjon om sammen med Symantec. Men, frykt ikke 🙂 Vi skal nok klare å bake inn tips om betalte SSL sertifikat der det passer seg, basert på analyse av dine behov. Eksempelvis i diagnose av webhotell og liknende – på sikt.

Hva med deg som allerede har SSL sertifikat fra Symantec?

Dersom du har:

  • Kun gratis SSL sertifikat vil dette automatisk fornyes med nytt sertifikat før det utløper.
  • Gratis SSL sertifikat med sidesegl vil vi erstatte dette med ett PositiveSSL sertifikat til samme pris for deg før det utløper. Du får altså ett fullverdig betalt sertifikat med ca. 30% rabatt. Ulempen er at du vil måtte legge inn nytt sidesegl, men dette hjelper vi deg gjerne med om du har behov for hjelp.
  • Gratis SSL sertifikat med wildcard (Basis SSL Pluss) vil vi erstatte dette med ett PositiveSSL wildcard sertifikat til samme pris som du betalte før det utløper . Du får altså også her ett fullverdig betalt sertifikat med rabatt i stedet for det gamle.

Hvor ofte utstedes gratis SSL sertifikat?

De nye sertifikatene utstedes/fornyes automatisk en gang per natt for alle domener på våre webhotell som ikke allerede har SSL sertifikat eller har sertifikat som er i ferd med å utløpe. Har du behov for sertifikat umiddelbart har du tilgang til å utstede dette automatisk via cPanel som vist i guiden «Installere gratis SSL sertifikat via AutoSSL«.

Har du spørsmål rundt overgangen eller om den nye løsningen er det bare å ta kontakt 🙂

PRO ISP støtter IKT servicefag
Skrevet av: Isabelle

PRO ISP startet i 2017 et samarbeid med IKT servicefag på Haugaland videregående skole. Samarbeidet innebærer egne priser for webhotell som benyttes i skolesammenheng.

Elevene kommer raskt i gang med opplæringen

Rune Karlsen er faglærer på IKT servicefag og forteller: «Ved å benytte PRO ISP sine tjenester kommer elevene raskt i gang med opplæringen for å drifte nettsider. Vi er opptatt av at dataene skal lagres på en mest mulig sikker måte, at det skal være mest mulig lokalt, og at serverhosten følger norske lover og regler. Vi kjører både lokal server og ekstern server slik at elvene får opplæring i begge. De må kjenne til de fleste mulighetene når de senere skal ut i jobb. Vi ønsker å bevisstgjøre dem i forhold til om det lønner seg økonomisk å sette ut tjenester, eller å kjøre dem selv.»

Tjenester som er relevante for elevene

PRO ISP fokuserer på automatisering av tjenestene der det er mulig. Vi er i tillegg opptatt av standardisering og kvalitetssikring. Det er viktig at tjenestene elevene benytter seg av er relevante og forbereder dem på IT-samfunnet de skal delta i.

«Vi er i konstant dialog med læreplassene til våre elever. Det er disse som legger føringer på hva elevene skal og bær lære før de blir ansatt som lærlinger. Det er vårt ansvar som faglærer å tolke hva som ligger innenfor kompetansemålene for å deretter lage læringsmål av dem» sier Karlsen.

PRO ISP ble anbefalt

«Vi ble anbefalt PRO ISP av Hatteland Solutions som også samarbeider tett med dem.» Karlsen forteller videre at de ønsker elevene skal besøke datahallene til Hatteland for å fysisk se hvor data blir lagret, og hvordan sikkerheten blir ivaretatt.

«Ved å benytte PRO ISP vet vi også at dataene til våre elever lagres i Norge og følger norske lover og regler. PRO ISP kunne også tilby våre elever en tjeneste til en overkommelig pris. At elevene også kunne overta tjenesten/nettsiden etter endt utdanning, var også et pluss.»

Et vellykket samarbeid

Faglærer Karlsen er meget fornøyd med samarbeidet mellom IKT servicefag og PRO ISP. Hele prosessen med å opprette domene for elevene, til installasjon av andre tjenester gikk smertefritt. Han forteller at elevene ga tilbakemelding om at det var intuitivt og enkelt å forholde seg til tjenestene fra PRO ISP.

«Jeg vil anbefale denne ordningen for alle IKT klasser. Våre elever lærte utmerket hvordan domene, webhotell, cPanel, integrering av eposter med MX etc henger sammen. Vi opplevde det var lettere for våre elever å se sammenhengen mellom de ulike teknologiene når vi benyttet PRO ISP. Vi er strålende fornøyd med tilbudet vi fikk og håper vi kan fortsette samarbeidet i mange år fremover.»

Skoleklasse som behøver webhotell?

PRO ISP tilbyr gode og rimelige avtaler for skoleklasser som ønsker å benytte våre webhotell. For mer informasjon kan lærer ta kontakt med oss på salg@proisp.no.

Sikkerhet for nettsider – hvordan gjøre nettsiden sikker
Skrevet av: Trond Olav Ånesen

Å ivareta sikkerheten på nett er ikke på noen måte noe nytt. Mange tenker gjerne kun sikkerhet som besøkende på en nettside, men som eier må man også tenke sikkerhet. Det har ingen betydning hvilken type nettside du har. Enten det er en enkel informasjonsside, en blogg, en nettavis, en nettbutikk eller hva som helst.

Sikkerheten er viktig både for deg som eier og driver siden, og for de som besøker og bruker nettsiden. I denne artikkelen ser vi på hvordan man opprettholder grunnleggende sikkerhet og hva man kan/må gjøre hvis noe inntreffer.

Sikkerhet på nettsiden din handler om:

  • Det skal være trygt for alle å besøke nettsiden
  • Nettsiden skal ikke være infisert med skadelig kode som kan infisere besøkende
  • Nettsiden skal ikke videresende til sider med skadelig kode
  • Informasjonen som utveksles mellom besøkende og nettside/server skal ikke kunne fanges opp av uvedkommende

I en artikkel som dette har vi ikke anledning til å gå i dybden på alt, men vi fokuserer på det viktigste; Det skal være trygt å besøke nettsiden din!

sikkerhet for nettsider

Sørg for at nettsiden ikke er eller kan bli infisert

Når en nettside er åpen på nett er den et potensielt mål for en hacker. Hackeren er ikke nødvendigvis en kar i svart hettejakke som bor i en klam kjeller. I de aller fleste tilfellene er en hacker bare en automatisert «Bot» (Robot). Slike «Boter» står kontinuerlig og skanner både kjente og ukjente nettsider etter sårbarheter som kan utnyttes. Sårbarhetene eksisterer i koden man kjører, direkte, eller i tillegg, utvidelser og annet. Et klassisk eksempel er en nettside laget i WordPress, med eget tema og en håndfull plugins installert. Vi tar utgangspunkt i nettopp dette eksempelet videre i denne artikkelen.

Siden WordPress er så utbredt som det er, så er det populært å lete etter svakheter i denne type installasjoner. Klarer man å infisere 1 nettside, kan man potensielt gjøre det samme med mange tusen flere nettsider.

Motivet bak det å infisere en nettside kan være forskjellig; en hacker ønsker å spre sitt eget budskap, de ønsker å sende ut spam fra din konto, de ønsker å fange opp sensitiv informasjon fra besøkende, de ønsker å videresende besøkende til andre lumske sider, de ønsker å bruke ressursene til konto i andre angrep osv. Dette er noe man selvsagt ønsker å unngå. Som regel er det ikke deg direkte de ønsker å ta.

Sjekkliste for å unngå at din nettside blir infisert

  • Alt må være oppdatert, alltid
    Siden WordPress (og andre lignende systemer) er såpass populært, kommer det også oppdateringer så snart sårbarheter blir funnet, og utbedringer blir laget. Man må følge med slik at man får med seg oppdateringer og implementere disse i egen installasjon. Så snart en sårbarhet er oppdaget og kjent, er det kun et tidsspørsmål før nettsider som ikke er oppdatert blir angrepet. Det samme gjelder for alt av tillegg som er installert.I eksempelet vårt kjøres et eget tema og en del plugins. Disse kan også inneholde sårbarheter og utviklerne kommer da jevnlig med oppdateringer som retter dette. Derfor er det like viktig at dette holdes oppdatert som selve installasjonen.
  • Alt som ikke er i bruk på webhotellet bør fjernes
    Alle temaer og utvidelser/plugins som ikke er i bruk bør slettes/fjernes. Selv om man deaktiverer en utvidelse/plugin eller tema så er ikke alltid alt faktisk borte. Filer ligger ofte igjen og kan da potensielt misbrukes. Altså; kun det som er nødvendig for å ha nettsiden fungerende optimalt skal være åpent tilgjengelig. Alt annet må enten slettes eller flyttes til et område hvor det ikke kan nås.
  • Bruk captcha i skjemaer
    Skjemaer; da av typen kontaktskjemaer, bestillingsskjemaer osv, må sikres slik at de ikke kan fylles ut automatisk. Slike «Boter» som vi nevnte i sted kan også brukes til å misbruke slike skjemaer, når de finnes, og da eksempelvis sende ut spam fra nettside/konto. Dette går ut over de besøkende på to måter:
    1. Ved at ressurser på webhotellet kan bli brukt til kun dette, slik at besøkende ikke får lastet siden.
    2. Ved at misbruket er av en slik karakter at konto må suspenderes for å unngå videre problemer. Da blir siden i praksis tatt ned. På alt av skjemaer og annet hvor besøkende kan fylle ut info, bør man ha en ekstra sjekk på plass. Captcha er den mest brukte (og anbefalte) metoden for dette.

sikkerhet for nettsider

  • Passord som benyttes må være sikre
    Et sikkert passord er langt og satt sammen av både tall, små og store bokstaver og ander tegn. Lange passord kan også være setninger eller fraser sammen med tilfeldige tall/tegn som kan være enklere å huske. Passord er relevant både på kundesider hos oss, på webhotell, på epostkontoer og på selve nettsiden/installasjonen. De passordene som brukes mest er også de som er mest sårbare. Man bør bytte passord minst et par ganger i løpet av er år. Det bør heller ikke brukes samme passord noe sted.
  • Implementer ekstra sikkerhet hvor det er mulig
    For mange CMSer (WordPress/Joomla/Drupal) utvikles det egne plugins som fokuserer kun på sikkerhet. Her bør man undersøke litt hvilke behov man har, og installere det man mener passer best. Det finnes flere gratis alternativer som er gode nok, men har man en stor side som genererer mye trafikk kan det være verdt å betale for ekstra sikkerhet. Eksempel på en aktør med godt rykte rundt dette, som også tilbyr gratis plugin, er Sucuri.

sikkerhet for nettside

  • Sørg for å alltid ha backup (sikkerhetskopi) av innholdet
    Man bør alltid sørge for at man har backup (sikkerhetskopi) av innholdet. Kunder av PRO ISP har inkludert en av de beste løsningene som er i markedet for backup. Denne løsningen har de tilgang til direkte via webhotellets kontrollpanel (cPanel). PRO ISP tar backup av all data 1 gang pr døgn, og backupen beholdes i 30 dager. Selv om man har svært god backup inkludert i webhotellet hos PRO ISP så anbefales det alltid å ha en ekstra kopi lagret eksternt. Slik backup kan da være av typen tatt 1 gang pr måned, 1 gang pr kvartal osv, litt avhengig av hvor kritisk det er og hvor mye endringer man er villige til å miste.

Nettsiden er allerede blitt infisert, hva gjør man?

Hva om skaden alt er skjedd? Hva om kontoen din har blitt suspendert av oss? Mange kan oppleve dette, og det oppleves i de fleste tilfellene som svært urettferdig.

Alle hostingselskaper operer på samme måte når det gjelder webhoteller; mange webhoteller deler ressurser på samme server. Det er naturlig nok litt av opphavet til navnet; Serveren er hotellet, kundenes kontoer er hotellrom på dette hotellet.

Når en webhotelleverandør opplever at ressurser misbrukes må dette stoppes for å unngå at det går ut over alle andre på samme hotell. Tenk for eksempel at et hotellrom blir ekstremt mye besøkt, så mye at ingen andre hotellgjester kommer seg verken inn eller ut av sine rom. Da må det rommet som skaper problemer stenges for å unngå nettopp dette.
Det er ikke alltid at en konto stenges ned, men ser vi tegn til hacking/misbruk så kan vi gi beskjed direkte om dette slik at det kan utbedres.

Det viktigste i slike tilfeller er; Følg de instrukser som gis, og spør om tips/råd/veiledning dersom man er usikker.

Dersom vi oppdager hacking/misbruk, og enten gir beskjed om det eller suspenderer konto, så gir vi alltid beskjed om hva som må gjøres.
I de fleste tilfeller er hackingen såpass ny at man kan benytte seg av backupen som er inkludert i webhotellet. Prosedyren er da forholdsvis enkel:

  • Slett innhold på webhotellet som er relatert til nettsiden.
  • Gjenopprett innholdet fra en dato FØR hacking fant sted (evt den eldste tilgjengelige backup, ved usikkerhet)
  • Gjennomgå punktene over for å hindre videre hacking/misbruk, altså oppdater alt, slett alt som er unødveding, sikre alle skjemaer, bytt alle passord og implementer ekstra sikkerhet

Gjør man det som blir anbefalt, og sørger for å skjerpe rutinene med alle nevnte punkter, så er man så sikker man kan få blitt. Da vil både du som eier nettsiden, de som besøker nettsiden, og vi som serverer den fra våre servere være fornøyd.

Sikre informasjon mellom besøkende og server (SSL sertifikat)

Sikkerhetssertifikat er noe som blir mer og mer aktuelt å snakke om, og høyst aktuelt når det gjelder sikkerhet for nettsider. Vi har tidligere hatt innlegg både om «Hvordan velge riktig SSL sertifikat» og hvordan de store leverandørene planlegger å «tvinge» mer og bedre bruk av dette for å opprettholde sikkerheten på nettet («Google advarer: Sikre nettsiden din»).

Nå blir det noen litt tekniske ord og uttrykk her, men litt teknisk må vi bli for å forklare:
SSL* er en krypteringsprotokoll, eller et sett med regler som forteller en server/klient (nettsiden og besøkende) om hvordan kryptering av data skal foregå. Kryptering er da prosessen med å gjøre noe uleselig eller uforståelig for andre.

* I praksis er det TLS som benyttes, men SSL og SSL sertifikater benyttes i dagligtalen, så derfor også her.

Målet med SSL er altså at kun den som besøker nettstedet, og serveren/nettstedet, skal kunne lese data som sendes mellom disse. Det er da spesielt viktig når det er personlig eller sensitiv informasjon som utveksles, så som telefonnr, brukernavn, passord, epostadresser, kredittkortinformasjon og lignende; for vi ønsker IKKE at slik info skal kunne ses av andre.

sikkerhet for nettside

For å få til denne krypteringen bruker vi såkalte «nøkler», og når både den besøkende og serveren/nettsiden har samme type «nøkkel», er det kun de som kan lese, og kryptere, informasjonen. Et SSL sertifikat er da et sertifikat som bekrefter eierskapet til disse nøklene, og at de er autentiske og gyldige. Hvor nøyaktig og grundig den bekreftelsen er kommer an på sertifikatet, les mer om dette i «Hvordan velge riktig SSL». I praksis bekreftes at sertifikatet er utstedt av en gyldig utsteder, for det nettstedet man besøker, og at det er gyldig for nettopp dette.
Du som besøkende kan se dette ved at man får opp en hengelås i adressefeltet og at nettleseren rapporterer om at nettstedet er å anse som «sikkert».

Som vi nevnte i «Google advarer: Sikre nettsiden din» så er kryptering av informasjon høyst aktuelt siden det snart blir et krav. Man kan selvsagt unngå bruk av SSL sertifikater, men da vil besøkende bli advart når de går til siden din. Denne advarselen kan sammenlignes med å rope til kundene: «Jeg tar ikke sikkerhet på alvor». For de som ikke har fått nettsiden sin over på https er tiden definitivt inne for å ta grep!

Har du flere spørsmål etter å ha lest innlegget?

Som nevnt innledningsvis er sikkerhet et såpass stort tema man ikke kan dekke alt i en enkel artikkel. Likevel, følger man de råd som er gitt her, og har sikkerhet litt mer i «bakhodet» har man kommet et langt stykke på vei.

Leser du innlegget og sitter igjen som et spørsmålstegn? Er det ting du lurer på som ikke ble forklart eller besvart her? Eller ønsker du bare råd og veiledning? Ikke nøl med å ta kontakt med oss.

Epost: support@proisp.no
Facebook: https://www.facebook.com/proisp/

Nettsider på Enterprise webhotell – del 1
Skrevet av: Jon Eivind Malde

I denne bloggserien vil vi se nærmere på kunder som har byttet fra våre standard webhotell til Enterprise webhotell og hvilke forbedringer dette har medført. Vi vil også gå nærmere inn på hvilke endringer som er utført i skript dersom det er gjort forbedringer i forhold til dette.

Første kunde* vi ser nærmere på har flyttet www.trondheim.no og www.trondheim.com fra våre vanlige webhotell med Apache webserver til Enterprise webhotell. Nettsidene er basert på Joomla og det er ikke utført noen endringer i oppsettet i overgangen. Nettsidene er offisielle nettsider for Trondheim hvor kort og godt det meste om Trondheim er presentert på en oversiktelig måte på både norsk og engelsk.

Per dags dato tilbyr ikke LiteSpeed egen plugin for Joomla for caching (som de for eksempel gjør for WordPress), men dette skal være på planleggingsstadiet. Det skal være mulig å sette opp LiteSpeed caching for Joomla som beskrevet her:
Joomla LSCache

Vi har ikke satt på caching som nevnt over og nettsidene hadde ikke aktivert noen form for caching i perioden da nettsidene ble flyttet.

For å best mulig vise forbedringene flyttingen har medført har vi foretatt målinger før og etter flytting via følgende:

Ettersom resultatene er tilnærmet like for nettsidene og kun den norske versjonen var tilgjengelig på no.trondheim.com har vi foretatt alle tester mot den adressen.

Før flytting til Enterprise webhotell

ab fra Norge

# ab -n 300 -c 2 http://no.trondheim.com/
This is ApacheBench, Version 2.3 <$Revision: 655654
gt; Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking no.trondheim.com (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Finished 300 requests Server Software: Apache Server Hostname: no.trondheim.com Server Port: 80 Document Path: / Document Length: 21846 bytes Concurrency Level: 2 Time taken for tests: 77.225 seconds Complete requests: 300 Failed requests: 0 Write errors: 0 Total transferred: 6728100 bytes HTML transferred: 6553800 bytes Requests per second: 3.88 [#/sec] (mean) Time per request: 514.833 [ms] (mean) Time per request: 257.416 [ms] (mean, across all concurrent requests) Transfer rate: 85.08 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 5 5 0.1 5 6 Processing: 341 507 76.3 523 1063 Waiting: 323 480 73.8 498 1038 Total: 346 513 76.3 528 1068 Percentage of the requests served within a certain time (ms) 50% 528 66% 540 75% 544 80% 548 90% 559 95% 573 98% 643 99% 867 100% 1068 (longest request)

ab fra Tyskland

# ab -n 300 -c 2 http://no.trondheim.com/
This is ApacheBench, Version 2.3 <$Revision: 655654
gt; Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking no.trondheim.com (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Finished 300 requests Server Software: Apache Server Hostname: no.trondheim.com Server Port: 80 Document Path: / Document Length: 21846 bytes Concurrency Level: 2 Time taken for tests: 88.542 seconds Complete requests: 300 Failed requests: 0 Write errors: 0 Total transferred: 6728100 bytes HTML transferred: 6553800 bytes Requests per second: 3.39 [#/sec] (mean) Time per request: 590.282 [ms] (mean) Time per request: 295.141 [ms] (mean, across all concurrent requests) Transfer rate: 74.21 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 32 34 0.6 34 37 Processing: 377 553 119.3 562 1316 Waiting: 342 509 95.5 526 1058 Total: 411 587 119.3 596 1351 Percentage of the requests served within a certain time (ms) 50% 596 66% 606 75% 612 80% 618 90% 670 95% 801 98% 1000 99% 1136 100% 1351 (longest request)

Pingdom Website Speed Test

Pingdom før flytting til Enterprise webhotell

GTMetrix

GTMetrix før flytting til Enterprise webhotell

Etter flytting til Enterprise webhotell

ab fra Norge

# ab -n 300 -c 2 http://no.trondheim.com/
This is ApacheBench, Version 2.3 <$Revision: 655654
gt; Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking no.trondheim.com (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Finished 300 requests Server Software: LiteSpeed Server Hostname: no.trondheim.com Server Port: 80 Document Path: / Document Length: 21846 bytes Concurrency Level: 2 Time taken for tests: 35.143 seconds Complete requests: 300 Failed requests: 0 Write errors: 0 Total transferred: 6735600 bytes HTML transferred: 6553800 bytes Requests per second: 8.54 [#/sec] (mean) Time per request: 234.287 [ms] (mean) Time per request: 117.144 [ms] (mean, across all concurrent requests) Transfer rate: 187.17 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 3 3 0.2 3 5 Processing: 217 231 15.5 228 380 Waiting: 208 220 14.7 218 369 Total: 220 234 15.5 231 383 Percentage of the requests served within a certain time (ms) 50% 231 66% 234 75% 235 80% 236 90% 240 95% 247 98% 273 99% 325 100% 383 (longest request)

ab fra Tyskland

# ab -n 300 -c 2 http://no.trondheim.com/
This is ApacheBench, Version 2.3 <$Revision: 655654
gt; Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking no.trondheim.com (be patient) Completed 100 requests Completed 200 requests Completed 300 requests Finished 300 requests Server Software: LiteSpeed Server Hostname: no.trondheim.com Server Port: 80 Document Path: / Document Length: 21846 bytes Concurrency Level: 2 Time taken for tests: 47.443 seconds Complete requests: 300 Failed requests: 0 Write errors: 0 Total transferred: 6735600 bytes HTML transferred: 6553800 bytes Requests per second: 6.32 [#/sec] (mean) Time per request: 316.284 [ms] (mean) Time per request: 158.142 [ms] (mean, across all concurrent requests) Transfer rate: 138.65 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 31 33 0.8 33 36 Processing: 269 282 10.4 281 386 Waiting: 237 249 10.3 248 353 Total: 301 315 10.5 313 420 Percentage of the requests served within a certain time (ms) 50% 313 66% 316 75% 317 80% 318 90% 322 95% 327 98% 337 99% 369 100% 420 (longest request)

Pingdom Website Speed Test

Pingdom etter flytting til Enterprise webhotell

GTMetrix

GTMetrix etter flytting til Enterprise webhotell

Forbedringer som følge av flyttingen til Enterprise webhotell

Det som er verdt å merke seg i forhold til forskjellene mellom før og etter for ab testene i Norge er at gjennomsnittlig lastetid er gått ned fra 513ms til 234ms, noe som tilsvarer en reduksjon på ca. 54%. Vi ser også at forskjellen på laveste lastetid til høyeste lastetid er gått fra 722ms til 149ms, noe som innebærer at besøkende til nettsiden nå ikke vil oppleve store variasjoner i lastetiden som de kanskje gjorde før.

Pingdom og GTMetrix testene viser også at innholdet som lastes ned er redusert fra ca. 1.9mb til 1.0mb. Dette skyldes i hovedsak at det ikke var satt på noen form for komprimering på forrige server, mens LiteSpeed er satt opp til å automatisk komprimere innholdet. Vi ser også at den totale lastetiden ca. 37% for Pingdom og 21% for GTMetrix. Årsaken til at reduksjonen er lavere for disse enn for ab testene er i hovedsak at ab testene kun laster ned HTML koden som vises på siden, mens de 2 andre laster ned alle elementer (bilder, CSS filer mm.) som inkluderer det som ligger på webhotellet hos oss og på eksterne servere.

Ab testene er relativt like med unntak av avstanden mellom Norge og Tyskland både før og etter flytting. Vi har tatt med ab fra 2 lokasjoner kun for å bekrefte resultatene fra mer enn en lokasjon.

Oppsummering:
Vi kan slå fast at det har vært en markant forbedring på lastetiden etter flytting til Enterprise webhotell, samt at den varierer i mye mindre grad enn før. Reduksjonen på størrelsen på det som lastes ned er også redusert markant, noe som er svært fordelaktig i forhold til enheter som befinner seg på tregere nett. Alle forbedringene kommer uten at noen endringer er utført på eksisterende løsning. Dersom vi hadde aktivert Joomla LSCache hadde lastetiden vært redusert ytterligere.

Ønsker du å flytte til Enterprise webhotell?

Har du en nettside du kan tenke deg å flytte til våre Enterprise webhotell? Ta kontakt så kan vi være behjelpelige i forhold til flytting, benyttelse av cache i LiteSpeed (om aktuelt) og presentere resultatet dersom nettsiden benytter en løsning som ikke allerede er presentert.

*Grunnet etiske prinsipper og retningslinjer kan vi ikke omtale kunden nærmere, noe vi kommer til å gjøre for andre nettsider i kommende blogginnlegg så sant ikke samme omstendigheter gjelder.