Web Proxy Autodiscovery Protocol (WPAD) กับ ISA และ TMG

วันนี้ขอมาสาระสักเล็กน้อยเกี่ยวกับ WPAD บน ISA และ TMG นะครับ

WPAD หรือ Web Proxy Automaticdiscovery Protocol (WPAD) เป็นโปรโตคอลที่ถูกออกแบบมาให้ไคลเอนต์สามารถค้นหาพร็อกซีได้โดยอัตโนมัติผ่านเว็บเบราเซอร์ ซึ่งถ้าหากผู้อ่านทุกท่านลอง Sniff ข้อมูลในขณะที่เปิดเว็บเบราเซอร์ขึ้นมาไม่ว่าจะตัวไหนก็ตาม ก็จะพบว่าจะมีการพยายาม Resolve Hostname ที่ชื่อ WPAD ก่อนโดยตลอด กระบวนการนี้คือการค้นหาพร็อกซีโดยอัตโนมัตินั่นเอง

ปกติแล้วเราสามารถใช้ระบบนี้ได้โดยผ่านทั้ง DHCP และ DNS สำหรับ DHCP จะสามารถใช้ได้เฉพาะซอฟท์แวร์ของไมโครซอฟท์เท่านั้น (ยกเว้นเราจะเขียน Add-on สำหรับเว็บเบราเซอร์อื่นๆ) เพราะ DHCP Option ที่ใช้นี้จะถูกระบุใน RFC ว่าเป็น Private Use นั่นหมายความว่า Vendor เจ้าไหนก็สามารถนำไปใช้กับซอฟท์แวร์ของตนเองได้หมด ซึ่งในกรณีนี้ก็คือ ISA, TMG จะใช้กับ IE นั่นเอง

ในทาง Security แล้ว เราไม่ควรใช้งาน WPAD  ในระบบของเราเท่าใดนัก เพราะการใช้งาน WPAD จะทำให้ Attacker สามารถจะ Identify ตัว Proxy Server ของเราได้ ซึ่งแน่นอนว่าเมื่อได้ข้อมูลตรงนี้แล้ว การทำ Information Gathering รวมไปถึงการทำ Vulnerability Assessment กับตัว Proxy จะทำได้อย่างมีประสิทธิภาพมาก ในท้ายที่สุดก็จะนำมาสู่การโจมตีตัว Proxy นั่นเอง

อย่างไรก็ตามในบางระบบการใช้งาน WPAD ก็เป็นสิ่งที่จำเป็น ดังนั้นหากเราเลี่ยงไม่ได้แล้ว สิ่งที่ควรจะทำคือการ Hardening ตัว Proxy ของเราให้ดีที่สุด ซึ่งก็ทำได้หลายวิธีด้วยกันครับ

อีกสิ่งหนึ่งที่อาจจะมีข้ึ่อถกเถียงบ้างคือตัว DHCP Option นั้นยังมีหลายๆท่านเข้าใจว่าต้องใส่เป็น Hostname เท่านั้น ซึ่งผมขอเรียนว่าไม่จำเป็นครับ เพราะการใส่เป็น Hostname แล้วเท่ากับว่าบังคับให้ไคลเอนต์ทุกคนต้องชี้  DNS, WINS มาที่ระบบของท่านเอง ซึ่งในบางครั้งทำไม่ได้แน่ๆ จะหวังไปพึ่ง NetBIOS ก็อยากเรียนว่าสมัยนี้แล้วจะใช้ NetBIOS ให้ล่อเป้าในการทำ Enum และ Exploit ไปทำไม จริงไหมครับ

OS Fingerprint หรือระบบเราจะมีรอยนิ้วมือ

ห่างหายไปนานมาครั้งนี้แวะเอาเรื่อง Security มาฝากกันครับ

.

ในการทำ Auditing หรือการทดสอบระบบโดยการลองแฮกเข้าไปนั้น ขั้นตอนแรกที่ทุกคนจะต้องทำ (ในกรณีที่ไม่รู้ข้อมูลใดๆมาก่อนเลย) ก็คือ Information Gathering

