Vvmebel.com

Новости с мира ПК
5 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Безопасность веб сервера

Information Security Squad

stay tune stay secure

Советы и рекомендации по обеспечению безопасности вашего веб-сервера Nginx

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

Nginx работает в операционных системах Linux, Windows, Mac OS и Solaris.

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

В этом руководстве мы расскажем о некоторых популярных советах и рекомендациях по безопасности сервера Nginx.

Требования

  • Сервер под управлением Ubuntu 18.04 или Debian 9.
  • Пароль root установлен на вашем сервере.

Установить Nginx

Во-первых, вам нужно будет установить Nginx в вашу систему.

Вы можете установить его, выполнив следующую команду:

После установки Nginx вы можете проверить состояние Nginx с помощью следующей команды:

Вы должны увидеть следующий вывод:

Обновление Nginx

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

Большинство современных дистрибутивов Linux не включают последнюю версию nginx в списки пакетов по умолчанию.

Поэтому вам необходимо обновить последнюю версию nginx через менеджер пакетов.

Вы можете обновить свой веб-сервер Nginx с помощью следующей команды:

Предотвратить раскрытие информации

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

По умолчанию Nginx показывает свое имя и версию в заголовках HTTP.

Вы можете проверить это с помощью следующей команды:

Вы должны увидеть следующий вывод:

В приведенном выше выводе вы должны увидеть версию Nginx и операционной системы.

Вы можете скрыть эту информацию, отредактировав файл /etc/nginx/nginx.conf:

Добавьте server_tokens off внутри части конфигурации http:

Сохраните и закройте файл, когда вы закончите.

Затем перезапустите веб-сервер Nginx, чтобы применить изменения:

Теперь снова запустите команду curl:

Вы должны увидеть следующий вывод:

Ограничить IP-адреса

Nginx поставляется с простым модулем, который называется ngx_http_access_module, чтобы разрешить или запретить определенный IP-адрес.

Если вы хотите разрешить доступ к Nginx с 172.16.0.0/16 и запретить из других подсетей.

Затем откройте файл /etc/nginx/sites-enabled/default:

Сохраните и закройте файл, когда вы закончите.

Затем перезапустите Nginx, чтобы применить эти изменения:

Теперь попробуйте получить доступ к вашему серверу Nginx с другого диапазона IP-адресов, например 192.168.0.102.

Затем проверьте журнал Nginx с помощью следующей команды:

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

Безопасный Nginx с TLS

TLS (Transport Layer Security) является преемником SSL (Secure Socket Layer).

Он обеспечивает более сильный и эффективный протокл HTTPS и содержит больше усовершенствований, таких как прямая секретность, совместимость с современными наборами шифров OpenSSL и HSTS.

В этом руководстве показано, как включить самоподписанный SSL-сертификат в Nginx.

Если вы хотите использовать вместо этого сертификат Let’s Encrypt, посмотрите Как легко включить TLS 1.3 в Nginx на Ubuntu 18.10, 18.04, 16.04, 14.04

Сначала создайте каталог для SSL с помощью следующей команды:

Затем сгенерируйте ключ и сертификат с помощью следующей команды:

Сначала сгенерируйте ключ с помощью следующей команды:

Вы должны увидеть следующий вывод:

Затем сгенерируйте csr с помощью следующей команды:

Предоставьте всю информацию, как показано ниже:

Затем подпишите сертификат с помощью следующей команды:

Вы должны увидеть следующий вывод:

Затем откройте файл виртуального хоста Nginx по умолчанию и определите сертификат:

Сделайте следующие изменения:

Сохраните и закройте файл, когда вы закончите.

Затем перезапустите сервер Nginx, чтобы применить эти изменения:

Защита паролем каталога

При настройке веб-сервера Nginx вы также можете защитить определенный каталог паролем.

Вы можете сделать это с помощью файла .htpasswd.

Для этого создайте файл с passwd и добавьте в него пользователя с помощью следующей команды:

Вы должны увидеть следующий вывод:

Затем создайте тестовый каталог внутри Nginx с помощью следующей команды:

Затем передайте права владения пользователю www-data с помощью следующей команды:

