04. OSI 7 Layer 계층 별 프로토콜 (3/3) - Telnet, SSH, HTTP, HTTPS, DNS

안녕하세요?

계층 별 프로토콜을 다루고 있습니다.

이번에는 SSH, Telnet, HTTP, HTTPS, DNS 관련 내용을 정리해 보겠습니다.

 

프로토콜은 자료를 찾으면 계속 나올 정도로 양이 방대한 것 같습니다.

부족한 내용이 있는 점 양해 부탁드립니다.

같은 이유로 프로토콜들의 특징을 전부, 오래 기억하는 것도 쉽지 않습니다.

- 중요한 내용을 파악하는 것을 우선으로

- 자신의 현재 시점에서 필요한 지식에 빠르게 접근하는 것에 초점을 두는 것이 좋겠습니다. 

 

순서는 아래와 같습니다.

1. OSI 7 Layer 계층 별 프로토콜 정리

2.

• FTP (컨트롤채널, 데이터채널, 액티브 모드, 패시브 모드)
• SMTP, POP3, IMAP (이메일 전송 프로토콜)
• ICMP (오류 메시지)

3.

• Telnet, SSH 
• HTTP, HTTPS
• DNS

---

 

Telnet 과 SSH (Secure Shell) :

Telnet과 SSH를 묶어 전반적인 내용을 함께 이해하면서 학습함.

 

Telnet은 주로 텍스트 기반의 터미널 환경을 원격으로 접속하기 위해 사용한다.

그러므로 CLI(Command Line Interface) 기반의 시스템에 사용된다.

 

Telnet은 과거 운영체제 플랫폼에 대해 제한이 없었기 때문에 원격 접속의 용도로 편리하게 많이 사용했다.
그러나 텔넷은 데이터를 암호화하지 않고 평문으로 전송하기 때문에 여러가지 민감한 정보가 쉽게 노출되는 것이 취약점으로 드러났다. 따라서 Telnet은 보안 상의 이유로 거의 안쓰지만 필요시에 윈도우 등 환경 내에서 따로 활성화해서 사용한다. 이러한 점을 보완하기 위해 SSH라는 프로토콜을 디폴트로 사용하게 되었다.

 

WireShark같은 패킷 분석 프로그램을 이용하면 원격 접속 과정에서 옮겨지는 비밀번호나 파일 내용 등의 데이터를 탈취할 수 있음. 때문에 이를 암호화하는 SSH 기술이 등장했고, 현재 원격 접속 보안을 위한 필수적인 요소로 자리잡고 있다. 그리고 클라우드 서비스에서 제공하는 서버는 기본적으로 원격 접속을 해서 접근하고 사용한다. 이 때문에 NBP나 AWS와 같은 CSP(Cloud Service Provider, 클라우드 서비스를 제공하는 곳)에서 서버 생성시 필수적으로 SSH 보안 과정을 거친다.

즉, Telnet (텔넷) 과 SSH는 원격 호스트에 접속하기 위해 사용하는 프로토콜이다.
SSH는 Telnet에 암호화를 추가한 보안 프로토콜이다.

 

23번 포트 사용: Telnet 클라이언트는 일반적으로 TCP의 23번 포트를 사용하여 서버에 접속을 요청한다.

22번 포트 사용: SSH 클라이언트는 일반적으로 TCP의 22번 포트를 사용하여 서버에 접속을 요청한다.

 

Telnet 작동 방식 (통신 과정) :

Telnet은 네트워크 상에서 텍스트 기반의 터미널 에뮬레이션을 제공하는 프로토콜 및 클라이언트 소프트웨어이다.

주로 원격 시스템에 접속하여 명령을 실행하거나 데이터를 송수신하는 데 사용된다. 

 

Telnet 클라이언트는
원격 서버의 IP 주소나 도메인 이름 및 Telnet 서비스가 실행 중인 포트(기본 23번)로 접속을 시도한다.

접속이 성공하면 클라이언트와 서버 간에 텍스트 기반의 통신이 이루어진다.
사용자는 명령을 입력하고, 서버는 해당 명령을 처리하고 그 결과를 클라이언트에게 보내준다.

 

이러한 과정에서 상술한 정보 노출 등의 문제가 발생할 수 있기 때문에 현재는 Telnet 사용을 권장하지 않는다.

대안으로 SSH를 더 많이 사용한다.

 

SSH 작동 방식 (통신 과정) :

접속 요청 >> 인증 >> 세션 설정 >> 명령 실행 및 파일 전송 >> 세션 종료

 

접속 요청: 클라이언트는 SSH를 사용하여 원격 서버에 접속을 요청한다.

기본적으로 TCP의 22번 포트를 사용하며, 포트 포워딩 기능을 통해 다른 서비스에 접근할 수 있다.

