Простой пример того, как реализовать анимацию пульсации, используя HTML и CSS. <pre class="ql-syntax" spellcheck="false">&lt;span class="pulse"&gt;&lt;/span&gt;
﻿
.pulse {
&nbsp; margin:100px;
&nbsp; display: block;
&nbsp; width: 22px;
&nbsp; height: 22px;
&nbsp; border-radius: 50%;
&nbsp; background: #cca92c;
&nbsp; cursor: pointer;
&nbsp; box-shadow: 0 0 0 rgba(204,169,44, 0.4);
&nbsp; animation: pulse 2s infinite;
}
.pulse:hover {
&nbsp; animation: none;
}

@-webkit-keyframes pulse {
&nbsp; 0% {
&nbsp;&nbsp;&nbsp; -webkit-box-shadow: 0 0 0 0 rgba(204,169,44, 0.4);
&nbsp; }
&nbsp; 70% {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -webkit-box-shadow: 0 0 0 10px rgba(204,169,44, 0);
&nbsp; }
&nbsp; 100% {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -webkit-box-shadow: 0 0 0 0 rgba(204,169,44, 0);
&nbsp; }
}
@keyframes pulse {
&nbsp; 0% {
&nbsp;&nbsp;&nbsp; -moz-box-shadow: 0 0 0 0 rgba(204,169,44, 0.4);
&nbsp;&nbsp;&nbsp; box-shadow: 0 0 0 0 rgba(204,169,44, 0.4);
&nbsp; }
&nbsp; 70% {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -moz-box-shadow: 0 0 0 10px rgba(204,169,44, 0);
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; box-shadow: 0 0 0 10px rgba(204,169,44, 0);
&nbsp; }
&nbsp; 100% {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -moz-box-shadow: 0 0 0 0 rgba(204,169,44, 0);
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; box-shadow: 0 0 0 0 rgba(204,169,44, 0);
&nbsp; }
}
</pre>

64f2a101fa89b99e50efbeee62834646_puls.gif

Простой пример того, как реализовать анимацию пульсации, используя HTML и CSS

CSS анимация пульсации

Всем привет! 🖖В этой статье я расскажу об основных моментах документирования кода в Rust. Из коробки Rust предоставляет инструмент rustdoc. Его основная задача - генерация документации для Rust проекта. Если просто, то он берет соответствующие Markdown комментарии к коду и сам код и преобразует их в красивое HTML-CSS-JS представление, в сайт. Вызывать команду rustdoc можно напрямую, либо используя cargo. Я предпочитаю второй вариант. Перейдите в вашу рабочую директорию, откройте в ней окно терминала и создайте новый Rust проект:cargo new --lib rust_doc &amp;&amp; cd rust_doc Выполните в термине следующую команду:cargo doc --open В открывшемся окне браузера вы увидите базовый, пока что пустой, сайт с документацией к вашему проекту. Давайте напишем немного кода. Откройте проект rust_doc в вашем любимом редакторе, лично я работаю в Visual Code, а затем откройте файл lib.rs, который находится в папке src. Создадим вначале файла lib.rs структуру Employee и определим у нее базовую функцию инициализации new, которая принимает на входе имя, фамилию и должность сотрудника, а возвращает instance структуры Employee: <pre class="ql-syntax" spellcheck="false">pub struct Employee {
 pub name: String,
 pub lastname: String,
 pub job_title: String,
}

impl Employee {
 pub fn new(name: String, lastname: String, job_title: String) -&gt; Person {
 return Employee {
 name,
 lastname,
 job_title,
 };
 }
}
</pre> Теперь можем приступить к документированию кода.Добавьте в самое начало файла lib.rs следующий фрагмент кода, после чего выполните в консоли cargo doc --open: <pre class="ql-syntax" spellcheck="false">//! # rust_doc библиотека 
﻿//! *Она создана для понимания базовых 
﻿//! основ документирования кода в Rust*
</pre> Обратите внимание на изменения, которые произошли в документации.Теперь давайте задокументируем структуру Employee, после внесения изменений в код вызовите документацию и посмотрите, что изменилось: <pre class="ql-syntax" spellcheck="false">/// ## Структура сотрудника
/// Она предназначена для представления персональной инофмации о сотруднике
pub struct Employee {
 /// Имя сотрудникаpub 
 ﻿name: String,
 /// Фамилия сотрудникаpub 
 lastname: String, 
 /// Должность сотрудникаpub 
 job_title: String, 
}
</pre> Самое время задокументировать инициализатор, но с добавлением вишенки на торте - написанием теста функции. После изменения кода изучите результат вызываю cargo doc --open. <pre class="ql-syntax" spellcheck="false">/// Определение базовых функций
impl Employee {
&nbsp;&nbsp;&nbsp; /// Функция инициализации инстанса нового сотрудника
&nbsp;&nbsp;&nbsp; /// ```
&nbsp;&nbsp;&nbsp; /// use rust_doc::Employee;
&nbsp;&nbsp;&nbsp; /// let emp = Employee::new("Иван".to_string(),"Иванов".to_string(),"Директор".to_string());
&nbsp;&nbsp;&nbsp; /// assert!(emp.name == "Иван");
&nbsp;&nbsp;&nbsp; /// assert!(emp.lastname == "Иванов");
&nbsp;&nbsp;&nbsp; /// assert!(emp.job_title == "Директор");
&nbsp;&nbsp;&nbsp; /// ```
&nbsp;&nbsp;&nbsp; pub fn new(name: String, lastname: String, job_title: String) -&gt; Employee {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return Employee {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; lastname,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; name,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; job_title,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; };
&nbsp;&nbsp;&nbsp; }
} 
</pre> То, что в коде, в комментариях к функции, находится после ``` - это и есть наш тест. Давайте запустим его. Вызовите в консоли следующую команду:cargo test --doc --package rust_doc -- Employee::new --nocapture Тест пройден успешно. Обратите внимание, что при написании документации я использовал обычный синтаксис Markdown разметки. Документировать нужно, почти, все, чтобы не искать вручную не задокументированные строки кода, добавьте в начало main или lib файла следующий код, с помощью которого вы будете получать подсказки, если что-то не задокументировали:#![warn(missing_docs)] Важно! Если вы пишите описание самого проекта, которое обычно располагается в lib или main файле, то начинайте с символов //!, если же описываете непосредственно код, то документируйте с помощью ///. Вот краткий экскурс в документирование Rust. Более подробно про документирование можно почитать <a href="https://doc.rust-lang.org/rustdoc/write-documentation/what-to-include.html" rel="noopener noreferrer" target="_blank">здесь</a>.

558111a40d3ab1b1ab9aaa9bda155881_rust_doc.jpg

В этой статье рассмотрим то, как происходит документирование в Rust и рассмотрим очень полезную возможность - написание тестов через документирование.

rust

Документирование кода в языке программирования Rust

Всем привет! 🖖Сегодня мы начинаем погружаться в увлекательный мир информационной безопасности, а если точнее, то в один из его значительных подразделов - тестирование на проникновение. <h2>Что такое тестирование на проникновение (Пентест)?</h2> Корпоративная сеть предприятия бывает внешняя, которая объединяет различные сервера и прочие удаленные устройства, и внутренняя(локальная сеть), которая объединяет в сеть устройства предприятия находящиеся в пределах локации офиса. Каждое из этих устройств выполняет какую-то функцию, например сервер для корпоративного сайта, хранилище данных или рабочий компьютер сотрудника. Как у операционных систем, так и у программ, могут быть слабые места. Если правильно надавить на эти слабые места, то можно получить доступ к управлению устройством(-ами), а далее с помощью определенных методов захватить всю корпоративную сеть. Таким образов можно разделить пентест на внешний и внутренний. Подробнее об этом поговорим в разделе «Основные этапы тестирования». Таким образом пентест - это моделирование хакерской атаки, которая нацелена на поиск и компрометацию уязвимых устройств во внешней и внутренней сети предприятия, либо в глобальной сети интернет в целом, с целью кражи данных или выведения из устройства из рабочего состояния. <h2>Методолгии тестирования</h2> Методы «белого ящика». В этой группе тестов испытатель хорошо знает проверяемую систему и имеет полный доступ ко всем ее компонентам. Испытатели работают с клиентом и имеют доступ к закрытой информации, серверам, запущенному программному обеспечению, сетевым схемам, а иногда даже к учетным данным. Этот тип испытаний обычно проводится для проверки новых приложений перед их вводом в эксплуатацию, а также для регулярной проверки системы в рамках ее жизненного цикла - Systems Development Life Cycle (SDLC). Такие мероприятия позволяют выявить и устранить уязвимости раньше, чем они могут попасть в систему и навредить ей. Методы «черного ящика». Эта группа тестов применима, когда испытателю ничего не известно об испытуемой системе. Этот тип тестирования в наибольшей степени похож на настоящие атаки злоумышленника. Испытатель должен получить всю информацию, творчески применяя имеющиеся у него в распоряжении методы и инструменты, но не выходя за рамки заключенного с клиентом соглашения. Но и этот метод имеет свои недостатки: хотя он и имитирует реальную атаку на систему или приложения, испытатель, используя только его, может пропустить некоторые уязвимости. Это очень дорогой тест, так как занимает большое количество времени. Выполняя его, испытатель изучит все возможные направления атаки и только после этого сообщит о результатах. Кроме того, чтобы не повредить проверяемую систему и не вызвать сбой, испытатель должен быть очень осторожным. Методы «серого ящика». Тест учитывает все преимущества и недостатки первых двух тестов. В этом случае испытателю доступна только ограниченная информация, позволяющая провести внешнюю атаку на систему. Испытанияобычно выполняются в ограниченном объеме, когда испытатель немного знает о системе. Пример информации - диапазон IP адресов, которые необходимо проверить на уязвимость. <h2>Заключение</h2> Тестирование на проникновение - это очень большой и значимый раздел информационной безопасности. Он помогает многим компаниям по всему миру снизить риски компрометации устройств, выявить недобросовестный персонал. С каждой новой статье на эту тематику мы будем глубже погружаться в мир пентеста. В следующей публикации мы рассмотрим, в общих чертах, из каких этапов состоит классическое тестирование на проникновение.

7a9a9370893487919b036e36f0809599_pentes.jpg

Начинаем рассматривать один из основных методов оценки безопасности компьютерных систем и сетей на предмет потенциальных уязвимостей - тестирование на проникновение

pentest

infosec

Знакомьтесь,  Пентест

Всем привет! 🖖В этой статье мы начнем рассматривать фундаментальную модель сетевого взаимодействия - OSI. Уже к 70-м годам существовало множество различных стеков коммуникационных протоколов: TCP/IP, IBM SNA и другие. Подобное разнообразие породило проблему несовместимости устройств, использующих разные протоколы. В начале 80-х ISO (International Standards Organization) и ITU (International Telecommunications Union) разработали стандартную модель взаимодействия открытых систем (OSI). Модель OSI определяет:<ol><li>уровни взаимодействия;</li><li>стандартные названия уровней;</li><li>функции уровней.</li></ol> Средства взаимодействия в модели OSI делятся на семь уровней:<ul><li>прикладной (application layer);</li><li>представления (presentation layer);</li><li>сеансовый (session layer);</li><li>транспортный (transport layer);</li><li>сетевой (network layer);</li><li>канальный (data link layer);</li><li>физический (physical layer).</li></ul> Давайте, абстрактно, рассмотрим как происходит взаимодействие по модели OSI между двумя приложениями. Предположим, у нас есть два приложения A и B, которые запущены на разных компьютерах. Приложение А это браузер, а приложение B это сервер интернет-магазина. Они обмениваются различными сообщениями, например информацией о товарах или заказах. <img src="https://storage.yandexcloud.net/galiullin/osi.jpeg"> Браузер с помощью системных вызовов операционной системы, образующих API, отправляет запросы к системным средствам прикладного уровня с просьбой передать запрос на сервер-интернет магазина. Далее это сообщение проходит через каждый уровень, который отвечает за конкретную функцию, например уровень представления за перекодировку сообщения. На каждом уровне к сообщению добавляются служебные заголовки уровня, которые будут анализироваться на компьютере, которому адресован запрос (на изображении клетки с цифрами 1-7). Когда сообщение достигает средств физического уровня, который и отвечает за передачу запроса по линиям связи, оно отправляется к адресату. Стоит отметить, что в данном примере хождение по уровням, до момента попадания на линию происходит в рамках процессов на одном компьютере. Когда отправленный запрос доходит до второго компьютера, оно принимается его физическим уровнем и последовательно перемещается вверх уровень за уровнем. На каждом уровне происходит анализ заголовков, присвоенных на уровнях компьютера с браузером. Протоколы нижних четырех уровней обобщенно называют сетевым транспортом, так как они полностью решают задачу транспортировки сообщений с заданным уровнем качества в составных сетях с произвольной топологией и различными технологиями. Оставшиеся три уровня объединяет то, что они тесно связаны с пользовательскими приложениями, предоставляя им высокоуровневые услуги по использованию сетевых ресурсов и сервисов. В следующих статьях мы рассмотрим каждый из уровней более детально.

ade4563e328cb3908e75cda64bbbc7dc_cover_osi.jpg

В этой статье начинаем рассматривать фундаментальную модель сетевого взаимодействия - OSI

CSS анимация пульсации

Документирование кода в языке программирования Rust

Знакомьтесь, Пентест

Знакомство с моделью OSI