По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Протокол Syslog - это способ для сетевых устройств отправлять сообщения о событиях на сервер регистрации - обычно известный как Syslog сервер. Этот протокол поддерживается широким спектром устройств и может использоваться для регистрации различных типов событий. Например, маршрутизатор может отправлять сообщения о том, что пользователи подключаются через консоль, а веб-сервер может регистрировать события, в которых отказано в доступе. Большинство сетевых устройств, таких как маршрутизаторы и коммутаторы, могут отправлять сообщения системного журнала. Кроме того, серверы *nix также могут генерировать данные системного журнала, как и большинство брандмауэров, некоторые принтеры и даже веб-серверы, такие как Apache. Серверы на базе Windows изначально не поддерживают Syslog, но большое количество сторонних инструментов позволяет легко собирать данные журнала событий Windows или IIS и пересылать их на сервер Syslog. В отличие от SNMP, Syslog не может использоваться для «опроса» устройств для сбора информации. Например, SNMP имеет сложную иерархическую структуру, которая позволяет станции управления запрашивать у устройства информацию о таких вещах, как данные о температуре или доступное дисковое пространство. Это невозможно с Syslog - он просто отправляет сообщения в центральное место, когда инициируются определенные события. Syslog серверы Syslog - отличный способ объединить логи из нескольких источников в одном месте. Как правило, большинство серверов Syslog имеют несколько компонентов, которые делают это возможным. Syslog слушатель: Syslog сервер должен получать сообщения, отправленные по сети. Процесс прослушивания собирает данные системного журнала, отправленные через 514 UDP порт. Как мы знаем UDP-сообщения не подтверждаются или не гарантируются, поэтому имейте в виду, что некоторые сетевые устройства будут отправлять данные Syslog через 1468 TCP порт для обеспечения доставки сообщений. База данных: большие сети могут генерировать огромное количество данных syslog’а . Хорошие серверы будут использовать базу данных для хранения логов для быстрого поиска. Программное обеспечение для управления и фильтрации: из-за больших объемов данных иногда бывает сложно найти конкретные записи в журнале. Решение состоит в том, чтобы использовать syslog сервер, который автоматизирует часть работы и позволяет легко фильтровать и просматривать важные сообщения журнала. Серверы должны иметь возможность генерировать оповещения, уведомления и алерты в ответ на выбранные сообщения, чтобы администраторы сразу узнавали, когда возникла проблема, и могли предпринять быстрые действия Syslog сообщения Сообщения системного журнала обычно содержат информацию, помогающую определить основную информацию о том, где, когда и почему был отправлен лог: IP-адрес, отметка времени и фактическое сообщение. Системный журнал использует концепцию, называемое “facility”, чтобы идентифицировать источник сообщения на любом компьютере. Например, facility “0” будет сообщением ядра, а facility «11» будет сообщением FTP. Это восходит своими корнями к syslog'а UNIX. В большинстве сетевых устройств Cisco используются коды объектов «Local6» или «Local7». Syslog сообщения также имеют поле уровня серьезности. Уровень серьезности указывает, насколько важным считается сообщение. Серьезность «0» является чрезвычайной ситуацией, «1» - это предупреждение, которое требует немедленных действий, а шкала продолжается вплоть до «6» и «7» - информационных и отладочных сообщений. 0 Emergency Система не работоспособна 1 Alert Система требует немедленного вмешательства 2 Critical Состояние системы критическое 3 Error Сообщения об ошибках 4 Warning Предупреждения о возможных проблемах 5 Notice Сообщения о нормальных, но важных событиях 6 Informational Информационные сообщения 7 Debug Отладочные сообщения Недостатки syslog У протокола syslog есть несколько недостатков. Во-первых, проблема согласованности. Протокол Syslog не определяет стандартный способ форматирования содержимого сообщения - и существует столько же способов форматирования сообщения, сколько существует разработчиков. Некоторые сообщения могут быть удобочитаемыми, а некоторые нет. Syslog это не волнует - он просто предоставляет способ передачи сообщения. Есть также некоторые проблемы, которые возникают из-за того, что syslog использует UDP в качестве транспорта - поэтому возможно потерять сообщения из-за перегрузки сети или потери пакетов. Наконец, есть некоторые проблемы безопасности. В сообщениях syslog’а нет аутентификации, поэтому один компьютер может выдать себя за другой компьютер и отправить ложные события журнала. Он также подвержен повторным атакам. Несмотря на это, многие администраторы считают, что syslog является ценным инструментом, и что его недостатки относительно незначительны.
img
JIT-компиляция – это метод повышения производительности интерпретируемых программ. JIT расшифровывается как Just-in-time. Во время выполнения программа может быть скомпилирована в машинный код для повышения ее производительности. Также этот метод известен как динамическая компиляция. Динамическая компиляция имеет несколько преимуществ перед статической. При запуске приложений на JAVA или C# среда выполнения может профилировать приложение во время его исполнения. Это позволяет создавать более оптимизированный код. Если поведение приложения меняется во время его исполнения, то среда выполнения может перекомпилировать код. Есть некоторые недостатки, заключающиеся в задержках при запуске или непроизводительных издержках при компиляции во время выполнения. Чтобы ограничить эти издержки, многие JIT-компиляторы компилируют только пути кода, которые часто используются. Обзор Традиционно существует два метода преобразования исходного кода в форму, которую можно запустить на платформе. Статистическая компиляция преобразует код в язык для конкретной платформы. Интерпретатор непосредственно выполняет исходный код. JIT-компиляция пытается использовать преимущества обоих. В то время как выполняется интерпретируемая программа, JIT-компилятор определяет участки часто используемого кода и компилирует его в машинный код. В зависимости от компилятора это можно сделать для метода или меньшего участка кода. Впервые динамическая компиляция была описана в статье о языке LISP Дж. Маккарти в 1960 году. Компиляция на лету, JIT или динамическая компиляция – это компиляция, которая выполняется непосредственно во время исполнения программы, а не до этого. Что в этот момент происходит? Перевод в машинный код. Преимущества JIT-компиляции заключаются в том, что поскольку компиляция происходит во время выполнения, то JIT-компилятор имеет доступ к динамической информации времени выполнения, а это в свою очередь позволяет ему оптимизировать процесс (например, встраивать функции). Что важно понимать, когда речь идет о JIT-компиляции? Она скомпилирует байт-код в инструкции машинного кода работающего компьютера. Это означает, что полученный машинный код оптимизирован для архитектуры процессора конкретного компьютера. В качестве примеров JIT-компиляторов можно привести JVM (Java Virtual Machine - виртуальная машина Java) на Java и CLR (Common Language Runtime – общеязыковая исполняющая среда) на C#. История Изначально компилятор отвечал за преобразование языка высокого уровня (выше, чем ассемблер) в объектный код (машинные инструкции), который затем должен был быть связан (линкером) с исполняемой программой. В какой-то момент эволюции языков компиляторы начали компилировать язык высокого уровня в псевдокод, который затем интерпретировался (интерпретатором) для запуска программы. Это исключило объектный код и исполняемые программы и позволило перенести эти языки на несколько операционных систем и аппаратных платформ. Одним из первых был Pascal (который скомпилирован в P-Code); более современными примерами являются Java и C#. Со временем термин P-Code был заменен на байт-код, поскольку большинство псевдоопераций имеют длину в один байт. JIT-компилятор – это функция интерпретатора, которая вместо интерпретации байт-кода при каждом вызове компилирует байт-код в инструкции машинного кода работающей машины, а затем вызывает этот объектный код. В идеальном варианте эффективность выполнения объектного кода должна превзойти неэффективность перекомпиляции программы при каждом ее запуске. Обычный сценарий Исходный код полностью преобразуется в машинный код. JIT-сценарий Исходный код преобразуется в структуру на языке ассемблера, например, IL (промежуточный язык) для C#, ByteCode для Java. Промежуточный код преобразуется в машинный только тогда, когда приложение нуждается в том, чтобы необходимые коды были преобразованы в машинный код. JIT или не JIT При JIT-компиляции не весь код преобразуется в машинный код. Для начала преобразуется только необходимая часть кода. Затем, если вызываемый метод или выполняемые функции находятся не в виде машинного кода, то они тоже будут преобразованы в машинный код. Это снижает нагрузку на ЦП. Поскольку машинный код будет генерироваться во время выполнения, то JIT-компилятор создаст машинный код, оптимизированный для запуска архитектуры ЦП машины. Ниже приведены некоторые примеры JIT-компиляторов: Java: JVM (Java Virtual Machine – виртуальная машина Java) C#: CLR (Common Language Runtime – общеязыковая исполняющая среда) Android: DVM (Dalvik Virtual Machine – виртуальная машина Dalvik) или ART (Android RunTime – среда выполнения Android-приложений) в новых версиях Виртуальная машина Java (JVM) выполняет байт-код и ведет подсчет времени выполнения функции. Если это значение превышает предустановленный порог, то JIT-компилятор компилирует код в машинный код, который в дальнейшем может быть выполнен непосредственно процессором (в отличие от случая, когда javac компилирует код в байт-код, а затем интерпретатор интерпретирует этот байт-код построчно, переводя его в машинный код, и выполняет его). Кроме того, при следующем вычислении функции тот же скомпилированный код выполняется снова, в отличие от обычной интерпретации, когда код повторно интерпретируется построчно. Это значительно ускоряет процесс выполнения программы.
img
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 Ранее мы узнали, что организация может получить цифровой сертификат от доверенного центра сертификации в Интернете. Однако во многих крупных организациях вы обычно найдете корневой ЦС и множество промежуточных ЦС. Корневой ЦС отвечает за создание первичного цифрового сертификата, который затем делегируется каждому подчиненному ЦС или промежуточному ЦС. Промежуточный ЦС будет использовать цифровой сертификат корневого сервера для создания новых цифровых сертификатов для конечных устройств, таких как внутренние серверы. На следующем рисунке показана иерархия корневого и промежуточного ЦС: Использование этого типа иерархической структуры снимает нагрузку с корневого центра сертификации по управлению всеми цифровыми сертификатами в организации. Некоторые из этих обязанностей делегированы промежуточным серверам ЦС в сети. Представьте, что в вашем головном офисе вы развернули корневой ЦС, а в каждом удаленном филиале развернули промежуточные ЦС. Следовательно, каждый промежуточный ЦС отвечает за управление сертификатами своего собственного домена или филиала. Это также снижает риски взлома корневого ЦС злоумышленником, так что в случае взлома промежуточного ЦС корневой ЦС может быть отключен от сети, не затрагивая другие конечные устройства или промежуточные ЦС. В небольших сетях можно развернуть один корневой ЦС для предоставления цифровых сертификатов каждому конечному устройству, как показано на следующем рисунке: Как показано на предыдущем рисунке, одним ЦС легко управлять. Однако по мере роста сети наличие единственного центра сертификации в сети не позволит легко масштабироваться, поэтому необходимо использовать иерархическую структуру с корневым центром сертификации и промежуточными (подчиненными) центрами сертификации.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59