Затем откройте файл виртуального хоста Nginx по умолчанию с помощью следующей команды:

Nest, защитите тестовый каталог, как показано ниже:

Сохраните и закройте файл, когда вы закончите.

Затем перезапустите службу Nginx, чтобы применить эти изменения:

Затем откройте веб-браузер и введите URL-адрес http://your-server-ip/test.

Вам будет предложено ввести имя пользователя и пароль для доступа к тестовой директории, как показано на следующей странице:

Поздравляем! Вы успешно защитили свой сервер Nginx на сервере Ubuntu 18.04.

Я надеюсь, что это поможет вам защитить ваше приложение, размещенное на веб-сервере Nginx.

Не стесняйтесь спрашивать меня, если у вас есть какие-либо вопросы.

Для получения дополнительной информации вы можете обратиться к документу по безопасности Nginx.

Безопасность веб сервера

WEB-сервер достаточно сложная и потому уязвимая для атак программа. Причем угрозы могут исходить из самых неожиданных мест. Так в конце июня 1997 года было обнаружено, что Windows-95 (и NT) “повисает” (полный перечень причин повисания этой системы может занять целый том) при приходе на ее вход ICMP-пакета с длиной, которая не соответствует значению, указанному в его поле заголовка Длина.

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

Доступ к WEB-серверу имеет пять уровней:

Общедоступный с возможностью только чтения всех URL за исключением тех, что помещены в каталогах /private.

Доступ сотрудников фирмы или организации, которой принадлежит сервер. Здесь также допустимо только чтение, но доступны и секции каталога /private.

Разработчики WEB-сервера. Имеют возможность модифицировать содержимое сервера, инсталлировать CGI-скрипты, прерывать работу сервера.

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

Системные администраторы. Имеют идентичные привилегии с администраторами сервера.

Для получения доступа на уровне 3-5 необходимо письменное разрешение директора организации или его заместителя по информационным системам. Доступ уровня 2 автоматически получают все сотрудники организации или фирмы при авторизации. Администраторы могут аннулировать авторизацию по решению заместителя директора по информационным системам, а при чрезвычайных обстоятельствах самостоятельно, но с последующим уведомлением руководства. Работа с локальной консоли WEB-сервера разрешается только администраторам. Удаленная работа администраторам запрещена, они должны работать только с локального терминала. CGI-скрипты устанавливаются на сервер после их проверки и одобрения как минимум двумя членами группы администраторов. Скрипты, исходные тексты которых недоступны, устанавливаются только по решению заместителя директора по информационным системам.

Информация из каталогов /private, которая считается конфиденциальной, доступна только с терминала самой ЭВМ.

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

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

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

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

Системы Windows NT и UNIX обладают сопоставимыми и достаточно высокими уровнями безопасности. Большое число сообщений о дефектах безопасности UNIX свидетельствует о его массовом использовании.

Теперь рассмотрим, что нужно сделать, чтобы обеспечить максимально возможную безопасность WEB-cервера.

Выбрать наиболее безопасную ОС и сконфигурировать ее с учетом требования безопасности. Использовать все известные корректирующие программы, выпущенные разработчиком ОС.

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

Контролировать доступ к конфиденциальным документам. Доступ к таким документом должен быть разрешен только ограниченному числу пользователей. Доступ к таким частям сервера должен быть организован с использованием протокола SSL.

Тщательно разрабатывать и проверять используемые CGI-скрипты и аплеты.

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

Защитить локальную сеть от WEB-сервера. Исключить возможность проникновения к жизненно важным ресурсам сети через WEB-сервер, например, с помощью Firewall.

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

При работе с ОС Windows NT следует отключить доступ TCP/IP от услуг NETBIOS. Это может быть сделано с помощью Firewall, блокировкой доступа к портам 137 и 138 для UDP и TCP. Можно решить эту проблему отключения NETBIOS от TCP/IP драйвера переконфигурировав Windows NT.

Если WEB-сервер нуждается в контроле доступа, то в настоящее время (в HTTP/1.1) имеется две возможности. Первая (basic) — предполагает традиционный ввод и передачу по сети имени клиента и пароля. Эта схема проста, но допускает перехват параметров доступа (а между клиентом и сервером может быть достаточно много промежуточных узлов). Вторая схема (digest) для пользователя выглядит аналогично, но вводимое имя и пароль не передаются по сети непосредственно. На их базе формируется дайджест MD5, который пересылается по сети и используется для идентификации клиента.

Читать еще:  Политика безопасности это

Apache Web Server Security

21 октября 2016 г. 0 Jack White 1136

В этой статье приведено несколько советов для обеспечения безопасности веб сервера Apache

Перед тем как начать я приведу некоторые базовые настройки сервера:

  • Директория Document root: /var/www/html или /var/www
  • Основной файл настроек: /etc/httpd/conf/httpd.conf (RHEL/CentOS/Fedora) или /etc/apache/apache2.conf (Debian/Ubuntu).
  • HTTP порт по умолчанию: 80 TCP
  • HTTPS порт по умолчанию: 443 TCP
  • Access Log веб сервера: /var/log/httpd/access_log
  • Error Log веб сервера: /var/log/httpd/error_log

Проверьте свои настройки файла конфигурации и синтаксиса: httpd -t или sudu apachectl -t

Скрываем версию Apache и подпись ОС со страниц ошибок

После установки Apache, по умолчанию при отработке страницы ошибки вы можете увидеть версию Apache, установленные пакеты и модули Apache, а также название вашей операционной системы.

Это одна из основных угроз безопасности для веб-сервера, а также для самой ОС. Злоумышленник может воспользоваться этой лазейкой для взлома сервера. Исправим это. Чтобы запретить отображать эту информацию, необходимо внести небольшие изменения в основном (главном) конфигурационном файле Apache.

Откройте файл конфигурации с помощью редактора vim.

Найдите строку ServerSignature и замените ее значение на Off.

Так же найдите строку ServerTokens и установите для нее значение Prod

Таким простым образом мы отключили вывод подписи ОС сервера и Apache.

Чтобы изменения вступили в силу, нужно перезапустить Apache.

Перезапуск Apache для RHEL/CentOS/Fedora:

Перезапуск Apache для Debian/Ubuntu:

Отключаем вывод списка файлов в директории

По умолчанию Apache выводит все содержимое корневой директории при отсутствии индексного файла или запрета в файле .htaccess.

И так, исправить это мы можем с помощью директивы Options, которую нужно отключить в файле конфигурации для конкретного каталога. Для этого нам нужно сделать запись в файле httpd.conf или apache2.conf:

Регулярно обновляйте Apache

Разработчики Apache постоянно работают над обеспечением безопасности и выпускают обновление с новыми параметрами безопасности. Поэтому рекомендуется использовать последнюю версию Apache в качестве веб-сервера.

Проверить версию Apache можно с помощью следующей команды:

Обновить версию можно с помощью следующей команды.

Обновление Apache для RHEL/CentOS/Fedora

Обновление Apache для Debian/Ubuntu

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

Отключаем ненужные модули

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

Для отключения модуля его необходимо закомментировать с помощью #.

Отключить можно следующие модули:

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

Запуск Apache как отдельный пользователь и группа

После установки Apache запускает свой процесс по умолчанию под пользователем nobody или demon. Из соображений безопасности лучше запускать Apache в своем непривилегированном пользователе. Например: http-web.

Создаем пользователя и группу для Apache

Теперь нужно поменять пользователя и группу для Apache: откройте файл /etc/httpd/conf/httpd.conf и смените пользователя и группу:

Чтобы изменения вступили в силу необходимо и перезапустить службу.

Используйте Allow и Deny для ограничения доступа к каталогам

Ограничить доступ к каталогам можно с помощью опции Allow и Deny в файле httpd.conf. Обеспечим безопасность корневого каталога, для этого, установим следующие данные в файле httpd.conf:

  • None — позволит пользователям включать любые дополнительные функции.
  • Order deny, allow — порядок, в котором директивы deny и allow будут обработаны. Сначала запрещаем, а затем разрешаем.
  • Deny from all — отклонить запрос от всех к корневому каталогу, никто не сможет получить доступ к корневой директории.

Обеспечение безопасности Apache с помощью mod_security

