Seberapa besar masalah untuk melubangi DMZ ke satu server web?


15

Saat ini kami memiliki server web kami di DMZ. Server web tidak dapat melihat apa pun dalam jaringan internal, tetapi jaringan internal dapat melihat server web. Seberapa amankah membuat lubang di firewall antara DMZ dan jaringan internal untuk hanya satu server web di intranet? Kami sedang mengerjakan sesuatu yang akan berinteraksi dengan beberapa aplikasi back-office kami (yang semuanya ada di satu server) dan akan jauh lebih mudah untuk melakukan proyek ini jika kami dapat berkomunikasi langsung dengan server IBM i yang menyimpan data ini ( melalui layanan web).

Dari pemahaman saya (dan saya tidak tahu merek), kami memiliki satu firewall untuk DMZ dengan IP eksternal yang berbeda dari IP primer kami dengan firewall lain. Firewall lain adalah antara server web dan intranet.

Jadi sesuatu seperti:

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

Bagaimana dengan beberapa detail seperti apa firewall menyediakan DMZ ini?
SpacemanSpiff

@SpacemanSpiff Saya mencoba dari pengetahuan minimal yang saya miliki tentang jaringan. Saya seorang pengembang yang merencanakan proyek berikutnya ini dan memberikan pilihan.
Mike Wills

Jawaban:


25

Tidak ada yang salah dengan menciptakan mekanisme akses untuk host di DMZ untuk mengakses host di jaringan yang dilindungi saat ini diperlukan untuk mencapai hasil yang Anda inginkan. Mungkin, itu tidak disukai untuk dilakukan, tetapi kadang-kadang itu satu-satunya cara untuk menyelesaikan pekerjaan.

Hal-hal utama yang perlu dipertimbangkan adalah:

  • Batasi akses ke aturan firewall paling spesifik yang Anda bisa. Jika memungkinkan, beri nama host spesifik yang terlibat dalam aturan bersama dengan protokol spesifik (port TCP dan / atau UDP) yang akan digunakan. Pada dasarnya, buka lubang sekecil yang Anda butuhkan.

  • Pastikan bahwa Anda mencatat akses dari host DMZ ke host di jaringan yang dilindungi dan, jika mungkin, menganalisis log-log tersebut secara otomatis untuk anomali. Anda ingin tahu kapan sesuatu yang luar biasa terjadi.

  • Ketahuilah bahwa Anda mengekspos host internal, meskipun secara tidak langsung, ke Internet. Tetap di atas tambalan dan pembaruan untuk perangkat lunak yang Anda buka dan perangkat lunak sistem operasi host itu sendiri.

  • Pertimbangkan otentikasi timbal balik antara host DMZ dan host internal, jika itu layak dengan arsitektur aplikasi Anda. Akan menyenangkan mengetahui bahwa permintaan yang datang ke host internal sebenarnya berasal dari host DMZ. Apakah Anda dapat melakukan ini atau tidak akan sangat tergantung pada arsitektur aplikasi Anda. Juga, ingatlah bahwa seseorang yang "memiliki" host DMZ akan dapat membuat permintaan ke host internal bahkan jika otentikasi sedang terjadi (karena mereka akan, secara efektif, menjadi host DMZ).

  • Jika ada kekhawatiran tentang serangan DoS, pertimbangkan untuk menggunakan pembatasan tingkat untuk mencegah host DMZ menghabiskan sumber daya host internal.

  • Anda mungkin ingin mempertimbangkan untuk menggunakan pendekatan layer 7 "firewall", di mana permintaan dari host DMZ diteruskan terlebih dahulu ke host internal tujuan khusus yang dapat "membersihkan" permintaan, memeriksa kewarasannya, dan kemudian meneruskannya ke host back-end "asli". Karena Anda berbicara tentang interfacing ke aplikasi back-office Anda di IBM iSeries Anda, saya menduga Anda memiliki kemampuan terbatas untuk melakukan pemeriksaan kewarasan terhadap permintaan yang masuk pada iSeries itu sendiri.

Jika Anda mendekati ini dengan cara metodis dan menyimpan akal sehat tentang hal itu, tidak ada alasan Anda tidak bisa melakukan apa yang Anda gambarkan sambil meminimalkan risiko pada saat yang bersamaan.

Terus terang, bahwa Anda memiliki DMZ yang tidak memiliki akses tidak terkekang ke jaringan yang dilindungi menempatkan Anda dengan cepat melampaui banyak jaringan yang pernah saya lihat. Bagi sebagian orang, tampaknya, DMZ hanya berarti "antarmuka lain pada firewall, mungkin dengan beberapa alamat RFC 1918 yang berbeda, dan pada dasarnya akses tanpa batas ke Internet dan jaringan yang dilindungi". Cobalah dan jaga agar DMZ Anda terkunci semaksimal mungkin sambil tetap mencapai sasaran bisnis dan Anda akan melakukannya dengan baik.


Waaaay jawaban lebih teliti dari saya :) +1
Matius

Saya suka informasi ini. Sebelum saya bertanya, saya mengerti beberapa hal yang Anda bicarakan. Tapi banyak hal yang tidak saya pahami sepenuhnya. Terima kasih!
Mike Wills

Itu tergantung pada apa yang Anda maksud dengan pemeriksaan kewarasan. Dalam kasus seperti ini, kita akan menghindari SQL sebanyak mungkin (karena RPG dapat "membaca" database) dan memvalidasi data yang masuk sebelum memprosesnya. Juga, sebagian besar data yang dimasukkan ke dalam perangkat lunak back-office mungkin akan ditambahkan ke "kotak masuk" untuk ditangani oleh karyawan secara manual.
Mike Wills

6

Jelas ada beberapa bahaya, tetapi Anda bisa melakukannya. Pada dasarnya Anda membuka lubang kecil yang bisa dilalui seseorang, jadi buatlah kecil. Batasi hanya untuk server di kedua ujung, dan izinkan hanya data pada port yang dipilih. Bukan ide yang buruk untuk menggunakan terjemahan alamat port hanya menggunakan port aneh. Namun, keamanan karena ketidakjelasan bukanlah keamanan sama sekali. Pastikan bahwa apa pun server di sisi lain memiliki semacam cara untuk memeriksa bahwa informasi yang melalui koneksi itu benar-benar seperti yang terlihat ... atau setidaknya memiliki semacam konteks firewall sadar di tempat. Juga, ada firewall tertentu yang dibuat untuk hal semacam ini ... Saya tahu microsoft ISA melakukan hal yang sama untuk OWA dan server Exchange.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.