- Новое
- Добавить закладку
- #1
Привет! Не сильно увлекался и вдавался в администрирование(так что, прошу не кидать помидоры сразу), но встал вопрос поднятие сервиса в сеть и упереся в безопастность и аннонимность.
Давайте для понимая покажу пример структуры(5 минут draw io)
все сервера на линуксе, подключения по ssh (отключены все порты, рут, добавлен ssh ключ только для 1 пк)
Меня волнует вопрос как именно и как правильно подключиться к серверам не оставляя за собой следы и немаловажно скрыть эти сервера друг от друга
чтобы воркер 1 не знал о сервере где s3 storage например или не знал где лежит база, можно конечно добавить цепочку еще одну, проложив между ними еще один сервер, но товарищ майор, получив доступ к серверу воркер 1, узнает где промежуточный, получив к нему доступ узнает и об бд или api.
Посоветуйте пожалуйста статьи, примеры, архитектуры может, мнение знающих и опытных. Интересно почитать и узнать новое.
В качестве примера я привел на схеме jump server, который может скрыть первичный ip, но тот же телеграм видит откуда ему летят запросы, можно начать копать отсюда и выйти на первый серв -> и на остальные, разве нет?
Благодарю заранее.
Хотел бы в тему своего вопроса добавить, как по мне очень интересную схему и метод, может кому пригодится. выданный товарищем(сообщение потерял, читал давно)
Давайте для понимая покажу пример структуры(5 минут draw io)
все сервера на линуксе, подключения по ssh (отключены все порты, рут, добавлен ssh ключ только для 1 пк)
Меня волнует вопрос как именно и как правильно подключиться к серверам не оставляя за собой следы и немаловажно скрыть эти сервера друг от друга
чтобы воркер 1 не знал о сервере где s3 storage например или не знал где лежит база, можно конечно добавить цепочку еще одну, проложив между ними еще один сервер, но товарищ майор, получив доступ к серверу воркер 1, узнает где промежуточный, получив к нему доступ узнает и об бд или api.
Посоветуйте пожалуйста статьи, примеры, архитектуры может, мнение знающих и опытных. Интересно почитать и узнать новое.
В качестве примера я привел на схеме jump server, который может скрыть первичный ip, но тот же телеграм видит откуда ему летят запросы, можно начать копать отсюда и выйти на первый серв -> и на остальные, разве нет?
Благодарю заранее.
Хотел бы в тему своего вопроса добавить, как по мне очень интересную схему и метод, может кому пригодится. выданный товарищем(сообщение потерял, читал давно)
Dread Pirate Roberts
![]()
заказываем две пятибаксовые вдски и дорогой сервер с кучей хардов под хранилище.
пусть у первого вдс будет условный IP 111.111.111.111, у второй 222.222.222.222, и у сервера 55.66.77.88.
первый вдс - это "фронтенд", он торчит голой жопой в сеть, на него направлена DNS A запись нашего домена, к нему мы подключаемся, чтобы попасть по SSH на хранилище, и так далее.
настраиваем на первом вдс VPN, он будет впн сервером (условный IP 10.1.1.1) для второй пятибаксовой вдски.
второй вдс - это "промежуточный сервер", он прячет реальный сервер от первой вдски.
настраиваем на втором вдс два VPN - этот вдс является клиентом в VPN сети между ним и первой вдской (условный IP VPN клиента 10.1.1.2), и является сервером в VPN сети между ним и реальным сервером (условный IP VPN сервера 10.2.2.1)
дальше настраиваем на "бэкенде" (реальном сервере) контейнер (LXC или VDS, пофиг), выдаём ему виртуальный IP адрес 192.168.0.2, и внутри контейнера подключаемся к VPN второго вдс.
дальше настраиваем фаервол и маршрутизацию:
- на первом вдс перенаправляем веб трафик на IP адрес контейнера 10.2.2.2. добавляем маршрут к 10.2.2.2 через VPN сеть второго вдс (10.1.1.2)
- на втором вдс врубаем маскарад - делаем вид, что запросы от первого вдс к контейнеру на самом деле идут от второго вдс, и что ответы от контейнера к первому вдс на самом деле идут от второго вдс.
- на бэкенде блокируем любой трафик от контейнера, кроме трафика к второму вдс 222.222.222.222.
- на контейнере настраиваем основной маршрут через VPN сеть второго вдс (потому что после предыдущего пункта ничего другое больше не доступно)
- ещё я забыл на картинке несколько iptables -A FORWARD ... для VPN, это оставлю в качестве домашнего задания любопытному читателю)
результаты всего этого:
- подключаясь браузером к IP 111.111.111.111 мы попадаем на сайт, запущенный на контейнере внутри реального сервера.
- подключившись к VPN сети первой VDS мы сможем зайти по SSH на контейнер по локальному IP адресу 10.2.2.2. также мы можем спокойно выдавать SSH аккаунты внутри контейнера, и пользователи никак не узнают реальный IP адрес реального сервера, любые запросы в Интернет от контейнера приобретают IP адрес 111.111.111.111.
если ещё пошаманить с фаерволом, то можно сделать так, чтобы контейнер даже о существовании 222.222.222.222 не знал, и видел только IP адреса из локальных сетей типа 10.* и 192.168.*.
- хостер первого вдс видит хождение трафика между 111.111.111.111 и 222.222.222.222, и понятия не имеет о существовании 55.66.77.88.
- хостер второго вдс видит хождение трафика между 222.222.222.222 и 55.66.77.88, и понятия не имеет о том, что это на самом деле к 55.66.77.88 подключаются из Большого
Интернета.
- если товарищ майор арестовывает вдс 111.111.111.111, то ничего на нём не находит, кроме логов подключения к 222.222.222.222. покупаем новую вдску за 5 баксов и делаем её VPN сервером 10.1.1.1. для профилактики желательно ещё и вдс 222.222.222.222 заменить, т.к. скорее всего за ней тоже придут.
Последнее редактирование: