Архитектура современных веб сервисов и способы их защиты

Архитектура современных веб-сервисов и способы их защиты

Сегодня большинство сервисов разрабатывается для публикации в интернете. Многие компании используют их как единственный способ дистрибуции продуктов и общения с клиентами. Из чего же состоят современные веб-сервисы и какие подводные камни встречаются в их реализации?

Введение

Современные веб-приложения строятся на основе микросервисной архитектуры — стиля, который структурирует приложение как набор сервисов. Каждый такой сервис максимально автономен, необходим для выполнения конкретной задачи и поддерживается конкретной командой. Эта архитектура позволяет применять модульный принцип построения приложений с учётом потребностей бизнеса. Другими словами, вы всегда можете поменять один или несколько сервисов, таких как веб-сервер или сервер обработки запросов, в случае изменения потребностей без ущерба для бизнеса.

Рисунок 1. Современная архитектура веб-приложения (источник: videoblocks.com)

Другой разновидностью подхода к построению приложений является монолитная архитектура, дающая преимущество в виде минимальных проблем согласованности компонентов, но не обладающая такой гибкостью в построении, как микросервисная. Монолитная архитектура вполне имеет право на существование, но её достоинство является и её недостатком, и в современном мире она практически не встречается в веб-приложениях, т. к. не удовлетворяет требованиям Time To Market — требованиям бизнеса по выпуску новых продуктов на рынок.

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

Рисунок 2. Отличия монолитной и микросервисной архитектур (источник: xm-online.com)

Вызовы времени

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

Продвижение достижений в сфере защиты происходит на профильных конференциях и путём написания стандартов и общих практик, которых должны придерживаться все участники. Из данных достижений возникают технологии, которые сами по себе весьма сложны и неполноценны, но энтузиасты отрасли «толкают» их на поверхность и стараются адаптировать их к реалиям бизнеса. Именно данный срез по отрасли и демонстрирует компания Gartner в своём ежегодном отчёте Hype Cycle.

Gartner уже много лет подряд выпускает ежегодный «чарт» трендов для средств защиты приложений. В нём компания отражает своё видение роста популярности тех или иных средств защиты приложений в целом и веб-приложений в частности. Стоит сказать, что данный рейтинг имеет много общего с текущей ситуацией на рынке средств защиты и его можно расценивать как некий перечень потребностей бизнеса в таких средствах.

Рисунок 3. Тренды для средств защиты приложений за 2019 год

Упомянутый перечень представлен в виде графика функции не просто так. Дело в том, что у каждой технологии есть периоды становления и не все технологии приживаются в отрасли. Данный график — это наглядное представление того, в чём у бизнеса, скорее всего, будет потребность через пять или десять лет, если эта технология, конечно же, останется на рынке. Отчёт составлен в 2019 году, и мы можем считать, что предсказания сбываются: технологии, которые востребованны уже сейчас, — это межсетевые экраны уровня веб-приложений (Web Application Firewalls) и средства управления жизненным циклом API (Full Life Cycle API Management).

Также у бизнеса возникает всё большая потребность в профессиональных услугах по обеспечению безопасности приложений (Application Security Professional Services, далее — AS). Источники этих профессиональных услуг можно разделить на четыре основные категории:

• крупные поставщики телекоммуникационных услуг с практиками AS,
• сторонние фирмы по разработке приложений с применением практик AS,
• поставщики инструментов AS с крупными профессиональными сервисными службами,
• специализированные консалтинговые фирмы, специализирующиеся на услугах AS.

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

История развития веб-приложений

Для лучшего понимания того, откуда взялись проблемы безопасности современных веб-приложений, стоит заглянуть на 30 лет назад. Современный веб, как и тогда, строится на основе протокола HTTP и ряда языков разметки / программирования, таких как HTML, JavaScript и PHP. Так же в этой схеме присутствуют веб-браузер и веб-сервер.

Рисунок 4. Схема современного веба

В первой версии протокола HTTP (HTTP/0.9), разработанной в 1991 году, был всего один метод взаимодействия клиента и сервера — метод GET с последующим путём к ресурсу, например GET /mypage.html. В ответ приходил документ в формате <HTML>Ответ</HTML>. Не было заголовков, и поэтому передавать можно было только HTML-файлы. Не было и кодов ошибок с описанием ситуации, которые мы все привыкли видеть в том случае, если ресурс недоступен или страница не найдена. Но это продолжалось недолго, и в версию протокола HTTP/1.0 добавили и заголовки, и поля ошибок. Благодаря заголовку «content-type» появилась возможность передавать при помощи протокола HTTP не только HTML-файлы, но и другие типы объектов, такие как картинки и архивы.

