Регистрация ошибок через HTTP - последствия для безопасности

Question

Я пишу приложение, в котором ошибки приложения регистрируются и отправляются в прослушивающий порт HTTP на нашем сервере. Мы решили отказаться от электронной почты, поскольку многие клиенты, работающие на сервере, «не смогут отправлять что-либо через SMTP» (согласно боссу)

Я просто собирался отправить данные как есть, используя log4net и специально написанный HTTPAppender.

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

Answer 1

Это зависит от того, как вы определяете безопасность и как вы ее блокируете.

Какое влияние окажет внешняя атака на ваш HTTP-слушатель? Предполагая, что сам слушатель безопасен, все, что он сможет сделать, это добавить ложные записи в журнал. Это серьезная проблема? Вас беспокоит возможный отказ в обслуживании, например, записи нежелательного журнала, заполняющие все доступное дисковое пространство?

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

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

Answer 2

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

Answer 3

Если ваш сервер находится в той же сети и не является общедоступным, проблем не должно быть.

Если он доступен из Интернета, то вы можете подписать свои журналы, чтобы избежать DOS-атак. Если в вашем приложении есть что-то чувствительное к ошибкам, вы можете использовать шифрование, чтобы избежать утечки информации.

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

Answer 4

Если запросы отправляются по HTTP без SSL / TLS, то сообщения, конечно, подвергаются целому ряду атак типа «человек посередине». Любой узел между отправителем / клиентом и сервером сможет читать сообщения и манипулировать ими.