безопасность с настройкой Solo Baker

Question

безопасность с настройкой Solo Baker

- 8
- 254 2019-01-30
Я видел,как многие люди упоминали о настройкахtezos для выпечки. Общая идея состоит в том,чтобы запустить несколько узлов FE,вероятно,географически разбросанных,а затем иметь частный узел,который подключается только к вашим узлам FE. И,если возможно,частный узел будет использовать Ledger для операций запекания/подписи.

Такая система была бы для меня экономически нецелесообразной. Я также достаточно странствующий,что не могу просто настроить домашнюю систему. Поэтому я хотел спросить об общих мыслях относительно безопасности моей установки.

Я использую один узел на VPS. Он работает в частном режиме,и его одноранговые узлы являются только узлами TF. Узел общается с подписывающим лицом,работающим на другом VPS,через частную сеть. Брандмауэр подписывающей стороны полностью заблокирован,за исключением выбранного мной подписывающего порта,а ssh доступен только через туннельный компьютер,который также является частью частной сети.

Брандмауэр подписывающей стороны разрешает подключения к порту подписывающей стороны только от узла VPS,IP-адрес которого я внес в белый список. Из-за этого я не чувствовал необходимости настраивать аутентификацию подписывающего лица.

Подписывающая сторона подписывает адрес моего делегата и адрес делегата содержит достаточноtezzies (и немного лишнего для передышки),чтобы внести залог для PRESERVED_CYCLES,как вывод Estimated-rights.py скрипт.

Остальныеtezzies живут в созданной учетной записи в другом месте,которая делегирует полномочия моему делегату,а ключи учетной записи хранятся в Ledger.

Несколько вопросов:

Звучит ли это как достаточно безопасная установка?

Есть какие-нибудь дыры или что-нибудь,что мне не хватает?

Достаточно ли подключения только к узлам TF,чтобы иметь высокую вероятность того,что блоки,которые я запекаю,будут быстро и успешно внедрены по сети?

Бонусные баллы: кто-нибудь знает,есть ли в разработке шаблон блокчейна AWS,аналогичный тому,который существует для Ethereum? См. Использование Шаблон AWS Blockchain для Ethereum

(В этом вопросе есть диаграмма точной настройки,которая для меня экономически невыполнима,учитывая что я просто пекарь-одиночка)
I've seen a lot of people mention tezos setups for baking. The general idea would be to run a handful of FE nodes, likely geographically dispersed, and then having a private node which connects to just your FE nodes. And if possible, the private node would use a Ledger for baking/signing operations.

Such a system would be economically infeasible for me. I'm also itinerant enough that I can't just setup a home system. So I wanted to ask about general thoughts regarding the security of my setup.

I run a single node in a VPS. It runs in private mode and its peers are only the TF peers. The node talks to a signer running in another VPS via a private network. The signer's firewall is completely blocked off except for the signer port I chose and ssh is only available via a tunnel machine that is also part of the private network.

The the signer's firewall only allows connections to the signer port from the node VPS who's IP I whitelisted. Because of this, I didn't feel it was necessary to setup signer authentication.

The signer signs for my delegate address and the delegate address contains just enough tezzies (and a little extra for breathing room) to put up the deposits for PRESERVED_CYCLES as output by the estimated-rights.py script.

The rest of the tezzies live in an originated account elsewhere that delegates to my delegate, with the account keys stored on a Ledger.

A few questions:

Does this sound like a reasonably secure setup?

Any holes or anything I'm missing?

Is connecting to just the TF nodes enough to give me a high probability that blocks I bake are propagated through the network quickly and successfully injected?

Bonus points: Does anyone know if there is an AWS blockchain template in the works, similar to how there is for Ethereum? See: Using the AWS Blockchain Template for Ethereum

(This question has a diagram of the exact setup that is economically infeasible for me given that I am just a solo baker)
ledger hsm setup solo-baking

2 ответ

голосов

- 3
- 2019-01-30
<цитата>
Брандмауэр подписывающей стороны разрешает подключения к порту подписывающей стороны только от узла VPS,IP-адрес которого я внес в белый список.Из-за этого я не чувствовал необходимости настраивать аутентификацию подписывающего лица.

