Що означає скарга на зловживання з VPS

Що насправді означає скарга на зловживання з VPS

Скарга на зловживання з VPS — це повідомлення про мережевий трафік, який вийшов із вашої IP-адреси та був надісланий контакту для скарг, опублікованому для цього блоку IP-адрес. Потім ваш хостинг-провайдер пересилає це повідомлення вам і надає час для відповіді. Опублікований контакт належить компанії, яка володіє цим адресним простором. Тому першим повідомлення про ваш сервер майже ніколи читаєте не ви. Хостинг-провайдер зіставляє IP-адресу та час із вашим обліковим записом і пересилає скаргу.

Це повідомлення не доводить, що ви навмисно щось зробили. IP-адреса — єдиний ідентифікатор, доступний тому, хто надіслав скаргу. Скомпрометований застосунок, який надсилає спам о 03:00, спричиняє таке саме повідомлення, як і людина, яка надсилає спам о 03:00. Саме тому відповідь має вирішальне значення. Від вас очікують пояснення, яким було джерело проблеми та що ви змінили.

Хто надсилає звіт і як він потрапляє на ваш хост

Кожен публічний блок IP-адрес зареєстрований у регіональному інтернет-реєстраторі (RIR): RIPE NCC, ARIN, APNIC, LACNIC або AFRINIC. У кожному записі публікується контакт для повідомлень про зловживання. Саме туди надходять звіти. Ви можете переглянути той самий запис, який бачить відправник звіту:

whois 203.0.113.10 | grep -iE 'netname|descr|abuse'

Записи RIPE містять об’єкт ролі abuse-c:, у якому вказано рядок abuse-mailbox:. Записи ARIN містять OrgAbuseEmail:. На опубліковану там адресу надходять скарги. Тому звіт про ваш сервер потрапляє до вашого хоста, а не у вашу поштову скриньку.

Зазвичай звіт надсилає машина. Майже всі випадки, з якими ви зіткнетеся, належать до чотирьох типів:

• Автоматизовані сканери та honeypot-системи. Машина фіксує спробу підключення з вашої IP-адреси та надсилає звіт із доданим фрагментом журналу.
• Цикли зворотного зв’язку (FBL), які підтримують поштові провайдери. Одержувач натискає кнопку скарги на спам, і копія повідомлення повертається у форматі ARF (abuse reporting format) — структурованому поштовому форматі, призначеному для машинного аналізу.
• Агенти з питань авторських прав. Вони відстежують torrent-рої або сканують загальнодоступні URL, а потім надсилають повідомлення DMCA (digital millennium copyright act), у якому вказують файл, вашу IP-адресу та часову позначку в UTC.
• Оператори blocklist і мережеві інженери, які надсилають короткий лист із проблемними рядками з власних журналів.

Оскільки більшість перших звітів генерується автоматично, аргументація у відповіді нічого не дає. Натомість важливі факти: що саме працювало і коли це припинилося.

Чому повідомлення містить кінцевий термін

Ваш хост також є орендованим ресурсом. Його адресний простір розташований за мережами upstream-операторів і внесений до баз репутації, якими керують інші сторони. Проігноровані повідомлення погіршують оцінку всього адресного блоку, а не лише вашої окремої адреси, тому отриманий кінцевий термін є переданим вам тиском. Зверніть увагу на строк, указаний у повідомленні, і сприймайте його серйозно.

Якщо щодо проігнорованого випадку вживають заходів, це зазвичай null route, тобто трафік до цієї IP-адреси відкидається upstream-оператором, або призупинення інстансу. Причиною зазвичай є відсутність відповіді, а не початкова подія. Конкретні дії щодо певного хоста та строки їх виконання визначаються його власною політикою й самим повідомленням. Це єдині документи, на які варто посилатися, тому не дійте на підставі тверджень із форуму про те, що дозволяє провайдер.

Вихідний спам: чому мій VPS надсилає листи, яких я не надсилав

У звіті зазначено, що ваша IP-адреса доставила лист на spam trap або що одержувачі позначили ваші листи як спам. У більшості випадків причина одна з чотирьох: вебзастосунок із формою надсилання пошти без обмеження частоти запитів, витік SMTP-облікових даних, якими тепер користується інша особа, поштовий сервер, що ретранслює пошту для хостів, яким це не дозволено, або викрадений обліковий запис у застосунку для розсилок. Почніть із черги, оскільки скомпрометований відправник зазвичай помітний саме там:

sudo postqueue -p | tail -n 20
sudo postqueue -p | grep -c '^[0-9A-F]'