Information Gathering คือการรวบรวมข้อมูลเกี่ยวกับเป้าหมายให้มากที่สุดเท่าที่จะมากได้ อย่างไรก็ดีข้อมูลที่รวบรวมหากเป็นไปได้ควรเลือกมานิดจะดีมาก เพราะมีหลายกรณีเหมือนกันที่เป้าหมายมีข้อมูลใน Public Website เยอะมาก เช่น ผู้ใช้ในองค์กรเล่นเน็ตกระจาย เอาเมลองค์กรไปใช้ซะทุกเว็บที่ตนเข้า ข้อมูลเหล่านี้แม้จะมีประโยชน์มากในกรณีที่จะต้องทำ Social Engineering แต่ปัจจุบันคงต้องยอมรับกันตรงๆว่าองค์กรหลายๆแห่งยังไม่มีความต้องการทดสอบในส่วน Social Engineering เท่าใดนัก ดังนั้นความพยายามในการรวบรวมข้อมูลส่วนนี้ที่มากจนเกินไปอาจจะก่อให้เกิดการเสียเวลาได้เหมือนกัน

นอกจากข้อมูลประเภท DNS Record, IP Block แล้วอีกสิ่งหนึ่งที่ควรจะหามาให้ได้นั้นคงหนีไม่พ้น Operating System หรือ Application ที่ติดตั้งอยู่ เพราะเมื่อรู้แล้วก็จะทำการต่อไปได้ไม่ยาก การทำงานในส่วนนี้เราจะเรียกว่าการหา Fingerprint หรือรอยนิ้วมือของ OS นั่นเอง

ในกรณี Web Server เรามีวิธีการมากมายเลยที่จะดูว่า Web Server นี้ใช้ซอฟท์แวร์ใด วิธีง่ายที่สุดคงหนีไม่พ้นการ Sniff ข้อมูลและดูในส่วนของ HTTP Header ซึ่งก็จะมีรายละเอียดของ Application (IIS, Apache) รวมทั้ง OS (Windows, Linux, etc.) ส่งมาให้พร้อมศัพท์

แต่ปัจจุบันผู้ดูแลระบบหลายๆท่านได้ตัดฟิลด์ที่ว่านี้ใน HTTP Header ทิ้งไปเรียบร้อย แต่ก็ยังไม่พ้นการใช้เทคนิค OS Fingerprint จากซอฟท์แวร์ประเภท OS Detection อยู่ดีครับ เพราะซอฟท์แวร์ประเภทนี้จะตรวจสอบรายละเอียดที่มากกว่า HTTP Header เช่น การตรวจสอบในส่วนของ TCP/IP Paremeter ต่างๆ

อย่างไรก็ดีเรายังสามารถจะปลอม OS Fingerprint ของเราได้โดยการ Modify TPC/IP Parameter แต่ควรทำอย่างระมัดระวังเนื่องจากการเปลี่ยนแปลงในส่วนนี้อาจจะมีส่วนไปทำให้ Application มี Performance ต่ำลงไปครับ

.

สำหรับวันนี้ต้องขอตัวก่อนนะครับ พบกันใหม่โอกาสหน้าครับ

.

.

ปล วันเสาร์นี้มีสอน Network Infrastructure นะครับ (ไม่วายขายยา)

ScreenOS ความสบายที่ยังไม่อยากให้จากกันเลยจริงๆ

ปัจจุบันทาง Juniper Networks มีการวางจำหน่ายอุปกรณ์ประเภท  Gateway Appliance (หรือง่ายๆก็ Firewall แหละครับ) ในโมเดลใหม่คือ SRX ซึ่งมี OS เป็น JUNOS อันเป็น OS ที่สร้างชื่อให้กับ Juniper มากๆ เพราะ JUNOS เป็น OS ที่อยู่ใน Router ของทาง Juniper ที่ขึ้นชื่อมากใน Router ระดับ Hi-End พวก ISP ใหญ่ๆในเมืองนอกนิยมกันมาก

ทุกอย่างดูจะดีทีเดียวครับ เพราะ JUNOS ถือเป็น OS ที่การสั่งงานผ่าน CLI ยอดเยี่ยมมากเฉกเช่น CISCO IOS เลย (แต่ GUI อย่าไปคาดหวังนะครับ ฮ่าๆ รู้กันครับของแบบนี้) และยังเสถียรอย่างมากอีกด้วย แต่สำหรับคนที่ทำ Firewall ของ Juniper มาแต่ต้นคงจะคุ้นเคยกันอยู่กับ ScreenOS มากพอสมควร (ซึ่งไปซื้อเค้ามาอีกที เนื่องจากจะขายไฟร์วอลล์ด้วย) ซึ่งปัจจุบันทาง Juniper Networks ยืนยันว่าจะยังคงขาย Firewall ที่เป็น ScreenOS อยู่ แต่หากดูจากเทรนด์แล้ว คงพอจะเดาๆกันได้ว่าอีกไม่นาน ScreenOS น่าจะหายไปจากตลาดแล้ว เพราะหากดู Performance ของ SRX (JUNOS) กับ SSG (ScreenOS) แล้วจะเห็นชัดๆเลยว่าราคาที่ตั้งมานั้น SRX ทำราคาได้ดีกว่ามาก เหมือนกับว่าตั้งใจว่ากลุ่มลูกค้าใหม่นี่เอา JUNOS ไปเลย ส่วน ScreenOS จะเก็บไว้บริการลูกค้าเก่าหรือคนที่มีอยู่แล้วแต่จะซื้อเพิ่มเพื่อทำ HA กัน

เรื่องนี้สำหรับคนที่คุ้นเคยกับ ScreenOS อยู่แล้วคงจะต้องเสียเวลามาเรียนรู้ JUNOS นิดหนึ่ง (เฉพาะคนไม่เคยทำ Router ถ้าเคยทำก็ command เดิมๆเลย เพิ่มมาแต่ส่วน firewall, security) ถามว่าเป็นเรื่องลำบากไหม ผมคิดว่าไม่เท่าไหร่ครับเพราะเอาจริงๆคนที่ทำด้าน Network มานานๆเปลี่ยน Hardware หรือ Command นิดหน่อยไม่น่าจะกระเทือนเท่าไหร่หรอกครับ เพราะอุปกรณ์ Network ทุกอย่างมันก็เกิดมาจากทฤษฎีและมาตรฐานเดียวกันอยู่แล้ว ดังนั้นหากแม่นเรื่องพวกนี้ไปทำอะไรก็รอดหมดครับ

แต่สิ่งที่ผมรู้สึกเสียดายนิดหน่อยคือเรื่องที่ต้องจาก CLI ที่คุ้นเคยอย่าง ScreenOS ไปมากกว่า เพราะผมเองทำ ScreenOS มาระยะหนึ่ง และรู้สึกว่า CLI ของมันสะดวกดี ถึงขนาดว่ามีไฟล์เก็บ Useful Command ไว้เลย เวลาจะใช้ก็มาแก้ค่าไอพีกะค่าจิปาถะเล็กน้อย กอปวางเข้าไป จบงานเลย งานนี้เลยต้องบอกว่าเสียดายเล็กน้อยครับ

งานชิ้นล่าสุดที่ได้ไปทำก็คือวันศุกร์ที่ผ่านมา หิ้วน้องเล็กอย่าง SSG20 ไปทำ Lab Test งานชิ้นหนึ่ง ไปถึงก็โยน command ไป แป้บเดียวจบ จากนั้นก็ไปเซตตัวอื่นๆต่อ สรุปจบงาน Test ได้ในครึ่งวัน เรียกว่าหากเป็นตัวอื่นผมคิดว่าน่าจะเสียเวลามากกว่านี้แน่ๆครับ พอทำเสร็จก็เลยมาคิดได้ว่า อีกไม่นานจะต้องทำ JUNOS แล้วแน่ๆ งานนี้เลยรู้สึกเสียดายนิดๆ (แต่หากมี Lab Test หากเป็นไปได้ก็จะใช้ SSG20 นี่ล่ะ และ SSG20 ตัวนี้ในออฟฟิซเค้าไม่เรียก Firewall กันแล้ว เพราะมี Lab ทีไร มันกลายเป็น Router ทุกที ไม่ NAT ก็ Route แทบไม่ได้เซต security function ไหนทีมันมีเลย นอกจาก any any allow ฮ่าๆ)

เอ้า โชคดีนะ ScreenOS

การทำ Static NAT บน Juniper

วันนี้มาอัปบล๊อคกันแบบมีสาระหน่อยครับ

.

การทำ Static NAT ถือเป็นเรื่องจำเป็นมากในกรณีที่เราต้องการให้ผู้ใช้ภายนอก

เข้ามาใช้งาน Server ที่อยู่ใน DMZ หรือ Trust Zone

การทำ Static NAT ใน Juniper เมื่อเทียบกับ Checkpoint อาจจะดูยุ่งยากกว่าเล็กน้อยครับ

เพราะใน Checkpoint คลิกที่ Host Object แล้วใส่ NAT IP ไปก็จบแล้ว

แต่ใน Juniper จะต้องไปเซต Interface ก่อน แล้วมาทำ Policy ต่ออีก

และหากเพิ่งเริ่มทำอาจจะงงๆได้เพราะมันจะไม่ได้เขียนว่า NAT ด้วยล่ะเอ้อ

.

Static NAT ใน Juniper จะเรียกว่า MIP หรือ Mapped IP Addresses

การทำงานจะเป็นดังรูปครับ

Juniper MIP (Static NAT)

ว่าแล้วก็ส่งต่อ Command ไปครับ

set interface ethernet1 zone trust
set interface ethernet1 ip 10.1.1.1/24
set interface ethernet1 nat
set interface ethernet2 zone untrust
set interface ethernet2 ip 1.1.1.1/24

set interface ethernet2 mip 1.1.1.5 host 10.1.1.5 netmask 255.255.255.255 vrouter trust-vr

อื่นๆเกี่ยวกับ MIP

1. MIP จะเก็บอยู่ใน Global Zone
2. เมื่อทำ MIP เวลา Server จะ Initiate Connection มันจะออกไปเป็น IP ของ MIP เลย ไม่สามารถใช้งาน NAT Policy อื่นๆได้ ดังนั้นในกรณีนี้จะเป็นปัญหาเรื่อง Security ทันที เพราะเท่ากับว่าตัว Server ภายใน DMZ หรือ Trust Zone ไม่ได้ถูกซ่อน IP จริงๆของตัวเองเอาไว้เมื่อติดต่อกับ Untrust Zone ดังนั้นหากกังวลเรื่องนี้คงจะต้องใช้วิธี NAT แบบอื่นแทน เช่น VIP ครับ

สำหรับวันนี้ขอตัวก่อนนะครับ วันหลังมีโอกาสจะแวะเอา Tips เล็กๆน้อยๆมาฝากอีกครับ

รับสอน Windows Server, Active Directory, Exchange, ISA และอุปกรณ์ Network มากมาย

วันนี้ขอนอกเรื่องจากเรื่องเล่ามาโฆษณานิดหนึ่งนะครับ

รับสอนของต่างๆดังนี้นะครับ

Windows Server 2008 (Active Directory)

Exchange Server 2007

ISA Server 2006

และอื่นๆอีกมากมาย

รายละเอียดตามนี้เลยครับ

http://www.izitcer.com/?page_id=29

.

.

สอนโดย Engineer (SI – System Integrator) ที่ยังทำงานทั้งด้าน Design และ Configuration ครับ ^^

สนใจติดต่อได้ตามรายละเอียดด้านบนครับ