Obezbeđivanje domena i sajta

Puno puta sam čuo sledeću priču: “angažovan je freelancer za izradu sajta, došlo je do nekog nesporazuma/problema, pa do ucene gubitkom sajta, ili/i domena ako ne platim”. Ili: “registrovan je domen preko hosting provajdera, ali hoću da menjam provajdera, a šta će biti sa domenom?” U ovom članku baviću se tim i sličnim problemima, objasniti kako se mogu izbeći i – kako naslov kaže – objasniti kako da se zaštiti domen i sav trud uložen u kreiranje kvalitetnog sadržaja.

Objasniću ukratko i širu sliku vezanu za zaštitu i bezbednost, pošto mislim da je to važno kako bi se moglo shvatiti sve o čemu se priča – a ne da se samo radi napamet, po instrukcijama. Spremite kafu, ili čaj, ovo će biti dugačak članak, ali nadam se da će vredeti – mada moram napomenuti da vam 30 minuta potrebnih za čitanje niko nikada neće vratiti.

Sadržaj:

1. Uvod
2. Vektori napada na sajt – objašnjenje
   2.1. Socijalni inženjering
3. Najslabija karika – bezbednost poput lanca
4. Slojevi – bezbednost poput luka
5. Zaštita domena i sajta – u celini
6. Kako se zaštititi ako radite sa developerom / freelancerom
7. Moje lično mišljenje i iskustvo
8. Video – kreiranje i bezbedno čuvanje jakih lozinki

1. Uvod

Prvo da se ogradim: nisam nikakav ekspert za sigurnost. Sve informacije date u ovom (i ostalim člancima na sajtu) su na osnovu mog dosadašnjeg iskustva i znanja, u smislu: “koliko ja znam”.

Postoji dobra izreka: “poštenog čoveka ne možeš prevariti”. Drugim rečima, većina prevara bazira se na ljudskoj pohlepi: ljudi ne žele propustiti nešto što deluje kao odlična prilika (često na očiglednu štetu onoga ko je nudi) i zanemare normalan oprez i zdrav razum (“šta ti dobijaš od toga?”, “kako se tebi to isplati?”).

Isto tako, mnogi ljudi veruju svemu što pročitaju, ili vide – bez osnovnog preispitivanja.

Konkretan primer ovog drugog su plagini za redirekciju kada se u WordPress-u promeni struktura permalinkova. U ranijim verzijama WordPress nije radio sam automatske redirekcije i takvi plagini su bili neophodni. Sada ih radi potpuno automatski – sa poslednje verzije permalinkova. Napisao sam i članak o promeni permalinkova i automatskim redirekcijama. Ipak, postoji gomila članaka na Internetu gde ljudi pišu kako su prilikom promene strukture permalinkova neophodni plagini, ili .htaccess redirekcije. Ovo provereno nije tačno (način testiranja tako da možete sami proveriti sam pružio u linkovanom članku).

U tom smislu: pročitajte boldovanu rečenicu u pasusu iznad (druga rečenica po redu). Znate šta? Nemam pojma da li je tačna (deo o tome da stare verzije WordPress-a ne prave automatske redirekcije – to nisam nikad testirao). Jeste mi bili poverovali da to pouzdano i provereno znam? Vidite o čemu pričam? Ne radim ovo inače, sad sam uradio namerno kako bih demonstrirao na šta mislim. Obično naglasim kada u vezi nečega nisam siguran i izbegavam takve tvrdnje za stvari koje nisam proverio. Da li to svi rade? Mnogi ljudi ponavljaju nešto što su pročitali/čuli, iznoseći to kao utvrđenu činjenicu. Kao papagaji, rekao bih.

Sa kritičkim razmišljanjem, zdravim razumom i malo opreza možete dogurati daleko kad je bezbednost u pitanju.

Za kraj ovog dugačkog uvoda, par reči o developerima / freelancerima: mnogi od njih zavise od dobre reputacije i preporuka. Verujem da većini nije cilj da bilo koga prevare, ili oštete. Većina problema o kojima sam imao priliku čuti, ili ih iskusiti, su zbog nesporazuma, loše komunikacije, nedovoljno jasnog definisanja šta sve treba da se uradi, ili klijentovog nerazumevanja procesa izrade sajta (čak i kad se sve lepo objasni). Na primer:

“Super je sajt – možeš još ubaciti verziju na engleskom na svakoj strani? Ništa komplikovano – samo da bude ona zastavica za izbor jezika”.

Ne pada mi trenutno bolji primer na pamet, ali vezano za ovaj: ne nude svi plaginovi podršku za više jezika, ili je nude samo u plaćenoj verziji, što drastično podiže cenu, ili/i traži više vremena (što opet košta jer freelanceri koji rade za džabe umru od gladi). Funkcija koja deluje trivijalno klijentu, pa se to i zaboravi spomenuti na početku, može dosta zakomplikovati stvari.

2. Vektori napada na sajt – objašnjenje

Vektori napada su važan termin / koncept koji je dobro shvatiti. Kako bih lakše objasnio, predlažem da zamislimo sajt (ili domen, ili bilo šta što se štiti) kao kuću i razmotrimo vektore napada:

Vektori napada su prikazani crvenim strelicama. Za nekog ko pokušava neovlašteno ući u kuću sa slike, vektori napada 1 i 2 teško da imaju smisla i tražili bi puno više muke, u odnosu na vektor napada 3 – kroz staklena vrata.

U tom smislu, kad se razmatra bezbednost, treba videti koji sve vektori napada postoje i obezbediti prvo najslabije tačke, kao i vektore napada koji su najizgledniji, najčešće korišteni (slabe tačke i često korišteni vektori napada nisu uvek isto). Za kuću sa slike 1: stavljanje rešetki na vrata i prozore, sa dobrim bravama, bi verovatno bio dobar prvi korak.

Vektori napada nisu neki unapred poznati skup – uvek se javljaju novi, do tada nepoznati i nekorišteni, tako da bezbednost nije nešto što se uradi jednom, to je proces.

2.1. Socijalni inženjering

Ali – šta ako znamo da vlasnik kuće voli da se kupa na određenoj plaži – da li bismo mogli iskoristiti priliku i ukrasti ključeve kuće sa plaže dok pliva? Ili ga nekako navesti da nam da ključeve, makar na kratko (koliko je potrebno da napravimo kopiju) – ako se predstavimo kao majstori i slično? Ovaj vektor napada naziva se socijalni inženjering. Često se koristi, a često se ne uzima u obzir.

Pod ovo spadaju: kliktanje na mejl gde se pošiljalac lažno predstavlja kao vaša banka, YouTube, Google, hosting provajder, domen registrar itd – proverite zaglavlja kada god vam se traži kliktanje na link, ili/i davanje podataka. Članak na tu temu: Kako bezbedno rukovati mejlovima.

Isto važi za davanje pristupa vašem računaru, mobilnom, radnim prostorijama itd.

3. Najslabija karika – bezbednost poput lanca

Ovoga sam se dotakao u prethodnom poglavlju, razmatrajući vektore napada. Bezbednost se može posmatrati na dva načina. Prvi je: lanac. Jak koliko i najslabija karika. Drugi je objašnjen u narednom poglavlju.

Pošto volim analogije, evo još jedne prigodne slike:

Kako vam se sviđa zaštita sa slike 3? Analogije vezano za sajtove bi bile:

• Odična lozinka, ali neobezbeđen mejl nalog za reset lozinke (registraciju naloga).
• Odlična lozinka koja se koristi na više različitih mesta (sajtova, naloga) – ako se bilo koji od njih hakuje i provali lozinka, odmah su i ostali kompromitovani.
• Dobra brute force zaštita (blokiranje IP adrese posetioca posle X neuspešnih logovanja), ali slaba lozinka (poput: “admin123”).
• Nekorištenje enkripcije, ili dobre zaštite, već oslanjanje na sakrivanje linka za login (loš primer bezbednosti sakrivanjem), često od strane korisnika nazvano i “bolje nego ništa” zaštita. Uz napomenu da bezbednost kroz sakrivanje nije loša sama po sebi – loše je ako je to jedini vid bezbednosti (ili ako uvodi druge probleme).

