TFTP 간단한 내용이지만, 그만큼 관련 자료가 적어서, 정리하는데 고생했음. 시작 고고 2조

TFTP? TFTP(Trivial File Transfer Protocol) ◦ RFC 1350 에서 공식화. ◦ UDP 방식을 사용 ( 69 PORT ) ◦ Embedded System ( 또는 WorkStation ) 에서 운영 체제의 업로드용으로 주로 사용. 1. TFTP란 ? FTP와 마찬가지로 파일을 전송하기 위한 프로토콜이지만, FTP보다 더 단순한 방식으로 파일을 전송한다. 2. RFC 번호 : IETF(Internet Engineering Task Force)에서, 인터넷에서 기술을 구현하는 데에 필요한 절차 등을 제공하는 온라인 공문서 간행물이다. 각각의 RFC 문서에는 일련번호가 부여되며, 한 번 부여된 번호는 중복하여 사용되지 않는다. 3. TCP 흐름의 대표 사례가 FTP 라면, TFTP는 UDP 원리의 흐름을 대표할 수 있는 사례 중 하나라고 볼 수 있다. 자세한 내용은 뒤에 다시 다루도록 하겠다. 임베디드 시스템에서 운영 체제 업로드로 주로 사용 -> 임베디드란 컴퓨터 관련 시스템의 몇 가지 기능만을 수행하는 간단한 장치를 의미하지만, 요즘은 개념의 확장이 크다. ( 컴퓨터 하드 디스크, 모뎀 기능 장비류들 등의 플래시 메모리를 내장하여 기능적 OS 를 설치해야 하는 부품들.. ) 4.

TFTP의 Message Message RRQ WRQ DATA ACK ERROR RRQ ( Read request ) WRQ ( Write request ) DATA ACK ( Acknowledge ) ERROR

TFTP Message 전체 구성도입니다. 뒤에 하나씩 설명드리도록 하겠습니다.

TFTP의 Message RRQ(Read request) 클라이언트가 서버로부터 데이터를 읽기 위한 연결을 설정 하는데 사용 OpCode : 2 바이트 동작 코드, 값 1 File name : 가변 길이의 문자열 ASCII 코드로 부호화 1 바이트 필드로 종료점 표시(All 0’s) Mode : 전송 모드를 정의. 서버가 이 모드의 데이터들을 수신하면, 자신에게 맞는 포맷으로 변환한다. ASCII – net ascii 모드 바이너리 파일 – octet 모드 Mail : 메일 주소

TFTP의 Message WRQ(Write request) 클라이언트가 서버에 데이터를 쓰기 위한 연결 요청 읽기 요청의 앞과 비교해서 OpCode 값이 2로 변한것을 알 수 있다.

TFTP의 Message DATA 데이터 블록을 전송하기 위해 사용 DATA 메시지 필드 OpCode : 2 바이트 동작 코드, 값 3 Block number : 블록의 순서 번호를 표시 DATA 마지막을 제외한 모든 블록이 512 바이트 마지막 블록 : 0 ~ 511 바이트 ( 왜 512보다 작은지는 잠시 뒤에 말씀드립니다 ) 마지막 블록은 End-of-File(파일의 끝을 나타내는) 지시자 로 사용 NVT ASCII, 2진 8진수 사용

TFTP의 Message ACK( Acknowledge : 확인 응답 ) 데이터 블록을 수신하였음을 응답해 준다. 4byte의 길이. ACK 메시지 필드 OpCode : 2 바이트 동작 코드, 값 4 Block number : 수신된 블록 번호를 표시 꼭 DATA만이 아닌, WRQ에 대한 응답으로도 사용된다. 서버측에서 ACK로 응답하면 수신할(서버에 Write할) 준비가 되어 있음을 의미

TFTP의 Message ERROR 연결을 설정하지 못했거나 데이터 전송 중에 문제가 발생할 때 사용. RRQ나 WRQ에 대한 부정 응답으로도 사용. ERROR 메시지 필드 OpCode : 두 바이트 동작 코드, 값 5 Error number : 오류의 종류를 정의 Error data : 오류 데이터를 포함

TFTP의 Message ERROR Number Number Meaning Not defiend 1 File not Found Not defiend 1 File not Found 2 Access Violation 3 Disk Full quota Or disk exceeded 4 Illegal operation 5 Unknown port number 6 File already exists 7 No such user 에러 메시지 코드 0 : 정의되지 않았다 1 : 파일을 찾을수 없다 2 : 엑세스 위반 3 : 디스크가 꽉 차거나 용량을 초과하다 4 : 정책 위반적인 잘못된 접근 5 : 알 수 없는 포트 넘버 6 : 이미 존재하는 파일 7 : 유저를 찾을 수 없다 각 코드 내용에 대한 상세한 정의는 강사님이 해주실 겁니다. - 로 Pass ㅋ

TFTP의 연결 UDP를 사용 TCP방식의 FTP에 비해서 간단한 전송형태. 부트로더(BOOTP) 등과 연동하여 네트워크 부트, OS설치 등에 사용. 쌍방 연결 설정과 종료를 제공하지 않음. 데이터 블록을 사용자 데이터그램으로 캡슐화. UDP : 일반 ftp프로토콜은 tcp프로토콜(3웨이 핸드쉐이킹방식)을 사용하지만, tftp는 udp프로토콜(단방향 핸드쉐이킹) 방식을 사용하여 전송한다 UDP의 특성 대부분 그대로라고 보면 된다.

TFTP의 연결 모든 데이터 블록을 전송할 수 있는 연결 필요 RRQ, WRQ, ACK, ERROR 사용 메시지 사용연결 종료를 위해 512 바이트보다 적은 DATA 메시지 사용 UDP : 일반 ftp프로토콜은 tcp프로토콜(3웨이 핸드쉐이킹방식)을 사용하지만, tftp는 udp프로토콜(단방향 핸드쉐이킹) 방식을 사용하여 전송한다 UDP의 특성 대부분 그대로라고 보면 된다.

TFTP의 연결 연결 흐름 연결 설정 구성도 읽기(read) 쪽 클라이언트 쪽에서 RRQ 메시지 전송 : 파일 이름과 전송 모드 ( RRQ 는 이름 그대로 서버측으로부터 읽어오기 위한 요청응답 준비 ) 2. 서버 쪽에서 첫번째 블록을 포함하는 DATA 메시지 전송 응답 문제 발생시 ERROR 메시지 전송, 부정 응답 쓰기(write) 쪽 1. 클라이언트 쪽에서 WRQ 메시지 전송 : 파일 이름과 전송 모드 ( WRQ 란 서버에 쓰기 위한 요청 메시지 ) 2. 서버 쪽은 블록 번호가 0인 ACK 메시지 전송 응답 3. 연결 종료시 앞에서 말했던 대로, 연결 종료는 512 바이트보다 적은 데이터의 마지막 블록을 전송하면 그렇게 처리되는 방식. 뒤에서 간단한 패킷 확인을 해보도록 하겠다.

TFTP의 데이터 전송 흐름 데이터 전송 과정 연결과 종료 사이에 수행 전송 과정 파일을 데이터 블록으로 나눈다. ASCII나 2진 파일 형태 전송 흐름 제어와 오류 제어 기능이 없음 신뢰성 없는 UDP 사용 전송 과정 파일을 데이터 블록으로 나눔 마지막 블록을 제외한 블록은 512 바이트의 크기(UDP의 전형적 구조) 마지막 블록은 0 ~ 511 바이트의 크기. 그 이유는 마지막 블록은 데이터 전송의 종료 신호를 위해서 512byte보다 작은 크기를 사용하게 된다. 자체적으로 흐름을 제어하는 기능이 기본적으로 없기 때문에 연속적 데이터 블록의 전송을 위해 TFTP가 흐름 제어와 오류 제어 메커니즘 자체 생성하게 된다.

TFTP의 데이터 전송 흐름 데이터 흐름 제어 데이터 블록 하나를 DATA 메시지로 전송하고 ACK 메시지를 기다림 응답이 있으면 다음 블록 전송 정지 – 대기 프로토콜 사용 흐름 제어 파일 읽읅 경우 클라이언트 : RRQ 메시지 전송 서버 : DATA 메시지에 첫번째 블록을 실어 응답 ( 아까 op코드 다음에 1의 블록 기억 ) ( 화면을 다시 아까 그림으로 돌리면서 설명한다 ) 파일 저장할 경우 클라이언트 : WRQ 메시지 전송 서버 : ACK 메시지로 응답

