Модуль I · Хмарні сервіси й документи · тема 9, один урок · 120 хвилин · останній урок модуля
Мета. Сьогодні ти не вивчаєш нову тему. Ти перевіряєш те, що вже зробив. За цей модуль у твоєму акаунті з’явилися сайт, форма, дашборд і бот. А ще чужі відповіді, скрипти й ключі.
Разом із ними могли непомітно з’явитися дірки. Зайві права на теці. Забутий токен у коді. Копія чужих персональних даних. Урок про те, як знайти їх самому — раніше за когось іншого.
~/www/security/report.json — машиночитний звіт аудиту
(password_entropy_bits, масив checks зі
status і fix, phishing_score) і
~/www/security/index.html — пам’ятка «5 правил» своїми словами:
не менше 800 символів тексту і не менше 5 пунктів <li>.drwxr-xr-x і перекладати його в число — і навпаки;.js у файл поза ~/www,
а той, що вже втік, — відкликати;Рядок drwxr-xr-x, слово «токен» і «стійкість пароля в бітах»
поки нічого не означають. Розберемо їх по черзі.
| Етап | Хв | Що робимо |
|---|---|---|
| Вхід у тему | 10 | Три шкільні кейси: що саме зламали |
| Права доступу | 20 | Анатомія drwxr-xr-x, ls -la, find |
| Секрети в коді | 15 | .env, токен у браузері, історія git |
| Паролі і 2FA | 20 | Калькулятор стійкості, словниковий перебір |
| Перерва | 10 | — |
| Фішинг | 15 | Тренажер «Пошта-пастка» на 6 листів |
| Сканер акаунта | 25 | Проходиш чек-лист у терміналі, збираєш report.json |
| Підсумок модуля | 5 | Що ти вмів у вересні і що вмієш зараз |
| Разом | 120 |
Сервер класу спільний. Твій сусід по парті — це ще й сусідній обліковий запис на тій самій машині.
У Linux у кожного файлу є власник, група і решта —
усі інші користувачі системи. Для кожної з трьох категорій окремо вказано три
дозволи: читати (r), писати (w), виконувати
(x). Для теки x означає «можна зайти всередину».
Саме це й показує перший стовпчик у виводі ls -la. Розберемо
його по літері.
r = 4, w = 2,
x = 1. Тому rwx — це 7, а r-x — це 5.755 на ~/www, а 700 на рештіСторінку з ~/www віддає браузеру не ти, а окрема програма
на сервері. Вона зветься nginx: приймає запит і надсилає у відповідь
потрібний файл. Працює вона від власного системного користувача, а не від
тебе. Тому для твоєї теки nginx — «решта».
Щоб зайти в теку й прочитати файл, «решті» потрібні r і
x на теку та r на файл. Звідси 755
для тек і 644 для файлів у публічній частині. Читати може
будь-хто, змінювати — тільки власник.
А в ~/notes і ~/.ssh нікому чужому заходити
не треба. Ні nginx, ні сусідові. Там 700.
У ~/data нашого кабінету стоїть 750. Читати має
ще й група: від її імені працює скрипт збору форми. «Решта» не читає нічого.
А на authorized_keys стоїть 600: хто допише туди
рядок, заходитиме на сервер як ти.
| Що | Права | Хто читає | Навіщо саме так |
|---|---|---|---|
~/www і теки в ньому | 755 | усі | nginx має зайти в теку, щоб віддати сторінку |
файли в ~/www | 644 | усі читають | читати — так, змінювати — тільки ти |
~/data | 750 | ти і група | відповіді однокласників не для інтернету |
~/upload | 750 | ти і група | приймальня FTP, не публічна вітрина |
~/notes | 700 | тільки ти | чернетки нікого не стосуються |
~/.ssh | 700 | тільки ти | список твоїх ключів нікого більше не стосується; це ще й вимога критерію |
~/.ssh/authorized_keys | 600 | тільки ти | хто допише туди свій ключ — зайде як ти |
~/bin/build_dash.py | 700 | тільки ти | запускати твій скрипт має право лише ти |
~/.ssh рівно 700 — ключ не
спрацює». Це неточно. Сервер із увімкненим StrictModes
відмовляє тоді, коли теку або authorized_keys може
записувати хтось, крім власника, — тобто на правах
775 чи 777. Права 755 він приймає
спокійно, і вхід за ключем працює.
700 ми ставимо з іншої причини: сусідові по серверу нема чого
читати список твоїх ключів. Це гігієна і вимога критерію
perm_ssh, а не технічна відмова.777 не ставлять ніколи
Сімка для «решти» — це rwx для будь-якого користувача сервера.
Він може не тільки прочитати твій файл, а й переписати його.
Підмінити index.html. Дописати рядок у твій скрипт, який ти
сам потім запустиш від свого імені. На питання «чому не працює»
777 відповіді не дає — воно лише ховає справжню причину.ls -ld показує саму теку, а не її вміст. Саме це й потрібно
для перевірки прав. Ключ -l дає довгий формат, -d —
«саму теку». Вивід вище демонстраційний: у твоєму буде твій логін і твої дати.
Але переглядати очима сотні файлів безглуздо. Питання «чи є в мене дірки»
ставлять інакше — find шукає саме порушення:
-perm -o=w — «серед прав є запис для решти»: усе, що
знайшлося, може переписати будь-хто на сервері. Порожній вивід — це добре;! -perm -o=r — навпаки, файли, які «решта» не читає.
Саме тому браузер віддає 403 замість сторінки;o=w означає «містить щонайменше ці біти»; без
дефіса, як у третій команді, find шукає точний збіг усіх дев’яти.Клацай прапорці. Сторінка одразу показує рядок ls, число
і вердикт: годиться таке для публічної теки чи це вже дірка.
Форма не зберігала відповіді, і ти зробив chmod -R 777 ~/www/form —
«щоб точно працювало». Форма запрацювала. Що ти зробив насправді?
ls -ld ~/data показує drwxr-xr-x. Файлів у теці
ти не чіпав, а /data/ у браузері й далі дає 403. Це нормально?
.js — це вже не секретКлюч, пароль, токен доступу до API — усе це «секрети». Головне правило: секрет не лежить у тому, що ти віддаєш людям.
Уяви рядок у твоєму ~/www/dash/app.js:
Цей файл лежить у публічній теці. Отже, будь-хто в інтернеті може просто його завантажити — і побачити ключ:
Не потрібні ні злам, ні хитрощі: браузер зобов’язаний завантажити твій JavaScript, інакше сторінка не запрацює. Той самий рядок видно у DevTools → Sources і в «переглянути код сторінки».
Перед виливанням на сайт JavaScript часто стискають: прибирають пробіли, переноси рядків і довгі імена змінних. Файл стає удвічі меншим і незручним для читання. Таке стиснення звуть мінімізацією. Ховати вона нічого не вміє: ключ лишається тим самим текстом, просто без пробілів навколо.
.html, .css або .js
у ~/www, — публічне. Секрет живе там, куди відвідувач не
дістає: у файлі поза ~/www, у змінній оточення, у конфігу
серверного скрипта..env — і чому саме 600.env — простий текстовий файл «ім’я=значення». Звідти
програма читає свої секрети під час запуску.
Він дає три речі одразу. Секрету немає в коді, тож код можна показувати
кому завгодно. Файл лежить поза ~/www, тож його не віддає
веб-сервер. Права на ньому 600 — читає й пише лише власник.
Скрипт build_dash.py читає ключ звідти. У самому скрипті
лишається тільки ім’я змінної. Тепер його можна показати на проєкторі,
залити в репозиторій команди й віддати на код-рев’ю: секрету в ньому немає.
У цій команді чотири ключі, і кожен закриває свою проблему.
-r — шукати не в одному файлі, а в усій теці разом
із підтеками. Без нього grep подивиться тільки те, що лежить
у ~/www верхнім шаром. А забутий токен зазвичай лежить не там,
а на кілька тек глибше.
-I — це велика латинська «і». Вона каже: не заглядай
у картинки, відео й архіви. Такі файли складаються не з літер, а з байтів,
і їх звуть двійковими. Слова token там не буде, а екран
вони засмітять сотнями рядків.
-n — писати біля кожного знайденого рядка його номер.
Це економить хвилини: ти відкриваєш файл одразу на потрібному рядку,
а не гортаєш його очима.
-E — дозволити в шаблоні пошуку значок |
зі значенням «або». Шаблон зі значками, які щось означають, звуть
регулярним виразом — англійською regexp. Наш шаблон
читається так: знайди api_key, або secret,
або token — усі п’ять форм за один прохід.
Git не зберігає «поточний стан теки». Він зберігає усі стани: кожен
коміт — це знімок, і всі знімки лишаються в репозиторії назавжди. Ти видалив
.env і зробив новий коміт — з’явився ще один знімок, у якому файлу
немає. Але попередній знімок, де він є, нікуди не подівся.
Один рядок — і ключ знову на екрані, через тиждень після «видалення».
А якщо коміт уже пішов у спільний репозиторій, копії є в кожного, хто зробив
git clone чи git fetch.
push копій стає більше, ніж ти можеш відстежити.
Допомагає одне: відкликати сам секрет..env
поза ~/www. Додай .env у .gitignore.
Історію чистити можна потім, за бажанням: головним був перший крок.Богдан сховав ключ у файл ~/www/dash/config.js. Посилання
на нього немає на жодній сторінці. «Його ніхто не знайде, адреси ж
ніде немає». Наскільки він у безпеці?
Ти випадково закомітив .env із робочим токеном і зробив
push у репозиторій команди. Через хвилину зробив
git rm .env, новий коміт і ще один push.
Що робити далі?
Стійкість пароля вимірюють не «складністю на вигляд», а числом варіантів, які довелося б перебрати.
Кожен символ множить кількість варіантів на розмір алфавіту. Якщо в паролі тільки малі літери, алфавіт — 26 символів. Якщо ще й великі, цифри й розділові знаки з клавіатури — 95. Пароль довжиною L з алфавіту N дає NL варіантів. Вагу цього числа зручно міряти в бітах:
Ось звідки береться головна порада. Заміна o на
0 і a на @ ентропії не додає.
Слово лишилося тим самим словниковим. А правило заміни знає кожна програма
перебору. Дописати ще два слова — це +26 біт. Різниця в мільйони разів.
Ніхто не перебирає паролі «підряд» від aaaaaa. Спершу
пробують списки вже витеклих паролів. Їх мільярди, і вони
у відкритому доступі.
Потім до кожного слова застосовують правила. Додати рік у кінці.
Зробити першу літеру великою. Замінити літери на схожі цифри. Приписати
! чи 123. І тільки якщо нічого не збіглося,
починається справжній повний перебір.
Тому P@ssw0rd! формально має 9 символів і 59 біт. А насправді
падає в перші секунди: він є в списках витоків просто в такому вигляді.
І Sasha2010 — це «ім’я + рік», найпопулярніше правило зі всіх.
Нічого не надсилається в мережу і нічого не зберігається. Це просто арифметика на цій сторінці — можеш від’єднати ноутбук від Wi-Fi і перевірити. І все ж вводь схему свого пароля, а не сам пароль: та сама довжина, ті самі види символів.
Довжина 0 · алфавіт 0 символів · 0 біт
Уяви ланцюжок. Ти зареєструвався на маленькому форумі про ігри, він через рік втратив базу користувачів. У базі — твоя пошта й твій пароль. Далі працює автомат: ту саму пару «пошта + пароль» підставляють у сотні популярних сервісів підряд. Це називається credential stuffing — не злам, а просто вхід із правильним паролем.
Ніхто не «зламував» твою пошту. Її відкрили ключем, який ти сам залишив на форумі. Тому правило звучить так: унікальний пароль на кожен сервіс. Насамперед на пошту: через неї відновлюють доступ до всього іншого.
Запам’ятати три десятки різних паролів неможливо. Цього ніхто й не вимагає. Для цього є менеджер паролів — програма, що тримає всі паролі в зашифрованому файлі.
Ти пам’ятаєш один майстер-пароль: довгий, із кількох слів. Решту менеджер вигадує сам і сам підставляє. Є й побічна користь. Пароль він підставляє тільки на правильному домені. На сайті-двійнику він не запропонує нічого — і це вже готова перевірка на фішинг.
Пароль — це «щось, що я знаю». Його можна підглянути, вгадати або дістати з витоку. Другий фактор — «щось, що в мене є»: телефон, на якому кожні 30 секунд з’являється новий шестизначний код. Щоб зайти, потрібні обидва.
Код рахує сам застосунок. Він знає спільний секрет, виданий при налаштуванні, і поточний час. Нічого не надсилається. Тому код працює навіть без інтернету, а зловмисник із твоїм паролем стоїть перед порожнім полем.
Сайт вимагає «мінімум 8 символів, велика літера, цифра і спецсимвол».
Марія вводить Marija1!, Олег — слива-вітер-камінь-сім,
але сайт його не приймає. Хто з них має стійкіший пароль і чому?
У тебе один добрий пароль на 22 символи, і він стоїть скрізь: пошта, ігровий акаунт, форум, сервер класу. Форум злили. Що станеться далі?
Фішинг не ламає програму. Він ламає людину — поспіхом, страхом і однією літерою в адресі.
Схема завжди та сама. Лист виглядає як від сервісу, яким ти користуєшся. Він вимагає терміново кудись увійти чи щось відкрити. Сторінка, на яку ти потрапляєш, — точна копія справжньої.
Ти вводиш пароль — і він одразу в чужих руках. Далі тебе перекидає на справжній сайт, щоб ти нічого не запідозрив.
Окремо варто знати приманку саме для школярів: «перевір, чи не зламали твій акаунт — увійди тут». Вона працює, бо звучить як турбота і як порада з уроку інформатики.
Насправді сервіс, який щось помітив, не проситиме тебе входити за посиланням із листа. Він просто заблокує вхід і скаже зайти на сайт самостійно.
| Ознака | Що конкретно перевірити |
|---|---|
| Адреса відправника | не ім’я, а те, що після @. Ім’я відправника вписує сам відправник — воно нічого не доводить |
| Домен-двійник | підмінена літера (shcool, paypa1, rn замість m), зайвий дефіс, інша зона: .top замість .ua |
| Терміновість | «протягом 2 годин», «інакше видалимо», «останнє попередження» — щоб ти не встиг подумати |
| Адреса посилання | наведи курсор: текст посилання і справжня адреса можуть не збігатися взагалі |
| Вкладення | подвійне розширення .pdf.exe, архів із паролем «щоб антивірус не заважав», прохання «увімкнути макроси» |
| Сама вимога | надіслати пароль, код із SMS, фото документа — цього не просить жодна нормальна служба підтримки |
Прочитай кожен лист і вирішуй: це безпечно чи це фішинг. Після відповіді підсвітяться ознаки, які варто було помітити.
Пройдено 0 з 6 · правильно 0
Це розминка перед серверним тренажером. У
report.json потрапляє результат серверного тренажера
на 10 листів — його чекер звіряє з логом, тому вписати собі 10/10 руками
не вийде.
Приходить лист: «Ми помітили вхід до твого акаунта з іншого міста.
Перевір, чи не зламали тебе — увійди тут». Домен у посиланні —
school-vps-check.top. Твої дії?
Тобі приходить SMS із кодом підтвердження входу, хоча ти нікуди не входив. За хвилину — повідомлення: «Це служба підтримки, продиктуйте код, щоб ми скасували чужий вхід». Що це означає і що робити?
Найчастіше персональні дані витікають не через злам, а через копію файлу, яку хтось поклав «щоб було зручно».
За модуль через твої руки пройшли чужі дані: відповіді однокласників на твою форму, тестові діалоги з ботом, дані для дашборда. Усе це — персональні дані інших людей, і відповідаєш за них ти.
Перше: чи не лишились у моїх файлах чужі відповіді? Класична
історія — копія responses.csv у ~/www/form/,
зроблена, щоб «швидше подивитися». З цієї секунди відповіді всього класу
лежать в інтернеті за прямим посиланням. Знайти їх може будь-хто, кому
це спаде на думку.
Друга команда шукає у публічній теці те, що схоже на телефон, пошту
або номер у форматі +380. Ключ -l друкує лише
імена файлів, а не самі рядки. Так чужі дані не з’являться ще й у тебе
на екрані під час перевірки.
Друге: чи справді ~/data/ не віддається по HTTP?
Права на теці — це захист від сусіда по серверу. Від інтернету захищає
конфігурація nginx. Перевіряють це не логікою, а запитом:
-o /dev/null викидає тіло відповіді, а
-w "%{http_code}" друкує лише код. 403 або
404 — добре. 200 — так бути не має: скажи
вчителю одразу, не чекаючи кінця уроку.
Третє: чи прибрав я тестові дані? Під час розробки ти сам заповнював свою форму, писав тестові репліки в бота, вставляв у приклади імена однокласників. Чернетки, дампи діалогів і «тимчасові» копії лишаються назавжди, якщо їх не прибрати свідомо.
~/www цілком, без винятків. Файл не стає
приватним від того, що на нього немає посилання: адресу можна вгадати, знайти
в логах, побачити в історії репозиторію. Приватні дані живуть у
~/data, і крапка.Наталя поклала responses.csv у ~/www/form/.
Файл вона перейменувала на x7f3-tmp.csv. Пояснює так:
«таку назву ніхто не вгадає, а мені зручно відкривати з телефона».
Що з цим не так?
У ~/www/bot/dialogs.json лежать тестові діалоги, де
однокласники писали боту свої імена й клас. Роботу здано, оцінку
виставлено. Що робити з файлом?
Десять перевірок. Кожну ти виконуєш у своєму терміналі й
чесно позначаєш результат — сторінка складає з цього
security/report.json і показує світлофор.
Сканер нічого не перевіряє за тебе. Доступу до твого акаунта він не має і мати не може. Він робить інше: тримає порядок перевірки й підказує точну команду. А наприкінці збирає твої відповіді у звіт, який читає чекер.
Обманювати сканер немає сенсу: check 16 запускає ті самі
перевірки на сервері вже без тебе.
Ентропію бере калькулятор на кроці 4 — щойно ти щось туди введеш, число підставиться сюди саме. Результат тренажера вписуєш руками, але чекер звіряє його з серверним логом.
Зелених 0 · жовтих 0 · червоних 0 · без відповіді 10
report.jsonОце й треба покласти у ~/www/security/report.json. Кнопка
копіює весь текст цілком.
nano ~/www/security/report.json,
вставити текст, зберегти. Якщо робиш файл на своєму комп’ютері, збережи його
у UTF-8 без BOM (VS Code, Notepad++). У Windows PowerShell 5.1 не роби
echo … > report.json: перенаправлення > запише
файл у UTF-16, і jq на сервері вилетить із незрозумілою помилкою.
Якщо все ж PowerShell — тільки Out-File -Encoding utf8, і навіть
тоді перевір результат командою head -c 3 report.json | xxd.Кроки 1—11 — у SSH-сесії на сервері (крок 5 — у себе на комп’ютері), кроки 12—13 — здача. Галочки зберігаються.
id_ed25519 — приватний,
лишається у тебе на комп’ютері; id_ed25519.pub — публічний, його
й кладуть на сервер. Якщо на сервері з’явився файл без .pub —
ключ скомпрометовано, треба генерувати нову пару.Чекер повторює твій аудит уже без тебе: сам дивиться права,
сам шукає секрети, сам звіряє phishing_score з логом
тренажера. Спроби не обмежені.
Демонстраційний режим: результат згенеровано для показу. На сервері
ця кнопка викликає POST /api/check, який запускає
check 16 від імені учня.
ls -la ~/.ssh просто зараз: 700 на теці,
600 на authorized_keys, приватного ключа немає;checks був червоним і якою
командою ти його виправив;report.json у браузері й показуєш, що
fix написаний твоїми словами, а не скопійований;Це те, що бачить учитель, коли виставляє оцінку.
| Складник | Вага | Результат |
|---|
755 на публічне,
700 на приватне, 777 — ніколи;777, щоб «точно працювало», і лишають так до кінця року;phishing_score руками, не пройшовши тренажер —
звірка з логом ловить це одразу;fix у звіті загальними словами («виправити права»)
замість конкретної команди, яку виконали;.env із теки й вважають справу закритою, не
відкликавши токен.На початку року в тебе був логін і порожня тека. Ось що змінилося.
| Тема | Було на початку | Стало |
|---|---|---|
| Сервер і файли | файли лежали «десь на комп’ютері» | працюєш у Linux по SSH, розрізняєш публічне і приватне, читаєш і виставляєш права |
| 1 · LLM | «запитав у нейромережі» | будуєш керований промпт, бачиш галюцинації, зберігаєш історію як граф у JSON |
| 2 · Дані | таблиця як розлінований аркуш | проєктуєш поля й типи, збираєш дані власною формою, знаєш, чому валідації в HTML замало |
| 3 · Презентація | слайд-простирадло з текстом виступу | будуєш виступ за структурою, тримаєш контраст 4.5:1, малюєш живі діаграми з data.json |
| 4 · Комікс | «намалювала нейромережа» | ведеш канон героя, документуєш промпти, верстаєш панелі й чесно маркуєш AI |
| 5 · Звук і відео | монтаж кнопками, як вийде | пишеш музику кодом і збираєш відео скриптом build.sh, який відтворюваний |
| 6 · Дашборд | цифри переписували руками | будуєш ETL-конвеєр, ставиш його в cron і читаєш власні логи |
| 7 · Бот | «бот — це магія» | описуєш діалог автоматом і розумієш, що таке ін’єкція в промпт |
| 8 · Команда | файли пересилали в чаті | гілки, pull request, код-рев’ю і деплой, який робиться сам після push |
| 9 · Безпека | «мене це не стосується» | проводиш аудит власного акаунта, знаходиш свої ж дірки й закриваєш їх |
Останній рядок — головний. П’ятнадцять уроків ти щось створював. Сьогодні ти вперше подивився на створене очима того, хто шукає слабке місце.
Тепер ти прочитаєш права на своїй теці. Знайдеш токен у власному коді. Перевіриш, чи не лежать чужі телефони в публічних файлах. Це і є звичка, яку варто лишити собі: перевіряти свою роботу першим.
Пройди цей самий чек-лист для свого особистого акаунта — пошти або ігрового. Питання ті самі. Чи унікальний там пароль? Чи ввімкнена двофакторка? Чи не світиться десь твій номер телефону? Чи не приходили тобі листи, які тепер виглядають як фішинг?
За результатами допиши до пам’ятки шосте правило — своє власне, сформульоване з того, що ти знайшов у себе.
Усе на цій сторінці — з документації, стандартів і відкритих рекомендацій. Перевіряти дозволено й корисно.
chmod, вісімкові числа, біти rwx.
gnu.org/software/coreutils · File permissions,
man7.org/chmod.1find -perm, значення дефіса перед маскою.
man7.org/find.1~/.ssh і authorized_keys.
man.openbsd.org/sshd,
man.openbsd.org/ssh-keygenПовний список із поясненнями, що саме звідки взято, —
у файлі urok-16-джерела.md поруч із цією сторінкою.