Исследование рівня безпеки ОС Linux

Запровадження 8.

1. Основні поняття комп’ютерної безпеки 10.

2. Локальна й мережеву безпеку Linux 15.

2.1. Користувачі і паролі 18.

2.2. Особливості файлової системи Linux 24.

2.2.1. Права доступу 24.

2.2.2. Атрибути файлів 29.

2.2.3. Механізм квот 33.

2.3. Бібліотека PAM 36.

2.4. Брандмауэр 48.

2.5. Глухе управління 57.

3. Кошти посилення безпеки в Linux 63.

3.1. Linux ACLs 63.

3.2. LIDS 65.

3.3. AIDE 71.

4. Техніка безпеки 74.

Укладання 80.

Список літератури 82.

Додаток 83.

Постійно зростання інтересу до гарантування безпеки різних мережевих ОС, а особливості до UNIX-подобным системам, таки спонукав мене вибрати саме цієї теми роботи. Проблема інформаційну безпеку, починаючи з появи потреби у ній, постійно тривожить уми сотні тисяч чоловік, примушуючи їх удосконалювати засоби її. Стосовно проблем безпеки інформаційних систем написано дуже багато книжок і статей, щодня виходять нариси, у яких повідомляється то продуктах, вдосконаленні існуючих систем безпеки, описуються по кроків засоби захисту від різних вторгнень, методи усунення наслідків. Ця тема постійно розвивається, тож до ній будь-коли згасне. Проблема інформаційну безпеку буде актуальною до того часу, поки існують інформація, яку треба захистити від стороннього глаза.

Завданням даної роботи є підставою огляд коштів як стандартних, не зовсім, що надає операційна система Linux для безпечного функціонування, безпечної роботи користувачів, і навіть схоронності конфіденційної комп’ютерної інформації, для зберігання якої ця ОС може використовуватися. Діяльність зачіпаються як питання, мають безпосередній стосунок до гарантування безпеки ОС Linux. Оскільки Linux — мережна ОС, і основним її призначенням є робота у мережі, було б неправильним залишити поза увагою питання мережевий безопасности.

Робота поділена чотирма частини: перша частина є теоретичним оглядом основних термінів комп’ютерної безпеки; у другій частині розглядаються аспекти локальної мережі й мережевий безпеки системи; третя частина є оглядом додаткові засоби, наданих розробниками світу UNIX контролю, реєстрацію ЗМІ й запобігання загрозам безпеки ОС Linux і чверть є додатковий розділ, у якому розглядається техніка безпечної роботи з персональним комп’ютером і монитором.

1. Основні поняття комп’ютерної безопасности.

У різних категорій людей слово «безпеку» викликає свої асоціації. Є безліч різновидів цього терміна, пов’язані з різними сферами діяльності. Наприклад, державна безпеку або ж безпека життєдіяльності, політична чи будівельна безпеку. Взагалі таких різновидів дуже багато, у разі до цього терміну пред’являються специфічні конкретної роду діяльності вимоги, які від решти. Узагальнене ж визначення терміна «безпеку» можна сформулювати так: безпеку — це набір засобів і вимог, вкладених у запобігання заборонених дій, виконання яких можуть призвести до небажаним последствиям.

Термін «інформаційна безпеку» з’явився порівняно недавно, з розвитком обчислювальної техніки і ЕОМ. Інформаційна безпеку включає у собі крім безпеки використовуваного програмного забезпечення, також безпеку апаратних коштів, безпеку каналів зв’язку й багато другое.

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

Якщо є заборона, з’явиться ще й людина, який намагатиметься до його порушення! З розвитком інформаційних технологій і запровадженням комп’ютера практично у всі сфери діяльності з’явилися люди, звані «кракеры» (від анг. cracker — «зломщик комп’ютерних мереж, і програм»), які різними хитрощами і нестандартними методами намагаються з єдиною метою власної вигоди отримати не санкціонованого доступу до інформації, яка їм не призначена. Часом ця призводить до плачевним наслідків для власника цієї інформації. Тоді й виникла потреба у боротьби з «інформаційними шкідниками». Розробив цілі комплекси програм посилення інформаційну безпеку і з кракерами. А оскільки будь-яким электронно-вычислительным комплексом управляє певна ОС, то, відповідно, задля забезпечення безпеки системи загалом слід подбати про безпеку самої ОС.

Кожен виробник по-своєму подивився безпеку своєї ОС. У результаті одні системи виявилися досить захищеними, захист інших обійти було лише, а треті виявилися практично беззахисними перед зломщиками. Ступінь захищеності ОС Linux — із ще однією UNIX-подобной ОС реального часу, у цієї работе.

Вивчаючи безпеку ОС, мушу торкнутися теорії комп’ютерної безпеки. Теорія комп’ютерної безпеки оперує трьома основними поняттями: загроза, вразливість і атака.

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

Уразливість комп’ютерної системи — це такий невдала або зовсім коректна її характеристика, що представляє можливим виникнення загрози. Уразливості таки є причиною виникнення неприємних ситуаций.

До уязвимостям можна віднести такі стану інформаційних систем:

1. Недосконалість використовуваного програмного обеспечения.

Програмне забезпечення написано людиною, а людина схильна допускати помилки. Під час створення програмного продукту простежити всі системи зв’язку і можливі помилки практично неможливо, коли над проектом працює велике громадян України. Творці програмних продуктів намагаються якнайкраще оптимізувати код програми розвитку й позбавити його від власних помилок, але, тим щонайменше, передбачити всіх можливих ситуацій неможливо. Іноді такі недоробки не несуть ніяких критичних наслідків самої програми чи даних, які вона оперує, але буває, що вказують використовувати програму цілях, відмінних тих, котрим вона створювалася спочатку, ми інколи з дуже серйозні наслідки (псування даних, наприклад). Такі недоробки у програмі зазвичай називають «дырами».

Ще існує поняття, як «люк». Люком називають спеціальні комбінації дій над програмою, які дозволяють обійти деякі етапи виконання. Зазвичай люки використовуються програмістами в розробці й тестуванні програм із єдиною метою обходу вже перевірених блоків і наприкінці повинні «закриватися», тобто програмний код, відповідальний за люк, повинен бути вивели із готової програми. І те, що має, робиться який завжди. Програміст просто може забути про люк, внаслідок люк залишається в готової програмі і може становити загрозу для правильного выполнения.

2. Неправильна настроювання програмного обеспечения.

Безпека системи великою мірою залежить від правильної настройки програмного забезпечення, встановленого у ній. За правильну настроювання програм, встановлених на користувальному комп’ютері, відповідає сам користувач комп’ютера (зазвичай, його власник), за правильну настроювання програм, тож сервісів, працівників спеціалізованому комп’ютері, обслуговуючому запити користувачів (сервері), відповідає адміністратор. У обох випадках ці фізичні особи несуть повну відповідальність за схоронність даних, і нормальне функціонування програм на обслуживаемом комп’ютері. Від, наскільки правильно налаштоване ту чи іншу програмне забезпечення, може залежати, отримає зловмисник доступу до комп’ютера чи нет.

Атака на комп’ютерну систему — це алгоритм дій, з допомогою яких може бути здійснений пошук уязвимостей і їх використання із єдиною метою здійснення угрозы.

Існують три основні види загроз:. Погрози розкриття. Погрози цілісності. Погрози відмови від обслуживании.

Загроза розкриття у тому, що набуває розголосу тому, кому було б її знати. У термінах комп’ютерної безпеки загроза розкриття має місце щоразу, коли отримано доступом до деякою конфіденційної комп’ютерної інформації, що зберігається у обчислювальної системі чи переданої від однієї системи в іншу. Іноді замість слова «розкриття «використовуються терміни «крадіжка «чи «витік » .

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

Загроза відмови від обслуговуванні виникає щоразу, коли час деяких дій блокується доступом до деякому ресурсу обчислювальної системи. Реально блокування то, можливо постійним, щоб запитуваний ресурс ніколи було отримано, чи її може викликати лише затримку цього ресурсу, досить тривалу у тому, щоб він став непотрібним. У разі кажуть, що ресурс исчерпан.

Вывод.

У цьому главі було здійснено огляд основних термінів комп’ютерної безпеки, розглянуті такі поняття, як загроза безпеки, вразливість системи, атака й на систему, описані основні види атак.

2. Локальна й мережеву безпеку Linux.

Linux є мережевий ОС, тому провести чітку межу між локальної мережі й мережевий безпекою дуже складно. Але, оскільки комп’ютер, на якому встановлено ОС Linux, може бути як у вигляді користувальницького комп’ютера, і у ролі серверу, підключення його до мережі не гарантується. За відсутності мережі недоречно казати про мережевий безпеки, оскільки мережевий погрози на принципі немає. Отже, поділ загальної безпеки системи на дві складові цілком целесообразно.

Зважаючи на це, можна дійти невтішного висновку, що локальна безпеку є обов’язковою практично у разі, крім, коли до комп’ютера має доступ лише одна людина — його власник. Мережевий ж безпеку є актуальним лише у разі, коли комп’ютер з встановленої у ньому Linux має вихід мережу. Мережевий безпеку є дополняющим ланкою локальної безпеки, які спільно визначають загальну безпеку системи загалом. У принципі так, локальну безпеку вважатимуться останнім бар'єром у спільній безпеки системы.

Локальна безпеку — це правила, міри і зусилля, створені задля захист системи зсередини, від локальних пользователей.

ОС Linux є повноцінної многопользовательской системою із простої і розподіленої архітектурою. Архітектура ОС Linux приведено малюнку 2.1.

Рис. 2.1. Структура ОС Linux.

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

То навіщо ж необхідно убезпечити систему від локальних пользователей?

Щоб відповісти це питання спочатку розглянемо, але це бачиться можливим користувачеві, який має доступ в систему.

— Після входу до системи користувачеві виділяється велика частина машинних ресурсів (дискового простору, оперативної пам’яті, процесорного часу й таке інше). Добре, якщо ОС спочатку налаштована правильне поділ ресурсів. Якщо ж немає? Досить одному користувачеві запустити два-три «важких» програм, як час очікування й інших програм навіть у потужної машині може вийти на межу допустимого.

— Існують програми, що має запускати лише суперкористувач (користувач root). Зазвичай із допомогою цих програм здійснюється настроювання системних параметрів ОС, неправильна конфігурація яких може негативно позначитися їхньому працездатності. Випадковий запуск такий програми звичайним користувачем можуть призвести до фатальним наслідків для всієї системи в целом.

— «Гуляючи» з дерева каталогів на жорсткому диску, користувач може потрапити до ті частини, у якій йому не належить (наприклад, до каталогу, де зберігаються файли інших користувачів). Особисті файли кожного користувача мають бути доступні йому тільки Мариновському, якщо, звісно, вона сама не вирішить иначе.

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

Тепер на, які ж засоби надає система Linux для забезпечення локальної безопасности.

2.1. Користувачі і пароли.

Користувач — людина, користується ресурсами й потенційними можливостями, що йому надає той чи інший сервіс. Користувач зобов’язаний знати всіх аспектів функціонування цих сервісів, усе, що він повинен знати — це як користуватися ими.

У Linux кожен користувач має власний унікальний числової ідентифікатор, яким він ідентифікується у системі. Цьому ідентифікатору ще зручною роботи відповідає ім'я користувача. Наприклад, для привілейованого користувача root зарезервований нульової идентификатор.

Усі імена користувачів Linux відповідні їм ідентифікатори зберігаються у спеціальному файлі passwd. Цей файл міститься у каталозі etc, який, своєю чергою, перебуває у кореневому каталозі системи /. Файл має звичайну текстову форму.

Приклад файла користувальних імен passwd. root: x:0:0:root:/root:/bin/bash bin: x:1:1:bin:/bin:/sbin/nologin daemon: x:2:2:daemon:/sbin:/sbin/nologin sync: x:5:0:sync:/sbin:/bin/sync mail: x:8:12:mail:/var/spool/mail:/sbin/nologin uucp: x:10:14:uucp:/var/spool/uucp:/sbin/nologin ftp: x:14:50:FTP User:/var/ftp:/sbin/nologin.

Кожна запис у тому файлі розділена двокрапками на майже 7 частей:

1. Ім'я користувача. Це полі містить ім'я користувача. Для ОС байдуже, яке ім'я має користувач, система орієнтується на ідентифікатор, а ім'я грає, мабуть, лише інформаційне значення в людини, працював у системе.

2. Поле пароля. Це полі ранніх версіях Linux містив зашифрований пароль, тепер, коли технологія тіньових паролів, у тому полі просто ставиться x. Практичного застосування це полі не имеет.

3. Ідентифікатор користувача (UID). У системі Linux кожен користувач має унікальний ідентифікаційний номер, який однозначно визначає її у системі. Цей номер використовують у різноманітних цілях, наприклад, за умови встановлення прав доступу на файли. Права доступу будуть розглянуті наступного разделе.

4. Ідентифікатор групи, до якої підключено цей користувач (GID). Концепція груп розглядатиметься у таких разделах.

5. Поле коментарю. У цьому вся полі може зберігатися будь-яка додаткова інформацію про користувачі, наприклад, його повне имя.

6. Повний шлях до домашнього каталогу користувача. У ОС Linux для кожного користувача створюється його домашню каталог, коли він може зберігати свої документи. Зазвичай це каталоги містяться у директорії /home кореневого каталогу й за умовчанням мають імена владельцев.

7. Шлях до командної оболонці. Останнє полі містить повний шлях до робочої оболонці користувача (за умовчанням такий оболонкою є bash). Ця оболонка запускається, коли користувач проходить процедуру аутентифікації. З метою безпеки для системних користувачів у тому полі часто-густо ставиться /sbin/nologin. У наведеному прикладі користувач bin має саме така значення на полі командного інтерпретатора. Сама по собі програма nologin перестав бути оболонкою, єдине її призначення — недопущення вхід до системи. Тому, за спробі входу під назвою користувача, яка має як робочої оболонки встановлено /sbin/nologin, щось відбувається. Зазвичай такий використовується при створенні користувачів, що є системними, тобто не від імені яких виконуються якісь дії всередині системи. Позаяк таким користувачам непотрібна робоча оболонка, хорошим рішенням, з погляду безпеки, буде установка поля оболонки в /sbin/nologin. Ще однією поширеним рішенням таких ситуаціях є налаштованість цього поля була в значення /bin/false. Як відомо, в Linux, та й у більшості інших операційними системами, успішний розв’язок програми визначається типом возвращаемого значення. Якщо повертається нульовий значення, виконання програми минуло успішно, якщо ненульове — у виконання програми виникли помилки. За підсумками возвращаемого значення система аутентифікації робить висновок у тому, пройдено чи аутентификация успішно або він «провалилася». false — програма, яка незалежно від зовнішніх чинників завжди повертає значення, не на нуля, що в разі означає виникнення помилок під час запуску оболонки, і управління і знову повертається системі аутентификации.

При вході у систему програма, що дає доступ, виробляє читання інформації про користувачів саме з файла passwd. Право на запис у цей файл має сенс тільки привілейований користувач root, читати само одержувати його всі користувачі системи (права доступу описуються розділ «Особливості файловій системи Linux»).

Цей файл будь-коли редагується вручну, хоча, у принципі, це цілком можна. Зазвичай для редагування файла користувачів використовують спеціальні програми: useradd, usermod і userdel.

Програма додавання useradd дозволяє додати новому користувачеві в систему. Для управління процесом створення користувача цю програму може ухвалювати різні параметри в командної рядку. Наприклад, параметр -p.s задає використовуваний користувачем shell, а параметр -g — групу, до котрої я належить створюваний користувач. Крім додавання записи про користувачі в файл /etc/passwd, програма useradd створює домашній каталог користувача, котрий за вмовчанням повинен будуть показані у директорії /home. Шлях до користувальницькому каталогу то, можливо визначено з допомогою параметра -d, котрого супроводжує повний шлях від кореневого каталогу до каталогу пользователя.

Програма usermod дозволяє змінювати такі параметри, як робоча оболонка користувача, домашній каталог, група, ідентифікатор користувача й дуже далее.

Неважко здогадатися, що виконує програма userdel. Вона видаляє користувача із системи. Детальна інформація про ці програмах міститься у man-руководствах.

Ім'я користувача перестав бути секретної інформацією, та її без проблем дізнатися інші користувачі системи. Однак у цьому випадку повинна існувати небезпека входу одного користувача під назвою іншого. Проте цього немає. Використовується такого поняття, як аутентификация.

Аутентификация — це встановлення дійсності користувача, тобто встановлення факту те, що користувач з такою назвою є тим, проти всіх себе выдает.

Для аутентифікації в ОС Linux використовується віддавна перевірене і довела свою надійність засіб — пароль.

Пароль — це набір символів (секретне слово), відомий лише його власнику і використовуваний для посвідчення його подлинности.

Кожен користувач у системі має власний пароль. Наявність пароля — необхідна складова політики безпеки користувачів Linux. Пароль є хіба що перепусткою користувача до системи. Без пароля, знаючи лише ім'я користувача, поринути у систему невозможно.

