8 основни съвета за осигуряване на сървър на уеб приложения

В повечето случаи сървърите за уеб приложения трябва да бъдат обществено достъпни, което означава, че са изложени на всякакви заплахи.


Много от тези заплахи са предвидими и лесно избягващи, докато други са неизвестни и могат да ви хванат извън опасност. За да сведем до минимум възможността за този последен случай, ние предлагаме списък от основни съвети, за да поддържаме сървърите на уеб приложения максимално сигурни.

Преди да започнете със списъка с бакшиши, трябва да разберете, че сървърът на уеб приложения не е остров. Сървърът е централният компонент във фермата за уеб приложения, който прави възможно хостинга и работата на уеб приложение. Следователно, за да се защитите, трябва да вземете предвид всички компоненти, които го заобикалят и да осигурите цялата среда на уеб приложението.

Основна среда за хостинг и стартиране на уеб приложения включва операционната система (Linux, Windows), софтуера за уеб сървър (Apache, Nginx), сървър на база данни. Ако някой от тези компоненти бъде разбит, нападателите могат да получат достъп и да извършат всички злонамерени действия, които искат.

Първият и основен съвет за осигуряване на среда като описаната по-горе е да прочетете указанията за сигурност и списъка с най-добри практики за всеки един от компонентите. Като се има предвид, нека разгледаме редица насоки за сигурност на здравия разум, които се прилагат за почти всяка среда на уеб приложения.

Защитната стена демистифицирана

Може да се изкушите бързо да проверите този елемент, като си помислите: „късметлийка ми, вече имам защитна стена, защитаваща мрежата ми.“ Но по-добре държи конете си.

Вашата защитна стена може да се грижи за границите на мрежата ви, да пази лошите и добрите момчета, но със сигурност оставя широко отворена врата за нападателите да пробият сървъра на уеб приложението ви.

как?

Просто: мрежовата ви защитна стена трябва поне да позволява входящия трафик на портове 80 и 443 (това е HTTP и HTTPS) и не знае кой или какво минава през тези портове.

Това, което трябва да защитите приложението си, е защитната стена на уеб приложението (WAF), която конкретно анализира уеб трафика и блокира всеки опит за използване на уязвимости като скриптове на различни места или инжектиране на код. WAF работи като типичен антивирусен и антивирусен софтуер: търси известни модели в потока от данни и го блокира, когато открие злонамерена заявка.

За да бъде ефективна, WAF трябва да има своята база данни постоянно да се актуализира с нови модели на заплахи, за да може да ги блокира. Проблемът с базираната на модели предотвратяване на атаки е, че вашето уеб приложение може да бъде една от първите цели на нова заплаха, за която вашият WAF все още не е запознат.

Поради тези причини вашето уеб приложение се нуждае от допълнителни защитни слоеве, освен мрежовата защитна стена.

Сканиране за специфични за уеб уязвимости

Отново не мислете, че вашият сървър на уеб приложения не е уязвим, само защото вашият скенер за мрежова сигурност казва така.

Мрежовите скенери не могат да открият специфични за приложенията уязвимости. За да откриете и премахнете тези уязвимости, трябва да поставите приложенията под серия от тестове и одити, като тестове за проникване, сканиране на черни кутии и одит на изходния код. Нито един от тези методи обаче не е бронежилетен. В идеалния случай трябва да извършите възможно най-много от тях, за да премахнете всички уязвимости.

Например скенери за сигурност, като Netsparker, гарантира, че никакъв използваем код не попада в производствената среда. Но може да има логически уязвимости, които могат да бъдат открити само чрез ръчен одит на код. Ръчният одит, освен че струва много, е човешки и следователно метод, предразположен към грешки. Добра идея да направите този вид одит, без да губите много пари, е вграждането му в процеса на разработка, най-вече чрез обучение на вашите разработчици.

Обучете своите разработчици

Разработчиците са склонни да мислят, че техните приложения работят в идеални светове, където ресурсите са неограничени, потребителите не правят грешки и няма хора с безмилостни намерения. За съжаление в един момент те трябва да се сблъскат с проблеми от реалния свят, особено тези, свързани с информационната сигурност.

Когато разработват уеб приложения, кодерите трябва да знаят и прилагат механизми за защита, за да се гарантира, че не е уязвима. Тези механизми за сигурност трябва да бъдат част от ръководството за най-добри практики, на което екипът за разработка трябва да се съобрази.

Одитирането на качеството на софтуера се използва, за да се гарантира спазването на най-добрите практики. Най-добрите практики и одитът са единствените начини за откриване на логически уязвимости, като (например) преминаване на незашифровани и видими параметри вътре в URL адреса, който нападателят може лесно да промени, за да направи това, което той или тя иска.

Изключете ненужната функционалност

Ако приемем, че уеб приложенията са възможно най-безгрешни и уеб фермата е защитена, нека да видим какво може да се направи на самия сървър, за да го защити от атаки.

