Предлагаю смотреть на вопрос философски. Многие из нас работают на удаленке. Защищая свою рабочую машину для просмотра котиков, мы возможно избавим от проблем себя и свою любимую компанию. А вот откуда может прилететь, сходу сказать сложно. Будем считать против нас Бох! Ну не тот который всё создал, а тот который специализируется на атаках ИБ, ну и раз он Бох, то он конечно умеет читать мысли и бессмертен.

( читать дальше... )

В этот раз через QEMU + KVM + скрипты.

( читать дальше... )

В этот раз покажу действительно красивый десктоп,чтобы умилились самые бородатые обитатели ЛОРа ;)

Ну и заодно расскажу о настройке Вентуры в эмуляторе.

OS: Mageia Linux, XFCE4
Иконки: Vimix
Оформление окон: HitoriDots4
Шрифты: Carlito Regular

Про то что KVM и Qemu настолько сильно развился честно говоря даже не подозревал, как и про возможность пробросить видеокарту целиком в эмулируемую систему. Поэтому до последнего гонял MacOS в Vmware и Virtualbox, со всеми присущими тормозами и проблемами.

Вообщем взял вот эти скрипты и чуть доработал. Получилось отдельное руководство, уже на русском. Наслаждайтесь.

P.S. Wallpaper тоже мой.

>>> Просмотр (1920x1080, 2067 Kb)

Добрый день.

Речь про Debian Jessie, хотя тема может быть актуальной и для других дистрибутивов (ubuntu?).

Настроено шифрование корневого раздела (LUKS). Хочется, что бы расшифровка выполнялась с флэшки, а если она не вставлена - то при помощи ввода пароля.

Проблема в том, что работает или запрос пароля или использование ключа с флэшки.

Запись в /etc/crypttab сейчас такая (UUDI'ы заменил на точки, разрывы строк добавлены для удобочитаемости):

crypt_md0p5 UUID=..... \
/dev/disk/by-uuid/.....:/luks.key \
luks,noauto,keyscript=/lib/cryptsetup/scripts/passdev

Если флэшка с ключем вставлена - все загружается. Если же не вставлена - загрузка прерывается, пароль не запрашивается.

Хочется найти решение без использования сторонних скриптов (т.е. средствами из дистрибутива).

Требуется ключом расположенным на флешке расшифровывать root раздел при загрузке.

нашёл простой гайд:
https://gist.github.com/martijnvermaat/2726386
http://www.cheshirekow.com/wordpress/?p=810
http://proc.fsckwits.com/2010/05/ubuntu-encrypted-lvms-and-keyfile-on.html
Пишут в комментах, что они работают, но у меня не взлетает. п.с. пробовал разные скрипты и гайды, ошибки одни. И действия там одни и те же.

Что сделал:
настроил lvm, шифрование по паролю, в шифрованном разделе создал root и swap, boot отдельно не шифрованный.
Всё работает, но нужно каждый раз вводить пароль.
Создал ключ, добавил его в контейнер, расположил на юсб флешке. Отредактировал crypttab. Создал скрипт для отправки ключа с флешки в стдаут(или вроде того)). Обновил образ.

На проверку зашифровал /tmp, всё работает, в boot.log видно что расшифровка происходит уже после монтирования root. С root разделом это не работает, хотя гайд как раз для этого случая и написан.

/etc/crypttab

sda5_crypt UUID=*** none luks,keyscript=/sbin/keyscript

/sbin/keyscript

#!/bin/sh
modprobe usb-storage
sleep 5
mkdir /keydev 1>&2
mount -t ext4 -o ro /dev/disk/by-uuid/d58009e6-a694-47b6-a9ca-6a4ada8383a8 /keydev 1>&2
cat /keydev/key
umount /keydev 1>&2

Вываливаются ошибки wrong syntax #!/bin/sh и ещё что-то(под рукой лога нет)

Кодировку менял, не помогло. Думаю не подгружаются системные переменные поэтому ошибки и вываливаются, но знаний не хватает для решения проблемы.

