목차
1. SSH-22
- 네트워크 상의 다른 컴퓨터에 로그인하거나 원격 시스템에서 명령을 실행하고 다른 시스템으로 파일을 복사할 수 있도록 해주는 응용 프로그램 또는 프로토콜
- Telnet을 대체하기 위해 설계되었으며, 강력한 인증 방법 및 안전하지 못한 네트워크에서 안전하게 통신을 할 수 있는 기능을 제공
- 높은 대역폭을 사용
- 공공 네트워크에 적합
- 원격 암호화된 연결
- 터널링 기능
- 데이터 전송
- 원격 제어
- 서로 다른 운영체제간 원격 불가(서버 <-> 서버)
1) 작동방식
키를 생성하여 공개키와 개인키가 만들어지고 개인키(Private key)는 클라이언트에 공개키(Public key)는 서버에 위치한다.
1. SSH Client가 SSH로 접속을 시도하면 SSH Server는 서로의 키가 일치하는지 확인하기 위해 서버의 공개키로 암호화된 메시지를 보낸다.
2. SSH Client는 가지고 있는 개인키를 이용해, 공개키로 암호화된 메시지를 복호화하여 SSH Server에 보낸다.
3. SSH Server는 SSH Client가 가지고 있는 개인키가 자신의 공개키와 한 쌍인 것을 확인한다.
(만약 한 쌍이 아닌 경우 복호화할 수 없다.)
4. 서로 한쌍의 키라는 것이 인증되면 클라이언트와 서버는 통신을 위한 대칭 키를 생성한다.
이 키는 세션 동안 서버와 클라이언트 간의 모든 통신을 암호화하는데 사용된다.
2) 대칭키의 생성과 교환 과정에서 키가 탈취될 위험에 대한 해결 방법
- 대칭키의 생성과 교환에 디피-헬먼 키 교환 알고리즘(Diffie-Hellman Key Exchange)이 사용된다.
- 이 방식을 통해 키 탈취 우려가 있는 대칭키를 양쪽에서 안전하게 생성할 수 있으며, 이후 통신은 이 대칭키를 사용하여 암호화된다.
2. Telnet-23
- 로컬 영역이나 인터넷에 있는 원격 시스템의 가상 터미널을 제공하는 클라이언트와 서버 간 응용 프로토콜
- TCP/IP 기반의 프로토콜
- NVT라는 가상 터미널의 개념을 사용 => 서로 다른 운영체제간 원격 연결이 가능하다.
- 보안 매커니즘을 사용하지 않고 일반 텍스트로 데이터를 전송하므로 패킷을 스니핑하여 중요한 정보를 얻을 수 있으므로 보안에 취약하다.
- SSH보다 낮은 대역폭을 사용
- 개인 네트워크에 적합
*NVT : 송신호스트로부터 수신 호스트로 데이터를 전송할 때 두 시스템에서의 데이터 양식이 다르기 때문에 데이터를 변환시키는 가상 장치
1) 작동방식
1. 클라이언트는 원격 로그인을 통하여 서버에 TCP 연결을 한다.
2. 서버는 연결된 클라이언트에게 가상의 터미널을 제공한다.
3. 클라이언트는 실제 터미널인 것처럼 서버에 명령어를 실행한다.
4. 서버는 클라이언트의 명령을 수행하여 결과를 다시 클라이언트에게 전송한다.
| SSH | Telnet | |
| 포트번호 | 22 | 23 |
| 데이터 전송 시 암호화 방식 | 비대칭 암호화 | 암호화 없이 데이터 전송 |
| 보안 | Telnet보다 보안이 높음 | SSH보다 보안이 낮음 |
| 대역폭 | 높은 대역폭을 사용 | 낮은 대역폭을 사용 |
| 네트워크 | 공공 네트워크에 적합 | 개인 네트워크에 적합 |
3. HTTP-80
- W3 상에서 정보(html, 이미지 등)를 주고받을 수 있는 프로토콜
- 클라이언트 서버 구조
- 무상태 프로토콜(Stateless) : HTTP에서 서버가 클라이언트의 상태를 보존하지 않는 상태
- 비연결성(Connectionless) -> HTTP 1.0 기준
1) HTTP는 기본이 연결을 유지하지 않는 모델
2) 실제로 요청을 주고 받을 때만 연결을 유지하고 응답을 주고나면 TCP/IP 연결을 끊는다.
3) 이를 통해 최소한의 자원으로 서버 유지가 가능
4) 연결을 할때마다 tcp연결을 해야되므로 시간도 오래 걸리고 비효율적이라 HTTP 1.1부터는 지속적인 연결이 가능해져서 비연결성의 한계를 극복했다. - 단순함, 확장 가능
- 데이터 평문으로 전송
1) 작동방식
클라이언트가 브라우저를 통해서 어떠한 서비스를 URL를 통해 서버에 요청(Request)하면 서버에서 해당 요청에 대한 결과를 응답(Response)하는 형태
4. HTTPS-443
- HTTP의 확장 버전으로 보다 안전한 버전 (HTTP + SSL)
- 통신하는 과정에서 HTTPS는 SSL/TLS 프로토콜로 전송 내용을 암호화함
암호화를 통해 중간 매개체에서 통신 내용을 확인할 수 없기 때문에, 발신자가 전송한 암호 및 기밀문서를 보호할 수 있음 - 공개키 암호화 방식 사용
HTTP는 항상 신뢰하는 사람이라 생각하지만 HTTPS는 공개키 방식으로 SSL 인증서에 공개키와 개인키가 맞아야 합법적인 호스트라고 증명을 한다.
이 방식으로 중간자 공격, DNS 스푸핑 등 인증이 없을 때 발생할 수 있는 여러 공격을 방지하거나 차단할 수 있다.
*SSL/TLS
- 일명 '디지털 인증서'라고 불리며 웹 서버와 브라우저 간에 통신되는 모든 데이터를 안전하게 보장하는 보안 표준 기술
1) 작동방식
먼저 SSL 핸드셰이크를 수행한다. 이때 데이터를 주고받기 위해 어떤 방법을 사용해야 하는지 서로의 상태를 파악한다. SSL은 443번 포트를 기본으로 사용하는 TCP 기반의 프로토콜로 TCP 기반이기 때문에 SSL 핸드셰이크 전에 TCP 3-Way 핸드셰이크 또한 수행한다.
서로 간 협상이 완료되면, SSL 세션이 생성되고 클라이언트와 서버는 원하는 데이터를 주고받게 된다.
그리고 데이터 전송의 끝을 서로에게 알리며 세션을 종료한다.
2) 핸드셰이크 과정에서 어떤것들을 협상할가?
- Clinet Hello :클라이언트가 서버에게 연락한다. 브라우저 검색창에 도메인을 입력하는 것으로 이때 클라이언트는 자신의 브라우저가 지원할 수 있는 암호화 방식(Cipher Suite)을 먼저 제시한다. 그리고 랜덤 데이터를 생성하여 추가로 전송한다.
- Server Hello : 서버가 클라이언트에게 연락한다. 서버는 클라이언트가 제시한 암호화 방식 중 하나를 선정하여 알려준다. 또한, 서버 자신의 인증서를 전달한다. 이 인증서에는 서버의 공개키가 포함되어 있다. 클라이언트와 마찬가지로 서버 측에서 생성한 랜덤 데이터 또한 전달한다.
- Client key exchange : 클라이언트는 미리 주고받은 자신과 서버의 랜덤 데이터를 참고하여 서버와 암호화 통신을 할 때 사용할 키를 생성한 후 서버에게 전달한다. 이때 키는 서버로부터 받은 공개키로 암호화되어 보내진다.
- Finished : 마지막으로 핸드셰이크 과정이 정상적으로 마무리되면, 클라이언트와 서버 모두 'Finished' 메시지를 보낸다. 그 후부턴 클라이언트가 생성한 키를 이용하여 암호화된 데이터를 주고받게 된다.
5. DNS-53
- 호스트의 도메인 이름을 호스트의 네트워크 주소로 바꾸거나 그 반대의 변환을 수행할 수 있도록 하기 위해 개발됨
- 특정 컴퓨터의 주소를 찾기 위해, 사람이 이해하기 쉬운 도메인 이름을 숫자로 된 식별 번호(IP)로 변환해 준다.
- 도메인 이름 해석
DNS는 도메인 이름을 IP주소로 해석하여 사용자가 웹사이트에 접속할 수 있도록 한다. - 계층적 구조
DNS는 계층적인 구조를 가지고 있으며, 최상위 도메인(TLD)부터 시작하여 하위 도메인까지 계층적으로 구성된다. - 분산 데이터베이스
DNS는 전 세계에 분산된 여러 DNS 서버들에 의해 유지되는 분산 데이터베이스를 기반으로 동작한다. - 캐싱
DNS 서버는 이전에 해석한 도메인 이름과 IP주소의 매핑 정보를 캐싱하여 다음에 같은 요청이 있을때 다시 조회하지 않고 캐시된 정보를 사용할 수 있다. 이를 통해 빠른 응답 시간을 제공한다. - 오류 처리
DNS는 잘못된 도메인 이름이나 IP주소를 입력한 경우에도 적절한 오류 처리를 통해 사용자에게 올바른 정보를 제공한다. - 다양한 레코드 타입
DNS는 A레코드, AAAA레코드, CNAME레코드, MX 레코드, TXT 레코드 등 다양한 레코드 타입을 지원하여 다양한 네트워크 서비스를 지원한다.
1) 작동방식
1. 웹 브라우저에 www.naver.com을 을 입력하면 먼저 PC에 저장된 Local DNS(기지국 DNS서버)에게 www.naver.com이라는 hostname에 대한 IP주소를 요청한다.
2. Local DNS는 이제 www.naver.com의 IP주소를 찾아내기 위해 다른 DNS 서버들과 통신을 시작한다. 먼저 Root DNS서버에게 www.naver.com 의 IP주소를 요청한다.
3. Root DNS 서버는 www.naver.com 의 IP주소를 찾을 수 없어 Local DNS 서버에게 www.naver.com 의 IP주소를 찾을 수 없다고 다른 DNS서버에게 물어봐 라고 응답을 한다.
4. 이제 Local DNS 서버는 com도메인을 관리하는 TLD DNS서버(최상위 도메인 서버)에 다시 www.naver.com 에 대한 IP주소를 요청한다.
5. com 도메인을 관리하는 DNS 서버에도 해당 정보가 없으면 Local DNS 서버에게 다른 DNS 서버에게 물어봐 라고 응답한다.
6. 이제 Local DNS 서버는 naver.com DNS 서버(Authoritative DNS 서버)에게 다시 www.naver.com 의 IP 주소를 요청한다.
7. naver.com DNS 서버에는 www.naver.com 의 IP 주소가 있으므로 Local DNS 서버에게 IP 주소를 응답한다.
8. 이를 수신한 Local DNS는 www.naver.com 의 IP 주소를 캐싱을 하고 이후 다른 요청이 있을 시 응답할 수 있도록 IP 주소 정보를 PC에 전달해 준다.
Root DNS -> TLD DNS -> Authoritative DNS로 요청해서 답을 찾는 과정을 재귀적 쿼리라고 부른다.
참고 문헌
'리팩토링' 카테고리의 다른 글
| 리팩토링 9주차 악성코드 (0) | 2024.09.19 |
|---|---|
| 리팩토링 8주차 Firewall, IDS, IPS, DDoS (0) | 2024.09.06 |
| 리팩토링 6주차 OSI 7계층 프로토콜 (0) | 2024.08.23 |
| 리팩토링 5주차 OSI 7계층 장비 (2) | 2024.08.15 |
| 리팩토링 4주차 UDP (0) | 2024.08.09 |