Но по-настоящему всё это начало применяться с 1999 года, когда международной сетевой рабочей группой (International Network Working Group) была принята версия протокола HTTP/1.1, которая дорабатывается до сих пор. Стандарт устранял неясности и вносил значительные улучшения, которыми мы пользуемся и сейчас. Среди них — переиспользование соединений для сокращения времени на обработку новых запросов, конвейерная обработка, позволяющая отправлять второй запрос до того, как первый будет принят, дробление («чанкование») запросов. Разработаны дополнительные механизмы контроля кеша и согласования контента, добавлен заголовок «host», позволяющий размещать разные домены на одном IP-адресе.

Одновременно с разработкой протокола HTTP, в 1994 году компания Netscape Communications создавала криптографический протокол SSL (Secure Sockets Layer), который позволил появиться рынку электронной коммерции. SSL решили стандартизировать, и итоговым названием протокола стало TLS 1.0 (Transport Layer Security). Актуальная версия TLS 1.3 уже используется не только участниками электронной торговли, но и всеми, кто хотел бы защитить передаваемую информацию.

Вскоре, в 1996 году, протокол HTTP был расширен за счёт дополнений, поддерживающих совместную работу пользователей над редактированием файлов и управлением ими на удалённых серверах. Этому дополнению дали название WebDAV (Web Distributed Authoring and Versioning). Если сказать проще, то HTTP использовался для чтения, а WebDAV — для записи данных.

Как продолжение развития протокола HTTP в 2000 году был разработан архитектурный стиль взаимодействия компонентов распределённого приложения в сети (REST), который отлично укладывался в концепцию микросервисной архитектуры. Он предполагал взаимодействие компонентов приложения посредством заранее созданных и должным образом описанных интерфейсов с возможностью выполнения процедур обработки или выдачи информации при помощи вызовов. Сейчас подобные интерфейсы чаще всего называются API (Application Programming Interface), но ещё до этого момента были как минимум протоколы DRC и SOAP.

Подход к построению веб-приложений с использованием API позволил обмениваться информацией и командами между компонентами веб-приложения без обновления серверов или браузеров: достаточно изменить спецификацию программного интерфейса, что делается намного проще. С 2005 года популярность REST API только росла и его начали использовать на веб-сайтах для пуш-уведомлений или в рамках протокола WebSocket. Развитие API и технологий, являющихся производными от данного типа интерфейсов, мы рассмотрим в следующих статьях.

Как обеспечить безопасность веб-приложений

Все мы знаем, что интернет — в опасности. Это — общая или, как говорят, комплексная проблема, и решают её все специалисты нашей отрасли. Сейчас уже сформировано множество альянсов за безопасный интернет со стороны как технологических компаний, так и отдельных специалистов. Почти все результаты работы данных команд или проектов становятся общедоступными — вспомнить хотя бы Mozilla MDN или открытый проект OWASP с их подходом Top 10. Всех их объединяют общие принципы и подходы к обеспечению безопасности веб-технологий.

Рисунок 5. Наиболее распространённые уязвимости из списка OWASP Top 10 (источник: ptsecurity.com)

Я не открою ни для кого тайну, если скажу, что суть всех средств обеспечения безопасности веб-приложений — в том, чтобы защититься от человеческого фактора в различных его проявлениях. Эту мысль подтверждает большой перечень аналитических отчётов из года в год. Существует множество способов сделать сервис неправильно, начиная с выстраивания процесса разработки веб-приложения и заканчивая его публикацией и сопровождением. Даже вывести из эксплуатации сервис нужно как следует. Если перейти от абстракции к конкретным способам защиты, то первое, на что нужно обратить внимание, — это решения класса Web Application Firewall (WAF).

Первые WAF появились более 20 лет назад, когда компания Perfecto Technologies представила продукт AppShield — обособленную систему защиты серверов приложений сегмента e-business, позволявшую осуществлять контроль эксплуатации уязвимостей (сколько их тогда было?), изъянов в коде приложения и ошибок безопасности сторонних модулей. Сама защита веб-приложения происходила путём анализа каждого HTTP-запроса и каждой HTML-страницы.

