Установка и настройка knockd

Для чего нужен knockd? Для реализации метода port knocking — «стука» в фаервол для открытия определённых портов. Это обычное применение данной программы, но этим оно не ограничивается и можно придумать более экзотическое её использование.

Для начала установовим пакеты knockd и iptables-persistent. Последний нужен для постоянного хранения правил фаервола в случае перезагрузки сервера.

apt-get install knockd iptables-persistent

Минимальный набор правил для iptables при это будет выглядеть так:

iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X

iptables -P INPUT DROP

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

iptables -A INPUT -i eth0 -j DROP

В данном случае eth0 — это название сетевого интерфейса. На свежих системах название будет другое. Например enp3s0 или подобное. 😉

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

iptables-save > /etc/iptables/rules.v4

Теперь можно перейти непосредственно к настройке knockd. Для примера рассмотрим использование port knocking для открытия порта ssh сервиса.

Разрешим запуск knockd в режиме демон. Для этого отредактируем файл /etc/default/knockd и поменяем в нём строку на следующую:

START_KNOCKD=1

Если у вас, как и у меня, используется systemd, приведём файл /lib/systemd/system/knockd.service, который выглядит вот так:

[Unit]
Description=Port-Knock Daemon
After=network.target
Documentation=man:knockd(1)

[Service]
EnvironmentFile=-/etc/default/knockd
ExecStart=/usr/sbin/knockd $KNOCKD_OPTS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=mixed
SuccessExitStatus=0 2 15
ProtectSystem=full
CapabilityBoundingSet=CAP_NET_RAW CAP_NET_ADMIN

к следующему виду:

[Unit]
Description=Port-Knock Daemon
After=network.target
Requires=network.target
Documentation=man:knockd(1)

[Service]
EnvironmentFile=-/etc/default/knockd
ExecStartPre=/bin/sleep 1
ExecStart=/usr/sbin/knockd $KNOCKD_OPTS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=mixed
SuccessExitStatus=0 2 15
ProtectSystem=full
CapabilityBoundingSet=CAP_NET_RAW CAP_NET_ADMIN

[Install]
WantedBy=multi-user.target

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

systemctl daemon-reload

Теперь можно разрешить запускать knockd как сервис:

systemctl enable knockd.service

И осталось последнее — отредактировать конфигурационный файл knockd /etc/knockd.conf. Так он выглядит при установке:

[options]
        UseSyslog

[openSSH]
        sequence    = 7000,8000,9000
        seq_timeout = 5
        command     = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
        tcpflags    = syn

[closeSSH]
        sequence    = 9000,8000,7000
        seq_timeout = 5
        command     = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
        tcpflags    = syn

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

[options]
    UseSyslog
    Interface = eth0

[opencloseSSH]
    sequence      = 7000,8000,9000
    seq_timeout   = 10
    cmd_timeout   = 60
    tcpflags      = syn
    start_command = /sbin/iptables -I INPUT 3 -s %IP% -p tcp --dport 22 -j ACCEPT
    stop_command  = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT

В sequence можно указать любые свободные порты, которые вам нравятся. Через 60 секунд после выполнения команды, указанной в start_command, выполнится команда stop_command, которая уберёт правило, открывающее доступ к 22 порту.

Запустим knockd сервис:

systemctl start knockd.service

И проверим, что он работает корректно:

root@tests:~# systemctl status knockd.service 
● knockd.service - Port-Knock Daemon
     Loaded: loaded (/lib/systemd/system/knockd.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2023-02-04 08:41:19 MSK; 53s ago
       Docs: man:knockd(1)
    Process: 1762844 ExecStartPre=/bin/sleep 1 (code=exited, status=0/SUCCESS)
   Main PID: 1762845 (knockd)
      Tasks: 1 (limit: 9507)
     Memory: 768.0K
        CPU: 25ms
     CGroup: /system.slice/knockd.service
             └─1762845 /usr/sbin/knockd

Feb 04 08:41:18 tests systemd[1]: Starting Port-Knock Daemon...
Feb 04 08:41:19 tests systemd[1]: Started Port-Knock Daemon.
Feb 04 08:41:19 tests knockd[1762845]: starting up, listening on eth0

Теперь проверим, что сервис действительно работает. Для этого «постучим» на сервер снаружи:

knock  7000:tcp 8000:tcp 9008:tcp

На сервере в /var/log/syslog мы увидим следующее:

Feb  4 08:43:43 tests knockd: xx.xx.xx.xx: opencloseSSH: Stage 1
Feb  4 08:43:43 tests knockd: xx.xx.xx.xx: opencloseSSH: Stage 2
Feb  4 08:43:43 tests knockd: xx.xx.xx.xx: opencloseSSH: Stage 3
Feb  4 08:43:43 tests knockd: xx.xx.xx.xx: opencloseSSH: OPEN SESAME
Feb  4 08:43:43 tests knockd: opencloseSSH: running command: /sbin/iptables -I INPUT 3 -s xx.xx.xx.xx -p tcp --dport 22 -j ACCEPT

Это означает, что 22 порт открылся. Убедимся в этом, посмотрев список правил iptables:

iptables -nL
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
ACCEPT     tcp  --  xx.xx.xx.xx          0.0.0.0/0            tcp dpt:22
DROP       all  --  0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy DROP)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Продолжая наблюдать логи в /var/log/syslog, через 60 секунд мы увидим отработку команды stop_command, указанной в конфиге:

Feb  4 08:44:43 tests knockd: xx.xx.xx.xx: opencloseSSH: command timeout
Feb  4 08:44:43 tests knockd: opencloseSSH: running command: /sbin/iptables -D INPUT -s xx.xx.xx.xx -p tcp --dport 22 -j ACCEPT

Правило для открытия 22 порта удалилось. Проверям в iptables:

iptables -nL
Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
DROP       all  --  0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy DROP)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Так и есть. Всё работает отлично. 🙂

Теперь пару слов о том, как ещё можно использовать knockd. В start_command в /etc/knockd.conf можно необязательно указывать добавление/удаление правил iptables. Можно сделать, например, выключение сервера в экстренной ситуации, указав:

start_command = /sbin/shutdown -h now

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

Как настроить DKIM и SPF в Postfix

Краткая инструкция по настройке DKIM/SPF для домена example.com. Нужно это для того, чтобы снизить вероятность попадания в спам писем, отправляемых с вашего сервера.

Установим opendkim и mailutils

apt-get update
apt-get install opendkim opendkim-tools mailutils

Теперь перейдём непосредственно к настройке. Для настройки SPF необходимо создать TXT-запись следующего вида:

Хост        Указатель                    TTL
@           v=spf1 ip4:server_ip ~all    3600

server_ip — IP-адрес вашего почтового сервера, который отправляет письма.
~all означает, что письмо, которое не прошло проверку, будет отклонено.

Теперь настроим DKIM

mkdir /etc/postfix/dkim/

Создаём ключи ключи для домена example.com:

opendkim-genkey -D /etc/postfix/dkim/ -d example.com -s mail

После выполнения последней команды в каталоге /etc/postfix/dkim/ появится пара ключей — публичный и приватный для домена example.com:

Установим права на приватный ключ:

chmod 600 /etc/postfix/dkim/example.com.private

Поменяем владельца каталога:

chown -R opendkim /etc/postfix/dkim/

В опции в файле /etc/opendkim.conf необходимо внести следующие правки:

Syslog yes
Mode sv
KeyTable file:/etc/postfix/dkim/keytable
SigningTable file:/etc/postfix/dkim/signingtable

Mode sv — режим подписи и проверка подписей
KeyTable — список ключей
SigningTable — соответствие доменов и подписывающих их ключей

В файле /etc/postfix/dkim/keytable указываем данные о приватных ключах для доменов в формате имя_ключа домен:селектор:/путь/до/ключа

mail._domainkey.example.com example.com:mail:/etc/postfix/dkim/example.com.private

В файле /etc/postfix/dkim/signingtable указываются домены, которые необходимо подписывать в формате домен имя_ключа:

example.com mail._domainkey.example.com

В /etc/default/opendkim необходимо указать сокет, на котором будет opendkim. Другие настройки можно закомментировать:

SOCKET="inet:8891@localhost"

Добавляем в /etc/postfix/main.cf:

milter_default_action = accept
milter_protocol = 2
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891

Перезапускаем postfix и opendkim:

systemctl restart postfix
systemctl restart opendkim

Теперь осталось настроить DNS.

В панели управления доменом создаём TXT-запись следующего вида:

Запись                      Содержимое                               TTL
mail._domainkey             v=DKIM1; h=sha256; k=rsa; p=MII...QAB    3600

Содержимое строки p=MII…QAB берём из файла /etc/postfix/dkim/example.com.txt.

После обновления DNS, всё должно заработать.

Как проверить, что всё сделано правильно? Для проверки можно отправить тестовое сообщение на свой почтовый ящик с помощью утилиты mail:

"test message" | mail -aFrom:mail@example.com my_email@google.com

В заголовках полученного сообщения проверки SPF и DKIM должны выполниться успешно:

spf=pass
dkim=pass

Также проверить DKIM можно с помощью утилиты opendkim-testkey:

opendkim-testkey -d example.com -s mail -vvv -k /etc/opendkim/keys/mail.private

opendkim-testkey: using default configfile /etc/opendkim.conf
opendkim-testkey: checking key 'mail._domainkey.example.com'
opendkim-testkey: key not secure
opendkim-testkey: key OK

Таким образом мы получаем настроенный DKIM, что позволяет письмам доходить до получателя, а не сразу улетать в спам. 🙂

Исправляем ошибку с сертификатами для сайта Сбербанка

Краткая инструкция, как вернуть безопасный доступ к сайту Сбербанка.

Несколько дней назад заходя на сайт Сбербанка (нынче Сбер) пользователи сторонних браузеров столкнулись с проблемой небезопасного соединения в браузерах Chrome, Firefox и прочих. Произошло это по причине того, что теперь сертификат Сбербанка подписан российским удостоверяющим центром, а в перечисленных браузерах его корневого сертификата нет. Для решения проблемы можно использовать Яндекс.Браузер, а можно добавить сертификаты в свой браузер.

Например, я пользуюсь браузером Brave. Его и будем «приводить в чувства». 🙂

1. Заходим на сайт Госуслуг — https://www.gosuslugi.ru/crt. Прокручиваем страницу чуть ниже, находим кнопки «Скачать корневой сертификат» и «Скачать выпускающий сертификат«. Жмём их и получаем два файла:

russian_trusted_root_ca.cer
russian_trusted_sub_ca.cer

2. Заходим в настройки Brave: Setting -> Privacy and security. Выбираем Manage certificates, вкладку Authorities и импортируем скачанные сертификаты.

3. Вы великолепны! У вас снова работает безопасное соединение с сайтом Сбера.

По аналогии решается проблема в других браузерах. Всем удачи и безопасного серфинга в интернете. 🙂

Автозапуск упавшего сервиса в systemd

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

Рассмотрим в качестве примера древний сервис php5-fpm:

systemctl status php5-fpm.service
● php5-fpm.service - The PHP FastCGI Process Manager
   Loaded: loaded (/lib/systemd/system/php5-fpm.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2021-06-30 10:14:55 MSK; 12h ago
  Process: 9349 ExecStartPre=/usr/lib/php5/php5-fpm-checkconf (code=exited, status=0/SUCCESS)
 Main PID: 9354 (php5-fpm)
   Status: "Processes active: 0, idle: 5, Requests: 499, slow: 0, Traffic: 0req/sec"
    Tasks: 6 (limit: 4700)
   Memory: 857.9M
   CGroup: /system.slice/php5-fpm.service
           ├─ 9354 php-fpm: master process (/etc/php5/fpm/php-fpm.conf)
           ├─ 9357 php-fpm: pool web19
           ├─ 9358 php-fpm: pool web19
           ├─ 9359 php-fpm: pool www
           ├─ 9360 php-fpm: pool www
           └─20671 php-fpm: pool www

Открываем на редактирование файл /lib/systemd/system/php5-fpm.service и видим обычное содержимое:

[Unit]
Description=The PHP FastCGI Process Manager
After=network.target

[Service] 
Type=notify
PIDFile=/var/run/php5-fpm.pid
ExecStartPre=/usr/lib/php5/php5-fpm-checkconf
ExecStart=/usr/sbin/php5-fpm --nodaemonize --fpm-config /etc/php5/fpm/php-fpm.conf
ExecReload=/bin/kill -USR2 $MAINPID

[Install]
WantedBy=multi-user.target

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

StartLimitIntervalSec=500
StartLimitBurst=5

А в секцию Service добавить:

Restart=on-failure
RestartSec=5s

После добавления нужно заставить systemd перечитать конфиги:

systemctl daemon-reload

И теперь, если сервис вдруг остановится по незапланированным причинам, в течение 5 секунд он будет перезапущен. Попыток рестарта сервиса будет 5 в течение 500 секунд и если все эти попытки закончатся неудачей, дальнейших попыток перезапуска не будет. Этого времени должно хватить сисадмину, чтобы среагировать на проблему вручную. 🙂

a2dp-sink profile connect failed

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

Для начала пересобрал и обновил модуль. Ошибок стало меньше, но наушники всё так же не хотели подключаться, в логах была ошибка:

bluetoothd[xxxx]: src/service.c:btd_service_connect() a2dp-sink profile connect failed for XX:XX:XX:XX:XX:XX: Protocol not available

Проблема решилась добавлением в конфиг pulseaudio /etc/pulse/default.pa загрузки модуля module-bluez5-discover:

load-module module-bluez5-discover

Перезапускаем PulseAudio:

killall pulseaudio

Подключаем наушники, в логах не видим ошибок — всё прошло успешно. 🙂