Почему я получаю много журналов [UFW_BLOCK] для IP-адресов клиентов и коммутаторов?
У меня есть сервер базы данных MariaDB который является узлом моего кластера Galera, и когда я смотрю файл /var/log/ufw.log, я вижу много журналов UFW_BLOCK для IP-адресов клиентов, которые были подключены к базе данных и успешно выполняли операции. Я также подключаюсь к базе данных со своего компьютера и вижу, что мой IP-адрес также регистрируется как UFW_BLOCK, но у меня не было ошибок или каких-либо других прерываний во время моих подключений к базе данных. Я также видел некоторые IP-адреса, которые регистрируются с помощью UFW_BLOCK, которых я не знаю. Когда я поискал и проверил эти IP, я увидел, что это были IP-адреса Коммутаторов LAN. Почему это происходит и что мне делать? Создает ли эта ситуация проблему? Следует ли разрешить использование этих IP-адресов в iptables?
Пример журнала находится здесь:
Mar 3 12:14:47 DB-Srv1 kernel: [6300510.451352] [UFW BLOCK] IN=ens160 OUT= Mac=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=xx.xx.85.222 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x00 TTL=1 ID=19898 PROTO=2
1 ответ
Мы внесли изменения в нашу системную службу:
[Unit]
Description=change dhcpd.leases permissions
After=isc-dhcp-server.service
[Service]
Type=oneshot
WorkingDirectory=/var/lib/dhcp
ExecStartPre=/bin/sleep 30
ExecStart=chown -R whisker:whisker /var/lib/dhcp/
User=root
[Install]
WantedBy=multi-user.target
Это несколько иной подход, чем мы пытались раньше, но это лучший подход. chmod 777 опасен, так как делает файл доступным для чтения, записи и выполнения всеми. Вместо этого эта служба изменяет владельца файла, где whisker - имя пользователя. Приложение работает как виски пользователя, поэтому теперь приложение умеет читать и писать файл dhcpd.leses, который является именно тем, что мы хотим. Владелец всего каталога/var/lib/dhcp должен быть изменен в отличие от файла dhcpd.leses в соответствии с этим . Как мы поняли, файл dhcpd.leses ~, имеющий разрешения по умолчанию, время от времени перезаписывает файл dhcpd.leses, включая установленные разрешения. Это поведение можно устранить, изменив владельца каталога. В результате при перезагрузке системы владелец файла не возвращается.
-121--909177-Для получения более воспроизводимых результатов рекомендуется удалить локально установленные R с помощью
sudo rm /usr/local/bin/R
, а затем установить версию из официальных репозиториев с помощью
sudo apt-add-repository universe
sudo apt-get update
sudo apt-get install r-base-dev
, а затем протестировать установку с помощью R-версии .
Для TCP-соединений Linux, как правило, использует «полудуплексную» последовательность закрытия, где каждая сторона сессии может инициировать завершение соединения посредством однонаправленного двухстороннего квитирования FIN-ACK (что переводит соединение в CLOSE_WAIT состояние), вместо полного четырехстороннего FIN-ACK Когда маршрутизатор находится между ними, это часто приводит к тому, что один конец забывает о соединении раньше другого, что приводит к UFW_BLOCK наблюдаемым сообщениям.
Вы не привели никаких примеров, поэтому этот ответ не является однозначным. Просмотрите флаги TCP в записях журнала, чтобы узнать, связаны ли они с завершением сеанса. Или отредактируйте вопрос, добавив несколько примеров.
EDIT:
Пример записи журнала: многоадресный пакет . Совершенно не связан ни с одним из ваших полезных клиентских пакетов.
Вы также можете наблюдать пакеты, к которым применяется мой первоначальный ответ.