Таким образом, ещё на заре электронной коммерции уже стояла проблема защиты интернет-магазинов, онлайн-банков и других сервисов, для которых особо актуальна угроза раскрытия информации. Веб-серверам, опубликованным в общедоступной сети, приходится сталкиваться с атаками раньше других компонентов веб-приложения, поэтому защита данных серверов от угроз — это первый и очень важный рубеж защиты всего приложения.

Как говорилось ранее, современный сервис — это набор микросервисов и взаимодействие между ними. Вторая цель злоумышленников, после того как они пробили рубеж веб-сервера, — это данные, находящиеся во внутренней базе веб-приложения. Это могут быть базы клиентов, информация по транзакциям, служебные или иные сведения, раскрывать которые никто не собирался. Вы скажете: для чего же хранить данную информацию в таком незащищённом месте?

Всё дело — в том, что часто она может быть разбросана между множеством баз данных, необходимых для выполнения бизнес-логики веб-приложения, и извлекаются эти данные путём SQL-запросов. Суть SQL-запроса заключается в том, что в базу отправляется строка, содержащая команду на выгрузку или загрузку каких-либо данных. Если не ведётся контроль команд, отправляемых SQL-серверу, то может произойти утечка, т. к. сами по себе запросы — это вполне легитимные обращения, а вот команда, содержащаяся в одном из них, может спровоцировать выгрузку и отправку злоумышленнику всей базы клиентов веб-сервиса. Если кратко — мониторинг SQL-запросов должен производиться на регулярной основе, и чем ближе этот мониторинг будет происходить к самой базе данных, тем лучше будет результат.

Выводы

После чтения этих строк может сложиться впечатление, что спасения нет, но на самом деле проблема кроется в процессе защиты. Грамотно выстроенный жизненный цикл разработки и публикации веб-приложений — это основа защищённости сервиса, т. к. стоимость исправления ошибки в публикуемом веб-сервисе снижается при смещении фокуса обеспечения безопасности в самое начало — путём выстраивания процесса безопасной разработки и применения специальных средств анализа уязвимостей, таких как решения класса Application Security Testing. Их — множество, и они призваны повысить качество кода с точки зрения исключения небезопасных вызовов и выполнения проверок входящих запросов.

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

Источник

Защита web сервера от программ для ddos атак

Некоторое время назад я написал подробную статью про установку и настройку web сервера на базе nginx и php-fpm последних версий. Там я упомянул, что это первая статья из цикла заметок о веб сервере. Сегодня я расскажу как простыми и подручными средствами защититься от простых ddos атак.

Введение

Сразу сделаю оговорку по поводу слова ddos, которое тут не совсем уместно, но я не придумал, как еще популярно объяснить о чем идет речь. От полноценной ddos атаки вы не сможете защититься в рамках настройки веб сервера. У вас просто будет забит весь канал и сервер перестанет отвечать. Если мощности сервера не достаточно для обработки и фильтрации входящих запросов, то он ляжет, чтобы вы там не делали. Для полноценной защиты от ddos нужны полноценные средства, которые стоят ощутимых финансовых затрат. Более подробно с теорией по защите от ddos читайте в отдельной статье.

Нужно понимать, что защита от ddos должна быть адекватна значимости ресурса. Если у вас персональный блог, который не приносит существенной прибыли, то платить за защиту от ddos бессмысленно. Достаточно просто полежать какое-то время или сделать защиту своими силами. В общем, всегда нужно соизмерять стоимость простоя со стоимостью защиты и на основе этого принимать решение о целесообразности того или иного метода.

Я приведу советы по защите от простых атак ботов или каких-то мелких вредителей и пакостников, которые без должных действий с вашей стороны могут положить ваш сайт или сервер без особых проблем. Вот простой пример. Есть не очень слабый виртуальный сервер от ihor, на борту которого 2 ярда, 8 гигов оперативы и ssd диск.

Сервер настроен по моей предыдущей статье, ссылку на которую привел в начале. На сервере развернут wordpress сайт с некоторым содержимым. И есть у нас вредитель, который на своем сервере запускает простой тест от apache на производительность веб сервера:

Всего лишь 50 параллельных потоков. Что мы видим на своем веб сервере:

Не очень приятная картина. Сервер загружен на 100%. И хотя он нормально обрабатывает запросы и в целом корректно работает. Даже не очень тормозит, но все равно это плохо. А если будет 3 сервера и по 100 потоков на каждом? Нет никаких проблем даже на тест взять у разных хостеров по виртуальной машине и запускать на них подобные штуки, имитируя ддос атаку.

