임호화된 UnRAID 서버 자동으로 시작

!
경고: 이 글이 작성된 지 365일이 넘었습니다. 글의 정보가 오래되어 부정확할 수 있습니다.

암호화된 UnRAID 서버를 재부팅 후 자동으로 시작하는 방법을 찾는다면, 거의 대부분 이 쓰레드에 있는 절차 (경고: 영어)를 사용할 겁니다. 하지만 별다른 SMB 공유 폴더를 만들기 싫다면요? 비밀번호 파일을 계속 공유하는 서버를 운영하고 싶지 않다면 어떻게 할까요?

그렇다면 사용하실 수 있는 다른 방법이 하나 있습니다.

절차

  1. UnRAID 서버가 있는 네트워크에 다른 컴퓨터에 다음 파이썬 스크립트를 만들고 실행시킵니다:

main.py:

#!/usr/bin/env python3
from os.path import exists
import http.server

# 여기에 설정값 수정
PORT = 9999
PASSWORD_FILE_NAME = "password.txt" # 현재 경로 안에
TIMEOUT = 300   # 초 단위

# 비밀번호를 불러오거나 물어보기
if exists(PASSWORD_FILE_NAME):
    print(f"비밀번호 파일 {PASSWORD_FILE_NAME} (이)가 존재합니다. 안의 비밀번호를 사용합니다.")
    with open(PASSWORD_FILE_NAME) as password_file:
        PASSWORD_TO_SEND = password_file.readline().strip()
else:
    from getpass import getpass
    print("비밀번호 파일이 없습니다. 비밀번호를 입력하세요.")
    PASSWORD_TO_SEND = getpass()

# 웹 서버 시작
class RequestHandler(http.server.BaseHTTPRequestHandler):
    def do_GET(s):
        s.send_response(200)
        s.send_header("Content-Type", "text/plain")
        s.end_headers()
        s.wfile.write(str.encode(PASSWORD_TO_SEND))

httpd = http.server.HTTPServer(('', PORT), RequestHandler)
httpd.timeout = TIMEOUT
httpd.handle_request()

참고:

  • 스크립트와 같은 경로에 password.txt 파일을 만들고 안에 암호화 비밀번호를 저장하세요.
  • 타임아웃 값을 UnRAID 서버가 재부팅하는 시간보다 길게 설정하세요.
  • 다른 컴퓨터에 텍스트 파일로 비밀번호를 저장하지 않고 비밀번호를 수동으로 입력하고 싶으시다면, password.txt을 삭제하시면 됩니다. 스크립트가 실행될 때 비밀번호를 물어봅니다.
  1. UnRAID 플래시를 수정해서 다른 컴퓨터에서 키를 가져오도록 합니다.

(UnRAID 포럼에서의 기존 스크립트를 제공하신 @bonienl께 감사의 말씀 드립니다. 아래의 스크립트는 이 절차와 호환되도록 일부 수정된 버전입니다.)

만약 다른 컴퓨터에 USB 스틱을 연결하였을 경우, 파일 경로에서 /boot/를 빼셔도 좋습니다.

/boot/config/go를 편집하고 다음 줄들을 추가/수정합니다:

# ...생략...

# emhttp 이벤트 경로에 스크립트 복사
install -D /boot/custom/keyscript/fetch_key /usr/local/emhttp/webGui/event/starting/fetch_key
install -D /boot/custom/keyscript/delete_key /usr/local/emhttp/webGui/event/started/delete_key

# 실행 권한 부여
chmod a+x /usr/local/emhttpd/webGui/event/starting/fetch_key
chmod a+x /usr/local/emhttpd/webGui/event/started/delete_key

# webGUI 시작
/usr/local/sbin/emhttp &

/boot/custom/keyscript/fetch_key를 만듭니다:

#!/bin/bash

if [[ ! -e /root/keyfile ]]; then
  curl other-computer:9999 > /root/keyfile # 포트를 변경하셨을 경우 여기에서 수정해주세요!
fi

/boot/custom/keyscript/delete_key를 만듭니다:

#!/bin/bash

rm -f /root/keyfile
  1. 이제 UnRAID 머신을 재부팅시켜야 될 때, 다른 컴퓨터로 접속해서, 파이썬 스크립트를 실행시킨 다음, 재부팅을 진행하세요. 재부팅이 완료된 UnRAID 서버가 다른 컴퓨터에서 암호화 키를 가져와서 자동으로 디스크를 잠금 해제하고 마운트시킵니다.

