Centos 8 minimal. ERROR Failed to set locale, defaulting to C

При настройке нового сервера на CentOS 8 в minimal пакете при установке пакетов возникала следующая ошибка Failed to set locale, defaulting to C.

Правильный вариант решения такой.

Создаем файл конфигурации для всех пользователей:

# vi /etc/profile.d/locale.sh

Пишем туда следующие значение и сохраняем файл

export LANG=en_US.UTF-8
export LANGUAGE=en_US.UTF-8
export LC_COLLATE=C
export LC_CTYPE=en_US.UTF-8

Загружаем настройки

# source /etc/profile.d/locale.sh
Готово! Кстати, многие советуют писать эти настройки в файл /etc/bashrc, но так делать нельзя, т.к. этот файл может с легкостью затереться при обновлении системы.

Centos 7. After update CentOS 7.7 with kernel 3.10.0-1062.1.1.el7.x86_64 the built in network card shows NO-CARRIER

После обновления ядра с 3.10.0-957 на 3.10.0-1062 сетевая карта REALTEK не поднялась.

Лечение:

lsmod reveals that module r8169 is loaded, but module realtek is not.

# rmmod r8169
# modprobe r8169
# systemctl restart network.service

fixes the problem temporarily, but this does not survive a reboot.

# echo realtek >/etc/modules-load.d/realtek.conf

fixes the problem and survives a reboot.

 

https://bugs.centos.org/view.php?id=16413

Linux Mint 19.2 – щелчки в динамиках

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

В новых ядрах включен режим powersaving. От этого и щелчки (просыпание). Проверить можно:

$ cat /sys/module/snd_hda_intel/parameters/power_save

если 1, то оно включено.

Чтобы отключить, отредактировать /etc/modprobe.d/alsa-base.conf добавив строку:

options snd_hda_intel power_save=0

и перезагрузка.

PhpMyAdmin ERROR: session_start(): open(/var/lib/php/session/sess_… Permission denied (13)

После обновления PhpMyAdmin вылезла ошибка:

session_start(): open(/var/lib/php/session/sess_... Permission denied (13)

Проверяем права:

# ls -l /var/lib/php
итого 56
drwxrwx--- 2 root apache 40960 Окт 26 15:48 session
drwxrwx--- 2 root apache 6 Окт 26 15:48 wsdlcache

Меняем на правильного владельца и группу:

# chown -R nginx:www-data /var/lib/php/

Проверяем.

openvpn – список валидных сертификатов

Список валидных и отозванных сертификатов можно посмотреть в файле ~/easy-rsa-master/easyrsa3/pki/index.txt. Начало строки оисания каждого сертификата начинается с букв V или R, что значит Valid и Revoked, например:

V 280722183908Z D288F79E74CB80BB55DB330A9CAF3B0B unknown /CN=server
V 280722184608Z 089261212A13CEA1449D5E4A824DCA0D unknown /CN=client
V 280722193955Z 3DA48E4D623DF211D094FDB3FF5FD3E7 unknown /CN=usetik
V 280725144641Z D63D26DBAFE1229315E3DA77FBA1296B unknown /CN=lenar
V 280807111448Z 9A5B2031B488A0A5D21805C90155A5A3 unknown /CN=segvm
V 290130071936Z F92191F47724966EC67ED7C145CF464B unknown /CN=seg-ron-note
V 290622112126Z D9D4006648168F2048EE8FDEC980759B unknown /CN=alina
V 290916124222Z A3D733DD4F70F2F193A5D93762151451 unknown /CN=vet

В моем случае все сертификаты валидные.

Пятитысячное хауту по OpenVPN


https://habr.com/ru/post/433250/
https://habr.com/ru/post/435802/

Apache: включаем OCSP и HSTS

OCSP

Включается глобально – нужно раскоментировать строки:

# ee /usr/local/etc/apache24/extra/httpd-ssl.conf

# Enable stapling for all SSL-enabled servers:
SSLUseStapling On
SSLStaplingCache "shmcb:/var/run/ssl_stapling(32768)"
SSLStaplingStandardCacheTimeout 3600

или для каждого виртуального хоста индивидуально в файле ./extra/httpd-vhosts.conf или в файлах ./Includes/:

<VirtualHost _default_:443>
 # General setup for the virtual host
 DocumentRoot "/usr/local/www/apache24/data"
 ServerName mail.domen.ua:443
 ServerAdmin postmaster@domen.ua
 ErrorLog "/var/log/httpd-error.log"
 TransferLog "/var/log/httpd-access.log"

 # SSL Engine Switch:
 # Enable/Disable SSL for this virtual host.
 SSLEngine on
 ...
 SSLUseStapling On
 SSLStaplingCache "shmcb:/var/run/ssl_stapling(32768)"
...
</VirtualHost>

Проверяем на сайтах www.ssllabs.com, www.digicert.com или в консоли:

% openssl s_client -connect mail.imp.kiev.ua:443 -tls1 -tlsextdebug -status 

OCSP response: 
======================================
OCSP Response Data:
     OCSP Response Status: successful (0x0)
     Response Type: Basic OCSP Response
     Version: 1 (0x0)
     Responder Id: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
     Produced At: Jul 22 22:37:00 2019 GMT
     Responses:
     Certificate ID:
       Hash Algorithm: sha1
       Issuer Name Hash: 7EED44DAAB3FCF8A220646C16A09AD71085D
       Issuer Key Hash: A84A6A63047DDDBAE6D139B7D44DAEFF3A8ECA1
       Serial Number: 03F102AA63047DDDBAE6DA7043D44DA589
     Cert Status: good
     This Update: Jul 22 22:00:00 2019 GMT
     Next Update: Jul 29 22:00:00 2019 GMT

HSTS

Добавляем строку в extra/httpd-vhosts.conf

<VirtualHost *:443>
 ...
 ## HSTS
 Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains;"
</VirtualHost>

При этом должна быть настроена переадресация с http на https:

# ee extra/httpd-vhosts.conf
<VirtualHost *:80>
 ServerName mail.domen.ua
 RewriteEngine On
 RewriteCond %{HTTPS} off
 RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>

Проверяем на сайте www.ssllabs.com.


nginx: включение OCSP и HSTS

Технология OCSP

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

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

С помощью OCSP (Online Certificate Status Protocol) веб-браузеры могут проверить достоверность SSL-сертификата. Реализуется это при помощи технологии OCSP Stapling (сшивание OCSP). В этом случае веб-сервер загружает копию ответа удостоверяющего центра, которая затем передается непосредственно в браузер.

Фактически, ответчики OCSP управляются удостоверяющим центром, недоступность которого для браузера приведёт к ошибке, если ответ не будет получен своевременно. Это уменьшает безопасность, позволяя атакующему наводнить запросами ответчик OCSP, чтобы отключить проверку.

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

Сервер посылает ответ OCSP из кэша только если клиент его запрашивает, сообщая в CLIENT HELLO о поддержке расширения TLS status_request.

Большинство серверов сохраняют в кэш OCSP-ответы на 48 часов. Через регулярные интервалы времени сервер будет подключаться к ответчику OCSP удостоверяющего центра, чтобы получить свежую запись OCSP. Расположение ответчика OCSP берётся из подписанного сертификата, из поля Authority Information Access – доступ к информации о подлинности.

Метод OCSP Stapling помогает быстро и безопасно установить достоверность SSL-сертификата. Последовательность проверки достоверности сертификата по технологии OCSP Stapling состоит из следующих шагов:

  • Шаг 1. Веб-сервер, на котором находится вебсайт, защищенный SSL, отправляет запрос удостоверяющему центру. В ответе от УЦ приходит статус сертификата, а также подписанный timestamp (временная метка). Подписание метки позволяет гарантировать то, что она не будет каким-либо образом изменена веб-сервером.
  • Шаг 2. Браузер посетителя подключается к серверу. В этот момент сервер привязывает временную метку, полученную от УЦ, к SSL-сертификату.
  • Шаг 3. Браузер проверяет временную метку. Она подписана поставщиком сертификата, а значит, ей можно доверять.
  • Шаг 4. Если SSL-сертификат является доверенным, то в таком случае браузер откроет страницу. В противном случае пользователь получит сообщение об ошибке.

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

Благодаря OCSP Stapling достигаются сразу несколько целей:

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

Требования

Необходим nginx версии не ниже 1.3.7. Также нужно создать исключение в пакетном фильтре, чтобы разрешить веб-серверу совершать исходящие подключения к вышестоящим серверам OCSP.

В настройки ssl.conf добавляем (докум. nginx):

## Включаем OCSP-ответы, тем самым уменьшая время загрузки страниц у пользователей
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;
ssl_trusted_certificate /etc/letsencrypt/live/tst-amo.net.ua/chain.pem;

OCSP Must-Staple для Let’s Encrypt / certbot

Если пользуетесь для HTTPS-сертификатов бесплатным Let’s Encrypt, то там ситуация будет ещё проще. Вы можете что вручную добавлять в строку запроса сертификата параметр --must-staple, например в cron:

certbot renew --quiet --must-staple --allow-subset-of-names

что добавить в файл cli.ini (или в конкретный conf-файл в каталоге /renewal) строчку:

must-staple = True

Разве что учитывайте, что файл cli.ini будет перекрывать собой настройки для конкретных сертификатов – т.е. если на одной системе у вас пачка доменов, и certbot регулярно пробегает и обновляет сертификаты, то заданное в cli.ini будет перекрывать всё остальное. С “айтишной” точки зрения это непривычно – общая настройка “для всей системы” перекрывает более специфичные частные. Однако тут логика чуть другая – файл cli.ini – это “то, что по умолчанию добавлять как будто бы админ это руками к каждому запросу дописывает”. Так что прописывайте OCSP Must-Staple в cli.ini только если это точно надо для всех сертификатов на данной системе, если же нет – то добавьте только в нужные.

Проверка OCSP из консоли:

# openssl s_client -connect tst-amo.net.ua:443 -tls1 -tlsextdebug -status

CONNECTED(00000003)
TLS server extension "renegotiation info" (id=65281), len=1
0001 - <SPACES/NULS>
TLS server extension "EC point formats" (id=11), len=4
0000 - 03 00 01 02 ....
TLS server extension "session ticket" (id=35), len=0
TLS server extension "status request" (id=5), len=0
TLS server extension "heartbeat" (id=15), len=1
0000 - 01 .
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = tst-amo.net.ua
verify return:1
OCSP response: 
======================================
OCSP Response Data:
    OCSP Response Status: successful (0x0)
    Response Type: Basic OCSP Response
    Version: 1 (0x0)
    Responder Id: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
    Produced At: Jul 21 09:37:00 2019 GMT
    Responses:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash: 7EE66AE7729AB3FCF8A220646C16A12D6071085D
      Issuer Key Hash: A84A6A63047DDDBAE6D139B7A64565EFF3A8ECA1
      Serial Number: 034CBD9A46BC406FA10ED89DDBB09119A6BF
Cert Status: good
This Update: Jul 21 09:00:00 2019 GMT
Next Update: Jul 28 09:00:00 2019 GMT
....

Если технология выключена или неработает, то будет вывод, типа:

OCSP response: no response sent

Для более полной проверки идем на ssllabs. Если включена поддержка OCSP то будет примерно такая картина:

OCSP stapling Yes

При первом тестировании может показать, что OCSP stapling No, это стандартное поведение nginx’а. При первом запросе nginx отвечает без ocsp_stapling и асинхронно пытается его получить. Если ему это удается, то в следующий раз он отдаёт ocsp response.

Включаем HSTS

Для рейтинга A+ нужно, что бы был включен HSTS, для этого добавляем в ssl.conf:

## On HSTS
add_header Strict-Transport-Security "max-age=15768000; includeSubDomains; preload";
Strict Transport Security (HSTS) Yes
max-age=15768000; includeSubDomains; preload

Проверяем используя curl:

# curl -s -D- https://tst-amo.net.ua | grep -i Strict
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Что такое HSTS?

HSTS (HTTP Strict Transport Security) — это механизм защиты от даунгрейд-атак на TLS, указывающий браузеру всегда использовать TLS для сайтов с соответствующими политиками. Стандарт описан в RFC6797, а политики бывают двух видов:

Динамические

Политика применяется из HTTP-заголовка Strict-Transport-Security при первом заходе на сайт по HTTPS, в нём указан срок действия и применимость к субдоменам:

Strict-Transport-Security: max-age=15768000; includeSubDomains;
Статические

Статические политики захардкожены в браузер и для некоторых сайтов включает привязку к вышестоящему CA, выпустевшему сертификат (например: google.com, paypal.com или torproject.org). Причем она может действовать только когда сайт открыт через TLS, разрешая незащищённое соединение, но блокируя MitM с подменой сертификата.

Список из Chromium используют все популярные браузеры (Firefox, Safari и IE 11+Edge) и добавить в него сайт может любой желающий, если веб-сервер отдаёт заголовок Strict-Transport-Security со сроком действия от двух лет и ключевым словом preload в конце:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Данный механизм преследует достаточно простую цель – сделать так, чтобы ресурс, доступный по HTTPS, был бы доступен исключительно по HTTPS, без возможности “сваливания” в обычный HTTP. Т.е. если у вас есть сайт вида https://www.atraining.ru/ , то предполагается, что всё взаимодействие клиента идёт только по HTTPS, даже если каким-то образом клиенту будет подсунута ссылка на http-версию (обычно в целях перехвата данных).

Реализуется это с двух сторон, сервером и клиентом. Сервер:

  • Добавляет в HTTP-ответ специальный заголовок Strict-Transport-Security, в котором говорит, что надо включить данный механизм.
  • Указывает в параметрах время, которое будет действовать данная директива (т.е. что-то вида “вот с текущего момента и ещё целый год, ты сюда ходи только по https, если увидишь ссылку на этот домен, но с http – поправь до отправки запроса”)

Клиент:

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

Звучит достаточно просто – но, по факту, данный механизм отсекает целую пачку потенциальных проблем вида “после установки HTTPS-сессии как-то удалось перейти обратно на HTTP”, например атаку SSL-stripping MItM (делается утилитой sslstrip), или кражу cookies через утилиту Firesheep.

Протестировать HSTS можно на сайте hstspreload, там же добавить себя в статический список.

Имейте в виду, что как только вы установите заголовок STS и отправите свой домен в список предварительной загрузки HSTS, его невозможно оттуда удалить. Это одностороннее решение сделать ваши домены доступными через HTTPS. Вы берёте на себя обязанность перед пользователями поддерживать HTTPS версию сайта, включая поддержку вашего доверенного сертификата.

Дополнительная защита сервера с помощью HTTP headers

Добавим строки в наш ssl.conf

# XSS Protection for Nginx web server
add_header X-Frame-Options SAMEORIGIN;
add_header X-XSS-Protection "1; mode=block";
add_header X-Content-Type-Options nosniff;
add_header X-Robots-Tag none;

X-Frame-Options в заголовке HTTP-ответа может использоваться для указания того, разрешено ли браузеру открывать страницу в фрейме или iframe.

Это предотвратит внесение содержимого сайта в другие сайты.

Вы пытались внедрить Google.com на свой сайт в качестве рамки? Вы не можете, потому что он защищен, и вы тоже можете защититься.

Для X-Frame-Options есть три параметра:
  1. SAMEORIGIN: позволяет загрузку контента в frame/iframe только если фрейм и страница, его загружающая, расположены на одном домене.
  2. DENY: этот параметр предотвратит отображение страницы в фрейме или iframe (например, Roundcube перестанет показывать содержимое писем).
  3. ALLOW-FROM URI: этот параметр позволяет отображать страницу только по указанному источнику.

X-XSS-Protection

Заголовок X-XSS-Protection может предотвратить некоторые XSS-атаки («межсайтовый скриптинг»), он совместим с IE 8+, Chrome, Opera, Safari и Android.

Google, Facebook, Github используют этот заголовок, и большинство консультантов по предупреждению проникновений порекомендуют Вам его использовать.

X-Content-Type-Options

Можно предотвратить атаки с использованием подмены MIME типов, добавив этот заголовок ответа HTTP. Заголовок содержит инструкции по определению типа файла и не допускает сниффинг контента. При конфигурации потребуется добавить только один параметр: “nosniff”.

X-Robots-Tag – управления индексированием и показом:

noindex         Не показывать эту страницу, а также ссылку “Сохраненная копия” в результатах поиска.
nofollow        Не выполнять переход по ссылкам на этой странице.
none               Аналогично метатегам noindex, nofollow.

Content-Security-Policy

Для RoundCube CSP имел такую запись:

add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-eval' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self'; frame-src 'self'; connect-src 'self'; frame-ancestors 'self'; base-uri 'self'; form-action 'self'";

Проверка X-HEADERS

http://vladimir-stupin.blogspot.com/2017/02/ocsp-nginx.html
https://www.atraining.ru/tls-armoring-windows-server/#hsts
https://forum.netgate.com/topic/129063/ocsp-must-staple-nginx-configuration
https://content-security-policy.com/

HSTS в Nginx или получаем оценку А+ от SSL Labs

https://habr.com/ru/post/320164/
https://certbot.eff.org/docs/using.html#where-are-my-certificates
https://www.howtoforge.com/tutorial/nginx-with-letsencrypt-ciphersuite/
https://serverfault.com/questions/874936/adding-hsts-to-nginx-config
Использование HTTP заголовков для предупреждения уязвимостей
https://developers.google.com/search/reference/robots_meta_tag?hl=ru

 

 

 

doveadm – утилита управления Dovecot-ом

Просмотр всех настроек Dovecot

# dovecot -a

Просмотр настроек отличных от дефолтных

# dovecot -n

Просмотр активных подключений

# doveadm who

Размещение LOG-файлов Dovecot

# doveadm log find

Просмотр последних 1000 ошибок и предупреждений с момента последнего запуска Dovecot

# doveadm log errors

Переоткрытие всех логов Dovecot(полезно выполнять после ручной ротации логов)

# doveadm log reopen

Тестирование аутентификации для пользователя(где rip-remote ip)

# doveadm auth test -x service=imap -x rip=10.10.1.4 user_name@example.com
# doveadm auth test -x service=pop3 -x rip=10.10.1.4 user_name@example.com
# doveadm auth test -x service=smtp -x rip=10.10.1.4 user_name@example.com

Выполнить писк passdb (без authentication) вместо поска userdb

# doveadm auth lookup user_name@example.com

Просмотр информации о пользователе

# doveadm user user_name@example.com

Поиск сообщений, которые совпадают под критерий поиска(для пользователя username@example.com в каталоге Корзина/Trash )

# doveadm search -u user_name@example.com mailbox Trash

Удаление таких сообщений(всех сообщений из каталога Trash)

# doveadm expunge -u user_name@example.com mailbox Trash all

Удаление писем с каталога Trash, которые были помещены туда более 2 недель назад

# doveadm expunge -u user_name@example.com mailbox Trash savedbefore 2w

Регулярная очистка скриптом по cron-у некоторых каталогов определенного пользователя, от писем которые были помещены туда более 2-х недель назад

$ cat doveadm_user_name_DIRS.sh
#!/bin/sh
/usr/local/bin/doveadm expunge -u name_user@example.com mailbox CRON savedbefore 2w
/usr/local/bin/doveadm expunge -u name_user@example.com mailbox VIRIS savedbefore 2w

В crontab добавляем запись:

11 1  * * * /home/user/bin/doveadm_user_name_DIRS.sh > /dev/null

Просмотр квоты пользователя

# doveadm quota get -u user_name@example.com

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

# for user in `mysql -Bse "select username from postfix.mailbox"`; do doveadm quota get -u $user; done

Альтернативно можно попробовать использовать команду

# doveadm quota get -A

Пересчет квоты пользователя

# doveadm quota recalc -u username@example.com

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

# for user in `mysql -Bse "select username from postfix.mailbox"`; do doveadm quota recalc -u $user; done

Альтернативно можно попробовать использовать команду

# doveadm quota recalc -A