Какими способами можно предотвратить выход спама с ваших серверов в случае взлома учетной записи хостинга?
У вас есть группа клиентов на сервере с cpanel, но они задаются вопросом, есть ли способ просто предотвратить возможность взлома учетной записи.
Когда я имел в виду скомпрометированный, я имел в виду, что клиент регистрируется или учетная запись клиента взламывается, а его учетная запись используется для рассылки спама.
не могли бы вы установить какой-либо тип условий фильтра / черного списка в exim или spamassassin, который блокировал бы / останавливал отправку почты, если бы она соответствовала этому?
Не поддавайтесь компромиссу. Шутки в сторону.
Контролируйте свой трафик. Вы поймете, что нормально, и сможете распознать ненормальный трафик.
Выключите ненужные демоны. Если сервер не должен отправлять почту, не запускайте sendmail или postfix.
Ограничьте доступ по SSH и / или назначьте SSH нестандартный порт (например, не используйте порт по умолчанию 22). Если вам нужно использовать порт 22, дополните его услугой вроде DenyHosts для отслеживания и остановки входящих попыток аутентификации бота по SSH.
Используйте или применяйте надежные пароли для себя и своих клиентов.
Вы работаете с провайдером веб-хостинга, что по своей природе означает, что ваши клиенты будут использовать ненадежный и часто небезопасный код.
Помимо того, что вы уже должны делать для общей защиты сервера, подумайте:
Запустите сканирование клиентских данных на наличие вредоносных программ с помощью такого инструмента, как мальдет. Регулярно обновляйте свои определения.
Разрешить исходящий SMTP-трафик только на локальный почтовый сервер, где вы можете регистрировать исходящую почту и осуществлять некоторый контроль над ней. Добавьте правило брандмауэра для исходящего трафика, которое запрещает кому-либо, кроме вашего почтового сервера, подключаться к порту 25 на удаленных узлах. Пример правила может быть:
iptables -I OUTPUT -m owner ! --uid-owner EXIM_USER -p tcp --dport 25 -j DROP
(Аутентифицированный SMTP-трафик на сторонний почтовый сервер клиента, такой как Gmail, будет проходить через порт 587, и это не повлияет на него.)
Проще всего было бы заблокировать исходящие соединения с портом 25 до тех пор, пока клиент не «запросит» его разблокировку для своего IP-адреса. На самом деле не должно быть никого, кто запускал бы почтовый сервер с сайта хостинга CPanel (если они генерируют электронную почту, которая «отправляется» другим сервером, то она должна быть отправлена на этот сервер на порт 587 согласно RFC и так с 1998 года).
Я действительно хочу, чтобы больше провайдеров уделяли вам внимание, даже если вы не блокируете трафик 25 порта назначения. Мы ценим эту мысль и еще больше ценим брандмауэр.
Если ни один из серверов, которые вы используете, не требует исходящей почты, я бы поставил билет на ваш хост и попросил их заблокировать входящий и исходящий порт 25 для систем. У ewwhite есть правильная идея - если одна из ваших систем полностью скомпрометирована, вы ничего не сможете сделать с этой системой, чтобы предотвратить ее превращение в зомби-спам или столь же нежелательные вещи. Однако вы можете вмешаться еще на один шаг вверх по цепочке.
Помимо комплексной стратегии защиты, поддержания обновлений, ограничения доступа и всех других передовых методов, о которых упоминает ewwhite, я предлагаю взять принцип наименьших привилегий на более высокий уровень для хоста или поставщика сети. Если машинам никогда не понадобится отправлять почту, сделайте так, чтобы они действительно не могу.
Я повторю совет ewwhite, а также предложение отбросить весь SMTP-трафик с вашего брандмауэра, кроме вашего почтового хоста, от Майкла Хэмптона.
Еще одно предложение - настроить отслеживание трафика в клиентских приложениях для исходящего SMTP. Их веб-серверы не должны генерировать почту, поэтому, если они ДЕЙСТВУЮТ, вы захотите узнать, о чем идет речь - возможно, вы сможете получить некоторое представление об исходном источнике. Другие вещи, которые можно попробовать:
Если вам известен IP-блок вашего клиента, вы можете перехватить трафик telnet, удаленного рабочего стола (3389) и SSH на веб-хост и отфильтровать их IP-блок из результатов. Это должно дать вам представление о том, управляет ли хостом кто-либо кроме них.
Другой тип трафика для отслеживания - это IRC, поскольку этот протокол широко используется как сеть команд и управления для компьютеров-зомби. Или просто отключите порты IRC на вашем брандмауэре так же, как вы сбросили SMTP.
Другой возможный вектор распространения вредоносных программ - через торренты. Если веб-сервер вашего клиента открывает торрент-соединения, он может использоваться как узел распространения торрентов, а также как источник спама в электронной почте. Если ваши клиенты не запрашивали эту услугу как поддерживаемую, вы можете либо отбросить ее через брандмауэр, либо отключить службы на хосте.
Окончательное решение: после того, как вы создали резервную копию того, что вам нужно для поиска вектора поглощения (или если нет реального толчка, чтобы выяснить, что произошло), вы можете просто убить виртуальную машину или повторно создать образ сервера, а затем восстановить клиентские приложения. и данные из предыдущей резервной копии. У них могут быть проблемы с этим ... но это одна из затрат на запуск незащищенного кода.
установить CSF (межсетевой экран ConfigServer)