Getting Data In

Heavy Forwarder Server vs Clients connecting directly from DMZ

jlum
New Member

Which is preferable, having a heavy forwarder/deployment server in the DMZ or opening the Splunk ports from the existing DMZ servers (30 servers) to communicate with Splunk in production? If we build a new HF/Deployment Server in the DMZ, we will not have to worry about opening the Splunk ports from the other DMZ servers BUT we would want to have RDP access (opening the RDP port) to this new deployment server from our desktops. If we choose not to have a deployment server in the DMZ, there is no need for us to open additional RDP ports. Is there a recommendation/best practice to follow for this?

0 Karma
1 Solution

wyfwa4
Communicator

Having a heavy forwarder with deployment services running in the DMZ means you only have a single interface between your DMZ and your internal network. This means the firewall rules are much simpler to manage and also to monitor. The risk is that you need to create an inbound firewall connection from the DMZ to your internal network to allow the data to be sent to an indexer. For RDP, this is not normally considered an issue, as it is outbound only (from your network to DMZ) and so should not allow any traffic to enter from the DMZ. Just make sure the firewall rules are clearly defined as uni-directional.

One other option to consider, is to also use this heavy forwarder as an indexer to store your data - you could then add an outbound rule from your internal indexer to your DMZ indexer. This would allow you to search the DMZ data from inside your network without needing to open any inbound connections. This option is only realistic if the data being stored in the DMZ is not sensitive.

View solution in original post

0 Karma

wyfwa4
Communicator

Having a heavy forwarder with deployment services running in the DMZ means you only have a single interface between your DMZ and your internal network. This means the firewall rules are much simpler to manage and also to monitor. The risk is that you need to create an inbound firewall connection from the DMZ to your internal network to allow the data to be sent to an indexer. For RDP, this is not normally considered an issue, as it is outbound only (from your network to DMZ) and so should not allow any traffic to enter from the DMZ. Just make sure the firewall rules are clearly defined as uni-directional.

One other option to consider, is to also use this heavy forwarder as an indexer to store your data - you could then add an outbound rule from your internal indexer to your DMZ indexer. This would allow you to search the DMZ data from inside your network without needing to open any inbound connections. This option is only realistic if the data being stored in the DMZ is not sensitive.

0 Karma

jlum
New Member

Thank you for the response.

0 Karma

vessev
Path Finder

Hi,
how could a configuration look like where i pull data from an DMZ HF?
The only settings i know are push.

Best Regards Michele

0 Karma

wyfwa4
Communicator

Just to clarify - Splunk forwarders / heavy forwarders can only push data to another Splunk instance - this is explicitly defined in the name "forwarder". They cannot pull data from another Splunk instance. You cannot "pull" data from a heavy forwarder.

The only time you use Splunk to "pull" data is in the following scenarios

  1. A Splunk instance (forwarder/indexer etc) has an input defined to remotely collect data. For example to monitor a file on a remote share
  2. You send a remote command to a Splunk instance to read/write/apply configuration settings. - for example run CLI command or rest API call. However this generally relates to configuration only and not to perform regular data pulls.
  3. A splunk search head can point to a remote indexer to perform a remote search and effectively pull the data back to the search head - but the target needs to be an indexer which stores data.

So if you want to have data remaining in the DMZ that you can "pull" - you would have to deploy an indexer to store this data in the DMZ, then you use a remote search instance to "pull" results as and when required.

0 Karma
Get Updates on the Splunk Community!

Adoption of RUM and APM at Splunk

    Unleash the power of Splunk Observability   Watch Now In this can't miss Tech Talk! The Splunk Growth ...

Routing logs with Splunk OTel Collector for Kubernetes

The Splunk Distribution of the OpenTelemetry (OTel) Collector is a product that provides a way to ingest ...

Welcome to the Splunk Community!

(view in My Videos) We're so glad you're here! The Splunk Community is place to connect, learn, give back, and ...