일일 정리

네트워크 구성 실습, SSH 서버, 해시 함수, 전자 서명

mysecurity 2025. 2. 17. 22:37

목차

1. 네트워크 구성 실습

1-1 라우팅 설정

 

2. SSH 서버

2-1 2-1 안전 세션 설정

2-2 설치와 실행

2-3 주요 설정

2-4 리눅스에서 SSH 키 로그인

 

3. 해시 함수

3-1 해시 함수의 이해

 

4. 전자 서명

4-1 전자 서명의 이해

4-2 공개키를 이용한 전자 서명

 

 

1. 네트워크 구성 실습

1-1 라우팅 설정

지난 실습에서 생성한 라우터의 /etc/sysctl.conf 파일의 내용을 1 로 수정하여 패킷이 자신의 몸을 통과할 수 있도록 설정하였다.

현재 네트워크 구성도

 

이후 192.168.12.12 컴퓨터에서 8.8.8.8로 핑을 보낼 수 있는 것을 확인하였으나 이는 가상 구현 시스템의 영향으로 연결된 것으로 실제로는 아직 192.168.12.12 컴퓨터는 외부와 연결되지 않았다.

정상적인 라우팅을 위해 다음과 같은 설정을 진행한다.

 

● 10.140 에서192.168.12.12 네트워크 접속 설정 (Windows 설정)

route ‐p add  [IP]  MASK [MASK]  [GW_IP]

route ‐p add 192.168.12.0 MASK 255.255.255.0 192.168.11.254

 

● 11.11 에서192.168.12.12 네트워크 접속 설정 (Linux 설정)

route add ‐net 192.168.12.0 netmask 255.255.255.0 gw 192.168.11.254

 

설정이 정상적으로 완료되었다면 이후 윈도우인 10.140 , 11.11 그리고 12.12 컴퓨터가 모두 서로 통신이 가능해지며 셋 모두 DNS 서버 8.8.8.8 과 통신이 가능함을 확인할 수 있다.

 

2. SSH 서버

+

ssh, telnet 등은 1티어 아키텍쳐를 흉내내는 프로그램이다.

※ 1티어 아키넥쳐 : 1대의 호스트에 다량의 터미널이 연결된 환경

    - 호스트: 컴퓨터

    - 터미널: 모니터, 키보드 등의 I/O 장치 (2025-03-06 추가)

 

2-1 안전 세션 설정

서버와 클라이언트 간의 보안 세션 설정은 서버 측에서 공개키/개인키를 생성하여 진행한다. 전체적인 순서는 다음과 같다.

 

1. 애초에 서버 공개키를 클라이언트에게 다이렉트로 전달해놓는다.

2. 클라이언트가 서버에 SSH 접속을 요청한다.

3. 서버와 클라이언트 간 핸드셰이킹을 통해 서로의 버전, 알고리즘 등을 확인한다.

4. 클라이언트는 세션키를 생성해 서버 공개키로 암호화해 서버에게 전달한다.

5. 보안 세션 설정 후 통신한다.

 

세션키 생성은 RSA 혹은 DSA를 사용한다.

보안 세션은 IDEA 혹은 DES를 사용한다.

 

2-2 설치와 실행

● SSH 서버설치확인

# yum list openssh*

 

● SSH 서버실행

# systemctl   start   sshd.service : ssh 서버를 실행한다.

                    restart                      : ssh 서버를 재실행한다.

                     stop                        : ssh 서버를 정지시킨다.

 

● 관련파일

데몬: /usr/sbin/sshd

스크립트: /usr/lib/systemd/system/sshd.service

환경 설정 파일: /etc/ssh/sshd_config

공개키 저장 경로: $HOME/.ssh/

 

2-3 주요 설정

● /etc/ssh/sshd_config

# 된 부분은 기본값을 의미한다. 수정을 원하는 경우 #을 삭제하고 내용을 수정한다.

 

#Port 22                                : Port 번호지정

#Protocol 2,1                        : SSH1, SSH 2 지원

#ListenAddress                     : 여러 개의 IP 중 SSH 이용할 IP

#PermitRootLogin yes          : Root 계정 로그인 허용

#PermitEmptyPasswords no : 암호 없는 계정에 대한 접속 여부

 

● sshd_config를 이용한 사용자 제한

사용자를 제한하는 방법으로는 계정으로 제한하는 방법, IP 주소로 제한하는 방법이 있다. IP주소로 제한하는 것은 방화벽의 기능으로 넘어가 ssh 설정에서 없어지는 추세이다.

 

AllowUsers [유저] [유저] … Allowgroups [그룹] [그룹] …

: 지정된 유저나 그룹만 접속이 가능하다.

 

DenyUsers [유저] [유저] … DenyGroups [그룹] [그룹] …

: 지정한 유저나 그룹은 접속이 불가하다.

 

- Deny 설정이 더 강하다.

: 접근 허용 대상과 불허 대상 설정이 중복될 경우, 불허로 설정된다.

: allowusers root, allowgroups te 설정 시 아무도 허용되지 않는다.

 

2-4 리눅스에서 SSH 키 로그인

이전 실습에서 puttygen을 통해 윈도우에서 공개키/개인키를 생성해 리눅스 로그인에 이용해보았다. 리눅스 클라이언트에서도 이와 같이 키를 이용한 로그인이 가능하다.

 

① 클라이언트 키 생성

# ssh‐keygen  ‐t  <type>  ‐b  <bits> 

‐t : rsa, dsa

‐b : rsa(768~2048), dsa(1024)

개인키: id_rsa, 공개키: id_rsa.pub(authorized_keys)

 

② 공개키를 서버로 이전

ssh‐copy‐id  계정@IP

위의 명령어를 실행하면 다음과 같이 서버의 ~/.ssh/authorized_keys로 공개키가 저장되는 것을 확인할 수 있다.

서버에 저장된 공개키

 

③ 접속 확인

ssh 계정@IP

위의 명령어로 클라이언트에서 서버로 접속을 할 수 있다. 이때 클라이언트의 개인키가 인식이 되지 않는다면 

ssh -i 개인키위치 계정@IP 

위의 명령어로 접속할 수 있다.

 

만약 공개키/개인키 생성을 리눅스에서 ssh‐keygen 명령어를 사용한 것이 아닌 puttygen에서 생성한 경우 키 저장방법은 다음과 같다.

 

공개키: puttygen에서 직접 복사해 서버의 ~/.ssh/authorized_keys로 저장한다.

개인키: puttygen에서 export openssh key로 개인키의 형식을 바꾸고 직접 복사에 클라이언트의 ~/.ssh/id_rsa로 저장한다.

직접 저장하는 경우 개인키 파일의 퍼미션을 chmod 600 명령어를 통해 소유자 root에게만 rw권한을 부여해야 퍼미션 경고 없이 정상적인 로그인이 가능하다.

개인키 형식 변환

 

3. 해시 함수

3-1 해시 함수의 이해

해시 함수는 메시지 인증 코드에 대한 변형으로, 임의의 길이(M)를 취해서 정해진 크기(h)의 Message Digest(= 해시코드)를 만드는 one‐way function(H)이다. 

- one-way function: 결과물로 원문을 추적할 수 없다.

 

디지털 서명, 인증 등의 서비스를 제공한다.

 

● 해시 함수의 요구 조건

- 어떤 크기의 메시지 M에도 적용 가능하다.

- H는 고정된 크기의 해시코드를 만든다.

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

- 주어진 해시코드 h에 대해, H(M) = h인 M을 찾는 것이 계산적으로 실행 불가능하다.(one‐way)

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

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

 

단순 해시 함수는 메시지를 n비트 블록 m개로 나누어 블록끼리 XOR하여 출력되는 블록을 해시코드로 한다.

 

● 해시 함수의 종류

해시 함수의 종류

 

MD5와 SHA의 차이

MD5와 SHA의 차이

 

4. 전자 서명

4-1 전자 서명의 이해

●배경

1976년 Diffie와 Hellman에 의해 제시된 개념으로, 정보화 사회에서 전자 문서 사용의 증가로 인해 데이터 무결성, 사용자 인증, 부인 방지 서비스가 필수적으로 요구되어 제시되었다.

 

● 목적

기밀성이 아닌 사용자 인증과 메시지 무결성 확보를 목적으로 한다.

전자 서명 = 사용자 인증 + 메시지 인증

 

● 전자 문서의 문제점

- 위/변조가 용이하다.

- 문서 작성 사실 입증이 곤란하다.

 

● 전자상거래의 문제점

- 거래 상대의 신원 확인이 곤란하다.

- 전송 내용의 비밀 유지가 곤란하다.

 

● 전자 서명의 필수 요구 속성 5가지

- 서명자 신원 확인

: 개인키의 소유자가 전자 서명 행위자임을 증명한다.

 

- 위조 불가

: 합법적인 서명자 외에는 전자 서명 생성이 불가능함을 증명한다.

 

- 변경 불가

: 서명한 문서의 내용과 서명의 변경이 불가능함을 증명한다.

 

- 부인 불가 

: 서명은 본인 이외에는 불가능함을 증명한다.

 

- 재사용 불가

: 다른 전자 문서의 서명으로 사용이 불가능함을 증명한다.

 

● 암호화 방법과 전자 서명

전자 서명은 전자 서명의 조건을 만족하면서 서명 방식과 검증 방식이 명확해야한다.

대칭키 암호 알고리즘에 의한 방법과 공개키 암호 알고리즘에 의한 방법이 있으나 현재 국내에서 사용하는 방식은 공개키 암호 알고리즘에 의한 '메시지 부가형 전자서명 방식'이다.

 

4-2 공개키를 이용한 전자 서명

전자 서명의 인감 증명 역할 ‐> ‘공개키’ 이며

서명자 A가 갖고 있는 인감  ‐> ‘개인키’ 이다.

 

- 전자 서명

: 서명자 A의 개인키로 데이터의 전자 서명을 생성한다.

: 서명자 A의 공개키로 전자 서명을 검증한다.

진행 과정은 다음과 같다.

전자 서명 진행 과정

 

① 해시코드(메시지 다이제스트)를 계산한다.

② 그것을 송신자의 개인키로 암호화한다. 이것이 전자 서명이다.

③ 이것을 메시지와 함께 수신자에게 보낸다.

④ 수신자는 먼저 수신 메시지의 해시코드를 계산한다.

⑤ 다음으로 송신자로부터 온 전자 서명을 송신자의 공개키로 복구한다.

⑥ 이전 메시지로부터 계산한 해시코드와 비교한다.

 

비교 결과가 같다면 메시지의 무결성과 근원지가 증명된 것이다.