On Mon, 7 Jun 2010, Dirk H. Schulz wrote: > Hi David, > > Am 07.06.10 16:19, schrieb [email protected]: >> 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. >> > Thanks for your elaborated answer. There is a phenomenon you did not > address: enterprise management. :-) > We have to implement policies defining the rules I described, be they > technically sensible or not.
as one of the paranoid security people setting such policies, I understand this. but it's something that can be addressed. >> 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. >> > That sounds like a promising compromise I could offer the policy guys. > Could you please post an example of how you escape binary characters? rsyslog does this by default, replacing any non-printable ascii characters with #nnn where nnn is the octal value of the byte this confuses some parsers (when there is a tab for example), but it means that the output is pretty safe to deal with. On these hardened servers I also have extra stuff to deal with 'problem' sources (things that don't send properly formatted messages, like things that put a message sequence nubmer in the server position) David Lang >> 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. >> > That is why I instinctively did not want to explore that kind of solution. > > Thanks a lot, David! > > Dirk > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