В общем, если вы совсем не сделали никакой защиты на своем сервере, то любой человек сможет вам без особых проблем доставить некоторые неудобства. Защититься от такой «атаки» не сложно. Дальше я расскажу как это сделать.

Защита от ddos с помощью iptables

Для защиты от простейшей атаки мы будем использовать firewall — iptables, модуль ядра ipset для хранения больших списков ip и самописные скрипты. По фаерволу смотрите мою статью — настройка iptables. Здесь я не буду на этом останавливаться.

Вопрос настройки ipset я подробно рассматривал в своей статье по блокировке ботов по странам. Советую посмотреть материал, так как он напрямую связан с этой статьей и дополняет ее.

Итак, приступим к созданию нашей простой защиты от dos атаки с большим количеством подключений с одного ip адреса. Для начала проверим команду, которая покажет нам количество подключений с каждого ip адреса:

У меня получается примерно так. Много единичных подключений. Идет штатная работа веб сервера, никто на него не ломится десятками подключений. Теперь нагрузим наш сервер множественными паразитными запросами и еще раз посмотрим вывод команды.

Вот он, нарушитель нашего спокойствия, пытающийся организовать дос атаку на наш сервер. Теперь нарисуем скрипт, который будет блокировать всех кто устанавливает более 50-ти одновременных соединений с сайтом.

В принципе, комментировать тут особо нечего. Берем список подключений, который только что вывели, в нем сравниваем первую колонку, если она больше 50, то результат второй колонки, где записан ip адрес, передаем в файл.

Далее читаем этот файл и добавляем все ip адреса из него в ipset список под названием much_conn. Предварительно его надо создать. Подробно об этом я рассказывал в статье, на которую привел ссылку выше, но повторю еще раз здесь:

Посмотреть содержимое списка можно командой:

Теперь нужно добавить в iptables правило, по которому будут блокироваться все подключения из указанного списка ipset.

На всякий случай предупреждаю, чтобы вы проверили свой доступ к консоли сервера, прежде чем настраивать правила iptables. Всякое бывает, можно просто ошибиться, скопировать и вставить не то, что нужно.

Все, мы заблокировали всех, кто создает массовый спам подключений к серверу. Ограничение в 50 подключений можете исправлять по месту, возможно его нужно будет уменьшить, если кто-то будет открывать меньше подключений с одного ip.

Единственный момент, о котором хочу сказать. Сам я не проверял, сколько подключений открывают поисковые боты, когда приходят на сайт. Я подозреваю, что явно не 50 и даже не 30, но наверняка я не проверял. В общем, будьте аккуратны, когда используете это средство.

Данный скрипт можно засунуть в крон и запускать каждую минуту. Но лично я бы так не стал делать. Я рекомендую мониторить ресурсы сервера и запускать подобные средства, только если сервер работает на пределе своих возможностей и вы вручную зашли и убедились, что вас кто-то спамит подключениями. После этого врубайте на какое-то время данный скрипт по крону. Когда ddos прекратится, отключайте.

Было бы неплохо как-то автоматически очищать список забаненных, удаляя оттуда тех, кто уже сутки к вам не подключается, но это сильно усложняет задачу. Нужно как минимум вести лог по блокирующему списку, сохранять время последнего обращения. Обрабатывать все это, высчитывать. В общем, задача хоть и не сильно сложная, но уже не тривиальная. Мне не захотелось этим заниматься.

Есть хоть и не очень изящное, но простое решение этой проблемы. Создать список ipset с заданным временем жизни записи с помощью timeout. Например вот так:

В данном случае запись с забаненным ip в списке ipset будет храниться в течении 3600 секунд или 60 минут.

Нужно понимать, что в данном примере с 1 ip адресом использовать ipset нет никакого смысла, можно сразу банить средствами самого iptables. Ipset нужен только тогда, когда этот список хотя бы в сотни строк. Если там несколько десяткой адресов, хватит и одного iptables.

Анализ лог файла web сервера для защиты от ddos

Рассмотрим еще один простой, но все же более сложный тип ддос атаки, когда идут типовые запросы с разных IP. То есть простой ботнет, может быть даже собранный руками из нескольких дешевых vds серверов. Одновременных подключений будет не много, но если у вас тяжелый сайт и злоумышленник найдет его слабое место (например поиск), то этого может быть достаточно, чтобы положить сайт.

