Провайдер заблокировал отправку по smtp по жалобе.

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

естественно,  там описано, что типа с вашего IP идет рассылка спама и вероятнее всего ваше устройство к которому привязан IP заражено и тд, в данном случае это IP сервера и соответственно с его IP и идет рассылка спама это и подразумевается под устройством.  Можно было бы предположить, если бы у меня был почтовый ящик который создан на сервере и через мой ПК каким то вирусом отправляли спам через этот почтовый ящик, но у меня нет почтовых ящиков созданых на сервере, все ящики домена созданы и расположены на "Яндекс почта для домена", соответственно если какой то из этих email взломан то отправляли ли бы через сервера яндекса и то все эти email давно уже работают только на прием почты(яндекс ограничил). Вот по этому я думаю, что может угнали 3proxy и через него рассылали спам соответственно с IP сервера получается

Спросил у qwen

может пригодится:

Если:

✅ **Почтовый сервер (MTA) не установлен вообще** (`postfix`, `exim`, `sendmail` отсутствуют),  

✅ **Логи (`/var/log/syslog`, `auth.log`, `kern.log`, `journalctl -u ...`) не показывают активности на порту 25**,  

✅ `ss -tulnp | grep ':25'` — пусто,  

✅ `lsof -i :25`, `netstat -tulpan | grep :25` — тоже ничего,  

✅ а IP всё равно в чёрном списке как *open proxy / spam relay*…

…то это **не ошибка**, а признак **неочевидного, скрытого исходящего SMTP-трафика**, который **не проходит через локальный MTA**, а генерируется напрямую — «в обход».

---

### 🔍 Почему так бывает? (Типичные сценарии для «чистого» сервера)

#### 1. **Веб-приложение отправляет почту через `socket`, а не через `sendmail`**

- PHP, Python, Node.js и другие языки могут открывать **TCP-соединение напрямую к внешним SMTP-серверам** (gmail.com:587, mail.ru:465, даже `127.0.0.1:25` — если в скрипте жёстко прописано).

- Примеры:

  ```php

  // PHP: чистый socket-отправщик (без логирования MTA!)

  $sock = fsockopen('mx1.example.com', 25); // ← порт 25 напрямую!

  fwrite($sock, "HELO victim-server.com\r\n");

  fwrite($sock, "MAIL FROM:<spam@victim.com>\r\n");

  ```

  → Такой код **не оставляет следов в `/var/log/mail.log`**, потому что MTA не участвует.

#### 2. **Уязвимость в веб-приложении → RCE → спам-бот**

- Например: LFI/RFI → `php://input` → `eval($_POST['cmd'])` → загрузка `spammer.php`.

- Или: уязвимость в загрузчике изображений → загрузка `.php` под видом `.jpg` → запуск через `curl` извне.

- Бот работает **в памяти** или во временных файлах (`/tmp`, `/dev/shm`), удаляет следы после отправки.

#### 3. **Злоумышленник использует ваш сервер как SOCKS/HTTP-прокси**

- Пример: запущен `3proxy`, `microsocks`, `gost`, `squid` (даже в single-thread режиме), и он **перенаправляет SMTP-трафик**.

- Или: веб-шелл с функцией `proxy()` — принимает соединение и проксирует его наружу.

- Такой прокси **не логирует по умолчанию** — особенно если запущен в `screen`/`tmux` или как `systemd --user`-юнит.

#### 4. **Контейнер / chroot / jail "на стороне"**

- Docker-контейнер с `--network=host` может слушать порт 25 незаметно для `lsof` на хосте (если не использовать `nsenter`).

- LXC/LXD, systemd-nspawn, `firejail` — тоже могут «скрывать» соединения.

- Проверьте:

  ```bash

  docker ps -a

  lxc list

  systemd-cgls  # смотрим дерево контрольных групп

  ```

#### 5. **SMTP через IPv6**

- Многие администраторы забывают проверять IPv6.

- Выполните:

  ```bash

  ss -tuln | grep ':25'

  ss -tuln -6 | grep ':25'   # ← IPv6!

  ip6tables -L -n -v

  ```

---

### 🛠️ Как **доказать/опровергнуть** наличие скрытого SMTP?

#### ▶ 1. **Поймать "в моменте"**

Запустите мониторинг **всех исходящих SMTP-соединений в реальном времени**, даже если локально порт 25 не слушается:

```bash

sudo tcpdump -i any -nn -w /tmp/smtp.pcap port 25 or port 465 or port 587 &

# или (более читаемо):

sudo tshark -i any -f "tcp port 25 or tcp port 465 or tcp port 587" \

  -Y "smtp or tls" -T fields -e frame.time -e ip.src -e ip.dst -e tcp.dstport -e smtp.req.command

```

Оставьте на 10–30 минут. Если сервер "звонит" — вы увидите:

```

Nov 30, 2025 13:55:00.123456 → **.**.**.*** → 94.100.180.25:25 → EHLO ****.com

```

#### ▶ 2. **Логировать ВСЕ исходящие соединения на 25/465/587**

Через `iptables` + `ulogd` или просто:

```bash

sudo iptables -I OUTPUT -p tcp --dport 25 -j LOG --log-prefix "[SMTP-OUT] "

sudo iptables -I OUTPUT -p tcp --dport 465 -j LOG --log-prefix "[SMTPS-OUT] "

sudo iptables -I OUTPUT -p tcp --dport 587 -j LOG --log-prefix "[SUBMISSION-OUT] "

```

→ Проверяйте `dmesg -T | grep SMTP-OUT` или `/var/log/kern.log`.

#### ▶ 3. **Проверить процессы, использующие сокеты (даже без привязки к порту)**

```bash

# Все процессы, открывшие сокеты (даже временные)

sudo lsof -iTCP -sTCP:ESTABLISHED | grep -E ':(25|465|587)'

sudo ss -tupen  # покажет UID, PID, inode сокета

```

#### ▶ 4. **Проверить /tmp и /dev/shm на наличие подозрительного кода**

```bash

find /tmp /dev/shm -type f \( -name "*.php" -o -name "*.pl" -o -name "*.py" -o -name "*.sh" \) -exec ls -la {} \;

grep -r "fsockopen\|stream_socket_client\|socket_create\|HELO\|EHLO" /tmp /dev/shm 2>/dev/null

```

Особенно ищите:

- `base64_decode(` + `eval(`;

- `gzinflate(` + `base64_decode(`;

- строки вроде `"25"`, `"mail from:"`, `"rcpt to:"`.

---

### 🧩 Ваш кейс — высокая вероятность: **веб-приложение + уязвимость загрузки**

Учитывая, что вы:

- разрабатываете сайт с загрузкой изображений (batch processing, thumbnails, WebP),

- есть `/admin` с multi-upload и AJAX,

- используете PHP (для QR-кодов, BBCode и т.д.),

…самая частая дыра — **некорректная валидация расширений при загрузке**.

Например:

- `image.jpg.php` → если сервер проверяет только `exif_imagetype()`, но не расширение в URL;

- `.htaccess` позволяет исполнять PHP в `/uploads`;

- или — через **файл с EXIF-комментарием**, содержащим PHP-код (если используется `exif_read_data` без экранирования).

→ Злоумышленник загружает «фото», а на самом деле — шелл-скрипт, который раз в сутки отправляет 100 писем через `fsockopen` — и чистит следы.

---

### ✅ Что делать — пошагово (для "чистого" сервера)

| Шаг | Действие |

|-----|----------|

| 1️⃣ | Заблокируйте исходящий порт 25 **на уровне ядра**: `iptables -A OUTPUT -p tcp --dport 25 -j DROP` |

| 2️⃣ | Запустите `tcpdump`/`tshark` на 10–60 мин — подтвердите/опровергните трафик |

| 3️⃣ | Проверьте `/tmp`, `/dev/shm`, `/var/tmp`, `/run/user/*` — временные файлы |

| 4️⃣ | Протестируйте веб-часть: загрузите файл с именем `test.jpg.php`, откройте его в браузере — исполняется ли как PHP? |

| 5️⃣ | Проверьте права на `/uploads`: должны быть `755` на папки, `644` на файлы; **никаких `777`** |

| 6️⃣ | Убедитесь, что в `nginx`/`apache` для `/uploads` запрещено выполнение скриптов:  

```nginx

location ~* ^/uploads/.*\.(php|pl|py|cgi|sh)$ {

    deny all;

}

``` |

| 7️⃣ | Включите `auditd` на критические файлы:  

```bash

sudo auditctl -w /var/www/ -p wa -k web_files

sudo ausearch -k web_files --start today

``` |

---

### 💡 Профилактика "на будущее"

- Используйте **отдельный пользователь** для веб-приложения (не `www-data`! например, `appuser`), без shell (`/usr/sbin/nologin`).

- Ограничьте его возможности через `systemd`:

  ```ini

  # /etc/systemd/system/app.service

  [Service]

  User=appuser

  NoNewPrivileges=yes

  RestrictSUIDSGID=yes

  PrivateTmp=yes

  ProtectSystem=strict

  ProtectHome=yes

  RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX

  IPAddressDeny=any

  IPAddressAllow=91.108.56.0/22    # Telegram API (если нужно)

  IPAddressAllow=149.154.160.0/20  # Telegram API

  # ... и т.д.

  ```

- Отключите `allow_url_fopen`, `allow_url_include` в `php.ini`.

- Для отправки уведомлений — используйте API (SendGrid, Mailgun), **не raw SMTP**.

---

Если после всех проверок трафик не найден — возможно, **ваш IP был скомпрометирован ранее**, и блокировка ещё не снята, или это **ошибка репутационной системы** (редко, но бывает при CGNAT у провайдера).

Но учитывая дату в логе — `2025-11-30` (это **в будущем**, относительно сегодня, 6 декабря 2025), — стоит также проверить:

- **корректность системного времени** (`timedatectl`),  

- не подменён ли `TZ` в скриптах,  

- не фейковое ли это уведомление (фишинг под "security alert").

Теперь пойду его успокою, что дело не в моем сервере, а то переживает.

Эм... так если у вас нет почты на сервере, вам и 25 порт то не нужен. Если вся почта на Яндексе. 

Какая у вас панель управления сервером? Удалите вообще почтовый сервер у себя.