도커 실행해보기(Execute Docker)

이번 포스트에서는 도커로 서비스하는 과정을 실습해보도록 하겠다.

앞의 글에서도 설명 되어있듯이, 도커 가상화에서는 각자의 서비스 실행됨에 있어서

"운영체제 설치 > 소프트웨어 설치 > 서비스 ..."등의  빌드 과정이 필요없이

서비스만 단독적으로 실행이 가능하다는 점이 존재한다고 했다.

 

그 예시로 웹 개발, 서버에 관한 공부를 하는 분들에게는 익숙할 수 있는 웹 엔진 "NginX"

도커 컨테이너 가상화를 통하여 서비스하는 과정에 대한 실습을 진행해보았다.

 

 

* 실습환경 : Intel i7-1260P(AMD64) /  VMWare Workstation 16

** 네트워크 대역 : 192.168.100.0/24

*** 해당 실습에서 사용된 가상머신 : Ubunser(.99), CentOS7(.140)

**** 실습 중 "docker" 커맨드가 alias = "dkr" 로 사용되었음

 

 

● 도커를 활용한 웹 서비스

Docker NginX

먼저 Docker를 이용하여 웹 서비스를 제공해줄 가상머신(필자기준 Ubunser)에서

"sudo docker run -p 8080:80 -d --name "NewNgin" nginx:latest" 명령으로

"nginx:latest" 태그에 해당하는 도커 이미지가 로컬에 존재하지 않는다면 

Docker Registry에서 Pull하여 자동으로 실행되게 된다.

** Docker Registry는 로컬이 될 수도 있고, Docker Hub와 같은 네임드 레지스트리일 수도 있다.

 

"-p 8080:80" 옵션의 의미로는 현재 도커 위에서 실행되는 컨테이너에는 

각자의 IP주소를 부여받지 않았기 때문에 나의 호스트 머신(Ubunser)의 8080포트로 요청 전송 시,

컨테이너로 실행되는 웹 서비스로 Redirect 해주기 위해서 위와 같은 옵션이 사용되었다.

* 외부(External) 요청 포트번호는 임의적으로 지정해주어도 된다.

 

"--name [Name]" 옵션을 이용하여 새롭게 생성할 컨테이너에 이름을 부여하여 

보다 편리한 관리를 가능하게 해준다.

 

 

Docker NginX

"sudo ss -nltp | grep LISTEN" 명령어를 이용하여 도커 컨테이너(프로세스) 생성 시 지정한 포트가

LISTEN 상태가 되어있는 지 확인해본다.

 

 

Docker NginX

"sudo docker ps" 명령어를 이용하여 현재 실행되고 있는 컨테이너 목록을 확인할 수 있으며,

앞에서 생성한 "NewNgin" 컨테이너가 외부(External) ANY(0.0.0.0)로 부터 8080 포트로 요청 시 -> NginX(80)컨테이너가

응답할 수 있도록 Port Redirect가 설정된 채로 생성 되어있는 것을 확인해볼 수 있다.

 

 

Docker NginX

"firefox http://localhost:8080" 명령을 이용하여 우선 로컬(Ubunser)에서 먼저 접속을 시도해보면,

위의 그림과 같이 생성된 NginX 컨테이너가 정상적으로 응답하는 모습을 확인해볼 수 있다.

 

 

Docker NginX

다음으로 외부에서 접근 시에도 정상적으로 서비스가 이루어지는가를 확인하기 위해

별도의 가상 머신(CentOS7)에서 "firefox http://192.168.100.99(Ubunser의 주소):8080" 

입력하여 웹 사이트 요청을 진행했을 때에도 정상적으로 NginX의 Default 페이지가 출력되는 것을 확인해볼 수 있다.

 

 

● 도커 볼륨(Docker Volume)

도커에서 각종 이미지를 기반으로 한 컨테이너(APPs, OS, DB ...)가 실행될 때 해당 다양한 내용들에 대한

수정 / 변경이 발생하게 되는데, 실행되고 있는 컨테이너의 상태는 그저 메모리(Volatile)에 적재되어 실행되는

프로세스에 불과하기 때문에 작업이 종료되어 컨테이너를 삭제하게 되면 그간 작업했던 내용들도 함께 삭제가 된다. 

이런 부분을 보완하기 위해서 사용되는 것이 바로 컨테이너 <-> 호스트 간 저장공간을 공유하는 도커 볼륨이다.

 

 

Docker Volume

먼저 도커 볼륨의 동작 방식을 직접 확인해보기 위해서 임의의 경로에 index.html 파일을 생성해두었다.

 

Docker Volume

새로운 컨테이너 생성 시 공유될 볼륨을 지정한 상태로 진행

 

sudo mkdir /home/[UserName]/Desktop/website && su -c "echo \"<h1>This is Docker Site</h1>\" > /home/master/Desktop/website/index.html

# 컨테이너와 공유될 디렉토리를 새롭게 생성한 뒤, NginX에서 표현될 HTML 코드를 간단하게 작성한 뒤 저장


sudo docker run --name [ContainerName] -v ${pwd}:/usr/share/nginx/html:ro -p 10000:80 -d nginx:latest

# [ContainerName] 이름의 컨테이너를 생성하는 과정으로, 
# -v 옵션으로 상호간 연결시켜줄 디렉토리의 경로를 지정해준다.
# ${pwd} -> 현재 호스트(Ubunser)머신에서 작업중인 디렉토리를 공유하겠다는 의미이며,
# 경로지정은 상대적인 요소로 필자의 경우 현재 위치를 공유하기 위해 ${pwd} 환경변수를 이용함
# :/usr/share/nginx/html -> 컨테이너의 ~html 디렉토리에 공유된 데이터 볼륨을 마운트한다는 의미로,
# 현재 ${pwd} 경로에는 index.html 파일이 저장 되어있다.
# :ro -> 읽기 전용(Read Only)로 실행되는 것을 의미한다.
# -p 10000:80 -> 외부(External) 요청 포트번호는 임의의 숫자 10000을 부여해주었다.
# 도커 이미지는 nginx:latest를 사용하였다.

 

 

Docker Volume

"firefox http://localhost:10000" 를 입력하여 접속 시, 

호스트머신에서 생성 후 호스트머신에 저장되었던 HTML 문서가

도커 볼륨 설정으로 인해 컨테이너에서 해당 웹 페이지를 서비스 해주는 것을 확인해볼 수 있다.

 

 

Docker Volume

좀 더 직관적으로 구조를 확인해보기 위해서 

"sudo docker exec -it [Container Name] bash"를 입력하여 실행되고 있는

컨테이너의 Shell 로 진입한 뒤, 컨테이너에서 파일을 생성한 뒤 저장을 했을 때,

호스트 머신의 저장공간에 컨테이너 안에서 생성한 파일이 저장 되어있는 것을 확인할 수 있었다.

 

 

▼ Docker & Bootstrap Template을 활용한 반응형 웹 페이지 서비스

Docker & Bootstrap

웹 서비스를 제공할 호스트 머신(Ubunser)에서 

"firefox http://startbootstrap.com/"를 입력하여 해당 Bootstrap 웹 사이트에 진입해본다.

 

Bootstrap은 유료 및 무료(MIT License) 디자인 템플릿을 제공해주는 프레임워크로,

공개 되어있는 반응형 웹 페이지를 컨테이너에 적재하여 서비스하는 것을 구현하고자 사용하였다.

 

해당 사이트 진입 후 본인 입맛에 맞는 공개된 웹 페이지의 코드를 다운로드하여 

호스트 머신에 저장을 한 뒤 실습을 진행한다.

 

해당 포스트에서는 첨부 자료가 생략되었지만 템플릿 다운로드 후,

~/Download 경로에 저장된 아카이브를 "unzip" 으로 해제한 뒤,

 

