androidstreet.ru

10 рекомендаций по написанию эффективных Bash-скриптов

2012-05-24T17:48:18+00:00

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

1. Используейте встроенные в Bash команды

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

/bin/echo "hello"

Замените ее на такую:

echo "hello"

В этом случае Bash будет использовать встроенную команду. Полный список встроенных команд вы можете узнать прочитав "man bash".

2. Не используйте внешние команды для простых вычислений

Кроме встроенных команд Bash имеет в своем арсенале средства для простых вычислений. В большинстве случаев их будет достаточно, а если вам понадобится сделать расчеты с плавающей точкой вы всегда сможете воспользоваться командой /usr/bin/bc. Примеры:

four=$(( 2 + 2 ))
four=$[ 2 + 2 ]
let four="2 + 2"

3. Избегайте использования cat

Команды вроде grep, awk и sed принимают в качестве имена файлов. Это значит, что их можно использовать и без перенаправления содержимого файла с помощью cat. Например, если в вашем скрипте есть следующий код:

cat /etc/hosts | grep localhost

Вы можете заменить его на такой и повысить скорость работы скрипта:

grep localhost /etc/hosts

4. Избегайте перенаправления вывода grep в awk

Если вы используете awk вам не нужен grep. Например, следующая строка:

grep error /var/log/messages | awk '{ print $4 }'

Может быть безболезненно заменена на более эффективную:

awk '/error/ { print $4 }' /var/log/messages

5. Избегайте перенаправления вывода sed в sed

Редактор sed может выполнять несколько команд за раз, поэтому все строки вида:

sed 's/hello/goodbye/g' filename | sed 's/monday/friday/g'

лучше заменить на:

sed -e 's/hello/goodbye/g; s/monday/friday/g' filename

6. Используйте двойные ковычки для сравнения с регулярным выражением

