Вопросы Теги

Полностью задействовать DNSSEC

Во-первых, вы никогда не должны монтировать диск для чтения -записи во время восстановления. Затем вы можете скопировать расшифрованное устройство (в/dev/mapper/foo-crypt)на незашифрованное устройство, если у вас есть инструменты, которые работают только с реальными дисками. Для обычных утилит Linux/dev/mapper/foo-crypt)должно быть нормально.

Тогда testdisk и photorec — хороший выбор, и если вам, например, нужен какой-то важный текстовый документ, вы даже можете попробовать с помощью dd и grep вырезать разные части изображения и попытаться найти информацию.

Хорошая новость заключается в том, что большая часть данных, вероятно, все еще там. Плохая новость заключается в том, что имена файлов и каталогов часто исчезают, и то, что можно восстановить, зависит от вашей файловой системы. Классический подход Windows заключался в том, чтобы (с FAT32 )заменить первый байт имени файла на 0, поэтому имена файлов почти не изменились. Насколько я знаю, ext2/3/4 полностью уничтожает иноды. Таким образом, вы, вероятно, не найдете таких метаданных, но такие инструменты, как testdisk, должны быть в состоянии извлекать форматы файлов, которые они знают, из необработанных данных в разделе.

Возможно, вы сможете восстановить структуру каталогов, если найдете файлы, содержащие ее. Обратите внимание, например, на базу данных locate (1 ), индексы поисковых систем на рабочем столе, последние записи файлов в gnome/kde/различных программах и т. д.

Вероятно, вам придется самостоятельно рассортировать восстановленные файлы по найденной структуре каталогов.

5
01.12.2019, 09:05
1 ответ

Если и dnscrypt-proxy, и systemd-resolvedиспользуют 127.0.0.1:53, этого не должно быть. Вам необходимо отключить systemd-resolvedв соответствии с рекомендациями dnscrypt -proxy wiki , а также заблокировать /etc/resolv.confдля возможных изменений, внесенных вашим сетевым менеджером. Итак, вот шаги:

  • Отключитьsystemd-resolved:
sudo systemctl stop systemd-resolved
sudo systemctl disable systemd-resolved

  • Проверьте, есть ли что-то еще, использующее ту же пару address:port, что и dnscrypt-proxy:sudo ss -lp 'sport = :domain'. Если они есть, отключите их.

  • Если dnscrypt-proxyпрослушивает 127.0.0.1:53и resolv.confимеет nameserver 127.0.0.1, добавьте options edns0(, необходимое для включения расширений безопасности DNS ), под записью nameserverв resolv.conf, чтобы это выглядело как:

nameserver 127.0.0.1
options edns0
  • Заблокировать /etc/resolv.confфайл для внесения изменений:sudo chattr +i /etc/resolv.conf.
  • Вы можете перезапустить dnscrypt-proxy.

В целом, нужно убедиться, что:

  • Только dnscrypt-proxyиспользует127.0.0.1:53
  • resolv.confимеет тот же адрес, что иdnscrypt-proxy
  • resolv.confзащищен от изменений, внесенных другим программным обеспечением, таким как Network Manager.

Кроме того, тот факт, что тест dnsleak показывает IP-адреса Google, не означает, что служба распознавания DNS управляется Google. Возможно, серверы принадлежат Google, но управляются другим лицом. Если вы этого не хотите, вы можете выбрать другой резолвер из dnscrypt -списка общедоступных резолверов прокси-серверов . Убедитесь, что для выбранного преобразователя присутствует поддержка dnssec. Лично я использую резолверы dnscrypt.eu, у которых нет -журнала, нет -фильтра, не -Google и dnssec -.

Ссылки:

2
27.01.2020, 20:42

Теги

Похожие вопросы