Firewall Rules Needed

[chicodeme]

When you install the splunk client by default it will have the following: tcp 0 0 0.0.0.0:8089 0.0.0.0:* LISTEN

If you issue: /opt/splunk/bin/splunk set splunkd-port 9089 Then you get: tcp 0 0 0.0.0.0:9089 0.0.0.0:* LISTEN

But if you look in web.conf: [root@server~]# cat /opt/splunk/etc/system/local/web.conf [settings] mgmtHostPort = 127.0.0.1:9089

So splunk is listening on all interfaces no matter what instead of just 127.0.0.1. Buggy?

I have some indexers accepting data from LWF's via 9997. So I know that I need the port 9997 open from the LWF's to the indexers. I started wondering if I would need 8089 open for anything. For downloading the deployment server apps, I allow on the firewall for LWF's to talk to the indexers(aka deployment servers) on 8089. I don't think that the deployment server would need to talk to the LWF's on 8089 so I don't have that open. Is that true?

If 8089 was listening on localhost like in says it would in the web.conf then I would know it doesn't need to talk from the deployment servers to LWF's.. but since that port is open on the network I am curious. Couldn't find anything searching around splunk.com

Also, if it is not needed. I'm going to have to get that process to listen only on localhost for extra security. Anyone know how to do that?

[araitz · Accepted solution]

You are looking in web.conf, where you are seeing the Splunk Web server being configured to talk to splunkd on 127.0.0.1:8089. That has nothing to do with what IP address Splunk binds to.

You need to set SPLUNK_BINDIP in ./etc/splunk-launch.conf:

SPLUNK_BINDIP=192.168.0.1

Listening to all listening interfaces by default is a fine standard behavior, not a bug at all.

To answer your other question, LWF will initiate all connections to the indexer, including data forwarding and deployment server activities. Thus, they will all need to be able to access the Splunk server at a routable IP address on TCP port 8089 (or whatever you set the management port t_o.

[chicodeme]

got it.. i thought it would NAT itself and it could get out.. but would run into the same type of issue since an ip datagram has a 127.0.0.1 at some point.. thanks for taking the time to provide this information.

[araitz]

Nope, 127.0.0.1 is non-routable except to localhost:

http://en.wikipedia.org/wiki/Localhost

"Any IP datagram with a source or destination address set to a loopback address must not appear outside of a computing system, or be routed by any routing device. Packets received on an interface with a loopback destination address must be dropped."

[chicodeme]

If the daemon was bound to 127.0.0.1 wouldn't it just use the default route of the server to reach out to deployment servers or indexers? which would be routable....

[araitz]

The problem with setting SPLUNK_BINDIP to 127.0.0.1 is that when they try to reach out to indexers or deployment servers to send data or poll for config changes, they won't be able to get there because the 127.0.0.0/24 is not routable by definition. If you are concerned about the port being open, I would recommend using a client firewall.

[chicodeme]

gotit..

i wasn't suggesting multiple interface listening was a bug.. i was suggesting that if its configured to listen on localhost and its not that is a bug.. but obviously that is not the case since this bindip variable exists.. ty.

i'll be setting that splunk_bindip=127.0.0.1 on all the LWF's..so that its not a port listening on the network for no need..