Pages:
Author

Topic: btcex.com: биржа BTC <-> RUB - page 2. (Read 37342 times)

sr. member
Activity: 868
Merit: 251
February 03, 2011, 09:46:59 PM
Да какой же идиот даёт рутовый доступ веб-порталу?
Какие буквы в словосочетании "несанкционированно порутили" вам не ясны?
Я на подобные вещи обычно отвечаю - порутайте-ка мой сервак.
Обычно после скана и нескольких попыток применить сплойт разговор или заканчивается, или переходит в троллинг и срач за неимением аргументов.
legendary
Activity: 1386
Merit: 1000
February 03, 2011, 09:44:48 PM
Да какой же идиот даёт рутовый доступ веб-порталу?

Какие буквы в словосочетании "несанкционированно порутили" вам не ясны?

между серверами у меня единая БД юзеров и прав. Зачем мне какие-то там прокидывания, если я могу вызвать функцию из специальной библиотеки и получить всё, что нужно?

Затем, что у хакера есть сниффер и рутовый доступ и он тоже может вызвать функцию из специальной библиотеки.
sr. member
Activity: 868
Merit: 251
February 03, 2011, 09:43:31 PM
Что-то я не совсем понял, где взялись бы данные пользователя без доступа к БД в случае с кербкросом.
я не понял, что неясно.
Пользовательские данные в случае биллинга содержат журнальные записи из БД. Если у веб-приложения нет связи с базой, где взять логи?

И у вас действительно не было требований по интеграции с другими серверами
Что вы тогда подразумеваете под "другими серверами"?

Пример:
web-фронт-энт (огромный портал) коннектиться к аналитическому серверу или серверу подготовки отчетов. Сервер подготовки отчетов коннектится к БД.

В случае с Kerberos - прокидываем аккаунт пользователя и каждый сервер может разграничить доступ для этого пользователя. Чей пароль подобрали или комп захватили - тот ССЗБ.
ответственне пользователи - unaffected.

В случае Без Kerberos - хакер ломает сервер с порталом, получает рутовый доступ, получает возможность запустить свой код под аккаунтом портала, обращается к
аналитическому серверу и считывает секретную информацию ответственных пользователей.
Да какой же идиот даёт рутовый доступ веб-порталу?
И да, слово "трёхзвенка" или вообще multi-tier вам знакомо?
И ещё, между серверами у меня единая БД юзеров и прав. Зачем мне какие-то там прокидывания, если я могу вызвать функцию из специальной библиотеки и получить всё, что нужно?
legendary
Activity: 1386
Merit: 1000
February 03, 2011, 09:33:15 PM
Что-то я не совсем понял, где взялись бы данные пользователя без доступа к БД в случае с кербкросом.

я не понял, что неясно.

И у вас действительно не было требований по интеграции с другими серверами
Что вы тогда подразумеваете под "другими серверами"?

Пример:
web-фронт-энт (огромный портал) коннектиться к аналитическому серверу или серверу подготовки отчетов. Сервер подготовки отчетов коннектится к БД.

В случае с Kerberos - прокидываем аккаунт пользователя и каждый сервер может разграничить доступ для этого пользователя. Чей пароль подобрали или комп захватили - тот ССЗБ.
ответственне пользователи - unaffected.

В случае Без Kerberos - хакер ломает сервер с порталом, получает рутовый доступ, получает возможность запустить свой код под аккаунтом портала, обращается к
аналитическому серверу и считывает секретную информацию ответственных пользователей.
LZ
legendary
Activity: 1722
Merit: 1072
P2P Cryptocurrency
February 03, 2011, 09:33:04 PM
Если это еще какой-то более новый баг, то дайте ссылку на (неподтвержденную) информацию о нем
Собственно, пост на этом форуме и является такой информацией.
Полагаю, bitcoinex сформирует и опубликует детальное описание.
sr. member
Activity: 868
Merit: 251
February 03, 2011, 09:29:14 PM
LDAP не обеспечивает безопасной сквозной аутентификации (зашли на сервер, с него доступен другой сервер, потом третий и т.д.) и не умеет аутентифицировать на удалённом сервере используя локально воткнутую PKI-смарткарточку. (Админ пришёл на работу, воткнул карту в ридер и пошел на удалённый сервер настраивать. При всём желании пароль в такой схеме не украдёшь. Уйти с работы забыв карточку он тоже не сможет - дверь не откроется.)
До таких извратов в нашей деревне ещё не дошли.

