В конце концов, создать им рядом базу / схему с доступом для их юзеров и на продовые данные сильно зарезать доступ. Но лучше сразу реплику с пофильтрованными данными.
Vadimayer, ну почему приложение завершилось, да ещё и с кодом 0...
А, кстати, оно ж небось с консолью работает, раз это какой-то "shell"? В контейнере с этим могут быть сложности. Нужно уговорить docker на ключи -i -t в docker-compose, мне никогда не требовалось, но вот подсказывают https://stackoverflow.com/a/39150040
mayton2019, уязвимости скорее всего ни при чём. Просто протокол надо поддерживать постоянно, тестировать в новых релизах итд итп. При том, что сам протокол очень кривой со своими отдельными DTP-коннектами и трудностями с active/passive, каждый из которых ещё и может упереться в firewall, что как бы дополнительно всё осложняет. Ну отдельно отмечу, что в rfc959 неспецифицирован формат ответа на LIST, и в разных серверах он может быть реализован по-разному (по факту есть два варианта: ftp в винде и ftp у всех остальных).
Теоретически, можно взять MIDI-контроллер с крутилками (тем более они бывают не только "как пианино", но даже и без клавиш совсем) и попробовать написать приложение, которое будет управлять громкостью в PulseAudio через приём команд MIDI. Есть ли готовое удобное решение я не искал.
Если использовать jack, то кажется даже простейшее решение нашлось у меня прямо в системе. Такой командой:
jack_mix_box -s 73
я сделал фильтр, который повесил на fader CC=73 мидиклавы а сам его вставил в разрез вывода программного синтезатора. И таки работает!
velosipedist, wireshark и tcpdump используют один и тот же системный интфейс к пакетам.
Про мак я поспешил, в бридже же будет виден мак исходного устройства, а спуфить на другом устрйостве даже хуже будет. Хотя если провайдер мак не смотрит, то ну и ладно. Но в любом случае, он в теории может спалить наличие на порту других маков, даже если они не будут светиться по IP. В некоторых случаях провайдеры следят, чтобы на порту больше одного мака не было.
velosipedist, да, кстати, если провайдер проверяет мак-адрес клиента на порту, то ещё надо будет показывать на интерфейсе в сторону провайдера такой же мак...
velosipedist, собираем тестовый стенд и пробуем tcpdump. Ну в целом я и так скажу, что слушать bridge, хотя на обоих интерфейсах будет ловиться всё то же самое...
montarano, например, настоящие пацаны читают документацию по Flask на тему того, как его завести в WSGI. Даже ключевые слова, по которым искать, вполне себе очевидны...
Лично не видел, но во время "провайдерских войн" внутри общаги одного вуза 20 дет назд аффилированный с одним из "провайдеров" товарищ вставил свой "сервер" в разрез магистрали другого провайдера и рандомно дроппал чуть-чуть пакетов... Был жостко наказан неблагодарными студентами, когда это вскрылось :)
Конечно можно, делаешь bridge между интерфейсами и ловишь всё что надо. Главное чтобы производительности хватило на весь трафик, шоб не спалиться на том, что гигабитный тариф не выдерживается...
Лучше не все порты, а только нужные. Как минимум, имеет смысл оставить порт для ssh, чтобы на внешний сервак можно было бы зайти в случае чего. И порт для VPN-сервера, конечно же, не надо пробрасывать.
А дальше поднять VPN по любой технологии и сделать nat, например:
Для трафика со стороны домашнего сервера сделать nat на выход:
iptables -t nat -A POSTROUTING -s <IP-домашнего-в-VPN> -j MASQURADE
Не забыть включить маршрутизацию (net.ipv4.ip_forward=1 в sysctl, файл /etc/sysctl.conf).
Со стороны домашнего сервера надо будет сделать policy routing (source routing), если надо только отвечать на запросы снаружи. Либо (что намного проще) сделать default route внутрь VPN, а также сделать отдельно роут до внешнего сервера мимо VPN, чтобы он не пытался трафик до VPN заворачивать внутрь VPN. В последнем случае исходящий трафик тоже будет ходить через внешний сервер поверх VPN.
Это общие сведения, дальше учиться, тренироваться, набивать шишки, изменять ТЗ по ситуации...
К блокировкам это не имеет отношения. Транзитный провайдер может блокировать всё равно.
А вот что с таким имуществом придётся получить дорогую лицензию оператора, поставить СОРМ или как-то убедить регулятора что никому не оказываешь услуг...
Да и LIR не может просто так выдать сетку, по крайней мере IPv4. Нужны обоснования, что сетка прям нужна.
В любом случае, содержание файловой системы будет в состоянии как если бы системе рубануть питание. Так что подобным образом нормальные бэкапы не очень хорошо делать.
Если внутри виртуалки используется система с возможностью снапшотов (zfs, btrfs), то можно внутри сделать снапшот и его сбэкапить.
Но правильнее выбирать инструмент под конкретные условия, сразу же думая о том, как этот бэкап использовать. Просто делать бэкапы бинарных данных не имеет смысла. Например, у меня был случай, когда наличие бинарного бэкапа mysql не помогло. Потому что данные в ibdata очень капризны, чуть что не сойдётся - и всё, приехали... Даже медитация со строго такой же версией mysql и таким же конфигом не спасает. Для баз данных есть свои специальные средства для бэкапа. А чтобы исключить влияние - делается репликация базы и бэкап снимается с реплики. Опять же, если бэкап делается с целью восстановить состояние базы на любой момент, то надо иметь регулярные бэкапы плюс бинлоги в качестве инкрементов. Мне приходилось такое восстанавливать для убитой базы, которой неприемлемо было откатиться на сутки.
Для файлов имеет смысл делать файловые бэкапы, код лучше держать в git, ну а вместо (и/или помимо!) бэкапа всей системы надо наладиться над автоматизацией разворачивания (automated install, ansible итд). Чтобы если с сервером что-то случилось - можно было бы быстро поднять такой же, а не страдать полночи.
В конце концов, создать им рядом базу / схему с доступом для их юзеров и на продовые данные сильно зарезать доступ. Но лучше сразу реплику с пофильтрованными данными.