솔로 베이커 설정으로 보안

Question

솔로 베이커 설정으로 보안

- 8
- 254 2019-01-30
많은 사람들이 베이킹을위한tezos 설정을 언급하는 것을 보았습니다. 일반적인 아이디어는 지리적으로 분산 된 소수의 FE 노드를 실행 한 다음 FE 노드에만 연결되는 개인 노드를 갖는 것입니다. 그리고 가능하다면 개인 노드는 베이킹/서명 작업에 원장을 사용합니다.

이러한 시스템은 경제적으로 불가능합니다. 나는 또한 단지 홈 시스템을 설정할 수 없을만큼 충분히 순회하고 있습니다. 그래서 설정 보안에 대한 일반적인 생각을 묻고 싶었습니다.

VPS에서 단일 노드를 실행합니다. 개인 모드로 실행되며 피어는 TF 피어 일뿐입니다. 노드는 사설 네트워크를 통해 다른 VPS에서 실행중인 서명자와 통신합니다. 내가 선택한 서명자 포트를 제외하고 서명자의 방화벽이 완전히 차단되었으며 ssh는 사설 네트워크의 일부인 터널 머신을 통해서만 사용할 수 있습니다.

서명자의 방화벽은 IP I 화이트리스트에있는 노드 VPS에서 서명자 포트로의 연결 만 허용합니다. 이 때문에 서명자 인증을 설정할 필요가 없다고 생각했습니다.

서명자는 내 대리인 주소에 대한 서명을하고 대리인 주소에는 estimated-rights.py 스크립트

나머지tezzies는 원장에 저장된 계정 키와 함께 내 대리인에게 위임하는 다른 출처의 계정에 살고 있습니다.

몇 가지 질문 :

합리적으로 안전한 설정처럼 들리나요?

누락 된 구멍이나 무엇이 있습니까?

내가 구워낸 블록이 네트워크를 통해 빠르게 전파되고 성공적으로 주입 될 가능성을 높이기에 충분할 정도로 TF 노드에만 연결하고 있습니까?

보너스 포인트 : Ethereum과 비슷한 AWS 블록 체인 템플릿이 작동 중인지 아는 사람이 있습니까? 참조 : Ethereum 용 AWS 블록 체인 템플릿

(이 질문에는 경제적으로 실행 불가능한 정확한 설정에 대한 다이어그램 이 있습니다. 나는 단지 솔로 베이커 일뿐)
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
<인용구>
서명자의 방화벽은 IP I 화이트리스트에있는 노드 VPS에서 서명자 포트로의 연결 만 허용합니다.이 때문에 서명자 인증을 설정할 필요가 없다고 생각했습니다.

나는 이것을 뒤집을 것입니다.서명자에게 들어오는 모든 연결을 차단하고 대신 서명자가 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

<인용구>

서명자의 방화벽은 IP I 화이트리스트에있는 노드 VPS에서 서명자 포트로의 연결 만 허용합니다. 이 때문에 서명자 인증을 설정할 필요가 없다고 생각했습니다.

이것이 제가 가질 수있는 주요 보안 문제입니다. 일반적으로 설정은 상당히 안전하지만 주요 위험은 다음과 같습니다.

서명자는 인증이 없기 때문에 베이킹 시스템에 로그인 할 수있는 사람은 누구든지 본드/예금 잔액 이체를 포함하여 원격 서명자와 함께 메시지에 서명 할 수 있습니다.
많은 VPS 공급자가 VPS 공급자 또는 다른 고객이 메모리 콘텐츠를 볼 수 있도록 허용 할 수있는 부 채널 공격으로부터 제대로 보호하지 못하기 때문에 서명자의 개인 키도 VPS에서 실행될 위험이 있습니다. VM의 개인 키를 노출합니다.

저렴한 또 다른 보안 방법 :

집에서 실행할 수있는 작은 Linux 서버를 확보합니다. 2GB 이상의 메모리와 블록 체인을위한 충분한 디스크 공간 (현재 2019 년 1 월 현재 73GB)이 있으면 중고 PC 일 수 있습니다.
원장을 사용하여 개인 키를 저장합니다.
베이커가 가정 인터넷 연결을 사용하여 이미하고있는 것처럼 --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