mod_security работает как фаервол и позволяет отслеживать трафик в реальном времени. Также, mod_security содержит набор базовых правил фильтрации Core Rule Set, в которые входят правила для защиты от SQL инъекций, межсайтового скриптинга, троянов, ботов, захватов сеанса и многих других атак и взломов.

Установка mod_security на Ubuntu/Debian

Установка mod_security на RHEL/CentOS/Fedora

Отключаем символические ссылки для Apache

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

Чтобы разрешить символические ссылки для конкретного сайта нужно просто добавить правило в файле .htaccess этого сайта:

Чтобы разрешить правила перезаписи внутри .htaccess, в основном конфигурационном файле должна быть запись AllowOverride All.

Выключаем Server Side Includes и выполнение CGI

Мы можем отключить Server Side Includes (mod_include) и выполнение CGI, если это нам не нужно, для этого необходимо изменить основной конфигурационный файл:

Так же можно отключить это для конкретного каталога. Для этого используется тег Directory. Для примера отключим Server Side Includes и CGI для каталога /var/www/html/site:

Так же с помощью директивы Options можно включить или выключить следующее:

  • Options All — включить все (значение по умолчанию).
  • Options IncludesNOEXEC — позволяет выполнять CGI скрипты и файлы.
  • Options SymLinksIfOwnerMatch — похоже на FollowSymLinks, но будет работать только тогда, когда владелец один и тот же между исходной директории и ссылко с которой она связана.

Ограничение размера запроса

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

Включение логирования Apache

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

Для этого вам необходимо включить модуль mod_log_config. Рассмотрим 3 основные директивы mod_log_config.

  • TransferLog — создание файла журнала.
  • LogFormat — установить пользовательский формат.
  • CustomLog — создание и форматирование файла лога.

Это можно использовать как для всего сервера, так и для отдельного файла. Для этого вам необходимо указать его в секции виртуального хоста. Например:

Защита Apache с помощью SSL сертификата

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

О том как установить SSL сертификат на сервер и включить на сайте описано здесь:

БАЗА ЗНАНИЙ

Инструменты пользователя

Инструменты сайта

Содержание

Безопасный доступ к 1С:Предприятие через Интернет

Организация доступа к информационным базам 1С:Предприятия через Интернет по сути своей аналогична установке шкафов с документами организации в стену здания, дверцами наружу. Вы в принципе рискуете и делаете возможным для любого прохожего с улицы:

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

В этой статье мы собрали базовые рекомендации по организации безопасного онлайн доступа к информационным базам 1С:Предприятие с использованием свободного программного обеспечения.

Возможные угрозы

Атака грубой силы

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

На практике используется метод метод перебора по словарю, он отличается от метода полного перебора тем, что в нем перебираются не все возможные пароли, а наиболее часто используемые в порядке убывания популярности. И начинается этот словарь с самых популярных паролей 12345678 и qwerty .

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

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

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

Читать еще:  Корпоративная политика безопасности

Если внешние пользователи подключаются с динамических IP адресов, или они они не сидят на одном месте, но при этом они все-таки являются Вашими сотрудниками — объедините их в виртуальную частную сеть .

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

Атака посредника

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

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

Для защиты от такой атаки существуют удостоверяющие центры (англ. Certification Authority — CA), которые подтверждают клиентам, что Ваш сервер именно тот, за кого он себя выдает. Разумеется, это работает только тогда, когда клиент принимает во внимание результаты такой проверки.

DDoS атака

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

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

Что бы от такой атаки не пострадала работа Вашего предприятия придерживайтесь следующих рекомендаций:

Методы противодействия угрозам

Ограничение доступа по IP адресам

Существует два подхода к вопросам информационной безопасности:

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

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

Хорошая практика — управлять доступностью через межсетевой экран, ограждающий сервер с Apache от Интернета. Настраиваете его сначала на полное блокирование входящих пакетов, а затем добавляете в исключения разрешенные IP адреса и подсети.

Если на Apahe публикуется несколько виртуальных хостов и не для всех приемлемы столь строгие ограничения доступа, ограничьте доступ на уровне настройки виртуального хоста Apahe или .htaccess, добавьте директивы

