Crt secure no warnings c как подключить

Crt secure no warnings c как подключить

БлогNot. Visual C++: используем _CRT_SECURE_NO_WARNINGS для совместимости с классическими.

Visual C++: используем _CRT_SECURE_NO_WARNINGS для совместимости с классическими функциями

Часто жалуются на «неработающие» коды, особенно консольных приложений или CLR, особенно тех, что работали без каких-либо замечаний в версиях 2010-2013 и вдруг «не работают» в 2015, например, вот этот код.

Выдаются ошибки типа

Ошибка C4996 ‘strcpy’: This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.

Можете, как и рекомендует компилятор, заменить старые названия функций на их безопасные версии, скажем, strcpy на strcpy_s и fopen на fopen_s .

Правда, в последнем случае изменится и «классический» оператор открытия файла, скажем, с

FILE *out = fopen_s("data.txt", "wt");

FILE *out; fopen_s(&out,"data.txt", "wt");

Суть дела в том, что функции, возвращающие указатель, считаются небезопасными, отсюда и изменившийся шаблон метода открытия файла.

Есть путь ещё проще — напишите

#define _CRT_SECURE_NO_WARNINGS

в самом начале до всех #include .

Если используется предкомпиляция, то можно определить этот макрос в заголовочном файле stdafx.h .

Можно также попробовать «дорисовать» его не в заголовках, а в настройках проекта.

Управление предкомпилированными заголовками находится вот где: меню Проект — Свойства C/C++ — Препроцессор (Preprocessor) — Определения препроцессора (Preprocessor Definitions).

Проверено на пустом проекте C++ Visual Studio 2015, 2019, сработало.

Некоторым функциям директива «не поможет», например, stricmp всё равно придётся заменять но _stricmp , правда, без изменения списка аргументов.

Заметим, что по стандартам C++ функции strcpy , strcat и другие не устарели, это собственная политика Microsoft.

13.10.2015, 11:48 [103646 просмотров]

Функции безопасности в CRT

Многие старые функции CRT имеют новые, более безопасные версии. Если существует безопасная функция, более старая, менее безопасная версия помечена как нерекомендуемая. Новая версия имеет _s суффикс (secure).

В этом контексте «не рекомендуется» означает, что использование функции не рекомендуется. Это не означает, что функция будет удалена из CRT.

Безопасные функции не предотвращают или не исправляют ошибки безопасности. Вместо этого они перехватывают ошибки при их возникновении. Они выполняют дополнительные проверка для условий ошибки. Если возникает ошибка, они вызывают обработчик ошибок (см . проверку параметров).

Например, функция не может определить, strcpy слишком ли копируется строка для целевого буфера. Его безопасный аналог strcpy_s принимает размер буфера в качестве параметра. Таким образом, он может определить, произойдет ли переполнение буфера. Если вы используете strcpy_s для копирования 11 символов в буфер символов 10, это ошибка в вашей части; strcpy_s не удается исправить ошибку. Но он может обнаружить ошибку и сообщить вам, вызвав обработчик недопустимых параметров.

Устранение предупреждений о нерекомендуемых функциях

Существует несколько способов устранить предупреждения о нерекомендуемых функциях для старых менее безопасных функций. Проще всего определить _CRT_SECURE_NO_WARNINGS или использовать warning pragma. Либо отключит предупреждения об отключении, но проблемы безопасности, вызвавшие предупреждения, по-прежнему существуют. Рекомендуется оставить предупреждения о нерекомендуемых оповещениях и воспользоваться новыми функциями безопасности CRT.

В C++проще всего исключить предупреждения о нерекомендуемом использовании безопасных перегрузок шаблонов. Перегрузки устраняют нерекомендующие предупреждения во многих случаях. Они заменяют вызовы устаревших функций вызовами для безопасных версий функций. Например, рассмотрим нерекомендуемый вызов функции strcpy :

char szBuf[10]; strcpy(szBuf, "test"); // warning: deprecated 

Задание символа _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES равным 1 устраняет предупреждение, заменяя вызов функции strcpy вызовом функции strcpy_s , которая предотвращает переполнение буфера. Дополнительные сведения см. в разделе «Безопасные перегрузки шаблонов».

Для тех нерекомендуемых функций, у которых нет безопасных шаблонных перегрузок, определенно стоит рассмотреть возможность обновления кода вручную для использования безопасных функций.

Еще один источник предупреждений о нерекомендуемых функциях, не связанный с безопасностью, — POSIX-функции. Замените имена функций POSIX стандартными эквивалентами (например, изменением access _access ) или отключением предупреждений о прекращении использования POSIX путем определения _CRT_NONSTDC_NO_WARNINGS . Дополнительные сведения см. в разделе Совместимость.

Дополнительные функции безопасности

Ниже перечислены некоторые функции безопасности:

• Проверка параметров Безопасные функции и многие из их небезопасных коллег проверяют параметры. Проверка может включать:
  • Проверка значений NULL .
  • Проверка допустимости перечислимых значений.
  • Проверка принадлежности целочисленных значений допустимым диапазонам.

  Дополнительные сведения см. в разделе «Проверка параметров».

  Разработчику также доступен обработчик недопустимого параметра. Если функция сталкивается с недопустимым параметром, а не утверждением и выходом из приложения, CRT позволяет проверка эти проблемы через _set_invalid_parameter_handler или _set_thread_local_invalid_parameter_handler .

  Инфраструктурные системы

  Перейдите в настройки и сначала включите отправку событий в Syslog.

  Для этого выберите:

  Настройки>Аудит>Настройки сбора сообщений.

  Выберите чекбоксы — Включить аудит событий и отправка в Syslog.

  Рисунок 1 — Настройка отправки событий в Syslog.

  Для отправки можно включить все уведомления или только необходимые. Для включения всех уведомлений выделите их с помощью комбинации клавиш Ctrl+A и выберите любой чекбокс, после чего будут добавлены все события (см. рисунок 2).

  

  Рисунок 2 — Добавление всех уведомлений.

  После того как вы включили возможность отправки событий, необходимо указать адрес log-collector’a и порт.

  Для этого выберите:

  Настройки>Аудит>Настройка уведомлений о событиях по протоколу Syslog.

  Выберите чекбокс — Включить отправку уведомлений.

  В поле «Сервер» укажите адрес log-collector’a. В поле «Порт» укажите порт log-collector’a.

  

  Рисунок 3 — Настройка адреса и порта.

  Настройки конфигурации log-collectora

  # = vGate = udp_input_515: &udp_input_515 id: "udp_input_515" host: "172.30.254.166" port: 515 sock_buf_size: 0 format: "json" tcp_output_2745: &tcp_output_2745 id: "tcp_output_2745" target_host: "172.30.254.67" port: 2745 #===== senders: port: 48002 log_level: "INFO" tcp: -  

  ISC Bind DNS

  Настройка логирования bind

  В файл /etc/bind/named.conf добавьте следующие строки:

  logging < channel named < file "/var/log/named/named.log" versions 10 size 20M; severity info; print-time yes; print-category yes; print-severity yes; >; channel security < file "/var/log/named/security.log" versions 10 size 20M; severity info; print-time yes; print-severity yes; >; channel dnssec < file "/var/log/named/dnssec.log" versions 10 size 20M; severity info; print-time yes; print-severity yes; >; channel resolver < file "/var/log/named/resolver.log" versions 10 size 20M; severity info; print-time yes; print-severity yes; >; channel query_log < file "/var/log/named/query.log" versions 10 size 80M; severity info; print-time yes; print-severity yes; >; channel query_error < file "/var/log/named/query_errors.log" versions 10 size 20M; severity info; print-time yes; print-severity yes; >; channel lame_servers < file "/var/log/named/lame-servers.log" versions 10 size 20M; severity info; print-time yes; print-severity yes; >; channel capacity < file "/var/log/named/capacity.log" versions 10 size 20M; severity info; print-time yes; print-severity yes; >; channel database < file "/var/log/named/database.log" versions 10 size 20M; severity info; print-time yes; print-severity yes; >; channel update < file "/var/log/named/update.log" versions 10 size 10M; severity info; print-time yes; print-severity yes; >; category default < default_syslog; named; >; category general < default_syslog; named; >; category security < security; >; category queries < query_log; >; category query-errors < query_error; >; category lame-servers < lame_servers; >; category dnssec < dnssec; >; category edns-disabled < default_syslog; resolver; >; category config < default_syslog; named; >; category resolver < resolver; >; category cname < resolver; >; category spill < capacity; >; category rate-limit < capacity; >; category database < database; >; category client < default_syslog; named; >; category network < default_syslog; named; >; category unmatched < named; >; category delegation-only < named; >; category update < default_syslog; update; >; category update-security < default_syslog; update; >; >; 

  Далее необходимо сохранить, выйти и проверить конфигурацию.

  sudo named-checkconf /etc/bind/named.conf.options 

  Далее создать директорию где будут хранится журналы и нужные файлы под них, задать необходимые разрешения и владельцев, перезапустить сервис Bind9.

  mkdir -p /var/log/named touch /var/log/named/named.log touch /var/log/named/security.log touch /var/log/named/dnssec.log touch /var/log/named/resolver.log touch /var/log/named/query.log touch /var/log/named/query_errors.log touch /var/log/named/lame-servers.log touch /var/log/named/capacity.log touch /var/log/named/database.log touch /var/log/named/update.log chown bind:bind /var/log/named chown bind:bind /var/log/named/*.log chmod 640 /var/log/named/*.log service bind9 restart 

  Это позволит начать отслеживание логов bind.

  Настройка rsyslog на сервере bind

  Создайте шаблон для rsyslog'a по пути /etc/rsyslog.d/ . Например bind.conf

  sudo nano /etc/rsyslog.d/bind.conf 

  Содержимое файла представлено ниже:

  module(load="imfile" PollingInterval="10") input(type="imfile" reopenOnTruncate="on" File="/var/log/named/capacity.log" Tag="tag_dns_log") input(type="imfile" reopenOnTruncate="on" File="/var/log/named/dnssec.log" Tag="tag_dns_log") input(type="imfile" reopenOnTruncate="on" File="/var/log/named/named.log" Tag="tag_dns_log") input(type="imfile" reopenOnTruncate="on" File="/var/log/named/query.log" Tag="tag_dns_log") input(type="imfile" reopenOnTruncate="on" File="/var/log/named/security.log" Tag="tag_dns_log") input(type="imfile" reopenOnTruncate="on" File="/var/log/named/database.log" Tag="tag_dns_log") input(type="imfile" reopenOnTruncate="on" File="/var/log/named/lame-servers.log" Tag="tag_dns_log") input(type="imfile" reopenOnTruncate="on" File="/var/log/named/query_errors.log" Tag="tag_dns_log") input(type="imfile" reopenOnTruncate="on" File="/var/log/named/resolver.log" Tag="tag_dns_log") input(type="imfile" reopenOnTruncate="on" File="/var/log/named/update.log" Tag="tag_dns_log") if $syslogtag == 'tag_dns_log' then @x.x.x.x:2800 & stop 

  Где вместо x.x.x.x укажите ip-адрес лог-коллектора и порт после двоеточия.

  Перезапустите службу rsyslog.

  systemctl restart rsyslog 

  Настройки конфигурации log-collectora

  udp_input_2800: &udp_input_2800 id: "udp_input_2800" host: "192.168.1.100" port: 2800 sock_buf_size: 0 format: "json" tcp_output_2800: &tcp_output_2800 id: "tcp_output_2800" target_host: "192.168.1.200" port: 2800 senders: port: 48002 log_level: "INFO" tcp: -  

  Вместо x.x.x.x укажите ip-адрес лог-коллектора и выбранный ранее порт для tcp_input.

  Dell IDRAC

  Включение аудита IDRAC

  1. Войдите в Chasis Management Controller UI . Выберите Server Overview > Properties > Status. Рисунок 4 -- Выбор настроек.
  2. Нажмите на кнопку IDRAC для серверов, на которых вы хотите включить логирование. Рисунок 5 -- Выбор серверов.
  3. Выберите Server > Logs > Settings. На странице Settings отметьте галочкой Enable the Remote Syslog Settings , затем введите IP лог-коллектора в поле Syslog Server и выбранный номер порта для подключения в поле Port Number. Рисунок 6 -- Настройка параметров логгирования.
  4. Выберите Server > Alerts > Включите Alerts и Alert Filter в зависимости от ваших требований. Рисунок 7 -- Выбор алертов.
  5. Чуть ниже во вкладке Alerts and Remote System Log Configuration > отметьте галочками Remote System Log для создания необходимых алертов. Рисунок 8 -- Создание алертов. Повторите создание алертов на всех страницах.

  Добавление новой конфигурации в коллектор

  Приведенные настройки с описанием для добавления в config.yaml ниже:

  tcp_input_3: &tcp_input_3 id: "tcp_input_3" host: "" port: 999 sock_buf_size: 0 format: "json" encoding: change_to_utf8: true original_encoding: "cp1251" 

  В качестве порта для подключения необходимо указать порт, выбранный на шаге 3.

  Linux KVM

  Установка KVM

  #Проверка поддержки виртуализации и разрядности egrep -c '(vmx|svm)' /proc/cpuinfo egrep -c 'lm' /proc/cpuinfo # Установка пакетов apt install virtinst apt install qemu-kvm bridge-utils virt-manager virt-viewer # Добавить пользователя в группы adduser libvirt adduser kvm 

  Проверка работы KVM

  # Проверка наличия qemu в системе с помощью утилиты virsh virsh -c qemu:///system list Id Name State -------------------- # Проверка прав доступа к файлам ls -la /var/run/libvirt/libvirt-sock srw-rw-rw- 1 root root 0 Aug 23 13:52 /var/run/libvirt/libvirt-sock ls -lh /usr/bin/kvm lrwxrwxrwx 1 root root 18 Jul 11 23:07 /usr/bin/kvm -> qemu-system-x86_64 #Если запущена хотя бы одна виртуальная машина virsh -c qemu:///system list Id Name State ----------------------------- 7 ubuntu22.04 running 

  Настройка rsyslog

  Лог KVM располагается в директории:

  /home/$USER/.cache/virt-manager/virt-manager.log 

  Настройка доступа к данному файлу.

  chmod 644 /home/$USER/.cache/virt-manager/virt-manager.log 

  Далее необходимо подготовить конфигурационный файл для rsyslog . Файл будет располагаться в директории /etc/rsyslog.d/ . Желательно именовать файл в соответствии с системным шаблоном: [00]- .conf, где [00] - приоритетный номер конфигурации в директории rsyslog.d , а - имя источника. Чем меньше номер конфигурации, тем выше приоритет его обработки системой.

  sudo vi /etc/rsyslog.d/30-kvm.conf # Input modules module(load="imfile" mode="inotify" PollingInterval="10") # KVM log input(type="imfile" File="/home/$USER/.cache/virt-manager/virt-manager.log" Tag="kvm" Severity="info" Facility="local3") local3.* @@172.30.250.70:3000 

  • imfile - модуль, обрабатывающий лог;
  • File - непосредственно сам лог (полный путь к файлу);
  • Tag - тег, который будет использоваться для записей, полученных из указанного выше лог-файла;
  • Severity - уровень критичности события (info, debug, warning, error);
  • Facility - категория источника;
  • local3.* @@172.30.250.70:3000 - переслать лог на лог-коллектор по порту 3000 с использованием протокола TCP (@@ - TCP, @ - UDP).

  Проверка конфигурации rsyslog :

  rsyslogd -N1 rsyslogd: version 8.2310.0-1.fc38, config validation run (level 1), master config /etc/rsyslog.conf rsyslogd: End of config validation run. Bye. # Проверить конкретный файл конфигурации rsyslogd -f /etc/rsyslog.d/30-kvm.conf -N1 rsyslogd: version 8.2310.0-1.fc38, config validation run (level 1), master config /etc/rsyslog.d/30-kvm.conf.conf rsyslogd: End of config validation run. Bye. 

  Перезапуск службы rsyslog

  systemctl restart rsyslog 

  Настройка лог-коллектора

  ## IP-адрес лог-коллектора: 172.30.250.70, IP-адрес Платформы: 172.30.254.84 ## Лог-коллектор принимает события через порт 3000, Платформа - 2746 --- cluster: url: "https://172.30.254.84:9000/cm/api/agent/" api_key: "57dbc2b0-41e8-0f55-95d8-1c19c2e44347" controller: port: 48000 metric_server: port: 48005 log_level: "ERROR" api_server: address: "172.30.250.70" port: 8085 read_timeout: 60 write_timeout: 60 wait: 5 enable_tls: false cert_file: "/opt/pangeoradar/certs/server.crt" key_file: "/opt/pangeoradar/certs/server.key" cert_key_pass: "" require_client_cert: false ca_file: "/opt/pangeoradar/certs/pgr.crt" log_level: "WARN" journal: port: 48004 log_level: "INFO" log_path: "/var/log/logcollector/journal.log" rotation_size: 30 max_backups: 7 max_age: 7 tcp_input: &tcp_input id: "tcp_input" host: "172.30.250.70" port: 3000 buf_size: 0 format: "json" tcp_sender: &tcp_sender id: "tcp_sender" target_host: "172.30.254.84" port: 2746 log_level: "WARN" senders: port: 48002 out_file: -  

  Пример лога KVM

  [Thu, 19 Oct 2023 10:55:32 virt-manager 27744] DEBUG (storage:207) refreshing pool=VMachines [Thu, 19 Oct 2023 10:55:32 virt-manager 27744] DEBUG (connection:691) storage pool refresh event: pool=VMachines [Thu, 19 Oct 2023 10:55:58 virt-manager 27744] DEBUG (createvol:313) Starting background vol creation. [Thu, 19 Oct 2023 10:55:58 virt-manager 27744] DEBUG (storage:659) Creating storage volume 'host-suse-test.qcow2' [Thu, 19 Oct 2023 10:55:58 virt-manager 27744] DEBUG (storage:697) Using vol create flags=1 [Thu, 19 Oct 2023 10:56:01 virt-manager 27744] DEBUG (storage:701) Storage volume 'host-suse-test.qcow2' install complete. [Thu, 19 Oct 2023 10:56:01 virt-manager 27744] DEBUG (createvol:315) vol creation complete. [Thu, 19 Oct 2023 10:56:01 virt-manager 27744] DEBUG (createvol:69) Closing new volume wizard [Thu, 19 Oct 2023 10:56:01 virt-manager 27744] DEBUG (connection:691) storage pool refresh event: pool=VMachines 

  Linux NFS Server

  Данное руководство описывает механизм сбора событий Linux NFS server и отправки их в Платформу Радар.

  Настройка журналирования NFS

  Все настройки, перечисленные ниже, должны осуществляться с правами администратора (root). Если вы работаете под непривилегированным пользователем, используйте команду sudo. Пример конфигурации приведен для сервера под управлением ОС Debian. Если вы используете другой дистрибутив Linux, то расположение файлов и настройки могут немного отличаться, в таком случае обратитесь к документации к своему дистрибутиву.

  1. Откройте файл /etc/default/nfs-kernel-server # nano /etc/default/nfs-kernel-server и добавьте следующую строку: RPCNFSDOPTS="--syslog" Если параметр RPCNFSDOPTS уже присутствует, то просто нужно добавить ключ --syslog
  2. Откройте файл /etc/idmapd.conf # nano /etc/idmapd.conf и для переменной Verbosity введите значение 4: Verbosity = 4
  3. Выполните следующую команду: # rpcdebug -m nfsd -s all
  4. Перезапустите службу nfs-kernel-server # systemctl restart nfs-kernel-server.service
  5. Откройте файл /etc/rsyslog.conf # nano /etc/rsyslog.conf и добавьте в конец файла следующую строку: :msg,contains,"nfsd" @@172.30.250.32:4570
  6. Перезапустите службу rsyslog # systemctl restart rsyslog.service

  Конфигурация лог коллектора

  Пример конфигурационного файла лог коллектора:

  license_path: "C:/Program Files/Log Collector//pgr-agent.lic" cluster: url: "https://адрес_Радар_Мастер" api_key: "api_key" controller: port: 48000 metric_server: port: 48005 secret_file: "C:/Program Files/Log Collector/secret" secret_storage: "C:/Program Files/Log Collector/secret_storage" api_server: address: "ip-адрес лог коллектора" port: 8080 read_timeout: 60 write_timeout: 60 wait: 5 enable_tls: false cert_file: "C:/Program Files/Log Collector/certs/agent.crt" key_file: "C:/Program Files/Log Collector/certs/agent.key" cert_key_pass: "" require_client_cert: false ca_file: "C:/Program Files/Log Collector/certs/pgr.crt" log_level: "WARN" journal: port: 48004 log_level: "INFO" log_path: "C:/Program Files/Log Collector/journal.log" rotation_size: 30 max_backups: 7 max_age: 7 tcp_input_linux_nfs: &tcp_input_linux_nfs id: "tcp_input_linux_nfs" host: "ip-адрес лог коллектора" port: 4570 enable_tls: false compression_enabled: false connections_limit: 10 format: "json" log_level: "INFO" tcp_output_linux_nfs: &tcp_output_linux_nfs id: "tcp_output_linux_nfs" target_host: "ip-адрес балансера" port: 4570 senders: port: 48002 tcp: -  

  Microsoft DNS

  Для получения событий запросов и ответов DNS сервера необходимо включить журнал отладки, по умолчанию он выключен. Для этого откройте оснастку DNS сервера, далее перейдите в его свойства. В свойствах DNS сервера выберите "Ведение журнала отладки".

  

  Рисунок 9 -- Ведение журнала отладки.

  Отметьте чекбоксы (см. рисунок 9) и нажмите кнопку "ОК".

  В поле "Имя и путь к файлу" укажите Ваш файл, куда DNS сервер будет создавать события.

  Нажмите кнопку "Применить".

  Настройки Logcollectora

  Сценарий, когда лог-коллектор развёрнут на том же хосте где и сам DNS сервер.

  cluster: url: "https://192.168.1.200:9000/cm/api/agent/" api_key: "bac1e342-f819-1a9f-5a16-c925b8b407b7" controller: port: 48000 metric_server: port: 48005 secret_file: "C:\\Program Files\\Log Collector\\secret" secret_storage: "C:\\Program Files\\Log Collector\\secret.storage" api_server: address: "192.168.1.100" port: 8080 read_timeout: 60 write_timeout: 60 wait: 5 enable_tls: false cert_file: "certs/server.crt" key_file: "certs/server.key" cert_key_pass: "" require_client_cert: true ca_file: "certs/pgr.crt" log_level: "INFO" journal: port: 48004 log_level: "INFO" log_path: "C:/Program Files/Log Collector/journal.log" rotation_size: 30 max_backups: 7 max_age: 7 win_dns: &win_dns id: "win_dns" poll_interval: 1 files: ["C:\\\\DNS_logs\\dns_logs.txt"] using_regexp: false regexp_starting_dir: "c://DNS_logs/" regexp_expression: ".txt" dir_check_interval: 2 read_from_last: true enable_watcher: true log_level: "INFO" format: "json" encoding: change_to_utf8: false original_encoding: "cp1251" filters: blacklist: ["^M.*", "^D.*", "^L.*", "^\\s+.*"] win_dns_out: &win_dns_out id: "win_dns_out" target_host: "192.168.1.200" port: 1516 senders: port: 48002 tcp: -  

  Сценарий, когда лог-коллектор забирает события с DNS сервера по SMB.

  cluster: url: "https://192.168.1.200:9000/cm/api/agent/" api_key: "57dbc2b0-41e8-0f55-95d8-1c19c2e44347" controller: port: 48000 metric_server: port: 48005 secret_file: "C:\\Program Files\\Log Collector\\secret" secret_storage: "C:\\Program Files\\Log Collector\\secret.storage" api_server: address: "192.168.1.100" port: 8080 read_timeout: 60 write_timeout: 60 wait: 5 enable_tls: false cert_file: "certs/server.crt" key_file: "certs/server.key" cert_key_pass: "" require_client_cert: true ca_file: "certs/pgr.crt" log_level: "INFO" journal: port: 48004 log_level: "INFO" log_path: "C:\\Program Files\\Log Collector\\journal.log" rotation_size: 30 max_backups: 7 max_age: 7 smb_collector_out: &smb_collector_out id: "smb_collector_out" target_host: "192.168.1.200" port: 1516 smb_collector: &smb_collector id: "smb_collector" remote_servers: ["192.168.1.2"] port: 445 share: "\\\\192.168.88.1.2\\DNS_logs" domain: "." user: "logcoll" password: "1" poll_interval: 5 files: ["dns_logs.txt"] using_regexp: false regexp_starting_dir: "." regexp_expression: ".(?:txt|log)$" dir_check_interval: 5 read_from_last: true format: "json" log_level: "INFO" filters: blacklist: ["^M.*", "^D.*", "^L.*", "^\\s+.*"] senders: port: 48002 log_level: "INFO" tcp: -  

  FreeRADIUS

  Для отправки событий с сервера FreeRADIUS используется rsyslog. События записываются и забираются из файла radius.log .

  Для источника FreeRADIUS используется порт 2935.

  В разделе "Журнал" файла radiusd.conf находится основная конфигурация ведения журнала для сервера FreeRADIUS.

  nano /etc/freeradius/3.0/radiusd.conf 

  Необходимо найти блок log:

  log < destination = files #Куда попадают логи file = $/radius.log #Назначение файла лога syslog_facility = daemon #Название журнала stripped_names = no auth = no # Статус аутентификации auth_badpass = no # Тот же статус но с некорректными данными auth_goodpass = no # Тот же статус но с корректными данными # msg_goodpass = "" # msg_badpass = "" > 

  И далее настроить его следующим образом:

  В конфигурационном файле найдите пункт logdir = /var/log/freeradius/radius.log и замените его на logdir = syslog

  Далее необходимо настроить rslyslog.conf , разрешить отправку по tcp порту, создать в rslyslog.d свою конфигурацию с содержимым

  local2.* @@адрес лог коллектора:2935 

  tcp_input_2935: &tcp_input_2935 id: "tcp_input_2935" host: "xx.xx.xx.xx" #адрес лог-коллектора port: 2935 sock_buf_size: 0 format: "json" tcp_output_2935: &tcp_output_2935 id: "tcp_output_2935" target_host: "xx.xx.xx.xx" #адрес платформы port: 2935 senders: port: 48002 tcp: -  

  

  To configure an HTTPS server, the ssl parameter must be enabled on listening sockets in the server block, and the locations of the server certificate and private key files should be specified:

  server < listen 443 ssl; server_name www.example.com; ssl_certificate www.example.com.crt; ssl_certificate_key www.example.com.key; ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; . >

  The server certificate is a public entity. It is sent to every client that connects to the server. The private key is a secure entity and should be stored in a file with restricted access, however, it must be readable by nginx’s master process. The private key may alternately be stored in the same file as the certificate:

  ssl_certificate www.example.com.cert; ssl_certificate_key www.example.com.cert;

  in which case the file access rights should also be restricted. Although the certificate and the key are stored in one file, only the certificate is sent to a client.

  The directives ssl_protocols and ssl_ciphers can be used to limit connections to include only the strong versions and ciphers of SSL/TLS. By default nginx uses “ ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3 ” and “ ssl_ciphers HIGH:!aNULL:!MD5 ”, so configuring them explicitly is generally not needed. Note that default values of these directives were changed several times.

  HTTPS server optimization

  SSL operations consume extra CPU resources. On multi-processor systems several worker processes should be run, no less than the number of available CPU cores. The most CPU-intensive operation is the SSL handshake. There are two ways to minimize the number of these operations per client: the first is by enabling keepalive connections to send several requests via one connection and the second is to reuse SSL session parameters to avoid SSL handshakes for parallel and subsequent connections. The sessions are stored in an SSL session cache shared between workers and configured by the ssl_session_cache directive. One megabyte of the cache contains about 4000 sessions. The default cache timeout is 5 minutes. It can be increased by using the ssl_session_timeout directive. Here is a sample configuration optimized for a multi-core system with 10 megabyte shared session cache:

  worker_processes auto; http < ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; server < listen 443 ssl; server_name www.example.com; keepalive_timeout 70; ssl_certificate www.example.com.crt; ssl_certificate_key www.example.com.key; ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; .

  SSL certificate chains

  Some browsers may complain about a certificate signed by a well-known certificate authority, while other browsers may accept the certificate without issues. This occurs because the issuing authority has signed the server certificate using an intermediate certificate that is not present in the certificate base of well-known trusted certificate authorities which is distributed with a particular browser. In this case the authority provides a bundle of chained certificates which should be concatenated to the signed server certificate. The server certificate must appear before the chained certificates in the combined file:

  $ cat www.example.com.crt bundle.crt > www.example.com.chained.crt

  The resulting file should be used in the ssl_certificate directive:

  server

  If the server certificate and the bundle have been concatenated in the wrong order, nginx will fail to start and will display the error message:

  SSL_CTX_use_PrivateKey_file(" . /www.example.com.key") failed (SSL: error:0B080074:x509 certificate routines: X509_check_private_key:key values mismatch)

  because nginx has tried to use the private key with the bundle’s first certificate instead of the server certificate.

  Browsers usually store intermediate certificates which they receive and which are signed by trusted authorities, so actively used browsers may already have the required intermediate certificates and may not complain about a certificate sent without a chained bundle. To ensure the server sends the complete certificate chain, the openssl command-line utility may be used, for example:

  $ openssl s_client -connect www.godaddy.com:443 . Certificate chain 0 s:/C=US/ST=Arizona/L=Scottsdale/1.3.6.1.4.1.311.60.2.1.3=US /1.3.6.1.4.1.311.60.2.1.2=AZ/O=GoDaddy.com, Inc /OU=MIS Department/CN=www.GoDaddy.com /serialNumber=0796928-7/2.5.4.15=V1.0, Clause 5.(b) i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc. /OU=http://certificates.godaddy.com/repository /CN=Go Daddy Secure Certification Authority /serialNumber=07969287 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc. /OU=http://certificates.godaddy.com/repository /CN=Go Daddy Secure Certification Authority /serialNumber=07969287 i:/C=US/O=The Go Daddy Group, Inc. /OU=Go Daddy Class 2 Certification Authority 2 s:/C=US/O=The Go Daddy Group, Inc. /OU=Go Daddy Class 2 Certification Authority i:/L=ValiCert Validation Network/O=ValiCert, Inc. /OU=ValiCert Class 2 Policy Validation Authority /CN=http://www.valicert.com//emailAddress=info@valicert.com .

  When testing configurations with SNI, it is important to specify the -servername option as openssl does not use SNI by default.

  In this example the subject (“s”) of the www.GoDaddy.com server certificate #0 is signed by an issuer (“i”) which itself is the subject of the certificate #1, which is signed by an issuer which itself is the subject of the certificate #2, which signed by the well-known issuer ValiCert, Inc. whose certificate is stored in the browsers’ built-in certificate base (that lay in the house that Jack built).

  If a certificate bundle has not been added, only the server certificate #0 will be shown.

  A single HTTP/HTTPS server

  It is possible to configure a single server that handles both HTTP and HTTPS requests:

  server

  Prior to 0.7.14 SSL could not be enabled selectively for individual listening sockets, as shown above. SSL could only be enabled for the entire server using the ssl directive, making it impossible to set up a single HTTP/HTTPS server. The ssl parameter of the listen directive was added to solve this issue. The use of the ssl directive in modern versions is thus discouraged.

  Name-based HTTPS servers

  A common issue arises when configuring two or more HTTPS servers listening on a single IP address:

  server < listen 443 ssl; server_name www.example.com; ssl_certificate www.example.com.crt; . >server

  With this configuration a browser receives the default server’s certificate, i.e. www.example.com regardless of the requested server name. This is caused by SSL protocol behaviour. The SSL connection is established before the browser sends an HTTP request and nginx does not know the name of the requested server. Therefore, it may only offer the default server’s certificate.

  The oldest and most robust method to resolve the issue is to assign a separate IP address for every HTTPS server:

  server < listen 192.168.1.1:443 ssl; server_name www.example.com; ssl_certificate www.example.com.crt; . >server

  An SSL certificate with several names

  There are other ways that allow sharing a single IP address between several HTTPS servers. However, all of them have their drawbacks. One way is to use a certificate with several names in the SubjectAltName certificate field, for example, www.example.com and www.example.org . However, the SubjectAltName field length is limited.

  Another way is to use a certificate with a wildcard name, for example, *.example.org . A wildcard certificate secures all subdomains of the specified domain, but only on one level. This certificate matches www.example.org , but does not match example.org and www.sub.example.org . These two methods can also be combined. A certificate may contain exact and wildcard names in the SubjectAltName field, for example, example.org and *.example.org .

  It is better to place a certificate file with several names and its private key file at the http level of configuration to inherit their single memory copy in all servers:

  ssl_certificate common.crt; ssl_certificate_key common.key; server < listen 443 ssl; server_name www.example.com; . >server

  Server Name Indication

  A more generic solution for running several HTTPS servers on a single IP address is TLS Server Name Indication extension (SNI, RFC 6066), which allows a browser to pass a requested server name during the SSL handshake and, therefore, the server will know which certificate it should use for the connection. SNI is currently supported by most modern browsers, though may not be used by some old or special clients.

  Only domain names can be passed in SNI, however some browsers may erroneously pass an IP address of the server as its name if a request includes literal IP address. One should not rely on this.

  In order to use SNI in nginx, it must be supported in both the OpenSSL library with which the nginx binary has been built as well as the library to which it is being dynamically linked at run time. OpenSSL supports SNI since 0.9.8f version if it was built with config option Since OpenSSL 0.9.8j this option is enabled by default. If nginx was built with SNI support, then nginx will show this when run with the “-V” switch:

  $ nginx -V . TLS SNI support enabled .

  However, if the SNI-enabled nginx is linked dynamically to an OpenSSL library without SNI support, nginx displays the warning:

  nginx was built with SNI support, however, now it is linked dynamically to an OpenSSL library which has no tlsext support, therefore SNI is not available

  Compatibility

  • The SNI support status has been shown by the “-V” switch since 0.8.21 and 0.7.62.
  • The ssl parameter of the listen directive has been supported since 0.7.14. Prior to 0.8.21 it could only be specified along with the default parameter.
  • SNI has been supported since 0.5.23.
  • The shared SSL session cache has been supported since 0.5.6.
  • Version 1.23.4 and later: the default SSL protocols are TLSv1, TLSv1.1, TLSv1.2, and TLSv1.3 (if supported by the OpenSSL library).
  • Version 1.9.1 and later: the default SSL protocols are TLSv1, TLSv1.1, and TLSv1.2 (if supported by the OpenSSL library).
  • Version 0.7.65, 0.8.19 and later: the default SSL protocols are SSLv3, TLSv1, TLSv1.1, and TLSv1.2 (if supported by the OpenSSL library).
  • Version 0.7.64, 0.8.18 and earlier: the default SSL protocols are SSLv2, SSLv3, and TLSv1.
  • Version 1.0.5 and later: the default SSL ciphers are “ HIGH:!aNULL:!MD5 ”.
  • Version 0.7.65, 0.8.20 and later: the default SSL ciphers are “ HIGH:!ADH:!MD5 ”.
  • Version 0.8.19: the default SSL ciphers are “ ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM ”.
  • Version 0.7.64, 0.8.18 and earlier: the default SSL ciphers are
    “ ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP ”.

  written by Igor Sysoev edited by Brian Mercer

  Читать:

  Как убрать число с фотографии