N
NOOB_DOS
สมาชิกใหม่
สมาชิกรุ่นแรก
สมาชิก
LV
1
เทสพอร์ตที่เปิดไว้แล้วอย่าง RDP กับทูลดีๆ อย่าง Network Watcher ดีกว่าเธอว์
อย่าเคยชินกับการใช้แต่ ICMP ในเมื่อเค้าบล็อกกันหมดแล้ว
ชาวเน็ตเวิร์กล้วนใช้การ Ping/Tracert ผ่านโปรโตคอล ICMP ในการแก้ปัญหาการเชื่อมต่อตั้งแต่สมัยพระเจ้าเหา ที่ท่องกันมา (ตั้งแต่สอบ TSHOOT ใน CCNP) ไล่ตั้งเลเยอร์แรกของ OSI Model ว่าถ้าติดต่อปลายทาง เข่น ออกเน็ตไม่ได้ ให้เช็คอุปกรณ์กายภาพ เช่นสายแลนเสียบแน่นไหม สวิตช์หรือเราเตอร์ร้อน ควรปิดพักแล้วเปิดใหม่ไหมก่อน (เรื่องจริง! 55+ คือถ้าว่าใช้งานอยู่ดีๆ ไม่มีใครไปเปลี่ยนการตั้งค่าอะไร)
แล้วค่อยขึ้นมาเลเยอร์ 2 ดู arp -a เห็น MAC ของเราเตอร์หรือสวิตช์ L3 เราไหม แล้วถึงขึ้นมาปิงดูไล่จากไอพีตัวเองเพื่อเช็คการ์ดแลนเราเจ๊งไหม ไล่ปิงทยอยออกไปที่เกตเวย์ ไล่ Tracert ดูฮอปถัดๆ ไปเรื่อยๆ
ประการแรก ปัจจุบันเราใช้คลาวด์ตั้งแต่ระดับ SaaS ขึ้นไป เราไม่มีสายแลน การ์ดแลน หรือสวิตช์เราเตอร์กายภาพเลเยอร์ 1 หรือแม้แต่เลเยอร์ 2 MAC ให้เช็ค
จึงไม่แปลกที่คนทำคลาวด์จะคิดถึงการปิง การใช้ ICMP ยิงเพื่อเช็คการเชื่อมต่อ รวมไปถึงแฮ็กเกอร์ที่อยากให้ระบบล่มด้วย
ใช่! รวมถึงคนไม่ประสงค์ดีด้วย
เวลาปิงหรือยิง ICMP echo request ไป เราต้องให้ปลายทางตอบ ICMP echo reply กลับมา ถ้าเกิดยิงเยอะ (Flood) ยิงจากบอทเน็ตหลายล้านตัว (Distributed) พร้อมกัน ก็ต้องเสียเวลาเสียทรัพยากรในการประมวลผลเพื่อตอบ แทบทราฟิกรีพลายก็ล้นกินแบนด์วิธขึ้นมาอีกเท่าตัว ระบบเหยื่อเป้าหมายไม่เหลือเวลาทำมาหากินอะไรอย่างอื่น ล่มค้างด้วยภาวะ DDoS แน่นอน
จึงกลายเป็นดีฟอลต์ที่แม้ตั้งแต่ระดับโฮสต์ เช่น ไฟร์วอลล์ของโอเอสบนวีเอ็ม ก็จะบล็อก ICMP ก่อน เพราะไม่ใช่โปรโตคอลอะไรสำหรับการใช้งานจริง เลขพอร์ตก็ไม่มีให้อ้างถึงระดับแอพพลิเคชันไหน
ดังนั้น ประการที่สอง ถ้าคิดจะเทสปิงไปที่วีเอ็ม ก็ต้องเสียเวลารีโมตเข้าไปอะลาวกฎรับ ICMP ขาเข้า (Inbound) นั้น ยังไม่นับรวม NSG ที่สร้างมาให้ตอนสร้างวีเอ็มวินโดวส์ (นอกจากเราเลือกเปลี่ยนเป็นไม่สร้างแทน) ที่ไม่มีออพชั่นให้เลือกเปิด ICMP ตั้งแต่แรกอีก ต้องเสียเวลาเข้าไปเพิ่มกฎใน NSG ขาอินบาวด์ที่การ์ดแลน NIC ของวีเอ็มนั้นด้วย
อ่านแล้วสะดุดตรงไหนไหม? ใช้ ตอนสร้างวีเอ็มใน Azure หน้าแรกล่างสุดจะมีให้เลือกว่าจะเปิดพอร์ตเข้าไปรีโมตจัดการอันไหน เช่น HTTP(S)80(443)/SSH22(กรณีลีนุกซ์)/RDP3389(กรณีวินโดวส์) ถ้าเลือกเปิดพอร์ตไหนแล้ว ทั้งไฟร์วอลล์บนโอเอส ทั้ง NSG บนพอร์ตแลน (ถ้าปล่อยให้เลือกสร้างไว้) ก็จะมีกฎเปิดรับโปรโตคอลขาเข้านั้นๆ ให้เรียบร้อย ไม่ต้องเสียเวลาไปเพิ่มกฎใหม่อีก (รีโมตเข้าวีเอ็มทีก็หลายนาทีอยู่ไหม)
เรามักเลือกเปิดพอร์ตขาเข้า (Public inbound ports) อยู่แล้ว เช่น พอร์ต TCP 3389 (RDP) ตอนสร้าง Virtual Machine ใหม่ที่ใช้โอเอสเป็นวินโดวส์ ซึ่ง NSG บน NIC รวมถึงไฟร์วอลล์บนโอเอสของ VM ก็จะเปิดพอร์ตนี้ให้
สู้เราใช้ทราฟิกเลขพอร์ตปลายทางที่ปลายทางของเราเปิดรับอยู่แล้วในการเช็คการเชื่อมต่อไม่ดีกว่าเหรอ แล้วเราก็มีเซอร์วิสบนหน้า Azure อยู่แล้วสำหรับกรณีนี้ชื่อ Network Watcher ที่สามารถเข้าไปทางหน้า VM ต้นทางที่เราอยากเช็ค > Connection Troubleshoot > Network Watcher (หรือเข้า Network Watcher > IP Flow ก็ได้กรณีสร้างตัว Network Watcher ขึ้นมาแล้ว)
วิธีที่แนะนำ: เข้ามาที่ VM ที่เป็นต้นทางทดสอบการเชื่อมต่อ แล้วลงมาที่เมนูหมวด Support + Troubleshooting คลิกเลือก Correction troubleshoot แล้วคลิกลิงค์ Use Network Watcher for detailed connection tracking
แล้วเลือกทราฟิก TCP พอร์ต 3389 (RDP) กรณีวีเอ็มปลายทางเป็นวินโดวส์ที่เปิดพอร์ตรอไว้ โอเคมันอาจจะช้ากว่าเทสปิงหน่อย (เพราะส่งโพรบไปตั้ง 66 ครั้ง ถ้าปิง ICMP ส่งไปแค่ 10 ครั้ง //เออ ทำไมเนอะ?) แต่ก็ได้ผลเทสเลยพร้อมค่า Latency และข้อมูล Hop ระหว่างทางเรียบร้อยเสมือนทำ Traceroute
ตรงนี้ล่ะ แทนที่จะเลือก ICMP ก็ไปเลือก Protocol เป็น TCP ในพอร์ตที่ VM ปลายทางเปิดรับอยู่แล้วแทน
ไม่ต้องเสียเวลารีโมตเข้าไปแก้ไฟร์วอลล์ในวีเอ็ม (เปิดใช้แบชชั้นเข้าผ่านหน้าเว็บก็เสียตังค์รายนาทีอีก) แล้วอย่างนี้จะยังเทสปิงบนคลาวด์กันทำไมเอ่ย
ได้ข้อมูลละเอียดเสมือน Traceroute มาเลย โดยไม่ต้องเสียเวลารีโมตเข้าไปทำบน VM ด้วยซ้ำ
THX | CR: thaicysec
อย่าเคยชินกับการใช้แต่ ICMP ในเมื่อเค้าบล็อกกันหมดแล้ว
ชาวเน็ตเวิร์กล้วนใช้การ Ping/Tracert ผ่านโปรโตคอล ICMP ในการแก้ปัญหาการเชื่อมต่อตั้งแต่สมัยพระเจ้าเหา ที่ท่องกันมา (ตั้งแต่สอบ TSHOOT ใน CCNP) ไล่ตั้งเลเยอร์แรกของ OSI Model ว่าถ้าติดต่อปลายทาง เข่น ออกเน็ตไม่ได้ ให้เช็คอุปกรณ์กายภาพ เช่นสายแลนเสียบแน่นไหม สวิตช์หรือเราเตอร์ร้อน ควรปิดพักแล้วเปิดใหม่ไหมก่อน (เรื่องจริง! 55+ คือถ้าว่าใช้งานอยู่ดีๆ ไม่มีใครไปเปลี่ยนการตั้งค่าอะไร)
แล้วค่อยขึ้นมาเลเยอร์ 2 ดู arp -a เห็น MAC ของเราเตอร์หรือสวิตช์ L3 เราไหม แล้วถึงขึ้นมาปิงดูไล่จากไอพีตัวเองเพื่อเช็คการ์ดแลนเราเจ๊งไหม ไล่ปิงทยอยออกไปที่เกตเวย์ ไล่ Tracert ดูฮอปถัดๆ ไปเรื่อยๆ
ประการแรก ปัจจุบันเราใช้คลาวด์ตั้งแต่ระดับ SaaS ขึ้นไป เราไม่มีสายแลน การ์ดแลน หรือสวิตช์เราเตอร์กายภาพเลเยอร์ 1 หรือแม้แต่เลเยอร์ 2 MAC ให้เช็ค
จึงไม่แปลกที่คนทำคลาวด์จะคิดถึงการปิง การใช้ ICMP ยิงเพื่อเช็คการเชื่อมต่อ รวมไปถึงแฮ็กเกอร์ที่อยากให้ระบบล่มด้วย
ใช่! รวมถึงคนไม่ประสงค์ดีด้วย
เวลาปิงหรือยิง ICMP echo request ไป เราต้องให้ปลายทางตอบ ICMP echo reply กลับมา ถ้าเกิดยิงเยอะ (Flood) ยิงจากบอทเน็ตหลายล้านตัว (Distributed) พร้อมกัน ก็ต้องเสียเวลาเสียทรัพยากรในการประมวลผลเพื่อตอบ แทบทราฟิกรีพลายก็ล้นกินแบนด์วิธขึ้นมาอีกเท่าตัว ระบบเหยื่อเป้าหมายไม่เหลือเวลาทำมาหากินอะไรอย่างอื่น ล่มค้างด้วยภาวะ DDoS แน่นอน
จึงกลายเป็นดีฟอลต์ที่แม้ตั้งแต่ระดับโฮสต์ เช่น ไฟร์วอลล์ของโอเอสบนวีเอ็ม ก็จะบล็อก ICMP ก่อน เพราะไม่ใช่โปรโตคอลอะไรสำหรับการใช้งานจริง เลขพอร์ตก็ไม่มีให้อ้างถึงระดับแอพพลิเคชันไหน
ดังนั้น ประการที่สอง ถ้าคิดจะเทสปิงไปที่วีเอ็ม ก็ต้องเสียเวลารีโมตเข้าไปอะลาวกฎรับ ICMP ขาเข้า (Inbound) นั้น ยังไม่นับรวม NSG ที่สร้างมาให้ตอนสร้างวีเอ็มวินโดวส์ (นอกจากเราเลือกเปลี่ยนเป็นไม่สร้างแทน) ที่ไม่มีออพชั่นให้เลือกเปิด ICMP ตั้งแต่แรกอีก ต้องเสียเวลาเข้าไปเพิ่มกฎใน NSG ขาอินบาวด์ที่การ์ดแลน NIC ของวีเอ็มนั้นด้วย
อ่านแล้วสะดุดตรงไหนไหม? ใช้ ตอนสร้างวีเอ็มใน Azure หน้าแรกล่างสุดจะมีให้เลือกว่าจะเปิดพอร์ตเข้าไปรีโมตจัดการอันไหน เช่น HTTP(S)80(443)/SSH22(กรณีลีนุกซ์)/RDP3389(กรณีวินโดวส์) ถ้าเลือกเปิดพอร์ตไหนแล้ว ทั้งไฟร์วอลล์บนโอเอส ทั้ง NSG บนพอร์ตแลน (ถ้าปล่อยให้เลือกสร้างไว้) ก็จะมีกฎเปิดรับโปรโตคอลขาเข้านั้นๆ ให้เรียบร้อย ไม่ต้องเสียเวลาไปเพิ่มกฎใหม่อีก (รีโมตเข้าวีเอ็มทีก็หลายนาทีอยู่ไหม)
เรามักเลือกเปิดพอร์ตขาเข้า (Public inbound ports) อยู่แล้ว เช่น พอร์ต TCP 3389 (RDP) ตอนสร้าง Virtual Machine ใหม่ที่ใช้โอเอสเป็นวินโดวส์ ซึ่ง NSG บน NIC รวมถึงไฟร์วอลล์บนโอเอสของ VM ก็จะเปิดพอร์ตนี้ให้
สู้เราใช้ทราฟิกเลขพอร์ตปลายทางที่ปลายทางของเราเปิดรับอยู่แล้วในการเช็คการเชื่อมต่อไม่ดีกว่าเหรอ แล้วเราก็มีเซอร์วิสบนหน้า Azure อยู่แล้วสำหรับกรณีนี้ชื่อ Network Watcher ที่สามารถเข้าไปทางหน้า VM ต้นทางที่เราอยากเช็ค > Connection Troubleshoot > Network Watcher (หรือเข้า Network Watcher > IP Flow ก็ได้กรณีสร้างตัว Network Watcher ขึ้นมาแล้ว)
วิธีที่แนะนำ: เข้ามาที่ VM ที่เป็นต้นทางทดสอบการเชื่อมต่อ แล้วลงมาที่เมนูหมวด Support + Troubleshooting คลิกเลือก Correction troubleshoot แล้วคลิกลิงค์ Use Network Watcher for detailed connection tracking
แล้วเลือกทราฟิก TCP พอร์ต 3389 (RDP) กรณีวีเอ็มปลายทางเป็นวินโดวส์ที่เปิดพอร์ตรอไว้ โอเคมันอาจจะช้ากว่าเทสปิงหน่อย (เพราะส่งโพรบไปตั้ง 66 ครั้ง ถ้าปิง ICMP ส่งไปแค่ 10 ครั้ง //เออ ทำไมเนอะ?) แต่ก็ได้ผลเทสเลยพร้อมค่า Latency และข้อมูล Hop ระหว่างทางเรียบร้อยเสมือนทำ Traceroute
ตรงนี้ล่ะ แทนที่จะเลือก ICMP ก็ไปเลือก Protocol เป็น TCP ในพอร์ตที่ VM ปลายทางเปิดรับอยู่แล้วแทน
ไม่ต้องเสียเวลารีโมตเข้าไปแก้ไฟร์วอลล์ในวีเอ็ม (เปิดใช้แบชชั้นเข้าผ่านหน้าเว็บก็เสียตังค์รายนาทีอีก) แล้วอย่างนี้จะยังเทสปิงบนคลาวด์กันทำไมเอ่ย
ได้ข้อมูลละเอียดเสมือน Traceroute มาเลย โดยไม่ต้องเสียเวลารีโมตเข้าไปทำบน VM ด้วยซ้ำ
THX | CR: thaicysec