On Mon, 7 Jun 2010, Dirk H. Schulz wrote: > Hi folks, > > I have stumbled over a difficult question. > > In a developed security environment where you run several network zones > with the most important data/servers in the inner zones and "outside > contact servers" like web proxies in the outer zone - in such an > environment a central syslog server should be positioned somewhere in > the inner zones, but the servers in the outer zones must not be allowed > to push messages into the inner zones - these messages have to be > fetched by the central servers from the outside zones' servers.
Yes and No. The reason for not wanting to push data in is that the data originating from the less secure zones may be corrupt and/or an attack. Pulling the same data in doesn't help protect against this. On the other hand, one of the big reasons for getting the logs from the less secure zone is for forensic purposes. In this case you want the logs to not sit on the outside (where they can be tampered with) if you can avoid it. Pushing the data into the central server as each log is generated is far better than polling to get the accumulated messages would be. The syslog protocol is a fairly nice combination of some strictly defined elements and loosely defined content. As a result, things accepting and processing the messages have to accpet a lot of strange stuff and deal with it sanely, but at the same time you can setup fairly simple systems to detect strange things being sent to you. What I do is to have dedicated relay boxes that are hardened and monitored to receive the messages from the untrusted zones, they then perform any fixups needed to the logs (including escaping binary characters in log messages), and then sending the santitized messages on to the central log server. There are many schemes out there to have systems write logs locally and then poll to retrieve the files. rsyslog supports reading log messages from files to you could easily insert the logs back into a normal syslog stream, but I always try to avoid such schemes. They tend to be fragile, and they leave the logs on untrusted systems where they can be tampered with for a window of time. David Lang _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
