Предположим есть стандартная схема системы — общедоступный вебсайт, который в своем коде не имеет никакой логики и для доступа к бизнес-логике обращается к application серверу (скажем через WCF) спрятанному в локальной сети. Т.е. вроде как аппликейшн сервер находится в безопасности (как и база данных) в локальной сети и его типа не взломать.
Однако чем конкретно это безопаснее? Ведь если взломан пользовательский аккаунт на общедоступном сайте мы-ж все равно транзитивно получили доступ к бизнес-логике и сможем совершить какие-то действия с ним.
Яркий пример — интернет-банкинг, я больше чем уверен что база данных с сервером бизнес логики в банках запрятана весьма глубоко, однако что-бы пользователь смог что-то делать со своим аккаунтом цепочка от веб браузера до базы данных должна все равно существовать.
Вопрос можно сформулировать более прямо, вот есть скажем метод MakePayment() в WCF или WebAPI апп сервере. Какую именно пользу мы получаем спрятав его в локальную сеть а не выставив наружу в интернет?
Здравствуйте, Stalker., Вы писали:
S>...Какую именно пользу мы получаем спрятав его в локальную сеть а не выставив наружу в интернет?
Когда вирусня зашифрует диск с базой данных, приходи расскажешь о пользе ДМЗ. Переустановить новую копию софта на веб сервере не так уж и сложно. С серверами БД все сильно сложнее.
Здравствуйте, BOBKA_XPEH, Вы писали:
BOB>Когда вирусня зашифрует диск с базой данных, приходи расскажешь о пользе ДМЗ. Переустановить новую копию софта на веб сервере не так уж и сложно. С серверами БД все сильно сложнее.
что вирусне мешает пробраться дальше к аппсерверу? Вебсервак заражен, он под контролем хакера. Чем локалка тут собирается помогать? Метод MakePayment() все равно виден хакеру и он сможет его вызвать
Здравствуйте, Stalker., Вы писали:
S>что вирусне мешает пробраться дальше к аппсерверу?
Фаервол.
S>...Вебсервак заражен, он под контролем хакера...
Вебсервер может подключаться к аппликейшен серверу или БД только по одному порту.
S>...Чем локалка тут собирается помогать? Метод MakePayment() все равно виден хакеру и он сможет его вызвать
Если приложение написано без дыр в безопасности вроде динамических скл запросов то хакеру будет бесполезена веб страница, максимум он может на ней какое-нибудь сообщение повесить. Если вы пишите программы с дырками, тогда ой... тут я не виноват.
Здравствуйте, BOBKA_XPEH, Вы писали:
BOB>Фаервол.
BOB>Вебсервер может подключаться к аппликейшен серверу или БД только по одному порту.
файервол есть и перед вебсайтом, там тоже открыт только один 80 порт. Тем не менее хакер его захватил так, что имеет возможность зашифровать мне диск. Отлично. Раз может зашифровать диск, то вызвать метод MakePayment() с аппсервера в локалке сможет и тем более!? Ведь вебсервер имеет права на вызов аппсервера
Здравствуйте, Stalker., Вы писали:
S>файервол есть и перед вебсайтом, там тоже открыт только один 80 порт. Тем не менее хакер его захватил так, что имеет возможность зашифровать мне диск. Отлично...
Почитай что ли книгу по сетевым технологиям. Если открыт только это порт то никто ничего сделать с сервером не сможет, ддос атаку только.
Здравствуйте, BOBKA_XPEH, Вы писали:
BOB>Почитай что ли книгу по сетевым технологиям. Если открыт только это порт то никто ничего сделать с сервером не сможет, ддос атаку только.
т.е. достаточно закрыть все порты, кроме 80, и никакие ДМЗ больше не нужны?
Здравствуйте, Stalker., Вы писали:
S>Предположим есть стандартная схема системы
Стандартная схема защиты, инженерный подход — это берем решето, да не одно, а штук пять, и пытаемся совместить их так, чтобы одна дырка не оказалась над другой и не образовала сквозного прохода. В этом смысл DMZ.
Если вести речь только о взломе через уязвимости, а не о DoS, то например Postgres вполне можно выставлять наружу в интернет, не опасаясь, что его взломают — потому что количество CVE для него в 10 раз меньше, чем для MySql. Потому что Postgres написан правильно и "академично", а не инженерно.
Здравствуйте, Stalker., Вы писали:
S>т.е. достаточно закрыть все порты, кроме 80, и никакие ДМЗ больше не нужны?
Зависит от того какое приложение обрабатывает запросы по этому порту и насколько оно толково написано. Например достаточно много приложений подвержены скл инжекшенс, хотя казалось бы написать приложение которое такой атаке не подвержено достаточно просто, но каждый разработчик считает себя пупом земли и не следует "глупым" гайдам всяких "стариков"...
Здравствуйте, Stalker., Вы писали:
S>Однако чем конкретно это безопаснее?
Тем, что значительно сокращается attack surface.
S>Ведь если взломан пользовательский аккаунт на общедоступном сайте мы-ж все равно транзитивно получили доступ к бизнес-логике и сможем совершить какие-то действия с ним.
Увести деньги с одного аккаунта или зайти по ssh/rdp/<еще какой-то дырявый сервис> и слить всю базу — есть разница?
Кроме того, если взломан пользовательский аккаунт, злоумышленнику даже нет необходимости проникать в DMZ.
Здравствуйте, Слава, Вы писали:
С>например Postgres вполне можно выставлять наружу в интернет, не опасаясь, что его взломают — потому что количество CVE для него в 10 раз меньше, чем для MySql. Потому что Postgres написан правильно и "академично", а не инженерно.
Здравствуйте, wildwind, Вы писали:
W>Нет, это потому, что его не выставляют.
Нет, не поэтому. MySql тоже не выставляют. "Выставленность" или нет какого-то сервиса совершенно не влияет на возможность искать в нем уязвимости локально, у себя — как и делают исследователи. Но вот вам результаты:
Здравствуйте, Слава, Вы писали:
W>>Нет, это потому, что его не выставляют. С>Нет, не поэтому. MySql тоже не выставляют.
Это сейчас уже не выставляют. А лет 5-10 назад выставляли еще как.
С>"Выставленность" или нет какого-то сервиса совершенно не влияет на возможность искать в нем уязвимости локально, у себя — как и делают исследователи.
Исследователи находят меньшую часть уязвимостей. Большую часть первыми находят более мотивированные товарищи. И "выставленность" сильно влияет на их мотивацию.
С>Но вот вам результаты: С>MySql: 244 уязвимости С>Postgresql: 95 уязвимостей
Примерно соответствует их распространенности. Не текущей, а за весь период, так сказать.
Здравствуйте, BOBKA_XPEH, Вы писали:
S>>т.е. достаточно закрыть все порты, кроме 80, и никакие ДМЗ больше не нужны?
BOB>Зависит от того какое приложение обрабатывает запросы по этому порту и насколько оно толково написано. Например достаточно много приложений подвержены скл инжекшенс, хотя казалось бы написать приложение которое такой атаке не подвержено достаточно просто, но каждый разработчик считает себя пупом земли и не следует "глупым" гайдам всяких "стариков"...
Здравствуйте, GarryIV, Вы писали:
GIV>И как DMZ поможет против sql injection?
DMZ поможет против того, что на веб-сервере случайно* открыли файловую шару для удобства разработчиков и для всего интернета.
*патаму что срочна! нада! ррряяяя!!!111одинодин, заказчик-директор, еще какой хрен недоволен, вякает, и вместо того, чтобы ему рот заткнуть — желательно петардой большой мощности, все бросаются исполнять
Здравствуйте, Слава, Вы писали:
GIV>>И как DMZ поможет против sql injection?
С>DMZ поможет против того, что на веб-сервере случайно* открыли файловую шару для удобства разработчиков и для всего интернета.
Я вообще то про другое спрашивал но раз уж ты затронул эту тему расскажи как dmz не позволит шару создать на веб сервере.
Здравствуйте, GarryIV, Вы писали:
GIV>И как DMZ поможет против sql injection?
Ты прикидываешься или на самом деле? Если нет доступа по сети, как ты будешь эксплуатировать sql injection? Во внутренней сети может быть десяток серверов с десятком сервисов на каждом. Sql injection может быть в любом из них.
Здравствуйте, GarryIV, Вы писали:
GIV>Я вообще то про другое спрашивал но раз уж ты затронул эту тему расскажи как dmz не позволит шару создать на веб сервере.
Шару-то создадут. Но поскольку веб-сервер будет за внешним файрволлом(не на самом сервере), который разрешает обращение к серверу снаружи только по портам 80 и 443, то шара не будет доступна снаружи.
Здравствуйте, wildwind, Вы писали:
W>Увести деньги с одного аккаунта или зайти по ssh/rdp/<еще какой-то дырявый сервис> и слить всю базу — есть разница? W>Кроме того, если взломан пользовательский аккаунт, злоумышленнику даже нет необходимости проникать в DMZ.
мой вопрос изначально касался аппсервера с бизнес логикой, не сервера базы данных. Каким образом выставив аппсервер наружу можно слить всю базу? Ну хакнут аппсервер, получат доступ к методам бизнес-логики. Уровень взлома будет примерно таким-же, как и хакнутый веб сервер. В чем разница-то?
Здравствуйте, Слава, Вы писали:
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>Это стоит время и деньги.
Безопасность стоит недешево, да. Тут ты Америку не открыл. Как и масштабируемость.
Переустановить новую копию софта на веб сервере не так уж и сложно. С серверами БД все сильно сложнее.
ок, уговорили, DMZ помогает против SQL injection...