П.с.с пробовал разные дистрибутивы, дебиан, минт, убунту. Везде одно.

Помогите познать безопасность 256 битного аеs. Или ткните в рабочий гайд или скрипт.

Привет

Решил поиграться с локалями в /usr/share/i18n/locales. Там юникодный текст представлен в виде кодов, например <U0412><U043E><U0441><U043A><U0440><U0435><U0441><U0435><U043D><U044C><U0435>.

Как это сконвертировать во что-то читабельное?

Перемещено hobbit из general

Состоялся выпуск библиотеки libmdbx v0.11.7 с реализацией высокопроизводительной компактной встраиваемой базы данных класса ключ-значение. Код распространяется под лицензией OpenLDAP Public License. Заявлено о поддержке всех актуальных операционных системы и архитектур, включая российский Эльбрус 2000.

Заслуживает внимания, что с 2021 года libmdbx используется в трех самых высокопроизводительных реализациях Ethereum (Erigon, Akula, Silkwork), а также связанных с ними проектах Binance Chain. При этом разработчики Erigon разъяснили причины выбора libmdbx, а Ankr Team отметили 30% прирост производительности в сравнении с RocksDB.

Важное отличие этого релиза от предыдущих в вынужденной миграции на GitFlic после блокировки и удаления проекта администрацией GitHub. Кроме этого, разработчики сообщают об устранении множества недочётов и решении проблем со сборками для редких конфигураций. Полный перечень всех значимых доработок доступен в ChangeLog.

Кроме традиционного C API, в libmdbx предлагается развитое C++ API, а также поддерживаемые энтузиастами привязки к языкам Lua, Rust, Haskell, Python, NodeJS, Ruby, Go, Nim, Deno, Scala.

Исторически libmdbx является глубокой переработкой библиотектой LMDBhttps://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database. По утверждению разработчиков, libmdbx превосходит своего прародителя по надёжности, набору возможностей и производительности. Больше внимание уделяется тестированию и автоматическим проверкам.

>>> Подробности

Национальное агентство по цифровизации здравоохранения в Германии Gematik выбрало Matrix в качестве открытого стандарта, на котором будет основан их универсальный стандарт обмена мгновенными сообщениями в здравоохранении – TI-Messenger.

На основе стандарта TI-Messenger агентство Gematik создаст общенациональную децентрализованную сеть связи на основе Matrix для поддержки потенциально более 150000 медицинских организаций в рамках национальной системы здравоохранения Германии. Сеть обеспечит сквозное шифрование аудио/видео звонков и обмена сообщениями для всей системы здравоохранения, а также возможность обмениваться медицинскими данными, изображениями и файлами.

Каждый поставщик медицинских услуг сможет выбрать своего собственного провайдера сервиса TI-Messenger. Домашний сервер для учетных записей может быть размещен в ЦОД провайдера или локально на территории учреждения здравоохранения.

Таким образом, каждая организация и частное лицо сохранят полное владение и контроль над своими данными, при этом имея возможность безопасно делиться ими в системе здравоохранения с помощью сквозного шифрования по умолчанию. Все серверы федерации на основе Matrix будут размещены в Германии.

Излишне говорить, что безопасность является ключевым моментом при поддержке инфраструктуры здравоохранения всей страны и защите конфиденциальных данных пациентов. Таким образом, вся реализация будет аккредитована BSI (Федеральное управление по информационной безопасности) и BfDI (Федеральный комиссар по защите данных и свободе информации).

>>> Подробности

Hunter Wittenborn представил свой проект Debian User Repository. DUR это аналог репозитория AUR (Arch User Repository) для Debian, позволяющий разным людям распространять свои пакеты без включения в основные репозитории Debian. Как и в AUR метаданные и инструкции сборки пакетов в DUR определяются с использованием PKGBUILD. Для того, чтобы собрать такой пакет, нужно воспользоваться утилитой makedeb (аналог утилиты makepkg из Arch Linux). Также, имеется утилита mpm с помощью который можно производить различные манипуляции (загрузка, распаковка) с уже готовыми пакетами из AUR и репозиториев Arch Linux, а утилита makedeb-db поможет с заменой специфических зависимостей. Таким образом, пользователь дистрибутива Debian может легко скачивать и устанавливать пакеты из AUR.

