서버를 구축하고 AWS상에 서비스하기

2022-02-22 server developement xfrnk2

목표

에러와 해결했던 내용을 기록하기
새롭게 알게된 것들을 알아보고 기록하기

진행 상황

Local 서버 구축 / Window/MacOS + Apache PHP MySQL (Bitnami)
외부에서 접속하기: phpinfo 띄우기 (by 포트포워딩)

AWS 서버 구축 / Linux + Nginx PHP MySQL
외부에서 접속하기: phpinfo 띄우기
MySQL 외부에서 접속하기 (DataGrip or Workbench)
phpMyAdmin 설치
Domain 적용 (가비아, 후이즈 … 구입)
HTTPS 적용 (let’s encrypt)
Sub Domain 적용 (Dev, Prod)
Redirection 적용 (IP to Domain, http → https)

Sub Domain에 각각 나만의 페이지 만들기 (html, css, javascript 활용)

외부에서 접속하기: phpinfo 띄우기 (by 포트포워딩)

외부에서 접속하기 위한 포트포워딩 설정

Untitled (20)

자가 공유기의 관리자 이름과 비밀번호가 일치하지 않아서 초기화 후 차례대로 진행했다.

Untitled (21)

Untitled (22)

현재 접속된 PC의 IP주소로 설정 후 추가한다.

Untitled (23)

초기화 한 김에 무선 비밀번호를 재설정하기 위해서 들어간 곳에 보이는 여러 프로토콜들.. 학부 과정 중 눈에 익은 게 몇 보이지만, 당장 설명할 수는 없을 것 같아서, 간단하게 한 문장으로라도 요약해 보고 싶단 생각이 들어 정리해봤다.

AES는 의 약자로 ‘고급 암호화 표준’라는 의미이고, 미국 표준 기술 연구소에 의해서 연방 정보 처리 표준으로 지정된 암호화 방식 AES-128, AES-192, AES-256로 불리고, 숫자는 각각 암호화 키 길이이고 키에 따라 각 10, 12, 14 라운드를 실행한다.

TKIP : 임시 키 무결성 프로토콜(Temporal Key Integrity Protocol, TKIP), IEEE 802.11의 무선 네트워킹 표준으로 사용되는 보안 프로토콜

WPA (Wi-Fi® Protected Access) 는 무선 환경을 위한 데이터 암호화 기술 PSK(Pre-shared Key).말 그대로 사전 공유키

이로서 노트북에 접근할 수 있는 조건이 완벽하게 갖추어 졌다.

phpinfo 띄우기

index.php파일을 새로 하나 만들어 주고… apache2> conf > httpd.conf가 있다. (http-daemon configuration)

열고 나서, “DirectoryIndex"를 찾아보자. .php를 가장 우선 열고 싶다면, 순서를 바꾸어서, index.php index.html과 같이 수정할 수 있다.

웹 서버 호스팅을 받는 경우, in dex.html을 아래와 같이 수정한다.

<?php
header("Location: index.php");
exit;
?>

<html>
...기존 코드...
</html>

Untitled (24)

Untitled (25)

아파치를 재시작하니 잘 나온다.

Untitled (26)

AWS 서버 구축 / Linux + Nginx PHP MySQL

AWS 서버 생성

AWS 홈페이지 접속
계정 생성 및 로그인 후, 우상단 지역에 서울로 선택.
서비스 대분류에서 EC2를 클릭
인스턴스 선택 > 인스턴스 시작
아래의 항목 선택

Untitled (27)

기타 설정

프리티어 선택후 기본 값 설정 유지 후 다음 단계 단계 4에서, 프리티어이므로 크기 30기가까지 사용 가능하다고 하니 30으로 정정해주기.

키 페어를 잘 보관하도록 한다.

Untitled (28)

서버 생성 완료.

AWS 서버 접속

WinSCP 설치 후 로그인을 시도한다.

WinSCP는 마이크로소프트 윈도우용으로 개발된 자유-오픈 소스 소프트웨어이고, SFTP, SCP 및 FTP 클라이언트이다. 주요 기능은 로컬 및 원격 컴퓨터 간 보안 파일 전송이다. 그뿐 아니라 WinSCP는 기본적인 파일 관리자와 파일 동기화 기능을 제공한다.

Untitled (29)

호스트 이름에는 AWS의 인스턴스 > 퍼블릭 IPv4 주소를 복붙 한다. 사용자 이름은 아래의 문서를 따라 입력한다.

Untitled (30)

고급 > 고급 > SSH > 인증 > 개인키 파일 클릭 후 AWS에서 생성한 키 페어(.pem 확장자)를 선택 후 (OpenSSH 개인키를 PuTTY 형식으로 변환) ppk 파일로 변환하고 저장 > 저장 순으로 진행한다.

로그인 후 좌상단에 아래와 같은 모습이 보인다. 오른쪽에서 두 번째(번개 모양) 아이콘을 클릭하면 터미널을 실행한다.

Untitled (31)

Mysql 외부에서 접속하기

sudo mysql_secure_installation 명령어 실행을 통해 mysql-server 설치시, 아래와 같은 스크립트가 나오는데, 원하는 조건에 맞게 응답하면 되겠다.

Would you like to setup VALIDATE PASSWORD plugin? 패스워드를 설정하니 Y,

LOW Length >= 8 MEDIUM Length >= 8, numeric, mixed case, and special characters STRONG Length >= 8, numeric, mixed case, special characters and dictionary file Please enter 0 = LOW, 1 = MEDIUM and 2 = STRONG: 2 가급적 강력한 패스워드를 원하므로 2

Remove anonymous users? default인 anonymous user를 제거하고자 하므로 y,(단, 접속시 -u 옵션을 반드시 명시해야 한다. 주의!)

