가볍게 생각나는 것들을 적는 것이 주 목적이지만 이 서버를 만지면서 내가 자꾸 헤매게 되어서 정리를 해보려고 한다.

1. 목적 설정

목적에 따라 구성이 달라질 수 밖에 없다. 그래서 내가 홈서버를 구축하기로 한 사고의 흐름(생각들)을 정리해본다.

취미와 가벼운 실사용

홈서버를 구축하고 운영하는 것은 리눅스 시스템을 만지는 것을 좋아하는 나에게는 괜찮은 취미 거리 중 하나 이다. 혼자 사용할 서비스지만 그룹웨어와 프로젝트매니지먼트 도구에 관심이 많은 나에게는 만지작거릴 재밌는 오픈소스 프로젝트들이 있다. 이런 오픈소스 프로젝트의 결과물을 서비스하고 이용하는 것도 재밌는 취미다.

서비스 목록

• Nextcloud
  자세한 역사는 모른다. 다만 Owncloud에서 포크된 프로젝트로 오픈소스+무료로 제공되는 범위가 훨씬 넓고 애초에 구현된 기능의 범위 자체가 더 넓다. 아마 오픈소스 정책과 기능 구현 범위에 관한 의견이 불일치 해서 프로젝트가 분리된 것 같다.
• Openproject
  프로젝트 관리 중 이슈 추적과 일정 계획 및 관리, 시간 및 비용 추적 기능이 편리하게 구현되었고 PM2 관리 방법론에 필요한 거의 모든 기능을 제공한다. Redmain에 플러그인을 추가하면 거의 동일하거나 더 나은 기능을 제공하지만 무료로 사용 가능한 Redmain과 무료 플러그인 만으로는 시각적으로 만족스러운 디자인을 볼 수 없다. 오픈프로젝트는 제법 예쁜 인터페이스를 제공한다.
• WordPress
  CMS(컨텐츠 매니지먼트 시스템)이다. 주로 웹사이트, 블로그 제작에 사용되고 웹컨텐츠관리 분야에서는 압도적인 점유율을 자랑한다. 그만큼 큰 시장이기 때문에 유료 플러그인이 매우 다양하다. 그래서 잘 찾아보면 무료 내가 원하는 기능이 무료로 제공되는 플러그인을 찾아보기 쉽다.

관리는 편리해야 하지만 그 것을 위해서 너무 많은 노력이 들어가지 않아야지

중요한 이야기이다. 취미로 구축하고 운영하는 것이고 가볍게 사용하는 것이지만 어찌 됐든 사용하기로 한 이상 적절한 수준으로 관리해야 하고 그 과정이 편리해야 한다. 또 그 편리함을 구축하기 위해 들어가는 노력이 취미라고 할 만한 수준을 벗어 나는 것도 곤란하다.

관리에 필수적이거나 편리함을 위한 도구들

• SSH
  일단 리눅스 서버라면 기본 중에 기본인 관리도구 이다. ssh프로토콜을 통해 리눅스의 CLI(shell)을 사용할 수 있다. 기본적이고 필수적이다. 편리하지 않을 수는 있지만 관리를 위해 필요한 모든 행동을 여기에서 할 수 있다.
• Docker
  앞서 언급한 세가지 서비스를 리눅스 호스트에 직접 설치해서 운영하려면 상당한 기술과 트릭이 필요하다. 일단 넥스트클라우드가 문제인데, 이 녀석을 설치하려면 웹서버, PHP, MySQL(or MariaDB)를 먼저 설치해야 한다. 각각 설치하고 넥스트클라우드를 구동하는 것 자체가 꽤 기술을 필요로 하는 일이고 넥스트클라우드는 443포트 외의 다른 포트로 서비스 하는 것을 허용하지 않기 때문에 포트 관리에도 주의 해야 한다. 게다가 오픈프로젝트의 패키지 설치 스크립트는 웹서버(아파치) 설치를 포함하고 있다.(물론 제외하고 진행 할 수도 있지만……) 호스트 운영체제에서 온갖 충돌이 발생 할 수 있는 것들을 서버 관리자가 직접 고려해야 한다.
  도커시스템은 이런 불편함을 모두 해결해준다.
