홈서버 구축 - 보안, 관리, 아키텍처(2)

홈서버 구축 - 보안, 관리, 아키텍처(2)

홈서버에 관한 보안, 관리, Application 아키텍처에 대해서 포스팅을 이어 나가도록 하겠다.

이전글에 이어서 서버의 보안 및 애플리케이션 레벨 아키텍처, 사용 까지 포스팅하도록 하겠다.

홈서버에 관한 개요는 아래의 링크에서 확인하도록 하자!

 

홈서버 구축 시리즈

홈서버 구축 - 개요, 설계, 네트워크(1)

홈서버 구축 - 보안, 관리, 아키텍처(2)

 

목차

1. 보안
2. 관리
3. 최종 아키텍처

 

 

1. 보안

이전글에서 보안을 설정을 해도 무차별적인 공격(Brute force)이 들어온다는것을 확인했을것이다.

서버를 관리하는 직무, Linux 에 익숙한 사람들은 이미 알고있을만한 내용이고, 더 좋은 보안 방법들을 가지고 있을것이다.

필자또한 관리가 너무 복잡하지 않은선에서 계속해서 보안요소를 수정,추가 하고 있는중이다.

 

우선 필자의 홈서버에 나름대로 적용했었던 보안설정들을 리스트업 먼저 해보도록 하겠다.

 

- 실제 적용한 설정

1. 필요한 port 만 open 하기
2. 주로(자주) 사용하는 port 번호 변경
3. Fail2ban, ufw 로 방화벽, ssh 보안
4. root 계정 로그인 차단
5. 일반 user 계정 로그인시 password 사용 X -> 특정 pub_key 만 허용
6. sudo 권한 접근 제어(특정 계정만 허용)
7. 중요 디렉토리 접근제한
8. Web Application 의 경우 Gateway(Spring) 단에서 해외 IP 차단 설정
9. github actions, jenkins 와 같이 CICD 파이프라인 전용 계정 추가 및 특정 명령어만 실행 가능하게 설정
10. Application 및 Server 에 요청은 외부 리버스 프록시 서버를 두어 IP 노출 차단

 

- 고려했던 설정 및 미적용 설정

1. 2FA 적용(Google Authenticator)
2. MySQL, Redis, Nginx 에 관한 공격패턴 감시 기능 
3. SELinux - 파일, 프로세스 권한 관련 보안기능
4. SSH 접속은 VPN 을 통해서 접속하도록 하는 기능

 

이정도를 해도 취약한 부분은 존재하기 마련이고, 충분하지 않을 수 있다 다만 너무 과한 보안설정을 통해

배보다 배꼽이 더 커지는 상황이 발생하는건 원치 않았다.(관리, 자원 점유)

 

"고려했던 설정, 미적용 설정" 항목은 그래서 바로 도입하지 않았다.

하나씩 적용을 하지 않은 이유를 먼저 알아보도록 하겠다.

2FA 인증의 경우 CICD 파이프라인 구축, 자동화 스크립트 사용시 제약사항이 존재했고 Login Session Timeout 즉 재로그인 해야할때마다 인증을 해야했기 때문에 너무 불편했다.

 

특정 서비스들의 공격패턴 감시 -> 차단의 경우 로그 확인시 공격시도가 없었고(Nginx 제외) DB 내부에는 또 보안설정을 추가로 해주었기 떄문에 적용 하지 않았다.

4번의 VPN 을 통해 SSH 접속 해당 부분은 Proxmox 로 하이퍼바이저를 구축했다는 가정하에 계획 해두었던것인데, 현재는 VPN 서버를 따로 둘 수 없는 상황이기에 설정해두지 않았다.

 

그외에 Docker 네트워크 별도 분리, DDos 공격 차단등 추가 설정이 있지만 DDos 공격 차단은 인터넷제공업체(통신사)를 통해서 1차 방어가 되고 있기때문에 별도 적용하지 않았고, Docker 네트워크의 경우 이미 여기까지 뚫린거면 다 뚫렸다고 생각해서 추가 하지않았다.

여기까지가 필자가 생각한 관리가 복잡하지 않으면서, 사용하기 편한 보안설정을 적용해 둔 내용이다.

 

 

- 외부 리버스 프록시 서버?

필자의 경우 Domain 을 연결해두었기 때문에 IP 가 노출되는 구조였다. 다만 IP 가 공공에 노출되면 공격자들에 의해 더 많은 공격들이 들어올것이 뻔했다.(오라클 클라우드 서버가 그랬다) 

이때 IP 를 공공에 노출하지 않는 방법중 하나가 "Reverse Proxy" 이다. 

 

Frontend, Backend 개발을 하다보면 종종 듣게 되는 단어일것이다. 

리버스 프록시는 Client 가 최종 목적지 서버(홈서버)를 알 수 없으며, 최종 목적지 서버에 보내는 요청방식을 숨길 수 있다.

그렇다면 Reverse Proxy 를 하려면 서버가 1대가 더 있어야 하는것이 아닌가? 

 

네 맞습니다, 별도의 Reverse Proxy 서버가 한대가 더 필요하게 됩니다.

다만 Cloudflare Proxy 를 사용한다면 서버가 없더라도 설정할 수 있게됩니다. 

무료 DNS 제공, DDos 방어, 트래픽 정보 제공, SSL 인증서 등등 다양한 기능을 제공하고 있으므로 관심이 있다면 알아보는것을 추천합니다.

CloudFlare Reverse Proxy

 

필자의 경우 놀고있는 Oracle Cloud Server 가 1대 남아있었기에 Oracle 서버를 Reverse Proxy 로 사용했다.

Oracle Cloud 서버의 경우 보안 리스트 설정에 있는것들 또한 기본적으로 설정해둔 상태였다.

 

미리 설치되어있던 NGinx 에 SSL 인증서를 추가했고, Domain 을 오라클 서버로 연결해 두었다.

이후 Nginx 의 Reverse Proxy 설정을 통해 특정 Domain 으로 들어오는 요청들은 홈서버로 다시 보내도록 해주었다.

해외 IP 차단의 경우 Nginx 에 연결하여 사용할 수 있지만 Oracle 서버의 경우 리소스가 매우매우매우 한정적이기때문에 홈서버의 

Gateway 에서 요청을 막는것으로 설계를 했다.

 

Client 의 요청을 리버스프록시 서버를 거치게 되는 만큼 속도는 느려질 수 있다. 

이러한 부분은 감안해야 할것같다.

 

 

 

2. 관리

홈서버를 활용하는 방법들은 많지만 필자의 경우처럼 개인 Cloud, 개발 DB, 서버들을 사용하는것이 가장 큰 비중일것이다.

수많은 Application 을 관리, 사용하기에 가장 좋은 방법은 많이 사용하는 Docker 를 사용하는 방법일것이다. 

추가로 많은 기업들에서는 수많은 Container 관리 및 확장 목적으로 K8s 를 사용하지만, 홈서버 구축에 있어서는 

오버 엔지니어링일것이다......

그렇기에 Docker Container 관리에 중점을 두어 구축하게 되었다.

 

- Docker Swarm + Portainer

Docker Swarm 의 경우 K8s 와 같이 오케스트레이션 도구중 하나이다. K8s 가 하는일처럼

node 관리, LB(Load Balancing), 확장, 네트워킹등 자동화 및 관리를 할 수 있는 도구이다.

다만 꼭 여러 node 를 관리한다는 측면이 아닌, Container 그룹 관리 측면에서 도입 결정을 하게 되었다. 

 

Docker 의 Container 를 서버 재기동마다 하나씩 실행시키는것은 너무 비효율적인 방법이다.

필자는 모든 Docker Container 를 Docker Compose (yml) 로 관리하는데 

(관리,유틸), DB, Applications 를 그룹화(stack) 하여 Container 실행, 관리를 하게 했다.

Clustering 이나, Container 확장을 쉽게 할 수 있으니, 효율적으로 관리하고자 한다면 알아보도록하자.

 

기본적으로 커맨드를 사용하여 Docker 를 관리하지만, 커맨드가 너무 길어진다거나, 로그 확인 등등 CLI 환경에서는 불편할때가 존재하는데 Portainer 는 Docker 를 WebUI 로 관리하게 해주는 도구로서, 도커의 기본적인 기능들을 클릭만으로 사용할 수 있다.

 

Docker Swarm

Portainer

 

 

- Cockpit

Cockpit 은 간단하게 WebUI 기반의 모니터링, 관리 도구이다.

서버에 해당 도구를 설치하게 되면, 설정한 포트로 접속시 (Ex. localhost:9090) 서버자원에 대한 모니터링, 

네트워크, 작업, 터미널 등등 CLI 로 작업해야하는 거의 모든 부분을 UI 로 편하게 작업할 수 있다.

원격에서 접속하는것은 기존의 SSH 와 동일하지만, 모바일 환경에서도 원격 업무가 가능한 점이 가장큰 차이점이라고 할 수 있겠다.

다만 리소스 점유, 해킹등의 이유로 필요할때만 실행시켜 사용하고 있다.

 

 

 

3. 최종 아키텍처

 

위의 다이어그램이 필자가 최종적으로 구축한 인프라이다.

홈서버내에 아이콘이 누락되어있는게 좀 많긴하지만,,,, 글을 쭉 읽고 이해가 되었다면 어떤식으로 Application 들을 사용하는지는 

알고 있을것이라고 생각된다.. 

 

다만 홈서버의 활용도를 더 높여가면서 드는 하나의 아쉬움은 돈을 좀더 들여서,,, 하드웨어의 성능을 올려둘걸,, 이라는 아쉬움이다.

공부하고 있는 도구들(Kafka, Elastic Search, etc Applications,,,,) 전부를 한번에 운용하기에는 가끔 불안한 상황들이 나왔기 때문이다.

 

 

개발 서버 및, Spring Application 들의 경우 Docker Registry + ShellScript, Github Actions 를 활용해서 CICD 파이프라인을 사용하고 있었는데 이럴때도 스펙에 관한 아쉬움이 올라온다....

아래는 필자가 사용하는 CICD 파이프라인에 대한 간략한 다이어그램이다... 

Giuhub Actions

 

 

Docker Registry

 

Jenkins, Travis CI 와 같은 CICD Tool 을 쓰면 안되나? 하는 의문이 있을수도 있다. 

하지만 계속 언급했듯, 모든 Tool 들을 홈서버에 띄운 상태로 사용하는것은 성능적으로 부담이 있었기에, 현재는 잘 사용하지 않는다.

Jenkins 의 경우 Github 과 연동하여 필요한 경우에만 컨테이너 실행하여 사용하는 방식도 사용했었지만, 그 시간들을 들여서 사용하는것보다는, 완벽한 자동화가 아닌 현재의 파이프라인도 복잡하거나 귀찮지 않아서 해당 방식들을 차용하고 있다.

 

 

홈서버를 구축함에 있어 그래도 가성비를 챙기면서, 활용할 수 있는 자원내에서 만족할 만한 인프라를 구축한것 같다.

또한 구축하면서 많은 개념들을 자연스레(강제적) 공부할 수 있게되었던게 좋은점중 하나였던것 같다.

로컬 PC 에서 모든 작업을 하다가 별도의 머신으로 분산한것도 꽤나 만족하면서 사용하고 있다. 

 

궁금한점이나 이외에 더 좋은 설정들, 아키텍처 등등 좋은 구성이 있다면 언제든지 공유해주시면 감사하겠습니다~