views:

43

answers:

4

I am writing an application in which application errors are logged and posted to a listening HTTP port on our server. We decided against email since many of the clients running the server "would not be able to send anything through SMTP" (according to boss dude)

I was just going to send the data as-is using log4net and a custom-written HTTPAppender.

I'm wondering about possible security implications of using this approach, or whether there's a better one out there. The listening port would of course be protected against SQL injections and the like.

+2  A: 

I would cryptographically sign anything you send to that listener - not to keep it secret, but to prevent DoS type attacks, you don't want it wide open so that anybody can send anything to it. Anything that isn't signed should be rejected.

slugster
+1  A: 

If the requests are sent over HTTP without SSL/TLS then the messages are subject to a range of man-in-the-middle attacks of course. Any node between the sender/client and the server will be able to read and manipulate the messages.

Michael Greene
+3  A: 

It depends on how you define security, and how you go about locking it down.

What is the impact if an outside attacker is able to reach your HTTP listener? Assuming the listener itself is secure, all that they would be able to do is append spurious entries to the log. Is this a serious problem? Are you concerned about a possible denial of service, for example, junk log entries filling up all the available disk space?

If so, then do what you can to lock down the listener. Use some form of HTTP authentication. Configure it to only accept traffic from certain IP addresses. Better yet, put it on a restricted network where the outside world can't reach it at all.

The only other risk is if your listener is literally at a remote location and you have to go over the public internet to reach it. This I would not recommend as it opens up the possibility of somebody snooping on the messages and thus discovering potentially sensitive information about your system.

Aaronaught
+1  A: 

If your server is on the same network and not publicly accessible there should be no issue.

If it is accessible from the internet then you would want to sign your logs to avoid DOS attacks. If there is anything sensitive in your application errors, you may want to consider encryption to avoid information leakage.

Another option might be to leave your server behind a firewall and connect to it with a SSH tunnel or similar. If the client machines accept port-forwarding connections only from localhost, this would mitigate both the denial of service and leakage problems.

Duncan