Hakawati Security Lab

WSL2 에서 Systemd 사용하기

hakawati — Tue, 18 Jul 2023 23:49:59 +0900

Overview

WSL을 기본적으로 설치하면 sysvinit, 줄여서 init을 사용한다. 이는 오래된 시스템으로 centos 기준 6버전 이하, ubuntu 기준 12.04 이하 버전에서 사용해 왔다. 최신 리눅스 시스템은 init 대신 systemd를 사용한다. 이 둘의 차이점은 서비스를 실행할 때 명령이 service이냐 systemctl 이냐 차이를 가지고 있다. 최신 리눅스 시스템을 사용하는 사용자라면 systemctl에 서비스를 구성하는 것에 익숙하기다. 이 포스트에서는 service 대신 systemctl을 사용하는 방법을 설명한다.

Prepare

WSL에서 init 대신 systemd를 사용하려면 기본적으로 WSL 2를 써야만한다. WSL 2 구성은 아래 포스트를 참고한다.

[Information Technology/Operation System] - WSL Version Upgrade

Install

아마도 2022년 9월 이전에 설치한 WSL 2 버전에서는 systemd를 사용하기 위해 다양한 방식이 도전되어 왔었다. 대부분 누군가가 systemd를 활성화하기 위한 스크립트를 제작하고, 이것을 다운로드 받는 방식으로 진행되었다.

https://gist.github.com/djfdyuruiry/6720faa3f9fc59bfdf6284ee1f41f950

WSL 2 - Enabling systemd

WSL 2 - Enabling systemd. GitHub Gist: instantly share code, notes, and snippets.

gist.github.com

https://dzzienki.tistory.com/93

window wsl2 systemctl 활성화

윈도우 터미널에서 지원하는 wsl2 ubuntu 22-04 버전은 기본적으로 systemctl 을 지원하지 않습니다. 그래서 수동 설정으로 사용할 수 있도록 설정을 해야하는데 방법은 sudo apt install git git clone https://git

dzzienki.tistory.com

하지만 Microsoft에서 공식적으로 systemd 사용을 지원을 한다고 포스팅이 올라왔고, 오피셜 문서에도 관련 내용이 업데이트 되었다.

https://devblogs.microsoft.com/commandline/systemd-support-is-now-available-in-wsl/

Systemd support is now available in WSL!

Systemd support is now available in WSL! The Windows Subsystem for Linux (WSL) can now run systemd inside of your WSL distros, empowering you to do more with your Linux workflows on your Windows machine. This post will cover: What is systemd?

devblogs.microsoft.com

https://learn.microsoft.com/en-us/windows/wsl/systemd

Use systemd to manage Linux services with WSL

Learn how to use systemd to manage Linux services with Windows Subsystem for Linux.

learn.microsoft.com

방법은 간단하다. wsl을 최신 버전으로 업데이트(최소한 wsl 0.67.6 이상 버전으로)하면 된다.

wsl --update

하나 추가로 확인해야할 것은 /etc/wsl.conf에 systemd=true로 설정되어 있는가이다. ubuntu 22.04에는 기본적으로 설정되어 있지만, 다른 유형의 리눅스나 낮은 버전의 ubuntu에는 이 설정이 안되어 있을 수 있다.

cat /etc/wsl.conf

[boot]
systemd=true

WSL Version Upgrade

hakawati — Mon, 17 Jul 2023 22:53:34 +0900

Overview

WSL은 Windows Subsystem for Linux의 약어로 윈도우에 종속된 리눅스 시스템을 운영하는 것을 의미한다. 과거에는 하이퍼바이저(VMware, Virtualbox)와 같은 가상머신 소프트웨어를 설치하고 리눅스 시스템을 올려 사용했지만, WSL이 나온 이후로 윈도우 환경에서 편리하게 리눅스를 사용할 수 있다. WSL을 기본적으로 설치하면 WSL 1 버전이 설치되기에 이 포스트에서 WSL 2 설치 하는 방법에 대해 소개한다.

Version Check

우선 WSL 버전을 확인한다. WSL 버전은 1과 2로 구분되는데 버전 1은 systemd를 파이썬 스크립트로 편법적으로 사용해야 이용할 수 있어 운영상 안전성이 상당히 떨어진다. 반면 버전 2는 공식적으로 systemd를 지원한다. 버전을 확인하는 방법은 먼저 wsl을 설치하고 재부팅 후 Microsoft Store에서 Ubuntu 최신 버전을 다운로드한다. 다운로드가 끝나면 Ubunbtu install을 완료하고, 그 후 cmd나 powershell에서 버전 확인이 가능하다.

Ubuntu Install 완료 화면

아래 처럼 wsl --list --verbose 명령을 사용하면 실행중인 WSL 환경과 버전을 확인할 수 있다. 실행중인 시스템 환경이 없다면 첫 번째 명령이 실행된 것처럼 보여지며 버전을 확인할 수 없다.

WSL 버전 확인

WSL Upgrade

만약 Version 이 1로 확인된다면, 다음과 같이 Version 2로 업그레이드할 수 있다. 업그레이드 시 먼저 확인해야 할 것은 윈도우 버전이다. Windows 10을 사용 중 이라면 다음 버전을 충족해야하고, 버전 확인 방법은 cmd에서 ver 명령으로 확인할 수 있다.

x64 시스템의 경우: 버전 1903 이상, 빌드 18362 이상
ARM64 시스템의 경우: 버전 2004 이상, 빌드 19041 이상

관리자 권한으로 cmd나 powershell에서 다음 명령을 입력한다. 첫 번째 명령은 WSL을 사용하겠다는 의미이고 두 번째 명령을 가상머신 기능을 활성화하겠다는 의미이다.

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

다음 Linux 커널 업데이트 패키지를 설치한다. x64또는 AMD64에 따라 설치 파일이 다르다. 내 컴퓨터가 어떤 시스템 유형인지 확인하고 싶다면 systeminfo | find "시스템 종류" 명령으로 확인할 수 있고, 한글 윈도우가 아니라면 systeminfo | find "System Type" 명령으로 확인할 수 있다.

설치가 다 끝났다면 재부팅을 하고, WSL을 운영할 때 기본 버전이 2를 사용하겠다는 명령을 입력한다. 꼭 재부팅을 한 후에 진행해야 한다.

wsl --set-default-version 2

이제 Microsoft Store에서 설치하고 싶은 Sub-System을 검색해 설치를 진행한다.

vscode server cli 구축하기

hakawati — Sun, 2 Jul 2023 13:40:17 +0900

일전에 vscode를 구축하는 포스트를 발행한 적이 있다. 이 방식은 vscode 서버부터 NginX까지 구축을 진행하여 완전한 섯버 형태로 구축하는 내용을 다룬다.

[Information Technology/Programming] - Code Server - 구축편

이 방식보다 더욱 편리하게 Code Server를 구축하는 방식이 vscode CLI server를 구축하는 것이다. 아마도, vscode 개발 팀에서 이야기하는 vscode의 발전 방향에서 지난 구축 방식은 Remote - SSH, Tunnels에 해당하고, 이번 포스팅은 Remote - SSH, Tunnels + Dev Containers 방식에 해당하는 것으로 추측한다.

vscode's feature

Prepare

우분투 리눅스 시스템(WSL도 가능)

Installation

Download

vscode server 설치는 매우 단순하다. MS에서 제공하는 code cli를 다운로드한다.

ubuntu@ip-172-31-13-104:~$ curl -Lk 'https://code.visualstudio.com/sha/download?build=stable&os=cli-alpine-x64' --output vscode_cli.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   133  100   133    0     0    115      0  0:00:01  0:00:01 --:--:--   115
100 6852k  100 6852k    0     0  4594k      0  0:00:01  0:00:01 --:--:-- 25.0M

다운로드가 되었다면 압축을 해제하는데 해제 위치를 /usr/local/bin에 구성한다.

ubuntu@ip-172-31-13-104:~$ sudo tar xvzf vscode_cli.tar.gz  -C /usr/local/bin/
code

Execution & Configuration

이제 로컬에 vscode-server 명령으로 추가적인 구성 없이 vscode server를 실행할 수 있다. 첫 실행은 라이선스 동의와 인증에 관한 설정 그리고 tunnel 키를 설정한다. 라이선스 동의는 자동으로 yes로 설정되어 있어 엔터를 눌러 동의한다.

ubuntu@ip-172-31-13-104:~$ code tunnel

VS Code Server