Построение виртуальной частной сети

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

Гораздо безопаснее развернуть виртуальную частную сеть — VPN. Единственная «проходная» из Интернет к Вам в офис — это шлюз VPN, а при грамотной настройке это очень хорошо защищенная проходная.

Шлюз VPN можно поднять на роутере, практически все модели профессионального оборудования имеют такую встроенную функцию. Или это можно сделать на отдельном сервере.

Оптимальный вариант — разместить шлюз в DMZ, он будет принимать входящие запросы из Интернет, следовательно он подвержен внешним угрозам. Для этого идеально подойдет небольшой сервер на Ubuntu с установленным на нем сервером OpenVPN.

Клиентские части OpenVPN есть для всех популярных платформ.

Использование цифровых сертификатов пользователя

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

Веб-сервер Apache и веб-клиетнт 1С:Предприятие поддерживают аутентификацию по SSL-сертификатам. Внешний пользователь сначала будет проверен средствами Apache, и только пользователь, предъявивший действующий сертификат будет допущен к форме ввода логина-пароля 1С:Предприятие.

Для начала нужно развернуть у себя Certification Authority (CA). Тут паранойя лишней не бывает, вот неплохой HOW-TO по безопасной установке CA.

Сгенерируйте и удостоверьте в CA нужное количество пользовательских сертификатов.

Обычно клиентские сертификаты выдаются пользователям в виде зашифрованных .pfx или .p12 файлов. Такой файл можно передавать, копировать, пересылать по электронной почте, но для того, что бы им воспользоваться, нужно знать пароль, которым он зашифрован. Если такой уровень безопасности Вы считаете недостаточным и готовы увеличить свои расходы на информационную безопасность — используйте USB токены с поддержкой SSL. Запишите пользовательский сертификат в токен и запретите его экспортировать. Теперь без этого токена никак к Вам не зайти.

Остается настроить Apache. В описании виртуального хоста, там где Вы настраивали HTTPS добавьте

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

Использование подписанных сертификатов сервера

Для безопасного обмена информацией в Интернет важно, что бы не только сервер был уверен, что клиент именно тот, за кого он себя выдает, но и клиент мог удостовериться, что он соединился именно с тем сервером, который ему нужен, и что передаваемую между ними зашифрованную информацию никто другой не прочитает. Помогают в этом удостоверяющие центры, англ. Certification Authority (CA).

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

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

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

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

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

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

Роль «нотариуса» в Интернете выполняют т.н. доверенные удостоверяющие центры. Корневые сертификаты таких CA по-умолчанию установлены в браузеры, и браузеры по-умолчанию доверяют сайтам, предъявляющим сертификаты, подписанные доверенными CA.

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

Когда Вы установите такой сертификат себе на сервер, браузеры сразу будут считать Ваш сайт безопасным.

В веб-клиенте 1С:Предприятия есть настройка проверки сертификата сервера.

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

Никогда ни при каких обстоятельствах не передавайте посторонним приватный ключ.

Безопасность веб сервера

Взлом и защита веб-сервера — на каждый яд есть свое противоядие

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

Все тесты проводились на сервере следующей конфигурации ОС: FreeBSD 6.0; Apache 2.0.x, PHP-5.2.x.

Читать еще:  Протоколы информационной безопасности

Согласно официальной статистике количество веб-сайтов, которые могут быть взломаны, составляет примерно 1/3. “Неужели хостинг-компании не способны обеспечить должный уровень защищенности веб-сайтов?” – спросят многие.

“Способны”, – отвечу я вам, вот только вопрос, какими усилиями.

Можно считать, что безопасность веб-сервера держится на двух китах. Первый из них — это непосредственно безопасность кода веб-приложения (этот вопрос мы оставим для программистов, слава Богу, статей на тему написания безопасного кода предостаточно). Второй — это тонкое конфигурирование сервера силами системного администратора или специалиста ИБ-шника, привлеченного со стороны. О втором “ките” мы как раз и поговорим.

