WordPress i sigurnost (WP Security How-to guide on Croatian)

Autentifikacija, autorizacija i role unutar WP projekta se trebaju jasno i jednoznačno definirati. Glavni administratorski račun omogućite samo za glavne programere, maksimalno njih dvoje ili troje. Vlasnici sadržaja ili osobe koje odobravaju sadržaj (popularno agilno: Product Owner) bi trebali dobiti rolu urednika (Editor), dok je osobama koje kreiraju sadržaj namijenjena rola autora ili suradnika (suradnik može pisati ali ne može objaviti svoj sadržaj). WordPress podržava i prilagođene role korisnika. One bi mogle biti potrebne pri produkciji većih medijskih portala (npr. fotografi koji imaju omogućen pristup knjižnici medijskih zapisa no ne mogu pristupiti člancima). Unutar državnih WP projekata radi otprilike 20 do 30 ljudi, a spomenute nativne role su dovoljne za određivanje prava pristupa svih korisnika.

Poanta ove točke je slijedeća – ograničavanjem administratorskog pristupa na dvoje ili troje ljudi smanjujete najveći prozor napada na WordPress – automatizirane robote (botove) koji se pokušavaju prijaviti na sustav kao glavni administrator te potajno preuzeti kontrolu nad cijelim web sjedištem. Radi se o igri velikih brojeva – na svijetu postoji više milijuna WordPress instalacija, a velika većina njih ostavlja default username “admin” za prijavu u administratorski dio web sjedišta. S time napadač treba pogoditi samo lozinku te dobiti potpunu kontrolu nad cijelim sadržajem.

Takvi dictionary brute-force napadi su automatizirani no lako ih se može spriječiti. Prvo i osnovno, promjenite default username iz “admin” u nešto smisleno tipa “IvicaKicmanovic”. Drugo, koristite generatore zaporki za kreiranje hashed lozinki. Treće, omogućite autentifikaciju u dva koraka ( 2FA ) nad administratorskim i uredničkim računima. WordPress također omogućava blokiranje prijave u sustav nakon neuspjelog trećeg pokušaja pa postavite i tu značajku kao četvrtu razinu zaštite od brute-force napada.

Osnovnu tehničku zaštitu na bazu podataka je lako postaviti. Prefiksacija MySQL tablica malim random znakovima (npr. mrz17zg_ posts ) će spriječiti trivijalne SQL injection napade jer napadač više ne zna standardni naziv jedne od tablica u bazi. Važna napomena: ovo je najosnovnija zaštita protiv SQL injectiona no otežat će napad “botova” koji čine 99% napada na WP instalacije.

Što se tiče sesija i kolačića (cookies), WordPress ih enkriptira pomoću tzv. “Saltova”. Ti sigurnosni ključevi se trebaju nanovo generirati za svaki portal koji radite, ali velika većina programera to zaboravlja. Ključeve možete generirati na slijedećoj adresi. Napredniju tehničku zaštitu možete lako postaviti. Ovdje mislim na whitelist/blacklist IP adrese koje imaju pristup administratorskom sučelju, spajanje WordPressa na bazu poznatih napadača (blacklist offenders list) te vremensko ograničavanje pristupa administratorskom sučelju.

Održavanje projekta i proaktivna analiza WordPress verzije je dio sigurnosnih postavki oko kojih treba voditi najviše brige. Prve opisane točke nisu toliki operativni izazov ukoliko slijedite utabane sigurnosne koncepte, a dodatne “zdrave” aktivnosti bi trebale uključivati slijedeće radnje:

• Svakodnevni backup svih datoteka i baza podataka na udaljeni enkriptirani server npr. CodeGuard
• GIT revizija programskog koda uz cloud Git storage poput BitBucket-a
• Kontinuirana nadogradnja WordPress “core” sustava i vanjskih plugin-ova na zadnje verzije. (Zgodan trik je da spojite RSS feed od samog plugina i WordPress core-a na Slack kanal od vaših programera (ili čak da pomoću Zapiera / IFTTT kreirate “taskove” nadogradnje čim autor objavi novu verziju plugin-a)
• Automatizirani nadzor WP instalacije uz file change detection monitor. Odlične vanjske usluge koje možete koristiti za ove namjene su StatusCake, Rollbar i New Relic. Sa ta tri alata ćete u svakom trenutku znati što se dešava sa WP instalacijom, a s New Relic-om možete podesiti i prilagođene alarme ukoliko se infrastruktura krene ponašati izvan zadanih gabarita npr. RAM usage > 35% / CPU % utilization > 10%