Я бы перевернул это.Заблокируйте все входящие соединения с подписывающей стороной и вместо этого пусть подписывающая сторона подключится к TF.Таким образом,вам не нужно беспокоиться о том,что злонамеренный узел попытается подключиться к вашей подписывающей стороне посредством атак,таких как захват IP.

The the signer's firewall only allows connections to the signer port from the node VPS who's IP I whitelisted. Because of this, I didn't feel it was necessary to setup signer authentication.

I would flip this. Block all incoming connections to the signer and instead have the signer connect to the TF. That way you don't have to worry about a malicious node trying to connect to your signer through attacks such as IP hijacking.
- Я не уверен,что понимаю это.Подписывающая сторона должна принимать запросы на подпись.Сам подписывающая сторона ни к чему не подключается,она только отвечает на запросы подписи.
  
  I'm not sure I understand this. The signer needs to accept requests to sign. The signer itself doesn't connect to anything, it only responds to signing requests.
  - 3
  - 2019-01-31
  - lostdorje
- Это на уровне подключения.Подписывающая сторона должна оформить запрос.Это означает,что он потенциально может находиться за NAT,например,за домашним маршрутизатором,и вам не нужно открывать какой-либо порт,чтобы подписывающая сторона была доступна из внешнего мира. Это не влияет на то,как выдаются запросы на подпись.Это влияет только на то,кто инициирует TCP-соединение.
  
  This is on the connection level. The signer should issue the request. It means that it can potentially be behind a NAT, such as a home router, and you don't need to open any port to make the signer accessible from the outside world. This doesn't affect how signing requests are issued. It only affects who initiates the TCP connection.
  - 1
  - 2019-02-01
  - adrian

Luke Youngblood · Accepted Answer · 2019-01-30

6

2019-01-30

<цитата>

Брандмауэр подписывающей стороны разрешает подключения к порту подписывающей стороны только от узла VPS,IP-адрес которого я внес в белый список. Из-за этого я не чувствовал необходимости настраивать аутентификацию подписывающего лица.

Это основная проблема безопасности,которая у меня возникнет. В целом ваша установка достаточно безопасна,однако основные риски:

Поскольку у подписывающей стороны нет аутентификации,любой,кто может войти в вашу систему выпечки,может каким-либо образом подписывать сообщения с удаленной подписывающей стороной,включая перевод баланса вашей облигации/депозита.
Закрытый ключ подписывающей стороны также может быть подвержен риску использования на VPS,поскольку многие поставщики VPS не защищают должным образом от атак по побочным каналам,что может позволить провайдеру VPS или другому клиенту просматривать содержимое памяти. вашей виртуальной машины и предоставьте закрытый ключ.

Еще один безопасный метод,который может быть недорогим:

Приобретите небольшой сервер Linux,который можно запустить дома. Это может быть подержанный компьютер,если у вас есть 2 ГБ памяти или более и достаточно места на диске для блокчейна (в настоящее время 73 ГБ по состоянию на январь 2019 г.).
Используйте бухгалтерскую книгу для хранения личных ключей.
Пекарь должен подключиться в --private-mode к загрузочным узлам TF,как вы уже делаете,используя домашнее подключение к Интернету.

Благодаря!Ах,да,я должен настроить аутентификацию.И что касается закрытого ключа,после того,как я введу пароль для ключа,он будет жить в памяти в незашифрованном виде. Что касается небольшого сервера Linux,мой IP-адрес предоставляется через DHCP и часто меняется по какой-либо причине из-за моего интернет-провайдера.Это изменение IP не является проблемой для других узлов (узлов TF),связывающихся с моим узлом?

Thanks! Ah, ok yeah I should setup authentication. And right about the private key, after I enter the password for the key it will live in memory unencrypted. About the small Linux server, my IP is provided via DHCP and changes often for whatever reason due to my internet provider. This changing IP isn't a problem for other nodes (the TF nodes) contacting my node?
- 1
- 2019-01-30
- lostdorje
Если вы используете `--private-mode`,все ваши соединения будут исходящими (ваш узел будет блокировать любые неожиданные входящие соединения),поэтому наличие динамического IP-адреса не будет проблемой.

If you're using `--private-mode` your connections are all outbound anyway (your node will block any unexpected inbound connections) so having a dynamic IP address won't be a problem.
- 1
- 2019-01-30
- Luke Youngblood