Банить будем тоже через iptables, а список адресов для бана будем извлекать из логов веб сервера. Для этого у вас должно быть включено логирование запросов к веб серверу. Например, в nginx за это отвечает такая настройка виртуального хоста:

Мы не будем каждый раз анализировать весь лог файл. Эта операция сама по себе будет сильно нагружать веб сервер. Возьмем последние 1000 строк из лог файла и посчитаем количество подключений с одного ip с типовым содержимым, например запрос главной страницы по протоколу http 1.0, «GET / HTTP/1.0». Если вы заметите другой постоянный признак ботнета, который вас атакует, используйте его. Это может быть один и тот же user agent или что-то еще. Допустим, если атакующий будет долбить в уязвимое место, то это будет адрес этой страницы.

Результатом этой команды будет примерно такой список.

В данном случае я использовал немного другое условие и просто вывел список всех тех, кто стучался на главную страницу. Но уже тут видно нарушителя, которого можно забанить.

Рисуем похожий на предыдущий скрипт для автоматической блокировки тех, кто отправляет слишком много запросов на наш сайт и создает проблемы с производительностью. Повторюсь еще раз, если проблем с производительностью нет, я не рекомендую делать лишних движений.

Здесь делаем то же самое, что и раньше. Те, кто сделали более 50-ти одинаковых запросов по нашей маске на последние 1000 строк в лог файле, отправляются в бан.

Обращаю внимание на строку, по которой вы будете фильтровать запросы. В данном случае я показал только пример. Не надо брать и применять в том виде, как я показываю. Я демонстрирую технические возможности и подход. Настраивать и калибровать систему вам нужно у себя по месту. Важно это понимать и не применять решение бездумно. Будет только вред.

Не забудьте создать отдельный список в ipset и добавить отдельное правило в ipables. Можно использовать уже существующий список и добавленное правило из предыдущего примера, но я рекомендую все разделять. Так удобнее для последующего анализа.

Во время ddos атаки добавляете это правило в cron и выполняете каждую минуту. После завершения атаки скрипт можно отключить. В принципе, можно и на постоянку оставлять, но тут нужно хорошенько подумать и прикинуть, как оно должно выглядеть. Главный принцип — не навредить.

Баним ботов с неправильным referer

Есть категория простых ботов, которые подставляют в referrer либо мусор, либо кривые урлы без http или https в начале. Например вот такие:

Корректное поле referer должно содержать либо http, либо https, либо быть пустым. Все, что иначе, можно смело блокировать или возвращать статус ошибки. Добавляем примерно такую конструкцию в конфигурацию виртуального хоста, в раздел server <>.

После этого проверьте конфигурацию nginx и перечитайте ее.

Если вас достает какой-то бот с конкретным referer, можно забанить именно его. Для этого можно дополнить условие, или изменить. Например, вот так:

В дополнение, можно всех этих ботов с помощью простого скрипта банить на iptables, как в примерах выше. К слову сказать, их можно банить сразу, разбирая http запросы еще до того, как они будут попадать к nginx, например, с помощью ngrep, но это более сложная задача. Не все это умеют делать, там есть нюансы, а с nginx знакомы все. Не составит большого труда реализовать данный метод.

Защита от ддос с помощью модулей nginx — limit_conn и limit_req

Поделюсь еще одним простым способом снизить нагрузку на сервер и частично защититься от ддос с помощью модулей nginx — limit_conn и limit_req. Настроить их не сложно, частично результат работы первого модуля будет пересекаться с первыми двумя способами ddos защиты, описанными в начале. Он более простой для настройки, так что если не справились с теми способами, можно попробовать этот.

Смысл данных модулей в том, что один может ограничить одновременное количество разрешенных соединений с сайтом, а другой количество соединений в единицу времени.

Я ограничу в своем примере количество одновременных подключений к сайту с одного ip числом 50, а количество одновременных запросов к динамическому контенту не более 2-х в секунду. При этом будет разрешен всплеск (burst) запросов до 5-ти. Объясню, как понимать этот всплеск, так как сам не сразу понял, что конкретно он означает.

