Здравствуйте, Слава, Вы писали:

GIV>>Я вообще то про другое спрашивал но раз уж ты затронул эту тему расскажи как dmz не позволит шару создать на веб сервере.

С>Шару-то создадут. Но поскольку веб-сервер будет за внешним файрволлом(не на самом сервере), который разрешает обращение к серверу снаружи только по портам 80 и 443, то шара не будет доступна снаружи.

Ты путаешь DMZ и фаервол. Внешний фаервол есть в любом случае, безотносительно наличия DMZ и именно он оганичивает доступ по портам.

Здравствуйте, wildwind, Вы писали:

GIV>>И как DMZ поможет против sql injection?

W>Ты прикидываешься или на самом деле? Если нет доступа по сети, как ты будешь эксплуатировать sql injection? Во внутренней сети может быть десяток серверов с десятком сервисов на каждом. Sql injection может быть в любом из них.

ок, уговорили, DMZ помогает против SQL injection...

Здравствуйте, GarryIV, Вы писали:

GIV>Ты путаешь DMZ и фаервол. Внешний фаервол есть в любом случае, безотносительно наличия DMZ и именно он оганичивает доступ по портам.

Нет, не путаю. Просто оно идёт в комплексе, как например у защищенного SIP имеется SIP over TLS + SRTP, можно и по частям делать, но нет в этом смысла.

Здравствуйте, Stalker., Вы писали:

S>мой вопрос изначально касался аппсервера с бизнес логикой, не сервера базы данных.

Мой пример всего лишь один из примеров.

S> Каким образом выставив аппсервер наружу можно слить всю базу?

Разным. Понимаешь, infosec это не школьная математика, где все теоремы доказаны и все особые случаи давно рассмотрены в учебниках.
Например, аппсервер обычно подключается к базе от имени пользователя с весьма широкими правами, часто даже полными. А пароль этого пользователя часто лежит рядом, в конфиге. Подключился и сливай что хочешь. Или удаляй.

S>Ну хакнут аппсервер, получат доступ к методам бизнес-логики. Уровень взлома будет примерно таким-же, как и хакнутый веб сервер. В чем разница-то?

Совсем не таким же. На аппсервере можно выполнять действия с любыми аккаунтами, заметать следы и т.д.
С другой стороны, взломав веб-сервер, можно заняться фишингом. Везде свои угрозы.

Если вернуться к исходному вопросу, то смысл DMZ не в том, чтобы защитить конкретно аппсервер или сервер БД. А в том, чтобы изолировать всю внутреннюю сеть, защитить ее от проникновения через хосты в DMZ, которые определенно могут быть скомпрометированы.

Здравствуйте, Слава, Вы писали:

GIV>>Ты путаешь DMZ и фаервол. Внешний фаервол есть в любом случае, безотносительно наличия DMZ и именно он оганичивает доступ по портам.

С>Нет, не путаю. Просто оно идёт в комплексе, как например у защищенного SIP имеется SIP over TLS + SRTP, можно и по частям делать, но нет в этом смысла.

Понял, фаервол без ДМЗ безсмысленен, я много нового узнал сегодня.

Здравствуйте, Stalker., Вы писали:

S>Предположим есть стандартная схема системы — общедоступный вебсайт, который в своем коде не имеет никакой логики и для доступа к бизнес-логике обращается к application серверу (скажем через WCF) спрятанному в локальной сети. Т.е. вроде как аппликейшн сервер находится в безопасности (как и база данных) в локальной сети и его типа не взломать.
S>Однако чем конкретно это безопаснее? Ведь если взломан пользовательский аккаунт на общедоступном сайте мы-ж все равно транзитивно получили доступ к бизнес-логике и сможем совершить какие-то действия с ним.

