influxdata / telegraf

Agent for collecting, processing, aggregating, and writing metrics, logs, and other arbitrary data.
https://influxdata.com/telegraf
MIT License
14.59k stars 5.56k forks source link

IPTables input not working #2215

Closed MrDienns closed 7 years ago

MrDienns commented 7 years ago

Hello

Im trying to get the iptables input to work for telegraf. After already having a bunch of issues using permissions, I finally got it "working". The systemd output from iptables can be found here: https://hastebin.com/umikevodos.vbs

To be me this looks like iptables is properly being able to use sudo, as defined in the config, and upload its data to the server. Whenever I check the server though, there are no measurements for iptables. There's nothing there. I tested this on multiple servers, and none of them is pushing data towards InfluxDB.

All other inputs from telegraf seem to work fine.

Ubuntu 16.04 LTS Telegraf 1.1.1

sparrc commented 7 years ago

you'll need to provide more information for debugging this. Can you try using a file output plugin to test getting metrics? did you try running with different user permissions?

MrDienns commented 7 years ago

Here is a more detailed log, also containing the other metrics that I used. https://hastebin.com/emoveyucec.coffeescript Like I said before, as you can see all other inputs from telegraf work fine.

Here is a screenshot my InfluxDB query; http://prntscr.com/dtf8x4

As you can see, there's only one database. No mistakingly using the wrong one. You can see all of the other measurements, like I said before, those work fine. IPTables is just not pushing data into InfluxDB. It looks like its able to gather data, but I cant confirm this. I tried running it as root, still no results in InfluxDB. Permissions should no longer be the issue.

http://prntscr.com/dtfadu Here's another screenshot of the other metrics data being used in Grafana. It's simply IPTables which does not seem to work.

Note: I'm a beginner when it comes to Linux, if you want me to do something, please provide some commands. :)

sparrc commented 7 years ago

please provide the configuration entry for the iptabels plugin

MrDienns commented 7 years ago

Here you go https://hastebin.com/qoraxetoru.lua

sparrc commented 7 years ago

what happens if you run sudo iptables -nvL INPUT -t filter -x? Try running this as the telegraf user as well, does it ask for a password?

MrDienns commented 7 years ago

Result of the command: https://hastebin.com/cojodofegu.sql Executing it as telegraf means that I have to login, I suppose. It's asking for a password.

sparrc commented 7 years ago

did you edit your sudoers file?: https://github.com/influxdata/telegraf/tree/master/plugins/inputs/iptables#using-sudo

MrDienns commented 7 years ago

Yes I did. Pretty sure you're able to see from the first log I provided that IPTables is able to open a session with root privileges. Never the less, the sudoers file contains telegraf ALL=(root) NOPASSWD:ALL at the moment since the given one on the GitHub page did not work properly duo to insufficient permissions issue.

sparrc commented 7 years ago

I don't think it's setup properly if it's asking for a password. The point is that telegraf needs to be able to run a "sudo" command without a password

MrDienns commented 7 years ago

It asks for a password when I try to login as the user, like I said. It does not ask for a password when using sudo, as set up in the sudoers file: telegraf ALL=(root) NOPASSWD:ALL

sparrc commented 7 years ago

Can you try using a file output plugin to test getting metrics? Send the metrics to stdout and see if the iptables metrics are appearing

MrDienns commented 7 years ago

I replaced the InfluxDB output with a file output and let it run about half a minute. Here's the result.

https://hastebin.com/eketosujon.go

(Sorry for the wait)

sparrc commented 7 years ago

seems like it must be a permissions issue, sorry I can't help debug that any further, but the best I can advise you would be to login as the telegraf user and attempt to run the provided iptables command.

If there are any steps that are not already outlined in the documentation that you find helpful, please consider submitting a PR to clarify.

If you have any evidence that shows otherwise, feel free to reopen the issue.

MrDienns commented 7 years ago