А ещё чистый керберос совсем не использует ассиметричное шифрование, так что когда квантовые компьютеры нас поработят перейдём на керберос в масштабах планеты
Обалдеть. Всегда считал, что асимметричное шифрование надёжнее, чем симметричное.
legendary
Activity: 1386
Merit: 1000
February 03, 2011, 09:26:58 PM
Ещё раз:

https://www.bitcoin.org/smf/index.php?topic=1018.msg44139#msg44139
Биржа отключена в связи с багом (это про новый неподтверждённый баг) в новой версии Postgresql-сервера. Использование старой версии невозможно из-за обнаружения там опасной уязвимости. (это про CVE-2010-4015)

> это про новый неподтверждённый баг

Я спросил какой баг. Вы ответили, что  dsa-2157-1

вот этот баг в DSA:
http://www.debian.org/security/2011/dsa-2157

там говорится только про contrib modules, которых у меня нет

Если это еще какой-то более новый баг, то дайте ссылку на (неподтвержденную) информацию о нем
sr. member
Activity: 868
Merit: 251
February 03, 2011, 09:26:35 PM
Не расчитывали на взлом web-части. В этом случае ваша БД осталась бы незащищенной против коннекта под аккаунтом, под которым работает web-приложение и была бы скомпрометирована полностью. А в случае отсутствия такого аккаунта (при использовании kerberos он не нужен) были бы скомпрометированы только данные пользователя, под которым удалось залогинится изначально.
Что-то я не совсем понял, где взялись бы данные пользователя без доступа к БД в случае с кербкросом.

И у вас действительно не было требований по интеграции с другими серверами
Что вы тогда подразумеваете под "другими серверами"?
Я, как архитектор, систему сначала продумал целиком, только потом взялся за реализацию. Все её части и связи с внешним миром были реализованы единообразно. Поэтому мне не пришлось изобретать костылей для интеграции - всё было уже интегрировано by design. Wink
legendary
Activity: 1386
Merit: 1000
February 03, 2011, 09:14:59 PM
Что я делал не так?

Не расчитывали на взлом web-части. В этом случае ваша БД осталась бы незащищенной против коннекта под аккаунтом, под которым работает web-приложение и была бы скомпрометирована полностью. А в случае отсутствия такого аккаунта (при использовании kerberos он не нужен) были бы скомпрометированы только данные пользователя, под которым удалось залогинится изначально.

И у вас действительно не было требований по интеграции с другими серверами
sr. member
Activity: 350
Merit: 252
probiwon.com
February 03, 2011, 09:12:48 PM
Quote
Может, придумаете задачку, в которой без Kerberos-а никак, тогда я пойму, зачем он нужен?

Администрирование 100 компьютеров, разбросанных по офисам корпорации.

Чтобы обеспечить возможность конкретным пользователям быть админами на компах нужно научить эти компьютеры пониманию того что, скажем, юзер из группы admins - админ, плюс научить аутентифицировать юзеров, которые доступа к этим компьютерам ранее вообще не имели ни в каком виде. Вторую задачу решает kerberos.
Мне почему-то для этого всегда хватало NIS и LDAP.

LDAP не обеспечивает безопасной сквозной аутентификации (зашли на сервер, с него доступен другой сервер, потом третий и т.д.) и не умеет аутентифицировать на удалённом сервере используя локально воткнутую PKI-смарткарточку. (Админ пришёл на работу, воткнул карту в ридер и пошел на удалённый сервер настраивать. При всём желании пароль в такой схеме не украдёшь. Уйти с работы забыв карточку он тоже не сможет - дверь не откроется.)