기존 도커 볼륨으로 사용중인 "/home/master/Desktop/website/~" 디렉토리 아래로 옮겨주었다.

* 필자 기준

 

 

Docker & Bootstrap

sudo docker run --name [ContainerName] -v ${pwd}:/usr/share/nginx/html:rw -p 8080:80 -d nginx:latest

# -v{pwd} -> 컨테이너와 공유할 위치를 지정
# :/usr/share/nginx/html -> NginX 컨테이너의 마운트포인트
# :rw -> 마운트포인트에 Read, Write를 허용
# 8080:80 -> Redirect 할 Port를 명시
# -d -> 컨테이너를 Daemon(백그라운드) 형태로 실행
# 컨테이너 생성에 사용할 도커 이미지를 지정

위 처럼 Bootstrap 템플릿이 저장 되어있는 디렉토리를 컨테이너와 공유하는 컨테이너를 생성

 

 

Docker & Bootstrap

sudo dkr run --name [Old Container Name] --volumes-from [New Container Name] -p 8081:80 -d nginx:latest

# 위 명령어는 앞에서 먼저 생성된 A(Old) 컨테이너가 도커 볼륨으로 사용중인 호스트 머신의 디렉토리를 
# B(New) 컨테이너에서도 동일한 디렉토리를 사용한다는 의미로, --volumes-from ~ 옵션이 그 역할을 한다.
# Port Redirect는 기존의 컨테이너와 충돌이 발생하지 않도록 한다.

기존 도커 볼륨이 설정 되어있는 컨테이너와 같은 디렉토리를 공유할 수 있도록 공유 경로를 참조하여 컨테이너를 생성할 수 있다.

 

 

Docker & Bootstrap

호스트 머신에서 컨테이너의 정상 작동 여부를 확인하기 위해 

"firefox http://localhost:8081(두 번째로 만든 컨테이너)" 로 웹 사이트를 요청하여 

위의 그림처럼 Bootstrap Template 에서 다운받은 양식의 웹 페이지가 출력 된다면 정상적으로 실행되었음을 확인할 수 있다.

 

물리적인 서버에 웹 서버를 구축 ~ 서비스 하는 과정에 비하면 훨씬 간단하고 가볍게 진행되는 것을 확인해볼 수 있었다.

그에 따른 문제점도 분명히 존재 하겠지만, 전적으로 테스팅 및 공용 프로젝트를 진행하는 환경이라면 사용하지 않을 이유는 없을 것으로 생각된다.

수업을 진행하며 좀 더 깊이 있는 내용을 포스팅 해야겠다.

'Cloud_Virtualization' 카테고리의 다른 글

[Cloud_Virtualizaiton]Build_Docker  (0) 2023.03.13

도커(Docker)

도커 설치에 앞서 도커를 사용하는 이유에 관해서 간단하게 짚어본다.

우리가 도커를 사용하는 가장 큰 목적은 무엇보다 "개발의 편리함""빠른 배포" 일 것이다.

"어느 환경에서나 도커 엔진만 있다면 컨테이너 이미지를 실행하여 동일한 환경을 만들어 준다" 가 위 두 가지 목적의 근거가 될 수 있다.

 

결론적으로 도커란 "서비스 개발 및 편리한 배포"를 위한 도구로써,

2013년에 새롭게 등장한 "컨테이너" 기반의 가상화 도구이다.

 

가상화의 대표적인 두 가지 방법으로는,

 

- Hypervisor Virtualization(하이퍼바이저) :

• Type 1:  

베어메탈(Bare-Metal Hypervisor)라고도 불리우며 아무 것도 설치 되어있지 않은

물리적 하드웨어 위에 하이퍼바이저가 위치하여 N개의 OS를 하이퍼바이저가 관리하는 구조로,

구조상 가상머신과 하드웨어 사이에 별도의 호스트 OS가 없기 때문에 Type 2보다 효율적인 면에서 우세하다고 하여

가상화 서버를 구축할 때 주로 이용된다고 하지만, 구축 및 관리면에서 단점이 존재한다고 한다.

이 베어메탈(Type 1)가상화 방식도 세부적으로 또 한 번 나누어지지만 해당 포스트에서는 다루지 않는다.

 

(좌) Container 가상화 구조의 도식화 / (우) Bare-Metal 가상화 구조의 도식화

 

 

• Type 2:

현재 우리가 공부를 함에 있어서 가장 많이 사용되는 가상화 구조로 호스트 기반 하이퍼바이저(Hosted Based Hypervisor)라고 불리우며

물리적인 하드웨어(PC / Workstation)의 기존의 OS(Windows, MacOS, Linux ...)위에 가상화 소프트웨를 통하여,

해당 소프트웨어가 호스트(Host)와 가상 호스트(Guest)에게 물리적인 리소스를 분리/할당 하여 가상머신을 생성하는 형태를 의미한다.

(VMWare, Virtualbox, UTM(For Mac) ... 등이 이에 해당)

 

(좌) Hosted Based 가상화 구조의 도식화 / (우) Container 가상화 구조의 도식화

 

 

- Container Virtualization(컨테이너 가상화):

리눅스 커널(Kernel)에 기반하여사용되는 가상화 방식으로, 프로세스를 격리해서 실행하고 관리할 수 있도록 도와주며

계층화된 파일 시스템을 기반으로 해서 효율적으로 이미지 API를 프로세스 실행환경으로 구축하게 된다.

앞에서 소개된 가상화 방식과 가장 큰 차이점으로는 VM(가상머신) 이 각각의 프로세스로

존재하기 때문에 호스트 머신의 물리적인 하드웨어를 할당받는 것이 아닌

Linux OS 안에 하나의 프로세스로 존재하게 된다는 것이다.

 

풀어서 말한다면 여타 다른 가상화와는 달리 컨테이너 가상화 서비스에서는

서비스(NginX, Apache, Database ...)가 별도의 운영체제 위에서 실행되는 것이 아닌

그저 시스템이 실행중인 프로세스의 형태로 구동되는 것으로 가볍고 빠르다는 장점이 존재한다.

따라서 리소스에 대한 부담이 감소하게 된다. 물론 이에따른 단점도 분명 존재한다.

 

 

* 실습환경 : Intel i7-1260P(AMD64) /  VMWare Workstation 16

** 네트워크 대역 : 192.168.100.0/24

*** 해당 실습에서 사용된 가상머신 : Ubunser(20.04)

 

 

● 도커 수동 설치(Docker Manual Build)

Build Docker

본격적인 도커 환경 구축에 앞서 VMWare Workstation을 사용하는 독자라면

Setting(가상머신) -> Processors -> 우측 Virtualization Engine -> Virtualization Intel VT-x/EPT or AMD-V/RVI

에 진입하여 체크박스에 체크가 되어있는지 확인해준다.

(체크가 되어있어야 가상화 지원이 가능)

 

 

[Docker Maunual Build]
sudo apt update -y && sudo apt upgrade -y
# 최신 패키지 유지를 위한 레포지토리 업데이트를 진행

sudo apt install -y apt-transport-https ca-certificates curl gnupg-agent software-properties-common 
# 도커환경 구성에 필요한 종속 패키지를 Install

su -c "curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -"
# 외부 저장소에서 Install 해줄 Docker 패키지의 무결성 검증을 위한 Key를 추가

sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
# Docker 패키지를 다운받기 위한 레포지토리를 임의로 추가

sudo apt update -y
# 추가된 레포지토리 적용을 위한 업데이트

sudo apt install -y docker-ce docker-ce-cli containerd.io 
# Docker 실행에 필요한 구성 패키지 다운로드

 

 

/etc/docker/daemon.json 파일의 내용

 

sudo vim /etc/docker/daemon.json
# Docker 데몬을 새롭게 생성해주기 위해 에디터로 파일을 편집

