5. Вопросы безопасности
Механизм ANONYMOUS предоставляет доступ к службам и/или ресурсам любому желающему. По этой причине его следует отключать по умолчанию, предоставляя администратору возможность включения этого механизма при необходимости.
Если анонимному пользователю предоставляется право записи, возможна организация атаки на службу путем заполнения всего доступного для записи пространства. Для предотвращения таких атак можно запретить запись для анонимных пользователей.
Если анонимные пользователи имеют возможность чтения и записи в одну область, сервер можно будет использовать в качестве коммуникационного механизма анонимного обмена информацией. Серверам, разрешающим анонимным пользователям подачу информации, следует реализовать модель "drop box", в которой анонимный доступ для чтения невозможен в областях, открытых анонимным пользователям для подачи информации.
Если анонимный пользователь может запускать множество ресурсоемких операций (например, команд IMAP SEARCH BODY), это позволяет организовать атаку на службу. Для серверов настоятельно рекомендуется снизить приоритет для анонимных пользователей или ограничить для них выделяемые ресурсы.
Хотя серверы могут вносить ограничения на число анонимных пользователей, такие ограничения открывают возможность атак на службы, поэтому ими следует пользоваться с осторожностью.
Трассировочная информация не проверяется и ее можно фальсифицировать. Это может использоваться для указания чужих данных при доступе к информации сомнительного свойства. Администраторам, исследующим факты недопустимого использования, следует принимать во внимание возможность фальсификации трассировочных данных.
Клиентские программы, использующие корректный адрес электронной почты в качестве трассировочной информации без явного на то разрешения пользователя, может подвергать риску персональные данные пользователя. Любой, кто пользуется доступом к архивам специфического содержания с анонимным доступом (например, сексуальные извращения), очевидно нуждается в скрытности. Клиентским программам не следует передавать почтовый адрес пользователя без явного разрешения и следует предлагать пользователю опцию отказа от передачи трассировочной информации, показывая только IP-адрес и время.
Прокси-серверы с анонимным доступом помогут защитить приватную информацию, но следует принимать во внимание возможность организации в таких случаях DoS-атак.
Анонимные соединения чувствительны к перехвату с участием человека (man-in-the-middle attack) при которых передаваемая информация может просматриваться и изменяться. Клиентам и серверам настоятельно рекомендуется использовать внешние средства защиты данных.
Протоколы, которые не могут обеспечить явную регистрацию в системе (login) для анонимных пользователей, более уязвимы к вторжениям, связанным с некоторыми общепринятыми методами реализации. В частности, серверы Unix, которые предлагают пользователям регистрацию в системе (login) могут запускаться с правами пользователя root и переключаться на соответствующее значение user id после явной команды login. Обычно такие серверы отвергают все команды доступа к данным до явной регистрации в системе (login) и могут создавать безопасную среду с ограниченными возможностями (например, с помощью chroot в Unix) для анонимных пользователей. Если анонимный доступ не запрашивается явно, вся система доступа к данным может подвергнуться внешним атакам без возможности явного использования защитных мер. Протоколам, предлагающим ограниченный доступ к данным для анонимных пользователей, не следует предоставлять такой доступ без этапа явной регистрации в системе (login).
Общие вопросы безопасности SASL [SASL] применимы и к данному механизму.
Вопросы безопасности StringPrep [StringPrep] и вопросы безопасности Unicode [Unicode], рассмотренные в [StringPrep], также применимы к этому механизму. Вопросы безопасности UTF-8 [UTF-8] также применимы к данному механизму.