Паролі зберігаються у окремому файлі /etc/shadow. У ранніх версіях Linux імена і паролі користувачів зберігалися щодо одного файлі /etc/passwd. Але практика показала, що з забезпечення надійнішою захисту паролів необхідно створення осібного файла їхнього зберігання. Отже, технологія виділення окремого файла shadow для зберігання паролів отримала назва технології «тіньових паролей».

Приклад файла та її структура наведено нижче. root:$ 1 $pOy8fNrf$uOh/dQlI03BMIdEAhWrE.0:12 369:0:99 999:7: bin:*:12 245:0:99 999:7: daemon:*:12 245:0:99 999:7: sync:*:12 245:0:99 999:7:

Файл shadow, як і файл passwd, розділений сталася на кілька частин двоеточиями:

1. Ім'я користувача. Це полі просто дублюється з файла passwd.

2. Хэш пароля. Пароль в Linux будь-коли зберігається у вигляді, в на відміну від імені користувача. При установці пароля до збереження їх у файлі він шифрується зі спеціального алгоритму. За умовчанням таким алгоритмом є алгоритм одностороннього шифрування DES (Data Encryption Standard). Використання одностороннього алгоритму шифрування виключає можливості розшифровки пароля.

Інші поля містять різну службову информацию.

Файл паролів повинен лише з читання і лише суперкористувача (права доступу описуються розділ «Особливості файлової системи Linux»). Його вміст є недоступним пересічних користувачів, в такий спосіб, виключається можливість розкриття зашифрованого пароля.

Для зміни пароля в Linux спочатку включена спеціальна дитяча програма passwd. Як параметра в командної рядку вона отримує ім'я користувача і за запуску вимагає введення пароля при цьому користувача. При введення з метою безпеки пароль не відображається на екрані монітора, є дуже висока ймовірність припуститися помилки, особливо коли пароль складається з цифр і символів різного регістру. Тому введення пароля здійснюється 2 разу для перевірки вмотивованості введення. Після підтвердження пароль шифрується й тепло зберігається в файлі /etc/shadow.

При вході у систему процедурою отримання імені Ілліча та пароля користувача управляє програма mingetty. mingetty — це програма, видає запрошення для введення імені користувача і пароля на віртуальну консоль. Після цього її запуску на екрані монітора з’являється строка-приглашение до введення імені Ілліча та пароля користувача. Після введення імені Ілліча та пароля програма передає управління програмі login. login — це програма-посередник, яка здійснює перевірку існування, коректності та відповідності імені користувача та її пароля у системі. Пароль з допомогою механізмів аутентифікації шифрується і порівнюється зі хэшем з файла. Після успішного завершення процедури аутентифікації програма login запускає системну оболонку для взаємодії користувача з операційній системою, так званий shell (від анг. shell — «оболонка»). Шлях до исполняемому файлу shell вказується у тому сьомому полі записи файла passwd. Зазвичай по вмовчанням використовується bash (Bourne Shell). Видається запрошення до введення команд з символом # чи $ наприкінці (за умовчанням символ # використовують у запрошенні суперкористувача, а символ $ - в запрошенні звичайного користувача). Відтоді система готовий приймати від користувача команди на выполнение.

Для зручного управління доступом до ресурсів в Linux все користувачі об'єднують у групи. У разі група — це безліч користувачів, об'єднаних по будь-яким критериям.

До якої групі належить користувач, каже 4 полі реєстраційної запис у файлі passwd. Наявність груп дозволяє створити гнучку політику безпеки, засновану на поділі доступу до ресурсів. Значення груп потреби ділити доступу докладніше описується розділ «Особливості файлової системи Linux».

Практичне застосування розглянутим інформації наводиться в додатку в прикладі 1.

2.2. Особливості файловою системи Linux.

Для організації та постійного зберігання інформації в різних її носіях ОС використовує так звану файлову систему.

Файлова система — це методи лікування й структури даних, що використовуються ОС для зберігання файлів на диску чи його разделе.

Біля кожної ОС є своя файлова система, яка від від інших. Від надійності, ефективності та безпеки роботи файловою системи багато в чому залежить якість функціонування ОС в целом.

Нині переважають у всіх дистрибутивах ОС Linux для зберігання інформації активно використовується файлова система ext2 (The Second Extended File System). Ext2 є файловою системою з багатими функціональними можливостями, а те що, що ext2 розробили спеціально для Linux, вже говорить про необхідність присутність у ній засобів контролю та безопасности.

До основних рис файловій системи ext2: максимальний обсяг файловою системи — 4 Тбайт; максимальна довжина файла — 2 Гбайт; максимальна довжина імені файла — 255 символів; присутній підтримка трьох осередків часу зміни файла; також є можливість розширення файловою системи; присутні механізми захисту і можливість змінювати розмір блока.

2.2.1. Права доступа.

Розглянемо ситуацію, коли користувач Щодо зберігання дуже важливих документів має свою домашній каталог. Інформація, що зберігається у документах, є суворо конфіденційної, а, по цього ніхто, крім її власника, ні отримати до неї доступ. Користувач У просто з цікавості, і може і з злісними намірами, спробував отримати вміст цих документів. Результатом спроби стала помилка з описом ‘permission denied' (‘доступ заборонено'). Появою помилки послужило відсутність у користувача B прав для читання документів, що належать користувачеві А. З наведеного прикладу можна дійти невтішного висновку, що має рацію доступу дозволяють обмежити доступом до повну інформацію, чи, простіше кажучи, захистити деяку інформацію з певних пользователей.

Концепція файловою політики безпеки Linux будується у тому, що будь-який файл системи має 3 категорії власників: власне власника файла чи, простіше, її творця, якусь групу користувачів, в яку найчастіше входить власник файла, й інших. Отже, привілейований користувач чи власник файла, бо тільки він мають можливість змінювати права доступу, може спорудити політику файлової безпеки, визначаючи права окремо для власника файла, для групи користувачів і всіх інших користувачів системы.

Права доступу до файлу чи каталогу описуються трьома восьмеричними цифрами, сама ліва у тому числі - права доступу власника, середня — права групи, права — права доступу ж для решти. Кожна з цих восьмеричних цифр є битовую маску з 3-х біт. Ці біти визначають декларація про читання, запис і виконання файла чи каталогу. Якщо біт встановлено у 1 — операція дозволена, тоді як 0 — запрещена.

Для різних типів файлів значення прав доступу трохи отличаются.

Право для читання файла дозволяє користувачеві читати вміст файла. Для каталогу установка права для читання дозволяє читати файли, які перебувають у тому каталоге.

Право на запис файла дозволяє користувачеві змінювати його вміст. Для каталогу — створювати файли всередині каталога.

Право виконання для файла дозволяє запускати файл виконання в ролі програми. Для каталогу установка цього права дає можливість користувачеві укладати каталог і переглядати його содержимое.

Які права доступу визначено кожному за файла, можна почути, набравши в терміналі команду ls з ключем -l: [root@app tmpdir]# ls -l lrwxrwxrwx 1 root users 86 Фев 7 19:49 linkfile -> myfile drwxr-xr-x 1 root users 4096 Фев 7 19:49 lnkrwxr——- 1 anotheruser users 97 Фев 7 19:48 myfile1 -rw-rw-r— 1 root users 84 Фев 7 19:45 myfile2.

У першій колонці представлені права доступу до файлу. Ця колонка містить 10 символів. Перший зліва свідчить, якого типу належить файл, тобто чи є він файлом, каталогом, посиланням й дуже далі. Далі зліва-направо представлені права доступу відповідно для власника, для групи, і наприкінці - ж для решти. Друга колонка відображає кількість жорстких посилань для цього файла. Третя свідчить про ім'я власника файла, четверта — з ім'ям группы-владельца, п’ята колонка — розмір файла, шоста — дата створення файла, сьома — ім'я файла.

Як очевидно з прикладу, linkfile є символічною посиланням на файл myfile. Про це свідчить літера l у самій лівої частини колонки прав доступу. Для символічних посилань завдання прав доступу можливо, але навряд чи є сенс. Річ у тім, що символічна посилання свідчить про файл, який має права доступу, тому при доступі за символічною засланні перевіряються права кінцевого файла. Файл lnk є каталогом, що каже літера d на полі прав доступу. Поле власника свідчить, що власником каталогу є користувач root, а группа-владелец — users. Власник має право читання файлів в каталозі, запис файлів і читання вмісту каталогу. Буква r (від слова Read) говорить про можливість для даного користувача виконувати операції читання файлів каталогу, літера w (від слова Write) — про можливість записи файлів до каталогу, остання літера x (від слова eXecute) дає права на перегляд вмісту каталогу. Користувачі, належать до групи users, заслуговують лише з читання файлів цього каталогу і його вмісту (літери r і x), декларація про запис файлів у цей каталог вони відсутня. Решта користувачі мають самі права доступу, як і группа-владелец. Останні два файла myfile1 і myfile2 є звичайними файлами. Файл myfile2 повинен читання і запис для власника (користувача root) і групи users, й інші заслуговують лише читати файл. Файл myfile1 повинен для читання, запис і виконання для власника, яким у разі є користувач anotheruser. Група users проти неї лише з читання цього файла, проте інші користувачі взагалі можуть виконувати будь-які дії з цим файлом.

Зміна прав доступу до файлу здійснюється за допомогою стандартної системної команди chmod. Права доступу при виклик команди можуть задаватися як битовой маскою в десятковому поданні, і з допомогою символів. Докладно використання цієї команди описано на відповідної manстранице.

Крім прав доступу існують звані модифікатори доступу. До модифікаторам доступу ставляться Sticky bit, SUID і SGID.

Sticky bit (P.S). Для файлів установка цього модифікатора у сприйнятті сучасних дистрибутивах втратила своє значення. Установка Sticky bit до каталогу дозволяє користувачеві записувати файли у цей каталог, але видаляти від цього каталогу може ті файли, власником яких є, чи тому випадку, коли йому явно задано права записи.

SUID (p.s). Якщо файлу встановлено модифікатор доступу SUID і файл виконуваний, то файл під час запуску виконання отримує помиляюся користувача, що запустив його, а права власника файла. Такі прийоми йдуть на здобуття права користувач міг працювати з декотрими системними файлами, власником якого є привілейований користувач. Приміром, у тому, щоб користувач міг самостійно змінити свій пароль з допомогою програми passwd, в цій програми, власником є користувач root, необхідно встановити біт SUID, оскільки він працює із файлом shadow, модифікацію якого має право робити тільки користувач root.

SGID (p.s). Якщо файл має модифікатор доступу SGID, це аналогічно установці біта SUID, лише замість власника файла використовується група, котра має файл. Що стосується установки SGID до каталогу файли, які у цьому каталозі, матимуть установки групи таку ж, як в каталогу. [root@app mydir]# ls -lrwsr—r-x 1 anotheruser users 97 Фев 7 19:48 myfile1.

У наведеному прикладі видно, що файл myfile1 має встановлений біт SUID. Після запуску файла будь-яким користувачем системи (права виконання встановлено всім) файл виконуватиме дії від імені його він власника, у разі від імені користувача anotheruser.

Модифікатори доступу за використання представляють дуже сильніша і небезпечніша гнучке засіб. З іншого боку, неправильна настроювання системи з цих модифікаторів може зводити всі дії з гарантуванню безпеки нанівець. Особливо небезпечної представляється ситуація, коли той самий SUID установлено в виконуваний файл, приналежний привілейованому користувачеві. За виконання файла запустив його користувач отримує право виконувати операції, були доступні лише користувачеві root. Навіть якщо файл не виконує ніяких системних операцій та спрацьовує з системними файлами, неправильне його використання може призвести до дуже неприємний последствиям.

Практичне застосування розглянутим інформації наводиться в додатку в прикладі 2.

2.2.2. Атрибути файлов.

У файловою структурі ОС є файли, які повинні змінюватися у процесі функціонування системи, наприклад, виконувані файли чи файли, що їх відкоректовані лише якось при їх настроюванні системи та нічого не винні змінюватися згодом, прикладом можуть бути конфігураційні файли. Є й такі, які можна доповнені, але з може бути віддалені чи перезаписаны. Наявність коштів, які гарантують виконання умов, дозволяє дуже підвищити безпеку файловій системи, зберігши початкову цілісність даних що за різних типах атак.

Починаючи з версії ядра 1.1, в файловій системі Linux крім прав доступу присутній підтримка розширених атрибутів файлів. Останніх версіях ядра 2.4 присутній підтримка наступних атрибутів:. Atime (A). Щоразу, коли система звертається до файлу, відбувається зміна осередки часу останнього звернення до файлу. Установка атрибута atime дозволяє уникнути відновлення часу останнього обігу євро і продуктивність файлової системи, особливо у випадках, коли звернення до файлам відбувається дуже часто. Проте, відсутність часу останньої модифікації файла загрожує зміни файла без наступної реєстрації цього дії, що небезпека може загрожувати безпеки.. Sync (P.S). Установка атрибута sync дозволяє відразу фіксувати зміни, які з файлом, на жорсткому диску одночасно з процесом, що здійснює ці зміни. Це забезпечує безпечнішу роботу, а може також знизити продуктивність через прямий постійної записи на диск.. Append (a). Цей атрибут дозволяє відкривати файл лише для його доповнення. Усічення чи перезапис файла забороняється. Для каталогу установка цього атрибута означає, що видаляти файли, які у цьому каталозі, заборонено, хоча створення нові й модифікація існуючих можливі.. Immutable (і). Файл з установленою атрибутом immutable неспроможна піддаватися ніяким змін взагалі. Якщо встановити цей атрибут до каталогу, процеси зможуть модифікувати файли, перебувають у ньому, але з зможуть партія створюватиме або видаляти файли. Забезпечували охорону має значення.. No Dump (d). Установка атрибута no dump наказує процесу, здійснюючому створення дампа, ігнорувати цей файл і включати їх у створення резервної копії.. Compress (з). Цей атрибут дає можливості виробляти прозоре стиснення файлів перед записом їх у диск. При доступі до файлу він декомпрессируется і кінцевому процесу представляється вже у нормальному вигляді.. Secure Deletion (p.s). Якщо це атрибут встановлено, то, при видаленні файла все блоки, у яких розташовувався, заповнюються нулями, тобто виробляється повне видалення файла, Не тільки його дескриптора.. Undelete (u). При видаленні файла з цим атрибутом система зберігає все блоки файла на диску, що дозволяє за бажання відновити віддалений файл.

Останні версії ядер, починаючи з 2.4, ігнорують значення останніх трьох атрибутів: compress, secure deletion і undelete. Розробники вважали, що й подальше використання немає смысла.

Для зміни і перегляду встановлених атрибутів у стандартний системний пакет Linux входять дві програми chattr і lsattr. Перша дозволяє змінювати атрибути, додавати або ж орендувати їх, друга дозволяє отримати список встановлених атрибутів. Приклад роботи програми lsattr показаний нижче. [root@app tmpdir]# lsattr myfile* —-і————— myfile ——a————- myfile1.

У прикладі перший файл має встановлений атрибут immutable, другий — атрибут atime. Докладно використання програм lsattr і chattr описується у man-руководствах.

При певних умов процеси, що їх від імені привілейованого користувача, можуть ігнорувати ці атрибути. З іншого боку, атрибути ext2 враховуються деякими системними викликами, такими як sys_open () відкриття файла чи sys_truncate () щодо його відсікання, причому незалежно від ідентифікатора користувача, викликаний їх процесу інших умов. Наприклад, присутність прапора immutable в дескрипторі файла призводить до того, що системних виклики, що стосуються модифікації файлів, просто перестає працювати незалежно з інших умов. Наявність даних атрибутів і спеціальних режимів роботи ядра в Linux дозволяє це й ефективно приборкувати абсолютні можливості, якими має привілейований користувач. Мета комплексної настройки у тому, щоб атрибути накладали обмеження всіх процесів незалежно від своїх прав доступу та підвищення рівня привілеїв. Вони можуть б служити у ролі ефективної низкоуровневой захисту від атак про всяк привілейований процес, у якому можуть бути присутні будь-які невідомі уязвимости.

Проте, сама політика безпеки, побудована на установці атрибутів типу immutable і append, є лише однією стороною монети. Хоча ці атрибути й відвернуть зміна захищених ними файлів навіть із боку процесів, які виконуються від імені привілейованого користувача, в звичайних обставинах користувач root однаково може прибрати ці прапори та продовжити роботи з файлами вже без цих атрибутів. Інакше кажучи, ніщо корисно програмі, виконуваної від імені користувача root, перед початком роботи виконати перевірку файла на наявність цих атрибутів і їх отменить.

Дополняющим компонентом, або ж другий стороною монети, вважатимуться спеціальні можливості ядер 2.4, дозволяють конфіґурувати систему в режимі повної захисту файлів з атрибутами immutable і append досі перезавантаження в однокористувальницький режим. Для установки цих та безлічі інших, параметрів ядра користуються програмою lcap (Linux Kernel Capabilities Bounding Set Editor).

Приклад використання lcap [root@app /]# lcap CAP_LINUX_IMMUTABLE [root@app /]# lcap CAP_SYS_RAWIO.

Перший виклик lcap з параметром CAP_LINUX_IMMUTABLE скасовує можливість у привілейованих процесів знімати прапори immutable і append. Другий виклик з параметром CAP_SYS_RAWIO забороняє низкоуровневый доступом до блоковим пристроям, таких як диски, задля унеможливлення прямого доступу до файлам.

