Вопрос или проблема
У меня есть сервер Almalinux от Hetzner с 12-ядерным процессором и 128 ГБ оперативной памяти, на который я установил PostgreSQL, и все прошло нормально. Но в последнее время PostgreSQL потребляет много процессорного времени и памяти, и IP-адрес сервера был заблокирован дата-центром. Когда я использую strace для его PID, он пытается подключиться к IP-адресам из Франции, Африки и других мест, но не может. Эти неудачные подключения нагружают процессор. Ниже скриншот htop и логи strace. Может кто-нибудь объяснить мне, является ли такое поведение нормальным и здоровым, и как это можно контролировать?
~# strace -p 1931753
socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 12
setsockopt(12, SOL_TCP, TCP_NODELAY, [1], 4) = 0
setsockopt(12, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
setsockopt(12, SOL_TCP, TCP_KEEPIDLE, [60], 4) = 0
setsockopt(12, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
setsockopt(12, SOL_TCP, TCP_KEEPCNT, [10], 4) = 0
connect(12, {sa_family=AF_INET, sin_port=htons(9090), sin_addr=inet_addr("151.80.33.214")}, 16) = -1 EINPROGRESS (Operation now in progress)
epoll_ctl(0, EPOLL_CTL_ADD, 12, {events=EPOLLOUT, data={u32=12, u64=12}}) = 0
epoll_pwait(0, [{events=EPOLLERR, data={u32=12, u64=12}}], 1024, 37, NULL, 8) = 1
getsockopt(12, SOL_SOCKET, SO_ERROR, [ECONNREFUSED], [4]) = 0
setsockopt(12, SOL_SOCKET, SO_KEEPALIVE, [0], 4) = 0
epoll_ctl(0, EPOLL_CTL_DEL, 12, 0x7fff7bf6dbd4) = 0
close(12) = 0
epoll_pwait(0, [], 1024, 35, NULL, 8) = 0
epoll_pwait(0, [], 1024, 500, NULL, 8) = 0
epoll_pwait(0, [], 1024, 460, NULL, 8) = 0
epoll_pwait(0, [], 1024, 38, NULL, 8) = 0
epoll_pwait(0, [], 1024, 500, NULL, 8) = 0
epoll_pwait(0, [], 1024, 460, NULL, 8) = 0
epoll_pwait(0, [], 1024, 37, NULL, 8) = 0
epoll_pwait(0, [], 1024, 500, NULL, 8) = 0
epoll_pwait(0, [], 1024, 460, NULL, 8) = 0
epoll_pwait(0, [], 1024, 38, NULL, 8) = 0
epoll_pwait(0, [], 1024, 500, NULL, 8) = 0
epoll_pwait(0, [], 1024, 459, NULL, 8) = 0
epoll_pwait(0, [], 1024, 38, NULL, 8) = 0
epoll_pwait(0, [], 1024, 500, NULL, 8) = 0
epoll_pwait(0, [], 1024, 460, NULL, 8) = 0
socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 12
setsockopt(12, SOL_TCP, TCP_NODELAY, [1], 4) = 0
setsockopt(12, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
setsockopt(12, SOL_TCP, TCP_KEEPIDLE, [60], 4) = 0
setsockopt(12, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
setsockopt(12, SOL_TCP, TCP_KEEPCNT, [10], 4) = 0
connect(12, {sa_family=AF_INET, sin_port=htons(9090), sin_addr=inet_addr("151.80.33.214")}, 16) = -1 EINPROGRESS (Operation now in progress)
epoll_ctl(0, EPOLL_CTL_ADD, 12, {events=EPOLLOUT, data={u32=12, u64=12}}) = 0
epoll_pwait(0, [{events=EPOLLERR, data={u32=12, u64=12}}], 1024, 37, NULL, 8) = 1
getsockopt(12, SOL_SOCKET, SO_ERROR, [ECONNREFUSED], [4]) = 0
setsockopt(12, SOL_SOCKET, SO_KEEPALIVE, [0], 4) = 0
epoll_ctl(0, EPOLL_CTL_DEL, 12, 0x7fff7bf6dbd4) = 0
close(12) = 0
epoll_pwait(0, [], 1024, 35, NULL, 8) = 0
epoll_pwait(0, [], 1024, 500, NULL, 8) = 0
epoll_pwait(0, [], 1024, 460, NULL, 8) = 0
epoll_pwait(0, [], 1024, 38, NULL, 8) = 0
epoll_pwait(0, [], 1024, 500, NULL, 8) = 0
epoll_pwait(0, [], 1024, 460, NULL, 8) = 0
epoll_pwait(0, [], 1024, 37, NULL, 8) = 0
epoll_pwait(0, [], 1024, 500, NULL, 8) = 0
epoll_pwait(0, [], 1024, 460, NULL, 8) = 0
epoll_pwait(0, [], 1024, 38, NULL, 8) = 0
epoll_pwait(0, [], 1024, 500, NULL, 8) = 0
epoll_pwait(0, [], 1024, 459, NULL, 8) = 0
epoll_pwait(0, [], 1024, 38, NULL, 8) = 0
epoll_pwait(0, [], 1024, 500, NULL, 8) = 0
epoll_pwait(0, [], 1024, 460, NULL, 8) = 0
socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 12
setsockopt(12, SOL_TCP, TCP_NODELAY, [1], 4) = 0
setsockopt(12, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
setsockopt(12, SOL_TCP, TCP_KEEPIDLE, [60], 4) = 0
setsockopt(12, SOL_TCP, TCP_KEEPINTVL, [1], 4) = 0
setsockopt(12, SOL_TCP, TCP_KEEPCNT, [10], 4) = 0
Ответ или решение
Похоже, у вас возникли проблемы с сервером PostgreSQL на вашем сервере Almalinux, установленном в Hetzner. Симптомы включают в себя значительное использование ресурсов процессора и памяти, а также блокировку IP-адреса вашего сервера дата-центром. С помощью strace вы заметили постоянные попытки подключения к внешним IP-адресам, что вызывает нагрузку на сервер.
Такое поведение ненормально и может указывать на некоторые потенциальные проблемы. Рассмотрим возможные причины и решения:
-
Возможная компрометация системы:
- Если PostgreSQL или другие процессы пытаются подключиться к неизвестным внешним IP-адресам, это может указывать на взлом вашего сервера. Вредоносные программы могут использовать ваш сервер для рассылки спама или других нежелательных действий.
- Проверьте, какие программы и процессы работают на сервере. Используйте команды
ps aux
,netstat -tulnp
, иss -tulnp
, чтобы идентифицировать подозрительные активности. - Проверьте журналы системного и PostgreSQL.
-
Неожиданное поведение сторонних расширений или конфигураций:
- Проверьте список установленных расширений в PostgreSQL и убедитесь, что все они безопасны и нуждаются в вашей конфигурации.
- Проанализируйте параметры конфигурации PostgreSQL и убедитесь, что они не настроены для выполнения неожиданных сетевых операций.
-
Конфигурационная ошибка:
- Проверьте конфигурационные файлы PostgreSQL на предмет неправильных сетевых настроек. Это могут быть settings, касающиеся подключения к сетевым интерфейсам или настройкам резервного копирования.
- Убедитесь, что только разрешенные хосты имеют доступ к PostgreSQL, используя файл
pg_hba.conf
.
-
Reстрикции и Патчи безопасности:
- Если ваш сервер не обновлялся недавно, убедитесь, что у вас установлены все последние обновления и патчи безопасности для ОС и PostgreSQL.
- Установите или обновите файрвол или инструменты защиты, чтобы предотвратить несанкционированный доступ.
Рекомендации по действиям:
- Немедленно отключите сервер от сети, если вы подозреваете взлом.
- Переустановите ПО, если возможно (например, PostgreSQL), и настройте его заново.
- Рассмотрите возможность использования дополнительных мер безопасности, таких как средство обнаружения вторжений (IDS).
Важно также взаимодействовать с вашей инфраструктурной поддержкой или провайдером дата-центра, чтобы выяснить причину блокировки IP и обсудить возможные решения.