0Pricing
Security+ Academy · บทเรียน

การแทนที่โพรโทคอลที่ไม่ปลอดภัย: Telnet กับ SSH, FTP กับ SFTP

ทำความเข้าใจว่าเหตุใดโพรโทคอลแบบข้อความเปิด เช่น Telnet, FTP และ HTTP จึงเปิดเผยข้อมูลรับรอง และโพรโทคอลเข้ารหัสที่มาแทนที่ (SSH, SFTP, HTTPS) แก้ปัญหาเหล่านี้อย่างไร

การแทนที่โพรโทคอลที่ไม่ปลอดภัย: Telnet กับ SSH, FTP กับ SFTP เป็นบทเรียน Security+ Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Security+ Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Security+ Academy มีบทเรียนทั้งหมด 4 บทเรียน

ปัญหาของโปรโตคอลข้อความไม่เข้ารหัส

โปรโตคอลอินเทอร์เน็ตพื้นฐานจำนวนมากได้รับการออกแบบในช่วงทศวรรษ 1970 และ 1980 ซึ่งในขณะนั้นความปลอดภัยยังไม่ใช่ประเด็นสำคัญ โปรโตคอลข้อความไม่เข้ารหัสจะส่งข้อมูลทั้งหมด — รวมถึงชื่อผู้ใช้ รหัสผ่าน และข้อมูลอ่อนไหว — เป็นข้อความธรรมดาผ่านเครือข่าย อุปกรณ์ใดก็ตามที่อยู่ในเซกเมนต์เครือข่ายเดียวกัน หรือระบบใดก็ตามที่แพ็กเก็ตเดินทางผ่าน สามารถดักจับและอ่านการรับส่งข้อมูลนี้ได้ด้วยเครื่องมือที่หาใช้ได้ทั่วไป เช่น Wireshark ในสภาพแวดล้อมที่มีสวิตช์เครือข่าย (ซึ่งโดยปกติจะแยกการรับส่งข้อมูลระหว่างพอร์ต) การปลอมแปลง ARP สามารถเปลี่ยนเส้นทางการรับส่งข้อมูลไปยังระบบของผู้โจมตี ทำให้โปรโตคอลข้อความไม่เข้ารหัสเป็นอันตรายแม้แต่บนเครือข่าย 'ภายใน'

# What an attacker sees on the wire with Telnet
# (captured via Wireshark or tcpdump)

tcpdump -i eth0 -A port 23

# Sample Telnet capture output:
..login: admin..
..password: S3cr3tPa$$...
..$ ls -la /etc/passwd..

# Every keystroke is visible in plaintext
# Credentials, commands, and file contents - all exposed

Telnet เทียบกับ SSH

Telnet (พอร์ต TCP 23) ให้การเข้าถึงบรรทัดคำสั่งระยะไกลไปยังระบบ แต่ส่งข้อมูลทุกอย่างเป็นข้อความธรรมดา ไม่มีการยืนยันตัวตนในตัวนอกเหนือจากชื่อผู้ใช้และรหัสผ่าน ซึ่งถูกส่งโดยไม่เข้ารหัส SSH (Secure Shell) (พอร์ต TCP 22) ใช้แทน Telnet ด้วยช่องทางที่เข้ารหัสและยืนยันตัวตนแล้ว SSH ใช้การแลกเปลี่ยนกุญแจแบบอสมมาตรเพื่อสร้างกุญแจเซสชัน จากนั้นเข้ารหัสการสื่อสารทั้งหมดที่เหลือด้วยการเข้ารหัสแบบสมมาตร SSH ยังยืนยันตัวตนของเซิร์ฟเวอร์ (ป้องกันการปลอมแปลงเซิร์ฟเวอร์) และรองรับ การยืนยันตัวตนด้วยกุญแจสาธารณะ (ไม่ต้องใช้รหัสผ่านและปลอดภัยกว่ารหัสผ่าน) นอกเหนือจากการยืนยันตัวตนด้วยรหัสผ่าน

# SSH connection (encrypted, server authenticated)
ssh admin@192.168.1.10

# SSH key-based authentication (no password)
ssh -i ~/.ssh/id_rsa admin@192.168.1.10

# Generate SSH key pair
ssh-keygen -t ed25519 -C 'admin@company.com'

# Copy public key to server
ssh-copy-id -i ~/.ssh/id_rsa.pub admin@192.168.1.10

# Disable Telnet on network devices (Cisco IOS)
no service telnet
line vty 0 4
  transport input ssh
  login local

การแลกเปลี่ยนกุญแจและการยืนยันตัวตนของ SSH

ความปลอดภัยของ SSH อาศัยกระบวนการแลกเปลี่ยนกุญแจที่แข็งแกร่ง เมื่อเชื่อมต่อ ไคลเอ็นต์จะตรวจสอบ กุญแจโฮสต์ของเซิร์ฟเวอร์กับสำเนาที่จัดเก็บไว้ภายในเครื่อง — วิธีนี้ป้องกันการปลอมแปลงเซิร์ฟเวอร์ หากกุญแจโฮสต์เปลี่ยนแปลงโดยไม่คาดคิด SSH จะแจ้งเตือนผู้ใช้ (ซึ่งเป็นสัญญาณทั่วไปของการโจมตีแบบคนกลาง) หลังจากตรวจสอบเซิร์ฟเวอร์แล้ว การยืนยันตัวตนของไคลเอ็นต์สามารถใช้: รหัสผ่าน (เข้ารหัสระหว่างส่งข้อมูล แต่เสี่ยงต่อการเดารหัสผ่านแบบลองทุกค่า), กุญแจสาธารณะ (ไคลเอ็นต์พิสูจน์ว่าครอบครองกุญแจส่วนตัว ซึ่งแข็งแกร่งกว่ามาก) หรือ การโต้ตอบผ่านแป้นพิมพ์ (รองรับ MFA) องค์กรควรบังคับใช้การยืนยันตัวตนด้วยกุญแจ และปิดใช้การยืนยันตัวตนด้วยรหัสผ่านบนบริการ SSH ที่เปิดให้เข้าถึงจากอินเทอร์เน็ต

# Harden SSH server configuration
# /etc/ssh/sshd_config
Port 22
PermitRootLogin no
PasswordAuthentication no    # Require key auth only
ChallengeResponseAuthentication no
MaxAuthTries 3
AllowUsers admin deploy
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
ClientAliveInterval 300      # Disconnect idle sessions
ClientAliveCountMax 0

# Restart SSH after changes
systemctl restart sshd

FTP เทียบกับ SFTP และ FTPS

FTP (File Transfer Protocol) (พอร์ต TCP 20/21) ถ่ายโอนไฟล์เป็นข้อความธรรมดา — ข้อมูลยืนยันตัวตน คำสั่ง และข้อมูลไฟล์ล้วนถูกเปิดเผย FTP ยังใช้ช่องทางข้อมูลแยกต่างหาก (โหมดพาสซีฟหรือแอกทีฟ) ซึ่งทำให้กฎไฟร์วอลล์ซับซ้อนขึ้น SFTP (SSH File Transfer Protocol) เจาะอุโมงค์การถ่ายโอนไฟล์ผ่าน SSH บนพอร์ต 22 — แตกต่างจาก FTP อย่างสิ้นเชิง เพียงแต่มีชื่อคล้ายกัน FTPS (FTP Secure) เพิ่มการเข้ารหัส TLS ให้กับโปรโตคอล FTP เดิม โดยทั่วไปนิยมใช้ SFTP มากกว่า เพราะใช้พอร์ตเดียวและสืบทอดการยืนยันตัวตนกับการเข้ารหัสของ SSH ควรปิดใช้ FTP บนระบบที่ใช้งานจริงทั้งหมด

# SFTP usage (over SSH, single connection)
sftp admin@fileserver.company.com
sftp> put localfile.zip /uploads/
sftp> get /reports/monthly.pdf .
sftp> ls /uploads/
sftp> exit

# Automated SFTP transfer with key auth
sftp -i ~/.ssh/id_rsa admin@fileserver.company.com <<EOF
put /tmp/report.csv /incoming/
EOF

# Disable FTP on Linux (remove vsftpd)
apt purge vsftpd
# Verify no FTP listener:
ss -tlnp | grep ':21'

HTTP เทียบกับ HTTPS

HTTP (พอร์ต TCP 80) ส่งเนื้อหาเว็บ รวมถึงข้อมูลแบบฟอร์ม คุกกี้เซสชัน และโทเค็นยืนยันตัวตนเป็นข้อความธรรมดา HTTPS (พอร์ต TCP 443) ห่อหุ้ม HTTP ด้วย TLS เพื่อให้มีการเข้ารหัส การยืนยันตัวตนเซิร์ฟเวอร์ และความถูกต้องครบถ้วนของข้อมูล องค์กรควรบังคับใช้ HTTPS ทุกที่: เปลี่ยนเส้นทางการรับส่งข้อมูล HTTP ทั้งหมดไปยัง HTTPS (การเปลี่ยนเส้นทาง 301) ใช้ HSTS เพื่อป้องกันไม่ให้เบราว์เซอร์เชื่อมต่อผ่าน HTTP และกำหนดแฟล็กคุกกี้ secure และ HttpOnly เพื่อป้องกันไม่ให้โทเค็นเซสชันถูกขโมยผ่าน HTTP หรือ JavaScript เบราว์เซอร์สมัยใหม่จะแสดงเว็บไซต์ HTTP เป็น 'ไม่ปลอดภัย' — ปัจจุบัน HTTPS คือมาตรฐานพื้นฐานที่คาดหวังสำหรับบริการเว็บทั้งหมด

# nginx: force HTTPS redirect
server {
  listen 80;
  server_name example.com;
  return 301 https://$host$request_uri;
}

server {
  listen 443 ssl;
  ssl_certificate /etc/ssl/example.crt;
  ssl_certificate_key /etc/ssl/example.key;
  add_header Strict-Transport-Security
    'max-age=31536000; includeSubDomains; preload';
  add_header X-Content-Type-Options nosniff;
  add_header X-Frame-Options SAMEORIGIN;
}

SNMP v1/v2 เทียบกับ SNMPv3

SNMP (Simple Network Management Protocol)ใช้จัดการอุปกรณ์เครือข่ายและเซิร์ฟเวอร์ SNMPv1 และ v2c ใช้สตริงชุมชน (โดยพื้นฐานคือรหัสผ่านที่ใช้ร่วมกัน) ซึ่งส่งเป็นข้อความธรรมดา — สตริงชุมชนอย่าง 'public' (อ่าน) และ 'private' (เขียน) เป็นค่าเริ่มต้นที่ผู้โจมตีทราบ อผู้โจมตีที่ดักจับการรับส่งข้อมูล SNMP จะทราบสตริงชุมชน และสามารถอ่านการกำหนดค่าอุปกรณ์หรือเปลี่ยนการตั้งค่าอุปกรณ์ได้ SNMPv3 เพิ่มการยืนยันตัวตน (HMAC-MD5 หรือ HMAC-SHA) และการเข้ารหัส (AES) ด้วยข้อมูลยืนยันตัวตนแยกตามผู้ใช้ ทำให้เป็นเวอร์ชันเดียวที่เหมาะสมสำหรับสภาพแวดล้อมใช้งานจริง ควรปิดใช้ SNMPv1/v2c

# SNMPv3 configuration (Cisco IOS)
snmp-server group MYGROUP v3 priv
snmp-server user MONITORUSER MYGROUP v3 \
  auth sha MyAuthP@ss priv aes 128 MyPrivP@ss