TFTP의 데이터 전송 흐름 데이터 오류 제어 유실 응답 메시지를 재전송 중복된 메시지 검출 및 제거 유실 응답 메시지 상세 - 수신자의 타이머가 먼저 끝났을 경우 수신자가 응답을 재 전송 - 송신자의 타이머가 먼저 끝났을 경우 송신자가 데이터를 재 전송 중복 메시지 검출 수신자가 블록 번호를 보고 검출 수신자가 중복된 블록을 제거

TFTP의 연결 통로. UDP UDP Port TFTP 는 69번 포트를 사용. 연결을 긴 시간 유지 ( 수 초~ 수 분 ) - 그 동안 해당 포트에 다른 클라이언트가 접속하면 서비스를 사용할 수 없는 문제점 발생. 신뢰성이 부족하므로, 대용량의 파일이나 패킷 손실이 많은 환경에서는 불편하다.

TFTP의 연결 통로. UDP PORT 해결책 : 임시 포트 FTP 의 경우 20, 21번 포트로 각각 응답과 송수신을 제어한다고 가정한다면, TFTP 는 클라이언트의 랜덤포트에서 보낸 응답을 69번 포트로 수신하고 마찬가지로 임시포트(예전의 경우 1350번 같은) 로 응답을 보내게 된다. 보다시피, 예를 들어 ACL 의 화이트 리스트(?)에 모든 포트를 막고, 69번 포트만 열어둔다면 당연히 제대로 동작하지 않을 것이다.

TFTP의 옵션 RRQ와 WRQ 메시지에 옵션 추가 - 블록 크기와 초기 순서번호 변경 - 상대방의 옵션 수용 여부 - 옵션이 없으면 항상 512byte( 마지막 블록 제외 ) 옵션이 있으면 UDP 데이터그램에 수용될 수 있는 수 OACK(Option Acknowledgement) - 상대방의 옵션 수용 여부

TFTP의 보안 보안에 대한 구체적 고려가 부족 핵심 파일에 대한 접근자 권한 설정 Telnet 과 같은 타 응용 프로그램을 사용 - 기본적으로 TFTP 자체에서는 디렉토리 인덱스 서비스를 제공하지 않기 때문에, 정확한 파일명을 입력하여 ( 예 : get / put [파일명] ) 접근해야 한다. FTP와의 차이점은, 로그인 대신 정확한 파일명을 알고 있다면, 특별한 인증 없이도 기본적으로 접근이 가능하다는 점이다.

TFTP의 실습 간단한 TFTP 환경 구축 - Yum 또는 rpm으로 관련 패키지 설치 Vmware 가상 머신(CentOS)의 네트워크 어댑터를 VMnat8(NAT)으로 세팅하고, dhclient 명령으로 외부 인터넷환경을 이용 가능하도록 만든다. 이미 외부환경이 설정되어 있다면 생략 가능하다. TFTP 관련 패키지는 TFTP 메인과, TFTP-SERVER 패키지로 구성되어 있다. RPM 수동설치는 관련 의존성이 번거롭기 때문에, 실습은 YUM으로 진행하였다.

TFTP의 실습 서버 가동 - TFTP 서비스를 사용하기 위해 환경 설정 파일 수정 Vmware 가상 머신(CentOS)의 네트워크 어댑터를 VMnat8(NAT)으로 세팅하고, dhclient 명령으로 외부 인터넷환경을 이용 가능하도록 만든다. 이미 외부환경이 설정되어 있다면 생략 가능하다. TFTP 관련 패키지는 TFTP 메인과, TFTP-SERVER 패키지로 구성되어 있다. RPM 수동설치는 관련 의존성이 번거롭기 때문에, 실습은 YUM으로 진행하였다.

TFTP의 실습 관련 데몬 재시작 후 파일 준비 TFTP 설치 후 부팅시 자동으로 서비스에 등록되도록 할 수 있다. Setup(원래 ntsysv ) 명령어를 이용한다. 환경설정에서 지정된 기본 디렉토리에 임의의 파일을 추가한 후, XP 에서 TFTP RRQ 를 전송할 것이다.

