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

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

Отмычка такая. Добавляем кастомный конфиг /etc/apt/apt.conf.d/99custom такого содержания:

Acquire::Check-Valid-Until "false";
Acquire::AllowInsecureRepositories "true";
Acquire::AllowDowngradeToInsecureRepositories "true";

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

Дебиановские установочные образы non-free firmware

Иногда возникает необходимость скачать несвежий устанвщик дебиана с версией несвободных пакетов. Свежий постоянно располагается по ссылке:
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/current/amd64/iso-cd/

А «несвежий» можно загрузить по ссылке из из архива:
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/archive/

Изменение PATH в Debian buster

В дистрибутиве Buster зачем-то подчистили переменную PATH от важных и полезных путей, в частности /usr/sbin. В итоге полезные и весьма нередко используемые команды вроде dpkg-reconfigure, fdisk, blkid и многие другие стали недоступны без указания точного пути. Интерпретатор пишет command not found и усё на этом.

Возвращаем к обратному добавлением в .bashrc:

export PATH=$PATH:/usr/sbin

После следующего логина всё работает

SSLError: [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol

В новом дебиане при попытке законнектиться к очень старым сайтам из питона (и не только) периодически вылезает ошибка «SSLError: [SSL: UNSUPPORTED_PROTOCOL] unsupported protocol». Вылезает она из-за отсутствия поддержки более-менее современных протоколов серверами с теми сайтами. Работать с этими сайтами надо, а повлиять никак, поэтому единственный доступный выход — это обойти ограничение. На глобальном уровне это делается правкой секции в /etc/ssl/openssl.cnf:

[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=1

на

[system_default_sect]
MinProtocol = None
CipherString = DEFAULT

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

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

Начиная примерно с дистрибутива buster стандартный установщик дебиана apt-get требует подписи всех используемых репозитариев. Обычный способ использования репозитария — добавление его подписи в систему. Это, однако, не всегда удобно и целесообразно. Иногда нужно что-то взять из сторонних репозитариев не добавляя подписи в систему. Это можно сделать разово при обновлении с помощью опции

apt-get update --allow-unauthenticated

Намного удобнее сделать это навсегда в отдельном списке репозитариев по типу:

deb [arch=amd64 allow-insecure=yes] http://www.deb-something-exampe.org buster main

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

UPD: Обновленный и более хороший способ

perl5 unescaped left brace deprecated

После частичного обновления дебиановского софта где-то между jessie и stretch при установке пакетов начинает возникать ошибка.

Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/^(.*?)(\\)?\${ <-- HERE ([^{}]+)}(.*)$/ at /usr/share/perl5/Debconf/Question.pm line 72.
Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\${ <-- HERE ([^}]+)}/ at /usr/share/perl5/Debconf/Config.pm line 30.

Она неопасна, однако, несколько достаёт. Исправляется обновлением debconf до последней версии используемого релиза:

apt-get update
apt-get install debconf

Резервирование UEFI в Linux

В большинстве случаев на серверные системы Linux ставится на RAID, железный или программный. В простом случае программный рейд создаётся при помощи mdadm, в форме зеркала. Корень и разделы системные и данных легко ставятся на получившиеся /dev/mdX-разделы и такое решение отлично защищает от потери данных в случае аппаратной неисправности жесткого диска. Однако, в стандартной установке загрузчик ставится только на один жёсткий диск и в случае его поломки система не загрузится. Поставим задачу зарезервировать ещё и загрузку, т.е. сделать систему загружаемой с любого из дисков зеркала.

Будем рассматривать наиболее простую конфигурацию и разбиение носителей — 2 NVMe-тома, на которых всего по 2 раздела: для UEFI и для корня системы. Например:

# fdisk /dev/nvme0n1
...
Device          Start       End   Sectors  Size Type
/dev/nvme0n1p1   2048    526335    524288  256M EFI System
/dev/nvme0n1p2 526336 879097934 878571599  419G Linux RAID

Имеем первый раздел для EFI и второй под корень системы. Корень уже в mdadm массиве уровня 1, с ним все уже в порядке. Второй такой же носитель /dev/nvme1n1 имеет в точности такую же разбивку.

После установки получим efi-раздел, монтируемый в /boot/efi и параметры загрузки EFI вроде

# efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0002,0006,0005
Boot0000* debian        HD(1,800,80000,0496eff8-477c-4335-ada1-ce9200ddff6e)File(\EFI\debian\grubx64.efi)
Boot0002* UEFI: Built-in EFI Shell      Vendor(5023b95c-db26-429b-a648-bd47664c8012,)..BO
Boot0005* UEFI: Intel(R) I350 Gigabit Network Connection        ACPI(a0341d0,0)PCI(3,3)PCI(0,0)MAC(MAC(0cc47ada7688,1)..BO
Boot0006* UEFI: IP4 Intel(R) I350 Gigabit Network Connection    ACPI(a0341d0,0)PCI(3,3)PCI(0,0)MAC(MAC(0cc47ada7688,1)..BO
Boot0007* UEFI: Intel(R) I350 Gigabit Network Connection        ACPI(a0341d0,0)PCI(3,3)PCI(0,1)MAC(MAC(0cc47ada7689,1)..BO
Boot0008* UEFI: IP4 Intel(R) I350 Gigabit Network Connection    ACPI(a0341d0,0)PCI(3,3)PCI(0,1)MAC(MAC(0cc47ada7689,1)..BO

Раздел /dev/nvme0n1p1 непустой и содержит загрузчик. Аналогичный раздел со второго носителя /dev/nvme1n1p1 пустой. Запишем загрузчик в него и добавим его в последовательность загрузки. В случае BIOS срабатывал штатный grub-install на второй диск. Здесь аналогичный способ перепишет строчку в последовательности загрузки efiboot выше и по сути переключит загрузку на второй диск. Поступим иначе, а именно наново сделаем загрузку на второй диск, её сохраним, и затем вернём загрузку с первого.

Для начала подменим уже смонтированный раздел /dev/nvme0n1p1 аналогичным со второго диска

umount /boot/efi
mount -o umask=0077 /dev/nvme1n1p1 /boot/efi

и убедимся, что смонтировался именно он. Если этот раздел не отформатирован при загрузке сделаем это сейчас

mkfs.vfat -F32 /dev/nvme1n1p1

FAT32 может не быть в системе изначально, он доустанавливается из dosfstools. Раздел должен быть пустым.

Далее стандартными средствами, по мануалу дебиана прописываем загрузчик:

apt-get install --reinstall grub-efi
grub-install /dev/nvme1n1
update-grub

В результате получаем загрузчик в /boot/efi (смонтированный на /dev/nvme1n1p1) и строчку в последовательности UEFI-загрузки

# efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0002,0006,0005
Boot0000* debian       HD(1,800,80000,37194fa6-dca2-491e-a0cf-a7fded36e2c5)File(\EFI\debian\grubx64.efi)
Boot0002* UEFI: Built-in EFI Shell      Vendor(5023b95c-db26-429b-a648-bd47664c8012,)..BO
Boot0005* UEFI: Intel(R) I350 Gigabit Network Connection        ACPI(a0341d0,0)PCI(3,3)PCI(0,0)MAC(MAC(0cc47ada7688,1)..BO
Boot0006* UEFI: IP4 Intel(R) I350 Gigabit Network Connection    ACPI(a0341d0,0)PCI(3,3)PCI(0,0)MAC(MAC(0cc47ada7688,1)..BO
Boot0007* UEFI: Intel(R) I350 Gigabit Network Connection        ACPI(a0341d0,0)PCI(3,3)PCI(0,1)MAC(MAC(0cc47ada7689,1)..BO
Boot0008* UEFI: IP4 Intel(R) I350 Gigabit Network Connection    ACPI(a0341d0,0)PCI(3,3)PCI(0,1)MAC(MAC(0cc47ada7689,1)..BO

Посмотрим таблицу идентификаторов UUID

# blkid
/dev/nvme0n1p1: UUID="AC77-0809" TYPE="vfat" PARTUUID="0496eff8-477c-4335-ada1-ce9200ddff6e"
/dev/nvme0n1p2: UUID="9643fce5-dcfb-1ff3-d03d-14004857da61" UUID_SUB="f5c3d323-29ec-3079-0e58-3259275e26db" LABEL="s00:0" TYPE="linux_raid_member" PARTUUID="d37e4df1-07ef-467e-acf8-ab98bbb60f87"
/dev/nvme1n1p1: UUID="4072-D808" TYPE="vfat" PARTUUID="37194fa6-dca2-491e-a0cf-a7fded36e2c5"
/dev/nvme1n1p2: UUID="9643fce5-dcfb-1ff3-d03d-14004857da61" UUID_SUB="f5e0f678-9b1d-3111-df00-74096ddf7e6d" LABEL="s00:0" TYPE="linux_raid_member" PARTUUID="660ba68e-7e25-4287-a646-3f555b510533"
/dev/md0: UUID="ce3f9f38-e7d9-4c89-ae36-2127a71670e0" TYPE="ext4"
/dev/nvme0n1: PTUUID="86a68d04-a4d9-4296-8a1a-48d02b7171fb" PTTYPE="gpt"
/dev/nvme1n1: PTUUID="1bc21b63-6011-42e9-80ab-1fd120b69907" PTTYPE="gpt"

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

efibootmgr -c -d /dev/nvme1n1 -p 1 -L "debian1" -l "\EFI\debian\grubx64.efi"

Проверяем результат

# efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0002,0006,0005
Boot0000* debian        HD(1,800,80000,37194fa6-dca2-491e-a0cf-a7fded36e2c5)File(\EFI\debian\grubx64.efi)
Boot0001* debian1       HD(1,800,80000,37194fa6-dca2-491e-a0cf-a7fded36e2c5)File(\EFI\debian\grubx64.efi)
Boot0002* UEFI: Built-in EFI Shell      Vendor(5023b95c-db26-429b-a648-bd47664c8012,)..BO
Boot0005* UEFI: Intel(R) I350 Gigabit Network Connection        ACPI(a0341d0,0)PCI(3,3)PCI(0,0)MAC(MAC(0cc47ada7688,1)..BO
Boot0006* UEFI: IP4 Intel(R) I350 Gigabit Network Connection    ACPI(a0341d0,0)PCI(3,3)PCI(0,0)MAC(MAC(0cc47ada7688,1)..BO
Boot0007* UEFI: Intel(R) I350 Gigabit Network Connection        ACPI(a0341d0,0)PCI(3,3)PCI(0,1)MAC(MAC(0cc47ada7689,1)..BO
Boot0008* UEFI: IP4 Intel(R) I350 Gigabit Network Connection    ACPI(a0341d0,0)PCI(3,3)PCI(0,1)MAC(MAC(0cc47ada7689,1)..BO

И меняем порядок загрузки на необходимый

# efibootmgr -o 0000,0001,0002

Вторая часть — это вернуть обратно первый загрузчик. Перемонтируем обратно раздел с ним на оригинальный с первого диска

umount /boot/efi
mount /boot/efi

Убеждаемся, что смонтировался именно он, и стандартными средствами записываем загрузчик

apt-get install --reinstall grub-efi
grub-install /dev/nvme1n1
update-grub

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

В любом способе в конечном варианте загрузки должны видеть примерно следующую последовательность UEFI

# efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0001,0002
Boot0000* debian        HD(1,800,80000,0496eff8-477c-4335-ada1-ce9200ddff6e)File(\EFI\debian\grubx64.efi)
Boot0001* debian1       HD(1,800,80000,37194fa6-dca2-491e-a0cf-a7fded36e2c5)File(\EFI\debian\grubx64.efi)
Boot0002* UEFI: Built-in EFI Shell      Vendor(5023b95c-db26-429b-a648-bd47664c8012,)..BO
Boot0005* UEFI: Intel(R) I350 Gigabit Network Connection        ACPI(a0341d0,0)PCI(3,3)PCI(0,0)MAC(MAC(0cc47ada7688,1)..BO
Boot0006* UEFI: IP4 Intel(R) I350 Gigabit Network Connection    ACPI(a0341d0,0)PCI(3,3)PCI(0,0)MAC(MAC(0cc47ada7688,1)..BO
Boot0007* UEFI: Intel(R) I350 Gigabit Network Connection        ACPI(a0341d0,0)PCI(3,3)PCI(0,1)MAC(MAC(0cc47ada7689,1)..BO
Boot0008* UEFI: IP4 Intel(R) I350 Gigabit Network Connection    ACPI(a0341d0,0)PCI(3,3)PCI(0,1)MAC(MAC(0cc47ada7689,1)..BO

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

Подключение bind9 к мониторингу munin

Для отладки да и просто для статистики полезно мониторить какие запросы идут к named-серверу, какие из них выполняются корректно и какие некорректные. Демон bind позволяет настроить гибкое логирование запросов, затем эти логи можно анализировать сторонней утилитой. В качестве такой утилиты удобно использовать систему мониторинга munin с bind-плагинами «из коробки».

Первое, что сделаем — включим нужные плагины. Их в директории с готовыми плагинами два, оба и подключим

cd /etc/munin/plugins
ln -s /usr/share/munin/plugins/bind9
ln -s /usr/share/munin/plugins/bind9_rndc

Эти плагины — перловские скрипты. Из их исходного текста можно увидеть, что первый из них (bind9) парсит стандартный лог неймсервера /var/log/bind9/query.log, второй (bind9_rndc) — парсит данные rndc из /var/run/named.stats и выдаёт расширенную статистику по запросам к DNS-серверу. В большинстве задач достаточно будет и общего плагина, однако, сконфигурируем их оба.

bind9

Конфигурируем параметры запуска скрипта мониторинга. Соответственно, общего плагина в файле /etc/plugin-conf.d/bind9:

[bind9]
user bind
env.logfile /var/log/named/query.log

Стандартная директория для логов bind /var/log/named, а мунин их читает из /var/log/bind9. Поэтому, явно указываем в конфиге путь к логу (как сделано выше). Как альтернатива, чтобы вносить меньше правок в конфигурацию, можно сделать симлинк:

cd /var/log
ln -s named bind9

Далее, настроим сбор логов от неймсервера в лог. Для этого создаем файл (например /etc/bind/logging.conf) с указанием данных, которые нужно писать в лог. Не будем мелочиться и настроим наиболее полное логирование, причем разных каналов в разные файлы.

logging {
	channel default_file {
		file "/var/log/named/default.log" versions 5 size 10m;
		severity dynamic;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel general_file {
		file "/var/log/named/general.log" versions 5 size 10m;
		severity dynamic;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel database_file {
		file "/var/log/named/database.log" versions 5 size 10m;
		severity dynamic;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel security_file {
		file "/var/log/named/security.log" versions 5 size 10m;
		severity dynamic;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel config_file {
		file "/var/log/named/config.log" versions 5 size 10m;
		severity dynamic;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel resolver_file {
		file "/var/log/named/resolver.log" versions 5 size 10m;
		severity dynamic;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel xfer-in_file {
		file "/var/log/named/xfer-in.log" versions 5 size 10m;
		severity dynamic;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel xfer-out_file {
		file "/var/log/named/xfer-out.log" versions 5 size 10m;
		severity dynamic;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel notify_file {
		file "/var/log/named/notify.log" versions 5 size 10m;
		severity dynamic;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel client_file {
		file "/var/log/named/client.log" versions 5 size 10m;
		severity dynamic;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel unmatched_file {
		file "/var/log/named/unmatched.log" versions 5 size 10m;
		severity dynamic;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel queries_file {
		file "/var/log/named/query.log" versions 5 size 10m;
		severity dynamic;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel network_file {
		file "/var/log/named/network.log" versions 5 size 10m;
		severity dynamic;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel update_file {
		file "/var/log/named/update.log" versions 5 size 10m;
		severity dynamic;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel dispatch_file {
		file "/var/log/named/dispatch.log" versions 5 size 10m;
		severity dynamic;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel dnssec_file {
		file "/var/log/named/dnssec.log" versions 5 size 10m;
		severity dynamic;
		print-category yes;
		print-severity yes;
		print-time yes;
	};
	channel lame-servers_file {
		file "/var/log/named/lame-servers.log" versions 5 size 10m;
		severity dynamic;
		print-category yes;
		print-severity yes;
		print-time yes;
	};

	category default { default_file; };
	category general { general_file; };
	category database { database_file; };
	category security { security_file; };
	category config { config_file; };
	category resolver { resolver_file; };
	category xfer-in { xfer-in_file; };
	category xfer-out { xfer-out_file; };
	category notify { notify_file; };
	category client { client_file; };
	category unmatched { unmatched_file; };
	category queries { queries_file; };
	category network { network_file; };
	category update { update_file; };
	category dispatch { dispatch_file; };
	category dnssec { dnssec_file; };
	category lame-servers { lame-servers_file; };
};

Для munin потребуется только лог запросов query.log, остальное — в отладочных целях и смело можно вычеркнуть.
Включаем этот файл в конфиге бинда

include "/etc/bind/logging.conf";

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

Далее, нужно убедиться, что лог читаем для парсера плагина, что делается штатной муниновской командой

munin-run bind9

В случае корректной настройки тест вернёт количество запросов разного типа. Или не вернёт — тогда нужно искать ошибку в конфигурации. Типичная ошибка происходит с правами доступа, поэтому или выставляем доступные права для /var/named/* или настраиваем запуск плагина от рута.

bind9_rndc

Включаем сам плагин для сбора статистики rndc в /etc/plugin-conf.d/bind9_rndc и настраиваем его параметры:

[bind9_rndc]
user bind
env.querystats /var/cache/bind/named.stats

Путь для файла статистики намеренно указан нестандартный, поскольку apparmor в дистрибутивах Debian/Ubuntu ограничивает запись в стандартную директорию /var/run/named. Поэтому указываем файл в директории для кеша, где нет явных ограничений на запись.

Теперь включим расширенную статистику rndc со стороны bind. Включаем в конфигурации (обычно /etc/bind9/named.conf.options) строчку:

statistics-file "/var/cache/bind/named.stats";

и рестартуем bind9.

Аналогично вышеуказанному плагину проверяем, что плагин работает корректно

munin-run bind9_rndc

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

/etc/init.d/munin-node restart

и проверяем, что логи корректно парсятся и в отчётах мунина присутствует статистика по DNS-запросам. В хорошем случае получаем картинки такого вида

Ошибка Munin INDIVIDUAL BUFFER POOL INFO

При обновлении MySQL от версии 5.6 его показатели не читаются мунином. В логах появляется ошибка:

Unknown section: INDIVIDUAL BUFFER POOL INFO at /etc/munin/plugins/mysql_innodb_rows line 1098.

Ошибка возникает в результате того, что мунин не распознает новую секцию (INDIVIDUAL BUFFER POOL INFO) в ответе СУБД. Наикратчайший (однако, не лучший) путь вылечить — отключить эту секцию. Для этого в скрипте, который парсит параметры БД /usr/share/munin/plugins/mysql_, находим немного перед 1098 строчкой определение секции

my %section_map = (

и добавляем в самом начале этой секции

'INDIVIDUAL BUFFER POOL INFO' => \&skip,

Проверить корректность запуска можно munin-run на любом из собирающих скриптов. Например:

cd /etc/munin/plugins
munin-run mysql_innodb_rows

Конфигурация пакетов через dialog

В минимальной установке дебиана конфигурация пакетов после установки происходит с помощью текстового интерфейса, что не всегда удобно. Перевод в «менюподобный» интерфейс (с использованием libncurses) происходит доустановкой пакета dialog:

apt-get install dialog

Оригинальные JDK и JRE в Debian

Есть ряд ПО под java, которое лучше работает на оригинальной оракловской жаве. Дебиан содержит открытый пакет openjdk, однако его недостаточно. А оригинальные оракловские бинарники Java отсутствуют в дебиановских репозитариях вследствие строгой лицензионной политики. Поставим вручную.

Корректный (через репозитарий) способ состоит в использовании установщика из репозитария. Но можно короче и чище сделать это вручную. Для этого качается нужный дистрибутив JDK (или Server JRE), поскольку оракл требует принятия их лицензии, то напрямую без куков скачать не получится. Поэтому качаем локально, заливаем на сервер. Устанавливать будем в

mkdir /opt/jdk
tar -zxf jdk-8u5-linux-x64.tar.gz -C /opt/jdk

Проверяем, что все распаковалось, а далее делаем симлинк на исполняемые файлы

update-alternatives --install /usr/bin/java java /opt/jdk/jdk1.8.0_66/bin/java 100
update-alternatives --install /usr/bin/javaс javaс /opt/jdk/jdk1.8.0_66/bin/javaс 100

Проверяем, что все поставилось корректно

update-alternatives --display java
update-alternatives --display javaс

Или альтернативный способ

java -version
javac -version

Done!

Из быстрых и чистых способов поставить жаву, это скорее всего самый короткий.

Минимум настроек apache2 и nginx веб-серверов для повышения безопасности

Рассмотрим типовую схему веб-сервера: nginx используется в качестве фронтэнда (front-end), apache2 — бэкэнда (back-end). Установка пакетов из репозитариев дает стандартную конфигурацию, которая применима для сервера разработки и тестирования. Однако, стоковая конфигурация изначально подстроена под большой класс задач и требует доработки. В частности, в плане безопасности. Опишем минимум настроек, которые необходимо сделать, если настраиваемый сервер выходит в интернет для широкого использования.

apache2

Отключаем потенциально опасные и просто неиспользуемые модули, а также неиспользуемые подконфиги. Почти всегда можно (и нужно) отключить:

  • модуль autoindex, позволяющий просматривать содержимое директории при отсутствии индексного файла,
  • обработку cgi-bin, которая в deb-based системах лежит в конфиге serve-cgi-bin.conf и используется очень редко,
  • Другие неиспользуемые модули (список которых зависит от выкладываемого кода). Т.е. необходимо перешерстить директории mods-enabled, conf-enabled

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

Apache/2.4.10 (Debian) Server at ...

Этот параметр, как и некоторые другие настройки безопасности в debian-системах обычно находится в конфиге /etc/apache2/conf-available/security.conf. Переключаем в менее информативную и, соответственно, более безопасную версию:

#ServerTokens Minimal
#ServerTokens OS
#ServerTokens Full
ServerTokens Prod

Аналогичным образом стоит поступить с подписью сервера на «ошибочных» страницах

ServerSignature Off
#ServerSignature On

и трассировкой

TraceEnable Off

Последняя обычно уже отключена, но в этом необходимо убедиться.

Код некоторых выкладываемых сайтов может содержать скрытые файлы, вроде .gitignore, .svn и других, раскрывающих стуктуру кода. Их желательно отключить здесь же, в апаче, или в фронт-энде. Можно отключить сразу все скрытые файлы:

<DirectoryMatch "/\.">
	Require all denied
</DirectoryMatch>

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

Некоторые из правил для бэкэнда закрывают те же места, что и в фронтэнде. Даже если каким-то образом будет поломана конфигурация nginx, уязвимость все равно не реализуется.

Отключим доступ к скрытым файлам — в секции виртуалхоста добавляем:

RedirectMatch 404 /\..*$

Такие файлы нередко встречаются в проектах. В частности, системы контроля версий вроде git, svn. Эта метаинформация не должна попадать в прошакш, тем не менее следует превентивно защититься от такой возможности.

Если VirtualHost на сервере не один, то также не плохо будет раскомментировать секцию


   AllowOverride None
   Order Deny,Allow
   Deny from all

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


	AllowOverride All
	Order Deny,Allow
	Allow from all

Я не описываю настройку прав доступа (пользователь:группа) на уровне ОС и файловой системы и использование модуля mpm_itk с директивой AssignUserID. Это тоже должно быть сделано для серверов, на которых такое разделение требуется.

nginx

Отключим отображение скрытых файлов:

location ~ /\. {
	deny all;
}

nginx используется как frontend, и если на нем отдается контент по https, то повышаем его безопасность. Для начала отключаем SSLv3 и другие небезопасные протоколы. Если nginx свежий, то в нем это уже и так отключено, поэтому лучше просто обновиться.
Генерируем параметры обмена ключами Diffie-Hellman (которые могут генерироваться достаточно долго, запаситесь временем)

openssl dhparam -out /etc/nginx/ssl/dhparam.pem 4096

и затем подключаем их в энжинксе

ssl_dhparam /etc/nginx/ssl/dhparam.pem;

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

ssl_ciphers 'AES256+EECDH:AES256+EDH:!aNULL';

Также имеет смысл включить кеширование

ssl_session_cache shared:SSL:10m;

После всех настроек желательно проверить их корректность в каком-нибудь сервисе, например, этом.

PHP

Как и в случае апача скрываем версию

expose_php = Off

В зависимости от задач можно отключить вывод ошибок:

error_reporting = 0
display_errors = Off

 

Проверки

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

HEAD example.com

Также побродим по сайту, в том числе по страницам, которые генерируют 4xx и 5xx ошибки, проверим, что версии софта не раскрываются и тем более не раскрывается внутренняя структура сервиса.

Завершающие замечания

Если на сервере хостится несколько сайтов, то многие из приведённых выше настроек повышают безопасность лишь частично. Сделать хорошую защиту между виртуалхостами на одной машине принципиально будет достаточно сложно. Если такое требуется — лучше смотреть в сторону виртуализации уровня операционной системы, по образцу OpenVZ или lxc.

Со временем пост будет пополняться.

Настройка DKIM в exim4

Заставить exim4 подписывать исходящую почту совсем просто. Для этого в конфиг экзима /etc/exim4/exim4.conf.template дополняем следующими строками

#########################
## DKIM SETTINGS

DKIM_DOMAIN = ${lc:${domain:$h_from:}}
DKIM_FILE = /etc/mail/${lc:${domain:$h_from:}}.key
DKIM_PRIVATE_KEY = ${if exists{DKIM_FILE}{DKIM_FILE}{0}}
DKIM_SELECTOR = m01

## DKIM SETTINGS END
########################

По вкусу можно поместить конфигурацию не в шаблон, а в какой-нибудь из conf.d-файлов. Далее, чтобы все работало как надо:

  • Создаем пару ключей с помощью openssl,
  • Прописываем открытый ключ в DNS,
  • Закрытый ключ помещаем в /etc/mail/domain_name.key (вместо domain_name имя домена) и меняем его права и владельца на 0640 и root:Debian-exim,
  • Перезагружаем exim4, отправляем тестовое письмо на адрес с включенной верификацией DKIM-подписи и убеждаемся, что все работает правильно.

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

DKIM_SELECTOR = ${extract{-1}{.}{DKIM_PRIVATE_KEY}}

Кроме настройки DKIM в exim полезно настроить обрезание определённых нежелательных заголовков в целях безопасности. Такими, например, могут быть имена формирующих письмо скриптов или IP-адреса отправителей письма (при отправке по SMTP с другой машины, которая может стоять во внутренней сети), которые раскрывают внутреннюю структуру системы. Для этого в тот же шаблон /etc/exim4/exim4.conf.template рядом с DKIM добавляем фильтр по заголовкам

system_filter = /etc/exim4/filter

Содержимое файла конфигурации фильтра /etc/exim4/filter может быть, например, таким

headers remove X-PHP-Originating-Script
headers remove Received

В конце обязательно релодим экзим и проверяем, что все работает корректно. Проверить почту можно прямо из шелла:

$ echo "This will go into the body of the mail." | mail -s "Hello world" -a "From: me@mydomain.com" myemail@example.com

PS: вышеприведенная конфигурация — Debian-based дистрибутивов. Для RedHat и других файлы конфигов могут быть немного другими.

Настройка виртуализации Windows под KVM libvirt linux

Система будет тестовая и стабильность на ней не нужна, поэтому настраивать это все будем в дистрибутиве Debian jessie, который на данный момент является веткой testing.
Оригинальные и краткие руководства к действию можно найти на дебиане: KVM и QEMU. Ниже несколько подогнанная под мои задачи выжимка.

Шаблон

Если потребуется создавать много виртуальных машин или менять их параметры, очень удобно создать шаблон конфигурации виртуальных машин и скрипт её создания. Можно, конечно создавать командами вроде

virt-install --connect qemu:///system \
--name vm1 \
--ram 1024 \
--vcpus=1 \
--disk pool=storage,cache=none,size=40, format= qcow2\
--disk /vm/Win7.iso,device=cdrom \
--bridge=br0,model=e1000 \
--os-type=windows
--graphics vnc,port=5911,listen=0.0.0.0

но делать это постоянно очень неудобно. В качестве шаблона создаем конфиг вроде

<domain type='kvm'>
  <name>{name}</name>
  <memory>{ram}</memory>
  <currentMemory>{ram}</currentMemory>
  <vcpu>1</vcpu>
  <os>
    <type arch='x86_64' machine='pc-0.12'>hvm</type>
    <boot dev='cdrom'/>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <clock offset='localtime'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/bin/kvm</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='none'/>
      <source file='/vm/{name}.img'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='none'/>
      <source file='/vm/virtio.img'/>
      <target dev='hda' bus='ide'/>
      <address type='drive' controller='0' bus='0' unit='0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/vm/iso/ru_windows_8.1_professional_vl_with_update_x64_dvd_4050520.iso'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
      <address type='drive' controller='0' bus='1' unit='0'/>
    </disk>
    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <source file='/vm/virtio-win-0.1-30.iso'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
      <address type='drive' controller='0' bus='1' unit='1'/>
    </disk>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <interface type='bridge'>
      <mac address='52:54:00:9d:be:d9'/>
      <source bridge='br0'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <input type='tablet' bus='usb'/>
    <input type='mouse' bus='ps2'/>
    <graphics type='vnc' port='{port}' autoport='no' listen='0.0.0.0' keymap='en-us' passwd='{passwd}'/>
    <video>
      <model type='vga' vram='9216' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </memballoon>
  </devices>
</domain>

Типовые шаблоны можно найти в документации, идущей вместе с пакетами. Также создаём устанавливающий скрипт vmcreate.sh:

#!/bin/sh

template=template.xml
path=/vm

while true; do
	read -p "VM name: " name
	if [ "$name" ]; then
		break
	fi
done


while true; do
	read -p "VNC port: " port
	case $port in
		[0-9]* ) break;;
	esac
done

while true; do
	read -p "VNC password: " password
	if [ "$password" ]; then
		break
	fi
done

while true; do
	read -p "HDD size in Gb [50]: " hdd
	case $hdd in
		[0-9]* ) break;;
		* )	hdd=50
			break;;
	esac
done

while true; do
	read -p "RAM in Mb [1536]: " ram
	case $ram in
		[0-9]* ) break;;
		* )	ram=1536
			break;;
	esac
done


echo "VM name: $name"
echo "VNC port: $port"
echo "Password: $password"
echo "HDD : $hdd Gb"
echo "RAM : $ram Mb"

while true; do
	read -p "Continue [y/N]? " yn
	case $yn in
		[Yy]* ) cont=1
			break;;
		* ) cont=0
			break;;
	esac
done

ramb=$((1024*$ram))

if [ -f "$path/$name.img" ]; then
#	cont=0
	echo "File $path/$name.img exist."
else
	qemu-img create -f raw "$path/$name.img" ${hdd}G
fi


if [ "$cont" -eq 1 ]; then
	sed "s/{name}/$name/g" $path/$template | sed "s/{port}/$port/g" | sed "s/{passwd}/$password/g" | sed "s/{hdd}/$hdd/g" | sed "s/{ram}/$ramb/g" > $path/$name.orig.xml
#	virsh create $name.orig.xml
	virsh define $name.orig.xml
	virsh start $name
else
	echo "Aborted."
fi

После такой подготовки виртуальная машина создается фактически запуском этого скрипта и ответом на вопросы. Конечную конфигурацию можно всегда поправить в XML-конфигах /etc/libvirt/qemu или с помощью утилиты virsh.

Типовая установка Windows в виртуалке

Драйвер от Win7 x64 вполне годится и для Windows 8.1, выбираем его при установке(Red Hat VirtIO SCSI controller, VIOSTOR.INF VirtIO Balloon Driver BALLOON.INF). Там же находим драйвер для сетевой карты, он пригодится позже. После этого виртуальный HDD находится системой, запускаем установку.
Уже на установленной системе ставим VirtIO-драйвер для Ethernet от Red Hat и настраиваем параметры сети.

Сеть

Для работы сети потребуется некоторая маршрутизация на самом хосте. Ниже представлен не самый оптимальный, но рабочий вариант для большинства (не-production) применений. А именно, разрешим forwarding на основной машине и явно пропишем пути из NAT-сети в интернет.
/etc/network/interfaces

up route add -host 10.0.5.2 dev br0

Также в местном фаерволле, т.е. скрипте, который настраивает iptables-правила, добавляем локальную сеть и нужные перенаправления:

IPTABLES=/sbin/iptables

echo 1 > /proc/sys/net/ipv4/ip_forward 2> /dev/null

ip addr add 10.0.6.1./24 dev br0
$IPTABLES -F -t nat
$IPTABLES -X -t nat

LAN="10.0.5.0/24"

$IPTABLES -A INPUT -s $LAN -j ACCEPT
$IPTABLES -A OUTPUT -s $LAN -j ACCEPT

$IPTABLES -t nat -A POSTROUTING -s $LAN -o br0 -j MASQUERADE

$IPTABLES -t nat -A PREROUTING -p tcp --dport 55003 -j DNAT --to-destination 10.0.5.3:3389

Управление с помощью утилиты virsh

Утилитой virsh совершаются штатно многие операции с вируалками. Наиболее часто используются старт, мягкая и жёсткая остановка

virsh start VMNAME
virsh shutdown VMNAME
virsh destroy VMNAME

Удалить существующую виртуальную машину (совсем!) также можно этой утилитой:

virsh undefine VMNAME

Как правило, виртуальная машина ставится надолго, поэтому её целесообразно стартовать при загрузке самой машины:

virsh autostart VMNAME

Завершающие дополнения

Конфиги виртуальных машин находятся в /etc/libvirt/qemu и могут быть исправлены до нужного состояния. В нём можно поменять физические параметры контейнера (объем ОЗУ, количество ядер и т.п.), также подключить/отключить образы жёстких дисков и CD/DVD.

На *nix-системах время обычно хранится в UTC, тогда как Windows его хранит в локальном часовом поясе. Проблему решает reg-файл следующего содержания:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
"RealTimeIsUniversal"=dword:00000001

LXC контейнеры в Debian jessie

LXC представляет собой набор утилит для управления виртуализацией на уровне операционной системы. Технология основана на механизме cgroups, которая позволяет создавать несколько Linux-окружений с собственным пространством процессов и сетевым стеком. Все контейнеры работают на одном ядре вместе с основной машиной, что делает виртуализацию этого типа очень эффективной. По этой причине виртуализация такого типа — отличный выбор для различных применений, где не требуется устанавливать дополнительные модули к ядру и подобная специфика.

Почти всю полезную информацию можно найти в дебиановском источнике. Ниже — наиболее короткий howto, как быстро настроить lxc-виртуализацию под Debian Linux.

Настройка хост-машины

Начинаем как обычно с установки необходимого софта

apt-get install lxc bridge-utils libvirt-bin debootstrap

Контейнеры будем создавать в стандартной директории /var/lib/lxc. Для удобства сделаем симлинк в корне файловой системы на эту директорию:

ln -s /var/lib/lxc

Настроим сеть. Для этого доустанавливается пакет bridge-utils, типовой конфиг сети (/etc/network/interfaces) будет следующим

auto lo
iface lo inet loopback

auto br0
iface br0 inet static
	address 123.123.123.3
	netmask 255.255.255.248
	gateway 123.123.123.1
	bridge_ports eth0
	bridge_fd 0
	bridge_maxwait 0
	bridge_stp off
	dns-nameservers 8.8.8.8 8.8.4.4

Проверяем, всё ли в порядке с установкой

lxc-checkconfig

и если все нормально, то ставим туда первый контейнер

lxc-create -n myvm -t debian

В результате получаем виртуальную машину и root-пароль к ней. Контейнер будет из stable-дистрибутива (Wheezy), однако его можно дообновить до testing или изначально ставить testing.

Настройка виртуальной машины

Конфиг виртуальной машины находится в /lxc/myvm/config. Доводим его до вменяемого состояния, например такого

lxc.network.type = veth
lxc.rootfs = /var/lib/lxc/myvm/rootfs

# Common configuration
lxc.include = /usr/share/lxc/config/debian.common.conf

# Container specific configuration
lxc.mount = /var/lib/lxc/myvm/fstab
lxc.utsname = myvm
lxc.arch = amd64


lxc.network.flags = up
lxc.network.link = br0

lxc.network.hwaddr = 00:25:90:01:5e:22

lxc.start.auto = 1

Последний параметр отвечает за автозагрузку при запуске основной машины.

Перед запуском виртуалки также меняем сетевые настройки в /etc/network/interfaces.

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

apt-get install apt-utils iputils-ping cron rsyslog iptables

Иногда будем получать ругань вроде

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LC_CTYPE = "ru_RU.UTF-8",
        LC_COLLATE = "ru_RU.UTF-8",
        LC_MESSAGES = "C",
        LC_NUMERIC = "POSIX",
        LANG = (unset)
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

Поэтому сразу конфигурируем локаль

dpkg-reconfigure locales

Стандартного почтового агента (MTA) в системе тоже нет, поэтому ставим его и настраиваем:

apt-get install exim4
dpkg-reconfigure exim4-config

Полезные команды для управления

Запустить и погасить виртуальную машину используются

lxc-start -n myvm -d
lxc-stop -n myvm

Параметр -d в случае старта означает запуск в режиме демона. Если его не указать, то getty захватит текущую консоль (что бывает полезно, если не удаётся подключиться по SSH).

Получить краткую информацию о статусе машины можно с помощью

lxc-info -n myvm

Заключение

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

PS

Статья устарела. Более качественный способ приведён в дебиановском мануале. И, что важно, постоянно обновляется.

Debian hostname

Правильно настроенный хост должен возвращать следующие имена hostname:

  • короткое имя по hostname
  • FQDN по hostname -f
  • доменное имя по hostname -d

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

Иногда на принимаемых серверах hostname настроен некорректно. Правится ситуация несложным образом:

  • Проверяем, что в /etc/hostname прописано короткое имя. Если нет, то прописываем.
  • Проверяем, что в /etc/hosts первым доменом на ip-адрес сервера прописан FQDN и если нет, то прописываем.
    1.2.3.4 somehost.prod.example.com somehost somehost.prod
    

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

Дополнение:
Неправильный hosts, а точнее не-FQDN на первом месте после ip-адреса сервера приводит к ошибке apache2:

AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using XXX.XXX.XXX.XXX. Set the 'ServerName' directive globally to suppress this message                                                                                                 

Установка sphinx-плагина для memcached в Debian

Многие плагины к сфинксу в дебиане можно найти и подключить с помощью

munin-node-configure --suggest
munin-node-configure --shell

Однако, есть много стоковых плагинов в /urs/share/munin/plugins/, которые не предлагаются и не включаются таким способом. В частности, плагин к memcached подключается вручную. Ставится он коротко следующим образом.

Плагин требует перловскую библиотеку Cache::Memcached, если её нет в системе — ставим:

apt-get install libcache-memcached-perl

Далее вручную идем в директорию с конфигами и подключаем плагин:

cd /etc/munin/plugins
ln -s /usr/share/munin/plugins/memcached_ memcached_rates
ln -s /usr/share/munin/plugins/memcached_ memcached_bytes
ln -s /usr/share/munin/plugins/memcached_ memcached_counters

Что означают все показатели и как работает плагин можно посмотреть в самом perl-скрипте /usr/share/munin/plugins/memcached_.

Далее запускаем получившиеся симлинки и проверяем, что плагин работает. По окончании рестартуем munin-node:

locale failed in Debian

При установке в свежей ОС Debian новых пакетов обычно возникает ошибка вроде

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = «en_US:en»,
LC_ALL = (unset),
LC_CTYPE = «ru_RU.UTF-8»,
LANG = «en_US.UTF-8»
are supported and installed on your system.
perl: warning: Falling back to the standard locale («C»).

Для исправления нужно подключить локали, хватает русской и английской utf-8. Для этого:

dpkg-reconfigure locales

И там выбираем соответствующие en_US.UTF-8 и ru_RU.UTF-8.

grub-install на raid1-массивы

Стандартный установщик Debian при установке на raid1-массив почему-то делает загрузочную запись только на первый носитель (обычно /dev/sda). Если этот носитель через некоторое время сдохнет, то со второго система не загрузится. Для исправления этого бага после установки необходимо сделать что-то вроде grub-install /dev/sda на второй носитель raid-массива.

Проверка rar в amavis на почтовом сервере

Оказывается, стандартный unrar-free не распаковывает многоуровневые вложенные rar-архивы. Для того, чтобы такие архивы распаковывались и их содержимое проверялось необходимо включить «несвободную» unrar-библиотеку. Если конкретно, то изменить в конфиге amavis стоковую конфигурацию (которая находится в /etc/amavis/conf.d/01-debian:

#$unrar = ['rar', 'unrar']; #disabled (non-free, no security support)
$unrar = ['unrar-free'];

на свою:

$unrar = ['rar', 'unrar']; #disabled (non-free, no security support)
#$unrar = ['unrar-free'];

После этого амавис корректно открывает rar-архивы и можно запрещать неугодные разрешения файлов.

UPDATE:
Если закомментировать обе строки, то будет использоваться архиватор 7zip (который заранее, естественно, установить надо). Также его можно указать вручную. Это похоже наилучшее решение.