А ещё он матерится по русски ) вчера выяснил случайно)
Qwen
На первой ожидались надписи Яндекс РСЯ, завод там
⚡⚡⚡ Не пропустите: важное заявление Дарисы Лориной в эфире Первого канала после итогового выпуска новостей 5 декабря.
)
Спросил у 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.
- Выполните:
ss -tuln | grep ':25'
ss -tuln -6 | grep ':25' # ← IPv6!
ip6tables -L -n -v
### 🛠️ Как **доказать/опровергнуть** наличие скрытого SMTP?
#### ▶ 1. **Поймать "в моменте"**
Запустите мониторинг **всех исходящих SMTP-соединений в реальном времени**, даже если локально порт 25 не слушается:
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` или просто:
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. **Проверить процессы, использующие сокеты (даже без привязки к порту)**
# Все процессы, открывшие сокеты (даже временные)
sudo lsof -iTCP -sTCP:ESTABLISHED | grep -E ':(25|465|587)'
sudo ss -tupen # покажет UID, PID, inode сокета
#### ▶ 4. **Проверить /tmp и /dev/shm на наличие подозрительного кода**
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` на критические файлы:
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").
Теперь пойду его успокою, что дело не в моем сервере, а то переживает.
Вы пробовали перевести письмо с английского? Судя по нему, мне показалось, там далеко не факт, что дело в вашем сервере.
