[16일 차] 21.08.10 : Windows Server 5

 

두통은 좀 남아있긴 하지만 많이 나아졌다. 오늘은 수업 듣는데 이상이 없을 것 같다.

 

오늘은 실습이 특정 웹 서비스를 체험하는 방식이 많았는데, 대충 "이러한 방향으로 설정한다" 정도만 기억하면 된다.

각 제품의 설정 방법을 세세하게 알아둘 필요는 없다.

---

• 웹하드 : 구글 드라이브 같은 것. 웹을 통해 서버에 파일을 접근/저장/다운로드

 

WPI, IIS, PHP 설치

※ PHP 설치 확인 : 기본 경로에 phpinfo 테스트 파일 만들어서 접속해보기.

-> phpinfo.php : <? php phpinfo(); ?>

-> PHP는 버전에 민감해서 보통 수동 설치. 버전이 바뀌면 호환성이 망가지는 경우가 허다하다.

 

* 에러 코드가 뜨면 어디에서 문제가 발생한 것인지 인지할 수 있어야 한다.

-> 예를 들면, 500이 떴다면 서버의 파일에 문제가 생긴 것임을 알아차려야 한다.

 

* 어제처럼 뭐 파일을 기본 경로에 갖다 놓고 접속할 때, 항상 기본 경로 확인할 것.

-> 이번에는 웹하드 목적으로 설치하는 것이니, 해당 폴더에 불특정 다수가 접근/수정/쓰기가 가능해야 한다.

-> 파일 속성> 보안에서 IUSR 그룹 추가 및 모든 권한 허용

-> C드라이브의 Windows> Temp 폴더에도 동일하게 추가/권한 허용. 임시 파일이 저장되는 경로다.

Temp 폴더 : 모든 파일마다 해당 사용자/그룹의 권한이 있는데, 여기 있는 파일들은 스스로 지워진다. 불특정 다수가 파일을 읽고 나갈 때 생기는 파일 정보/쿠키 파일 등의 세션 정보가 이 디렉터리에 남았다가 스스로 삭제된다.

 

웹하드 실습은 pydio 웹하드 구현

-> 자바, mysql, php 설치 후 대충 설치 과정 따라가기

-> 설치 완료 후 우측 상단의 메뉴> 설정으로, 좌측 메뉴의 People>새 사용자로 사용자 등록

-> 어제와 마찬가지로 업로드 용량 제한이 있다. 어제처럼 용량 확장 과정을 거친다.

 

온프레미스 웹하드가 요즘은 클라우드로 옮겨간 것.

클라우드의 실체는 클러스터의 집합인데, 거기에 조각나서 저장되는 것이다. 여기에서 가상화나 저장소의 개념이 적용되는 것.

클라우드 저장소

-> 웹 서버, PC, 회사 컴퓨터, 스마트폰 등이 인터넷으로 연결되어 있고

-> 서버/집/회사에 있는 파일들이 서로 동기화를 거치고

-> 인터넷을 통해서 주고받고

-> ownCloud 실습

 

ownCloud와 PHP 호환성 관련 설정 : 중요한 것은 아님

압축 풀고 권한 설정하고 -> IIS 관리자> 처리기 매핑> PHP55_via_FastCGI> 요청 제한> 동사>모든 동사, 로 변경 후 확인> 실행 파일 경로 " "로 묶어주기> 서버 재시작

접속 후 초기 설정> 우측 상단의 admin> 사용자> 정보 입력하고 만들기, 로 새로운 사용자 추가> 그룹 관리자/할당량 조정 가능

얘도 웹하드처럼 용량 설정해줘야 한다. 업로드해보기> 여기까진 웹하드와 동일.

공유> 링크 공유로 링크를 통한 공유 가능.

클라이언트 측에 프로그램을 설치해 웹서버에 있는 사용자의 폴더와 사용자 PC의 지정 폴더 간의 동기화 가능

 

* PHP 수동 설치 : WPI로는 설치가 안될 수 있다.

통으로 설치하려고 하니 IIS 관리자에서 FIRST 진입> 처리기 매핑> PHP55~> 좌측의 모듈 매핑 추가

