Большой SLC-кеш, хорошо ли это?
Сегодня основным типом твердотельного накопителя является накопитель с типом ячеек TLC, три бита на одну ячейку. Другой памяти вы в современных дисках не найдете, за исключением QLC – еще более медленной с четырьмя битами на одну ячейку.
Те редкие модели с памятью MLC которые сегодня можно встретить в продаже относятся к устаревшим моделям с интерфейсом SATA и их скоростные характеристики оставляют желать лучшего.
Сама TLC память достаточно медленная, и чтобы улучшить скоростные характеристики накопителя был придуман SLC-кеш.
Сразу скажем, что никакой отдельной памяти для этого кеша нет, просто в SLC-режим переводится часть ячеек накопителя. А так как SLC – это один бит на ячейку, то емкость ячейки падает в три раза для TLC и в четыре для QLC.
Таким образом максимальный объем SLC кеша для TLC не может превышать 33,3% емкости накопителя, а для QLC – 25%.
Режим кеширования производителем не разглашается и зависит от программных настроек прошивки контроллера, но бытует мнение, что чем больше размер кеша, тем лучше. Но это далеко не так. Почему?
Один из распространенных алгоритмов кеширования предусматривает выделение под кеш большого объема, примерно в 30% от свободного объема накопителя.
Что это значит? Это значит, что мы перевели в SLC-режим практически всю память, потому что 30% кеша – это 90% объема.
Да, такой кеш будет поддерживать высокую скорость записи, но по его исчерпанию диску просто становится некуда писать. Поэтому ему приходится одновременно уплотнять запись, переводя SLC-ячейки в TLC-режим и принимать новые данные. При этом скорость записи катастрофически падает, местами до 100 МБ/с и ниже.
Другая стратегия предлагает выделение небольшого объема под кеш 5-10% емкости диска. При этом основная часть ячеек диска остается в режиме TLC и по исчерпании кеша вполне способны обеспечить скорость записи в районе весьма комфортных 400 – 500 МБ/с.
Что из этого лучше? Однозначного мнения тут нет и быть не может. Все зависит от сценариев работы. В первом случае вы сможете принять на полной скорости примерно треть свободного объема диска, но потом получите скорость улитки, попавшей в студень.
Во-втором на полной скорости получится записать лишь небольшой объем данных, но за пределами кеша также будет сохраняться вполне комфортная скорость.
Поэтому если ваши сценарии предусматривают запись значительных объемов данных, то дополнительно будет неплохо почитать обзоры и выяснить алгоритмы кеширования выбранного диска.
При этом помните, что это сугубо программная настройка. И на рынке присутствует множество моделей абсолютно одинаковых аппаратно, но имеющие разные алгоритмы кеширования и, соответственно, разные скоростные характеристики.
Сегодня основным типом твердотельного накопителя является накопитель с типом ячеек TLC, три бита на одну ячейку. Другой памяти вы в современных дисках не найдете, за исключением QLC – еще более медленной с четырьмя битами на одну ячейку.
Те редкие модели с памятью MLC которые сегодня можно встретить в продаже относятся к устаревшим моделям с интерфейсом SATA и их скоростные характеристики оставляют желать лучшего.
Сама TLC память достаточно медленная, и чтобы улучшить скоростные характеристики накопителя был придуман SLC-кеш.
Сразу скажем, что никакой отдельной памяти для этого кеша нет, просто в SLC-режим переводится часть ячеек накопителя. А так как SLC – это один бит на ячейку, то емкость ячейки падает в три раза для TLC и в четыре для QLC.
Таким образом максимальный объем SLC кеша для TLC не может превышать 33,3% емкости накопителя, а для QLC – 25%.
Режим кеширования производителем не разглашается и зависит от программных настроек прошивки контроллера, но бытует мнение, что чем больше размер кеша, тем лучше. Но это далеко не так. Почему?
Один из распространенных алгоритмов кеширования предусматривает выделение под кеш большого объема, примерно в 30% от свободного объема накопителя.
Что это значит? Это значит, что мы перевели в SLC-режим практически всю память, потому что 30% кеша – это 90% объема.
Да, такой кеш будет поддерживать высокую скорость записи, но по его исчерпанию диску просто становится некуда писать. Поэтому ему приходится одновременно уплотнять запись, переводя SLC-ячейки в TLC-режим и принимать новые данные. При этом скорость записи катастрофически падает, местами до 100 МБ/с и ниже.
Другая стратегия предлагает выделение небольшого объема под кеш 5-10% емкости диска. При этом основная часть ячеек диска остается в режиме TLC и по исчерпании кеша вполне способны обеспечить скорость записи в районе весьма комфортных 400 – 500 МБ/с.
Что из этого лучше? Однозначного мнения тут нет и быть не может. Все зависит от сценариев работы. В первом случае вы сможете принять на полной скорости примерно треть свободного объема диска, но потом получите скорость улитки, попавшей в студень.
Во-втором на полной скорости получится записать лишь небольшой объем данных, но за пределами кеша также будет сохраняться вполне комфортная скорость.
Поэтому если ваши сценарии предусматривают запись значительных объемов данных, то дополнительно будет неплохо почитать обзоры и выяснить алгоритмы кеширования выбранного диска.
При этом помните, что это сугубо программная настройка. И на рынке присутствует множество моделей абсолютно одинаковых аппаратно, но имеющие разные алгоритмы кеширования и, соответственно, разные скоростные характеристики.
👍12❤3
Укажите наиболее часто используемый, можно выбрать несколько вариантов
Anonymous Poll
32%
VMware
29%
Hyper‑V
64%
Proxmox VE
10%
Linux KVM
1%
XenServer
1%
XCP-ng
5%
Российские гипервизоры
1%
Bhyve
1%
Другое (напишу в комментариях)
5%
Просто посмотреть ответы
👍2❤1
Завершающий слеш в путях Linux
Данному вопросу часто не уделяют должного внимания и зря, он не так прост, как кажется, поэтому мы решили уделить ему отдельную заметку.
В Linux символом разделения каталогов является слеш, если после имени файла стоит этот символ, то подразумевается, что данный файл является каталогом. А в Linux, как мы помним, всё есть файл.
Также в Linux очень часто обходятся без расширения имен файлов, потому как тип файла определяется по содержимому (сейчас мы не берем во внимание графические оболочки). Поэтому запись:
Может быть как файлом, так и каталогом. Если же мы напишем так, то перед нами предположительно каталог:
Почему предположительно? Потому что мы можем написать слеш и после имени файла, но если мы попробуем выполнить с ним любую файловую операцию, то система выдаст нам ошибку, потому как данный файл не является каталогом.
Т.е. закрывающий слеш – не императив, а всего лишь указатель на предполагаемый тип файла. Его отсутствие вызывает состояние неопределенности, что может привести к некоторым казусам.
Например, в нашем скрипте написано в цикле что-то вроде:
Данная конструкция имеет неопределенность, потому что если мы забудем создать папку
Если же мы напишем:
То при отсутствии директории получим ошибку:
Если же мы попробуем указать вместо каталога обычный файл, например, там действительно существует файл
Т.е. систему не обмануть, и она всегда при файловой операции проверит тип файла, независимо от того поставили вы закрывающий слеш или нет.
Но наличие слеша устраняет неопределенность, потому что явно предписывает системе работать с путем как с каталогом и никак иначе. Кстати, при автоподстановке по Tab пути к каталогам сразу дополняются закрывающим слешем.
Достаточно ли просто добавить завершающий слеш в путь скрипта? А вот здесь все не так просто. Да, мы уберем неопределенность, да получим ошибку. Но что, если это случится уже после того, как скрипт отлажен и запущен в работу? Допустим целевой каталог переместили, переименовали или удалили?
В этом случае мы получим ошибку, запишем ее в лог и дальше? А дальше вопрос, когда именно администратор его прочитает. Ведь все мы любим читать логи за чашкой утреннего кофе, не правда-ли?
Поэтому в скриптах такие вещи всегда лучше проверять явно, например:
В данном случае мы проверили существование каталога и создали его при отсутствии, но никто не мешает выполнить и другие действия, скажем, направить сообщение на почту администратора и прекратить работу скрипта.
В любом случае это лучше, чем просто получить ошибку (или даже многочисленные ошибки) выполнения с записью в лог.
А после того, как мы выполнили подобную проверку и предприняли явные действия, то там уже становится все равно, есть закрывающий слеш в команде перемещения или нет.
Данному вопросу часто не уделяют должного внимания и зря, он не так прост, как кажется, поэтому мы решили уделить ему отдельную заметку.
В Linux символом разделения каталогов является слеш, если после имени файла стоит этот символ, то подразумевается, что данный файл является каталогом. А в Linux, как мы помним, всё есть файл.
Также в Linux очень часто обходятся без расширения имен файлов, потому как тип файла определяется по содержимому (сейчас мы не берем во внимание графические оболочки). Поэтому запись:
~/video
Может быть как файлом, так и каталогом. Если же мы напишем так, то перед нами предположительно каталог:
~/video/
Почему предположительно? Потому что мы можем написать слеш и после имени файла, но если мы попробуем выполнить с ним любую файловую операцию, то система выдаст нам ошибку, потому как данный файл не является каталогом.
Т.е. закрывающий слеш – не императив, а всего лишь указатель на предполагаемый тип файла. Его отсутствие вызывает состояние неопределенности, что может привести к некоторым казусам.
Например, в нашем скрипте написано в цикле что-то вроде:
mv -f "$file" /new_path/video
Данная конструкция имеет неопределенность, потому что если мы забудем создать папку
video, то все файлы будут перемещены в новый файл video и последовательно его перезапишут. Т.е. мы останемся без видео, у нас сохранится только последний файл.Если же мы напишем:
mv -f "$file" /new_path/video/
То при отсутствии директории получим ошибку:
mv: невозможно создать обычный файл ' video/': Это не каталог
Если же мы попробуем указать вместо каталога обычный файл, например, там действительно существует файл
video, скажем как результат предыдущего ошибочного запуска скрипта, то ошибка будет иной:mv: не удалось получить доступ к ' video /': Это не каталог
Т.е. систему не обмануть, и она всегда при файловой операции проверит тип файла, независимо от того поставили вы закрывающий слеш или нет.
Но наличие слеша устраняет неопределенность, потому что явно предписывает системе работать с путем как с каталогом и никак иначе. Кстати, при автоподстановке по Tab пути к каталогам сразу дополняются закрывающим слешем.
Достаточно ли просто добавить завершающий слеш в путь скрипта? А вот здесь все не так просто. Да, мы уберем неопределенность, да получим ошибку. Но что, если это случится уже после того, как скрипт отлажен и запущен в работу? Допустим целевой каталог переместили, переименовали или удалили?
В этом случае мы получим ошибку, запишем ее в лог и дальше? А дальше вопрос, когда именно администратор его прочитает. Ведь все мы любим читать логи за чашкой утреннего кофе, не правда-ли?
Поэтому в скриптах такие вещи всегда лучше проверять явно, например:
if ! [ -d /new_path/video/ ]; then
mkdir -p /new_path/video
fi
В данном случае мы проверили существование каталога и создали его при отсутствии, но никто не мешает выполнить и другие действия, скажем, направить сообщение на почту администратора и прекратить работу скрипта.
В любом случае это лучше, чем просто получить ошибку (или даже многочисленные ошибки) выполнения с записью в лог.
А после того, как мы выполнили подобную проверку и предприняли явные действия, то там уже становится все равно, есть закрывающий слеш в команде перемещения или нет.
👍19👌5❤4🔥2
Самозаверенные сертификаты. Мифы и реальность.
Самозаверенные, они же самозаверяющие или самоподписанные сертификаты являются предметом многих расхожих мифов. Основной их смысл сводится к тому, что такие сертификаты жутко небезопасны и выставить наружу ресурс с таким сертификатом – это все равно, что без сертификата вообще.
Но это мнение не имеет под собой никакого основания, так как сертификат сам по себе не определяет стойкость шифрования — за выбор протоколов и шифронаборов отвечают настройки сервера и клиента.
Кроме того, следует помнить, что выбор шифра – процесс обоюдный и недаром называется согласованием. В процессе установления соединения клиент получает от сервера список поддерживаемых шифров и выбирает самый стойкий из тех, которые поддерживает сам.
Если клиент не поддерживает ни один из предложенных шифров, то соединение установить не удастся. Но и наоборот, существуют специальные атаки на понижение шифрования, цель которых согласовать старый и нестойкий шифр. Поэтому предлагаемый набор шифров — это всегда компромисс между совместимостью и безопасностью.
Так мы можем иметь «настоящий» сертификат и слабый набор шифров ради обеспечения совместимости с устаревшими клиентами или, наоборот, самоподписанный сертификат с небольшим набором самых современных криптографических алгоритмов. И вторая система будет обеспечивать гораздо более высокий уровень безопасности чем первая.
Так чем же плох самоподписанный сертификат? Тем, что с ним невозможно установить отношения доверия, которые являются ключевыми во всей современной криптографии. Проще говоря, устанавливая защищенное соединение мы хотим быть уверены, что сертификат действительно принадлежит указанному владельцу, а не третьему лицу.
Чтобы помочь нам в этом вопросе существуют центры сертификации, авторитет которых не подлежит сомнению, и, если сертификат подписан одним из этих CA, то доверие к центру сертификации распространяется на сертификат, и мы тоже можем ему доверять.
Для проверки доверия все центры сертификации выпускают собственные корневые сертификаты, которые позволяют убедиться, что сертификат выпущен именно этим издателем.
Корневые сертификаты известных издателей распространяются вместе с ОС и хранятся в особом системном хранилище, исключающем их случайную подмену.
Здесь существует один парадокс. Корневой сертификат удостоверяющего центра не является секретным, но доступ к нему в системе должен быть ограничен, так как в противном случае возможна атака типа человек посередине, и вы автоматически примете сертификат, подписанный злоумышленником.
По этой же причине требуется крайне внимательно относиться к сертификатам, которые вы устанавливаете в качестве доверенных корневых центров сертификации, так как после его установки вы будете автоматически доверять всем сертификатам, выпущенным этим центром.
Также не следует путать самозаверенные сертификаты с сертификатами частных центров сертификации, например, корпоративным CA. С последними можно легко установить доверительные отношения (если вы действительно им доверяете) просто установив в систему нужный корневой сертификат.
Самозаверенный сертификат не имеет доверенного центра сертификации в цепочке и доверительные отношения с ним установить не удастся, все, что мы можем – это добавить его в исключения, чтобы не получать уведомлений системы безопасности.
Но это нужно сделать на каждой системе, при этом обязательно проверив, тот ли это сертификат по отпечатку подписи. Но это способен сделать далеко не каждый пользователь и на практике даже добавления в исключения часто не происходит. Чаще всего предупреждение безопасности просто игнорируется, что является крайне плохой практикой, так как вам спокойно могут подменить сертификат, а вы даже не заметите.
Подведем итог: самозаверенный сертификат с точки зрения шифрования столь же безопасен, как и любой другой. Основная его проблема – это невозможность установить доверительные отношения и однозначно доверять ему без дополнительных проверок.
Самозаверенные, они же самозаверяющие или самоподписанные сертификаты являются предметом многих расхожих мифов. Основной их смысл сводится к тому, что такие сертификаты жутко небезопасны и выставить наружу ресурс с таким сертификатом – это все равно, что без сертификата вообще.
Но это мнение не имеет под собой никакого основания, так как сертификат сам по себе не определяет стойкость шифрования — за выбор протоколов и шифронаборов отвечают настройки сервера и клиента.
Кроме того, следует помнить, что выбор шифра – процесс обоюдный и недаром называется согласованием. В процессе установления соединения клиент получает от сервера список поддерживаемых шифров и выбирает самый стойкий из тех, которые поддерживает сам.
Если клиент не поддерживает ни один из предложенных шифров, то соединение установить не удастся. Но и наоборот, существуют специальные атаки на понижение шифрования, цель которых согласовать старый и нестойкий шифр. Поэтому предлагаемый набор шифров — это всегда компромисс между совместимостью и безопасностью.
Так мы можем иметь «настоящий» сертификат и слабый набор шифров ради обеспечения совместимости с устаревшими клиентами или, наоборот, самоподписанный сертификат с небольшим набором самых современных криптографических алгоритмов. И вторая система будет обеспечивать гораздо более высокий уровень безопасности чем первая.
Так чем же плох самоподписанный сертификат? Тем, что с ним невозможно установить отношения доверия, которые являются ключевыми во всей современной криптографии. Проще говоря, устанавливая защищенное соединение мы хотим быть уверены, что сертификат действительно принадлежит указанному владельцу, а не третьему лицу.
Чтобы помочь нам в этом вопросе существуют центры сертификации, авторитет которых не подлежит сомнению, и, если сертификат подписан одним из этих CA, то доверие к центру сертификации распространяется на сертификат, и мы тоже можем ему доверять.
Для проверки доверия все центры сертификации выпускают собственные корневые сертификаты, которые позволяют убедиться, что сертификат выпущен именно этим издателем.
Корневые сертификаты известных издателей распространяются вместе с ОС и хранятся в особом системном хранилище, исключающем их случайную подмену.
Здесь существует один парадокс. Корневой сертификат удостоверяющего центра не является секретным, но доступ к нему в системе должен быть ограничен, так как в противном случае возможна атака типа человек посередине, и вы автоматически примете сертификат, подписанный злоумышленником.
По этой же причине требуется крайне внимательно относиться к сертификатам, которые вы устанавливаете в качестве доверенных корневых центров сертификации, так как после его установки вы будете автоматически доверять всем сертификатам, выпущенным этим центром.
Также не следует путать самозаверенные сертификаты с сертификатами частных центров сертификации, например, корпоративным CA. С последними можно легко установить доверительные отношения (если вы действительно им доверяете) просто установив в систему нужный корневой сертификат.
Самозаверенный сертификат не имеет доверенного центра сертификации в цепочке и доверительные отношения с ним установить не удастся, все, что мы можем – это добавить его в исключения, чтобы не получать уведомлений системы безопасности.
Но это нужно сделать на каждой системе, при этом обязательно проверив, тот ли это сертификат по отпечатку подписи. Но это способен сделать далеко не каждый пользователь и на практике даже добавления в исключения часто не происходит. Чаще всего предупреждение безопасности просто игнорируется, что является крайне плохой практикой, так как вам спокойно могут подменить сертификат, а вы даже не заметите.
Подведем итог: самозаверенный сертификат с точки зрения шифрования столь же безопасен, как и любой другой. Основная его проблема – это невозможность установить доверительные отношения и однозначно доверять ему без дополнительных проверок.
👍14🥱2❤1
И снова про отечественные сертификаты
Осень еще не наступила, а очередное осеннее обострение уже началось. С завидной регулярностью отдельные товарищи начинают разгонять очередную дичь про сертификаты Мицифры.
Мол какое может быть доверие этим сертификатам и этому CA если… (тут можете вписать любой набор стандартных пугалок), в отличие от коммерческих западных CA, которые прозрачны, контролируемы, регулируемы и т.д. и т.п.
Сразу начнем с того, что все взаимодействия в инфраструктуре открытых ключей (PKI) строятся на основании отношений доверия и ключевые участники этого рынка такими отношениями сильно дорожат.
Но все ли так светло и радужно? Нет, достаточно вспомнить историю с WoSign и StartCom, которые творили лютую дичь, включая выпуск сертификатов задним числом и крайне слабые проверки действительного владельца домена.
За ним последовал Symantec, тоже не последний игрок на рынке, и хотя его прегрешения были куда попроще, но это ему тоже не помогло.
Поэтому ни покровительство Минцифры, ни какие иные административные факторы не помогут отечественному CA удержать отношения доверия если он вдруг влипнет в какую-нибудь нехорошую историю.
И инициаторами вынесения вотума недоверия будет не общественность и не активисты, а крупные игроки этого рынка, пользующиеся его услугами, тот же Сбербанк.
Так что мы не видим никаких разумных предпосылок не доверять сертификатам Минцифры по различным надуманным причинам.
Но это была теория, а теперь перейдем к практике. Основная пугалка адептов секты свидетелей Товарища Майора гласит, что сразу после установки сертификата вы делаете весь свой трафик доступным тому самому Товарищу Майору.
Так ли это? Конечно же не так. Что делает удостоверяющий центр Минцифры выдавая сертификат тому же Сбербанку? Прежде всего он удостоверяется, что за сертификатом пришел именно Сбербанк и подписывает выданный сертификат своим закрытым ключом.
Теперь каждый у кого есть открытый ключ (сертификат) Минцифры может проверить подлинность этого сертификата и начать доверять ему, так как мы доверяем удостоверяющему центру, выдавшему сертификат.
Может ли теперь Минцифры расшифровать трафик, зашифрованный этим сертификатом? Нет! Сделать этот может только владелец закрытого ключа, т.е. Сбербанк. Для получения сертификата закрытый ключ удостоверяющему центру предоставлять не нужно.
Но в реальности все еще более интересно, открыв свойства защищенного соединения в браузере, например, для того же Сбербанка, мы увидим строку наподобие:
Это означает, что для формирования сеансового ключа, которым зашифрован канал связи используется алгоритм Диффи-Хеллмана, который позволяет формировать динамические ключи шифрования обоими сторонами без передачи их по каналам связи.
Сеансовые ключи являются одноразовыми и нигде не сохраняются. Это называется совершенная прямая секретность и не позволяет расшифровать записанный сеанс связи даже получив доступ к закрытому ключу владельца сертификата.
Говорить про возможный MitM тем более несерьезно, потому что такое решение должно приниматься на самом высоком уровне и для этого нужны крайне серьезные основания. Плюс не забываем о возможных негативных последствиях со стороны других крупных игроков рынка.
При том, что этот самый MitM давно уже существует на ПК многих и многих пользователей совершенно легально и с их ведома, но почему-то это никого не интересует и не создает такого ажиотажа.
Да, мы про антивирусное ПО, которое имеет функцию проверки трафика на лету, для чего устанавливает собственный доверенный сертификат и делает все тоже самое, в чем пытаются безосновательно обвинить Минцифры.
Хотя потенциальному Товарищу Майору гораздо проще пойти договориться с Касперским, чем мутить с нуля свой собственный MitM.
Поэтому – будьте благоразумны, удостоверяющий центр Минцифры ничем не отличается от любого другого удостоверяющего центра и использование его несет одинаковые с ними угрозы. При том, как мы видели выше, коммерческие УЦ тоже далеко не образцы для подражания.
Осень еще не наступила, а очередное осеннее обострение уже началось. С завидной регулярностью отдельные товарищи начинают разгонять очередную дичь про сертификаты Мицифры.
Мол какое может быть доверие этим сертификатам и этому CA если… (тут можете вписать любой набор стандартных пугалок), в отличие от коммерческих западных CA, которые прозрачны, контролируемы, регулируемы и т.д. и т.п.
Сразу начнем с того, что все взаимодействия в инфраструктуре открытых ключей (PKI) строятся на основании отношений доверия и ключевые участники этого рынка такими отношениями сильно дорожат.
Но все ли так светло и радужно? Нет, достаточно вспомнить историю с WoSign и StartCom, которые творили лютую дичь, включая выпуск сертификатов задним числом и крайне слабые проверки действительного владельца домена.
За ним последовал Symantec, тоже не последний игрок на рынке, и хотя его прегрешения были куда попроще, но это ему тоже не помогло.
Поэтому ни покровительство Минцифры, ни какие иные административные факторы не помогут отечественному CA удержать отношения доверия если он вдруг влипнет в какую-нибудь нехорошую историю.
И инициаторами вынесения вотума недоверия будет не общественность и не активисты, а крупные игроки этого рынка, пользующиеся его услугами, тот же Сбербанк.
Так что мы не видим никаких разумных предпосылок не доверять сертификатам Минцифры по различным надуманным причинам.
Но это была теория, а теперь перейдем к практике. Основная пугалка адептов секты свидетелей Товарища Майора гласит, что сразу после установки сертификата вы делаете весь свой трафик доступным тому самому Товарищу Майору.
Так ли это? Конечно же не так. Что делает удостоверяющий центр Минцифры выдавая сертификат тому же Сбербанку? Прежде всего он удостоверяется, что за сертификатом пришел именно Сбербанк и подписывает выданный сертификат своим закрытым ключом.
Теперь каждый у кого есть открытый ключ (сертификат) Минцифры может проверить подлинность этого сертификата и начать доверять ему, так как мы доверяем удостоверяющему центру, выдавшему сертификат.
Может ли теперь Минцифры расшифровать трафик, зашифрованный этим сертификатом? Нет! Сделать этот может только владелец закрытого ключа, т.е. Сбербанк. Для получения сертификата закрытый ключ удостоверяющему центру предоставлять не нужно.
Но в реальности все еще более интересно, открыв свойства защищенного соединения в браузере, например, для того же Сбербанка, мы увидим строку наподобие:
Key exchange ECDHE_RSA with P-256Это означает, что для формирования сеансового ключа, которым зашифрован канал связи используется алгоритм Диффи-Хеллмана, который позволяет формировать динамические ключи шифрования обоими сторонами без передачи их по каналам связи.
Сеансовые ключи являются одноразовыми и нигде не сохраняются. Это называется совершенная прямая секретность и не позволяет расшифровать записанный сеанс связи даже получив доступ к закрытому ключу владельца сертификата.
Говорить про возможный MitM тем более несерьезно, потому что такое решение должно приниматься на самом высоком уровне и для этого нужны крайне серьезные основания. Плюс не забываем о возможных негативных последствиях со стороны других крупных игроков рынка.
При том, что этот самый MitM давно уже существует на ПК многих и многих пользователей совершенно легально и с их ведома, но почему-то это никого не интересует и не создает такого ажиотажа.
Да, мы про антивирусное ПО, которое имеет функцию проверки трафика на лету, для чего устанавливает собственный доверенный сертификат и делает все тоже самое, в чем пытаются безосновательно обвинить Минцифры.
Хотя потенциальному Товарищу Майору гораздо проще пойти договориться с Касперским, чем мутить с нуля свой собственный MitM.
Поэтому – будьте благоразумны, удостоверяющий центр Минцифры ничем не отличается от любого другого удостоверяющего центра и использование его несет одинаковые с ними угрозы. При том, как мы видели выше, коммерческие УЦ тоже далеко не образцы для подражания.
👍30🤡14❤3🤔3🥱3
Включаем отображение Samba-сервера в сетевом окружении Windows
Если вы используете Samba для организации общих файловых ресурсов, то, наверное, заметили, что в последних версиях Windows такие сервера больше не отображаются в сетевом окружении, хотя нормально работают при прямом подключении к ним.
Это связано с полным отказом в Windows от использования протокола SMB1 и невозможностью обнаружить Samba по протоколу NetBIOS. Современные Windows системы используют для обнаружения устройств WSD (Web Services for Devices) и сегодня мы расскажем, как добавить его поддержку для вашего сервера Samba.
✅ Читать далее: https://interface31.ru/post/vklyuchaem-otobrazhenie-samba-servera-v-setevom-okruzhenii-windows/
Если вы используете Samba для организации общих файловых ресурсов, то, наверное, заметили, что в последних версиях Windows такие сервера больше не отображаются в сетевом окружении, хотя нормально работают при прямом подключении к ним.
Это связано с полным отказом в Windows от использования протокола SMB1 и невозможностью обнаружить Samba по протоколу NetBIOS. Современные Windows системы используют для обнаружения устройств WSD (Web Services for Devices) и сегодня мы расскажем, как добавить его поддержку для вашего сервера Samba.
✅ Читать далее: https://interface31.ru/post/vklyuchaem-otobrazhenie-samba-servera-v-setevom-okruzhenii-windows/
1👍17
Результат опроса – гипервизоры
❗️Важное предупреждение! Так как в опросе был доступен выбор нескольких вариантов общая сумма процентов будет превышать 100%. Это особенность такого рода опросов и не является ошибкой.
Виртуализация сегодня давно не экзотика, а самая обычная повседневная технология и достаточно интересно посмотреть, как распределяются пользовательские предпочтения.
Обошлось без неожиданностей – лидером опроса стал Proxmox VE, это современное и зрелое решение, к тому же бесплатное. Фактически, несмотря на наличие различных альтернатив, выбирать кроме Proxmox нечего.
Когда мы берем в качестве решения бесплатный софт, то сразу понимаем – поддержка ложится целиком и полностью на наши плечи. Поэтому на первый план выходит наличие информации по продукту в сети и существование активных сообществ, желательно русскоязычных.
У Proxmox это все есть и благодаря этому он законно удерживает пальму первенства. А с учетом наличия готовой экосистемы – собственного решения для бекапов, он становится крайне привлекательным и фактически претендует на роль отраслевого стандарта де-факто.
Куда более скромные значения имеют решения от VMware и Microsoft Hyper-V. Первых подкосила агрессивная политика нового владельца – Broadcom, которые фактически кинули всех клиентов с «вечными» лицензиями и перевели продукт на подписную модель.
Сегодня владельцы VMware – это либо унаследованные системы, оставшиеся без поддержки, либо пираты, которых этот вопрос не волнует, но до поры, до времени.
Hyper-V тоже находится в подвисшей ситуации, бесплатный Hyper-V Server закончился на версии 2019 и его поддержка заканчивается в 2029 году. Альтернатива – покупка Windows Server, в котором Hyper-V как роль продолжает поддерживаться.
Но зачем? Функционально это самый слабый гипервизор и самый сложный в эксплуатации, требующий глубокой интеграции в экосистему Microsoft. Например, вы не сможете настроить HA-кластер Hyper-V без наличия Active Directory.
Поэтому такие системы в большинстве тоже унаследованные и перед ними стоит вопрос миграции на что-то более современное и поддерживаемое.
Некоторую долю систем занимает чистый KVM, такой подход вполне имеет право на существование, особенно если виртуалок вам нужно совсем немного. Ставить для этого Proxmox – это пустая трата ресурсов, но это решение не для серьезных продуктивных систем.
А дальше идет все то, что мы говорили про Proxmox, при внедрении открытых решений важно наличие активных сообществ и информации в целом. Поэтому ни XenServer, ни его форк XCP-ng не получили никакой ощутимой доли голосов в опросе.
Да, это технологически неплохие решения, но редко кто рискнет внедрять у себя непопулярный продукт, потому что в случае чего информацию придется искать по крупицам и не факт, что она найдется. А инфраструктура стоит.
Включая в опрос Bhyve, мы также не ожидали какого-либо результата и оказались правы, сегодня BSD системы в качестве хостов виртуализации не могут предложить совсем ничего конкурентного, время упущено, поезд ушел.
Российские гипервизоры – тоже отдельный разговор, их выбор – это в подавляющем большинстве случаев требование регуляторов и выбора там как такового нет. Потому что если вы используете для импортозамещения системы какого-либо вендора, то и гипервизор будет от него же.
Ну и прочие альтернативы – их нет, пользователей всякой экзотики кое-как набралось на один процент, что никакой погоды не делает.
🤔 А с какого гипервизора и куда вы переехали (или планируете переезжать) за последние два года?
❗️Важное предупреждение! Так как в опросе был доступен выбор нескольких вариантов общая сумма процентов будет превышать 100%. Это особенность такого рода опросов и не является ошибкой.
Виртуализация сегодня давно не экзотика, а самая обычная повседневная технология и достаточно интересно посмотреть, как распределяются пользовательские предпочтения.
Обошлось без неожиданностей – лидером опроса стал Proxmox VE, это современное и зрелое решение, к тому же бесплатное. Фактически, несмотря на наличие различных альтернатив, выбирать кроме Proxmox нечего.
Когда мы берем в качестве решения бесплатный софт, то сразу понимаем – поддержка ложится целиком и полностью на наши плечи. Поэтому на первый план выходит наличие информации по продукту в сети и существование активных сообществ, желательно русскоязычных.
У Proxmox это все есть и благодаря этому он законно удерживает пальму первенства. А с учетом наличия готовой экосистемы – собственного решения для бекапов, он становится крайне привлекательным и фактически претендует на роль отраслевого стандарта де-факто.
Куда более скромные значения имеют решения от VMware и Microsoft Hyper-V. Первых подкосила агрессивная политика нового владельца – Broadcom, которые фактически кинули всех клиентов с «вечными» лицензиями и перевели продукт на подписную модель.
Сегодня владельцы VMware – это либо унаследованные системы, оставшиеся без поддержки, либо пираты, которых этот вопрос не волнует, но до поры, до времени.
Hyper-V тоже находится в подвисшей ситуации, бесплатный Hyper-V Server закончился на версии 2019 и его поддержка заканчивается в 2029 году. Альтернатива – покупка Windows Server, в котором Hyper-V как роль продолжает поддерживаться.
Но зачем? Функционально это самый слабый гипервизор и самый сложный в эксплуатации, требующий глубокой интеграции в экосистему Microsoft. Например, вы не сможете настроить HA-кластер Hyper-V без наличия Active Directory.
Поэтому такие системы в большинстве тоже унаследованные и перед ними стоит вопрос миграции на что-то более современное и поддерживаемое.
Некоторую долю систем занимает чистый KVM, такой подход вполне имеет право на существование, особенно если виртуалок вам нужно совсем немного. Ставить для этого Proxmox – это пустая трата ресурсов, но это решение не для серьезных продуктивных систем.
А дальше идет все то, что мы говорили про Proxmox, при внедрении открытых решений важно наличие активных сообществ и информации в целом. Поэтому ни XenServer, ни его форк XCP-ng не получили никакой ощутимой доли голосов в опросе.
Да, это технологически неплохие решения, но редко кто рискнет внедрять у себя непопулярный продукт, потому что в случае чего информацию придется искать по крупицам и не факт, что она найдется. А инфраструктура стоит.
Включая в опрос Bhyve, мы также не ожидали какого-либо результата и оказались правы, сегодня BSD системы в качестве хостов виртуализации не могут предложить совсем ничего конкурентного, время упущено, поезд ушел.
Российские гипервизоры – тоже отдельный разговор, их выбор – это в подавляющем большинстве случаев требование регуляторов и выбора там как такового нет. Потому что если вы используете для импортозамещения системы какого-либо вендора, то и гипервизор будет от него же.
Ну и прочие альтернативы – их нет, пользователей всякой экзотики кое-как набралось на один процент, что никакой погоды не делает.
🤔 А с какого гипервизора и куда вы переехали (или планируете переезжать) за последние два года?
👍10❤4
С днем рождения Linux!
25 августа 1991 года в рассылке новостей группы пользователей OC MINIX появилось сообщение:
Вряд ли кто-то тогда мог подумать, что оно серьезно изменит компьютерный мир уже в течении этого десятилетия. Простой студенческий проект никому не известного финского парня…
Изначально система должна была называться Freax, но Ари Лемке, который предоставил место для проекта на своем FTP сервере назвал каталог pub/OS/Linux, которое и закрепилось в качестве названия системы.
Важной вехой в развитии системы стала кооперация с проектом GNU, который еще с 1983 года под руководством Ричарда Столлмана занимался созданием полностью открытой и свободной операционной системы.
К 1991 году у Столлмана было практически все, что нужно, кроме ядра. Собственные попытки разработать ядро Hurd не привели к успеху (причем до сих пор) и тут появилось ядро, которому как раз нужно было прикладное ПО.
Уже через год начали появляться первые дистрибутивы, так в 1992 году увидел свет Slackware Патрика Фолькердинга, а в 1993 Debian Яна Мёрдока, в 1994 появились S.U.S.E и Red Hat.
В этом же году увидело свет ядро 1.0.0 содержавшее 176 250 строчек кода, а уже в 1996 была выпущена версия 2.0, началась эпоха стремительного развития молодой системы.
В этом же году появился официальный талисман системы – пингвин Tux, его нарисовал Ларри Юинг. Слово Tux придумал Джеймз Хьюз, соединив два слова: (T)orvalds (U)ni(X).
В 1998 году Матиас Эттрих представил первый выпуск KDE, которая предлагала законченную среду рабочего стола с набором программ базировавшуюся на Qt, а годом позже Мигель де Иказа и Федерико Мен выпустили первую версию GNOME на GTK+.
Менее чем за 10 лет Linux прошел путь от небольшого студенческого проекта до полноценной ОС с графической оболочкой.
В дальнейшем система продолжила развиваться и занимать новые ниши, так уже в 2002 году увидел свет Red Hat Enterprise Linux.
Домашние пользователи тоже не остались без внимания, в 1998 году появился Mandrake Linux, позже Mandriva – один из самых дружелюбных дистрибутивов того времени.
В это же время появился дистрибутив Linux-Mandrake Russian Edition, который впоследствии занялся полностью собственной разработкой и теперь мы его знаем как ALT Linux.
А сам Mandrake/Mandriva прошел сложный путь, несколько раз менял владельца пока не превратился в ROSA Linux.
Еще одно знаковое событие произошло в 2004 году, с выходом дистрибутива Ubuntu Linux, который сделал систему ближе в прямом и переносном смысле.
В те времена широкополосный интернет был еще дорог и труднодоступен, поэтому Canonical рассылала диски с Ubuntu почтой бесплатно в любую точку земного шара.
А дальше вы и так, наверное, все знаете, размер заметки не позволяет продолжать наше повествование. Поэтому еще раз вспомним как все начиналось и поздравим Linux c днем рождения.
25 августа 1991 года в рассылке новостей группы пользователей OC MINIX появилось сообщение:
всем пользователям minix!
Я пишу (бесплатную) операционную систему (это просто хобби, ничего большого и профессионального вроде gnu) для AT 386(486). Я вожусь с этим с апреля, и она, похоже, скоро будет готова. Напишите мне, кому что нравится/не нравится в minix, поскольку моя ОС на неё похожа (кроме всего прочего, у неё — по практическим соображениям — то же физическое размещение файловой системы).
Пока что я перенёс в неё bash (1.08) и gсс (1.40), и всё вроде работает. Значит, в ближайшие месяцы у меня получится уже что-то работающее, и мне бы хотелось знать, какие функции нужны большинству. Все заявки принимаются, но выполнение не гарантируется :-)
Линус (torvalds@kruuna.helsinki.fi)
PS. Она свободна от кода minix и включает мультизадачную файловую систему. Она НЕ переносима (используется переключение задач 386 и пр.) и, возможно, никогда не будет поддерживать ничего, кроме АТ-винчестеров, потому что у меня больше ничего нет :-(
Вряд ли кто-то тогда мог подумать, что оно серьезно изменит компьютерный мир уже в течении этого десятилетия. Простой студенческий проект никому не известного финского парня…
Изначально система должна была называться Freax, но Ари Лемке, который предоставил место для проекта на своем FTP сервере назвал каталог pub/OS/Linux, которое и закрепилось в качестве названия системы.
Важной вехой в развитии системы стала кооперация с проектом GNU, который еще с 1983 года под руководством Ричарда Столлмана занимался созданием полностью открытой и свободной операционной системы.
К 1991 году у Столлмана было практически все, что нужно, кроме ядра. Собственные попытки разработать ядро Hurd не привели к успеху (причем до сих пор) и тут появилось ядро, которому как раз нужно было прикладное ПО.
Уже через год начали появляться первые дистрибутивы, так в 1992 году увидел свет Slackware Патрика Фолькердинга, а в 1993 Debian Яна Мёрдока, в 1994 появились S.U.S.E и Red Hat.
В этом же году увидело свет ядро 1.0.0 содержавшее 176 250 строчек кода, а уже в 1996 была выпущена версия 2.0, началась эпоха стремительного развития молодой системы.
В этом же году появился официальный талисман системы – пингвин Tux, его нарисовал Ларри Юинг. Слово Tux придумал Джеймз Хьюз, соединив два слова: (T)orvalds (U)ni(X).
В 1998 году Матиас Эттрих представил первый выпуск KDE, которая предлагала законченную среду рабочего стола с набором программ базировавшуюся на Qt, а годом позже Мигель де Иказа и Федерико Мен выпустили первую версию GNOME на GTK+.
Менее чем за 10 лет Linux прошел путь от небольшого студенческого проекта до полноценной ОС с графической оболочкой.
В дальнейшем система продолжила развиваться и занимать новые ниши, так уже в 2002 году увидел свет Red Hat Enterprise Linux.
Домашние пользователи тоже не остались без внимания, в 1998 году появился Mandrake Linux, позже Mandriva – один из самых дружелюбных дистрибутивов того времени.
В это же время появился дистрибутив Linux-Mandrake Russian Edition, который впоследствии занялся полностью собственной разработкой и теперь мы его знаем как ALT Linux.
А сам Mandrake/Mandriva прошел сложный путь, несколько раз менял владельца пока не превратился в ROSA Linux.
Еще одно знаковое событие произошло в 2004 году, с выходом дистрибутива Ubuntu Linux, который сделал систему ближе в прямом и переносном смысле.
В те времена широкополосный интернет был еще дорог и труднодоступен, поэтому Canonical рассылала диски с Ubuntu почтой бесплатно в любую точку земного шара.
А дальше вы и так, наверное, все знаете, размер заметки не позволяет продолжать наше повествование. Поэтому еще раз вспомним как все начиналось и поздравим Linux c днем рождения.
1👍38❤12
История Windows NT
Windows NT без преувеличения можно назвать ключевой системой для Microsoft, именно она и заложенные в нее технологии заложила ту основу, которую системы Windows используют сейчас.
Начиная с Windows XP закончилось деление ОС Windows на пользовательскую и профессиональную линейку и дальше пошла развиваться именно линия NT и сегодня, запуская Windows 10 или 11 мы имеем под капотом потомка той самой NT.
Вся эта история началась очень давно, в 1980 году, когда IBM готовилась к выводу на рынок IBM PC и искала для него операционную систему. Сложность дополнительно состояла в том, что все существующие на тот момент ПК были 8-битными и для 16-битного IBM PC систему еще предстояло написать.
В этот момент на сцену вышел Билл Гейтс, который пообещал недорого решить проблему IBM, для чего купил 86-DOS у компании Seattle Computer Products и перепродал лицензию IBM.
Затем, если систему продавал IBM, то она называлась PC-DOS, а если Microsoft или кто-то еще – MS-DOS.
Несмотря на то, что на момент выхода IBM PC уже вышли 16-битные версии уже существовавших ОС DOS уверенно занял рыночную нишу. Все дело было в цене, лицензия на DOS-стоила всего 40$, а CP/M – 450$ (144$ и 1613$ в нынешних ценах).
Однако дальше дела пошли не столь хорошо, ожидаемая на замену DOS операционная система Windows в версиях 1 и 2 провалилась, а выпушенная в 1987 году OS/2 оказалась тяжелой и трудно конфигурируемой, вследствие чего тоже не достигла успеха.
Понимая, что для успеха нужна новая операционная система партнеры принялись за разработку NT OS/2, которая была полностью новой системой и не базировалась ни на DOS, ни на OS/2.
Для этого Microsoft пригласила команду специалистов из DEC во главе с Девидом Катлером, который до этого разрабатывал там VAX/VMS и RSX-11M. Система изначально разрабатывалась как полностью 32-разрядная, переносимая и многопользовательская.
Сначала данный проект должен был основываться на графическом интерфейсе OS/2 и планировался к выходу как OS/2 3.0, но отношения между партерами начали портится.
IBM была недовольна открытой архитектурой IBM PC и предпринимала действия к выпуску нового поколения компьютеров PS/2 на максимально закрытой архитектуре и с использованием в качестве системы OS/2.
Но ни PS/2, ни OS/2 не имели коммерческого успеха, а в 1990 вышла в свет Windows 3.0, которая имела оглушительный рыночный успех.
В свете успехов Microsoft решила добавить в проект NT OS/2 подсистему для программной совместимости с Windows, что очень сильно не понравилось IBM, которая, наоборот, продолжала курс на максимальную закрытость и возврат контроля над всеми компонентами ПК.
В итоге в 1991 пути компаний полностью разошлись. IBM продолжило работы над OS/2, а Microsoft забрали свои наработки и выпустила в 1993 году новую ОС под именем Windows NT.
Система позиционировалась как для сетей и профессионалов, а номер первой версии был взят от рыночно успешной Windows 3.0, и новая система вышла как Windows NT 3.1
Вместе с ней увидела свет и файловая система нового поколения NTFS, а также очень многое из того, что широко применяется сейчас.
Взрывного успеха Windows NT не получила, но за год, до момента выхода NT 3.5 было продано более 300 тыс. копий по 495$ каждая (1080$ в текущих ценах).
Несмотря на наличие ресурсов и хорошие заделы по OS/2 Warp 3 компания IBM проиграла рыночную гонку с Microsoft и так и не смогла предоставить достойного конкурента Windows.
Во многом это было связано с тем, что Microsoft и лично Билл Гейтс сделали ставку на Windows и выиграли, в то время как в IBM никто не был готов взять на себя такую ответственность за проект OS/2, который продолжал оставаться еще одним из многочисленных проектов гиганта.
Вокруг этой истории до сих пор ходит масса мифов, но на самом деле Windows NT не имеет ничего общего с IBM OS/2, кроме того, что работа некоторое время велась в рамках одного проекта, это совершенно новая ОС.
Также IBM никогда не подавала к Microsoft судебных исков по поводу Windows NT.
Windows NT без преувеличения можно назвать ключевой системой для Microsoft, именно она и заложенные в нее технологии заложила ту основу, которую системы Windows используют сейчас.
Начиная с Windows XP закончилось деление ОС Windows на пользовательскую и профессиональную линейку и дальше пошла развиваться именно линия NT и сегодня, запуская Windows 10 или 11 мы имеем под капотом потомка той самой NT.
Вся эта история началась очень давно, в 1980 году, когда IBM готовилась к выводу на рынок IBM PC и искала для него операционную систему. Сложность дополнительно состояла в том, что все существующие на тот момент ПК были 8-битными и для 16-битного IBM PC систему еще предстояло написать.
В этот момент на сцену вышел Билл Гейтс, который пообещал недорого решить проблему IBM, для чего купил 86-DOS у компании Seattle Computer Products и перепродал лицензию IBM.
Затем, если систему продавал IBM, то она называлась PC-DOS, а если Microsoft или кто-то еще – MS-DOS.
Несмотря на то, что на момент выхода IBM PC уже вышли 16-битные версии уже существовавших ОС DOS уверенно занял рыночную нишу. Все дело было в цене, лицензия на DOS-стоила всего 40$, а CP/M – 450$ (144$ и 1613$ в нынешних ценах).
Однако дальше дела пошли не столь хорошо, ожидаемая на замену DOS операционная система Windows в версиях 1 и 2 провалилась, а выпушенная в 1987 году OS/2 оказалась тяжелой и трудно конфигурируемой, вследствие чего тоже не достигла успеха.
Понимая, что для успеха нужна новая операционная система партнеры принялись за разработку NT OS/2, которая была полностью новой системой и не базировалась ни на DOS, ни на OS/2.
Для этого Microsoft пригласила команду специалистов из DEC во главе с Девидом Катлером, который до этого разрабатывал там VAX/VMS и RSX-11M. Система изначально разрабатывалась как полностью 32-разрядная, переносимая и многопользовательская.
Сначала данный проект должен был основываться на графическом интерфейсе OS/2 и планировался к выходу как OS/2 3.0, но отношения между партерами начали портится.
IBM была недовольна открытой архитектурой IBM PC и предпринимала действия к выпуску нового поколения компьютеров PS/2 на максимально закрытой архитектуре и с использованием в качестве системы OS/2.
Но ни PS/2, ни OS/2 не имели коммерческого успеха, а в 1990 вышла в свет Windows 3.0, которая имела оглушительный рыночный успех.
В свете успехов Microsoft решила добавить в проект NT OS/2 подсистему для программной совместимости с Windows, что очень сильно не понравилось IBM, которая, наоборот, продолжала курс на максимальную закрытость и возврат контроля над всеми компонентами ПК.
В итоге в 1991 пути компаний полностью разошлись. IBM продолжило работы над OS/2, а Microsoft забрали свои наработки и выпустила в 1993 году новую ОС под именем Windows NT.
Система позиционировалась как для сетей и профессионалов, а номер первой версии был взят от рыночно успешной Windows 3.0, и новая система вышла как Windows NT 3.1
Вместе с ней увидела свет и файловая система нового поколения NTFS, а также очень многое из того, что широко применяется сейчас.
Взрывного успеха Windows NT не получила, но за год, до момента выхода NT 3.5 было продано более 300 тыс. копий по 495$ каждая (1080$ в текущих ценах).
Несмотря на наличие ресурсов и хорошие заделы по OS/2 Warp 3 компания IBM проиграла рыночную гонку с Microsoft и так и не смогла предоставить достойного конкурента Windows.
Во многом это было связано с тем, что Microsoft и лично Билл Гейтс сделали ставку на Windows и выиграли, в то время как в IBM никто не был готов взять на себя такую ответственность за проект OS/2, который продолжал оставаться еще одним из многочисленных проектов гиганта.
Вокруг этой истории до сих пор ходит масса мифов, но на самом деле Windows NT не имеет ничего общего с IBM OS/2, кроме того, что работа некоторое время велась в рамках одного проекта, это совершенно новая ОС.
Также IBM никогда не подавала к Microsoft судебных исков по поводу Windows NT.
👍10❤1🤮1
Версии PowerShell
PowerShell активно используется Windows-администраторами для автоматизации и написания скриптов, но далеко не все правильно ориентируются в версиях и выпусках PowerShell, поэтому сегодня разберем этот вопрос подробнее.
На сегодняшний день существуют две версии PowerShell:
🔹 Windows PowerShell – основан на .NET Framework, существует только для Windows, предустановлен начиная с Windows Server 2008 R2 и Windows 7. В настоящий момент не развивается, последний выпуск – 5.1
🔹 PowerShell (ранние выпуски назывались PowerShell Core) – основан на базе современного .NET (Core / 6 / 8+), является кроссплатформенным ПО с открытым исходным кодом, может быть установлен в Windows, Linux и macOS. В PowerShell нет полной совместимости с Windows PowerShell, однако для выпуска PowerShell 7.х разработчиками заявлена максимальная совместимость.
🔸 Windows PowerShell имеет следующие выпуски:
▫️ PowerShell 1.0 – предназначен для ручной установки начиная с Windows Server 2003 SP1 и Windows XP
▫️ PowerShell 2.0 – предустановлен в Windows Server 2008 R2 и Windows 7
▫️ PowerShell 3.0 – предустановлен в Windows Server 2012 и Windows 8
▫️ PowerShell 4.0 – предустановлен в Windows Server 2012 R2 и Windows 8.1
▫️ PowerShell 5.0 – предустановлен в Windows 10 ранних выпусков, автоматически обновляется до 5.1
▫️ PowerShell 5.1 – предустановлен начиная с Windows Server 2016 и Windows 10 1709
В настоящий момент Windows PowerShell не развивается и рекомендуется переход на PowerShell.
🔸 PowerShell имеет следующие выпуски:
▫️ PowerShell Core 6.х на базе .NET Core 2.x, имеет неполную обратную совместимость с Windows PowerShell
▫️ PowerShell 7.х на базе актуальных релизов .NET (с долгосрочной поддержкой LTS), заявлена максимальная обратная совместимость, при этом рекомендуется протестировать работу старых скриптов.
Версия 6.x и ранние 7.0/7.1 полностью выведены из поддержки (End of Life). Актуальной веткой является семейство PowerShell 7.x LTS / Current.
👉 PowerShell можно получить с официальной страницы на Github, через WinGet или из магазина Windows. Обратите внимание, что PowerShell 7 устанавливается параллельно с Windows PowerShell 5.1, не заменяя его.
Для обновления Windows PowerShell вам потребуется установить Windows Management Framework (WMF) соответствующей версии и связанный с ним пакет .NET Framework. Если вы обновите WMF, но не установите новый .NET Framework, то часть функций PowerShell может отказаться работать.
Также следует помнить, что среда разработки PowerShell ISE предназначена только для Windows PowerShell, для работы с PowerShell следует использовать Visual Studio Code.
PowerShell активно используется Windows-администраторами для автоматизации и написания скриптов, но далеко не все правильно ориентируются в версиях и выпусках PowerShell, поэтому сегодня разберем этот вопрос подробнее.
На сегодняшний день существуют две версии PowerShell:
🔹 Windows PowerShell – основан на .NET Framework, существует только для Windows, предустановлен начиная с Windows Server 2008 R2 и Windows 7. В настоящий момент не развивается, последний выпуск – 5.1
🔹 PowerShell (ранние выпуски назывались PowerShell Core) – основан на базе современного .NET (Core / 6 / 8+), является кроссплатформенным ПО с открытым исходным кодом, может быть установлен в Windows, Linux и macOS. В PowerShell нет полной совместимости с Windows PowerShell, однако для выпуска PowerShell 7.х разработчиками заявлена максимальная совместимость.
🔸 Windows PowerShell имеет следующие выпуски:
▫️ PowerShell 1.0 – предназначен для ручной установки начиная с Windows Server 2003 SP1 и Windows XP
▫️ PowerShell 2.0 – предустановлен в Windows Server 2008 R2 и Windows 7
▫️ PowerShell 3.0 – предустановлен в Windows Server 2012 и Windows 8
▫️ PowerShell 4.0 – предустановлен в Windows Server 2012 R2 и Windows 8.1
▫️ PowerShell 5.0 – предустановлен в Windows 10 ранних выпусков, автоматически обновляется до 5.1
▫️ PowerShell 5.1 – предустановлен начиная с Windows Server 2016 и Windows 10 1709
В настоящий момент Windows PowerShell не развивается и рекомендуется переход на PowerShell.
🔸 PowerShell имеет следующие выпуски:
▫️ PowerShell Core 6.х на базе .NET Core 2.x, имеет неполную обратную совместимость с Windows PowerShell
▫️ PowerShell 7.х на базе актуальных релизов .NET (с долгосрочной поддержкой LTS), заявлена максимальная обратная совместимость, при этом рекомендуется протестировать работу старых скриптов.
Версия 6.x и ранние 7.0/7.1 полностью выведены из поддержки (End of Life). Актуальной веткой является семейство PowerShell 7.x LTS / Current.
👉 PowerShell можно получить с официальной страницы на Github, через WinGet или из магазина Windows. Обратите внимание, что PowerShell 7 устанавливается параллельно с Windows PowerShell 5.1, не заменяя его.
Для обновления Windows PowerShell вам потребуется установить Windows Management Framework (WMF) соответствующей версии и связанный с ним пакет .NET Framework. Если вы обновите WMF, но не установите новый .NET Framework, то часть функций PowerShell может отказаться работать.
Также следует помнить, что среда разработки PowerShell ISE предназначена только для Windows PowerShell, для работы с PowerShell следует использовать Visual Studio Code.
👍20😱3👌1
Веселые картинки
Недавно один из коллег снова притащил ссылку на «хороший материал по сегментации» на известный репозиторий на гитхабе: https://github.com/sergiomarotco/Network-segmentation-cheat-sheet
К сожалению, я не могу считать данный материал хорошим и тем более рекомендовать его, хотя автор и ссылается на некие «лучшие практики».
Почему? Начнем издалека, с принципов построения обучающих материалов. Хороший обучающий материал, тем более схема или диаграмма должна быть способна сразу донести до обучаемого основные принципы и ключевые моменты изучаемой темы.
Ничего лишнего, никаких ненужных подробностей на схеме быть не должно, они только размывают внимание на второстепенные вещи, путают и вызывают лишние вопросы.
Вместо этого нас встречает перегруженная значками и связями схема, которая ничего не поясняет, а только еще больше запутывает. Сразу возникает масса вопросов, причем абсолютно к теме сегментации не относящихся.
В целом, человек немного «в теме» со схемами первых уровней за пять-десять минут вождения по ним пальцем разберется и здравое зерно там есть. Но для начинающего это будет просто темный лес: ничего не понятно, но очень интересно. Еще хуже если последуют попытки слепого копирования.
Но все можно было сделать гораздо проще, убрать все эти ненужные подробности и связи, оставив только самые широкие мазки: вот у нас продуктовые сервера, вот поддержка продуктовой части, вот пользовательская часть, вот поддержка пользовательской части, вот управление, вот сетевое оборудование, вот DMZ.
Ну и хорошую пояснительную записку, поясняющую что именно сделано, для чего и почему.
А текущие схемы сильно напоминают мне казуальные игрушки, где нужно копать-строить да отбиваться от толп монстров, и каждая следующая толпа сильнее предыдущей.
А все эти линии напоминают производственные цепочки, которые могут быть неоптимальны и запутаны, но так «исторически сложились». И вообще переделать пока никак нельзя, а то не отобьемся.
И автор схем только подливает масла в огонь, указывая в описании к первому уровню что вам понадобится больше средств защиты информации или потребуется переход на второй уровень.
Знакомо? Чтобы отбиваться от монстров вам нужно все больше и больше стреляющих башен, но башни стоят ресурсов, их надо где-то строить, и монстры начинают сносить их на ура. Хочешь - не хочешь, а уровень придется повышать.
Причем складывается такое впечатление, что автор схем отринул реальность и занялся сегментацией ради сегментации. Уже на третьем уровне он вводит системы обнаружения инцидентов и реагирования на них, вскользь упомянув «что вам понадобится штат 10-20 человек безопасников».
Серьезно? Организации такого уровня, где риски ИБ выходят на уровень операционных рисков явно не будут искать схемы по гитам и на этом можно бы было закончить. Но фантазия автора устремляется только вперед.
Хотя для простого пользователя все эти многочисленные возникшие объекты с непонятными аббревиатурами ничем не будут отличаться от генератора маны, школы магов и чего там еще надо построить для того, чтобы башни начали стрелять электричеством.
Ну и последняя схема – просто апофеоз:
Теперь злоумышленник не сможет атаковать производственную сеть, поскольку теперь потенциально скомпрометированная рабочая станция в корпоративной сети принципиально не имеет доступа к производственной сети. Связанные проблемы:
Отдельные рабочие станции для доступа к производственной сети – да, теперь у вас на рабочем столе будет 2 компьютера;
Да, именно к этому бизнес и стремился… И деньги на него, наверное, с неба падают.
Вопросы разумной достаточности здесь не поднимаются в принципе. Автор рассматривает сегментацию с позиции типичного гика в вакууме. Хотя для того, чтобы закрыть в садовом домике две лопаты и ржавые грабли достаточно замка за 100 рублей и ставить сейфовую дверь с укреплением коробки там явно излишне.
В общем материал забавный, красивый. Но практической пользы – близко к нулю.
Недавно один из коллег снова притащил ссылку на «хороший материал по сегментации» на известный репозиторий на гитхабе: https://github.com/sergiomarotco/Network-segmentation-cheat-sheet
К сожалению, я не могу считать данный материал хорошим и тем более рекомендовать его, хотя автор и ссылается на некие «лучшие практики».
Почему? Начнем издалека, с принципов построения обучающих материалов. Хороший обучающий материал, тем более схема или диаграмма должна быть способна сразу донести до обучаемого основные принципы и ключевые моменты изучаемой темы.
Ничего лишнего, никаких ненужных подробностей на схеме быть не должно, они только размывают внимание на второстепенные вещи, путают и вызывают лишние вопросы.
Вместо этого нас встречает перегруженная значками и связями схема, которая ничего не поясняет, а только еще больше запутывает. Сразу возникает масса вопросов, причем абсолютно к теме сегментации не относящихся.
В целом, человек немного «в теме» со схемами первых уровней за пять-десять минут вождения по ним пальцем разберется и здравое зерно там есть. Но для начинающего это будет просто темный лес: ничего не понятно, но очень интересно. Еще хуже если последуют попытки слепого копирования.
Но все можно было сделать гораздо проще, убрать все эти ненужные подробности и связи, оставив только самые широкие мазки: вот у нас продуктовые сервера, вот поддержка продуктовой части, вот пользовательская часть, вот поддержка пользовательской части, вот управление, вот сетевое оборудование, вот DMZ.
Ну и хорошую пояснительную записку, поясняющую что именно сделано, для чего и почему.
А текущие схемы сильно напоминают мне казуальные игрушки, где нужно копать-строить да отбиваться от толп монстров, и каждая следующая толпа сильнее предыдущей.
А все эти линии напоминают производственные цепочки, которые могут быть неоптимальны и запутаны, но так «исторически сложились». И вообще переделать пока никак нельзя, а то не отобьемся.
И автор схем только подливает масла в огонь, указывая в описании к первому уровню что вам понадобится больше средств защиты информации или потребуется переход на второй уровень.
Знакомо? Чтобы отбиваться от монстров вам нужно все больше и больше стреляющих башен, но башни стоят ресурсов, их надо где-то строить, и монстры начинают сносить их на ура. Хочешь - не хочешь, а уровень придется повышать.
Причем складывается такое впечатление, что автор схем отринул реальность и занялся сегментацией ради сегментации. Уже на третьем уровне он вводит системы обнаружения инцидентов и реагирования на них, вскользь упомянув «что вам понадобится штат 10-20 человек безопасников».
Серьезно? Организации такого уровня, где риски ИБ выходят на уровень операционных рисков явно не будут искать схемы по гитам и на этом можно бы было закончить. Но фантазия автора устремляется только вперед.
Хотя для простого пользователя все эти многочисленные возникшие объекты с непонятными аббревиатурами ничем не будут отличаться от генератора маны, школы магов и чего там еще надо построить для того, чтобы башни начали стрелять электричеством.
Ну и последняя схема – просто апофеоз:
Теперь злоумышленник не сможет атаковать производственную сеть, поскольку теперь потенциально скомпрометированная рабочая станция в корпоративной сети принципиально не имеет доступа к производственной сети. Связанные проблемы:
Отдельные рабочие станции для доступа к производственной сети – да, теперь у вас на рабочем столе будет 2 компьютера;
Да, именно к этому бизнес и стремился… И деньги на него, наверное, с неба падают.
Вопросы разумной достаточности здесь не поднимаются в принципе. Автор рассматривает сегментацию с позиции типичного гика в вакууме. Хотя для того, чтобы закрыть в садовом домике две лопаты и ржавые грабли достаточно замка за 100 рублей и ставить сейфовую дверь с укреплением коробки там явно излишне.
В общем материал забавный, красивый. Но практической пользы – близко к нулю.
👍14❤4🥱1
Please open Telegram to view this post
VIEW IN TELEGRAM
👍16🔥13👌6❤1😱1
И как вы думаете, что это такое? Это скриншот из одного отеля в Дагестане, где я провел летний отпуск. Причем это не какой-то мелкий отель или гостевой дом, это дорогой сетевой отель 5 звезд уровня полный пансион.
А весь выход во внешнюю сеть там организован через Cloudflare WARP, просто и «без палева». Хотя владельцев отеля понять можно – отель дорогой, зачем причинять неудобства тем, кто везет тебе деньги.
В остальном по региону я тоже каких-то особых сложностей не замечал – мобильный интернет был везде, ну кроме дикой природы и работал так, как от него ожидается, во всяком случае мой Телеграм спокойно соединялся с собственным MT Proxy и работал.
А вот что удивило, так это отношение к маркировке. На нее там забит болт, даже в крупных региональных сетевых супермаркетах. Там вам свободно пробьют три бутылки минералки один раз кликнув пол линейному ШК и нажав кнопку 3 на клавиатуре.
Единственное место, где более-менее что-то соблюдается – это аптеки. Ну да там своя система и с маркировкой у нее общего разве что название.
А вот что твориться далее – кроме как маразмом не назовешь. Практически всю дорогу от Махачкалы до Россоши мобильный интернет отсутствовал как класс, а для подключения к беспроводному интернет от РЖД на станциях надо предварительно как-то зайти на портал авторизации.
В общем, за 30 минут стоянки в Ростове у меня получилось это сделать аккурат к отправлению поезда. Поэтому пришлось звонить знакомым, чтобы перевели денег за квартиру в Россоши, так как ночевать на вокзале или в машине категорически не хотелось.
В комментариях пишите свой опыт по состоянию дел с указанием региона.
А весь выход во внешнюю сеть там организован через Cloudflare WARP, просто и «без палева». Хотя владельцев отеля понять можно – отель дорогой, зачем причинять неудобства тем, кто везет тебе деньги.
В остальном по региону я тоже каких-то особых сложностей не замечал – мобильный интернет был везде, ну кроме дикой природы и работал так, как от него ожидается, во всяком случае мой Телеграм спокойно соединялся с собственным MT Proxy и работал.
А вот что удивило, так это отношение к маркировке. На нее там забит болт, даже в крупных региональных сетевых супермаркетах. Там вам свободно пробьют три бутылки минералки один раз кликнув пол линейному ШК и нажав кнопку 3 на клавиатуре.
Единственное место, где более-менее что-то соблюдается – это аптеки. Ну да там своя система и с маркировкой у нее общего разве что название.
А вот что твориться далее – кроме как маразмом не назовешь. Практически всю дорогу от Махачкалы до Россоши мобильный интернет отсутствовал как класс, а для подключения к беспроводному интернет от РЖД на станциях надо предварительно как-то зайти на портал авторизации.
В общем, за 30 минут стоянки в Ростове у меня получилось это сделать аккурат к отправлению поезда. Поэтому пришлось звонить знакомым, чтобы перевели денег за квартиру в Россоши, так как ночевать на вокзале или в машине категорически не хотелось.
В комментариях пишите свой опыт по состоянию дел с указанием региона.
👍9❤1
Как сделать QR-код для доступа к Wi-Fi при помощи PowerShell
Пароль для беспроводной сети – головная боль системного администратора. Сделать его простым – очень скоро его будет знать каждый первый. Сделать сложным – сам утомишься вводить.
Отличный выход из этой ситуации – генерация специального QR-кода для автоматической настройки Wi-Fi. Сделать это совсем не сложно, нам только понадобится дополнительный модуль PowerShell.
Для его установки выполните:
Данный модуль позволяет генерировать различные QR-кода, но нас сейчас интересует код для Wi-Fi:
Опции тут в целом понятны, но все-таки разберем их кратко:
▫️ SSID – идентификатор SSID беспроводной сети
▫️ Password – пароль доступа к сети
▫️ OutPath – путь и имя файла изображения, если не указана то генерируется файл со случайным названием в текущей папке
▫️ Show – открыть изображение в сопоставленной программе
▫️ Width – ширина элемента изображения в пикселях, по умолчанию 100
По последней опции следует пройтись внимательнее. Она указывает не ширину всего изображения, а ширину одного его элемента. Так в нашем примере генерируется изображение 41 х 41 элемент, его размеры при значении по умолчанию нетрудно посчитать самостоятельно.
Ну и не забываем, что сгенерированный нами QR-код содержит пароль, а поэтому принимаем меры к его безопасному хранению.
Пароль для беспроводной сети – головная боль системного администратора. Сделать его простым – очень скоро его будет знать каждый первый. Сделать сложным – сам утомишься вводить.
Отличный выход из этой ситуации – генерация специального QR-кода для автоматической настройки Wi-Fi. Сделать это совсем не сложно, нам только понадобится дополнительный модуль PowerShell.
Для его установки выполните:
Install-Module -Name QRCodeGenerator
Данный модуль позволяет генерировать различные QR-кода, но нас сейчас интересует код для Wi-Fi:
New-PSOneQRCodeWifiAccess -SSID MyWi-Fi -Password MyPassworD -Width 10 -Show -OutPath "$home\Desktop\qr.png"
Опции тут в целом понятны, но все-таки разберем их кратко:
▫️ SSID – идентификатор SSID беспроводной сети
▫️ Password – пароль доступа к сети
▫️ OutPath – путь и имя файла изображения, если не указана то генерируется файл со случайным названием в текущей папке
▫️ Show – открыть изображение в сопоставленной программе
▫️ Width – ширина элемента изображения в пикселях, по умолчанию 100
По последней опции следует пройтись внимательнее. Она указывает не ширину всего изображения, а ширину одного его элемента. Так в нашем примере генерируется изображение 41 х 41 элемент, его размеры при значении по умолчанию нетрудно посчитать самостоятельно.
Ну и не забываем, что сгенерированный нами QR-код содержит пароль, а поэтому принимаем меры к его безопасному хранению.
🔥18👍4🤔2🤮2🥱1
This media is not supported in your browser
VIEW IN TELEGRAM
🐱 Кот из дома – мыши в пляс 🐭🐭🐭
Хотите посмотреть, что делают ваши сотрудники, подрядчики и прочие лица, наделенные административным доступом в Linux?
Да, можно почитать логи, посмотреть историю команд, но это не даст полного представления, особенно если были использованы интерактивные утилиты.
Но sudo готово нам помочь, причем совершенно «бесплатно», все нужные инструменты уже есть из коробки, осталось только использовать.
Для этого добавьте в /etc/sudoers два параметра, которые отвечают за запись потоков ввода и вывода сессии, например:
Потом смотрим, кто и когда работал под sudo указав имя пользователя:
В колонке TSID находим номер сеанса и запускаем его просмотр, обязательно добавьте ключ -R, чтобы не изменять размер изображения, который может поломать картинку, также можно добавить ключ -s и указать нужную скорость:
Приятного просмотра!
Хотите посмотреть, что делают ваши сотрудники, подрядчики и прочие лица, наделенные административным доступом в Linux?
Да, можно почитать логи, посмотреть историю команд, но это не даст полного представления, особенно если были использованы интерактивные утилиты.
Но sudo готово нам помочь, причем совершенно «бесплатно», все нужные инструменты уже есть из коробки, осталось только использовать.
Для этого добавьте в /etc/sudoers два параметра, которые отвечают за запись потоков ввода и вывода сессии, например:
%sudo ALL=(ALL:ALL) NOPASSWD:LOG_INPUT:LOG_OUTPUT:ALL
Потом смотрим, кто и когда работал под sudo указав имя пользователя:
sudoreplay -l user andrey
В колонке TSID находим номер сеанса и запускаем его просмотр, обязательно добавьте ключ -R, чтобы не изменять размер изображения, который может поломать картинку, также можно добавить ключ -s и указать нужную скорость:
sudoreplay 000005 -R -s 2
Приятного просмотра!
👍24
Действие ради действия?
Про разную бюрократию, бессмысленную и беспощадную, можно рассказывать часами, но существуют моменты, которые по своей бессмысленности бьют всякие рекорды.
Сегодня у одного заказчика наблюдаем с утра такую прекрасную картину и полностью отказываемся понимать ее смысл. Честный знак сегодня – это обязательная система для любого участника оборота маркированного товара. Особо подчеркнем – для любого!
В чем тогда тайный смысл процедуры рассмотрения и кто рассматривает заявки? Неужели специально обученные сотрудники? Прямо вот сидят и рассматривают, со всех сторон проверяя кандидата – а достоен ли? А не подведет? А может рано ему пока еще?
При том, что регистрацию вы выполняете строго по ЭП, что исключает спам и фейковые регистрации. Т.е. подлинность заявителя подтверждена еще на этапе регистрации и никаких дополнительных данных, кроме телефона и адреса электронной почты он не предоставляет?
Так чего вы там ждете? Проверки по базе ФНС? Она давно делается автоматически в режиме реального времени. Ну может не реального, если запросов у вас много, и они стоят в очереди – но все равно в течении единиц, максимум – десятков минут.
В чем смысл мариновать заявку весь день? Ну вот для чего? Чтобы пользователь проникся? Он и так проникся и еще проникнется в процессе работы.
А по факту это прямое вредительство, так как срывает все сроки как клиентам, так и подрядчикам. И дело не только в настройках и регистрациях. До тех пор пока вас нет в Честном знаке ни один поставщик не отгрузит вам маркированный товар. А у вас открытие на следующей неделе? Ничего не знаем и вообще не мешайте, мы делом заняты, вашу заявку рассматриваем.
Про разную бюрократию, бессмысленную и беспощадную, можно рассказывать часами, но существуют моменты, которые по своей бессмысленности бьют всякие рекорды.
Сегодня у одного заказчика наблюдаем с утра такую прекрасную картину и полностью отказываемся понимать ее смысл. Честный знак сегодня – это обязательная система для любого участника оборота маркированного товара. Особо подчеркнем – для любого!
В чем тогда тайный смысл процедуры рассмотрения и кто рассматривает заявки? Неужели специально обученные сотрудники? Прямо вот сидят и рассматривают, со всех сторон проверяя кандидата – а достоен ли? А не подведет? А может рано ему пока еще?
При том, что регистрацию вы выполняете строго по ЭП, что исключает спам и фейковые регистрации. Т.е. подлинность заявителя подтверждена еще на этапе регистрации и никаких дополнительных данных, кроме телефона и адреса электронной почты он не предоставляет?
Так чего вы там ждете? Проверки по базе ФНС? Она давно делается автоматически в режиме реального времени. Ну может не реального, если запросов у вас много, и они стоят в очереди – но все равно в течении единиц, максимум – десятков минут.
В чем смысл мариновать заявку весь день? Ну вот для чего? Чтобы пользователь проникся? Он и так проникся и еще проникнется в процессе работы.
А по факту это прямое вредительство, так как срывает все сроки как клиентам, так и подрядчикам. И дело не только в настройках и регистрациях. До тех пор пока вас нет в Честном знаке ни один поставщик не отгрузит вам маркированный товар. А у вас открытие на следующей неделе? Ничего не знаем и вообще не мешайте, мы делом заняты, вашу заявку рассматриваем.
⚡7🔥6👍4🤬3🤡3