По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Public Key Infrastructure (PKI) - это набор различных технологий, которые используются для обеспечения аутентификации источника, целостности данных и конфиденциальности для пользователя в сети. PKI использует преимущества асимметричного шифрования и использует пары открытого и закрытого ключей для шифрования данных.
В PKI открытый ключ обычно связан с цифровой подписью, чтобы добавить доверие и проверить сведения о владельце сертификата. Ниже приведен ключевой жизненный цикл в PKI:
Генерация ключа: Этот процесс определяет шифр и размер ключа.
Генерация сертификата: Этот процесс создает цифровой сертификат и назначает его человеку или устройству.
Распространение: Процесс распространения отвечает за безопасное распространение ключа пользователю или устройству.
Хранение: Этот процесс отвечает за безопасное хранение ключа, чтобы предотвратить любой несанкционированный доступ к нему.
Отзыв: Сертификат или ключ могут быть отозваны, если они скомпрометированы субъектом угрозы.
Срок действия: Каждый сертификат имеет срок службы.
Каждый день мы посещаем различные веб-сайты, такие как социальные сети, стрим, новости, спорт, блоги и другие платформы. Однако задумывались ли вы когда-нибудь о проверке подлинности веб-сайтов, которые вы посещаете? Вы, наверное, думаете, что всему, что находится в Интернете, нельзя доверять. Хотя это отчасти правда, мы можем доверять только ограниченному числу веб-сайтов, например, доверять веб-сайту вашего банка. Главный вопрос заключается в том, как мы можем проверить подлинность веб-сайтов, которые мы посещаем? Именно здесь как PKI, так и цифровые сертификаты помогают установить доверие между хостом в Интернете и нашим компьютером.
Центр сертификации
PKI играет жизненно важную роль в Интернете, поскольку многим пользователям и устройствам требуется метод установления доверия в самой ненадежной сети в мире – Интернете. Понимание компонентов, которые помогают PKI обеспечить доверие, необходимую как пользователям, так и устройствам, имеет важное значение для любого специалиста по кибербезопасности.
Вы можете рассматривать PKI как набор процедур, правил, аппаратного и программного обеспечения, а также людей, которые работают вместе для управления цифровыми сертификатами. Цифровой сертификат-это официальная форма идентификации объекта, которая проверяется доверенной стороной. Эти цифровые сертификаты выдаются доверенной стороной в сети или Интернете. Они известны как Центр сертификации (Certificate Authority - CA).
В каждой стране существует государственное учреждение, которое обычно отвечает за проверку личности своих граждан и выдачу удостоверений личности, такой как паспорт.
Этот паспорт будет содержать важную информацию о владельце и сроке действия, например, дату окончания срока действия. В сети и в Интернете центр сертификации выполняет похожую роль и функции. В Интернете есть множество поставщиков, которые являются доверенными центрами сертификации, которые позволяют вам приобретать цифровой сертификат для личного использования. Примеры доверенных центров сертификации включают GoDaddy, DigiCert, Let's Encrypt, Comodo, Cloudflare и многие другие.
Важное примечание! Цифровой сертификат создается при объединении ключа и цифровой подписи. Сертификат будет содержать сведения о владельце сертификата, например, об организации.
ЦС выдаст объекту цифровой сертификат только после того, как его личность будет проверена. После того, как ЦС создает цифровой сертификат, он сохраняется в базе данных сертификатов, которая используется для безопасного хранения всех утвержденных ЦС цифровых сертификатов.
Важное примечание! По истечении срока действия цифрового сертификата он возвращается в ЦС, который затем помещается в список отзыва сертификатов (Certificate Revocation List - CRL), который поддерживается ЦС.
Цифровой сертификат форматируется с использованием стандарта X.509, который содержит следующие сведения:
Номер версии
Серийный номер
Идентификатор алгоритма подписи
Название эмитента
Срок годности
Не раньше, чем
Не после
Имя субъекта
Информация об открытом ключе субъекта
Алгоритм открытого ключа
Открытый ключ субъекта
Уникальный идентификатор эмитента (необязательно)
Уникальный идентификатор субъекта (необязательно)
Расширения (необязательно)
Алгоритм подписи сертификата
Подпись сертификата
Регистрирующий орган (RA)
Следующий рисунок - это цифровой сертификат, который используется для проверки веб-сайта Cisco:
Как показано на предыдущем рисунке, видно, что CA - это HydrantID SSH ICA G2, который выдает сертификат на www.cisco.com на срок действия с 20 сентября 2019 года по 20 сентября 2021 года.
Как показано на следующем рисунке, цифровой сертификат содержит дополнительную информацию, которая хранится с использованием стандарта X.509:
Далее давайте рассмотрим, как создается цифровая подпись и ее роль в PKI.
Цифровая подпись
При совершении деловых операций на документах требуется подпись, чтобы гарантировать, что сделка санкционирована соответствующим лицом. Такая же концепция требуется в сети, так что цифровая подпись отправляется вместе с сообщением на конечный хост. Затем узел назначения может использовать цифровую подпись для проверки подлинности сообщения.
При использовании PKI используются следующие алгоритмы для создания и проверки цифровых подписей:
DSA
RSA
Elliptic Curve Digital Signature Algorithm (ECDSA)
Чтобы создать цифровую подпись, между Алисой (отправителем) и Сергеем Алексеевичем (получателем) происходит следующий процесс:
1) Алиса будет использовать алгоритм хеширования для создания хэша (дайджеста) сообщения:
2) Затем Алиса будет использовать свой закрытый ключ для шифрования хэша (дайджеста) сообщения:
Цифровая подпись используется в качестве доказательства того, что Алиса подписала сообщение.
Чтобы лучше понять, как используются цифровые подписи в реальной жизни, давайте представим, что в сети есть два пользователя. Алиса хочет отправить Сергею Алексеевичу сообщение. Алиса может использовать цифровую подпись с сообщением, чтобы заверить Сергея Алексеевича в том, что сообщение исходило именно от нее. Это шаги, которые Алиса будет использовать для обеспечения подлинности, целостности и неотрицания:
Алиса создаст пару открытых и закрытых ключей для шифрования данных.
Алиса даст Сергею Алексеевичу только открытый ключ. Таким образом, закрытый ключ хранится у Алисы.
Алиса создаст сообщение для Сергея Алексеевича и создаст хэш (дайджест) сообщения.
Затем Алиса будет использовать закрытый ключ для шифрования хэша (дайджеста) сообщения для создания цифровой подписи.
Алиса отправит сообщение и цифровую подпись Сергею Алексеевичу.
Сергей Алексеевич будет использовать открытый ключ Алисы для расшифровки цифровой подписи, чтобы получить хэш сообщения.
Сергей Алексеевич также сгенерирует хэш сообщения и сравнит его с хэшем, полученным из цифровой подписи Алисы. Как только два значения хэша (дайджеста) совпадают, это просто означает, что сообщение подписано и отправлено Алисой.
Цифровые подписи используются не только для проверки подлинности сообщений. Они также используются в следующих случаях:
Цифровые подписи для цифровых сертификатов: это позволяет отправителю вставить цифровую подпись в цифровой сертификат.
Цифровые подписи для подписи кода: это позволяет разработчику приложения вставить свою цифровую подпись в исходник приложения, чтобы помочь пользователям проверить подлинность программного обеспечения или приложения.
На следующем рисунке показан пример приложения, содержащего цифровой сертификат:
На следующем рисунке показана дополнительная проверка цифровой подписи подписавшего:
Система доверия PKI
Ранее мы узнали, что организация может получить цифровой сертификат от доверенного центра сертификации в Интернете. Однако во многих крупных организациях вы обычно найдете корневой ЦС и множество промежуточных ЦС. Корневой ЦС отвечает за создание первичного цифрового сертификата, который затем делегируется каждому подчиненному ЦС или промежуточному ЦС. Промежуточный ЦС будет использовать цифровой сертификат корневого сервера для создания новых цифровых сертификатов для конечных устройств, таких как внутренние серверы.
На следующем рисунке показана иерархия корневого и промежуточного ЦС:
Использование этого типа иерархической структуры снимает нагрузку с корневого центра сертификации по управлению всеми цифровыми сертификатами в организации. Некоторые из этих обязанностей делегированы промежуточным серверам ЦС в сети. Представьте, что в вашем головном офисе вы развернули корневой ЦС, а в каждом удаленном филиале развернули промежуточные ЦС. Следовательно, каждый промежуточный ЦС отвечает за управление сертификатами своего собственного домена или филиала. Это также снижает риски взлома корневого ЦС злоумышленником, так что в случае взлома промежуточного ЦС корневой ЦС может быть отключен от сети, не затрагивая другие конечные устройства или промежуточные ЦС.
В небольших сетях можно развернуть один корневой ЦС для предоставления цифровых сертификатов каждому конечному устройству, как показано на следующем рисунке:
Как показано на предыдущем рисунке, одним ЦС легко управлять. Однако по мере роста сети наличие единственного центра сертификации в сети не позволит легко масштабироваться, поэтому необходимо использовать иерархическую структуру с корневым центром сертификации и промежуточными (подчиненными) центрами сертификации.
При написании некоторых скриптов бывает нужно обратиться какому-либо ресурсу. Это может быть HTTP/HTTPS запрос какой-нибудь HTML странички сайта, FTP запрос на скачивание файла или же, это может быть GET/POST запрос к удалённому ресурсу, для передачи на него какой-либо информации.
Для этих целей в роутерах MikroTik предусмотрен инструмент Fetch, о нём и поговорим.
Инструмент Fetch позволяет настроить отправку HTTP и FTP запросов к сетевому ресурсу, чтобы скопировать с, или же загрузить на него определённые данеые (web-страничка, файл). Поддержка HTTPS включена по умолчанию, проверка сертификатов, предъявляемых сетевыми ресурсами при запросе, не осуществляется. Включить проверку цепочки сертификации можно с помощью опции check-certificate.
Чтобы начать работу с инструментом Fetch, введите команду:
/tool fetch
Далее нужно задавать параметры ресурса, к которому Вы хотите обратиться, метод обращения и данные, которые нужно получить или загрузить на этот ресурс.
Доступны следующие параметры:
address - задаёт IP адрес ресурса, к которому необходимо обратиться;
ascii - включает поддержку ASCII (по умолчанию - no);
check-certificate - включает проверку цепочки сертификации удаленного ресурса;
dst-path - название файла, который нужно скачать и полный путь к нему на удаленном ресурсе;
host - доменное имя ресурса, к которому нужно обратиться. Например - shareit.merionet.ru;
http-method - метод HTTP обращения. Доступны следующие методы: get, post, put, delete. По умолчанию используется get;
http-data - данные, которые нужно отправить на удаленный ресурс, при использовании методов put и post;
http-content-type - идентификатор данных, которые нужно отправить на удаленный ресурс в формате MIME. По умолчанию - application/x-www-form-urlencoded;
keep-result - если данный параметр активирован, то будет создан входной файл;
mode - задаёт протокол, по которому будет осуществляться соединение с удаленным ресурсом. Можно задать http, https, ftp или tftp;
password - задаёт пароль который нужен для аутентификации на удаленном ресурсе. (Используйте только если удаленный ресурс требует аутентификации подключения);
port - порт, по которому будет осуществляться соединение;
src-path - название файла, который нужно загрузить на удаленный ресурс;
upload - если данный параметр активирован, то инструмент fetch будет использоваться именно для загрузки локального файла на удаленный ресурс. При этом требуется, чтобы были указаны src-path и dst-path файла;
url - URL путь к файлу. Может быть использовано вместо address или src-path;
user - имя пользователя, которое нужно ввести для аутентификации на удаленном ресурсе (используйте только если удаленный ресурс требует аутентификации подключения);
Давайте рассмотрим несколько use кейсов, когда Вам может пригодиться инструмент fetch.
Скачивание файла с удаленного ресурса
В статье про защиту роутера MikroTik методом превентивного блокирования адресов из "черных" списков мы уже прибегали к этому методу.
Для этого мы писали такую команду:
/tool fetch address=www.squidblacklist.org host=www.squidblacklist.org mode=http src-path=/downloads/drop.malicious.rsc
В данном случае, мы обращаемся к ресурсу www.squidblacklist.org по протоколу http и скачиваем файл /downloads/drop.malicious.rsc
Допустим, мы имеем дело с FTP сервером, требующим аутентификации, тогда запрос может быть таким:
/tool fetch address=192.168.11.48 src-path=conf.rsc user=admin mode=ftp password=samplepass dst-path=sample.rsc port=21 host="" keep-result=yes
Можно также указать URL, по которому доступен нужный файл для скачивания:
/tool fetch url="https://wiki.merionet.ru/rukovodstvo-administratora-freepbx-na-russkom-yazyke/Rukovodstvo_Administratora_FreePBX_na_russkom_yazyke.pdf" mode=http
Загрузка файлов на удаленный сервер может быть нужна для автоматизации процесса резервного копирования конфигурации роутера
Ниже приведен пример команды для отправки файла с бэкапом по протоколу FTP, на удаленный сервер по адресу 192.168.11.56, который требует аутентификации:
/tool> fetch address=192.168.11.56 src-path=cnfig.rsc user=admin mode=ftp password=samplepass dst-path=backup.rsc upload=yes
Отправление информации на удаленный сервер
С помощью инструмента fetch можно также отправлять информацию на удаленный сервер, используя HTTP запросы. Например, ниже показан пример того, как можно через POST запрос отправить json массив данных на удаленный сервер:
/tool fetch http-method=post http-content-type="application/json" http-data="{ "as": "AS16509 Amazon.com, Inc.", "city": "Boardman", "country": "United States", "countryCode": "US", "isp": "Amazon", "lat": 45.8696, "lon": -119.688, "org": "Amazon", "query": "54.148.84.95", "region": "OR", "regionName": "Oregon", "status": "success", "timezone": "America/Los_Angeles", "zip": "97818" }" url="http://locator.loc/index.php"
Сохранять результат как переменную
В версии RouterOS v6.43, появилась возможность сохранить результат команды fetch в переменную. Это может быть полезно, например, для написания скриптов, которые производят какие-либо действия в зависимости от того, какой был ответ на HTTP запрос.
Например, ниже приведен пример скрипта, который отсылает письмо SERVICE FAILED, если при запросе страницы PHP (check.php) возвратился “0” и SERVICE RUNNING, если запрос был успешно обработан.
{ :local result [/tool fetch url=http://192.168.11.56/check.php as-value output=user]; :if ($result->"status" = "finished") do={ :if ($result->"data" = "0") do={ /tool e-mail send to="mnadmin@mndomain.ru" subject="$[/system identity get name] export" body="$[/system clock get date] SERVICE FAILED; } else={ /tool e-mail send to="mnadmin@mndomain.ru" subject="$[/system identity get name] export" body="$[/system clock get date] SERVICE RUNNING; } } }
Предварительно, нужно чтобы был настроен почтовый сервер - tool e-mail> set server=192.168.1.34 set port=25 from=”mnmikrotik@mndomain.ru”
Кстати, в WinBox нет отдельной реализации инструмента fetch. Однако, мы можем использовать его, когда пишем скрипты через инструмент Scripts. Например, можно туда добавить скрипт, который мы привели выше:
Сложная терминология в некоторых темах, касающихся IT, иногда заводит в тупик. Простой и понятный процесс может быть описан очень комплексным языком, из-за чего, даже после изучения темы, могут остаться вопросы. Это касается и контейнеризации. В рамках этой темы ответим на вопрос - в чем разница между LXC, LXD и LXCFS.
О LXC
LXC (Linux Containers) представляет собой интерфейс в пользовательской среде, функция которого - сдерживать ядро Linux. Имея в активе эффективный API и набор простых инструментов, LXC дает пользователю возможность администрировать любые использующиеся контейнеры.
Важные характеристики
Текущая версия LXC задействует ряд функций ядра, чтобы обеспечить контейнеризацию следующих процессов:
namespaces (ipc, uts, mount, pid);
профиль AppArmor (та же SELinux);
правила Seccomp;
Chroots (задействуя pivot _root);
потенциал ядра;
группы контроля (CGroups).
Как правило, контейнеры LXC обычно воспринимаются пользователями как нечто усредненное между Chroot и VM. Эта технология нацелена на то, чтобы создать среду, аналогичную стандартно установленной Linux, но сделать это без необходимости в дополнительном ядре.
Компоненты
Ниже в списке, несколько актуальных компонентов LXC:
liblxc;
языковые привязки для AP (Python (2 и 3 ), Lua, Go, Ruby, Haskell);
стандартные инструменты администрирования контейнеров;
готовые варианты контейнеров;
LXD - решение для LXC
LXD (Linux Container Daemon) является базирующимся на LXC гипервизором контейнеров.
Основные части LXD:
системный daemon (lxd);
клиент LXC;
плагин (nova-compute-lxd);
REST API предоставляется демоном в локальном или сетевом режиме. Эффективная утилита управления, клиент командной строки, отличается своей интуитивностью и простотой. Именно с помощью него реализовано управление каждым контейнером. Клиент обрабатывает подключение одновременно к разному количеству контейнеров, отображает уже созданные и создает новые. Есть возможность их перемещения в процессе функционирования.
Упомянутый плагин “превращает” все LXD-host в вычислительные узлы, которые работают для поддержки контейнеров, а не VM.
Преимущества
Основные преимущества LXD:
обеспечение безопасности (контейнеры не обладают привилегированностью, ресурсы ограничиваются и так далее.)
любой масштаб использования;
интуитивность (простое управление через ввод в командной строке);
образ-ориентированность (использование надежных образов, вместо шаблонов);
возможность активной миграции;
Связь с LXC
LXD не является новой версией LXC, скорее, он использует ее как базу. Чтобы администрирование контейнеров стало еще проще, LXD задействует LXC, влияя на библиотеку последней. Также во взаимодействии участвует прослойка, написанная на Go. Таким образом, LXD является, по сути, альтернативой LXC с расширенными возможностями (отличный пример - управление через сеть).
LXCFS: настройка контейнеризации
LXCFS - это небольшая архитектура файлов в среде пользователя, которая способна оптимизировать работу ядра Linux.
LXCFS включает в себя:
файлы, которые монтируются над оригинальными аналогами и предоставляют CGroup-совместимые значения;
дерево cgroupfs, функционирующее в независимости от контейнеров.
Архитектура представляет из себя простой код, созданный в C. Задача, которую необходимо было решить - запуск контейнера systemdпод базовым пользователем с параллельным запуском systemd внутри контейнера, с целью взаимодействовать с cgroups.
Если говорить простым языком, цель создания этой архитектуры - ощущение активного контейнера, как независимой системы.
Так в чем же разница?
Сравнивать LXC, LXD, LXCFS не имеет смысла, так как они не представляют из себя 3 разных продукта с одинаковым функционалом. Грубо можно описать их как программу, дополнение к ней и патч, который позволяет среде пользователя адаптироваться под ее нужды.