Мои вкусы очень специфичны, а потому хотелось бы видеть: – Возможность определять устройства не по MAC, а по IP (с маской и без) и по имени учётной записи из радиуса, например – Возможность гибко настраивать каждый день, т.е., условно, "интернет есть в понедельник с 16 до 17 и с 20 до 21, а в воскресенье есть с 9 до 16 и с 19 до 21" и т.д. и т.п. Для примера, у меня настроено вот так:
К сожалению, функционал родительского контроля в микротике очень неочень, а предлагаемое вами решение несколько переусложнено и не покрывает кейс когда у чилдренов есть ещё тачки с ethernet-линком
Я в своё время перебрал достаточно много вариантов и, в итоге, пришёл к тому, что был сделан бридж со своим пулом серых ip специально для детей, этот бридж обслуживает и отдельный "детский" wlan и ethernet-розетки в детской. Все dns-запросы с этого пула ip редиректятся в "днс для детей", в частности 77.88.8.7 (не реклама, тут может быть любой другой dns), а вместо того чтобы гасить wlan и/или ethernet, просто по времени реджектится любой исходящий траффик правилами фильтрации
Ну согласитесь, что не будет по одному диспетчерскому центру на 750 счётчиков – будет один диспетчерский центр, из которого будет возможность отключить X*750 счётчиков. Да, возможно, это будет мониториться, да, возможно, там будет так, что такого рубильника не будет у работников низкого ранга, но если мы говорим про злоумышленника, который получил доступ к серверу, то никаких согласований ему не потребуется – он сам волен вызвать команду подтверждения от имени сотрудника, которому такое можно делать. Да, можно сказать, что там будет ЭЦП на таком запросе, но, увы, реальность такова, что это просто влажные фантазии и не более – всё будет как у РЖД или у ребят на водоочистной станции в Олдсмаре.
Корень проблем безопасности на самом деле в том, что все участники этой схемы, начиная от производителей железа и заканчивая компаниями-поставщиками электроэнергии, не занимаются информационной безопасностью настолько, насколько это стоило бы им делать, а полагаются на безопасность через неясность и отсутсвие ИБ-процессов как таковых, иначе мы бы в новостях читали вида «железки производителя X прошли независимый аудит безопасности компанией Y, по результатам которого было устранено Z уязвимостей» или «независимая компания А провела аудит безопасности систем компании B, по результатам которого было устранено С уязвимостей, устранены спорные моменты в процессах» и так далее.
Я, возможно, не прав, но со стороны обывателя это выглядит именно так – я знаю много публичных программ вознаграждений за уязвимости во многих интеренет-компаниях, но я ни разу не видел таких программ ни у производителей IoT-железяк и, тем более, у компаний-поставщиков электроэнергии.
Роста внутридомовых потерь не будет – он же просто не изменится. Это очень притянутая за уши теория, которая никак не может доказать чью-либо причастность к воровству электричества – банальное объяснение будет звучать как «я уехал в отпуск, всё отключил, если у вас общедомовые потери не поменялись, то ищите утечку на подконтрольной вам территории, т.е. не в моей квартире». Вся проводка что у вас сделана после счётчика ни коим образом не относится к зоне ответственности или контроля компании которая предоставляет вам электричество, и статью 25 конституции никто не отменял.
Но не поймите меня неправильно, я не призываю никого реализовывать подобную схему у себя, да и у меня самого всё сделано честно – я лишь описываю то, что эта задача вполне реализуема и, с большой долей вероятности, наказание за это никакое не последует. Но есть моральная сторона вопроса и тут каждый волен делать выбор сам.
Это легко обходится если полностью разрывать линию после счётчика (и фаз(у|ы) и ноль) – он будет думать что просто всё в доме выключено. Например чем-то вроде трёхпозиционных модульных переключателей TMD МП-63.
«Умный» прибор учёта имеет защиту от вскрытия и всяких волшебных магнитов. При попытке их использовать отправит на сервер тревожный сигнал
А для чего вскрывать счётчик или покупать волшебные магниты, когда достаточно кинуть «сопю» мимо счётчика? Из очевидных вариантов (если мы говорим про панельку-брежневку):
При ремонте своей квартиры нужно вскрыть стяжку и можно легко подключиться к проводке соседа
В четверти квартир канал с силовыми проводами, через которые запитываются все квартиры, легко доступен если снять выключатель в прихожей и можно относительно легко запитаться от них минуя счётчик
Тупо за щитком в квартире сделать врезку на вводе до счётчика
Самое важное. По команде с сервера, «умный» счётчик сможет отключить потребителя от сети или ограничить его. Прощайте монтёры с бокорезами, здравствуйте диспетчера с кнопками в интерфейсе
И привет злоумышленники, которые взломают диспетчерский центр и погасят свет во всём городе/районе/квартале. Наивно полагать что с безопасностью этой системы всё будет как с
аттракционами в парке Диснейленд
Мы стараемся решать эту проблему без использования программы Bug Bounty. Например, мониторить issue у проектов, исследовать их своими силами и т. д.
Я забыл отметить момент с 0-day уязвимостями. Для них точно не может быть ни issue, ни security advisory, т.е. даже вендор может не знать о том, что проблема у него есть. Навскидку два примера, когда проблема была обнаружена только потому, что о ней было сообщено в стороннюю программу – раз и два.
Если мы Вас правильно поняли, то Вы опасаетесь, что в процессе исследования ресерчер сможет получить данные клиента. В рамках Bug Bounty программы это не является проблемой, так как между нами, Bug Bounty платформой и ресерчерами заключено соглашение о неразглашении данных (NDA).
И не только этого. Можно этот список продолжить, например, падением сервиса, которое произойдёт в процессе исследования ресёрчером и закончить банальным rm -rf /. Но это ни в какое сравнение не идёт с тем, что данные пользователей будут доступны третьим лицам. Я не думаю, что пользователи вашего сервиса будут рады тому, что какой-то ресёрчер из Уганды сдампил у вас базу с их данными, даже при условии, что ресёрчер принял условия оферты.
Одна из целей программы, как мне кажется, повышение уровня защищённости пользователей, и не стоит правилами самой же программы эту цель топтать в грязь.
Также стоит отметить, что при реальном инциденте вы не сможете отличить ресёрчера от нересёрчера, или нересёрчер, даже если вы его заметите, смело сошлётся на ваши правила программы и будет настаивать на том, что он просто пытался раскрутить уязвимость до максимального импакта. Скорее всего вы не пойдёте в суд с этим, а если и пойдёте, то, скорее всего, проиграете его.
До сих пор не все наши сервисы и продукты выставлены на Bug Bounty платформу. Это сделано сознательно, так как часть сервисов, например, создана на основе opеn source решений: их развитием и поддержкой занимаются сторонние команды, поэтому мы считаем, что нет смысла их выставлять в рамках нашей Bug Bounty платформы, так как наша команда следит только за актуальностью данных сервисов.
Данное решение в дальнейшем может сыграть с вами злую шутку. Например, в одном из таких сервисов найдут критичную уязвимость, которую вендор либо вовсе откажется исправлять, либо будет затягивать выпуск исправления, и, пока нет исправления, эту уязвимость будут эксплуатировать in the wild, в том числе, возможно, и в ваших сервисах, но вы просто об этом не узнаете, или узнаете, но поздно, потому что вам просто никто не принесёт репорт в вашу программу, т.к. он не входит в рамки программы. Если цель вашей программы не сэкономить денег, а именно получить уязвимость, которая есть в ваших сервисах, как можно скорее, то платить за уязвимость в стороннем софте, который у вас используется, необходимо.
Таким образом, для установления уровня критичности найденного бага мы анализируем тип уязвимости, важность сервера и степень влияния на компанию. На основании этих критериев мы определяем уровень для каждой найденной уязвимости, от этого и зависит размер вознаграждения багхантеру. Однако добавим, что всё учесть невозможно и часто при определении уровня критичности найденного бага не обойтись без субъективности.
У подобной методики оценки есть, как минимум, следующие недостатки:
Эта система определения критичности непрозрачна для ресёрчера и выглядит как явное одобрение с вашей стороны пост-эксплуатации найденной уязвимости. Например, если ресёрчер найдёт у вас SQLi, то он будет пытаться её раскрутить до RCE в надежде продемонстрировать максимально возможную критичность. В процессе этого он может случайно получить доступ к данным ваших пользователей, защита которых, как мне кажется, должна быть на первом месте;
В перспективе, когда количество репортов у вас будет не 72 в год, а 72 в неделю, вы столкнётесь с тем, что вы будете тратить непростительно много времени на определение критичности по этой методике. И как вы указали, субъективность будет только усугублять это – если критичность репорта и размер вознаграждения у вас определяется командой, а не одним человеком, то они (члены команды) будут очень часто и много спорить о критичности, а следовательно, и о размере вознаграждения;
В любом случае, если у вас в результате запуска программы вознаграждения за найденные уязвимости начались изменения в процессах с в лучшую сторону, то, смею вас заверить, вы двигаетесь в нужном направлении, и средства потраченные на выплату вознаграждений потрачены не зря.
Возможно, мы друг друга неверно поняли. Я имел ввиду адекватность лишь в плане работы. Человек может быть вполне адекватным как работник или руководитель, а в нерабочее время расчленять бабушек и делать из них котлеты. И, наоборот, может ежедневно саботировать работу, а после саботажа вязать крестиком пинетки оставленным в роддоме младенцам и подкармливать бездомных животных.
Я не согласен с оценочным суждением автора в обозначенном вами абзаце.
Я не думаю, что я перефразировал позицию автора статьи. Я лишь отметил, что ситуация «адекватный руководитель неадекватного подчинённого» тоже имеет место быть.
Ну, как вам сказать, то что вам ваше начальство кажется неадекватным еще не означает, что на самом деле так оно и есть. Всегда ведь есть шанс, что вы просто сами неадекват, и потому вам непросто работать с адекватными людьми. Пример этот, кстати, я не из головы взял, скажем так.
Утверждение о том, что X-Frame-Options устарел, и что его можно заменить на Content-Security-Policy: frame-ancestors 'self', явно преувеличено, т.к. если посмотреть на то, кто же поддерживает атрибут frame-ancestors, то станет понятно, что замены для X-Frame-Options на данный момент просто нет. Для сравнения, X-Frame-Options работать будет почти на любом «чайнике»
Всё верно, но не стал использовать по причине того, что если разрешить GET, то автоматом будет разрешён HEAD. Таким образом в случае если какой-то из клиентов сделает HEAD перед тем как скачать файл, то файл будет удалён, но при этом отдан не будет.
Также подобные if вполне укладываются в допустимые, т.к. «The only 100% safe things which may be done inside if in a location context are:
return ...;
rewrite… last;»
Вы безусловно правы, от этого if можно легко избавиться даже в текущей ситуации, иб достаточно того, что путь валидируется ещё на этапе GET-запроса в первый location, а имя папки для удаления можно из него же записать в переменную вот так, которую после использовать в location delete
Именно в данном случае нет, потому что нам обязательно нужно провалидировать путь и получить из пути кусок, чтобы кто-то случайно, а может и специально, не подал на вход uri содержащий ../ или нечто подобное, что приведёт к удалению папки upload вместе со всеми остальными файлами. Впрочем, может быть я слишком перестраховываюсь. Но этот if не настолько плох, чтобы думать над тем, чтобы избавиться от него. Также хочу заметить, что если файлы будут загружаться и скачиваться из корня домена, то этот if можно убрать.
Мои вкусы очень специфичны, а потому хотелось бы видеть:
– Возможность определять устройства не по MAC, а по IP (с маской и без) и по имени учётной записи из радиуса, например
– Возможность гибко настраивать каждый день, т.е., условно, "интернет есть в понедельник с 16 до 17 и с 20 до 21, а в воскресенье есть с 9 до 16 и с 19 до 21" и т.д. и т.п. Для примера, у меня настроено вот так:
К сожалению, функционал родительского контроля в микротике очень неочень, а предлагаемое вами решение несколько переусложнено и не покрывает кейс когда у чилдренов есть ещё тачки с ethernet-линком
Я в своё время перебрал достаточно много вариантов и, в итоге, пришёл к тому, что был сделан бридж со своим пулом серых ip специально для детей, этот бридж обслуживает и отдельный "детский" wlan и ethernet-розетки в детской. Все dns-запросы с этого пула ip редиректятся в "днс для детей", в частности 77.88.8.7 (не реклама, тут может быть любой другой dns), а вместо того чтобы гасить wlan и/или ethernet, просто по времени реджектится любой исходящий траффик правилами фильтрации
Корень проблем безопасности на самом деле в том, что все участники этой схемы, начиная от производителей железа и заканчивая компаниями-поставщиками электроэнергии, не занимаются информационной безопасностью настолько, насколько это стоило бы им делать, а полагаются на безопасность через неясность и отсутсвие ИБ-процессов как таковых, иначе мы бы в новостях читали вида «железки производителя X прошли независимый аудит безопасности компанией Y, по результатам которого было устранено Z уязвимостей» или «независимая компания А провела аудит безопасности систем компании B, по результатам которого было устранено С уязвимостей, устранены спорные моменты в процессах» и так далее.
Я, возможно, не прав, но со стороны обывателя это выглядит именно так – я знаю много публичных программ вознаграждений за уязвимости во многих интеренет-компаниях, но я ни разу не видел таких программ ни у производителей IoT-железяк и, тем более, у компаний-поставщиков электроэнергии.
Но не поймите меня неправильно, я не призываю никого реализовывать подобную схему у себя, да и у меня самого всё сделано честно – я лишь описываю то, что эта задача вполне реализуема и, с большой долей вероятности, наказание за это никакое не последует. Но есть моральная сторона вопроса и тут каждый волен делать выбор сам.
А для чего вскрывать счётчик или покупать волшебные магниты, когда достаточно кинуть «сопю» мимо счётчика? Из очевидных вариантов (если мы говорим про панельку-брежневку):
И привет злоумышленники, которые взломают диспетчерский центр и погасят свет во всём городе/районе/квартале. Наивно полагать что с безопасностью этой системы всё будет как с
аттракционами в парке Диснейленд
Я забыл отметить момент с 0-day уязвимостями. Для них точно не может быть ни issue, ни security advisory, т.е. даже вендор может не знать о том, что проблема у него есть. Навскидку два примера, когда проблема была обнаружена только потому, что о ней было сообщено в стороннюю программу – раз и два.
И не только этого. Можно этот список продолжить, например, падением сервиса, которое произойдёт в процессе исследования ресёрчером и закончить банальным rm -rf /. Но это ни в какое сравнение не идёт с тем, что данные пользователей будут доступны третьим лицам. Я не думаю, что пользователи вашего сервиса будут рады тому, что какой-то ресёрчер из Уганды сдампил у вас базу с их данными, даже при условии, что ресёрчер принял условия оферты.
Одна из целей программы, как мне кажется, повышение уровня защищённости пользователей, и не стоит правилами самой же программы эту цель топтать в грязь.
Также стоит отметить, что при реальном инциденте вы не сможете отличить ресёрчера от нересёрчера, или нересёрчер, даже если вы его заметите, смело сошлётся на ваши правила программы и будет настаивать на том, что он просто пытался раскрутить уязвимость до максимального импакта. Скорее всего вы не пойдёте в суд с этим, а если и пойдёте, то, скорее всего, проиграете его.
Данное решение в дальнейшем может сыграть с вами злую шутку. Например, в одном из таких сервисов найдут критичную уязвимость, которую вендор либо вовсе откажется исправлять, либо будет затягивать выпуск исправления, и, пока нет исправления, эту уязвимость будут эксплуатировать in the wild, в том числе, возможно, и в ваших сервисах, но вы просто об этом не узнаете, или узнаете, но поздно, потому что вам просто никто не принесёт репорт в вашу программу, т.к. он не входит в рамки программы. Если цель вашей программы не сэкономить денег, а именно получить уязвимость, которая есть в ваших сервисах, как можно скорее, то платить за уязвимость в стороннем софте, который у вас используется, необходимо.
У подобной методики оценки есть, как минимум, следующие недостатки:
В любом случае, если у вас в результате запуска программы вознаграждения за найденные уязвимости начались изменения в процессах с в лучшую сторону, то, смею вас заверить, вы двигаетесь в нужном направлении, и средства потраченные на выплату вознаграждений потрачены не зря.
Я не согласен с оценочным суждением автора в обозначенном вами абзаце.
Также подобные if вполне укладываются в допустимые, т.к. «The only 100% safe things which may be done inside if in a location context are:
return ...;
rewrite… last;»
Для этого нужно немного поправить первый location
А location delete сделать таким