Disallow root login remotely? localhost가 아닌 ip로부터 root 계정으로 원격 액세스가 필요하니 no를 선택했다.

MySQL에 접근하기 위한 유저 만들기

EC2 인스턴스 서버에서 root계정으로 접속해서 계정을 만든다.

필자의 계정 이름은 bon이다.

$ sudo mysql

mysql> create user 'bon'@'%' identified by '비밀번호';

//만든 계정 확인
mysql> use mysql;
mysql> select user, host from bon;

bon계정으로 조회가 가능한 데이터베이스 및 테이블을 생성한다.

mysql> create database test;
mysql> use test;
mysql> create table ttest(test1 varchar(100), test2 varchar(100));
mysql> insert into ttest(test1,test2) values('10','20');
mysql> insert into ttest(test1,test2) values('20','30');

데이터베이스 접근 권한 주기

mysql> grant all privileges on test.* to 'bon'@'%';
mysql> flush privileges;
mysql> show grants for 'bon'@'%';

flush privileges는 grant라는 테이블을 즉시 리로드해서 변경 사항을 즉시 반영한다.

원격 접속하기 위한 계정 설정은 끝났고 이제 원격 접속을 가능하게 MySQL 설정 파일을 변경하여야한다.

$ cd /etc/mysql/mysql.conf.d
$ sudo vi mysqlc.cnf

MySQL 외부 접속 설정

mysqld.conf를 vi편집기로 열어 bind-address를 0.0.0.0으로 수정한다.

Untitled (32)

AWS EC2 인스턴스에서도 인바운드 규칙을 설정해주어야한다.

Untitled (33)

인바운드 규칙을 다음과 같이 한다.

sudo service mysql relaod명령어를 통해 재실행시킨다.

Mysql Workbench를 사용한다. (Datagrip 등도 사용이 가능)

Untitled (34)

만일 접근이 불가하다면 권한 문제일 가능성이 크다.
루트계정 비번변경방법은 아래 웹사이트 링크를 참조한다. https://kutar37.tistory.com/entry/Mysql-root-비밀번호-재설정

Untitled (35)

성공적으로 접속이 되었다.

php myadmin 설치

$ sudo apt update
$ sudo apt upgrade
$ sudo apt install phpmyadmin

Web Server와 phpMyAdmin의 데이터베이스를 dbconfig-common로 설정 여부를 묻는 창이 나온다.

webserver : 현 과정에서는 nginx를 사용할 예정이므로 선택하지 않았다.

dbconfig-common은 필요가 없으므로 No를 선택한다.

심볼릭 링크란 링크를 연결하여 원본 파일을 직접 사용하는 것 같은 효과를 내는 링크를 말한다.

Nginx 가 phpMyAdmin 파일을 올바르게 찾게 하기 위해서 /usr/share/phpmyadmin (phpMyAdmin 디렉토리)로부터 /var/www/html/phpmyadmin(Nginx 도큐먼트 root 디렉토리)로 심볼릭 링크를 생성해준다.

$ sudo ln -s /usr/share/phpmyadmin /var/www/html/phpmyadmin

Nginx 설정 파일에서 index.php를 추가하여 php 파일이 nginx를 통해 웹에 보일 수 있게 된다.

$ sudo vi /etc/nginx/sites-available/default

Untitled (36)

이후 재시작을 통해 변경 사항을 저장, 적용해준다.

$ sudo service nginx restart

AWS외부아이피주소/phpmyadmin 에 접속한다.

phpmyadmin 접속이 정상적으로 되었다.

Untitled (37)

도메인 구매하고 적용하기(호스팅케이알 이용)

호스팅케이알에서는 도메인 등록 시 무료로 네임서버를 제공하고 있으며, 등록 후에 언제든지 변경이 가능하다.

호스팅케이알(hosting.kr)웹 사이트 가입 후 도매인을 구매한다.
마이페이지 > 도메인 관리 > DNS 레코드 관리에 들어간다.
호스팅케이알의 DNS 레코드 설정 가이드를 참고하여 아래와 같은 형식으로 기입한다.

Untitled (38)

참조 : https://help.hosting.kr/hc/ko/articles/900001814906

구매한 도메인으로 문제 없이 접속 되는 것을 확인.

Untitled (39)

Let’s Encrypt 적용하기

Let’s Encrypt SSL 인증서 발급 방법 4가지

Let’s Encrypt SSL 인증서 발급 방법은 webroot와 Standalone, DNS의 3가지 방식 존재
인증서 발급은 사이트에서 인증기관인 Let’s Encrypt에 접속해 이 사이트의 유효성을 검증하는 과정을 거치며 이 과정을 아래 4가지 방법 중 하나를 선택해 진행할 수 있음