[편집 내용]
{
        "exec-opts" : ["native.cgroupdriver=systemd"],
        "log-driver" : "json-file",
        "log-opts" : { "max-size" : "100m" },
        "storage-driver" : "overlay2"
}
# json 포맷으로 파일을 작성해주었으며, 오타에 유의하여 작성

sudo mkdir -p /etc/systemd/system.docker.service.d
# rootless 모드에서 사용될 디렉토리를 새롭게 생성

sudo systemctl daemon-reload && sudo systemctl restart docker && sudo systemctl enable docker.service
# 새롭게 생성된 데몬 적용을 위해 reload, Docker 서비스를 재시작하여 Service Status를 확인

 

 

Build Docker

"systemctl status ~" 커맨드를 이용하여 도커 서비스의 작동 여부를 확인한다.

(Error 발생 시 경험 상 대부분의 문제가 앞에서 json 포맷으로 작성한 데몬파일인 경우가 많았으니 이 부분 참고)

 

 

Build Docker

필자는 alias를 사용하여 "docker"를 "dkr"로 줄여서 사용함

기존 명령어는 "sudo docker run hello-world"

 

위의 그림을 확인해보면

내가 구축 한 도커의 로컬 영역에 "Hello World"라는 이미지가 존재하지 않기에

Docker Image를 도커의 Default Regitstry "https://hub.docker.com/" 경로에서 Pull 하여

가져오는 것이 확인되면 정상적으로 도커 엔진이 설치된 것

'Cloud_Virtualization' 카테고리의 다른 글

[Cloud_Virtualization]Execute_Docker  (0) 2023.03.14

암호 재설정 디스크(Password Reset Disk)

윈도우 시스템 사용 중 비밀번호를 분실하여 시스템에

접속하지 못 하는 경우가 발생할 수도 있는데,

 

이런 경우를 대비하여 미리 외부 저장장치(USB, 외장 HDD, SDD...)등에 

*.psw(Windows Password Reset Disk File)형식의 

파일을 저장하여 해당 파일로 암호 재설정을 할 수 있도록

인증해주는 방식이다.

 

 

* 실습환경 : Intel i7-1260P(AMD64)

** 네트워크 대역 : 192.168.100.0/24

*** 해당 실습에서 사용된 가상머신 : WinSer1(.200)

 

 

● 암호 재설정 디스크 만들기

Password Reset Disk

먼저 해당 실습이 원격지에 있는 윈도우 시스템에서 진행되었기에

물리적인 USB를 실제로 삽입 및 제거가 어려워

임시적으로 가상머신의 플로피디스크를 추가하여 진행하였다.

 

 

Password Reset Disk

암호 재설정 디스크를 생성하는 작업을 진행하면

외부장치(플로피 디스크)에 암호 키가 들어가기 때문에

부팅에 영향을 주지 않도록 사전에 부팅 시퀀스(Hard Drive First)를 변경해주었다.

 

 

Password Reset Disk

작업 시작 전 빠른 포맷을 체크하여 새롭게 추가된 외장 디스크 포맷을 진행해준다.

(위 그림에서는 플로피디스크로 실습을 진행하여 FAT 시스템으로 포맷을 진행함)

 

 

Password Reset Disk

'제어판' -> '사용자 계정' -> '좌측 상단의 암호 재설정 디스크 만들기' 클릭

 

 

Password Reset Disk

암호 기억 마법사의 진행 양식에 맞추어 작업을 진행하다보면,

암호 키가 저장 될 디스크를 지정할 수 있는 선택창이 나온다.

 

 

Password Reset Disk

현재 로그온 되어있는 사용자의 패스워드를 입력

 

 

Password Reset Disk

절차대로 진행 시 완료 되었다는 알림과 함께 마법사가 종료된다.

 

 

Password Reset Disk

외부 저장장치의 스페이스를 확인해보면,

암호 키가 추가된 것을 확인할 수 있다.

 

 

● 실제 사용 예시

Password Reset Disk

 

암호 재설정을 위하여 "암호 초기화..." 문구가

발생하도록 패스워드를 2회 정도 고의로 틀린 상태이다.

 

 

Password Reset Disk

 

암호 재설정 방식 중 '암호 재설정 디스크'를 선택하여 

절차를 진행한다.

 

 

Password Reset Disk

재설정 암호 키가 해당 유저의 소유임이 정상적으로 확인되면

암호를 재설정 할 수 있도록 양식이 표시된다.

 

 

Password Reset Disk

정상적으로 패스워를 변경한 것을 확인할 수 있다.

 

보안 상에서 암호 재설정 키를 생성해두고 로그인을 시도할 때 마다 

패스워드를 주기적으로 변경해주는 것도 보안상에 이점이 될 수 있을 것 같다.

'Windows_System' 카테고리의 다른 글

[Windows]Windows_Remote_Desktop  (0) 2023.02.28
[Windows]Windows_Server  (0) 2023.02.27

윈도우 원격 데스크톱(Windows Remote Desktop)

원격지 혹은 로컬에 존재하는 다른 PC나 서버로 접속해서 작업을 수행해야할 때 사용되는

윈도우 운영체제에서 공식적으로 지원해주는 프로토콜로, 클라이언트(HOME / PRO)에서

윈도우 서버 2008로 원격 데스크톱을 설정한 뒤 접속해보는 실습을 진행한다.

 

필자도 현재 M1 기반의 Mac과 Intel 기반의 Windows 랩탑을 사용하며

VMWare Workstation을 사용해야 하거나 Intel 칩셋 기반에서의 작업이 요구되는 수업 진행 시

윈도우 원격 데스크톱을 요긴하게 사용하고 있는데 개인적으로 정말 편하다...

(Mac <-> Windows 간 원격 데스크톱 사용 시 네트워크 상태만 좋다면 이질감이 거의 없는 수준으로 사용이 가능)

 

참고로 윈도우 원격 데스크톱의 경우 Home 버전에서는 원격지(서버)가 될 수 없지만,

원격지로 접속을 하는 클라이언트는 가능하다.

즉 , 윈도우 Home 버전 사용 시 외부에서 내 컴퓨터로의 원격 접속은 불가능 하지만

외부에 존재하는 다른 컴퓨터로의 원격접속은 가능

 

윈도우 원격 데스크톱을 실제로 사용중인 모습

 

* 실습환경 : Intel i7-1260P(AMD64)

** 네트워크 대역 : 192.168.100.0/24

*** 해당 실습에서 사용된 가상머신 : WinSer1(.200), Windows7(.147)

 

 

● 윈도우 원격 데스크톱 설정 및 실행

Windows Remote Desktop

제어판에 들어간 뒤 '시스템' 아이콘을 클릭하여 설정에 진입했을 때의 화면이다.

일반적인 윈도우 10/11 에서는 '설정 -> 원격 데스크톱 검색' 시에 유사한 내용을 확인해볼 수 있음

(Windows Server 2008 기준으로 작성되었기 때문에 현재 윈도우 버전과의 인터페이스 차이가 있음)

 

 

Windows Remote Desktop

원격 데스크톱 활성화 및 활성화 시 보안 수준에 관한 부분을 통제할 수 있는 부분으로,

'네트워크 수준 인증을 가진 원격 데스크톱을 실행 중인 컴퓨터에서만 연결 허용' 선택 시,

 

▼ 아래의 사진과 같이 표기가 되어있는 PC에서만 접속을 허용 하는 것

Windows Remote Desktop

'원격 데스크톱 연결' 실행 후 '메시지 박스 안의 빈 공간 우 클릭 -> 정보(A)'를 선택하여 확인할 수 있다.

 

 

Windows Remote Desktop

원격 데스크톱 활성화 시 중요한 부분으로 유저 지정이 잘못 됐을 때에는 원격으로 접속이 안되는 경우가 있다.

