Часто вирусные файлы приходят в виде тех же vbs скриптов, упакованных в архив. Я не буду говорить про другие форматы, их не так уж и много, но каждый из них может доставить кучу неприятностей. Особенно если это будет шифровальщик.
Так уж сложилось, что несмотря на все ухищрения, используя стандартные методы, нельзя заставить ClamAV проверять архивы на наличие файлов определенного типа. Он может только попытаться определить заражен ли тот или иной файл в архиве, но со скриптами у него явные проблемы. Скрипт по сути представляет собой обычный текстовый файл, поэтому найти в нем код вируса достаточно проблематично.
Часть этого вопроса удалось решить, заставив postfix отбрасывать письма, в которые вложены файлы из «черного» списка. Но он не может работать с архивами, увы. Это был первый, так сказать этап, который успешно показал себя.
Вторым этапом стал поиск файлов в архивах при помощи ClamAV. Оказывается, можно все-таки заставить его проверять архивы на наличие нужных файлов. Неслучайно копаясь в интернете, наткнулся на эту вот замечательную статью. Использовав информацию из нее, подкинул созданный файл в папку с антивирусными базами ClamAV и перегрузил его. Никаких исправлений в файлы конфигураций вносить не пришлось, он сразу его подхватил. Далее я отправил письмо, полученное утром, и содержащее vbs-скрипт в архиве .7z через этот сервер. Хотел было поймать процесс обработки письма, но не успел. Впрочем, через минуту мне на почту упало сообщение от антивируса, что письмо обработано, найден архив с «вредным» файлом и что письмо было заблокировано. Это было все, чего я добивался.

Virus name: rules_block_7z_vbs.UNOFFICIAL
Sender: *****@*****.ru
Recipient(s): *****@*****.ru

Quarantined to: /var/tmp/virus.yHPWqV

Сам файл с нужными определениями состоит из строк вида

rules_block_exe:CL_TYPE_MAIL:*:\.[Ee][Xx][Ee]$:*:*:*:*:*:*

Здесь самыми интересными для нас являются три поля: имя правила, тип правила и расширение файла. Имя и тип задаются первыми двумя параметрами, разделенными двоеточием. Затем идет имя файла с расширением в виде regexp-строки. Оставшиеся параметры оставляем без изменений. Расширение файла указывается в обоих регистрах.

На днях установил себе, ради эксперимента, Nextcloud. Это вроде как свое личное облако. Поначалу были проблемы с загрузкой файлов — более одного мегабайта закачивать не мог. После кучи экспериментов оказалось, что вся проблема в модуле security для apache. Поиск в гугле с соответствующим запросом помог решить этот вопрос. Дальнейшее подключение других модулей проблем никаких не вызвало, кроме нескольких.
На первой стадии это был модуль Sensors Logger. Почитал крайне «тощую» документацию, состоящую из нескольких предложений и все равно ничего не понял. Хотя было бы интересно иметь готовый веб-интерфейс для своих датчиков. Далее на очереди был модуль Collabora Online. Вот здесь я застрял надолго. Все таки интересно, когда ты открываешь файл в облаке и можешь его редактировать. Пусть даже и с ограниченной, по сравнению с программами для обычных компьютеров, функциональностью, но все же! На решение проблем с ним я потратил, можно сказать, три дня — пятницу и все выходные. И только сегодня проблема была решена. Заключалась она в моей тяге к защите информации. В данном случае — в настройках CSP, которые запрещали взаимодействие между моими сайтами. После внесения исправлений все заработало. Ну как заработало... На домашнем компьютере под управлением Linux в браузере Firefox нифига не работает, в то время как на том же компьютере, но в браузере Chrome все нормально. Все нормально работает также на рабочем компьютере под Windows с браузерами Firefox, Internet Explorer и Chrome. Решив эту проблему, вернулся к Sensors Logger. Почитал снова документацию и опять нифига не понял. Отключил модуль, оставлю на потом.
Забавно было подключить другие свои сайты к Nextcloud. Например, этот блог, домен с зеркалом обновлений NOD32 и видеонаблюдением. Все работало, пока я не пришел домой. Снова препоной стал Firefox, в Chrome все нормально. Не хотелось бы, но, может быть, стоит вернуться на Chrome? Надо почитать последние исследования по браузерам. Насколько я помню, Chrome полностью отказался от работы в Windows XP. Кстати, сайты, подключенные к Nextcloud, отображаются как его дочерние окна — вот что мне было интересно.
Не полностью тестировал еще синхронизацию контактов и календарей в этом облаке. Но что мне понравилось — после синхронизации контактов, Nextcloud сам создал события в календаре по дням рождений. Это хорошо, избавляет от необходимости вводить их вручную.
Пытался также подключить модуль для управления проектами на Github. Обломался. Снова подвела крайне скудная информация по модулю. Снова буквально пара строк. Или я уже совсем умственно деградировал?
Если получится создать свое облако, где можно хранить несколько сотен гигабайт информации, может быть, настанет пора отказаться от всяких второстепенных программ? На текущий момент сервер собирает почту со всех моих аккаунтов и складывает все в один ящик. Все данные вроде календарей и контактов можно также агрегировать в одно место. Конечно, никуда не девается вопрос об отказоустойчивости системы и, лучше всего, ее распределенности, но это, как ни странно, тоже вполне решаемый вопрос.

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

