(20250807031)DNS서버, 키분배,해쉬함수

 

ns.kr
- ns.co.kr
  - ns.itclass.co.kr
      - www
      - host명

 

캐시파일만 가지고 있는 네임서버를 캐시네임서버라고 한다.

zone파일 : dns정보를 가지고 있는 파일

캐시파일 : root name server의 정보를 가지고 있는 파일

모든 dns서버는 root name server의 아이피를 포함시켜야 한다.

 

root name server

•  Authoritative DNS 서버를 찾기 위해서 접근한다. (이름을 반환하는 역할을 수행하지 않는다.)

 

Top-Level domain(TLD) server

• com, org, net등과 같은 상위 레벨 도메인과 모든 국가의 상위 레벨 도메인에 대한 책임이 있다.

ㄴ com : 일반 회사들이 등록, edu : 대학교 등록, net: 네트워크 관련된 기업들이 등록, org : 뭔지 모르겠으면 등록.(it에서는 비상용 서비스를 제공하는 것들)

• net TLD : Network solutions maintains servers

• edu TLD : 교육.

 

Authoritative DNS server (1차, 2차)

• 인터넷에 접근하기 쉬운 host를 가진 기관은 호스트 명을 IP로 매핑하기 위한 DNS 레코드를 제공하 는데 책임 DNS서버가 레코드를 갖는다.

• 일부 서비스 제공자의 책임 DNS서버에 이 레코드를 저장하도록 비용을 지불할 수도 있다.

ㄴ 책임 dns서버는 도메인 트리 안에 있어야 작동이 된다.

 

Cache DNS server(Forwarder) - 자기가 관리하는 도메인이 없다. (로컬네임서버의 역할은 충분히 한다.)

• 엄격한 계층 구조에 포함되어 있지 않다.

• IP 매핑을 위한 도메인 정보를 갖지 않는다.

• 호스트의 질의에 대답만을 제공한다.

• Local DNS 서버로 authoritative DNS보다 많이 쓰인다.

 

 

Cache DNS 서버 설정

 

1. DNS 서버 설치 및 설치 확인

2. 환경 설정

      • /etc/resolv.conf

3. /etc/named.conf 파일 설정

4. Cache 파일 확인

      • named.ca 파일

5. name 서버 시작

# systemctl [start | stop | status] named.service

 

•  named.ca 파일은 ftp.rs.internic.net에서 다운가능하다.

•  Cache DNS 서버는 주로 Local DNS 서버로 많이 이용된다.

 

DNS 서버 구성

• 데몬 : /usr/sbin/named

• 관리 스크립트 : /usr/lib/system/system/named.service

• 환경 설정 파일 : /etc/named.conf - 유일한 dns 환경설정파일

• 설정 파일 경로 : /var/named/- named.ca와 여러 zone 파일들 - (책임 dns서버를 만들면 무조건적으로 만들어야 함.)

• 이외 관련 파일 : /etc/resolv.conf, /etc/host.conf(이건 보통 없음.)

 

• 실행을 위한 최소 권한
    - /etc/named.conf, /var/named, /var/named/*
    - 그룹 소유자는 반드시 named로 정의한다.

 

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

 

실습

Cache DNS 서버  만들어 보기

DNS를 테스트할 Client  서버    : 192.168.10.192

 

/etc/named.conf

 

options {

         directory "/var/named";

};

 

zone "." {

         type hint; file "named.ca";

};

 

이 부분 빼고는 다 지워줍니다. 

설정이 끝나면 

# systemctl start named.service

# systemctl enable named.service

 

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

실습

 

Authoritative DNS 서버 만들기

 

도메인네임서버명을 ast12.sec로 만들기

네임서버 : ns.ast12.sec → 192.168.10.156

 

/etc/named.conf

 

zone "te.sec." {

         type master;

         file "te.sec.zone";

};

추가해 주기

 

/var/named에 ast12.sec.zone을 만들어 줍니다.

만들어준 다음 그룹을 named로 바꿔줍니다.

그리고 밑에 내용을 추가해 줍니다.

 

# systemctl restart named.service

 

157에서 확인을 해보면

 

[root@linux157 ~]# nslookup ftp.ast12.sec

Server: 192.168.10.156

Address: 192.168.10.156#53

 

Name: ftp.ast12.sec

Address: 192.168.10.157

 

 

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

---

암호학

 

키관리 = 키를 주고받는 방법

 

 

비밀키 분배의 어려움

 

물리적인 방법으로 전달

• 링크 암호화에서 적용 가능

• 단대단 암호화에서 적용 어려움

 

이전의 키를 사용하여 암호화된 새로운 키를 전송

• 링크 암호화나 단대단 암호화 모두 적용 가능

• 공격자가 어떤 한 키를 안다면 이후의 모든 키가 노출

 

제 3자(키 분배 센터)를 통하여 키 분배

• 단대단 암호화에서 널리 채택

• 사용자는 키 분배 센터와 유일한 키를 공유

 

 

KDC를 이용한 키분배 방법(Kerboros) - local네트워크에서 사용한다.

 

※ 키 분베센터는 가입자에게 세션키를 나눠줍니다. 

※ 키 분베센터에서 A, B가 한 번은 상면을 해야 합니다.

※ A, B가 키 분배 센터에 등록을 하면 식별정보가 정해지고 마스터키를 나누어 가집니다.

※ 마스터키는 키분배센터와 통신할 때만 사용하기 때문에 A, B가 비밀키(세션키)를 나누어 가져야 합니다.

(1) Request || ID(A)

     ㄴ A가 B랑 통신을 하기 위한 세션키를 키 분베센터에 보내달라고 한다.

(2) EKA [SK, ID(B), T]

     ㄴ 키 분베센터에서 세션키를 A한테 보낸다. 보낼 때 세션키와, B의 신원정보, 난수 T를 키 분베센터에서 받은 마스터키로 암호화해서  보낸다.

(2) EKB [SK, ID(A), T]

     ㄴ  키 분베센터에서 세션키를 B한테 보낸다. 보낼 때 세션키와, A의 신원정보, 난수 T를 키 분베센터에서 받은 마스터키로 암호화해서  보낸다.

(3) ESK [ID(A), T]

    ㄴ A의 신원정보와 난수 T를 세션키로 암호화해서 B에게 보낸다. B는 자신이 가지고 있는 난수 T와 비교를 하고 A의 신원정보가 맞으면 받고 아니면 세션을 끊어버린다.

(4) ESK [ID(B), T+1] - T

    ㄴ A의 신원정보가 확인이 되면 B가 A에게 자신의 신원정보, 난수 T를 세션키로 암호화해서 A에게로 보냅니다.(T+1은 미리 악속 된 연산.)

이런 과정을 거치고 통신을 시작합니다.

만약 다시 접속하려면 새로운 세션키를 다시 받습니다.

 

 

 

공개키에 의한 세션키 분배 (SESAME) - lan에서는 사용하지 않고 인증서에서 사용하는 기본적인 방법

 

※ 위조된 공개키가 올라오는 경우가 있기 때문에 A, B가 공개키 기관에 직접 가서 자신의 공개키를 등록합니다

※ 공개키 기관의 공개키를 A, B가 서로 가져갑니다.

 

 

 

(1) 공개키 기관에 B의 공개키를 보내달라고 요청을 한다.

(2) B의 공개키를 공개키 기관의 개인키로 암호화를 해서 A에게 전달을 합니다.

    ㄴ A는 공개키 기관의 공개키를 가지고 있기 때문에 그 공개키로 암호를 풀어 B의 공개키를 알 수 있습니다. 

(3) A가 자신의 신원정보, N1이라는 난수를 B의 공개키로 암호화해서 B에게 보냅니다.(진짜 B인지 확인하는 난수)

(4) B는 공개키 기관에 A의 공개키를 보내달라고 요청을 합니다.

(5) A의 공개키를 공개키 기관의 개인키로 암호화해서 B에게 전달을 합니다.

    ㄴ B는 공개키 기관의 공개키를 가지고 있기 때문에 그 공개키로 암호를 풀어 A의 공개키를 알 수 있습니다. 

(6) B는 자신이 받은 난수 N1과 난수 N2를 A의 공개키로 암호화해서 A에게 보냅니다.(진짜 A인지 확인하는 난수)

(7) A가 아까 받은 난수 N2를 B의 공개키를 통해 암호화해서 B로 보냅니다.(상대방들이 진짜 A, B인지 확인이 마쳐진 상태)

(8) A가 세션키(Ks)를 만들어서 자신의 개인키로 암호화하고, B의 공개키로 암호화해서 보내면, B는 받아서 자신의 개인키로 풀고, A의 공개키로 풀면 세션키를 둘이 나누어 가지게 됩니다.

 

통신이 끝나면 세션키는 무조건 버립니다.

시리얼넘버를 들고 공개키기관에서 이거 써도 돼요? 해서 써도 된다고 하면 바로 사용한다.(상태 검증)

 

 

 

해쉬 함수

 

정의

• 임의의 길이(M)를 취해서 정해진 크기(h)의 Message Digest를 만드는 one-way function(H)

•  디지털서명, 인증, 등의 서비스 제공

 

 

● 해쉬함수의 요구 조건

• 어떤 크기의 메시지 M에도 적용 가능

• H는 고정된 크기의 hash code를 만듦

• H(M)은 어떤 주어진 M에 대해서도 계산하는 것이 쉽다.

• 주어진 hash code h에 대해, H(M) = h인 M을 찾는 것이 계산적으로 실행불가능(one-way)

• 어떤 주어진 블록 M에 대해서, H(M’) = H(M)인 M과 M’가 서로 다른 것을 찾는 것이 계산적으로 실행 불가능

    - 이게 되면 망가진 해쉬코드

• H(M’) = H(M)인 어떤 (M, M’) 쌍을 찾는 것이 계산적으로 실행 불가능(collision free)

    - 메시지는 다른데 해쉬코드가 같다는 소리(이러면 안 된다.)

 

 

패스워드는 해쉬코드로 저장한다.

암호화하면 복호화하면 되지만, 해쉬코드로 되어있으면 원문을 찾아낼 수가 없다.

 

 

평문= 암호일 때만 사용함.

해쉬 = 원래문서를 암호문이라 하지 않고 메시지라고 한다.

 

메시지 : 길이가 고정되어있지 않다.

Message Digest : 길이가 고정되어 있음.

↓

똑같은 메시지 다이제스트가 나오는 메시지가 무한대 있기 때문에 복원 불가능(메시지는 10개 1000개씩 되지만 메시지 다이제스트는 2^128승 이렇게 고정되어 있기 때문.)

똑같은 메시지 다이제스트를 찾으면 비밀번호를 뚫을 수 있다..

ㄴ 이걸 방지하기 위해 솔트를 사용. 하지만 의미는 없음... 사용하는 이유는 내부관리자가 해쉬값만 보고 비밀번호를 유추하는 것을 어렵게 만들기 위해서 사용

 

패스워드를 공격  ▶생일공격

ㄴ 원문을 찾는 게 아니라 해쉬코드가 같은 놈을 찾으면 되기 때문에.