Nadam se da je ovo dobro objašnjeno. Pogledajmo sad na bezbednost iz još jednog ugla:

4. Slojevi – bezbednost poput luka

U ovom članku, do sada smo se bavili bezbednošću samo na nivou jednog sloja. Sad zamislite kuću sa slike 1, koja je okružena ogradom sa kapijom (ne samo kapijom koja jedino zatvara prilazni put kao na slici 3). To bi bio dodatni sloj sigurnosti. Na slici 4, koristićemo primer koji je više vezan za sajtove:

Dakle, zaštita logovanja na sajt sa tri sloja: 1. sloj blokira velik broj neuspešnih pokušaja logovanja (kako bi se teže pogodila lozinka), 2. sloj čini jaka lozinka (idealno sa korisničkim imenom koje nije javno dostupno), a treći sloj čini 2FA, što sprečava neovlašten pristup čak i ako neko probije prethodna dva sloja, tj. “provali” lozinku.

Ne treba zanemariti ni zabranu fizičkog pristupa neovlaštenih lica serveru, zbog čega je važno birati pouzdane hosting provajdere.

5. Zaštita domena i sajta – u celini

• Da biste registrovali domen, morate kreirati nalog na domen registraru – sa mejl adresom koji ćete koristiti.
• Kada otvarate nalog kod hosting provajdera – opet morate koristiti neki mejl.
• Za WordPress sajt, pogađate, takođe je potreban neki mejl vezan za administratorski nalog.

Jasno vam je kuda ovo ide? Vidite koliko je važno imati pouzdan mejl nalog?

Naravno, ovo se sve radi sa računara (OK, mnogi koriste i pametne telefone, mada nisam siguran koliko je to pametno). Kako obezbediti računar, lozinke i generalno o bezbednim navikama, pisao sam u članku o zaštiti (WordPress) sajta. Preporučujem da omdah sada pročitate prvih 5 poglavlja u tom članku, pa se vratite ovde.

Da pogledamo sad kako cela ova priča izgleda grafički prikazano:

2FA je nacrtan kao džoker – može se koristiti za zaštitu logovanja i na mejl, i na domen registrar, hosting server, kao i sam sajt.

Pri tome: sav sadržaj sajta se može vratiti iz bekapa sajta. Srušen server se može ponovo podići, ili migrirati sajt na drugi. Ali, ako izgubite kontrolu nad domenom, to je muka posle vraiti (dokazati vlasništvo, naterati registrar “novog vlasnika” da domen vrati, ili vama vrati kontrolu nad vašim nalogom…). Ako se ne vrati kontrola nad domenom, svi rezultati Google rangiranja, beklinkovi itd. će biti izgubljeni.

Isto tako, ako izgubite kontrolu nad mejl nalogom korištenim za pravljenje naloga na domenu (i ostalim servisima), opet je veoma komplikovano to promeniti (mada ne i nemoguće).

Da ne zaboravim i najvažnije: koristite dobre i pouzdane domen registrare. Lično koristim i preporučujem Namecheap i Porkbun (affiliate linkovi). Moje ocene Namecheap i Porkbun domen registrara.

6. Kako se zaštititi ako radite sa developerom / freelancerom

Na prvom mestu razuman oprez i zdrav razum – detaljnije objašnjeni u 1. poglavlju.

Ažuriranje 2024:
Vezano za web hosting, angažovanje agencija i frilansera, možda vredi da pročitate moj članak “Tražite bolje, a ne jeftinije.”

Zatim: bekap sajta. Ako imate već puno kreiranog sadržaja, sačuvajte svoj bekap pre angažovanja trećih lica za rad na sajtu.

