8 Bitnih savjeta za osiguravanje poslužitelja web aplikacija

U većini slučajeva poslužitelji web aplikacija moraju biti javno dostupni, što znači da su izloženi svim vrstama prijetnji.


Mnoge od tih prijetnji su predvidljive i lako ih je izbjeći, dok su druge nepoznate i mogu vas uhvatiti izvan zaštite. Kako bismo umanjili mogućnost ovog potonjeg slučaja, nudimo popis bitnih savjeta kako da poslužitelji web aplikacija budu što sigurniji.

Prije nego što započnete s popisom savjeta, morate shvatiti da poslužitelj web aplikacija nije otok. Poslužitelj je središnja komponenta na farmi web aplikacija koja omogućuje hosting i rad web aplikacije. Stoga, da biste osigurali, morate uzeti u obzir sve komponente koje ga okružuju i osigurati cjelokupno okruženje web aplikacija.

Osnovno okruženje za hosting i pokretanje web aplikacija uključuje operativni sustav (Linux, Windows), softver za webserver (Apache, Nginx), poslužitelj baze podataka. Ako se bilo koja od ovih komponenti provali u napad, napadači mogu dobiti pristup i izvršiti sve zlonamjerne radnje koje žele.

Prvi i osnovni savjet za osiguranje okruženja poput onog opisanog gore je čitanje sigurnosnih smjernica i popisa najboljih praksi za svaku od komponenti. U skladu s tim, razmotrimo nekoliko sigurnosnih smjernica koje se odnose na zdrav razum i odnose se na gotovo svako okruženje web aplikacija.

Vatrozid je demistificiran

Možda ćete biti u iskušenju da brzo pregledate ovaj predmet, misleći: “Srećno, imam vatrozid koji štiti mrežu.” Ali bolje je da držiš svoje konje.

Vaš vatrozid može voditi brigu o granicama vaše mreže, sprečava loše dečke i dobre dečke, ali sigurno ostavlja vrata širom otvorena za napadače da probiju na poslužitelju vaše web aplikacije.

Kako?

Jednostavno: vaš mrežni vatrozid mora barem dopustiti dolazni promet na priključcima 80 i 443 (to su HTTP i HTTPS) i ne zna tko ili što prolazi kroz te priključke.

Ono što trebate da biste zaštitili svoju aplikaciju je vatrozid web aplikacije (WAF) koji posebno analizira web promet i blokira svaki pokušaj iskorištavanja ranjivosti kao što su skripti na više mjesta ili ubrizgavanje koda. WAF djeluje poput tipičnog antivirusnog i antimalware-a: traži poznate uzorke u protoku podataka i blokira ih kada otkrije zlonamjeran zahtjev..

Da bi bio učinkovit, WAF mora svoju bazu podataka stalno ažurirati novim obrascima prijetnji, kako bi ih mogao blokirati. Problem s prevencijom napada temeljen na uzorku je taj što vaša web aplikacija može biti jedna od prvih meta nove prijetnje za koju vaš WAF još nije svjestan..

Iz tih razloga vaša web aplikacija zahtijeva dodatne zaštitne slojeve osim mrežnog vatrozida.

Skenirajte na web-ranjivosti

Opet, nemojte misliti da je vaš poslužitelj web aplikacija bez ranjivosti samo zato što vaš mrežni sigurnosni skener to kaže.

Mrežni skeneri ne mogu otkriti ranjivosti specifične za aplikaciju. Da biste otkrili i uklonili ove ranjivosti, aplikacije morate podvrgnuti nizu testova i revizija, poput penetracijskih testova, skeniranja crne kutije i revizije izvornog koda. Ipak, nijedna od ovih metoda nije probojna. U idealnom slučaju, trebali biste izvesti što više njih kako biste uklonili sve ranjivosti.

Na primjer, sigurnosni skeneri, poput Netsparker, osigurati da nijedan iskoristivi kod ne dođe u proizvodno okruženje Ali mogu postojati logične ranjivosti koje se mogu otkriti samo ručnom revizijom koda. Ručna revizija, osim što košta puno, je ljudska i, prema tome, metoda sklona pogreškama. Dobra ideja da se takva revizija obavi bez trošenja puno novca je da se ugradi u razvojni proces, uglavnom educirajući programere..

Educirajte svoje programere

Programeri obično misle da se njihove aplikacije pokreću u idealnim svjetovima, gdje su resursi neograničeni, korisnici ne prave pogreške i nema ljudi s bezobzirnim namjerama. Nažalost, u nekom se trenutku trebaju suočiti sa stvarnim problemima, posebno onima koji se tiču ​​informacijske sigurnosti.

Prilikom razvoja web aplikacija koderi moraju znati i implementirati sigurnosne mehanizme kako bi se osiguralo da nisu ranjivi. Ti sigurnosni mehanizmi trebali bi biti dio vodiča najboljih praksi kojih se mora pridržavati razvojni tim.

Revizija kvalitete softvera koristi se za osiguravanje usklađenosti s najboljom praksom. Najbolje prakse i revizija jedini su načini otkrivanja logičkih ranjivosti, kao što je (na primjer) prolazak nekriptiranih i vidljivih parametara unutar URL-a, koje bi napadač mogao lako promijeniti da učini što želi.

Isključite nepotrebnu funkcionalnost

Pod pretpostavkom da su web-aplikacije što je moguće pogrešnije, a web-farma zaštićena, pogledajmo što se može učiniti na samom poslužitelju da bi se zaštitilo od napada.

