8 noodsaaklike wenke om die webtoepassingsbediener te beveilig

In die meeste gevalle moet bedieners van die webtoepassing in die openbaar toeganklik wees, wat beteken dat hulle blootgestel word aan allerlei bedreigings.


Baie van hierdie dreigemente is voorspelbaar en maklik vermybaar, terwyl ander onbekend is en u in die wiele ry. Om die moontlikheid van laasgenoemde geval tot die minimum te beperk, bied ons ‘n lys van belangrike wenke om bedieners van die webtoepassing so veilig as moontlik te hou.

Voordat u met die fooi-lys begin, moet u verstaan ​​dat ‘n webtoepassingsbediener nie ‘n eiland is nie. Die bediener is die sentrale komponent op die webtoeplaasplaas wat die gasheer en bedryf van ‘n webtoepassing moontlik maak. Om dit te beveilig, moet u dus rekening hou met al die komponente wat daar rondom is en die hele webtoepassingsomgewing beveilig.

‘N Basiese omgewing vir die aanbieding en bestuur van webtoepassings sluit die bedryfstelsel (Linux, Windows), die webbediener-sagteware (Apache, Nginx), ‘n databasisbediener in. As een van hierdie komponente ingebreek word, kan aanvallers toegang verkry tot al die kwaadwillige handelinge wat hulle wil hê.

‘N Eerste en basiese wenk om ‘n omgewing te verseker, soos hierbo beskryf, is om die veiligheidsriglyne en beste praktyklys vir elk van die komponente te lees. Dit gesê, kom ons kyk na ‘n aantal veiligheidsriglyne vir gesonde verstand wat van toepassing is op byna elke webtoepassingsomgewing.

Die firewall is ontmystifiseer

U kan miskien in die versoeking kom om hierdie artikel vinnig na te gaan en te dink: “Geluk, ek het al ‘n firewall wat my netwerk beskerm.” Maar u moet u perde beter vashou.

U firewall sorg moontlik vir die grense van u netwerk en hou die slegte ouens buite en die goeie ouens in, maar dit laat ‘n deur oop vir aanvallers om u webtoepassingsbediener in te breek.

hoe?

Eenvoudig: u netwerk firewall moet ten minste inkomende verkeer toelaat op poorte 80 en 443 (dit is HTTP en HTTPS), en weet nie wie of wat deur daardie poorte gaan nie..

Wat u nodig het om u aansoek te beskerm, is ‘n webtoepassings firewall (WAF) wat die webverkeer spesifiek ontleed en elke poging om kwesbaarhede te benut, soos skripwerk op die terrein of kode-inspuiting, blokkeer. ‘N WAF werk soos ‘n tipiese antivirus en antimalware: dit soek na bekende patrone in die datastroom en blokkeer dit wanneer dit ‘n kwaadwillige versoek opspoor.

Om effektief te wees, moet die WAF sy databasis voortdurend opgedateer hê met nuwe bedreigingspatrone om dit te kan blokkeer. Die probleem met patroongebaseerde aanvalvoorkoming is dat u webtoepassing een van die eerste teikens kan wees vir ‘n nuwe bedreiging waarvan u WAF nog nie bewus is nie.

Om hierdie redes het u webtoepassing ekstra beskermingslae nodig buiten die netwerk firewall.

Soek na webspesifieke kwesbaarhede

Moet ook nie dink dat u webtoepassingsbediener kwesbaar is nie net omdat u netwerksekuriteitskandeerder so sê.

Netwerkskandeerders kan nie toepassingsspesifieke kwesbaarhede opspoor nie. Om hierdie kwesbaarhede op te spoor en uit te skakel, moet u die toepassings onder ‘n reeks toetse en oudits plaas, soos penetrasietoetse, swartkassieskandering en bronkode-ouditering. Geen van hierdie metodes is egter koeëlvast nie. Ideaal gesproke moet u soveel moontlik doen om alle kwesbaarhede uit te skakel.

Byvoorbeeld, sekuriteitskandeerders, soos Netsparker, sorg dat daar geen ontginbare kode in die produksieomgewing verkry word nie. Daar kan egter logiese kwesbaarhede wees wat slegs opgespoor kan word deur handmatige kodesouditering. Handmatige ouditering, behalwe dat dit baie kos, is ‘n menslike en dus foutgevoerde metode. ‘N Goeie idee om hierdie soort ouditering te doen sonder om baie geld te mors, is om dit in te sluit in die ontwikkelingsproses, meestal deur u ontwikkelaars op te voed.

Leer u ontwikkelaars op

Ontwikkelaars is geneig om te dink dat hul toepassings in ideale wêrelde werk, waar hulpbronne onbeperk is, gebruikers nie foute maak nie, en daar is geen mense met genadeloos bedoelings nie. Ongelukkig moet hulle op ‘n sekere tydstip probleme in die wêreld in die gesig staar, veral die wat informasiesekuriteit betref.

By die ontwikkeling van webtoepassings moet coders sekuriteitsmeganismes ken en implementeer om te verseker dat dit vry is van kwesbaarhede. Daardie sekuriteitsmeganismes moet deel uitmaak van die gids vir beste praktyke waaraan die ontwikkelingspan moet voldoen.

Ouditering van sagtewarekwaliteit word gebruik om te verseker dat die beste praktyke nagekom word. Beste praktyke en ouditering is die enigste maniere om logiese kwesbaarhede op te spoor, soos (byvoorbeeld) om nie-gekodeerde en sigbare parameters binne ‘n URL deur te gee, wat ‘n aanvaller maklik kan verander om te doen wat hy of sy wil.

Skakel onnodige funksies uit