Hosting nalog: ako je potrebno da se treće lice uloguje na hosting nalog (tj. ako samo FTP login nije dovoljan), tehnički mogu izmeniti lozinku, a kod mnogih provajdera, i kontakt podatke. Praktično vas isključujući sa vašeg hosting naloga. Ako plaćate PayPal-om, svako naručivanje dodatnih usluga ćete imati priliku da stopirate (tj. stopirate plaćanje za isto). Ako ste registrovali karticu kod hosting provajdera (Visa i sl.), onda ćete možda moći preko svoje banke osporiti naplatu. U svakom slučaju, ako se promeni lozinka za logovanje, trebalo bi što pre stupiti u kontakt sa hosting provajderom, objasniti tačno o čemu se radi i blokirati nalog, sa resetom lozinke i kontakt mejla na one koje vi kontrolišete. Pre toga, za svaki slučaj, proveriti sa angažovanim developerom da nije neka zabuna u pitanju. Isto važi i u slučaju bilo kakvih neočekivanih “kupovina” na hosting nalogu.

Reseller hosting je zahvalan u ovom smislu, pošto ne morate davati podatke za glavni reseller nalog, dok se sa kreiranih pod-naloga ne mogu kupovati dodatne usluge, a i lako ćete im sami resetovati lozinku i ostale podatke.

DNS: ako se koristi Cloudflare, moguće je dodati prava drugom korisniku, ali da on ne dobije vlasništvo nad nalogom. Opcije se nalaze u “Members” delu glavnog menija. Bilo bi dobro uraditi eksport DNS podešavanja pre toga, za svaki slučaj. Ne znam kakva je situacija sa drugim DNS servisima po ovom pitanju.

Ako se koristi DNS sa hosting naloga (cPanel, ili DirectAdmin), videti pod “Hosting nalog” iznad.

Google Analytics: pod “Admin” opcijom u glavnom meiju, pa “Account User Management”, može se dodati bilo koji gmail nalog i odrediti mu nivo pristupa (i ukinuti kada se želi). Kako povezati Google Analytics sa sajtom.

Google Search Console: Klik na “Settings”, pa na “Users and permissions”, zatim na “Add user”. Mogu se dodeliti različita prava, po želji – “Full” (puna), ili “Restricted” (ograničena). Gugl dokumentacija, klikom na “Permission details” objašnjava kakva prava koji korisnik ima – Managing owners, users, and permissions. Članak koji objašnjava kako povezati sajt sa Google Search Console.

Domen registrar: ako nekome verujete dovoljno sa ključevima od stana, možete mu/joj dati i podatke za logovanje na domen registrar. Valjda. Developer može tražiti da podesite nameserver koji je potreban, što je u redu. Ulogujte se i sami podesite nameservere koje treba. Da bi ste nekom dali da se uloguje na vaš domen registrar, potrebno je puno poverenja i dobar razlog zašto.

7. Moje lično mišljenje i iskustvo

Više prava i više poverenja nosi i veću odgovornost. Većina klijenata me pronalazi preko dobrih preporuka. Sa većinom imam dobar odnos i puno poverenja. Puno puta sam se logovao na hosting naloge, domen registrare, čak i naručivao servise preko kartica klijenata (nakon što sam zamoljen za to). Mnogim ljudima je jednostavno lakše da nađu nekog od poverenja i ne misle o tehničkim stvarima.

Sad, takav nivo poverenja sigurno laska, ali i opterećuje. Uglavnom apelujem na to da, čak i ako dobijem lozinku za logovanje, ona bude promenjena nakon što završim posao. U slučaju bilo kakvih problema, lakše je naći krivca kada je broj osumnjičenih najmanji mogući.

Da, izuzeci se mogu praviti za ljude sa kojima čovek ima dugoročnu saradnju, koji su praktično deo tima. Ipak, oprez nije isto što i sumnja. Ja čuvam lozinke u kriptovanom obliku, koristim za posao Linux računar sa kriptovanom particijom i generalno, po prirodi posla, imam malo veću dozu opreza od “normalnih ljudi”. Da li su takvi svi developeri? Pa, čak bih rekao: “nadam se da nisu”. 🙂

Neću da ovo zvuči ni kao neko lično hvaljenje, ni kao pritužba na klijente. Glavni cilj ovog članka je davanje osnovnih informacija vezano za zaštitu. Da ljudima pomogne u zaštiti njihovih domena i sajtova – svog truda i novca uloženog u njih.

8. Video – kreiranje i bezbedno čuvanje jakih lozinki