Взломали сервер. Спамят с 25 порта.

Надо бы разобраться через какую дырку тебя взломали. Php shell это намек. В противном случае смысла от переустановки не много

я подозреваю через какую. думаю это wordpress и плагины волнует только, почему ко мне на 25 порт летят пакеты и есть ли доступ у паразитов на сам впс

Так php shell это и есть доступ на vps. А на 25 порт возможно тебе пытаются слать отлупы те, кому ты отправил письма ранее

Хотят через твой сервак почту переправлять, у тебя там что почтовый сервер что ли?

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

Стоит ли переустановить сервер?

Я бы переустановил от греха подальше.

был установлен. я его отключил уже.

что можно проверить? логи на месте вроде. может смотрел не то

логи на месте вроде.

По ним видно, что и когда …

какие конкретно проверить можно?

В идеале — все. Может оно ещё куда пролезло и спряталось; будешь потом искать дыры, а оно тебя изнутри ломает.

А так — auth, cron, security, maillog.

О дистра зависит, messages, security, httpd … там кучи их.

P.S. Не понимаю зачем люди пытаются админить linux если в нем полный 0.

логи в порядке вроде. непонятно только почему ко мне на 25 порт летят запросы

Не понимаю зачем люди пытаются админить linux если в нем полный 0.

И при этом категорически не желают учиться!
Думают, что переустановка решит все их проблемы, ага, как же…

А вообще, это не только про админство.

логи в порядке вроде

Как ты это понял? (%

непонятно только почему ко мне на 25 порт летят запросы

Очень даже понятно: потому что он открыт. (%

У тебя неправильные вопросы. Правильно заданный вопрос содержит в себе половину ответа!

Стоит ли переустановить сервер?

облить бензином и сжечь

они на месте. не потерты. и на первый взгляд ничего не вижу там криминального. изучу подробнее.

про порт я спрашивал в первом сообщении. применил такие правила

sudo iptables -A INPUT -p tcp --dport 25 -j DROP
sudo iptables -A OUTPUT -p tcp --dport 25 -j DROP

на input копятся байтики так вот вопрос был, правильно ли я понимаю. что хоть я и вижу через tcpdump входящие запросы к себе на порт 25 - они дропаются. или, если бы было закрыто я бы даже в tcpdump не видел?

они на месте. не потерты.

Тереть файлы это огромный красный флаг, «смотри, мы тебя взломали, мы уже здесь!» Обычно достаточно опустошить его, хотя бы частично (с момента взлома до получения прав — вполне достаточно).

на input копятся байтики так вот вопрос был, правильно ли я понимаю. что хоть я и вижу через tcpdump входящие запросы к себе на порт 25 - они дропаются. или, если бы было закрыто я бы даже в tcpdump не видел?

Если они копятся только на input, значит к тебе прилетает, и "по пути умирает" — ответ обратно никакой не шлётся (правильнее делать return, чтобы отправитель видел что у тебя порт закрыт… хотя ботнетам пофиг).

я бы даже в tcpdump не видел?

Тогда какой толк от tcpdump?
Вообще, оно видит даже пакеты, которые "пролетели мимо" (предназначены другому сетевому интерфейсу или машине). В promiscious mode.

есть ли доступ у паразитов на сам впс

Учитывая, что ты не переставлял систему, и не знаешь точно как тебя ломали, то разумно думать, что да, есть.

ответ обратно никакой не шлётся (правильнее делать return, чтобы отправитель видел что у тебя порт закрыт… хотя ботнетам пофиг).

Наоборот, лучше делать именно DROP, чтобы отправитель «мучался ожиданием ответа», а мы не тратили ни лишнее процессорное время на генерацию ответных rst-пакетов, ни канал сетевой карты на их отправку.

Более того, разумно думать, что он у них быстро появится заново после переустановки.

Он выше писал что у него был почтовый сервер, который он уже отключил. Я хз зачем ему сдался этот 25 порт тогда …

Лучше бы по логам httpd поглядел чего тама было.

лучше

Тебе не кажется что "правильнее" и "лучше" это два совершенно разных по смыслу слова? ^_~

Лучше — для кого?

чтобы отправитель «мучался ожиданием ответа»

Даже если это нормальные отправители (у топикстартера была почта, читай тред), а не спамеры долбят релей?

Отправитель не будет мучиться, а почтовый сервер просто будет долбить пока письмо не примут наконец.

а мы не тратили ни лишнее процессорное время на генерацию ответных rst-пакетов, ни канал сетевой карты на их отправку

Экономия на спичках. Причём отправить reset, в случае если это нормальный почтовый сервер — дешевле, он увидит что порт закрыт и угомонится на какое-то время, а через несколько попыток и вовсе прекратит это делать. А с drop сервер-отправитель не получает никакого ответа.

Он выше писал что у него был почтовый сервер, который он уже отключил.

Он ведь не уточнил что именно ему там летит на 25.
Но написал только что хостер говорит что от него летит много с 25.

Лучше бы по логам httpd поглядел чего тама было.

На этом наши полномочия как бы всё, кончились. (=

Тебе не кажется что «правильнее» и «лучше» это два совершенно разных по смыслу слова? ^_~

Не кажется. У слова «правильнее» тут смысл может быть только такой же как у «лучше» - сделать лучше владельцу сервера. Никакой другой правильности в данном контексте быть не может.

Отправитель не будет мучиться, а почтовый сервер просто будет долбить пока письмо не примут наконец.

rst и таймаут они обрабатывают обычно примерно одинаково (несколько попыток, а потом «письмо невозможно доставить»), так что нам пофиг.

Вот если бы в smtp был статус «почтового сервера тут нет и не будет, больше никогда не пытайся сюда коннектиться» - она имела бы смысл.

У слова «правильнее» тут смысл может быть только такой же как у «лучше» - сделать лучше владельцу сервера.

Подмена понятий чтобы натянуть на личное мнение.
Иди, читай RFC. Прочитаешь — переформулируй и зови, в таком виде я не стану даже читать дальше, не то что время тратить на ответ.

ну если root получили - может быть все что угодно. А вообще по крайней мере посмотри скрипты автозапуска + там могут какую нить хрень запускать где угодно

RFC тут ни при чём. У владельца любого сервера есть единственная задача - эксплуатировать его себе на благо. RFC можно читать чтобы узнать, как именно его эксплуатировать целесообразнее. Ну, например, если сервер будет слать битые tcp-пакеты, то к нему никто не сможет подключиться и задачу он не выполнить. Как сделать не битые - написано в rfc. Но вот всякие заявления вида «делайте так, просто потому что тут так написано, и невзирая на то что пользы вы от этого не получите» можно смело игнорировать.