Черга з тисячами повідомлень на адреси, яких ви не впізнаєте, означає, що сервер надсилає пошту. Далі з’ясуйте, хто пройшов автентифікацію:

sudo grep -o 'sasl_username=[^ ]*' /var/log/mail.log | sort | uniq -c | sort -rn | head

Обліковий запис, для якого кількість повідомлень значно перевищує показники інших, використовує витік облікових даних. Якщо /var/log/mail.log не існує, у системі не встановлено rsyslog, а ті самі рядки містяться в журналі: sudo journalctl -t postfix --since '2 days ago'.

Якщо автентифікацію не виконано, відправником є локальний процес. Перевірте правила ретрансляції та відкриті з’єднання:

sudo postconf -n | grep -E 'mynetworks|inet_interfaces|relay'
sudo ss -tnp state established '( dport = :25 )'

Стандартний Postfix у Debian або Ubuntu не ретранслює пошту для сторонніх хостів. Він стає відкритим ретранслятором, коли параметр mynetworks вручну розширюють до цілої підмережі хостингу, оскільки тоді кожен інший орендар цієї підмережі отримує право надсилати пошту через ваш сервер. Будь-яке з’єднання з портом 25, яке належить процесу, що не є вашим поштовим сервером, означає, що скрипт надсилає пошту самостійно. Саме так зазвичай працює скомпрометований PHP-застосунок.

Зупиніть надсилання до початку розслідування та збережіть докази:

sudo systemctl stop postfix
sudo tar czf /root/mailqueue.tgz -C /var/spool postfix

sudo postsuper -d ALL очищає чергу, а також знищує дані про те, що було надіслано, тому спочатку створіть копію. Потім змініть усі облікові дані, до яких має доступ застосунок, оновіть застосунок і перевірте, що залишив після себе зловмисник. Інцидент зі спамом і компрометація найчастіше є однією подією, тому виконайте кроки відновлення після злому VPS, а не лише очистьте чергу.

Сканування портів і brute force: який вигляд має скомпрометований контейнер

У цьому звіті наведено рядки з журналу іншого оператора. Вони мають такий вигляд:

sshd[2841]: Invalid user admin from 203.0.113.10 port 51992

Майже завжди причина полягає в сервісі, який, на вашу думку, був захищений firewall. Часто це Docker. Публікація порту за допомогою -p 6379:6379 додає правила до ланцюжків DOCKER-USER і nat. Ці ланцюжки обробляються до правил ufw, тому ufw deny 6379 не блокує такий доступ, і база даних відповідає всьому інтернету.

sudo ss -ltnp
sudo iptables -S DOCKER-USER
docker ps

Усе, що в ss -ltnp прив’язано до 0.0.0.0 або [::], прослуховує публічну адресу. Якщо доступ до сервісу потрібен лише з хоста, публікуйте його на loopback-адресі: -p 127.0.0.1:6379:6379. Рішення про те, де саме має працювати база даних, потребує окремого розгляду. У матеріалі база даних у Docker чи на хості описано відповідні компроміси.

Щоб перевірити, чи сканує ваш сервер порти просто зараз:

sudo ss -tnp state syn-sent

Велика кількість напіввідкритих з’єднань до багатьох різних адрес означає, що триває вихідне сканування. Якщо kernel log заповнюється повідомленнями nf_conntrack: table full, dropping packet, це вказує на ту саму проблему з іншого боку: щось відкриває значно більше з’єднань, ніж цей сервер має підстави відкривати.

Скомпрометований контейнер потрібно перебудувати, а не очищати. Неможливо довести, що всередині нього не було змінено нічого іншого. Перебудуйте контейнер з образу, якому довіряєте, відновіть лише надійні дані та замініть cryptographic keys, якими володів цей контейнер.

Повідомлення про порушення авторських прав: який файл вони насправді побачили

У повідомленні DMCA вказано URL або info hash торента, вашу IP-адресу та часову мітку в UTC. Майже всі такі випадки мають одну з двох причин: вебсервер публічно показує каталог із медіафайлами або torrent-клієнт продовжує роздавати дані після завершення завантаження.

Зіставте часову мітку з журналом доступу. Формат combined log в nginx містить статус у полі 9, а шлях запиту — у полі 7:

sudo grep '14/Aug/2026:03' /var/log/nginx/access.log | awk '{print $9, $7}' | sort | uniq -c | sort -rn | head

Перш ніж зробити висновок, що нічого не було віддано, перевірте час. Повідомлення містить час у UTC, а журнали використовують часовий пояс сервера. Тому різниця в кілька годин може спрямувати пошук не в той часовий інтервал і призвести до хибного негативного результату:

timedatectl
sudo timedatectl set-timezone UTC

