Обеспечение безопасности сервера

Как обеспечить безопасность сервера?

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

• инфобезопасность;
• техбезопасность;
• организационная (она же административная) безопасность.

Стоит узнать подробнее о каждом понятии.

Информационная безопасность

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

Техническая безопасность

Здесь безопасность сервера определяется физическим функционированием ВТ и комплексом дополнительного оборудования. Следует уделять необходимое внимание вопросу технической безопасности, потому что сейчас его катастрофически не хватает.

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

Организационная или административная безопасность

Этот вид безопасности должен нужным образом обеспечивать работоспособность системы целиком (а не только серверной станции) с помощью административно-хозяйственных методов. Почему-то эту часть вопроса безопасности в настоящее время мало освещают в статьях. Безопасность сервера в организационном смысле содержит много вопросов, которые тесно связаны с административным ограничением доступа к объектам системы. Для безопасности необходимо создание списка определённых лиц, которые будут иметь доступ ко всей информации и техническим средствам, а также нужен режим выбора и смены паролей в системе, и, конечно, вопросы конфиденциальности информации.

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

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

И только при комплексном подходе можно получить гарантию хорошего результата и безопасности.

Обеспечение безопасности серверов и веб-сайтов

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

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

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

• Monitorus круглосуточно наблюдает за вашим сайтом и в случае обнаружения каких-либо проблем или подозрительной активности на сайте немедленно информирует вас об этом по e-mail и sms. Monitorus круглосуточно проверяет работоспособность сайта с интервалом от 1 минуты. Постоянно контролирует файлы сайта на изменение, добавление и удаление без вашего ведома. Регулярно проверяет сайт на наличие вирусов, в том числе вирусов организующих поисковый и мобильный редирект. Проверяет не попал ли ваш сайт в базы антивирусов. Следит за валидностью и сроком действия вашего SSL сертификата. Рассчитывает показатель Uptime и выводит его на сайте в специальном виджете. Также вы можете установить на сайт информер сертификата безопасности сайта от Monitorus. Под защитой сервиса находится 18 тысяч сайтов.
• Levelab предлагает услуги по техподдержке и аудиту безопасности ваших сайтов. Аудит безопасности включает симуляцию хакерской атаки на сайт с целью выявления потенциальных уязвимостей для получения контроля над сайтом/сервером и его компонентами. По итогам аудита предоставляется подробный отчет по каждой обнаруженной уязвимости и даются рекомендации по их устранению. Техподдержка включает постоянный мониторинг работоспособности сайта и информирование при возникновении подозрительной активности, своевременное обновление ПО и регулярное резервное копирование на независимое от вашего хостинга облачное хранилище. Если же предпринимаемых в рамках техподдержки профилактических мероприятий оказалось недостаточно для полной защиты сайта, то выполняются все необходимые работы по очистке сайта от вредоносного и шпионского ПО.
• Компания «Ревизиум» — более 7 лет остается, пожалуй, главной «скорой помощью» для взломанных и зараженных сайтов. В течение 48 часов с момента обращения специалисты компании восстанавливают работоспособность сайта, очищают его от вирусов и вредоносного кода и настраивают защиту от веб-атак. «Ревизиум» — авторы технологии «цементирования» сайта — эффективной комплексной защиты от взлома; разработчики популярного вирусного сканера «AI-BOLIT» и сервиса диагностики безопасности «Revizorro», которыми пользуются крупнейшие хостинг-компании Рунета, сотни веб-студий и тысячи веб-разработчиков по всему миру. Также стоит отметить, что с момента своего основания, компания активно принимает участие в становлении и развитии сегмента рынка безопасности сайтов.
• Сервис StormWall предоставляет услуги защиты от всех имеющихся на текущий момент типов и разновидностей DDoS атак: IP malformed, TCP SYN flood, ICMP flood, TCP-malformed, SlowLoris, ICMP smurf, HTTP POST flood, HTTP SLOW POST и др. Фильтрующее оборудование компании StormWall позволяет успешно отражать DDoS атаки любой мощности. Инженеры компании несут круглосуточное дежурство и готовы оперативно прийти вам на помощь. Предлагаются удобные тарифы для корпоративных веб-сайтов, интернет-магазинов, игровых проектов, финансовых проектов, а также для хостинговых компаний и дата-центров. Специалисты и руководители компании внимательно следят за тенденциями в области защиты от атак, принимают участие в работе тематических семинаров и конференций, ведут блог по вопросам ИТ-безопасности.
• FSCURE — здесь вы можете бесплатно скачать скрипт для удаления вирусов на сайтах. Скрипт предназначен для автоматического поиска вирусов по сигнатурам. При запуске скрипт выводит список файлов содержащих потенциально вредоносные сигнатуры. «Потенциально вредоносные» это значит, что решать вирус это или не вирус, придется вам. Для успешного применения скрипта требуется некоторая квалификация, и если вам трудно самостоятельно проделать работы по очистке сайта, то можете обратиться за помощью к разработчику скрипта. Услуги платные, но цены разумные. Разработчик скрипта автор многочисленных публикаций в области защиты информации вообще и защиты веб сайтов от вирусов в частности.
• ProtectYourSite — это качественное удаление вирусов с сайта с последующей установкой защиты от дальнейшего взлома. Многолетний опыт позволит разрешить любую проблему и найти самые заковыристые вредоносные вставки, а ручное удаление оставит сайт работоспособным. Кроме этого вы можете заказать аудит безопасности вашего сайта и выявить слабые стороны и потенциальные уязвимости, такие как SQL инжекты, уязвимости полей ввода CSRF и т.д. и получить рекомендации по устранению этих уязвимостей. Также при необходимости вы можете заказать удаление вирусов с сайтов под управлением Joomla, WordPress, Drupal. Одновременно с работами по очистке сайта проводится анализ и устранение дыр, через которые происходит проникновение вирусов и предлагаются варианты организации антивирусной защиты. При необходимости производится апгрейд CMS, причем не только ядра, а по возможности всех необходимых для работы сайта модулей и плагинов. Все работы производятся оперативно, с высоким качеством и по разумным ценам. Имеется представительный портфолио и многочисленные положительные отзывы клиентов.

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

Рекомендации по защите: 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. Логирование и аудит.
Настройте ведение подробных логов, хотя бы по работе критически важных сегментов вашей инфраструктуры и регулярно инспектируйте их.

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

• Главная
• Сетевая безопасность. Часть 1 — Ubuntu Server.

Сетевая безопасность. Часть 1 — Ubuntu Server.

• Автор: Уваров А.С.
• 20.09.2011

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

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

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

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

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

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

С чего начинается безопасность?

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

Поэтому первое, что вы должны сделать — это провести аудит безопасности. Не пугайтесь этого слова, все не так сложно: начертите схематический план сети, на котором отметьте безопасную зону, зону потенциальной опасности и зону повышенной опасности, а также составьте список пользователей которые имеют (должны иметь доступ) к этим зонам.

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

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

К опасной зоне следует отнести устройства непосредственно доступные извне, в идеальном случае это должен быть один роутер.

По возможности потенциально опасную зону следует вынести в отдельную подсеть — демилитаризованную зону (DMZ), которая отделена от основной сети дополнительным брандмауэром.

Устройства локальной сети должны иметь доступ только к тем службам в DMZ, которые им необходимы, например SMTP, POP3, HTTP, остальные соединения должны блокироваться. Это позволит надежно изолировать злоумышленника или вредоносное ПО, воспользовавшихся уязвимостью в отдельном сервисе, демилитаризованной зоной, закрыв им доступ к основной сети.

Физически DMZ можно организовать поставив отдельный сервер / аппаратный брандмауэр или добавив дополнительную сетевую карту в роутер, однако в последнем случае придется уделить пристальное внимание безопасности роутера. Но в любом случае обеспечить безопасность одного сервера гораздо проще, чем группы серверов.

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

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

Кроме того пароль не должен включать логин пользователя или его часть, не содержать дат и имен, которые можно связать с пользователем и, желательно, не являться словарным словом.

Неплохо завести практику менять пароли раз в 30-40 дней. Понятно, что подобная политика способна вызвать неприятие со стороны пользователей, но вы должны всегда помнить, что пароли типа 123 или qwerty равносильны ключу оставленному под ковриком.

Безопасность сервера — ничего лишнего.

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

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

Сконфигурируйте службы, обслуживающие локальную сеть (например squid), таким образом, чтобы они принимали запросы исключительно с локального интерфейса. Чем меньше служб доступно извне, тем лучше.

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

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

Сканер показывает открытые порты, пытается определить тип работающей службы и, если это удалось, уязвимости для нее. Как видим — правильно сконфигурированная система вполне безопасна, однако не стоит оставлять ключ под ковриком, наличие на роутере открытых портов 1723 (VPN) и 3389 (RDP, проброшен на терминальный сервер) хороший повод подумать о политике паролей.

Отдельно стоит поговорить о безопасности SSH, данная служба обычно используется администраторами для удаленного управления сервером и представляет повышенный интерес для злоумышленников. Настройки SSH хранятся в файле /etc/ssh/sshd_config, все описываемые ниже изменения вносятся в него. В первую очередь следует запретить авторизацию под пользователем root, для этого добавьте опцию:

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

Стоит явно указать список разрешенных пользователей, при этом можно использовать записи типа user@host, которая разрешает указанному пользователю подключаться только с указанного хоста. Например чтобы разрешить пользователю ivanov подключаться из дома (IP 1.2.3.4) следует добавить следующую запись:

Также запретите использование устаревшего и менее безопасного протокола SSH1, разрешив только вторую версию протокола, для этого приведите следующую строку к виду:

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

Данная утилита готова к работе сразу после установки, однако мы бы советовали сразу изменить некоторые параметры, для этого внесите изменения в файл /etc/fail2ban/jail.conf. По умолчанию контролируется только доступ к SSH и время бана составляет 10 минут (600 секунд), на наш взгляд стоит его увеличить, изменив следующую опцию:

После чего пролистайте файл и включите секции для работающих в вашей системе служб, установив после имени соответствующей секции параметр enabled в состояние true, например для службы proftpd это будет выглядеть так:

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

Лог работы утилиты вы можете посмотреть в /var/log/fail2ban.log.

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

6.7 Безопасность WEB-серверов

Семенов Ю.А. (ИТЭФ-МФТИ)
Yu. Semenov (ITEP-MIPT)

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

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

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

1. Общедоступный с возможностью только чтения всех URL за исключением тех, что помещены в каталогах /private.
2. Доступ сотрудников фирмы или организации, которой принадлежит сервер. Здесь также допустимо только чтение, но доступны и секции каталога /private.
3. Разработчики WEB-сервера. Имеют возможность модифицировать содержимое сервера, инсталлировать CGI-скрипты, прерывать работу сервера.
4. Администраторы узла (сервера). Имеют те же привилегии, что и разработчики, но могут также реконфигурировать сервер и определять категорию доступа.
5. Системные администраторы. Имеют идентичные привилегии с администраторами сервера.

Для получения доступа на уровне 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, который пересылается по сети и используется для идентификации клиента.