• Portainer
  도커시스템을 웹기반 GUI로 접근하게 해준다. 이 녀석도 도커를 통해 설치한다. 보안 관점에서 고려할 점이 있지만 가볍게 사용하는 서비스를 구동하는 홈서버라는 관점에서 적당히 타협하자.
• 그 밖에 몇 가지 도구들을 더 적용했지만 보안 강화를 위한 부분이다. 구상 부분에서 더 이야기 해보겠다.

2. 홈서버 구성

“서비스들과 도구들을 다 구성했는데 뭘 더 구성한다는 건가?”

구성 요소들만 주르륵 나열한다고 구성이 끝날 리가 없다. 일단 물리적인 구성도 고민해야 하고 네트워크 구조 정도는 구성이 되어야 실제 구축 작업을 시작할 수 있다. 물론 나는 이걸 다 하고 구축한 것이 아니라 구축한 결과물을 정리해서 적어두는 거다. 덕분이 많이 헤맸고, 어떤 이유로 든 다시 구축해야 하는 상황을 맞았을 때(실은 그게 어제 밤이다. 뭐가 꼬였는지 몇 시간 동안 헤맸지만 복구가 안됐다.), 헤매지 않기 위한 기록물이다.

물리적 구성, 네트워크(물리적인 부분 소프트웨어 적인 구조 등..), 보안, 백업시스템 이렇게 4~5개 관점에서 서버를 구성해보자.

(1) 물리적 구성

[하드웨어]

• 모델명 : LG 올데이 그램(13Z970-GX55K, 2017)
• CPU : intel i5-7200U(2core 4thread)
• RAM : 16GB
• Storage : 512GB(NVMe SSD)
• Wifi

[물리적 네트워크]

네트워크는 도커 네트워크라는게 따로 있지만, 먼저 물리적 구성을 점검해보자. 경우에 따라서는 직접구성할 수도 있겠지만, 대부분의 가정에서는 인터넷 공급자 – 라우터(공유기) – {홈서버, PC, 휴대전화, …}과 같은 구성을 피할 수 없음으로 간단하게 점검만 해보도록한다.

대부분 가정에서는 아래 도표와 같은 네트워크 구성을 가지고 있을 것이다. 다른 점이 있다면 cloudflare proxy라는 부분인데 취미 수준의 서버관리자라면 보안관리에 대한 고민은 해본적도 없던가 아직 고민만 하고 있을 것이다. cloudflare의 무료 플랜 만으로도 취미수준의 서버관리자가 할 수 있는 어떤 것보다 훌륭한 보안 옵션을 제공한다(왠만하면 쓰도록 하자). 그렇다고 프록시를 거치도록 설정하는 것 만으로는 아무것도 하지 않은 것 보다 조금 나은 것에 불과하므로 보안조치에 대해서는 나중에 다시 살펴보도록 하자.

인터넷망과 라우터를 직접 연결한 선은 PC나 IPTV, 휴대전화 등이 사용하는 망을 의미한다. 별다른 이유가 없다면 이렇게 쓰면 된다. 이런 장치들은 인터넷 망으로부터 들어오는 요청을 처리하는 것이 아니므로 보안 상 문제 될 것이 없다. 물론 어떤 종류의 악의적인 조작이 없는 정상적인 장치 일 경우에 한정이다. 해킹 프로그램이 깔려있으면 별수 없지 않나.

본격적으로 점검할 부분은 오히려 간단하다. 위 도표와 같이 구성된 홈서버가 인터넷 망에 서비스 되도록 하기 위해 필수 조건은 단 하나이다. 바로 포트 포워딩이다. 인터넷 망의 모든 요청은 라우터가 수신한다. 라우터는 그 요청을 어디로 보내야될지 알지 못하므로 그냥 무시하게 된다. 포트포워딩은 라우터에게 1234라는 포트로 들어온 요청은 홈서버의 5678이라는 포트로 보내서 처리하라고 알려주는 것이다. 포트포워딩이 되어있고 도착 포트에 어떤 서비스가 존재한다면 이곳으로 전달된 요청은 서비스가 처리 하게된다. 이 서비스에 어떤 취약점이 있다면 공격자에게 노출되어있다는 의미다. 포트포워딩은 최소로만 하도록하자.