Если у нас идет превышение количества установленных запросов в секунду, то их выполнение задерживается, и они выстраиваются в очередь на исполнение с указанной скоростью. Размер этой очереди и равен значению всплеска. Все запросы, которым не хватит места в очереди, будут завершены с ошибкой. То есть, если запросов будет 4 в секунду, то 2 выполнятся сразу и еще 2 встанут в очередь. А если будет 10, то 2 выполнятся сразу, 5 встанут в очередь на выполнение по 2 штуки в секунду, а остальные будут завершены с ошибкой.

Исходя из этих условий, ограничение на подключения нужно установить в контексте server, а на доступ к динамическому контенту в соответствующем location. При этом описание зон, которые будут использовать директивы, нужно расположить в http.

Вот пример конфига nginx для реализации установленных ограничений с целью защиты от ддос атак.

После этого перезапустите nginx и проверьте как работают лимиты. Ограничение на количество выполняемых динамических запросов можно увидеть, просто нажимая очень быстро F5 в браузере. Если будете достаточно ловки, то скоро увидите картинку

и запись в логе с ошибками:

Лимит на количество подключений можете проверить той же утилитой ab, о которой я рассказал во введении.

Только не забывайте, что тест нужно запускать не на конкретную страницу, тогда вы попадете на ограничение выполнения динамического контента, а на что-то другое. Например, как в моем примере, на картинку.

При выставлении ограничений, не забудьте проконтролировать, не попадают ли в эти ограничения поисковые боты. По-умолчанию, они стараются не создавать повышенную нагрузку на сайт. При желании, роботу яндекса можно указать через robots.txt, с какой скоростью сканировать ваш сайт. А роботу гугла то же самое можно сделать через webmaster.

Заключение

Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!

Я рассмотрел наиболее простые способы для защиты web сервера от не менее простых ddos атак, которые больше похожи на баловство. Серьезная атака, которая просто зальет весь входящий канал сервера, даже не заметит наших защит. Но тем не менее, мне приходилось убеждаться в эффективности этих способов в отражении некоторых атак.

Существует до сих пор огромное количество веб серверов, которые вообще никак не защищены даже от утилиты ab 🙂 Я знаю о чем говорю, так как мне попадаются в работу такие серверы. И есть так же много всяких ботов и простых программ, которые можно найти на просторах интернета и побаловаться, заваливая сайты, которые не готовы к нагрузкам вообще.

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

Суть защиты в том, что с помощью nginx выдаем пользователю определенную cookies, а потом редиректим на запрашиваемую страницу. Если бот не понимает кукисов или редиректов, то он отваливается. Нормальные пользователи ничего не замечают. Возможно позже я отдельно расскажу про этот способ и дополню статью. А пока все. Буду рад замечаниям по существу в статьях.

Помогла статья? Подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Источник



Рекомендации по защите: Web-серверы. Windows

3. Изолирование ролей сервисов.
В идеале, один сервер — одна функция. То есть сервер должен выполнять какую-то конкретную функцию: контроллер домена, файловый сервер или другие. Конечно, на практике такого сложно добиться, но можно выполнить эту рекомендацию, например, с помощью виртуальных машин, развернутых для выполнения отдельных ролей.

4. Отключение SSL2.0 и SSL3.0.
Данные версии протокола считаются криптографически небезопасными. Используйте протокол TLS не ниже версии 1.2.

5. Использование HTTP версии не ниже 1.1.
Все новые версии популярных web-серверов и браузеров уже поддерживают HTTP/2. Новая спецификация быстрее и производительнее существующего HTTP 1.1 и давно устаревшего HTTP версии 1.0.

6. HttpOnly и Secure cookie.
Похищение cookie из приложения может привести к захвату авторизованного сеанса пользователя. Кражу cookie можно осуществить с помощью атаки типа XSS. Атрибут HttpOnly позволяет снизить эту угрозу, ограничивая доступ к cookie из JavaScript.

7. Настройка доступных Internet Media Types (MIME).
Это проверка содержимого файлов, которая может защитить вас от все тех же атак типа XSS. С помощью MIME можно выбрать типы файлов, которые могут храниться и быть обработанными на сервере. Все остальные файлы, в том числе и те, которые попытается загрузить злоумышленник, не будут загружены, и система выдаст ошибку.

9. Использование IP Address and Domain Restrictions.
Составьте с помощью Domain Restrictions белые списки IP-адресов для ограничения доступа к сайту. Например, для того чтобы открыть доступ к панели администратора только с определенного IP-адреса.

