Последствия для безопасности сервера с ограниченными функциями

Question

Я хочу собирать определенную информацию от людей / устройств по электронной почте. Эти электронные письма никогда не будут никому доставляться, а просто обрабатываются на сервере. Полученные электронные письма будут обработаны - некоторые просто отброшены, большинство сохранено (в базе данных), вложения могут или не могут быть сохранены (но никогда не выполнены) в зависимости от определенных условий.

Я исследовал с помощью существующего программного обеспечения MTA для этого, и пришел к выводу, что это было бы излишним и создать сложность намного выше, чем необходимо для этой цели.

Если бы я писал свое собственное программное обеспечение MTA, мне нужно было бы реализовать довольно ограниченный набор функций - буквально достаточно, чтобы получать электронные письма, не отправляя их вообще. Я бы держал реальное программное обеспечение MTA настолько тонким, насколько это возможно, чтобы минимизировать объем технического обслуживания. Таким образом, после того, как программное обеспечение MTA получит электронное письмо, оно передаст его (полностью) второму программному обеспечению, которое выполнит обработку.

Электронные письма просто хранятся, чтобы быть отправленными в веб-интерфейсе отправителем и кем-либо еще, кого они специально разрешают. Некоторые вложения будут сохранены, но никогда не будут выполнены на сервере и снова доступны только отправителю исходного письма и другим кандидатам.

Я очень мало знаю о мире сетевой безопасности - с таким ограниченным сервером я открываю потенциальный путь? Я думаю, что ответ на этот вопрос всегда да - но я менее безопасен, чем с хорошо поддерживаемым, безопасным, но полнофункциональным программным обеспечением MTA (например, Postfix)?

Если я не был конкретен или достаточно ясен, пожалуйста, дайте мне знать, спасибо!

(Сервер будет Linux, скорее всего, Ubuntu. Программное обеспечение, скорее всего, написано на C# под Mono, возможно, Python или смесь (сервер C#, обработка Python))

@ S. Lott Я потратил последние 3 дня на изучение возможности использования существующего программного обеспечения, и мне кажется, что моим лучшим решением будет Postfix > Procmail > моя собственная обработка. Postfix - это законченное решение MTA, для которого потребовалось немало конфигураций, чтобы приблизиться к тому, что я хочу, - сложность во многом связана с конфигурацией, и заставить стороннее программное обеспечение работать вместе, что и делает мой выбор. Я уверен, что кому-то хорошо разбирающемуся в настройке почтовых серверов и администрировании nix-серверов в целом, было бы намного проще, но, на мой взгляд, индивидуальное решение не было бы огромным проектом - моя единственная реальная проблема - безопасность.

Кроме того, что касается перерасхода - мне нужно очень ограниченное подмножество того, что делает Postfix, и большая часть конфигурации, на которую я смотрел, пыталась отключить определенное поведение. Во многих отношениях я предпочел бы использовать зрелый, стабильный Postfix вместо моего собственного решения, но я чувствую, что уже потраченное время можно было бы использовать гораздо более продуктивно, написав что-то специально для этой задачи.

Answer 1

Если я могу предположить, что данные, которые вы собираете, не являются конфиденциальными, поэтому шифрование / конфиденциальность не нужны, я вижу очень небольшой риск при написании вашего собственного сервера, особенно если вы следуете рекомендации PaulG о размещении сервера в защищенной от огня DMZ.

Исходя из вашего описания, я не считаю ваш сервер MTA; скорее это сервер передачи файлов, который говорит по SMTP. Давайте посмотрим на гипотетическую сессию и обсудим некоторые вопросы:

[Client connects to your server]
< 220 Welcome message from your.server.com
> HELO someclient.com
< 250 your.server.com
> MAIL From: [e-mail]
< 250 OK
> RCPT To: another_address@also_ignored.com
< 250 OK
> DATA
< 254 End data with <CR><LF>.<CR><LF>
> client sends data here
> .
< 250 OK
> QUIT
< 221 Bye
[Close connection]

Что нужно подумать:

• Является ли безопасность проблемой вообще? (Нужно ли защищаться от спама? Вам нужно проверить клиента, отправителя или получателя?) Если ответ "нет", вы можете игнорировать все, что следует HELO, MAIL, а также RCPT и отправить 250 ответ безоговорочно.

• Вы можете сбросить все между DATA и . в файл для обработки. Возможно, вы захотите ограничить размер, и обработка будет проще, если данные будут в незашифрованном виде: без MIME или Base64, без вложений.

• Вашему серверу потребуется обработка исключений: он должен корректно реагировать на тайм-ауты, ошибки протокола и преждевременное отключение.

• Если вы контролируете содержимое сообщения, вы можете выполнить простую аутентификацию и проверку, поместив ваши данные между какими-то строками BEGIN и END и добавив соленый хеш. При обработке даты игнорируйте все, что находится за пределами строк BEGIN/END, и проверьте хеш.

• Наконец, я бы сказал, что postfix может создать больше проблем с безопасностью, чем решить. Со всеми его функциями и гибкостью вам действительно нужно понимать, как правильно его настроить, а неправильная конфигурация может превратить ваш сервер в реле для спама.

Удачи - пожалуйста, дайте нам знать, какое решение вы выберете!

Answer 2

Я не вижу большой проблемы. Я бы положил MTA внутрь DMZ, которая строго огненная. Например, база данных будет находиться за пределами DMZ в другом окне.

Такое использование DMZ является хорошей практикой, независимо от того, используете ли вы коммерческий почтовый сервер или пользовательский сервер. Если пользовательский выбор является более практичным выбором, то вы на правильном пути

Answer 3

Если у вас нет опыта написания серверного программного обеспечения, я бы просто использовал Postfix в качестве MTA и обрабатывал сообщения, используя любые интерфейсы, которые он предлагает (вместо того, чтобы пересылать почту в ваше приложение через SMTP.

Я бы не стал писать новый пользовательский MTA, это просто еще один слой, который вы должны реализовать и защитить.

Не стоит недооценивать:

1. Сложность безопасности, особенно если вы не сталкивались с атаками в этой области.

2- Возможная долговечность вашей системы. Может показаться, что сейчас не стоит атаковать, но что если его оставить на 10 лет...?