Наскільки велика проблема пробити дірку в DMZ на одному веб-сервері?


15

В даний час ми маємо наш веб-сервер у DMZ. Веб-сервер не може бачити нічого у внутрішній мережі, але внутрішня мережа може бачити веб-сервер. Наскільки безпечним було б пробити дірку в брандмауері між DMZ та внутрішньою мережею лише на одному веб-сервері в інтрамережі? Ми працюємо над тим, що буде взаємодіяти з декількома нашими бек-офісними додатками (які всі знаходяться на одному сервері), і зробити цей проект було б набагато простіше, якби ми могли спілкуватися безпосередньо з сервером IBM i, що зберігає ці дані ( через веб-сервіси).

З мого розуміння (і я не знаю торгових марок), у нас є один брандмауер для DMZ з іншим зовнішнім IP-адресом від нашого основного IP-адреси з іншим брандмауером. Ще один брандмауер знаходиться між веб-сервером та інтранет.

Тож щось на кшталт:

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

Як щодо деяких деталей, таких як, який брандмауер надає цей DMZ?
SpacemanSpiff

@SpacemanSpiff Я постарався з мінімальних знань про мережу. Я розробник, який планує наступний проект і придумує варіанти.
Майк Уіллс

Відповіді:


25

Немає нічого поганого в створенні механізмів доступу для хостів у DMZ для доступу до хостів у захищеній мережі, коли це необхідно для досягнення наміченого результату. Можливо, це не бажано робити, але іноді це єдиний спосіб зробити роботу.

Ключові речі, які слід враховувати:

  • Обмежте доступ до найбільш конкретного правила брандмауера. Якщо можливо, назвіть конкретні хости, що беруть участь у правилі, разом із конкретними протоколами (порти TCP та / або UDP), які будуть використовуватися. В основному, відкрийте лише стільки отворів, скільки вам потрібно.

  • Будьте впевнені, що ви реєструєте доступ від хоста DMZ до хосту в захищеній мережі та, якщо можливо, аналізуйте ці журнали автоматизованим способом на предмет аномалій. Ви хочете знати, коли трапляється щось незвичне.

  • Визнайте, що ви відкриваєте внутрішнього хоста, навіть якщо це побічно, в Інтернеті. Будьте в курсі виправлень та оновлень для програмного забезпечення, яке ви відкриваєте, та самого програмного забезпечення операційної системи хоста.

  • Подумайте про взаємну автентифікацію між хостом DMZ та внутрішнім хостом, якщо це можливо з вашою архітектурою додатків. Було б добре знати, що запити, що надходять до внутрішнього хоста, насправді надходять від хоста DMZ. Ви можете це зробити чи ні, буде сильно залежати від вашої архітектури додатків. Також майте на увазі, що хтось, хто "володіє" хостом DMZ, зможе надсилати запити до внутрішнього хоста, навіть якщо відбувається аутентифікація (оскільки вони фактично будуть хостом DMZ).

  • Якщо виникає занепокоєння щодо DoS-атак, розгляньте можливість обмеження швидкості, щоб хост DMZ не вичерпав ресурси внутрішнього хоста.

  • Ви можете розглянути можливість використання підходу "брандмауера" рівня 7, коли запити від хоста DMZ передаються спочатку внутрішньому хосту спеціального призначення, який може "санітувати" запити, перевірити їх, а потім передати їх "справжній" бек-енд-хост. Оскільки ви говорите про взаємодію зі своїми позаштатними програмами на своїх iSeries IBM, я здогадуюсь, що у вас є обмежена спроможність здійснювати перевірку правильності щодо вхідних запитів у самій iSeries.

Якщо ви підходите до цього методологічно і дотримуєтесь здорового глузду щодо цього, немає ніяких причин ви не можете робити те, що ви описуєте, зберігаючи при цьому ризик мінімізованим.

Відверто кажучи, у вас DMZ, який не має безперешкодного доступу до захищеної мережі, робить вас стрибками та межею за межі багатьох мереж, які я бачив. Для деяких людей, здається, DMZ просто означає "інший інтерфейс на брандмауері, можливо, з деякими різними адресами RFC 1918, і в основному безперебійний доступ до Інтернету та захищеної мережі". Спробуйте зберегти свій DMZ максимально зафіксованим, поки ви ще досягаєте бізнес-цілей, і ви будете робити добре.


Вааая більш ретельна відповідь, ніж моя :) +1
Метью

Я люблю цю інформацію. Перш ніж запитати, я зрозумів деякі речі, про які ти говорив. Але багато цього я не повністю зрозумів. Спасибі!
Майк Уіллс

Це залежить від того, що ви маєте на увазі під сумнівом перевірок. У такому випадку ми уникатимемо якомога більше SQL (оскільки RPG може "читати" бази даних) та перевіряти дані, що надходять до їх обробки. Крім того, більшість даних, що вводяться в бек-офісне програмне забезпечення, ймовірно, будуть додані до папки "Вхідні", щоб співробітники мали справу з вручну.
Майк Уіллс

6

Очевидно є деякі небезпеки, але ви можете це зробити. В основному ви відкриваєте щілину, через яку хтось може пройти, тому зробіть її крихітною. Обмежте його лише на серверах на обох кінцях, а дозвольте лише дані про обрані порти. Не погана ідея використовувати переклад адрес портів, щоб просто використовувати химерні порти. І все-таки безпека через незрозумілість - це взагалі не безпека. Переконайтеся, що незалежно від того, на якому сервері знаходиться інша сторона, є якийсь спосіб перевірити, чи інформація, яка проходить через це з'єднання, є справді такою, якою вона здається ... або, принаймні, має якийсь брандмауер, що обізнаний з контекстом. Крім того, існують певні брандмауери для подібних речей ... Я знаю, що Microsoft MSA робить це те ж саме для серверів OWA та Exchange.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.