SecServerSignature " "

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

Этот вопрос давно висел в воздухе, но вспомнили про него только недавно. Задача: сделать общую адресную книгу для сети аптек. Сразу скажу, что в качестве почтового клиента там используется TheBat! Это довольно важный вопрос, ниже опишу почему.
Я перебрал несколько самых разных вариантов серверов, которые работают с carddav. Основной упор был на то, чтобы либо поставить его из репозитория системы, либо он должен быть полностью автономным. Например, написанным на PHP. В итоге мне попался Baikal, который работал по второму варианту. Установка и настройка крайне просты, описывать их смысла нет. Но, как оказалось позднее, есть в настройках один нюанс, из-за которого TheBat! не сможет работать с ним, в то время как остальные программы типа Thunderbird или EssentialPIM прекрасно выполняют синхронизацию. Этот параметр называется «WebDAV authentication type» и предоставляет на выбор два варианта: Digest и Basic. Если вы при установке Baikal выберете Digest, то сможете использовать адресную книгу или календарь такими программами как Thunderbird, но не сможете использовать TheBat!. В случае с Basic TheBat! прекрасно работает, но в этом случае не сможет синхронизироваться Thunderbird. Другие почтовые клиенты я не проверял за их отсутствием.
Допустим, вы установили и настроили Baikal, сейчас вам нужно настроить клиента. Приведу настройки для трех программ: Thunderbird, TheBat! и EssentialPIM.

Thunderbird
Для того, чтобы иметь возможность подключения к серверу carddav, сначала нужно установить SOGo Connector. Для этого идем по этому адресу, выбираем вкладку Frontends и скачиваем последнюю версию SOGo Connector. На этот момент это версия 31.0.5, которая прекрасно работает с Mozilla Thunderbird 45.
Открываем пункт меню Инструменты — Адресная книга. Если вы правильно установили расширение для программы, то у нас появится пункт меню Файл — Создать — Remote address book. Выбираем его. В поле Name вводим любое название книги, в поле URL, соответственно, адрес подключения к адресной книге. Выглядеть он будет примерно так:

http://example.com/card.php/addressbooks/kini/default/

где kini — имя пользователя, созданного нами ранее в Baikal.
Выставляем галочки в окне в соответствии со своими предпочтениями и нажимаем «ОК». Теперь щелкаем правой кнопкой мыши на созданную книгу и выбираем пункт Synchronize. В случае. если вы указали все верно, Thunderbird спросит логин и пароль пользователя, затем начнет синхронизацию. В противном случае, он просто промолчит :-) Пока что это единственная встреченная мной программа, которой все равно какой тип аутентификации вы выбрали в настройках Baikal.

TheBat!
Открываем меню Инструменты — Адресная книга. Или просто нажимаем клавишу F8. В открывшемся окне выбираем пункт меню Файл — Создать — Адресная книга. Задаем ей любое название, в поле «Эта адресная книга» выбираем вариант «Связана с сервером Carddav». Теперь у нас появляется возможность ввести данные для подключения. В поле адрес сервера вводим адрес нужной нам книги, который будет выглядеть так же, как и для Thunderbird. В два поля ниже вводим имя пользователя и пароль соответственно. При необходимости настраиваем периодичность синхронизации адресов. Все, нажимаем кнопку «ОК».
Для проверки работоспособности нажимаем правой кнопкой мыши на созданную нами книгу и выбираем пункт «Синхронизировать». Если все нормально, то в строке состояния мы увидим, что идет процесс синхронизации. В противном случае там ничего не будет. Возможно, что TheBat! будет снова и снова запрашивать логин и пароль пользователя. Это значит, что при установке Baikal, вы выбрали тип аутентификации Digest и вам нужно изменить его на Basic. В журнале веб-сервера при этом будет выдаваться сообщение об ошибке 401 «Not auth».

