Lab 3: Application Layer Protocols — File Transfer and Remote Access

ชื่อ-สกุลผู้ทำ Lab: _______________________________ รหัสนักศึกษา: _______________

วัตถุประสงค์ของ Lab

1. เข้าใจสถาปัตยกรรมและกลไกการทำงานของโปรโตคอลถ่ายโอนไฟล์ FTP, SFTP, FTPS, SCP และ SSHFS
2. สามารถติดตั้งและกำหนดค่า FTP Server (vsftpd) ทั้งแบบไม่ปลอดภัยและแบบ FTPS (TLS)
3. สามารถดักจับ (Capture) และวิเคราะห์ Packet ด้วย tcpdump เพื่อพิสูจน์ช่องโหว่ของ FTP แบบ Plaintext
4. สามารถกำหนดค่า SFTP พร้อม Chroot Jail บน OpenSSH
5. สามารถสร้างและใช้งาน SSH Key-based Authentication รวมถึงกำหนดค่า sshd_config แบบ Hardened
6. สามารถใช้งาน SCP และ SSHFS สำหรับการถ่ายโอนไฟล์และ Mount Remote Filesystem
7. สามารถใช้ fail2ban เพื่อป้องกัน Brute-force Attack และวิเคราะห์ Log การเชื่อมต่อ

อุปกรณ์และสภาพแวดล้อมที่ใช้

⚠️ คำเตือน: Lab นี้ทำในสภาพแวดล้อมปิด (Closed Lab Network) เท่านั้น ห้ามนำ Configuration ที่ไม่ปลอดภัย (เช่น FTP Plaintext) ไปใช้งานจริงบน Production หรือเครือข่ายสาธารณะ

บันทึกข้อมูลเครื่องที่ใช้ในการทำ Lab

ส่วนที่ 1: FTP — ติดตั้งและพิสูจน์ช่องโหว่ (45 นาที)

1.1 ติดตั้งและตั้งค่า FTP Server

ภารกิจ: ติดตั้ง vsftpd บนเครื่อง Server ตามขั้นตอนในเอกสารประกอบบทที่ 3 (หัวข้อ 3.1.5) สร้างผู้ใช้ student01 รหัสผ่านตามที่กำหนดเอง และสร้างไฟล์ทดสอบขนาดประมาณ 1 MB

# พื้นที่สำหรับบันทึกคำสั่งที่ใช้จริง (ถ้าต่างจากเอกสาร)

บันทึกผลลัพธ์ที่ 1.1 — คัดลอกผลลัพธ์จากคำสั่ง sudo systemctl status vsftpd:

[วางผลลัพธ์ที่นี่]

1.2 เชื่อมต่อและทดลองใช้งานคำสั่ง FTP พื้นฐาน

ใช้คำสั่ง ftp เชื่อมต่อไปยัง Server แล้วทดลองคำสั่งต่อไปนี้อย่างน้อย: pwd, ls -la, get, put, bye

บันทึกผลลัพธ์ที่ 1.2 — วาง Transcript การเชื่อมต่อทั้งหมด:

[วางผลลัพธ์ที่นี่]

คำถามที่ 1.2.1 เมื่อ Client ส่งคำสั่ง PASV เซิร์ฟเวอร์ตอบกลับด้วย Response Code ใด และมีความหมายว่าอย่างไร?

คำถามที่ 1.2.2 จาก PASV Response ที่ Server ส่งกลับมาจริงในการทดลองของคุณ ให้คำนวณหมายเลข Port ของ Data Connection โดยใช้สูตร Port = (p₁ × 256) + p₂ พร้อมแสดงวิธีคำนวณ:

Response ที่ได้: ___________________________________
p1 = _______  p2 = _______
Port = (p1 × 256) + p2 = _______________

1.3 ดักจับ Packet ด้วย tcpdump เพื่อพิสูจน์ช่องโหว่

ทำตามขั้นตอนในหัวข้อ 3.1.5 ขั้นตอนที่ 4 — เปิด tcpdump ดักจับที่ Port 21 แล้วทำการ Login FTP ใหม่ จากนั้นค้นหา USER และ PASS ใน Capture File

บันทึกผลลัพธ์ที่ 1.3 — วางผลลัพธ์จากคำสั่ง tcpdump -r ... -A | grep -E 'USER|PASS':

[วางผลลัพธ์ที่นี่ — ควรเห็น Username/Password แบบ Plaintext]

1.4 คำนวณ Transfer Rate

ใช้ไฟล์ที่ดาวน์โหลดในข้อ 1.2 บันทึกขนาดไฟล์ (bytes) และเวลาที่ใช้ถ่ายโอนจริงจากผลลัพธ์ของคำสั่ง get แล้วคำนวณ Transfer Rate ทั้งหน่วย B/s และ Mbps (ใช้สคริปต์ Python ในเอกสารหัวข้อ 3.1.5 เป็นแนวทาง)

ขนาดไฟล์ (S) = _____________ bytes
เวลาที่ใช้ (T) = _____________ วินาที

R (B/s)   = S / T           = _____________
R (Mbps)  = (S × 8) / (T × 10^6) = _____________

🗨️ อภิปรายท้ายส่วนที่ 1

1. จากผลการดักจับ Packet ในข้อ 1.3 อธิบายว่าเหตุใด FTP จึงไม่ควรใช้งานบนเครือข่ายสาธารณะหรือ Production และยกตัวอย่างสถานการณ์โจมตีที่อาจเกิดขึ้นได้จากช่องโหว่นี้

2. เปรียบเทียบข้อดี-ข้อเสียของ Active Mode และ Passive Mode ในบริบทของเครือข่ายที่มี NAT/Firewall

ส่วนที่ 2: SFTP — SSH File Transfer Protocol พร้อม Chroot Jail (45 นาที)

2.1 ตรวจสอบ SFTP Subsystem และสร้างโครงสร้าง Directory

ทำตามขั้นตอนหัวข้อ 3.2.2 ขั้นตอนที่ 1–2 สร้างผู้ใช้ sftpuser01 และโครงสร้าง Chroot ที่ /srv/sftp/sftpuser01

บันทึกผลลัพธ์ที่ 2.1 — วางผลลัพธ์จากคำสั่ง ls -la /srv/sftp/sftpuser01/:

[วางผลลัพธ์ที่นี่]

2.2 กำหนดค่า sshd_config สำหรับ SFTP Chroot

เพิ่มการตั้งค่า Match Group sftpusers ตามเอกสารหัวข้อ 3.2.2 ขั้นตอนที่ 3 แล้วตรวจสอบ Config และ Restart Service

บันทึกผลลัพธ์ที่ 2.2 — ผลลัพธ์จากคำสั่ง sudo sshd -t:

[วางผลลัพธ์ที่นี่]

2.3 ทดสอบการใช้งาน SFTP และ Chroot Jail

เชื่อมต่อด้วย sftp sftpuser01@<Server_IP> แล้วทดลอง: อัปโหลดไฟล์ 1 ไฟล์ (put), ดาวน์โหลด 1 ไฟล์ (get), และพยายาม cd /etc เพื่อทดสอบว่า Chroot ทำงานจริง

บันทึกผลลัพธ์ที่ 2.3.a — Transcript การใช้งาน put/get:

[วางผลลัพธ์ที่นี่]

บันทึกผลลัพธ์ที่ 2.3.b — ผลลัพธ์เมื่อพยายาม cd /etc และ ls /:

[วางผลลัพธ์ที่นี่]

บันทึกผลลัพธ์ที่ 2.3.c — ผลลัพธ์เมื่อพยายาม ssh sftpuser01@<Server_IP> (ควรถูกปฏิเสธ เพราะมี ForceCommand):

[วางผลลัพธ์ที่นี่]

2.4 สร้างสคริปต์ SFTP แบบ Batch (Non-interactive)

สร้างไฟล์ sftp_batch.txt ตามตัวอย่างในเอกสาร แล้วรันด้วย sftp -b

บันทึกผลลัพธ์ที่ 2.4:

[วางเนื้อหาไฟล์ batch และผลลัพธ์การรัน]

🗨️ อภิปรายท้ายส่วนที่ 2

1. SFTP แตกต่างจาก FTPS อย่างไรในเชิงสถาปัตยกรรม (จำนวน Port ที่ใช้ และ Layer ที่ทำงาน)?

2. เพราะเหตุใด Directory ที่ใช้เป็น ChrootDirectory (เช่น /srv/sftp/sftpuser01) จึงต้องเป็นเจ้าของโดย root:root เท่านั้น ห้ามให้ User เจ้าของ Account เป็นเจ้าของ Directory นั้นเอง? หากตั้งค่าผิดจะเกิดผลอย่างไร (ลองค้นคว้าเพิ่มเติมหรือทดลองเปลี่ยน Permission ดู)

ส่วนที่ 3: FTPS — FTP over TLS (30 นาที)

3.1 สร้าง TLS Certificate และกำหนดค่า vsftpd สำหรับ FTPS

ทำตามหัวข้อ 3.3.3 ขั้นตอนที่ 1–2 สร้าง Self-signed Certificate และปรับ /etc/vsftpd.conf ให้บังคับใช้ TLS (Explicit FTPS)

บันทึกผลลัพธ์ที่ 3.1 — ผลลัพธ์จากคำสั่งตรวจสอบ Certificate (openssl x509 ... -text -noout | grep -E "Subject:|Not After"):

[วางผลลัพธ์ที่นี่]