As ons aanvaar dat die webtoepassings so foutloos moontlik is en dat die webplaas beveilig is, kom ons kyk wat op die bediener self gedoen kan word om dit teen aanvalle te beskerm.

‘N Basiese wenk vir gesonde verstand is om die aantal moontlik kwesbare toegangspunte te verminder. As aanvallers enige van die komponente van die webbediener kan benut, kan die hele webbediener in gevaar wees.

Maak ‘n lys van al die oop hawens en die bestuur van dienste of dememons op u bediener en die onnodige dienste toemaak, deaktiveer of uitskakel. Die bediener moenie vir enige ander doel gebruik word as om u webtoepassings te bestuur nie, dus oorweeg dit om alle bykomende funksies na ander bedieners in u netwerk te verskuif.

Gebruik aparte omgewings vir ontwikkeling, toetsing en produksie

Ontwikkelaars en toetsers het voorregte nodig vir die omgewings waaraan hulle werk, wat hulle nie op die regstreekse toepassingsbediener behoort te hê nie. Selfs as u hulle blindelings vertrou, kan hul wagwoorde maklik lek en in ongewenste hande val.

Behalwe vir wagwoorde en voorregte, is daar meestal agterdeure, loglêers, bronkode of ander ontfoutinginligting in die ontwikkelings- en toetsomgewings wat sensitiewe inligting kan blootstel, soos gebruikersname en wagwoorde van databasis. Die implementering van die webtoepassing moet gedoen word deur ‘n administrateur wat moet sorg dat geen sensitiewe inligting blootgestel word na die installering van die toepassing op die regstreekse bediener nie..

Dieselfde segregasiekonsep moet op die data van die toepassing toegepas word. Toetsers en ontwikkelaars verkies altyd regte data om mee te werk, maar dit is nie ‘n goeie idee om toegang tot die produksiedatabasis of selfs ‘n kopie daarvan te gee nie. Behalwe vir die ooglopende probleme rakende privaatheid, kan die databasis konfigurasieparameters bevat wat interne bedienerinstellings openbaar – soos eindpuntadresse of padname om ‘n paartjie te noem.

Hou u bedienersagteware opgedateer

So ooglopend soos dit mag lyk, is dit een van die take wat die meeste oorgesien word. SUCURI het bevind dat 59% van die CMS-aansoeke verouderd is, wat moontlik is vir risiko’s.

Daar verskyn elke dag nuwe bedreigings, en die enigste manier om te voorkom dat dit u bediener in die gedrang bring, is om altyd die nuutste beveiligingsprogramme te installeer.

Ons het voorheen genoem dat netwerkvuurmure en netwerksekerheidskandeerders nie voldoende is om aanvalle op webtoepassings te voorkom nie. Dit is egter nodig om u bediener te beskerm teen algemene bedreigings vir kuberveiligheid, soos DDoS-aanvalle. Sorg dus dat u sulke toepassings altyd bygewerk het, en dat dit u besigheidstoepassing effektief beskerm.

Beperk toegang en voorregte

‘N Basiese veiligheidsmaatreël is om verkeer met afstandtoegang – soos RDP en SSH – geïnkripteer en tonnemaat te hou. Dit is ook ‘n goeie idee om ‘n gereduseerde lys van IP-adresse te hou waar afstandtoegang toegelaat word, en sorg dat enige poging om afstand vanaf enige ander IP af aan te meld geblokkeer is.

Administrateurs gee af en toe diensrekeninge alle moontlike voorregte omdat hulle weet dat, deur dit te doen, “alles sal werk.” Maar dit is nie ‘n goeie praktyk nie, want aanvallers kan kwesbaarhede in die dienste gebruik om die bediener binne te dring. As hierdie dienste met administrateurvoorregte is, kan hulle die hele bediener gebruik.

‘N Goeie balans tussen sekuriteit en praktiese funksie vereis dat elke rekening – beide aanmeldrekeninge en diensrekeninge – die voorregte het om sy werk te verrig, en niks anders nie.

U kan byvoorbeeld verskillende rekeninge vir ‘n administrateur definieer om verskillende take te verrig: een om rugsteun te maak, ander om loglêers skoon te maak, ander om die konfigurasie van dienste te verander, ensovoorts. Dieselfde geld vir databasisrekeninge: ‘n toepassing het gewoonlik net die regte nodig om data te lees en te skryf, en nie tabelle te skep of te laat val nie. Daarom moet dit loop met ‘n rekening met voorregte wat beperk is om die take te verrig wat hy moet uitvoer.

Hou bedienerlogboeke dop

Loglêers is daar vir ‘n rede.

Administrateurs moet dit gereeld monitor om enige verdagte gedrag op te spoor voordat dit skade berokken. Deur loglêers te ontleed, kan u baie inligting ontbloot om u te help om die toepassing beter te beskerm. As ‘n aanval sou plaasvind, kan loglêers vir u wys wanneer en hoe dit begin het, wat help om beter skade te beheer.

U moet ook ‘n outomatiese prosedure hê om ou loglêers te verwyder of om verouderde inligting te snoei, om te verhoed dat hulle alle beskikbare stoorplek op die bediener verbruik.

Bonuswenk: hou u op hoogte

Daar is baie gratis en nuttige inligting op die internet wat u kan gebruik ten bate van u webtoepassing. Moenie enige nuwe pos op betroubare blogs (soos hierdie) mis nie en bly op hoogte van wat in die veiligheids- en webbedryf aangaan.

tutoriale, kursusse, video’s en boeke is ook bronne van nuttige kennis. Oefen om een ​​of twee uur per week te spandeer net om op hoogte te bly van nuus oor die bedryf – dit sal u die gemoedsrus gee om te weet dat u die regte ding doen om u aansoeke veilig te hou.

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