-> 요청 경로(*. php), 모듈(FastCgiModule), 실행 파일(php-cgi.exe), 이름(PHP 5.4_via_FastCGI)

-> 테스트하려면 기존 PHP55는 잠금

 

 

이제 https, DNS로 넘어간다.

 

내가 보는 화면이 그 서버에서 온 것이 맞을까?

7 계층 http는 평문 데이터를 전송. 4, 5 계층 사이에 SSL/TLS라는 보안 계층을 삽입해 http 평문 데이터가 이 보안 계층을 지나게 해서 암호문으로 바꾸는 것이 https. 인증 동작(서버 인증)과 암호화 동작 제공

인증

-> 비대칭 키 알고리즘 사용 - 개인 키(암호화 목적), 공개 키(복호화 목적)

인증서

-> CA(Certificate Authority)의 개인 키로 사용자의 공개 키를 암호화. 은행에 저장된 CA의 공개 키로 복호화,

-> CA의 개인키 + 사용자의 공개키 = 공인인증서

 

• HTTPS 작동 원리 : SSL/TLS의 프로세스

1단계(Hello 교환)

1. SSL 핸드 셰이크 과정은 먼저 클라이언트가 서버에게 Client Hello 메시지를 송신.

2. 이 메시지 안에는 서버가 SSL을 사용해 클라이언트와 연결하기 위해 필요한 모든 정보, 즉 암호화 알고리즘의 종류와 지원이 가능한 SSL 버전 정보가 포함되어 있다.

3. 서버는 이에 대해 비슷한 정보가 포함된 Server Hello 메시지를 송신, 이 메시지에는 클라이언트와 같이 사용할 암호화 알고리즘 및 SSL 버전 정보가 포함되어 있다.

 

2단계(인증서 교환)

1. 서버는 자신의 신분을 증명할 SSL 인증서를 클라이언트에게 송신.

2. 이 SSL 인증서는 소유자의 이름, 서버의 공개키, 전자서명 및 그 유효기간 등의 정보가 포함되어 있다.

3. 클라이언트는 이 인증서가 신뢰할만한지를 검증한다(CA의 공개키로).

4. 서버도 클라이언트의 신분 증명을 위해 인증서를 요구한다(대부분 이 부분 생략).

 

3단계(키 교환)

1. 클라이언트는 DES, AES와 같은 대칭키 알고리즘을 사용해 임의의 키를 생성하고, 이 키를 서버의 공개키로 암호화해서 서버로 송신.

2. 서버는 자신의 개인키를 사용하여 수신된 이 임의의 키를 복호화한 후에 데이터 전송 시 복호화된 이 대칭키로 암호화해서 클라이언트에게 전달.

강사님이 그려주신 그림으로 보는 3단계 설명

 

강사님의 그림설명

• 암호화 : 개인키(복호화), 공개키(암호화) -> 수신 측이 가지고 있다

송신 측이 요청하면 수신 측이 공개키를 송신 측에게 전달

->송신 측은 메시지와 공개키, 합의한 암호화 알고리즘으로 암호문 생성

->수신 측은 전달받은 암호문을 동일한 암호화 알고리즘에 암호문과 개인키를 넣어 평문으로 복호화.

 

• 인증 : 개인키(암호화), 공개키(복호화) -> 송신 측이 가지고 있다.

송신 측(서버/은행 등), 수신 측(웹 브라우저, 사용자 등)이 있을 때, 송신 측이 개인키와 공개키를 만든다.

-> 이 공개키에는 CA의 개인키로 서명(암호화)이 되어 있다(인증서).

-> 송신 측은 그렇게 처리가 되어있는 공개키를 수신 측에게 전달.

-> 송신 측은 비대칭키 암호화 알고리즘에 개인키와 평문을 넣어 암호화(서명), 뽑힌 암호를 전송.

-> 수신 측은 송신 측과 동일한 알고리즘에 이 암호문과 송신 측이 미리 보냈던 송신 측의 공개키를 넣어 평문으로 복호화.

-> 복호화에 성공했다면 인증 성공!

인증서는 데이터를 암호화할 목적으로 사용하는 것이 아니다. 인증이 목적.

 

개인키

인증서 => 서버의 공개키를 CA의 개인키로 전자서명

 

• HTTPS 구성 순서

1. 인증서 생성

   /etc/pki/tls/certs

1-1. 개인키 생성(htp.key)

1-2. 요청 서키 생성(http.csr)

1-3. 개인키+요청 서키 인증서 생성(http.crt)

2. ssl.conf 설정

3. 테스트

 

• 윈도 서버 2016 HTTPS 서버 구성 단계

1. 인증서 생성(위 1-1~3 단계)

2. 인증서 설정

3. 웹사이트에 인증서 등록(HTTPS 서버 구성)

4. 확인

 

1. IIS 관리자> FIRST> 서버 인증서> 우측의 인증서 요청 만들기,를 원래 해야 하지만 좀 까다로워서 간단하게 하기 위해 자체 서명된 인증서 만들기 선택> 인증서 이름 지정(확장자. ssl), 저장소(개인)>여기까지로 인증서 생성/설정 끝

2. 인증서 등록을 위한 웹사이트 만들기. 좌측의 사이트 우클릭> 웹 사이트 추가(사이트 이름은 대충 wwwssl, 경로 대충 지정, 바인딩-종류는 https, 간이로 만들었던 인증서 등록)> 사이트 들어가 보면(https://127.0.0.1/) 인증서에 문제가 있다고 뜬다. CA에 등록하지 않고 간이로 했으니 당연한 것. > 무시하고 들어가면 인증서 오류가 난 상태로 진행.

 

https 실습 끝.

 

 

• DNS 실습 : 도메인 통신. IP 말고 문자로 주소 기억하기

리눅스 때 자세히 하고, 윈도에서는 간단하게. 

리눅스는 /etc/hosts에, Windows에서는 C:\Windows\System32\drivers\etc 밑의 hosts 파일에 주소들 매핑을 쭉 기록. 메모장으로 열어보면 쓰여있는데, 주석 처리로 되어있는 건 사람 보라고 써놓은 것.

 

 

캐싱 DNS 서버 구현 실습

 

도메인 이름 체계 = 디렉터리 서비스 = 체계화

하나의 DNS 서버가 모든 것을 저장할 수는 없다. 분산 저장.

루트 DNS 서버에서 최상위 도메인을 관리, 요청이 오면 최상의 도메인을 관리하는 DNS 서버를 알려주고...

크게 루트, 로컬, 캐시 DNS 서버로 구분하는데...

 

서버 관리자> 기능 추가> DNS Server 체크>쭉 진행

제어판> Windows 방화벽> 좌측의 앱이 ~허용 어쩌고, 에서 DNS 체크되었는지 확인

서비스> DNS Server 실행 중인지 확인

이더넷 설정> 설정> dns 서버 주소 설정

 

DNS는 TCP, UDP 모두 사용한다. 일반적으로는 UDP를 쓰지만, 마스터 DNS 대신 슬레이브 DNS가 답변할 때 마스터에게 있는 zone 파일을 동기화할 때 TCP 사용. 대신 포트는 다름

 

내일은 종합 실습 : VM 2개로 DNS 서버와 웹 서버 구현.

SECOND : 웹 서버 ownCloud와 FTP 서버 구성

FIRST : soldesk.com이라는 도메인을 가진 DNS 서버

WINCLIENT에서 문자 주소로 접속할 수 있도록

---

실습이 많은 수업이다 보니 세팅하는데 최소 1교시는 날아가는 것 같다.

수강생들의 실력 탓이라기보단 비대면 수업으로 인해 실습 환경이 제각각인 것이 주원인...

이상 생기면 강사님이 훌쩍 가서 봐주면 되던걸 원격 접속이나 텍스트 설명으로 해결해야 하니 번거롭긴 하다.

 

3교시 중반의 설명 다시 듣기, 6교시 인증 관련 다시 듣기, 8교시의 DNS 다시 듣기