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

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

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

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

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

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

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

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

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

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

Ответы [ 3 ]

2 голосов
/ 21 сентября 2009

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

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

1 голос
/ 21 октября 2009

Если я могу предположить, что данные, которые вы собираете, не являются конфиденциальными, поэтому шифрование / конфиденциальность не нужны, я вижу очень небольшой риск при написании вашего собственного сервера, особенно если вы будете следовать рекомендации 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: address@ignored.com
< 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 и добавив salted hash . При обработке даты игнорируйте все, что находится за пределами строк BEGIN / END, и проверьте хеш.

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

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

1 голос
/ 21 октября 2009

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

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

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

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

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

...