포트포워딩 이란?

아래 그림은 설명의 내용을 예시를 들어 도표로 나타낸 것이다. 서버에 서비스가 대기 중인 포트로 요청하더라도 포트포워딩 규칙에서 외부포트를 다른 포트로 지정해 두었다면 해당 요청은 무시된다. 당연한 얘기지만 내부 IP로 요청하게되면 그 요청은 도착 할 곳을 찾지 못한다.

정리하면 라우터가 가지고 있는 공인 IP로 포트포워딩 규칙에 정의된 외부 포트로 도착하는 요청은 규칙에 따라 “내부 IP:내부 포트”로 전달하게 된다.

홈서버의 내부 IP 고정하기

그러면 네트워크 구성도에 “홈서버 IP 고정”이라는 의미는 뭐냐?

가정과 같은 소규모 네트워크는 IP 자원 관리를 DHCP에 대충 맡겨둔다. 이렇게 하면 알아서 사용하지 않는 IP를 할당해주기 때문에 신경 쓸 것이 없기 때문이다. 즉 자동 할당이라는 건데, 공유기가 재시작하거나 홈서버가 재시작 할 때 마다 공유기가 매번 다른 IP 주소를 할당한다면 어떻게 되겠는가?

포트포워딩 규칙은 내부 IP를 반드시 지정해야 되는데 서버의 내부 IP가 계속 바뀌게 되므로 포트포워딩이 재대로 작동할 수 없다.
홈서버의 IP는 DHCP 서버에 항상 같은 IP를 할당하라고 미리 알려주거나 홈서버가 IP할당을 요청 할 때, 자동 할당이 아닌 정해진 IP를 요청하도록 해야 한다. 물론 전자가 훨씬 편하고 잘 작동한다. 후자의 경우는 홈서버가 재시작하는 사이 다른 장치가 홈서버의 IP를 먼저 할당 받으면 IP 충돌이 발생한다.

(2) 도커 네트워크 및 서비스 구성

도커는 넓은 의미의 가상화에 해당한다. 운영체제 커널은 호스트의 것을 공유(커널 수준의 처리를 호스트 커널에 호출한다는 의미)하지만 그 밖에 것들은 컨테이너라는 격리된 환경에서 작동한다.

격리는 조금 더 높은 수준의 보안과 관리상의 편리함을 제공한다. 파이썬을 사용해본 사람이라면 프로젝트 별로 다른 environment를 정의 해서 써봤을 것이다. 비슷한 개념으로 이해할 수 있다.

격리된 개별 컨테이너간의 통신을 위해서 도커는 가상 네트워크를 사용한다. 내가 구성한 서비스와 도커 네트워크를 도식화하면 아래의 그림과 같이 표현할 수 있다.

초록색 점선은 보안 터널이다. 물리적으로 패킷은 호스트 게이트웨이와 라우터를 거칠 수 밖에 없지만, 이 보안 터널을 통한 통신은 클라우드플레어 서버와 클라우드플레어 데몬(내 서버에서 실행)간의 통신이고 자세한 원리는 모르지만 라우터의 포트포워딩 없이 외부요청을 전달 할 수 있다. 암호화된 패킷을 이용하고 클라우드플레어 데몬이 내부에서 외부로 연결을 요청해서 일종의 터널의 만들고 그 터널을 통해서 통신하는 것으로 이해된다.(정확하지는 않지만…) 아무튼 보안을 위해서 공개된 포트가 아니라 암호화된 통신과 클라우드플레어가 제공하는 2단계 인증 등을 통해 보안 중요도가 높은 관리 도구들은 강화된 보안을 적용한 것이다. 뿐만 아니라 도커 네트워크 구성에서도 서비스 네트워크인 caddy_net과 관리자 네트워크인 admin_net으로 격리하였다.