3.2 ทดสอบเชื่อมต่อ FTPS ด้วย lftp และดักจับ Packet ซ้ำ

ทำตามหัวข้อ 3.3.3 ขั้นตอนที่ 3 — เชื่อมต่อด้วย lftp แล้วดักจับ Packet ด้วย tcpdump อีกครั้ง เปรียบเทียบกับผลในข้อ 1.3

บันทึกผลลัพธ์ที่ 3.2.a — Transcript การเชื่อมต่อ lftp:

[วางผลลัพธ์ที่นี่]

บันทึกผลลัพธ์ที่ 3.2.b — ผลลัพธ์จาก tcpdump -r /tmp/ftps.pcap -A | grep -i "pass\|user" (ควรไม่พบ Credentials แบบอ่านได้):

[วางผลลัพธ์ที่นี่]

3.3 คำนวณ TLS Record Overhead

จากข้อมูลไฟล์ที่ถ่ายโอนจริงในข้อ 3.2 (หรือใช้ตัวเลขสมมติหากไม่สามารถวัดได้) ให้คำนวณ TLS Overhead ต่อ Record ขนาดสูงสุด 16,384 bytes โดยใช้ AES-128-GCM (H=5, MAC=16, IV=0, Padding=0)

O_TLS = H + IV + MAC + Padding = _____________ bytes/record
% Overhead = (O_TLS / 16384) × 100 = _____________ %

🗨️ อภิปรายท้ายส่วนที่ 3

1. เปรียบเทียบผลการดักจับ Packet ในข้อ 1.3 (FTP) กับข้อ 3.2.b (FTPS) — อธิบายความแตกต่างที่สังเกตเห็นและเชื่อมโยงกับกระบวนการ TLS Handshake

2. Implicit FTPS และ Explicit FTPS (FTPES) ต่างกันอย่างไร และเพราะเหตุใด Explicit FTPS จึงเป็นที่นิยมมากกว่าในปัจจุบัน?

ส่วนที่ 4: SCP และ SSHFS (30 นาที)

4.1 ทดสอบ SCP และตรวจสอบ Integrity ด้วย MD5

สร้างไฟล์ทดสอบขนาด 10 MB ด้วย dd แล้วคัดลอกไปยัง Server ด้วย scp พร้อมจับเวลา จากนั้นตรวจสอบ MD5 Checksum ทั้งสองฝั่งตามหัวข้อ 3.4.1

บันทึกผลลัพธ์ที่ 4.1 — ผลลัพธ์จากคำสั่ง time scp ... และการเปรียบเทียบ MD5:

[วางผลลัพธ์ที่นี่]



Local MD5:  _______________________
Remote MD5: _______________________
ตรงกันหรือไม่: _______________________

4.2 Mount Remote Directory ด้วย SSHFS

ติดตั้ง sshfs และ Mount Directory ของ Server มาที่ /mnt/server_home ตามหัวข้อ 3.4.2 แล้วทดลองคัดลอกไฟล์เข้า-ออกผ่าน Mount Point

บันทึกผลลัพธ์ที่ 4.2 — ผลลัพธ์จากคำสั่ง df -h /mnt/server_home และการทดลองใช้งาน:

[วางผลลัพธ์ที่นี่]

4.3 เปรียบเทียบ rsync กับ SCP

รันคำสั่ง rsync -avz --dry-run ... ตามตัวอย่างในหัวข้อ 3.4.3 แล้วเปรียบเทียบเวลาที่ใช้และปริมาณข้อมูลที่ส่งจริง เมื่อรันซ้ำครั้งที่สองโดยไม่มีไฟล์เปลี่ยนแปลง

บันทึกผลลัพธ์ที่ 4.3:

รอบที่ 1 (มีการเปลี่ยนแปลง):
[วางผลลัพธ์]

รอบที่ 2 (ไม่มีการเปลี่ยนแปลง):
[วางผลลัพธ์]

🗨️ อภิปรายท้ายส่วนที่ 4

1. จากผลลัพธ์ในข้อ 4.3 อธิบายว่า Incremental Transfer ของ rsync ช่วยประหยัด Bandwidth ได้อย่างไร เมื่อเทียบกับ SCP ที่ส่งไฟล์ใหม่ทั้งหมดทุกครั้ง

2. จงยกตัวอย่างสถานการณ์การทำงานจริงที่ควรเลือกใช้ SCP, rsync และ SSHFS ตามลำดับ พร้อมให้เหตุผลประกอบ

ส่วนที่ 5: SSH Hardening และ fail2ban (30 นาที)

5.1 สร้าง SSH Key และตั้งค่า Key-based Authentication

สร้าง Ed25519 Key Pair ตามหัวข้อ 3.5.2 แล้วคัดลอก Public Key ไปยัง Server ด้วย ssh-copy-id ตามหัวข้อ 3.5.3 ทดสอบ Login โดยไม่ใช้ Password

