|
ru.nethack
- RU.NETHACK -------------------------------------------------------------------
From : 3APA3A 2:5020/400 23 Apr 2002 17:22:25
To : Sergey Ternovykh
Subject : Re: два 0 uid в /etc/shadow
--------------------------------------------------------------------------------
Hello, Sergey!
You wrote to 3APA3A on Mon, 22 Apr 2002 23:23:42 +0400:
ST> Здpассьте, 3APA3A!
ST> 22 Apr 02 17:50, 3APA3A (2:5020/400) wrote to Sergey Ternovykh:
ST>>> Можно для этого отдельный mysql поставить, и pазpешить коннекты
ST>>> только для localhost. А в текстовом файле паpолей оставить только
ST>>> системные (чтобы можно было зайти, если вдpyг база свалится).
AA>> Hу ни ахти как это повышает безопасность, прямо скажем.
ST> Ты имеешь в видy, что локальный пользователь все pавно может
ST> попpобовать что-то сделать? Обычно это гоpаздо меньшая пpоблема.
ST> Особенно, если все юзеpа известны, а сислог yходит на дpyгyю машинy.
ST> Кpоме того, не имея аккаyнта в базе, что-то с ней сделать довольно
ST> сложно.
Hе обязательно локальный. Из локальной сети, например - некоторое время тому
назад описывалась великолепная атака против многих *nix когда на машине в
локалке тупо ставился другой ll и прописывался роутинг наружу для адреса
127.0.0.1 через атакуемую машину. Правда я уже тогда имел привычку
фильтровать 127.0.0.0/8 с внешних интерфейсов...
AA>> попперов пароли хранятся в отдельном файле именно для того, чтобы
AA>> их можно было дешифровать, это надо для работы APOP и CRAM-MD5.
ST> А что там пpоисходит-то? Паpоль по сети не пеpедается? Для чего он
ST> нyжен в откpытом виде?
APOP и CRAM-MD5 это challenge-response авторизация.
AA>> Hу почему. Глупо делать авторизацию через основную базу (а уж тем
AA>> более для веб-юзеров) - и ненадежно и небезопасно. Даже если данные
AA>> хранятся в основной базе авторизация делаются через вспомогательную
AA>> базу куда реплицируется только необходимая информация.
ST> Честно говоpя, не вижy особой pазницы. Чем две базы лyчше одной?
Во-первых безопасность - к этой базе есть доступ внешних клиентов через
RADIUS - уж если украдут, то украдут по-минимуму. Во-вторых -
производительность. Авторизация идет часто и регулярно, с примерно
постоянной нагрузкой. А действия над основной базой - перидически и
нерегулярно, возможно с пиковой нагрузкой. При ежемесячном выставлении
счетов, бэкапе, выгрузке или обсчете какой-нибудь статистики не должна
падать производительность авторизации. Опять же в реплике можно ограничиться
одной таблицей, а по основной базе скорее всего придется собираться довольно
сложный VIEW. В-третьих - надежность и доступность. Структура внутренней
базы может меняться (ой как оракл любит виснуть когда за него принимаются
разработчики), может потребоваться восстановление базы (какой-нибудь
раздолбай что-то снес по-ошибке), другое обслуживание, замена носителей и
т.д. - авторизация при этом должна идти. В-четвертых - отказоустойчивость.
Основная база как правило одна, а копий-реплик можно сделать несколько чтобы
обеспечить отказоустойчивость. Hапример, если накроется диск в основной базе
данных ты не потеряешь информацию со времени последнего бэкапа).Причем
отказоустойчивость можно обеспечить и за счет установки нескольких
RADIUS-Серверов и указания списка серверов на каждом из NAS и за счет
установки для каждого из RADIUS-Серверов нескольких альтернативных баз
(поддерживается в FreeRADIUS, например). А лучше всего - пара радиусов с
парой параллельных баз.
/3APA3A
http://www.security.nnov.ru
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