인증: 서버는 클라이언트의 신원을 확인하기 위해 사용자의 계정 및 비밀번호를 요청하거나 공개키 인증을 통해 접속을 허용한다.

세션 설정: 클라이언트와 서버 간에 안전한 통신을 위한 암호화된 세션을 설정한다.

원격 명령 실행 및 파일 전송: 클라이언트가 명령을 실행하거나 파일을 전송할 수 있다.

세션 종료: 작업이 완료되면 클라이언트와 서버 간의 연결이 종료된다.

 

대칭키와 비대칭키

SSH를 구성하는 핵심적인 키워드는 ‘KEY(키, 열쇠)’이다. 사용자(클라이언트)와 서버(호스트)는 각각의 키를 보유하고 있으며, 이 키를 이용해 연결 상대를 인증하고 안전하게 데이터를 주고 받게 된다. 키를 생성하는 방식으로는 ‘대칭키’와 ‘비대칭키’ 방식이 있다. SSH는 효율성과 안전성을 고려해 대칭키 암호화와 비대칭키 암호화를 혼합하여 사용하는 하이브리드 암호화 시스템을 채택한다.

1. 대칭키(Symmetric Key) 암호화:

대칭키는 주로 데이터 전송에 사용되며, SSH에서는 실제 데이터를 암호화하는데에 대칭키를 사용

특징:

동일한 키를 암호화와 복호화에 사용하는 방식이다. 
빠르고 효율적이지만, 키 관리에 대한 어려움이 있다.

동작 방식:

데이터를 보내기 전에 먼저 대칭키를 사용하여 암호화를 한다.  
수신 측에서는 동일한 키를 사용하여 데이터를 복호화 한다.

2. 비대칭키(Asymmetric Key) 암호화:

비대칭키는 주로 안전한 키 교환 및 디지털 서명에 사용된다.
SSH에서는 초기 연결 단계에서 비대칭키를 사용하여 대칭키를 안전하게 교환한다.

특징: 

공개 키와 비밀 키 두 개의 키 쌍을 사용한다.

공개 키로는 암호화만 가능하며, 비밀 키로는 복호화만 가능하다.
보안성이 높지만 대칭키에 비해 계산 비용이 높다.

동작 방식: 

수신 측은 공개 키로 암호화된 데이터를 비밀 키를 사용하여 복호화 한다.
공개 키로 암호화된 데이터는 해당 공개 키만 대응되는 비밀 키로만 해독이 가능하다.

 

3. SSH의 하이브리드 암호화: 

신뢰성 있는 키 교환과 데이터 보호 목적

 

SSH는 대칭키와 비대칭키를 혼합하여 사용한다.
초기 연결에서는 비대칭키를 사용하여 안전하게 대칭키를 교환한다.
이후 데이터 전송은 대칭키를 사용하여 암호화하며, 실제 데이터를 효율적으로 전송한다.

 

SSH는 암호화된 통신을 하므로 텔넷의 취약점을 대체-보완하는 부분이 강점이다.

유지보수 등 특별히 원격 접속을 사용해야 할 경우 SSH를 통해 원격 접속을 지원한다.
SSH가 적용되어있는, SSH를 지원하는 프로그램 : 푸티, Secure CRT 등
이런 프로그램들을 통해서 원격으로 접속을 지원한다.

 

SSH와 Telnet 비교

 

---

 

HTTP 와 HTTPS :

HTTP는 월드 와이드 웹(World Wide Web)에서 정보를 주고받기 위한 프로토콜
클라이언트와 서버 간 데이터 교환, HTML 문서, 이미지, 동영상, 스크립트 등을 전송하는 데 사용한다.

 

Request - Response
TCP/IP 프로토콜을 사용하며, 기본적으로 연결 지향적이다.

클라이언트가 서버에게 요청을 보내면 서버는 응답을 보내고 연결이 종료된다.

HTTP 메시지는 헤더(Header)와 본문(Body)으로 구성된다.

헤더: 메시지에 대한 부가 정보를 포함한다.

클라이언트와 서버 간에 전달되어야 할 설정이나 메타데이터가 여기에 포함된다.

 

본문: 요청이나 응답의 본문으로, 실제 전송되는 데이터가 여기에 위치한다.

 

클라이언트가 서버에게 요청 메시지를 보낸다.
요청 메시지에는 요청 종류(GET, POST 등), 요청한 자원의 위치(URL), 사용하는 프로토콜 버전 등이 포함된다.

 

서버는 클라이언트에게 응답 메시지를 보낸다.
응답 메시지에는 상태 코드(성공, 실패 등), 응답하는 자원의 유형, 실제 데이터 등이 포함된다.

 

