[32일 차] 21.09.02 : Linux Server 11

1교시

 

DDNS : 존 파일의 내용은 마스터 서버에서만 조정 가능한데, 원격으로 존 파일을 수정할 수 있게 하는 것.

 

슬레이브 DNS 설정 

 

마스터에서는 

rfc 설정 파일에 allow-transfer { 192.168.111.200; }; 구문을 chul.com, jeong.com, 역방향 블록에 추가

chul.zone에 NS ns2.chul.com, ns2 192.168.111.200 추가

 

슬레이브에서는 

똑같이 bind 패키지들 설치, 방화벽 열고

주 설정 파일은 똑같이 수정

rfc 설정 파일은 똑같이 추가하되, zone 이름은 똑같이, 타입은 slave, file은 "slaves/xxx.zone", allow-update는 주석 처리

타입이 슬레이브면 업데이트 X

dig @ns.chul.com chul.com ns : 해당 zone에 대한 상세 질의. $1에게 $2에 대한 $3 레코드 값을 질의.

slave의 DNS에 192.168.111.200 추가 후 적용

-> /etc/resolv.conf에 nameserver가 써있다.

master의 named를 끄고 slave에서 다시 dig로 물어보면 응답 안됨.

-> slave의 DNS는 ns2.chul.com으로 작성했었기 때문.

-> ns2.chul.com에게 물어보면 응답한다.

-> 슬레이브가 마스터에게 받은 존 파일은 /var/named/slaves에 있다.

-> 얘도 소유자:소유그룹을 root:named로 바꾸기

 

 

FIRST를 또 다른 서브 DNS로 등록하기

FIRST의 네트워크에 DNS로 192.168.111.100 등록 > FIRST의 서버 관리자 기능 추가로 DNS 기능 추가 > DNS 관리자 > 정방향 조회 영역 우클릭, 새 영역 > 보조 영역 > chul.com과 192.168.111.100(첫 단계 거쳤으면 도메인으로 적어도 무관) 등록, jeong.com과 192.168.111.100 등록 > 역방향도 등록

DNS 실습 구조

실습에서는 하나의 VM으로 클라이언트/서버의 역할을 모두 진행해서 헷갈릴 수 있는데, 어떤 때 클라이언트의 역할이고, 어떤 때 DNS의 역할인지 주의할 것.

---

2교시

 

Recursive 네임 서버

-> 자신의 캐시를 조회한 후 있으면 응답, 없으면 최상위 도메인에서부터 질의 대상 DNS까지 반복적 질의 수행

Caching Only 

-> 스스로 관리하는 존 파일 없이 반복되는 질의만을 처리

Forwarding 네임 서버

-> 네임 서버가 설정 파일에 Forwarders를 설정하면 이 서버가 직접 도메인 정보를 찾는 것이 아니라 클라이언트의 모든 요청은 Forwarders에 지정된 서버로 연결되어 해당 서버가 대신 정보를 찾아준다. 

-> /etc/named.conf 파일에

forwarders { 8.8.8.8; 8.8.8.4; };      -> 구글 서버에게서 받아온다
forward only;     -> only(포워더가 모르면 DNS에게 recursion X), first(포워더가 모르면 다른 DNS에게 물어본다)

클라이언트(slave vm)에게 dig로 아무 사이트를 물어보면 응답한다.

 

동적 DNS(DDNS)

-> DNS 서버의 변경하고자 하는 설정 내용을 실시간으로 DNS 서버에 업데이트할 수 있는 기능

 

allow-update 옵션

-> 등록한 IP 주소의 장비는 zone 파일/설정 파일을 수정 가능

-> 보안 취약

 

rfc 설정 파일의 allow-update 항목에 IP 주소 작성 > /var/named 디렉터리에 sticky bit가 붙어 있다.

등록해놓은 slave vm에서 nsupdate 실행

> server ns.chul.com   -> 서버 지정
> zone chul.com      -> 변경할 존 지정
> update add test.chul.com 3600 A 192.168.111.10      -> 존에 도메인 추가
> send      -> 전송
> show      -> 변경 내용 조회
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:      0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; ZONE SECTION:
;chul.com. IN SOA
> quit

조금 기다리면 업데이트된다.

 

update-policy 옵션 : 키 값을 이용해서 인증

1. 주 DNS에서 키 생성

-> ddns-confgen -a hmac-md5 -z chul.com 실행하면

-> 키 값이 나온다.

key "ddns-key.chul.com" {
   algorithm hmac-md5;
   secret "d6fFAnRrezntCXbcspI5HQ==";
};

update-policy {
  grant ddns-key.chul.com zonesub ANY;
};

위 항목을 저장해놓고

2. 주 DNS에서 주 설정 파일에 키 추가(등록)

-> named.conf 파일의 상단에 위에서 저장해놨던 키 블록 작성

-> 적용할 zone 블록(여기선 chul.com) 내부의 allow-update 주석 처리, 그 아래에 위의 update-policy 작성

-> vim /etc/named/ddns-key.chul.com 작성해서 위의 키 블록 작성

3. 키를 슬레이브로 전송

-> $1을 복사해서 $2에 붙여넣기. 양쪽에 sshd 켜져있어야 하고, 방화벽도 열려있어야 한다.

scp /root/.ssh/id_rsa.pub 
원격서버계정@원격서버아이피:
~/.ssh/id_rsa.192.168.111.10.pub

-> scp /etc/named/ddns-key.chul.com root@192.168.111.200:/etc/named/ 실행

 

3. 테스트

-> nsupdate -k /etc/named/ddns-key.chul.com

> server ns.chul.com
> zone chul.com
> update add test.chul.com 3600 A 192.168.111.10
> send
> show
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:      0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; ZONE SECTION:
;chul.com. IN SOA
> quit

 

-> dig test.chul.com

---

3교시

 

FIRST를 웹 서버로 구성하고, DHCP 서버로부터 IP를 동적 할당받는다. 

DHCP 서버에 의해 FIRST의 주소가 바뀌면, DNS에게 동적 업데이트(DDNS)

slave를 DHCP로 잡고 master를 DNS, FIRST를 웹 서버로 구성

 

slave vm에 DHCP 설치 : yum -y install dhcp-server.x86_64 

주 설정 파일이 없으니 샘플 파일 복사

-> cp /usr/share/doc/dhcp-server/dhcpd.conf.example /etc/dhcp/dhcpd.conf

-> /etc/dhcp/dhcpd.conf를 열어서 : 기본 대여 시간, 최대 대여 시간 등의 정보가 있다.

옵션 부분이 따로 없으니 아무곳이나 - 대략 26행쯤에 아래 내용 작성

option subnet-mask 255.255.255.0;

option broadcast-address 192.168.111.255;

option routers 192.168.111.2;

option domain-name-server 192.168.111.100,192.168.111.2;

option domain-search "chul.com";

subnet 192.168.111.0 netmask 255.255.255.0 {

   range 192.168.111.150 192.168.111.155;

}

-> subnet 이 부분은 pool을 의미. domain-name-server 여기서 설정 안하면 이 값으로 설정될 것이다.

-> 저장하고 나와서 서비스 시작 : systemctl start dhcpd

-> dhcp 방화벽 열어주기 : fiewall-cmd --permenant --add-service=dhcp

-> lsof -i udp:67   (dhcp가 사용하는 포트와 프로토콜)

/var/lib/dhcpd/dhcpd.leases 라는 파일에 할당해준 주소들을 볼 수 있다.

 

이제 DDNS 연동 : /etc/dhcp/dhcpd.conf 파일로 들어가서 아래 내용을 작성(위치 무관).

ddns-updates on;

ddns-update-style interim;

ddns-domainname "chul.com";

allow client-updates;

include "/etc/named/ddns-key.chul.com";