webroot : 사이트 디렉토리 내에 인증서 유효성을 확인할 수 있는 파일을 업로드하여 인증서를 발급하는 방법. 실제 작동하고 있는 웹서버의 특정 데렉토리의 특정 파일 쓰기 작업을 통해서 인증. 이 방식의 장점은 nginx를 중단시킬 필요가 없음.. 이 방법의 단점은 인증 명령에 하나의 도메인 인증서만 발급 가능
웹서버. Nginx나 아파치와 같은 웹서버에서 직접 SSL 인증을 실시하고 웹서버에 맞는 SSL세팅값을 부여. 발급이나 갱신을 위해 웹서버를 중단시킬 필요가 없음. 인증서 갱신 시 상황에 맞게 세팅을 자동으로 업데이트. 사용자가 세팅을 변경할 수 있지만 자동 업데이트 시 반영되지는 않음
Standalone : 사이트 작동을 멈추고 이 사이트의 네크워킹을 이용해 사이트 유효성을 확인해 Let’s Encrypt SSL 인증서를 발급하는 방식. 80포트로 가상 staandalone 웹서버를 띄워 인증서를 발급. 이 방식은 동시에 여러 도메인을 발급 받을 수 있음. 그렇지만 인증서 발급 전에 Nginx를 중단하고 발급 완료 후 다시 Nginx를 시작해야 함
DNS : 도메인을 쿼리해 확인되는 TXT 레코드로 사이트 유효성을 확인하는 방법. 와일드 카드 방식으로 인증서를 발급 가능. 이 방법은 당연하게도 서버 관리자가 도메인 DNS를 관리/수정할 수 있어야 하며. 인증서 갱신 시마다 DNS에서 TXT값을 변경해야 하므로외부에서 TXT 레코드를 입력할 수 있도록 DNS가 API를 제공하는 경우만 갱신 과정을 자동으로 처리(클라우두플레어 API가 대표적인 사례)

필자가 시도해 본 방법은 2, 3, 4인데 최종적으로 사용하기로한 방법은 2번,

Nginx에서 직접 SSL인증을 실시하는 방법을 사용했다.

3, 4를 시도해 보았으나 도중에 적합하지 않다는 생각이 들어 중단했는데 이유는 다음과 같다.

3.(Standalone)

standalone 옵션은 또한 한꺼번에 여러 개의 사이트를 인증 받을 수 있는데, 연속된 사이트명을 나열하면 된다.

그런데 허점이 있다. 이렇게 여러개 사이트를 인증 받을 시 인증서 존재 위치가 맨앞 사이트명으로 통일되게 된다. 나중에 사이트를 없앨 때 곤란한 상황에 처할 수 있는 것이다.

service nginx stop

certbot certonly --standalone -d 사이트명

4.(DNS)

서브도메인을 모두 적용한다고 가정해 보자. 와일드 카드 방식으로 인증서가 발급 가능하다길래 시도해봤다.

DNS가 API를 제공하는 경우에만 갱신 작업을 수행하는 스크립트를 실행하던가 해서 처리가 가능하다. 일반적인 도메인 등록 업체를 사용하는 경우 수동으로 갱신할 수밖에 없다.

즉 호스팅케이알과 같은 도메인 등록업체를 사용하고 있다면, 와일드카드 SSL인증서는 자동으로 갱신이 되지 않는다고 볼 수 있다.

문제점은 아래와 같다.

와일드 카드 인증서를 받는 방식은 DNS 소유권을 확인하는 과정이 필요하기 때문에 갱신시에도 DNS _acme-challenge TXT 값을 매번 갱신해서 소유권을 확인하도록 되어있다.보통 도메인 대행업체를 이용해서 사용하는 대부분의 경우 이 TXT 레코드를 자동으로 변경해주는 기능이 없기 때문에 인증서 자동갱신이 되지 않는다.

certbot 에서 제공하는 TXT 레코드 자동갱신 플러그인은 아래와 같이 다양한 종류를 지원한다.

Cloudflare DNS plugin
DigitalOcean DNS plugin
DNSimple DNS plugin
Gehirn DNS plugin
Google DNS plugin
Linode DNS plugin
OVH DNS plugin
RFC 2136 DNS plugin
Route53 DNS plugin
SakuraCloud DNS plugin

위에서 지원하지 않는 일반 도메인대행업체의 DNS서버를 이용하여 와일드카드 인증서를 받았다면 자동갱신은 불가능하다고 보면 된다.따라서 자동갱신이 가능한 AWS Route53, CloudFlare, Google DNS 등의 서비스를 이용하면 편하게 갱신할 수 있다는점을 참고하기 바란다.

또한 직접 DNS서버(bind같은)를 운영한다면 rfc2136 플러그인을 사용하여 갱신도 가능하다.

certbot certonly --manual -d *.bonster.xyz -d bonster.xyz --preferred-challenges dns

Untitled (40)

Untitled (41)

위는 시도한 과정중 일부이다

매 3달 주기로 갱신이 필요해질 때마다 도메인 관리 사이트에 들어가서,(필자의 경우 호스팅케이알이다)

DNS 레코드 설정 페이지에서 매 번 위의 색칠한 부분을 포함한(이후 과정이 더 있긴 하지만) 토큰을 갱신 후 수동으로 등록해주는 절차가 필요하다.

DNS서버에 TXT타입의 _acme-challenge 항목을 넣어줘야 한다. (위 이미지상 색칠한 부분)

2개를 넣어 줘야 하는데, 첫번째 항목을 DNS에 갱신시켜 주고 “nslookup -q=txt _acme-challenge.<도메인명>” 갱싱된 내용확인후 진행하면 된다.

3개월마다 일련의 순서를 따라 인증서를 갱신하고 HTTP웹서버를 재시작시켜 줘야 한다. 와일드 카드 인증서는 보안적 측면에서 사용을 지양하는 편이 낫겠다고 판단했다.

이유는 아래에 있다.

와일드카드 인증서 등록방법

https://atl.kr/dokuwiki/doku.php/let_s_encrypt_certbot_wildcard_certificates

와일드카드 사용을 지양하는 이유 , 읽을거리

https://gist.github.com/joepie91/7e5cad8c0726fd6a5e90360a754fc568

https://tech.ssut.me/why-you-probably-should-not-use-a-wildcard-certificate/

아래는 위의 링크의 내용을 일부 발췌해 온 것이다.