Оператор [[ можно использовать для составных команд и сравнения с регулярным выражением:

if [[ expression1 || expression2 ]]; then do_something; fi
if [[ string =~ regex ]]; then do_something; fi

7. Выносите повторяющуюся фрагменты скрипта в функции

Если скрипт становится сложным и внем есть повторяющиеся фрагменты, вынесите их в функции:

function_name() {
    do_something
    return $?
}

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

#!/bin/bash
. /path/to/shared_functions

8. Используйте массивы вместо нескольких переменных

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

color1='Blue'
color2='Red'
echo $color1
echo $color2

можно заменить на такой:

colors=('Blue' 'Red')
echo ${colors[0]}
echo ${colors[1]}

9. Используйте /bin/mktemp для создания временных файлов

Если вам нужен временный файл используйте команду mktemp:

tempfile=$(/bin/mktemp)
tempdir=$(/bin/mktemp -d)

10. Используйте /bin/egrep или /bin/sed для сравнения с регулярным выражением

egrep 'localhost|127\.0\.0\.1' /etc/hosts
sed -n 's/localhost.*/&/p' /etc/hosts

Сервис-центр "Гранд-Сервис" выполнит ремонт сотовых телефонов sony ericsson практически всех марок. Все виды услуг, включая дистику, русификацию, разблокировку, замена дисплеев, аудио-элементов, ремонт и замена клавиатуры, микросхем, установка ПО.

Аргументы ядра Linux, о которых должен знать каждый администратор

2012-05-20T13:42:26+00:00

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

init

Аргумент init используется для указания ядру какому приложению оно должно передать управление после окончания загрузки. По умолчанию этот параметр содержит значение /sbin/init, приложение, которое порождает все остальные процессы системы, включая демоны, сервер X Window и приглашение к входу. Этот аргумент удобно использовать для восстановления системы забыли пароль. Укажите при загрузке ядра:

init=/bin/bash

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

single

Аргумент single принуждает процесс init загружать систему в однопользовательском режиме без запуска каких-либо демонов. Он может быть полезен в том случае, если ОС не может выполнить полноценную загрузку из-за проблем с запуском демонов.

root

С помощью аргумента root можно указать ядру какое устройство содержит корневую файловую систему. Это можно использовать, например, для загрузки дстрибутива, установленного на жесткий с ядром с LiveCD, либо для исправления проблем после переноса системы на другой диск. Пример использования:

root=/dev/sda1

ro

Аргумент ro принуждает ядро монтировать корневую ФС в режиме "только для чтения", что можно использовать для последующего исправления файловой системы с помощью fsck.

rw

Этот аргумент принуждает ядро монтировать корневую ФС в режиме записи.

panic

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

panic=10

Перезагрузка через 10 секунд после возникновения паники ядра.

maxcpus

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

maxcpus=2

debug

Включение механизма отладки ядра. Полезно для разработчиков ядра и приложений.

selinux

Отключение или включение SELinux: "selinux 0" или "selinux 1".

raid

Указывает ядру как должны быть собраны RAID-массивы при загрузке. Пример: "raid=/dev/md1".

mem

Параметр mem указывает ядру сколько оперативной памяти оно должно "видеть" в системе. Полезно при возникновении проблем с загрузкой системы на машинах с большим количеством ОЗУ, которое ядро не может использовать или для отладки приложений. Пример:

mem=1024M

hdX=noprobe

Отключает инициализацию указанного диска:

hdb=noprobe

Полезно когда ядро уходит в панику из-за проблем с диском.

Где указывать эти аругменты

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

Источник: www.cyberciti.biz

Хотите купить сервер в Москве? Нет ничего проще! Компания WESTCOMP (www.westcomp.ru) предлагает большое количество б/у севреров от ведущих мировых производителей, включая такие бренды как HP, IBM, Dell и Cisco. Отличное качество, низкие цены, доставка, гарантия.

Файлы со странными именами

2012-05-14T19:42:11+00:00

Порой в файловой системе можно найти файлы со странными именами и неудобными для обработки в терминале названиями. Это могут быть файлы с пробелами между словами, неалфавитными или непечатаемыми символами в названии. Они могут появится благодаря неправильно работающим приложениям, в результате скачивания из интернета или просто по недосмотру других пользователей системы. В любом случае работать с такими файлами неудобно, вы не сможете просто выполнить команду "rm файл" или "mv файл". Что можно сделать?

Случай #1. Файлы с пробелами в названии

Допустим вы имеете следующее:

$ ls -l
file2.txt
test file.txt

Чтобы удалить/переместить файл "test file.txt" просто используйте функцию автодополнения. Наберите "mv test", нажмите Tab и командный интерпретатор закончит имя файла, расставив перед пробелами знаки экранирования: "test\ file.txt". Все. Если в каталоге есть второй файл, имя которого начинается на "test" просто повторно нажмите "Tab".

Случай #2. Файлы, имена которых начинаются на знак -

Теперь у вас есть такой каталог:

$ ls -1
file2.txt
test file.txt
test2.txt
-file

Если вы просто попытаетесь выполнить команду в отношении этого файла, то получите примерно следующий результат:

$ rm -file
rm: invalid option -- 'l'

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

$ rm -file
rm: invalid option -- 'l'
Try `rm ./-file' to remove the file `-file'.

Второй способ состоит в том, чтобы добавить перед именем файла последовательность из двух минусов, которая сообщит команде, что все флаги на этом месте заканчиваются и все последующие аргументы следует принимать непосредственно, то есть как имена файлов в случае с такими командами как rm/mv/cp и другими:

$ rm -- -file

Тяжелый случай

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

$ ls -1
-file
--file
file2.txt
test2.txt
test file.txt
\+Xy \+\8

В этом случае можно использовать универсальный подход, который сработает в 100% случаев. Заключается он в том, чтобы заставить команду "ls" показать нам не только имена файлов, но и их номера inode, которые всегда имеют числовую форму:

$ ls -i1
285134 -file
285136 --file
3901 file2.txt
285132 test2.txt
2302 test file.txt
285461 \+Xy \+\8

Команда "ls" сообщает нам, что последний файл имеет inode 285461. Теперь мы можем использовать эту информацию чтобы удалить файл. С помощью rm это сделать не получится, однако команда find легко найдет файл по его inode:

$ find . -inum 285461 | xargs rm

Ищете помещение под офис в Брянске? Нет проблем. "Управляющая компания" поможет вам найти выгодное предложение от собственников. Продажа коммерческой недвижимости, офисов, нежелых помещений.

Вирусы в UNIX

2012-03-26T14:47:51+00:00

Еще один интересный (с исторической точки зрения) пост, опубликованный в блоге Раса Кокса: "Вирусы в UNIX" (Unix Viruses) с рассказом о беспочвенности веры в то, что вирусов в UNIX нет.

Дисковые компьютерные вирусы берут свое начало в эпоху MS-DOS, сетевые вирусы пришли из эпохи Windows.

Многие пользователи Linux и OS X имеют в корне неверное убеждение, что им не страшны вирусы, потому что они используют Unix. Это очевидная ошибка: первый интернет-червь поражал UNIX-машины. Простые механизмы защиты, применяемые в UNIX-подобных операционных системах, несколько затрудняют процесс написания вирусов, но их малое распространение связано вовсе не с тем, что UNIX неуязвима для вирусов, а с тем, что UNIX просто не имеет той доли рынка, ради которой стоило бы тратить усилия на написание вредоносного ПО.

Для отрезвления неверующих в эту точку зрения я рекомендовал бы почитать доклад Тома Дафа (Tom Duff) 1987 года под названием "Вирусные атаки против систем безопасности UNIX" (Viral Attacks on UNIX System Security), в которой описан простой, но качественный дисковый вирус, поражающий исполняемые файлы UNIX. Несмотря на ограничения прав доступа к файлам, за несколько месяцев вирусу Дафа удалось инфицировать 466 файлов на 46 машинах, включая экспериментальную "безопасную" версию UNIX (справедливости ради стоит сказать что в результате система все-таки обнаружила вирус). В докладе Даф также описал процесс написания простого вируса на языке сценариев sh. Он предупреждает:

Как бы вам не хотелось не запускайте этот код. Я случайно сделал это на своей машине во время отладки и за час этот вирус инфицировал 140 файлов, которые также начали попытки инфицировать другие файлы, создавая нагрузку на машину в районе 0.05-1.25 с пиковыми значениями в 17. Мне пришлось остановить работу машины посреди рабочего дня и потратить 3 часа на очистку дисков, выслушивая упреки сослуживцев (скорее всего Даф запустил вирус на центральном сервере, к которому его сослуживцы имели терминальный доступ - прим.пер.). Мне невероятно повезло, что вирус не успел инфицировать другие машины нашей сети.

В документе "Вирусология 101 (Virology 101), опубликованном в 1989 году, Дуг Макилрой (Doug McIlroy) резюмирует:

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

Как бы там ни было и какой бы опасности вы не подвергали себя, пользуюсь UNIX, во время долгих путешествий вам не обойтись без рюкзаков для ноутбука. Рюкзаки для любых ноутбуков вы легко найдете в интернет-магазине SotMarket. Диагонали от 9 до 20 дюймов, большой выбор производителей и расцветок. Приятные цены.

Абсолютный дизайн файловой системы

2012-03-26T07:17:36+00:00

Сегодня я хочу предложить вашему вниманию перевод довольно интересной записи, опубликованной в блоге Раса Кокса (Russ Cox), одного из активных разработчиков post-unix операционной системы Plan 9 и порта ее компонентов в UNIX plan9port. В оригинале название поста звучит как Absolute File System Design и описывает файловую систему компьютера Alto, созданного более 30 лет назад.

В 1979 году Батлер Лэмпсон (Butler Lampson) и Роберт Спроул (Robert Sproull) опубликовали документ "Операционная система для однопользовательского компьютера" (An Open Operating System for a Single-User Machine), в котором описали операционную систему компьютера Alto, персональной сетевой рабочей станции, основанной на Xerox PARC. Многие особенности Alto позднее стали неотъемлемыми атрибутами любого настольного ПК, однако его инновационная устойчивая к сбоям файловая система осталось забытой.

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

Технология, позволяющая добиться такого эффекта, была описана в третьем разделе документа. Базовая техника защиты состояла в том, что каждый блок данных имел небольшой заголовок, содержащий идентификационный номер и версию файла, к которому он привязан, а также логическое смещение этого блока в файле и количество данных файла в блоке (последний блок файла мог содержать меньше данных, чем размер самого блока). Лэпсон и Спроул ссылались на эту информацию как на истину в первой инстанции. Специальная утилита (наподобие fsck в UNIX) могла просканировать всю файловую систему, читая заголовки блоков и восстановить (хотя бы частичное) содержимое любого файла при любых нарушениях файловой системы.

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

Сравните эту схему с файловыми дескрипторами (inode) в современных файловых системах UNIX (BSD FFS или Linux Ext2/3). Если вы потеряете блок данных, содержащий inode файла, вы потеряете весь файл. Никакие проверки в этом случае не помогут, потому как список блоков файла содержится только в inode, а сами блоки не имеют идентификаторов принадлежности. Это намного менее стойкая схема чем та, что использовалась в файловой системе Alto. Конечно, бывают и намного более худшие сценарии, например потеря суперблока, которая приведет к потере всей файловой системы. Но так как суперблок настолько важен, файловые системы обычно дублируют его по всему диску. Однако, не менее важные файловые дескрипторы имеют только одну копию.

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

Геометрия дисков играет свою роль: трудно "подружить" (скажем) 32-байтный заголовок с (например) 4 Кб блоком данных. Если поместить заголовок в сам блок данных, мы обрежем блок данных до 4064 байт и получим ухудшение производительности из-за неверного выравнивания данных. Если мы поместим заголовок в сектор перед блоком данных, то потеряем дисковое пространство, используя 512 байт для 32-байтного заголовка. Мы могли бы использовать один сектор для хранения 16 заголовков для следующих 16 блоков. Это наиболее оптимальный вариант, но и он имеет свои недостатки (но зато мы не потеряем данные!).

Другая причина историческая: оригинальная файловая система UNIX не имела подобных механизмов, а FFS и Ext2/3 не так уж и сильно отличаются от нее.

Причина может быть и философской: вы защищаетесь от сбоев жестких дисков с помощью бэкапов, а ни каких-то трюков файловой системы. Это наименее правдоподобный аргумент: почему бы не использовать возможности ФС чтобы не обращаться к бэкапам так часто?

Еще причина может носить прагматичный характер: может быть диски "сыплются" как-то по другому, чем в 1979 году. Здесь трудно сказать что-то определенное, так как мы не имеем достаточной информации о том, как "сыпались" диски в 1979-ом.

Каким бы ни был аргумент против заголовков, нельзя отрицать того факта, что они позволяют создать очень устойчивую файловую систему. Почему бы не сделать такую систему сегодня. И почему современные файловые системы не такие устойчивые?

Сломался компьютер, а за ремонт сдирают бешенные деньги? Не беда, на Купонаторе много купонов на Обслуживание и ремонт компьютеров со скидкой от 50%. Приходите - берите.

11 полезных команд для администраторов

2012-02-27T10:39:25+00:00

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

1 Сохранение man-страниц в формате PDF

$ man -t awk | ps2pdf - awk.pdf

2 Дублирование установленных пакетов на другую машину

$ ssh root@remote.host "rpm -qa" | xargs yum -y install

3 Размещение подписи в верхней части PDF-страниц

$ echo "ТЕКСТ" | enscript -B -f Courier-Bold16 -o- | \
    ps2pdf - | pdftk input.pdf stamp - output output.pdf

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

$ mysql -u root -p -BNe \
    "select host,count(host) from processlist group by host;" \
    information_schema

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

$ ssh user@host "tar -zcf - /path/to/dir" > dir.tar.gz

6 Просмотр логов удаленной машины

$ ssh -t remotebox "tail -f /var/log/remote.log"

7 Просмотр списка пользователей и групп в виде наглядной диаграммы

$ awk 'BEGIN{FS=":"; print "digraph{"}{split($4, a, ","); \
    for (i in a) printf "\"%s\" [shape=box]\n\"%s\" \
    -> \"%s\"\n", $1, a[i], $1}END{print "}"}' /etc/group|display

8 Просмотр зависимостей загруженных модулей в виде графа

lsmod | perl -e 'print "digraph \"lsmod\" \
    {";<>;while(<>){@_=split/\s+/; \
    print "\"$_[0]\" -> \"$_\"\n" for split/,/,$_[3]}print "}"' |\
    dot -Tpng | display -

9 Создание стойкого, но легкого для запоминания пароля

$ read -s pass; echo $pass | md5sum | base64 | cut -c -16

10 Поиск всех файлов, длиннее 500 Мб, но короче 1 Гб

$ find / -type f -size +500M -size -1G

11 Ограничение приложения в процессорных ресурсах

$ sudo cpulimit -p pid -l 50

Источник: http://www.unixmen.com/11-useful-commands-for-linuxunix-administrators/

Команда /bin/ip для новичков

2012-01-10T16:26:52+00:00

Команда /bin/ip появилась в Linux-дистрибутивах уже давно, однако пользователи продолжают по привычке использовать старый добрый /sbin/ifconfig. Давайте посмотрим правде в глаза: ifconfig конечно никуда не денется, зато ip обладает намного более внушительным набором возможностей.

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

Список сетевых карт и их конфигураций

$ ifconfig

$ ip addr show
$ ip link show

Включение сетевого интерфейса

$ ifconfig eth0 up

$ ip link set eth0 up

Выключение происходит по такой же схеме:

$ ifconfig eth0 down

$ ip link set eth0 down

Назначение IP-адреса

$ ifconfig eth0 192.168.0.77

$ ip address add 192.168.0.77 dev eth0

Это простой вариант команды. Обычно необходимо указать также маску подсети и широковещательный адрес:

$ ifconfig eth0 192.168.0.77 netmask 255.255.255.0 broadcast 192.168.0.255

$ ip addr add 192.168.0.77/24 broadcast 192.168.1.255 dev eth0

Удаление IP-адреса

С помощью ip вы также можете удалить IP-адрес:

$ ip addr del 192.168.0.77/24 dev eth0

Псевдонимы (alias)

$ ifconfig eth0:1 10.0.0.1/8

$ ip addr add 10.0.0.1/8 dev eth0 label eth0:1

Протокол ARP

Новая запись в ARP-таблице:

$ arp -i eth0 -s 192.168.0.1 00:11:22:33:44:55

$ ip neigh add 192.168.0.1 lladdr 00:11:22:33:44:55 nud permanent dev eth0

Отключение протокола ARP на интерфейсе:

$ ifconfig ~arp eth0

$ ip link set dev eth0 arp off

Оригинал на английском.

Ищете площадку для размещения серверного и коммутационного оборудования? Дата центр MSM.ru к вашим услугам. Аренда юнитов, стоек и выделенных серверов.

Шифруем файлы с помощью OpenSSL

2011-12-01T16:16:23+00:00

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

В качестве универсального средства шифрования каталогов и дисков OpenSSL, конечно, подходит плохо, но для криптования отдельно взятых файлов лучше инструмента не найти. В качестве примера попробуем зашифровать файл secret.txt:

$ openssl enc aes-256-cbc -salt -in secret.txt -out secret.aes
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:

Здесь мы используем алгоритм шифрования AES (один из лучших на сегодня) с длиной ключа 256 байт и режимом шифрования CBC (который хоть и скомпрометировал себя, но для домашних нужд вполне сгодится). Также с помощью опции -salt добавим соли чтобы результат получился совсем мудреный. В ответ на запрос пароля вводим пароль (дважды).

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

$ openssl aes-256-cbc -d -in secret.aes -out secret.txt

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

$ echo секретный текст | openssl aes-256-cbc -salt -out secret.aes

Объединив этот способ со всемогущим netcat получаем сетевой cp:

приемник...$ nc -l -p 666 | openssl aes-256-cbc -d
передатчик.$ echo секретный текст | openssl aes-256-cbc -salt | nc 192.168.0.1 666

Чтобы зашифровать сразу несколько файлов можно написать небольшой скрипт:

$ for f in * ; do [ -f $f ] &&\
    openssl enc -aes-256-cbc -salt -in $f -out $f.enc\
    -pass file:/tmp/passwd ; done

Оцпия -pass file:/tmp/passwd здесь используется чтобы не вводить пароль для каждого файла. Достаточно просто поместить его в указанный файл и дело в шляпе (можно также использовать опцию -pass pass:пароль для прямого указания пароля, но это небезопасно, он осядет в истории bash).

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

$ tar c каталог | openssl enc -aes-256-cbc -e > secret.tar.enc

Также OpenSSL удобно использовать для генерирования стойких паролей:

$ openssl rand 8 -base64
O0Hqtv9l0sY=

И хэшей для записи в /etc/passwd:

# openssl passwd -1 my-secret-pass
$1$WA7AVhQL$y9VaGwseiKRLSGoJg21TP0

И даже фиктивных MAC-адресов:

$ openssl rand -hex 6 | sed 's/\(..\)/\1:/g; s/.$//'
f2:9e:56:fd:5a:93

Идеальное предложение для тех, кто хочет отдохнуть в Египте. Горячие туры в Египет здесь и сейчас. Заходите и берите.

Используем графический процессор в личных целях. Часть 2

2011-11-05T17:36:39+00:00

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

Первая часть.

Что нам нужно?

Во-первых, понадобится видео-карта, поддерживающая технологию CUDA или Stream. Не обязательно, чтобы это была топовая модель, достаточно любой карты с годом выпуска не раньше 2009. Полный список поддерживаемых видео-карт можно посмотреть в википедии на страницах CUDA и AMD_Stream_Processor. Также о поддержке той или иной технологии можно узнать прочитав документацию, хотя в большинстве случаев будет достаточным взглянуть на коробку из под видео-карты или ноутбука. Обычно на нее наклеены различные рекламные стикеры.

Во-вторых, в систему должны быть установлены последние проприетарные драйвера для видео-карты, они обеспечат поддержку как родных для карточки технологий GPGPU, так и открытого OpenCL.

И в-третьих, так как пока дистрибутивостроители еще не начали распространять пакеты приложений с поддержкой GPGPU, нам придется собирать приложения самостоятельно, а для этого нужны официальные SDK от производителей: CUDA Toolkit или ATI Stream SDK. Они содержат в себе необходимые для сборки приложений заголовочные файлы и библиотеки.

Ставим CUDA Toolkit

Идем по вышеприведенной ссылке и скачиваем CUDA Toolkit для Linux (выбрать можно из нескольких версий, для дистрибутивов Fedora, RHEL, Ubuntu и SUSE, есть версии как для архитектуры x86, так и для x86_64). Кроме того, там же надо скачать комплектов драйверов для разработчиков (Developer Drivers for Linux, они идут первыми в списке).

Запускаем инсталлятор SDK:

$ sudo sh cudatoolkit_4.0.17_linux_64_ubuntu10.10.run

Когда установка будет завершена приступаем к установке драйверов. Для этого завершаем X-сервер:

# sudo /etc/init.d/gdm stop

Открываем консоль <Ctrl+Alt+F5> и запускаем инсталлятор драйверов:

$ sudo sh devdriver_4.0_linux_64_270.41.19.run

После окончания установки стартуем иксы:

$ startx

Чтобы приложения смогли работать с CUDA/OpenCL, прописываем путь до каталога с CUDA-библиотеками в переменную LD_LIBRARY_PATH:

$ export LD_LIBRARY_PATH=/usr/local/cuda/lib64

Или, если вы установили 32-битную версию:

$ export LD_LIBRARY_PATH=/usr/local/cuda/lib32

Также необходимо прописать путь до заголовочных файлов CUDA, чтобы компилятор их нашел на этапе сборки приложения:

$ export C_INCLUDE_PATH=/usr/local/cuda/include

Все, теперь можно, приступить к сборке CUDA/OpenCL-софта.

Ставим ATI Stream SDK

Stream SDK не требует установки, поэтому скачанный с сайта AMD архив можно просто распаковать в любой каталог (лучшим выбором будет /opt) и прописать путь до него во все ту же перменную LD_LIBRARY_PATH:

$ cd
$ wget http://download2-developer.amd.com/amd/APPSDK/AMD-APP-SDK-v2.4-lnx64.tgz
$ cd /opt
$ sudo tar -xzf ~/AMD-APP-SDK-v2.4-lnx64.tgz
$ export LD_LIBRARY_PATH=/opt/AMD-APP-SDK-v2.4-lnx64/lib/x86_64/
$ export C_INCLUDE_PATH=/opt/AMD-APP-SDK-v2.4-lnx64/include/

Как и в случае с CUDA Toolkit, x86_64 необходимо заменить на x86 в 32-битных системах. Теперь переходим в корневой каталог и распаковываем архив icd-registration.tgz (это своего рода бесплатный лицензионный ключ):

$ cd /
$ sudo tar -xzf /opt/AMD-APP-SDK-v2.4-lnx64/icd-registration.tgz

Проверяем правильность установки/работы пакета с помощью инструмента clinfo:

$ /opt/AMD-APP-SDK-v2.4-lnx64/bin/x86_64/clinfo

ImageMagick и OpenCL

Поддержка OpenCL появилась в ImageMagick уже достаточно давно, однако по умолчанию она не активирована ни в одном дистрибутиве. Поэтому нам придется собрать IM самостоятельно из исходников.

Ничего сложного в этом нет, все необходимое уже есть в SDK, поэтому сборка не потребует установки каких-то дополнительных библиотек от nVidia или AMD. Итак, скачиваем/распаковываем архив с исходниками:

$ wget ftp://mirror.aarnet.edu.au/pub/imagemagick/ImageMagick-6.7.0-0.tar.bz2
$ tar -xjf ImageMagick-6.7.0-0.tar.bz2
$ cd ImageMagick-6.7.0-0

Далее устанавливаем инстурменты сборки:

$ sudo apt-get install build-essential

Запускаем конфигуратор и грепаем его вывод на предмет поддержки OpenCL:

$ LDFLAGS=-L$LD_LIBRARY_PATH ./configure | grep -e cl.h -e OpenCL

checking CL/cl.h usability... yes
checking CL/cl.h presence... yes
checking for CL/cl.h... yes
checking OpenCL/cl.h usability... no
checking OpenCL/cl.h presence... no
checking for OpenCL/cl.h... no
checking for OpenCL library... -lOpenCL

Словом “yes” должны быть отмечены либо первые три строки, либо вторые (или обе сразу). Если это не так, значит скорее всего была неправильно инициализирована переменная C_INCLUDE_PATH. Если же словом “no” отмечена последняя строка, значит дело в переменной LD_LIBRARY_PATH.

Если все ок запускаем процесс сборки/установки:

$ sudo make install clean

Проверяем, что ImageMagick действительно был скомпилирован с поддержкой OpenCL:

$ /usr/local/bin/convert -version | grep Features
Features: OpenMP OpenCL

Теперь измерим полученный выигрыш в скорости. Разработчики ImageMagick рекомендуют использовать для этого фильтр convolve:

$ time /usr/bin/convert image.jpg -convolve '-1, -1, -1, -1, 9, -1, -1, -1, -1' image2.jpg
$ time /usr/local/bin/convert image.jpg -convolve '-1, -1, -1, -1, 9, -1, -1, -1, -1' image2.jpg

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

FlacCL (Flacuda)

FlacCL - это кодировщик звуковых файлов в формат FLAC, задействующий в своей работе возможности OpenCL. Он входит в состав пакета CUETools для Windows, но благодаря mono может быть использован и в Linux.

Для получения архива с кодировщиком выполняем следующую команду:

$ mkdir flaccl && cd flaccl
$ wget http://www.cuetools.net/install/flaccl03.rar

Далее устанавливаем unrar, mono и распаковываем архив:

$ sudo apt-get install unrar mono
$ unrar x flaccl03.rar

Чтобы программа смогла найти библиотеку OpenCL делаем символическую ссылку:

$ ln -s $LD_LIBRARY_PATH/libOpenCL.so libopencl.so

Теперь запускаем кодировщик:

$ mono CUETools.FLACCL.cmd.exe music.wav

Если на экран будет выведено ссобщение об ощибке следующего вида:

Error: Requested compile size is bigger than the required workgroup size of 32

Значит у нас в системе слишком слабенькая видео-карта и количество задействованных ядер следует сократить до указанного числа с помощью флага ‘--group-size XX’, где XX - нужное количество ядер.

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

oclHashcat или брутфорс по быстрому

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

oclHashcat - это ломалка, которая умеет подбирать пароли по их хэшу с экстремально высокой скоростью, задействуя при этом мощности GPU с помощью OpenCL. Если верить замерам, опубликованным на сайте проекта, скорость подбора MD5-паролей на nVidia GTX580 составляет до 15800 млн комбинаций в секунду, благодаря чему oclHashcat способен найти средний по сложности восьмисимвольный пароль за какие-то 9 минут.

Программа поддерживает OpenCL и CUDA, алгоритмы MD5, md5($pass.$salt), md5(md5($pass)), vBulletin < v3.8.5, SHA1, sha1($pass.$salt), хэши MySQL, MD4, NTLM, Domain Cached Credentials, SHA256, поддерживает распределенный подбора паролей с задействованием мощностей нескольких машин.

Автор не раскрывает исходники (что, в общем-то, логично), но у программы есть нормально работающая Linux-версия, которую можно получить с официальной странички: http://hashcat.net/files/oclHashcat-0.25.7z.

Далее следует распаковать архив:

$ 7z x oclHashcat-0.25.7z
$ cd oclHashcat-0.25

И запустить программу (воспользуемся пробным списком хэшей и пробным словарем):

$ ./oclHashcat64.bin example.hash ?l?l?l?l example.dict

oclHashcat откроет текст пользовательского соглашения, с которым следует согласиться набрав “YES”. После этого начнется процесс перебора, прогресс которого можно узнать нажав <s>, также приостановить процесс с помощью клавиши <p> и возобновить нажав <r>.

Также можно использовать прямой перебор (например, от aaaaaaaa до zzzzzzzz):

$ ./oclHashcat64.bin hash.txt ?l?l?l?l ?l?l?l?l

И различные модификации словаря и метода прямого перебора, а также их комбинации (об этом можно прочитать в файле docs/examples.txt). В моем случае скорость перебора всего словаря составила 11 минут, тогда как прямой перебор (от aaaaaaaa до zzzzzzzz) длился около 40 минут. В среднем скорость работы GPU (чип RV710) составила 88.3M/s.

Выводы

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

KGPU или ядро Linux, ускоренное GPU

Исследователи из университета Юты разработали систему KGPU, позволяющую выполнять некоторые функции ядра Linux на графическом процессоре с помощью фреймворка CUDA. Для выполнения этой задачи используется модифицированное ядро Linux и специальный демон, который работает в пространстве пользователя, слушает запросы ядра и передает их драйверу видео-карты с помощью библиотеки CUDA. Интересно, что несмотря на существенный оверхед, который создает такая архитектура, авторам KGPU удалось создать реализацию алгоритма AES, который поднимает скорость шифрования файловой системы eCryptfs в 6 раз.

Ссылки

Облачный сервис, позволяющий загружать и запускать софт с поддержкой CUDA и OpenCL: http://www.hoopoe-cloud.com.
FASTRA II - суперкомпьютер, построенный с использованием 13 видео-карт, мощностью 12TFLOPS: http://fastra2.ua.ac.be.
Реализация архиватора bzip2 с использованием CUDA: http://bzip2-cuda.github.com

Статья написана для журнала Хакер.

У вас собственных помещений для размещения серверов? Дата центр msm.ru к вашим услугам. Размещения серверного и коммутационного оборудования, аренда серверов, приемлемые цены.

Используем графический процессор в личных целях (GPGPU). Часть 1

2011-11-04T15:15:55+00:00

Сегодня новости об использовании графических процессоров для общих вычислений можно услышать на каждом углу. Такие слова как CUDA, Stream и OpenCL за каких то два года стали чуть ли не самыми цитируемыми в айтишном интернете и на страницах журналов и книг. Однако, что значат эти слова и что несут стоящие за ними технологии, известно далеко не каждому, а для линуксойдов, привыкших “быть в пролете”, так и вообще все это видится темным лесом.

В этой статье мы попытаемся разобраться зачем нужна технология GPGPU (General-purpose graphics processing units - Графический процессор общего назначения) и все связанные с ней реализации от конкретных производителей. Узнаем почему эта технология имеет очень узкую сферу применения, в которую подавляющее большинство софта не попадает в принципе, и конечно же, попытаемся извлечь из всего этого выгоду в виде существенных приростов производительности в таких задачах как шифрование, подбор паролей, работа с мультимедиа и архивирование.

О чем это я?

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

Позже появились многоядерные процессоры и многопроцессорные системы, в которых таких компонентов было несколько. Это позволило машинам выполнять несколько задач одновременно, а общая (теоретическая) производительность системы поднялась ровно во столько раз, сколько ядер было установлено в машине. Однако, оказалось, что производить и конструировать многоядерные процессоры слишком сложно и дорого. В каждом ядре приходилось размещать полноценный процессор сложной и запутанной x86-архитектуры, со своим (довольно объемным) кэшем, конвейером инструкций, блоками SSE, множеством блоков, выполняющих оптимизации и т.д и т.п. Поэтому процесс наращивания количества ядер существенно затормозился и белые университетские халаты, которым 2 или 4 ядра было явно мало, нашли способ задействовать для своих научных расчетов другие вычислительные мощности, которых было в достатке на видео-карте (в результате даже появился инструмент BrookGPU, эмулирующий дополнительный процессор с помощью вызовов функций DirectX и OpenGL).

Графические процессоры, лишенные многих недостатков центрального процессора, оказались отличной и очень быстрой счетной машинкой и совсем скоро к наработкам ученых умов начали присматриваться сами производители GPU (а nVidia так и вообще наняла большинство исследователей на работу). В результате появилась технология nVidia CUDA, определяющая интерфейс, с помощью которого стало возможным перенести вычисление сложных алгоритмов на плечи GPU без каких-либо костылей. Позже за ней последовала ATi (AMD) с собственным вариантом технологии под названием Close to Metal (ныне Stream), а совсем скоро появилась ставшая стандартом версия от Apple под названием OpenCL.

GPU наше все?

Несмотря на все преимущества техника GPGPU имеет несколько проблем. Первая из них заключается в очень узкой сфере применения. GPU шагнули далеко вперед центрального процессора в плане наращивания вычислительной мощности и общего количества ядер (видеокарты несут на себе вычилительный блок, состоящий из более чем сотни ядер), однако такая высокая плотность достигается за счет максимального упрощения дизайна самого чипа.

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

Вторая проблема GPGPU в том, что адаптировать для выполнения на GPU можно далеко не каждый алгоритм. Отдельно взятые ядра графического процессора довольно медлительны и их мощь проявляется только при работе сообща. А это значит, что алгоритм будет настолько эффективным, насколько эффективно его сможет распараллелить программист. В большинстве случаев с такой работой может справиться только хороший математик, которых среди разработчиков софта далеко не большинство.

И третье: графические процессоры работают с памятью, установленной на самой видео-карте, так что при каждом задействовании GPU будет происходить две дополнительных операции копирования: входные данные из оперативной памяти самого приложения и выходные данные из GRAM обратно в память приложения. Не трудно догадаться, что это может свести на нет весь выигрыш во времени работы приложения (как и происходит в случае с инструментом FlacCL, который мы рассмотрим позже).

Но и это еще не все. Несмотря на существование общепризнанного стандарта в лице OpenCL, многие программисты до сих пор предпочитают использовать привязанные к производителю реализации техники GPGPU. Особенно популярной оказалась CUDA, которая хоть и дает более гибкий интерфейс программирования (кстати, OpenCL в драйверах nVidia реализован поверх CUDA), но намертво привязывает приложение к видео-картам одного производителя.

Что есть сейчас?

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

Одними из первых появились крэкеры различных хэшей, алгоритмы работы которых очень легко распараллелить. Также родились мультимедийные приложения, такие кодировщик FlacCL, позволяющий перекодировать звуковую дорожку в формат FLAC. Поддержкой GPGPU обзавелись и некоторые уже существовавшие ранее приложения, самым заметным из которых стал ImageMagick, который теперь умеет перекладывать часть своей работы на графический процессор с помощью OpenCL. Также есть проекты по переводу на CUDA/OpenCL (не любят юниксойды ATi) архиваторов данных и других систем сжатия информации. Наиболее интересные из этих проектов мы рассмотрим в следующей статье.

Статья написана для журнала Хакер.

Хотите купить кондиционер? Тогда интернет-магазин климатической техники cli.ru к вашим услугам.Бесплатная доставка, выезд специалиста, срочный монтаж, комплексный подход к оказанию услуг.

Альманах по борьбе с DDoS

2011-10-27T18:51:31+00:00

Твое утро начинается с чтения багрепортов и анализа логов. Ты ежедневно обновляешь ПО и ежечасно дорабатываешь правила брандмауэра. Snort твой лучший друг, а Zabbix – невидимый помощник. Ты построил настоящий бастион, к которому не подобраться ни с одной стороны. Но! Ты совершенно беззащитен против самой коварной и подлой атаки на свете – DDoS.

Анатомия DoS-атак

Трудно сказать, когда впервые появился термин DoS-атака. Специалисты говорят о 1996-м, попутно намекая, что до широких масс этот тип атак «дошел» только в 1999 году, когда один за другим попадали web-сайты Amazon, Yahoo, CNN и eBay. Еще раньше DoS-эффект использовали для тестирования устойчивости систем и каналов связи. А если копнуть глубже и воспользоваться термином DoS для обозначения явления, то становится ясно, что он существовал всегда, со времен первых мейнфреймов, вот только задумываться о нем как о средстве устрашения начали гораздо позже.

Говоря простым языком, DoS-атаки – это некоторый вид злонамеренной деятельности, ставящей своей целью довести компьютерную систему до такого состояния, когда она не сможет обслуживать правомерных пользователей или правильно выполнять возложенные на нее функции. К состоянию «отказ в обслуживании» обычно приводят ошибки в ПО или чрезмерная нагрузка на сетевой канал или систему в целом, в результате чего ПО, либо вся операционная система машины «падает» или же оказывается в «зацикленном» состоянии. А это грозит простоями, потерей посетителей/клиентов и убытками.

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

Удаленная эксплуатация ошибок в ПО для того, чтобы привести его в нерабочее состояние.
Flood – посылка на адрес жертвы огромного количества бессмысленных (реже осмысленных) пакетов. Целью флуда может быть канал связи или ресурсы машины. В первом случае поток пакетов занимает весь пропускной канал и не дает атакуемой машине возможность обрабатывать легальные запросы. Во втором – ресурсы машины захватываются с помощью многократного и очень частого обращения к какому-либо сервису, выполняющему сложную, ресурсоемкую операцию. Это может быть, например, длительное обращение к одному из активных компонентов (скрипту) web-сервера. В результате сервер тратит все ресурсы машины на обработку запросов атакующего, а пользователям приходится ждать.

В своем традиционном исполнении (один атакующий – одна жертва) на данный момент остается эффективным только первый вид атак. Классический флуд бесполезен просто потому, что при сегодняшней ширине канала серверов, уровне вычислительных мощностей и повсеместном использовании различных анти-DoS приемов в ПО (например, задержки при многократном выполнении одних и тех же действий одним клиентом), атакующий превращается в надоедливого комара, не способного нанести какой бы то ни было ущерб. Но если этих комаров наберутся сотни, тысячи или даже сотни тысяч, они легко положат сервер на лопатки. Толпа – страшная сила не только в жизни, но и в компьютерном мире. Распределенная атака типа «отказ в обслуживании» (DDoS), обычно осуществляемая с помощью множества зомбифицированных хостов, может отрезать от внешнего мира даже самый стойкий сервер, и единственная эффективная защита от нее – организация распределенной системы серверов (но это по карману далеко не всем, привет Google).

Методы борьбы

Опасность большинства DDoS-атак в их абсолютной прозрачности и «нормальности». Ведь если ошибка в ПО всегда может быть исправлена, то полное сжирание ресурсов – явление почти обыденное, с которым сталкиваются многие администраторы, когда ресурсов машины (ширины канала) становится недостаточно, или их web-сайт подвергается слэшдот-эффекту (twitter.com стал недоступен уже через несколько минут после первого известия о смерти Майкла Джексона). И если резать трафик и ресурсы для всех подряд, то спасешься от DDoS, но потеряешь добрую половину клиентов.

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

Борьба с flood-атаками

Итак, существует два типа DoS/DDoS-атак, и наиболее распространенная из них основана на идее флуда, то есть заваливания жертвы огромным количеством пакетов. Но флуд бывает разным: ICMP-флуд, SYN-флуд, UDP-флуд и HTTP-флуд. Современные DoS-боты могут использовать все эти виды атак одновременно, поэтому следует заранее позаботиться об адекватной защите от каждой из них.

ICMP-флуд. Очень примитивный метод забивания полосы пропускания и создания нагрузок на сетевой стек через монотонную посылку запросов ICMP ECHO (пинг). Легко обнаруживается с помощью анализа потоков трафика в обе стороны: во время атаки типа ICMP-флуд они практически идентичны. Почти безболезненный способ абсолютной защиты основан на отключении ответов на запросы ICMP ECHO:

# sysctl net.ipv4.icmp_echo_ignore_all=1

Или с помощью брандмауэра:

# iptables -A INPUT -p icmp -j DROP --icmp-type 8

SYN-флуд. Один из распространенных способов не только забить канал связи, но и ввести сетевой стек операционной системы в такое состояние, когда он уже не сможет принимать новые запросы на подключение. Основан на попытке инициализации большого числа одновременных TCP-соединений через посылку SYN-пакета с несуществующим обратным адресом. После нескольких попыток отослать ответный ACK-пакет на недоступный адрес большинство операционок ставят неустановленное соединение в очередь и только после n-ой попытки закрывают соединение. Так как поток ACK-пакетов очень велик, вскоре очередь оказывается заполненной, и ядро дает отказ на попытки открыть новое соединение. Наиболее умные DoS-боты еще и анализируют систему перед началом атаки, чтобы слать запросы только на открытые жизненно важные порты. Идентифицировать такую атаку просто: достаточно попробовать подключиться к одному из сервисов. Оборонительные мероприятия обычно включают в себя:

Увеличение очереди «полуоткрытых» TCP-соединений:

# sysctl -w net.ipv4.tcp_max_syn_backlog=1024

Уменьшение времени удержания «полуоткрытых» соединений:

# sysctl -w net.ipv4.tcp_synack_retries=1

Включение механизма TCP syncookies:

# sysctl -w net.ipv4.tcp_syncookies=1

Ограничение максимального числа «полуоткрытых» соединений с одного IP к конкретному порту:

# iptables -I INPUT -p tcp --syn --dport 80 -m iplimit \
    --iplimit-above 10 -j DROP

UDP-флуд. Типичный метод захламления полосы пропускания, основанный на бесконечной посылке UDP-пакетов на порты различных UDP-сервисов. Легко устраняется за счет отрезания таких сервисов от внешнего мира и установку лимита на количество соединений в единицу времени к DNS-серверу на стороне шлюза:

# iptables -I INPUT -p udp --dport 53 -j DROP -m iplimit \
    --iplimit-above 1

HTTP-флуд. Один из самых распространенных на сегодняшний день способов флуда. Основан на бесконечной посылке HTTP-сообщений GET на 80-ый порт с целью загрузить web-сервер настолько, чтобы он оказался не в состоянии обрабатывать все остальные запросы. Часто целью флуда становится не корень web-сервера, а один из скриптов, выполняющих ресурсоемкие задачи или работающий с базой данных. В любом случае, индикатором начавшейся атаки будет служить аномально быстрый рост логов web-сервера.

Методы борьбы с HTTP-флудом включают в себя тюнинг web-сервера и базы данных с целью снизить эффект от атаки и отсеивание DoS-ботов с помощью различных приемов. Во-первых, следует увеличить максимальное число коннектов к базе данных одновременно. Во-вторых – установить перед web-сервером Apache легкий и производительный nginx, который будет кэшировать запросы и отдавать статику. Это решение из списка «must have», которое не только снизит эффект DoS-атак, но и позволит серверу выдержать огромные нагрузки. Небольшой пример:

# Увеличиваем максимальное количество используемых файлов
worker_rlimit_nofile 80000;
events {
    # Увеличиваем максимальное количество соединений
    worker_connections 65536;
    # Использовать эффективный метод epoll для обработки соединений
    use epoll;
}
http {
    gzip off;
    # Отключаем таймаут на закрытие keep-alive соединений
    keepalive_timeout 0;
    # Не отдавать версию nginx в заголовке ответа
    server_tokens off;
    # Сбрасывать соединение по таймауту
    reset_timedout_connection on;
}
# Стандартные настройки для работы в качестве прокси
server {
    listen 111.111.111.111 default deferred;
    server_name host.com www.host.com;
    log_format IP $remote_addr;
    location / {
        proxy_pass http://127.0.0.1/;
    }
    location ~* \.(jpeg|jpg|gif|png|css|js|pdf|txt|tar)$ {
        root /home/www/host.com/httpdocs;
    }
}

В случае необходимости можно задействовать nginx-модуль ngx_http_limit_req_module, ограничивающий количество одновременных подключений с одного адреса. Ресурсоемкие скрипты можно защитить от ботов с помощью задержек, кнопок «Нажми меня», выставления кукисов и других приемов, направленных на проверку «человечности».

Универсальные советы

Чтобы не попасть в безвыходное положение во время обрушения DDoS-шторма на системы, необходимо тщательным образом подготовить их к такой ситуации:

Все сервера, имеющие прямой доступ во внешнюю сеть, должны быть подготовлены к простому и быстрому удаленному ребуту (sshd спасет отца русской демократии). Большим плюсом будет наличие второго, административного, сетевого интерфейса, через который можно получить доступ к серверу в случае забитости основного канала.
ПО, используемое на сервере, всегда должно находиться в актуальном состоянии. Все дырки – пропатчены, все обновления установлены (простой как сапог совет, которому многие не следуют). Это автоматически оградит тебя от DoS-атак, эксплуатирующих баги в сервисах.
Все слушающие сетевые сервисы, предназначенные для административного использования, должны быть спрятаны брандмауэром ото всех, кто не должен иметь к ним доступ. Тогда атакующий не сможет использовать их для проведения DoS-атаки или брутфорса.
На подходах к серверу (ближайшем маршрутизаторе) должна быть установлена система анализа трафика (NetFlow в помощь), которая позволит своевременно узнать о начинающейся атаке и вовремя принять меры по ее предотвращению.

Добавь в /etc/sysctl.conf следующие строки:

# Защита от спуфинга
net.ipv4.conf.default.rp_filter = 1
# Проверять TCP-соединение каждую минуту. Если на другой стороне -
# легальная машина, она сразу ответит. Дефолтовое значение - 2 часа.
net.ipv4.tcp_keepalive_time = 60
# Повторить пробу через десять секунд
net.ipv4.tcp_keepalive_intvl = 10
# Количество проверок перед закрытием соединения
net.ipv4.tcp_keepalive_probes = 5

Следует отметить, что все приемы, приведенные в прошлом и этом разделах, направлены на снижение эффективности DDoS-атак, ставящих своей целью израсходовать ресурсы машины. От флуда, забивающего канал мусором, защититься практически невозможно, и единственно правильный, но не всегда осуществимый способ борьбы с таким видом атак заключается в том, чтобы «лишить атаку смысла». Если ты заимеешь в свое распоряжение действительно широкий канал, который легко пропустит трафик небольшого ботнета, считай, что от 90% атак твой сервер защищен. Еще более изощренный способ защиты основан на организации распределенной вычислительной сети, включающей в себя множество дублирующих серверов, подключенных к разным магистральным каналам. Когда вычислительные мощности или пропускная способность канала заканчиваются, все новые клиенты перенаправляются на другой сервер (или же постепенно «размазываются» по всем серверам по принципу round-robin). Это невероятно дорогая, но очень стойкая структура, завалить которую практически нереально.

Другое более-менее эффективное решение заключается в покупке дорогостоящих хардварных систем Cisco Traffic Anomaly Detector и Cisco Guard. Работая в связке, они могут подавить начинающуюся атаку, но как и большинство других решений, основанных на обучении и анализе состояний, дают сбои. Поэтому следует хорошенько подумать перед тем, как выбивать из начальства десятки тысячи долларов на такую защиту.

Кажется, началось. Что делать?

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

Наличие SYN-флуда устанавливается легко – через подсчет числа «полуоткрытых» TCP-соединений:

# netstat -na | grep ":80\ " | grep SYN_RCVD

В обычной ситуации их не должно быть совсем (или очень небольшое количество: максимум 1-3). Если это не так – ты атакован, срочно переходи к дропанью атакующих.

С HTTP-флудом все несколько сложнее. Для начала нужно подсчитать количество процессов Apache и количество коннектов на 80-ый порт (HTTP-флуд):

# ps aux | grep httpd | wc -l
# netstat -na | grep ":80\ " | wc -l

Значения, в несколько раз превышающие среднестатистические, дают все основания задуматься. Далее следует просмотреть список IP-адресов, с которых идут запросы на подключение:

# netstat -na | grep ":80\ " | sort | uniq -c | \
    sort -nr | less

Однозначно идентифицировать DoS-атаку нельзя, можно лишь подтвердить свои догадки о ее наличии, если один адрес повторяется в списке слишком много раз (да и то, это может говорить о посетителях, сидящих за NAT’ом). Дополнительным подтверждением будет анализ пакетов с помощью tcpdump:

# tcpdump -n -i eth0 -s 0 -w output.txt dst port 80 \
    and host IP-сервера

Показателем служит большой поток однообразных (и не содержащих полезной информации) пакетов от разных IP, направленных на один порт/сервис (например, корень web-сервера или определенный cgi-скрипт).

Окончательно определившись, начинаем дропать неугодных по IP-адресам (будет гораздо больше эффекта, если ты сделаешь это на маршрутизаторе):

# iptables -A INPUT -s xxx.xxx.xxx.xxx -p tcp \
    --destination-port http -j DROP

Или сразу по подсетям:

# iptables -A INPUT -s xxx.xxx.0.0/16 -p tcp \
    --destination-port http -j DROP

Это даст тебе некоторую фору (совсем маленькую; зачастую IP-адрес источника спуфится), которую ты должен использовать для того, чтобы обратиться к провайдеру/хостеру (с приложенными к сообщению логами web-сервера, ядра, брандмауэра и списком выявленных тобой IP-адресов). Большинство из них, конечно, проигнорируют это сообщение (а хостинги с оплатой трафика еще и порадуются – DoS-атака принесет им прибыль) или просто отключат твой сервер. Но в любом случае это следует сделать обязательно, эффективная защита от DDoS возможна только на магистральных каналах, в одиночку ты справишься с мелкими нападками, направленными на истощение ресурсов сервера, но окажешься беззащитным перед более-менее серьезным DDoS’ом.

Борьба с DDoS во FreeBSD

Уменьшаем время ожидания ответного пакета на запрос SYN-ACK (защита от SYN-флуда):

# sysctl net.inet.tcp.msl=7500

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

# sysctl net.inet.tcp.blackhole=2
# sysctl net.inet.udp.blackhole=1

Ограничиваем число ответов на ICMP-сообщения 50-тью в секунду (защита от ICMP-флуда):

# sysctl net.inet.icmp.icmplim=50

Увеличиваем максимальное количество подключений к серверу (защита от всех видов DDoS):

# sysctl kern.ipc.somaxconn=32768

Включаем DEVICE_POLLING – самостоятельный опрос сетевого драйвера ядром на высоких нагрузках (существенно снижает нагрузку на систему во время DDoS’а):

Пересобираем ядро с опцией «options DEVICE_POLLING»
Активируем механизм поллинга: «sysctl kern.polling.enable=1»
Добавляем запись «kern.polling.enable=1» в /etc/sysctl.conf

Пример ограничения подключений к web-серверу с помощью pf (файл pf.conf)

ext_if="fxp0"

pass in on $ext_if inet proto tcp to $ext_if \
    port www keep state (max 100, source-track rule, \
    max-src-nodes 50, max-src-states 10)

Пример ограничения подключений средствами индейца (файл httpd.conf)

Timeout 300
KeepAlive On
MaxKeepAliveRequests 32
KeepAliveTimeout 15

MinSpareServers 1
MaxSpareServers 4
StartServers 1
MaxClients 32

Крупнейшие ботнеты

Kraken – 400 тысяч компьютеров.
Srizbi – 315 тысяч компьютеров.
Bobax – 185 тысяч компьютеров.
Rustock – 150 тысяч компьютеров.
Storm – 100 тысяч компьютеров.
Psybot – 100 тысяч ADSL-маршрутизаторов, основанных на Linux.
Ботнет BBC – 22 тысячи компьютеров. Экспериментальный ботнет, созданный компанией BBC.

Cлед в истории

1997 год – DDoS-атака на web-сайт Microsoft. Один день молчания.
1999 год – «вне зоны действия» оказались web-сайты Yahoo, CNN, eBay и другие.
Октябрь 2002 – атака на корневые DNS-серверы интернета. На некоторое время были выведены из строя 7 из 13 серверов.
21 февраля 2003 года – DDoS-нападение на LiveJournal.com. Два дня сервис находился в парализованном состоянии, лишь иногда подавая признаки жизни.

Интеллектуальные системы

Интересную альтернативу решениям Cisco выпускает компания Reactive Networks. Их продукт под названием FloodGuard представляет собой аппаратный комплекс, состоящий из детекторов и исполнительных модулей. Детекторы, установленные на брандмауэрах, маршрутизаторах и свитчах, постоянно мониторят трафик и создают его профиль на основе таких параметров, как объем пакетов, источник, направление, тип и т.д. В случае возникновения аномалий детектор посылает все подробности о произошедшем исполнительным модулям, располагающимся на маршрутизаторах в разных сегментах сети. Получив сообщение от детектора, исполнительные модули начинают действовать: они отыскивают паразитный трафик в проходящих пакетах и, в случае удачи, оповещают об этом предыдущие по ходу трафика модули и посылают им инструкции по активации фильтров на маршрутизаторах. В результате перед потоком флуд-трафика должен образоваться заслон, который будет быстро перемещаться в сторону его источника.

Статья написана для журнала Хакер.

Не можете выбрать компьютер для дома? Тогда сайт cominftech.ru для вас. Все об информационных технологиях, обеспечение безопасности компьютера, помощь, советы, адреса магазинов.

Просто о сложном или разбираемся с SELinux

2011-10-25T17:46:15+00:00

SELinux снискала славу сложной в понимании и настройке системы безопасности, которая хоть и делает Linux намного более устойчивой к взлому операционной системой, но создает больше проблем, чем приносит решений. Такая точка зрения в корне не верна и в этой статье я покажу, что SELinux намного проще и удобнее в использовании, чем это кажется на первый взгляд.

Система SELinux (Security-Enhanced Linux - Linux с улучшенной безопасностью) была разработана министерством обороны США и всего за несколько лет стала стандартом в области систем контроля прав доступа. Она была включена в ядро Linux версии 2.6.0 и впервые появилась как полностью работающая из коробки система в дистрибутиве Red Hat Enterprise Linux 4. Впоследствии поддержка SELinux была интегрирована в такие дистрибутивы как Debian, OpenSUSE и Ubuntu, а дополнительные пакеты, активирующие систему, были добавлены во многие другие более или менее популярные дистрибутивы. Именно благодаря SELinux дистрибутиву RHEL5, работающему на серверах IBM, удалось получить сертификат безопасности EAL4 Augmented with ALC_FLR.3, который в то время имела лишь одна операционная система - Trusted Solaris.

SELinux существенно расширяет ядро Linux, делая операционные системы, построенные на его основе, пригодными к использования в сферах, где доступ к информации должен быть строго разграничен, а приложения, запускаемые пользователями, иметь определенный набор прав, который не выходит за рамки минимально необходимого. Это делает систему привлекательной для госучреждений и военных, однако кажется не совсем понятным зачем она нужна администраторам рядовых серверов, а уж тем более обычным пользователям (в Fedora SELinux по умолчанию включен). Сейчас я попытаюсь объяснить этот момент.

Зачем это нужно?

Создатели UNIX наделили свою ОС простым, но весьма гибким и красивом механизмом безопасности. В его основе лежат всем нам известные права доступа на файлы, которые определяют круг лиц (пользователей, процессов), способных выполнять какие-либо действия над файлами и каталогами. Например, мы можем создать исполняемый файл и выставить на него права доступа “-rwxr-xr-x”, что будет означать, что мы (то есть владелец файла), можем делать с ним все, что захотим, пользователи, входящие в нашу группу могут его читать и исполнять, а все остальные только исполнять.

Учитывая тот факт, что все устройства в UNIX представлены файлами, такой механизм позволяет не только четко разграничивать доступ пользователей (их приложений) к информации, но и к устройствам и даже некоторым функциями операционной системы (procfs и sysfs). Однако, у механизма прав доступа есть два серьезных недостатка:

Во-первых, их реализация слишком топорна. Она хорошо подходит для отделения процессов от конфиденциальной информации пользователей, но абсолютно не подходит для гибкого управления их возможностями. Например, чтобы дать какой-либо дисковой утилите (cfdisk, например) возможность модификации хранящейся на диске информации, мы можем либо разрешить полный доступ к диску группе, к которой принадлежит ее владелец, либо запустить ее с правами пользователя root. Как в первом, так и во втором случае мы создадим потенциальную брешь в безопасности: все остальные пользователи/приложения группы получат права доступа к диску или сама утилита получит наивысшие и безграничные права в системе. А что если нужно дать доступ не к модификации диска, а только к вызову определенных его функций (ioctl)? Здесь права доступа вообще не помогут.

Во-вторых, файлами в Linux представлены далеко не все ресурсы операционной системы. Огромное количество функций ядра скрыто в более чем трех сотнях системных вызовов, большая часть которых доступна для использования абсолютно всем процессам, а если процесс имеет права root, то его возможности вообще никак не ограничиваются. Если, к примеру, мы захотим запустить FTP-сервер на стандартном для него 21 порту, который доступен только процессам с правами root, нам придется всецело довериться его разработчику, так как работая от root, FTP-сервер будет способен делать абсолютно все и ошибка, найденная в его коде, даст взломщику полный контроль над системой. И это из-за простой потребности слушать привилегированный порт.

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

Как это работает?

Здесь я должен начать рассуждать о таких вещах как дискреционный и мандатный контроль доступа, RBAC, MCS и других околонаучных вещах. Однако, мое объяснение будет другим.

Понять принцип работы SELinux и заложенные в него идеи проще всего разобравшись с тем, что происходит во время его активации. Что делает SELinux для того, чтобы контролировать обращения процессов к ресурсам ОС? Концептуально можно выделить четыре шага:

1 Все субъекты (процессы) и объекты (файлы, системные вызовы и т.д.) взаимодействия помечаются с помощью специальных меток, называемых контекстом безопасности (процессы во время запуска, файлы - во время создания или установки ОС ( их метки хранятся в расширенных атрибутах ФС), системные вызовы - при компиляции модуля SELinux).

2 Когда субъект пытается произвести какое-либо действие в отношении объекта, информация об этом действии поступает к обработчику SELinux.

3 Обработчик смотрит на контексты безопасности субъекта и объекта и, сверяясь с написанными ранее правилами (так называемая политика), принимает решение о дозволенности действия.

4 Если действие оказывается правомочным (политика его разрешает), объект (программа) продолжает работать в обычном режиме, в противном случае он либо принудительно завершается, либо получает вежливый отказ.

В реальной ситуации все это выглядит примерно так: один из скриптов инициализации дистрибутива, имеющий метку initrc_t (на самом деле эту метку имеют порождаемые им процессы, но сейчас это не важно), запускает веб-сервер Apache с помощью файла /usr/sbin/httpd, который имеет метку httpd_exec_t. Как и все остальные действия, запрос на эту операцию поступает в SELinux, в правилах (политике) которого указано, что initrc_t не только имеет право запускать файл с меткой httpd_exec_t, но и то, что при запуске этого файла процесс и его потомки должны получить метку httpd_t. Теперь в системе появляется один или несколько процессов Apache, помеченных как httpd_t. Каждый из них будет подчинятся правилам SELinux, относящимся к этой метке, поэтому, если в политике указано, что httpd_t может получать доступ только к файлам, помеченным как httpd_sys_content_t и 80 порту, Apache не сможет нарушить эти правила (перевесив его на другой порт мы попросту получим ошибку запуска).

Откуда берутся правила? Их пишут люди, а точнее мантейнеры дистрибутивов, что тем не менее, не мешает системному администратору исправить их так, чтобы подогнать к своим потребностям. Обычно правила загружаются на первом этапе инициализации ОС, но с помощью особых приемов их можно подсунуть и в уже работающую систему (не перезагружать же сервер с аптаймом 1.5 года только для того, чтобы разрешить FTP-серверу ходить по симлинкам). Типичный объем файла политик SELinux для основных приложений и сервисов дистрибутива может содержать до нескольких сотен тысяч строк, поэтому, чтобы не обременять админов рутинной работой были созданы инструменты для их автоматической генерации с помощью обучения (например, утилита audit2allow позволяет составлять правила SELinux на основе лог-файлов подсистемы audit). В следующих разделах мы подробнее остановимся на этом вопросе, однако для начала нам следует разобраться с “политикой управления доступом на основе ролей”.

Управление доступом на основе ролей или RBAC

Само собой разумеется, что SELinux не смог бы так радовать военных, если бы в его основе лежали только метки, определяющие контекст безопасности, и механизм разделения доступа на их основе (кстати, это называется “мандатным управлением доступом” и многие ошибочно приписывают его SELinux). Из-за своей низкоуровневости такая система безопасности была бы слишком сложной в управлении и не гибкой, поэтому создатели SELinux снабдили ее еще одним уровнем доступа, именуемым “ролями”.

Когда мы говорили о метках SELinux, я намеренно упустил из виду одну важную деталь. На самом деле контекст безопасности (метка) состоит не из одного, а из трех компонентов (есть еще и четвертый компонент, но об этом пока не стоит задумываться): имени пользователя, роли и типа субъекта (тот самый компонент, который оканчивается на “_t”). Каждый пользователь SELinux (который может быть связан с учетной записью пользователя Linux, но обычно все Linux-пользователи отображаются в SELinux-пользователя unconfined_u) может выполнять несколько ролей, в рамках каждой из которых ему доступны несколько типов субъектов, а каждый субъект в свою очередь может иметь доступ к некоторому количеству объектов.

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

Любой Linux-дистрибутив, из коробки оснащенный SELinux, по умолчанию использует так называемую “целевую политику”, которая предполагает наличие всего нескольких общих SELinux-пользователей и ролей. Например, целевая политика Fedora и RHEL определяет только двух дефолтовых пользователей (на самом деле есть еще несколько специальных пользователей, но обычно они не используются) и две роли: пользователь system_u, роль system_r и пользователь unconfined_u, роль unconfined_r. Первые используются для запуска системных процессов во время инициализации системы, и в политике четко указано, что запускаемые пользователем system_u, который имеет роль system_r, приложения должны получать конкретный тип субъекта (например, httpd_t), определяемый типом объекта (файла), из которого они запускаются (например, httpd_exec_t). В их отношении действуют строгие правила ограничения, о которых мы говорили в предыдущем разделе.

Пользователь unconfined_u и роль unconfined_r предназначены для обычных Linux-пользователей. На последнем этапе инициализации системы запускается менеджер входа в систему (он работает в домене system_u:system_r:login_t), который принимает имя пользователя и его пароль и запускает шелл/графическую оболочку. Однако, вместо того, чтобы сохранить текущий контекст безопасности, либо изменить его на system_u:system_r:shell_t в соответствии с правилами политики SELinux (если бы такие были), он обращается к PAM-модулю pam_selinux, который сообщает SELinux, что запущенный менеджером входа процесс (шелл или оболочка) должен получить контекст unconfined_u:unconfined_r:unconfined_t. Смысл этого перехода в том, что целевая политика SELinux имеет правила, которые разрешают приложениям, работающим в этом контексте делать что угодно, в том числе запускать другие приложения. Однако, если пользователь запустит приложение, в контексте безопасности которого указан SELinux-пользователь system_u и тип, для которого в политике есть правила, процессы этого приложения будут ограничены в правах точно также, как если бы они были запущены во время инициализации.

Если говорить о контексте безопасности файлов, то здесь роли не используются в принципе и второе поле всегда равно object_r, а первое будет либо system_u, либо unconfined_u, если это файл, созданный пользователем.

Таким образом можно сказать, что при использовании целевой политики значимым полем контекста безопасности остается только тип субъекта/объекта, тогда как поля пользователь и роль просто определяют отношение SELinux к процессу (либо он находится под контролем правил, либо - нет).

Работаем с системой

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

1 SELinux должен быть включен. Глупо отключать SELinux только потому, что так рекомендуют делать многие сисадмины и пользователи. Работу штатных сервисов он нарушить не может, а если тебе нужно расширить возможности какого-либо приложения, это всегда можно сделать с помощью изменения мета-настроек или отключения проверок для определенного типа субъекта (позже я скажу как это сделать).

2 ‘-Z’ твой друг. Да, вся эта возня с контекстами безопасности и всем остальным может вывести из себя. Но есть множество инструментов, которые позволяют выяснить текущий контекст безопасности процессов и файлов:

$ id -Z
$ ps auxZ
$ ls -Z

найти файлы с нужным контекстом:

$ find /etc -context '*net_conf_t'

восстановить правильный контекст файла:

# restorecon -v /usr/sbin/httpd

и даже узнать каким должен быть контекст файла и сравнить его с текущим:

# matchpathcon -V /var/www/html/*

3 Скажи mv нет. Во время установки дистрибутива все файлы получают определенный контекст безопасности, а все файлы, созданные в процессе работы - контекст безопасности, определяемый правилами на основе родительского каталога (например, если создать файл внтури каталога /etc, его тип автоматически станет etc_t, а для файлов каталога /var/www/html - httpd_sys_content_t). Однако это работает только в отношении вновь созданных файлов. Во время перемещения файла с помощью mv его контекст сохраняется, что может привести к отказу в доступе (например, Apache не сможет получить доступ к файлу, если его тип не httpd_sys_content_t).

4 Маны наше все. В дистрибутивах Fedora и RHEL есть большое количество man-страниц, которые разъясняют все ограничения SELinux в отношении сервисов и демонов. Например, на странице httpd_selinux(8) описано в каком контексте безопасности работает Apache, какие у него есть полномочия и какие контексты должны иметь доступные ему файлы.

Теперь разберемся с тем, что нужно делать, когда SELinux начинает мешать. Обычно это происходит вследствие того, что админ пытается включить определенную функцию сервиса или как-то перенастроить его, а SELinux начинает сыпать на экран предупреждающие сообщения. Первое, что нужно сделать в этой ситуации, это проверить лог-файлы. Главный журнальный файл SELinux носит имя /var/log/audit/audit.log. Туда поступают “необработанные” сообщения, которые могут быть полезны другим приложениям, но трудны в чтении человеком. Поэтому существует второе место, куда поступают те же сообщения, но в гораздо более понятном формате. Это файл /var/log/messages, в нем сообщения могут выглядеть так:

# grep "SELinux is preventing" /var/log/messages

May 7 18:55:56 localhost setroubleshoot: SELinux is preventing httpd (httpd_t) "getattr" to /var/www/html/index.html (home_dir_t). For complete SELinux messages. run sealert -l de7e30d6-5488-466d-a606-92c9f40d316d

Здесь все должно быть понятно: SELinux запретил субъекту httpd_t (веб-сервер Apache) доступ к файлу /var/www/html/index.html на том основании, что тот имеет неправильный тип объекта (home_dir_t присваивается файлам, созданным в домашнем каталоге пользователя). Для получения более детальной информации SELinux рекомендует выполнить команду sealert -l бла-бла-бла. Эта команда выведет очень информативное сообщение, где будут описаны все обстоятельства произошедшего, причины, по котором они могли возникнуть, а также пути решения проблемы.

В нашем случае причина проста: админ переместил файл index.html из своего домашнего каталога с помощью mv, выставил на него нужного владельца и права, но забыл изменить контекст. Выхода из ситуации два. Либо присвоить файлу правильный контекст с помощью команды chcon:

# chcon -t httpd_sys_content_t /var/www/html/index.html

Либо заставить систему “сбросить” контекст всех файлов каталога:

# restorecon -v /var/www/html

После перезапуска Apache все должно быть Ok. Однако этот метод не сработает если мы захотим переместить корневой каталог Apache в другое место (например, в /www). Дело в том, chcon изменяет контекст только до следующего переиндексации с помощью restorecon, которая сбросит контекст файлов каталога /www до default_t (по правилам политики все каталоги, не имеющие родительского каталога, и их файлы получают такой тип). Поэтому мы должны изменить саму политику:

# semanage fcontext -a -t httpd_sys_content_t /www
# restorecon -v /www

Первая команда изменит политику так, чтобы дефлтовым типом для каталога /www и его содержимого был httpd_sys_content_t, а вторая сбросит контекст его файлов, так что они получат тот же тип (правила SELinux допускают, чтобы дефолтовые метки каталогов и их содержимого отличались, но для удобства semanage делает их одинаковыми).

Также semanage может быть использована для просмотра списка мета-правил:

# semanage boolean -l

С помощью мета-правил можно контролировать такие аспекты работы приложений как, например, возможность веб-сервера подключаться к удаленной базе данных (httpd_can_network_connect_db) или разрешение ftp-сервера читать файлы домашнего каталога пользователей (ftp_home_dir) и т.д. Такие правила группируют в себе большое количество низкоуровневых правил, что существенно упрощает жизнь сисадмина.

Чтобы включить/отключить то или иное правило можно использовать команду setsebool:

# setsebool httpd_can_network_connect_db on
# setsebool httpd_can_network_connect_db off

Указав флаг ‘-P’ можно сделать эти правила постоянными между перезагрузками. В самом крайнем случае semanage можно использовать для полного отключения проверок SELinux в отношении определенного субъекта:

# semanage permissive -a httpd_t

Включение производится с помощью похожей команды:

# semanage permissive -d httpd_t

Выводы

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

Ограниченные пользователи

Кроме SELinux-пользователя unconfined_u, который по дефолту присваивается всем юзерам системы, в целевой политике также описано несколько непривилегированных пользователей, которых можно использовать для создания гостевых учетных записей, процессы которых будут очень ограничены в правах (возможности и различия этих пользователей смотри в таблице “Дефолтовые пользователи SELinux”).

Чтобы создать такого пользователя достаточно выполнить следующую команду:

# useradd -Z xguest_u имя_юзера

Кроме этого можно сделать его дефолтовым, так что ограниченными будут все вновь созданные Linux-юзеры:

# semanage login -m -S targeted -s "xguest_u" -r s0 __default__

Посмотреть список текущих SELinux-юзеров можно так:

# /usr/sbin/semanage login -l

PS Еще один способ отключить SELinux для приложения:

# chcon -t unconfined_exec_t /usr/sbin/httpd

Статья написана для журнала Хакер.

Хотите купить canon eos 600d? Интернет-магазин prophotos.ru к вашим услугам. Здесь вы сможете найти нужный вам фотоаппарат, подобрать объектив и аксессуары, ознакомиться с отзывами и результатами тестов. Все в одном месте.

RIP Dennis

2011-10-13T15:56:10+00:00

Дэнис Ритчи, стоявший у истоков UNIX и языка Си умер в минувшие выходные. Об этом сообщил Роб Пайк на своей странице в Google+.

Эмуляция Linux во FreeBSD

2011-10-11T17:03:59+00:00

Несмотря на популярность и применимость в самых различных сферах, FreeBSD все же уступает Linux в одном немаловажном отношении - доступности программного обеспечения. Разработчики коммерческого ПО неохотно портируют свои продукты для FreeBSD, останавливаясь на ее гораздо более популярном конкуренте. К счастью, выход есть - эмуляция Linux ABI.

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

Пространство ядра

Для того чтобы научить ядро FreeBSD понимать исполняемые файлы Linux, достаточно подгрузить модуль linux.ko (kldload linux), содержащий все необходимые обработчики и альтернативную таблицу системных вызовов. После этого операционная система будет готова к принятию "чужого" кода. Для закрепления результата следует добавить строку linux_load="YES" в /boot/loader.conf (загрузка одновременно с ядром), либо linux_enable="YES" в /etc/rc.conf (загрузка во время инициализации системы).

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

option COMPAT_LINUX
option PSEUDOFS
option LINPROCFS
option LINSYSFS

Если сборка будет происходить для архитектуры amd64, то вместо COMPAT_LINUX следует указать строку COMPAT_LINUX32. Последние две строки указывают на то, что код Linux-реализаций файловых систем proc и sys также должен быть включен в ядро. Делать это не обязательно, каждая из них может быть собрана модулем.

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

Пространство пользователя

Исполнение бинарных файлов Linux происходит в изолированном окружении, которое располагается в каталоге /compat/linux. Чтобы программы могли работать в таком окружении, им требуется доступ ко всем необходимым библиотекам, конфигурационным файлам и специальным файлам, вроде тех, что находятся в каталоге /proc. Есть несколько способов обеспечить наличие этих файлов, но самый простой - установка из портов.

Существует несколько портов, разворачивающих окружение времени исполнения различных дистрибутивов Linux. В современных версиях FreeBSD средой исполнения по умолчанию является набор пакетов из дистрибутива Fedora Core 10 (emulators/linux_base-f10), также доступны коллекции пакетов из дистрибутива Gentoo (linux_base-gentoo-stage3). По большому счету неважно, какой из них использовать. Необходимость в переключении на окружение другого дистрибутива может возникнуть только в случае, если программа откажется работать в среде, установленной в данный момент.

Установить Linux-окружение также просто как и любую программу:

# cd /usr/ports/emulators/linux_base-fc4
# make install clean

После этого каталог /compat/linux превратится в локальную версию дистрибутива Linux. Далее необходимо обеспечить доступ к виртуальным файловым системам, иначе некоторые Linux-софтины откажутся работать. Открываем файл /etc/fstab и добавляем в него следующие строки:

none /compat/linux/proc linprocfs rw 0 0
none /compat/linux/sys linsysfs rw 0 0
none /compat/linux/dev devfs rw 0 0

Обратите внимание, что последняя строка монтирует родную devfs FreeBSD в Linux-окружение. Нужно это для работы звука через OSS, интерфейс которого одинаков во FreeBSD и Linux.

После того как операция по модификации файла /etc/fstab будет закончена, набираем «mount –a», чтобы изменения вступили в силу. Это все, теперь внутри FreeBSD есть самый настоящий Linux. В него даже можно войти, набрав от имени суперпользователя следующую команду:

# chroot /compat/linux /bin/bash

Linux-софт теперь должен запускаться и корректно работать. Это относится не только к простым программам, вроде xcalc, но и к гораздо более комплексным приложениям: Quake4, UT2004, Adobe Flash Plugin. Среда гарантирует, что программа будет работать с такой скоростью, как если бы она была запущена в настоящем Linux.

На закуску: список Linux-специфичных портов:

emulators/linux-ePSXe
sysutils/linux-nero
emulators/linux-vmware-toolbox6
games/linux-americasarmy
games/linux-darwinia-demo
games/linux-doom3
games/linux-enemyterritory
games/linux-gorky17-demo
games/linux-majesty-demo
games/linux-quake3
games/linux-quake4
games/linux-savage
games/linux-steam
games/linux-unrealgold
games/linux-ut
games/linux-ut2003-demo
games/linux-ut2004-demo
games/linux-worldofgoo-demo
multimedia/linux-realplayer
www/linux-f10-flashplugin10

Кстати, окружение Linux можно не устанавливать, а просто примонтировать файловую систему установленного на соседнем резделе Linux-дистрибутива.

Статья написана для журнала Хакер.

CDE или портабельные приложения 2

2011-09-27T13:03:04+00:00

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

CDE (Code, Data, and Environment) отличается от AppImage в первую очередь тем, что использует совершенно иной подход к сборке этих самых портабельных приложений. Если инструментарий, предназначенный для создания AppImage был простым (и плохо написанным) скриптом, который просто перегонял Deb-пакеты в запускаемые ISO-образы (да, именно так), которые включали в себя все файлы программы, а также файлы всех его зависимостей, перечисленных в манифесте пакета, то инструмент сборки CDE-пакетов - это программа, которая анализирует приложение прямо во время его исполнения и помещает в пакет любые файлы, к которым оно обращалось (сделано это с помощью банального ptrace).

Преимущество такого подхода в том, что он делает CDE по-настоящему полезным инструментом, а не безделушкой из разряда "proof of concept", которым по сути и был AppImage. Например, я хочу держать на флешке набор своих любимых приложений, да так чтобы они работали абсолютно также как на моем десктопе и имели те же настройки. Применив AppImage мне бы потребовалось еще долго пилить получившееся пакеты, чтобы добавить в них все мои настройки и файлы. Вручную это сделать было бы гораздо труднее. Но если я воспользуюсь CDE, все что мне понадобиться сделать, это просто запустить каждую программу под управлением этого инструмента и положить получившийся каталог на флешку:

$ cde chromium

Откроется окно Chromium, которое можно со спокойной душой тут же закрыть. Во время запуска приложения CDE проанализирует зависимости программы, соберет их в одном месте в каталоге cde-package и создаст скрипт, подготавливающий максимально приближенное к оригиналу окружение (включая все переменные окружения).

Теперь я просто копирую каталог cde-package на флешку:

$ cp -R cde-package /media/флешка

Беру ее с собой, вставляю в другой компьютер и спокойно запускаю:

$ /media/флешка/cde-package/chromium.cde

Кстати, сам CDE тоже самодостаточная программа, установить которую очень просто:

$ wget https://github.com/downloads/pgbovine/CDE/cde_2011-08-15_32bit -O cde
$ chmod +x cde

Для установки 64-битной сборки достаточно заменить 32bit на 64bit.

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

$ export LD_ASSUME_KERNEL=2.4.1
$ cde-package/приложение.cde

Ищете выгодный способ обмена WebMoney - Paxum? Тогда сервис мониторинга обменников BestChange.ru то, что вам нужно.