CodingFuture + Puppet. Частина VI: актуальні чорні списки і захищений стукіт

use cases
Коротко:
  1. Захист сервісів і відкриття портів по стукоту криптографічно стійким і не відтворюваним Single Packet Authorization (SPA) fwknop 2.6.9+.
  2. Динамічно настроюється оновлення чорних списків All Cybercrime IP Feeds by FireHOL.
  3. Повноцінна підтримка
    ipset
    cfnetwork.
  4. Підтримка власних чорних списків.
  5. Типові варіанти застосування.

Тематичний цикл:
Використання у виробничому середовищі в різних областях застосування пред'являє все більше специфічних вимог до налаштування мережного фільтра, що вимагає відповідного рішення.
Port-knocking або відкриття доступу через "простукування" портів
Призначення
Будь публічно доступний сервіс апріорі піддається злому або просто відмови в обслуговуванні з-за обмежених ресурсів на обробку сполук. Найбільш типові приклад — це SSHd, який досить просто піддається Dos у зі збоями в доступі для адміністратора. VPN не є панацеєю і сам встає під атаку.
найефективніший спосіб — це обмеження доступу на рівні мережі за вихідними адресами, але далеко не завжди це можливо: доступ в дорозі, динамічні адреси, тимчасові працівники і т. п.
Історія
За деякими відсилання тема стала більш висвітлена Martin Krzywinski в 2003 році. Спочатку в кінці 90-х для динамічного відкриття доступу був придуманий механізм посилки пакетів в певній послідовності в обмеженому інтервалі часу, прям як у гостросюжетних фільмах з секретним стуком у двері. На стороні сервера були різні варіанти реалізації обробки таких пакетів та відкриття доступу. Такий механізм має всі недоліки загального пароль, що передається у відкритому вигляді, і повинен бути підданий анафемі як telnet і rsh, хоча в деяких варіантах і підтримуються тимчасові паролі і якесь хешування.
Безліч варіантів реалізації перераховано на www.portknocking.org.
Згодом, все ж таки додумалися притягнути повноцінну криптографію з метою захисту від підслуховування, відтворення, підміни даних і підтримки окремих користувачів. Використовуючи секретні ключі для підпису повідомлення і синхронізацію часу з допустимим відхиленням, з'явилася можливість досить надійно посилати команди одним пакетом. Перші публічні відсилання "Single Packet Authorization" (далі SPA) йдуть до липневої сходці BlackHat в 2005 році.
fwknop — FireWall KNock OPerator
Перший реліз проекту був в 2004 році і він до цих пір підтримується. Стандартні пакети присутні в різних дистрибутивах. Початковий підхід був прослуховування трафіку через pcap, що дещо сумнівно. Далі було накручено безліч функцій, аж до віддаленого запуску команд, а-ля poor man's ssh.
Зрозуміло, навіть незважаючи на якісний аудит коду, всі прибамбаси викликають побоювання для використання, особливо з правами супер-користувача. Однак, підтримка безлічі користувачів і підтримка SPA є серйозними плюсами.
Тільки в 2014 році в v2.6.4 був доданий режим "UDP сервера" без необхідності в pcap, а в кінці 2015-го до v2.6.8 додали підтримку запуску абстрактних команд відкриття та закриття доступу замість прямого шматування мережевого фільтра. Саме ці дві фічі дозволили зняти деякі побоювання для застосування.
Інтеграція fwknop з модулем cffirehol
Сервіс
fwknop
настроюється і запускається з обмеженими привілеями та ресурсами для більшої безпеки. При вдалій аутентифікації допускається лише додавати необхідну адресу в заздалегідь підготовлені списки (
ipset
розглянуто далі), а по закінченню часу видаляти з них.
1. Генеруємо секретні ключі клієнта:
$ server="my_new_host"; \
fwknop --key-gen --key-gen-файл ~/.ssh/fwknop_id_${server}; \
cat ~/.ssh/fwknop_id_${server}
[+] Wrote Rijndael and HMAC keys to: .../.ssh/fwknop_id_my_new_host
KEY_BASE64: WB8/Hh9imafehfoJC/+XF5a2gOuK3zVvGnPVG6ELtLc=
HMAC_KEY_BASE64: AuWdYzJ5MSgrM3gbELS9YyhUYLUW5jqlirson2mhkn0zl/5AdSSTbJnrgb5Rqhe1cs4nYFJIeBJzKG5faqbamg==

2. Додаємо користувачів
# включаємо підтримку fwknop
cffirehol::fwknop::enable: true
# порт за замовчуванням, слід поміняти
cffirehol::fwknop::port: 62201
# додаємо користувачів
cffirehol::knockers:
portable:
timeout: 3600
key_b64: 'WB8/Hh9imafehfoJC/+XF5a2gOuK3zVvGnPVG6ELtLc='
hmac_key_b64: 'AuWdYzJ5MSgrM3gbELS9YyhUYLUW5jqlirson2mhkn0zl/5AdSSTbJnrgb5Rqhe1cs4nYFJIeBJzKG5faqbamg=='
home:
timeout: 43200
ipset:
- cfauth_admin
- other_purpose
key_b64: '<OTHER KEY>'
hmac_key_b64: '<OTHET_HMAC_KEY>'

3. Развертываем puppet на сервері
$ sudo /opt/puppetlabs/bin/puppet agent --test

4. Створюємо файл конфігурації
fwknop
клієнта.
Потрібно
fwknop-client
2.6.4+ з підтримкою "UDP сервера", який доступний в Debian 9+ і Ubuntu 17+, а для всіх інших .deb систем повинні підійти складання з LaunchPad — саме вони використовуються в модулі.
[default]
WGET_CMD /usr/bin/wget
SPA_SERVER_PROTO udp
USE_HMAC Y
HMAC_DIGEST_TYPE sha256
RESOLVE_IP_HTTPS Y
# just a placeholder for SPA format
ACCESS tcp/1

[my_new_host]
SPA_SERVER 128.1.2.3
SPA_SERVER_PORT 62201
SPOOF_USER portable
KEY_BASE64 WB8/Hh9imafehfoJC/+XF5a2gOuK3zVvGnPVG6ELtLc=
HMAC_KEY_BASE64 AuWdYzJ5MSgrM3gbELS9YyhUYLUW5jqlirson2mhkn0zl/5AdSSTbJnrgb5Rqhe1cs4nYFJIeBJzKG5faqbamg==

Увага: у форматі файлу немає двокрапки, як у файлі з першого пункту.
5. Тестуємо відкриття доступ
fwknop -n my_new_host

Примітка
  • Зазвичай, тека
    .ssh
    в домашньому каталозі одне з найбільш захищених місць. Тому використовується для прикладу.
  • Не слід робити глобальних налаштувань
    cffirehol::knockers
    для уникнення витоку інформації на всі системи в каталогах Puppet.
  • Для кожного вузла у користувача повинні бути окремі ключі з банальних міркувань управління симетричними ключами.
  • Відразу використовується два ключі для підпису повідомлення і для шифрування, хоча це може здаватися дещо зайвим.
  • В залежності від типу пристрою і умов використання слід вибирати підходящий часовий інтервал для відкриття доступу.
  • мається на Увазі використання спільно з модулем cfauth — тому за замовчуванням використовується список
    cfauth_admin
    , але допустимо використовувати і інші.
  • Сервер вимагає зазначення явного IP, не покладаючись на заголовок UDP пакети.
Чорні списки
Навряд чи потрібно пояснювати сенс терміну, але не варто забувати, що завжди є можливість переграти себе самого і обов'язково слід мати більш пріоритетний білий список.
По-друге, не варто прописувати адреси у вигляді окремих правил мережевого фільтра. Це неефективно. Для вирішення даної проблеми в Linux існує підтримка IP sets в рамках проекту netfilter (він же iptables).
Глобальні списки небажаних адрес
На просторах інтернету існує безліч платних і відкритих постійно оновлюються списків адрес різної якості. Одним з чудових об'єднують проектів є All Cybercrime IP Feeds by FireHOL.
Зазначимо, що буде легковажно накидати всі можливі списки. Деякі можуть бути вкрай сумнівної якості або дуже суб'єктивні: наприклад, адреси інтернет-тролів.
Власні чорні списки
Подібні списки складаються як вручну, так і автоматично за результатами робіт систем виявлення вторгнень (IDS). Добре відомий приклад fail2ban. В "ручному режимі" списки адрес можуть братися з баз даних із заблокованими користувачами і т. п.
Підтримка списків IP-адрес в модулі cfnetwork
Був доданий новий тип
cfnetwork::ipset
і концепція часткової конфігурації, коли на етапі розгортання безліч списків з єдиним префіксом об'єднуються в один. Приклад:
  • vpn_access
    — основне визначення списку і його параметрів. Ця назва використовується для посилання.
  • vpn_access:hardcoded
    ,
    vpn_access:static
    або будь-яке інше назву може задаватися в конфігурації або інших модулях.
  • vpn_access-net4
    vpn_access-net6
    — таке буде реальне ім'я списку створене для сімейства IPv4 і IPv6 відповідно
Списки можуть бути динамічними — конфігурація мережевого фільтра передбачає, що вони будуть змінюватися в режимі реального часу. Правила мережевого фільтра з динамічними списками, що додаються на всі можливі інтерфейси. Інакше, більш інтелектуально — тільки на інтерфейси, де мають сенс, виходячи із змісту.
У всі конфігурації портів, де можливо вказати IP-адресу або ім'я хоста, можливо послатися і на визначений список з префіксом "ipset:".
Списки можуть включати в себе інші списки, але це має сенс тільки для наперед заданих адрес. Приклад:
cfnetwork::ipsets:
locations:
addr:
- '128.1.2.3'
- 'somehost.example.com'
- "2001:db8::/32"
puppet_access:
addr: 'ipset:locations'
vpn_access:
addr:
- 'ipset:locations'
- 'ipset:cfauth_admin'
'whitelist:static':
addr:
- 'trusted.example.com'
cfnetwork::service_ports:
'main:puppet':
src: 'ipset:puppet_access'

Примітка: список
cfauth_admin
автоматично додається в
whitelist
.
Підтримка актуальних чорних списків в модулі cffirehol
Проект чорних списків від FireHOL має власний інструмент update-ipsets, який дозволяє оновлювати списки з перевіркою віку, маніпулювати ними і оновлювати їх у ядрі. Незважаючи на це, робота з такими комплексними операціями під супер-користувачем здалася небезпечною. Тому вся підготовка списків проходить під непривілейованим користувачем, а збереження і оновлення в ядрі вже робиться власними коштами.
Для оптимізації зберігання та обробки, можуть допускатися деякі помилкові спрацьовування. Наприклад, замість розрізнених IP-адрес може відбуватися укрупнення в одну запис з префіксом з налаштованим коефіцієнтом, а не мають сенсу запису, вкриті більш загальними, просто віддаляються інструментом iprange.
Параметри
cffirehol::dynblacklist::blacklists4
та
cffirehol::dynblacklist::blacklists6
— дозволяють вибрати іменовані списки. За замовчуванням використовується рекомендований список
firehol-level1
з найменшою кількістю помилкових спрацьовувань.
Параметр
cffirehol::dynblacklist::addon_ipsets
— дозволяє додати конфігурацію власних списків для
update-ipsets
.
На крайній випадок, існує параметри
cffirehol::dynblacklist::custom_*
для більш гнучкого отримання власних чорних списків.
Мінімально для включення актуальних чорних списків достатньо:
cffirehol::dynblacklist::enable: true

Що маємо в підсумку
По-перше, для цілей зручного адміністрування розширено функціонал cfnetwork, що дозволяє без зайвих проблем поєднувати роботу з IPv4 і IPv6 адресами. А так само, підтримуються успадковані списки, концепція яких відсутня в інструментах більш низького рівня. Це дозволяє логічно ділити адреси на групи без зайвого дублювання.
По-друге, запроваджено додатковий легкий рівень захисту сервісів. В першу чергу, він дозволяє закривати такі "важкі" сервіси як SSH і VPN від небажаних сполук. Такий підхід знаходить своє застосування і для доступу в середовище розробки з боку позаштатних співробітників з персональним ключем для кожного.
по-третє, тепер підтримуються динамічні постійно оновлювані чорні списки як з глобальних централізованих ресурсів, так і з власних джерел.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.