https://hastebin.com/dogijahaca.vbs

Does this not indicate that it's able to use the sudo command and check IPTables? There is no no-permission error anywhere to be seen. How do I even login as the telegraf user? I don't have any credentials.

The log states that it's able to gather metrics, but they don't end up in InfluxDB. Sure this is not a bug..?

MrDienns commented 7 years ago

I just ran telegraf as root for a minute, while pinging the server in another window. Pings are blocked duo to the default firewall rule of DROP.

https://hastebin.com/figoqojufo.rb

I'm now fully sure, this is not a permission issue.

dimtion commented 7 years ago

I'm having the same problem on a Debian Wheezy installation, even with running telegraf in root or with telegraf ALL=(ALL) NOPASSWD: ALL in the sudo file the plugins doesn't seems to ouput any data.

In /etc/telegraf/telgraf.conf:`

[[inputs.iptables]]
  use_sudo = true
  table = "filter"
  chains = [ "INPUT" ]

Another problem I have noticed on debian is that the path to iptables is not /usr/bin/iptables but /sbin/iptables. I don't think it is relevant for the plugin.

The other plugins are working well.

tkuehne commented 7 years ago

Hi @MrDienns, @dimtion,

I've had similar issues today on Debian Jessie. What finally fixed the problem, was removing these lines again from the /etc/systemd/system/multi-user.target.wants/telegraf.service file:

CapabilityBoundingSet=CAP_NET_RAW CAP_NET_ADMIN
AmbientCapabilities=CAP_NET_RAW CAP_NET_ADMIN

And run this afterwards:

systemctl daemon-reload

Here's what my sudoers file for the telegraf user has:

# cat /etc/sudoers.d/telegraf
telegraf ALL=(root) NOPASSWD: /sbin/iptables -nvL*

You may check, if sudo works properly by running this as root:

sudo -u telegraf sudo iptables -nvL

If this gives the expected output, the iptables plugin should work as well! :smile:

fahimeh2010 commented 7 years ago

same problem.

sudo -u telegraf sudo iptables -nvL

works as expected, but it does not output any data. sound likes iptables plugin does not work and also there is no log in telegraf.log

sparrc commented 7 years ago

OK, I'll reopen, if anyone can post exact steps to reproduce it would be helpful for us

fahimeh2010 commented 7 years ago

Telegraf Config: [[inputs.iptables]] use_sudo = true table = "filter" chains = [ "INPUT" ]

sudo configuration: telegraf ALL=(root) NOPASSWD: /sbin/iptables -nvL *

no permission problem. there is no output as measurement for iptables.

Thank you

MrDienns commented 7 years ago

Same issue as @fahimeh2010

I managed to get the permissions working, but nothing ends up in my database. No errors, no warnings. Only thing I see is that the telegraf user is able to use sudo, but I don't see any data.

All tests, logs files, etc are already listed way above.

sparrc commented 7 years ago

@ririsoft can you take a look at this?

ghost commented 7 years ago

@fahimeh2010, @MrDienns :

From the documentation:

Rules are identified through associated comment. Rules without comment are ignored.

Looking at the file provided by @MrDienns the iptables rules do not have any comment, thus explaining your results. You have to add comment to the rules you want to monitor using iptables comment module for instance: -m comment --comment "a comment to identify this rule"

For @fahimeh2010 and others I have no iptables output but I suspect this is the issue, unless proven the contrary.

This behavior was discussed when I initially submitted this plugin. Maybe we can do better here. Any idea is welcome.

sparrc commented 7 years ago

@ririsoft it seems to be confusing a fair amount of people, so it's probably worth making the documentation state this more obviously, and also even put a NOTE: ... line in the SampleConfig.

ghost commented 7 years ago

@sparrc I wish I had a better idea for this than just improving the documentation. I discover that it was also discussed on the iptables mailing list 13 years ago without a better solution than what we propose here unfortunately.