Потому, як за допомогою lcap змінили будь-якої параметр ядра, його повторне зміна можлива тільки після перезавантаження системи. Ця особливість дає у тому, що у системі не зможуть непомітно здійснюватися зміни без отримання фізичного доступу і перезавантаження в однокористувальницький режим.

Детальну документацію за програмою lcap можна знайти у відповідних man-руководствах.

Практичне застосування розглянутим інформації наводиться в додатку в прикладі 3.

2.2.3. Механізм квот.

Мабуть, кожен адміністратор многопользовательской системи знайомий з поняттям «дискової квоти». Спробуймо розібратися, що це таке, і який ставлення це поняття має до гарантування безпеки системы.

Дискова квота — заздалегідь певне, фіксований кількість блоків дискового простору і/або кількість файлових дескрипторів, що виділяється кожному користувачеві чи групі користувачів до роботи і збереження данных.

Використання дискових квот дозволяє обмежувати два аспекти дискового простору: кількість файлових дескрипторів, інакше кажучи, кількість файлів, що може бути створено користувачем чи групою користувачів, і частку всього обсягу диска, яке може використовувати користувач чи група для зберігання своїх файлів. Ідея у тому, щоб визначити кожному за користувача чи групи певну частину від загального обсягу диска, щоб за яких умов користувач не зміг перевищити той обсяг використовуваної дискової пам’яті, що йому виділено. Отже, усувається проблема переповнення диска або через брак дискового простору й інших користувачів і процессов.

Концепція поділу дискового простору оперує трьома поняттями: м’яке обмеження (soft limit), жорстке обмеження (hard limit) і період відстрочки (grace period).

М’яка обмеження визначає максимальна величина дискового простору, що може бути зайнятий даними певного користувача чи групи пользователей.

Жорстке обмеження працює, лише коли встановлено період відстрочки grace period.

Якщо період відстрочки встановлено у значення, не на нуля, те, коли зайнятий обсяг перевищує обсяг м’якого обмеження, користувачеві видається повідомлення, що його дискове простір наприкінці. Якщо користувач ігнорує це попередження та її дискова квота продовжує перевищувати значення м’якого обмеження, після закінчення періоду відстрочки дискова квота вважається вичерпаною. У цьому обов’язково має бути встановлено жорстке обмеження. Жорстке обмеження є абсолютною максимумом використання простору файловій системи пользователем.

Управління механізмом квот здійснює ядро ОС. У останніх версіях Linux в стандартне ядро, яка йде в дистрибутиві, підтримка квот включена за умовчанням. Якщо ж виробляється складання нового ядра, підтримку квот необхідно включити явно. Включення підтримки механізму квот здійснюється установкою параметра Quota Support (CONFIG_QUOTA) розділ FileSystems при конфигурировании ядра до процесу складання. Якщо такої параметра в ядрі немає, це, що це версія ядра підтримувати не може механізм квот. І тут на підтримку квот на ядро має бути накладений «латочку» — спеціальне доповнення у стандартний код ядра. Латочку можна завантажити з Интернета.

Підтримка квот поширюється на логічний розділ диска і вказується за його монтуванні. Для монтування розділу використовується файл /etc/fstab, у якому задаються параметри, що вказують на використання квот. Це параметри usrquota і grpquota.

Для управління і настрою дискових квот використовується пакет quota. У сучасних дистрибутивах Linux цей пакет входить у стандартну поставку, проте його можна завантажити останню версію з Интернета.

Зараз написання роботи останньої стабільної версією пакета quota була версія 3.11. Далі перераховані основні програми пакета quota-3.11, необхідних настройки механізму квот: quota — програма дозволяє відображати поточний стан механізму квот. За умовчанням відображається лише квота користувача, що запустив програму виконання. Цю програму може запускати будь-який користувач системи. convertquota — програма виробляє переклад файлів quota. user і quota. group в файли aquota. user і aquota.group. Файли quota. user і quota. group є файлами користувальних квот старого формату. Починаючи з версії ядра 2.4.0, в Linux використовують новий формат дискових квот, який має, на відміну старої версії, такими преимуществами:

— підтримка 32-бітних ідентифікаторів користувачів (UID);

— установка квоти для привілейованого пользователя;

— установка дискової квоти в байтах (у колишній версії одиницею дискової квоти служив килобайт);

— підтримка дискової квоти для журналируемой файловою системи ReiserFS.

Для настройки нової версії механізму квот використовуються файли aquota. user і aquota.group. Інакше кажучи, програма convertquota дозволяє перевести файли настройки квот із попереднього формату у новий, цим дозволяючи можливість перейти до використанню нової версії з мінімальним перенастройкой системи. edquota — програма є редактором користувальних квот. При виклик програмних засобів запускається текстовий редактор, встановлений по вмовчанням у системі. У цьому вся редакторі можна зробити ці зміни в файлі дискової квоти. qout — програма виводить статистику в кілобайтах по користувальницьким квот для конкретної файлової системи. Зараз написання роботи програма quot, що входить у пакет версії 3.11, підтримувала лише файлову системи XFS. quotacheck — програма для перевірки цілісності дискової квоти. При інтенсивної роботі механізму квот в файловою системі можуть бути різні неточності, пов’язані з допомогою дискового простору користувачів. Програма quotacheck проводить перевірку файловій системи, визначаючи розмір доступного і зайнятого простору, виробляє побудова таблиці поточного використання дискового простору й порівнює отримані дані з записами розмов у файлі дискової квоти. Якщо є якісь невідповідності, ці невідповідності усуваються шляхом виправлення невірних значень в файлах дискової квоти. quotaon — програма для включення користувальних квот на зазначеної файловою системі. До використання програмних засобів необхідне необхідної файлової системи встановити параметр usrquota і/або grpquota в файлі /etc/fstab. quotaoff — програма для вимикання користувальних квот на зазначеної файловій системі. repquota — програма висновку статистики з використання дискового простору для зазначеної файлової системи. setquota — програма для редагування користувальних квот як командної рядки. warnquota — програма для інформування користувачів у тому, що й дискове простір наприкінці. Інформування відбувається шляхом посилки що попереджав повідомлення електронній почте.

Більше докладна інформацію про програмах пакета quota то, можливо отримана з відповідних man-руководств.

Практичне застосування розглянутим інформації наводиться в додатку в прикладі 4.

2.3. Бібліотека PAM.

PAM (Pluggable Authentication Modules) — подгружаемые модулі аутентифікації. PAM є набором динамічно подключаемых модулів, з допомогою яких привілейований користувач може вибирати, як додаток має здійснювати процес аутентифікації. Така технологія виявилося дуже корисна, особливо в появу різних методів аутентифікації користувача у системі. Ця технологія має дві основних переваги. Першим перевагою є модульність додатків, підтримують PAM. Це означає, що з докладання, підтримує PAM, з’являється можливість змінити механізм аутентифікації користувачів без перекомпіляції програми, кажуть «в процесі лікування», досить змінити конфігураційний файл PAM. Друге перевагу використання PAM у тому, що адміністратор системи отримує повну волю виборі схеми аутентифікації кожному за окремого докладання, причому ця схема може бути досить складною і що з кількох етапів. Єдиним невід'ємним вимогою від використання PAM є наявність спочатку вмонтованих у додаток функцій роботи з бібліотекою PAM. Зараз майже всі популярні програмні продукти мають вмонтовану підтримку PAM.

[pic].

Рис. 2.3.1 Структурна схема взаємодії докладання і наукові бібліотеки PAM.

На малюнку 2.3.1 наочно показано, як відбувається взаємодія нікого докладання, А бібліотекою PAM. Додаток взаємодіє зі бібліотекою PAM, причому додатку невідомо, які алгоритми аутентифікації використовуються під час перевірки дійсності користувача. Усі операції з аутентифікації, тобто шифрування пароля та її перевірку, виробляє бібліотека PAM. Бібліотека Linux-PAM (у середині малюнка) виробляє читання параметрів аутентифікації докладання, А з конфігураційного файла і завантажує необхідні модулі на згадку про. Потім завантажені модулі потрапляють у жодну з чотирьох управляючих груп (розміщених у частині малюнка посередині) і поміщаються туди гаразд появи в конфигурационном файлі (спочатку модуль, а групу auth, його b тощо). Ці модулі при виклик бібліотекою Linux-PAM виконують різні завдання аутентифікації для докладання А. Для передачі текстовій інформації, яку просять у користувача, можна використовувати вбудована функція обмена.

Усі модулі PAM за умовчанням вміщено у каталозі /lib/security, а конфігураційні файли PAM — в каталозі /etc/pam.d. Ім'я кожного конфігураційного файла, що за каталозі /etc/pam.d, збігаються з ім'ям докладання, котрий використовує його. Наприклад, для програми login повний шлях до конфигурационному файлу PAM матиме вид /etc/pam.d/login. Вміст цього файла може мати такий вигляд: #%PAM-1.0 auth required /lib/security/pam_securetty.so auth required /lib/security/pam_stack.so service=system-auth auth required /lib/security/pam_nologin.so account required /lib/security/pam_stack.so service=system-auth password required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_limits.so session optional /lib/security/pam_console.so.

Кожна рядок файла означає, що з вдалою аутентифікації користувач має відбутися через зазначений модуль. Формат рядки будь-якого конфігураційного файла PAM має вигляд: тип_модуля флаг_контроля путь_к_модулю параметры_модуля.

Усі модулі бібліотеки PAM по функціональному ознакою діляться чотирма типу: auth — цей тип модулів дозволяє здійснювати два аспекти аутентифікації. По-перше, він виконує саму аутентификацию, тобто встановлює факт те, що користувач справді той, проти всіх себе видає. Це то, можливо запит пароля й інші методи ідентифікації. Удругих, модуль розв’яже членство групи (незалежно від файла груп користувачів group) чи визначити інші привілеї, виходячи з інформації про користувачі. account — цей тип модулів виконує функції, які пов’язані з аутентификацией безпосередньо. Звичайно використовується до розв’язання чи заборони доступу залежно певних умов, як-от час дня, кількість користувачів, одночасно запросивших ресурс, різні параметри системи та таке інше. sessions — переважно цей тип використовується визначення додаткових дій, які потрібно виконати до чи помирають після надання сервісу користувачеві. Сюди можна віднести протоколювання дій зі відкриттю певних файлів, монтування каталогів, видалення тимчасових файлів тощо. password — цей останній тип необхідний відновлення пізнавального ознаки (наприклад, того самого пароля), який ідентифікує пользователя.

Наявність чотирьох управляючих типів свідчить, що саме технологія аутентифікації з допомогою бібліотеки PAM здатна надати не лише «голий» спосіб встановлення дійсності користувача, ще гроші і широкий, спектр додаткових можливостей захисту системи та надання доступу до сервисам.

Прапор контролю визначає, як система буде поводитися за вдалого чи невдалому проходженні відповідного модуля. Оскільки модулі запускаються одна одною, то спеціальної розстановкою прапорів можна визначити значимість кожного їх. Як прапорів можна використовувати чотири ключових слова: required — цей прапор визначає, що з вдалою аутентифікації загалом необхідно успішне проходження відповідного модуля. Якщо за проходженні цього модуля системі поставлено відмова, процес аутентифікації триває до того часу, доки всі модулі ні оброблені, і лише потім присуджується повідомлення про помилку. requisite — ефект дії цього прапора хоча б, як і прапора required, з однією різницею: і при отриманні відмови управління відразу повертається додатку, проходження інших модулів немає. sufficient — весь процес аутентифікації вважається успішним, якщо робота модуля з цим прапором була успішною і перевірка попередніх модулях із прапором required не провалилася. Якщо робота модуля з цим прапором була невдалої, це вважається фатальною помилкою. optional — успішність модуля з цим прапором є необов’язковою і його використання не критично для аутентификации.

Шлях до модуля містить рядок повного шляху до модуля в файлової системі. Усі модулі зберігаються у каталозі /lib/security, тому, наприклад, шлях до модулю pam_limits виглядатиме як /lib/security/pam_limits.so.

Параметри модуля є індивідуальним кожному за модуля і описуються в документації модуля.

Крім основних конфігураційних файлів деякі модулі використовують додаткові файли конфігурації, перебувають у каталозі /etc/security. Кожен файл у тому каталозі призначений для конкретної групи настройок: time. conf — у тому файлі можна обмежити час доступу користувачів з різних терміналів до різним сервісів. Ці настройки використовує модуль pam_time, для набрання чинності тимчасових обмежень необхідно додати модуль pam_time в конфігураційний файл докладання, яким повинні поширюватися ці обмеження. pam_env.conf — з допомогою цього файла можна позбавити можливості зміни деяких змінних середовища користувачами. Цей файл використовується модулем pam_env. limits. conf — цей файл дає можливість обмежити розмір core-файла, максимально припустимий розмір файла, якомога більше одночасно відкритих файлів, запущених процесів, величезну кількість водночас відкритих користувальних сесій тощо. Використовується модулем pam_limits. access. conf — з допомогою цього файла можна визначити різні параметри входу користувача до системи, наприклад, з яких комп’ютерів користувач має доступ до системи. Цей конфігураційний файл використовується модулем pam_access. group. conf — у тому файлі можна вказати, якої групі буде належати процес, запущений користувачем у час з певного термінала. Файл читається модулями pam_time і pam_group. console. perms — у тому файлі є можливість вказати права, призначувані привілейованим користувачам біля входу до систему і які повертаються консолі за його виході. Файл використовується модулем pam_console.

Як неодноразово згадувалося, все модулі вміщено у каталозі /lib/security. Розглянемо коротко, які модулі входить у стандартний пакет PAM, і які функції виконує кожен із них:

|Название модуля |Тип модуля |Опис | |pam_cracklib |password |Дозволяє перевіряти пароль на стійкість, | | | |чи він, наприклад, словом з | | | |словника тощо. буд. Здебільшого використовується | | | |програмами, які задають паролі. До корисним | | | |параметрами ставляться: | | | |retry=N — задає кількість спроб на | | | |виправлення помилки; | | | |diffok=N — визначає мінімальне | | | |кількість символів, що має бути | | | |змінено на зміну пароля; | | | |minlen=N — задає мінімальний розмір | | | |пароля в символах; | | | |dcredit=N ucredit=N lcredit=N ocredit=N — | | | |задає мінімум цифр, | | | |малих літер, прописних літер та інших | | | |символів, які мають бути присутнім на | | | |пароль. | |pam_deny |будь-який |Основне призначення цього модуля — заборона | | | |доступу за жодних умов. | |pam_env |auth |Контролює схоронність змінних середовища.| | | |З допомогою параметра conffile=S можна | | | |вказати файл конфігурації, відмінний від | | | |стандартного. | |pam_ftp |auth |Призначений в організацію анонімного | | | |доступу. Отримавши ролі імені | | | |користувача послідовність | | | |‘anonymous', модуль як пароль | | | |вимагає рядок, схожу поштову адресу.| | | |До корисним параметрами ставляться: | | | |users=XXX, XXX, … — дозволяє анонімний | | | |вхід для користувачів із списку; | | | |ignore — дозволяє не зважати, | | | |схожий чи пароль поштову адресу. | |pam_group |auth |Визначає группу-владельца процесу, | | | |запущеного аутентифицированным | | | |користувачем. | |pam_lastlog |auth |Повідомляє про місце й часу входу в | | | |систему. Для протоколювання використовується| | | |файл wtmp, що у каталозі /var/log| | | |. До корисним параметрами можна віднести: | | | |nodate noterm nohost silent — дозволяють не| | | |виводити у міжнародному сполученні дату, термінал, адресу| | | |машини чи нічого не нотувати у | | | |файл; | | | |never — дає можливість видачі | | | |вітання користувача, вперше | | | |що у систему. | |pam_limits |session |Дозволяє ставити обмеження | | | |користувача на розмір файлів, число | | | |одночасно відкритих дескрипторів тощо. буд.| | | |Має параметр conf=S для вказівки | | | |альтернативного конфігураційного файла. | |pam_listfile |auth |Призначений в організацію доступу на | | | |основі конфігураційних файлів на кшталт | | | |/etc/ftpaccess. Можливі паарметры: | | | |onerr=succeed | fail — задає яке| | | |значення у разі невдалого пошуку; | | | |sence=allow | deny — задає яке | | | |значення у разі вдалого пошуку; | | | |file=filename — дозволяє вказати ім'я | | | |файла з переліком; | | | |item=user | tty | rhost | ruser | group | | | | |shell — визначає тип елементів у списку.| | | |Наприклад, значення item=user означає, що| | | |в файлі міститься список імен | | | |користувачів, які можуть входу в| | | |систему. | |pam_mail |auth |Дозволяє повідомляти користувача про знову | | | |яка прийшла пошті. Корисні параметри: | | | |dir=S — вказує шлях до каталогу поштових| | | |черг; | | | |noenv — скасовує установку перемінної | | | |середовища MAIL; | | | |close — дозволяє повідомляти то | | | |листах в скриньках користувачів з | | | |анульованими бюджетами; | | | |nopen — забороняє висновок будь-якої | | | |поштової інформації для знову заведеного | | | |бюджету. | |pam_nologin |auth |Якщо файл /etc/nologin існує, в | | | |систему здатний лише | | | |привілейований користувач root, | | | |іншим навіть за спробі входу видається | | | |вміст цього файла. | |pam_permit |будь-який |Цей модуль дає доступ за будь-яких | | | |умовах. Необдумане використання цього| | | |модуля дуже небезпечний! | |pam_pwdb |будь-який |Заміщає модулі серії pam_unix. Цей | | | |модуль використовує інтерфейс бібліотеки | | | |libpwdb, готовий до роботи з | | | |користувальницькими базами даних, що | | | |підвищує незалежність системи | | | |аутентифікації від способу зберігання | | | |користувальних даних. Корисні | | | |параметри: | | | |nullok — дозволяє використання порожніх | | | |паролів; | | | |md5 shadow bigcrypt — вказує | | | |використовувані алгоритми шифрування паролів.| |pam_radius |session |Дозволяє здійснювати аутентификацию | | | |через сервер RADIUS. | |pam_rhosts_auth |auth |Механізм цього модуля грунтується | | | |на аналізі вмісту файлів hosts. equiv | | | |і .rhosts, що використовуються аутентифікації| | | |такими службами, як rlogin і rsh. | | | |Корисні параметри: | | | |no_hosts_equiv — дозволяє ігнорувати | | | |вміст файла hosts. equiv; | | | |no_rhosts — дозволяє ігнорувати | | | |вміст файла. rhosts; | | | |suppress — дозволяє уникнути запис | | | |малозначних повідомлень в системний | | | |журнал, зокрема, під час використання | | | |прапора sufficient. | |pam_root_ok |auth |Дозволяє організувати доступ | | | |привілейованого користувача до сервісу,| | | |минаючи процедуру введення пароля. Користувач| | | |допускається до сервісу, лише коли його | | | |системний ідентифікатор нульовий (то | | | |є привілейований користувач root).| |pam_securetty |auth |Дозволяє враховувати файл /etc/securetty. У| | | |файлі /etc/securetty вказані термінали, з | | | |яких привілейований користувач | | | |має доступ до системи. | |pam_time |account |Накладає тимчасові обмеження на | | | |доступ до системи. | |pam_warn |auth, |Виробляє запис у системних журналах при| | |password |певних діях. | |pam_wheel |auth |Цей модуль дозволяє їм отримати права | | | |привілейованого користувача лише | | | |користувачам певної групи. | | | |Корисні параметри: | | | |group=XXX — задає групу, користувачі | | | |якої мають нагоду отримати права | | | |користувача root; | | | |deny — цей параметр інвертує дію | | | |модуля, інакше кажучи, він забороняє | | | |зміна прав на права користувача root | | | |для зазначеної групи; | | | |trust — рятує користувачів зазначеної | | | |групи від виробничої необхідності введення пароля при | | | |зміні ідентифікатора на нульової. |.

