Стандартный установщик Debian при установке на raid1-массив почему-то делает загрузочную запись только на первый носитель (обычно /dev/sda
). Если этот носитель через некоторое время сдохнет, то со второго система не загрузится. Для исправления этого бага после установки необходимо сделать что-то вроде grub-install /dev/sda
на второй носитель raid-массива.
Автор: unixmin
Уязвимость SSLv3 POODLE
В протоколе SSLv3 обнаружена уязвимость, поэтому все сервисы, завязанные на него следует переконфигурировать. А если точнее, отключить SSLv3 вообще. Ниже кратко как это делается.
nginx
В энжинксе явно разрешаем только хорошие протоколы
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
apache2
В апаче и ниже — запрещаем.
SSLProtocol all -SSLv3 -SSLv2
dovecot
ssl_protocols = !SSLv3 !SSLv2
postfix
smtpd_tls_mandatory_protocols=!SSLv2, !SSLv3
Тесты SSL уязвимости
Здесь можно проверить на уязвимость свои серверы, а здесь — браузер.
Другие параметры SSL можно проверить с помощью этого теста, кроме этого легко гуглится ещё много подобных сервисов.
Дополнительно
Естественно, все демоны после изменения конфигов релодятся или рестартятся.
PS: Разработчики nginx отключили SSLv3 в конфигах. На новых версиях этого делать уже не требуется.
Экономные дифференциальные бэкапы с hard links
Часто возникает задача делать backup больших объемов редко изменяющихся файлов. Обычно для этого используют замечательную утилиту rsync
, которая синхронизирует обновленные файлы, чем существенно экономит время бэкапа и сетевой траффик. Количество копий бэкапа, на которые происходит синхронизация, произвольно и чем оно больше — тем лучше. Естественное ограничение — свободное местом носителя. И здесь на помощь приходят две полезные опции рсинка:
--compare-dest=DIR also compare received files relative to DIR --link-dest=DIR hardlink to files in DIR when unchanged
Первая из них создает чисто дифференциальный бэкап сравнением с существующим, то есть помещает в новый бэкап только изменившиеся файлы. Вторая — создает полный бэкап, при этом не изменившиеся файлы с помощью hardlinks ссылаются на забэкапленные. В плане использования свободного места бэкапного сервера различия несущественны, но чисто дифференциальный для использования требует наличия директории сравнения. Основанный на hardlinks — можно сразу использовать «как есть», что намного удобнее. Поэтому, будем рассматривать вариант именно с жесткими ссылками.
Логика бэкапов сделаем наподобие logrotate. Новая директория добавляется с номером 0, при этом существующие сдвигаются на +1 вперед. Количество бэкапов ограничим: последняя директория будет удаляться. Получаем следующий скрипт:
#!/bin/sh servname="mailserv" backup_dir=/backup/$servname/vmail len=60 tmpname=--temp-- curr_dir="$backup_dir/$tmpname" zero_dir="$backup_dir/`printf "%02d" 0`" prev_dir="$backup_dir/`printf "%02d" 1`" last_dir="$backup_dir/`printf "%02d" $len`" date=`date` echo "Starting backup: $date." if [ -d "$zero_dir" ]; then echo "Rotating directories up to $len." # removing last directory if [ -d "$last_dir" ]; then rm -rf "$last_dir" fi # rotating for i in $(seq $len -1 0); do src="$backup_dir/`printf "%02d" $i`" if [ -d "$src" ]; then mv "$src" "$backup_dir/`printf "%02d" $(($i+1))`" fi done fi if [ -d "$curr_dir" ] ; then echo "Warning: \"$curr_dir\" already exists. Probably it was not renamed during last run. Resuming it." fi if [ -d "$prev_dir" ] ; then echo "Making hard-linked incremental backup." rsync -rtzKL --delete --stats --link-dest="$prev_dir" -v $servname:/var/vmail "$curr_dir" # rsync -rtzKL --delete --stats --compare-dest="$prev_dir" $servname:/var/vmail "$curr_dir" else echo "Making init backup." #rsync -rtzKL -e "ssh -i /home/bu/.ssh/id_dsa" --delete --stats $servname:/var/vmail "$curr_dir" rsync -rtzKL --delete --stats $servname:/var/vmail "$curr_dir" fi # moving temporary to latest mv "$curr_dir" "$zero_dir" echo "Backup finished: $date." echo "=================================" echo ""
В результате на файловой системе с поддержкой жестких ссылок можно разместить бэкапов размером на порядки больше, чем размер самого носителя. Например бэкап почтового сервера размером ~870 Gb состоящий из 30 копий занимает всего 970 Gb.
PS: Для систем с разделением прав доступа и разными пользователями такой бэкап желательно делать с опцией --numeric-ids
, которая сохранит (цифровые) owner:group
.
Безопасность
Бородатый анекдот:
Два геолога в тайге встречают медведя. Ружья нет. Один геолог бросается бежать, а второй кричит ему вслед:
— Бесполезно, ты всё равно не сможешь бежать быстрее медведя!
— А мне не нужно бежать быстрее медведя. Мне всего лишь достаточно бежать быстрее тебя!
В большинстве случаев этот подход оптимален и в компьютерной безопасности.
Быстрое удаление служб Windows
В Windows легко удалить службу с помощью командной строки. Для этого:
- Проверяем статус службы по имени с помощью команды
sc
:sc query UselessServiceName
Если не знаем точного имени сервиса, можно вывести список всех той же инструкцией без указания имени сервиса.
- Останавливаем службу, если она запущена:
sc stop UselessServiceName
- Удаляем службу окончательно:
sc delete UselessServiceName
PS: Часто полезно сделать бэкап (сохраниться) перед удалением службы. Для этого надо экспортировать ветку реестра
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\[имя_службы]
Правда, в этом случае легче удалить службу удалением соответствующей этой службе ветки реестра.
SSD на серверах
Сколько было сказано о бестолковости использования SSD на серверах, народ всё равно продолжает брать. Действительно полезен SSD лишь на очень узком круге круге задач, где требуется быстрый рандомный доступ к памяти на чтение. В остальных случаях прирост лучше обеспечивается или быстрыми RAID или увеличением RAM. Кому интересно почему последнее работает — гуглит Page Cache.
В качестве примера выше приведены графики использования памяти (день, неделя) на типичном веб-сервере. Фиолетовая часть и есть тот самый кеш, который снижает нагрузку на input-output. На недельном графике на 11 число приходится перезагрузка, после которой кеш в последующие дни медленно наполняется.
Основы безопасности сайта
В последнее время распространена проблема автоматизированного взлома сайтов на известных CMS. Целью взлома обычно является: рассылка с сайта спама и размещение ссылок на внешние ресурсы. Несмотря на то, что проблема обычна вызвана уязвимостями в самой CMS, она может быть решена в общем виде.
Для решения как минимум нужно обеспечить условия:
- Исполняемый код должен быть защищен от записи от пользователя веб-сервера. Наиболее очевидный вариант как это сделать: назначить ему
owner:group
другого пользователя, от которого и работать с кодом на запись, а веб-серверу оставить права только на чтение. - Запретить исполнение кода во всех директориях разрешенных на запись от веб-сервера (контент, кеш и подобные).
- Забыть про ftp и не сохранять пароли в файловых менеджерах. Взамен пользоваться scp/sftp, желательно с авторизацей по ключу.
- Для разных virtual hosts использовать разных системных пользователей, которые не читают данные друг друга.
Первый пункт из вышеприведенных гарантирует сохранность кода, даже в движке с дырами или бэкдором. Второй затрудняет исполнение залитых файлов: их можно исполнить с помощью include()
, но для этого в read-only коде должна быть такая возможность (которая по сути является бэкдором).
Кроме этого, желательно:
- Ограничить доступ в административные части сайта по IP-адресам на уровне веб-сервера только с рабочих компьютеров. Способ помогает даже при компрометации паролей, а также при человеческих конфликтах.
- Использовать SSL-соединения (с префиксом https://) для входа в административные части и везде, где используется пароль для входа. Это защитит от компрометации паролей и данных по каналам связи, например при работе по незащищённому вайфаю.
- Если точек входа на сайт небольшое количество, разрешить использовать только их, остальное запретить.
Системный администратор — самая неблагодарная профессия
Системный администратор, вероятно, самая неблагодарная профессия.
Когда всё работает: – Зачем мы платим ему деньги.
Когда ничего не работает: – За что мы платим ему деньги.
Проверка 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
(который заранее, естественно, установить надо). Также его можно указать вручную. Это похоже наилучшее решение.
Безопасность Skype
Так уж повелось, что я не доверяю Skype и некоторым новомодным браузерам: рассматриваю их как разновидность неопасных троянских коней. Может, конечно, они плохого ничего и не делают, но свои данные я им открывать не хочу. Для огораживания подобных подозрительных приложений отлично подходит runas от другого непривелигерованного пользователя. Например:
%windir%\system32\runas.exe /profile /user:another_user "C:\Program Files\Skype\Phone\Skype.exe"
После этого софт не имеет возможности прочитать данные пользователя. Windows уже давно имеет этот функционал, жаль что мало кто им пользуется. Тоже самое применимо к браузерам, особенно поделкам от поисковиков. И не только в качестве защиты от самого браузера, но также и запуска в нем чего-нибудь левого.
Юниксовый юмор
За что я в частности люблю юниксы-линуксы, так это за тонкий юмор в документации. Открываем man killall
и среди всякого практичного и полезного читаем
Be warned that typing killall name may not have the desired effect on
non-Linux systems, especially when done by a privileged user.
Это прекрасно!
Начнем
И посмотрим что получится.