Вопрос что называется «не в бровь, а в глаз» :) Мы пока только набиваем шишки. Продукт всего несколько месяцев, как запустился. Поэтому на все вопросы дать исчерпывающих ответов пока не можем.
Про этическую сторону вопроса. Мы собираем только общедоступную информацию используя только стандартные протоколы. Не нужно обладать какими-либо специализированными знаниями или инструментами, чтобы собрать информацию о любом ресурсе в том же объеме, что есть у нас. Ценность продукта не в том, что он содержит какую-то тайну, а в том, что вся информация агрегирована в одном месте, размечена, обогащена, есть поиск и возможность дальнейшей автоматизированной обработки через API. По сути это атлас. Ничего неэтичного в атласах мы не видим. Ну то есть да, наверное его можно использовать с разными целями. Но это уже на совести того, кто использует. Мы видим множество конструктивных способов использования продукта. А значит, штука в целом полезная.
С юридической точки зрения ответить тяжело. Поскольку сканеры обходят Интернет целиком, вероятно, мы заглядываем во все возможные юрисдикции. Можем чего-то не знать. Если что-то и нарушаем, думаю мы это быстро выясним 0_o Нашу позицию по вопросу соблюдения законодательства мы изложили на сайте продукта, вот тут: https://netlas.io/legal
Ну SIEMкой то оно конечно удобнее :) В этом я с Вами согласен.
А я пытался донести ту мысль, что контроль версий и вот такие вот скрипты-триггеры для разных целей служат. Они вместе должны «играть». Ни кто ни кому не проигрывает.
Не соглашусь с Вами. Контроль версий штука безусловно полезная и необходимая. Но что с него толку, если у Вас 100 проектов? Вы действительно будете глазками анализировать все изменения? Нужно же знать, куда смотреть.
На мой взгляд триггеры, которые привлекают внимание к возможной проблеме, нужны независимо от контроля версий. Да и вопрос того, какие изменения были внесены, это уже больше к расследованию.
Свободных и удобных одновременно к сожалению не встречал. Использую PowerDesigner.
Одно время был инструмент от Borland. Не помню как назывался (Team чего-то там). Потом он стал платным.
К. Ларман. "Применение UML и шаблонов проектирования".
Фундаментальный труд, охватывающий сразу несколько аспектов разработки ПО. Я читал эту книгу довольно давно, перечитывал некоторые части много раз. Сразу оговорюсь, я читал 2-ое издание, но сейчас в продаже уже 3-е.
Первое, что я вынес для себя из этой книги - это представление о том, как должен выглядеть итеративный процесс разработки в частности и процесс разработки в общем. В книге описывается UP. Причем описываются различные аспекты и виды работ: начиная от формирования первоначального видения проекта и описания use-case`ов, и заканчивая тестированием продукта. Приведены наиболее распространенные шаблоны проектирования. Подробные описания и разъяснения, а также примеры применения шаблонов. И конечно же это отличный учебник по UML.
Способ подачи материала не рассчитан на профессионала. Это, скорее всего, учебник, который дает представление обо всех аспектах объектно-ориентированного подхода к созданию ПО и об итеративном процессе разработки. Простой и понятный язык.
Если хочется упорядочить уже имеющиеся знания и получить базовые знания обо всех смежных с разработкой ПО областях - анализ, проектирование, тестирование, документирование и т.д. - очень рекомендую.
Из минусов: не очень хорошо переведены некоторые термины, книгой неудобно пользоваться как справочником.
Вот ссылка на ozon: http://www.ozon.ru/context/detail/id/3105480/
Да. Я в общем-то согласен, что статья научной ценности не представляет.
Уважаемый m1z0, я надеюсь, что Вы воспримите конструктивную критику? Позвольте указать, где по моему мнению (кроме очевидных моментов, на которые указал господин vilgeforce), Вы были не правы.
1. Язык. Следите за теми оборотами, которые Вы употребляете. В качестве примеров можно читать различные научные статьи или книги и заимствтвать от туда. Только не руководствуйтесь сленгом журнала "Хакер" или подобных ему.
2. Даже если вы решили написать статью простым языком, так сказать "для обывателей", то все равно не следует употреблять призывы наподобие: "Помните, что паранойя – лучшая защита". Это перебор.
3. Не стоит писать о том, в чем Вы плохо разбираетесь. Вы только вводите в заблуждение читателей.
4. Угрозы очень сильно различаются в зависимости от системы и условий ее существования. Некоторые угрозы, которые актуальны для Web-сервера, неактуальны для сотового телефона. Вы же свалили все, что смогли найти в одну кучу.
5. Дочитал до SQL Injection... Ух... Если про угрозу фишинга Вы писали так, что поймет ученик начальной школы, то тут я бы (специалист по ИБ) не разобрался, если бы не знал, о чем идет речь.
Все дальше читать не буду.
Ну и последнее, "...к аффтору притензий не предъявлять" - если Вы претендуете на авторство, то и все вопросы к Вам!
Надежным решением в данном случае (ИМХО) будет нормализация трафика. Кстати, если кто-то считает, что потоковый звук и видео плохо нормализуются, то это заблуждение. Есть нормализаторы, которые справляются с этой задачей просто "на ура" (сам видел!). Правда, есть другой аспект... это дорого. И это не единственная проблема: все пакеты придется инкапсулировать; если применяется шифрование с инкапсуляцией, то исходный пакет будет обернут 2 раза.
И тут уже не понятно где мы больше сэкономим. Либо это переменный битрейт, который дает ощутимый результат при компресии, плюс двойная обертка пакетов и выравнивающий трафик, сгенерированный нормализатором. Либо постоянный битрейт, как следствие, больший объем трафика, но отсутствие необходимости нормализации.
Это все опять же здорово в теории. А на практике как оператор решит, так и будет :)
Про этическую сторону вопроса. Мы собираем только общедоступную информацию используя только стандартные протоколы. Не нужно обладать какими-либо специализированными знаниями или инструментами, чтобы собрать информацию о любом ресурсе в том же объеме, что есть у нас. Ценность продукта не в том, что он содержит какую-то тайну, а в том, что вся информация агрегирована в одном месте, размечена, обогащена, есть поиск и возможность дальнейшей автоматизированной обработки через API. По сути это атлас. Ничего неэтичного в атласах мы не видим. Ну то есть да, наверное его можно использовать с разными целями. Но это уже на совести того, кто использует. Мы видим множество конструктивных способов использования продукта. А значит, штука в целом полезная.
С юридической точки зрения ответить тяжело. Поскольку сканеры обходят Интернет целиком, вероятно, мы заглядываем во все возможные юрисдикции. Можем чего-то не знать. Если что-то и нарушаем, думаю мы это быстро выясним 0_o Нашу позицию по вопросу соблюдения законодательства мы изложили на сайте продукта, вот тут: https://netlas.io/legal
А я пытался донести ту мысль, что контроль версий и вот такие вот скрипты-триггеры для разных целей служат. Они вместе должны «играть». Ни кто ни кому не проигрывает.
На мой взгляд триггеры, которые привлекают внимание к возможной проблеме, нужны независимо от контроля версий. Да и вопрос того, какие изменения были внесены, это уже больше к расследованию.
Одно время был инструмент от Borland. Не помню как назывался (Team чего-то там). Потом он стал платным.
Использовал различные UML-плагины к Eclipse.
Фундаментальный труд, охватывающий сразу несколько аспектов разработки ПО. Я читал эту книгу довольно давно, перечитывал некоторые части много раз. Сразу оговорюсь, я читал 2-ое издание, но сейчас в продаже уже 3-е.
Первое, что я вынес для себя из этой книги - это представление о том, как должен выглядеть итеративный процесс разработки в частности и процесс разработки в общем. В книге описывается UP. Причем описываются различные аспекты и виды работ: начиная от формирования первоначального видения проекта и описания use-case`ов, и заканчивая тестированием продукта. Приведены наиболее распространенные шаблоны проектирования. Подробные описания и разъяснения, а также примеры применения шаблонов. И конечно же это отличный учебник по UML.
Способ подачи материала не рассчитан на профессионала. Это, скорее всего, учебник, который дает представление обо всех аспектах объектно-ориентированного подхода к созданию ПО и об итеративном процессе разработки. Простой и понятный язык.
Если хочется упорядочить уже имеющиеся знания и получить базовые знания обо всех смежных с разработкой ПО областях - анализ, проектирование, тестирование, документирование и т.д. - очень рекомендую.
Из минусов: не очень хорошо переведены некоторые термины, книгой неудобно пользоваться как справочником.
Вот ссылка на ozon: http://www.ozon.ru/context/detail/id/3105480/
Уважаемый m1z0, я надеюсь, что Вы воспримите конструктивную критику? Позвольте указать, где по моему мнению (кроме очевидных моментов, на которые указал господин vilgeforce), Вы были не правы.
1. Язык. Следите за теми оборотами, которые Вы употребляете. В качестве примеров можно читать различные научные статьи или книги и заимствтвать от туда. Только не руководствуйтесь сленгом журнала "Хакер" или подобных ему.
2. Даже если вы решили написать статью простым языком, так сказать "для обывателей", то все равно не следует употреблять призывы наподобие: "Помните, что паранойя – лучшая защита". Это перебор.
3. Не стоит писать о том, в чем Вы плохо разбираетесь. Вы только вводите в заблуждение читателей.
4. Угрозы очень сильно различаются в зависимости от системы и условий ее существования. Некоторые угрозы, которые актуальны для Web-сервера, неактуальны для сотового телефона. Вы же свалили все, что смогли найти в одну кучу.
5. Дочитал до SQL Injection... Ух... Если про угрозу фишинга Вы писали так, что поймет ученик начальной школы, то тут я бы (специалист по ИБ) не разобрался, если бы не знал, о чем идет речь.
Все дальше читать не буду.
Ну и последнее, "...к аффтору притензий не предъявлять" - если Вы претендуете на авторство, то и все вопросы к Вам!
И тут уже не понятно где мы больше сэкономим. Либо это переменный битрейт, который дает ощутимый результат при компресии, плюс двойная обертка пакетов и выравнивающий трафик, сгенерированный нормализатором. Либо постоянный битрейт, как следствие, больший объем трафика, но отсутствие необходимости нормализации.
Это все опять же здорово в теории. А на практике как оператор решит, так и будет :)