Вы упомянули, что cronjob работает случайно; Вы проверяли cronjobs crontab -l
для чего-нибудь необычного? Является ли учетная запись скомпрометированной учетной записью root? Даже если это не так, проверили ли вы последние логины и записи cron для учетной записи root, есть ли у вас права root?
Я регулярно сталкиваюсь со словарными атаками с IP-адресов по всему миру на сервер SSH, которым я управляю. Если вы используете аутентификацию по паролю и не используете надежный пароль , кто-то может также угадать ваш новый пароль.
Если вы управляете сервером, то есть у вас есть root-доступ, если вы знаете, что вам нужно будет подключаться к серверу только по SSH с ограниченного числа или диапазона IP-адресов, создайте правило брандмауэра, чтобы разрешить SSH-доступ только с IP-адресов. с которого нужно подключиться.
На этом этапе, если злоумышленник, возможно, получил root-доступ, может быть трудно исключить возможность того, что злоумышленник не установил какое-либо программное обеспечение, чтобы разрешить ему доступ и другими способами, например, путем изменения системных файлов, поэтому самый безопасный путь будет переустановить операционную систему и все необходимые вам приложения. Если это невозможно, можете ли вы контролировать и контролировать доступ к системе из точки, внешней по отношению к системе, например, через брандмауэр перед сервером?
Также см. Вопрос о сбое сервера. Как узнать, что мой сервер Linux был взломан? для предложений о действиях, которые вы можете предпринять. Например, Ян Пертон предложил использовать команду, find /etc /var -mtime -2
чтобы увидеть, были ли файлы изменены в последние два дня в этих каталогах. Замените соответствующее количество дней на -2
. Вы также можете запустить chkrootkit, как кто-то другой предложил.
Если вы используете программное обеспечение брандмауэра, которое позволяет вам указать fqdn в дополнение к IP-адресам для правил брандмауэра, вы можете указать, что хотите разрешить доступ с чего-то вроде muki.mydomain.com, а затем использовать службу DDNS , такую как No- IP, так что любой новый IP-адрес будет связан с muki.mydomain.com. No-IP предлагает бесплатный уровень обслуживания, при котором вы используете один из их доменов, но можете указать что-то вроде muki.noipdomain.com для вашего хоста. Затем вы устанавливаете программное обеспечение в системе, которую используете для клиента SSH, который периодически сообщает свой IP-адрес DNS-серверам без IP. Затем эти серверы будут преобразовывать muki.mydomain.com или muki.noipdomain.com в любой текущий IP-адрес, назначенный системе, из которой вы пытаетесь установить соединение SSH.
Или вы можете контролировать доступ с помощью открытых / закрытых ключей вместо паролей. Т.е. кто-то может войти в учетную запись только на SSH-сервере, если у него есть закрытый ключ, соответствующий открытому ключу для учетной записи на сервере. Если аутентификация по паролю отключена, а доступ ограничен открытыми / закрытыми ключами, тогда угадывание пароля не будет работать. Только тот, кто имеет закрытый ключ, соответствующий открытому ключу для учетной записи на сервере, может войти в эту учетную запись через SSH. Я не использую WHM, но есть статья WHM / cPanel: SSH с отключенным Root Login о том, как это сделать с помощью WHM.