Osnovni, zdravi razum savjet je smanjiti broj potencijalno ranjivih ulaznih mjesta. Ako napadači mogu iskoristiti bilo koju komponentu web poslužitelja, cijeli web poslužitelj može biti u opasnosti.

Napravite popis svih otvorene luke i pokretanje usluga ili demona na vašem poslužitelju i zatvorite, onemogućite ili isključite nepotrebne. Poslužitelj se ne bi trebao koristiti u bilo koju drugu svrhu osim pokretanja vaših web aplikacija, pa razmislite o premještanju svih dodatnih funkcija na druge poslužitelje u vašoj mreži.

Koristite zasebna okruženja za razvoj, testiranje i proizvodnju

Programeri i testeri trebaju privilegije u okruženjima u kojima rade i koje ne bi trebali imati na poslužitelju aplikacija uživo. Čak i ako im slijepo vjerujete, njihove lozinke lako bi mogle procuriti i pasti u neželjene ruke.

Osim zaporki i privilegija, u okruženju za razvoj i testiranje obično postoje zaledje, datoteke dnevnika, izvorni kôd ili druge informacije za uklanjanje pogrešaka koje mogu izložiti osjetljive podatke, poput korisničkih imena i lozinki baze podataka. Postupak implementacije web aplikacije trebao bi obaviti administrator, koji mora osigurati da nisu izložene osjetljive informacije nakon instaliranja aplikacije na live server.

Na podatke aplikacije treba primijeniti isti koncept segregacije. Ispitivači i programeri uvijek preferiraju stvarne podatke s kojima rade, ali nije dobra ideja dodijeliti im pristup proizvodnoj bazi podataka, ili čak njihovoj kopiji. Osim očiglednih nedoumica u vezi s privatnošću, baza podataka može sadržavati konfiguracijske parametre koji otkrivaju interne postavke poslužitelja – kao što su adrese krajnjih točaka ili imena staza, za imenovanje nekoliko.

Redovno ažurirajte softver vašeg poslužitelja

Koliko god očito izgledalo, ovo je jedan od najnevidljivijih zadataka. SUCURI je ustanovio da je 59% CMS aplikacija zastarjelo, što je otvoreno za rizik.

Nove prijetnje pojavljuju se svakodnevno, a jedini način da se spriječi da ugroze vaš poslužitelj jest uvijek instalirati najnovije sigurnosne zakrpe.

Prije smo spomenuli da mrežni zaštitni zidovi i mrežni sigurnosni skeneri nisu dovoljni da spriječe napade na web aplikacije. Ali oni su potrebni kako bi zaštitili vaš poslužitelj od uobičajenih prijetnji cyber-sigurnosti, poput DDoS napada. Stoga provjerite imate li takve aplikacije uvijek ažurirane i da učinkovito štite vašu poslovnu aplikaciju.

Ograničite pristup i privilegije

Osnovna sigurnosna mjera je zadržavanje prometa na daljinu – kao što su RDP i SSH – šifrirano i tunirano. Također je dobra ideja smanjiti popis IP adresa s mjesta gdje je udaljeni pristup dopušten, pri čemu je svaki pokušaj daljinske prijave s bilo kojeg drugog IP-a blokiran..

Administratori povremeno servisnim računima daju sve moguće privilegije jer znaju da će, radeći to, “sve funkcionirati.” Ali to nije dobra praksa jer napadači mogu iskoristiti ranjivosti u uslugama da bi prodrli na poslužitelj. Ako se te usluge pokreću s povlasticama administratora, mogu zauzeti cijeli poslužitelj.

Dobra ravnoteža između sigurnosti i praktičnosti zahtijeva da svaki račun – i računi za prijavu i računi za usluge – ima povlastice potrebne za obavljanje svog posla i ništa drugo.

Na primjer, možete definirati različite račune za administratora koji može obavljati različite zadatke: jedan za izradu sigurnosnih kopija, drugi za čišćenje datoteka dnevnika, drugi za promjenu konfiguracije usluga i tako dalje. Isto se odnosi i na račune baze podataka: aplikaciji su obično potrebna samo dopuštenja za čitanje i pisanje podataka, a ne za stvaranje ili ispuštanje tablica. Stoga bi trebao imati račun s povlasticama ograničenim za obavljanje zadataka koje je potrebno za obavljanje.

Pazite na zapisnike poslužitelja

Datoteke dnevnika nalaze se s razlogom.

Administratori bi ih trebali redovito nadgledati kako bi otkrili bilo kakvo sumnjivo ponašanje prije nego što nanesu bilo kakvu štetu. Analizom datoteka dnevnika možete otkriti puno informacija koje će vam pomoći da bolje zaštitite aplikaciju. Ako se napad dogodi, datoteke dnevnika mogu vam pokazati kada i kako je započeo, pomažući u boljoj kontroli štete.

Morate imati i automatizirani postupak za brisanje starih datoteka dnevnika ili obrezivanje zastarjelih podataka kako bi se spriječilo da troše sav dostupni prostor za pohranu na poslužitelju..

Savjet o bonusu: informirajte se

Na internetu postoji puno besplatnih i korisnih informacija koje možete koristiti u korist svoje web aplikacije. Ne propustite nijedan novi post na uglednim sigurnosnim blogovima (poput ovog) i budite informirani o onome što se događa u sigurnosnoj i web industriji.

Tutoriali, tečajevi, videozapisi i knjige su također izvor korisnog znanja. Vježbajte trošiti jedan ili dva sata tjedno samo zato da budete informirani o novostima u industriji – pružit će vam mirnoću znajući da radite ispravno kako biste zaštitili svoje 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