Controlling Logging to Central Syslog-ng Server, DoS etc
Hi all, What is the best way to control logging to my central log server? I have read syslog-ng docs quite a lot when I was first setting it up but I don't recall seeing anything on access control. Doesn't this leave me open to DoS attacks etc? After all, you couldn't somebody just write a loop to send garbage to it and fill the whole machine up, not to mention drown out all other valid logs so you miss any important events (oops, I am giving away too much here?). I'm actually tempted to write an attack for this right now... So what do I do to stop some other person from doing this to me? I guess I could use iptables to make sure that only authorized ips can connect to my tcp and udp ports. Is there a better way I haven't thought of? -h -- Hari Sekhon
On Fri, Sep 22, 2006 at 03:18:50PM +0100, Hari Sekhon wrote:
After all, you couldn't somebody just write a loop to send garbage to it and fill the whole machine up, not to mention drown out all other valid logs so you miss any important events (oops, I am giving away too much here?). I'm actually tempted to write an attack for this right now...
This is always a risk. It's obvious enough that it's not discussed much. syslog-ng has tcp wrappers support, and you always have packet filtering. You should certainly block unauthorized IPs, but your authorized IPs are just as scary as the others. The miscreant will either be an authorized user or have compromised an authorized account and will flood your syslog server from there. If you want to dicuss DoS, come up with a way to deal with that. -- Nate "Let us be thankful for the fools. But for them the rest of us could not succeed." - Following the Equator, Pudd'nhead Wilson's New Calendar - Samuel Clemens
nate wrote:
On Fri, Sep 22, 2006 at 03:18:50PM +0100, Hari Sekhon wrote:
After all, you couldn't somebody just write a loop to send garbage to it and fill the whole machine up, not to mention drown out all other valid logs so you miss any important events (oops, I am giving away too much here?). I'm actually tempted to write an attack for this right now...
This is always a risk. It's obvious enough that it's not discussed much. syslog-ng has tcp wrappers support, and you always have packet filtering.
You should certainly block unauthorized IPs, but your authorized IPs are just as scary as the others. The miscreant will either be an authorized user or have compromised an authorized account and will flood your syslog server from there.
If you want to dicuss DoS, come up with a way to deal with that.
I agree. Unfortunately, the syslog protocol is insecure by nature and therefore we are left with either old ip filtering which as you said still leaves a problem, in that a miscreant will either be an authorized user or have compromised an authorised user's account. In fact, it's even worse because you can simply spoof an address of a real server to get through. It's even easier if you allow udp because they could just fire off udp packets without even having to reply to them and therefore you don't even need to take over the ip of the spoofed machine. One possibility is that you could try and surpass syslog protocol by allowing only syslog-ng tcp connections and providing some authentication mechanism like certificates or keys or something, like ssh keys or some other public private certificate system. Although the overhead will be considerable, both in machine terms and humans admin terms, but I can't think of any other way of really doing this at the moment. Perhaps instead of the connection being authenticated, the packets themselves could be signed, although I'm no cryptography expert to know how secure that would be against forgery. Would it be more secure to use a tcp SSL tunnel using or something and then set up tunnels for the syslog machines? Although highly secure in that only specific machines could go through to the server and loop back in to the syslog server, you'd be left with those servers being the only points of failure regarding malicious users or compromised accounts, other than the syslog-ng server itself. I feel that it would be a huge and difficult task to add serious security to syslog-ng beyond this. just my 3 cents... -h -- Hari Sekhon
Hi, Hari Sekhon <hpsekhon@googlemail.com> [20060922 16:34:40 +0100]:
If you want to dicuss DoS, come up with a way to deal with that.
[snipped]
Perhaps instead of the connection being authenticated, the packets themselves could be signed, although I'm no cryptography expert to know how secure that would be against forgery.
Would it be more secure to use a tcp SSL tunnel using or something and then set up tunnels for the syslog machines? Although highly secure in that only specific machines could go through to the server and loop back in to the syslog server, you'd be left with those servers being the only points of failure regarding malicious users or compromised accounts, other than the syslog-ng server itself.
erm.....IPSec or use IPv6 where then encryption/authentication is built in. You could slap the same certificate on all the machines or be *very* lazy and use a shared secret passphrase. Either way the kernel would drop the packet as its not encrypted correctly and of course its multi-platform.
I feel that it would be a huge and difficult task to add serious security to syslog-ng beyond this.
just my 3 cents...
IPSec could give you change for that ;) Cheers Alex
On Fri, 22 Sep 2006 18:26:16 BST, Alexander Clouter said:
erm.....IPSec or use IPv6 where then encryption/authentication is built in.
Just as a heads-up - "IPv6 where encryption is built in" doesn't mean what you think it means. :) IPv6 uses *the same exact* IPSec that IPv4 uses. The only difference is that IPSec is an *optional* thing to support under IPv4, while an IPv6 stack has to support it. This in *no* way means that a site running IPv6 has to, or does, actually configure and enable the IPSec support - just that the stack has to come with the pieces needed to do it if the site so chooses. And in fact, given the amount of time that IPSec has been out for both IPv4 and IPv6, I doubt that there's any sites that have set it up for IPv6 that did *not* already use it for IPv4....
On 9/22/06, Hari Sekhon <hpsekhon@googlemail.com> wrote:
nate wrote: On Fri, Sep 22, 2006 at 03:18:50PM +0100, Hari Sekhon wrote: After all, you couldn't somebody just write a loop to send garbage to it and fill the whole machine up, not to mention drown out all other valid logs so you miss any important events (oops, I am giving away too much here?). I'm actually tempted to write an attack for this right now...
It's been done. Code is out there.
One possibility is that you could try and surpass syslog protocol by allowing only syslog-ng tcp connections and providing some authentication mechanism like certificates or keys or something, like ssh keys or some other public private certificate system. Although the overhead will be considerable, both in machine terms and humans admin terms, but I can't think of any other way of really doing this at the moment.
For very low volume logs, I've installed syslog-ng and stunnel on both the source and destination machines, and bound the TCP sockets to 127.0.01 on the sending and receiving machines, so all syslog goes via the tunnel. Tricky part is getting stunnel's "transparent mode" to work so syslog-ng sees the connection as coming from the real source, not from loopback.
Perhaps instead of the connection being authenticated, the packets themselves could be signed, although I'm no cryptography expert to know how secure that would be against forgery.
There are a couple of options to address this without changing syslog-ng: 1) You can turn on IPSEC on the source machines and the syslog server, and then you can even take in UDP packets. 2) As of OpenSSH version 4.3, you can tunnel UDP packets through SSH.
I feel that it would be a huge and difficult task to add serious security to syslog-ng beyond this.
I feel it would be a small and easy task to add SSL support to syslog-ng for TCP connections, just link against OpenSSL and add a few new options for tcp() sources. Kevin
On Fri, 2006-09-22 at 16:34 +0100, Hari Sekhon wrote:
nate wrote:
On Fri, Sep 22, 2006 at 03:18:50PM +0100, Hari Sekhon wrote:
After all, you couldn't somebody just write a loop to send garbage to it and fill the whole machine up, not to mention drown out all other valid logs so you miss any important events (oops, I am giving away too much here?). I'm actually tempted to write an attack for this right now...
This is always a risk. It's obvious enough that it's not discussed much. syslog-ng has tcp wrappers support, and you always have packet filtering.
You should certainly block unauthorized IPs, but your authorized IPs are just as scary as the others. The miscreant will either be an authorized user or have compromised an authorized account and will flood your syslog server from there.
If you want to dicuss DoS, come up with a way to deal with that.
I agree. Unfortunately, the syslog protocol is insecure by nature and therefore we are left with either old ip filtering which as you said still leaves a problem, in that a miscreant will either be an authorized user or have compromised an authorised user's account.
In fact, it's even worse because you can simply spoof an address of a real server to get through. It's even easier if you allow udp because they could just fire off udp packets without even having to reply to them and therefore you don't even need to take over the ip of the spoofed machine.
One possibility is that you could try and surpass syslog protocol by allowing only syslog-ng tcp connections and providing some authentication mechanism like certificates or keys or something, like ssh keys or some other public private certificate system. Although the overhead will be considerable, both in machine terms and humans admin terms, but I can't think of any other way of really doing this at the moment.
Perhaps instead of the connection being authenticated, the packets themselves could be signed, although I'm no cryptography expert to know how secure that would be against forgery.
Would it be more secure to use a tcp SSL tunnel using or something and then set up tunnels for the syslog machines? Although highly secure in that only specific machines could go through to the server and loop back in to the syslog server, you'd be left with those servers being the only points of failure regarding malicious users or compromised accounts, other than the syslog-ng server itself.
I feel that it would be a huge and difficult task to add serious security to syslog-ng beyond this.
just my 3 cents...
I have already committed partial TLS support to my internal development tree. If you only allow TCP/TLS connections with X.509 certificate based authentication, then _if_ you trust complete hosts (e.g. no rogue users), you should be fine. There's also a syslog-sign draft floating around, which signs individual syslog messages, but that requires even more application support which currently simply does not exist. -- Bazsi
participants (6)
-
Alexander Clouter
-
Balazs Scheidler
-
Hari Sekhon
-
Kevin
-
nate
-
Valdis.Kletnieks＠vt.edu