Во время быстрого развития ИТ среды, многие её активные участники пользуются готовыми решениями обеспечивающими их определённым функционалом, который хотелось бы расширить. Но расширение продукта зачастую является либо платным, либо чрезвычайно затратным действием, требующим постоянного контроля доступной кодовой базы, адаптацией и корректировкой своей части для совместимости. Приходится создавать продукты размещаемые "рядом" и различными способами производить интеграцию. Попробуем изменить это с помощью минимальных затрат и расширить функционал Gitlab получив практически "бесшовную" интеграцию со своими продуктами.
Многие компании выбирающие для себя средства хранения кода и «комбайны» организации процессов CI/CD останавливают свой выбор на Gitlab. С точки зрения небольших и больших организаций, функционала Gitlab вполне хватает, чтоб решать повседневные задачи разработки. Продукт хорошо документирован, имеет платные подписки с расширением функционала (множество доменов для аутентификации, полнотекстный поиск, системные хуки и прочее).
Как показала практика использования продукта, основные проблемы начинаются при попытке кастомизировать или расширить внутренний функционал системы. В нашем случае в качестве расширения функционала рассматривается улучшение уровня аудита по работе с репозиториями в части соответствия требованиям ЦБ и ГОСТ Р 56 939–2016.
Торговая система QUIK [ссылка удалена мод.] для большинства серьёзных игроков рынка является очень популярной системой предоставления своим клиентам интерфейса для торговли ценными бумагами. Но в большинстве своём внутренности этой системы, как и любого коммерческого продукта являются закрытыми, в связи с чем могут возникать проблемы интеграции во внутреннюю инфраструктуру предприятия. В этой статье будут рассмотрены возможные механизмы интеграции QUIK в системы предприятия являющегося клиентом брокера или самостоятельным брокером.
Безусловно одной из самых популярных технологий доставки оповещений на устройства пользователей являются Push уведомления. Технология такова, что для её работы необходим постоянный доступ к интернету, а именно доступ к серверам, на которых регистрируются устройства пользователя для получения уведомлений. В данной статье мы рассмотрим весь спектр механизмов технологии WebPush уведомлений, спрятанных за словами WebSocket, ServiceWorker, vapid, register, broadcast, message encryption и т.д. Основной причиной побудившей меня к реверсу и изучению механизма, являлась необходимость доставки уведомлений мониторинга на рабочие места техподдержки, находящиеся в закрытом сегменте сети без доступа в интернет. И да, это возможно! Подробности под катом.
Как мы все знаем, рабочий процесс предприятия, в соответствии с официальными государственными и международными праздниками, зачастую требует изменения производственного процесса в части сдвига или замены рабочих и нерабочих дней. Во множестве организаций существуют внутренние производственные календари, на расписании которых работают технологические и бизнес-процессы. Системы мониторинга работающие автономно, довольно часто настроены на мониторинг бизнес-процессов в рамках обычной деятельности предприятия и имеют жёсткое фиксированное расписание по контролю информационных потоков и данных, сопровождающих бизнес процессы. В моменты изменения ежедневного рабочего расписания, администраторам требуются ручные действия по изменению логики мониторинга. Как заставить Zabbix использовать производственный календарь? Рассмотрим несколько вариантов поподробнее.
OpenVPN, как много в этом слове. Мультиплатформенный, гибко настраиваемый, бесплатный VPN сервер с открытым исходным кодом, являющийся фактически стандартом "defacto" для организации доступа к внутренним корпоративным сетям. Большинство администраторов используют его с настройками по умолчанию или с типовыми конфигурациями широко описанными в разных HOW-TO. Но так ли прост OpenVPN, как он кажется на первый взгляд? В данной статье мы рассмотрим скрытые от глаз внутренние механизмы OpenVPN, которые кардинально меняют представление о его возможностях.
В работе DevOps/Администраторов зачастую возникают моменты, в которые необходимо куда-то кому-то срочно предоставить доступ. Будь то инстанс докера, один из многочисленных контейнеров или какой-то внутренний сервис.
Все знают о возможностях nginx с точки зрения проксирования трафика, балансировки нагрузки между серверами и прочих полезных вещей, помогающих объединять разрозненные сервисы. Однако задача разрешения проблем возникающих в процессе разработки намного обширнее.
Основной посыл данной статьи — показать нестандартный подход к казалось бы простым вещам, таким как предоставление временного доступа внутрь закрытого сегмента.
Описывая участие в проекте по модернизации VoIP оператора связи Часть 1 и Часть 2, одной из задач, которая выпала из поля зрения, было создание унифицированного инструмента для визуализации и мониторинга работы сервера Asterisk. По сути, после выхода из данного проекта, навязчивая идея привести отображение информации Asterisk к более удобному виду вылилась в проект создания прототипа унифицированной виртуальной файловой системы, объединяющей возможности всех разрозненных инструментов доступных в Asterisk.
Думаю что многие из администраторов, которые имели дело с Asterisk, зачастую удивлялись тому количеству различных команд, при помощи которых из Asterisk можно получать данные. Речь пойдёт об учётных записях для абонентских устройств, пользователях для аутентификации, каналах, а также о нестандартном применении виртуальных файловых систем.
Продолжаем наш рассказ о модификации движка для VoIP оператора связи.
В первой части мы рассказали о начальной структуре базы данных и настройке Asterisk для обслуживания вызовов, с мониторингом состояния вызова. В этой части мы затронем такие вещи как тарификатор, LCR, биллинг и геолокация.
Ровно год назад к нам обратились бывшие коллеги, с предложением принять участие в модификации движка VoIP оператора связи. Задача сводилась к полной переделке личного кабинета, обеспечению масштабирования системы, создания системы биллинга, LCR, мониторинга расходов пользователей, контроля длительности разговоров, аналитики по звонкам. История закончилась печально, т.к. заложенный нами расширенный функционал системы якобы не соответствовал ТЗ, никак не формализованному на бумаге и находящемуся только в головах менеджеров оператора. В связи с тем, что за разработанный функционал, который заказчику очень понравился, менеджеры платить не захотели, отношения мы разорвали. NDA и договора у нас не было, поэтому посоветовавшись с коллегами мы решили часть наработок выложить в свободный доступ. Я думаю, что это будет серия статей. И начнём пожалуй с базовых вещей и архитектуры.
Так получилось, что для одного из проектов понадобилась управляемая система пространственного позиционирования целеуказателя. Сервоприводы различных производителей оказались довольно дорогими и было решено купить управляемую камеру и использовать встроенный сервопривод камеры для позиционирования. С PTZ камерами я дела никогда не имел, поэтому на пробу была приобретена камера J2000IP-CmPTZ-111v2.0, якобы российского производителя "3С-Групп".
Внимание! Публикация не является обзором камеры и скорее всего описывает разбор механизмов управления камерой предлагаемый производителем оборудования, а также оценку безопасности её использования.
Как показывает практика, множество систем с использованием календарей обычно строится в виде статических таблиц, в которых перечислены даты и их соответствие рабочим, выходным, праздничным дням. Обычно проблемы начинаются когда система работает без вмешательств программистов достаточно долго и заполненный календарь просто кончается. Для очередного проекта я решил немного оптимизировать данную ситуацию и написал календарь, который создаётся или пересчитывается автоматически, например по встроенному таймеру.
Участвуя последнее время в разных интересных проектах, возникла задачка альтернативного управления продуктом Perco Электронная проходная KT02.3. Данный продукт является законченным решением и не подразумевает использование в составе других систем СКУД, а также какого-либо вторжения в свою среду управления. Но, как говорится в поговорке, «Возможно все! На невозможное просто требуется больше времени» (С) Дэн Браун.
Но мы сделали это. Как всё получилось читайте под катом.
Большинство системных администраторов так или иначе мониторящих оборудование компании, знакомы с пакетом smstools, зачастую используемого лишь для отправки SMS сообщений о состоянии инфраструктуры. Оборотной стороной медали является необходимость удалённого управления инфраструктурой предприятия при недоступности VPN подключения или нахождении вне зоны доступа в интернет. Ранее описанные способы управления безусловно имеют право на жизнь, но рассчитаны на управление одним сервером и не предоставляют возможности безопасного выполнения команд. Ниже по тексту я предлагаю вашему вниманию рабочий механизм безопасного подтверждения выполнения sms команд внутри локальной сети.
Зачастую возникает необходимость принять аудиосигнал с множества несвязанных устройств и выдать полученный сигнал на множество несвязанных акустических систем. Многие делают это через медиаматрицы BiAMP, Kramer в связке с управлением через Kramer, Palantir и т.д., но это оборудование стоит денег, а деньги есть не всегда.
Осмелюсь описать бюджетный вариант, который в базовом функционале не уступает вышеописанным продуктам. А с точки зрения управления может быть более гибок.
В проекте используется 15 медиасерверов (Windows 7), с каждого из которых идёт свой видеоряд отображаемый на плазмах и проекторах, а также аудиопоток, сопровождающий видеоряд. Также имеется 3 акустические системы, на которые аудиопоток можно вывести.
Решил я тут намедни поискать своих бизнес-партнёров на LinkedIn и обнаружил небольшую дырку в предоставлении информации. Схема работает для небольших, либо связанных компаний. Так сказать локальный Privilege Escalation внутри LinkedIn.
Заранее прошу прощения у своих коллег из компании NETCUBE за использование их профилей в посте.
Итак.
Продолжаем публикацию полезных статей о непростых вещах.
Сегодня речь пойдёт о публикации различных сервисов через несколько провайдеров связи одновременно.
В связи с тем, что с течением времени почти во всех организациях появляются дополнительные каналы связи для резервирования или других нужд, возникает вопрос: «А можно ли использовать эти каналы связи для одновременной публикации корпоративных сервисов ?»
Некоторое время назад данный вопрос возник и у нас в компании, поэтому было решено перестроить внешний периметр.
В нашем случае было 4 провайдера и следующий список сервисов:
Ни для кого не секрет, что технология RemoteApp внедрённая в Windows 2008 это ответ Microsoft технологиям доступа к приложениям компании Citrix. Всё бы ничего, но для использования данной технологии в повседневной жизни, без наличия RD Gateway, нужен открытый наружу RDP Port tcp/3389. Наблюдая за своими терминальными серверами, я обнаружил что сервера постоянно подвергаются brute-force атакам подбора паролей различных пользователей.
Дабы не испытывать судьбу я немного модифицировал схему доступа к RDP.
Так случилось, что в короткие сроки появилась необходимость перевезти 70 человек с аналоговыми телефонами из одного бизнес центра в другой. Ситуация усугублялась тем, что в новом офисе у владельца не было аналоговых портов в АТС, а АТС в старом принадлежала телефонной компании. Пришлось в короткие сроки внедрять IP телефонию с переносом всех аналоговых городских линий на Asterisk. Поставка оборудования была назначена на день предшествующий дню переезда, что означало — времени на развертывание телефонии будет очень мало.
Что из этого вышло под катом.
Материала много, так что не пугайтесь.
Поставив для экспериментов dsniff, через пару суток обнаружил, что он насобирал невероятное количество мусора от всяких разных банерных сетей и лог работы стало невозможно читать.
Поискав в интернете скрипты редактирования лога решил написать свой.
