Береги себя: защищаемся от западлостроений

В прошлом номере мы говорили о шутках, западлостроениях и всем том, что можно сделать с UNIX-системой в отсутствие владельца машины (или подсунув ему наш зловредный код). Все это, конечно, интересно и необычайно эффективно, вот только совершая западлостроение против другого, надо думать и о себе. Рано или поздно месть придет, и к ней надо быть готовым.

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

Защита рубежей

Западлостроения в офисе, учебном заведении и любом людном месте наиболее распространены и эффективны. Машины постоянно остаются без присмотра и любой, хоть чуточку подкованный в техническом плане, человек может делать с брошенными системами все, что угодно. Ты уходишь за кофе, возвращаешься и видишь вместо привычного черного окна xterm нечто раскрашенное в гламурно-розовый цвет с кадром из какого-то ситкома в качестве бэкграунда. Страшного ничего нет, зато ЛОР на ближайшие 10 минут остался без тебя.
К счастью, защититься от физического доступа очень просто. Для этого надо привыкнуть блокировать экран на время своего отсутствия (и можно спокойно бродить где угодно). Способов сделать это уйма, начиная от выбора пункта меню Lock Screen в любой среде и заканчивая клавиатурными комбинациями: <Ctrl+Alt+L> (KDE и Gnome) и <Ctrl+Alt+Del> (Xfce). То же самое можно сделать и из командной строки: KDE $ qdbus org.freedesktop.

ScreenSaver /ScreenSaver Lock
Gnome $ gnome-screensaver-command -l
Xfce $ xflock

Для остальных случаев можно использовать команду:

$ xscreensaver-command -lock

Или установить программку xlock, если xscreensaver не активирован. Консольный аналог называется vlock. Популярные текстовые оконные менеджеры, такие как GNU Screen и Tmux, также позволяют лочить терминал.

Блокировка экрана не принесет большой выгоды, если в BIOS активирована возможность загрузки с CD (всегда найдутся перцы, которые вставят Linux LiveCD в привод и нажмут кнопку Reset). Поэтому загрузку с любых носителей, кроме жесткого диска, придется запретить через CMOS Setup и поставить на него пароль. Для пущей надежности обнули файл /etc/securetty, хранящий списки всех терминалов, с которых возможен вход под учетной записью root.

Если же враг все-таки ухитрился войти в систему, украв пароль или же каким-то другим способом, то его деятельность легко отследить с помощью вызова команды «last», которая покажет все, гхм, акты проникновения, а также чтения файлов истории (~/.history, ~/.bash_history) и логов.

Инсайдеры

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

1. Не запускай команды, действие которых ты полностью не понимаешь. Различные зловредные команды UNIX-шелла могут быть ловко замаскированы в sh/perl/python/ruby-скрипт, запустив который ты можешь остаться без системы.

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

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

4. Никогда не устанавливай пакеты вручную, путем скачивания с сайта и исполнения команды rpm/deb/что-то еще. Любой нормальный дистрибутив имеет удаленный репозиторий, для доступа к которому используются ключи, а все пакеты имеют проверочный хэш-код. В крайнем случае, скачивай пакеты с сайтов, идентифицирующих себя с помощью сертификатов.

5. Всегда распаковывай архивы во временный подкаталог своего домашнего каталога и не ленись проверять их содержимое перед распаковкой. Архив может быть tar-бомбой, подменяющей файлы твоего домашнего каталога, или содержать decompression-бомбу, которая после распаковки превратится в огромный файл, и если он попадет, например, в /tmp, то работоспособность системы будет нарушена.