บันทึกผลลัพธ์ที่ 5.1.a — ผลลัพธ์จากคำสั่ง ssh-keygen -lf ~/.ssh/id_ed25519.pub (Fingerprint):

[วางผลลัพธ์ที่นี่]

บันทึกผลลัพธ์ที่ 5.1.b — ยืนยันว่า Login ด้วย Key สำเร็จโดยไม่ถาม Password:

[วางผลลัพธ์ที่นี่]

5.2 กำหนดค่า sshd_config แบบ Hardened

ปรับแก้ /etc/ssh/sshd_config ตามตัวอย่างในหัวข้อ 3.5.4 อย่างน้อยต้องมี: เปลี่ยน Port, ปิด PasswordAuthentication, ปิด PermitRootLogin, ตั้งค่า AllowUsers, และปิด X11/TCP/Agent Forwarding

บันทึกผลลัพธ์ที่ 5.2 — รันสคริปต์ ssh_security_check.sh จากหัวข้อ 3.7.3 (คัดลอกไปสร้างไฟล์เอง) แล้ววางผลลัพธ์ทั้งหมด:

[วางผลลัพธ์ที่นี่]

5.3 ติดตั้งและทดสอบ fail2ban

ติดตั้งและกำหนดค่า fail2ban ตามหัวข้อ 3.5.5 จากนั้นทดลอง Login ผิด Password ติดต่อกันเกิน maxretry ครั้งจากเครื่อง Client แล้วตรวจสอบว่า IP ถูก Ban

บันทึกผลลัพธ์ที่ 5.3.a — ผลลัพธ์จาก sudo fail2ban-client status sshd หลังทดลอง Login ผิด:

[วางผลลัพธ์ที่นี่]

บันทึกผลลัพธ์ที่ 5.3.b — ผลลัพธ์เมื่อพยายามเชื่อมต่อซ้ำหลังถูก Ban (ควร Connection Refused/Timeout):

[วางผลลัพธ์ที่นี่]

อย่าลืม Unban ตัวเองด้วยคำสั่ง sudo fail2ban-client set sshd unbanip <Client_IP> เมื่อทดลองเสร็จ

5.4 คำนวณ Entropy ของ Passphrase

เลือก Passphrase ของคุณเอง (หรือ Private Key Passphrase ที่ใช้ในข้อ 5.1) แล้วคำนวณ Entropy ตามสูตร H = L × log₂(N) โดยระบุว่าใช้ Character Set แบบใด (N)

Passphrase ตัวอย่าง (หรือรูปแบบ): _______________________
L (ความยาว) = _____________
N (จำนวนตัวอักษรที่เป็นไปได้) = _____________
H = L × log2(N) = _____________ bits
ระดับความปลอดภัย (WEAK <60 / OK <80 / STRONG ≥80): _____________

🗨️ อภิปรายท้ายส่วนที่ 5

1. เพราะเหตุใด Key-based Authentication จึงปลอดภัยกว่า Password Authentication โดยพื้นฐาน อธิบายโดยอ้างอิงกระบวนการ Challenge-Response ในหัวข้อ 3.5.3

2. การเปลี่ยน SSH Port จาก 22 เป็น Port อื่น (Security through Obscurity) ช่วยลดความเสี่ยงได้จริงหรือไม่ อย่างไร และมีข้อจำกัดอะไรบ้าง?

3. หากองค์กรของคุณต้องดูแล Server ที่มีทั้ง SFTP User และ SSH Shell User ปะปนกัน จะออกแบบ Match Block ใน sshd_config อย่างไรเพื่อแยกสิทธิ์ทั้งสองกลุ่มออกจากกันอย่างปลอดภัย?

สรุปผล Lab และการประเมินตนเอง

ตารางสรุปเปรียบเทียบผลการทดลองจริง

คำถามสรุปรวม

1. จาก Lab ทั้งหมด ให้เรียงลำดับโปรโตคอลที่ควรใช้งานจริงในองค์กรของคุณ จากที่แนะนำที่สุดไปน้อยที่สุด พร้อมเหตุผลสั้นๆ

2. ระบุปัญหาหรืออุปสรรคที่พบระหว่างทำ Lab นี้ และวิธีที่คุณใช้แก้ไข

3. ให้คะแนนความเข้าใจของตนเองต่อเนื้อหาบทที่ 3 (1 = ยังไม่เข้าใจ, 5 = เข้าใจดีมาก): ⭐ / 5

เอกสารอ้างอิงประกอบการทำ Lab

อ้างอิงตามรายการในเอกสารประกอบบทที่ 3 "Application Layer Protocols: File Transfer and Remote Access" โดยเฉพาะ RFC 959, RFC 4217, RFC 4251–4254 และเอกสาร OpenSSH/vsftpd Manual