Можливе також створення власних PAM-модулей з урахуванням готових шаблонів, що дозволяє швидко отримати необхідний метод аутентифікації без особливих зусиль. Більше докладну інформацію про модулях і бібліотеці PAM можна знайти у документації, яка поставляється разом із пакетом. Практичне застосування розглянутим інформації наводиться при застосуванні в прикладі 5.

2.4. Брандмауэр

Локальна безпеку — необхідна складова загальної безпеки системи. Вона дозволяє усунути загрозу локального зламування. Проте, при роботі комп’ютера у мережі ще один тип загрози — мережевий. Для усунення мережевий загрози, як й у локальної, є свої кошти й методи. Одним таким засобом, найважливішим та практично необхідним при побудові мережевий системи безпеки є брандмауэр.

Брандмауэр, він також мережевий екран, він також firewall (з анг. «вогненна стіна») — це система чи група систем, що реалізують правила управління доступом між двома мережами. Фактичні кошти, з допомогою яких досягається, дуже різні, проте у принципі брандмауэр так можна трактувати як пару механізмів: один для блокування передачі, а інший — для пропуску інформації. Деякі брандмауэры приділяють більше уваги блокування передачі, інші - її пропуску. Деякі брандмауэры пропускають лише повідомлення електронної пошти, цим захищаючи мережу від будь-яких атак, крім атак на поштову службу. Інші брандмауэры забезпечують менш сувору захист і блокують лише служби, точно загрозливі безпеки. Зазвичай брандмауэры конфигурируются захисту від неавторизованої інтерактивною реєстрації із зовнішнього світу. Саме ця, більше, ніж усе інше, допомагає запобігти проникнення зломщиків в комп’ютери внутрішньої мережі. Більше розвинені брандмауэры блокують передачу інформації ззовні в защищаемую мережу, дозволяючи у своїй внутрішнім користувачам вільно взаємодіяти з зовнішнім миром.

Схема мережного запиту на сервер з установленою брандмауэром показано малюнку 2.4.1.

Рис. 2.4.1. Покрокова схема виконання мережного запиту з впровадження сполуки до ОС Linux.

Ядро ОС Linux версії 2.4 і більше пізніх має вмонтований міжмережевий екран netfilter, який має такими можливостями:. дозволяє здійснювати фільтрацію вхідних, вихідних і транзитних пакетів, виходячи з змісті заголовка пакета, типі пакета, визначального його у поєднанні (першу чергу встановлення сполуки, пакет синхронізації, пакет завершення сеансу), IP адресі компьютера-отправителя і компьютера-получателя, MAC адресі відправника і одержувача тощо.. дозволяє здійснювати трансляцію мережевих адрес NAT (Network Address.

Translation) і підміну портів NPT (Network Port Translation). Действие.

NAT залежить від підміні IP адреси компьютера-отправителя чи комп’ютераодержувача на зазначений. Найчастіше цю можливість використовується в організацію обміну інформацією між двома мережами, мають різні діапазони IP адрес. Дія NPT аналогічно NAT з тією різницею, що у останньому виробляється підміна порту докладання вместо.

IP адреси.. дозволяє змінювати спеціальні поля заголовка пакета, такі як TOS (Type.

Of Service), TTL (Time To Live) тощо, що надає розширені змогу управління процесом маршрутизации.

Уся логічна структура екрана netfilter будується на поняттях ланцюжків, таблиць і керував доступа.

Ланцюжок — певний набір правил управління доступом. Потрапляючи в ланцюжок, пакет проходить її правила, починаючи з першого. Кожне правило має критерій і дію. Якщо пакет потрапляє під критерій правила, те з пакетом виробляється дію, певне при цьому правила.

Таблиця — це набір ланцюжків. Таблиці діляться за функціональному призначенню визначають дії, які дозволено виконувати в правилах ланцюжків цих таблиц.

Netfilter містить лише три таблиці: mangle — ця таблиця використовується внесення змін — у заголовки пакетів. Прикладом може бути зміна поля TTL, TOS чи MARK. Таблиця має п’ять ланцюжків: PREROUTING, POSTROUTING, INPUT, OUTPUT і FORWARD. Ланцюжок PREROUTING використовується внесення змін вході у брандмауэр, перед рішенням про маршрутизації. Ланцюжок POSTROUTING використовується внесення змін виході з брандмауэра вже після ухвалення рішення про маршрутизації. Ланцюжок INPUT використовується внесення змін — у пакети до того, як вони передані локального додатку всередині брандмауэра. Ланцюжок OUTPUT використовується внесення змін — у пакети, які від додатків всередині брандмауэра. І, нарешті, ланцюжок FORWARD використовується внесення змін — у транзитні пакети після першого ухвалення рішення про маршрутизації, але перед останнім прийняттям рішення про маршрутизації. Використання таблиці з метою, ніж зміни заголовка пакета, неприпустиме. nat — ця таблиця використовується для перетворення мережевих адрес, так званої також NAT, і підміни портів NPT. Через цю таблицю проходить лише першу чергу з усього потоку даних сполуки. Перетворення адрес автоматично застосовується всім наступним пакетів. Ця таблиця містить три заздалегідь певні ланцюжка. Ланцюжок PREROUTING використовується внесення змін — у пакети на вході у брандмауэр. Ланцюжок OUTPUT використовується для перетворення адрес в пакетах, створених додатками всередині брандмауэра, перед рішенням про маршрутизації. І останнє третя ланцюжок у цій таблиці - POSTROUTING, яку використовують перетворення пакетів перед відправкою в мережу. Ця таблиця повинна застосовуватися лише для перетворення адрес і портів у пакеті. filter — ця таблиця використовується головним чином заради фільтрації пакетів. Таблиця має три вбудованих ланцюжка. Перша — FORWARD, використовувана для фільтрації пакетів, не адресованих серверу, у якому встановлено брандмауэр, тобто які йдуть транзитом нього. Ланцюжок INPUT проходять пакети, призначених локальним додатків серверу. І ланцюжок OUTPUT використовується для фільтрації вихідних пакетів, сгенерированных додатками на сервері з брандмауэром.

Структурна схема брандмауэра netfilter показано малюнку 2.4.2.

Рис. 2.4.2. Структурна організація брандмауэра.

А, щоб брандмауэр виконував ті функції, котрі з нього покладаються, для комплексної мережевий захисту необхідно, щоб усе пакети, які надходять через мережу і які у мережу, проходили нього. Якщо йому це правило, не дотримується, чи дотримується частково, то ми все дії, створені задля створення безпечного серверу з допомогою брандмауэра, будуть безкорисними. Якщо існує хоч найменша ймовірність, що брандмауэр можна обминути, цю можливість обов’язково рано чи пізно буде використана зломщиками. У Linux брандмауэр є частиною ядра, а бо всі операції під час роботи з мережею контролює ядро, гарантію того, що це мережні пакети пройдуть нього, вважатимуться практично стопроцентной.

Дотримуючись малюнку 2.4.2, розглянемо, який шлях робить пакет, колись ніж досягти місця призначення. Потрапляючи на сервер, пакет спочатку проходить ланцюжка PREROUTING таблиць mangle і nat. Потім, залежно від цього, кому адресовано пакет, його напрям не може змінюватися. Якщо пакет адресовано локального процесу серверу, після маршрутизації він потрапляє у ланцюжка INPUT таблиць mangle і filter. Коли йому вдасться успішно пройти ці ланцюжка, пакет сягає локального процесу. Відповідь локального процесу перед відправкою проходить спочатку ланцюжок OUTPUT всіх трьох таблиць, і, якщо пакет ні отфильтрован, він потрапляє у заключну ланцюжок POSTROUTING таблиць mangle і nat. Після цього пакет залишає сервер.

Якщо ж пакет адресовано іншому комп’ютера, тобто є транзитним, то після маршрутизації він потрапляє у ланцюжок FORWARD таблиць mangle і filter, у якій рухаються всі необхідне по управлінню доступом всім транзитних пакетів. Далі, як і пакет локального процесу, перед відправленням його у мережу транзитний пакет проходить через ланцюжка POSTROUTING таблиць mangle і nat.

Цих трьох таблиць із заздалегідь закріпленим функціональним призначенням цілком достатньо реалізації всіх згаданих раніше можливостей. Кількість таблиць є певних захворювань і може бути змінено ні за яких умовах. При настроюванні брандмауэра до таблиць може бути додано інші ланцюжка на додаток до вже існуючих, що дозволяє створювати гнучкішу систему управління доступом, ніж просто додавання правив у заздалегідь певні ланцюжка. На відміну від ланцюжків, створених адміністратором, системні ланцюжка INPUT, OUTPUT, FORWARD, PREROUTING і POSTROUTING неможливо знайти віддалені ані за яких условиях.

Для настроювання й управління брандмауэром у складі ОС Linux поставляється програмний пакет iptables. Цей пакет крім файлів документації і модулів, подгружаемых в ядро і що використовуються здійснення фільтрації по різним критеріям, входять такі виконувані файли: iptables — основна програма пакета, з допомогою якої виготовляється маніпулювання правилами в ланцюжках. Ця програма дозволяє здійснювати з правилами і користувальницькими ланцюжками все доступні дії. iptables-save — програма, що дозволяє зберігати усі наші поточні правила щодо одного файлі на подальше відновлення. За умовчанням цим файлом є /etc/sysconfig/iptables. У файлі /etc/sysconfig/iptables зберігається вся конфігурація брандмауэра і від цього файла вона зчитується при завантаженні системи. iptables-restore — цю програму дозволяє зчитувати правил і ланцюжка, збережені раніше програмою iptables-save. За умовчанням цю програму намагається завантажити файл /etc/sysconfig/iptables, коли він существует.

Більше докладна інформацію про програмному пакеті iptables міститься у файлах документації, соціальній та відповідних man-руководствах.

Практичне застосування розглянутим інформації наводиться в додатку в прикладі 6.

2.5. Глухе управление.

Потреба такого далекого управлінні почалося з моменту появи сіті й систем, які було адмініструвати на расстоянии.

Щоб краще уявити, у чому зручність від використання програм віддаленого управління, візьмемо простий приклад. Організація має свій власний сервер, у якому розташовується поштова система і поштові ящики всіх співробітників. Організація орендує приміщення на двадцятому поверсі висотного будинку, у якому крім неї функціонує ще десяток-другий так само організацій. У цьому будинку є спеціалізоване підвальне приміщення зі в добре організованій системою охолодження, у якому розташовуються комунікаційні кошти, системи зв’язку й серверу. Сервер аналізованої організації також міститься у цьому самому приміщенні. За працездатністю серверу стежить спеціальне обличчя, яке виконує функції адміністратора мережі, яке крім того виконує ці зміни в конфігурації наданих сервісів. Нині ж уявімо, що насамперед необхідно зробити адміністратору, якщо, наприклад, якомусь користувачеві поштової системи треба змінити пароль. За відсутності віддаленого управління адміністратор змушений щоразу спускатися з двадцятого поверху в підвальне приміщення, відкривати локальну консоль на сервері і, виконавши необхідне, повертатися назад. У принципі так, ситуація не така вже безвихідна. Якщо ж організація орендує сервер іншій країні чи іншому континенте?

У разі ідеальним рішенням є організація повнофункціонального управління сервером у вигляді мережного доступу. Є кілька найпоширеніших протоколів віддаленого адміністрування, дозволяють управляти системою з допомогою. Найбільш давнім і найпоширенішим, але водночас самим небезпечним, є протокол Telnet. Це найбільш перший протокол віддаленого взаємодії, який побачив світанку розвитку обчислювальних мереж, коли проблемі безпеки під час передачі інформації не приділялося практично ніякого уваги. При передачі інформації з протоколу Telnet всі дані передаються у відкритому незашифрованном вигляді, зокрема імена і паролі користувачів. Будь-який, навіть малодосвідчений в комп’ютерних справах, користувач, маючи програму, під загальним назвою network sniffer (з анг. «мережевий аналізатор пакетів»), може мати простий ім'я і пароль під час передачі їх за сети.

Крім протоколу Telnet в UNIX-системах існує цілий сімейство так званих r-программ. До них належать rsh, rlogin (початкова літера r сприймається як remote) та інші, дозволяють виробляти різні операції, пов’язані з віддаленим адмініструванням. Проте рівень безпеки під час використання r-программ, як і культурний рівень безпеки при використанні Telnet, також ще залишає бажати лучшего.

Є ще один протокол керувати деякими параметрами системи та отримання неї. Це протокол SNMP (Simple Network Management Protocol). Протокол SNMP має обмежений спектр можливостей і позбавлений тієї ж недоліків у плані безпеки, як і протокол Telnet.

Ці протоколи можуть бути хорошим рішенням для таких локальних мереж, де вимоги, які пред’являються безпеки, не є дуже високими. Проте, під час передачі даних із такий мережі, як Інтернет, де пакет, колись ніж досягти адресата, проходить кілька небезпечних вузлів, їх використання може бути потенційної загрозою безпеки і основний причиною успішного проникнення систему.

Сьогодні однією з поширених і безпечних протоколів віддаленого адміністрування, використовують шифрування при передачі даних, є протокол SSH (Secure SHell). Розглянемо докладніше, що ж полягає перевагу протоколу SSH над іншими протоколами віддаленого управления.

Протокол SSH виник 1995 року і від запрацювала основу була покладено ідея створення кошти організації безпечного доступу до комп’ютерів під час роботи по небезпечним каналами зв’язку, таких як мережу Інтернет. У протоколі SSH в організацію безпечного доступу застосовується процедура аутентифікації з допомогою асиметричного шифрування з відкритим ключем. Це забезпечує вищу безпеку, аніж за використанні симетричного шифрування, хоч і породжує додаткову обчислювальну навантаження. При наступному обміні даними застосовується вже симетричний шифрування, економічніше себто витрат процесорного часу. Також SSH підтримує можливість роботи з роботи вже згаданим протоколом Telnet, безпечну роботу з протоколу графічного рівня X11, завдяки можливості перенаправлення відповідних даних із надійним SSH-каналам, надає безпечну заміну багатьом r-программам UNIX, з якими традиційно пов’язані проблеми забезпечення безопасности.

Проект стандарту SSH описує протоколи SSH і складається з кількох документів, які описують загальну архітектуру протоколу, і навіть протоколи трьох рівнів: протокол транспортного рівня, протокол аутентифікації і протокол сполуки. Їх завдання — забезпечувати безпечну мережну службу на кшталт Telnet поверх небезпечної сети.