На сегодняшний день в арсенале взломщиков имеется более десятка проверенных техник взлома веб-приложений. С полным перечнем вариантов взлома можно ознакомиться, изучив «Классификацию угроз безопасности веб-приложений» (согласно Web Application Security Consortium//www.webappsec.org). Популярнейшими из атак являются всего три. Кратко рассмотрим их.

1) SQL-injection (SQL-инъекция). На сегодняшний день является одним из самых популярных и опасных способов взлома сайтов. Атака основана на внедрении в запрос произвольного SQL-кода с целью получения критичной информации из баз данных (логины и хеши паролей пользователей). Технически подобная атака возможна из-за недостаточной фильтрации входящих данных, используемых в SQL-запросах. Взлом также возможен и по причине некорректно настроенной серверной ОС и ее приложений (Apache, PHP, MySQL).

2) PHP-including (внедрение PHP-кода). В отличие от XSS (где код выполнялся в браузере клиента; о XSS мы поговорим ниже) PHP-include позволяет выполнить произвольный код на стороне сервера. Различают два типа PHP-include:
— локальный PHP-include (LFI) — подразумевает выполнение PHP-кода, находящегося в пределах файловой системы сервера;
— глобальный PHP-include(RFI) — подразумевает выполнение PHP-кода путем подключения файлов извне.

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

Рис.1. Чтение системного файла /etc/passwd посредством локального PHP-include

В любом из случаев взломщик постарается выжать из обнаруженной уязвимости максимум. Как вариант – предварительно залив на сервер простейший веб-шелл (используя технику apache log file injection, к примеру), у хакера появится возможность выполнять произвольные команды от имени веб- сервера:

[pic]
Рис.2. Выполнение произвольных команд на стороне сервера

Даже если вы не используете php, и сайт создан исключительно на html – это еще не говорит о том, что его нельзя взломать. Почему так? Да все просто. Чаще всего на сервере хостится не один, а несколько веб-проектов (если это, конечно, не Dedicated или VPS-сервер с одним сайтом на борту). Достаточно взломать соседний, чтобы получить доступ к вашему. Да, существуют технологии, ограничивающие действия взломщиков в соседних каталогах в случае успешного взлома (как пример, suEXEC), но как оно всегда и бывает, внедрению подобных технологий препятствует сложность настройки, а порой и просто незнание.

3) XSS* (cross site scripting, межсайтовый скриптинг). Суть данной атаки заключается в том, чтобы внедрить в веб-страницу произвольный код, который впоследствии выполнится на стороне клиента (в браузере жертвы). Условно XSS делятся на активные и пассивные:

— активные XSS: вредоносный скрипт срабатывает в браузере жертвы, при открытии какой-либо страницы зараженного сайта; XSS подобного типа может иметь место при условии слабой фильтрации полей ввода. Как правило, подобный тип атаки может быть осуществлен с использованием некорректной фильтрации в полях профиля пользователя, комментариях и т.п.;

— пассивные XSS: данный тип XSS подразумевает некое дополнительное действие со стороны клиента, обычно это переход по специально
сформированной ссылке.

Чаще всего XSS используется для хищения cookies пользователя и как следствие — паролей и логинов.

*В контексте данной статьи мы не будем заострять внимание на защите от XSS, оставив эту задачу разработчикам ПО (большинство из XSS можно отнести к категории недоработок программного кода) и клиентам (в отличие от PHP-инклудинга и SQL-инъекций, которые выполняются на стороне сервера, XSS, как это уже было сказано выше, выполняется в браузере клиента). Резонными мерами защиты от XSS может быть использование плагина NoScript и прочих аналогичных модулей/надстроек браузера, на лету фильтрующих подозрительное содержание веб-страниц.

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

Рис. 3. SNORT: Зафиксирована попытка использования exploit’а

Ставим IDS (Intrusion Detection System — система обнаружения вторжений), как хороший пример – SNORT. Принцип работы IDS основан на обнаружении сигнатур возможных атак. IDS позволит нам оперативно анализировать попытки взлома и принимать эффективные решения для защиты сервера. Также следует отметить и то, что альтернативой IDS может стать IPS (Intrusion Prevention System — система предотвращения атак), и это в большей степени зависит от предназначения и загрузки сервера.

После запуска SNORT все нехорошие запросы будут записываться в лог-файл:

Рис. 4. SNORT: Зафиксирована попытка атаки «webroot directory traversal»

Как видите, теперь у нашего сервера есть первый рубеж обороны – SNORT, способный проинформировать администратора сервера о подозрительной активности извне.

Помещаем Apache и MySQL в chroot. Напомню нашим читателям, что chroot представляет собой ограниченную для доступа наружу (к реальной файловой системе) среду, позволяющую минимизировать последствия в случае успешного взлома. Методология создания chroot-среды хорошо отработана и документирована, и фактически сводится к созданию в файловой системе автономной зоны со своим набором файлов и папок.

Рис.5. Запуск MySQL в chroot-окружении

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

Mod_security очень часто называют веб-антивирусом, и это отчасти верно. Именно благодаря mod_security становится возможным предотвращение большинства типов атак – таких, например, как SQL-injection и PHP-Including.
Рассмотрим на реальном примере результат работы mod-security. При попытке прочитать системные файлы в лог-файлах вашего сервера вы увидите примерно следующее:

Рис.6. Mod_security: предотвращена попытка удаленного просмотра системных файлов

Ответ веб-браузера при попытке просмотра системного файла при включенном mod_security выдаст вам “Method Not Implemented”:

Рис.7

Мы уже прошли большой путь, установив SNORT, поместив Apache и MySQL в chroot, подключив модули mod_security и mod_rewrite, но это еще не все :).
Следующим шагом на пути создания многоуровневой защиты нашего веб-сервера станет непосредственно конфигурирование Apache и PHP.

Делаем Apache менее разговорчивым

Подробную инструкцию по конфигурированию Apache можно найти на официальном сайте www.apache.org, здесь же мы ограничимся минимумом. Подразумевается, что ваш веб-сервер уже настроен и не содержит таких досадных ошибок администрирования, как, к примеру, доступные для индексирования директории с конфиденциальными данными и права rwxrwxrwx на файл «.htaccess». Основным файлом настроек для апача является httpd.conf.

Наш минимум сделать апач менее разговорчивым с «незнакомыми» посредством добавления (изменения) следующих строк:
ServerTokens Prod и Server Signature Off.

Делаем выполнение PHP-кода более безопасным

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

Первым делом нам необходимо установить Suhosin Patch (в последних версиях PHP Suhosin устанавливается вместе с PHP по умолчанию). Напомню нашим читателям, что данный пакет позволяет эффективно контролировать выполнение потенциально опасного PHP-кода.

Изменяем настройки PHP, для этого нам надо отредактировать его главный файл настроек php.ini (в Unix-подобных системах конфигурационный файл может быть размещен, к примеру, здесь: /usr/local/etc/php.ini для Free BSD или здесь: /etc/php.ini для Linux систем).

. register_globals=Off – отключаем глобализацию переменных. Значение в On – пожалуй, самая известная ошибка конфигурирования PHP;
. safe_mode=On — включаем жесткий режим ограничений (с этой настройкой следует быть аккуратным);
. open_basedir= /www – ограничиваем место выполнения PHP-кода;
. magic_quotes=On — включаем «магические кавычки» для GET/POST/COOKIE — препятствует SQL-inj;
. mysql.trace_mode=Off — отключаем показ ошибок Mysql;
. allow_url_fopen=Off — отключаем удаленное открытие файлов файловыми функциями (препятствует удаленному PHP-инклуду);
. allow_url_include=Off — отключаем удаленное подключение файлов (препятствует удаленному PHP-инклуду);
. error_reporting=Off — отключаем показ всех ошибок (действительно, зачем посвящать взламывающего во все тонкости работы сервера:)); . disable_functions= exec, system, passthru – задаем ограничение на использование потенциально опасных функций.

Итак, давайте теперь посмотрим, как отреагирует наш веб-сервер на попытку использования запрещенной функции (мы неслучайно отключили exec, system и passthru – эти функции активно используются при написании самодельных веб-шеллов!):

Рис. 8. Ограничение на использование потенциально опасных функций

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

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

голоса
Рейтинг статьи
Ссылка на основную публикацию
Adblock
detector