-
Похожий контент
-
От KL FC Bot
Сканирование жестких дисков рабочих компьютеров — простая ежедневная процедура, которая не мешает пользователю и не требует никаких ручных действий. Однако в случае с серверами ситуация осложняется, особенно если сканирование проводится при реагировании на инциденты и нужно внепланово проверить вообще все хранилища компании, а там — десятки терабайт данных. И при этом нужно обеспечить полную сохранность данных и не допустить заметного пользователям падения производительности. Чтобы не потерять время зря и не допустить дополнительных инцидентов, воспользуйтесь нашими советами и предосторожностями по списку. Советы, касающиеся непосредственно наших решений, мы даем на примерах Kaspersky Endpoint Security, но та же логика применима к другим защитным продуктам EPP/EDR.
Предварительные проверки
Проверьте конфигурацию компьютера, который будет проводить сканирование. Важно убедиться, что он имеет свежую и обновленную версию ОС, которая способна подключиться ко всем проверяемым дискам и корректно обработать данные: «понимает» длинные имена файлов с Unicode, может работать с файлами очень большого размера, файлами на разделах, чувствительных к регистру символов в именах, и так далее. Для ускорения проверки важно выбрать компьютер с мощным многоядерным процессором, значительным количеством памяти и быстрым локальным хранилищем для временных файлов.
Убедитесь, что доступ к дискам будет быстрым. Компьютер должен подключаться ко всем хранилищам либо напрямую (local storage), либо через быстрый сетевой интерфейс по производительному протоколу (в идеале — по разновидности SAN).
Проверьте резервные копии. Хотя сканирование не должно влиять на хранимые данные, в ситуации возможного заражения ВПО или повреждения файлов важно заранее продумать план «Б». Поэтому нужно тщательно проверить дату и состав свежей резервной копии всех данных, учесть, когда были учения по восстановлению данных, в общем, подтвердить полезность текущих версий бэкапа. Если актуальных резервных копий нет, нужно оценить риски, сроки и, возможно, создать резервную копию критических данных перед сканированием.
View the full article
-
От KL FC Bot
Чуть больше года назад в посте Google OAuth и фантомные аккаунты мы уже обсуждали, что использование опции «Вход с аккаунтом Google» в корпоративные сервисы дает возможность сотрудникам создавать фантомные Google-аккаунты, которые не контролируются администратором корпоративного Google Workspace и продолжают работать после оффбординга. Недавно выяснилось, что это не единственная проблема, связанная с OAuth. Из-за недостатков этого механизма аутентификации любой желающий может получить доступ к данным многих прекративших деятельность организаций, перерегистрировав на себя брошенные компаниями домены. Рассказываем подробнее об этой атаке.
Как работает аутентификация при использовании «Вход с аккаунтом Google»
Некоторые могут подумать, что, доверяя опции «Вход с аккаунтом Google», компания получает надежный механизм аутентификации, использующий продвинутые технологии Google и широкие возможности интернет-гиганта по мониторингу пользователей. Однако на деле это не так: при входе с Google OAuth применяется достаточно примитивная проверка. Сводится она, как правило, к тому, что у пользователя есть доступ к почтовому адресу, который привязан к Google Workspace организации.
Причем, как мы уже говорили в предыдущем материале о Google OAuth, это вовсе не обязательно Gmail — ведь привязать Google-аккаунт можно совершенно к любой почте. Получается, что при использовании «Входа с аккаунтом Google» доступ к тому или иному корпоративному сервису защищен ровно настолько надежно, насколько защищен почтовый адрес, к которому привязан Google-аккаунт.
Если говорить несколько более подробно, то при аутентификации пользователя в корпоративном сервисе Google OAuth отправляет этому сервису следующую информацию:
В теории в ID-токене Google OAuth есть уникальный для каждого Google-аккаунта параметр sub, но на практике из-за проблем с его использованием сервисы проверяют лишь домен и адрес электронной почты. Источник
View the full article
-
От KL FC Bot
Удобство облачных хранилищ файлов наподобие Dropbox и OneDrive омрачается лишь тем, что злоумышленники, спецслужбы или просто сотрудники хостинг-провайдера могут несанкционированно просматривать файлы в облаке. Но решение для конфиденциального хранения есть: целый ряд сервисов предлагает хранить файлы в зашифрованном виде. Некоторые называют это End-to-End Encryption, сквозным шифрованием, по аналогии с Signal и WhatsApp. Реклама гласит, что файлы шифруются еще на устройстве хозяина и отправляются в облако уже зашифрованными, а ключ шифрования есть только у владельца файлов. И никто, даже сотрудники сервиса, не может получить доступ к информации. Но так ли это на самом деле?
Наташа, мы сломали все шифрование. Честно
Исследователи с факультета прикладной криптографии ETH Zurich детально разобрали алгоритмы пяти популярных зашифрованных хранилищ: Sync.com, pCloud, Icedrive, Seafile и Tresorit. Оказалось, что разработчики каждого из этих сервисов допустили ошибки в реализации шифрования, позволяющие в той или иной степени манипулировать файлами и даже получать доступ к фрагментам незашифрованных данных. В двух других популярных хостингах, MEGA и Nextcloud, исследователи обнаружили дефекты раньше.
View the full article
-
От SEcrash63
Доброго всем времени суток.
Может быть кто сможет помочь, с такой проблемой.
Имеется ПК с установленной W7 x64 (без SP1, установить не могу обновление, ругается на поврежденное хранилище)
Случилась проблема что перестали работать многие сетевые службы и другие, ПК перестал выходить в интернет, получать Ip и много чего.
Частично проблемы удалось исправить, но привести полностью в рабочее состояние так и не удалось. Журнал событий ругается как минимум на две ошибки, одна из них проблема со службой
"Служба "Служба политики диагностики" завершена из-за ошибки. Не удается найти указанный файл."
И "Не удается найти описание для идентификатора события 0 из источника .NET Runtime. Вызывающий данное событие компонент не установлен на этом локальном компьютере или поврежден. Установите или восстановите компонент на локальном компьютере. .NET Runtime version : 2.0.50727.8806 - Отладчик не найден.Не указан зарегистрированный отладчик JIT"
Делал сканирование системы SFC \SCANNOW говорит проблемы есть, но починить не могу.
Делал DISM /Online /Cleanup-Image /ScanHealth - по его логам с доноров пособирал большую часть файлов, часть выкорчевывал из пакетов обновлений, но не все удалось найти.
Антивирус был все время Kaspersky, после появления проблем временно все удалил. Сейчас никакого антивируса нет.
Логи и того и другого прилагаю.
Подскажите может кто сможет поделится файлами из лога CheckSUR.
Или может быть подскажете другие пути решения проблемы? (Систему с нуля бы поставил, было бы проще, но в данном случае это не предоставляется возможным, очень важно сохранить рабой вариант текущей)
Заранее спасибо.
CBS.log CheckSUR7.log sfcdetails.txt SFCFix.txt
-
От Bercolitt
В качестве сайта выбираю https://www.vtb.ru для аккаунта в хранилище. Прописываю сайт в безопасных платежах Kaspersky Plus. Делаю переход на сайт и попадаю в безопасные платежи на браузере Firefox, хотя в настройках Windows 10 указываю по умолчанию браузер Google Chrome.
Сейчас личный кабинет на сайте стал дурить.На несколько секунд появляется нормальное изображение, потом фон резко темнеет, буквы с трудом различимы. Нажимаешь кружок со стрелкой рядом с адресной строй URL для перезагрузки личного кабинета. Фон становится белым, но буквы постепенно становятся размытыми. Какое-то издевательство, видимо программисты постарались. Уж не фишинговый ли это сайт?
-
Рекомендуемые сообщения
Пожалуйста, войдите, чтобы комментировать
Вы сможете оставить комментарий после входа в
Войти