» » Продолжаем смотреть публичные камеры видео-наблюдения Москвы

 

Продолжаем смотреть публичные камеры видео-наблюдения Москвы

Автор: admin от 29-01-2015, 13:45, посмотрело: 3491

Дело было вечером, делать было нечего. Поводом послужила активность пользователя leider, который дал в комментарии ссылку на публичный ресурс: http://video.dit.mos.ru/window/

Продолжаем смотреть публичные камеры видео-наблюдения Москвы

Чем примечателен этот ресурс — он предоставляет публичный доступ к камерам видео-наблюдения через встроенный плеер.

Продолжаем смотреть публичные камеры видео-наблюдения Москвы

В данной статье не будет ни «соли», ни сахара, а только здоровые пища ссылки прямо из печки.

Список ссылок, которые использует плеер на том ресурсе:

http://videoproxy2.echd.ru:41025/rtsplive/10.200.21.21:2033/rtsp___10.208.1.18_axis_media_media.amp/live
http://videoproxy2.echd.ru:41025/rtsplive/10.200.21.22:2033/rtsp___10.208.1.186_axis_media_media.amp/live
http://videoproxy2.echd.ru:41025/rtsplive/10.200.21.22:2033/rtsp___10.208.0.50_axis_media_media.amp/live
http://videoproxy2.echd.ru:41025/rtsplive/10.200.21.22:2033/rtsp___10.208.41.134_axis_media_media.amp/live
http://videoproxy2.echd.ru:41025/rtsplive/10.200.21.23:2033/rtsp___10.194.23.9_axis_media_media.amp/live
http://videoproxy2.echd.ru:41025/rtsplive/10.200.30.24:2033/rtsp___10.208.14.78_axis_media_media.amp_camera_4/live
http://videoproxy2.echd.ru:41025/rtsplive/10.200.30.33:2033/rtsp___10.208.14.117_axis_media_media.amp_camera_2/live

http://videoproxy2.echd.ru:41025/rtsplive/10.200.26.150:2033/rtsp___10.232.0.121_live_h264/live
http://videoproxy2.echd.ru:41025/rtsplive/10.200.26.150:2033/rtsp___10.232.0.1_live_h264/live
http://videoproxy2.echd.ru:41025/rtsplive/10.200.26.153:2033/rtsp___10.232.0.113_live_h264/live

Включаем логику программиста "влоб!":

  • http://videoproxy2.echd.ru:41025/rtsplive — это прокси

  • 10.200.30.33:2033 — это кеширующий сервер

  • rtsp___10.208.14.117_axis_media_media.amp_camera_2/live — это ссылка на поток с камеры на сервере.



Рабочие ссылки:

  • http://videoproxy2.echd.ru:41025/rtsplive/10.200.21.21:2033/rtsp___10.208.1.18_axis_media_media.amp/live

  • http://videoproxy2.echd.ru:41025/rtsplive/10.200.21.21:2033/rtsp___10.208.1.18_axis_media_media.amp


Нерабочие ссылки:

  • http://videoproxy2.echd.ru:41025/rtsplive/10.200.21.21:2033/rtsp___10.208.1.18

  • http://videoproxy2.echd.ru:41025/rtsplive/10.208.1.18:80

  • http://videoproxy2.echd.ru:41025/rtsplive/10.208.1.18:81

  • http://videoproxy2.echd.ru:41025/rtsplive/10.208.1.18:8080

  • http://videoproxy2.echd.ru:41025/rtsplive/10.208.1.18:8081

  • http://videoproxy2.echd.ru:41025/rtsplive/10.208.1.18:[пачка_rtsp_портов из wiki, так же 7020 и 27020]



Автоматизация поиска


Теория:

  • прокся только одна (videoproxy2.echd.ru:41025/rtsplive/)

  • порт кеширующих серверов неизменен (:2033)

  • хвостик _axis_media_media.amp/live

  • хвостик _live_h264/live


Далее, _camera_4 и т.д. не учитывается, так как  существует «10.200.30.24:2033/rtsp___10.208.14.78_axis_media_media.amp_camera_4/live» и не существует «10.200.30.24:2033/rtsp___10.208.14.77_axis_media_media.amp_camera_3/live», но следуя логике должна быть обязательно "_axis_media_media.amp/live" — вот их-то и будем искать.

Список IP для кеширующих серверов:

  • 10.200.21.21

  • 10.200.21.22

  • 10.200.21.23

  • 10.200.30.24

  • 10.200.30.33

  • 10.200.26.150

  • 10.200.26.153


В идеале как диапазон надо бы выбрать 10.200.21.1--10.200.30.254.

Список IP адресов для камер:

  • 10.194.1.7

  • 10.194.23.9

  • 10.208.0.50

  • 10.208.1.186

  • 10.208.14.117

  • 10.208.41.134

  • 10.232.0.113

  • 10.232.0.121


Как диапазон (опять же идеальный) берем адреса 10.194.0.1--10.232.255.254 за исключением 10.200.*.* , так как по моей логике (как бы сделал я) — это кеширующие сервера.

В итоге вырисовывается вот такой шаблон для запросов:

  • http://videoproxy2.echd.ru:41025/rtsplive/10.200.ip13.ip14:2033/rtsp___10.ip22.ip23.ip24_axis_media_media.amp/live

  • http://videoproxy2.echd.ru:41025/rtsplive/10.200.ip13.ip14:2033/rtsp___10.ip22.ip23.ip24_live_h264/live




  • ip13 — 21..30

  • ip14 — 0..254

  • ip22 — 194..232

  • ip23 — 0..255

  • ip24 — 1..254


Получаем: 5 миллиардов адресов и запросов… В реальности запросов много меньше и мы к тому же можем экономить 903k запросов за 10-15 секунд простоя скрипта… (об этом ниже).

Успех:

  • В случае успеха сервер нам возвращает в Content-type x-flv или обратное условие НЕ text;

  • В случае успеха сервер отвечает за 1-3 секунды.


Неудача:

  • Сервер отвечает за 200-400мс с text в Content-type;

  • Сервер долго думает, если послали запрос к «несуществующему» кеш-серверу, в этом случае надо остановить парсинг по этому серверу и перескочить на IP «выше».


Чтобы минимизировать время парсинга задаем timeout на соединение равный 10000 мс, следом перед запросом и после запроса (когда сервер ответил или сработал timeout на нашем клиенте) сохраняем значение времени. Далее из второго вычитаем первое и если прошло 9500мс или более, то переходит на 1 IP выше (для кеширующего сервера), что дает нам упомянутую выше экономию 903 224 запросов или 104 дня ожидания по 10 секунд!

Так же надо понимать, что ссылки на камеры бегут по кругу, и как заметили в предыдущей статье — камер около 140 000. Сервер спокойно отдает 10 запросов в секунду, так что если мы уже нашли 140 000 камер, то в будущем нам искать их повторно не нужно.

Но парсинг такого количество адресов займет целую вечность, а мы пока не в матрице!


Практика


Сокращаем круг поисков:

  • 10.200.21.21-24, камеры 10.[194, 208, 232].0-255.1-254

  • 10.200.30.21-34, камеры 10.[194, 208, 232].0-255.1-254

  • 10.200.26.150-153, камеры 10.232.0-255.1-254


Их прокся спокойно обрабатывает ~10 запросов на 1 поток, пробуем… 8 потоков, 16 потоков… хватит и 16. Итого ~160 ссылок в секунду и поток на уровне 2-3 мегабит, что не нагружает сеть.

Ответ от сервера:

video/x-flv — это если мы получили поток с камеры через их сервер, text/html — если сообщение об ошибке. В программе надо делать условие не нахождения x-flv, а отсутствия text. Потому, что если камера лежит, то сервер просто тупит и мы ничего не получаем, но камера-то есть.

В результате было найдено 608 камер:



































IP.21.23.21.22.21.21.26.150.26.151.30.21.26.152.30.24.26.153.30.23.30.25.21.24.30.22
число193176171311074433321


  • 540 камер _axis_media_media.amp/live

  • 68 камер _live_h264/live




Уведомления:

  • 27 января в полдень было отправлено письмо на [email protected], час спустя личка leider чтобы посмотрели почту. В письме было описано что и как работает.

  • 28 января так же в полдень — новое письмо на [email protected], где упомянул, что уже писал на [email protected] и что ответа так и не последовало (в каждом письме было указано, что жду новостей)


«Новости»:

  • Ссылка на камеру, приведенная в примере была закрыта еще 27 числа… тихо и молча.


Надеюсь, что после этой публикации они введут проверку на videoproxy2, чтобы он выдавал только камеры из проекта «окна». Для прочих камер/всех камер можно поднять blablaproxy2, который нигде не светить и который будет работать по https.

Ссылки по теме:

Страница с плеерами || дамп в формате mysql (описание полей в комментариях).

Источник: Хабрахабр

Категория: Информационная безопасность

Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

Добавление комментария

Имя:*
E-Mail:
Комментарий:
Полужирный Наклонный текст Подчеркнутый текст Зачеркнутый текст | Выравнивание по левому краю По центру Выравнивание по правому краю | Вставка смайликов Выбор цвета | Скрытый текст Вставка цитаты Преобразовать выбранный текст из транслитерации в кириллицу Вставка спойлера
Введите два слова, показанных на изображении: *