해당 설정은 관리자 권한으로 실행되어야 하며, 관리자로 접속이 되어있지 않은 경우

관리자 패스워드를 입력하라는 문구를 확인할 수 있다.

 

 

Windows Remote Desktop

유저 지정이 정상적으로 이루어졌다면 위 처럼 표기되는 것을 확인할 수 있다.

* 해당 실습에서는 일반 권한의 사용자의 계정으로 원격 접속을 허용했음

 

▼ N개의 계정을 한 번에 설정하는 것도 가능하다

Windows Remote Desktop

위의 그림과 같이 "WINSER1\winser_user2;" 세미콜론으로 하나의 계정임을 구분지어준 뒤,

띄어쓰기 없이 '[로컬 머신 이름]\[계정]'을 입력한 후,  우측에 보이는 '이름 확인' 버튼을 클릭해서 계정을 추가해볼 수 있다.

('컴퓨터 관리' -> '그룹' 선택 시 보여지는 그룹들은 운영체제 설치 시 기본적으로 포함 되어있는 내장 그룹이다.)

 

 

Windows Remote Desktop

'시작' 버튼을 클릭 후 '방화벽'을 검색하여 Windows 방화벽에 진입하여

좌측 상단의 'Windows 방화벽을 통해 프로그램 허용'을 클릭해서

방화벽에서 허용할 원격 데스크톱의 예외 포트(Default : 3389)를 허용해준다.

 

여기까지 마쳤다면 원격 데스크톱 서버에서의 설정은 끝났다.

클라이언트의 PC로 넘어가 원격 데스크톱을 실행해본다.

 

 

● Windows7(.147)에서의 작업

Windows Remote Desktop

WINSER1의 IP주소인 192.168.100.200을 입력한 뒤,

인증서 증명 알림창으로 인해 사용자 이름이 가려져 보이지 않지만

위 그림에서 사용자는 앞에서 미리 추가해두었던 'winser1_user1'이며

두 가지 정보를 기입해준 뒤 연결요청을 해보았다.

 

 

Windows Remote Desktop

정상적으로 WINSER1 머신에 winser1_user1 이라는 유저의 계정으로  원격 세션이 성사된 모습이다.

인터페이스를 보면 화면 상단에 '192.168.100.200'이 표기되어 해당 머신에

원격으로 접속하여 작업중인 것을 알아볼 수 있다.

 

 

▼ 이미 원격세션이 있는 상태에서 다른 PC가 또 다른 원격 데스크톱 연결을 요청 시

Windows Remote Desktop

원격 데스크톱은 1:N 연결이 불가능하다.

즉, 1:1로만 연결이 가능하며 기본 값으로 설정이 된 상태에서는 추가적으로

연결을 요청하는 쪽이 기존의 세션을 끊어버릴 수 있다는 점이 존재한다.

(이 부분은 다시 포스팅)

 

 

● 권한 부여가 되지 않은 계정에 접속 시도

Windows Remote Desktop

앞에서 계정을 추가했을 때 'winser1_user1'은 원격 데스크톱 사용자로 권한이 부여되었지만

'winser1_user2'의 경우 별도의 설정이 이루어지지 않았다.

권한이 설정 되지않은 사용자를 입력한 후 원격 접속을 요청해본다.

 

 

Windows Remote Desktop

위의 그림과 같이 권한이 없기 때문에 연결이 거부되었다는 경고문을 확인할 수 있다.

이번 실습 환경은 로컬(LAN)을 배경으로 진행되었기 때문에 별도의 포트포워딩이 필요 없었지만

만일 외부(WAN) 구간을 통과해야하는 원격 접속의 경우 라우터(공유기)에서의 포트포워딩이 필수적으로 필요하다.

(상황에 따라 DDNS 주소를 할당 받아서 갱신되는 공인 IP에 대한 매핑 작업이 필요할 수도 있다.)

'Windows_System' 카테고리의 다른 글

[Windows]Password_Reset_Disk  (0) 2023.03.02
[Windows]Windows_Server  (0) 2023.02.27

윈도우즈 서버(Windows Server)

Windows서버는 Linux(Server)와 동일하게 조직의 도메인 구성 및 다양한 서비스(FTP, HTTP, DNS ...)를

위해 사용되는 운영체제로 우리가 일반적으로 사용하는 Windows Home / Pro 와 UI가

비슷할 수는 있어도 내재 되어있는 구성과 기능들은 다른 점이 많다.

 

Windows서버의 핵심 기능으로는 IIS(Internet Information System), AD(Active Directory) 등이 있으며

수업이 진행중인 상태이므로 차차 풀어나가보도록 하겠다.

 

Windows서버도 리눅스와 유사하게 CLI 기반 시스템 구동이 가능하다.

이를 Server Core라고 칭하며, 그래픽 없이 서버의 핵심 기능만으로 운영하는 방식이다.

리소스 사용률이 적으며 보안이 좋다는 장점이 존재한다.

 

Linux와 비교했을 때 Windows서버만의 장점으로는,

 

- 모든 도메인 내의 노드들에 적용되는 GPO(Group Policy Object)

(그룹 정책 관리)

 

- 여러 개의 Domain 구축 시 확장성과 연계성이 편리함

(Domain 간 Trust 관계를 갖음)

 

두 가지를 대표적으로 꼽아볼 수 있다.

 

특히 시스템 관리자의 입장에서 GPO의 경우 Domain에 속한 

구성원들에 대해서 중앙 집중식 관리를 통해, 일관된 정책 사항들을 반영할 수 있다는 점이 가장 큰 장점이다.

ex) 1(관리자) : N(구성원) 의 관리를 한 번의 작업으로 가능하게 하는 것

 

* 실습환경 : Intel i7-1260P(AMD64)

** 네트워크 대역 : 192.168.100.0/24

*** 해당 실습에서 사용된 이미지파일 버전 : Windows Server 2008 x64

 

● VMWare를 사용하여 가상머신(Windows Server)를 생성

Windows Server 2008의 리소스 구성

위의 그림과 같이 가상머신의 리소스를 구성했다.

* Hyper-V가 요구되는 작업 시에는 Processors의 옵션에서 가상화 허용을 체크해줘야함

 

 

Windows Server 2008

원활한 실습을 위해 '네트워크 및 공유센터'에서 공유에 관련된 권한을 위의 그림과 같이 설정

 

 

Windows Server 2008

Windows Server의 핵심이라고 할 수 있는 부분이다.

리눅스와 달리 윈도우 레지스트리 편집기와 동일하게 정책반영 시,

그래픽이 주가 되기 때문에 자주 사용되는 도구의 위치는 미리 알고 있는 게 도움이 될 수 있다.

 

 

Windows Server 2008

시작 버튼 → 서버 관리자 → IE ESC(Internet Explorer Enhanced Security Configuration) 구성 선택 시

위의 그림과 같은 설정화면이 출력되는데, 이는 일반적인 윈도우 클라이언트(Home/Pro) 버전이 아니기 때문에

Default는 웹 기반 콘텐츠에 관한 제재가 설정이 되어져 있다. 

(해당 옵션 활성 시 외부로 연결되는 웹 사이트 접속 시에 실습을 위해 해제함 본래에는 사용 해야함)

 

 

● '로컬 그룹 정책'의 역할 확인을 위한 실습

Windows Server 2008

테스트를 위해 만들어 본 'jerry'라는 이름의 유저

해당 작업은 GUI 환경에서도 수행 가능하지만

임시 사용자를 생성할 때에는 명령 프롬프트가 간결하고 빠르다.

 

 

 

Windows서버(2008)에서는 사용자 계정 추가를 위해

컴퓨터 관리를 사용하며 새로운 계정 추가 시 위의 그림처럼

