8 osnovnih nasvetov za zaščito strežnika spletnih aplikacij

V večini primerov morajo biti strežniki spletnih aplikacij javno dostopni, kar pomeni, da so izpostavljeni vsem vrstam groženj.


Mnoge od teh groženj so predvidljive in jih je enostavno izogniti, druge pa so neznane in vas lahko ujamejo brez strahu. Da bi zmanjšali možnost tega zadnjega primera, ponujamo seznam bistvenih nasvetov, da bodo strežniki spletnih aplikacij čim bolj varni.

Preden začnete s seznamom nasvetov, morate razumeti, da strežnik spletnih aplikacij ni otok. Strežnik je osrednja komponenta na kmetiji spletnih aplikacij, ki omogoča gostovanje in delovanje spletne aplikacije. Zato morate za zaščito upoštevati vse komponente, ki ga obdajajo, in zavarovati celotno okolje spletnih aplikacij.

Osnovno okolje za gostovanje in zagon spletnih aplikacij vključuje operacijski sistem (Linux, Windows), programsko opremo za spletni strežnik (Apache, Nginx) in strežnik baz podatkov. Če v katero koli od teh komponent vdrejo, bi napadalci lahko dobili dostop in izvedli vsa zlonamerna dejanja, ki jih želijo.

Prvi in ​​osnovni nasvet za varstvo okolja, kot je zgoraj opisano, je prebrati varnostne smernice in seznam najboljših praks za vsako od komponent. Ob tem pa si oglejmo številne varnostne smernice zdravega razuma, ki veljajo za skoraj vsako okolje spletnih aplikacij.

Požarni zid je demistificiran

Morda vas bo poskušal hitro pregledati, če pomislite: “Srečno, že imam požarni zid, ki ščiti moje omrežje.” A raje držite konje.

Vaš požarni zid morda skrbi za meje vaše mreže, preprečuje slabe in dobre fante, toda zagotovo pušča vrata za napadalce, da vdrejo na strežnik spletnih aplikacij.

Kako?

Preprosto: vaš požarni zid mora omogočiti vsaj dohodni promet v vratih 80 in 443 (to sta HTTP in HTTPS) in ne ve, kdo ali kaj poteka skozi ta vrata.

Za zaščito aplikacije morate požarni zid spletne aplikacije (WAF), ki posebej analizira spletni promet in blokira vse poskuse izkoriščanja ranljivosti, kot sta skriptno skriptanje ali vstavljanje kode. WAF deluje kot tipičen antivirus in antimalware: v podatkovnem toku išče znane vzorce in jih blokira, ko zazna zlonamerno zahtevo.

Za učinkovito delovanje mora imeti WAF svojo bazo podatkov stalno posodabljati z novimi vzorci groženj, da jih lahko blokira. Težava pri preprečevanju napadov na podlagi vzorca je, da je lahko vaša spletna aplikacija ena prvih tarč nove grožnje, za katero vaš WAF še ni seznanjen..

Zaradi tega vaša spletna aplikacija poleg omrežnega požarnega zidu potrebuje dodatne zaščitne plasti.

Poiščite ranljivosti, povezane s spletom

Ponovno ne mislite, da je vaš strežnik spletnih aplikacij brez ranljivosti samo zato, ker tako pravi vaš varnostni skener omrežja.

Omrežni skenerji ne morejo zaznati ranljivosti, specifičnih za aplikacijo. Če želite zaznati in odpraviti te ranljivosti, morate aplikacije postaviti pod vrsto testov in revizij, kot so penetracijski testi, skeniranje v črni okvir in revizija izvorne kode. Nobena od teh metod pa ni neprebojna. V idealnem primeru bi morali izvesti čim več njih, da odpravite vse ranljivosti.

Na primer varnostni skenerji, kot npr Netsparker, zagotovite, da nobena uporabna koda ne pride v proizvodno okolje. Lahko pa obstajajo logične ranljivosti, ki jih lahko odkrijemo le z ročnim pregledovanjem kode. Ročna revizija, poleg tega, da stane veliko, je človeška in zato nagnjena k napakam. Dobra ideja, da naredite tovrstno revizijo, ne da bi zapravili veliko denarja, jo vključite v razvojni postopek, večinoma s poučevanjem svojih razvijalcev.

Izobražite svoje razvijalce

Razvijalci mislijo, da njihove aplikacije delujejo v idealnih svetovih, kjer so viri neomejeni, uporabniki ne delajo napak in ni ljudi z neusmiljenimi nameni. Na žalost se morajo v nekem trenutku soočiti z vprašanji v resničnem svetu, zlasti v zvezi z informacijsko varnostjo.

Pri razvoju spletnih aplikacij morajo kodirniki poznati in izvajati varnostne mehanizme, da se zagotovi, da niso ranljive. Ti varnostni mehanizmi bi morali biti del vodnika o najboljših praksah, ki jih mora upoštevati razvojna skupina.

Revizija kakovosti programske opreme se uporablja za zagotavljanje skladnosti z najboljšimi praksami. Najboljše prakse in revizija so edini načini zaznavanja logičnih ranljivosti, na primer (na primer) prenosa nešifriranih in vidnih parametrov znotraj URL-ja, ki bi ga napadalec zlahka spremenil in naredil, kar želi.

Izklopite nepotrebno funkcionalnost

Ob predpostavki, da so spletne aplikacije čim manj napak in je spletna kmetija zavarovana, poglejmo, kaj lahko storimo na samem strežniku, da jo zaščitimo pred napadi.

Osnovni zdravi namig je zmanjšati število potencialno ranljivih vstopnih točk. Če lahko napadalci izkoristijo katero koli komponento spletnega strežnika, bi lahko bil celoten spletni strežnik v nevarnosti.

Sestavite seznam vseh odprta vrata in izvajate storitve ali demone na vašem strežniku in zaprete, onemogočite ali izklopite nepotrebne. Strežnika ne bi smeli uporabljati v noben drug namen kot za zagon spletnih aplikacij, zato razmislite o premikanju vseh dodatnih funkcij na druge strežnike v vašem omrežju.

Za razvoj, preskušanje in proizvodnjo uporabite ločena okolja

Razvijalci in preizkuševalci potrebujejo privilegije v okoljih, v katerih delajo, ki jih ne bi smeli imeti na strežniku aplikacij v živo. Tudi če jim slepo zaupate, bi lahko njihova gesla zlahka puščala in padla v nezaželene roke.

Poleg gesel in privilegijev v okolju za razvoj in testiranje običajno obstajajo zaledje, dnevniške datoteke, izvorna koda ali druge informacije za odpravljanje napak, ki lahko izpostavijo občutljive podatke, na primer uporabniška imena in gesla baze podatkov. Postopek uvajanja spletnih aplikacij bi moral opraviti skrbnik, ki mora zagotoviti, da po namestitvi aplikacije na strežnik v živo ni izpostavljenih nobenih občutljivih informacij..

Za podatke aplikacije je treba uporabiti isti koncept segregacije. Testerji in razvijalci imajo vedno raje resnične podatke, s katerimi delajo, vendar ni dobro, da bi jim omogočili dostop do proizvodne baze podatkov ali celo do njene kopije. Poleg očitnih pomislekov glede zasebnosti bi lahko baza podatkov vsebovala konfiguracijske parametre, ki razkrivajo notranje nastavitve strežnika – na primer naslove končnih točk ali imena poti.

Posodobite strežniško programsko opremo

Kot očitno se zdi, je to ena izmed najbolj spregledanih nalog. SUCURI je ugotovil, da je 59% aplikacij CMS zastarelo, kar lahko pomeni tveganje.

Vsakodnevno se pojavljajo nove grožnje in edini način, kako preprečiti, da bi ogrozil vaš strežnik, je vedno namestiti najnovejše varnostne popravke.

Prej smo omenili, da omrežni požarni zidovi in ​​omrežni varnostni skenerji ne zadostujejo za preprečevanje napadov na spletne aplikacije. Vendar so potrebne za zaščito vašega strežnika pred običajnimi grožnjami kibernetske varnosti, kot so napadi DDoS. Tako se prepričajte, da imate takšne aplikacije vedno posodobljene in da učinkovito ščitijo vašo poslovno aplikacijo.

Omejite dostop in privilegije

Osnovni varnostni ukrep je ohraniti šifriran in tuneliziran promet na daljavo – na primer RDP in SSH. Prav tako je dobro obdržati zmanjšan seznam naslovov IP, od koder je dovoljen oddaljeni dostop, in poskrbite, da je vsak poskus daljinske prijave iz katerega koli drugega IP-ja blokiran.

Administratorji občasno dajejo račune storitev vse možne privilegije, ker vedo, da s tem “bo vse delovalo.” Vendar to ni dobra praksa, saj lahko napadalci ranljivosti v storitvah uporabijo za prodor do strežnika. Če te storitve delujejo s skrbniškimi pravicami, lahko zasedejo celoten strežnik.

Dobro razmerje med varnostjo in praktičnostjo zahteva, da ima vsak račun – tako prijavni računi kot računi storitev – privilegij, ki ga potrebuje za opravljanje svojega dela in nič drugega.

Na primer, lahko določite različne račune, da lahko skrbnik opravi različne naloge: eni za izdelavo varnostnih kopij, drugi za čiščenje dnevniških datotek, drugi za spreminjanje konfiguracije storitev in podobno. Enako velja za račune baze podatkov: aplikacija običajno potrebuje samo dovoljenja za branje in pisanje podatkov, ne pa za ustvarjanje ali spuščanje tabel. Zato bi moral imeti račun z omejenimi privilegiji za opravljanje nalog, ki jih potrebuje za opravljanje.

Pazite na dnevnike strežnikov

Dnevniške datoteke so tam z razlogom.

Skrbniki bi jih morali redno spremljati, da bi odkrili kakršno koli sumljivo vedenje, preden naredi škodo. Z analizo datotek dnevnikov lahko odkrijete veliko informacij, da boste lažje zaščitili aplikacijo. Če bi se napad zgodil, bi lahko datoteke datotek prikazale, kdaj in kako se je začel, kar bi pripomoglo k boljšemu nadzoru škode.

Prav tako morate imeti samodejen postopek za brisanje starih dnevniških datotek ali obrezovanje zastarelih informacij, da preprečite, da bi porabili ves razpoložljivi prostor za shranjevanje v strežniku.

Nasvet o bonusu: informirajte se

V internetu je na voljo veliko brezplačnih in koristnih informacij, ki jih lahko uporabite v korist svoje spletne aplikacije. Ne zamudite nobene nove objave na uglednih varnostnih blogih (kot je ta) in bodite obveščeni o dogajanju v varnostni in spletni industriji.

Vadnice, tečajev, videoposnetki in knjige so tudi viri koristnega znanja. Vadite eno ali dve uri na teden samo zato, da boste obveščeni o novostih v industriji – zagotovili vam boste brezskrbnost, če veste, da delate pravilno, da bodo zaščitene aplikacije.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map