Протокол транспортного рівня забезпечує аутентификацию серверу, конфіденційність і цілісність. Протокол аутентифікації забезпечує аутентификацию клієнта для серверу. Нарешті, протокол сполуки SSH мультиплексирует безпечний шифруемый канал, представляючи його вигляді кількох логічних каналів, що використовуються різних цілей чи різних видів служб. До того ж протокол транспортного рівня передбачає можливість стискування даних, що явним перевагою проти протоколом Telnet під час передачі даних із низкоскоростному каналу. Протокол транспортного рівня працює поверх сполуки TCP/IP, своєю чергою протокол аутентифікації працює поверх протоколу транспортного рівня, а протокол сполуки — поверх протоколу аутентифікації. У результаті виходить жорстка взаємозв'язок протоколів, забезпечуючи у сумі найбезпечнішу і ефективну передачу данных.

З з підвищення безпеки в протоколі SSH здійснюється як аутентификация клієнта для серверу, якого звертається клієнт, а й аутентификация серверу клієнтом — інакше кажучи, відбувається аутентификация обох сторін. Клієнт шле запит обслуговування у раз, коли встановлюється безпечне з'єднання транспортного рівня SSH. Другий запит іде вже після завершення аутентифікації клиента.

У дистрибутивах Linux в більшості UNIX-подобных ОС можливість роботи з протоколу SSH надає безплатний та вільноякий розповсюджується програмний продукт OpenSSH, куди включені як серверна програма, і клієнтське додаток. Налаштування програм пакета OpenSSH здійснюється почасти за умови встановлення пакета, деяка настроювання виробляється у вигляді зміни у конфігураційних файлах.

При установці пакета із вихідних файлів під час запуску програми конфигурирования configure можна поставити низку ключів. Зокрема, можна вказати, які методи шифрування сеансу буде використано під час роботи SSH: IDEA, DES, потрійний DES, ARCFOUR і BLOWFISH. За умовчанням основним є алгоритм IDEA, використовує 128-разрядные ключі. Якщо він виключений відповідним ключем, основним алгоритмом стає 3DES — триразове послідовне DES-шифрование з 56-разрядным ключем. Можна виділити також метод BLOWFISH, який за тієї самої довжини ключа (від 32 до 448 розрядів) працює швидше IDEA і DES. Можна поставити також заміну стандартних команд rlogin і rsh відповідними однойменними модулями з дистрибутива SSH. Тоді для сполук використовуватиметься протокол SSH, звісно, якщо віддалений комп’ютер його підтримує. Інакше після попередження буде реалізовано перехід до звичайних r-средствам. Усі можливі ключі конфигурационной програми можна з документації, що йде з дистрибутивом, чи запуском програми з ключем -help.

За умовчанням, якщо шлях ні змінено ключем конфигурационной програми, файли конфігурації OpenSSH за умови встановлення вкладаються у каталог /usr/local/etc/ssh. Після установки цей каталог містить кілька конфігураційних файлів, основними серед яких є файли конфігурації sshd_config і ssh_config серверної і клієнтською частин відповідно. Ці файли мають формат.

и можна використовувати для установки таких параметрів роботи, як, наприклад, необхідність використання аутентифікації серверу з урахуванням імені комп’ютера, аутентифікації користувача з допомогою пароля, протокол який версії SSH (нині існує дві основні версії: SSH версії 1.0 і SSH версії 2.0) необхідно використовувати під час обміну інформацією. Для серверної програми в конфигурационном файлі sshd_config є можливість вказати, якою порту демон sshd прийматиме сполуки (за умовчанням цієї мети використовується порт з номером 22), і навіть який IP адресу мають з’являтися запити. Усі параметри конфігураційних файлів дуже докладно описані у документації, яка поставляється з пакетом OpenSSH.

Практичне застосування розглянутим інформації наводиться в додатку в прикладі 7.

Вывод.

У цьому главі роботи було розглянуті кошти безпеки, якими володіє ОС Linux. У першій частині глави наводиться опис коштів забезпечення локальної безпеки, тобто не враховуючи підключення комп’ютера з ОС Linux до неї. Друга частина орієнтована на проблеми забезпечення мережевий безпеки. Перша частина висвітлює основні можливості файловій системи ext2, наводиться опис програм зміни прав доступу і власника файла chmod і chown, докладно розглядаються атрибути файлів, програми роботи з атрибутами chattr і lsattr. У доповнення до всього наводиться опис пакета lcap для настройки деяких параметрів ядра ОС. Далі розглядається концепція користувальних дискових квот, пакет до роботи з користувальницькими квотами quota. У останньому розділі, присвяченому локальної безпеки, наводиться сучасну технологію аутентифікації з допомогою бібліотеки PAM, розглядаються її можливості, наводиться перелік модулів, які входять у цю бібліотеку, та його опис. Докладно розглядається формат конфігураційних файлів PAM. В другій частині глави розглядається принцип захисту системи від мережного втручання у вигляді межсетевого екрана netfilter, описується алгоритм функціонування межсетевого екрана, розглядається концепція побудови правил фільтрації. Далі наводиться загальний огляд протоколів віддаленого адміністрування і велика увагу приділяється протоколу ассиметричного шифрування SSH, розглядаються принципи роботи цього протоколу, призначення й захопити основні характеристики.

3. Кошти посилення безпеки в Linux.

Крім стандартних коштів організації безпечної роботи Linux дуже багато додаткового системного програмного забезпечення, що дозволяє розширити можливості стандартних засобів і нові, гнучкіші і пристосовані до специфічним умовам. У вона найчастіше стандартні кошти Linux дозволяють домогтися необхідного рівні захисту. Але є ситуації, коли до системи пред’являються підвищені вимоги, і стандартних коштів забезпечення безпеки може досить. У разі через просте рішення може бути використання додаткових програмних пакетов.

3.1. Linux ACLs.

Іноді своєю практикою адміністратор серверу може мати справу з проблемою правильної установки прав доступу. Наприклад, виникла ситуація, коли однією файл необхідно встановити декларація про читання трьом користувачам різних груп, і декларація про читання і виконання для користувача четвертої групи. Вирішення проблеми стандартними засобами є дуже складним завданням. Права доступу в Linux задаються дев’ятьма бітами, що передбачає встановлення прав лише пользователя-владельца, групивласника й інших. Будь-які додаткових можливостей по установці прав доступу до файлу у кімнаті стандартного конфігурації ОС Linux відсутні. Через війну на вирішення завдання може знадобитися внесення користувачів в загальні групи або створення додаткових груп, що не завжди прийнятним і крім іншого створює додаткові проблеми управления.

Оптимальним рішенням ситуації що така може бути програмна розробка Linux ACLs.

Linux ACLs (Access Control Lists) — це набір латок для ядра операційної системи й додатків до роботи з файловій системою та кілька додаткових програм, що дає змогу встановлювати права доступу до файлам як для пользователя-владельца і группы-владельца файла, але й будь-якого користувача і группы.

Linux ACLs використовує розширені атрибути для зберігання даних про права доступу до файлам користувачів і груп. Список розширеного контролю доступу існує кожному за файла у системі і складається з шести компонентів. Перші три є копією стандартних прав доступу до файлу. Вони утримуватися в єдиному примірнику в ACL є в кожного файла в системі:. ACL_USER_OBJ — режим доступу до файлу пользователя-владельца;. ACL_GROUP_OBJ — режим доступу до файлу группы-владельца;. ACL_OTHER — режим доступу до файлу інших пользователей.

Наступні два компонента встановлюються кожному за файла в окремішності і може бути присутнім на ACL у кількох примірниках:. ACL_USER — містить UID і режим доступу до файлу користувача, якому встановлено права, які від основних. На кожного користувача відносини із своїми правами даний файл зберігається окрема запис. Не може існувати більше записи однієї й того користувача;. ACL_GROUP — містить ті ж дані, як і ACL_USER, але для групи користувачів;. ACL_MASK — маска діючих прав доступу для розширеного режима.

При установці додаткових прав доступу присвоюється значення і елементу ACL_MASK.

Каталоги також може мати список контролю доступу за умовчанням. У на відміну від основного ACL, він діє створювані всередині даного каталогу файли і каталоги. Під час створення файла всередині такого каталогу файл отримує ACL, рівний ACL за умовчанням цього каталога.

Для використання Linux ACLs необхідно одержати з сайту розробника пакет Linux ACLs і латки до ядру ОС Linux деяким програмам системного оточення. Спочатку накласти латочку на вихідні файли ядра, щоб заручитися підтримкою аркушів доступу, потім зібрати ядро з підтримкою розширених атрибутів і аркушів контролю доступу. Після складання ядра із підтримкою аркушів доступу потрібно накласти латки певні системні програми розвитку й перезібрати їх. Далі необхідно зібрати пакет додатків ACL, що теж перебуває в сайті розробника. З допомогою додатків цього пакета виробляється управління розширеними правами доступу. Весь процес установки Linux ACLs, починаючи накладенням латок і закінчуючи складанням пакета ACL, докладно описаний в документації програмного пакета.

Після включення до системі підтримки Linux ACLs маніпулювання розширеними атрибутами проводиться за допомогою двох програм, які входять у пакет ACL — getfacl і setfacl. Перша програма дозволяє їм отримати інформацію про розширених правах доступу файла. Друга виробляє зміна цих прав доступу. Синтаксис командних рядків цих програм докладно описаний у man-руководствах пакета.

3.2. LIDS.

LIDS (Linux Intrusion Detection/Defence System) — система виявлення й захисту від вторгнення. Цю систему є доповнення до ядру ОС Linux, добавляющее додаткових можливостей для збільшення безпеки ОС. LIDS дозволяє заборонити чи обмежити доступом до файлам, пам’яті, пристроям, мережним інтерфейсам і запущеним додатків привілейованому користувачеві, що дозволяє можливість надійно захистити навіть зламану операційну систему від подальшого вмешательства.

На відміну з інших засобів захисту ОС Linux, цю систему неможливо відключити, не знаючи пароля адміністратора LIDS, що у зашифрованому вигляді зберігається у спеціальній файлі, видимому лише програмою адміністрування LIDS. Так само захищені і конфігураційні файли LIDS. До того ж система має одну дуже суттєва перевагу: знаючи пароль адміністратора LIDS, систему можна відключити тільки з локальної консолі компьютера.

А, аби з’ясувати LIDS, необхідно включити підтримку цієї системи в ядрі, що потребує накладення латок на вихідні файли ядра і включення можливостей LIDS при конфигурировании ядра до його складання. Після включення до ядрі підтримки LIDS стане доступним список параметрів LIDS. Також пакет LIDS включає програми для настройки цієї системы.

Після установки LIDS в каталозі /etc з’явиться каталог lids, у якому такі конфігураційні файли: lids. cap — цей файл призначений для зберігання поточних значень установок здібностей. lids.net — файл призначений для настройки відправки електронних повідомлень системою LIDS. lids. pw — у тому файлі записаний у зашифрованому вигляді пароль адміністратора. Змінювати цей файл лише з допомогою програми lidsadm пакета LIDS. lids. conf — цей файл містить поточні установки правил доступу. Змінювати цей файл може тільки програму lidsadm.

При установці різних обмежень LIDS використовує звані способности.

Здатність — це можливість програм здійснювати будь-які действия.

Усі здібності встановлюються в файлі /etc/lids/lids.cap. Цей файл має наступний формат: [ + | - ] :

«+» включає відповідну здатність, а «-» виключає її. номер — порядковий номер здібності. здатність — найменування способности.

Редагування файла /etc/lids/lids.cap можна робити з допомогою будь-якого текстового редактора. Включення здібностей впливає все програми без винятку, а вимикання впливає все програми, крім, яким безпосередньо зазначена дана здатність з допомогою правил доступу lidsadm.

Після установки файл /etc/lids/lids.cap містить включеними такі здібності:. CAP_CHOWN — встановлює здатність програм змінювати власника і группу-владельца файла;. CAP_DAC_OVERRIDE — дозволяє програмам, запускаемым привілейованим користувачем, не брати до уваги режими доступу до файлам. При відключенні цієї здібності користувач root втрачає можливість змінювати файли, коли йому безпосередньо не задано права доступу;. CAP_DAC_READ_SEARCH — визначає той самий, як і CAP_DAC_OVERRIDE, лише у тому випадку обмеження поширюється лише з каталоги;. CAP_FOWNER — дозволяє операції з файлами, коли власник файла повинен збігатися з користувачем, що чинять операцію;. CAP_FSETID — дозволяє установку біт SUID і SGID на файлах, котрі належать до користувачеві root;. CAP_KILL — дозволяє процесам привілейованого користувача знищувати інших процесів;. CAP_SETGID, CAP_SETUID — управляє здатністю програм привілейованого користувача змінювати групу і користувача, під якими працює програма;. CAP_SETPCAP — дозволяє програмам змінювати здібності;. CAP_LINUX_IMMUTABLE — управляє здатністю знімати розширені атрибути immutable і append з файлів;. CAP_NET_BIND_SERVICE — дозволяє програмам, выполняющимся немає від імені користувача root, використовувати мережевий порт нижче 1024;. CAP_NET_BROADCAST — управляє здатністю програм розсилати широкомовні пакети;. CAP_NET_ADMIN — параметр управляє велику кількість різних здібностей: конфигурирование мережевих інтерфейсів, зміна правил брандмауэра, зміна таблиць маршрутизації та інших здібностей, що з мережними настройками Linux;. CAP_NET_RAW — управляє здатністю програм використовувати гнізда;. CAP_IPC_LOCK — управляє здатністю процесів привілейованого користувача блокувати сегменти поділюваної пам’яті;. CAP_IPC_OWNER — управляє доступом програм користувача root до ресурсів межпроцессорного взаємодії процесів, котрі належать до користувачеві root;. CAP_SYS_MODULE — управляє здатністю завантажувати модулі ядра;. CAP_SYS_RAWIO — управляє низкоуровневым доступом на чтение/запись до таких пристроям, як /dev/mem, /dev/kmem, /dev/port, /dev/hd*,.

/dev/sd*;. CAP_SYS_CHROOT — управляє здатністю встановлювати кореневої каталог для поточної командної оболонки;. CAP_SYS_PTRACE — дозволяє програмам використовувати виклик функції ptrace (), що дозволяє процессу-родителю управляти виконанням процессов-потомков;. CAP_SYS_PACCT — управляє здатністю конфіґурувати облік процесів;. CAP_SYS_ADMIN — управляє безліччю здібностей: управління устройством.

/dev/random, створення нових пристроїв, конфигурирование дискових квот, настроювання роботи klogd, установка доменного імені комп’ютера, скидання кешу, монтування і размонтирование дисків, включення і відключення розділу віртуальної пам’яті, установка параметрів послідовних портів й багато іншого;. CAP_SYS_BOOT — управляє здатністю перезавантажувати систему;. CAP_SYS_NICE — управляє здатністю змінювати пріоритет процесів, котрі належать до привілейованому користувачеві;. CAP_SYS_RESOURCE — управляє здатністю змінювати граничні значення використання ресурсів системи: дискові квоти, зарезервоване простір на розділах з файлової системою ext2, якомога більше консольных програм, тож таке інше;. CAP_SYS_TIME — управляє здатністю змінювати системне час;. CAP_SYS_TTY_CONFIG — управляє здатністю змінювати настройки пристроїв tty;. CAP_HIDDEN — управляє здатністю програм стає невидимими у списку виконуваних процесів. Не впливає все програми;. CAP_INIT_KILL — управляє здатністю знищувати процессы-потомки процесу init;

Для набрання чинності здібностей, необхідно відразу після завантаження системи та запуску всіх сервісів виконати команду lidsadm -I.

У цю команду зазвичай записується одного з файлів сценаріїв, виконуваних за мінімального завантаження системы.

Крім здібностей система LIDS дозволяє ставити правила доступу до дисковим ресурсів. Усі управління LIDS здійснюється з допомогою програми lidsadm. Ця програма може працювати у двох режимах: режимі настройки правил доступу і режимі введення команд адміністрування. Усі установки правил доступу перебувають у файлі /etc/lids/lids.conf. Для їх перегляду необхідно запустити програму lidsadm з параметром -L. [root@app /]# lidsadm -L LIST Subject ACCESS TYPE Object ——————————————————————————————- Any File READ /sbin Any File READ /bin Any File READ /boot Any File READ /lib Any File READ /usr Any File DENY /etc/shadow /bin/login READ /etc/shadow /bin/su READ /etc/shadow Any File APPEND /var/log Any File WRITE /var/log/wtmp …

Правила доступу складаються із трьох елементів: суб'єкта, об'єкта й мети. Об'єктом є будь-який файл чи каталог, який має діяти правила доступу і захист LIDS. Якщо ролі об'єкта зазначений каталог, то все файли у ньому і вкладені підкаталоги зі своїми файлами автоматично стають объектами.

Суб'єктом є будь-яка захищена програма, якої дають доступом до защищаемому об'єкту. Тому, як використовувати програму ролі суб'єкта, її саму треба захистити засобами LIDS, вживши щодо ній правила доступу як об'єкта. Якщо суб'єкт не зазначений, суб'єктом є будь-яка программа.

Метою є тип доступу суб'єкта об'єкта. Існують такі типи доступу:. READ — доступ для читання;. WRITE — доступ на запис;. DENY — заборона будь-якої доступ взагалі;. APPEND — відкриття лише запис у кінець файла;. IGNORE — ігнорування защиты.

Побудова прав доступу докладно описано у файлах документації і man-руководствах.

3.3. AIDE.

AIDE (Advanced Intrusion Detection Environment) — розширене оточення виявлення вторгнень. Основне призначення програмного продукту AIDE — виявлення зміни файлів, їх атрибутів, прав доступу, користувачів власників, розміру, кількості посилань на файл та інших параметрів, які притаманні файлу в Linux.

Програмний пакет AIDE створює базі даних всіх файлів, переказаних у основному конфигурационном файлі програми aide.conf. У базу крім стандартних атрибутів файла записується також криптографічна контрольна сума чи хэш кожного файла, вирахуваних з допомогою однієї чи комбінації наступних алгоритмів шифрування: SHA1, MD5, RMD160, TIGER.

Відразу після встановлення і настройки необхідних сервісів і програм, але перед підключенням системи до неї, адміністратор повинен створити базу AIDE. Це база міститиме інформацію про файлах у тому початковому вигляді. Зазвичай до контрольованих файлам можна адресувати бінарні файли, виконувані файли, конфігураційні файли системи та програм, заголовкові файли, файли вихідного коду та інші файли, зміну яких після установки мало производится.

До сформування бази даних програма aide запускається з параметром -init. [root@gw /]# aide -init.

Після створення бази її треба перемістити в безпечне місце, де привілейований користувач root має обмежений доступ або має доступу взагалі. Найкращим рішенням буде запис бази на будь-якої зйомний носій інформації, який особливих труднощів можна залучити до системі у будь-якій момент.

Перевірка цілісності файлів виробляється викликом програми aide з параметром -check. [root@gw /]# aide -check.

Програма виконує читання файлів на диску і робить порівнювати з даними з даних. Звіт про проведеної перевірці відразу виводиться на экран.

Програмний пакет AIDE може служити гарним доповненням до базової захисту як засіб профілактики, проте використання цього продукту ролі основний системи захисту небажано. Поза тим, що зломщик може змінитися саму базі даних AIDE, якщо матиме змогу отримати до неї доступ, так само може оцінити зміна файла зі збереженням основних його атрибутів. Природно, підробити контрольну суму файла саме його зміни — нелегке завдання, проте осуществимая.

Вывод.

Ця глава присвячена додатковому програмному забезпеченню, расширяющему стандартні можливості систем Linux у плані безпеки. У першій його частині глави розглядається програмний пакет Linux ACLs, листи доступу з урахуванням розширених атрибутів, програми getfacl і setfacl для роботи з розширеними правами доступу. Друга частина присвячена системі виявлення й захисту від вторгнення LIDS, описуються можливості ядер 2.4 і принципи роботи LIDS з урахуванням цих атрибутів. Також наводиться формат конфігураційних файлів цією системою. Заключний розділ присвячений розширеному оточенню виявлення вторгнень AIDE, описується призначення, принцип роботи і засади конфигурирования.

4. Техніка безопасности.

Цей поділ є доповненням до основний дипломної роботі. У цьому вся розділі розглядаються деякі аспекти безпечної роботи з компьютере.

Серед різних фізичних чинників довкілля, що потенційно можуть надавати несприятливий вплив на чоловіки й біологічні об'єкти, велику складність представляють електромагнітні поля неионизирующей природи, особливо які стосуються радіочастотному випромінюванню. Тут неприйнятний замкнутий цикл виробництва без викиду забруднюючої чинника в навколишню середу, бо я вживаю унікальна здатність радіохвиль поширюватися на далекі відстані. З цієї причини неприйнятно і екранування випромінювання та заміна токсичного чинника в інший, менш токсичний чинник. Неминучість впливу електромагнітного випромінювання на населення та навколишню живу природу стало даниною сучасному технічному прогресу й більше широкому застосуванню телебачення і радіомовлення, радіозв'язку і радіолокації, використання СВЧ-излучающих приладів та так далі. І хоча можлива певна каналізація випромінювання, що вчетверо-вп'ятеро зменшує небажане опромінення населення, і регламентація під час робіт випромінюючих пристроїв, подальший технічний прогрес все-таки підвищує ймовірність впливу електромагнітного випромінювання на человека.

На можливість несприятливого впливу організм людини електромагнітних полів було звернено увагу ще наприкінці 40-х років. У результаті обстеження людей, що працюють у умовах впливу електромагнітних полів значної інтенсивності, засвідчили, що найвідчутнішими до цього впливу є нервова і сердечносудинна система. Описано зміни кровотворення, порушення ендокринної системи, метаболічних процесів, захворювання органів зору. Встановлено, що клінічні прояви впливу радіохвиль найбільш часто характеризуються астеническими і вегетативними реакциями.

У разі тривалого професійного опромінення з періодичним підвищенням гранично допустимих рівнів частина людей відзначали функціональні зміни у органах травлення, що виражаються у зміні секреції і кислотності шлункового соку, соціальній та явищах дискінезії кишечника.

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

Останніми роками з’являються повідомлення про можливість індукції електромагнітного випромінювання злоякісних захворювань. Ще нечисленні дані все-таки кажуть, що найбільше випадків посідає пухлини кровотворних тканин та зокрема лейкоз. Це стає загальної закономірністю канцерогенного ефекту при вплив на організм людини і тварин фізичних чинників різної природи й у низці інших случаев.

Монітори персональних комп’ютерів використав процесі повсякденної діяльності мільйони службовців в усьому світі. Комп’ютеризація нашій країні приймає широкого розмаху, і з сотні тисяч чоловік проводять більшу частину робочого дня перед екраном дисплея. Поруч із визнанням безсумнівною користі застосування комп’ютерна техніка викликає в користувачів персональних комп’ютерів занепокоєння за своє здоровье.

Є статистичні дані, за якими особи, хто з персональним комп’ютером, більш неспокійні, підозрілі, частіше уникають спілкування, і навіть недовірливі, дратівливі, схильні до посиленої самооцінці, зарозумілі, фіксують увагу до неудачах.

Найбільшими джерелами електромагнітних випромінювань є радіоі телевізійні засоби зв’язку і методи обробки інформації, радіолокаційні і навігаційні кошти, лазерні системи, повітряні лінії электропередач.

Серйозного уваги заслуговують питання гігієнічної оцінки рівнів електромагнітного випромінювання, яким піддаються особи, працюють у зоні дії випромінювань, але з пов’язані з обслуговуванням радіотехнічних пристроїв. За даними американського Агентства охорони навколишнього середовища близько 1% людської популяції піддаються впливу електромагнітного випромінювання інтенсивністю більш 1мкВт/см2. У цьому найбільші значення інтенсивності зафіксовано у висотні будинки, особливо у рівнях, відповідних рівням розміщення антенних систем.

На жаль, шкідливий вплив електромагнітного випромінювання пов’язано не тільки з джерелами широкомасштабного випромінювання. Відомо, що магнітне полі виникає навколо будь-якого предмета, працюючого на електричному полі. А це практично будь-який прилад, супроводжуючий нашій побуті (навіть електричні часы).

Дисплеї персональних комп’ютерів, виконані на електронно-променевих трубках, є потенційними джерелами м’якого рентгенівського, ультрафіолетового, інфрачервоного, видимого, радіочастотного, понаді низькочастотного електромагнітного излучения.

Наслідки регулярної роботи з комп’ютером не залучаючи захисних коштів:. захворювання органів зору (60% користувачів);. хвороби серцево-судинної системи (60%);. захворювання шлунково-кишкового тракту (40%);. шкірні захворювання (10%);. різні опухоли.

Особливо небезпечно електромагнітне випромінювання комп’ютера для дітей і вагітних жінок. Встановлено, що з вагітних жінок, працівників комп’ютерах з дисплеями на електронно-променевих трубках, з 90-відсоткової ймовірністю в 1,5 разу частіше трапляються викидні й у 2,5 разу частіше народжуються діти з уродженими пороками.

Деякі допустимі рівні електромагнітних полів наведені у таблиці 4.1.

Таблиця 4.1. Гранично допустимі рівні електромагнітних полів при цілодобовому безупинному випромінюванні |Метричне | |Довжини |Гранично | |підрозділ диапазона|Частоты |хвиль |Допустимий | | | | |Рівень | |Кілометрові хвилі, |30−330 кГц |10−1 км |25 В/м | |низькі частоти | | | | |Гектометровые хвилі, |0,3−3 МГц |1−0,1 км |15 В/м | |середні частоти | | | | |Декаметровые хвилі, |3−30 МГц |100−10 м |10 В/м | |високі частоти | | | | |Метрові хвилі, |30−300 МГц |10−1 м |3 В/м | |Дуже високі частоти | | | | |Дециметрові хвилі, |300−3000 МГц |1−0,1 м |10 мквт/см2 | |Ультравысокие хвилі | | | | |Сантиметрові хвилі, |3−30 ГГц |10−1 див |10 мквт/см2 | |Надвисокі частоти | | | |.

Персональні комп’ютери зайняли міцне місце у діяльності багатьох людей. Нині вже неможливо уявити повноцінну діяльність на підприємствах, у приватному бізнесі, та й у процесі навчання без самого персонального комп’ютера. Але це неспроможна б викликати стурбованості в відношенні їх шкідливого впливу стан здоров’я користувачів. Недооцінка особливостей роботи з дисплеями, крім зниження надійності і ефективності роботи із нею, призводить до істотним проблем із здоровьем.

Рекомендується, наприклад, щоб екран дисплея знаходився від очей користувача з відривом не ближче, ніж 50−70 см.

Режими праці та відпочинку під час роботи з персональним комп’ютером залежить від категорії трудовий деятельности.

Всі роботи з персональним комп’ютером діляться втричі категорії:. Епізодична зчитування і введення інформації трохи більше 2 годин за 8-часовую робочу зміну.. Зчитування інформації, або творча праця трохи більше 4 годин за 8-часовую зміну.. Зчитування інформації, або творча праця понад чотири години за 8-часовую смену.

Тривалість безперервної роботи з персональним комп’ютером не повинна перевищувати 2 часов.

Якщо приміщенні експлуатується більше комп’ютера, слід врахувати, що у користувача одного комп’ютера можуть впливати випромінювання з інших персональних комп’ютерів, насамперед із боку бічних, в тому числі задньої стінки монітора. З огляду на, що з випромінювання зі боку екрана монітора можна захистити застосуванням спеціальних фільтрів, необхідно, щоб користувач розміщався від бічних і задніх стінок інших дисплеїв з відривом упродовж як мінімум метра.

На монітори рекомендується встановлювати захисні фільтри класу повної захисту (Total Shield), що забезпечують практично повний захист від шкідливих впливів монітора в електромагнітному спектрі й дозволяють зменшити відблиск від електронно-променевої трубки, і навіть підвищити читаність символов.

Вывод.

У цьому главі роботи розглядаються аспекти безпечної роботи за комп’ютером, здебільшого глава присвячена електромагнітному випромінюванню електронно-променевих трубок, які у моніторах. У розділі наводиться опис видів випромінювань, нормативні значення цього випромінювання при різних режимах роботи за комп’ютером, і навіть методи і засоби, які дозволяють зводити до мінімуму ризик опромінення під час роботи за компьютером.

Заключение

.

У цьому роботі було виконано огляд коштів безпеки, якими має операційна система Linux для безпечного функціонування як як користувальницької системи, і у ролі сервера.

Діяльність було розглянуто такі теми:. Огляд основних термінів комп’ютерної безпеки, загроза безпеки, вразливість системи, атака й на систему, розглянуті основні види атак;. Користувальні запис у Linux, додавання і видалення користувачів, зміна реєстраційних записів, структура файла користувальних реєстраційних записів passwd, структура файла паролів shadow, програми управління користувальницькими записами useradd, usermod і userdel, програма установки пароля користувача passwd, приклад безпечної настройки системи з допомогою видалення непотрібних реєстраційних записів;. Можливості файлової системи ext2, права доступу, програми зміни прав доступу і власника файла chmod і chown, атрибути файлів, програми роботи з атрибутами chattr і lsattr, пакет lcap, користувальні дискові квоти, пакет до роботи з дисковими квотами quota, приклад безпечної настройки системи з допомогою прав доступу, розширених атрибутів і дискових квот;. Бібліотека PAM, її можливості, методи обмеження ресурсів з помощью.

PAM, перелік модулів PAM та його опис, формат конфігураційних файлов.

PAM, приклад безпечної настройки системи з допомогою обмеження ресурсів;. Безпека лише на рівні ядра, міжмережевий екран netfilter, огляд можливостей брандмауэра netfilter, програмний пакет iptables, використання iptables для настройки брандмауэра Linux, приклад безпечної настройки межсетевого екрана до роботи на небезпечної мережі;. Глухе управління, протоколи Telnet, rsh, SNMP, опис протокола.

SSH, програмний продукт OpenSSH, опис конфігураційного файла демона sshd, приклад настройки безпечного серверу SSH;. Програмний пакет Linux ACLs, листи доступу з урахуванням розширених атрибутів, програми getfacl і setfacl;. Система виявлення й захисту від вторгнення LIDS, можливості ядер 2.4, формат конфігураційних файлів LIDS;. Розширене оточення виявлення вторгнень AIDE, призначення, принцип роботи.. Випромінення монітора, нормативні значення електромагнітних полів для нормальної роботи користувачів за комп’ютером, і навіть кошти й методи зменшення негативного впливу електромагнітного випромінювання на організм человека.

Крім теоретичної частини до кожного поділу при застосуванні наводиться приклад практичного застосування розглянутої матеріалу. Усі приклади, наведені у роботі, були випробувані за умов й успішно реалізовані на серверах Узбецького зовнішньоекономічного інформаційнокомерційного центру «Узинкомцентр» при Агентстві зовнішніх економічних зв’язків Республіки Узбекистан. Зараз захисту роботи мною були проинсталлированы і сім серверів з урахуванням ОС Linux, чотири з яких є серверами загального призначення, решта — спеціалізовані серверу з обмеженою набором функцій. П’ять серверів успішно функціонують по сьогодні. Двоє скасовані за ненадобностью.

1. Linux. Олексій Стахнов, видавництво «БХВ-Петербург», Санкт-Петербург,.

2002. 2. Технічна електронна документація по операційній системі Linux.

Приложение.

ПРИКЛАД 1.

Вихідні дані: ОС Linux RedHat 7.3 без графічної оболонки. Призначення — маршрутизатор.

Завдання: видалити невикористовувані реєстраційні запису і додати три записи. Необхідно додати користувачів anna і pavel, і навіть одного користувача безпосередньо з ім'ям systemuser для системних нужд.

Реализация.

Спочатку файл користувальних реєстраційних записів може мати такий вигляд: root: x:0:0:root:/root:/bin/bash bin: x:1:1:bin:/bin:/sbin/nologin daemon: x:2:2:daemon:/sbin:/sbin/nologin adm: x:3:4:adm:/var/adm:/sbin/nologin lp: x:4:7:lp:/var/spool/lpd:/sbin/nologin sync: x:5:0:sync:/sbin:/bin/sync shutdown: x:6:0:shutdown:/sbin:/sbin/shutdown halt: x:7:0:halt:/sbin:/sbin/halt mail: x:8:12:mail:/var/spool/mail:/sbin/nologin news: x:9:13:news:/etc/news: uucp: x:10:14:uucp:/var/spool/uucp:/sbin/nologin operator: x:11:0:operator:/root:/sbin/nologin games: x:12:100:games:/usr/games:/sbin/nologin gopher: x:13:30:gopher:/var/gopher:/sbin/nologin ftp: x:14:50:FTP User:/var/ftp:/sbin/nologin nobody: x:99:99:Nobody:/:/sbin/nologin rpm: x:37:37:/var/lib/rpm:/bin/bash.

Залежно від встановлених програм, зміст цього файла може відрізнятиметься від приведенного.

Із міркувань безпеки слід видалити такі невикористовувані в даної конфігурації серверу системні записи: adm, lp, shutdown, halt, news, operator, games, gopher, ftp. Системна запис lp використовується лише у разі, якщо комп’ютера підключений принтер. Налагоджуваний комп’ютер виконує функції маршрутизатора, отже ця реєстраційна запис є зайвою. Записи shutdown і halt дозволяють звичайним програмам вимикати комп’ютер, що з серверу є лише додатковою проломом безпечно. Записи news, gopher і ftp використовують у тому випадку, якщо сервер виконує функції служби новин, серверу GOPHER чи FTP-сервера. Облікова запис games використовується програмами графічного інтерфейсу, а оскільки він відсутня на маршрутизаторе, ця облікова запис теж є лишней.

Для видалення користувачів необхідне кожної облікової записи виконати команду userdel.

У реалізації це буде так: [root@gw /]# userdel adm [root@gw /]# userdel lp [root@gw /]# userdel shutdown [root@gw /]# userdel halt [root@gw /]# userdel news [root@gw /]# userdel operator [root@gw /]# userdel games [root@gw /]# userdel gopher [root@gw /]# userdel ftp.