EssentialPIM
Тут тоже все очень просто. Открываем меню Файл — Синхронизация — Добавить синхронизацию — Carddav. В окне вводим адрес нужной книги, логин и пароль пользователя. Проверяем, что стоит галочка на пункте «Контакты» чуть ниже и нажимаем кнопку «Далее». В поле «Имя синхронизации» вводим любое, задаем с какой периодичностью она будет выполняться, ставим галочку «Синхронизировать сейчас» и жмем кнопку «Завершить».

С учетом того, что сервер порой не работает по непонятным пока что причинам, было принято решение перенести owfs на роутер. Он, конечно, и так достаточно загружен, но с отправкой данных один раз в 5 минут, думаю, справится. Для чего нужен owfs? Для считывания данных с датчика температуры и отправки данных на другие серверы типа narodmon.ru.
Поначалу роутер не видел USB-TTL адаптер, пришлось установить еще один дополнительный пакет. После его установки и перезагрузки роутера в списке устройств появился адаптер. Дальше было делом техники: установить owserver, переконфигурировать файл ownet.php на сервере, чтобы он забирал данные с роутера и выдавал их на сайт. Затем просто проследить, что все это работает.
К сожалению, далеко не в первый раз, оказалось, что сервер narodmon периодически перестает отвечать на отправку данных и, по истечении указанного времени, шлет сообщения о том, что мой сервер ничего не присылает. Просмотр журналов работы показывает, что в период, когда narodmon не «получает» от моего сервера данные, последний вполне успешно их отсылает, но narodmon не подтверждает их получение. В общем, мутная достаточно ситуация... В тоже время WeatherUnderground вполне успешно сигнализирует о получении данных, что позволяет сделать заключение о том, что проблемы на стороне narodmon. От чего они, впрочем, вполне ожидаемо, открещиваются.

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

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

Рассказ про пятисотмильную электронную почту
From **@.* Fri Nov 29 18:00:49 2002
Date: Sun, 24 Nov 2002 21:03:02 -0500 (EST)
From: Trey Harris
To: **-***@.*
Subject: The case of the 500-mile email (was RE: [SAGE] Favorite impossible
task?)

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

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

«У нас проблема с отправкой почты с кафедры»
Я: «В чем проблема?»

«Мы не можем послать электронную почту больше чем на 500 миль»

Я роняю чашку с кофе. «Повторите, пожалуйста?»

«Мы не можем отправить письмо адресатам, находящимся далее 500 миль отсюда», повторяет завкафедрой. «Точнее, 520. Но не дальше».

Я пытаюсь собраться с мыслями. Крыша начинает медленно меня покидать, но нельзя позволить крыше уйти в разговоре с завкафедрой. Даже завкафедрой статистики. «Хммм... Понимаете, принцип доставки электронной почты не зависит от расстояния. Почему Вы думаете, что не можете отправлять почту далее 500 миль?»

«Я не думаю, я знаю» — довольно жестким тоном заявляет завкафедрой.
«Когда мы впервые это заметили, несколько дней назад...»
«Вы ждали несколько ДНЕЙ?» — перебиваю я уже слегка дрожащим голосом — «и вы обходились без почты?»
«Нет. Мы могли отправлять письма, но...».
«Но не далее 500 миль, сэр? Но почему же Вы не позвонили раньше?»
«Ну, у нас не было достаточного количества данных до сегодняшнего дня».
Ну да. Кафедра статистики, как-никак. О Господи...
«Ну, так или иначе — я попросил наших геостатистиков разобраться...»

Так. Геостатистики.

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

«Я понял, сэр». Крыша-таки решила меня оставить. «Когда это началось? Вы сказали — несколько дней назад. Вы перенастраивали Ваши сервера в последнее время?»

