Перекиньте свой сайт на https и ваш хостинг не сможет безнаказанно перехватывать трафик, как минимум у пользователей будет выскакивать ошибка сертификата и это станет сразу видно.
Странно, что у вас интернет работать не переставал. При чем только LeaseWeb и ваши базы 🍿
На виртуальном, если софт используется от ISPsystem, то и проблемы бы такой не возникло, т.к там устанавливается агент внутри сервера и пароль можно поменять из vmmanager.
Это если есть IPKVM/IPMI
В большом кол-ве датацентров управление питанием происходит через APC powerbar или аналогичное устройство. Поэтому автоматизированная перезагрузка в rescue по-любому перезагрузит сервер внепланово, т.е по питанию, а не через ctrl-alt-del.
Конечо, если есть IPMI, можно перегрузить "мягко", но чаще всего его нет.
Квоты будут проверяться после такой перезагрузки гарантированно, а fsck - не факт, но чаще всего будет именно так , т.к сервер не перегружался до этого очень давно.
Да, конечо, если клиент просит быстро, можно отключить проверку fsck и не монтировать ФС c квотами. Тогда гарантированно укладываемся в 20 минут (а то и меньше), при отсутствии хардварных проблем (диск сдох, сервер залип с ошибкой в BIOS).
Вы не учитываете тот момент, что
а) сервер не перезагружался XXX дней и будет инициирована проверка диска. При очень большом кол-ве файлов, а так же файловой системе ext3 это может занять длительное время
б) сервер скорее всего будет перезагружен по питанию, а значит с вероятностью 100% навернется файл с дисковыми квотами и при перезагрузке он будет перестроен. На большом количестве файлов это очень медленная операция. И сервер все это время будет недоступен.
Поэтому со стороны хостера ответ вполне резонный.
Через RIPE у провайдеров требовать ничего не получится.
RIPE ведет базу данных маршрутов - route object, магистральные провайдеру используют эту БД для построение фильтров BGP, для того чтобы не было всяких route hijacks, т.е кто-нить гугл не стал анонсировать.
Что касается спуфинга исходящего IP, то это к фильтрам BGP не имеет никакого отношения и находится на совести конечного провайдера.
Я че-то тут подумал, что RIPE, radb и прочее irr никак не помогут в борьбе со спуфом, т.к для этого потребуется, чтобы непосредственно сам провайдер фильтровал у себя на бордере исходящий трафик и не пускал в свои апстримы не свой траф. А указанные базы влияют только на фильтры BGP, а ни как не на фактическое прохождение пакетов.
Но вот в целом, для рассылки спама - очень сложное решение у ваших "вредителей", даже я бы сказал мало правдоподобное.. слишком много других способов имеется для этой не хорошей задачи.
https://en.wikipedia.org/wiki/Opportunistic_TLS#SSL_ports
Извините, если не понял сути (много написано), но почту можно отправлять не только через 25 порт.
Есть еще 587 порт SMTP+STARTTLS
