информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Где водятся OGRыСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Microsoft предупредила о двух незакрытых... 
 Перевод Firefox на DNS over HTTPS 
 Microsoft закрыла серьёзную уязвимость,... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / theory
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
С одной стороны централизованная или распределенная система... 23.04.08 15:08  Число просмотров: 5992
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 23.04.08 15:16  Количество правок: 3
<"чистая" ссылка>
> , причём практически неконтролируемо (никто же не мешает
> его предварительно отключить), а если чувак ещё и
> альтруист, то update main set "Количество оставшихся
> проходов"=65535, выполненное на очень ограниченном (!, по
> сравнению с нынешней системой) количестве носителей
> информации вызовет коллапс всей(!) системы получения
> прибыли метрополитена.

С одной стороны централизованная или распределенная система в определенной степени менее устойчива к атакам инсайдеров. Я вообще то говорил, рассматривая именно "удаленную систему". Ее можно сделать устойчивой, поскольку даже не со стороны билетосчитывателей, но и со стороны сети он опять же может быть таковой. Для начала разумеется надо предусмотреть исключение возможности удаленного изменения программного обеспечения. Это даже не обсуждается (может и перпрошивку со стороны считывателей предусмотреть :-). Поле "Количество оставшихся проходов" сузить до байта, а в добавок ко всему предусмотреть контроль валидности данных (по ночам). Например контроль этого поля на максимальное значение (60-70), контроль срока действия билета (квартал, например). Сверку базы с центральным сервером (если что не так - пищать, орать, в логи писать что да как и почему). Обмен данными - звезда с центральным серваком. Ему посылается инфа о продаже новых билетов, о проходах и с него берется инфа о проходах на других станциях. Репликации можно защищать электронной подписью. В репликациях только инфа что номер билета такой-то - совершен проход. Даже дату и время не обязательно, пусть на других станциях старая остается. Если на серваке одной из станций и умудриться прописать 65535/255/70, то это изменение не попадет на другие и будет актуально до ночи. Сервак на станции не должен уметь выполнять никаких sql запросов по массовой модификации данных типа "обновить поле количество оставшихся проходов для всех записей на 70".
Короче, если что не так и в логах появится, что какой-то билет был продан на 255 проходов - сразу разбираться, какой кассир и во сколько продал, кто имел доступ к серваку в это время и т.п. Кривую транзакцию (пакет) о том, что кто-то где-то продал билет на дофига поездок вычислить легко на главном серваке. Контроль опять же по сумме бабла, полученого кассиром и сколько и каких он билетов продал опять же по репликам, которые прошли через главный сервак.

> В данной реализации сотня[лана, тыща, десять]-другая
> товарищей, за которыми в добавок бегает батальон ментов,

И не надо ни за кем бегать будет.
<theory> Поиск 








Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2020 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach