Стоит только выставить голую жопу пару сервисов в Интернет — тут же начинают всячески их абъюзить, то есть, говоря общо, использовать не по назначению. Рассмотрим возникающие проблемы и варианты их решения, на паре примеров. Я попробую писать так, чтобы понятно было всем. Только для юниксоидов и желающих приобщиться. Поправки и комментарии приветствуются. На полноту охвата решений я не претендую, изложены лишь некоторые варианты.

Проблема 1: brute-force атака по перебору паролей на sshd.

Злобные и тупые крякеры, завидев на стандартном 22-м порту работающий sshd, начинают пытаться логиниться туда рутом, перебирая пароли. Конечно, не вручную, а с помощью генератора паролей, поэтому попытки идут довольно быстро. Если у вас рутовый пароль нормальный, а не "пять пятёрок" (как было по дефолту в одной из организаций, где я давно работал), то опасаться в принципе нечего. Беспокоит только большое количество записей в логах, мол, "пытались залогиниться с такого-то хоста таким-то юзером, пароль неверен". А когда логов много, они превращаются в мусор. Это плохо — в общем-то, логи надо читать, а мусор читать невозможно.

Решения
Вариант 1.1: на уровне фаерволла (iptables) разрешить доступ на 22-й порт только с тех IP адресов, с которых ты реально ходишь или собираешься, а со всех остальных — запретить. Плюсы: достаточно простое и, пожалуй, наиболее секьюрное решение. Минусы: оказавшись в гостях, в командировке, в интернет-кафе, у чёрта на куличках — на свою машину вы не зайдёте. Workaround: иметь другую машину, на которую вы можете зайти отовсюду, и включить её IP в "белый список".

Вариант 1.2: написать скриптик, читающий те логи о неправильных логинах, и закрывающий доступ на 22-й порт тому, кто особенно рьяно ломится (например, сделал более 10 неуспешных попыток логина за минуту). Плюсы: эффективно, "самообучаемо". Минусы: относительная сложность/громоздкость реализации, надо программировать, держать демона, он может упасть и т.п.

Вариант 1.3: ограничить rate (как ето по-рюсски?) SYN-пакетов на 22-й порт. То есть не давать делать более трёх (к примеру) коннектов в минуту. Они будут перебирать пароли, но куда как медленнее. Плюсы: достаточно просто. Минусы: от мусора в логах полностью не избавляет.

Вариант 1.4: перевесить sshd на другой порт. Это делается директивой Port в файле /etc/ssh/sshd_config. Плюсы: самое простое и надёжное решение. Минусы: на клиенте нужно явно прописывать порт; продвинутые крякеры могут найти ваш sshd с помощью портскана и брют-форсить новый порт.

Я использую на *.openvz.org и некоторых других своих хостах как раз последний вариант, покоряющий меня своей простотой.

Проблема 2: спам.

Заводим мы кучу имейлов, адресов рассылки и т.п. Потом на всё на это начинает сыпаться спам (особенно в адреса рассылки, ибо их адреса даны тут и там, а потом ещё люди начинают держать у себя их архивы и т.п.).

Вариант 2.1 (только для списков рассылки): поставить опцию "только подписчики могут постить в список" для всех списков рассылки. Плюсы: простота реализации; помогает очень хорошо, ни один спам-робот не догадается пройти процесса подписки. Минусы: иногда на список пишут что-то довольно умное и важное неподписанные люди, и их приходится пост-модерировать вручную. А вместе с ними и весь спам. Что превращает простое элегантное решение в ежедневный кошмар. Поэтому надо что-то придумывать вдобавок.

Вариант 2.2: поставить spam assassin или dspam. Плюсы: таки убьёт большую часть спама. Минусы: нетривиальная инсталляция/настройка/обучение; прожорливость по части ресурсов (память, процессор); возможность false positives (это когда не-спам примут за спам и важное письмо улетит в тартарары). Многовато минусов, незачёт.

Вариант 2.3: чёрные списки. Чёрный список обычно ведёт какая-нибудь компания или организация, а ты можешь им воспользоваться; точнее, почтовый сервер может проверять, скажем, айпи отправителя на присутствие в этом блэк-листе. Плюсы: раньше это работало. Минусы: в последние годы эта мера себя полностью дискредитировала: организации начинают ставить в блек-листы кого попало, а за удаление просят немного денег. Коммерция тут ни к чему хорошему не приводит — понятно, что спамер может запросто и заплатить. Вторая проблема — нехватка IP адресов и повсеместное использование NAT/masquerading, что ведёт к тому, что за одним IP скрывается сотня пользователей; когда один из них шлёт спам (к примеру, с заражённого компа) и IP попадает в чёрный список, это затрагивает всех остальных.

Вариант 2.4: honeypots ("как ето по-рюсски? ловушки?"). Да, ловушки. Это вариант самонастраивающегося собственного чёрного списка. Это когда вы на сайте публикуете адрес почты, и пишете: "Этот адрес — ловушка, предназначенная для спам-ботов, собирающих почтовые адреса. Внимание: если вы напишете на него, то попадёте в чёрный список!". Понятное дело, что спам-боты тупые и не могут понять сиё предупреждение, в то время как большинство людей отличаются чуть большим интеллектом и не станут на адрес ловушки посылать пространных посланий. Сам я это не пробовал и не могу сказать, работает или нет, хорошо ли или так себе...

Вариант 2.5: серые списки (greylisting). Идея такая: когда приходит письмо, сервер отвечает (соответствующим кодом), что вот прямо сейчас он несколько не готов принять это письмо, мол, "временно не могу". На что правильный почтовый сервер на стороне отправителя не смутится, а поставит то письмо в очередь на повторную отправку, которая случится, как правило, через час. Вот на сей раз письмо примется, а сервер поставит триплет from_email:to_email:sender_ip в белый список. А неправильный почтовый сервер (какой-нибудь спамерский масс-мейлер) увидит, что что-то не сложилось, и не будет откладывать письмо для повторной отправки. Плюсы: простота идеи, самонастраиваемость. Минусы: первое письмо приходит с задержкой; некоторые "правильные" мейлеры на самом деле неправильные; есть вероятность, что некоторые спамеры продвинуты и используют "правильные" мейлеры.

В общем, я воплотил на openvz.org варианты 2.1 (давно) и 2.5 (вчера) и через пару недель расскажу, что из этого получилось.