Ой-вей, молодое поколение уже тоже на том же ютубе всяких пропагандонов смотрит во всю, и почитайте комментарии, там такая звериная злоба, что можно с уверенностью сказать - в ближайшее время будет достаточно Павликов Морозовых и мальчишей-кибальчишей и просто авторов доносов по призванию. А в школах Юнармия только подъехала и еще не везде закрепилась. Рухнет громко и больно, но до тех пор настрадаются все.
Поэтому при бизнес-использовании документы в нем не передаются, а только ссылки на них во внутреннюю wiki, хранилище секретов и т. п. Не все такие ответственные, но надо просто людям объяснить, и большинство все делает правильно. И то же самое я бы рекомендовал даже для self-hosted продуктов, потому что файлы в чатах пересылать - устаревший подход в принципе.
Это не для того, чтобы система мониторинга могла работать, это чтобы вы могли раскладывать скрипты, раз другие средства для вас не подходят. Театр абсурда - начать замещение системы мониторинга, не изучив продукт, на который переходите. Купите уже курсы себе, у заббикса отличные тренеры есть. Я освоил сам, но раз у вас такая сложная ситуация, вам точно не помешает. Насколько я понимаю, с заббиксом вы можете вообще не хранить скрипты на конечных устройствах, а хранить их на сервере и исполнять удаленно агентом на эндпоинте: https://www.zabbix.com/documentation/6.0/en/manual/web_interface/frontend_sections/administration/scripts Одна строчка конфига агента и все. Мне такая функциональность не нужна, и я ее не изучал, но нагуглил за минуту. И если это то же самое, про что вы писали о system.run, то похоже, можно увеличить лимит длины скрипта по вашему желанию: https://www.zabbix.com/forum/zabbix-help/44075-custom-scripts-increasing-limit-beyond-255-chars UPD: ...Я, конечно, не знаю, что в вашем понимании "короткие" и "достаточно длинные" скрипты, но это ж система мониторинга, а не управления, 1024 символа достаточно?
Вы конечно сделали это в рамках купленной платной подписки Zabbix Global, которая включает 20 предоплаченных дней для разработки интеграций и расширения функционала по запросу клиента?
Использовали в команде разработки и вообще в бизнесе на 120 человек, как замену всяким слакам и внешним мессенджерам. Абсолютно волшебный продукт во всех отношениях - очень удобное управление своим "серверами" (т. е. внутреннеми закрытыми группами компании). Пользователей надо заводить вручную, но дальше есть группы\права. Лучшая ВКС что я в жизни пробовал - 100+ человек смотрят демонстрацию экрана 1080p без тормозов, идеальный шумодав в звонках. Интеграции по веб-хукам с чем хочешь (zabbix, redmine, Jenkins). Веб и десктоп-версия. Теги, упоминания, диалоги... Плюсы можно перечислять бесконечно. Минусы есть, но немного. На новой работе его нет, все в телеге, но тут и нет такой необходимости в удаленном взаимодействии. Если бы была, снова продвигал бы дискорд. Будет крайне жалко, если заблокируют.
Это что же, вы не ощуаете его дружелюбия, когда из-за одного пробела все падает? Или, может, вам не дружелюбно, когда дебажите плейбуку, и считаете пробелы в разных строках за пределами одного экрана, и никак не можете сообразить, сколько же их должно быть, с учетом вложенности элементов? Да вы просто ничего не понимаете в дружелюбии!
Да, 3000 серверов на винде (и импортозамещение?), это будет непросто. Но Zabbix + git + ansible список хостов и одна playbook на 10 строчек все это сделают. Подготовки с развертыванием будет гораздо больше, чем 10 строчек, но как правило, оно того стоит. И чем раньше начнете, тем дальше импортозамещаться будет проще.
Нет, Вы нипанимаити! 1. Ansible и Git очень простые продукты с минимальным импактом на инфраструктуру и поддержку 2. Это не workflow заббикса, это ваши скрипты, разложите их как вам удобно (совсем не понимаю, не хотите Ansible - что вам мешает пользоваться майкрософтовскими же GPO?) UPD: Заодно расскажите, пожалуйста, как в SCOM решается задача разработки, хранения репозитория этих самых скриптов и их версионирования?
Потому что продукты майкрософт, в частности SCOM, - переусложненные overengeneered комбайны, работающие поверх такого же стека технологий. Умеют все на свете, даже то, что никому не надо. Заббикс работает не так, он система мониторинга, а не раксладывания скриптов. Раскладывание скриптов элементарно решается групповыми политиками, или Ansible + Git.
В статье действительно про этот момент какая-то дичь. Говоря вообще о защите от перехвата голосового трафика, есть возможность подключить щифрование трафика ZRTP и у некоторых операторов это реализовано в ЛК, либо voice vpn (по-сути, от обычного ВПН мало чем отличается) и он тоже у некоторых провайдеров есть. Это до абонента. А как там у них внутре трафик ходит, или на межоператорских стыках - никто не знает.
Десять лет на них в двух разных компаниях с тех пор еще, когда они были Zadarma (с резервом у другого оператора). За все это время из проблем - тот самый эпический DDos, после которого они подключили DDos защиту. И теперь совсем никаких проблем нет. Изредка не проходят вызовы в какой-нибудь край земли, пишешь в поддержку и через 15 минут все ок. Мониторим пинги до их шлюзов, падения транков, и еще параметры по-мелочи, ничего криминального мониторинг не показывает. Качество голоса нормальное. От поддержки их мне никогда ничего сложного не требовалось, по простым вопросам отвечали всегда минут за 10-20. По каким-либо вопросам с сип (например, подключение транка в онлайн-CRM) подольше, но зато с логами и пояснениями, что крутить на нашей стороне.
Не могу ничего сказать про провайдерский уровень, но на уровне компании все это легчайше настраивается сразу из коробки, и в ВПН, и сквозь НАТ с пробросами и как угодно еще. Бывают местечковые провайдеры у которых телефонисты еще медно-бронзовые и под них надо фиксировать нестандартный порт или что-то еще подкручивать, но у меня таких из 20 был только один. Мессенджеры хороши, но для компаний важно, чтобы разговоры централизовано записывались, а софт и оборудование были под их полным контролем. Мессенджеры (если мы про ватсапп\телеграм и т. п.) централизованно никак не управляются, не настраиваются и не развертываются до сих пор, через них можно спокойно засылать друг другу вирусы, потому что шифрование. Без записи разговоров, компании, где я работал, потеряли бы в судах миллионы, потому что клиент уверял, что заказывал по телефону совсем не то, что ему предоставили и не будет платить.
На уровне офиса, к счастью, вместе с PRI мы безвозвратно и навсегда потеряли привязку к конкретному медному кабелю в офисе (на удаленку в соседний район себе линию не протянешь, не то что на другой континент), жуткие, дорогие, тормозные офисные АТС, где каждое расширение функционала - это отдельная физическая коробка за бешеные деньги, почти полное отсутствие резервирования на уровне офиса\компании, неудобные телефоны без LDAP-адресных книг и так далее до бесконечности. Вместе с Софтсвичами, ip- и софтфонами у нас все это есть. Ранее были сомнения по надежности, но все работает как часы годами. И резерв ВМ с АТС организовать куда как проще. UPD: Но вот доверять 100% облачным АТС я бы не стал, абоненты Новофона и Манго-Офис, из-за DDoS сидевшие без телефонии по 4 суток не дадут соврать. Поэтому, если облачная АТС - то у двух разных провайдеров сразу. Либо транки покупаем у двух отдельных провайдеров, а АТС у третьего и держим в офисе свою резервную FreePBX и если что переводим транки на нее.
Выглядит так, будто статью опубликовали случайно раньше времени, написав только четверть. Где ответы, Билли? Да, опенсорс хорошо, но не везде подходит. Еще варианты? Если соберетесь дописать остальное, расскажите, пожалуйста, кто все эти компании, на чьи продукты влияет ключевая ставка. Касперский, PositiveTechnologies, Astra, все сидят на кредитах без собственных оборотных средств? Бедненькие. Как они тогда вообще дожили до этого момента?
Мысль про бюджеты и "косты" понял. Но реально-то ИБшники нужны-нужны. Причем всем, даже небольшому бизнесу от 50 человек. Может, не в штате, а на аутсорсе от средних и крупных поставщиков решений безопасности и SOC. Пошифрованные и дважды заплатившие выкуп компании не дадут соврать.
Я не спец по ИБ, в сторонке стою, смотрю, и сам занимаюсь по-минимуму, как админ. И я даже представить не могу, каков у настоящих ИБшников уровень стресса, перегрузки и выгорания. По-моему, это адовая работа, когда у нападающих всегда преимущество, бизнес требует сохранять дырявое старое ПО, потому что его нечем заместить, бюджетов и рук постоянно не хватает, а угрозы и возможные последствия просто чудовищные и с каждым днем хуже. А еще "документарная" безопасность и соответствие требованиям (compliance) порождающие кучу бумажной работы... Мрак, тоска и тлен. Так что господину Ляпунову хорошо бы не ляпать неподумавши такие нелепицы, а активно развивать и финансировать ИБ-факультеты, стажировки, курсы там и вот это все.
Оценил ваши усилия и статью, но не рекомендую WikiJS и вот почему. Используем в работе небольшой команды поддержки, выбирал коллега и на мой взгляд крайне неудачно: 1. Поддерживалась одним единственным автором, у него проблемы со здоровьем и он перестал развивать проект. Чем и когда эти проблемы кончатся - неизвестно. Версия 3 все в альфе и никаких подвижек нет уже очень давно: https://beta.js.wiki/blog/2022-the-road-to-the-wiki-js-3-beta Скорее всего проект будет заброшен. 2. В стабильной версии 2 нет копипасты изображений из буфера - надо отдельно загрузить картинку в "Ассеты" и оттуда уже втавлять. Это настолько неудобно, что я в некоторых статьях не ставлю скриншоты, если этого можно хоть как-то избежать и это снижает наглядность и понятность. 3. Полнотекстовый поиск в мое инсталляции не работал из коробки и пришлось его доприкручивать руками. Без этого поиск только по заголовкам, подзаголовкам и тегам.
Поэтому настоятельно рекомендую что-то другое, например bookstack, лишен всех перечисленных недостатков
А что, во все эти циски до сих пор api нормальные не завезли?
Это факт. Человекочитаемый, но не очень человекописа́емый :)
Ой-вей, молодое поколение уже тоже на том же ютубе всяких пропагандонов смотрит во всю, и почитайте комментарии, там такая звериная злоба, что можно с уверенностью сказать - в ближайшее время будет достаточно Павликов Морозовых и мальчишей-кибальчишей и просто авторов доносов по призванию. А в школах Юнармия только подъехала и еще не везде закрепилась. Рухнет громко и больно, но до тех пор настрадаются все.
Поэтому при бизнес-использовании документы в нем не передаются, а только ссылки на них во внутреннюю wiki, хранилище секретов и т. п.
Не все такие ответственные, но надо просто людям объяснить, и большинство все делает правильно.
И то же самое я бы рекомендовал даже для self-hosted продуктов, потому что файлы в чатах пересылать - устаревший подход в принципе.
Это не для того, чтобы система мониторинга могла работать, это чтобы вы могли раскладывать скрипты, раз другие средства для вас не подходят.
Театр абсурда - начать замещение системы мониторинга, не изучив продукт, на который переходите. Купите уже курсы себе, у заббикса отличные тренеры есть.
Я освоил сам, но раз у вас такая сложная ситуация, вам точно не помешает.
Насколько я понимаю, с заббиксом вы можете вообще не хранить скрипты на конечных устройствах, а хранить их на сервере и исполнять удаленно агентом на эндпоинте:
https://www.zabbix.com/documentation/6.0/en/manual/web_interface/frontend_sections/administration/scripts
Одна строчка конфига агента и все.
Мне такая функциональность не нужна, и я ее не изучал, но нагуглил за минуту.
И если это то же самое, про что вы писали о system.run, то похоже, можно увеличить лимит длины скрипта по вашему желанию:
https://www.zabbix.com/forum/zabbix-help/44075-custom-scripts-increasing-limit-beyond-255-chars
UPD: ...Я, конечно, не знаю, что в вашем понимании "короткие" и "достаточно длинные" скрипты, но это ж система мониторинга, а не управления, 1024 символа достаточно?
Вы конечно сделали это в рамках купленной платной подписки Zabbix Global, которая включает 20 предоплаченных дней для разработки интеграций и расширения функционала по запросу клиента?
Использовали в команде разработки и вообще в бизнесе на 120 человек, как замену всяким слакам и внешним мессенджерам.
Абсолютно волшебный продукт во всех отношениях - очень удобное управление своим "серверами" (т. е. внутреннеми закрытыми группами компании). Пользователей надо заводить вручную, но дальше есть группы\права. Лучшая ВКС что я в жизни пробовал - 100+ человек смотрят демонстрацию экрана 1080p без тормозов, идеальный шумодав в звонках.
Интеграции по веб-хукам с чем хочешь (zabbix, redmine, Jenkins). Веб и десктоп-версия.
Теги, упоминания, диалоги...
Плюсы можно перечислять бесконечно.
Минусы есть, но немного.
На новой работе его нет, все в телеге, но тут и нет такой необходимости в удаленном взаимодействии. Если бы была, снова продвигал бы дискорд. Будет крайне жалко, если заблокируют.
Это что же, вы не ощуаете его дружелюбия, когда из-за одного пробела все падает?
Или, может, вам не дружелюбно, когда дебажите плейбуку, и считаете пробелы в разных строках за пределами одного экрана, и никак не можете сообразить, сколько же их должно быть, с учетом вложенности элементов? Да вы просто ничего не понимаете в дружелюбии!
Зашел написать о том же. Не хватает только насечки для правильного формирования осколков :)
Да, 3000 серверов на винде (и импортозамещение?), это будет непросто. Но Zabbix + git + ansible список хостов и одна playbook на 10 строчек все это сделают. Подготовки с развертыванием будет гораздо больше, чем 10 строчек, но как правило, оно того стоит. И чем раньше начнете, тем дальше импортозамещаться будет проще.
Нет, Вы нипанимаити! 1. Ansible и Git очень простые продукты с минимальным импактом на инфраструктуру и поддержку 2. Это не workflow заббикса, это ваши скрипты, разложите их как вам удобно (совсем не понимаю, не хотите Ansible - что вам мешает пользоваться майкрософтовскими же GPO?)
UPD: Заодно расскажите, пожалуйста, как в SCOM решается задача разработки, хранения репозитория этих самых скриптов и их версионирования?
Потому что продукты майкрософт, в частности SCOM, - переусложненные overengeneered комбайны, работающие поверх такого же стека технологий. Умеют все на свете, даже то, что никому не надо.
Заббикс работает не так, он система мониторинга, а не раксладывания скриптов.
Раскладывание скриптов элементарно решается групповыми политиками, или Ansible + Git.
В статье действительно про этот момент какая-то дичь. Говоря вообще о защите от перехвата голосового трафика, есть возможность подключить щифрование трафика ZRTP и у некоторых операторов это реализовано в ЛК, либо voice vpn (по-сути, от обычного ВПН мало чем отличается) и он тоже у некоторых провайдеров есть. Это до абонента. А как там у них внутре трафик ходит, или на межоператорских стыках - никто не знает.
Десять лет на них в двух разных компаниях с тех пор еще, когда они были Zadarma (с резервом у другого оператора). За все это время из проблем - тот самый эпический DDos, после которого они подключили DDos защиту. И теперь совсем никаких проблем нет. Изредка не проходят вызовы в какой-нибудь край земли, пишешь в поддержку и через 15 минут все ок. Мониторим пинги до их шлюзов, падения транков, и еще параметры по-мелочи, ничего криминального мониторинг не показывает. Качество голоса нормальное. От поддержки их мне никогда ничего сложного не требовалось, по простым вопросам отвечали всегда минут за 10-20. По каким-либо вопросам с сип (например, подключение транка в онлайн-CRM) подольше, но зато с логами и пояснениями, что крутить на нашей стороне.
Не могу ничего сказать про провайдерский уровень, но на уровне компании все это легчайше настраивается сразу из коробки, и в ВПН, и сквозь НАТ с пробросами и как угодно еще. Бывают местечковые провайдеры у которых телефонисты еще медно-бронзовые и под них надо фиксировать нестандартный порт или что-то еще подкручивать, но у меня таких из 20 был только один. Мессенджеры хороши, но для компаний важно, чтобы разговоры централизовано записывались, а софт и оборудование были под их полным контролем. Мессенджеры (если мы про ватсапп\телеграм и т. п.) централизованно никак не управляются, не настраиваются и не развертываются до сих пор, через них можно спокойно засылать друг другу вирусы, потому что шифрование. Без записи разговоров, компании, где я работал, потеряли бы в судах миллионы, потому что клиент уверял, что заказывал по телефону совсем не то, что ему предоставили и не будет платить.
На уровне офиса, к счастью, вместе с PRI мы безвозвратно и навсегда потеряли привязку к конкретному медному кабелю в офисе (на удаленку в соседний район себе линию не протянешь, не то что на другой континент), жуткие, дорогие, тормозные офисные АТС, где каждое расширение функционала - это отдельная физическая коробка за бешеные деньги, почти полное отсутствие резервирования на уровне офиса\компании, неудобные телефоны без LDAP-адресных книг и так далее до бесконечности.
Вместе с Софтсвичами, ip- и софтфонами у нас все это есть. Ранее были сомнения по надежности, но все работает как часы годами. И резерв ВМ с АТС организовать куда как проще.
UPD: Но вот доверять 100% облачным АТС я бы не стал, абоненты Новофона и Манго-Офис, из-за DDoS сидевшие без телефонии по 4 суток не дадут соврать.
Поэтому, если облачная АТС - то у двух разных провайдеров сразу. Либо транки покупаем у двух отдельных провайдеров, а АТС у третьего и держим в офисе свою резервную FreePBX и если что переводим транки на нее.
Выглядит так, будто статью опубликовали случайно раньше времени, написав только четверть. Где ответы, Билли? Да, опенсорс хорошо, но не везде подходит. Еще варианты?
Если соберетесь дописать остальное, расскажите, пожалуйста, кто все эти компании, на чьи продукты влияет ключевая ставка. Касперский, PositiveTechnologies, Astra, все сидят на кредитах без собственных оборотных средств? Бедненькие. Как они тогда вообще дожили до этого момента?
Мысль про бюджеты и "косты" понял. Но реально-то ИБшники нужны-нужны. Причем всем, даже небольшому бизнесу от 50 человек. Может, не в штате, а на аутсорсе от средних и крупных поставщиков решений безопасности и SOC. Пошифрованные и дважды заплатившие выкуп компании не дадут соврать.
Я не спец по ИБ, в сторонке стою, смотрю, и сам занимаюсь по-минимуму, как админ.
И я даже представить не могу, каков у настоящих ИБшников уровень стресса, перегрузки и выгорания. По-моему, это адовая работа, когда у нападающих всегда преимущество, бизнес требует сохранять дырявое старое ПО, потому что его нечем заместить, бюджетов и рук постоянно не хватает, а угрозы и возможные последствия просто чудовищные и с каждым днем хуже.
А еще "документарная" безопасность и соответствие требованиям (compliance) порождающие кучу бумажной работы... Мрак, тоска и тлен.
Так что господину Ляпунову хорошо бы не ляпать неподумавши такие нелепицы, а активно развивать и финансировать ИБ-факультеты, стажировки, курсы там и вот это все.
Оценил ваши усилия и статью, но не рекомендую WikiJS и вот почему.
Используем в работе небольшой команды поддержки, выбирал коллега и на мой взгляд крайне неудачно:
1. Поддерживалась одним единственным автором, у него проблемы со здоровьем и он перестал развивать проект. Чем и когда эти проблемы кончатся - неизвестно. Версия 3 все в альфе и никаких подвижек нет уже очень давно: https://beta.js.wiki/blog/2022-the-road-to-the-wiki-js-3-beta
Скорее всего проект будет заброшен.
2. В стабильной версии 2 нет копипасты изображений из буфера - надо отдельно загрузить картинку в "Ассеты" и оттуда уже втавлять. Это настолько неудобно, что я в некоторых статьях не ставлю скриншоты, если этого можно хоть как-то избежать и это снижает наглядность и понятность.
3. Полнотекстовый поиск в мое инсталляции не работал из коробки и пришлось его доприкручивать руками. Без этого поиск только по заголовкам, подзаголовкам и тегам.
Поэтому настоятельно рекомендую что-то другое, например bookstack, лишен всех перечисленных недостатков