Найкраща практика для доступу до сховищ пакетів


16

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

Це створює виклик, коли мені потрібно оновити пакети. Для репозиторіїв Yum я наразі відображаю всі необхідні репост з Інтернету та надаю дзеркала у внутрішню мережу. Я зберігаю копії кожного репо в кожному з наших п'яти середовищ: dev, QA, постановочний і два виробничих центри даних.

В даний час я не вирішую для конкретних мовних пакетів репозитів. Коли сервери потребують оновлення від rubygems, PyPI, PECL, CPAN або npm, вони повинні отримати тимчасовий вихідний доступ до Інтернету для отримання пакетів. Мене попросили почати дзеркальне відображення рубігем і PyPI, а решта, ймовірно, буде слідувати.

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

  • Це може бути прямий або зворотний проксі; кожен менеджер пакунків підтримує проксі-сервер або кінцеву точку користувальницького сховища, яка може бути або локальним дзеркалом, або зворотним проксі.
  • Він потребує детального контролю доступу, тому я можу обмежити, які IP-адреси клієнтів можуть підключатися до яких репо-доменів.
  • Клієнти повинні мати можливість слідкувати за переспрямуванням до невідомих доменів. Ваш початковий запит може бути обмежений rubygems.org, але якщо цей сервер поверне 302 випадковому CDN, ви зможете виконати його.
  • Він повинен підтримувати HTTPS-пакети. Мені не обов’язково потрібно видавати себе за інші SSL-сервери, але я повинен мати змогу повторно виставляти HTTPS-сайт через HTTP або припиняти та повторно шифрувати іншим сертифікатом.

Я спочатку дивився на зворотні проксі, і Варніс, здається, єдиний, хто дозволив би внутрішньо вирішити 302 переадресації в межах проксі. Однак безкоштовна версія Varnish не підтримує HTTPS-пакети. Зараз я оцінюю Squid як варіант прямого проксі.

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

Спасибі!

Відповіді:


5

Для цього використовуємо кальмарів; приємна річ у кальмарах полягає в тому, що ви можете досить швидко встановити термін дії об'єктів на основі відповідності шаблону, що дозволяє досить швидко очистити метадані з yum repo. Конфігурація, яка реалізує це:

refresh_pattern (Release|Packages(.gz)*)$      0       20%     2880
refresh_pattern (\.xml|xml\.gz)$      0       20%     2880
refresh_pattern ((sqlite.bz2)*)$      0       20%     2880
refresh_pattern (\.deb|\.udeb)$   1296000 100% 1296000
refresh_pattern (\.rpm|\.srpm)$   1296000 100% 1296000
refresh_pattern .        0    20%    4320

http://www.squid-cache.org/Doc/config/refresh_pattern/


5

Це остаточний випадок використання проксі . Звичайний проксі, а не зворотний проксі (ака. Балансири навантаження).

Найвідоміший та вільний та з відкритим кодом - кальмари . На щастя, це одне з небагатьох хороших програм з відкритим кодом, яке можна легко встановити за допомогою одного apt-get install squid3та налаштувати з одним файлом /etc/squid3/squid.conf.

Ми переглянемо добрі практики та уроки, про які вам відомо.

Офіційний файл конфігурації трохи змінено (5000 непотрібних коментованих рядків було видалено).

#       WELCOME TO SQUID 3.4.8
#       ----------------------------
#
#       This is the documentation for the Squid configuration file.
#       This documentation can also be found online at:
#               http://www.squid-cache.org/Doc/config/
#
#       You may wish to look at the Squid home page and wiki for the
#       FAQ and other documentation:
#               http://www.squid-cache.org/
#               http://wiki.squid-cache.org/SquidFaq
#               http://wiki.squid-cache.org/ConfigExamples
#

###########################################################
# ACL
###########################################################

acl SSL_ports port 443
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443         # https
acl Safe_ports port 1025-65535  # unregistered ports

acl CONNECT method CONNECT

#####################################################
# Recommended minimum Access Permission configuration
#####################################################
# Deny requests to certain unsafe ports
http_access deny !Safe_ports

# Deny CONNECT to other than secure SSL ports
http_access deny CONNECT !SSL_ports

# Only allow cachemgr access from localhost
http_access allow localhost manager
http_access deny manager

#####################################################
# ACL
#####################################################

# access is limited to our subnets
acl mycompany_net   src 10.0.0.0/8

# access is limited to whitelisted domains
# ".example.com" includes all subdomains of example.com
acl repo_domain dstdomain .keyserver.ubuntu.com
acl repo_domain dstdomain .debian.org
acl repo_domain dstdomain .python.org

# clients come from a known subnet AND go to a known domain
http_access allow repo_domain mycompany_net

# And finally deny all other access to this proxy
http_access deny all

#####################################################
# Other
#####################################################

# default proxy port is 3128
http_port 0.0.0.0:3128

# don't forward internal private IP addresses
forwarded_for off

# disable ALL caching
# bandwidth is cheap. debugging cache related bugs is expensive.
cache deny all

# logs
# Note: not sure if squid configures logrotate or not
access_log daemon:/var/log/squid3/access.log squid
access_log syslog:squid.INFO squid


# leave coredumps in the first cache dir
coredump_dir /var/spool/squid3

# force immediaty expiry of items in the cache.
# caching is disabled. This setting is set as an additional precaution.
refresh_pattern .               0       0%      0

Конфігурація клієнта - змінні середовища

Налаштуйте ці дві змінні середовища у всіх системах.

http_proxy=squid.internal.mycompany.com:3128
https_proxy=squid.internal.mycompany.com:3128

Більшість бібліотек клієнтів http (libcurl, httpclient, ...) самоконфігуруються за допомогою змінних оточення. Більшість додатків використовують одну із загальних бібліотек і, таким чином, підтримують наближення до коробки (без того, щоб розробник обов'язково знав, що вони роблять).

Зауважте, що синтаксис суворий:

  1. Ім'я змінної http_proxyОБОВ'ЯЗКОВО має бути малим регістром у більшості Linux
  2. Значення змінної НЕ МОЖЕ починатися з http(s)://(протокол супроводу НЕ http (s)).

Конфігурація клієнта - конкретна

Деякі програми ігнорують змінні середовища та / або запускаються як сервіс до того, як змінні можуть бути встановлені (наприклад, debian apt).

Ці програми потребують спеціальної конфігурації (наприклад /etc/apt.conf).

HTTPS-проксі - підключення

HTTPS-проксі повністю підтримується дизайном. Він використовує спеціальний метод "CONNECT", який встановлює певний тунель між браузером і проксі.

Не знаю багато про цю річ, але у мене ніколи не було проблем з цим протягом багатьох років. Це просто працює.

Особливий чохол HTTPS - прозорий проксі

Примітка про прозорий проксі. (тобто проксі прихований і він перехоплює клієнтські запити, на жаль, людина-посередині).

Прозорі проксі-сервери ламають HTTPS. Клієнт не знає, що є проксі і не має підстав використовувати спеціальний метод Connect.

Клієнт пробує пряме HTTPS-з'єднання ... яке перехоплюється. Виявляється перехоплення і помилки кидаються всюди. (HTTPS призначений для виявлення атак "людина-в-середині".

Білий список доменів та CDN

Білі списки доменів та субдоменів повністю підтримуються кальмарами. Тим не менш, час від часу він неочікувано провалюється.

Сучасні веб-сайти можуть мати всілякі переадресації домену та CDN. Це порушить ACL, коли люди не пройдуть зайву милю, щоб все акуратно розмістити в одному домені.

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

Кешування

Наданий файл конфігурації вимикає кешування всіх форм. Краще перестрахуватися, ніж потім шкодувати.

Особисто я зараз запускаю речі в хмарі, всі екземпляри мають принаймні 100 Мбіт / с, і провайдер запускає власні репости для популярних матеріалів (наприклад, Debian), які виявляються автоматично. Це робить пропускну здатність товаром, про який я не міг менше піклуватися.

Я вважаю за краще повністю відключити кешування, ніж зазнати жодної помилки кешування, яка розтопить мій мозок при усуненні неполадок. Кожна людина в Інтернеті НЕ МОЖЕ отримати правильні заголовки кешування.

Не у всіх середовищах однакові вимоги. Ви можете пройти додаткову милю і налаштувати кешування.

НІКОЛИ не вимагайте автентифікації на проксі

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

Якщо ви хочете зробити автентифікацію на проксі, не робіть цього.

Якщо керівництво хоче автентифікацію, поясніть, що це неможливо.

Якщо ви дев, і ви щойно приєдналися до компанії, яка блокує прямий Інтернет та змушує аутентифікацію проксі-сервера, РУНУЙТЕ ВЖЕ, КОЛИ ВИ МОЖЕТЕ.

Висновок

Ми пройшли загальну конфігурацію, загальні помилки та речі, про які потрібно знати.

Заняття:

  • Є гарне програмне забезпечення з відкритим кодом для проксі (кальмарів)
  • Це просто і легко налаштувати (один короткий файл)
  • Усі (необов'язково) заходи безпеки мають компроміси
  • Більшість вдосконалених варіантів розіб’ють речі та повернуться до переслідування
  • Прозорі проксі-сервери ламають HTTPS
  • Аутентифікація проксі - це зло

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

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


s / людина-в-середині / людина-в-середині / (S / E забороняє редагувати один символ)
Chen Levy

4

Це не вирішить усіх ваших завдань, але, можливо, це все-таки корисно. Незважаючи на назву, apt-cacher-ng не працює лише з Debian та похідними, а є

проксі-кешування. Спеціалізований для файлів пакетів від дистриб'юторів Linux, в першу чергу для дистрибутивів Debian (і на основі Debian), але не обмежуючись ними.

Я використовую це у виробництві в подібному (на основі Debian) середовищі, як ваше.

Однак, AFAIK, це не підтримує рубігем, PyPI, PECL, CPAN або npm і не забезпечує деталізовані ACL.

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


2

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

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

Ви можете домогтися того, що ви хочете використовувати ace на проксі-сервері, використовуючи рядки користувача-агента або поєднання ips / mask джерел та обмежуючи їх доступ до певних доменів, але якщо ви це зробите, я бачу, що це різні версії пакетів / бібліотек. Отже, якщо один з хостів може отримати доступ до cpan і запитувати модуль xxx :: yyy, якщо клієнт не вкаже використовувати конкретну версію, витягне останню з cpan (або pypy або rubygems), яка може бути, а може і не бути тією, яка вже була кешоване в проксі. Таким чином, ви можете отримати різні версії в одному середовищі. У вас не виникне такої проблеми, якщо ви використовуєте локальні сховища.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.