'다음 로그온할 때 반드시 암호 변경'옵션이 기본값으로 체크 되어있는 것을 확인할 수 있다.

 

 

Window Server 2008

위의 과정과 동일하게 유저 생성 시 초기 로그온 화면에서 

암호를 바꾸어야 한다는 경고문을 확인할 수 있다.

 

이후 로그온 진행 시 기존 패스워드와 변경할 패스워드를 입력하여 

정상적으로 시스템에 로그온 할 수 있다.

 

 

● '최소 암호 길이' 정책 실습

Windows Server 2008

기본 값으로 설정된 Windows서버에서 새로운 계정 추가 시,

패스워드를 지정할 때 별도의 제한이 없어서 '1234', '1', 'password' ... 등의

예측하기 쉬운 문자(Easy-Passphrase)로의 설정이 가능했었다.

이 부분도 역시 로컬 보안 정책을 통하여 일괄적으로 규제를 걸어줄 수 있다.

(위 그림의 경우 최소 암호 길이를 기존 '0'에서 '5'로 변경 후 저장함)

 

 

Windows Server

위의 그림에 해당하는 정책 설정은 로그온 과정에서 N회 이상 틀린 값을 대입하였을 때

일정 시간동안 해당 계정을 잠금상태(Lock)로 전환시키는 옵션으로,

Linux 시스템에서의 Fail2ban과 유사한 동작을 수행하는 정책 설정이다.

 

 

Windows Server 2008

앞에서 설정된 내용을 기반으로하여 어떤 식으로 동작하기 위해서

설정된 정책에 위배되는 동작을 수행하였음

 

위 사진은 '암호 정책'에서 암호의 최소 문자 길이를 5문자로 설정한 뒤,

1자리수의 문자만으로 비밀번호 생성을 시도 하였을 때 나타나는 경고문

 

 

Window Server 2008

위의 사진은 '계정 잠금 정책'에서 설정 되었던 내용으로 

로그온 시 3회 이상 특정 유저에 대한 패스워드 입력값이 틀렸으므로

앞에서 설정한 시간인 1분 동안 계정이 '잠금 상태'로 전환된 것을 확인할 수 있다.

'Windows_System' 카테고리의 다른 글

[Windows]Password_Reset_Disk  (0) 2023.03.02
[Windows]Windows_Remote_Desktop  (0) 2023.02.28

Static Route(정적 경로 설정)

네트워크를 공부함에 있어서, A 네트워크 대역과 B 네트워크 간 통신을 성사시키려면,

라우터(Router)라는 장비가 필요하다는 것을 확인할 수 있다.

 

자신이 현재 속한 네트워크 대역이 아닌 다른 네트워크와 원활한 통신을 하기 위해서는

해당 대역으로 가기위한 최적의 경로를 알아보고, 목적지 까지의 경로가 

(라우터의) 라우팅 테이블에 저장되어 있어야 한다.

 

지금 설명하는 static route의 경우 동적 라우팅 프로토콜(Dynamic Routing Protocol)과 달리

주로 소규모에서 주로 이용되며 해당 기술을 사용하려면 경로 설정을 해주고자하는

네트워크의 구조를 정확하게 파악하고 있는 네트워크 엔지니어야만 한다.

 

▼ 대표적인 정적 경로설정 

- Static Route : 명확한 목적지에 대한 경로정보를 지정

- Default Route : 목적지의 정보가 없을 시에 최후로 전송해줄 Inteface를 지정

(주로 다른 목적지로 가기 위한 경로가 하나인 stub 네트워크에서 사용)

 

Stub Network

정도로 나누어 볼 수 있는데,

각 경로지정의 쓰임새에 차이가 존재한다.

 

 

● Static route 설정

토폴로지 1

 

 

방법 1 : 다음 홉(hop)의 인터페이스로 설정
방법 2 : 패킷이 빠져나갈 자신의 인터페이스를 설정

RT 1 라우터에 인터페이스별 IP 설정 및 기본설정을 마친 후 

static route를 설정 

 

RT1 (config)#ip route ?

입력 시 목적지 IP를 입력하라는 문구를 확인할 수 있다.

 

RT1 (config) #ip route 172.16.30.0 255.255.255.252 10.10.10.1

→ 172.16.30.0 255.255.255.252 네트워크에 도달하기 위해

10.10.10.1을 통과하여 가겠다는 의미로 경로를 수동으로 지정한다.

 

 

RT1 (config) #ip route 172.16.30.0 255.255.255.252 s2/0

→ 172.16.30.0 255.255.255.252 네트워크에 도달하기 위해

자신(RT 1)의 Serial 2/0 인터페이스로 패킷을 

빠져 나가도록 설정한다.

 

 

라우팅 테이블을 확인

RT1#show ip route

명령으로 현재 라우팅 테이블을 확인 시,

S    172.16.30.0 [1/0] via 10.10.10.1 

형식으로 패킷 전송 시의 경로를 확인해볼 수 있는데,

 

[1/0] 이라고 표현된 부분에서 앞의 숫자 1이 의미하는 것은

관리거리(Administrative Distance) 라고 하며 이 부분은

목적지에 달성하기 위한 경로가 두 개 이상일 때

경로 값, 효율(Cost)을 계산하기 위함이라고 생각하면 될 것 같다.

(추후 기술)

 

 

● Default Route 설정

Default Route

 

Default Route 설정 후 라우팅 테이블 확인

 

RT 3 라우터에서도 Default Route 설정

RT1#show ip route

입력시 라우팅 테이블의 내용을 확인해보면

S*    0.0.0.0/0 [1/0] via 10.10.10.1

 

앞에서 보았던 Static Route의 코드인 S에  *이 추가된 형태로 보이고

코드 설명을 보면 Candidate(후보)로 설정되어 있는 것을 확인해볼 수 있다.

 

Default Route 설정 후 통신상태를 확인하기 위해서

RT 3 라우터에서도 동일하게 경로를 지정해준다. 

 

RT1#ping 172.16.30.2

명령으로 통신 확인 시 문제없이 가능한 것을 확인할 수 있다.

 

'Network' 카테고리의 다른 글

[Network]Port_Security  (0) 2022.11.25
[Network]Router_02  (0) 2022.11.22
[Network]Router_01  (0) 2022.11.21
[Network]VLAN  (0) 2022.11.16
[Network]STP_Algorithm  (0) 2022.11.11

디지털 인증서(Digital Certifiate)

우리가 웹 사이트나 모바일 뱅킹 등의 서비스를 이용할 때 안전하게 사용할 수 있는 이유로는
TLS(Transport Layer Security) 방식으로 서버와 노드간 주고받는 내용을 암호화 처리하여
패킷을 가로채더라도 복호화를 해야만 볼 수 있게끔 만들어주는 기술이 적용되기 때문이다.

웹 서버는 클라이언트와 서버의 보안접속을 위해서
대중적으로 많이 사용되는 웹 브라우저(Chrome, Firefox, Whale, MS Edge, Opera ..)에
자신들의 인증서(.crt = Public Key)웹 브라우저에 배포해 보안접속을 가능하게 해준다.

실제로 서비스에 사용되는 인증서의 경우는 금액을 지불하고 인증기관(CA)에 요청하여
CA에게 서명을 받은 인증서를 발급받게 되는데, 이런 공인된 인증서를 발급해주는 회사로는
COMODO, VeriSign, DigiCert ... 등의 대표적인 기업이 존재한다.

공인된 인증서의 경우 금액과 복잡성의 리스크가 존재하므로,
이번 실습에서는 로컬 및 집단의 내부에서만 사용되는 인증서 생성 및 배포를 실시

▶ 공인된 인증서의 발급 과정

1. 인증서 발급을 위한 개인 키(Private Key)를 생성

2. 인증서 발급 요청서(*.csr)을 개인 키와 공개 키를 이용하여 생성
(공개 키를 포함한 인증서(*.crt) 생성을 위해서 개인 키로 인증을 실시한다)