Перша частина поставленого завдання виконано. Далі треба додати зазначених користувачів. [root@gw /]# useradd -m -p.s /bin/bash -з ‘Normal User' -d /home/pavel -g users pavel [root@gw /]# useradd -m -p.s /bin/bash -з ‘Normal User' -d /home/pavel -g users anna [root@gw /]# useradd -r -p.s /sbin/nologin -з ‘System User' -d /var/empty systemuser.

Наведені команди створюють на системі зазначених користувачів, проте, для входу до системи звичайним користувачам додатково до всього слід поставити що й пароль. Це виконують наведені нижче команди. [root@gw /]# passwd anna Changing password for user anna. New password: Retype new password: passwd: all authentication tokens updated successfully. [root@gw /]# passwd pavel Changing password for user pavel. New password: Retype new password: passwd: all authentication tokens updated successfully.

Через війну вироблених дій система міститиме все необхідних нормально функціонувати системні реєстраційні записи, і навіть двох користувачів anna і pavel, зможуть заходити і працювати у системе.

ПРИКЛАД 2.

Вихідні дані: ОС Linux RedHat 7.3 без графічної оболонки. Призначення — сервер додатків. Програмне забезпечення — web-сервер Apache, FTP-сервер Proftpd. Web-сервер виконується від імені системного користувача nobody, FTP-сервер — від імені системного користувача ftpuser. Обидва користувача входять до групи nogroup. На сервері працює web-портал, має розподілену структуру. Весь портал ділиться на 2 частини: администрируемую частина — динамічні дані і неадминистрируемую частина — статичні дані чи оболонка. Адміністрування динамічної частини може здійснюватися як за допомогою протоколу FTP, і з допомогою спеціально розробленого web-интерфейса. Статичні дані може змінювати лише привілейований користувач і лише за допомогою термінального доступа.

Завдання: настроювання захищеної конфігурації web-портала з допомогою коштів розмежування прав доступа.

Реализация.

Припустимо, що це файли об'єкта захисту, тобто web-портала, перебувають в директорії /www. Натомість, директорія /www містить каталоги ftp і html: перший — для збереження і доступу до файлам по FTP протоколу, другий — для доступу до файлам за протоколом HTTP. Задля більшої захисту файли, перебувають у каталозі /www, повинен мати доступ лише з читання для користувачів nobody і ftpuser. Файли, перебувають у каталозі /www/ftp, мають бути доступними для читання і запис як користувачеві ftpuser, і користувачеві nobody. Натомість, файли каталогу /www/html би мало бути доступні лише користувачеві nobody і з правами лише з читання. Привілейований користувач має декларація про читання і запис, незалежно від прав доступу, встановлених для файла.

З огляду на, що обидві користувача nobody і ftpuser належать однієї групі nogroup, права на каталог /www можуть бути наступним чином: [root@app /]# chmod 050 /www [root@app /]# chown root: nogroup /www [root@app /]# ls -l … d—-r-x—- 1 root nogroup 4096 Фев 7 19:48 www …

Перша команда встановлює права лише з читання і вхід до каталогу для користувачів группы-владельца каталогу. Друга команда змінює групувласника каталогу на групу nogroup. Третя команда дозволяє переглянути зроблені зміни. Як очевидно з результату виконання третьої команди, каталог www тепер повинен доступу для групи лише з читання і вхід, для пользователя-владельца й інших будь-які права відсутні вообще.

Тепер, коли доступ до каталогу www мають обидва системних користувача, необхідно розмежувати права на внутрішні каталоги www. [root@app www]# chown -R ftpuser: nogroup /www/ftp [root@app www]# chmod -R o-rwx /www/ftp [root@app www]# chmod -R ug+rw /www/ftp [root@app www]# chown -R nobody: root /www/html [root@app www]# chmod -R go-rwx /www/html [root@app www]# chmod -R u+r /www/html [root@app www]# ls -l /www drwxrwx—- 1 ftpuser nogroup 4096 Фев 7 19:55 ftp dr-x——— 1 nobody root 4096 Фев 7 20:01 html.

Перша команда змінює группу-владельца і пользователя-владельца для каталогу ftp, друга — скасовує всі права для операцій з файлами всім інших, третя — додає права для читання і запис для користувачавласника і группы-владельца. Ключ -R дозволяє рекурсивно змінити параметри у поточного каталогу й всіх підкаталогів і файлів, які у ньому. Наступна команда «chown -R nobody: root /www/html» дозволяє змінити пользователя-владельца до каталогу html всіх його підкаталогів і файлів до користувача nobody. Команда «chmod -R go-rwx /www/html» скасовує всі права для группы-владельца й інших. Далі команда «chmod -R u+r /www/html» встановлює права лише з читання для пользователя-владельца. Остання команда виводить результат виконаних операцій на екран. Завдання выполнена!

слід зробити маленьке зауваження: вищенаведене вірно лише у тому випадку, якщо маска створення файла за умовчанням під час створення каталогів і файлів було визначено як 022 (umask 022). Інакше дії, які необхідно зробити для установки необхідних прав доступу, залежить від конкретних настройок системы.

ПРИКЛАД 3.

Вихідні дані: ОС Linux RedHat 7.3 без графічної оболонки. Програмне забезпечення — пакет lcap. У разі функціональне призначення серверу істотною ролі не играет.

Завдання: зробити настроювання комплексної захисту серверу з використанням розширених атрибутів (зокрема, з допомогою атрибута immutable).

Реализация.

Задля реалізації поставленого завдання необхідно спочатку визначити, які файли своєю практикою можуть змінитися, а які може бути змінені лише у спеціальний режим, наприклад, лише у режимі профілактики чи відновленні програмного забезпечення. У разі спеціальний режим передбачає переведення системи в однокористувальницький режим работы.

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

/boot /etc — в остаточно налаштованої системі вміст цих каталогів змінюватися на повинен. За рідкісними винятками вміст каталогу /etc не може змінюватися при перенастройке будь-яких програм чи сервисов.

/bin — каталог містить виконувані файли, які можна змінені, віддалені чи додано лише за відновленні програмного обеспечения.

/sbin — в каталозі зберігаються виконувані файли системних програм, більшість із яких доступно виконання лише привілейованому користувачеві й теж має змінюватись під час роботи системы.

/lib — каталог системних бібліотек, що можуть змінитися лише за відновленні програмних продуктов.

Наступні команди дозволяють встановити атрибут immutable для перелічених вище директорій і всіх файлів, що у них. [root@app /]# chattr -R +і /boot /etc /bin /sbin /lib [root@app /]# lsattr —-і————— ./boot … —-і————— ./etc ——————— ./root —-і————— ./bin ——————— ./initrd —-і————— ./lib … —-і————— ./sbin.

Параметр -R як й у попередніх прикладах використовується для рекурсивної установки атрибута всім файлів і каталогів, розташованих нижчий за иерархии.

Каталог /usr має власну власну ієрархію. У цьому ієрархії такі каталоги повинен мати встановлений прапор immutable:

/usr/bin /usr/sbin /usr/lib /usr/local/bin /usr/local/sbin /usr/local/lib — перелічені каталоги мають те ж значення, як і однойменні каталоги кореневої иерархии.

/usr/include /usr/local/include — обидва каталогу містить заголовкові файли для компилируемых програм. Заголовкові файли нічого не винні змінюватися ані за яких умовах, ну хіба що тоді, коли комп’ютер використовується і розробити програмного забезпечення й у заголовкові файли вносяться зміни. [root@app /]# chattr -R +і /usr/bin /usr/sbin /usr/lib /usr/include [root@app /]# lsattr /usr ——————— /usr/lost+found —-і————— /usr/bin —-і————— /usr/lib ——————— /usr/libexec —-і————— /usr/sbin … —-і————— /usr/include ——————— /usr/local —-і————— /usr/src …

Насамкінець всіх операцій можна виконати програму lcap з параметрами CAP_LINUX_IMMUTABLE і CAP_SYS_RAWIO: [root@app /]# lcap CAP_LINUX_IMMUTABLE [root@app /]# lcap CAP_SYS_RAWIO.

Слід також встановити запуск цієї команди у стартові сценарії, що вони виконувалися за будь-якої завантаженні системы.

Наведений приклад, знов-таки, не завжди застосовним, все залежить від конкретної конфігурації системи та конкретних умов її эксплуатации.

ПРИКЛАД 4.

Вихідні дані: ОС Linux RedHat 7.3 без графічної оболонки. Призначення — сервер додатків. Програмне забезпечення — ядро версії 2.4.20, зібране із підтримкою користувальних квот, пакет quota-3.11. Для користувальних каталогів виділено окремий розділ /dev/hda3 обсягом 25 Гбайт, змонтований в директорії /home.

Завдання: організувати поділ дискового простору між користувачами через механізм квот. Кожному користувачеві необхідно виділити по 10 Мбайт дискового простору з максимальним кількістю можливих файлів — 1000.

Реализация.

Користувальні квоти поширюються на окремий розділ жорсткого диска і активізуються за мінімального завантаження системи. Для включення підтримки квот необхідна за файлі /etc/fstab для розділу /home додати параметр usrquota чи grpquota, чи обидва цих параметра, якщо потрібна підтримка квоти для користувачів і груп одночасно. У разі для реалізації поставленого завдання потрібні лише параметр usrquota.

Рядок файла /etc/fstab, належить поділу /home, після зміни може мати такий вигляд: /dev/hda3 /home ext2 default, usrquota 1 2.

Оскільки версії ядер починаючи з гілки 2.4 підтримують новий формат користувальних квот, який має деякими перевагами перед старої версією, використання нової версії буде набагато доцільнішим. Уся наступна настроювання здійснюється з цим учетом.

Для активації користувальних квот необхідно перезавантажити систему. При завантаженні необхідні перевірку квотируемого розділу, які можна зробити запуском програми quotacheck, і навіть включити механізм квот її виконанням quotaon. Ці обидві програми мають безліч параметрів командної рядки, про які довідатися з цієї man-руководств, які входять у пакет quota. Стандартна рядок запуску цих програм, яка адресований більшості систем, може мати вид: quotacheck -aug quotaon -aug.

Параметр командної рядки -a повідомляє програмі, що необхідно виконати перевірку всіх файлових систем, переказаних у файлі fstab, на яких включена підтримка квот, і який є файловими системами NFS. Параметр -u вказує виконати перевірку квот для користувачів на розділах, переказаних у файлі /etc/mtab. Файл /etc/mtab модифікується при монтуванні і размонтировании будь-який файлової системи та містить все файлові системи, змонтовані на момент. Параметр -g виконує таку ж функцію, як і параметр -u, але для груп. Останній параметр має значення, якщо квота включена лише користувачів, але, щоб надалі за зміни конфігурації не виникало проблем, рекомендую додавати цей параметр.

Бажано зробити, щоб механізм квот активировался відразу після монтування файлових систем. Монтування файлових систем під час запуску Linux RedHat виконується в файлі /etc/rc.d/init.d/rc.sysinit. У тому ж файлі відразу після монтування слід код, який запускає програми quotacheck і quoaton з зазначеними параметрами, якщо вони є в системі. Отже, для Linux RedHat додавати код запуску програм не потрібно, оскільки вона вже присутній за умовчанням. Для інших версій ОС Linux цей код, можливо, доведеться додавати вручную.

Під час завантаження системи програма quotacheck виконає перевірку файлових систем з увімкненими квотами на наявність файлів квот і, якщо файли відсутні, quotacheck створить в кореневому каталозі цієї файловою системи. У разі в каталозі /home з’явиться файл aquota. user, в якому зберігатися інформацію про користувальних квотах.

Далі, використовуючи програму setquota, необхідні надстройку квот кожному за користувача, має домашній каталог розділ /home. Це можна зробити командою: [root@app /]# setquota -u 10 240 0 1000 0 /dev/hda3.

Наведена команда встановить обмеження дискового простору удесятеро Мбайт з максимальною кількістю можливих файлів — 1000 для зазначеного користувача. Для користувача anna ця команда матиме вид: [root@app /]# setquota -u anna 10 240 0 1000 0 /dev/hda3.

Якщо квота інших користувачів мусить бути ідентична наведеної, що саме і потрібно реалізації, квоту користувача anna можна використовувати як шаблон. Далі під час створення квоти для користувача igor параметри квотування користувача anna просто копіюються: [root@app /]# setquota -u -p anna igor /dev/hda3.

У виконання команди користувач igor отримує самі настройки квоти, як і користувач anna, у разі йому виділяється 10 Мбайт за зберігання 1000 файлів. Вищенаведену команду необхідні всім користувачів системы.

Перегляд зроблених настройок дозволяє виконати програма repquota. Виклик програмних засобів з параметрами -a виводить досить чіткий докладний звіт за всі файловим системам з включеної підтримкою квот. [root@app /]# repquotaa *** Report for user quotas on device /dev/hda3 Block grace time: 00:00; Inode grace time: 00:00.

Block limits File limits User used soft hard grace used soft hard grace ———————————————————————————————— … anna — 4 2 097 152 0 1 0 0 igor — 4 2 097 152 0 1 0 0 …

Задля більшої надійності роботи механізму квот, потрібен час від часу виробляти перевірку цілісності файла aquota. user щодо наявності помилок. З цією метою можна використовувати программу-планировщик cron, що є стандартної практично всім версій ОС Linux. Зараз перевірки файловою системи рекомендується відключити підтримку механізму квот з цією файлової системи щоб уникнути ушкоджень. Для цього перед запуском quotacheck необхідні програму quotaoff. Виконання зазначеної послідовності можна реалізувати, створивши окремий виконуваний файл, наприклад /usr/sbin/chkquota, що мати таке зміст: #!/bin/bash.

# Turn off quotas quotaoff -aug.

# Check quotas quotacheck -aug.

# Turn on quotas quotaon -aug.

Тоді рядок запуску перевірки квот в конфигурационном файлі /etc/crontab програми cron може бути так: 0 3 * * 0 root /usr/sbin/chkquota.

Ця конфігурація дозволяє виконувати перевірку квот щонеділі тепер у 3 години ночі. Для детального ознайомлення з форматом файла /etc/crontab існують man-руководства, включені в окремий пакет cron.

ПРИКЛАД 5.

Вихідні дані: ОС Linux RedHat 7.3 без графічної оболонки. Призначення — сервер додатків. Програмне забезпечення — бібліотека pam- 0.75−32.

Завдання: налаштувати обмеження ресурсів, які у процесі роботи, для користувачів групи users. Необхідно обмежити кількість одночасно запущених процесів до 20, величезну кількість водночас відкритих файлів до 30 і заборонити створення будь-яких файлів ядра.

Реализация.

Обмеженням ресурсів займається модуль pam_limits. Цей модуль використовує файл конфігурації /etc/security/limits.conf, у якому задаються необхідні параметри обмеження. Файл складається з рядків, кожна у тому числі визначає обмеження визначений вид ресурсу. Формат рядки следующий:

Суб'єктом обмеження може або одиночний користувач, або група, що визначається додаванням знака @ перед її ім'ям, або значок *, що означає, що обмеження має поширюватися усім без винятку. Задля реалізації завдання суб'єктом обмеження служитиме слово @users.

Тип ресурсу може або soft, або hard. Значення soft задає м’яке обмеження використання зазначеного ресурсу, а значення hard визначає жорстке чи абсолютне граничне значення використання ресурсу. Задля реалізації завдання найкращим чином вказати жорстке обмеження попри всі види ресурсов.

Об'єкт обмеження вказує, який вид ресурсу поширюється це обмеження. Задля реалізації завдання у ролі ограничиваемых об'єктів необхідно вказати такі параметри: nproc — величезну кількість водночас запущених процесів. Повинно мати значення 20. nofile — величезну кількість водночас відкритих файлів. Мабуть встановлено за 30 я. core — розмір файла ядра. Для заборонити створення файлів ядра значення цього параметра має бути встановлено в 0.

Через війну файл /etc/security/limits.conf матиме вид: @users hard nproc 20 @users hard nofile 30 @users hard core 0.

А, щоб активізувати обмеження ресурсів конкретної докладання, виклик модуля pam_limits треба додати в відповідний файл сценарію бібліотеки PAM. Для локального входу користувачів цим додатком є програма login, має однойменний файл сценарію в каталозі /etc/pam.d. Після модифікації файл /etc/pam.d/login може бути так: #%PAM-1.0 auth required pam_securetty.so auth required pam_stack.so service=system-auth auth required 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 optional pam_console.so session required pam_limits.so.

Останній рядок наказує бібліотеці PAM використовувати модуль pam_limits, причому успішне проходження крізь цей модуля є необхідним завершення процесу аутентифікації в целом.

Для термінального доступу за протоколом ssh виклик модуля pam_limits слід також додати в файл /etc/pam.d/sshd. У результаті файл може бути такою: #%PAM-1.0 auth required pam_stack.so service=system-auth auth required 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 optional pam_console.so session required pam_limits.so.

Під час такої конфігурації як локальний, і віддалений доступ для користувачів групи users матиме обмеження на зазначені ресурсы.

ПРИКЛАД 6.