Після цього усуньте причину. Видаліть файл або обмежте доступ до нього, вимкніть показ вмісту каталогів за допомогою autoindex off; у блоці location nginx і прив’яжіть torrent-клієнт до інтерфейсу, який не є публічним. У відповіді вкажіть назву файлу, внесену зміну та час її виконання. Якщо ви вважаєте саму претензію помилковою, це юридичне питання між вами та відправником; у повідомленні зазначено порядок її оскарження. Ваш хостинг-провайдер не вирішує це питання, тому звернення з аргументами по суті претензії не дасть результату.

Переліки blocklist: чому перестала працювати вихідна пошта

У такій ситуації вам часто взагалі не надходить повідомлення. Вихідна пошта просто перестає прийматися, а bounce-повідомлення містить причину:

554 5.7.1 Service unavailable; Client host [203.0.113.10] blocked using zen.spamhaus.org

Перевірте наявність IP-адреси в переліку. Для цього поміняйте місцями чотири октети IP-адреси та виконайте запит до зони цього переліку:

dig +short 10.113.0.203.zen.spamhaus.org

Порожня відповідь означає, що вашої адреси в цьому переліку немає. Відповідь 127.0.0.x означає, що адресу внесено до переліку, а останній октет показує, який саме підсписок збігся. Відповідь у діапазоні 127.255.255.x означає, що запит відхилено, а не оброблено. Зазвичай це відбувається тому, що запит надійшов через великий публічний resolver, який безкоштовний сервіс не обслуговує. Повторіть запит через resolver самого сервера, щоб отримати фактичний результат.

Видалення з переліку виконується на сайті його оператора, а не через вашого хостинг-провайдера. Це допомагає лише після усунення джерела проблеми, оскільки trap, через який вашу адресу внесли до переліку, знову додасть її після наступного повідомлення. Після цього на доставлення пошти впливають ще дві речі. Запис PTR, тобто ім’я в reverse DNS для цієї IP-адреси, контролює ваш хостинг-провайдер. Попросіть його встановити ім’я, яке вказує назад на ту саму адресу, і використовуйте це ім’я як HELO. IP-адреса, повторно видана після попереднього орендаря, може мати історію, яку створили не ви. Тому варто запитати про це, перш ніж витратити тиждень на переписування DNS. Правильне налаштування записів SPF (sender policy framework) і DKIM (domainkeys identified mail), а також політики DMARC, яка їх об’єднує, повністю описано в посібнику із запуску власного поштового сервера з Mailcow.

Релейна інфраструктура, де опрацювання скарг на зловживання є частиною роботи

Якщо ви обслуговуєте вихідний вузол Tor, публічний VPN або проксі для інших користувачів, скарги на трафік, який генерували не ви, є звичайними операційними витратами. Ваше завдання — зробити так, щоб інфраструктура була явно схожа на relay, а не на скомпрометований сервер. Налаштуйте reverse DNS на описову назву, розмістіть на порту 80 коротку інформаційну сторінку з поясненням призначення цієї адреси, швидко відповідайте на листи до abuse-контакту тим самим поясненням і використовуйте доступну в програмному забезпеченні політику, щоб блокувати порти, з яких надходить найбільше скарг. Розмістіть relay на власній IP-адресі, а бажано — і на окремому інстансі, щоб null route для цієї адреси не вивів з ладу ваш вебзастосунок. Перед запуском узгодьте це з хостинг-провайдером, оскільки дозволені дії залежать від компанії, а іноді й від IP-блоку. Це питання слід ставити провайдеру, а не обговорювати на форумі. Запуск вихідного вузла Tor на VPS докладно описує exit policy та інформаційну сторінку.

Як відповісти так, щоб звернення закрили

• Опублікуйте контактну адресу, яку читає людина. RFC 2142 визначає abuse@ і postmaster@ у вашому домені як адреси, на які скаржники звертаються насамперед. Розмістіть цю поштову скриньку не на тому самому сервері, який вона захищає, оскільки призупинений інстанс не зможе доставити повідомлення про власне призупинення.
• Зберігайте журнали достатньо довго, щоб узагалі можна було надати відповідь. На звернення про трафік дванадцятиденної давності неможливо відповісти, якщо журнал ротувався через сім днів. Перевірте journalctl --disk-usage, задайте MaxRetentionSec=90d у /etc/systemd/journald.conf, а потім виконайте sudo systemctl restart systemd-journald. Журнали вебсервера та пошти ротуються за власним розкладом у /etc/logrotate.d/.
• Використовуйте UTC на сервері, щоб час у зверненні збігався з часом у журналах і не потребував додаткових обчислень.
• Відокремте те, що спричиняє скарги, від того, що не можна втратити. Розмістіть пошту на одній адресі, вебзастосунок — на іншій, а relay-сервіси — на окремих інстансах. Дія, застосована до IP-адреси, поширюється на все, що розміщено за нею.
• Відповідайте протягом установленого строку, навіть якщо розслідування ще не завершене. Проміжна відповідь із зазначеним часом є повною відповіддю для першого етапу.