(3) 보안을 위한 구성

네트워크와 도커 구성을 통해서 일정 수준의 보안을 달성할 수 있다.(앞서 설명한 것들..) 예를 들면 포트포워딩으로 노출 시키는 포트 수를 제한하고, 도커를 이용해 서비스와 호스트를 격리하는 것들이 보안 조치에 해당한다. 그리고 기본적으로 내가 구동하는 서비스들을 개발한 개발자들도 보안을 위한 많은 노력을 경주하고 있다.
하지만 아무리 홈서버라고 해도 이것 만으로는 충분하지 않다.

왜 그런지 생각해보자.

일단, 봇에 의한 무차별 공격에 대한 대책이 없다. 예를 들면 로그인 페이지에 관리자 ID로 무차별 패스워드 공격을 한다면 어떻게 될까? 예측하기 쉬운 비밀번호라면 오래지 않아 관리자 권한을 탈취 당할 것이다.
두번째로는 워드프레스에 댓글에 스팸공격에 대한 대책도 없다.
세번째로는 내가 서비스하는 앱의 개발자가 무차별 공격에 대한 방어 조치로 로그인 실패 시 계정이나 공격자 IP를 차단하도록 했다고 생각해보자. 그러면 무차별 공격에 의해 관리자 권한이 탈취되지 않더라도 내가 필요할 때 내 계정을 사용하지 못 할 수 있다.(오늘 아침 격은 일이다..-_-;;)
마지막 네번째로 일종의 무차별 공격인 DDos에 취약하다. 내가 운영하는 서비스 앱에 DDos 취약점이 있다면 단순히 부하를 증가시키는 요청을 반복하기만 해도 내 서버는 금새 다운될거다.(구형 랩탑을 활용한 빈약한 하드웨어라서 더 그렇다.)

그렇다면 서버 보안은 어떻게 할까?

일단 서버 보안의 개념을 살펴보자. 난 보안 전문가가 아니다. 그냥 홈서버를 구축하고 약 2~3주 운영하면서 필요한 보안 조치를 취하면서 생각해본 것들을 정리해서 글을 써보려고 한다.

[노출 면적과 심층보안]

노출 면적은 공격 가능한 요소가 얼마나 많은 지를 의미한다. 노출면적은 인터넷, 내부망, 도커네트워크, 애플리케이션(서비스 데몬 등) 등에 있을 수 있다. 하나씩 살펴보도록하자.

• 인터넷 노출 면적
  공개된 IP의 갯수와 포트의 갯수가 노출 면적이다. 가능한 줄여보자.
• 내부망 노출 면적
  내부망에 접속 할 수 있는 장치의 갯수가 노출면적이다. 공유기에 접속 비밀번호를 설정하자.
  그리고 내부 망에 접속한 장치가 서버에 접근 할 수 있다면 이것도 서버의 노출면적이다. 서버에 방화벽을 설치해서 내부 망 접속자도 접근하지 못하도록 하거나 호스트 OS가 노출하는 포트 수를 최소화 해야한다.
• 도커 네트워크 노출 면적
  호스트 네트워크로 브릿지(포트포워딩과 유사한 개념)된 아이피와 포트의 갯수다. 이것도 가능한 줄여보자.
  또는 어떤 도커 네트워크에서 실행되는 컨테이너가 다른 도커 네트워크에 접근 하도록 허용한 갯수다. 이것도 줄여야 한다.
• 애플리케이션 노출 면적
  서버에 구동되고 있는 모든 애플리케이션을 의미한다. 가능한 줄여보자.
  서버에 운영체제를 최소 구성으로 설치해야 한다.(KDE, Gnome, Cinamon 같은 GUI는 굳이 설치 하지 말자)

결론은 노출 면적은 가능한 줄여야 한다는 것이다. 그리고 가장 앞에 노출된 인터넷 뿐만 아니라 내부망, 도커내트워크, 애플리케이션 등 여러 단계에 걸친 노출면적을 최소화하는 것은 일종의 심층방어의 개념이다.

[취약점 방어와 심층보안]