Если все сделано "по уму" — взламывать веб-сервер затея бессмысленная и (почти) бесполезная
— логики там практически 0 — распарсить/минимально отвалидировать запрос/куки, отправить его практически как есть на app server, получить его ответ и отрендерить его в HTML
— это отдельная VM, которых 3 и больше (обычно намного), работающая в режиме read-only (даже логи "пишутся" в сокет а не в FS) и рестартующая как регулярно так и вообще по каждому чиху — реальный пример: "забыли" выставить разные лимиты по пейджнгу для разных типов пользователей — рендер для обычного пользователя "взорвется по памяти" на тысячах записей и соотв копия веб-сервера будет прибита и перезапущена, а рендер site-map спокойно переварит и 100k
— взломав пользовательский аккаунт намного проще использовать штатный веб-интерфейс, чем подделывать/перехватывать все необходимые ID пользователя, сессии, и подписи для "особо-критических" обращений к app server-у
— даже возможность RCE на случайном веб-сервере не даст злоумышленнику никакого преимущества в сравнении с "если взломан пользовательский аккаунт"

S>Яркий пример — интернет-банкинг, я больше чем уверен что база данных с сервером бизнес логики в банках запрятана весьма глубоко, однако что-бы пользователь смог что-то делать со своим аккаунтом цепочка от веб браузера до базы данных должна все равно существовать.
S>Вопрос можно сформулировать более прямо, вот есть скажем метод MakePayment() в WCF или WebAPI апп сервере. Какую именно пользу мы получаем спрятав его в локальную сеть а не выставив наружу в интернет?

В отличии от общедоступного веб-интерфейса (веб сервера) — "web API" (app server)
— намного проще заДДОС-сить сравнительно небольшим количеством запросов
— отреверсить/найти ошибки позволяющие создавать проблеммы всем пользователям, "ронять" весь сервер в целом и т.д.
— в конце-концов веб-сервер "не жалко" — ресурсов почти не использует, автоматически мониторить и рестартовать значительно проще, рестартует считанные секунды и совершенно прозрачно для пользователей, самое худшее что с ним может случиться — временный дефейс одного из его инстанцов, который заметит только часть пользователей
— app sever же вещь намного более тяжеловесная, возможность "прозрачного" рестарта требует дополнительных усилий/программирования, сам рестарт тоже процесс небыстрый

По большому счету DMZ — дополнительный барьер на пути к гораздо-более уязвимому app-server-у и упрощение разработки app server.

Здравствуйте, Candle, Вы писали:

C>В отличии от общедоступного веб-интерфейса (веб сервера) — "web API" (app server)
C> — намного проще заДДОС-сить сравнительно небольшим количеством запросов
C> — отреверсить/найти ошибки позволяющие создавать проблеммы всем пользователям, "ронять" весь сервер в целом и т.д.
C> — в конце-концов веб-сервер "не жалко" — ресурсов почти не использует, автоматически мониторить и рестартовать значительно проще, рестартует считанные секунды и совершенно прозрачно для пользователей, самое худшее что с ним может случиться — временный дефейс одного из его инстанцов, который заметит только часть пользователей
C> — app sever же вещь намного более тяжеловесная, возможность "прозрачного" рестарта требует дополнительных усилий/программирования, сам рестарт тоже процесс небыстрый

C>По большому счету DMZ — дополнительный барьер на пути к гораздо-более уязвимому app-server-у и упрощение разработки app server.

так ведь аппсервер — это тоже вебсервер. Вот возьмем все тот-же MakePayment() пример. Вот есть у нас на вебформе кнопка Платеж. Она вызывает метод MakePayment_Click() на вебсервере, который просто перенаправляет полученное DTO в метод POST /payment {json body} на WebAPI внутри ДМЗ.
1) ДОС атаки — почему ДМЗ здесь поможет? Если пришло 1000 запросов — они просто перенаправились в аппсервер и он так-же также упадет как и без ДМЗ. Максимум что вебсервер сделает — автоматически отсечет невалидные запросы (обязательные поля или тип данных), но нет-же никаких проблем досить валидными запросами.
2) Найти какие-то ошибки в бизнес-логике — опять-же как нам тут ДМЗ помогло-то? Ошибка точно также будет видна и через вебсайт, он-же просто передаст ответ от аппсервера хакеру
3) Непонятно почему есть какие-то проблемы с рестартом, и вебсервер и аппсервер оба хостяться на IIS и рестарт там вещь тривиальная