DUR использует систему рейтинга, основанную на голосовании пользователей, специальные метки от проверенных участников, а также цифровые подписи разработчиков, все это в сумме должно уменьшить шанс появления недоброкачественного контента.

Количество пакетов в DUR на момент публикации: 4

DUR является личным проектом и не является официальным подпроектом Debian.

>>> Подробности

Участник GitHub Security Lab Kevin Backhouse обнаружил уязвимость в Polkit, которая впервые появилась семь лет назад в коммите bfa5036 и с версией 0.113 попала в некоторые дистрибутивы. Она позволяет непривилегированному локальному пользователю получить права root в системе, приложив для этого минимальные усилия. Уязвимости подвержены любые дистрибутивы с установленной версией Polkit 0.113 (или более поздней). Например, такие популярные, как RHEL 8 и Ubuntu 20.04. Уязвимость была устранена 3 июня 2021 года.

Как пишет Kevin Backhouse, уязвимость очень просто эксплуатируется, для этого достаточно простых инструментов: bash, kill, и dbus-send. Кроме них, для своей статьи (PoC exploit) он так же использовал accountsservice и gnome-control-center, которые можно найти на многих системах с GUI. Следует заметить, что accountsservice и gnome-control-center не содержат уязвимость и являются просто клиентами для Polkit.

Собственно уязвимость активируется с помощью команды dbus-send (т.е. простой отправки сообщения через шину D-Bus), которую нужно завершить во время, пока Polkit ещё обрабатывает запрос. Теоретически, можно нажать Ctrl + C на клавиатуре в нужный момент, однако Kevin Backhouse не смог продемонстрировать именно такой вариант.

( читать дальше... )

>>> Подробности

ОС: Arch Linux DE: Gnome Графически сервер: Wayland

Установка: чистовая от вчерашнего дня (шаги, которые я проделывал многократно) Проблема: черный экран при загрузке (с мигающим подчеркиванием, ага). Нажимаю Ctrl + Alt + F3 и вхожу через линуксовую консоль, потом переключаюсь на терминал, где висит графика и вместо черного экрана там GDM с полем для ввода пароля.

Вопрос к знатокам: что это?.

Логи gdm:

Apr 05 11:50:45 sergey-desktop systemd[1]: Starting GNOME Display Manager...
Apr 05 11:50:45 sergey-desktop systemd[1]: Started GNOME Display Manager.
Apr 05 11:50:45 sergey-desktop gdm[462]: Gdm: GdmDisplay: Session never registered, failing
Apr 05 11:50:45 sergey-desktop gdm[462]: Gdm: Child process -599 was already dead.
Apr 05 11:50:45 sergey-desktop gdm[462]: Gdm: Child process -599 was already dead.
Apr 05 11:50:46 sergey-desktop gdm[462]: Gdm: Child process -636 was already dead.
Apr 05 11:51:32 sergey-desktop gdm-password][3611]: gkr-pam: unable to locate daemon control file
Apr 05 11:51:32 sergey-desktop gdm-password][3611]: gkr-pam: stashed password to try later in open session
Apr 05 11:51:32 sergey-desktop gdm-password][3611]: pam_systemd_home(gdm-password:account): systemd-homed is not available: Unit dbus-org.freedesktop.home1.service not found.
Apr 05 11:51:32 sergey-desktop gdm-password][3611]: pam_unix(gdm-password:session): session opened for user sergey(uid=1000) by (uid=0)
Apr 05 11:51:32 sergey-desktop gdm-password][3611]: pam_env(gdm-password:session): deprecated reading of user environment enabled
Apr 05 11:51:32 sergey-desktop gdm-password][3611]: gkr-pam: gnome-keyring-daemon started properly and unlocked keyring
Apr 05 11:51:36 sergey-desktop gdm[462]: Gdm: Child process -3325 was already dead.