위의 절차를 간단하게 하는 스크립트도 아래 적어두었습니다:

#!/bin/bash

# 암호화 비밀번호 서버 스크립트 시작
python3 main.py &

# 서버에 SSH로 접속 후 재부팅 시작
# 호스트 이름을 변경하는 것을 잊지 마세요
ssh root@unraid-server-hostname reboot

문제 해결

Bonjour 문제

만약 UnRAID 서버나 다른 컴퓨터가 호스트를 찾을 수 없다는 오류를 발생시킨다면, 네트워크가 호스트 이름을 기반으로 서로를 찾는 것을 지원하지 않을 수 있습니다. 이 문제를 해결하려면, 두 머신 모두 고정 IP를 설정한 다음, 스크립트에서 호스트 이름을 고정 IP로 대체하세요.

장점

다른 방식과 비교해서 이 방식은 몇 가지 장점을 가지고 있습니다:

  • 비밀번호를 계속 노출시키는 서버와는 다르게, 로컬 네트워크에 잠시동안 비밀번호가 노출됩니다. 타임아웃 설정값을 넘을 경우, 간단한 HTTP 서버를 돌리는 스크립트는 자동으로 종료됩니다.
  • 만약 누군가가 UnRAID 서버에 몰래 접근하여 플래시 드라이브의 내용을 확인할 경우, 그들은 서버가 시작하기 위에 다른 컴퓨터에서 비밀번호를 가져온다는 것을 확인할 수 있지만, 비밀번호를 확인할 수는 없습니다 (단, 서버가 돌아가고 있을 경우에는 그냥 메모리를 확인하면 되기에 여기에서는 고려하지 않겠습니다).
  • 만약 누군가가 다른 컴퓨터에 몰래 접근할 경우, 그들은 UnRAID 서버에 비밀번호를 제공하는 스크립트가 있다는 것을 확인할 수 있지만, 비밀번호를 텍스트 파일로 저장하지 않았다면 확인할 수 없습니다. 그리고 만약 텍스트 파일로 저장되어 있다면, 다른 컴퓨터를 원격으로 잠그기만 하더라도 비밀번호를 확인할 수 없게 됩니다.

단점

물론, 이 방식은 몇 가지 단점과 제약사항도 가지고 있습니다:

  • 이 방식에서는 다른 컴퓨터와 UnRAID 서버 사이의 통신이 암호화되어 있지 않습니다. 일반적으로 신뢰하는 기기들만이 있는 홈 네트워크에서는 문제가 되지 않지만, 만약 네트워크 상에 도청이 이루어질 경우 비밀번호를 가로챌 수 있습니다. 이 방식을 적용하기 전, 네트워크 보안을 검토하는 것을 고려하세요.
  • 이 방식은 UnRAID 머신과 같은 네트워크에 다른 컴퓨터가 있는 것을 필요로 합니다. 만약 UnRAID 서버가 예시로 DHCP 서버를 돌리고 있다면, 이 방식은 작동하지 않을 것입니다. 디스크가 마운트되고 서비스가 시작될 때까지는 UnRAID 서버가 다른 컴퓨터에 연락할 수 없기 때문입니다. 이 문제를 해결하려면 UnRAID 서버가 꺼져도 네트워크 쪽에 관여하지 않는 것을 확인하세요.
  • 비밀번호 파일은 다른 컴퓨터에 보호되지 않은 상태로 저장됩니다. 이 보안 리스크를 해소하려면 비밀번호를 텍스트 파일로 저장하는 대신, 스크립트를 돌릴 때마다 입력하실 수 있습니다.

결론

이 블로그 글을 작성하는 동안, 만약 UnRAID 서버와 같은 네트워크에 다른 컴퓨터가 있다면, 그냥 WebUI에 접속하여 비밀번호를 입력하면 되는 거 아니야? 라는 생각을 했습니다. 그럼 위의 방식은 별로 의미가 없는 거 아닌가요?

하지만 이 방식은 다른 컴퓨터에 GUI 접근 (예를 들어, VNC/RDP 접근이 없는 헤드리스 (headless) 머신)에서도 작동합니다. 재부팅하기 전 이 스크립트를 돌리면 되기 때문입니다.

보안상으로는 이 방식이 조금 취약할 수 있기에, 네트워크 보안과 개인의 위협 모델을 꼼꼼히 검토한 후 적용하시는 것을 추천합니다.

비슷한 게시물

댓글