*
* By using the software, you agree to the
* the Visual Studio Code Server License Terms (https://aka.ms/vscode-server-license) and
* the Microsoft Privacy Statement (https://privacy.microsoft.com/en-US/privacystatement).
*

✔ Do you accept the terms in the License Agreement · yes

다음 장치 인증이다. 장치 인증은 github를 이용한다. github의 device 인증은 사용자 기기를 인증하는 것으로 인증한 기기가 github에 로그인된 상태로 사용자 기기 인증을 진행하는 방식으로 인증하는 구성이다. 다음과 같이 인증 코드를 출력되면 https://github.com/login/device에 방문한다.

To grant access to the server, please log into https://github.com/login/device and use code 1AE0-305C

방문한 사이트에 인증 코드를 입력하고 continue를 누른다.

github.com/login/device에 인증 코드 입력

다음 이미지처럼 github에 로그인된 사용자의 정보가 출력되며 이 연동을 허용하겠는지, vscode가 github의 어떤 데이터에 접근할 것인지를 보여주며, 정보가 맞는지 확인했으면 Authorize Visual-Studio-Code를 선택한다.

정보 확인 및 인증

인증이 완료되면 다음과 같은 화면으로 설정이 완료된다.

인증 완료

이제 vscode server가 설치되는 시스템에 설치하는 시스템이 어떤 이름으로 불리길 원하는지 작성하는 prompt가 실행된다. 이 구성은 우리가 직접 구축한 웹 서버에 접근해서 vscode를 이용하는 것이 아닌 MS 클라우드 시스템에 접근했을 때 터널링 구성이 되면서 우리가 구축한 vscode에 접근할 때 우리 시스템으로 접근하는 터널링을 식별하는 키로 사용된다.

✔ What would you like to call this machine? · hakawati-code

터널링 구성이 완료되며 vscode server가 운영 중인 채 도메인을 보여준다. 해당 사이트에 방문하면 vscode를 사용할 수 있다.

✔ What would you like to call this machine? · hakawati-code
[2023-07-02 02:04:19] info Creating tunnel with the name: hakawati-code

Open this link in your browser https://vscode.dev/tunnel/hakawati-code

URL 방문시 보여지는 첫 화면

허용 버튼을 클릭하면 github 인증이 되어야만 해당 도메인에 접근했을 시 내 code server에 접근할 수 있도록 자동으로 설정이 구성되며, 설정이 완료되었다면 언제 어디서든 동일한 코딩 환경을 이용할 수 있다.

마지막으로 code tunnel 명령으로 서비스가 시작되는데, 이는 원격 터미널로 연결했거나 로컬 쉘이 종료되는 순간 서비스도 함께 종료된다. 따라서 systemd를 이용해 백그라운드에서 서비스가 실행되도록 구성한다. 먼저 systemd 서비스 파일을 생성한다.

ubuntu@ip-172-31-13-104:~$ sudo vim /lib/systemd/system/code.service

다음과 같이 정보를 기입하는데 가장 중요한 것은 code server 설정 정보가 사용자 홈 디렉터리에 위치하기에 User와 Group을 구성하는 시스템의 사용자 이름으로 구성한다.

[Unit]
Description=VSCode CLI Server

[Service]
Type=simple
User=ubuntu
Group=ubuntu
ExecStart=/usr/local/bin/code tunnel

[Install]
WantedBy=multi-user.target

새로운 systemctl 서비스가 등록되었기에 deamon을 리로드하고, 서비스를 실행한다.

ubuntu@ip-172-31-13-104:~$ sudo systemctl daemon-reload
ubuntu@ip-172-31-13-104:~$ sudo systemctl start code.service

그리고 시스템이 재부팅 되더라도 서비스가 실행되도록 설정한다.

ubuntu@ip-172-31-13-104:~$ sudo systemctl enable code.service
Created symlink /etc/systemd/system/multi-user.target.wants/code.service → /lib/systemd/system/code.service.

마지막으로 서비스가 잘 실행 중인지 status 명령으로 살펴본다.

ubuntu@ip-172-31-13-104:~$ sudo systemctl status code.service
● code.service - VSCode CLI Server
     Loaded: loaded (/lib/systemd/system/code.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2023-07-02 05:23:49 UTC; 7min ago
   Main PID: 32493 (code)
      Tasks: 37 (limit: 1141)
     Memory: 115.7M
        CPU: 16.409s
     CGroup: /system.slice/code.service
             ├─32493 /usr/local/bin/code tunnel
             ├─32543 sh /home/ubuntu/.vscode/cli/servers/Stable-695af097c7bd098fbf017ce3ac85e09bbc5dda06/server/bin/>
             ├─32547 /home/ubuntu/.vscode/cli/servers/Stable-695af097c7bd098fbf017ce3ac85e09bbc5dda06/server/node /h>
             ├─32558 /home/ubuntu/.vscode/cli/servers/Stable-695af097c7bd098fbf017ce3ac85e09bbc5dda06/server/node /h>
             └─32588 /home/ubuntu/.vscode/cli/servers/Stable-695af097c7bd098fbf017ce3ac85e09bbc5dda06/server/node /h>

Jul 02 05:23:52 ip-172-31-13-104 code[32493]: [2023-07-02 05:23:52] error [tunnels::connections::relay_tunnel_host] >
Jul 02 05:23:52 ip-172-31-13-104 code[32493]: [2023-07-02 05:23:52] info [tunnels::connections::relay_tunnel_host] O>
Jul 02 05:23:52 ip-172-31-13-104 code[32493]: [2023-07-02 05:23:52] info [tunnels::connections::relay_tunnel_host] O>
Jul 02 05:23:53 ip-172-31-13-104 code[32493]: [2023-07-02 05:23:53] info [tunnels::connections::relay_tunnel_host] O>
Jul 02 05:23:53 ip-172-31-13-104 code[32493]: [2023-07-02 05:23:53] info [tunnels::connections::relay_tunnel_host] O>
Jul 02 05:23:53 ip-172-31-13-104 code[32493]: [2023-07-02 05:23:53] info [tunnels::connections::relay_tunnel_host] O>
Jul 02 05:24:04 ip-172-31-13-104 code[32493]: [2023-07-02 05:24:04] info [tunnels::connections::relay_tunnel_host] O>
Jul 02 05:24:05 ip-172-31-13-104 code[32493]: [2023-07-02 05:24:05] info [rpc.0] Checking /home/ubuntu/.vscode/cli/s>
Jul 02 05:24:05 ip-172-31-13-104 code[32493]: [2023-07-02 05:24:05] info [rpc.0] Starting server...
Jul 02 05:24:05 ip-172-31-13-104 code[32493]: [2023-07-02 05:24:05] info [rpc.0] Server started

Review

vscode CLI는 tunneling 방식으로 구성되기에 가상머신에 우분투를 구축하고 사설 아이피에서 동일한 방식으로 구성해도 https://vscode.dev/tunnel/장치명으로 접근이 가능하다. 또한 장치명이 고유한 값이기에 도메인을 할당해서 사용하는 방향으로 활용할 수 있다. 이제 언제 어디서 어떤 컴퓨터에서든 동일한 환경에서 코드를 개발할 수 있다.

AWS에 EC2 생성하기

hakawati — Fri, 30 Jun 2023 00:32:25 +0900

간단한 서버를 운영하기에 클라우드가 매우 편하다. 전세계에 다양한 클라우드 서비스가 있는데 가장 오래되고 높은 점유율을 가지고 있는 AWS를 이용한다. 클라우드 컴퓨터를 EC2라고 부르는데, 언제 어디서나 컴퓨터 디바이스 의존도가 필요없는 IDE 서버를 구축하기 위해 EC2 생성을 진행한다.

Prepare

AWS 계정 및 로그인

Setting

Choose Region

EC2를 본격적으로 생성하기 앞서 리전(Region)을 먼저 선택한다. 리전이 가지는 의미는 AWS 서비스의 국가적 위치를 의미한다. 모든 설정은 리전에 종속되기 때문에 본인이 구성한 AWS 환경이 보이지 않는다면 리전을 변경해 보는 것이 좋다. 코딩으로 AWS를 제어할 것이라면 주요 리전의 코드 네임인 ap-northeast-2를 기억해 두는 것이 좋다.

리전 선택

Create Instance

로그인을 하게 되면 처음 방문한 페이지는 다음과 같이 대표적인 서비스를 확인할 수 있다. 이 중 EC2를 이용한다.

로그인 후 메인 페이지

EC2를 선택하면 다양한 설정들이 보이는데 대표적인 EC2 생성과 그와 관련있는 다양한 부수적인 기능들에 관한 내용들이다. 가장 기초적인 EC2를 생성하기 위해 인스턴스 시작 버튼을 선택한다.

인스턴스 시작 버튼

이제 가상의 컴퓨터를 생성할 수 있다. 이름에는 생성하고자 하는 컴퓨터의 이름을 기입한다.

EC2에 생성할 컴퓨터 이름 설정

추가적인 정보를 기입하자면 추가 태그 추가를 선택해 정보를 추가로 기입할 수 있다. 컴퓨터 이름은 기본적으로 태그의 키 이름이 Name이다. 추가 태그 추가를 선택하면 숨겨진 설정 정보가 하나 더 있는데 그것은 리소스 유형 정보로 인스턴스 이외에 설정할 필요는 없다.

볼륨(Volume): 생성하는 인스턴스가 사용할 볼륨으로 쉽게 설명하면 컴퓨터의 하드디스크를 의미한다.
스팟 인스턴스(Spot Instance): 일반적으로 생성한 EC2 인스턴스보다 낮은 가격으로 이용할 수 있는 단순한 형태의 인스턴스를 의미한다. 입찰 방식이기에 AWS에서 제시한 시세보다 낮으면 인스턴스는 중단되어 안전성이 떨어져 순간 리스소가 필요한 경우 생성하는 인스턴스다.
네트워크 인터페이스(Network Interface): 말 그대로 인스턴스가 네트워크 통신에 사용할 자원을 의미한다.

추가 태그 추가 설정

다음으로 설정하는 것은 애플레케이션 및 OS 이미지다. 가상머신이어도 그 위에 운영체제나 애플리케이션이 운영이 되어야 한다. 참고로 Amazon Linux는 AWS에서 Red Hat 기반으로 제작한 AWS의 운영체제이다. 여기서 Ubuntu를 선택한다. Ubuntu를 선택하면 AMI(Amazon Machine Image)를 선택할 수 있는데 AWS에서 사전에 구축해둔 기본 운영체제 버전을 선택할 수 있다. 아키텍처는 64비트(x86)을 선택한다.

애플리케이션 및 OS 이미지 구성

다음 설정한 것은 인스턴스 유형이다. 사용하고자 하는 목적에 따라 CPU 수, 메모리 크기 등을 선택할 수 있다. 인스턴스는 운영체제와 시스템 사양에 따라 비용이 달라진다. 매월 설정된 사용량(일반적으로 750시간이며 약 31일이다.) 만큼 무료로 사용할 수 있는 프리 티어는 1 CPU, 1GB 메모리의 크기를 가진다.

인스턴스 유형 설정

생성한 인스턴스에 접근해 통제하는 것은 일반적으로 SSH를 이용한다. 이 때 사용할 키를 생성하는 것이 키 페어 설정이다.

키 페어 생성

처음 생성하는 것이기에 새 키 페어 생성을 진행한다. 키 페어 이름을 작성하고, 키 페어 유형을 선택한다. 일반적으로 표준 암호화 방식인 RSA를 선택한다. 프라이빗 키 파일 형식은 각자의 환경에 맞게 선택한다. 윈도우 CMD나 Powershell 또는 OpenSSH를 사용하는 경우 .pem키를 선택하고 PuTTY 도구를 사용할 계획이면 .ppk 파일을 선택한다. 그리고 키 페어 생성을 하면 선택한 파일 유형에 맞는 키를 다운로드할 수 있고, 인스턴스가 생성이 완료되면 이 키를 이용해 인스턴스를 제어할 수 있다.

키 페어 생성

인스턴스가 사용할 네트워크를 설정한다. AWS에서 네트워크는 VPC(Virtual Private Cloud)로 불린다. 사설 아이피, 서브넷, 공인 아이피(Public IP) 등 세부적인 설정을 할 수 있지만, 기본적인 설정만으로도 충분히 운영이 가능하여 세부적인 편집을 할 필요 없다. 만약 VPC 변경, 서브넷 변경, 퍼블릭 IP 할당 비활성화 등 세부적인 구성을 하고 싶다면 네트워크 설정 이름의 오른쪽에 편집 버튼을 선택하여 설정을 변경한다.

보안 그룹(SG, Security Group, 방화벽을 의미)을 설정한다. 이미 기존에 보안 그룹을 생성한 것이 없기에 보안 그룹 생성을 선택한다. 기초적인 설정을 제안하는데, 프라이빗 키를 생성했다고 하더라도 SSH 서비스가 인터넷에 노출되는 것은 위험할 수 있으니 위치를 선택해 자신의 아이피를 선택한다. 그리고 코드 서버를 구축하고 도메인을 할당할 계획이기에 HTTP(S) 트래픽을 허용하도록 설정한다.

네트워크(VPC) 기본 설정

코드 서버는 혼자서만 이용할 서버이기에 내 아이피만 HTTP(S)에 접근하도록 추가 설정을 진행해 안전하게 운영할 필요가 있다. 따라서 우측 상단에 편집 버튼을 누르면 세부적인 보안 그룹 설정을 추가로 진행할 수 있다. 먼저 보안 그룹 이름과 설명을 기록한다.

SG 이름과 설명 작성

다음 세부적인 보안 그룹 규칙을 볼 수 있는데, HTTP와 HTTPS의 소스 유형을 위치 무관에서 내 IP로 변경한다. 추가적인 보안 그룹 규칙이 필요하다면, 보안 그룹 규칙 추가를 선택해 규칙을 자유롭게 생성할 수 있다.

보안 그룹 규칙 변경

하단에 고급 네트워크 구성이 있는데, 이미 구성된 네트워크 인터페이스에 보조 아이피를 생성하거나 네트워크 인터페이스를 추가해 하나의 서버에 여러 아이피를 할당하는 등의 고급 네트워크 구성을 진행할 수 있다.

고급 네트워크 구성 화면

하드디스크 혹은 볼륨으로 불리는 스토리지 구성이다. 프리 티어는 30GB에 EBS 범용(SSD)를 사용할 수 있다. 따라서 크기는 30GiB로 설정하고 볼륨 유형은 gp3를 선택한다. gp2와 gp3는 범용 SSD의 세대를 의미하며 gp3가 gp2 보다 최신 유형이다. 가장 큰건 gp3가 gp2보다 20% 정도 더 저렴하다고 한다. gp3는 3,000 IOPS를 제공하는데, IOPS(Input/Output Operations Per Second) 초당 입출력을 의미하는 것으로 1초당 45.875MiB/s (3,000 * 16KiB / 1,024) 정도 속도를 가진다.

Amazon EBS 범용 볼륨 -Amazon Web Services

gp3 볼륨은 고객이 가상 데스크톱, Microsoft SQL Server 및 Oracle과 같은 중간 규모의 단일 인스턴스 데이터베이스, Kafka 및 Spark와 같은 프레임워크 기반의 지연 시간에 민감한 대화형 애플리케이션, 개

aws.amazon.com

Amazon EBS 볼륨 유형 - Amazon Elastic Compute Cloud

마그네틱은 이전 세대 볼륨 유형입니다. 이전 세대 볼륨이 제공할 수 있는 것보다 더 높은 성능 또는 성능 일관성이 필요한 경우 최신 볼륨 유형 중 하나를 사용하는 것이 좋습니다.

docs.aws.amazon.com

3스토리지 구성

고급 세부 정보는 LDAP이나 AD와 같은 디렉터리 시스템에 조인할 것인지, 계정 권한과 역할을 관리하는 IAM등 세부적인 설정은 고급 세부 정보에서 설정하는 영역이다. 별도의 세부적인 설정 없이 진행한다.

고급 세부 정보 화면

마지막으로 Summary를 확인한다. Summary는 지금까지 설정한 구성을 확인할 수 있다. 또한 프리 티어의 세부적인 정보를 볼 수 있는데 더욱 세부적인 정보를 보고자 한다면 다음 링크를 참조한다. Summary로 구성한 설정 정보 확인이 끝났다면 인스턴스 시작 버튼을 클릭한다.

무료 클라우드 컴퓨팅 서비스 - AWS 프리 티어

Q: AWS 프리 티어란 무엇입니까? AWS 프리 티어는 고객에게 서비스별로 지정된 한도 내에서 무료로 AWS 서비스를 살펴보고 사용해 볼 수 있는 기능을 제공합니다. 프리 티어는 12개월 프리 티어, 상

aws.amazon.com

인스턴스 시작

인스턴스 시작 완료

이제 인스턴스 또는 홈 화면에서 EC2를 선택하면 서버가 운영중인 것을 확인할 수 있다.

인스턴스 생성 확인

인스턴스 ID에 링크가 포함되어 있는데 해당 링크를 클릭하면 설정한 정보뿐만 아니라 AWS가 이 인스턴스에 할당한 추가 정보들을 볼 수 있다. 퍼블릭 IPv4의 아이피로 SSH에 접근할 수 있다.

인스턴스 세부 설정 정보

Review

지금까지 구성한 것이 잘 동작하는지, 인스턴스에 직접 접근하는 것으로 확인해본다.

인스턴스에 SSH 접속하기

인스턴스 상세 정보에서 작업을 선택하면 연결이란 기능을 볼 수 있다.

연결 기능 선택

상단에 SSH 클라이언트를 선택하면 SSH 접속 예시를 확인할 수 있다. 해당 내용을 복사해서 파워쉘에서 실행한다.

인스턴스에 접근하는 방법

다음과 같이 Permission 에러가 발생할 수 있다.

파워쉘 기준에서 다음과 같이 명령을 입력하여 리눅스 기준 chmod 400 권한을 할당한다. 파워쉘이 아닌 cmd에서 진행한다면 현재 사용자 정보인 ${env:UserName}을 %username%으로 변경해 사용하면 된다.

Icacls "key of haka.pem" /reset
Icacls "key of haka.pem" /grant:r ${env:UserName}:F
Icacls "key of haka.pem" /inheritance:r

이제 다시 ssh 접속하면 AWS 인스턴스에 잘 접속되는 것을 확인할 수 있다.

AWS 인스턴스 접속 성공

SSH Config 설정

좀 더 편하게 이용하려면 SSH Config를 설정하는 것이 좋다. 매번 pem키를 지정할 필요가 없기 때문이다. 먼저 사용자 홈 디렉터리에 .ssh 폴더가 있을 것이다. 없다면 새로 생성해도 무방하다. 해당 폴더에 pem 키를 옮긴다.

mv "C:\haka\key of haka.pem" C:\Users\hakawati\.ssh\

이제 해당 폴더에 config 파일을 생성하고 값을 입력한다. HostName에 AWS 인스턴스에 할당된 공인 아이피를 입력한다. 파워쉘 코드로 작성하기 번거롭다면 .ssh 디렉토리에 config 파일을 생성하고 -Value 내용을 기록하여 저장해도 무관하다.

Set-Content -Path 'C:\Users\hakawati\.ssh\config' -Value 'Host code.hakawati.co.kr'
Add-Content -Path 'C:\Users\hakawati\.ssh\config' -Value '    HostName 3.xxx.xxx.xxx'
Add-Content -Path 'C:\Users\hakawati\.ssh\config' -Value '    User ubuntu'
Add-Content -Path 'C:\Users\hakawati\.ssh\config' -Value '    IdentityFile "~/.ssh/key of haka.pem"'

이렇게 설정했다면 어느 경로에서나 자유롭게 pem 파일을 지정할 필요 없이 다음과 같이 AWS 인스턴스에 접근할 수 있다.

ssh code.hakawati.co.kr

AWS 인스턴스 접속 성공

이제 나만의 서버가 만들어 졌다. AWS의 엄청나게 많은 다양한 서비스 중 하나인 EC2 생성, 그리고 생성 과정에 다채로운 설정을 모두 살펴보지 않고 가장 기본적인 것만 사용하여 온프렘 인스턴스를 생성했다. 이제 자유롭게 서버를 구성해 볼 수 있다.

Cloudflare를 이용한 www 서브도메인 구성

hakawati — Wed, 28 Jun 2023 22:17:33 +0900

Cloudflare를 이용하여 도메인을 관리할 때 별도의 서브도메인 설정이 없는 경우 www 서브 도메인으로 트래픽을 전달하는 구성 방법을 소개한다.

Purpose

흔히 웹 사이트에 방문할 때 www.google.com이나 www.naver.com 같은 도메인을 봤을 것이다. 주로 메인 웹 사이트에 www 서브도메인을 할당하는데, 이 구성은 google.com이나 naver.com을 방문해도 www 서브도메인이 자동으로 할당된다. Cloudflare를 이용해 도메인을 관리하고 있다면, 다음과 같이 설정하여 이 구성을 이용할 수 있다.

Prepare

Cloudflare 계정
Cloudflare에서 도메인을 구매했거나, 가지고 있는 도메인을 Cloudflare로 이관한 경우

Setting

Set of Domain

처음 Cloudflare에 로그인을 하면 다음과 같이 관리할 수 있는 도메인을 확인할 수 있다.

Cloudflare 웹 사이트 구성 화면

관리 중인도메인을 클릭하면 여러 도메인 설정을 확인할 수 있는데 그중 DNS 설정에서 레코드에 방문한다. A, AAAA, CNAME, TXT 등 다양한 도메인 운영을 위한 설정을 레코드라 부른다.

Cloudflare DNS Record

레코드 설정에서 두 가지 구성을 진행한다. 티스토리 운영인 경우 유형을 CNAME 레코드로 설정하고 이름에는 www 대상에는 티스토리 대체 도메인을 관리하는 서버인 host.tistory.io를 입력한다. 개인인 호스팅 서버를 이용하고 있다면 유형을 A 레코드로 설정하고, 이름에는 www, 대상에는 공인아이피를 입력한다. Cloudflare에서 도메인 설정 시 프락시를 흔히 볼 수 있는데, 아래 그림과 같이 프락시를 설정할 경우 www.hakawati.co.kr을 방문 시 Cloudflare를 거쳐서 host.tistory.io로 전달되는 구조를 가진다. 이런 방식은 속도가 다소 느려지지만, 사이트 방문자 통계와 약간의 Cloudflare의 보안적 기능을 이용할 수 있다.

www 도메인의 CNAME과 이름 그리고 대상 설정

다음으로 구성해야 할 것은 hakawati.co.kr이다. 누군가가 www 없이 hakawati.co.kr을 도메인을 입력했을 때 레코드가 구성되어 있어야 어떤 형태로든 처리를 할 수 있기 때문이다. 이 경우 대상이 도메인이기 때문에 CNAME을 설정하고 이름은 @ (자기 자신을 의미) 대상을 www.hakawati.co.kr로 로 설정한다. 프락시 설정은 위 설명과 동일하다.

www가 없는 도메인의 CNAME과 이름 그리고 대상 설정

Set of Bulk Redirection

이제 www.hakawati.co.kr에 방문하면 티스토리 도메인이 잘 동작하나, hakawati.co.kr로 방문하면 www.hakawati.co.kr로로 전달(Redirection)을 하도록 구성해야 한다. Cloudflare에서는 이 설정을 대량 리디렉션(Bulk Redirection)에서 구성할 수 있다. 대량 리디렉션 설정은 다음 두 위치에서 동일하게 설정할 수 있다.

CloudFlare 메인 페이지에서 대량 리디렉션 설정 위치

도메인 설정에서 대량 리디렉션 설정

처음 생성은 리디렉션 이름을 설정한다. 이 이름은 20자 미만이어야 하고, 띄어쓰기는 불가능하다.

리디렉션 생성

다음은 설정인데, 수동 추가 버튼을 선택한다. 원본 URL은 리디렉션이 되어야 할 URL, 대상 URL은 리디렉션 되어 방문할 URL을 의미한다. 상태는 301, 302, 307, 308 상태 코드를 선택할 수 있다. 301 리디렉션은 영구적 이동, 302 리디렉션은 임시적 이동을 의미한다. 도메인의 기준에서 301을 선택하면 사용자가 hakawati.co.kr을 입력하면 브라우저는 www.hakawati.co.kr로 완전한 이동을 하여 주소가 변경된다. 하지만 302는 주소가 변경되지 않고 hakawati.co.kr을 유지하고 내부적으로 www.hakawati.co.kr을 랜더링 하게 된다.

301 리디렉션 선택 이유

새로운 도메인으로 영구적으로 마이그레이션 할 경우
HTTP에서 HTTPS로 전환하는 경우
여러 웹 사이트를 하나의 도메인으로 병합하는 경우
www가 없는 도메인 방문 시 www 가 존재하는 것으로 구성할 경우

302 리디렉션 선택 이유

각각의 도메인을 유지한 채 하나의 웹 호스팅 서버로 병합하는 경우
웹 사이트의 페이지, 디자인, 성능 등 테스트를 위해 분할하는 경우
방문자가 사용하는 언어에 맞게 리디렉션 하는 경우
운영 중인 사이트가 SEO에 영향을 주지 않고 다른 페이지로 전달하고자 하는 경우

즉, 초기 구성을 할 경우 301을 선택해야 하고, 이미 많은 정보를 운영 중인 웹 서비스에 적용할 경우 검색엔진 노출(SEO)이 처음부터 다시 진행될 수도 있기에 이런 경우 302를 선택하는 것이 좋다. 참고로 SEO 관점에서 리디렉션 방식을 자주 변경하는 것은 검색엔진 입장에서 검색엔진에 노출할 웹 사이트가 불안정해 보이기에 부정적인 평가를 하게 되어 좋지 않다.

307은 302와 유사하고 308은 301과 유사한 리디렉션 상태 코드이다. 다만 차이는 HTTP Method를 유지하는 점이다. 301과 302는 어떤 HTTP Method가 오더라도 GET Method로 변경해 리디렉션 하는 반면, 307과 308은 HTTP Method를 유지해 리디렉션 한다. 만약 티스토리 블로그가 아니라 워드프레스 블로그이고, 다수의 사용자가 함께 운영한다면 307이나 308을 선택하는 것이 좋다. 그렇지 않더라도 안전성을 높이기 위해 308을 선택하는 것도 좋다.

마지막 구성으로 매개변수이다. 쿼리 문자열, 하위 경로, 경로 접미사 모두 유지하는 것으로 선택한다. 하위 도메인을 포함하도록 설정하면 asdf.hakawati.co.kr 같이 설정하지 않은 모든 하위 도메인들이 모두 www.hakawati.co.kr로 전달하는 구성인데, 도메인을 하위 도메인을 구분해 활용할 계획이면 설정하지 않는 것이 중요하다.

URL 리디렉션 수동 추가

한번 더 검토를 위해 설정 정보를 보여준다. 검토 후 다음 버튼을 누른다. 그 후 리디렉션 규칙으로 계속 진행을 선택한다.

리디렉션 검토

리디렉션 규칙으로 계속 진행

다음 방금 구성한 설정으로 배포를 진행한다. 배포 이름은 자유롭게 설정할 수 있다. 저장 및 배포를 누르면 구성한 설정이 즉시 배포된다.

규칙 배포

Review

이제 http://hakawati.co.kr, http://www.hakawati.co.kr, https://hakawati.co.kr 어느 방식으로 사이트를 방문하더라도 https://www.hakawati.co.kr로 리디렉션이 발생하는 것을 확인할 수 있다. 참고로 구성의 순서를 변경하여 원본 웹 호스트를 hakawati.co.kr로 지정하고 www.hakawati.co.kr로 로 리디렉션하는 방식을 구성해도 큰 차이는 없을 수 있으나, 티스토리 기준에서는 하나의 도메인만 HTTPS 인증서를 제공하기 때문에 hakawati.co.kr을 등록하고 www.hakawati.co.kr로 로 리디렉션 구성을 하게 되면 인증서 문제가 발생한다. 따라서 운영하는 웹 서비스의 구성 상태에 따라 응용하는 것이 중요하다.

티스토리의 개인 도메인 설정

Amazon Macie (1/2) - 구축편

hakawati — Wed, 28 Jun 2023 22:17:18 +0900

소개

Amazon Macie는 Amazon S4 버킷에서 데이터를 검색할 때 사용하는 기능이다. 이를 특정 문자나 정규표현식을 사용하여 찾는다. 설명에는 기계학습을 사용하여 개인정보(PII)나 민감한 데이터를 식별할 수 있다고 소개한다.

구축

처음 Macie에 들어가면 기능 활성화를 진행할 수 있다. 첫 활성화 땐 30일 무료 평가판으로 자동 등록되어 무료로 사용할 수 있다.

Macie 활성화 시작 화면

최초 활성화를 하면 목적에 맞게 현재의 권한으로 접근할 수 있는 S3 버킷의 상태를 살펴볼 수 있다.

Macie의 대시보드

제일 먼저 설정해야 할 부분은 검색 결과이다. 민감한 데이터를 검색하고 찾아낸 결과를 새로운 S3 버킷에 저장한다. 본 포스트에서는 테스트를 위해서 오레온 데이터 센터를선택했지만, 보안 분야에서 찾아낼 민감한 데이터란 개인정보가 주류를 이루기에 개인정보보호법상 서울로 데이터센터로 변경해 진행하는 것을 추천한다.

Macie 전용 S3 버킷 설정 시작 화면

말 그대로 민감한 데이터이기에 필수로 암호화 기능을 이용해야 한다. 새로운 S3에서 직접 만들때 기본 암호화에서 AWS-KMS 기능을 활성화하고 키와 연동하여 생성하고, Macie에서 해당 버킷과 암호키를 선택하여 구성할 수 있다. 아니면 간단하게 Macie를 생성할 때 새로운 S3 버킷과 암호키 지정하여 새로운 S3 버킷을 생성할 수 있다. 이 포스트에서는 새로운 버킷과 새로운 암호화키를 생성하는 방식으로 진행한다. 다음과 같이 버킷 생성을 선택하고 버킷 이름을 지정한다.

버킷 생성으로 설정 시 화면

자동으로 KMS 암호화가 활성화 되는데, 우측 상단의 새 KMS 키 생성을 선택하여 새로운 암호키를 생성한다. 키는 대칭키로,

Macie가 사용할 키 유형 설정

키 이름을 지정하고

Macie가 사용할 키 별칭 설정

IAM 롤 설정이 없고 1인 사용자이기에 키 관리자는 선택하지 않고 굳이 개인 사용자가 마스터 키를 가질 필요도 없으니 CMK(Customer Master Key)는 선택 없이 넘긴다. (참고로 키 관리를 AWS에 맡기면 비용이 발생한다.)

Macie가 사용할 S3 버킷의 키 관리 정의

Macie가 사용할 S3 버킷의 키 사용 권한 정의

마지막으로 키 정책 검토인데, 생성한 키를 Macie가 사용할 수 있도록 정책을 편집한다. 삽입할 정책은 다음과 같으며, Json 구조에 맞게 잘 삽입한다.

{ 
    "Sid": "Allow Macie to use the key", 
    "Effect": "Allow", 
    "Principal": { "Service": "macie.amazonaws.com" }, 
    "Action": [ "kms:GenerateDataKey", "kms:Encrypt" ], 
    "Resource": "*" 
}

Storing and retaining sensitive data discovery results with Amazon Macie에서 Macie의 정책을 키에 삽입하는 방법을 참고할 수 있다. 키를 생성했다면 다시 Macie로 돌아와서 KMS 키 별칭 끝의 Refresh 아이콘을 클릭하고 새로 생성한 키를 선택한다.

Macie 저장소 설정 완료 단계

설정이 잘 되었다면 저장을 눌렀을 때 다음과 같은 화면이 보여진다.

Amazon Macie 결과 저장소 생성 완료

삽질

Macie를 이용해 S3 버킷을 즉흥적으로 생성할 때 Macie가 암호키를 사용할 수 있도록 권한을 부여하지 않은채 생성 버튼을 누른다면, S3 버킷은 생성되고 암호키는 사용하지 못한채 "권한이 없다"는 에러메시지가 출력된다.

Amazon Macie (2/2) - 활용편

hakawati — Wed, 28 Jun 2023 22:17:03 +0900

소개

활용

이제 Macie를 이용해 검색하기 위해 패턴을 생성한다. 패턴은 우측 패널에 설정에서 사용자 지정 데이터 식별자를 선택한다.

민감 정보를 찾기 위한 패턴 설정 1

민감한 데이터인 폰 번호를 검색하는 정규표현식을 간단히 작성한다. 단순 문자열도 최대 50개까지 지정할 수 있고, 예외처리도 10개 까지 가능하다.

민감 정보를 찾기 위한 패턴 설정 2

이제 검색은 검색 대상이 되는 S3 버킷을 선택한다. 버킷 선택은 우측 패널의 S3 버킷에서 선택 가능하며 여러 버킷을 지정하여 한번에 검색도 가능하다.

Macie 스캐닝 대상이 되는 S3 버킷 설정

다음과 같이 간단한 S3 버킷의 정보를 보여주고, 우측에는 Macie의 요금 정보도 간략하게 보여준다.

Macie 스캐닝 하기 앞서 선택한 S3 버킷 정보

상세한 Macie의 요금은 요금 | Amazon Macie | Amazon Web Services(AWS)에서 확인 가능하다. Macie를 활성화 한 것만으로도 버킷 갯수당 0.10 달러가 소비된다. 그 이유는 검색 속도를 높이기 위해 인덱싱하는 것 때문으로 추측된다. 다음 버튼을 누르면 작업 방식을 선택할 수 있다. 지속적으로 반복작업을 할 것인가? 반복 작업을 한다면 기존 객체를 포함할 것인가? 이번 한번만 작업할 것인가? 등 설정할 수 있다. 기업의 경우 개인정보보호법에 의거해 데이터가 암호화되어 저장되어 있더라고 Pulic 버킷에 대해서는 지속적으로 Macie를 이용해 스캐닝하고, 최초로 진행할 땐 기존 객체를 포함을, 그렇지 않은 경우 기존 객체를 미포함으로 선택하여 비용을 줄일 수 있어 보인다. 반면 S3 버킷에서 탐지한 민감한 데이터를 조치를 하고 다시 스캔하여 결과를 확인할 수도 있다.

Macie를 이용한 민감한 정보 스캐닝 스케줄링 설정

다음으로 넘어가면 어떤 것을 검색할 것인지 미리 생성한 패턴을 선택한다.

Macie를 이용한 민감한 정보 스캐닝 탐지 패턴 설정

결과를 식별할 수 있게 Macie 작업 이름을 지정한다.

Macie를 이용한 민감한 정보 스캐닝 이름 설정

마지막을 설정한 작업을 검토하고 문제 없으면 제출을 클릭하여 스캐닝을 진행한다.

Macie를 이용한 민감한 정보 스캐닝 작업 최종 검토

스캐닝 결과는 우측 패널의 결과에서 확인할 수 있다. 결과는 모든 탐지 결과를 보여주며, 버킷별, 유형별, 작업별로 구분하여 볼 수 있다.

Macie를 이용한 민감한 정보 스캐닝 결과

각 결과를 선택하면 상세한 정보를 볼 수 있다. 중요한 것은 무엇이 탐지되었는가를 Macie에서 확인할 수 없다. 따라서 상세 결과의 개요에 리소스 부분의 링크를 선택하여 직접 S3 버킷에 방문하고, 탐지된 파일을 다운로드하여 분석할 수 있다.

Macie를 이용한 민감한 정보 스캐닝 상세 결과

간단하게 Macie를 구성하고 스캐닝도 해봤다. S3 버킷별로 암호화가 되어 있는 경우 처리하는 방법도 살펴볼 필요가 있고, 기업마다 개인정보의 유형이 다르기 때문에 패턴 생성에도 심혈을 기울여야 할 것 같다.

참고

What is Amazon Macie? - Amazon Macie

What is Amazon Macie? Amazon Macie is a fully managed data security and data privacy service that uses machine learning and pattern matching to discover, monitor, and help you protect your sensitive data in Amazon Simple Storage Service (Amazon S3). Macie

docs.aws.amazon.com

Code Server - 구축편

hakawati — Wed, 28 Jun 2023 22:16:40 +0900

페이지 목차

Code Server - 구축편

컨텐츠 목차

소개
구축
- code-server 구축 및 설정
  - code-server 구축
  - code-server 운영 옵션
  - code-server 시스템 서비스 설정
- NginX 구축 및 설정
  - NginX 구축
  - NginX의 패스워드 인증 구성
  - NginX와 Certbot을 이용한 https 통신 설정
참고

소개

대 클라우드 시대가 시작되면서 IDE를 로컬에 설치할 필요 없이 서버에 IDE를 구축하고 언제 어디서든 브라우저로 코딩을 할 수 있는 시대가 왔다. 이러한 환경은 개발자가 자신이 개발한 코드를 Github에 Push하고 다른 개발자가 Pull하여 받은 다음 개발하고, 충돌 문제를 해결하는 등의 환경을 실시간 동시 개발을 진행하도록 도와주어 더욱 편리한 개발을 할 수 있게 해준다. 또한 로컬에 설치된 라이브러리나 쿠버네틱스와 같은 환경도 일원화할 수 있다는 장점이 있다. 대표적인 클라우드 IDE는 구글의 Cloud Code, Amazon의 Cloud9과 구름의 goormIDE가 있다.

여기서 소개하려는 Cloud IDE는 Visual Studio Code를 서버 버전으로 제작된 code-server다. Visual Studio Code가 익숙하다면 code-server를 사용하는 것이 편리하다. 구글의 Cloud Code에서 Visual Studio Code를 사용할 수 있으나, 클라우드 IDE는 테스트하는 여러 환경에 대한 비용이 발생한다. 따라서, Private으로 운영하기 위해 자체 서버에 구축을 진행했다. code-server는 오픈소스고 공개되어 있다. 아주 감사하게도 라이선스는 MIT 라이선스를 채택했다. 상용/비사용 여부를 떠나 어떠한 조건 없이 무료로 사용할 수 있는 라이선스다.

구축

code-server 구축 및 설정

code-server 구축

구축은 우분투 서버 18.04에서 진행되었다. 초기 운영체제 설치 시 운영체제 업데이트를 진행했고, 설치가 끝나면 openssh-server를 설치했다. 설치는 단순하게 다음 명령으로 진행할 수 있다. 포스팅하는 과정에 설치되는 버전은 3.5.0이다.

curl -fsSL https://code-server.dev/install.sh | sh
Ubuntu 18.04.5 LTS
Installing v3.5.0 deb package from GitHub releases.

+ mkdir -p ~/.cache/code-server
+ curl -#fL -o ~/.cache/code-server/code-server_3.5.0_amd64.deb.incomplete -C - https://github.com/cdr/code-server/releases/download/v3.5.0/code-server_3.5.0_amd64.deb
######################################################################## 100.0%######################################################################### 100.0%
+ mv ~/.cache/code-server/code-server_3.5.0_amd64.deb.incomplete ~/.cache/code-server/code-server_3.5.0_amd64.deb
+ sudo dpkg -i ~/.cache/code-server/code-server_3.5.0_amd64.deb
Selecting previously unselected package code-server.
(Reading database ... 67091 files and directories currently installed.)
Preparing to unpack .../code-server_3.5.0_amd64.deb ...
Unpacking code-server (3.5.0) ...
Setting up code-server (3.5.0) ...

To have systemd start code-server now and restart on boot:
  sudo systemctl enable --now code-server@$USER
Or, if you don't want/need a background service you can run:
  code-server

설치가 끝나면 code-server 명령으로 서버를 실행할 수 있다.

code-server
[2020-10-02T13:28:04.566Z] info  Wrote default config file to ~/.config/code-server/config.yaml
[2020-10-02T13:28:04.568Z] info  Using config file ~/.config/code-server/config.yaml
[2020-10-02T13:28:04.827Z] info  Using user-data-dir ~/.local/share/code-server
[2020-10-02T13:28:04.831Z] info  code-server 3.5.0 de41646fc402b968ca6d555fdf2da7de9554d28a
[2020-10-02T13:28:04.834Z] info  HTTP server listening on http://127.0.0.1:8080
[2020-10-02T13:28:04.834Z] info      - Using password from ~/.config/code-server/config.yaml
[2020-10-02T13:28:04.835Z] info      - To disable use `--auth none`
[2020-10-02T13:28:04.835Z] info    - Not serving HTTPS

code-server 운영 옵션

code-server는 환경 변수에 값을 설정하거나, 서버 동작시 옵션을 주거나, 설정 파일을 지정하여 다양한 옵션을 활용하여 서비스를 운영할 수 있다. code-server.dev/install.sh로 설치한 경우 설치한 사용자 디렉터리에서 .config/code-server/config.yaml 파일이 기본 설정 파일이 된다. 이 설정 파일에는 네 가지 설정이 구성된다.

bind-addr은 서버의 아이피와 포트 정보를 설정하며, auth는 패스워드 설정 유무(password 또는 none을 지정)를 결정한다. 패스워드 유형은 단순한 형태로 config.yaml을 수정하여 OTP를 사용하거나 LDAP, AD에 Join할 수 없다. auth를 password로 설정한 경우 password 키에 지정한 값으로 code-server에 로그인할 수 있다. 마지막으로 cert는 https 통신에 사용할 인증서를 의미한다. true로 설정하여 사용한 경우 로컬 인증서를 자동 생성해서 사용하는데 안전하진 않다. 사설 인증서를 사용할 경우 cert 대신 cert-key를 사용하여 인증서 경로를 지정할 수 있다.

vim .config/code-server/config.yaml

bind-addr: 127.0.0.1:8080
auth: password
password: 1bc76233f828b459af0a4a6f
cert: false

개인적으로 이런 방식의 서버 구성을 지원하는 것은 단편적인 사용에 용이할 수 있으나 확장성과 서버 운영 안전성에 좋진 않은 것 같다. 따라서 NginX를 구성하여 인증과 https 통신을 구성하는 것을 추천한다. 따라서 다음과 같이 설정을 변경한다.

vim .config/code-server/config.yaml

bind-addr: 127.0.0.1:8080
auth: none

code-server가 사용할 수 있는 옵션과 환경 변수 이름 등은 help 명령을 통해 확인할 수 있다.

code-server --help
[2020-10-02T15:44:33.999Z] info  Using config file ~/.config/code-server/config.yaml
code-server 3.5.0 de41646fc402b968ca6d555fdf2da7de9554d28a

Usage: code-server [options] [path]

Options
      --auth                The type of authentication to use. [password, none]
      --password            The password for password authentication (can only be passed in via $PASSWORD or the config file).
      --cert                Path to certificate. Generated if no path is provided.
      --cert-key            Path to certificate key when using non-generated cert.
      --disable-telemetry   Disable telemetry.
   -h --help                Show this output.
      --open                Open in browser on startup. Does not work remotely.
      --bind-addr           Address to bind to in host:port. You can also use $PORT to override the port.
      --config              Path to yaml config file. Every flag maps directly to a key in the config file.
      --socket              Path to a socket (bind-addr will be ignored).
   -v --version             Display version information.
      --user-data-dir       Path to the user data directory.
      --extensions-dir      Path to the extensions directory.
      --list-extensions     List installed VS Code extensions.
      --force               Avoid prompts when installing VS Code extensions.
      --install-extension   Install or update a VS Code extension by id or vsix. The identifier of an extension is `${publisher}.${name}`. To install a specific version provide `@${version}`. For example: 'vscode.csharp@1.2.3'.
      --enable-proposed-api Enable proposed API features for extensions. Can receive one or more extension IDs to enable individually.
      --uninstall-extension Uninstall a VS Code extension by id.
      --show-versions       Show VS Code extension versions.
      --proxy-domain        Domain used for proxying ports.
   -n --new-window          Force to open a new window. (use with open-in)
   -r --reuse-window        Force to open a file or folder in an already opened window. (use with open-in)
 -vvv --verbose             Enable verbose logging.

code-server 시스템 서비스 설정

code-server가 백그라운드에서 동작, 시스템이 부팅 시 자동으로 실행 등 운영에 있어 보조적으로 도움이 되도록 운영하려면 시스템이 관리하도록 설정하는 것이 좋다.

systemctl --user enable --now code-server
Created symlink /home/hakawati/.config/systemd/user/default.target.wants/code-server.service → /usr/lib/systemd/user/code-server.service.

이렇게 설정하면 바로 code-server는 systemctl의 관리 대상에 포함된다. 잘 동작하는지는 다음과 같이 확인할 수 있다.

systemctl --user status code-server
● code-server.service - code-server
   Loaded: loaded (/usr/lib/systemd/user/code-server.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2020-10-02 15:54:22 UTC; 4min 40s ago
 Main PID: 7389 (node)
   CGroup: /user.slice/user-1000.slice/user@1000.service/code-server.service
           ├─7389 /usr/lib/code-server/lib/node /usr/lib/code-server
           ├─7407 /usr/lib/code-server/lib/node /usr/lib/code-server
           ├─7420 /usr/lib/code-server/lib/node /usr/lib/code-server/lib/vscode/out/vs/server/fork
           └─7434 /usr/lib/code-server/lib/node /usr/lib/code-server/lib/vscode/out/bootstrap-fork --type=extensionHost

Oct 02 15:54:22 codeserver systemd[1381]: Started code-server.
Oct 02 15:54:23 codeserver code-server[7389]: [2020-10-02T15:54:23.018Z] info  Using config file ~/.config/code-server/config.yaml
Oct 02 15:54:23 codeserver code-server[7389]: [2020-10-02T15:54:23.155Z] info  Using user-data-dir ~/.local/share/code-server
Oct 02 15:54:23 codeserver code-server[7389]: [2020-10-02T15:54:23.158Z] info  code-server 3.5.0 de41646fc402b968ca6d555fdf2da7de9554d28a
Oct 02 15:54:23 codeserver code-server[7389]: [2020-10-02T15:54:23.160Z] info  HTTP server listening on http://127.0.0.1:8080
Oct 02 15:54:23 codeserver code-server[7389]: [2020-10-02T15:54:23.160Z] info    - No authentication
Oct 02 15:54:23 codeserver code-server[7389]: [2020-10-02T15:54:23.160Z] info    - Not serving HTTPS

이제 시스템에 문제가 생겨 재부팅이 되더라도 자동으로 code-server가 운영될 것이다. 로그는 남겨지지 않도록 설정해도된다. NginX에서 시스템 로그로 생성되기 때문이다.

NginX 구축 및 설정

NginX 구축

NginX는 Apache처럼 웹 서버 애플리케이션이다. 여기서는 code.hakawati.co.kr(필자가 code-server에 할당할 도메인)로 접속하면 NginX가 수신한 후 code-server의 127.0.0.1:8080으로 리디렉션하여 IDE를 브라우저로 사용할 수 있다. 이렇게 사용하려면 Proxy Redirection 역할을 하도록 구성한다. 설치는 apt로 간단하게 진행한다.

sudo apt install nginx

Proxy Redirection을 위해 NginX 설정 파일을 생성할 필요가 있는데, https 통신을 설정하기 앞서 http 통신으로 접속하도록 설정 파일을 생성한다.

sudo vim /etc/nginx/sites-available/code-server.conf

upstream code-server {
        server 127.0.0.1:8080;
}

server {
        listen 80 default_server;
        listen [::]:80 default_server;
        server_name codeserver;

        location / {
                proxy_pass http://code-server;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection upgrade;
                proxy_set_header Host $host;
                proxy_set_header Accept-Encoding gzip;
        }
}

Apache 디폴트 페이지 처럼 NginX도 디폴트 페이지가 있다. 디폴트 페이지를 비활성화하고, code-server는 활성화하는 작업을 진행한다.

sudo rm /etc/nginx/sites-enabled/default
sudo ln -s /etc/nginx/sites-available/code-server.conf /etc/nginx/sites-enabled/code-server.conf

설정 파일에 오타가 없는지, 동작하는데 문제가 없는지 테스트를 진행하고, 문제가 없다면 NginX 서비스를 재시작한다. code-server에 http로 접근되는 것을 확인할 수 있다.

sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
sudo systemctl reload nginx.service

code-server 동작 확인

NginX의 패스워드 인증 구성

웹 서비스에 로그인 없이 바로 접근되는 것은 불안한 일이다. code-server는 터미널을 제공하기에 만약 공인 아이피였다면 공격자가 시스템에 침투한 것과 동일한 수준의 서비스를 제공한다. NginX의 간단한 사용자 인증 기능을 넣어 안전성을 조금이라도 높일 수 있다. NginX의 패스워드 설정은 htpasswd를 이용하여 구성할 수 있다. htpasswd를 사용하려면 apache2의 유틸리티를 설치하여 htpasswd 명령을 이용하거나 Openssl의 passwd 명령을 이용하여 구성할 수 있다.

sudo apt install apache2-utils

code-server의 패스워드 인증은 사용자 구분을 할 수 없는데, htpasswd는 사용자별 패스워드를 구성할 수 있다. 최초 사용자와 패스워드 파일을 생성할 때 -c 옵션을 사용하며, 추가 사용자와 패스워드 파일을 생성할 땐 -c 옵션을 빼고 사용한다.

sudo htpasswd -c /etc/nginx/.htpasswd hakawati
New password:
Re-type new password:
Adding password for user hakawati

NginX의 설정 파일인 code-server.conf 파일의 location / 에 auth_basic와 auth_basic_user_file를 설정한다.

sudo vim /etc/nginx/sites-available/code-server.conf

upstream code-server {
        server 127.0.0.1:8080;
}

server {
        listen 80 default_server;
        listen [::]:80 default_server;
        server_name codeserver;

        location / {
                proxy_pass http://code-server;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection upgrade;
                proxy_set_header Host $host;
                proxy_set_header Accept-Encoding gzip;
                auth_basic "Authentication Page";
                auth_basic_user_file /etc/nginx/.htpasswd;
        }
}

sudo nginx -t 명령으로 설정 파일에 오류가 있는지 확인하고, 문제 없다면 sudo systemctl reload nginx.server로 NginX를 재시작한다. 그리고 다시 code-server에 방문하면 다음과 같이 계정과 패스워드를 입력하는 창을 볼 수 있다.

로그인 설정 테스트

NginX와 Certbot을 이용한 https 통신 설정

암호화 통신은 네트워크 통신에 있어서 중요한 보안 요소 중 하나다. NginX를 이용하고 있다면 Certbot으로 무료 인증서를 쉽게 설정할 수 있다. Certbot을 설치한다.

sudo apt install certbot python3-certbot-nginx

certbot은 http-01 방식과 dns-01 방식으로 https 인증서를 발행하기 앞서 정당한 인증서 발행인지 확인하는 과정을 진행한다. http-01 방식은 공인 아이피가 필요하고, dns-01 방식은 도메인이 필요하다. 목적에 따라 사용하는 방식이 다르기에 도메인은 고정으로 사용하고 서버 아이피를 자유롭게 변경하고 싶다면, 또는 서브 도메인이 어떤 것이 오든 인증서가 받아들이게 구성하려면 dns-01 방식을 사용해야한다. 도메인 소유주가 도메인의 txt 레코드에 인증 값을 설정하여 인증서를 발행할 수 있다.

Are you OK with your IP being logged? 질문에 무조건 y를 해야 진행할 수 있다. 생성된 8TFRb_ecZvl8wxj8uY81Xo41rRdAGxDaJhEybeOqM3g 값은 _acme-challenge.code.hakawati.co.kr 키로 매칭되도록 도메인의 TXT 레코드에 등록한다. 그리고 Enter를 누르면 TXT 키의 값을 확인하고 검증이 통과되면 /etc/letsencrypt/live/code.hakawati.co.kr/ 디렉터리에 공개키인 fullchain.pem과 비밀키인 privkey.pem이 생성된 것을 확인할 수 있다.

sudo certbot -d code.hakawati.co.kr --manual --preferred-challenges dns certonly
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for code.hakawati.co.kr

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NOTE: The IP of this machine will be publicly logged as having requested this
certificate. If you're running certbot in manual mode on a machine that is not
your server, please ensure you're okay with that.

Are you OK with your IP being logged?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: y

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please deploy a DNS TXT record under the name
_acme-challenge.code.hakawati.co.kr with the following value:

8TFRb_ecZvl8wxj8uY81Xo41rRdAGxDaJhEybeOqM3g

Before continuing, verify the record is deployed.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/code.hakawati.co.kr/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/code.hakawati.co.kr/privkey.pem
   Your cert will expire on 2020-12-31. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

이제 NginX의 설정 파일인 code-server.conf 파일을 수정하여 https 통신을 하도록 구성한다. 이 과정은 certbot이 자동으로 구성하도록 도와주기 때문에 다음과 같이 진행한다.

첫번째 질문은 인증서를 다시 설치하겠는가? 아니면 인증서를 다시 받을 것인가? 를 질문하는 것이다. 다시 설치하는 1을 선택한다. 두번째 질문은 http로 접근하면 https로 리디렉션하겠는가의 질문이다. 리디렉션하도록 2을 선택한다.

sudo certbot --nginx -d code.hakawati.co.kr
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Cert not yet due for renewal

You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /etc/letsencrypt/renewal/code.hakawati.co.kr.conf)

What would you like to do?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Attempt to reinstall this existing certificate
2: Renew & replace the cert (limit ~5 per 7 days)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 1
Keeping the existing certificate
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/code-server.conf

Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: No redirect - Make no further changes to the webserver configuration.
2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you're confident your site works on HTTPS. You can undo this
change by editing your web server's configuration.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/code-server.conf

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled https://code.hakawati.co.kr

You should test your configuration at:
https://www.ssllabs.com/ssltest/analyze.html?d=code.hakawati.co.kr
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/code.hakawati.co.kr/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/code.hakawati.co.kr/privkey.pem
   Your cert will expire on 2020-12-31. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot again
   with the "certonly" option. To non-interactively renew *all* of
   your certificates, run "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

인증서가 잘 생성되었는지는 다음과 같이 확인할 수 있다.

sudo certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Found the following certs:
  Certificate Name: code.hakawati.co.kr
    Domains: code.hakawati.co.kr
    Expiry Date: 2020-12-31 14:23:20+00:00 (VALID: 89 days)
    Certificate Path: /etc/letsencrypt/live/code.hakawati.co.kr/fullchain.pem
    Private Key Path: /etc/letsencrypt/live/code.hakawati.co.kr/privkey.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

설정 로그처럼 code-server.conf 파일을 자동으로 인식하여 https 통신을 하도록 내용이 구성된다. 기존에 우리가 구성했던 부분을 삭제하여 설정을 정리한다.

삭제된 설정

server {
        listen 80 default_server;
        listen [::]:80 default_server;
        server_name codeserver;

        location / {
                proxy_pass http://code-server;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection upgrade;
                proxy_set_header Host $host;
                proxy_set_header Accept-Encoding gzip;
                auth_basic "Authentication Page";
                auth_basic_user_file /etc/nginx/.htpasswd;
        }
}

최종 설정

upstream code-server {
        server 127.0.0.1:8080;
}

server {
    server_name code.hakawati.co.kr; # managed by Certbot

        location / {
                proxy_pass http://code-server;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection upgrade;
                proxy_set_header Host $host;
                proxy_set_header Accept-Encoding gzip;
                auth_basic "Authentication Page";
                auth_basic_user_file /etc/nginx/.htpasswd;
        }

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/code.hakawati.co.kr/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/code.hakawati.co.kr/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

server {
    if ($host = code.hakawati.co.kr) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

        listen 80 ;
        listen [::]:80 ;
    server_name code.hakawati.co.kr;
    return 404; # managed by Certbot
}

이제 https로 접속하면 code-server가 잘 동작하는 것을 확인할 수 있다.

certbot을 통해 설정한 무료 인증서는 90일 갱신 주기를 가지며, certbot의 유료 인증서의 갱신 주기는 1년이다. 공인 아이피로 인증하는 http-01이 아닌 dns-01 방식으로 구성했기에 자동 갱신이 되지 않는다. 수동으로 갱신하려면 다음 명령 후 2번을 선택하면 수동 갱신(특히 이 명령으로 갱신할 경우 강제 갱신된다.)을 할 수 있다.

sudo certbot -d code.hakawati.co.kr --manual --preferred-challenges dns certonly
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Cert not yet due for renewal

You have an existing certificate that has exactly the same domains or certificate name you requested and isn't close to expiry.
(ref: /etc/letsencrypt/renewal/code.hakawati.co.kr.conf)

What would you like to do?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: Keep the existing certificate for now
2: Renew & replace the cert (limit ~5 per 7 days)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
Renewing an existing certificate
Performing the following challenges:
dns-01 challenge for code.hakawati.co.kr

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NOTE: The IP of this machine will be publicly logged as having requested this
certificate. If you're running certbot in manual mode on a machine that is not
your server, please ensure you're okay with that.

Are you OK with your IP being logged?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o: Y

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please deploy a DNS TXT record under the name
_acme-challenge.code.hakawati.co.kr with the following value:

8TFRb_ecZvl8wxj8uY81Xo41rRdAGxDaJhEybeOqM3g

Before continuing, verify the record is deployed.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/code.hakawati.co.kr/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/code.hakawati.co.kr/privkey.pem
   Your cert will expire on 2020-12-31. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

인터넷 검색을 열심히 해본 결과 certbot의 숨겨진 옵션과 리눅스의 명령을 조합해 자동화 할 수 있다. 아래 명령을 쉘 스크립트 파일로 만들고 crontab을 이용하여 3달마다 갱신하도록 설정하면 된다. 당연히 crontab에 의해 실행되는 명령의 주체는 root 여야 한다. 참고로 crontab은 sudo crontab -e를 이용하면 기본으로 root 권한으로 동작하게 설정되며, /etc/crontab 파일을 수정할 경우 root 사용자로 실행한다는 것을 명시해야 한다.

echo "\n" | sudo certbot --text --agree-tos -d code.hakawati.co.kr --manual --preferred-challenges dns --expand --renew-by-default --manual-public-ip-logging-ok certonly --post-hook "systemctl start nginx.service"

인증서 기간까지 고려해 스크립트를 만든다면 다음과 같다.

#!⁄bin⁄bash
VALID=($(certbot certificates | grep VALID))
VALID_DATE=$(expr ${VALID[5]})
if [ $VALID_DATE -lt 30 ]; then 
	echo "\n" | certbot --text --agree-tos -d code.hakawati.co.kr --manual --preferred-challenges dns --expand --renew-by-default --manual-public-ip-logging-ok certonly --post-hook "systemctl start nginx.service"
fi

참고

How to Install Visual Studio Code - Server IDE on Ubuntu 20.04 LTS

Code-server is a Visual Studio Code (VS) that can be run remotely on the server and which is accessible through a web browser. It allows you to create...

www.howtoforge.com

How To Set Up Password Authentication with Nginx on Ubuntu 14.04 | DigitalOcean

When setting up a web server, there are often sections of the site that you wish to restrict access to. Web applications often provide their own authentication and authorization methods, but the web server itself can be used to restrict access if thes

www.digitalocean.com

AWS EC2에 code-server 설치하고 커스텀 도메인 ssl 배포까지

code-server는 웹에서 VS-Code를 쓸 수 있도록 해주는 서비스다. 전역 후 아이패드로 코딩할 생각에 행복회로를 돌리던 나는 미리 구현해놓기로 했다...

velog.io

Renew domains using certbot and using DNS challenge

I created several SSL certificates for several domains using the standalone method. I am only interested in the certificates, without server integration. They are now for renewal. So, I ran: cert...

serverfault.com

User Guide — Certbot 1.8.0.dev0 documentation

To view a list of the certificates Certbot knows about, run the certificates subcommand: Certificate Name shows the name of the certificate. Pass this name using the --cert-name flag to specify a particular certificate for the run, certonly, certificates,

certbot.eff.org

How to setup Code Server on Ubuntu 20.04 LTS

Code-server is a cloud development environment based on the popular code editor Visual Studio Code. Visual Studio Code is a powerful code editor developed by Microsoft capable of running on multiple platforms. It supports many languages built-in and a lot

bitlaunch.io

About ME

hakawati — Sat, 29 Aug 2020 20:06:28 +0900

hakawati(Jason H. Choi), 1987

학력

2005.02, 대구경신고등학교 졸업
2014.02, 대구가톨릭대학교 컴퓨터공학과 졸업
2018.03, 성균관대학원 일반대학원 과학수사학과 입학 - 디지털포렌식 전공
2020.02, 성균관대학원 일반대학원 과학수사학과 졸업

경력

2012.05, (주) 한국정보보호교육센터 40기 수료
2012.06, (주) TriCubeLab 입사
2014.05, (주) TriCubeLab 퇴사
2014.06, (주) 한국정보보호교육센터 입사
2019.05, (주) 한국정보보호교육센터 퇴사
2019.07, 쿠팡 입사

경력 활동

2012.03, Syslog 서버 구축 및 운용법
2012.03, Iptables 기본 사용법
2012.04, UPX 패킹 분석 및 우회
2012.04, Yada Protector 분석 및 우회
2012.05, Metasploit 사용법
2012.05, Origami를 이용한 PDF 자바스크립트 삽입
2012.06, Anti-Debugging 종류와 분석 및 우회
2012.06, Cuckoo Sandbox v0.3 시스템 구축
2012.08, CVE-2012-1889 분석
2012.11, Yara v1.6 매뉴얼 번역
2012.11, CVE-2012-4969 분석
2012.12, Phoneyc 연구 및 문서 작성
2012.12, Thug 연구 및 문서 작성
2013.01, GeoIP 활용 방안 연구
2013.01, Pygoogle 활용 방안 연구
2013.01, iScanner 활용 방안 연구
2013.03, Watering Hole Attack 연구
2013.03, Javocalypse 연구
2013.03, TDS 연구
2013.03, 3.20 대란 분석 및 보고서 작성
2013.04, JSUnpack 활용 방안 연구
2013.04, HoneySpider Network 연구
2013.04, Automater.py
2013.05, 바이러스토탈, IP, 국가, Registrar 정보 수집 스크립트 제작
2013.06, Dehydrating a String 난독화 연구
2013.06, MSB ASCII 난독화 연구
2013.07, 자바스크립트 난독화 정리
2013.08, Krakatau 활용 방안 연구
2013.08, Malcome 0.3 활용 방안 연구
2013.09, 온라인 지하산업 연구
2013.09, Vulnerability와 CVE 연구
2013.10, jjencode 난독화 연구
2013.10, 자바스크립트 Base64 난독화 연구
2013.10, HoneyProxy 기술 연구
2013.10, DNS 스푸핑 연구
2014.01, 공다팩 상세 분석
2014.02, Cuckoo Sandbox v1.0 시스템 구축
2014.02, Google SafeBrowsing을 활용한 URL 점검 코드 개발
2014.02, CVE-2013-2094 분석
2014.04, CVE-2014-0160 분석
2014.05, malcontrol 활용 방안 연구

2012.06~ 분석 및 홍보 영상 제작 12건
2012.12~ 경유지, 유포지 분석 약 300건
2013.01~ YARA 패턴 제작 104건
2013.05~ 리눅스 스크립트 제작 8건
2013.06~ 신규 아이디어 5건
2013.10~ 취약점 정보 수집 및 정리 18건

2014.08, 웹 진단 컨설팅 (1)
2014.08, 웹 진단 컨설팅 (2)
2014.11, 웹 진단 컨설팅 (3)
2015.01, Gh0st 취약점 분석 및 보고서 작성
2015.01, CapTipper v0.01 연구
2015.03, 악성 DDNS 연구
2015.04, Crypt0L0cker 분석 보고서
2015.04, Malware Information Sharing Platform & Threat Sharing 연구
2015.05, 드라이브-바이 다운로드 용어 정리
2015.05, Simple Phishing Test
2015.08, 해킹 팀(Hacking Team) 글로벌 사회 이슈 분석
2015.09, 웹 진단 컨설팅 (4)
2015.12, hidden-tear 오픈소스 랜섬웨어 구축 및 활용 연구
2016.01, Cuckoo Sandbox 2.0 RC1
2016.02, Mobile Security Framework 0.88
2016.02, CVE-Search
2016.05, Phineas Fisher's Gamma Industry Hacking Report 번역
2016.05, Phineas Fisher's Hacking Team Hacking Report 번역
2016.06, ISMS 인증을 위한 웹 진단 컨설팅 (5)
2016.07, nightHawk
2016.08, CVE-2016-0189 분석 및 활용 방안
2016,09, Codex Gigas v1.3
2016.09, 웹 진단 컨설팅 (6)
2016.09, 이메일 피싱 서버 구축
2016,09, CVE-2016-6662 분석
2016,11, 미라이(Mirai) 봇넷 소스코드 분석
2016.11, ISMS 인증을 위한 웹 사이트 진단 컨설팅 (7)
2017.06, 스팸메일 대응 모의훈련 시스템 구축 및 진단 (1)
2017.08, 스팸메일 대응 모의훈련 시스템 구축 및 진단 (2)
2017.08, 스팸메일 대응 모의훈련 시스템 구축 및 진단 (3)
2017.09, 정보보안 교육 컨텐츠 관리 체계 구성
2017.10, 컴퓨터 시스템 교재 개발
2017.12, 스팸메일 대응 모의훈련 시스템 구축 및 진단 (4)
2018.04, 시나리오 기반 모의해킹 실습 환경 구축
2018.05, 복구 솔루션을 활용한 교육장 실습 PC 운영 방안 마련
2018.06, 스팸메일 대응 모의훈련 시스템 구축 및 진단 (5)
2018.07, 케이쉴드 주니어 제안 작업 참여
2018.08, 스팸메일 대응 모의훈련 시스템 구축 및 진단 (6)
2018.08, 교육 컨텐츠 관리 체계화 방법론 구축
2018.08, NCS를 적용한 커리큘럼 제작 (분석 파트)
2018.09, PacketFense를 이용한 NAC 시스템 구축 및 테스트
2018.09, 세미나 기획 및 운영 방안 마련
2018.10, 케이쉴드 주니어 교재 제작
2019.02, 이산수학과 암호학 교재 개발
2019.07, 이메일 시큐리티
2020.04, Threat Hunting, Compromised Assessment

커뮤니티 활동

2012.06, BoanProject 악성코드 프로젝트 활동
2012.08, 보안프로젝트 악성코드 활동
2012.10, 보안프로젝트 취약점 분석 활동
2013.02, 보안프로젝트 팀장 활동
2014.05, KISEC 스터디 그룹 참여
2014.05, KISEC 페이스북 페이지 운영
2015.05, KISEC 스터디 그룹 종료
2015.05, Rnfwoa 스터디 참여
2016.08, FITALK 활동 참여
2017.03, Incognito 멘토단 참여
2017.03, S2M 악성코드 및 정보보안 정보 공유 비공개 모임 참여
2018.07, 포렌식 인사이트 학생부(FING) 모임 운영 및 멘토링
2018.10, 케이쉴드 주니어 멘토링 활동

대외 활동

2014.03, 제2회 Let's Security Festival(with APNG, SUA) 발표 - 드라이브-바이 다운로드
2014.05, 차세대 전문가 포럼 - 드라이브-바이 다운로드
2014.06, 차세대 전문가 포럼 - 중국 온라인 지하경제 동향
2014.08, 2014 탐라 SUM 페스티발 - '사물인터넷과 보안'
2014.11, 2014 코드엔진 11 - 자바스크립트 난독화 너네 뭐니? [자료]
2015.07, SUA 정보보안 컨퍼런스 - 워터링홀 공격 구현 발표
2015.12, 2015 코드엔진 클로즈세미나 03
2016.02, 제 13회 해킹캠프 - 있는거라도 잘 쓰자
2016.09, 2016 코드엔진 13 - 시나브로 무쓸모 마그네틱 스트라이프
2016.10, 2016 개인정보 유출사고 대응훈련 2기 - 공격자 관점에서 바라본 APT 공격
2016.12, 2016 6회 신한시큐어 정보보안토크콘서트
2017.03, 2017 제1회 한국정보보호학회 악성코드와 인텔리전스 - 악성코드 유포
2017.03, 2017 1/4 분기 한국인터넷진흥원 침해사고 공유 세미나 - 취약성 거래와 경제
2017.07, FIOS - Advanced Drive-by Download
2017.07, 2017 2/4 분기 한국인터넷진흥원 침해사고공유 세미나 - 악성코드 자동화 분석을 통한 인텔리전스
2018.05, 성균관대 과학수사학과 커뮤니티 제1회 정기모임 - Automated Malware Analysis and Cyber Security Intelligence

자문 활동

2014.11, 사이버침해대응지원센터, 자문위원단
2017.04, 한국인터넷진흥원, 사이버 시큐리티 인텔리전스 구축 자문위원단
2017.05, 인코그니토 멘토 참여
2018.07, 한국인터넷진흥원, CTI R&D 과제 자문위원단 자문
2018.12, 한국인터넷진흥원, 오픈소스 인텔리전스 시스템 구축 자문

집필 활동

2014.05, 칼리 리눅스와 백트랙을 활용한 모의 해킹, 에이콘, 공저
2015.09, 파이썬 오픈소스 도구를 활용한 악성코드 분석, 에이콘, 공저
2016.08, DBD 공격과 자바스크립트 난독화로 배우는 해킹의 기술, 한빛미디어, 최우석 저
2018.08, CUCKOO SANDBOX 쿡쿠 샌드박스 구축과 확장 + 운영 팁, 에이콘, 최우석 저
2018.12, 디지털포렌식 이론/기술, 미디어랩, 공저

강의 활동

2014.07, [특강] 국가정보보안교육원 - 악성코드 유포 방법론
2014.08, [특강] 국가정보보안교육원 - 정보통신기반시설과 악성코드
2014.09, [교육] 고용노동부, 한국산업인력공단 - 스펙초월 멘토스쿨 악성코드 멘토
2014.10, [교육] 교육부 - 모바일 보안 (21h)
2014.12, [특강] 보안프로젝트 - 드라이브-바이 다운로드와 자바스크립트 난독화 (3h)
2015.01, [특강] 보안프로젝트 - 드라이브-바이 다운로드와 자바스크립트 난독화 (3h)
2015.02, [특강] 보안프로젝트 - Viper를 이용한 악성코드 관리 (3h)
2015.03, [특강] 보안프로젝트 - 드라이브-바이 다운로드와 자바스크립트 난독화 특강 (3h)
2015.04, [특강] 한국정보보호교육센터 - 사물인터넷과 보안 (3h)
2015.04, [교육] 한국정보보호교육센터 - 악성코드 분석 실무 (35h)
2015.04, [특강] 보안프로젝트 - 드라이브-바이 다운로드와 자바스크립트 난독화 (3h)
2015.05, [교육] 금융보안원 - 악성코드 분석 실무 (35h)
2015.06, [교육] 한국정보보호교육센터 - 악성코드 분석 실무 (35h)
2015.07, [교육] 금융보안연구원 - 악성코드 분석 실무 (35h)
2015.09, [특강] 보안프로젝트 - 자바스크립트 난독화 (3h)
2015.10, [교육] 금융보안원 - 악성코드 분석 실무 (35h)
2015.11, [특강] SKT - 드라이브-바이 다운로드와 자바스크립트 난독화 (2h)
2015.11, [교육] 한국정보보호교육센터 - 악성코드 분석 실무 (35h)
2015.11, [특강] 보안프로젝트 - 드라이브-바이 다운로드와 자바스크립트 난독화 (3h)
2015.12, [특강] 넥슨 - 드라이브-바이 다운로드와 자바스크립트 난독화 (2h)
2016.06, [교육] 한국정보보호교육센터 - 악성코드 분석 실무 (35h)
2016.07, [특강] 머니투데이 - 랜섬웨어 (30m)
2016.08, [교육] 한국정보보호교육센터 - 악성코드 분석 실무 (21h)
2016.08, [교육] KUCIS 대학정보보호동아리연합회 - 악성코드 분석 실무 (35h)
2016.11, [교육] 대구시청 - 악성코드 분석 실무 (21h)
2016.12, [교육] 한국정보보호교육센터 - 악성코드 분석 실무 (35h)
2016.12, [특강] 경기정보보호지원센터 - 사물인터넷과 보안(3h)
2017.03, [교육] 한국정보보호교육센터 - 악성코드 분석 실무 (56h)
2017.05, [교육] 경기도 광주시청 - 정보화인원 전문교육 (12h)
2017.07, [교육] KUCIS 대학정보보호동아리연합회 - 악성코드 분석 (35h)
2017.08, [특강] 선린고 - 모의해킹 (8h)
2017.09, [특강] 금융보안원 - 랜섬웨어 (6h)
2017.10, [교육] 산업통상자원부 - 침해사고대응 (28h)
2017.10, [교육] 경기 융합보안지원센터 - 침해사고대응 (70h)
2018.01, [교육] 한국정보보호교육센터 - 66기, 악성코드 분석 실무 (35h)
2018.04, [교육] 한국정보보호교육센터 - 단기, 침해사고 분석 및 대응 (35h)
2018.06, [특강] 유한킴벌리 - 악성코드 유포 (3h)
2018.07, [교육] 한국정보보호교육센터 - 67기, 악성코드 분석 실무 (70h)
2018.09, [특강] 한세고 - 악성코드 분석 (4h)
2018.11, [특강] LG U+ 악성코드, 침해사고대응 특강 (4h)
2018.11, [교육] 중부발전 악성코드 강의 (30h)
2019.01, [교육] 동서발전 악성코드 강의 (24h)

기사

2014.07, 보안뉴스 '반도의 흔한 공다팩, 당하였느냐?'
2017.03, 전자신문 '사이버 무기 '보안취약점' 암거래 활개친다'
2017.04, 한국일보 '보안 취약점’ 가격 급등… 화이트해커 신세계 열리다'
2018.04, 보안뉴스 '의료 사이트, 디페이스 공격 당해...해킹에 여전히 취약'
2018.04, 보안뉴스 '3개 대학 9곳 또 디페이스! 대학관련 홈피 해킹 왜 계속되나'

자격증

2000.08, 워드프로세서 1급
2001.10, 정보처리기능사
2010.06, ITQ 파워포인트
2012.08, 정보처리기사
2015.02, IEQ 인터넷윤리자격 2급
2015.12, CEH(Certified Ethical Hacker)
2018.12, 디지털포렌식 전문가 2급

연락처

Email: PCRE = /hakawati@naver\.(com|co\.kr)/
Blog: http://www.hakawati.co.kr
Facebook: https://www.facebook.com/hakawati2

블로그 정보

포스팅 수가 나태함을 상징하는 블로그

운영 규약

본 블로그 안에 모든 자료는 공유를 위한 목적이기에 제 사진을 제외한 자료들은 편하게 이용하시면 됩니다.
단, 이 블로그 안에 모든 자료를 그대로 복사하여 이용하지 마시고, 새로운 형태의 콘텐츠 활용으로 이용해주시길 바랍니다.
기타 자료 문의사항은 위 연락처 또는 댓글, 방명록을 통해서 연락해 주시길 바랍니다.(방명록도 있어요.)
본 블로그의 자료는 The GNU General Public License v3.0 라이선스 규약을 따릅니다.

출처 표기하면 가져다 쓰셔도 됩니다.

보안 규약

연구 목적으로 사용하지 않고 악의적인 목적으로 이용할 시 발생할 수 있는 법적인 책임은 모두 본인에게 있습니다.

"정보통신망 이용촉진 및 정보보호 등에 관한 법률" 정당한 접근권한이 없거나 허용된 접근 권한의 범위를 초과하여 정보통신망에 침하는 행위를 금지한다.(48조 1항) 위반하면 3년 이하의 징역 또는 3000만원 이한의 벌금에 처한다.(63조 1항 1호)

주요 정보통신기반시설을 침해하여 교란·마비 또는 파괴한 자는 10년 이하의 징역 또는 1억 원 이하의 벌금에 처하도록 규정하고 있다(28조 1항).

또 형법에서도 컴퓨터 등 정보처리장치에 허위의 정보 또는 부정한 명령을 입력하거나 그밖의 방법으로 정보처리에 장애를 발생하게 한 자는 업무방해죄로 5년 이하의 징역 또는 1500만 원 이하의 벌금에 처하도록 규정하고 있다(314조 2항).

2018年 12月 21日 올림

MITRE ATT&CKcon 2018 review - 진행 중

hakawati — Fri, 21 Dec 2018 17:30:06 +0900

ATT&CKcon 2018 Full Play List - https://www.youtube.com/playlist?list=PLkTApXQou_8JrhtrFDfAskvMqk97Yu2S2
ATT&CKcon 2018 Presentations - https://attack.mitre.org/resources/attackcon/

1. Advancing Infosec, Keynote Presentation

마이크로소프트 위협 인텔리전스 센터 총 책임자인 존 램버트가 키노트를 잡았다. 전통적인 방어와 최근 방어의 차이를 설명했으며, 마이크로소프트에는 One Hunt라는 것이 있다고 설명했다. One Hunt는 레드팀, 블루팀 모두 하나의 공통 과제를 제공하고 이 과제를 해결하는 프로젝트를 의미하는 것 같았다. 아무래도 공격과 방어의 인사이트를 공유하여 융합되도록 하는데 있어 중요한 부분인 것 같다.

위협 정보 공유하는 것은 매우 중요하다고 언급하며 지속적으로 컨퍼런스 발표, 블로그 운영, 트위터 활동, 도구 제작 및 오픈소스로 공개 그리고 멘토링을 통해 다른 팀이나 다른 사람들과 함께 성장하도록 장려한다고 말한다. 그러면서 이러한 결과가 ATT&CK Matrix가 만들어지지 않았나 라고 말하는 것 같다. 그러면서 다음 오픈소스들을 언급했다.

atomic red team - https://github.com/redcanaryco/atomic-red-team
- 얜 ATT&CK를 공부하면서 알게된 녀석인데 실제 공격에 사용된 코드를 살펴볼 수 있어서 기억하고 있는 오픈소스다.
sigma - https://github.com/Neo23x0/sigma
- 얜 HELK였나 무슨 오픈소스에서 시그니처 부분에 sigma를 적극 도입한다고 이야기해서 알게되었고, Neo23x0은 워낙 유명한 사람이라 놀랐던 오픈소스다.
jupyter - https://jupyter.org/
- 한번 봤었다가 뭐야 이거 하면서 넘겼던 녀석인데 브라우저에서 코딩하는 IDE 오픈소스 같다.
binder - https://mybinder.org/
- 얜 이번에 처음 봤는데 주피터 노트북이 있는 깃헙 주소를 바인더에 넣으면 브라우저에서 실시간으로 컴파일(인터프리터)해서 결과를 보여주는 도구 같다.

이러한 오픈소스를 적재적소에 사용하여 위협 인텔리전스를 수행하는 것이 매우 중요하며, 깃허브화(Githubification)을 진행하여 함께 할 수 있도록 구성하는 것이 중요하다고 언급하며 끝났다. (야레야레 깃헙 이제 MS 꺼잖아 소스코드 올리면 누구 좋으라는거야? 깃랩에 올리자 가용성이 조금 불안하지만..)

The "Githubification" of Infosec - towards a goal of standardizing and sharing knowledge across the community in a way that is usable and repeatable @JohnLaTwC #ATTACKcon pic.twitter.com/0polnVrVrG
— ATT&CK (@MITREattack) 2018년 10월 23일

2. How Did We Get Here?

MITRE의 ATT&CK 리더인 Blake Storm과 인터뷰 내용이다. 처음엔 엑셀로 정리하면서 ATT&CK 프로젝트를 시작했고, 공격 정보를 토대로 방어를 할 수 있길 바랬다고 말한다. 이후 질문들이 이어지는데, 기억에 남는 질문이 ATT&CK의 단편적인 내용으로만 대응을 진행하면 오탐율이 많아지는데, 맥락(Context)적인 내용도 추가할 예정인지 물어본다. 이에 대한 답변으로 기존에 진행하는 방법론에 ATT&CK를 섞어 쓰는게 어떤가를 이야기한다. 플랫폼에 클라우드를 추가하는게 어떤가에 대한 질문에는 당연히 어렵다고 말한다. 각 TTPs에 심각도를 추가하는 것이 어떤가에 대한 질문에는 각 환경이 상이하기에 위협의 크기를 수치화하기가 힘들다고 답변한다. 그 외 다음 도구에 대한 질문이 꽤나 있었다. 아무래도 근거 자료로 매우 중요한 프로젝트이기 때문인듯 하다.

CAR - https://car.mitre.org/
Cyber Analytics Repository의 약자로 공격에 대한 분석 결과를 저장한 저장소 같은 역할을 담당한다. CVE 처럼 별도의 식별 키워드로 CAR를 사용한다.

3. Operationalizing ATT&CK

SCYTHE사의 CEO인 Bryson Bort가 발표했다. 이 회사는 ATT&CK 프레임워크를 이용하여 레드 팀과 블루 팀을 컨설팅하는 회사다. 5분짜리 영상인 점을 보았을 때 핵심만 골라서 이야기한거 같다. 한마디로 "ATT&CK를 원소 주기율표의 원소들 처럼 이리섞고 저리섞어 활용해야 한다."로 요약할 수 있다.

4. Summiting the Pyramid of Pain: Operationalizing ATT&CK

General Electric의 인텔리전스 분석가 EMMA와 사고 분석가 JUSTIN이 발표했다. 일단 위협 인텔리전스 활동이 얼마나 고통스러운지 파이어아이의 고통의 피라미드(Pyramid of Pain)을 가지고 나왔다. 특히나 IDD(Intelligence Driven Defense)를 수행할 때 인텔리전스 팀과 침해사고 대응팀의 임시적 대화(ad hoc communication)이 가장 큰 고통이며, 이 간극이 인텔리전스 팀이 생산하는 데이터와 침해사고대응팀이 생산하는 데이터에 간극을 일으킨다고 언급한다. 이를 해결하기 위해 선택한 것이 스프레드시트로 데이터를 정립해 운영하는 것이었으나 이 또한 720개가 넘어가는 TTP를 분류하는 점에서 또 다른 고통(Spreadsheet of Pain)으로 이야기를 한다.

고통에서 해방하고자 만든 자체적인 프로세스인 Tiamat을 소개했다. 한 기업이 위협 인텔리전스를 수용하려면 이러한 고통을 이겨냈을 때 성과가 발현될 듯 싶지만, 전문적이고 지속적으로 활동 가능한 침해사고대응팀부터 만들어야 하지 않을까 싶다.

5. ATT&CK: All the Things

미공군인 USAA의 정보보안 전문가 Neelsen Cyrus와 디텍션 리더인 David Thompson의 발표다. 사이버 킬체인은 낡은 방법론이고 ATT&CK는 최신 방법론으로 이야기한다. 따라서 ATT&CK로 분석하기 위해 데이터를 수집하여 관리하는데 이를 kafka 메시징 수집기를 이용하고 Logstash를 통해 로그를 분류한다. 90일 데이터는 Elasticsearch 데이터베이스에 기록하고, 1년의 데이터는 Hadoop 파일 시스템을 이용하여 기록한다. 그리고 위협 인텔리전스를 하기 위해 자체적으로 생태계를 구축한 이야기를 한다.

DMR(Detection Management Reporting) - 흔히 말하는 대시보드 같은 역할을 하는 기능으로 보인다.
DSP(Defense Security Posture) - 탐지 방법을 설정하면 DMR에 반영되고, DMR에서 우선순위를 정하면 DSP에 반영된다. 탐지 방법을 반영하기에 ATT&CK의 TTPs를 여기에 적용한다.
GWH - 시그니처 기반으로 큐를 돌려 헌팅되면 그 결과를 보여준다.
PAX - 억제 엔진으로 ATT&CK의 모든 정보를 단순히 탐지하는 형태로 사용하면 오탐이 많을 수 있기에 이를 억제하기 위해 사용하는 기능으로 보여진다.
AST(A Simulation Tool) - Canaries나 PoC 실행, 공격 명령어 등 공격을 시뮬레이팅할 수 잇는 기능이다.
MIST(Malicious Intel Search Tool) - IoC 정보를 수집하거나 인터넷에 공개된 다양한 위협 정보를 수집하는 기능이다.
SHP(Secure Hub Portal) - 공격을 매트릭스 형태로 관리하고, 보고서를 생산하는 등 기능을 가진다.

군에서 솔루션을 직접 구축해 운영하고, 그 구축에 필요하다면 오픈소스를 적극 활용하면서 이를 컨퍼런스에서 다양한 전문가에게 공개하고 토론하는 문화가 신기했다.

6. Agile Continuous Improvement Using ATT&CK

음 캘리포니아 치과 의사 협회(Delta Dental of California)? 여기에 사이버 위협 관리자인 Matthew Stiak와 컨설팅 업체인 Level Nine Group의 Jason Sinchak이 발표했다. 주된 내용은 조직에 ATT&CK를 적용하는데 필요한 고찰에 관한 이야기다. 탐지(Detection), 방지(Prevention), 대응(Response) 영역은 꾸준이 발전하고 있으니 식별 영역으로 넘어가자는 의미를 가지고 있다. 이를 위해서 ATT&CK를 고민했는데, 새로운 방법론을 도입할 때 고충은 기존 방법론과의 마찰이다. 이 마찰을 다음과 같이 정의했다.

구조적 제한
교육이 필요
한정된 자원과 시간 관리

이를 해결하기 위해 선택한 방법으로 다음을 제안한다. 제안의 핵심은 애자일이다.

애자일 방법론을 이용하여 장접을 부곽시킨다.
미시적 관점까지 살펴볼 수 있는 퍼플 팀을 창설한다.
각 항목별 평가 지표를 구성한다.

애자일 방법론은 이야기만 들어봤지 구체적으로 무엇인지 모른다. 오늘 퇴근길에 당장 서점에 들려서 애자일 관련 책 중 가장 많이 판매된 책을 한권 구매해서 읽어봐야 할것 같다. 퍼플 팀은 여섯 번째 영상에서 처음 나온 단어인데, 레드 팀과 블루 팀의 소통의 부재를 연결짓고 매니징하는 관리직으로 보면 된다. 다만 여기서 제안하는 'micro' 퍼플 팀은 레드 팀과 블루 팀의 활동의 단편적인 한 블록 단위로 평가를 하는 미시적인 평가를 진행하는 형태로 표현한다. 이 집단에 의해 만든 평가 지표로 객관적인 평가를 구성하여 효과성을 증명하는 것으로 이야기가 마무리된다.

이전 까지는 레드 팀과 블루 팀만 언급나왔다면 처음으로 퍼플 팀에 관한 이야기를 했다. 분야가 다른 두 전문 분야를 섞었을 때 마찰은 커진다. 우리나라는 그 조율을 각 분야의 상급자가 조율했다면, 외국의 경우 여유가 있는지 없는지는 모르겠으나 중재자 역할을 하는 조직을 별도로 운영하는 것으로 알고 있다. 이 점을 미루어 보았을 때 퍼플 팀은 매우 중요한 교두보 효과를 억제할 수 있다고 생각한다.

7. Vendor Panel Discussion

ATT&CK를 이용하는 밴더사 패널이다. Tag Cyber는 처음 보는 회사고 나머지 회사는 요즘 핫한 트렌드에 발맞춰 움직이는 회사들이다. 팔로알토는 다른 회사에 비해 전통성이 있지만.. 토론에 참여한 밴더사는 영상을 보는 기준 왼쪽부터 순서대로 다음과 같다.

Tag Cyber - 컨설팅, 교육, eBook 간행물 등을 진행하는 회사다. 이 패널 토의에서 Tag Cyber의 Ed Amoroso 박사는 진행자 역할을 한다.
ATTACKIQ - BAS(Breach and Attack Simulation) 솔루션으로 유명한 회사다. 알려진 유출 및 공격 시나리오를 기반으로 자사의 위험성을 판단하는 솔루션으로 특히나 ATTACKIQ에서는 ATT&CK의 분류 방식을 포함하여 광범위한 유출과 공격 시나리오를 제공한다.
Endgame - 얼마전에 ATT&CK 시나리오를 에뮬레이팅할 수 있는 솔루션 소개 영상을 보고 감탄한 회사다. 그것 보다 사실 어벤저스 엔드게임을 빨리 보고 싶다.
Cybereason - 이스라엘에 본사가 위치한 정보보안 업체로 국내에도 이 회사의 솔루션을 많이 검토하고 사용한다. 이 회사의 대표적인 솔루션은 EDR(Endpoint Detection & Response)로 엔드포인트에서 탐지하고 대응하기 위한 수 많은 로그 분석을 진행하고, 당연히 제품에는 ATT&CK를 활용하고 있는 것으로 알려져있다.
Unit 42 at PaloAlto Networks - 팔로알토 네트웤스의 Unit 42는 APT 공격을 전문적으로 분석하고 CTI화하여 운영하는 대표적인 조직 중 하나다.

첫 번째 질문은 ATT&CK 프레임워크에 대한 생각을 물어봤다. 요약하자면 다음과 같다.

Unit 42의 Jen은 ATT&CK 프레임워크를 가지고 환경에 적용해보고 그 결과를 통해 방어하는 방법을 다루는 것이 좋다고 언급한다. 특히 오픈소스를 사용하는 경우가 많은데 능력있는 공격자는 오픈소스를 많이 사용하기에 문제되지 않는다고 말한다.
Cybereason의 Ross는 ATT&CK 프레임워크가 로제타 스톤과 비유했는데, 그 이유는 이 프레임워크를 통해 기술적인 것들을 공통된 언어로 사용하여 소통할 수 있었기 때문이다고 말한다. (로제타 스톤은 고대 이집트의 법전이 새겨진 비석인데, 이 비석이 발견되면서 이집트의 상형 문자를 해독하여 이집트 역사를 이해할 수 있게 되었기 때문에 이를 비유한 것으로 보여진다.) 그 외 사이버 보안의 문제로 공격자가 방어자보다 늘 우위에 있는 이유는 많은 시간을 가질 수 있기 때문이라고 말한다. 그렇기에 방어자는 제한된 시간 안에 방어를 유지해야하고, 이러한 상황에 필요한건 효율적인 방어 전략이라고 말한다.
Endgame의 Devon은 수 많은 위협을 어떻게 분류할 것인가, 분류한 것을 어떻게 이해시킬 것인가에 많은 방법이 있는 만큼 많은 고민이 필요하다고 말한다. 이런 고민에 있어서 현지화된 정보만으로는 한계가 있고, 다양한 정보가 공유되어 활용되어야 하는데 ATT&CK 프레임워크가 큰 한몫을 한 것으로 이야기한다. 게다가 ATT&CK는 실제 활용되고 있기에 매우 긍정적으로 이야기한다.
마지막으로 ATTACKIQ의 Carl은 보안을 경제적으로 접근했다. 방어에 비해 공격자가 100배 정도 되는 금액을 더 많이 소비하여 공격한다고 이야기한다. 이런 비대칭적인 소비에 집중하여 이런 문제를 해결할 수 있는 방법을 찾는 것이 좋지 않을까 이야기한다. 또한 ATT&CK 프레임워크는 더욱 가공되어야 한다고 말한다. 예시로 클라우드 침해에 관한 내용인데, 이 부분은 프레임워크에 포함된 TTPs가 없음을 이야기했다.

마지막에 Carl이 말한 클라우드 침해에 관한 이야기 때문에 중반 이후부터는 일반적인 보안 트렌드와 패널 질문(보안의 고충)에 대한 이야기를 한다. 이 이야기 안에 핵심으로 손꼽을만한 이야기를 한다면 바로 경제 관점에서 바라보는 보안이다. 과거에 공격자는 단순히 Spray-and-pray 모델로 공격을 통한 수익을 노렸다면, 지금은 시스템화되어 있고 기술력있게 공격하여 얼마만큼의 수익을 가질 것인가를 생각한다고 말한다.

자본주의 시대에 충분히 고려해볼 문제다. 공격자가 방어자의 방어를 뚫는데 많은 시간과 돈(시간이 곧 돈이지)이 든다면 부담감을 느끼거나, 만만하게 시작했다면 손해볼 수 있을 것이다. 그러면 다음 공격은 더 큰 자본을 가지지 않는 이상 쉽지 않을 것이다. 이러한 관점이 경제 관점에서 바라보는 보안으로 이야기할 수 있을 것이다.

8. VCAF: Expanding the ATT&CK Framework to cover VERIS Threat Action Varieties

9. Playing Devil’s Advocate to Security Initiatives with ATT&CK

10. From Red VS Blue to Red Loves Blue

11. Helping Your Non-Security Executives Understand ATT&CK in 10 Minutes or Less