А ещё чистый керберос совсем не использует ассиметричное шифрование, так что когда квантовые компьютеры нас поработят перейдём на керберос в масштабах планеты
sr. member
Activity: 868
Merit: 251
February 03, 2011, 09:09:02 PM
в частности, биллинговую систему.
значит это была плохо (недостаточно детально) засекьюренная система, либо не было требований по интеграции с другими серверами
Вот у меня были веб-сервера (для работы админов и юзеров), сервера БД (кластер) и сервера доступа (NAS). И всё между ними прекрасно ходило. Серьёзных дырок за годы эксплуатации обнаружено не было. Kerberos не использовался и не планировался. Что я делал не так?
sr. member
Activity: 350
Merit: 252
probiwon.com
February 03, 2011, 09:07:49 PM
Да другой же баг

Ну как же другой, когда написано CVE-2010-4015 ?

Ещё раз:

https://www.bitcoin.org/smf/index.php?topic=1018.msg44139#msg44139
Биржа отключена в связи с багом (это про новый неподтверждённый баг) в новой версии Postgresql-сервера. Использование старой версии невозможно из-за обнаружения там опасной уязвимости. (это про CVE-2010-4015)
sr. member
Activity: 868
Merit: 251
February 03, 2011, 09:06:01 PM
sr. member
Activity: 350
Merit: 252
probiwon.com
February 03, 2011, 08:57:30 PM
legendary
Activity: 1386
Merit: 1000
February 03, 2011, 08:55:38 PM
объясните простому архитектору

Выше уже bitcoinex объяснял. Внешние пользователи идут через https. Можно каждому пользователю - сертификат. Дальше внешние пользователи меппятся на внутренние аккаунты.
приходят пользователи на один логический сервер, тот логический сервер может обращаться к другим логическим серверам, запрашивая различные сервисы. Обращаться он может либо имперсонировавшись пользователем, либо из под специального аккаунта. Во втором случае нельзя настроить права на внутренних серверах так же детально как в первом.

в частности, биллинговую систему.

значит это была плохо (недостаточно детально) засекьюренная система, либо не было требований по интеграции с другими серверами
sr. member
Activity: 868
Merit: 251
February 03, 2011, 08:51:24 PM
у вас какие-то заморочки, слабо понятные простому админу и программеру.
Непонятки простых программеров шерифов-архитекторов не интересуют.
Ну хорошо, объясните простому архитектору, негогда разработавшему, в частности, биллинговую систему.
legendary
Activity: 1386
Merit: 1000
February 03, 2011, 08:48:57 PM
Да другой же баг

Ну как же другой, когда написано CVE-2010-4015 ?
legendary
Activity: 1386
Merit: 1000
February 03, 2011, 08:47:32 PM
у вас какие-то заморочки, слабо понятные простому админу и программеру.

Непонятки простых программеров - аналитиков и архитекторов не интересуют.
sr. member
Activity: 350
Merit: 252
probiwon.com
February 03, 2011, 08:46:46 PM
Потому что я думаю что он привнесён с новой версией а я его первооткрыватель.

Тогда описание  на http://www.postgresql.org/support/security некорректно.
там написано, что этот баг fixed in 9.0.3

Да другой же баг, он ещё даже не воспроизведён никем пока что.
legendary
Activity: 1386
Merit: 1000
February 03, 2011, 08:43:49 PM
Потому что я думаю что он привнесён с новой версией а я его первооткрыватель.

Тогда описание  на http://www.postgresql.org/support/security некорректно.
там написано, что этот баг fixed in 9.0.3

Тем более, что там написано, что этот баг из Contrib Modules,
Contrib modules are not installed by default when PostgreSQL is installed from source.

а у меня гента.
Pages:
Jump to: