Локальная безопасность
Начнем с банальных вещей, о которых многие почему-то забывают. Никогда не работай под рутом, используй эту учетную запись только в случае крайней необходимости. Для повседневной работы используй непривилегированную учетную запись (например, admin). Во многих справочных материалах это не объясняется. А нужно это вот зачем: команда rm –r рекурсивно удаляет данные с диска. Если же ты случайно введешь ее под рутом (хотелось бы посмотреть на человека, который способен случайно под рутом ввести rm –r :)) то эта команда удалит все, тогда как под обычным пользователем основные системные файлы сохранятся. Возьмем более жизненный пример: некоторые вредоносные Java-апплеты могут получить твои права доступа и использовать их для атаки - а это случай не такой уж и редкий. Идем дальше. В противовес команде для выполнения административных задач – su, ты можешь использовать другую – sudo. Ее преимущество перед su - возможность работы без ввода рутного пароля. В конфигурационный файл /etc/sudoers прописываются команды, хосты и пользователи, которые эти команды могут выполнять. Например, в файле /etc/sudoers есть такая запись:
admin ALL=(ALL) ALL
Это значит, что пользователь admin может выполнять все команды на всех хостах от имени любого пользователя. О списке всех полезных опций sudo читай в мануале: man sudo. Теперь поговорим о правах доступа, точнее, о специальных правах доступа. Их два:
SGID (установить идентификатор группы - 2000)
SUID (установить идентификатор пользователя - 4000)
О том, что программы с такими правами доступа опасны, знают все (или почти все), однако не все знают, почему они опасны. Обычно программа выполняется с правами юзера, запустившего ее. Но SUID-программа выполняется с правами ее владельца. Это не страшно, если ее владельцем является обычный юзер, но что, если ее владельцем станет root? А будет вот что: если в программе есть ошибки (читай - баги), то непривилегированный юзер может получить привилегии рута. Поэтому сначала стоит проверить, так ли уж нужен программам этот бит, и если все-таки нужен - внимательно следить за ними. А поможет в этом программа sXid - программа для контроля за SUID/SGID программами. Запускаемая из cron, эта программа отслеживает любые изменения в suid’ных программах и папках. После ее инсталляции можно забыть о проблеме suid’ных файлов раз и навсегда. Скачиваем здесь: www.mirrors.wiretapped.net/security/host-intrusion-detection/sxid/sxid_4.0.2.tar.gz
Устанавливаем:
make install &&
install-log sxid
Конфигурация хранится в файле /etc/sxid.conf, однако редактировать там ничего не надо - по умолчанию даны оптимальные установки. Теперь прописываем вызов sxid в cron, если не хотим каждый день запускать ее вручную.
Анализируем файлы
Анализ файлов регистрации событий является одной из важнейших и одновременно одной из самых нудных задач администратора. В настольной системе дневной объем лог-файлов не такой большой, и их можно просмотреть вручную. Однако на постоянно включенном сервере дневной объем лог-файлов может составлять до нескольких мегабайт, и в этом случае их просмотр будет отнимать много времени. К счастью, существуют программы для автоматизации ревизии лог-файлов, такие как logcheck. Logcheck - программа для автоматического запуска и проверки лог-файлов на предмет событий безопасности и необычной активности. Она содержит программу logtail, которая запоминает последнюю позицию, считанную из лог-файла, и использует ее при следующем запуске для получения новой информации.
Скачиваем: www.psionic.com/products/logsentry.html. Перед компиляцией необходимо поправить Makefile, внеся следующие изменения:
INSTALLDIR=/etc/logcheck
INSTALLDIR_SH=/usr/local/bin
TMPDIR=/etc/logcheck/tmp
Кроме того, 67 строка должна выглядеть так:
@if [ ! -d $(TMPDIR) ]; then /bin/mkdir -p $(TMPDIR); fi
Устанавливаем:
make linux &&
install-log logcheck
Теперь надо изменить переменные в основном скрипте - /usr/local/bin/logcheck.sh.
Внеси следующие изменения:
TMPDIR=/etc/logcheck/tmp
HACKING_FILE=/etc/logcheck/logcheck.hacking
VIOLATIONS_FILE=/etc/logcheck/logcheck.violations
VIOLATIONS_INGORE_FILE=/etc/logcheck/logcheck.violations.ignore
IGNORE_FILE=/etc/logcheck/logcheck.ignore
Также необходимо изменить пути к лог-файлам. По умолчанию в LFS все события фиксируются в файле /var/log/sys.log, поэтому закомментируй все, что относится к Red Hat (строки 169-171), и добавь следующее:
#LFS-3.3
$LOGTAIL /var/log/sys.log > $TMPDIR/check.$$
Все, скрипт готов к употреблению. Пропиши его в cron для запуска каждый час и получай отчет по почте!
Шифрование
Теперь займемся поддержкой шифрования. OpenSSL - некоммерческая реализация протоколов SSL (Security Sockets Layer) и TLS (Transport Layer Security) с полной криптографией. Скачиваем: www.openssl.org/source/openssl-0.9.7.tar.gz.
Устанавливаем:
perl util/perlpath.pl /usr/bin
После этого надо отредактировать файл Configure для оптимизации. В строке 331 замени опцию -m486 на -march=i686 -mcpu=i686 для оптимизации.
./Configure linux-elf -DSSL_FORBID_ENULL --prefix=/usr --openssldir=/etc/ssl &&
make &&
make install &&
install-log openssl
OpenSSL, как ты знаешь, используется для поддержки шифрования почти во всех программах - начиная от SSH и заканчивая почтовыми клиентами. Ни для кого не секрет, что программа telnet, призванная решать ежедневные административные задачи, передает данные в открытом виде, что делает их доступными для электронного прослушивания (sniffing). Программа SSH, которая была создана для замены программ telnet, rlogin, rsh, rexec полностью решает эту проблему, шифруя передаваемые данные. Кстати, раз уж речь зашла об r-программах, поделюсь своими наблюдениями. rlogin читает файл .rhosts, который находится в домашней директории и содержит ip-адреса машин, с которых возможен вход без пароля. На первый взгляд это удобно, но при подмене ip-адреса (spoofing) атакующий может получить шелл. Об этом написано во всех книгах по безопасности, об этом не раз писал и X. Однако во всех дистрибутивах Linux эти программы устанавливаются по умолчанию. Спрашивается - зачем? Дистрибутивы тащат за собой софт, который повсеместно не используется уже несколько лет. Отсюда получается большой объем системы и необходимость начинать настройку безопасности с удаления старых неиспользуемых программ. OpenSSH - это свободно распространяемая реализация SSH.
Скачиваем: ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-3.5p1.tar.gz.
Устанавливаем:
./configure --prefix=/usr \
--sysconfdir=/etc/ssh \
--with-ipv4-defaults \
--with-md5-passwords \
--with-pam &&
make &&
make install &&
install-log openssh
Создаем файл /etc/pam.d/sshd:
#Begin /etc/pam.d/sshd
auth required pam_stack.so service=system-auth
auth rquired pam_nologin.so
account required pam_stack.so service=system-auth
password required pam_stack.so service=system-auth
session required pam_stack.so service=system-auth
session required pam_limits.so
#End /etc/pam.d/sshd
Если ты хочешь открыть на своей машине ssh-сервер, в /etc/rc.d/init.d создай скрипт:
#!/bin/sh
source /etc/sysconfig/rc
source $rc_functions
case "$1" in
start)
echo "Starting SSH... "
loadproc sshd
;;
stop)
echo "Stopping SSH... "
killproc sshd
;;
restart)
$0 stop
$0 start
;;
*)
echo "Usage: $0 {start|stop|restart}"
exit 1
esac
Остается лишь сделать на него символические ссылки в директориях rcN.d.
Tripwire
Средняя инсталляция Linux включает в себя порядка 20000 файлов. Уследить за всеми довольно трудно. Для решения этой проблемы была создана программа tripwire. При первом запуске она сканирует диск и создает базу системных файлов, цифровой отпечаток системы в безопасном состоянии. Настройка tripwire для LFS - процесс очень долгий. Дело в том, что в конфигурационном файле прописываются файлы, за которыми надо следить. По умолчанию в нем прописаны файлы для Red Hat. В LFS файлов намного меньше, да и расположение порой другое, поэтому на подгонку файла конфигурации может уйти довольно много времени. Скачиваем: www.tripwire.org/files/tripwire-2.3-47.bin.tar.gz.
Это готовые бинарники, не требующие компиляции. Для установки надо запустить инсталляционный скрипт install.sh, но сначала нужно поправить файл install.cfg. Tripwire может посылать отчеты по почте, поэтому в файле install.cfg надо отредактировать переменную TWMAILMETHOD. По умолчанию используется метод SENDMAIL. Если он тебя устраивает, то надо поправить путь к sendmail - переменную TWMAILPROGRAM. Значение по умолчанию - /usr/lib/sendmail -oi -t. Есть и альтернативный метод - через хост. В этом случае закомментируй все относящееся к методу SENDMAIL и раскомментируй метод SMTP:
TWMAILMETHOD=SMTP
TWSMTPHOST="mail.domain.com"
TWSMTPPORT=25
После этого будут выведены значения опций, которые надо подтвердить. Затем tripwire скопирует файлы и начнет создавать ключи, для чего нужно ввести парольную фразу. Парольная фраза отличается от пароля широтой выбора. Она может быть любой длины и содержать пробелы. Сначала нужно ввести парольную фразу для ключевого файла, а затем - для локального ключевого файла. После генерации ключа будет создан файл конфигурации, и tripwire запросит парольную фразу для сайта.
После окончания установки конфигурационные файлы будут находиться в /etc/tripwire.
Теперь надо настроить файл политики /etc/tripwire/twpol.txt. Однако tripwire использует не этот файл. Настоящий файл политики зашифрован и называется tw.pol. После некоторых исправлений в файле twpol.txt надо сгенерить tw.pol:
twadmin --create-polfile /etc/tripwire/twpol.txt
После этого надо ввести парольную фразу и будет сгенерирован зашифрованный файл политики.
Теперь надо сгенерировать базу данных tripwire:
tripwire --init
По запросу надо ввести локальную парольную фразу, и начнется генерация базы. Вот тут-то и проявятся ошибки в файле политики:
..................
### Warning: File system error.
### Filename: /bin/somefile
### No such file or directory
### Continuing
Записав все ошибки, надо исправить файл twpol.txt и опять попробовать сгенерировать базу. После всего этого гимора, база должна сгенериться без ошибок. После первого запуска tripwire сохранит снимок всей системы, который будет использоваться как эталон при последующих проверках. Проверка выполняется с помощью следующей команды:
tripwire --check
Результатом проверки будет подробный отчет о файловой системе - количество добавленных, удаленных, модифицированных файлов и оценка их критичности. После подгонки файла политики, файлы twpol.txt и twcfg.txt необходимо удалить. Однако я все же рекомендую удалить текстовые файлы с сервера и хранить их на внешнем носителе – мало ли, вдруг тебе понадобится их модифицировать.
Сетевая безопасность
Iptables - пакетный фильтр, брандмауэр, созданный на основе ядра Linux. Обычно брандмауэр ставят на маршрутизаторе, который перенаправляет пакеты согласно правилам фильтрации. Однако им можно защитить и обычную рабочую станцию. Основными данными при фильтрации являются ip-адреса отправителя и получателя, порты отправителя и получателя, протокол. На основе этих данных можно составить цепочки правил брандмауэра. Скачиваем: www.netfilter.org/.
Для установки iptables необходимы исходники ядра. Устанавливаем:
make KERNEL_DIR=/usr/src/linux &&
make install KERNEL_DIR=/usr/src/linux &&
install-log iptables
После этого надо перекомпилить ядро с поддержкой iptables. В секции Networking options включи опцию Network packet filtering (replaces ipchains). После этого в этой же секции появится пункт IP: Netfilter Configuration. Заходи в него и включи опцию IP tables support. Остальное - по вкусу и желанию. Затем компиль ядро, добавляй в LILO и перегружайся. Далее надо создать скрипт, содержащий цепочки. Создай файл /etc/rc.d/rc.firewall и пиши в него:
#!/bin/sh
IPTABLES=/usr/local/sbin/iptables
# Для начала очищаем цепочки от старых правил
$IPTABLES -F INPUT
$IPTABLES -F OUTPUT
$IPTABLES -F FORWARD
# А зачем нужна эта строка - поймешь дальше
/etc/rc.d/rc.firewall-blocked
# End /etc/rc.d/rc.firewall
Этот скрипт очищает цепочки от старых правил и подгружает файл rc.firewall-blocked. Существует множество документов по пакетным фильтрам. Один из лучших - книга Р. Зиглера "Брандмауэры в Linux". На русском языке она есть только для ipchains, в английском варианте есть вторая редакция - по iptables. Защититься от сканирования портов и от последующих атак нам поможет IDS. IDS - Intrusion Detective System - система обнаружения атак в реальном времени. При коннекте IDS рассматривает трафик на предмет вредоносных действий и в случае их обнаружения принимает определенные меры.
Скачиваем: www.psionic.com/products/.
Устанавливаем:
make linux &&
make install
Теперь правим конфигурационный файл /usr/local/psionic/portsenrty/portsentry.conf. Будем запускать portsentry в расширенном режиме обнаружения скрытого сканирования, поэтому в секции Port Configuration ничего редактировать не надо. В секции Ignore Options исправь:
BLOCK_UDP="2"
BLOCK_TCP="2"
Это значит, что при обнаружении сканирования будет выполнена внешняя команда, поэтому в секциях Dropping Routes и TCP Wrappers все закомментируй, а в секции External Command пиши:
KILL_RUN_CMD="/usr/local/psionic/portsentry/add_rule $TARGET$"
Теперь создай файл /usr/local/psionic/portsentry/add_rule и пиши в него:
#!/bin/sh
echo "/usr/local/sbin/iptables -I INPUT -s" $1 " -j DROP" >> /etc/rc.d/rc.firewall-blocked
/etc/rc.d/rc.firewall
Этот скрипт будет добавлять запрещающие правила в файл rc.firewall-blocked и перезапускать брандмауэр. PortSentry - одна из самых простых IDS, однако это не значит, что она неэффективна. У меня она ловила порядка 10 попыток сканирования с разных ip в сутки.
|