만약 [images.google.com](http://images.google.com/) 서버만 해킹당한다면 [mail.google.com](http://mail.google.com/)은 영향을 받지 않을겁니다.

하지만, [images.google.com](http://images.google.com/) 서버의 인증서가 *.[google.com](http://google.com/)을 위한 와일드카드 인증서였다면 [mail.google.com](http://mail.google.com/)까지 털어서 이메일 트래픽을 훔쳐본다던가 할 수 있게 되겠죠.

[mail.google.com](http://mail.google.com/) 서버는 해킹당하지 않았는데도 말이죠!

만약 당신이 같은 서버에서 같은 서비스를 가리키는 여러 호스트네임을 갖고 있다면 와일드카드 인증서를 써도 좋습니다. 이 와일드카드 인증서가 다른 서버를 가리키는 호스트네임까지 커버하지 않는다면 말이죠. 그렇지 않다면, 각각의 서비스는 반드시 각각의 서비스를 위한 인증서를 가져야 합니다.

만약 당신이 단일 서버면서 단일 서비스를 가리키는 호스트네임을 갖고 있다면 - 예로 [login.mysite.com](http://login.mysite.com/) 및 사용자에게 생성된 사이트 - 사용자에게 생성된 사이트의 경우는 그 서비스를 위한 접두사(prefix)를 두어야 합니다. 예로, 인증서 하나는 [login.mysite.com](http://login.mysite.com/), 나머지(와일드카드)는 *.[users.mysite.com](http://users.mysite.com/) 처럼요.

(명확하게: 이 내용은 Let’s Encrypt에만 해당하는 것이 아니라 일반적인 모든 와일드카드 인증서에 해당합니다. 하지만 Let’s Encrypt 덕분에 와일드카드 인증서가 더이상 값비싸지지 않은 지금, 이 문제는 조금 더 주의를 기울일 필요가 있다고 봅니다.)

세 줄 요약

하나의 와일드카드 인증서를 공유하는 조건이라면, 하나의 서버가 해킹당할 경우 같은 인증서를 공유하고 있는 다른 서버들 또한 해킹 당하는 것이 가능한 일이다.
서브 도메인이 단일 서비스를 가리키고 있다면 단일 서비스 당 하나의 인증서를 두도록 한다.
필자가 구글링 해 본 결과 메일이나 로그인의 경우 단일 서비스당 하나의 인증서를 두는 편이 좋아 보인다.

웹서버에서 Let’s Encript로 SSL 인증서 발급하기

아래의 문단은 아래의 한 줄 아래 링크에 있는, Let’s Encrypt의 번역본을 완전히 참조한다. 참조 링크 : https://velog.io/@pinot/Ubuntu-18.04에서-Lets-Encrypt를-사용하여-Nginx에-SSL을-적용하는-방법

Let’s Encript란

Let’s Encrypt는 무료 SSL / TLS 인증서를 얻고 설치할 수 있는 인증 기관으로, 웹 서버에서 암호화 된 HTTPS를 사용할 수 있게 해줍니다. 또한, Certbot 이라는 자동화 클라이언트를 제공하여 Apache 및 Nginx에서 인증서를 획득하고, 설치하는 전체 프로세스가 자동화 되어 있습니다.

이 도움말에서는 Certbot을 사용하여 Ubuntu 18.04 에서 Nginx용 무료 SSL 인증서를 받고, 자동으로 갱신하도록 설정할 수 있습니다.

또한, 이 도움말에서는 default 파일 대신, 별도의 Nginx 서버 블록 파일을 사용합니다. 일반적인 실수를 방지하고, default 파일을 예외 처리 파일로 유지할 수 있으므로, 도메인마다 새로운 Nginx 서버 블록 파일을 만드는 것을 추천합니다.

1. Nginx 설치

sudo apt update sudo apt install nginx

2. 방화벽 설치(AWS 쓰고있으면 Skip)

웹서버 확인

sudo service nginx status

nginx.service - A high performance web server and a reverse proxy server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: en
   Active: active (running) since Wed 2020-09-16 17:19:24 KST; 1h 19min ago
     Docs: man:nginx(8)
  Process: 7597 ExecStop=/sbin/start-stop-daemon --quiet --stop --retry QUIT/5 -
  Process: 7611 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code
  Process: 7599 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process
 Main PID: 7615 (nginx)
    Tasks: 2 (limit: 1140)
   CGroup: /system.slice/nginx.service
           ├─7615 nginx: master process /usr/sbin/nginx -g daemon on; master_pro
           └─7754 nginx: worker process

3. 서버 블록 설정하기

우분투 18.04에서 Nginx설치하면 기본으로 /var/www/html 을 제공합니다. 새로운 Nginx 서버블록을 만드려면 자신의 도메인이름으로 된 폴더를 만들어야 합니다.

sudo mkdir -p /var/www/{도메인이름}/html sudo chown -R $USER:$USER /var/www/{도메인이름}/html sudo chmod -R 755 /var/www/{도메인이름}

이제부터 {도메인이름}은 example.com 으로 지정하겠습니다.

지정하고 나면 /etc/nginx/sites-available/ 에 example.com 을 만듭니다.

sudo vi /etc/nginx/sites-available/example.com

server {
        listen 80;
        listen [::]:80;

        root /var/www/example.com/html;
        index index.html index.htm index.nginx-debian.html;

        server_name example.com www.example.com;

				location / {
								#try_files $uri $uri/ =404; 주석처리
                proxy_pass http://localhost:8080;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forward-For $proxy_add_x_forwarded_for;
                proxy_set_header Host $http_host;
        }
}

proxy_pass를 추가하여 리버스프록시 설정합니다.

이 파일을 sites-enabled 폴더에 연결합니다.

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

`/etc/nginx/nginx.conf` 에서 해시 버킷 메모리 문제 해결하기

...
http {
    ...
    server_names_hash_bucket_size 64;
    ...
}
...

Nginx 설정이 잘됐는지 확인하기

sudo nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

테스트가 성공적이라면 바로 nginx restart

sudo service nginx restart

4. Certbot 설치

Let’s Encrypt를 사용하여 SSL 인증서를 얻기 위해서는 우분투 서버에 Certbot 클라이언트를 설치해야 합니다. Certbot의 개발은 빠르게 개발되고 있어서, 우분투 apt 에서 제공하는 Certbot 패키지는 조금 오래된 버젼입니다. 하지만, Certbot의 레포지토리는 항상 최신을 유지하고 있습니다. 우리는 레포지토리를 사용하여 설치할 예정입니다.

아래 명령어를 추가하여 레포지토리를 추가합니다.

sudo add-apt-repository ppa:certbot/certbot

설치하기

sudo apt install python-certbot-nginx

5. SSL 인증서 가져오기

Certbot은 다양한 웹 서버에 대하여 SSL 인증서를 얻을 수 있는 플러그인을 제공합니다.

Nginx 플러그인을 사용하기 위해, 다음과 같이 입력합니다.

sudo certbot --nginx -d example.com

certbot은 -d 우측에 있는 도메인들을 유효하게 만드는 설정을 진행할 수 있습니다.

진행시 다음처럼 뜹니다.

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Enter email address (used for urgent renewal and security notices) (Enter 'c' to
cancel): 이메일 주소

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
agree in order to register with the ACME server at
https://acme-v02.api.letsencrypt.org/directory
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(A)gree/(C)ancel: 

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Would you be willing to share your email address with the Electronic Frontier
Foundation, a founding partner of the Let's Encrypt project and the non-profit
organization that develops Certbot? We'd like to send you email about our work
encrypting the web, EFF news, campaigns, and ways to support digital freedom.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(Y)es/(N)o:

이메일 주소 입력하고, 서비스 약관에 동의해야하는 절차를 수행하면 됩니다.

위 절차가 성공적으로 진행한다면, certbot은 https를 어떻게 설정할 지 묻습니다.

Obtaining a new certificate
Performing the following challenges:
http-01 challenge for example.com
Waiting for verification...
Cleaning up challenges
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/example.com

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

질문: http 트래픽을 https로 리다이렉트 할 것입니까? 아니면 http 접근을 막으실 겁니까?

1번: 리다이렉트 없음 - 웹서버 설정에 아무런 변화도 없습니다.

2번: 리다이렉트 - 모든 http 연결을 https로 리다이렉트 합니다. 웹서버 설정을 바꿀 수 있습니다. 바뀐 설정은 다시 되돌릴 수 있습니다.

여기서 2번을 선택하여 http연결을 https로 리다이렉트합니다.

Congratulations! You have successfully enabled
https://example.com

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

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/example.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/example.com/privkey.pem
   Your cert will expire on 2020-12-15. 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"
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - 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

Let’s Encrypt의 인증서는 설치가 완료된 이후 90일 까지만 유효합니다.

90일 지나기전에 certbot을 다시 실행하여 인증서를 갱신해야합니다.

6. SSL 자동으로 갱신시키기

Let’s Encrypt의 인증서는 90일 동안만 유효합니다. 인증서를 자주 갱신시키는 것이 권장되기 때문입니다. 우리는 certbot 패키지를 설치하여 이 문제를 자동화 시킬 수 있습니다. /etc/cron.d 내의 스크립트는 하루 두번씩 실행되어 만료일까지 30일 이내의 모든 인증서를 자동으로 갱신 시킬 수 있습니다.

갱신 절차를 테스트 해보려면, 다음 명령어를 입력하세요.

$ sudo certbot renew --dry-run

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Processing /etc/letsencrypt/renewal/example.com.conf
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator nginx, Installer nginx
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for example.com
Waiting for verification...
Cleaning up challenges
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
new certificate deployed with reload of nginx server; fullchain is
/etc/letsencrypt/live/example.com/fullchain.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates below have not been saved.)
Congratulations, all renewals succeeded. The following certs have been renewed: /etc/letsencrypt/live/example.com/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates above have not been saved.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
IMPORTANT NOTES: - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal.

오류가 없다면, 당신은 모든 설정을 마친 것입니다. 이제 certbot이 자동적으로 인증서를 갱신하고, Nginx를 재시작 할것입니다. 만약 자동 갱신 프로세스가 실패할 경우, 인증서가 만료되기 이전에 사전에 지정된 이메일로 경고 메시지가 보내질 것입니다.

실제로 수동으로 갱신하려면

sudo certbot renew

실행하면 됩니다.

ERROR

위의 도움말에서 5번 과정 - SSL 인증서 가져오기에서 서두의 명령어를 실행했더니 아래와 같은 에러가 발생했다.

(SSL 인증서를 가져올 목적으로 Certbot과 nginx를 사용하기 위한 명령어)

sudo certbot --nginx -d bonster.xyz

Untitled (42)

nginx.conf 파일의 server_name 설정에 동일한 도메인(xxx)가 중복으로 설정되어 있었다.

필자가 위의 에러가 발생한 이유는 별도의 server 블록을 만들어 놓았던 것 때문이므로, 이것을 backup 시키도록 했다.

보통의 경우라면 중복 찾아 제거하면 될 것이다.

Certbot 자동 갱신 확인

Let’s Encrypt의 인증서는 90일 동안만 유효하므로, 90일마다 갱신시켜줘야 한다.

하지만 설치하는 과정에서 /etc/cron.d에 자동으로 갱신시켜주는 커맨드가 추가되어 있다.

다만, 갱신 프로세스가 잘 동작하는지 테스트를 해보고 싶다면 다음과 같은 명령어를 입력해서

테스트를 진행할 수 있다.

$ sudo certbot renew --dry-run

아래는 명령어를 실행한 뒤 화면이다.

Untitled (43)

모든 설정이 끝났다.

이제 certbot이 자동적으로 인증서를 갱신하고, Nginx를 재시작한다. 만약 자동 갱신 프로세스가 실패할 경우, 인증서가 만료되기 이전에 사전에 지정된 이메일로 경고 메시지가 보내진다고 한다.

수동으로 갱신하려면 아래의 명령어를 실행한다.

sudo certbot renew

7. 인바운드 규칙 추가(HTTPS)

HTTP → HTTPS 리디렉션 작업을 성공적으로 수행하기 위해 AWS상에서도 보안 설정을 변경해야 한다.

인바운드 규칙 편집에서 HTTPS를 추가해서 443 포트를 연다.

Untitled (44)

www.ssllabs.com/ssltest/

위의 웹 사이트에서 해당 도메인에 대한 서버 SSL 테스트를 진행할 수 있다.

Untitled (45)

Untitled (46)

크롬을 비롯한 기타 브라우저에서도 인증서가 있는 것으로 확인된다.

서브도메인 적용하기

참조 링크 : https://darrengwon.tistory.com/543

새로운 웹 페이지를 생성한다. mkdir /var/www/[원하는 이름]

root의 처음 설정은 /var/www/html 이다.

필자는 /var/www/{도메인이름}/html 형태의 구조로 셋팅했다.

이렇게 폴더 구조를 만든 다음, 해당 폴더로 이동해서, 아래의 명령어를 실행해서 html 파일을 생성 및 편집한다.

touch virtualtest.html
vim virtualtest.html

755로 권한을 부여한다.

chmod -R 755 /var/www/virtual

dev 도메인과 prod 도메인을 추가로 설정

# dev.bonster.xyz, prod.bonster.xyz 디렉토리를 생성
sudo mkdir -p /var/www/dev.bonster.xyz
sudo mkdir -p /var/www/prod.bonster.xyz

# $USER를 사용하여 디렉토리의 소유권을 설정
sudo chown -R $USER:$USER /var/www/dev.bonster.xyz
sudo chmod -R 755 /var/www/prod.bonster.xyz

신규 디렉토리에 index.html 생성

# index.html 을 열어 html을 작성
sudo vi /var/www/dev.bonster.xyz/index.html
# dev의 index.html 작성 후 prod의 index.html도 작성
sudo vi /var/www/prod.bonster.xyz/index.html

서버 블록 생성

default는 건드리지 않고, 별도의 서버 블록을 생성해 심볼릭 링크를 적용시킬 것이다.

아래의 코드는 prod가 생략되었다.

sudo vi /etc/nginx/sites-available/dev.bonster.xyz
server {
        listen 80;
        listen [::]:80;

        root /var/www/dev.bonster.xyz;
        index index.html index.htm index.nginx-debian.html;

        server_name dev.bonster.xyz;

        location / {
                try_files $uri $uri/ =404;
        }
}

심볼릭 링크 생성

sudo ln -s /etc/nginx/sites-available/dev.bonster.xyz /etc/nginx/sites-enabled/

해시 버킷 메모리 문제 대비

해시 버킷 : 해시 테이블 내부에 있는, 실제 값이 저장되는 장소

sudo vi /etc/nginx/nginx.conf

Untitled (47)

중간에 보이는 server_names_hash_bucket_size 에 대한 주석을 해제한다. 위 캡쳐 사진은 주석을 해제한 상태이다.

지금까지 진행한 것에 문제가 없는지 확인

sudo nginx -t

적용을 위해 재시작

sudo systemctl restart nginx

호스팅케이알(도메인 관리 서비스) 내 설정하기

호스팅케이알 웹 페이지의 메뉴얼을 보고 설정한 값은 아래와 같다.

Untitled (48)

결과

Untitled (56)

앞의 과정을 응용하면, 서브도메인에도 발급된 인증서를 가지고 SSL 세팅값을 부여할 수 있다.

아주 간단하다. certbot 명령어를 활용해 보자. 위에서 한 것과 같이 서브도메인의 url을 명시한 뒤 명령어를 실행하면 되더라.

이렇게 서브도메인 prod와 dev에도 모두 SSL 인증서를 적용했다.

덧붙이자면, 속도때문에 SSL은 로그인이나 회원 가입등 일부 부분에서만 사용한다고 한다. 네이버에서도 일부분만 적용한다고 한다.

리디렉션 적용하기 (HTTP → HTTPS)

server {
    if ($host = bonster.xyz) {
        return 301 https://$host$request_uri;
    } # managed by Certbot

        listen 80 ;
        listen [::]:80 ;
    server_name bonster.xyz;
    return 404; # managed by Certbot
}

위와 같이 https로 return 해주면 된다.

Certbot이 알아서 해주던데… 바꾸기 위해서 vi 편집기로 파일을 열고 보니 별도의 작업이 필요가 없다. 시무룩..

서브도메인에서도 http→ https 리디렉션이 정상적으로 적용이 되고 있다.

서브도메인에 웹 페이지 만들기

별다른 목표가 없어서 테스트 겸, 재미 삼아 겸 아래와 같이 간단히 만들었다.

하나는 문장 하나뿐이고, 하나는 아는 분들의 닉네임으로 구성된 룰렛이다. 누르면 돌아간다.

Untitled (50)

Untitled (51)

룰렛 소스는 아래의 링크에서 사용했고 나름 수정했다.

https://m.blog.naver.com/sgj4958/221865512339

What I learned

AWS의 root사용자와 IAM(Identity and Access Management)에 대해서

Untitled (52)

IAM 사용자 계정을 이용해서 각 사용자 별로 필요한 접근 권한만 줄 수 있다.
여러명이 하나의 계정을 공유하거나 할 일이 없어지는 것이다. 보안이 강화된다.
IAM 사용자 계정에 Full Access Permission을 주면 루트 사용자과 같은 효과를 낼 수 있다.
그리고 그 계정으로 다른 IAM 계정을 관리한다면 루트 사용자 계정을 사용하지 않아도 된다.
루트 사용자만 사용할 수 있는 권한이 존재하므로 필요시만 로그인한다.
이것 역시 보안이 강화되는 효과를 볼 수 있다.

AES : 의 약자로 ‘고급 암호화 표준’라는 의미이고, 미국 표준 기술 연구소에 의해서 연방 정보 처리 표준으로 지정된 암호화 방식 AES-128, AES-192, AES-256로 불리고, 숫자는 각각 암호화 키 길이이고 키에 따라 각 10, 12, 14 라운드를 실행한다.

TKIP : 임시 키 무결성 프로토콜(Temporal Key Integrity Protocol, TKIP), IEEE 802.11의 무선 네트워킹 표준으로 사용되는 보안 프로토콜

WPA (Wi-Fi® Protected Access) : 무선 환경을 위한 데이터 암호화 기술 PSK(Pre-shared Key).말 그대로 사전 공유키

Secure shell (SSH) : 네트워크 상의 다른 컴퓨터에 로그인하거나 원격 시스템에서 명령을 실행하고 다른 시스템으로 파일을 복사할 수 있도록 해 주는 응용 프로그램 또는 그 프로토콜을 가리킨다.

암호화 알고리즘 정리, 시간이 있으면 복습 해 두도록 하자.

Untitled (53)

RSA, ed25519 차이는??

Today, the RSA is the most widely used public-key algorithm for SSH key. But compared to Ed25519, it’s slower and even considered not safe if it’s generated with the key smaller than 2048-bit length. The Ed25519 public-key is compact. It only contains 68 characters, compared to RSA 3072 that has 544 characters.

아래의 웹 사이트 링크를 참조한다. https://security.stackexchange.com/questions/90077/ssh-key-ed25519-vs-rsa

apt-get install과 직접 설치의 차이점

환경변수 PATH에 실행파일 경로 설정, init데몬에 등록하는 일 등을 대신 해주는가, 그렇지 않는가에 있다. “apt-get install” 명령어 하나로 모조리 세팅해 주는 것이 apt-get 직접 설치는 이 모든것을 직접 해주어야 하는 방식이다.
소스 컴파일을 마쳐서 끝나는 문제가 아니고, 수동 설치시 해당 서비스가 의존관계를 가진 라이브러리를 모두 찾아가서 다운로드 해야하므로, 배포판마다 패키지 관리를 편하게 하기 위한 프로그램을 만들어 주는데.. 그게 apt-get의 정체이다.
우분투에 탑재되는건 dpkg로 apt-get 명령어역시 dpkg가 패키지를 관리해준다. 사용자가 할 일을 프로그램이 대신 해주는 심엔ㄷ.. 이 dpkg 패키지 관리 프로그램은 생각보다 똑똑해서 의존라이브러리도 알아서 다 다운받아주고 설정해주고 사용자가 할일이 거의 없게 다 알아서 셋팅해준다. 환경변수까지 모조리 싹~ 다 해준다. 그리고, 시작시 자동 실행이 되라고 init데몬에 올려주기까지 한다.
아래의 웹 사이트 링크를 참조한다. https://forum.ubuntu-kr.org/viewtopic.php?t=25859
dpkg(Debian Package): 데비안 패키지 관리 시스템의 기초가 되는 소프트웨어이다. dpkg 명령어가 . deb 패키지의 설치, 삭제, 정보 제공을 위해 사용된다. dpkg 그 자체는 저레벨의 도구이며, APT와 같은 고급 도구들이 복잡한 패키지 관계와 패키지를 원격에서 받아오는 등의 일을 한다.

dpkg와 apt-get의 차이점

dpkg는 해당 패키지만 설치를 진행하고 해당 패키지에 종속되서 설치되야하는 프로그램을 같이 설치해주지는 않는다. 이 문제는 apt-get이 해결해준다.
apt-get(Advanced Packaging Tool) apt-get역시 dpkg를 사용하여 실제 패키지 설치를 수행하다. 수행 방식은 아래 이미지를 참조할 수 있다.

Untitled (54)

저장소의 url가 /etc/apt/sources.list 에 작성되어있다면 인터넷을 통해서 해당 저장소에서 파일을 다운로드해서 설치한다. 이 방식은 dpkg와 달리 종속된 프로그램이 만약 피씨에 미설치되어있다면 추가 수동설치 필요없이 자동으로 설치해준다.
네임서버(DNS: Domain Name Server)는 대표적으로 IP 주소와 도메인 주소를 연결해주는 역할을 한다. 인터넷 주소창에 도메인을 입력할 때 도메인 등록 시 지정된 네임서버를 통해 해당 도메인과 연결된 IP 주소를 확인하여 연결하게 된다. 따라서 도메인 등록시에 네임서버를 지정하고, 해당 네임서버에 연결 설정을 해야 정상 이용이 가능하다.

return 301 : ip 주소로 접근하면 return 301 응답으로 도메인으로 이동된다. 301 응답은 영구적인 URL 리다이렉션을 의미한다.

리눅스의 권한 분류

읽기 Reading - 4
쓰기 Writing - 2
실행 Executing - 1

만약 777의 권한이 부여되었다면 각각의 7은 (4 + 2 + 1)을 의미한다. 즉 읽고 쓰고 실행 모두 가능하다는 의미이다.

처음의 7 - 소유자 권한

두번째의 7 - 그룹 사용자 권한

세번째의 7 - 기타 사용자 권한

Q/A**) 만약 755의 권한이라면 어떤 권한을 가지는 것일까?**

755는 소유자만 모든 것(쓰기, 읽기, 실행)이 가능하고 그 외 사용자의 경우는 읽기, 실행은 가능하나 쓰기는 불가능하다.

chmod를 사용한 권한 부여방법

파일 또는 디렉토리(폴더)에 권한을 부여, 수정하는 방법은 아래와 같다.

모든 권한 읽기, 쓰기, 실행을 부여

sudo -s // root 권한 얻기

chmod -R 777 filename

모든 파일 또는 폴더의 권한을 한번에 바꾸는 방법

find 키워드를 사용하면 가능하다.

find /test -exec chmod 755 {} \;

/test 경로에 위치한 모든 파일 및 폴더의 권한을 755로 변경한다.

폴더 또는 파일의 권한만 모두 변경하는 방법

find /test -type f chmod 755 {} \;

폴더만 변경하려면 아래와 같이 type 값을 f로 바꾼다.

find /test -type f chmod 755 {} \;

sites-enabled과 sites-available의 차이는 무엇인가

apache에서도 위와 같은 이름의 파일이 존재하는데 같은 관계이다.

sites-available은 서버에서 운영할 사이트의 설정 파일이며

sites-enabled은 sites-available에 설정한 파일을 심볼릭 링크로 추가하여 실제 운영에 사용할 설정파일들이다.

SOLVED ERRORS

ERROR

도메인 관리 사이트에서 TXT에 토큰을 입력해서 추가했으나 여전히 같은 현상 반복,

위의 이슈를 해결하기 위해 다방면으로 시도해 보았으나, 여러번 시도 하니 아래의 에러가 발생

Untitled (55)

설명 : SSL 발급 요청을 너무 많이 했는데 모두 유효하지 않은 요청이라 악의적이라 판단해서 해당 도메인에 대해 발급 요청이 일시 중단된 상태이다(1시간 가량 기다린 후에 다시 진행 해야함)

검색을 거듭하던 중 발견한 와일드 카드 사용을 비추천 하는 것에 대한 글이 있었다.

짐작되는 원인은 도메인 관리 사이트의 레코드가 실시간 반영되지 않아서 인 것 같다. 조금 더 시간적 간격을 두고 해봐야 겠다는 생각이 들었다.

회고

감사하게도, 구글링을 해보니 참으로 좋은 글과 소스가 많아서 별 문제없이 과정을 수행한 것 같다.

우선 가상호스팅을 사용하고 있으므로 보안 차원이라도 SSL을 적용하는게 좋을 것 같고

SSL 적용후 속도 저하라던지는 아직 없기 때문에 현재로선 문제는 없다.

하지만 나중에 다른 환경에서 개발하게 된다면 개선을 고민해볼 필요는 있겠다.

서버를 구축하고 AWS상에 서비스하기

목표

진행 상황

외부에서 접속하기: phpinfo 띄우기 (by 포트포워딩)

외부에서 접속하기 위한 포트포워딩 설정

phpinfo 띄우기

AWS 서버 구축 / Linux + Nginx PHP MySQL

AWS 서버 생성

AWS 서버 접속

Mysql 외부에서 접속하기

MySQL에 접근하기 위한 유저 만들기

데이터베이스 접근 권한 주기

MySQL 외부 접속 설정

php myadmin 설치

도메인 구매하고 적용하기(호스팅케이알 이용)

Let’s Encrypt 적용하기

Let’s Encrypt SSL 인증서 발급 방법 4가지

3, 4를 시도해 보았으나 도중에 적합하지 않다는 생각이 들어 중단했는데 이유는 다음과 같다.

문제점은 아래와 같다.

와일드카드 사용을 지양하는 이유 , 읽을거리

세 줄 요약

웹서버에서 Let’s Encript로 SSL 인증서 발급하기

Let’s Encript란

1. Nginx 설치

2. 방화벽 설치(AWS 쓰고있으면 Skip)

웹서버 확인

3. 서버 블록 설정하기

/etc/nginx/nginx.conf 에서 해시 버킷 메모리 문제 해결하기

Nginx 설정이 잘됐는지 확인하기

4. Certbot 설치

5. SSL 인증서 가져오기

6**. SSL 자동으로 갱신시키기**

ERROR

Certbot 자동 갱신 확인

7. 인바운드 규칙 추가(HTTPS)

서브도메인 적용하기

dev 도메인과 prod 도메인을 추가로 설정

신규 디렉토리에 index.html 생성

서버 블록 생성

해시 버킷 메모리 문제 대비

지금까지 진행한 것에 문제가 없는지 확인

적용을 위해 재시작

호스팅케이알(도메인 관리 서비스) 내 설정하기

결과

리디렉션 적용하기 (HTTP → HTTPS)

서브도메인에 웹 페이지 만들기

What I learned

AWS의 root사용자와 IAM(Identity and Access Management)에 대해서

RSA, ed25519 차이는??

apt-get install과 직접 설치의 차이점

dpkg와 apt-get의 차이점

리눅스의 권한 분류

chmod를 사용한 권한 부여방법

sites-enabled과 sites-available의 차이는 무엇인가

SOLVED ERRORS

ERROR

회고

Refference

`/etc/nginx/nginx.conf` 에서 해시 버킷 메모리 문제 해결하기

6. SSL 자동으로 갱신시키기