3. 생성된 인증서 발급 요청서를 이용하여 인증 기관(CA)에 인증서 인증을 요청

4. 검토 절차가 종료된 후 FingerPrintDigita Signing을 인증서에 등록하여 발부



물론 로컬에서 웹 서비스등의 서비스 테스트를 위한 사설 인증서 발급의 경우에는
위의 절차 보다는 편리하게 사설 인증서로 직접 인증서를 생성하여 사용할 수도 있다.

* 실습환경 : Intel i7-1260P(AMD64)
** 네트워크 대역 : 192.168.100.0/24
*** 해당 실습에서 사용된 가상 머신 : CentOS 7(.140 = Web Server), Windows 7(.147 = Web Client)


▼ HTTP(평문장) 연결방식과 HTTPS(암호화) 전송 방식의 차이점 참고자료

 

[Security]HTTPS

HTTPS(Hyper Text Tranfer Protocol Secure) 네트워크 서비스(웹 사이트, 금융, 공인인증서 ...)를 안전하게 이용할 수 있게 해주는 역할을 하는 방식으로 대부분 네트워크 패킷 전송에 사용되는 TCP 프로토콜

for-security.tistory.com

 

● 개인 키와 서명 인증 요청서 생성

# openssl 패키지 다운로드 및 수동설치
sudo wget https://www.openssl.org/source/openssl-1.1.1t.tar.gz
sudo tar xvfz openssl-1.1.1t.tar.gz

# www.ditto.com의 개인 키 생성
sudo openssl genrsa -out www.ditto.com.key 2048		# 2048은 키의 복잡도를 의미

# 개인키의 보안을 위한 허가권 변경
sudo chmod 600 www.ditto.com.key

# 개인 키를 암호화 포맷으로 저장하는 방법
sudo openssl rsa -in www.ditto.com.key -des3 -out www.ditto.com.key.secure.key

openssl 개인 키 생성 및 허가권 변경

 

# sha256 암호화 알고리즘이 적용된 서명 인증 요청서를 생성
sudo openssl req -new -sha256 -key www.ditto.com.key -out www.ditto.com.csr

(좌)서명 인증 요청서 생성 / (우)서명 인증 요청서의 내용

위의 두 파일을 사용하여 공인 기관(CA)를 통한 기간제 무료 인증서 발급이 가능하며,
해당 기관의 인증을 받은 인증서는 실제 웹 서비스 호스팅 시 사용이 가능하다.

▼ 로컬 도메인에서만 사용 가능한 사설 인증서 발급과정

# 앞에서 생성한 개인 키로 자체적으로 인증서(*.crt)를 발급
# x509는 공개키 알고리즘의 표준(방식)
sudo openssl req -new -sha256 -x509 -nodes -days 365 -key www.ditto.com.key -out www.ditto.com.crt

# 인증서 발급 시 기재사항
# Country Name ~ Email Address까지 순서대로 국가, 도시, 지역(구), 조직이름, 부서명, 이메일을 의미함

