Most all of the example configurations out there that show how to setup logstash with syslog traffic tend to always include some sort of non-standard syslog port, such as 5000 or 5514. Now this is fine so long as the client you are shipping the logs from provides the ability to specify which port they do so on – but I’ve run into a few different scenarios where I’m forced to send my syslog traffic down port 514, the normal syslog port, without the ability to select any other port.
The standard syslog port, 514, presents a problem in itself though – in some newer Linux distributions we have these things called privileged ports. Basically, those ports which are less than 1024 are deemed “privileged” – and a privileged port can only be opened and listened on by the root account!
So what? No biggie right!? Well, in the case of the logstash service it runs under a user by the name of “logstash”, not root – therefore, if you are trying to send traffic through to logstash on a port that is privileged, like 514, we have an issue!
So what we are left with are some errors within our logstash logs – similar to the following
ERROR couldn’t connect to tcp socket on 10.0.0.3:514; No connection could be made because the target machine actively refused it.
So what do we do?
I tried a number of different workarounds (using IP Tables to forward 514 -> 5514, getting the logstash daemon to run as root, etc) – but in the end, I found that using setcap was probably the easiest and less obtrusive method. So – to be “quick to the point” like the title suggests – here is my workaround
|
1 |
setcap cap_net_bind_service=+epi /usr/lib/jvm/java-8-oracle/jre/bin/java |
In the end what we are doing here is allowing the java process to bind to those privileged ports which are less than 1024. Obviously changing the location to suit the needs of your environment and where you have the java binaries. After a quick restart of logstash you should be successfully receiving syslogs on its’ standard port.
