По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
По статистике, в данный момент более 90% всех заражений происходят по электронной почте. Цифра кажется безумной только на первый взгляд, но, я уверен, вы также открывали множество ссылок и писем просто на полном автомате, или же даже по причине любопытства.
Давайте сначала разберем возможные способы атаки через электронную почту, а затем рассмотрим способы борьбы со злоумышленниками.
Способы и средства атаки
В общем и целом, атаки на электронную почту можно условно разделить на целевые (spear-phishing) и на атаки массового поражения.
В первом случае письмо приходит вам от доверенного человека, чаще всего даже вашего начальника и родственника, и там используется какой-либо посыл для того, чтобы вы открыли файл или же перешли по ссылке. Очевидно, что 99,99% людей попадутся на этот крючок, т.к такие письма ничем не вызывают подозрения - ни доменом, ни смыслом написанного, ни типом вложения. Все выглядит ровно так, как в тысяче других уже открытых прежде вами писем. Но есть нюанс - чаще всего для повышения открываемости таких писем используются психологические приемы. К числу таких приемов относятся призывы к срочности, помощи или жажде наживы, так что если письмо отличается от большинства прочих письма от вашего знакомого/начальника - будьте внимательны.
Во втором случае злоумышленники просто массово рассылают письмо с вредоносной ссылкой или вредоносным файлом, причем зачастую это выглядит как запароленный архив и сам пароль в тексте письма. С такими письмами бороться не в пример проще программно-аппаратными методами, но и ложными фишинговыми рассылками по вашей компании, чтобы бы сразу стал понятен список пользователей, которые склонны открывать такие письма.
По сути, отдельно также можно упомянуть обычный спам, который, казалось бы, совершенно безопасен. Но давайте обратимся к обычной математике: в день сотрудник тратит 30 секунд на удаление/прочтение спам-писем, а в компании 5000 сотрудников. Это значит, что сотрудники тратят в день практически 42 часа на борьбу со спамом. Нехило, да?
Способы и средства защиты
Давайте попробуем проанализировать сказанное выше и подумать, как можно защититься от такого добра, и для анализа возьмем второй сценарий с массовым фишингом.
Для начала нужно проверить домен на его наличие в различным репутационных списках
Оценить домен с помощью Защита вашего e-mail происходит с помощью специальной многоуровневой фильтрации, которая уже выполняет проверку отправляющего сервера на основе представленных данных SPF, DMARC, DKIM;
Оценить вложения на предмет их "злокачественности", то есть прогнать через антивирусные движки и при необходимости "обезвредить" - то есть преобразовать файлы с макросами в pdf формат и пометить письмо как подозрительное;
Отправить вложения в песочницу, если они поступили из странного источника и не отдавать письмо пользователю до получения вердикта;
Проверить ссылки в письме и открыть их через прокси-сервер, для определения точного сайта;
Оценить изображения в письме на предмет спама/вредоносов;
Сравнить содержимое письма с теми шаблонами вредоносных рассылок, которые происходят в мире в данный момент;
SPF - представлен в роли расширения для протокола SMTP. С помощью него возможно проверить подлинность домена отправителя; DMARC - является технической спецификацией, предназначенной для защиты электронной почты от спама и фишинговых писем; DKIM - цифровая подпись. Письмо отправленной из обслуживаемого домена присваивает себе такую подпись;
Использование этих технологий позволяет вам быть уверенным в двух вещах: ваш почтовый домен никто не спуфит, и что отправитель - это легитимный товарищ;
К сожалению, даже эти 7 шагов не являются панацеей, хотя их и можно выполнять автоматически с помощью специализированных решений, вроде Barracuda, Cisco ESA, FortiMail и пр. Касперских.
Кроме того, нужно быть уверенным, что:
Учетные записи не были скомпрометированы;
Ваша почтовый сервер не упадет от DDoS атаки;
Ваши сотрудники используют VPN для доступа к вашему почтовому серверу;
У всех сотрудников установлен антивирус на рабочих станциях;
Вы используете надежное и современное решение по защите почты, а именно - почтовую прокси, к примеру одну из перечисленных выше;
Вы постоянно проводите обучение ваших сотрудников азам ИБ и возможных типов атак с помощью электронной почты;
Вы шифруете исходящую и входящую почту с помощью PGP-ключей;
Обсудим некоторые особенности защиты E-mail от Google, Yandex, Mail.ru
Когда вы используете корпоративную почту от одного из известных IT-гигантов, вы уже оказываетесь защищены многослойной системой безопасностью. Но есть большое "но" - а именно тот факт, что вы не можете тюнинговать эту защиту именно под специфику вашей организации (если не говорить про защиту O365 от Microsoft).
Кроме того, двухфакторная аутентификация также является важной функцией, и все значимые представители облачных почтовых служб дают вам такой функционал. К примеру, Яндекс.Почта имеет двухэтапную систему аутентификации пользователей, а сервис Gmail обеспечивает защиту с помощью токен-ключа. Это может означать только одно, если же вы потеряли свой пароль, то злоумышленник никак не сможет получить доступ к вашей электронной почте без специального кода, пришедшего вам на SMS.
Apache Cassandra — это программное обеспечение для управления базами данных NoSQL. Организации используют его для обработки больших объемов данных распределенным способом. Популярность этого программного обеспечения возросла благодаря высокой доступности и отказоустойчивости.
Для этого Cassandra перешла от концепции главных или именованных узлов к симметричным распределенным узлам P2P. Каждый узел в кластере имеет одно или несколько пространств ключей, содержащих данные.
В этом руководстве вы узнаете, что такое пространство ключей, его компоненты и как создавать, изменять и удалять пространства ключей.
Что такое пространство ключей в Cassandra?
Пространство ключей (Keyspace) — это контейнер данных в Cassandra, похожий на базу данных в системах управления реляционными базами данных (RDMBS). Кластер имеет одно пространство ключей для каждого приложения, столько, сколько необходимо, в зависимости от требований и использования системы. Пространства ключей — это совершенно отдельные объекты, и данные, которые они содержат, не связаны друг с другом.
В кластере Cassandra пространство ключей — это самый внешний объект, который определяет, как данные реплицируются на узлах. Пространства ключей состоят из основных объектов, называемых семействами столбцов (которые похожи на таблицы в СУБД), строк, индексированных по ключам, типам данных, сведениям о центре обработки данных, коэффициенту репликации и стратегии пространства ключей.
Компоненты пространства ключей Cassandra
Есть некоторые важные компоненты пространства ключей, которые необходимо указать при создании пространства ключей. Эти компоненты:
Стратегия репликации
При определении пространства ключей стратегия репликации указывает узлы, на которых будут размещены реплики. Используя несколько узлов для размещения реплик, вы достигаете отказоустойчивости, высокой доступности и надежности.
Возможны две стратегии:
Простая стратегия. Используйте эту стратегию для сред тестирования и разработки, а также если вы не собираетесь развертывать кластер более чем в одном центре обработки данных. Коэффициент репликации применяется ко всему кластеру. Разделитель решает, где разместить первую реплику на узле. Затем другие реплики распределяются по часовой стрелке на следующих узлах независимо от центра обработки данных или местоположения.
Стратегия сетевой топологии. Эта стратегия подходит, когда вам нужно развернуть свой кластер в нескольких центрах обработки данных. Однако вы можете использовать его даже с одним центром обработки данных, чтобы впоследствии расширить его. Стратегия сетевой топологии работает как для продакшена, так и для разработки. Она имеет тенденцию размещать реплики на узлах, которые не находятся в одной стойке, чтобы избежать проблем, когда одна стойка выходит из строя. С помощью этого параметра каждый центр обработки данных может иметь отдельный коэффициент репликации.
Фактор репликации
Этот параметр определяет, сколько реплик строки хранить на каждом узле.
Минимум должно быть две реплики на центр обработки данных. Это означает, что сбой одного узла не влияет на работу группы репликации. Поэтому рекомендуется установить три копии каждой строки на разных узлах для достижения удовлетворительной отказоустойчивости.
Эмпирическое правило заключается в том, чтобы коэффициент репликации оставался таким же, как и количество узлов.
Базовый синтаксис пространства ключей
Вы можете создать пространство ключей с различными настройками репликации. Ниже приведен основной синтаксис для создания пространства ключей:
CREATE KEYSPACE keypsace_name WITH replication = {properties};
Свойства (properties) включают в себя различные параметры, такие как стратегия репликации, коэффициент или долговременная запись.
Примечание. Команды CQL заканчиваются точкой с запятой (;). Если вы не используете точку с запятой в конце запроса, система будет ждать дополнительного ввода.
Создать пространство ключей с помощью Cqlsh
Чтобы создать пространство ключей, запустите оболочку CQL:
cqlsh
Затем, следуя базовому синтаксису, создайте пространство ключей с нужным именем и настройками репликации.
В этом случае мы создадим test_keyspace с SimpleStrategy и replication_factor 3:
CREATE KEYSPACE test_keyspace
WITH replication = {'class':'SimpleStrategy', 'replication_factor' : 3};
Используйте приведенный выше пример, если вы не собираетесь расширяться до нескольких центров обработки данных. Кроме того, если у вас есть только один узел и вы используете Cassandra для тестирования, вы можете установить replication_factor равным 1.
Для производственных сред и нескольких центров обработки данных создайте пространство ключей со стратегией репликации сетевой топологии.
Для этого введите:
CREATE KEYSPACE keyspace_network_topology
WITH replication = {'class':'NetworkTopologyStrategy', 'datacenter1' : 3};
Имя центра обработки данных по умолчанию — datacenter1. Чтобы проверить имя вашего центра обработки данных, закройте оболочку CQL и используйте nodetool:
nodetool status
Если у вас несколько центров обработки данных, перечислите их все в запросе с соответствующими коэффициентами репликации.
Например, запрос для двух центров обработки данных выглядит так:
CREATE KEYSPACE keyspace_network_topology
WITH replication = {'class':'NetworkTopologyStrategy', 'datacenter1' : 3, 'datacenter2' : 3};
Проверить ключевое пространство
Поскольку в выводе нет ответа об успешном создании пространства ключей, используйте эту команду, чтобы убедиться, что пространство ключей находится в списке:
DESCRIBE KEYSPACES;
Система возвращает список всех доступных пространств ключей Cassandra. Мы выделили два пространства ключей, которые мы создали в приведенных выше примерах. Есть пара пространств ключей по умолчанию, которые поставляются с установкой Cassandra.
Отключить устойчивую запись (Durable Writes)
В Cassandra конфигурация durable_writes по умолчанию имеет значение true. Вы можете отключить его, но только для NetworkTopologyStrategy. Этот параметр сообщает Cassandra, следует ли ей использовать журнал фиксации для внесения обновлений в выбранное пространство ключей.
Когда вы пытаетесь отключить durable_writes при создании пространства ключей с помощью SimpleStrategy, вы получаете предупреждение не делать этого. Причина в том, что вы можете потерять свои данные, если вы не синхронизировали данные из memtable в sstable, и ваш дата-центр выйдет из строя.
Чтобы отключить durable_writes при создании пространства ключей, введите этот запрос:
CREATE KEYSPACE keyspace_durwrites
WITH replication = {'class':'NetworkTopologyStrategy', 'datacenter1' : 3}
AND DURABLE_WRITES = false;
Проверка устойчивых операций записи
Вы можете проверить запрос, который использовался при создании пространства ключей, описав пространство ключей. Также появляется часть durable_writes:
DESCRIBE keyspace_durwrites
Чтобы проверить настройки durable_writes для всех пространств ключей, запросите system_schema:
SELECT * FROM system_schema.keyspaces;
В выходных данных показаны все пространства ключей и их настройки, включая durable_writes.
Использование пространства ключей
Чтобы выбрать пространство ключей в Cassandra и выполнить над ним действия, используйте ключевое слово USE.
Синтаксис:
USE keyspace_name
Например:
USE keyspace_durwrites;
Оболочка CQL переключается на указанное вами имя пространства ключей. Чтобы изменить текущее пространство ключей, используйте ту же команду с другим именем.
Примечание. Всякий раз, когда вы создаете таблицу в Cassandra, вы начинаете с определения пространства ключей.
Изменить ключевое пространство
После создания пространства ключей вы можете изменить конфигурацию с помощью ключевого слова ALTER.
Единственное, что вы не можете изменить, это имя пространства ключей. Помимо этого, вы можете изменить стратегию репликации, коэффициент репликации и устойчивые записи.
Чтобы изменить пространство ключей, следуйте тому же синтаксису, что и при его создании, но используйте ALTER вместо CREATE. Измените значения, которые вы хотите.
Например:
ALTER KEYSPACE keyspace_durwrites
WITH replication = {'class':'NetworkTopologyStrategy', 'datacenter1' : 2}
AND DURABLE_WRITES = true;
Чтобы убедиться, что изменения вступили в силу, используйте ключевое слово DESCRIBE:
На изображении выше показана конфигурация пространства ключей до и после изменения.
Удалить ключевое пространство
Если вы отбросите ключевое пространство, оно будет удалено из системы. Ключевое слово DROP удаляет из пространства ключей все семейства столбцов, а также индексы и типы данных.
Чтобы удалить пространство ключей в Cassandra, используйте этот синтаксис:
DROP keyspace_name;
Например:
DROP keyspace_durwrites;
Чтобы убедиться, что вы удалили пространство ключей, снова используйте запрос DESCRIBE.
Итоги
Выполнив шаги, описанные в этом руководстве, вы сможете успешно создать пространство ключей в Cassandra. Примеры в этом руководстве показали вам, как создать пространство ключей для разных сред и с разными настройками.
Мы также показали вам, как изменить и удалить ключевое пространство, если вам нужно внести какие-либо изменения.
Понимать состояние ваших серверов с точки зрения их загрузки и производительности - крайне важная задача. В этой статье мы опишем несколько самых популярных методов для проверки и мониторинга загрузки ЦПУ на Linux хосте.
Методы проверки
Проверяем загрузку процессора с помощью команды top
Отличным способом проверки загрузки является команда top. Вывод этой команды выглядит достаточно сложным, зато если вы в нем разберетесь, то точно сможете понять какие процессы занимают большую часть ваших вычислительных мощностей.
Команда состоит всего из трех букв: top
У вас откроется окно в терминале, которое будет отображать запущенные сервисы в реальном времени, долю системных ресурсов, которую эти сервисы потребляют, общую сводку по загрузке CPU и т.д
Будем идти по порядку: первая строчка отображает системное время, аптайм, количество активных пользовательских сессий и среднюю загруженность системы. Средняя загруженность для нас особенно важна, т.к дает понимание о среднем проценте утилизации ресурсов за некоторые промежутки времени.
Три числа показывают среднюю загрузку: за 1, 5 и 15 минут соответственно. Считайте, что эти числа - это процентная загрузка, т.е 0.2 означает 20%, а 1.00 - стопроцентную загрузку. Это звучит и выглядит достаточно логично, но иногда там могут проскакивать странные значения - вроде 2.50. Это происходит из-за того, что этот показатель не прямое значение загрузки процессора, а нечто вроде общего количества "работы", которое ваша система пытается выполнить. К примеру, значение 2.50 означает, что текущая загрузка равна 250% и ваша система на 150% перегружена.
Вторая строчка достаточна понятна и просто показывает количество задач, запущенных в системе и их текущий статус.
Третья строчка позволит вам отследить загрузку ЦПУ с подробной статистикой. Но здесь нужно сделать некоторые комментарии:
us: процент времени, когда ЦПУ был загружен и которое было затрачено на user space (созданные/запущенные пользователем процессы)
sy: процент времени, когда ЦПУ был загружен и которое было затрачено на на kernel (системные процессы)
ni: процент времени, когда ЦПУ был загружен и которое было затрачено на приоритезированные пользовательские процессы (системные процессы)
id: процент времени, когда ЦПУ не был загружен
wa: процент времени, когда ЦПУ ожидал отклика от устройств ввода - вывода (к примеру, ожидание завершения записи информации на диск)
hi: процент времени, когда ЦПУ получал аппаратные прерывания (например, от сетевого адаптера)
si: процент времени, когда ЦПУ получал программные прерывания (например, от какого-то приложения адаптера)
st: сколько процентов было "украдено" виртуальной машиной - в случае, если гипервизору понадобилось увеличить собственные ресурсы
Следующие две строчки показывают сколько занято/свободно оперативно памяти и файла подкачки, и не так релевантны относительно задачи проверки нагрузки на процессор. Под информацией о памяти вы увидите список процессов и процент ЦПУ, который они тратят.
Также вы можете нажимать на кнопку t, чтобы прокручивать между различными вариантами вывода информации и использовать кнопку q для выхода из top
Немного более модный способ: htop
Существует более удобная утилита под названием htop, которая предоставляет достаточно удобный интерфейс с красивым форматированием. Установка утилиты экстремально проста:Для Ubuntu и Debian:
sudo apt-get install htop
Для CentOS и Red Hat:
yum install htop
Для Fedora:
dnf install htop
После установки просто введите команду ниже:
htop
Как видно на скриншоте, htop гораздо лучше подходит для простой проверки степени загрузки процессора. Выход также осуществляется кнопкой q
Прочие способы проверки степени загрузки ЦПУ
Есть еще несколько полезных утилит, и одна из них (а точнее целый набор) называется sysstat.Установка для Ubuntu и Debian:
sudo apt-get install sysstat
Установка для CentOS и Red Hat:
yum install sysstat
Как только вы установите systat, вы сможете выполнить команду mpstat - опять же, практически тот же вывод, что и у top, но в гораздо лаконичнее.
Следующая утилита в этом пакете это sar. Она наиболее полезна, если вы ее вводите вместе с каким-нибудь числом, например 6. Это определяет временной интервал, через который команда sar будет выводить информацию о загрузке ЦПУ.
К примеру, проверяем загрузку ЦПУ каждые 6 секунд:
sar 6
Если же вы хотите остановить вывод после нескольких итераций, например 10, добавьте еще одно число:
sar 6 10
Так вы также увидите средние значения за 10 выводов.
Как настроить оповещения о слишком высокой нагрузке на процессор
Одним из самых правильных способов является написание простого bash скрипта, который будет отправлять вам алерты о слишком высокой степени утилизации системных ресурсов.
#!/bin/bash
CPU=$(sar 1 5 | grep "Average" | sed 's/^.* //')
CPU=$( printf "%.0f" $CPU )
if [ "$CPU" -lt 20 ]
then
echo "CPU usage is high!" | sendmail admin@example.com
fi
Скрипт будет использовать обработчик sed и среднюю загрузку от команды sar. Как только нагрузка на сервер будет превышать 85%, администратор будет получать письмо на электронную почту. Соответственно, значения в скрипте можно изменить под ваши требования - к примеру поменять тайминги, выводить алерт в консоль, отправлять оповещения в лог и т.д.
Естественно, для выполнения этого скрипта нужно будет запустить его по крону:
crontab -e
Для ежеминутного запуска введите:
* * * * * /path/to/cpu-alert.sh
Заключение
Соответственно, лучшим способом будет комбинировать эти способы - например использовать htop при отладке и экспериментах, а для постоянного контроля держать запущенным скрипт.