Уязвимости СКУД

[kROOT]

Поменял работу и теперь в мои обязанности вошла работа со СКУДом, соответственно заинтересовался и нашел интересную статью.
Настоятельно рекомендую прочитать, но если коротко, то на многих системах на базу данных стоит дефолтный пароль, через который можно зайти и добавить юзеров, изменить права оператора, откорректировать время прохода и т.д.
и 2я основная уязвимость это то, что сетевые клиенты СКУД общаются не с сервером СКУД, а с БД и соответственно права в системе контролирует не система, а локально установленная программа, которая определяет свой функционал по записям в БД.
Резюмируя, ставить систему только в изолированной сети.

[google]

[greenkpz]

Поздравляю со сменой работы!
проблема НЕдефолтного пароля банальна - его прое... забудут, потеряют и т.д. и т.п.
через пару тройку лет на том же объекте придется все сносить к чертям и делать заново...
особо жестоко получается когда объект делал не ты, а хз кто и данные "переданы заказчику" т.е. см. выше.
статья ересь и мракобесие айтишника как и сам хабр/гик - посмотрите их статьи по видео.
пункт 1. сервер скуд не торчит в инете/корп сети - далее статья не имеет смысла. все.

[GenaSPB]

Проблема актуальна для СКУД которые изначально криво сделаны где клиенты работают на прямую с базой. В системах где база работает локально и все клиенты обращаются к базе через серверную часть. проблема не столько актуальна.

[kROOT]

Проблема актуальна для СКУД которые изначально криво сделаны где клиенты работают на прямую с базой. В системах где база работает локально и все клиенты обращаются к базе через серверную часть. проблема не столько актуальна.

это понятно дело, особенно если трафик шифруется, но там есть пример, где система общается через телнет и передает по запросу пароли.
но самые распостраненные работают через базу.
Типичное решение - бюро пропусков/кадры в одном месте, сервер в другом. под пропуска ставить отдельный комп?

[kROOT]

Поздравляю со сменой работы!
проблема НЕдефолтного пароля банальна - его прое... забудут, потеряют и т.д. и т.п.
через пару тройку лет на том же объекте придется все сносить к чертям и делать заново...
особо жестоко получается когда объект делал не ты, а хз кто и данные "переданы заказчику" т.е. см. выше.
статья ересь и мракобесие айтишника как и сам хабр/гик - посмотрите их статьи по видео.
пункт 1. сервер скуд не торчит в инете/корп сети - далее статья не имеет смысла. все.

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

[Sergiodemaster]

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

Работать от суперюзера - дыра в безопасности что в БД, что где то еще. Если софт не позволяет сменить юзера - это серьезный баг, такую дыру надо закрывать.

и 2я основная уязвимость это то, что сетевые клиенты СКУД общаются не с сервером СКУД, а с БД и соответственно права в системе контролирует не система, а локально установленная программа, которая определяет свой функционал по записям в БД.

БД в любом случае используется сторонняя. Какая разница, кто будет дергать JDBC коннектор - локально установленная программа или удаленный клиент?
Нормальный софт должен накрывать соединения либо ssl, либо через ssh.
Если он использует открытый http запрос и без туннеля с ssh - то это крайне дырявый софт.

Резюмируя, ставить систему только в изолированной сети.

Любая система безопасности должна работать в изолированном сегмент. Валить всё в общий влан - необдуманно.

З.Ы. С почином в деле информационной и комплексной безопасности!

[GenaSPB]

Типичное решение - бюро пропусков/кадры в одном месте, сервер в другом. под пропуска ставить отдельный комп?

Да, и только так. Ну или как минимум сервер у кадров, а в бюро пропусков комп. Но ненаоборот это точно.

[ALEX_SE]

По этой теме и статье которая пубьликовалась на Мосту было относительно большое обсуждение там же.

А проблемы инфобезопасности присущи системам безопасности всем - и скуду и видео и ОПС.... Не думают там об этом. Вовсе. Те же проблемы были и у многих систем автоматизации бухгалтерского учета, например. Взять ту же 1С где средств нормальных ограничения доступа до 8 версии не было в принципе.

Что до работы через сервер/напрямки с базой есть и плюсы и минусы у такого решения.