4 заметки с тегом

безопасность

/core.php, line 2
Error 2: Use of undefined constant k - assumed 'k' (this will throw an Error in a future version of PHP)

/core.php, line 2
Error 2: Use of undefined constant k - assumed 'k' (this will throw an Error in a future version of PHP)

/core.php, line 2
Error 2: Use of undefined constant k - assumed 'k' (this will throw an Error in a future version of PHP)

/core.php, line 2
Error 2: Use of undefined constant k - assumed 'k' (this will throw an Error in a future version of PHP)

Неожиданное решение

Вчера утром передо мной была поставлена задача разобраться с интернетом в профилактории: убрать ненужные точки подключения, понять сколько мы платим сейчас за интернет и т. п. И сделать общедоступную сеть для проживающих. Ну как бы не вопрос!
Позвонил провайдеру, где меня обругали за то, что я не могу назвать номера счетов. Хм, действительно, что это я? По названным IP-адресам назвали текущие тарифы и сумму оплаты в месяц. Звоню главному бухгалтеру профилактория, прошу у нее номера счетов. В ходе разговора выясняется, что их не два, а три. А я почему-то знаю только про две точки подключения. С какой целью заключался третий договор она назвать не смогла, посоветовала спросить у инженера. Звоню директору, надеясь, что он-то должен быть в курсе зачем там третий договор. Наивный... Директор тоже не в курсе и тоже ссылается на инженера. Прошу соединить меня с ним. Через минут 5 он сам перезванивает, задаю ему тот же вопрос — зачем заключали третий договор с провайдером. Он тоже не в курсе. «Зашибись!» — думаю, — «договор есть, но никто не в курсе зачем он там.» Минут через 5 он все-таки вспомнил и выдает примерно такую фразу: «Мы же лифт к интернету подключили, вспомнил.» Моя реакция была примерно такой

Что, блядь?

Далее выясняются причины такого «нестандартного» подхода. Одной из проверяющих организаций не понравилось, что люди, застряв в лифте, нажимают кнопку вызова диспетчера и попадают к администратору на первом этаже. Тот, в свою очередь, звонит в лифтерную и сообщает о поломке. Интернет был подключен для того, чтобы после нажатия кнопки вызова в лифте, люди напрямую. соединялись с лифтерной. Любопытно, но понятно.
В общем, собрал всю информацию по интернету в профилактории, иду «сдаваться» начальству. Рассказываю:

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

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

Убираем название сервера Apache

Не совсем, конечно, правильный заголовок, но какой уж есть...
Собственно, сегодня я не планировал этим заниматься, просто так вышло. На сервере установлен Apache версии 2.4. При помощи двух параметров (ServerTokens Prod и ServerSignature Off) можно сократить название сервера до банального Apache. Но убрать само название сервера «нельзя». Для того, чтобы это сделать понадобится установить или включить дополнительный модуль mod_security. У меня он установлен не был, но был в репозитории. Раньше, кстати, когда был установлен Apache версии 2.2, его там не было, поэтому приходилось довольствоваться тем, что получилось. Итак, установил модуль, включил его и... поймал ошибку при запуске сервера. Что за ошибка было поначалу не совсем понятно, поскольку ее текст уходил за пределы экрана. Пришлось вывод команды перенаправить в файл, из которого уже стало понятно, что сервер не может найти файлы конфигурации в подкаталоге модуля. Посмотрев в папке, вообще не нашел таковых. Видимо, не очень-то они и нужны. Поэтому просто закомментировал эти строчки и еще раз перезапустил сервер. На этот раз все прошло штатно, он заработал. «Хорошо», подумал я и добавил в файл конфигурации модуля строку

SecServerSignature " "

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

2017   apache   безопасность   имя   настройка   сервер

Связка nginx+Apache

Немного почитав про эту связку, пришел к выводу, что стоит попробовать ее использовать. Установил nginx, перенастроил Apache таким образом, чтобы он работал только локально, затем настроил nginx таким образом, чтобы он все запросы отдавал Apache. Потом еще некоторое время пришлось повозиться с настройками nginx, но вуаля! Я добился-таки того, что все сайты, на которых я проводил тестирование своего сервера, выдали мне оценку «А+». Итак, что из «плюсов» мы имеем:

  • — возросла скорость загрузки сайта;
  • — уменьшилась нагрузка на Apache;
  • — статические данные теперь отдает nginx, динамические — формирует Apache;
  • — остались все «плюшки» .htaccess;
  • — возросла безопасность сервера.

Из «минусов»:

  • — теперь на сервере у меня два веб-сервера.

Чуть позже попробую конфигурацию с «голым» nginx, если его работа меня устроит, то, скорее всего, полностью перейду на него. Теперь что касается безопасности сервера (ну да, у меня маленький бзик на этот счет).

В связи с тем, что nginx, в отличие от Apache, поддерживает наборы шифрования ECDHE, появилась возможность их использовать. Также он поддерживает OCSP stapling, что позволяет немного ускорить загрузку страниц при работе через HTTPS.

Тестирование проводилось при помощи трех сайтов: SSL Analyzer от Comodo, Free SSL Server Test от High-Tech Bridge, ну и конечно незабвенный SSL Server Test от лаборатории Qualys SSL.

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

Затем тест проводился при помощи High-Tech Bridge. По скорость он является более медленным, но проверяет чуть больше параметров. В том числе на соответствие требованиям NIST (американский институт стандартов и технологий) и стандарта PCI DSS. Здесь пришлось немного попотеть, разыскивая наборы шифрования, которые, по его мнению, должны быть включены в список.

И под конец проверка шла при помощи Qualys SSL. Он является самым медленным из указанного списка, но выдает результаты практически по всем параметрам. Здесь пришлось поработать над несколькими пунктами, но и тут была одержана победа.

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

  • — сервер работает только по протоколу TLS;
  • — слабые шифры удалены из списка;
  • — Perfect Forward Secrecy (PFS) работает со всеми более-менее новыми браузерами;
  • — поддерживаются HSTS и HPKP;
  • — поддерживается OCSP stapling;
  • — работает Content Security Policy;
  • — работает вся ранее настроенная в Apache защита от атак.

В общем все круто и я всем доволен :-) Кроме, разве что того момента, что теперь в этом плане мне делать нечего и скоро я опять начну скучать.

Повышение безопасности сервера при помощи заголовков

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

  1. HTTP Strict Transport Security (HSTS) — позволяет форсировать HTTPS подключение.
  2. HTTP Public Key Pinning (HPKP)  — позволяет создать своеобразную «электронную подпись» для вашего сайта.
  3. X-Download-Options со значением «noopen» позволяет запретить открытие любых файлов с вашего сайта (например, документов в формате PDF), становится возможно только скачать их.
  4. X-Content-Type-Options со значением «nosniff» инструктирует Internet Explorer версии 8 не определять автоматически content-type, а использовать уже полученный.
  5. Еще один заголовок X-XSS-Protection со значением «1; mode=block» активирует встроенную защиту от XSS (Cross-Site Scripting, «межсайтовый скриптинг»).
  6. X-Frame-Options со значением «SAMEORIGIN» запрещает открывать страницы вашего сайта во фрейме на чужом сайте.
  7. Заголовок Set-Cookie должен указываться с параметрами HttpOnly и Secure. Это предотвратит XSS-атаки и защитит cookie от кражи при помощи скрипта javascript.
  8. В заголовке Server также должна быть указана минимальная информация о сервере. Например, просто Apache. Это не даст злоумышленнику получить дополнительную информацию о программном обеспечении, установленном на вашем сервере.
  9. По аналогичным причинам рекомендуется убрать заголовок X-Powered-By, если таковой присутствует.

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

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

Если вы думаете, что я что-то пропустил, то пишите в комментариях.