POP3/IMAP

SMTP

Telnet/SSH

FTP

HTTP/HTTPS

Здесь особые вариации отсутствуют: на *nix платформах безгранично властвует Web-server Apache. Сервер этот в особых проблемах с безопас ностью замечен не был, за исключением, может быть, настройки по умолчанию (в каковой присутствуют два не очень приятных для администратора скрипта). Да и работает этот сервер обычно от пользователя с минимальными правами в системе (идеальный вариант – вообще для каждого сервера/демона и для Apache в том числе – выделить своего отдельного пользователя с непересекающимися группами других сервисов и пользователей).

Здесь ситуация уже не так однозначна: не столь редко, сколько хотелось бы можно встретить на дистрибутиве по умолчанию демон WU-FTP, который всем вроде неплох, но вот по количеству «дырок» среди себе подобных, он, пожалуй, безусловный лидер. В качестве альтернатив, написанных с учётом требований безопасности, можно предложить ProFTP, BSD FTPD. Стоит заметить, что сам по себе FTP-протокол небезопасен, о чём подробнее можно прочитать здесь https://www.security.nnov.ru/articles/sacerdote.asp.

Оба вышеобозначенные протокола используются для удалённого доступа к машине. Относительно безопасности: в реализациях обоих протоколов были серьезные проблемы (например, remote root access через львиную долю реализаций протокола telnet), однако частота появлений таких дырок достаточно низка.

Недостаток telnet-протокола в основном заключается в том, что при наличии возможности прослушивания линии (sniffing), можно восстановить всю сессию, включая введенные имя пользователя и пароль. Существуют реализации этого протокола с шифрованием всей введенной информации, но тогда теряется то преимущество, что telnet-клиенты есть практически во всех операционных системах, да и гораздо лучше с этим справляется протокол ssh.

SSH изначально проектировался как замена telnet, а потому учитывает все его недостатки и, кроме того, добавляет большое количество полезных возможностей, а именно: полное шифрование сеанса, сжатие информации (вещь весьма полезная для доступа к серверу с dial-up соединений), а также возможность выступать посредником сетевого уровня между приложениями.

С самим по себе протоколом проблем особенных нет (тем более, что существует и его реализация с шифрованием информации), единственная проблема, обычно связанная с функцией отправки почты сервера – это сам демон – в большинстве случаев это сервер sendmail. В прошлом этот сервер имел, пожалуй, самую богатую родословную по количеству ошибок. Сейчас все (или большинство) эти проблемы похоже что устранены, но для использования на сервере всё же можно посоветовать почтовый клиент qmail (https://cr.yp.to/), неплохо справляющийся со своими функциями и не имеющий (на данный момент) проблем с безопасностью.

Здесь практически всё так же, как и с SMTP-протоколом, и в качестве сервера и здесь можно посоветовать всё тот же пакет qmail, куда входит и клиент для POP3.