10. Настройка Request Filtering.
Добавьте фильтрацию по заголовку, методам, URL, расширению, чтобы оградить себя от возможных методов DoS атак. А фильтрация query-параметров поможет защититься от попытки получить доступ к конфигурационному файлу web.config или файлу с паролями.

11. Dynamic IP Address Restrictions.
Используя эту особенность, ограничьте частоту запросов, чтобы IIS на аномально огромное количество запросов с одного IP-адреса выдавал ошибку как результат. Будьте осторожны, при неправильной настройке можно заблокировать доступ со стороны серверов CDN.

12. Настройка страниц ошибок.
К каждому типу ошибок, которые могут возникнуть при работе с сайтом, необходимо создать и привязать
страницу-заглушку для того, чтобы скрыть конфиденциальную информацию. В IIS есть возможность выдачи различных страниц с ошибками для конечных пользователей и администраторов.

13. Защита от Clickjacking атак.
Для этого во вкладке «Соединения» в списке функций найдите «заголовки HTTP-ответов» и добавьте новый подпункт под названием «X-Frame-Options» со значением «SAMEORIGIN».

14. Проверка конфигурационного файла.
В модуле «Configuration» расположен элемент «Credentials», который позволяет указывать дополнительные логины и пароли для учетных записей. Рекомендуется не хранить пароли в файле конфигурации, даже в виде хеша. Аутентификационные учетные данные всегда должны храниться в защищенных местах, чтобы уменьшить риск их кражи.

15. Изоляция web-контента от системных файлов.
Создайте отдельный раздел на жестком диске для хранения файлов web-контента. Это позволит снизить нагрузку на дисковое пространство, в котором хранятся системные файлы и уменьшить риск нарушения их конфиденциальности и целостности.

17. Отключение возможности просмотра каталогов.
Просмотр каталога позволяет отображать содержимое каталога по запросу от
web-клиента. Если просмотр каталогов включен для каталога в Internet Information Services, пользователи получают страницу, в которой перечисленo содержимое каталога.

18. Отключение метода «Trace».
На действующем web-сайте трассировка должна быть отключена, поскольку она может отображать конфиденциальную информацию всем, кто просматривает страницы на сайте. При необходимости атрибуту localOnly может быть присвоено значение true, чтобы информация о трассировке отображалась только для запросов с локального хоста.

19. Выбор правильных алгоритмов шифрования и хэширования.
Элемент «machineKey» в конфигурационном файле web.config задает алгоритм и ключи, которые ASP.NET будет использовать для шифрования и хеширования служб приложений. Настройте его на использование алгоритмом шифрования AES и хеширования SHA1.

20. Проверка режима отладки (debug).
По умолчанию режим отладки отключен, но он очень удобен для разработки при исправлении неполадок. Этот режим компилирует приложения с выводом дополнительной информации, которая позволяет внимательно отслеживать и контролировать выполнение кода. Часто, уже после устранения проблем с кодом, его забывают отключать.

21. Логирование и аудит.
Настройте ведение подробных логов, хотя бы по работе критически важных сегментов вашей инфраструктуры и регулярно инспектируйте их.

Источник

Защита веб-сервера и сервера приложений

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

Веб-сервер представляет собой сервер, обслуживающий HTTP-запросы. Его главная задача заключается в отображении статического контента сайта. Дополнительно он автоматизирует работу веб-страниц, авторизует и аутентифицирует пользователей, ведет журнал пользовательских запросов, поддерживает защищенные HTTPS-соединения. Такой веб-сервер называют ещё статическим. Он может работать отдельно без сервера приложений.

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

Сервер приложений представляет собой фреймворк (программную платформу), который работает не только с HTTP и HTTPS, но и с другими протоколами. Он обеспечивает взаимодействие пользователей с динамическим и статическим контентом.

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

Виды угроз

Перед осуществлением мероприятий по информационной защите веб-сервера, необходимо провести аудит (анализ) систем работы сервера. Он помогает определить вид угрозы и методы обеспечения безопасности.

Основными видами угроз являются:

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

Способы защиты веб-сервера и сервера приложений

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

Web application firewall

Для обеспечения безопасности в работе сервера приложений используется межсетевой экран приложений (Web application firewall или сокращенно WAF). Это комплекс мониторов и фильтров, работающих на прикладном уровне. WAF надстраивается над сервером приложений для анализа в режиме реального времени входящего и исходящего трафика и принятия решений отклонить или предоставить доступ.

Создание SSH-ключей

Пара из открытого и закрытого SSH-ключей — это специальные коды, созданные при помощи криптографии. Они позволяют идентифицировать доверенного пользователя и по эффективности превосходят генерацию логинов и паролей.

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

Настроить SSH-ключи может системный администратор на любой операционной системе, включая Unix-системы с открытым исходным кодом.

Установка межсетевого экрана

Межсетевой экран еще называют сетевым экраном, файрволом или брандмауэром. Это программно-аппаратное или программное решение, которое защищает веб-сервер от несанкционированного доступа через открытые порты и трафик. Доступ регулируется настройками сетевого экрана согласно корпоративной политике безопасности.

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

VPN и Private Networking

VPN и Private Networking — это технологии создания виртуальной частной сети и частной сети с безопасным соединением между серверами и пользователями.

VPN и Private Networking настраиваются под потребности компании. О существовании частной сети знают только ее пользователи. Это позволяет минимизировать внешние угрозы.

Защита от DDoS-атак

Стандартные способы защиты веб-сервера не могут оградить его от DDoS-атак.

Для безопасности веб-сервера от DDoS-атак необходимы межсетевой экран, утилиты iptables и ipset, а также скрипты для блокировки ботов.

PKI- и SSL/TLS-шифрование

Это построение инфраструктуры открытых ключей (PKI) для создания сертификатов идентификации пользователя и передачи зашифрованной информации через криптографический протокол SSL/TLS.

Для этого создается центр сертификации и управления сертификатами для проверки прав доступа.

Построение изолированной среды

Это создание изолированной среды работы приложений и программ при помощи их отделения друг от друга и распределения на собственные серверы. Степень изоляции зависит от системных требований каждого программного продукта и уровня его значимости в работе всей ИТ-инфраструктуры.

Таким образом программное обеспечение изолируется от угроз и влияния на работу всей системы несанкционированного доступа к одному процессу.

Антивирусные программы

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

Обеспечение доступности данных

Помимо защиты веб-сервера и сервера приложений от внешних угроз, применяются меры и от угроз внутренних: ошибки сотрудников, выход из строя оборудования или ПО. Комплекс решений направлен на защиту данных и обеспечение отказоустойчивости технических средств.

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

Партнёры-разработчики решений по защите веб-сервера

Сегодня для обеспечения защиты веб-сервера и сервера приложений собственные решения разрабатывают многие ИТ-компании:

Источник

Как защитить веб-сервер: базовые советы

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

При условии, что у вас «белый» IP, к вашему веб-серверу может подключиться из интернета любой пользователь. Также, если вы, подключены к локальной сети, то опять же к вашему веб-серверу может подключиться любой компьютер из этой локальной сети.

По этой причине необходимо правильно настроить компоненты веб-сервера.

Запрет доступа извне к MariaDB/MySQL

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

6 июля в 11:00, Онлайн, Беcплатно

Как правило веб-сервер имеет две сетевые службы:

• сам веб-сервер, который прослушивает 80 порт (HTTPS — 443 порт),
• сетевая служба системы управления базами данных, MariaDB/MySQL – 3306.

Чтобы MariaDB/MySQL принимали подключения только от веб-приложений, работающих на localhost, исправьте конфигурационный файл my.cnf.

Выглядеть он должен следующим образом:

После изменения конфигурационного файла, перезапустите службу.

Теперь никто извне не сможет подключится к MariaDB/MySQL, кроме компьютера, на котором работает веб-сервер.

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

Устанавливайте пароль на MariaDB/MySQL

По дефолту у администратора установлен пустой пароль. Так как мы отключили доступ из вне к серверу, о чем писали выше, то данные дефолтные настройки не так опасны для нас. Но есть вероятность, что злоумышленник найдет уязвимость в веб-приложении и через нее сможет выполнить подключение к нашему серверу. Поэтому желательно все же изменить дефолтные настройки и задать безопасный пароль для доступа к серверу.

Зачищайте

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

Блокируйте доступ к резерву

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

Прячьте версию веб-сервера

Версия сервера может рассказать злоумышленнику очень многое: какие уязвимости доступны на данном сервере и как его можно взломать. Также злоумышленник сможет понять, на какой ОС запущен сервер, что так же поможет ему при планировании атаки.

Установите файрвол

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

Для веб-серверов c ОС Linux — Apache или nginx — рекомендуются следующие меры защиты:

Источник