HTTP, HTTPS 응답 메시지의 상태 코드:

각각의 코드는 요청이 성공했는지 또는 어떤 문제가 발생했는지를 나타낸다.
예: 200 OK(성공), 404 Not Found(찾을 수 없음), 500 Internal Server Error(서버 오류) 등.

 

평문 통신과 암호화 통신
HTTP:

보안 인증서를 요구하지 않는다.

평문 통신을 사용하여 데이터를 암호화하지 않고 전송 

네트워크 상에서 데이터를 가로챌 경우, 그 내용을 쉽게 볼 수 있다는 보안 문제가 발생함.

중간자 공격(MITM), 스니핑(Sniffing) 같은 공격에 취약하다.

 

HTTPS:

HTTP에 SSL/TLS 프로토콜로 데이터 암호화 기술을 적용한 프로토콜

웹 서버는 HTTPS 연결을 위해 SSL(Secure Sockets Layer)/TLS(Transport Layer Security) 인증서를 사용.

인증서는 신뢰할 수 있는 인증 기관(Certificate Authority, CA)에 의해 발급되며, 서버(웹 사이트)의 신뢰성을 증명함.

 

HTTPS는 대칭키와 비대칭키 암호화를 혼합하여 사용한다.
초기 연결에서는 비대칭키를 사용하여 안전한 대칭키를 교환한다.

그 이후의 데이터 전송은 대칭키를 사용하여 암호화를 한다.

이를 통해 서버와 클라이언트 간의 통신이 암호화되며 중간에서 데이터를 가로채도 해독이 어려움.

 

그러나 HTTPS 자체가 완벽한 보안을 보장하지는 않는다.

취약한 SSL/TLS 구현이나 잘못된 설정이 있으면 보안 문제가 발생할 수 있다.

 

특징 비교

포트번호

HTTP: 기본적으로 80번 포트를 사용합니다.
HTTPS: 기본적으로 443번 포트를 사용합니다.

 

URL 구조

HTTP: http://로 시작하는 URL을 사용합니다.
HTTPS: https://로 시작하는 URL을 사용합니다.


HTTP의 다양한 메소드 정리
GET: 서버에서 리소스를 요청하고 가져오는 메소드로 URL에 데이터를 포함하여 전송한다.
POST: 서버에 데이터를 전송하여 리소스를 생성하거나 업데이트한다. 데이터는 요청 본문에 포함된다.
PUT: 서버에 리소스를 생성하거나, 리소스를 업데이트하는 데 사용된다. 기존 데이터를 대체한다.
DELETE: 서버에서 지정된 리소스를 삭제하는 메소드이다.
OPTIONS: 서버에서 사용할 수 있는 메소드들을 요청한다.

HEAD: 서버로부터 응답 헤더만 요청하고, 실제 데이터는 요청하지 않는다.
PATCH: 리소스의 일부만을 업데이트하는 데 사용된다.

 

HTTPS Everywhere 원칙: 보안성 강화를 위해, 웹사이트들은 사용자의 데이터를 암호화하여 전송해야 한다는 원칙

---

 

DNS (Domain Name System) :

 

DNS는 호스트의 도메인 이름을 IP 주소로 변환하거나 그 반대의 변환을 수행하는 인터넷의 분산 데이터베이스 시스템이다. DNS는 평소에는 UDP로 통신하는 대표적인 프로토콜 중 하나이다. 그러나 특정한 경우에는 TCP로 통신한다. 어떤 경우에 UDP로 통신하고 TCP로 통신하는지를 살펴보면 다음과 같다.

 

포트 번호: DNS의 기본 포트는 53번이며 UDP와 TCP 모두 이 포트를 사용한다. 

아래는 DNS와 TCP/UDP 간의 관계를 설명한 것이다.

UDP를 통한 DNS: 

DNS는 주로 UDP를 사용하여 클라이언트와 서버 간의 일반적인 쿼리와 응답을 처리한다. UDP를 사용하는 이유는 대부분의 DNS 쿼리와 응답은 512바이트 이내로 크기가 작기 때문이다. 이 방식은 빠른 응답 속도가 요구되는 상황에서 적합하다. 또한 UDP는 연결이 없는 프로토콜로 간단하고 빠르게 데이터를 전송할 수 있기 때문에 DNS에서 많이 사용된다. UDP는 패킷 손실이 발생할 수 있으며 이를 보완하기 위해 DNS는 재시도 및 타임아웃과 같은 메커니즘을 사용한다.

 

TCP를 통한 DNS:

대부분의 DNS 쿼리는 UDP로 이루어지지만 일부 쿼리는 (512바이트를 초과하여) 크기가 크거나 응답이 클 경우 TCP를 사용한다. 예를들어 DNSSEC(도메인 보안 확장)과 같은 보안 확장이 사용될 때, 혹은 대용량 데이터를 전송해야 하는 경우에 TCP를 사용한다. 캐시된 데이터가 아닌 직접 DNS 서버에게 쿼리할 때, DNS 서버 간의 존 전송(Zone Transfer)과 같이 전체 도메인 데이터 전송 시에도 TCP가 사용된다. TCP는 데이터의 신뢰성과 순서 보장을 위해 연결 지향적이므로, 대량의 데이터를 처리하는 데 적합하다.

계층 구조: DNS는 계층 구조로 이루어져 있다. 최상위에는 루트 도메인이 있고 그 하위에는 일반적으로 gTLD(generic Top-Level Domain)와 ccTLD(country Code Top-Level Domain), 그리고 이를 사용하는 도메인들이 계층적으로 구성된다.

Caching: DNS는 캐싱을 지원하여 이전에 해석한 도메인 이름과 IP 주소의 매핑을 일정 기간 동안 저장한다. 이를 통해 동일한 쿼리에 대해 빠르게 응답할 수 있다.

도메인 네임의 구조: 도메인 이름은 오른쪽에서 왼쪽으로 계층적으로 구성된다. 예를 들어 "http://www.example.com"에서 "com"은 최상위 도메인(TLD)이고 "example"는 이를 사용하는 도메인, "www"는 서브도메인이다.

TTL(Time to Live): DNS 응답은 TTL 값과 함께 전송된다. TTL은 캐시에 저장된 도메인 정보의 유효 기간을 나타내며 이 기간 동안은 저장된 정보를 사용하고 TTL이 만료되면 새로운 쿼리를 통해 업데이트한다.

별칭(Alias) 및 CNAME 레코드: DNS는 도메인에 여러 개의 별칭을 부여할 수 있다. 이는 하나의 호스트명이 여러 가지 다른 도메인에 연결되어 있는 경우 유용하다. CNAME(Canonical Name) 레코드를 사용하여 이러한 별칭을 설정할 수 있다.

MX(Mail Exchange) 레코드: MX 레코드는 이메일을 수신하는 메일 서버를 지정한다. 도메인에 대한 MX 레코드는 이 도메인으로 전송된 이메일을 처리하는 메일 서버를 가리킨다.

도메인 등록 및 WHOIS: 도메인은 등록 기관을 통해 등록되며 WHOIS 서비스를 통해 도메인의 소유자 정보 등을 확인할 수 있다.

IPv6 지원: DNS는 IPv6 주소를 지원하여 IPv4와 함께 사용된다. 이는 IPv6 환경에서 도메인 이름을 IPv6 주소로 해석하는 데 사용된다.

 

다시 한 번 DNS의 프로토콜 : UDP와 TCP 

UDP와 TCP의 차이점: UDP는 연결을 설정하지 않고 데이터를 전송하기 때문에 속도가 빠르지만, 데이터의 전송 여부를 확인하거나 재전송하는 과정이 없다. 이에 비해 TCP는 신뢰성 있는 전송을 보장하기 위해 연결 설정 후 데이터를 주고받고, 데이터가 손실되거나 순서가 뒤바뀌었을 때 이를 재전송하거나 재정렬한다. 이러한 차이점은 특히 데이터 크기가 작을 때 UDP가 선호되는 이유이며, 크기가 커지면 TCP를 통해 안정적인 전송이 필요해진다.

데이터 크기와 통신 방식: DNS는 기본적으로 512바이트 이하의 데이터 전송 시에는 UDP를 사용하고, 512바이트를 초과하는 경우에는 TCP로 전환하여 통신을 수행한다. UDP는 빠르지만 데이터 전송에 한계가 있기 때문에, 대량의 데이터가 필요한 응답은 TCP로 처리되며 이를 통해 데이터 손실 및 오류를 방지할 수 있다.

---

 

네. 이번 글에서는 SSH, Telnet, HTTP, HTTPS, DNS 에 대해 알아보았습니다. 

 

1. Telnet은 평문으로 전송하여 보안에 취약하지만 SSH는 대칭키-비대칭키(공개키,비밀키)로 데이터를 암호화하여 안전한 '원격 접속'을 제공한다. 포트 Telnet은 23번, SSH는 22번
2. HTTP는 80번 포트로 평문 통신을 사용하는 반면, HTTPS는 443번 포트로 SSL/TLS를 통해 데이터를 암호화하여 안전한 통신을 제공한다.  
3. DNS는 도메인 이름을 IP 주소로 변환하며 53번 포트를 사용하고, 주로 UDP를 사용하지만 대용량 데이터 전송 시에는 TCP를 사용한다.

 

감사합니다!