Вообще мой вопрос проистекает из такой ситуации, что для создания ДМЗ (физической или в облаке) потребуется написание таких-вот прокладок которые ничего по-сути не делают кроме перенаправления запроса внутрь ДМЗ. Тот-же платеж может совершатся как через вебформу так скажем и через телефон, и если в случае только вебформы нет никакой разницы где захостить аппсервер, то для телефона, которому нужен метод MakePayment() бизнес-логики придется создавать полную копию интерфейса которая смотрит в интернет и затем просто перенаправляет запросы внутрь ДМЗ настоящему аппсерверу. Как-то меня берут большие сомнения что системы делаются таким-вот образом

Здравствуйте, wildwind, Вы писали:

W>Разным. Понимаешь, infosec это не школьная математика, где все теоремы доказаны и все особые случаи давно рассмотрены в учебниках.
W>Например, аппсервер обычно подключается к базе от имени пользователя с весьма широкими правами, часто даже полными. А пароль этого пользователя часто лежит рядом, в конфиге. Подключился и сливай что хочешь. Или удаляй.
W>Совсем не таким же. На аппсервере можно выполнять действия с любыми аккаунтами, заметать следы и т.д.
W>С другой стороны, взломав веб-сервер, можно заняться фишингом. Везде свои угрозы.

W>Если вернуться к исходному вопросу, то смысл DMZ не в том, чтобы защитить конкретно аппсервер или сервер БД. А в том, чтобы изолировать всю внутреннюю сеть, защитить ее от проникновения через хосты в DMZ, которые определенно могут быть скомпрометированы.

если хакер запустил вирус на вебсервер способный захватить файловую систему с конфиг файлами, то что именно в ДМЗ остановит этот вирус от захвата теперь уже аппсервера с его конфиг файлами? Я как максимум вижу что здесь хакеру надо делать еще один шаг, это важно конечно и чем больше телодвижений надо сделать для захвата — тем выше безопасность, но непонятно насколько создание подобных прокладок реально усложняют захваты систем. Вот из разработку усложнят

Здравствуйте, Stalker., Вы писали:

S>Предположим есть стандартная схема системы — общедоступный вебсайт, который в своем коде не имеет никакой логики и для доступа к бизнес-логике обращается к application серверу (скажем через WCF) спрятанному в локальной сети.

Это уже дырявый DMZ. Т.е. вроде бы каменная стенка есть, но сбоку калитка и ключ под половичком, чтоб веб-сервер ходил. При компрометации веб-сервера, как внутренняя сеть сможет распознать: это запрос от веб-сервака или forged request?

Настоящий DMZ всегда однонаправленный: т.е. из внутренней сетки в него достучаться можно (скажем, для деплоя, бэкапов и т.п.), а из DMZ — доступа в локалку нет.

Здравствуйте, Stalker., Вы писали:

S>если хакер запустил вирус на вебсервер способный захватить файловую систему с конфиг файлами, то что именно в ДМЗ остановит этот вирус от захвата теперь уже аппсервера с его конфиг файлами?

То, что апсервер находится не в DMZ, а во внутренней сети (это мне КО подсказал). А из DMZ на нем доступен только порт приложения, принимающего запросы. Ты, может быть, представляешь себе, что у хакера, атакующего сеть, есть некий супер-мега-вирус, способный проникнуть на любой сервер через любой порт. На самом деле все эти "вирусы" нацелены на конкретное ПО конкретных версий. И если используемый веб-вервер хакеру скорее всего известен (из заголовков или по результатам сканирования из интернета), то какое ПО используется на аппсервере, нужно еще выяснить. Кроме того, при грамотном подходе к защите в сети работает IDS, которая анализирует трафик, проходящий через периметр, и сигнализирует о подозрительной активности.

S>Я как максимум вижу что здесь хакеру надо делать еще один шаг, это важно конечно и чем больше телодвижений надо сделать для захвата — тем выше безопасность, но непонятно насколько создание подобных прокладок реально усложняют захваты систем.