zone chul.com {

   primary 192.168.111.100;

   key "ddns-key.chul.com";

}

작성 후 dhcpd 재시작

 

FIRST 네트워크 설정에서 주소를 자동으로 받아오도록 설정하고, 주소를 받아오기 위해 ipconfig /release와 ipconfig /renew로 주소 받아오기

 

DHCP 구축 파트는 뒤쳐져서 다시 들어야 한다.

=============

클라이언트 명령어들

클라이언트 프로그램
1. nslookup
-> 도메인 DNS에게 질의 : 그냥 치면 내부 모드로 들어가고, 아래처럼 옵션을 줘서 실행하기도 가능
nslookup www.chul.com
nslookup -type=mx chul.com
nslookup -type=any chul.com
nslookup naver.com ns.chul.com
nslookup 192.168.111.100

2. host
-> 도메인 DNS에게 질의 : 더 상세한 정보가 온다.
host -t ns chul.com
host -t mx chul.com
host -t any chul.com
host -al chul.com
host www.chul.com
host www.chul.com ns.chul.com

3. dig
dig @ns.chul.com google.com any +nocomments
dig www.chul.com
dig chul.com mx
dig +trace www.naver.com
dig @ns.chul.com +nocmd +noall +answer a www.chul.com

 

---

4교시 

 

DDNS Security

-> DNS 설정하려면 보안 기능은 필수. 구축하는 정도만 알아두기.

 

DNS 캐시 poisoning 공격

-> 캐시 DNS 서버에게 도메인을 들고 주소를 물어보고, 캐시가 모르면 루트 서버에게 물어보는 식으로 recursive 하게 진행될 것이다.

-> 이런 정상적인 진행 도중, 공격자가 가짜 웹 사이트 주소를 캐시 서버에게 계속 보낸다.

-> 그럼 해당 도메인에 대한 주소가 가짜 주소로 바뀔 것이다. 결국 해당 캐시 DNS를 찾는 모든 클라이언트는 잘못된 주소를 통해 가짜 웹 사이트로 가게 될 것이다.

DNS 싱크홀

-> DNS 서버가 악성 서버/감염된 PC 같은 악성 도메인을 질의받으면, 기존에는 해커 서버의 IP를 응답했다.

-> 이러면 해커 서버는 앞으로 질의자의 PC에 계속 접근 가능했다.

-> 싱크홀을 적용하면 악성 도메인 목록을 DNS 서버에게 전달해서 질의자가 악성 도메인을 질의하면 싱크홀 서버로 가도록 응답한다.

 

아무튼 이런 공격을 막는 것이 DNS Security(DNSSEC)

-> 네임 서버와 클라이언트(캐싱 DNS) 간 DNS 데이터 보호

-> 공개 키와 개인 키를 생성하고, 개인 키를 이용해 DNS 데이터에 서명

-> 캐싱 서버들은 그 네임 서버가 제공한 공개 키를 사용해서 인증

-> 서명하면 존 파일의 모든 레코드가 암호화된다.

-> 루트의 개인키로 서명된 데이터를 캐싱 서버가 루트의 공개 키로 풀고, kr dns의 개인키로 서명된 데이터를 캐싱 서버가 kr의 공개 키로 풀고.... 결과적으로는 각 DNS가 자신의 개인 키로 서명하고, 공개 키를 다른 서버들에게 제공할 것이다. 이러면 서명이 안된 데이터는 받지 않으니 poisoning 공격이 통하지 않는다.

-> 암호화 기법이 아니라 인증 방식

 

RRset : 원본 레코드와 동일한 레코드 집합

DNSKEY : KSK(공개키), ZSK(공개키)

ZSK(Zone Signing Key) : 한 존 내에서 각 레코드를 서명하기 위해 사용

KSK(Key Signing Key) : ZSK를 서명하고 신뢰 사슬을 생성하기 위해 사용

RRSIG : RRset을 ZSK(개인키)를 이용해 서명한 레코드

 

 

1단계 : 도메인 Zone Key 생성

dnssec-keygen -a NSEC3RSASHA1 -r /dev/urandom -b 1024 -n ZONE chul.com.   -> ZSK 키 생성

dnssec-keygen -a NSEC3RSASHA1 -r /dev/urandom -b 2048 -n ZONE -f KSK chul.com.   -> KSK 키 생성

 

2단계 : 공개 키 Zone에 추가

/var/named/keys 디렉터리 만들고 소유자/소유 그룹 named로 변경, 만들었던 키 이 디렉터리로 이동

.key는 공개키, .private는 개인키

chul.zone 파일 하단에 공개 키 추가

$INCLUDE /var/named/keys/Kchul.com.+007+31508.key
$INCLUDE /var/named/keys/Kchul.com.+007+05701.key

 

3단계 : Zone 서명

dnssec-signzone -S -K /var/named/keys/ -3 96e920 -o chul.com. /var/named/chul.zone

 

4단계 : 설정 파일 수정

/etc/named.rfc~ 파일 수정

존 블록에서 file 항목을 .signed 파일을 전송하도록 수정

하단에 auto-dnssec allow 추가

슬레이브 쪽의 /etc/named.rfc~ 파일에도 file 항목을 똑같이 수정

 

5단계 : dig 이용 DNSSEC 검증

dig @ns.chul.com chul.com dnskey +multiline

dig @ns.chul.com chul.com a +dnssec +multiline

실행해보면 존 정보가 암호화된 상태로 보인다.

 

전자서명은 인증성(자격과 내용 검증)을 위한 것이지 기밀성(송신-수신 측만 정보를 볼 수 있게 한다)을 위한 것이 아니다.

---

5교시

 

DNS는 여기까지, 이제는 SSH 서버 연결/원격 접속. 중요. AWS 인스턴스에 접근할 방법이 SSH밖에 없기 때문이다.

패스워드 인증과 전자 서명 방식이 있다.

 

모든 로그인은 /bin/login 프로세스가 전담.

 

로그인 기록 파일
/var/log/messages
/var/log/secure : 원격 접속 기록

 

/etc/securetty : root에 대한 로그인 허용 관련 파일

-> CentOS 8에서는 해당 모듈이 비활성화되어 있어 이 파일이 없음.

 

원격 접속 데몬 sshd

클라이언트 설정 파일 /etc/ssh/ssh_config

ssh 서버 설정 파일 : /etc/ssh/sshd_config

 

SSH는 22번 포트를 사용하는 7 계층 프로토콜. 크게 보면 버전 1과 버전 2가 있는데, 버전 1이 보안상으로 좋지 않아 버전 2를 많이 쓴다고 한다.

 

접속 방식 : 원격 접속이다. 접속 후 명령을 실행한다는 것이 어디에서 실행하는 것인지 인지할 것.

1. 접속 과정 자세히 보기

-> ssh -vv 192.168.111.100

-> ssh 버전, 참고하는 설정 파일 등이 출력되며 접속한다. SSH 버전이 다르면 접속 안됨.

-> The authenticity of host~ 묻는 것은 최초 접속 시에 뜨는 것. yes 하면 호스트 키가 저장되는데...

 

호스트 키 : 서버는 먼저 클라이언트에게 서버가 가지고 있는 호스트 키를 전달

-> 홈 디렉터리의 .ssh/디렉터리에 known_hosts에 저장된다.

 

2. 지정 사용자로 접속

ssh -l 계정명 서버 IP 또는 ssh 계정명@IP주소

 

3. ssh 포트 변경 접속

ssh -l 계정명 -p 포트번호 서버IP

 

4. 전자 서명을 이용한 ssh 접속 : 위 3가지는 패스워드를 사용한 접속 방식이었다.

---

6교시

 

SSH 접속 시, 클라이언트는 접속할 서버가 알맞은 서버인지 검증하고, 서버는 접속 가능한 클라이언트인지 검증한다.

서버의 공개 키는 호스트 키라는 이름으로 ~/.ssh/known_hosts라는 파일에 저장된다.

인증을 위해서는 위 1번에서 yes로 호스트 키를 반드시 받아야 한다.

 

서버에서 /etc/ssh/sshd_config 파일을 보면

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

이 부분이 기본값이다. 주석 처리라고 해서 적용이 안되어있는 것이 아니다.

변경을 원할 때 주석을 해제하고 수정하는 것이다.

 

PermitRootLogin yes : root 로그인 허용

-> 보안에 좋지 않아 차단하는 경우다 많다.

PubkeyAuthentication yes : 전자서명 방식 인증

AuthorizedKeysFile      .ssh/authorized_keys : 전자서명 시 찾는 키 파일. 클라이언트들이 보낸 공개 키가 쌓여 있다.

#PermitEmptyPasswords no : 패스워드 없이도 인증 가능 X

X11Forwarding yes : 현재 서버가 GUI모드로 작동 중이라면 클라이언트가 GUI모드로 접속하는 것을 허용

 

 

전자 서명을 사용한 접속 방법 : slave -> master

master의 /etc/ssh/sshd_config 파일에서

PasswordAuthentication 주석 처리

PubkeyAuthentication 주석 해제

 

slave에서 su - user1 접속

ssh-keygen -t rsa 실행해서 키 생성 - 저장 경로, 패스워드 지정

-> 저장 경로를 가보면 개인키, 공개키(.pub)가 있다

-> 이제 원격 서버로 공개 키를 보내야 한다.

-> 원격 서버에서는 전송받은 공개 키를 ~/.ssh/authorized_keys에 추가해야 한다.

전용 명령어로 원격 서버에 파일 자동 생성

ssh-copy-id -i ~/.ssh/id_rsa.pub user1@192.168.111.100

-> 첫 전송(연결) 시에는 패스워드 인증을 켜놔야 한다.

-> 명령어 실행해서 전송하면, master 측의 ~user1/.ssh/authorized_keys에 전송받은 키가 저장되어 있다.

 

확인해보자. 주 설정 파일에서 다시 패스워드 인증 끈다.

전자서명 방식으로 접속하려면 접속 시 키를 지정해줘야 한다.

ssh -i ~/.ssh/id_rsa user1@192.168.111.100 : -i [키 경로] 옵션 추가

같은 키를 사용해서 root도 user1으로 접속할 수 있지만, 다른 일반 사용자는 키에 대한 권한이 없어 접속 불가.

 

master, slave에 각각 user2 생성 후 user1처럼 접속 실습

 

전자서명 기법, 비대칭/대칭 키 알고리즘 등의 과정에 대해 알아두기

---

7교시

 

스토리지/NFS 서버

 

NFS(Network File System)

-> 다른 컴퓨터의 파일 시스템을 마운트하고 공유하여 상대방의 파일 시스템 일부를 자신의 디렉터리처럼 사용할 수 있도록 한다.

-> 모든 컴퓨터가 각각 자원을 가지고 있을 필요가 없다.

-> 편리하지만 보안이 약하다. 그래서 보통 사설 공간에서 사용한다.

 

-> NFS 서버는 언제든지 클라이언트가 마운트 할 수 있도록 준비되어 있어야 한다.

-> NFS는 rpc.mountd와 rpc.nfsd 두 데몬을 가지고 있다. /etc/rc.dinit.d/nfs 스크립트로 두 데몬을 실행시킬 수 있다.

-> 관련 데몬이 많지만 nfs가 핵심. 나머지는 보안 기능

 

주 설정 환경 파일 /etc/exports에

/var/server_share/     192.168.111.0/24(rw,sync,no_root_squash,no_all_squash)

작성

[디렉터리] [클라이언트](option)

의 형식.

