Если память не изменяет, главное, чтобы у других пользователей (в смысле other) не было доступа на запись в домашнюю директорию. Мой сетап работает со StrictModes yes.
В описанном сценарии это особо не принципиально. Если у вас отдельный привилегированный пользователь для создания бэкапа на машине, то нет разницы, лежит ли у него ключ файлом или добавлен в агент.
На сервере, где хранятся копии, создаём отдельного пользователя с домашней директорией, и добавляем его в группу chrooted
Для домашней директории выставляем права доступа drwxr-x--x, пользователь и группа — root
В домашней директории создаём каталоги backup с правами drwxr-x-wx и backup-backup с drwx-----, оба также root:root.
В crond на сервере добавляем mv /home/backup-user/backup/* /home/backup-user/backup-backup/
На клиенте, который делает резервное копирование, генерируем уникальный ssh-ключ для этой задачи, добавляем его на сервер
В sshd_config добавляем то, что ниже
Match Group chrooted
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no
GatewayPorts no
X11Forwarding no
PermitUserRC no
Получили в итоге:
Доступ к SSH-консоли отключён, работает только SFTP
По SFTP клиент может зайти только в директорию backup внутри собственной домашней директории, при этом не может сделать листинг файлов в ней (нет +r, есть только +x), а может только «вслепую» загрузить (или прочитать) файл бэкапа. Создание файлов и директорий вне backup невозможно.
Сервер по cron'у перемещает загруженные в backup бэкапы в директорию backup-backup, куда доступа у SSH-клиента нет никакого, чтобы нельзя было изменить или удалить загруженные файлы даже вслепую
Это костыль, но рабочий. Лучше, конечно, применять специализированные решения, изначально рассчитанные на write-only доступ.
Использовать ssh-agent и ключи без паролей в скриптах.
Это плохой совет, потому что стандартный ssh-agent просто предоставляет доступ к ключу, без всяких ограничений и подтверждений. Любое вредоносное ПО на сервере сможет пользоваться ключом подключённого администратора и подключаться к другим серверам.
Лифт это конкретное законченное устройство, не подразумевающее добавления функций, обновлений, особой программной поддержки, да и вообще изменений после внедрения. ПО лифта это только малая часть устройства. Программисту наперёд известны требования: даже если нет технического задания (на примере @BerZerKku), можно взять или купить любой сертифицированный типовой проект и изучить стандарты и требования еще до написания первой строчки кода. Не всегда это бесплатно, но доступно — однозначно.
Для разработки есть стандарты и рекомендации (чек-листы) примерно для всего, начиная от отдельных областей и заканчивая общими методами безопасной разработки (Secure Development Lifecycle, SDLC) в целом, только далеко не каждый о них знает или хочет им следовать.
Многие из стандартов есть не только на бумаге, но и в виде статических анализаторов кода (как отдельное ПО или как набор правил к существующим анализаторам), а чек-листы говорят о конкретных функциях о особенностях, которые должны быть в ПО для safety & security, с примерами кода.
По другую сторону баррикад есть классификация уязвимостей, с подробным описанием каждой проблемы; автоматические сканеры обнаруживают не только задокументированные уязвимости, но и абстрактный класс проблем в целом.
Мы же при создании софта по факту создаём всё равно что тестовый экземпляр, а потом обкатываем его в реальной среде
Чем это отличается от создания автомобиля, где на этапе планирования сначала закладывают необходимые характеристики по безопасности в конструкцию, затем валидируют их в компьютерных симуляциях, затем в собранном прототипе на полигонах и динамометрическом стенде, далее устраивают краш-тесты по стандартам независимой организации, специализирующейся на этом, которая и выдаёт вердикт, соответствует ли прототип выдвигаемым к современному автомобилю требованиям, или нет?
УКЭП-то это подпись, а не шифрование. А вопрос в отправке конфиденциальных данных по публичным каналам. От того, будут ли они подписаны, или нет, ничего не поменяется (скорее даже хуже станет).
Никакого. Производитель наушников установил ограничение битрейта, которое сообщается стороне, воспроизводящей звук — в моем случае это Linux с Pipewire. Патчем Pipewire я отключил учитывание ограничения сообщаемого битрейта, заставив использовать максимально возможный.
Указывать в письме суммы, даты, отправителя подозрительных операций.
Запрещено, потому что для передачи такой информации нельзя использовать открытые каналы связи. Так ВТБ в своё время мне ответил, несмотря на то, что это чуть ли не единственный банк с широким спектром email-уведомлений об операциях. Впрочем, так отвечал не только ВТБ.
производитель там где-то что-то ограничил, то при чём тут PipeWire?
Ограничения учитываются на стороне, которая формирует и отправляет звук. Если их отключить, можно установить любой произвольный битрейт (если нет других сопутствующих ограничений, как MTU в данном случае).
А на ведре как битрейт поднять? Тоже что-то патчить, а что?
В этом и вопрос. В IT почти поголовно ноль ответственности. В иных профессиях с риском навредить себе или другим есть обучение, аккредитация, допуски и разряды; факап чреват уголовной ответственностью. В IT не так: делай почти всё, виноватых нет, максимум начальнику достается. Есть разве что классические сферы с регуляцией, где АО или ПО идёт в дополнение к текущим требованиям (и они на них поэтому также распространяются).
Конкретно здесь человека попросили сделать один из элементов законченного устройства — систему управления. Сертификацию проходит всё изделие целиком, и безопасность достигается в т.ч. fail-safe механикой. Если лифт прошел сертификацию и вводится в эксплуатацию, подразумевается, что и код управления прошел все тесты.
Подумаешь пассажира пополам перерезало, главное не я за это отвечаю - такая риторика ?
Если еще и эксплуатироваться это будет где-то далеко, и пассажир вообще на другом континенте, то абсолютное большинство именно так и думает. Меня по рукам бьют, когда я открываю тему ответственности. Её отсутствие считается преимуществом.
Я не пользовался Recall'ом, но вообще был бы очень рад подобной функции, еще 10 лет назад буквально мечтал о ней во время пентестов. Записывал экран с 6-7 fps, чтобы не забыть ничего во время недельных аудитов, а затем просматривал в 10-кратно ускоренном режиме, и знал, что когда-нибудь смогу просто выполнить «поиск внутри видео».
Ненавижу форматы с битовым (а не байтовым) выравниванием.
Делаете враппер и обрабатываете
SSH_ORIGINAL_COMMAND.Если память не изменяет, главное, чтобы у других пользователей (в смысле other) не было доступа на запись в домашнюю директорию. Мой сетап работает со
StrictModes yes.Это решается
sudo.PermitRootLoginнужен фактически только для единственной функции: туннели (VPN) через sshd (не путать с пробросом портов).В описанном сценарии это особо не принципиально. Если у вас отдельный привилегированный пользователь для создания бэкапа на машине, то нет разницы, лежит ли у него ключ файлом или добавлен в агент.
Я обычно завожу уникальный ключ, которому указываю
command=…(forced command), чтобы этим ключом нельзя было сделать ничего недозволенного.Для резервного копирования по SSH?
На сервере, где хранятся копии, создаём отдельного пользователя с домашней директорией, и добавляем его в группу chrooted
Для домашней директории выставляем права доступа
drwxr-x--x, пользователь и группа — rootВ домашней директории создаём каталоги
backupс правамиdrwxr-x-wxиbackup-backupсdrwx-----, оба такжеroot:root.В crond на сервере добавляем
mv /home/backup-user/backup/* /home/backup-user/backup-backup/На клиенте, который делает резервное копирование, генерируем уникальный ssh-ключ для этой задачи, добавляем его на сервер
В sshd_config добавляем то, что ниже
Получили в итоге:
Доступ к SSH-консоли отключён, работает только SFTP
По SFTP клиент может зайти только в директорию backup внутри собственной домашней директории, при этом не может сделать листинг файлов в ней (нет
+r, есть только+x), а может только «вслепую» загрузить (или прочитать) файл бэкапа. Создание файлов и директорий внеbackupневозможно.Сервер по cron'у перемещает загруженные в
backupбэкапы в директориюbackup-backup, куда доступа у SSH-клиента нет никакого, чтобы нельзя было изменить или удалить загруженные файлы даже вслепуюЭто костыль, но рабочий. Лучше, конечно, применять специализированные решения, изначально рассчитанные на write-only доступ.
Это плохой совет, потому что стандартный ssh-agent просто предоставляет доступ к ключу, без всяких ограничений и подтверждений. Любое вредоносное ПО на сервере сможет пользоваться ключом подключённого администратора и подключаться к другим серверам.
Лифт это конкретное законченное устройство, не подразумевающее добавления функций, обновлений, особой программной поддержки, да и вообще изменений после внедрения.
ПО лифта это только малая часть устройства. Программисту наперёд известны требования: даже если нет технического задания (на примере @BerZerKku), можно взять или купить любой сертифицированный типовой проект и изучить стандарты и требования еще до написания первой строчки кода. Не всегда это бесплатно, но доступно — однозначно.
Для разработки есть стандарты и рекомендации (чек-листы) примерно для всего, начиная от отдельных областей и заканчивая общими методами безопасной разработки (Secure Development Lifecycle, SDLC) в целом, только далеко не каждый о них знает или хочет им следовать.
Многие из стандартов есть не только на бумаге, но и в виде статических анализаторов кода (как отдельное ПО или как набор правил к существующим анализаторам), а чек-листы говорят о конкретных функциях о особенностях, которые должны быть в ПО для safety & security, с примерами кода.
По другую сторону баррикад есть классификация уязвимостей, с подробным описанием каждой проблемы; автоматические сканеры обнаруживают не только задокументированные уязвимости, но и абстрактный класс проблем в целом.
Чем это отличается от создания автомобиля, где на этапе планирования сначала закладывают необходимые характеристики по безопасности в конструкцию, затем валидируют их в компьютерных симуляциях, затем в собранном прототипе на полигонах и динамометрическом стенде, далее устраивают краш-тесты по стандартам независимой организации, специализирующейся на этом, которая и выдаёт вердикт, соответствует ли прототип выдвигаемым к современному автомобилю требованиям, или нет?
УКЭП-то это подпись, а не шифрование. А вопрос в отправке конфиденциальных данных по публичным каналам. От того, будут ли они подписаны, или нет, ничего не поменяется (скорее даже хуже станет).
Битрейт настраивается производителем наушников. А не делать то, что сделал я, приписывает стандарт.
Никакого.
Производитель наушников установил ограничение битрейта, которое сообщается стороне, воспроизводящей звук — в моем случае это Linux с Pipewire. Патчем Pipewire я отключил учитывание ограничения сообщаемого битрейта, заставив использовать максимально возможный.
Может, и еще может использовать PGP, S/MIME или шифрование по стандартам ГОСТ. Только банки этого не делают.
А согласно ответам этого же банка
Запрещено, потому что для передачи такой информации нельзя использовать открытые каналы связи. Так ВТБ в своё время мне ответил, несмотря на то, что это чуть ли не единственный банк с широким спектром email-уведомлений об операциях. Впрочем, так отвечал не только ВТБ.
Ограничения учитываются на стороне, которая формирует и отправляет звук. Если их отключить, можно установить любой произвольный битрейт (если нет других сопутствующих ограничений, как MTU в данном случае).
Bluetooth-стек.
В этом и вопрос. В IT почти поголовно ноль ответственности. В иных профессиях с риском навредить себе или другим есть обучение, аккредитация, допуски и разряды; факап чреват уголовной ответственностью.
В IT не так: делай почти всё, виноватых нет, максимум начальнику достается. Есть разве что классические сферы с регуляцией, где АО или ПО идёт в дополнение к текущим требованиям (и они на них поэтому также распространяются).
Конкретно здесь человека попросили сделать один из элементов законченного устройства — систему управления. Сертификацию проходит всё изделие целиком, и безопасность достигается в т.ч. fail-safe механикой. Если лифт прошел сертификацию и вводится в эксплуатацию, подразумевается, что и код управления прошел все тесты.
Если еще и эксплуатироваться это будет где-то далеко, и пассажир вообще на другом континенте, то абсолютное большинство именно так и думает.
Меня по рукам бьют, когда я открываю тему ответственности. Её отсутствие считается преимуществом.
А почему вы не согласились? На вас какая ответственность?
Так вот же скриншоты
https://t.me/silentcrow_reborn/18
Hidden text
Я не пользовался Recall'ом, но вообще был бы очень рад подобной функции, еще 10 лет назад буквально мечтал о ней во время пентестов. Записывал экран с 6-7 fps, чтобы не забыть ничего во время недельных аудитов, а затем просматривал в 10-кратно ускоренном режиме, и знал, что когда-нибудь смогу просто выполнить «поиск внутри видео».