취약점은 운영체제나 애플리케이션이 의도하지 않은 동작을 하는 것을 말한다. 이 의도하지 않는 동작은 운영체제 또는 애플리케이션의 관리자 권한을 탈취하는 결과로 이어질 수 있다. 운영체제나 애플리케이션이 자체적으로 가지고 있는 취약점이라는 것인데 어떻게 방어 할 것인가?

두 가지 관점에서 생각해 볼 수 있다.

첫째, 운영체제와 내가 운영하는 서비스 애플리케이션의 최신화(보안업데이트 적용) 이다. 취약점 방어의 기본이자 가장 중요한 부분이다.

둘째, 운영체제와 서비스 애플리케이션을 격리하여 취약점으로 인한 보안 침해의 범위가 확대되지 않도록 해야한다. 기본적으로 도커와 같은 애플리케이션 격리도구를 사용하고 애플리케이션들이 운영체제의 관리자 권한으로 실행되지 않아야 한다. 취약점으로 인해 애플리케이션의 모든 권한이 탈취됐을 때, 그 애플리케이션이 운영체제의 관리자 권한으로 실행되고 있다면 운영체제의 관리자 권한도 위태롭게 된다. 이렇게 되면 애써 격리한 다른 애플리케이션이 서비스하고 있는 자료들 또한 위태롭게 된다.

최신화와 같은 기본적은 방어에 애플리케이션 격리까지 적용하는 것이 취약점 방어에서 심층방어이다.

[무차별 공격 방어와 심층보안]

• 충분히 길고 예측하기 어려운 비밀번호
• 알려진 공격 패턴을 방어하는 정교한 방화벽 설정
• 공격 봇에 대한 Challenge 적용(“로봇이 아닙니다.” 다들 한번쯤 해보셨죠?)

마찬가지로 한 가지 방법이나 첫 번째 단계 뿐만 아니라 다양한 방법과 다양한 단계에 보안조치을 했다면 그것이 심층보안이다. Challenge는 로그인 시도 전 단계에서 알려진 공격 패턴을 차단하는 것은 무차별 공격이 진행되는 단계에서 방어하는 것이다.

[보안구성 예: 나는 이렇게 했다.]

노출면적 관리

• 인터넷 노출면적 최소화
  포트포워딩으로 외부 요청을 허용한 IP (1개, 홈서버)
  포트포워딩된 포트 – 80, 443, 3478 (3개)
  관리용 애플리케이션은 포트 노출 없이 보안 터널 적용(클라우드플레어)
• 내부망 노출면적 최소화
  와이파이 비밀번호 난독화(예측불가)
• 도커 네트워크 노출면적 최소화(격리)
  각 컨테이너 간의 통신은 서비스를 위해 필요한 최소한으로 제한.(도커네트워크 구성도 참조)
  관리 애플리케이션이 실행되는 도커네트워크에는 더 강화된 보안 적용.(도커네트워크 구성도 참조)
  각 애플리케이션이 서비스 되기 위해 필요한 DB, 웹서버와 같은 애플리케이션 간에도 격리 적용.(모든 애플리케이션이 한 컨테이너에 들어있지 않다는 의미)
• 애플리케이션 노출 면적 최소화
  딱 내가 쓸거만. 도커네트워크 구성도를 살펴보면 SSH 포함 8개의 애플리케이션이 실행된다.
  물론 각 애플리케이션이 웹서버나 DB가 필요하면 이런 것들이 실행되는 컨테이너들도 실행되고 있다.
  총 25개 컨테이너 실행 중.
  

취약점 관리 및 애플리케이션 격리

