В большинстве случаев серверы веб-приложений должны быть общедоступными, что означает, что они подвержены всевозможным угрозам.


Многие из этих угроз предсказуемы и их легко избежать, тогда как другие неизвестны и могут застать вас врасплох. Чтобы свести к минимуму вероятность этого последнего случая, мы предлагаем список важных советов для обеспечения максимальной безопасности серверов веб-приложений..

Прежде чем начать со списком советов, необходимо понять, что сервер веб-приложений не является островом. Сервер – это центральный компонент в ферме веб-приложений, который делает возможным размещение и работу веб-приложения. Поэтому для обеспечения безопасности необходимо учитывать все компоненты, которые его окружают, и защищать всю среду веб-приложений..

Базовая среда для размещения и запуска веб-приложений включает операционную систему (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