TFTP의 실습 XP에서 CentOS의 TFTP서버에서 파일을 다운받는다. 서버는 Wireshark 를 켜고 패킷을 관찰한다. XP와 CentOS 간에 물론 통신이 가능한 상태로 만들어 둬야 한다. ( 앞에 NAT 을 다시 VMnet1 또는 2로 돌린 후 ping 테스트 요망 ) 보다시피 클라이언트 역할인 XP(10.0.0.1)에서 RRQ(Read Request : 서버 읽기 요청) 를 날렸고 서버는 XP 로 데이터 패킷을 블록 단위로 전송하였다. 그리고 클라이언트는 받았음을 응답하는 확인 패킷(ACK) 를 다시 보낸다. 이를 반복하는데, 가령 이것이 응답이 지연되어 같은 신호를 중복 수신하고, 데이터도 중복되는 현상이 발생한다면, 이는 다음장의 “초보 마법사 신드롬” 이라는 현상이라고 생각할 수 있다.

TFTP의 데이터 전송 흐름 마법사 견습생 신드롬 마법사의 초보적 버그라는 의미로, 판타지아라는 영화의 세그먼트 부분을 따서 붙은 이름. ACK 메시지가 지연되는 경우에 발생 이후의 모든 데이터 블록과 응답이 중복 송/수신

TFTP의 실습 Install.log 파일의 크기에 비슷하게 블럭화되어 전송 데이터 전송 블록의 크기 마지막 전송 블록의 크기 데이터 전송 블록의 크기 마지막 전송 블록의 크기 31904byte 를 512byte 로 나눠보면 실제로는 62.xxx번의 블록 번호가 나오는데 왜 64번까지 가는지는 헤더 구조를 조금 생각해보면 알 수 있다. 보시다시피 실제로 전송되면서 블럭당 크기가 512가 아닌 558 byte 로 캡쳐되었음을 알 수 있다. 즉 실제로는 총 용량이 커지는 것이다. ( 558*63+484 = 35638 이를 558로 나눠보면 대충 63.88번으로 64에 맞게 떨어지는 것을 확인할 수 있었다 ) TFTP 의 데이터 전송 단위는 512bye이다. 앞에서 설명했듯이 OP코드의 값이 3 인것도 확인가능하다. 마지막 전송 블록의 크기가 512보다 작은 이유는 역시 앞에서 보았듯이, 512보다 작은 값의 블록 신호 자체가 데이터 전송의 종료 시점을 알려주는 것이다. 데이터 다이어그램의 크기는 총 524byte 인 것을 볼 수 있다. 이는 데이터의 블럭당 크기 512byte에 UDP 프로토콜의 헤더(8바이트)와 DATA 메세지의 크기(OP코드 2바이트, 블록 넘버 2바이트)가 더해진 것 같다. AcK 신호를 확인해도 4byte 의 값에 헤더값 8이 더해져서 12byte 로 표기되는 것 같다. 한 단계 아래인 IP 프로토콜의 영역으로 가보면 544byte 가 되어 있음을 알 수 있는데 , 이 또한 IP 헤더 영역의 20byte 가 추가되었음을 짐작할 수 있다. 나머지는… 강사님께서 자세히 설명해 주실 것이라고 생각한다. ㅋ IP 영역에서의 크기 UDP 영역에서의 크기

끝 TFTP 의 데이터 전송 단위는 512bye이다. 앞에서 설명했듯이 OP코드의 값이 3 인것도 확인가능하다. 마지막 전송 블록의 크기가 512보다 작은 이유는 역시 앞에서 보았듯이, 512보다 작은 값의 블록 신호 자체가 데이터 전송의 종료 시점을 알려주는 것이다. 데이터 다이어그램의 크기는 총 524byte 인 것을 볼 수 있다. 이는 데이터의 블럭당 크기 512byte에 UDP 프로토콜의 헤더(8바이트)와 DATA 메세지의 크기(OP코드 2바이트, 블록 넘버 2바이트)가 더해진 것 같다. AcK 신호를 확인해도 4byte 의 값에 헤더값 8이 더해져서 12byte 로 표기되는 것 같다. 한 단계 아래인 IP 프로토콜의 영역으로 가보면 544byte 가 되어 있음을 알 수 있는데 , 이 또한 IP 헤더 영역의 20byte 가 추가되었음을 짐작할 수 있다. 나머지는… 강사님께서 자세히 설명해 주실 것이라고 생각한다. ㅋ