A very quick question to be sure in firewall's rules:
I have to open firewalls routes to permit traffic from the Forwarders to the indexers on 9997 port (one way).
Otherwise, to permit traffic between Forwarders and the Deployment Server on port 8089, I must open traffic both from and to the Deployment Server and the Forwarders. In other words, is it two way traffic or one way traffic like 9997?
I know that Forwarders call the Deployment Server and it polls them so I think that it's two way traffic, but I didn't find any confirmation to this in Splunk documentation.
Can someone help me to confirm this?
Thanks.
Bye.
Giuseppe
Updating this answer to help.
The direction determines which way the original communication can go.
If host a will contact host b every time,
Then you need one direction opened (from a to b). If both hosts will open connections to each other, you need both directions opened.
UFs call the Deployment server and ask for their apps, the deployment server never calls the UFs. So you don't need bodirectional from UFs to DS.
However, there are some apps that require inbound to the UF for managing the UF via REST. So if you plan to use those apps you will probably open 8089 from a search head to the forwarders.
Hi Giuseppe! For the purpose of configuring rules on a typical stateful firewall you just need to allow connections from the Forwarder to the Deployment Server on tcp/8089. In other words, the Deployment Server does not (at least currently) initiate connections to the Forwarder. It's just like your Forwarder to Indexer connections where you have a one way rule.
So you're saying when you deploy code FROM the deployment server, TO the forwarder... there's no need to allow communications FROM the deployment server TO the forwarder?
I get what you're thinking... the forwarder queries the deployment server to see if any changes have been made to the apps... that's one way... and its not the deployment server querying the forwarders to see if they have the latest apps. However... how does the forwarder know that the deployment server received the request to check if there are apps? Then, how does the deployment server send the code back through the firewall if indeed there are apps to be updated on the forwarders. Even if the forwarders PULL the data, communications are traveling in both directions.
Once a connection is established from the Forwarder to the DS, I agree that the communication must be bidirectional on that connection. However, the question was about firewall rules and firewalls typically track connection state and allow packets to flow in both directions on an established connection (https://en.wikipedia.org/wiki/Stateful_firewall). The question indicated that they already have a "one way" rule configured for Forwarder to Indexer traffic and I'm confident that they can use a similar rule for the Forwarder to DS traffic.
Finally, the communication from the Forwarder to the DS is typically going to be initiated from a random source port. Allowing the DS to send traffic to the Forwarder on destination port tcp/8089 will not have the desired result because the connection will have already been established from a different port on the Forwarder.
These are very good points and I stand corrected. As is always the case when I think I know it all 😜
When a forwarder starts call DS on 8089 port and when the DS polls uses 8089.
For this reason I think that I need a two ways open of firewall's rules.
Bye.
Giuseppe
For what it's worth, the management port is turned off on our Forwarders and DS works fine. The connections go in just one direction since the DS does not currently poll deployment clients. Sounds like you have a plan for your environment; good luck!
A lovely discussion with an outstanding visio diagram, which I downloaded and treasure ; -) - What are the ports that I need to open?
It says there -
-- On my forwarders, I see bi-directional data flowing on port 9997 between the forwarders and the indexers (using tcpdump src port 9997 and tcpdump dst port 9997)
The mentioned Visio grows my confusion: in the draw all 8089 and 9997 flows seems to be unidirection (there is only one arrow end), the only bidirectional flow seems to be the indexers replication.
Everyway to be sure I'll open 8089 in both the direction.
Bye.
Giuseppe
Right... the connection with the deployment server is, for sure, bidirectional. So, right this lovely visio diagram needs to change a bit ; -)
Updating this answer to help.
The direction determines which way the original communication can go.
If host a will contact host b every time,
Then you need one direction opened (from a to b). If both hosts will open connections to each other, you need both directions opened.
UFs call the Deployment server and ask for their apps, the deployment server never calls the UFs. So you don't need bodirectional from UFs to DS.
However, there are some apps that require inbound to the UF for managing the UF via REST. So if you plan to use those apps you will probably open 8089 from a search head to the forwarders.
Exactly jkat54!
Its networking / OSI model 101: TCP is a "connection-full" protocol. It requires bi-directional communications so the sender can receive ACKs from the receiver. UDP is a "connection-less" protocol. It sends data and doesnt care if anyone is listening or not.
All Splunk communications except for UDP/SYSLOG inputs & outputs are TCP. Therefore all Splunk ports are bi-directional. It doesnt matter what VISIO diagram you find and who/where it came from. Not everyone understands TCP, and very few ever have to understand bi-directional vs uni-directional. You can almost always count on the technical writers getting it wrong with their "arrows".
Jtacy corrected my networking 101
Mistake with a bit of networking 201.
The "directionality" of the FIRST communication is typically what is being discussed here. If I let
Server 1 communicate to the Internet on port 80 via unidirectional rule... Then TCP works fine and traffic flows both directions. However it's only server 1 who can open / initiate the connection on port
80 and therefore the Internet can't open the connection back to server
1. This means the forwarders can be unidirectional to the deployment server. Port 8089 however, typically carries traffic in both directions but it's not typically used on forwarders.
A reason you might want 8089 open to a forwarder is if you want to manage it via API remotely. Which in that case you would only need unidirectional TO the forwarder.
Final answer is no you don't need bidirectional from the forwarders but unidirectional from the forwarders will do just fine.
All credit to @jtacy.
For what it's worth, I don't see a huge security issue with having bidirectional on port 9997; just its not necessary.
I agree to that. There is a confusion about what is "bidirectionnal" here. Any TCP connection, once opened by a source towards a destination on a specified port, will have data flowing in both directions by design: https://tools.ietf.org/html/rfc793#section-1.5.
When firewall configuration considerations happen, then the true question to answer is not about flow but rather "who opens that connection ?". Who is the source and who is the destination ? That is what IT staffs asks me all the time : give me your "source + destination + protocol + port involved" (see, this is a one way rule).
Now, I think the deployment server never initiates/opens a connection to the FWDers (poll mecanism from fwders to DS), so to agree with the response above and below made by @jkat54 and @jtacy : on the firewall => unidirection/one way rule for tcp traffic (1 firewall rule allowing connection from FWD => DS).
Hope it helps and confirms the answers made so far by @jkat54 and @jtacy.