Под кешем в данном контексте имеется ввиду индекс, правильно?
>установленным плагином от ПС => определенная информация попадает в кэш
какая информация? урлы?
То есть по Вашей логике получается, что все урлы по которым ходит пользователь должны быть проиндексированы и должны быть доступны по запросу. почему этого не происходит?
>Каждый из указанных каналов передает информацию поисковой системе, таким образом в кэш попадают фрагменты конфиденциальных данных.
Объясните пожалуйста подробней, как из одного следует другое?
>Рассмотренные каналы утечки: 1) Я.Метрика/GoogleAnalytics — скрипты сервиса для веб-мастеров
Вы же в статье пишите, что
>Тем не менее, сам код аналитической системы для веб-разработчика не спровоцировал индексацию страниц, а значит, как минимум, на данном этапе он не может являться каналом утечки данных в поисковую систему
Уважаемый автор так увлёкся срывом покровов, что забыл ответить на вопрос почему же он читал смс.
Кроме того, не понятно, что он хотел сказать фразой
>которая по каналам утечки попадает в различные уголки сети
Бары собирают данные и раскладывают их по пиринговым сетям?
>Скрипт системы интернет-банкинга передает всю введенную информацию в GET-запросе и это провоцирует передачу конфиденциальной информации на сервис Яндекса. Косяк… Причем, со стороны вендора системы.
Автор, по-видимому, придирчиво искал платёжную систему, так как передача конфиденциальных данных через GET — довольно замшелый косяк (оседают в истории браузера и логах сервера).
Ну и отдельно доставляет стилистика первого абзаца в разделе «Глазами аналитика».
Но в целом статья понравилась — даёт исчерпывающе представление об уровне «экспертов ИБ».
PS
Было бы круто приложить к посту лупу для изучения скриншотов.
Технически можно — обнаружить вы скорее всего успеете. Но смысла нет, так же легко констатировать ддос можно, обнаружив падение сервиса. Смысл обнаружения и наблюдения DDOS в том, чтоб можно было оценивать эффективность принимаемых мер, то есть сама система наблюдения за DDOS должна быть уязвима в гораздо меньшей степени. В описанном случае лучшим источником по которым следует наблюдать ddos являются счётчики на активном сетевом оборудовании.
Snort это, конечно, очень гибкий инструмент, но нацелен он на обнаружение\предотвращение вторжений.
>установленным плагином от ПС => определенная информация попадает в кэш
какая информация? урлы?
То есть по Вашей логике получается, что все урлы по которым ходит пользователь должны быть проиндексированы и должны быть доступны по запросу. почему этого не происходит?
www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
Объясните пожалуйста подробней, как из одного следует другое?
>Рассмотренные каналы утечки: 1) Я.Метрика/GoogleAnalytics — скрипты сервиса для веб-мастеров
Вы же в статье пишите, что
>Тем не менее, сам код аналитической системы для веб-разработчика не спровоцировал индексацию страниц, а значит, как минимум, на данном этапе он не может являться каналом утечки данных в поисковую систему
Кроме того, не понятно, что он хотел сказать фразой
>которая по каналам утечки попадает в различные уголки сети
Бары собирают данные и раскладывают их по пиринговым сетям?
>Скрипт системы интернет-банкинга передает всю введенную информацию в GET-запросе и это провоцирует передачу конфиденциальной информации на сервис Яндекса. Косяк… Причем, со стороны вендора системы.
Автор, по-видимому, придирчиво искал платёжную систему, так как передача конфиденциальных данных через GET — довольно замшелый косяк (оседают в истории браузера и логах сервера).
Ну и отдельно доставляет стилистика первого абзаца в разделе «Глазами аналитика».
Но в целом статья понравилась — даёт исчерпывающе представление об уровне «экспертов ИБ».
PS
Было бы круто приложить к посту лупу для изучения скриншотов.
Snort это, конечно, очень гибкий инструмент, но нацелен он на обнаружение\предотвращение вторжений.
А что именно make install может поломать? Какие косяки могут быть результатом make install и как с ними бороться?
Техническое описание можно тут посмотреть