Перша відповідь, після якої закривається більшість звернень, має бути короткою та конкретною:

Received, thank you. Confirmed at 09:14 UTC.
Source: a contact form in our web app that allowed unauthenticated sending.
Action: form disabled, Postfix stopped, all SMTP credentials rotated 09:31 UTC.
Evidence: mail queue and logs preserved for 90 days if you need them.
Next: patched app redeployed by 18:00 UTC today. I will confirm here.

Повідомте, що вам відомо, і зазначте, що ще не вдалося з’ясувати. Мовчання сприймається як ознака сервера без належного супроводу, а процедура ескалації застосовується саме до таких серверів. Чи належить вам узагалі виконувати цю роботу, залежить від придбаного продукту. У цьому полягає практична різниця між керованим і некерованим VPS-хостингом. На некерованому плані орендар сам виконує функції команди безпеки.

Як це виглядає, коли все працює належним чином

Скарга на зловживання спочатку є проблемою маршрутизації. Повідомлення про IP-адресу надходить до сторони, відповідальної за цю адресу, а потім передається тому, хто може усунути проблему. Ви контролюєте контактну адресу, зберігання журналів, розподіл сервісів між IP-адресами та швидкість відповіді. Якщо все це налаштовано правильно, більшість повідомлень закінчується після одного обміну. Ті самі підходи допомагають відповісти на ширше питання про безпеку VPS-хостингу, оскільки саме сервер, за яким ніхто не стежить, зрештою опиняється в чужих журналах.

FAQ

Чи означає скарга на зловживання, що мій VPS зламали?

Не обов’язково, але саме це потрібно перевірити насамперед. Звіт підтверджує лише те, що трафік виходив із вашої IP-адреси. Вихідний спам і сканування портів набагато частіше спричиняє скомпрометований застосунок або контейнер, а не власник облікового запису. Тому спочатку перевірте чергу пошти за допомогою sudo postqueue -p і сокети, що прослуховують порти, за допомогою sudo ss -ltnp. Повідомлення про порушення авторських прав і потрапляння до blocklist мають інший характер: зазвичай вони вказують на те, що ви навмисно запустили.

Скільки часу в мене є, щоб відповісти на повідомлення про зловживання?

Термін указано в отриманому повідомленні. Він залежить від хостинг-провайдера та категорії порушення. Для повідомлень про порушення авторських прав і spam trap зазвичай встановлюють найкоротші терміни. Сприймайте вказаний термін як фактичний і надішліть коротку проміжну відповідь до його завершення, навіть якщо ви ще встановлюєте причину. Для того, хто обробляє тикет, важливо бачити, що справою займається людина і що трафік припинився.

Моя IP-адреса потрапила до blocklist. Чи може хостинг-провайдер видалити її звідти?

Ні. Видалення з blocklist виконує оператор цього списку на власному сайті, а ваш хостинг-провайдер не має доступу до його бази даних. Водночас хостинг-провайдер керує записом PTR — іменем reverse DNS для вашої IP-адреси. Це окремий запит, який варто подати одночасно. Спочатку усуньте проблему з надсиланням, а потім подавайте запит на видалення з blocklist. Інакше spam trap, через який вашу адресу внесли до списку, знову внесе її туди після наступного повідомлення.

Чи потрібно повідомляти хостинг-провайдеру, що саме сталося?

Потрібно повідомити достатньо, щоб закрити тикет: указати джерело проблеми та час її припинення. Ви не зобов’язані надавати forensic-звіт або дані користувачів. Нечітка відповідь гірша за коротку, оскільки обробник тикета, який не бачить, що саме змінилося, не має підстав вважати справу вирішеною.

Чи можна ігнорувати автоматичний звіт сканера?

Ні. Автоматичні звіти враховуються, а повторні звіти щодо однієї IP-адреси погіршують оцінку всього діапазону адрес вашого хостинг-провайдера. Саме так невелика проблема перетворюється на ескалацію. Ваша відповідь може складатися з одного абзацу. Автоматизований відправник зазвичай її не читає, але її прочитає обробник тикета у вашого хостинг-провайдера. Саме він вирішує, що станеться з вашим інстансом.