# SNMPv3 query from monitoring server
snmpwalk -v3 -l authPriv \
  -u MONITORUSER \
  -a SHA -A MyAuthP@ss \
  -x AES -X MyPrivP@ss \
  192.168.1.1 sysDescr

# Disable SNMPv1/v2c:
no snmp-server community public ro
no snmp-server community private rw

LDAP เทียบกับ LDAPS

LDAP (Lightweight Directory Access Protocol) (พอร์ต TCP 389) ใช้ยืนยันตัวตนและค้นหาบริการไดเรกทอรี (Active Directory, OpenLDAP) โดยค่าเริ่มต้นเป็นข้อความธรรมดา ทำให้ข้อมูลยืนยันตัวตนและข้อมูลไดเรกทอรีถูกเปิดเผย LDAPS (LDAP over SSL/TLS, พอร์ต TCP 636) เข้ารหัสการเชื่อมต่อโดยใช้ใบรับรอง StartTLS เป็นทางเลือกที่ยกระดับการเชื่อมต่อ LDAP ที่มีอยู่ให้เป็น TLS โดยใช้พอร์ต 389 เดิม ทั้ง LDAPS และ StartTLS ให้การเข้ารหัส แต่โดยทั่วไป LDAPS ตั้งค่าได้ง่ายกว่าและเชื่อถือได้มากกว่า องค์กรควรกำหนดค่าแอปพลิเคชันทั้งหมดที่ใช้ LDAP ให้ใช้ LDAPS และ Block LDAP ที่ไม่เข้ารหัสบนพอร์ต 389 ที่ไฟร์วอลล์

POP3/IMAP เทียบกับการเรียกคืนอีเมลที่เข้ารหัส

ไคลเอ็นต์อีเมลรุ่นเก่าจะเรียกคืนอีเมลโดยใช้ POP3 (พอร์ต 110) และ IMAP (พอร์ต 143) แบบข้อความธรรมดา ทางเลือกที่เข้ารหัส ได้แก่ POP3S (พอร์ต 995, TLS) และ IMAPS (พอร์ต 993, TLS) แพลตฟอร์มอีเมลสมัยใหม่ (Exchange Online, Google Workspace) บังคับใช้ TLS สำหรับการเชื่อมต่อไคลเอ็นต์ทั้งหมด และรองรับการยืนยันตัวตนด้วยโทเค็น OAuth 2.0 แทนรหัสผ่าน องค์กรควรปิดใช้ การยืนยันตัวตนพื้นฐานบนโปรโตคอลอีเมล — การกำหนดให้ใช้การยืนยันตัวตนสมัยใหม่ (OAuth 2.0 + MFA) จะป้องกันการโจมตีแบบยัดข้อมูลยืนยันตัวตน ซึ่งอาศัยกลไกการยืนยันตัวตนที่ไม่เข้ารหัสของโปรโตคอลอีเมลรุ่นเก่า

# Protocol port reference card
Protocol    Insecure Port  Secure Port  Replacement
---------   ------------   ----------  -----------
Telnet      23             22           SSH
FTP         20/21          22           SFTP
HTTP        80             443          HTTPS
SMTP        25             587/465      SMTPS
POP3        110            995          POP3S
IMAP        143            993          IMAPS
LDAP        389            636          LDAPS
SNMP        161/162        161/162      SNMPv3
RDP         3389           3389         RDP+NLA+TLS

การแทนที่โปรโตคอลในการใช้งานจริง

การแทนที่โปรโตคอลที่ไม่ปลอดภัยไม่ได้มีเพียงการเปิดใช้เวอร์ชันที่ปลอดภัยเท่านั้น — ต้องปิดใช้เวอร์ชันที่ไม่ปลอดภัยอย่างจริงจังด้วย ขั้นตอน: ตรวจสอบการใช้งานโปรโตคอลที่มีอยู่ (การสแกน Nmap บันทึกไฟร์วอลล์) ย้ายแอปพลิเคชันและการกำหนดค่าไปยังโปรโตคอลที่ปลอดภัย ทดสอบอย่างละเอียด (แอปพลิเคชันทางธุรกิจอาจทำงานขัดข้อง) จากนั้น Blockโปรโตคอลที่ไม่ปลอดภัยที่ไฟร์วอลล์และบนโฮสต์ ข้อควรระวังที่พบบ่อย: เครื่องพิมพ์รุ่นเก่าและอุปกรณ์ฝังตัวมักรองรับเฉพาะ FTP หรือ SNMPv2 ระบบอุตสาหกรรมรุ่นเก่าอาจต้องพึ่งพา Telnet กรณีเหล่านี้ต้องใช้การแยกเครือข่ายหรือเปลี่ยนอุปกรณ์จากผู้จำหน่าย แทนการอัปเกรดโปรโตคอลโดยตรง

# Audit for insecure protocol usage
# Nmap: find all Telnet listeners on network
nmap -p 23 10.0.0.0/24 --open -sV

# Find FTP listeners
nmap -p 21 10.0.0.0/24 --open

# Find HTTP (not HTTPS) web services
nmap -p 80 --open 10.0.0.0/24

# Check for SNMPv1/v2c community strings
nmap -sU -p 161 --script snmp-info 10.0.0.0/24

# Block Telnet at firewall after migration
iptables -A FORWARD -p tcp --dport 23 -j DROP
iptables -A INPUT -p tcp --dport 23 -j DROP

ความปลอดภัยของ Remote Desktop Protocol

RDP (Remote Desktop Protocol) (พอร์ต 3389) ใช้กันอย่างแพร่หลายสำหรับการดูแลระบบ Windows ระยะไกล และเป็นเป้าหมายการโจมตีสำคัญ การกำหนดค่า RDP ที่ไม่ปลอดภัย ได้แก่ การเปิดพอร์ต 3389 สู่อินเทอร์เน็ต การใช้การยืนยันตัวตนด้วยรหัสผ่านเท่านั้น และการปิดใช้ NLA การเสริมความปลอดภัยของ RDP: เปิดใช้ Network Level Authentication (NLA) ซึ่งยืนยันตัวตนก่อนเปิดเซสชันเต็มรูปแบบ (ปิดกั้นการเชื่อมต่อที่ไม่ได้ยืนยันตัวตน) กำหนดให้เซสชัน RDP ทั้งหมดใช้ TLS 1.2+ วาง RDP ไว้หลัง VPN หรือเกตเวย์ RDP แทนการเปิดเผยต่ออินเทอร์เน็ต และบังคับใช้ การล็อกบัญชีเพื่อป้องกันการเดารหัสผ่านแบบลองทุกค่า แคมเปญเรียกค่าไถ่จำนวนมากเข้าถึงระบบครั้งแรกผ่าน RDP ที่เปิดเผยและรักษาความปลอดภัยไม่ดี

การเลิกใช้โปรโตคอลที่ไม่ปลอดภัยเป็นระยะ

การย้ายออกจากโปรโตคอลที่ไม่ปลอดภัยในสภาพแวดล้อมใช้งานจริงต้องมีการวางแผนอย่างรอบคอบเพื่อหลีกเลี่ยงการหยุดชะงักทางธุรกิจ แนวทางแบบเป็นระยะ: Phase 1 — ค้นหา: เรียกใช้การสแกน Nmap และตรวจสอบบันทึกไฟร์วอลล์เพื่อระบุการใช้โปรโตคอลข้อความไม่เข้ารหัสทั้งหมด Phase 2 — เปิดใช้ทางเลือกที่ปลอดภัย: กำหนดค่า SSH, SFTP, HTTPS ควบคู่กับบริการที่ไม่ปลอดภัยเดิม Phase 3 — ย้ายผู้ใช้งาน: อัปเดตสคริปต์ แอปพลิเคชัน เครื่องมือเฝ้าติดตาม และขั้นตอนการทำงานของผู้ใช้ให้ใช้โปรโตคอลที่ปลอดภัย Phase 4 — ปิดใช้และ Block: ปิดใช้บริการที่ไม่ปลอดภัยบนแต่ละโฮสต์ และ Block พอร์ตที่ไฟร์วอลล์ การทดสอบในแต่ละระยะช่วยป้องกันการหยุดให้บริการในระบบใช้งานจริง

# Phase 4: Disable and block Telnet permanently

# Disable Telnet service on Linux
systemctl stop telnet.socket
systemctl disable telnet.socket

# Block Telnet at iptables
iptables -A INPUT -p tcp --dport 23 -j DROP
iptables -A OUTPUT -p tcp --dport 23 -j DROP
# Save rules
iptables-save > /etc/iptables/rules.v4

# Block at network firewall (Cisco ASA)
access-list OUTSIDE_IN deny tcp any any eq 23

# Verify: should timeout / connection refused
nc -zv 192.168.1.10 23

ตรวจสอบอย่างรวดเร็ว

ทดสอบความเข้าใจแนวคิด CompTIA Security+ (SY0-701) จากบทเรียนนี้

สรุปบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า โพรโทคอลแบบข้อความล้วน (Telnet, FTP, HTTP, SNMPv1/v2c, LDAP) เปิดเผยข้อมูลประจำตัวและข้อมูลต่าง ๆ ให้ถูกดักฟังบนเครือข่าย จึงต้องแทนที่ด้วย โพรโทคอลทดแทนที่ปลอดภัย (SSH, SFTP, HTTPS, SNMPv3, LDAPS) ซึ่งใช้การเข้ารหัส TLS หรือ SSH เพื่อปกป้องการทำงานเดิม และ การแทนที่โพรโทคอลจำเป็นต้องปิดใช้งานรุ่นที่ไม่ปลอดภัย ทั้งในระดับไฟร์วอลล์และโฮสต์ หลังจากตรวจสอบการพึ่งพาระบบเดิมแล้ว ต่อไปเราจะศึกษาเวอร์ชัน TLS ชุดรหัสลับ และความลับส่งต่ออย่างสมบูรณ์แบบ

คำถามที่พบบ่อย

บทเรียน “การแทนที่โพรโทคอลที่ไม่ปลอดภัย: Telnet กับ SSH, FTP กับ SFTP” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “การแทนที่โพรโทคอลที่ไม่ปลอดภัย: Telnet กับ SSH, FTP กับ SFTP” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Security+ Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Security+ Academy มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “การแทนที่โพรโทคอลที่ไม่ปลอดภัย: Telnet กับ SSH, FTP กับ SFTP”

ทำความเข้าใจว่าเหตุใดโพรโทคอลแบบข้อความเปิด เช่น Telnet, FTP และ HTTP จึงเปิดเผยข้อมูลรับรอง และโพรโทคอลเข้ารหัสที่มาแทนที่ (SSH, SFTP, HTTPS) แก้ปัญหาเหล่านี้อย่างไร คุณปฏิบัติ Security+ Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Security+ Academy หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Security+ Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน

บทเรียน “การแทนที่โพรโทคอลที่ไม่ปลอดภัย: Telnet กับ SSH, FTP กับ SFTP” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Security+ Academy นี้ได้ไหม

ได้ บทเรียน Security+ Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. การแทนที่โพรโทคอลที่ไม่ปลอดภัย: Telnet กับ SSH, FTP กับ SFTP
  2. เวอร์ชัน TLS ชุดรหัสลับ และการรักษาความลับล่วงหน้าอย่างสมบูรณ์
  3. DNS ที่ปลอดภัย: DNSSEC และ DNS ผ่าน HTTPS (DoH)
  4. IPsec โพรโทคอล VPN และความปลอดภัยในการเข้าถึงจากระยะไกล
← กลับไปที่ Security+ Academy