나도 아직 적용 안 했다. 자동 업데이트는 적용 예정이고, 루트리스 도커는 적용했다가 다시 루트풀 도커로 돌아왔다. 왜 다시 돌아왔는가? 응답 시간이 미세하게 길어진다. 문제될 정도는 아니지만 느껴질 정도는 되어서 별로 다. 자세한 내용은 별도로 포스팅 해야겠다.(긴 얘기다. 까먹기 전에 포스팅 해야 할텐데…) 루트리스 도커를 적용하는 것은 도커를 사용하는 환경에서는 가장 좋은 보안 옵션이지만, 필수적이라고 생각하지는 않는다.
기본적으로 내가 이용하는 애플리케이션의 공식 이미지와 컴포즈 파일은 도커 내부 사용자 권한이 일반사용자이기도하고, 도커는 기본적으로 샌드박스로 작동한다. seccomp 규칙에 의해서 도커 내부의 사용자나 애플리케이션이 호출할 수 있는 시스템 명령어는 제한되어 있다. 그리고 도커소켓을 컨테이너 내부에 노출 하지 않는 한 컨테이너 내부에서 호스트 운영체제에 할 수 있는 행동은 이미 충분히 차단되었다고 생각한다. 이게 불충분하다고 생각하는 사람들을 위해 루트리스 모드가 있는 거다. 아무런 제약 없이 좋은 보안을 제공한다면 모르겠는데 조금 불편한 구석도 있다(예: 루트리스에서 실행하기 위해 커스텀 이미지를 생성 해야하는 경우가 있다.). 그러니 각자 판단하도록 하자.

• 운영체제 및 도커 자동 업데이트 스크립트 작성 및 systemd timer 적용.
• 루트리스 도커로 마이그레이션(더 나은 격리)

무차별 공격 방어

• Cloudflare reverse proxy 적용 <–알려진 공격 패턴차단, DDos 방어를 해준다.
  wordpress 호스트에만 적용했다. 무료 플랜에서는 단일 요청으로 가능한 최대 업로드 용량이 100MB로 제한된다. 넥스트클라우드나 오픈프로젝트에 적용하면 꽤 귀찮을거 같아서 일단 미적용.(이 후 100 MB 단일 파일 업로드가 없을거 같으면 적용할 예정이다.)
• Cloudflare Turnstile(봇 challenge)
  워드프레스는 플러그인으로 입력 창이 노출된 경우 챌린지 하도록 설정
  터널을 통해 접근하는 관리 도구는 보안규칙을 통해 챌린지 하도록 설정
• SSH 보안 조치
  보안키를 생성해서 적용하고 패스워드를 통한 로그인 금지
  포트 노출 없이 터널로만 접근 가능.
  터널 접근 시 이메일을 이용한 2단계 인증
• 로그인 시도 실패 5회 반복 시 계정 차단 – Nextcloud, Openproject에 적용.
• 로그인 시도 실패 반복 마다 로그인 지연 시간 증가 – Nextcloud에 적용.

3. 정리

정리에 앞서 백업 전략 구성은 다음 포스트로 미루기로 한다.(아직 구상 중…)

정리하면 보안은 공격자를 차단하거나 귀찮게 하기 위해서 사용자와 관리자도 어느 정도의 귀찮음을 감수하게 된다. 이를 타협해야 될 것이고, 다양한 방법과 다양한 단계에 보안 조치를 취하는 심층방어의 개념을 적용하도록하자. IT 보안에서도 심층방어라고 하나? 원자력공학전공인 나는 원자력발전소의 안전에 관해서 이야기할때 심층방어라는 표현을 종종들었기 때문에 사용해 봤다.(아님 말고)

그리고 다양한 방법을 다양한 계층에 적용하는 것은 적절한 조합을 찾을 경우 사용자와 관리자가 감수해야 할 귀찮음을 감소시키는 방안이 될 수도 있다.

마지막으로 나머지는 직접 신경써야 할 것이지만 무차별 공격 방어는 직접 해보기엔 아마추어에게 쉬운 일이 아니다. 왠만하면 cloudflare나 비슷한 서비스를 이용하도록 하자. 2~3주 쯤 운영해본 결과 사실이게 제일 중요한거 아닌가 싶다. 이걸 적용하기 전까지는 무차별 공격시도가 끝도 없었다. LOG를 살펴보면 로그인 실패가 1분에 6~8회정도 기록된다.(ssh의 경우)
넥스트클라우드도 오늘 아침에 내 계정이 차단되어있었다.

끝~.