«Да, приходили ребята от производителя, пропатчили сервер и перезагрузили его. Но я специально у них спросил — они говорят, что почты это никоим образом не коснулось».

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

Нууу... Для начала я залогинился на сервер их кафедры и отправил несколько пробных писем. Все это происходило в Северной Каролине, и все письма моментально вернулись ко мне в ящик. Ричмонд, Атланта, Вашингтон — сработало. Принстон (400 миль) — сработало.

Далее я попробовал послать письмо в Мемфис (600 миль). Отлуп.
Бостон, отлуп. Детройт, отлуп. Я открыл адресную книгу и начал пытаться сузить круги. Нью-Йорк (420 миль) — работает, Провиденс (580 миль) — отлуп.

У меня появились сомнения в собственной вменяемости. Я решил попробовать отправить письмо своему другу, живущему в Северной Каролине, но работающему с провайдером в Сиэттле.
Благодарю Тебя, Господи. Отлуп. Если бы оказалось, что прохождение писем зависит от того, где находится человек, их получающий — я бы сам, по собственной инициативе и с гордо поднятой головой пошел бы сдаваться санитарам.

Поняв, наконец, что завкафедрой не бредит, я решил посмотреть на sendmail.cf. Вполне нормальный sendmail.cf. Знакомый даже.

Я сравнил его diff’ом со стандартным sendmail.cf у меня на диске. Он не изменялся. Это был ровно тот же sendmail.cf, который я делал собственноручно.
Но опцию «FAIL_MAIL_OVER_500_MILES» я не включал, это точно.
Каюк. Ну что еще попробовать? telnet по 25-му порту на сервер этой гребаной кафедры.
Сервер радостно отвечает, как ему и положено — blah-blah-blah, я, говорит, SunOS.

Стоп-стоп-стоп... SunOS sendmail? Sun тогда поставлял со своей операционкой sendmail 5, хотя все нормальные люди уже работали с sendmail 8.
Поскольку я — все-таки неплохой администратор, почта у меня ходила под sendmail 8. Ну и опять-таки — поскольку я — человек, приученный к порядку, я переписал sendmail.cf с нормальными, понятными именами переменных и опций. Что с переменными и опциями делал sendmail 5, вы должны помнить.

Так-так-так... Картинка собиралась. Мне снова захотелось кофе.
Ребятки от Sun пропатчили операционку, но sendmail, в общем-то, тоже ее часть. Они удачно закрыли дыры, но sendmail снова стал 5, а не 8. Но в одном они были правы — sendmail.cf действительно никто не тронул. А какая разница, для восьмой версии он или для пятой?

Ну, короче говоря. Пятый (по крайней мере, в варианте Sun’а) — нормально отрабатывал sendmail.cf от восьмого. Рулсеты-то не изменились.
Но вот опции настройки, такие неприлично длинные — он считал чуть ли не комментариями. Клал на них. А откомпилирован он был без настроек по умолчанию.
И, как честный человек, не найдя чего-то в sendmail.cf, он устанавливал это в 0.

Одна из успешно установленных в ноль настроек — таймаут для соединения с удаленным SMTP — сервером. Поигравшись с этим сервером, я понял, что «ноль» по его мнению — это около трех миллисекунд.

Так. Ага...
Сетка наша уже в то время была на коммутаторах, и задержек практически не имела.
Задержки снаружи — это, в общем. Было понятно.

Ага. Скорость распространения электромагнитной волны.

ОООПС....
Умножаем время на скорость света, и получаем... и получаем...
558.84719

Пятьсот пятьдесят восемь миль.

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

Вчера в обед, пообщавшись с поддержкой, решил обновить сервер до последней версии операционной системы. Среди интересных для меня нововведений был Apache и openssl. Обновление много времени не заняло, после чего я уехал немного поиграть. Вернулся, позанимался каким-то делами и спокойно залег спать.
Утро принесло несколько не очень приятных известий. Во-первых, перестала работать почта, только сыпала сообщениями о том, что не может доставить сообщения. Во-вторых, сайт также перестал работать. Отправка показаний уличного термометра тоже не осуществлялась. Короче говоря, многие вещи перестали работать. С почтой разобрался достаточно быстро, заработала. Все остальное отложил на более позднее время.
С 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 минуты, будем надеяться, что это будет исправлено. Также есть возможность включить в запрос дополнительные параметры.

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