You are about to be asked to enter information that will be incorporated into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter the field will be left blank.
---
Country Name (2 letter code) [XX]:KR	
State or Province Name (full name) []:Seoul	
Locality Name (eg, city) [Default City]:Mapo
Organization Name (eg, company) [Default Company Ltd]: Company
Organizational Unit Name (eg, section) []:Security
Common Name (eg, your name or your server's hostname) []:www.ditto.com
Email Address J:admin@ditto.com	

# 생성된 인증서의 내용을 확인
sudo openssl ×509 -noout -text -in www.ditto.com.crt

(좌)자체 인증서 발급 / (우)인증서의 내용 확인

 

# 보안을 위해 허가권과 저장 경로를 변경
sudo cp -arp www.ditto.* /etc/pki/tls/private
sudo chmod 600 -R /etc/pki/tls/private/*

생성된 키, 서명 요청서, 인증서

 

# mod_ssl 패키지 다운로드
sudo yum install -y mod_ssl

# Apache 구성파일 중, /etc/httpd/conf.d/ssl_conf 파일 수정
sudo vim /etc/httpd/conf.d/ssl_conf

[파일 내용]
95 # Server Certificate:
96 # Point SSLCertificateFile at a PEM encoded certificate. If
97 # the certificate is encrypted, then you will be prompted for a
98 # pass phrase. Note that a kill -HUP will prompt again. A new
99 # certificate can be generated using the genkey (1) command.
100 SSLCertificateFile/etc/pki/tls/private/www.ditto.com.crt		# 인증서 경로
101
102 #Server Private Key:
103 #If the key is not combined with the certificate, use this
104 #directive to point at the key file. Keep in mind that if
105 #you've both a RSA and a DSA private key you can configure
106 #both in parallel (to also allow the use of DSA ciphers, etc.)
107 SSLCertificateKeyFile/etc/pki/tls/private/www.ditto.com.key		# 개인 키 경로

Apache 서비스, ssl_conf 파일

 

sudo vim /etc/pki/tls/openssl.cnf

서버 내에 웹 서비스 뿐이 아닌 다른 서비스가 존재한다면,
해당 프로토콜을 지원하는 인증서를 함께 발급하여 인증서를 유효화할 수 있다.

# 클라이언트에서 접속할 수 있도록 방화벽 개방
sudo firewall-cmd --permanent --zone=public --add-service=http
sudo firewall-cmd --permanent --zone=public --add-service=https
sudo firewall-cmd --reload 

# 포트 개방상태를 확인
sudo netstat -nltp | grep LISTEN
tcp		0 	0 0.0.0.0:80		0.0.0.0:* 		LISTEN		80/httpd
tcp		0 	0 0.0.0.0:80		0.0.0.0:* 		LISTEN		443/httpd

# 간단한 웹 페이지를 생성
[centos@localhost ~]$ su -c "echo \"<h1>This is Ditto's Web For test Certificates</h1>\" > /var/www/html/index.html"
[centos@localhost ~]$ cat /var/www/html/index.html
<h1>This is Ditto's Web For test Certifiacate</h1>

# httpd 서비스 재시작 후 상태확인
sudo systemctl restart httpd
sudo systemctl status httpd

 

 

httpd 서비스 재시작 시 발생할 수 있는 경고문

오류 메시지의 내용을 읽어보면, 해당 컨텐츠의 내용을 사용자가 읽기 가능하게 하려면
'httpd_user_read_user_content'의 SEboolean 값을 1(참)로 변경하라는 것을 확인할 수 있다.
SELinux 의 Status를 Permissive(0)으로 만들어 해결도 가능하지만 보안상 취약하므로 선호되지 않는다.
(아래에 표기되어 있는 방식대로 SELinux의 보안 레벨을 수정 후 재시작하면 해결)

▼ Web Client Windows 7(.147) 에서의 작업

C:\Windows\System32\drivers\etc\hosts 파일

관리자 권한으로 메모장을 실행한 뒤 해당 경로의 hosts 파일에
CentOS 7의 웹 서버 FQDN을 정의해준다.

CentOS의 사설 인증서를 윈도우 PC로 복사

본래 인증서는 USB나 SMB .. 등의 수단으로 인증서를 옮기지만,
실습 편의를 위해 드래그 앤 드롭 형태로 인증서를 복사하였다.
더블 클릭하여 인증서 등록 과정을 진행한다.

 

외부 인증서를 윈도우 PC에 설치하는 과정

로컬에서 CA의 공식 인증이 아닌 자체적으로 제작된 인증서인 관계로
위의 그림과 같은 경고문을 확인할 수 있는데, 출력된 내용대로
'루트 인증 기관 저장소'에 설치해야 인증서로서의 기능이 적용된다.
(해당 인증서는 Google Chrome에서 사용이 불가했다)

 

(좌)등로된&nbsp; 후의 인증서 / (우)인증서의 정보를 확인

인증서 내용 확인 시, CentOS에서 생성 시 기입했던 내용의 정보와 일치하는 것을 확인할 수 있다.

 

https://www.ditto.com

https 프로토콜로 접속 시 서버와의 연결이 암호화 되었다는 안내문구를 확인할 수 있음

'System_Security' 카테고리의 다른 글

[Security]TrueCrypt  (0) 2023.02.02
[Security]SSH_Keygen  (0) 2023.02.01
[Security]HTTPS  (0) 2023.01.31
[Security]chroot  (0) 2023.01.27
[Security]Snort  (0) 2023.01.26

Log Server(Rsyslog를 활용한 원격 로그서버)

OS의 종류를 막론하고 서버, 시스템을 관리하는 시선에서의 로그(Log)는 굉장히 중요한 파일이자 증거물이다.

 

로그는 커널, 보안관련, 서비스 등지에서 발생하는 이벤트에 대해 기록되는 것으로,

기본적으로 리눅스에서는 'rsyslog' 패키지의 데몬을 통해서

로컬(/var/log/~) 혹은 원격 로그 서버(Remote Log Serverr)에 저장하게 된다.

(FTP, DB, HTTP .. 등의 메인 서버에서 발생하는 로그의 관리방식)

 

로컬 머신에 저장되는 로그의 경우 해커가 작업을 마친 후 로그를 삭제하면

그 증거를 찾아내기 어려워지지만, 실시간으로 발생하는 로그를 

원격지의 서버로 SSH를 통하여 전송하여 통합 저장 및 관리를 한다면

보다 안전하고 효율적으로 관리할 수 있을 것이다.

 

* 실습환경 : Intel i7-1260P(AMD64)

** 네트워크 대역 : 192.168.100.0/24

*** 해당 실습에서 사용된 가상 머신 : CentOS 1(LogServer .140), CentOS 2(Client, ditto.com, .160),

Ubunser(.135)

 

 

● Rsyslog를 활용한 원격 로그서버 구축

# CentOS7 1(.140 == Remote Log Server)

# rsyslog 패키지를 설치(대부분 기본 패키지로 설치 되어있음)
sudo yum install -y rsyslog

# 기본 설정파일 백업 생성
sudo cp -arp /etc/rsyslog.conf /etc/rsyslog.conf.bak

 

# rsyslog 서버의 /etc/rsyslog.conf 파일 내용 수정

[파일 내용]
14 # Provides UP syslog reception
15 $ModLoad imudp
16 $UDPServerRun 514

18 # Provides TCP syslog reception
19 $template TemlAuth, "/var/log/%HOSTNAME%/PROGRAMNAME%. log"
20 *.*?TemlAuth
21 $ModLoad imtcp
22 $InputTCPServerRun 514

# 원격 로그 서버로 사용될 머신에서 514포트(syslog Protocol) 부분의 주석을 해제
# 19번 째 라인을 보면 새로운 템플릿을 정의한 후 원격지(클라이언트)에서 수신받는 로그의 저장 경로를 지정
# 20번 째 라인의 경우 모든상황에 대한 모든 메시지를 수신한다는 의미

[파일수정 완료 후]
sudo firewall-cmd --permanent --zone=public --add-port=514/tcp
sudo firewall-cmd --permanent --zone=public --add-port=514/udp
sudo firewall-cmd --reload

sudo systemctl restart rsyslog && sudo systemctl status rsyslog

# 방화벽 설정 적용과 수정내용 적용을 위한 재시작을 실행

 

/etc/rsyslog.conf

 

 

포트 개방 상태를 확인

 

 

▼ Centos7 2(.160, Client)

/etc/rsyslog.conf

"*.info;mail.none;cron.none@192.168.100.140(원격 로그 서버의 IP주소)"

info 레벨의 로그를 전송하는데, mail과 cron에서 발생한 이벤트에 대해서는 전송하지 않는다는 의미를 가진다.

 

 

서비스 재시작

설정파일 적용을 위해 서비스를 재시작 후 상태를 확인한다.

 

 

▼ Ubunser(.135, SSH Client)

로컬의 다른 가상머신에서 원격 접속을 시도(비밀번호 2회 오류 후 접속)

 

▼ 결과물(Report)

LogServer에서 'ditto' 호스트의 sshd.log 정보를 확인

 

LogClient에서 자신의 로그파일을 확인

몇 분 차이로 클라이언트 머신에서는 다른 이벤트가 발생하여 내용이 추가되었지만,

서버의 SSHD 관련 로그와 내용을 비교 해보았을 때, 내용이 일치하는 것을 확인할 수 있다.

동기화가 정상적으로 이루어졌다는 의미

'Linux_System' 카테고리의 다른 글

[Linux]DHCP  (0) 2023.02.10
[Linux]Squid(Proxy_Server)  (0) 2023.02.09
[Linux]Ansible  (0) 2023.02.04
[Linux]YUM_Priority  (0) 2023.01.18
[Linux]ZFS  (0) 2023.01.16

DHCP(Dynamic Host Configuration Protocol)

DHCP란 호스트들의 IP, Gataway, DNS 서버를 자동으로 할당해주는 프로토콜로,
과거 BootP(디스크가 없는 컴퓨터에게 IP 주소 및 구성정보를 자동으로 설정)의 상위버전으로 볼 수 있다.

LAN 구성도

위의 그림과 같이 조직 내부에서 지정된 범위의 IP를 자동으로 할당해주는 서버를
리눅스로 구성해보겠다.

* 실습환경 : Intel i7-1260P(AMD64)
** 네트워크 대역 : 192.168.100.0/24
*** 해당 실습에서 사용된 가상 머신 : Ubunser20.04(.145), CentOS7
(.DHCP), Windows7(.DHCP)

● DHCP 서버 구축

VMWare Edit Tab -&gt; Virtual Network Editor

현재 실습환경은 물리적인 노드가 아닌 VMWare 안의 가상머신으로 진행되기 때문에
VMWare 메인 네트워크 어댑터를 통한 자동 IP할당 옵션을 체크해제

# DHCP 서버 구축을 위해 필요한 패키지 설치(Ubuntu Server 20.04 기준 패키지)
sudo apt install -y isc-dhcp-server

# Default 설정파일을 백업
sudo cp -arp /etc/dhcpd.conf /etc/dhcpd.conf.bak


# dhcpd.conf 파일을 수정하여 설정사항을 저장
sudo vim /etc/dhcpd.conf

[파일내용]
# A slightly different configuration for an internal subnet.
subnet 192.168.100.0 netmask 255.255.255.0 {
  range 192.168.100.210 192.168.100.215;
  option domain-name-servers 192.168.100.2;
  option domain-name "ditto.com"
  option subnet-mask 255.255.255.0;
  option routers 192.168.100.2;
  option broadcast-address 192. 168.100.255;
  default-lease-time 600;
  max-lease-time 7200;
}

# DHCP 할당 시켜줄 네트워크 대역을 정의 192.168.100.0/24
# DHCP 할당 시켜줄 네트워크의 범위를 설정 .210 ~ .215까지 할당
# DNS를 설정 192.168.100.2(Default)
# Domain Name을 설정 "ditto.com"
# 기본 대여 시간 600초, 최대 대여 시간 7200초로 설정됨


sudo iptables -I INPUT 1 -p udp -m state --state NEW --dport 67 -j ACCEPT

DHCP의 포트 번호로는 서버(67번) / 클라이언트(68번)을 사용하며
클라이언트가 IP 할당을 위해 요청을 할 수 있게끔 67번 포트를 활성화해준다.

iptables를 이용하여 INPUT 체인에 67번 포트에 관한 룰을 추가해준다.
(sudo ufw allow ~ 를 이용하여 대체할 수 있음)

sudo /etc/init.d/isc-dhcp-server start

해당 명령어를 이용하여 서비스 시작 또는 재시작이 가능하며,
보편적으로 systemctl [Option] [Service] 를 이용하여 서비스를 시작해준다.

▼ CentOS7(DHCP 클라이언트)

# 기존 Static(정적)으로 설정 되어있던 CentOS7의 네트워크 설정파일을 수정
sudo vim /etc/sysconfig/network-scripts/ifcfg-ens33

[파일 내용]
TYPE="Ethernet"
PROXY METHOD="none"
BROUISER ONLS="no
BOOTPROTO="dhcp"			# BOOTPROTO = "dhcp" 설정
DEFROUTE "yes"
IPU4_FAILURE_FATAL = "no"
IPUGINIT-"yes"
IPU6 _AUTOCONF="yes"
IPV6 _DEFROUTE-"Jes"
IPUG FAILURE FATAL= "no"
IPU6_ADDR_GEN _MODE-"stable-privacy"
NAME-"ens33"
UUID="3c9ae2f6-bf1a-469a-8217-ca99bce784ff"
DEUICE="ens33"
ONBOOT-"ues"
#IPADDR="192.168.100.160"
#PREFTX=124*
#GATEWAY="'192.168.100.2"
#ONS1="192.168.100.2"
10052=44192.168. 190 :7.
#DNS3="8.8.8.8"				# 기존에 정적으로 설정되었던 부분은 주석처리

CentOS7

CentOS7

설정파일 수정 및 저장 후,
"sudo ifdown ens33 && sudo ifup ens33"
명령으로 네트워크 카드를 재시작해보면
DHCP 범위의 첫 번째 주소인 .210 으로 할당된 것을 확인해볼 수 있다.


▼ Windows 7(DHCP 클라이언트)

Windows 7

윈도우 탭 -> 네트워크 -> 네트워크 속성(R) 탭을 클릭하여
수동으로 지정 되어있던 IP 설정을 자동으로 변경해준다.

Windows 7

설정을 마친 후 윈도우 명령 프롬프트에서 "ipconfig" 로 네트워크 정보 확인 시
DHCP 할당 범위에 속하는 ~.211로 IP가 설정된 것을 확인할 수 있다.

▼ Ubunser(DHCP 서버)

sudo dhcp-lease-list

해당 명령어로 현재 IP주소를 부여받은 노드들의 정보를 확인해볼 수 있다.




'Linux_System' 카테고리의 다른 글

[Linux]Log_Server  (0) 2023.02.10
[Linux]Squid(Proxy_Server)  (0) 2023.02.09
[Linux]Ansible  (0) 2023.02.04
[Linux]YUM_Priority  (0) 2023.01.18
[Linux]ZFS  (0) 2023.01.16

Squid를 활용한 Proxy서버 구축

Proxy서버는 Cache서버 라고도 불리우며 네트워크 상의 각 노드들이
네트워크 서비스(외부:WAN)으로 접속하려 할 때, 각 노드들이 기존에 접속했던 정보를 쿠키(Cookie)로 보유함으로써
내부 네트워크 (내부:LAN)와외부 네트워크 서버 사이에서 연결에 대한 도움을 주는 중계기 같은 역할을 하는 서버이다.

네트워크 구성도

예를들어 위와 같은 그림의 구조를 가진 네트워크에서 1 ~3 번 노드들이
기존에 접속했었던 서버의 정보(쿠키)를 프록시 서버에 저장 해두었다가.
추후 동일한 서버로의 접속을 요청하면 외부(ex. Global DNS)로 쿼리를 하지않고,

내부의 프록시 서버가 경로를 지정해주므로 경로가 단순화 될 수 있다는 장점(트래픽 감소)이 존재하며
유해 사이트 및 접근해서는 안되는 서버를 ACL로 Permit, Deny로 통제해주는 역할을 수행한다.

많이 사용하게 되는 웹 브라우저에 프록시 서버를 지정하여 접속 제한을 하는 진행

* 실습환경 : M1 Based Mac(ARM64)
** 네트워크 대역 : 10.211.55.0/24
*** 해당 실습에서 사용된 가상 머신 : Fedora(.30= Proxy Server), Fedora(.20 = Just Node..)

● Proxy Server 구축

sudo dnf install -y squid

프록시 서버 구축을 위한 Squid 패키지를 다운로드

# 원본파일 백업
sudo cp -arp /etc/squid/squid.conf /etc/squid/squid.conf.bak

# Squid 설정파일 수정
sudo vim /etc/squid/squid.conf

[squid.conf 수정내용]
2 # Recommended minimum configuration:
5 # Example rule allowing access from your local networks.
# Adapt to list your (internal) IP networks from where browsing
7 # should be allowed
8 acl bad url_regex -i "/etc/squid/blocked"	### 해당부분에 룰과 참조파일 경로를 지정
9 acl localnet sc 0.0.0.1-0.255.255.255
10 acl localnet sc 10.0.0.0/8
11 acl localnet sc 100.64.0.0/10
12 acl localnet sc 169.254.0.0/16
13 #acl localnet sc 172.16.0.0/12
14 acl localnet sc 10.211.55.0/24
.
.
.
52 # Example rule allowing access from your local networks.
53 # Adapt localnet in the AL section to list your (internal IP networks
54 # from where browsing should be allowed
55 http access allow localnet !bad			### bad로 지정되지 않는 IP접속은 허가
56 http_access allow localhost

58 # And finally deny all other access to this proxy
59 http_access deny all

61 # Squid normally listens to port 3128
62 http port 3128							### Proxy 서버로 사용할 Port 번호
63 # Uncomment and adjust the following to add a disk cache directory.
64 #cache dir ufs /var/spool/squid 100 16 256

66 # Leave coredumps in the first cache dir
67 coredump_dir /var/spool/squid


/etc/squid/squid.conf
/etc/squid/sqiud.conf


# 차단될 FQDN(목적지)가 정의된 파일생성
sudo vim /etc/squid/blocked

[파일내용]
1 www.youtube.com
2 .daum.net
3 .naver.com

# 앞 부분 ~.[FQDN]을 사용하면 프로토콜과 관계 없이 도메인 전체차단의 효과
# 정규표현식의 Asterisk(*)과 유사한효과


[방화벽 설정]
sudo firewall-cmd --permanent --zone=public --add-service=squid 
sudo firewall-cmd --reload
sudo firewall-cmd --list-services

[포트확인 Open상태 확인]
sudo ss -nltp | grep LISTEN
방화벽과 포트 LISTEN 상태를 확인



● Fedora(.20 = Node)에서 프록시 서버를 지정

Firefox

웹 브라우저 우측 상단의 삼단바를 클릭하여 Setting 클릭 후,
설정 페이지로 접근

Firefox

우측의 검색창에 'proxy'를 입력 후 검색

Firefox

'Manual Proxy Configuration' 체크란에 체크 후, 앞에서 프록시 서버로 구축한
프록시 서버의 주소(10.211.55.30)와 포트번호 '3128'을 기재하여 저장

Firefox

앞에서 정의한 'blocked'에 지정 되어있지 않은 facebook 웹 사이트 접속은 정상적으로 가능

Firefox

차단 목록에 포함 되어있는 ~.naver.com 사이트 접속요청 시
'The Proxy server is refusing' 이라는 경고문과 함께
접근이 차단되는 것을 확인할 수 있다.

'Linux_System' 카테고리의 다른 글

[Linux]Log_Server  (0) 2023.02.10
[Linux]DHCP  (0) 2023.02.10
[Linux]Ansible  (0) 2023.02.04
[Linux]YUM_Priority  (0) 2023.01.18
[Linux]ZFS  (0) 2023.01.16

+ Recent posts