Основен, здрав разум, е да се намали броят на потенциално уязвимите точки за влизане. Ако нападателите могат да експлоатират някой от компонентите на уеб сървъра, целият уеб сървър може да бъде застрашен.

Направете списък на всички отворени портове и стартирайте услуги или демони на вашия сървър и затворете, деактивирайте или изключете ненужните. Сървърът не трябва да се използва за каквато и да е друга цел освен за стартиране на вашите уеб приложения, така че помислете за преместване на всички допълнителни функции към други сървъри във вашата мрежа.

Използвайте отделни среди за разработка, тестване и производство

Разработчиците и тестерите се нуждаят от привилегии за средите, в които работят, които не трябва да имат на сървъра за приложения на живо. Дори ако сляпо им се доверите, паролите им лесно могат да изтекат и да попаднат в нежелани ръце.

Освен пароли и привилегии, в средите за разработка и тестване обикновено има заден план, лог файлове, изходен код или друга информация за отстраняване на грешки, които биха могли да изложат чувствителни данни, като потребителски имена и пароли на базата данни. Процесът на внедряване на уеб приложението трябва да се извършва от администратор, който трябва да се увери, че не е изложена чувствителна информация след инсталиране на приложението на живия сървър.

Същата концепция за сегрегация трябва да се приложи към данните на приложението. Тестерите и разработчиците винаги предпочитат реални данни за работа, но не е добра идея да им предоставите достъп до производствената база данни или дори до копие от нея. Освен очевидни проблеми, свързани с поверителността, базата данни може да съдържа конфигурационни параметри, които разкриват вътрешни настройки на сървъра – като адреси на крайни точки или имена на пътища, за да се назове двойка.

Поддържайте актуализиран софтуера на вашия сървър

Колкото и очевидно да изглежда, това е една от най-пренебрегваните задачи. SUCURI установи, че 59% от приложенията за CMS са остарели, което е открито за риск.

Всеки ден се появяват нови заплахи и единственият начин да им попречите да застрашават сървъра ви е винаги да инсталирате най-новите лепенки за сигурност..

Преди споменахме, че мрежовите защитни стени и скенерите за мрежова сигурност не са достатъчни, за да предотвратят атаки върху уеб приложения. Но те са необходими, за да защитят вашия сървър от общи заплахи за киберсигурност, като DDoS атаки. Затова се уверете, че имате такива приложения винаги актуализирани и че те ефективно защитават вашето бизнес приложение.

Ограничете достъпа и привилегиите

Основна мярка за сигурност е запазването на трафика на отдалечен достъп – като RDP и SSH – да бъде криптиран и тунелиран. Също така е добра идея да запазите намален списък от IP адреси, откъдето е разрешен отдалечен достъп, като се уверите, че всеки опит за отдалечено влизане от всеки друг IP е блокиран.

Понякога администраторите предоставят на сервизните акаунти всички възможни привилегии, защото знаят, че по този начин „всичко ще работи“. Но това не е добра практика, тъй като нападателите могат да използват уязвимости в услугите, за да проникнат в сървъра. Ако тези услуги работят с права на администратор, те могат да изземят целия сървър.

Добрият баланс между сигурността и практичността изисква всеки акаунт – както акаунти за вход, така и акаунти за услуги – да има привилегиите, необходими за изпълнение на работата си и нищо друго.

Например, можете да дефинирате различни акаунти за даден администратор да извърши различна задача: един да прави архивиране, други за почистване на лог файлове, други за промяна на конфигурацията на услугите и т.н. Същото се отнася и за акаунти в базата данни: приложението обикновено се нуждае само от разрешения за четене и записване на данни, а не за създаване или пускане на таблици. Следователно той трябва да работи с акаунт с привилегии, ограничени да изпълнява задачите, които му е необходимо да изпълнява.

Следете регистрационните файлове на сървъра

Лог файловете са налице защо.

Администраторите трябва да ги наблюдават редовно, за да открият всяко подозрително поведение, преди да нанесе някаква вреда. Анализирайки лог файлове, можете да разкриете много информация, която да ви помогне да защитите по-добре приложението. Ако се случи атака, лог файловете могат да ви покажат кога и как е започнала, помагайки за по-добър контрол на щетите.

Трябва също така да имате автоматизирана процедура за изтриване на стари файлове на журнали или за подрязване на остаряла информация, за да не им бъде потребено цялото налично пространство за съхранение в сървъра.

Съвет за бонус: информирайте се

В интернет има много безплатна и полезна информация, която можете да използвате в полза на уеб приложението си. Не пропускайте никаква нова публикация в реномирани блогове за сигурност (като тази) и бъдете информирани за случващото се в сигурността и уеб индустрията.

уроци, курсове, видеоклипове и книги също са източници на полезни знания. Практикувайте да отделяте един или два часа седмично, само за да сте информирани за новините в бранша – ще ви даде спокойствието да знаете, че правите правилно, за да запазите приложенията си защитени.

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