ปัญหาใหญ่แค่ไหนที่จะเจาะรูใน DMZ ไปยังเว็บเซิร์ฟเวอร์เดียว

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

จากความเข้าใจของฉัน (และฉันไม่รู้แบรนด์) เรามีไฟร์วอลล์หนึ่งไฟร์วอลล์สำหรับ DMZ ที่มี IP ภายนอกที่แตกต่างจาก IP หลักของเรากับไฟร์วอลล์อื่น ไฟร์วอลล์อื่นอยู่ระหว่างเว็บเซิร์ฟเวอร์และอินทราเน็ต

ดังนั้นสิ่งที่ชอบ:

Web Server  <==== Firewall ===== Intranet
     |                              |
     |                              |
  Firewall                      Firewall
     |                              |
     |                              |
 Internet IP1                  Internet IP2

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

สิ่งสำคัญที่ต้องพิจารณาคือ:

• จำกัด การเข้าถึงกฎไฟร์วอลล์เฉพาะที่คุณสามารถทำได้ ถ้าเป็นไปได้ตั้งชื่อโฮสต์เฉพาะที่เกี่ยวข้องในกฎพร้อมกับโปรโตคอลเฉพาะ (พอร์ต TCP และ / หรือ UDP) ที่จะใช้ โดยทั่วไปเปิดเฉพาะรูเล็กตามที่คุณต้องการ

• ตรวจสอบให้แน่ใจว่าคุณกำลังบันทึกการเข้าถึงจากโฮสต์ DMZ ไปยังโฮสต์บนเครือข่ายที่มีการป้องกันและหากเป็นไปได้ให้วิเคราะห์บันทึกเหล่านั้นด้วยวิธีอัตโนมัติสำหรับความผิดปกติ คุณต้องการที่จะรู้ว่าเมื่อมีอะไรผิดปกติเกิดขึ้น

• ยอมรับว่าคุณกำลังเปิดเผยโฮสต์ภายในแม้ว่าจะอยู่ในลักษณะทางอ้อมต่ออินเทอร์เน็ตก็ตาม อยู่ด้านบนของแพตช์และอัปเดตสำหรับซอฟต์แวร์ที่คุณเปิดเผยและซอฟต์แวร์ระบบปฏิบัติการของโฮสต์เอง

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

• หากมีข้อกังวลเกี่ยวกับการโจมตี DoS ให้พิจารณาใช้การ จำกัด อัตราเพื่อป้องกันโฮสต์ DMZ ไม่ให้ใช้ทรัพยากรของโฮสต์ภายในหมดลง

• คุณอาจต้องการพิจารณาการใช้เลเยอร์ 7 "ไฟร์วอลล์" ซึ่งการร้องขอจากโฮสต์ DMZ จะถูกส่งผ่านไปยังโฮสต์ภายในที่มีวัตถุประสงค์พิเศษที่สามารถ "ฆ่า" การร้องขอตรวจสอบสติและจากนั้นส่งต่อไปยัง โฮสต์แบ็คเอนด์ "ของจริง" เนื่องจากคุณกำลังพูดถึงการเชื่อมต่อกับแอ็พพลิเคชันแบ็คออฟฟิศของคุณบน IBM iSeries ของคุณฉันเดาว่าคุณมีความสามารถ จำกัด ในการดำเนินการตรวจสอบสติกับคำขอที่เข้ามาใน iSeries

หากคุณเข้าใกล้สิ่งนี้ด้วยวิธีการที่เป็นระเบียบและมีความรู้สึกร่วมกันเกี่ยวกับเรื่องนี้ไม่มีเหตุผลที่คุณไม่สามารถทำสิ่งที่คุณกำลังอธิบายได้ในขณะที่ลดความเสี่ยงลงในเวลาเดียวกัน

ตรงไปตรงมาว่าคุณมี DMZ ที่ไม่สามารถเข้าถึงเครือข่ายที่มีการป้องกันได้อย่างอิสระทำให้คุณก้าวกระโดดเกินขอบเขตเครือข่ายที่ฉันเคยเห็น สำหรับบางคนดูเหมือนว่า DMZ หมายถึง "อินเทอร์เฟซอื่นบนไฟร์วอลล์อาจมีที่อยู่ RFC 1918 ที่แตกต่างกันและโดยทั่วไปแล้วการเข้าถึงอินเทอร์เน็ตและเครือข่ายที่ได้รับการป้องกัน" นั้นเป็นอิสระ พยายามรักษา DMZ ของคุณให้ถูกล็อคไว้เท่าที่จะทำได้ในขณะที่ยังคงบรรลุเป้าหมายทางธุรกิจและคุณจะทำได้ดี

เห็นได้ชัดว่ามีอันตรายบางอย่าง แต่คุณสามารถทำได้ โดยพื้นฐานแล้วคุณกำลังเปิดรูเข็มที่ใครบางคนสามารถผ่านเข้าไปได้ จำกัด เฉพาะเซิร์ฟเวอร์ที่ปลายทั้งสองและอนุญาตเฉพาะข้อมูลบนพอร์ตที่เลือก ไม่ใช่ความคิดที่ดีที่จะใช้การแปลที่อยู่พอร์ตเพื่อใช้พอร์ตที่แปลกประหลาด ถึงกระนั้นก็ตามการรักษาความปลอดภัยด้วยความสับสนก็ยังไม่มีการรักษาความปลอดภัยเลย ตรวจสอบให้แน่ใจว่าสิ่งที่เซิร์ฟเวอร์ในฝั่งอื่น ๆ มีวิธีตรวจสอบข้อมูลที่ผ่านการเชื่อมต่อนั้นเป็นสิ่งที่ดูเหมือนว่าจะเป็น ... หรืออย่างน้อยก็มีไฟร์วอลล์ที่รับรู้บริบท นอกจากนี้ยังมีไฟร์วอลล์บางอย่างที่สร้างขึ้นมาเพื่อสิ่งนี้ ... ฉันรู้ว่า Microsoft ISA ทำสิ่งเดียวกันนี้สำหรับเซิร์ฟเวอร์ OWA และ Exchange