Именно так. Все меры в комплексе надежно отсекают хакеров из разряда "нажми на кнопку, получишь результат", узнавших вчера про Metasploit, а более серьезным ребятам сильно осложняют жизнь. Если интересно, почитай отчеты о пентестах, которые иногда публикуют. Весьма познавательно.

S>Вот из разработку усложнят

Разработку они усложняют при плохо организованном процессе. При правильно организованном разработчики отвечают за код, а за деплой и работоспособность боевого сервера отвечают админы.

Здравствуйте, Stalker., Вы писали:

S>Предположим есть стандартная схема системы — общедоступный вебсайт, который в своем коде не имеет никакой логики и для доступа к бизнес-логике обращается к application серверу (скажем через WCF) спрятанному в локальной сети. Т.е. вроде как аппликейшн сервер находится в безопасности (как и база данных) в локальной сети и его типа не взломать.
S>Однако чем конкретно это безопаснее? Ведь если взломан пользовательский аккаунт на общедоступном сайте мы-ж все равно транзитивно получили доступ к бизнес-логике и сможем совершить какие-то действия с ним.
S>Яркий пример — интернет-банкинг, я больше чем уверен что база данных с сервером бизнес логики в банках запрятана весьма глубоко, однако что-бы пользователь смог что-то делать со своим аккаунтом цепочка от веб браузера до базы данных должна все равно существовать.
S>Вопрос можно сформулировать более прямо, вот есть скажем метод MakePayment() в WCF или WebAPI апп сервере. Какую именно пользу мы получаем спрятав его в локальную сеть а не выставив наружу в интернет?

Дикий ветер написал же что сокращается attack surface. Но это неполный ответ.

На самом деле в DMZ разработчикам никто не дает ничего устанавливать или конфигурировать. DMZ физически отдельные люди саппортят и обновляют. А приложение/службы девелоперы как хотят, то и делают.

И безопасность не страдает и архитекторы ничем не ограничены. На пальцах примерно так.

Здравствуйте, wildwind, Вы писали:

W>Разработку они усложняют при плохо организованном процессе. При правильно организованном разработчики отвечают за код, а за деплой и работоспособность боевого сервера отвечают админы.

разработку это усложняет в том смысле, что при таком подходе для всех "смотрящих" в интернет сервисов надо создавать прокладки, просто принимающие запросы и перенаправляющие их внутрь к настоящим сервисам. Это стоит время и деньги. Поэтому я и пытаюсь выяснить насколько эти прокладки полезны. А то может действительно есть вирусы, которыми легко заразить общедоступный сайт, а потом начинать пинговать внутреннюю сеть
И кстати софт этих прокладок будет таким-же, как и у настоящих сервисов в ДМЗ, никто-ж не будет писать прокладку на web api, а потом вызывать какой-нибудь wcf в надежде запутать хакера.

Здравствуйте, Stalker., Вы писали:

S>Здравствуйте, wildwind, Вы писали:

W>>Разработку они усложняют при плохо организованном процессе. При правильно организованном разработчики отвечают за код, а за деплой и работоспособность боевого сервера отвечают админы.

S>разработку это усложняет в том смысле, что при таком подходе для всех "смотрящих" в интернет сервисов надо создавать прокладки, просто принимающие запросы и перенаправляющие их внутрь к настоящим сервисам.

Не знвю, из чего ты сделал такой вывод, но явно не из того, что написали в этой теме. Прокладка, просто принимающая и перенаправляющая запросы, называется прокси сервером. И создавать их не нужно, их полно готовых. А, к примеру, сервер реализующий веб интерфейс к системе, это просто один из слоев в многозвенной архитектуре. И выделяется этот слой в отдельный сервис далеко не только для того, чтобы "запутать хакера". А главным образом для эффективного масштабирования.

S>Это стоит время и деньги.

Безопасность стоит недешево, да. Тут ты Америку не открыл. Как и масштабируемость.