Вихідні дані: ОС Linux RedHat 7.3 без графічної оболонки. Призначення — маршрутизатор. Програмне забезпечення — iptables-1.2.5, ядро версії 2.4.22, зібране із підтримкою netfilter і iptables. На сервері встановлено три мережні карти. З допомогою двох мережевих карт під символічними іменами eth0 і eth1 сервер пов’язує дві локальні TCP/IP мережі з різними діапазонами IP адрес. Першу мережу має адресу 192.168.0.0, друга — 192.168.1.0, обидві мережі мають маску 255.255.255.0. Мережевий карта eth0 має IP адресу 192.168.0.1, а eth1 — 192.168.1.1. Третя мережна карта під символічною ім'ям eth2 має реальний мережевий адресу 144.333.333.333 забезпечує вихід Интернет.

Завдання: налаштувати міжмережевий екран з підвищеними вимогами до безпеки. З Інтернету необхідно відкрити доступом до HTTP-серверу, поштової службі, функціонуючої за протоколом SMTP, серверу імен DNS, а також термінальний доступ за протоколом SSH. Комп’ютери обох локальних мереж крім перелічених сервісів повинен мати можливість отримувати пошту з локального серверу у вигляді протоколу POP3. Слід також забезпечити обміну інформацією між комп’ютерами двох локальних мереж, забезпечити вихід комп’ютерів мережі 192.168.0.0 до Інтернету, та якщо з мережі 192.168.1.0 — лише комп’ютерів з IP адресами 192.168.1.30 і 192.168.1.45.

Реализация.

Щоб маршрутизатор функціонував як шлюзу, в ядрі необхідно поміняти значення перемінної ip_forward. Це можна зробити командою наведеної далі, а щоб ця змінна встановлювалася один за мінімального завантаження, необхідна за файлі /etc/sysctl.conf знайти й раскомментировать, якщо вона закомментирована, рядок виду «net.ipv4.ip_forward = 0» й змінити значення 0 у цій рядку на 1. Якщо ж виникає такий рядки немає, її треба додати. Отже, маршрутизатор отримує вказівку працювати у ролі шлюзу, тобто обробляти пакети, що зі сіті й не адресовані локальним процесам, відповідно до заздалегідь заданої таблицею маршрутизації. Включення цієї функції необхідне забезпечення доступу у мережу Інтернет з цих двох локальних мереж. [root@app /]# echo 1 > /proc/sys/net/ipv4/ip_forward.

Далі наводиться послідовність дій, які потрібно виконати, щоб побудувати необхідну конфігурацію брандмауэра. [root@app /]# /sbin/iptables -t filterP INPUT DROP [root@app /]# /sbin/iptables -t filterP OUTPUT DROP [root@app /]# /sbin/iptables -t filterP FORWARD DROP.

Параметр командної рядки -Р дозволяє визначити політику дії з вмовчанням всім пакетів, які потрапили ні під один критерій в правилах INPUT, OUTPUT і FORWARD. Дія DROP означає, що пакет повинен бути знищено, якщо жодна правило ланцюжка їй немає відповідає. Параметр -t вказує, над який таблицею виробляється дію. Якщо це параметр не зазначений, використовується таблиця filter, тому використання цього параметра у разі не обязательно.

Для розподілу навантаження і простоти під управлінням можна створити у таблиці filter додаткові ланцюжка з різними функціональним призначенням. [root@app /]# /sbin/iptablesN bad_tcp_packets [root@app /]# /sbin/iptablesN allowed [root@app /]# /sbin/iptablesN tcp_packets [root@app /]# /sbin/iptablesN udp_packets [root@app /]# /sbin/iptablesN icmp_packets.

Ланцюжок bad_tcp_packets варта отфильтровывания пакетів з «неправильними «заголовками. Тут відфільтровуються все пакети, які розпізнаються як NEW, тобто пакети, що відкривали нове з'єднання, але з є SYN пакетами, тобто частина пакета, відповідальна за синхронізацію, відсутня, а як і обробляються SYN/ACK-пакеты, мають статус NEW. Ця ланцюжок можна використовувати захисту від вторгнення і сканування портів. [root@app /]# /sbin/iptablesA bad_tcp_packetsp tcp —tcp-flags SYN, ACK SYN, ACKm state —state NEWj REJECT —reject-with tcp-reset [root@app /]# /sbin/iptablesA bad_tcp_packetsp tcp ! —synm state — state NEWj LOG —log-prefix «New not syn: «[root@app /]# /sbin/iptablesA bad_tcp_packetsp tcp ! —synm state — state NEWj DROP.

Ланцюжок tcp_packets є фільтром мережевих сервісів. Саме в ланцюжку здійснюватиметься фільтрація tcp-соединений критерієм цього сервісу. Як такого критерію використовується порт, на який надходять запити обслуговування. А, аби тільки користувачі локальної мережі отримували пошту, на минулих двох правилах як додатковий критерію фільтрації використовуються символічні імена мережевих інтерфейсів локальних мереж. Як дії пакет посилається в ланцюжок allowed для наступної перевірки більш низького рівня. [root@app /]# /sbin/iptablesA tcp_packetsp TCP —dport 22 -j allowed [root@app /]# /sbin/iptablesA tcp_packetsp TCP —dport 25 -j allowed [root@app /]# /sbin/iptablesA tcp_packetsp TCP —dport 80 -j allowed [root@app /]# /sbin/iptablesA tcp_packetsp TCP -і eth0 —dport 110 -j allowed [root@app /]# /sbin/iptablesA tcp_packetsp TCP -і eth1—dport 110 -j allowed.

Ланцюжок allowed використовується для додаткової фільтрації tcp пакетів, минулих ланцюжок tcp_packets і прийнятих у ній. Перше правило перевіряє, встановлено у заголовку пакета біт SYN, тобто, чи є пакет першим пакетом встановлення сполуки. Такі пакети вважаються дозволеними і пропускаються. Друге правило перевіряє стан пакета, і коли вона або ESTABLISHED, або RELATED, то пакет дозволяється. Ці стану присвоюються пакетів, коли з'єднання вже встановлено й ведеться обмін даними. Останнє правило просто скидає й інші пакети, не потрапили під перші двоє правила. [root@app /]# /sbin/iptablesA allowedp TCP —synj ACCEPT [root@app /]# /sbin/iptablesA allowedp TCPm state —state ESTABLISHED, RELATEDj ACCEPT [root@app /]# /sbin/iptablesA allowedp TCPj DROP.

Ланцюжок udp_packets має таку ж функцію, як і ланцюжок tcp_packets, з єдиним відзнакою — у цьому ланцюжку виробляється фільтрація udpсполук. Сервіс DNS використовує саме протокол UDP обмінюватись інформацією, тому правило, що буде вирішувати пакети DNS, треба додати саме у цей тендітний ланцюжок. [root@app /]# /sbin/iptablesA udp_packetsp UDP —dport 53 -j ACCEPT.

Ланцюжок icmp_packets варта фільтрації icmp-пакетов. Для нормально функціонувати серверу Linux у мережі досить дозвіл лише двох типів повідомлень: ICMP Echo Request і Time Exceeded. [root@app /]# /sbin/iptablesA icmp_packetsp ICMP —icmp-type 8 -j ACCEPT [root@app /]# /sbin/iptablesA icmp_packetsp ICMP —icmp-type 11 -j ACCEPT.

Вкотре хочу помітити, що у вмовчанням без використання параметра -t всі дії виробляються в таблиці filter.

Тепер час торкнутися заповнення основних системних таблиць. Почати з яка входить ланцюжка INPUT таблиці filter. [root@app /]# /sbin/iptablesA INPUTp tcpj bad_tcp_packets [root@app /]# /sbin/iptablesA INPUTі lo -p.s 127.0.0.0/8 -j ACCEPT [root@app /]# /sbin/iptablesA INPUTі lop. s 192.168.0.1 -j ACCEPT [root@app /]# /sbin/iptablesA INPUTі lop. s 192.168.1.1 -j ACCEPT [root@app /]# /sbin/iptablesA INPUTі lop. s 144.333.333.333 -j ACCEPT [root@app /]# /sbin/iptablesA INPUTm state —state ESTABLISHED, RELATEDj ACCEPT [root@app /]# /sbin/iptablesA INPUT -p TCPj tcp_packets [root@app /]# /sbin/iptablesA INPUTp UDPj udp_packets [root@app /]# /sbin/iptablesA INPUTp ICMPj icmp_packets [root@app /]# /sbin/iptablesA INPUTm limit —limit 3/minute —limitburst 3 -j LOG —log-level DEBUG —log-prefix «IPT INPUT packet died: «.

Спочатку все пакети повинні відбутися через ланцюжок bad_tcp_packets на предмет неправильного заголовка. Далі необхідно ухвалити все пакети, які прийшли від усіх адрес мережевих карт через локальний інтерфейс. Такі пакети можуть посилати лише локальні докладання, для їх нормально функціонувати необхідно пропускати ці пакети безперешкодно. Потім правило що б стан пакета. Якщо пакет перебуває у одному з цих двох станів (RELATED чи ESTABLISHED), він теж безперешкодно дозволяється. Річ у тім, що настроювання брандмауэра передбачає 99-процентную достовірність фільтрації які приходять запитів, тому, якщо з'єднання було дозволено на етапі встановлення, то, при наступному обмін інформацією критерії сервісу не перевіряються, що дозволяє трохи збільшити швидкість обробітку грунту і зменшити навантаження на сервер.

Якщо пакет не задовольняє жодному з вище перерахованих умов, далі йдуть правила, у яких пакет класифікується на кшталт використовуваного протоколу. Пакети протоколів TCP, UDP і ICMP потрапляють у однойменні ланцюжка їхнього фільтрації на кшталт цього сервісу. Якщо пакет проходить одну з цих ланцюжків, і до нього було застосовано дію ACCEPT, тобто пакет перестав бути запитом до дозволеному сервісу, спочатку відбувається запис параметрів запиту в журнальний файл (дію LOG), та був застосовується політика за умовчанням ланцюжка INPUT, тобто пакет просто знищується. [root@app /]# /sbin/iptablesA FORWARDp tcpj bad_tcp_packets [root@app /]# /sbin/iptablesA FORWARDm state —state ESTABLISHED, RELATEDj ACCEPT [root@app /]# /sbin/iptablesA FORWARDі eth0 -p.s 192.168.0.0/24 -j ACCEPT [root@app /]# /sbin/iptablesA FORWARDі eth1 -p.s 192.168.1.30 -j ACCEPT [root@app /]# /sbin/iptablesA FORWARDі eth1 -p.s 192.168.1.45 -j ACCEPT [root@app /]# /sbin/iptablesA FORWARDm limit —limit 3/minute —limitburst 3 -j LOG —log-level DEBUG —log-prefix «IPT FORWARD packet died: «.

Аналогічно ланцюжку INPUT, пакети, які відбуваються транзитом, спочатку фільтруються щодо неправильного заголовка з допомогою таблиці bad_tcp_packets. Пакети вже встановленого сполуки дозволяються без додаткових перевірок. Далі все пакети, що зі інтерфейсу eth0, з якого до сервера підключена мережу 192.168.0.0, дозволяються, що дозволяє всім користувачам мережі 192.168.0.0 працювати у Інтернет. Проте, які були необхідно налаштувати NAT, що й зроблено далі. [root@app /]# /sbin/iptablest natA POSTROUTINGo eth2 -j SNAT —tosource 144.333.333.333.

Наведена команда додає в ланцюжок POSTROUTING таблиці nat правило, яке змінює адрес-источник у пакета, покидає сервер через інтерфейс eth2, тобто пакета, що має бути відправлений у мережу Інтернет, на адресу інтерфейсу серверу. Через війну комп’ютер, яка має немає реального адреси у мережі Інтернет, має можливість у вигляді локального серверу обмінюватися інформацією із кожним сервером з Інтернету. [root@app /]# /sbin/iptablesA OUTPUTp tcpj bad_tcp_packets [root@app /]# /sbin/iptablesA OUTPUTp. s 127.0.0.0/8 -j ACCEPT [root@app /]# /sbin/iptablesA OUTPUTp. s 192.168.0.1 -j ACCEPT [root@app /]# /sbin/iptablesA OUTPUTp. s 192.168.1.1 -j ACCEPT [root@app /]# /sbin/iptablesA OUTPUTp. s 144.333.333.333 -j ACCEPT [root@app /]# /sbin/iptablesA OUTPUTm limit —limit 3/minute —limitburst 3 -j LOG —log-level DEBUG —log-prefix «IPT OUTPUT packet died: «.

Для ланцюжка OUTPUT необхідно вказати, з яких IP адрес вирішувати пакети. Тут мають бути перераховані все адреси, привласнених мережним картам сервера.

Наприкінці створених правил необхідно зберегти командою [root@app /]# /sbin/iptables-save > /etc/sysconfig/iptables.

Надалі за мінімального завантаження серверу цих правил автоматично будуть завантажені в ядро.

У цьому надстройку брандмауэра вважатимуться оконченной.

ПРИКЛАД 7.

Вихідні дані: ОС Linux RedHat 7.3 без графічної оболонки. Призначення — маршрутизатор. Програмне забезпечення — пакет OpenSSH- 3.6.1p2.

Завдання: виконати безпечну настроювання сервісу SSH з урахуванням уязвимостей в версії SSH 1.0.

Реализация.

Версія 1.0 протоколу SSH має вразливість, що дозволяє при певних умов отримання доступу з правами привілейованого користувача. Версія 2.0 від цього недоробки у системі безпеки позбавлена, тому її використання буде найоптимальнішим рішенням. Налаштування сервісу SSH по мовчанню дозволяє вживати обидві версії протоколу, вибір ввозяться залежність від того, який протокол підтримує клієнтська програма. Щоб явно заборонити використання протоколу версії 1.0, необхідна за файл конфігурації sshd_config внести наступний рядок Protocol 2.

Ця рядок вказує демону sshd використовувати лише протокол версії 2.0. Інакше, якщо клієнт запросить дозволу відкриття сеансу з допомогою протоколу 1.0, запит буде отвергнут.

OpenSSH версії 3.6 і спроби деяких попередніх версій має спеціальний параметр UsePrivilegeSeparation, що дозволяє запускати процес sshd від імені аутентифицированного користувача. Потому, як користувач успішно пройшов аутентификацию, основний процес sshd, запущений від імені привілейованого користувача, передає управління додатковому процесу sshd, виконуваному вже від імені аутентифицированного користувача. Така технологія дозволяє досягнути високого рівня безпеки проти попередніми версіями пакета OpenSSH, у яких доступ користувачів контролювався процесом, запущеним з правами користувача root. Конфігурація демона за умовчанням вже використовує цей параметр, однак у деяких попередніх версіях цей параметр виключений. Для активації поділу користувальних привілеїв в файл sshd_config треба додати рядок UsePrivilegeSeparation yes.

Якщо складання пакет здійснювалася із вихідних файлів, для настройки поділу привілеїв необхідно зробити кілька додаткових операцій. Ці операції добре документовані і послідовність їх виконання в документації встановлення пакета OpenSSH розписана практично по шагам.

Щоб обмежити доступ привілейованому користувачеві, можна використовувати параметр PermitRootLogin. Установка цього параметра в значение.

PermitRootLogin no.

не дозволить користувачеві root одержати доступ віддаленому терміналу. Одержання привілеїв користувача root у разі можна буде потрапити здійснити, лише запуском команди su.

Для настройки обмеження доступу є й параметри AllowGroups, DenyGroups і AllowUsers, DenyUsers до розв’язання й скасування заборони на доступ певним групам і користувачам відповідно. Наприклад, для заборони доступу усім етнічним групам користувачів крім користувачів групи wheel, конфігураційний файл мусить мати такі рядки DenyGroups * AllowGroups wheel.

Для посилення рівня безпеки можна змінити решта 2 параметра. Значення цих параметрів за умовчанням прийнятні більшість систем та його зміна у разі великий ролі не грає. Параметр MaxStartups дозволяє поставити якомога більше одночасно запущених процесів демона sshd, інакше кажучи, цей параметр визначає якомога більше одночасно підключених користувачів. По вмовчанням обмеження кількості користувачів одно 10. Якщо систему повинен мати доступ лише адміністратор і іще кілька чоловік персоналу, цей параметр можна виставити в значення 5. Параметр LoginGraceTime визначає період, протягом якого, починаючи з моменту встановлення сполуки, має бути здійснена аутентификация користувача. За умовчанням це значення одно 2 хвилинах. Якщо недоїмку протягом цього часу користувач не пройде аутентификацию, серверна сторона просто закриє з'єднання. Якщо адміністрування робиться з локальної мережі, для аутентифікації може бути досить 30 секунд, Якщо ж існує хоча б ймовірність, що доступ здійснюватиметься через низкоскоростное з'єднання, наприклад, у вигляді телефонного сполуки, можна буде виставити це значення в $ 60 секунд минимум.

Далі наводиться частина конфігураційного файла, сформована з урахуванням всього вищевказаного … Protocol 2 UsePrivilegeSeparation yes PermitRootLogin no MaxStartups 5 LoginGraceTime 30 …

Сервіс SSH відпочатку налаштований з максимальними вимогами до безпеки, тому зміна будь-яких додаткових настройок для стандартної конфігурації непотрібен. Зміни можуть знадобитися лише тому випадку, якщо роботі сервісу пред’являються особливі требования.