После моей публикации обзора VDSina один комментатор справедливо заметил, что не совсем корректно приводить в статье показатели PageSpeed Insights для пустого сайта. И приложил скриншот значений для этого блога. Которые, конечно, были далеки от идеала. Читать
Как настроить mod_jk на HTTP-сервере Apache
Mod_jk — это модуль или коннектор Apache, который соединяет контейнер сервлетов Apache Tomcat с веб-серверами, такими как Apache, IIS и другими. Mod_jk — это полная замена старого модуля mod_jser, который обрабатывает связь между Tomcat и HTTP-серверами с использованием протокола Apache JServ.
Мы не будем углубляться в работу модуля mod_jk, поскольку это выходит за рамки данной статьи. Вместо этого мы сосредоточимся на том, как интегрировать его с HTTP-сервером Apache.
Узнайте больше о том, как работает mod_jk.
Шаг 1. Загрузите и установите mod_jk
Первым шагом является загрузка модуля mod_jk для Linux и его сборка для веб-сервера Apache. Если вы работаете в Windows, вы найдете предварительно созданный двоичный файл для настройки mod_jk.
Откройте терминал и введите команду:
wget https://dlcdn.apache.org/tomcat/tomcat-connectors/jk/tomcat-connectors-1.2.48-src.tar.gz
После загрузки пакета распакуйте его как:
tar xvf tomcat-connectors-1.2.48-src.tar.gz
Затем перейдите в извлеченный каталог /native как:
cd tomcat-connectors-1.2.48-src/native/
Находясь в собственном каталоге, выполните команду:
./configure -with-apxs=/usr/bin/apxs
Приведенная выше команда устанавливает путь к инструментам apxs для HTTP-сервера Apache. Если вы не знаете расположение инструментов apxs, используйте команду which как:
which apxs /usr/bin/apxs
Если вы получили пустой результат, вам необходимо установить пакет apache dev с помощью команды:
sudo apt install apache2-dev # или yum install httpd-devel
Следующим шагом является создание системного объектного файла для модуля mod_jk.
Используйте команду make в собственном каталоге.
make
После успешного завершения вы должны увидеть каталог apache-2.0, созданный в собственном каталоге.
Вы должны увидеть в каталоге файл mod_jk.so.
Скопируйте файл mod_jk.so в каталог модулей apache. Он должен находиться в /usr/lib/apache2/modules или /etc/httpd/modules.
sudo cp mod_jk.so /usr/lib/apache2/modules/
Шаг 2: Загрузите модуль mod_jk
После того, как мы добавили модуль mod_jk в каталог модулей Apache HTTPD, нам нужно загрузить его, отредактировав файл httpd.conf.
В каталоге conf отредактируйте файл httpd.conf с помощью вашего любимого текстового редактора? например Vim.
vim /etc/apache2/apache2.conf
Затем нам нужно добавить директиву include в файл конфигурации apache для загрузки модуля. Вы можете узнать, как загрузить модули, с помощью grep.
grep -i ^Include /etc/apache2/apache2.conf
Приведенная выше команда выдаст такой результат, как показано:
IncludeOptional mods-enabled/*.load IncludeOptional mods-enabled/*.conf Include ports.conf IncludeOptional conf-enabled/*.conf IncludeOptional sites-enabled/*.conf
Из файла конфигурации выше, модули расположены в каталоге с поддержкой модов.
Перейдите в каталог /etc/apache2/mods-enabled и создайте файл mod_jk.conf.
cd /etc/apache2/mods-enabled/ && sudo touch mods_jk.conf
Внутри файла добавьте следующие записи.
LoadModule jk_module "/usr/lib/apache2/modules/mod_jk.so" JkWorkersFile /etc/apache2/conf-enabled/workers.properties JkShmFile /etc/apache2/logs/mod_jk.shm JkLogFile /etc/apache2/logs/mod_jk.log JkLogLev JkMount /stat/* stat JkMount /* balancer el debug JkLogOptions +forwardKeySize +ForwardURICompat -ForwardDirectories
В JkWorkersFile мы определяем информацию об узле.
JkLogFile определяет расположение файла журнала.
JkLogLevel устанавливает уровень журнала для отладки
Шаг 3: Настройка файла рабочих
В файле воркера, указанном по пути выше, мы определяем информацию о запущенных серверах приложений.
Вот пример конфигурации:
worker.list=stat worker.jk-status.type=status worker.jk-status.read_only=true worker.tomcat_1.type=ajp13 worker.tomcat_1.port=9001 worker.tomcat_1.host=127.0.0.1 worker.tomcat_2.type=ajp13 worker.tomcat_2.port=9002 worker.tomcat_2.host=127.0.0.1 worker.tomcat_3.type=ajp13 worker.tomcat_3.port=9003 worker.tomcat_3.host=1270.0.0.1 worker.list=balancer worker.balancer.type=lb worker.balancer.balance_workers=tomcat_1,tomcat_2,tomcat_3
После этого у вас должен быть установлен и готов к работе модуль mod_jk на сервере Apache.
Заключение
В этой статье показано, как настроить и использовать модуль mod_jk на сервере HTTPD Apache. Вы можете узнать больше из официальных документов.
Как включить ведение журнала отладки в Apache
Как системный администратор, вам необходимо понимать, что происходит под капотом различных служб в вашей системе. Ведение журнала, вероятно, лучший способ сделать это.
Журналы позволяют собирать информацию о службах и приложениях, запущенных в вашей системе, и сохранять этот журнал в файл для использования в будущем.
Из этой статьи вы узнаете, как собрать подробную информацию о службе Apache Tomcat, включив режим DEBUG.
Как включить ведение журнала отладки Apache Tomcat в Linux
Чтобы включить ведение журнала отладки для Apache Tomcat в Linux, отредактируйте файл logging.properties. Файл находится в каталоге conf корневой установки Apache Tomcat.
Например:
vim /opt/tomcat/conf/logging.properties.
Найдите следующую запись:
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = FINE
Измените значение с FINE на ALL.
Последняя запись должна быть:
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = ALL
Сохраните файл и закройте. Вам нужно будет перезапустить Tomcat Service, чтобы включить уровни журнала.
Если вам не нужны все сообщения журнала от Tomcat, вы можете установить различные уровни, используя уровни журнала JULI, как:
- SEVERE — Сообщения о серьезных сбоях
- WARNING — возможные ошибки
- INFO — Информационные журналы
- FINE — Журналы трассировки
- CONFIG — статические журналы конфигурации
- FINEST — подробные журналы трассировки
- FINER — подробные журналы трассировки
- ALL — все сообщения (режим отладки)
Вы также можете включить ведение журнала для внутренних компонентов Apache Tomcat, изменив следующие значения на all:
org.apache.catalina.session.level=FINE java.util.logging.ConsoleHandler.level=FINE
на:
java.util.logging.ConsoleHandler.level=ALL
Как включить журнал отладки Apache Tomcat в Windows
Предположим, вы запускаете Apache Tomcat на машине с Windows. Вы можете использовать предоставленный интерфейс конфигурации для управления уровнями журнала.
Откройте меню «Пуск» и найдите «Настроить Tomcat».
Запустите приложение и перейдите на вкладку ведения журнала. Выберите уровень журнала и установите его на DEBUG.
Затем нажмите «Применить» и перейдите на вкладку «Общие». Наконец, нажмите «Остановить», а затем «Пуск», чтобы перезапустить службу Apache.
Заключение
В этой статье показано, как включить ведение журнала отладки для Apache Tomcat в системах Windows и Linux.
Спасибо за чтение.
Настройка репликации PostgreSQL в контейнерах Docker
Мы рассмотрим процесс поднятия двух контейнеров с PostgreSQL и настройки репликации данных между ними. Использовать будем систему на базе Linux, однако, сам процесс настройки Docker и репликации не зависит от операционной системы.
Подготовка компьютера
На компьютере, где мы будем запускать наш кластер баз данных должен быть установлен Docker. Также мы сразу рассмотрим развертывание нужной нам инфраструктуры в docker-compose. Для установки необходимой одноименной платформы смотрим инструкцию Установка Docker на Linux.
После мы можем переходить к поднятию контейнеров.
Запуск контейнеров с СУБД
Как говорилось выше, мы будем поднимать наши контейнеры с помощью docker-compose.
Создадим каталог, в котором будем работать:
mkdir -p /opt/docker/postgresql
Переходим в него:
cd /opt/docker/postgresql
Создаем файл для docker-compose:
vi docker-compose.yml
---
services:
postgresql_01:
image: postgres
container_name: postgresql_01
restart: always
volumes:
- /data/postgresql_01:/var/lib/postgresql/data
environment:
POSTGRES_PASSWORD: postgres024
postgresql_02:
image: postgres
container_name: postgresql_02
restart: always
volumes:
- /data/postgresql_02/:/var/lib/postgresql/data
environment:
POSTGRES_PASSWORD: postgres024
* рассмотрим некоторый опции подробнее:
- postgresql_01/postgresql_02 — названия для сервисов, контейнеры для которых мы будем поднимать.
- image — образ, из которого будут создаваться контейнеры. В данном примере мы берем официальный образ postgres.
- container_name — имя, которое будет присвоено контейнеру после его запуска. В нашем примере это postgresql_01 и postgresql_02.
- restart — режим перезапуска. Говорит, в каких случаях наш контейнер должен стартовать.
- volumes — хорошим тоном для работы базы данных в контейнере является проброс каталога хостового компьютера внутрь контейнера. Таким образом, после удаления контейнера данные останутся на компьютере. В нашем примере в каталоге /data будут созданы каталоги postgresql_01 и postgresql_02, которые будут прокинуты в каталог /var/lib/postgresql/data контейнера.
- environment — для первого запуска необходима инициализация базы данных. Без пароля системы выдает ошибку. Поэтому мы задаем переменную среды POSTGRES_PASSWORD.
Запускаем наши контейнеры:
docker-compose up -d
Мы должны увидеть:
Creating postgresql_02 ... done
Creating postgresql_01 ... done
А если вывести список контейнеров:
docker ps
… мы должны увидеть наши два.
Теперь можно переходить к настройке репликации.
Настройка репликации
Условимся, что первичный сервер или master будет в контейнере с названием postgresql_01. Вторичный — postgresql_02. Мы будем настраивать потоковую (streaming) асинхронную репликацию.
Настройка на мастере
Подключаемся к контейнеру docker:
docker exec -it postgresql_01 bash
Заходим под пользователем postgres:
su - postgres
Создаем пользователя, под которым будем подключаться со стороны вторичного сервера:
createuser --replication -P repluser
* в данном примере будет создаваться учетная запись repluser с правами репликации.
Система потребует ввода пароля. Придумываем его и набираем дважды.
Выходим из-под пользователя postgres:
exit
Выходим из контейнера:
exit
Открываем конфигурационный файл postgresql.conf:
vi /data/postgresql_01/postgresql.conf
Приводим к следующием виду некоторые параметры:
wal_level = replica
max_wal_senders = 2
max_replication_slots = 2
hot_standby = on
hot_standby_feedback = on
* где
- wal_level указывает, сколько информации записывается в WAL (журнал операций, который используется для репликации). Значение replica указывает на необходимость записывать только данные для поддержки архивирования WAL и репликации.
- max_wal_senders — количество планируемых слейвов;
- max_replication_slots — максимальное число слотов репликации (данный параметр не нужен для postgresql 9.2 — с ним сервер не запустится);
- hot_standby — определяет, можно или нет подключаться к postgresql для выполнения запросов в процессе восстановления;
- hot_standby_feedback — определяет, будет или нет сервер slave сообщать мастеру о запросах, которые он выполняет.
Посмотрим подсеть, которая используется для контейнеров с postgresql:
docker network inspect postgresql_default | grep Subnet
В моем случае, ответ был:
"Subnet": "172.19.0.0/16",
Теперь открываем файл:
vi /data/postgresql_01/pg_hba.conf
И добавляем строку после остальных «host replication»:
host replication all 172.19.0.0/16 md5
* в данном примере мы разрешили подключение пользователю replication из подсети 172.19.0.0/16 с проверкой подлинности по паролю.
Перезапустим докер контейнер:
docker restart postgresql_01
Настройка на слейве
Выполним настройку вторичного сервера. Для начала, удалим содержимое рабочего каталога вторичной базы:
rm -r /data/postgresql_02/*
* в данном примере мы удалим все содержимое каталога /data/postgresql_02.
Мы должны быть уверены, что в базе нет ничего важного. Только после этого стоить удалять данные.
Заходим внутрь контейнера postgresql_02:
docker exec -it postgresql_02 bash
Выполняем команду:
su - postgres -c "pg_basebackup --host=postgresql_01 --username=repluser --pgdata=/var/lib/postgresql/data --wal-method=stream --write-recovery-conf"
* где postgresql_01 — наш мастер; /var/lib/postgresql/data — путь до каталога с данными слейва.
Система должна запросить пароль для пользователя repluser — вводим его. Начнется процесс репликации, продолжительность которого зависит от объема данных.
Проверка
Смотрим статус работы мастера:
docker exec -it postgresql_01 su - postgres -c "psql -c 'select * from pg_stat_replication;'"
Смотрим статус работы слейва:
docker exec -it postgresql_02 su - postgres -c "psql -c 'select * from pg_stat_wal_receiver;'"
Источник: https://www.dmosk.ru/miniinstruktions.php?mini=postgresql-replication-docker
👾 Как проверить систему на уязвимости процессора
Клонируйте репозиторий Spectre & Meltdown Checker, чтобы получить ” шелл скрипт для оценки устойчивости вашей системы к нескольким CVE, которые были опубликованы с начала 2018 года, и дать вам рекомендации по их устранению”.
$ git clone https://github.com/speed47/spectre-meltdown-checker.git
Cloning into 'spectre-meltdown-checker'... remote: Enumerating objects: 1479, done. remote: Counting objects: 100% (42/42), done. remote: Compressing objects: 100% (19/19), done. remote: Total 1479 (delta 24), reused 36 (delta 23), pack-reused 1437 Receiving objects: 100% (1479/1479), 774.42 KiB | 2.44 MiB/s, done. Resolving deltas: 100% (923/923), done.
Измените рабочий каталог.
$ cd spectre-meltdown-checker
Проверьте параметры скрипта:
$ ./spectre-meltdown-checker.sh --help
Spectre and Meltdown mitigation detection tool v0.44-15-ga485c78 Usage: Live mode (auto): spectre-meltdown-checker.sh [options] Live mode (manual): spectre-meltdown-checker.sh [options] <[--kernel ] [--config ] [--map ]> --live Offline mode: spectre-meltdown-checker.sh [options] <[--kernel ] [--config ] [--map ]> Modes: Two modes are available. First mode is the "live" mode (default), it does its best to find information about the currently running kernel. To run under this mode, just start the script without any option (you can also use --live explicitly) Second mode is the "offline" mode, where you can inspect a non-running kernel. This mode is automatically enabled when you specify the location of the kernel file, config and System.map files: --kernel kernel_file specify a (possibly compressed) Linux or BSD kernel file --config kernel_config specify a kernel config file (Linux only) --map kernel_map_file specify a kernel System.map file (Linux only) If you want to use live mode while specifying the location of the kernel, config or map file yourself, you can add --live to the above options, to tell the script to run in live mode instead of the offline mode, which is enabled by default when at least one file is specified on the command line. Options: --no-color don't use color codes --verbose, -v increase verbosity level, possibly several times --explain produce an additional human-readable explanation of actions to take to mitigate a vulnerability --paranoid require IBPB to deem Variant 2 as mitigated also require SMT disabled + unconditional L1D flush to deem Foreshadow-NG VMM as mitigated also require SMT disabled to deem MDS vulnerabilities mitigated --no-sysfs don't use the /sys interface even if present [Linux] --sysfs-only only use the /sys interface, don't run our own checks [Linux] --coreos special mode for CoreOS (use an ephemeral toolbox to inspect kernel) [Linux] --arch-prefix PREFIX specify a prefix for cross-inspecting a kernel of a different arch, for example "aarch64-linux-gnu-", so that invoked tools will be prefixed with this (i.e. aarch64-linux-gnu-objdump) --batch text produce machine readable output, this is the default if --batch is specified alone --batch short produce only one line with the vulnerabilities separated by spaces --batch json produce JSON output formatted for Puppet, Ansible, Chef... --batch nrpe produce machine readable output formatted for NRPE --batch prometheus produce output for consumption by prometheus-node-exporter --variant VARIANT specify which variant you'd like to check, by default all variants are checked VARIANT can be one of 1, 2, 3, 3a, 4, l1tf, msbds, mfbds, mlpds, mdsum, taa, mcepsc, srbds can be specified multiple times (e.g. --variant 2 --variant 3) --cve [cve1,cve2,...] specify which CVE you'd like to check, by default all supported CVEs are checked --hw-only only check for CPU information, don't check for any variant --no-hw skip CPU information and checks, if you're inspecting a kernel not to be run on this host --vmm [auto,yes,no] override the detection of the presence of a hypervisor, default: auto --update-fwdb update our local copy of the CPU microcodes versions database (using the awesome MCExtractor project and the Intel firmwares GitHub repository) --update-builtin-fwdb same as --update-fwdb but update builtin DB inside the script itself --dump-mock-data used to mimick a CPU on an other system, mainly used to help debugging this script Return codes: 0 (not vulnerable), 2 (vulnerable), 3 (unknown), 255 (error) IMPORTANT: A false sense of security is worse than no security at all. Please use the --disclaimer option to understand exactly what this script does.
Просмотрим дисклеймер
$ ./spectre-meltdown-checker.sh --disclaimer
Spectre and Meltdown mitigation detection tool v0.44-15-ga485c78 Disclaimer: This tool does its best to determine whether your system is immune (or has proper mitigations in place) for the collectively named "speculative execution" vulnerabilities. It doesn't attempt to run any kind of exploit, and can't guarantee that your system is secure, but rather helps you verifying whether your system has the known correct mitigations in place. However, some mitigations could also exist in your kernel that this script doesn't know (yet) how to detect, or it might falsely detect mitigations that in the end don't work as expected (for example, on backported or modified kernels). Your system exposure also depends on your CPU. As of now, AMD and ARM processors are marked as immune to some or all of these vulnerabilities (except some specific ARM models). All Intel processors manufactured since circa 1995 are thought to be vulnerable, except some specific/old models, such as some early Atoms. Whatever processor one uses, one might seek more information from the manufacturer of that processor and/or of the device in which it runs. The nature of the discovered vulnerabilities being quite new, the landscape of vulnerable processors can be expected to change over time, which is why this script makes the assumption that all CPUs are vulnerable, except if the manufacturer explicitly stated otherwise in a verifiable public announcement. Please also note that for Spectre vulnerabilities, all software can possibly be exploited, this tool only verifies that the kernel (which is the core of the system) you're using has the proper protections in place. Verifying all the other software is out of the scope of this tool. As a general measure, ensure you always have the most up to date stable versions of all the software you use, especially for those who are exposed to the world, such as network daemons and browsers. This tool has been released in the hope that it'll be useful, but don't use it to jump to conclusions about your security.
Оцените ситуацию.
$ sudo ./spectre-meltdown-checker.sh --explain Spectre and Meltdown mitigation detection tool v0.44-15-ga485c78 Checking for vulnerabilities on current system Kernel is Linux 5.11.0-34-generic #36-Ubuntu SMP Thu Aug 26 19:22:09 UTC 2021 x86_64 CPU is Intel(R) Core(TM) i5-4570S CPU @ 2.90GHz Hardware check * Hardware support (CPU microcode) for mitigation techniques * Indirect Branch Restricted Speculation (IBRS) * SPEC_CTRL MSR is available: YES * CPU indicates IBRS capability: YES (SPEC_CTRL feature bit) * Indirect Branch Prediction Barrier (IBPB) * PRED_CMD MSR is available: YES * CPU indicates IBPB capability: YES (SPEC_CTRL feature bit) * Single Thread Indirect Branch Predictors (STIBP) * SPEC_CTRL MSR is available: YES * CPU indicates STIBP capability: YES (Intel STIBP feature bit) * Speculative Store Bypass Disable (SSBD) * CPU indicates SSBD capability: YES (Intel SSBD) * L1 data cache invalidation * FLUSH_CMD MSR is available: YES * CPU indicates L1D flush capability: YES (L1D flush feature bit) * Microarchitectural Data Sampling * VERW instruction is available: YES (MD_CLEAR feature bit) * Enhanced IBRS (IBRS_ALL) * CPU indicates ARCH_CAPABILITIES MSR availability: NO * ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO * CPU explicitly indicates not being vulnerable to Meltdown/L1TF (RDCL_NO): NO * CPU explicitly indicates not being vulnerable to Variant 4 (SSB_NO): NO * CPU/Hypervisor indicates L1D flushing is not necessary on this system: NO * Hypervisor indicates host CPU might be vulnerable to RSB underflow (RSBA): NO * CPU explicitly indicates not being vulnerable to Microarchitectural Data Sampling (MDS_NO): NO * CPU explicitly indicates not being vulnerable to TSX Asynchronous Abort (TAA_NO): NO * CPU explicitly indicates not being vulnerable to iTLB Multihit (PSCHANGE_MSC_NO): NO * CPU explicitly indicates having MSR for TSX control (TSX_CTRL_MSR): NO * CPU supports Transactional Synchronization Extensions (TSX): NO * CPU supports Software Guard Extensions (SGX): NO * CPU supports Special Register Buffer Data Sampling (SRBDS): YES * CPU microcode is known to cause stability problems: NO (family 0x6 model 0x3c stepping 0x3 ucode 0x28 cpuid 0x306c3) * CPU microcode is the latest known available version: YES (latest version is 0x28 dated 2019/11/12 according to builtin firmwares DB v191+i20210217) * CPU vulnerability to the speculative execution attack variants * Affected by CVE-2017-5753 (Spectre Variant 1, bounds check bypass): YES * Affected by CVE-2017-5715 (Spectre Variant 2, branch target injection): YES * Affected by CVE-2017-5754 (Variant 3, Meltdown, rogue data cache load): YES * Affected by CVE-2018-3640 (Variant 3a, rogue system register read): YES * Affected by CVE-2018-3639 (Variant 4, speculative store bypass): YES * Affected by CVE-2018-3615 (Foreshadow (SGX), L1 terminal fault): NO * Affected by CVE-2018-3620 (Foreshadow-NG (OS), L1 terminal fault): YES * Affected by CVE-2018-3646 (Foreshadow-NG (VMM), L1 terminal fault): YES * Affected by CVE-2018-12126 (Fallout, microarchitectural store buffer data sampling (MSBDS)): YES * Affected by CVE-2018-12130 (ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)): YES * Affected by CVE-2018-12127 (RIDL, microarchitectural load port data sampling (MLPDS)): YES * Affected by CVE-2019-11091 (RIDL, microarchitectural data sampling uncacheable memory (MDSUM)): YES * Affected by CVE-2019-11135 (ZombieLoad V2, TSX Asynchronous Abort (TAA)): NO * Affected by CVE-2018-12207 (No eXcuses, iTLB Multihit, machine check exception on page size changes (MCEPSC)): YES * Affected by CVE-2020-0543 (Special Register Buffer Data Sampling (SRBDS)): YES CVE-2017-5753 aka 'Spectre Variant 1, bounds check bypass' * Mitigated according to the /sys interface: NO (Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers) * Kernel has array_index_mask_nospec: YES (1 occurrence(s) found of x86 64 bits array_index_mask_nospec()) * Kernel has the Red Hat/Ubuntu patch: NO * Kernel has mask_nospec64 (arm64): NO * Kernel has array_index_nospec (arm64): NO > STATUS: VULNERABLE (Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers) CVE-2017-5715 aka 'Spectre Variant 2, branch target injection' * Mitigated according to the /sys interface: NO (Vulnerable, IBPB: disabled, STIBP: disabled) * Mitigation 1 * Kernel is compiled with IBRS support: YES * IBRS enabled and active: UNKNOWN * Kernel is compiled with IBPB support: YES * IBPB enabled and active: YES * Mitigation 2 * Kernel has branch predictor hardening (arm): NO * Kernel compiled with retpoline option: YES > STATUS: VULNERABLE (IBRS+IBPB or retpoline+IBPB is needed to mitigate the vulnerability) > How to fix: To mitigate this vulnerability, you need either IBRS + IBPB, both requiring hardware support from your CPU microcode in addition to kernel support, or a kernel compiled with retpoline and IBPB, with retpoline requiring a retpoline-aware compiler (re-run this script with -v to know if your version of gcc is retpoline-aware) and IBPB requiring hardware support from your CPU microcode. The retpoline + IBPB approach is generally preferred as the performance impact is lower. More information about how to enable the missing bits for those two possible mitigations on your system follow. You only need to take one of the two approaches. > How to fix: Both your CPU and your kernel have IBRS support, but it is currently disabled. You may enable it. Check in your distro's documentation on how to do this. CVE-2017-5754 aka 'Variant 3, Meltdown, rogue data cache load' * Mitigated according to the /sys interface: NO (Vulnerable) * Kernel supports Page Table Isolation (PTI): YES * PTI enabled and active: NO * Reduced performance impact of PTI: YES (CPU supports INVPCID, performance impact of PTI will be greatly reduced) * Running as a Xen PV DomU: NO > STATUS: VULNERABLE (PTI is needed to mitigate the vulnerability) > How to fix: If you're using a distro kernel, upgrade your distro to get the latest kernel available. Otherwise, recompile the kernel with the CONFIG_PAGE_TABLE_ISOLATION option (named CONFIG_KAISER for some kernels), or the CONFIG_UNMAP_KERNEL_AT_EL0 option (for ARM64) CVE-2018-3640 aka 'Variant 3a, rogue system register read' * CPU microcode mitigates the vulnerability: YES > STATUS: NOT VULNERABLE (your CPU microcode mitigates the vulnerability) CVE-2018-3639 aka 'Variant 4, speculative store bypass' * Mitigated according to the /sys interface: NO (Vulnerable) * Kernel supports disabling speculative store bypass (SSB): YES (found in /proc/self/status) * SSB mitigation is enabled and active: NO > STATUS: VULNERABLE (your CPU and kernel both support SSBD but the mitigation is not active) CVE-2018-3615 aka 'Foreshadow (SGX), L1 terminal fault' * CPU microcode mitigates the vulnerability: N/A > STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable) CVE-2018-3620 aka 'Foreshadow-NG (OS), L1 terminal fault' * Mitigated according to the /sys interface: YES (Mitigation: PTE Inversion; VMX: vulnerable, SMT disabled) * Kernel supports PTE inversion: YES (found in kernel image) * PTE inversion enabled and active: YES > STATUS: NOT VULNERABLE (Mitigation: PTE Inversion; VMX: vulnerable, SMT disabled) CVE-2018-3646 aka 'Foreshadow-NG (VMM), L1 terminal fault' * Information from the /sys interface: Mitigation: PTE Inversion; VMX: vulnerable, SMT disabled * This system is a host running a hypervisor: NO * Mitigation 1 (KVM) * EPT is disabled: NO * Mitigation 2 * L1D flush is supported by kernel: YES (found flush_l1d in /proc/cpuinfo) * L1D flush enabled: NO * Hardware-backed L1D flush supported: YES (performance impact of the mitigation will be greatly reduced) * Hyper-Threading (SMT) is enabled: NO > STATUS: NOT VULNERABLE (this system is not running a hypervisor) CVE-2018-12126 aka 'Fallout, microarchitectural store buffer data sampling (MSBDS)' * Mitigated according to the /sys interface: NO (Vulnerable; SMT disabled) * Kernel supports using MD_CLEAR mitigation: YES (md_clear found in /proc/cpuinfo) * Kernel mitigation is enabled and active: NO * SMT is either mitigated or disabled: YES > STATUS: VULNERABLE (Your microcode and kernel are both up to date for this mitigation, but the mitigation is not active) CVE-2018-12130 aka 'ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)' * Mitigated according to the /sys interface: NO (Vulnerable; SMT disabled) * Kernel supports using MD_CLEAR mitigation: YES (md_clear found in /proc/cpuinfo) * Kernel mitigation is enabled and active: NO * SMT is either mitigated or disabled: YES > STATUS: VULNERABLE (Your microcode and kernel are both up to date for this mitigation, but the mitigation is not active) CVE-2018-12127 aka 'RIDL, microarchitectural load port data sampling (MLPDS)' * Mitigated according to the /sys interface: NO (Vulnerable; SMT disabled) * Kernel supports using MD_CLEAR mitigation: YES (md_clear found in /proc/cpuinfo) * Kernel mitigation is enabled and active: NO * SMT is either mitigated or disabled: YES > STATUS: VULNERABLE (Your microcode and kernel are both up to date for this mitigation, but the mitigation is not active) CVE-2019-11091 aka 'RIDL, microarchitectural data sampling uncacheable memory (MDSUM)' * Mitigated according to the /sys interface: NO (Vulnerable; SMT disabled) * Kernel supports using MD_CLEAR mitigation: YES (md_clear found in /proc/cpuinfo) * Kernel mitigation is enabled and active: NO * SMT is either mitigated or disabled: YES > STATUS: VULNERABLE (Your microcode and kernel are both up to date for this mitigation, but the mitigation is not active) CVE-2019-11135 aka 'ZombieLoad V2, TSX Asynchronous Abort (TAA)' * Mitigated according to the /sys interface: YES (Not affected) * TAA mitigation is supported by kernel: YES (found tsx_async_abort in kernel image) * TAA mitigation enabled and active: NO > STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable) CVE-2018-12207 aka 'No eXcuses, iTLB Multihit, machine check exception on page size changes (MCEPSC)' * Mitigated according to the /sys interface: UNKNOWN (KVM: Vulnerable) * This system is a host running a hypervisor: NO * iTLB Multihit mitigation is supported by kernel: YES (found itlb_multihit in kernel image) * iTLB Multihit mitigation enabled and active: NO > STATUS: NOT VULNERABLE (this system is not running a hypervisor) CVE-2020-0543 aka 'Special Register Buffer Data Sampling (SRBDS)' * Mitigated according to the /sys interface: NO (Vulnerable) * SRBDS mitigation control is supported by the kernel: YES (found SRBDS implementation evidence in kernel image. Your kernel is up to date for SRBDS mitigation) * SRBDS mitigation control is enabled and active: NO > STATUS: NOT VULNERABLE (Your microcode and kernel are both up to date for SRBDS mitigation control. Mitigation is enabled) > SUMMARY: CVE-2017-5753:KO CVE-2017-5715:KO CVE-2017-5754:KO CVE-2018-3640:OK CVE-2018-3639:KO CVE-2018-3615:OK CVE-2018-3620:OK CVE-2018-3646:OK CVE-2018-12126:KO CVE-2018-12130:KO CVE-2018-12127:KO CVE-2019-11091:KO CVE-2019-11135:OK CVE-2018-12207:OK CVE-2020-0543:OK A false sense of security is worse than no security at all, see --disclaimer
Просмотр только уязвимостей:
$ sudo ./spectre-meltdown-checker.sh --batch nrpe
Vulnerable: CVE-2017-5753 CVE-2017-5715 CVE-2017-5754 CVE-2018-3639 CVE-2018-12126 CVE-2018-12130 CVE-2018-12127 CVE-2019-11091
Получим машиночитаемый вывод.
$ sudo ./spectre-meltdown-checker.sh --batch text
CVE-2017-5753: VULN (Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers) CVE-2017-5715: VULN (IBRS+IBPB or retpoline+IBPB is needed to mitigate the vulnerability) CVE-2017-5754: VULN (PTI is needed to mitigate the vulnerability) CVE-2018-3640: OK (your CPU microcode mitigates the vulnerability) CVE-2018-3639: VULN (your CPU and kernel both support SSBD but the mitigation is not active) CVE-2018-3615: OK (your CPU vendor reported your CPU model as not vulnerable) CVE-2018-3620: OK (Mitigation: PTE Inversion; VMX: vulnerable, SMT disabled) CVE-2018-3646: OK (this system is not running a hypervisor) CVE-2018-12126: VULN (Your microcode and kernel are both up to date for this mitigation, but the mitigation is not active) CVE-2018-12130: VULN (Your microcode and kernel are both up to date for this mitigation, but the mitigation is not active) CVE-2018-12127: VULN (Your microcode and kernel are both up to date for this mitigation, but the mitigation is not active) CVE-2019-11091: VULN (Your microcode and kernel are both up to date for this mitigation, but the mitigation is not active) CVE-2019-11135: OK (your CPU vendor reported your CPU model as not vulnerable) CVE-2018-12207: OK (this system is not running a hypervisor) CVE-2020-0543: OK (Your microcode and kernel are both up to date for SRBDS mitigation control. Mitigation is enabled)
Получим вывод в JSON:
$ sudo ./spectre-meltdown-checker.sh --batch json | jq .
[
{
"NAME": "SPECTRE VARIANT 1",
"CVE": "CVE-2017-5753",
"VULNERABLE": true,
"INFOS": "Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers"
},
{
"NAME": "SPECTRE VARIANT 2",
"CVE": "CVE-2017-5715",
"VULNERABLE": true,
"INFOS": "IBRS+IBPB or retpoline+IBPB is needed to mitigate the vulnerability"
},
{
"NAME": "MELTDOWN",
"CVE": "CVE-2017-5754",
"VULNERABLE": true,
"INFOS": "PTI is needed to mitigate the vulnerability"
},
{
"NAME": "VARIANT 3A",
"CVE": "CVE-2018-3640",
"VULNERABLE": false,
"INFOS": "your CPU microcode mitigates the vulnerability"
},
{
"NAME": "VARIANT 4",
"CVE": "CVE-2018-3639",
"VULNERABLE": true,
"INFOS": "your CPU and kernel both support SSBD but the mitigation is not active"
},
{
"NAME": "L1TF SGX",
"CVE": "CVE-2018-3615",
"VULNERABLE": false,
"INFOS": "your CPU vendor reported your CPU model as not vulnerable"
},
{
"NAME": "L1TF OS",
"CVE": "CVE-2018-3620",
"VULNERABLE": false,
"INFOS": "Mitigation: PTE Inversion; VMX: vulnerable, SMT disabled"
},
{
"NAME": "L1TF VMM",
"CVE": "CVE-2018-3646",
"VULNERABLE": false,
"INFOS": "this system is not running a hypervisor"
},
{
"NAME": "MSBDS",
"CVE": "CVE-2018-12126",
"VULNERABLE": true,
"INFOS": "Your microcode and kernel are both up to date for this mitigation, but the mitigation is not active"
},
{
"NAME": "MFBDS",
"CVE": "CVE-2018-12130",
"VULNERABLE": true,
"INFOS": "Your microcode and kernel are both up to date for this mitigation, but the mitigation is not active"
},
{
"NAME": "MLPDS",
"CVE": "CVE-2018-12127",
"VULNERABLE": true,
"INFOS": "Your microcode and kernel are both up to date for this mitigation, but the mitigation is not active"
},
{
"NAME": "MDSUM",
"CVE": "CVE-2019-11091",
"VULNERABLE": true,
"INFOS": "Your microcode and kernel are both up to date for this mitigation, but the mitigation is not active"
},
{
"NAME": "TAA",
"CVE": "CVE-2019-11135",
"VULNERABLE": false,
"INFOS": "your CPU vendor reported your CPU model as not vulnerable"
},
{
"NAME": "ITLBMH",
"CVE": "CVE-2018-12207",
"VULNERABLE": false,
"INFOS": "this system is not running a hypervisor"
},
{
"NAME": "SRBDS",
"CVE": "CVE-2020-0543",
"VULNERABLE": false,
"INFOS": "Your microcode and kernel are both up to date for SRBDS mitigation control. Mitigation is enabled"
}
]
Получение вывода для экспортера Prometheus.
$ sudo ./spectre-meltdown-checker.sh --batch prometheus
# TYPE specex_vuln_status untyped
# HELP specex_vuln_status Exposure of system to speculative execution vulnerabilities
specex_vuln_status{name="SPECTRE VARIANT 1",cve="CVE-2017-5753",status="VULN",info="Vulnerable: __user pointer sanitization and usercopy barriers only; no swapgs barriers"} 1
specex_vuln_status{name="SPECTRE VARIANT 2",cve="CVE-2017-5715",status="VULN",info="IBRS+IBPB or retpoline+IBPB is needed to mitigate the vulnerability"} 1
specex_vuln_status{name="MELTDOWN",cve="CVE-2017-5754",status="VULN",info="PTI is needed to mitigate the vulnerability"} 1
specex_vuln_status{name="VARIANT 3A",cve="CVE-2018-3640",status="OK",info="your CPU microcode mitigates the vulnerability"} 1
specex_vuln_status{name="VARIANT 4",cve="CVE-2018-3639",status="VULN",info="your CPU and kernel both support SSBD but the mitigation is not active"} 1
specex_vuln_status{name="L1TF SGX",cve="CVE-2018-3615",status="OK",info="your CPU vendor reported your CPU model as not vulnerable"} 1
specex_vuln_status{name="L1TF OS",cve="CVE-2018-3620",status="OK",info="Mitigation: PTE Inversion; VMX: vulnerable, SMT disabled"} 1
specex_vuln_status{name="L1TF VMM",cve="CVE-2018-3646",status="OK",info="this system is not running a hypervisor"} 1
specex_vuln_status{name="MSBDS",cve="CVE-2018-12126",status="VULN",info="Your microcode and kernel are both up to date for this mitigation, but the mitigation is not active"} 1
specex_vuln_status{name="MFBDS",cve="CVE-2018-12130",status="VULN",info="Your microcode and kernel are both up to date for this mitigation, but the mitigation is not active"} 1
specex_vuln_status{name="MLPDS",cve="CVE-2018-12127",status="VULN",info="Your microcode and kernel are both up to date for this mitigation, but the mitigation is not active"} 1
specex_vuln_status{name="MDSUM",cve="CVE-2019-11091",status="VULN",info="Your microcode and kernel are both up to date for this mitigation, but the mitigation is not active"} 1
specex_vuln_status{name="TAA",cve="CVE-2019-11135",status="OK",info="your CPU vendor reported your CPU model as not vulnerable"} 1
specex_vuln_status{name="ITLBMH",cve="CVE-2018-12207",status="OK",info="this system is not running a hypervisor"} 1
specex_vuln_status{name="SRBDS",cve="CVE-2020-0543",status="OK",info="Your microcode and kernel are both up to date for SRBDS mitigation control. Mitigation is enabled"} 1
Код выхода 2 будет означать, что данная система уязвима.
$ echo $?
2
См. также:
- Kali Linux 2018.2 выпущен с исправлениями для Spectre, Meltdown и более легкого доступа к скрипту Metasploit
- Windows Spectre патчи
- Критические уязвимости в архитектуре процессоров Intel,AMD и ARM
- 👾 Как отключить меры по устранению уязвимостей процессора
- Как вручную включить Retpoline в Windows 10
Этапы разработки сайтов – как быстро создать собственный сайт
Этапы разработки сайтов – как быстро создать собственный сайт
Вы начинающий вебмастер и хотите быстро сделать собственный сайт? Для начала стоит разобраться, какие способы создания сайтов существуют.
Обычный способ: три этапа работы
Первое, что нужно для создания сайта – идея. Далее действуем в три этапа.
Первый этап – дизайн
Вы должны определиться с тем, как будет выглядеть сайт, продумать оформление. Здесь пригодится умение работать с графическим редактором, например, Adobe Photoshop или Corel Draw. Вы разработаете дизайн и подготовите основу для будущей работы. Но если планируется создание простого сайта с минимумом графики, то без этого можно обойтись и приступить сразу ко второму этапу.
Второй этап – верстка
Сверстать сайт означает расположить на нем все необходимые элементы – графика, текст, видео и прочее – в нужном порядке. Для этого создают html-страницу или html-шаблон. Напомним, что для простых сайтов этап с дизайном можно пропустить, для сложных – верстка идёт только после него.
Второй этап очень важен, поскольку html-страницы являются основой сайта. Можно действовать двумя способами:
- самостоятельно написать html-код, воспользовавшись текстовым редактором. Подойдёт Microsoft Word или даже Блокнот. Для этого нужно хорошо знать язык html.
- использовать визуальный редактор, например, Dreamweaver. В этом случае достаточно лишь знать основы html. Это оптимальный способ создавать код страницы.
Третий этап – программирование
Этот этап также можно пропустить, если планируете обойтись без интерактивности. Если же хочется использовать какие-нибудь интересные функции для взаимодействия с пользователями, то без него не обойтись. Но потребуется знание языков веб-программирования.
Как правило, код пишут в текстовом редакторе строчка за строчкой. Самостоятельная работа на этом этапе может быть сложной для тех, кто не знаком с программированием. Чтобы облегчить задачу можно не писать скрипты с нуля, а найти готовые в Сети.
На этом сайт считается готовым, и его можно размещать в интернете. Но для этого требуется придумать ему название и подобрать хостинг – платный или бесплатный. Дальше на сайт нужно привлекать посетителей, ведь если о нем никто не узнает, то и посещаемость будет нулевой. Потому далее наступает этап раскрутки ресурса в Сети. Если хотите, чтобы сайт не просто существовал, а приносил доход, то нужно поработать над его монетизацией.
Учтите, что ваш ресурс должен быть в безопасности от хакеров, которые могут его взломать.
Быстрое создание собственного сайта
Чтобы создать свой сайт необязательно разбираться в программировании, веб-дизайне, верстке и знать язык html. Достаточно использовать в качестве основы готовый шаблон. После небольшого редактирования можно получить относительно ресурс с относительно уникальным дизайном.
Найти подходящий шаблон можно в Сети, подобрав его под тематику своего сайта. Далее останется только добавить свой текст и названия пунктов в меню там, где это нужно. Как только шаблон будет отредактирован – готовый сайт можно загрузить на хостинг. Он готов к работе.
Ещё один вариант быстро создать собственный сайт – скопировать любой понравившийся и изменить его. Изменения обязательны, иначе это будет считаться воровством. Потому действуйте так:
- сохраните страницу понравившегося сайта, выбрав пункт «сохранить как…»;
- отредактируйте страницу, открыв ее в специальной программе, например используйте редактор Dreamweaver.
Самый быстрый способ создания собственного сайта
Есть еще один способ сделать сайт в самые сжатые сроки – использовать конструктор или Систему Управления Контентом (CMS).
CMS – это то, что поможет вам управлять содержимым сайта, который вы разместите на любом выбранном хостинге. С ее помощью можно редактировать и настраивать свой ресурс в онлайн-режиме. Выбирайте CMS в зависимости от того, насколько сложный ресурс вы создаете. Самые простые системы управления контентом позволят добавлять и редактировать страницы сайта. CMS посложнее дают возможность добавлять сложные компоненты, например фотогалерею или целый онлайн-магазин.
Конструктор сайтов – лучшее решение для самых неопытных вебмастеров. Для их использования не нужно иметь никаких специальных знаний. Будущий сайт разместится на платном или бесплатном хостинге. Вам достаточно подобрать шаблоны по количеству страниц сайта и наполнить их простым текстом. В качестве одного из лучших конструкторов можно привести в пример – Wix. Многие независимые рейтинги по конструкторам сайтов считают Wix наиболее совершенным онлайн конструктором. И к тому же он является бесплатным.
Установка CMS – несложный процесс, и, как правило, он занимает примерно минуту. Вы получите сайт, который далее нужно будет заполнить информацией. Это тоже делается просто – если умеете использовать Microsoft Word, то справитесь легко. Выбирайте Joomla или WordPress – это удобные и популярные системы управления контентом.
Использование CMS привлекательно тем, что можно легко создавать странички сайта и наполнять их текстовым и графическим контентом, даже не имея никаких специальных знаний. Умение работать с графическими редакторами тоже не требуется. Результатом использования CMS станет стандартный сайт. По набору функций и дизайну он будет похож на множество других, которые делали таким же способом.
Если хочется уникализировать сайт, то есть решение в виде установки дополнительных модулей и шаблонов. С их помощью и меняется внешний вид ресурса, и добавляются новые функции. Также можно написать собственный модуль, чтобы получить оригинальный дизайн или совершенно новые функции, но это довольно сложная задача.
Один из самых простых способов быстро создать себе сайт – выбрать хостинг с предустановленной CMS. Это значительно упрощает процесс, так как не придется дополнительно скачивать никаких файлов. Все решается нажатием одной кнопки на панели управления хостингом.
Что в итоге выбрать?
У каждого способа создания собственного сайта есть плюсы и минусы.
Выбирая самостоятельное создание с нуля сложного и красивого ресурса, нужно будет применять самые разные знания и навыки работы с полезными программами, в том числе графическими редакторами. Тогда на выходе получится уникальный сайт, полностью отвечающий вашим требованиям.
Реализовать свою идею можно быстрее и проще, если использовать CMS или конструктор. В этом случае потребуются минимальные навыки и знания. Но сделать сложный и уникальный ресурс не получится – функции и настройки останутся стандартными. По дизайну он будет напоминать многие другие сайты.
При выборе способа создания сайта исходите из того, какой ресурс вам требуется. Если предполагается сложный функционал, и скрипты нужно писать с нуля, то это отнимет много времени. Потому оптимально создавать сайт на CMS.