options
ro : 읽기 전용 모드
rw : 읽기 쓰기 모드
root_squash : 클라이언트의 root를 서버의 nobody 권한으로 설정
no_root_squash : 클라이언트의 root를 서버의 root 권한으로 설정
insecure : 인증되지 않은 액세스도 가능 쓰면 안 됨
sync : 클라이언트가 파일 쓰기 완료 후 디스크 동기화

 

vim /etc/idmapd.conf에서 도메인 설정

NFSv4에서 NFS의 ID와 이름을 일치시키기 위해 libnfsidmap 패키지 사용

클라이언트와 서버들이 함께 사용할 도메인 이름을 설정

Domain = chul.com을 상단에 대충 입력

 

exportfs -r : export 정보 refresh

 

RPC(Remote Procedure Call) 원격 프로시저 호출

systemctl enable rpcbind

systemctl enable nfs-server

firewall-cmd --permanent --add-service={nfs3,mountd,rpc-bind,nfs} 후 reload

lsof -i tcp:111 확인

exportfs -v : 검증

 

여기까지는 NFS 서버 설정, 이제 클라이언트 설정

sssd-nfs-idmap-2.4.0-9.el8_4.2.x86_64
libnfsidmap-2.3.3-41.el8_4.2.x86_64
nfs-utils-2.3.3-41.el8_4.2.x86_64

위 3개 패키지 설치 확인 후 

동일하게 vim /etc/idmapd.conf에 Domain = chul.com을 상단에 대충 입력

mkdir /mnt/client_share 만들고

showmount -e 192.168.111.100 : 공유되는 마운트 출력

mount -t nfs 192.168.111.100:/var/server_share/ /mnt/client_share/

-> nfs 타입으로 $3에 마운트 걸어서 사용

mount | grep server : 마운트 확인

 

이제 클라이언트 측에서 /mnt/client_share/에 뭔가 만들면, 서버 측의 /var/server_share/에도 생긴다.

-> root가 만들면 root:root, user1이 만들면 user1:user1

 

재부팅/umount 되면 NFS가 끊긴다. 그러면 클라이언트 측에서는 당연히 해당 디렉터리를 볼 수 없다. 서버 측에서는 볼 수 있고.

-> 클라이언트 측의 /etc/fstab에 등록해야 재부팅 후에도 유지

-> 192.168.111.100:/var/server_share/       /mnt/client_share/     nfs     defaults        0 0

-> 설정 후 재부팅해보면 다시 연결되어 있다.

 

복습 : master에 하드디스크 추가 후 NFS 작업해보기

---

8교시

 

자동 마운트 기능의 autofs 패키지 사용해보기. /etc/fstab 마운트 삭제 후

yum -y install autofs.x86_64 설치

vim /etc/auto.master

-> 마운트포인트   자동마운트설정파일

-> /mnt    /etc/auto.mount

-> /etc/auto.mount 파일에

client_share    -fstype=nfs,rw  192.168.111.100:/var/server_share 작성

-> /mnt 디렉터리 아래의 client_share 디렉터리에 nfs,rw 옵션으로 192.168.111.100:/var/server_share에 연결

-> /etc/fstab에 설정 후 master 서버에서 NFS 설정을 바꾸면 부팅이 안되지만, 이 방법은 일단 부팅은 된다. 훨씬 안전

 

-> 여기까지만 하면, 다시 마운트 하려면 해당 경로에 최소 한 번은 접근해야 마운트 된다.

 

-> 이러기도 싫다면 직접 매핑 설정.

-> 기존에 추가했던 /mnt    /etc/auto.mount을 삭제하고

/-      /etc/auto.mount 추가

-> /etc/auto.mount 파일에

/mnt/client_share       -fstype=nfs,rw  192.168.111.100:/var/server_share

로 수정

-> 이렇게 하면 접근 필요 없이 바로 접근된다.

 

내일은 iSCSI

---

3교시(11:40~12:20) DHCP 다시 듣기

7교시(16:50~17:00) NFS

 

대략 다음 주 화요일부터 Ansible