/

Я ради любопытства решил попробовать помайнить.

Запускаю сервак:

$ geth --http --http.addr 127.0.0.1 --http.port 8545 --datadir /tmp/eth --syncmode "fast" --miner.etherbase 0x7FC1d5e14eD6eB277390458dcCf84639bc42232D

Далее пробую:

λ ethminer -G -P http://127.0.0.1:8545


ethminer 0.18.0
Build: linux/release/gnu

 i 20:03:53 ethminer Configured pool 127.0.0.1:8545
 i 20:03:53 ethminer Selected pool 127.0.0.1:8545
 i 20:03:53 ethminer Established connection to 127.0.0.1:8545
 i 20:03:53 ethminer Spinning up miners...
cl 20:03:53 cl-0     Using PciId : 09:00.0 Ellesmere OpenCL 1.2 AMD-APP (3224.4) Memory : 7.14 GB
 X 20:03:53 ethminer Got code:-32000 message:no mining work available yet  from 127.0.0.1:8545
 m 20:03:58 ethminer 0:00 A0 0.00 h - cl0 0.00
 m 20:04:03 ethminer 0:00 A0 0.00 h - cl0 0.00
 m 20:04:08 ethminer 0:00 A0 0.00 h - cl0 0.00
 m 20:04:13 ethminer 0:00 A0 0.00 h - cl0 0.00
 m 20:04:18 ethminer 0:00 A0 0.00 h - cl0 0.00
 m 20:04:23 ethminer 0:00 A0 0.00 h - cl0 0.00
 X 20:04:23 ethminer Got code:-32000 message:no mining work available yet  from 127.0.0.1:8545

ЧЯДНТ??????????????????????

Советы с пулами мне не подходят. У меня одна видюха и ждать месяц-другой пока намайнишь минималку для вывода не хочу. Хочу намайнить пару баксов на покупку анонимных аккаунтов вконтакте

Вышла новая версия библиотеки и командной утилиты grex 1.2.0, которая позволяет создавать регулярное выражение из предоставленных пользователем тестовых данных. Созданное регулярное выражение имеет синтаксис PCRE.

grex начинался как порт JavaScript-утилиты regexgen и написан на языке программирования Rust.

>>> Подробности

Скрипт архивации тут

# cat /root/do_restore.sh
#!/bin/bash

PORT=5433
USERNAME='dbadmin'
SERVERNAME='localhost'
ARCHIVEDIR='/incrimental'
NEWDBNAME='';
OLDDBNAME='';
ARCHIVEDATE='';
FILETORESTORE=''

if [[ $1 != '' ]]
then
    NEWDBNAME=$1
else
    echo "Enter new DB name as first parametr"
    exit
fi

if [[ $2 != '' ]]
then
    OLDDBNAME=$2
else
    echo "Enter DB name in archive"
    exit
fi

if [[ $3 != '' ]]
then
    ARCHIVEDATE=$3
else
    echo "Enter date in forman YYYY-mm-dd"
    exit
fi

if psql -U $USERNAME -h $SERVERNAME -p $PORT -lqt | cut -d \| -f 1 | grep -qw $NEWDBNAME
then
    echo "Database with this name exists on this cluster"
    exit
fi

DBLIST="$(ls $ARCHIVEDIR/$OLDDBNAME | grep -E "^${OLDDBNAME}.*$ARCHIVEDATE.*(.delta|.dump.gz)\$")"

if [[ "$DBLIST" = '' ]]
then
    echo "There is no file to restore"
    exit
fi


index=1
for var in $DBLIST
do
    echo "${index} $var"
    index=$(($index+1))
done

echo -n "Enter the number of archive in this list "

read answer

index=1
for var in $DBLIST
do
    if [[ $index = $answer ]]
    then
        FILETORESTORE=$var
        echo "$FILETORESTORE"
        break
    fi
    index=$(($index+1))
done

filetype=0

if file $ARCHIVEDIR/$OLDDBNAME/$FILETORESTORE | grep -qw "rdiff network-delta data"
then
    filetype=1