6. Создай файл с именем «-i» в корневом каталоге (touch /-i). Это заставит команду «rm -rf /*» спрашивать пользователя перед удалением каждого файла корневого каталога (rm примет файл «-i» за флаг командной строки).

Враг внутри

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

Любая UNIX-система позволяет накладывать самые разнообразные ограничения на процессы пользователей. Это может быть максимальное количество открытых файлов, максимальное количество процессов, приоритет процессов и т.д. Также существуют дисковые квоты, предназначенные для ограничения занимаемого файлами пользователя пространства на диске. Правильная установка ограничений позволит запереть зловредные процессы в коробку, границы которой они не смогут нарушить, а следовательно, и навредить системе. Ограничения особенно эффективны против различных форк-бомб, плодящих бесконечное количество процессов и сжирающих память; программ, создающих массу файлов; decompressionбомб и тому подобных «приложений».

Ограничиваем ресурсы процессов

Ограничения на процессы накладываются с помощью команды ulimit. Запусти ее с флагом ‘-a’, чтобы увидеть текущие значения. Наиболее интересны для нас строки:

1. Строка «data seg size», флаг ‘-d’. Максимальный размер сегмента данных процесса. Обычно не ограничен, а это значит, что любой процесс может запросто отожрать сколько угодно оперативной памяти с помощью вызова malloc(). Трудно сказать, каким будет оптимальное значение: одни программы потребляют очень много памяти (например, Gimp, который хранит изображения, слои, историю и все остальное в сыром виде), другие обходятся пару килобайтами. Стоит попробовать значение 20480 (20 Мб) и наращивать его в случае необходимости.

2. Строка «file size», флаг ‘-f’. Максимально допустимый размер создаваемого файла. В большинстве систем значение не ограничено, а это значит, что любой пользовательский процесс способен создать файл, размер которого будет ограничен только лимитами, заложенными в файловую систему. Правильным значением будет размер порядка 8 Гб, указанный в блоках файловой системы (обычно 4 Кб).

3. Строка «open files», флаг ‘-n’. Максимальное количество одновременно открытых файлов. В большинстве настольных систем установлено в 1024, что очень разумно. Снятие ограничения приведет к тому, что процесс сможет открывать файлы до тех пор, пока система не впадет в ступор.

4. Строка «max user processes», флаг ‘-u’. Максимальное количество порождаемых пользователем процессов. Обычно значение не ограничено, благодаря чему самая простая форк-бомба может разгуляться на всю катушку. В то же время установка лимита может еще более усугубить ситуацию. Дело в том, что современное ядро Linux вполне способно выдержать действие форк-бомбы, оставаясь при этом отзывчивым, а значит, позволит пользователю открыть терминал и убить вредный процесс. Установив же ограничение, мы добьемся того, что во время действия форкбомбы будет достигнут лимит процессов, и пользователь уже не сможет запустить терминал или выполнить любую другую команду.

В Linux предпочтительные значения ограничений можно указывать не только с помощью вызова команды ulimit, но и используя конфигурационный файл /etc/security/limits.conf, формат которого следующий:

<domain> <type> <resource> <value>

Где <domain> — это имя пользователя, @группа или символ ‘*’ для всех. Столбец <type> — тип ограничения (soft, hard или ‘-’ для обоих), <resource> — ограничиваемый ресурс, <value> — значение. Для перечисленных выше четырех ресурсов их имена для limits.conf будут выглядеть как data, fsize, nofile и nproc. Тип ограничения hard используется для указания максимального значения, которое пользователь вправе установить самостоятельно. Стоит сказать, что никакие комбинации ограничений не будут особенно эффективны против форк-бомб двойного действия, — их порождают процессы, каждый из которых отжирает память в бесконечном цикле.

Приведу пример: ты устанавливаешь ограничение «data seg size», но оставляешь неограниченным «max user processes». Форк-бомба плодит процессы, и система остается доступной, но ровно до момента, пока ее процессы не сожрут всю доступную память, а момент наступит очень быстро (причем вне зависимости от значения «data seg size»!). Можно попытаться решить проблему, установив значение «data seg size» в 20480, а «max user processes» в 128, что достаточно жестко и, на первый взгляд, эффективно. Однако после запуска форк-бомбы ты получишь следующую картину: если бомба сможет породить хотя бы 100 процессов (допустим, что остальные 28 являются легальными), то общий объем съеденной памяти будет равен 100*20480/1024 = 2000 Мб, а доступ к системе окажется заблокированным.
Поэтому, как ни крути, а финал один. Единственный выход: жесткие ограничения на «data seg size» и «max user processes», плюс постоянно открытый шелл с правами root (ограничения на процессы которого сняты).

Устанавливаем квоты

Ограничения на объем занимаемого дискового пространства устанавливаются с использованием механизма квот, который может быть активирован только суперпользователем. Квоты эффективны против файловых и decompression-бомб, ставящих своей целью произвести DoS через попытку полного заполнения файловой системы. Поддержка квот реализована на уровне ядра, но для управления их установкой и снятием показаний предназначены специальные утилиты, обычно распространяемые в пакете quota. Поэтому сначала следует установить этот пакет:

$ sudo apt-get install quota

Далее переходим в однопользовательский режим:

$ sudo bash
# init 1

И добавляем к опциям монтируемых файловых систем слово usrquota в файле /etc/fstab:

/dev/sda2 /home ext3
defaults,usrquota 1 1

Перемонтируем /home, чтобы изменения вступили в силу:

# mount -o remount /home

Создаем файл квот, в котором будут храниться текущие ограничения:

# touch /home/aquota.user
# chmod 600 /home/aquota.user

С помощью команды quotacheck позволяем системе найти файлы квот и связать их с файловой системой:

# quotacheck

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

# edquota -u <пользователь>

Команда активирует редактор, используя который необходимо отредактировать настройки квот. Формат файла следующий: одна строка — одна файловая система. Строка разбита на разделенные пробелом и следующие друг за другом поля:

Поля EDQUOTA

Filesystem — файловая система (имя раздела, на котором она располагается)
Blocks — количество блоков, используемых пользователем в данный момент (блок равен одному килобайту)
Soft — мягкий лимит на количество используемых блоков
Hard — жесткий лимит на количество используемых блоков
Inodes — количество inode (файлов), используемых пользователем
Soft — мягкий лимит на количество inode
Hard — жесткий лимит на количество inode

Исторически ядра UNIX позволяют задавать два ограничения для каждого пользователя: мягкое и жесткое. Сделано так, чтобы пользователь, превысивший мягкое ограничение, смог узнать об этом (получив сообщение в консоль) и успел принять меры по очистке своих каталогов перед тем, как истечет так называемый «период отсрочки», и мягкое ограничение превратится в жесткое. Само собой разумеется, что в современном мире подобный наивный подход не действует, поэтому жесткое ограничение обычно устанавливают в ноль, чтобы ограничение мягкое изначально становилось жестким, и пользователь не мог его превысить. Последуем этому примеру и мы.
Ограничим самого себя 50 гигами (50 * 1024 * 1024 = 52428800), а максимальное количество файлов установим в 2000:

# edquota -u xakep
Disk quotas for user xakep (uid 1001):

Filesystem blocks soft hard inodes soft hard
/dev/sda2 2043743 52428800 0 162 2000 0

Поля blocks и inodes оставляем неизменными, а оба поля hard устанавливаем в 0. Выходим из однопользовательского режима, набрав:

# init 5

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

Контроль целостности системы

Контроль целостности системы представляет собой метод обнаружения разного рода троянов, вирусов и тому подобной нечисти, путем создания заведомо правильного снимка файловой системы и последующей сверки его с текущим состоянием ФС. Осуществлять контроль целостности можно и с помощью простых самописных скриптов, но для Linux уже давно доступна система tripwire, которая автоматизирует эту работу и сводит процент ложных срабатываний к минимуму. Установить tripwire можно с помощью пакетного менеджера любого дистрибутива. Например, в Ubuntu это делается так:

$ sudo apt-get install tripwire

Сразу после установки начнется процесс конфигурирования, который будет выводить на экран информационные окна и задавать вопросы, на каждый из которых следует отвечать «Yes». В конце ты увидишь два приглашения к вводу пароля: site passphrase и local passphrase. Они оба используются для шифрования баз данных (снимков) и конфигурационных файлов, с той лишь разницей, что первый может быть использован сразу на нескольких машинах.

После завершения конфигурирования установи правильные права на файлы конфигурации и политики:

$ cd /etc/tripwire
$ sudo chmod 0600 tw.cfg tw.pol

Далее ты можешь открыть файл политик /etc/tripwire/tw.pol, чтобы изменить правила обработки некоторых файлов. В большинстве случаев менять ничего не придется, потому что разработчики дистрибутивов сами составляют надлежащие файлы политик. После закрытия редактора выполни следующую команду:

$ sudo twadmin --create-polfile --cfgfile ./tw.cfg \
--site-keyfile ./site.key ./twpol.txt

Все, можно создать снимок файлов системы, который будет использоваться в качестве эталона во время поиска изменившихся файлов (в качестве пароля введи указанную во время установки «local passphrase»):

$ sudo tripwire --init --cfgfile \
/etc/tripwire/tw.cfg \
--polfile /etc/tripwire/tw.pol
--site-keyfile /etc/tripwire/site.key \
--local-keyfile /etc/tripwire/HOSTNAMElocal.key

Теперь можно выполнить пробную проверку:

$ tripwire --check

Такие проверки станут происходить каждый день (пакет автоматически установил задание cron), а все отчеты об изменившихся файлах будет получать root на email. Ясно, что tripwire начнет дико орать даже после легальной модификации файлов ОС (правка системных конфигов, установка пакетов и т.д.), поэтому после любого изменения системных файлов (включая файлы /root) следует обновлять базу:

$ sudo tripwire --update -Z low

Также есть специальная команда для обновления файла политик:

$ sudo tripwire --update-policy
--cfgfile ./tw.cfg --polfile \
./tw.pol --site-keyfile ./site.key \
--local-keyfile ./HOSTNAME-local.key \
./twpol.txt

Постскриптум

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

Три совета

1. Следи за правами доступа. Все важные системные файлы настроек должны быть доступны для чтения и записи только суперпользователю. К файлам твоего домашнего каталога должен иметь доступ только ты (права 600). Этого легко добиться, просто указав правильную маску прав доступа в ~/.profile или ~/.bashrc (umask 077).

2. Не помещай себя во множество разных системных групп вроде operator, audio и т.д. Это создает брешь в безопасности и наделяет тебя особыми полномочиями, которые могут быть использованы для западла.

3. Права root нужны только тогда, когда они действительно нужны. Не «сиди» под root’ом, не заходи в систему под root’ом, старайся не запускать команды от имени root. При необходимости используй sudo.

Info

Для большей безопасности конфигурационные файлы и файлы политик tripwire следует хранить на Flash-брелке (и лучше в закриптованном виде).