fi

if file $ARCHIVEDIR/$OLDDBNAME/$FILETORESTORE | grep -qw "PostgreSQL custom database dump"
then
    filetype=2
fi

if file $ARCHIVEDIR/$OLDDBNAME/$FILETORESTORE | grep -qw "gzip compressed data"
then
    filetype=3
fi


case "$filetype" in
    1)
        echo "rdiff network-delta data"
        SERIALNUM=$(echo "$FILETORESTORE" | sed 's/^.*'"${OLDDBNAME}"'_//;s/_daily.*//')
        echo $SERIALNUM
        ORIGINAL=$(find $ARCHIVEDIR/$OLDDBNAME/*$SERIALNUM*.dump.gz)
        echo $ORIGINAL
        gunzip -c $ORIGINAL > $ORIGINAL.decompressed
        /usr/bin/rdiff patch $ORIGINAL.decompressed $ARCHIVEDIR/$OLDDBNAME/$FILETORESTORE $ORIGINAL.restored
        rm $ORIGINAL.decompressed
        psql -U $USERNAME -h $SERVERNAME -p $PORT -c 'create database '$NEWDBNAME -d postgres
        psql -h $SERVERNAME -U $USERNAME -p $PORT -d $NEWDBNAME < $ORIGINAL.restored
        rm $ORIGINAL.restored
        ;;
    2)
        echo "PostgreSQL custom database dump"
        psql -U $USERNAME -h $SERVERNAME -p $PORT -c 'create database '$NEWDBNAME -d postgres
        pg_restore -h $SERVERNAME -U $USERNAME -p $PORT -d $NEWDBNAME -w -Fc $ARCHIVEDIR/$OLDDBNAME/$FILETORESTORE
        ;;
    3)
        echo "gzip compressed data"
        psql -U $USERNAME -h $SERVERNAME -p $PORT -c 'create database '$NEWDBNAME -d postgres
        gunzip < $ARCHIVEDIR/$OLDDBNAME/$FILETORESTORE | psql -h $SERVERNAME -U $USERNAME -p $PORT -d $NEWDBNAME
        ;;
    *)
        echo "Undefined file type"
        exit 0
        ;;

Спасибо всем кто помогает

Представим что у нас есть файл размером * 100500 оперативной памяти, находится он на HDD в ext4 фс. Обычное считывание со смещением на N будет происходить так: открываем файл, читаем, считаем прочитанное по байту, если прочитанное равно началу смещения, то помещаем [N:] в буфер и считаем пока прочитанное не станет равно концу смещения [:N].

Допустим у нас есть файл-индекс по полю Name, где записан указатель на начало и конец смещения.

Правильно ли я понимаю процесс считывания?

Правильно ли я понимаю схему выборки?

Какие есть способы хакинга чтобы прочитать N байт из большого файла, где N произвольно или ближе к концу файла?

Немного сумбурно, буду признателен за любые ответы и ссылки. Спасибо.

Опубликован обзор, в котором обобщены все сведения о сертификации ФСТЭК, Минобороны и ФСБ различных дистрибутивов Linux в России в сравнении с операционными системами Windows.

В результате получена весьма любопытная информация: операционные системы Microsoft Windows не могут использоваться для обработки сколько-нибудь важной конфиденциальной информации.

Несмотря на это, во многих госорганах закрывают на это глаза, предпочитая не задумываться о последствиях. В результате мы получаем множественные утечки информации и практически нулевую сохранность персональных данных.

С другой стороны, рядом российских компаний проведена колоссальная работа по созданию на базе операционных систем GNU/Linux действительно надежных российских операционных систем.

К сожалению, информация об этом зачастую оказывается неизвестна не только специалистам, которые интересуются данной проблематикой, но и руководителям государственных органов и госпредприятий, которые несут ответственность за сохранность конфиденциальной информации.

Хотя коммерческие организации всегда стремились применять новейшие технологии и не меньшим образом берегли свои секреты — в России они почему-то существенно отстали даже от консервативных военных.

Работа рекомендуется для компаний по внедрению средств защит информации и оказывающих услуги на рынке аттестации автоматизированных рабочих мест.

Скачать обзор (PDF)

>>> Подробности

привет!

подключился по ssh как root(нужно именно как root) к удаленной машине. на удаленной машине есть xserver, он запущен и работает как надо.

вопрос в том, как в данной ситуации запустить GUI прогу на удаленном компе чтоб она отображалась на удаленном компе?

сейчас получаю ошибку: XOpenDisplay: unable to open display

спасибо.

накидайте классической музыки, эмбиента (можно в сочетании) и киберпанка.
например:
Свиридов - Весна
Jeremy Soule - Dungeon Siege
Juraj Karkus - Portland
что-нибудь динамичное, эмоциональное или атмосферное.

Перемещено tailgunner из desktop

Поступил заказ на изготовление тулзы, которая должна проверить существование имейлов. Для того, чтоб узнать, что ящика нет - устанавливается соединение с нужным smtp-сервером, и говорим, что собираемся отослать письмо такому-то получателю. Ожидается, что в ответ на

rcpt to: recipient@example.com

250 2.1.5 Ok

либо

550 5.1.1 <recipient@example.com>: Recipient address rejected: User unknown in virtual mailbox table

Отслеживать, конечно же, будем код ответа. Если 250 - значит ок (с какой-то долей погрешности), если не 250 - значит считать, что такого пользователя нет. После этого от сервера отключаемся

В исходной хтмл форме будет формироваться десяток возможных вариантов имейла исходя из имени и фамилии пользователя, в идеале надо проверить существование всех вариантов. Предполагается сделать это вебдванольненько, т.е. использовать асинхронные джаваскрипт запрос с группой имейлов, упакованных, скажем, в JSON. А серверная часть должна оптимальным образом без особого палева проверить наличие почтовых адресов и отдать ответ.

А теперь суть вопроса: как лучше лучше всего сделать серверную часть и ее взаимодействие с браузерной? По одному конекту на каждый адрес - глупо. Не хотелось бы таким подозрительным поведением провоцировать бан.

Спросить в пределах одного подключения десяток адресов - отличная идея. Но тогда надо сразу знать все эти десять адресов. Тест гугловых смтп серверов показал, что они отвечают примерно с секундной задержкой. Нехорошо заставлять пользователя ждать целых 10 секунд. Но если приходится, то уж хоть по одному адресу отмечать - прошел он валидацию или нет. Но если получать ответ по каждому имейлу, то тогда придется делать по конекту на каждый имейл.

В общем, непонятна наиболее оптимальная тактика. И не хотелось бы усложнять систему и придумывать себе работу чрезмерно. Хотелось бы просто чтоб заказчику понравилось.

Если создавать новую учётную запись почты например в thunderbird, то иногда он по адресу почты правильно подставляет адрес почтового сервера. Например если domain.ru обслуживается гуглём или яндексом то указываются их почтовые сервера, типа: imap.yandex.com и smtp.yandex.com. При этом mx запись отличается: mx.yandex.net. Впрочем, thunderbird здесь сразу говорит «конфигурация найдена в базе isp в mozilla». По видимому он читает mx запись и по ней находит у себя правильные сервера.

Если мы захотим сделать почту на произвольном домене второго уровня то он подставит mail.domain.ru. Можно предположить что он опирается на mx запись. По крайней мере принятое решение совпадает с ней. Или просто для domain.ru столько раз настраивали почту что он запомнил, а то и внёс в свою базу?

Но когда я сделал домен третьего уровня, определять правильно он перестал. Запись в зоне выглядит так:

subdomain          IN      A       1.2.3.4
subdomain          IN      MX      10 mail2

Хотел сравнить с штатным клиентом андроид но у него вообще никакого автоопределения нет, во всех случаях подставляет в качестве почтового сервера domain.ru. Да, и чтоб два раза не вставать, нет ли возможности для андроида описать настройки в некоем файле и открыть этот файл почтовым клиентом?